Wikipedia:Village pump (proposals)/Archive 27

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

"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 "10³⁰ years from now" to "10³⁰ years AD." NeonMerlin 13:27, 18 May 2008 (UTC)

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)

An editor with a sense of humour! Please, please don't leave Wikipedia! Philcha (talk) 13:35, 21 May 2008 (UTC)

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)

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)

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)

Yes, every civilisation has its own dating system. It's hard to find a base date that's precise and stable and culture-independent. For example the estimated date of formation of the Earth (4.6 BYA) is currently stable (I'm asking for trouble!) but not precise; the Big Bang's date is neither stable nor precise. Perhaps the date on which a spectacular astronomical observation was recorded would do, e.g. the Crab Nebula (=1054 AD).

Am I poking fun at the proposal? Yes!!! Philcha (talk) 13:35, 21 May 2008 (UTC)

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)

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)

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

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)

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)

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

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)

See? This whole discussion is moot. 199.125.109.126 (talk) 16:47, 18 May 2008 (UTC)

Wait... Are we in the fifties now? Waltham, The Duke of 17:41, 18 May 2008 (UTC)

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)

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)

January 1, 1950 (midnight UTC, probably).--Pharos (talk) 02:57, 19 May 2008 (UTC)

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)

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)

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)

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)

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)

Allow admin to restrict gadgets.

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

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)

That sounds like it would work too. Rgoodermote  20:12, 20 May 2008 (UTC)

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)

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)

We already have a process to restrict access to tools - see, for example, WP:AWB, where individual editors need to request use of the tool, and their contributions are evaluated before access is provided (I just looked - to date, 1825 regular editors can use it). If Twinkle is too powerful to simply let any editor select it, regardless of experience, then a similar approach could be used to restrict its use, without involving admins (or developers, to write yet more code). -- John Broughton (♫♫) 20:50, 21 May 2008 (UTC)

I had no clue...sorry for that. I will close this. Rgoodermote  01:57, 22 May 2008 (UTC)

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

Naming conventions (Burmese)

Please come over to Wikipedia talk:Naming conventions (Burmese) and state whether or not you would like to approve our naming conventions. We don't have many, so it won't take much of your time. Thanks! Kaldari (talk) 15:54, 21 May 2008 (UTC)

Search For User Contributions On A Specific Talk Page, Article Page, Category Page, Etc. Etc.

I proposal a way to search for all the contributions by a the same contributor on a specific talk page, article page, category page, etc. etc.

We can go to User contributions and see what the user contributed, using filters and using the drop down box to filterout for say contributions in the Articlespace. We need to search for contributions by editors for contributions in an article space for a specific article, let's say, so we can track down all the vandalism to the article contributed by the editor, let's say that it was pov. Please post this on the proposal media bugzilla or whatever cause I don't have an account. Thanks so much!68.148.164.166 (talk) 20:18, 21 May 2008 (UTC)

There are already a number of tools to do this - see the "History (of an article)" topic on the WP:EIW page. And we don't tend to look at vandalism just to a specific page - if an editor/IP address is suspected or known to be vandalizing, we check all edits - so the standard user contributions page is - for almost all cases of vandalism - the best tool. (For deep, pov vandalism, then yes, an article-oriented tool - see above - may be best, but this is relatively rare.) -- John Broughton (♫♫) 20:46, 21 May 2008 (UTC)

Reply button

Ever read a diff on an incredibly long page that you would like to reply to? What a hassle! You have to either find the exact section the comment was made in or you hit edit and wait a million years for the kilobytes of page text that has nothing to do with your edit to load. Wouldn't it be nice to be able to reply directly to a comment that was made. It would be easy to write a script that would insert the new comment directly below the other comment with the appropriate indentation. That would be glorious! Please, developers, develop this feature! I don't have this page on my watchlist, so if someone says they want to join me in rallying for this feature, comment on my talk page. ScienceApologist (talk) 23:48, 21 May 2008 (UTC)

How do you define "a comment"? --Carnildo (talk) 04:01, 22 May 2008 (UTC)

Presumably by looking for rows of colons at the start of the line. However, that feature is being developed, I think, in LiquidThreads (which many people are looking forward to, and many other people oppose). --ais523 11:04, 22 May 2008 (UTC)

A better talk system has been a perennial issue, unfortunately nobody has actually developed a workable alternative. --Dragon695 (talk) 01:02, 23 May 2008 (UTC)

What is wrong with LiquidThreads? —TreasuryTag—t—c 17:33, 23 May 2008 (UTC)

History of this text

This suggestion sort is something I've had in mind for a while, but it also sort of ties in with the previous one.

The most frequent reason I look at article histories is to find the change that added a specific part of the text. That's the sort of task a computer could do much more easily. I envision two ways to provide this function, one pretty simple and the other not.

Section history

The simple one is to provide, for every section of every article, a "section history" link that would display a list exactly like the article history page, but restricted to edits that may have affected the specific section. To keep the processing simple, edits that don't have a /* section */ command in their edit summary would always be included -- although it would be better if there was a database identifying which sections were edited in each change, so they could be included or excluded from the list as applicable.

The section history links could appear either on their own page with a manu based on the TOC (perhaps alphabetized, since section titles will have changed over time) and reached by a single link from the article and/or article history pages. Or alternatively, the section titles appearing in gray in the article history could become links to section histories.

Where an edit changes the title of a section, it would be ideal for this to be recognized and a combined history provided, but the simple solution of treating a retitled section as a new section that replaces the older one would still be practical.

Specific-text history

A more general technique would be to provide a form into which a chunk of text from the article could be pasted. The edit history would be scanned and all edits affecting text that matches that chunk would be listed. The comparison would be have to be on a form of the text resembling what you get if you copy-and-paste the rendered page, excluding all Wikimarkup.

No, I don't expect this would be fast -- but it'd be faster than doing it "by hand", and when it's what you want, it's what you want.

--207.176.159.90 (talk) 00:17, 22 May 2008 (UTC)

I, for one, would find this very useful. I frequently see articles with Cite errors caused by apparent inadvertent deletion of <Ref name=whatever>...<&lt/Ref> ref declarations which left orphan <Ref name=whatever /> refs behind. In those cases, I would use this facility to search the history for instances of <Ref name=whatever> to find the now-missing ref declaration. Searching manually for the missing ref declarations is very tedious.-- Boracay Bill (talk) 01:20, 22 May 2008 (UTC)

FYI: LemmeyBOT recently started to patrol and resolve certain ref issues like this. --—— Gadget850 (Ed) ^talk - 14:04, 22 May 2008 (UTC)

Have you seen WikiBlame? Anomie⚔ 01:22, 23 May 2008 (UTC)

Hadn't seen it. Thanks for pointing it out. I've bookmarked it. -- Boracay Bill (talk) 01:58, 23 May 2008 (UTC)

Yeah, interesting. It still would be nice to have this functionality within Wikipedia so you wouldn't have to download large numbers of versions to get an answer, but this is certainly better than nothing. Thanks. --207.176.159.90 (talk) 22:19, 23 May 2008 (UTC)

prononciation

I viewed the following page "Deus", and thought in general it would be cool, if one could click on the word

"pronounced",

and have the computer audio teach how to pronounce it. I would do it myself, but I am a real dunce in the computer world and am scheduled to die well before this task could be acheved. Hope some computer literate younger person might think this a worthy task. Good luck!

Deus (pronounced ['deːus]) is the Latin word for "god" or "deity". The Latin words deus and dīvus, and Greek διϝος = "divine", are descended from Proto-Indo-European *deiwos = "divine", from the same root as Dyēus, the reconstructed chief god of the Proto-Indo-European pantheon, also a cognate of the Greek Ζευς (Zeus). By the era of Classical Latin it ... —Preceding unsigned comment added by 24.190.247.176 (talk) 17:34, 22 May 2008 (UTC)

Some articles do have pronunciations you can listen to. You might want to suggest someone record one on the article's Talk page. — The Hand That Feeds You:^Bite 20:47, 22 May 2008 (UTC)

I think it would be great to have a systematic Wikiproject that tracks down all articles supplying pronunciations and adds audio pronunciations to them (as well as locates articles that ought to have one). Anyone who can read IPA and pronounce the necessary sounds could contribute to this. For articles like Napoleon it could give both the English and original foreign-language pronunciation. I think I'll propose this project if no one sees a reason not to. There's some overlap with Wikipedia:WikiProject Spoken Wikipedia, but that project has quite a different (and more difficult) mission. Dcoetzee 21:02, 22 May 2008 (UTC)

Please voice your opinion at Wikipedia_talk:WikiProject Spoken Wikipedia#Proposal: Pronunciation task force. Dcoetzee 21:21, 22 May 2008 (UTC)

Category:Main pages with misplaced talk page templates

This is an easy cleanup category to patrol - but there are a stack of "User:" and "Wikipedia:" space entries here - clearly the software is labelling user mainspace and Wikipedia project/policy mainspace as general mainspace. Can this be fixed? (i.e. so only article mainspace appears) Cricketgirl (talk) 08:02, 23 May 2008 (UTC)

That's the intended functionality of {{check talk}}. If there's consensus that it should be changed, it can easily be done by any admin. Algebraist 11:23, 23 May 2008 (UTC)

Language clean-up category splitting by language?

The categories which I try to do some work in, as a German-English bilingual, such as Category:Rough translations and Category:Wikipedia articles needing cleanup after translation, are generated by templates which have a parameter for sources language - so would it be possible to split the cleanup categories by language? It's really annoying to have to click through almost every article trying to find the ones that are from German - and having a distinct category for, say, Japanese, might make it easier to recruit Japanese-English bilingual help. Cricketgirl (talk) 08:05, 23 May 2008 (UTC)

Not a bad idea, that; and I doubt very controversial. You might want to ask over at WP:VPT to get a template coder to modify the templates and maybe a bot to sort the articles. —Ashanda (talk) 12:33, 24 May 2008 (UTC)

New section for Number articles: Age at time of death

A friend of mine had a birthday this week and I thought it would be fun if I could link to a page that shows historical figures that she is now older than. It would cross reference to a sentence on biographies that says [person] was ## years old when they died. —Preceding unsigned comment added by Vtricia (talk • contribs) 18:03, 23 May 2008 (UTC)

Wikipedia has about a quarter-million biographies of dead people. Is it really useful to have pages with lists of 10,000 or so names? --Carnildo (talk) 19:11, 23 May 2008 (UTC)

I don't think that's practical. How about Category:People that died in their 60's? --Tango (talk) 20:04, 23 May 2008 (UTC)

A category with maybe 100,000 entries is practical?? --207.176.159.90 (talk) 22:21, 23 May 2008 (UTC)

More so than a list with 10,000 entries, anyway. It could be split more. It's probably not worth it, though. Perhaps in the future we'll have the ability to semantically tag things in articles, then you could just run a query "list where type=person, deathdate-birthdate>X" (there is an extension, Semantic MediaWiki, that allows that kind of thing - it might be implemented on Wikipedia at some point in the future). --Tango (talk) 23:33, 23 May 2008 (UTC)

Go back to the old current event icon

Someone has been going around changing all of the current event templates to use instead of . Frankly, the one we were using before looks much better. I propose that we go back to the old icon on all the current event template messages. —Remember the dot ^(talk) 05:48, 24 May 2008 (UTC)

FYI, I think that this is the discussion that led to the change. Kelly ^hi! 06:02, 24 May 2008 (UTC)

I agree with Remember the dot! Totally unnecessary, and as you say the “new” one is not very appealing. It doesn’t look like consensus was actually reached to make the switch in the first place anyway. The changes should be reverted pending a better discussion. --S.dedalus (talk) 06:06, 24 May 2008 (UTC)

I agree that the old icon is nicer than the new icon. However, I feel that looks better than either of those two. —David Levy 09:00, 24 May 2008 (UTC)

I agree, the one David has put forward seems more professional looking somehow, I say replace the old and new one with that. ☯Ferdia O'Brien ^(T)/_(C) 09:10, 24 May 2008 (UTC)

I also agree with Remember the dot. We should by now have a significant enough number of users to demonstrate that the change did not have consensus. Harryboyles 13:43, 24 May 2008 (UTC)

• I have reverted all of the templates back to the old icons, including the group of templates like {{future}} that had the new icon since May 4.[1] Cheers. Zzyzx11 (Talk) 15:55, 24 May 2008 (UTC)

Rating Images?

I was thinking about a rating system for images similar to WP:ASSESS. Any ideas? RedThunder 14:49, 24 May 2008 (UTC)

The idea is interesting, but I'm not sure I get the purpose. One major difference between images and articles is that the former tends to be static, especially when it comes to photographs. It may be possible to bring stub to a featured article, but not to bring a 800x600 overexposed photograph to featured picture status. Assessment may determine important articles that are of good quality, but ultimately images are useful only to the extent that they help illustrate an article. One thing that's useful is to determine if pictures can be somehow improved—e.g., if svg diagrams have incorrect information, or if a picture has a watermark, or if a photo is too dark and needs to be made lighter—and this Wikipedia and Commons already do have systems for that. Gracenotes^T § 15:20, 24 May 2008 (UTC)

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)

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)

The Editors' Index to Wikipedia covers some of what you want.-gadfium 04:18, 18 May 2008 (UTC)

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)

Since this seems to be an uncontroversial suggestion I've gone ahead and implemented it at WP:RFPP and I've also made an AfD example page. More opinions would be appreciated. Pax:Vobiscum (talk) 16:04, 23 May 2008 (UTC)

Yes please, implement this across the board now... I remember not knowing where to start, and part of the problem stopping me from dipping my toes in the water at MfD is that the instructions are in 16 different places. And then, once they're all in the same place across the board, we can start standardising - keeping headers in the same place, as Z-man said. Go for it, quick! I can't see the downside. Alex Muller 19:02, 25 May 2008 (UTC)

Oh, by the way - I don't know whether there'd be much call for something like this because it's probably not necessary to move between those pages, but an index of all of them might not go amiss... Alex Muller 19:14, 25 May 2008 (UTC)

Shortcut template changes

Today a fairly big change of the functionality of links in the {{shortcut}} templates was suggested. (The links will no longer take you back to the page the box is on, but instead to the shortcut redirect page.) The change seems like a useful improvement so I am thinking of adding it. Since this affects lots of project pages (like this page) and I know many of you reading this page uses such shortcuts I thought it best to announce it here too. Take a look at the discussion and examples at Template talk:Shortcut#Shortcut links.

And while I am at it: We added a feature to the shortcut templates some week ago: They now automatically add section anchors to the pages they are used on. See documentation of the anchor functionality at {{shortcut}}.

--David Göthberg (talk) 02:23, 26 May 2008 (UTC)

If I understand this correctly, implementing the proposal will make things a bit more difficult and confusing for non-editor WP users who click shortcuts in order to provide an occasional slight convenience for WP editors who are into the nut & bolt workings of wikinavigation. If I've got that right, the priorities seem reversed. -- Boracay Bill (talk) 03:19, 26 May 2008 (UTC)

The links on the {{shortcut}} template are shortcuts for the page you are currently on, so the link will just take you back to the current page. For example, see the shortcut box for this page. Mr.Z-man 03:55, 26 May 2008 (UTC)

Please guys, discuss this at that template's talk page: Template talk:Shortcut#Shortcut links. Since then the conclusions of the discussion are left at the right place for future editors to read, instead of deep inside the Village pump archives. I announced the changes here just to draw attention to them and so people won't come later and ask: "Why didn't you announce the changes before you did them?"

Boracay Bill: I responded to your comment at that template's talk page.

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

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)

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)

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)

Hmm. There's always Special:WhatLinksHere/Wikipedia:Use_common_sense. Dcoetzee 02:55, 16 May 2008 (UTC)

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)

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

OK, I see that a "common sense noticeboard" per se might not be such a good idea, but what about a centralized location with links to discussions on article talk pages which potentially serve as examples of how policies and guidelines might need to be reworded? PSWG1920 (talk) 22:40, 21 May 2008 (UTC)

It would wind up linking to practically every policy page, though. Policies & guidelines are constantly reworded, challenged and otherwise debated. — The Hand That Feeds You:^Bite 22:57, 27 May 2008 (UTC)

Requesting more details

I generally love Wikipedia and use it almost daily, but from time to time there are particular details on topics that I'd like to see expanded. I have a very slow internet connection, so there may already be a way to do this that I haven't found, but could there be a mechanism to request expansion on topics, maybe by flagging the article? I think something like this could help Wikipedia grow by providing authors with a means of feedback so they know what readers want to know more about. This may not be practical and I doen't expect any kind of personalized service, but it could result in a one stop place where someone who wanted to contribute could see what topics have a demand for more details. —Preceding unsigned comment added by 132.236.155.76 (talk) 21:28, 25 May 2008 (UTC)

Normaly adding some kind of stub template or {{Expand}} but there are so many articles that need expansion that taging is unlikely to help much.Geni 23:26, 25 May 2008 (UTC)

My best advice is: leave a note on the talk page giving specific requests for the information that you believe is missing. A general {{expand}} tag says almost nothing - a specific request evokes a response, either in the form of actual article expansion, "that sounds like a good idea but I don't know that info," or "that info doesn't really belong in this article, but maybe we should link X." Dcoetzee 05:53, 26 May 2008 (UTC)

Absolutely - click the "discussion" tab, then "new section", then leave a comment saying something like "I expected to find information about thing1, thing2, thing3 ..., but didn't. Would someone please add that to the article?" (As for "expand" templates, I dislike those - virtually everything but Feature Articles and Good Articles need expanding, so what exactly is the point?) -- John Broughton (♫♫) 16:17, 27 May 2008 (UTC)

Threats/suicide admin. notice board

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

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

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

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

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

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

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

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

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

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

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

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

I'm not very sure what should be done.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Video requests

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

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

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

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

muchasref

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

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

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

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

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

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

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

There's also this template as well:

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

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

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

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

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

Unified login

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

Slideshows

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

Pronunciation explanations

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

Renaming the "move" tab to "rename"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agreed, will do. -- Quiddity (talk) 23:37, 7 June 2008 (UTC)

Non-admin rollbackers

Transcluded from Wikipedia:Rollback feature/throttle removal

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Discussion

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

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

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

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

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

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

Straw Poll c

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

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

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

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

Support for rollback throttle removal

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

Oppose rollback throttle removal

Neutral

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

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

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

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

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

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

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

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

Origin of the throttle

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

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

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

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

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

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

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

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

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

Update

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

10/minute, actually -- Gurchzilla (talk) 17:37, 28 May 2008 (UTC)

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

raw signature example

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

English Wikibooks needs a new logo

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

Emergency anti-Sock task force

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

Site-wide spelling choice tabs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Non-Wiki Talk Pages

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

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

Disadvantages (apart from the two posted above):

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

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

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

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

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

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

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

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

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

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

New user group for prolific article creators

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Send to a friend

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

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

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

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

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

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

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

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

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

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

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

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

Why is news being posted on the Main Page?

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

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

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

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

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

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

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

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

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

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

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

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

User:FritzpollBot creating millions of new articles

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

Operator response to some issues

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

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

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

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

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

Re: RfA proposal

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

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

to:

Dear nominee, please answer the following questions:.

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

Improvement in "Random page" methods

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

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

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

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

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

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

Page move speed restriction

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

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

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

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

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

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

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

Straw poll

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

Increase autoconfirm

Please see Wikipedia:Autoconfirmed Proposal/Poll.

Page move speed restriction

1. There is a restriction already, of course, but making it smaller would probably be worthwhile. Now we have the move-with-subpages feature, 1/60 (i.e. one page move a minute) would probably be worthwhile. With the current setup admins and bots would be immune to it, and it would be trivial to set up a third group that could move pages more quickly (along the same lines as accountcreator) if a need for it were found. --ais523 13:57, 9 June 2008 (UTC)

Don't change anything

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

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

Comments/other

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

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

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

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

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

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

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

Message box standardisation, all namespaces

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Proposal to extend CSD A3

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

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

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

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

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

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

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

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

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

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

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

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

FritzpollBot Discussion

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

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

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

Submit To Bugzilla

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

Two related proposals

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

search

 

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

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

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

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

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

Confusing note on Wikipedia:Sandbox

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

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

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

Make established articles move protected?

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

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

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

or

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

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

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

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

Post On Bugzilla

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

Merge donation banner with anon tips

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

Ratification vote on {{C-Class}} started

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

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

Change "navigation" on sidebar to "browse"

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

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

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

The results of merge discussions are seldom recorded

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

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

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

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

Font Style in Wikipedia difficult to read

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

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

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

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

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

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

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

Image copyright tags

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

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

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

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

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

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

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

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

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

Proposal to reduce the protection level of Wikipedia:Upload

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

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

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

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

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

Welcoming Committee

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

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

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

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

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

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

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

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

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

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

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

"First" and "Last" buttons

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

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

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

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

User interface proposals

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

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

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

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

Default Auto-Sign

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

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

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

Using Random String Instead of IP Addresses

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

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

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

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

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

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

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

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

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

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

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

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

Category Overlap Tool

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

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

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

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

Stagnation Prevention List and View Count

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

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

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

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

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

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

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

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

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

Please Post On Bugzilla, Thanks!

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

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

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

Founder or Co-founder that is the question

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

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

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

File upload instructions

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

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