Template talk:Ambox/Archive 11

Is there any particular reason why the amboxes aren't hard-coded on this project page? 129.215.149.99 18:15, 27 September 2007 (UTC)

So that the page isn't accidentally added to the cleanup categories, and to show the "intended" design to anyone who is having display problems or who has changed their monobook.css to alter it. I think. --Quiddity 19:46, 27 September 2007 (UTC)

Yeah, I too think that 129.215.149.99 meant: "Is there any particular reason why the article message box examples are hard-coded on this project page?"

And Quiddity explained it perfectly. And there is one more reason: So the examples don't change when we screw up the real running code like I did today...

--David Göthberg 20:46, 27 September 2007 (UTC)

They're too similar. It used to be that I could tell what they were at a glance but now I have to read them to find out what they're about. Sometimes non-conformity is better, you know? 86.137.127.139 16:56, 22 September 2007 (UTC)

And they're too easy to ignore. I don't know, my eye just scrolls past them without even noticing they're there. I liked the old, ugly ones. They got my attention. 86.137.127.139 16:58, 22 September 2007 (UTC)

Oh well, seems I am ignored :( 86.137.127.139 10:55, 23 September 2007 (UTC)

I agree somewhat with your point. Making the article messageboxes look nice and uniform shouldn't be a big concern, especially if it might interfere with usability. Personally I find the look too cheery and festive which strikes me as out of sync with their purpose. That said they may just take some getting used to. Cheers. —dv82matt 11:39, 23 September 2007 (UTC)

Standardization of some sort was necessary, though. Before, people would often place redundant or incorrect tags on pages just because they were so disorganized. This helps with that problem somewhat. Pyrospirit (talk · contribs) 15:09, 23 September 2007 (UTC)

Adding distinctive icons to more of them should help indentifying them at a glance. Unfortunately, some people seem to be objecting to icons on the grounds that "they're for birds and illiterates" (paraphrased, can't remember exact wording) and that people should just read the text. Some of the same people seem to object to the "kindergarten colors" in the sidebars too. —Ilmari Karonen (talk) 17:17, 24 September 2007 (UTC)

If we could make the icons a little smaller, I'd be happier with them ;) They're useful, but they often don't need to be as large as they are. --Quiddity 18:24, 24 September 2007 (UTC)

I think the icons, as they are now, seem a little too quirky and fun for what should. I'd like to make a batch of smaller (around 24px), simpler and less obtrusive icons for wikipedia, but I'm worried that such an undertaking might be rather fruitless in the face of hundreds of picky editors. Should I do a test run in an SVG file and post it here? —Down10 ^TACO 06:09, 28 September 2007 (UTC)

Please see the last few posts in the thread below at #Unity of design. I'd love to see some new icons made available, and draft/sketch examples would be great. This would indeed be a possibly contentious undertaking, and would need a separate page/project to work at (Make a subpage at Wikipedia:Icons perhaps). Wikipedia:Graphic Lab might be able to help, too. --Quiddity 18:25, 28 September 2007 (UTC)

 

• Note: This also creates vertical scroll bar. -Rocket000 06:22, 28 September 2007 (UTC)

  The ambox was incorrectly placed after the TOCLeft (I fixed it at Wikipedia:Most wanted articles). --Quiddity 07:13, 28 September 2007 (UTC)

Oh, didn't realize that. Thank you for fixing it, and thank you for fixing this page ;) -Rocket000 15:44, 28 September 2007 (UTC)

I have coded up a meta template for protection templates. It automatically handles the different message box looks for different name spaces. And while I was at it I took the liberty to add the standardised talk page "coffee roll" style. And it is designed to easily handle any further standards for other name spaces.

Disclaimer: Don't bother too much about the technical details of this template, since I have not yet documented all the technical peculiarities. And if you compare with the code for the current protection templates bear in mind that they have several errors and weird things in their code that I fixed in the meta template.

So take a look at {{pp-meta}} and say what you think here. (Please spare the talk page of the meta template for the technical discussions.)

--David Göthberg 21:56, 21 September 2007 (UTC)

Looks great! -- Flyguy649 ^talk _contribs 23:41, 21 September 2007 (UTC)

Why is there an icon in the top corner? --MZMcBride 17:45, 22 September 2007 (UTC)

Still, they shouldn't have different style on different namespaces. I would recommend you to wait until you officially have changed this projects area to outside the article namespace. _→AzaToth 21:02, 22 September 2007 (UTC)

MZMcBride: Do you mean the little grey padlock in the top right corner of {{pp-meta}}? That is part of the examples showing what that template can generate. Read the first sentence in the examples section in that template's docs.

AzaToth: What do you mean, do you dislike that we want the protection templates to match our other message boxes in main (article) space, or do you dislike that I applied the standardised talk page template look when they are in talk space? Talk page templates were standardised long ago, just that the protection templates were missed that time. And as you can see, I did retain the old look for all other name spaces. So I don't think I stepped outside the bounds of these two standards. Besides, it is mostly {{pp-template}} and {{pp-semi-template}} that should be used in template space and they should only be used in template space, so they really should follow the standardised talk page template style.

But, in the end this is just a suggestion, let's see what people think.

--David Göthberg 14:49, 23 September 2007 (UTC)

Generally, I don't understand why the templates should look different on talk pages, and to divert the appearance even more to other namespace for me seems illogical. _→AzaToth 15:20, 23 September 2007 (UTC)

Yeah, it shouldn't be doing that. The current protection templates don't have a grey icon on the top, because it's misleading. The protection templates are fully-protected, so they use a gold icon, and it's position is further to the right. While I think that the code should be standardised for protection templates, the functionality needs to remain the exact same. --MZMcBride 16:41, 23 September 2007 (UTC)

MZMcBride: As I answered you right above here and as that page also states: The grey padlock icon in the top right corner of the {{pp-meta}} page is just an example. The template can generate a golden padlock too, or a green, or black, or whatever colour you like. But since that page is not yet protected I choose to use the grey padlock in the example since that is the least untrue right now. Of course when/if that template goes into use then it should be fully protected and then that page should have a golden padlock in the top right corner.

And regarding the position: Most protection templates now actually place their small padlock icon where I put it for {{pp-meta}}. I think the reason is pretty clear, since if it is placed more to the right then it collides/hides several other things that are sometimes placed in the top right corner, like the "featured article golden star" etc.

--David Göthberg 09:35, 24 September 2007 (UTC)

I like the idea of standardizing it in the mainspace, and the talk namespace version is appropriate. As for other namespaces, I'd like to see it take on the {{ambox}} look, but I believe standardization of those is a completely different issue right? -- Reaper X 02:24, 26 September 2007 (UTC)

I think we really need to switch to {{pp-meta}} - the protection templates are the only templates commonly applied to mainspace which have not been converted, and if we want to change the design in other project spaces, a small change to {{pp-meta}} will enact the change instantly. Talk pages are already standardized, and it's in line with that where needed. It's a well-designed alternative with broad options, so I'd like to see it in action and might boldly change it. Nihiltres^(t.l) 14:44, 27 September 2007 (UTC)

Incidentally, I've come up with the code to convert {{pp-semi-protected}}, see Template talk:Pp-semi-protected#Conversion_to_pp-meta. Nihiltres^(t.l) 15:20, 27 September 2007 (UTC)

I would support using the ambox look for protection templates in the article namespace. I don't think that there is currently consensus to change the protection templates' appearance in other namespaces. —Remember the dot ^(talk) 17:08, 27 September 2007 (UTC)

Just to clarify ambiguity there, that means that you support the use of {{pp-meta}}, right? It's currently designed to only a) make pp templates ambox when in article space and b) not change the other namespaces, but be dynamic for templates placed in particular namespaces (talk namespaces use coffeeroll, non-talk, non-main use classic protection style). I'd like to see pp-meta implemented, so I'm essentially asking permission to switch the template design around here. Nihiltres^(t.l) 17:27, 27 September 2007 (UTC)

The question still is if it is ok to divert the look of the protection templates to satisfies the mainspace standardization, or that it would be better to wait and handle the protection templates when a project to standardize all message templates exists. I would recommend not to rush this. _→AzaToth 19:28, 27 September 2007 (UTC)

Why not? I'm not really seeing any objections or major disadvanmtages to not standardizing them. -- Reaper X 20:27, 27 September 2007 (UTC)

The question was which of these alternatives are the best, 1: break consistency of protection template to suit main space standard, 2: go out of scope of project, 3: wait until full standardization is in progress. _→AzaToth 21:32, 27 September 2007 (UTC)

AzaToth, {{pp-meta}} won't change anything, really, since the ambox conversion is namespace-dependent. All of the changes reflect accepted standardization movements, and non-talk, non-mainspace template incidences won't be affected (so Wikipedia: pages will look the same). I'll go through and change the main templates (though I can probably leave, say, {{pp-template}} alone, and maybe a couple others), and I'm sure people won't see ambox protection templates outside the mainspace. Nihiltres^(t.l) 21:34, 27 September 2007 (UTC)

That what I meant by alternative one, to divert the protection templates more than they are now, to suit the main space standardization. _→AzaToth 16:50, 28 September 2007 (UTC)

It seems to me to be a good idea to standardize the protection templates, despite the difference across namespaces, since it allows the standardization of the mainspace template messages to be completed while avoiding suddenly changing the appearance of the pages in other namespaces, for which there is no consensus yet for a change. I don't think it's out of the scope of the standardization project, since it involves a template placed most commonly on articles. I also don't think it's necessarily bad to display the template differently across different namespaces: it avoids the question of having amboxes in the project namespace, an idea which hasn't been addressed yet. Nihiltres^(t.l) 22:16, 29 September 2007 (UTC)

I've now worked out the code to use in general for any given protection template, but I'm unsure of text size relative to the standardization. Can someone check out User:Nihiltres/Sandbox, which currently contains the test version for {{pp-semi-protected}} (the prototype for the other protection templates), for font size/spacing issues? It's the only barrier I have before converting all the protection templates to the new namespace-dependent format. I'm confident that this is a good idea in general, since it makes the ambox improvement to the mainspace while minimizing the effect outside of article space. In any experiments, feel free to change the examples after the noinclude, they're for testing purposes (purge the page after editing to update the examples, and note that they might be being forced to represent being in a particular namespace at any given time.) Nihiltres^(t.l) 03:45, 28 September 2007 (UTC)

What's going on with the widths?

It doesn't happen all the time, but it does most of the time. Just case it doesn't do it for you, here's a screenshot of what I see.

Yes, it does it on articles too. - Rocket000 17:43, 27 September 2007 (UTC)

I saw that on articles, and wanted to ask the same thing too. What is going on? Titoxd^{(?!? - cool stuff)} 18:17, 27 September 2007 (UTC)

The CSS was changed but has been changed back. If you refresh your cache it should have the previous appearance again. — Carl (CBM · talk) 18:37, 27 September 2007 (UTC)

Now that was strange. In the screenshot above the templates {{future product}}, {{future road}} and {{future television}} behaves strange. I checked their code, that is not supposed to happen with the CSS change we did. (I also checked that no one has altered their code lately.) Browser bugs are weird...

--David Göthberg 20:31, 27 September 2007 (UTC)

I wonder if some templates still have custom divbox widths left over from before standardization. Or perhaps a few regular maintainers of specific templates set a custom width, as in "My template's too important to have just a regular width". szyslak 06:24, 28 September 2007 (UTC)

Or perhaps, "This template looks completely crap when it's so wide it takes up most of the page", which is the case for a lot of templates you've "standardized" – 86.133.139.4 11:00, 29 September 2007 (UTC)

I know this belongs as a part of the Manual of Style guideline series, however, the page still reads like it's a WikiProject. Is there even a project anymore? Because now that the standardization is (almost) complete, I have some ideas of other things we can work on, not specifically the ambox or talk-notice designs. Since this project page is now a official guideline, it's not really the place for discussing other tasks of template standardization, where should this work continue? What's the status of this project?

P.S. We missed {{Cleanup-articletitle}}. - Rocket000 18:00, 28 September 2007 (UTC)

Other template standard overhauls should be discussed at new pages, and linked from Wikipedia:Template standardisation.

We missed {{Cleanup-articletitle}} because it isn't listed anywhere at Wikipedia:Template messages, and is only used in 2 places currently! (I'll fix that now). --Quiddity 18:39, 28 September 2007 (UTC)

Thanks Quiddity! Yeah, I know it wasn't listed on Wikipedia:Template messages, I've been running into all kinds of templates I never knew existed. We missed other article message temps. For example, {{gamma software}} and {{Recently convicted}}. If I find any important ones I'll definitely post 'em here or change them myself if I can.

We have way too many, and sometimes it's hard to find the right temp (which is one reason people create redundant ones). This is one issue I want to address in a new (sub)project. It deals with creating a standard set of templates ("official" templates, if you will). We wouldn't be creating the actual templates, but creating a definite list of all templates to use. Inclusion/exclusion would be based on usage/logic/consensus. This would help us: organize them so they're easy to find, track changes, streamline any updates to the standard styles (helping future projects like this), among many other things... Anyway, where should something like this be discussed? I don't know the details yet or how to go about this so I don't want to propose a whole new WikiProject. Should it be a sub page of Wikipedia:Template standardisation or maybe just the talk page Wikipedia talk:Template standardisation, since it not really used anymore after the split? Someplace else? - Rocket000 04:59, 29 September 2007 (UTC)

Yes, that's the place. I've pulled the redirects to {{refimprove}} {{no source}} {{unreferenced}} and {{fact}} onto their respective documentation. This gives an idea of how complex the task could be. Rich Farmbrough, 11:22 29 September 2007 (GMT).

That sounds kind of like a duplicate of Wikipedia:Template messages? If you're suggesting adding an "approval-process" for the creation of new maintenance templates, I don't think that's a good idea (we have too much backlogged-process as it is, and the required-processes for creating new infoboxes/portals were discontinued due to general ignoring/not-seeing (iirc)).

However, improving/updating/clarifying/simplifying the current subpages of Wikipedia:Template messages would be good. TfD the unnecessary templates, redirect/merge the almost-identical templates, add the missing templates, check that templates are properly categorized, etc. If you want to improve the master page (which is akin to Help:Contents), discuss at it's talkpage and go cautiously, as many editors "know where things are, dangit!"

Never fork that which can be fixed! Duplication/redundancy is bad, as it leads to inconsistencies and broken discussions.

If you just want a shortlist of the most common/useful ones, there are all sorts of userpage templates, like User:Fuhghettaboutit/Toolbox, Template:UserTools, (the complete(?) list at) Template:Template messages, etc. --Quiddity 17:52, 29 September 2007 (UTC)

Well, here's what I was thinking. We would use Wikipedia:Template messages as our "main use" list. It would basically be our initial task - organizing/cleaning/adding/deleting. The other part would be creating (or repairing) subpages for each type of template which would list all the rest (our "complete list"). "Approval" would simply be including it in a list. The only criteria would be: is there a need for it? (duplicate?), does it adhere to the standard style/width?, and does it follow WP policies like NPOV? That's all I meant. After they're all collected, or after all of one kind are collected, then we can work on condensing/expanding/standardizing/making sure they're all doc'd/whatever. On the whole, the main purpose would be cleaning up the template namespace. A lot of work, I know, but once we get it organized, I think we can get it into shape. Rocket000 04:21, 2 October 2007 (UTC)

To avoid this:

 

Res ip sur lociter Res ip sur lociterRes ip sur lociterRes ip sur lociterRes ip sur lociterRes ip sur lociterRes ip sur lociterRes ip sur lociterRes ip sur lociterRes ip sur lociterRes ip sur lociterRes ip sur lociterRes ip sur lociterRes ip sur lociterRes ip sur lociterRes ip sur lociterRes ip sur lociterRes ip sur lociterRes ip sur lociterRes ip sur lociter

Rich Farmbrough, 11:22 29 September 2007 (GMT).

Please see discussion here: Template talk:Ambox#New suggestion. Several ideas are still under discussion. --TheDJ (talk • contribs) 01:52, 30 September 2007 (UTC)

Theoritically(Aesthetics) colors should be distributed throughout the area. So bar on right and image on left or vice versa would be better.

This article documents a current event. Information may change rapidly as the event progresses.

how does it look? or

This article documents a current event. Information may change rapidly as the event progresses.

Either of this would certainly look good than currently "imbalanced" layout. Thanks. Lara_bran 15:09, 1 October 2007 (UTC) Another "balanced" layout: (template removed) Thanks. Lara_bran 15:20, 1 October 2007 (UTC)

This was discussed earlier: Wikipedia_talk:Article message boxes/Archive 1#Single left bar.3B or two bars.2C one each side.3F. I like thin bars on either side, but most of the respondents liked a single bar.--Father Goose 20:22, 1 October 2007 (UTC)

You can customize your own layout to the right-border or double-border by copying the relevant ambox content from MediaWiki:Common.css to Special:Mypage/monobook.css and changing the CSS as you see fit - mostly changing "border-left 10px solid #xxxxxx" to "border-right 5px solid #xxxxxx; border-left 10px solid #xxxxxx". There's a consensus already that the left-bar design is generally good. Nihiltres^(t.l) 21:26, 1 October 2007 (UTC)

Single bar is fine, but bar and image on same side will make layout highly imbalanced(See Category:Visual arts theory). Thanks. Lara_bran 04:38, 2 October 2007 (UTC)

Thanks User:Nihiltres, but i hardly browse articles when logged in, i mean my pc keeps changing. Lara_bran 04:47, 2 October 2007 (UTC)

I still notice various older, more general cleanup tags that have not had their formatting standardized nor the color system introduced. I propose that we gather them and fix them up so that all cleanup tags will be standardized. Judgesurreal777 21:52, 1 October 2007 (UTC)

Let us know which ones we missed. Some have escaped notice by not being listed at WP:TM. Others are talk page notices, and follow the standard "talk page" style.--Father Goose 22:25, 1 October 2007 (UTC)

And let me know where your finding these (for my little project). Thanks. Rocket000 04:37, 2 October 2007 (UTC)

Will do! Judgesurreal777 14:09, 3 October 2007 (UTC)

Thanks! Rocket000 21:55, 3 October 2007 (UTC)

Just two sections below i have given 2 templates which should be incorporated into ambox. Please give a look, thanks. Lara_bran 16:07, 3 October 2007 (UTC)

I don't know if I missed the discussion, but why are the {{mfd}} tags so ugly? - Rocket000 04:41, 2 October 2007 (UTC)

That looks quite... nausiating indeed. — Edokter • Talk • 13:21, 2 October 2007 (UTC)

That looks better, but why is a different color used for MfD instead of the standard pink? Rocket000 21:07, 3 October 2007 (UTC)

Only the speedy templates are pink. szyslak 21:42, 3 October 2007 (UTC)

Pink is reserved for speedy deletions. I do feel the MfD template should have a grey background, but someone prefers to keep it green instead. — Edokter • Talk • 21:43, 3 October 2007 (UTC)

Oh, yeah, I knew that.. so why doesn't it match {{Afd}} and {{Rfd}}? I was also wondering about {{Delrev}} and {{Prod-nn}}. Do they need conversion? Rocket000 21:56, 3 October 2007 (UTC)

Yeah. So does {{PrSpam}}. Man, that green/red for Mfd, ick. I started a thread about it at Template talk:Mfd#Green background.--Father Goose 22:34, 3 October 2007 (UTC)

Isn't MfD totally outside this projects area? _→AzaToth 22:19, 3 October 2007 (UTC)

It's outside the declared scope, yes, but if there's no controversy over using amboxes elsewhere, I don't see why we shouldn't. I personally favor a standard look for all the deletion templates (AfD, MfD, CfD, RfD).--Father Goose 22:34, 3 October 2007 (UTC)

Or maybe I should have said "CfD, RfD, AfD, MfD". That way it spells CRAM. What the hell is he talking about?--Father Goose 22:38, 3 October 2007 (UTC)

I would support a standard look for all the deletion templates too.

As I've said before, I think they need to stand out more from the wall-o'-cleanup. Background shading is one way, and complete border rather than just left side border is another (For example, see Template:Ifd). They should also be at the top of an article (though below a "protected" template"), and probably have a "line space" between them and the "wall". For the shading, how about the "blue" of the Wikipedia space background when used on "white" pages (such as article space), and white when used on blue pages (such as category space).

(And is thinking that we should abbreviate XfD to CRAMfD in Father Goose's honour : ) - jc37 23:07, 3 October 2007 (UTC)

Don't forget about {{TfD}} and {{IfD}}! CRAMITfD?

Speaking of having a standard look - there's also {{AfDM}}, {{smartafd}}, {{afdx}}, {{dated ifd}}, {{afd new}}, {{afd-mergeto}}, and {{catfd}} to consider. Personally, I think all of these should follow the style specific to the namespace where it's used. - Rocket000 08:01, 4 October 2007 (UTC)

All AfD derivatives link back to AfDm, which is the AfD meta template. All AfD template using AfDm are automatically 'amboxed'. But maybe we should start thinking about a standardization project for all deletion related templates... dembox, Deletion Message Boxes! — Edokter • Talk • 17:21, 5 October 2007 (UTC)

How about we handle the project message boxes instead?

This page documents an official policy on the English Wikipedia. It has wide acceptance among editors and is considered a standard that all users should follow. When editing this page, please ensure that your revision reflects consensus. When in doubt, discuss first on the talk page.

FunPika 23:29, 5 October 2007 (UTC)

No rush... — Edokter • Talk • 11:35, 6 October 2007 (UTC)

I have started Wikipedia:Deletion message boxes as a continuation of this project. Everyone is welcome to discuss. — Edokter • Talk • 11:35, 6 October 2007 (UTC)

You should leave the standardization of the deletion templates up to their namespace's standardization projects when they are made. And why did you immediately put DMB into the manual of style?

FunPika 12:28, 6 October 2007 (UTC)

That was a mistake (just copied it from here). But why seperate it by namespace? — Edokter • Talk • 14:52, 6 October 2007 (UTC)

So that they can match their namespace's standardization (I might create the proposal for the project space standardization later today). When are you going to see an MFD template on an article with templates standardized into the Ambox format? FunPika 15:04, 6 October 2007 (UTC)

The only other standardisation projects are Talk: and Wikipedia: (project namespace, which is already standardised). Of course, they could do with an update... And what is wrong with cross-project standardisation? — Edokter • Talk • 15:13, 6 October 2007 (UTC)

• Why can't they just be regularized to Ambox? Titoxd^{(?!? - cool stuff)} 06:51, 7 October 2007 (UTC)

  They can be, the issue is a question of being able to easily notice them outside the wall-o-cleanup. And I think giving them a different background shading, and a full border and at least linespace between them and the wall, would work. They should be at the top of the page (but a linespace below protection - which also should have a full border). As far as I can tell, all of this is possible with ambox. - jc37 06:57, 7 October 2007 (UTC)

• The mfd template is being discussed at Template talk:Mfd (where it should be discussed!) — xaosflux ^Talk 14:34, 7 October 2007 (UTC)

Two templates that appear in the middle of the article yet to be amboxed. Since these 2 messages appear not in bottom i would support converting them to ambox. But standard size ambox would be too big, one line text message would be ideal. Two template talks are: Template_talk:Expand_list#proposal and Template_talk:Sectstub#ambox. Proposed versions are:

This list is incomplete; you can help by expanding it

and

This short section requires expansion.

You can see current version. I think text message should be left unaltered. Thanks. Lara_bran 04:43, 2 October 2007 (UTC)

Well, the expand section one I think of as a "section stub", and stubs aren't amboxed. If you do make that one an ambox, though, I would make it the same width as the trivia one. As for the list one, that goes on like every list, and a lot of the times those lists will never be complete. I would rather have more subtle message like we have now. Rocket000 05:19, 2 October 2007 (UTC)

Agree "stubs aren't amboxed". But this is not exactly one of the 100s of stub templates that appear at bottom of the article. These appear in the middle of the article, to distinguish it from the article text, a box is necessary. These(above) would be the subtlest possible solution, but the messages MUST be distinguished from the article text by a box. Thanks. Lara_bran 05:25, 2 October 2007 (UTC)

Let me explain. These two templates are not specific to the articles, like {{main}}, {{see also}}, which need article specific arguments. These are the messages that appear in the middle of the article, and maintenance messages. This can not be considered as "article content", while main, see also, or dablinks are related to the article content. Since these are just messages, to distinguish it from the article content / article text, these should be boxed. To keep these least intrusive i suggest to keep the text message same as earlier. Thanks. Lara_bran 16:06, 3 October 2007 (UTC)

I understand what you mean, but there doesn't seem to be any consensus over the expansion templates. We have {{sectstub}} (stub-style) and {{expand-section}} (ambox-style), because people can't agree which to use. In addition we have {{expand}} (ambox-style) which could be used for either sections or articles. So you can have your pick. I still would prefer keeping {{listdev}} the way it is, to match {{dynamic list}} and {{complete}}. Rocket000 06:54, 4 October 2007 (UTC)

OK, so these are not just 2 templates. But my point had been that which are not related to article content should be boxed. I have brought to community notice, bid bye now. Thanks. Lara_bran 08:06, 4 October 2007 (UTC)

Style and content templates are not really very important to someone who is just using the encyclopedia as a reference, yet with colour and icon they tend to stand out even more than the text they are moaning about. They get in the way of reading the articles. Unlike the other varieties they tend to be scattered through an article. There are those who say they should be removed altogether - rather I think they should merely be made much less noticable. Such pages tend to be categorized so there's no real issue of losing the information conveyed. Color and icons and graphics should be used mainly for enhancing the article content, not the editorial annotations. Quirkie 20:20, 2 October 2007 (UTC)

See my reply at the Village pump thread: Wikipedia:Village pump (proposals)#Quieter cleanup style templates. --Quiddity 07:23, 4 October 2007 (UTC)

Does anyone have thoughts on placing a date on Article message boxes? Some templates have them others don't. Jeepday (talk) 03:12, 3 October 2007 (UTC)

I don't think all of them need it, but all the clean-up and content ones (orange and yellow) should have a "date=" parameter. What would be even better, is if the templates added the date automatically without needing to enter it manually (or even with a bot). Rocket000 08:06, 4 October 2007 (UTC)

Only the massively backlogged categories tend to need date-separation into smaller subcats. E.g. there are only 58 articles tagged with {{histinfo}}, but there are 13,000 articles tagged with {{wikify}}, hence only the latter needs subcategorizing by date.

We (try to) only add complexity when it becomes beneficial ;) --Quiddity 17:00, 5 October 2007 (UTC)

True, but we don't need to categorize them (unless they need it) just because they have a date. Rocket000 20:30, 5 October 2007 (UTC)

I found this sight from the notices link on the Community bulletin board. So this is where all the changes have been happening. You are doing a great job. Keep up the good work. -- Jreferee t/c 07:25, 5 October 2007 (UTC)

There was a discussion on making the style templates less conspicuous which was archived recently. Wikipedia_talk:Template_standardisation/Archive_1#Eliminate_style_templates.21

The discussion was archived because it is a "perennial" however I believe if you read the discussion you will see there was a consensus for change and a number of different alternatives were proposed.

• provide a hide / show option with the templates condensed to one line by default.
• where a page has multiple style templates combine these in one summary template with a show button to see the details.
• move style templates to the bottom of the page
• replace style templates by categories so pages needing work can be tracked inconspicuously.
• Move style templates to talk pages
• Make style templates more like stub templates

I'm not sure which of these is worth further attention. Any thoughts?

Maybe this is not the place to discuss this. If so can you point me to the relevant page.Filceolaire 21:46, 8 October 2007 (UTC)

I agree, but I'd like to generalize: too many, too visible tags (not only "style", but all the amboxes), are dangerously approaching certain limits established by WP:NOT#HOWTO. And WP:NOT isn't an optional guideline, it is a policy, set by wise men and women to point wikipedia in some direction. In a direction at some point in time perceived as right.

What I would really like to see is a formal guideline how to use these zillions of amboxes, on what conditions add them to an article (easy part), and when to remove from an article (hard part). A guideline based—of course—on the spirit of Wikipedia's policy, a guideline well-balanced between using amboxes to "inform reader how to help Wikipedia" and "decrease background noise, focus reader on the topic". Many forget about the latter, and have to be reminded. --Kubanczyk 11:34, 10 October 2007 (UTC)

There's a longish thread about this on the mailing list currently. The 3 point summary: the cleanup templates help convert readers into editors, they help alert readers that an article is known to have problems, and they help inform readers as to how Wikipedia works. Because of those, there is no chance of consensus for moving the templates to the talkpage or the bottom of the page or into categories. Wikipedia is a work-in-progress - we shouldn't be ashamed of that, and we need help improving it.

For specific problem templates (eg WP:NDA violaters such as {{HurricaneWarning}}, as mentioned in the mailing list) take them to TFD (after attempting discussion at their talkpages).

For combining multiple templates into one, see {{articleissues}}.

Altering the style of the current templates is possible, and this is the page to discuss it at, but creating a draft example of your improvement ideas is the only real way to get a discussion going, as a large number of editors like (or are getting used to) the current style.

Changing the icons was suggested here and here. I'd love to see some more subdued/professional icon choices, we're just waiting for someone to design them... --Quiddity 17:58, 10 October 2007 (UTC)

Well, I'll try to create a draft of guideline, despite my poor English. Would you kindly inform me, is this process current? And which namespace is appropriate—userland or Wikipedia:? --Kubanczyk 22:41, 10 October 2007 (UTC)

Yes, that is current. Draft wherever you like (just tag it with {{proposed}}). You could also try discussing it beforehand, at Wikipedia:Village pump (policy), to get ideas and judge potential consensus. --Quiddity 05:32, 11 October 2007 (UTC)

After re-thinking, the ambox guideline would be nothing but instruction creep. Any template, including ambox, in fact generates a normal content of an article, a content that is subject to existing policies. Slight adjustment of those will be sufficient if people start adding too much amboxes. And I don't think we are there yet. --Kubanczyk 17:49, 26 October 2007 (UTC)

I uploaded a new image, Image:Verify-icon.png for use on cleanup templates.

This is one example:

I like the new ambox style, it's excellent!! --Solumeiras ^talk 16:31, 12 October 2007 (UTC) --Solumeiras ^talk 16:33, 12 October 2007 (UTC)

• A question - should we use the red-coloured ambox one a bit more for some templates, like we do on AfDs?? --Solumeiras ^talk 16:32, 12 October 2007 (UTC)

• I think that there's a general consensus that the red-border ambox should be exclusive to deletion-related issues, content issues are orange, cleanup is yellow, and expansion tags, notices (e.g. current event), and general templates are blue. This is a standardization issue, after all. :) Nihiltres^(t.l) 21:13, 12 October 2007 (UTC)

• Very true, Nihiltres... but what I'm suggesting is we add a third colour, maybe green (like my username is in my signature above!) - and this one could be used for some other use - any ideas for this one?? --Solumeiras ^talk 21:54, 12 October 2007 (UTC)

Oh no, not the green again. lol. Rocket000 22:08, 12 October 2007 (UTC)

You'd better put green back in this color code, or I am not going to lift my personal ban on that code. If you don't know what I'm talking about, just look at my monobook.css page. --  Denelson83  11:19, 14 November 2007 (UTC)

Default icon size is 40px. Do you have an SVG version? — Edokter • Talk • 21:56, 14 October 2007 (UTC)

For those of you interested, a similar standardization project is starting up for category message boxes. Your input would be greatly appreciated at Wikipedia:Category message boxes. Cheers, Rocket000 06:29, 13 October 2007 (UTC)

Template:Backlog hasn't been unified. -Halo 21:15, 14 October 2007 (UTC)

That is not an article message. — Edokter • Talk • 21:54, 14 October 2007 (UTC)

Yes, but what about all the {{protected}} and the like? Not all of them have been standardized yet... ~user:orngjce223 how am I typing? 01:52, 15 October 2007 (UTC)

{{Protected}} is used in article space (as well as all others). As far as I can tell, {{backlog}} only goes in the Wikipedia: namespace. But there are discussions to standardize other namespaces underway right now.--Father Goose 03:15, 15 October 2007 (UTC)

{{backlog}} is used in the category namespace too. But I agree that it shouldn't be ambox'd Rocket000 03:29, 15 October 2007 (UTC)

another: {{PB-familiar}}. — pd_THOR ^{| =/\=} | 17:56, 2 November 2007 (UTC)

That one would be better off just being deleted. Rocket000 23:55, 2 November 2007 (UTC)

I've nominated it for deletion. szyslak 09:36, 4 November 2007 (UTC)

There is discussion of adding an icon for the template unreferenced: Template_talk:Unreferenced#Icon_in_the_template. I gather that it's been discussed regularly in the past, and in different locations. I'd suggest discussing it there, or post there why you don't think it should be discussed there. :-) -Agyle 03:06, 15 October 2007 (UTC)

{{Essay}}, used in the Wikipedia: namespace, is another good candidate for standardization. -- The Anome 12:39, 17 October 2007 (UTC)

That already conforms to the standard as used in the rest of the templates listed at Wikipedia:Template messages/Wikipedia namespace. --Quiddity 18:26, 17 October 2007 (UTC)

(edit conflict) That's the Wikipedia namespace. Unless my eyes deceive me, the title of this page is "Article message boxes". Nihiltres^(t.l) 18:27, 17 October 2007 (UTC)

I want to suggest that some of the major maintenance templates (particularly those dealings with notability and core verifiability issues) should be modified to support project-specific variants. i.e. that the notional WikiProject foobar should have an easy way of creating a foobar-specific variant of these templates, which would allow articles to be categorised in a project category.

The example I have experimented with so far is {{unreferenced}}. I first created {{unreferenced/sandbox}} to provide hooks for the extensions (it's intended as a rough draft of a replacement for {{unreferenced}}), and from that the project specific {{foobar-unreferenced}}. As you can see from the example, {{foobar-unreferenced}} is the same as bog-standard {{unreferenced}}, with the addition of the project's own cleanup category and (crudely implemented) text identifying the project. (Note that the project's own cleanup category is in addition to the standard categories, not a replacement).

Before you rush to respond, lemme explain the reasoning. It arises out of discussions I have been having with the good folk at WikiProject Middle-earth (of which I am not a member). We got off to a bad start when some project members felt upset by my addition of tags such as {{unreferenced}} to a lot of middle-earth articles after I stumbled on a cluster of articles, some of which were one or more of ureferenced, missing evidence of notability, using only primary sources ... and then found many more.

After a lot of discussion (most recently with Carcharoth at User talk:BrownHairedGirl#Tagging_-_how_to_keep_track), I think we now broadly in agreement that these tags are useful as a way of encouraging editors to improve articles, but that they have two shortcomings for any WikiProject:

• they are good at telling editors what needs to be fixed, but poor at pointing editors towards help in how to do those fixes (e.g. "where should I look for sources?")
• a project which wants to improve the quality of its articles has no ready means of identifying which of the articles within its scope have a major deficiency such as being unreferenced

One solution is to create a project-specific template, but so far that has been possible only by forking the content (as with {{LawUnref}}), which seems to me to thoroughly undesirable, both because changes to the general template will not cascade to the specific ones and because projects might be tempted to dilute or alter the message of the templates.

So I thought that the best solution would be to create a simple, standardised way of extending these templates, rather than forking them. That way, the projects could have their own additional category to track problems in articles without removing the articles from the general cleanup categories, changes in the general template would cascade (maintaining standardisation), and the template could include some project-specific text.

There are a few issues to consider:

1. how would the tags be applied? Two ways I can see: foobar project members tag the articles using the {{foobar-unreferenced}}, and the the project's categories are periodically scanned (using AWB or a bot) to replace a generic {{unreferenced}} tag with {{foobar-unreferenced}}.
2. some articles fall within the scope of more than one WikiProjects and there may be a risk of competition. I don't think that's too serious a problem, because these templates will be removed when the problem is fixed, and no wikiproject gets less information than before because another project has used "it's tag".
3. How much scope should there be for extra text? My initial thought was to allow a free text field in the template, but I'm inclined to think that this could lead to bloat, and that a simple link to the project would be better

I know that this could be seen as instruction creep, excessive complexity etc, and all those concerns have some validity ... but to my mind the important point is to improve the tools available to wikiprojects which are working to improve articles. The general categories of unreferenced articles are too diffuse to be much use for an editor with knowledge and sources in a particular field.

Any thoughts? --BrownHairedGirl (talk) • (contribs) 04:04, 7 November 2007 (UTC)

Sounds like this should ideally be handled via software changes: some way to search on intersections of categories. Long-term, this should definitely be added to MediaWiki, instead of forcing atypical intersections to be handled via subcategories of unrelated categories.

Shy of that, wouldn't it be best to just browse through the articles in a particular subject area (or WikiProject) and see which ones have cleanup tags? (It's a rare article that doesn't need work of some sort anyway.)--Father Goose 08:27, 7 November 2007 (UTC)

You said it: "instruction creep, excessive complexity etc", and I agree. You have a limited supply of good editors, with a limited brain power. This change will undoubtedly distract a number of them, only to focus on creating, maintaining, fighting over a number of per-wikiproject Giant ToDo Lists (GTDLs). The problem with GTDLs is that they depress people: they are by design (!) impossible to complete. Do they increase productivity? Not at all. Editors become productive when they identify and when they are involved. While it is easy to become involved with a normal article, it is pretty hard with a freakin never-ending uncontrollable List.

There is already a one ultra-huge "unreferenced" list/category, that is, as you say, pretty much unusable. The pattern does not work, so I would say: leave it, don't spread, don't replicate, don't mention.

And the most major flaw: WikiProjects were, are, and should be referenced only on talk pages. There's a reason for that - wikipedia policies and guidelines. The self-referencing "online community" content does not fit into an encyclopedia.

--Kubanczyk 10:07, 7 November 2007 (UTC)

Some further points. Splitting up large categories like "Unreferenced" is not a new thing. The category is already split up by month. Splitting it by topics is a logical step, and will help people find areas to work on. This may work best for medium-sized WikiProjects, with several hundred to a thousand articles. Browsing that many to find ones with a cleanup tag on them is not something most people will chose to do. Kubanczyk's point about fighting over and maintaining lists is strange, because these are categories, not lists, and don't need separate maintaining. All the work is done at the article level. Kubanczyk's point about self-references is a good one, but in fact this can be addressed by avoiding explicit reference to the WikiProject, and referring to the topic area instead. eg. {{LawUnref}} says: "This law-related article does not cite its references or sources. You can help Wikipedia by including appropriate citations, which can be found through legal research." - no reference to the WikiProject there Category:Law-related articles lacking sources would be the place to refer to the relevant WikiProjects. Finally, this kind of system is already in operation for the {{fact}} template. See {{fix}}, and look at Wikipedia:WikiProject Inline Templates. The purpose of the 'fix' template is described as follows: "Most inline notices use virtually identical formats. This template is designed to provide a single standardized format which can accommodate the different text, links, and categories of individual templates." - the same philosophy should apply to article message boxes. I am going to leave a message at Wikipedia talk:WikiProject Inline Templates to see if they can help. Carcharoth 11:21, 7 November 2007 (UTC)

I think the 'fix' template system (to make the formatting uniform) arose from this TfD debate: Wikipedia:Templates for deletion/Log/2007 June 5#Misc. In-universe templates, which may be of interest. Carcharoth 11:44, 7 November 2007 (UTC)

Since the current {{unreferenced}} template generates a second category when a date parameter is added (for example, Category: Articles lacking sources from June 2007) why not have a set of parameters wikiproject1= , wikiproject2=, wikiproject3=, that a bot can add to the unreferenced template by using the info on the talk page? The parameters could generate additional categories, such as Category:Articles lacking sources that are within the scope of WikiProject Middle Earth (or whatever). I can't see anyone objecting to another category appearing at the bottom of a page.

This approach also has the advantage of not needing to maintain or protect hundreds of Wikiproject templates, and it avoids, it seems to me, the WP:OWN issue of who "owns" a template when, say, a WikiProject goes inactive.

As for poor at pointing editors towards help in how to do those fixes, why don't we change the "improve this article" link in the template, which links back to the page itself (why?), to link to WP:WRE or (ahem) WP:EIW-Resource instead? (The latter page is scheduled to be moved to Wikipedia namespace late this month or in early December) -- John Broughton (♫♫) 14:00, 7 November 2007 (UTC)

I like John Broughton's idea of wikiproject1= , wikiproject2=, etc. It avoids the ownership issues and removes any need to maintain multiple variants of each template, and allows as many projects as are interested to benefit from the tag's identification of articles needing particular types of improvement. --BrownHairedGirl (talk) • (contribs) 14:50, 7 November 2007 (UTC)

Carcharoth, I think you are right about most facts you provide. But I fail to see any arguments against the main points I made. You say "Splitting it by topics is a logical step", and I agree, "...and will help people find areas to work on", and I disagree here. I would say: splitting it by topics is a logical step, that will absorb a certain part of editors' energy, require—yes—"work on article level", and provide insufficient benefits in return. This is also my opinion about {{LawUnref}}, of course.

Note, that the same thing would be achieved right now at the spot by a simple script that takes two sets and outputs intersection of these sets. If you feed it with "Category:Articles lacking sources" and "Category:Characters in The Silmarillion", you would instantly get the desired result—unreferenced pages that you happen to be interested with. With zero collateral damage, with zero manual tagging. --Kubanczyk 14:59, 7 November 2007 (UTC)

Of course. The same thing could be done with many other categories, yet we have Category:World War II French infantry weapons instead of telling people to write a script and intersect Category:World War II, Category:Weapons and Category:France. Do you see anyone rushing to create such a script? I don't have the skills to write such an intersection script. Would you be prepared to do this? Carcharoth 18:23, 7 November 2007 (UTC)

I think it verges on complicated. It would be simple to do it by running a query directly on a copy of the database. If you want to work fromm the live dataset, there is a MediaWiki API that allows fetching category members in raw form, but I believe it doesn't fetch subcategory members (such as "Unreferenced from date"), so you might have to extract the data from a non-machine formatted category page and have the script perform recursion itself.--Father Goose 20:07, 7 November 2007 (UTC)

If it were only a matter of how to do category intersections, I would have pointed to m:User:Duesentrieb/CatScan, which solves that problem, rather than suggesting parameters that can be populated by bots. But category intersection isn't a solution when the intersection is between a category on an article talk page (that would be the wikiproject) and a category on the article page itself (that would be a cleanup category). And sure, you can do just about anything you want with a database query; of course, we're looking for tools that any editor can use, not someone with SQL skills and a terrabyte of storage on a server with a high-speed connection (I exaggerate for effect). (And yes, if there were always a one-to-one relationship between wikiprojects listed on an article talk page and categories on an article page, then of course this would be moot, but that isn't the case.) -- John Broughton (♫♫) 21:26, 7 November 2007 (UTC)

Ohhh, nice. *bookmarks*--Father Goose 02:22, 8 November 2007 (UTC)

Carcharoth, I won't continue the discussion. I'm seeing ignoratio elenchi (or maybe red herring) for a second time now... EOT. --Kubanczyk 23:20, 7 November 2007 (UTC)

Well, the only way we are going to get past our misunderstandings and have a chance of understanding each other is if we continue discussing this. If you ever chose to reconsider, I'm happy to carry on discussing this, maybe going a bit slower in the hope of avoiding such misunderstandings. For what it is worth, I was aware of category intersections before this discussion, hence my slight irritation that people tried to brush this off with a "use category intersection" answer, but I was not the first person to bring up category intersections in this discussion. As for the "insufficient benefits in return" bit, I think we will have to disagree on that - you seem to be arguing against the basic idea of using tags such as {{unreferenced}}. I hope this more directly addresses what you were saying, and I hope you can accept that any previous wandering off-topic by me was just that, and not an obscure Latin phrase or red herring. Carcharoth 01:15, 8 November 2007 (UTC)

Template:Ambox has already done for message boxes exactly what Template:Fix does for inline notices. Indeed, the 'Fix' template was originally a wrapper for 'Fix-inline' and 'Fix-box' templates, but I scrapped the 'box' version when the Ambox project came along with an organized group doing the same thing. How to handle 'intersections' between Wikiprojects and various message boxes (and inline notices) is really a separate issue - though some of the same methodology can be applied. In addition to the options discussed above, these intersections could also be tracked through 'what links here' if links to blank (or non-existant) pages were added. That'd basically work the same way as having additional categories for each intersection, but be effectively 'invisible' to the general user... there wouldn't be additional categories listed on the page or in the tree, you'd have to go to a special link to see the list of pages in that category which are also associated with the Wikiproject. Including those links on the category page might be a good way of allowing people to view different 'subsets' of the category. Any special instructions on how to handle the general issue (e.g. 'Cleanup') in relation to the individual Wikiproject could go on the linked page itself inside 'noinclude' tags. --CBD 13:35, 10 December 2007 (UTC)

I think tint without border looks hip.

Current gray border with gray tint looks bad, and to distinguish infobox and bordered images from amb's, colored tint would be better than gray. Other-being-sep (talk) 06:46, 30 November 2007 (UTC)

The standard objection is that some people (especially those with impaired color vision) find colored backgrounds extremely hard to read. Check the archives of this talk page. —DragonHawk (talk|hist) 13:39, 10 December 2007 (UTC)

Another thing, I have a PC and a Mac, and you cannot see the tint at all on the mac.-- Penubag  00:37, 11 December 2007 (UTC)

I just happened to look at the French wiki and found that they have implemented a very similar template system to ours. violet/riga (t) 01:07, 20 January 2008 (UTC)

What is Rainbowflage? It is a color pattern that projects positive frequency's from earth to the universe. Camouflage is Tactical and deceptive. Rainbowflage symbolizes:Truth,courage,and love. Created By:Artist Blake 2002, on the Big island of Hawaii. —Preceding unsigned comment added by 71.146.100.221 (talk) 09:14, 27 January 2008 (UTC)

...and now for something completely different: my signature utilising two different shades of green. -- Reaper X 21:53, 27 January 2008 (UTC)

What? MilesAgain (talk) 21:39, 1 February 2008 (UTC)

  Resolved

This term is used (with the quotes, yet) in the main article's See also section, but isn't defined there or in the link that supposedly explains it. Can someone add an explanation somewhere - or better yet, skip the cutesy jargon and say what you mean? 68.238.239.34 (talk) 16:16, 1 February 2008 (UTC)

I added a note at WP:TPT. Thanks for pointing this out. —Ms2ger (talk) 21:16, 1 February 2008 (UTC)

ClockworkSoul's Coffee Roll is the name of the theme that won the big vote for talk page standard templates, back in '05 I think it was. MilesAgain (talk) 21:35, 1 February 2008 (UTC)

Ahh... The good old days...

In any case, I suppose these are the only templates allowed in talk pages, no? Because sometimes people move article messages boxes to the talk page, I suppose because they don't want to have to see it in the article. Which is absurd, because that template attracts more contributors who could solve the problem, and is an extra motive to those who don't like seeing it. "Tags are evil", sure, but moving them to the talk page only makes them stick around longer, and in the wrong place. Waltham, The Duke of 01:17, 15 March 2008 (UTC)

See Template:Bio-context. It's not widely used, so it must have simply been overlooked when the templates were being upgraded, but it should be standardised to appear the same as the rest. Terraxos (talk) 17:21, 1 February 2008 (UTC)

  Resolved

--TheDJ (talk • contribs) 18:43, 1 February 2008 (UTC)

Template:Alphabetize -- penubag  02:39, 2 February 2008 (UTC)

  Resolved

szyslak 03:14, 2 February 2008 (UTC)

Is it possible to have the templates institute a buffer underneath the bottom, only providing there are no {{ambox}} templates below it? This may be impossible, and while I really and supported the new standardization, I just get annoyed by the look of article message boxes abutting the tops of infoboxes. — pd_THOR ^{| =/\=} | 19:07, 24 February 2008 (UTC)

I agree. Alternatively, adding a 2-4 pixel margin-top for all infoboxes. Adding .infobox {margin-top:4px;} to my monobook.css temporarily solves the abutment issue. -- Quiddity (talk) 19:54, 24 February 2008 (UTC)

It could be done using javascript, as it involves changing a CSS property of the bottom box. — Edokter • Talk • 21:05, 24 February 2008 (UTC)

I'm going to request that margin-top:5em be added to the infobox class in mediawiki:common.css. It cramps things like disambig hatnotes as well.--Father Goose (talk) 00:39, 25 February 2008 (UTC)

Awesome, let us know how it goes. — pd_THOR ^{| =/\=} | 01:43, 25 February 2008 (UTC)

Done already. Clear caches :) -- Quiddity (talk) 02:27, 25 February 2008 (UTC)

Is there any particular reason you can't create a custom ambox with the "protection" gray sidebar? We've got options for all the other types, including the red deletion, but trying to enter "type=protection" or "type=ambox-protection" just gets the default blue. Is the gray specifically and exclusively reserved for protection, or did someone just forget to add that in the code? Hersfold ^(t/a/c) 00:04, 15 March 2008 (UTC)

It's not in the ambox code, because protection templates adopted the style later then the rest. And since the protection templates are rather complex (see {{pp-meta}}), they don't actually use {{ambox}}, only the styling in common.css to mimic ambox. However, I don't see why we can't hack the extra color and image into ambox to allow for custom protection boxes. — Edokter • Talk • 00:25, 15 March 2008 (UTC)

Since I'm now able to edit the template, does anyone mind if I do so? From what I can tell, it will only involve adding a single line of code:

  | protection = ambox-protection

Which should pull that gray sidebar from the Common.css file. Most of the extra code in {{pp-meta}}, from what I can tell, is name-space detecting stuff to match the style used for each namespace - basically a hardcoded version of what David mentions in the section below. Hersfold ^(t/a/c) 21:49, 19 March 2008 (UTC)

Well, since I am the one who started out the {{ambox}} template I should perhaps respond to this. (Note, I didn't come up with the excellent colours and design etc, I just created the meta-template and named it "ambox". Then others made the template even better.)

Hersfold: The code line you show above is correct. But you also should add a default image for "protection" further down in the code. So what colour for the padlock should you choose as the default?

And now for my list of reasons why you should add the "protection" type to ambox:

1. Completeness. All the other article message box styles are there now.
2. Make it easier to make custom protection boxes. (Not really true, see next list.)

Reasons why not to add the "protection" type to ambox:

1. We already have the {{pp-meta}} for that. If you need a custom protection box use {{pp-meta}}, that's what it is for. And then you automatically get all the details right, like the proper position of the small padlock etc.
2. Ambox has already caused several server crashes since updates of ambox causes too many pages to re-render. It is unwise to add even more load on the same template. Infact, we should seriously consider splitting up ambox to one meta-template for each type of article message box. (One for each colour of the left bar.) Like {{ambox notice}}, {{ambox style}} and so on. Thus we can spread updates of those boxes over time so not to overload the servers. And don't hit me with "we should not worry about performance", because when a template is used on 300,000+ pages then we do need to worry about performance.

So I think we should not add the "protection" style to ambox, sorry. (I would have liked to have it all in the same template, I like advanced automagic meta-templates.)

--David Göthberg (talk) 22:38, 19 March 2008 (UTC)

But if it is ultimately decided that another change to ambox is Definitely A Good Idea (I express no opinion either way), read Template talk:Ambox#Standing request first.--Father Goose (talk) 04:49, 20 March 2008 (UTC)

1: Thanks for the reminder about that update Father Goose.

2: I have been thinking a bit more. Hersfold is kind of right. We could have good use for a "ambox with protection style", since the current {{pp-meta}} does not have all the extra tricks that people here added during the autumn. I mean the tricks that makes it flow nicely left of infoboxes and images etc. But instead of putting it into the {{ambox}} itself I suggest we make it a well coded {{ambox protection}}. Then {{pp-meta}} can call that one. Since as Hersfold correctly noted {{pp-meta}} is primarily for detecting namespaces and handle other things, thus it is better to have the actual ambox-protection code in a separate template. And the neat part is that we could use the {{ambox protection}} as a prototype if/when we decide to split out the other colour types to separate amboxes. What do you guys think?

3: Should we name it {{ambox protection}} or {{ambox-protection}} like the CSS classes?

--David Göthberg (talk) 07:25, 20 March 2008 (UTC)

I go for "ambox protection" instead of "ambox-protection". Look at {{subcat guideline}}, for instance. And I think your idea of trying it out as a prototype is sound.--Father Goose (talk) 09:12, 20 March 2008 (UTC)

I agree with the idea of splitting out the templates, and I prefer "ambox protection" as well. Where performance can be improved, it should be done, and staggering changes between categories of ambox templates can reduce the load of such modifications to the servers. Waltham, The Duke of 17:31, 20 March 2008 (UTC)

I very much disagree with splitting the templates, as I regard {{ambox}} as probably the second-best individual page on Wikipedia (the best being {{!}}!). I don't think it's correct to say ambox is responsible for server crashes - certainly it causes a massive spike in the job queue whenever it's edited, but the MediaWiki software can usually handle it. I think it's had a bad name because it got associated with the commons bug which corrupted most of the image thumbnails right at the time we were implementing it, but in fact the two issues were (IIRC) unrelated. Certainly don't hesitate to make an edit if you think it's necessary - and I would consider this change necessary - it's big, but it's not that big (it's not even in the top ten!). Creating new templates just to avoid editing existing ones completely defeats the object of us creating metatemplates in the first place. {{pp-meta}} should (once this edit is made) be reconfigured to use ambox to take advantage of the fixes you mention above. Happy‑melon 23:09, 23 March 2008 (UTC)

I agree, there is no reason to split up this template, and stories of servers crashing are highly exsaggerated. It makes matters only more complex. I also agree that {{pp-meta}} could easily be adapted to use ambox instead of a hard-coded box. — Edokter • Talk • 23:57, 23 March 2008 (UTC)

From the (in)famous creator of the {{ambox}}, here comes a new meta-template:

I have coded up a solution for the message boxes that are used on several types of pages. Take a look at the {{main talk other}} template. It helps other templates detect what type of page they are on, so they can change appearance. And I think I have managed to make it really easy to use.

If you also need to detect category pages then there is a template for that too: {{main talk category other}}.

Disclaimer: The first sentence above is a joke. The ambox was very much a teamwork and a lot of people worked hard in this project.

--David Göthberg (talk) 03:30, 19 March 2008 (UTC)

I've changed the example table to have cell explicitly showing the colour. The reason was that the table row style="border-left: 10px solid #f28500;" code wasn't working properly. (I run IE and windows XP, so I assume the same woudl apply to the majority of users). Tompw (talk) (review) 19:26, 31 March 2008 (UTC)

I tested with my old MS Internet Explorer 5.5. from 2001 that I use for compatibility testing. Seems you are right, IE only supports "border-left" for the whole table, not for table rows and not for table cells. So your solution is right. (The amboxes are not affected by this bug in IE, since they use "border-left" for the whole table.)

--David Göthberg (talk) 07:44, 1 April 2008 (UTC)

About the color coding: I noticed that the colors for normal deletion and speedy deletion are the same. Shouldn't the "normal deletion" color be a red hue for more distinguishment and so that it indicates less harshness in addition to the pink background of the speedy deletion templates? STYROFOAM1994^talkReview me! 01:13, 4 April 2008 (UTC)

What do you mean? The "normal deletion" boxes already have a red bar on the left side. Do you mean that it should have a different kind of red in the left side bar compared to the "speedy deletion" boxes? Or do you mean that the background colour of the "normal deletion" boxes should be slightly tinted in red? So its background end up somewhere between other boxes and the "speedy deletion" boxes?

--David Göthberg (talk) 01:40, 4 April 2008 (UTC)

I'm suggesting that the little red bar on the side should be a little lighter red than the speedy deletion side bars. So the side bar for "normal deletion" should be   instead of  . I'm not suggesting anything about the background color. STYROFOAM1994^talkReview me! 02:16, 4 April 2008 (UTC)

Ah, thanks for clarifying that. Now that I know what you mean I see that I don't have an opinion on the matter. I see good reasons both for having the same side bar colour for both kind of boxes (as it is now), and good reasons for having a differing colour (as you suggest). Let's see what the others think.

--David Göthberg (talk) 02:51, 4 April 2008 (UTC)

Apart from the matter of preference, which doesn't really matter, given that each editor has their own (personally, I don't like the tomato colour—I quite prefer dark hues), I believe that we ought to keep it simple: let's stick to the basic colours and leave variations out. And as far as semantics is concerned, I don't think there's any reason not to be "harsh"; sure, the deletion is not certain, but it is probable, and deletion is arguably the worst thing that could happen to an article. The red background for speedy deletions indicates urgency, but that for "slow" deletions is perfectly neutral, so there's enough differentiation between the two, and the ambox for proper deletions is "calm" enough. Waltham, The Duke of 04:44, 4 April 2008 (UTC)

Styrofoam, if you personally only want to see this change, add

table.ambox-serious {
border-left: 10px solid red ;
}

to your monobook.css and you'll see the changes -- penubag  (talk) 04:50, 4 April 2008 (UTC)

Uhm, no. This is about different borders for speedy and normal deletion boxes. They both have the ambox-serious class. —Ms2ger (talk) 11:22, 4 April 2008 (UTC)

Ms2ger is right. And that brings up the point that the speedy deletion templates really should have their own CSS class that sets the colour of the side bar and the background. So that users and other skins can skin it as they wish. I suggest such a class be called "ambox-speedy" and be added to MediaWiki:Common.css, and then when the 31 day CSS caching time have passed it be added to {{ambox}} etc.

--David Göthberg (talk) 11:44, 4 April 2008 (UTC)

We already have a different background for speedy deletion templates; the red bar only indicates it is a deletion-related message. My opinion is there shouldn't be any variations in the sidebar colors. — Edokter • Talk • 13:54, 4 April 2008 (UTC)

I think adding more colors is a bad idea (KISS). However, I see no objection to adding ambox-speedy as an additional class to the ambox HTML. class="ambox-serious ambox-speedy" would at least allow people to customize that background of speedy tags and set a different border color if they really want to. --TheDJ (talk • contribs) 14:22, 4 April 2008 (UTC)

I am adding this code to MediaWiki:Common.css:

table.ambox-speedy {
    border-left: 10px solid #b22222;     /* Red */
    background: #fee;                    /* Pink */
}

It is the exact colours listed for "speedy" at Wikipedia:Article message boxes#Categories and colours and used in {{db-meta}} since a long time now.

And 30 days later I am going to update {{ambox}} to support it natively. (MediaWiki:Common.css is unfortunately set to a 30 days web browser caching time.)

--David Göthberg (talk) 01:58, 19 April 2008 (UTC)

Cool. Don't forget to do this at the same time. ;-) --Father Goose (talk) 05:13, 19 April 2008 (UTC)

And to revisit a thread above, should we add "ambox-protection"? The initial discussion seemed to favor a move toward splitting apart the ambox subtypes, but subsequent replies went the other way.--Father Goose (talk) 05:16, 19 April 2008 (UTC)

Oh, silly me, you did both in the sandbox [1]. *slinks off*--Father Goose (talk) 05:25, 19 April 2008 (UTC)

I have made a new version of {{ambox}} in its sandbox {{ambox/sandbox}} and tested it on its testcases page. Please have a look, I will deploy this version within some days.

Based on discussions on this page and other pages I have made the following additions to {{ambox/sandbox}}:

1. Added the "protection" type, with a grey padlock as default image.
2. Added the "speedy" type. Uses the colours we use in speedy delete message boxes since a long time now.
3. Added the "delete" type. Same as "serious" but the "serious" name has caused lots of confusion so we added the extra name "ambox-delete" to the "ambox-serious" CSS class long ago. It is time to switch over to the new better name we decided on long ago. The old parameter "serious" also still works, so we are backwards compatible.
4. Added the "textstyle" parameter. That was the standing request from Father Goose.
5. All images now have an image width set. (Other editors had already fixed that in the sandbox, so I kept that.)

Nothing has been removed so existing message boxes based on {{ambox}} should look the same after the update.

Note: To see the "speedy" type properly you might need to refresh your web browser cache, since I added the "ambox-speedy" CSS class today. This is due to that MediaWiki:Common.css is set to be cached in web browsers for 30 days. Thus the "speedy" type will not be fully usable until 19 May.

The "ambox-protection" and "ambox-delete" CSS classes were added long ago and should look okay for everyone by now.

In other words, we can add all this new code to {{ambox}} now, but we may not use the parameter "speedy" to build our speedy delete message boxes until 19 May.

I will do the code update during low traffic hours, since {{ambox}} is used on 342,000 pages.

--David Göthberg (talk) 05:35, 19 April 2008 (UTC)

I have no objections. I do however think we should consider using class="ambox-delete ambox-speedy" instead of having a separate class="ambox-speedy" This ambox speedy class would then only set the background, with the border being inherited from ambox-delete. It is just a small semantic difference. --TheDJ (talk • contribs) 13:23, 19 April 2008 (UTC)

But that is how it's currently done. The point of a seperate class is to not have to added extra CSS in the template. — Edokter • Talk • 16:36, 19 April 2008 (UTC)

Could we add a {{{class}}} parameter? — Dispenser 16:26, 19 April 2008 (UTC)

Could you elaborate on the possible benefits in doing so? — Edokter • Talk • 16:36, 19 April 2008 (UTC)

I don't see a reason to add a class parameter when there's already a style parameter. Most people have no control over the classes, and are also not even aware of what classes exist, so I don't think it'd be very popular. As for style, however, you can fit anything you'd like in there, which makes it very flexible. Gary King (talk) 19:27, 19 April 2008 (UTC)

I can think of some reasons:

1: When making an article message box based on {{ambox}} you might want to add classes like "nowraplinks". It prevents links from line wrapping and that functionality can not be added as a style parameter, it has to be a class. Hehe, just noticed that {{ambox}} already has the class "plainlinks" that I was going to use as another example. Such usage is probably a good thing.

2: Or you might want to add the name of the message box as a class so you can skin that box separately, although that kind of defeats the purpose of standardising the article message boxes in the first place. Perhaps a reason to not have the "class" parameter?

3: I also think I have seen the use to tag several boxes with the same class so that bots can automatically know they belong to the same type. This is a very dubious reason, there are other ways to handle that.

--David Göthberg (talk) 20:04, 19 April 2008 (UTC)

Looks fine to me. Would this mean that "delete" will be changable to a new "look", presuming there is future consensus for it? (As I've said previously, I really think that deletion boxes should be a different shade than the rest of the "wall-o-cleanup".) - jc37 18:06, 19 April 2008 (UTC)

1: TheDJ: No, I would not like to make "ambox-speedy" dependant on "ambox-delete". That would add code complexity in a number of places and would thus be confusing to future handlers of these classes and templates. It is much easier and in a way more flexible to handle "speedy" as a separate type.

2: jc37: Well, "serious" and "delete" are just two names for the exact same type. When we started this project we used the name "serious" for the red deletion related message boxes. But it caused a lot of confusion since many editors thought that "serious" meant the orange "content" boxes. So we added the extra name "ambox-delete" to the "ambox-serious" CSS class, so that we can use that name when hand coding message boxes. I am now doing the same change in the {{ambox}} meta-template. That is, I am making "delete" the preferred name for red deletion related boxes, and deprecating the name "serious" for them. As has already been done long ago in the descriptions and examples at Wikipedia:Article message boxes.

3: jc37: It has always been possible to change the looks of the "delete/serious" type. Just that so far there has not been consensus for it. Although there have been lots of suggestions. Instead you might want to take a look at and perhaps use the ready made skins that are available for it!

--David Göthberg (talk) 19:38, 19 April 2008 (UTC)

Today David Levy did several changes to the {{ambox/sandbox}}, see diff.

1: I disagree with the new default images. They don't look as good as the old ones. (He copied the documentation there so if you scroll down you can see the new images in the "Default images" section.)

2: I disagree with the reordering of the types into alphabetical order. That is confusing and it splits up the cases where we have more than one name for a type.

3: I agree with adding the new name "move" for the old purple type "merge". I see that the name "move" has been used at Wikipedia:Article message boxes for some time now and it is a better name. We will of course also keep the old parameter "merge", so we will be backwards compatible. (Note: David Levy today added the extra name "ambox-move" for the "ambox-merge" class to MediaWiki:Common.css, so we can not use the new class name until 20 May due to the 30 day web browser caching of that CSS page. That is why he correctly pointed the new "move" type parameter to the old class "ambox-merge".)

I would like feedback from the rest of you on this.

--David Göthberg (talk) 11:52, 20 April 2008 (UTC)

Thanks for your feedback, David!

1. Can you please be more specific regarding the default images? The "notice" image is a native 40px version of the current icon (which presently has to be resized from 53px, thereby resulting in reduced sharpness). The "content" image is derived from the same source, so it's a perfect match (unlike the current icon, which clashes with the "notice" icon and has relatively poor anti-aliasing). The "delete" icon doesn't appear to be in use in any of the relevant templates (so which version it is doesn't matter very much), but it seems logical to designate something other than the image associated with user blocks (and a stop hand has little to do with deletion).

2. The alphabetical order seems more intuitive to me, but I don't care about this very much. —David Levy 12:18, 20 April 2008 (UTC)

The images here have been improved several times since this discussion was started. Thus what you see here now is not what we saw when we wrote these comments.

The notice image: Your new Image:Ambox notice.png   doesn't have the same colour as your old Image:Info non-talk.png   so it doesn't match the blue bar to the left in the amboxes. And it doesn't have a shadow like the old image, so it looks a bit flat and boring. And it currently has a grey background so it looks terrible in older browsers who do not understand transparent PNGs. The old one at least get a white background when MediaWiki rescales it, so it doesn't clash that much with the "Wikipedia menu box grey-white" that ambox uses. But yes, the new image renders sharper. But then Image:Info non-talk.svg   would be a better choice since it is sharp too, has about the right colour, a shadow and renders with a white background in the old browsers. But I know you were the one who made the 53px "Info non-talk.png" and "Info talk.png" in the first place to handle the background problem in the old browsers. So if you could fix those things again then a 40px image that would not have to rescale would be better yes.

The content image: Oh, I took a second look. You are right, your new Image:Ambox content.png   looks better than the old Image:Emblem-important.svg  . Could you fix it up with a shadow? And the right background colour for ambox so it looks good in the older browsers? Then it would be perfect.

The delete image: Well, I just think that your new image Image:Ambox deletion.png   doesn't look as good as the old Image:Stop hand nuvola.svg  . Its too dark, has no shine and no 3D feel. Regarding which symbol to use: Well, for me both a stop hand and an exclamation mark works for "deletion".

Sorry to pick your images apart like this. Oh, and I should perhaps mention that the old "SVG transparency in old Internet Explorers" bug is back. Whatever fix they applied here on the English Wikipedia last year seems to be undone. :(

--David Göthberg (talk) 16:17, 20 April 2008 (UTC)

Thanks again for your feedback!

I reverted my alphabetization. For the "notice" icon, I restored the original hue. I added shadows to that icon and the "content" icon. I replaced the "delete" icon with another from the Nuvola set.

The IE6 PNG-24 transparency fix is working on my end. Do you have JavaScript enabled?

You were seeing a gray background because that's what IE substitutes for PNG-24 transparency when no background attribute is specified. (When scaling PNGs or SVGs, MediaWiki automatically inserts a white background, but because these images are transcluded at their native size, MediaWiki isn't scaling or otherwise altering them.) I added a background attribute of #fbfbfb (which is used for the template's background), and I'll create custom versions of the other icons if this issue is widespread. —David Levy 01:20, 21 April 2008 (UTC)

Another thing I noticed is that the new ambox images don't have a shadow. — Edokter • Talk • 18:08, 20 April 2008 (UTC)

Fixed. —David Levy 01:20, 21 April 2008 (UTC)

Re the ambox-delete icon; I liked the concept of the exclamation mark in the stop sign, it just looked poor. If it had the same shading as the new content icon, it would look great. — Edokter • Talk • 11:28, 21 April 2008 (UTC)

I'm indifferent about the new "content" and "notice" icons; they're not different enough to stir me either way. But the new "serious" icon is flat and not anti-aliased. I also agree that it should be grouped by ambox type, not sorted alphabetically.

Also, any reason why you got rid of {{documentation}}? --Father Goose (talk) 19:49, 20 April 2008 (UTC)

I've replaced the "serious"/"delete" icon with another from the Nuvola set, and I've restored the original grouping.

I replaced the {{documentation}} transclusion only to display the sandbox's documentation instead. That change isn't intended to be carried over to the actual template. —David Levy 01:20, 21 April 2008 (UTC)

The triangle icon for "serious/delete" looks fine to me.--Father Goose (talk) 03:28, 21 April 2008 (UTC)

I think that the changes look great! Just one qualm, the new image for ambox-content is too red, it should be the orange matching the content ambox sidebar. I've made:  , what do you guys think? I personally think it is at least a hair more attractive. -- penubag  (talk) 10:34, 21 April 2008 (UTC)

It seems a bit too yellowish on my end, but your original upload looks good to me. —David Levy 19:29, 21 April 2008 (UTC)

David Levy:

Your the man! (Sorry that I was a bit cranky the other day, I am having the flu.) The Image:Ambox notice.png   now looks great in all my browsers. Looks sharp, has shadow and has correct background for ambox even in my really old Internet Explorer. But since Image:Ambox notice.png is slightly darker than Image:Info non-talk.png   then I think they are "just" equally good. So I now have no point of view on which one to use.

Your new content image is now perfect and looks right in my older browsers too: Image:Ambox content.png  . So your content image now is the best.

Did you mean that Wikipedia uses some javascript to fix the PNG background problem? I have javascript enabled in all my browsers. (My extra javascript based top page buttons are visible in the IE too so seems javascript is running.) Still I get grey background on any icon that you haven't fixed.

I think that your new delete image (shiny warning triangle with an exclamation mark) Image:Ambox deletion.png   is equally as good as Image:Stop hand nuvola.svg  . So I now have no point of view on which one to use.

And lets compare the content images from David Levy and Penubag:

Image:Ambox content_o.png from Penubag.

Image:Ambox content.png from David Levy.

I prefer the one from David Levy. Sorry Penubag, I think your one is too yellow. But note that I use a CRT screen so I see colours slightly differently than what most other people see nowadays with LCD screens. What do the rest of you guys think?

--David Göthberg (talk) 18:27, 21 April 2008 (UTC)

And I like Penubag better; it matches the bar perfectly. That is also the reason I like the top one of these two icons:

Commons:Information icon.svg blue matches bar better

Image:Info non-talk.png current 'chloride' version

— Edokter • Talk • 18:46, 21 April 2008 (UTC)

I agree with David that Penubag's current attempt leans too much toward yellow (and I'm using an LCD screen), but I like Penubag's original upload of the file.

Regarding the "notice" icon, neither shade is the same as that of the ambox bar (which I don't think would translate well), but the top one looks purplish to me. —David Levy 19:29, 21 April 2008 (UTC)

Great! I'm glad that I was able to make these improvements.

Regarding Image:Ambox notice.png, my second attempt's coloring is copied directly from Image:Info non-talk.svg, so it should match Image:Info non-talk.png fairly closely.

Yes, I believe that the IE6 PNG-24 transparency fix is JavaScript-based. Are you using IE6? (The fix is incompatible with IE5.) —David Levy 19:29, 21 April 2008 (UTC)

For compatibility testing I am using Internet Explorer 5.5 and Opera 9.02. IE 5.5 is the last version that runs on Win98 and non-English WinME versions as far as I know. And yes, there are still people out there using those OSs. Unfortunately I can not test with Safari since it is not available for my OS. But of course, normally I am using Firefox.

--David Göthberg (talk) 22:42, 21 April 2008 (UTC)

Okay, that's why the fix isn't working for you. Unfortunately (as I realize that Internet Explorer 5.5 remains in use), it's compatible only with version 6. —David Levy 00:51, 22 April 2008 (UTC)

I've reuploaded my original orange one, please see the image summary for a comparison. I still like my original the best (Image:Ambox content_o.png), but let's see how they fair out. As for the ambox-info image, I prefer Commons:Image:Information icon.svg as it matches the bar color. -- penubag  (talk) 04:33, 22 April 2008 (UTC)

Maybe you can redo Commons:Image:Information icon.svg for ambox as well , as it is slightly too small (to much whitespace around it). — Edokter • Talk • 11:25, 22 April 2008 (UTC)

Does it not appear purplish on your end? (I'm trying to understand how it's a better match with the blue ambox bar). —David Levy 11:34, 22 April 2008 (UTC)

Only slightly purplish... but the current one is too 'chloride'. maybe a color in between? — Edokter • Talk • 13:46, 22 April 2008 (UTC)

I like Penubag's "original upload" too, might be the best content colour so far: Image:Ambox content o1.png  

And yes, a colour in between for the notice icon might be a good compromise, since some seem to prefer the darker ones. But I prefer the lighter ones. If someone is willing to tinker with it. But please make it blue, not purplish then.

--David Göthberg (talk) 15:33, 22 April 2008 (UTC)

I'd be glad to work on a color for the information image. Just hang on one sec... -- penubag  (talk) 23:50, 22 April 2008 (UTC)

Image:Information icon2.svg - lighter

Image:Information icon1.svg - darker

Here it is. Suggestions for improvement welcome -- penubag  (talk) 02:03, 23 April 2008 (UTC)

I like the lighter one. I think it is the best one so far, better than any of the old ones. I recommend that we convert it to a PNG when it is ready (when we have consensus on the exact colour) and let David Levy work his background magic on it so it looks as good in all browsers. (I gotta install a more modern image editing program that can handle transparent PNGs some day. But hey, if others can do the job... :)

David Levy: By the way, just in case to save you some work: I do not know how you usually do it, but that SVG there looks good. What we really see there is a PNG rendered from the SVG by MediaWiki. I think you can simply take that PNG and fix its background, since then you automatically get the shadow, right? Or perhaps that is already how you usually do it?

--David Göthberg (talk) 07:14, 23 April 2008 (UTC)

Yes, I usually do it that way. In this instance, however, I wanted to ensure that the orange "content" icon (which has no SVG counterpart) would match to the pixel, so took a different approach; I converted the SVG to a large bitmap, derived the "content" icon from that, and reduced both images to the correct size. As Penubag's SVGs are identical other than the color, I can easily scale one in the same manner (and still have it match the "content" icon perfectly). —David Levy 07:51, 23 April 2008 (UTC)

Thank you! I actually already converted them to pngs before I made the svgs (or I should say originally png) see. Only the light one is not an exact replica of the svg version so it might be best to let David Levy work his magic, unless it's good enough. -- penubag  (talk) 07:54, 23 April 2008 (UTC)

Indeed, I do want the "notice" and "content" icons to match perfectly, which is quite easy to accomplish.  :-) —David Levy 07:59, 23 April 2008 (UTC)

Only easy for people with magic! -- penubag  (talk) 08:05, 23 April 2008 (UTC)

I love your new versions, Penubag! —David Levy 07:51, 23 April 2008 (UTC)

I like the darker one better; it matches the bar slighly better, but they both look fine. — Edokter • Talk • 12:15, 24 April 2008 (UTC)

Not trying to start any meaningless discussions, but personally I feel that   Image:Circle-style-warning.svg is a better image than   Ambox deletion.png since it seems that our ambox images are not glossy anymore, we should follow a common theme.

-- penubag  (talk) 05:32, 24 April 2008 (UTC)

OK, having played a bit with Inkscape for the first time, how is this for a deletion icon? I had hoped to turn it into a hexagonoctagon, but haven't figured out how to do that. Color may need a bit of tweaking.

— Edokter • Talk • 14:25, 24 April 2008 (UTC)

Of the two triangles above with exclamation marks I prefer the glossy one. Although the non-glossy one is pretty good too, but it feels flatter than all the others. (Sorry Penubag.)

I like Edokters crossed one, I find it about equally good as the glossy triangle with an exclamation mark and the old "stop hand nuvola". Why do I get the urge to click it to stop the loading of the page? :))

--David Göthberg (talk) 18:10, 24 April 2008 (UTC)

Edokter: I assume you meant an octagon, right? How about this?

I took the colours from Edokter's image above. Colours, shadow and margins might need some tweaking.

--David Göthberg (talk) 21:58, 25 April 2008 (UTC)

Yes, that was what I was aiming for. — Edokter • Talk • 22:03, 25 April 2008 (UTC)

Ah good. Personally I like if the icons are slightly lighter than the side bars, since then they don't stand out too much compared to the text. So I find your red colours very nice Edokter.

--David Göthberg (talk) 22:39, 25 April 2008 (UTC)

So here are the ones that seem to be of interest now. If I missed one please add it into this example:

Circle-style-warning.svg

Ambox deletion.png

Octagon delete.svg

Deletion icon.svg

Ambox content o1.png

Information icon2.svg

Information icon1.svg

Of the red I prefer the glossy triangle with exclamation mark (Ambox deletion.png). I find the octagon the worst, it's too bulky and I don't feel it has a clear meaning. Of the blue I prefer the lighter one (Information icon2.svg).

--David Göthberg (talk) 22:41, 26 April 2008 (UTC)

Give me some time to perfect the octagon; it is indeed too big. I'm reworking it (based on deletion_icon) to get the dimensions just right. I have the basic shape icon down, but I'm stuck on the shadow... — Edokter • Talk • 00:07, 27 April 2008 (UTC)

I've uploaded a new version of Image:Octagon delete.svg, based on Image:Deletion icon.svg, so the dimensions and margins match perfect now... but the shadow still needs to match the basic shape. Anyone a bit more skilled in Inkscape should be able to do so easily. BTW, the traffic signs are the least of my favorites; either of the two white crosses (octagon or round) have my !vote. — Edokter • Talk • 20:16, 27 April 2008 (UTC)

I have to admit that I dislike any octagon or circle for the deletion image. I prefer a triangle as the octagon is used for blocked users and the circle for information and content boxes; but if that is not consensus, then I understand. I've some versions of triangle delete icons, how do you like them? Image:Ambox warning pn.svg   and Image:Ambox warning pn.svg  

Triangle type warnings:

Circle-style-warning.svg

Ambox deletion.png

Ambox warning pn.svg

Ambox warning pn.svg

For comparison: Octagon delete.svg

Of the triangles, the latter is my favorite (Ambox warning pn.svg)-- penubag  (talk) 23:01, 27 April 2008 (UTC)

Edokter: I see you made the "Octagon delete.svg" smaller and with thinner borders than what I did. I agree that is an improvement. I added the octagon shaped shadow from the old version. The new shadow has no gradient/toning but that doesn't matter when it is rendered in icon size. The shadow might need some more tweaking, perhaps a bit too intense now.

But I prefer the triangles anyway. To me they mean "Warning, this page is probably going to be deleted". While the red buttons with the white cross resembles the emergency stop buttons we have in factories here in Sweden, so to me they mean "Press/click here to stop!". And the octagon looks exactly like the "Stop loading this page" button in Firefox.

Penubag: I agree, the "Ambox warning pn.svg" is the best one so far. The gradient you added gives it a little 3D feel like the icons for the notice and content types.

--David Göthberg (talk) 11:22, 28 April 2008 (UTC)

I also prefer the triangles to octagons, circles, and especially the "stop hand". However, do any of the delete templates currently in use on Wikipedia use any of the icons? This may be a fight over what color the invisible unicorn should be.--Father Goose (talk) 22:15, 28 April 2008 (UTC)

As far as I know, no deletion template currently contains the icon. So yeah, this decision isn't of the utmost importance.

I do, however, agree that one of the triangles would be best (for reasons cited by David Göthberg). —David Levy 22:23, 28 April 2008 (UTC)

So, I think we might be down to this set of images:

Ambox warning pn.svg

Ambox content o1.png

Information icon1.svg

Information icon2.svg

Image:Information icon4.svg Halfway in between 1&2

And you guys are correct. The deletion icon is currently not even used for article deletion messages. But for image space deletion templates such a triangle is currently used. And commons also uses such a triangle. But anyway, I am more eager to get the blue notice icon right. Which of the blue should we use? I have a slight preference for the lighter one (Information icon2.svg) but would be happy with the darker one too.

--David Göthberg (talk) 23:06, 28 April 2008 (UTC)

I also slightly prefer the lighter blue icon but would be happy with either. —David Levy 23:15, 28 April 2008 (UTC)

Me and Edoker (as stated above) prefer the darker one, but that creates a conflict. So, I made another image that is halfway in between 1 and 2. Easy compromise? :) -- penubag  (talk) 23:55, 28 April 2008 (UTC)

I believe so. Nice job!  :-) —David Levy 00:00, 29 April 2008 (UTC)

Perfect! Its so nice to work with professionals. So, David Levy, can you work your background magic on the images above and upload them as Image:Ambox delete.png (or Image:Ambox deletion.png) and Image:Ambox notice.png? I see you have already fixed Image:Ambox content.png to be the same as Image:Ambox content o1.png. Then we will be set to deploy the new {{ambox}}.

--David Göthberg (talk) 00:43, 29 April 2008 (UTC)

Thanks Gothberg :-D !! It's a pleasure to work with you as well! I can't wait for this to go live after Levy's done with his magic, then I can get to standardizing all the other images, such as this. -- penubag  (talk) 04:49, 29 April 2008 (UTC)

I've updated all of the icons:

delete

content

style

notice/default

move

protection

Does everything look okay? —David Levy 18:22, 29 April 2008 (UTC)

They look fine... I still don't like the traffic sign though. In retrospect, Deletion_icon.svg is my favorite. A cross is a symbol for deletion, the traffic sign says "danger ahead". Doesn't really make sense. — Edokter • Talk • 18:50, 29 April 2008 (UTC)

They're perfect! Just tell me when this is going live so I'll know when to finish standardizing all the other images by. -- penubag  (talk) 19:54, 29 April 2008 (UTC)

I agree, the images are now perfect. Thanks everyone. (Sorry Edokter.)

David Levy: I checked in my old IE 5.5 and they all look great there too, their backgrounds match the ambox.

Since the ambox code has been ready for some time now and the images now are ready too: I intend to deploy the new ambox tonight at soon after 00:00 UTC. That is four hours from now and is when the low traffic hours start for Wikipedia.

David Levy: I want to add back the image size code in ambox/sandbox since if some admin screws up and changes one of the images it protects us from getting a huge image all over Wikipedia.

--David Göthberg (talk) 20:17, 29 April 2008 (UTC)

Okay, I've restored the size parameters (excepting the blank image, which needs to lack the parameter to remain unclickable). —David Levy 20:23, 29 April 2008 (UTC)

Yes, right you are. Silly me. While you were typing that I tried image size on the blank image and it even caused one more problem: It of course became a white box in my old IE 5.5. So I reverted back to your code.

Penubag: You don't need to have the other images ready before we deploy. Since they will not be automatically visible in all the templates out there. So you can work in your own speed.

--David Göthberg (talk) 20:36, 29 April 2008 (UTC)

I know, but, it'd still be nice if all the changes were visible all at once. Well, I'm off to work now. -- penubag  (talk) 21:00, 29 April 2008 (UTC)

Okay, I finished most of the templates (or all the one's I'll do today), just need some admin help in updating a few (Template:POV, Template:Wikify). Thanks! You could see the templates I've updated by viewing my contribs -- penubag  (talk) 23:45, 29 April 2008 (UTC)

The {{ambox}} now "carries protection". That is, I have deployed the new version and updated the /doc. Thus it now offers several new types and parameters, among them the "protection" type. I have done several checks and all seems well.

And it seems the servers are handling the load well. The job queue didn't even jump up much and as far as I can see images are served and rendered as normal.

During the save of the new code I received a big scary error message. Thankfully I had been told in advance about it. That is normal when a big job is put on the job queue, since adding it to the queue takes longer than the save time out. As I had been told I did not press the save button again, but instead just waited a while and loaded the page and it had the new code.

--David Göthberg (talk) 00:54, 30 April 2008 (UTC)

Great, it's finally done :D ! I'll still finish standardizing the images at my own pace though. -- penubag  (talk) 01:57, 30 April 2008 (UTC)

Procedural note: Please be sure to fully protect any images used in {{ambox}}. --MZMcBride (talk) 22:04, 20 April 2008 (UTC)

Indeed, I did protect the proposed "notice" and "content" images. The "delete" icon doesn't appear to be transcluded in any dependent templates, so it isn't a high-risk image. —David Levy 01:20, 21 April 2008 (UTC)

I think the new code for {{ambox}} is ready. But I will wait with updating {{ambox}} since if we do any changes to the new images such as Image:Ambox notice.png then it might cause re-rendering of all the 343,000 pages that use ambox. I am not sure if it causes re-rendering if the image is of the same size, but I know that if the new version has different size (in pixels) then it does cause re-rendering of the pages.

--David Göthberg (talk) 15:47, 22 April 2008 (UTC)

New version deployed and all seems well, see my comment in the section above.

--David Göthberg (talk) 00:56, 30 April 2008 (UTC)

Now the images should be moved to Commons, and some of the old test-images removed (if the uploaders so wish). — Edokter • Talk • 01:33, 30 April 2008 (UTC)

Agreed, the images should be copied to commons to the same names, but the protected versions kept here.

--David Göthberg (talk) 01:50, 30 April 2008 (UTC)

Already done, I originally uploaded all the svg images to commons. I don't see any reason to also upload the png images there. -- penubag  (talk) 01:57, 30 April 2008 (UTC)

Well, as far as I know one reason to copy the PNGs to Commons is that other language Wikipedias often copy templates from the English Wikipedia. If the images are on Commons the templates will work correctly "out of the box" on the other projects. Well, in the ambox case they have to copy the CSS code too. So it is a service to them. Ambox already has 19 interwiki links...

--David Göthberg (talk) 02:45, 30 April 2008 (UTC)

Indeed, the SVGs should be copied as well; the local images can then be removed and salted here. — Edokter • Talk • 19:11, 30 April 2008 (UTC)

Edokter: By the way, I noticed your edit to the {{ambox/sandbox}} changing the blank image to a nbsp. I agree that is a better solution and I tested it in all my browsers. Besides, that is the way we have handled empty table cells since at least 1997 so I bet all browsers handle it well. So I kept your change and that was deployed with the new version of {{ambox}}.

--David Göthberg (talk) 21:00, 30 April 2008 (UTC)

I've noticed, thanks. Glad I could slip it in in time. — Edokter • Talk • 22:21, 30 April 2008 (UTC)

Please comment on a new article space template at TfD Images needed. GregManninLB (talk) 08:01, 20 April 2008 (UTC)

All, I'm sorry if I'm raising an issue that is previously discussed...if so, please point me to the previous consensus. Is there a policy or consensus to limit the use of {{ambox}} to article space? I was attempting to standardize some imagespace cleanup templates, and I used Ambox as the basis (it's already used in {{Copy to Wikimedia Commons}} and a few other imagespace templates). However, my efforts were reverted almost as soon as I made them because the templates were not designed for use in image space. I investigated and saw that other people's efforts to use this metatemplate in other namespaces, like category space, were reverted as well.

I would really like to use {{ambox}} as the basis for an imagespace standardization effort, but if there's a consensus to limit Ambox to article space, I suppose it could be cloned as {{Imbox}} or whatever. But I don't think that would be a good idea, as any improvements/upgrades to the base metatemplate would then have to be made in two places.

Any thoughts are definitely welcome, thanks! Kelly ^hi! 16:04, 24 April 2008 (UTC)

Right, ambox is limited to article space only. "ambox" is short for "article message box". You can read the guideline page that this is the talk page of. You can also see the old discussions in the first two archives of this page.

Image space message boxes more or less do have a de facto standard now. That is to use a thick coloured border around the whole box, at least for the more urgent boxes. Less urgent boxes often use the old "other pages" style, that is a simple grey border around the box.

And you are right about the {{Copy to Wikimedia Commons}}. That one should not use ambox since it is only for image space. Though it could use a slightly thinner purple border (3-4 pixels) all the way around, then it would be in-line with the de facto standard. Or since it is not an urgent box, perhaps just use the thin grey border.

There are some boxes that are used both in article space and other spaces. Currently most of them use {{ambox}}. But we have converted some to detect namespace and change appearance accordingly. See for instance {{notice}}. (That one has examples of three of the namespace box design standards.)

--David Göthberg (talk) 18:31, 24 April 2008 (UTC)

David, thanks for replying...I did read the guideline page, and also read the index of the archives at this page (not the entire archives!). {{Notice}} is fine for when there's only a single template at the top of the image page, but when there's more than one issue, you end up with a big stack of headache-inducing boxes you have to scroll through to get to the real image information. What I'm proposing is using Ambox for the image maintenance templates, like {{BadGIF}} or {{bsr}}, and image deletion templates, like {{ifd}}. This would allow Ambox's stacking and color scheme to be used, for exactly the same reason it was implemented in article space. I'm not proposing it be used for license or information templates, like {{PD-US}} or {{Information}}, that would be inappropriate. I'm curious to hear reasons for opposition to this. I would have proposed this at WP:TMIN, but that page seems to be moribund. Also, barring everything else, is there a reason I couldn't just copy Ambox to a new page and call it "image message box" if the only concern is the name? (Obviously I would prefer not to do that!) Thanks! Kelly ^hi! 19:18, 24 April 2008 (UTC)

1: You can use the same kind of margins etc. as ambox uses in other boxes, so they stack the same way. But the coloured left bar is now reserved for article message box usage. The reason being that it should be clear what kind of page one is looking at. (And to some extent on what kind of page a message box is supposed to be used.) Wikipedia uses several subtle signals to indicate what kind of page you are looking at, for instance a slight colour shift in the page background.

2: But if you use {{notice}} as the basis for an image message box then you will get the thin grey border on it, that is the "other space" look. And I don't find that headache inducing. I think you might be thinking of the thick coloured border around the whole box that many image message boxes use, right?

3: But if I get you right you want to use border colours like yellow and orange to signal severity levels, just like the ambox do, right? Then you can use a thin coloured border all around, instead of the thick border. That is less intensive, more like the intensity of the ambox. 1-2 pixels width of the border is nice. A thin coloured border like that has been suggested for several namespaces, but has not yet been reserved for any namespace, so you can use it. Besides, image namespace already uses coloured borders (both thin and thick) more than any other namespace.

If you want to stack exactly without any space in between then watch out with the top and bottom margins for the box so the borders don't overlap. Since overlaps look really bad when using differently coloured borders. You might need to set the margin to at least 1-2 pixels or so. Depends on if you use 1 or 2 pixels border and if you use collapsing borders or not on your table. Remember to test in several different web browsers.

--David Göthberg (talk) 22:12, 24 April 2008 (UTC)

Thanks, David...how do I use the parameters in {{Notice}} to change border colors? I'm not seeing that in the documentation. I'm hoping for a metatemplate so that future created templates are consistent. Also, can you please point me to the MoS/guideline/policy on appearance of templates in the various namespaces? I'm sorry if I seemed somewhat annoyed when I came here - I try to consolidate all template edits in order to minimize server load. When my changes were reverted, they also reverted totally unrelated changes like template rewording, links, recategorization, and transclusion of template documentation.[2][3] It almost made me feel as if people were trying to !own transclusion of the Ambox template. A pointer to the policy would be most greatly appreciated. Kelly ^hi! 22:18, 24 April 2008 (UTC)

{{notice}} was just an example if you were simply going to use the traditional grey "other spaces" border and not going to use several different border colours for severity levels.

As you state we probably need a meta-template for "image message boxes" that works similarly to {{ambox}}. I see that you already suggested the excellent name {{imbox}} for it.

Since some months I am also working towards building a meta-template that can be used in all namespaces (detect namespace and use the right appearance in all of them) and use the different coloured severity levels and side images and so on. But putting all that together in one well working, easy to use, unit is not so easy as it might look. Recently I made {{main talk other}} and its sister templates to supply one of the needed building blocks but I am also looking at an alternative approach that might be much better.

The guidelines are: Wikipedia:Article message boxes and Wikipedia:Talk page templates. For project space (pages beginning with "Wikipedia:") there is an old de facto standard that is not documented but pretty hardly enforced. Its the grey border and the background colour you see in for instance the message boxes on top of those guidelines. It is also encoded as the CSS class "messagebox". By the way, if you check out Wikipedia:Template standardisation you can see there have been efforts to do standardisation for other namespaces too but those have not reached a consensus yet.

Oh dear, that was almost funny, sorry. David Levy who reverted you usually is a very nice guy. I guess he (like most of us) is just so very tired of everyone that tries to use ambox for all kinds of things it was not made for, so he got a little bit grumpy and didn't bother to look close. And yes, we do try to own it, in the sense that we try to enforce the guideline that it is only for "article message boxes". Unfortunately today people add so much junk to Wikipedia that many editors and admins have become very delete and revert trigger happy. So nowadays you have to spend some time working on a new article or new template in your own user space before you can show it to the world. I assume you know how to make subpages under your own user page, right? And that you can transclude such pages onto other such pages to test template functionality etc.

--David Göthberg (talk) 00:13, 25 April 2008 (UTC)

Thank you, David...yes, I am familiar with using userspace and with the basics of template coding. I also extensively read the links you posted above before I ever posted here. Some of the advanced functions of templates are (currently) beyond me, and of course as an ordinary user/gnome I can do nothing at the MediaWiki level. What I will do is copy Ambox to Imbox and use that as a basis for standardizing imagespace templates. It seems to me this is an incremental improvement over the mess in imagespace we have now, and the risk of user confusion seems low - I don't think they'll have any doubt that they're in imagespace as opposed to mainspace. The truth is that nobody much cares about imagespace templates (image space is not even listed at Wikipedia:Template standardisation). If I posted a proposal it would languish for weeks or months, so I think the best thing is to be bold and just start standardizing the templates. For the protected templates, I will post the proposed coding on a subpage and make an {{editrequest}}. If someone here with the requisite skills would make changes to {{imbox}} to differentiate the style from mainspace templates, I would have no objection and would in fact be greatly appreciative. It would also be fantastic if, in the event someone here had a problem with my edits, they would discuss instead of just reverting all my work. Thanks! Kelly ^hi! 00:30, 25 April 2008 (UTC)

It would be fantastic if people would discuss instead of reintroducing ambox styling to a template from which I've already removed it and redirecting a template from which I've removed it to another image-space template to which they've just introduced ambox styling.

I assume that you didn't realize the above, just as I obviously didn't realize that you'd made unrelated changes (which you didn't note in your edit summaries).

I honestly wasn't angry or trying to be rude, however. I merely sought to undo your honest mistakes. —David Levy 01:18, 25 April 2008 (UTC)

Right, be bold is the right approach in this case. I might take a look some day, but I am way to busy with other things.

Oh, and there is a new improved version of ambox in its sandbox, we are going to deploy that version in some days. You should copy that one instead.

And do write something in the /doc of {{imbox}} immediately. Since if there is no explanation there what is going on then it will likely be deleted.

--David Göthberg (talk) 00:52, 25 April 2008 (UTC)

Will do, thank you! Kelly ^hi! 00:56, 25 April 2008 (UTC)

I've taken a look at the ambox Mediawiki coding, and I think I'll base "Imbox" on Ambox without a direct copy of the ambox MediaWiki templates, using your suggestions above. I'll follow the same color and stacking scheme for simplicity and consistency, but I won't use the left-border color bar which is the signature of ambox; I'll instead use a thin color border as suggested above and/or (possibly) a pastel-colored box based on the same color scheme. Kelly ^hi! 22:08, 25 April 2008 (UTC)

Ehm, sorry to be a nay sayer. But even though light pastel coloured background can be very nice I would advice against it. Since it seems the category message boxes now is using coloured background. Of course if you use very light coloured background then that would be very different from the category boxes and could be nice.

--David Göthberg (talk) 23:00, 25 April 2008 (UTC)

Would you recommend a plain white background? I was thinking the colors used in Wikipedia:Ambox CSS classes/Skins#Pastel (not for a left-border bar, but for the background colour. Kelly ^hi! 23:11, 25 April 2008 (UTC)

Nah, not a plain white background. It is usually too intense since everything else here at Wikipedia, including the pages themselves, use a slight tone on the background. The background used by most old message boxes and still boxes in "project space" is #F9F9F9 which is a slightly grey tone. Ambox as you know uses #FBFBFB, which is lighter and is about the same as the table of content, the <pre> tag boxes and also the colour of the background outside of the page (the left area below the menus).

So I guess you have to experiment and see what you come up with. But #FBFBFB background with a 2 pixel coloured border all around is what I would try first. But hey, my female friends say my sense of colour sucks.

--David Göthberg (talk) 23:50, 25 April 2008 (UTC)

One, somewhat tangential suggestion I'd like to make is that it would be really nice if our image templates shared a consistent visual style with those on Commons. I personally have no idea what, if any, standard template design guidelines exist on Commons, but if the idea is to introduce a consistent style for image templates, it might be a good idea to start the process there first and then copy it to local projects such as this one. —Ilmari Karonen (talk) 00:21, 26 April 2008 (UTC)

I totally agree! I actually spend much of my time on Commons...what led me into the template issue on en Wiki is that people use CommonsHelper to transfer free images to the Commons, and many templates don't transfer because of no Commons equivalent, and are thus lost or distorted. But I think the en Wikipedia culture is by far the most dominant on Commons, most admins there are primarily en users or admins. In any case, I think Ambox is the best standardization scheme anyone on any wiki has come up with so far, and Id like to start from this point and spread the same theme to other namespaces, and eventually other projects. What I like most about Ambox is its attempt to comply with ANSI standards, and to create a translingual imagery theme. Kelly ^hi! 01:17, 26 April 2008 (UTC)

Sorry if this was already discussed, but it seems a little odd to me to be creating a bunch of new ambox-like templates ({{imbox}}, {{cambox}}). Will there eventually be a "tembox" (template message box) or "wimbox" (Wikipedia message box) in the future? Might a good idea instead be to use {{ambox}} for article messages, and something like "nambox" (non-article message box) for all other namespaces (instead of imbox, cambox, etc.)? This would keep the code and CSS simpler and prevent an explosion of different styles for each namespace. Just a thought... --CapitalR (talk) 01:43, 30 April 2008 (UTC)

CapitalR: You probably know most of this, but just in case and for everyone else:

Well, for template space there already are a standard design. The brown style as specified in this guideline: Wikipedia:Talk page templates. And that is available as the CSS class combination "messagebox standard-talk". And that style pre-dates ambox.

And for "other" spaces such as Help and Wikipedia space we have a very old de facto style that is widely used and enforced. (Grey border and light grey background.) It is available as the CSS class "messagebox".

But for image space people are now using a separate style with coloured borders. Probably inspired by the Commons box style. (Or who knows where that style turned up first?) Although currently everyone does it slightly differently, so it looks bad when several message boxes are on the same image page at once.

And for reasons I don't really agree with people came up with a special style for categories and started using it. (Very dark coloured background. I find it hard to read text in such boxes.) But again, everyone does it slightly differently, so it looks bad when several message boxes are on the same category page at once.

And frequently people try to use {{ambox}} in those namespaces since they think ambox is convenient and looks good.

So what {{imbox}} and {{cambox}} is meant to do is to at least standardise the new styles used in those two name spaces so they look good and when several boxes are used on a page they stack well. And they also give us a central place where we can achieve a concensus on how those styles should look. Instead of now having to fight the battle box by box. And my experience with Wikipedia so far is that when we do bring in a lot of people and achieve consensus on the looks of something it usually turns out pretty well looking.

But yeah, I would prefer that the simple grey "other" style was used in all namespaces except for articles and talk pages. Perhaps with the addition of a thin red border for deletion templates. Feel free to bring that up as a counter suggestion, for instance at the Wikipedia:Village pump (policy). You will have my vote. But I think we will loose.

--David Göthberg (talk) 02:28, 30 April 2008 (UTC)

Hi David, thanks for your reply. It really isn't much of a big deal to me, I was just momentarily worried that there would be an explosion of ambox copies and associated CSS (I'm a big fan of standardization, which you already know), but my fears have been calmed. The image space color matching to the Commons actually sounds like a great idea now that I think about it. Oh, and it's good to hear that all went well with the recent upgrade. --CapitalR (talk) 20:40, 30 April 2008 (UTC)

Yeah, the CSS and Javascript files for Wikipedia are starting to get very large. Wikipedia must be a slow load to modem users nowadays. And the {{imbox}} and {{cambox}} unfortunately will add to the size of the CSS code in MediaWiki:Common.css. Although I will integrate their CSS code with the ambox classes to save some code size and to avoid code redundancy. That is, I will simply give some of those classes more names, not more code. I have already tested that in my own personal monobook.css.

--David Göthberg (talk) 21:14, 30 April 2008 (UTC)

To standardise the look of message boxes in image space and category space we have now coded up some suggestions. See the new meta-templates {{imbox}} and {{cmbox}} and discuss the design for them at their talk pages.

I will announce this standardisation effort in the appropriate places here at Wikipedia during the next few days.

--David Göthberg (talk) 12:47, 1 May 2008 (UTC)

  Done - Kelly ^hi! 11:46, 2 May 2008 (UTC)

• {{Cleanup-images}}

Probably because it's mistakenly categorized as an image box, but it's actually an article cleanup box. Kelly ^hi! 18:04, 1 May 2008 (UTC)

Yes I agree, that clearly is an article message box. I say a yellow "style" one. Feel free to fix it.

--David Göthberg (talk) 19:14, 1 May 2008 (UTC)

It's completely unused, and not even mentioned in the template lists: Special:WhatLinksHere/Template:Cleanup-images. It should either be added to Wikipedia:Template messages/Cleanup#Images or TfD'd. -- Quiddity (talk) 19:56, 1 May 2008 (UTC)

I can see how it would potentially be useful...my guess is that nobody knows about it. I'll take responsibility for it, clean it up tonight, and add it to the cleanup template page. If it turns out that nobody wants it there I'll nom it for deletion. Kelly ^hi! 20:13, 1 May 2008 (UTC)

Wikipedia:Words to avoid is tagged with {{pp-dispute}}, but it does not appear on the page as it is supposed to be; it has a thicker-than-normal grey border all around and no sidebar, and the lettering is smaller. In the source, the code is a simple {{pp-dispute}}, and I wonder what could be responsible for this change in appearance. Waltham, The Duke of 07:05, 2 May 2008 (UTC)

That template, or actually {{pp-meta}}, is set up to have a different appearance in different namespaces. In articles it adopts the {{ambox}} style, on talk pages it follows the standard "coffeeroll" color scheme, and in other namespaces it looks the way you see on the page you linked to. The point is that you can use the same template on any page, and it will adapt itself to the specific visual style used in each namespace. —Ilmari Karonen (talk) 07:46, 2 May 2008 (UTC)

I kind of knew that already, but it escaped me that the page in question was in the project namespace. I'll try to be more careful in the future, but I promise nothing. :-) Anyway, thanks. Waltham, The Duke of 08:04, 2 May 2008 (UTC)

I saw the new clock graphic for the "needs to be updated" template, looks hot. Think we could see if we could implement icons like this on the Current events templates? ViperSnake151 15:12, 2 May 2008 (UTC)

Thanks! I'm working on standardizing all the images, I'll get to it as soon as I do. -- penubag  (talk) 16:21, 2 May 2008 (UTC)

This article documents a current event. Information may change rapidly as the event progresses.

How does this look? -- penubag  (talk) 01:35, 3 May 2008 (UTC)

What's wrong with the current event icon we use now? Image:Gnome globe current event.svg  

--David Göthberg (talk) 08:54, 3 May 2008 (UTC)

It's been decided that any message box which uses the Ambox template will have a consistent icon style. See above. ViperSnake151 17:41, 3 May 2008 (UTC)

ViperSnake151: No, I am not aware of any such decision or consensus. The previous discussions on this page were just that we made the default images for the {{ambox}} meta-template look better together.

However I have noticed that Penubag have been talking about that he now is "standardising" the other images used in article massage boxes. And from what I have seen that means he takes existing images and symbols and shrinks them and put them on top of round toned signs just like the default images. I disagree with that and as can be seen on for instance Template talk:Wikify#Image others disagree with that too. The round signs are fine when the symbol is a simple "i", "!" or "?", but for more complex symbols it just distracts and makes the symbol harder to see. I have been meaning to discuss this with Penubag but I have been very busy lately.

And regarding the globe images above: The one with the red clock was developed as a teamwork with several editors involved, since we needed a free alternative to the old WikiMedia current event logo. Since the WikiMedia logos are not under free licenses they can not be used in articles since articles get mirrored to other sites. We kept a red clock since red indicates "urgency" as in "current". And we did put the clock in a high position so it would look okay with a shadow, since we wanted to have some 3D feel.

--David Göthberg (talk) 18:33, 3 May 2008 (UTC)

I just readjusted the new globe icon to be red and at the top like the old one. This better? ViperSnake151 19:41, 3 May 2008 (UTC)

I just wanted to mention this gallery. We got a ton of "current event" icons to choose from. I've been collecting them. If you want consistency, stick with anything that has the red clock (like in the current icon). The globe can change, but most topic-related ones have matching red clocks. Rocket000 (talk) 03:21, 4 May 2008 (UTC)

I have noticed Penubag's campaign of standardisation for ambox images... And I am not fully satisfied with the results so far. Taking images, painting them white, and placing them on disks works well for the "content" boxes, where the contrast is sufficient (and I must say I was delighted to see the dreadful NPOV balance go), but in the "style" boxes things are different. The contrast is simply not sharp enough. Template:Grammar, for example, had a very nice gothic A for an icon, and with this edit (which refers to this page for a rationale, which I cannot find anywhere) placed the A on a yellow disk, rendering it difficult to understand, especially in its smaller version. Surely such treatment should be reserved for cases with good contrast, both in terms of colour and of a simple enough design? Waltham, The Duke of 02:17, 6 May 2008 (UTC)

The whole point is standardization, we are all working on imbox, ambox, and cmbox to achieve unity. True, I sort of arbitrarily decided that during this -box standardization, I would also standardize the images used by them to follow a common theme. But, I've also mentioned it several times (about 3 times) on this page, see above in New Ambox Version, and there were no objections. Being WP:BOLD I made the changes to the images without facing any opposition. If you oppose, I'd be glad to talk it out. The icon in Template:Grammar was good and sharp for the most part until it was overwritten. I'll work out the yellow in some problematic icons to fix this problem though. -- penubag  (talk) 02:56, 6 May 2008 (UTC)

How's a darker stroke around images used in the yellow circle look when scaled down appear?   -- penubag  (talk) 04:35, 6 May 2008 (UTC)

I still can't read that text at all. There's just not nearly enough contrast between yellow and white, even with the dark outline. --CapitalR (talk) 06:23, 6 May 2008 (UTC)

Oy, I'd forgotten about this one. (Sorry.) Well... It might be an improvement over the previous version, but the contrast is still rather low. Personally, I don't think the icons should all be of exactly the same type, as long as they are presentable and follow some general lines. For instance, the previous grey A was handsome and clear-cut, and matched the style of most icons used in the various message boxes. As a matter of fact, some variation should be allowed, if only for the sake of avoiding boring repetition, as well as in order to ensure that if there are, say, two or three style amboxes stacked at the top of an article, they won't appear almost identical on first glance.

All that said, I appreciate your efforts, and such standardisation might be more acceptable in the content boxes, where the contrast is better. As I said, I really liked the new NPOV icon, and the Rewrite one isn't bad either. (Also note that I did not watch closely the discussion above, although I did have a look once in a while and did not realise that anything else than the default images was discussed. Your three comments were in a small part of the discussion, near its end.) Waltham, The Duke of 01:41, 9 May 2008 (UTC)

I don't know standardizing all icons to this "coin" template is a great idea. The role of the icon is to allow the user to quickly identify the message if he is already familiar with it, or to get an idea of what it is about if he is not. The silhouette of an image is an important visual cue, and by confining all of the images to the same silhouette you give away some of the icon's power in this role. Not that it matters anymore, but when I designed these boxes, my idea was that the icons would have an overall consistent graphic style, and the color scheme would coordinate with the color bar. I never intended for the icons to be templated, though. The {{cleanup}} template was what I had in mind as a jumping off point. – flamurai (t) 23:05, 13 May 2008 (UTC)

I fully agree with Flamurai here. It is a benefit if different icons have different silhouette. Especially when they have the same colour. And it is not necessary that the icons be yellow in the yellow boxes, they can just as well be black (or perhaps grey) since those are neutral colours in the ambox scheme.

--David Göthberg (talk) 23:18, 13 May 2008 (UTC)

I agree also. I was under the impression that Penubag merely intended to standardize the icons that already contained color-coded circles (which was my intention when I replaced the "content" icon). I didn't realize that Penubag intended to replace other icons with matching circular ones as well (which seems rather counterproductive, as it makes the tags harder to differentiate). —David Levy 00:28, 14 May 2008 (UTC)

The two new message box meta-templates {{imbox}} and {{cmbox}} for category and image message boxes are based on {{ambox}}. While we worked with them we discovered some oddities and improvements that we fixed in them. Now I would like to apply the same improvements to the ambox code.

1: I intend to add -1 pixel top and bottom margin to the CSS code for the ambox so when stacked it only gets one single line between the boxes in all web browsers. If you compare the examples in the doc for {{ambox}} and {{cmbox}} you will see that ambox gets double lines between the boxes in some browsers.

2: There are several oddities in the second switch case in the ambox code. Among other things it misbehaves if you feed an empty image parameter, like this: image =

3: I would like to remove the parameter "image=blank". That's the parameter that causes a blank area the same size as a default image. I don't think any boxes use that one anymore, but I'll check that and change any boxes that do. We should of course keep the "image=none" parameter.

Any comments before I go ahead with this?

--David Göthberg (talk) 19:27, 11 May 2008 (UTC)

Might it be a good idea to wait until the {{cmbox}}/{{imbox}} deployment is winding down (both to avoid putting additional stress on the servers and to ensure that no bugs emerge)? —David Levy 20:25, 11 May 2008 (UTC)

I'd keep the "image=blank" parameter around as an option, even if it's unused. The other changes sound reasonable.--Father Goose (talk) 20:41, 11 May 2008 (UTC)

David Levy: Yeah, I am in no hurry. I just wanted to bring the changes up for discussion while I was thinking of them and so people have some time to take a look.

Father Goose: Ouch, you like "image=blank"? I always disliked it and since it seems to be unused I wanted to take the chance to get rid of it. But oh well, handling that one properly when I fix the bugs in the second switch case only costs a little extra code.

--David Göthberg (talk) 21:02, 11 May 2008 (UTC)

I agree that image=blank should stay; it's not in the way and is used mainly in custom boxes, not necessarely templates. — Edokter • Talk • 22:29, 11 May 2008 (UTC)

Ah well, so we'll keep the "image=blank" parameter then.

I have now updated the ambox CSS code in MediaWiki:Common.css to use the -1 pixel top and bottom margin. Such a change costs nearly no server work, so it costs nearly nothing to revert if I did a mistake. Now the amboxes will look nice in "all" web browsers as far as we know.

The switch case fix needs to be done in the template code itself. So I'll probably wait until 20 May when we at the same time can change to use the CSS class "ambox-move" instead of "ambox-merge". (Due to that we added that new class name 20 April and the web browsers cache Common.css for 30 days.)

--David Göthberg (talk) 01:54, 13 May 2008 (UTC)

I have now updated the code of ambox with the planned fixes: Using the new CSS class names (deployed for 30 days now). Fixing the empty "image=" parameter bug. I also fixed another bug: The padding for the image=none case. And I did some other clean-up. I of course tested the new code in the sandbox first. The "image=blank" parameter still works.

--David Göthberg (talk) 08:33, 25 May 2008 (UTC)

Per discussion at MediaWiki talk:Common.css#Metadata class in mboxes:

In the next {{ambox}} code update I intend to add the ".noprint" class. I also intend to remove the "@media print { .ambox { display: none; } }" code from MediaWiki:Common.css since that code will then be unnecessary.

--David Göthberg (talk) 07:28, 27 May 2008 (UTC)

Not sure about using the "noprint" class anymore, I think I know a better solution now. Will test that some day when I get the time. Just wanted to note that here so others don't go ahead and do this change.

--David Göthberg (talk) 20:18, 16 June 2008 (UTC)

Last summer we deployed {{ambox}} for article message boxes and some weeks ago we deployed {{imbox}} and {{cmbox}} for image page and category page message boxes.

Now we have coded up the {{tmbox}} for talk pages and the {{ombox}} for all other types of pages such as "Wikipedia:" pages. This means all the namespaces are covered. Everyone is invited to take a look at the new boxes and have a say at their talk pages.

Note that we are suggesting some colour changes for talk page and "other pages" message boxes. So we really would like some input from some editors before we deploy this all over Wikipedia. For instance, this is a {{tmbox}} with the suggested style for "minor warnings and problems".

And this is an {{ombox}} with the suggested style for "major warnings and problems".

--David Göthberg (talk) 12:18, 2 June 2008 (UTC)

{{Totally-disputed-lead}} was created on 9 September 2007 and probably escaped the standardization effort because it is not categorized. It is similar to {{Totally-disputed-section}}, with the only difference in text being that the former refers to "the lead section" and the latter refers to "this section". Since the "disputed-lead" template is only used in one article, perhaps a better solution would change it to a redirect. -- Zyxw (talk) 18:58, 6 June 2008 (UTC)

Endorse. — Edokter • Talk • 00:25, 7 June 2008 (UTC)

I just updated {{Totally-disputed-lead}} to the new style. It uses the same format and text as {{Totally-disputed}}, but replaces the word "article" with "lead section". I did this instead of using a redirect after noticing a similar template named {{POV-intro}} which is only used in two articles, yet survived a WP:TFD nomination (archived here). -- Zyxw (talk) 05:20, 7 June 2008 (UTC)

Maybe this has been discussed before, but is there any reason we can't use the Tango icons?

This page may meet Wikipedia's criteria for speedy deletion...

This article is being considered for deletion in accordance with Wikipedia's deletion policy...

The neutrality of this article is disputed...

This article may require cleanup to meet Wikipedia's quality standards. Please improve this article if you can...

This article documents a current event. Information may change rapidly as the event progresses...

It has been suggested that this page be split into multiple pages accessible from a disambiguation page...

Editing of this page by new or unregistered users is currently disabled...

They all match and look nice together, plus they match the direction the open-source community's moving in. —Werson (talk) —Werson (talk) 22:57, 26 June 2008 (UTC)

It has been discussed extensively; the current icons are even custom made specifically for ambox. Have a look in the archives linked above. — Edokter • Talk • 23:54, 26 June 2008 (UTC)

There's no way that's true; Image:Merge-arrows.gif ( ) dates all the way back to June 2005. This standardization project is less than a year old. I looked through the archive and couldn't find anything discussing an icon reboot. —Werson (talk) 01:00, 27 June 2008 (UTC)

This is all stated in the archives of this page, but for your convenience here is the compact version of it:

Well, I was the one that created Image:Merge-split-transwiki default.svg   and the purpose was to use it (or rather its ambox optimised PNG version Image:Imbox move.png) as the default image for the {{ambox}} move type.

Already when I created it we were aware that it doesn't really match the other ambox icons. But its purpose and demands are different. It is only a placeholder image for demonstration and testing purposes, it is not meant to be used in actual move message boxes. But as such it still should match the style of the other move/merge/split icons, not the style of the other ambox icons. Take a look at the set of standardised move/merge/split icons at the description page of Image:Merge-split-transwiki default.svg.

The purple bent arrow you suggest does not match the standardised move/merge/split arrows thus your suggested arrow is "wrong".

And the reason the move box is purple is that the move/merge/split arrows are red and blue, thus the box matches them best if it is in-between, that is purple.

Of course, already back then we thought that the standardised move/merge/split arrows were a bit flat and boring. So if anyone feel up to it you can design new more glossy versions of those arrows and present them at this talk page and you might get consensus for the new arrows. Remember to also announce it on the village pump since this would mean changing a very old and well used standard. And you need to make new versions for the whole set. Otherwise you probably will not get consensus for a change. Well, you can first make new versions for say two of them and start out the discussion to see what styles people like. And I recommend that you keep the idea of one red and one blue arrow since most move/merge/split messages involve two or more articles.

--David Göthberg (talk) 04:08, 27 June 2008 (UTC)

 

 

 

I never really liked our "move" icon; it seems relatively flat. So inspired by Werson, who purpled the redo arrow, I modified it to play nice with the current set. Any takers?--HereToHelp ^{(talk to me)} 00:35, 27 June 2008 (UTC)

See my response above. Although I admit you made a pretty cool suggestion. Nice shadow!

--David Göthberg (talk) 04:08, 27 June 2008 (UTC)

So, something stylistically similar but with red and blue arrows?--HereToHelp ^{(talk to me)} 17:37, 27 June 2008 (UTC)

Yes! I like your "Potential replacement 2" Image:Merge-split-transwiki default 2.svg to the right. It is clearly an improvement over my old "flat" version. And that kind of "shiny" arrows would work fine with all the other move/merge/split icons.

Perhaps we can even make the arrows slightly rounded or bent in some way so they don't look so straight? Don't know if that would be an improvement but might be worth a try.

--David Göthberg (talk) 15:57, 28 June 2008 (UTC)

Caution: Not all users think that flat=boring. I (and many others) prefer the less-flashy less-cartoony icons. I also prefer the small file sizes for the simple icons. The more distinct we make the aesthetic style - the less people are going to like it - which is why simple and minimal is generally best. Dropshadows and 3d-effects are not necessarily helpful. Basically: Please don't force an AOL/AIM/smiley aesthetic on us! Thanks. -- Quiddity (talk) 18:36, 28 June 2008 (UTC)

That's fine, but can we at least agree that "all flat" and "all 3-D" are each preferable to a disparate mixture of the two? —Werson (talk)

Generally agreed. But there will always be some 2d icons (eg Image:Unbalanced scales.svg) so forcing icons into 3d is unnecessary. -- Quiddity (talk) 19:17, 28 June 2008 (UTC) (edited at 20:07, 28 June 2008 (UTC))

But you won't need a disparate mixture; I've created a complete set:

(Pardon the odd formatting; I borrowed it from commons:Template:Series-merging.) I was thinking of adding drop shadows, but I guess I've got enough of a fight on my hands. Anyway, I'll let the images speak for themselves. I fully support them.--HereToHelp ^{(talk to me)} 19:52, 28 June 2008 (UTC)

Quiddity: So why can't we get 3D scales? There are a finite number of icons. There doesn't have to any 2D icon.--HereToHelp ^{(talk to me)} 20:14, 28 June 2008 (UTC)

I wasn't referring to your "move" icon. The problem extends way beyond that. —Werson (talk) 20:30, 28 June 2008 (UTC)

So does the lack of 3D icons prevent us from implementing those we already have? They're not even 3D (no drop shadow), just a border and a gradient.--HereToHelp ^{(talk to me)} 20:33, 28 June 2008 (UTC)

This conversation's a little mixed up. I was disagreeing with Quiddity and supporting you. Most of the icons being used are 3-D(ish) so let's move in that direction. —Werson (talk) 21:01, 28 June 2008 (UTC)

Oh. (*blush*) Thanks. Quiddity: I agree that the "candy" icons at the top of this section aren't serious enough. They're characterized by a semi-transparent whitish sheen meant to simulate reflection. Mine, on the other hand, don't have drop shadows or the sheen, rather just (like I said before) a border and a gradient. --HereToHelp ^{(talk to me)} 21:15, 28 June 2008 (UTC)

Absolutely. I'm not opposing the "Potential replacement 2" style. I just wanted to inject a voice a caution into the conversation. Plus it never hurts to remind/inform editors that things like this are to be avoided (Because it appeals to some, but repels others). As long as we avoid decoration-for-its-own-sake, and keep it to simple usability improvements, then I'm happy.

I would oppose 3d scales (for example) because it wouldn't make the image any clearer in meaning. That would be "complication/decoration for its own sake".

Lastly, the new images (in the table above) are all 300% the size (in kb) of their old counterparts. I don't know enough about images to help, but perhaps an image lab editor could help reduce/optimize the file size somewhat? -- Quiddity (talk) 00:16, 29 June 2008 (UTC)

We won't be using SVG files for message boxes anyway. They'll be optimized PNGs once we come to an agreement (IE and MediaWiki have a joint problem with SVG-PNG transparency). —Werson (talk) 01:17, 29 June 2008 (UTC)

They're bigger files because they have to store data on gradients and borders, although in one cases there are fewer shapes. And I'm aware of the PNG optimization, but that's fairly easy to do. Sorry about the misunderstanding, but it seems like there's fairly strong support for the new set. Thanks.--HereToHelp ^{(talk to me)} 01:45, 29 June 2008 (UTC)

Given the previous standardization on a set of icons that partially reflects several known computer operating-system GUI's (incl. Microsoft Windows 4.0-up), I see an alternate set of icons that may meet the requirements, several of which are in routine use here on Wikipedia^®. One new icon I would recommend for Speedy-Deletion and Indefinite-Block is a transparent-backed PNG consistent with Image:Dialog-error-round.svg, shared by several OS's, incl. MS-Windows and the Tango Desktop Project. My proposal for default Icons for certain Message Box Templates I demonstrate using the basic form of Template:Imbox:

Type:Speedy. (Example: DB-CopyVio.)

Type:Delete. (Example: AfD.)

Type:Content. (Example: Totally-Disputed.)

Type:Style. (Example: Cleanup.)

Type:Notice. (Example: CurrentEvent).

Type:Move.

Type:Feature.

Type:Protection.

Type:License.

This setup could work on a Template using BGColor=#F8EABA (for Talk pages), excepting Speedy and License; additional icons consistent with preexisting practice for given situations may be applied with the ImageRight parameter. What pros and cons per new default icon? B. C. Schmerker (talk) 09:26, 27 June 2008 (UTC)

Update: Image:Ambox deletion.png, similar to Image:Ambox warning pn.svg, is already standard for Nominations for deletion; I consider Image:Deletion icon.svg and Image:Octagon delete.svg candidates for a Speedy default icon, as both are immediately differentiable from the exclamation triangle of Image:Ambox deletion.png used on Nominations for Deletion. Using the form of Template:Ambox, they would appear thusly:

Type:Speedy, Image:Deletion icon.svg. (Example: DB-CopyVio.)

Type:Speedy, Image:Octagon delete.svg. (Example: DB-CopyVio.)

Type:Delete, Image:Ambox deletion.png. (Example: AfD.)

Reactions? B. C. Schmerker (talk) 04:10, 30 June 2008 (UTC)

Yes; I react to the use of thusly. (Sorry, I couldn't resist; it's a strange word for me. :-D)

Seriously, now, although I don't have much heavier arguments than "I don't like it" (the X icons look somewhat bulky), I do believe that disambiguation through the icon is not all that necessary, considering the different background. It is quite distinctive on its own. And I could add that there is no difference in meaning between slow and speedy deletion—just in urgency—so there is no reason to change icons. Especially since the triangular one are more familiar and conveys the appropriate message ("Attention!") more accurately. And the consistency between the three triangular icons is also an attractive feature, as I see it, showing increasing levels of urgency in a way easy to understand.

Hm. Maybe I do have arguments after all. (scratches head) Waltham, The Duke of 11:28, 30 June 2008 (UTC)

As illustrated in the foregoing examples, PNGs developed from Image:Ambox warning orange.svg (for an updated Image:Ambox content.png) and Image:Ambox warning yellow.svg (for an updated Image:Ambox style) will require MOVEs of existing Images, which I still consider useful. Should both exclamation-triangle Ambox ID images be adopted, recommend the following MOVEs for the pre-existing Images:

• Image:Ambox content.png -> Image:Ambox alert.png, as the circle-exclamation is good for Notices of needful items less serious than Deletion, Content or Style Issues.
• Image:Ambox style.png -> Image:Ambox cleanup.png, as the broom is an instant-ID cleanup indicator.

- B. C. Schmerker (talk) 18:41, 5 July 2008 (UTC)

This section was previously named "Discussion on colour change for template". --David Göthberg (talk) 13:17, 25 July 2008 (UTC)

An editor feels that {{POV-check}} should belong to style instead of content class. The relevant discussion (right out of the freezer) can be found here.

I was unsure of where to post the above... Now that the standardisation effort is more or less over, at least where ambox is concerned, which is to be the difference between this talk page and Template talk:Ambox? Waltham, The Duke of 21:14, 23 July 2008 (UTC)

Even though that the standardisation effort is more or less over for ambox, this is probably the best place to discuss things like what colour level to use for a message box. Since this page is watched by many editors who have worked with this and have discussed such colour levels before. So thanks for pointing to the discussion about {{POV-check}}. I responded at its talk page. (And my personal view is that it should remain orange, although it is a tough case.)

And regarding this talk page contra Template talk:Ambox: Yes, having these two talk pages have caused a lot of confusion and split up discussions all since we started the ambox project. That is why when we made the {{tmbox}}, {{imbox}}, {{cmbox}} and {{ombox}} we kept all talk on their talk pages. Both regarding the templates themselves and regarding the new colours and styles for such message boxes.

I am thinking of solving this problem by doing this: Archive all the sections of Template talk:Ambox, then link to those archives at the top of this page (next to the box that links to this page's own archives), then redirect Template talk:Ambox to this talk page.

And I think this talk page should be the "main" one for article message boxes since this is the talk page of the guideline.

--David Göthberg (talk) 15:33, 24 July 2008 (UTC)

You have left nothing for me to add; I agree completely. Waltham, The Duke of 19:10, 24 July 2008 (UTC)

Yes please. Merge to keep things together/simple would be good. -- Quiddity (talk) 19:32, 25 July 2008 (UTC)

I laughed when I saw the {{mergefrom}} on this page... I've indirectly provided an argument in favour of borders in move-type boxes. :-D Waltham, The Duke of 21:32, 25 July 2008 (UTC)

For some reason I've been under the impression that the merge had been sorted out. I now realise that it has not. Shall I proceed with the above-described course of action? Waltham, The Duke of 02:10, 10 September 2008 (UTC)

Waltham.: Oh sorry, I just have not had the time to do it yet. (It has a low priority on my long to-do list.) You are more than welcome to do it.

--David Göthberg (talk) 07:49, 10 September 2008 (UTC)

Mission accomplished. Although, I regret to say, I did not have the courage to re-order the archived sections; several of them from September and October 2007 are out of order and divided between the two (uneven) archives. The Erinyes will hunt me forever... Waltham, The Duke of 23:26, 10 September 2008 (UTC)

Waltham: Thanks, well done. And as I stated above I have now added a hand-coded archive box at the page top, that explains the merge and links to the archives of Template talk:Ambox. (Well, not very hand-coded, with {{tmbox}} it was a breeze to do it.)

And I don't think we need to worry about the order of the sections in those old archives. Besides, we can sort them out any time in the future when we feel sufficiently bored.

--David Göthberg (talk) 00:50, 11 September 2008 (UTC)

Indeed. Although boredom is something unlikely for me to experience in the foreseeable future. :-) Waltham, The Duke of 04:52, 11 September 2008 (UTC)

I have now built the {{fmbox}} "header & footer message box template".

Some time ago I noticed that we could have good use for a message box similar to the {{ombox}} but with 100% width and only one colour style. It can be used to build message boxes for system messages such as MediaWiki:Sharedupload and MediaWiki:Sp-contributions-footer-anon. It can also be used for header and footer boxes on user pages.

I would appreciate if those that are interested would check it out and comment on its talk page.

At the same time I would like to draw the attention to a closely related message box standardisation discussion: Should editnotices be transparent or have the "table of content colours"? See Wikipedia talk:Editnotice#Colours for editnotices.

--David Göthberg (talk) 11:03, 9 September 2008 (UTC)

We are now discussing to standardise some more colours for the {{fmbox}}, so it can be used for warning messages like MediaWiki:Editingold and MediaWiki:Protectedpagewarning. Everyone is welcome to join the discussion over at Template talk:Fmbox#New type?.

--David Göthberg (talk) 14:20, 25 October 2008 (UTC)

Template:Current disaster has recently acquired a parameter that allows one to change the sidebar's colour from blue to red. As this treatment of the template falls outside the ambox colouring scheme, I believe the editors dealing with such boxes might be interested to comment in the relevant thread here. Waltham, The Duke of 02:18, 10 September 2008 (UTC)

I need to clarify that the link given above is to a convenience subsection of the longer debate. For those who would like to read the lengthy discussion prior and how the conclusion was reached, please go to WP:AN#warning template for Hurricane Gustav. Cheers! —Elipongo (Talk contribs) 06:26, 10 September 2008 (UTC)

Oh dear. Thanks for the heads up Waltham. That red border they show at the bottom of the documentation for {{Current disaster}} makes it look like a page is going to be deleted.

And yes, we should take part in that debate and try to convince them that using red in that case is a bad thing.

--David Göthberg (talk) 07:54, 10 September 2008 (UTC)

I was asked to solve a problem with the disambig and set index boxes. (There are a whole bunch of them.) And while solving that problem I realised it would be better if they used a single meta-template. And they have pretty much the same needs as the other mboxes. So I made the {{dmbox}} which works like the other mboxes but looks like a disambig or set index box.

--David Göthberg (talk) 02:04, 13 October 2008 (UTC)

I tried to use this template - and when using default notice - there is no border or background colours - just the 'i' image and the default text is fine. What am I missing here - something to do with referencing to the tables? PLA72 (talk) 17:51, 27 October 2008 (UTC)

Where did you try to use it? —Ms2ger (talk) 19:07, 27 October 2008 (UTC)

On a local ubuntu server machine - had to copy the common.css and the FunctionParser extension. PLA72 (talk) 10:35, 28 October 2008 (UTC)

Did you make sure you cleared your own cache? I don't know what else could be the problem. —Ms2ger (talk) 10:51, 28 October 2008 (UTC)

Yes I did, and also checked on different computer that hasn't accessed the wiki before - same result. I even restarted the server just to make sure. It's like the table coding is not taken into consideration, everything was copy and pasted from here. PLA72 (talk) 11:35, 28 October 2008 (UTC)

Right, you need to copy the ambox CSS classes from MediaWiki:Common.css, and enable the ParserFunctions extension in MediaWiki. And then you need to install/enable the MediaWiki extension that allows HTML in wikitext, since the {{ambox}} uses "HTML wikimarkup" (like <table> and so on) instead of plain wikimarkup for the table (like {| |} ). See meta:Help:HTML in wikitext#External links. Since as far as I remember the support for HTML wikitables are not enabled in the default installation of MediaWiki. But it is enabled in the Wikimedia projects like the English Wikipedia.

And of course, then you need to purge the page that use an ambox, and then you need to bypass your browser cache. (Note that that is two separate operations.)

--David Göthberg (talk) 12:31, 28 October 2008 (UTC)

Already done all that - but want to ask - which extension is recommended to 'enable' HTML as there are a few out there? Thanks.

And I have enabled the $wgRawHtml but does nothing. The Ambox does show the image, the text in correct order but the border and the background colour is not showing up. PLA72 (talk) 13:06, 28 October 2008 (UTC)

Ouch, you have already done all that and still don't see the borders? Then I don't know what more to do.

And regarding which MediaWiki HTML extension to use: I have never installed a MediaWiki, and I think most or all of the people who watch this page have never done that. So you have to ask at the forum for that, probably somewhere on mediawiki.org or so. Sorry.

--David Göthberg (talk) 13:18, 28 October 2008 (UTC)

Ok thanks for your help, have registered and posted my question there... PLA72 (talk) 13:42, 28 October 2008 (UTC)

It is working now - What I did with common.css was I created a file and put it into skins folder! Now I did it via MediaWiki:Common.css which I never realised I needed to do this. Thanks for your help in trying to get me sorted. PLA72 (talk) 13:29, 29 October 2008 (UTC)

Minor thing: Here at Wikipedia we put our signatures after our comments, not before. I fixed your comments above accordingly.

Ah, good to hear that you solved it. And yeah, I am not surprised that the MediaWiki default installation doesn't have the same CSS file names as Wikipedia. Next time you ask people for help, then if possible link to the problematic page (on your site in this case) so people can take a look. If you had linked, we probably would have discovered that your page didn't have the CSS code loaded.

--David Göthberg (talk) 18:03, 29 October 2008 (UTC)

So {{Current sport-related}} used to use its own hacked-up "tiny" attribute to float it underneath article infoboxen. I've converted it for the time being to use a raw mbox, but adding a small attrib to this template with slightly different styling (basically, to give it the same width and styling as an {{infobox}}) would be even better. Comments / suggestions? Chris Cunningham (not at work) - talk 10:38, 5 December 2008 (UTC)

There was an ambox-mini class, but it was removed, because it wasn't used at all. I think the best way forward is to get .ambox-small into Common.css but keep it out of {{Ambox}}, as this template is really the only use. I do believe, though, that we shouldn't be using {{Ombox}} for an Ambox. —Ms2ger (talk) 12:11, 5 December 2008 (UTC)

Yeah, I know, it's hackish. I'll see what I can do. Chris Cunningham (not at work) - talk 12:33, 5 December 2008 (UTC)

There actually is a better solution: as of next year, we'll be able to use class="ambox ambox-notice mbox-small". Until then, I'd go for hard coded styles. —Ms2ger (talk) 12:38, 5 December 2008 (UTC)

Great. Thanks! Chris Cunningham (not at work) - talk 15:18, 5 December 2008 (UTC)

There is a discussion over at Template talk:Expand-section#More subtle style to add a left aligned small style to {{expand-section}}.

--David Göthberg (talk) 04:51, 3 March 2009 (UTC)