Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The proposals section of the village pump is used to discuss new ideas and proposals that are not policy-related (see Wikipedia:Village pump (policy) for that).

Recurring policy proposals are listed at Wikipedia:Perennial proposals. If you have a proposal for something that sounds overwhelmingly obvious and are amazed that Wikipedia doesn't have it, please check there first before posting it, as someone else might have found it obvious, too.

Before posting your proposal:

• Read this FAQ page for a list of frequent proposals and the responses to them.
• If the proposal is a change to the software, file a bug at Bugzilla instead. Your proposal is unlikely to be noticed by a developer unless it is placed there.
• If the proposal is a change in policy, be sure to also post the proposal to, say, Wikipedia:Manual of style, and ask people to discuss it there.
• If the proposal is for a new wiki-style project outside of Wikipedia, please go to m:Proposals for new projects and follow the guidelines there. Please do not post it here. These are different from WikiProjects.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

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 ") was added at the end of the summary and then let admins view all versions of the edit summary. -- Imperator3733 (talk) 20:29, 12 May 2008 (UTC)

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

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

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

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

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

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

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

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

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

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

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

Straw poll

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

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

Support

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

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

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

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

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

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

12. Support - offensive summaries or summaries that reveal personal data are a big problem, but right now there is no way of editing them except for deleting the edit completely... which is not a solution most of the time. Figure out a way to prevent abuses, but it should be implemented. Renata (talk) 21:51, 24 May 2008 (UTC)
13. Support I also like this idea but I can definitely see the problems it might introduce. If this is ever implemented, I think it should be restricted to auto-confirmed users and above. Perhaps there could be a feature that allows sysops to revoke a user their right to editing their summary. Also, it should definitely be possible for the user's last edit and only for a set time. ——Ryan | t • c 08:43, 16 June 2008 (UTC)

Conditional Support

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

Oppose

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

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

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

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

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

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

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

19. Oppose Edit summaries serve the use of giving a reader a general idea of what the editor did. They are not extremely important. After all, the reader can always compare versions and see exactly what happened between those two versions. Constantly changing edit summaries would be confusing to the reader ("Wait--what? Didn't it just say something else a minute ago?") and would also serve for another place for vandals. Edit summaries are not that important! Like I said before, no one's going to change exactly what you did to the page, which is most important. IceUnshattered (talk) 00:12, 10 June 2008 (UTC)

    I am still waiting for an explanation how this feature could be used for vandalism under the proposed restrictions. I would also be interested how you came to the conclusion that editors would "constantly changing" their summaries under those restrictions. I disagree that summaries are not important, we have them for a good reason, i.e. to make life easier, and again, this proposal is for correcting accidentally misleading and confusing summaries. Cacycle (talk) 00:50, 16 June 2008 (UTC)

20. Oppose otherwise what we end up with editors sanitizing their edit summaries as part of the lead up to RFA, RFB or ARBCOM. Yeah ok we all leave the odd spelling/typo error but live with it why waste server load with editors changing edit summaries. Gnangarra 04:10, 17 June 2008 (UTC)

    Please check the following "Short break" section for the actual proposal. You will see that it would not be possible to sanitize edit summaries. Cacycle (talk) 23:05, 17 June 2008 (UTC)

21. Oppose I think any possible wasting of time over editing edit summaries or even the possibility of misuse or confusion in doing this easily outweighs the (to my mind) negligable benefits. Davewild (talk) 20:58, 19 June 2008 (UTC)

Short break:

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

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

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

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

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)

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)

<-- Image that may be used if accepted -- penubag  (talk) 04:33, 12 June 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)

As penubag said, the "live preview" version is the wrong image! the one he suggested is shown in the image above that (the screenshot).
—Apis (talk) 03:17, 12 June 2008 (UTC)

That's right. I uploaded to avoid confusion (if this is accepted, I'll tweak the contrast, if necessary)-- penubag  (talk) 04:33, 12 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)

---

I actually like the idea of having the W on a white "piece of paper" background! The problems with the current version are:

• No border around the letter, the W has direct contact with the surrounding
• The icon has no boundary, the white background melts into the usually gray surrounding
• The W is somewhat blurred

I have been playing around with smaller W's and I really like the following one:

     

The W has a one pixel white separator and the bottom-right dark border gives it an optical boundary as well as a nice 3D effect. I have tested different background colors (including black) and it looks good on all of them. Cacycle (talk) 05:13, 12 June 2008 (UTC)

---

The W on the puzzle piece is so small as to be basically just a grey blob, and I've got 20:20 vision. I wouldn't mind seeing the puzzle-piece icon used, but the letter has to be big enough to be easily recognisable. You can't trademark a jigsaw piece. Happy‑melon 14:58, 18 June 2008 (UTC)

Move the search box directly beneath the puzzle globe

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

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

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

You can try this out in your own browser by adding

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

to your monobook.js. You can also type

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

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

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

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

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

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

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

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

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

 

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

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

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

• Expand the discussion

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

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

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

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

See http://stats.grok.se/ eg [1]. -- 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)
  • Actually, half the links of the first two boxes ("navigation" and "interaction") are quite important for readers. And frequency of use is not really a factor; it is important that the reader's eye can go straight to the box, not that it should cover the least distance from the monitor's top. Light goes from the fastest road, not the straightest; this is similar. Waltham, The Duke of 01:22, 18 June 2008 (UTC)
• Support. --Wikinaut (talk) 13:13, 6 June 2008 (UTC)
• Oppose per EVula and LtPowers above. Like they said, the search box provides a clear distinction between the nav/interact boxes, which may be used by anyone, and the toolbox, which is mainly used by editors. Without the search box in its current position, this distinction would be lost and it would be more difficult to find a particular link. The search box is fine in its current position and does not require scrolling to locate, except for those who use lower-resolution displays. Kal ^(talk) 22:04, 6 June 2008 (UTC)
• Support- I can navigate the boxes OK and it's irritating to have to scroll down to reach the often-used Search box. -- SEWilco (talk) 17:01, 7 June 2008 (UTC)
• I am neutral regarding the location of the box, but would be against any proposal to have two of them on the main page (the current one in the left sidebar plus a new one for the main page only).
• Support -The way I see it, if I have to look for it sometimes, and I come here every day, then other older and newer will have trouble. —Preceding unsigned comment added by Leonard^Bloom (talk • contribs) 03:12, 12 June 2008 (UTC)
• Support - This will make things a lot easier for many; I'm not sure if the veterans in opposition are really putting themselevs into the shoes of a brand new user. The first thing they'll see is the logo, and, hopefully, with a new format, the second thing will be the search box right below the globe. -- Anonymous Dissident^Talk 13:38, 14 June 2008 (UTC)
  • You are an old user... Do you consider your judgement more accurate than ours as far as the way newcomers view Wikipedia's layout is concerned? :-) In any case, I strongly disagree with the view that people read a screen like a book page, line by line, top-to-bottom. A newspaper or magazine page would be a more accurate analogy: people first look at the most distinctive elements (in printed press that would be headlines, pictures, and captions). In the case of the main page, not only is the search box as conspicuous as it can be with its current formatting because it breaks the sidebar's pattern of link boxes, but it would be overshadowed by the bold lettering of the logo right above it. The move could actually make the search box less conspicuous. Waltham, The Duke of 01:22, 18 June 2008 (UTC)
• Support - Excellent aesthetic improvement. Jeff Carr (talk) 16:22, 16 June 2008 (UTC)
• Strongly Support - Good usability should be a prime objective of every website and that means following design conventions where they exist and placing the search where the visitor expects it. The current position violates usablity guidelines which state that the search should be placed at the top of the screen. I see no rhyme or reason for placing the search where it currently is. This should be a no brainer. --Wolbo (talk) 21:11, 16 June 2008 (UTC)
  • Yet it is not. And I agree as far as the top of the page is concerned, and there are indeed many websites placing their search bars right at the top. However, the top of the sidebar is not the top of the page. We are talking about very different layouts, and the comparison here is rather poor. Waltham, The Duke of 01:22, 18 June 2008 (UTC)

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)

Just to jump back in to comment on the GFDL issue, I don't think that's a big deal. I don't think anyone is likely to make an issue out of such a technicality. (If we're going to be hypertechnical, maybe the GFDL requires that "history" be capitalized!) But after reviewing the GFDL, I don't think it requires that the tab be named history, as long as the page title is named History. Even if there was a ruling that there had to be a link called "history" to the article history, we could probably create a second link called history somewhere on the page, and keep the tab named something else (as kludgy as that sounds). --Groggy Dice T | C 21:01, 21 June 2008 (UTC)

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

We all know what "revision history" means, but some readers might think it means "revisionist history". rspeer / ɹəədsɹ 18:18, 10 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)

Support 'Revision' seems most appropriate. Old discussion was not as convincing. Jeff Carr (talk) 16:27, 16 June 2008 (UTC)

Support The German Wikipedia's menu bar makes more sense to me, and I'm not even that good at German. 'Revision'/'Log' sound like pretty good names if it was changed. Leonard^Bloom (talk) 19:07, 17 June 2008 (UTC)

I don't have a current opinion on the title.. but we could conduct some kind of test or survey to see which possibility is best understood. We could, for example, change it for some subset of the visitors to the site and see which one generates the most usage. Or we could perform a survey where people are asked "which of these would you look at to determine..." ... I think we'll get better results if we test rather than guess. --Gmaxwell (talk) 19:29, 17 June 2008 (UTC)

I think the first option (the change and review) is a very good one. Visitors may feel the survey is intrusive. Leonard^Bloom (talk) 19:56, 17 June 2008 (UTC)

Brackets around citation numbers

With what appears to be the growing acceptance on this project of what I call "cite bombing" - that is, the addition of a cite, or multiple cites, for every sentence, and sometimes every clause of a sentence, I am finding it increasingly difficult to read some articles, because of the amount of "clutter" that the cites 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 intrusive indeed. 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 brown fox jumped over the lazy dog.

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

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

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

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

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

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

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

And in most cases, it seems like its just other editors trying to be difficult by requesting citations far in excess of what policy actually requires or demanding citations on every sentence even when the citation at the end of the paragraph cites what they demand be sourced. Mr.Z-man 16:22, 9 June 2008 (UTC)

I think that we are creating something new and revolutionary at WP, and we should consider being revolutionary in our approach to footnotes. The current schemes have evolved with the limitations of print and the logisitics of a printed page. I think that some people are a bit anal about citing, but in some cases a critical paragraph could need a citation per sentence or more, where two sources supply the facts for multiple assertions in the sentence. I really like the idea of removing the brackets and allowing multiple sources to be cited under one footnote. --Kevin Murray (talk) 15:10, 13 June 2008 (UTC)

Hi. I've seen on the French Wikipedia, cites are small, kind of like this¹²¹⁴. However, this could cause problems because we don't know if the cites are 1,2,14 or 12,14 or 121,4 or 12,1,4, etc. I like the idea of making them less cluttered, though. ~AH1^(TCU) 16:48, 15 June 2008 (UTC)

The numbers don't matter. Just a dot?^* Or, perhaps a dash is even less innocuous.^- Could the mediawiki be modified to not underline the citation link? Jeff Carr (talk) 16:59, 16 June 2008 (UTC)

The numbers don't matter if you're only going from the claim to the citation; but you'd get into an awful mess if you wanted to edit one particular citation (redlink, deadlink, typo, whatever) and couldn't work out which one it was. In fact, though, not having the numbers will cause problems when the reference list is short and right at the bottom of the article, as browsers won't be able to jump far down enough to put the citation on the first line. I'll have a look at fr.wiki's implementation - I guess it must be a MediaWiki page or something in their .css or .js. I'd have thought that removing the braces and just leaving spaced numbers would be a Good Idea^TM. Happy‑melon 19:13, 19 June 2008 (UTC)

Numbers are also needed for those who print out pages. As for cite-bombing, I understand the concerns, but I think WP suffers more from under citing than overciting. Since we are only a tertiary source, containing no original research, and no one should be citing us, then we must provide cites for our statements. If a paragraph contains several facts from a variety of sources, or facts which might be disputed, or are not in common knowledge, then they must each be cited. If they clump together too much, with too many ideas in one sentence or short paragraph, then perhaps it is a prose issue rather than a citation issue. That said, if there was a way of making the cites smaller without affecting their readability, that would be a good solution. Gwinva (talk) 19:52, 19 June 2008 (UTC)

I've had a look, and it's just a trivial CSS tweak: they wrap the braces in a separate css class, then hide it in their common.css. I've added the classes here (called cite_braces here) - you can imitate the fr.wiki appearance by adding the following lines to your monobook.css:

/* Hide braces around references */
.cite_braces { display:none }

The system would be vastly improved if a spacing between the numbers could be maintained: I'll have a play on test.wiki. Happy‑melon 19:55, 19 June 2008 (UTC)

Improvising on Random article

Dear Sir/m'am, This is with respect to a very good facility provided by Wiki Side bar in Main site i.e. The Random article. During my use of the aforementioned I have noted a tendency of the "Randomiser" to land onto page which I myself ,per se ,have no interest in .These include subjects like place names and Counties and Schools. I propose a facility for the registered and frequent user to be able to select a range , not too specific, of subjects that interests that particular PERSON. This may be recorded as a javaBit next to the "Random article" tag. A Maximum of 6 to 7 (with option of choosing 2 not more), with memory facility(ie The Ability to retain the choices in next LOGIN would be optimal IMHO. I do not know how articles are indexed in Wiki <myself not trained in Computers>.However as in such cases the numbers of the Key index pertaining to A SPECIFIC ARTICLE will have a correlation w.r.t. the TAG that it holds (History , Natural Science , Politics , Psychology , Fine Arts , linguistics etc.) and the same may be used here, if POSSIBLE.

I hope due consideration may be given to this thought.

I remain,

Yours Sincerely

ChimesM --Chimesmonster (talk) 06:24, 8 June 2008 (UTC)

We should probably either mark "Improve Special:Random" as a perennial proposal or else figure out a way to do it (the latter would be nice, I wouldn't mind being able to look up a random article within a category). I suppose we might add a category parameter for it and have a separate link beside the normal randomiser to give a list of some of the high-level categories you can select (something like: "Random article (pick type)". An editable (but presumably protected) page could be reserved to maintain a list of eligible categories, I guess (not sure if there is much caching to worry about in this regard).

That's a random idea anyway, probably someone can think of a better way to do it! --_{tiny plastic} Grey Knight ⊖ 07:53, 10 June 2008 (UTC)

Check out Wikipedia:Link intersection -- a proposal to create a tool to find similar articles based on them sharing the same wikilinks. -- ☑ SamuelWantman 07:02, 15 June 2008 (UTC)

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

Major rename proposal of certain "lists" to "outlines"

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

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)

Except that "Lists of topics" (without the "basic") are comprehensive in scope, and have a tendency grow to include thousands of topics. The "Lists of basic topics" weren't designed for that - increasing their scope would ruin them. The Transhumanist    08:24, 9 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)

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)

These outlines were designed as a set, as a form of table of contents to Wikipedia, with each outline following a standard design. Navigating them is easy because they are all organized in the same way. Whatever namespace they are assigned to, they should be kept together as a set.

Portal space is underused in part because it isn't included in Wikipedia's default search parameters. That's probably because the deluge of portal subpages clutters search results when portals are included in searches, making the results of those searches almost unintelligible. Moving these lists to portal space would essentially bury them. And we wouldn't want to do that. Besides, portals follow an entirely different design philosophy, and serve different purposes than this set of outlines.

Portals belong in portal space. Regardless of what we rename these pages to, they're still lists, not portals, developed according to the list guideline, which defines them as "structured lists". There are many structured lists besides those in this set, and they're sprinkled all around Wikipedia. As stand-alone lists, they are a form of article. Articles, including lists, belong in article space.

So how about it... may I change their titles to "Outline of ______"?

The Transhumanist    07:44, 9 June 2008 (UTC)

We tried moving them to portalspace at Wikipedia:Move navigational lists to portal namespace, but it failed to attain consensus (due to a number of reasons: primarily because the portal namespace isn't included in default searches making the lists hard to access, but also because some bad examples were used at the beginning of the discussion (eg Lists of mathematics topics a former featured list)). -- Quiddity (talk) 20:13, 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)

List of basic history topics is another of my favorites. The Transhumanist    08:42, 9 June 2008 (UTC)

The format was modified a bit for countries. Check these out: Albania • Argentina • Australia • Canada • Ecuador • Egypt • France • Germany • Iceland • India • Indonesia • Iraq • Ireland • Italy • Isle of Man • Israel • Japan • Macau • Mexico • Russia • Taiwan • United Kingdom • United States The Transhumanist    09:14, 9 June 2008 (UTC)

I'd agree with the change, especially for these large topics. For smaller lists it might be a bit of a bold term, but I think its worth standardizing the titles. Thanks for all your work on these lists, by the way. Lists are in my mind the best way to navigate Wikipedia -- or at least navigate a complex topic. And when you look through them, they can help you structure your thoughts and remember better. ImpIn | (t - c) 09:50, 9 June 2008 (UTC)

You're welcome. I'm glad you like them. The Transhumanist    03:10, 10 June 2008 (UTC)

Could not "Topic (overview)" or "Overview of Topic" be possible renamings, as an alternative to "outline"? --MASEM 13:56, 9 June 2008 (UTC)

That would conflict with the current title of the Portal:Contents/Overviews page. -- Quiddity (talk) 20:35, 9 June 2008 (UTC)

And "overview" doesn't pertain to format, just to scope. For example, core articles are overviews of their subjects. The article "Geography" is an overview of geography. The title alone would not imply that someone couldn't add prose to the body of an overview. The word "outline" is a format designation. The Transhumanist    13:20, 10 June 2008 (UTC)

The word "outline" is complicated because of its other "silhouette" meaning: Outline of Italy is quite confusing as a title.

How about changing to "List of core ____ articles"? Retaining the "list" designation is clear, accurate, and useful, because it defines what standards the lists need to meet, and describes the contents accurately. E.g. List of core history articles and List of core geography articles.

Alternatively, "main" or "essential" or "key", instead of "basic" or "core". E.g. List of main Ireland articles or List of key education articles or List of essential history articles.

Or swap the word order for something like List of core articles in geography.

Just some thoughts... -- Quiddity (talk) 20:35, 9 June 2008 (UTC)

Outline of Italy topics is not confusing, which is what it would likely be named. ImpIn | (t - c) 04:42, 10 June 2008 (UTC)

I don't care so much about the labels of the Portal:Contents classification system as I do the structure. This discussion seems to be about what's contained under Portal:Contents/Lists of basic topics and Portal:Contents/Lists of topics. I would be perfectly fine with Template:Contents pages (header bar) calling these links Outlines and Indexes, respectively. If that classification clarification means resorting what's included on each page, then all the better. If some leftover links seem to suggest a new type of page or so, then we're getting closer to arranging the encyclopedic topics by the various forms of page structures represented under Portal:Contents. That sounds like a good thing to me. As far as stylistic names go, "Outline of _____ topics" and "Index of _____ topics" works for me. RichardF (talk) 19:50, 12 June 2008 (UTC)

Topical outline

Good points. You got my mental juices flowing...

"Key", "core", "essential", and "main" would invite the same problem as "basic" from the sourcing diehards who from time to time question the verifiability of the "basicness" of the items in one of these lists. I've tried looking for sources, and it is a real pain in the... head. Going around looking for sources for the topics' "coreness", or "keyness", etc. would be just as daunting.

Using "articles" in the titles makes them a little inconsistent with their contents, because the list may (and many do) contain redlinks. A topic can be red and still be a topic, but articles can't be red and still be articles.

You've given me the idea of combining the initial proposal with your idea of swapping the word order. This would fix the ambiguity problem for countries. For example: "Topical outline of Italy". "Topical outline of" would also be less likely to duplicate a title from the real world, and therefore would be good to use for all the subjects, not just the countries. The Transhumanist    01:58, 10 June 2008 (UTC)

Upon trying it out on a bunch of subjects, this phrase looks, sounds, and feels encyclopedic:

• Topical outline of culture
• Topical outline of music
• Topical outline of literature
• Topical outline of geography
• Topical outline of history
• Topical outline of Italy
• Topical outline of Japan
• Topical outline of the United States
• Etc.

And its meaning is consistent with how its used on the Internet. (See Google).

The Transhumanist    01:58, 10 June 2008 (UTC)

I don't like prepending "topical". "Outline of geography topics" sounds so much better to me than "Topical outline of geography". ImpIn | (t - c) 04:42, 10 June 2008 (UTC)

But the plural tense doesn't fit well. "Outline of geography topics" means "outline of more than one geography topic", while "Outline of geography" clearly means "outline of the subject of geography". But "Outline" by itself looks funny in front of country names, though I believe Wikipedia's readers are smart enough to know what context is intended. I prefer "Outline" too. But some have expressed concern over the ambiguity of the word. Therefore, we need to find a compromise that works equally well for all subjects. "Topical outline" fits. It's contextually accurate. I can't find any other term that describes these pages as precisely as "Topical outline" does." The Transhumanist    20:54, 11 June 2008 (UTC)

Strongly support. "Topical outline of ___" works very well. It would also result in Category:Topical outlines which would match perfectly with the existent Category:Topical indexes. (unless there are any even better suggestions...?) -- Quiddity (talk) 05:30, 10 June 2008 (UTC)

Uh, no, I think "topical outline" is too vague, and the word "outline" itself is ambiguous. The "outline of Italy", for example, is a shape like a leg with a boot on it. I don't see much wrong with what we've got now. Gatoclass (talk) 06:46, 10 June 2008 (UTC)

How is "topical outline" vague? I thought it was pretty clear: "Outline of a subject comprised of its topics." The Transhumanist    13:28, 10 June 2008 (UTC)

Come to think of it, our competitors have outlines. Worldbook places outlines at the ends of articles. Britannica published an outline of the whole of human knowledge. But as far as I know, neither of them publishes outlines as articles. We do! But you can't tell they are outlines by reading their titles. For these structured lists, the word "List" in their titles doesn't convey the essence of what they contain. There's no indication of structure. A list may be unsorted, sorted, or topically arranged, but you can't tell which from its title. All three types are clumped together under the same name: "List". The Transhumanist    13:38, 10 June 2008 (UTC)

Outline of Italy articles does not convey the sense that we're talking about the country's geographical shape. I don't see it as confusing. Like I said, I oppose prepending topical just because it seems wordy to me. If It is simply "outline of <something> articles", then I'm OK with it. Although strictly speaking the word "outline" is best for structured lists, an "outline" which is simply a categorized list is, technically speaking, also an outline. ImpIn | (t - c) 00:44, 11 June 2008 (UTC)

How about one of Geography (contents), Geography (table of contents), Contents (geography) or Table of Contents (geography)? Bluap (talk) 02:11, 11 June 2008 (UTC)

Don't like those very much either. What's wrong with "Outline of geography articles"? ImpIn | (t - c) 09:29, 11 June 2008 (UTC)

"Table of contents" just doesn't capture the essence of these pages. These pages can serve as tables of contents, true, because of their links. But they don't stop there. These outlines go way beyond the scope and format of a table of contents and include a lead section/introduction, annotations and data, maps and pictures. Each one also has a see also section, and an external links section. These are articles (as defined in the list guideline) and their focus is the world outside Wikipedia - they present the structure of subjects, not the structure of Wikipedia. The Transhumanist    09:38, 11 June 2008 (UTC)

ImpIn, "outline of articles" conveys the meaning of an outline of multiple articles. "Outline of Italy articles" appears to mean that it is an outline of multiple articles about Italy. These aren't outlines of articles, they're outlines of subjects.

With respect to wordiness, "Topical outline of Italy" has four words and nine syllables, while "Outline of Italy articles" has exactly the same: four words and nine syllables. They're equally wordy.

"List of basic Italy topics", the current name of that page, has nine syllables too, but it has five words instead of four. It's definitely wordier. The Transhumanist    09:38, 11 June 2008 (UTC)

I don't particularly care that much. I see from Google that it is fairly common to create "topical outlines"; the verbiage doesn't quite please me, but I'll let it pass with a neutral. The content is what actually matters. ImpIn | (t - c) 09:53, 11 June 2008 (UTC)

Keep in mind that we'll always have the option of removing the word "topical" later, if the community felt strongly enough that the word was unnecessary. (Though I believe the pun "Outline of Italy" will always bother someone). Therefore, I suggest we move forward with "Topical outline of". The Transhumanist    20:54, 11 June 2008 (UTC)

• Support. -- Quiddity (talk) 04:42, 12 June 2008 (UTC)
• Support, except where "Index" is more appropriate (see below). --OscarTheCat3 (talk) 20:09, 13 June 2008 (UTC)
• Support -- The Transhumanist    20:59, 13 June 2008 (UTC)

 Done The Transhumanist    07:07, 16 June 2008 (UTC)

Adjective such as 'basic' or 'core' vs. no adjective

• Argument against using such an adj.: There are sometimes battles over which topics are or aren't 'basic'.
• Arguments for: Without such an adjective, many readers AND editors will assume that this article is supposed to be a list or outline of all of articles on this subject. Editors will be much more likely to constantly add minor topics, based on this incorrect assumption. If the list is intended to be limited, the title should reflect this in some manner. ike9898 (talk) 20:35, 12 June 2008 (UTC)

The line "The following outline is provided as an overview of and introduction to foo:" deals with the problem by defining the scope of the page. If editors go rampant and start warping the scope of these pages by adding everything under the sun, we could add "basic" back in to the titles, but that probably won't be necessary... Outlines choked with topics lose their usefulness as outlines and cross a line to become topical indexes. Also, you've currently got someone (me) who watches over these pages. So if anything goes wrong, the community will be alerted. By me.  :) The Transhumanist    22:51, 12 June 2008 (UTC)

We have a List of basic chemistry topics, which given the meaning of basic within chemistry, might be seen as the counterpart of the List of acidic chemistry topics! --Itub (talk) 10:07, 13 June 2008 (UTC)

Some other puns that result are basic programming, basic English, basic research, basic law, basic training, basic role-playing, basic education, basic service, and basic instinct :). The Transhumanist    20:32, 13 June 2008 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Indexes

Index to foo topics perhaps? Just another thought. OscarTheCat3 (talk) 21:06, 11 June 2008 (UTC)

Interesting that you should bring this up. Wikipedia does have some alphabetical indexes:

• Lists of environmental topics
• List of geography topics
• List of history topics
• Lists of law topics
• List of mathematics articles
• Lists of philosophy topics
• List of politics topics
• List of psychology topics
• List of Japan-related articles

To name a few. While "Index of" would not fit most lists, such as structured lists or small lists, it would be appropriate to rename extensive alphabetical lists to "Index of ____ articles". The Transhumanist    21:29, 11 June 2008 (UTC)

Need indexes necessarily be alphabetical? Skomorokh 00:59, 12 June 2008 (UTC)

Not necessarily (but usually, see Index and wikt:index); however, there is a large set of articles that currently follow this scheme. See Category:Topical indexes for all 436 of them. -- Quiddity (talk) 01:31, 12 June 2008 (UTC)

(edit conflict) At one point I even considered whether an Index: namespace might be appropriate for many of the List of foo articles articles. The drawback to that approach, obviously, is that the most useful wikilinks in those articles would then become cross-namespace wikilinks.

I think Skomorokh raises an excellent point: indices need not be alphabetical. Truly, most are, because it tends to be easier for a human to locate a specific entry in an ordered list than an unordered list, and the Latin alphabet provides a familiar ordering mechanism. Nonetheless, "classified" or "topical" indices do exist. (Indeed, the whole of Wikispecies is an index of living things.)

I may be opening another can of worms entirely here, but don't many of these "lists of foo topics" (in articlespace) redundantly repeat Category:foo (in categoryspace)? AfD could have a field day. --OscarTheCat3 (talk) 20:44, 12 June 2008 (UTC)

Thanks for correcting my grammar, Transhumanist, but "redundantly repeat redundantly" was intentional. "Repeat" alone would suffice, of course. --OscarTheCat3 (talk) 19:36, 13 June 2008 (UTC)

Please don't edit other people's comments for minor typing/grammar errors. See the second sentence of Wikipedia:Talk page guidelines#Editing comments: "It tends to irritate the users whose comments you are correcting." There's a list of standard exceptions below. -- Quiddity (talk) 21:18, 13 June 2008 (UTC)

Yup, a whole different can of worms. They're mostly for the benefits of wikiprojects, but also aid the occasional reader (see intro wording in many, such as List of Andorra-related topics (which is also an example of a "classified" index)). See WP:TRIFECTA for details, as to why they aren't taken to afd ;-) (they would just get moved to projectspace, and thereby get used less (less easily found, less motivation to update, ...)) -- Quiddity (talk) 21:42, 12 June 2008 (UTC)

WP:TRI -- you mean the DBAD principle, specifically? :-) --OscarTheCat3 (talk) 19:36, 13 June 2008 (UTC)

Not especially. IAR, if anything specific. I meant the page as a whole (irreverent, contextual, eventualist, adults-only, ambiguous). This place contains a lot of mess, and it should be a bit of a mess for at least another x number of years. M:Immediatism is the greatest cause of harm to our community, in most cases (imho, and a completely different topic). -- Quiddity (talk) 21:18, 13 June 2008 (UTC)

See the guideline Wikipedia:Categories, lists, and navigational templates which addresses the issue of redundancy. Lists are beginning to take the role of an upgrade over categories, with superior presentation formats, annotation and image support, non-link data, the convenience of scrolling, searchability, redlink support, etc. (Lists of basic topics are a good example because they utilize all of these features). Should one system replace the other? The category system shouldn't be eliminated from Wikipedia because it is useful for gathering links and building the superior lists. Lists in turn are useful sources for updating categories. Lists are a lot easier to work with (they're easy to combine, divide, or to copy and paste sections to or from them - you can't directly edit categories) and lists make categories easier to work with: lists can be plugged into AWB to update categories, which is much faster than updating those categories by hand. The two systems (lists and categories) are synergistic, and complement each other. The Transhumanist    22:42, 12 June 2008 (UTC)

Excellent point, and one I had not considered: this need not be a case of either/or, but rather and/also. Frankly, I wasn't aware WP:CLN existed. I never read the whole of the MoS either, as I didn't realize there might be a quiz later.  :-) For what it is worth:

* Support moving List of X topics/articles to Index to/of X topics/articles where appropriate (and of course, creating redirs in their place). --OscarTheCat3 (talk) 19:36, 13 June 2008 (UTC)

I also support "Index of (basic) foo topics" (topics not articles, to limit scope and allow for redlinks). This is based on the assumptions that the non-alphabetical use does not jar with other uses of the word "index" across Wikipedia, and that readers won't be surprised at finding a non-alphabetical link. Transhumanist, Quiddity, what say ye? Skomorokh 09:18, 15 June 2008 (UTC)

The (basic) part shouldn't be required anywhere, those are completely seperate projects (the indexes aim to be exhaustive, the basic lists aim to be core/basic only).

But yes, I would support a move of all the "List of foo topics" articles in Category:Topical indexes to either "Topical index of foo" or "Index of foo topics". (I prefer the first, as it matches the category name, and means the keyword is always at the end of the line (as with "Topical outline of foo"). -- Quiddity (talk) 21:22, 15 June 2008 (UTC)

I agree with Quiddity that the index project or proposal doesn't apply to the basic lists. The outline structure, lead section prose, annotations, images, charts, maps, external link support, and limited scope of the basic lists makes them very distinct from indexes. As the outlines become more developed, their structure will become even more refined - and they will further diverge from indexes, and this can easily be seen in the country outlines. For example, the presentation of the structure of a branch of government wouldn't be retained in an index, and describing a page with this type of content as an index would be very misleading. Here's the executive branch section from the List of basic Japan topics:

---

Executive branch of the government of Japan

Present Kantei, office and residence of the Prime Minister.

• Symbol of state: Akihito, Emperor of Japan
  • Emperor has no executive authority, but is treated as a head of state under diplomatic protocol
  • Controversies regarding the role of the Emperor of Japan
  • Emperors of the past
• Head of state: de facto head of state of Japan is the head of government, the Prime Minister (see below)
• Head of government: Yasuo Fukuda, Prime Minister of Japan
  • Kantei (Office and residence of the Prime Minister)
  • Prime Ministers of the past
• Cabinet of Japan
• Ministries of Japan
  • National Public Safety Commission
  • Ministry of Internal Affairs and Communications
  • Ministry of Justice
  • Ministry of Foreign Affairs
  • Ministry of Finance (Japan)
  • Ministry of Education, Culture, Sports, Science and Technology
  • Ministry of Health, Labour and Welfare
  • Ministry of Agriculture, Forestry and Fisheries
  • Ministry of Economy, Trade and Industry
  • Ministry of Land, Infrastructure and Transport
  • Ministry of the Environment
  • Ministry of Defence

---

I think the lists of topics that are obviously indexes and not outlines should be renamed to "Index of foo articles". An index is a directory of subjects covered in a specific work. Imagine a book that had an "index" that listed topics that weren't covered in the book. Its index would no longer fall under the definition of index. An "Index of topics" in a book would be assumed to present topics included in the work the index supported, and would default to "Index of articles" in connotation - and this same principle applies to Wikipedia. Which brings us to the issue of redlinks. Upon thinking it over, redlinks are a core feature of Wikipedia, and aren't out of place, even in an index. Like all pages on Wikipedia, indexes are works in progress, and redlinks simply designate planned articles. Therefor, "Index of foo articles" fits better than "Index of foo topics". The Transhumanist    22:14, 15 June 2008 (UTC)

Perhaps a broader discussion is needed

I find most of this discussion to be very pertinent and wonder if a broader discussion of lists, portals, categories and other methods of navigation should be undertaken. I've been concerned that categories will soon need to be overhauled when category intersection is fully implemented. It is already possible to find the intersection of categories using search, but because we do not have broadly populated categories (most get diffused into small categories), the feature is not very usable. I'm hoping that we can create "index categories" that will be very broadly defined. It might help to try and rethink how we might want to reshape categories, lists, etc... as part of an general overhaul of navigating around Wikipedia. The problem is that there seems to be resistance to any form of overhaul because of the overwhelming inertia of the status quo. However, if there is interest, I'd be happy to discuss this with others, to see if we could come up with a new scheme for organizing things. Perhaps a subject or two could be reorganized according to the scheme as a test project. -- ☑ SamuelWantman 07:20, 15 June 2008 (UTC)

2 things.

• You might be interested in reading through Wikipedia:Portal peer review/Contents/archive1 and Portal talk:Contents. I haven't had the time/energy, but I keep meaning to bring this all up with the V1.0 folks, to see what they think. See particularly the lists at Portal talk:Contents#Things to consider and Portal talk:Contents/TopicSystems.
• I'm stuck on the idea of placing our four internal "See also" types of content together (the See also links, the categories, the footer navboxes, the sister-project linkboxes). It'd be nice they weren't forced apart by the references/external links sections.

That should distract you for a while ;) -- Quiddity (talk) 21:33, 15 June 2008 (UTC)

Broader discussion? OK. See below... The Transhumanist    07:13, 16 June 2008 (UTC)

Index-builder bots

The creation of index category pages is interesting in theory, but maintaining them would be extremely difficult because categories have no tracking feature. And not being able to edit them directly is also a major impediment. Redlink support is also missing. Index pages are much easier to develop and maintain, in part because the category system can be mined by AWB in gathering links for index pages. Perhaps bots can be created for mining categories, inserting the links found in them into index pages, and then automatically sorting the index pages. This would allow index pages that included all the links from the relevant categories, as well as any links that editors added by hand. Redlinks would also be supported, as the bots would only add to indexes, not delete items from them. The Transhumanist    22:49, 15 June 2008 (UTC)

I find this comment to be very telling. Pehaps, after 4 years of working on categories, we may end up concluding that lists were better to begin with. I find the lack of tracking and the inability to easily revert category changes to be be flaws that prevent the categorization system from improving past its current so-so condition. Editable lists (or indexes or whatever we call them) have many advantages. The only disadvantages when compared to categories is that it takes more work to add an entry to a list from an article you are working on, and lists cannot be used to do database searches, which is now minimally possible with categories, and will be more likely in the future. Perhaps the entire scheme needs rethinking. Categories seem to be most useful as a database. If we were to only put articles in top level single attribute categories, they would be much more useful for creating intersections. If all the categories were transcribed by bots into lists and thus archived as you describe, it would be much improved. While we're at it, the process should work both ways. There should be bots that can restore a category to a previous state by comparing the current population with the archived state. This would mean that lists (or indexes as you call them) would once again become the primary way of navigating through articles. Categories would be used for database functions ad data mining.

We might want to think about adding an "Index" namespace for all these lists. You could add an "Index" entry to an article and it would add the article to an index just as it now adds it to a category. Index pages could be edited just like an article, and would contain links to all the articles that are so indexed. If you do not organize the links, they would be automatically be added to the bottom of the page in an "Unsorted entries" section. The software would keep track of all the pages linked from the index. If someone adds a link to the index, it automatically gets added to the article. If you add the link to the article, it automatically gets added to the index. I'd guess you'd want them removed the same way. This way the change could be reverted at either end. There could be an area for listing indexes that appears just above the category listings at the bottom of articles. I would guess that the default for this would be that they would not be seen unless you clicked on "Show indexes", like many navigation boxes. Many indexes could be created by mining category intersections. I think this has possibilities. -- ☑ SamuelWantman 01:54, 16 June 2008 (UTC)

Except for including redlinks, a lot of this sounds like it could be solved with a CategoryTree. Example below. The whole topic deserves a new/separate thread though. -- Quiddity (talk) 18:42, 16 June 2008 (UTC)

Philosophy

The search box, revisited

Is anybody else annoyed by the pop-up suggestions that appear when one types something into the search box? What annoys me is that the suggestions cover/override the actual "search" button itself. 69.140.152.55 (talk) 14:44, 9 June 2008 (UTC)

If you register an account, you can turn this feature off in your preferences. And this isn't really a proposal. Mr.Z-man 16:27, 9 June 2008 (UTC)

You know, I'm willing to bet that the "cover/override" bit is more the symptom of a faulty browser. — CharlotteWebb 15:51, 10 June 2008 (UTC)

Doesn't just override the go & search buttons on IE, it does it on Safari too. I suggest the symptom of inadequate testing before implementation. I would add that blaming the most widely used browser in the world (by a very long way) for display problems is not terribly helpful. Do we want to be "Wikipedia - the encyclopædia that doesn't work on most PCs?" DuncanHill (talk) 11:25, 11 June 2008 (UTC)

It covers the button in the same way the search history box built into most browsers would also cover the button. The search box works just fine, you can press Enter on your keyboard or click outside the search box to make the suggestion box go away, and the search button still works, it isn't "overridden." Mr.Z-man 05:13, 12 June 2008 (UTC)

Sorry, I seem to have misunderstood the problem. As Z-man says, you can make it disappear by clicking outside it ("Esc" on the keyboard works for me). If anybody has an idea for how to rearrange things to avoid this, they should say so. I can't think of one at the moment. — CharlotteWebb 16:12, 18 June 2008 (UTC)

Useroval

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

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

What was it that you were wondering? I don't understand. If you want to make a userbox that uses this then I guess you can (although I think creating them in the User: namespace is the recommended best practice nowadays). What are you asking? --_{tiny plastic} Grey Knight ⊖ 15:07, 14 June 2008 (UTC)

I think he's asking to have the template imported to Wikipedia for use here. — The Hand That Feeds You:^Bite 18:35, 14 June 2008 (UTC)

ok	Okay, it's in my userspace if anyone gives a flying squirrel.

--_{tiny plastic} Grey Knight ⊖ 08:45, 16 June 2008 (UTC)

Anti Harassment Unit

Stalking is costing Wikipedia contributors. Many qualified productive contributors have left Wikipedia due to persistent harassment. Therefore it is causing a serious problem and opening the Foundation up to liability. This issue is not new and its existence can not be denied. Already, at least two deaths have occurred due to cyber harassment. If the situation continues in its laissez faire state, people could die. We must act now to prevent further emotional harm. We need to send a message to these stalkers that no matter where they hide, no matter who they attack, we will not stand for this any longer. These anonymous cowards must face justice.

I am proposing the creation of a Anti Harassment Unit. This unit shall be run on a system similar to Abuse Reports. Upon receiving a report, it shall be investigated. If probable cause exists of harassment, a second member shall make contact with the ISP and police forces. All actions will be publicized, most likely on an external website, and will be released to the press.

Thoughts? Geoff Plourde (talk) 06:35, 15 June 2008 (UTC)

. Especially the "two deaths," as you're implying they're due to Wikistalking. — The Hand That Feeds You:^Bite 12:13, 15 June 2008 (UTC)

I am not implying they are due to wikistalking. There have been two deaths resulting from social networking sites. I am stating that we must act before someone dies because of wikistalking. Geoff Plourde (talk) 00:28, 16 June 2008 (UTC)

So, two people have died from online stalking in the entire 25-year history of the Internet. Is this really something we should be worried about? --Carnildo (talk) 04:30, 16 June 2008 (UTC)

The two deaths I referenced were teenagers. Those are just the two I can think of at this point. And this is in the history of social networking sites (About 8 years). Even one death is too many. Geoff Plourde (talk) 06:09, 16 June 2008 (UTC)

I trust you do not own a car, and your house has neither a bathtub nor a staircase? Each of those causes more than two deaths per day. --Carnildo (talk) 06:22, 16 June 2008 (UTC)

This is not something the community should be responsible for -- we'd wind up looking like rather impotent vigilantes, which would only be embarrassing. If anybody should do it, the Foundation should. Perhaps you should petition them about it. — Dan | talk 04:28, 16 June 2008 (UTC)

The Foundation has already shown over the past seven years that it will do nothing. The community has the authority to make decisions concerning itself. This is one of those decisions. Geoff Plourde (talk) 06:13, 16 June 2008 (UTC)

Problematic there as people are understandably reluctant to give information publicly so members of the community turned to a mailing list to address this and enable discussion about how to address the problem editors on Wikipedia. This collapsed after trusted admins were vilified on WP:AN/I over issues relating to stalkers. For any editor all they can do is;

• Ask for assistance at WP:AN/I
• contact the foundation,
• If necessary seek police assistance

That said it is something the community needs to address but the discussions need to be on a noticeboard and any action needs consensus. Gnangarra 04:55, 16 June 2008 (UTC)

Well, the problem is that we need to strike back at stalkers. The reason they are so bold is because all that happens is talk talk talk. That is all the noticeboards are good for. If consensus exists to make a external mailing list for reporting only, I see no problem with it. The time for words is past, the time for action is now. Geoff Plourde (talk) 06:13, 16 June 2008 (UTC)

How about a "report this page"/"report this user" button everywhere, similar to forums and Facebook and stuff? Admins could then receive a job-list type thing if they set it up in their preferences. ╟─TreasuryTag (talk ╬ contribs)─╢ 21:00, 16 June 2008 (UTC)

This might be a better idea.. Geoff Plourde (talk) 01:04, 17 June 2008 (UTC)

First, you'll have to demonstrate that this is actively a problem on Wikipedia. Right now WP:ANI handles harassment claims and I've seen nothing to indicate we need a new board to deal with that subject. — The Hand That Feeds You:^Bite 22:09, 18 June 2008 (UTC)

Gah, no more noticeboards. WP:DFT applies here too, if we have some sort of system for this, it should be a private mailing list, but not so private as the wpcyberstalking one, more like unblock-en-l. Mr.Z-man 22:45, 18 June 2008 (UTC)

There's a huge difference between the level & extent of stalking & harassment which can result from social networking sites, where users typically divulge personal information including their name, email address & photograph, and any equivalent on a Wiki site with anonymous users. I cannot foresee Wikipedia-based cyberstalking resulting in any deaths. Sure, harrassment should be taken seriously when it occurs, and perpetrators' user accounts should be suspended or blocked, but I don't think that involving ISPs or the police is justified. Weasel Fetlocks (talk) 11:20, 19 June 2008 (UTC)

Well, the harassment is escalating to death threats. We need a coordinated method of shipping those cases off to law enforcement. A semi private mailing list staffed by people who know what they are doing would probably work. Geoff Plourde (talk) 02:57, 20 June 2008 (UTC)

Please cite examples of harrassment escalating to death threats. Weasel Fetlocks (talk) 10:04, 20 June 2008 (UTC)

Durova and David Shankbone both have received death threats. Geoff Plourde (talk) 02:52, 21 June 2008 (UTC)

Inactive users

Sometimes when I search through a list or category of users (for example: members of a wikiproject, some-language-speaking users category...), for contact, most of the time, I end up posting for inactive users. I started the habit to check before posting, the contribution page of each user to see whether he's still contributing or not. But It's a tedious task. I know this is not the right place to post this (I think it's Bugzilla, but I don't know how to post there) but I think it would be useful to add some indication about whether a user is active or not. Maybe it could be a sign which appears at the top, bottom, or on the side bar, when visiting a User page. The sign could be either a active/inactive button, or just mention when his last edit was. But what I also prefer, is that links to inactive (or active) users are highlighted in some colors (just as broken links or stubs are colored in red) to indicate their status (what should be considered active depends on a setting in the preference page). What do you think? Eklipse (talk) 16:38, 15 June 2008 (UTC)

I think it'd be too much server load to have everyone's contributions being checked constantly to see how long ago it's been since they last edited. Perhaps a script you could run as needed would be more appropriate. — The Hand That Feeds You:^Bite 18:24, 15 June 2008 (UTC)

Thank you. I added a request at Wikipedia:WikiProject User scripts/Requests#Checking for active users. Eklipse (talk) 03:42, 17 June 2008 (UTC)

Grawp Eradication Program (GEP)

Hi. I would like to propose a set of steps to reduce or eliminate Grawp behaviour on Wikipedia. Below are a list of possible reccomendations:

• Putting captcha on all page moves
• Limiting pagemove to 3 a day for users with less than 100 non-move edits AND/OR allowing excessive moves only to administrators OR give this as a userright
• Upgrading Cluebot to automaticly revert ALL common Grawp-like behaviour, including edit summaries, moved pages, and insertion of megabyte images
• Giving a bot administrator status that automaticly blocks Grawp vandals, deletes and salts the pagemove vandalism title, and move-protects the page, and puts its actions into a category database for admins and other users to look over OR the bot automaticly reporting suspected Grawp behaviour to AIV, no warnings nessecary
• Having some users monitor Encyclopaedia Dramatica activities, aquiring any clues about which users are Grawp sleepers and blocking them
• Implementing a MediaWiki that gives an error page whenever Grawp-like edit summaries are used (eg. "For great justice and epic lulz", anything containing on.nimp.org)
• Giving administrators a function allowing rollback of all contributions, AND/OR allowing admins to give other users this userright, AND/OR allowing rollback of page moves rather than plain reverts
• Allowing users to use their monobook to filter out recent changes to include only "Recent moves"
• Allowing moving of a userpage or entire userspace ONLY if the username had been changed AND/OR create an error message when moving a main userpage belonging to another user with a high amount of contributions to a mainspace page, especially ones containing Grawp-like capital letters (eg. WANT TO HAVE SEX WITH GRAWP, GIANT DICK MAKES HUGE ORGASMS, etc)
• Create MediaWiki error messages for ALL detected Grawp-like behaviour

So, any opinions? I would appreciate your input. Remember these proposals are for reducing or eliminating Grawp attacks, so please discuss on which ones are most easily accomplished and effective, or present your own ideas. Thanks. ~AH1^(TCU) 17:18, 15 June 2008 (UTC)

Um... a lot of these are really unreasonable, and some are just placeholder tactics. A blacklist for edit summaries might be handy, but your idea of an admin bot will never get off the ground. We don't need a bot for that; we generally grab Grawp pretty quickly anyway. Editing MediaWiki just for Grawp... no, I'm sorry, but that's not very likely to happen. EVula // talk // ☯ // 17:38, 15 June 2008 (UTC)

(ec) Cluebot is already doing a great job catching Grawp. We've changed the autoconfirmed to require a certain number of edits, which seems to have significantly lowered the amount of vandalism. Grawp uses Unicode characters that make things hard to target. To me, this seems unnecessary. But I'd like to hear from someone who's been more active in vandal-fighting. Grandmasterka 17:39, 15 June 2008 (UTC)

Agree with EVula. This is nothing new, and he doesn't cause any more disruption than WoW, Oompapa etc did. There are far worse problems affecting Wikipedia. I don't think any Grawp account has ever been active more than 2-3 minutes. – iridescent 17:41, 15 June 2008 (UTC)

After thinking about it a bit more, it would be nice to have a one-touch "revert everything" button that undoes all a user's pagemoves and rollbacks their edits all at once; that would be plenty handy, and more effective in dealing with Grawp-level vandalism than some of the other suggestions. EVula // talk // ☯ // 17:42, 15 June 2008 (UTC)

Same here. Though I worry about the potential for unhappy accidents with "nuclear rollback". I would only support it if the mass-rollback could itself be all undone at once. Grandmasterka 17:47, 15 June 2008 (UTC)

I like the idea of 'rollback on steroids' and an edit summary blacklist, at least that should stop Grawp & co. putting shock site references in edit summaries. RichardΩ612 Ɣ ɸ 17:54, June 15, 2008 (UTC)

While I like some ideas, I strongly disagree with a blacklist on edit summaries. If people want to make terrible edit summaries, I would rather it be known and in the public over they not being allowed to. Those kinds of things are huge parts of the arguments at WP:RFA and a technical barrier is not the way to go. Besides, like all blacklists, it just becomes a new game to get around. I mean, Grawp has been shifting his tactics quite a bit and like the other major vandals, it's pretty idiotic in general. I mean, those guys are a ton better than the guys who do sneaky vandalism for long periods of time. -- Ricky81682 (talk) 18:12, 15 June 2008 (UTC)

A captcha on all page moves is massive overkill, probably less than 1% of pagemoves are grawp and a captcha would also affect users reverting his moves. You can monitor ED all you want, but I'm pretty sure they aren't dumb enough to just list the accounts they use, I don't know what "clues" you could "acquire" from their discussions. I have a script that reverts all a users pagemoves, it only seems to work in FF3 now (I also have one that deletes the redirects left over, but its ... buggy) if someone wants to take a copy and make it suck less, User:Mr.Z-man/moverevert.js is the move-only one and User:Mr.Z-man/movereverttest.js has redirect deletion. The problem is detecting "Grawp-like behavior" with no false positives. A captcha on pagemoves, or restricting moves to a new user group are really the only things that would have an appreciable affect and wouldn't require significant software changes, but the benefits are far less than the costs. Mr.Z-man 18:25, 15 June 2008 (UTC)

As a proof of concept I built a module out of off the shelf code that ended up recognizing 87% of all letters which translated into 14% of words pairs on wikipedia captcha's. Low yes but computers don't care about efficiency too much. --Samuel Pepys (talk) 18:30, 15 June 2008 (UTC)

I like the idea to put captchas on page moves. We could add captchas if a user moves more than, say, 3 pages in 5 minutes, and only if that user is in no special group (To exclude Admins, Rollbackers and so on). --Conti|✉ 18:54, 15 June 2008 (UTC)

There is a master rollback script written by VoA for use by admins. It reverts all top edits, and all page moves by a user. Just need the password and a couple clicks to confirm. KnowledgeOfSelf | talk 20:39, 15 June 2008 (UTC)

As for Cluebot helping, please see the pages in this announcement. This technique may be effective for special automated reverting of the sock-puppeteer. 209.244.31.53 (talk) 02:38, 19 June 2008 (UTC)

Point by point comments:

• Putting captcha on all page moves
  • Signal to noise doesn't justify this, and there are bots which move pages that are approved, which this would cause many issues with.
• Limiting pagemove to 3 a day for users with less than 100 non-move edits AND/OR allowing excessive moves only to administrators OR give this as a userright
  • This doesn't help stop Grawp, whose accounts are only active for 30secs tops after he starts moving. One per minute (ie. one page and its talk page) would be better.
• Upgrading Cluebot to automaticly revert ALL common Grawp-like behaviour, including edit summaries, moved pages, and insertion of megabyte images
  • Would cause more trouble than good. Detecting what is "Grawp behaviour" isn't easy, as it's so dynamic.
• Giving a bot administrator status that automaticly blocks Grawp vandals, deletes and salts the pagemove vandalism title, and move-protects the page, and puts its actions into a category database for admins and other users to look over OR the bot automaticly reporting suspected Grawp behaviour to AIV, no warnings nessecary
  • No, per above.
• Having some users monitor Encyclopaedia Dramatica activities, aquiring any clues about which users are Grawp sleepers and blocking them
  • Not likely to do anything beneficial, but feel free to do so yourself.
• Implementing a MediaWiki that gives an error page whenever Grawp-like edit summaries are used (eg. "For great justice and epic lulz", anything containing on.nimp.org)
  • Possible, but StN may still be a tad low - he'll just use "F0r gr3at" etc., as he does with pagemove destinations now.
• Giving administrators a function allowing rollback of all contributions, AND/OR allowing admins to give other users this userright, AND/OR allowing rollback of page moves rather than plain reverts
  • Maybe if it could only be used for contributors with < X edits - accidentally clicking "rollback all" on an established account would be terribly disruptive and a pain to fix.
• Allowing users to use their monobook to filter out recent changes to include only "Recent moves"
  • If someone comes up with a script then sure, each person can decide.
• Allowing moving of a userpage or entire userspace ONLY if the username had been changed AND/OR create an error message when moving a main userpage belonging to another user with a high amount of contributions to a mainspace page, especially ones containing Grawp-like capital letters (eg. WANT TO HAVE SEX WITH GRAWP, GIANT DICK MAKES HUGE ORGASMS, etc)
  • Just contact an administrator to do it. Userspaces, a case of "meh".
• Create MediaWiki error messages for ALL detected Grawp-like behaviour
  • Per ClueBot reason.

Daniel (talk) 04:21, 16 June 2008 (UTC)

I concur with Daniel here on most points. The suggestion about blocking Grawp sleepers makes me wonder about how the media is going to perceive that. (Blocking based on ED?) Geoff Plourde (talk) 06:18, 16 June 2008 (UTC)

I don't think the media will care, just as the media doesn't care about most of Wikipedia's internal workings (unless you count The Register and Valleywag as "the media"). The main problem with monitoring ED is that it will be almost entirely pointless and if you publicize it like this people on ED might start providing false information. (people don't think they read these threads?) Mr.Z-man 16:52, 16 June 2008 (UTC)

Not only that, but "what will the media think?" should never be the primary factor in how we behave ourselves. We shouldn't be blind to such things (ie: we should be fully aware that blocking an IP for the US Senate might generate noise), but we should never shy away from doing what's right by our rules just because it might cause a huff. I can't imagine anyone but ED caring if we block people "per ED". EVula // talk // ☯ // 18:24, 16 June 2008 (UTC)

Evula, I meant that what are people going to say if they see us using a parody site for information on whom to block. Geoff Plourde (talk) 00:26, 17 June 2008 (UTC)

Since when do they care about internal minutiae like that? Mr.Z-man 03:55, 17 June 2008 (UTC)

"less than 100 non-move edits" - please fix to "fewer than". I do agree with the ideas above, plus the fact that whatever we do can fairly easily be outdone by those behind Grawp, by their changing of tactics. As easy is it is to forget, there are people behind |Grawp - not some unconscious bot who we can outcode. Some nice ideas though, but I feel they'll give undue attention to those behind this - what they want(?). Also, WP:DENY. Thanks, Martinp23 18:40, 16 June 2008 (UTC)

Hi. How about move-protecting all pages that are either high-traffic, a target for vandals, or featured, that definitely don't need moving without discussing first? This might not prevent move-vandalism, but it might reduce it slightly? Or, should pages not be move-protected simply because they "don't need moving"? Thanks. ~AH1^(TCU) 20:34, 16 June 2008 (UTC)

It's pretty complicated, but I discussed the move-only userright on IRC before, we have to stop giving him what he wants, seriously. As for ED, I'm way ahead of ya. BoL (Talk) 21:21, 16 June 2008 (UTC)

I'm working on something a little more targetted. — Werdna talk 09:12, 17 June 2008 (UTC)

• You all seem to have forgotten that we're supposed to deny recognition and not feed the trolls. If grawp reads this, how much is it going to stoke his ego?--Jac16888 (talk) 10:40, 17 June 2008 (UTC)
  • They are just essays, though. However, I would agree with you to the extent this should be about general changes to improve the project, rather than just how to "eradicate" one user George The Dragon (talk) 14:10, 17 June 2008 (UTC)

Why not just put ourselves in a straight jacket and give him the key as a trophy? An autoblocker bot is a good idea, I think we have already disabled recursive page moves. One way to defeat him is to not give so much attention. _{1 != 2} 14:13, 17 June 2008 (UTC)

What is a Grawp??? When I look it up on Wikipedia, I only get the Harry Potter character. On Wiktionary, nothing. If Grawp is an accepted internet/usenet term like 'troll', shouldn't there be an entry explaining it? Weasel Fetlocks (talk) 13:13, 20 June 2008 (UTC)

It's a group of people vandalising Wikipedia under a variety of accounts by moving pages to titles containing words related to Grawp, e.g. hagger etc. Tra (Talk) 16:15, 20 June 2008 (UTC)

Multiple levels of autoconfirm to handle trolls

Right now, there are 3 basic categories of normal-user accounts:

• Anonymous, not logged in, cannot move or create pages
• New accounts: cannot create pages, not sure about moving
• 3-day-old accounts: can create and move pages, I think with per-limits to prevent rapid-fire spamming

More granularity in autoconfirm will help:

• New-ish accounts or semi-active accounts should be limited to a few page moves a day not counting page moves entirely within their own userspace.
• New-ish accounts or semi-active accounts should have large-image uploads "embargoed" so they aren't visible until an administrator has looked at them.
• New-ish accounts or semi-active accounts should prevent someone from adding more than a certain amount of text to an article at once. Make the person do 2-3 edits if he wants to add 1MB to an article. Have a blanket exception if the new size is not much bigger than any recent edit, so new users can still undo blanking vandalism.

As straw-values, "New-ish" would be anything with less than 10 days old, anything with less than 100 edits, or anything with less than 5 edits in the last year. Obviously these numbers are a straw number and will need tweaking to meet the needs of the project. davidwr/(talk)/(contribs)/(e-mail) 17:33, 20 June 2008 (UTC)

Add "censor edit summaries" as a user preference

Allow users to set a preference so edit summaries will be censored for words on a blacklist set by the user. If the user wanted to, he could include global blacklists, such as {{Wikipedia:blacklist-dirtywords}}, {{Wikipedia:blackwords-offensive}}, {{Wikipedia:blacklist-vandalphrases}}, user blacklists such as {{User:MyBestFriend/Blacklists/religiousinsults}}, or his own blacklists.. There would also be a check-box "Fuzzy - block look-alike letters" which would do just that. Censored words would show up just as "xxxxxx" or something. davidwr/(talk)/(contribs)/(e-mail) 17:33, 20 June 2008 (UTC)

Well, based on a report at WP:ABUSE, I don't think any kind of blacklist is going to help since I personally believe that Grawp is some kind of professional spammer off wiki just because a lot of those IPs are known spammers according to http://www.trustedsource.org, and considering that those IPs are from all over the world, I'm guessing that Grawp isn't a real person but rather an army of zombied computer systems launching an attack at the Wikimedia Foundation. If my hypothesis is true, then blacklists won't do a darn thing since spam bots dodge spam filters on a regular basis using complicated techniques that are way too advanced for a simple blacklist invented by a bunch of Wikipedians to defeat. If we blacklist the edit summaries, he'll probably start using normal appearing edit summaries that make it more difficult for us to detect him at all. Spammers running bots like the Storm Worm have cursed many websites for many years, and none of them have found it easy to combat them without getting tough on them, and getting tough on Grawp is something that I don't think WP is going to do unfortunately. GO-PCHS-NJROTC ^(Messages) 22:30, 21 June 2008 (UTC)

You're giving him far too much credit, most of the IPs he uses are dynamic dialup or DSL IPs. If they're on spam lists its because they change owner every day or when they reset their modem. He posts on the talk pages of Encyclopedia Dramatica and 4chan to get people to vandalize, which is why the IPs appear to be from all over. Some people might use open proxies to conceal their own IP. If he was running an automated botnet he'd be able to operate more then one account at a time. Professional spammers and botnet operators try to make a profit, I don't see how pagemove vandalism does that. Mr.Z-man 23:02, 21 June 2008 (UTC)

You could be right, but although pagemove vandalism isn't that profitable, it could be a spammer testing out a new technique of some kind on WP before he does it in the world of email or blogs. Also, I do believe Grawp mentioned websites in some of her/his vandalism, correct? The bottom line is that, like Storm Worm, Grawp is a mystery; we really don't have any idea what his/her point is, and why we really care, I don't know. I agree that we're givin' him/her too much attention; he ain't worth our time. GO-PCHS-NJROTC ^(Messages) 23:11, 21 June 2008 (UTC)

Named references in infoboxes

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

Are you sure that the ref in your example was used in the infobox? I did this (having the full ref in the infobox, and the ref name later) in the South Dakota article, for the area, and it turned out alright. Often when the 'cite error' thing appears, it is a problem with the ref name, as in it wasn't copied properly or something; I don't know that the problem is having it in the infobox. AlexiusHoratius (talk) 18:02, 15 June 2008 (UTC)

Use {{#tag:ref|content|name=foo}} instead of <ref name="foo">content</ref>, and you can bypass the bug. Also, make sure that the template or the reference itself at least, for transcluded, default references, is wrapped in <includeonly> and </includeonly> at the template page. {{Nihiltres|talk|log}} 22:19, 15 June 2008 (UTC)

Oooh! Nifty. Does that mean refs can now be generated during the template-processing phase? Also, wouldn't a {{#tag:references}} then be necessary? -- Fullstop (talk) 19:02, 16 June 2008 (UTC)

You have two problems:

• In the infobox, you had <ref name=NBA.com> and in the body, you had <ref name=NBA.com />. Your ref name must be in quotes: <ref name="NBA.com">.
• You are using {{Infobox NBA Player}} and entering the reference in the field for "nickname". The problem is that this infobox does not have a nickname field, thus the first reference is not being transcluded.

--—— Gadget850 (Ed) ^talk - 19:25, 16 June 2008 (UTC)

Fullstop, no. {{#tag:foo}} based tags work exactly the same way as other tags, just their content gets parsed differently (i.e. is parsed rather than just passed through as literal). A {{#tag:ref}} reference will work with <references/> exactly as though it were a <ref>. It's wonderful; give the devs a hug. :D {{Nihiltres|talk|log}} 21:05, 16 June 2008 (UTC)

DOI

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

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

New poll to establish consensus about autoconfirmed status

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

Spammers :(

Hi, Please delete the Users with less than 10 edits (or so)and are absent in Wikipedia for more than a year.

Today I saw the IDs such as {!!!!!!!!!!!!!!!!!}and so on..... with no records or contributions

Hope you understand

Somehow upgrade the Wiki software to do the deleting part as it is impossible to cope with spammers.Wikipedia shows scores of users (~~7) ,but only ten thousand are genuine.Rest are spammers grabbing the usernames and forgeting the day after ! I myself had a friend like this in school donning wikipedia with 'against wikipedia' usr names
I make a sugesstion : Make a group (like administrators/autoconfirmed users {Who have access to DB} ) who will only patrol round the Wikipedia users DB and del them when they expire with less edits.(higher editing users can be honoured) and this should be stictly followed.

Think this helps You can also drop an opinion in my talk page Raunak' ' ( .:: Raunak Roy ::.. )

Yours sincerely, --Raunak' ' ( .:: Raunak Roy ::.. ) 07:34, 17 June 2008 (UTC) Roy Raunak

User accounts can't be deleted at all, for any reason, due to the GFDL requirements of Wikipedia (and of course users themselves shouldn't be deleted ;-)). I'm sure somebody else could explain this in more detail if you like, but the gist of it is that we have to keep the account in order to attribute their contributions to them. Anyway, if they're not using the account then they're not doing any harm, so it's better to leave it in case they come back and do something good for us. If you think an account's username is inappropriate for some reason, please see Wikipedia:Username policy#Inappropriate usernames for instructions on how to bring this to the attention of a janitor. Hope that helps! --_{tiny plastic} Grey Knight ⊖ 12:44, 17 June 2008 (UTC)

For what it's worth, I think he is talking about the names which appear at the front of Special:Listusers, most of which have been blocked without making any edits. "!" being a popular choice as it has the lowest lexicographical order except for white space. — CharlotteWebb 16:39, 17 June 2008 (UTC)

This was originally asked and answered at Wikipedia talk:Community Portal#Delete. -- Quiddity (talk) 19:59, 17 June 2008 (UTC)

There is a "middle path' that is a possible way to deal with this. GFDL requires attribution, but there is no problem with renaming accounts. Inactive accounts, with less than X edits and no activity in Y months, could be renamed to User:Inactive1, User:Inactive2, etc... The previous names could then be usurped if they are desired, or forgotten. Many of these accounts have nothing in their logs, so they could be deleted. -- ☑ SamuelWantman 19:53, 17 June 2008 (UTC)

There's currently no rule anywhere against creating an account just to set display preferences and not making any edits, although I guess most of those would eventually be attached to a global account. -Steve Sanbeg (talk) 20:39, 17 June 2008 (UTC)

Request for comment: Wikipedia:Naming conventions (events)

Please comment here regarding the appropriate names for articles about plane crashes, train crashes, and similar events. Yechiel (Shalom) 21:07, 17 June 2008 (UTC)

New-article patrol - Flag recently-deleted articles

Re: this discussion: Modify Special:NewPages so it shows articles that have been previously deleted, along with the most recent deletion log entry. This will make it easy to spot article-recreation vandalism and make sure those articles don't get lost in the backlog. davidwr/(talk)/(contribs)/(e-mail) 23:27, 17 June 2008 (UTC)

I think this is a great idea but I'm not sure why it should be limited to recent deletions. Only some small percentage of articles will have been previously deleted and in many cases the past deletion will provide just as useful information for articles deleted at some time remove. What would be really great is if the software could also recognize whenever an article is created where there exists a deletion debate; it would search each entry for the query "wikipedia articles for deletion/name" and if a hit is returned, maybe place a symbol to flag that, linking to the deletion debate. That way it would be more easy to recognize G4s which are only discovered currently on a catch-as-catch-can basis of when the article pops up on someone's watchlist and they remember the deletion debate taking place.--Fuhghettaboutit (talk) 01:18, 18 June 2008 (UTC)

Yeah, interesting idea. Probably the best way from a software point of view would be to flag any article that was previously deleted for any reason. Undoubtedly some of these will be false positives, so uninformed newpage patrollers who see an item and think "OMG G4" will need to be put in their place, but with care this can be avoided. Yechiel (Shalom) 18:48, 18 June 2008 (UTC)

• Support. ╟─TreasuryTag (talk ╬ contribs)─╢ 18:54, 18 June 2008 (UTC)

I've written a script that will show the deletion log for any article that has a deletion log, see User:Mr.Z-man/delLog for details. I already had code for much of this from an earlier project I never finished, so this was fairly easy. Doing it for Special:NewPages or doing a search for an AfD would be more difficult but not impossible. Mr.Z-man 22:52, 18 June 2008 (UTC)

Content Disclaimer and Wikipedia's "ambitious mission of documenting all human knowledge"

I've been told that changes to disclaimer texts should be proposed here. The Wikipedia:Content disclaimer, a very important document, opens with these rather astonishing words:

"In its ambitious mission of documenting all human knowledge, Wikipedia contains millions of articles on a vast array of topics".

This wording seems to have sat there unchallenged for several years. However, the claim that Wikipedia aims to record "all human knowledge" is entirely unsupported. If there was such an aim, it would be outlined more fully in one of the policy pages, but I cannot find such a claim elsewhere. Clearly Wikipedia cannot and should not attempt to document all human knowledge - much of each human's knowledge concerns things in their everyday personal life which do not belong on Wikipedia. Instead Wikipedia should contain only knowledge which can be of general interest and value to the public.

The "ambitious mission" statement directly contradicts the policy pages WP:NOT#INFO and WP:ENC, which tell us that "Wikipedia is not an indiscriminate collection of information", that "merely being true, or even verifiable, does not automatically make something suitable for inclusion in the encyclopedia" and that "WIKIPEDIA IS NOT A DUMPING GROUND FOR RANDOM INFORMATION".

This contradiction may cause some confusion, or the stated mission of documenting "all human knowledge" may encourage the kind of trivia additions which Wikipedia would rather discourage. WP:Trivia is also clear on this: "lists of miscellaneous facts" should be avoided.

I suggest that the opening nine words of the Wikipedia:Content disclaimer be entirely removed. The disclaimer would then start by simply stating that "Wikipedia contains millions of articles on a vast array of topics". This assertion does not require any kind of 'mission statement' to qualify it.

Alternatively, a less contraversial wording could be established, such as:

"In its encyclopedic function, Wikipedia contains millions of articles on a vast array of topics".

Weasel Fetlocks (talk) 12:26, 18 June 2008 (UTC)

That's a good point, it could be pretty confusing. User:RockMFR's comment that "not even sure removals are really possible at all" is also worth thinking about, mind you; if that page has real-world legal repercussions then the Foundation presumably has the final say. But this seems as good a place as any to make our case on the subject, and I don't think this phrase has very much substance with regards to the disclaimer, so it's not infeasible to have a change. I'd prefer something like your second wording; the "encyclopaedic function" bit clearly illustrates why we have all these articles and topics (which is a part that does have substance, I guess). --_{tiny plastic} Grey Knight ⊖ 14:19, 18 June 2008 (UTC)

If the disclaimer has a legitimate legal function, I think this makes it all the more important that the statements it makes about Wikipedia's aims and functions should be accurate and supported by the Wikipedia community. Weasel Fetlocks (talk) 14:39, 18 June 2008 (UTC)

• I would support making this change. The 'all knowledge' hyperbole used to be part of the stated Wikimedia Foundation mission, but it even got trimmed from there. The disclaimers are even less of an appropriate place for marketing. It sounds snazzy but it's not needed there.--Gmaxwell (talk) 14:44, 18 June 2008 (UTC)

Actually, the disclaimer is an official, formal legal document produced by the Foundation, in consultation with their lawyers, and I'm sure that we're not supposed to go near it. ╟─TreasuryTag (talk ╬ contribs)─╢ 15:01, 18 June 2008 (UTC)

(ec) Sorry, maybe I didn't phrase my comment properly; what I mean is that we should see if people agree or if they think the existing wording is correct; if we think it should be changed then we should talk to the Foundation at that point. My comment was only meant to imply my opinion that it was uncontroversial, but even if that's true the final decision has to go through the office for the reasons you state. --_{tiny plastic} Grey Knight ⊖ 15:20, 18 June 2008 (UTC)

We're not talking about changing the whole thing, just one line; a change which would make it more appropriate to the actual purpose of Wikipedia (i.e. to create an encyclopedia, not a complete repository of all 'true' things). Oh, and yes, I support this. RichardΩ612 Ɣ ɸ 15:05, June 18, 2008 (UTC)

This will need to be rubber-stamped by the Foundation and its legal counsel, but it's emminently sensible. Support. Happy‑melon 15:08, 18 June 2008 (UTC)

• I would support a change to "all verifiable human knowledge" with a link to Wikipedia:Verifiability. — CharlotteWebb 15:57, 18 June 2008 (UTC)

Hmmm, I still disagree with that. Being verifiable proves that knowledge is factual; it does not automatically make it valid for inclusion in an encyclopedia. Have a good look through WP:NOT - plenty of information is verifiable but still does not belong on Wikipedia. The knowledge on Wikipedia should be concise and on subjects that fall within public interest. Weasel Fetlocks (talk) 21:25, 18 June 2008 (UTC)

• I would support this Gnevin (talk) 21:42, 18 June 2008 (UTC)

Isn't this similar to our famous slogan "the free encyclopedia that any can edit." Obviously, a person without the Internet access can't edit, and there are articles that are only editable by admins. So, "All human knowledge" is basically a shorthand for "All human knowledge (except for those failing our notability and verifiability policies.)" What counts is a spirit, not actual language. I don't see much need to bother. -- Taku (talk) 22:53, 18 June 2008 (UTC)

Don't touch the disclaimers! :) Prodego ^talk 02:56, 19 June 2008 (UTC)

Why not?? Check the history link on disclaimer pages & you'll see that they are regularly edited - not as frequently as other pages because of the restrictions on doing so, but they are still living, changing documents, like any other Wikipedia page. Weasel Fetlocks (talk) 11:24, 19 June 2008 (UTC)

I also support making a change - specifically, shortening the disclaimer by removing the nine words. The purpose of the disclaimer isn't to provide general information on Wikipedia - it's to warn readers about matters of content that they may be unaware of. In this case, shorter is better. -- John Broughton (♫♫) 13:08, 19 June 2008 (UTC)

I support this change. :-) Waltham, The Duke of 07:25, 20 June 2008 (UTC)

• Strongly support. That demonstrably is not the goal of this, or any other encyclopedia. --Haemo (talk) 10:31, 20 June 2008 (UTC)

OK, so consensus seems to be largely in favour of removing or ammending the contraversial wording, so how do we proceed from here? People are saying this needs Foundation approval. Can an administrator with some knowledge on this proceed from here? Thank you. Weasel Fetlocks (talk) 13:44, 22 June 2008 (UTC)

Missing interwikis

About a month ago I checked ten "Help" pages and found that:

• 3 had 5 or more interwikis
• 4 had between 1 and 3 interwikis
• 3 had NO interwikis

This seemed quite poor and I wonder if there is a group of Wikipedians interested in helping improve this situation on the Wikipedia, Help, and other namespaces (if applicable).

Best regards,

Virgilio A. P. Machado

vapmachado ^talk.cw 01:28, 19 June 2008 (UTC)

C-Class to be added to the assessment scale

As a result of a "ratification vote" that took place at WT:ASSESS, the C-Class will now be added to the Version 1.0 Assessment scale. Please see this for further details. All comments are welcome. Regards, D.M.N. (talk) 11:08, 19 June 2008 (UTC)

Spaces in Diff

I've noticed that if a space has been added or removed between two words, it is impossible to detect when comparing revisions. Every other kind of edit uses red markers to indicate a change in the text. There has to be some way to clearly indicate where spaces have been added/removed! --Cryptic C62 · Talk 15:32, 19 June 2008 (UTC)

Why is it necessary? ╟─TreasuryTag (talk ╬ contribs)─╢ 15:33, 19 June 2008 (UTC)

So we can detect the change and determine whether it needs to be reverted or not. As it works now, we essentially have to either squint at the diff, or scroll down to the edited section and squint at that. Some sort of red indicator would be faster and would involve less squinting. --Cryptic C62 · Talk 15:55, 19 June 2008 (UTC)

Note that the addition of spaces to the wikimarkup doesn't actually affect the way that a page is rendered. Any number of spaces will appear as a single blank in the page that is actually sent to readers. For example, in the space between the two arrows → ← I left ten spaces in the markup, but you can see it only shows up as a single space.

The only way that changing spaces will actually 'break' a page is if a single space is removed, so that two words run together. In that case, one of two things happens. If a space is removed between two words, the change shows up correctly in red—the difference detection engine highlights the change from 'two words' to 'twowords' in red, because it sees them as two different words. The one case – that I can see – where it doesn't work properly is if a space is removed between a word and a punctuation mark. the difference detector accepts periods and commas as word separators, and doesn't highlight the words in that case. (So changing 'foo. The' to 'foo.The' wouldn't highlight the words.) Perhaps someone could file a bug/feature request to adjust the behaviour of the engine slightly? TenOfAllTrades(talk) 16:17, 19 June 2008 (UTC)

A few months ago there was some vandalism to the main page, where someone changed a </ref> tag to < /ref>, which broke the whole reference section from that point on. This was impossible to see in the diff. EdJohnston (talk) 16:29, 19 June 2008 (UTC)

I don't think we need to be giving any more ideas here. Beans, nose, etc. :-) Mahalo. --Ali'i 16:39, 19 June 2008 (UTC)

Then again, we could always fix the difference engine, but I don't know how difficult that code is. If we fix this, maybe at the same time we could also make it easier to do null edits? (Inserting a space usually doesn't work, since the added space is ignored, and the change will not save). EdJohnston (talk) 19:01, 19 June 2008 (UTC)

For those with Firefox, I suggest using wikEd (it's in the gadgets); its changes-viewing tool shows modifications in spacing and other minor edits much better than the standard Wikipedia tool. Waltham, The Duke of 07:36, 20 June 2008 (UTC)

You can use the cross-browser compatible User:Cacycle/wikEdDiff even without wikEd. Additionally, you can change your monobook.cs page to display a background color on the standard diff view. Cacycle (talk) 13:18, 20 June 2008 (UTC)

Searching Edits by IP Ranges

This may also qualify as a technical question. Is it possible to adjust the Anonymous Edits Search page to allow for viewing edits made by IP ranges that would for instance allow one to see all edits made by a business/organization? (ie: Search: [10.167.224.324-356]) This would allow for greater transparency for seeing coordinated or questionable edits allowing for a system more in sync with the wikiscanner tool. It would make the process more streamlined for watch dogs. does anyone else find this desirable? Some thing (talk) 18:00, 19 June 2008 (UTC)

You can enable a feature that allows you to search for contributions by CIDR range (/16, /24, and /32). Go check it out in your preferences. GO-PCHS-NJROTC ^(Messages) 18:34, 19 June 2008 (UTC)

Interwiki redirects

Is there a good reason why hard interwiki redirects are disabled? In the interests of inter-project co-operation and mutual support, I'd have thought that occasionally diverting readership to wiktionary or wikispecies would be a good idea, especially when the article topic is a niche (dicdef, species, etc) which is more effectively covered at one of our sister projects. Thoughts? Happy‑melon 20:30, 19 June 2008 (UTC)

The reason can be found at Wikipedia:Soft redirect. Briefly, it is difficult to correct an incorrect hard interwiki redirect, as the target page doesn't have the redirected from foo link that we enjoy for internal redirects. Fixing such a redirect requires manual editing of the URL to call up the redirecting page. Obviously, such redirects were also a target for vandalism. TenOfAllTrades(talk) 21:09, 19 June 2008 (UTC)

It could also potentially confusing for readers if they search for something on Wikipedia and end up on a different site. Mr.Z-man 05:31, 20 June 2008 (UTC)

It would be especially problematic for interwikis to non-Wikimedia sites, e.g. google:Wikipedia, memoryalpha:Jean-Luc Picard, uncyclopedia:Peer, et cetera. {{Nihiltres|talk|log}} 14:28, 20 June 2008 (UTC)

Suggestion for adding a search box at the end of page

Hi ,

I am a regular user of Wikipedia though I registered only now. To the point, when we read out to the last part of a particular page (to be specific ,a long page ) and we got another key word to search , then we have to scroll all the way up to the top of the page to reach the search text box. what I have to suggest is to build a search box on the last portion of pages.This one may probably save a little time for scrolling.The same is incorporated in Google search result pages .

Thanking you ,

Sreedish . P .S India —Preceding unsigned comment added by 59.93.15.37 (talk) 17:02, 20 June 2008 (UTC)

Since you're registered, you can change how Wikipedia looks to you. One option for adding a search box at the end of the page is to click on the "preferences" link at the top of the page, and select the "classic" skin. --Carnildo (talk) 19:17, 20 June 2008 (UTC)

(Hi Sreedish, welcome to Wikipedia! Remember that you need to log into your account before you can change the "skin"; it seems that you made the above post logged out. Cheers! – Thomas H. Larsen 00:11, 21 June 2008 (UTC))

Take away "sign" button when editing non-talk pages

I've seen people sign their names on non-talk pages (Wikipedia policies, articles, etc). It's irritating and makes them look like newbs (not that they are). I think that someone should go inside Monobook and add something to remove the sign button for these pages. G2.0 USA ^{contributions} 21:12, 21 June 2008 (UTC)

Hi. This is a good idea overall, but can cause some problems. The signing option is also available in the box below the edit box, however. Also, some pages like the reference desk, help desk, and village pump pages (including this one) need to be signed, so it would be helpful if we could sign on select Wikipedia: pages by clocking the tab also. Thanks. ~AH1^(TCU) 21:32, 21 June 2008 (UTC)

Such exceptions (noticeboard pages, etc. which are for discussion but not in a "_talk:" namespace) are generally identifiable by the __NEWSECTIONLINK__ keyword, and since the toolbar buttons require javascript anyway, well, you know... — CharlotteWebb 04:10, 23 June 2008 (UTC)

We need a policy regarding DoS Attacks on WP

Not to give anybody any ideas (which is why I'm not going to be too specific unless I have to), but recently at least one particular person has been targeting WP with DoS Attacks. I don't believe WP has a particular policy regarding such attacks other than the good old WP:VANDAL. I think we need to be a little more strict towards those kind of vandals since that's more destructive than simply replacing a page with "Wikipedia sucks" or "John Doe is a jacka**." In fact, I believe that any DoS Attacks should be reported to the vandals' ISPs; I think ISPs would be more likely to respond to a complaint regarding a DoS Attack than just somebody replacing a page with "I luv John" or "Foo." An example of how ISPs take DoS attacks seriously can be found at http://www2.embarq.com/legal/acceptableuse.html?rid=acceptableuse.

If someone is legitimately attempting to DoS this site, e-mail security@wikimedia.org. Though most attempts to do so are entirely ineffective. We usually just do it ourselves by accident occasionally. --MZMcBride (talk) 21:54, 21 June 2008 (UTC)

It was Grawp and his bag of tricks. See this link. So does security AT wikimedia DOT org email ISPs? GO-PCHS-NJROTC ^(Messages) 22:04, 21 June 2008 (UTC)

A single 2 MB page doesn't actually count as a DoS unless it's the Main Page or something. Grawp, et al. aren't crashing the site, they're crashing a browser or two. As others have noted, use Pop-ups to see the page size first, or perhaps we can figure out some sort of JS detection mechanism that would prevent loading of the page if it is over a certain size. Really, the best solution might be getting ClueBot to automatically blank the pages if there is a large spike in the size like that. As I recall, it's always the same content that is added. --MZMcBride (talk) 23:55, 21 June 2008 (UTC)

Footnotes/References

You'll see something like

“ 2. ^ ^{a b c d e} Rosewater, Mark (2002-08-12). "Codename of the Game". Making Magic. Wizards of the Coast. Retrieved 2006-09-25. {{cite web}}: Check date values in: |date= (help) ”

You see the ^{a b c d}? We don't know excactly what ^{a b c d} refering to, because the referencer will just appear as:

“ Wizards of the Coast also assigns an internal editor^[2] to each set. ”

What we need is something like:

“ Wizards of the Coast also assigns an internal editor^[2_c] to each set. The different editions of the base set, which have varied in size from 295 to 449 cards, contain cards which have all been printed before, with the exception of Alpha, which was the game's first set. Wizards of the Coast releases Magic cards in expansion packs^[2_d]. ”

As you can see, with out my proposal, you don't know WHERE the letter (a b c d, etc.) is refering to.

Ok, so I have a few limitations, such as the pointed hat\accent\carat\lambda does not look like what it does in <references/> and I could not internal blue link ^[2], ^[2_c], or ^[2_d].

Please post this on Bugzilla, since I don't haven an account, thanks!68.148.164.166 (talk) 07:45, 22 June 2008 (UTC)

I don't see a problem with how it's done now. The abcd simply means that this reference has been used more than once. You can click on the ^[2] in the article to view the reference, or click on the ^[a] in the reference to be taken up into the document where it's linked. — The Hand That Feeds You:^Bite 13:55, 22 June 2008 (UTC)

The problem is that it's not clear which letter you have to click on to get back to where you were in the article. Algebraist 15:36, 22 June 2008 (UTC)

Ah! Well, in most modern browsers, if you clicked on the ^[2] to get to the reference, you can just click the Back button in your browser, and it'll take you back to where you were in the article previously. Some will take you back to the top of the page (if that's the last link you loaded), but I confirmed that Firefox 3, at least, will take you back to the last spot you were reading on the page. — The Hand That Feeds You:^Bite 18:36, 22 June 2008 (UTC)

View deleted images for commons admins

There is currently a poll on meta which will grant Wikimedia Commons admins the ability to view deleted image and image_talk pages on all Wikimedia projects, including English Wikipedia. No other rights would be granted by this proposal. This is important because many images on commons were copied from other projects and are then deleted on those projects. When a commons administrator is investigating the history of an image (for copyright or other purposes) the admin is currently unable to investigate the image's deleted history on other projects. This can result in inappropriate deletions and wasted time all around. Please take the time to review the proposal and leave your thoughts. English Wikipedia is Wikimedia's largest project and its opinion is important for this poll. Thanks. --Gmaxwell (talk) 21:55, 22 June 2008 (UTC)