Template talk:Ambox/Archive 12

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 5

←

Archive 10

Archive 11

Archive 12

Archive 13

Standardising cleanup box formatting

I've made a proposal regarding standardisation of the way cleanup templates are laid out. Please add comments and suggestions there. Chris Cunningham (not at work) - talk 15:13, 13 December 2008 (UTC)

Ambox/float overlapping in Opera

Resolved.

As seen on this article, the ambox ends up overlapping a Wiktionary float (evidently only in Opera). This problem is tied to the order of templates inserted in the article, does not occur with a Imbox, and appears not to affect the second ambox in an article (for whatever reason). Can whatever makes Imbox work correctly be ported to ambox? – 74 17:41, 5 February 2009 (UTC)

First of all: Thanks for such a clear bug report.

Secondly: Yes, that is a known problem with the current margin top and bottom code used for the {{ambox}}. Ambox has the same problem with all kinds of right and left floating objects, such as images and other boxes.

The amboxes stack tightly on top of each other and that causes problems with the border and margin between them. We discussed this at MediaWiki talk:Common.css/Archive 5#Ambox and cmbox margin problems last summer and tested a lot of code versions, without finding a solution that worked perfectly in all browsers. Unfortunately some time after that discussion someone changed the code to one of the more broken versions. Unfortunately I have been too busy elsewhere to handle that. The current broken version of the code is in MediaWiki:Common.css and looks like this:

table.ambox {            /* 10% = Will not overlap with other elements */
    margin: -1px 10% 0px;    /* -1px = Single border between stacked boxes in all browsers */
}

It's on my to-do list to investigate that again.

The solution I prefer would be to do like we did with the {{cmbox}}. It used to stack tight and have the same problems. But we changed it to have some space between when stacked, just like all the other mboxes. Thus no problem at all. Here is an example how it would look with amboxes:

I think that looks better than tight stacking. And as was the real reason for the change in {{cmbox}}: It makes it clearer where the border between two boxes are when there are big boxes with lots of text in.

--David Göthberg (talk) 02:27, 6 February 2009 (UTC)

Alright; sorry to bother you with a known bug (I admit I didn't make it very far searching through the archives). For what (little) it's worth, your proposed solution sounds good to me. Thanks for the explanation (and all the hard work too!). – 74 03:06, 6 February 2009 (UTC)

No, it is I who should be sorry that we haven't fixed this yet, in spite that we have known about it for such a long time.

We are now discussing and testing possible solutions over at MediaWiki talk:Common.css#Infobox / ambox. And which of the two possible solutions we should choose. More opinions are welcome over there.

--David Göthberg (talk) 02:56, 31 March 2009 (UTC)

Done - We have now fixed this by adding the following code to MediaWiki:Common.css:

table.ambox {
    margin: 0px 10%;
}
.ambox + .ambox {   /* Single border between stacked boxes. */
    margin-top: -1px;
}

All glory go to TheDJ who came up with the solution.

--David Göthberg (talk) 15:05, 12 April 2009 (UTC)

Need it be so tall?

For templates with one line of text such as {{cleanup}}, there is twice as much empty space in the box than there is text. Is this level of padding really necessary? Skomorokh 04:10, 10 February 2009 (UTC)

First of all, if you only see one line of text in {{cleanup}} then you are using a higher screen resolution than most users. Most of us see two lines in that box.

Secondly, what causes the height your seeing is the size of the image in the box. Ambox only uses 2px of padding above and below the image. Decreasing to 1px or 0px looks really bad. 2px really is not much padding. And making the image smaller would make it too small, especially for people like you who use high screen resolutions.

So, try lowering your screen resolution to say 1024x768 and you'll see why these boxes are designed the way they are.

--David Göthberg (talk) 10:00, 10 February 2009 (UTC)

It's also worth pointing out that even on high-res displays {{cleanup}} is rather an exception; most ambox templates use two lines. I'd considered adding wording to {{cleanup}} to take it to two lines but didn't think it was appropriate in the end. Chris Cunningham (not at work) - talk 22:53, 10 February 2009 (UTC)

Metadata class

This discussion was moved here from David's talk page since it probably also will be interesting for other users. --David Göthberg (talk) 10:04, 25 February 2009 (UTC)

Hello, I'm an admin in vi.wiki, could I ask you a question? I saw that in mbox templates, there is metadata param in class. It works well in en.wiki but when I import it to vi.wiki, it didn't show up until I deleted that parameter. Can you tell where should I do to make metadata class work in vi.wiki? Please notice me if you respond, thank you. Vinhtantran (talk) 17:02, 9 January 2009 (UTC)

Hi Vinhtantran. Well, the noprint/metadata classes are (or at least were when I last checked some months ago) a mess here at the English Wikipedia. And those classes are not standardised across the different language versions of Wikipedia. What the metadata class here at the English Wikipedia currently does is to hide whatever is marked with it when a page is printed to paper. But that wasn't even its original meaning here. And as you noticed it has different meaning on different Wikipedias. (So, that means that article message boxes built with the ambox is not visible when printing a page here at the English Wikipedia. We have decided that the article message boxes are unnecessary information when printing to paper, so we want to save people some paper and printing cartridges.)

So for now my best advice is to simply remove the "metadata" class from the {{ambox}} when you port it to another language Wikipedia, just as you say you already did.

--David Göthberg (talk) 10:04, 25 February 2009 (UTC)

Left-aligned small ambox

We are about to add a "small=left" parameter that will make {{ambox}} show as a small left-aligned box.

See Template talk:Expand-section#More subtle style for the style discussion.

See Template talk:Mbox#Left-floating small box for the technical discussion.

--David Göthberg (talk) 05:06, 10 March 2009 (UTC)

On Commons

If anyone would like to help a similar transition I'm organizing on Commons, feel free to help. ViperSnake151 Talk 02:38, 8 April 2009 (UTC)

Background

What, if any, consensus has been established in general, about which messages in article space should be using one of these standard boxes? Is it recognised that some messages are not suitable in this format?

I'm just looking for some background as I just had an edit reverted on Template:Expand list, which I had converted to a small ambox. Thanks, — Martin (MSGJ · talk) 08:20, 26 April 2009 (UTC)

Don't know if there is a standard. But I do agree that this edit was not an improvement. From a small message to readers it changed to a bigger in your face navbox. Garion96 (talk) 09:09, 26 April 2009 (UTC)

I don't think there's anything like a consensus here. Myself, personally, I think the change was for the better. By putting editorial remarks in message boxes, we make clearer the distinction between something that's part-of-the-article (like a "see also" link) and something that's about-the-article-itself. Others obviously disagree. There's always been some dynamic tension on Wikipedia over the prominence of editorial remarks. At one end you have people who want them to be obvious, with the argument that it's part of the wiki nature to invite everybody to be an editor; at the other end of you have people who want them hidden except for active editors, with the argument that the primary purpose of the project is to be an encyclopedia, and it doesn't serve the reader to wallpaper articles with notices. With other positions along the spectrum between. I suspect we'll never have universal agreement on this. —DragonHawk (talk|hist) 17:23, 26 April 2009 (UTC)

True, I am more in the camp of "doesn't serve the reader to wallpaper articles with notices". :) But besides that, this tag looks to be more in line with a stub notice. Which also is not in a navbox. Garion96 (talk) 17:52, 26 April 2009 (UTC)

Category proposal

Please see Wikipedia:Village pump (proposals)#Message box categories. Thanks. Dragons flight (talk) 06:58, 3 June 2009 (UTC)

Banner blindness.

Please see Wikipedia talk:Template messages/Archive 5#Banner blindness. It's not meant for deletion notices which stand out pretty well. -- Jeandré (talk), 2009-07-02t18:35z

Vertical space

Everywhere I see these boxes they butt up unpleasantly with infobox titles; example. ¦ Reisio (talk) 09:50, 8 July 2009 (UTC)

Please provide more information. Specifically, what browser you are using. —TheDJ (talk • contribs) 10:28, 11 July 2009 (UTC)

Worst in Firefox. ¦ Reisio (talk) 23:19, 8 August 2009 (UTC)

Improving accessibility for visually impaired

As discussed in WP:ALT #When to specify, purely decorative images should not link to other web pages, because the links confuse screen readers. But consider this call to {{ombox}}:

{{ombox|text=This article is undergoing '''[[WP:PR|peer review]]'''.}}

Currently, it generates this:

This article is undergoing peer review.

which causes a screen reader to say something like "image eye em bee oh ex notice dot pee en gee This article is undergoing peer review". The template should generate this:

This article is undergoing peer review.

which causes a screen reader to skip the (now purely-decorative) image and say something like "This article is undergoing peer review" instead, which is much better. (The difference is that the circled-"i" does not link to Image:Imbox notice.png.)

The fix suggested in WP:ALT is to add "|link=" to decorative images, such as the icons that the article message box templates generate. I have tested this in a simple change to Template:Ambox/core/sandbox and can easily implement further changes to the other article message box templates. Template:Ambox/doc suggests bringing up changes like these on this talk page first, though; hence this thread. Eubulides (talk) 07:44, 11 July 2009 (UTC)

I think a better idea would be to hide the links from screenreaders instead of not linking them because images need to be attributable and easy to find; unlinking them may be a GFDL violation. We should instead add speak: none; to the images. — Edokter • Talk • 13:08, 11 July 2009 (UTC)

Unfortunately, all indications are that screenreaders don't take CSS much into account unfortunately. Graham87 has verified this repeatedly in the past. —TheDJ (talk • contribs) 14:37, 11 July 2009 (UTC)

The images specified in these macros are all public domain, right? So there's no GFDL violation here. Eubulides (talk) 17:22, 11 July 2009 (UTC)

Since anyone can create his own box with an image, that is not a given. Also, it is more about giving people a way to VERIFY the status of an image. —TheDJ (talk • contribs) 19:00, 12 July 2009 (UTC)

There's no GFDL violation in the way the template is normally used.
This template is just a tool. It's not the responsibility of this template to police all its uses. Otherwise, we'd have to remove images entirely from the the template (and remove the text as well). For example:

{{ombox|text=This [[File:Pepper's.jpg|20px]] article is the collaboration of many users.|image=[[File:Pepper's.jpg|40px]]}}

This call violates the copyright of the Sgt. Pepper cover twice, once in the text and once in the image. But that's not ombox's fault; it's the fault of the caller of ombox.

The primary audience of Wikipedia is readers, not editors. If there's a clash between making Wikipedia more convenient for editors to verify the status of an image, and making it more convenient for visually impaired readers to read the encyclopedia, we should do the latter. Naturally, we should try to do both. But it's not that hard for an editor to verify the status of an image even with "|link=".

Eubulides (talk) 05:55, 13 July 2009 (UTC)

On the technical side. I can't guarantee that this "link=" trick will continue to work throughout eternity. It is actual an accidental and unintended side effect. —TheDJ (talk • contribs) 10:28, 13 July 2009 (UTC) Bold text

` Nothing is forever, but "link=" works now. If something better comes up in the future, we can use that. In the meantime, "link=" is documented to work in the standard places (WP:EIS, WP:ALT) so we should use it. Eubulides (talk) 16:37, 13 July 2009 (UTC)

I know it works (i touched part of those changes not too long ago.), it's just that the behaviour of an empty link= is an unintended side effect. —TheDJ (talk • contribs) 18:50, 13 July 2009 (UTC)

It may have been an unintended side effect when the change was first installed, but many Wikipedia articles use this feature now, as it is highly useful for WP:ACCESSIBILITY. If this method of specifying linkless images is withdrawn despite the obvious backward-compatibility issues, surely there will be a different way of achieving the same effect, and we can use that instead. In the meantime we can use the feature that works now. Eubulides (talk) 21:06, 13 July 2009 (UTC)

Any reason not to do this?

This discussion has dried up, but is there any reason not to do this? In addition to the screen reader improvements, it would be less confusing to readers who click the linked images expecting them to go somewhere relevant (as is the standard behavior for the rest of the Web). If you look at the stats for the image description page of File:Imbox notice.png, it gets viewed on enwiki 400-odd times per day, presumably by people clicking it for help.

Most of the default images used in these templates are public domain, and it could be done quite easily for those while letting override images link normally. E.g., in Template:Ambox/core, by changing:

    | speedy     = Ambox speedy deletion.png
    | delete     = Ambox deletion.png
    | content    = Ambox content.png
    | style      = Imbox style.png
    | move       = Ambox move.png
    | protection = Ambox protection.png
    | notice          <!-- notice = default -->
    | #default   = Ambox notice.png

to

    | speedy     = Ambox speedy deletion.png{{!}}link=
    | delete     = Ambox deletion.png{{!}}link=
    | content    = Ambox content.png{{!}}link=
    | style      = Imbox style.png
    | move       = Ambox move.png{{!}}link=
    | protection = Ambox protection.png{{!}}link=
    | notice          <!-- notice = default -->
    | #default   = Ambox notice.png{{!}}link=

I excepted Imbox style.png (the cleanup broom) as that is GPL. This sort of change would need to be done separately in the various ?mbox/core templates. • Anakin ^(talk) 09:32, 23 October 2009 (UTC)

I agree that this sort of change should be done. However, the images also need to be marked with an empty |alt=, as recently-installed Mediawiki software requires this; see WP:ALT #Purely decorative images. The lone image that's currently GPLed, File:Imbox style.png, can be replaced by some other broom without a license issue (File:Edit-clear.svg, say). I've implemented this revised suggestion with this simple sandbox edit and have tested it in the test cases. As far as I know this addresses the concerns mentioned above; let's install it. Eubulides (talk) 21:16, 23 October 2009 (UTC)

Not done for now - First you need to get consensus, before you use the {{editprotected}} template (that is calling in an admin to implement your changes). Your code is "correct", but you removed the well established File:Imbox style.png

instead using File:Edit-clear.svg

You need to first get consensus to use that image. I think the old image looks slightly better when used in the mboxes.

And there is more to this: Then we also first need to locally upload and protect the new image, otherwise you open up a major high-risk image for vandals to edit.

Note: We might perhaps locally upload the new image under the old name File:Imbox style.png. So for future reference, at the time I write this File:Imbox style.png is just a tweaked copy of File:Broom icon.svg

--David Göthberg (talk) 22:23, 23 October 2009 (UTC)

OK, uploading and protecting would also have to be done as part of the change. As far as the main issue goes, is the small improvement in the visual appearance of that tiny broom worth really worth the WP:ACCESSIBILITY cost of making lots of pages harder for visually-impaired readers to access? If aesthetics are really that much of an issue, I can make a new public-domain broom of my own, which is close enough to the Ambox broom to satisfy the aesthetic issue, while not infringing its copyright. If that suggestion is what it takes to make this happen, could you please explain exactly why you think the old image looks better? I don't want to go to all that work and then be rejected again. Eubulides (talk) 22:37, 23 October 2009 (UTC)

And here is the message that I was typing while Eubulides did his editprotected request above (evil editconflicts!):

First of all, we can't unlink images that are non-PD. Images that are GPL or similar must have attribution, or we break copyright law. The mbox meta-templates use some non-PD images, and the message boxes built with the mbox meta-templates use many non-PD images. However skipping attribution only when viewed by impaired users is probably legal, since most civilised countries allow exceptions for impaired people.

Secondly, we have another solution. We can create the nospeak CSS class, see MediaWiki talk:Common.css/Archive 8#Nospeak class. According to the lists I have seen, many screen readers support that.

TheDJ: In the old discussion over at Common.css you said that Graham87 said it doesn't work. Well, did he test several screen readers? And did he test with the full belt and braces nospeak class? (That class as I suggest it use all five standard ways to suppress speech at the same time.) As I said, according to the lists I have seen that class should work for many screen readers. There are also some more things to keep in mind:

If we start using the nospeak class, then it will be easier for our devs or others to make a server based filter that makes it possible to remove all items that should not be spoken, much like the "Printable version" you see in the menu to the left.
We admins could even code up a javascript gadget that removes all nospeak marked items from the page. Thus allowing logged in users to click "Hide all items that should not be spoken" under "My preferences - Gadgets". I hope many screen readers at least support javascript.
If major websites like Wikipedia start to use the standardised speech suppression methods, then more screen readers will also start to support them. We do have the power to make software support us. Several times bugs have been unfixed in browsers for years, until we pointed out that the bugs become visible when reading Wikipedia, then the browser coders fixed the bugs quickly.
If we add the standardised speech suppression methods, then users have the choice of using those screen readers that work correctly.

--David Göthberg (talk) 22:41, 23 October 2009 (UTC)

Eubulides: Give me some time to think about this. It seems to me your solution is the cleanest, simplest and best working one, for the default images. And your suggested broom icon is pretty good, so I don't mind it that much. I just have a very slight preference for the old image.

Unfortunately this doesn't solve it for many of the message boxes that are built using the mbox meta-templates. Since those message boxes use their own images, many of which are non-PD. Then we still could have good use of the nospeak class.

But give me some day to think about this.

--David Göthberg (talk) 22:58, 23 October 2009 (UTC)

Thanks for considering it. I agree with you that the old broom is a bit better, which is why I'm willing to go to the work of creating a new one that's more like it. (I'm no artist, by the way; this will take me about 100 times longer than a commercial artist will take, but accessibility is worth it to me.)
I also agree that it doesn't solve the problem for other images, just for the builtin ones. But one step at a time.
I like the idea of getting nospeak to work as a longer term goal. That would be a very useful tool in the accessibility arsenal. However, I expect that will take some time to test, and that it may have some problems for message boxes, as it wouldn't work for text browsers like Lynx.
A simpler fix for the licensing issue would be to modify the licensing info that is linked-to at the bottom of Wikipedia article, so that it says something like 'The license info for an image whose URL ends in "/NNNpx-NAME" can be found in "http://en.wikipedia.org/wiki/File:NAME".' This would suffice for the large number of images that are licensed under CC-SA 3.0, which seems to be the preferred license for Wikipedia nowadays. CC-SA 3.0 is deliberately generous in allowing us to credit attribution in "any reasonable manner", and this would qualify. Doing this would solve some licensing hassles not only here, but elsewhere.

Eubulides (talk) 23:24, 23 October 2009 (UTC)

Eubulides: The new broom is okay, no need to create another one. I just meant that I have a slight preference for the older broom image. But I think you should announce your suggestion and then wait a while, since these images and the functionality in the mboxes have been established through lengthy discussions and time. And any changes here literally affects millions of pages.

The nospeak class I am suggesting is already tested in several browsers. It does no harm at all, so we could deploy it pretty much right away.

Regarding your edits to the ambox documentation: I have now reverted you twice. Please stop. You unlinked non-PD images, thus breaking copyright law. (Funny note: You even unlinked an image for which I am one of the creators and copyright holders, thus in theory I could now sue you. :))

And you are referring to Wikipedia:Alternative text for images#Purely decorative images, which is marked with "This guideline is a part of the English Wikipedia's Manual of Style". But the Manual of Style should be based on wide consensus, but you wrote much of that page yourself. (And you used the shortcut WP:ALT in the documentation, instead of the full page name. That is not user friendly. See Wikipedia:Shortcut#Readability about that.)

And the images in the mboxes are not purely decorative. They convey several meanings. For instance, together with the border colour of the box their colour and looks show the level of urgency, something that the text in the box often doesn't state.

--David Göthberg (talk) 00:54, 24 October 2009 (UTC)

It's fine to let the issue simmer here for a while; there's no rush.
Sorry, I didn't realize that you had reverted me even once, and I thought those images were PD. I ssume it's OK if I insert the part of the changes that affect only PD images?
Modifying the licensing info, in the way that I proposed in my previous comment, would fix the notification issue in a far simpler and more-general way; but that would require consensus elsewhere, not here, and right now I'm just looking for a solution here.
I did write most of the words currently in WP:ALT #Purely decorative images, but that section is based not only on Wikipedia consensus; it is also based on widespread consensus in the Web community. See, for example, section H67 of Caldwell B, Cooper M, Guarino Reid L et al. (eds.) (2008-12-11). "Techniques for WCAG 2.0". W3C Web Accessibility Initiative. {{cite web}}: |author= has generic name (help)CS1 maint: multiple names: authors list (link) I don't know of any reliable source that seriously disputes the consensus about purely decorative images not needing alt text.
If the images in the mbox convey useful information that is not in the text, then we need to either (1) supply alt text that conveys this info, or (2) omit the alt text and link, and modify nearby text to convey this info. Both solutions would fix the WP:ACCESSIBILITY problem of the current template. I mildly prefer (2) but (1) is clearly fine as well.

Eubulides (talk) 01:31, 24 October 2009 (UTC)

I have edited the documentation to discuss alt text; in this edit I took care so that every image whose license requires attribution continued to be linked in the same way as before. This addressed the most pressing comment above. The only remaining issue directly relevant to the proposed patch is the comment "the images in the mboxes are not purely decorative". If it's important that their info be put into text, that's easily done as well; see simple sandbox edit B. I mildely prefer the even simpler sandbox edit (mentioned above) that marks the images as decorative, because I don't think the info they provide is important enough to bother the visually impaired reader with; but either sandbox edit will fix the template so that it conforms to the W3C guidelines, and so either is good enough and is a real improvement over the existing situation. Eubulides (talk) 05:53, 28 October 2009 (UTC)

Eubulides: I will have to revert your edits to the ambox documentation again. You should not incite template programmers to perform copyright violations. The majority of the icons used in the message boxes built with {{ambox}} are not public domain, instead they have licenses that require attribution, so the images have to be linked. Also, it is rude towards those who made the images to not attribute them. Thus the examples in the documentation should mainly show the code for linked images.

Instead what I think we can do is to add a section explaining that if an image is public domain, then it is a good thing to unlink it. And explain why that is a good thing. And you can of course recommend that people try to find public domain images to use. And in that section show the code used to unlink the images.

Regarding the warning level colours and the information the images convey: No, I don't think that we should feed extra text to the listening users about that, they are already enough informed and/or disturbed by the text in the boxes. After all, what most of them want is to read the articles, not listen to complaints about "This article needs wikifying". And since they can't skip by the boxes as easily as we seeing readers then those boxes are much more annoying to them than to us. Actually, for that reason we have marked the ambox with the "metadata" class, so that it is possible to make skins, gadgets and personal styles that filter away the amboxes altogether. Since we think that for most listening users the boxes probably do more bad than good. (I'm sorry to say that such a skin or gadget have not yet been built.)

Anyway, what I reacted against in my earlier comments is that you call our images "purely decorative", since that is untrue and slightly condescending. To us seeing users they are a good extra addition, and people spend a lot of work on finding, making and discussing good images.

And regarding your code in the sandbox: As I mentioned above: Yes, we should unlink the default icons that are public domain. And I agree that we should change to the broom image you suggested File:Edit-clear.svg

so that we can unlink that default image too. However, that will be a very visible change of a long established icon, and will be visible on lots of pages, so I'd like at least some more editor to agree on this. Anyone reading this?

--David Göthberg (talk) 07:18, 28 October 2009 (UTC)

We already have three editors (you, me, and Anakin) who agree that unlinking the default images is a good thing. I seriously doubt whether anyone much cares whether one sweeping-broom image is so much better than the other one that we should mess up support for visually impaired readers in order to get it.
I don't see how the documentation I wrote "incites" people to ignore copyright: it talks about how to do public-domain images, and how to do non-public-domain images, and expresses zero preference about which is better.
I see no evidence that "The majority of the icons used in the message boxes built with {{ambox}} are not public domain"; on the contrary, if you look at the examples that are currently in the documentation (without my edits), 16 uses (including the builtin uses) are public domain and 6 are not. Even if we ignore the uses of images built into the template, 5 are public-domain and 3 are not.
As a practical matter, once accessibility is taken into account, it is better to use public-domain images, as they result in a more-accessible interface (because the non-public-domain images require links that get in the way of accessibility). So, come to think of it, perhaps the documentation should recommend public-domain images. For clip art (which is what these images are, mostly), public-domain is often the most appropriate license anyway.

Eubulides (talk) 08:02, 28 October 2009 (UTC)

I quietly endorse the proposed changes, too. (And also any proposals to reduce the recommended size of the mbox icons.) -- Quiddity (talk) 21:00, 28 October 2009 (UTC)

Is it possible for now to just unlink the ones that are PD, and place a request with the graphic lab to produce PD versions of the remaining icons?--Father Goose (talk) 09:25, 29 October 2009 (UTC)

Yes that could be done, but the result wouldn't differ in any significant way from the simple sandbox edit already proposed, as the PD version of the (one) remaining icon couldn't look exactly like the GPLed version (due to copyright concerns), and the simple sandbox edit already substitutes a broom

that looks very much like the existing broom

without being identical to it. If there's any specific objection to the PD broom that can easily be fixed (want it slanted the other way? that's easy), but as no specific objection has been given, it's good enough. Eubulides (talk) 20:19, 29 October 2009 (UTC)

I tried it in a box and I think the new broom image looks best as is, slanted to the left. I have uploaded File:Edit-clear.svg

and protected it locally here at the English Wikipedia, so it is ready for use in the {{ambox}}.

Eubulides: In response to your dotted message above:

You seem to forget that {{ambox}} is a meta-template. {{ambox}} should normally not be used directly on articles. Instead it is used to build article message box templates such as the ones you see listed in Wikipedia:Template messages/Cleanup. Many of those message boxes use their own more specific images. And many of those images are not public domain. But you changed all the examples in the ambox /doc to show "|link=|alt=". And we know from experience that when people use a meta-template to build a box they often cut and paste the example code as is. Thus with your examples most of the new message boxes being built would contain "|link=|alt=", thus causing massive copyright infringement. (Boxes built with the {{ambox}} is being used on 638,000 pages so far.)

So I strongly recommend that we do not use "|link=|alt=" in most of the examples, but instead add such an example in a separate section. The section could be named say "Accessibility", and perhaps be placed between the sections "Other images" and "More examples". And add a proper explanation that only when an image is public domain can it use "|link=|alt=". And do avoid the use of the expression "purely decorative" since it is not true and it is rude. Compare that to the text that you used:

Often these images are purely decorative, in that they do not add significant useful information to the template, and so they should be marked with "|link=|alt=".

For accessibility by the visually impaired, icons whose licenses require links should use an |alt= parameter specifying alt text that describes the icons, instead of using "|link=|alt=".

Only stating "whose licenses require links" fails to tell what licenses that is. Again, public domain is the keyword here.

By the way: When using only the "|alt=" and not the "|link=", do the screen readers then speak the URL or not?

--David Göthberg (talk) 01:21, 30 October 2009 (UTC)

With |alt=alt text but without |link=, screen readers speak the alt text, not the file name.
I reworked the documentation to try to address the above criticisms. This edit did not replace any images with public-domain images: instead, it added alt text for images that were not public domain. The change also describes when links are needed. As it is not correct to say that only public-domain images can use "|link=|alt=", it defers to WP:ALT for the gory details.
The phrase "purely decorative" is a standard technical term used by the W3C in its accessibility documentation. It is not intended to be rude. The reworded documentation attempts to make this clear.
Could I ask that any further problems be fixed in the new version, rather than having these changes be reverted again? These repeated reverts make editors' work here much harder than it should be. It is frustrating to spend way, waaay more time defending code and documentation than actually coding templates and documenting them.
Regardless of our disagreements about the documentation, it appears that there's a strong consensus to make the simple sandbox edit to the template.

Eubulides (talk) 06:30, 30 October 2009 (UTC)

Reawakening this before it stalls for another four months. We seem to have unanimous agreement that unlinking the PD images is either a good thing or a harmless thing, and I like those odds. I've no preference on brooms. Does an admin want to just do it? • Anakin ^(talk) 20:28, 4 November 2009 (UTC)

{{editprotected}}

Yes, the above discussion establishes a strong consensus for the simple sandbox edit. Please install this edit. Eubulides (talk) 20:40, 4 November 2009 (UTC)

Done — Martin (MSGJ · talk) 22:53, 4 November 2009 (UTC)

The other templates have an almost identical set of images. Can similar changes be made at:

Template:Tmbox/core, Template:Ombox/core, and Template:Cmbox (all default images PD except for the broom) Done and
Template:Imbox (all default images PD except for the broom and featured article star)
Template:Fmbox (all default images PD) Done

? • Anakin ^(talk) 23:08, 4 November 2009 (UTC) I should have re-enabled the editprotected template. • Anakin ^(talk) 23:49, 4 November 2009 (UTC)

Done most of them. Do you have an alternative for the featured star? — Martin (MSGJ · talk) 16:08, 6 November 2009 (UTC)

All variations on that star are marked GFDL. Better just to leave it linked and unlink the others. That's okay though, because it's quite an important image. It should perhaps have better alt text though, "Gold star" rather than "Imbox featured". • Anakin ^(talk) 20:15, 6 November 2009 (UTC)

Image

Is there a problem with the ambox style image ? It doesn't show up on, for example - http://en.wikipedia.org/wiki/Juan_del_Encina -- Beardo (talk) 14:06, 31 August 2009 (UTC)

It was accidentally deleted on Commons. Should be fixed now. — Edokter • Talk • 15:40, 31 August 2009 (UTC)

Microsoft Ambox?

Has anyone noticed the new look of the notifications in Windows Update (the inbuilt version in Vista/Windows 7/etc.)? Looks... familiar. :-) I'd post a picture, but this being Wikipedia, it will be deleted. Off-site pics, then: [1] [2]. And here's how it used to look: [3] [4]. And while we're at it: [5]--Father Goose (talk) 07:16, 22 October 2009 (UTC)

Well spotted !! It sure looks like an ambox —TheDJ (talk • contribs) 08:41, 22 October 2009 (UTC)

We should sue! Joking aside, design aspects also fall under CC, and require attribution, do they not? — Edokter • Talk • 12:01, 22 October 2009 (UTC)

Hilarious! Thanks for telling us Father Goose. Yeah, seems Microsoft have been copying us. Those sure are amboxes, even though their colour scale is somewhat different. Just goes to show what I have been telling my friends: As Wikipedia editors we wield great power, since what we write and create are read and viewed by so many.

--David Göthberg (talk) 19:42, 22 October 2009 (UTC)

Ha! PlagiarismFlattery will get them nowhere.

Based on User:Flamurai/TS/blanca, I've let Flamurai and Sparkit know about this thread. -- Quiddity (talk) 20:59, 22 October 2009 (UTC)

Knowing Microsoft, though, they could have stuffed attribution deep within the dank dungeons of some obscure EULA agreement or something. Still, pretty funny! =D 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 20:28, 23 October 2009 (UTC)

Realistically, the design element they copied is too basic for us to have any unique claim to it: a saturated color bar on the left side of a box with a thin gray border. The old Windows Update style already had a thin gray border and the same color scheme (red, yellow, green), and even had a color-matched icon on the left side of the color bar (which was at the top and less saturated).

But the ambox style has become one of Wikipedia's signature design elements, and it definitely seems to be catching the eye of other designers.--Father Goose (talk) 23:19, 23 October 2009 (UTC)

Here's someone using a variation on it for blockquotes: http://raincoaster.com/2008/03/18/steve-jobs-cthulhu/ --Father Goose (talk) 21:27, 8 December 2009 (UTC)

Ambox/sandbox/doc

I just discovered something weird: Template:Ambox/sandbox/doc. That's an old separate /doc page for the /sandbox version of {{ambox}}. Nowadays the doc system instead automatically displays Template:Ambox/doc also when on the /sandbox. I have no memory of that page but I see I was one of the editors of it. That old separate /doc page is no longer in use, and as far as I can see the edit history of it has no value, it was just a copy of the main doc page. (Why did we maintain a copy like that? Very weird.) I also see that some editors still waste time on updating it, apparently they don't realise that it isn't used anymore.

So I intend to delete Template:Ambox/sandbox/doc.

--David Göthberg (talk) 20:27, 18 January 2010 (UTC)

I have now added

{{db-t3|~~~~~|Ambox/doc}}

— Martin (MSGJ · talk) 20:37, 18 January 2010 (UTC)

CSS class

Would it be reasonable for the ambox template to take a parameter to specify an additional CSS class for the wrapper table? So another template might call ambox with the class=foo parameter, and then the table generated would have css class foo added to it. This would make it easier to restyle the ambox in user CSS on a template by template basis. — Carl (CBM · talk) 14:57, 9 February 2010 (UTC)

I am opposed to adding the "class" parameter to the {{ambox}}, here's why:

We have had many requests about adding a "class" parameter, most of them with the purpose of restyling the boxes so every user sees the difference. But one of the main points of the {{ambox}} and its sister templates is standardisation.

I see that your request is different, it seems you want the "class" parameter so you can feed the name of the template you build with an ambox, thus making it possible in CSS to know which template it is. That is similar to how we use the {{fmbox}} in system messages: We usually feed the system message's name as the CSS id and class, so we can detect those system messages in javascript and CSS.

You want this for styling in your personal /monobook.css, which would be okay but doesn't seem especially important. But we know from experience that the "class" parameter will be abused by editors feeding classes that change the appearance for everyone or even break the box flow of the message boxes they build.

--David Göthberg (talk) 17:19, 9 February 2010 (UTC)

No problem; I can achieve the same thing (with not much more more effort) via javascript. The class parameter was just the easiest way. — Carl (CBM · talk) 18:59, 9 February 2010 (UTC)

Conversion needed

Could someone convert {{Non-free currency-EU coin national}} to properly use {{imbox}}? Thanks in advance. MBisanz ^talk 00:57, 18 April 2010 (UTC)

MoS naming style

There is currently an ongoing discussion about the future of this and others MoS naming style. Please consider the issues raised in the discussion and vote if you wish GnevinAWB (talk) 20:49, 25 April 2010 (UTC)

Use vector images when possible

{{Editprotected}} I guess the boxes should use vector images when availble. Here is the hint: {{ambox}} could use Ambox important.svg instead of Ambox content.png. Artem Karimov (talk | edits) 14:22, 18 September 2010 (UTC)

Not done. When Ambox was created, it was decided to use PNG renderings of those SVG images, in order to have more control over the size and render quality, and also to be able to protect the used images to prevent vandalism. — Edokter • Talk • 14:34, 18 September 2010 (UTC)

"Expand" templates

Moved to Template talk:Expand

– Subsection is Type --Tothwolf (talk) 09:48, 13 November 2010 (UTC)

Shouldn't templates like {{expand}} be orange instead of blue? The question was raised at Wikipedia:Templates for discussion/Log/2010 November 9#Template:Incomplete. Tijfo098 (talk) 18:14, 10 November 2010 (UTC)

I've replied at the TfD to this question. --Bsherr (talk) 23:14, 10 November 2010 (UTC)

I am aware of no templates closely-related to {{expand}} being classified as type=notice (blue), but a large number in the relevant category of WP:TMC, and particularly WP:TMC#Expand and add, that are type=content (orange), so consistency would suggest that {{expand}} should be color-coded the same. Hrafn^Talk_Stalk^(P) 09:56, 12 November 2010 (UTC)
- {{Expand}} is not a "cleanup" template, however. --Tothwolf (talk) 12:56, 12 November 2010 (UTC)
  - It is certainly a part of "Expand and add", which is taken to be a subset of "cleanup". If it isn't cleanup, then which subcategory of WP:TM does it belong in? Hrafn^Talk_Stalk^(P) 15:33, 12 November 2010 (UTC)
Oppose Per my comment on this issue at Template talk:Expand. [6] I do not think these templates should be "orange" (content) instead of "blue" (notice). Nor do I think they should be converted to "yellow" (style). Templates such as {{Expand}} are not intended to be "Warning" templates, cautioning readers that something is wrong with the article or content. These templates exist solely to bring about article expansion from readers/editors, and not to "warn" or "caution" a reader. It is heavily ingrained into the English Wikipedia community that the orange colour used for "content" type templates is a warning that something is wrong with the article. Similar can be said of the "style" type (for example, {{Cat improve}}), but it is treated as less severe than a "content" type. There is nothing at all wrong with templates such as {{Expand}} using the "notice" type. --Tothwolf (talk) 12:30, 12 November 2010 (UTC)

This isn't the appropriate place for the RfC. This issue is not a Manual of Style issue. It's an issue concerning this specific template, and substantial conversation has already begun on the template talk page. The RfC, if desired, should be there. --Bsherr (talk) 15:09, 12 November 2010 (UTC)

No it is not "an issue [only] concerning this specific template" -- it also concerns {{Expand section‎}}, discussion of which was redirected here from Template talk:Expand section‎. I really wish people would quit the musical chairs. Hrafn^Talk_Stalk^(P) 15:33, 12 November 2010 (UTC)

Yes that's true. But the outcome of this RfC does not propose to change the Manual of Style, so an RfC here is not the right place. Significant discussion has already occurred at Template talk:Expand. But if that's too specific to one template, the discussion should occur at WT:TEMP, not here. While a discussion was already underway at Template talk:Expand, the proposer went forum shopping to this page, where there was no existing discussion, and started the RfC here. It forces everyone to repeat comments already made at Template talk:Expand. --Bsherr (talk) 17:08, 12 November 2010 (UTC)

I would point out that your proposal does in fact "propose to change the Manual of Style" -- specifically to expand the blue/notice category to include the unrelated templates that "Merely suggesting possible expansion". See also Tijfo098's comments here and here, which seem to indicate that he views this as an adjustment to this MOS. Hrafn^Talk_Stalk^(P) 08:06, 14 November 2010 (UTC)

Add functionality to ambox

Most uses of {{ambox}} now include a call to Template:Dated maintenance category. I think it would be neater if we centralised the code and added some parameters to ambox to support this.

Also, most article message templates contain code to detect incorrectly substituted templates. This could also be added to ambox to avoid this duplication of code on each separate template. — Martin (MSGJ · talk) 20:15, 13 May 2010 (UTC)

No objections here, sounds like a positive move all around. -- Quiddity (talk) 21:09, 13 May 2010 (UTC)

I am starting to work on this idea in the /sandbox. — Martin (MSGJ · talk) 16:53, 9 February 2011 (UTC)

Okay, I've made some changes/improvements to the sandbox copy and invite comments.

New parameters {{{cat}}}, {{{date}}}, {{{all}}} and {{{undated}}} added to support categorisation for clean-up categories, so no need to call separate template {{DMCA}}.
Substitution detection at the meta-template, so no need for clumsy code on every template.
Automatically transclude documentation on template page.

— Martin (MSGJ · talk) 16:27, 11 February 2011 (UTC)

I realise that this is not a well-watched talk page, but I have implemented the proposed code and tried the new features out on a small sample of maintenance templates to check there are no issues. — Martin (MSGJ · talk) 17:34, 13 February 2011 (UTC)

Well no issues seem to have arisen. Would there be support for trialling the new functionality on more templates, say about 30? — Martin (MSGJ · talk) 15:01, 16 February 2011 (UTC)

I am gradually adding the new functionality to more templates. — Martin (MSGJ · talk) 11:18, 23 February 2011 (UTC)

Date parameter

Most templates which use a date also display this date in small italics after the message. I suggest we add this automatically at the meta-template level. — Martin (MSGJ · talk) 11:18, 23 February 2011 (UTC)

I have now implemented this. So if date is passed to ambox it will automatically display after the text. — Martin (MSGJ · talk) 17:17, 24 February 2011 (UTC)

And now the current date will be displayed on the template version, so it is clearer what the template produces. — Martin (MSGJ · talk) 17:36, 28 February 2011 (UTC)

Undated parameter

It seems that this functionality is not used as I have not encountered it anywhere. I am planning to remove this parameter from the template. Any template that is using it can code it separately. — Martin (MSGJ · talk) 17:58, 1 March 2011 (UTC)

I have now removed this parameter. — Martin (MSGJ · talk) 15:37, 4 March 2011 (UTC)

It would be good if we can achieve more commonality in category naming at the same time. The red-herring of starting all maintenance cats with "Wikipedia" and other historical artifacts have meant there are some anomolies. Also there is the vexed question of "All..." categories which are in many cases huge, and only kept the first time around because the bot that made suggestions used them - I wrote some python to make them unnecessary for that purpose but never heard back from the bot-meister. Now they have a champion in Fram, strangely enough. Rich Farmbrough, 21:29, 4 March 2011 (UTC).

Please keep to this issue and not personalise, eh? The "all" categories might be good to axe if there is no real need for them. Can you give some background on which bot needed them, so I can dig around and make further enquiries? Can you explain the "red-herring", i.e. why do you feel the "Wikipedia" is better left off (if that's what you think)? — Martin (MSGJ · talk) 18:26, 11 March 2011 (UTC)

I will hunt around for the bot. It maintained a page which listed five each of some common cleanup categories.
The use of the disambiguating prefix "Wikipedia" was promulgated when we didn't have hidden cats. It was almost a pseudo-namespace, designed to distinguish (quite reasonably) between, say, "Tools" and "Wikipedia tools". The problems are (apart form being made less relevant with hidden cats) is 1. reflex disambiguation 2. Use/mention (e.g. Category:Wikipedia reliability is a content category). Rich Farmbrough, 14:53, 6 July 2011 (UTC).

The list is http://en.wikipedia.org/wiki/Wikipedia:OPEN, the bot is flBot, the user is User:fl and the code to render "All ..." categories un-needed is at http://en.wikipedia.org/wiki/User_talk:Fl/Archive_15#flBot_and_opentasks. Rich Farmbrough, 20:52, 6 July 2011 (UTC).

Clean-up templates

Here's my thoughts about where these have been/could be going - these have been developing for years and are based partly on reading lots of other editors comments over that time.

Fragmentation by type (subject)

By type. Items such as "Chemical importance" "ME importance" "Unreferenced Kent" etc...

Proposal: to bring them back into the fold by using a "subject" or "type" field in the main templates, as is currently used by some of the "Expert" family. Possibly more than one type (N_T) field should be used. I envision the granularity being at WikiProject level - and being implemented by those projects that want to use it. At the same time "Multiple issues" can be simplified so that it takes N_T type parameters and "expert" can be set as a date the same as all the others.

I have done a little work on the type field. TDMCA takes a type field and categorises accordingly. TUDMCA is for special cases like BLP unsourced where the name begins with a capital. I implemented a trial for "Notability" since it has a similar functionality already, and sandboxed a trial for Unreferenced. Rich Farmbrough, 17:37, 3 March 2011 (UTC).

This is an interesting idea and possible worth doing. In order to handle to categories automatically, they would have to all fit a naming schema. Otherwise things may become too complicated. For example, Kent-related articles lacking sources from January 2011 and/or All Kent-related articles lacking sources. — Martin (MSGJ · talk) 15:46, 4 March 2011 (UTC)

Yes indeed. I moved one small category of 12 items as part of the trial, and got reverted by an editor who, as far as I know, doesn't use the category. <insert smiley of your choice /> I also created a simple template for setting up the categories {{Clean-up type category}}, which can be called with no parameters provided the name of the category doesn't break the length limits of the string handling functions (and could probably use the functions that deal with longer strings before it is used widely). Clean-up subject category would probably be a better name, since that is what Expert uses and Ambox has a type parameter already. Rich Farmbrough, 21:29, 4 March 2011 (UTC).

Oh and I would not suggest cross categorisation by subject and date, unless it becomes obviously useful. Most of the existing categories are pretty small, the largest being the "in universe" categories, which I beleive run to several hundred max. The "notability" cats if they inherited parameter 1 as a default subject, as I tested, would give rise to larger categories, but still not huge. Rich Farmbrough, 21:29, 4 March 2011 (UTC).

I agree that "subject" is a better name than "type". Okay, so universal categorising by date and specific subject categorising without date. Do you have any information on the likely number of these specific subject versions of templates there are? Would you suggest using wrapper templates (e.g. {{Chemical-importance}}) rather than calling the main template with parameters (e.g. {{Notability|subject=chemical}})? If you go down the latter route, we might need some masking to stop unrecognised subjects being used, and this might become complicated. — Martin (MSGJ · talk) 18:33, 11 March 2011 (UTC)

Fragmentation by object

Swinging back and forth between {{XXXX|section and {{{XXX section|.

Proposal: to have one core template per type, all the rest being pass-through - thus:

Unreferenced - contains the code

Unreferenced section - calls Unreferenced with a parameter set to "section" Unreferenced table - calls Unreferenced with a parameter set to "table" Unreferenced lead - calls Unreferenced with a parameter set to "lead" Unreferenced caption - calls Unreferenced with a parameter set to "caption" Unreferenced inline - calls Unreferenced with a parameter set to "inline" Unreferenced stub - calls Unreferenced with a parameter set to "stub"

Of course these templates may all have redirects too. Possibly in addition to wording and categorisation the object parameter (likely to be default parameter 1) could drive the "small" parameter for ?mbox call. Rich Farmbrough, 17:37, 3 March 2011 (UTC).

Agree that this would be a logical way to deal with these. We could add an additional parameter to each of the templates that call ambox. This would allow the direct all {{XXXX|section or with the use of wrapper templates via {{{XXX section| as you suggest. I would favour a named parameter to an unnamed one and will give some thought to a suitable name. — Martin (MSGJ · talk) 15:04, 4 March 2011 (UTC)

This is one of the few cases where I prefer an unnamed parameter, as a matter of keeping what the editor types simple. Also I am agnostic about which (if either) the preferred style should be, without the pipe is simpler, but if the community prefers with then (ultimately) we should conform all pages to that (probably without wasting edits on it). (This is based on the same principle as the Internet RFCs, WP should accept a very wide range of input and treat it properly, but only produce a standardised product.) Rich Farmbrough, 16:55, 7 July 2011 (UTC).

What's best to do next

I don't know, if you are redesigning Ambox to have the kind of functionality of MI/messages it might be best to put most of this stuff in there. On the other hand the DMCA family is relatively explicit for template coders.

If I was doing this single handed I'd try the type parameter(s) on the rest of the places where there are separate templates at the moment, and then add the facility to the other templates if it all went according to plan. Since it's incremental, it's unlikely to cause any problems ... <irony alert /> ... one would think. The other part really is a tidying up exercise, and I would probably not get it done in a month of Sundays, since there's always more pressing matters, but I think it would cut the number of clean-up templates with operating code in them by maybe 60% or more.

My only other point on clean-up templates (and templates in general) is the proliferation of special cases which do not apply to Encyclopaedia space. This strikes me as a bad thing, since every invocation of a template has to check to see if it's being used in a demo context or if its category is being overridden, or if it has to pretend to be in a different namespace.

That's all for now. Rich Farmbrough, 17:37, 3 March 2011 (UTC).

Thank you for your ideas. The more I think about them, the more they seem to make sense. I'm replying separately above. The problem with the way you approached it previously, is that it was impulsive, not discussed or thought through properly, and created errors as a result which then had to be fixed. If we can talk through these ideas as we are now, hopefully we can get things right first time and save us some work :) Well, that's the theory. — Martin (MSGJ · talk) 15:12, 4 March 2011 (UTC)

Template loops

My code for automatically adding the {{documentation}} template on the template page has caused some problems when transclusions of the template are used as examples on the documentation page, because it causes a template loop. (Not a real template loop, but it seems the software stops checking the first time it reaches the same template.) So I am thinking about adding a parameter doc to stop documentation being displayed in these cases so that noinclude can be used in the usual way. Alternatively we could abandon this feature altogether, although it does seem convenient in 95% of cases. — Martin (MSGJ · talk) 18:51, 11 March 2011 (UTC)

I would like to remove this. Firstly on the principle of least surprise. Secondly it means every {{Ambox}} is doing an (otherwise) unnecessary test on the namespace etc., to save a few one-off keystrokes for actual template pages. Rich Farmbrough, 18:10, 22 May 2011 (UTC).

I don't have strong feelings either way but I think the namespace check will still be needed to populate Category:Article message boxes? In fact the check for adding the documentation is simply

{{#ifeq:{{FULLPAGENAME}}|Template:{{PAGENAME:{{{name}}}}}

which is hardly taxing. If this functionality is removed, there will be a lot of templates which need documentation adding manually again. — Martin (MSGJ · talk) 16:38, 23 May 2011 (UTC)

Streamlining the look of cleanup tags

There's a proposed update to the template's general-style and individual-content, being drafted at User:MuZemike/Cleanup proposal, and being discussed at the talkpage there, and at WP:VPP#Streamlining the look of cleanup tags. Please take a look, and provide some feedback. Thanks. -- Quiddity (talk) 19:46, 21 November 2010 (UTC)

I think that they (solely) reference WP:NPOV in places where other guidelines would be more pertinent. E.g. WP:STYLE would appear more pertinent to {{review}}. Likewise {{Essay-like}}. As far as overall look&feel, I think I like them. Hrafn^Talk_Stalk^(P) 03:17, 22 November 2010 (UTC)

Don't know if this is still being worked on, but it looks like a nice idea. I thought that having two separate parameters, e.g. {{{problem}}} (what is the problem) and {{{solution}}} (how should it be fixed) and let {{ambox}} control the formatting, e.g. put {{{solution}}} in smaller type on a new line, if that's what people think best. We should try to make the style consistent across all article message boxes. — Martin (MSGJ · talk) 16:59, 9 February 2011 (UTC)

RFC: restructuring of the Manual of Style

Editors may be interested in this RFC, along with the discussion of its implementation:

Should all subsidiary pages of the Manual of Style be made subpages_of WP:MOS?

It's big; and it promises huge improvements. Great if everyone can be involved. Noetica^Tea? 00:27, 25 June 2011 (UTC)

Duplicate /doc page showing up on template page

Please see: WP:VPT#Duplicate /doc page showing up on template page. Is there an error in the Ambox template that is causing this to happen? Thanks, --Funandtrvl (talk) 20:07, 11 July 2011 (UTC)

No it is a "feature" not an error ;) I will comment there. — Martin (MSGJ · talk) 11:10, 12 July 2011 (UTC)

Raw option

I've been thinking about a better way to code the {{multiple issues}} template. The current problems are

Two separate copies of the message being maintained, so that if one is updated the other one may not be;
Performance concerns of a large #switch mean that only the most used templates are added.

The best way to tackle both of these concerns may be to introduce a |raw= parameter to Template:Ambox which, if activated, would output the raw text of the message. This could be used by other templates (i.e. Template:Multiple issues) and keeps one central copy of the message. — Martin (MSGJ · talk) 14:23, 27 June 2011 (UTC)

But would add overhead to every call to Ambox. Rich Farmbrough, 20:50, 6 July 2011 (UTC).

Can you think of a better way to achieve the same outcome? — Martin (MSGJ · talk) 11:10, 12 July 2011 (UTC)

Yes. Rich Farmbrough, 01:11, 11 December 2011 (UTC).

Adding HTML IDs to article maintenance tags

I am proposing to add a unique HTML ID to all article maintenance tags. Please see Wikipedia:Village pump (proposals)#Add HTML IDs to article maintenance tags for discussion. — This, that, and the other (talk) 04:16, 13 August 2011 (UTC)

This edit request to Template:Ambox has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

There has been no opposition to the above proposal. Hence, I have implemented this proposal in Template:Ambox/sandbox and Template:Ambox/core/sandbox. Could an admin please synchronise the sandboxes to the main template pages? (Note that some other changes have been made to the core sandbox. This request is only for merging this change.) — This, that, and the other (talk) 02:00, 20 August 2011 (UTC)

Done by Sandstein and me. You may want to update the documentation. — Edokter (talk) — 22:40, 20 August 2011 (UTC)

Thanks for that. — This, that, and the other (talk) 08:11, 21 August 2011 (UTC)

Substitution checking

Please see the two sections I posted about this subject on Template_talk:Fix#Substitution_check and Template_talk:Fix#Method_of_substitution_check (one right after the other). I compare Ambox with Fix, asking a few questions and making a few suggestions. Debresser (talk) 00:53, 27 November 2011 (UTC)

Classes

Can we make these boxes take class parameters, as does {{Navbox}}? As a minimum, |bodyclass=? We could then, for instance, apply class="hlist", per WP:HIST Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:06, 28 November 2011 (UTC)

{{mbox}}, {{ambox}}, and {{tmbox}} already have the class= parameter. How likely is it for the others to contain lists? — Edokter (talk) — 11:49, 29 November 2011 (UTC)

Thank you. It's not documented in two out of three of those cases; I assumed all used the same core. is that not the case? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:06, 30 November 2011 (UTC)

No. Ambox, ombox and tmbox each have a core subtemplate, the others are straight tables, and mbox is an auto-switching template. There was at one point the intention to use one core template, but that idea was abandoned because it would have put too much stress on it due to transclusion count, which would have made updating it unworkable. — Edokter (talk) — 00:38, 30 November 2011 (UTC)

Andy, where do we use hlists? Rich Farmbrough, 23:48, 10 December 2011 (UTC).

[Late reply, sorry] Chiefly in navboxes, but anywhere a list is rendered horizontally, usually replacing lists separated with {{!w}}, {{·}}, or suchlike. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:25, 18 December 2011 (UTC)

Er.. I meant where in Amboxes? Rich Farmbrough, 20:31, 18 December 2011 (UTC).

I can't cite an example off the top of my head, but I've seen a few, which is what brought me here. I'll let you know when I next find one (if I remember!). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:47, 18 December 2011 (UTC)

The only one I've seen so far is {{WikiProject status}} & that's an ombox. -- WOSlinker (talk) 22:58, 18 December 2011 (UTC)

Is this page still needed?

The page as it stands appears to be an overview of the design rather than the usage of amboxes; since this is now complete, does this page still need MOS status? Can it be marked historical? Or would a rewrite serve it better? Grandiose (me, talk, contribs) 14:05, 1 October 2011 (UTC)

I think a rewrite may be in order. This page is useful as a background as to how these message boxes became standardised, but I think it should contain more about their usage. And perhaps it does not need to be part of the MOS now. — Martin (MSGJ · talk) 16:23, 7 June 2012 (UTC)

I am planning to move some or all of this talk page to Template talk:Ambox because it all discussion concerns that template. — Martin (MSGJ · talk) 16:23, 7 June 2012 (UTC)

Now done. — Martin (MSGJ · talk) 08:35, 8 June 2012 (UTC)

Template loop

Why did I get a template loop on Template:Contradict-other-multiple (see documentation)? I got one on Template:Contradict-other as well, and the only way to fix it was to stop using the automatic documentation (see this diff). Debresser (talk) 23:29, 26 November 2011 (UTC)

More generally: whenever I use the "name" parameter, then if there is a call to the template on its documentation page, it causes a template loop. Why is that, and can this be helped? Debresser (talk) 21:06, 10 December 2011 (UTC)

I understand that "Ambox" stands for "Article message box", and that documentation pages are in template namespace. But that seems like a small matter, and shouldn't be hard to fix. Debresser (talk) 22:33, 10 December 2011 (UTC)

Namespaces aren't the problem, as afar as I can see. Rich Farmbrough, 23:52, 10 December 2011 (UTC).

Yes this is curious. I wondered why I didn't get template loops with documentation before, I suspect some cleverness with parseing "noinclude". Probably this fails with the auto-doc. And to be frank, I don't like the auto-doc, clever though it is. The reason is that, on opening an auto-doc'd template my first instinct (which I have followed once or twice) is to add the standard documentation cliché. Then I get puzzled about the double-docs. It also makes hard work for, for example, interwiki bots. The same reasons, in fine, as for not putting {{Reflist}} in a template. Rich Farmbrough, 23:46, 10 December 2011 (UTC).

(Template loops are to stop a template calling itself infinitely, or indirectly a->b->a->b... Unfortunately they also stop well managed recursion, or at least make it harder - see my reverse family of templates.) Rich Farmbrough, 23:52, 10 December 2011 (UTC).

The template loops and the bot argument make a strong case against having this automated documentation feature. Wonder what MSGJ will have to say to defend this functionality. Debresser (talk) 00:21, 11 December 2011 (UTC)

I tested the Ambox code on Template:X5 calling it in Template:X6 in the simplest rudimentary form possible: {{#ifeq:{{FULLPAGENAME}}|Template:{{PAGENAME:{{{name}}}}} |{{Documentation}}}}. And there still is template loop inherent somewhere in the code. Using the name parameter and including a documentation page leads to a template loop. Now let's try and solve it. Debresser (talk) 18:09, 11 December 2011 (UTC)

Yep. Forget about X5 and X6, look at Template:X4. These parser functions return the main template name without the "/doc" extension when the documentation page is visible on the template page, so they call {{Documentation}} again, causing a template loop. Solution: the {{Documentation}} template must somehow be transcluded together with noinclude tags. How to do that, I don't know. Debresser (talk) 18:50, 11 December 2011 (UTC)

Alternative, undo the automatic {{Documentation}} functionality. Because it does not allow for examples on the documentation pages. But then we shall have to check for all usages of it, and add {{Documentation}} back in. Debresser (talk) 17:33, 31 December 2011 (UTC)

Shall we remove the auto-documentation feature? I thought it was good because it made the code shorter and simpler, but I see there are disadvantages. (However there are several templates which will need the documentation adding again if we remove it here.) — Martin (MSGJ · talk) 09:54, 3 January 2012 (UTC)

There is no fix for the template loop issue? If there isn't, then perhaps indeed remove the auto-documentation functionality. Debresser (talk) 13:22, 3 January 2012 (UTC)

Perhaps something with "<" instead of "<"? Debresser (talk) 12:07, 8 January 2012 (UTC)

I tried some things, but to no avail. Debresser (talk) 03:30, 15 January 2012 (UTC)

Yes I think so. Nifty coding, but to no avail in this case. Rich Farmbrough, 06:36, 19 January 2012 (UTC).

Okay I will remove the feature. I see it has created more bother than not. I've added a tracking category Category:Article message boxes with automatically transcluded documentation, which will contain the templates to be fixed. — Martin (MSGJ · talk) 20:22, 21 May 2012 (UTC)

I added the Documentation template to all non-fully protected templates there, and made other improvements to the those templates en passant. An admin will have to do the (so far 5) fully protected ones. Debresser (talk) 23:32, 21 May 2012 (UTC)

There is nothing about the automatic addition of the Documentation template in the documentation of Ambox itself. If I am correct, the 'name' parameter serves only for this issue, and can now be removed from both the Ambox code and the documentation. Debresser (talk) 23:40, 21 May 2012 (UTC)

Actually there is another use of the name parameter which may be useful. If the template is substituted accidentally, the warning message will say which template has been substituted and this may help when fixing up Category:Pages with incorrectly substituted templates. For example:

Template {{Wikify}} has been incorrectly substituted.

In any case I think it would be useful to leave this parameter in as it would allow other functionality to be added if we choose later. Future-proofing if you like. — Martin (MSGJ · talk) 12:00, 22 May 2012 (UTC)

I finished making sure that all templates transclude their own documentation and have now removed the auto-documentation feature from Template:Ambox. — Martin (MSGJ · talk) 16:50, 7 June 2012 (UTC)

Request

Please add the possibility for a second and third dated and undated category, that is: category2, category3, all2, all3. Debresser (talk) 21:04, 10 December 2011 (UTC)

See Template:Ambox/sandbox, and Template:Ambox/category/sandbox. I have tested these versions successfully , see Template:Template sandbox and Point Valid (my usual testing sacrifice). Just don't forget to remove to remove "/sandbox" from Template:Ambox/sandbox when copying. Note that the documentation should be updated, minimally, by adding these parameters at least to the full list of parameters. Debresser (talk) 22:40, 10 December 2011 (UTC)

This edit request to Template:Ambox has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please copy the tested and ready versions from these two sandboxes to the templates, to add the possibility of a second and third dated and all-inclusive category. Debresser (talk) 01:50, 21 December 2011 (UTC)

Done and done. Killiondude (talk) 08:42, 30 December 2011 (UTC)

Thanks. Great. Debresser (talk) 16:03, 31 December 2011 (UTC)

Got a slightly cleaner and more efficient method in the sandboxes (Template:Ambox/sandbox, Template:Ambox/category/sandbox) which allows the latter to be significantly shortened. Good to go? — Martin (MSGJ · talk) 20:17, 21 May 2012 (UTC)

I went ahead and made this change. — Martin (MSGJ · talk) 16:32, 7 June 2012 (UTC)

It makes the Template:Ambox/category subpage simpler, but the actual Template:Ambox a little longer. A matter of taste. I think we should make category handling of Ambox and Fix alike as much as possible. Debresser (talk) 20:01, 7 June 2012 (UTC)

Shorter overall and a more efficient approach IMHO. I take your point about {{fix}} - can we change this one too? Actually why do we need all these separate templates which do the same thing? — Martin (MSGJ · talk) 08:42, 8 June 2012 (UTC)

Borders, proeminence

I agree that making the borders color match the special left border used for example in {{Cleanup-rewrite}} would be good. I'm under the impression that boxes are not proeminent enough to attract my attention. The 10% margins on each side may have something to do with it too. --Chealer (talk) 19:30, 2 March 2012 (UTC)

Standardising cleanup box formatting

Ambox/float overlapping in Opera

Need it be so tall?

Metadata class

Left-aligned small ambox

On Commons

Background

Category proposal

Banner blindness.

Vertical space

Improving accessibility for visually impaired

Any reason not to do this?

Image

Microsoft Ambox?

Ambox/sandbox/doc

CSS class

Conversion needed

MoS naming style

Use vector images when possible

"Expand" templates

Add functionality to ambox

Date parameter

Undated parameter

Clean-up templates

Fragmentation by type (subject)

Fragmentation by object

What's best to do next

Template loops

Categories

Streamlining the look of cleanup tags

RFC: restructuring of the Manual of Style

Duplicate /doc page showing up on template page

Raw option

Adding HTML IDs to article maintenance tags

Substitution checking

Classes

Is this page still needed?

Template loop

Request

Borders, proeminence