Wikipedia:Village pump (proposals)/Archive 28

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)

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)

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)

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 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)

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 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 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,  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)


 * 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.
 * 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 oldid of random page which has the same level of context as a normal diff because normally a [ ] type link just shows up as, 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 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)

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)

Innovation
My name is Jay Shah and I would like to share a new innovative game (or rather say a challenge) that can be easily played on WIKIPEDIA.I call this as "wikiLINKIA challenge" or simply "wikiLINKIA".It goes like this that a player is given a particular article and he will be given a target article and the player has to reach the target article using minimum links provided right from the given in the article.It may seem very difficult to understand just from one sentence and hence let's consider this example: suppose a user is given the article of RMS TITANIC and his target is WORLD TRADE CENTER.So the user may link his target via NEW YORK CITY as RMS TITANIC was bound for NEW YORK CITY and finally to his target since WORLD TRADE CENTER is located in NEW YORK CITY.I hope I have roughly put on the concept of my game to an image.This example was just a basic one to justify my game.This game can be more exciting since we can restrict either the minimum links clicked to reach the target and the shortest link pathway to the target.I have been playing this game by my own self and even trained my younger sister to play it and now she says she loves this game as it is exciting, interesting.Me and my sister would play side by side on a particular wikiLINKIA challenge and our game would last from five minutes to once even a week and the winner with minimum number of link pathways would be the wikiLINKIA champion.And we would feel very proud to be associated WIKIPEDIA or BEING called as a champion.My DAD who had once tried this game also said that this game can certainly help one to envisage one's vision and tests one's wit and association power to link one thing with the other.Alas I would say that this can be fun and a high level challenge which can be played on well established platform of WIKIPEDIA articles.There is much more to discuss about this game.I will even try my level best to submit the video demonstration as soon as possible.So members please look forward onto this. —Preceding unsigned comment added by EnSYS (talk • contribs) 17:02, 9 June 2008 (UTC)
 * Welcome to Wikipedia! You might be interested in Six degrees of Wikipedia, in particular the website that it links to, Omnipelagos. BigBlueFish (talk) 21:14, 9 June 2008 (UTC)


 * ??? -  Ca ri bb e a  n ~ H. Q.  21:17, 9 June 2008 (UTC)


 * I... dislike... capitals... Waltham, The Duke of 21:43, 9 June 2008 (UTC)

New proposal for Discography sections at WikiProject Musicians
Please take a look at this proposal and express your support or objections. Keep in mind we currently have no guidelines for Discography sections whatsoever, so this would at least be a start. Kaldari (talk) 18:15, 9 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)
 * A good, good many, in fact; see Category:External link templates, which happens also to note (or at least to purport to note; I don't know that criterion two, in particular, is one that we generally follow, and I don't know that it, to the extent it fails to distinguish between those sites that are linked to as sources for substanive material, to which RS would generally apply, and those sites that are linked to merely for their being prominent sites that comment, notably, on a given topic, should be one that we follow) the criteria that the community have generally used to determine whether an external link merits a template, as might be relevant here. Joe 06:45, 10 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 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 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</b> 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. <font face="Broadway">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. <font color="Red">1 <font color="Green"> !=  <font color="Red">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. 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.  —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&hearts;  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 Requested moves.  --Allen3 talk 12:28, 9 June 2008 (UTC)
 * Submitted as ; but comments are still welcome, as the developers will read this thread before making any changes. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 12:39, 9 June 2008 (UTC)
 * Support - please make this change ASAP. <u style="text-decoration:none;font:100% cursive;color:#600">Neıl  <u style="text-decoration:none;color:#226"><B>龱</B>  12:47, 9 June 2008 (UTC)
 * Support, too much vandalism. Max S em(Han shot first!) 13:55, 9 June 2008 (UTC)
 * Support, definitely - I've just blocked another vandal who has found this feature useful. :-) <font face="Verdana"> 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)


 * Indeed if someone who knows them can contact the devs and let them know about this clear consensus, then we can close this little exploit. <font color="Red">1 <font color="Green"> !=  <font color="Red">2  14:10, 9 June 2008 (UTC)
 * Daniel has implimented a little hack into the Common css to remove the checkmark until this issue is cleared up.— Ryūlóng ( 竜龙 ) 14:13, 9 June 2008 (UTC)
 * .js, even, and don't go spreading the fact around or else someone will drop the bean jar :) Daniel (talk) 14:24, 9 June 2008 (UTC)


 * Support will certainly be of benefit when clearing up vandalism. -- Anonymous Dissident  Talk 14:59, 9 June 2008 (UTC)
 * Support, too powerful. It's possible to revert when the main source page has not been modified after the move, the subpages whose source haven't been modified are moved over redirect. But it's not possible to reverse a move like this when the main source page has been modified. So each subpage has to moved back individually. And even if the source page is not modified, the amount of work and the time needed to cleanup this kind of vandalism is too high compared to the benefit. <font color="#000080">Cena <font color="#1560bd">rium <font color="#000090"> (talk) 15:05, 9 June 2008 (UTC)
 * Support I didn't even know this feature existed. The uses of this are rare (the only instances that springs to mind is a WikiProject that renames itself or moving entire talk page archives but these are still rare situations) and can easily be requested elsewhere. This feature is too powerful to let just anyone use. -- .: Alex  :.  15:21, 9 June 2008 (UTC)
 * Support - After cleaning up in the wake of a large number of vandalistic page moves, I was thinking that move subpages should be locked down because it has the potential to cause a lot of damage that cannot be reverted as easily as it was caused. <font color="1E90FF">Chris <font color="4169E1">lk02 <font color="2A52BE">Chris Kreider 15:25, 9 June 2008 (UTC)
 * Support - I'd personally support pagemoves in their entirety being admin-only, but this is a good start. No need for people to do mass moves like this. Tony Fox (arf!) 16:16, 9 June 2008 (UTC)
 * Support. I can't imagine that this feature would be used very much, and if it was needed, it is very easy to ask an admin to do it for you. Or, if there were just a few subpages (less than 8), a non-admin could just move them manually. J.delanoy <sup style="color:red;">gabs <sub style="color:blue;">adds  16:36, 9 June 2008 (UTC)
 * As to how you contact the devs, when the non-admin rollback throttle removal thingy was discussed, I spammed messaged the devs on IRC, but I can't remember which channel I used. J.delanoy <sup style="color:red;">gabs <sub style="color:blue;">adds  16:48, 9 June 2008 (UTC)
 * Support - the possibility that this has for abuse and vandalism outweighs the its benefits. It's easy enough to ask an admin to move subpages at once if required. <small style="font:bold 12px Trebuchet MS;display:inline;padding:1px 6px 2px 7px;"><font color="#630">RichardΩ612  Ɣ ɸ 16:46, June 9, 2008 (UTC)
 * Strong support - I have personally had to clean up messes made by this feature and it is not fun. Tiptoety  talk 18:25, 9 June 2008 (UTC)
 * Support, evidently.  Sandstein   20:36, 9 June 2008 (UTC)
 * UPDATE: This proposal has (apparently) been passed for now. —Wknight94 (talk) 21:16, 9 June 2008 (UTC)
 * I support this: at the moment, I've seen nothing but abuse from this feature, and limiting it to admins should eliminate that abuse. Acalamari 23:43, 9 June 2008 (UTC)
 * Support Looks like it's been restricted for the moment, but I'd like to voice my support for enabling it permanently. It's a reduction of editor abilities that has a positive cost/benefit breakdown between allowing people to edit and protecting the project from vandalism. EVula // talk // &#9775;  // 23:47, 9 June 2008 (UTC)
 * Oppose, I'm not an admin and I find this could be useful. If we can restrict editing of pages to established users, surely we can restrict moving subpages to established users. Failing that, we should allow for mass deletions of pointless subpages. --M1ss1ontomars2k4 (talk) 03:00, 10 June 2008 (UTC)
 * We don't restrict editing to established users, we can restrict it to autoconfirmed users, which is users whose accounts are 4 days old and have 10 edits, which was also the same restriction that was originally used by this feature. <font face="Broadway">Mr.Z-man 03:43, 10 June 2008 (UTC)
 * So...so disappointed that good features that help editors whenever a page move is performed, has to be taken away from those who do not abuse it. — M o e   ε  03:30, 10 June 2008 (UTC)
 * How often do you need to move a page with subpages? <font face="Broadway">Mr.Z-man 03:43, 10 June 2008 (UTC)
 * Well, if there was a situation where a article and its talk page (with archives) needed to be moved, the feature would help move the archives to the new basename. Other than that, moving subpages of your own userspace, which is what I did about 5 days ago, the tool was very helpful to me. Other than that..there aren't many more situations where subpages are used on Wikipedia. The only other thing I can think of is if something like WP:AN (for example) was moved with consensus, and archives were moved with it. That feature might do some good, but the with the limited number of pages like that, the chances of a normal user doing it are pretty slim. — M o e   ε  03:53, 10 June 2008 (UTC)
 * I don't think it's technically possible to move WP:AN. There are several hundred subpages.— Ryūlóng ( 竜龙 ) 04:50, 10 June 2008 (UTC)
 * True, I meant that as an example, but you know what I mean. All that aside, something I would actually support is, instead of restricting the 'move subpages' feature to admins, restricting the number of pages moves that could be performed with a single click. Like if the page has 4 or more sub-pages, an administrator or higher only has access to mass move that many sub-pages, but when its 3 or less, a normal user can use the feature. This would certianly reduce in the number of incidents with abuse of the tool, if abuse was to occur, the damage would be minimal, and the feature would still be available to those like myself who use it on a small-scale. — M o e   ε  06:17, 10 June 2008 (UTC)
 * Support - maybe make it a 'trusted', userrights option similar to the AccountCreator option. Pagemove vandalism can be just overwhelming at times - A l is o n  ❤ 09:53, 10 June 2008 (UTC)
 * Oppose useful feature, disappointing discussion. Guest9999 (talk) 10:45, 10 June 2008 (UTC)

non-copyrighted restricted images
I have opened the discussion on non-copyrighted restricted materials again at the Non-free content talk page. In the past this issue has annoyed me severely, and I was told that we would take care of it after the issues with copyrighted materials had been dealt with. Well that is all done now and as such I think the time has come to fix this unclarity. According to current Foundation policy, materials like images need to be "free for usage", but many non-copyrighted materials are not (trademarked logos, military insignia, flags etc etc.). There seems to be a general "exception" for these materials, but there is no real basis for this in the Foundation resolution or our Exemption Doctrine Policy. The General Disclaimer speaks about trademarks in general (including textual trademarks in our articles), but I do no see how this exempts the images from the Free Content Licenses as defined by the "Definition of Free Cultural Works", as adopted by the Foundation. It is my hope, the discussion will be our start to getting this sorted out once and for all. --TheDJ (talk • contribs) 11:20, 10 June 2008 (UTC)

Easier access to Special:Listusers
It could be that I'm just missing this, but I'm looking for a way to very easily and quickly check the rights of any user. I'm finding this more and more necessary as more user groups are created (Accountcreator, IPexempt...) - so what I'm imagining is either a link in the toolbox from a user or user talk page, or just the user's listuser entry at the top of their log page. Unless, of course, there's already some easy way to access this. <span style="border:2px solid #20406F;padding:1px 3px;font-family:Verdana,sans-serif;"><font color="#20406F">Alex Muller  11:33, 10 June 2008 (UTC)
 * This can be easily done with JavaScript, unless you think this should be in everyone's toolbox. Algebraist 11:37, 10 June 2008 (UTC)
 * Oh, really? In that case, would you or someone else mind sharing how... my Javascript-foo isn't what it should be ;) <span style="border:2px solid #20406F;padding:1px 3px;font-family:Verdana,sans-serif;"><font color="#20406F">Alex Muller  11:44, 10 June 2008 (UTC)

This will add it to the toolbox when you view somebody's user or user talk page. Of course adding it elsewhere would require more code. addOnloadHook(function{ if(wgCanonicalNamespace[0] != 'U') return; t = 'Userrights';  url = wgScript + '?title=Special:Listusers&limit=1&username=' + wgTitle.replace(/\/.*$/,'');  r = document.createElement('li'); a = document.createElement("a");  a.setAttribute("title", t); a.setAttribute("href", url); a.innerHTML = t;  r.setAttribute('id', 't-' + t); r.appendChild(a);  u = document.getElementById('t-upload');  u.parentNode.insertBefore(r, u);   }); — CharlotteWebb 15:43, 10 June 2008 (UTC)
 * Many thanks Charlotte, that's perfect - really, exactly what I wanted... it's going to be incredibly useful for me at least, and hopefully others as well. Again, thank you :) <span style="border:2px solid #20406F;padding:1px 3px;font-family:Verdana,sans-serif;"><font color="#20406F">Alex Muller  17:08, 10 June 2008 (UTC)
 * Well I just realized it will fail for users whose name contains "&" but I think it will work for all other allowable names. Also I chose to put it before the "upload" link because this link will always be present. Trying to put it above the "block" link (or the "contributions" link, etc.) will cause an error if you are on the page of a non-existing user. I think this will only be a noticeable problem if you rely on other scripts to load properly after this one, but adding <tt>if(u) </tt> to the beginning of the last line would fix it. — CharlotteWebb 17:52, 10 June 2008 (UTC)
 * Ah, but it will still fail (albeit without an error) for anybody who doesn't have a "block" button and tries to copy your version. — CharlotteWebb 17:58, 10 June 2008 (UTC)
 * I have a sysop detector that Splarka wrote a bit ago. It changes the user page tab to read (sysop) when the user is a sysop. (Even when the sysop doesn't have a user page.) You can import it from User:Splarka/sysopdectector.js. --MZMcBride (talk) 18:22, 10 June 2008 (UTC)
 * Maybe I should adapt that to appear in page history, recentchanges, watchlist, etc. as a big red conspicuous "do not revert" warning. Seriously though I did once try to do something with "XMLHttpRequest" on one of my own sites but it kept getting refused by Firefox as a security problem (I don't remember the actual error message). — CharlotteWebb 18:50, 10 June 2008 (UTC)


 * Simpler (and works for all usernames):


 * This code adds the link to the bottom of the toolbox. If you want it placed earlier, you need to pass additional parameters to   — see the comments for that function in wikibits.js.  —Ilmari Karonen (talk) 18:29, 10 June 2008 (UTC)
 * Or even simpler:


 * :-) —Ilmari Karonen (talk) 18:33, 10 June 2008 (UTC)
 * Ah I wasn't sure if <tt>split</tt> would work in the more common case where there is nowhere to split, hence the unsightly regex. — CharlotteWebb 18:50, 10 June 2008 (UTC)

Another really good script that I use is User:Ais523 non-admin/adminrights.js which lightly highlights the names of any sysop on wherever their name appears. This is good because it saves you the step of having to click buttons to see if they're a sysop. I'd recommend at least a try. -- penubag  (talk) 03:40, 11 June 2008 (UTC)

Use the Geotag Icon in association with coordinates
Wikipedia currently use a little globe icon to indicate GPS coordinates e.g. here:

http://en.wikipedia.org/wiki/Empire_State_Building

The globe currently in use is indistinct and not location-specific, since globes are used in a variety of other contexts. The community-designed and free Geotag Icon has been created expressly for better illumination of geodata:

http://www.geotagicons.com

It is appropriate for geotagging using any format (meta data, microformats, EXIF-GPS, etc) and has been added to the microformats.org icons page:

http://microformats.org/wiki/icons

The information on the Project website is comprehensive and self-explanatory, but if I can answer any questions or be of other assistance please don't hesitate to get in touch.

Project Coordinator: Bruce McKenzie The Home of the Geotag Icon Project www.geotagicons.com —Preceding unsigned comment added by 85.152.18.129 (talk) 14:00, 11 June 2008 (UTC)

What should be done with Articles requested for more than a year?
Should it be moved to Articles requested for more than two years? Should it be converted to a category along with Requested articles? Something else entirely? All comments are welcome at Wikipedia_talk:Articles_requested_for_more_than_a_year. shoy 15:08, 11 June 2008 (UTC)

en.wikipedia.mobi
When accessing Wikipedia from a cell phone, it takes several minutes to scroll down to the log in button and uploading images is nearly impossible (if it's not impossible). Wouldn't it be great if there was a mobile version of Wikipedia so that people could more easily upload images, edit pages, and read articles? Now I realize that the cell phone user would not have much reason to edit pages from a cell phone (unless they were just fixing a spelling error, or, at worst, vandalizing), but I think it would be great if there was a mobile version of Wikipedia for uploading images, possibly including them in articles, and of course, reading articles. As far as uploading images, another possible venue would be to create a short code so that images could be sent as a picture message so that cell phone pictures could be used in articles. I know a work around for this problem: I send cell phone pictures to my email address and then upload them from my computer, but a lot of people, probably including many experienced, good faith Wikipedia contributers, don't know how to do this, and it's not always convenient. <font color="red" face="Comic Sans MS">GO-PCHS-NJROTC <font color="black" face="Comic Sans MS">(Messages) 17:37, 11 June 2008 (UTC)
 * See WAP access for a bunch of options, and this current thread at Talk:Main Page. Might help? -- Quiddity (talk) 19:28, 11 June 2008 (UTC)

Automatic generation of reference information from URL
Providing references is one of the most important tasks of any editor, but it is also one of the most challenging (I think) for new users. It requires technical knowledge of Template:Cite and the manual entering of bibliographic information. However, at least for online references (which [probably make up the majority of references) it seems like it should be possible to automatically generate this information once you have the URL of a site because most major news sites are consistent in the tags and formatting they use for different sections of articles (author, title, etc.). Therefore, it should be possible to create some sort of database of these sites and write a script that would put all the correct reference information into the footnote just given the URL. Would this in fact be feasible, and would anyone be interested in helping to achieve it? Theshibboleth (talk) 01:48, 11 June 2008 (UTC)
 * Not a solution but, ottobib creates nice templates using ISBNs. And I use the copyurlplus firefox extension to copy url+titles to clipboard - this might be partially adaptable on a personal level.
 * Your suggestion sounds great, but I would guess requires a more fully developed semantic web (or a large manually created database to draw from) for anything automagical to work.
 * A text entry form that spits out the cite template might be more within reach? -- Quiddity (talk) 02:02, 11 June 2008 (UTC)


 * I'm not sure that it is as out-of-reach as it might seem though... even though a lot of sites don't use semantically meaningful formatting, they still style titles, bylines, etc. a certain way, and a script could use those as cues of some sort... I know almost nothing about scripting though, but perhaps I could try to figure out how to do this for one or two sites... I could at least probably figure out what the cues might be.... Theshibboleth (talk) 02:10, 11 June 2008 (UTC)
 * So for Yahoo! News, the title is at HTML:BODY:DIV ynwrap:DIV yncont:DIV ynbody:DIV ynstory:H1. The author is at ...DIV ynstory:DIV ynmain:DIV storybody:DIV storyhdr:p:SPAN, and the date at ...p:EM recenttimedate. This is the article I'm basing this on - http://news.yahoo.com/s/ap/sudan_plane_crash;_ylt=Ag5praSYT_HOHGzqB4ORgpus0NUE. Theshibboleth (talk) 02:23, 11 June 2008 (UTC)

You're probably aware of these, for journal articles this can often be done. Check the Tools on WP:CITE. I like Verisimilus' Google Scholar search, and use it a fair bit. Also check out the Bibtex to Wikitext converter -- most journals will allow you to export the citation in Bibtext. ImpIn | (t - c) 09:40, 11 June 2008 (UTC)


 * I use Zotero. I also maintain bibliographies in my userspace to share with other editors; I can do fact checks from my library as requested.  See also:  WikiProject Fact and Reference Check and WikiProject Resource Exchange.  --——  Gadget850 (Ed)  <sup style="color:darkblue;">talk  -  19:13, 12 June 2008 (UTC)

Requests for reverts
This is an idea I raise due to WP:3RR. On the Batman Begins, an IP added false information based on speculation in a cited article and also added a redundant url. I removed this and explained very nicely in my edit summary, but he/she just reverted it and now the false information is sitting in the article waiting for another regular editor to undo it. So my proposal is for page requesting another editor or administrator to undo something when someone is clearly not going to respond in a discussion, speeding up the process. Alientraveller (talk) 19:27, 12 June 2008 (UTC)
 * Encouraging people to bypass 3RR by proxy is not a good idea. If someone refuses to discuss their edits then they can be blocked for disruptive editing. Revert warring doesn't solve anything. <font face="Broadway">Mr.Z-man 19:54, 12 June 2008 (UTC)
 * I think the particular dispute you mention was resolvable anyway; I made an edit in that regard. I otherwise agree with User:Mr.Z-man, the only cases I can think of where lots of reverts might be really needed that discussion wouldn't solve would be covered by the anti-vandalism procedures.  It's OK if the article stays at the wrong version for a bit while the disagreeing editors discuss the issue. -- tiny plastic Grey Knight   &#x2296;  20:11, 12 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 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. <font face="Broadway">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)


 * What's to stop someone from deleting the RfCU on their talk page? ImpIn | (t - c) 09:27, 11 June 2008 (UTC)


 * "a User's Talk page should not be endorsed as a proxy for a user's record" - I say that's a good thing. Even the worst users are quite capable of reforming (User:Poetlister). Most users screw up a few times when they are brand new. Why should we create a permanent record of that? If someone was in an edit war in March of 2007 and wasn't blocked for it, should that affect anything now? "Right now we seem to rely upon the memory of individual users to keep people in line" - You really need to read WP:AGF if you think every user needs to be "kept in line." You want a page where you can monitor RFC/U's and RFA's, but you don't want to watchlist WP:RFC/U or WP:RFA? That's just silly. <font face="Broadway">Mr.Z-man 15:53, 13 June 2008 (UTC)


 * Most long term problem users simply blank warnings, policy seems to accept that. However I do see the benefit in having a record that some user has been warned about personal attacks 17 times in the past, and talk pages simply do not provide that function like it should. <font color="Red">1 <font color="Green"> !=  <font color="Red">2  15:56, 13 June 2008 (UTC)

Make 'new section' bold and 'edit this page' regular
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? – <font color="90EE90">F ISDOF <font color="D3D3D3">9 23:54, 7 June 2008 (UTC)


 * That might be a good idea. Pity that we seem to have failed to receive enough attention here. I had forgotten about this myself for almost a week... Stupid Pump. Waltham, The Duke of 00:30, 14 June 2008 (UTC)

Mascot
I propose that Wikipedia should have a mascot:Wikipe-tan. <em style="font-family:Comic Sans MS;color:DarkBlue">StewieGriffin!  &bull; Talk Sign 17:51, 12 June 2008 (UTC)
 * Mascot. We don't have an official one, but Wikipe-tan is already our unofficial mascot. EVula // talk // &#9775;  // 18:14, 12 June 2008 (UTC)
 * This should be the official Wikipedia mascot. -- Coasttocoast (talk) 21:46, 13 June 2008 (UTC)

Proposal to amend the naming convention for numbers
I propose to amend naming conventions for numbers and years, and also to redirect 911 to 911 (disambiguation) and rename the main article as 911 (year). (Note that the consensus against on Talk:911, while overwhelming, is 2 years old.) Please discuss here and here. 69.140.152.55 (talk) 13:22, 9 June 2008 (UTC)
 * Ignoring that this would play the dickens with WP:DATE format, do you also propose some objective way to decide which stand-alone numbers should or should not point to a year, or is this an isolated gut feeling about "911"? — CharlotteWebb 15:49, 10 June 2008 (UTC)


 * It appears, from discussion both at Talk:911 and Wikipedia talk:naming conventions, that the intention of this proposal was specifically to allow the moving of the year article from 911, in order to then allow the emergency telephone number article to be moved to this name. Andrewa (talk) 17:34, 14 June 2008 (UTC)


 * There have now been two proposals to move 911, both rejected.


 * The first was rejected, at least in part, because of policy opposing the move. In the light of this, the second foreshadowed this proposed change in policy.


 * I suggest that we can therefore now regard this policy proposal as also rejected. Andrewa (talk) 17:34, 14 June 2008 (UTC)

Wiki-Genealogy Project Proposal
Hello. My name is Ziang Song, one of my fiends and I have a idea to make wiki more encyclopedic. We have held the idea to build a wonderful module into wiki for a long time. Now we would like to share our new idea with you.

We would like to add a Genealogy or Family Tree module into wiki, in which, anything having relationships can be found here. No matter whether it is the genealogy created by authors in the novel or the actually family tree in our daily life, wiki-genealogy will be a powerful tool to showing every thing in a relationship. We can make it fancy by showing entites in graphs or trees or the similar.

Wiki-genealogy will contribute to the scholars who are studying people relationship in different history as well as novel fans finding it easy to understand personal relationship when they are reading a famous novel...

Definitely wiki-genealogy is a free encyclopedia and can be maintained by people in the world. We can also handle privacy or the similar by some technique which we can discuss later.

If you think it is possible for us to join wiki to do this, please let we know. If not, please also let we know, anyway, comparing notes is happy time for us to learning new things, and we will definitely try our idea in the future.

Thank you.

--Ziang Song (talk) 02:22, 14 June 2008 (UTC)
 * "comparing notes is happy time for us to learning new things" --- Yes I do believe that sums things up nicely. --Samuel Pepys (talk) 02:25, 14 June 2008 (UTC)


 * While a genealogy-based wiki sounds like a great idea, Wikipedia is not a good place to run it. You can always download the software Wikipedia runs on, and start your own wiki. &mdash;  The Hand That Feeds You :Bite 13:33, 14 June 2008 (UTC)


 * We can currently put family trees into articles using certain templates for that purpose. If you want to maintain more formal structure, then you might want to set up your own wiki as User:HandThatFeeds mentions, or you could get some wiki-farm to host it for you, saving some effort.  A MediaWiki-based one would probably be the easiest to incorporate into the "family" (pun not intended) of wikis that includes Wikipedia (that is, the Wikimedia family), if it becomes popular and useful enough that the WMF decide to adopt it.
 * You might want to read this old page which used to list ideas for new projects, although please note it is no longer in use (but there are some hints you might like). Probably you will want to post a discussion somewhere on Meta to get some ideas on exactly what is the best way to set the project up before you start.
 * Finally, this sounds like an interesting project, I hope you have fun with it!
 * -- tiny plastic Grey Knight  &#x2296;  13:53, 14 June 2008 (UTC)

Does anybody have ideas about it? We hope to hear any suggestions about it :)--Ziang Song (talk) 03:39, 23 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&#8711;&#8710;&#8711;&#8710; 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. <font color="Red">1 <font color="Green"> !=  <font color="Red">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... &mdash;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. <font face="Broadway">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)

How about a more honest solution. ;) ... On a more serious note, I still run into more people who are surprised that you can just edit. Most who have a low opinion simply think that WP has a low threshold of whom it allows to edit, not that there is no threshold. --Gmaxwell (talk) 19:53, 15 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 vote establish 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," 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)
 * ________________________________

Comments added later : Sounds to me like one of the rare proper uses of subpages. See Wikipedia talk:WikiProject Outline of knowledge +sj +  15:12, 10 March 2009 (UTC)

Useroval
Hi, I am an IP user on wikiHow (but a registered user here), I saw they have a Template:Useroval, like the userbox, except it displays as an oval in Firefox. It will make no difference in IE, an will display like the normal Userbox template. I was just wondering, thanks,

♦ { Crimson  } ♦ Talk • Contributions 14:47, 14 June 2008 (UTC)


 * What was it that you were wondering? I don't understand.  If you want to make a userbox that uses this then I guess you can (although I think creating them in the User: namespace is the recommended best practice nowadays).  What are you asking? -- tiny plastic Grey Knight   &#x2296;  15:07, 14 June 2008 (UTC)
 * I think he's asking to have the template imported to Wikipedia for use here. &mdash;  The Hand That Feeds You :Bite 18:35, 14 June 2008 (UTC)


 * -- tiny plastic Grey Knight  &#x2296;  08:45, 16 June 2008 (UTC)
 * -- tiny plastic Grey Knight  &#x2296;  08:45, 16 June 2008 (UTC)

Inactive users
Sometimes when I search through a list or category of users (for example: members of a wikiproject, some-language-speaking users category...), for contact, most of the time, I end up posting for inactive users. I started the habit to check before posting, the contribution page of each user to see whether he's still contributing or not. But It's a tedious task. I know this is not the right place to post this (I think it's Bugzilla, but I don't know how to post there) but I think it would be useful to add some indication about whether a user is active or not. Maybe it could be a sign which appears at the top, bottom, or on the side bar, when visiting a User page. The sign could be either a active/inactive button, or just mention when his last edit was. But what I also prefer, is that links to inactive (or active) users are highlighted in some colors (just as broken links or stubs are colored in red) to indicate their status (what should be considered active depends on a setting in the preference page). What do you think? Eklipse (talk) 16:38, 15 June 2008 (UTC)
 * I think it'd be too much server load to have everyone's contributions being checked constantly to see how long ago it's been since they last edited. Perhaps a script you could run as needed would be more appropriate. &mdash;  The Hand That Feeds You :Bite 18:24, 15 June 2008 (UTC)
 * Thank you. I added a request at WikiProject User scripts/Requests. Eklipse (talk) 03:42, 17 June 2008 (UTC)

Named references in infoboxes
It appears that having a named reference that is first used in an infobox and later used in the article space will cause a cite error. My encounters with Category:Pages with incorrect ref formatting shows this has been a widespread problem. I have copied most of the problem refs into the article but this issue will only reappear later. A technical fix needs to be made to allow the named reference to pass from an infobox to the article space. --Samuel Pepys (talk) 17:51, 15 June 2008 (UTC)


 * Are you sure that the ref in your example was used in the infobox? I did this (having the full ref in the infobox, and the ref name later) in the South Dakota article, for the area, and it turned out alright. Often when the 'cite error' thing appears, it is a problem with the ref name, as in it wasn't copied properly or something; I don't know that the problem is having it in the infobox. AlexiusHoratius (talk) 18:02, 15 June 2008 (UTC)
 * Use  instead of , and you can bypass the bug. Also, make sure that the template or the reference itself at least, for transcluded, default references, is wrapped in   and   at the template page. { { Nihiltres | talk|log } } 22:19, 15 June 2008 (UTC)
 * Oooh! Nifty. Does that mean refs can now be generated during the template-processing phase? Also, wouldn't a then be necessary? -- Fullstop (talk) 19:02, 16 June 2008 (UTC)


 * You have two problems:
 * In the infobox, you had  and in the body, you had  .  Your ref name must be in quotes:.
 * You are using Infobox NBA Player and entering the reference in the field for "nickname". The problem is that this infobox does not have a nickname field, thus the first reference is not being transcluded.
 * --—— Gadget850 (Ed)  <sup style="color:darkblue;">talk  -  19:25, 16 June 2008 (UTC)
 * Fullstop, no.  based tags work exactly the same way as other tags, just their content gets parsed differently (i.e. is parsed rather than just passed through as literal). A   reference will work with   exactly as though it were a  . It's wonderful; give the devs a hug. :D { { Nihiltres | talk|log } } 21:05, 16 June 2008 (UTC)

DOI
Should every Wikipedia article have a digital object identifier (DOI)? Or even every oldid? JFW | T@lk  10:13, 16 June 2008 (UTC)


 * Actually oldid is a doi. Like so: http://en.wikipedia.org/w/index.php?oldid=219728437, the previous version of which is http://en.wikipedia.org/w/index.php?oldid=199899596 and so on. -- Fullstop (talk) 18:52, 16 June 2008 (UTC)

New poll to establish consensus about autoconfirmed status
Since the results of the first poll have been rejected by the the developers, a new poll has been created to establish "unequivocal consensus" about when accounts should be granted auto-confirmed status. Please express your opinion there. Thanks! Kaldari (talk) 16:41, 16 June 2008 (UTC)

Move the search box directly beneath the puzzle globe
This is a follow-up to Village pump (technical) (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 <pre style="overflow:scroll"> addOnloadHook(function {   document.getElementById("column-one").insertBefore(document.getElementById("p-search"), document.getElementById("p-cactions")) })

to your monobook.js. You can also type <pre style="overflow:scroll"> 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. <small style="font:bold 12px Trebuchet MS;display:inline;padding:1px 6px 2px 7px;"><font color="#630">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)
 * [[Image:X mark.svg|15px]] 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! <small style="white-space:nowrap;size:95%;color:#2F74FF">—<small style="background:#FFFFFF;border:#EB8500 1px solid;padding:0px 3px 1px 4px">TreasuryTag —<small style="background:#DBDBDB;border:#EB8500 1px solid;padding:0px 3px 1px 4px">t —<small style="background:#DBDBDB;border:#EB8500 1px solid;padding:0px 3px 1px 4px">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. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 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.d ela noy <sup style="color:red;">gabs <sub style="color:blue;">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. Graham 87 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&#39;i 14:29, 21 May 2008 (UTC)
 * Oppose Too much white space clumped together. It looks better the way it is now. <font color="Red">1 <font color="Green"> !=  <font color="Red">2  14:34, 21 May 2008 (UTC)
 * Oppose as a site-wide JavaScript hack. If you want it changed, please change it in MediaWiki. Grace notes T <span title="Wikipedia:Village pump (proposals)">§ 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&#39;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. Grace notes T <span title="Wikipedia:Village pump (proposals)">§ 15:18, 21 May 2008 (UTC)
 * Well, I wasn't 100% sure myself, so I figured I could have been totally wrong. :-) Mahalo. --Ali&#39;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. <font color="#233D7A">Nihiltres { <font color="#000">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 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.  <b style="color:#629632;">Celarnor</b> <sup style="color:#7733ff;">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 <span style="font-family:Verdana, Arial, sans-serif;"><font color="#20406F">Alex <font color="#20406F">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. –<font color="#112299">Outriggr § 10:33, 22 May 2008 (UTC)
 * I would suggest Special:Search and Google as good examples. <font color="#233D7A">Nihiltres { <font color="#000">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 // &#9775;  // 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 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 . -- 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. &mdash;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. – <font color="90EE90">F ISDOF <font color="D3D3D3">9 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. &mdash;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. &mdash;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 Main Page alternative (Search Box) (perhaps using elements from 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:
 * "It distracts from the sidebar box" (which would indicate that people notice it).
 * "it makes searching look too important" (these could be used against any attempt to make the search box more conspicuous).
 * "It disturbs the layout of the main page" (that only relates to the specific proposal).
 * "Redundant", "it will make people think there is something special about one box over the other"
 * "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 <sup style="color:#45E03A;">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)

<pre style="overflow:scroll"> 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)
 * 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. <span style="font-family:Papyrus, sans-serif; color:#775ca8;">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. <span style="font-family:Papyrus, sans-serif; color:#775ca8;">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.  Felis  Leo 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. sho  y  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. <font color="black" face="tahoma">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
 * 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)
 * Actually, half the links of the first two boxes ("navigation" and "interaction") are quite important for readers. And frequency of use is not really a factor; it is important that the reader's eye can go straight to the box, not that it should cover the least distance from the monitor's top. Light goes from the fastest road, not the straightest; this is similar. Waltham, The Duke of 01:22, 18 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).
 * Support -The way I see it, if I have to look for it sometimes, and I come here every day, then other older and newer will have trouble. —Preceding unsigned comment added by Leonard^Bloom (talk • contribs) 03:12, 12 June 2008 (UTC)
 * Support - This will make things a lot easier for many; I'm not sure if the veterans in opposition are really putting themselevs into the shoes of a brand new user. The first thing they'll see is the logo, and, hopefully, with a new format, the second thing will be the search box right below the globe. -- Anonymous Dissident  Talk 13:38, 14 June 2008 (UTC)
 * You are an old user... Do you consider your judgement more accurate than ours as far as the way newcomers view Wikipedia's layout is concerned? :-) In any case, I strongly disagree with the view that people read a screen like a book page, line by line, top-to-bottom. A newspaper or magazine page would be a more accurate analogy: people first look at the most distinctive elements (in printed press that would be headlines, pictures, and captions). In the case of the main page, not only is the search box as conspicuous as it can be with its current formatting because it breaks the sidebar's pattern of link boxes, but it would be overshadowed by the bold lettering of the logo right above it. The move could actually make the search box less conspicuous. Waltham, The Duke of 01:22, 18 June 2008 (UTC)
 * Support - Excellent aesthetic improvement. Jeff Carr (talk) 16:22, 16 June 2008 (UTC)
 * Strongly Support - Good usability should be a prime objective of every website and that means following design conventions where they exist and placing the search where the visitor expects it. The current position violates usablity guidelines which state that the search should be placed at the top of the screen. I see no rhyme or reason for placing the search where it currently is. This should be a no brainer. --Wolbo (talk) 21:11, 16 June 2008 (UTC)
 * Yet it is not. And I agree as far as the top of the page is concerned, and there are indeed many websites placing their search bars right at the top. However, the top of the sidebar is not the top of the page. We are talking about very different layouts, and the comparison here is rather poor. Waltham, The Duke of 01:22, 18 June 2008 (UTC)
 * Support. That's a no brainer. The readers are who we are doing this for. Ther are the majority of users, and we have to acknowledge that we get lots of visitors that are not familiar with the site. We have to make it as easy as possible for the reader to find what is probably the most important function of the site. Plus it'll help users with mobile devices. Furthermore the searchbox should be at the same position on every page (principle of least surprise). --Dschwen 14:43, 11 July 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)


 * We should probably either mark "Improve Special:Random" as a perennial proposal or else figure out a way to do it (the latter would be nice, I wouldn't mind being able to look up a random article within a category). I suppose we might add a category parameter for it and have a separate link beside the normal randomiser to give a list of some of the high-level categories you can select (something like: <tt>"Random article (pick type)"</tt>.  An editable (but presumably protected) page could be reserved to maintain a list of eligible categories, I guess (not sure if there is much caching to worry about in this regard).
 * That's a random idea anyway, probably someone can think of a better way to do it! -- tiny plastic Grey Knight   ⊖  07:53, 10 June 2008 (UTC)
 * Check out Link intersection -- a proposal to create a tool to find similar articles based on them sharing the same wikilinks. -- &#x2611; Sam<font color="#CCCCFF">uelWantman 07:02, 15 June 2008 (UTC)


 * ###How obvious is this? Lets have to option to not land on stubs and disambiguation pages!69.134.171.127 (talk) 22:57, 17 June 2008 (UTC)  —Preceding unsigned comment added by 69.134.171.127 (talk) 22:56, 17 June 2008 (UTC)