Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

[edit] Being able to edit your edit summaries

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[edit] Straw poll

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

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

[edit] Support

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

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

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

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

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

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

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

[edit] Conditional Support

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

[edit] Oppose

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

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

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

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

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

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

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

[edit] Short break:

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

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

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

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

[edit] Neutral

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

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

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

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

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

[edit] Page move speed restriction

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

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

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

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

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

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

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

[edit] Straw poll

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

[edit] Increase autoconfirm

Please see Wikipedia:Autoconfirmed Proposal/Poll.

[edit] Page move speed restriction

[edit] Easier to undo page moves

[edit] Don't change anything

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

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

[edit] Comments/other

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

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

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

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

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

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

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

[edit] Site-wide spelling choice tabs

Hi, I don't know if this has been proposed before, because I haven't read the archives. On the Chinese Wikipedia they have tabs at the top of the page where a user can choose to display all WP pages in the writing style of their choice. The options are: no conversion, Simplified characters, Traditional characters, Mainland simplified, Taiwan variant, Singapore variant, and Hong Kong/Macau variant. The entire page is instantly changed to the style of choice, for example 國 is detected and changed to 国.

Couldn't something like this be implemented on the English Wikipedia, so the user can select their preferred writing style? I'm unaware of differences between the countries of Commonwealth English, so the three tabs would be "no conversion", "Commonwealth English" and "American English". The term "color" would be detected and converted into "colour" at the click of a tab. The tab could be auto-selected based on a user's IP, and a change stored in cookies.

Of course this could bring up server load issues, but I don't know if there are more Chinese character variants than English word variants, or vice versa, so the usage would either be greater or less. Also, there would need to be exceptions, like proper nouns such as Medal of Honor, possibly within article titles or a template that hides the term from detection in article content, along the lines of {{noconvert|Medal of Honor}}.

I wasn't sure if this should be at Bugzilla, but I figured that if it's already done on the Chinese WP, it's already part of the software. --Joowwww (talk) 19:44, 16 May 2008 (UTC)

I think it's feasible, but not necessary or worth the effort it would take to develop. After all, just because something can be done doesn't mean there a reason to do it. In the case of English, the spelling differences between the two dialects are pretty slim. Aside from the occasional added "u" and "z" becoming "s", that's pretty much where the spelling issues end, and I doubt this causes any problems for readers. The more substantial differences between the two are in phrasing, and that's probably not something that could reliably be changed on-the-fly anyway, even if we did see a potential benefit in doing it. Equazcion •✗/C • 19:50, 16 May 2008 (UTC)

I move that this proposal be tabled. --Carnildo (talk) 20:25, 16 May 2008 (UTC)

This has been discussed in the past. It was decided that it wasn't worth the effort or arguments it would create. BrokenSegue 21:34, 16 May 2008 (UTC)

I think this is a bad idea simply because the differences between the different versions of English are so slight that they can be understood by any dialect. The added problems and work this would require is massively outweighed by the advantages. -Halo (talk) 22:06, 16 May 2008 (UTC)

I would second the motion if we worked that way. I do agree— of all the things to fix, this is way at the bottom of the list. --— Gadget850 (Ed)talk 15:51, 17 May 2008 (UTC)

You hit the nail on the head yourself, Joowwww: "there would need to be exceptions". The question is, how many, where, and who's going to exempt them? We have two and a half million articles now, and eleven million pages overall. The number of exceptions which would have to be coded for a proposal like this to be implemented is just mind-boggling. And the worst part is, just like spelling-bots, we wouldn't be able to automate it: it would have to be done by hand. Far too much work for an utterly trivial gain, and it still wouldn't solve the Georgia debate :D Happy‑melon 15:55, 17 May 2008 (UTC)

What's the "Georgia debate"? -- Imperator3733 (talk) 15:18, 23 May 2008 (UTC)

Look at the history - for a while last year there was a running move-war between about ten editors over whether Georgia should redirect to (or contain the contents of) Georgia (US State), Georgia (country), both, or neither. Similar arguments have cropped up over Petrol / Gasoline, Liancourt Rocks and a variety of other names, and a number of other pathetic cultural rivalries. Check out Wikipedia:Lamest edit wars - the majority of them are over dialect-related hiccups. Happy‑melon 16:58, 27 May 2008 (UTC)

Was Carnildo's comment a subtle joke? To a Brit "this prpoposal should be tabled" means "we should put this on the agenda and act on it" but to an American it means "we should ignore this". Really translating between dialects is almost impossible. Dingo1729 (talk) 04:26, 19 May 2008 (UTC)

Exactly. There's no context, so an automated system wouldn't be able to tell what I meant. --Carnildo (talk) 06:53, 19 May 2008 (UTC)

Speaking as an American with several semesters of parliamentary procedure under my belt through student government and clubs, I disagree. As we learned it, to table something is akin to holding a piece of paper actively being discussed, then after the motion to table it is passed, the paper is set back down on the table to be picked up again at the next regularly scheduled meeting, and discussion would continue where it left off. So, technically, both of Dingo's comments are correct, but they are just opposite ends of the process. "We should ignore this [for now, but] put this on the agenda [for our next meeting] and act on it [then]" would be the full process. Aww... such memories you brought back to me on arguments over the intricacies of Robert's Rules of Order Newly Revised. --Willscrlt (Talk) 11:23, 1 June 2008 (UTC)

Switching Chinese writing styles is just a font change AFAIK. This proposal would be far more involved since it needs to change the content of the page rather than just the presentation. The effort-to-benefit ratio of this proposal I think falls squarely on the side of not implementing it. --Selket ^Talk 18:00, 21 May 2008 (UTC)

I have no problem with the idea of this (i.e. I wouldn't object if it was implemented), but it just seems to complicated to implement. English speakers can understand either spelling. -- Imperator3733 (talk) 15:20, 23 May 2008 (UTC)

It's not "complicated", it's "impossible". Read my earlier comments, then look up the meaning of the word "table" in the context of parlimentary procedure. --Carnildo (talk) 04:47, 24 May 2008 (UTC)

It's no more impossible than the corresponding system at the Chinese Wikipedia (which does involve phrase and idiom changes in addition to simple character remapping). It would, however, require writers to pay attention to it and regularly add manual exception for phrases that cannot or should not be automatically translated (like your "tabled" example). As pointed out above, this would be way too much work for way too little gain here. For details, see meta:Automatic conversion between simplified and traditional Chinese. —Ilmari Karonen (talk) 19:31, 27 May 2008 (UTC)

[edit] Favicon improvement

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[edit] Move the search box directly beneath the puzzle globe

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

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

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

You can try this out in your own browser by adding

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

to your monobook.js. You can also type

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

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

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

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

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

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

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

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

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

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

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

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

• Expand the discussion

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[edit] Two related proposals

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

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

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

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

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

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

[edit] Non-Wiki Talk Pages

I was wondering why exactly the discussion pages are wiki-pages (i.e. editable). Why wouldn't we just use a standardized approach (I'm thinking forum-alike)? I know this would of course a big overhaul, and that it causes problems with respect to the talk-pages already in place. I only would like to know if people agree, aside from the issues above, this would be a better system. Advantages:

• Clear separation of posts and topics.
• Quick and easy identification of users.
• Easier replying.
• Automatic signing.

Disadvantages (apart from the two posted above):

• Where to put top-page templates? (This would be solvable though)

84.87.183.181 (talk) 12:21, 22 May 2008 (UTC)

To incorporate a totally different style of discussion would involve a massive amount of work, for very little gain, as the way those two "types" of software handle their data are totally different. If you're a web developer and wish to try your hand at integrating a board system into the MediaWiki software, by all means, prove me wrong. :) EVula // talk // ☯ // 14:46, 22 May 2008 (UTC)

Wiki talk pages mean that users can commute techniques learned between article editing and discussions. Why make users learn one syntax for articles and a different syntax for talk pages, when wiki markup works well for both? It also facilitates linking to articles and other talk pages (allowing both to be done the same way), and it makes quoting articles on talk pages much easier. Powers ^T 18:13, 22 May 2008 (UTC)

See mw:Extension:LiquidThreads. Coming soon, maybe. -- Quiddity (talk) 18:33, 22 May 2008 (UTC)

I'm not sure what the development status of LiquidThreads is, but I agree strongly with you that there ought to be forums on talk pages. See User:Dcoetzee/Why wikithreads are bad for my argument why. I already address all of LtPowers' objections, which aren't new. Dcoetzee 19:57, 22 May 2008 (UTC)

I can't agree with you more, Dcoetzee. Why do we still have to archive discussion threads manually? That's so primitive (and error-prone). (Or remember to put "Taku (talk) 08:43, 23 May 2008 (UTC)") Wikipedia is great, but the software system on which it operators isn't quite so, unfortunately. -- Taku (talk) 08:43, 23 May 2008 (UTC)

I think LiquidThreads looks good but too complicated to implement. —TreasuryTag—t—c 13:09, 23 May 2008 (UTC)

This sounds like a lot of work with very little benefit. GO-PCHS-NJROTC ^(Messages) 23:49, 29 May 2008 (UTC)

I've got a better idea! Let's convert all the forum-type discussion boards over to wikis, and then nobody would be confused anymore (said with tongue planted firmly in cheek). My real answer: Because once you get used to wiki editing, Talk just is another namespace. Why would you even want to dive into a different environment? Keep things simple. --Willscrlt (Talk) 11:30, 1 June 2008 (UTC)

[edit] Welcoming Committee

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

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

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

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

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

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

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

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

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

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

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

[edit] Change "navigation" on sidebar to "browse"

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

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

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

[edit] New user group for prolific article creators

It would be beneficial to users patrolling Special:Newpages if users who create lots of quality articles were excluded from their articles needing review. The 'autopatrol' right is already given to admins and bots - any new pages they create are automatically marked as patrolled. However, many of these users don't want or need the rest of admin tools. This could be given out by admins, similar to rollback and accountcreator, to users with a history of creating good articles (lots of good creations, no problems with articles being deleted). So what do people think? Mr.Z-man 05:41, 26 May 2008 (UTC)

I like the either, only question is if the account should be separate from the main account (a modified bot account) or if the flag should be given to the main account. MBisanz ^talk 05:44, 26 May 2008 (UTC)

Since we only use the patrolled edits feature for newpages (and we really only patrol new articles AFAIK), there's not much of an issue with giving it to the main account; its basically just regular article work. Mr.Z-man 05:48, 26 May 2008 (UTC)

Ok, but from a technical point of view, all pages, regardless of namespace are listed for patrol. We've just decided the default view should only be the article space. MBisanz ^talk 05:52, 26 May 2008 (UTC)

Is there any worry that users who create quality articles are going to create inappropriate pages in other namespaces that people don't patrol anyway? I understand that all the namespaces are included in the patrolled edits feature, I just don't see why its an issue. Mr.Z-man 05:59, 26 May 2008 (UTC)

No, no real risk issue. Also, I'd be against Admins giving it out. I'd prefer crats give it out. MBisanz ^talk 06:03, 26 May 2008 (UTC)

I think it's un-necessary, and low-risk, if it has to happen then admins giving it out seems fine. —TreasuryTag—t | c 07:06, 26 May 2008 (UTC)

Let's have it be a minimum of 100 good articles first (not Good Articles, just good, valid articles). Sound good? DS (talk) 12:10, 26 May 2008 (UTC)

I think that this is a good idea; anything that helps content-creators can't be that bad, after all, content is what WP is all about. I think that admins should give it out (it's hardly high-risk and can easily be revoked). What about giving it to content-creation bots such as User:FritzpollBot? If such bots are creating 1000s of basically identical articles, it would be tedious to patrol them all manually, not to mention unnecessary to check them. RichardΩ612 Ɣ ɸ 12:31, May 26, 2008 (UTC)

I like this idea. Would each admin have the ability to approve someone or would there be a more formal approval system for this? Captain panda 12:37, 26 May 2008 (UTC)

Bots already have the flag, so that won't be necessary. As for approval, a page like WP:RFR could be set up, or it could be like the accountcreator group, given out by admins involved to non-admins involved, as this is less of an "everyone can use it" thing like rollback and more of a "only a few people need it" thing like accountcreator. Mr.Z-man 20:21, 26 May 2008 (UTC)

(Unindent) This sounds like fun. I'd like this kind of access for myself, but I suppose if I really wanted it that badly I could do an RFA. I put "construction" templates to keep the speedy deletion tags off my pages, and I'd prefer not to have to do that, but I've gotten used to it by now. Of course, we must also consider the consequences of creating endless new user access levels for no particularly compelling reason. :) Shalom (Hello • Peace) 03:47, 27 May 2008 (UTC)

This sounds like it might be useful to admins, but it's not really the user's problem. I mean, I never really thought about people patrolling the new articles I started - whoever they are they are apparently a lot more laid-back than the deletionists I often run up against when I start a new paragraph! So there's no reason I can see to make any special action to apply for this, except as a status symbol. I think the admins should just keep a list of who they trust on this point, which wouldn't even necessarily have to be public since it doesn't actually confer any special privilege beyond a chance of getting away with something until it's spotted. Wnt (talk) 00:07, 28 May 2008 (UTC)

Err, you may not have seen WT:CSD then. Overzealous patrollers is a problem frequently raised by content creators. With something like this, all patrollers could know to ignore certain users (and patrolling isn't limited to only admins either). We don't even have to make it a thing to apply for. The users with the flag won't notice anything (except their articles won't be plastered with cleanup tags an inappropriate speedy tags 2 minutes after creation). Mr.Z-man 02:29, 30 May 2008 (UTC)

Seems sensible to me. There few things seem more pointless than going through the patrol log ticking off yet another bunch of Blofeld's French geostubs. Angus McLellan (Talk) 15:12, 30 May 2008 (UTC)

I have to agree with Angus here. This would benefit both the article creators by allowing them to work in peace without having to deal with overzealous NP patrollers (like my self ¬_¬ ;) ), but would also aid the said NP patrollers by not requiring them to scroll through endless lists of legit new articles (we're averaging what? 18-20k+ legit new articles/day?) to find the "Tommy is the coolest guy in the world" articles. I can't think of any downside to implementing something like this. Thingg^⊕⊗ 15:19, 30 May 2008 (UTC)

So right now, the fact that I have ~3600+ edits here and another 1000 or so on other projects, doesn't make any difference in the way an edit looks in the change log compared to a new account with under 100 edits? That seems counter-intuitive. I kind of see it as a flag that is turned on by default when an account is created. Then, when any admin notices a solid history of good editing (i.e., they get tired of seeing the name show up in the new pages log since they are always good edits given enough time), he or she can turn off the flag, and the new pages created by that person aren't logged the same way. Or maybe they are logged, but there's a little letter next to the edit like there is for "b"ots, "n"ew, etc. I have encountered overzealous people flagging new article pages with tags moments after I created the page. It does get annoying, especially if you are working in another window preparing to paste a lot of text in, then when you try, the page has just been speedy deleted. Grr. Things like that really annoy both new and experienced editors. --Willscrlt (Talk) 11:47, 1 June 2008 (UTC)

[edit] Send to a friend

It would be helpful if pages had a link or button so they could be emailed (either the whole text or a link). Job listing example —Preceding unsigned comment added by Wiki11790 (talk • contribs) 02:29, 27 May 2008 (UTC)

I think most web browsers have a "send a link" feature built in. Mr.Z-man 03:19, 27 May 2008 (UTC)

I'm using Mozilla Firefox and Internet Explorer and I don't believe they have that feature.-- _{Wiki11790  talk}  06:47, 27 May 2008 (UTC)

In Firefox: File->Send Link. In IE7: Page->Send link by email. Mr.Z-man 06:52, 27 May 2008 (UTC)

True! We don't need a Wiki-feature for that. ╟─TreasuryTag (talk ╬ contribs)─╢ 07:05, 27 May 2008 (UTC)

Both of those seem to require that you have an email account set up with the web browsers. I'm suggesting a feature that would allow you to type in your email address and a friend's email address to send it to.-- _{Wiki11790  talk}  15:49, 27 May 2008 (UTC)

If that were to be implemented, it would probably last about 3 minutes before being disabled after spambots started auto-vandalizing pages with ads and then sending that version to their 10,000 "friends"... Anomie⚔ 01:38, 28 May 2008 (UTC)

That's entirely possible, but why not assume good faith? The technology exists, articles could have been auto-vandalized up until now and web browsers used to send that to "friends". I feel as though this would be convenient and practical for wikipedia users.-- _{Wiki11790  talk}  05:48, 28 May 2008 (UTC)

There is a big difference between using the web browser's "email this page" feature and having such a feature built into Wikipedia. In the former, the message is sent from the email account of the person sending, using that person's and their ISP's resources and reputation, and making that person answerable to their ISP's AUP. In the latter, the message is sent from Wikipedia's servers using Wikipedia's resources and reputation, and all we could do is block various IP addresses from using the misfeature. As for AGF, Wikipedia's legitimate users might use it in good faith, but the spammers and their zombies would abuse it horribly. Anomie⚔ 13:24, 28 May 2008 (UTC)

Wikipedia already has this feature. See: Template:Email -- penubag  (talk) 06:11, 28 May 2008 (UTC)

I think this is a really good idea, and that the spambots can be overcome. If all major news websites can do it, why can't wikipedia? Saluton (talk) 21:20, 30 May 2008 (UTC)

The "send link" type of e-mails are blocked by default in many spam filters, thus they are useless. You're better off copying and pasting the link and sending manually. I know that Wikipedia doesn't need much help in improving it's search engine ratings (haha), but links to Digg, Del.icio.us, Stumble, and e-mail a friend (probably only available to registered users with a valid e-mail account on file), are common and helpful. It would be a big boost to whichever sites are selected as "preferred" links, but there shouldn't be any problem with a send by e-mail link. Necessary? No. Nice? Yes. --Willscrlt (Talk) 11:51, 1 June 2008 (UTC)

[edit] Why is news being posted on the Main Page?

Why is news shown on Wikipedia's main page? That is what Wikinews is for. Wikipedia is supposed to be an encyclopedia, not a newspaper. In real life, would you open up the encyclopedia volume to find the latest news? Certainly not. Likewise, would you open up the newspaper to find general news? Again, no.

Wikinews should be dedicated to news, and likewise Wikipedia to knowledge and learning. On Wikipedia's main page, they could continue to provide a news section, but it should only be a link to Wikinews.

I often wonder why Wikipedia is the only project of the Wikimedia Foundation that has truly taken off. Perhaps it was the first and the oldest and the other projects will follow. Please discuss anything further either at the Village Pump or elsewhere, but please keep me informed as this goes on. Thank you!

Agomulka (talk) 13:15, 29 May 2008 (UTC)

I would gather it's there to point people to the respective articles related to ongoing current events such that they may be updated as required. I would support renaming it from "In the news" to "Current events" to more accurately reflect this. xenocidic (talk) 13:20, 29 May 2008 (UTC)

I agree, as really it just covers current events rather than going into huge detail and covering different news stories. I'd support such a change. --.:Alex:. 13:55, 29 May 2008 (UTC)

I concur with the original poster's point. We are not a news service, we are a reference work. I'd love to see a conscious effort to de-emphasize the "current events" aspect of things in all our public faces, as a first step towards actually addressing our hideous plague of blatant recentism. --Orange Mike | Talk 14:09, 29 May 2008 (UTC)

Or "Updates". Phlegm Rooster (talk) 19:15, 29 May 2008 (UTC)

I disagree. Statistics have shown that have readers have an overwhelming interest in articles related to current events - even if those articles already existed before the media brought attention to the topic. The "in the news" box is really about listing a few topics that the reader is likely to be interested in, because they're relevant to current events. They're not news articles, as they discuss the topic in its entirety, frequently with only a section dedicated to the current event. Dcoetzee 20:38, 29 May 2008 (UTC)

Traditional encyclopedias do publish news annually in yearbooks, according to Encyclopedia Yearbook Reference Guides. To do so daily would be difficult. -- Wavelength (talk) 03:01, 30 May 2008 (UTC)

I was always under the impression that the "In the news" section on the front page was not there to provide news reports, but rather to provide some dense-with-links headlines that would lead people to articles where they could find more in-depth information about people, places and things that had been in the news recently. As Dcoetzee said - our readers are interested in reading articles about things related to current events. --Stormie (talk) 11:00, 1 June 2008 (UTC)

Since Wikipedia is often the first page I see when I open my browser, I like to keep up with big events happening in the world. It's also small and out of the way, so it's useful without being obnoxious. Plus, I have often followed links there to stories. Having the links helps bring the news into perspective in new and interesting ways. Try that on CNN. Can't do it. You have to open up Wikipedia in another tab, and that's a pain. --Willscrlt (Talk) 11:54, 1 June 2008 (UTC)

[edit] Message box standardisation, all namespaces

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

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

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

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

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

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

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

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

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

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

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

[edit] Confusing note on Wikipedia:Sandbox

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

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

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

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

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

"Waste of time. Terrible, unreliable info"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[edit] User:FritzpollBot creating millions of new articles

Discussion moved to subpage: Wikipedia:Village pump (proposals)/FritzpollBot. -- Anonymous Dissident^Talk 10:54, 1 June 2008 (UTC)

[edit] Operator response to some issues

Hi there - I actually operate the bot. I've only glanced through the text above, and fully support the community involvement in this process. Let me answer some of the points raised above:

• The example being cited is now out-of-date. Further to discussions at the BAG proposal, the code has been modified to point to sort out some stylistic issues, and to adjust the references. Looking at the new Afghan articles is probably a better guide.
• The bot is stupid! Computer programs are not inherently intelligent, and on a task like this, cannot be left to their own devices. Further to that, my proposal, as implemented and approved has the following steps:

1. Bot extracts data and uploads lists to the subpages of [[3]].
2. Data is then checked by human editors. This includes checking for disambiguation requirements, any spelling errors not consistent with Wikipedia's existing content, and any other issues.
3. Once the check is complete, I am notified. The bot then scans the list, creating articles for any article that is red-linked - it will not do anything is the page already exists, beyond write out a log to me of all places that it did not create.

• As part of this process, I have encouraged the inclusion of Wikiprojects in these areas - as I upload, and common errors are checked, I hope to contact all interested parties. This will allow consistency within a project, more specialised templates, categories, etc.
• Inclusion of others will also make it more likely that we can find extra data, such as census data, etc. that can be built-in to the article from day one. I am happy to include this where available, provided it is in a readable, accessible and publically available format.
• Each area has its own idiosyncrasies in terms of administrative division, etc. so the bot is already being manually adjusted to cope with some of these. For the technically minded out there, I run the code in debug, edit & continue mode to allow intervention with any exceptions that arise, and to monitor the early stages of creation to ensure that things are being done properly. Takes longer, but worthwhile.

In short, the bot is only a tool for extraction and article creation. It still requires human input, but in a format where human interaction can be very efficient. The timescale is relatively short, but the articles are only created country-by-country, following human eyes (the community here, not just me) confirming the validity of the data. I hope this addresses some concerns about the bot, but I am of course happy (and in my opinion obligated) to respond to any other comments you may have. Best wishes Fritzpoll (talk) 10:58, 1 June 2008 (UTC)

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

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

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

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

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

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

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

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

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

[edit] The results of merge discussions are seldom recorded

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

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

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

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

[edit] Re: RfA proposal

There's a discussion on refining the wording of RfA boilerplate taking place at Template talk:RfA#Proposal to change the following sentence. The current proposal is to change the sentence introducing the questions from:

It is recommended that you answer these optional questions to provide guidance for participants:

to:

Dear nominee, please answer the following questions:.

The Transhumanist    13:56, 1 June 2008 (UTC)

[edit] Improvement in "Random page" methods

Per the discussion at subpage Wikipedia:Village pump (proposals)/FritzpollBot creating millions of new articles, which in one day has already gotten longer than this whole page, I propose a slight change in the random page function. Rather than weight every article equally (as I presume happens now), why don't we weight the articles by size in bytes? (Alternatively, we could use age or number of edits, or any one of many dependent functions.) The immediate benefit is that better articles get better exposure, even though randomness is thoroughly preserved. There is an additional benefit in that a very high number of very short (4K) new geographical stubs is expected to be created over the next months by the proposed bot, and having a disproportionate number (as high as 50%) of random articles resulting in geo-stubs is a definite drag to many people. Weighting would be an excellent solution to this problem, and would be an improvement even if there were no such problem.

Though we are not to worry about implementation and costs, the simplest way is to have a periodic (e.g. daily) update of a field in the article's database entry which contains the then-current cumulative bytecount (i.e. total bytes in all articles up to and including the current one). Then you pick a random number from 1 to total bytes in the system, and select the article where that field contains the lowest number greater than or equal to the random number. I think this would be an excellent consideration for all spaces completely independent of the bot debate. Who would be able to work on it? JJB 21:23, 1 June 2008 (UTC)

That's a good idea. It would be extremely simple to modify the PhP code to alter the random page choice probabilities based on any number of weighting factors. And once you're modifying the PhP code and perhaps adding a field might as well spend a few hours to do a good job. I'm not sure the anyone would put a high priority on it, but if the random page were a little more selective, and more prominently featured, it might considerably improve the usefulness of Wikipedia to casual readers...hence promoting the image of disseminating encyclopedic knowledge to the world. Wikidemo (talk) 21:58, 1 June 2008 (UTC)

Note that any changes to Special:Random would/should probably involve adding optional parameters for specifying the behavior, rather than forcing a single behavior that weights articles in some fashion.

You really have to think about how the random article function is actually being used. Are there people who use it to find well-written articles? I myself use it primarily to find crappy articles and missed vandalism. It would be interesting to poll readers to find out why they use the random article function and what they intend to find with it. --- RockMFR 22:49, 1 June 2008 (UTC)

This doesn't sound like such a bad idea at all, and yes, it would indeed be nice to have several weighting choices. Maybe we should have a new page_weights table for it, instead of storing the weights in the page table. Also, it's not really necessary to run the updates in one pass, it can be done in small chunks. I think, however, that this would all be best implemented as a MediaWiki extension rather than in the core. In fact, if the extension works well, we might want to consider removing Special:Random from core entirely; there are lots of MediaWiki installations for which the random page feature is all but useless. —Ilmari Karonen (talk) 00:50, 2 June 2008 (UTC)

[edit] Proposal to extend CSD A3

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

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

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

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

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

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

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

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

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

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

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

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

[edit] New Article Creation "Holding Area".

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

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

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

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

[edit] FritzpollBot Discussion

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

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

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

[edit] Renaming "history" tab

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

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

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

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

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

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

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

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

[edit] Submit To Bugzilla

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

[edit] Make established articles move protected?

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

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

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

or

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

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

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

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

[edit] Order of Precedent

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

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

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

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

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

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

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

[edit] Font Style in Wikipedia difficult to read

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

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

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

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

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

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

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

[edit] Post On Bugzilla

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

[edit] Merge donation banner with anon tips

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

[edit] "First" and "Last" buttons

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

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

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

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

[edit] Ratification vote on {{C-Class}} started

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

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

[edit] Image copyright tags

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

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

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

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

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

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

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

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

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

[edit] User interface proposals

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

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

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

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

[edit] Default Auto-Sign

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

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

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

[edit] Proposal to reduce the protection level of Wikipedia:Upload

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

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

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

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

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

[edit] Using Random String Instead of IP Addresses

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

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

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

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

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

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

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

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

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

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

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

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

[edit] Category Overlap Tool

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

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

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

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

[edit] Stagnation Prevention List and View Count

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

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

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

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

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

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

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

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

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

[edit] Please Post On Bugzilla, Thanks!

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

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

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

[edit] Founder or Co-founder that is the question

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

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

And yes, this does sound quite petty. Mr.Z-man 14:59, 6 June 2008 (UTC)

[edit] Brackets around citation numbers

With what appears to be the growing acceptance on this project of what I call "cite bombing" - that is, the addition of a cite, or multiple cites, for every sentence, and sometimes every clause of a sentence, I am finding it increasingly difficult to read some articles, because of the amount of "clutter" that the cites ^[1] add.

In thinking about how this might be rectified, it occurred to me that the use of brackets around the cite number [] is arguably unnecessary. One doesn't, after all, find brackets around citation numbers in a book, but they are still easy to see and use, and they don't disrupt the text at all. So why, exactly, do we have these brackets? Are they really necessary? Is it time we maybe thought about dropping them, and just having the number instead? Gatoclass (talk) 10:09, 6 June 2008 (UTC)

I (kinda) agree with you but it is not that cluttered that it isn't unreadableTHROUGH?AWIKI?DARKLY (talk) 10:11, 6 June 2008 (UTC)

I've seen a few articles with the condition that you're talking about, User:Gatoclass, it can be a bit awkward. I can't find any examples just now, if you turn any up it might help to link diffs here so people can see what you mean. :-) Anyway, I was wondering if it's possible to have multiple refs written as ^{[10,11,12,13,14]} rather than ^{[10][11][12][13][14]}, which would cut down on the size of the "ref nugget" a little bit. Might not be possible with the way the ref system is setup at the minute, though, and to not much effect. An easier solution might be to discourage people from over-doing it in the first place! --_{tiny plastic} Grey Knight ⊖ 13:14, 6 June 2008 (UTC)

As far as I'm aware, there shouldn't be multiple refs for a single statement except for rare and very particular circumstances. Even then there should never be that many. If you could give us an example, there are probably a few I could point out that could even be removed (there is such a thing as excessive citing). Still, merging multiple refs into a single set of brackets is a very interesting idea. --.:Alex:. 14:22, 6 June 2008 (UTC)

I think instances of it come from either (1) citing all statements in a sentence/paragraph at the end, or (2) people being overzealous in their reaction to "that statement's not cited in multiple secondary sources". I found an example at Soulja Boy#Initial_reception revision, if it's of interest. A mere four refs in a row, I'd like to point out that I have seen bigger "nuggets" in the past! :-) --_{tiny plastic} Grey Knight ⊖ 14:43, 6 June 2008 (UTC)

It can also sometimes be found when there is a statement like, "Many other critics agreed.^{[10][11][12][13][14]}" or similar. --Ali'i 14:54, 6 June 2008 (UTC)

I've seen it often enough. I think it should be written with ranges, e.g. ^{[2, 10-14]}. That's how it's done in scientific literature, more or less. -- Tim Starling (talk) 15:18, 6 June 2008 (UTC)

Or maybe multiple citations could be placed in one ref tage (I may have seen this somewhere, but now I cannot remember where). Such as "The sky is sometimes not blue.^[4]" then when you click "4", you see 5 or 6 different cites either bulleted or lettered, etc. Although if you wanted to use a specific citation again, the ref name feature wouldn't really work. (less helpful?) Mahalo. --Ali'i 15:30, 6 June 2008 (UTC)

A-ha, an example. I knew I had seen it somewhere. The first ref (number 152 currently) in this section has multiple sources in one ref tag. Mahalo. --Ali'i 15:38, 6 June 2008 (UTC)

Yes, putting multiple sources under one tag is one way to cut down the mess Ali'i, but you still have the problem of articles which cite refs at the end of every sentence or even every phrase. Even if it's only a single number, I find it very disruptive to one's reading. I just don't see why we need these darned brackets [ ] at all, and I'd like to know why we can't just get rid of them. Gatoclass (talk) 17:55, 6 June 2008 (UTC)

I, for one, find the brackets make the references clearer and easier on the eyes. Big "nuggets", as it were, would persist regardless of the omission of brackets as large collections of references which are not grouped will still amount to long lists of reference numbers. While I like the idea of ranges, it is probably unpractical without a major code reworking as we allow reference numbers to be used multiple times in a document, meaning that reference numbers are not necessarily in order. Nihiltres^{t.l} 23:06, 6 June 2008 (UTC)

How do you know they "make the references clearer" when you haven't seen the alternative?

What I do know is that citation numbers in books, ¹ which don't come in brackets, ² don't distract me at all, whereas these hefty bracketed things on wikipedia are very^[2] intrusive^[3] indeed.^[4] So it stands to reason that if one removes the brackets, the text should be more readable and more attractive to look at. Gatoclass (talk) 12:35, 7 June 2008 (UTC)

I agree with everything Nihiltres notes, and only need to add that a range like [10-15] makes [11], [12], [13] and [14] unclickable. Not a big deal perhaps, but worth keeping in mind. -- Fullstop (talk) 05:13, 7 June 2008 (UTC)

The quick¹ brown² fox³ jumped over the lazy dog.

The quick^[5] brown^[6] fox^[7] jumped over the lazy dog.

Which is easier to read? Gatoclass (talk) 12:39, 7 June 2008 (UTC)

If the issue is that the view is cluttered when you have five or so cites, then it is probably a good time to look at the content and how it is referenced. Multiple cites indicate an overzealous editor, or there is a content issue and cites are being improperly used. To use Ali'i's example of Expelled: No Intelligence Allowed, it is my opinion that the bundled use of reference 152 is being used not to back up the statement that "The film was promoted by Christian media", but to illustrate examples where the film was promoted by Christian media— a subtle but crucial difference. --—— Gadget850 (Ed) ^talk - 13:09, 7 June 2008 (UTC)

Excuse me for coming in so late, but the phrase "cite bombing" caught my attention. IMO there are aspects of Wikipedia policy, its implementation and its more fanatical enforcers that can make "cite bombing" almost mandatory, for example:

• In 4X some guy insisted on applying a "notablility" tag to the article, which might have led to the article's deletion. I slapped in about 10 cites for use of the term "4X" to make him go away. Later I realised I could package them all in 1 footnote.
• On Evolution I put in some extra cites to support the point that's it's the majority view among scientists. In this case I couldn't package them in 1 footnote because most were also used elsewhere in the article.
• On Talk:Max Euwe someone recently made a comment that virtually demanded a citation (which would have been the same source) for each sentence in a paragraph.
• Then there are the WP:RS ayatollahs who remove without notice citations that do not satisfy their interpretation of WP:RS or one of its sub-pages. If the sentence / paragraph then gets visited by a deletionist, good-bye.

So editors are driven to "cite bomb" in order to protect content they've spent time researching and writing. Philcha (talk) 15:49, 7 June 2008 (UTC)

Yes, I sympathise, I am not necessarily blaming editors for engaging in it, I am simply noting the tendency over time for an increasing number of cites to be added to articles. I know of one case, for example, where an editor has basically stopped submitting articles to GA because she disagrees with the number of cites she is now expected to add to her articles.

"Cite bombing" seems to be a growing trend and I am simply suggesting a method by which its impact can be reduced. Gatoclass (talk) 17:04, 7 June 2008 (UTC)

[edit] File upload instructions

I noticed the instructions for uploading images don't make it clear that the image needs to be on the editor's computer first. I've noticed several times on the help desk where people have had difficulty uploading fair use images, and have gone "Oh! I didn't know that" when told to download it from their source first; or they have tried to add HTML <img...> tags into articles to externally link images. A clarification to the file upload instructions might reduce this type of help desk query. Astronaut (talk) 16:35, 6 June 2008 (UTC)

It would be better to have the software give a useful error message when someone tries to insert an <img> tag or upload a URL -- the vast majority of users aren't making those mistakes, so we shouldn't clutter up the instructions to deal with the unusual cases. --Carnildo (talk) 19:55, 6 June 2008 (UTC)

[edit] 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)

[edit] 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[6] kind of external link linking to part of Wikipedia itself; a previous version of a page. Now I personally think that that is a bit clunky, I mean, using an external link to link into Wikipedia itself? It should be much more smoother.

So I propose that instead of external linking we create a new namespace (or more accurately, an interwiki redirect called maybe diff:, prev: or edit:, I'm not fussed) and then when linking to a diff we use that namespace and the page id instead. Now many people right now may be going huh? and scratching their (hopefully) computer literate heads so I will endeavor to explain how this would work.

NOTE: Throughout this I will be using the diff: namespace/redirect as an example, this can be substituted for whatever you think is the best; its not permanent.

Ok, say X wants to show someone a previous version of a page he made, he could

1. type out (or copy/paste) http://en.wikipedia.org/w/index.php?oldid=3432489 and shove some [ and ] outside it and give it to his friend, or
2. simply type (or copy/paste) [[diff:3432489]] or [[diff:3432489|name of link]]. That would give a direct link to the old page in question without having to type all of the Wikipedia address. It would even work cross project e.g. to meta [[m:diff:3432489]].

Now that is all well and good for just a single id, but what if you want to compare (diff) fuction? Well, I have thought of an idea for that too. All you'd do is something like [[diff:left column id-right column id]], I'm not fussed about what symbol separates the left column id and the right column id. And to help users who would just copy/paste the url of the diff/oldid in question, in the heading of older pages (in this case "Math rock") it would say "Math rock (diff:3432489)" or if your comparing "Math rock (diff:left column id-right column id)".

Now I have a feeling people will say Why do we need this kind of thing?, well I thought of several reasons,

1. when search engines come to Wikipedia and try to index the pages, if they come across an external link they get hit with the robot.txt NOFOLLOW tag (meaning that the robot will not go into that link and check out that file) and;
2. I just think it makes more sense, I mean, when linking to anything else internally we use [[page]], [7] tags have be adopted as the defacto diff linking system, they should follow the conventions that all other internal links follow.
3. It reduces the clutter when listing many links on the same page.

ADITION TO PROPOSAL: Possibly move the diff access link from an index.php paramenter (e.g. /w/index.php?oldid=344&diff=45354) to the wiki space (e.g. /wiki/diff:344-45354).  Atyndall93 | talk  01:12, 8 June 2008 (UTC)

Feel free to change as you wish; I am open to improvements. Thankyou for listening. Happy editing!  Atyndall93 | talk  05:38, 7 June 2008 (UTC)

1. Diffs and oldids are already deliberately excluded from search engine results regardless of whether a link has nofollow attributes by robots.txt which blocks everything in /w/ and by meta tags in the page.
2. Regardless of the form of the link you're still going to have to copy and paste something containing a horrible oldid. I wouldn't object to a template which expands the oldid parameters to a working URL, the code to which could be displayed for copying on the diff page, but the extra bloat on those pages might not be worth the savings in editbox bloat.

That's my opinion. BigBlueFish (talk) 15:47, 7 June 2008 (UTC)

The idea's neat, though in implementation this might be tricky, as it is not only diff id that matters but also oldid, and there are always the special cases. For example, diff=9&oldid=5 shows the difference between revision 5 and revision 9, whereas diff=prev&oldid=5 shows the difference between revision 5 and the previous revision for that page (as revision ids are not contiguous for the same page) with a similar difference for diff=next and I'm not sure how we'd integrate the syntax considering those variables as well. Nihiltres^{t.l} 16:38, 7 June 2008 (UTC)

With my idea diff=9&oldid=5 would be something like [[diff:5-9]] and diff=prev&oldid=5 would be [[diff:prev-5]].  Atyndall93 | talk  01:12, 8 June 2008 (UTC)

Turns out a shorthand is available as {{diff}}. Since search engine indexing is not wanted for oldids, I see no reason to change the URLs; a preconstructed code for the diff template on the diff page itself might be useful if there's demand. BigBlueFish (talk) 17:41, 7 June 2008 (UTC)

That template still uses external linking (with the plainlinks class) though I I think its a bit clunky.  Atyndall93 | talk  01:12, 8 June 2008 (UTC)

I don't have any advice on the technical details of how to do this, but I do agree that something should be done. The current system of entering a whole URL is awkward, and I would prefer to point to a diff using an in-line citation instead of a superscript. --A Knight Who Says Ni (talk) 17:50, 7 June 2008 (UTC)

• It's a nice idea in theory, I suppose, but it'd create a huge trashyard of diff: namespace pages that would never ever be referenced. I think we're up to something like 50 or 60 million total edits so far. How many of these are likely to be referenced? -- Anonymous Dissident^Talk 18:06, 7 June 2008 (UTC)

  The word "namespace" is confusing - the proposer is suggesting something more along the lines of a specialized interwiki that would link to wikipedia diffs, much the way that we have a special interwiki for Google searching. {{Nihiltres|talk|log}} 18:58, 7 June 2008 (UTC)

  Yes, it wouldn't actually create the pages, but it would appear that way.

It sounds good on the surface, but BigBlueFish makes a good point. Which is easier? Copy and pasting a URL or using an interwiki, which would mean copying the oldid and the diff oldid separately? The diff URL also has the context of the page title in it usually. Mr.Z-man 03:49, 8 June 2008 (UTC)

In the proposal I suggested having the title show "Title (wikilink for diff/oldpage)" type thing where the text in the brackets is the relevant wikilink for that diff or old version of a page. E.g. (diff:3493-3433) means that its comparing oldids 3493 and 3433. So you wouldn't have to copy/paste the oldids separately as when viewing a comparison page both are listed in the correct format, so you just copy/paste the stuff listed in the brackets (it could be placed anywhere on the page really). e.g. if you typed [[diff:3493-3433]] you would get that exact comparison. And in reply to the context of the links, the actual page name is irrelevant (if you remove it from the link, the link still works) and if you wanted to show name that link you could say [[diff:3493-3433|oldid of random page]] which has the same level of context as a normal diff because normally a [ ] type link just shows up as [8], 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)

[edit] 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)

[edit] A database on user's past records: a page to watch for these things

I think that we could improve transparency by making it easier to locate people's records of disruptive (at least in some people's mind) behavior. Requests for Comments on users and other relevant information should be easier to find. Unless they are particularly easy to find besides through searching and I just don't know about it? Now, searching is OK, but it requires some effort and thought, and it is not comprehensive -- a search for Requests for User <user> does not give me other relevant results like Arb decisions Wikiquette alerts ect. I know that many people will be uncomfortable with this idea, but it is for the best. ImpIn | (t - c) 10:56, 7 June 2008 (UTC)

A glance at a user's talk page and their recent contributions is all you need to know about a user. If they are acting disruptively, then their history of disruption will be clear from the talk page. However, most users are good, and bad users can change (especially considering the large contingent of teenage users). On the whole, there is no merit in judging the character of a user unless they are deliberately trying to undermine the project, in which case they should already be banned if there's been any past attention to them. BigBlueFish (talk) 15:35, 7 June 2008 (UTC)

The users talk page should be used within reason. It also should never be read as a rap sheet. True a malicious or 'bad' user will have a talk page propagated with warnings and notices, but also a 'good' or innocent user who gets tapped by a bot (moving or redirecting pages named like Bob Sagot used to trip the fagot warning on a antivandal bot) or runs into an over active twinkle user will have a talk page filled with the same warnings. Users who work with controversial topics, will often have warnings or notices from users who may have agendas. People should always look at specific edits (within the context of the subject space and not just a raw diff) to establish a regular pattern of behavior. --Samuel Pepys (talk) 22:06, 7 June 2008 (UTC)

Also, because of the Assume Good Faith guideline, we tend to have a "forgive and forget" system when it comes to things like this. If we keep "rap sheets" for every user, people may never be able to live down incidents in their past. Mr.Z-man 21:00, 7 June 2008 (UTC)

I expected to hear these kinds of responses, and I don't think they hold water. First, looking at a User's Talk page should not be endorsed as a proxy for a user's record. Disruption notices can be taken off of talk pages, and these notices are often made in error, as noted. For example, I recently got a "warning on 9/11 simply because the editors who think they own the article didn't bother to carefully read my edit or its references (they cited conspiracy theory; there was no such thing). People who are attempting to judge a user's character on the Talk page need to be strongly reminded of the problems with that approach. Looking at a user's past contributions is terribly time-consuming and inexact; many users use bots to pad themselves with thousands of trivial edits, which are difficult to sift through. Lastly, I don't have time to keep close watch on Requests for Admin and Requests for Comment User; if I could watchlist a page where these are posted, it would make life much easier for me. I worry that Wikipedia is segregated into groups who perform certain functions: some patrol AfD, some patrol RfA, ect., but when you have a system like that you don't necessarily get input from the most relevant people. There are lots of users for whom I would want to be immediately notified if a Requests for Admin or a Requests for Comment came up, but as it stands, I currently only have a small chance of finding that out, since I can't watchlist these people's talk pages, and don't have want to watchlist RfA since most of the people I do not have time to investigate and comment on. And I don't think that "assume good faith" means that we should forget past indiscretions. Assume it, sure, but if it has been tested, people should be allowed to easily find that out. There needs to be accountability. Right now we seem to rely upon the memory of individual users to keep people in line, and I don't think that's sustainable. ImpIn | (t - c) 23:57, 7 June 2008 (UTC)

[edit] Edit this page versus add new section

The sensible way to edit a large, oft frequented discussion page is by clicking on 'new section' or the 'edit' link next to the section of interest. Otherwise, one must search for the relevant section within the edit window and deal with the horror of edit-conflicts. Currently on pages like the Science Reference desk et al., the 'edit this page' link is bold and the 'new section' link is regular, leading to me accidentally being drawn to the bold link when I want the regular one. Indeed, I imagine few people ever need the 'edit this page' button on the reference desks. I suggest that the 'new section' link is made bold and the 'edit this page' link is made regular, so that people are drawn to what is probably the correct link out of the two. ----Seans Potato Business 17:29, 7 June 2008 (UTC)

It sounds sensible, but... Can this be done for a single page? Waltham, The Duke of 20:13, 7 June 2008 (UTC)

How about doing it for all talk pages and pages with __NEWSECTIONLINK__ on them? – FISDOF9 23:54, 7 June 2008 (UTC)

[edit] 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)

[edit] 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)

[edit] Creation of New Negotiation Board in the Dispute Resolution Process

I have noticed that there is a current hole in the negotiation step of DR that none of the current processes cover. I would like to propose that a new board be created for disputes which range over multiple articles but which don’t require the intervention of administrators and in which both parties are civil. Most of these types of threads get posted at ANI even though it is specifically mentioned in the ANI header that ANI is not part of the DR process. RFC works great for a single article but when there is the same dispute on multiple articles it falls outside the scope of RFC. The only processes that are currently set up to handle such a thing that are part of the DR process is Wikiquette alerts and that only applies if a party is uncivil. To my understanding ANI is mainly to report abuse that requires administer intervention that is too complex for AIV but in which there is no real dispute. All you have to do is take a quick look at ANI to realize that even though there is a notice there that specifically says its not part of DR people ignore that and post disputes there anyways. If we are not to create a new board to deal with this type of dispute then I think we should consider adding ANI to the dispute resolution process as that is what is happening anyways. --Nn123645 (talk) 14:01, 8 June 2008 (UTC)

[edit] 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)

[edit] 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)

[edit] Restrict the "move subpages" feature to admins

This idea has been bounced around the noticeboards ever since the "move subpages" checkbox, sometimes referred to as the "recursive move" feature, was added to MediaWiki in rev:33565. The ability to move a page, its talk page and up to 100 subpages all in one action, has been quickly seized upon by a number of pagemove vandals (see 1, 2, 3, 4). With careful choice of targets, the feature enables a vandal to move up to 800 pages before hitting the pagemove throttle, which is supposed to limit non-admin users to 8 moves/min. There has been discussion in various places (1, 2) about restricting this feature to administrators only, and in rev:36038 Simetrical added the technical means to do this. What do we think? Happy‑melon 19:54, 8 June 2008 (UTC)

Restrict it to admins. The feature is virtually useless here (it was added at the request of Wikibooks, not Wikipedia) - the only people who are going to have a need to move subpages on a regular basis are bureaucrats when changing usernames (and they will be unaffected by a change as they are all admins). Hut 8.5 20:04, 8 June 2008 (UTC)

Restrict it to admins, clearly. There are way too few cases where it would be useful for individual users to need this here. —Simetrical (talk • contribs) 21:16, 8 June 2008 (UTC)

Restrict it to admins, the uses here are so few (the only thing I can think of would be moving an article where the talk page has archives, which doesn't happen often), there's no need for almost all users to have this. Mr.Z-man 23:03, 8 June 2008 (UTC)

Support the restriction--I found it hard to believe this was available generally. If Wikibooks wants to use it more generally, they can do so. DGG (talk) 04:46, 9 June 2008 (UTC)

Too easily abused, much harder to revert than to do. Restrict it to admins, and possibly bots. _{1 != 2} 23:05, 8 June 2008 (UTC)

Support I've moved plenty of pages, but never needed to simultaneously move a subpage at the same time (sometimes I'm had to move an article talk page archive, but that's no big deal). I suggest restrict to admins. AndrewRT(Talk) 00:03, 9 June 2008 (UTC)

• Support restricting to admins, little or no utility to non-admins, tremendous facilitation of hard-to-clean-up vandalism otherwise. NawlinWiki (talk) 03:38, 9 June 2008 (UTC)

[edit] Proposal to rename each "List of basic ______ topics" to "Outline of ______"

Each one of the Lists of basic topics is more like an outline than a mere list.

I would like to rename them as outlines.

For example, List of basic geography topics would become Outline of geography.

It just seems more professional, and I've always felt that the lists of basic topics were awkwardly named. Referring to each as an "outline" is clearer, crisper, and more familiar to our general audience than a "list of basic topics". The latter just sounds weird, tacky, and contrived. I apologize for naming them that in the first place (yes, it's my fault). I just couldn't think of anything else at the time. Sorry.  :)

The change would include updating any self-references on these pages as well. (Where each refers to itself as a "list" would be changed to "outline", for consistency).

One of the problems with the current titles is recurring contention over the word "basic", and what constitutes a "basic" topic. Renaming the pages would eliminate this problem. The simplification would also remove the word "topics" from the title, which is another awkward element (it's superfluous).

Since there are a lot of them (see Lists of basic topics), I thought it would be best to ask you first.

May I rename them, please?

Sincerely,

The Transhumanist    21:41, 8 June 2008 (UTC)

I find "Outline of foo" much less clear than "List of basic foo topics". Removing the "basic" from "basic foo", however, would certainly be acceptable as a means to stop those debates you mention. {{Nihiltres|talk|log}} 23:22, 8 June 2008 (UTC)

However, if it's not a list of basic topics, isn't it a portal? BigBlueFish (talk) 23:53, 8 June 2008 (UTC)

That's an interesting point, not because I agree with it or disagree with it, but because it suggests a viable alternative. Why not move these lists to the Portal namespace? {{Nihiltres|talk|log}} 01:40, 9 June 2008 (UTC)

I agree with your essential point, that "List of Basic Geography Topics" is patently not how a general audience would describe it! Sounds like jargon which should be ditched AndrewRT(Talk) 00:05, 9 June 2008 (UTC)

Why didn't I think of that? The Portal space is underused, even though this is exactly what it was made for. Paragon12321 (talk) 04:19, 9 June 2008 (UTC)