Wikipedia:Village pump (proposals) 

Village pumps: Policy • Technical • Proposals (persistent) • Miscellaneous
Skip to: Table of contents | First discussion | Bottom of page
Village pump proposals   post
The proposals section of the village pump is used to discuss new ideas and proposals that are not policy-related (see Wikipedia:Village pump (policy) for that).

Recurring policy proposals are listed at Wikipedia:Perennial proposals. If you have a proposal for something that sounds overwhelmingly obvious and are amazed that Wikipedia doesn't have it, please check there first before posting it, as someone else might have found it obvious, too.

Before posting your proposal:

  • Read this FAQ page for a list of frequent proposals and the responses to them.
  • If the proposal is a change to the software, file a bug at Bugzilla instead. Your proposal is unlikely to be noticed by a developer unless it is placed there.
  • If the proposal is a change in policy, be sure to also post the proposal to, say, Wikipedia:Manual of style, and ask people to discuss it there.
  • If the proposal is for a new wiki-style project outside of Wikipedia, please go to m:Proposals for new projects and follow the guidelines there. Please do not post it here. These are different from WikiProjects.
Shortcuts:
WP:VPR
WP:VP/PR
WP:PROPS
Please sign and date your post (by typing ~~~~ or clicking the signature icon in the edit toolbar). Please add new topics to the bottom of this page.

« Older discussions | Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39

Contents

Wikipedia SSML (speech synthesis) webservice

This is, I guess, a feature request for wikipedia.

It could be potentially useful if wikipedia could provide a service for people to use which returned a SSML Speech Synthesis Markup Language representation of an article instead of the webpage.

I'm imagining a really convenient, voice controlled program for Windows, Mac, or Linux where one asks the computer about some topic, and the computer searches wikipedia. For example, "Computer, what's Buddhism?" or "Computer, look up New York City." Then the program uses the webservice to get an article's SSML, which it can then feed to the OS's voice synthesis engine, which then reads the 'article' to you.

P: and T: Pseudospaces

According to [1] and [2], the Pseudospaces for T: and P: all redirect to Templates and Portals. I propose that the developers code these pseudospaces into the namespace system as they did for WP: and WT: to move these pages out of the article space and into the proper Template and Portal spaces. No functionality will be lost, nor will searches or use be altered. MBisanz talk 03:09, 16 November 2008 (UTC)

No harm done, but what advantages does this bring? — Werdna • talk 05:35, 16 November 2008 (UTC)

Saves typing and space (in the search box and in links on talk pages, edit summaries etc.) I'm all in favour of more of this (C: for categories as well, if that still hasn't been done).--Kotniski (talk) 08:08, 16 November 2008 (UTC)

You clearly don't understand the proposal. The shortcuts already exist, the proposal is merely to formalise 'P' and 'T' as aliases for the Portal and Template namespaces. — Werdna • talk 09:29, 16 November 2008 (UTC)

I'll tell you how I understand it, then, and you can tell me if I'm wrong about something. At the moment, the shortcuts exist only if someone makes them. If the pseudospaces were coded in, the shortcuts would work automatically. For example, at the moment I can't type T:Archives as a shortcut for Template:Archives, because no-one's ever got round to creating that redirect. However I can type WP:Policy as a shortcut for Wikipedia:Policy, not because it's a redirect, but because the developers have coded the WP pseudospace into the system. --Kotniski (talk) 09:37, 16 November 2008 (UTC)
I understand things the same as Kotniski, this would make it easier to link to any template as T: would work universally, instead of being linked to half a dozen pages we create. Also, it would eliminate duplication of template links currently in the articlespace (T:DYK is considered an article). MBisanz talk 09:41, 16 November 2008 (UTC)
It would also make it impossible to create articles beginning with "T:" or "P:". --Carnildo (talk) 09:49, 16 November 2008 (UTC)
Seeing as we have 2,500,000 articles so far, and none feel the need to use the T:, WP, WT, or P: prefix, and that we have article names that conflict with the existing structure like Help:A Day in the Life, I don't see this as a major matter. MBisanz talk 09:59, 16 November 2008 (UTC)
Help:A Day in the Life is not an article but a redirect to Help!: A Day in the Life. Special:WhatLinksHere/Help:A Day in the Life currently shows 5 mainspace articles. They link to the Help space which redirects back to mainspace. Those 5 links will probably break in many data users. The existence of such a redirect encourages creation of improper links. I think it should be replaced with a short message and a wikilink. The 5 links should of course be fixed but I'm leaving them for now if others want to see them. PrimeHunter (talk) 00:43, 17 November 2008 (UTC)
Can you explain what you mean by "these links will probably break..."? And what improper links it might encourage people to create? Given that this redirect is (potentially, slightly) useful, we shouldn't get rid of it unless we can be specific about the harm it is alleged to do. (Anyway, we're going off topic here - Help: isn't a pseudospace; in fact I think pseudospaces are even more problematic in this regard.)--Kotniski (talk) 06:57, 17 November 2008 (UTC)
Most re-users only copy the article, template, and image namespaces. If there's an article->help->article link, they won't get it when they copy Wikipedia. --Carnildo (talk) 08:05, 17 November 2008 (UTC)
Yes, I'm not disputing that we should change the links. But the redirect itself does no harm (well, it might cause the "wrong" link to remain longer than it should because it won't appear red; but then its not being red is good for us, and we must prioritize the real WP ahead of anyone's copies of it).--Kotniski (talk) 13:07, 17 November 2008 (UTC)

What's this about main namespace being considered the "article" namespace? — Werdna • talk 10:45, 16 November 2008 (UTC)

See Wikipedia:Namespace#Main The main namespace or article namespace is.... MBisanz talk 13:08, 16 November 2008 (UTC)

Pages in the Wikipedia namespace are what some person wrote about Wikipedia (descriptive, not prescriptive). Since I doubt that area has been actually discussed/debated, it should not be treated as 'correct' policy, especially on a minor detail like this.

Am I missing something, or is this relevant to anything?--Kotniski (talk) 16:31, 17 November 2008 (UTC)
I was thinking the same thing. This has nothing to do with the discussion. -- Imperator3733 (talk) 16:50, 17 November 2008 (UTC)
Hmm, I thought someone had said that would be the case in a discussion similar to this a while back. Oh well, it is easier anyway. -- Imperator3733 (talk) 19:49, 17 November 2008 (UTC)

Scrap Template:Copyedit, or at least explain how it's useful

Hosei University is a pathetic little stub of an article. However, I think (or I delude myself) that what very little it does say, it says competently enough. Meanwhile, I'm open to complaints that no, it doesn't.

By adding a very few characters, another user recently made it start A This article or section needs copy editing for grammar, style, cohesion, tone or spelling. You can assist by editing it now. A how-to guide is available. (November 2008). He and I have been discussing this (look 2/3 way down the page) to little effect, other than to establish that the beef is (beefs are) in style rather than grammar, cohesion, tone or spelling.

Let's suppose for a moment that this or some other article is indeed a stylistic nightmare, making the informative content (locutionary force?) of the template thoroughly deserved. Right then, I'd like to know:

  1. How this template helps the potential readers of the article.
  2. How this template is of more help to potential editors of the article than would be served by something similar (but preferably more informative) on its talk page.
  3. What other benefit this template has to anyone.

Note that I have no objection either (i) to being told (even brusquely) that I've committed stylistic solecisms, or (ii) to the conspicuous placing atop articles of templates such as Template:Unreferenced. For the first, you'll have to take my word for it that I'm thick skinned. As for the second, "Unreferenced" is one of a number of templates that serve to alert readers of potential danger (even fraud), readers who might otherwise be lulled into credulity by burnished, pseudo-encyclopedic prose. By contrast, if an article needs copyediting, literate readers will likely realize this for themselves, and even if they don't IMHO won't be helped in their understanding of the subject by being told the article needs copyediting. Tama1988 (talk) 07:28, 16 November 2008 (UTC)

PS You may wonder why I didn't simply send this template to Templates-for-Deletion. Two reasons. First, I'm willing to be persuaded that the template is helpful. Secondly, that I was sure any nomination for TfD would be dismissed as sour grapes at best, and more likely speedily removed as "pointy" and/or disruptive. Yet I hope that politely making a point here about the template might lead to some improvement: whether a radical revision of the template, its deletion, or something else. Tama1988 (talk) 07:37, 16 November 2008 (UTC)

Might be better to put stuff like that on the talk page. It's designed to make articles needing copyediting visible and searchable. — Werdna • talk 08:02, 16 November 2008 (UTC)

I wouldn't call your article "a pathetic little stub". It is a stub that provides an overview of the subject and, like all stubs, "it will greatly help WP if you can expand it". The problem is not the template itself but its application to a stub that does not have any major spelling or grammar problems. I think you'd be justified in referring the other party to WP:UCS. Regards. ---BlackJack | talk page 09:32, 16 November 2008 (UTC)
Well, thank you--but I don't want to air a grievance with this specific user of the template, or to score points off him. I was slightly irritated at first, it's true; but that quickly gave way to a bigger question: What possible use is there for these templates? Tama1988 (talk) 15:14, 16 November 2008 (UTC)
The use I see for a template like this on the article rather than the talk page is that it invites the reader to become an editor by pointing out something specific they can do. Anomie⚔ 14:05, 16 November 2008 (UTC)
But:
First, it doesn't point out anything specific. The person using the template has the option of making it slightly more specific (an option that this person did not take). As far as I understand it, the template doesn't even have the option of pointing the reader to a supplementary explanation on the talk page, and all in all it does nothing to encourage the template-fastener to do anything helpful whatever.
Secondly, at least for educated readers of English as a first language, errors of spelling, grammar and style should be (perhaps painfully) obvious. Why would the presence of such (utterly unspecified) errors need to be flagged? I don't see why those qualified to copyedit should need to be told that copyediting would help, particularly when I consider that such extra encouragement is just as likely to trigger "improvements" from people who don't know what they're doing. (Putting aside the matter of the stylistically clueless, we have well-intentioned beginners who may well turn "wrong" [in fact OK British] spellings to "correct" [in the US] spellings, or vice versa.) Tama1988 (talk) 15:14, 16 November 2008 (UTC)

Well, I'm not sure if it's appropriate for me to even be in this discussion, but your template question here is essentially just one of many more article issues templates. (See Template:Articleissues) In the documentation, you can find the list of all the different tags. These tags are used to flag articles for other editors to work on them (not to serve as one user's to-do list). Essentially, since the article has not reached a certain level of quality, this article is considered to be incomplete (my most Wiki assessment rubrics). Since it is incomplete, it is logical for - let's say - a grader, to mark spelling, style, etc. errors on the page if it is in print. Instead of using a red pen and marking sections with "awkward style" or "incoherent sentence", a simple copyedit tag is added above the article to show that copyediting is needed. - Jameson L. Tai talk ♦ guestbook ♦ contribs 17:56, 16 November 2008 (UTC)

Of course you're most welcome to join the discussion, and indeed to do so forcefully.
This is indeed one of a set of templates, but it seems anomalous to me as it's about matters that are on the surface. (It's not as if actual or suspected problems lurk to ensnare the gullible reader.)
The huge majority of articles, even of those on more or less static subjects, are incomplete. This one is very, very incomplete. Indeed, it's a stub, and it's so labeled. But are you really saying that incompleteness implies a need for stylistic work? If so, I don't follow this at all. (Indeed, if it were true then the stub template would render the copyedit template superfluous.)
Anyway, let's agree that, whether in this article or elsewhere, copyediting is needed. 1. Shouldn't the need be apparent to those people who are linguistically/rhetorically equipped to do the copyediting? 2. If no, a direct nudge would somehow be helpful, why should it appear on the article itself rather than in the talk page (where it could easily be augmented with detail)? Tama1988 (talk) 04:51, 17 November 2008 (UTC)

"Issue" templates that appear at the top of articles are themselves an issue, and their use (especially their "passive" use) seems to be increasing. First and foremost, they fail to recognize that Wikipedia is a work in progress, and that, barring egregious problems, there is no reason to point this out at the top of every article. Second, they are almost always placed without any accompanying discussion by the "editor". The unspoken rule about article templates that passively point out "problems" is this: unless the editor who put them there has actually begun a discourse about the problem they see with the article, you are free to remove the template, and certainly no explanation can be expected of you when none was given by the first party. Third, these templates make articles ugly. I'm all for general disclaimers about the content of Wikipedia, and in fact I'd support more prominent, global disclaimers about that content, but drive-by tagging is unproductive, unacceptable and revertable on sight. It is not editing; it is not another branch of "wikignome" editing. It is nothing. –Outriggr § 05:23, 17 November 2008 (UTC)

Interesting: You seem more strongly opposed to them than I am. As I've said, I can see the benefit of a template that says "This article has this [less than utterly obvious] problem (and so you should take its content with a shovelful of salt)." Although come to think of it you could be right about more prominent, global disclaimers as an alternative: after all, the more "unreferenced" tags readers see, the greater the risk that they'll take the lack of an "unreferenced" template to mean that an article's content is referenced (perhaps via some arcane method to which, as newcomers, they're not privy). Tama1988 (talk) 08:52, 17 November 2008 (UTC)
Well, I've taken up this "school of thought" quite seriously after seeing the atrocities—generally, the lack of any thought or insight—that accompanies most of this templating. What you echo above is a key point: every templated article, to a random reader, can be taken to imply something about every un-templated article. Wikipedia is hardly that simple and hardly that consistent. A template could highlight an important disagreement occurring on the talk page—fine—but at least in your case, there is no disagreement; after all, your interlocutor (and this is quite common) has had, what, four chances (as of the 15:42 message below) to explain his or her position—why the article needed "copyediting"—and still hasn't done so. It's hard to assume good faith when you have, right in front of you, a passive-aggressive action combined with evasion when questioned. Issue templates are another oversimplification of the kind we must avoid on Wikipedia—they pack great rhetorical power without requiring the instigator to accept the responsibility associated with their template-statement. And they should not be doled out using programs called "Friendly" (which is Wikipedia irony at its best). –Outriggr § 00:10, 18 November 2008 (UTC)
I think we need to be clear about the specific problem which is inappropriate use of the template on Hosei University and other stubs. There is absolutely no need whatsoever to tag a stub with a template like that. To quote Outriggr, it is drive-by tagging and it achieves nothing except to annoy readers and other editors. If there was a spelling mistake or a split infinitive in the stub, why didn't Jamesontai simply make a couple of quick corrections? Would it have taken any more time and effort? Would it have been a less positive action to take?
On the other hand, if Hosei University held 35k of content and it was littered with typos, errors and poor syntax, then application of the template would be necessary and correct.
There is nothing wrong with the template. The problem is that there is a minority of people using the site who do not understand when and how such a template should be applied. ---BlackJack | talk page 10:17, 17 November 2008 (UTC)
Just to be clear, it wasn't a simple spelling mistake. And even if it were really cluttered with spelling mistakes (and the user was lazy...) a quick AWB run-through would have taken care of it as well. - Jameson L. Tai talk ♦ guestbook ♦ contribs 15:42, 17 November 2008 (UTC)
To me, the specific article Hosei University is a side issue. Let's forget the periphery and go for the crux.
Outriggr writes: if [an article] held 35k of content and it was littered with typos, errors and poor syntax, then application of the template would be necessary and correct.
Why?
As I've said, an article in crap prose wears its ghastliness on its sleeve. Those capable of fixing it will see that it needs fixing; this doesn't need to be pointed out to them. (Contrast this with a template warning of a suspected hoax.)
I can think of one use for this template. Suppose a ghastly article is created by a series of IP numbers, and you get the impression that this person is (these people are) not the type inclined to waste valuable time (as they might say) in talk page discussions. A message (whether friendly, curt, firm, or informative) on a user (IP) talk page or the article's talk page would therefore be unlikely to have any effect, if it's read at all. So the top of the article is a good place to, well, start to knock some sense into the creators.
What other benefit of this template have I missed? Tama1988 (talk) 06:48, 18 November 2008 (UTC)
First, writing is not limited to either FAs or "crap prose". Second, en-wiki is full of non-native readers/writers like yours truly; we are not as sharp in spotting faint "shades of crap", especially in our own writing. I suspect that a lot of native speakers aren't perfect too; there is a gray area where the notice is relevant. I agree with the quoted statement in general: 15k or 35k, content comes first (with NPOV, RS and all that alphabet soup). First fix contents, than polish the prose. An {{unreferenced}} or {{npov}} renders {{copyedit}} useless: who would bother copyediting the content that needs a radical change or even deletion? NVO (talk) 17:55, 18 November 2008 (UTC)
Yes, there are plenty of articles that would benefit from copyediting. But how is it better--no, no, I'd ask the same question that I'm asking some lines below in response to a comment by Edjohnston Tama1988 (talk) 09:06, 19 November 2008 (UTC)

I hope it won't be considered intrusive if I chime in here. In my opinion "Drive-by tagging" or "drive-by templating" is a huge problem. I am faced with it at present in an article I started, Bethmanns and Rothschilds. To give a brief run-down, one editor dropped two Templates on the Article, "peacock" and "essay", with no explanation on the Talk page. There ensued a rather unhappy contretemps between myself, that editor and another who sided with him. I put my concern into an AN/I thread which unfortunately gathered almost no comments and slid into the archives unresolved. One of these two editors concurrently (and paradoxically) nominated the article for deletion at WP:Articles for deletion/Bethmanns and Rothschilds. A few hours ago the closing admin sent this back to the Article's Talk page as a "no consensus". Now in spite of this closure and in spite of my detailed and lengthy exposition of why the Article should be kept which I posted a few seconds after the admin's closing, one of the critics now has slapped an "original research" Template on the Article and again insists that the Article be deleted (Talk:Bethmanns_and_Rothschilds). I'd like to assume good faith but this kind of conduct just makes it very very difficult. I agree that the Article has issues and acknowledge that it needs to be improved, but telling me that the Article should be deleted a few hours after the AfD closes and slapping on a Template is, well, not so "Friendly", even if the software they used to put it on calls itself that. --Goodmorningworld (talk) 17:34, 17 November 2008 (UTC)

"Friendly" is Newspeakish, isn't it? Of course you're most welcome to chime in. But since you bring up this article, I have to say that my interpretation is different. Although the writer says that he hasn't changed his mind and that he still thinks the article should be deleted, he doesn't threaten to do anything about it. Does the article include "original research"? I haven't spent long enough reading and thinking to do more than start to form an opinion about this; however, I do think that some articles do contain OR and that flagging them accordingly might serve as a useful warning to some readers. (Ditto for the "peacock" template.) Whereas I can't say this about the "copyedit" template. (Or, come to think of it, the "essay" template.) Anyway, I'd encourage you to copy what you wrote at the end of the AfD and paste it onto the article's talk page. Tama1988 (talk) 10:58, 18 November 2008 (UTC)
Just FYI: A less intrusive approach to "copy and pasting" the entire AfD discussion onto the talk page, you might want to just transclude it and put it in a collapsable navibox so it can be hidden if it isn't needed. - Jameson L. Tai talk ♦ guestbook ♦ contribs 15:47, 18 November 2008 (UTC)
Back to the general question of excessive tagging, a tag is really a comment by one user that he thinks a discussion is needed about a specific fault of the article. The person who *places* the tag should be willing to engage in a discussion about the problems they see, whenever asked. If for any reason the person placing the tag is not available, or doesn't have time to join in on the Talk page then, after notice has been given on the Talk page and a reasonable time has elapsed, the tag can usually be removed. EdJohnston (talk) 16:48, 18 November 2008 (UTC)
Yes yes yes, bags of articles would benefit from copywriting. Yes there may be some reason for a person to point out the need (rather than to just go ahead and copyedit). But, bearing in mind that an obvious need for copyeding will anyway be obvious to those who are capable of copyediting, how is it better to point out the need by sticking an imprecise--"grammar, style, cohesion, tone or spelling"--notice on the article than to say what's wrong more precisely within the talk page? Tama1988 (talk) 09:06, 19 November 2008 (UTC)
It might be true that "an obvious need for copyeding will anyway be obvious to those who are capable of copyediting", but it is not useful if the ones willing to copyedit won't find the article itself. And there are two ways to find an article to copyedit: 1) it is possible to search for candidates in some subcategory of Category:Wikipedia articles needing copy edit, 2) it is possible to browse Wikipedia "normally" until an article to be copyedited is found. Now the {{copyedit}} template helps in both cases: it assigns the article to the category (and the copyeditors that use the category can find it), and someone who finds such article "normally" and copyedits it knows that it is necessary to remove the template (as otherwise the copyeditors who use the category will have to waste time searching for errors where none are to be found). --Martynas Patasius (talk) 19:15, 19 November 2008 (UTC)
OK, but then why not instead do one or other of this pair? (1) Put the template (or a version of the template adjusted for this purpose) on the talk page. (2) Use a category, e.g. Category:Articles in need of copyediting. The second lends itself to helpful elaboration: Category:Visual arts articles in need of copyediting, Category:Education articles in need of copyediting, etc.
Incidentally, after further brains-wracking, I've come up with an arguable justification for retaining a conspicuous "Essay" template: without it, the person browsing Wikipedia might encounter some essays (or belles lettres) masquerading as articles, and might be more likely to infer that this was an acceptable way to write articles, and might essayfy existing articles or create new essays. However, this justification can't be extended to the "Copyedit" template, because an article that obviously needs copyediting, uh, obviously needs copyediting. Tama1988 (talk) 10:05, 20 November 2008 (UTC)
Because both template on the talk page and the category as such would not be that easy to see for everyone (including potential copyeditors). Remember, if the article belongs to the category and a user corrects a mistake, the user has to remove the article from the category (unless there are more mistakes left). And that is impossible if the user doesn't even see the notice to be removed - the relevant categories are hidden and it might seem pointless to look at the "discussion" when there doesn't seem to be much worth discussing... Yes, the experienced users would probably adapt if necessary, but what about the new ones (for all we know, the tag might actually encourage them to be bold about correcting the mistakes)? And since I don't really see any serious downside of having a tag (I doubt that tags make articles ugly - who knows, some articles might even be beautified by some tags - well, de gustibus non est disputandum), I'd say that the tags should be used.
By the way, the idea to group the articles in need of copyediting (and probably some others) by subject does seem interesting... --Martynas Patasius (talk) 17:33, 20 November 2008 (UTC)
But remember, we're talking about an alleged need for copyediting. Anybody capable of copywriting who arrives at such an article won't need to be told that it needs copywriting. Yes, for all we know, the tag might actually encourage newbies to be bold about correcting the mistakes; but it might also give the message that a Wikipedia editor's normal procedure when noticing flaws is to do nothing that's directly constructive but instead to tut-tut about the flaws in a fancy rectangle in the expectation that somebody else will fix them.
The other disadvantages of these tags? The way they provide a lazy alternative to actual copyediting, and their unhelpfulness to either the general reader or the general editor. Go back to the beginning of this section and you'll see how they were first brought to my (first irritated, then mystified) attention; I still don't know what was (and thus presumably remains) wrong with the article in question. (Contrast this with, say, "{{dubious}}", which points any baffled would-be editor to a discussion on the talk page.) Tama1988 (talk) 05:12, 22 November 2008 (UTC)
(unidenting) Once again, the user capable of copyediting still has to find the page - that's the main use of such tags. And, well, if "anybody capable of copywriting who arrives at such an article won't need to be told that it needs copywriting", how would a more detailed explanation help? I suspect it would only be so if the original author wants to find out the mistakes to learn to avoid them - and then a much longer discussion (concerning the editor and not the article) is likely to be necessary.
And on the matter of "a lazy alternative to actual copyediting" - yes, in most cases it is better to correct mistakes than to add a tag, but adding a tag is still much better than not even adding a tag. After all, Wikipedia is not a concentration camp - the editors are volunteers and can do as much (or as little) work, as they want. --Martynas Patasius (talk) 16:50, 28 November 2008 (UTC)
But if the goal is to make an article appear in a list of articles needing improvement, it isn't necessary to place the tag at the top of the Article, a step that stirs up a lot of bad blood and resentment. The tag can go on the Talk page instead. The "copyedit" tag you have been discussing with Tama1988 above is part of what I call "non-self-explanatory tags" (the self-explanatory tags being tags such as "references missing").
WP:DRIVEBY, a how-to guide on the use of the NPOV tag, has this useful piece of advice:

Drive-by tagging is strongly discouraged. The editor who adds the tag must address the issues on the talk page, pointing to specific issues that are actionable within the content policies, namely Wikipedia:Neutral point of view, Wikipedia:Verifiability, Wikipedia:No original research and Wikipedia:Biographies of living persons. Simply being of the opinion that a page is not neutral is not sufficient to justify the addition of the tag. Tags should be added as a last resort.

The last sentence especially, Tags should be added as a last resort is spot on. Even if a rules change to mandate placement of tags on the Talk pages of articles is not forthcoming soon, the guidelines quoted above are common sense. They apply not just to the "NPOV" tag but to each and every "non-self-explanatory"-type tag.
  1. Do not engage in hit-and-run tagging, ever.
  2. ALWAYS provide an explanation for the tag on the Talk page at the same time.
  3. Raise the issues on the Talk page first.
  4. Use the tag ONLY as a last resort.--Goodmorningworld (talk) 02:07, 1 December 2008 (UTC)
And it is truly the correct way to deal with NPOV tags. Those tags say "(something) has been disputed". Now, if there is nothing on the talk page, and even nothing in the edit comment, then nothing has been "disputed", meaning that, technically, the tag does not belong here. But the other tags (including the one about copyediting) say "(something) is wrong with the article". The truth of this statement does not depend on anything in the talk page. And what can be written on the talk page? If one is expected to write a detailed explanation ("There are 10 spelling mistakes and two style mistakes in this article.", or even listing every single of them), that would require about as much work and skill as the actual copyediting, which would probably mean that the mistakes would stay as if they were unnoticed. And if one is expected to write something like "The article needs copyediting.", how would that really differ from the use of the tag? Also, with NPOV tags we expect that the explanation on the talk page will start a discussion to determine the best couse of action. And what discussion can be expected in case of message "This article needs copyediting."? Do we really expect it to result in "a lot of bad blood and resentment"? Personally, I suspect that the situation with Tama1988 was the "worst-case scenario" in this case (maybe even "worse-than-worst-case scenario") - or were there any Arbitration Committee cases about "copyediting" tags (as opposed to NPOV tags)?
Finally, the "copyediting" tag seems rather "self-explanatory" to me - while Tama1988's saying "an obvious need for copyeding will anyway be obvious to those who are capable of copyediting" might be an overstatement, I suspect that in many cases a more detailed message would not be that useful. Now, it would be nice if someone who adds such a tag would give one or two examples of mistakes (let's say, in the edit comment), but turning that into a requirement seems to be somewhat dangerous. --Martynas Patasius (talk) 19:26, 1 December 2008 (UTC)

mbox type names

Right now, the current type names listed are:

These were determined after lengthy (somewhat messy - eggs were broken, but the omelette was made) discussions.

The goal, presumably, was to intuitively include all templates, and to cut down on the variations of each, and create a standard in order to enhance readbility. Laudable goal.

I am in no way suggesting that this good work be undone.

What I am suggesting is that two of the names of the types be changed.

Why?

Well for one thing, to better integrate the historical (pre-existing) system of templates: Template:Notice / Template:Caution / Template:Warning. (Blue / orange / red.)

And also because "red" is being used for more templates than just "delete". And "orange" for more than just "content".

This would make the intended usage of the "types" much clearer.

Implementation shouldn't be difficult, I presume. Simply edit the name in the code, and bots can update the type name in the templates. - jc37 15:18, 20 November 2008 (UTC)

Imperator3733 (directly below) has further clarified implementation. - jc37 18:43, 20 November 2008 (UTC)

Discussion

It's not the case that the 'delete' type is correctly used for anything other than deletion notices. The |type=delete type should not be used for anything else, as it represents more than just a set of styles. The type is metadata that is invaluable for, for instance, blind editors using screen readers, where the intonation of content is governed by the surrounding classes (among other things). What is correct is to use |type=content for all serious warnings and override the default styles if the warning is genuinely critical, although this should not be done lightly. See, for instance, Talk:Muhammad. The warning about images at the top appears to be using the 'delete' type, a misunderstanding which is (I suspect) the genesis of this proposal. In fact, if you look at the wikicode, the type of the message is correctly set as "content", as the message is about the content of the attached article. The extreme importance of the message warrants radical measures to make it stand out, in this case using the red border from the deletion boxes is sensible and acceptable. But it is not the case that this box uses the "delete" type, because it is not a deletion template; nor should such usage be condoned! We currently are in the situation where an extremely important category of messages are distinguished absolutley by one set of class names, an invaluable tool and one that we should not cast aside. Remember that there is far more to the mbox series than what they look like on a page. The situation with the "content" type templates is less well defined, and I will admit that the nomenclature of the "content" and "style" types is less sensible than the others. But it is not the case that there are four types for ordinary messages, there are three: "notice", "style", and "content". There should rarely if ever be the need to display a warning more eye-catchingly than the orange-bordered style without it pertaining to deletion, on those rare occasions, custom styles should be used, not the delete type.

That aside, you must ask whether this change, which creates an enormous amount of work for absolutley no visible gain, is really productive. I agree that the mbox types are different to the 'old' set of three templates, but if you look now, you see that they now use their appropriate mbox styles, and have done so for months. I see no real complaints about the change to these styles, which means we should not concern ourselves with how things 'used to look'; we are at liberty to move forward without being hamstrung by the past. In this case, I can't really see how changing two names allows us to "better integrate" with the notice/caution/warning hierarchy: given that all the type names are internal, they are fully integrated already. All it would do is to encourage the incorrect use of the "delete" type, which I have explained at length above. All in all, I don't consider this change to be either necessary or useful, and note that it would require a large number of edits to many different templates (hundreds of which, being protected, would have to be made by hand) which would force literally millions of page recaches. Performance is not an issue as long as we continue to be sensible with our changes, and don't adopt sweeping but ultimately trivial semantic changes such as this. Does it affect the mainspace in any way? No. Why is all this infrastructure here? For the mainspace. Do we have better things to be doing with our time? Yes. So let's go do them :D Happy‑melon 23:49, 20 November 2008 (UTC)

As I said above, I guessed that coders wouldn't see the point to this. And the comments above would seem to reinforce that.
And incidentally, nearly every mbox is related to "content" in one way or other. So that name alone is a rather horrid misnomer. And that aside, making Template:warning an "orange"-level mbox would seem contrary to it's historic usage, and by changing it, you (whomever made the change), have now affected any number of pages.
And by the way, changing the names isn't going to affect "blind editors using screen readers", since we're in no way changing the styles themselves.
And finally, if there are other things you'd rather be doing, go enjoy : ) - jc37 23:57, 20 November 2008 (UTC)
I don't think that unilaterally declaring that the opinions of template coders are irrelevant to this discussion because "[they] wouldn't see the point". As the proposed change affects precisely no one on wikipedia apart from template coders, their comments would surely be very important indeed. Discounting the opinions of anyone simply because they do not agree with your own is no way to forward a proposal.
The point I make above is that, by changing the class name from "delete", which has a very obvious semantic meaning, to the less obviously only-for-deletion-templates "warning", you encourage and in fact actively support people using that type for more than just deletion messages. That is, for the reasons I've already given, actively unhelpful. Changing the name affects "blind editors using screen readers", among others, not because of the change of name but of the associated change of meaning, and it affects them negatively. So we have a group of wikipedia readers who are actively disadvantaged by this proposal, and no evidence yet that anyone will benefit, except possibly those who are so tied to the past that they cannot adapt to a stylistic change. The only people who could possibly be advantaged by these changes are those who have a reason to edit the {{caution}} and {{warning}} templates, and the advantage is truly trivial. "Wow, we can use the same type name as the template name... woot woot". So we are to throw away the time spent by hundreds of editors to learn the ambox type parameters over the past year for a semantic improvement in two templates? That requires editing thousands (over 750 for ambox alone) of other templates, let alone other pages? That results in a visible change on precisely none of those pages? You are correct that I don't see the point to this. What surprises me is that you somehow do.
To clarify my position, as it seems to have been misrepresented above. The change from "delete" to "warning" is actively damaging to the encyclopedia as it represents a loss of semantic clarity. The correct way to handle 'very serious' warnings is to manually override the styles in the individual instances. The proposed change from "content" to "caution" certainly does no permanent damage to the encyclopedia, but is to my mind utterly pointless. If we had our time again, perhaps we would have chosen different names for these types if we knew they would eventually be used outside the mainspace. That is hardly an uncommon situation here on a dynamically-evolving wiki. It is proposed to change to a set of type names that are not significantly more clear than their predecessors; which seem to place more importance on conformance to an outdated system of messages that precisely no one apart from the OP has objected to changing, than to the current usage of the system and the fact that it is monumentally more wide-ranging than those three templates ever were. Undertaking the terrifying amount of work required to implement this schema change seems pointless in the extreme. And to answer your rather unnecessarily barbed final comment, I'm staying here in order to free up my time later, when I would otherwise, like many other template coders, be running round picking up the pieces of broken glass this proposal would leave behind. Happy‑melon 15:53, 21 November 2008 (UTC)
tl;dr. But the summary seems to be that you're against changing "delete" to "warning" because the class name of "delete" has useful connotations, and you don't care about changing "content" to "caution" beyond the work involved to do so. Would you be similarly opposed to creating a separate class "warning" for use by critical warnings? After all, "warning" over "content+extra styles" would have useful semantic value as well ;) Anomie⚔ 18:01, 21 November 2008 (UTC)
I can't say I blame you: that's what the summary is for :D. I would also be opposed to creating a new type for 'very serious warnings', as it would encourage the 'arms race' of increasing eye-catching-ness of messages; requiring editors to override the styles forces them to think twice about whether the warning message they are creating is really so dire as to require such special treatment, in very few cases it it genuinely so. Of course as you say this has to be weighed against the semantic value of distinguishing such messages... but I fear that if we created an extra type for "very serious messages" it would quickly become populated with messages that are not, in fact, particularly terrifying, thereby both perpetuating the arms-race and rendering the semantic distinction useless. As you can see I'm not fundamentally opposed to this proposal, but I'm not entirely convinced. I wouldn't say that I "don't care" about changing "content" to "caution": the work involved is very considerable, and would in all likelihood involve me and other template coders in work we'd rather not spend time on. If it were as simple as someone writing a bot and setting it loose, maybe, although there would still be disruption and bloating of logs, watchlists etc. And I'm not fully convinced either that it wouldn't be a net loss to the project to complete such an extensive change without tangible benefits. But my main point is certainly that a change from "delete" to anything else would be actively harmful. Happy‑melon 18:51, 21 November 2008 (UTC)
"Actively harmful"? While I think the mbox convention is a great idea. The Wikipedia doesn't sink if it's not enacted. And that goes for any default styles as well. So I'm not sure how that can be supported.
"Changing the name affects "blind editors using screen readers", among others, not because of the change of name but of the associated change of meaning, and it affects them negatively." - I'm apparently not understand this, would you clarify?
That aside, did you consider Template:Warning to be problematic in the way that you feel that a style called warning could be? Because that's all we'd essentially be doing. When mbox was implemented, the sub-transclusions of the warning template were replaced with a style type and mbox instead. So all we'd be doing now is to rename that style type to reflect that. This is honestly something that should have been considered and more fully discussed in the ambox implementation steps, but wasn't because at that time, the discussion was more about article boxes. And these were more used for other namespaces. But when the implementation of the other namespaces happened, everyone claimed that they had consensus based upon the ambox discussion, and that railroaded other discussion, despite the policy that Consensus can change. And when coders unite and say they won't even consider something, what are non-coder editors supposed to do? (Incidentally, when I speak of "coders" I'm talking about those who are designing the more complex templates. Not those who are just inputting paramenters in templates for transclusion. My apologies for any confusion.)
So now, we're looking back. mbox and it's clones have been implemented, but issues are starting to appear based upon current usage of the templates. And further, issues with other historical templates, and how they can be integrated into the mbox convention.
This proposal should resolve all of that.
I don't know if I've addressed all your points, if I missed any, please feel free to let me know. - jc37 20:03, 21 November 2008 (UTC)
Your first two quotes refer specifically to changing "delete" to "warning": we have recently taken a large step forward by standardising all templates releted to 'deletion' on wikipedia to use CSS classes following the "xbox-delete" style. That means that special instructions can be applied to treat these objects differently because they're deletion messages - blind editors could configure their screen readers to read these warnings first, or colourblind editors could change their colour to one that they can distinguish, or researchers analysing wikipedia processes could actively search pages for these templates. If we change the name to "warning", we actively encourage these classes to be used for other things, destroying that semantic clarity. In an environment where it is so incredibly difficult to take steps backwards, this would be one of them. Hence, it would be actively harmful to the encyclopedia, and would affect readers who use the classes in these ways negatively.
Aside from the "delete" type, which should not be changed, I do agree that the names "style" and "content" for the yellow and orange boxes are not the clearest possible terms to use. Indeed, if we had anticipated in the development of ambox that the types would eventually be propagated to all namespaces, we might have chosen differently. We didn't, so we didn't, and now we have what we have. However, it is not fair to conclude from that that the other mboxes somehow didn't have consensus: each mbox was discussed and deployed separately and nowhere was there any suggestion of using different type names to ambox. Indeed it would have been ludicrous to do so.
You claim that "coders [have united] and won't even consider [your proposal]" as if that had both happened and been a bad thing. As you can see above, I have given your proposal a great deal of "consideration", and have written over three screens on why it is overall a bad idea. Since it is inevitable that the editors who "are designing the more complex templates" are going to know more about their internal workings (and the reasons for their idiosyncracies) than other editors, discounting their input to the discussion would not be very clever. Of course the reason this discussion is occuring here is so that we can gain the broadest involvement possible, so it would be equally unclever to discount the comments and suggestions of editors who are not deeply involved with the templates, but the purpose of discussion is to draw on the expertise and experiences of everyone who has useful contributions to offer.
I'm going to continue this discussion off Nihiltres' comment, as I think it sums up most accurately the situation here. Happy‑melon 11:57, 22 November 2008 (UTC)
Something I should clear up: When talking about the past, I'm referring to several ambox-related discussions. A good example of this was the outcry upon implementation concerning the "pink" speedy, which resulted in the "speedy" style type, which was initially opposed by "the coders". There were more examples than those, but most were railroaded by the suggestion that a.) trying to discuss might derail the whole thing, and most seemed to like the plan enough to accept waiting until "later" b.) the final argument in most discussions was (paraphrasing): "If you don't like it, tough, we're coding this, so we're doing it this way. If you like something else, code it yourself." I'm not saying that this was the stance of veeryone, but it was fairly common enough. So anyway, that's roughly some of what I was referring to.
You indeed seem to have considered this, and more than your initial post may have initially indicated. So if anything in my comments has come across in any way seeming to be negative feeling towards you, you have my apologies. - jc37 12:48, 22 November 2008 (UTC)

(unindent) I believe I'm understanding the problem better now, on review. There is a reasonable discrepancy between the internal design of the mbox types, which were designed for mainspace notices (with good separation of classes of notice), and the series of templates you mention, which were designed as general-purpose warning messages (and thus are inherently vague). I still oppose changing the fundamental mbox type names for the mainspace in the manner currently proposed (as we would then lose valuable semantic coherence), but there is a good point in that some type names are incongruous in, for example, talk namespaces. I think that we need to consider a third solution: your solution appears unacceptable to Happy-melon and me as it kills the system as applied for the main namespace, while our current system is too optimized for the main namespace to be applied as a general "mbox" as opposed to a specific "ambox", for example. I'll sleep on this (it's ~2AM here at the moment) and come up with a more concrete way of moving forward soon. {{Nihiltres|talk|log}} 07:11, 22 November 2008 (UTC)

Yes, exactly.
Perhaps one way to deal with this is to have another "red" type? We already have speedy (red, though with pink shading), and delete. perhaps if we add "warning" to be used as the "red type", while retaining "delete" only for the deletion templates?
That may resolve most of the issues?
As for content and style, I dunno. We could presumably add caution as an alternate orange type (and I could accept that), but I also think that we should probably beware of setting an example of just adding more and more style types. Especially since content and caution may be essentially identical stylistically.
One thing that merely adding "caution" and "warning" would do is resolve icons. Delete-style templates really don't need icons, they're a mass of text. And the triangle "!" was the icon for "caution" (it's currently being used for delete), and the stopsign was the icon for "warning". By adding these two, then, content could retain it's circle "!" (with its usage more clearly established as being content related) and caution having the triangle "!" (with its usage being clarified from "content").
More thoughts obviously welcome. - jc37 12:48, 22 November 2008 (UTC)
Please keep the icon discussion out of this for now. That is a separate issue. If you mix it in here then this discussion will be too chaotic.
Anyway, regarding mbox type names: I have been heavily involved in the mbox project almost since it started, so I was asked to come here and comment.
Short version: I agree with Happy-melon and Nihiltres. And I disagree with Jc37.
Long version: This is a fairly complex and big system of styles and templates, so let's go through the details since many who will read this do not know the details:
1: The term "template" can mean any kind of template, not only message boxes.
2: Here we are talking about templates of the kind "message boxes". Such boxes are used in main (article) space, but also in other spaces such as talk space, "Wikipedia:" space, image space and so on.
3: When an article message box has been built and contains text we sometimes also call it a "notice". Note that this is not to be confused with the mbox type notice, since for instance a warning message box can be called a "warning notice", and we have "deletion notices" and so on.
4: Message box standardisation has been ongoing since at least 2005 when the brown talk page message box standard was designed, see Wikipedia:Talk page templates. And message boxes for "Wikipedia:" space seems to have had an unofficial standard since long before that.
What message boxes looked like before we standardised them.
5: In summer 2007 we standardised the message boxes for articles (main space). And for convenience we made the {{ambox}} meta-template and the "ambox-*" CSS classes. See also Wikipedia:Article message boxes. And that was when we did choose the type names notice, style, content, delete and so on. So those names were only chosen with main (article) space in mind. And thus some of those type names are a bit weird when we reuse them in other namespaces.
6: In spring and summer 2008 we standardised the message boxes for all other namespaces. And we somewhat extended the old brown talk page standard and the grey "Wikipedia:" space standard, so they did get the same "colour ladder" as the article message boxes. This resulted in the meta-templates {{tmbox}} for talk space, {{imbox}} for image space, {{cmbox}} for category space, and {{ombox}} for all "other" spaces such as "Wikipedia:" and user space.
7: When we designed the mboxes for the other namespaces we reused the ambox parameter naming. The reasons were that people were already used to the {{ambox}} parameters, and we wanted to build the {{mbox}} that automatically changes style depending on what kind of page it is used. (We need the mbox since some message boxes are used in more than one namespace.) For the mbox to work well we need all the mbox templates to support the same basic set of type names. That is: notice, style, content, delete, and some other.
8: Technically we can make the mboxes understand more than one type name for the same style, thus we can make a transition smoothly. Actually, for some time the red ambox type was called "type=serious". When we changed to the less confusing name "type=delete" we made it so the ambox understood both parameters during the months it took to change all the thousands of usage cases out there on the pages. We also changed the CSS class name from "ambox-serious" to "ambox-delete". That conversion is still not 100% done so we still have to have both CSS class names in MediaWiki:Common.css. So we who did that conversion know that to change name for widely used types like that is a huge effort and takes about a year of work. To describe all the steps it involved to make that transition smoothly would take several pages of text...
9: Using several type names for the same style can be very confusing for the users of the meta-templates. Among other things it means the type names would no longer match the CSS class names. And it becomes especially messy when using the {{mbox}} that detects namespace and automatically changes style depending on what type of page it is on. And if we add a second name for a type we get stuck with supporting that forever, which over time causes a lot of work behind the scenes. Or if we instead opt to completely change over to a new type name it takes a huge effort. So I think that adding a name or changing a name should only be done if it is really necessary.
Now for the styles and type names that we are really discussing here:
10: For general non-urgent notices we have the "type=notice". That style is usually blue or grey or whatever is the neutral default message box colour in each namespace. That type name seems to be okay to use in all namespaces and is well accepted.
11: For minor warnings we have the yellow "type=style". It did get that name since in main (article) space it is meant for notices about style issues, such as bad wording or bad spelling and similar. In other namespaces it can be used for any minor non-urgent warning.
12: For major warnings we have the orange "type=content". It did get that name since in main (article) space it is meant for notices about content issues. Such as the article having wrong facts, or doesn't use neutral point of view, and other issues that we consider serious problems with an article. In other namespaces it can be used for any major warning. This includes urgent warnings of any kind.
13: For deletion notices we have the red "type=delete". (And for speedy delete we have the red+pink "type=speedy".) The red style is at least in main (article) space strictly reserved for deletion notices. Other urgent warnings in article space must use the orange "type=content" style. For this we have a broad consensus.
14: Red should probably also be used for the highest level block messages to be placed on user and user talk pages. It seems most users agree on this too. But as far as I know the styles for such block messages have not yet been properly standardised, so we don't know exactly when to use yellow, orange, or red for a block message.
If we use the red colour only for the very highest level of block messages, such as messages that state that the user has been permanently blocked, then I think it is fairly okay to use the naming "type=delete", since in a sense we have then "deleted" the user. I can anyway not come up with a good short name for such a "permanently banned" type. So I think we can stick with the slightly odd "type=delete" naming there, at least for the time being. But personally I don't have that much of a point of view on the colours to use for user warning and block messages.
15: For the other namespaces it seems most of us want to apply the same rule as in main (article) space. That is, orange for major warnings, and red for deletion. However some users want to use red for urgent messages in other namespaces. Jc37 who started this discussion above, seems to be one of them. And I think more importantly for Jc37, he wants to use the red style for the medium level warning messages to put on user talk pages. And that seems to be why Jc37 wants the red style to be "type=warning". (I know this since Jc37 and I have been discussing this over at the talk pages of {{caution}} and {{warning}} before.) I don't mind that much that Jc37 and others use a red colour for such user warning messages, but I strongly disagree with naming the red style "type=warning" because of that. One single namespace should not dictate a type naming that is weird in all other namespaces. (Sure, the current "style/content/delete" naming comes from the main space, but that is for historical reasons.) And especially the user space should not dictate anything for the other namespaces. And especially since when to use which style for warning messages on user talk pages is not even properly standardised yet.
16: If we add some extra names for some of the types, then this is the naming I suggest:
  • Minor non-urgent warnings: Yellow "type=style", could also be called "type=caution". (So I want "caution" to be used for one level lower than Jc37 wants.)
  • All major warnings, often urgent warnings: Orange "type=content", could also be called "type=warning".
  • Deletion notices and highest level block messages: Red "type=delete". Should not be called "type=warning". Thus unchanged. Perhaps, if we really feel the need for it, add the name "type=block" or so. But I think we should not add any new names for the user talk space until the colour levels for user warnings and user block messages have been properly standardised.
So I am suggesting that we might use the type names "caution" and "warning", but for one colour level lower than what Jc37 is suggesting. Although I am currently only suggesting that we might add those names as extra names, not doing a full transition to those names. But both options would cost us a staggering amount of work, so I am very hesitant.
17: And I have a question to Jc37, since you want to change the naming: Are you prepared to put in the many months of work it takes to transition to the new names? Since if you want to change to names that we disagree with, then you can't expect us to do that work for you.
Sorry for this long message, but this is a complex issue.
--David Göthberg (talk) 15:27, 22 November 2008 (UTC)
Nice break down. Thank you for helping to clarify things even more.
A couple things:
My reasons for this (which has been guessed at several times), is that I'd like to see something consistent, that can be adaptable, and useful in all of the situations noted by others above. And further, I think deprecating the historical templates (caution and warning, the latter in particular) was rather poorly done, and likely not the best way to implement this.
And so based on the idea of consistancy, red should be the highest "warning", whether it's the top level for warning users, warning about deletion, or any other warning. That makes it red-level. Something that it was, long before the mbox came along, and something which wasn't considered in the ambox discussions, since that was focused on articles. Most of the discussions since, while lengthy, have been on template talk pages. (So while, there were VP and CENT notices, they weren't anywhere close to as active as the ambox discussion. And further, most discussions resolved the way Davidgothberg did above: (paraphrasing) "this was the consensus at ambox, and since we don't agree, we won't help with implementing alternate ideas, so we "win" by fait accompli, since (as he states above) "you can't expect us to do that work for you." - So much for Wikipedians being "happy to help"...) I should note that, AFAIK, the topic if mboxes is the only place that I've disagreed with him, and honestly respect him as an editor, coder, etc. And he's one of the first places I go if I have had a technical question.)
And as "content" is not the same as "caution", and "delete" is not the same as "warning", especially since, as dg notes, he suggests that "warning" should now be orange, instead of red as it was historically. And that presumption in implementation did what? It made the "warning" and "caution" templates identical (orange). And this obviously creates problems.
Hence my modified suggestion, based on the discussion so far:
1.) Deletion templates don't use icons, so there is no need to even have that as a part of the "style", especially if we intend to enforce the idea that "delete" only be used for deletion templates, for the reasons that Happy-melon laid out above.
2.) Therefore, we can assign the triangle "!" icon currently used as the default for the delete templates to be instead (as it was historically) the default for the (proposed new) orange "caution" style. (Note that this then leaves the "content" style in place for use in ambox, and anywhere else a content-related mbox would be used.)
3.) The (proposed new) Warning style be created. Using the red-level, and a stopsign icon (as has been traditional). This would also be useful for resolving several of the issues laid out by others above.
The coding of the "styles" part of this shouldn't presumably be incredibly difficult? (I'm not positive, so I'm asking.)
And once done, I would indeed be happy to help. One thing I think I could help with is the restoration of the warning templates, once that "style" has been created. The implementation thus far has been spread over several editors, so I'm not sure if we have a single contribution history of all who deprecated Template:warning, but if so, such a list (in order to assess and implement) would, I presume, be helpful.
Yes, this may mean more work. But I think it means less work on the long run, especially for consistancy amongst all the mboxes. - jc37 16:26, 22 November 2008 (UTC)
I'm still thinking about the yellow and orange colour levels, but red should definitely remain "delete": it's already consistent across all namespaces. Icons, as mentioned by David Göthberg, should be ignored for now—they're defined separately, locally customizable, and a bigger headache in terms of this discussion.
When I look at each of the various mboxes, I see that all of them (with exception to special cases dmbox and fmbox) have the same set of styles, with a couple of extra for imbox that are unique to the Image namespace. Among these, I concede that the majority do not use the content and style names for "content" issues and "style" issues: most of them even say "major issues" for "content" and "minor issues" for "style". Now, I'd prefer, if possible, to keep the "content" and style distinction for the namespace, so I see a few relatively simple (but, naturally :), complex in implementation) ideas:
  1. Harmonize the type names universally, for "content" → "major" and "style" → "minor" or some such. This loses some semantics for the mainspace, but makes all types (except namespace-specific ones) consistent across all namespaces. I personally dislike this solution as it's the most vaguely defined system. It involves a full style change that will take a while to implement, and sweeping trivial changes across many, many templates.
  2. Prefer the mainspace type names universally, and harmonize the use among extant templates. This was the original solution, and I still think it's reasonable, though it does perpetuate the problem of somewhat-incongruous type names for many templates. It probably involves the least work, as most templates should already be happy with the system, though there are undoubtedly many to be fixed. We'd likely do this work anyway even if we decide to not act upon this discussion, as we want our templates to be harmonized with the system we've chosen.
  3. Break the mainspace away from the other namespaces: it's always been a special case. Create new, vague (meh) classes for "major" and "minor" or some such, and use them everywhere outside the mainspace. The multi-namespace mbox can use a simple namespace switch to determine which classes to use, and in the CSS we'll mainly be changing names. This is probably a fair compromise, though it fails to resolve the ultimate issue of semantic coherence for the other namespaces, and creates a split in usage across namespaces which isn't exactly desirable. It will involve a full style change for most namespaces, and sweeping trivial changes across many, many templates.
These are just a few basic suggestions, and none of them are completely ideal. Ideally, we'd be able to define clear distinctions across all namespaces that reflected the general nature of the two contentious levels, and do some general work harmonizing those templates which did not fit our system, and perhaps change the names slightly to reflect the somewhat-general nature while retaining most of the coherence that the main namespace now enjoys with "content" and "style". Is there a way to concretely divide those messages in other namespaces which would work effectively in the mainspace as well? I think that we could probably all agree on such a solution, if we can define our problem well enough to find it. {{Nihiltres|talk|log}} 18:31, 22 November 2008 (UTC)
I don't see why "delete" needs to be the "top" of the colour chain. It's a different kind of notice (similar to "protect"). And could be noted to be as such.
It was only placed there back when we were only suggesting a heirarchical colour scheme. Since then, we've added protect, and several other things (especially when we consider the other mboxes). And so now it's really not heirarchical. For ambox, none of the colours are "more important" than the others, just "different". (We could make "style" green, and "content" yellow, and nothing would change much for the enduser, for example.)
But when dealing with warnings (especially user action/conduct), there really does seem to be a want to have a heirarchy of colour: orange, then red, as the "top levels". And "delete" is a warning-style notice. Honestly, if we get technical about it, delete could easily be orange, with speedy as red, if we follow the heirarchical system, since "delete" is more a "caution" that a page will be deleted due to discussion after (presumably) several days. While Speedy suggests that the users need to be warned that this page may be deleted at any moment. While both are impending, obviously there is a difference.
So any "heirarchy" can presumably be pretty much whatever we decide it should be. - jc37 22:51, 22 November 2008 (UTC)

Arbitrary section break to help deal with our wall of text :)

Hang on, I think I might have picked up something that I didn't fully comprehend before. Are you saying, jc, that prior to the mbox standardisation {{warning}} and {{caution}} were metatemplates? That is, they were used primarily to create other templates?? And that post-standardisation, that system has been abolished and all the templates that previously used warning and caution were edited to use {{mbox}} or {{ombox}} directly? Happy‑melon 19:25, 22 November 2008 (UTC)

Yes, yes, yes! : )
And Template:Notice (which was "blue" before), was also.
Though they were used in more than just those two mbox implementations. Talk pages, category pages, template pages, Wikipedia-space pages, etc. And I'm not certain about "all". I think that there may still be templates out there which use these as their metatemplates, even after the various mbox implementations.
(And through implementation both have been set to "orange-level" arbitrarily.) - jc37 22:51, 22 November 2008 (UTC)
Oh, so that was what you Jc37 meant by that the {{caution}} and {{warning}} templates have been "deprecated". Since as far as I know those templates are not deprecated. They are still in use, they are still useful, and their documentation says nothing about any deprecation. But yeah, they are usually not used as meta-templates anymore.
Jc37: Regarding "happy to help": Right, we Wikipedians are usually happy to help, but why should we be happy to help with something we dislike and don't want?
Jc37: I just realised that you have never mentioned yellow in our discussions anywhere. (Jc37 and I have been discussing these matters at the talk pages of several message boxes for quite some time now.) And over at Template talk:Mfd you are one of the users that want to use green for the deletion notices. And I see now that in your comments above you think that the {{caution}} message box is orange. But take a look at it, it is yellow now and have been so for some time. It used to be plain grey, but with an orange icon, so in a sense you can say it used to be "orange". So Jc37, I think you should disclose the full colour scale you are thinking of. Since it seems you want a colour scale something like this:
  • Blue/grey/neutral = As it is now, that is for general non-urgent notices, "type=notice".
  • You don't want to use yellow at all.
  • Orange = For minor warnings, and you want to call that "type=caution".
  • Red = For major warnings and the least urgent deletion notices, and you want to call that "type=warning".
  • Green = For most of the deletion notices.
  • Red+pink = As it is now, for the speedy deletion notices.
Jc37: Am I guessing your colour scale correctly?
And I disagree with that colour scale. I find your scale v