Wikipedia:Village pump (proposals)/Archive 50

wikEd does something like this. Mr.Z-man

16:19, 27 July 2009 (UTC)

^{(edit conflict)} You can already do this using wikEd (locatable through the search tool), Swpb. I appreciate that add-on, while easy to activate, isn't the same as an on-by-default standard feature—plus adds several more buttons. I don't think it would be that difficult (not that I could be the one to do it) a patch. Care would be needed to keep the scope narrow, to avoid wishitems for syntax-coloring of many programming languages drawing its development out, I suppose. I think your suggestion's definitely worth considering. –Whitehorse1 16:21, 27 July 2009 (UTC)

Hmm - yes, I think having the functionality only available through an add-on negates the potential benefit to technophobes. As far as the scope, it should only be applied to code that is active on the page (headers, internal/external links, namespaces, transclusions, table syntax, html tags, latex codes inside <math> tags, etc.), and not to random snippets of any old programming language that an article might be quoting. Also, it needn't differentiate between different code elements, the biggest benefit would just be in differentiating code from non-code, which might also allow it to be developed faster. For example:

I would suggest that for any parameters, user-supplied values should be treated as plain text, whereas pre-defined parameters (like "thumb" for the "file:" namespace) should be highlighted as code, as I've done above. Alternately, all parameters could be either highlighted or not. »

• ¢

17:40, 27 July 2009 (UTC)

Sounds like a good idea (though I'd hope for an easier-on-the-eyes default colour than red). Rd232 ^talk 14:07, 28 July 2009 (UTC)

Ok, so how should I go about getting broader consensus on this? I figure something like changing the default look of the editing window merits some significant community input, like its own talk page and a mention in the signpost, if not one of those nifty watchlist notices. Does anyone know how to do the latter? Then, assuming a consensus emerges, I figure I should submit it to the developers by means of a bug report? »

• ¢

15:05, 29 July 2009 (UTC)

The only reason why this is not implemented is because there is no good way to do it. Automatic syntax highlighting tools written in JavaScript mess up the undo/redo buttons. The best wikEd can do is give you a button that you have to click to update the highlighting. If you can find a good solution to this problem, I'm sure there'd be little opposition to rolling out syntax highlighting by default. —Remember the dot ^(talk) 06:00, 30 July 2009 (UTC)

If this is ever implemented, ensure that there's a way to turn it off. I don't want my text garbaged. Thanks. Greg Tyler ^{(t • c)} 16:16, 30 July 2009 (UTC)

Right. Pink letters (example above) are an eyesore. Please default to all blacks.

NVO (talk

) 10:21, 31 July 2009 (UTC)

Well, red (or pink) need not be the color used. However, syntax highlighting would be extremely helpful to many editors, which I think trumps the "eyesore" argument for having it off by default. If it bothers you, I agree with [[

• ¢

15:40, 31 July 2009 (UTC)

...maybe there could be a locking system like on TV Tropes. There a page gets locked for a certain amount of time when someone starts editing a page. If they do not save their edit before the time runs out it's not added. This idea could use some work, I admit.--Occono (talk) 00:28, 2 August 2009 (UTC)

Why would this be superior to the current system? Algebraist 00:29, 2 August 2009 (UTC)

I think this would be less frustrating when another editor is making lots of edits and you cannot get any in...I suppose I can't ::give a great reason why this would be superior, I'm just throwing it out there.--Occono (talk) 00:34, 2 August 2009 (UTC)

TBH, it seems like it would be a lot more frustrating to not be able to edit the page at all then to get a couple edit conflicts, especially since only edits that can't be automatically merged cause conflicts, not every instance when edits overlap. Mr.Z-man 02:09, 2 August 2009 (UTC)

Agreed. Wikipedia is just too busy and frequently edited for that option to work here. hmwithτ 13:50, 2 August 2009 (UTC)

We do need a less-crappy system for handling edit conflicts, though. Having to root through the entire page, rather than just a section, is no fun.    M   01:46, 3 August 2009 (UTC)

If you're planning an edit which affects large portions of a page and may require a significant amount of time to complete (restructuring a whole article, massive copyediting, etc.), then you can use the {{

inuse}} template to flag your work in progress to other editors. If you do come across an edit conflict, many web browsers will allow you to hit the back button, taking you back to the edit window in which you were just working and allowing you to copy any text you wish to preserve. For more complex edits (why didn't you use {inuse}?) you can open a new tab with a fresh copy of the edit window, where you can paste in material from the original edit window. TenOfAllTrades(talk

) 02:57, 3 August 2009 (UTC)

If you give me just the section I was working on, I won't have to click back and forward.    M   03:07, 3 August 2009 (UTC)

I believe M was referring to what happens when you get an edit conflict: you see the entire content of the page, even if you were previously editing just one section. Powers ^T 12:53, 3 August 2009 (UTC)

(unindent) Having to go through the entire page after an edit conflict IS SO FREAKIN' ANNOYING I have to emphasize it through font and an exclamation point! The solution would be to make so you go back to the section you were working on after an edit conflict, and to use the {{inuse}} and {{underconstruction}} tags, not to lock the page when it's being edited. I have several disabilities that, I'm sure, at times make it so it takes longer for me to edit a page. I do horribly with time limits. My IQ allegedly can't be tested because of this. So, in other words, this solution makes it inaccessible to me at least, and probably a lot of other people with disabilities. I dream of horses (T) @ 01:43, 5 August 2009 (UTC)

Sounds like a perfect tool for hijacking an

I think there should be at least an informal suggestion somewhere encouraging editors to give new pages "some time" to develop before AfD or slapping a tag on them about "orphan", "uncategorized". or "needs citations" or what have you. Two things brought me to this. One, quite awhile ago, I changed an article that had been a redirect for 2 years into an actual article. It was put up for deletion before I could expand it and show notability, and the reason the editor gave for putting it up for deletion was that it had been around for over 2 years and no one had expanded it from the two sentences that were there (the two I had just put there). He had not checked the history and seen it had been a redirect for those two years and had just got turned into an article. Luckily me and another quickly expanded further and showed notability. Second, and this happened today- I created an article, left it to post at another editor's page and at the appropriate wikiproject's "new article" page that I had created it, and in the 3 minutes it took to do that... someone tagged it with orphan and uncategorized tags! It seems a bit silly to me to not give an article, oh, maybe a couple days to a couple months before we start doing that kind of stuff, what do others think?Camelbinky (talk) 03:32, 4 August 2009 (UTC)

This falls under

instruction creep. Granted, it is pretty silly to show up at an article within a matter of a few minutes and start slapping it with tags - or worse, deletion nominations - but it is a matter for common sense, not set time limits. Shereth

04:28, 4 August 2009 (UTC)

Perhaps you didnt read my post closely enough before trying to stop conversation prematurely. I never said anything about imposing a limit, I said "informal suggestion" to encourage editors to stop being overly...well, I guess overly stupid. As for creep, that's ridiculous and I'm sick of that being the default excuse anytime someone doesnt like change. Anyways, this is the village pump (proposals), this isnt the village pump (policy) and I'm not trying to set up a new policy. The village pump is an open discussion forum. I suggest we allow everyone to simply comment and talk about this, which was my whole reason for bringing it up. It doesnt matter if this is a perenial discussion, perhaps if it continues to be brought up over and over maybe those editors who do it might just get the hint and do some research before tagging a new article.Camelbinky (talk) 05:29, 4 August 2009 (UTC)

When it's clear that a brand-new article is obviously headed for deletion, it wastes less of everyone's time to do it right away. It's not a kindness to stand idly by while people who don't understand the standards pour effort into a page that was always destined for the gallows. --Trovatore (talk) 08:26, 4 August 2009 (UTC)

I think that this falls under the spirit of

Since when has a proposal being listed at peren been grounds for dismissing it out of hand? Consensus can change folks - but not if a debate gets stamped on before it can start. DuncanHill (talk) 12:05, 4 August 2009 (UTC)

Consensus can change, but when a proposal has been made often enough that it appears on

WP:SENSE when they just don't have any is often like trying to get blood from a stone. TenOfAllTrades(talk

) 12:52, 4 August 2009 (UTC)

Camelbinky, I’m sympathetic to the frustration of trying to improve an article, and seeing it proposed for deletion even as you start working on it. On the other hand, I can easily imagine the first step triggering an entry in a watchlist, and a user taking a quick look at the very limited information and deciding it deserves deletion. That user may be unaware that the article is in the process of improvement, even when there are signs that an attentive editor could read. Your proposal is that we pass along informal suggestions to give the article some time. While I understand the suggestion, it creates a process problem without a simple solution. The user reviewing the article either has to do some detective work to ascertain that the article is being worked on, or find some way to calendar the article to return later to see if there is progress. While this isn’t a lot of work, why is it fair to out the burden on the reviewer? There are two better solutions, which remove the burden from the reviewer. One is for the editor improving the article to place the appropriate template (hangon, inuse, or underconstruction) to let the reviewer know you are working on it. A better option is to work on the article in your sandbox, and move or copy it when there’s enough to stave off the deletionists. I think the last option is the preferred option in any case, so I think it makes more sense to encourage editors to follow best practices, rather than put a burden on reviewers to determine whether the article is about to be improved.--SPhilbrickT 15:07, 4 August 2009 (UTC)

(<-){{

Maybe the templates can be changed in a matter I

suggested at WT:CSD to only show them after some time has passed, so they still exist but are not shown on the article before a fixed time has passed. Unfortunately, the MMORPG approach to NPP is still too often used... Regards SoWhy

15:18, 4 August 2009 (UTC)

A previous suggestion to write the articles in a sandbox - or make heavy use of the "show preview" button to check on small revisions - is a great one. NPP is a difficult place that I have long avoided because it can be extremely difficult for the patrollers to make an informed decision on what amounts to a sub-sub-stub, and given the volume of stuff going through there, it is not very reasonable to burden them by requiring additional steps. A lot of this conflict could be avoided if articles were not constructed piecemeal style in mainspace. Shereth 15:27, 4 August 2009 (UTC)

Unless it's a SNOW close, an AfD discussion lasts 7 days. If an editor or group of editors can't make the article look like it should be kept in seven days, then either they have no interest in doing so, or they can't. People involved in the discussion can change their minds based on improvements, or the closing admin can take a look at the article in question and decide that, despite the stale !votes, the article now appears notable enough to be kept. Why is the seven days not a sufficient time to get the article improved? Who then was a gentleman? (talk) 18:47, 4 August 2009 (UTC)

Seven days is enough time to get the article improved, but if it is being put up for deletion after only existing for 2 days then the editor has just begun and now has a 7 day deadline, which as others have pointed out is still enough time to make it notable. But the thing is, alot of editors always make the comment "why put undue burden on the reviewer", how about we think from the editors point of view and say "why do we put undue burden on the contributor?" If you are going to tag something, then do your homework first. I know the work these reviewers do is just as important as those who actually edit and put info in, its just important in a less noticeable way and users like me who focus on putting things in instead of tagging often dont appreciate those other types of editors (who we often think of as making our lives miserable). I guess I brought this up to vent. But maybe we really should think again about having on a guideline page a sentence along the lines of "it is common courtesy to do some research, by looking at the talk page and the history on a page before tagging it with AfD or other tags to make sure it is not a new article or one whose problems are currently being addressed", similar to the paragraph we already have regarding removing uncited material that says:

• "Any material lacking a reliable source may be removed, but how quickly this should happen depends on the material in question and the overall state of the article. Editors might object if you remove material without giving them enough time to provide references, especially in an underdeveloped article. It has always been
  good practice
  to make reasonable efforts to find sources oneself that support such material, and cite them."

So that reviewers and editors know the burden is on the editor, but really the reviewer should take some time to be courteous and do some work themselves, instead of just slapping a tag and expecting someone else to come along and fix it.Camelbinky (talk) 23:02, 4 August 2009 (UTC)

I don't agree with this proposal in any form whatsoever.

Sometimes, when I am new page patrolling, I see articles that in my opinion (or stubs) that don't or just barely qualify for articles (or stubs). Sometimes I'm not sure if the article really qualifies to be speedied, sometimes I think the article has potential and deserve five to twelve days to improve. A lot of times, I'll PROD, tag and continue to new page patrol. Sometimes I'll clean up a little myself. However, there are times when I simply don't have the energy or expertise to clean it up, and sometimes there are simply too many articles that do qualify for speedy that I'll just do a "drive-by" tagging and continue patrolling.

If you disagree with a PROD tag, just take the tag down. We'll take it from there. I may or may not take it to AfD. Usually I don't.

If you can't improve an article in twelve days, then you can't improve the article, period. In the meantime, I will do you the courtesy of nominating it for deletion so you can hopefully move on with editing.

By the way, I don't "officially" patrol pages with {{underconstruction}} tags on them. I just realize the page is still being written and move on. No tagging, no nominations, nothing. Sandboxes are another, better alternative, as I then don't have a page clogging up the page setting off my "Hey, I have to look at this" alarm.

Hopefully, you will see a better side of Wikipedia someday.I dream of horses (T) @ 01:30, 5 August 2009 (UTC)

Camelbinky, there is nothing an editor can do to "make [an article] notable" — the topic either is notable or it isn't. Sure, in some borderline cases, time could be useful to make the case that the subject is notable. But when it's clear that the page is something made up in school one day, or if it's an attack page, or copyvio, or if the article name is tendentious or clearly a neologism, then there's not much point in waiting.

Deletion is not supposed to be (much) about the current quality of a given article, but about whether there should be an article about that thing at all. --Trovatore (talk) 01:51, 5 August 2009 (UTC)

But Trovatore, that is the problem, it isnt supposed to be about the current quality but to alot of these patrollers that's what they look at because too many of them patrol articles they have no expertise in and have no idea what they are looking at and therefore cant possibly know if it is notable or not. The one article I talked about earlier that had been a redirect for a long time before I made it and it then got put up for deletion right away is one example. The patroller had no knowledge about traffic circles or even the region it was in. I had to take time out while I was in the middle of putting an article through a GA review (which because I had to dedicate so much time to the one article the reviewer failed my GA review because I didnt get to her concerns fast enough, luckily I brought it back to her later and passed). This is one instance where it was indeed an UNDUE BURDEN to the editor (me) to quickly have to show notability. All because these reviewers, and I know they do it in good faith, go around to articles they dont know about. My personal policy is to keep my nose out of articles I dont know about. Perhaps if wikiprojects could police their own some of these problems could be handled without tags, if your a patroller and you see an article you have a problem with, and it has a wikiproject banner on it, let the wikiproject know and they can handle it since they would have a better understanding of what is notable in that subject/geographic region. I know with the wikiproject I co-founded concerning the Albany, NY region this has happened before and three or four members will jump to the article and have issues fixed within 48 hours (we just did that very thing last week, actually took us less than 6 hours I would say). Obviously not every wikiproject has motivated active members willing to do this, but many do I'm sure.Camelbinky (talk) 04:59, 5 August 2009 (UTC)

How are we supposed to judge an article if not by its current quality? And, quite frankly, it's not as if you have to drop everything to "defend" an article that's been marked for deletion. Recreation is allowed and, perhaps, it's just a sign that the article should be improved first before being moved to mainspace. If nothing else, just request it be userfied until you've had a chance to improve it. — The Hand That Feeds You:^Bite 19:27, 5 August 2009 (UTC)

In deletion discussions, you're actually not supposed to be judging the article. You're judging the title. Should there be an article about Plutonian hydrogen hockey, or not? That's the question before you, not whether it has a good writeup at the moment.

Granted, there are exceptions, but this is the baseline concept. --Trovatore (talk) 19:43, 5 August 2009 (UTC)

Thank you Trovatore, I completely agree and hope more reviewers in AfD read your post and follow it.Camelbinky (talk) 23:54, 6 August 2009 (UTC)

I noticed on the Polish Wikipedia that on the upper right links (where you see "my talk"/"my preferences" etc) there is a link to a user's personal sandbox, which when clicked opens up at the equivalent of "User:YourName/Sandbox". I would find this option very useful as I frequently work in a user sandbox before publishing in mainspace. Is something like this already available? Or even feasible to activate on en.wiki? I think in usability terms it would help too, as many new users could benefit from having a personal, safe location to work on their first articles etc.

You can do this for yourself easily with personal javascript. It can be implemented easily enough for all logged-in users if there's consensus, but I think I remember a fair amount of opposition last time this came up. Algebraist 14:27, 5 August 2009 (UTC)

Previous discussion here and here. Algebraist 14:31, 5 August 2009 (UTC)

I have that on my personal user javascript file. Feel free to copy from User:A_Knight_Who_Says_Ni/monobook.js.

There is a nascent discussion at

We've had abuse filters nearly 5 months now, and they have been quite a tremendous asset. After a few slipups at the beginning, the quality of these filters, has been great, with very little collateral damage. We have learned to prioritize filters, and use the abuse filter efficiently and effectively. Filters of several groups have been developed. One group warns users who make common 'newbie' editing mistakes. For example, if someone were to add '''Bold text''' to an article, they will be given a friendly warning pointing them to the sandbox, a warning that they can override if they wish. Another type attempts to identify and tag possible vandalism. Tagged edits can be reviewed by editors, to identify which edits are vandalism, and which are not. Finally the third type of filter targets specific, repeated, high-priority, and ongoing vandalism. Filter 179 is an example of this. As you can see, the hits from this filter are packed tightly in time, and have extremely good discrimination between good and bad edits. They look only for one specific type of vandalism, and target only that type as narrowly as possible. Due to the nature of these filters, the users who hit them are nearly always compromised hosts, or open proxies. Filter 7s recent repeat triggering today is a great example of this phenomenon. To block these proxies, someone has to manually block every IP that hits the filter. Because of the very targeted nature of these filters (for example, a filter might only target page moves where the new page name contains 'on wheels'), and because these filters tend to be active only during the periods where these vandals are active, is is virtually guaranteed that any hit of the filter is genuine. I think that the ability to make this very small subset of filters automatically block users that trip them would save administrators a great deal of time, as they would not have to constantly monitor and block anyone tripping the filter. Obviously the filters that would be set to block would only be the most narrow in scope and most accurate. What are people's thoughts on enabling the ability to create blocking abuse filters? Prodego ^talk 22:03, 31 July 2009 (UTC)

I think it is an overdue need and that in circumstances that the filter has a very low false positive rate and its an edit that would be a blockable offense (as judged by its creator) there is no reason that this ability should be restricted. Alexfusco⁵ 22:13, 31 July 2009 (UTC)

That is an important point Alexfusco, this would only be used for actions which would justify an immediate block. Prodego ^talk 22:14, 31 July 2009 (UTC)

I don't think implementing this is a good idea. Blocks, are recorded on the permanent history of an account. I do not share your faith in the unlikelihood of false positives or lack of need for human checks before such blocking. For these reasons I'm against the proposal. Despite your suggesting only very select filters would be involved here, I do not share your confidence in trusting them to appropriately autoblock. –Whitehorse1 22:20, 31 July 2009 (UTC)

Is it really too much trouble for a human admin to adjudge the merits and side effects of blocking each IP or user? That isn't a rhetorical question. This proposal is clearly against the

WP:BLOCK policy as it is now written and presumably requires a very broad discussion. Delicious carbuncle (talk

) 22:33, 31 July 2009 (UTC)

I wouldn't say it is against the block policy. Let me just give you an example of what would be an acceptable situation for a filter to block. Lets say, some vandal, using many proxies, is going around and replacing the content of random pages with some phrase. Lets say the phrase is something like 'I will sue you in a Court of Law in Trenton, New Jersey!', you can use any obvious example you want, say some image of a penis... In this case, you could create a filter which would trip only when a non-registered user takes an existing page and blanks it, leaving only the text 'I will sue you in a Court of Law in Trenton, New Jersey!'. Any administrator, knowing that this is just a throwaway proxy, would immediately block that IP, and there is no situation where you would legitimately replace a page with this phrase. Even then, the filter would immediately be disabled once the vandalism stops. To be honest, when I create a filter with this level of accuracy, I block those who hit it without looking at the content of the edit. Why don't I have to look? Because I already know what the content of the edit was, the filter is so specific as to immediately identify it. Prodego ^talk 22:40, 31 July 2009 (UTC)

The first sentence of the policy is: "Blocking is the method by which administrators may technically prevent users from editing Wikipedia". It is a mistake to assume that simple text string matches will never have false positives. You seem to have skipped my non-rhetorical question - is it really too much trouble for a human admin to adjudge the merits and side effects of blocking each IP or user? Delicious carbuncle (talk) 23:28, 31 July 2009 (UTC)

It takes enough time that I have not been doing it. Perhaps some people do. Prodego ^talk 23:30, 31 July 2009 (UTC)

I'm going to oppose this until there is a very clear procedure on when to set a filter to block a user, and when not to. Just activating this would be a very, very bad idea, and I don't think any single administrator should be allowed to just set a filter to block when triggered. There needs to be a very clear consensus first, and there should be no false positives. I suppose that's common sense, but I want this to be set in stone (as in, written into the edit filter guideline) before I'm even thinking about supporting this. --Conti|✉ 22:44, 31 July 2009 (UTC)

Of course. I'm talking about the general idea of implementing it, not the specific procedure that would be used. One option we have is to restrict who can create blocking filters to a new user group, which could be selected in some way. Additionally, there would have to be something done about the 2 non-admins who currently have access to edit the filters. What I am asking is: do you believe that enabling blocking filters would be positive. Not: this is how we are going to implement it. So I agree with your analysis fully Conti. Prodego ^talk 22:50, 31 July 2009 (UTC)

I suppose in an ideal world the blocking feature for the filter would be a good thing. I'm just not sure if we live in such a world yet. :) If the feature is not abused, if no careless mistakes are made, if people get a fair way to be heard when they disagree with the blocks, then yes, I don't oppose the new blocking feature. I like FT2's proposal below. --Conti|✉ 10:41, 1 August 2009 (UTC)

I note that no one has answered Delicious Carbuncle's non-rhetorical question: is there a problem that needs to be solved with this? How much work is being done by admins that would be avoided by this solution, and that could not be taken care of by FT2's "parallel proposal" below, and is it sufficiently burdensome to warrant this solution? I concur with EdJohnston's recommendation below that each blocking filter have a specific admin who takes responsibility for it. ☺Coppertwig (talk) 13:06, 2 August 2009 (UTC)

Proposal

If some filters are now identifying issues with high precision, then I would suggest a specific process, akin to approval for an bot. It's the same kind of idea - an automated process will be allowed to act on-wiki, and the community should have the chance to scrutinize the evidence that the filter is tested, stable, mature, and discriminating, before it is in effect given an admin right. Proposal:

A filter that has achieved stability, maturity and a high level of precision (and in particular an extremely low "false positive"), over a period of time, may be proposed to have administrator tool responses added to it. These may include blocking and page protection. Such requests are presented for communal scrutiny, with a formal statement and evidence section showing The filter's purpose Evidence of need Evidence of track record (including in each case, "false positive" analysis showing how it would have acted if admin tools had been in place) An explanation why adding admin tool responses would be beneficial to the project An explanation of how the filter will be maintained, how its quality will be reviewed, and any proposed safeguards over its admin tool use. If there is a false positive risk, but this is said to be of a very low level, then the statement should explain why this is on balance reasonable, and how the responses will be designed so that users who are affected by a false positive will receive a courteous explanation and be able to quickly and without prejudice rectify it. If consensus agrees then after a discussion lasting [7, 10] days, the tool will have admin responses enabled (possibly to an agreed limited extent) for a trial period of 2 weeks. Subject to lack of evidenced problems, admin responses will then be considered approved. Any subsequent significant change to the filter code, or nature of responses of a kind likely to introduce a higher risk of errors, shall require reconfirmation. Users making such amendments may wish to trial the code on a new filter so that the original filter is not disturbed.

Any good?

FT2 ^{(Talk | email)} 23:03, 31 July 2009 (UTC)

In my opinion, any blocking that does not involve a human performing the block is a bad thing.--Rockfang (talk) 23:14, 31 July 2009 (UTC)

I was able to look at today's log of Filter 179. This is an extremely specific filter that nobody could run into by accident, it deals with conscious vandalism of a certain kind, and I wouldn't see a problem if each of those edits had triggered a block. Since all these accounts were IPs, a block of anywhere from one day to a week might be reasonable. Let's say that it would be extremely surprising if anybody would have the temerity to ask for an unblock, if they were caught by Filter 179. So far as Filter 7 goes, my own review didn't convince me that Filter 7 was ready to do any automatic blocking; I'd need to hear more. If automatic blocking is ever turned on, the blocks need to be 'owned' by some administrator who is responsible if anything goes wrong and whose reputation would suffer if they goofed up. There needs to be a community review of whatever scheme (if any) is adopted, and FT2's idea may be heading in the right direction. (If the details of Filter179 were fully explained, though, it might lose its value). EdJohnston (talk) 23:33, 31 July 2009 (UTC)

The difference is that 179 was designed to be extremely specific. It is effectively my personal filter for ongoing attacks. 7 is rougher because it is being customized for ongoing vandalism, by many people, and is only supposed to be enabled during anontalk attacks, not all the time, like (most of) 179. I'll discuss FT2s proposal later, but the gist of my response is going to be that the type of filters that need to be blocking will not be useful 7 to 10 days after you need them. Prodego ^talk 23:38, 31 July 2009 (UTC)

(e/c)@Rockfang: I would point out that we've had a bot blocking open proxies for about 6 months now as well as a bot blocking pagemove vandals and abusive usernames. Mr.Z-man 23:43, 31 July 2009 (UTC)

Not to mention the unapproved blocking adminbot that is User:Misza13. Prodego ^talk 23:48, 31 July 2009 (UTC)

<-I agree with Rockfang, automated blocks make me very nervous, if one cannot be virtually certain that false positives will not occur. I'm not familiar with the proxy that blocks open proxies, but if I understand open proxies correctly (and I'm not sure I do), the concept of a block on one's permanent record isn't an issue in that case. I'll toss out an intermediate option (intermediate between a bot blocking and an administrator having to manually block). Why couldn't a bot identifying what appears to be a blockable offense drop a notice on the talk page - saying something like "Attempted edit xxxx appears to be a violation for which blocking is warranted. If you think this is in error, please contact an administrator (you can do this with template adminhelp) within n days. If you do not provide a reason, you will be blocked. If an administrator reviews the edit prior to that time, you may be blocked sooner."--SPhilbrickT 19:44, 1 August 2009 (UTC)

"within n days"? I'm not quite sure you you understand the purpose of such filters and bots. These are things that require immediate attention. Spambots, pagemove vandals, attack usernames, etc. Mr.Z-man 21:33, 1 August 2009 (UTC)

Sorry, I'm not buying this. And it is fully possible I don't fully understand, so if there's a place to read more about it, please point it out.

Can we distinguish between a user moving a single page in violation of a policy, and a vandal attempting mass movement of pages for disruption? I have no problem with a bot doing blocking if it detects multiple blockable offenses, but I find it hard to believe that a new user, me for example, couldn't accidentally move a page in a way that violates the rules. I cannot believe that such a single move is so egregious that it can't wait a few minutes for an admin to look into it—instead, a bot must block immediately. While my original proposal didn't distinguish between a single action and multiple actions, that distinction now seems appropriate.

I don't follow how an attack username requires immediate attention. By "attackusername", are you talking about a name in violation of policy? If so, why does it require blocking within seconds? Keeping in mind that a very egregious violation is likely to attract a live admin in short order anyway, the only time this would otherwise go unnoticed for several days if if the violation is in a gray area. Do you have bots that are that good? Again, I'm sure I'm missing something - please help me figure out what I'm missing.--SPhilbrickT 16:56, 3 August 2009 (UTC)

I'm referring to page move vandalism like moving Judaism to "JEWS DID 9/11" and other things like these, I find it hard to believe that a user could do that by accident. Given a few minutes, a dedicated page move vandal could move a couple dozen pages. (And yes, both bots and the abuse filter can distinguish between multiple violations, though in obvious cases, it isn't necessary). For attack usernames, I'm referring to things like "User:X's real name is John Doe and he lives in ...". Things like that require an oversighter to clean up after it. And yes, we do have a bot that catches these - User:AntiAbuseBot. Nobody is proposing handing full control of anti-vandalism work over to bots, just to allow the abuse filter to handle some of the obvious cases without manual intervention. Mr.Z-man 17:34, 3 August 2009 (UTC)

I'm afraid we aren't on the same page. My question is motivated by the observation that we have bots with the ability to block users, and the culture which tags a block as a serious blot on one's record. If true, false positives are serious. I don't disagree that moving "Judaism" to "JEWS DID 9/11" is blockable—are you telling me you have a bot that can distinguish that move from an attempt to move "Judaism" to "Jewish Religion", the latter of which deserves a revert and an admonition but not a block? That's a fairly sophisticated bot, if true.

Thanks for the explication of attacknames, I did misunderstand the term. Now that I understand it, are you really saying there are bots that can find such an statement without any false positives? And that such an action requires immediate blocking? I understand why the elimination of the outing requires prompt attention, I'm missing why the block as to be done mechanically, rather than by a human. We don't have any bots with oversight rights do we? I assume oversighters have admin rights, so if an oversighter cleans up the mess, why can't they do the block.

Sorry if I sound obtuse, I'm trying to understand.--SPhilbrickT 20:11, 3 August 2009 (UTC)

I can't tell if you're over- or under-estimating the capabilities of bots. Are you imagining that a bot would just block everyone who moved the Judaism page? Or that one would need a complex set of heuristics to tell the difference between the 2 moves? It would not be especially difficult. It might be more difficult to avoid a false positive if the page was (in good faith) moved to something like "RELIGION OF THE JEWS AFTER 9/11" but that's a rather unlikely scenario.

Its easy to avoid false positives if you just have very strict criteria for a match. Its just a balancing act. We would (using hypothetical numbers) basically have to choose between the bot catching 90% of all abusive usernames, with one false positive per week, or 70% of abusive usernames with one false positive per year. You're never going to be able to catch 100% with 0% false positive rate, but that doesn't mean we shouldn't try. As for "if an oversighter cleans up the mess, why can't they do the block" - its about damage control. The sooner its blocked, the fewer edits have to be oversighted and the fewer people see the potentially private, libelous, (or sometimes both) information and the more frustrating it is for the vandal. Mr.Z-man 22:02, 3 August 2009 (UTC)

Not sure. Would requiring 7-10 days of discussion make the feature relatively useless, since it's needed (?) in specific situations where huge numbers of sockpuppets are appearing at that moment? On the other hand, would allowing it without such discussion make it too dangerous? Here's an idea (if it's established that this is needed at all; maybe just FT2's parallel proposal would be enough): Identify a number of admins who have experience with abuse filters and are trusted to do this. If an admin wants to make a filter to address an immediate situation, they get it (quickly) approved by one of those experienced admins, implement it, announce it on AN/I, and if there isn't consensus for it, it can be turned off again. ☺Coppertwig (talk) 13:06, 2 August 2009 (UTC)

A parallel proposal

In parallel with that, this may be an alternative approach that doesn't require approval for admin tool responses, and does not have a problem with error rates, and therefore is useful for many filters that would not meet the approval level above.

If the extension provides a page of "filter hits" with check boxes next to each (AJAX filterable by filter # or the like), then an admin can click on individual checkboxes or shift-click a range, to perform a specified admin action on all selected events or the users responsible. FT2 ^{(Talk | email)} 23:45, 31 July 2009 (UTC)

Good idea, I think, whether or not there is automatic blocking as such. Admins would still have to be careful about false positives. ☺Coppertwig (talk) 13:06, 2 August 2009 (UTC)

Special:AbuseLog isn't quite that quick, but it does allow for fast review, and can be sorted by filter, user, and/or page. I'd be worried people might not look closely enough at edits before taking action, but nevertheless it's an interesting idea. – Luna Santin (talk) 09:28, 3 August 2009 (UTC)

Who would get the new flag?

Should all admins get it, or should it be separate from the admin flag? If the latter, how should users get the flag?

I think it would be very wise not to give the abilty to every admin, since abuse or misuse of it could mean serious harm. Only those that need it should have it, and there should be an informal (like

I think a new userright is overkill, but perhaps we could have some kind of "Senior edit filter managers", and the understanding only they are allowed to set the flag. They could be voted on at

WT:EF. –xeno^talk

00:44, 2 August 2009 (UTC) Edit: just read Werdna's statement below that the blocking functions could be restricted to admins, and perhaps a subset of the same. That's a good idea, especially the former, the latter if it doesn't require a usergroup.

I'd rather not have 1000 admins with the ability to automatically block users with the edit filter. I don't see what's wrong with a new usergroup, since the new feature would be used by only a few admins, anyways. Giving it to all admins will simply heighten the chance dramatically of someone making a rather bad mistake. --Conti|✉ 11:47, 2 August 2009 (UTC)

It is important that many people have the ability to disable a blocking edit filter. It is fine if not many people can create one, but it needs to be easy to shut down while everybody who understands the code is sleeping. Kusma (talk) 06:49, 3 August 2009 (UTC)

I have just given myself the editabusefilter right. In the current implementation, I could shut down a misbehaving filter, and will be able to figure out quickly what to do. Of course, any admin who writes sucky abuse filters should be told not to do so, and be desysopped if they don't stop. But that's no different from other admin tools. I don't see a need for an extra usergroup here, unless you want to have non-admins who write blocking abuse filters. Kusma (talk) 06:59, 3 August 2009 (UTC)

It would make me nervous, but a new user priviledge is overkill -- just restrict it to all abuse filter editors who are also admins, and treat it much like the MediaWiki namespace editing every admin can already do, where consensus is a must and the expectation is pretty much that one screw-up will lead to immediate mauling by angry bears. As has been mentioned, the more people can disable one of these filters, the safer we'll be. – Luna Santin (talk) 09:22, 3 August 2009 (UTC)

Technical Clarifications

Note that the following so-far-unseen features apply to blocking abuse filters:

• Filters which match a large percentage (currently 5%, I think) of edits and are set to block will have the blocking part disabled.
• Adding the block action to a filter, or editing a filter which is set to block, is restricted to users in a particular group. This group could be the administrator group, or a subset thereof.

Time permitting, I am happy to implement features of reasonable complexity that improve the safety of blocking Abuse Filters. — Werdna • talk 09:00, 1 August 2009 (UTC)

Can users who are not part of the block-filter group still see the contents of the corresponding filters? --Conti|✉ 10:52, 1 August 2009 (UTC)

Eh, wait. That's what the "hidden" option is for, so I guess the answer is "yes". Leaving this here just in case I'm wrong, tho. :) --Conti|✉ 10:54, 1 August 2009 (UTC)

Okay, let me ask one question of implementation. Assume somebody gets wrongly blocked by the abuse filter (not a common occurrence, but it will probably happen at some point). If a standard adminbot does that, I can go and unblock the user and block the adminbot so the problem doesn't happen again until it is fixed (and I'll talk to the adminbot owner about it). What can I do when I find that somebody was wrongly blocked by the abuse filter? I wouldn't be happy if I can't easily disable the offending filter until it is fixed. (That is our standard way to deal with bot problems: disable them quickly, investigate later before more harm has been done). So please make it easy to disable specific features of the abuse filter without waiting until somebody with technical knowledge shows up. Kusma (talk) 16:06, 2 August 2009 (UTC)

This is another reason why I believe that all admins should have the abusefilter-modify permission, so they can quickly react to situations like this. As an admin, you have the ability to modify the edit filters... the workflow is Special:UserRights → fill in your username → check "Edit filter managers" → enter "panic" as the reason → save → Special:AbuseFilter → take action. The first five steps are entirely pointless makework in 'peace', and dangerous timewasters in an emergency. Happy‑melon 16:19, 2 August 2009 (UTC)

These four steps (you don't need to enter a reason) take about 20 seconds or less, if you know what you're doing. If you don't, then you probably shouldn't try and modify a broken filter. --Conti|✉ 20:00, 2 August 2009 (UTC)

I agree, I'm not trying to claim that they represent a difficult hurdle to gaining access to the filters. That is precisely the problem; they do nothing as checks and balances, because they are so trivial to complete, yet they are a noticeable and tedious piece of bureacuracy in the process. You say that a reason is not required. So the addition need not even be justified, requires no human thought whatsoever, it is purely a cookie-crumb trail of button clicks that has to be completed before the filters become accessible. Again, what purpose does that serve? Happy‑melon 20:55, 2 August 2009 (UTC)

As I said above, the modification of a broken filter (which requires technical knowledge) doesn't have to be done immediately, but it has to turned off immediately until it does more damage. Simple really: If a bot misbehaves, it gets immediately blocked, and then it is fixed and unblocked. No reason to treat the edit filter different from other automated systems. (And while I don't want to learn how to program edit filters, I am smart enough to unclick the "enable" button and to click "save" to disable a filter when there seems to be a problem). Kusma (talk) 07:03, 3 August 2009 (UTC)

That's actually a good point. More people being able to disable a filter is certainly a good thing. I'm simply worried about someone messing things up, but instead of halting the editing of the wiki for a few minutes, we'll end up with hundreds of people being blocked, or something similar. We need a clear process/guideline/whatever before we turn this thing on, especially if we add this feature to the editfilter usergroup. --Conti|✉ 10:59, 3 August 2009 (UTC)

Wider discussion requested

I have started a thread at AN to discuss the discrepancy between current

Why can't we have the filters post to a central page, similar to bot-reported vandalism at Wikipedia:Administrator intervention against vandalism? This way, the filter does not perform the block itself, but with hundreds of admins watchlisting the filters' reports page, we should have a very quick response time. -- Avi (talk) 07:02, 3 August 2009 (UTC)

Special:AbuseLog provides something akin to that, though not in a format or location I think most of our users are familiar with; are there ways in which it might be made more useful? – Luna Santin (talk) 09:36, 3 August 2009 (UTC)

An indication whether an edit caught by the filter was actually made would be a very big step forward. :) --Conti|✉ 11:00, 3 August 2009 (UTC)

User:Mr.Z-bot already does that. Cenarium (talk) 13:43, 7 August 2009 (UTC)

I've been advised to post this here as I've tried Main Page discussion and Main Page/Errors discussion which apparently was the wrong place. Just a minor thing but could the main page sidebar navbox titles (navigation, search, interaction etc.) start with an upper case letter to match the contents of the boxes? Just looks 'wrong' to me! The simple English version is the same but other language wikis appear correct. Many thanks for your time. Nimbus (Cumulus nimbus floats by) 08:37, 7 August 2009 (UTC)

They directed you here, because the toolbar is not just present on the Main Page, but it's present everywhere in the same basic state (see it on the side of this page?) That can be changed. You may like to try Beta. The titles are all capitalized in it. hmwitht 17:43, 7 August 2009 (UTC)

The link for "Try Beta" is at the top of your window, just by your username. Thincat (talk) 17:57, 7 August 2009 (UTC)

If you don't like the vector beta, you can do this in monobook with CSS. Algebraist 22:25, 7 August 2009 (UTC)

I noticed that Wikia sites have the option to switch between the normal text editor and a rich text editor (when you edit a page, the content appears the same as when you view the page - you don't see the raw code). I think this would be a great option to have (especially on the discussion pages) and would give casual editors a much more user friendly option for editing. Any thoughts?--SuaveArt (talk) 09:58, 7 August 2009 (UTC)

They're currently working on the editing window, toolbar, and similar ideas regarding usability (for information about the usability initiative and future releases, see [4]). In the meantime, you can try the the new Beta version or try

WP:WIKED for more features. hmwitht

17:37, 7 August 2009 (UTC)

I propose we place interwiki links to the simple English Wikipedia at the top of the "other languages" links. The current practise is to sort them alphabetically by language code, putting them somewhere in the middle to lower area where no-one notices it. Of course this would also have to be implemented technically, but I believe this can be done by just asking the maintainers of the interwiki bots and the interwiki bot framework to move the simple English link whenever they modify an article. —Ruud 17:50, 3 August 2009 (UTC)

I would additionally or alternatively like to propose making the links to the simple English Wikipedia stand out more by, for example, making them appear in bold. This can easily we done by adding a single line of CSS to the stylesheet. —Ruud 17:53, 3 August 2009 (UTC)

The assumption with this, I'm assuming, is that a simplified version of each article is desired by the reader. I don't see why you'd make that assumption; the only time we should highlight an interwiki above any other is when the quality of that article is exceptionally high (which we do with the {{Link FA}} template).
Now, that said, I wouldn't be opposed to SE interwikis being at the top of the list, but isn't there javascript that could affect that change instead? EVula // talk // ☯ // 18:06, 3 August 2009 (UTC)

My reasons are twofold:

• I indeed believe that the Simple English article is preferable to a lot of readers. A non-native reader of English would probably prefer the articles in his native language(s) and those in the English or Simple English language. Obviously, what the article in his or her native language is would differ for between the readers, but in total a large proportion of them would favour the simple English language article.
• The second, maybe even more important, reason is that simple English would be unduly disadvantaged by sorting it so arbitrarily. A reader would have a clear incentive to look for his native language in the list, but not for the simple English link as he or she is probably unaware of its existence.

Yes, I could also write a short piece of JavaScript that accomplishes this. It is probably not very preferable to rearrange page elements after is has been loaded with JavaScript, but might do as an interim solution. Actually, it is also possible to use JavaScript to move the articles in the language(s) configured in the user's browser as his or her prefered language(s) to the top. —Ruud 18:28, 3 August 2009 (UTC)

I seems that JavaScript can only figure out the language of browser's interface. The full list of prefered language can only be accessed server-side. —Ruud 18:57, 3 August 2009 (UTC)

I'm afraid that encouraging people to go to Simple English will just increase the nationalism, COI and POV wars on Simple, with fewer eyes to control them. Who then was a gentleman? (talk) 20:10, 3 August 2009 (UTC)

What? I wasn't aware of any serious problems on Simple English. If you want to discourage people from going visiting the simple English Wikipedia, you should seriously consider shutting it down entirely. Of course, this could potentially have the opposite effect if due to increased visibility en adminsactive editors would start keeping an eye on simple? —Ruud 20:47, 3 August 2009 (UTC)

So let's be honest: I'm pretty skeptical of simple both as a concept and as a project as currently implemented. As I understand it, the content is not supposed to be dumbed down; only the language is supposed to be simplified. But these tend to be contradictory goals; the difficult parts of natural language are there, for the most part, because they were needed, not to make people's lives more difficult. I don't think simple is a success or ever will be, so I don't support giving it more prominence.

But no, I have no ambition to shut it down. Let people try, if they want to, to do this very difficult (most likely impossible) thing. Maybe the effort will expose places where the complexity in the enwiki article really isn't ncessary. --Trovatore (talk) 20:54, 3 August 2009 (UTC)

I sceptical of simple for the same reasons, but I'd say that either we'd try to make it successful (or at least pretend it is or will be and give it the prominence that would be justified if it was) or shut it down right away. Keeping it lingeringly active, tucked away in some obscure place doesn't seem an appropriate way to handle this to me. —Ruud 21:09, 3 August 2009 (UTC)

No, there isn't a great deal of controversy at Simple, but if we "advertised" it all over en., then the edit warriors who get shot down here could go there to continue their wars, and there are far fewer admins to deal with them over there. And en admins have no control over Simple, it's its own Wiki. I've never said anything about shutting down Simple, nor do I advocate that. Who then was a gentleman? (talk) 21:01, 3 August 2009 (UTC)

Just as a note, this has been

It can be added to MediaWiki:Sidebar. According to File:Simple_English_Sidebar3.png it should be put right after the toolbox. Ruslik_Zero 15:06, 4 August 2009 (UTC)

Not only will conflicts come from here to there, but there will be people who will shout IMPERIALISTS! NATIONALISTS! OPPRESSORS! IMPOSERS!, because we're "imposing" the English language (and English-speaking culture_ on other people by advertising the simple english wikipedia. I'm not sure what to think of the latter opinion, but it is worth looking into. I dream of horses (T) @ 01:36, 5 August 2009 (UTC)

I think that promoting the Simple English WP on the English WP over French and Japanese is perfectly understandable. I very seriously doubt that anyone would be upset by it. I completely agree with the above that Simple isn't useful, but as long as we can't close it (it's been tried), we might as well use it. ▫ JohnnyMrNinja 07:44, 9 August 2009 (UTC)

How about using

I'm positive it's been proposed before, but it'd be nice if in your list of watched pages, there were some sort of marker to identify pages that are redirects. I dunno how technically feasible this is, but since the "what links here" shows it, I can't imagine it'd be TOO hard. ♫ Melodia Chaconne ♫ (talk) 20:08, 7 August 2009 (UTC)

If you're satisfied with something that works only for users who activate it, User:Anomie/linkclassifier.js does this, among other things you might want. (I noticed that my colours disappear when I switch to the new Beta though, but I guess that can be solved.) —JAO • T • C 20:24, 7 August 2009 (UTC)

Putting your personal .js in vector.js instead of monobook.js is the first step. Some scripts will need actual rewriting, though. Algebraist 22:28, 7 August 2009 (UTC)

Thanks—works like a charm! —JAO • T • C 08:52, 8 August 2009 (UTC)

As an improvement to the Article request page, how about an Article Launcher like YKTTW on TV Tropes? It could be useful for allowing I.P.s to start articles whilst limiting the problems that led to Anons not being able to create pages. Thoughts?----Occono (talk) 00:31, 11 August 2009 (UTC)

Maybe I'm missing how that works, but isn't it primarily for issues naming articles? I don't it is the titles that are the issue with anon page creation, but rather the content. Did I misunderstand it's function? ~ Amory (user • talk • contribs) 00:54, 11 August 2009 (UTC)

No, and yes. It's mainly for determining whether something is a genuine Trope, gathering examples, making sure it's not a duplicate etc., though it can be used just for coming up with catchy names. Anyway, the point is that it would be good for improving the content of an article before launching it.----Occono (talk) 01:24, 11 August 2009 (UTC)

Is it needed? YellowMonkey (cricket photo poll!) paid editing=POV 03:45, 11 August 2009 (UTC)

After carefully reviewing all the mentions of "Vector" on Village Pump pages and [5], I propose that it replace Monobook as the default skin immediately for a period of one day after which the default shall be reverted, comments shall be examined, and further proposals including either general adoption and/or goals for the usability team will be in order. HowDoIUseUnifiedLogin? (talk) 17:58, 1 August 2009 (UTC) (sock of Nrcprm2026 --Enric Naval (talk) 02:24, 7 August 2009 (UTC))

Has anyone checked the scripts that people now invoke from their monobook.js, for example:

User:Mr.Z-man/closeAFD.js

User:Jnothman/afd_helper/script.js

Do the existing scripts that were written under Monobook continue to work when invoked from the new vector.js in all browsers? What about Twinkle? Checking how many people have tried creating their own Javascript file under the Vector skin, I only see 50-100 people who have created 'vector.js' files for themselves. Blanket usage of the Vector skin sounds premature. EdJohnston (talk) 21:12, 1 August 2009 (UTC)

Most "major" scripts will work in Vector. All gadgets definitely work. This was tested and fixed about a month ago. Everything that does not work can be easily fixed. —TheDJ (talk • contribs) 21:18, 1 August 2009 (UTC)

How do you tell the difference between "using the default skin" and "using Monobook"? Or are all those who prefer Monobook going to have to suffer through your day? Anomie⚔ 21:31, 1 August 2009 (UTC)

You can't; there's no obvious way in preferences of distinguishing between "I use Monobook because I love it" and "I use Monobook because, meh, I haven't bothered changing". A forced change like this would also remove any changes made to a Monobook user's personal css, which would undoubtedly prove unpopular!

talk

| 21:35, 1 August 2009 (UTC)

This is no longer entirely true. Since a couple of months ago, preferences are only saved in the database when they have been modified; 'default' settings are no longer stored, and so can be changed without affecting users who have saved an explicit preference. However, there is some complication with the huge body of preferences saved before this transition, which won't have this ability. But the default can be changed for logged-out and new users without impacting on users who have specified another skin, including monobook. Happy‑melon 16:09, 2 August 2009 (UTC)

I think this discussion was just had about something less big, but all users that are currently at "default" could conceivably be switched to Monobook, right? ▫ JohnnyMrNinja 03:25, 3 August 2009 (UTC)

There is absolutely no point in performing a one-day test. There's not a whole lot of point in performing a one-week test. The Foundation has poured thousands of dollars into the usability initiative that has created Vector. This skin, or another like it (certainly 'a skin other than monobook') will become the default skin on WMF wikis. What do we gain from yo-yo-ing between the two skins, other than confusion? If we anticipate problems (other than familiarity issues) with the transition, then that's evidence that the transition is premature. But this change is going to happen at some point AFAICT, despite the huge inertia of the projects. There's no point in rushing: if we can't agree that the time is right to transition permanently, then the time is not right to transition at all. Happy‑melon 22:19, 1 August 2009 (UTC)

I agree, the confusion caused from switching the skin back and forth so rapidly would likely overwhelm any useful data. Mr.Z-man 23:18, 1 August 2009 (UTC)

I agree with each of you that Vector is probably ready for mainstream (indefinite) use and that a short test would be confusing, but I'm worried that changes in Vector, or another, newer skin, might cause similar problems to that of a short test. For example, Vector is the "Acai" (A) release, and has open-ended tabs. The "Babaco" (B) release mockup has closed tabs and a different, "soft shiny" look. Given the significant aesthetic differences, I'm wondering how soon we want to make the new skin the public default: if the usability initiative is going to make significant aesthetic differences with each release, it would look odd to the outside world to have Wikipedia's look continually changing, even through the "official" mechanisms of the Usability Initiative. If we implement something, we want it to last at least a couple of months before it is changed. {{Nihiltres|talk|edits}} 23:43, 1 August 2009 (UTC)

Site-wide "Beta" invitation is scheduled to be rolled out to all Wikimedia projects later this week. This invitation is intend for non-logged in users to either create an account or log-in and change their default skin to Vector and enables the enhanced toolbar. People who do not like the new interface can leave "Beta" in one click and provide feedback if they choose to do so. The usability team will share the opt-in/opt-out stats once we have accumulated data. You can check out how the beta invitation is implemented by visiting the prototype site. --Shuhari (talk) 21:05, 3 August 2009 (UTC)

In light of the above I modify my proposal to simply cut everyone over if they have Monobook in preferences, with some kind of a warning in a site notice that they will have to change it back if they want to keep the customizations in their monobook.css or monobook.js file(s). HowDoIUseUnifiedLogin? (talk) 01:54, 2 August 2009 (UTC) (sock of Nrcprm2026 --Enric Naval (talk) 02:24, 7 August 2009 (UTC))

With due respect, that sounds like a terrible idea. Deliberately interfering with someone's preference settings violates every possible expectation of what those setting mean, and would piss most people off to no good end. Moreover, you're not going to get a neutral evaluation of the Vector skin from people who have had it summarily dumped in their laps when they did not want it. — Gavia immer (talk) 02:06, 2 August 2009 (UTC)

Er, that's how the transition will have to work, since we don't have a 'use site default' selection in addition to the "default" monobook.    M   03:12, 3 August 2009 (UTC)

Well no. You could leave all existing accounts as is and only switch IPs and new accounts after some date. Dragons flight (talk) 03:29, 3 August 2009 (UTC)

Out of curiousity, is there a compelling use case for Vector? By which, I mean is there something I can do with Vector that I can't do with Monobook? Maybe I'm old fashioned, but I've played around with Vector and generally find I like the feel of Monobook better, so I plan to continue using it for the foreseeable future. I did install the advanced editing toolbar though, that's nice. Dragons flight (talk) 02:28, 3 August 2009 (UTC)

I agree with DF. I've played with Vector and still prefer Monobook. Also, I think some of VoA's scripts aren't working with Vector, FWIW. -- Avi (talk) 07:12, 3 August 2009 (UTC)

Quite simple. It's what the unregistered readers will see. So I would stick with monobook for writing in user space but will use the new ... novelty for checking page layout when it's ready for release into main space, or making major changes to existing page layout.

NVO (talk

) 10:30, 3 August 2009 (UTC)

I'm with Dragons flight on this too. Vector is supposed to improve usability, but I see nothing but arbitrary change for the sake of change (which invariably reduces usability for a time). I'm very uncomfortable with the idea that the skin's default implementation is predetermined and inevitable (because of the amount of money invested in it?), regardless of the community's opinion. "We have no choice, so we might as well get it over with" (scare quotes) is far from a compelling rationale. —

David Levy

10:59, 3 August 2009 (UTC)

I'm also curious what is so great about it; but then, I have already improved usability for myself by removing the edit toolbar (you shouldn't use the mouse to write code) and switching to Modern. I see as little incentive to use Vector as I see to use Monobook (the incentive for Monobook is mostly "it's the standard"; I sometimes check what pages look like in Monobook so I'll see what others see). Kusma (talk) 14:14, 3 August 2009 (UTC)

I tried out vector, and I see that is wastes more screen area at the top and bottom, making it harder to head articles on small screens. Changing the default skin would also disable all the user scripts people have in their monobook.js files. You would have to copy everyones monobook.js to vector.js, or make the user scripts not connected to the skin. Why is like that anyway? In general I think very few have heard of Vector, even among the most active Wikipedians. You should spread some awareness before you force the switch. --Apoc2400 (talk) 10:17, 3 August 2009 (UTC)

T12183 is related to the idea of a Special:Mypage/common.js. I do think it would be a good idea. (also)Happy‑melon 10:47, 3 August 2009 (UTC)

It does not always work either; I copied my jss/cs to Vector, and the VoA scripts still do not work, at least those that I have tried. -- Avi (talk) 12:43, 3 August 2009 (UTC)

Ew. Vector is ugly! Who then was a gentleman? (talk) 20:07, 3 August 2009 (UTC)

I second that assessment. I thought someone in my family had screwed up the computer’s defaults, but couldn’t find a way to fix it … then I noticed the same “problem” when trying to access WP from work. So, when do we revert? Askari Mark (Talk) 17:06, 7 August 2009 (UTC)

Ok, so, usability point: "use sitewide default" as a skin selection? --Kim Bruning (talk) 23:42, 3 August 2009 (UTC)

Definitely. Oh, and I hadn't realized that they still haven't fixed any of the problems brought up on that feedback page over at usability., especially that huge space at the top of the page. Until they do that and are ready to solve any new problems that come up, we should stick with monobook.    M   00:03, 4 August 2009 (UTC)

• At the rist of spamming, would it be effective to use a bot to post a note pn the talk page of every user with a custom monobook.css page, warning them of the iminent shift and asking them to copy their scripts to vector.css to check for problems? It could be limited to those who've edited within some reasonable time increment to avoid spamming inactive accoutns.   Will Beback  talk  01:28, 4 August 2009 (UTC)

Excuse me, but what's wrong with monobook? Why fixed something that isn't broken? I dream of horses (T) @ 01:46, 5 August 2009 (UTC)

I too can't see the need for change and certainly don't understand why people should be forced to use vector, if only for a day. I'd welcome a global message notifying people of its existence, and encouraging new users who can't use monobook to employ it, but I can't see why we should change defaults and traditions. It's basically a pimped monobook which doesn't look as functional and has been created and pushed for default implementation without the need being as great as implied by supporters. Greg Tyler ^{(t • c)} 23:12, 6 August 2009 (UTC)

I'm assuming "Vector" is the same as the beta. So, how does one, using the beta, "unwatch" a page, please? - Denimadept (talk) 23:38, 6 August 2009 (UTC)

This is a terrible idea, and it's being thrown around by a banned editor who uses socks to bounce around ideas[6]. This guy was just trolling by proposing a preposterous idea. (P.D.: for why it's a preposterous idea, see Usability testing and how testing is done in small groups before rolling huge changes to the world. This idea makes Jakob Nielsen sad) --Enric Naval (talk) 02:24, 7 August 2009 (UTC) P.D.: actually, after seeing other off-wiki proposals by the person behind the account I think that there is the possibility that he is simply clueless to the point where his good-faith proposals are so terribly misguided that they look like trolling. --Enric Naval (talk) 18:54, 8 August 2009 (UTC)

Toolbar

The new toolbar does not work with the editing gadget and Greasemonkey script wikEd, please see Bug 20134. Cacycle (talk) 19:25, 8 August 2009 (UTC)

The toolbar is a part of Extension:UsabilityInitiative; it isn't a part of the Vector skin or MediaWiki 1.16alpha. Go to the Usability Initiative wiki and report the problem. --Michaeldsuarez (talk) 17:02, 10 August 2009 (UTC)

WP:VECTOR

As it was mentioned above that WM spent several thousand dollars on Vector, and this will become our default skin at some point, I have scribbled out WP:Vector. My thinking is that the project page will be for explaining vector in depth. What issues is it addressing? How is it addressing them? How much did we spend and where? And known bugs. The talk page would be for discussion of Vector errors or usability issues or help or whatever. There is never enough on-wiki documentation of our new software. This way there is no digging through talk pages or other wikis for basic info. Obviously I didn't put much info on that page, because I don't have any info on vector. Please assist in building this page. Thanks. ▫ JohnnyMrNinja 13:51, 7 August 2009 (UTC)

It has to be said, the redesign was not worth $0000s. Vector simply has new icons, a moved search box and more irritating tabs (why have a drop-down box for all the things I regularly use? And how is that not my choice?) En plusse, the fade-y tabs look revolting and footer and navigation boxes flow far too easily into one another. If I hadn't known, I would've thought Monobook to be a more straight forward, improved version of Vector. Greg Tyler ^{(t • c)} 16:47, 7 August 2009 (UTC)

There is a clear difference between noob usability and editor usability. The whole usability initiative was primarily intended for the first set of users, in an attempt to get them to become part of the second group. That this would have some impact on the current editor group was a given fact in the first place. That does not mean you don't have a say. Give feedback. on the place where you were invited to give it. usability wiki. And also, this is step 1, not final station. I'm personally just amused at how much editors are stuck in their patterns. Any form of change except the one they personally approved is BAD. With so many editors, you can't do a thing correct in changing the interface of course. And judging from the fact that some people still use pre-monobook skins because they didn't like the monobook skin, will tell you that there is simply gonna be a large group at the end, that will not be happy with the result. No matter what the endproduct will be. —TheDJ (talk • contribs) 00:34, 8 August 2009 (UTC)

I've been using Vector all day, and I'd have to say that after a few minutes of reorientation I like it. I don't intend to switch back to the old monobook skin, as I think it's a significant improvement. --

Fatuorum

00:40, 8 August 2009 (UTC)

I see no connection between spending any amount of cash and forcing the users and readers to use an inferior replacement.

NVO (talk

) 21:00, 8 August 2009 (UTC)

You have something called preferences, and anyone can use them to select their preferred skin. —TheDJ (talk • contribs) 21:51, 8 August 2009 (UTC)

Well of course I do, but readers "from the streets" don't.

NVO (talk

) 20:53, 9 August 2009 (UTC)

Vector is still in development. And you will (hopefully) be able to customize what menus are open by default. HereToHelp ^{(talk to me)} 11:58, 11 August 2009 (UTC)

It would be great if some of the stats from en.wikichecker.com could be incorporated into the History tab of articles. The key ones would be:

1. total number of edits and editors - to give a perspective of the 'depth' of the article
2. date of first edit (ie age of article) - this and the above can then be combined to form some sort of average edits/day measure.
3. top 10 editors (with either the number of edits or proportion of total) - to give a more sophisticated view of the first statistic
4. edit mix of registered vs anonymous users

I have been using this site to check a number of the articles I watch, and think it would be an incredibly valuable resource for everyone from those who mainly read to those who mainly edit. The best way to expose all this information would be to roll it into Wikipedia officially rather than having an external site do it. Note I am in no way affiliated with wikichecker.com, I just think that the stats it presents are really useful! Cheers Mitsuhirato (talk) 12:14, 10 August 2009 (UTC)

A rather good idea - this one has my support. I did not even know of http://en.wikichecker.com until I read your post! ACEOREVIVED (talk) 20:13, 11 August 2009 (UTC)

The date of the first edit can be found by clicking the "earliest" link and looking at the last entry on the page. EVula // talk // ☯ // 20:21, 11 August 2009 (UTC)

Input is required at Wikipedia talk:WikiProject Scotland#Scotland location to come to a consensus on which map best serves the purpose. Dr. Blofeld ^{White cat} 10:31, 11 August 2009 (UTC)

There's been many recent RFDs on so-called "vanity" redirects (not to single anyone out, but, for example: WT:SANDY -> User talk:SandyGeorgia).

What about allowing users to create shortcut redirects as subpages of the redirect pages "

Example:

WT:U/X -> User talk:Xeno

(I realize my name is already pretty short - this is an example only and I'll delete it if this proposal doesn't carry)

Thoughts? –xeno^talk 17:12, 10 August 2009 (UTC)

It's also possible to turn U: and UT: into name space aliases of User: and User talk: (like WP: currently is an alias of Wikipedia:). You could then register and redirect User:X (U:X), also elimination the possibility for naming conflict. —Ruud 18:47, 10 August 2009 (UTC)

That's another idea, but then there would be a landgrab for short usernames. (Not that there won't be a landgrab for short subpage names, but this is extensible) –xeno^talk 19:12, 10 August 2009 (UTC)

I don't like it. It's quite possible and even likely that we will run into naming conflicts in the future, in which case the shortcut doesn't help any. Further, if a user wants a different link to his page, he should have himself renamed. Each user is an individual, and it would be prudent to leave that the way it is. --Izno (talk) 18:56, 10 August 2009 (UTC)

Agreed. You'd get into the same sort of Trademark issue that exists now with urls. What if X! wants U:X - does he get it or does Xeno get first rights? The logical conclusion is, as you point out, where we are right now. ~ Amory (user • talk • contribs) 00:48, 11 August 2009 (UTC)

Well, he could use WP:K/X. But it's first-come-first-serve. I don't see a particularly compelling reason not to allow users to hijack the subspace of these one letter redirects in WP space. –xeno^talk 15:03, 11 August 2009 (UTC)

Please see

We could say that anyone can create U:xx redirects to pages they use a lot, just to save them typing in the search box, but that wouldn't give them any permanent right to the redirect (someone else might reuse it for something else at some point). The trouble with programmed aliases is that you make it impossible to create an article beginning with that alias should the need arise. (We ought to have personalized redirects that work only for you, but that would require software development...)--Kotniski (talk) 09:11, 11 August 2009 (UTC)

That would be a pseudo namespace in the mainspace. I would oppose that. –xeno^talk 15:03, 11 August 2009 (UTC)

The pseudo-namespaces we have are in the mainspace (P:, T:, CAT:,etc.) Why would this be any different? Or do you oppose all such uses?--Kotniski (talk) 08:51, 12 August 2009 (UTC)

I'm not a fan of them. I don't think they should be extended to user pages. –xeno^talk 13:34, 12 August 2009 (UTC)

I'm not really seeing much tangible benefit to this proposal. Most user names are relatively short and easy to type as it is, and I don't see how there is any need for a shorthand method of typing them. Shortcut redirects also exist to help users get to policy/guideline pages whose titles may not be as memorable as their shortcuts; again, this should not be an issue for usernames. It strikes me as little more than a vanity redirect that has the potential to run into

Some folks find them useful. Some people do have longer names to type, e.g. User:Moonriddengirl (luckily she has User:MRG as a handy doppel and redirect). The example above, WT:SANDY was made by someone-other-than Sandy as a shortcut because SandyGeorgia is a valuable and oft-used resource. I just think that allowing users to use the subspace of one-letter redirects wouldn't really be that bad of an idea. I'm sure not many would even bother, but it would keep it out of WP: space proper. –xeno^talk 13:38, 12 August 2009 (UTC)

Currently there are only 9 pages that link to WT:SANDY, including this one and the one at RFD. I do not believe they are really that useful. Userpages are, by their very nature, easy to remember; the only argument in favor of this proposal is that it makes for a little less typing. Sure, there are a few examples of long usernames out there, but even then, the benefit is minimal at best in shaving off half a dozen letters. If a user's name is so unweildy that they feel the need to register a shortcut to it, perhaps they should have just used a less unweildy name to begin with. Shereth 14:11, 12 August 2009 (UTC)

You may not find them useful, but what about the folks who do?... those that type them into the search box regularly to navigate to the desired page? (See the pageview statistics for WT:SANDY, it's not huge, but it's being used on a semi-regular basis). What harm would they cause? –xeno^talk 16:36, 12 August 2009 (UTC)

To be honest I'm somewhat ambivalent toward the idea. I don't think it's a harmful proposal, but I also do not believe it to be a useful proposal. I don't believe it to be worth implementing but at the same time I'm not going to pitch a fit if it is. Shereth 16:40, 12 August 2009 (UTC)

It requires no implementation other than the understanding that the subpages of single-letter redirects are fair game for users to use as redirects. The benefit is that they stop using WP and WT pages for this and saves time at RFD. –xeno^talk 16:42, 12 August 2009 (UTC)

(ec) Why not just register a doppelganger sockpuppet (clearly identified as such) with a short username - if you absolutely must have one. There's not that much difference between typing U:FOO and User:FOO. User:FOO can then contain a redirect to User:FooSmithJonesIII. Yes, there's still the 'land grab' problem, but that would exist with any designated namespace or subpage holding area for these redirects. TenOfAllTrades(talk) 13:42, 12 August 2009 (UTC)

Doppelgangers would work if we could have a namespace-redirect (not pseudo) from UT to User talk:. Otherwise WT:?/ still saves six characters over User talk:. It's also extensible, there's 26 letters and ten single numbers (not to mention symbols). –xeno^talk 13:45, 12 August 2009 (UTC)

Is there any way in which we could make link piping such as [[Link, to be piped|]] display itself as [[Link, to be piped|Link]] in references? Currently, the only way that we can pipe a link inside ref tags is to type the text to be displayed; if we simply put the pipe and then the brackets, it displays as if it were inside nowiki tags. For example, search for the words "Hopewell (Union Bridge, Maryland)" and "Mount Airy Historic District (Mount Airy, Maryland)" in the references section of this version of National Register of Historic Places listings in Maryland. Isn't there some way that we could make it work like in normal text, where all text after the first comma or first parenthesis is hidden? Nyttend (talk) 14:19, 12 August 2009 (UTC)

This is bugzilla:2700. Algebraist 15:14, 12 August 2009 (UTC)

Thanks. Nyttend (talk) 16:02, 12 August 2009 (UTC)

I'd like to propose that pages containing or pertaining to sexual content be added to a Category:Sexual Content. This would make it a lot easier for filters. (I am by no means in favor of any kind of censorship). Any opinions on this? Support? Oppose? I'd like to hear what you think.Smallman12q (talk) 16:02, 10 August 2009 (UTC)

I think a hidden category "Pages containing images which may be considered objectionable" that allowed opt-in scripts to suppress image display might be worthwhile. –xeno^talk 16:05, 10 August 2009 (UTC)

A possibility would be PICS, but that hasn't been widely adopted yet.—RJH (talk) 17:27, 10 August 2009 (UTC)

We should not even consider this. Open any encyclopedia and you may see "sexual content", do we put disclaimers on those? What next, Category:Content that may be offensive to (name of some group - Muslims, Christians, Scientologists etc) - no a thoroughly bad idea. – ukexpat (talk) 17:39, 10 August 2009 (UTC)

WP:NOTCENSORED. It should be pretty obvious that navgiating to risque topics such as Anal sex is likely to result in the display of risque images, and users can avoid these topics when at work/school/whatever. Otherwise, the old mantra "Wikipedia is not censored" applies. Shereth

17:40, 10 August 2009 (UTC)

"Wikipedia is not censored" translates pretty easily into "Wikipedia is inflexible." Bus stop (talk) 17:45, 10 August 2009 (UTC)

Providing options is not censorship. This would be strictly opt-in. The pages would be tagged with a hidden category or template and scripts would act on it. –xeno^talk 17:46, 10 August 2009 (UTC)

Exactly. There's no need for a knee-jerk anti-censorship reaction here. I don't want to see mandatory censorship, but I would like the option of avoiding articles that are not "office friendly". This can occur, for example, when selecting a random article for a little lunch-time browse/ce.—RJH (talk) 17:45, 11 August 2009 (UTC)

reject early, reject often - rejected every time it comes up for the reasons mentioned above. I might consider it if we also add a category that is called Content that may be offensive to people who are afraid of clowns to all clown related articles. --Cameron Scott (talk) 17:48, 10 August 2009 (UTC)

Could you elucidate what reasons were mentioned above? I support WP:NOTCENSORED but haven't seen any reasons to reject an optional way to not display certain material. –xeno^talk 17:53, 10 August 2009 (UTC)

OK then, who decides what constitutes "sexual content"? That's the problem with any censorship, quasi-censorship, or opt-in based on content - it's subjective and will just lead to more, endless, Wikidrama. So, bad idea. – ukexpat (talk) 17:51, 10 August 2009 (UTC)

This is why I suggested "Pages containing images which may be considered objectionable" and I'm sure it could be broadly construed. Users opting in would have to accept that images may be suppressed that they might not themselves find objectionable. Some things that might be hidden: Images containing nudity, depictions of sex, depictions of Muhammad, Rorschach inkblots, etc. –xeno^talk 17:53, 10 August 2009 (UTC)

Same problem, who decides? Then there will be endless edit wars adding and deleting the category. Just seems unworkable to me. – ukexpat (talk) 18:01, 10 August 2009 (UTC)

It's opt-in only so there shouldn't be any debate over it. –xeno^talk 18:23, 10 August 2009 (UTC)

Of course there will be - there are debates over the most excruciating minutiae on Wikipedia. This will be a fruitful area for debate. – ukexpat (talk) 18:25, 10 August 2009 (UTC)

I resent your position that this undebatable position will be debatable. I ask you to strike it at once, else we will have to engage in further debate. –xeno^talk 20:32, 10 August 2009 (UTC)

We could classify it, eg Content likely to be objectionable to small-town Americans, content likely to be objectionable to city-dwelling Americans, content likely to be objectionable to the Swiss, Content likely to be objectionable to nuns, etc, to account for the vast variations in what people find objectionable. DuncanHill (talk) 17:54, 10 August 2009 (UTC)

Perhaps, rather than having this "endorsed" in a sense, by the community as a whole, a userscript could be created with a community-built database of material that will be suppressed. –xeno^talk 17:56, 10 August 2009 (UTC)

We'll need "material that may be considered objectionable by some psychiatrists but not by others" for the inkblots. All sexual content? Stamens and pistils? sorry, lost the sigDuncanHill (talk) 18:07, 10 August 2009 (UTC)

(ec, reply to Xeno) If someone wants to create a userscript that employs a third-party database of "objectionable" images, updates that database on their own, and does not start adding tags on Wikimedia sites itself, then I say more power to them. If the community starts doing this, or even implies an endorsement by allowing an article to be tagged, then we set a bad precedent. Shereth 18:04, 10 August 2009 (UTC)

(edit conflict) Reply to Xeno: Now we're getting somewhere. I think the consensus is pretty well-worn that "Categories (metadata) should not be placed in articles if their sole purpose is censorship." So I agree with Shereth's position: a third-party database is fine, whereas no endorsement of solely-censoring categories should be tolerated. But what about the gray area? --

WP:Hornbook

18:20, 10 August 2009 (UTC)

So - just for a moment to attempt to take this suggestion seriously:

• Who would decide what tags were placed on articles?
• What would happen about edit wars on this?
• Who would decide what went into this "community-built database"?
• Would there be a new class of censor bureaucrats?
• What would their qualifications be?
• How would they be appointed?
• Would all of this be in fact a new area for POV editors to waste their time debating the merits of various articles?

Feel free to expand on above. Jezhotwells (talk) 18:06, 10 August 2009 (UTC)

I see that some of the thoughts I have expressed in previous discussions have already been stated. If someone wanted to provide rated lists or scripts of articles and images outside of the Wikipedia environs, then more power to them. ---— Gadget850 (Ed) ^talk 18:15, 10 August 2009 (UTC)

Someone will eventually end up being offended by an article being included in a "Content that may be offensive to X" category. The cycle will never end. hmwitht 18:18, 10 August 2009 (UTC)

Aw, hell, I had a long post all constructed, and then Xeno makes it obsolete by thinking of a better idea. Yes, rather than upset people by inserting hidden categories into articles, anyone who wanted to could create lists of articles that meet a certain criterion, and then scripts could perform an action based on those lists. There would really be no limit, and no disruption for others, if someone actually did create User:Example/Content that may be offensive to people who are afraid of clowns, and tweaked a master script with their own preferences, so they could see the content but not the images. True phobics could choose to not even be able to load an article listed in it.

Of course this would be inefficient if each user created their own lists, but very quickly people would stop re-inventing the wheel, and start using the same lists. Subpages of WP:Filtered content could be set up by any group interested in taking the time to do so, with absolutely no effect on those of us who don't want to filter anything, or those of us who do want to filter some things, but aren't scared of clowns. Or, less optimally but still possible, something similar to User:UBX could be used, and subpages of User:Filtered content could be used to set up lists of files there. Or something. anyway, this, to me, is the solution.

It would be nice if Wikipedia's community allowed this to be done in a semi-organized way, but I imagine a group of determined users could set something like this up by themselves. But I don't see any need to force it to happen off-wiki. This would be a true service to readers, and since that is our core business, we should help to make it as useful as possible. --Floquenbeam (talk) 18:24, 10 August 2009 (UTC)

I can just imagine all of the Muslims who will want to add all images of women's bare faces to be added to this list. Who then was a gentleman? (talk) 20:29, 10 August 2009 (UTC)

Break 1

To address those concerned with censorship, this would be strictly opt-in. Censorship is defined as "the suppression of speech or deletion of communicative material which may be considered objectionable, harmful, sensitive, or inconvenient to the government or media organizations as determined by a censor." In this case, the censor would be the person themselves; essentially self-censorship.

Ideally, I'm hoping something along the lines of Platform for Internet Content Selection can be created. Currently, you can indeed easily write a script to filter based on categories, so all this fuss regarding Category:Content that may be offensive to (name of some group - Muslims, Christians, Scientologists etc) is misguided.

Perhaps some kind of central list that more broadly categorizes content (based on certain criteria) can be designed.

I'm not looking to censor anything. I'm not here to create a legal disclaimer about content. I'm here to create a kind of central opt-in list that will allow users to better control the content they want to see. We have pop-up blockers and ad blockers, and so I'm hoping to make wikipedia more friendly to various people.Smallman12q (talk) 20:46, 10 August 2009 (UTC)

Opt-in vs censorship isn't the problem, the problem is that someone has to categorise, or add other metadata to, the article to enable the option. The decision to add the category is wholly subjective, and subject to abuse and massive edit warring, with ensuing wikidrama, dispute resolution etc, etc. Then other "offended groups" will come along and say "what about our feelings?" and on it goes. – ukexpat (talk) 21:01, 10 August 2009 (UTC)

Mohammed, mid importance would include menstruation and alcohol

, low importance would include pictures of exposed female skin.

This outcome would horrify me, but there's nothing I can do about it.

WP:Hornbook

21:42, 10 August 2009 (UTC)

Of course,

WP:Hornbook

22:03, 10 August 2009 (UTC)

The problem is that, no matter how you look at it, this is censorship. Whether it's opt-in or mandatory, whether it's 3rd party or done by editors, is all immaterial. It's a restriction of rights (yes, I said the R word; did I hear some gasps?). The only thing that this would do would be to drive away people from Wikipedia, including myself, as WP:NPOV became a laughing matter (Neutral Point of View implies there is no censorship - the reader views what they want, and they don't view what they don't want). What is REALLY required is that all articles have explicit enough titles so the user KNOWS when the would rather not read / see something. This also means that all links have text that works similarly to article titles.

An encyclopedia, in print or online, is a fountain of information. Censorship of any kind would restrict the amount of information perceived, and so the status of Wikipedia would quickly go downhill. Tim Sabin (talk) 22:17, 10 August 2009 (UTC)

Are you trying to elicit some type of emotional outrage? A restriction of rights? It would be strictly opt-in, I don't see vegetarians complaining that they are somehow being restricted by an entity other than themselves.

Well instead of physically marking an article, perhaps a central list could be compiled. (Please Note:It could easily be done off wikipedia).Smallman12q (talk) 22:26, 10 August 2009 (UTC)

As I stated before, I really don't care if some third party wants to compile a list of "offensive" images and create a userscript that would filter these out. Users have an awful lot of leeway with userscripts, this is no different. I would be absolutely opposed to any system that physically tags an article/image with categories or any kind of metadata, visible or otherwise. I'm also fairly opposed to any kind of on-wiki project, or any kind of on-wiki list or database of "offensive" images/articles. Just as we should not be facilitating censorship, we should not be facilitating the labeling of images/articles with subjective descriptions such as "offensive". The maintenance of such a list in userspace would be somewhat more palatable and I would not have such a strong objection to it, but the other solutions being suggested are not acceptable. Shereth 22:43, 10 August 2009 (UTC)

Similarly, I have a friend who is Sudanese and Muslim and actively supporting Lubna al-Hussein, a Sudanese woman facing ten lashes for wearing trousers in public. I imagine she would be gravely offended by any sort of list or category that purports to represent Muslims, Sudanese, or Sudanese Muslims and prevents the viewing of images of women wearing trousers. Any sort of listing that purports to represent a group of individuals who are not actually involved in choosing the contents of that list is an instrument of control, not choice. People are fine to do whatever they want off wiki to shape their and others' viewing experience, but let's not pretend that it's an apolitical act. - BanyanTree 07:25, 11 August 2009 (UTC)

Here, here! Tim Sabin (talk) 11:59, 11 August 2009 (UTC)

Hear, hear, I'll second that! – ukexpat (talk) 15:04, 11 August 2009 (UTC)

What Shereth has said, in general. Count me opposed to anything of this sort. Exploding Boy (talk) 17:49, 11 August 2009 (UTC)

This is a persistent proposal; just wanted to see if anything had changed. So far though, it seems as though most people are opposed.Smallman12q (talk) 15:27, 12 August 2009 (UTC)

No, no, no, no. Although this proposal is nobly attempting to make this metadata have minimal visual impact, the trouble is that standards for what constitutes objectionable sexual content are extremely subjective, and would be the subject of pointless debate. I may not object to a hidden category for "articles containing sexual images", since this is fairly objective, but I would seriously question the misdirected goals of any filtering software that blocks all articles in this category (contrary to popular belief, children do need to learn about sex). Dcoetzee 20:12, 12 August 2009 (UTC)

I don't think "sexual image" is an objective criterion at all. Is File:Closeup of female breast.jpg "sexual"? Or File:Gynecomastia 001.jpg? File:Namibie Himba 0716a.jpg? File:Invertednipple.jpg? What about File:Rocky Horror 2.JPG? File:Pamela_Anderson_2.jpg? --Stephan Schulz (talk) 23:43, 12 August 2009 (UTC)

Moved discussion to Village pump (proposals) as a more relevant forum. --Cybercobra (talk) 22:46, 12 August 2009 (UTC)

Hey folks! Am I the only one interested in transferring quality referenced articles from German wikipedia into English? The project needs people who understand a bit of German and see the potential in translating quality articles from German wikipedia. I need your help guys! Dr. Blofeld ^{White cat} 19:16, 5 August 2009 (UTC)

Hi there. Well, the page was only created about 3 or 4 days ago. *g* Clicking through to your talkpage we learn you held off from posting to the wider audience here for a week, in order to sensibly focus discussion initially. I don't speak German so won't be able to participate, but as there're several other WikiProject Intertranswiki/$lang pages created around the same time my curiousity is piqued ...

You used the phrase "transferring quality referenced articles", Dr. Blofeld. Please could you say below whether the scope of these Intertranswiki projects is restricted to quality in terms of assessed (FA/GA-equivalents) articles or manually selected well-developed longer articles; additionally, could you clarify if stubs (a sometimes ambiguous term, so take it to mean <3–4 sentences, perhaps unref'd), be they geostubs or others, are definitively excluded from these Intertranswiki projects?

As you might know, there was a recent issue of 4,000 unreferenced German politician substub articles created, involving semi-automated tools. Of course that's since been taken care of, and we don't need to revisit specifics; ultimately a mass-deletion was used to deal with the most part. I understand it wasn't you who created them, as well as that the editor had done so in good faith, with blp management aspects seen only later. We've no suggestion biography articles are involved in this new initiative. Let me explain why I've brought it up: It's purely for illustrating considerations involved in large translation initiatives, often involving topics which may stay short for a long time, and even for which scarce English-language sources may exist for easy expansion by those who aren't fluent in the respective languages. I also appreciate your positive effort with this initiative is so as to approach content transfer *proactively*, allowing things to go smoothly.

Will article intertranswikifys be checked by an editor who has mother tongue fluency or is a native speaker, in the respective language? Additionally, do machine translations play a part in the intertranswikifying?

Last, my understanding is that while there's long been a category system to hold articles tagged with language expansion templates, no active accompanying WikiProject existed to collaborate and direct efforts. Looking at a couple of the categories, there're many tagged articles; I've tagged some myself in the past that remain unexpanded. In excess of 750 German and 7,000 French articles, for example, according to the cat pages. Is initial clearing of those by Intertranswiki projects planned, or is broader concentration on articles in foreign language Wikipedias without en-wp counterparts planned? Sorry, that's quite a few questions! Thanks –Whitehorse1 21:09, 5 August 2009 (UTC)

I checked a few candidates from history... these are start-class articles with only referenced to printed books (some from 19th century) - no page numbers, no inline citations. Should I trust these texts, knowing that the very existence of some 12th century prince is debated? If anyone likes to improve

NVO (talk

) 05:06, 6 August 2009 (UTC)

NVO, thank you. While I don't speak German, I have read many references to de-wp here; my understanding is that many things're done differently there and in some cases better. I looked at the en-wp article you wikilinked. It's not even start-class; stub-class is more accurate. Its entire content is "Burgruine Petersberg is a castle in Carinthia, Austria." with zero references. Worse, the de-wp original has the titles listed under References marked "(formal falsche ISBN)", which an online translation tool reports is "(ISBN formally wrong)"; on checking the ISBNs, there is no matching title for one, with the other not even valid syntax for an ISBN. The en-wp article has a See also section wikilinking "List of castles in Austria". I clicked on 3 random list entries:

Burg Oberkapfenberg

Burg Oberkapfenberg is a castle in Styria, Austria. (de-wp: a 1-line & 2-paragraph unreferenced stub)

Burg Obervoitsberg

Burg Obervoitsberg is a castle in Styria, Austria. (de-wp: link to corresponding de-wp article leads to 'page does not exist')

Ruine Burg Schachenstein

Burg Schachenstein is a castle in Styria, Austria. (de-wp: a 1-line & 1-(small) paragraph unreferenced stub)

This is concerning. I am unable to consider any of these "quality referenced articles" as Dr. Blofeld referred to. Those I examined comprise broken links, perhaps an error during creating left unchecked, and sparse content either wholly unreferenced or invalidly (non-verifiably) referenced on the de-wp original. Burg, apparently glosses the English word castle. Burgruine Petersberg, the article you linked, was created on de-wp November, 2007, while Burg Oberkapfenberg was created March, 2004. It is difficult to be confident in the likelihood of their development or improvement on en-wp, when they have remained in that form for some years on their native-wp. At present, I do not know if the article you linked and the related articles I listed above derive from the Intertranswiki/German project Dr. Blofeld describes. It seems best for me to remain with good faith by making no assumptions. My hope is that Dr. Blofeld will respond to the questions I posted in reply above, so everybody can better understand the initiative. –Whitehorse1 20:31, 12 August 2009 (UTC)

Uhhh. This is why I established a wikiproject To improve the quality of transwikying to avoid the creation of weak stubs. Please read the main project page 'carefully before jumping to conclusions. Dr. Blofeld ^{White cat} 16:50, 13 August 2009 (UTC)

As I said when replying to your similarly-worded post on my talkpage, when the questions were posted your new project page (permalink) had very little information. For whatever reason, it appears you have taken my interest in your initiative and my desire for its success the wrong way. On that basis, perhaps it is better to simply move on from this thread. I wish you every success with your WikiProject(s), Dr. Blofeld. Thank you. –Whitehorse1 17:34, 13 August 2009 (UTC)

I just dropped my keyboard and rolled back this page. I have seen a lot of people accidentally hit the rollback button on their watchlists, some without even noticing. How would people feel about a little JavaScript popup that asks if you yes or no if you want to actually roll something back? ▫ JohnnyMrNinja 04:40, 6 August 2009 (UTC)

I would hate it; rollback is there for one-click rolling back of edits. If you accidentally rollback an edit, it's a sign that you need to be more careful, not that the tool needs to be changed. (and I say that as someone that has accidentally done so) EVula // talk // ☯ // 04:45, 6 August 2009 (UTC)

Perchance a gadget? Would it be possible to give a gadget to just rollbackers? ▫ JohnnyMrNinja 04:56, 6 August 2009 (UTC)

I agree with EVula about the "

Rollbackers will have a choice to enable a popup if they wish to. Harlem675

14:01, 6 August 2009 (UTC)

I wouldn't be opposed to a gadget, but it would either be in the way (turned on when you don't want it to) or not be there when you want it to be (turned off when you need it). Since we're talking about accidents, it's hard to predict when you need it (pretty much whenever you're not actively rolling back someone's edits). Perhaps an initial pop-up that only comes up a single time every two minutes (ie: it asks on the first rolledback edit, and assumes you still want to for all subsequent rollbacks for a short period). That'd strike a fair balance between preventing one-off mistaken rollbacks, but not reduce the effectiveness of the tool. EVula // talk // ☯ // 16:19, 6 August 2009 (UTC)

That sounds like a good idea to me. Harlem675 17:58, 6 August 2009 (UTC)

You could also consider disabling rollback links in your watchlist, recentchanges, etc., to limit accidental use. There's a thread in the archives on how to do this. –xeno^talk 18:03, 6 August 2009 (UTC)

I threw together a little script in JS that adds a confirmation popup when you click "rollback". You can employ it by adding importScript('User:Greg_Tyler/rollbackprompt.js'); to your monobook.js page. Greg Tyler ^{(t • c)} 16:40, 7 August 2009 (UTC)

The whole point of the rollback link is to give one-click access to the feature; a mandatory confirmation click would largely be a waste of time. I don't mind the idea of having an optional confirmation (for the users who are either still getting used to the button, or who are accident prone) either integrated into Mediawiki (if the devs have spare time) or as a plugin/script (per Greg Tyler, above).

A relatively recent change that I very much approve of was the addition of the 'diff' to the 'rollback successful' screen. It makes it much easier to detect when you've rolled back further than you expected, or undone something that you shouldn't have. An ideal enhancement to that screen would be one more link: Rollback this change, or similar wording. If you did accidentally click rollback, you would have the immediate opportunity to undo your action in a single click, hopefully before anyone else notices. :D Thoughts on that? TenOfAllTrades(talk) 14:02, 12 August 2009 (UTC)

I like it! –xeno^talk 14:08, 12 August 2009 (UTC)

I absolutely recommend adding the following line to your monobook.js:

importScript('User:Ilmari_Karonen/rollbacksummary.js');

As long as JavaScript is activated (important point! initially I got bitten several times when it wasn't), it opens a popup where you can enter a custom edit summary. If you just enter return or click OK, you get the default summary. If you click Cancel, the rollback is cancelled.

This function allows the use of rollback for non-vandalism reverts, but you need to be verify that you really want to revert all consecutive edits by the last editor. Hans Adler 17:11, 13 August 2009 (UTC)

Please do not laugh at this proposal - this is only a suggestion. Today (August 6 2009), when looking at the "Deaths in 2009" category, I saw reference to this Wikipedia article:

http://en.wikipedia.org/wiki/Sam_(koala)

I saw that earlier today, this had the tag "This article is about a person who has recently died" but this has now been removed - and rightly so, I say, since Sam was a koala, not a person. However, how about introducing a tag which says "This article is about an animal that has recently died?" Wikipedia does list recent deaths of notable non-human animals, so perhaps there should be a tag for recent deaths for them, as there is for human beings who recently entered the pearly gates. ACEOREVIVED (talk) 19:40, 6 August 2009 (UTC)

My apologies; that did make me laugh. But it sounds do-able. --A Knight Who Says Ni (talk) 21:17, 6 August 2009 (UTC)

{{Recent death}} could add a species parameter. There are also notable trees and some of them are getting old... PrimeHunter (talk) 04:20, 7 August 2009 (UTC)

Better to add |alt= parameter, which will replace the word "person" if defined. Ruslik_Zero 19:04, 7 August 2009 (UTC)

Well, many thanks to the Wikipedian who operates under the uesrname "Canadian Paul" - there is now a category called "2009 Animal Deaths"! Perhaps this Wikipedian saw this discussion, or maybe this was just another Wikipedian thinking likewise. This could be the beginning of the type of thing I had in mind. ACEOREVIVED (talk) 20:38, 14 August 2009 (UTC)

Imho it's unlucky that the first sentence of an article often contains so much clutter: synonyms, pronunciation, etymology, etc. I feel the beginning, the article's most prominent place, is being wasted in this way.

An example is the

The sentence "The Holocaust is the term generally used ..." is ripped apart, interrupted with several lines that do not help me understand what the Holocaust is. Some other bad examples would be Chernobyl, Uruk, or China.

My proposal is a template to put linguistic information above the main text. It would be similar to the disambig templates. Example:

The wiki markup would look something like this. I derived it from the markup on the Holocaust page.

How the template would exactly work is to be determined. People who know how to write templates: please weigh in.

Notes

• The template would be used for:
  • "Word origin:"
  • "Also known as:"
  • "Pronunciation:"
  • Native names, example: the article "Germany" would have "German name: Deutschland"
  • "Transliteration:"
  • Anything else?
• Is linkifying the language justified? A link from let's say "China" to "Chinese language" makes real sense, but a link from "Holocaust" to "Latin language" seems very far-fetched. Probably we should drop these links to reduce visual clutter.
• The template would indent its text like the disambig templates
• I really think a smaller font size (<small>) is appropriate. It identifies the information as secondary, so that you can easily skip over it.
• The template would have to accept that it can contain other templates ({lang|yi|...}). Is template nesting even techically possible?
• Note that above for "Shoah", I made up a {{lingu-inline}}

I hope you like the idea. 84.130.125.27 (talk) 03:12, 13 August 2009 (UTC)

The relevant part of the Manual of Style appears to be

MOS:BOLDTITLE. The examples given there do not substantially detract from comprehensibility. For subjects which do have etymology and several synonyms, such as this, it might be easier to move the etymology into a separate sentence, paragraph or even section, depending on its complexity. This does not require special templates. The Holocaust article has a separate section on "Etymology and use of the term", so it would appear that the etymology could be dropped from the lede. However, I'm only following your lead of considering Holocaust as an example; please consider raising the matter on the talk page of that article before making changes to it.-gadfium

04:49, 13 August 2009 (UTC)

I believe the main problem is that a lot of editors believe that starting with this etymology clutter makes an article look more official/correct/encyclopedic/.... In my opinion the MOS should strongly discourage long or complicated etymologies in the first sentence, and only allow etymologies there if they actually contribute to an understanding of the topic. An etymology box would be an attempt at a practical solution to the problem, but I am not sure that I like it. Some articles already have too many boxes. Hans Adler 09:20, 13 August 2009 (UTC)

An even worse example of clutter is Kyrgyzstan, which starts off like this:

Kyrgyzstan (pronounced

China to the east. The ethnonym "Kyrgyz", after which the country is named, is thought to originally mean either "forty girls" or "forty tribes", presumably referring to the epic hero Manas who, as legend has it, unified forty tribes against the Khitans.^{[citation needed]} The 40-ray sun on the flag of Kyrgyzstan symbolizes the forty tribes of Manas.^[1]

Better than creating a new template, in my opinion, would be moving off the clutter into the infobox. Goodmorningworld (talk) 09:35, 13 August 2009 (UTC)

Technically, infoboxes should not contain information that is not also found elsewhere in the article. Powers ^T 12:37, 13 August 2009 (UTC)

Why not? Goodmorningworld (talk) 16:12, 13 August 2009 (UTC)

Could have sworn I read that somewhere... Powers ^T 17:18, 13 August 2009 (UTC)

I think he meant *moving* the clutter to the box, not copying it. 84.130.98.21 (talk) 18:43, 13 August 2009 (UTC)

What's even worse than the way it shows up when you're reading it, is the clutter when you're trying to edit it, and have to parse through all of the various templates and such to actually find, you know, content. Who then was a gentleman? (talk) 18:18, 13 August 2009 (UTC)

As a little summary, it's clear that not just one guy feels irritated. Right now the options seem to be:

1. Move clutter above main text (template like disambig)
2. Move to info box
3. Move down in main text, e.g. end of section 0

Personally, I think that a new template (#1) may be a clearer signal to editors than just a change in the MOS (#3). From a layout/visual standpoint, I think both #1 and #2 fit very well. 84.130.98.21 (talk) 18:43, 13 August 2009 (UTC)

I guess a fourth option would be a separate small box (distinct from the Information Box) for "Etymology and pronunciation", or whatever applies. However, you'd probably want the type in normal size (or maybe 80%-95%) since small type is a real pain on small screens like mine (Compaq FS7600) for long texts and texts in other alphabets, including the International Phonetic Alphabet, especially with accent marks that are sometimes hard enough to distinguish at normal size (e.g. circumflex from umlaut from tilde from macron).

I agree that, if more than half-a-dozen ordinary words, the parenthetical material can become a real obstacle; the little "click this" loudspeaker icon to hear the word pronounced (on browsers and systems equipped to do this) can add to the clutter, where it might fit naturally into a separate box. —— Shakescene (talk) 04:04, 15 August 2009 (UTC)

Below a page are linked the categories to which it belongs. Clicking on a category name takes one to the category page, which is fine. However, If one clicks on the word "Categories" in front of the category list, one is linked to

I think Category:Contents should be mentioned at the top of Special:Categories. Ruslik_Zero 19:06, 13 August 2009 (UTC)

Wikipedia:FAQ/Categories is another possibility (though as the creator of that page I may be biased).--Kotniski (talk) 07:43, 14 August 2009 (UTC)

No proposal here. Just seems an intuitive place to notify of this. I have made a template series that allows users to track the usage of substituted templates. As far as I know, there was no prior way to do this other than to search for unique text of a template, which was never much use and is now almost impossible since we instituted Google noindexing outside the main namespace. Anyone ever confronted with wanting to track a template that is normally substituted, head on over, create a "z number template" and add it to the syntax of the template you want to track. All the information is on the documentation page link above.--Fuhghettaboutit (talk) 02:48, 14 August 2009 (UTC)

The reason they're substed to begin with is to get rid of the numerous transclusions... why would we add transclusions back in? -_- --Izno (talk) 05:36, 14 August 2009 (UTC)

No. Our reasons for substituting templates has nothing to do with that and numerous templates contain internal transcluding templates (see e.g., {{

^}}). Note that the z number templates call no text or code. --Fuhghettaboutit (talk

) 12:03, 14 August 2009 (UTC)

He's actually right, when the substitute was introduced it was to make it easier on the servers, and avoid unneeded transclusions. This seems like a step backward. --

M^ask?

02:53, 15 August 2009 (UTC)

When a template with code and text is transcluded the server must get that material from the separate page for each template used. As far as I know, since these templates have no code or text to call, they will have no or negligible server load affect on the pages in which they are transcluded. I do not claim to be an expert on server load but it appears that the more text and code a template has to call, the larger the load, as implied at Help:Substitution#Partial substitution. But even if the transclusion does have some more than negligible server load effect, that is neither here nor there. See Wikipedia:Don't worry about performance. So stop worrying about performance. (It irks me that this is what I get instead of anything about usefulness).

Despite that it is entirely irrelevant what the original motivation was for starting substitution, out of curiosity I did some digging. This is apparently the very first page where substitution is described, as written on December 6, 2003, which does not appear to support the notion that its first use had anything to do with server load (we could always ask Tim Starling, and then either you or I would be well within our inalienable rights to cry "nah-nah" at each other, but this is such a sidetrack).--Fuhghettaboutit (talk) 05:03, 15 August 2009 (UTC)

According to WebCite, "[i]n one study published in the journal Science, 13% of Internet references in scholarly articles were inactive after only 27 months." On Wikipedia we can update dead links, but we can't update links where the original page has vanished forever, and sometimes it can take months for someone to notice a link is dead. We also can't rely on archive.org, since it's unpredictable which pages (and which versions of those pages) it will archive. Ideally, Wikipedia should automatically store copies of the webpages it references, at the time that they are referenced, and provide a link to this "archived" version for every reference.

This isn't exactly an urgent matter, since at least in theory all of our web citations ought to include sufficient information to track down the original work if it still exists in some form. Nevertheless it would be really convenient, make fact checking easier, and would help articles be more resistant to the passage of time. I don't believe there's any copyright issue in mirroring exact copies of webpages, since a lot of reputable organisations like archive.org do it, although I'm not sure why this is. Dcoetzee 22:29, 14 August 2009 (UTC)

There was a proposal to automatically have WebCite store copies the contents of URLs in Wikipedia references via a bot. I forget what became of it... --Cybercobra (talk) 22:36, 14 August 2009 (UTC)

Found the bot. --Cybercobra (talk) 22:43, 14 August 2009 (UTC)

Interesting. I think at this point we probably want to run with WebCiteBot. No sense doing ourselves what others are willing and able to do for us. I'll follow up with the author to see if there's anything I can do. Dcoetzee 22:54, 14 August 2009 (UTC)

Yeah, I've also frequently thought of this. It shouldn't be too difficult to write a simple web crawler and have it run on the Toolserver. Disk space might be a bit of a problem, though. —Ruud 22:40, 14 August 2009 (UTC)

There are copy right issues but most of them are somehow swiped away with loop hole for libraries. Anyway I intend to have

Checklinks tool automatically submit links dependent on conditions. The tool already can searches and archive pages, but the service tends to crap out if I run faster than ~1 link minute. — Dispenser

09:07, 15 August 2009 (UTC)

NotAnIP83:149:66:11 (talk) 18:50, 15 August 2009 (UTC)

Wanting to watch the watchmen, are we? --Izno (talk

) 19:03, 15 August 2009 (UTC)

I and other admins already deal at Speedy Patrol with ones unreasonably nominated for deletion there, and the community with those unreasonably nominated for AfD. But in looking at newish articles I certainly see many examples of both over-tagging & biting new editors, or of under-tagging, of merely placing a tag on an article that really needs to go--and if someone seems to be doing this persistently enough to catch my eye I'll give them some advice. . But I cannot see any way or reviewing this systematically without doing the work twice over. There does remain one check--many people do this with the intention of learning the rules and applying for adminship, and people's histories are look at very intensively there. DGG ( talk ) 00:22, 16 August 2009 (UTC)

I think Talk Page is for actual discussions (and sometimes additional information and links), and "Discussion" links should not become blue just because of "Wikiproject" template. Majority of pages have such useless (for readers) talk pages. May be "WikiProject" templates should be either in main article (in collapsed state, for example) or in some dedicated namespace? _Vi (talk) 20:34, 15 August 2009 (UTC)

Note to readers: See its origin,

Reasons not previously discussed:

1. The Ogg format is not catching on, nor will it. (see #3)
2. Creating files in the Ogg format requires tools and computer skills that are unfamiliar to most people and, more importantly, unfamiliar to most audio professionals. (This point added later by CharlesGillingham (talk) 23:04, 14 August 2009 (UTC)).
3. Ogg sounds terrible. The reasons are more subtle than you think. There are two important ones that computer professionals have probably overlooked, but audio professionals (like myself) are aware of:
   1. MP3 sound good because the players make them sound good. Billions of dollars of effort has gone into modern MP3 players, including the ones in your computer. They are specifically designed to make MP3's sound good. When the MP3 format first came out, professionals shunned it, because it sounded like crap. Ten years later it sounded great. What changed? The players. There is no equivalent effort to make Ogg files sound good.
   2. Audio professionals (such as recording artists, like myself) deliberately try to make their products sound good on mp3. So any file that has passed through the hands of audio professional is going to sound best on MP3, AIFF and WAV. These are the formats that professional software products export (or "bounce") to. They are the only formats that we have complete control of. These are the only formats we can make sound good. You need to let us use
      vinyl
      was: it sounds good because we know how to make it sound good.

Reasons already discussed:

1. Everybody can hear it.
   1. On your mobile
   2. At the elementary school library
   3. At the airport lounge computer
   4. At a computer owned by someone over thirty by someone over thirty who isn't a computer professional.
2. Anybody can record it.
   1. On your mobile.
   2. Etc., you get the picture.
3. MP3 players (in the form of iTunes or WMP) are free.
4. MP3 represents "free music" to billions of people. If you want to make a political statement, the phrase "MP3" says "rip, mix, burn". (What burned is the
   music industry
   .) "Ogg" says "I spend eight hours a day in front of a computer and I have no clue what the weather is outside."
5. There is no way I'm downloading shareware on to my work computer without a condom. It could screw up my audio driver or worse. (ProTools gets sick very easily.)
6. I think it's arrogant and insulting to assume that we are all as comfortable dealing with oddball file conversions as computer professionals are.
7. I think it's arrogant and obnoxious to make Wikipedia worse in order to prove a moot point. MP3 won. Ogg lost. Get over it. The music industry is going down in flames either way. It's over.

Do you want to have professional sounding audio on Wikipedia? Of course we do. Then, please, allow me upload this MP3 file (I just spent two hours recording and mixing). ---- CharlesGillingham (talk) 13:08, 12 August 2009 (UTC)

The only reason MP3 is not used, is due to patent issues. Thomson and Fraunhofer hold important patents on this technology that will not expire in the US till at least 2012, and there are other patents, that will expire at a later time. Though perhaps these "other patents" are invalid, the Foundation will probably not be able to afford proving that in court. Thus using MP3 is either VERY expensive, or if you don't pay, will become even more expensive in a court. We want our information to be free, so that not only we, but everybody can use it, and that plan includes free storage formats. At the moment Ogg is one of the few codecs that does this. Also a grant has been received that will be put to use towards improving upload, playback and online editing of these materials. —TheDJ (talk • contribs) 13:27, 12 August 2009 (UTC)

I've just read that MP4A, or AAC has no patent issues. How about AAC? Does IE play AACs? I know that Safari does. ---- CharlesGillingham (talk) 14:49, 12 August 2009 (UTC)

This is not entirely true. Distribution of content is free, but encoders and decoders are not. So less expensive, but still expensive (with editing and conversion being introduced into the website this year). —TheDJ (talk • contribs) 15:22, 12 August 2009 (UTC)

Maybe I'm being dense here, but doesn't the browser decode it? Wikimedia wouldn't have to write a decoder, would they? If not, then there's no exposure; we're not decoding it, we're distributing it. ---- CharlesGillingham (talk) 15:56, 12 August 2009 (UTC)

We want the information we provide - including our media files - to be usable by anyone. A patent-burdened audio format may require some people in some countries or areas to lack a freely (beer & thought) tool to be able to decode it. Thus, we need to provide the media in a free format that does not have that burden. --MASEM (t) 16:06, 12 August 2009 (UTC)

Okay, I get it. I didn't realize that there were legal issues. Still I argue Ogg is monumentally inconvenient. ---- CharlesGillingham (talk) 06:23, 14 August 2009 (UTC)

That, and the fact that the large majority of complete music files on the site don't exactly have good sound quality in the first place. With sound samples, sound quality is irrelevant. That said, being able to post without transcoding anything (which I imagine most things are) would certainly be a very good thing. Though I have to wonder why any "professional" would actually use Mp3 as the master format. That would be pretty damn stupid. ♫ Melodia Chaconne ♫ (talk) 14:18, 12 August 2009 (UTC)

(1) A bad sample played through a better player sounds better. (2) We agree that easier is better. (3) MP3 isn't the "master format". MP3 is a format that professional tools will produce. ---- CharlesGillingham (talk) 14:49, 12 August 2009 (UTC)

A professional tool will never use MP3, because it is rather

lossless codec. The goal however is that we look towards the essence. Freedom is good. If freedom means that the tools are too complicated, then we have to improve the tools, because that is where the problem is. This is part of what will be taken on this year. —TheDJ (talk • contribs

) 15:22, 12 August 2009 (UTC)

Read the previous. Professional tools will produce MP3s and AACs on request. They don't produce Ogg.---- CharlesGillingham (talk) 15:44, 12 August 2009 (UTC)

Except that it's trivially easy to convert any lossless file to ogg. Yeah maybe it's one extra step, but it's not as if making ogg files is in any way difficult. One other thing -- at the least, they are VERY common in independent computer games, probably for the same reason that WP uses them, though I do believe (I could be wrong), they may be useful for performance issues as well. So while they may not be propagated in the matter of general listening (and how many people actually DL stuff from WP to put on a hardware player?), they certainly aren't the desert wasteland format you claim. ♫ Melodia Chaconne ♫ (talk) 16:15, 12 August 2009 (UTC)

(1) Trivial for whom? As I said, some of us don't like shareware and have had bad experiences with it in the past. (2) The hardware I discussed above is the D/A converter in every personal computer. ---- CharlesGillingham (talk) 06:23, 14 August 2009 (UTC)

There are a lot of open source (note the difference with shareware) converters available. Unlike commercial converters they usually require no installation and device drivers, have no reason to install ad- or spyware on your computer and therefore will have little chance to damage your computer or software configuration. Unjustified technophobia on the uploader's end would probably be a very bad reason to start accepting non-free audio formats on Wikipedia. —Ruud 20:53, 14 August 2009 (UTC)

It's not technophobia, if you don't make a distinction between shareware and open source software, or if you don't like to mix-and-match software from various sources on one machine. I don't have any Microsoft software on my studio computer either. I just can't afford any kind of conflicts. My work computers are mission critical, and I don't have the expertise or the time to fix any problems that might come up. That's not technophobia. That's prudence.

More to the point, it's not technophobia that makes it difficult for the average person to create an .ogg file on the Mac. The "recommended" tool to change .WAV files into .OGG files on the mac is a linux commandline utility! This requires the user to go "under the hood" by opening the "terminal" application and then negotiate the

Bash shell

. The bash shell is hard to use the first time: it doesn't allow cut and paste, you have to name each file from the root directory, (or use "~" or "." characters) and, if you're filename contains blanks (which it usually does on a Mac), you have to know about the escape character "\" and what it does. All of this would require the average audio professional to have to study a bash manual searching for a clue as to what to do. Is this hard because the user is a technophobe? No. It's hard because we're all not computer professionals. Some have chosen other careers, that don't require knowledge of the bash shell. Assuming that everybody who doesn't know how to use open source software in the bash shell is a technophobe is, frankly, insulting. I'm sorry, no offense, but it is. It's like saying that everyone who doesn't change their own brake fluid is a technophobe. It's just not our job. We hire people to do that sort of thing.

To sum up: Wikipedia's "recommended" method of uploading audio on the mac (the computer used by the vast majority of audio professionals) requires users to know the

bash shell. This excludes the vast majority of potential contributors from participating. Computer professionals who claim this situation is "okay" are (If you'll allow me a sporting reply to your accusation of "technophobia") elitist and out of touch with reality. ;) ---- CharlesGillingham (talk

) 05:13, 15 August 2009 (UTC)

<Look, maybe I shouldn't have mentioned pro audio because it just seems to have confused you all. My point was supposed to be this Wikipedia should conform to widely used standards because the network effect is very powerful. When something is popular, everyone works together to make it better and more useful. In the case of audio file formats, the effect is that every aspect of digital audio, from the studio to the D/A converter in your computer, is designed with MP3, AAC, WAV and AIFF in mind. This is just one more way that the network effect causes the most popular standard to become the best standard. Does that make sense? At any rate, I'm revising my proposal now that I understand what the actual issue is. See the next section. ---- CharlesGillingham (talk) 06:23, 14 August 2009 (UTC)

Wikipedia is a free content, freely editable encyclopedia accesible free of charge. Wikipedia already does things quite clearly, explicitly and consciously different from the usual standard. So, no, I don't see why it should confirm to widely used standards. In fact given it's goals it should actively fight against vendor lock-in the methods which cause it and allow it to exist. —Ruud 20:40, 14 August 2009 (UTC)

Yes, keeping the encyclopedia free is a core goal of Wikipedia. Unfortunately .Ogg violates the other core goal of Wikipedia: Anyone can edit it. So we need to find a way to have audio files in Wikipedia that satisfies both these goals. Forcing editors to upload .ogg files just doesn't cut it. ---- CharlesGillingham (talk) 06:52, 15 August 2009 (UTC)

By that argument, you could just as easily claim that our requirement here that people write in comprehensible English violates "Anyone can edit", since some people can't manage do that. Or that many of our advanced physics and mathematics articles violate "Anyone can edit" since so many can't even understand the math involved. Anomie⚔ 00:42, 16 August 2009 (UTC)

Okay, fair enough, if you want to be picky. I suppose you're pointing out that Wikipedia's core goal isn't that "anyone can edit", as I said, but that it is "anyone (who has something high quality to contribute) can edit." I still argue that requiring audio be uploaded in the .ogg format prevents "anyone (who has high quality audio to contribute)" from editing, because, on the mac at least, Wikipedia is recommending that users know the

bash shell in order to upload audio. A-ight? Sheesh. ;) ---- CharlesGillingham (talk

) 05:26, 16 August 2009 (UTC)

I think we already support FLAC? —Ruud 20:30, 14 August 2009 (UTC)

Yes, but creating a file in FLAC, like Ogg, requires tools and computer skills that are unfamiliar to most audio professionals. That's my complaint. ---- CharlesGillingham (talk) 22:50, 14 August 2009 (UTC)

Indeed, automatic conversion would be preferable, but unfortunately this feature has not yet been developed. —Ruud 23:15, 14 August 2009 (UTC)

Agreed. (Did you mean to post that on the next thread?) ---- CharlesGillingham (talk) 06:52, 15 August 2009 (UTC)

Still don't have an answer of why we don't allow .WAV or .AIFF. Are there patent issues? Or is it the size that is the problem? ---- CharlesGillingham (talk) 06:52, 15 August 2009 (UTC)

I think in the past the size was the issue, and that even though this may no longer be an issue, currently the playback integration for those files is missing so it now needs some development work. —TheDJ (talk • contribs) 10:57, 15 August 2009 (UTC)

Note that size is much more of a concern for what our visitors must download; storage space on the servers is fairly cheap. Anomie⚔ 00:42, 16 August 2009 (UTC)

On-the-fly AAC conversion

Here's a potentially useful compromise: since AAC can be redistributed without paying licensing fees, why don't we offer an option to automatically convert any OGG file to AAC on-the-fly for playback or download? This would let people who already own AAC tools take advantage of them, while still making OGG available to people who can't afford them. Likewise, we could accept uploads of AAC audio and automatically convert them to OGG on the server side. Dcoetzee 22:48, 14 August 2009 (UTC)

Well, hopefully the grant that DJ mentioned above will cover automatic conversion of AAC, AIF or WAV into and out of Ogg. DJ, do you have a link to a page about this grant? ---- CharlesGillingham (talk) 22:59, 14 August 2009 (UTC)

• mozilla grant towards improvement of the encoders and firefox and mediawiki support of material upload and playback.
• Kaltura sponsors Michael Dale to work on a open source video editing system for Wikipedia
• Google Summer of Code project to improve the playback JAVA plugin cortado.
• new wizard to add and upload media enters testing
• Brianna discussing the new tools part2

So a lot of work, but it's complicated and takes a lot of time and money. Still in the past year a lot of work has been done (even though most has not reached the state of being widely deployed so far). —TheDJ (talk • contribs) 23:39, 14 August 2009 (UTC)

Yes PLEASE anything other than the god-awful OGG. I don't even bother with audio on Wikipedia anymore because OGG is nightmarish. AAC sounds like a good idea, and I for one would willingly convert a half dozen files a day. I think that most other editors with the software to do so would be similarly willing. Cool3 (talk) 05:21, 15 August 2009 (UTC)

Note: since OGG can be a container for FLAC, it would also be handy to have on-the-fly conversion between OGG-FLAC and WAV/AIFF. @Cool3, I'm talking here about automatic conversion being available on every audio file, nothing manual required. Dcoetzee 05:58, 15 August 2009 (UTC)

I was under the impression that the above was to imply that the technology for the automatic conversion wasn't yet quite there? If it is fact available already, then all the better; sounds fantastic to me. Cool3 (talk) 06:05, 15 August 2009 (UTC)

This seems like the best solution: Wikimedia needs to allow editors to upload .WAV or .AIFF files and then convert them (if necessary) into .OGG-FLAC files under the covers. That would satisfy all my complaints. ---- CharlesGillingham (talk) 06:52, 15 August 2009 (UTC)

For anyone who cares there is a Flash Ogg Vorbis software player being developed for fun. — Dispenser 09:32, 15 August 2009 (UTC)

Thanks

Thanks to everyone for helping me to hone my argument. I've entered an enhancement request into bugzilla. See bugzilla 20252. ---- CharlesGillingham (talk) 07:31, 15 August 2009 (UTC)

By the way, I finally did convert my file, using the bash shell and the whole nine yards. I replaced this:

The Wikipedia theme

---

Problems playing this file? See media help.

with this: (watch out, the level is a lot hotter on my version -- turn down your audio if you turned it up to hear the first one).

The Wikipedia theme

(as five second commercial television cue)

---

Problems playing this file? See media help.

(It's supposed to be ironic.) ---- CharlesGillingham (talk) 07:48, 15 August 2009 (UTC)