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:
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.
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!
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.
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)
Integration Proposal 2
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)
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)
Contingency MOVEs for existing Images supplanted
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:
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.
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.
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.
Indeed. Although boredom is something unlikely for me to experience in the foreseeable future. :-) Waltham, The Duke of 04:52, 11 September 2008 (UTC)
Header and footer message box
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.
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 (Talkcontribs) 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.
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.
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.)
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.
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.