Wikipedia:Village pump (proposals)/Archive 39

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 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, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

Public Black Background version of Wikipedia

Hi! I haven't edited for a long time, and I never had much involvement with community issues, so I apologize if my question seems odd here.

Is there a way to access Wikipedia with a black background on it without having to log in? (almost like how we can go to mobile.wikipedia.org if we're using iPods or Blackberries.) I use the black background and green text setting on my preferences, but I'm just wondering if I can use it without logging in. (I tend to be obsessed with saving energy all the time...) =)

Google has a similar format on Blackle if you don't get what I mean.--Dem393 (talk) 19:52, 15 November 2008 (UTC)

Blackle only saves power for people using CRT monitors. For people using LCD monitors, there's no difference between black and white in terms of power use: the backlight is always on. --Carnildo (talk) 00:52, 16 November 2008 (UTC)

CRT monitors are generally box-shaped, right?--Dem393 (talk) 03:13, 16 November 2008 (UTC)

The use of black backgrounds on any type of monitor does not save appreciable amounts of energy - you could save a lot more by turning your heating or A/C down one degree. Worry about usability and eye strain. Dcoetzee 08:49, 16 November 2008 (UTC)

I disagree. If a lot of people begin to use black backgrounds, then we will be saving an appreciable amount of energy, right? Having a public website reserved for black backgrounds, such as blackle, would also remind everyone that we need to start taking small steps to make a big difference in saving power. --Dem393 (talk) 15:08, 16 November 2008 (UTC)

Small steps, long medical bills. I don't have spare eyes, do you? NVO (talk) 17:33, 18 November 2008 (UTC)

Quite, I use the black-background gadget because the normal display hurts my eyes. DuncanHill (talk) 17:46, 18 November 2008 (UTC)

Hi there! If you take a copy of PHProxy from sourceforge:projects/poxy/ and add

$blackurl = complete_url("/w/index.php?title=MediaWiki:Gadget-Blackskin.css&usemsgcache=yes&ctype=text%2Fcss&smaxage=2678400&action=raw&maxage=2678400");
preg_match("/<link rel=\"stylesheet\".*Monobook\.css.*\/>/i", $_response_body, $matcher);
$_response_body = str_replace($matcher[0], "<link rel=\"stylesheet\" href=\"$blackurl\" type=\"text/css\" />", $_response_body);

just before

echo $_response_body;

in index.php, browsing through that proxy will automatically modify the CSS file to use the black/green version on-the-fly, regardless of being logged in or not. If your not sure how to do this, drop me a line on my talk page. Foxy Loxy ^Pounce! 11:19, 16 November 2008 (UTC)

Or, if you use Firefox... Tools -> Options -> Content tab -> Colors -> Change background to black, text to white or green, uncheck "Allow pages to choose their own colors." Then it works on every page on the internet, not just Wikipedia (it also changes the background color for things the gadget misses, like the main page and infoboxes) You could also use a Greasemonkey script to add the CSS if you still want to use the gadget and have it apply only to Wikipedia. Mr.Z-man 04:04, 17 November 2008 (UTC)

New permissions for rollbackers

Title blacklist override

Proposed: that rollbackers be allowed to create and move pages without hindrance from the title blacklist. This can be done by making a bug request to have a developer add the "tboverride" permission to the "rollbacker" group (if no objections are raised here, of course). I acknowledge that this is not exactly of widespread utility, but on the other hand I have a hard time thinking of good reasons to prevent minimally trusted users to create pages with these titles. Some users, it turns out, have good reasons to create pages with names like Talk:(+)-cis-2-Aminomethylcyclopropane carboxylic acid. Why not allow them to do so? Thoughts? HiDrNick! 20:10, 17 November 2008 (UTC)

• Oppose: I'm not sure I see how this would be useful for users with rollback rights. - Rjd0060 (talk) 04:06, 18 November 2008 (UTC)
• Oppose: Rollbacker is not a "trusted user" group and this doesn't seem like it would help at all with reverting vandalism. Mr.Z-man 00:09, 19 November 2008 (UTC)

Unwatchedpages

Proposed: that rollbackers be allowed to use Special:Unwatchedpages, a list of pages that are unwatched by any user, useful in fighting vandalism. Similarly, this can be effected by a developer adding the "unwatchedpages" permission to the rollbacker group. Any objections? HiDrNick! 20:10, 17 November 2008 (UTC)

• Oppose: I'm not sure this is useful for anybody including users with rollback. I'm a sysop and I've never seen much use for that special page. - Rjd0060 (talk) 04:06, 18 November 2008 (UTC)
• Oppose - This would allow a user to have an account which becomes trustworthy enough to gain access to this page, and then use it for their sockpuppets. עוד מישהו Od Mishehu 07:03, 18 November 2008 (UTC)
• Oppose - too much like asking for trouble. Pseudomonas_(talk) 00:12, 19 November 2008 (UTC)

General comments

One of the major arguments in favour of allowing rollback to be granted liberally and with minimum fuss is that it doesn't grant any privileges or abilities that regular autoconfirmed users don't have. (Any editor can revert an edit; through the use of user-side automated tools any editor can even make one-click reverts.) Both of these proposals would grant new abilities or access. Consequently, rollback would become more of a 'big deal', and administrators would be required to vet rollback requests much more thoroughly than they do now. The tradeoff isn't worth it for what seems a minimal potential benefit to the project. Even the proposer acknowledges that being able to override the title blacklist is would be a seldom-used tool, while easy-to-get access to the list of unwatched pages seems like a delightful gift to the vandal who would like to undermine our reputation. TenOfAllTrades(talk) 04:28, 18 November 2008 (UTC)

possible way to auto-preview a virtual reflist

Right now whenever a new reference is added for inline citation, I have to either edit the whole article or edit the page and check the article to see if there are any errors. The former leads to history logs which aren't always clear what was edited and the latter can lead to many edits in a row, especially if multiple citations are added if small things like capitalization or spaces, missing letter, etc. are off. Neither one is good for keeping a easily readable history log.

What I think should be done is any time a reference code is used, a preview spits out a virtual reference sheet just with the references listed. If the reference is shortened for space as it's used multiple times, then it could either retrieve that from the main article or just show that name is at least working (so you can see if you accidentally forgot to put the "/" in.Jinnai (talk) 22:27, 17 November 2008 (UTC)

You can always put {{reflist}} at the bottom of the section you are editing and hit the Preview button. That will build the citations for the section you are in. Once the reference looks right, remove the {{reflist}} and save the section. Karanacs (talk) 22:43, 17 November 2008 (UTC)

How many newer editors would know to do that know? Or older editors not used to adding in-line citations? Also, it means you have to remember that every single time.Jinnai (talk) 22:46, 17 November 2008 (UTC)

[E/C] Good idea. I've run into the same problem repeatedly. As a workaround, I'll sometimes add {{reflist}} at the bottom of the section I'm editing. It's not perfect because I have to remember to delete it before saving, and it doesn't show refs that were named in other sections. ·:· Will Beback ·:· 22:47, 17 November 2008 (UTC)

Does seem like a good idea, i'd support it if its doable, i've had the same problem before. Never thought of using a temp reflist though, thanks for the tip--Jac16888 (talk) 23:06, 17 November 2008 (UTC)

This might help:

//add "Preview refs" link at bottom of edit box
if (wgAction == "edit" || wgAction == "submit") { addOnloadHook(function() {
    var refPreview = document.createElement("div");
    var regPreview = document.getElementById("wikiPreview").nextSibling;
    regPreview.parentNode.insertBefore(refPreview, regPreview);
    var prev = getElementsByClassName(document.getElementById("editform"), "span", "editHelp")[0], alink = document.createElement("a"), req;
    alink.href = "javascript:void(0)";
    alink.appendChild(document.createTextNode("Preview refs"));
    prev.parentNode.insertBefore(alink, prev);
    prev.parentNode.insertBefore(document.createTextNode(" | "), prev);
    alink.onclick = function() {
        if (req) { alert("Already getting refs preview..."); return; }
        req = new XMLHttpRequest();
        req.open("POST", wgServer + wgScriptPath + "/api.php", true);
        req.onreadystatechange = function() { if (req.readyState == 4 && req.status == 200) {
            var div = document.createElement("div");
            div.innerHTML = eval("("+req.responseText+")")["parse"]["text"]["*"];
            req = null;
            var refs = getElementsByClassName(div, "div", "references-small")[0];
            if (!refs || !refs.hasChildNodes())
                refs = document.createTextNode("Could not find any references!");
            if (refPreview.hasChildNodes())
                refPreview.replaceChild(refs, refPreview.firstChild);
            else
                refPreview.appendChild(refs);
        }}
        req.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
        req.send("action=parse&format=json&title="+wgPageName+"&text="
            +encodeURIComponent(document.getElementById("wpTextbox1").value+"\n{{reflist}}"))
        return false;
    }
}}

Please excuse any rough edges :) The script retrieves the preview for the entire section with a {{reflist}} tacked on, then adds only the reflist to the bottom of the preview section. It has the same behavior as adding a {{reflist}} at the end of a section, in that it encounters errors with named refs in other sections (e.g. <ref name="foo" />).

It's in no way a replacement for a built-in refs preview, and it could probably be integrated into a larger script, like wikEd. Gracenotes^T § 00:01, 18 November 2008 (UTC)

I will add this funcionality to wikEd by attaching "<references />" to the Ajax preview for section edits. It is invisible without inline references and throws red error text for references defined in other sections. Cacycle (talk) 04:04, 19 November 2008 (UTC)

I have added it to wikEd. Cacycle (talk) 04:31, 20 November 2008 (UTC)

Temporarily adding {{reflist}} is explained at Wikipedia:Footnotes#Previewing a single section edit. A better way to do this is to use User:Anomie/ajaxpreview.js— this adds another preview button that will include refs. I also recommend enabling refTools, now with error checking. --—— Gadget850 (Ed) ^talk - 00:09, 18 November 2008 (UTC)

Another preview script user:js/ajaxPreview also automatically adds <references />. However, I would like to point out that Anomie's preview script is the most advanced in this particular area, since it can retreive even the refs that are not defined in the current section (known only by name=). —AlexSm 05:08, 20 November 2008 (UTC)

Problem with that one is i first have to preview normally and then preview with the script. If i preview without doing that, it uses the last preview (or actual content if i haven't previewed at all).Jinnai (talk) 05:30, 21 November 2008 (UTC)

Video Interviews

Hi,

I’m Tabitha the Marketing Director of t5m, I'm writing to propose that the wikipedia community discuss whether they feel like the content we at t5m produce is relevant to wikipedia.

t5m is an online tv network who’s mission is to produce content which inspires and entertains. Unlike most video networks which either aggregate existing content or rely on user generate content. t5m creates, produces and syndicates original exclusive interviews with celebrities.

t5m prides itself on have a great relationship with the talent we interview, which ensure that we create candid, entertaining and by the very nature of the medium reliably informative interviews. The celebrities are all happy with the content and encourage us to make sure their fans see it as they firmly believe that we are no journalist or advertorial but just being a mouth piece for them.

I feel that many of the interviews we have are relevant to the wikipedia pages on the particular talent. I understand that it is unethical for me to link to t5m on all the pages where our content is relevant so i wanted to highlight our site to the wikipedia community and see whether people see our site as a valuable place to have an external link to.

I have been reading about how wikipedia is moving more into the video arena and i thought that some of our interviews might be a good place to start. So this is also something i would be really happy to discuss.

to check out the content visit www.t5m.com [1] Richard Dawkins interview [2] or Ray Winstone interview[3] as these interviews are good places to start looking.

below is a list of all out personality interview content...

thank you very much for your time

tabitha

Hi tabitha (and I hope you don't mind, but I removed the extra list of people, because it didn't format very well, and I think folk will get the idea :-) - I really enjoyed the Dawkins interview, so thanks for letting us know about it - I'm sure some of these videos might be suitable for reference from some pages, this would be a matter for the various volunteers who work on the articles - you could, for example, try heading over to Richard Dawkins and mentioning politely (and maybe briefly :-) on the talk page who you are, and providing a link to the video. For video content to actually be within wikipedia's pages, we need it to be on a copyleft license (click for more info) - which means that you basically waive most of your 'intellectual property' rights (for example, allowing others to use the content commercially). It'd be fantastic if you were up for releasing some videos, and there are many around here who will talk you through the myriad of benefits doing so can bring :-) Once again thanks for the Dawkins heads up - I recently re-read The Ancestor's Tale, so it was cool to see him chat a bit more :-) cheers, Privatemusings (talk) 05:39, 20 November 2008 (UTC)

Also posted at WP:VPM#Video Interviews; perhaps this discussion should continue only at this page or that one, not at both. -- John Broughton (♫♫) 21:00, 20 November 2008 (UTC)

Clicking on a red link

What has happened? When I click on a red link, I am taken to an edit page where I can create the article. It hasn't always been like this, has it? I think this is dangerous because it is inviting new users to create articles, which they do not know how to do. There is a link to WP:YFA, but it does not stand out very well. Clicking on a red link should go to a This Page Does Not Exist page, from which the page can be started. Leading directly to an edit page leads to an increased amount of badly-written and non-encyclopedic articles from new users. Reywas92^Talk 17:33, 12 November 2008 (UTC)

As far as I know, it has always been like this (though I believe we no longer allow anonymous IPs to start articles, the one change I can think of). - Jmabel | Talk 18:27, 12 November 2008 (UTC)

it is inviting new users to create articles, which they do not know how to do - Did I miss a memo? When did we stop encouraging new users to edit? I was under the impression that WP:BOLD was a guideline. If the article is non-encyclopedic, we shouldn't be linking to it as if the articles are unencyclopedic, its likely the topic is as well. As for "badly written" - we're not on a deadline (and MoS noncompliance is not the same as bad writing), we should be encouraging people to learn by experience, not demanding perfection from the first edit. Mr.Z-man 19:11, 12 November 2008 (UTC)

As Jmabel pointed out, you're only going directly to the edit page because you are registered and autoconfirmed, as others are not able to create the page. Try logging out and then clicking the link. -- Jao (talk) 21:18, 12 November 2008 (UTC)

I see, but that's for unregistered. Are you sure that only autoconfirmed see it? Registered but not autoconfirmed can still create articles. Thanks for the response, Mr. Z-Man. I hadn't thought through it all the way, that the pages we link to in the first place should already be encyclopedic. I must try to be less critical sometimes. My response is that experience can be obtained from editing pre-existing articles, not necessarily in creating new ones that require much more attention.

Right, I should have checked first; new accounts can create articles, only IPs cannot. -- Jao (talk) 22:04, 12 November 2008 (UTC)

When did we decide we didn't want new users to write new articles? Celarnor ^{Talk to me} 01:55, 13 November 2008 (UTC)

I think this is dangerous because it is inviting new users to create articles, which they do not know how to do.

This is a wiki. Wikis are about radical openness. You don't need special authority or permission or skill to create a new article, you just do it, and if you mess something up, somebody will fix it for you. That's the point of a wiki! If you are uncomfortable with this concept, you are free to find another place to edit. — Werdna • talk 13:29, 14 November 2008 (UTC)

I sympathise with Werdna's comment (13:29, 14 November 2008) "Wikis are about radical openness", but that's not how Wikipedia actually works. A poorly-written article with no citations is likely to wind up at WP:AfD, a newbie editor is likely to miss the "this article is at AfD" banner and unlikely to know how to use the Watchlist, etc. A common result is that newbies' articles get deleted. My ideal solution would be to change WP:AfD to "WP:Articles needing improvement", and change WP:DELETE to say "do not even think of deleting unless someone presents evidence that a reasonable effort has been made to find supporting WP:RS and improve the article" - but I'm not holding my breath. It might actually be kinder to make newbies go though Wikipedia:Requested articles, but give them clear instructions on how to create User sub-pages so they can produce drafts there first. --Philcha (talk) 18:24, 21 November 2008 (UTC)

Edit link

Is there a reason why the link for editing a section is on the right side of the page? Frequently, when there are multiple images or tables, they force the links down or off to the side, leading to them a) not lining up with the section header and b) on top of the encyclopedia text itself.

Many other editions, including the German, the French, the Italian, and I'm sure many others have the edit link just immediately to the right of the section header, and not all the way off to the side. This is superior, I think - is there any reason, aside from tradition, to have it as we have it now? zafiroblue05 | Talk 06:30, 20 November 2008 (UTC)

One downside I can think of with having the edit link right after the section header is that it's not in the same place for all sections. With the current position, you can just move the mouse to the far right of the page and the edit link will be somewhere around there. Your proposal would make it harder to quickly click the edit link. -- Imperator3733 (talk) 08:16, 20 November 2008 (UTC)

Have a look at WP:BUNCH. I'm not sure what happened on that discussion on the misplacing of edit links. Someone seemed to propose a solution, then everything went silent. I presume either the solution wasn't implemented or didn't work, since I still see this problem sometime in Firefox (though not in IE). (Actually, looking at the Bugzilla discussion, I see the devs haven't worked out how to fix this yet.)--Kotniski (talk) 12:09, 20 November 2008 (UTC)

WP:BUNCH is a strong argument for moving the edit links to be placed immediately to the right of the related section headings. As for the concept of just moving one's mouse to the far right of the screen - since an editor has to move the mouse up to the heading level, it seems to me just as intuitive to use the section heading as a guide - just move the mouse pointer to the end of the section heading.

To me, the strongest argument for moving the links is to encourage editing - edit links are much more prominent in the middle of the screen (at the end of a section heading) than they are on the far right, I think. -- John Broughton (♫♫) 20:50, 20 November 2008 (UTC)

There are also accessibility issues with the section edit links as they currently are. See bug 11270 and bug 11555. Graham87 08:12, 21 November 2008 (UTC)

Yeah, I agree. It would improve usability and fix broken accessibility.

The link would be more convenient immediately to the right of the title, right under the reader's eye, rather than disconnected over at the RH side of the page. I wouldn't be surprised if some new readers can read whole articles without noticing them. In this position they could be made less visually obtrusive, but would be harder to miss. Positioning them this way would also be technically easier and more correct—in my browser, they float too high in H1 and H2 headings, and too low in H4–6. This could also solve accessibility problems, which is more important than any of these. —Michael Z. 2008-11-21 23:46 z

Christmas-themed DYK

I thought I'd give a heads-up here to a discussion at Wikipedia_talk:Did_you_know#Christmas_DYK. DYK has proposed having a Christmas theme on December 25, and relaxing the rules on when creations/expansions of Christmas-related articles took place to allow more articles on this topic to qualify. This is similar to the recent Halloween theme and an April Fool's theme earlier this year. Other users have suggested that this is biased, as Hannukah, Kwanzaa, and the Islamic New Year all fall during the week of December 25 (Hannukah actually overlaps), but articles about those topics would be excluded from DYK inclusion on the 25th or would not be subject to the same relaxed rules. More voices would be welcome at the discussion to determine a consensus. Karanacs (talk) 18:27, 20 November 2008 (UTC)

I don't know about the Halloween theme, but the April Fool's theme did not relax the rules. Little Red Riding Hoodtalk 01:10, 21 November 2008 (UTC)

If all four of these festivals fall at the same time - why not have a mixture of DKY's for them all? Witty Lama 12:44, 21 November 2008 (UTC)

Sexualised Content on Wikipedia

I'd like to raise some of my concerns, with a view to drafting a proposal which would aim to raise the bar of 'encyclopedic usefulness' for pictures broadly defined as sexualised content (I'd likely support the deletion, and definitionn of almost all of these images as inappropriate for wikipedia, for example). The Personality rights of folk in things like this image also likely warrant deletion in my book.

Perhaps pragmatically this is synonymous with applying the theoretical bar of 'only images which benefit the project should be here' a little more strongly. I'd hope so, and wondered what others might think. cheers, Privatemusings (talk) 05:33, 20 November 2008 (UTC)

I think since most, if not all of the images in question are on Commons, its more of a Commons issue than a Wikipedia issue. Mr.Z-man 06:38, 20 November 2008 (UTC)

Does the 'WikiPr0n' page fit with WP:User page? While I don't believe in censorship, Wikipedia is not here to host someone's porn collection and several of these image would be orphaned if it was removed. --Nate1481 16:40, 20 November 2008 (UTC)

Again, the images are on Commons and are (supposedly) free. The fact that they would be orphaned on en.wikipedia if they were removed from that page is mostly irrelevant to whether or not they would be kept. Mr.Z-man 17:16, 20 November 2008 (UTC)

Ok simply put, does any one else think WikiPr0n should be put up for MfD? --Nate1481 17:44, 20 November 2008 (UTC)

The issue with the page being put forth as an example isn't usefulness, since that really has to do with articles (or should), nor is it hosting per se, since the images are at Commons. Rather, it has to do with what editors do with their user space; in this case, User:Ewlyahoocom/WikiPr0n. That is covered at the guideline Wikipedia:User page; if the guideline doesn't address this issue (I've not looked), then it would be appropriate to discuss the matter at Wikipedia talk:User page. -- John Broughton (♫♫) 20:57, 20 November 2008 (UTC)

Please read Wikipedia:Perennial proposals#Censor offensive images. Cacycle (talk) 00:46, 21 November 2008 (UTC)

have done, Cacylce - and I'm afraid I feel that there remains an issue to examine. I take Z's point that almost all of these images are on commons, but I presume that 'we' (the en-wiki community) are free to talk about, and establish some sort of practice / policy / guideline for the use of such images here? I'm thinking of something like Wikipedia:Sexualised Content, which would have absolutely nothing to do with Commons' mission of being a 'copyleft' media repository, and everything to do with establishing some sensible standards etc. here..... I'll start something, and welcome comment :-) cheers, Privatemusings (talk) 02:32, 21 November 2008 (UTC)

So what you are saying is "I have, but but but but but...", basically, rather than actually presenting a rational argument for your position. You would have done well to just stick with the Personality rights issue, since that is harder to address than your personal dislike. In most cases, the current policies work well to prevent inappropriate use of sexualised content, which leaves only those articles for which its usage would be appropriate and would naturally (and hence should) benefit from the inclusion. As for any moral issue, the perennial proposition entry is entirely correct, see things like Sex-positivism. LinaMishima (talk) 02:43, 21 November 2008 (UTC)

Your input over at Wikipedia:Sexualised Content would be awesome, Lina - I'm just saying that it makes sense to apply some rigour to examining whether or not explicit imagery is actually working for the project. I don't entirely follow your assertion that the perennial proposition entries can be guaranteed to be morally correct.. (is that what you're suggesting?) - but I'm certainly thinking about it... :-) Privatemusings (talk) 02:47, 21 November 2008 (UTC)

I think you make a fair point with this private, these images are not being used for the benefit of the encyclopedia, and really having pages like the wikip0rn one seems wildly innappropriate. However, as is said above, what can we do? The images are commons based, nothing we can do about them--Jac16888 (talk) 02:55, 21 November 2008 (UTC)

technically, maybe not.. but we are empowered, as a community, to come up with a guideline, or policy about the best way to handle this subset of pictures (eg. saying strongly discouraged or even not permitted in userspace etc.) .... see what you think about Wikipedia:Sexualised Content :-) best, Privatemusings (talk) 02:59, 21 November 2008 (UTC)

The problem with saying "not permitted in userspace" is that there are valid academic/editorial uses of these images that may take place within userspace. If you start to add qualifiers like "strongly discouraged", pointless debates will emerge between those who dislike such images (and so see every use as inappropriate) and those who have need to use them (when editing appropriate articles). If your issue is with a single userpage, or the potential for such a userpage, please then address your actual issue. LinaMishima (talk) 03:10, 21 November 2008 (UTC)

Interesting your choice of words regarding the perennial proposition entry - I stated that it handles the moral issues, whereas you state that the perennial proposition entry itself may be morally incorrect. This leads me to suspect that you have a personal moral objection to these types of images, rather than a purely rational one. I have already given my input over there, and I believe that current consensus sides with WP:IMAGE and WP:IUP, which I strongly suspect are new to you (since WP:IUP addresses the personality rights issue). LinaMishima (talk) 03:10, 21 November 2008 (UTC)

I think the 'don't entirely follow' bit was probably more accurate! sorry! Perhaps rather than my highlighting specific pages, or your 'bigger picture' view we could take a middle ground by talking through our disagreements at the Wikipedia:Sexualised Content proposal? cheers, Privatemusings (talk) 03:14, 21 November 2008 (UTC)

I have left my statement of position there already. Please remember that consensus is not about finding a middle ground between all parties, but rather agreeing upon the strongest set of rationale. So far you have failed to counter any of the rationale against the proposal, except by stating that your society is against the images and you believe that consensus should be used. LinaMishima (talk) 03:21, 21 November 2008 (UTC)

I fail to see why there should be a separate standard for 'sexualised content'?
—Apis (talk) 03:17, 21 November 2008 (UTC)

well if it's a sort of synthesis of other policies, or something, it might still serve a useful function as a good place to talk through and develop community consensus.... do you disagree with any of it at the moment? Privatemusings (talk) 03:18, 21 November 2008 (UTC)

WP:CREEP LinaMishima (talk) 03:22, 21 November 2008 (UTC)

yeah - I think you're right that we should be careful of that, Lina - but I think keeping the dangers of WP:CREEP in mind, whilst talking about things is probably the best course of action :-) Privatemusings (talk) 03:25, 21 November 2008 (UTC)

You mean keep in mind that WP:IMAGE and WP:IUP already sufficiently cover not only this issue, but the more general case, too? (i.e, this proposal is nothing but WP:CREEP by definition, and runs the serious risk of infringing upon WP:NOT) LinaMishima (talk) 03:29, 21 November 2008 (UTC)

Lina - it's certainly pretty clear that you're completely resolved about the whole thing! - I hope, and believe that I'm WP:NOT a WP:CREEP, though I do wonder what the hell am I doing here once in a while ;-) - maybe you and I should talk to a few others about stuff for a bit, 'cos I think there's a danger we're talking past each other... best, Privatemusings (talk) 03:33, 21 November 2008 (UTC)

I don't know about you, but I am reading comments and then addressing their arguments rationally and not simply ignore the inconvenient ones. I find it helps. LinaMishima (talk) 03:39, 21 November 2008 (UTC)

Well, I don't understand why there is a need for a special standard for 'sexualised content'. If there is a problem with personality rights, that would apply to all images not just 'sexualised'. This proposal seems more concerned with 'raising the bar' for inclusion of 'sexualised images' and I don't see any reason given for doing so?
—Apis (talk) 03:46, 21 November 2008 (UTC)

I feel that sexual content (not sexualised, which has been pointed out as being not at all what I mean! sorry..) warrants a greater degree of rigour in terms of us (as a project) making sure we're being responsible (as a good web citizen sort of thing) than much material. It's also a specific subset of images for which I think it's reasonable to advocate a specific community discussion / guideline / policy etc. (I'd point to graphic violent images as another subset worth discussing, for example). What do you think about the idea of saying that we'll 'raise the bar' in areas of sensitivity, such as violent imagery, or in this case sexual content, by restricting the use of such images to article space, where a 'present consensus to include' might help a little? cheers, Privatemusings (talk) 05:18, 21 November 2008 (UTC)

you know I think there are some prety sick things on Wikipedia, we shouldent be driving the next generation of conservatives to abandon Wikipedias golden knowledge because of Porn, We should raise the bar on its standards. Who gives a shit if porno articles do not have picture references Wikipedia is not here to show people how to have sex its here for general references and making people not dumb. In my book these pictures should not be in any article. --Zaharous (talk) 05:29, 21 November 2008 (UTC)

<- While I belive some images are useful in articles, the collection above is not encyclopaedic. So I have nominated the page (not the images) for deletion here:Wikipedia:Miscellany for deletion/User:Ewlyahoocom/WikiPr0n --Nate1481 11:54, 21 November 2008 (UTC)

Privatemusings, you have repeated this 'Good Web Citizen' line about ten times, but not actually explained why sexualised content makes us a 'Bad Web Citizen'. Care to elaborate? — Werdna • talk 23:23, 22 November 2008 (UTC)

sure :-) - but in the interests of focusing the discussion at a better spot, I'll take this to the talk page, if I may (I'll copy your post over, and respond) :-) Privatemusings (talk) 23:30, 22 November 2008 (UTC)

Google Analytics

It has frequently been said that Wikipedia doesn't have the server resources to count hits on each page, etc. So why not let Google do it? If Wikipedia were signed up for Google Analytics, we'd get hit counts for all articles and a bunch of other useful stats as well (eg. how much of our traffic was from mobile devices). I bet Google would even be willing to waive the US$1/day AdWords requirement that normally applies to sites of more than 5 million pageviews per month. NeonMerlin 00:56, 22 November 2008 (UTC)

How does http://stats.grok.se/ work then? CIreland (talk) 01:07, 22 November 2008 (UTC)

The WMF privacy policy prohibits the funneling of IP data to third parties, such as Google. Dragons flight (talk) 08:01, 22 November 2008 (UTC)

We don't lack server resources. We lack a hit-counter system integrated into Wikipedia, which I am working on. — Werdna • talk 07:41, 22 November 2008 (UTC)

Astrological signs on articles

Why not list an article subject's astrological sign next to their birthdays? I think there are many readers who would be curious about which sign they were born under. If this proposal has already been made, then please forgive me, as going through stacks of archives is very time consuming. --Crackthewhip775 (talk) 01:25, 22 November 2008 (UTC)

First, because adding an astrological sign would give tacit support to the suggestion that there's some merit to such silliness.

(When I say silliness, yes I'm aware of the role of astrology in the history of science and also in premodern societies. But I'm instead discussing the average role of astrology in the world-view of people using computers to access this encyclopedia. While realizing that Wikipedia is not a reliable source, I quote its article on astrology: Astrology has repeatedly failed to demonstrate its effectiveness in numerous controlled studies. Effect size studies in astrology conclude that the mean accuracy of astrological predictions is no greater than what is expected by chance, and astrology's perceived performance has disappeared on critical inspection.)

Secondly, because those poor deluded souls who credulously consume such twaddle can easily find this non-information for themselves.

I realize that piles of Wikipedia articles on Japanese starlets provide [what is claimed to be] their blood type; of course this is similar twaddle, but perhaps a disproportionate number of the editors and readers of articles on Japanese starlets are very young. (I'd hate to think they instead were "challenged".) Tama1988 (talk) 08:32, 22 November 2008 (UTC)

I think it's a horrible idea. I also don't think blood types should be in articles, and certainly not without a reference to a reliable source. dougweller (talk) 18:52, 22 November 2008 (UTC)

I believe that this isn't a matter of age as such, but rather japanese culture. As I understand it, there is currently a belief in blood types being meaningful, and as such, any japanese readers could reasonably expect to find details (of course, how WP:V these are is another matter]]. Unlike star signs, for which the date of birth effectively already informs you of this, the only way to learn someone's blood type is to be told it. And you never know, maybe wikipedia might help a paramedic out one day! :P LinaMishima (talk) 00:40, 23 November 2008 (UTC)

If people actually care, they can figure it out based on the birthday. Otherwise its just irrelevant trivia. Mr.Z-man 20:34, 22 November 2008 (UTC)

Proposed change to {{POV}} / {{NPOV}}

• Template:POV (edit | talk | history | links | watch | logs)

The correct place for this would be Template talk:POV but I don't imagine many people watch that page so I'm bringing this here.

The template which is widely used throughout Wikipedia currently reads:

The neutrality of this article is disputed.

The placing of an {{NPOV}} tag is one of the most frequent causes of edit wars and rancorous disputes. The reason for this is, I think, fairly obvious: The addition of {{NPOV}} is not simply a comment on the article, it indirectly affects the article content. By labelling the neutrality of the article as "disputed" it suggests to the reader that the article contains bias - this is why we have so many edit wars over this tag - adding it to a largely neutral article serves to push the article away from neutrality.

More controversially, I have seen a number of occasions where editors, failing to achieve consensus for their preferred version through discussion, will resort to the use of {{NPOV}} in order to, at worst, skew the article or, at best, scorch the earth. Both are unacceptable.

In short, the way in which {{NPOV}} is often used is at odds with the neutral point of view policy.

Consequently, I would like to either change the wording of the template or deprecate its use. I suggest the wording:

The neutrality of this article is being discussed.

I would be very interested in any comments or any suggestions for alternate wordings.

CIreland (talk) 00:44, 22 November 2008 (UTC)

"neutrality" is pretty much a Wikipedia term of ar, with a specific technical meaning. Since this message appears of article pages read mostly by those unfamiliar with such specifics, I suggest, the fairness of this article is being discussed. DGG (talk) 23:52, 23 November 2008 (UTC)

Good point there! Your suggested wording would also help reinforce WP:DUE, which 'neutrality' often seems to make editors forget, in my experience. LinaMishima (talk) 01:15, 24 November 2008 (UTC)

I agree with DGG about the issue with "neutrality". Another idea, which I'm not sure whether I like or not, would be "The fairness and balance of this article is being discussed" and possibly append "on [[the talk page]]". CIreland (talk) 02:59, 24 November 2008 (UTC)

submitting a new page about a person

I would like to know if I can submit page about the biography (and related stories / issues) of a local public official - a police chief. If this is possible, please let me know. I have navigated around the site and I have not been able to determine if this is OK and if so, where to submit the proposed article / page.

Dave Duffy

Wikipedia may be contributed to by anyone - feel free to just create an article about the official and see what the community thinks of it! However, please keep in mind our policies and guidelines, and understand that if the article is considered to not meet them, it may be removed. Most importantly, you need to make sure that all details you list are verifiable and from reliable sources. There are some specific rules to be used when writing about someone alive, and there is also a guideline on notability for people, which advises how to judge when a person is notable enough to result in a good quality, long-lasting, article. Good luck! LinaMishima (talk) 00:36, 23 November 2008 (UTC)

Hi Dave. Like LinaMishima said, yes, it's okay to create an article about someone. In my opinion, the main thing to think about is the notability guideline. Read the "Basic criteria" section for a brief overview. A new article about a person should show that they are notable by citing reliable sources. To speak plainly, if enough editors think that the subject of the article is not notable, the article will probably be deleted. Don't worry too much about the fine points of formatting, other editors can fix that later. As for how to submit a proposed article, the procedure is to just go ahead and create the article. You'll need to have an account and be signed in, but that part's easy. I recommend that you read the Wikipedia:Tutorial, it's pretty short and it covers all the important basics. Have fun. — Mudwater ^(Talk) 13:06, 23 November 2008 (UTC)

Article Tooltips

Whenever I am reading up on a subject of interest (especially a subject which I am not an expert on) I find myself clicking a lot on the blue links within the article just to find out what things are. This made me think of a specific feature in the chat client known as Trillian. In Trillian, certain words that appear in conversation can be moused over for a tooltip with a short preview of that page on Wikipedia. I think that this would be a very useful feature to apply to the blue links on Wikipedia. This way, a reader could mouse over the link for a quick definition or explanation, and if they wish to read more they can click on it and open the article. The reader will not have to open up a whole other article just to find out what a word refers to. I do not have a deep understanding of how Wikipedia works, but if it is possible I think that article tooltips would be a very useful feature on Wikipedia. DE5933 (talk) 16:47, 23 November 2008 (UTC)

Sounds a bit like Popups. Algebraist 16:50, 23 November 2008 (UTC)

Place former names, titles, motto, slogans and whatelse, in one place.

I made a test template at User:JSH-alive/Sandbox/Testground (or http://en.wikipedia.org/w/index.php?title=User:JSH-alive/Sandbox/Testground&oldid=253731034 for the specific revision). You can put in on any kind of infobox. Comments are welcome. - JSH-alive ^(talk)_(cntrbtns)^{(mail me)} 04:29, 24 November 2008 (UTC)

WP:DASH

Please read the discussion at Wikipedia_talk:Manual_of_Style#Categories.

• WP:DASH

This concerns the sections at WP:MOS concerning the "dash", and whether it should be applied to category-space.

The section makes a presumption that automatic redirects may be made (as is typical in mainspace, and other spaces).

But that isn't the case in category-space. We're limited to soft-redirects there. (And there seem to be concerns about a certain bot. See the discussion for more information.)

So realistically, if this section is applied, then we'd be duplicating every category which has a "dash" in it's name.

And also, having category redirects means that they are bluelinks. Which means that they have the potential to be categorised themselves, which can cause issues, which may not be noticed by the casual observer.

And further, the whole point of categories is navigation (as noted at WP:CAT). So forcing category names to make it more difficult for those who don't have an "en dash" on their keyboard, would seem to be a hindrance to navigation.

Therefore, I'd like to propose that categories be an exception to WP:DASH. So in categories, the hyphen is to be the preferred punctuation used. - jc37 07:20, 4 November 2008 (UTC)

• Responses to the above arguments in turn:

1. The redirects are handled by the bot, User:RussBot. No specific concerns have yet been offered about how this bot works - it seems to do the job well.
2. Duplication would indeed occur, as it does with articles. But if the proposal is accepted, then we should probably duplicate the categories anyway, to allow for the people who – reasonably – expect dashes there.
3. The possibility of redirects being themselves categorised applies to all redirects, and is not a significant problem anyway.
4. The navigation problem is solved by the redirects – if it isn't solved already by inbuilt search-box functionality, which I suspect it is.--Kotniski (talk) 16:57, 4 November 2008 (UTC)

Kotniski: Sorry but you don't seem to understand how category redirects work. (Or rather, how bad they work.)

--David Göthberg (talk) 18:19, 4 November 2008 (UTC)

Well, whose fault is that? I keep asking for explanations, and don't get any. I therefore naturally conclude that these "problems" are simply someone's invention. Tell me what they are and I'll probably change my opinion.--Kotniski (talk) 15:58, 5 November 2008 (UTC)

There is really no such thing as a category redirect. All that exists is the template {{Category redirect}} which allows those who have clicked on category A to read text suggesting that they click further to category B. This is much weaker and less useful than a true redirect would be - another case which the developers could fix, but have not. Septentrionalis PMAnderson 19:26, 5 November 2008 (UTC)

Straw Poll

Oppose (prefer en/em dashes)

• Oppose and support stating explicitly in the appropriate guidelines that dashes should be used when style requires it. The problems claimed to exist with dashes in category names appear to be imaginary. Use of hyphens instead will lead to inconsistency with article names and other article text, causing not only an inferior output for readers, but leading to hypercorrections (or mis-pastings) on the part of more literate or intuitive editors. --Kotniski (talk) 09:34, 4 November 2008 (UTC)

  Considering the concerns of others at the discussion, I'm not sure how you can assert that the problems are "imaginary". - jc37 10:16, 4 November 2008 (UTC)

  Well, all the concerns I know of have been answered. If there are real problems, let's hear them.--Kotniski (talk) 13:29, 4 November 2008 (UTC)

• Oppose If the possible lack of RussBot longevity is that much of a concern, soft redirects from the hyphenated titles are sufficient, so there is really no need for an exception from MOS:DASH for category names. However, if something did happen to RussBot, it would not be that much trouble for someone else's bot to take up the task. The bot source is even available, so all that would be needed is for someone to install pywikipedia and start running it. Anomie⚔ 21:55, 4 November 2008 (UTC)
• Oppose. Categories should never be an exception to any naming guideline, they are part of the encyclopedia and should conform to the same naming guidelines as articles. Also: the lack of a particular character on certain users' keyboards should not be taken into account in any naming guidelines, naming guidelines should be about using the correct names, regardless of whether or not any particular user can type them. MTC (talk) 16:59, 5 November 2008 (UTC)
• Oppose—it's possible to fix the problem, and we have an acceptable, though not ideal, solution in place at the moment. Allowing the preferable em/en dashes in category space for now will help ease the transition later to a better category redirect system, and avoids conflicts with article names or obtuse exceptions from the Manual of Style for category pages. {{Nihiltres|talk|log}} 17:21, 5 November 2008 (UTC)
• Oppose. Editors who read WP:DASH, or are creating categories named after articles with en-dashes, will create the en-dash-named categories anyway, so the efficacy of category redirects is not a reason to support. That leaves consistency of style as the primary reason to have the en-dashes. — Arthur Rubin (talk) 18:58, 6 November 2008 (UTC)

  If this proposal achieves consensus, WP:DASH would be updated to reflect this. And it would also mean that renaming the categories would fall under speedy. So the categories would be consistent. - jc37 19:11, 6 November 2008 (UTC)

  Yes, with each other (which would at least be an improvement over the present situation). But it would be even better for them to be consistent with article space (not just for appearance, but because people are likely to copy and paste "between" these two spaces).--Kotniski (talk) 09:52, 7 November 2008 (UTC)

Support (prefer hyphens)

• Support - Until category redirects work as they should (automatically categorizing into the _target category), they should be something to be avoided, not proliferated. Mr.Z-man 17:51, 4 November 2008 (UTC)
• Support The proposed system of relying on a bot is too jury-rigged for my liking. If we could get a built in function in MediaWiki to do this, I would be ok with en/em dashs in categories. MBisanz ^talk 17:59, 4 November 2008 (UTC)
• Support - I type in category names from the keyboard all the time, and I don't have an en dash on my keyboard. And it makes it harder to copy and paste the category names. (Yes, some of us are stuck with old computers with bad operating systems, pardon me for not being able to afford a new computer.) But most importantly, if/when RussBot stops working the category redirect system goes from somewhat broken to very broken, so we can not rely on category redirects. But even when the bot is running there are some problems with category redirects, thus it is better to not rely on redirects. --David Göthberg (talk) 18:19, 4 November 2008 (UTC)
• Support until category redirects work. Dendodge Talk^Contribs 22:03, 4 November 2008 (UTC)
• Support I don't see the real need for em dashes or en dashes in the first place. Reywas92^Talk 22:10, 4 November 2008 (UTC)
• Support Things should be human-typeable unless easy ways around it exist. When the redirection is fixed, then we can use dashes. Shoemaker's Holiday (talk) 07:03, 5 November 2008 (UTC)
• Support Given the way that categories are redirected, the inability (or unwillingness) to use en/em dashes when assigning categories creates far more problems than any benefit gained through compliance with WP:DASH. Alansohn (talk) 15:40, 5 November 2008 (UTC)
• Support hyphens until category redirects automatically categorize articles into the correct category. Relying on a bot is problematic, and using hyphens eliminates that. --Kbdank71 16:10, 5 November 2008 (UTC)
• Comment: It would be more helpful if those voting, instead of repeating arguments that have already been apparently refuted, could address why they think the refuations are wrong. Then we might actually get somewhere. This isn't an issue to be solved by counting votes; it involves actual technical problems that we should be working together to identify and (if possible) solve. Just counting how many people believe what unsupported claim doesn't seem a very constructive way of proceeding.--Kotniski (talk) 16:13, 5 November 2008 (UTC)
  • "Apparently" being the key word there. I don't think you have refuted any argument. You continue to say we should rely on technical solutions to a problem, technical solutions that require more work for editors, readers, Russ, and now the devs, when a much simpler solution would be to use a typeable hyphen in category names. I'm sorry, but I still don't buy the "for style" argument to force everyone to jump through all these hoops. --Kbdank71 16:39, 5 November 2008 (UTC)
    • More work? Hoops? For whom? Editors can still type hyphens if they're that lazy (I wonder what these same editors do when a dash is required in an article they're writing?); readers can certainly type hyphens on the (very rare) occasions they might type a category name; and the bot owner and the devs won't be doing any extra work on account of hyphens and dashes, as the issue of category redirects is a much wider one. I know some people don't consider "style" to be important, or would prefer the whole of WP to be in ASCII, but the community has long decided it wants the encyclopedia to follow a good and consistent style of English using the full range of available characters, and we should be prepared to make (at least very minor) sacrifices to maintain that valuable goal. (And we shouldn't be using this specific category issue as a vent for our views about punctuation in general if we know them to be against community consensus.) --Kotniski (talk) 17:40, 5 November 2008 (UTC)
• Support. I don't see why we need dashes in the first place. I'm not convinced by the "for style" argument; I think dashes are ugly and that they shouldn't be used at all unless they're specifically being discussed; we should aim to use "real" characters from the ASCII set whenever possible for usability, not sprinkle these kind of flourishes throughout the project. Celarnor ^{Talk to me} 17:33, 5 November 2008 (UTC)

• ASCII = real? Let me guess - you're a computer scientist, right? --Kotniski (talk) 17:47, 5 November 2008 (UTC)

• Affirmative. It's in UTF-8, but I don't see any need to use it when there's a perfectly good ASCII equivalent available. I don't think it adds any benefit; in fact, I think it's more ugly than a hyphen, so I don't really see any reason to do this. Celarnor ^{Talk to me} 17:52, 5 November 2008 (UTC)

• Support. Requiring dashes would make it more difficult for readers to use and consult categories to the extent that a "category redirect" is worse than a real redirect and to the extent to which redirects from hyphen to endash fail to exist. Typing in [[category:Foo[hyphen]Bar]] and getting nowhere, when [[category:Foo[dash]Bar]] exists and would have been titled with a hyphen without this rule, is the worst possible outcome. Doing all this for a debatable typographical nicety is uncalledfor. Septentrionalis PMAnderson 19:32, 5 November 2008 (UTC)

Category redirects do exist and do work though, as is continually being explained. They don't even rely on a bot. The bot is required only to move pages out of the redirected category to the _target one (on the rare occasions that editors declare the category using the wrong name).--Kotniski (talk) 11:57, 6 November 2008 (UTC)

Show me an example of their "working", please; the ones I've seen don't really work. Septentrionalis PMAnderson 18:32, 6 November 2008 (UTC)

Well, there are two types of redirect - hard and soft. Hard ones work normally; soft ones require an extra click. Category:Poland topics is an example of a soft one; its previous incarnation (see the history, before the bot changed it) was an example of a hard one. There seems to be a belief (possibly founded on the same sort of superstition that we've seen in this debate, but possibly there's a genuine reason for it) that the redirects that the bot handles have to be soft ones. This means one extra click for readers, on the very rare occasions that they may type a category name into the search box and that category is redirected. Is this what you mean by not working? Or is it the fact that there's a time delay between an article's being added to the "wrong" category and its being moved to the correct one? If the rare extra click is felt to be a problem, then the best solution would be to push for hard redirects (with a message on the _target page - this should be there anyway - that there may be additional pages temporarily categorized at [hard link to redirected cat]). The other problem - the time delay - has already been raised of course, and it's best solved (if it's felt to be significant) by editors' putting articles in the correct category to start with. Entering a dash isn't really a big deal (I imagine all serious editors who write stuff in English are used to it by now); indeed, when you're copying and pasting a phrase from article text, the dash is more likely and more natural.--Kotniski (talk) 10:12, 7 November 2008 (UTC)

"Entering a dash isn't really a big deal" - yes it is. The thing you seem to be forgetting is that categories are not content-space. They are merely intended to be used for navigation purposes. So ease of use for navigation trumps style. - jc37 20:02, 7 November 2008 (UTC)

It's "reader-facing" (i.e. intended for readers to look at, and hence part of the Wikipedia product), so style is important. With maintenance categories, intended for editors, I don't care so much, but for those used by readers, we should make an effort (and it really is only a tiny effort - indeed for many editors it would be more of an effort to remember or find out that we have different rules for categories than for other things, and to change dashes to hyphens when they do copy-and-paste).--Kotniski (talk) 09:59, 8 November 2008 (UTC)

• Support. For usability, ease of navigation and editing, I prefer hyphens to en-dashes in nearly all contexts. I realize there is a typographical distinction that some people feel is important, but frankly I see little value in that distinction where it interferes with editing. In most contexts, I'm more comfortable with the use of em-dashes, which provide a greater degree of distinctiveness, though without true redirects those also seem problematic for categories. Dragons flight (talk) 19:59, 5 November 2008 (UTC)
• Support; the use of hyphens improves usability for editors and readers while being equally clear, unambiguous, and aesthetically appealing. Considering the extra problems caused by the use of en-dashes, one would expect there to be an actual reason for their use in place of hyphens, yet none has been put forward. Christopher Parham (talk) 00:40, 9 November 2008 (UTC)

Do people actually read the previous debate before voting? The reason is good English style and consistency with article names and article text. And the "extra problems" have been shown to be mainly an illusion (at least, there may be slight inconveniences, but they apply just as much to the use of hyphens where many editors would expect dashes).--Kotniski (talk) 08:27, 9 November 2008 (UTC)

From a style perspective I'm fine with the hyphen. It is equally clear, equally attractive, completely unambiguous, etc. There is no actual reason to recommend against its use. I'd be happy to ensure consistency by moving article titles. No editors would "expect" dashes in my view, since everyone is very familiar with the natural use of the hyphen in this situation, so I see that as a non-issue. Christopher Parham (talk) 23:07, 9 November 2008 (UTC)

You think "no" editors know or pay any attention to what it says in the Manual of Style? Maybe you don't, but I think the vast majority of serious editors - at least, of those of the type we would like to encourage - do know what it says there and try to follow it, and expect it to be followed.--Kotniski (talk) 17:30, 10 November 2008 (UTC)

I am deliberately not taking the current MOS guidance into account; current decisions shouldn't be bound by poor decisions of the past. Rather, past decisions should usually be amended to reflect the new, improved judgment of today. Were there no MOS, editors would be unsurprised to see hyphens since that is a normal, clear, and attractive way of presenting English text. Christopher Parham (talk) 23:19, 10 November 2008 (UTC)

• Support. Category redirects don't work and implementing the illusion of them creates far greater problems than the supposed cosmetic problems of the hyphen. older ≠ wiser 23:27, 9 November 2008 (UTC)

  Go on then, why is it an "illusion" that category redirects work? I presume you have read the remainder of this discussion, which seems to have established that they pretty much do work.--Kotniski (talk) 17:30, 10 November 2008 (UTC)

  While I appreciate that that's your interpretation, I'm not seeing that in the responses/comments from the coders (and others) who have commented thus far. And "pretty much do work" doesn't necessarily equal "they work". - jc37 17:33, 10 November 2008 (UTC)

  So in what way do you continue to think that they don't work? And what makes you so confident that they aren't needed if we use hyphens instead of dashes? Perhaps we should divide this issue into two questions: 1) dashes or hyphens? 2) redirects or redlinks? The two questions are independent (despite what many seem to assume) and I think we're quite close to establishing what the arguments on both sides are in each case.--Kotniski (talk) 17:41, 10 November 2008 (UTC)

  Kotinsky, No, I've not seen that this discussion has established that category redirects "work" in any useful way. older ≠ wiser 18:32, 10 November 2008 (UTC)

  Well, all the claims that they don't have so far been rebuffed. If you know of other ways in which you think they fail to work, let's hear about them. --Kotniski (talk) 13:15, 12 November 2008 (UTC)

  "Rebuffed" is an excellent word. But then, another way to accurately portray your comments might be: "I'm ignoring others' good faith concerns, and merely want what I want." If you feel that I'm mischaracterising your comments, please feel free to clarify. - jc37 01:00, 13 November 2008 (UTC)

  Unsurprisingly, I do feel you're mischaracterising my comments. I would put it like this: I'm doing my best to address others' good-faith concerns wherever they're expressed, but others seem, instead of engaging in dialogue with me over the specific issues, simply to repeat the same general "they don't work" mantra that we started out with. I suspect it's either because they can't be bothered to go into the analysis, or because they don't want redirects to work because they don't attach any value to good punctuation from the outset. Or (in some cases) that they are simply convinced by what I say and see no reason to respond further.--Kotniski (talk) 13:35, 17 November 2008 (UTC)

  Very good point Jc37. Category redirects are broken because they do not work in the way any sensible user would expect them to work, and they require a bot to correct the kludgey misbehavior. That, to me, is not acceptable to make into a recommended standard. older ≠ wiser 12:43, 14 November 2008 (UTC)

• Support. Since category redirects are broken, I believe it's a bad idea to create categories with dashes, let alone encourage or require them. - Mgm|^(talk) 10:53, 17 November 2008 (UTC)

Other opinions

• Use "hyphens" everywhere. The English language only needs one punctuation mark in the form of a horizontal line. Why waste brain cycles trying to remember which length of line is correct, or fixing "errors" by switching between characters that look pretty much exactly the same? Let's all just use the button that's already on our keyboards, and use "-" for everything. -- Beland (talk) 17:51, 6 November 2008 (UTC)

• I can't express how much I agree with this. Celarnor ^{Talk to me} 00:20, 10 November 2008 (UTC)
• Yeah, I'm good with this as well. --Kbdank71 14:25, 10 November 2008 (UTC)

• That's not the issue being discussed here, though. WP has a very well established consensus about the use of hyphens and dashes in general, based on the fairly unanimous recommendations of respected English style guides. Personally I would change some of the rules we apply (not insisting on dashes for "disjunction", for example), but more important than the details is that once we have these rules, we should apply them consistently. --Kotniski (talk) 17:35, 10 November 2008 (UTC)

• While you're right in that this was not the initial proposal, anyone can obviously offer their own proposal for discussion. Straw polls are not "votes", so any and every opinion is to be weighed in closing the discussion. - jc37 17:42, 10 November 2008 (UTC)
• once we have these rules, we should apply them consistently Or, as consensus can change, we can discuss and change the rules as we see fit. --Kbdank71 17:52, 10 November 2008 (UTC)

• I mostly agree with Beland here. That is, I think we should use ASCII hyphens in both category and article titles, so they are easy to type and copy and paste into other mediums such as emails and pure text files. Thus making it much easier to find and reuse the Wikipedia content. However I think we can use en dashes in the article texts. Since if the en dash becomes a junk character in the article text when for instance an email program can't handle it, then it doesn't hurt that much. But if we get junk characters in the article title that causes much more problems. --David Göthberg (talk) 03:47, 25 November 2008 (UTC)

Comment on poll so far

seems to me that most of the votes are invalid, since they assume that redirects dont work, when in fact they do. But if we don't trust the bot to do it, let's ask the devs to build it in to the system (it can't be that dififcult). Propose suspending voting until we get a reply from the devs as to how long this would take (unless someone knows of such an idea's having been proposed/rejected already).--Kotniski (talk) 08:14, 5 November 2008 (UTC)

Looks like the issue is one that's come up before - see Bugzilla 3311 (and vote for it, if you believe that has any effect). Seems the issue is solvable, but no devs are in any hurry to do it. But still, we have a perfectly efficient bot to tide us over, and as Anomie points out, if Russ stops running it then someone else can take over. (And the redirects continue to work even without the bot - the bot is only needed for moving any articles that happen to be put into the other category.) So these alleged "problems" seem to boil down to just one - if an article is placed in one of these categories by an editor who doesn't know when dashes are required or is in too much of a hurry to paste/java-ize one in, then it won't show up on the _target page until the next bot run (typically 24 hours max.). But even if this is considered a significant argument, let's remember that it works the other way round too - if the article is added by an editor who doesn't know about the hyphen-only policy or makes the category declaration by pasting the phrase in from elsewhere, then we're back in the same situation.--Kotniski (talk) 13:42, 5 November 2008 (UTC)

You've said this repeatedly. And yet those above still disagree with you.

Huh?? Let them speak for themselves - none of them have responded to me yet. K

In the discussion that led to this, you said you were waiting for User:Davidgothberg to comment. He now has. (As have several other coders.)

Another huh?? I was waiting for them to comment by explaining the "real problems" with the bot. It seems so far there aren't any (except that it might stop working; but then someone else can take over). K

And no, it doesn't work "the other way round". If an editor uses the dash instead of a hyphen, then the category is simply renamed. No need to duplicate mountains of categories with category redirects. - jc37 14:09, 5 November 2008 (UTC)

A third huh?? Who's going to rename the category? (OK, maybe the red link might be a warning cue to the editor, but who's to say he won't react by creating the redlinked category - or just giving up and deleting the cat declaration - instead of searching for the hyphenated one?) And we're not talking "mountains" of anything here - the number of redirects involved would be very small compared with the number WP has already, and redirects cost hardly anything anyway.--Kotniski (talk) 14:48, 5 November 2008 (UTC)

Kotniski: No, it doesn't take only 24 hours for the bot to move a page from the soft redirected category to the correct category. First of all the bot has a "standoff period", among other things to prevent it from mass editing pages if a category redirect is changed erroneously. That is, to give humans the chance to correct the redirect before the bot edits all those pages. As far as I know that "standoff period" is one week. Then the Wikipedia servers run category list updates as a low priority job, which means that during periods of high server load it can take up to a week before a page is visible in the right category. And this happens more often than most people think. That makes it a total of up to two weeks before a page is visible in the right category, provided the bot is up and running. If the miscategorising is due to a template, then it often takes more than three weeks before most of the pages are shown in the right category. And in the template case, for pages that get no visitors, it can take "forever". But for now I'll skip the long and complex explanation why that is so.

Regarding "invalid votes": Now that is very undemocratic of you, claiming that the votes you disagree with are invalid. We have already explained some of the technical issues here, and we already have linked you to the more in-depth discussions of the problems over at Template talk:Category redirect. Your failure to understand the technical issues at hand is your problem, not ours. But this is tricky stuff, so I don't blame you for not understanding. Instead I blame you for not accepting that you do not understand.

Remember, categorisation is a technical tool. It is not pretty article text. But I guess your next _target will be to demand that we use Unicode symbols, instead of ASCII, in template and javascript programming, right? That is, ≠, ≤, ≥, − and ×, instead of !=, <=, >=, - and *. I wonder if there is a Unicode symbol for a long equal sign? The symbol we use for equal comparisons, what we in ASCII write as "a == b". Perhaps it is called "em equal"? :))

By the way, to avoid most of the technical problems we should perhaps ask the devs to make it so the category system interprets hyphen, en dash and em dash as the same symbol? So it doesn't matter which one we use. And that would be helpful even if/when they have fixed the other issues with the category redirect system.

--David Göthberg (talk) 19:57, 5 November 2008 (UTC)

Well, {{#expr}} was recently changed to recognize − in addition to -. Anomie⚔ 22:17, 5 November 2008 (UTC)

There's U+2263, which is the symbol for "Strictly equivalent to"; I guess you could use that for a long equals.  :) Celarnor ^{Talk to me} 22:12, 5 November 2008 (UTC)

OK David, thank you for finally explaining what you think the problems are. (Even the most intelligent of us can't understand things we're not told.) (And I don't know what you're going on about with Unicode in programming - obviously no-one's proposing that.) But I still don't see that the problem you cite - the standoff one - is applicable in this case. It's a problem that occurs once, when you change the name of any category. It will likely occur, for example, when categories are changed from dashes to hyphens according to the proposal. It isn't a problem that (as far as I can see) affects the later maintenance of redirected categories, so I don't see its relevance to this debate. When I change a page's category I always seem to see it in the new category straight away, so I don't see that in practice there is much delay in the updates happening (and if anyone's in that much of a hurry to get their article categorized, they can spend the extra five seconds it takes to enter the dash symbol to start with). Problems with templates I do understand (I'm not as totally ignorant as I might appear), but again, that's not very relevant, since I imagine the number of existing templates that impose hyphen-for-dash categories much be close to zero (for maintenance categories I can accept hyphens, since they're hidden from readers), and any new templates so created can be created with the dash already in place. --Kotniski (talk) 11:48, 6 November 2008 (UTC)

WP:DASH – Summary so far

Category redirects behave as follows:

1. Going to the redirected category page takes you to the _target page, just as with any other redirect.
2. If the redirect is formatted as #REDIRECT [[Category:foo]], the redirected category will show up as a subcategory of Category:foo.
3. If the redirect is formatted as #REDIRECT [[:Category:foo]], the redirected category will not show up as a subcategory of Category:foo.
4. Pages placed into the redirected category are not automatically placed into the _target category.
5. To fix #4 above, User:RussBot periodically moves those pages into the _target category. If RussBot ever stops working, it would be trivially easy for anyone else to run a new bot doing the same thing.

Supporters of the proposal to make an exception to WP:DASH cite the following reasons:

1. Item #5 above is not sufficient to counter the trouble that #4 causes, as the correction is not done instantly.
2. RussBot does not empty newly-redirected categories until 7 days after the last edit. This may lead to several weeks' delay in updating the pages in pathological cases.
3. It is easier to type a hyphen on standard keyboards.
4. WP:DASH should be overturned completely, not just with respect to categories.

Supporters also make the following nonsense arguments:

1. "Category redirects are broken." Too vague. This could be referring to supporting reason #1, but it could also be that people believe that behavior #1 is not the case or that they are unaware of behavior #3.
2. "It results in unnecessary duplication of redirects." This happens with all non-category pages that WP:DASH applies to too.
3. "Redirected categories are not redlinks". This happens with all non-category redirects too.
4. "People might enter the hyphenated version into the search box or url". That is what redirects are for.
5. "There is no such thing as a category redirect." This is false.
6. "All category redirects must be soft redirects." This is false from a technical standpoint.
7. "I don't trust RussBot." There is no reason not to trust it. If the slightest bot downtime is that much of an issue, duplicate bots could be run concurrently.
8. "Categories are not content." Some are not, but many are.

Opponents of the proposal cite the following reasons:

1. Item #5 is sufficient to counter #4.
2. Categories that are part of the encyclopedia (as opposed to maintenance categories) should follow the same style guidelines as the rest of the encyclopedia.
3. The proposed exception would cause category names to not match the corresponding article names, when there is a correspondence.
4. Dashes are easy to enter using the buttons at the bottom of the page, or by copying and pasting the category name.
5. RussBot's 7-day cooldown is irrelevant. The person creating the new redirect should empty the old category before redirecting it.

Opponents also make the following nonsense arguments:

1. "Category redirects are not broken." Too vague. This could be referring to opposing reason #1, but it could also be completely ignoring behavior #4.

Frankly, I find much of the previous discussion confusing. We have three options being discussed above: "Everything uses dashes", "Everything except categories uses dashes", and "Nothing uses dashes". People !voting "oppose" are choosing the first option, but people !voting "support" may be choosing the second or the third, and it's often impossible to determine which. Anomie⚔ 21:17, 12 November 2008 (UTC)

You've got the category redirects wrong. Categories are not redirected with #REDIRECT [[:Category:foo]]. They use soft redirects, as is used at Category:Manchu people. You are not automatically taken to the _target category. --Kbdank71 21:39, 12 November 2008 (UTC)

Have you actually tried it? It works fine. Whether or not the feature is commonly used at this time is irrelevant. Anomie⚔ 23:58, 12 November 2008 (UTC)

From a technical standpoint, yes it works. But usability-wise, it doesn't work at all. Say Category:Manchu people was a hard redirect. You go there, it automatically takes you to Category:Manchus. It works fine, right? Now edit an article and add it to Category:Manchu people. Save it. If you click on Category:Manchu people in the article, you are instantly taken to Category:Manchus, but the article isn't there, because it's sitting in Category:Manchu people. Your casual reader isn't going to understand what happened. So, the soft redirect. It is extremely relevant as to why hard category redirects are not used. --Kbdank71 00:10, 13 November 2008 (UTC)

Hence RussBot. Anomie⚔ 01:28, 13 November 2008 (UTC)

And as you summarized above, RussBot does not empty newly-redirected categories until 7 days after the last edit. And speaking of the summary, did you have anything to add to it, or are you still confused? --Kbdank71 01:39, 13 November 2008 (UTC)

And as I summarized above, RussBot's 7-day cooldown is irrelevant. The person creating the new redirect should empty the old category before redirecting it. I was hoping that by summarizing that it would help the discussion move forward instead of continuing to go around in circles. Anomie⚔ 02:40, 13 November 2008 (UTC)

protecting minors from themselves in userspace

Oversight requests frequently relate to a minor using {{User infobox}}, or some other person infobox, and filling it in with their precise birthdate, and other identifying information.

This is the most recent case:

Wikipedia:Administrators'_noticeboard/Incidents#Location_details_of_Minor

Would it be reasonable for templates like {{Birth date and age}} to "break" when they are used in userspace, and the parameters indicate that they are a minor? Should we protect them from themselves? Are there good reasons to not do this? John Vandenberg ^(chat) 21:16, 23 November 2008 (UTC)

Wikipedia:Requests_for_arbitration/Protecting_children's_privacy#Self-identified_children seems to say yes, we need to disable that template for minors. MBisanz ^talk 21:21, 23 November 2008 (UTC)

(edit conflict) How so? Wikipedia:Requests for arbitration/Protecting children's privacy#Self-identified children just points out that someone claiming to be a child may be lying. Nor do any of the proposed remedies there suggest breaking templates. Anomie⚔ 23:11, 23 November 2008 (UTC)

(edit conflict) IMO, that would be completely useless. For one, the child's information would still be there, in the page history if not in the broken template invocation on the current version of the page. If the kid is intelligent enough to figure out parser functions, they might just copy the age-calculating code out of the template without the "block minors" section, and if not they might just forgo having it automatically calculate their age and put it there in plain wikitext. It also does nothing about children posting their full name, photograph, school location and schedule, and all manner of other information best kept private.

A better technical solution would be for Wikipedia to just reject all pageviews with the RFC 3514 "evil bit" set, so anyone looking at userpages trying to find children to exploit would be automatically blocked. ;) Seriously, though, I think the second and third proposed remedies in the mentioned arbcom case are the best course of action: block trolls pretending to be children, and oversight the personal information of actual children. Anomie⚔ 23:11, 23 November 2008 (UTC)

Whilst I completely agree with the suggestion here, the section heading isn't quite fair - it's not the minors who pose the risk to themselves, and in an ideal world, the risk wouldn't exist :P A simpler "protecting minors privacy" would suffice in future, I feel LinaMishima (talk) 22:35, 23 November 2008 (UTC)

See Wikipedia:Protecting children's privacy. Also note that we have a myriad of userboxes to identify users as teens, students and the like. --—— Gadget850 (Ed) ^talk - 18:18, 24 November 2008 (UTC)

Consensus at Category:Albums by producer

There seems to be a split regarding whether or not Category:Albums produced by Richard Landis should exist due to the fact that Richard Landis doesn't have an article and is very unlikely to have one. I would like to establish some sort of proposal that producers should not have individual subcategories unless a.) they are the sole producer of several albums, and b.) they meet WP:N. I have found absolutely no sources for Landis that do not directly tie to the artists he's produced for, and can't possibly imagine why anyone would want this category kept (he's only produced about 10 albums anyway, what's the big deal?). I would like to gather others' opinions first, though. Ten Pound Hammer and his otters • ^{(Broken clamshells • Otter chirps • HELP)} 19:58, 24 November 2008 (UTC)

User:Secret/Attract More Editors

I would welcome contributions and comments for this new proposal to attract editors. Thanks Secret ^account 21:36, 24 November 2008 (UTC)

P: and T: Pseudospaces

According to [4] and [5], 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)

• Support - this suggestion looks like it will only do good. It Is Me Here (talk) 09:54, 16 November 2008 (UTC)
• Support - this is a good idea, plus it would make it easier to link to an article (i.e. [[C:Category]] instead of [[:Category:Category]]). -- Imperator3733 (talk) 16:50, 17 November 2008 (UTC)

  That won't be the case, you'll still need to write [[:C:Foo]]. But it still makes it a lot easier to type. Happy‑melon 17:28, 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)

• Support. This proposal makes sense, and I see no obvious problems with it. Ruslik (talk) 20:23, 17 November 2008 (UTC)
• Support for P: and T:; Oppose for C: for practical reasons - using a category page as a redirect (such as C:CSD->Category:Candidates for speedy deletion) is problematic. Additionally, not all existing C: pages are redirects to categories - out of 24 of them, 6 are redirects to articles, and 3 are articles. עוד מישהו Od Mishehu 07:09, 18 November 2008 (UTC)
• I've committed a bug for this (T18452) for the P: and T: pseudospaces only. Please do continue to comment and indicate support if you think it's a good idea; the stronger the consensus we can present to the developers, the more likely they are to make the change. Happy‑melon 22:38, 24 November 2008 (UTC)
• Oppose, (a) not really necessary, I still don't buy it that cross-space redirects are harmful [the reusers argument seems to be mostly hypothetic], (b) it seems overkill to reserve all these areas for non-articles, while Od Mishehu notes that these typing aids would mean we'd have to rename existing articles to suboptimal names. Kusma (talk) 09:55, 25 November 2008 (UTC)
• Weak Support - I like this, though my main concern is whether users may confuse T: for Talk: (which would seem more intuitive). As a user (I presume) is more likely to (more often going to) link to talk namespace than to a template (as templates are more likely to be transcluded, in which case the antecedent of Template: is already presumed), perhaps we should go with TEMP: (or something similar) for template space? - jc37 17:09, 25 November 2008 (UTC)

  As far as I know, that's not in line with actual practice. While I agree with your hypothesis that such links should be more common and intuitive, if you look at the list of redirects we have you see that most if not all of them are, in fact, to the Template: namespace. The hardcoded namespace alias should reflect current practice. Happy‑melon 19:13, 25 November 2008 (UTC)

  • What about having Ta: or TA: redirect to Talk:? I couldn't find any articles that started with either of those prefixes. -- Imperator3733 (talk) 19:25, 25 November 2008 (UTC)
    • We could do that as a phase II, but I wanted to focus on P and T right now since those create the least unresearched situations. MBisanz ^talk 22:01, 25 November 2008 (UTC)

mbox type names

Right now, the current type names listed are:

• speedy / delete / content / style / notice / move / protection

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.

• Rename the orange-level of content to caution
• Rename the red-level of delete to warning

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

• I obviously support this proposal, for the reasons I noted above. - jc37 15:18, 20 November 2008 (UTC)

• This seems like a good idea, but there is a slight modification that should be made to the conversion plan. If we change the name in the code, and then change the name in the templates, there would be a small period where templates would be pointing to the old name, which wouldn't exist. We also couldn't change the templates first, since there would be the same problem. Therefore, the implementation should be: (1) make a copy of the styles to be renamed, (2) rename the copies, (3) change the templates, and (4) remove the old style names once everything else has been changed. This should eliminate any issues during the transition. -- Imperator3733 (talk) 17:57, 20 November 2008 (UTC)

  Sounds great. Thank you for clearing that up. - jc37 18:41, 20 November 2008 (UTC)

• Wouldn't it be simpler to simply fix any templates not fitting the system? I, for one, greatly appreciate the simplicity of having a well-defined colour scheme. Knowing that all red-bordered templates are deletion templates, all X-coloured templates are Y templates, etc. is worth the trouble. Is there a particularly large body of templates which are using red or other colours but don't belong to the corresponding category? If so, where are they? Surely it would be simpler to fix these than re-engineer our current system. {{Nihiltres|talk|log}} 19:04, 20 November 2008 (UTC)

  Yes, there are more than a few. (Including the historical usage of the three templates I noted above.) But even if there weren't, while I understand from a coder's point of view that what a type is "called" may be merely a label (and therefore "who cares if the code looks 'pretty'?"), from an editor's point of view, having the name indicate usage would seem to be more helpful. This is about user-friendliness for the enduser. (Among other things, of course.) - jc37 19:20, 20 November 2008 (UTC)

  I believe you have misinterpreted my comment. My suggestion does account for the end-user. The idea is that the colour of a notice should reflect its category. I don't care about the designation in the code because of appearance: I care about the designation because it reflects an categorization scheme that we've come up with, and making any categorization scheme vague runs the risk of destroying its benefits.

  As I understand it, the system we came up with is that red represents deletion, orange represents serious issues, yellow represents style issues, blue for notices, et cetera. The benefit is that an end-user can look at these warnings—which become warmer in colour according to their severity—and understand a little of the issue without even reading the text. My goal is that the templates themselves ultimately follow a rational colour scheme that is not only aesthetic, but also useful.

  Making the description in the code more vague runs counter to this goal, as I see it, as it makes the distinction between the categories more fuzzy. The solution, according to my reasoning, would therefore to be to fix the templates that don't follow this pattern, rather than damaging the pattern itself to make things fit. Does this make more sense? {{Nihiltres|talk|log}} 23:43, 20 November 2008 (UTC)

  As I remember it, the colours were intended to be "the hotter the colour, the more "impending" the notice".

  But memory aside, considering that most notices (regardless of colour) are about "content", it's rather the ultimate "vague" term.

  Whereas, by making this simple change, we retain everything about the current system, and we embrace the past. The mbox implementation change shouldn't have "broken" past intent with the upgrades. Also, Template:warning was used for more than just content "warnings". Same with Template:Caution. It was about escalating notices to users. And that's another issue. These boxes are being used for user conduct notices as well. Obviously they are "none of the above". But with this simple name change, all of those boxes easily join the scheme as well.

  Any scheme should be adaptable. And currently the styles are, but the names don't reflect that adaptability.

  Whereas the past system does.

  I guess I'm surprised by the opposition for what is (to coders at least) a cosmetic change. - jc37 00:21, 21 November 2008 (UTC)

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 very strange. Especially to use green for deletion? Green is not a warning colour, instead green is a colour that usually means that something is good. For comparison, here is the colour scale most of us have agreed on so far:

• Blue/grey/neutral = For general non-urgent notices, "type=notice".
• Yellow = For minor warnings, "type=style", and I think we can perhaps give it the additional name "type=caution".
• Orange = For major warnings, "type=content", and I think we can perhaps give it the additional name "type=warning".
• Red = For the deletion notices, "type=delete".
• Red+pink = For the speedy deletion notices, "type=speedy".

And yes, you can say this is a slight break with the traditional warning colours that we used before summer 2007. Since then we often used orange for minor warnings and red for major warnings. But really, back then it was mostly chaotic and up to each editor what colour was used. So when we standardised the message boxes we choose this better colour scale. And we have now been using this colour scale for about 1.5 years in main space, and about 0.5 years in the other namespaces. I see no reason to "revert" to a less logical colour scale.

Example of an Ishihara color test plate. The numeral "74" should be clearly visible to viewers with normal color vision. Viewers with dichromacy or anomalous trichromacy may read it as "21", and viewers with achromatopsia may not see numbers.

Jc37: Don't take this wrong, I don't mean to be rude. I just want to make sure, since it would explain a lot: I am starting to think that you might have a slight red-green colour blindness. Since then the yellow and orange message boxes would look the same to you. And the green that you are suggesting for most of the deletion notices would just be a different nuance compared to the red used for the other deletion boxes. While for the rest of us that have full colour vision that green is not a nuance, instead it is the opposite colour of the red and thus has the opposite meaning. Having a slight red-green colour vision deficiency is pretty common among men. And I don't mean full red-green blindness, just a slight deficiency.

Nihiltres: As I have explained above, I don't think we should remove the "type=style" and "type=content" from any mbox. Instead I think we should perhaps make it so all the mboxes understand two names for those styles, that is the names "type = style / caution" for yellow and "type = content / warning" for orange. That is fairly simple to add in the code of ambox/tmbox/imbox/cmbox/ombox. And it means the namespace detecting {{mbox}} still works for all namespaces. And it means we don't need to change any templates that have already been built with those meta-templates. That is, we are then backwards compatible.

Then we have to ponder if we should promote the use of the old type naming for the main (article) space, since that is more clear in that namespace, and the new naming for the other namespaces. Or if we should promote the new naming in all namespaces.

And of course, having two names for some styles will be confusing for the users, and it means some extra maintenance work of the documentation and the code, and it makes the naming of the CSS classes pretty confusing. And over time that will cost quite some extra work. So question is if adding the extra names will cost more or less confusion and work than now. (Now instead it costs extra work to explain for users why we have the slightly strange naming.)

--David Göthberg (talk) 00:49, 23 November 2008 (UTC)

I didn't talk about yellow (or other colours) mostly because I wasn't talking about them. I'm currently focused on the orange and red of caution and warning (et al).

And no, I'm not favouring green for the MfD template. In that discussion at least, I was favouring that all deletion templates should stand out more from the "wall-o-cleanup". (I prefer the "look" of cmbox, if I were forced to pick one.) And there is especially a problem in that PROD is being confused by editors for XfD templates, and vice-versa. And since PROD may be removed, and XfD templates are notices which need to remain during the discussion, this can (and has been) an issue. (Noting that this is a tangent somewhat from the main discussion/proposal.)

I think the main point (so far) where you and I disagree (here at least) is that "caution" is not and should not be "yellow", and "warning is not and should not be "orange". They should be orange and red, respectively. It's what they were historically, and it reflects directly on the "heirarchy of seriousness".

And no, I'm not colour blind, though my monitor definitely has had its better (and worse) days at times : )

As for what my preference for what the colour scale should be, I'm for, essentially, as little change as is necessary, since it seems to have been established that any change would require a fair amount of work.

"Style" and "content" could be any colour, and it shouldn't matter. Especially "style", since being in violation of a style guide won't cause a page to be removed. Content concerns, on the other hand, may lead a page to be nominated for discussion (to be possibly deleted). As such, it could be yellow, and nothing would be harmed. (Since yellow/orange/red seems to be the "heirarchy of seriousness".) But it really shouldn't matter if it's yellow or orange. (Honestly, different content related concerns might be yellow or orange, depending on the severity of the content-related problem). All that said, since it sounds like it's more than a bit of work to formulate this, I wouldn't oppose leaving content as is (presuming, of course, that the orange-level "caution" can be created). But if it makes it "easier" or "more clear", then we could make style green, content yellow, caution orange, and warning red. (With delete, and speedy also being red, as being very specific types of "warning"s.)

Else we could merely consider "content" to be a "specific" type of "caution". Which is why it co-exists at the orange-level. And that would mean we could just leave "style" at yellow (where it is now).

Which brings us back to what I said above: a.) remove the icon from the "delete"-level. b.) Use that icon (and some shade/tint thereof, if deemed appropriate) for orange-level "caution" c.) create red level "warning" using the stopsign icon.

If enacted, that would make it:

• "cool" colours (blue, grey, neutral) for neutral notices
• "warm" colours" (yellow, and especially orange and red) for cautions/warnings. "content" is merely a more specific type of "caution" and "delete" a more specific type of "warning". Yellow is for notices which aren't "neutral", but aren't "danger zones" either. Anything involving cleaning up style and presentation, for example.

This framework is what I was roughly visualising when I initially suggested renaming content to caution and delete to warning, but that's clearly problematic, if only due to the want for "delete" to specifically refer only to deletion-related templates.

Does this better clarify? - jc37 06:59, 23 November 2008 (UTC)

Jc37: Yes, thanks for clarifying exactly what colour scale you are thinking of. And that shows that you and I disagree a lot about the colour scale, its usage and its naming. So I think you and I now have to sit back and listen to what the others think about it.

--David Göthberg (talk) 08:00, 23 November 2008 (UTC)

I think the weakness in your argument, jc, is the statement "They should be orange and red, respectively". Why should they be that way? Is it just because 'they've always been like that'? That reasoning is why we have green deletion templates and innumerable useless gadgets that serve only to revert cosmetic changes. We are not bound by the past; we continue to use things from the past if they remain useful in the present, and won't cause problems in the future. In this case, there are good reasons why change is good. You note an old system of templates that form a three-step hierarchy. We now have a set of styles that form a three-step hierarchy, yet you want to extend it to four? The way you want to change the mbox system makes it internally less compatible with the old templates, not more. All so we can retain an ancient set of colours? What is the fascination with orange and red? Having accepted that using the "delete" type for other messages is a Bad Idea^TM, you then attempt to artificially remove it from the hierarchy in order to 'make space' for a new red warning type, saying everything from "delete... is a different kind of notice... it's really not heirarchical" to "delete is a warning-style notice" to "delete is more a caution". Which is it? Delete is delete; it's everything you say rolled into one, which is why it is not possible to dislodge it from its position: it is without a doubt the most important message we have for most pages. It really is in a whole class of its own, which is why it fully deserves the red styles. Almost every other message pales in comparison with deletion messages, so it is entirely appropriate that they use somewhat less overpowering colours. Can you give us any examples of templated messages that are as important as deletion warnings? I don't believe that any such reusable messages exist; only bespoke warnings like on Talk:Mohammed. We have to ask, why is it necessary to have a red warning type? What utility will it have? And the answer "we need one because we used to have one" is a non-answer, because it makes the assumption that the 'necessity' of the old red warning message was never in any question. If {{warning}} had from day one used orange borders and images, would the world have ended? I very much doubt it. Without evidence to the contrary, the majority of this discussion seems just to be about change; and I haven't seen any real evidence that change was in any way bad.

The one thing I will mention as having been a Bad Thing, however, was converting all the templates that used {{caution}}, {{warning}}, etc, to be independent. There was no need for that, it was completely unnecessary and it seems to have been largely the root of this issue. we would be in a much better position to evaluate this situation if we had that data on which templates use and used to be based on the three old templates. Happy‑melon 20:40, 23 November 2008 (UTC)

Your comments leave me somewhat dismayed. It's clear now that what I'm saying is apparently not being understood.

First, apparently part of my mistake was offering multiple ways in which the "sense" of the heirachy could be conveyed. That apparently has led to your confusion above, indicated by the quotes of my thoughts out of context. My point was essentially that, just because we may presume to have a colour heirarchy, we shoudn't necessarily presume what topics should be assigned to what colours. In other words, if A should be deemed to be worthy of being "higher" on a heirarchy than B, then A could be orange, and B yellow; or A red, and B orange; or A magenta, and B cyan; or A gold, and B silver, or whatever heirarchical system we use. I was essentially attempting to suggest that we think about the reasons behind why A is higher than B, first, and make a determination of whether A should be "higher" than B (that is, if there really is a "heirarchy" between the concepts); than to focus the on the worry about what colour A should be.

Should "delete" be at the top of any heirarchy we put in place? Sure. Is it different than every other notice? Yes!

What I'm saying is that for several reasons, the "delete" template beyond being "red-level", and should be a step "higher", or at least "different" than the rest of the heirarchy of the wall-o-cleanup/noticeboard. Protection is considered to be "different", and I think that most would argue that that's a rather more important situation that whether there are style issues on a page. (And as a matter of fact I believe that they said just that during the discussions regarding implementation.)

And before someone comes out with a claim of "overwelming consensus", I suggest that they go back and read at least the first few archives of Wikipedia talk:Article message boxes. Especially when we come to number 3. This was a small group of editors, who then became united in opposition of anyone else who might voice concerns.

Now the difference of this discussion is that I honestly feel that you are listening, but perhaps not understanding because I'm basing my observations upon experiences that I haven't conveyed, or just not well enough conveying in general.

With that in mind, I went back and re-read the archives as a refresher. (For one thing, I don't wish to mischaracterise the past based upon hazy memory.)

The first 3 archives in particular are, I think, rather eye-opening, for anyone who wasn't around for them.

Wikipedia talk:Article message boxes/Archive 2#Colour-coding - initial proposal regarding colour. This is clearly a heirachical system. Now note ahow many people commented in that thread to "approve" it... Not the "overwhelming consensus" that we keep hearing about. What happened after this is that violetriga (and a couple others) pretty much assaulted anyone who opposed their system. What helped them "get away with" such railroading, was that User:tyrenius was just as (if not more) problematic in opposition. So actions were deemed "justified" based upon the presumed egregiousness of his actions. (If you feel I'm in anyway mischaracterising, please feel free to read over the next few archives, I believe that that statement is fairly supported. User:Splash did a breakdown of such things at one point. In my opinion, in these "discussions" our fellow Wikipedians would seem to be not at their best concerning WP:AGF or possibly even WP:OWN.)

Now, as I mention above, eggs may need to be broken to make an omelette, but (to mix metaphors), I strongly think that this was a case of where the baby was thrown out with the bathwater.

Now all of that said, I find it a bit ironic that my initial proposal above actually follows that initial proposal. That the colour-levels should have a general name, with each being a grouping of specific "types". What happened later was that when it came to names, since those present decided amongst themselves that "most" of the usage in a certain "seriousness-level" was (for example) "content-related", then that level should be called "content".

That's my main complaint/concern.

Just as has been noted above, ambox was mostly focused on article namespace, and further, it was very clear that those making these arbitrary choices rather obviously had no real idea about how many templates would be affected, and in what ways. (This was brought up several times by several editors.)

Was there overwhelming consensus that soemthing like mobox should be implemented? Yes. Did most editors like the idea of the heirarchical system? Yes. (Especially since it was somewhat already in place in quite q few templates.) Does anyone honestly believe that all those who "voted" for implementation of this really had any idea of all the various nuances involved? And further, wouldn't it seem that most were trusting that those involved in creating the presentations "voted" on, had come up with whatever was "best"?

Yes. And as a matter of fact, that is borne out by the fact that immediately upon implementation, there was an outcry (by many who had supported) concerning the speedy deletion templates. Apparently those in the discussions had not realised the impact or problems that they were creating.

I'm agreeing that we should have a red and an orange level. But that they should have different names, because they are much broader than just content and delete. And this is actually simplified in that, as Happy-melon notes, "delete" should be restricted to only deletion templates, for various usage reasons. If we do that, then we're still left with a vaccuum for a 'red-level" set of templates. And to merge all the historically "top-level/red templates with the orange-level templates is simply a very bad idea. And worse, as has been noted, this has somewhat already been done. And we also have the problem that users need a "red-level" that isn't delete (else they wouldn't be still using that level for tremplates). There is a definite need here that should be addressed. And while I do think it's fixable, to do so, we'll need to "let go" of a bit of ownership, and allow the templates to be used as editors wish, not necessarily how we would like to force them to use them. (Note I'm not saying that the case with anyone in this discussion, but I think you may agree that it's an easy trap to fall into, especially when one has put so much work into this implementation.)

And to suggest: "well they can customise the styles for their specific usage", defeats the purpose of having a standard. If this "standard" is going to work, it needs to be adaptable as needs grow and possibly change. We should be inclusive, both of the past and the present (and potentially the future). Note that the ambox discussions are "the past" as well. So disounting "the past" for merely being "the past" is rather a red herring.

So in this proposal, I'm making the presumption that we're using a colour-based semi-heirarchal system of "organising" these messagebox templates. Hence "orange-red" heirarchy that HM didin't seem to understand above.

So my proposal was and is essentially to try to help these "grow" to include common practice (which is what our guidelines are supposed to reflect) while trying to do so with the least amount of change, and thereby, hopefully, the least amount of work/effort.

As an aside, to clarify the "style" comments (which are now somewhat a sideline topic), see The style boxes aren't "serious". Also note that using the word "content" is problematic because technically "style" of content presentation is itself page "content".

Anyway, since this has become long, I'll restate the proposals, perhaps they will make more sense (I hoping, anyway):

Long form:

1.) Unlike most other notices in the heirachy, deletion templates refer to a discussion concerning the whole of a page (rather proposing modifications to the "content" or "style" or presentation of a page). So while they may be considered the "most important" messageboxes, that doesn't mean that they should necessarily be restricted to the heirarchical cleanup system. And their existance doesn't and shouldn't mean that there should not be other "red-level" seriousness notices. If anything, "delete" is "beyond" the heirarchy.

As an aside, deletion templates don't use icons, so there is no need to even have a default icon 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 (though perhaps tweaking it's shade/tint) 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. Look at the top template at Wikipedia:Template messages/Disputes, and Template:Caution, for example.

By doing this, we could either leave the "content" style in place for use in ambox, rather than merely deprecating it. Or we could set "content" to a different colour (such as yellow). I don't have a strong opinion either way, though I am leaning towards leaving "content" as a separate "orange" style, because a.) it's easier and b.) while it may not be as useful elsewhere, it's apparently useful for articlespace.

3.) The (proposed new) Warning style be created. Using the red-level, and a stopsign icon (as was used historically). This would also be useful for resolving several of the issues laid out by others above, including reflecting "common practice". (See the current version of Template:Warning, and then look at what it looked like previously.)

Short form: add two new styles: "Warning" (red) and "Caution" (orange).

I'm really hoping this clarifies : ) - jc37 16:17, 24 November 2008 (UTC)

I understand, and I thank you for taking the time to explain. Unforutnately, I still don't agree substantially with you. While I applaud your efforts to ensure that the early ambox implementation discussions are fairly presented, I don't actually care about them. As you note, they were disorganised at best and abusive at worst, and they certainly shouldn't be considered a model of consensus-building on wikipedia. I have not once referred to the "consensus" of these discussions because they are ultimately irrelevant. The only relevant overall point is that they resulted in a highly successful system of templates and styles that has now encompassed the majority of pages on en.wiki. The 'consensus' for the continued use of the mbox system is evident from the willingness of wikipedia editors as a body to propagate and implement it for new and old messages. As you point out, the majority of the features and objectives of that system were never even considered in those initial proposals; they have, like the templates themselves, grown organically over time. Which is why we find ourselves in our current position. What went before is important only if it remains relevant today, old systems for doing things remain useful only if they are superior to newer implementations.

So, to the current issues. We are, I believe, now agreed that the deletion templates must remain in a type of their own, for whatever reason. Thus we currently have three types that are 'available' for generic notices. I have agreed above and will agree again that "notice" "style" and "content" are unintuitive names for these types and are a clear throwover from the ambox development process. As I've said, I have no fundamental objection to changing these names aside from the huge amount of work required to do so. This would, IMO, be the solution that is "as little change as is necessary". However, you continue to argue on the assumption that a generic type with red formatting is an absolute necessity, that "is a definite need here that should be addressed". Why is it a neccessity? Why are we "left with a vaccuum for a 'red-level' set of templates"(my emphasis)?? The only examples of messages that are not deletion notices using red borders that I have ever seen are bespoke messages such as Talk:Muhammad, and Template:Remove-section (which I recently changed because it incorrectly used the "delete" type as I have explained above. While I can see the connection, it is not a valid XfD notice). Can you present examples of warning messages that are serious enough to genuinely require red styling, are not bespoke messages, and are not deletion warnings? And I'm not talking about "this template used to use red styles before it was changed" 'examples', because such retreats to the past are irrelevant. In the past, we had a template system that had three levels, the most serious of which used red styles. Now, we have a warning system which has three levels, the most serious of which uses orange styles. I still don't see the evidence (and I would be very interested to) for the current system of blue/yellow/orange being 'inferior' to the old system of blue/orange/red.

Without such evidence, and taking fully your advice to separate the scale itself from the styles that clothe it, I conclude that your proposal is actually to extend the current three-point scale to a four-point scale, and I wonder wonder why it is considered necessary to do so. Even if we were to consider historical precedent, there is none for such an extension. On the other hand, I can see a number of disadvantages, including confusion with the (likely similarly-styled) "delete" type based on visible appearance, the inevitable abuse of a 'very serious warning' category with messages that are not, in fact, very serious, and the increased likelihood of disagreement over which now-smaller 'box' message X fits into. Ultimately, this discussion seems to be about two very simple stylistic changes: that the new mbox styles have replaced an old orange template with a new yellow template, and an old red template with a new orange template. To restate: why is this so great an issue as to require extensive restyling of a set of templates that span the entire encyclopedia? Happy‑melon 20:18, 24 November 2008 (UTC)

First of all, let me just say: whew.

I think now you do understand.

To try to respond, as I mentioned to dg above, I wasn't even thinking about yellow being a part of the heirarchy (though it indeed currently is), since it's notices aren't and shouldn't be considered "Danger, Will Robinson". That's why I said that "style" could be any colour.

I actually was looking at a two-tiered heirarchy (orange-red), with "delete" being "something else".

While I think you are suggesting that the two-tiers should be yellow-orange (so that delete can be the "only" red-level).

Also, I think that perhaps we've identified that "style" notices aren't "danger" notices, and as such, if we presume that yellow is one of the colours intuitively suggesting "danger, and presuming that yellow/orange/red is the heirarchy we're looking towards, then "style" shouldn't be "yellow", and instead should be "something else". (And perhaps that would be "easier" in implementation, I dunno.)

The issue with doing the latter, though, is that when categorising notices which are user conduct/action warnings. The highest level "warning" would seem to be intuitively "red". (See also: Wikipedia:Template messages/User talk namespace.)

Which means that, on one hand, we'd have red for delete, but on the other, we have red for "warnings". (Which seems to be the current "state" of things.) So that means that these warnings may (and do) conflict/be confused with other XfD templates.

All of that said, you have a good point concerning "the inevitable abuse of a 'very serious warning' category with messages that are not, in fact, very serious"

The question is whether we should see that as "abuse", or as a sign that they, "like the templates themselves, [are growing] organically over time". I think that the key should be to somehow remove subjective decision-making in regards to which mbox style to select.

Anyway, if we do consider this a "danger" heirarchy (of yellow/orange/red), I guess I could weakly support:

• Yellow = content (for notices involving the "danger" of "content" of a page in its current state. Though a better name would be welcome)
• Orange = caution (for all "warnings" except deletion)
• Red = delete (solely for deletion templates)

And we can come up with some new colour (green?) for "style". (and perhaps a better name.)

Though I prefer:

• Yellow - style
• Orange - content
• Red - caution

And we can come up with some new style for deletion templates (a bold, all-around border, and making usage to be non-stackable, could, I think, be a good start.)

I think that the latter is more intuitive, and less likely to to be prone to subjective or arbitrary placement of an mbox "style".

What do you think? - jc37 15:37, 25 November 2008 (UTC)

I think you're not taking your own advice :D. If you remove the styles and whatever connotations you may personally assign to them, you're left with a template with seven possible types. Four of those ("protect", "move", "delete" and "speedy") are 'restricted' and are only available to a narrow group of warnings. That leaves three types available for generic "messages". You're right in that messages using the "style" type "aren't 'danger' notices", but only to the extent that neither are "content" messages. The only messages that really warn of impending doom are the "delete" ones. Aside from that, however, both 'yellow' and 'orange' messages are readily considered "warning messages", indeed we've all used this terminology interchangeably above. We inevitably conclude the existence of a 'hierarchy' whereby 'orange' warnings are more serious than 'yellow' warnings, both of which are more pessimistic than 'blue' messages, which we agree are usually considered mere "notices". So you are correct, of the pair of types that contain "warnings", I see the lower one as being naturally yellow and the upper one naturally orange. You confuse the issue, I believe, by retaining the connotations of the "style" name - I believe we are now all agreed that these names are at best unfortunate. I am coming to the conclusion that the term "caution" would in fact be preferable, as would "warning" for the orange type. with these new names, we have a more natural and generic hierarchy, which ports well to other namespaces. There is no reason to require that 'style' warnings in the mainspace need different styles to moderate warnings elsewhere; consider as an example {{intricate template}}. This template clearly has nothing to do with 'style', if anything it's more 'content', but it is a 'moderate warning', so the yellow style is appropriate. If this yellow style were called "caution", the intent would be much clearer.

You just can't help yourself, can you :D? "The highest level 'warning' would seem to be intuitively 'red'"... why? I notice that even the indef-block templates, that would seem to me to most closely approximate "deletion" in the user namespace, are not red but beige. Red does not seem to be a prominent colour in the warnings you link to, even in the most severe instances.

So I suppose the position I'm increasingly coming round to is to say that the best balance between improving usability and reducing effort is to have the scale "notice"/"caution"/"warning" for blue/yellow/orange. Precise implementation details are, of course, a triviality. Happy‑melon 20:05, 25 November 2008 (UTC)

New Idea

I think wikipedia needs a better chat application than the IRC because they won't work for me I think it would be more efficient you Wikipedia had a chat more like the webiste www.facebook.com for those of you who are familiar with Facebook's chat application you know how easy it is to use and instead of talking back and fourth it would be better if there was something like this. Thank you for your time. DellLaptop (talk) 23:48, 20 November 2008 (UTC)

You can always use AIM or something.Petero9 (talk) 00:10, 21 November 2008 (UTC)

How can IRC not "work" for you? IRC is an open protocol. There's IRC clients, including several free ones, available for pretty much every operating system, as well as Java and JavaScript Internet-based clients. Mr.Z-man 05:11, 21 November 2008 (UTC)

This idea is not as silly as it is made out to be. Though implementing a IM-chat into media-wiki is not on the cards there is definitely work being done on how to improve the communication methods on-wiki. For starters they are looking at how to improve the threaded messages. I would personally like to see an integration of some real-time communication - perhaps a little symbol next to a person's name in the recent changes log to indicate that they are currently online. In any case, requests for technical additions would probably be better made at bugzilla on Meta. Witty Lama 12:43, 21 November 2008 (UTC)

How would you define "currently online"? --Carnildo (talk) 23:07, 21 November 2008 (UTC)

I would define it as currently logged in - a browser window (that has not timed out) is active with the username logged in. I imagine this would look something like the way on some chat forums there is a little symbol. For example, on the MacRumors forum site, there is a little grey circle on the bottom left-hand corner of each person's posting. When that user is still online then that little circle turns green. for example here. Just an idea... Witty Lama 07:24, 23 November 2008 (UTC)

There is this extension, although as Witty Lama says, getting it implemented is unlikely. seresin ( ¡? )  00:59, 23 November 2008 (UTC)

Especially since one can just as easily go to mibbit.com. As for the "currently online" feature, people may be interested in User:Splarka/userstatus, currently in development. Mr.Z-man 19:40, 25 November 2008 (UTC)

The lead section of an article should have its own edit link by default. You should have to tweak preferences to turn it off.

I was happy to learn that I can choose to see an edit link for the lead section of any article by setting my preferences, but it was annoying not to have it until I learned to turn it on, and I imagine it is annoying for other new editors, including ones that may never learn how to do it or come here to add their agreement to this proposal. It's impossible for editors that have not signed up to see the edit link, since they don't have preferences. Using the "edit this page" link to edit the lead section is annoying, cumbersome, and slow as the whole article is loaded into the editor. It also makes it easier for mistakes to damage larger portions of the article unnecessarily. For the general convenience of editors, especially new editors, I suggest that the interface philosophy of allowing each section to have its own edit link be extended to include the opening section, by making the default status be that the link appears, rather than the current default status of having it not appear. -- Another Stickler (talk) 01:44, 22 November 2008 (UTC)

I think this is a perennial... — Werdna • talk 07:40, 22 November 2008 (UTC)

It's not listed at Wikipedia:Perennial proposals. What reasons are there for rejecting it? Algebraist 12:51, 22 November 2008 (UTC)

I can't say exactly how many but there have been numerous posts over the years to various help pages where new users, unaware of the "edit this page" link, have asked how do they edit the lead section at all. My impression as a help desk/NCHD/VPA regular is that this has been asked hundreds of times. I can see no good reason for not enabling this by default as Another Stickler suggests.--Fuhghettaboutit (talk) 14:33, 22 November 2008 (UTC)

I found some information at Wikipedia:Wikipedia Signpost/2007-08-13/Bug review#Section edit link for section 0. According to that precis, the subject has been discussed and there was disagreement over where to place the link. Also, apparently it causes some problems with right-floating page content. See the bug report for more detail.--Fuhghettaboutit (talk) 14:39, 22 November 2008 (UTC)

Thanks for those links. I agree with comment #6 that right-floating content is problematic throughout the page, so that's not a powerful argument for denying one section an edit link. -- Another Stickler (talk) 09:22, 23 November 2008 (UTC)

I agree it would be a good implementation. The preference setting is recent, I think. Previously, I clicked edit on any section, and then changed the end of the URL so it read "section=0". This allows the lead to be edited on its own. Ty 13:15, 23 November 2008 (UTC)

I looked at my preferences, didn't find anything to let me edit section 0. Where is it? Thanks. dougweller (talk) 15:29, 23 November 2008 (UTC)

Gadgets/User interface gadgets. Algebraist 15:30, 23 November 2008 (UTC)

Fuhghettaboutit's comment (14:33, 22 November 2008), from the contributor with most relevant experience here, is conclusive - enable it by default. --Philcha (talk) 15:53, 23 November 2008 (UTC)

I really can't see any disadvantage to enabling this here for all users; it's as simple as moving the code from MediaWiki:Gadget-edittop.js to MediaWiki:Common.js, and removing it as a gadget. Happy‑melon 18:11, 23 November 2008 (UTC)

Ew, JS hacks. — Werdna • talk 04:26, 24 November 2008 (UTC)

Don't like 'em? Go fix it for us in trunk then :D Happy‑melon 09:38, 24 November 2008 (UTC)

It seems like the majority of responses here are positive. So now what happens? -- Another Stickler (talk) 00:23, 25 November 2008 (UTC)

Ancient bug. Aren't there layout concerns still? Esp. with the use of a featured content star, audio recording indicator, and coords. Surely one of those things overlaps, no? (Oh, and if you want it enabled site-wide, seek consensus at MediaWiki talk:Common.js.) --MZMcBride (talk) 00:30, 25 November 2008 (UTC)

Thanks MZMcBride, I started a thread in MediaWiki talk too. Here's the link: [6] -- Another Stickler (talk) 03:30, 26 November 2008 (UTC)

Village pumps get a wider readership, and so it is probably good that it is getting aired here too. --Timeshifter (talk) 04:59, 25 November 2008 (UTC)

I too think the default should be an [edit] link at section 0. It saves a lot of load and rendering times for us with slow connections and/or slow computers when editing the lead section. And it makes it easier to compare the code in the edit window with the rendered output in the preview, since we don't have to scroll past the preview of the entire page. And there's no real problem with other items such as the featured article star etc., since we can easily move them out of the way. And I have used several such [edit] scripts over the years and have not seen any interference with page content such as right floating infoboxes in any of my browsers. So I too think the code from MediaWiki:Gadget-edittop.js should be moved to MediaWiki:Common.js. (Possibly instead with a gadget to turn the edit link off for those that dislike it.)

--David Göthberg (talk) 04:41, 25 November 2008 (UTC)

• Support. I did not know of this for the longest time. It wastes so much time and bandwidth to not have this as the default setting for all readers (registered or not). Think about it. This change alone would greatly lower server loads, and greatly increase editing productivity. --Timeshifter (talk) 04:55, 25 November 2008 (UTC)

There is one potential problem with doing this for newbs and anon - The edit link might (I stress "might") be confused with the "Edit This Page" link at the top of the article. Might be better to expand the section-edit text to "Edit this section" before doing this, or at least change the one for the LEAD to something along the lines of "edit the introduction." That said, I would welcome this both here and back in the trunk - I was really tired of adding "section=0" to my edit links to force this before the feature was made available here, but I'm getting even more annoyed by it on all the other wikis I'm involved in. MrZaius^talk 10:00, 25 November 2008 (UTC)

I support this (finally) being added into the MediaWiki trunk, but would settle for the gadget being turned on by default (or put into common.js). The argument that the lead edit link interferes with right-floating content is a moot point in light of the recent work being done in that area - see the discussions at MediaWiki talk:Common.js#Topbar content and MediaWiki talk:Common.js#topicon part deux, and the request for an update to the gadget at MediaWiki talk:Gadget-edittop.js#New version that is aware of any topicon. —Dinoguy1000 21:59, 25 November 2008 (UTC)

Date linking RFC: Three proposals for change to Wikipedia:Manual of Style (dates and numbers)

There are three proposals for a change to Wikipedia:Manual of Style (dates and numbers). In summary, they are:

• delete the current discouragement to link dates and replace it with encouragement to link dates
• delete the current discouragement of autoformatting and replace it with encouragement of autoformatting
• create an additional requirement whereby all bots/scripts need additional consensus at the Manual of Style talk page before are allowed to implement a Manual of Style guideline

Voting is already underway. Feel free to add your vote at: Wikipedia talk:Manual of Style (dates and numbers)#RfC: Three proposals for change to MOSNUM Regards Lightmouse (talk) 21:12, 23 November 2008 (UTC)

See this discussion, where some editors are complaining that the date linking RFC referenced above is a bad-faith attempt by a vocal opponent of date linking (Tony1) to short circuit the well-balanced RFC being drafted with input from many editors concerning closely related issues. Tennis expert (talk) 21:48, 23 November 2008 (UTC)

This is indeed the case. Tony is a vocal opponent of date linking and has back doored this RFC to try and frame the debate his way (and not the consensus way as noted at the other RFC). —Locke Cole • t • c 00:41, 25 November 2008 (UTC)

There is a new request for comment underway at Wikipedia talk:Manual of Style (dates and numbers)#Date Linking RFC as to the proper linking of dates in articles. This is the RfC that is the result of a lengthy, collaborative process. Another RfC was removed from the RFCstyle list by an admin due to controversy over its neutrality. Please comment, or if you commented on the prior RfC, please do so again on this more detailed an less controversial RfC.--User:2008Olympian_chitchat^seemywork 08:09, 25 November 2008 (UTC)

Wikipedias Reliability

Wikipedia is getting reliable as more and more users contribute to its content (s. “Wisdom_of_the_crowd”). The more often an article has been modified and the more people have worked on it, the more accurate is its information – at least statistically. Therefore, a glance at “history” of a page delivers good indicators for its trustworthiness. Instead of clicking “history” I suggest to put such indicators on top of every page: its age, number of (accepted) changes and number of users having changed it.
Beyond that, a rating system could also improve reliability. Logged in users should be able to rate an article. It could be a simple rating system with showing the average rating or showing a statistic about number of votes for every rating level. Better would be a sophisticated statistic like “How this article has been rated by users rating my rated articles similarly?” --Asolymosi (talk) 12:03, 24 November 2008 (UTC)

No, a glance at the history of a page delivers mere hints about its trustworthiness.

Your three suggested indicators wouldn't be bad, but they just add to the clobber surrounding the article proper. I don't suppose I'm so unusual in being happy that WP articles (at least when viewed here, at least when viewed here, not via commercial scrapes) aren't burdened with "Ads from Google" and suchlike noise common elsewhere.

I don't see what the point is of having logged-in users rate the reliability of an article. People might have good grounds for rating the reliability of an article largely written by me, they might have very shaky grounds, and they might have no grounds at all. We wouldn't know.

If you do want something like this, there's also Veropedia, whose system starts to make sense (or seemed to when I last read about it). -- Hoary (talk)

Not yet: pressed the search button and "Firefox can't find the server at search.veropedia.com." Maybe next year. NVO (talk) 18:13, 24 November 2008 (UTC)

I think it's not a good idea because after I were to vouch for an article in this way, I would want to withdraw my voucherhood as soon as anything was changed, because I hadn't read the new version of the article. The rating would be therefore most logically associated with a particular old revision. Citizendium may be doing what you're suggesting - at some point articles can get peer-reviewed and marked so, apparently. I've never used it, though. Tempshill (talk) 20:17, 24 November 2008 (UTC)

Asolymosi, maybe you didn't read this part of the article you linked, "While many articles on Wikipedia may be of a high quality and edited by multiple people (therefore taking advantage of the crowd's collective wisdom), other articles may be maintained by a single editor, whose ethics and opinions may be questionable. In the anonymous domain of the internet it can be difficult to detect a difference between the two articles, but the same amount of reliability and correctness may incorrectly be expected from both." Crowds may be statistically correct, but a reliable reference source is expected to be perfect. Wikipedia is not a reliable reference source and cannot be because of its open design. Any teacher who accepts a student's report citing wikipedia as an authority is doing the student a disservice by allowing that perception to continue. Wikipedia may be a good place to get an overview on a topic and some pointers to possible actual reference works. It's definitely a good place to exercise ones critical reading and writing/editing skills. -- Another Stickler (talk) 01:05, 25 November 2008 (UTC)

Asolymosi, when you click "history" you can click on "Revision history statistics." I know this used to go to aka's tool which would show you the first edit to a page, the number of edits, and the number of unique editors. It looks like "Revision history statistics" now points to a tool on the toolserver written by Duesentrieb on the German Wikipedia, which shows you the users with the most edits to the page. It looks like the link to aka's tool was added to MediaWiki:Histlegend at the end of August, but was removed in early November because of an AN thread about the tool results displaying Google ads. I don't know if it would be feasible to analyze a page and provide that information after every new edit.

The recent survey in early November did have a question kind of related to a rating system (checked/endorsed), so you might want to wait until the beginning of January to see the results of that. You may also want to take a look at Wikipedia:Flagged revisions and its talk page (although I admit to being confused about most of that myself). --Pixelface (talk) 11:39, 25 November 2008 (UTC)

Touch the Clouds

I propose Touch the Clouds to be TFA tomorrow! If not, then I propose Pier Gerlofs Donia] would do. J.B. (talk) 14:36, 24 November 2008 (UTC)

Then go to WP:Today's featured article/requests, although i doubt it will be since its only a GA nominee, and the other one didn't meet GA--Jac16888 (talk) 14:50, 24 November 2008 (UTC)

The other one would meet the requirements now - just read the Pier Gerlofs Donia-article in its current state and then tell me what you think. I personally think it is a well written, well-sourced and long article. It is well-illustrated and has no grammatical errors. J.B. (talk) 14:53, 24 November 2008 (UTC)

You're not listening. To be a TFA, an article has to do three things. 1) It has to be peer reviewed and found to be a WP:GA. 2) it has to be taken to WP:FA and has to have a consensus to be a FA. 3) The Featured Article Director has to approve it, and make it a TFA. Neither of those two articles have done any of the above, if you want to make them tfa's, i suggest you go work on them--Jac16888 (talk) 15:06, 24 November 2008 (UTC)

The first step is advisable but not necessary. I struck it. Ruslik (talk) 17:14, 24 November 2008 (UTC)

I understand. Now listen to me please: Pier Gerlofs Donia is fit for GA class in my eyes. If I were to renominate it, would you or someone else pass it in its current state so that I could do above said? J.B. (talk) 15:15, 24 November 2008 (UTC)

I wouldn't, I've no experience in GA reviewing, and wouldn't know what to look for. If it meets the standards, I'm sure the guys and gals at GA will--Jac16888 (talk) 15:26, 24 November 2008 (UTC)

Last I checked, (granted, it was a while ago), being a GA is not a prerequisite for becoming an FA. The GA and FA processes can be very slow. I don't see why people should have to go through both of them. Back when I wrote more content, I found it was easier to do WP:FAC first, where, even if it didn't pass, it would surely get enough feedback and improvement to easily pass WP:GAC. Mr.Z-man 17:04, 24 November 2008 (UTC)

I didn't know, mainly because I have next to zero experience with either process. However I believe it would be safe to assume that an article which fails a GA assessment, won't pass a FA assessment--Jac16888 (talk) 22:49, 24 November 2008 (UTC)

I can hardly imagine Pier Gerlofs Donia failing GA: just look at it now! I understand however, that there can be questions towards Touch the Clouds. {{subst:User:Jouke Bersma/sig}} 11:06, 25 November 2008 (UTC)