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, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Renaming the "move" tab to "rename"

I've never really understood why "move" was called "move." In reality, you're not moving anything, you're just changing the title of the page. None of the logs move, none of the deleted revisions move, nada, zilch, squat-diddily. The history moves over, but that's sort of an expected result of renaming something. In short, there is, so far as I can tell, no point whatsoever in calling that a "move." Because that's exactly what it isn't. I'm not the only one confused by this, either - the help desk gets asked on a regular basis "How do I edit the title?", "How do I rename this page?", or my personal favorite, the all-caps "WRONG TITLE". Here's one today, from Apr. 14, from Apr. 9, just after that last one, and so on. Mind, we do get a LOT of repeat questions, but renaming this tab would be really helpful in reducing those numbers, as well as reducing the number of confused newbies who don't bother asking. Of course, the log will still appear as a "Move log", but those who need to check those logs will probably know what it's referring to. For reference, the appropriate MediaWiki page is MediaWiki:Move. Hersfold ^(t/a/c) 23:37, 16 April 2008 (UTC)

Support the change (in fact, I've been thinking about it for a while). Soxred93 | talk bot 23:38, 16 April 2008 (UTC)

For what it's worth, "move" makes perfect sense to me, as you're moving the entire article (with history) to a new name. *shrug* EVula // talk // ☯ // 23:50, 16 April 2008 (UTC)

I support this. It makes a lot of sense. Majorly (talk) 23:51, 16 April 2008 (UTC)

I think [move] suffices just fine, honestly. seresin ( ¡? ) 23:56, 16 April 2008 (UTC)

@ EVula and Seresin: I will admit it does sort of make some sense, but look at it from the eyes of a newbie. If you're looking to change the title, would you click on "move", or would you be confused when there wasn't a "rename" tab? Hersfold ^(t/a/c) 00:24, 17 April 2008 (UTC)

I think rename makes more sense semantically, but I think it might cause more confusion to newbies due to the tree structure of pages. If someone wants to move a top-level page to a subpage, it's not as intuitive to call that a "rename". People might not understand that they are both the same function, and that in order to move a page within the "tree", you need only "rename" it. People here are used to computer file systems, where changing something so that it's in a "sub-folder" requires a "move", which is a separate function from "rename". In reality, you're not actually "moving" anything within a file system either, you're merely changing its name. But the illusion is important to the intuitiveness of the system. Equazcion •✗/C • 00:32, 17 Apr 2008 (UTC)

I'm probably a bad person to ask, because when I was a newbie, I put that together quite readily. But I'm also the sort of person that pokes at every little button up there to find out what they do... EVula // talk // ☯ // 00:34, 17 April 2008 (UTC)

This has come up here before. While move doesn't really fit, rename just invites newbies to vandalize with it or test it even more than just move does. Reywas92^Talk 01:28, 17 April 2008 (UTC)

That was before only autoconfirmed users could move pages, though. Soxred93 | talk bot 01:53, 17 April 2008 (UTC)

"Rename" sounds better, for newbies, in theory, so I support it in principle. My personal preference for "move" can be easily achieved with some JavaScript; I already have "edit this page" fixed to "edit" and a few other changes. Nihiltres^{t.l} 02:50, 17 April 2008 (UTC)

I wasn't confused by the word "move", but I admit that "rename" is clearer, so I'll support. I don't think we would have a problem with people testing it any more than we do now; and any small increase in vandalism can be delt with by stern warnings and blocks. --Arctic Gnome (talk • contribs) 03:04, 17 April 2008 (UTC)

• Yes, I'd support changing the "move" button to the "rename" button: many times I have encountered users who don't know how to rename a page because they can't find the "rename" button, and instead, they perform cut-and-paste renames, which are disruptive. Changing "move" to "rename" will be a very good idea. Acalamari 16:13, 17 April 2008 (UTC)

• I did this before and it got reverted...up for it again though. Voice-of-All 16:57, 17 April 2008 (UTC)
• In my opinion, "rename" makes the action sound less computationally intensive than it actually is, in terms of the number of pages that need to be reparsed as a result. Unlike simply renaming a directory name in a file system (the tree structure Equazcion mentioned), or changing a file name in Windows (where all shortcuts to the file are changed to reflect the rename), moves can corrupt link structure. If one doesn't know what "move" means, how might one know what a "double redirect" is, and all of the problems that are caused by it? e.g. "I wonder what happens if I rename 'Kitten' to 'Kittie cat'. I'll just rename it back when I'm done". Users making constructive page moves when they need to is a great thing, but imho, calling a page move a rename simplifies what the action does and does not do. The term is more clear in terms of what the MediaWiki actually does with the database (see Title.php, "public function moveTo"), but not in terms of what the consequences of the action are. Gracenotes^T § 19:16, 17 April 2008 (UTC)
  • But how can moving renaming pages screw up links when the original page is always automatically redirected to the new page? GO-PCHS-NJROTC (talk) 19:22, 26 April 2008 (UTC)

  I agree. "Move" is clearer. It gives the connotation that more is happening than the name of a page is being changed. If it was possible to edit the title of a page, then I could understand "rename", but that's not what happens, and we do a disservice to newbies by making it appear otherwise. - jc37 00:56, 18 April 2008 (UTC)

  I also prefer "move" for the same reason. —Remember the dot ^(talk) 00:38, 19 April 2008 (UTC)

  Likewise. Allow me to give you a metaphor... Titles are like lockers, ready to accept labelled containers (boxes etc.) of various types of content (representing information). An index also exists (representing the network of links and categories here), tracking all the containers and noting which lockers they are in. Moving pages is like moving the contents to different lockers inside their containers, orderly and with their names on top; the index is updated. Cutting and pasting is like emptying the containers and clumsily moving the contents by hand, unlabelled. On one hand, the index to the lockers will refer to the empty containers, so tracking the contents will be difficult. On the other hand, the contents will be outside any indexed and labelled containers, and thus unidentifiable (no history). As one can plainly see, there is a problem at both ends of the equation... And all this cannot be represented by Rename, which would imply a simple re-numbering of the lockers. Waltham, The Duke of 17:19, 19 April 2008 (UTC)

Given the hierarchical way in which subpages work, "move" seems to a better descriptor than "rename". If something goes from User:Until(1 == 2)/Foobar draft to foobar, then that has been moved, not just renamed. _(1 == 2)^Until 17:40, 19 April 2008 (UTC)

I don't see the point. Move and rename are synonyms computer-wise - I don't think one is any clearer than the other -Halo (talk) 17:49, 19 April 2008 (UTC)

Move requires users have a mental conceptual model that equates physical locations with different articles or web pages. I bet for novices that's more complex than the conceptual model that they can rename the article on a web page. They don't need to then understand how the hierarchy / name space works to make sense of the tab. - Owlmonkey (talk) 18:56, 23 April 2008 (UTC)

Exactly; novices should have a complex image of the moving process because it is a complex process, or at least it is much more complex than a simple Rename implies. Look at my metaphor above; it is essential that all editors should learn early on exactly what a move entails, and the suggested modification, if implemented, would create a false image of non-existent simplicity. Waltham, The Duke of 01:13, 27 April 2008 (UTC)

• Support. Simpler conceptual model for users to learn = easier to use UI. - Owlmonkey (talk) 18:56, 23 April 2008 (UTC)

• Strong Support; the name "move" could be confused with page merging. "Rename" would be a much more appropriate term. The only problem I can think of is that there are many essays and policies that will have to be modified after the change, but that aside, this is a terrific idea. GO-PCHS-NJROTC (talk) 19:13, 26 April 2008 (UTC)
  • What you are essentially saying is that there are newbies who do not know what moving is but are familiar with the concept of page merging. I have trouble believing that. Waltham, The Duke of 01:13, 27 April 2008 (UTC)
    • It depends on what we're talking about when we say "newbie", and it depends on what part of Wikipedia a person has been working with. Someone who has only been here a few days would probably usually not even know how to properly cite his/her sources, much less know anything about Wikipedia terminology. However, someone who has been here a few weeks may know a little bit about moving and merging, but may not understand them thoroughly. A person may not know what page moving is until he/she's either played around with it him/herself, or he/she has asked someone what it is. I remember this from when I first came here. Oh well, so much for my opinion. GO-PCHS-NJROTC (talk) 00:01, 28 April 2008 (UTC)
      • Actually, editors are supposed to read the relevant documentation before trying out anything new, but it looks as if this is not the cool way to do things on Wikipedia. (rolls eyes) In any event, if an editor has picked something up about page merging, which means that they will have probably heard people talking about it, it is also likely that they have heard about its being restricted to administrators. Moves are discussed much more, and clicking on Move tells one what it is anyway: "Using the form below will rename a page, moving all of its history to the new name. The old title will become a redirect page to the new title. Links to the old page title will not be changed; be sure to check for double redirects (using 'What links here') after the move. You are responsible for making sure that links continue to point where they are supposed to go." There is nothing about merging here. Waltham, The Duke of 13:42, 30 April 2008 (UTC)

• Strong oppose – per my various arguments above (I do not like repeating myself). Also, a point which has just occurred to me: by moving a page one can (and usually does) also move its corresponding talk page; it is much easier to say that the talk page is moved along the main page than to say that it was renamed in the same way as the main page... More intuitive as well. Waltham, The Duke of 01:13, 27 April 2008 (UTC)
• Support - I agree that from a user perspective, the "move" functionality is identical to "renaming the article" Bluap (talk) 04:30, 28 April 2008 (UTC)
  • If the user botches it up, then they will realise that this is not true the hard way. Even if they do it correctly, they will still have to fix double redirects (I know that a bot does it as well, but it is better if the users do that themselves); rename implies that changing the name of the page will also automatically update all incoming links. This is misleading. Waltham, The Duke of 13:42, 30 April 2008 (UTC)
• Oppose - "Rename" isn't descriptive of moving pages to or from sub-pages, and is confusing in that regard, especially to newbies. Equazcion •✗/C • 04:46, 28 Apr 2008 (UTC)

PS. This section should've been called "Moving the 'move' tab to 'rename'"! Hyuk hyuk. Equazcion •✗/C • 04:52, 28 Apr 2008 (UTC)

• Support - to me, "rename" is the clearest word to describe what happens from the user's point of view, which frankly is all that should matter. I like owlmonkey's argument. I don't like these "psychology" arguments about using "move" (perhaps I'm exaggerating a little here) because it confuses potential vandals or induces new users to read about what the word means. Dwr12 (talk) 20:26, 5 May 2008 (UTC)
• Oppose, when I first got the idea of changing the name of a page, the Move thing was a bit concerning, and I think that's the way it should be; thought-provoking. If it is called rename, many childish acts of vandalism will result. Phlegm Rooster (talk) 06:45, 6 May 2008 (UTC)
  • Don't you have to be a registered user to move articles though? Dwr12 (talk) 18:20, 7 May 2008 (UTC)
    • You really think there are no childish acts of vandalism from registered users? SamBC(talk) 18:31, 7 May 2008 (UTC)
      • If they do, it's easy to fix right? If we are really concerned about registered users vandalizing the encyclopedia then the solution is (not that I'm advocating this ) to make renaming available only to administrators rather than an ambiguously-worded button. Dwr12 (talk) 23:51, 8 May 2008 (UTC)
        • "Easy" is a relative concept; the page will have to be moved back. If the initial page has been edited in the meantime, things are even more complicated, because only an administrator will then be able to move the page back. And it's not just vandalism; we should be more worried about honest mistakes caused by a lacking understanding of the moving procedure. Things can go wrong along the way. Waltham, The Duke of 00:47, 9 May 2008 (UTC)
• Oppose, by the way, lots of good arguments on both sides, but creating a false feeling of simplicity is just going to cause more confusion. SamBC(talk) 18:31, 7 May 2008 (UTC)
• Support if autoconfirm is strengthened. Otherwise, we're just inviting move (ahem ... rename) vandalism. (See Wikipedia:Autoconfirmed Proposal/Poll.) -- John Broughton (♫♫) 23:59, 8 May 2008 (UTC)
  • With all due respect, sir, adding ten or twenty edits to the auto-confirmation threshold will not make editors experts in moving pages, with move-vandals or without. Waltham, The Duke of 00:47, 9 May 2008 (UTC)
• Support this. While I figured out what "move" did without too much trouble, "rename" seems like it would be a lot clearer from the newbie perspective. Lankiveil ^{(speak to me)} 12:10, 12 May 2008 (UTC).
• Support -- "rename" is easier for newbies to understand than "move" and the overall effect is basically the same. One thing that I thought of is having a setting in preferences so that registered users can choose between "move" and "rename" -- unregistered users, who are generally (but not always) newbies, would see "rename". -- Imperator3733 (talk) 20:23, 12 May 2008 (UTC)
• Resounding oppose - "move" is clear, accurate and succinct... thus has all the makings of a good title. It also has a root in our 'history', such as it is. —TreasuryTag—t—c 18:51, 13 May 2008 (UTC)
• Oppose - prefer move, and less likely (I feel) to be abused as much, maybe. FT2 ^{(Talk | email)} 16:25, 15 May 2008 (UTC)
• Support. FWIW, on fr: the tab has been named "renommer" (= rename) for years. _R_ (talk) 18:02, 16 May 2008 (UTC)
• Support change to rename for the sake of clarity, "Move" has always seemed unintuitive to me. If we want to keep newbies away from renaming articles we should rename it "Virtual relocation" or something (<-- joke). :) Pax:Vobiscum (talk) 23:13, 17 May 2008 (UTC)
• oppose - renaming is only a part of the functionality "move" is used for, i.e. "rename" is when moving a page to another page in the same namespace, and the same level, and with the intention to rename, and not for example histmerge etc... Could support it if it was only changed for newbies, but then it would require some advanced AI to be able to raise an newbie flag, and adapt the UI accordingly. _→AzaToth 23:24, 17 May 2008 (UTC)
• Comment What about putting both on the tab? "Rename / move" is clear and accurate. --ais523 23:32, 17 May 2008 (UTC)
  • The tooltip text already says "Rename this page". —Remember the dot ^(talk) 00:16, 18 May 2008 (UTC)
• Oppose You are moving a page... --Willypx2 (talk) 19:28, 20 May 2008 (UTC)

• note I checked, and what is happens technically is a rename - the title of the page row is changed and a new page for the redirect is created at the old title (as opposed to a new page being created at the new title and all revisions being moved to it). The pageid goes to the new title. Whether this is relevant is of course a different question. --Random832 (contribs) 19:34, 21 May 2008 (UTC)
• Strong Oppose proposed name does not make sense in the context of a cross-namespace move. The existing name works in all contexts and is certainly not confusing. Jerry talk ¤ count/logs 15:35, 26 May 2008 (UTC)
• Strongly oppose - 1) You are actually moving the article, it's history, it's talk page, and the talk page's history. 2) Renaming something sounds trivial; moving something sounds like work. Moving actually is a big deal, and it helps stress that fact. 3) When you move things a redirect is created in the old place; if you rename something, nothing would be left behind. 4) If you rename something, don't like it, just rename it again. And again. And again. And so on. Newbies, vandals, and ordinary users would not understand the consequences as well. When you move something, it leaves a trail behind of collateral damage--redirects, double redirects, potentially even more redirects, move log entries, and a long trail of actions. 5) I'm quite happy that it is a little difficult for new users to figure out how to move articles. When I first started here, I was cautious, but I still caused more problems with my first moves than I resolved. I would probably have been less careful if it was just a simple rename. At least mentally, the two things sound very different, and it's an important difference to me. --Willscrlt (Talk) 11:00, 1 June 2008 (UTC)
• Oppose You are moving it from a user point of view, the page gets renamed yes but a new page is created with the same name as the old one and a redirect gets applied to it, so from the users point of view your just moving the data to a new page. ☯Ferdia O'Brien ^(T)/_(C) 14:21, 3 June 2008 (UTC)

I think this one's dead... It's been here for a month and a half and there is more opposition than support. Does any one agree that it is time for archiving? Waltham, The Duke of 03:41, 4 June 2008 (UTC)

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)

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)

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)

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)

Page move speed restriction

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

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

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

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

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

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

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

Straw poll

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

Increase autoconfirm

Please see Wikipedia:Autoconfirmed Proposal/Poll.

Don't change anything

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

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

Comments/other

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

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

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

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

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

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

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

raw signature example

I propose that an example of the raw signature such as: <small>--<font face="rage italic" size="4.5" color="LightSteelBlue"> [[User:taxa|Taxa]]</font> ([[User talk:taxa|talk]])</small> be included on the my preferences page. -- Taxa (talk) 15:16, 12 May 2008 (UTC)

Oppose. We should not encourage obnoxious signatures, especially ones using the deprecated font-tags. --Dschwen 16:41, 12 May 2008 (UTC)

Oppose per Dschwen. Signatures such as those suggested above are extremely ugly, non-standards compliant and should be discouraged rather than encouraged. -Halo (talk) 18:20, 12 May 2008 (UTC)

Oppose - Agreed, those signatures truly do suck :) Equazcion •✗/C • 18:23, 12 May 2008 (UTC)

Seriously though, I do oppose encouraging newbies to experiment with funky signatures. That would get annoying very quickly. I'd rather they wait and discover that ability on their own, when they'll likely have a better feel for what's acceptable on talk pages. Equazcion •✗/C • 18:23, 12 May 2008 (UTC)

Some never do... (evil grin) Waltham, The Duke of 01:20, 17 May 2008 (UTC)

Oppose I wouldn't be opposed to a better explanation of what a raw signature is, but that example is... no, not good. EVula // talk // ☯ // 18:34, 12 May 2008 (UTC)

Oppose. There are better places to experiment with HTML tags. Elaborate, complex signatures are usually harmful to Wikipedia — they make it more difficult to contribute to discussions, especially threaded discussions, because of the markup clutter they introduce. An editor in this discussion will notice that Equazcion's signature above is larger (266 characters!) than either of his comments. While it is by no means the only criterion by which I judge, I do take large, elaborate signatures as one sign that the editors in question care more about their own preening than about the convenience of their fellow editors. TenOfAllTrades(talk) 03:49, 15 May 2008 (UTC)

I don't care so much about my own preening as I do about showing everyone how much better I am than they are. Equazcion •✗/C • 03:53, 15 May 2008 (UTC)

Oppose more useless sigcruft, especially when it's using bad HTML too. Stifle (talk) 09:28, 16 May 2008 (UTC)

Oppose – I understand that many editors like to be able to find their comments easily in a discussion, but I doubt that newbies feel this urge so intensely. And it doesn't necessarily take an elaborate signature; you'll be surprised at how easily I find my comments. (Although, for all its simplicity, my signature does comprise 102 characters.) Waltham, The Duke of 01:20, 17 May 2008 (UTC)

Oppose. They look ugly most of the time, and they advocate a sort of 'l33t' atmosphere, which scares newbies away. How terrifying is it when you're just little newbie, and you find some fault in an article that you feel you might be able to rectify, but on the talk page everyone's signature has some crazy fonts and stuff going on. Suddenly you feel insufficient and you don't want to help anymore. It's not cool. If you want to play around with HTML, go to myspace or neopets. Agelseb (talk) 18:48, 18 May 2008 (UTC)

Oppose. Also disallow anything but wikicode for the signatures. (You may think I'm joking, but I'm dead-serious here. All of those stylish signatures are just annoying, and add no value to Wikipedia whatsoever. They're just annoying.) Jon Harald Søby (talk) 18:42, 19 May 2008 (UTC)

Oppose with some caveats: Don't show that, show something more like [[User:Example|Example]]~''[[User talk:Example|talk]]'' which would be better, more because it doesn't have those ridiculous font tags in it... ~user:orngjce223 how am I typing? 21:00, 26 May 2008 (UTC)

Oppose I don't even think signatures should be customizable at all. Jason Quinn (talk) 23:53, 31 May 2008 (UTC)

Non-admin rollbackers

Transcluded from Wikipedia:Rollback feature/throttle removal

The following discussion 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.

---

The following discussion was moved from Wikipedia:Village pump (technical)#Non-admin rollbackers

I don't know if this has been/is being discussed somewhere else, or even if this is the correct place to post this, but I think that non-admin rollbackers should be allowed to make more than 5 rollbacks in a minute before being throttled. I think that they (OK, we) should be able to make at least 10 rollbacks (15 would be better) before being throttled.

Considering that rollback rights are not automatically assigned (as autoconfirmed rights are), I do not see any reason that we should be restricted so much. I use Huggle rather vigorously, and I would be able to be much more effective in my vandal-fighting (especially during high-volume times) if I was not slowed down by having to force Huggle to mimic the rollback feature for ⁵/₆ of the time after I use up my 5 rollbacks in 10 seconds. (which I do fairly frequently when vandalism is at its peak)

Also, I sometimes encounter someone who adds external links (pointing to pages in the same website) to many articles (think 15-25) before I realize what he/she is doing. I review their contribs in Huggle to ensure that they are all spam, and if they have not been warned previously, I usually give them either a level 2 or a level 3 warning, open their contribs, and click on the rollback links. It is incredibly annoying to only be able to do 5 rollbacks, and then having to click "undo" for the rest. J.delanoy^gabs_adds 02:04, 11 May 2008 (UTC)

I have to agree. I had the same problem when reverting someone who had spammed about 120 articles today. Even though I took a second or two to double check every single diff using popups, I still bumped on the limit several times. Rather frustrating and time consuming. —Ashanda (talk) 02:36, 11 May 2008 (UTC)

I haven't personally hit the limit but I agree that since there's approval to receive rollback it could probably be increased a bit. xenocidic (talk) 02:38, 11 May 2008 (UTC)

The throttle is set in the site configuration, but it is easy to change. You just need to point the developers the presence of the mythical beast of consensus. Titoxd^{(?!? - cool stuff)} 03:19, 11 May 2008 (UTC)

That's what I am hoping to get here... J.delanoy^gabs_adds 13:29, 11 May 2008 (UTC)

Doesn't seem like it should be much of a risk to increase the limit to, say, 25 or even 50 rollbacks per minute. Actually, I'm not sure it even really needs a limit at all; after all, the worst you could do with unlimited rollback would be to run a bot to rollback every page and every new edit as soon as it's made — and that would just get you blocked quickly and the rollbacks reverted. Yes, that would be a nuisance, but hardly a serious one. Probably about equal in overall annoyance level to a 5-minute database lock or thereabouts. —Ilmari Karonen (talk) 14:05, 11 May 2008 (UTC)

It sounds like double or tripling the limit would help editors, while posing minimal risk. Unless a case is made for a higher limit, I don't think we should go there; there is a clear downside, and - absent a demonstrated need - why go there? (So count this as a vote for doubling or tripling the current limit.) -- John Broughton (♫♫) 01:52, 13 May 2008 (UTC)

So, would 15 rollbacks per minute enjoy consensus? —Ilmari Karonen (talk) 19:15, 13 May 2008 (UTC)

I'd say so; the benefit is real, and the opposition is not. :) EVula // talk // ☯ // 20:02, 13 May 2008 (UTC)

Why on Earth do we even need a limit? We can just revoke it from someone who abuses it. _{1 != 2} 20:10, 13 May 2008 (UTC)

I agree that we don't need a limit on the number of reverts a minute: I don't see why it was necessary to include a limit in the first place. Rollback is very easy to remove if it's abused, and changing non-admin rollback from five reverts a minute to unlimited will be a major positive, in my opinion. Acalamari 20:32, 13 May 2008 (UTC)

I think the limit was placed when non-admin rollback was first introduced, as part of a compromise to those that were opposed to it. I'd be fine with the restriction's removal, now that we've established that granting rollback isn't the encyclopedia-destroying concept some may have been concerned it would be. As has been pointed out, abuse can easily be dealt with by any admin. EVula // talk // ☯ // 20:55, 13 May 2008 (UTC)

←OK, it looks like several people think it's a good idea, so, how do we move forward from here? Should I create a poll somewhere to try to get more community input? If so where should I create it? As a subpage of WP:ROLLBACK? J.delanoy^gabs_adds 21:11, 13 May 2008 (UTC)

The feature request is bug 12760. I support this measure and would prefer no restriction, the current limit makes rollback useless at nuking spam. MER-C 06:50, 14 May 2008 (UTC)

I put a limit on it because I thought we were going to be sensible and give rollback to all users, and I had the limit set accordingly. I'm not attached to it, and it was pretty much plucked from thin air, so there's no big deal in upping it two or three-fold. FWIW, I've hit this limit too, and it's a bit of a pain. — Werdna talk 09:16, 14 May 2008 (UTC)

As the person who filed bug 12760 back when rollback was first made available, this obviously has my full support. I can confirm that the limit is easily reached during busy periods when only a handful of people are patrolling recent changes. While I have addressed this to some extent in Huggle by falling back to normal reversion rather than just displaying an "Action throttled" error message, the difference in speed can be significant Gurchzilla (talk) 12:10, 14 May 2008 (UTC)
OK, it looks like we have quite a bit of support for this. I'm going to move it to WP:VPP and open a straw poll. J.delanoy^gabs_adds 15:18, 15 May 2008 (UTC)

Previous discussion from Wikipedia:Village pump (technical)#Non-admin rollbackers. Please add any new discussion in the section below.

Discussion

It seems that most of the people above supported removing the limit entirely. When I originally made the post, I did not want to sound too radical. (for lack of a better term) Many of the users who supported removing the limit entirely on VP:technical are administrators, which is why I worded the straw poll the way I did. J.delanoy^gabs_adds 15:33, 15 May 2008 (UTC)

I count over 30 users in support of either raising the limit or removing it altogether, with no opposition. Enough for now? I'm not too optimistic about the change actually being implemented since I requested it four months ago, but it might be helpful to be able to say "there is consensus for this" -- Gurchzilla (talk) 16:53, 19 May 2008 (UTC)

I was going to wait a week, but I was unprepared for the amount of support this got. Where do I go from here? Do I contact a developer directly? J.delanoy^gabs_adds 17:01, 19 May 2008 (UTC)

Good question. I'd say take it to Bugzilla, but no one seems to care about those. If I were you I'd leave this discussion here and wait until someone with significant influence sees it and decides it's time to make the change happen. Equazcion •✗/C • 17:05, 19 May 2008 (UTC)

Hmmm. I guess I'll spammessage a couple of devs and ask what the proper procedure for this is. J.delanoy^gabs_adds 17:14, 19 May 2008 (UTC)

Or a dev.... [2] J.delanoy^gabs_adds 17:42, 19 May 2008 (UTC)

Straw Poll c

At present, non-admin rollbackers are able to make 5 rollbacks per minute.

Considering that mass rollback vandalism would be fairly easy to revert, and that any admin can remove rollback rights from any non-admin rollbacker, I beg the question:

Should non-admin rollbackers be able to make unlimited rollbacks without being throttled?

(After your signature on your !vote, please include the user group which shows up under Special:ListUsers/ when you type your name in. I do not mean for this to be demeaning to uninvolved parties, it is merely to aid in determining the natural bias of votes, as present rollbackers (e.g. me) would obviously be very likely to support this measure. Thanks.)

Support for rollback throttle removal

1. Reasons already stated above. J.delanoy^gabs_adds 15:33, 15 May 2008 (UTC) (rollbacker)
2. Support, either the removal of the limit, but at very least it should be increased to say, 20 per minute (that's 3 seconds per rollback which is a enough time to verify the edit qualifies for rollback). xenocidic ( talk ¿ review ) 16:31, 15 May 2008 (UTC) (rollbacker)
3. Support removing the limit. Imposing something like Xenocidic suggested might not be a bad idea, and wouldn't hinder people's use of RB too much, while still stopping revert-sprees or edit-warring [hopefully!]. RichardΩ612 Ɣ |ɸ 16:35, May 15, 2008 (UTC)(Account creator, rollback)
4. I followed the original discussion on VPT, and J.delanoy makes an excellent case. Removal of rollback from abusers is easy. --barneca (talk) 16:59, 15 May 2008 (UTC) (Administrator)
5. Support total removal of the throttle, per my rationale below. Equazcion •✗/C • 17:02, 15 May 2008 (UTC) (rollbacker)
6. per "dictator" Equazcion ( ;) ) and J.delanoy's rational. Thingg^⊕⊗ 17:05, 15 May 2008 (UTC) (rollbacker)
7. Given the overall responsible way admins have been handling rollback permissions, among other things mentioned above, removing (or raising substantially) the limit should be fine. Gracenotes^T § 17:08, 15 May 2008 (UTC) (rollbacker)
8. I can't see any need for a throttle. Editors who abuse the tool can be blocked or have the permission removed. Hut 8.5 17:57, 15 May 2008 (UTC) (Administrator)
9. There's no need for the throttle: anyone who abuses unlimited rollback can have the right removed from them. Removing the throttle will increase our vandal-fighting capabilities greatly. Acalamari 19:21, 15 May 2008 (UTC) (Administrator)
10. We can always take away rollback permission for anyone who abuses it. There's no reason to make life hard for the many who use it properly. Aleta ^Sing 19:38, 15 May 2008 (UTC) (Adminstrator)
11. I haven't seen any problems that would make it necessary that there is a limit to rollbacks per minute. Captain panda 21:03, 15 May 2008 (UTC) (rollbacker)
12. As mentioned by others, the benefits are great, and if someone abuses it, they will lose permission. -- Imperator3733 (talk) 04:16, 16 May 2008 (UTC) (no group memberships)
13. Originally I was all about proceeding with caution with rollback, but things are going very smoothly with the process, and I personally feel it would be safe to remove the throttle. I actually wasn't even aware there was one, but even so, it doesn't seem necessary to me. -- Ned Scott 04:38, 16 May 2008 (UTC) (normal user)
14. For the record. MER-C 12:03, 16 May 2008 (UTC) (rollbacker)
15. It would be a benefit to the project in increasing vandal fighter effectiveness. Easy enough to remove from any abuser. --Gwguffey (talk) 15:23, 16 May 2008 (UTC) (rollbacker)
16. Abusers can easily be removed. BigDunc^Talk 15:39, 16 May 2008 (UTC) (rollbacker)
17. A measure like this should only have been introduced if it had turned out that the rollback permission gave rase to substantial abuse. Oliphaunt (talk) 15:46, 16 May 2008 (UTC) (rollbacker)
18. I do not see any major objections (technical or otherwise), so therefore I believe it can be removed. A throttle can always be replaced if abuse gets out of hand. Mahalo. --Ali'i 15:48, 16 May 2008 (UTC) (regular old boring editor)
19. Its easy enough to remove. MBisanz ^talk 15:50, 16 May 2008 (UTC) (admin)
20. Per all the reasons stated above. Juliancolton ^{Tropical Cyclone} 15:54, 16 May 2008 (UTC) (Rollbacker)
21. Support as perfectly reasonable suggestion. —TreasuryTag—t—c 16:20, 16 May 2008 (UTC) (rollbacker, innit)
22. CWii_{(Talk|Contribs)} 22:33, 16 May 2008 (UTC) (rollbacker, account creator)
23. Unnecessary support in an unnecessary poll^[why] for an unnecessary throttle. It would be better applied to page moves. :) Nihiltres^{t.l} 23:53, 16 May 2008 (UTC) (Administrator)
24. Support - Rollback can be taken away even easier than Twinkle can (in the event of abuse of rollback priviledges), now that Twinkle is a gadget. —  scetoaux (T|C) 01:49, 17 May 2008 (UTC) (Rollbacker)
25. Support - The rate of rollback is not much of a concern to me; page moves are a more serious matter. I'd suggest also that rollbackers have unlimited page moves but non-rollback editors be limited to a certain number of moves per hour (Administrator). EdJohnston (talk) 02:20, 17 May 2008 (UTC)
26. Support Any increase at which the vandals would be able to use this if they every got a hold of it is offset by the increased speed at which their work could be undone. - Icewedge (talk) 08:25, 17 May 2008 (UTC) (Rollbacker)
27. Support. *Dan T.* (talk) 11:50, 17 May 2008 (UTC) (Rollbacker)
28. Support. Would help us faster for vandal reversing... --Creamy!^Talk 13:13, 17 May 2008 (UTC) (rollbacker)
29. Support Would be helpful to vandal fighters. FunPika 20:55, 17 May 2008 (UTC) (rollbacker, account creator)
30. Support, with no reservations. The reasons behind the throttle are no longer valid. Titoxd^{(?!? - cool stuff)} 06:00, 19 May 2008 (UTC) (administrator)
31. Support, Per above users. Also EdJohnston like the page move idea. Rgoodermote  19:38, 20 May 2008 (UTC) (Rollbacker)
32. Support per above. I also agree with EdJohnston regarding page moves, though I suspect that's a separate kettle of fish. Matt Deres (talk) 19:44, 21 May 2008 (UTC) (rollbacker)

Oppose rollback throttle removal

Neutral

Straw polls are stupid, and I already made my position clear in non-poll form above

1. Gurchzilla (talk) 16:04, 16 May 2008 (UTC)

Adding straw poll options to facetiously declare how stupid straw polls are has been overdone

1. Equazcion •✗/C • 19:57, 16 May 2008 (UTC)
2. J.delanoy^gabs_adds 00:15, 17 May 2008 (UTC)
3. Waltham, The Duke of 01:13, 17 May 2008 (UTC)
4. "Are has been overdone"? MER-C 10:54, 17 May 2008 (UTC)

   All ur base r belong 2 us :P J.delanoy^gabs_adds 14:02, 18 May 2008 (UTC)

5. Love the sense of irony. (I couldn't care less about rollback.) -- Taku (talk) 11:28, 17 May 2008 (UTC)

   Actually, most of us who voted here already voted above. I don't think this was actually intended to be a real option in the straw poll. J.delanoy^gabs_adds 13:47, 17 May 2008 (UTC)

6. Agree 107.232005281% with this. —TreasuryTag—t—c 17:00, 18 May 2008 (UTC)

Origin of the throttle

I was rather active in the original proposal to implement a non-administrative rollback feature, and I don't recall any mention of a "throttle" or similar limit. Can someone post a link to the discussion that led to the setting of such a limit? Equazcion •✗/C • 16:42, 15 May 2008 (UTC)

I looked over Wikipedia:Non-administrator rollback, but I didn't see any discussions about throttling. I have no idea where throttling came from. Sorry. J.delanoy^gabs_adds 16:56, 15 May 2008 (UTC)

At the risk of being judged a unilateral dictator, I think the throttle should be removed now with no further discussion required. There was a massive discussion regarding the adding of an administrative rollback feature in which very wide consensus was established to implement it, and no discussion whatsoever, as far as we can find, regarding the setting of any throttle. It should never have been implemented in the first place and as such it should be removed. That's my two cents. Equazcion •✗/C • 17:01, 15 May 2008 (UTC)

Unless a Dev provides a technical reason for it (server load, or some such), then I would concur. UltraExactZZ ^Claims ~ Evidence 18:02, 15 May 2008 (UTC)

Read Werdna's post above from yesterday. GRBerry 23:02, 15 May 2008 (UTC)

Basically the developer who implemented it did so on the assumption that it would be given to all registered user accounts, and that it would be necessary to do this to guard against abuse. Widespread objection to this led to it being limited to individual users at the discretion of administrators; since this provides much more stringent protection against abuse, the original reason for the limit no longer applies -- Gurchzilla (talk) 16:03, 16 May 2008 (UTC)

Sounds like it was a reasonable suggestion. It should've been discussed rather than decided on by one person. I suppose that's moot though, since it seems that it'll be removed now. Equazcion •✗/C • 17:47, 16 May 2008 (UTC)

• Can't we just raise the throttle to a higher number, say 20rpm? — xaosflux ^Talk 16:35, 17 May 2008 (UTC)

  We could, and indeed that was the original suggestion. Arguing over whether to raise the limit or remove it seems a little pointless, though, and many people seem to prefer removing it. Since the only purpose the limit serves is to reduce the potential for abuse -- something that can be handled far more conclusively by removing the user from the rollback group and/or blocking them -- and was only added in the first place because the developers anticipated rollback being given to all autoconfirmed users, I believe the argument is that there is really no point to a limit at all, as the current one sometimes hinders genuine use of rollback while doing nothing to prevent abuse (since possession of rollback is regulated by administrators) and a higher limit would be similarly pointless -- Gurchzilla (talk) 16:51, 17 May 2008 (UTC)

Update

The rollback rate limit has been raised to 100 / minute on all WMF wikis. --MZMcBride (talk) 02:24, 21 May 2008 (UTC)

10/minute, actually -- Gurchzilla (talk) 17:37, 28 May 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.

Site-wide spelling choice tabs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Favicon improvement

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

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

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

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

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

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

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

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

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

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

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

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

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

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

English Wikibooks needs a new logo

For those artsy folk, the English Wikibooks project is choosing a new logo currently. Although we have 10 proposals (which will not be expanded) we would be very much interested in improvements on those proposed logos. Comments would be useful too. Please see m:Wikibooks/Logo. Thanks to anyone who helps! – Mike.lifeguard | ^@en.wb 23:45, 31 May 2008 (UTC)

Threats/suicide admin. notice board

I’d like to suggest that an administrator noticeboard be set up handle threats of violence or suicide made anywhere on Wikipedia. The standard response to this is usually to contact the local authorities with any information available I believe. (I’m not sure if we have a formal policy on that though.) I suggest this be called Wikipedia:Administrators' noticeboard/threats or something similer.

I’m suggesting this as a follow up to this thread on WP:AN/I. (For further discussion of these issues please also see discussion here.) --S.dedalus (talk) 00:29, 21 May 2008 (UTC)

After that little fiasco a system should be setup to deal with these quickly. A couple of yanks with an inability to call internationaly is not good. Basically. Instead of a Notice Board why not first responders...or a list of admin/trusted users from various countries who are available near round the clock. Rgoodermote  00:49, 21 May 2008 (UTC)

This would in effect function like that since most administrators have all the admin noticeboards on their watchlists. --S.dedalus (talk) 01:01, 21 May 2008 (UTC)

Sounds like a good idea to me, and there should be guidelines posted there about how to deal with such threats. However, I'd name it "threats of violence", rather than just "threats", or we might get people posting threats to delete other's comments, etc., which isn't what this board would be for. StuRat (talk) 01:26, 21 May 2008 (UTC)

True, and I guess suicide can be looked at as self directed violence. --S.dedalus (talk) 01:29, 21 May 2008 (UTC)

This seems like a pretty terrible idea to me. We're here to write a free online encyclopedia, let's focus on that. A board like this would only serve as a troll / vandal / drama magnet. --MZMcBride (talk) 01:36, 21 May 2008 (UTC)

Indeed we are a free online encyclopedia, however we have notice boards like Wikipedia:Requests for oversight to insure that editing here is safe. A violent threat response protocol is no different from our protocol for responding to personal information. It is meant to protect editors from harassment or violence. I fail to see how anyone could object to administrators calling the police in an editors vicinity if that editor threatens to stage a Virginia Tech style massacre for instance. If it’s a troll, that troll gets a couple of policeman at their door and there’s no harm done, if it’s NOT a troll our action could prevent a tragedy. --S.dedalus (talk) 01:52, 21 May 2008 (UTC)

As I may have mentioned elsewhere, I prefer the simple "contact the Foundation and let the Foundation handle it" approach. However, I might also mention that a post saying that one wishes to hurt one's self is not a "threat," and the Foundation should handle it more respectfully than an actual threat. (The end point, contacting the authorities, may be the same, but how it's done or who's contacted might be different.)

If you do the noticeboard approach, then please make it a private noticeboard, accessible only to trusted users. (Otherwise it could be patrolled by trolls.) 69.140.152.55 (talk) 02:56, 21 May 2008 (UTC)

Requests for oversight is not a noticeboard, it is a closed mailing list. If we're going to do something like this, it should be a private thing, like the oversight mailing list, open to admins and trusted people who want to help. If we make a huge deal over every little thing that could be considered a threat, and the trolls are going to have another attack vector; we're calling the FBI over every "OSAMA WILL ATTACK AT NOON" I'm surprised they haven't caught on already. Since very little of a threat requires on-wiki action, there's no reason to have something like this on-wiki. Mr.Z-man 03:20, 21 May 2008 (UTC)

• I support the idea of creating a special board to post such information and to do what we can to contact the appropriate forms of assistance. Johntex\^talk 03:58, 21 May 2008 (UTC)

I'm not very sure what should be done.

On one hand, even though Wikipedia is an encyclopedia, it is also a community and as such, I think it should try to take care of its members. It would be tragic if someone were to post threats of suicide or harm to others, and have those threats come true out of inaction on our part.

On the other hand, there are very real concerns about being trolled, and questions of privacy and legal responsibility.

Under the current system, it seems to me that either individual administrators take the initiative to contact the authorities by themselves, or the Foundation is notified (or both). Perhaps what could be done is establish a private noticeboard and/or mailing list for discussion of incidents, and whenever a threat of violence is posted to WP:AN, WP:ANI, etc., the revision can be hidden from public view so as to reduce the amount of on-wiki drama. I understand that this would reduce the amount of transparency in these cases, but I also think that these have to be handled with sensitivity. --Kyoko 05:25, 21 May 2008 (UTC)

Of course, unless the police also have an admin on their staff, deleting the revisions right away makes it somewhat difficult for them to see the threat. Mr.Z-man 06:00, 21 May 2008 (UTC)

Indeed, I don’t think we need to delete these kinds of messages from the page history, most vandals and trolls don’t even know the page history exists, but I think an oversight mailing list might be the right direction to go. --S.dedalus (talk) 06:07, 21 May 2008 (UTC)

I'm happy with the current "report to WP:ANI and follow WP:TOV"; I'd rather not prefer a noticeboard which will turn into a troll magnet. x42bn6 Talk Mess 17:26, 21 May 2008 (UTC)

We are now considering some sort of a closed mailing list I believe; something which would be inaccessible to trolls. WP:ANI has time and again been proven to be slow and inept at handling delicate maters like this. TOV is great, but most users don’t know or follow that procedure. --S.dedalus (talk) 22:28, 21 May 2008 (UTC)

Now that is a better idea. I support the idea of a closed mailing list. But I also highly suggest still going to WP:ANI before using that mailing list. As it is highly likely that the mailing list could be bombarded with reports that are not even remotely close to threats of violence. Rgoodermote  22:47, 21 May 2008 (UTC)

We could just put a BIG sign at the top of the page instructing people on what belongs in the mailing list and what doesn’t. I suspect if there is another step involved it will just slow down what should be a fast response. Either way though, we can work that out if/and when this is set up. --S.dedalus (talk) 23:09, 21 May 2008 (UTC)

The problem with those billboards is that sure they attract the right crowd. But with that we get the wrong crowd. The poor email would be getting bombarded with emails from would be pranksters. I was thinking why not just put a link in WP:TOV, make it obvious...but yet hidden. Because I do not know how you would be able to make it for established users only. If you can then I am for the billboard. I am still for the mailing idea. Rgoodermote  01:55, 22 May 2008 (UTC)

We have several mailing lists on Wikipedia. Sure they get trolled sometimes, but we’ve been dealing with that for years. Users who miss-use Wikipedia get blocked. The mailing list will only include members who are interested in helping and willing to deal with an occasional troll when it rears it’s ugly head so I don’t think it will be a problem. Actually I’m virtually certain that trolls will ignore it completely if it’s in the form of a mailing list. Trolls do what they do in order to get a reaction. The only reaction they would get if they misused the mailing list would be a stern note on their talk page. Per Wikipedia precedent we can’t really have a “hidden” link. We also can’t add the link to WP:TOV since that is a rejected policy and, as far as I know, you’re not supposed to edit those. --S.dedalus (talk) 03:21, 22 May 2008 (UTC)

If we tell people to report it to ANI at the same time as the list, it defeats the purpose of the list, which is to handle such matters discretely and if the ANI comment just serves as a note, it is sort of a misuse of ANI, which is to attract a lot of people to an incident. If we have the list, we can't stop people from posting to ANI instead, but we shouldn't encourage it. Mr.Z-man 02:05, 22 May 2008 (UTC)

I actually thought that through later and decided it a bad idea. The only problems I can see now is. A. Getting people to use that instead. B. Notification of the list C. Implementation of the list D. Who will run it? Rgoodermote  02:20, 22 May 2008 (UTC)

I don't think this will work out. So long as the WMF tells users and admins to use their best judgment and lets them call authorities when they think appropriate, they are not themselves responsible or liable. But the more systematically they intervene the more they can be accused of making the wrong decision. For example, suppose someone posts a note that they are going to shoot up Bogus High School at 2 p.m., and an admin diligently deletes the note and calls the cops. But he contacts a dispatcher in the wrong jurisdication or doesn't make the point well or has a language barrier... and the alert doesn't get implemented quickly. Then after a shooting happens some mother turns up saying that her son's class was all working on the high school's Wikipedia article and if WP hadn't decided to delete it one of them would have seen the message and raised the alarm... now the lawyers will have their proboscides so deep into WMF funds you might as well start making your edits on a mirror site. Wnt (talk) 15:20, 22 May 2008 (UTC)

That's why I support the idea of submitting tips to http://tips.fbi.gov in that kind of case; they have juristiction over the whole United States. They have agents working around the clock who will route any tips to the appropriate FBI office (or in some cases, foreign agencies) so they can handle that kind of case. Of course, it's probably not a good idea to "cry wolf" to them since they would cease to take reports seriously if we did. Trying to locate the correct local sheriff and police departments can be difficult, and in my experience, they won't take reports of such threats over the phone or internet, so we'd need a Wikipedian in every town and city around the globe to volunteer. I also think it'd be a good idea to notify the freaks' ISPs; many ISPs would gladly notify the editor's local law enforcement of the problem, especially if we're talking about a school or place of work. GO-PCHS-NJROTC ^(Messages) 23:02, 29 May 2008 (UTC)

See Good Samaritan law. Except in a very few countries a bystander can never be held accountable for not taking action or taking the wrong action in an emergency. This mailing list is intended to protect people, that’s all. Legal issues are for the foundation to handle. --S.dedalus (talk) 04:23, 23 May 2008 (UTC)

I looked at that article, but it matches my preconception that such laws are narrowly cast to protect first aid responders. It is true that the legal issues can be left to the foundation, but that would seem to imply adhering to (current) policy. If you start setting up large private mailing lists and arranging to censor Wikipedia so that a group of people with no special credentials can "handle" serious threats (not yet emergencies), I think you're going to deviate from the status quo in a negative way. Also note that in the example I give above, the censorship might actually contribute to a lethal event - while no one can give you a firm prediction of numbers as to how many times deleting a post will push an event one way or the other, it is my general belief that openness is a more healthy practice. Another factor to consider is that an elaborate formal mandatory procedure handled by highest level admins and WMF people would serve as a soft juicy target for any vandal on Wikipedia. Wnt (talk) 16:56, 23 May 2008 (UTC)

There is no aspect of this which includes censorship, unless you believe that policy as currently implemented is censorship. If someone makes a threat of violence on Wikipedia the material already is removed and the authorities are called. All that is being proposed here is that we have a more streamlined system for handling the existing policy. Note too, that there are already many mailing lists for handling sensitive Wikipedia issues. These include I believe networks for handling stalking, real world abuse, personal information, vandalism and many other things. --S.dedalus (talk) 00:32, 24 May 2008 (UTC)

I think some of us are taking this whole "Wikipedia is not censored" thing way too seriously; if we keep goin' at this rate, we're liable to have all of the drug dealers, hookers, and fraudsters in this world using Wikipedia as a medium in their crimes. I don't support total censorship, but we can't go letting people use Wikipedia for purposes it was not intended for. Wikipedia is a free encyclopedia; it is not Myspace, it is not Ebay, it is not an advertising service, it is not the Better Business Bureau, it is not a place to vandalize, it is not a form of communication (although communication relating to the improvment, use, etc of the encyclopedia is permitted), and it is not a place to place threatening or harassing comments, and as long as we allow people to make Wikipedia into something it is not, people will continue to abuse it. We are an uncensored encyclopedia, not an uncensored anarchy. GO-PCHS-NJROTC ^(Messages) 23:15, 29 May 2008 (UTC)

• I like the idea of having a system similar to WP:ABUSE for this where anyone can volunteer to help; why should a volunteer for something like this have to be an administrator? GO-PCHS-NJROTC ^(Messages) 22:46, 29 May 2008 (UTC)

I think this is a fairly good example of why encouraging the reporting of all such threats on-wiki may not be a good idea. Mr.Z-man 23:15, 29 May 2008 (UTC)

You're right. After thinking about it, if some nutcase posted a bonafide threat and was reported on-wiki, wouldn't (s)he just remove the report from the list and mark it as vandalism to the list or something? GO-PCHS-NJROTC ^(Messages) 23:40, 29 May 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 [3]. -- 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)

Two related proposals

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

search

 

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

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

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

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

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

Non-Wiki Talk Pages

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

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

Disadvantages (apart from the two posted above):

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

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

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

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

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

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

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

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

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

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

Welcoming Committee

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

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

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

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

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

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

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

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

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

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

Change "navigation" on sidebar to "browse"

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

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

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

Video requests

There are a lot of articles that could be vastly improved by the inclusion of videos of sufficient quality and length which are not difficult to obtain. Liquid crystal thermometer, for example, is hard to understand without a non-static visual reference. Since the Template:Reqvideo is seldom used and the Template:Reqphoto is way overused, how about a central video request page, where articles in need of videos could be listed, and people could contribute their own videos to it? Dr. eXtreme 23:09, 25 May 2008 (UTC)

since we have a fairly small number of people who knwo there way around the technical side of sorting out videos would probably have to make it clear that suggestions may be removed if unliekly to be fulfilled.Geni 23:31, 25 May 2008 (UTC)

Theres "Audio and Visual requests" on Commons http://commons.wikimedia.org/wiki/Commons:Audio_and_video_requests -- Coasttocoast (talk) 00:46, 27 May 2008 (UTC)

That's a neat idea, but it seems to me that using too many videos in articles could cause complications (examples: people using cell phones or dial up ISPs may find it more difficult to use Wikipedia). GO-PCHS-NJROTC ^(Messages) 00:04, 30 May 2008 (UTC)

New user group for prolific article creators

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Send to a friend

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

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

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

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

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

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

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

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

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

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

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

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

muchasref

I think we should try this w:es:Plantilla:Muchasref. It's a very useful tool to make smaller the references section. Srmagnetismo (talk) 02:38, 27 May 2008 (UTC)

Do you mean the fixed-height scrollable box for containing references such as on this Spanish article? I'm sure I saw one in a featured article on the English Wikipedia maybe a month or two ago. I do agree that this sort of thing should be used more extensivley as sometimes the refs section can get extremely long. Does anyone know what the English Wikipedia equivalent template is?--85.158.139.99 (talk) 11:10, 27 May 2008 (UTC)

This? I think it's a good idea, as some references sections are ridiculously long and there is a group of editors who oppose all such methods to remedy this problem citing that the templates are "not standard" which is not a valid reason.

<div style="height: 220px; overflow: auto; padding: 3px; border:1px solid #AAAAAA; reflist4" >

--.:Alex:. 11:59, 27 May 2008 (UTC)

I'm a proponent too, but other editors cite screen-reader compatibility as an issue. User:Krator (t c) 15:13, 27 May 2008 (UTC)

Well that makes sense, it's a better argument than "it's not standard so we won't/can't use it". Could you elaborate on these compatibility issues? It's at least worth trying to rectify them and seeing what we can come up with. .:Alex:. 15:38, 27 May 2008 (UTC)

There's also this template as well:

<div class="references-small">{{reflist}}</div>

It makes the text in the references section smaller, which is a good alternative to using the scrollable box if it's causing problems (and may not suit the article). .:Alex:. 15:44, 27 May 2008 (UTC)

See Wikipedia:Citing sources#Scrolling lists. I'm guessing this has come up before. --—— Gadget850 (Ed) ^talk - 20:42, 27 May 2008 (UTC)

Would anyone be opposed to using the second template I posted, the one that makes the text smaller? Here's an example. .:Alex:. 17:25, 28 May 2008 (UTC)

{{reflist}} already makes the font smaller. No further reduction is needed. As for scrollbars, they have been utterly rejected due to a number of accessibility problems and problems printing out articles. Also keep in mind that the entire point of Wikipedia is to provide a starting point for further research, which isn't helped by trying to hide references in any and every way possible. --- RockMFR 01:11, 29 May 2008 (UTC)

Why is news being posted on the Main Page?

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

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

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

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

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

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

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

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

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

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

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

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

Unified login

Unified login is now available. We should have a message to users to Special:MergeAccounts like on other wikis. Reywas92^Talk 22:20, 29 May 2008 (UTC)

Message box standardisation, all namespaces

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

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

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

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

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

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

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

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

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

Slideshows

Wouldn't it be nice if an automatic slideshow of the pictures of an article could be created and accesible at a single click? —Preceding unsigned comment added by Simon.bastien (talk • contribs) 02:17, 31 May 2008 (UTC)

Pronunciation explanations

I think articles like this one look bad with too much explanations about the pronunciation, that's not so important for using the whole first line. It could be put bellow, or inside anoyher section --Moraleh (talk) 02:52, 31 May 2008 (UTC)

Confusing note on Wikipedia:Sandbox

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

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

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

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

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

"Waste of time. Terrible, unreliable info"

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

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

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

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

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

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

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

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

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

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

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

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

Emergency anti-Sock task force

After a quick review of Wikipedia:Requests for checkuser/Case/Hkelkar suggests some banned users are most tenacious sock articles. It becomes quite repeatative to file RFCU. May I propse to form a new project or something like WP:Emergency anti-sockpuppet task force etc. to counter the continuous socks. Otolemur crassicaudatus (talk) 18:40, 31 May 2008 (UTC)

User:FritzpollBot creating millions of new articles

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

Operator response to some issues

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The results of merge discussions are seldom recorded

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

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

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

Re: RfA proposal

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

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

to:

Dear nominee, please answer the following questions:.

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

Improvement in "Random page" methods

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

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

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

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

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

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

Proposal to extend CSD A3

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

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

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

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

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

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

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

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

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

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

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

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

New Article Creation "Holding Area".

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

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

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

FritzpollBot Discussion

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

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

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

Renaming "history" tab

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

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

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

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

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

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

Submit To Bugzilla

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

Make established articles move protected?

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

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

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

or

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

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

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

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

Order of Precedent

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

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

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

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

Font Style in Wikipedia difficult to read

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

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

Post On Bugzilla

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

Merge donation banner with anon tips

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

"First" and "Last" buttons

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

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

Ratification vote on {{C-Class}} started

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

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

Image copyright tags

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

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

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

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

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

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

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

User interface proposals

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

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

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