Wikipedia:Village pump (proposals)/Archive 34

Why not put the links to the reference desk, village pump, etc. in the area below the wikipedia logo? It'd be much easier plus you would not have to scroll thru other stuff to find those links. Just a thought.

I have proposed renaming

• Wikipedia:WikiProject Illustration
• Wikipedia:WikiProject Photography
• Wikipedia:WikiProject Free images

-- John Broughton (♫♫) 14:59, 24 August 2008 (UTC)

The relationship between these is described at

Wikipedia:WikiProject Graphics#WikiProject Graphics lineage

:

WikiProject Graphics

WikiProject Photography

WikiProject Free images

Graphic Lab

WikiProject Illustration

--User:Ceyockey (talk to me) 21:10, 24 August 2008 (UTC)

Don't "Images" count as "Media"? Deamon138 (talk) 22:17, 25 August 2008 (UTC)

(Yes, but, "WP:WikiProject Media" is very ambiguous and already taken, and "WikiProject Images, Video, Sound, Animation, Text, and Assorted Other Media Formats" is too long ;-) -- Quiddity 00:23, 26 August 2008 (UTC)

How about "WikiProject Wikipedia Media" — this clarifies that it is dedicated to media on Wikipedia, not newspapers, magazine, and media in that sense. Although Wikipedia:WikiProject Wikipedia Media looks funny with all that "Wiki–". — Twas Now ( talk • contribs • e-mail ) 02:15, 26 August 2008 (UTC)

This was brought up in the discussion, "Images and media" is simply the way such files are referred to together on WP (see

Wikipedia:Images and media for deletion). I feel this is the most intuitive name for the purpose. ~ JohnnyMrNinja

06:37, 27 August 2008 (UTC)

If an IP address hasn't edited in the past year and is not currently blocked, is there any issue with clearing its talk page? Talk pages can be scary with a lot of tags, especially to new users. The tags are also largely irrelevant as the trouble users have moved on or the IP has changed hands. The history of the talk page and the block log, etc. would still reveal prior bad acts, but is there any issue with a clean slate for anonymous users? --MZMcBride (talk) 05:03, 26 August 2008 (UTC)

I think that's a good idea. There's still the history if you want to reconstruct the past of the IP, but I don't really see any reason for those to be there on a (probably) dynamic IP. Those can be pretty scary if you don't know what they are, and don't understand that they aren't actually meant for you. Celarnor ^{Talk to me} 05:06, 26 August 2008 (UTC)

At least a year ago I ran across the description of a bot that was charged with blanking pages related to IP users ... however, I have been unsuccessful in a rather extensive search for information about this. I think it would not be unreasonable to charge a bot with blanking IP account user pages (except for certain templates, such as {{

WP:BOTREQ. --User:Ceyockey (talk to me

) 01:52, 27 August 2008 (UTC)

I'd agree with making a bot do blank inactive IP talk pages (except for {{

sharedip}} like Ceyockey said). No use in having warnings on there when they aren't even being used by the same person anymore. -- Imperator3733 (talk

) 02:19, 27 August 2008 (UTC)

That's a great idea, but I think that we should not remove templates such as {{

(Messages)

03:36, 27 August 2008 (UTC)

This seems like a decent idea, although it might be an idea for a bot to leave a box or note on the page saying that the pages has been blanked. However, wouldn't removing contrib records violate the whole gnu/gdfl leagal thing where edits have to be attributable?--Jac16888 (talk) 01:18, 28 August 2008 (UTC)

If you spend any time at RfA, you know that 2 or 3 times per week we get a new user who in his/her excitement applies for adminship. These candidates are destined to fail... often after receiving several harsh (bity) opposes. Oftentimes they will leave the project, but even if they don't they have been marked by their eagerness when they applied for the RfA. A few months ago, we started closing RfA's per

Over the past several days, we've been discussing some minor changes at

We also want to add a new reason to speedy delete a page per G7. We want to allow new users (those with fewer than 1000 edits AND 3 months of edit history) to have a "NOTNOW" RfA deleted. We want to make this a standard reason as it isn't fair to a candidate to have a premature RfA haunt them 6 months down the road when/if they reapply for adminship. These RfA's would only be deleted if the user is new and requested it.

Before we made either of these changes, we wanted to open this up for general discussion.---Balloonman ^PoppaBalloon 07:00, 19 August 2008 (UTC)

Smacks of

history revisionism to me, which is not a Good Thing. --MZMcBride (talk

) 07:11, 19 August 2008 (UTC)

We allow people that already, for example by creating new accounts to not be haunted by the mistakes of the past (see

WP:NOTNOW

are met, i.e. to purge a very premature RfA from this user's past to allow them to revisit RfA after gaining experience without fear of opposes based on that premature RfA. Let's face it, adminship sounds like a trophy especially to newcomers and they will more often than not just apply without reading all the stuff about it in the first place. Then they will be bitten and if they are lucky they will withdraw in time or be closed as NOTNOW soon but a stain will remain.

I think it should be possible but very rare: A one time only offer, only valid if the RfA shows very little knowledge of what is expected and if the user is really new. Of course it should not apply for the 2nd RfA, for people active more than 2-3 months, for those who are opposed because their actions speak against them (i.e.

WP:SNOW-closes). But, as mentioned before, we already have mechanisms in place to allow people to wipe a bad thing from their Wikihistory and this would be the same thing to do. SoWhy

07:23, 19 August 2008 (UTC)

Erm...

WP:SOCK#LEGIT is about a prior "negative track record." Running for RfA early is not what that section was intended to cover. This is the wrong solution to a problem. The fact is that the person ran for RfA and failed previously. Rewriting history because people at RfA are using bad logic when voting is just silly. --MZMcBride (talk

) 21:26, 19 August 2008 (UTC)

Not comfortable with this, as it is effectively a new CSD and does not meet items 1-3 of the header at

talk

) 08:35, 19 August 2008 (UTC)

It is objective if the person has been here for less than 3 months or fewer than 1000 edits, and closed as

WP:BITE. Many of these newbies who run instantly for RfA do so because they want to contribute/be productive. Do we punish them for being enthusiastic? By keeping the RfA in their history, it does reflect on them in the future. Right now, people WOULD oppose deleting an RfA because it isn't common practice. I think this is wrong. As for how often it would arise, probably 3-7 times per week. This past week alone: 1234567 I would consider that frequent enough. Notice how some of the comments can be bity, and we are preserving them? Plus, by forcing them to go through MfD compounds the insult. You were just embarrassed via RfA, now let's have you go through MfD to get a clean start? The person was just bitten by applying too early in their wikipedia career. Now, we want to embarrass them again by making them go through MfD to show more people how many people opposed them? I say let them clear off that premature move, usually made in good faith, by getting it deleted without subjecting them to more embarrassment of an MfD. Thus, I believe they do fit the criteria.---Balloonman ^PoppaBalloon

17:17, 19 August 2008 (UTC)

"While the community has not established a minimum set of requirements... With this in mind, requests of users with fewer than 1,000 edits and 3 months experience will almost ever always be closed." Surely that means a minimum set of requirements HAS been established? Deamon138 (talk) 16:28, 19 August 2008 (UTC)

Indeed. Why are we going to hem and haw over this if it is abundantly clear that a set of "minimum standards" is being set? Unless someone can think of a relatively recent case in which a user below the "3 month/1000 edit" threshold has run a successful RfA, let's just stop kidding ourselves, do away with this "NOTNOW" business and say it like it is : a minimum standard now exists, don't bother with the nomination if you don't meet it. Shereth 16:33, 19 August 2008 (UTC)

Hmm, I can think of a couple of examples where this could be possible. For example an editor who contributed often via IPs and when registered started participating in AfDs and suchlike and did great there...but you are correct in theory. I guess a minimum set of requirements could be created with the above proposal with a sentence indicating that

WP:IAR still applies and that there can be exceptions... SoWhy

16:50, 19 August 2008 (UTC)

Naturally, IAR is always in play. The thing that baffles me is why the community seems to try so hard to insist that we still cling to the "no big deal" mantra and insists that we don't have a minimum set of criteria when RfA has proven quite the opposite. It does no one - inexperienced editors thinking of doing a self-nom especially - any good to pretend that criteria do not exist when they very clearly do. For what it is worth, I am personally against the notion of minimum criteria, but I am not so naive as to pretend that the community as a whole agrees with me. Shereth 16:57, 19 August 2008 (UTC)

No, it doesn't mean that a minimum standard has been established, what it does mean is that there is a point where an RfA has no hope of passing. 1000 edits/3 months is so far below most people's expectations that it is unlikely to garner much (if any) support. It does not mean that a person with 1001 edits and 3 months + 1 of history now meets the minimum. What I think is a minimum may be completely different from what others think of as a minimum. Personally, I think you could almost double the number of edits and tenure and still be fairly safe that the candidate at least face stiff opposition (probably fail.) If you word it as a minimum, then people are going to expect to pass when they meet the "minimum." We are trying to put something in there to protect newbies from getting bitten. By the time they have 1000 edits and 3 months of history, they should know enough to be able to determine what the community expects.---Balloonman ^PoppaBalloon 17:17, 19 August 2008 (UTC)

I have no problem with the notion of not setting a "minimum" in the sense that, once you pass it you are good to go - but the statement that the community has not established a minimum set of requirements is not entirely honest. Any wording change should make it abundantly clear that anyone below a certain point is certain to fail and thus should not start a nomination. Shereth 17:55, 19 August 2008 (UTC)

How about There is no formal set of requirements but (...)? SoWhy 18:06, 19 August 2008 (UTC)

Actually, it is honest, there is no established minimum set of requirements. There are individual criteria, that individuals use when evaluating candidates, but there is no official set of requirements. How about: While the community has not established a minimum set of requirements, admins are expected to have experience and familiarity with Wikipedia policies and procedures. With this in mind, requests of users with fewer than 1,000 edits or 3 months experience will be closed as

WP:NOTNOW and should not be started. Before running for adminship, one should be familiar with current expectations, which are much stricter than the 1000 edit/3 month threshold.---Balloonman ^PoppaBalloon

18:17, 19 August 2008 (UTC)

No it isn't honest. How on the one hand can you say, "the community has not established a minimum set of requirements" then on the other hand say, "requests of users with fewer than 1,000 edits or 3 months experience will be closed as

WP:CONSENSUS. When a decision is made, we don't normally vote, we judge on content of arguments/points/comments. Could this not be applied to editors applying to adminship? I mean there could be an editor out there with (say) 900 edits and 2 months experience, but his comments could be filled with the wisdom of a sage. Would admin status be denied to that editor? Deamon138 (talk

) 19:59, 19 August 2008 (UTC)

I agree, completely. It isn't honest - nor does it make much sense - to tell someone "We don't have minimum requirements, but if you don't meet these requirements your nomination will be closed." Either a minimum exists, or it does not. If it does, then it serves no purpose to couch it in duplicitous verbiage. If it does not, then why are we talking about closing nominations that don't meet certain requirements? It seems rather silly. Call a spade a spade - if we're telling people their nom will be closed below certain criteria, we are setting a minimum requirement. Shereth 20:19, 19 August 2008 (UTC)

Think of it this way, what score do you need to make it cut in the PGA? There is not an official score, but I can tell you now that if you golf a 80, you won't make it. How fast do you have to run the 100m to qualify for the olympics? There isn't an official score, but I can tell you that if you run like I do, you don't need to apply. Having a minimum a and trying to protect people from BITE are two different things. That is ultimately what we are trying to do is protect newbies from getting burnt.---Balloonman ^PoppaBalloon 00:14, 20 August 2008 (UTC)

I think there is a differentiation between having a minimum set of requirements and strongly noting that her RfA is likely to fail. The newbie could, if he chose, continue the RfA process. However, with stronger wording he may be more disinclined to not nominate. Lazulilasher (talk) 15:09, 20 August 2008 (UTC)

What are the cases of a "premature RfA haunting a user down the road"? And if at least part of the community disapproves of that sort of thing, it's not right for you to delete evidence of it because you disapprove of their disapproval.--Father Goose (talk) 21:02, 19 August 2008 (UTC)

I won't say who it affected, but I have seen failed RFAs give people the equivalent of nervous breakdowns. bibliomaniac15 21:58, 19 August 2008 (UTC)

Failed RfA's have lead to people leaving the project. Getting bitten has lead people to leaving the project. Ultimately, this is all about BITE. If there is a user a day who applies for adminship prematurely, as there has been this past week, then there needs to be some sort of language to disuade them from doing so. Also, the goal is to protect newbies from BITE. That is what motivated NOTNOW and this movement.---Balloonman ^PoppaBalloon 00:14, 20 August 2008 (UTC)

I'm fine with NOTNOW, but months down the road when someone reapplies for adminship, he or she should not be in any way shape or form a newbie. Not biting newbies is one thing (something I wholly support), but erasing people's newbie mistakes because they might be embarrassing to them months later does not fall under the rubric of

WP:BITE. We all stumble when we first arrive at this place; cluelessness only comes back to haunt you if you never stop being clueless (and such a person will never become an admin anyway).--Father Goose (talk

) 22:30, 20 August 2008 (UTC)

I guess the CSD change is pretty much dead, which I can live with if we can eliminate the root of the problem. Which is premature RfA's.---Balloonman ^PoppaBalloon 00:44, 23 August 2008 (UTC)

Instead of arguing about how we can word the lack of official minimum requirements but still explain that there are unofficial minimum requirements without making them official, why not just create minimum requirements? Like say: 1000 edits and 3 months? Mr.Z-man 22:38, 19 August 2008 (UTC)

Precisely! The hand-wringing about how to introduce minimum requirements without actually calling them such is silly. Shereth 22:50, 19 August 2008 (UTC)

And just what would that minimum be? And how would we reach it? Minimum edit counts/time in service only paint part of the picture and if we set up a threshold, people would expect it to be followed---but there is a great variance as to what people consider to be accepted... I don't think there is any desire to establish numerics such as this. 1000 edits and 3 months is so far below what anybody considers normal that it isn't even funny. We push for much higher, but at that level, the theory is nobody would object that they are unachievable or too high. Again, this is an effort to prevent BITING the newbie.---Balloonman ^PoppaBalloon 00:14, 20 August 2008 (UTC)

If judges of RfAs are currently failing to follow WP:Assume good faith and WP:Please do not bite the newcomers, why would they follow any other policy/guideline about that? Surely if they aren't assuming good faith, and are biting the newcomers, then they are breaking Wikipedia conventions and should be reprimanded. Why do we need anything new to make them stop? Surely the problem is that other admins aren't standing up and criticizing those that do bite the newcomers in RfAs? Deamon138 (talk) 00:26, 20 August 2008 (UTC)

(e/c)Where on earth did I even suggest some limit would be some sort of all encompassing threshold that anyone over it would be likely to pass? I suggested creating an actual limit instead of pussyfooting around it with all that pseudo-unofficial-guideline limit stuff. But I would hope by the time someone gets a thousand or so edits they would realize they need more. 1000 edits and 3 months was what was suggested above, that's why I used it, I could care less what the actual limit is, or if one is established at all, I just can't stand watching people argue over silly semantics like was happening above. I fail to see how removing a new user's RFA because they didn't meet the official limit is any more bitey than removing it because they didn't meet the official unofficial one. The effect would be the same but without all the odd semi-guideline wording. If anything, having an official limit might prevent more new users from starting an RFA than an unofficial one would, as the user would hopefully realize that if its an actual rule, and not just a strong suggestion, people are less likely to make an exception for them. Mr.Z-man 00:29, 20 August 2008 (UTC)

I tend to support the initiative of hardening the wording, as above. Ideally, if the wording is correct, then newbie editors would be disinclined to prematurely nominate themselves. While it is true that we have a de facto set of minimum standards, at this time I think it would be best to implement a stronger recommendation to prospective nominees. Just my opinion, it's been wrong before :) Lazulilasher (talk) 15:01, 20 August 2008 (UTC)

But you aren't in my opinion now ;)---Balloonman ^PoppaBalloon 00:44, 23 August 2008 (UTC)

You are also conflating the notion of "minimum requirements" with a sort of "guaranteed in". Just because there is a minimum requirement does not mean "as long as you pass this level, you are in." What it means is "There is a minimum requirement of at least X edits and Y time on the project. If you don't have at least this much, do not bother with an RfA because it will be closed and removed." Nowhere in that sort of phrase is it implied "If you do have that much, well, welcome to the club!" We're talking about minimum requirements to run for administrator, not be an administrator. Shereth 15:04, 20 August 2008 (UTC)

Arbitrary Break

Ok, looks like the CSD idea failed, but there is interest in the wording change. The question is what wording? Here is my latest proposal: While the community has not established a minimum set of requirements, admins are expected to have experience and familiarity with Wikipedia policies and procedures. With this in mind, candidates with fewer than 1,000 edits and 3 months experience are strongly advised against requesting adminship since requesting adminship takes up the community's time and should only be undertaken by those with a reasonable chance of succeeding; and going through an unsuccessful request for adminship can also be a very distressing experience for the candidate. These RfAs will generally be closed per

Consider wording such as "...are strongly advised against requesting adminship since requesting adminship takes up the community's time and should only be undertaken by those with a reasonable chance of succeeding; and going through an unsuccessful request for adminship can also be a very distressing experience for the candidate. These RfAs will generally be closed per

WP:NOTNOW." I think the correct wording is "requesting adminship" rather than "running", and "RfAs" without apostrophe. ☺ Coppertwig (talk

) 14:18, 23 August 2008 (UTC)

So amended.---Balloonman ^PoppaBalloon 14:28, 23 August 2008 (UTC)

I think you mean that you made the two minor wording/spelling changes I suggested in your above post; I'm not sure whether you've done anything with the substantive changes I suggested above, which involve explicitly stating reasons for not requesting adminship under those circumstances. ☺ Coppertwig (talk) 14:35, 23 August 2008 (UTC)

Noted and adjusted.---Balloonman ^PoppaBalloon 20:58, 28 August 2008 (UTC)

Does hidden text within the body of an article display correctly in all browsers, in printable versions, and in mirrors? Or should we not be using hide templates within the prose section of an article? Should hide templates be confined to places like infoboxes and navigational templates at the bottom of articles, per

In firefox, the section is still hidden even in the "printable version". I haven't tried to print from it yet, but I don't think it would show up without clicking "show". Ottava Rima (talk) 01:35, 23 August 2008 (UTC)

Hidden and collapsed sections will A) not collapse/hide correctly on mirrors that have not copied our CSS/JS, and in browsers that do not support CSS/JS; B) not be handled correctly by screen readers and old browsers, C) look wierd in low-resolution browsers like PDAs and phones. So yes, hide templates should be kept out of the article prose. Happy‑melon 10:37, 23 August 2008 (UTC)

Or, a technical solution that improves how they render in these circumstances should be sought. That may well be preferable, actually. Show/hide functionality is very useful and fixing how it prints/renders is not undoable. Has anyone raised a bugzilla enhancement request yet? ++Lar: t/c 11:56, 28 August 2008 (UTC)

Videos from You Tube should be able to be put into articles. a.) it would be cool b.) it would help expain ideas better, not all things can be shown through writing and pictures. All encyclopedias have pictures and words, why not offer more? Jcfreaknrdfghtr (talk) 20:54, 26 August 2008 (UTC)

this is my cue to invite you to take a look at Category:Articles containing video clips - there are issues with copyright, and non-freely licensed technology (ie. Flash video) over at youtube.. but we've actually got quite a lot of stuff here already.... I've been thinking about starting a wiki-project for those who are into this sort of thing - whaddya reckon? :-) Privatemusings (talk) 21:16, 26 August 2008 (UTC)

There's nothing wrong with Youtube or videos per se, and video can in fact be uploaded just as images are, but we can't link to copyright violations any more than we can use them directly. Unfortunately, many of the videos people would want to link on Youtube are copyright violations. Also, BTW, "it would be cool" isn't a good reason to add videos; unless the video really does explain things better than text and/or static images, it is probably unnecessary. Anomie⚔ 21:53, 26 August 2008 (UTC)

99% of all of the websites we currently reference are non-free, so how would referencing You Tube be any different?

(Messages)

03:24, 27 August 2008 (UTC)

There's a difference between linking to non-free content and embedding it in an article. The first is the point of copyright - that you can't copy the content so instead you direct people to where the content provider wants them to go to see it. The second is a breach of copyright - not only are many YouTube videos copyright violations already, I'm 99% certain YouTube's terms of use regarding embedding are not compatible with the GFDL. Confusing Manifestation(Say hi!) 05:52, 27 August 2008 (UTC)

We can't link to Youtube on most occasions, because usually the content violates copyright. See

WP:YOUTUBE and further up that page where it says, "Linking to a page that illegally distributes someone else's work sheds a bad light on Wikipedia and its editors. This is particularly relevant when linking to sites such as YouTube, where due care should be taken to avoid linking to material that violates its creator's copyright." So in most cases we can't link to it, and we can't embed it because it is Flash. The only option (other than linking to non-copyrighted content) would be to convert the video in a format that Wikipedia can use, and than select a few seconds of it per fair use. Though I think Youtube don't like it when their videos are downloaded rather than streamed. So maybe even that one's a no-go. Still, if it's possible to do that, then I would say videos are better than text or images for illustration of an article per point b above. But I'm not sure it's allowable to even get those few seconds off of Youtube. Deamon138 (talk

) 15:41, 27 August 2008 (UTC)

GREAT IDEA: it should only be a few seconds in length, just to highlight the context and information provided, upon completion of the clip, the full movie would be available via link, back to source. I think limiting it to Youtube would be necessary as not to overstep copyright rulings. Deletion would be decided through talk pages as per norm. Could work, and in context with WP, it would make sense as it would be used here for the expansion of a public database useable by all and edited by many.Tdk12 (talk) 16:58, 28 August 2008 (UTC)

Again, Youtube does not operate under freely licensed code. The flash standards are not open. Not everyone can use youtube because of this, myself among them, because of these proprietary restrictions. We can, however, embed video within articles themselves, or link to them on Commons, both of which are much better solutions than relying on a third party. Celarnor ^{Talk to me} 03:04, 29 August 2008 (UTC)

Just as everyone's monobook.js (etc.) other than yours is fully protected, I think everyone's user page other than yours should be semi-protected. This is out of similar concerns to the protection of others' monobook.js pages; that you shouldn't really be editing that type of page at all, usually. Semi-protection should stop most random unregistered vandals and at the same time allow user page designers and what have you to make constructive edits to others' user pages (as I would imagine that people who do that sort of thing would easily meet the low requirements for the

On the other hand, there should probably be a template or something that should be created and that people could put on their user page (it would not have to actually alter the appearance of the page, I suppose) in order to enable it to be edited by anyone, for anyone who wants to do that.

Comments and feedback are appreciated.

It Is Me Here (talk) 11:30, 27 August 2008 (UTC)

There's little harm that can be done by people editing userpages, so I don't see the point of pre-emptive protection of all such pages. We protect them on request at

WP:RFPP; this keeps the default open for collaboration by anybody. Kusma (talk

) 11:36, 27 August 2008 (UTC)

User pages are part of the project and thus the same basic principles should be used. See

WP:RFPP as Kusma points out. I don't think vandalism is such a major problem in talk pages that we would need to protect them all. Or is yours hit by vandalism daily? Mine was hit only once and I revert vandalism and tag pages for CSD very often... SoWhy

11:41, 27 August 2008 (UTC)

Well, my thinking was that people aren't really supposed to edit others' user pages as far as I am aware (at least, I'm pretty sure I've read that somewhere), and semi-protection should not make any difference to those who do need to edit others' user pages (e.g. to add a new layout at their request), so this would only really hurt (potential) user page vandals, I would have thought. It Is Me Here (talk) 13:39, 27 August 2008 (UTC)

Is your assumption that the majority of unregistered edits are vandalism, not helpful? What if an unregistered user finds a userpage that blatantly violates

WP:USERPAGE? Sure, they could still report it, but I think allowing them to correct it and then notify people is better. — Twas Now ( talk • contribs • e-mail

) 21:50, 27 August 2008 (UTC)

It is much more likely that a long term editor will have found it first, I reckon. Deamon138 (talk) 22:04, 27 August 2008 (UTC)

Yes, and it is much more likely for a long term editor to find vandalism in main-space first. We shouldn't block unregistered users from editing just because they might not statistically be the first person to stumble upon vandalism. — Twas Now ( talk • contribs • e-mail ) 22:16, 27 August 2008 (UTC)

So are you proposing that, for example, when user A is logged in, all the user pages except for User:A are semi-protected and when user B is logged in User:A is semi-protected but User:B is not? Is that even possible with the software? It seems a bit hard to implement, but I guess if it is possible, it would be a good idea. -- Imperator3733 (talk) 15:22, 27 August 2008 (UTC)

He is proposing that unregistered users cannot edit User pages. Anyone logged in can still edit them. — Twas Now ( talk • contribs • e-mail ) 21:50, 27 August 2008 (UTC)

Yes, there's already support for pages only editable by a single user, as the original poster noted (e.g. monobook.js). Dcoetzee 18:30, 27 August 2008 (UTC)

If it is possible, then I think it is a good idea. It would stop vandalism by new users who are actually just sockpuppets of a banned user. But is it possible? Deamon138 (talk) 15:30, 27 August 2008 (UTC)

A prime example of what this could stop would be this kind of thing. Deamon138 (talk) 18:24, 27 August 2008 (UTC)

That example is actually kind of funny—replacing a user page with the Book of Genesis? Ha ha! — Twas Now ( talk • contribs • e-mail ) 21:52, 27 August 2008 (UTC)

Haven't you encountered Tile join before? He's a regular at Evolution (at the top of the history right now, in fact). Algebraist 21:55, 27 August 2008 (UTC)

Seems like he's out in force tonight! Deamon138 (talk) 22:08, 27 August 2008 (UTC)

So instead, they find something that matters, like an article, to vandalize? I don't see much of a benefit to this. The majority of userpages are likely never vandalized. Mr.Z-man 20:32, 27 August 2008 (UTC)

I would rather vandals open themselves to indefinite blocking on userpages than articles. EVula // talk // ☯ // 20:34, 27 August 2008 (UTC)

Firstly, Twas Now, for the lowdown on that edit, have a look

here

.

"I would rather vandals open themselves to indefinite blocking on userpages than articles." But regardless of whether this proposal goes through or not, they can still vandalize articles. This is just to stop them doing it to userpages as well. Especially since vandalizing a userpage can affect real people (i.e. the users).

"I don't see much of a benefit to this. The majority of userpages are likely never vandalized." Yes but some are. This is to stop those ones being vandalized. Just because a bad act is rare doesn't mean we shouldn't try everything in our power that is reasonable to counteract it. Would you dismiss knife crime as, "The majority of people are never knifed"? Deamon138 (talk) 22:03, 27 August 2008 (UTC)

I would if knifings could be put better almost instantly by the victim or any passing stranger. Algebraist 22:10, 27 August 2008 (UTC)

(after e/c) Sure, but does the fact that people get cut by knives mean that we should take them out of every kitchen? The cutters would just resort to using edges of paper instead. (Thistles go right through Kevlar by the way - learned that one the hard way). Counter-intuitive though it may seem, Wikipedia is truly open, everyone is welcome to edit here, however they desire. We choose to respond to the minority who are malevolent, with the trusty Undo button, rather than create a restrictive atmosphere for the many good-faith contributors who show up on any given day. Franamax (talk) 22:14, 27 August 2008 (UTC)

Hello there. I have tried to answer most people's points below.

• Re.
  WP:USERPAGE
  ), will have created an account.
• Re. Mr.Z-man and EVula, are you proposing, then, to use user pages as giant fly traps for vandals? Is that not slightly unfair on Wikipedia's users? Moreover, I would argue that a good number of edits to others' user pages by vandals occur in retaliation to their being warned about vandalising an article by the user whose user page they are about to vandalise; i.e. implementing this change would almost certainly see a net decrease in vandalism, not an increase, as people who want to vandalise articles do so anyway.
• Re. Franamax, I think this is certainly true with regards to articles, but user pages are not really articles and, as I have said above, I do not feel that others' user pages are really the sorts of pages that users should be editing on a regular basis, especially unregistered users. As Wikipedia has already taken many decisions which limit users' ability to edit certain pages, believing that the risk of vandalism outweighs the possible reward of more people being able to submit useful edits to a page, I think that a similar decision needs to be made here. After all, unregistered users will always be able to leave a note on someone's talk page informing them that such and such a feature on their user page should or could be improved.

It Is Me Here (talk) 08:46, 28 August 2008 (UTC)

Vandalism to user pages is harmless. An editor who vandalizes userspace doesn't vandalize mainspace, and can be blocked, preventing vandalism to the encyclopedia much more efficiently than semiprotection. All user talk pages need to be open for editing, and many user pages need regular editing by people other than the user itself (categories, transclusions, etc.) As this is a wiki, we should try to be as open as possible, and as no real harm can be done by IP edits on userpages, we should not give up our commitment to openness for a small amount of convenience. Kusma (talk) 08:54, 28 August 2008 (UTC)

To reply to some of the replies:

• "slightly unfair on Wikipedia's users" - Absolutely not. Vandalism on articles is worse, because then its unfair to the readers. If a user's page actually gets vandalized it can be protected, but semiprotecting all of them preemptively seems excessive. Some articles get vandalized, but that doesn't mean we should disallow anon editing.
• "I am making the assumption" - So this proposal isn't even based on facts? We should definitely not make such massive changes to open editing based on assumptions.
• @Deamon138: Not only is it a rare problem, its a minor problem. Comparing it to knife attacks is just silly. People get paper cuts, but that doesn't mean paper should start coming with padded edges. Mr.Z-man 17:31, 28 August 2008 (UTC)

Well, after my most recent check of Special:Recentchanges, using the same parameters for checking both the User and article namespaces, I counted 24 bold red edits on the User namespace compared to 15 on the article namespace, which does suggest that there is more vandalism on the User namespace. Furthermore, from what I could see, many of the positive anonymous contributions to others' user pages were to user pages or user subpages which were actually articles in waiting (and so which could be tagged with a template that unprotects the page). Although I did see one vandalism revert, as that was that IP's only edit, I am willing to bet that it was actually a Wikipedia regular who just happened to not be logged in at the time. It Is Me Here (talk) 18:35, 28 August 2008 (UTC)

Mr. Z-man, I used the knife analogy as a form of Reductio ad absurdum. Knife crime hurts people (physically). In the same way, vandalism of an article can hurt people (mentally). Besides, yes people get paper cuts, but then I've never heard of people running around with paper trying to cut other people with it. Have you?

Franamax, you're right, we shouldn't take knives out of kitchens, for that is their best place to be. The analogy is: keep knives (green user editing) off the streets (user pages), but leave them in the kitchen (article space).

Also to Kusma, I don't think anyone wants to see the user talk pages semiprotected as well, only the user pages. Deamon138 (talk) 20:26, 28 August 2008 (UTC)

Hi,

I am an occasionnal Wikipedia contributor and I really love your site.

However, I think that with the web standards evolving so fast, Wikipedia's user interface is now getting old (not much evolution since I started to use it some 5 years ago). I am talking about the look and feel, the general ergonomy of the site. It is alright now (but not great), I think a lot can be done in order to improve it.

A few examples : when editing an article, there should be a WYSIWYG edition window, the background color of the site could also change in order to reflect the fact that you are in edition mode. A better visual differenciation between the abstract of an article and the content would alos be nice.

In Wikimedia Commons, the feature picture voting procedure is just repelling. I used it several times but I have to says that it looks like if it was designed to keep normal people away from getting involved... Also, I have used many forums, but none had such a weird user interface as this one I am using right now : The wiki script is good for some uses, but it was not design for pools nor for forums ! Wikipedia's purpose is to make a great (probably the best) encyclopedia, not about doing everything with the wiki script only. The wiki script is good for editing content of the encyclopedia, but for other tasks there are other open-source scripts that are far more convenient.

Please keep in mind the following : The user/contributor should only have to focus the content, not on the technical things.

Google started Knol not long ago. They are using fixed width for their pages. I don't konw if it is a better design choice, but I think Wikipedia should really watch if some of their ideas concerning the design are not more confortable for the user.

Thanks for all the work you have done, and please, keep it on the cutting-edge of user-experience !

Noé Lecocq

It's been awhile since I thought about this, but Wikipedia is kind of ugly, and some of the special pages and forms are a bit inaccesible and confusing for newbies (including all Talk pages, I guess). Maybe WP should hire some professionals to take a look at what can be fixed wrt site design? Yeah, a lot of the Google pages/apps are a snap to use, but some of the more advanced features can be kind of hard to find. That said, you kind of get used to how Wikipedia looks and works once you've been around it for a while.

talk

) 09:24, 26 August 2008 (UTC)

I'll give my replies point by point:

• WYSIWYG edit window: If this ever happens, please make a preference to disable it. I prefer wikitext to WYSMBWYGBIPTAU, personally.
• Background color of the edit screen: Makes no difference to me. If the full-page text box doesn't tip you off, though...
• "Abstract" of the article: Do we have these? I've never seen one.

The abstract is the short summary text between the title of an article and the contents table. Sorry that I did not login, but I just realized that my fr.wikipedia.org account does not work on en.wikipedia.org. This would be a great thing to unify... N.L.

Oh, here that's called a

WP:SUL. Anomie⚔

10:33, 29 August 2008 (UTC)

• Commons featured picture voting: I've never used it, but Commons:Featured picture candidates seems fairly straightforward to me. First it lists the judging criteria, then tells you how to nominate, then tells you how to vote (I'm surprised it's an actual vote). Or does this really relate to the following point?
• Wiki interface for discussion: IMO it has certain advantages, as the same wikitext that is used in articles can be used in the discussion about articles, and I can see all the new comments on the page using the "diff" feature from the last version I read. There is an extension under development to give Wikipedia a more forum-like discussion system which you might like to contribute to. (At a first glance, though, I'm not too impressed with it.)

Anomie⚔ 11:09, 26 August 2008 (UTC)

I can sympathize with your concerns, Noé, but I do think that many of the advanced usability revisions need to be optional (invoked on demand) rather than default. First, consider the actual page output for an article; in order to reach the broadest possible contingent of people on the planet, the default Skin (monobook) really needs to address the lowest common denominator. I am a bit biased in that I am the kind of presenter who prefers black and white slides to full color with animations, but if one is trying to reach both the affluent student in a Swiss private boarding school and a dusty school room in Nigeria, some compromises need to be made with respect to the default presentation. As far as I can recall, the Skin set has not changed in AGES; so there is room there for addition of new Skins that take advantage of the latest and greatest capabilities of IE7 and FF2.

Second, I do agree that a WYSWYG editor would be a good addition - though I would not use it personally. Some commercial wikis have this as an option; for instance, the Confluence Enterprise Wiki, which I recently started using at work, has a three-tabbed format - one tab for 'preview mode', one tab for 'wikitext' mode and one tab for 'wyswyg' mode (I'm not looking at it right now, so these tab titles are likely wrong - but the functions are right).

Finally, third, there is a severe governor set on MediaWiki development—the availability of experts to actually code, prototype and implement enhancements. I have not spent much time outside Wikipedia/Wiktionary/Wikisource, but I have never seen an invitation to test an emerging enhancement, which I think is really odd. There are certainly far more enhancement requests than will ever be acted on, but when one is acted upon, it seems to be put directly into Production rather than emerging as a beta-function for user acceptance testing - and development of an editor communications plan that would maximize awareness and utilization of the new functionality. Again, I am biased in that one of my roles in my work life is as coordinator for training and "awareness" activities for a research site of a couple of hundred scientists - so I am rather keen on maximizing ROI through relatively low cost communications and user engagement methods.

--User:Ceyockey (talk to me) 02:21, 27 August 2008 (UTC)

You're right, Wikipedia does look a bit on the black & white side, but changing websites around too much isn't always that cool. When extra unneeded gadgets are added to websites, it makes it take longer to load on slower computers. Plus, the addition of flash content, java scripts, ActiveX controls, etc. makes it impossible to access certain content from certain machines. It would be nice to spice it up a little around here, but remember to minimize any negative impact.

(Messages)

03:33, 27 August 2008 (UTC)

The use of ordinary wiki pages for discussion and forums is a serious problem that I discuss in some detail at User:Dcoetzee/Why wikithreads are bad. I believe it's vital that some interested developers sink the necessary effort into integrating a real forum system with Mediawiki. Dcoetzee 07:11, 27 August 2008 (UTC)

I propose to make the French and German Wikipedia's way of showing "edit section" links the default for the English Wikipedia as well. See the fr example and the de example, paying attention to the fact that the edit section link ("modifier" or "bearbeiten") is printed just next to the section header rather than hundreds of pixels away from it as it is printed on the English Wikipedia (see en example). See also this relevant comment. NerdyNSK (talk) 00:30, 27 August 2008 (UTC)

The edit links are also to the right in the de: link - at least when I viewed it they were. Also, I'd actually rather have the edit links further away from the section headings so I wouldn't have to look at them as much; this should probably be made toggle-able through your preferences if it were implemented. It Is Me Here (talk) 11:36, 27 August 2008 (UTC)

I prefer the en-way, because it does not make the section headings look strange with a little blue [edit] to it. Maybe you could have an option in the prefs where you want them? SoWhy 22:51, 27 August 2008 (UTC)

Prefer no, because Wikipedia is an encyclopedia first, and the editing part secondary. Let's not confuse readers here. x42bn6 Talk Mess 01:17, 28 August 2008 (UTC)

I think that putting "edit" close to section titles will encourage editing; whether that will increase vandalism more than it increases useful contributions is another issue. In any case, we need to separate out arguments about (a) what is best for readers and potential editors from (b) comments about what individual Wikipedia editors commenting here prefer. For the latter, we can always set up a gadget to put the edit link to the far right. (That's why the "new section" tab now reads as it does; for editors who wanted the tab to continue to be "+", they just needed to change a preference.) -- John Broughton (♫♫) 21:59, 29 August 2008 (UTC)

Two things that are done in de-wiki that I think we should use here as well:

1. In de-wiki when you preview a page, it has a link on top that allows you to jump back down to the edit window, saving you the scrolling. Can we have something like that as well here?
2. Also, when you edit a page anonymously, as an IP, on de-wiki you are forced to use the preview button before you are allowed to save the page. That way I think we could maybe prevent dozens of page revisions because an inexperienced user has made a mistake and edits again and again to fix it instead of using preview to see the mistake before it's saved.

What do you all think? SoWhy 22:58, 27 August 2008 (UTC)

1. Yes please, right away. 2. Not so keen on force previewing IPs. It may discourage them from editing. Deamon138 (talk) 23:34, 27 August 2008 (UTC)

Agreed on 1. The page to edit is MediaWiki:Previewnote, but I'm not sure where the link should point: #toolbar will presumably break if the toolbar's disabled, while #editform will skip the toolbar if it isn't. Algebraist 23:53, 27 August 2008 (UTC)

I'd also like to see 1. I'm not to sure about 2, though. There is the definite possibility that IPs would be discouraged. -- Imperator3733 (talk) 06:25, 28 August 2008 (UTC)

In contrast to those above, i don't really care about scrolling down to the preview box, it makes no difference to me, although an added button wouldn't bother me either, why not make it a user preference, like the option of having an edit section button for the top part. As for the forced-preview idea, i like the idea, both because, as sowhy says, it can reduce the number of accidental edits and slip-ups, and also because for the less dedicated would-be vandals it effectively doubles the time it takes them to vandalise = get bored quicker = net gain for the project--Jac16888 (talk) 06:53, 28 August 2008 (UTC)

As for the concerns raised about 1. by Algebraist, I think that will not be a problem, as de-wiki uses it. We just have to copy it from them. See de:Mediawiki:Previewnote (it's the "Zum Bearbeitungsfenster"-link). They use #editform as anchor but I think I recall that it works and still shows the toolbar. I can't test it, because some admin thought it fun to block my company's IP range from de-wiki.

As for scaring away IP users, I don't think there is much of a risk. Someone who wants to add information will do so even if it takes him another click. Best way to find that out would be to ask someone who has complete server access to have a look at the logs for de-wiki and tell us if IP edits where significantly reduced after de-wiki introduced this.

But as Jac16888 points out, it makes vandalism more annoying and as I said, could diminish the number of accidental edits. SoWhy 07:55, 28 August 2008 (UTC)

On de.wiki, the anchor is on the edit box, which (in FF3 at least) means the toolbar is off the top of the screen and invisible. A dev could fix this behaviour, but I don't think an admin could. Algebraist 11:57, 28 August 2008 (UTC)

I think point two is a similar thing to Wikipedia:Perennial_proposals#Automatically_prompt_for_missing_edit_summary. Deamon138 (talk) 20:34, 28 August 2008 (UTC)

No, because they would still be able to not use edit summaries. The proposal is to make them preview changes first before beinge able to save. SoWhy 20:38, 28 August 2008 (UTC)

No what I mean is that it is similar in that in your proposal (2), they are forced to preview, in that link they are forced to make an edit summary. Both times when the user clicks save their edit won't be saved until they go through another step. Basically the arguments against the proposal in that link are the same arguments being made here. I thought I would make people aware that a similar thing had been proposed (and rejected) before: making people go through an extra step before their changes are saved. Anyway, I think the arguments against forced edit summary apply to this one, and any argument for this change that addresses these arguments would automatically address reasons not to have forced edit summaries. Not that I think these arguments will be addressed though. Deamon138 (talk) 20:52, 28 August 2008 (UTC)

Re edit window, you may find it easier to have the edit window at the top when previewing. Go to "my preferences", "Editing", and unclick "show preview before edit box". ☺ Coppertwig (talk) 02:23, 29 August 2008 (UTC)

You have it all wrong, that shock site doesn't even belong to Grawp or anyone assossiated with him. He just uses it for trolling. 86.154.196.196 (talk) 16:31, 29 August 2008 (UTC)

Wrong section, the discussion you're contributing to was deleted,

WP:Deny--Jac16888 (talk

) 17:34, 29 August 2008 (UTC)

I support #1, and I like it floating in the right corner of "This is only a preview ..." message, see working example on testwiki (unfortunately, this would be a wrong direction for users with preview under edit window). #2 is much more serious desision and should have been proposed in a separate section. —AlexSm 17:37, 29 August 2008 (UTC)

@Coppertwig above: I personally prefer having the preview above the edit window since that is what you generally first want to look at when previewing, but on longer articles, it would be useful to have a link at the top to the edit window so I can just skip all the way down without having to scroll loads. Yes, poor poor me and my editing woes... Deamon138 (talk) 01:19, 30 August 2008 (UTC)

Issue: When a wiki user leaves a note on another wiki user's talk page, this user is informed of it by a system message. To take advantage of this function user A usually writes on user B's talk page while user B replies on user A's talk page. Unfortunately, this results in the discussion being torn so that it has to be followed on two wiki pages. This might be especially difficult for a third user who is interested in the discussion. (If more than two users are involved in a discussion I assume it will take place on an article's talk page, though, if not always.)

Proposal: If the opportunity was created for users to determine manually which other user(s) be informed of new talk page contributions of theirs, the discussion could be held on one talk page only without sacrificing the immediate notification of the other panelist(s). There could be a box in which to insert the user names who are to be notified. This device could also be used on article talk pages to inform fellow panelists of new contributions.

--

I think that would be to complicated to implement. I would suggest using {{talkback}} to prevent this. SoWhy 21:51, 29 August 2008 (UTC)

That's a great template I didn't know of.--

talk

) 22:08, 29 August 2008 (UTC)

You are welcome. You can consider placing {{usertalkback}} to your talk page as well. Have a nice evening :-) SoWhy 22:48, 29 August 2008 (UTC)

A plan is in the works to found a new UK chapter of the Wikimedia Foundation, and we are currently gathering support from the community. If you are interested in being part of this new UK chapter as a member, a board member or as someone with a general interest in the chapter, please head over to m:Wikimedia UK v2.0 and let us know. We also welcome help in making finishing touches to the plans. An election will be held shortly for the initial board, who will oversee the process of founding the company and accepting membership applications. They will then call an AGM to formally elect a new board, which will take the chapter forward, starting to raise funds and generally supporting the Wikimedia community in the UK.

Geni 23:30, 29 August 2008 (UTC)

Since many of the pages can be categorized geographically and if we know who all other Wikipedians belong to a city (through appropriate user category), the pages related to the city (typically categorized under a city category) can be better watched/managed/maintained (including less important ones but which belong to a city category). We may not enforce this but giving a optional option on user page can lead to many Wikipedians choosing that option. This will help address biggest worry of WP i.e. fighting vandals .

I think we have Userboxes and chapters for this sort of thing, but the "city" you belong to may not have much to do with what you edit. I have over 400 pages in my watchlist but only a couple of percent are geographically related to where I live, many of my edits are related to interests I have - some of which are obvious from my userboxes, though on second thoughts perhaps I need more user boxes. One possibly useful thing for people to know is your timezone - just add this {{User:Tkgd2007/Userboxes/My time|+1}} box and calibrate it to your timezone. But then there are night owls and early birds.... Mind you I'm not sure that vandals are our biggest problem, or that knowing whose geographically near you is going to be a big help. ϢereSpielChequers 00:27, 29 August 2008 (UTC)

I thought it was implicit in my post that city based User boxes are not much used by Wikipedians thus wanted WP to encourage it (though not enforce it). Like you there may be several Wikipedians whose work may belong to non-geographical pages but there are also several who wants to manage/maintain pages related to a city (primarily places, monumanets and people associated with City) and if this proposal is taken up then one can find out other fellow Wikipedian from same city and they can make a team and can manage the pages more effectivily. There are portals/projects on specific topics Cricket, Football etc and interested Wikipedians co-ordinate their activities through that but we cannot assume to have a separate Project/portal per city, that will be too much.

talk

) 13:25, 29 August 2008 (UTC).

What about people that live way out in the

(Messages)

20:45, 30 August 2008 (UTC)

I think we should add something to the top of

I think we need a note along those lines added to MediaWiki:Anoneditwarning. Thoughts? D.M.N. (talk) 09:16, 30 August 2008 (UTC)

I think that is not a bad idea but I do not think it should be restricted to IP users. Many registered users add unsourced material and BLP-violations as well... SoWhy 09:23, 30 August 2008 (UTC)

Change "...nor must they violate..." to "...and also must not violate" - jc37 09:24, 30 August 2008 (UTC)

Suggest WP:BLP be expanded to Wikipedia's biographies of living persons policy, with bold being optional and case as you see fit. WP:BLP would be meaningless to a newbie. LA (T) @ 10:20, 30 August 2008 (UTC)

I think I want to know where you are planning to remove 17 words from the interface?Geni 13:51, 30 August 2008 (UTC)

I can't remember the last time any words were removed from the interface. It just keeps growing, and growing... — CharlotteWebb 19:00, 30 August 2008 (UTC)

There isn't a page like that for logged in users which has a warning above the edit box, so I think one would have to be created, possibly under the title MediaWiki:Registereduserwarning to be implemented for registered users, as suggested by SoWhy (talk · contribs). Maybe a reword to the following would sound better:

Please note your edits must not constitute of

Wikipedia's biographies of living persons policy

.

I'm implemented Lady Aleena's suggestion about boldness. I've also bolded the Original Research phrase as well. D.M.N. (talk) 11:50, 30 August 2008 (UTC)

It could be added to the text below the editbox:

"Content that violates any copyright will be deleted. Encyclopedic content must be verifiable. You irrevocably agree to release your contributions under the terms of the GFDL*."

Maybe that could be rephrased and your idea added to it? Then there wouldn't be need for more than one change for both IPs and registered users. SoWhy 11:58, 30 August 2008 (UTC)

I've got no idea what MediaWiki page that is that would have to be changed in the process. D.M.N. (talk) 12:08, 30 August 2008 (UTC)

I have and it needs to be kept as short as posible. Adding anything that makes that text longer is not acceptable.Geni 13:51, 30 August 2008 (UTC)

The WikiProject naming convention being discussed is for the names of common pages, categories, and templates of all WikiProjects. If interested, please read the proposal and discuss it. LA (T) @ 10:14, 30 August 2008 (UTC)

I had an idea - does Wikipedia_talk:Administrators_open_to_recall#Proposal_for_changes_to_AOR make the whole AOR process fairer and address both ways it can be rorted then folks? Cheers, Casliber (talk · contribs) 13:08, 30 August 2008 (UTC)

If you're going to propose making the process mandatory for all admins and give bureaucrats some rather stunning new powers, do you think that it might be tad misleading to call your proposal a 'tweak'? TenOfAllTrades(talk) 18:53, 30 August 2008 (UTC)

Currently watchlist reports only when there is a change to a category page itself not when a Page is added/removed from it. Once this is done people will have smaller watchlists as well.

I believe this is being worked on. Mr.Z-man 19:37, 29 August 2008 (UTC)

Can this be moved to

talk

) 06:17, 1 September 2008 (UTC)

If we can reduce the height of editable area so that 'Save page' button can be accessed without scrolling then this will help a faster WP editing i.e. improved productivity. The need to scroll for even minor changes is a distraction/pain.

Press Tab from the edit area to jump to the 'Edit summary'. After typing your summary press Enter to save the page. —AlexSm 15:22, 29 August 2008 (UTC)

You can adjust the size of the edit box in your preferences. For people with high-resolution monitors, reducing the default size would probably slow down editing. Mr.Z-man 15:36, 29 August 2008 (UTC)

Thanks, this worked.

talk

) 06:04, 1 September 2008 (UTC).

A good idea would be to use some

Safari users can adjust the size of the box on the fly. Very, very handy when you need to see more of the box on just a single page. EVula // talk // ☯ // 05:29, 30 August 2008 (UTC)

I'm on a mac but prefer Firefox. It would be good of a simlar feature could be made global on mediawiki. — ^.^ [

needed

] 13:16, 30 August 2008 (UTC)

Currently I think '

No, it's admin only. I have rollback rights but I cannot see it as well. I like your proposal though - It should be available for rollbackers, because those users are usually trusted not to be vandals. I think by edit count would be harder to do because it would mean creating another group like "autoconfirmed". Also, adding it to rollbackers would allow admins to have control who gets to view it. SoWhy 18:15, 29 August 2008 (UTC)

support, i think that all of the above is a great idea, including adding to rollbacker, rather than another group, if we're trusted with rollbacker, i don't think it will hurt having access to a passive tool, with only net gain for the community. Might have to change the name of the rollbacker group though, perhaps go back to the "trusted user" idea--Jac16888 (talk) 18:29, 29 August 2008 (UTC)

Comment I am against changing the name of rollbackers to something like "trusted user", because that sounds like we have some users that are worth more than others. I think the name "rollbacker" is still good even with such a right added to it because like rollback, it's main use is to fight vandalism. SoWhy 19:06, 29 August 2008 (UTC)

I think this should be open to rollbackers. If all rollbackers watchlisted five pages that currently aren't watched, I think en-wiki would win the internet. Celarnor ^{Talk to me} 18:38, 29 August 2008 (UTC)

Yeah I would support it being viewed by Rollbackers as abuse of rollback will result in it's removal and then loss of ability to view this page. BigDunc^Talk 18:46, 29 August 2008 (UTC)

And if the user doesn't abuse their rollback but vandalizes with a different account? Pseudomonas_(talk) 09:12, 30 August 2008 (UTC)

Not necessarily. I've got 2,500 items on my watchlist; if I added five more pages to it, there's no guarantee that I'd be able to catch anything, given all the other stuff that shows up. EVula // talk // ☯ // 05:32, 30 August 2008 (UTC)

Well, I certainly would. I'd love to be able to expand what I watch in the articlespace. Celarnor ^{Talk to me} 05:46, 30 August 2008 (UTC)

I oppose this until the page becomes more useful (I think there is a bugzilla request to have the limit raised for expensive queries, like the one used to generate the unwatchedpages page). The page is pretty much just a novelty in its current state. Mr.Z-man 19:35, 29 August 2008 (UTC)

I think there's too much potential for abuse; additionally I don't want to create incentives for people to rack up n edits to claim their prize - I don't think that's the way that WP ought to work. Pseudomonas_(talk) 23:44, 29 August 2008 (UTC)

Would you be opposed to add the right to the rollbackers-group? They already have a right that has much potential for abuse anyway, so there is not more risk created by that. SoWhy 23:51, 29 August 2008 (UTC)

OK, if someone abuses rollback - and it happens - then you remove their rollback rights. If someone abuses this, then assuming they're not stupid enough to vandalize with the same account, then what do you do? If they copy all the unwatched pages onto some website or other, what then? I guess it'd be OK if the result is that pages don't hang around on the list for very long and the backlog is eliminated, but if it doesn't work like that, it could be a big headache. Pseudomonas_(talk) 09:10, 30 August 2008 (UTC)

Comment: the reason why it is only open to admins and not regular users is that by the

very process of determining adminship, the editors granted admin powers are judged to be trusted members of the community, whereas regular editors haven't been so judged. Saying that, I would give a weak support to granting this feature to rollbackers (and not because I am one myself). Rollbackers are judged in order to be granted the power, however the rollback feature is trivial compared to this feature, so the judgement of a requests for "Unwatched pages" would have to be more strenuous. I think if there is any going to be any serious proposal made for this feature to be opened up to more people, then the users involved in granting rollback powers need to be canvassed. Deamon138 (talk

) 01:47, 30 August 2008 (UTC)

• Oppose merging with rollback considering the level at which rb is given out; quite a bit of harm could be done with this by vandals, I don't want to spill any beans but if vandals know what pages are unwatched they can insert sneaky vandalism, the kind not caught by the recent changes patrollers, and have it stay for months and there is not that much good to counter act this negative; special:unwatchedpages is not a very helpful utility in fighting vandalism, or so I have been told; most vandalism is caught in the 'recent changes' and so the vandalism is very diffused throughout the pages on the list to the point that you have to go through hundreds of pages to find one instance of vandalism; no one is going to spend the time to do that. - Icewedge (talk) 05:46, 30 August 2008 (UTC)

Comment How about just some centralized facility where users can ask for an admin to email them a random listing of 500 or so unwatched pages? The reliable-user threshold should be much higher than for rollback, which is granted because it can be easily checked and removed. If any admin wants to send me a listing (preferably starting with letters, not starting from

Comment: that page is useless for anything but vandalism. There is no need to give access to it to anyone at all. Prodego ^talk 15:06, 30 August 2008 (UTC)

Wouldn't it be good to use to counter vandalism? Because it would allow those fighting it to have a list of potential targets... SoWhy 17:59, 30 August 2008 (UTC)

Maybe a "Special:Recentunwatchedchanges" page would be helpful . — CharlotteWebb 19:04, 30 August 2008 (UTC)

The question is irrelevant at the moment. The page only lists 5000 pages, which isn't even enough to get past the ones with titles starting with 1. Rollback is given out too liberally for this, but I don't have an objection in principle to making it available to trusted non-admins. Hut 8.5 12:06, 31 August 2008 (UTC)

I propose that there is a usergroup who can edit protected pages and templates. Similar to the purpose of the proposal of allowing certain users view deleted contribs, it will allow experienced users who are not admins to edit deleted pages. However, only trusted users, normally with 1500+ mainspace edits, will be granted this permission. Their edits will be reviewed before they will be granted this right. If the user has a known history of vandalism, or has very few mainspace edits, they will not be granted this right. This would be very useful for contributors who are not admins to update the In the news section of the main page, although an admin might do that for them.

That is not currently possible. If you set a page to edit:sysop, naturally only users with the sysop right could edit it. To do this you would need to to invent a whole new right, and give it to every admin. Which isn't going to happen. :) Prodego ^talk 15:03, 30 August 2008 (UTC)

Maybe you could set edit=rollbacker? That group exists already and they should, in theory, only get that right when trusted not to do vandalism. But I do not know if sysops were excluded then. I do not see any need for it though, if you need to do huge edits, there is always

WP:RFPP and if you want to correct something, you can always ask an admin to do it. We have not nearly enough admins for a project this big but it should always be possible to find someone to do it. If you think you need to do such things or want to be able to help others to make such edits, you can always request for adminship. :-) SoWhy

18:06, 30 August 2008 (UTC)

I am a rollbacker. Having said that, I disagree with adding this ability to the rollbacker group. People were granted rollback permission for one specific reason, adding new abilities to that group would, IMO, require taking a new look at everybody who has the rollback bit to see if they should be granted the new capability. Corvus cornix_talk 18:31, 30 August 2008 (UTC)

Actually, my understand is, due to the same software changes which introduced the rollbacker right (and several others) as "standalone" user-rights, having this as another "stand-alone" user-right would be a fairly simple thing to do.

All that would need to happen (AFAIK) would be for there to be consensus shown here, and the developers may make that addition.

(Incidentally, I also oppose combining this with rollbacker. It's two separate rights for two separate "needs".)

I strongly support this idea, however. For one thing there are experienced coders who could use this right yet have no need for the other tools of adminship.

Also, since this (presumably) would allow for editing pages which are protected at the "sysop" level, this should be granted by bureaucrats (as a result of whatever process is decided upon). - jc37 20:33, 30 August 2008 (UTC)

The rollbacker-idea was just that, an idea. I think it should not need a new group, because as Prodego points out, if you make such a group, you'd have to change the protection of all pages protected as "sysop" to the new group.

I personally am against such implementations, because I do not see any real need but a lot of potential for disruption. We should rather get us some more admins (there are more than 1000 users willing to do the job who you could nominate for that) than dissect the admin tools to create dozens of new groups for every need you can imagine. What's next? A read-deleted-pages-group? A group of people allowed to block users? A people-who-may-protect-pages-group? The possibilities are endless but none are really needed (I grant you rollbackers is not a bad idea though but just because it's more of a vandalism-fighting than an admin tool). SoWhy 20:49, 30 August 2008 (UTC)

My personal experience is that admins respond pretty quickly (and fairly) to {{

editprotected}} postings on talk/discussion pages. That's one reason I'm against the proposal; for things like templates, it isn't necessary. The other is that admins lock down articles for a reason - because there is a major edit war going on. Locking an article down forces editors to work on a consensus-driven change. (It's pretty rare for an admin, once an article is fully protected, to make any change other than perhaps deleting BLP violations or fixing an obvious error.) To let 1500+ more editors be able to edit those articles would be a mistake - if an admin abuses this privilege, he/she risks de-sysoping; if an editor with rollback rights abuses this privilege, he/she stands to lose ... what? And defining "abuse" could be very difficult - what is an abusive edit, as opposed to a helpful one? (But to editors without rollback privileges, such edits would be extremely aggravating - they're locked out, but others are still making changes.) -- John Broughton (♫♫)

14:55, 31 August 2008 (UTC)

The style for US college football and basketball teams on Portal:Current events/Sports is as follows:

• If there is an article on a team's season, use [[2008 Ohio State Buckeyes football season|Ohio State]]
• If there is no article on the team's season but is an article on the team, use [[Ohio State Buckeyes football|Ohio State]]
• If there is no article on the team but is an article on the athletic program, use [[Ohio State Buckeyes|Ohio State]]
• If there is no article on the athletic program, use [[Ohio State University|Ohio State]]

This is time-consuming for two reasons. One, you have to check for every team whether there is an article on the season, team or athletic program, and two, you have to type wordy links over and over again.

What would be helpful would be some kind of software shortcut that would automatically convert a short text string into the appropriate wikilink. For example, {{OhioStatefootball}} would automatically convert to [[2008 Ohio State Buckeyes football season|Ohio State]], [[Ohio State Buckeyes football|Ohio State]], [[Ohio State Buckeyes|Ohio State]] or [[Ohio State University|Ohio State]], depending on which articles exist.

Is this possible? Thanks -- Mwalcoff (talk) 02:56, 31 August 2008 (UTC)

"Why? What if you wanted

Because that's not the style used on the page. Nobody wants to have 2007 Ohio State Buckeyes football season 43, 2008 Youngstown State Penguins football seaso 0. -- Mwalcoff (talk) 00:07, 1 September 2008 (UTC)

Possible, yes. With enough template coding I think you can technically do anything. However, the necessary calls for determining if an article exists are rather taxing on the server so we don't like using them, particularly in non-subst: templates (a template like you describe would have to be non-substed to avoid leaving a giant mess in the wikicode), and making the templates sensitive to things like the year would require you do nearly as much typing. So I don't think this is likely to go through. --erachima talk 06:44, 31 August 2008 (UTC)

We have red colored words to indicate that an article is missing for that word. A good idea would be to have green colored words to indicate that an article is missing in the english wikipedia but is present in a different language wiki; of course this could be implemented in other language wikipedias as well. Green words may also point to a special page that, for example, reads:

We don't have an article for that word in this wikipedia but an article is available at the following wikipedias:

Language / Quality

If you speak one of these languages, you may help in developing a new article.

This would be of great help to translators or anyone speaking another language willing to contribute.
I don't think this would be too complicate to implement. --Itemirus^{Talk Page} 16:17, 21 August 2008 (UTC)

Surely most things are present in this wiki but not present in other language wikis though, seeing as this is the largest one? Also, if an article is notable enough for inclusion in another wiki, then it would be notable enough for here generally, so it should be redlinked to encourage its creation. Deamon138 (talk) 22:27, 21 August 2008 (UTC)

There are probably at least two general areas where en-W would lack articles but other language versions would have them: geography and biography. --User:Ceyockey (talk to me) 11:02, 22 August 2008 (UTC)

Support:The concept is very well stated and should be considered. At least, searches should be capable of resulting in the suggested special page as demonstrated above. Sswonk (talk) 01:59, 22 August 2008 (UTC)

How would the software recognize that the article is present in another language? — Twas Now ( talk • contribs • e-mail ) 03:42, 22 August 2008 (UTC)

Probably through the presence of

interlanguage links in the article. -- Boracay Bill (talk

) 03:48, 22 August 2008 (UTC)

There won't be any interlanguage links in a non-existent article.--Father Goose (talk) 08:17, 22 August 2008 (UTC)

But there could be an option on that page to add such manually, see my post below. SoWhy 08:42, 22 August 2008 (UTC)

Interwiki concept is far from being foolprof. It's probably OK for personalities and uncontroversial geographic location but anything else may be completely wrong (language/culture/etc incompatibility).

NVO (talk

) 23:11, 22 August 2008 (UTC)

Support: This is a great idea, and would probably be possible with some preprocessing directives during page generation and the use of interwiki links. Celarnor ^{Talk to me} 04:21, 22 August 2008 (UTC)

• Support - This looks like an excellent idea. Though I have a feeling it's going to be more useful to other wikipedias linking to here, than vice-versa : ) - jc37 04:30, 22 August 2008 (UTC)
• Support Sounds like a great idea, if it is possible to code. I don't think it's only for other Wikipedias though, for example the Italian Wikipedia might have more entries about Italy-specific topics than the English one, especially those topics that noone bothered with yet. It's a win-win situation for everyone. As for the technical stuff, I think names of peoples and places can be identified easily and those pages could allow manual linking so people could add the other languages to it (and a bot could look through all red links and got through a dictionary search to see if they exist...just an idea). SoWhy 07:43, 22 August 2008 (UTC)
• Er, I like the idea of being able to search for an article with a certain name in all wikis, but for many topics the name will be different on other wikis (in a different language), which limits its utility. Dcoetzee 08:50, 22 August 2008 (UTC)

By using Qwika one can find out easily what has been written about a certain subject in other wikipedias. JoJan (talk) 09:10, 22 August 2008 (UTC)

• The easiest way to do this could be the manual use of special tags like triple brackets or something similar; for example i am browsing the italian wiki and i find an article describing what a ground radar is; then i see that an iterwikilink is missing for the english wiki, so i open an english article about airports or radars and i look for an instance of ground radar in the article and i change its tag so that it turns from red to green. I know this sounds annoying and besides, i could write a stub myself, but it would be useful anyway - maybe a special patrol squad could be assigned to this task
• a bot could be useful for names of persons or things that don't change from language to language, as long as they use the same alphabet, i.e. Michelangelo or Pizza are written the same way in English, Finnish or Spanish;
• another bot or semiautomatic process could make use of dictionaries; probably this would need human supervision but i guess it can be done quite easily

These are just simple suggestions - if we get enough support i think we can work this out. --Itemirus^{Talk Page} 10:30, 22 August 2008 (UTC)

Comment: Regarding maybe a special patrol squad could be assigned to this task - basically, no one "assigns" anyone to do anything here, and certainly there is no way to "assign" a group of people to do something. Regarding a bot could be useful for names of persons or things that don't change from language to language, you might want to help the creator of the Interwiki-Link-Checker, since you think that a lot of what that person is asking humans to do could in fact be done by software. (Matching people - impossible without birthdates; matching things - almost certainly a huge number of false positives, if only because of disambiguation pages. And yes, I've actually used this tool.) -- John Broughton (♫♫) 00:32, 24 August 2008 (UTC)

• Oppose, not because I think it is a bad idea (it is a good idea) but because I think that adding more Wikipedia-specific "informative formatting" to article content is not a good thing. I think that a better solution would be to enhance the content of the existing "no article in wikipedia" page. There are two possible target pages for ground radar, one that is an 'edit now' version and another that is a 'no article exists here' version. A notice should be included on each of these pages indicating the (possible) existence of non-English versions, with interlanguage links to those. --User:Ceyockey (talk to me) 10:57, 22 August 2008 (UTC)

Comment - Well Ceyockey, i partially agree with your remark, but the advantage of using two colors is that you are immediately notified of the existance of the article in another language or of the fact that the topic has never been developed before anywhere. This way, with the green words you are quickly informed of the notability of the subject and that you have a starting point somewhere else (a subtle invitation to take part in the effort), while a red colored word might suggest that the subject is popular only within a specific culture or language.
The peculiarity and strength of WP lies in the interactive and collaborative side of the project, so, in my opinion, by adding options for interactivity and collaboration, as long as they are not too intrusive and distract the reader or hinder the information flow conveyed by the text, you are adding to the depth and strength of the project, without compromising overall usability. This is a case where the juice might be worth the squeeze.--Itemirus^{Talk Page} 12:36, 22 August 2008 (UTC)

Comment: Perhaps both a two-pronged approach and a compromise could work here. With respect to color - have this as an optional parameter setting rather than a default setting. It would be reasonable to put this on the "Misc" tab, directly under the checkbox reading "Format broken links like this (alternative: like this?)." This could be re-phrased as "Format links to articles missing from the English Wikipedia like this (alternative: like this?)." Below this could appear a checkbox with associated text like "Format links to articles missing from the English Wikipedia which are represented in other language Wikipedias like this". At the same time, enrich the content of the existing "no article in Wikipedia" pages as suggested in my 'oppose' above. --User:Ceyockey (talk to me) 01:32, 27 August 2008 (UTC)

Oppose: firstly, I think an extra colour will be distracting, and clutter up the page (I mean people are already removing auto-formatting from dates with clutter as one of the reasons). Secondly, those not in the know of this will not understand. Imagine you're a new user. You will wonder why in the hell that word is in green. Blue words are obvious, the rest of the web have them. Red words less obvious, but still get-able. But green words are not obvious at all. Thirdly, there is no way of knowing if content about a word on another language wiki would be notable enough for this wiki. The reason that this wiki doesn't have an article on it might be BECAUSE it isn't notable enough for this wiki, and hence there would be no reason to link to the article in another wiki. Fourthly, the majority of readers speak only one language fluently, so this proposal is mainly for editors. However, if an editor is well versed in English and another language, he will likely have an account in that other language, so he could find out that there is an article on it there that way, translate it, and copy it over. We shouldn't be having "placeholders" for content that either would fail notability, or if it could pass just hasn't been added to Wikipedia. Fifthly, it's inconsistent. In articles we DO have, we have a list of the other language versions of the article at the SIDE of the page. This proposal would be completely different to that, and therefore inconsistent. Sixthly, if a reader is fluent in more than one language, and can't find the article here, he will most likely go to another wiki he is fluent in, making the green links redundant. Seventhly (not sure I've gone this high before!), a similar reader may click on the link, only to find out that there isn't one in any of his languages but there is in lots of other languages that he doesn't know. He has basically just gone on a mini wild goose chase, which we've led him on. Eighthly, the majority of articles that are notable we already have, as this is the biggest Wikipedia. Someone said that the two exceptions are geography and biography. While other wikis might have different notability requirements, on this wiki, we are allowed articles of Polish villages, so geography wont be a problem. But if its not notable for here, then a link to where it is notable isn't worth it. We're basically saying, "here's some info you can read we don't deem good enough for this wiki". Better to make the article itself, than make a placeholder if it does deserve to be here. Ninethly, what about redirects? If there's an article on "Foo" a one wiki, but "Foo" is a redirect here, then what happens then? Is the redirect moved? Do we keep the redirect and disambiguate the other languages page? But then a user searching for "Foo" would end up at the redirect. Basically, if something deserves it's place on the English Wikipedia, in good time it will have it, regardless of how many other wikis have it. This proposal opens up a huge can of worms, for a problem that doesn't need fixing. If it ain't broke don't fix it! Deamon138 (talk) 20:28, 22 August 2008 (UTC)

Oppose. How in the world will the system tell that

• Another point. A/B/C ratings in foreign languages are set by local wikis and do not correspond to en-wiki standards. Standards of each wiki change over time, so a 2005 FA will only make a B-class today. Discard these grades.
  NVO (talk
  ) 23:16, 22 August 2008 (UTC)

Support but it requires a software solution, and I suggest using a colour similar to red (e.g. orange or orangered or pink?). This has similarities to something I proposed here, about having a single list of interwikis on a topic, to be used by projects in all languages: implementing one of these might help with implementing the other. Alternatively, maybe there's some way to implement it as a userscript. Coppertwig (talk) 02:01, 23 August 2008 (UTC)

Oppose because I find the proposal inferior to the much better alternative solution User:Ceyockey proposed in this discussion on 10:57, 22 August 2008 (UTC). NerdyNSK (talk) 00:38, 27 August 2008 (UTC)

• Support using a green color. This will also help translators to bring articles from other Wikimedia Wikis.
  Macy
  02:18, 27 August 2008 (UTC)

• Oppose, for reasons already mentioned Dwr12 (talk) 09:25, 28 August 2008 (UTC)

• Comment Wikipedia's own guidelines for accessibility recommend avoiding red-green contrasts because of color-blind readers. Coppertwig's post of 02:01, 23 August 2008 suggests orange or pink. Cwilsyn (talk) 11:29, 28 August 2008 (UTC)

• Comment Oppose until
  ^{[omg plz]}
   18:59, 28 August 2008 (UTC)

• Oppose until we can come up with a better system for interwikis, as there's no easy way to do this in the software, it would put a massive load on the interwiki bots and clutter up wikitext for minimal benefit to readers and editors. Mr.Z-man 17:06, 1 September 2008 (UTC)

I am proposing that mms: links be added to the MediaWiki Protocols, so they will appear like any other outside link. For those who don't know, mms: links normally go audio or video streams. As a member of

Again, my proposal is that mms: links be added to the MediaWiki Protocols. Thank you...NeutralHomer • Talk 06:46, 27 August 2008 (UTC)

Hmm...sounds like a reasonable idea but will that not lead to possible security risks? mms:// links are handled by Media Player on Windows and it would make it easier to slip in some modified file that installs a virus imho. Also, will that not make it easier to access streams that stream copyrighted material? SoWhy 20:45, 27 August 2008 (UTC)

I am not sure about the virus/security risk point you brought up. Maybe someone else can answer that one?

As for the copyrighted material, I don't think it would be an issue. Mostly what this would allow, is the linkage to radio (or television) station streams who wish to broadcast via just an mms: link. Some stations with use mms: (Windows Media) along with a .mp3 or .pls link (WinAmp)....but some don't. It could be tried on a case-by-case basis to make sure nothing bad or copyrighted was getting linked to, but I don't think it would be an issue. - NeutralHomer • Talk 07:04, 28 August 2008 (UTC)

Open a bug report (Product: Wikimedia, Component: Site Requests) asking mms:// to be added to the list of $wgUrlProtocols. ^

^{[omg plz]}

 18:54, 28 August 2008 (UTC)

I don't particularly like the idea of supporting proprietary formats like that. I don't have a problem doing it with streamed

Ogg Vorbis, though. Celarnor ^{Talk to me}

03:11, 29 August 2008 (UTC)

mms:// itself is not proprietary, it's just a protocol rollover URL (see

RTSP as the actual protocol. mms:// itsef can stream any format and thus is not a problem of propriety. SoWhy

09:13, 29 August 2008 (UTC)

The URI itself, isn't what bothers me, since as you said, it isn't limited to streaming proprietary formats, its the fact that people want to use it to stream proprietary formats with it. As long as we require that the audio stream be of an open format, I'm fine with it. Celarnor ^{Talk to me} 21:06, 30 August 2008 (UTC)

I do not see how we could. There is no way to check that automatically... SoWhy 22:17, 1 September 2008 (UTC)

I suppose this is as good a place as any, but I have a good idea. Originally thought of by

I think that will create unnecessary traffic, the bot would have to edit 2 million and more articles. Also, the change to the MoS guideline is only 4 days old and will surely be discussed further before being accepted as consensus. And MoS is only a guideline, not a policy. So I'd advise against such a bot, at least(!) at the current time but I think a bot to edit 2 million pages will never be a great idea... SoWhy 11:59, 29 August 2008 (UTC)

I agree, there's no rush, the MoS isn't critical. If this is really what's supposed to be done, it might be something to add into

WP:AWB's general fixes, but a bot to make hundreds of thousands of, or possibly over 2 million, arguably trivial edits to enforce 1 section of a guideline is unnecessary. Mr.Z-man

12:50, 29 August 2008 (UTC)

Is that MOS novelty stable? The history page looks like... you name it. Don't hurry. There is no stable MOSNUM right now (if it were, why would anyone protect the page from editwarring)?

NVO (talk

) 00:43, 30 August 2008 (UTC)

The edit warring is over the date-autoformatting, so no, no bot at this time. There is a script lying around somewhere that does it: Tony1 uses it. Woody (talk) 01:04, 30 August 2008 (UTC)

I thought the idea of removing auto-formatting was to remove dates that were effectively irrelevant to the article. How would a bot discriminate between those dates, and the auto-formatting dates that are actually useful? Deamon138 (talk) 01:22, 30 August 2008 (UTC)

It's still controversial. Having a bot force through the changes will create aggravation. Maybe in a year or so when this has stabilised. --Apoc2400 (talk) 11:33, 1 September 2008 (UTC)

There are now ample number of categories in the system so system should discourage creation of page without a category (I am not talking here about adding stub categories, one may add them but every page should have at least one non-stub category). Uncategorized pages/stub categorized pages typically gets lost and are not maintained till someone finds them and puts them in a proper category.

The system needs to allow people to save pages without categories instead of encouraging them to add just any random category so the page will save. To have categorization experts use

uncat}}) is better than forcing newbies to even attempt to understand our categorization system. Kusma (talk

) 13:41, 29 August 2008 (UTC)

If the system was so good then we shouldn't be having thousands of uncategorized pages, also since new page creation is only allowed to registered users they can be easily mentored in doing so by new page watchers who normally check for copyright and notability part then why not for missing category, either they them self add it or ask the page creator to search for a suitable category and assign it. Page creator can be trusted to add a somewhat relevant category say a Football players page is created we can assume the broadest category that will get added will be 'Football' or 'Football Players' or 'Country' to which the player belong, then other users who typically likes to maintain category will (like me) will move it to more narrower and more relevant category. Pl note I haven't said not allow page to be saved but within 2-3 days we should have a category. This should be added to guideline for new page watchers to look for category as well apart from Copyright and notability part.

talk

) 14:03, 29 August 2008 (UTC).

Okay, that makes sense. I just wanted to make sure that the categories should not need to be added by the page creator. Any new page patrollers should at the very least add {{

WP:NPP already says that). Kusma (talk

) 14:08, 29 August 2008 (UTC)

I don't thing adding {{

talk

) 14:35, 29 August 2008 (UTC).

the system so system should discourage creation of page without a category - no, it should encourage the creation of pages with categories. Perhaps messaging creators of new pages thanking them for the pages and suggesting that they might add categories if the page has gone unedited for an hour or thereabouts (implying they're not still working on it, and it's not been speedied)? Pseudomonas_(talk) 15:41, 29 August 2008 (UTC)

Yes this is a subtle but important difference. Plus, surely it's a bit

crystal-balling to suggest that every notable article created in future will always be able to be categorized in current categories. That isn't necessarily so. In fact, I contend that the future usually brings new things different to the past, so old categories may not be good enough for future articles. Deamon138 (talk

) 01:29, 30 August 2008 (UTC)

There are bots marking pages lacking categories and people who specialise in adding categories. If an editor chooses to focus on writing the article and leave categorization to others, we should not discourage that. --Apoc2400 (talk) 11:31, 1 September 2008 (UTC)

On a category page one can expand subcategory and can expand it further if it subcategory have some categories belonging to it and so on why can't system show the pages belonging to the subcategory as well, does it have something to do with circular categories (can someone tell me this as well why we support circular categories).

The reason we support circular categories is efficiency. Its easy to tell if a subcategory has its parent category as a subcategory, but there is no limit to the size of a category tree. Checking whether the subcategory of a subcategory of a subcategory of a subcategory of a subcategory of a subcategory of a subcategory of a subcategory of a subcategory of a subcategory of a subcategory has the parent of the highest level subcategory as a subcategory is going to be difficult, as there could be thousands of other subcategories branching off from each one. Mr.Z-man 15:33, 29 August 2008 (UTC)

1. Categories do not form a tree. 2. If you want to show pages in a single instance (not side-wide), you can use mw:Extension:CategoryTree, as demonstrated below.

People from Tarn-et-Garonne

Hope that helps. -- Quiddity (talk) 18:37, 29 August 2008 (UTC)

I can browse a category (including pages) using

talk

) 06:59, 1 September 2008 (UTC).

I think we could use a bot that adds the welcome template to new users' talk pages. Currently, there are many users that never see the useful information that the template includes until after they are blocked for violating policies they didn't even know about. The bot would add {{

This has been rejected several times in the past: Wikipedia:Perennial proposals#Use a bot to welcome new users. Algebraist 20:45, 30 August 2008 (UTC)

Sorry about that.

(Messages)

20:55, 30 August 2008 (UTC)

The objective here is not to make a lot of edits or to turn every user_talk link blue, but to make new users feel "welcome" and point them to basic information so they can learn how to contribute (granted, they may already know). There are more efficient ways to do this:

• MediaWiki:Welcomecreation is the message each user sees after creating an account. Much or all of the {{welcome}} template material should be merged here.
• MediaWiki:Noarticletext displays a different message depending on the namespace. A friendly welcome message could be added to the one for user_talk. This would appear as a placeholder for their talk page until somebody leaves an actual comment.

I would prefer to know which users have not received any actual messages by seeing that their talk page link is red. — CharlotteWebb 13:17, 31 August 2008 (UTC)

Other wikis use a MediaWiki extension that acts as a bot of sorts that welcomes new users.... --MZMcBride (talk) 06:02, 2 September 2008 (UTC)

Which can be quite annoying at times. I sometimes view Wikipedia in other languages to make sure interwiki links are correct; since I've got a SUL account, this creates a user account on that language. Recently, I got an email from the Turkish Wikipedia that I think was an automated welcome message, but since I don't read the language, I can't be sure. --Carnildo (talk) 20:15, 2 September 2008 (UTC)

I recently received an email from the Romanian Wikipedia. I've got a talk page, too, which is not much use to me, since I don't know a word of the language. Gwinva (talk) 22:41, 2 September 2008 (UTC)

I propose that

I frequently find myself tempted to commit vandalism,

It would degrade the reputation of the encyclopedia somewhat, and also encouraging vandalism would mean a lot of cleanup after the day's over. We have subtle jokes on April Fool's Day, but outright vandalism would be, in my opinion, a poor idea. Wikipedia is about the visitors, not the regulars, and most visitors just want to read. PeterSymonds (talk) 17:18, 14 August 2008 (UTC)

Unless you want the sites servers to crash, then definitely not. D.M.N. (talk) 17:25, 14 August 2008 (UTC)

Well, if we kept all of the vandalism in the alternate article, cleaning up would be a trivial matter of deleting the alternate article and returning the official link to the actual article. People are already distrustful of Wikipedia, and many, if not most, academic organizations won't allow it as a primary source, so I don't know that a very overt event would necessarily degrade Wiki's reputation...

In addition, only a few articles would get "alternate articles". No one's going to bother vandalizing CTTNBP2NL, so I don't see that it would overload the servers. AzureFury (talk | contribs) 17:33, 14 August 2008 (UTC)

Why not just use the

(Messages)

19:51, 14 August 2008 (UTC)

It would defeat the point of April Fool's Day if someone had to actively seek out a hoax. AzureFury (talk | contribs) 20:53, 14 August 2008 (UTC)

and it would defeat the object of wikipedia if we actively encouraged people to deface it--Jac16888 (talk) 21:02, 14 August 2008 (UTC)

I seem to recall some banning and de-sysopping on the last April Fools. --—— Gadget850 (Ed) ^talk - 21:05, 14 August 2008 (UTC)

No one was desysopped or banned IIRC, but several admins were blocked by others who had a sense-of-humour-failure at seeing "Welcome to Wikipedia, the free pokemon encyclopedia" at the top of every page (and about 300 google caches!). Happy‑melon 21:23, 14 August 2008 (UTC)

(e/c)Don't quote me on this as I might be wrong, but I believe the general consensus after this past April (when a few admins got blocked) was that as long as its only seen by the Wikipedia community and not the general public, its fine. Jokes in user/wikipedia-space and parts of the interface only seen by admins == fine. Jokes in articles and parts of the interface seen by everyone == bad. Mr.Z-man 21:25, 14 August 2008 (UTC)

Vandalism is never necessary, even on April Fool's Day. April Fool's jokes should be subtle and clever as well as funny; simple humour or vandalism is little better than run-of-the-mill defacement that we see, and revert with such prejudice, all the time. Happy‑melon 21:23, 14 August 2008 (UTC)

"April Fool's jokes should be subtle and clever as well as funny" is true but also illustrates the dangers - some people will be fooled, and others will be outraged. -- Philcha (talk) 22:52, 14 August 2008 (UTC)

No, by this he means like what we do with the featured image, article, and DYKs: real, but hard to believe, a la Ripley's Believe It or Not. Melon isn't meaning for us to put in hoaxes. bibliomaniac15 23:06, 14 August 2008 (UTC)

And the things like fake RfAs and RfBs, some of the reactions to the

delete the USA, etc etc... things that make you laugh, but that are actually very clever underneath, and ideally relevant to the current global or wiki political situation. Just adding "Woo April Fool's Day" or low-profile misinformation to as many articles as possible is childish and destructive. Happy‑melon

13:12, 15 August 2008 (UTC)

This proposal can always be done in Userspace. If someone wishes to copy and have a humorous version of an article in their Userspace for a period of time they can. Keep in mind that vandalizing probably wouldn't be as fun if it isn't the real article, so I can't see "dummy articles" helping much. But you can vandalize your own Userspace as much as you want to. ~ JohnnyMrNinja 23:41, 14 August 2008 (UTC)

Sounds like what we need is an alternative to the Wikipedia Signpost ... maybe the Wonion, or Wikipedia (Go) Postal, or The WikiManiac. The first issue could be 1 April 2009 and it could be persistant, but maybe only published on each full moon, with a special extended issue on each successive 1 April. Something like that might let people blow off steam in a funny but marginally edited way. Contributions could be via methods parallel to the Signpost mechanics. --User:Ceyockey (talk to me) 04:17, 15 August 2008 (UTC)

P.S. An accompanying "Hall of Mirrored Articles" could also exist that would allow GFDL-compliant article copy with subsequent mangulation by one or a mob. --User:Ceyockey (talk to me) 04:20, 15 August 2008 (UTC)

Hall of mirrored articles sounds like the right crazy idea for the right crazy day. A group of right crazy noble vandals can start the hall and that Wikipedia Postal or Wikipedia Post-it or Wikipedia Postman or whatever can sound a mating call to all other right crazy geeky people to join in. Ah! Already my fingers are itching to type out the first right crazy mirrored articles. Aditya^{(talk • contribs)} 05:25, 15 August 2008 (UTC)

That sounds like it would be fun, and a good solution to objections that encouraged vandalism would hurt Wiki. AzureFury (talk | contribs) 06:45, 15 August 2008 (UTC)

How about you just go and edit uncyclopedia on April 1? --Boring (old fart) 10:53, 15 August 2008 (UTC)

Or you could just wear a funny hat instead. --Slashme (talk) 11:18, 15 August 2008 (UTC)

I think any humorous "vandalism" should be done in a subpage of your userpage. This should then be linked to on either a subpage of

Personally I am opposed to any kind of April Fools Day shenanigans on Wikipedia, unless on user pages. Some might say, "But what about a small joke?" Well no, humour is subjective, and anything you might find funny others might find offensive or boring. I think that Little Britain was the most unfunny thing I have ever seen, but that didn't stop it winning awards.

Others might say, "But we work really hard during the year, how about a day where we can unwind?" Well sorry to be a killjoy, but Jimbo didn't invent this encyclopaedia for you to unwind. In fact there's a whole real world out there where you can unwind: take a wikibreak if you need to unwind so much.

Also, April Fools' Day is an example of Western bias: people from other parts of the world don't have a clue what it is, and would trust the information just as much as on any other day. That's not fair to them, just as vandalism isn't fair to anyone normally. In fact, if an act is frowned upon/punishable on every other day of the year, then it should be on April 1st too. The day should be treated like any other day.

If you need humour so bad on April 1st, then you're in the wrong place. Deamon138 (talk) 22:51, 21 August 2008 (UTC)

Jeez, it was just a suggestion I thought would be fun. It won't work, it doesn't have consensus, I get it. AzureFury (talk | contribs) 06:10, 25 August 2008 (UTC)

Erm, I believe I have every right to comment on a discussion if I have an opinion, regardless of whether consensus seems to be for my view or not. Deamon138 (talk) 01:12, 29 August 2008 (UTC)

How about a Willy on Wheels day instead? Where, in talk pages and edit summaries, sentances end in "on wheels"! It would be fun! Tutthoth-Ankhre (talk) 16:31, 2 September 2008 (UTC)

Or someone could set the server to reset after

I suggest to add a silver star for Good Articles in foreign languages (mostly as we have a gold star for FA with Template:Link FA). Several other wikipedias already do it. Poppy (talk) 22:12, 30 August 2008 (UTC)

I think that would be the same proposal as Wikipedia:Perennial proposals#Indicate Good Articles to readers. In other languages or in English, the problem would always be that the GA status is not community reviewed / consensus-based. SoWhy 22:43, 30 August 2008 (UTC)

In the French & German wikipedias (for example), it is. Not sure for others (no consensus in Spanish, consensus in nn). Maybe it would be possible to limit the star to the wikipedias "electing" their GA articles. Poppy (talk) 22:58, 30 August 2008 (UTC)

Hmm, if that's so, I think it could be a good idea, maybe even using the icons those projects use (for example in de-wiki). Of course it should only be done for those projects where the assessment is similar to our FA assessment. But I like the idea for those cases :-) SoWhy 23:22, 30 August 2008 (UTC)

We already star the interwiki links to each alternate-language version; isn't that enough? A silver star on the article would seem to the average user to indicate quality of that article, not of other articles. No offense meant, but I don't see how this proposal would add much except confusion to the user experience. {{Nihiltres|talk|log}} 02:59, 31 August 2008 (UTC)

I like the idea of starring the cream of the crop for foreign projects, but I don't think we need to point out every single gradation of quality. EVula // talk // ☯ // 04:05, 4 September 2008 (UTC)

Many websites now have spell checkers. Because Wikipedia does not, I have to look up words on Wiktionary when I'm not sure if I'm spelling them correctly. I see IPs and newly created accounts misspell words all the time. I believe that the addition of a Wiki spell checker would reduce this problem.

if you use Firefox or have the google tool bar you have a spell checker built into your browser, the only problem is that you have to use it, I think it would probably be the same thing with a wikipedia spell checker, even though it's there people probably won't use it. Redekopmark (talk) 06:06, 27 August 2008 (UTC)

I dun ned a speel cheker. Celarnor ^{Talk to me} 06:09, 27 August 2008 (UTC)

The is-you whiff spell chequers is that their naught vary good at knowing when pea-pole arr you-sing whirr-tssss in-core-ect-lea! That, and there’s the serious problem on a wiki as broad as this, with words that are deliberately ‘wrong’: see teh. Happy‑melon 11:56, 27 August 2008 (UTC)

Not to mention that the Firefox spellchecker seems to be region-dependent, where Wikipedia isn't. Words like colour, tyre, and programme are spelled wrong, at least as far as my USA-version of Firefox is concerned. Mr.Z-man 20:42, 27 August 2008 (UTC)

I don't use Google Toolbar or Firefox. I do use Earthlink Toolbar because it's way better than Google or Yahoo's in my opinion, and I do use Internet Explorer 7. Also, it probably wouldn't be a good idea to download such applications onto shared terminals such as the ones at school and at mom's work. I'm sure I'm not the only one that is not using Google Toolbar or Firefox. You mentioned the fact that most spell checkers have a lot of glitches, and that would probably be a good thing to remember if and when a Wiki spell checker is created. I was thinking something that is editable, meaning words could be added or removed. Also, there are some of these checkers that can detect grammer errors, and that would be a great idea if we did create a wiki spell checker.

(Messages)

22:25, 27 August 2008 (UTC)

have you looked at portable Firefox ? just stick it on a USB device and your golden, when I travel its what I do. (in fact my main browser at home is FF3 portable) it makes internet usage so much easier.

β^_command

23:37, 27 August 2008 (UTC)

I think aforementioned opposes are reasonable. If you make mistakes, you should get Firefox and use it's spell checker, it's built-in. I use it all the time and I rarely make spelling mistakes. A spell-checker on Wikipedia would be very resource-hogging, if it was loaded with every edit field. I don't think there is any need because IPs and newbies, as well as experienced editors, will make mistakes if not careful. And a spellchecker will not fix that. I think you should rather have a system like the German Wikipedia that does not allow IPs to save pages directly but forces them to preview first... SoWhy 22:49, 27 August 2008 (UTC)

You can easily install extra language packs for Firefox's spell checker if you want them,[1] and you can choose which to use from the right-click menu. Anomie⚔ 23:06, 27 August 2008 (UTC)

Thank you Anomie for this link! Deamon138 (talk) 23:18, 27 August 2008 (UTC)

What about the millions of Wikipedia editors that use shared terminals and are not authorized to download browsers, toolbars, and other crap?

(Messages)

23:38, 27 August 2008 (UTC)

Thank go I dont have that problem as a mac user who cant spell, I benefit from universal spell checkTdk12 (talk) 16:59, 28 August 2008 (UTC)

Good thing all the shared terminals I use are properly configured with an operating system that separates the userspace and system space so I can download any software that I want to as long as it doesn't edit files outside of my /home/ and /usr/ directories. Of course, said operating system already has free and open source support for spellchecking ... Celarnor ^{Talk to me} 03:07, 29 August 2008 (UTC)

Okay, but I'd like to see somebody try to download something onto or attempt to use a USB device with

(Messages)

20:50, 30 August 2008 (UTC)

Really? Your school doesn't permit USB flash drives? How are students supposed to save their work? —Remember the dot ^(talk) 21:04, 30 August 2008 (UTC)

Err, there is no school that I know of that'll allow USB drives - fear of viruses and all that. Work is saved on network drives. _TalkIslander 21:06, 30 August 2008 (UTC)

So if you want to work on something (like an essay) outside of school? My high school encouraged the use of floppy disks (and later flash drives) for saving work. If they're that paranoid about viruses they shouldn't allow internet access either. Mr.Z-man 17:10, 1 September 2008 (UTC)

Yeah, I don't really understand where these schools are. At my high school, we could use flash drives, burn cds, use external hard drives; hell, we could all mount the schools fileserver from home via

sshfs, or do X11 forwarding and work on the schools computers from home... and it mostly administrated by students. Granted, there were other schools around that weren't so technologically literate, but I've never seen anything where you can't at least mount things... Celarnor ^{Talk to me}

18:35, 1 September 2008 (UTC)

(somewhat off-topic) OK, when I say I know of "no" school, I'm talking about the two schools I've personally been to, and the dozen or so others that my friends tell me about (all in UK, fyi). Hardly the best selection for a fair, unbiased comment :P. However, at all of these schools, floppy's and USB drives were very strictly off-limits, and the use of them would probably result in your network account being closed. There's not really any need to move work to and from school - school work and home work tends to be separate, though obviously along the same topics. When it did become necessary at my school, there was a system called Easylink, where you could upload your files to the school servers where they'd wait in a queue for virus checking, and then pop into your home directory. Same could work in the other direction. I won't for a second deny that it was paranoid and over the top - now I'm at university where such pointless restrictions don't exist - but these restrictions were in place at my school and my friends schools, and are common around here, and so it wouldn't suprise me at all to learn that any school has these restrictions. _TalkIslander 22:14, 1 September 2008 (UTC)

I'm also from the UK, but all the schools I've come across effectively encouraged the use of USB drives. I am glad I didn't go to the schools you went to! Deamon138 (talk) 18:35, 4 September 2008 (UTC)

It never ceases to amaze me how technologically backwards and ignorant many K-12 administrators and techs are. Before I left high school, I worked as a service intern doing contract call-outs to area schools...they actually used Windows and IE in production environments, like for regular every day work. I managed to get most of them to upgrade to more secure browsers once I explained the dangers and problems with IE; 2 of them ended up changed to full-out

Citrix solution. I'm kind of ashamed that my tax dollars fund that kind of crap. Celarnor ^{Talk to me}

20:59, 30 August 2008 (UTC)

Bah! The British English dictionary add-on for Firefox doesn't work. Looks like I'll ave to make do with the American one. Nm. Deamon138 (talk) 20:15, 28 August 2008 (UTC)

<undent> IMDb has a spell-checker and it works just fine. Wikipedia needs one, there is no doubt about that. These days a buit-in spell-checker is a fairly standard tool for saving time when multiple users collaborate on a database. If you doubt me about IMDb, sign up and write a comment on a movie that you like. Test the spell-checker. See how easy it is to use, and how adaptable it is with respect to British versus USA versus slang spellings. Love it! Please buy Wikipedia a spell checker for Christmas! cat yronwode a.k.a. "64" 64.142.90.33 (talk) 08:02, 3 September 2008 (UTC)

I would like to propose the creation of a namespace for lists. They're kind of like a category, kind of not... I would feel better if a special area were reserved for them.

This is a good idea that I'd support. It is definitely possible to make new namespaces, and a list namespace would be a good choice. -- Imperator3733 (talk) 02:59, 3 September 2008 (UTC)

This would also provide an area for growth. In the future Wikimedia might be able to provide list content from category intersections. I.e., you'd be able to draw upon the power of the existing category system and have all the styling options currently available to templates.

talk

) 07:07, 3 September 2008 (UTC)

See also: User:Shyam/List Namespace. - jc37 07:36, 3 September 2008 (UTC)

So something like List:The Simpsons episodes instead of List of The Simpsons episodes? Excuse my question, but where exactly is the change in that? Those List: will work exactly like articles, won't they? SoWhy 09:35, 3 September 2008 (UTC)

Definitely read the whole User:Shyam/List Namespace thread. Most of the prior proposals and objections are mentioned there.

For the hypothetical/potential future uses concept, I think you might have something like mw:Wikidata in mind? But as it currently stands: Lists are not databases (though if Wikidata ever takes off, many of the lists will essentially end up being transferred to the databases). Disclaimer: I know nothing about the current state of Wikipedia:Category intersections, or what relevance that might have to this proposal. -- Quiddity (talk) 20:15, 3 September 2008 (UTC)

Yes, WikiData seems to be what I want and more. Thanks for bringing it to my attention.

talk

) 22:25, 3 September 2008 (UTC)

Lists are encyclopedia material, hence they're in the main encyclopedia namespace. I don't particularly see a reason they should be spun out to another namespace... EVula // talk // ☯ // 04:03, 4 September 2008 (UTC)

A "List:" namespace is confusing to those readers who don't know what a namespace is. It is much more obvious to type in "List of..." than "List:..." when looking for a particular list. I prefer them in the article namespace. Deamon138 (talk) 19:09, 4 September 2008 (UTC)

I see your point. As a parallel example, searching for "category of fish" does not lead one to

talk

) 01:56, 5 September 2008 (UTC)

I made this proposal on the mailing list a long time ago, but it just went unnoticed. Let's see if I have some better luck here :)

The problem:

• You have to be very technical and knowledgeable to understand the "edit conflict" screen.
• The majority of people are intimidated by this screen. They will either try to go back and submit their edit again (which just triggers the same conflict again) or they will give up and we lose their contribution.
• Even very patient users who try to cope with an edit conflict may do so incorrectly because it is so difficult. Occasionally this leads to animosity if the user inadvertantly reverts someone else's edits. The edit history shows no trace of there having been an edit conflict.
• The result is lost productivity as well as potential conflict between users.

My proposed solution:

• There should be no Edit Conflict screen. Instead, the article should be saved in a way that reflects the edit conflict.
• For example, if the sentence "He is a world-reknowned artist" is corrected by one editor as "He is a world-renowned artist" and by another as "He is a world-famous artist", the article would now show something like, "He is a EDIT CONFLICT: [world-renowned] [world-famous] artist".
• With the edit conflict now visible to everyone, anyone can make an attempt to fix it. The burden no longer lies with the person who encountered the conflict.
• The conflict is now confined to a small space. You no longer have to face the entire article, potentially pages long, to fix a single-word error like this.
• Even though an edit conflict could potentially leave a sentence or a section in somewhat of a mess, the same is true of any edit by an inexperienced user. It is no harder to fix than inexperienced edits or indeed vandalism.
• Experienced users who run into an edit conflict will fix it themselves immediately after noticing it. Therefore it is no different to them than the current system, but it is vastly better for inexperienced users.

Comments? — Timwi (talk) 13:50, 3 September 2008 (UTC)

No thank you, this would make dreadful mess of rapidly changing discussion pages. I think we are in fact better off losing edits from inexperienced editors than having all editors introduce a lot of conflict tags into the permanent record of documents. That said, the conflict resolution process should be improved. For example the conflict screen should only return the current section when the conflict is confined to that section. Dragons flight (talk) 13:59, 3 September 2008 (UTC)

Let me separate those two arguments from you. — One is about discussion pages. I think discussion pages need a fundamental rethink anyway; currently LiquidThreads is the most prominent alternative. The talk-page system just doesn't work for discussions. Edit Conflicts most definitely shouldn't apply to discussions. — Your second argument claims that a substantial number of edit conflict tags would be generated which would not be resolved; do you have any evidence to back this up? My experience on Wikipedia is that such errors are generally fixed rather quickly, and where they aren't it's generally on not-so-popular pages which aren't seen much anyway. — Timwi (talk) 14:57, 3 September 2008 (UTC)

(edit conflict haha)There is currently a discussion about the edit conflicts system, [2]. As for this idea, it only addresses minor edit conflicts like the example you gave, what if, for example, an article gets vandalised, e.g. LOLZ is added to it. Another user tries to remove this but edit conflicts with the vandal adding GAY!!!! to it, its quite common to ec with the determined vandals. What would happen then? would it not say ......EDIT CONFLICT: [LOLZ][][GAY!!!], which is hardly a desired outcome, particularly if the good user is unaware the conflict took place. without the ec page, a user would assume that their edit was saved--Jac16888 (talk) 14:00, 3 September 2008 (UTC)

Looks like you misunderstood my proposal. You said: would it not say ......EDIT CONFLICT: [LOLZ][][GAY!!!]. No, it would say "EDIT CONFLICT: [... the entire article ...] [GAY!!!!]". The tag at the top and the vandalism at the bottom would be hardly noticeable to casual readers, and the article is still there and perfectly readable. — As for your other argument, I don't think it matters that they think their edit was saved; in fact, their edit was saved, just with the edit conflict tag added to it. All other users will see that edit conflict tag in the diff for this user's edit, so someone will very likely fix it very quickly. — Timwi (talk) 14:57, 3 September 2008 (UTC)

We need to minimize any "behind the scenes" activity that occurs in mainspace. Boxes like {{cleanup}} are one thing as they encourage readers to participate despite the fact that there are issues with WP policy/guidelines/MOS behind it, but when you indicate something like this that may be very difficult for new editors to resolve out, it makes it obvious of what goes on behind the scenes without encouraging editors to help. And, if other editors are like me, having the EC page as it comes up now is helpful to recognize that the edit didn't take before we go back to the watchlist or whereever else we were working. Without the EC page (using the Preview feature to make sure the formatting was correct), I'd assume all was well and go off to the next task. --MASEM 15:24, 3 September 2008 (UTC)

If editors generally prefer to be explicitly alerted to edit conflicts they run into, this can always be done by displaying the Edit page (as opposed to the article) with an "Edit Conflict" heading, while still saving the page in the way I suggested. — Timwi (talk) 15:45, 3 September 2008 (UTC)

A few problems with this. One, the user who gets the edit conflict still has to resolve it, but now they have to make 2 edits. Two, it only works for simple edit conflicts. What happens if I rewrite a whole section of an article, and edit conflict with someone who moved the section to a different place in the article? Currently its easy to fix. I copy my section from the "My version" version and paste it into wherever the other user moved the section, replacing the old section. But with this, there's going to be "EDIT CONFLICT" and brackets all over the place. Mr.Z-man 16:16, 3 September 2008 (UTC)

I don't even agree that you have to be a technical person to understand "2 people tried to edit this at the same time; this is what you tried to save, this is what they saved". That's pretty simple. As it is now, its relatively trivial to fix edits conflicts as long as you read the edit conflict page that is presented to you. This proposal seems like it would be very problematic for interlaced edit conflicts and would result in brackets and edit conflicts all over the place. I'd rather lose an edit from someone that can't figure out to cut and paste things than clean up after them. Celarnor ^{Talk to me} 16:37, 3 September 2008 (UTC)

I'm amazed you are claiming that it is "trivial" to fix edit conflicts. You are presented with two big thumping textboxes, and you have to find (1) the right place in the second textbox to copy from; (2) the right place in the first textbox to paste to. And this is assuming you know which box is which in the first place; most people get confused between them. — Your theory regarding "brackets and edit conflicts all over the place" requires very frequent occurrence of edit conflicts, which I'm not convinced there is any evidence for. — Timwi (talk) 17:27, 3 September 2008 (UTC)

The proposed solution takes a situation that individuals currently deal with and just leaves it for someone else to do. We can't afford to have an edit conflict backlog, we all need to resolve our own edit conflicts.

Chillum

16:53, 3 September 2008 (UTC)

This is delusional. There is no evidence to suggest that everyone resolves edit conflicts successfully, not even close. Additionally, you're postulating a hypothetical "backlog" but I don't see how this proposal generates one. — Timwi (talk) 17:27, 3 September 2008 (UTC)

There's no evidence to suggest that anyone doesn't resolve edit conflicts successfully. This is a solution looking for a problem. Celarnor ^{Talk to me} 22:45, 3 September 2008 (UTC)

(e/c)Except in the example you gave in the initial proposal, it would be trivial to fix, and in a complex edit conflict, it still wouldn't be easy, as there would be a mess of brackets, repeated text and "EDIT CONFLICT" all over the page. The current interface explains what happened and what to do. It then shows the normal edit box, then a diff between your edit and the actual page, then shows the text of the page from your edit so you can merge it. The proposed system would leave a cryptic note in the actual article text and hopes that the editor sees it and knows what to do. We shouldn't change a working system just because people don't want to read the instructions. I got an edit conflict when posting this, if the proposed system was used, mine and Celarnor's comments would be wrapped in brackets and I'd have to make an additional edit to sort it out, instead of just copying my comment from the bottom and pasting it back in. Mr.Z-man 22:48, 3 September 2008 (UTC)

I agree with the last three comments,

Chillum because it creates more work for others. Sswonk (talk

) 16:59, 3 September 2008 (UTC)

Just because you understood edit conflicts the first time (as did I) doesn't mean everyone else does. Additionally, I don't see how it creates more work. I'd argue it saves a lot of work: Someone might provide information (or a source) which would take you hours to find; if they ignore their edit conflict and leave the site, you will never see any of it and you will have to spend those hours to find it. — Timwi (talk) 17:27, 3 September 2008 (UTC)

(ec)It creates more work because rather than doing what we have now ("Oh, edit conflict" ... *Highlight, ctrl+c, move mouse, ctrl+v, alt+enter*, rather than "Oh, edit conflict" ... *Click edit; wait to load, find the conflict, remove, restore, commit) is simpler, both in terms of interface and the fact that it doesn't damage the page and cause extra revisions and database queries that we certainly don't need. Celarnor ^{Talk to me} 22:45, 3 September 2008 (UTC)

Edit conflicts do suck. I hate them with a passion. I agree that they are not very "friendly" especially to new users, but the proposed fix here will not work for the multiple reasons stated above. I could see a push for a change in the way edit conflicts are handled (or, more appropriately, displayed to the user). If anything, I wish that the "new" edit box that comes up after an edit conflict would display only the section you were working on and not the whole article ... nevertheless, I cannot see this as being a workable fix. Shereth 22:31, 3 September 2008 (UTC)

I was just about to say almost exactly that. There is a problem, but this isn't the solution (mainly because it would be horrible with large changes). Getting sections to work nicely would be great, but I'm not sure of a solution to the problem which stops them being used now - it's very difficult to handle the situation where the section structure changes somehow in one or both of the edits. There probably is a solution to that problem, but not an easy one. --Tango (talk) 22:40, 3 September 2008 (UTC)

In my humble opinion, the better way of dealing with edit conflicts is to display an edit conflict message and provide a suggested edit integrating the original and conflicting edits, or, if you like, a "