Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by 69.140.152.55 (talk) at 02:56, 21 May 2008 (Should we reconsider the guidelines for responding to suicidal individuals, or should we just direct users to contact the Foundation?). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
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.

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

Support the change (in fact, I've been thinking about it for a while). Soxred93 | talk bot 23:38, 16 April 2008 (UTC)[reply]
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)[reply]
I support this. It makes a lot of sense. Majorly (talk) 23:51, 16 April 2008 (UTC)[reply]
I think [move] suffices just fine, honestly. seresin ( ¡? ) 23:56, 16 April 2008 (UTC)[reply]
@ 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)[reply]
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)[reply]

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. Reywas92Talk 01:28, 17 April 2008 (UTC)[reply]

That was before only autoconfirmed users could move pages, though. Soxred93 | talk bot 01:53, 17 April 2008 (UTC)[reply]
"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)[reply]
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)[reply]
  • 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)[reply]
  • I did this before and it got reverted...up for it again though. Voice-of-All 16:57, 17 April 2008 (UTC)[reply]
  • 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. GracenotesT § 19:16, 17 April 2008 (UTC)[reply]
    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)[reply]
    I also prefer "move" for the same reason. —Remember the dot (talk) 00:38, 19 April 2008 (UTC)[reply]
    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)[reply]
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)[reply]

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

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)[reply]
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)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
        • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • Don't you have to be a registered user to move articles though? Dwr12 (talk) 18:20, 7 May 2008 (UTC)[reply]
      • You really think there are no childish acts of vandalism from registered users? SamBC(talk) 18:31, 7 May 2008 (UTC)[reply]
        • 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)[reply]
          • "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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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).[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose - prefer move, and less likely (I feel) to be abused as much, maybe. FT2 (Talk | email) 16:25, 15 May 2008 (UTC)[reply]
  • Support. FWIW, on fr: the tab has been named "renommer" (= rename) for years. _R_ (talk) 18:02, 16 May 2008 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • Comment What about putting both on the tab? "Rename / move" is clear and accurate. --ais523 23:32, 17 May 2008 (UTC)
  • Oppose You are moving a page... --Willypx2 (talk) 19:28, 20 May 2008 (UTC)[reply]

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

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)[reply]
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)[reply]
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 Baastalk 18:21, 23 April 2008 (UTC)[reply]
This would require a fundamental change to how Wikipedia's database is structured. (1 == 2)Until 18:40, 23 April 2008 (UTC)[reply]
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 Baastalk
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
That happens to me all of the time. You pressed Enter. hmwithτ 18:26, 15 May 2008 (UTC)[reply]
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)[reply]
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)[reply]
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 Baastalk 15:36, 24 April 2008 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]
See also: bugzilla:10105. --MZMcBride (talk) 20:55, 26 April 2008 (UTC)[reply]

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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  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)[reply]
  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 Baastalk 14:19, 3 May 2008 (UTC)[reply]
  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)[reply]
  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)[reply]
  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).[reply]
  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)[reply]
  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)[reply]

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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

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

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)[reply]
    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)[reply]
  • 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)[reply]

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)

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

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

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

Increase autoconfirm

Please see Wikipedia:Autoconfirmed Proposal/Poll.

Page move speed restriction

Easier to undo page moves

Don't change anything

Comments/other

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

  1. Gurchzilla (talk) 16:05, 16 May 2008 (UTC)[reply]

Moving the Main Page

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.

I realize this has been discussed about 30 times before, but it's been a while, and there's no real reason to not discuss it again.

Proposed: We move the Main Page to Portal:Main Page.

It is one of the few pages that is still in the article namespace that is clearly not an article. Obviously Main Page would remain a redirect to Portal:Main Page. And the sidebar and logo could be easily updated to link to the correct location.

Thoughts? --MZMcBride (talk) 01:28, 3 May 2008 (UTC)[reply]

No.--Urban Rose 02:42, 3 May 2008 (UTC)[reply]
Yes. MBisanz talk
The main reason is that thousands of sites link to http://en.wikipedia.org/wiki/Main_Page so unless someone wants to create a page called "Main Page" it wouldn't be best to move the main page and delete the redirect (I'm assuming the redirect would be deleted, as redirects to project pages in the article namespace generally aren't allowed). When someone actually has reason to create "Main Page", we'll worry about it then. If it really bothers you, then you could start a band named Main Page and become famous.--Urban Rose 03:35, 3 May 2008 (UTC)[reply]
Or, there's always Main Page (movie). *Dan T.* (talk) 14:08, 3 May 2008 (UTC)[reply]
I would argue that the Main Page is grandfathered with regards to title; if it's an issue with it appearing as part of the main namespace, perhaps a technical change can be made to fix that – indeed, already there are technical differences: the tab reads "main page" instead of "article". "Portal:Main Page" just sounds awkward. Nihiltres{t.l} 15:11, 3 May 2008 (UTC)[reply]
Edit: After checking, no, that tab text is changed by JavaScript. As an additional argument, I should point out that "Portal:Main_Page" is worded redundantly. Nihiltres{t.l} 16:12, 3 May 2008 (UTC)[reply]
No. There is no reason to perform this move. Nakon 15:47, 3 May 2008 (UTC)[reply]
I don't think this is likely to improve the usefulness of Wikipedia to its consumers. Christopher Parham (talk) 20:43, 3 May 2008 (UTC)[reply]

I would prefer Wikipedia:Front Page. Aside from the more friendly name, this would be good for three reasons:

  1. No JavaScript required to fix the "article" tab to read "main page". The tab would simply read "project page".
  2. It would be easier for downstream users to separate article content from project content.
  3. If we ever needed to make an article at Main Page in the future, the backwards compatibility impact would not be so great because we would already have made the change a long time ago.

We would of course keep a redirect at Main Page unless we needed that space for an article. —Remember the dot (talk) 23:50, 3 May 2008 (UTC)[reply]

I appreciate the rationale behind the proposal, but I don't find it sufficiently convincing for such a change. Sorry. - Neparis (talk) 01:07, 4 May 2008 (UTC)[reply]

Prescriptivist reasoning with no pragmatic basis. Has multiple problems which have much more serious implications, both pragmatic and on-principle. — Werdna talk 13:05, 5 May 2008 (UTC)[reply]

I don't think this is worth doing, considering the drama and waste of time that would come as a result of it. dihydrogen monoxide (H2O) 10:19, 6 May 2008 (UTC)[reply]

To restate what's already been said above repeatedly in different words, the only reason to worry about this is some abstract semantic inconsistency. There's no practical benefit. The resulting title would actually be less user-friendly. Newbies and casual surfers who don't know about namespace differences wouldn't care or appreciate the change, at best. At worst, it would confuse people. Equazcion •✗/C • 10:25, 6 May 2008 (UTC)[reply]

Although I have to say I like Remember the dot's suggestion. "Wikipedia:Front Page" seems just as intuitive as "Main Page" while also being more technically accurate. It also seems somehow more pleasing to the eye than the current name. It seems to exude more competence, if that makes any sense. Equazcion •✗/C • 10:33, 6 May 2008 (UTC)[reply]

The one reason why we would want to do this is consistency with other portals, which is a tiny advantage, and as pointed out it could cause many problems. Not worth it. Hut 8.5 18:47, 7 May 2008 (UTC)[reply]

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.

Shadowing Template

I've been experimenting with a shadowing template I created and decided to test it in my Main Page sandbox. Please check it out and give me feedback. ~RayLast «Talk!» 02:42, 4 May 2008 (UTC)[reply]

Looks neat, but I think the multiple shades look odd. I think just the last, lightest box alone would give a more believable drop-shadow effect. Drop-shadow filters in image editing programs, for example, generally just add the one layer alone. Equazcion •✗/C • 07:06, 4 May 2008 (UTC)[reply]
Looks neat, trying to figure out how I'd use it, but yea it is a cool thing. MBisanz talk 11:26, 4 May 2008 (UTC)[reply]
I agree with Equazcion that the multiple shades look wrong. It is simpler to use one single shade. If you are going to use several shades you should not stack them diagonally like you did, instead you should stack smaller and smaller variants over the same centre to achieve a real looking shadow with toned borders.
--David Göthberg (talk) 13:10, 4 May 2008 (UTC)[reply]
I know what you mean. The template has the capability to be used for lighter shadow as well as diminishing the shadow spread which would minimize the effect you mention. With your suggestions I'm planning to add another variable like "simple = true" or something that would only display one shade instead of multiple. As per your comment David, I completely agree with you, but I'm still on the concept side of the development of the template. To create a more realistic effect I would use the same diagonal technique I used but with a lot more shades allowing for a lot less positioning shift from the previous shade since I like drop shadows and not perspective ones. Doing it over the same centre would create kind of a perspective shadow. ~RayLast «Talk!» 17:00, 4 May 2008 (UTC)[reply]
OK I just added the single shade option using the "simple=true" parameter. Is this what you meant? ~RayLast «Talk!» 17:53, 10 May 2008 (UTC)[reply]
I really like the simplicity and streamlined look of it now, with the "simple=true" parameter resulting in it being all one shade. hmwithτ 18:34, 15 May 2008 (UTC)[reply]

Possible "Did you mean " feature

Hello, When you type something into wikipedia and mispell it slighty the relavent page does not come up. But if you do the same on google it says " Did you mean.....". I was wondering how hard it would be to integrate a similar feature onto wikipedia. Could you plesae reply on my talk page or notify me on my talk page if you have replied. Thanks Bit Lordy (talk) 21:04, 4 May 2008 (UTC)[reply]

This has been proposed before (by me, among other people), and the response is usually that such a feature would be too much of a performance burden. I've disagreed with that response repeatedly, and wish we could try out something like this. Wikipedia is way behind in the site searching technology department. Nearly every other prominent site that features a site search function is light-years ahead of us. Equazcion •✗/C • 21:39, 4 May 2008 (UTC)[reply]
Can't we introduce this on a small trial basis on Wikitionary or something? Can we put this to a vote? If theres enough Consensus then they will find it hard to turn down. What do you think? Bit Lordy (talk) 21:43, 4 May 2008 (UTC)[reply]
I don't think we can decide things regarding Wiktionary from here. And I don't think a vote would be beneficial here. This should be a discussion by people who know about the technology and can offer educated guesses as to how it would work and what the performance cost would be. I do think a new discussion on this would be a good idea though. Welcoming any comments. Equazcion •✗/C • 21:58, 4 May 2008 (UTC)[reply]
It's not just a performance burden, it's also a difficult thing to do if you want it to give decent suggestions. --Carnildo (talk) 02:28, 5 May 2008 (UTC)[reply]

I think redirects and disambiguation pages work just fine for this purpose. If a redirect doesn't exist for a specific phrase, make one. If a redirect doesn't exist for a typo, learn how to type. --Cryptic C62 · Talk 00:21, 5 May 2008 (UTC)[reply]

Funny how for some reason all those other sites don't tell their users to "learn how to type". We must know something they all don't. Or maybe we're just better than them, or expect more from our users. Perhaps we're just very choosy about just who we want to accommodate here -- we wouldn't want just any idiot to be able to use the site. People who don't know how to spell something should really go and check the proper spelling using some other tool prior to searching here. Who needs user-friendliness? That's not our responsibility. Users should just get smarter. This is all sarcasm of course, cause "learn to type" was a ridiculous response. Again, other sites have this feature for a reason. It makes the site easier to use. That's reason enough to want it for ourselves. And if it isn't purely the performance issue that's keeping us from doing it, but rather that the feature is a challenge to construct, then let's roll up our sleeves and rise to it. Equazcion •✗/C • 03:50, 5 May 2008 (UTC)[reply]
Users should get smarter. That is the purpose of Wikipedia (or of any encyclopedia), right? Let's take our bold goal of free education a step further: let's couple the vast amount of information available on Wikipedia with some classical conditioning. When you type poorly, you don't get what you want. When you type well, you do get what you want. This forces the user to get better at typing. Sounds like a nice educational program to me. That's not to say we would expect users to already know how to spell everything. That's what redirects are for. User-friendliness is only valuable up to a point. Pass that point, and you're training people to be stupid. I think user-friendliness is at a good level right now. --Cryptic C62 · Talk 20:24, 8 May 2008 (UTC)[reply]

You are more than welcome to submit a patch for this feature. It will be reviewed for its performance impact on the site, code quality, and so on. See How to become a MediaWiki hacker for details. — Werdna talk 13:01, 5 May 2008 (UTC)[reply]

Thanks, but this is a proposed change to the site for discussion. Even if I were a developer capable of creating this feature on my own, I wouldn't even start putting in the effort until the proposal gained consensus here. And, we have developers for that sort of thing, so if consensus here is that it would be a benefit to the site, they could take over from there and implement it, as is usually the case for such proposed features. Equazcion •✗/C • 16:58, 5 May 2008 (UTC)[reply]
The vast majority of technical changes are implemented without any sort of community consensus or announcement. If you plan on waiting for the few paid developers we have to do this because people ask for it (most of the developers are volunteers, who work on whatever they feel like) you may be waiting for a while. Mr.Z-man 17:23, 5 May 2008 (UTC)[reply]
I'm aware of SUL. I created persistent proposals because of it. That's neither here nor there. As with any proposal, we should first decide whether or not it should be done, then worry about actually doing it. That's what this page is for -- proposing and discussing changes. We don't tell people who post here "Well go and make it yourself, then get back to us", so I'm not sure where the sudden attitude problem is coming from. Let's have an actual discussion, thanks much. Equazcion •✗/C • 17:42, 5 May 2008 (UTC)[reply]
I guess what I was trying to say was, I really don't see this as a controversial change in any way. If someone can code something that won't have a significant impact on performance, I don't see it as being the type of thing that the sysadmins would require a community consensus on every project to turn on, like the AJAX based search suggestions that were just added recently. Mr.Z-man 17:48, 5 May 2008 (UTC)[reply]
When it's been brought up before it was controversial. Also, the point of this page is also to demonstrate interest in a proposed feature. If there is enough demonstrated interest, that would serve as motivation for people (designated developers and others alike) to try and create the feature. A discussion of the feature, its possible benefits, and a simple demonstrated interest by as many people as possible is instrumental in getting a change implemented. At least three people here have so far expressed the feeling that this would be a beneficial addition to the site. Great. Keep them coming. If I could write something myself and bring it to the table I would, but I just don't have the programming ability. Hopefully with enough demonstrated interest, someone who does will take notice.
In other words, you seem to be saying this is a non-controversial change. If it's just a matter of getting someone to create it, then let's do whatever we can towards that end. Equazcion •✗/C • 17:57, 5 May 2008 (UTC)[reply]
I think this is a great idea. Can someone please implement this???? It would save so much time correcting little typos.Numpty454 (talk) 18:48, 5 May 2008 (UTC)[reply]
I'm all for anything that will improve Wikipedia's terrible search function. I too have mispelled things by one letter or something and it comes up with some other results at the bottom which are completely unrelated, but it doesn't come up with the thing I might have mispelled. In fact, sometimes you can have better luck looking up Wikipedia pages on Google than on Wikipedia itself! Please, please, PLEASE do something to drastically improve Wikipedia's search tool. .:Alex:. 18:54, 5 May 2008 (UTC)[reply]
See WP:PEREN. This feature exists but is disabled on English Wikipedia for performance reasons - it's not that this would be fundamentally impractical, but that the current implementation does not scale to a wiki this large. Dcoetzee 21:19, 5 May 2008 (UTC)[reply]
That's all very well but can't we find a solution to implement it to a large Wiki? I mean if Google the largest serach engine in the world can do it surely the largest Wiki can too :) Bit Lordy (talk) 21:33, 5 May 2008 (UTC)[reply]
Exactly. I'm not sure why this should be given up on just because the existing feature wasn't made for a site this large. If IMDb and especially Google can do it, I think we should be able to find a way, and what's more I think it should be a priority. Equazcion •✗/C • 21:36, 5 May 2008 (UTC)[reply]
I agree - it's a matter of finding someone who knows Mediawiki and the approximate query research to do an implementation. I could do this myself, actually, but need to find a bit of time first. Dcoetzee 06:36, 6 May 2008 (UTC)[reply]

I think one of the biggest flaws in wikipedia is it has articles on pretty much every subject but it doesn't take into account human error. For example if you spell a word incorrectly it doesnt recognise it as a mistake and come up with a "did you mean"? message like google does; the best you can hope for is a re-direct which in 9 out of 10 cases don't come up. I propose we implement a did you mean thing when displaying search results with obvious spelling errors --Hadseys 12:46, 8 May 2008 (UTC)[reply]


Support this change - it is becoming more and more common on other sites, and is very useful to users. I have repeatedly noticed its absence (due to my own poor typing!) Dhollm (talk) 22:13, 12 May 2008 (UTC)[reply]

Automatic linking whenever possible

I just did my first Deletion review, and as I noted there apparently the Deletion review doesn't drop automatically drop a note on the relevant AfD. That would be convenient for people looking at the AfD later, but even more convenient is that it would let people who are still watching the AfD know about the Deletion review. I think that, whenever possible, we should automatically link relevant things together. Previous AfDs should be automatically linked to later AfDs, previous RfAs should be linked to subsequent RfAs, ect. ImperfectlyInformed | {talk - contribs} 03:07, 6 May 2008 (UTC)[reply]

^Agree completely. The fact that people watching the deletion discussion aren't notified that it ended up at DRV is a problem. A link should be automatically generated and placed in the XfD. Equazcion •✗/C • 03:12, 6 May 2008 (UTC)[reply]
"Imperfectly informed"... Tell me about it. :-)
I also agree; there is a need for good information flow. There should be a certain degree of standardisation, I suppose... A dedicated section in each page, perhaps, to be added only in the event of further action on a deletion. I don't know the deletion pages that well, but I've seen templates used in some cases; however, template proliferation should be avoided. Any ideas? Waltham, The Duke of 22:26, 6 May 2008 (UTC)[reply]
There's a template to link to previous deletion discussions. I don't think I've ever seen one linking to deletion reviews once a deletion ends up there. Perhaps we just need to create a template, then people would use it. Equazcion •✗/C • 00:19, 7 May 2008 (UTC)[reply]
See Wikipedia_talk:Deletion_review#Change_to_DRV_instructions. Equazcion •✗/C • 07:09, 7 May 2008 (UTC)[reply]
Maybe I'll get around to doing it, but I can't make any guarantees. Ideally we should construct a database which automatically links up articles with the same title and transcludes a list of all the old DRVs/AfDs I don't think relying on human input is efficient or long-term feasible -- it requires too much reading and attention. Impin | {talk - contribs} 09:41, 16 May 2008 (UTC)[reply]
When there's a renewed deletion attempt of something that previously survived XfD, the new XfD should include a link to the old one(s) (though this isn't always done); but, to spread the notice more widely, the old, archived XfD should be edited to include a link to the new one. In fact, I'm inclined to say that anyone reopening a previous discussion, whether through a new XfD or a DRV, should be required to drop a note on the talk page of every editor who expressed a contrary opinion in the earlier discussion. A prior decision shouldn't be overturned just because the people whose views prevailed then didn't happen to know about the new discussion. JamesMLane t c 15:08, 8 May 2008 (UTC)[reply]
That is an impossible task. Why not tell people to keep these things on their watchlists, and then change the old XfD page. It sounds like you're suggesting this, but not realizing that by doing it, you can be informing people efficiently. You need to consider that we're volunteers with limited time. It's not smart to waste that time on endless bureaucracy. Plus, there's often a ridiculous number people weighing in on these things. Impin | {talk - contribs} 09:41, 16 May 2008 (UTC)[reply]
I agree with that. Magioladitis put something on my talk page about Wikipedia:Articles for deletion/Emily Sullivan, which otherwise I would most likely not have known about. Thanks Magioladitis! That should be a required step for new XfDs -- Imperator3733 (talk) 14:51, 14 May 2008 (UTC)[reply]

I want korean language warning templates!

I am a korean wikipedian. I use en-2.

In ko: wiki, I edit 10,000s and I use ko: wiki for 3 years. I edit en: wiki "sometimes" :)

User talk:WonRyong/Archive1#Replaceable fair use Image:Park_Geun-hye.jpg

In my talk page, above template warnig is there. many.

but, I don't know what means.

because, when I read english, I translate and understand. but that warning is too long. I can't understand what mean it.

so, I sugesst korean translate warnig templates!

Example: http://commons.wikimedia.org/wiki/Template:PD-old

I click "한국어(korean)", and I can easily understand what mean.

PLEASE!!! MAKE IT!!! :( -- WonRyong (talk) 12:02, 6 May 2008 (UTC)[reply]

Please keep in mind that I'm active on many, many foreign language wikis. However, to put it bluntly, this is the English Wikipedia, not the Korean. The only projects that I'd expect to have multi-language versions would be Commons, Meta, and Wikispecies, as they are language-independent projects. We have enough trouble getting people to translate everything for those projects; to expect each template to be translated for every other language is a bit optimistic. EVula // talk // ☯ // 14:27, 6 May 2008 (UTC)[reply]
I think what WonRyong is suggesting is that boilerplate warnings link to the Template in question, i.e. where the interwiki links would/could/should appear. At least, that is what I think he/she is suggesting. -- Fullstop (talk) 02:27, 7 May 2008 (UTC)[reply]
I considered that, but the various Wikipedias have very different policies, making such interwiki linking largely useless from the user's perspective. For example, while we have fairly strict rules about Fair Use images, we at least allow them here. On the Spanish Wikipedia, there are no images; it has to come from Commons or there's nothing, so a Spanish speaker receiving a warning here would be totally lost if looking on their home project for the equivalent (and it's ridiculous to expect all the projects to document every other project's policies not to mention the nightmare of keeping them all in sync). If a user was given an image warning here, the target language that they speak may not have anything for them, or might give them totally contrary advice. Not only that, but internal links wouldn't work; even in cases of similar policies between projects, the instructions would still likely be somewhat different, and again becomes a sprawling amount of effort for everyone to document everyone else.
Trust me, my attitude about using only English on this Wikipedia is not an opinion I generated lightly or off the cuff. I've gone on record as saying that, if a user can't actually contribute in a language, they shouldn't make the attempt. This is not because I'm a jerk (not saying that I'm not one) but because of the logistical nightmare of every project trying to support every language. Each language should support its own language and nothing else. EVula // talk // ☯ // 14:37, 7 May 2008 (UTC)[reply]
I think the original matter here has been more or less agreed upon (interwikis/foreign language texts in messages are not appropriate), but the fact that this person who appears to have a decent grasp of English can't understand the message in question would seem to indicate that it's badly written and difficult to understand. Is there any scope for making the boilerplate "Replaceable fair use" talk page message simpler and easier to understand? Lankiveil (speak to me) 12:43, 12 May 2008 (UTC).[reply]

English wikipedia is not for only native english people.

English wikipedia is not for only en-3 or en-4 people.

So many en-1, en-2 people use English wikipedia. Becuase many information is here.

I suggest...hmmm...

For en-1, en-2 users, make other languages' warning templates, please.

English wikipedia is not meta. English wikipedia is not commons.

But, in some respects, English wikipedia is meta. English wikipedia is commons. -- WonRyong (talk) 12:55, 12 May 2008 (UTC)[reply]

Method to protect your user and talk page from "quicky" vandals

About three years ago I recall asking if there was anyway to block a vandal or persistent stalker from posting to your user or user talk page. However, by accident I have recently discovered a way to do just that - at least in terms of a "quicky" vandal who is unwilling or unable to go to the extra trouble it takes to find your user or user talk page and cause trouble. The method is simply to use a different name (such as your real first name) in your raw signature line. The solution is that simple. Thanks. --Taxa 13:48, 6 May 2008 (UTC)

And what about editors that have a legitimate need to contact you? EVula // talk // ☯ // 14:15, 6 May 2008 (UTC)[reply]
It can still be done but not as quickly. --Taxa 17:04, 6 May 2008 (UTC) —Preceding unsigned comment added by Taxa (talk • contribs)
This post resulted from me asking Taxa to include a link to their user or user talk page in their sig, per WP:SIG. I agree with EVula; we shouldn't put obstacles like this in the way of legitimate editors in order to make things harder for a few vandals. — Matt Eason (Talk &#149; Contribs) 14:47, 6 May 2008 (UTC)[reply]
Its not a major obstacle and besides the sinebot usually corrects the missing link in a relatively short amount of time. No one should be so disparate to contact you that they can not wait for the sinebot to appear. --Taxa 17:06, 6 May 2008 (UTC) —Preceding unsigned comment added by Taxa (talk • contribs)
SineBot is not a replacement for normal user signature, it was designed for those who do not know how or forgot to sign. Besides, you admit yourself that SineBot makes your "method" ineffective anyway. Please fix your signature. —AlexSm 17:31, 6 May 2008 (UTC)[reply]
This method is also unlikely to have much effect: I find that vandals usually find my userpage (which is semi-and-move-protected) and my talk page (which is move-protected) through my contributions which are reversions of their vandalism. As one's signature does not appear on the contributions page, but instead links to one's userpage, this anti-vandal method is not very effective, either. If you're worried about vandalism to your userpage, request that it be semi-protected at WP:RPP. Nihiltres{t.l} 15:15, 6 May 2008 (UTC)[reply]

In addition to what EVula and Matt said, not linking to either your user or talk page is a clear violation of WP:SIG, which states "at least one of those two pages must be linked from your signature." --Kralizec! (talk) 17:18, 6 May 2008 (UTC)[reply]

I concur, there must be some link to your user-space in your signature and you must use your signature regularly when editing. MBisanz talk 19:26, 6 May 2008 (UTC)[reply]
Apart from all these, I should like to draw attention to the lightness of Taxa's signature; many editors will have a hard time reading it, and the lack of a link does not help things in the least. Waltham, The Duke of 19:49, 6 May 2008 (UTC)[reply]

Hi,

I made a kind of silly typo, in other language wiki. It looks something like ('(' and ')' are used instead of '[' and ']' to prevent link here)

((:en:exiting page)) instead of ((:en"existing page))


However, on preview, the interwiki link (on left side, which reads "English" was not red, so I did not notice. (so it went out. and when clicked new page for edit pops out)

Is it possible to make it red?

Thank you very much. AIEA (talk) 16:30, 7 May 2008 (UTC)[reply]

This totally makes sense. Red interwiki links would help to identify typos and when articles are deleted in other languages. Interwikis can be accurate without having to rely entirely upon bots. --Cryptic C62 · Talk 19:33, 7 May 2008 (UTC)[reply]


While red links for bad interwiki links would be useful, it's probably not trivial to implement. When Wikipedia software builds a page for display, it checks (internal) wikilinks in order to mark them for the browser to display. What is being suggested here is that the software needs to go outside of en.wikipedia.org in order to determine validity. Yes, all Wikipedias run on the same set of servers - but each uses a different instance of the software, including a different database. So now information is going to have to be fetched via an API or other database call - en.wikipedia.org needs to ask (say) fr.wikipedia.org if a given page exists or not. -- John Broughton (♫♫) 21:33, 7 May 2008 (UTC)[reply]
How would that be any more difficult than simply checking if the page's edit box has any text in it? Or checking the revision history to see if there are any entries? I'm not much of a programmer, but I can't imagine it would be that difficult to implement. And if it were, so what? John F. Kennedy would want to try it. :) --Cryptic C62 · Talk 21:38, 7 May 2008 (UTC)[reply]
I can see how – if not implemented very carefully and thoughtfully – such checks could be quite (computationally) costly. Articles on major topics can have more than a hundred outgoing interlanguage links (see, for example, the city of London). Checking all of those outgoing links every time the article is edited, previewed, or read could cause some very serious issues. As John notes, en.wikipedia would have to send queries to dozens of other wikipedia instances and wait for replies from all of them.
It would be a nice feature to have. Getting it to work in a test instance would be pretty easy. Implementing it in a way that doesn't hammer the servers is hard. TenOfAllTrades(talk) 19:41, 14 May 2008 (UTC)[reply]

I also found that broken interwikilink is not red either. ie not red is not red, and if you click this link, the page you get is what red link would show in Italian one. It may not be easy for programmers to fix, but it is not straightforward to users to follow link either.AIEA (talk) 15:14, 8 May 2008 (UTC)[reply]

Support, though it's not the highest priority. --Amir E. Aharoni (talk) 18:31, 14 May 2008 (UTC)[reply]

Requiring some time before uploading ability

I would like to suggest that, like the move feature, we require some time before people are allowed to upload images. I find it quite common to see people who are simply using Wikipedia as their personal image storage place. Besides, there is no reason for someone's first edit to be an image upload. -- Ricky81682 (talk) 00:16, 9 May 2008 (UTC)[reply]

This would also greatly reduce the number of problematic images uploaded. The statistics I've seen are a year or so out of date, but something like 50% of all deleted images were uploaded by people who aren't autoconfirmed. --Carnildo (talk) 00:34, 9 May 2008 (UTC)[reply]
Don't I know it. Sometimes it's simply a technical issue. -- Ricky81682 (talk) 00:39, 9 May 2008 (UTC)[reply]

Support, this would make it much more difficult for fools to upload vandalistic images and copyright violations. GO-PCHS-NJROTC (talk) 01:56, 9 May 2008 (UTC)[reply]

Perhaps something has changed, or there is incorrect information at Wikipedia:User access levels, or I'm misreading it, because it seems to say that an editor must be autoconfirmed in order to upload an image. Your statistics may not reflect that.
That doesn't mean (at the moment) that an editor's first action can't be to upload - it just means that the account needs to be at least four days old, so that it becomes autoconfirmed; then the editor can start uploading. And if that seems like a good argument for adding an edit requirement in order to become autoconfirmed, and/or lengthening the amount of time until autoconfirmation, then you might want to express your opinion at Wikipedia:Autoconfirmed Proposal/Poll‎. -- John Broughton (♫♫) 02:03, 9 May 2008 (UTC)[reply]
I'd support adding an edit requirement for autoconfirmation. I'm thinking something in the low double-digit range, like 10-15 edits, although that might be a bit low. -- Imperator3733 (talk) 17:21, 12 May 2008 (UTC)[reply]
Heck, I didn't even know that an editor had to be autoconfirmed to upload; I never paid attention. Oh well, it wasn't my proposal. GO-PCHS-NJROTC (talk) 00:53, 18 May 2008 (UTC)[reply]

Wikipedia logo improvement

Why does the German Wikipedia logo look so much better than ours? Can we do whatever they did? Notice their smooth anti-aliasing and lack of any white edge around the globe, despite the transparency. Any thoughts?

Equazcion •✗/C • 17:39, 11 May 2008 (UTC)[reply]


Even better, would be to fix the errors in the logo.
The last mention was Brion's message in June 2007: http://lists.wikimedia.org/pipermail/foundation-l/2007-June/030972.html
The listings at these 2 pages, Wikipedia:Wikipedia logos#The current logo and meta:Logo#Current logos, claim we're using different (fixed) logos, Image:Wikipedia-logo-en-big.png and Image:Wikipedia-logo.png, from the one we actually are using.
From a glance at commons:Category:Wikipedia logos, about 1/5 of the Wikipedias are using an updated/fixed logo:
Everything else I could find (back in Jan 2007) is listed at: User talk:Ambuj.Saxena/Wikipedia-logo#All the related discussion links
I emailed all this to Brion about 3 weeks ago, but he didn't respond. I was going to wait another week, before emailing someone else, but since you've brought it up... :)
Anyone know what's going on, or where/who to ask? -- Quiddity (talk) 18:30, 11 May 2008 (UTC)[reply]
Well I doubt there is any one person in control of the logo, I'd imagine any admin can change it. I defiantly agree with its replacement, I say just use the exact image that our German counterpart is using, bar the German tag line of course... ☯Ferdia O'Brien (T)/(C) 19:07, 11 May 2008 (UTC)[reply]
On some wikis the logo can be changed by admins at Image:Wiki.png, but that isn't enabled here. A request on Bugzilla could get it changed. Mr.Z-man 22:35, 11 May 2008 (UTC)[reply]
This has long been suggested but there's been no activity and has turned largely into a farce. Someone needs to take the initiative and get the mistakes in the logo fixed and the ugly transparency problems and get them included. -Halo (talk) 18:22, 12 May 2008 (UTC)[reply]
I support switching to the improved logo along with fixing all the logo errors. -- penubag  (talk) 01:31, 13 May 2008 (UTC)[reply]
Yes, the German style is better. Hut 8.5 19:24, 14 May 2008 (UTC)[reply]
Much better, in my opinion. Waltham, The Duke of 03:06, 15 May 2008 (UTC)[reply]


I also like the look of the Simple Wikipedia, it is very crisp and clean. Maybe just a tiny contrast adjustment and it would be better than the German Wikipedia. -- penubag  (talk) 07:40, 19 May 2008 (UTC)[reply]

Resolved
 – fixed version implemented

Equazcion •✗/C • 18:20, 19 May 2008 (UTC) [reply]

Let me know what you think. This is Image:WikiNewSample.png, a sample showing the new image, Image:WikiNew.png, against our background. See Image:WikiNew.png for the actual new logo with transparent background. According to the Bugzilla response, when we're ready, the image needs to be uploaded to Image:Wiki.png, then full protect the image description page again, then re-open the bugzilla ticket. Equazcion •✗/C • 15:49, 15 May 2008 (UTC)[reply]

  • I honestly can't see the difference. And does it make a difference? Who stares at the logo for hours deciding how transparent the barely visible back layer of colouring is? NIN (talk) 17:58, 15 May 2008 (UTC)[reply]
  • The difference is subtle, but on a site as prominent as ours, subtle imperfections come across as unprofessional. This would also vastly improve the appearance of user pages that have custom background image placed under the logo, such as User talk:LaraLove. I know that's not the most important thing to consider, but it is an added benefit. Equazcion •✗/C • 18:06, 15 May 2008 (UTC)[reply]

Fix the logo completely, or not at all

Thue's version

Seriously, there was an article in the New York Times about this on June 25, 2007. See my other comments at the top of this thread for the relevant links and details. Can nobody figure out how to fix these handful of problems at once?!? There are 2 major character issues (Devanagari and Japanese), and 2 minor misplaced accents (Ώ and Й), plus the aesthetic issues discussed above. I'm going to poke a few other talkpages/people, see if we can finally solve it. -- Quiddity (talk) 22:42, 18 May 2008 (UTC)[reply]

"Fix completely, or not at all"... I just love people who say that. How 'bout: "Bitch about it and fix it, but don't bitch about it while demanding that others fix it." It's along the same lines, you see. Complaining is just a partial fix -- the least-helpful part -- and yet, you demand that others either do a complete job or not try at all. Think about it. Equazcion •✗/C • 23:09, 18 May 2008 (UTC)[reply]
Also, see WP:AN#New_logo. We discussed this a little. Equazcion •✗/C • 23:15, 18 May 2008 (UTC)[reply]
I'm just saying, whilst we have the people together, and the programs open, and the issue raised, wouldn't it be nice to solve the multiple problems? It's shinier now, but it's still wrong. -- Quiddity (talk) 23:39, 18 May 2008 (UTC)[reply]
Yes, it's a capital idea. However to say that if all issues can't be fixed then none should be fixed is just wrong. I hope we agree there. Equazcion •✗/C • 23:48, 18 May 2008 (UTC)[reply]
I just learnt, the character was not tamil, it's khmer. Quiddity, can you confirm what else is pending in Thue's version? Regards, Ganeshk (talk) 03:08, 19 May 2008 (UTC)[reply]
It appears that all the errors mentioned are fixed in Thue's version linked above, no?--Father Goose (talk) 05:20, 19 May 2008 (UTC)[reply]
Yes, all the character errors seem to be fixed in Thue's version (2 characters, 2 accents).
I don't know the technical details of the transparency/anti-aliasing error, so that might be an issue still? -- Quiddity (talk) 06:19, 19 May 2008 (UTC)[reply]
If the developers change the logo settings to point to Image:Wiki.png, as we want, then the sitewide logo could be subsequently updated by any admin that uploads over that protected image. In other words there would be no bottleneck to uploading further corrections as they became available. Dragons flight (talk) 05:25, 19 May 2008 (UTC)[reply]
See Nohat's comments at the end of Talk:Main Page/Archive 86#Wrong devnagari symbol for "wi" in Wikipedia's logo: "The logo is a trademark of the Wikipedia Foundation. It is not subject to the same editing policies as Wikipedia content. Even if someone were to make an acceptable replacement image, any change to the logo will have to be subject to the approval of the board."
See also his comments at the end of User_talk:Nohat/archive_2005-06-12#The_characters_on_Wikipedia_logos: "The legal status of the logo's copyright is not currently well-defined..."
(Both old threads though).
That's part of the reason I'm suggesting we need get everything fixed at once. Any board members following this thread? -- Quiddity (talk) 06:19, 19 May 2008 (UTC)[reply]
The part about the legal status was a comment from April 2005. It has been resolved since then since Nohat signed over the copyright to the Foundation. Angela. 14:53, 19 May 2008 (UTC)[reply]
Heaven help us. I know the arguments about WMF copyright as well as anyone, but if we need the Board's approval to remove the white lip from the edges, then we truly have sunk imto a bureaucratic hell. The logo is an unregistered trademark, and it certainly will continue to be their trademark even after the much discussed errors are corrected. And lastly, as a point of order, I believe the WMF executive (rather than the Board) is principally responsible for brand management. Dragons flight (talk) 06:39, 19 May 2008 (UTC)[reply]
As mentioned above, A version of the logo with the errors mentioned in the NYT article is here: Image:Wikipedia-logo_thue.png. Thue | talk 07:56, 19 May 2008 (UTC)[reply]
  • On the legal issue: That's actually another reason to get the minor change implemented first before worrying about the character errors. This was brought up at the bugzilla ticket, and my only saving grace was the fact that this is such a minor change, and most of all that this change has already been implemented on most other language wikis. If we need to wait for the approval it would take to do something totally different, then we'll be waiting a while. It's better to get this minor graphical error fixed first, get the logo uniform with the other languages, and then start worrying about this more major change. Equazcion •✗/C • 15:32, 19 May 2008 (UTC)[reply]
  • I think the aliasing issues were only present as a result of the scaling-down. The original high-res image didn't have those issues, so it would just be a matter of scaling this one down correctly for the small version. Though I do believe as someone said above that such a change would require board approval. Equazcion •✗/C • 19:39, 19 May 2008 (UTC)[reply]


I created meta:Errors in the Wikipedia logo to summarize wanted improvements to the logo. Please feel free to contribute. Thue | talk 21:11, 19 May 2008 (UTC)[reply]
(ec)My two cents:
  1. several glyphs have extra diacritical marks that make them read 'vih' or 'wih', while others have only the base 'vah'/'wah'. All should, I think, be normalized to use the base character, sans diacritic (where possible). For instance, the Devanagri and Tibetan/Bhutanese (far left, respectively 2nd & 3rd from bottom) glyphs read 'vih' and 'wih' respectively -- instead of unadorned व (U+0935) and ཝ (U+0F5D).
  2. the Thai symbol (far right, bottom) should be ว (U+0E27 with diacritic วิ U+0E27+0E34) and not ฉ (U+0E09).
-- Fullstop (talk) 21:18, 19 May 2008 (UTC)[reply]
I am not going to work on that. As Quiddity remarked, making all the characters sound like "W" was not the original priority, and changing it is currently a lot of effort. But you could start a list at meta:Errors in the Wikipedia logo, and then it might be changed if we decide to regenerate the logo from scratch. Thue | talk 09:30, 20 May 2008 (UTC)[reply]

Wikipedia Toolbar

As some might already be aware, I suggested this a while ago, and when no one was interested I made it myself.

Now, keep in mind as you read this, that presently, this toolbar, well, sort of sucks. It's the first Firefox extension I've ever attempted to write, and I didn't have the inclination to really delve deep into the various possibilities. So while I think it's pretty useful, it's really still quite basic, no-frills, and essentially it boils down to some shortcuts that I sought to make for my own use.

Nevertheless, less than 4 months later, the download count reads 600, and that's just at the extension's Mozilla page.

To give you an idea of the significance of that number:

  • If you'll read WP:WPTB, the Mozilla page is actually considered a secondary download site. People who find the toolbar via its Wikepedia page are strongly advised to download from a different external site, the downloads from which I have no way of keep count of. So the 600 count likely doesn't include those who found the extension here.
  • Also, the extension is currently not in Mozilla's main public listing. Right now, it's in what they call the "sandbox", where just about anyone can upload just about any extension, and most of them don't get much attention. As far as I can see, the number of downloads this is getting is astronomical in comparison to other non-public extensions.

In the past, I think the mention of a Wikipedia toolbar made people cringe, because they think of crappy ad-campaign toolbars like Google and Yahoo. Had I heard the suggestion I might've thought the same myself. However I'd attest now that a toolbar doesn't need to be something that takes over the user's computer. It can instead be a real asset, especially to WP junkies who spend entirely too much time here (such as myself). My goal here is now to get some more interest going in development of this, perhaps even by Wikipedia's developers. There's only so much I can do here myself, and I think it's a shame that a tool with so much interest and potential has to be so limited.

The fact that this toolbar, in its admittedly very basic form, currently averages over 60 downloads a week, just at the secondary site (and that's a number that's been climbing steadily for as long as I can remember) should surely tell us that this is something worth serious consideration. I'm reasonably certain that a well-written tool could help get more people involved in the project, get more of the casual users to be more involved, and not to mention, make work easier for our current regulars. Equazcion •✗/C • 12:10, 12 May 2008 (UTC)[reply]

Excellent idea.! Fully supported :) FT2 (Talk | email) 16:23, 15 May 2008 (UTC)[reply]
Kudos on developing this. There was another Wiki toolbar for Firefox some years back, with some nice features such as custom macros etc. Unfortunately, it seems to have been abandoned and is no longer compatible with current versions of Firefox. I'll check and see if I can find more about it as the features may be useful here. --Ckatzchatspy 20:24, 15 May 2008 (UTC)[reply]
I took a look at that old one back when I made the initial proposal. It seems to have just recreated some buttons of the MediaWiki edit bar as a Firefox toolbar. That is to say, it was mainly for use while editing a page, rather than a "traditional" toolbar made for navigating/searching. At least that was my understanding -- I couldn't actually install it because it hadn't been updated in a while and wasn't compatible with the current Firefox. Equazcion •✗/C • 20:29, 15 May 2008 (UTC)[reply]
And thanks for the kudos :) I would like to get more people other than myself involved in development though, like I said. I'm quite beginner at this. Equazcion •✗/C • 20:42, 15 May 2008 (UTC)[reply]

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

Oppose. We should not encourage obnoxious signatures, especially ones using the deprecated font-tags. --Dschwen 16:41, 12 May 2008 (UTC)[reply]
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)[reply]
Oppose - Agreed, those signatures truly do suck :) Equazcion •✗/C • 18:23, 12 May 2008 (UTC)[reply]
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)[reply]
Some never do... (evil grin) Waltham, The Duke of 01:20, 17 May 2008 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Oppose more useless sigcruft, especially when it's using bad HTML too. Stifle (talk) 09:28, 16 May 2008 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

Twinkle

I really think we need to remove twinkle from gadgets. When it was in monobooks of users, we were able to remove it when problems arose. Now, we're stuck with the only option of blocking a user when it is misused. I have heard that protecting the monobook works to remove twinkle from the gadgets, but I'm not completely sure on this.

I don't think every user here can be trusted to use twinkle constructively, and as it's easy to install in your monobook, being able to remove the tool from a users monobook is one last safety net. Ryan Postlethwaite 17:47, 12 May 2008 (UTC)[reply]

When specifically would taking away Twinkle from someone be warranted while blocking wasn't? It seems to me that inappropriate or disruptive edits made using Twinkle can be handled the same way any other type of inappropriate edit would be; Warn a few times then block if necessary. Equazcion •✗/C • 17:52, 12 May 2008 (UTC)[reply]
Blocks should be preventative rather than punative. We had the perfect protective measure before, which was being able to remove it rather than block. Having to block an otherwise good faith contributor is silly when we have better options. Ryan Postlethwaite 17:58, 12 May 2008 (UTC)[reply]
If the editor is good-faith, then you must mean they're misusing Twinkle inadvertently. Couldn't they just be told, then, how to properly use it, or barring that, to lay off its features or even disable it in their preferences temporarily? Equazcion •✗/C • 18:01, 12 May 2008 (UTC)[reply]
Some people just don't learn, but a block is too harsh, especially, as I've already stated, when we have much better methods. I don't know who thought up the idea of putting it in gadgets, but they didn't really consider much when they did. Ryan Postlethwaite 18:04, 12 May 2008 (UTC)[reply]
And if/when they don't... then we're forced to block them? That's a less-than-elegant solution. EVula // talk // ☯ // 18:06, 12 May 2008 (UTC)[reply]
I will always support removing Twinkle from the Gadgets. The last thing we need is to allow newbies to make mistakes faster, easier, and more efficiently. EVula // talk // ☯ // 18:06, 12 May 2008 (UTC)[reply]

← (ec) Perhaps, but I'm sure we could conceive of a way to disable it per-user even though it's not in monobook.js. I see how you may have experienced trouble due to it, but looking at the larger picture, my concern is that it probably does much more good than harm having it more widely available. Equazcion •✗/C • 18:08, 12 May 2008 (UTC)[reply]

See Wikipedia:Administrators' noticeboard/Archive142#Vandal_making_use_of_Twinkle. --— Gadget850 (Ed) talk - 18:10, 12 May 2008 (UTC)[reply]
I don't want to see the ability to arbitrarily change someone's preferences; that's a somewhat scary thought. What I'd much rather see, however, is for Gadgets not to be implemented without substantial discussion. Call me crazy, but that strikes me as a better (and easier) solution. EVula // talk // ☯ // 18:32, 12 May 2008 (UTC)[reply]
Mmmm... I wasn't suggesting anyone be able to change just any preference, just gadgets. If an admin can change your monobook.js, is that all that different? I'm not sure why one is scary and the other isn't. For the future, public discussion regarding new gadgets is certainly required, but removing Twinkle now would mean disabling it for everyone who had it enabled, so I think that makes this a special situation. Equazcion •✗/C • 18:37, 12 May 2008 (UTC)[reply]
Well, aside from the fact that the ability to change someone else's gadgets (you are correct on the distinction, my bad; that is where a lot of my knee-jerk reaction came from) would require a substantial amount of technical mucking, there's still something a bit unsettling about it. Can't quite put my finger on it, but I still consider it totally different from editing a monobook.js file. EVula // talk // ☯ // 18:45, 12 May 2008 (UTC)[reply]

Please bear in mind that Twinkle only works for autoconfirmed users. I'll have to look into additional restrictions when I have time. —Remember the dot (talk) 18:41, 12 May 2008 (UTC)[reply]

Not to sound too draconian, but a user blacklist that automatically disabled Twinkle for anyone listed, regardless of their installation method, would satisfy my concern most of my concerns about a Gadget-installed Twinkle (I still have concerns about someone who doesn't know what they're doing installing the tool and going hog wild, whereas the manual installation adds a step to at least protect us from random "oh, what does this do?"; this would still be an acceptable mid-way point between the arguments). EVula // talk // ☯ // 18:51, 12 May 2008 (UTC)[reply]
That sounds like a good solution to me. Perhaps AzaToth might be willing to add that. Equazcion •✗/C • 18:48, 12 May 2008 (UTC)[reply]
Maybe another option that avoids keeping a central list of users with Twinkle disabled would be to allow setting a variable in monobook.js and have Twinkle refuse to run if that variable has been set. Tra (Talk) 19:24, 12 May 2008 (UTC)[reply]
That would require an admin to change the editor's monobook.js file and protect it. I like the central list idea better; in addition to the overall easiness, it centralizes all admin activity in regards to Twinkle abuse, which is a lot more transparent than having to modify every user's monobooj.js file. EVula // talk // ☯ // 19:34, 12 May 2008 (UTC)[reply]
A central list would be possible, but not scalable, and might make the devs cry, better then to hack gadgets instead. →AzaToth 19:46, 12 May 2008 (UTC)[reply]
Not to mention slow most of the Twinkle functions down by loading the page every time you use it. Mr.Z-man 19:56, 12 May 2008 (UTC)[reply]

It would be possible to have Twinkle turn off if the user's monobook.js is protected, but we'd have to set up a fairly complex cookie system to prevent a significant performance burden. We could also restrict the Twinkle gadget to rollbackers. Or we could remove it entirely and go back to users having to manually add it. You decide. —Remember the dot (talk) 00:38, 13 May 2008 (UTC)[reply]

restricting twinkle to rollbackers would be a reasonable compromise and have the smallest impact on current users. Gnangarra 01:02, 13 May 2008 (UTC)[reply]

Autoconfirmed would be a better alternative -- penubag  (talk) 01:28, 13 May 2008 (UTC)[reply]
It's already restricted to autoconfirmed users. Equazcion •✗/C • 02:40, 13 May 2008 (UTC)[reply]
And it all comes back to raising the auto-confirmation threshold... :-D (See, Equazcion? It's not just moving...) Waltham, The Duke of 06:10, 13 May 2008 (UTC)[reply]
Yes, it's not just moving. That's the problem. As Penubag already suggested at the poll, an added confirmation level could apply to moves and things like Twinkle, while still allowing for a lesser requirement for semi-protected edits. But let's not fragment that discussion. Keep it at the subpage. Equazcion •✗/C • 08:56, 13 May 2008 (UTC)[reply]

I for one support Twinkle being limited to rollbackers. That way, a user's rollback can be removed if an admin wishes to disable Twinkle, even if it's in use as a gadget. dihydrogen monoxide (H2O) 11:22, 13 May 2008 (UTC)[reply]

Can you give multiple examples of misuses of Twinkle that justifies changing the requirements? -62.172.143.205 (talk) 13:51, 13 May 2008 (UTC)[reply]

Corey Worthington Article

Greetings, There is a BIG backstory behind this article. So have a read of this before commenting - please. The two basic reason behind the repeated deletions of the Corey Worthington article have been WP:ONEEVENT and (my personal opinion) the other main reason has been because of WP:IDONTLIKEIT. With his continued coverage in the media over the last few months not relating to the initial event that made him notable, I now believe that ONEEVENT has been well and truly satisfied. To this end, I have been working on the article in userspace but I would now like to promote it to mainspace to allow a broader editorbase to edit it. I have created two subheading below to attempt to contain different disputes about this topic as I am sure it will get into another heated debate - please try to place your comments in the correct one (I reserve the right to move them to the correct heading if they are misfiled) Fosnez (talk) 07:17, 14 May 2008 (UTC)[reply]

This is already been discussed at deletion review here which is where this should probably be discussed. Davewild (talk) 07:30, 14 May 2008 (UTC)[reply]
Ops... thanks for that. Fosnez (talk) 09:42, 14 May 2008 (UTC)[reply]

Is howto needed if there is guideline and help?

Let's look at the page WP:MOSLINK#Context. This is a guideline, it provides some rules. Now there is Help:Piped link which is a Wikipedia-specific version of m:Help:Piped link. These are Help pages, they explain technical details. Having these pages (guide + help) I'm starting to wonder... What is the possible reason to maintain yet another howto page at Wikipedia:Piped link? This is an instruction creep, pure and simple! Should be split and redirected. And this is just an example, there are some more Wikipedia:xxx pages that unnecessarily replicate Help:xxx pages (instead of redirecting to them). --Kubanczyk (talk) 13:32, 14 May 2008 (UTC)[reply]

For a respected editor, when seeing an off-topic discussion, he/she could probably post a link to an appropriate website to carry on the discussion -- once in a while. But a designated area for links like that is just asking for advertisements/spam, so it's not a good idea. Equazcion •✗/C • 15:01, 14 May 2008 (UTC)[reply]
Hmmm? What designated area? --Kubanczyk (talk) 16:57, 14 May 2008 (UTC)[reply]
guh...? Either I'm senile at 26 or I inadvertently replied to a thread that was removed from the page just before I clicked edit. In answer to your proposal, I think you're right -- experienced Wikipedians tend not to respect the help pages' value. Those pages in the Wikipedia: space that are more or less identical to a help page should probably be redirected, as long as they're instructions and not guidelines. Guidelines (even rules that haven't been tagged as guidelines or policies) should stay in Wikipedia: space, though. Equazcion •✗/C • 19:32, 14 May 2008 (UTC)[reply]
I think you were replying to #"Discussion Links", way up top. Algebraist 01:04, 15 May 2008 (UTC)[reply]
which had no business being there anyway. Rectified. Algebraist 01:07, 15 May 2008 (UTC)[reply]

Semantic categories

(moved to Wikipedia talk:Categorization. --Amir E. Aharoni (talk) 19:42, 14 May 2008 (UTC))[reply]

Lt. Micheal Moulton

I beleive that entry is needed for Lt. Micheal Moulton. He was a Revolutionary Soldier and Moulton, Alabama is named after him. He accompananied Gen. Andrew Jackson at the Battle of Horseshoe Bend. thank you. —Preceding unsigned comment added by 70.222.105.224 (talk) 00:54, 15 May 2008 (UTC)[reply]

Please make your suggestion at WP:RA. This isn't the right place. -- Kesh (talk)

"Discussion Links"

I've noticed that many users will use the discussion page of an article to debate the topic of the article, not the article itself. Instead of simply telling them not to discuss these things, give them a space on the page to put links to other website or chatrooms where they can discuss them. 168.216.176.35 (talk) 14:55, 14 May 2008 (UTC)[reply]

For a respected editor, when seeing an off-topic discussion, he/she could probably post a link to an appropriate website to carry on the discussion -- once in a while. But a designated area for links like that is just asking for advertisements/spam, so it's not a good idea. Equazcion •✗/C • 15:01, 14 May 2008 (UTC)[reply]

Non-admin rollbackers

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 5/6 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.delanoygabsadds 02:04, 11 May 2008 (UTC)[reply]

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)[reply]
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)[reply]
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)[reply]
That's what I am hoping to get here... J.delanoygabsadds 13:29, 11 May 2008 (UTC)[reply]

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

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)[reply]
So, would 15 rollbacks per minute enjoy consensus? —Ilmari Karonen (talk) 19:15, 13 May 2008 (UTC)[reply]
I'd say so; the benefit is real, and the opposition is not. :) EVula // talk // ☯ // 20:02, 13 May 2008 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

←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.delanoygabsadds 21:11, 13 May 2008 (UTC)[reply]

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

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

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)[reply]
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.delanoygabsadds 15:18, 15 May 2008 (UTC)[reply]

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.delanoygabsadds 15:33, 15 May 2008 (UTC)[reply]

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

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.delanoygabsadds 17:01, 19 May 2008 (UTC)[reply]
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)[reply]
Hmmm. I guess I'll spammessage a couple of devs and ask what the proper procedure for this is. J.delanoygabsadds 17:14, 19 May 2008 (UTC)[reply]
Or a dev.... [1] J.delanoygabsadds 17:42, 19 May 2008 (UTC)[reply]

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.delanoygabsadds 15:33, 15 May 2008 (UTC) (rollbacker)[reply]
  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)[reply]
  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)[reply]
  5. Support total removal of the throttle, per my rationale below. Equazcion •✗/C • 17:02, 15 May 2008 (UTC) (rollbacker)[reply]
  6. per "dictator" Equazcion ( ;) ) and J.delanoy's rational. Thingg⊕⊗ 17:05, 15 May 2008 (UTC) (rollbacker)[reply]
  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. GracenotesT § 17:08, 15 May 2008 (UTC) (rollbacker)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  14. For the record. MER-C 12:03, 16 May 2008 (UTC) (rollbacker)[reply]
  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)[reply]
  16. Abusers can easily be removed. BigDuncTalk 15:39, 16 May 2008 (UTC) (rollbacker)[reply]
  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)[reply]
  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)[reply]
  19. Its easy enough to remove. MBisanz talk 15:50, 16 May 2008 (UTC) (admin)[reply]
  20. Per all the reasons stated above. Juliancolton Tropical Cyclone 15:54, 16 May 2008 (UTC) (Rollbacker)[reply]
  21. Support as perfectly reasonable suggestion. —TreasuryTag—t—c 16:20, 16 May 2008 (UTC) (rollbacker, innit)[reply]
  22. CWii(Talk|Contribs) 22:33, 16 May 2008 (UTC) (rollbacker, account creator)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  27. Support. *Dan T.* (talk) 11:50, 17 May 2008 (UTC) (Rollbacker)[reply]
  28. Support. Would help us faster for vandal reversing... --Creamy!Talk 13:13, 17 May 2008 (UTC) (rollbacker)[reply]
  29. Support Would be helpful to vandal fighters. FunPika 20:55, 17 May 2008 (UTC) (rollbacker, account creator) [reply]
  30. Support, with no reservations. The reasons behind the throttle are no longer valid. Titoxd(?!? - cool stuff) 06:00, 19 May 2008 (UTC) (administrator)[reply]
  31. Support, Per above users. Also EdJohnston like the page move idea. Rgoodermote  19:38, 20 May 2008 (UTC) (Rollbacker)[reply]

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

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

  1. Equazcion •✗/C • 19:57, 16 May 2008 (UTC)[reply]
  2. J.delanoygabsadds 00:15, 17 May 2008 (UTC)[reply]
  3. Waltham, The Duke of 01:13, 17 May 2008 (UTC)[reply]
  4. "Are has been overdone"? MER-C 10:54, 17 May 2008 (UTC)[reply]
    All ur base r belong 2 us :P J.delanoygabsadds 14:02, 18 May 2008 (UTC)[reply]
  5. Love the sense of irony. (I couldn't care less about rollback.) -- Taku (talk) 11:28, 17 May 2008 (UTC)[reply]
    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.delanoygabsadds 13:47, 17 May 2008 (UTC)[reply]
  6. Agree 107.232005281% with this. —TreasuryTag—t—c 17:00, 18 May 2008 (UTC)[reply]

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

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.delanoygabsadds 16:56, 15 May 2008 (UTC)[reply]
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)[reply]
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)[reply]
Read Werdna's post above from yesterday. GRBerry 23:02, 15 May 2008 (UTC)[reply]
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)[reply]
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)[reply]
  • Can't we just raise the throttle to a higher number, say 20rpm? — xaosflux Talk 16:35, 17 May 2008 (UTC)[reply]
    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)[reply]

Update

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

Multiple columns in {{reflist}} deemed bad

"Howzat for a provocative headline, eh?" — superlusertc

There have been some discussion on Template talk:Reflist about whether to remove multicolumn support from {{reflist}}. The simple solution would be to remove support for it in the reflist template, however, some users suggested it might be better to have a policy change? (I'm guessing they where referring to MoS?). So if you have any thoughts about that please consider taking part in the discussion.
— Apis (talk) 21:45, 15 May 2008 (UTC)[reply]

Common Sense Noticeboard?

Has a Common Sense Noticeboard ever been considered? By that I mean a noticeboard where disputes involving claims of common sense could be linked to, which could also potentially serve as examples of how policies and guidelines may need to be reworded. I originally posted this suggestion on the WP:COMMON discussion page, but that appears to get very little attention, so I thought this was probably a better place to suggest it. PSWG1920 (talk) 22:47, 15 May 2008 (UTC)[reply]

I think one side of an argument making an "official report" that the other side is lacking in common sense would probably make the dispute worse rather than better. Mr.Z-man 23:04, 15 May 2008 (UTC)[reply]
Probably not much more so than with other noticeboards. It could be the opposite as well. Someone could report that common sense is perhaps being wrongly invoked. And would it not be helpful to have a centralized location with potential examples of how policies and guidelines might need to be tweaked? PSWG1920 (talk) 01:10, 16 May 2008 (UTC)[reply]
Hmm. There's always Special:WhatLinksHere/Wikipedia:Use_common_sense. Dcoetzee 02:55, 16 May 2008 (UTC)[reply]
That list is too long to really be meaningful, although I suppose such a noticeboard might become the same way. PSWG1920 (talk) 03:01, 16 May 2008 (UTC)[reply]
"Common sense is the best distributed thing in the world, for we all think we possess a good share of it."
René Descartes, Discours de la Méthode (1637)
In other words, I don't think anyone could ever agree on what was a violation of "common sense" long enough to make it anything worth reporting. -- Kesh (talk)

Modernista! disclaimer in Common.js

After the deletion discussion of Modernista!/Notice, which thoroughly rejected the idea of a disclaimer on the Modernista! article, a disclaimer of sorts was added to MediaWiki:Common.js that is displayed to anyone coming to Wikipedia from modernista.com. I do not believe there was community consensus to do so and am proposing that this is removed from Common.js. --- RockMFR 19:22, 16 May 2008 (UTC)[reply]

What did/does the notice read? For those of us not familiar with the situation you may need to explain this more. I tried the deletion discussion but it wasn't apparent what the notice said or why it was originally thought necessary. Equazcion •✗/C • 19:53, 16 May 2008 (UTC)[reply]
Also this is probably better suited to AN or ANI than proposals. Equazcion •✗/C • 19:56, 16 May 2008 (UTC)[reply]

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

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)[reply]
I move that this proposal be tabled. --Carnildo (talk) 20:25, 16 May 2008 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

  • 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)[reply]
  • 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)[reply]
    • 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)[reply]

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

    • 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)[reply]

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

Editing and History page issues

There are a few things about the basic pages that come up when "edit this page" or "history" is pressed that I would like to improve.

  • Above all, it's so aggravating when I accidentally fire off an edit with an incomplete summary (or worse, wasn't even double-checked properly) because I catch the "Enter" by mistake when looking for a punctuation mark typing the edit summary. Enter is supposed to trigger a default action for a Web page, and that action should be show preview, not save page!
  • The proximity of the "this is a minor edit" checkmark to the Save Page box is also annoying, especially since style guidelines practically prohibit minor edits, and some people might not see them on edit summaries. I think I only once actually managed to press minor edit and save page with the same click, but it's still discomfiting.
  • On the History page, the current GMT time (as of the time the History report is generated) should be printed at the top of the page just above the most recent edit. This way it is possible for people to instantly see how long ago an edit was made without having to check the system clock, do mental arithmetic, wonder if they are set differently etc. This would help with vandalism and inadvertent edit conflicts. It would also occasionally help people to notice if they are looking at an old history page in their browser. Wnt (talk) 16:20, 17 May 2008 (UTC)[reply]
  • Actually, I rather like the enter key defaulting to save. When I'm done entering my edit summary, my next action is generally to save the page, and I wouldn't want to have to switch to the mouse in order to click the save button (or tab over to it). "Style guidelines prohibit minor edits" -- You might not understand what minor edits are. They're usually for spelling/grammar corrections, versus major removals or additions. They're not prohibited at all. If you look at your preferences under the "gadgets" tab, there's a tool available that will constantly display the current GMT time at the top of your browser. Equazcion •✗/C • 16:35, 17 May 2008 (UTC)[reply]
If you want preview to be the default action, then turn on 'Show preview on first edit' in your editing preferences. Algebraist 18:16, 17 May 2008 (UTC)[reply]
Thanks, everyone. The GMT clock is a handy gadget that I'd missed, though it doesn't mark when the History page was actually served. It's also true on reviewing the current guidelines that I've been underusing minor edits; I'm not sure if the policy has evolved or if I just never paid enough attention. Showing the preview on the first edit might serve as a workaround, though it's not quite what I had in mind - but I suppose that if an editor speaks up so soon who likes the current system I'm unlikely to find a strong consensus for a change. Ah well. Wnt (talk) 19:58, 17 May 2008 (UTC)[reply]

Standard location for admin instructions

When I became an admin I spent a lot of time just finding the templates to use when closing xfd:s, and I kept forgetting where the instructions were. To make it easier for new admins to get the hang of things (and for old admins to get involved in new areas) I suggest that we work out some sort of standard location to keep admin instructions, so when you come to a page like AfD or rfpp the "technical" instructions would always be in the same location. I've created a suggestion of how it could look like, if a link in the top right corner was used. I think a standard location of admin instructions would have several benefits:

  1. Quick and easy access to the right information for new admins (and oldies!)
  2. We could remove any admin instructions from main process page, making it less cluttered for non-admins
  3. We could break up huge instruction pages like Wikipedia:Deletion process, sending each section to the appropriate process page, thus making it easier for the people active in each process to update and monitor the instructions (and only having the appropriate section on your screen certainly makes navigation easier).

I guess my most important point is that I really think a standard location for admin instructions would make life easier for everyone. The exact implementation could be something totally different from what I suggested. The instruction pages should not contain any actual policies or policy interpreting stuff, just describe the process, present all the templates that an admin would need and links to the appropriate policies. Pax:Vobiscum (talk) 00:32, 18 May 2008 (UTC)[reply]

It would probably also be a good idea to standardize some of these things. Is it really necessary to have different templates and techniques for each type of XFD debate closing? Some go above the section header, some below. Some include the result as a template parameter, some put it after the template. Its unnecessarily confusing. Mr.Z-man 01:13, 18 May 2008 (UTC)[reply]
The Editors' Index to Wikipedia covers some of what you want.-gadfium 04:18, 18 May 2008 (UTC)[reply]
Yes, it's a nifty page, but hard to navigate and incomplete (as far as information for new admins goes). Even if it was greatly improved I still think having separate instruction pages for each process (and always having the links to the instruction pages in the same place) would be a much more efficient and user-friendly solution. I guess my proposal consists of two things: 1. Making sure that the links to the admin instructions are always in the same place and 2. Gathering all necessary admin info on separate instructions pages to ease maintenance and navigation. For most of the xfd:s it would just be a question of moving the right section of Wikipedia:Deletion process to its own page and creating a link in a standardized location (my suggestion would be in the top right corner). Pax:Vobiscum (talk) 20:09, 18 May 2008 (UTC)[reply]

Suggestions for image pages: Titles and Info Boxes

I'd like to suggest two additions to image pages; titles (as opposed to file names), and image information boxes.

My first suggestion is titles. While images that are displayed within a wikipedia entry are in boxes that also contain the image's name and artist/photographer, once you click through to the image's own page, there is no longer a simple artist & title summary, only the file name. There might be comments, or general info on the artist that is not specific to the particular image, but not a dedicated place or requirement for an image title. That leaves it to the uploader to have thought to name the file with the picture's title, or at least something that isn't "IMG-0024", but that is rarely the case with images on the internet.

Here are two pages showing images of the same print of Mt Fuji:
1. http://en.wikipedia.org/wiki/Image:Hokusai-fuji7.png
2. http://commons.wikimedia.org/wiki/Image:Red_Fuji_southern_wind_clear_morning.jpg

The first example's picture title is "Image:Hokusai-fuji7.png", and the second's is "Image:Red_Fuji_southern_wind_clear_morning.jpg". Rather than having those file names as titles, I think it would be better if each page's title has both the image name and file name, but on separate lines, like so;

Red Fuji Southern Wind Clear Morning, by Katsushika Hokusai
Filename: Image:Hokusai-fuji7.png

It's personal preference that I want the image title to be bigger than the file name. I'd actually like there to be less of a size difference between the two lines, however this is the best I could do with my limited knowledge of html.

My second suggestion is for a standard info box underneath each image, which can be filled in by users. I would suggest the following (example based on page 2 mentioned above);

Artist: Katsushika Hokusai
Title: Red Fuji Southern Wind Clear Morning
Series: 36 Views of Mount Fuji
Date: Original wood print circa 1830
Edition: circa 1930 reprint
Materials: Wood block print on paper

"Materials" could also be "composition", or whatever word is appropriate to represent the many types of art styles as well as photography, diagrams, etc. Or perhaps there could be different options for different image types, whatever you think would work best. There could also be Additional Comments, where further information, anecdotes, et. could be mentioned.

What do you think? Wwoorrddss (talk) 04:45, 18 May 2008 (UTC)[reply]

Both of those images are on Commons, so any changes need to be applied there. The closest template I know of that does what you want is {{information}}. ----— Gadget850 (Ed) talk - 16:08, 18 May 2008 (UTC)[reply]
I have no idea what any of that means! I'm just a user, I don't know anything about developing the site. I emailed with a suggestion, and was told to post it in the village pump. Is there, or perhaps there could be, a suggestions page, where people like me can add things like this? Wwoorrddss (talk) 12:15, 19 May 2008 (UTC)[reply]
You're in the right place, friend. Thanks for your suggestion! I'll try to break this down for you.
  1. The images you linked are on Wikimedia Commons, which is a free image repository that any Wikimedia project (including this one, the English Wikipedia) can use. The tight integration allows us here on Wikipedia to simply link an image on Commons as if it were on Wikipedia itself. Anyway, because those specific images are on Commons, we here at the English Wikipedia can't do anything with them.
  2. That said, I believe Gadget850 missed your point. You were merely using those images as examples, not requesting any specific change to those specific images. We do have images here on Wikipedia -- lots of them -- including some that cannot be uploaded to the Commons because they aren't free. Your proposal would certainly apply to those images.
  3. Most of your proposal is something that could be done easily by whoever uploads the image. As Gadget850 mentioned, we have a template called {{information}} that includes some of the information you suggest, but any of it could be added free-form without using a template. The catch is that it's up to the person who uploads the image to provide that information.
  4. Titling an image is trickier. The software that runs Wikipedia is coded to display the filename at the top of any media page, and I think most of the folks here would prefer it that way because it makes linking the image easier. Plus, a properly constructed filename is almost as useful as a title. Take, for example, one of my own images: Image:Rochester Midtown Plaza - Interior.jpg. It would be redundant to have a title on another line that just said "Rochester Midtown Plaza - Interior".
Your proposal is not a bad one, and most of what you suggest can be done now -- but it would have to be done by the person who uploaded the image. The titling proposal is a technical issue that could be addressed if there was a strong consensus for it. Thanks again for bringing your concerns here and helping to make Wikipedia a better encyclopedia!
-- Powers T 12:47, 19 May 2008 (UTC)[reply]

"Million years ago" to "million years BC"

In general, Wikipedia avoids phrases such as "recently" and "this year" that will go out of date quickly. But I think we need to avoid even phrases that will go out of date slowly, for two reasons:

First, it is entirely possible for an article to go without proper updating indefinitely, which could mean millions of years if Wikipedia remains active that long.

Second, if the human race or human civilization dies out, but has a successor, Wikipedia will become an archeological record. In this case, it will be more useful if all of its dates are absolute and the archeologist doesn't need to guess whether it's been 1 or 2 million years since something was dated to "2.4 million years ago."

Making dates truly ageless doesn't have to be hard. Just change "5 million years ago" to "5 million years BC," "approximately 18,000 years ago" to "approximately 16,000 years BC," and "1030 years from now" to "1030 years AD." NeonMerlin 13:27, 18 May 2008 (UTC)[reply]

And here I was, worrying about whether Wikipedia will still be here five years from now. While your suggestion is sound, it's also something that doesn't need to be acted upon right away. We can afford to wait maybe a quarter of a million years before we get started. By then, our slogan will have changed to "Wikipedia, the encyclopedia any sentient being/unit can edit". --A Knight Who Says Ni (talk) 13:48, 18 May 2008 (UTC)[reply]
This is an immensely hypothetical suggestion, but still interesting in that regard, just for the sake of argument. I see the value in being reasonably vigilante in using timeless language where possible, but as for archaeological reasons, it seems unlikely that if Wikipedia's database survives that long, that only final revisions would make it. With the history of each page available, it'll be fairly easy to determine when facts were added. Also, even if for some reason, only a final revision were to survive for each article, they would all still be date stamped, which would provide an accurate enough estimation. Equazcion •✗/C • 13:55, 18 May 2008 (UTC)[reply]
I really can't see Wikipedia in its current form surviving more than a decade or so. Technology is moving very fast and the web is moving with it. Wikipedia will have to change along with that. Second, the whole BC/AD (or BCE/CE) thing is an arbitrary break based on our calendar. If, in some proposed future, another civilization comes along, they'll still have to figure out when that arbitrary break took place. Whereas if I say "4000 years ago," they can look at the timestamp on my post and see when I was talking about. -- Kesh (talk) 15:36, 18 May 2008 (UTC)[reply]
Surely, if Wikipedia has survived, they can just look up BC? Also, if they can understand the timestamp, surely they can understand the calender? --Tango (talk) 16:39, 18 May 2008 (UTC)[reply]
Silly proposal. Million years BC is the same as Million years plus 2008, 2009, 2010, 2011, which is the same as "approximately one million BC plus or minus a thousand years". Since no dates one million BC are accurate even to a thousand years, there is no difference between "million years ago at the time this was written" and "million years BME (before modern era)". In 50,000 years feel free to change to "one million BC", until then it's moot. Besides who is to say that some other bloke won't come along every two thousand years or so and have their birth become the new reference point? 199.125.109.126 (talk) 16:09, 18 May 2008 (UTC)[reply]
The age when one man could make that big a difference ended long ago. It's more likely to be the birth of a new corporation or technology that's used as a reference point now :) Equazcion •✗/C • 16:16, 18 May 2008 (UTC)[reply]
"Am I the first to say this?" BCE = Before Computer Era, ACE = After Computer Era, using 1970 or whatever second it is that all the Unix computers reference time to. 199.125.109.126 (talk) 16:42, 18 May 2008 (UTC)[reply]
There's a future society which is revealed (by a rather obscure hint) to be running on Unix time in one of Vernor Vinge's stories, I believe. Algebraist 22:34, 18 May 2008 (UTC)[reply]
You're referring to 1970 January 1 00:00:00 UTC. That would be a good reference point for a future calendar. -- Imperator3733 (talk) 18:39, 19 May 2008 (UTC)[reply]
(ec x2) Two thousand years (or even 10,000 years) is well within the margin of error for any dating of "million years ago." Ten thousand is a mere mere 1% (and 2,000 is 0.2%) of 1,000,000. Even if "Wikipedia will become an archeological record" (erm, how?), the archaeologists will also know when an article was last modified, just as they know when a Mesopotamian clay tablet (that uses a relative date) was written. Assuming of course that the alien lifeforms do exist, that they care enough to that will be doing what we call archaeology, and that they will count (using the decimal system?) -- Fullstop (talk) 16:30, 18 May 2008 (UTC)[reply]
This serious problem has already been taken care of. "Million years ago" is actually a absolutely-defined unit, and it is assumed in scientific writing that the date is relative to Before Present, with "Present" defined as 1950.--Pharos (talk) 16:40, 18 May 2008 (UTC)[reply]
See? This whole discussion is moot. 199.125.109.126 (talk) 16:47, 18 May 2008 (UTC)[reply]
Wait... Are we in the fifties now? Waltham, The Duke of 17:41, 18 May 2008 (UTC)[reply]
I guess now whenever you see something that says "4 million years ago", it actually means 4,000,050 years ago. Equazcion •✗/C • 17:48, 18 May 2008 (UTC)[reply]
Just to be ridiculously picky, right now it means 4,000,057 years and 5 months ago, but I'm not sure when in 1950 now is supposed to mean. 199.125.109.126 (talk) 00:35, 19 May 2008 (UTC)[reply]
January 1, 1950 (midnight UTC, probably).--Pharos (talk) 02:57, 19 May 2008 (UTC)[reply]
Right now is 58 years after the present, obviously. (Postmodernism is a bit of a mindfuck, admittedly...)--Father Goose (talk) 06:32, 19 May 2008 (UTC)[reply]
This seems like a great way to export the AD/BC versus CE/BCE debate to a whole bunch of archaeology, cosmology, and geology articles that had until now been untouched by that particular style war. TenOfAllTrades(talk) 18:24, 18 May 2008 (UTC)[reply]
Point of order. There is a excellent reason for the choice of 1950. Aboveground atomic testing in that era both serves as marker and a contaminant when doing radiometric dating. Space aliens that land here a million years from now could use it as a reference point. Phlegm Rooster (talk) 06:45, 19 May 2008 (UTC)[reply]
But space aliens already landed here 3 years prior, so I think they'd just use that as their reference point. One alien would just look at the other and go, "Dude, when's the last time we were here?" and that'd be it. Equazcion •✗/C • 16:04, 19 May 2008 (UTC)[reply]
Point of order overruled, Mr Phlegm Rooster. No breach has been made.
I am not sure that the Roswell incident counts as a successful landing, Equazcion... A successful mission is probably one that has gone unnoticed, anyway, and could as well have happened much earlier.
(For the record, I do not believe in any of this nonsense about alien arrivals.) Waltham, The Duke of 22:54, 19 May 2008 (UTC)[reply]

The stub template currently has two links, one to "wp:stub", the other to "edit this page". See the proposal at Wikipedia talk:Stub#Proposal to change the second link to a short tutorial on how to add to an article, like on the French wikipedia. 199.125.109.126 (talk) 16:09, 18 May 2008 (UTC)[reply]


New idea for redirect templates

[Note: I take no credit for this idea, I am just the messenger.]
User:Lenoxus has had an idea for standardisation of redirect templates. The idea basically boils down to a meta-template replacing all those separate templates for categorising redirects. This would allow standardisation and easy adding of multiple reasons to redirects. Please comment over at WikiProject Redirects to keep all discussion coherent. Thanks. RichardΩ612 Ɣ ɸ 20:01, May 18, 2008 (UTC)

To clarify — I don't actually intend to replace the other templates, as they are extremely useful for categorization and succinct standard explanations. I might, howver, like to see them change their wording over time. Lenoxus " * " 20:14, 18 May 2008 (UTC)[reply]
But surely if the categories and explanations were incorporated into the meta-template, as they can be, then it makes the others redundant? RichardΩ612 Ɣ ɸ 20:23, May 18, 2008 (UTC)
Aha, now we're having a conversation! What I believe makes a templates-based system best is that it allows for shortcuts in a way categories don't. A redirect category and its associated templates can have as long a name as they like, but only templates can be properly redirected, so that, for example, one could enter dab or r dab into the template instead of Redirects to disambiguation pages, the current category.
Additionally, in the preview of the entered text, using templates allows for uniform explanations of why a page of type X should redirect to Y. If editors had to enter the information by hand every time, there would certainly be typos and other errors. Of course, I'm secretly assuming that MediaWiki will eventually be able to properly display all the text on a redirect page… is there a possible technical limit to that?
Oh, and I just realized that you may have pictured this template containing some basic explanations itself (such as abbreviations, plural forms, etc). My problem with that is that I don't want to limit the creative power of template creation for new kinds of redirects. If the meta-template had to be locked, for example, I wouldn't want editors to have to propose a change in order to be able to have the redirect page say whatever they have in mind. Lenoxus " * " 21:25, 18 May 2008 (UTC)[reply]
The problem I have with keeping the template-based system is that every single template would need to be modified to have the line removed, and the explanations standardised. Have a look at my example and play around with it. It does include an 'other' option so that people can include a custom reason.
Even if the template was locked, a quick proposal at WT:RE could get things approved and added by an admin, and it is probably not a good idea to have people creating new redirect categories willy-nilly anyway.
The template does have uniform explanations, using the 'abbrev' parameter generates the reason concerning abbreviations, which would be the same on any redirect the template is used on. [I'm the one who said 'comment at WT:RE', and here I am yakking on!. Oh, well, que sera sera!] RichardΩ612 Ɣ ɸ 21:45, May 18, 2008 (UTC)
Moreover, if you were thinking that the template-based system would be easier, then don't worry. The options can be abbreviated, and full documentation can be written, with a guide at WP:RE for new users. RichardΩ612 Ɣ ɸ 21:49, May 18, 2008 (UTC)

I want to merge my usernames.

I have 3 or 4 usernames.

REASON: forget password, email account is deleted, etc.

I want to merge their edit history, counts, watchlist, etc.

I moved user page and user talk page manually.

But I can not move edit history, edit counts.

make this feature, pleas! :) -- WonRyong (talk) 22:26, 18 May 2008 (UTC)[reply]

This is, I believe, impossible at present. You could file a feature request at Bugzilla, but don't hold your breath. Algebraist 22:31, 18 May 2008 (UTC)[reply]
(follow up to Algebraist's response), not currently possible per the first bullet in Wikipedia:Changing username#Notes. --Gwguffey (talk) 18:48, 19 May 2008 (UTC)[reply]

An idea for FC recognition

(Duped from here) So we've got stars at the top-right of individual FC items, but there's usually no way to tell if (say) an article's featured unless you go there. What if FC links appeared as a different color than blue, say, green? Since FC articles inevitably touch upon more than just their own subjects, greenlinks could help browsing by steering people to the best prospects for research. It'd also provide an additional reward for FC stuff in terms of added visibility. Thoughts? Cheers, Mdiamante (talk) 13:05, 15 May 2008 (UTC)[reply]

No one? ;) Mdiamante (talk) 00:28, 19 May 2008 (UTC)[reply]
:) I think this is thinking more in terms of helping the regular editors than the casual reader, such as say the kind who arrives here via a google search etc. Different-colored links will be confusing and need to be explained. I think this proposal might be helpful but only as a user script or gadget (the kinds of extra tools we have in preferences under the "gadgets" tab). FYI there's already a gadget that colors article page titles according to their class -- green for good, blue for featured, etc. Equazcion •✗/C • 00:37, 19 May 2008 (UTC)[reply]
Aye, I saw that gadget, but unless I'm wrong, it doesn't apply to links, which is what I'm getting at. I grant that there may be an element of confusion at first, but there could always be one of those hide-able "things you may not know/greenlinks" captions at the top of the article itself. And would one different link color (aside from the pretty self-explanatory red) really be so vague? Cheers, Mdiamante (talk) 15:38, 19 May 2008 (UTC)[reply]
I struggle to see how this could be technically feasible without putting massive strain on the servers. -Halo (talk) 16:14, 19 May 2008 (UTC)[reply]
The server already looks ahead at page links to see if pages exist for them, so it knows what to turn into red links. It probably wouldn't be any more of a strain to have it check a new assessment flag and color the links accordingly. I don't think it's unfeasible, but I also don't really see the necessity. Equazcion •✗/C • 16:17, 19 May 2008 (UTC)[reply]
Its not feasible because the servers know nothing of "FA." Article classification occurs at the "presentation" level; it is not a database thing. -- Fullstop (talk) 17:13, 19 May 2008 (UTC)[reply]
Hence the "new assessment flag" portion of my comment. Equazcion •✗/C • 02:54, 20 May 2008 (UTC)[reply]

Changing assessment levels - please give us your choice

We've had considerable discussion, and we're considering putting A below GA, and adding a C-Class between Start and B. Please choose your favourite option here. Walkerma (talk) 05:37, 19 May 2008 (UTC)[reply]

Current birthdays

I have a suggestion. Why don't you include a tab listing birthdays of all notable people for the specific day? The tab could be right next to the "recent deaths" tab. In that way, you can read up on notable people. It should not be too difficult to manage. I find the "recent deaths" very informative, the same will apply here. —Preceding unsigned comment added by Cozinsky (talk • contribs) 07:40, 19 May 2008 (UTC)[reply]

This is already available from the main page, by clicking on the current date at the bottom of the 'On this day...' box. I agree this isn't as obvious as it might be. Algebraist 09:55, 19 May 2008 (UTC)[reply]

favorite pages section

I think there should be a button I can click that lets me save my favorite pages for viewing later like on youtube. Did anyone already think of this yet, it seems pretty obvious. —Preceding unsigned comment added by Dcutler (talk • contribs) 08:45, 19 May 2008 (UTC)[reply]

You could bookmark them in your browser, or make a list on your userpage (or subpage). Algebraist 09:53, 19 May 2008 (UTC)[reply]
Add said pages to your watchlist, then they can be viewed via "my watchlist" then "View and edit watchlist". -Halo (talk) 16:16, 19 May 2008 (UTC)[reply]
List them on your userpage. bibliomaniac15 02:20, 20 May 2008 (UTC)[reply]

Allow admin to restrict gadgets.

I have seen a rise in abuse of Twinkle since it has been added to the Gadgets list. Well I was thinking maybe admin should have the ability to restrict a person's gadgets. Like if a person is abusing Twinkle instead of blocking you can turn off the gadget and then lock the monobook (just in case). It is just because people using the Gadgets make it hard for admin and that the only thing you can do is block them. Rgoodermote  20:06, 20 May 2008 (UTC)[reply]

I'd say that Twinkle simply needs its own restriction mechanism, such as a "blacklist". Or that every gadget that can be abused (i.e. not the search box one) should have a mechanism for restriction. Kind of like how templates' documentation is at /doc, we could have each gadget a /blacklist page or something. x42bn6 Talk Mess 20:08, 20 May 2008 (UTC)[reply]
That sounds like it would work too. Rgoodermote  20:12, 20 May 2008 (UTC)[reply]
If someone is abusing the wiki they should be blocked. There is no way to stop people from using scripts improperly except blocking. It has worked in the past, and will continue to work in the future. This is a solution looking for a problem. – Mike.lifeguard | @en.wb 22:53, 20 May 2008 (UTC)[reply]
If you feel it could cause problems I give my full permission to close this discussion. But not all need to be blocked. Some people truly think they are helping when we say they are abusing. Some are ignorant and ignore us while others truly try to hurt. To figure those out we need to be able to stop a person from using that with little collateral damage. Losing a potentially good user collateral. Rgoodermote  23:19, 20 May 2008 (UTC)[reply]

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

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)[reply]
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)[reply]
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)[reply]
True, and I guess suicide can be looked at as self directed violence. --S.dedalus (talk) 01:29, 21 May 2008 (UTC)[reply]
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)[reply]
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)[reply]
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. 69.140.152.55 (talk) 02:56, 21 May 2008 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=213864039"