Wikipedia:Village pump (proposals)/Archive 34

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

Village pump (proposals) archive

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

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

Announcing - WikiProject Images and Media (possibly)

I have proposed renaming WikiProject Graphics to WikiProject Images and Media. The project was created a few months back as a "top-level" project for Image concerns on Wikipedia. It went inactive shortly after, which I feel is likely due to lack of attention. I figure a slightly more intuitive name and a broadening of the scope would make this in to a very useful top-level project, as image and media efforts are very scattered right now. Please weigh in on the talk page with regards to the rename. Also, if you feel that such a project could (at some point) be useful, feel free to join! Cheers ~ JohnnyMrNinja 05:57, 24 August 2008 (UTC)

What would the relationship of the WikiProject be to the following?

-- 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 Help:Contents/Images and media and Wikipedia:Images and media for deletion). I feel this is the most intuitive name for the purpose. ~ JohnnyMrNinja 06:37, 27 August 2008 (UTC)

(unindent) Some consolidation of image help and resources is here: Wikipedia:Graphic Lab/Resources. Links to various related WikiProjects, categories, resources, etc.. Feel free to add more in the "see also" section. --Timeshifter (talk) 21:52, 27 August 2008 (UTC)

IP talk pages

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 {{sharedip}} and the like) after an appropriate period of inactivity - such as 1 year. A request for this could be placed at 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 {{sharedip}}, and more importantly, {{dynamicip}}. I would also support the idea of removing contribs from an IPs record after, lets say it hasn't edited in a two years perhaps. GO-PCHS-NJROTC ^(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)

RfA wording change

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 WP:NOTNOW. NOTNOW basically tries to tell the new user that their RfA failed because they didn't meet the pre-requisites of the community.

Over the past several days, we've been discussing some minor changes at WT:RFA. The first change is merely a wording change. It is merely a wording change because it simply spells out something that is already a reality. 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 almost ~~ever~~ always be closed as WP:NOTNOW and thus should be avoided. Before running for adminship, one should be familiar with current expectations, which are generally much higher than the 1000 edit/3 month threshold.

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:SOCK#LEGIT). It would just allow them a fresh start without registering a new username. I think a G7 delete can be in order when the criteria of 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. So Why 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 WT:CSD. Specifically, it is not objective, it is contestable, and it does not arise frequently. If there is such a big need for these RFAs to be deleted, MFD them. Stifle (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:NOTNOW. I don't think anybody would contest it, and if they did, I'd point them to 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: 1 2 3 4 5 6 7 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... So Why 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 (...)? So Why 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:NOTNOW". That sounds like the very definition of minimum requirements. I am not particularly against minimum requirements per se, but I think it's a little differing to the spirit of 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. bibliomaniac 1 5 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 WP:NOTNOW. Potential candidates should further investigate the current (unofficial) expectations for Adminship which are generally much more strict than this. I think this gets the message accross that newbies shouldn't start an RfA without creating a minimum.---Balloonman ^PoppaBalloon 00:44, 23 August 2008 (UTC)

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)

Hidden templates in article prose

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 WP:LAYOUT and scrolling lists? See Elizabeth A. Smart and Template talk:Hidden#Within article text. SandyGeorgia (Talk) 00:00, 23 August 2008 (UTC)

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)

You Tube Videos

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? GO-PCHS-NJROTC ^(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)

Oppose - First, YouTube is not under a free license, and, how would this improve articles? Also please note that Wikipedia only uses open-source software, and YouTube videos require Adobe Flash, and Flash is not open-source. Macy 02:23, 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)

Semi-protect everyone's userpage other than yours

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 autoconfirmed users group).

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:UP. If vandalism strikes you, you can request protection at 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... So Why 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. Twas Now, I am making the assumption that the majority of unregistered edits to user pages are vandalism, as I am assuming here that anyone who either is in the business of designing others' user pages for them, or is interested in enforcing Wikipedia policy (e.g. 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)

Improve user experience and ergnonomy of Wikipedia

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. SharkD (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 lead section, and it is considered part of the article rather than something separate (although a good one should be useful on its own). You should be able to unify your fr and en accounts, at least if you use the same name on both. See 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. GO-PCHS-NJROTC ^(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)

Edit section links per fr and de Wikipedias

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? So Why 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)

de-wiki stuff: "Jump to edit window"-link on preview-pages and mandatory preview for anons?

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

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?
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? So Why 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. So Why 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. So Why 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)

Preventing discussions on user talk pages from being torn

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.

--Emaster82 (talk) 21:46, 29 August 2008 (UTC)

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

That's a great template I didn't know of.--Emaster82 (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 :-) So Why 22:48, 29 August 2008 (UTC)

New UK wikimedia chapter

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)

Effective collaboration: WP should encourage users to list their city on their user page

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 . Vjdchauhan (talk) 14:18, 28 August 2008 (UTC).

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. Ϣere Spiel Chequers 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. Vjdchauhan (talk) 13:25, 29 August 2008 (UTC).

What about people that live way out in the boondocks where the nearest town to them wouldn't meet WP:N? GO-PCHS-NJROTC ^(Messages) 20:45, 30 August 2008 (UTC)

Propose addition to MediaWiki:Anoneditwarning

I think we should add something to the top of MediaWiki:Anoneditwarning. Most of the edits that IP's make are unsourced, and most of the time a violation of WP:BLP. I think we should add a note to the MediaWiki:Anoneditwarning page, something like:

Please note your edits must not constitute of Original Research, nor must they violate Wikipedia's BLP policy.

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... So Why 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 Original Research, and also must not violate 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. So Why 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)

WikiProject naming convention being discussed

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)

Tweak to AOR

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)

Category watch should report addition/removal of pages from it

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. Vjdchauhan (talk) 14:57, 29 August 2008 (UTC).

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

Can this be moved to Wikipedia:Perennial proposals page, I am not sure whether I can do it or not. Vjdchauhan (talk) 06:17, 1 September 2008 (UTC)

Edit section: scrolling down to enter 'Edit summary' or to press 'Save page'

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. Vjdchauhan (talk) 15:09, 29 August 2008 (UTC).

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. Vjdchauhan (talk) 06:04, 1 September 2008 (UTC).

A good idea would be to use some magic to make the edit box size itself appropiately depending on the edit window's size or, like wordpress' blog post editor, make the window resizable on the fly. This wouldbenefit users with compatible browsers but (using the magic of <noscript>) keep people whose browser's do not the same as it always was. — ^.^ ^{[citation needed]} 04:40, 30 August 2008 (UTC)

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. — ^.^ ^{[citation needed]} 13:16, 30 August 2008 (UTC)

Access to 'Special:Unwatchedpages' for users with high edit count and good track record

Currently I think 'Special:Unwatchedpages' is accessible only to Admins (is it accessible for rollbackers, I am not sure), we should be a bit more liberal with granting access to this page, I know it needs some restriction else vandals will misuse it but for sure there are thousands of Wikipedians who have very high edit count and are not admins and may not/do not want to become one. Vjdchauhan (talk) 15:15, 29 August 2008 (UTC).

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. So Why 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. So Why 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. So Why 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)

Support, I am a rollbacker myself (although it is not affecting my opinion) and I think that these tools could go hand-in-hand in preventing vandalism. Although the request for rollback program might need to be strengthened to prevent the occasional smart vandal. — ^.^ ^{[citation needed]} 04:29, 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 !), I'd be happy to trawl through it and add a hundred or so pages to my watchlist - from which I currently catch all kinds of vandalism that escapes RC patrollers, especially the sneaky-vandal stuff. It's not so much that we need access to the special page, we just need someone to feed us suggested pages to watch. The Special:Unwatched... page could also have a note directing editors to the central page to request page-slates, and it would then be up to admins to judge the reliability of each user. Franamax (talk) 05:57, 30 August 2008 (UTC)

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... So Why 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)

Allow a usergroup to edit protected pages

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. Narutolovehinata5 ^tccsdnew 12:12, 30 August 2008 (UTC)

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. :-) So Why 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). So Why 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)

Software shortcut for college football and basketball teams

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 2007 Ohio State Buckeyes football season? Corvus cornix_talk 04:50, 31 August 2008 (UTC)

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)

Green Colored Words

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

French / (stub class)

Italian / (start class)

Russian / (B class)

....

....

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. So Why 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). So Why 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 missing article is indeed present in Bishnupriya Manipuri language wiki? It can not. Someone human has to do manually, right? But writing a concise stub would not take much longer (as Deamon138 pointed above, author still must show notability). What I suspect would be better is to accompany the stub with a notice that "A far better article exists in XX-wiki" (foreign FAs are already tagged via interwikis). NVO (talk) 23:03, 22 August 2008 (UTC)

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 bugzilla:14024 can be completed and made not sucky. ^demon^{[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)

mms: Link Proposal

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 WikiProject Radio Stations, I run into these all the time and it is frustrating that they can't be added.

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? So Why 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. ^demon^{[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 Microsoft Media Server) and Microsoft uses RTSP as the actual protocol. mms:// itsef can stream any format and thus is not a problem of propriety. So Why 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... So Why 22:17, 1 September 2008 (UTC)

New bot

I suppose this is as good a place as any, but I have a good idea. Originally thought of by User:LonelyMarble on my talk page, we should have a bot to unlink all dates Per Wikipedia:Manual of Style (numbers and dates). I don't have the technical ability to, but I'm sure someone will. Thanks. Mm 40 (talk | contribs) 11:49, 29 August 2008 (UTC)

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... So Why 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)

New pages should always belong to a category

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. Vjdchauhan (talk) 13:31, 29 August 2008 (UTC).

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 Special:Uncategorizedpages (or just {{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. Vjdchauhan (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 {{uncat}} (and WP:NPP already says that). Kusma (talk) 14:08, 29 August 2008 (UTC)

I don't thing adding {{uncat}} or 'stub category' is helping much, also if NPP can add 'uncat' then why can't they add/ask page creator to add a category. You are an Admin, may be you can push for modification of WP:NPP guideline for categorization. I will anyway put this in its talk page but given my experience with proposals, I am sure someone will justify the existing system even though it is ample clear that {{uncat}} or 'stub category only' pages are getting lost and they remain till someone finds them accidentally. Policy makers should not assume normal Wikipedians to take pain to go through thousands of 'uncat' pages explicitly and categorize them, page creation is best time to handle this i.e. nipping it in the bud. People like me whose main contribution to WP is page categorization at least wants the uncat pages to belong to certain fundamental uncat-categories (on lines of Category:Fundamental categories). Vjdchauhan (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)

Category Page: show pages belonging to subcategory(s) as well

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). Vjdchauhan (talk) 14:16, 29 August 2008 (UTC).

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 Special:CategoryTree or by putting 'categorytree' text on a page (article/category/talk etc as suggested by you) but I want similar thing to be available for me for all categories existing on Wikipedia on the category page itself without me going to Special:CategoryTree page or by putting 'categorytree' temporarily on a page. Any solution? Vjdchauhan (talk) 06:59, 1 September 2008 (UTC).

Bot that adds {{welcome}} to new users' talk pages

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 {{welcome}} to newly registered users' talk pages, and it would add {{welcomeIP}} to IP talk pages that recently edited for the first time. Comments? GO-PCHS-NJROTC ^(Messages) 20:42, 30 August 2008 (UTC)

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. GO-PCHS-NJROTC ^(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)

Extend category naming guidelines to cover list articles

I propose that Wikipedia:Naming conventions (categories) be broadened in scope to include list-type articles. SharkD (talk) 01:15, 3 September 2008 (UTC)

Vandalism Holiday?

I frequently find myself tempted to commit vandalism, humorously, not malevolently. Apparently, given the amount of vandalism I revert and see others reverting, I'm not the only one. I was wondering if on April Fool's day we could not only allow vandalism, but encourage it. Maybe create alternate articles with a template on the top explaining that it was an April Fool's joke and linking to the actual article. AzureFury (talk | contribs) 17:15, 14 August 2008 (UTC)

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 sandbox? GO-PCHS-NJROTC ^(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. bibliomaniac 1 5 23:06, 14 August 2008 (UTC)

And the things like fake RfAs and RfBs, some of the reactions to the Rickrolling AfD, trying to 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 WP:April fools or the "Hall of Mirrored Articles" idea. I think humorous or creative edits to articles should be encouraged, but only if they are separate from the real articles. -- Imperator3733 (talk) 20:15, 16 August 2008 (UTC)

No. To add to above comments: consider the burden of undoing April 1 mess. By the end of the day each prankster must manually undo the prank.. it won't work. NVO (talk) 18:32, 21 August 2008 (UTC)

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 april fools. LiteralKa (talk) 18:49, 3 September 2008 (UTC)

Add silver star for Good Articles in foreign languages

Hello,

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. So Why 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 :-) So Why 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)

Spell checker

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. GO-PCHS-NJROTC ^(Messages) 04:02, 27 August 2008 (UTC)

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. GO-PCHS-NJROTC ^(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... So Why 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? GO-PCHS-NJROTC ^(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 CCPS computers. That would be one of the quickest ways to get suspended. GO-PCHS-NJROTC ^(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. _Talk Islander 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. _Talk Islander 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 Edubuntu systems, and another one opted to use a 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)

Namespace for lists

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. SharkD (talk) 01:38, 3 September 2008 (UTC)

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. SharkD (talk) 07:07, 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? So Why 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. SharkD (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 Category:Fish. SharkD (talk) 01:56, 5 September 2008 (UTC)

Edit conflicts should not prevent saving the page

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, Mr.Z-man because of the clutter and the ease of the copy/paste method both he and I use, Celarnor because I understood what had happenned and what needed to be done the very first time and 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 "patch". – Thomas H. Larsen 07:07, 4 September 2008 (UTC)

IIRC, if the software can determine how to merge the conflicting edits, it does already and doesn't give an edit conflict screen at all. It's only when the conflicting edits make changes to the same portion of the page that it gives the edit conflict screen. Anomie ⚔ 11:33, 4 September 2008 (UTC)

Wikipedia:2008 main page redesign proposal

A contest is currently on-going for designs to update the main page. Entries have been narrowed down, and there is a need for wider community attention to judge the semi-finalists. Please visit the page, look over the proposals and leave your comments. Thank you, Jennavecia ^(Talk) 15:09, 4 September 2008 (UTC)

Language disambiguation pages

What do you think of this proposal? Someone told me that the same mechanism might be used in general to avoid to add a new [[xx:article]] link to all Wikipedia each time a new article is created in language xx.--Dejudicibus (talk) 20:49, 4 September 2008 (UTC)

Proposal: Wikinews Main Page Leads

A proposal to include links to 3 main page lead articles from Wikinews onto the Main Page on Wikipedia. They would be incorporated from User:Wikinews Importer Bot/Wikinews Lead articles into {{In the news}}. Please weigh in at Template talk:In the news. Cirt (talk) 20:40, 30 August 2008 (UTC)

Update: There has been some discussion and now there is a new idea/proposal. Please see Template_talk:In_the_news#Update_-_Proposal_for_Portal:Current_events. Thank you, Cirt (talk) 07:28, 5 September 2008 (UTC)

Automatic wikilinks

So much editing on Wikipedia is just to get links straight (link or don't link dates, when to link about a referenced word, etc.). The point, we all know, is so that the reader of the article has access to information that may not be common knowledge yet is required for comprehension of an article. So, why not just be a script that lets people link themselves? What I mean is that all wikilinks in the code would be removed, and rather people could do something like select text and right-click to search wikipedia for that. This would make the articles look much cleaner (without all the blue and red and underline) and people would have quick access to what they need rather than what most people need. It's a dramatic change and I bet people are going to reflexively say that it's a stupid idea or something, but I think it's good and so I'm throwing it out there. Althepal (talk) 23:42, 5 September 2008 (UTC)

I'm not sure that the code can do that. However, the main thing we'd lose from this is the ability to pipe links. Overall, I don't think it's worth the complete code overhaul to do it. Paragon ¹²³²¹ 00:31, 6 September 2008 (UTC)

It's not possible. You'd need to modify every web browser in the world in order to support this, including the ones that don't support "select text" or "right click". --Carnildo (talk) 01:39, 6 September 2008 (UTC)

That's the spirit. Thankfully every web browser in the world supports Javascript. Even if wikilinks are kept in articles, you don't think that adding a javascript code to direct you to another page would be any good? Okay. Althepal (talk) 01:48, 6 September 2008 (UTC)

It could probably be implemented as a gadget if someone cared to write it. --Tango (talk) 06:11, 6 September 2008 (UTC)

What about Dillo? What about handheld browsers? Screen readers? Search engines that count links to determine which pages are more "important"? It seems to me that if an article is missing an important wikilink then that article should simply be edited to wikilink the term. Your system might be nice for simpler words that the article expects the reader to know, but it needs more thought and I don't think that anything like it could ever replace traditional wikilinking. —Remember the dot ^(talk) 02:44, 6 September 2008 (UTC)

We have this functionality already. It's called copy-paste and the search box. Algebraist 13:45, 6 September 2008 (UTC)

Eek. Do you know what sort of havoc could ensue if vandals had access to Javascript on Wikipedia? Corvus cornix_talk 18:13, 6 September 2008 (UTC)

All of them? I use Lynx on a regular basis. If you can tell me how to turn on Javascript support in it, and how to right-click over an SSH connection, I'll be most grateful. --Carnildo (talk) 01:05, 7 September 2008 (UTC)

There are 60 John Brown's in en-wiki. No bot can guess which one was meant by this particular paragraph. NVO (talk) 05:50, 6 September 2008 (UTC)

Blue links are useful because they tell you an article exists on that topic and also what it's called (possibly through piping). Removing links would mean people have to guess the titles of articles they are interested in. --Tango (talk) 06:11, 6 September 2008 (UTC)

What do I do if I want to select text, right click it, and not search Wikipedia for it? Mr.Z-man 18:29, 6 September 2008 (UTC)

That depends on the user interface of whatever particular web browser you happen to be using. Most browsers allow you to left-click outside of (on the whitespace to the left or right of) the bluelink and, holding the click, to drag the cursor across the link. Your browser will probably highlight the selected text as you do this. You may also be able to left-click on one side of the bluelink to define one side of the text you wish to select, reposition the cursor without holding the click, and then shift-leftclick (leftclick while holding the shift key) to define the other side of the text you wish to select. Again, your browser will probably highlight the text you have selected. You may also be able to right-click on a link to get a popup menu, and the menu might offer an option something like "copy link" to copy the text of the link into a temporary scratchpad (MS-Windows calls this a "clipboard"). Your mileage may vary, depending on which particular computer hardware, operating system, graphical user interface (if any), web browser and browser version you happen to be using, depending on how many buttons your mouse has, and depending on other user-peculiar conditions. -- Boracay Bill (talk) 01:01, 7 September 2008 (UTC)

This would require a change in the browser's expected behavior, which should be avoided. Many people, particularly the less internet-savvy, would be very confused if they highlighted some text and right clicked (to copy the highlighted text, perhaps), and, in contrast to what has happened on every website they have ever visited before, they are immediately led to a new page. However, I'm sure there is another way to implement the idea that could avoid this problem. Regardless, I don't like the idea for the reasons already mentioned (how will it know which John Brown is being sought, for example?). — Twas Now ( talk • contribs • e-mail ) 00:17, 7 September 2008 (UTC)

Specifically related internal wikipedia links

On certain pages, it is annoying as a viewer to figure out which internal wikipedia links go to general versions of that particular link title or specific versions of it (that is, related to the current page). For example, if you go to the National University of Colombia and scroll down to "Faculties", it lists the faculties. Agronomy, the first, has an internal wikipedia link. But how does the user know whether it goes to the Agronomy faculty of the National University of Colombia or simply to the general page for Agronomy. Sure, there are two ways: the user can click and find out; or, she can look at the status bar when she is hovering over the link. However, I think it would be better to have "specifically related links" colored differently (green?). That way, one could easily tell. There are several ways that we could implement this, but for now I would just like to hear comments on whether you think such links would be nice? annoying/confusing? inconsequential? PGScooter (talk) 05:10, 7 September 2008 (UTC)

Unnecessary, at least in that case. Wikipedia isn't a directory of academic faculty. Appropriately, the link goes to Agronomy, which makes sense; I don't think it needs to be more confused. That section is somewhat misleading anyway, as there's a list of colleges in the middle of a section on faculty. Celarnor ^{Talk to me} 05:20, 7 September 2008 (UTC)

ah, yes I agree that Wikipedia is not a directory of faculty. I must have been thinking in Spanish when I made that post, because faculty in Spanish means department. So I was referring to the Agronomy department. Sorry for the confusing mistake. PGScooter (talk) 05:59, 7 September 2008 (UTC)

Departments are subdivision of faculties. In other words, a particular university faculty is more likely to be notable than a department. — Twas Now ( talk • contribs • e-mail ) 06:29, 7 September 2008 (UTC)

That must be a UK usage. In the States, if there are subdivisions of a university larger than a department, they are generally called schools or colleges (Caltech calls them divisions). So for example UCLA has a College of Arts and Sciences, a College of Engineering, and so on. --Trovatore (talk) 21:10, 7 September 2008 (UTC)

Thanks for the clarification. PGScooter (talk) 06:39, 7 September 2008 (UTC)

It appears that I chose a poor example (or rather I was unskilled at explaining the example). How about another one: Suppose that in Barack Obama's page there is a sentence that says "On September 2nd, Obama gave a speech regarding national defense." The link, "speech", could go to a general article on speech or it could go to an article talking about that particular speech, on September 2nd. I think that this distinction should be reflected in the format of the link somehow, perhaps color. Is that example any better? PGScooter (talk) 06:39, 7 September 2008 (UTC)

Yes, I think it was clear the first time around; Celarnor was just being a bit pedantic. Anyway, do you know how this could be done, aside from an extra parameter somewhere in the wikilink? — Twas Now ( talk • contribs • e-mail ) 08:50, 7 September 2008 (UTC)

It is already done, as you can look at your browser's status bar and see the name of an article in the link, regardless of the actual text in the link. The same functionality is available in tooltips as you hover your mouse over links and leave its cursor there for a couple of seconds. Titoxd^{(?!? - cool stuff)} 09:06, 7 September 2008 (UTC)

I mentioned the status bar in my original post. I consider the status bar and hovering over solutions second best. My proposal is for a different colored link. And as such, although it might be unnecessary, silly, or confusing, it is not already done. PGScooter (talk) 17:33, 7 September 2008 (UTC)

I have several ideas as far as the implementation. My preferred one is that when you want to code such a link, you use [[[three bars]]] instead of two. Of course, a lot of links would not be changed at the start. And this, I think, is a problem. The user might understandably think that the green links are internal links and that all of the blue ones are not. However, this would not be true because the blue links would not all be changed over. Hence the possibility that a user would like to click on a link if it were specific but sees that its blue so doesn't even try. PGScooter (talk) 17:33, 7 September 2008 (UTC)

What is "particular" to the topic? What is not? It's too subjective. Yes, it's not a directory in the sense that it's impossible to define fields as strictly as a database format does. NVO (talk) 09:09, 7 September 2008 (UTC)

In my opinion, the process of writing an article on Wikipedia is extremely subjective. The reporting of facts is subjective- you choose what to include, even if you maintain a neutral tone. In regards to your questions, there would be guidelines. In my opinion, deciding whether a link is specifically related or not would be much less of a subjective process than deciding whether a page should be deleted or not, whether a page deserves a GA, whether a page should have the "expert attention" tag, etc. PGScooter (talk) 17:33, 7 September 2008 (UTC)

The solution is not to use pipes. Pipes are mostly bad. Occasionally there are good reasons to use them, but mostly not.

So when you see agronomy, it goes to the general article on agronomy, and that's what you should expect. If you're listing the faculties of the National University of Columbia, then spell it out as Faculty of agronomy, National University of Colombia, and don't pipe it to "Agronomy". Then what you see is what you get. (Granted, this would be awkward in the middle of a sentence, but for a list of bulleted items it should be fine.) --Trovatore (talk) 22:20, 7 September 2008 (UTC)

As a more philosophical point, this whole thing really only works if we presume that the department is notable, and that a list like that wouldn't be headed straight for AfD. Celarnor ^{Talk to me} 22:26, 7 September 2008 (UTC)

Well, I was talking about the list inside the National University of Colombia article, not a separate list article. Of course, if the faculty is not notable enough for an article, then just list it, and don't link it to anything. Or, list it as "Faculty of Agronomy"; while I dislike linking words inside a proper name, it might be justified in this case. --Trovatore (talk) 23:05, 7 September 2008 (UTC)

I agree with both Trovatore and Celarnor on this issue. That makes me believe more that my initial example was a poor one. As Trovatore mentioned, this would be awkward in the middle of a sentence. It is exactly this that I am directing my proposal at. There are some places where it would just look too wordy to type out the whole title, and that is why most people do not. PGScooter (talk) 23:17, 7 September 2008 (UTC)

Hmm, I can see some utility for making piped links show up in a different color from normal links. That would even slightly mitigate my general hostility to pipes, because then they wouldn't be quite as contrary to the least surprise principle. This could presumably be done with very little burden on the developers (no extension needed to wikimarkup) and would be automatic, with no need to go through and decide which words should get triple square brackets. --Trovatore (talk) 23:31, 7 September 2008 (UTC)

It seems that my underlying reason for this proposal (I just realize this now) is probably similar to your reason for disliking pipes. I do not understand the technical details at all about how it would be implemented. What do you mean by automatic and why wouldn't there be an extension to wikimarkup? Do you support the [[[three bars]]] idea, or do you have a better suggestion? Sorry for my ignorance on these topics. PGScooter (talk) 23:55, 7 September 2008 (UTC)

My thought (it's not a suggestion, as yet, since I'm not sure I support it) is that all piped links would automatically show up in a different color. That seems to address your concern, without any need to add a three-square-brackets syntax. --Trovatore (talk) 00:00, 8 September 2008 (UTC)

My only reservation is the problem that I mentioned above, which I will restate here: a lot of links would not be changed at the start. And this, I think, is a problem. The user might understandably think that the green links are internal links and that all of the blue ones are not. However, this would not be true because the blue links would not all be changed over. Hence the possibility that a user would like to click on a link if it were specific but sees that its blue so doesn't even try. PGScooter (talk) 23:55, 7 September 2008 (UTC)

Distinguishing between piped and unpiped links would not work, because there are links like [[Southern Railway (U.S.)|Southern Railway]] and [[Mississippi Highway 13|MS 13]]. --NE2 23:53, 7 September 2008 (UTC)

I don't follow. Why would those not work? It seems to me that these are the sorts of things that we should want to see in a different color, if the original poster's logic is accepted. --Trovatore (talk) 00:00, 8 September 2008 (UTC)

This isn't what PGScooter was suggesting, Trovatore. Those piped links suggested by NE2 are for very closely related terms; the suggestion by PGScooter was for less obvious links: "Martin Luther King, Jr.'s speech" — is "speech" linking to the article on speeches, or the article on the particular MLK speech? — Twas Now ( talk • contribs • e-mail ) 00:30, 8 September 2008 (UTC)

Well, you may be able to make a distinction here, but I don't see that it really makes a difference. The different color warns the reader that by following the link, he won't get to the Southern Railway article (which I'm guessing is a dab page) but to some article considered more appropriate in the current context. That's a useful piece of information, one that would make pipes less objectionable as a UI feature. --Trovatore (talk) 00:36, 8 September 2008 (UTC)

I don't see a problem with letting users select their color preference in these cases, but we should avoid making article too colorful for everyone who browses Wikipedia. — Twas Now ( talk • contribs • e-mail ) 01:31, 8 September 2008 (UTC)

Well, no. The reader will get to the Southern Railway article; it's just the article about the Southern Railway the reader cares about. --NE2 01:45, 8 September 2008 (UTC)

He won't get to the same article as if he types "Southern Railway" into the search box. That's a well-defined distinction with no need to worry about fine points and subtleties, and a sufficiently bad aspect of the user interface to make it worthwhile to warn him. --Trovatore (talk) 02:31, 8 September 2008 (UTC)

"Prompt me when entering a blank edit summary" should ignore automatic section names

Hi there, I have turned on "Prompt me when entering a blank edit summary" because sometimes I am quite hasty to click on save page, accidentally doing so when actually wanting to preview. But I noticed, that it does not work every time. When I replied on a section of my talk page [3] it saved without prompting me, most likely because it generates an automatic heading. So I am proposing that the script that is set in place to prevent blank summaries also works when the summary is only within /* */ markers. Comments? :-) So Why 10:28, 7 September 2008 (UTC)

Hey, my wikipedia asks for the magic word even with section-heading auto-text. NVO (talk) 18:28, 7 September 2008 (UTC)

What I would like to see is "Prompt me" continuing to do so when entering a blank edit summary in any namespace but not to do so with "automatic section names" in any "talk" namespace. --Ron Ritzman (talk) 04:25, 8 September 2008 (UTC)

DYK discussion

There is a discussion going on concerning the DYK process and how much "reused content" can be included in a new article for it to count as new. Please go here and here for more information. Ottava Rima (talk) 21:13, 7 September 2008 (UTC)

Reintroduce a "feature requests" page?

I think it could be useful to have a "feature requests" page for people to list MediaWiki software feature requests. I understand that feature requests should be filed in Bugzilla, and I do not think that should change, but a discussion place on this wiki (for example at Wikipedia talk:Feature requests which is currently a redirect) could be beneficial by:

Not forcing people to use an unfamiliar interface
Acting as a conduit - people can submit ideas on the wiki page, the ideas can be developed and finally someone technically minded can file a Bugzilla report
Providing a place to list the most common feature requests with the corresponding bug number, avoiding duplicate entries in Bugzilla. If discussion occurs at Wikipedia talk:Feature requests, then the list could be at Wikipedia:Feature requests

Also, thinking globally it would be interesting to see, at each project's relevant page, a top three feature request list for each project, eg Commons vs English Wikipedia vs German Wikibooks.--Commander Keane (talk) 09:22, 8 September 2008 (UTC)

I totally agree. I have tried many times to file a request at Bugzilla, and every time I am being discouraged by the totally unfamiliar interface. Eklipse (talk) 13:30, 8 September 2008 (UTC)

Awesome idea. This would be very useful. RedThunder 20:53, 9 September 2008 (UTC)

Poll on which date format for articles unconnected with anglophone countries

Here at MOSNUM. Tony (talk) 03:29, 10 September 2008 (UTC)

Wikipedia Emergency Alert System

In the United States and maybe some other countries, the Emergency Alert System interrupts television and radio transmissions to warn residents of danger, such as severe weather. Although it would probably be impractical to require registration, and it would probably be unfortunately impossible for such a system to be available for people in all areas, but I think it would be great to create a Wikiproject where people could register their locations so that they would receive an alert when issues such as severe weather would be a threat to them. As with all Wikiprojects, it would take some effort to make this take off, but this is far from unreasonable. The idea would be to have a bot place a template with a red backround on people's talk pages when something is going on in their recorded location. The bot would run monthly tests as well. To register, a person would add him/herself to a catagory such as Wikipedians located in Port Charlotte, Florida or Wikipedians located in Charlotte County, Florida (I believe there are catagories like that which already exist for certain locations). People who want to be included in one of these catagories, but want to opt out of Wikipedia Emergency Alert Systen would add themselves to a catagory such as Wikipedians who do not want to receive emergeny alerts. To obtain information about such events, we could either have a team that would research such information (which may prove unreliable), or the Wikiproject could subscribe to the same sources that the TV and radio channels subscribe to (I don't think it costs anything in the USA). For areas that don't have these emergency alert systems, we would either have to have volunteers that would research such information, or we would have to leave a note that the system is not available in all areas. This idea spawns off of the United States Emergency Alert System. Remember, this proposal is for a completely voluntary system where users can opt in or opt out. We'd have to find some way of informing people about the system. Perhaps we could mention it on the main page if it is created? GO-PCHS-NJROTC ^(Messages) 01:35, 1 September 2008 (UTC)

Good idea. We already have such a system you describe here technically coded into the software. It is lcoated Here, at Sitenotice. NonvocalScream (talk) 01:46, 1 September 2008 (UTC)
Beyond that, I think a EAS would be beyond the project scope. NonvocalScream (talk) 01:47, 1 September 2008 (UTC)

I don't see how this would work as a wiki. Is the sole purpose and function to inform people of the EAS warning for their region? It would be much easier (and on much better authority) if people checked websites of weather services. — Twas Now ( talk • contribs • e-mail ) 23:48, 1 September 2008 (UTC)

This is way out of our scope. Wikipedia is not...wait...it isn't in there. Still, anyone who is tech savvy enough to edit Wikipedia knows how to get weather updates. Paragon ¹²³²¹ 03:23, 2 September 2008 (UTC)

I agree with the other opposes, Wikipedia is an encyclopedia, not a general web portal like Yahoo (do even they do this?), this would be massively increasing the project's scope. And as Paragon says, the people who would use this system, the editors, are going to be more tech savvy, and know not to use Wikipedia for this sort of information. Mr.Z-man 03:38, 2 September 2008 (UTC)

An online EAS is a great idea, but Wikipedia is not the place for it. --Tango (talk) 04:38, 2 September 2008 (UTC)

Have to agree with the above - interesting idea, but not in the least bit relevant to Wikipedia. _Talk Islander 08:09, 2 September 2008 (UTC)

This will be good when Wikipedia articles get broadcast over the radio. Until then, let radio be radio, and WP be WP. ;) -- Fullstop (talk) 14:12, 2 September 2008 (UTC)

Just adding my name to the "neat idea, wrong place" crowd :) Shereth 15:44, 2 September 2008 (UTC)

Add me to that crowd. As an aspiring meteorologist, I personally love the EAS, but Wikipedia is not the place for it. RedThunder 01:12, 7 September 2008 (UTC)

I could see how this could help actually, as a kinda "call to order" for people especially in the area to help assist in building up information if needed. ViperSnake151 11:56, 10 September 2008 (UTC)

That would kind of be the opposite of what the original proposer intended, we want them to get out of harm's way, not stand on their lawn to get a picture. Mr.Z-man 16:02, 10 September 2008 (UTC)

Wikipedia is not an Emergency Alert System, nor should it be. Neither is it an airplane control surface, an intimation of a new friendship, a convection oven, a chiffon dress, a consular visa office, a top-40 hit, nor the glorious memory of all who gave their lives to our great cause. Teemu Leisti (talk) 22:01, 10 September 2008 (UTC)

Although, releasing a single is something to consider... --Tango (talk) 22:41, 10 September 2008 (UTC)

Expanded/Simple Watchlist

I have noticed several improvements to Special:Watchlist (semi-)recently, such as hiding anon or logged-in edits, or filtering by namespace. I suggest another improvement: the ability to view the "expanded" watchlist (the version which appeasrs when selecting "Expand watchlist to show all applicable changes") or "simple" watchlist without changing Special:Preferences. Just like the current hide/show links, the watchlist would return to its default state (i.e. the way is it set up in my preferences) the next time I click the "my watchlist" link. What are your thoughts concerning this? - SigmaEpsilon → ΣΕ 03:52, 4 September 2008 (UTC)

It sounds like a good feature, is there a bug report filed? If not you may like to make one.--Commander Keane (talk) 10:54, 7 September 2008 (UTC)

I also had this idea a long time ago. See my post: [4] and my mock-up design: Image:Improved watchlist.PNG-- penubag (talk) 07:08, 9 September 2008 (UTC)

To have the show/hide links would require Javascript, so this would require using the "enhanced recent changes" option (which affects watchlist as well) but an option to toggle show all/most recent might be a good idea. Mr.Z-man 16:11, 10 September 2008 (UTC)

Other areas of wikipedia links should be moved