From Wikipedia, the free encyclopedia

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)

Welcome to the village pump. This set of pages is used to discuss the technical issues, policies, and operations of Wikipedia, and is divided into five village pump sections. Please use the table below to find the most appropriate section to post in, or post in the miscellaneous section. You can view all village pump sections at once here. Please sign and date your post (by typing ~~~~ or clicking the signature icon in the edit toolbar).	Shortcuts: WP:VP WP:PUMP WP:VILLAGE	It can only be speculated that, like the modern office water cooler, the village pump must have been a gathering place to discuss ideas for the improvement of the locale in which its members dwelled.
Village pump sections Policy post | watch | search To discuss existing and proposed policies Technical post | watch | search To discuss technical issues. For wiki software bug reports use MediaZilla Proposals (persistent) post | watch | search To discuss new proposals that are not policy related. See also: perennial proposals. Assistance post | watch | search To post requests for assistance not covered by the Help desk or the Reference desk Miscellaneous post | watch | search To post messages that do not fit into any other category I want... Where to go To browse all village pump topics at once Village pump (all) To search all village pump section archives, Oct 2007 - present Search Help using Wikipedia Help desk To find my way around Wikipedia Department directory Specific facts (e.g. Who was the first pope?) Reference desk Constructive criticisms from others for a specific article Peer review Help resolving a specific article edit dispute or making a user conduct dispute complaint  Requests for comment To comment on a specific article Article's talk page To view other Wikimedia projects Wikimedia Meta-wiki To learn about citing Wikipedia in a bibliography Citing Wikipedia To report sites that copy Wikipedia content Mirrors and forks

Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive). These discussions will be kept archived for 7 more days. During this period the discussion can be moved to a relevant talk page if appropriate. After 7 days the discussion will be permanently removed.

Policy

Proposed change to banning policy

I have just noticed a puzzling formulation in Wikipedia:Banning policy, one that (I checked) was introduced in the very first version of the policy, few years back - but one that also seems contrary to our goal of building an encyclopedia. The formulation is: Any edits made in defiance of a ban may be reverted to enforce the ban, regardless of the merits of the edits themselves. In other words, this can be used (and I have seen this used in such a way) to justify reverting completly innocent edits such as Manual of Style changes (typo fixes, punctuation), addition of interlinks, or fixing of obvious errors. I think it is common sense that non controversial, innocent edits by banned editors should not be reverted just because they were carried out by a banned editor (or usually a suspected or confirmed sock of one). Of course, just be clear, if such a sock makes controversial edits, they should be reverted immediately and the block extended. But the idea that we should put enforcing our bans to the letter over the spirit of building an encyclopedia is just plain wrong. Feel free to comment at the policy talk page.--_{Piotr Konieczny aka Prokonsul Piotrus| talk} 12:15, 27 May 2008 (UTC)

I have changed the above heading from blocking to banning, because this is what it is about. The two terms are not synonymous. Waltham, The Duke of 20:13, 27 May 2008 (UTC)

They may be reverted, it doesn't force anyone to perform those reversions, it could be a bit clearer on that --Enric Naval (talk) 18:19, 28 May 2008 (UTC)

I agree with Piotrus. What troubles me about this section is that I've seen people who believe that all edits by a sock of a banned user should be reverted immediately, as it is too much trouble to check and see which edits are good and which are bad. This is not a constructive activity. I've even seen an instance where a perfectly acceptable article was deleted, after multiple edits by other editors were made, because the originating author was a sock. This in particular is indefensible and unjustifiable. If someone is too lazy to actually look at edits before reverting/deleting them, than find someone who isn't. Due to the wording of the policy, the people doing this are fully within their rights, and I simply do not agree that this should be universally permissible, let alone encouraged. I will admit that this is sometimes necessary, in situations where a large number of edits were made, and there is little chance, due to the nature of the sock, that there were any good edits. However, in many cases the application of blanket reversion is extreme, and it is an activity with the potential for mass disruption, not to mention unnecessary duplication of effort. In my view if an edit is good, who made it is utterly immaterial. The purpose of banning, in my interpretation, is to relieve the Wikipedia community of an editor whose editing, for whatever reason, has been determined to be a consistent net negative to the extent that there is no logical purpose for allowing their continued participation in the project. If they edit constructively while banned, reversion of those edits to "enforce" the ban is a net negative, and is thus utterly at odds for the original reason for banning them.--Dycedarg ж 21:01, 28 May 2008 (UTC)

I realize it's being a bit dickish to the banned user to revert even their innocent, good-faith changes, but this rule was created because some banned users were continuing to edit anyway, and after a certain point, we just have to give them the cold shoulder. Allowing those changes to stick gives them the satisfaction they need to continue editing, and they really aren't supposed to continue. Users are not banned lightly, and they aren't banned in ignorance of that rule, but rather with a clear awareness of it. Mangojuice^talk 15:55, 29 May 2008 (UTC)

Banned means banned. Not "banned when you are not nice". Everything by banned users should go. Dsmdgold (talk) 19:20, 31 May 2008 (UTC)

One reason – not the only one – why such reversions are permitted by the banning policy is that in some cases the banned editor will continue to make superficially constructive edits as part of a pattern of stalking or harrassment. Continuing to conspicuously edit pages that are watched by a former adversary can be a way to stir the pot even after a ban—particularly if well-meaning editors jump in with 'Why are you reverting those apparently-reasonable minor edits?'. TenOfAllTrades(talk) 19:29, 31 May 2008 (UTC)

Banning means the person is not welcome to edit here, so the rules makes a lot of sense to me. _{1 != 2} 19:52, 31 May 2008 (UTC)

As we're here to write an encyclopedia, an edit that advances the encyclopedia should stay, regardless of who makes it. A good quality edit by VoB should be kept in preference to a poor quality edit from me, for example. If not, then we're asserting that some other consideration should come ahead of writing the encyclopedia. --SSBohio 03:33, 4 June 2008 (UTC)

I couldn't put it better myself. If it serves the interests of the encyclopedia, then it doesn't matter who made it. It improves the project; in my opinion, reverting a good edit is a much more serious offense than breaking a ban to make a good-faith edit that isn't controversial or otherwise in obvious bad faith. Celarnor ^{Talk to me} 03:56, 4 June 2008 (UTC)

Reverting the edits of the banned user doesn't bother me, but insisting that nobody else is even allowed to re-make the same edits if that other (non-banned) user finds them worthwhile, as is sometimes loudly argued (complete with threats of blocks against that latter user) does. *Dan T.* (talk) 04:07, 4 June 2008 (UTC)

The point of the policy, as I understand it, is basically an extension of WP:Deny recognition. If they think they can contribute, they may think they're pulling their weight and should be allowed to stay or they may think they can get the last word in indirectly through another editor or otherwise disrupt the project. Repeating the edit may be tossing them a bone instead of a steak dinner, but it's still feeding a troll.Somedumbyankee (talk) 04:17, 4 June 2008 (UTC)

So, someone on some kind of ban reverts libel on a BLP subject, someone else restores it with an "OH NOES TEH BANNED UZER" edit summary, and we leave it there? Placing our community problems above furthering project seems kind of backwards to me. Celarnor ^{Talk to me} 04:20, 4 June 2008 (UTC)

The policy addresses that specific issue: "When reverting edits, care should be taken not to reinstate material that may be in violation of core policies such as Neutrality, Verifiability, and Biographies of Living Persons." As for backwards, without the community, there is no project. The vicious circle adds that without the project, there is no community. There has to be some sort of balance, and shunning and denying any access to banned users conserves the community at an acceptable loss to the project.Somedumbyankee (talk) 05:11, 4 June 2008 (UTC)

Of course there's a project without the community. If we shut down editing tommorow and made wikipedia read-only it would continue to be a useful resource for years to come. The same cannot be said the other way around.--Phoenix-wiki 19:38, 6 June 2008 (UTC)

Rollback for stewards

Hi, I am a steward and I am taking care about some articles on en.wp. As a steward, I am admin on every project. Besides privileges in which I am not interested at en.wp (blocking user, deleting and undeleting pages...), I've got "rollback" button. My question is: may I use it? It would help me in keeping consistent articles about I am taking care. --millosh (talk (meta:)) 08:03, 30 May 2008 (UTC)

I see no reason why not. : - ) --MZMcBride (talk) 08:08, 30 May 2008 (UTC)

Definitely read Wikipedia:Rollback feature if you haven't already--people here feel very strongly that rollback should only be used to revert vandalism or your own edits. Darkspots (talk) 13:33, 30 May 2008 (UTC)

Absolutely, though I'd expect you to only be using it for vandalism cleanup. EVula // talk // ☯ // 13:36, 30 May 2008 (UTC)

Of course, it is only about vandalism cleanup. For a long time my contribution to en.wp is related just to taking care about a small group of articles for which I suppose that no one else takes care. In my feed reader I usually see bot edits, nonsenses and vandalisms. At the contrast, I am taking care about Template:Case table, where I have to check every addition of the new case or "case"; and if it is not a grammatical case, I am always giving rationale on talk page. --millosh (talk (meta:)) 08:43, 31 May 2008 (UTC)

Thanks for trust. --millosh (talk (meta:)) 08:43, 31 May 2008 (UTC)

I have, actually, already made two rollback edits (I'm a steward as well) in response to vandalism-en emails on OTRS. I assumed there would be no problems if I used the tool only in clear vandalism cases. :) --Filip (§) 09:37, 31 May 2008 (UTC)

Same for me. If there are no objections I would use it to revert vandalism that I come across. Thanks, --Thogo (Talk) 12:37, 31 May 2008 (UTC)

Especially considering we're handing out the rollback right like candy to most users who have need/want of it, that sounds quite acceptable to me. If any of you stewards would prefer to avoid using it "as an admin," I suppose you could explicitly get your account flagged for rollback via Wikipedia:Rollback feature#How to apply for rollback. – Luna Santin (talk) 22:57, 2 June 2008 (UTC)

Given the level of trust it takes to be a steward, I would have no issue handing out local rollback to them, with my nice notification message to only use it on vandalism. MBisanz ^talk 04:25, 5 June 2008 (UTC)

Sister sites for well-researched miscellany

A search for all Wikipedia entries containing "Enterprise episode" reveals a jumbled mess: a separate entry for nearly every episode of the TV show, inconsistently including (Enterprise episode) or a variation thereof for the sake of disambiguation -- perhaps extinction and Extinction (Star Trek: Enterprise) coexisting in the same directory space is indicative of a much larger problem. It's great that Wikipedia provides information like this in a convenient place, but when it goes against the site's own policies, and when a more specialized wiki exists just to cater to this topic, why not remove the offending sites from Wikipedia and redirect instead to the specialized wiki? --38.100.221.66 (talk) 22:15, 1 June 2008 (UTC)

Because we can't be sure of the content or policies on those other specialized Wikis not controlled by the Wikimedia Foundation. For example, Memory Alpha (pretty much the accepted Wiki for ST content) could change its policies tomorrow to not allow edits from the outside, and then start changing crap randomly. Generally, in the case of television episodes, we provide an external link. Celarnor ^{Talk to me} 23:38, 1 June 2008 (UTC)

With regards to the INDISCRIMINATE accusation, there's content guidelines for episodes at EPISODE. Celarnor ^{Talk to me} 23:38, 1 June 2008 (UTC)

They don't violate Wikipedia's own policies. Wikipedia is not paper, articles should be verifiable, contain no original research, and be written from a neutral point of view. The phrase "Wikipedia is not an indiscriminate collection of information" is not meant to be applied to any article you personally don't like. I'm sure Memory Alpha goes into more detail than Wikipedia, but how does Extinction (Star Trek: Enterprise) turn Wikipedia into a an "indiscriminate collection of information" but the extinction article does not? What were you looking for when you searched for "Enterprise episode"? --Pixelface (talk) 20:48, 6 June 2008 (UTC)

Inconsistency with articles about retailers

I am somewhat confused as to what articles about retailers should be called on Wikipedia, and Wikipedia:Naming conventions (companies) didn't really answer my question, so I'll post it here.

Some retailers (e.g. Tesco) have only their names as their article titles, whereas others have various different things in brackets after their names (e.g. Iceland (supermarket) and Argos (retailer)). Shouldn't there only be one way of doing things, and do some of these articles need renaming? It Is Me Here (talk) 14:26, 2 June 2008 (UTC)

As for Tesco, it's best not to use any parenthetical if there is no other topic with the same title: obviously Iceland (supermarket) and Iceland are distinct topics. But for those with parentheticals, there is some value to having them be consistent if it's possible. I don't like (supermarket) as it's a bit too specific -- that could just be (store)... (retailer) could work, but something about calling a supermarket a "retailer" strikes me as wrong somehow. Mangojuice^talk 15:39, 2 June 2008 (UTC)

Calling Tesco or Iceland a 'store' would violate WP:ENGVAR. Algebraist 22:52, 2 June 2008 (UTC)

Indeed, a Tesco store would be a place where Tescos store things. DuncanHill (talk) 22:54, 2 June 2008 (UTC)

I think that would be a Tesco warehouse. A Tesco store would be a place where Tescos are stored. Algebraist 22:57, 2 June 2008 (UTC)

Isn't English fun? DuncanHill (talk) 23:07, 2 June 2008 (UTC)

As Mango mentioned, it's common practice to avoid parentheticals in article titles unless they're specifically needed. I also agree there's some advantage to uniformity, though. Seems "store" is out, but what about "retailer"? – Luna Santin (talk) 23:06, 2 June 2008 (UTC)

'Retailer' sounds reasonable. Any idea how much work this would entail? Algebraist 23:17, 2 June 2008 (UTC)

According to AWB, we have 582 pages in Category:Supermarkets by country, 79 of which have some parenthetical or other. A fair number of those parentheticals are a country name, a few are cities or state/provinces, but the majority look to be some variety of (store), (supermarket), (supermarket chain), and so on. – Luna Santin (talk) 03:23, 3 June 2008 (UTC)

I'm with Mangojuice: calling a supermarket a "retailer" seems slightly wrong. I can't quite put my finger on it, but I think that in UK English "retailer" has some connotations that it might not have in US English. Bluap (talk) 12:39, 3 June 2008 (UTC)

I'm surprised no-one's linked this, but the parentheticals are not actually meant to be taken as part of the actual title, but as a means of disambiguating them from other possible uses of the name - as mentioned above, there is already Iceland (the country) and Argos (the Greek city), but the majority of people who recognise the name "Tesco" would be thinking, first and foremost, of the chain of supermarkets, hence the lack of a parenthetical. Confusing Manifestation(Say hi!) 07:01, 5 June 2008 (UTC)

I've got no problem with that, I'm mainly after uniformity being enforced in the articles about shops (or whatever) that do have something in brackets after them. It Is Me Here (talk) 11:57, 7 June 2008 (UTC)

the "table of contents" of many articles break contents down into a single "part"

I learned in grammar school that one of the most basic rules of creating an outline is something like:

if you are going to create an indented sub-topic, you must create at least two sub-topics.

I think the idea is that in creating an indented sub-topic, you are breaking an idea into its component parts; but if a concept only has one part, then that part must be the whole concept. In that case, creating a sub-topic is misleading and not justified.

I think this is relevant in wikipedia because the tables of contents in many articles are in outline form, and so should follow the rules for outlining.

By the way, it bothers me that I have edited pages here on wikipedia at least twice in the past to make this suggestion and my edits were deleted. Please don't delete my request; instead justify your reasons for not implementing it if that is what you are going to do. What I would like to see is a generally available discusssion about this very non-trivial subject.

Please note that outlining is an important process: useful for organizing ideas before writing any complicated document, and probably useful for almost any planning. Wikipedia arguably is a very powerful standard setter, and as such may have a profound (in this case negative, I think) effect on the ability of many whom wikipedia influences to outline, write, think and plan.

Allow me to introduce an example below of what I mean:

From the "Quantum" article in wikipedia:

Contents [hide] 1 Development of quantum theory

    1.1 The quantum black-body radiation formula 

2 Beyond electromagnetic radiation

    2.1 The birthday of quantum mechanics 

3 See also 4 References 5 Notes

Above, "1 Development of quantum theory" is broken down (or outlined) into one component part. It seems to me that for this to adhere to the basic rule for outlining I am requesting that it must be either broken down into more than one part, or that "1.1 The quantum black-body radiation formula" should be "demoted" to a lower level, i.e. 1.1 would be demoted to replace "2 Beyond electromagnetic radiation" and "2 Beyond electromagnetic radiation" would be renumbered as "3 Beyond electromagnetic radiation" with remaining entries renumbered sequentially.

Another way of saying this is: Surely there is more than one part to item number 1 "the development of quantum theory"; if not, then I think "1.1 The quantum black-body radiation formula" should join the line above it or replace the line above it.

Summary: though it will be expensive in terms of person-hours, I think wikipedia should adopt a standard (which, considering wikipedia's considerable and growing influence will set a nearly universal standard) of not allowing solitary sub-topics in outlines (i.e. table of contents, etc). This would not be a new standard, it would merely be following long established rules of language (and thought).

69.225.94.162 (talk) 04:27, 3 June 2008 (UTC) Joe Cash email: joecash@sol.csustan.edu —Preceding unsigned comment added by 69.225.94.162 (talk) 01:28, 3 June 2008 (UTC)

I agree in principle, and if you want to make such edits, then please do so. In addition, you could find the WP page outlining the policy about headers — wherever it might exist — and present your idea as an edit to that page; then see if it flies. Sincerely, GeorgeLouis (talk) 07:25, 3 June 2008 (UTC)

• I agree, with one provision: sometimes a section will have a lead/introduction, and then a subsection. This mught be legitimate style, but still render a TOC as you described?  — Xiutwel ♫☺♥♪ (speech has the power to bind the absolute) 05:11, 5 June 2008 (UTC)

I agree with the above stated rule about outlines as I was taught the same thing. However, when I brought the subject up to the Wikipedia:Featured articles grammar and layout guru, User:Tony1, he stated he had never heard of such rule and that is was not in the critera for a FAC. So there you go! –Mattisse (Talk) 17:53, 9 June 2008 (UTC)

Israeli News Agency

I wanted to add a link for a speech made by the Israeli prime minister, citing the Israeli News Agency, but the system said that particular source was "blacklisted." How can that be? How can a source be "blacklisted"? Questioningly, GeorgeLouis (talk) 07:22, 3 June 2008 (UTC)

Assuming the url is israelnewsagency[dot]com, it's listed on the spam blacklist at meta (see m:Spam blacklist). The associated log entry mentions this request. – Luna Santin (talk) 10:06, 3 June 2008 (UTC)

Well, that's a pretty damning indictment. Is there a page that gives the actual rules and regulations for putting a source on this list, or is each item handled more or less on a case by case basis? Sincerely, GeorgeLouis (talk) 20:29, 3 June 2008 (UTC)

A blacklisted link typically means that it's been inappropriately added to articles at an excessive rate (i.e. "spammed"), and someone's made a request to blacklist it to prevent further occurrences. You may want to request that just the link to the speech be added to MediaWiki:Spam-whitelist so you can use it in the article. Confusing Manifestation(Say hi!) 06:57, 5 June 2008 (UTC)

Use of images in educational multimedia

Hi there, I create and deliver video conferences about palaeontology here at the Royal Tyrrell Museum in Canada. I would like to use some illustrations fromm Wikipedia pages, but I am unclear as to whether I need to aknowledge the creator of the image as part of the multimedia I am making and using. —Preceding unsigned comment added by 199.213.123.54 (talk) 15:52, 3 June 2008 (UTC)

Hi; images on Wikipedia are supposed to conform to the image use policy, which -- apart from the odd "fair use" image, which is a special case people are always talking about -- should all be usable for such a purpose. If you look at the image's own page (e.g. Image:Bpi01.jpg or Image:Pohlsepia mazonensis.jpg, you can see commentary below on the copyright and licensing status of each one. Some are public-domain, some require attribution, and you might like to avoid the "fair use" ones altogether for safety's sake. :-) You might also like to browse through Wikimedia Commons for images. --_{tiny plastic} Grey Knight ⊖ 12:16, 4 June 2008 (UTC)

Date links suck.

Hi,

I dislike date links. I think they should be excised from Wikipedia because they make articles harder to read.

I understand the main reason to keep them is to preserve autoformatting.

How would I propose that date links be invisible when reading the article? So a wikilink for 30 June 1944 would simply appear in the browser thus:

30 June 1944

Tempshill (talk) 18:03, 3 June 2008 (UTC)

P.S. I know date links in general are a longstanding point of contention and irritation. I just don't know where to make the proposal. Over at the Manual of Style (dates and numbers) link there's just a large intimidating longstanding flame war about something I don't even know what they're arguing about. Tempshill (talk) 18:07, 3 June 2008 (UTC)

Would you like a javascript tool to make them invisible to you? — CharlotteWebb 18:15, 3 June 2008 (UTC)

I can't speak for Tempshill, but I believe he or she is asking for a change in policy whereby the links would not be visible to the researcher (most of our visitors). Perhaps the Javascript tool should instead make them VISIBLE. I agree that highlighting the dates in blue is really silly and makes WP look like a conclave of nerds rather than serious writers and editors. Sincerely, GeorgeLouis (talk) 20:34, 3 June 2008 (UTC)

You say "sincerely" as if I might otherwise doubt the sincerity of your comment . In any case I do not understand why a casual reader would consider blue, clickable links to June 4, 2008 any nerdier than blue, clickable links to any other topic. Sincerely. — CharlotteWebb 13:46, 4 June 2008 (UTC)

I agree 99% that date links suck. However there are a few cases where they are useful to readers, e.g. in Guns, Germs, and Steel "trying into explain why, for example, in 1492 Eurasia was almost entirely populated by settled societies with governments, literacy, iron technology and standing armies while the other continents were almost entirely populated by stone age tribes of hunter-gatherers" provides an opportunity to remind readers of Columbus' voyage across the Atlantic, which effectively started modern European colonialism - which is very relevant to the theme of the book. I can also think of a few day-month dates that might usefully be wikilinked: 1 January, 1 April, 25 December, etc.

I think what's needed is:

• A flexible policy based on whether the value of a date is significant to the reader, which generally depends on the context.
• A mechanism for formatting dates (e.g. dd-mm-yyyy vs mm-dd-yyyy) without wikilinking. But IMO it must also be one that's easy for editors to use - unlike e.g. the requirement to use ISO format (yyyy-mm-dd) for accessdate in "cite web". That's a matter for the techies to resolve. Philcha (talk) 21:39, 3 June 2008 (UTC)

One thing that bugs me is overprecision about dates--which I think is related to the aesthetics of the blue date link. I have removed day or month information from dates to get rid of the wikilink--for example, who cares when in 1988 a particular book was released? I'd be very much in favor of a software solution to make date linking invisible. Darkspots (talk) 21:57, 3 June 2008 (UTC)

If we can verify the exact date of book publication (or any other event) the relevant articles should include the date in some form or fashion. The other obvious advantage of wiki-linking dates is that a list of referring pages makes it easier to add births, deaths, and other cataclysmic events to our day/month/year articles. I would support a "software solution" in the form of a "[x] Suppress links to day/month/year articles" (replacing them by "plain text") in Special:Preferences as long as it is unchecked (keeping status quo) by default. Failing that (I doubt the devs would consider this a high-priority issue — bigger fish to fry, you know...) I have offered to create a javascript tool to do pretty much the same thing, for users who do not wish to see (or, worse, accidentally click on) links to day/month/year articles. Blurring chronological information, i.e. changing a known and undisputed exact date to an approximate time-span (solely to avoid formatting it as a date), is disruptive and downright harmful. Please do not do this. — CharlotteWebb 13:46, 4 June 2008 (UTC)

When you have a series of events--let's say a list of novels written by an author in a biography of the author--and some of the dates have day, month, year, some have month, year, and some have only the year, that date link really stands out and looks ugly. I'm not talking about changing the date of a battle or an election from a day to a year. but in that list of books, making all the past dates have the same level of precision--like month, year--helps a lot. When reading a biography, do you really care on what date in May 1988, say, an author had a book published? Not really. You want to know the chronological order in which things happened, you want to know about what was happening in history at that moment. Now there are no doubt countless exceptions to this--Van Gogh scholars care deeply what happened on each date of the last years of his life, as a random example. In a more general way, if an author has multiple works published every month, obviously more specific dates would be in order. But unnecessary precision is no service to our readers. I wouldn't change a date just to get rid of a link, but it's definitely one of a lot of considerations. I try to edit in every situation with an eye to what's going to make the encyclopedia better. Darkspots (talk) 16:17, 4 June 2008 (UTC)

I see what you mean but the exact date (if known) should at least be mentioned in the article about each book (if the article exists). If the article about the book doesn't exist yet (and we are unwilling to create it at the moment) but the exact date of publication is verifiable and undisputed, it should be mentioned somewhere in the list as the book title should probably redirect to the list (which may itself be a sub-section of the author's biography), and the list is a logical starting point for anyone aspiring to create articles about these particular books.

Of course this is something that applies broadly to all topics and types of verifiable information — somebody somewhere will be looking for it, so if we have it, it should be available without having to dig through old revisions.

Back on topic, I'm willing to acknowledge that there are several users who do not like to see links to day/month/year articles for whatever reason I will not speculate. But I would like to know whether they would prefer that any sort of automatic de-linking of dates is done only for themselves and others sharing this sentiment, or for everyone reading the content. I would be amenable only to the former option. — CharlotteWebb 17:07, 4 June 2008 (UTC)

I completely agree that the articles for the books themselves should have the exact date, in this little example. Darkspots (talk) 17:11, 4 June 2008 (UTC)

Could you add nowiki tags to the date to make it not get autoformatted? It seems to me these are more useful by default than not; in the instances where you just have a list of chronological events, you could put tags around it so it wouldn't get linked. Celarnor ^{Talk to me} 16:32, 4 June 2008 (UTC)

Or just not use any brackets, perhaps. — CharlotteWebb 17:07, 4 June 2008 (UTC)

There are quite a few users that are unhappy with:

• mandatory date links. This is due to a bad software design that combines two entirely independent functions: (a) hyperlinks to date articles; and (b) formatting of dates. The cure is worse than the disease. Very few people have the disease but we are all forced to take the medicine. If you want a plain date, just take the square brackets out.
• the use of the Manual of Style (dates and numbers) talk pages for a war over binary prefixes. The policy page is defunct because you cannot read it and assume that it is policy. The binary prefix warriors decided that policy pages can contain proposals.

I would recommend that you take this issue to Manual of Style (dates and numbers), but like you, I am avoiding it and regard it as unserviceable for those of us outside that would prefer to remain unaffected by that war. Lightmouse (talk) 16:50, 5 June 2008 (UTC)

• Yup, the autodud system certainly does suck. All of our attempts to get the developers at Bugzilla to decouple autoformatting from linking have met a dead end. Brion Viber there doesn't seem at all keen to push things forward, despite a petition I organised more than a year ago with nearly 90 WPian signatories (I'm quite sure I could raise many hundreds now). See HERE (Comment 35 ff.
• But the main point I have to make here is that autodud is not mandatory. See MOSNUM , which says "A combination of a day number and a month can be autoformatted by adding square brackets". I'm unsure how that can be contrued as compulsion. I encourage people not to use autodud at all. TONY (talk) 02:58, 6 June 2008 (UTC)

Thanks for correcting my statement and pointing out the exact wording of the guideline. Links to dates are not mandatory. Lightmouse (talk) 09:07, 6 June 2008 (UTC)

But but by not linking, and in the current arrangement therefore disabling autoformatting, it gives the outward appearance of "This is the US Wikipedia. US date format rules!". Perhaps a Wikipedia International English Edition might solve it. I don't like being the doom monger, but its little things like this that I believe will eventually lead to a WP schism. There are international differences on date formats and it may have a massive amount of "I don't like it" in it but users should be able to come to Wikipedia and see something as simple as a date in the format that they want to see it in. A simple cookie and a some coding and people could have dates that are blue, black, pink or whatever colour they want and in the format that they want. The autolinking should be kept and should be mandatory but it should also have the ability for users to select the date appearance they want. It could even be made to work for IP users, with a splash screen allowing a user to set preferences (cookie) on their browser's first visit to WP and reading the preferences from the cookie on subsequent visits. I hope both sides of this debate can unite behind a common flag of getting a proper working solution implemented by the devs. - X201 (talk) 10:10, 6 June 2008 (UTC)

The same issue applies to spelling. There is US spelling and non-US spelling. We solved that without autoformatting of 'color' into 'colour'. Lightmouse (talk) 10:17, 6 June 2008 (UTC)

Well, most non-US spelling isn't confusing to a U.S. reader; when I see 'colour' I just smile about the silly 'u' in there but I still understand it means 'color'. Same for 'kerb' and 'curb', and so on. Dates, however, are more confusing; June 8, 2008 would be rendered 6/8/2008 in American short date format and 8/6/2008 in some non-U.S. date formats. Which is actively confusing, because to the U.S. reader, the second example means August 6, 2008. Apart from forcing everyone to use ISO standard 2008-06-08 (which I'd love, but nobody else would) making the server automagically display dates in their preferred format is a great idea.

That said, I never understood why the "this is a date" syntax is the same as the "this is a link" syntax. It's pretty non-orthogonal. Instead, it would be nice if some new syntax was invented to flag dates, like (( )) or something. That way, if you have your prefs set to, say, ISO date format like me, ((October 20, 2005)), ((20 Oct 2005)), ((2005-10-20)), ((20/10/2005)), ((10/20/2005 US)), etc could all render as a plain, unlinked "2005-10-20". This would have the added benefit of being able to do ((20 Oct [[2005]])) or even something like ((20 Oct [[2005 in film|2005]])) and get "2005-10-20". —Scott5114↗ [EXACT CHANGE ONLY] 09:07, 8 June 2008 (UTC)

The principle of least astonishment should preclude us from piping date-links to a non-obvious target. A reader seeing "2005" in blue should expect it to link to the main article for that year (the fact that it also breaks existing date-formatting mechanisms is secondary to this). The effect of the "new syntax" you describe could be achieved using a variety of parser functions (without linking the result) by using a #switch statement and some variable representing the viewer's preferred date format (if the devs are willing to add the latter). Alternatively the #time function could be made more robust (it is apparently limited to 1970 and later).

Back on topic how would you feel about an option in Special:Preferences to make date links appear as plain text? — CharlotteWebb 10:48, 8 June 2008 (UTC)

This seems to be a perennial discussion. See {{date}} and [1]. --B. Wolterding (talk) 10:38, 8 June 2008 (UTC)

• Charlotte, a preference to that effect would be great, and better than nothing; so then dates would appear as they do after our signatures: BLACK (except that they would be formatted according to the original: 8 September 2005 OR September 6, 2005, not the British/Australian formatting that automatically appears after all signatures). However, this wouldn't solve the larger issue, which is that 99% of readers are not registered and logged in, so don't ever benefit from the actual autoformatting—they just cop the bright-blue irritation.
• X201: no, we'd like either no autoformatting at all (big deal, it just appears as either well-known system, like spelling variants) or as now, but not bright-blue and underlined. TONY (talk) 14:38, 8 June 2008 (UTC)

I think user:Scott5114 has expressed several of the same thoughts as I have. The software has combined two orthogonal issues ('this is a link' and 'this is a date'). The issue is very important when there is ambiguity (i.e. slash format dates) but less so when there is no ambiguity (ISO dates, mmm dates, mmmm dates). We are fortunate that most editors write dates in an unambiguous format, I can't recall the last time I saw a slash date here. As user:CharlotteWebb says, on principle, a link that looks like '2005' should not be a hidden link to somewhere else. In practice, such links do not achieve their aim anyway because readers will treat them as solitary years and just ignore them so they are a waste. Like user:Tony1, I want an end to blue linked dates whether in full or in fragmented form. We should simply format the date appropriate for the region. If anyone wants to use automatic formatting, then it should not involve the current mechanism. Lightmouse (talk) 15:06, 8 June 2008 (UTC)

This had been a perennially occurring issue for at least two years. Is there any definitive answer on what the developers' plans are? Are they planning to implement it eventually? Have they decided to never implement it, and simply to ignore all discussion? Bluap (talk) 16:00, 8 June 2008 (UTC)

"If anyone wants to use automatic formatting, then it should not involve the current mechanism." ← What about anyone who wants to click on a year, month, or day and see what other events occurred on that year, month, day... or to see whether the (potentially major) event they are reading about (i.e. the context in which the year, month, or day appears) is properly listed in the article for that year, month, or day... or to use Special:Whatlinkshere to assist in populating year, month, or day articles with topics/events associated with a specific year, month, or day? For one, I fear that explicitly de-linking dates on a non-trivial scale would impede or even stifle the development of year, month, and day articles. This is why I would strongly favor a user preference to render bracketed years, months, and days as plain text (in the user's preferred format) rather than as links.

The counter-argument to that, of course, is that maybe "dates should be plain text by default and we can someday rely on the parser to determine whether or not certain parts of a sentence resemble a year, a month, a day, or a range of years, months, or days, or anything else with chronological significance, which could be reliably auto-formatted according each user's preferences... and... (optionally) appear as links for all the nerds who want to have links." March 2000 feet north and deliver June 3 lost Cleavers and 1 October Sky DVD (director's cut!) and you will understand the difficulty of fool-proofing this approach.

So Scott suggests above that we use a different syntax to inform the parser that a certain string of text is supposed to be a date, one which would accept a greater variety of formats (perhaps even "slash dates" — with a big red "ambiguity error" if the month and day are both 12 or less), and output it the date in whatever format the reader prefers. That would be fine as long as there is an easy way for the reader to make links appear and disappear as desired, ideally as a Special:Preferences setting. — CharlotteWebb 16:27, 9 June 2008 (UTC)

"Mahatma" (Great-Souled) or his name?

The Mohandas Karamchand Gandhi page is again beset with arguments about whether or not its name should be Mahatma Gandhi instead. Since this seems to happen from time to time, I thought I'd bring it up at the Village Pump.

"Mahatma" ("Great Souled") is a honorific, which was first applied to Gandhi around 1915, when he was 46 years old. He himself always signed his name M. K. Gandhi. My understanding of WP:NAMEPEOPLE is that it is very clear on "qualifiers" (which include honorifics). It says unambiguously (off the bat): "Do not have additional qualifiers (such as "King", "Saint", "Dr.", "(person)", "(ship)"), except when this is the simplest and most NPOV way to deal with disambiguation." Since there is no other person with the same name (Mohandas Karamchand Gandhi), the "Mahatma" is not needed for disambiguation. In addition, WP:NC says, "When in doubt, consult a standard mainstream reference work." There are no more standard tertiary sources than the following below and they are all agreed on the name.

1. Encyclopaedia Britannica: (Signed article by B. R. Nanda, Former Director, Nehru Memorial Museum and Library, New Delhi.) "Mohandas Karamchand Gandhi, born Oct. 2, 1869, Porbandar, India, died Jan. 30, 1948, Delhi, byname Mahatma (“Great-Souled”) Gandhi leader of the Indian nationalist movement against British rule, considered to be the father of his country."
2. Encyclopedia Encarta: Gandhi, Mohandas Karamchand (1869-1948), Indian nationalist leader, who established his country's freedom through a nonviolent revolution.
3. Columbia Encyclopedia: Gandhi, Mohandas Karamchand, 1869–1948, Indian political and spiritual leader, b. Porbandar.
4. World Book Encyclopedia. Signed article by Iyer, Raghavan. Gandhi, Mohandas Karamchand. The World Book Encyclopedia, Millennium 2000 Edition. World Book, Inc., Chicago, 2000.
5. Webster's Collegiate Encyclopedia: Main Entry: Gandhi, Mohandas K(aramchand) Pronunciation Guide. Variant(s): known as Mahatma Gandhi Date: (1869-1948). Preeminent leader of Indian nationalism and prophet of nonviolence in the 20th cent.
6. Oxford Dictionary of National Biography. Signed article. Judith M. Brown, (Beit Professor of Commonwealth History, University of Oxford), Gandhi, Mohandas Karamchand [Mahatma Gandhi] (1869–1948)’, first published Sept 2004, 6400 words.

My understanding, therefore, is that the name should remain "Mohandas Karamchand Gandhi." Please advise. Fowler&fowler«Talk» 02:48, 4 June 2008 (UTC)

The only credible argument I could make against you is that the person is more widely-known by the name "Mahatma Gandhi" in the English-speaking world, many of whom are unaware that "Mahatma" is an honorific and not a first name; for this reason, many artists such as Jewel (singer) and Madonna (entertainer) are listed by their stage names, and Lewis Carroll is listed under his pen name, although none of these are their legal names. Nevertheless, I support your position, partly because of precedent in other encyclopedias, and partly because "Mahatma Gandhi" does not clearly refer to a single person. Dcoetzee 19:17, 4 June 2008 (UTC)

• I agree with Fowler's description. WE have articles on many Indian subjects who are referred to by supports with honorific titles such as "Shri". If the subject has a clear birth name that he used himself and that is used by other reference works, then we should avoid using an honorary title in the article name. ·:· Will Beback ·:· 20:35, 7 June 2008 (UTC)

intent of editor

so if we all can edit, is it important to try to keep the orinigal intent of the previous editor esp. if he is the article creator? like tailor your eidts to capture the intent? JeanLatore (talk) 03:13, 4 June 2008 (UTC)

No, Wikipedia has an overarching set of editorial guidelines and policies that all articles should be tailored to conform towards, and on substantive issues this will generally take preferences over the intent of any one contributor. (Though there are some purely stylistic issues where the policy is simply to follow the original author, such as whether to use British or American spelling of words.) See Wikipedia:Key policies and guidelines and Wikipedia:Manual of Style. Since you talk about "intent", you might also look at WP:NPOV for a discussion of how topics should be presented. Dragons flight (talk) 03:22, 4 June 2008 (UTC)

But even a regional-variation-of English choice by the originator of the article can be overridden if the topic of the article suggests that it should be written in another regional variation. I point this out to highlight that no original intention by the article's creator overrides what is best for the article itself. Darkspots (talk) 12:42, 4 June 2008 (UTC)

Nope. It's important to form communal consensus around the way in which an article should be presented and what facts it should include, but no author has priority over any other. Dcoetzee 03:23, 4 June 2008 (UTC)

"If you don't want your writing to be edited mercilessly by others, do not submit it". Mr.Z-man 03:25, 4 June 2008 (UTC)

The previous editor does not WP:OWN the article, so you can meddle with the intent as long as neutrality and the intent of the sources used are maintained. The only time you'd want to be sure to maintain original intent is if you're marking an edit as minor.Somedumbyankee (talk) 03:26, 4 June 2008 (UTC)

There are editors who start articles as they are very good in identifying blank spots in the encyclopedia. Often these blind spots relate to their own hobbies. This may easily lead to a biased point of view. That makes the original editor still a very valuable contributor, but his intent may need to be modified to provide high quality content. Arnoutf (talk) 06:22, 4 June 2008 (UTC)

New global userright

I have started a centralized discussion at Wikipedia_talk:Administrators#New_global_userright on how our local policy should reflect changes to the global user rights policies at Meta. Please feel free to stop by and comment. MBisanz ^talk 22:26, 4 June 2008 (UTC)

make stub templates more useful with suggested content

Stub templates would be more useful if they suggested subject-related content. For example, if I create a page for Joe Blow that says "Joe Blow once played national football", someone else might tag it with football-bio-stub. If I click on the link, it might suggest that I add some details like date-of-birth, nationality, what countries he played for on what dates, and what, if anything, made him a notable player. Even better would be if there were an associated infobox and/or ProfessionalAthleteData, with a nice form to prompt for the data. --BobBagwill (talk) 23:47, 4 June 2008 (UTC)

Might be workable by linking to a relevant wikiproject, perhaps? – Luna Santin (talk) 02:27, 5 June 2008 (UTC)

• I agree more generally that it would be great to be more specific. I think any criticism on an article via a template should be accompanied by a linked-to talk page section which details the complaints. I hate seeing tagged articles when it is totally unclear what the problem is.  — Xiutwel ♫☺♥♪ (speech has the power to bind the absolute) 05:04, 5 June 2008 (UTC)

If there were some way to find "ex-stubs" in a given stub category, then you could look at what kind of expansions people have done to them. I don't see a way to easily do that though. Wikiprojects who have an interest in a given stub category might put some sort of "expansion tips" in the category's headnote, maybe? --_{tiny plastic} Grey Knight ⊖ 14:48, 5 June 2008 (UTC)

• I agree with Luna Santin that the relevant WikiProjects will probably have informations on infoboxes/resources/style guides etc. available. So actually, flipping over to the talk page and clicking on the WikiProject banner will be the best alternative. Of course one could somehow add this to the stub template line, but would that really be necessary? --B. Wolterding (talk) 14:58, 5 June 2008 (UTC)

Proxy votes/meatpuppetry

Would "proxy votes" be considered a form of meatpuppetry? Specifically, established User X is going to be away for a few days, and gives permission to established User Y to vote on his behalf in exactly the same way as User Y, since they know that they agree on everything. — Omegatron (talk) 03:17, 5 June 2008 (UTC)

That assumes that discussions are votes, which in most situations they're not. That said, if a given user's absence is particularly important to the discussion, it may be worth making a note of it. – Luna Santin (talk) 03:50, 5 June 2008 (UTC)

Well yeah. I already mentioned "we don't make decisions with votes" a few million times, but it falls on deaf ears. — Omegatron (talk) 03:52, 5 June 2008 (UTC)

Does X allow Y to sign in as X ? Or does Y mention that X has the same opinion? The first seems problematic to me, the second should be allowed but ignored...  — Xiutwel ♫☺♥♪ (speech has the power to bind the absolute) 05:02, 5 June 2008 (UTC)

No sharing of accounts; just saying "I'm going to be away for a few days, you have permission to double-vote with my username next to yours in each of the votes you propose." — Omegatron (talk) 23:06, 5 June 2008 (UTC)

I can't really think of any situation where an admin or crat would take such a proxy vote seriously. Resolute 03:05, 6 June 2008 (UTC)

If I understand correctly, this is similar to Wikipedia:Delegable proxy, a failed proposal. The talk page there should give you some things to read on the subject. "Meatpuppetry" was mentioned a few times, right enough. --_{tiny plastic} Grey Knight ⊖ 14:46, 5 June 2008 (UTC)

Interesting.  :) — Omegatron (talk) 23:06, 5 June 2008 (UTC)

Banning solves false flag related NPOV disputes?

I've notived that a huge number of editors has been topic-banned in the wake of an ArbCom case, even though the ArbCom did not give a single verdict on any specific behaviour by anyone. I myself have been topic-banned, ironically, after issuing a warning myself: {{Uw-9/11|{{{2}}}}}

Now I am interested to know whether there is only a small kernel of wikipedia editors and admins who happen to be interested in September 11, and favor banning other editors, or whether this approach of solving POV conflicts by banning one side of it, is supported by the community at large?

In my perception, edit conflicts are arising between two point of views, whereas those that are doing the banning seem to think that their POV is the truth and therefore the NPOV form that articles should have, and they call the editors to be banned "POV-pushers", whereas in my opinion, most of them are only trying to restore NPOV: make sure that multiple POV's get fair treatment.

For instance: would citing the 9/11 Commission Report likely be POV-pushing? Would factual descriptions of actions of government officials be POV-pushing? Would mentioning the opinions of prominent international polititians be?

If wikipedia is locking out so many editors, it really amounts to locking oneself in.

It's not just the subject of 9/11 which is at stake for me. I can live with the English language Wikipedia being inadequate on such a sensitive subject (other languages seem to have less problems here). Everyone has the freedom to his or her own beliefs. When a vast majority of editors is unable to detect false flag operations, so be it.

What concerns me, is that the same mechanisms seem to be at work all over wikipedia. Wikipedia is valuable to me because of the NPOV policy: the reader is likely to be presented multiple viewpoints on a given subject, which the rest of the web often fails to do. If we loose our understanding of true NPOV, than Wikipedia sinks back in the background noise of the web. I'd hate that !

 — Xiutwel ♫☺♥♪ (speech has the power to bind the absolute) 05:00, 5 June 2008 (UTC)

Anyone interested in the discussion about this user's Arbcom-related ban should read Wikipedia:Administrators' noticeboard/Arbitration enforcement/Archive20#Xiutwel. I see nothing wrong with this approach, when extreme amounts of disruption, as cited in the Arbcom case, require it. Mangojuice^talk 16:01, 5 June 2008 (UTC)

Is it really within our behavioral guidelines to issue preemptive warnings like {{uw-9/11}}? "Hi. You haven't done anything yet, but I'm going to assume you're likely to be bad" seems rather bitey and not assuming good faith to me. Anomie⚔ 00:51, 6 June 2008 (UTC)

Sourcing Adjudication Board

This is a follow-up to the recently archived discussion WP:Village pump (policy)/Archive_47#Sourcing_Adjudication_Board regarding the Sourcing Ajudication Board that ArbCom intends to set up as a part of its ruling in the ongoing case Wikipedia:Requests for arbitration/Homeopathy/Proposed decision.

To remind those who missed the original discussion, ArbCom plans to appoint the Sourcing Ajudication Board with broad jurisdiction over all sourcing disputes on Wikipedia.

The ArbCom now expaneded the language of the proposed decision (now in the voting stage) to include the following:

"Expedited sanctions

2) Upon receipt of a finding of inappropriate conduct from the Sourcing Adjudication Board, the Committee shall, without opening a case, issue appropriate sanctions (up to and including a ban from the project) against those editors named by the Board as having substantially violated sourcing policy."

There is an ongoing discussion of the SAB proposal at Wikipedia talk:Requests for arbitration/Homeopathy/Proposed decision. Nsk92 (talk) 07:43, 5 June 2008 (UTC)

Wikipedia:Attribution has been marked as a guideline

Wikipedia:Attribution (edit|talk|history|links|watch|logs) has recently been edited to mark it as a guideline. This is an automated notice of the change (more information). -- VeblenBot (talk) 18:48, 5 June 2008 (UTC)

Wikipedia:Attribution/Header has been marked as a guideline

Wikipedia:Attribution/Header (edit|talk|history|links|watch|logs) has recently been edited to mark it as a guideline. This is an automated notice of the change (more information). -- VeblenBot (talk) 18:48, 5 June 2008 (UTC)

Wikipedia:Template messages/Wikipedia namespace no longer marked as a policy

Wikipedia:Template messages/Wikipedia namespace (edit|talk|history|links|watch|logs) has been edited so that it is no longer marked as a policy. It was previously marked as a policy. This is an automated notice of the change (more information). -- VeblenBot (talk) 18:48, 5 June 2008 (UTC)

starred Language

Why is there a language starred in the language box? —Preceding unsigned comment added by 142.1.129.29 (talk) 20:57, 5 June 2008 (UTC)

Featured article in the "starred" language sister project Arnoutf (talk) 21:29, 5 June 2008 (UTC)

It means that article is a Featured Article on the corresponding-language Wikipedia version. --_{tiny plastic} Grey Knight ⊖ 15:51, 6 June 2008 (UTC)

Is there an echo in here? --_{tiny plastic} Grey Knight ⊖ 15:52, 6 June 2008 (UTC)

Please Post On Bugzilla, Thanks!

I would be great if we could click on the version instead of having to have to click on the 2 radio buttons just to get to the later version. Please post this on bugzilla, because I don't have an account, thanks!68.148.164.166 (talk) 02:22, 6 June 2008 (UTC)

Clicking on the time/date stamp to the right of the radio buttons brings up that version. You don't get the comparison chart, because you need to specify 2 versions to be compared. Is this what you're looking for? --A Knight Who Says Ni (talk) 04:45, 6 June 2008 (UTC)

Wikipedia:Notability

I honestly don't think this is necessary, nor any of it's associated other pages. If content complies WP:V, WP:OR, WP:NPOV and WP:NOT then surely it should be included? I'd like to know what other people think.--Phoenix-wiki 13:38, 6 June 2008 (UTC)

No, we have our standards for a reason. We're an encyclopedia not a directory of everything that has been mentioned ever. Al Tally ^talk 14:09, 6 June 2008 (UTC)

Of course we're not, which is what WP:NOT is for. While wikipedia discriminates against such things as opinion columns and speculation, the policy associated with wikipedia is not an indiscriminate collection of information does not discriminate against notability. The policy lists specific things that articles cannot be - none of these taboos mention that non-notable aren't allowed, although non-notable articles must still establish importance or the topic's "claim to fame".--Phoenix-wiki 14:20, 6 June 2008 (UTC)

Agreed. (BTW, V, OR and NPOV (bar POVFORK) are content criterion, so they can't render N redundant anyway). Orderinchaos 14:14, 6 June 2008 (UTC)

Unreferenced articles can be deleted, and I don't see the problem. Why should we keep out stuff like Garage bands? In practice, it would be very difficult to make the article verifiable, but if someone manages it, there's nothing wrong with letting it sit unviewed. Saying that something "does not belong" is not a reasoned argument; what are the costs and benefits?--Phoenix-wiki 14:20, 6 June 2008 (UTC)

None of the three are in fact deletion criteria - if they're being used as such, they're being used improperly. An article which can pass WP:N but which may have problems in *all* of the other three would always be kept providing there was no outright consensus to delete, but with a recommendation to fix urgently. If the problems are so major as to cause major concern (eg BLP) it's usual to stub the article. Orderinchaos 14:26, 6 June 2008 (UTC)

They aren't common deletion criteria at AFD, but take a look at the new sourcing adjudication board proposal, and new page patrol. Unreferenced material may be removed per WP:V, and I for one am prepared to do this. (See also:[2])--Phoenix-wiki 14:33, 6 June 2008 (UTC)

Phoenix, this page is for discussing policy. "Notability" has never been policy and by the grace of G-wd never will be . — CharlotteWebb 14:42, 6 June 2008 (UTC)

Lol Well It might as well be a policy, and the only other place this fits is misc, which isn't exactly where it fits, though according to that narration at the top, this is for guidelines too ;-)--Phoenix-wiki 14:45, 6 June 2008 (UTC)

Actually, since the deletion policy says a topic not meeting the notability guidelines is a reason for deletion, the notability guidelines are often treated like policy — somehow ABOVE WP:V, WP:NOR, and WP:NPOV. Mentions of "notability" have been creeping into WP:NOT, another policy. An essay, WP:ATA, is cited whenever anyone gives their personal opinion that something is notable. But that's all "nn" ever was — an opinion in AFD debates. And "nn" was flipped and turned into WP:NN in a horribly misguided move. Now, I've argued to delete because I thought something was non-notable too, but that's just my personal opinion...out of billions.

I think many of the current notability guidelines need to be deleted or re-started from scratch. The problem though with guidelines is that once created, they're rarely deleted. So I guess I would support marking them rejected or historical, and at least disputed. I suppose one could even create a competing guideline about the "presumed" notability across an entire group of subjects — although creating parallel guidelines is discouraged. Some topics are generally considered to be notable by default — mountains and cities for example. If editors want to say that a topic needs outside coverage before a topic can have an article, that's fine I guess — but coverage does not make something worthy of notice. WP:N should be deleted. I can understand why coverage would be a good idea for biographies of living people, bands, and some other topics, but "notability" has become a black hole that no topic can escape.

What started as an excuse to get rid of articles on garage bands and people/websites nobody cared about has transformed into Frankenstein's monster. Is Frankenstein's monster notable? This isn't the Notability Project anyone can edit. And I've seen no evidence that other encyclopedias use "notability" as their criteria for inclusion. The Wikimedia Foundation's vision statement is "the sum of all knowledge", not "the sum of all knowledge that's worthy of notice." — and who exactly is it supposed to be "worthy of notice" to anyway? The notability guidelines are a prime example of how inventing new rules you think everyone else should follow is actually detrimental to Wikipedia. If it's common practice for people to argue to delete an article because they think a topic is non-notable, fine, tell people that. If it's common practice for people to argue to keep an article if it cites a lot of outside coverage, fine, tell people that. But don't create a new round hoop while thousands of square articles are laying around and say "These square articles don't fit through this new hoop I invented!" Wikipedia was not paper and Wikipedia was not a bureaucracy, LONG before Wikipedia mutated into the Notability Project.

Do I think Project Chanology is worthy of notice? No. Do I think the article should be deleted? No. I'm sure someone else thinks it's worthy of notice. Do I think every topic in Encyclopedia Brittanica is worthy of notice? No, and it doesn't have to be. Is there some way to quantify the "value" of attention? The DGAF scale? Is the thinking that because certain sources have "noted" a topic, then the topic must be "note-able"? Does a source writing about a topic mean they think the topic is worthy of notice, or that they have a mortgage payment this month? The notability guidelines are, for the most part, broken. And I blame Radiant! for starting this mess, by tagging WP:N as a guideline after 16 days. I can understand that "Wikipedia is not an indiscriminate collection of information." But the notability guidelines are not what keeps Wikipedia from becoming an indiscriminate collection of information. No, what keeps Wikipedia from becoming an indiscriminate collection of information are editors. Editors are trusted to use their judgement to evaluate whether an article is neutral or not. Do editors have to provide outside evidence that an article is neutral? No. So why can't editors use their judgement to evaluate whether a topic is "notable" or not? Even better, remove the whole question of "notability" from the equation. What does "notability" have to do with encyclopedia articles? --Pixelface (talk) 19:51, 6 June 2008 (UTC)

Hear hear!--Phoenix-wiki 20:07, 6 June 2008 (UTC)

Notability guidelines might as well be policy, unfortunately. Hopefully one day we'll see them gone. While it isn't an opinion held by many editors, I would rather see a low-quality article with a few sources on an obscure subject than no article at all. I think that it'll be gone eventually once Wikipedia is mature enough. Celarnor ^{Talk to me} 20:32, 6 June 2008 (UTC)

Interesting. The reason I created this thread was to get rid of it in the very near future (The next month or so).--Phoenix-wiki 20:49, 6 June 2008 (UTC)

If you believe that we do not need notability, try doing some new page patrol. Notability provides us with a way to delete the tripe. Maybe we don't technically need notability due to our other, more important policies. However, 'notability' is easy to judge- it can be quickly judged, and the crap can be deleted. Our other policies require a little thought, and we just don't have that time, nor can we afford for the piles and piles and piles of rubbish to stay lying around while we all argue about whether it is technically verifiable. I just don't think that removing notability is, at this time, a good idea. It would create far more problems than it would solve. J Milburn (talk) 21:10, 6 June 2008 (UTC)

There's no speedy deletion criteria for being non-notable, and the usual crap falls under WP:NOT, the rest of the non-notable stuff, why not keep it if it's verified etc?--Phoenix-wiki 21:40, 6 June 2008 (UTC)

"Notability provides us with a way to delete the tripe" ← If no other concerns apply, I seriously doubt the content is "tripe". — CharlotteWebb 19:11, 7 June 2008 (UTC)

Something could easily be verifiable without being notable - a minor mention, a mention in a minor publication, or a mention in a source that is reliable for what it is cited for but not reliable to establish that it's worth reading. Almost every person, thing, and business establishment has been mentioned in the paper - who hasn't had their name in the paper? So with a verifiability standard alone, nearly everything in the world could be the subject for an article here. That would be nice but it's not going to happen, and if it did it would be a much very different project than Wikipedia. With the number of volunteer editors we have, we simply can't write a good article and keep enough interest to maintain it, about everything in the world. If we try, coverage will be spotty and uneven, we will have lots of bad articles, and visitors will have a lot of junk to wade through before they find anything useful to read. That's one of the main argument for notability, in my mind. Also, being forced to explain why something is notable helps article creation - it makes editors cut to the chase and state, concisely, why something matters. Practically, more power to you if you want to make a change but it seems very unlikely that enough people could be convinced to do away with the notability requirement. Wikidemo (talk) 21:14, 6 June 2008 (UTC)

You seem to be confused here. We want to let the previously non-notable things in, and not bother with notability at all. WP:NOT keeps out most of the crap. We're not saying to go out there and launch a drive to create the articles (I persoanlly think we should get our topics up to scratch first, they're a disgrace), but if some random new editor creates a verifiable, neutral article about their pet dog, why would we delete it? In practice, it would be very difficult to make the article verifiable. But if someone manages it, there's nothing wrong with letting it sit unviewed.--Phoenix-wiki 21:40, 6 June 2008 (UTC)

I couldn't get behind articles for pet dogs and I suspect most people couldn't either. --Pixelface (talk) 21:57, 6 June 2008 (UTC)

They would be almost impossible to reference, but if they were good and verifiable, why not?--Phoenix-wiki 22:01, 6 June 2008 (UTC)

Because Wikipedia is not your personal webhost, and if the dog is dead, Wikipedia is not a memorial. --Pixelface (talk) 22:08, 6 June 2008 (UTC)

That's not per WP:N then, that's WP:NOT, which, while debatable and lacking an objective set of criteria, is certainly more objective than WP:N, which is just not needed.--Phoenix-wiki 22:20, 6 June 2008 (UTC)

An important point to note here is that WP:NOT, while it contains some inclusion (or more specifically disclusion) guidelines, is mostly content and behavior issues - things that can be fixed without removing articles. While notability is mentioned in NOT, it is not called out as a specific guideline that falls under NOT. In other words, for the bulk of articles on WP, NOT does not say anything about if they should stay or go, only about their content. We need some inclusion guideline to keep WP maintainable and not an indiscriminate collection of information. Thus, we need something like NOTE to have that inplace. --MASEM 23:11, 6 June 2008 (UTC)

Wikipedia is whatever its users want it to be. If you think that the notability guidelines are no longer supported by the community, then start a discussion to abandon them. But from what I've seen, they're pretty well accepted and I don't think you'll be able to convince enough people to abandon them, but you're free to try. Considering we have WP:IAR, whether WP:N is policy or guideline is mostly irrelevant. Mr.Z-man 21:58, 6 June 2008 (UTC)

Can't you just go and create the articles on whatever you like without worrying about this? More than likely it will be noteworthy, and even if it has no refs, if you write well and it's beleivable and all people normally just ignore the fact that it has no references and take your word for it.--Serviam (talk) 22:18, 6 June 2008 (UTC)

You know, I was going to argue against this, on the basis that not everything that is verifiable really merits inclusion in Wikipedia, but then I realized that WP:NOT already says that anyway. In fact, having actually read that policy in its entirety, I've come to feel that Phoenix-wiki's suggestion might not really be a bad idea at all. The point being that most of the notability guideline is actually redundant with various sections of WP:NOT, whereas I'm not at all convinced that the remainder is all that useful in the end. To take an example, it would be extremely difficult for an article on a garage band or a student club to pass all of WP:V, WP:SOAP, WP:FUTURE and WP:INDISCRIMINATE; but if it did somehow clear all of those hurdles, it might well be worth having. Of course, if we did get rid of WP:N, I'm sure some of its content would just end up moving to WP:NOT, insofar as it's not already covered there. I'm not convinced that this would necessarily be a bad thing. —Ilmari Karonen (talk) 22:49, 6 June 2008 (UTC)

• First, this discussion should be at Wikipedia talk:Notability. This village pump was, I thought, for notices about discussions elsewhere. Second, people sometimes forget that notability applies to articles, not to the information contained in an article. Sometimes verifiable information is presented under too specific and non-notable a title, and the solution is not to delete, but to merge the information to the correct location. Notability is, in essence, less about deletion, than about correct presentation of information: ie. arrange material so that the notability is obvious to the reader as they read the article. Put minor stuff within an article, rather than creating a new one. Get the balance right within an article (per WP:UNDUE and WP:NPOV). Another way to look at it is to say that WP:UNDUE and WP:NPOV concern the arrangement and presentation of verifiable information within individual articles, while WP:NOTABILITY and WP:NOT concern the arrangement of information within the encyclopedia as a whole, and to what degree the information should be distributed between different articles, or presented in its own article. All these references to information refer to, of course, verifiable information. Does this way of looking at things make sense to people? Carcharoth (talk) 23:28, 6 June 2008 (UTC)

I think notability is such a basic policy of Wikipedia, it wasn't initially called out, but just asssumed as obvious in WP:NOT, and should be strengthened, not weakened. And I agree that the discussion should move to Wikipedia talk:Notability. --Alvestrand (talk) 07:35, 7 June 2008 (UTC)

The problem with relying on WP:NOT is that this policy is consistently under attack from the uber-inclusionists as well, including some of those that have commented above. A quick perusal of the wikilawyering and edit warring at WP:NOT and WT:NOT over the last few months would be useful. If we really want Wikipedia not to be an encyclopedia, but a repository of everything that has ever existed, this would be a good way to do it. Black Kite 10:38, 7 June 2008 (UTC)

Notability is important. Wikipedia is an encyclopedia, and every topic must be worthy of notice. Every time someone creates an article about a garage band, or their WoW guild, or their fanfiction, Wikipedia gets worse. Wikipedia grows ever more unreliable with every assertion that some gaming clan is "THE GREATEST EVAR!" People will, in good faith, claim a MySpace page is a good source for their garage band. With a project this size, a line must be drawn in the sand, and reliable secondary sources is a good place for that line. --Phirazo 04:35, 8 June 2008 (UTC)

I'm inclined to agree with you; but RS already requires that reliable sources be present for articles, and myspace simply doesn't qualify. Having a guideline that says "you need at least two RS for an article" is all fine and good; its when there gets to be too much creep (ATHLETE, CORP, MUSIC), that it becomes a problem. Things are no longer eligible for inclusion because they have secondary sources discussing them; they're eligible for inclusion because of some other arbitrary criteria (played on one of a set number of teams, an album in a set number of labels, etc). I don't have a problem with something saying "you need RS for an article", thats simply obvious and part of being an encyclopedia rather than a vast repository of FRINGE and OR, but all the separate notability guidelines create a lot of problems. Celarnor ^{Talk to me} 06:53, 8 June 2008 (UTC)

WP:ATHLETE (and the rest of WP:BIO), WP:CORP, WP:MUSIC, and so far as I'm aware all of the other secondary notability guidelines state that the main criterion is the presence of reliable sources. They identify cases where we accept articles even when there aren't any reliable sources. I'd be perfectly happy to get rid of them all and cut our content back to what can be sourced, too, but I suspect for reasons diametrically opposed to yours. —Cryptic 07:47, 8 June 2008 (UTC)

I am of two views on this one. Notability is important but it is used as an indiscrimate weapon in deletion debates. I think the notability guidelines are quite suitable to invoke on content debates for any given article. In those cases, both sides of the debate must make their notability claims with vigor and well cited sources. On the other hand, deletion debates are a poor place for notability discussions because any editor can merely say Not Notable without justifying it. This happens all too often when editors with little or no content knowledge on a subject weigh in on a deletion debate. They just say its not notable as if they really knew that. If they know its not notable, then they need to cite some evidence to that effect by challenging the evidence that others claim make it notable. In content debates, notability ought to endure rigourous scrutiny. In deletion debates, notablity ought to be assumed unless there is indisputable evidence that something is not notable.--Mike Cline (talk) 12:40, 8 June 2008 (UTC)

I think you'll find that plain Keep votes claiming "It's notable" are far more likely to occur than Delete "It's not notable". Surely if we are going to have quality articles, the burden of proof should be on article editors to show that something is notable? Black Kite 14:21, 8 June 2008 (UTC)

I agree with your 2nd thought wholeheartedly. However, my experience with deletion debates tells me that when notability guidelines are cited, its not a debate about the actual evidence or lack of evidence of notability, but merely a Its Notable--No Its Not Notable exchange. I would much rather see a deletion debate made on real notability substance rather than an exchange without substance. Here's a typical entry: Delete Fails my notability checking. Had this entry said: Delete Sources A and B do not meet the criteria for notability because ...... the debate would be on substance, not opinion.--Mike Cline (talk) 17:29, 8 June 2008 (UTC)

Of course. Conclusively proving that something isn't notable is basically impossible, you have to prove a negative - that there aren't any sources. Whereas to prove that something is notable, you only have to show that some sources do exist. Mr.Z-man 22:55, 8 June 2008 (UTC)

WP:N was created precisely because people were saying "Delete, it's not notable" in AFD debates. That statement was then twisted around into "Every topic on Wikipedia should be notable" — instead of what it should have been, "If you create an article and editors think it's about a non-notable topic, there's a good chance the article will be deleted." Black Kite, are you also saying that the burden of proof should be on article editors to show that something *is* neutral? That significant views *are* presented "fairly"? Editors should cite some outside evidence for an article's neutrality? If editors don't have to prove an article is neutral, why must they prove the topic is notable? Notability is totally subjective and varies from person to person, group to group, culture to culture, place to place, and time to time. The quality of an article doesn't depend on whether the topic is "worthy of notice" or not. --Pixelface (talk) 08:59, 9 June 2008 (UTC)

Personally I see the concept of notability as it is used currently on Wikipedia primarily as a way of enforcing our core (and not really contested) inclusion standards of no original research, verifiability and neutral point of view. Take the base notability criteria - "If a topic has received significant coverage in reliable sources that are independent of the subject, it is presumed to be notable.". If there are no reliable sources on a topic it will not be possible to verify the information within the article (WP:V), if those sources are not independent of the subject they are likely to have inherent bias (WP:NPOV) and if the topic hasn't received a certain level of coverage then it won't be possible to write a coherent article without editors introducing their own work (WP:OR). There are exceptions such as with fictional elements where primary sources are considered a reliable basis for an article, in those situations it really becomes an editorial decision rather one of delete/don't delete on how the information should be presented (as lists, group articles, individual articles, etc.) and how much detail is appropriate for the encyclopaedia. Guest9999 (talk) 16:51, 8 June 2008 (UTC)

LOL at the remark about "what started as a rationale for getting rid of articles about garage bands" because that is totally correct. Seriously, notability has become a big stick for the deletionists to whomp around, and I'd love to see it gone. Obscure crap is one of the things Wikipedia does best. :) I'd LOVE to kill that notability business. Barring that, could I please have a stick labelled "persnickety bitches" that I can use to whomp all the deletionists with. I've said it before and I'll said it again: We're all nerds by dint of being Wikipedia editors, but he who has nothing to contribute ornothing better to do than patrol, deletion and fuss his or her way through the Wiki bureaucracy is a sad, sad soul. Get a life. Or maybe just go away and leave us alone. If you only have negative energy to contribute, get the eff out of here. jengod (talk) 15:50, 9 June 2008 (UTC)

"primarily as a way of enforcing our core [...] standards of no no original research, verifiability and neutral point of view" ← This is also how "BLP" was advertised in the beginning. How ironic. — CharlotteWebb 16:41, 9 June 2008 (UTC)

Flagged revision talk

Now that flagged revisions are available on all projects, we need to figure out what en-wiki is going to do with them. Many people have made their opinions known in smaller discussions or on the mailing lists, but for an issue this big I think we need to set up one big centralized discussion page for everyone in the project to give their two cents, possibly set up in a way that lets us tally support for each of a few different setups. --Arctic Gnome (talk • contribs) 16:09, 6 June 2008 (UTC)

You mean like Wikipedia:Flagged revisions? Bluap (talk) 16:57, 6 June 2008 (UTC)

That page is an example of a collection of small conversations. I think to reach a final conclusion we'll need a more formalized process of arranging the various proposals and have a pre-determined way of deciding on which we have consensus. --Arctic Gnome (talk • contribs) 17:36, 6 June 2008 (UTC)

And that should take place at Wikipedia talk:Flagged revisions, not here, or anyplace else. Of course you can add links to there from here for 'advertising'. - Rjd0060 (talk) 14:58, 7 June 2008 (UTC)

Recursive page moves (rev:33565) is a great tool for vandals

I started a thread at WP:VPT#Recursive page moves (rev:33565) is a great tool for vandals which may have been appropriate here too. All are welcome. —Wknight94 (talk) 01:12, 7 June 2008 (UTC)

Diacritics in tennis

I'm not sure I can fully keep up with everything that's going on regarding moves of tennis players, but the main discussion seems to be here. The question is whether foreign tennis players' names should include diacritics. In any case I think we badly need a general policy on such matters, so it isn't decided separately (and likely inconsistently) for every sport or particular line of activity.--Kotniski (talk) 08:02, 7 June 2008 (UTC)

Wikipedia:Naming conventions (use English)#Modified letters, WP:NCP. What name do publications in English (i.e. Sports Illustrated) use? If they've played at Wimbledon or the U.S. Open, how are the names spelled at those events? Somedumbyankee (talk) 16:05, 7 June 2008 (UTC)

It would be better for the above editors to join the discussion at Wikipedia:Requested_moves/Tennis. If that thread doesn't come to an agreement I don't see how we'll be able to adopt a general policy here. As threads go, it is not a bad discussion, and it is somewhat cooperative. EdJohnston (talk) 16:35, 7 June 2008 (UTC)

Seems to me that there's only 26 letters in the English alphabet, and we should stick to those for article titles. Remember that some users may not have the necessary fonts to display some of those exotic accent marks. Squidfryerchef (talk) 20:22, 7 June 2008 (UTC)

Can we have wp:mosnum back?

The wp:mosnum policy page cannot be used for reference because it contains non-policy. Anyone that reads it could be mislead into thinking that non-policy is policy. This is acceptable to the people that are controlling wp:mosnum now. Anyone that tries to remove non-policy is just reverted.

The wp:mosnum talk page used to be active with discussions on a variety of topics. It is now dominated by the binary prefix war and its collateral damage. The binary prefix war was moved to a page called Wikipedia talk:Manual of Style (binary prefixes) but that lasted just a shortwhile before the page and the warfighting was moved back. It is a place for sockpuppets, puppetmasters and anonymous editors. They keep saying that the war will soon be over and then normal service will be resumed ...

The policy page and its talk page used to be worthwhile places. It had contributions on a variety of topics from many editors. Sadly, the policy page is not reliable and the talk page is scary. Does anybody have any suggestions as to how we can have a policy page and talk page where things other than binary prefixes matter? Lightmouse (talk) 15:47, 7 June 2008 (UTC)

Please respond at: Wikipedia talk:Manual of Style#Can we have wp:mosnum back?

Can you explain to the rest of us what "mosnum" is and what in the world "binary prefixes" are? Squidfryerchef (talk) 18:32, 7 June 2008 (UTC)

Apologies for the abbreviation, wp:mosnum is the abbreviation that you can type into the search field, it goes to Wikipedia:Manual of Style (dates and numbers). As for binary prefixes, it is a huge tedious war in the bit/byte community over 1000 versus 1024. Lightmouse (talk) 19:04, 7 June 2008 (UTC)

Is this the whole "kibibytes" nonsense? I've just started seeing that and my own opinion is its a borderline neologism that nobody uses in the computer industry. It also sounds like a brand of dog food. Squidfryerchef (talk) 20:11, 7 June 2008 (UTC)

Diacritics proposal

Further to the penultimate section, I have started constructing a proposal to make explicit our general policy on diacritics. Improvements and comments are welcome here.--Kotniski (talk) 05:37, 8 June 2008 (UTC)

Wikipedia "Probation," rehabilitation of problem users, and article improvement

An idea came to me this weekend as I was reading about users, who for whatever reason, have been placed on "probation" (either under "community" supervision or the supervision of a single "mentor"). My theory relies on the tenet that the best way to improve Wikipedia is 1) through the writing of new articles on notable subjects and 2) through the addition of clearly-written, NPOV, and referenced edits to existing articles. Users placed on community oversight or probation should therefore be required as a condition of their probation to make a certain number of reliably sourced, well-written article edits each month. Failure to do so would result in the revocation of the probation and the blocking of the user (indefinately if necessary). Those users who are incapable of constructive improvement of the articles directly, however, could be assigned to assist an editor in good standing or a group of article-contributors (like a wiki-project), where the user on probation would do research for the editor, write memoranda, and copyedit the prose of his "mentor." I think of it as "community service" requirement of probation.

This can only be a benefit to the encyclopedia, as not only will this result in literally thousands of good article edits a month, but also will teach the probationer-users the value of research, good writing skills, and how to work with others the Wikipedia way. As always, I appreciate your thoughts. Thanks, JeanLatore (talk) 00:44, 9 June 2008 (UTC)

I'm a bit more skeptical that trying to force people to do some sort of "community service" will really result in much of an improvement to the encyclopedia. More likely, it will just drive the person away or result in half-assed contributions that are little better than nothing. It also IMO violates the Wikipedia principle that such actions should be preventative of future problems rather than punitive for past actions. Anomie⚔ 01:23, 9 June 2008 (UTC)

But it is preventative, not punitive. If a probationer is busy writing articles and doing research for his study-group or mentor he has less time for disruption. And if it drives the person away, tis no big loss, since the "probation" would have been imposed in lieu of a ban anyway. JeanLatore (talk) 01:37, 9 June 2008 (UTC)

As shocking as it seems, some Wikipedia editors are grown-ups. We can't very well require that they do any work at all, since they might have other obligations. I edit WP whenever I get the urge and I'm sure that many probationary editors do the same. Putting them on a work schedule seems unfeasible and counterproductive. Phiwum (talk) 02:06, 9 June 2008 (UTC)

Why is it "counterproductive"? The situation will either stay the same or get better -- keep in mind the proposal calls for "reliably sourced, well-written article edits each month," not simply any edits to articles will do. Edits that are simple spamming or tagging simply won't count. And this proposal is quite feasible, given that it would be extended in lieu of a total ban. Thus it would give the user a second chance, can only be a benefit to the project, and would serve as rehabilitation. JeanLatore (talk) 02:13, 9 June 2008 (UTC)

It is counter-productive because there's a strong possibility that it can drive people away and make them no longer want to participate. The tenets of the projects are openness and that anyone can be redeemed. Indefinite blocks are extremely rare and are only used in the most egregious of circumstances. Anyone can be 'rehabiliated', and it is left up to the user to figure out how best to do that; it doesn't matter *how* they redeem themselves, just that they do, whether it be contributions in the mainspace, MedCab, RfA, reasoned arguments at XfDs or policy proposals. Having a hard-set "This is what you have to do or you get blocked" doesn't really make sense. People get blocked because they've done something incredibly stupid or wrong, have gotten warned multiple times (as you were before your block for incivility) and haven't gone along with policy. A block is a block. It's meant to be a block, to prevent them from doing anything further to damage the project, and hopefully knock some sense into them as a result. Celarnor ^{Talk to me} 03:55, 9 June 2008 (UTC)

An interesting and novel idea, but I don't like it. More likely than not, it's just going to drive people away. Like some other things that you've said elsewhere, this really brings to light the fact that you don't realize that there's a lot more to Wikipedia than sourcing and article-writing. You have to remember that not everyone here is a writer; we have people who spend most of their time in the Wikipedia space discussing policy or on the noticeboard giving their opinions on various things, other people who spend most of their time reverting vandalism and dubious unsourced statements from articles, people who spend their time copyediting, and people who spend their time at XfD discussing what does and doesn't merit inclusion in the mainspace. There are many things that have to happen here to make a quality encyclopedia, and as odd as it may sound, writing articles is only one of them. Regulating the behavior of editors so they *have* to make edits seems counterproductive to me; its important that we don't regulate off-wiki behavior, and forcing people to either stay on-wiki long enough to make so many edits a month constitutes exactly that. Celarnor ^{Talk to me} 03:55, 9 June 2008 (UTC)

Indeed an interesting and novel idea. I think some of the editors on probation are there because they honestly don't understand how to contribute, and some 'rehabilitation' process may help them. Others I am not sure about, and I seriously doubt we can find enough capable, professional, and more than all patient editors who could be the tutor in the process. So although the idea sounds sympathetic I seriously doubt it will ever fly. (besides this is agree with some of the above issues) Arnoutf (talk) 13:45, 9 June 2008 (UTC)

While I don't support the idea because it seems punitive and fails to consider the personal motivations (and abilities) of individual editors, I think it's worth a try. Specifically, I think JeanLatore should try it themselves. Decide on the number of "reliably sourced, well-written article edits" that might be expected from a probationary user and try it for a month. Delicious carbuncle (talk) 14:16, 9 June 2008 (UTC)

I already do that. If you would stop making fun of my ideas you would see that most of my editing is to law articles. JeanLatore (talk) 18:09, 9 June 2008 (UTC)

I have to strongly object to the statement "The tenets of the projects are openness and that anyone can be redeemed." Redemption is not our business. It's irrelevant to what we do here. We don't try to make editors who want to contribute usefully; we merely welcome those who already meet that basic requirement. Wikipedia is not therapy. Friday (talk) 14:24, 9 June 2008 (UTC)

I agree completely with Friday's comments, so consider my first thought to be a 'me-too'. Wikipedia isn't therapy, and it's not worth our while to coddle editors who can only be made to contribute constructively while they are held cornered at gunpoint.

Beyond that, I am concerned that probation of this type would (further) entrench the mistaken notion that the most valuable – or only valuable – edits to Wikipedia are always those that add material. It just ain't so. Wikipedia is stuffed full of tremendous amounts of information. We've got raw data just coming out of our ears. What many of our articles need most desperately is not the addition of more information (however well-referenced) but rather the judicious use of red pencil. We have fertile soil and the healthy plants; now we need to mow the lawn and pull the weeds. We're building a botanical garden, not a jungle. Imposing some semblance of order – within and across articles – is a valuable service to our readers. I'm tired of seeing editors who actually edit being treated as second-class contributors. TenOfAllTrades(talk) 16:14, 9 June 2008 (UTC)

Question about WP:COI and what it means to "exercise great caution"

Since the end of April, I've used this account to make suggestions on talk pages of articles within the scope of WP:FILM. I have limited my participation on these articles about upcoming Disney releases because the studio is a client of my employer. To be doubly sure I did not find myself on the wrong side of WP:COI, I started using this account only after a helpful discussion on this page.

Now, another question: Oftentimes I've found that my suggestions are not picked up after a few days of waiting. In these cases I've tried to locate editors who had already contributed to the article, or failing that, posted a comment on the WikiProject discussion page. This works, albeit quite slowly. After doing this for a couple weeks, I found a comment from the lead coordinator of WP:FILM following me on the discussion page of one such film:

There's absolutely nothing in COI that prevents you from editing the article, so long as you are performing neutral, uncontroversial edits. I appreciate your candor in disclosing possible bias, but if your edits involve facts which are unlikely to be contested and are reliably sourced, then - IMHO - by all means go for it.

I'm curious to know if other editors and administrators here agree with this suggestion? I don't know what WP:COI means precisely by "exercise great caution" but this strikes me as a reasonable interpretation.

My requests to date have been entirely factual in nature -- this film is rated PG-13, here is the official website, that producer's name is wrong, and so forth. (Click here to see my contributions.) And I have always provided reliable sources -- no IMDb, for example. If at some point one of my contributions was disputed, or I wished to join a pre-existing debate, then I think it would be prudent to cease direct edits and involve myself only with discussion pages.

But I'd like to hear from the community first. It would no doubt make my life easier, the movie pages more complete, and it would free up time for other editors as well. But I'm unsure what WP:COI allows exactly, so I'd love to get a second (and third and fourth...) opinion on the matter. Thanks. NMS Bill (talk) 16:42, 9 June 2008 (UTC)

My view is that for the sort of changes that you describe, ie. simple facts with no interpretation provided, then you should go ahead with the changes. As long as you are open about the possibility that a coi exists. For changes that could be controversial, or if you are reverted, it's better to use the procedure you describe and try to get an editor without a coi to make the changes. And even in these cases, if no one responds on the talk page within a couple of days you should feel free to make the changes yourself. Taemyr (talk) 17:46, 9 June 2008 (UTC)

In the Starwood Arbitration which was on the issue of COI of an editor (he was editing many, many article on the subject of which he had a financial interest in and entering his company name and link), the finding of ArbcomWikipedia:Requests for arbitration/Starwood/Proposed decision was the following:

Wikipedia:Conflict of interest, a guideline, discourages editing of articles concerning matters you have a substantial personal interest in, such as articles about an organization you are deeply involved with. However, such editing is not prohibited, if editing is responsible. –Mattisse (Talk) 18:01, 9 June 2008 (UTC)

I was not familiar with that ArbCom ruling, but I think that addresses my situation. I have no interest in spamming up Wikipedia, I just want to make sure that these articles are brought up to Wikipedia standards. And Taemyr's points about a waiting period for more controversial edits and resorting to discussion if reverted are well-taken also. NMS Bill (talk) 18:22, 9 June 2008 (UTC)

use of youtube

I was told that use of youtube videos was discouraged on Wikipedia because of copyright problems etc. Today someone added a youtube clip to Gideon v. Wainwright under External links. My edit removing it was reverted with the comment that the youtube clip was the work of the editor introducing it into the article and that was sufficient for copyright and GNU issues. Is it correct that youtube clips can be added on the say-so of the editor, without a more formal release process? Thanks, –Mattisse (Talk) 17:44, 9 June 2008 (UTC)

Technical

GREAT REQUEST

I am welcoming everyone warmly very much! I am a Polish Wikipedian. I would like to ask you for help very much in convincing my countrymen from Polish wikipedia so that they send the correct official name of the state of Nepal, following the example of you. Repeatedly I tried to implement updates, but they all the time for her aren't accepting. They are undermining the credibility of your information. Please compare both versions and pay attention to the official onomastics of the country: english version, polish version. Could you help it?

If grammatical mistakes are appearing in the text please to forgive me, because I am not knowing the English well. ; -)

83.31.142.53 (talk) 15:25, 4 June 2008 (UTC)

I'm afraid that editors of the english wikipedia have absolutely no influence over foreign-lanaguage wikipedias. You will have to discuss this issue with other editors of the polish wikipedia. Happy‑melon 15:51, 4 June 2008 (UTC)

m:WikiMiniAtlas disabled?

Resolved.

It looks like the m:WikiMiniAtlas has been disabled or is otherwise broken in the English Wikipedia. It no longer appears on any coordinate pages at all. There's no mention of its removal on the {{coord}} template talk page, the m:WikiMiniAtlas page, or the wiki project. Anyone know what's up? There's also a discussion on this at the help desk -- ShinmaWa^(talk) 22:20, 30 May 2008 (UTC)

Perhaps this change to MediaWiki:Common.js [3]. --—— Gadget850 (Ed) ^talk - 22:33, 30 May 2008 (UTC)

Good catch! I didn't even think to look there! After looking at the talk page, it might well have this this change -- ShinmaWa^(talk) 22:46, 30 May 2008 (UTC)

It is the same change— we are just looking at it differently. --—— Gadget850 (Ed) ^talk - 22:53, 30 May 2008 (UTC)

No, they are different diffs, but I'll move it off of the secure server. -- ShinmaWa^(talk) 22:59, 30 May 2008 (UTC)

I really don't think either of those changes should be causing the problem: mine is to a completely unrelated part of the code, while Brion's shouldn't have any effect unless you're using the secure server. (And no, the globe icon doesn't appear on the secure server, either.) Besides, I think we can usually assume Brion knows what he's doing. :-) The problem might be in m:MediaWiki:Wikiminiatlas.js too, although that page doesn't seem to have changed since April. —Ilmari Karonen (talk) 23:31, 30 May 2008 (UTC)

I would guess that it may be related to the domain change of the toolserver, but I really have no idea. --- RockMFR 00:17, 31 May 2008 (UTC)

Fixed it at least for the URL form I see at San Francisco. There might be others. --brion (talk) 00:28, 31 May 2008 (UTC)

Gee, one week of vacation and suddenly something exciting is happening. Thanks for adding the new toolserver.org URL. That should be it. --Dschwen 16:46, 2 June 2008 (UTC)

Is this related to the fact that suddenly all coordinate URL's are now rendering as gibberish in my browser (Firefox)? Nibios (talk) 15:13, 6 June 2008 (UTC)

Same thing on another machine using IE 7. Nibios (talk) 15:19, 6 June 2008 (UTC)

Subpage moves

Resolved.

According to the latest Signpost technology report, subpages can now be moved during a page move. I have been testing this: when you do a move, you not get a checkbox for " Move all subpages, if applicable". When I try this with a user subpage with a subpage, I get:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

    (SQL query hidden)

from within function "Article::insertOn". MySQL returned error "1062: Duplicate entry '2-Gadget850/movetest1' for key 2 (10.0.0.235)".

The main page gets moved, but not the subpage. Any thoughts? --—— Gadget850 (Ed) ^talk - 15:03, 31 May 2008 (UTC)

See bug 14258. MER-C 03:41, 1 June 2008 (UTC)

This worked for me on my test wiki. I don't know why that error would occur. A shell user needs to look into why it's failing on Wikimedia projects. —Simetrical (talk • contribs) 16:35, 1 June 2008 (UTC)

Seems to be fixed now. --—— Gadget850 (Ed) ^talk - 19:21, 4 June 2008 (UTC)

ChipIn for Wikiprojects

I like the Wikipedia:Bounty board, but I see WikiProjects as not having the same support it affords to articles. If, for example, someone wanted to set http://www.chipin.com/ on a Wikiproject, there would be no way to mark that up. Does the Foundation have the technical capability to fund WikiProjects as well as particular tasks? 76.240.230.195 (talk) 17:07, 1 June 2008 (UTC)

In case that was not clear, such money would be apportioned into bounties, for example. 76.240.230.195 (talk) 17:18, 1 June 2008 (UTC)

The Foundation isn't funding particular tasks; individual editors are. And it's not unheard of for several editors to jointly fund a particular bounty. It isn't clear what the question here is - if it's whether the software can or will be modified to allow a chip-in widget to be embedded on a Wikipedia page, the answer is no - Wikipedia isn't Facebook. -- John Broughton (♫♫) 20:05, 5 June 2008 (UTC)

What happened to the fraction "buttons"?

What happened to the fraction "buttons" (1/2, 1/3, 2/3, etc.) below the article text edit window? They were very handy to insert the symbols into an article. Should I take their removal as a Wikipedia WP:MOS "rule" they should not be used in articles? — X96lee15 (talk) 16:58, 2 June 2008 (UTC)

Looking at the history for MediaWiki:Edittools, "Please don't use Unicode superscripts, subscripts, and fractions in article text - it creates accessibility problems. Use the <sup> and <sub> tags instead, or TeX for formulas." I don't see anything in Wikipedia:Accessibility on this, so I'm not sure what the problem is. --—— Gadget850 (Ed) ^talk - 17:12, 2 June 2008 (UTC)

And by doing this the editor has made it impossible to enter for example fractions of an inch, and suggests installing software (i.e. :LaTeX) to allow you to continue to edit. So much for the "Encylopedia Anybody Can Edit" - well anybody if they are willing and able to install software items on their computer and edit off line. The arrogance of some users is amazing.Nigel Ish (talk) 17:43, 2 June 2008 (UTC)

With superscript and subscript one can type 1¹/₂" and get 1¹/₂", but it is far from ideal - too many clicks. DuncanHill (talk) 17:54, 2 June 2008 (UTC)

No... LaTeX is software installed here, on Wikipedia. You can use it to insert formula using the <math> tags. See WP:MATH. — Edokter • Talk • 17:59, 2 June 2008 (UTC)

So typing 1<math>\frac{1}{2}</math>" gives 1", which looks crap. DuncanHill (talk) 18:02, 2 June 2008 (UTC)

Or try this 1<math>\tfrac{1}{2}</math> which gives 1", which also looks crap. DuncanHill (talk) 18:04, 2 June 2008 (UTC)

I strongly agree. Pages like 1959 Ryder Cup would look terrible without the ½ character. — Andrwsc (talk · contribs) 18:20, 2 June 2008 (UTC)

They have been restored - ½⅓⅔¼¾⅛⅜⅝⅞woohoo! Thank you. DuncanHill (talk) 18:33, 2 June 2008 (UTC)

That was me, because there is clearly no consensus for their removal. This needs more discussion at WT:MOS or somewhere. Happy‑melon 18:35, 2 June 2008 (UTC)

Ah yes, thank you very much!!! — X96lee15 (talk) 19:00, 2 June 2008 (UTC)

What's wrong with 1+¹⁄₂″ ? --Random832 (contribs) 20:15, 2 June 2008 (UTC)

Looks ugly (the 2 goes below the line), and where did you find out how to type it? DuncanHill (talk) 20:19, 2 June 2008 (UTC)

{{frac}}. —Ilmari Karonen (talk) 20:30, 2 June 2008 (UTC)

Thanks, but how did you find it? DuncanHill (talk) 20:33, 2 June 2008 (UTC)

That is a very good question. We have a lot of good templates, but the organization stinks. If I have a job that needs a template I've never used before, I use Special:PrefixIndex and look in template space for a logical name— this really works a lot of times. Other times, I use a template because I saw it used somewhere else. --—— Gadget850 (Ed) ^talk - 20:44, 2 June 2008 (UTC)

Also, the template documentation page itself for {{frac}} shows problems in my brower (IE7), with truncated text. I stopped using frac for simple fractions (like ½) long ago for this reason. — Andrwsc (talk · contribs) 20:41, 2 June 2008 (UTC)

Random832 asks, "What's wrong with 1+¹⁄₂?″ The apparent grounds for rremoving the fraction "buttons" is "Please don't use Unicode superscripts, subscripts, and fractions in article text - it creates accessibility problems". 1½ (Unicode) is a lot more accessible than 1+¹⁄₂ (using the frac template) because:

• Decent screen reader programs can handle Unicode, which has been the dominant character encoding since about a year after the launch of Windows XP.
• +¹⁄₂ (using the frac template) generates the following HTML (which I got by using my browser's "View source" facility on this page):

<span style="white-space:nowrap"><s style="display:none">+</s><span class="template-frac">¹<big>⁄</big>₂</span></span>

which produces an adequate visual representation of the fraction ½ but which no screen reader software is ever likely to interpret as a fraction. Philcha (talk) 21:17, 2 June 2008 (UTC)

I wouldn't be so sure about that, though of course real evidence can only be obtained by testing various screen readers, which I haven't done. Still, stripping away the HTML markup, that boils down to "+1⁄2", where the "⁄" is a Unicode fraction slash. I seems at least reasonable that a screen reader should read that as "one half", or at least "one slash two". Certainly it's less ambiguous that just plain "1/2" using an ordinary slash. (Oh, and on the other hand, "¼", "½" and "¾" are long-established ISO Latin 1 characters, so it seems at least misleading, even if technically correct, to label them "Unicode fractions".) —Ilmari Karonen (talk) 23:39, 2 June 2008 (UTC)

The only screen reader I am slightly familiar with is JAWS, and it seems quite popular. Checking their support page,[4] it supports all of the Unicode characters, including fractions. Not an exhaustive study. --—— Gadget850 (Ed) ^talk - 23:55, 2 June 2008 (UTC)

&frac12;, &frac14;, and &frac34; work if you don't want to scroll down for those three. --NE2 00:08, 3 June 2008 (UTC) (Ampersands escaped to allow the entities to display as intended. —Ilmari Karonen (talk) 01:44, 3 June 2008 (UTC))

Sorry to be the cause of so much trouble...the fractions are fine really, and I shouldn't have removed them. My problem is with the Unicode superscript characters.

HTML superscript: E=mc²

Unicode superscript: E=mc²

As you can see the HTML superscript is much easier to read. Also, if you're trying to search for a number in a superscript, you can't if the Unicode superscript character was used unless you copy-and-paste it into the search box. Searching is easier if the <sup> tag is used instead because you can search for "2" instead of "²". —Remember the dot ^(talk) 00:51, 3 June 2008 (UTC)

Yes it's true that JAWS, the screen reader I use, supports Unicode characters, and has done so for a while now. The problem is that the pronunciation for almost all unicode characters outside Latin 1 and the users Windows code page is undefined because of memory limitations. The only Unicode characters that have defined pronunciations by default are some letters of the Arabic alphabet and arrow symbols. I use the default settings and only ½, ¼, and ¾ speak properly for me with JAWS 8 - not the most recent version but IMO a representative sample. Graham87 09:52, 3 June 2008 (UTC)

Superscript 1, 2, and 3 are in ISO Latin-1 (8859-1) and available as &sup1; &sup2; &sup3;. In Firefox I find expressions like E=mc² or "g = 9.8 m/s²" more legible when they are used; HTML superscripts come out too large and cause the line spacing to be irregular. And all the more so when I use lynx, which I sometimes do. --207.176.159.90 (talk) 22:26, 6 June 2008 (UTC)

Is it possible for an expression to return a user's last edit date & time ?

User:SoxBot V was indefinitely blocked today, sending us back to the dark ages as far as status updates go. Is there any expression that will return the date and time of a users last edit? Could this possibly be implemented? (Having this would allow a workaround for status indication that did not require a bot). xenocidic ( talk ¿ listen ) 23:21, 2 June 2008 (UTC)

Since this is a WP:PERF issue, any ideas that come up really should be run by a dev before someone implements it. MBisanz ^talk 23:34, 2 June 2008 (UTC)

• The status bots were helpful, and since they have been shutdown by the dev's having another method to query this information would be helpful, but seems to beg for the perennially denied request for user variables... — xaosflux ^Talk 23:53, 2 June 2008 (UTC)

Writing a simple MediaWiki extension to provide this information via parser functions shouldn't be too difficult. Making it update reliably without totally ruining page caching is a little bit trickier, but not much. —Ilmari Karonen (talk) 03:08, 3 June 2008 (UTC)

My Qui friends/status system is able to tell you when a user last edited (does API queries). --TheDJ (talk • contribs) 08:51, 3 June 2008 (UTC)

Cobi has worked on a mediawiki extension : [5] (bugzilla:14384). Thanks for the input all. xenocidic ( talk ¿ listen ) 12:55, 3 June 2008 (UTC)

Thank you DJ, I will use this in the interim/if the bugzilla doesn't get accepted. Good work. xenocidic ( talk ¿ listen ) 13:02, 3 June 2008 (UTC)

The bugzilla request was closed as WONTFIX, however there is an extension that sort of does the status thing --Chris 10:06, 4 June 2008 (UTC)

New Extension

With the fate of User:SoxBot V, I have been constantly looking for an alternative. After looking at mediawiki.org, I found an extenstion that automatically does it: mw:Extension:OnlineStatus. While some users may not like it, i believe it could be a benefit to Wikipedia, especially at WP:HAU. Before filling out a bugzilla request though, I would like community consensus. What do people think of this extension? Soxred 93 22:33, 3 June 2008 (UTC)

Just did a quick read, but it looks like you have to manually turn this on and off? — xaosflux ^Talk 03:21, 4 June 2008 (UTC)

I'd personally first like to know what the developers think of that extension. --TheDJ (talk • contribs) 08:38, 4 June 2008 (UTC)

One would set their Online/Offline toggle in their preferences, so one could log on, set this to online, getting ready to log out, set this to offline. There might be some code to add to a monobook file to do this automatically. 209.244.31.53 (talk) 18:54, 4 June 2008 (UTC)

ID duplication

This is a problem I've run into before: pages with more than one stub marker or navbox (read: not one of each, at least two of either) generate XHTML errors because IDs cannot be called multiple times. The fix is to change the "id=" statement to "class=", which is simple enough, however Wikipedia has countless templates. Is there a solution to this other than trudging through the templates and changing everything manually?·· TVO_talk 05:08, 4 June 2008 (UTC)

This should not happen. Do you have some articles that have this problem ? The fix is not to change id= to class= btw. That is a bad way to solve this problem. --TheDJ (talk • contribs) 08:27, 4 June 2008 (UTC)

Ouch, actually this does happen exactly like he said, because all stub templates (conforming to current standards) will contain a table wrapped inside a <div class="boilerplate metadata" id="stub">. The other two options would be

• Run a bot to change all stub templates to use id="{{subst:PAGENAME}}" i.e. the name of the template e.g. id="Latvia-bio-stub" or whatever.
• Change the software to prevent duplicate id attributes by numbering them sequentially after the first. Note that this is already done for section headings with duplicate names to keep the TOC working properly:

If you have these the same page	You get something like:
== Foo == == Foo ==	<p><a name="Foo" id="Foo"></a></p> <h2><span class="mw-headline">Foo</span></h2> <p><a name="Foo_2" id="Foo_2"></a></p> <h2><span class="mw-headline">Foo</span></h2>

Latter option is probably better as it will fix more scenarios than have been identified, and it won't make the job queue go over 9,000. — CharlotteWebb 16:00, 4 June 2008 (UTC)

Probably closer to a million actually - we have 850,000 stubs assessed through WP:1.0 quite apart from those that haven't been bannered. So the second option is considerably more elegant than the first and, as you say Charlotte, this problem occurs with more than just the stub templates. Happy‑melon 20:14, 4 June 2008 (UTC)

Agreed, this is bad. Suggest a bot fixes it all. Having duplicate ids is not something that mediawiki should handle in my opinion. --TheDJ (talk • contribs) 22:12, 4 June 2008 (UTC)

See bug 4515http://bugzilla.wikimedia.org/show_bug.cgi?id=4515. One problem (which is why Tidy doesn't fix this automatically) is that renumbering id's will basically break them: any styles or links to that ID will just break. People will have to stop abusing id's for things like stub templates in any case. —Simetrical (talk • contribs) 00:00, 5 June 2008 (UTC)

Simetrical, I only suggested renumbering id's after the first... wouldn't any link intended to point to them would already be broken? — CharlotteWebb 20:29, 5 June 2008 (UTC)

Yeah, you're right, it causes no problems with links (which probably go to the first anyway). It breaks styles, however (#stub may be styled), and possibly some JS. —Simetrical (talk • contribs) 20:32, 5 June 2008 (UTC)

Software tor handling

Just a quick note to let everybody know that the TorBlock extension has now been enabled on Wikimedia sites. All Tor blocks are now overridden by a Wikimedia-wide system. It will forbid unregistered users from editing through Tor. I realise that a lot of problems are caused by pagemove vandals using sockpuppets through tor, and this is why, in the extension, I have subjected all tor users to much stricter autoconfirmed requirements. Users editing through tor will now require 100 edits and a 90 days to become autoconfirmed. I hope that this addresses the objections to my extension (I've spoken to a few checkusers, stewards, and other developers, and they seemed to think this was a reasonable compromise). If not, you know where to find me. — Werdna talk 08:01, 4 June 2008 (UTC)

Sounds like fun! Any chance of you putting a few lines at mw:Extension:TorBlock so we have more of an idea how this extension actually works? Happy‑melon 09:02, 4 June 2008 (UTC)

I like the idea, I wish it would hardblock the tor nodes, but I know some places like Chinese Wiki wouldnt work if that was done WMF-wide. MBisanz ^talk 09:10, 4 June 2008 (UTC)

I haven't actually looked at the extension, but it might be possible to have a hardblock configuration variable. Mr.Z-man 23:22, 4 June 2008 (UTC)

Problem maximising Wikipedia images in IE7

Resolved.

Hello, recently I've been unable to maximise about 75% of Wikipedia images. I get the error message

"Internet Explorer cannot open the Internet site http://en.wikipedia.org/wiki/Image:Abd_el-Krim.jpg

Operation aborted"

After doing a bit of searching around, I came across these two links that show the same problem but don't help solve it: http://forums.techguy.org/windows-vista/718305-cannot-maximize-wikipedia-images.html and http://www.dslreports.com/forum/r20587288-IE-Error-Message-While-Browsing-Wikipedia

Most of the answers that I've found mention something about fiddling with Java code, something I don't have any knowledge of. I've tried running IE with no add-ons and the problem still persists. This isn't happening on any other website, and I'm not sure why it's just started up today!

I'm using IE7.0.5730.13 on XP Pro SP2. Thanks for any help! 78.143.205.7 (talk) 11:45, 4 June 2008 (UTC)

There are bugs in Internet Explorer which trigger this behavior sometimes, when some (but not all) JavaScript operations are performed in a certain order when there's some bad HTML code (or sometimes maybe for no particular reason). Some recent changes to English Wikipedia-specific custom JavaScript which fix a separate bug can sometimes trigger this one, but that is fixed by a slight change to the HTML layout.

So, it's possible for the moment to encounter the second error with the new JavaScript and the old cached HTML:

• If you use any browser but Internet Explorer, you won't encounter the bug.
• If you visit pages updated since yesterday, you won't encounter the bug.
• If you log in, you'll get all newly rendered pages and won't encounter the bug.
• If you wait for up to 30 days, all the old cached HTML will fall out of the system and you won't encounter the bug.

We might poke a bit to see if we can tweak the JavaScript in a way that doesn't trigger either bug, but no guarantees. --brion (talk) 16:22, 4 June 2008 (UTC)

Thanks for the advice. I just installed Opera anyway, which seems a lot better so far. No bugs or crashes as of yet! Cheers 78.143.205.7 (talk) 17:51, 4 June 2008 (UTC)

The trigger here was an improperly-closed <span/> in MediaWiki:Shareduploadwiki-desc. While technically that's valid XHTML, Internet Explorer gets confused by it, and its HTML parser freaks out when the JavaScript gets run. It's now fixed, but isn't a problem with the moved JS trigger anyway. Old cached pages with the bugs will still apply unless we can find a workaround at the JS. --brion (talk) 19:37, 4 June 2008 (UTC)

Ok, I found a tweak to the JavaScript code which doesn't trigger the "operation aborted" error even when the bad HTML is present. You _might_ have to clear your local cache if you've already got the previous version, but new visits shouldn't have any problems. --brion (talk) 20:22, 4 June 2008 (UTC)

Watchlist troubles

Has anyone else been having problems with their watchlist in the last day or two? Recently, sometimes when I've refreshed my watchlist, my browser locks up completely and crashes: this happened to me several times yesterday, and just once now. Is this a problem with me, or are other people having this? It only seems to be locking up when refreshing my watchlist. Thanks. Acalamari 16:24, 4 June 2008 (UTC)

What browser/operating system are you using? Algebraist 17:06, 4 June 2008 (UTC)

Internet Explorer 7. Acalamari 17:10, 4 June 2008 (UTC)

You might check out the FAQ section at http://www.ie7.com . — CharlotteWebb 17:21, 4 June 2008 (UTC)

Heh, well, I already do have Firefox, but it simply looks terrible on my monitor, and therefore, I don't use it. I'm actually confused by the watchlist crashing, as it's never happened before until yesterday: I'm trying to work out what's going on. Acalamari 17:27, 4 June 2008 (UTC)

More importantly, how many pages do you have watch-listed, and what settings to you have in the "Watchlist" section of Special:Preferences. — CharlotteWebb 17:37, 4 June 2008 (UTC)

151 pages, and none of the settings in preferences have been ticked. Acalamari 17:47, 4 June 2008 (UTC)

My suggestion: use Firefox, then pick a theme that looks better on your monitor. MyFireFox looks virtually identical to IE7, so it'll look the same but resolve the crashing issues. Pyrospirit (talk · contribs) 17:54, 4 June 2008 (UTC)

No thanks: I'd rather find out what the problem is rather than just change browsers. After all, the problem may not be limited to me, and it's better to find out what's wrong. Acalamari 18:05, 4 June 2008 (UTC)

I was referring more to the numbers for maximum days and edits. My watchlist is over 9,000 but I have it set to only go back one day, by default, so it never crashes. Also I don't use IE. How much does it load before crashing, or can you tell? Also if you have any kind of javascripts or "gadgets" that affect the appearance of the watchlist (the "(unwatch)" button comes to mind) IE's ability to handle them might be suspect. — CharlotteWebb 17:59, 4 June 2008 (UTC)

It doesn't load anything: the entire screen just goes white, and I'm told that it's "not responding". In addition, I don't use any gadgets that affect editing or the watchlist, so they're not the problem either. Acalamari 18:05, 4 June 2008 (UTC)

• I should note, however, that it doesn't crash every time I refresh my watchlist: only occasionally, but frequently enough that it's extremely annoying getting logged out and having to log back in again. Acalamari 18:09, 4 June 2008 (UTC)

Do you see an error message that looks like this or something else? If something else, what exactly does it say? --brion (talk) 18:13, 4 June 2008 (UTC)

No, I can log in perfectly. It's just that, when updating the watchlist sometimes, it doesn't open anything: the browser locks up, and most of the screen goes white, and the bar at the top of the screen says that it's "not responding". After that, I have to use "control, alt, delete" to exit the browser. Acalamari 18:19, 4 June 2008 (UTC)

I've actually had this happen in IE when attempting to refresh WP:AN or WP:ANI. My solution was to simply click on "Project page" at the top of the page, next to "discussion". In essence, it's what you'd click to get from the talk page to the project page; the fact that you're already at the project page is immaterial, as the browser treats it as a new request and a new page. This works for the watchlist as well, except that you click "special page" to reload. UltraExactZZ ^Claims ~ Evidence 17:20, 9 June 2008 (UTC)

Page move bug

Screenshot of move confirmation page

While moving Talk:University of Missouri–Columbia to Talk:University of Missouri for a requested move, I checked the button to automatically move subpages. The subpages were moved to the User: namespace instead of the Talk: namespace. Please see the above screenshot. --B (talk) 18:23, 4 June 2008 (UTC)

Fixed about half an hour ago. rev:35870. Mr.Z-man 18:30, 4 June 2008 (UTC)

Well, it was a maximum of 25 minutes ago ... it happened at 14:05 eastern / 18:05 GMT. --B (talk) 18:32, 4 June 2008 (UTC)

I installed the fix at 11:05 Pacific time, you got in just under the wire. :) --brion (talk) 19:14, 4 June 2008 (UTC)

The issue I discussed at #Subpage moves appears to be resolved as well. --—— Gadget850 (Ed) ^talk - 19:22, 4 June 2008 (UTC)

Anyone know if this bug is still outstanding? Should someone knock at bugzilla? Happy‑melon 21:07, 4 June 2008 (UTC)

bug 14356http://bugzilla.wikimedia.org/show_bug.cgi?id=14356, WONTFIX. It's not a bug, it's completely intended. The feature would be nonfunctional if the throttle applied per page rather than per action. Restricting the action to sysop only would be the appropriate thing to do here if it's a problem. —Simetrical (talk • contribs) 00:10, 5 June 2008 (UTC)

Er, did anyone think about writing it such that the throttle is updated after the page moves are done? My thoughts were that if you've got at least one pagemove left in your allowance you're allowed to move the page, but then it adds however many pages to your count so the next time you try and move something it finds you're way over. Basically, you'll always be allowed to move all the subpages, but in many cases that will put you over the throttle limit so you can't move anything else. Is there a reason that wasnt' considered in the bug thread? Happy‑melon 10:17, 5 June 2008 (UTC)

Why should that be treated differently, though? I explained my thoughts on the purpose of throttles in the commit message for r35897: "Rate limits should be applied per user action, not based on how large the effect of each action is. Note that moving a page with its talk page only counts as one move for rate limits; this is the same principle. The only point of rate limits (as far as I can think of) is to prevent unauthorized automated scripts from creating a mess in 30 seconds that it will take 10 hours to clean up by hand. Since a move with subpages is no harder to clean up (i.e., revert) than a move without subpages, they should count the same for rate limits." —Simetrical (talk • contribs) 20:35, 5 June 2008 (UTC)

Well, is there a button to delete the hundreds of redirects left behind by page-move vandalism in a single click, too? —Cryptic 21:31, 5 June 2008 (UTC)

Admittedly, no, not yet, as I mentioned in that revision comment. It might be a good idea to add an additional permission for this, and restrict it to only sysops on enwiki for the time being. —Simetrical (talk • contribs) 13:41, 6 June 2008 (UTC)

underground nuclear explosions

In an attempt to convert from amateur to professional writer, I am in need of an important answer. A hypothetical cache of nuclear weapons, set off simultaneously a mile or so underground, what would the effects be? Massive earthquakes? Eruptions? Nuclear fallout of any kind? Keeping in mind the necessary pipelines, elevator shafts, and all the whatnot... would the surface get much of anything? Thanks in advance. —Preceding unsigned comment added by 12.201.115.120 (talk) 21:42, 4 June 2008 (UTC)

This is not a Wikipedia technical question. You want Wikipedia:Reference desk/Science. Algebraist 21:44, 4 June 2008 (UTC)

Ah, but it could be. What if the underground nuclear bomb is set off one mile away from the location of the WikiMedia servers? How much would the normal operation of Wikipedia be affected? ;-) Waltham, The Duke of 01:38, 6 June 2008 (UTC)

Tool for finding diffs

Are there any tools for finding the diff URL for a certain piece of text? It's really a lot of work to search through the history manually if there are many edits.

(And on a tangent, I wish we could just overhaul the entire talk page system into something more like a web forum - with full wikisyntax and communal-editable spaces in each thread, of course - but with thread formatting, usernames, timestamps, meta-links, archiving, and so on taken care of automatically.) — Omegatron (talk) 02:54, 5 June 2008 (UTC)

Are you looking for WikiBlame?-gadfium 06:27, 5 June 2008 (UTC)

That looks like a really cool tool. Bookmarked! Regarding improvements to the talk page, it will most likely not happen because the whole point of a wiki is to be as flexible as possible, so it's how it is right now. Gary King (talk) 07:07, 5 June 2008 (UTC)

Actually, improvements to the talk page interface are in the works - see mw:Extension:LiquidThreads. Graham87 09:06, 5 June 2008 (UTC)

In the works does not guarantee implementation, however. It hasn't been touched for four months. Also, I'm sure there will be some disagreements over whether it should be implemented or not. Gary King (talk) 17:09, 5 June 2008 (UTC)

Yeah, I've used WikiBlame. It's not that useful for this kind of thing. The user has made more than 1000 edits to the talk page, and it's about 10x as much work to find each individual diff and copy and paste it. I have the username and timestamp, but not the URL. — Omegatron (talk) 00:50, 6 June 2008 (UTC)

Can the URL be generated directly from the timestamp of the comment? — Omegatron (talk) 00:51, 6 June 2008 (UTC)

Yes! There is a tool, different from Wikiblame called wpW5. User:Franamax developed it. Look on his userpage, and ask him and he'll email you a copy. -- penubag  (talk) 01:06, 6 June 2008 (UTC)

This is an external software tool? For what operating system? — Omegatron (talk) 01:27, 6 June 2008 (UTC)

Yes, it's an external tool exclusively for Windows, unless you know of another operating system that can read .exe's. It is really useful and I recommend it. -- penubag  (talk) 01:45, 6 June 2008 (UTC)

I'm in Linux, though I might be able to run it with WINE. Is it kind of the same functionality as WikiBlame, though? — Omegatron (talk) 01:48, 6 June 2008 (UTC)

I haven't used wikiblame yet but what wpW5 does is searche for when a diff was first inputed and tells you who and when it happened. For example, I tell the tool to look on the article, Dog and then I input a sting of text from the article (or was) that I want the tool to find when it first appeared. It then tells me User:Example wrote that sentence on this date. -- penubag  (talk) 01:54, 6 June 2008 (UTC)

Yeah, that's what WikiBlame does, though the interface is kind of confusing. This tool goes through the edit history diff by diff to find it?

Does anyone know if there's a way to generate diffs directly from datestamps? It seems the diff URL is just a sequential number for every single edit on any page. — Omegatron (talk) 01:57, 6 June 2008 (UTC)

You can go to the action=history of the page and use the &offset parameter (which takes a timestamp of the format &offset=yyyymmddhhmmss) ... for example, if you know the timestamp of an edit made to the Main Page was "15:34, 20 March 2008" you could find the diff thusly: title=Main_Page&action=history&dir=prev&limit=1&offset=20080320153400. --Splarka (rant) 07:16, 6 June 2008 (UTC)

Ah, that's helpful. Could probably write a javascript for that.

I was originally digging through the talk page's history, but discovered that it was easier to go to the user's contributions, list 500, and then Ctrl-F search for the time of the edit in question. — Omegatron (talk) 17:16, 7 June 2008 (UTC)

Delete confirmation

This one might only be understood by admins who delete pages or those more familiar with MediaWiki than I am =D. When I delete a page, there's a page for confirmation in which I select the reason (A7, G4, G8 or whatever). Until about two weeks ago the delete reason was fed automatically from the CSD template. The content also didn't show up in the "other reason" box, which it now does. I don't know if this was changed by consensus, but is there a script or something that will stop it doing that? It makes CSD (currently with a +100 backlog) patrol more tedious because I have to delete the content first. Thanks, PeterSymonds (talk) 15:00, 5 June 2008 (UTC)

Might be best to bring this to WP:AN, just to get their attention. If you got cookie problems, though, then this is the right place! :p Gary King (talk) 19:52, 5 June 2008 (UTC)

Heh, embarrassed now.:) Thanks, over to AN I go...Thanks Gary! PeterSymonds (talk) 19:57, 5 June 2008 (UTC)

Nie tłomačtie metek dla kratek do vypełniania na ięzyk narodovy

Problem description

Preferring a language different from English causes the labels of text input controls to be translated, which in turn causes the user thus solicited to fill the fields in the preferred language. As a result, the information entered there is unavailable to users whose preferred language is different, which disrupts the collaborative character of Wikipedia.

Recommendation

Please make these labels an exemption from localisation. See my talk page for an extensive discussion of the subject.

--Yecril (talk) 16:17, 5 June 2008 (UTC)

Discussion

That would make it very difficult to log in and work with a site whose primary language is not one you speak, so that's not a good idea. --brion (talk) 00:10, 6 June 2008 (UTC)

Yecril's position is that, because the input fields for edit comments and section headers (see above) is in the user's localized language, he is obligated to enter that information in his language. Hence, he has insisted on going around making edits with comments in Polish, and adding Talk sections (like this) with headers in Polish, despite the fact that he is obviously capable of writing in English.

To me, this obstinate behavior defies common sense (and common courtesy) on an English-language wiki.

However, as far as the UI is concerned, it does seem like a reasonable (if minor) improvement to label input fields with the site's language if a response in the site's language is expected—if the user knows enough English to enter an English edit comment, they should know enough English to understand "Edit summary". (How is the user supposed to "work" on the site otherwise?) Other UI elements that are read-only should of course be localized.

—Steven G. Johnson (talk) 01:44, 6 June 2008 (UTC)

All in all, does this request apply to Wikipedia or to Wikimedia or to MediaWiki? I am not good at discerning the layers involved. I would like to file a feature request and I am not sure where to do it. --Yecril (talk) 11:19, 6 June 2008 (UTC)

MediaWiki. The proper place to request the change is Bugzilla. —Simetrical (talk • contribs) 13:44, 6 June 2008 (UTC)

Interwiki link, vandalism cleanup, style & layout comments and questions, etc etc. --brion (talk) 16:28, 6 June 2008 (UTC)

Orsilochus ordered incorrectly in category

Can anyone figure out why Orsilochus shows up incorrectly in Category:Characters in the Odyssey? It appears first on the category page, as if it was defaultsorted as an asterisk, even though it's not, and I can't figure out why, and it's driving me absolutely nuts. The article appears sorted correctly in all other categories. Ford MF (talk) 22:39, 5 June 2008 (UTC)

It is because {{Characters in the Odyssey}} has the * sort key in it. I just manually added that category to the page, so know it sorts like the rest. I am guessing the sort key should be removed from the template though. - AWeenieMan (talk) 22:46, 5 June 2008 (UTC)

Ahh. Now I see what was going on. Someone wanted the template to be in the category at the top, but their way of doing it added a sort key to all the articles. Anyhow, I fixed the template, so going forward there shouldn't be problems. - AWeenieMan (talk) 22:50, 5 June 2008 (UTC)

Terrific, thanks. Ford MF (talk) 22:56, 5 June 2008 (UTC)

Looking for more input on user script suggestion

I recently suggested a method for avoiding script incompatibility at wt:WikiProject User scripts. Since that page isn't especially active, I'd like to bring it to interested editors' attention and hopefully get some input on it. The discussion is at wt:WikiProject User scripts#Suggestion to avoid script incompatibility. Pyrospirit (talk · contribs) 22:47, 5 June 2008 (UTC)

Please Post On Bugzilla, Thanks!

I would be great if we could click on the version instead of having to have to click on the 2 radio buttons just to get to the later version. Please post this on bugzilla, because I don't have an account, thanks!68.148.164.166 (talk) 02:22, 6 June 2008 (UTC)

If you click the (last) link next to the revision you want to diff, you will be able to see the next change. Nakon 02:44, 6 June 2008 (UTC)

Tooltip mania

Is anyone else finding the tooltips with every wikilink excessive and annoying, or am I the only conservative fool? Whereever I'm placing the cursor a tooltip is blocking the text I'm trying to read. Is there a way to shut them off? Arman ^(Talk) 07:23, 6 June 2008 (UTC)

I don't know if you're the only one, but I find them quite useful. OTOH, I have a script that makes the tooltip on redirects rather more useful (e.g. it tells me WP:DIE points to Wikipedia:No personal attacks). Anomie⚔ 10:51, 6 June 2008 (UTC)

Sections generated by templates, and the section "edit" link

Can anyone tell me why User:Pharos/Sandbox doesn't have a section "edit" link, and how I can fix it so that it does have one? Thanks.--Pharos (talk) 15:53, 6 June 2008 (UTC)

There are no sections; see Help:Section. --—— Gadget850 (Ed) ^talk - 15:59, 6 June 2008 (UTC)

Is there any way to fix it so there are sections?--Pharos (talk) 16:02, 6 June 2008 (UTC)

You create sections by using the "=" character, thus "==== Section ====" gives

Section

I'm not sure how this would work in your template. You can add an edit-like template with {{edit}}. What are you trying to do? --—— Gadget850 (Ed) ^talk - 16:22, 6 June 2008 (UTC)

Well if a "section edit" link did appear, it would point to a section of the transcluded page (which in this case doesn't exist unless the parameter is filled in). There isn't any way to have a "section edit" link on a template properly link to a section of the page where the template is being used, unless you spoof the edit link and add an extra parameter for the section number (something like /index.php?title={{FULLPAGENAME}}&action=edit&section={{{2}}}, the last part being necessary because there's no way for a template to know how many times it has been used on a page, or how many sections are above it) if that's what you meant. — CharlotteWebb 16:30, 6 June 2008 (UTC)

Is there any way to specify the section name rather than the section number?--Pharos (talk) 17:53, 6 June 2008 (UTC)

(edit conflict) I am trying to make a template that will create a new section if a certain variables are inputted, but that will create nothing if other variables are inputted. The name of the new section, if it is created, would be based on the inputted variable. I hope this makes sense. Thanks.--Pharos (talk) 16:37, 6 June 2008 (UTC)--Pharos (talk) 16:37, 6 June 2008 (UTC)

I think this has to do with the (new) preprocessor. meta:Migration to the new preprocessor has more. --MZMcBride (talk) 17:05, 6 June 2008 (UTC)

The reason there is no link is because you are using <h2>. Soxred 93 17:32, 6 June 2008 (UTC)

Nope. It's just folks playing in my sandbox (which I'm totally cool with).--Pharos (talk) 17:56, 6 June 2008 (UTC)

OK, I've given up on the first idea. Is there any way to create a new section if certain variables are inputted, but that create nothing if other variables are inputted (supposing that the code was on the page itself, not a template)? So far, this seems to be impossible too.--Pharos (talk) 02:28, 8 June 2008 (UTC)

Format issue

The article on MARK STEYN display improperly but I cannot understand why that is. The "AWARD" section should follow that about the Canadian Human Rights. It seems correct in the edit window but, close the edit, and the article page shows the two sections running together. --Interactbiz (Norm, Vancouver Canada) (talk) 20:05, 6 June 2008 (UTC)

Fixed. See Wikipedia:FAQ/Editing#Why does part of an article not appear, although it's there in the edit screen?. --—— Gadget850 (Ed) ^talk - 20:34, 6 June 2008 (UTC)

GeoHack

GeoHack isn't working. That is, if you click the latitude and longitude at the upper right corner of Venice for instance, it shows a page of garbage instead of links to maps. The same problem occurs with other links to GeoHack such as The Bronx and Athens, and on both Flock and Explorer browsers. Art LaPella (talk) 22:03, 6 June 2008 (UTC)

Problem also occurs in FireFox 2.0.0.14 WinXp. Algebraist 22:07, 6 June 2008 (UTC)

Something is screwed up at Template:GeoTemplate. I reverted to an old revision and it's working now... still looking into what caused it. --- RockMFR 02:34, 7 June 2008 (UTC)

That was bizarre. There was nothing wrong at the template, but effectively null editing it fixed the issue. Whatever. --- RockMFR 02:42, 7 June 2008 (UTC)

Recursive page moves (rev:33565) is a great tool for vandals

A recent wiki enhancement, rev:33565, allows autoconfirmed users to move not only a page, but every subpage under it. Not surprisingly, this has become a fantastic tool for vandals like Fuzzmetlacker (talk • contribs • logs) and AV-THE-3RD (talk • contribs • logs) and Matt the barber (talk • contribs • logs). I imagine we could recursively revert the moves (although I haven't tried recursive move-over-redirect) but there is no way to recursively delete the leftover redirects. Luckily, today's attacks stopped (WP:ANI#User:Fuzzmetlacker) but zillions of other pages - mostly user talk pages - are perfect vandal targets and just a few recursive moves take a very long time to completely undo. A few ideas:

1. Turn off the feature entirely here.
2. Allow only administrators to use the feature.
3. Allow only bureaucrats to use the feature (it is most useful for renaming users and all of their subpages).
4. Implement recursive deletes.

Any other ideas? Opinions? I personally vote for 2 or even 3. I've never had a need for recursive moves. 4 - which isn't exclusive to the rest - has some appeal to me for vanishing users, etc. Hopefully we can expedite this to the developer folks before a full scale move war breaks out. (BTW, feel free to move this to a more appropriate venue like WP:VPP). —Wknight94 (talk) 23:17, 6 June 2008 (UTC)

I would agree with restricting it. The code is already built into the user renaming extension, bureaucrats have had that ability for a while. But besides renaming users, there really aren't a whole lot of uses for it here as we don't use subpages too heavily (I'm sure its great on Wikibooks though). Brion is pretty adamant about not allowing the automatic suppression of redirect on page moves through the normal interface (admins and bots already have the right to do so, but it can only be done though the editing API, which isn't enabled here yet) so I doubt automatic deletion of the redirects, which is basically the same thing but less efficient, will be allowed. Due to the limited usage, I would support limiting it to admins though. Mr.Z-man 23:25, 6 June 2008 (UTC)

I agree with restricting it only to admins+. It does work over redirect (when I did it for PhilKnight). Except today most admins deleted the main talk page first so there was no way to use the feature. When all the admins get used to the feature though all that will be left is deleting and/or protecting. Now only if d-batch and p-batch worked when looking at someone's contributions. --ÐeadΣyeДrrow (Talk - Contribs) 01:41, 7 June 2008 (UTC)

Per the devs (Werdna), it's reatelimited to the same ammount as for normal moves. _→AzaToth 23:54, 6 June 2008 (UTC)

It's ratelimited to the same number of actions per minute as normal moves. I.e., a vandal can only move, what is it? Six top-level pages plus however many hundreds of subpages they have per minute. This is an exceedingly poorly thought-out feature that's imposing hours of work for administrators to clean up one click by a vandal, whose legitimate uses are not remotely frequent enough to justify it. —Cryptic 00:52, 7 June 2008 (UTC)

Werdna told me that each page was counted, so an autoconfirmed can move say one top page, and five subpages per limit. _→AzaToth 01:10, 7 June 2008 (UTC)

Inspection of the contributions of the vandals already linked above, or the comments of the developer who actually programmed this misfeature, is enough to show that Werdna, politely, has no idea what he's talking about. —Cryptic 03:56, 7 June 2008 (UTC)

Werdna did make the change exactly as he said, but I reverted it, agreeing with Brion that it didn't make sense. It would have basically made the feature non-functional for non-sysops/bots/bureaucrats on all wikis; if that were desired, it would be best done through a separate permission. Apparently Werdna didn't notice that his commit had been reverted. —Simetrical (talk • contribs) 19:00, 8 June 2008 (UTC)

Is that new? One of the vandals I mentioned above did 100 page moves from 19:25 to 19:26 today. I alone spent the better part of a half-hour reverting what it took the three of them about four minutes to do - and they were being merciful in stopping. —Wknight94 (talk) 01:22, 7 June 2008 (UTC)

Same here, precious time that I could have been using better. I mean I understand the good it can do, but I think the possibility of abuse and use by vandals far outweighs the positives. I say make available to admins+. Tiptoety ^talk 02:11, 7 June 2008 (UTC)

How about an alternate possibility? Is it possible to simply prevent non-admins from moving user-space pages not belonging to them? That would get rid of a lot of these shock value moves. --B (talk) 04:11, 7 June 2008 (UTC)

• I'm absolutely in favor of that, B. There is no reason for any user other than an admin to be moving someone else's userpage or its subpages. NawlinWiki (talk) 04:14, 7 June 2008 (UTC)

But what if someone finds someone else's abandoned sandbox page (via Google or whatnot) and wants to move it into article space? Rare yes, but could happen. Besides, then the vandals would go elsewhere and recursively move WT:TV-NC, etc. The problematic issue is still recursive moves in general. —Wknight94 (talk) 04:26, 7 June 2008 (UTC)

I agree that recursive moves should also be limited. But I think the need to move someone else's user page is rare enough that it shouldn't be a problem to ask an admin to do it. NawlinWiki (talk) 04:51, 7 June 2008 (UTC)

I can go along with that - as a separate issue. —Wknight94 (talk) 05:00, 7 June 2008 (UTC)

I just spent the last hour or so move-protecting some of the bigger targets, so hopefully any vandal moves are limited to just a few hundred subpages at a time. *rolls eyes* --- RockMFR 05:18, 7 June 2008 (UTC)

I've written a program to find a list of pages outside the article namespace which have 10 or more subpages, and it reckons there's about 8,000. If this vandal knew what he was doing he could have caused serious damage by moving User:UBX (3984 subpages and not protected until a few minutes ago). We need to either restrict the use of this tool or get an adminbot to move protect thousands of pages. Hut 8.5 10:43, 7 June 2008 (UTC)

Sorry, there was a bug in the program. The actual figure of pages with more than 10 subpages is nearly 12000. Hut 8.5 12:13, 7 June 2008 (UTC)

From looking at the recent autoconfirmed reform, it looks like the devs like polls, if only because it's easy to see how widely supported/attended they were. Is it time to adjourn to WP:VPP with a strawpoll along the lines of "the recursive pagemove feature should be restricted to administrators. Support/oppose"?? Happy‑melon 13:27, 7 June 2008 (UTC)

I'm all for it. Unless you think the devs would be impressed with the damage that's already been done and the potential for more. —Wknight94 (talk) 17:25, 7 June 2008 (UTC)

What would happen, performance wise, if an admin moved all the ~150000 subpages of Wikipedia:Articles for deletion? --- RockMFR 17:22, 7 June 2008 (UTC)

The feature is limited to 100 subpages. Though, I'm not sure if that's just for non-admins or for everyone. --MZMcBride (talk) 18:23, 7 June 2008 (UTC)

Then test it to find out :) _→AzaToth 23:22, 7 June 2008 (UTC)

Sounds good to me :D --- RockMFR 00:05, 8 June 2008 (UTC)

The default limit of 100 pages is for 1) performance, 2) log spam. It applies to admins as much as anyone. In the future, this feature might be refined to do all the operations in a single query, and/or some method of dealing with the huge number of log entries (bot flagging?) might be used. In this case the default limit could be greatly raised. —Simetrical (talk • contribs) 19:00, 8 June 2008 (UTC)

If anyone is still wondering recursive is limited to 100 page moves for admins. 1 for the mainpage 99 for subpages. Just take a look at my contribs. My apologies to the server and any patrollers. --ÐeadΣyeДrrow (Talk - Contribs) 01:05, 8 June 2008 (UTC)

In r36038 I added a new right that can be used to restrict moving subpages. It seems very sensible to disable subpage moving for the English Wikipedia at least, maybe for all Wikipedias. I wrote the feature for Wikibooks. —Simetrical (talk • contribs) 19:00, 8 June 2008 (UTC)

(Incidentally, "recursive move" is a fairly silly name for it, since there's nothing recursive about the process. "Moving with subpages" is the name used in the software and makes considerably more sense. You wouldn't call mving a directory "recursive" because it happens to move all subdirectories as well, would you? Things like cp -r actually do recursively traverse the directory tree and so deserve the name. —Simetrical (talk • contribs) 19:03, 8 June 2008 (UTC))

Thanks Simetrical. Let's bounce this back over to WP:VPR and get a consensus. All rise and adjourn to Wikipedia:Village pump (proposals)#Restrict the "move subpages" feature to admins :D. Happy‑melon 19:56, 8 June 2008 (UTC)

There are a few general possibilities for page move stuff which should be considered. --brion (talk) 17:01, 9 June 2008 (UTC)

Such as? We're all ears (not literally of course, it would make typing near-impossible :D). Happy‑melon 17:20, 9 June 2008 (UTC)

Wikipedia logo font

What is the name of the font used in the Wikipedia logo?

Is it available anywhere?

The Transhumanist    01:00, 7 June 2008 (UTC)

Try asking Nohat (talk · contribs) since he designed it. MBisanz ^talk 01:16, 7 June 2008 (UTC)

Good idea! The Transhumanist    01:51, 7 June 2008 (UTC)

You can also ask User:Equazcion I know he knows, although I haven't seen him online for a few weeks. -- penubag  (talk) 01:55, 7 June 2008 (UTC)

It's Hoefler Text smallcaps italic 13px (according to meta:Logo and this and this and this and this), but I'm not sure if it's the italic weight or just the standard weight italicized. It's available if you have an Apple computer, or pay Hoefler & Frere-Jones US$299 for a single cpu licence. -- Quiddity (talk) 03:47, 7 June 2008 (UTC)

Unified watchlist

Now that we have unified login, we can access watchlists on other Wikimedia sites without logging in from our browsers. Has anyone written a javascript to scrape the watchlists off other wikis and display them all on the same page? If not, can we? — Omegatron (talk) 17:18, 7 June 2008 (UTC)

Great idea! I'd like an other project new messages banner too:

You have new messages on the English Wikipedia.

and that could use a similar system...... Dendodge .. Talk^Help 17:45, 7 June 2008 (UTC)

That would be sweet. Gary King (talk) 15:51, 8 June 2008 (UTC)

Obviously with the coloured background. We ought to post this at bugzilla (I'll do that now)...... Dendodge .. Talk^Help 19:08, 9 June 2008 (UTC)

bug 14488 filed...... Dendodge .. Talk^Help 19:17, 9 June 2008 (UTC)

i have an illegal hacker block

i can not access to this talk page. i think a fascist Spanish hacker has blocked my access. Please, could some checkuser check it and see what is happening there with my IP?

i don't know where to leave this message so if anyone know what i have to do a little help i would thank it very much. —Preceding unsigned comment added by Sclua (talk • contribs) 17:31, 7 June 2008 (UTC)

I mediated a case involving you and this article a while back, and when I was dealing with it there was no mention of topic-banning you or anything - obviously this is worse than a topic ban (and is not permitted by WP policy). I doubt it's a hacker (remember WP:AGF) so it was probably a problem with your internet. We (Wikipedia) can't do anything so you could try again, or leave it...... Dendodge .. Talk^Help 17:39, 7 June 2008 (UTC)

Also suggesting that 'Spanish fascists' are responsible is disruptive, and makes your question much less legitimate. Please try to state your problems clearly and objectively, rather then blindly accusing 'fascists' for your problem. Thanks, Prodego ^talk 22:52, 7 June 2008 (UTC)

Problem solved i would like to thank the anonymous expert for solving my problem. If he leaves a messsage like "hello" on my page talk i will call him if i have this problem again, if not, i will try to come back here (i am saying "try" because i was unabled to access to these Village pump sections too, only post. Many thanks. (i will try to moderate my vocabulary). --Sclua (talk) 11:25, 8 June 2008 (UTC)

Strange problem: I'm 'half-blocked'

A few days ago, I started getting a message telling me that my IP or IP range was blocked whenever I went to a page-editing screen whilst not logged in. (Not that I ever edit without logging in first anyway, but I sometimes go to edit screens whilst not logged in so that I can see a page's code).

I can still edit when I am logged in. What's going on? Have I been 'caught in the crossfire' between some other user and the admins? --The Machine (talk) 00:45, 8 June 2008 (UTC)

Apparently, your IP is blocked. But that's a feature to MediaWiki, unless autobloc kis enabled, logged-in users can still edit. Soxred 93 01:46, 8 June 2008 (UTC)

Actually this will prevent other people's auto-blocks from affecting you, and also prevent you from forgetting to log in before editing. Might be a blessing in disguise. — CharlotteWebb 11:00, 8 June 2008 (UTC)

It seems like someone's softblocked your IP, or a range containing it. Most commonly this is because there's vandals on the same IP range as you, but legitimate contributors (such as you) there too. The only inconvenience to you should be that you're forced to log in to edit, so the software can tell that you're one of the legitimate users (generally speaking, creating accounts from inside such ranges is prevented, and vandal accounts which are inside the range are blocked, so only legitimate users inside the range have unblocked accounts to log in with. This sort of softblocking is especially common on school IPs (where there are often many vandals and a few legitimate users editing from the same IP), but can happen elsewhere. --ais523 16:14, 8 June 2008 (UTC)

Okay; thanks folks. So what do I do, then - just carry on as normal and let this thing run it's course? --The Machine (talk) 19:03, 9 June 2008 (UTC)

Tring to find <.math.> coding error

Resolved.

I'm trying to see where I'm making a mistake

• Failed to parse (lexing error): \ x'=ax+by+k_1

• 
• 
• Failed to parse (lexing error): \ x'=ax+by+k_1

These code as

*<math>\ x'=ax+by+k_1</math>
*<math>\ y'=cx+dy+k_2</math>
*<math>\ x'=ax+by+k_1</math>
*<math>\ x'=ax+by+k_1</math>

Any help would be appreciated. —Preceding unsigned comment added by Jmckeon ie (talk • contribs) 00:47, 8 June 2008 (UTC)

I can confirm the first and fourth formulae contain a symbol (&#129;) which doesn't render in LaTeX, apparently. x42bn6 Talk Mess 03:10, 8 June 2008 (UTC)

The first and fourth expressions have a bogus byte "", 0x81. This is invalid UTF-8 (I think, haven't calculated it out) and makes no sense to have in LaTeX formulas in any event. I don't know how it got there, but try manually retyping the bad formulas instead of copy-pasting, and it should go away. Like this:

—Simetrical (talk • contribs) 19:08, 8 June 2008 (UTC)

cheersJmckeon ie (talk) 20:21, 8 June 2008 (UTC)

It's valid UTF-8 encoding, it's just not for a useful character -- it's in a control character block, but isn't assigned to any... control... :) --brion (talk) 16:44, 9 June 2008 (UTC)

Tools: link target

When is the tools: interwiki-like link going to be targeted to point to toolserver.org instead of tools.wikimedia.de? — Dispenser 05:38, 8 June 2008 (UTC)

Its been updated on the Interwiki map, so it will be updated once the script is run to update the database. Mr.Z-man 06:40, 8 June 2008 (UTC)

ANNOYING PROBLEM WITH EDITING

Help me! Whenever i click edit on a page or Edit this Page, i get a download box asking for me to download 'index.php PHP file from wikipedia.org'. I have found that adding &internaledit=true to the URL of the edit page (e.g. http://en.wikipedia.org/w/index.php?title=TITLE&action=edit&internaledit=true ). But now i have to do that all the time so i can go to the edit page. This is very annoying. Can you please help promptly.....Juggernaut0102(talk) 09:47, 8 June 2008 (UTC)

Did you accidentally check "[x] Use external editor by default" in the "Editing" tab of Special:Preferences? — CharlotteWebb 10:56, 8 June 2008 (UTC)

Even if you didn't, that box has been known to be checked by gremlins. Algebraist 12:37, 8 June 2008 (UTC)

Thanks! it worked!! Juggernaut0102 (talk) 07:24, 9 June 2008 (UTC)

Baseball Card Adventure

This is really puzzling me. {{Baseball Card Adventure}} has the Category:Novel series templates cat with two noinclude tags wrapped around it. Yet despite this...on the article Joe "Stosh" Stoshack it still shows that Novel series template category. How can this be fixed? hbdragon88 (talk) 23:28, 8 June 2008 (UTC)

It didn't transclude the template; it was either substed or copied. Fixed now. —Cryptic 00:01, 9 June 2008 (UTC)

Image:King JesusII.jpg

This image page suffers from a strange problem. There is no history but the page clearly exists. There is no associated file. I can't edit the page to tag it for deletion because I always get an edit conflict, apparently with nobody. The length of the page is (allegedly) 0 but when I view the page source, it is not empty. It probably isn't worth bugging the devs at this point, we might be able to find a resolution to this problem here. MER-C 09:01, 9 June 2008 (UTC)

Solved by deletion[6]. Wasn't used anywhere anyway. MaxSem^{(Han shot first!)} 09:35, 9 June 2008 (UTC)

I thought that was the case. Thanks. MER-C 12:29, 9 June 2008 (UTC)

Watchlist auto-refreshing...

This has only recently started to happen -- maybe in the past two days or so. Basically, the way it has worked is that the watchlist page (and any other WP page, not sure if it's affected elsewhere) would stay at the last it was last on, like most pages. There's some pages on the web that will automaticallyr refresh whenever you switch pages (which can be annoying as it also tends to put you back up top), but here it seems that it's only doing it if I move two pages deep (like click "older edit" twice) or more. Anyone else notice this, and is there a way to fix it...or perhaps it's a bug? ♫ Melodia Chaconne ♫ (talk) 16:10, 9 June 2008 (UTC)

Well assuming you don't have some javascript set up to automatically refresh a browser window or tab which contains your watchlist (Brion would probably kill you for that), you probably mean that you are clicking the "back" button in your browser (to go back to your watchlist) and finding a newer list of edits than when you last saw it. That would mean that your browser is for whatever reason no longer caching the watchlist page (maybe caching is disabled now, or maybe you changed browsers), or that your browser did cache the page but it has been removed from your cache as "too old" or to clear space to cache something else. So you might start by adjusting the page-caching settings in your browser. — CharlotteWebb 17:19, 9 June 2008 (UTC)

That's just it, I haven't changed any settings, nor has it ever happened like this before. The only difference is the updating of two plugins (I use Firefox) but nothing beyond that has changed. I can't imagine either of those plugins affecting it. I figured something in WP's software changed recently since it seems to only be affecting things here that I've noticed. ♫ Melodia Chaconne ♫ (talk) 19:08, 9 June 2008 (UTC)

...and I think I found the culprit. It seems to only happen on the Video Games Project talk page. Must be something there doing it. ♫ Melodia Chaconne ♫ (talk) 19:16, 9 June 2008 (UTC)

Proposals

Being able to edit your edit summaries

Ok, I've done this way too often. I make an edit, write the edit summary, and click "Save page", only to notice that I completely misspelled a word. At this point, there is nothing I can do about it other than hope nobody looks at my contributions. My proposal is being able to edit your own edit summaries. I brought up this discussion on one of the Wikipedia IRC channels, and there were plenty of ideas. The first is only letting admins edit summaries, and letting people make requests for them, because there is fear that other users would abbuse it, and possibly fabricate them. The other is only being able to make minor edits to fix typos, and prohibit completely rewriting the edit summary. I know this sounds odd, but some people (myself included) think this would be something that would make editing a little easier. Juliancolton ^{Tropical Cyclone} 17:06, 23 April 2008 (UTC)

I really don't see the need for this, nor a big problem that this would solve. If anything, a user script can be created that would require some sort of confirmation of your edit summary before saving it. - Rjd0060 (talk) 17:36, 23 April 2008 (UTC)

I think such a feature would be useful, as long as only admins could change them, and a history of the changes was logged. It should only be done for typos and minor mistakes. Fabrications of edit summaries would obviously not be allowed. Majorly (talk) 18:17, 23 April 2008 (UTC)

I would say have it so you could only change it if it was the most recent edit to that article (and it was your edit, ofcourse). This would do away with the need for a history of changes, admin-only restriction, etc., while allowing for fixing of one's edit summary in the vast majority of cases where it would be useful and appropriate. Kevin Baas^talk 18:21, 23 April 2008 (UTC)

This would require a fundamental change to how Wikipedia's database is structured. _(1 == 2)^Until 18:40, 23 April 2008 (UTC)

How so? You wouldn't need to change any table names or column structures. As far as the database is concerned, it would just be one additional "update" query. Something like "update [table] set summary=? where article=? and revision=? and editor=? and revision=(select max(revision) from [table] where article=?)". That's not what i'd call a "fundamental change [in the] database [structure]". Kevin Baas^talk

I'd much rather be able to change my log summaries (blocking, protecting, etc) which can sometimes look odd with typos. MBisanz ^talk 18:43, 23 April 2008 (UTC)

I would support that if it's possible. I would add though, that a message (like "This edit summary was added at <TIME/DATE>") was added at the end of the summary and then let admins view all versions of the edit summary. -- Imperator3733 (talk) 20:29, 12 May 2008 (UTC)

Why waste time fixing a typo in an edit summary? Edit summaries are not part of article content, and so it doesn't matter that they have perfect grammar. If you really need to amend or retract an edit summary, then make a dummy edit or use the talk page. –Pomte 20:12, 23 April 2008 (UTC)

Because that would be an even greater waste of time to leave a message on the talk page. And it wouldn't take that long. It could be like Rollback. You have to be granted the ability to edit your edit summaries, and then you just have to press a button or something. And really, how much time is it going to waste? Also, an edit summary is supposed to give an overview of what you've changed in the article. If you misspelled something or gave the wrong information, people might mistake what you've done. Juliancolton ^{Tropical Cyclone} 20:27, 23 April 2008 (UTC)

And it can get worse. I have sometimes pressed the wrong key while writing the edit summary (I still don't know exactly what I did) and that resulted in the edit being saved with just half the summary. This is obviously unhelpful. Waltham, The Duke of 21:02, 23 April 2008 (UTC)

That happens to me all of the time. You pressed Enter. hmwithτ 18:26, 15 May 2008 (UTC)

I would go with Kevin Baas on this one. One's most recent summary should be editable to fix typo. Any more than that, I and see RfA candidates going back to give themselves a leg up. —Preceding unsigned comment added by Paragon12321 (talk • contribs) 22:29, 23 April 2008 (UTC)

There is a simpler solution. Cultivate the habit of proofreading the edit summary as well as the actual edit when you show a preview. If you make a small error, it is really not a problem. If you really screw it up, make another edit to carry a correction.

Letting people alter either edit summaries or the substance of edits is allowing the rewriting of edit histories. It undermines the integrity of edit histories. The benefits are not anywhere close to being worth the cost. IMO. Wanderer57 (talk) 02:25, 24 April 2008 (UTC)

Not if you only let them change their edit summary if it was the most recent edit to that article - as soon as another edit is made you can no longer change the edit summary, so a historical record is kept (and shown) that can't be rewritten. Kevin Baas^talk 15:36, 24 April 2008 (UTC)

You may be right. I think people are underestimating the technical difficulties involved in allowing people to edit their edit summaries, and overestimating the benefits of doing so. Wanderer57 (talk) 06:01, 25 April 2008 (UTC)

This is a great idea! I suggest limiting it to the latest edit during a 1 - 12 h period. Coding-wise it is an absolute no-brainer and will be very easy to implement (contrary to the above comments). Full support - Сасусlе 00:15, 26 April 2008 (UTC)

This is also good if you accidentally forgot to add a summary or put in the wrong one (happens if you have many tabs open). This would cut down on pseudoedits just to give or correct a summary. Сасусlе 20:49, 26 April 2008 (UTC)

Straw poll

I think it is too early to start a straw poll, please let us discuss details and implications a but further. Сасусlе 20:49, 26 April 2008 (UTC)

See also: bugzilla:10105. --MZMcBride (talk) 20:55, 26 April 2008 (UTC)

Support

1. This is an excellent idea. At present, vandals can put offensive comments in an edit summary and nothing can be done about it other than attempt to get the edit deleted from history. GO-PCHS-NJROTC (talk) 20:29, 26 April 2008 (UTC)

   I am pretty sure that there is a wide consensus that admins should NOT be able to edit summaries of other users. We are talking so far about changing your own summary during a limited time period for every user. Сасусlе 20:49, 26 April 2008 (UTC)

   That sucks; I think admins should be able to edit the edit summaries; I have seen WAY too many vandals using abusive edit summaries. But I still support, there's been plenty of times when I've screwed up with edit summaries and wished I could go back in and fix the problem. GO-PCHS-NJROTC (talk) 00:20, 28 April 2008 (UTC)

   If an edit summary in a vandalism edit is that offensive, the revision can be deleted by an admin -- no editing necessary. Equazcion •✗/C • 09:34, 4 May 2008 (UTC)

2. I have often wished I could edit my summary - sometimes I noticed my error just as I clicked the Save button. Allowing users to edit their own summaries immediately after saving and before any other edits to the page seems very reasonable. Sbowers3 (talk) 00:02, 28 April 2008 (UTC)
3. have it so you could only change it if it was the most recent edit to that article (and it was your edit, ofcourse). Kevin Baas^talk 14:19, 3 May 2008 (UTC)
4. This idea would be wonderful if it can ever be implemented. Users should only be able to edit their own summaries, except admins can edit other users summaries to remove stupid comments ect. .:Alex:. 19:25, 3 May 2008 (UTC)
5. Excellent idea; more people see edit comments that the actual text, and how many times have we all see boo-boos after pressing the button? TONY (talk) 14:00, 5 May 2008 (UTC)
6. A fine idea - a few times I've hit "Save Page" and at the last moment realised that I've omitted something from the edit summary that perhaps should have been there. I see no real drawbacks (apart from the drain on the programmer's time) to this proposal. Lankiveil ^{(speak to me)} 12:12, 12 May 2008 (UTC).
7. Support - users should be able to edit their last edit, as long as it is the last edit to a page and it has been no more than a couple hours. -- Imperator3733 (talk) 20:35, 12 May 2008 (UTC)
8. Support - It would stop embarassing things like this, where I had the fingers of my right hand one key over from where they were supposed to be and didn't notice until I'd hit "Save page". ~ ONUnicorn^{(Talk|Contribs)}problem solving 00:02, 17 May 2008 (UTC)
9. Support, On the grounds that the user can only edit their own summaries. Also, admin should be given the right to edit anyones summaries. Rgoodermote  19:46, 20 May 2008 (UTC)
10. Support for own edit summaries only, but with admins able to edit offensive edit summaries by anyone. DuncanHill (talk) 11:05, 21 May 2008 (UTC)
11. Support for last edit only, by same person/IP only. --207.176.159.90 (talk) 23:58, 21 May 2008 (UTC)

    Comment:No offense but I myself do not like the idea of an IP being able to edit their own edit summaries. I know you are an IP. But I would like to suggest that IPs be given a limit. Rgoodermote  18:11, 22 May 2008 (UTC)

12. Support - offensive summaries or summaries that reveal personal data are a big problem, but right now there is no way of editing them except for deleting the edit completely... which is not a solution most of the time. Figure out a way to prevent abuses, but it should be implemented. Renata (talk) 21:51, 24 May 2008 (UTC)

Short break:

It was really not a good idea to start a poll without talking about the same thing.

The current proposal and bugzilla discussion can be found here. It asks for a mechanism to correct edit summaries (1) if it is your own edit (2) and if it is the last edit (3) during a short time span. This exact same mechanism is implemented in most online forum systems and has proven its efficacy and safety. Under these restrictions (own, last, recent), there is absolutely no potential for abuse (e.g. any following edit would make the previous summary permanent). At the same time you keep the benefits such as fixing accidentally empty summaries, switched summaries (when you have many tabs open), and half-completed raw summaries.

I am sure that many of the opposing users (as well as some supporting users which were obviously voting for a different mechanism) would actually support such an implementation under these restrictions. Again, this is not about allowing administrators to change summaries, not about allowing admin candidates to white-wash their editing history, and not about giving vandals any type of new toy. It would just be a nice feature to make editing Wikipedia easier - nothing more and nothing less. Cacycle (talk) 03:28, 28 May 2008 (UTC)

I completely agree. With all due respect to the editors who have voted above, and to their arguments, a poll as badly organised as this one can yield little useful information on the consensus for the specific proposal made here. Waltham, The Duke of 15:22, 30 May 2008 (UTC)

Conditional Support

• On one hand there should be a mechanism for removing disrputive, offesnsive, promotional, or dangerous edit summaries without going through oversight. On the other hand, I'm opposed to allowing any user to change any edit summary. It has a huge potential for abuse or misuse and I'm not sure why the average contributor would need that capability anyway, except maybe to correct a typo on their last edit. My vote would be to definately give sysops the capability to modify or remove offensive or disruptive edit summaries, and to allow other users to edit their own most recent summary under some type of time limitation. Mister Senseless™ (Speak - Contributions) 18:39, 1 May 2008 (UTC)
• Yes – I have made typos in edit summaries, and also sometimes wished that I had written one (instead of using the default). This is a neat idea. However, I am not sure if there are any legal issues (therefore, I'm putting my support as "conditional.") 69.140.152.55 (talk) 14:10, 12 May 2008 (UTC)
• Weak support leaning towards "not really important", there's been a few instances where I wished I could fix my edit summary, but again it's no big deal (forgive the cliche). If it's not a huge technical hurdle, I'd support editing the last edit summary only, during a 5 minute window following the edit. xenocidic ( talk ¿ review ) 16:40, 15 May 2008 (UTC)
• Strong support as long as we are talking about an editor being able to change the summary of an edit if, and only if, it is their own edit, it is the most recent edit on the page, and no more than, say 12 or 24 hours have passed; this should apply equally to all registered users, including sysops. There is no potential for abuse there (nobody would "re-write article history"), and all sorts of problems with erroneous or incomplete summaries would be solved without complicating the history by leaving confusing or misleading summaries or making otherwise useless edits. Waltham, The Duke of 09:39, 18 May 2008 (UTC)
• Conditional Support Good idea, though I don't view not having this capability as a significant hinderance to the work of most editors on Wikipedia. If it is something that can be fixed in a relatively simple way, then I'm all for it. If not, then there are bigger fish to fry. - Masonpatriot (talk) 15:46, 3 June 2008 (UTC)
• Conditional Support I thinks users should only be allowed edit their own edit summaries, this way if you make a mistake you can correct it. Who cares if someone says something offensive in an edit summary. Pseudoanonymous (talk) 02:03, 9 June 2008 (UTC)

Oppose

1. Not worth fussing over. Live with your embarrassing mistakes, or make a non-edit follow-up to correctly describe your mis-typed previous edit. Too many issues about the reliability and fixed-ness of the edit history database arise in ths proposal. -- Yellowdesk (talk) 20:04, 3 May 2008 (UTC)
2. Language in an edit summary is often quoted in disputes, often very quickly after the edit. Fixing the imo trivial problem of typos in summaries would seriously jeopardise the ability to verify these claims if an editor can go back and modify their summary based on future events. Frankly, well meaning intentions aside, this is a no-brainer, or should be to anyone who has followed a few disputes before. A far worse problem that needs addressing is allowing no summary. MickMacNee (talk) 18:16, 13 May 2008 (UTC)

   But under this proposal, the edit summary could only be changed if it was the last edit made. It seems to me that most of the time what you are saying would not happen. Plus, I think someone proposed that admins would be able to view the previous edit summaries. -- Imperator3733 (talk) 14:42, 14 May 2008 (UTC)

3. Resounding oppose - toooooooo much potential, hardly any benefit, causes some damage (yeah, I know...), if people want to retract an edit they can always do a null edit afterwards. —TreasuryTag—t—c 18:56, 13 May 2008 (UTC)
4. This seems to offer little actual improvement to the editing experience to offset the major disruptions it could cause to the process of dispute resolution, vandalism fighting, etc. --Gwguffey (talk) 19:46, 13 May 2008 (UTC)
5. Strong Oppose. We have enough problems with vandalism without creating a route for "edit summary vandalism". – ukexpat (talk) 15:22, 14 May 2008 (UTC)

   If the editing is limited to the last edit during a relatively short timespan I do not see the potential for vandalism or disruption as any subsequent edit (e.g. fixing vandalism) makes a summary permanent. Cacycle (talk) 03:57, 15 May 2008 (UTC)

6. Highly doubt this would ever actually happen, but here's my two cents anyway. I agree it's annoying when you accidentally make a stupid grammar or spelling error in an edit summary, yeah it can be embarrassing etc, but guess what, it happens to all of us and it isn't important, so just deal with it. Also, as someone points out above, summaries are used as evidence in disputes -- so the ability to edit them would add a certain kind of recursive complication. Similar to the fact that edit summaries are required when editing a page, edit summaries would probably be needed when editing edit summaries as well -- it is, after all, the ability to change evidence, so an explanation for the edit would be needed, not to mention a history of previous versions.... seems to be getting silly then, right? You bet. This would only cause problems and, trust me on this one -- it's just not happening. No developer in their right mind would ever add this kind of superfluous functionality. Equazcion •✗/C • 04:16, 15 May 2008 (UTC)
7. Per above. ES are have document character here. If we make then editable we need a history/permalik feature for them as well. This will not happen. Don't waste your time fussing about it. The benefits are marginal. Everyone makes typos sometime, just suck it up. --Dschwen 17:09, 15 May 2008 (UTC)
8. Strong Oppose: They are often used in RFArb cases, so no hiding embarrassing edits. --Dragon695 (talk) 00:50, 23 May 2008 (UTC)
9. I have made spelling mistakes in my edit summaries an embarrassing number of times but I don't really see having the option to edit them improving the encyclopaedia. Spelling mistakes - not really a big deal, being able to easily hide past negative behaviour is potentially a big deal. If edit summaries were editable would they have histories, are are these histories going to have edit summaries, will those be editable? Guest9999 (talk) 02:50, 23 May 2008 (UTC)
10. Strong Oppose - Negligible benefit, strong likelihood for misuse/abuse. /Blaxthos ( t / c ) 12:11, 24 May 2008 (UTC)
    • I am referring here to all the opposing parties using this as an argument: How could the feature possibly be abused if the summary could only be changed within a few hours and as long as the edit is the top one? Or do people expect cases to open on the same day as the edit summaries are given? Honestly, I do not understand this. Waltham, The Duke of 23:29, 26 May 2008 (UTC)
11. Oppose. The benefits are negligible while the potential for abuse is substantial. Nsk92 (talk) 19:08, 24 May 2008 (UTC)
12. Oppose One of the points of edit summaries is to keep a record. Are we to also have edit summary histories? Do you make an edit summary to explain the change to you edit summary? Can you change those edit summaries too? This is a waste of the developers time too, as the current software cannot do this. _{1 != 2} 19:14, 24 May 2008 (UTC)
13. Oppose I do not see the problem for which this proposal advances a solution. I can imagine new problems and new rules about who is allowed to edit what in which summaries, and how to deal with those who abuse the feature, people suspected of abusing the feature, or people not using the feature being told they should. in lieu of null edits, etc. Why create a new layer of crap when the status quo is actually just fine? Jerry talk ¤ count/logs 17:34, 26 May 2008 (UTC)
14. Oppose if this were implemented, modifications would have to be logged for transparency. And of course, we'd have to have a field in which users could provide an explanation as to why they edited the summary. And then... oh... :D Happy‑melon 16:42, 27 May 2008 (UTC)
15. Oppose. Too little benefit would cost too much in time and effort. WODUP 20:36, 27 May 2008 (UTC)
16. So not worth it. It is supposed to be a record of what happened on the wiki - if you could change it (at all!) that defeats the purpose. Also, we would need a log for changes. But then people might make typos... – Mike.lifeguard | ^@en.wb 23:39, 31 May 2008 (UTC)
17. Strong Oppose Completely unnecessary and a real potential for abuse add up to make this a very bad idea. We've all made typos and other typographic faux pas and, yes, it's embarrassing. But it's very much not a big deal. Too real a potential for abuse for this to be implemented. faithless (^speak) 08:28, 1 June 2008 (UTC)
18. Strong oppose - We should be concentrating on editing articles, not summaries. Sure, it looks stupid to have a misspelled word in your edit history, but in the bigger picture who cares? All it really does it open up potential new problems (even with the "own, last, recent" restrictions mentioned below) and not improve the encyclopedic content of Wikipedia. As such, it runs counter to the principles of Wikipedia. As someone above mentioned, check your work before you submit. Also preview your work. I will edit and preview a massive rewrite of an entire article for sometimes two days before I finally hit submit. The change log shows +10,000 or more article length increases in a single edit, with no need to go back and make further edits. If you're careful, you don't need to edit your edits. That's not to say I never make mistakes (I'm human, not a bot, after all), but so what. Sometimes it's funny to look back at your goofs and smile. --Willscrlt (Talk) 11:07, 1 June 2008 (UTC)

    Willscrlt: I completely agree that we should not care to correct typos in summaries. But that is not the reason for this proposal anyway. The only reason why we need this is to correct accidentally misleading summaries, such as empty, switched, or half-written summaries. I do not see that Wikipedians would start focusing on editing old summaries instead of articles, so I do not really understand your strong opposition against this nice to have feature - especially after your confession that even you make some summary mistakes from time to time ;-) Cacycle (talk) 19:07, 1 June 2008 (UTC)

    I suppose that the reason is that summaries a) can be accidentally misleading - what a person only slightly familiar with a subject considers an "insignificant change" can be a big deal to someone intimately familiar with it; b) can be deliberately misleading - a vandal could say "correcting typos" when really he changed every occurrence of "orange" to "purple"; c) are often omitted because many people don't care or understand; and d) are no match for a quick diff comparison (I love popups for that). I guess my thinking is that summaries are nice, but are not an essential feature of the software. Editing comments is really wasting time that could be spent on improving the project. It also makes the software more complicated and increases the chance that a bug could be introduced. I run two other wikis that use MediaWiki software, and I would prefer to keep feature creep out of the software when it doesn't significantly improve anything. --Willscrlt (Talk) 23:08, 1 June 2008 (UTC)

Neutral

• As a number of people mentioned above, this could be difficult in implementation and perhaps more importantly could have wider implications. My suggestion would be a special kind of 'change edit summary' edit. This would function much like the above (only possible with most recent edit by the person who made the edit and perhaps some sort of time limit as well) except instead of actually changing the edit summary, it simply makes an automatically completely null edit with summary and marks the previous edit summary as 'obsoleted' or something of that sort (similar to minor edits and bot edits). By default, these obsoleted edit summaries will be hidden but editors can obviously chose to view them if they so desire. My suggestion would be to extend this to edits as well. (It will always be completely optional.) This way, editors who e.g. don't preview or otherwise make several edits in quick succession can choose to hide the intervening edits if they desire to make it easier for other editors to browse the edit history (but as I mentioned other editors can still view the intervening edits if they want). A time limit will probably be important in this case to avoid editors who think they're funny and vandalise or cause other problems and then hide it a few hours later to try and obscure what they're doing, and also to avoid encouraging editors to edit when they are in a foul mood thinking they can hide anything bad they did later. Potentially this should be added as an autoconfirmed option or even a rollback option to discourage misuse further. Nil Einne (talk) 06:50, 1 May 2008 (UTC)

  Under the restrictions we are currently talking about (last plus own edit for a short time) I do not see the potential for abuse (after all, any following edit to the page makes the previous summary permanent). Therefore, I do not think that we need a history for this. A simple link on the history page that lets you change the summary entry of that edit would do it. We probably want to restrict this to registered users, but I do not think that we would need further restrictions. Сасусlе 21:46, 1 May 2008 (UTC)

• While I'm still roughly neutral on whether an editor should be able to edit their own edit summaries (I can see both points of view, but haven't personally decided yet), I don't think admins should be able to edit "anyone's". Yes, talk page comments may be edited, but only under certain situations. (And I've seen enough successive revertings by admins of such edits, to be concerned.) And we really don't need to see the creation of reversion histories of edit summaries. So opening this door would seem to be a bad idea. And there's no real "need", since admins can always delete the revision in question. (And which can also be undeleted. And already has a set of logs.) If it's deemed truly necessary, just add this ability to the oversight "package". - jc37 20:17, 6 May 2008 (UTC)

Please participate in the discussion of the "official feature request" for this under https://bugzilla.wikimedia.org/show_bug.cgi?id=13937. Cacycle 19:16, 3 May 2008 (UTC)

Bugzilla is for technical implementation, not discussion of this sort. The developers will not be happy if you start spamming the bug with "DO WANT!" – Mike.lifeguard | ^@en.wb 03:59, 1 June 2008 (UTC)

Page move speed restriction

I believe there has been an increase in page move vandalism recently by sockpuppets (it could also be my imagination) and I remember a user (one account) who moved in excess of 40 pages before being blocked. This was mainly due to the speed that they are able to move pages and the fact that it requires an admin to properly clean-up afterwards means the damage can be significant. I therefore propose that there be a restriction on page move speed (e.g. no more than 10 in 5 minutes). I understand that this would inconvenience some users who wish to move lots of similarly badly-titled articles etc. but the benefits outweigh the inconveniences in my opinion. GDonato (talk) 18:34, 29 April 2008 (UTC)

Good idea if the software can be modified to accomplish this, though I'd suggest a limit of one move per minute. Obviously admins should not be subject to this limit. -- John Broughton (♫♫) 19:09, 29 April 2008 (UTC)

I would support this as well (though it would have to be 2/min, article & talk). Mr.Z-man 19:13, 29 April 2008 (UTC)

Bad idea. Some (maybe even most) valid page moves require multiple moves in order to be complete. The original page, the talk page, archives, perhaps some redirects -- A single move can mean multiple actual pages need to be moved, and the next time I have to do that, I don't want to have to do part of them and then remember to come back ten minutes later to do the next part. What we need here is a better way for editors to revert bad moves, rather than more restrictions. Equazcion •✗/C • 19:16, 29 Apr 2008 (UTC)

Or that, but I can't see how it is possible. GDonato (talk) 21:06, 29 April 2008 (UTC)

The 10 moves in 5 minutes idea sounds good. That should be enough to do most moves without having to wait. Of course, admins should not be subject to this. -- Imperator3733 (talk) 20:42, 12 May 2008 (UTC)

Is there any real reason not to set a throttle?, as evidenced here [7], unlimited page moves once autoconfirmed is a lot more useful for vandals, there can't be many legitimate reasons for a mass of page moves in a short space of time, and in those cases, it wouldn't be difficult to get admin help, obviously they'd be exempt--Jac16888 (talk) 16:41, 27 May 2008 (UTC)

Straw poll

Just to get an idea of whether anybody actually wants any changes and, if so, what they should be. Please feel free to sign under the heading which you believe would be the best solution to the page move vandalism "problem". GDonato (talk) 20:35, 5 May 2008 (UTC)

Increase autoconfirm

Please see Wikipedia:Autoconfirmed Proposal/Poll.

Page move speed restriction

1. There is a restriction already, of course, but making it smaller would probably be worthwhile. Now we have the move-with-subpages feature, 1/60 (i.e. one page move a minute) would probably be worthwhile. With the current setup admins and bots would be immune to it, and it would be trivial to set up a third group that could move pages more quickly (along the same lines as accountcreator) if a need for it were found. --ais523 13:57, 9 June 2008 (UTC)

Easier to undo page moves

Don't change anything

1. Oppose - I can surely see the logic of the proposal. However, having gone through a three-month long cleanup and reorganization project on well over a hundred articles, the proposal would have been a real pain in the butt and might have stopped me from completing the project. On top of that, I was a new user, with something like 10 edits under my belt when I started (just in case anyone thinks that the limit should only apply to new accounts). Perhaps throwing up a CAPTCHA after that time threshold would be adequate... not for each move, but every n-th move per x minutes. But really, that just makes the whole process even more complicated. Yeah, page moves can be abused, but I think the "cure" [any increase in the limit] would be worse than the problem in this case. --Willscrlt (Talk) 11:12, 1 June 2008 (UTC)

   Well, as pointed out below, there is already a limit in place, so definitely don't change anything. --Willscrlt (Talk) 23:10, 1 June 2008 (UTC)

Comments/other

1. Tight page move limit for accounts that have no edits between now-24 hours and now-720 hours, perhaps 0 page moves/minute. This will stop most socks.

• • Page move limit around 5/minute for accounts not falling into #1. Moving a page and the automatic move of the talk page counts as one move.
  • "Mover" attribute conceptually similar to "rollbacker" that effectively removes the move rate limitation. Attribute automatically (or manually) given to admins, and may be given by admins to others. Loren.wilton (talk) 12:12, 23 May 2008 (UTC)

There is already a page move speed restriction, didn't you know?

1. Gurchzilla (talk) 16:05, 16 May 2008 (UTC)
2. – Mike.lifeguard | ^@en.wb
3. --MZMcBride (talk) 06:37, 3 June 2008 (UTC)

Uh, do you know what it is? LegoK^ontribsT^alkM 06:13, 3 June 2008 (UTC)

'wgRateLimits' => array(
    // Limit new accounts to 2 moves per 90 seconds, and anons to 3 edits per 30 seconds
    'default' => array(
        'move' => array( 
            'newbie' => array( 2, 120 ),
            # To limit high-rate move page attacks on smaller wikis
            # Newbie limit was trivially avoided by a patient vandal
            'user' => array( 8, 60 ),
        ),
    )
),

from noc.wikimedia.org/conf. --MZMcBride (talk) 06:37, 3 June 2008 (UTC)

Favicon improvement

As requested by User:Alex.muller, I created a new version of our favicon. The idea was simply to remove the big (ugly) white box and instead make the background transparent. See the screenshot above, which compares the new favicon (FaviconNew.png, left) to the current one (right). Welcoming any comments. Equazcion •✗/C • 15:22, 17 May 2008 (UTC)

• Great work! looks much better, this is a no-brainer for me. The sooner its up the better (Nice job on the logo too btw, hope the devs take care of it) Acer (talk) 15:49, 17 May 2008 (UTC)
• Agreed. This looks good. Since this is based on Image:Favicon.png, it should inherit the description and license information and be moved to Commons. --— Gadget850 (Ed)talk 15:57, 17 May 2008 (UTC)
  • I'm not that knowledgeable with licensing, but just FYI, Favicon.png is a screenshot, not the actual favicon, so I'm not sure about that. Also, I couldn't actually use any of the old images to make this, it's made from scratch, so I don't know how much of that licensing info should be transferred over. In other words it's not actually "based" on anything, if that matters.Equazcion •✗/C • 16:11, 17 May 2008 (UTC)

• That looks much better... at 16x16. It looks horrible at 32x32. Yes, making a favicon invloves creating several images at both 16x16 and 32x32 in both 16 and 256-color formats, and maybe even 24-bit with alpha. — Edokter • Talk • 18:37, 17 May 2008 (UTC)
  • Image:FaviconNew32.png. I'll hold off on creating all the other necessary variations until consensus is reached. Equazcion •✗/C • 18:48, 17 May 2008 (UTC)
    • Just to be clear, you know the ICO file format actually stores several different icons at different resolutions at the same time, right? Does anyone know if you can upload ICO files to Mediawiki directly? I can't say that I've ever tried. Dragons flight (talk) 18:57, 17 May 2008 (UTC)
      • I knew Windows .ico files could do that, but I didn't know favicons were stored that way. I don't have software that does that, I'll have to look into it. I doubt mediawiki can store them in image space, at least not as viewable images. Equazcion •✗/C • 19:01, 17 May 2008 (UTC)
        • Our favicon is http://en.wikipedia.org/favicon.ico Dragons flight (talk) 19:08, 17 May 2008 (UTC)
          • I know -- that's not stored on the wiki in image space though. Also I downloaded that and can't see anything but the 16 pixel version, at least not using the Windows icon choosing dialog. Equazcion •✗/C • 19:12, 17 May 2008 (UTC)
            • It's possible that 16x16 is all that has ever been created (it is certainly the most widely used size). Dragons flight (talk) 19:14, 17 May 2008 (UTC)
              • Well since there's currently no 32x32 version, just a single 16x16 version, we can just worry about replacing that one for now. Equazcion •✗/C • 21:04, 17 May 2008 (UTC)
• I can think of one problem with the new version: if the user have configured his OS to have a dark color (e.g. the tabs are black) then the favicon would be invisible or at least hard to see. The vast majority probably don't and it's not a serious issue (in my opinion), but optimally the favicon should display nicely on all backgrounds.
  — Apis (talk) 15:24, 20 May 2008 (UTC)

As regards licensing: {{PD-font}} (it's just a "W" for goodness sakes) + {{trademark}}. Dragons flight (talk) 18:57, 17 May 2008 (UTC)

• • Since nobody spoke against this, and its just a graphical improvement that I don't think will be controversial maybe a bugzilla report can be made? Is anybody opposed to going ahead with it? Acer (talk) 23:35, 20 May 2008 (UTC)

I think this is a great improvement! It's been bugging me for a while now as well. But I had a different design in mind, if no one don't objects, and since Wiktionary has the same 'W' as us. How does this look?

Besides, this is more descriptive than just a W; much more symbolic and recognizable. -- penubag  (talk) 01:56, 21 May 2008 (UTC)

<-- Live preview, using Image:Wiki letter w.svg. Looks a bit messy and indistinguishable at favicon resolution, especially against a grey background. MER-C 06:49, 21 May 2008 (UTC)

Yes, the svg version above does look messy, which is why I created a different version, which can be seen in the screen shot. -- penubag  (talk) 16:31, 21 May 2008 (UTC)

Yes I was also thinking of using a "puzzle pice", looks good on the screenshot, and it solves the problem I mentioned above.
— Apis (talk) 14:53, 21 May 2008 (UTC)

Yep, I like the puzzle on the screenshot too. Looks nice Acer (talk) 19:12, 21 May 2008 (UTC)

• Well, is the silence an expression of utter indifference or something else? Maybe we could get a bugzilla report for this change, unless someone is against? It solves any problem I can think of at least, and goes well with the main puzzle globe logo.
  — Apis (talk) 00:40, 26 May 2008 (UTC)

No, I don't like the puzzle piece. I prefer just the W. Reywas92^Talk 16:22, 26 May 2008 (UTC)

Inquiry I kind of like the proposal for a transparent "W" but I think Apis raised a valid point about the black styles. I also like his puzzle piece idea equally (that also solves the black style problem) but I think the "W" isn't big or distinct enough in the sample version shown above. In any case, transparency support for the favicon for many browsers and past versions of browsers should be investigated. If any older browser still with a sizable market share (what is sizable? 0.2%? 0.5?) renders a favicon with transparency poorly this motion should be reconsidered. Jason Quinn (talk) 00:10, 1 June 2008 (UTC)
Again there's silence in the conversation, has someone bugzilla'd this? ☯Ferdia O'Brien ^(T)/_(C) 12:11, 4 June 2008 (UTC)

Nope no one has filed a bugzilla yet. If and when, I'll provide the puzzle piece image, if that's consensus. -- penubag  (talk) 00:27, 5 June 2008 (UTC)

I like the puzzle piece, but I think I like the W better unless the symbol on the piece can be made larger (I can't make it out on the "live preview"). Perhaps a white outline could be added to the W, that would solve the dark-background issue while still looking better than the white square. --_{tiny plastic} Grey Knight ⊖ 06:52, 5 June 2008 (UTC)

Finally, the favicon could become transparent! On that note, I prefer the W. While the puzzle piece looks nice, I think the W conveys more simplicity; plus, many visitors to Wikipedia are already familiar with the W. Kal ^(talk) 11:15, 7 June 2008 (UTC)

Move the search box directly beneath the puzzle globe

This is a follow-up to Wikipedia:Village pump (technical)#change the SEARCH field input box, please (permanent link).

Currently the search box, the first thing that our users want to use, is about 3/4 of the way down the screen, after the lists of "navigation" and "interaction" links. This can make it hard to find for new and elderly users.

I propose that we move the search box directly beneath the puzzle globe, like so:

You can try this out in your own browser by adding

addOnloadHook(function() {
    document.getElementById("column-one").insertBefore(document.getElementById("p-search"), document.getElementById("p-cactions"))
})

to your monobook.js. You can also type

javascript:void(document.getElementById("column-one").insertBefore(document.getElementById("p-search"), document.getElementById("p-cactions")))

into your browser's URL bar and press "Go" to see how just one page would look with the new layout.

If there is consensus to make this change, then I'm sure the developers can just tweak the search box's location by default, eliminating the need for JavaScript.

So, what do you think? —Remember the dot ^(talk) 03:28, 21 May 2008 (UTC)

• I like the idea of having the search box higher up the page, but this version seems to almost blend into the logo to me. Perhaps if a thicker line separates the globe from the search box? Johntex\^talk 04:01, 21 May 2008 (UTC)
• It could easily be added as a Gadget if people want it, I mean it's hardly a lot of code to implement. Oh, and yes, I like the idea. RichardΩ612 Ɣ ɸ 06:02, May 21, 2008 (UTC)
• Support new visitors to the Wikipedia are likely to be here to find things out. Having the search box as proposed makes this easier for them so to do. DuncanHill (talk) 09:28, 21 May 2008 (UTC)
• Oppose - I think it looks nicer the way it is; it's still not hard, and Google will direct most people to the right page anyway! —TreasuryTag—t—c 09:38, 21 May 2008 (UTC)
• support. It should be made more obvious than in the sample; ease of use is more important than aesthetics (ask Jakob Nielsen, he knows). While most people enter Wikipedia via search engines (including me!) and most find related articles via wikilinks, we should be encouraging visitors to search for other info that's of interest to them - either unconnected or connected in ways that were not foreseen by editors. Philcha (talk) 10:08, 21 May 2008 (UTC)
  • The point is to combine aesthetics and usability, not to go too far towards one thing on the expense of the other. And for people who do not enter through search engines, we should have a truly prominent search box on the Main Page. From that point on, it won't be hard for them to find their way around. Waltham, The Duke of 01:37, 25 May 2008 (UTC)
• Comment what about putting it between the "navigation" links and the "interaction" links? I do think it needs to be higher (people shouldn't have to scroll for it) but it does look a bit wierd right underneath the globe. What's the javascript for that? And there's no need to bug the devs for a change like this - if we gain consensus, just add the relevant code to Mediawiki:Common.js. Happy‑melon 11:04, 21 May 2008 (UTC)
  • Comment - I've corrected the proposal to make clear that developers don't need to be involved in making this change. —Preceding unsigned comment added by John Broughton (talk • contribs) 11:56, 21 May 2008 (UTC)
    • JavaScript is not the right tool for every task. It will work, and it's a good first step, but page loading would be more smooth and less prone to bugs if the change were made directly. —Remember the dot ^(talk) 14:29, 21 May 2008 (UTC)
  • Comment. I like Happy-melon's suggestion of moving it between "navigation" and "interaction" - that would fix my issue whereby I have very small screen (I've already pointed this out posting from a different IP) because it would then be visible without scrolling. But thinking further about this, why are links like "Featured content", "Current events" and "Random article" so high up? I don't believe these are central to most consumers of this encyclopaedia who generally are looking for information on something specific.--82.148.54.183 (talk) 18:05, 26 May 2008 (UTC)
• Support. The location of the search box should be optimized for readers; there are more than a thousand page views (by readers) for every edit that is done. The location may not be that important if a reader comes to a specific article via (say) Google, but it's hugely important when reader starts at the main page - and millions do so every day. Take a look at how Encyclopedia Britanica does it - search box right at the top. I don't think editors will have any problems adjusting - there was a major reorganization a couple of years ago without many complaints, I think. But for experiencd editors who like the old location, just create a gadget so that they can put the search box back where they prefer it. -- John Broughton (♫♫) 11:56, 21 May 2008 (UTC)
  • The analogy is an unfortunate one, I am afraid. Even if we do move the search box to the top, it will hardly be any more visible than it is now, given that we do not drastically change its formatting. Britannica's search box is incorporated in the masthead, or whatever it is called, which is always at the top—we have a sidebar, which occupies the left edge of the screen. Completely different vehicles for the display of important links. Furthermore, it is white on a blue background; our colours are much more subdued. In other words, it is clearly more conspicuous than our search box will ever be. And it probably needs to be, because there are visibly fewer ways to browse Britannica than Wikipedia. In any event, these are two very different examples. Adopting anything similar to Britannica's format would entail a radical change of Wikipedia's layout. And the current one works much better for the requirements it needs to meet. Waltham, The Duke of 23:02, 22 May 2008 (UTC)
    • Comment Citizendium has its search box right at the top - see here. Note that Citizendium, unlike Britannica, is a wiki-based encyclopaedia with similar features to Wikipedia.--86.145.248.219 (talk) 14:39, 25 May 2008 (UTC)
      • That's a better example. However, given the difference of the two sites' page layouts, especially with the tabs we have above each page, I am not quite sure that it would work well here. Waltham, The Duke of 02:11, 26 May 2008 (UTC)
• Oppose I think the search provided by Wikipedia is kinda useless. I don't use the search box. -- Taku (talk) 12:09, 21 May 2008 (UTC)
  • Comment: Are you saying that you think the Wikipedia search box should be less obvious so readers are less likely to find it and use it? -- John Broughton (♫♫) 16:36, 21 May 2008 (UTC)
  • Comment: Just because you don't use the search isn't a very good reason to oppose. If you don't use the search that moving it won't affect you. Many others do use it. You have to consider them. Jason Quinn (talk) 23:30, 31 May 2008 (UTC)
• Support The search box is THE most important thing of the sidebar and it makes every sense in the world (to me) to have it on the very top. John Broughton's arguments are spot on. Pax:Vobiscum (talk) 12:56, 21 May 2008 (UTC)
• Support I definitely like it better up there, and John's suggestion is a good one. J.delanoy^gabs_adds 13:27, 21 May 2008 (UTC)
• Support I like it better up there because it makes it easier to navigate by lists and headings with screen readers. To get to the categories of a page, I can just hit up arrow twice from the search heading and to get to the Article/Discussion/Edit tabs, I can just hit "l" to navigate to the next list from the search heading. With the old positioning, I sometimes had trouble finding my way around. I know about the hidden "Views" heading, but that doesn't work in my version of JAWS. Graham87 14:11, 21 May 2008 (UTC)
  • One-size-fits-all solutions always have problems, especially with the modern variety in monitor sizes. Some people say the search box is too low now; taking it to the top will have other problems, however, especially for people with bigger screens. Surely there isn't the ability to adapt the main page to various gadgets? The demands of different users often seem irreconcilable. Waltham, The Duke of 01:37, 25 May 2008 (UTC)
• Hmmm... I think I'm with User:Happy-melon. What about between the "navigation" and "interaction" boxes? Or altering the color of the box from white to a slight padtel or something to make it stand out more where it is? Mahalo. --Ali'i 14:29, 21 May 2008 (UTC)
• Oppose Too much white space clumped together. It looks better the way it is now. _{1 != 2} 14:34, 21 May 2008 (UTC)
• Oppose as a site-wide JavaScript hack. If you want it changed, please change it in MediaWiki. Gracenotes^T § 14:57, 21 May 2008 (UTC)

I thought that's what the proposal is for. To tweek MediaWiki so that the javascript workaround can be avoided. Missing something am I? --Ali'i 15:01, 21 May 2008 (UTC)

Ah, must have missed that paragraph (doesn't look like you missed anything, no); struck. No opinion on the GUI change, but implemented as a change in the monobook skin, there shouldn't a problem. Gracenotes^T § 15:18, 21 May 2008 (UTC)

Well, I wasn't 100% sure myself, so I figured I could have been totally wrong. :-) Mahalo. --Ali'i 15:26, 21 May 2008 (UTC)

• Support. Seems a lot more intuitive to me. Kaldari (talk) 16:02, 21 May 2008 (UTC)
• Oppose – the Main Page is a content page, not a search page. If we were to make it into a search page we'd include code like the below example, rather than making an ugly change to the interface. Nihiltres^{t.l} 16:30, 21 May 2008 (UTC)

• • Comment - This is a proposal to move the search box up to the top of the left margin on every page - the example above is simply an example. Moving the search box to where it is more visible doesn't change the nature of the Main Page; it's not a search page. The search box has to go somewhere - this question is simply about WHERE that somewhere is. -- John Broughton (♫♫) 16:36, 21 May 2008 (UTC)
    • I believe that Wikipedians could find a way to integrate a search box in the Main Page's top, where it would be most useful, without compromising aesthetics; it is certainly better than changing the appearance of a few million pages. Waltham, The Duke of 01:37, 25 May 2008 (UTC)
• Comment and background. See Wikipedia:Village pump (proposals)/Sidebar redesign for the previously proposed idea, of having the search box between the "navigation" and "interaction" boxes (which we all liked, but it appeared to be technically difficult to accomplish). I'd support that as the ideal, if it's possible.
  Otherwise, I'd support Oppose this proposal to move it to the top of the stack, per Waltham and Evula, plus our search results are still quite abysmal. -- Quiddity (talk) 18:13, 21 May 2008 (UTC)
• Support. I like it better this way, myself. It makes more sense, considering that Wikipedia is a searchable encyclopedia above everything else. Celarnor ^{Talk to me} 22:21, 21 May 2008 (UTC)
• Support. And in addition, perhaps make the word "Search" bigger and bolder. --207.176.159.90 (talk) 23:54, 21 May 2008 (UTC)
  • Comment There's no point to the word "search". Just get rid of it. There's already a button that says "Search". Less cluster is actually makes things easier for newbies. Jason Quinn (talk) 23:30, 31 May 2008 (UTC)
• Totally support this, to make it easier for new users to find their way around Alex Muller 06:00, 22 May 2008 (UTC)
• Oppose on the following grounds:
  • It would be rather distracting, being placed exactly next to the beginning of text in articles (I don't think the screenshot above is so representative, if this change is to take place in all pages). Its current position, on the other hand, is well into the body of articles, and therefore more distinct than the non-sidebar part of the page.
  • I consider the proposed place of the search box too high, forcing my eyes go almost to the top of the page for every single search. Furthermore, it does not give me the ability to change that, in contrast to the current position, which is easily adjustable in most pages by scrolling. I'd also like to note that, although the current position rarely ever requires scrolling to reach the box from the page's top, it requires less scrolling from the bottom than the proposed position.
  • The search bar is rather distinguishing as it is; while the rest of the sidebar is a long bulleted list, the search box has a long box and two large buttons below it. I believe it strikes a perfect balance between being visible and not distracting a viewer's attention. The sidebar should be discreet; if one needs it, one can look at it then.
  • The search box's being above the sidebar's first two boxes would make it look as if it is more important than the links in these boxes, which is not necessarily true. The first box contains standard ways of browsing, important to, and useful for, a great part of our readership. The second one includes pages of extreme importance, including the "About", contact, and donation pages and the Community Portal; the first two are of particular significance to non-editors.
  • The current location of the search box divides the sidebar into two parts, of arguably different importance and usage. The first two boxes are important to all Wikipedia users; the toolbox is only used by editors, and the languages box is a varying factor.
  • Finally, per 1 != 2. I don't like the aesthetic side of the proposal. (And don't you dare focus on this argument... :-D) Waltham, The Duke of 06:24, 22 May 2008 (UTC)
• Support. A very sensible idea, in line with navigation principles used on other web sites. And, replying to Nihiltres, if the main page isn't a "search" page as well as a "content" page, I wonder what is a search page? That's a rather overwrought statement—it's obviously both. –Outriggr § 10:33, 22 May 2008 (UTC)

  I would suggest Special:Search and Google as good examples. Nihiltres^{t.l} 14:29, 22 May 2008 (UTC)

• Support. As I suspect that it will make life easier for readers who are not used to the site. CambridgeBayWeather Have a gorilla 14:25, 22 May 2008 (UTC)
• Oppose Its current location is just fine; if a user is so easily confused that they can't figure it out, moving the box up won't help (and it's already above the threshold, so even on a small screen, it's visible). Moving it clumps all the other sections (Navigation, Interaction, Toolbox, Languages) together; having the search box in the middle helps to make the sidebar more visually distinctive. I think it would be perfect for a gadget, though. EVula // talk // ☯ // 14:42, 22 May 2008 (UTC)
• Oppose. I'm going to have go with the opposers on this; they've convinced me. Navigation and Interaction are just as important as the search bar, and its current location is, I think, more noticeable and distinctive than it would be up by the logo. To me, it's part of what makes the default Wikipedia skin look like Wikipedia. Powers ^T 18:27, 22 May 2008 (UTC)
• Support I've been trying out the new format and it's better all around. It looks better and it's more logically placed. And as was mentioned in other comment, it's important for mobile devices to have it higher. Jason Quinn (talk) 23:30, 31 May 2008 (UTC)

• Expand the discussion

Personally I prefer the current position because it's near the photo of the Feature Article, but try the other if you like. The real problem is that the Main Page is too long and needs to be edited down. This is a very tricky operation because everyone will have their favorite links! But the way it is I don't even remember to look at the Featured Picture most of the time, for example. There are three sections for other languages - the "Local embassy" link, the list of numbers of articles in other languages at bottom, and the sidebar with other languages. (By the way, I think that we should find a way to trim crazy languages like Volapuk from the main list; I know it has 100,000+ articles listed, but there should be some way to trim the list based on the number of articles and the number of actual readers; also Chinese should be at the top of the list rather than the bottom)

The problem is, we need a way to begin meaningful editing. There has to be some way for alternate Main Page versions to compete against one another in a very widespread test of approval. For example, if people could set a "Wikipedia home page" in their preferences, then different people, once logged in, could see different Main Pages, sometimes using portals or Wikiprojects, sometimes using an alternate development version of the main page. The statistics would start to prefer specific development versions that could be subjected to a Wiki-wide vote of approval or a test for a day. Wnt (talk) 15:51, 22 May 2008 (UTC)

This thread is about the Sidebar, not the Main Page. However, See Wikipedia:Main Page alternatives for Main Page variants, and the js code to make them your default. -- Quiddity (talk) 18:26, 22 May 2008 (UTC)

Thanks for pointing these out. Still, I think most users will bail out the moment they see ".js", without further consideration. Also, is there any way to gather statistics about how many use each version? Wnt (talk) 16:44, 23 May 2008 (UTC)

See http://stats.grok.se/ eg [8]. -- Quiddity (talk) 17:52, 23 May 2008 (UTC)

Hey, that's a handy tool - thanks! I guess no special method of collecting stats is needed then, though differences in the number of reloads between users could skew the results somewhat. Wnt (talk) 14:09, 26 May 2008 (UTC)

• Oppose—Silliest idea in a long time. Its current position allow you to access it both initially and having scrolled down further.TONY (talk) 02:18, 23 May 2008 (UTC)
  • I dunno...most of the time when I'm reading along in an article, I have to scroll up to get back to the search box anyway.
    • That depends on the length of an article; not all articles are (much) longer than one page. Waltham, The Duke of 01:37, 25 May 2008 (UTC)
  • We could also make the search box more prominent by adding it to the main page like the Commons does (although they hide the "Go" button and just leave the "Search" button). Would that be better? —Remember the dot ^(talk) 03:20, 23 May 2008 (UTC)
  • Comment That argument only works for a very specific article size. In fact, it fails for long articles (which are numerous) because you can always quickly drag the scroll bar all the way up and know that you'll see the search box; whereas with it in the middle on low-resolution display you may actually have to go down a page. Jason Quinn (talk) 23:30, 31 May 2008 (UTC)
• Support, as we have actually gotten complaints about it's current position (see the link at the top of the thread). You really have to look at the sidebar as a casual visitor does and realize that they're blind to it and many of its links because it looks similar to and is positioned similarly to contextual ads on other sites. I do recall seeing studies where people were asked to find something on a government website and almost everyone completely ignored a link to exactly what they were told to look for because it looked like an ad- logic doesn't even enter into it, there aren't ads on government sites. Putting it directly under the puzzle globe will make it much easier to find for new visitors- people look at logos because they're usually navigational aids. I'd also advise bolding the word "search" above the box to make it a tad more prominent. I don't like the way the searchbox on Common's main page is set up- it looks just horrible to me. That's my two pennies anyway. —Ashanda (talk) 01:04, 24 May 2008 (UTC)
  • Bolding search would not help because the Wikipedia logo has large, bold lettering anyway. Basically, all it takes for a user to know where the search box is is to find it once; and if there is a prominent box on the Main Page then they will know that there is searching capability, so that they will look for it on other pages even if they cannot find it straight away. And where will they look but in the sidebar? As long as they think to look at the sidebar, they will see it right away—within the sidebar the search box is rather distinctive. I agree that the Commons solution is rather ugly, but we don't have to do it this way. I am thinking of a page-wide narrow bar below the top box, which would be useful without disrupting the page's layout or ruining its appearance. Waltham, The Duke of 01:37, 25 May 2008 (UTC)
  • Comment No just get rid of the world search... it's redundant as the button already says it. Jason Quinn (talk) 23:30, 31 May 2008 (UTC)
• Support - The first thing most people want to do when they visit is search, so it makes sense to have the search box closer to the top. – FISDOF9 04:40, 24 May 2008 (UTC)
• Comment (I actually support this, but don't want make it appear I'm voting as I don't my opinion to get rejected as I'm an anon.) An important point is that an increasing number of users like me use small-sized screens (800x480 on my Asus Eee PC) and cannot currently see the search box without scrolling.--82.148.54.195 (talk) 12:43, 24 May 2008 (UTC)
• Support anything that helps searching. I would die to see the search box in the header next to "Welcome to Wikipedia" in place of the portals (like Portal:Art, Biography, etc...) Renata (talk) 21:44, 24 May 2008 (UTC)
  • That I would support (seeing Renata dead would not be bad, either). However, I do not want to see the portals replaced, but the inclusion of the search bar would certainly help; a long, narrow bar with bold wording below the top box would not affect the Main Page's layout and formatting much. See comment a few bullets below. Waltham, The Duke of 01:37, 25 May 2008 (UTC)
• Support - The two main activities on Wikipedia are "searching and browsing". It makes sense that those should go at the top where they are most noticable. Searching followed by navigating (browsing) is fine. The Transhumanist    22:37, 24 May 2008 (UTC)
  • As I say below and have said again, the top of the sidebar is not that much different than any other place in the sidebar, and moving the search box has more consequences than a simple re-arrangement; it changes its entire appearance and the way people look at it. The top of the Main Page, however, is much more prominent, and really is the first place one will look at on that page—which is dubious for the sidebar. Waltham, The Duke of 01:37, 25 May 2008 (UTC)
  • I disagree that the search box is more noticeable below the logo. I would (and did) in fact argue that it's more noticeable where it is now, than up by the logo. As it is now, the user's casual glance sees "round thing, block of text, interruption to the block of text, block of text" along the left sidebar. I fear that with the edit box moved up, it would blend in to the logo on a casual glance or in peripheral vision. Having it interrupt the "block of text" makes it stand out more. Powers ^T 13:49, 25 May 2008 (UTC)
    • In practice, however, new users don't even actually "perceive" the side bar's table of links because to them it looks like a series of contextual ads (white boxes with text in them) and is ignored because of banner blindness. I've had n00bs email me to ask how to do something linked to from the sidebar, and I've had to give them specific directions, including landmarks and how many links to count down to find what they're looking for. Putting the search box between the "white boxes" and the logo will definitely make it more visible to newcomers. —Ashanda (talk) 14:20, 25 May 2008 (UTC)
      • I don't know about "definitely" -- I understand the banner blindness, but I think it's precisely the current position of the search bar that serves to break that up. Moving it could exacerbate the problem rather than alleviate it. Powers ^T 14:50, 25 May 2008 (UTC)
      • Indeed; it is not at all assured that it will draw more attention to the sidebar. Nor is it assured that people read web pages like book pages in a very rational sequence from the top to the bottom. They focus on images, large headings, and otherwise distinctive features, like those breaking patterns (and that includes the search box). The logo is right in the corner; even if people look at it, they might as well ignore the search box even if it is right below, as it will be lost next to the big, bold Wikipedia. And then the sidebar will not be in the least noticeable, because it will just be a long and largely featureless column of links. Waltham, The Duke of 02:11, 26 May 2008 (UTC)
• Support This will more closely match user expectations. Essentially every site on earth does it at the top, though the top right corner is perhaps the most usual. In fact I think doing it up there, right above the page tabs might be the very best. DGG (talk) 00:22, 25 May 2008 (UTC)
  • This is what I propose, albeit only for the Main Page (which is the most important one anyway). Waltham, The Duke of 01:37, 25 May 2008 (UTC)
• Comment – If it is so important so help people find how to search in Wikipedia, then why not just have a search box on the Main Page—the main portal of entrance to Wikipedia—much more prominent than it would be anywhere in the sidebar, including the top? Renata's idea is splendid, and is in line with the otherwise completely irrelevant references to the layout of the Commons main page. For all other pages it does not matter so much, as people either know how to search in order to have found these pages, or have gone there from Google or other search engines. Personally, I prefer the status quo, but if there really is a problem, then this is the way to go, without ruining the grouping of the sidebar boxes or the balance of the search box's neither too high nor too low. Waltham, The Duke of 01:37, 25 May 2008 (UTC)
  • So, where on the main page would you put the search box? —Remember the dot ^(talk) 01:57, 25 May 2008 (UTC)
    • I am thinking of a one-line page-wide box just below the top box ("Welcome to Wikipedia", portal links, etc.). Too narrow to affect the page much, but it would still be noticed due to its prominent position, and perhaps slightly different colouring. (I have yet to decide if the box would be better above or below the "Overview", "Contents" and other links, but I think below would be better.) It would say "Search Wikipedia" on the left, with bold letters of medium size, and a long search box would be on that phrase's right; on the far right there would be the "Go" and "Search" buttons, or some differences might exist there. The details are open to discussion, but this is the general idea. A prominent box on the most important page, without adversely affecting either that page or the sidebar. Waltham, The Duke of 03:33, 25 May 2008 (UTC)
      • Well, one of the reasons why I'm hesitant to add a search box to the main page is because that would mean there would be two search boxes on the main page, a prominent one on the top and the regular one in the sidebar. It seems rather unprofessional...wouldn't it be more consistent and easier to find if the search box was in an easy-to-find place on every page? —Remember the dot ^(talk) 03:38, 25 May 2008 (UTC)
        • There would be two search boxes; although I do not generally like redundancy, I do not find this much of a problem—especially if we incorporate some sort of extra feature into the top search box which would make it more "special". The main points are two: one, I seriously doubt that a top position in the sidebar would make the search box much more visible (if one looks at the sidebar, one can easily locate the search box—this really is a matter of drawing more attention to the sidebar), and two, in the current position the search box acts like an anchor for the sidebar, splitting it into two well-defined parts, of which the first is always identical while the second is subject to changes. If we were to move the box to the top, we'd have all the other components of the sidebar lumped together, a grey mass with no distinguishing features; the whole thing would look like a long, fading line, instead of the current solid format. And, of course, there are the other arguments I have put forth in my main oppose (scrolling, semantics, etc.). Waltham, The Duke of 05:15, 25 May 2008 (UTC)
        • Update – There is redundancy elsewhere in the Main Page: out of the eight links below the top box, mostly linking to general information and browsing methods, four are already in the sidebar. I don't think redundancy should be considered so seriously for the main page.
          • What I don't like about this idea is that it may very well end up hindering navigation by new readers because they'll never notice the search box on every single page and will think they have to return to the main page every time they want to search. Besides, even the smallest changes to the main page seem to involve a lot of drama even after it seemed consensus had been reached. —Ashanda (talk) 14:20, 25 May 2008 (UTC)
            • That is exactly the reason we didn't implement this suggestion during the Main Page redesign. See specifically Wikipedia talk:WikiProject Usability/Main Page/Draft/Search box poll, plus many discussion threads.
              However, If you'd like to experiment with a new example, try fixing up Wikipedia:Main Page alternative (Search Box) (perhaps using elements from Wikipedia:WikiProject Usability/Main Page/Draft extra search box2). Hope that helps. -- Quiddity (talk) 20:42, 25 May 2008 (UTC)
              • Ashanda, we could give a link to the help page about searching in that bar, explaining the whole process. Many readers seem to be at a loss regarding how searching works in Wikipedia, even if they have located the box. Which, by the way, you make it sound quite difficult. The sidebar is one of the very few things that don't change from page to page; people are bound to notice that at some point. About the drama... If the arguments are compelling enough, they should prevail. Why should the Main Page be so much harder to change than an element appearing in every single page? Anyway, I now look at the poll, and see that the main arguments are:
                1. "It distracts from the sidebar box" (which would indicate that people notice it).
                2. "it makes searching look too important" (these could be used against any attempt to make the search box more conspicuous).
                3. "It disturbs the layout of the main page" (that only relates to the specific proposal).
                4. "Redundant", "it will make people think there is something special about one box over the other"
                5. "It confuses readers because it disappears on the next page"
              • The two last bullets contain the most compelling arguments, I believe. However, it must be noted that from the 116 supports for the extra box, only one mentioned moving the sidebar one up, and from the 131 opposes, again there was only one such suggestion. Apart from that, the comments seem directed towards making the box more prominent. That I am willing to support (depending, of course, on the means), but moving the box up would simply ruin the sidebar. Waltham, The Duke of 02:11, 26 May 2008 (UTC)
• Support, the most important navigation element (or should I say browsing element...) should be where new users actually find it (currently, it is easy to miss it in that jungle of small links). I further suggest to remove the 'search' heading above the search form, it is redundant to the 'search' button and it looks much, much better without. Cacycle (talk) 01:06, 26 May 2008 (UTC)

The search box is completely different from the "small links" (for one thing, it is sidebar-wide and has no blue at all), and a distinctive break in the sidebar's pattern; how can it be missed? And what makes the proposed spot "where new users actually find it"? In all honesty, I'd like to know where that comes from. In any case, the "search" heading, apart from ensuring consistency, actually helps setting the search box better apart, giving it more space. I am not so sure about its not being useful at the top, either; a box with no heading at all and just two buttons below would look downright strange, even below the logo. Waltham, The Duke of 02:11, 26 May 2008 (UTC)

Exactly because the "search box is completely different from the "small links"" the box should not be intermingled with those (for a new user more or less irrelevant) links. And for me it seems quite obvious from what I have read about usability that the place under the logo is the most prominent place to get the user's attention while any element hidden in small text and link lists at a visually non-prominent place will almost certainly be missed by a new visitor. Cacycle (talk) 03:14, 27 May 2008 (UTC)

How could you call it "intermingled" when the links are organised in boxes and separated from each other? And even if you don't believe that a box breaking a repeating pattern is more eye-catching than another lost in the shadow of the logo, do you really believe that the search box's move would not have detrimental effects on the appearance of the rest of the sidebar by accentuating this repetition and making the sidebar draw even less attention? I maintain that the move, although perhaps producing a small gain for the search box, would negatively affect the entire sidebar's layout and through it that of every single page in Wikipedia. Is it really worth it? And that small gain could be made much more painlessly by colouring the search box, as suggested by Quiddity below. Not anything loud... Just enough to be noticed, better guaranteed than dubiously beneficial moves. Waltham, The Duke of 19:37, 27 May 2008 (UTC)

• Oppose or Conditional support. I am use to where it is now. I'd rather it not be changed, but if it is there should be an option in Preferences to put it back. Reywas92^Talk 16:33, 26 May 2008 (UTC)
  • A gadget would be made available for experienced users who are accustomed to the old positioning. —Remember the dot ^(talk) 16:41, 26 May 2008 (UTC)
    • And I intend to use it if this passes. However, I've heard somewhere that it would delay downloading. Is that true? Waltham, The Duke of 00:26, 27 May 2008 (UTC)

Not true :-) Cacycle (talk) 03:14, 27 May 2008 (UTC)

• Oppose I prefer how it is now. - • The Giant Puffin • 21:52, 26 May 2008 (UTC)

I think the main point is less about how any of us likes it better, it is about how we can make life easier for new visitors. Cacycle (talk) 03:14, 27 May 2008 (UTC)

• Neutral I'm happy with the search box where it is, but I don't really care. I do care that the location of the search box be consistent on all Wikimedia wikis because I am active elsewhere and I depend on a comfort level with the interface in foreign languages. I don't think it's worthwhile to change the interface on a thousand different wikis, so my suggestion is: don't bother changing anything. Shalom (Hello • Peace) 03:41, 27 May 2008 (UTC)
• Weak Oppose - I'd normally strongly support this, as it conforms better to general web interaction conventions (familiarity being a large part of usability) and because it's very helpful for a user seeking info on a specific topic. On the other hand, the current search is fairly useless unless you know exactly the right term to search for; and worse, can be very confusing to people who use "go" instead of "search".
• Support Sounds good to me. Why anyone would oppose such a minor and trivial change is beyond me,... Dr. Cash (talk) 00:17, 28 May 2008 (UTC)
  • The upper left part of the screen, from the logo to the "toolbox" label, is (perhaps along with the "book" background) the only part of the interface that does not change in the slightest degree in any of Wikipedia's several million pages. It is the one constant element that acts as a connecting thread between the most diverse of pages, and which everybody recognises and often uses. Even the slightest change to that part would, and should, be subject to discussion. That said, this is certainly not a trivial change, considering that it would affect (very negatively, in my opinion) the appearance of the entire sidebar, as well as the searching experience of readers and editors alike. A move would entail consequences which would not be trivial. Waltham, The Duke of 20:27, 28 May 2008 (UTC)
• Support - would make life much easier for visitors and editors alike, and it's easy to implement. I don't think "I'm used to where it is" is a good reason to oppose - we'd soon all get used to the new position. Waggers (talk) 09:55, 29 May 2008 (UTC)
• Support. It's an excellent idea: the whole layout feels more consistent, and the search box is easier to access. -- The Anome (talk) 23:58, 29 May 2008 (UTC)
  • Would you mind elaborating, please? I did not understand the comment on consistency. Waltham, The Duke of 15:41, 30 May 2008 (UTC)
• Comment – Does any one know why when I hit Save without having previewed first I am taken to a search page? (For the record, I use wikEd's previewing tool.) It only happens in this thread. Waltham, The Duke of 15:41, 30 May 2008 (UTC)
• Support. As an ordinary user and only occasional contributor, I've been annoyed by the current placement for a very long time. As the proposer says, it's the first thing people want to use but is currently hidden away and a real nuisance if you're accessing wikipedia from a mobile device. Saluton (talk) 21:15, 30 May 2008 (UTC)
• Support. This is a request I heard many times in conferences and from regular users with a laptop. They hate scrolling up and down each time they need to do a search. Anthere (talk) 10:09, 1 June 2008 (UTC)
  • I don't see how this proposal helps them; they'll have to scroll up even more often if the search bar is moved up. Powers ^T 22:24, 1 June 2008 (UTC)
    • This is going to lead to some one suggesting the box move with the page. Rgoodermote  00:54, 2 June 2008 (UTC)
• Support All it is a simple move. Not only that it helps out those who have problems with finding the bar..and I have seen people struggle to find the bar. Rgoodermote  00:54, 2 June 2008 (UTC)
  • I don't see how this proposal helps. Do you have evidence that the search bar is easier to find if it's underneath the logo? Subjectively, it appears to me that it's less noticeable there. Powers ^T 12:13, 2 June 2008 (UTC)
• Oppose Per Powers and The duke of Waltham. Keep it the way it is. Or change it. But either way it should be an option in preferences. FelisLeo^Talk! 11:48, 3 June 2008 (UTC)
• Comment I think that moving it to the top is better than where it is now, however I think that an better place is at the bottom of the navigation navigation like it was way back in proposal 15. Is this possible to do? If so I'd greatly apprciate if somebody could give me the code to put in my personal monobook.js page Redekopmark (talk) 22:00, 3 June 2008 (UTC)
• Weak Oppose I think this is a solution looking for a problem. There's nothing wrong with the search bar being 100 pixels too low. If it ain't broke, don't fix it. Paragon12321 (talk) 03:00, 4 June 2008 (UTC)
• Neutral As long as there's a gadget to move it back, I'm happy either way. shoy 13:17, 4 June 2008 (UTC)
• Support As a reference desk monitor, it is clear to me that users need to be encouraged to search for the answer to their question on Wikipedia. In many cases, we already have an article that answers their question directly. ike9898 (talk) 14:44, 4 June 2008 (UTC)
• Support - Seems like a good and logical idea. Scarian^{Call me Pat!} 15:05, 4 June 2008 (UTC)
• Oppose I don't see why it needs to be moved. I've never actually heard anyone complain that they couldn't find it before and so I'm not sure that there is really a need to make the change. Also, to my eyes it appears to clash with the Wikipedia logo at the top rb000 —Preceding unsigned comment added by Rb000 (talk • contribs) 05:01, 5 June 2008 (UTC)
• Comment What about inbetween the Navigation and Interaction boxes, if you want to see how it looks you can see what it looks like by adding

addOnloadHook(function() {
    document.getElementById("column-one").insertBefore(document.getElementById("p-search"), document.getElementById("p-interaction"))
})

to your monobook.js Redekopmark (talk) 05:39, 5 June 2008 (UTC)

• Comment Between the navigation and interaction boxes would be fine with me. Also, a thick line or some other form of separation between the logo and the search bar would alleviate my concern. I still think the case for moving would be much stronger if anyone could provide a concrete example of how its current location has actually confused anyone Rb000 (talk) —Preceding comment was added at 23:17, 5 June 2008 (UTC)
• Support The new location looks nicer to me. Also, I have been asked by new users how to search wikipedia because they did not see the search box. The change makes it more visable.--Banana (talk) 00:15, 6 June 2008 (UTC)
• Support - The search box is easily the most used feature on Wikipedia. Almost everything else on the left side of the page is gobbledygook to non-editors. It's used much more than, for example, "current events" or "community portal" which are currently above the search box. --D. Monack | talk 05:42, 6 June 2008 (UTC)
• Support. --Wikinaut (talk) 13:13, 6 June 2008 (UTC)
• Oppose per EVula and LtPowers above. Like they said, the search box provides a clear distinction between the nav/interact boxes, which may be used by anyone, and the toolbox, which is mainly used by editors. Without the search box in its current position, this distinction would be lost and it would be more difficult to find a particular link. The search box is fine in its current position and does not require scrolling to locate, except for those who use lower-resolution displays. Kal ^(talk) 22:04, 6 June 2008 (UTC)
• Support- I can navigate the boxes OK and it's irritating to have to scroll down to reach the often-used Search box. -- SEWilco (talk) 17:01, 7 June 2008 (UTC)
• I am neutral regarding the location of the box, but would be against any proposal to have two of them on the main page (the current one in the left sidebar plus a new one for the main page only).

Two related proposals

Feel free to refactor/move these 2 comments into new threads/pages etc. I won't have much time this week, and just wanted to get them mentioned. -- Quiddity (talk) 21:25, 25 May 2008 (UTC)

• Change the search box button text - Proposed as part of the sidebar redesign, but postponed to avoid overloading the redesign with too many changes at once. (It should be re-raised sometime, and now seems appropriate.) The most favored option was changing "Go" to "Titles", and changing "Search" to "All text" - this is both more accurate and more informative than the current labels. Example above. (The "Titles" button should/will be bolded when in actual use (just like "Go" is), but cannot be shown in bold in the example due to technical restrictions with css-id usage). -- Quiddity (talk) 21:05, 25 May 2008 (UTC)
  • Comment – I am not sure that the new titles are any more clearer, and they might even be misleading—the Go button is more complex than that, and in fact leads to a search page if it finds no results in page titles. I should instead suggest adding a help link somewhere in the box, explaining how searching works on Wikipedia. Much more useful, don't you think? Waltham, The Duke of 02:11, 26 May 2008 (UTC)
    • See Help:Go button for an explanation of how it works. It searches case variations within titles, and then falls back to a normal (full article text) search if no matches are found. -- Quiddity (talk) 18:28, 26 May 2008 (UTC)
      • This I knew; it is many of the newcomers who are confused, and this is why I maintain that a link like this might be useful in the vicinity of the search box. Waltham, The Duke of 15:41, 30 May 2008 (UTC)
  • Oppose I know what thewy mean and I still find "Titles" and "All text" confusing. Most websites use search, and there's no reason why that should be changed. Reywas92^Talk 16:33, 26 May 2008 (UTC)
  • Strong support- I've seen many people go to Wikipedia and try to use it as a search engine (Typing 'Honda pictures red') and turning up no results. If the go button were renamed to 'Title search' this really should clear the confusion a bit. -- penubag  (talk) 06:55, 30 May 2008 (UTC)
    • I do not understand. The search page appears when there are no title results; wouldn't that page yield the same results if Search were to be hit directly? What difference does it make? Waltham, The Duke of 15:41, 30 May 2008 (UTC)
      • If you type 'Honda pictures red', Go turns up no results, neither does Search, but at least it clarifies. -- penubag  (talk) 02:30, 2 June 2008 (UTC)

Search box with highlighted yellow background, 1 of 3 example colors

• Highlight the search box, with color - A proposal that came out the Main Page Redesign discussion years ago, was that we Highlight the search box with colour (either border or background, see example images). It kind of fizzled out through lack of participation/consensus, but is still an option, both for individuals via css, or to implement sitewide. -- Quiddity (talk) 21:05, 25 May 2008 (UTC)
  • Comment – Highlighting could work; not only does it draw more attention to the larger box, but the long, white box where the letters go is also more prominent through contrast. If that is not accepted, I have another idea: colour the box for the letters yellow, until someone clicks in it the first time (or, even better, until someone searches for the first time). I don't know to what extent that would be technically feasible, but it would attract attention only until noticed. But I think Quiddity's proposal is better (old picture, eh?). Waltham, The Duke of 02:19, 26 May 2008 (UTC)
  • Oppose, I like it just fine as it is now. GO-PCHS-NJROTC ^(Messages) 23:42, 29 May 2008 (UTC)
    • Does this apply on the box's position, though? You might be interested in stating your opinion—whatever that is—above, as well. Waltham, The Duke of 15:41, 30 May 2008 (UTC)
  • Support. This is a request I heard many times in conferences and from regular users with a laptop. They hate scrolling up and down each time they need to do a search. Anthere (talk) 10:08, 1 June 2008 (UTC)
    • Actually, the point of the highlighting is that it will make the box's move unnecessary... On grounds of visual prominence. I like seeing supports here, but this one sounds more like an accident (it is identical to the one in the main poll). Unless, of course, you have additional reasons to support highlighting. Waltham, The Duke of 01:00, 2 June 2008 (UTC)

• If not colouring the search box - what about having the cursor automatically place itself in the search field when the mainpage loads (the way it does when you go to google.com for example). That at least cuts down on one click. And, as there is no other field on the page where you could type there is no other typing option being cut off. Witty Lama 06:38, 2 June 2008 (UTC)

  See Wikipedia:Main Page FAQ#Why doesn't the cursor appear in the search box, like with Google? for that. -- Quiddity (talk) 20:29, 3 June 2008 (UTC)

Welcoming Committee

I believe the WWC is need of help badly. With the large amounts of new users, the user creation log is full of red links. Therefore, I am asking anyone who wants to sign up please do so.--LAAFan 18:54, 23 May 2008 (UTC)

I certainly hope we're not trying to welcome every new user in the list, given that about 50% of accounts never edit, that's just a waste of effort. Only accounts that actually make a constructive edit should be welcomed. Mr.Z-man 19:16, 23 May 2008 (UTC)

I agree. Use newbie contribs, not the user creation log. The last thing you want to do is welcome a vandal. Paragon12321 (talk) 21:16, 23 May 2008 (UTC)

I agree, it is pointless to welcome accounts that never make an edit. However, welcoming productive users is important, and I do agree in part that the WC has fallen somewhat inactive. RichardΩ612 Ɣ ɸ 22:08, May 23, 2008 (UTC)

Here's what I do: When a change appears on my watchlist from a new user, and it's a meaningful contribution, I welcome the user myself. I think that's more meaningful than a committee dedicated to welcoming because it means that I actually saw their work and appreciated it. —Remember the dot ^(talk) 04:49, 24 May 2008 (UTC)

That's not to say that welcoming users based on Special:Contributions/newbies isn't meaningful. It is, but don't think we would have a problem at all if people took to welcoming new users that showed up on their watchlists. —Remember the dot ^(talk) 04:51, 24 May 2008 (UTC)

I agree with Remember the dot. I don't use my watchlist, but when I see a good edit by a user who doesn't yet have messages, I welcome that user. Note that welcome messages per se are unnecessary for users who don't edit because there's already a "welcome" message that you get when you create an account. It's only after you start editing that you might be helped by a welcome message from one of us. Shalom (Hello • Peace) 03:49, 27 May 2008 (UTC)

Why not create a robot to welcome new users? It's cool for the newbies to have a real Wikipedian welcome them and all, but I think a bot would be much more efficient. Many websites run by large corporations (such as Ebay, Myspace, Hotmail, Embarqmail, AOL, Amazon.com, etc) already have bots that send welcome messages to new users via email, so why shouldn't Wikipedia have a bot to post welcome messages on people's talk pages? GO-PCHS-NJROTC ^(Messages) 23:57, 29 May 2008 (UTC)

Because that would defeat the purpose of what we're trying to accomplish by welcoming them - extending a helping human hand and offering assistance if required. P.S. This is a perennial proposal that's been declined many times. xenocidic (talk) 00:03, 30 May 2008 (UTC)

But most people use a template anyways, so that'll make this a moot point. OhanaUnited^{Talk page} 04:04, 2 June 2008 (UTC)

I doubt most people pay attention to the Welcome greetings anyway. I know I didn't; I was mildly annoyed by it. ImpIn | (t - c) 00:11, 6 June 2008 (UTC)

Change "navigation" on sidebar to "browse"

The two main activities on Wikipedia are "searching and browsing" - they go together like bread and butter. They are referred to by these names on most of the relevant help pages, and on Wikipedia's main table of contents page.

Currently, on the sidebar, browsing is referred to as "navigation". This proposal is to change it to the word "browse". With the search section likely to be moved to the top of the sidebar (right below the Wikipedia logo - see that proposal above), having the "browse" section right below the "search" section would be the perfect companion. In any case, "browse" is the term in more common use on Wikipedia, and should replace "navigation". The Transhumanist    22:52, 24 May 2008 (UTC)

• Support - as proposer. The Transhumanist    22:52, 24 May 2008 (UTC)
• Question Could you remind us why it didn't get changed to that during the WP:VPR/Sidebar redesign? Thanks. -- Quiddity (talk) 00:10, 25 May 2008 (UTC)
  • I remember that it was part of the proposal (I might have voted in the poll), but that the specific term did not appear in the end. I did not look into it then, but was glad for the preservation of the word navigation, which is more general and sounds clearer to a non-technophile. Waltham, The Duke of 01:51, 25 May 2008 (UTC)
    • If I recall correctly, we had to retain "navigation" because changing it broke many users' scripts. —David Levy 20:23, 25 May 2008 (UTC)
      • I welcome the comment, but how exactly does the sidebar affect user scripts? And, if so, would moving the search box break any of them? (crosses fingers) Waltham, The Duke of 04:49, 26 May 2008 (UTC)
        • It's highly unlikely that moving the search box will affect any user scripts because the search box can be in a variety of locations depending on the user's skin, and user scripts are generally skin-independent. Furthermore, if a script needs to access the search box then it will probably access it by its id attribute, namely "p-search", and moving the box does not change its id. —Remember the dot ^(talk) 05:08, 26 May 2008 (UTC)
          • Darn. Waltham, The Duke of 00:34, 27 May 2008 (UTC)
      • Here is the reference, end of the thread: MediaWiki talk:Sidebar#Some slight adjustments are needed: "please change 'navigate' back to 'navigation': this is causing many scripts to freak out, and people have had this problem before with renaming navigation.". -- Quiddity (talk) 00:55, 4 June 2008 (UTC)
• Comment – Even if browse is used more in Wikipedia, isn't the box in question mostly for plain readers? These are more often than not completely unfamiliar with any Wikipedia terminology, so what we should be doing is examine what is more well understood outside Wikipedia, not amongst editors. Besides, one should be making a decision on its own merits, not as a response to a change that has yet to happen (and one, in my opinion, which would completely ruin the layout of the sidebar). Waltham, The Duke of 01:51, 25 May 2008 (UTC)
• Support It's a matter of semantics; apples and oranges, basically. Seriously, for such minor little changes, if the wikimedia foundation chooses to make a minor wording change, fine. Do we really need to vote? Dr. Cash (talk) 00:13, 28 May 2008 (UTC)
  • I suppose yes, because not all agree, no matter how small the change. (I should probably add an "oppose" somewhere around here...) Waltham, The Duke of 03:37, 28 May 2008 (UTC)
• Oppose I'm unconvinced this "browse" is better then the status quo. Chris M. (talk) 06:43, 28 May 2008 (UTC)
• Oppose This is a lateral change. There's no clear advantage to the word "browse" over "navigation" (other than being few characters and therefore less clutter). If anything I'd be more likely to get rid of the words "navigation", "interaction", and "toolbox" altogether. I don't think they serve all that much purpose. The logical grouping is already accomplished by the boxes. The words, at least for me, don't even seem to aid in finding what I want. Or alternatively, pulling them inside the boxes and giving them their own CSS might look more pleasing. Jason Quinn (talk) 23:39, 31 May 2008 (UTC)
• Strong oppose - I don't browse the Main Page or anythings else in the Navigation box. I go to it. It is how I navigate quickly to key areas within the Wikipedia. I agree with Jason Quinn that it's a "lateral change" with no apparent benefit, but I disagree that removal of the headings would be helpful. In several cases, I have given instructions to "go to Toolbox and click What links here" or something like that. Many people have done that throughout talk pages, templates, and elsewhere. Even moving the Search box will cause problems with that, since I tell people (if they are using monobook) that Toolbox is right under Search. Speaking of search, I've never yet met anyone who had a problem finding it in its current location. --Willscrlt (Talk) 11:36, 1 June 2008 (UTC)
• Oppose. per Will. Fleetflame 00:25, 4 June 2008 (UTC)
• Oppose. Technical problems with changing to anything other than "navigation", "browse" is less semantically encompassing, "browse" is subjectively less professional. -- Quiddity (talk) 00:55, 4 June 2008 (UTC)
• Oppose – my concerns are virtually identical to Quiddity's above. Nihiltres^{t.l} 11:56, 4 June 2008 (UTC)

Message box standardisation, all namespaces

Last summer the style for message boxes in articles were standardised and the meta-template {{ambox}} was implemented to allow easy creation of such boxes. Some weeks ago we deployed {{imbox}} and {{cmbox}} for image page and category page message boxes. (But we are still discussing one extra feature for imbox.)

Now we have coded up the {{tmbox}} for talk pages, the {{ombox}} for all other types of pages such as "Wikipedia:" pages, and the {{mbox}} namespace-detecting style-shifting message box to rule them all. This means all the namespaces are covered. Everyone is invited to take a look at the new boxes and have a say at their talk pages.

Please discuss at their talk pages and not here. This is just an announcement.

--David Göthberg (talk) 12:26, 30 May 2008 (UTC)

One template to rule them all, one template to find them, one template to bring them all and in the darkness bind them? Hope it's protected... :) -- Gurchzilla (talk) 14:01, 30 May 2008 (UTC)

Haha, oh yes they are protected by a whole army of WikiElfs backed up by hordes of WikiGnomes and WikiFairies. There might even be some WikiDragons and WikiKnights among our ranks.

And don't worry, the other boxes don't build on {{mbox}}, instead mbox uses the others. And mbox is meant to be the least used since it should only be used for message boxes that need to be used on several different types of pages, which is not that common.

--David Göthberg (talk) 14:30, 30 May 2008 (UTC)

Note that we are suggesting some colour changes for talk page and "other pages" message boxes. So we really would like some input from some more editors before we deploy this all over Wikipedia. For instance, this is a talk page message box {{tmbox}} with the suggested style for "minor warnings and problems".

And this is an other pages message box {{ombox}} with the suggested style for "major warnings and problems".

--David Göthberg (talk) 12:26, 2 June 2008 (UTC)

Confusing note on Wikipedia:Sandbox

For more experienced users (and probably most newbies), this usually wouldn't be very confusing since we already know what the sandbox is and what's permitted there, but I can't help but to wonder how many newbies have been confused when they've proceeded to edit the sandbox and read the text "For testing, please use the sandbox instead" on the sandbox. Should we delete "instead" from that sentence that appears whenever someone attempts to edit any page? GO-PCHS-NJROTC ^(Messages) 16:29, 31 May 2008 (UTC)

The relevant text is at MediaWiki:Edittools. It would be even better if this message and MediaWiki:Anoneditwarning didn't show the sandbox bit at all when editing WP:Sandbox. Is this possible? Algebraist 16:42, 31 May 2008 (UTC)

That's what I was thinking, but I figured it'd be easier to change the message to "Use the [[WP:SAND|Sandbox for test edits; do not save test edits in any other space" or something similar. GO-PCHS-NJROTC ^(Messages) 23:14, 3 June 2008 (UTC)

FRUSTRATED: Wikipedia REPUTATION is dirt, sneer, disrespect, skoff, ignored, contempt, unreliable

When I mention Wikipedia to most people older than 30, I get the same reaction:

"Waste of time. Terrible, unreliable info"

• (Personally, I find the Wikipedia concept is fantastic!)

When I probe a bit, I find the source of their disrespect, scorn, sneers, and contempt:

FIRST IMPRESSION - they see the EDIT button, they see that anyone can edit, and immediately write off the project as unreliable information. (They don't understand peer review on wikipedia.)

I know I know... it's a foundation issue and has been discussed thousands of times. All I'm saying is that this is the reaction from most people I meet in person. Wikipedia has a lousy reputation and it's because of the Edit button.

Even a simple change like "Submit" (instead of Edit) could make a huge difference. —Preceding unsigned comment added by VgerNeedsTheInfo (talk • contribs) 17:36, 31 May 2008 (UTC)

• "Wikipedia: the free encyclopedia that anyone can submit." Doesn't work as well. --jpgordon^∇∆∇∆ 17:38, 31 May 2008 (UTC)

If you think the button names or user interface could be changed for better presentation, that's a reasonable suggestion. There have been proposals to simplify or rearrange the buttons for users who have not logged in, on theory that the majority are not interested in all of the features. However, I don't share your perception about Wikipedia's reputation. That's simply a byproduct of biased and shallow coverage in the press, which is more interested in scare stories and amusing anecdotes than substance when it covers things on the Internet. Anyone who has that opinion has not given it much thought, and is not really the kind of user Wikipeida needs to reach. The Foundation lacks the multimillion dollar PR and marketing budget that commercial operations and even schools and charities use to counter bad press, so we might just have to live with it. 17:43, 31 May 2008 (UTC)

And yet we are one of the most popular web sites on the internet. We are a work in progress. _{1 != 2} 17:49, 31 May 2008 (UTC)

Of course, you could just rename the "Edit" button to "Contribute", but only to users who have not registered. It's something to consider nonetheless. --.:Alex:. 17:51, 31 May 2008 (UTC)

And my reply to anyone who thinks the edit button makes the information unreliable is to point out just how wonderfully satisfying it is to be able to actually correct errors rather than have to put up with them or consult lengthy errata sheets like you have to do with textbooks and other publications. The proverb, "Don't believe everything you read" long predates Wikipedia... —Ashanda (talk) 18:04, 31 May 2008 (UTC)

Wikipedia is not so universally denounced by non-young people. There are plenty of active contributors who are older. I've met multiple college professors who like the idea of Wikipedia - I've even seen a textbook that referred students to Wikipedia for information on topics that were too specific to be covered in the book. While Wikipedia isn't universally liked either, I don't think changing the wording of the edit tab is really going to change any minds. Mr.Z-man 18:08, 31 May 2008 (UTC)

And a lot of people under thirty dismiss us. Therequiembellishere (talk) 04:24, 1 June 2008 (UTC)

The fundamental problem with changing "edit" to "submit" is that it's inaccurate. This isn't really a peer reviewed system. Edits go live as soon as you hit "save page" without any other human eyes seeing them. If your older friends think this makes Wikipedia unreliable, that's their opinion. If the button said "submit", new editors might make changes assuming someone will look at their "submissions" before they become part of Wikipedia only to be surprised to see the changes immediately. --D. Monack | talk 05:55, 6 June 2008 (UTC)

It's actually important that people who use Wikipedia should expect the worst of the page they are reading. It's simply the truth that you can't be sure what has just been changed, by whom, in the last five minutes. The content of articles has to prove its reliability through quality and verifiability. In terms of an irrational fear of this, the advent of flagged revisions may serve as the safety blanket your friends need, to know that somebody with some experience has at least already checked the page. BigBlueFish (talk) 15:28, 7 June 2008 (UTC)

Instead of changing it to a "submit" button, What about a "correct/add" button? Bobzooka (talk) 12:55, 9 June 2008 (UTC)

That is simply an incomplete definition of editing. BigBlueFish (talk) 16:11, 9 June 2008 (UTC)

Being able to see the history of a section within a large article

The other day, I had a need to see the history of a small section of a large article I was working on. So, my only recourse was to view the history of the entire article. I must have looked at over 2000 entries of edits and not one of them referred to the section I was working on. It was just too overwheming, so I just gave up. Anyway, if there were an ability to view the history pertaining only to a section of an article, the information I needed would have been much easier to acquire. Just a thought. Thanks. --Champaign (talk) 22:48, 31 May 2008 (UTC)

This is not possible, I think, because the software doesn't record where in the article you make an edit. – Mike.lifeguard | ^@en.wb 23:55, 31 May 2008 (UTC)

There are so many times I have wanted this feature, it would really come in handy. --→ Ãlways Ãhëad (talk) 01:31, 1 June 2008 (UTC)

Completely agree. Therequiembellishere (talk) 02:28, 1 June 2008 (UTC)

Articles will be stored as one file, not a group of sections, so this would be impossible. It would be very problematic to change this, e.g. renaming a section would be much more difficult. It would have some advantages, e.g. being able to watch a given section only, or view its history, but it's not likely to happen. Richard001 (talk) 02:34, 1 June 2008 (UTC)

This is something that currently can only be done with external tools and only works as long as the section isn't renamed. --Samuel Pepys (talk) 02:36, 1 June 2008 (UTC)

And as long as only one section is edited at a time. – Mike.lifeguard | ^@en.wb 03:55, 1 June 2008 (UTC)

Not sure what you really want to achieve, but this tool is sometimes helpful if you want to identify who did what change. I know this is not at all what you where asking for, but maybe what you needed. :-) --Stefan ^talk 11:52, 2 June 2008 (UTC)

The results of merge discussions are seldom recorded

Like with AFD, I think we should have templates that record the results of merge discussions - either there was consensus not to merge, no consensus, or a merge occurred. In the first two cases, this should be recorded at the top of relevant talk pages (cf. Template:Oldafdfull). In the case that there was a merge, it should also be recorded at the top of the talk page the page where the merge took place. It needn't be enforced strictly, but I think it should become more common and templates should be made available for this purpose.

This can help people avoid suggesting merges without realizing there has been discussion before, or creating pages that have been merged in the past. Richard001 (talk) 02:58, 1 June 2008 (UTC)

Merge discussions aren't normally formalized, unless they were suggested and acted upon in an XfD. However, I agree with you that adding a note about merge discussions is a good idea. -- Ned Scott 04:29, 1 June 2008 (UTC)

I certainly don't like the divide between the formal XfD discussions, with usually plenty of input and a fairly solid outcome, and the informal merge discussions with little (if any) input and often no consensus. I think I'll just request these templates be created and use them here and there, and maybe others will follow my lead. Richard001 (talk) 05:56, 5 June 2008 (UTC)

Proposal to extend CSD A3

I have encountered a fair number of Commons image's talk pages being created on en.wiki with content similar to this. While this content clearly is not beneficial to the project, it does not fall under any of the current CSD criteria. The two closest "matches" are CSD A3 ("No content") and CSD G8 ("Talk pages whose article does not exist") and I think an extension to A3 to allow the "article" template to be placed on image talk pages would suffice to remedy this gap. An alternative would be to allow G8 to be placed on Commons image's talk pages as it currently has a prohibition on doing that. Another alternative would be to create an "I11" criteria that would basically be the same as A3 except it applies to image talk pages. Imho, extending A3 would be more effective than extending G8 because it could also be applied to similar "commentary talk pages" that show up on images hosted on en.wiki. Also, an I11 criteria is unnecessary imo because the same thing would be accomplished with the A3 extension. Any thoughts will be greatly appreciated. Thingg^⊕⊗ 22:44, 1 June 2008 (UTC)

But do we really have delete pages of this kind? as opposed to leave them alone or blank them if causing a problem. -- Taku (talk) 22:50, 1 June 2008 (UTC)

Current behavior is all across the board on this issue. I agree with TakuyaMurata in that the best option is to either blank it (usually if it is vandalism) or ignore it if it is just side commentary. --- RockMFR 22:52, 1 June 2008 (UTC)

Blank with the justification that the talk that does not contribute to the improvement/understanding of image & G6 perhaps? xenocidic ( talk ¿ listen ) 22:54, 1 June 2008 (UTC)

I don't mind blanking them, it just seems like a waste to have all these blank talk pages lying around. Thingg^⊕⊗ 22:58, 1 June 2008 (UTC)

That's why you follow it up with a WP:CSD#G6. xenocidic ( talk ¿ listen ) 23:00, 1 June 2008 (UTC)

I didn't know that could be applied there... ok thanks. Thingg^⊕⊗ 23:03, 1 June 2008 (UTC)

It can't, really; or at least that's not what it's meant for. The speedy deletion criteria for blank pages are either G7 (if the original author blanked the page) or A3 (for articles that have no valid content to revert to). That said, for pages as obviously useless as the one you cited above, I don't think anyone would complain if you stretched A3 to cover this, or (and this is what I usually prefer to do in such situations) just deleted it with the automatic default summary and let that speak for itself. Or, if you really want a justification in existing policy, just cite WP:SNOW and past precedent at MfD (which I'm pretty sure can be found in the archives if you dig a little — or just nominate one such page as a test case and see what happens). Just be sure if you do this that the page really is useless, and not something anyone would want kept around. —Ilmari Karonen (talk) 01:05, 2 June 2008 (UTC)

Yea, I wasn't quite sure if G6 would explicity apply. I think it could be re-written to though, no? (I just think G6 would seem to "fit" more, especially with it's current description). xenocidic ( talk ¿ listen ) 02:53, 2 June 2008 (UTC)

It's like a tree-in-the-forest thing. If an admin deletes a page under G6 and nobody complains, is there anything to complain about? If you think it's worth doing I would just be bold and add something to one criterion or another, being careful not to actually enable a broader range of deletions than one means. Wikidemo (talk) 05:33, 2 June 2008 (UTC)

For the one mentioned above, G6 would probably apply. I can't think of any reason why deleting a talk page consisting entirely of 'it's nice' would be controversial, especially given that the image is on Commons anyway. For others, an MfD test case may be helpful. RichardΩ612 Ɣ ɸ 06:15, June 2, 2008 (UTC)

I don't think G6 should become synonymous with WP:SNOW, even though the current wording could be interpreted that way. The original intent of G6 is that it should cover uncontroversial technical deletions, such as to repair cut-and-paste moves or to allow pages to be moved over redirects that have been edited since they were created. Those are things that only count as deletions in the technical sense anyway, since no meaningful content is actually permanently deleted. —Ilmari Karonen (talk) 00:48, 3 June 2008 (UTC)

New Article Creation "Holding Area".

How about instead of just letting everyone add article willy nilly, there exist a process by which new articles are automatically created in a users space. An editor can then, at their leisure but for a limited time, begin the creation process. After the new article has been created to the original editors liking, he can then choose to have that article sent out to the "baby article" log, where it can be viewed by his peers. At this point the new article is still not "published" but in a limbo area were consensus can be reached as to the readiness of the new article to be released into the wild. Reviewers can also suggest changes (or make it themselves) according to the current process.

This new method of article creation would eliminate much of the current hostility and needs for "damage control" by administrators while at the same time giving new articles a chance to grow and be useful to the using public. If at the end of a pre determined and documented time (provided at the top of every new article) an article does not receive a positive consensus to "keep", it is removed from the database with a copy automatically emailed to the original creator. Everybody wins! I think its a great idea, how about you? Snottythetroll (talk) 07:28, 2 June 2008 (UTC)

Good in theory, but doesn't work in practice, I think. This scheme sounds awfully like Wikipedia:Articles for creation. As I have heard, it has a huge backlog, which is still growing. The problem with this kind of reviewing mechanism is that the number of creators significantly outweighs that of reviews. A post-filterling system as opposed to a pre-filterling system seems like the only option we have. -- Taku (talk) 09:41, 2 June 2008 (UTC)

I suspect most seasoned editors develop articles in userspace and move them to articlespace when ready. Perhaps the Article wizard should be developed and promoted for new editors. Not perfect, but probably better than many of the new articles. --—— Gadget850 (Ed) ^talk - 15:21, 4 June 2008 (UTC)

Moreover, it would create a whole new breed of lawyering about whether an article is "notable" or not, with the respective sides of that never-ending argument looking out like hawks to kill or defend. I think WIkipedia already has a big enough problem with talk page buzzards picking at and complaining about articles. SiberioS (talk) 08:19, 9 June 2008 (UTC)

FritzpollBot Discussion

Hi - I've made a refined proposal based on yesterday's mad, mad rush of comments, which my brain has now had time to process. Thing is, I don't want to post it on the page as it is. Should I archive it, or start a new page? Otherwise the discussion will get in the way of what is actually being proposed. Arhciving would also remove the hideousness of the straw poll Fritzpoll (talk) 13:12, 2 June 2008 (UTC)

I would suggest just copying & pasting the entire contents to the talk page of the same page, and perhaps adding a {{talkarchive}} tag. Ensure your new proposal is ready to be put on the proposal page immediately afterwards (or simultaneously) before you do this. xenocidic ( talk ¿ listen ) 13:14, 2 June 2008 (UTC)

Thanks that's what I've done: I sure enjoyed removing that divisive discussion! Fritzpoll (talk) 13:38, 2 June 2008 (UTC)

Renaming "history" tab

Last year, editor Borisblue proposed changing the name of the history tab. I felt that renaming the tab to either "versions" or "revisions" would make its function clearer for casual readers and newbies. However, some respondents just didn't see the need for a change, and the proposal faded. (old discussion)

I think it's time to revisit the question. Part of the problem convincing people we ought to change, is that everyone who would be discussing it has been on Wikipedia long enough to know what the history tab is. Thus, it is hard for them to see how opaque it might appear to the uninitiated. They might, as in Borisblue's example, think that the tab on "Poland" would lead to "history of Poland." Or they might simply not get its purpose at all; after all, non-wiki pages don't have a mechanism for viewing past versions. I don't think we should assume that those readers will, out of sheer curiosity, click on the tab to see what it is, or do a mouseover. I believe that "versions" or "revisions" (or even "authors," the German Wiki uses "Versionen/Authoren") would be more likely to get people to click on the tab.

I know some people will say, "why change?," but can someone make the case why the current name is actually better or clearer? --Groggy Dice T | C 16:29, 2 June 2008 (UTC)

There may be issues with GFDL compliance, since I understand that Wikipedia asserts the history tab to be our "section entitled 'History'" as defined in section 1 of the GFDL and referenced in sections 4.I/J and the third paragraph of section 5. Of course, it doesn't seem like the non-English Wikipedias strictly comply with the titling requirements of section 1 anyway, and in any case our application of the GFDL is already rather idiosyncratic given that the license was never designed for wikis in the first place. —Ilmari Karonen (talk) 00:56, 3 June 2008 (UTC)

"Contributions" could perhaps increase community togetherness :). ☯Ferdia O'Brien ^(T)/_(C) 14:18, 3 June 2008 (UTC)

I like the idea of renaming it "Log." GO-PCHS-NJROTC ^(Messages) 23:19, 3 June 2008 (UTC)

We could name it "revision history" if we needed to... Titoxd^{(?!? - cool stuff)} 05:44, 5 June 2008 (UTC)

Isn't it called History in order to comply with the requirements of GFDL? Corvus cornix_talk 20:45, 5 June 2008 (UTC)

Submit To Bugzilla

Wouldn't it be great if we could have a page where we could see ALL the changes made to the document, including redirects, moves, and creation, from all the user who contributed? There could be a separate sub page, or function, where you have the Revision history page on one side, but only taking half (or whatever porportion) of this proposed page, and then lines to from the users who contributed (in bluelinks) to their changes! Please submit this idea to Bugzilla, since I don't have an account. Thank you! 68.148.164.166 (talk) 05:03, 3 June 2008 (UTC)

Make established articles move protected?

It seems that there is a recent increase in page move vandalism. The vandal choses the most visible articles. Do we really need to move articles like Sun, Canada or Pacific Ocean to move that often? Would be such a move unavoidably controversial and so better handled via WP:RM? I think any move of a well-established article should go via WP:RM so people who edited the article and were happy with the name could have their say. If so why not move-protect all "well established articles".

There are many ways to define which article is well established. We might base it either on the number of edits or editors or on the age of the article. How about:

• More than six month old article with more than two contributors?

or

• An article with more than 100 edits with more than two contributors?

The measure would not decrease the page move vandalism but it would make it more less visible. Alex Bakharev (talk) 12:32, 3 June 2008 (UTC)

Yeah, articles like Dog, Port Charlotte High School, United States, Child, Telephone, and Port Charlotte, Florida probably don't ever need to be moved. I think page moving should be like rollbacking; an editor should have to request the tool, and an administrator must grant or deny the request. GO-PCHS-NJROTC ^(Messages) 23:24, 3 June 2008 (UTC)

That's actually a pretty good idea. It would be interesting to run some metrics: what percentage of moves are non-vandalistic, and how many people actually ever move articles? --jpgordon^∇∆∇∆ 23:27, 3 June 2008 (UTC)

Order of precedence

As far as I can tell their is no explicitly laid out order of precedence for wiki policy. I feel its time we lay out which policy outweighs other policies. For example if on a WP:RM 10 people vote oppose but one votes support with a reference should WP:CON be overruled by WP:V? WP:C would over rule WP:V right? Gnevin (talk) 12:38, 3 June 2008 (UTC)

I think WP:IAR would come before anything, if that's any help to you. --.:Alex:. 12:59, 3 June 2008 (UTC)

I think something like this would only encourage more wikilawyering and detract from the community trying to reach consensus and compromise on matters of disagreement. - Masonpatriot (talk) 15:51, 3 June 2008 (UTC)

The current WP:BASHing isn't really helping reach con either as Wiki has many rules that will apply . Gnevin (talk) 07:29, 4 June 2008 (UTC)

But they apply in different ways in different situations; for example, if 10 people voteestablish consensus to delete an article due to its being supposed to be unverifiable, and one person comes and adds reliable references to the article just before closure, then the closing admin can ignore the earlier opinions as they no longer apply. Effectively the 11th editor used WP:V to overrule WP:CON, the opposite of what you say above. :-) I think that the easiest and simplest way to deal with precedence issues is to just WP:IGNORE the parts of any policies that you think have a lower precedence in a given situation (which gives the same effect without needing to create a list of situations vs. policy-precedence lists, which would probably end up being non-exhaustive anyway). I think that's what User:.:Alex:. was trying to say. --_{tiny plastic} Grey Knight ⊖ 07:20, 5 June 2008 (UTC)

Is there one single case of a Con of 10 to 1 being over turned based on WP:V? Gnevin (talk) 07:32, 5 June 2008 (UTC)

Well, if the only rationale provided by the other commenters was "has no reliable sources" and somebody fixes that mid-AfD, then I would imagine that would be the only reasonable outcome. I don't know of any actual examples, but I think that deleting a reliably-sourced article on the basis of having no reliable sources is pretty silly, so hopefully there are some! :-P --_{tiny plastic} Grey Knight ⊖ 08:10, 5 June 2008 (UTC) I made a slight edit to your comment to fix a formatting error

I propose that any rules necessary for compliance with U.S. law (such as WP:C) should come first, followed by WP:NPOV and the general principle of "first, do no harm" (that "the importance of following process may, at times, be superseded by the need to minimise the harm caused by inaccurate, unbalanced or inappropriate content,"^[1] which to me is implied by the mandate to "ignore all rules,") followed by all other policies, followed by consensus, followed by guidelines. That is not to say that guidelines ought to be ignored, but rather, that if anything higher on the list contradicts them, then whatever is highest on the hierarchy would ordinarily prevail. 69.140.152.55 (talk) 14:44, 9 June 2008 (UTC)

________________________________

1. ^ See the Wikipedia essay on avoiding harm, but keep in mind that the essay is only a suggested application to biographical articles, and the general principle should be applied everywhere.

69.140.152.55 (talk) 14:44, 9 June 2008 (UTC)

Font Style in Wikipedia difficult to read

Hello.. Every time I use Wikipedia I wince, visually. I find it very difficult to read and wonder if it could be styled with a font that does not tent to be so compressed, and perhaps has lower case letters as well. Doesn't have to be Arial / Verdana.. but the current choice is bordering on illegible. Can we change it? Thank you D. Heywood. June 3 2008—Preceding unsigned comment added by 66.92.19.126 (talk) 16:40, 3 June 2008 (UTC)

If you get a username, then you can adjust the font however you want by adjusting your preferences. Wrad (talk) 17:14, 3 June 2008 (UTC)

I just logged out and found it used the same font I normally see (which has lower case letters, of course) Logging back in, I found no way to change it in My Preferences. Does it require editing the user .css or .js files? If so, this is not a user-friendly way to change fonts. Rmhermen (talk) 17:32, 4 June 2008 (UTC)

The only thing you can change directly in your preferences is your skin. See Wikipedia:Skin for samples of each. Other changes can be made only by changing your .CSS; Wikipedia:Skin has the links to your .CSS for each skin. --—— Gadget850 (Ed) ^talk - 17:44, 4 June 2008 (UTC)

Wikipedia uses your web browser's default font selection. Change that, and you change the way Wikipedia looks. (Google specifies Ariel in their pages, you might like to set that). -- Quiddity (talk) 18:39, 4 June 2008 (UTC)

You can change your browser's font settings under "options", but you might not find what you want. I have the same size Times New Roman set in both Firefox and IE, on this computer, but the text is different in each; IE's TNR is much easier to read. Gwinva (talk) 21:31, 4 June 2008 (UTC)

Of course, IE is less manageable on here. Therequiembellishere (talk) 21:35, 4 June 2008 (UTC)

Post On Bugzilla

Wouldn't it be great if we could search within our own contributions (or whatever, (or changes)) for say, all things we replaced with "{{main|". Please post this on bugzilla since I don't have an account, thanks!68.148.164.166 (talk) 19:17, 3 June 2008 (UTC)

Merge donation banner with anon tips

There is a proposal to merge the anon tips ("Ten things you may not...", etc.) and the donation banner into one banner. The proposal is available here. Comments / input / feedback are welcome there. Cheers. --MZMcBride (talk) 19:19, 3 June 2008 (UTC)

"First" and "Last" buttons

Ever notice how some sites (such as web based email and search engines) not only have a next and previous button, but they also have a first and last button? I think it'd be swell if we had that kind of button under the history tabs. GO-PCHS-NJROTC ^(Messages) 23:28, 3 June 2008 (UTC)

• They are called "latest" and "earliest" in Wikipedia's history. Phlegm Rooster (talk) 23:33, 3 June 2008 (UTC)

• LOL, never mind. I could swear that there was something in Wikipedia that didn't have those buttons though. GO-PCHS-NJROTC ^(Messages) 23:26, 4 June 2008 (UTC)

• Perhaps you were thinking of "What links here"? Waltham, The Duke of 01:23, 6 June 2008 (UTC)

Ratification vote on {{C-Class}} started

Hi. The ratification vote to add {{C-Class}} to the assessment scale has started. The poll will run for two weeks, until 0300 UTC June 18, 2008, and you can find the poll here, where we ask for your comment.

On behalf of the Version 1.0 Editorial Team, Titoxd^{(?!? - cool stuff)} 03:09, 4 June 2008 (UTC)

Image copyright tags

Last year most of the non-free image tags were renamed to indicate their nonfree status by changing the naming scheme from {{logo}} to {{Non-free logo}}. However, on viewing Category:Non-free image copyright tags one can see that many tags are still wrongly named.

So I am proposing to go through and rename all non-standard tag names to the proper {{Non-free X}} model we have adopted. I will then file a WP:BRFA and correct the template use at the image level with my bot, as was done in the past for the other non-free tags. This will have the added advantage of making the Image: page more machine readable for fairuse compliance purposes. MBisanz ^talk 03:40, 4 June 2008 (UTC)

Go for it. Several of the tags were renamed, but the old name is still prevalent. {{Product-cover}} is a good example. —Remember the dot ^(talk) 04:21, 4 June 2008 (UTC)

Opened Wikipedia:Bots/Requests for approval/MBisanzBot 3 MBisanz ^talk 04:49, 4 June 2008 (UTC)

I completely support this proposal. I imagine these templates were either overlooked when the standardization took place or created at some point after it. As I understand it, this will just be another pass through Wikipedia:Non-free content/templates, which should include renaming templates in Category:Non-free image copyright tags (actually, a more complete list is found here, I will try to reconcile the uncategorized ones tomorrow) and deleting non-conforming redirects (after they have been completely decommissioned by bot). - AWeenieMan (talk) 04:50, 4 June 2008 (UTC)

Support. Also add a sortkey to the category in the template so that Template:Non-free xxx is sorted by xxx; otherwise the cat is going to be populated in T or N. --—— Gadget850 (Ed) ^talk - 12:08, 4 June 2008 (UTC)

Support - not sure if this is needed, but see this page in my userspace for all of the non-free license tags that I was able to track down - I think there may be some that escaped categorization. Kelly ^hi! 13:41, 4 June 2008 (UTC)

Ok, seeing no one has objected, I'll begin renaming in about 20 minutes. MBisanz ^talk 04:27, 5 June 2008 (UTC)

Ok, renaming Y Done MBisanz ^talk 06:20, 5 June 2008 (UTC)

User interface proposals

I have seen a number of proposals for changing the user interface and there are myriads of scripts or CSS changes that an editor can use. Instead of bite-size global changes, why not provide a preference page where each editor can customize their individual experience. I suppose many of these would be classed as gadgets, but the current approach is not unified. Some possible settings:

• Location of the search box
• Default search engine
• Wikipedia logo: on, off or custom image
• Default font style and size
• Link styles
• Location of the edit links
• Diff styles
• Tab names

--—— Gadget850 (Ed) ^talk - 13:39, 4 June 2008 (UTC)

Thats a bugger load of work for the developers to find there way through but customisable CSS settings would solve alot of the compaints we get on the topic. Can I suggest adding the curser automatically going to the search box to that list. We hear about that one on Talk:Main Page al the time. ☯Ferdia O'Brien ^(T)/_(C) 10:58, 5 June 2008 (UTC)

Default Auto-Sign

Users should have an option under "my preferences" to allow them to have their signature automatically added to non-minor edits on talk pages. This option should also allow users to override a default signature with some other. For example 4 ~'s added automatically, and 5 ~'s overriding that. _{Wiki11790  talk}  18:12, 4 June 2008 (UTC)

Where in their edit should it be added, though? Not all talk page edits consist of just adding a line; people frequently put complex things like "straw polls", blocks of suggested/removed article content, and what-have-you. Not counting talk-page tagging, archiving, thread-splitting, and so on. I think this is one of those tasks for which the manual solution is easiest. :-) --_{tiny plastic} Grey Knight ⊖ 10:39, 5 June 2008 (UTC)

This is a default feature in the upcoming(?) new implementation of talk page style. You can see more information on meta:LiquidThreads -- penubag  (talk) 23:56, 5 June 2008 (UTC)

Proposal to reduce the protection level of Wikipedia:Upload

A discussion is taking place at Wikipedia:Administrators' noticeboard#Wikipedia:Upload concerning the removal or reduction of the protection on the main upload page, to open it up to community development.

The Transhumanist    00:13, 5 June 2008 (UTC)

You know reducing the protection level of a page that gets that many views is one thing, but drawing it to everyone's attention is just begging for shock vandals to abuse it. _{1 != 2} 00:18, 5 June 2008 (UTC)

The page gets over 10,000 views a day. That's an average of about 1 view every 9 seconds. Any shock vandalism would be short-lived. And if the page's protect is reduced, its watchlisting will definitely increase. No worries. The Transhumanist    00:45, 5 June 2008 (UTC)

I wouldn't worry about shock vandalism overmuch. My concern is more subtle damage. It's very easy to screw up all those upload links in ways that wouldn't be immediately obvious to the casual contributor, and that might sneak past your average vandal patroller as well. We already have enough trouble with images that have inaccurate and imcomplete source and license information; I'm not sure I want to open up the page to editing by every single autoconfirmed editor. (Forget vandals, I can see the well-meaning but ham-fisted doing significant harm here.) TenOfAllTrades(talk) 01:21, 5 June 2008 (UTC)

Using Random String Instead of IP Addresses

It seems like sometimes people intentionally post messages without signing them, and that in some ways identifying the ip address of the person who posted an anonymous message almost violates their privacy. And since the use of the ip address is mainly useful for following posts on talk pages with unsigned comments, I propose that rather than using ip addresses as the identifier we should use some sort of random string generated specifically for that ip address. For certain public institutions (schools, government, large businesses), I think the ip address probably should still be public. Theshibboleth (talk) 10:10, 5 June 2008 (UTC)

They could always make an account and come up with their own identifying string. :-) But in any case, they're not forced to sign with tildes (although they should do it anyway), and if there's some pressing reason to avoid User:SineBot then they can either use the opt-out template {{NoAutosign}} on their user page or add "!nosign!" to the summary of a particular edit. At least, I think that all works for unregistered users. --_{tiny plastic} Grey Knight ⊖ 10:34, 5 June 2008 (UTC)

The privacy policy is determined globally by the foundation and cannot be changed locally at en.wikipedia, even if you gain consensus for these changes. Algebraist 10:45, 5 June 2008 (UTC)

More to the point, this would require changes to the MediaWiki software. It wouldn't be unprecedented — autoblocks are already anonymized in this manner — but it would require some rather extensive technical changes. (Probably the simplest way to implement it would be simply to change the routine that maps IP addresses to usernames, such that the obfuscated string would effectively become the IP's username.) Also, such obfuscation would interfere with some legitimate tasks, such as determining the likelihood of collateral damage from IP blocks, alerting organizations to vandalism from their IP addresses, open proxy detection and IP range blocking. Most of these problems could be mitigated by allowing administrators to see the actual, unobfuscated IP addresses, but that would make the implementation more complex yet.

Finally, it still wouldn't offer an ironclad protection against IP address disclosure: with a fixed IP-to-username mapping, as it would almost have to be, even a single spill of the address corresponding to a particular username would allow any edits ever made from that address, both before and after the spill, to be tied to the IP. In particular, anyone with access to the IP (e.g. because it's a shared proxy) would be trivially able to determine (and, if they wanted, to reveal) the corresponding username. Of course, some might consider that last part a desirable feature. —Ilmari Karonen (talk) 12:23, 5 June 2008 (UTC)

For that matter, the code to do the mapping would be visible in the MediaWiki source, and it would only be a matter of a few minutes to generate a complete mapping between valid IP addresses and obfusication strings. --Carnildo (talk) 20:45, 5 June 2008 (UTC)

Not if you generate a random key on install and store it in LocalSettings. We already store database passwords there, so it should be secure enough for that. Just better make sure the key is really random, and long enough to avoid any known-plaintext attacks. —Ilmari Karonen (talk) 20:54, 5 June 2008 (UTC)

It would not matter one iota if IPs were mangled on talk. They would also need to be mangled in history if "privacy" were an issue, and that would be a Bad Idea^(tm). IP addresses are essential for distinguishing vandals (I won't provide more hints for obvious reasons).

Further, they are necessary for determining range-blocks, and checkuser has enough on their hands as it is.

And with respect to exceptions for "public institutions": we don't do double-standards. Besides, it would be more overhead for the servers in order to determine whether an edit is from a "public institution" or not, and more overhead for the devs to keep that information up-to-date.

Besides, anon editors see an in-your-face warning that they are revealing private information. That is more than enough. Its their business if they choose to ignore that warning. -- Fullstop (talk) 21:46, 5 June 2008 (UTC)

And in most cases, IP address won't reveal any more than the user's ISP and general location. Unless people have access to ISP databases, its generally not "personal information." Mr.Z-man 02:21, 6 June 2008 (UTC)

Category Overlap Tool

So, could we add a function that lets you view the overlap between categories? For example, you could see what articles are in the categories for both French engineers and French mathematicians. -Link (talk) 12:39, 5 June 2008 (UTC)

I believe we already have it - see Wikipedia:Categorization#Searching for articles in categories. DuncanHill (talk) 12:47, 5 June 2008 (UTC)

Which for your query returns these results [9]. DuncanHill (talk) 12:49, 5 June 2008 (UTC)

Well, whaddaya know? Never mind.-Link (talk) 12:56, 5 June 2008 (UTC)

Stagnation Prevention List and View Count

How about a list of articles that haven't been edited in a while (say, a minimum of three months) so people can see what articles need attention? Obviously, the longer it's been since an edit, the higher it will be on the list.

Also, why don't whe add a view count, so we can see how many times a page has been viewed? This would make it a lot easier (or at least somewhat easier) to resolve certain issues, such as article priority. For an example of a wiki that does this, see here; view counts are at the very bottoms of articles.-Link (talk) 13:08, 5 June 2008 (UTC)

Your second proposal has come up several times before, but your first one may have merit. Perhaps there's some functionality in Specialpages that does that, I'm not sure. --_{tiny plastic} Grey Knight ⊖ 14:36, 5 June 2008 (UTC)

I saw that thing; I mean how many time a page has been viewed, ever, not how many users are watching it at the moment.-Link (talk) 14:44, 5 June 2008 (UTC)

You can view the traffic statistics of an article with this tool : [10] JoJan (talk) 15:15, 5 June 2008 (UTC)

Perhaps, but it would be a lot more useful to have a built-in feature that can count views, instead of having to go to another site.-Link (talk) 15:46, 5 June 2008 (UTC)

Also, as far as I can tell, there is no tool in the Special pages that indicates which pages have not been edited recently.-Link (talk) 17:44, 5 June 2008 (UTC)

View counts are a Mediawiki feature that is turned off in order to make page caching for anonymous readers possible; it's a performance tweak but an important one. Dcoetzee 21:49, 5 June 2008 (UTC)

As for articles which haven't been edited in a while, see Wikipedia:WikiProject Abandoned Articles. (On the WikiProject talk page I believe you'll find an offer from someone who has done analyses of a recent database dump, regarding more current lists.) -- John Broughton (♫♫) 01:22, 6 June 2008 (UTC)

Please Post On Bugzilla, Thanks!

I would be great if we could click on the version instead of having to have to click on the 2 radio buttons just to get to the later version. Please post this on bugzilla, because I don't have an account, thanks!68.148.164.166 (talk) 02:22, 6 June 2008 (UTC)

I'm not sure what you're asking for. If you want to look at an old version of the page, you click on the date/time link in the history. If you want the difference between an old revision and the previous revision, you click on the 'last' link. If you want the difference between an old revision and the current revision, you click on 'cur'. All you need the radio buttons for is comparing two old revisions that are more than one revision apart, and I can't see how this could be done better. Algebraist 08:56, 6 June 2008 (UTC)

Also, clicking on the version (the date/time link) has a particular function to itself, so this would be a WONTFIX. Titoxd^{(?!? - cool stuff)} 09:34, 6 June 2008 (UTC)

Founder or Co-founder that is the question

I believe as most people do in freedom of expression and I think it is wrong to censor user pages in most cases in fact almost all cases however when a user as important as Jimbo Wales whose page is viewed countless times writes something that though he himself may believe to be true is misleading it is the duty of Wikipedians to be neutral and write the truth. So how about we have a vote (consensus over truth) to persuade Jimbo Wales to change the information on his user page that states that he and he alone founded Wikipedia to co-founded. Note: I know this may sound petty and like a waste of time :) but I really think it is a mean thing of Jimbo to do so vote, please don't be afraid be bold.THROUGH?AWIKI?DARKLY (talk) 09:21, 6 June 2008 (UTC)

This is not a proposal. It's a content dispute you've been involved in (presumably under another account) on ANI, in a section entitled "Edit war on God". ╟─TreasuryTag (talk ╬ contribs)─╢ 09:23, 6 June 2008 (UTC)

And yes, this does sound quite petty. Mr.Z-man 14:59, 6 June 2008 (UTC)

Brackets around citation numbers

With what appears to be the growing acceptance on this project of what I call "cite bombing" - that is, the addition of a cite, or multiple cites, for every sentence, and sometimes every clause of a sentence, I am finding it increasingly difficult to read some articles, because of the amount of "clutter" that the cites ^[1] add.

In thinking about how this might be rectified, it occurred to me that the use of brackets around the cite number [] is arguably unnecessary. One doesn't, after all, find brackets around citation numbers in a book, but they are still easy to see and use, and they don't disrupt the text at all. So why, exactly, do we have these brackets? Are they really necessary? Is it time we maybe thought about dropping them, and just having the number instead? Gatoclass (talk) 10:09, 6 June 2008 (UTC)

I (kinda) agree with you but it is not that cluttered that it isn't unreadableTHROUGH?AWIKI?DARKLY (talk) 10:11, 6 June 2008 (UTC)

I've seen a few articles with the condition that you're talking about, User:Gatoclass, it can be a bit awkward. I can't find any examples just now, if you turn any up it might help to link diffs here so people can see what you mean. :-) Anyway, I was wondering if it's possible to have multiple refs written as ^{[10,11,12,13,14]} rather than ^{[10][11][12][13][14]}, which would cut down on the size of the "ref nugget" a little bit. Might not be possible with the way the ref system is setup at the minute, though, and to not much effect. An easier solution might be to discourage people from over-doing it in the first place! --_{tiny plastic} Grey Knight ⊖ 13:14, 6 June 2008 (UTC)

As far as I'm aware, there shouldn't be multiple refs for a single statement except for rare and very particular circumstances. Even then there should never be that many. If you could give us an example, there are probably a few I could point out that could even be removed (there is such a thing as excessive citing). Still, merging multiple refs into a single set of brackets is a very interesting idea. --.:Alex:. 14:22, 6 June 2008 (UTC)

I think instances of it come from either (1) citing all statements in a sentence/paragraph at the end, or (2) people being overzealous in their reaction to "that statement's not cited in multiple secondary sources". I found an example at Soulja Boy#Initial_reception revision, if it's of interest. A mere four refs in a row, I'd like to point out that I have seen bigger "nuggets" in the past! :-) --_{tiny plastic} Grey Knight ⊖ 14:43, 6 June 2008 (UTC)

It can also sometimes be found when there is a statement like, "Many other critics agreed.^{[10][11][12][13][14]}" or similar. --Ali'i 14:54, 6 June 2008 (UTC)

I've seen it often enough. I think it should be written with ranges, e.g. ^{[2, 10-14]}. That's how it's done in scientific literature, more or less. -- Tim Starling (talk) 15:18, 6 June 2008 (UTC)

Or maybe multiple citations could be placed in one ref tage (I may have seen this somewhere, but now I cannot remember where). Such as "The sky is sometimes not blue.^[4]" then when you click "4", you see 5 or 6 different cites either bulleted or lettered, etc. Although if you wanted to use a specific citation again, the ref name feature wouldn't really work. (less helpful?) Mahalo. --Ali'i 15:30, 6 June 2008 (UTC)

A-ha, an example. I knew I had seen it somewhere. The first ref (number 152 currently) in this section has multiple sources in one ref tag. Mahalo. --Ali'i 15:38, 6 June 2008 (UTC)

Yes, putting multiple sources under one tag is one way to cut down the mess Ali'i, but you still have the problem of articles which cite refs at the end of every sentence or even every phrase. Even if it's only a single number, I find it very disruptive to one's reading. I just don't see why we need these darned brackets [ ] at all, and I'd like to know why we can't just get rid of them. Gatoclass (talk) 17:55, 6 June 2008 (UTC)

I, for one, find the brackets make the references clearer and easier on the eyes. Big "nuggets", as it were, would persist regardless of the omission of brackets as large collections of references which are not grouped will still amount to long lists of reference numbers. While I like the idea of ranges, it is probably unpractical without a major code reworking as we allow reference numbers to be used multiple times in a document, meaning that reference numbers are not necessarily in order. Nihiltres^{t.l} 23:06, 6 June 2008 (UTC)

How do you know they "make the references clearer" when you haven't seen the alternative?

What I do know is that citation numbers in books, ¹ which don't come in brackets, ² don't distract me at all, whereas these hefty bracketed things on wikipedia are very^[2] intrusive^[3] indeed.^[4] So it stands to reason that if one removes the brackets, the text should be more readable and more attractive to look at. Gatoclass (talk) 12:35, 7 June 2008 (UTC)

I agree with everything Nihiltres notes, and only need to add that a range like [10-15] makes [11], [12], [13] and [14] unclickable. Not a big deal perhaps, but worth keeping in mind. -- Fullstop (talk) 05:13, 7 June 2008 (UTC)

The quick¹ brown² fox³ jumped over the lazy dog.

The quick^[5] brown^[6] fox^[7] jumped over the lazy dog.

Which is easier to read? Gatoclass (talk) 12:39, 7 June 2008 (UTC)

If the issue is that the view is cluttered when you have five or so cites, then it is probably a good time to look at the content and how it is referenced. Multiple cites indicate an overzealous editor, or there is a content issue and cites are being improperly used. To use Ali'i's example of Expelled: No Intelligence Allowed, it is my opinion that the bundled use of reference 152 is being used not to back up the statement that "The film was promoted by Christian media", but to illustrate examples where the film was promoted by Christian media— a subtle but crucial difference. --—— Gadget850 (Ed) ^talk - 13:09, 7 June 2008 (UTC)

Excuse me for coming in so late, but the phrase "cite bombing" caught my attention. IMO there are aspects of Wikipedia policy, its implementation and its more fanatical enforcers that can make "cite bombing" almost mandatory, for example:

• In 4X some guy insisted on applying a "notablility" tag to the article, which might have led to the article's deletion. I slapped in about 10 cites for use of the term "4X" to make him go away. Later I realised I could package them all in 1 footnote.
• On Evolution I put in some extra cites to support the point that's it's the majority view among scientists. In this case I couldn't package them in 1 footnote because most were also used elsewhere in the article.
• On Talk:Max Euwe someone recently made a comment that virtually demanded a citation (which would have been the same source) for each sentence in a paragraph.
• Then there are the WP:RS ayatollahs who remove without notice citations that do not satisfy their interpretation of WP:RS or one of its sub-pages. If the sentence / paragraph then gets visited by a deletionist, good-bye.

So editors are driven to "cite bomb" in order to protect content they've spent time researching and writing. Philcha (talk) 15:49, 7 June 2008 (UTC)

Yes, I sympathise, I am not necessarily blaming editors for engaging in it, I am simply noting the tendency over time for an increasing number of cites to be added to articles. I know of one case, for example, where an editor has basically stopped submitting articles to GA because she disagrees with the number of cites she is now expected to add to her articles.

"Cite bombing" seems to be a growing trend and I am simply suggesting a method by which its impact can be reduced. Gatoclass (talk) 17:04, 7 June 2008 (UTC)

And in most cases, it seems like its just other editors trying to be difficult by requesting citations far in excess of what policy actually requires or demanding citations on every sentence even when the citation at the end of the paragraph cites what they demand be sourced. Mr.Z-man 16:22, 9 June 2008 (UTC)

File upload instructions

I noticed the instructions for uploading images don't make it clear that the image needs to be on the editor's computer first. I've noticed several times on the help desk where people have had difficulty uploading fair use images, and have gone "Oh! I didn't know that" when told to download it from their source first; or they have tried to add HTML <img...> tags into articles to externally link images. A clarification to the file upload instructions might reduce this type of help desk query. Astronaut (talk) 16:35, 6 June 2008 (UTC)

It would be better to have the software give a useful error message when someone tries to insert an <img> tag or upload a URL -- the vast majority of users aren't making those mistakes, so we shouldn't clutter up the instructions to deal with the unusual cases. --Carnildo (talk) 19:55, 6 June 2008 (UTC)

The Problem with the Undo Button

You may have noticed that vandals do their work in segments: instead defacing the article to their liking in one edit, they do it in several consecutive edits. This may be because they are sloppy, or because they come up with another idea for defiling the article, or because they edit by sections. Or it may be because they don't understand how Wikipedia works. Or it may be the opposite: they do it because they do know how Wikipedia works.

If a vandal edits in segments, they pretty much make the "undo" button useless. If you undo their most recent edit, all you're doing is going back to another vandalized page. And you can't undo edits before the most recent one. The only option is the clumsier way: clicking history, then choose a version, then click edit, then click save.

What if we made it so that you can undo ALL the edits that a vandal has made in a row? For example, let's say that vandal A vandalizes page B. The a responsible user C reverts his edits. So the vandal does it again, but this time does it in two steps. Where before you would be forced to take the hard way, now you simply click "undo" on the first edit A made after C reverted his first edits.

Easier, yes?-Link (talk) 19:26, 6 June 2008 (UTC)

there already exists ways of doing that, a revert, or, if you have the right to do so, a rollback, both of which do what you're suggesting.--Jac16888 (talk) 19:32, 6 June 2008 (UTC)

As does Twinkle|. --—— Gadget850 (Ed) ^talk - 23:04, 6 June 2008 (UTC)

If there have been no constructive edits since the start of a sequence of vandalism edits, you can click on the latest good version of the article, edit the whole article (but not make any changes), and save it. I believe this is the recommended solution. --A Knight Who Says Ni (talk) 17:38, 7 June 2008 (UTC)

Navigational popups also let you do this, by hovering over a past revision's link and clicking revert. ╟─TreasuryTag (talk ╬ contribs)─╢ 17:39, 7 June 2008 (UTC)

A new namespace/interwiki link for diffs and old versions of pages.

I have no idea if anyone has proposed this before (and if its a good proposal it should go to meta to be put on all Wikimedia projects, actually, why not integrate it into MediaWiki?) but I think this would be an excellent idea for all Wikimedia projects.

When looking around Wikipedia related discussions, you always see this[11] kind of external link linking to part of Wikipedia itself; a previous version of a page. Now I personally think that that is a bit clunky, I mean, using an external link to link into Wikipedia itself? It should be much more smoother.

So I propose that instead of external linking we create a new namespace (or more accurately, an interwiki redirect called maybe diff:, prev: or edit:, I'm not fussed) and then when linking to a diff we use that namespace and the page id instead. Now many people right now may be going huh? and scratching their (hopefully) computer literate heads so I will endeavor to explain how this would work.

NOTE: Throughout this I will be using the diff: namespace/redirect as an example, this can be substituted for whatever you think is the best; its not permanent.

Ok, say X wants to show someone a previous version of a page he made, he could

1. type out (or copy/paste) http://en.wikipedia.org/w/index.php?oldid=3432489 and shove some [ and ] outside it and give it to his friend, or
2. simply type (or copy/paste) [[diff:3432489]] or [[diff:3432489|name of link]]. That would give a direct link to the old page in question without having to type all of the Wikipedia address. It would even work cross project e.g. to meta [[m:diff:3432489]].

Now that is all well and good for just a single id, but what if you want to compare (diff) fuction? Well, I have thought of an idea for that too. All you'd do is something like [[diff:left column id-right column id]], I'm not fussed about what symbol separates the left column id and the right column id. And to help users who would just copy/paste the url of the diff/oldid in question, in the heading of older pages (in this case "Math rock") it would say "Math rock (diff:3432489)" or if your comparing "Math rock (diff:left column id-right column id)".

Now I have a feeling people will say Why do we need this kind of thing?, well I thought of several reasons,

1. when search engines come to Wikipedia and try to index the pages, if they come across an external link they get hit with the robot.txt NOFOLLOW tag (meaning that the robot will not go into that link and check out that file) and;
2. I just think it makes more sense, I mean, when linking to anything else internally we use [[page]], [12] tags have be adopted as the defacto diff linking system, they should follow the conventions that all other internal links follow.
3. It reduces the clutter when listing many links on the same page.

ADITION TO PROPOSAL: Possibly move the diff access link from an index.php paramenter (e.g. /w/index.php?oldid=344&diff=45354) to the wiki space (e.g. /wiki/diff:344-45354).  Atyndall93 | talk  01:12, 8 June 2008 (UTC)

Feel free to change as you wish; I am open to improvements. Thankyou for listening. Happy editing!  Atyndall93 | talk  05:38, 7 June 2008 (UTC)

1. Diffs and oldids are already deliberately excluded from search engine results regardless of whether a link has nofollow attributes by robots.txt which blocks everything in /w/ and by meta tags in the page.
2. Regardless of the form of the link you're still going to have to copy and paste something containing a horrible oldid. I wouldn't object to a template which expands the oldid parameters to a working URL, the code to which could be displayed for copying on the diff page, but the extra bloat on those pages might not be worth the savings in editbox bloat.

That's my opinion. BigBlueFish (talk) 15:47, 7 June 2008 (UTC)

The idea's neat, though in implementation this might be tricky, as it is not only diff id that matters but also oldid, and there are always the special cases. For example, diff=9&oldid=5 shows the difference between revision 5 and revision 9, whereas diff=prev&oldid=5 shows the difference between revision 5 and the previous revision for that page (as revision ids are not contiguous for the same page) with a similar difference for diff=next and I'm not sure how we'd integrate the syntax considering those variables as well. Nihiltres^{t.l} 16:38, 7 June 2008 (UTC)

With my idea diff=9&oldid=5 would be something like [[diff:5-9]] and diff=prev&oldid=5 would be [[diff:prev-5]].  Atyndall93 | talk  01:12, 8 June 2008 (UTC)

Turns out a shorthand is available as {{diff}}. Since search engine indexing is not wanted for oldids, I see no reason to change the URLs; a preconstructed code for the diff template on the diff page itself might be useful if there's demand. BigBlueFish (talk) 17:41, 7 June 2008 (UTC)

That template still uses external linking (with the plainlinks class) though I I think its a bit clunky.  Atyndall93 | talk  01:12, 8 June 2008 (UTC)

I don't have any advice on the technical details of how to do this, but I do agree that something should be done. The current system of entering a whole URL is awkward, and I would prefer to point to a diff using an in-line citation instead of a superscript. --A Knight Who Says Ni (talk) 17:50, 7 June 2008 (UTC)

• It's a nice idea in theory, I suppose, but it'd create a huge trashyard of diff: namespace pages that would never ever be referenced. I think we're up to something like 50 or 60 million total edits so far. How many of these are likely to be referenced? -- Anonymous Dissident^Talk 18:06, 7 June 2008 (UTC)

  The word "namespace" is confusing - the proposer is suggesting something more along the lines of a specialized interwiki that would link to wikipedia diffs, much the way that we have a special interwiki for Google searching. {{Nihiltres|talk|log}} 18:58, 7 June 2008 (UTC)

  Yes, it wouldn't actually create the pages, but it would appear that way.

It sounds good on the surface, but BigBlueFish makes a good point. Which is easier? Copy and pasting a URL or using an interwiki, which would mean copying the oldid and the diff oldid separately? The diff URL also has the context of the page title in it usually. Mr.Z-man 03:49, 8 June 2008 (UTC)

In the proposal I suggested having the title show "Title (wikilink for diff/oldpage)" type thing where the text in the brackets is the relevant wikilink for that diff or old version of a page. E.g. (diff:3493-3433) means that its comparing oldids 3493 and 3433. So you wouldn't have to copy/paste the oldids separately as when viewing a comparison page both are listed in the correct format, so you just copy/paste the stuff listed in the brackets (it could be placed anywhere on the page really). e.g. if you typed [[diff:3493-3433]] you would get that exact comparison. And in reply to the context of the links, the actual page name is irrelevant (if you remove it from the link, the link still works) and if you wanted to show name that link you could say [[diff:3493-3433|oldid of random page]] which has the same level of context as a normal diff because normally a [ ] type link just shows up as [13], if you want to name it you have to type in the name next to the link. You could also have a tooltip appear with the page name when hovering over the diff link.  Atyndall93 | talk  07:32, 8 June 2008 (UTC)

What I mean is, when making a normal diff, I type a bracket, paste the URL, then type whatever text I want to appear, then another bracket. To do it as an interwiki-type link, I have to type 2 brackets, then "diff:", paste in the URL, delete all the parts I don't need, add the hyphen, then the pipe and the text I want to appear. It just seems like a lot of extra work for minimal benefit. What I meant by the page title in context, is that when hovering over a link, I see the full URL of the target in the status bar in my browser. Unless this looks up the title associated with the oldid and adds it to the link when parsing, all I would see is http://en.wikipedia.org/w/index.php?oldid=12345&diff=23456. Mr.Z-man 16:26, 8 June 2008 (UTC)

With my proposal you don't copy the url at all, in the title it says something like "Title of Page (diff:whatever)" so instead of copying the url you copy the text in the brackets and whack and around it, we could even make it so the title says "Title of Page ([[diff:whatever]])" so really all you have to do is pipe the link (and with my first proposal add [[ ]] around it. I would recommend the parser is set to show something like "Page Name (diff:whatever)" in a tooltip, thus keeping it in context. So with my proposal you just have to add two more characters (an extra [ and ]) and remove about a hundred from pasting the url.  Atyndall93 | talk  03:16, 9 June 2008 (UTC)

The title isn't really the main issue I have with it. You still need to get the 2 oldids from somewhere. You have to type them from memory, copy and paste them from the URL, or copy and paste the whole URL and remove everything except the oldids, all of which are more work then just copying and pasting the URL. If the only benefit is that the edit page will be slightly cleaner, I really don't see how this is worth the extra work that would be required. Mr.Z-man 05:41, 9 June 2008 (UTC)

Hmmm, I don't think you understand what I'm trying to say, but thats fine, I sometimes word things incorrectly. The oldids in the exact format they are needed to be in to be linked to (e.g. diff:342094-3234234) are listed in the title of the page so you can just copy paste that stuff instead of the url (and just put double [ around them). I'll see if I can make an example animation or something if I have time.  Atyndall93 | talk  10:49, 9 June 2008 (UTC)

So is the purpose of this to save space in the editbox by changing the length of the string that you copy/paste? In which case, why not put code in the form {{diff|Main Page|204901573|202506579}} on the page? BigBlueFish (talk) 12:04, 9 June 2008 (UTC)

(outdent) The purpose of this is to same space in the edit box, to use [[ ]] style linking; keeping it consistent with the rest of internal links and to stop using external links for posting diffs (as {{diff}} does) as I (and other people) thing that it is clunky etc. If people are for the change, it would be easy enough to implement I think.  Atyndall93 | talk  12:23, 9 June 2008 (UTC) My proposal also includes putting a kind of premade diff link in the title in brackets, for more information check the previous posts.  Atyndall93 | talk  12:25, 9 June 2008 (UTC)

Problem with Special:Prefixindex

Currently, it seems that Special:Prefixindex displays pages beginning with the text you enter, regardless of whether it is a subpage of the page you specified. For example, when you go to Special:Prefixindex/User:Anon, which is the equivalent of specifying User:Anon (no longer exists), you see userpages beginning with "User:Anon," like User:Anon! and mine, User:Anon126. I think this should be changed to show only subpages of the page specified. Anon126  (talk - contribs - commons - commons talk - commons contribs) —Preceding comment was added at 05:41, 7 June 2008 (UTC)

It has always done this. It simply displays pages beginning with the text you enter; restricting it to subpages would prevent uses such as Special:Prefixindex/List of to see all pages beginning with "List of" -- Gurch (talk) 05:50, 7 June 2008 (UTC)

If you want subpages only, just add a / to your query. Algebraist 10:01, 7 June 2008 (UTC)

A database on user's past records: a page to watch for these things

I think that we could improve transparency by making it easier to locate people's records of disruptive (at least in some people's mind) behavior. Requests for Comments on users and other relevant information should be easier to find. Unless they are particularly easy to find besides through searching and I just don't know about it? Now, searching is OK, but it requires some effort and thought, and it is not comprehensive -- a search for Requests for User <user> does not give me other relevant results like Arb decisions Wikiquette alerts ect. I know that many people will be uncomfortable with this idea, but it is for the best. ImpIn | (t - c) 10:56, 7 June 2008 (UTC)

A glance at a user's talk page and their recent contributions is all you need to know about a user. If they are acting disruptively, then their history of disruption will be clear from the talk page. However, most users are good, and bad users can change (especially considering the large contingent of teenage users). On the whole, there is no merit in judging the character of a user unless they are deliberately trying to undermine the project, in which case they should already be banned if there's been any past attention to them. BigBlueFish (talk) 15:35, 7 June 2008 (UTC)

The users talk page should be used within reason. It also should never be read as a rap sheet. True a malicious or 'bad' user will have a talk page propagated with warnings and notices, but also a 'good' or innocent user who gets tapped by a bot (moving or redirecting pages named like Bob Sagot used to trip the fagot warning on a antivandal bot) or runs into an over active twinkle user will have a talk page filled with the same warnings. Users who work with controversial topics, will often have warnings or notices from users who may have agendas. People should always look at specific edits (within the context of the subject space and not just a raw diff) to establish a regular pattern of behavior. --Samuel Pepys (talk) 22:06, 7 June 2008 (UTC)

Also, because of the Assume Good Faith guideline, we tend to have a "forgive and forget" system when it comes to things like this. If we keep "rap sheets" for every user, people may never be able to live down incidents in their past. Mr.Z-man 21:00, 7 June 2008 (UTC)

I expected to hear these kinds of responses, and I don't think they hold water. First, looking at a User's Talk page should not be endorsed as a proxy for a user's record. Disruption notices can be taken off of talk pages, and these notices are often made in error, as noted. For example, I recently got a "warning on 9/11 simply because the editors who think they own the article didn't bother to carefully read my edit or its references (they cited conspiracy theory; there was no such thing). People who are attempting to judge a user's character on the Talk page need to be strongly reminded of the problems with that approach. Looking at a user's past contributions is terribly time-consuming and inexact; many users use bots to pad themselves with thousands of trivial edits, which are difficult to sift through. Lastly, I don't have time to keep close watch on Requests for Admin and Requests for Comment User; if I could watchlist a page where these are posted, it would make life much easier for me. I worry that Wikipedia is segregated into groups who perform certain functions: some patrol AfD, some patrol RfA, ect., but when you have a system like that you don't necessarily get input from the most relevant people. There are lots of users for whom I would want to be immediately notified if a Requests for Admin or a Requests for Comment came up, but as it stands, I currently only have a small chance of finding that out, since I can't watchlist these people's talk pages, and don't have want to watchlist RfA since most of the people I do not have time to investigate and comment on. And I don't think that "assume good faith" means that we should forget past indiscretions. Assume it, sure, but if it has been tested, people should be allowed to easily find that out. There needs to be accountability. Right now we seem to rely upon the memory of individual users to keep people in line, and I don't think that's sustainable. ImpIn | (t - c) 23:57, 7 June 2008 (UTC)

Why should you expect there to be no mention of a user's RFA or RFCU on their talk page? If a user is sufficiently undisruptive that it's not even worth your while watching their talk page then frankly that user has the right to edit without being stalked. If the said user runs into trouble, the users who handle the situation are perfectly capable of finding information about past RFAs and RFCUs and any prior warnings, with due attention to the severity and/or faith in which they were solicited. Wikipedia already has a channel for monitoring those whose good faith may no longer always be assumed. BigBlueFish (talk) 12:22, 9 June 2008 (UTC)

Edit this page versus add new section

The sensible way to edit a large, oft frequented discussion page is by clicking on 'new section' or the 'edit' link next to the section of interest. Otherwise, one must search for the relevant section within the edit window and deal with the horror of edit-conflicts. Currently on pages like the Science Reference desk et al., the 'edit this page' link is bold and the 'new section' link is regular, leading to me accidentally being drawn to the bold link when I want the regular one. Indeed, I imagine few people ever need the 'edit this page' button on the reference desks. I suggest that the 'new section' link is made bold and the 'edit this page' link is made regular, so that people are drawn to what is probably the correct link out of the two. ----Seans Potato Business 17:29, 7 June 2008 (UTC)

It sounds sensible, but... Can this be done for a single page? Waltham, The Duke of 20:13, 7 June 2008 (UTC)

How about doing it for all talk pages and pages with __NEWSECTIONLINK__ on them? – FISDOF9 23:54, 7 June 2008 (UTC)

Addition to 'this page in other languages'

When looking up a subject, the site shows a box in the bottom left with other languages in which the article is available. If you're looking for every single bit of information you can get, and you can read multiple languages (I, for instance, took English, German and French in highschool, and thus have little trouble reading most European languages) it would be useful if aforementioned box would show the size of an article. Simple example: I'm looking for information on the German Sicherheitsdienst. I first read the Dutch article and wonder if the article in other languages has more information in it. The box lists the articles as follows: Dutch - 200 words, German - 300 words, English - 100 words,

--Max, 81.69.110.161 (talk) 23:56, 7 June 2008 (UTC)

Word count would be difficult because of the intricacies of wikitext and templates, but something like WP:POPUPS for interwiki links (if popups doesn't already work for interwikis) might be an interesting idea for a user script. Mr.Z-man 03:51, 8 June 2008 (UTC)

Improvising on Random article

Dear Sir/m'am, This is with respect to a very good facility provided by Wiki Side bar in Main site i.e. The Random article. During my use of the aforementioned I have noted a tendency of the "Randomiser" to land onto page which I myself ,per se ,have no interest in .These include subjects like place names and Counties and Schools. I propose a facility for the registered and frequent user to be able to select a range , not too specific, of subjects that interests that particular PERSON. This may be recorded as a javaBit next to the "Random article" tag. A Maximum of 6 to 7 (with option of choosing 2 not more), with memory facility(ie The Ability to retain the choices in next LOGIN would be optimal IMHO. I do not know how articles are indexed in Wiki <myself not trained in Computers>.However as in such cases the numbers of the Key index pertaining to A SPECIFIC ARTICLE will have a correlation w.r.t. the TAG that it holds (History , Natural Science , Politics , Psychology , Fine Arts , linguistics etc.) and the same may be used here, if POSSIBLE.

I hope due consideration may be given to this thought.

I remain,

Yours Sincerely

ChimesM --Chimesmonster (talk) 06:24, 8 June 2008 (UTC)

Creation of New Negotiation Board in the Dispute Resolution Process

I have noticed that there is a current hole in the negotiation step of DR that none of the current processes cover. I would like to propose that a new board be created for disputes which range over multiple articles but which don’t require the intervention of administrators and in which both parties are civil. Most of these types of threads get posted at ANI even though it is specifically mentioned in the ANI header that ANI is not part of the DR process. RFC works great for a single article but when there is the same dispute on multiple articles it falls outside the scope of RFC. The only processes that are currently set up to handle such a thing that are part of the DR process is Wikiquette alerts and that only applies if a party is uncivil. To my understanding ANI is mainly to report abuse that requires administer intervention that is too complex for AIV but in which there is no real dispute. All you have to do is take a quick look at ANI to realize that even though there is a notice there that specifically says its not part of DR people ignore that and post disputes there anyways. If we are not to create a new board to deal with this type of dispute then I think we should consider adding ANI to the dispute resolution process as that is what is happening anyways. --Nn123645 (talk) 14:01, 8 June 2008 (UTC)

Liberapedia

May I propose for creation of an external link template which will link to that article in Liberapedia? Otolemur crassicaudatus (talk) 18:12, 8 June 2008 (UTC)

From a quick glance at that site I don't see much benefit of creating a link template. Garion96 (talk) 18:16, 8 June 2008 (UTC)

Though it is helpful, liberapedia is not exactly joke site like Uncyclopedia. It documents real information, and in many cases with references. Otolemur crassicaudatus (talk) 18:20, 8 June 2008 (UTC)

It is not by any standards a reliable source. If it can be used by editors as a research tool to locate adequate sources then great, but Wikipedia does not have a large-scale need to link to this site. Not even massively referenced sites like the BBC News have a link template. BigBlueFish (talk) 12:27, 9 June 2008 (UTC)

Do we have templates for other non-Wikipedia-related sites? Corvus cornix_talk 17:01, 9 June 2008 (UTC)

SIZE guidelines

Please see the proposal at Wikipedia talk:Article size to update the article size guidelines, in particular to use industry standard word count instead of character count. Oakwillow (talk) 18:27, 8 June 2008 (UTC)

Restrict the "move subpages" feature to admins

This idea has been bounced around the noticeboards ever since the "move subpages" checkbox, sometimes referred to as the "recursive move" feature, was added to MediaWiki in rev:33565. The ability to move a page, its talk page and up to 100 subpages all in one action, has been quickly seized upon by a number of pagemove vandals (see 1, 2, 3, 4). With careful choice of targets, the feature enables a vandal to move up to 800 pages before hitting the pagemove throttle, which is supposed to limit non-admin users to 8 moves/min. There has been discussion in various places (1, 2) about restricting this feature to administrators only, and in rev:36038 Simetrical added the technical means to do this. What do we think? Happy‑melon 19:54, 8 June 2008 (UTC)

Restrict it to admins. The feature is virtually useless here (it was added at the request of Wikibooks, not Wikipedia) - the only people who are going to have a need to move subpages on a regular basis are bureaucrats when changing usernames (and they will be unaffected by a change as they are all admins). Hut 8.5 20:04, 8 June 2008 (UTC)

Restrict it to admins, clearly. There are way too few cases where it would be useful for individual users to need this here. —Simetrical (talk • contribs) 21:16, 8 June 2008 (UTC)

Restrict it to admins, the uses here are so few (the only thing I can think of would be moving an article where the talk page has archives, which doesn't happen often), there's no need for almost all users to have this. Mr.Z-man 23:03, 8 June 2008 (UTC)

Support the restriction--I found it hard to believe this was available generally. If Wikibooks wants to use it more generally, they can do so. DGG (talk) 04:46, 9 June 2008 (UTC)

Too easily abused, much harder to revert than to do. Restrict it to admins, and possibly bots. _{1 != 2} 23:05, 8 June 2008 (UTC)

Support I've moved plenty of pages, but never needed to simultaneously move a subpage at the same time (sometimes I'm had to move an article talk page archive, but that's no big deal). I suggest restrict to admins. AndrewRT(Talk) 00:03, 9 June 2008 (UTC)

• Support restricting to admins, little or no utility to non-admins, tremendous facilitation of hard-to-clean-up vandalism otherwise. NawlinWiki (talk) 03:38, 9 June 2008 (UTC)

• Support I didn't even know the feature existed, which clears up the mystery about why my talk page and archives were moved in very quick succession. :) But it's clear that vandals do know about it, and exploit it (see the diffs from Happy-Melon). If there are uncontroversial subpage moves, they can be requested at WP:RM#Uncontroversial proposals. This would happen rarely, very rarely most likely, so restricting it to vandals(whoops, I meant) admins seems to be the best way. PeterSymonds (talk) 11:05, 9 June 2008 (UTC)
• Support. See also discussion at WP:VPT#Recursive page moves (rev:33565) is a great tool for vandals. —Wknight94 (talk) 11:36, 9 June 2008 (UTC)
• Support. If there is a page with multiple subpages that legitimately need moving, requests can just be added at WP:RM. Seraphim♥Whipp 11:49, 9 June 2008 (UTC)

• Support it looks like it is being used more often for vandalism than for anything useful. Occasionally there are good reasons for subpages to be moved, but not very often, and it would still be possible, only it would take more time, if this was restricted. --Snigbrook ^(talk) 11:52, 9 June 2008 (UTC)
• Support and urge the devs to deploy this restriction as quickly as practical. There is no compelling reason for non-admins to have this tool and the use for vandalism is a "clear and present danger" as they say. Gwernol 12:16, 9 June 2008 (UTC)
• Support, though I want to clarify that this would only apply to the recursive "move subpages" function; non-admin users could move individual subpages in the normal way, just as they always have been able to. If there is a need for some non-admin use (renaming a page with lots of talk page archives, or what-have-you), then WP:RPM would be the appropriate forum - and even then, I imagine the response would be to do it manually or send a bot to do it. UltraExactZZ ^Claims ~ Evidence 12:20, 9 June 2008 (UTC)
• Support. This feature has a clear pattern of past abuse. The rare times on this project when there is a legitimate need to move a hierarchy of subpages can be handled by Wikipedia:Requested moves. --Allen3 ^talk 12:28, 9 June 2008 (UTC)
• Submitted as bug 14482http://bugzilla.wikimedia.org/show_bug.cgi?id=14482; but comments are still welcome, as the developers will read this thread before making any changes. Happy‑melon 12:39, 9 June 2008 (UTC)
• Support - please make this change ASAP. Neıl 龱 12:47, 9 June 2008 (UTC)
• Support, too much vandalism. MaxSem^{(Han shot first!)} 13:55, 9 June 2008 (UTC)
• Support, definitely - I've just blocked another vandal who has found this feature useful. :-) Stwalkerster [ talk ] 13:58, 9 June 2008 (UTC)
• Support just to help to demonstrate to the devs that there's a consensus for this. --ais523 14:05, 9 June 2008 (UTC)
• Strong support and move to snowball close as endorsed. It takes way too much work to cleanup after this type of vandalism. Users requiring recursive moves can apply to WP:RM. (oops, just noticed this was already bugzilla'd - support nonetheless) xenocidic (talk) 14:08, 9 June 2008 (UTC)