Jump to content

Wikipedia:Village pump (proposals)/Archive 52

From Wikipedia, the free encyclopedia

Stub edit tab: emphasis and invitation

Archived

For stubs, I suggest having the edit tab changed from edit this page to edit this stub.

Why change "page" to "stub"?

The word "stub" is more of a invitation to contribute. Indeed, "stub" suggests work is needed and that the reader is welcome to help. This would help create editing micro-opportunities.

Why orange?

Orange is a more "visible" colour than the current blue.
Orange is similar to red, underlying the similarity between stubs and nonexistent articles.

Discussion (edit tab)

Don't bite too hard! :) GeometryGirl (talk) 11:56, 9 September 2009 (UTC)

  • To more directly address the stub proposals though: You gloss this over potential problems section above, but the fact is that stub articles are not really special, and certainly should not be singled out as potentially needing attention. The root of this proposal seems to lie in a fundamental misunderstanding of what a Wikipedia:Stub article actually is.
    V = I * R (talk to Ω) 13:04, 9 September 2009 (UTC)
    "A stub is an article that is too short to contain suitably encyclopedic material" is the definition of a stub. Since this is indeed an encyclopedia, I think that means this most definitely does mean that they should be singled out as needing attention, and not just potentially. A stub article is not appropriate for an encyclopedia. I have seen some editors say "some articles just cant ever get beyond a stub", the correct response to those people is- 1- the article shouldnt then exist and should probably be merged with similar stubs as a list article or 2- its a short article but not a stub, a short article that has encyclopedic content and is a good article can be classified as more than a stub even an FA. I see no misunderstanding in what a stub is in this proposal, give good faith that people know what they are proposing, since doing otherwise and lecturing that they dont is bad-faith. With that done I do have to say that this is still a bad idea because its simply semantics. Who cares if it says "edit this article" or "edit this stub", it wont actually bring in more editors in my opinion.Camelbinky (talk) 13:35, 9 September 2009 (UTC)
    That is very much my point, thank you Camelbinky. What do you think of the orange link proposal above? And why don't you think making the link orange will not attract more people? GeometryGirl (talk) 13:40, 9 September 2009 (UTC)
    I see that is what the lead says now, but if you actually read the document it does (more accurately) state that stub articles are not specifically an issue to be resolved. Some articles should be stubs, and there's nothing wrong with that. They simply don't need attention due to the fact that they are stubs alone.
    V = I * R (talk to Ω) 13:55, 9 September 2009 (UTC)
    (edit conflict)Actually, merits aside, I have to wonder if this is technically feasible. Presently, tab names are assigned based on namespace, with no regard for content. --King Öomie 13:42, 9 September 2009 (UTC)
    That's what I was attempting to get across, above. It's really not technically feasible right now.
    V = I * R (talk to Ω) 13:55, 9 September 2009 (UTC)
    Well, it COULD be done, but it'd have to be global javascript, and could potentially play hell with people's Monobooks. Again, not seeing a possibility of global deployment. Looks fine for opt-in, though, I'm sure a script could do it (you can already reduce the "Discussion" tab to "Talk"). --King Öomie 14:00, 9 September 2009 (UTC)
  • While well intentioned, I find it extraordinarily doubtful that this change would result in any increase in the amount of stubs being upgraded. It is the article/subject itself - not an orange link at the top - that determines whether or not someone is interested in editing it. Shereth 16:21, 9 September 2009 (UTC)
    Why are there 300 000 000 different viewers a month but only 90 000 active editors in a given month? Come on! It's not just "the article/subject itself". Sure, that is a necessary condition, but it surely is not sufficient. GeometryGirl (talk) 16:30, 9 September 2009 (UTC)
    I don't follow your point. There are 300M visitors but only 90K editors because the vast majority of people are interested in reading, not editing. Visitors know Wikipedia is editable by anyone. As a general rule people edit articles that interest them. Put simply: if I am looking for information on Horse Mesa Dam, I go to the article and find very little information, so I move on to another source. How is changing the color of the "edit" link is going to cause a revelation that I should jump in and improve the article? I appreciate what you are trying to do, but colorizing the tabs at the top is not going to incite people who have no interest in editing to chagne their minds. Shereth 16:44, 9 September 2009 (UTC)
    My point is that Wikipedia is giving out the wrong message with everything blue. Basically, the current message is "you can edit Wikipedia if you want, but we are doing fine without you". The message Wikipedia ought to give is "you can edit Wikipedia and we really need you to do so". Get my point? GeometryGirl (talk) 16:47, 9 September 2009 (UTC)
    To put it another way, Wikipedia needs money, and they periodically ask for donations. Well Wikipedia also needs editors, and we should be advertising the NEED, not just the possibility of becoming an editor. There is a real need... (and a lot of potential). GeometryGirl (talk) 16:51, 9 September 2009 (UTC)
    I get your point. I don't agree with it. I do not agree that bluelinks imply "This article is finished and doesn't need improvement". I do not see how orange links would thusly imply "This article needs help", and I especially do not see how the casual reader is going to understand that implication. Moreover, I don't think you get my point. People who are not here to edit are not here to edit; changing link colors is not going to change that fact. People who are here to edit, edit what interests them; changing link colors is not going to change that fact. Again, I appreciate what you are trying to do, but I just don't see this as doing anything to help. Shereth 16:53, 9 September 2009 (UTC)
    So you do not think that there are people who come to Wikipedia "to read", would be willing to contribute, but do not contribute because they do not feel the need to contribute, or are not prompted enough to contribute? (Because, e.g., Wikipedia already has 3 000 000 articles and is doing just fine.) GeometryGirl (talk) 16:57, 9 September 2009 (UTC)
    The goal is to convert people from readers to editors. Really basic. GeometryGirl (talk) 16:59, 9 September 2009 (UTC)
As Shereth said, everyone who comes here knows that anyone can edit. It's on the logo. If they don't WANT to edit, and they come across a lackluster page, they're STILL not going to want to edit.
It doesn't matter how colorful the blown piston is, I still don't want to learn how to fix my engine. The tab name change is fine, for consistency's sake, but the color change is really not required. --King Öomie 17:04, 9 September 2009 (UTC)
(ec, response to GG) No, I don't think so. Take an example. I am a casual reader who is willing to contribute, and I go to Horse Mesa Dam. I see that the article is really short, and even has stub templates that say "This article ... is a stub. You can help Wikipedia by expanding it." Are you saying that, when I go to hit the "edit this page", I will see the blue link and therefore conclude "Oh wait, it is bluelinked, they must not need my help?"
Really, I should be dispensing with all of these hypotheticals and simply ask : how does an orange link (as opposed to a blue link) convey, to the causal reader, that we really want their help? If they are a casual reader, how are they supposed to understand this distinction between blue and orange links? I agree with your goal of trying to entice readers to become editors. Put simply, however, orange-linking a tab is very unlikely to contribute to this goal. Shereth 17:07, 9 September 2009 (UTC)
(e/c)I think you're completely misunderstanding his argument. I agree with Shereth. Bluelinks do not imply that the article is complete, or doesn't need any work. I don't what you're basing that on, other than personal opinion. Every article could be improved. No article is ever "finished" I don't see how changing link color is going to do anything other than make articles harder to read and introduce accessibility problems for people with poor vision (orange text on white background has rather poor color contrast, and I believe it fails WCAG AA priority level). Mr.Z-man 17:08, 9 September 2009 (UTC)
I agree with you guys, bluelinks do not imply that the article is complete, or doesn't need any work. I agree. However, what I am saying is that there is a difference between "YOU CAN EDIT" and "YOU NEED TO EDIT"? I agree with you, most people know that they can edit. But do they know that Wikipedia needs them? For you engine, you can just ask a mechanic. But Wikipedia is volunteer based... Can't ask people other than our readers.
I really don't see how the proposed change reflects that though. It relies too much on implied meaning by color and a slight wording change. Imagine if {{cleanup}} was nothing but a box with a picture of a broom in it. 1) I don't think the connection is very obvious and 2) As Shereth said, people edit what they're interested in, not what we tell them they should be editing. Mr.Z-man 17:21, 9 September 2009 (UTC)
And in response to GG, in the case of a busted engine, I'd likely rely instead on the volunteer network of 'My Neighbor Jeff', who keeps my car running because I do the same for his computers. --King Öomie 17:28, 9 September 2009 (UTC)
  • Pale orange, as proposed, is barely visible. It looks darker on cheap uncalibrated office-type LCDs; step up to a properly calibrated screen, you'll be amazed how light it is. As long as background is white, orange is a no-no. On a completely different issue, don't rely on article ratings below FA. Never. English wikipedia has no way of enforcing consistent and reliable article ratings. Take a look at this diff. Stub to GA. Guess what? It was not a stub. It was not GA either. How long could it go unnoticed? NVO (talk) 17:14, 9 September 2009 (UTC)

Stub edit tab: new proposal

Dismissed for now

For stubs, I suggest having the edit tab changed from edit this page to please edit this stub or please edit this stub or Please edit this stub pr Please edit this stub.

Why change "page" to "stub"?

The word "stub" is more of a invitation to contribute. Indeed, "stub" suggests work is needed and that the reader is welcome to help. This would help create editing micro-opportunities.

Why add "please"?

To make readers understand that they contribution is required for Wikipedia to exist and evolve. "Please" also formally expresses an invitation to contribute.

Why red?

Red is a more "visible" colour than the current blue.
Red expresses the similarity between stubs and nonexistent articles.
Red expresses a need.
Orange is too pale.

Why green?

Because red links on Wikipedia exclusively mean "this page does not exist".

Why stubs?

Because stub articles are not appropriate for an encyclopedia: "A stub is an article that is too short to contain suitably encyclopedic material". Also, new editors would less likely get lost in the small amount of wikisyntax contained in stubs. Finally, in many ways, improving a stub is easier than improving a developed article.

For who?

For all readers by default.

Discuss (edit tab new proposal)

Don't bite! GeometryGirl (talk) 17:27, 9 September 2009 (UTC)

Ok, we can find some other colour. Green? GeometryGirl (talk) 17:34, 9 September 2009 (UTC)
And subconsciously suggest that the article is fine? The full gamut of begging readers to expand the stub is accomplished by the {{stub}} template itself- if that won't sway them, more pressing will only serve to irritate.
<Creative slippery-slope argument that sways your opinion> --King Öomie 17:36, 9 September 2009 (UTC)
  • (ec) I don't want to badger you. Really I don't - I like what you are trying to do in encouraging more participation and in getting more readers to become editors. Really. This proposal, however, is just the last one re-done in new colors. The choice of color (red, blue, green, orange, magenta, ultraviolet, whatever) is not relevant. Even the wording ("Edit this page", "edit this stub", "please edit this stub", "We really need some help expanding this stub so please lend us your expertise and expand it into something bigger") is of little relevance. The whole point of my argument is that a tab at the top of a page is not going to encourage participation in the project. The ultimate goal of this proposal is noble but at the moment the energies here are being misdirected down a dead-end street. You are aware that the wording of pretty much every single stub template reads "This article ... is a stub. You can help Wikipedia by expanding it." The appeal has already been made, making it again is expending effort where it is not effective. I'm sorry, I just can't support a proposal that has little to no real benefit to it. Shereth 17:37, 9 September 2009 (UTC)
    Have you tested this proposal? Does it really have little to no benefit? That's slightly pretentious. But anyway, the template says "You can help Wikipedia" and not "please help Wikipedia" (in the same way that we have "Please donate" and not "You can donate"). It is a (subtle) matter of sending the right message. GeometryGirl (talk) 17:41, 9 September 2009 (UTC)
    Then perhaps your energies would be better spent on trying to refine existing mechanisms (by proposing changes to the stub templates) rather than by trying to re-invent the wheel? Shereth 17:44, 9 September 2009 (UTC)
    Please, assume good faith, and don't bite. Why not even do both? (For the template, I hadn't even thought about it.) GeometryGirl (talk) 17:46, 9 September 2009 (UTC)
    Pardon? I'm not sure where I have failed to assume good faith or violated WP:BITE? I have made every effort to be civil with my replies and I expect not to have these kinds of policies waved in my face for no apparent reason. As far as "why not do both" - it is woefully inefficient to do something twice when once will suffice. Modifying templates requires simple edits, whereas what you are proposing requires changes to the MediaWiki software itself. When a simple solution exists, why continue to pursue the more complex? Shereth 17:50, 9 September 2009 (UTC)
    Well you where saying I was "reinventing the wheel" when that was not at all my intention (faith). Maybe I just took the comment badly after all the negative comments I have been having in exchange of all the time I am donating. I have created a new proposal below. GeometryGirl (talk) 17:55, 9 September 2009 (UTC)
    Proposing something has become a battle. It seems editors are having the same problems with editing. No wonder editors are leaving. GeometryGirl (talk) 17:57, 9 September 2009 (UTC)
    Pass/fail statistics aren't subject to a grade curve. --King Öomie 17:59, 9 September 2009 (UTC)
I think this has almost all the same problems as the orange proposal. It still relies too much on the meaning being implied by using colors and "stub" instead of "page." It doesn't have the accessibility problems of orange. However, green sends the wrong message entirely. Green suggests that the article is fine, a lot more than blue does. Red on the other hand, would be confusing by having it serve 2 different (albeit related) purposes. And to reply to some recent comments, proposing things is a discussion. If nobody disagreed with the idea, chances are we'd already be doing it. Mr.Z-man 18:05, 9 September 2009 (UTC)
Again, I'm not sure why changing the edit tab would encourage editors; there's a lot of made-up "this would help!" arguments being made, but without any explanation as to why or how. EVula // talk // // 18:07, 9 September 2009 (UTC)
(edit conflict)Ok, make it blue, but underline it, I don't know. What do you think of Please edit this stub?
...why? Why would it be underlined? None of the other tabs are, and it's more important (in my mind) for things to be consistent. EVula // talk // // 18:12, 9 September 2009 (UTC)
OK, OK, as you want. Remove the underlining, Please edit this stub GeometryGirl (talk) 18:21, 9 September 2009 (UTC)
@EVula Why this would help? Because it changes the attitude Wikipedia has towards readers. Instead of saying to them "you can edit this page" which doesn't imply any need for this page to be edited, Wikipedia would say "please edit, you must!". It's a PR campain. GeometryGirl (talk) 18:12, 9 September 2009 (UTC)
Ah, that's why we disagree: you are wrong (I mean that in the nicest way possible, but after so many proposals in short order where everyone has been nice, I feel that someone needs to be a bit more blunt about it). Our readers don't have to edit Wikipedia; to say that they must is a lie. We, of course, would like to encourage more readers into getting involved, but honestly, it just plain isn't something for everyone. We need to remain open so that anyone can edit, but we don't need to be going out of our way to make sure that everyone does edit. As it is, I'm still not sure how "please edit" will achieve any sort of change whatsoever; I really think you're wasting your (apparently boundless) energy. You'd be better served trying to figure out a way to make editing more approachable by those readers who are interested in editing, rather than trying to fit square pegs into round holes. EVula // talk // // 18:21, 9 September 2009 (UTC)
I exaggerated a bit when I said "they must". But please see this video, it is my inspiration. GeometryGirl (talk) 18:25, 9 September 2009 (UTC)
  • I don't what to badger you either, but ultimately I agree with Shereth. I ahve all along, actually. I agree with the underlying goal here (encouraging participation), but this just isn't he means to achieve it. I can tell that you're feeling a bit embattled here, and for that I'm really sorry especially since you're obviously highly motivated to address the participation issue. I don't want to discourage you at all, and I don't think that Shareth or anyone else does either. We're just trying to say that you're energy is currently misdirected a little bit, is all. My recommendation is to check out, and jump into participating in and assisting, the Usability Initiative. This whole subject area is exactly what their tasked (and funded!) with pursuing.
    V = I * R (talk to Ω) 18:13, 9 September 2009 (UTC)
  • Thanks for the advice. I have already posted two proposals (one for green links, and one for orange links) on the usability wiki. The project seems dead, no one participates. Money doesn't make everything... GeometryGirl (talk) 18:19, 9 September 2009 (UTC)
A lot of people participate, actually. My watchlist moves faster than my car. --King Öomie 18:23, 9 September 2009 (UTC)
Well not mine! What is on your watchlist? GeometryGirl (talk) 18:26, 9 September 2009 (UTC)
Approaching 400 pages. I could add WP:AIV and WP:ANI to make it REALLY fly. --King Öomie 18:46, 9 September 2009 (UTC)
Oh, so you are watching every page! Well I'm just watching two, and they are basically dead. I looked around other pages and haven't found very active pages... GeometryGirl (talk) 18:49, 9 September 2009 (UTC)
I'm watching less than 0.014% of all the articles on En. Non-contentious articles can remain stagnant for weeks, and tend to see a flurry of activity when the subject is reported on in some fashion (read: Colbert). This is perfectly normal. Try following Barack Obama. Articles like Nickelback are plastered with vandalism multiple times daily (and my heart goes out to the vandals, they who know the truth, but lack the means to express it civilly :D). --King Öomie 18:57, 9 September 2009 (UTC)
She was talking about at the Usability Initiative, not en.wikipedia.
V = I * R (talk to Ω) 19:03, 9 September 2009 (UTC)
Hmm, I'm not sure. She referred to posting these proposals twice, and then referred to "the project" as dead, which I interpreted as the entire project. --King Öomie 19:07, 9 September 2009 (UTC)
Quote: "I have already posted two proposals (one for green links, and one for orange links) on the usability wiki. The project seems dead, no one participates." :)
V = I * R (talk to Ω) 19:09, 9 September 2009 (UTC)
Quote: "The project seems dead, no one participates." :D
Final word goes to GG. --King Öomie 19:12, 9 September 2009 (UTC)
I was talking about the usability wiki, obviously. Thank you Ohms law. GeometryGirl (talk) 19:52, 9 September 2009 (UTC)
=( --King Öomie 20:16, 9 September 2009 (UTC)
Just because they don't use the wiki that much doesn't mean the project is dead. Its still very much active on the software development side. Mr.Z-man 21:59, 9 September 2009 (UTC)

Changing the stub template

Proposed at WP:Stub
I propose to change to
This article is a stub. Please help by expanding it.

or something similar.

If I'm not mistaken, this belongs at Template talk:Stub. But for good measure, Support. --King Öomie 18:00, 9 September 2009 (UTC)
Actually, there are about 20,000 stub templates. I'm not really sure where it should go. --King Öomie 18:02, 9 September 2009 (UTC)
Thanks to one very sexy bot operator all stubs are now built with Template:Asbox. One simple change could make that phrase green, whether there is consensus to do so is another story. Discussion about that should occur here or maybe at WT:Stub. –xenotalk 18:04, 9 September 2009 (UTC)
All narcissism aside, I'd think a notification of this discussion at WT:STUB would be sufficient. But of course, we are all very thankful for sexy bot operators :) Shereth 18:12, 9 September 2009 (UTC)
Happier now? No green? Please, I wrote "or something similar", be constructive. GeometryGirl (talk) 18:14, 9 September 2009 (UTC)
Changed the colour. GeometryGirl (talk) 18:15, 9 September 2009 (UTC)

I have just had a thought. As any lecturer who has presented using overhead acetates or Powerpoint will know full well, one has to be very careful with choice of colours, so as not to confuse students who may suffer from colour blindness. Are you sure that your choice of colour scheme will not do this? One thing I should say is that perhaps the most common form of colour blindness is red-blue colour blindness - so perhaps you are right, we do not need to change the colours of wikilinks! ACEOREVIVED (talk) 23:11, 9 September 2009 (UTC) I have a feeling I was actually thinking of red-green colour blindness - please, pleaes, consider this. Although I do not suffer from colour blindness myself, remember, Wikipedia should be accessible to all. ACEOREVIVED (talk) 23:23, 9 September 2009 (UTC)

FWIW, red-green is the most common form of colourblindness, followed by total colourblindness, then blue-yellow - though that's all beside the point. I have a question, though... why is this change being proposed? If it serves no purpose (and for the life of me I can't see what purpose it would serve), then it simply seems to be wasting effort. What difference does centring the text do other than moving the icon away from the left margin and potentially making formatting look odd in a few cases? Similarly, what difference would changing the colour make other than making readers wonder whether the stub message is a hyperlink? In both cases it would increase the visibility of the stub template (something which we've been doing as much as possible to avoid at WP:WSS - the more discreet a stub template is, the better), but other than that, it wouldn't really make for any other than a cosmetic change. By the way, King Oomie is right - changes to the stub template(s) are normally discussed over at either Template talk:Stub or at Talk:Stub. Indeed, there have been numerous suggestions on changing the look of stub templates there in the past in many different ways - including, IIRC, a rejected suggestion to centre stub messages. Grutness...wha? 01:27, 10 September 2009 (UTC)

Auto update?

It would be cool if http://en.wikipedia.org/wiki/Special:Statistics auto updated. Accdude92 (talk) (sign) 13:14, 10 September 2009 (UTC)

The page would have to be a dynamic frontend, and I'm not sure that's technically possible on Wikipedia at this point. --King Öomie 13:27, 10 September 2009 (UTC)
It does "auto-update". That page is part of the software, and is updated as part of a batch job on the server. That's my understanding, at least. It's not real time, but it is regularly updated.
V = I * R (talk to Ω) 13:29, 10 September 2009 (UTC)
90% sure he means dynamically updating without having to reload the page. That's what my response was referring to, anyway. --King Öomie 13:31, 10 September 2009 (UTC)
(edit conflict)(edit conflict) i would like it to update in real time.Accdude92 (talk) (sign) 13:33, 10 September 2009 (UTC)
The dreaded double-conflict? Ouch. Again, that would be a WHOLE lot of coding work, not to mention possible performance issues, for an update that would really only be "increased coolness", with no actualy fuctionality boost. --King Öomie 13:39, 10 September 2009 (UTC)
lol yep, its the wikipedia apocalypse!!! Anyways, since this is the proposal section, I just posted this as an idea. So no hard feelings.Accdude92 (talk) (sign) 13:42, 10 September 2009 (UTC)
No, none at all. I agree, that would be cool (I'd love to see that for the Watchlist, as well as sorting and dynamic searching), but it's just not feasible. --King Öomie 13:48, 10 September 2009 (UTC)
Wow, it just kicked me an edit conflict over converting '~~~~' to my sig... --King Öomie 13:50, 10 September 2009 (UTC)
I told you its the wikipedia apocalypse!Accdude92 (talk) (sign) 13:55, 10 September 2009 (UTC)
Almost all of the statistics are up to date when you load the page. I think the "active users" count is the only thing that isn't. However, most of the statistics (except the number in each user group) are off somewhat anyway. The total number of pages is off by ~57,000. The number of images is off by ~8,500. The number of user accounts is off by ~29,000. (All of the numbers on the statistics page are lower than the actual.) There's no real efficient way to calculate the number of articles in the same way used to increment the count for the statistics, but its probably off by ~7,000. Mr.Z-man 18:22, 10 September 2009 (UTC)

Microformats in stubs redux

A number of stub templates already emit microformats. I have made a request for a change to {{Asbox}} to facilitate their use with less inline HTML markup, but a couple of editors have expressed concerns. Additional input (at that page, please) would help. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:33, 10 September 2009 (UTC)

Editing tools

Any time I want to edit, I have to wait while all those cutesy icons load (not all of which will function on the computer I use). when they are finally loaded, the screen jumps, and I usually have to scroll to get to the top of the section or article to be edited. It is an awkward mess. Is there any way I can turn off all this fancy stuff that makes Wik compete with MSW for bloat? Kdammers (talk) 09:35, 5 September 2009 (UTC)

It's in your preferences, amazingly enough. Algebraist 12:47, 5 September 2009 (UTC)
Editing tab -> untick "Show edit toolbar (requires JavaScript)" I would think. - Jarry1250 [ In the UK? Sign the petition! ] 12:52, 5 September 2009 (UTC)
My "Show edit toolbar (requires JavaScript)" is not ticked, but I still get the bloat. Kdammers (talk) 06:33, 12 September 2009 (UTC)

multi-lingual search>

I propose that there be an option to search all languages of Wik at once. Thus, if I want to know if John Z. Doe has been written about in any Wik, I could click this option. It would be helpful for both editors and for people looking for rare items. If this feature already exists, it should be made easier to see, e.g., on the Wik start page as a small button at the bottom. Kdammers (talk) 02:45, 12 September 2009 (UTC)

You can find this information by going to the John Z. Doe article and looking at the left sidebar. EVula // talk // // 02:47, 12 September 2009 (UTC)
I think Kdammers' point is that if you go to an article that does not exist, there's no way to determine which other languages do have the article. —Noisalt (talk) 04:41, 12 September 2009 (UTC)
Yeah, but words change from language to language. If you are looking for an article on England on allwikis, it wouldn't work because in French, England is Angleterre. Do you get what I'm saying? warrior4321 04:51, 12 September 2009 (UTC)
True, there would be limitations, but with most proper names for many or most languages, and with the help of auto-translation technology, I think it would at least cover a fair bit of ground. Kdammers (talk) 06:29, 12 September 2009 (UTC)
How often do people search (or have the need to search) the English Wikipedia for non-English articles? Not only that, but while I'm sure that there are articles on topics (people, locations, etc) that are possibly only in those localized languages, the English Wikipedia is pretty comprehensive; I'd say that, nine times out of ten, if we don't have an article on something, one of the smaller wikis doesn't either. (again, I realize there are times where that isn't the case, but they are traditionally for very local topics, and probably wouldn't be covered by Kdammer's "fair bit of ground" comment above) EVula // talk // // 14:59, 12 September 2009 (UTC)
Exactly. Moreover: In the simple cases, when the title is the same across languages, people can always use Google. And those cases which need translation would need our programmers' time, which is not worth it. — Sebastian 15:46, 12 September 2009 (UTC)

Well, you could go to List of Wikipedias, click on a Wikipedia listed there that is a likely candidate,and find out whether

the article is there (for example, there was an article on Hjalmar Sunden in the Swedish Wikipedia before one in the English Wikipedia). I would not rely too fully on internet translations - I have heard they are not always all that reliable. ACEOREVIVED (talk) 21:14, 12 September 2009 (UTC)

Proposed tweaks to Template:Convert's default precision

See the discussion at Template talk:Convert#Some suggestions for changes to the default precision. --___A. di M. 21:03, 12 September 2009 (UTC)

I think it would make sense to add something about images to the copyright footer, ie change MediaWiki:Copyright. Currently (eg) text is mentioned, but not images/media. It may help image creators with illegal misuse, and point re-users in the right direction.

Wikinews (eg) currently has "Copyright terms on images may vary, please check individual image pages prior to duplication" at the bottom of every page. We could use that, or something like "Check individual image's pages for licensing information".--Commander Keane (talk) 09:39, 13 September 2009 (UTC)

Category counter

Hello, if you're browsing through categories (for example Category:Wikipedia) then you're able to see the number of subcategories in brackets. For example, the subcategory "Websites which use Wikipedia" has two further subcategories. This is useful, however compared to what's possible, it's not really muich. By changing the right system message, we could be able to show the number of content pages, files and categories. This is done on Commons (see commons:Category:Commons), which I find kinda useful. You can directly see for example if there are articles in a category that should only contain further subcategories or catching files in article categories just when browsing. Furthermore, you can see how big the category is before you have to open it. With this code this could also be done here. What do you think? Would it be ok to change this or do you think "No way! We should only show the number of subcategories there!". Please let me know. Thank you. --The Evil IP address (talk) 10:32, 13 September 2009 (UTC)

I'd prefer to show the full information, unless someone's got some good reason why this is not done.--Kotniski (talk) 10:48, 13 September 2009 (UTC)
I've also wondered why it never showed how many articles were in the category you're browsing (Or about to click on to browse). It should show both the number of sub categories, as well as the number of articles. - ʄɭoʏɗiaɲ τ ¢ 15:56, 13 September 2009 (UTC)
I (provisionally) implemented this change. If somebody objects, they can revert. Ruslik_Zero 17:18, 13 September 2009 (UTC)
You mean it was seriously that easy and no one thought to do it before now? Amazing. —Noisalt (talk) 17:51, 13 September 2009 (UTC)

A better way to treat certain redirects

Today I found these two redirect pages redirecting to two DIFFERENT articles:

That should not happen and I fixed it. I've seen this situation maybe a couple of dozen times before—most recently on January 23rd, 2009, when I found these two redirecting to two DIFFERENT articles:

A bot cannot decide what pages things like this ought to redirect to, if any, but I would think a bot could be constructed to

  • find things like this;
  • make a list of them so that Wikipedians can go down the list and find those within their competence and fix them;
  • possibly call them to the attention of the appropriate WikiProjects based on the target articles' category tags.

I know nothing about writing bots. So (1) Can this be done; (2) Should it be done; (3) Are there persons skilled in writing bots whom we should enlist to work on this? Michael Hardy (talk) 22:02, 2 February 2009 (UTC)

And this is even worse: After posting the above, I found that these two went to different targets:
That's the difference between a hyphen and an ndash. Michael Hardy (talk) 22:10, 2 February 2009 (UTC)
This page is actually for discussing the village pump instructions etc, you probably want to post your suggestion at Wikipedia:Village pump (proposals). The suggestion looks like a good idea (generating a list of close matches with different redirects), perhaps you can get someone from Wikipedia:Bot requests to implement it, or contact a bot operator directly - probably someone with toolserver access or a database dump would be best.--Commander Keane (talk) 23:28, 2 February 2009 (UTC)
OK---I actually hadn't noticed that this is the talk page. Michael Hardy (talk) 01:26, 3 February 2009 (UTC)
Note: this thread has been moved from Wikipedia talk:Village pump. ▫ JohnnyMrNinja 18:48, 13 September 2009 (UTC)

Main page sidebar navbox

I've been advised to post this here as I've tried Main Page discussion and Main Page/Errors discussion which apparently was the wrong place. Just a minor thing but could the main page sidebar navbox titles (navigation, search, interaction etc.) start with an upper case letter to match the contents of the boxes? Just looks 'wrong' to me! The simple English version is the same but other language wikis appear correct. Many thanks for your time. Nimbus (Cumulus nimbus floats by) 21:17, 6 August 2009 (UTC)

This page is for discussing the village pump. You want the village pump itself, probably WP:VPR. Algebraist 01:39, 7 August 2009 (UTC)
Thanks, my quest to find the right place to post goes on!! Nimbus (Cumulus nimbus floats by) 08:36, 7 August 2009 (UTC)
Note: this thread has been moved from Wikipedia talk:Village pump. ▫ JohnnyMrNinja 18:48, 13 September 2009 (UTC)

coloring 'legend' with css on 'my preferences' page

sorry. I followed a bookmark to what I thought was 'village pump (technical). wont happen again. Lemmiwinks2 (talk) 19:15, 13 September 2009 (UTC)

PovWatch

I'd like to propose turning on an extension called PovWatch. It allows users to push problematic pages on to the watchlists of other subscribing users. Often I see reports on ANI asking users to watchlist a certain page that is having problems, so I feel that this could really help in certain circumstances, specifically those in which there BLP issues. This functionality is completely optional - you won't be affected by it at all unless you choose to subscribe. — Jake Wartenberg 02:13, 3 September 2009 (UTC)

Query. Based on the linked pages, I'm still not entirely clear about how this works, or how fine-grained the control is. Could someone post (or link to) a more detailed description of this extension? Specific questions I have include:

  • Who will have access to this extension? Will editors with povwatch_user flags set receive the updates to their watchlists, while editors with povwatch_admin set be able to add pages? Who sets/removes povwatch_admin and povwatch_user flags? Will there be a way to exclude users or groups? Who will be able to see what pages are in the log? (Not to open a can of BEANS here, but I can see this as a delightful toy for a troll: "Hey, wanna make a nasty/libellous/obscene/privacy-violating/obnoxious message appear on every admin's watchlist? Just edit any of the pages added to povwatch...".)
  • I get the impression that there's a single category of pages, and you either get all of them or none of them while you're subscribed; is that correct? Is this going to be a useful feature if it pushes to watchlists every controversial BLP, vandalism target, POV-pushing dispute, long-term fringe/pseudoscience battle, etc.
  • Is the purpose of this features supposed to be used 'narrowly' — that is, just for BLPs? If so, do the proposers envision ultimately watchlisting essentially every BLP raised on a noticeboard, or will there be further screening? Will the usefulness of this tool be diluted rapidly once a few high-traffic BLPs make it on to everyone's watchlists? (Once Barack Obama and a few other high-profile names get watched, all the other, minor, third-tier BLPs will get lost in the noise of crowded watchlists. I'm concerned that even though those pages will be watchlisted, they won't actually be watched.)

I may come up with more later, but I'm not convinced at the moment that some of these problems won't cause more harm than good. TenOfAllTrades(talk) 13:35, 3 September 2009 (UTC)

  • Support The example images have sysops putting pages on there, which seems like a good place to start, especially as any page that should be put on PovWatch is at the very least likely have some prior admin involvement or discussion. Any user dumb enough to vandalize on any of those pages will get to watch as they are simultaneously warned and blocked by 200 users and 20 sysops. These would quickly become some of the most-watched pages. I presume it would be used rather narrowly and for limited times - otherwise it would just become pointless. Suddenly everyone finds there is a dispute on a page, and in doing so they work it out, thus leading to the page being removed from the PovWatch list. It would kind of be a neat use of a new notification system. ~ Amory (usertalkcontribs) 14:30, 3 September 2009 (UTC)
Correct me if I am mistaken, but as I understand it there is no way to automatically unwatch pages that were added via the povwatch extension. Each subscriber has to manually remove pages from his watchlist, or it stays forever...? TenOfAllTrades(talk) 14:42, 3 September 2009 (UTC)
Oh, hmm. The way I interpreted it (based on this image) was that it was an all or nothing thing. You manually subscribe or unsubscribe to PovWatch, which puts or removes all those pages on/from your watchlist. You never watch the individual pages, just PovWatch. Kind of like a transclusion. ~ Amory (usertalkcontribs) 14:56, 3 September 2009 (UTC)
That's why we really need someone who knows how the extension works to offer a more detailed explanation before (and if) this goes live. SoWhy's point is also a good one. Through some pretty vigorous trimming, I have about fifteen hundred pages on my watchlist, and I know admins who have several thousand or more. If someone makes an edit without an edit summary (or with an innocuous one) and it pops up on my watchlist, it's not going to ring any warning bells in my mind unless I know that the article is on my watchlist for some important reason. TenOfAllTrades(talk) 15:10, 3 September 2009 (UTC)
I've installed this extension on a test wiki, and I can tell you that there is no way to remove a title once it has been pushed out. I think both the ability to do that and highlight pages watchlisted via the extension on user's watchlists would be huge improvements to the extension. That said, I feel it has plenty of potential as it is, and don't see the lack of these functionalities as major problems. — Jake Wartenberg 01:42, 5 September 2009 (UTC)
Bugzilla request filed. — Jake Wartenberg 22:37, 6 September 2009 (UTC)
  • Rename since this will probably be used for things other than watching for non-NPOV editing. Remember how the abuse filter was renamed "edit filter"? --NE2 03:00, 7 September 2009 (UTC)
  • Support I really like this idea. Ideally it can be expanded to other sorts of tags, such as COI and other warnings of high importance. Basket of Puppies 03:28, 7 September 2009 (UTC)
  • Oppose Comment If I was a nasty, underhanded type of person, I would use this to destroy the watchlists of people I didn't like by trebling or quadrupling their size, filling them with entries (chosen specially to be objectionable to the victims concerned) which my enemies would then have to delete manually. Now forgive me for being a little paranoid but since there are many people out there who actually are nasty and underhanded, I can't support this unless I have an "opt-out" option on my own watchlist to prevent the less pleasant denizens of the Internet messing with it. I am pretty sure that Grawp would love this extension. -- Derek Ross | Talk 04:26, 7 September 2009 (UTC)
Can this thing be in it's own category like another namespace so they can bee seen apart? YellowMonkey (bananabucket) 05:30, 7 September 2009 (UTC)
I am not sure I understand your question. The extension's functionality will be located at Special:PovWatch. — Jake Wartenberg 14:39, 7 September 2009 (UTC)
Opt-in ? I like the sound of that. Okay then, I withdraw my opposition. However I would still note that underhanded people have in the past gained trusted status. So I would still prefer to have "opt-out" which I can apply to my own watchlist. -- Derek Ross | Talk 22:02, 7 September 2009 (UTC)
Unless you subscribe to the extension nobody will be able to change your watchlist. — Jake Wartenberg 00:04, 8 September 2009 (UTC)
Excellent! In that case I have no objection to implementation. -- Derek Ross | Talk 06:13, 8 September 2009 (UTC)
  • Support It sounds like a helpful option. hmwitht 04:59, 7 September 2009 (UTC)
  • Eh I guess I don't see the benefit. I watchlist things because I'm waiting for a change (where I remove the page from my watchlist later), I care about the page content, or I created it (or somehow have it watched automatically). Between those three causes I think I have about 1100 pages watched (with the plurality being user pages). Among the three causes I care the least about articles which become watched through some automated process. Obviously my assertion about the extension isn't enough to stop installation. I can just as easily not participate in the extension after it is installed. but I guess I'm just really fuzzy on the proposed benefit. Protonk (talk) 07:16, 7 September 2009 (UTC)
    That sums up my own POV perfectly (pun completely intentional!)
    V = I * R (talk to Ω) 14:21, 7 September 2009 (UTC)
  • Support GeometryGirl (talk) 22:32, 10 September 2009 (UTC)

Comment Points of View (POV), also known as opinions, are subjective. Are pages going to be watched because people have strong views about the topic on a page? Following that, are opinions going to be policed? On what grounds? What is a "correct" point of view? What is a "correct" opinion? I'm thinking political views, philosophical views, etc. Sounds potentially Orwellian. Please be very careful with this idea - if it went (very) wrong, it could really damage wikipedia.

  • However. What would be good is a way to 'liberate' (with a polite tap on the shoulder) the (probably many) pages that are currently "owned" (and I mean locked-down), in each case, by a single, eccentric and dogmatic person who won't allow "their page" to ever evolve. Those pages are messed up. No need to reply, just adding to the conversation (I hope). JatterDisc (talk) 04:43, 14 September 2009 (UTC)

warning?

I think wikipedia should have a warning at the top of the main page saying that since anyone can edit here, its not a good school resource.Accdude92 (talk) (sign) 13:56, 10 September 2009 (UTC)

See disclaimer at the bottom of every page. ♫ Melodia Chaconne ♫ (talk) 14:11, 10 September 2009 (UTC)
i know, but I think that it should be made clearer.Accdude92 (talk) (sign) 14:25, 10 September 2009 (UTC)
I know where you're coming from, but the fact is, most articles are FINE to use as citations (with exceptions for old-fashioned or close-minded professors), especially because they contain references themselves. More warnings about Wikipedia not being a reliable source would really just make the site look foolish. "WARNING, DON'T BELIEVE ANYTHING YOU READ HERE" ...then what's the point at all? Why not just shut it down? --King Öomie 14:30, 10 September 2009 (UTC)
Also, "WARNING, DON'T BELIEVE ANYTHING YOU READ HERE" is self-referential in a way that's liable to make your head hurt if you think about it too much. :) Rd232 talk 14:40, 10 September 2009 (UTC)
"ONLY BELIEVE THE PREVIOUS WARNING IF YOU FOLLOW THIS INSTRUCTION" --King Öomie 14:45, 10 September 2009 (UTC)
Most articles are fine to use as citations? Eh? Citing Wikipedia is a pretty terrible idea at the college level, and probably not a very good idea in high school either for any sort of serious research writing. I mean, even on Wikipedia we don't consider Wikipedia to be a reliable source. Mr.Z-man 17:40, 10 September 2009 (UTC)
We can't cite Wikipedia in articles because that would cause a circular reference. I could change a page, cite the new information elsewhere, and then cite my addition with the page I just used it as reference. Regardless, the large warning being discussed here would be redundant to the general disclaimer, and if a particular professor refuses to accept papers that use Wikipedia as a reference, he'll put it in the class syllabus. Also, see below. --King Öomie 17:58, 10 September 2009 (UTC)
Its not about what professors will accept. Its just poor research to use tertiary sources, especially ones with no official fact-checking or peer-review, by, effectively, an unknown author as a citation in a serious research work. Mr.Z-man 20:05, 10 September 2009 (UTC)
Unless and until every page on the internet carries such a warning – in boldface, above the title – I'm not sure that we need to be more thorough about this. TenOfAllTrades(talk) 15:01, 10 September 2009 (UTC)

As some one who has marked undergraduate essays which have, at times, cited Wikipedia articles, I normally put a little note saying "Please be aware that Wikipedia is a wiki website - not an exclusively expert-written online encyclopaedia". I am not against my students using Wikipedia as a reference, just so long as they do not use it as their only reference. Yes, it is true that errors get into Wikipedia - but then one could say that many books contain errors - which they do (how many texts on social psychology have given inaccurate information on Kitty Genovese, or failed to point out that a famous study by Daniel Batson and John Darley might have had different findings if analysed by Bayesian statistics? There is a place for disclaimers in Wikipedia,but as Melodia Chaconne pointed above,they already exist. Perhaps the most obvious way in which Wikipedia differs from printed resources is that whereas a printed book is likely to remain a good, poor or mediocre book, the quality of a Wikipedia article may vary over time. This could actually be used to advantage in the school room - for example, a teacher could give a lesson on the pros and cons of Wiki websites. ACEOREVIVED (talk) 22:54, 14 September 2009 (UTC)ACEOREVIVED (talk) 21:32, 14 September 2009 (UTC)

Wikipedia - do we need a disclaimer for external links?

Although the article WP: What Wikipedia is not clarifies how Wikipedia is not a repository of external links, many articles do list external links. The BBC has a website that has, for years now, always stated, near to where it lists external links, that the BBC is not responsible for the content of any external links. Should we introduce a similar disclaimer into Wikipedia, along the lines of "Neither the Wikimedia Foundation nor any of the editors of Wikipedia accept responsbility for the content, presentation or implications of any external links"? ACEOREVIVED (talk) 20:34, 13 September 2009 (UTC)

I've always found those disclaimers moronic. They are links to external websites not controlled by us, under what possible rationale would we be responsible for them? --Cybercobra (talk) 21:49, 13 September 2009 (UTC)
I believe they are for safety in legal issues. warrior4321 21:52, 13 September 2009 (UTC)
Well, the Foundation doesn't seem to have found such a disclaimer necessary yet, otherwise it'd already be present. --Cybercobra (talk) 21:54, 13 September 2009 (UTC)
The General disclaimer already covers that Wikimedia is not responsible for any of the content on Wikipedia, that would presumably extend to links as well. Mr.Z-man 22:11, 13 September 2009 (UTC)
Yeah, anything inappropriate/incorrect/illegal is just as likely to appear here as on an external site. —Noisalt (talk) 22:47, 13 September 2009 (UTC)
As an aside, I would LOVE to see the plaintiff get torn to shreds if a case like that actually went to court. "See how the site that offended you doesn't say 'wikipedia' on top?" --King Öomie 14:12, 14 September 2009 (UTC)

Spanish Wiki features

I've noticed on the Spanish Wikipedia that they have several links to several tools on a page's history page. You can click to get a list of editors, contribution details, search the history, get general statistics on an article, or check the number of visits to a page. Check out this page. The Herramientas are tools (list of editors, contribution details, and history search), the Estadísticas are statistics (general stats and number of visits). We should add this to our pages too. ~~ Dr Dec (Talk) ~~ 18:59, 14 September 2009 (UTC)

Strange, the box those are in doesn't even show up if your language is set to anything other than English... I wouldn't be opposed to using some of those links here. EVula // talk // // 20:20, 14 September 2009 (UTC)
Which of those tools are we actually missing? We currently have links to Contributors, WikiBlame, and stats.
V = I * R (talk to Ω) 20:16, 15 September 2009 (UTC)
But it would be much better if they were integrated into MediaWiki (unlike the Spanish wiki). This would give a nice editing and monitoring framework for the WPedian. Eklipse (talk) 08:09, 16 September 2009 (UTC)
If those links are there, I for one have never noticed them, while the Spanish widget makes them quite clear. --Cybercobra (talk) 08:33, 16 September 2009 (UTC)
Their right at the top of every history page... *confused* Their also just as much "built in" here as they are on the Spanish Wikipedia, their just using plainlinks for external links (which I don't think is a good idea, since those links are actually outside the site, but that's just a style choice). The Spanish Wikipedia is using the exact same tools (their all on Wikimedia's toolserver), they just format the links differently is all.
V = I * R (talk to Ω) 15:11, 16 September 2009 (UTC)
I've just clicked the history tab for this page. There aren't any tools on that page; top or bottom! I know that the tools already exists, but we need to navigate onto another site, choose the tool, type in the page name. If it were integrated like it is on the Spanish Wiki then the info would be one click away. ~~ Dr Dec (Talk) ~~ 22:39, 16 September 2009 (UTC)
History page tools
History page no tools
Are you talking about the tools in the image I just uploaded to the right? Nanonic (talk) 23:18, 16 September 2009 (UTC)
Here's what this page's history looks like to me, with the tools circled. You're looks different? (edit conflict) lol, nanonic beat me too it.
V = I * R (talk to Ω) 23:22, 16 September 2009 (UTC)
Well, this is my screen shot (centre), and there are no tools! ~~ Dr Dec (Talk) ~~ 10:26, 17 September 2009 (UTC)
OK, I cleaned up the images and our discussion a little bit. As for the issue itself, I see that you're using Google Chrome and Vector. Are you using any custom CSS/Javascript? Do the tools show up if you use IE/FF or if you log out and look at a history page? Something in your config is obviously hiding that section.
V = I * R (talk to Ω) 15:05, 17 September 2009 (UTC)
Thanks for cleaning up the pictures. I am using Google Chrome and the Vector Skin along with Wikipedia Beta. I left Beta and changed my skin to monobook and there were still no tools. The same goes for Firefox. I've just logged out and the tools are there. I have a custom JS, but not a custom CSS. The custom JS is empty though. I did have something in there for an online/offline icon but I deleted that a while back. (See here). As for IE and FF, well, I don't know what you mean. ~~ Dr Dec (Talk) ~~ 15:21, 17 September 2009 (UTC) p.s. AH, I see: Internet Explorer and Firefox. Well the tools are there in every web browser; provided I log off and access Wikipedia as an IP address. ~~ Dr Dec (Talk) ~~ 15:25, 17 September 2009 (UTC)
well, I just looked at all of your subpages, and you're right... no custom CSS, and your custom javascript is empty. You could try actually deleting User:Declan Davis/monobook.js, but somehow I doubt that will help. The best idea I can come up with right now is to go into your preferences and start taking off Gadgets, and see if one of them is doing this too you.
V = I * R (talk to Ω) 16:21, 17 September 2009 (UTC)
I've asked a sys-op to delete my monobook.js – after they had deleted my vector.js - and still no difference. The only gadgets I use are Twinkle and Friendly. I turned them both off and still no joy. I have two interface gadgets: adding an edit link to the first section, and changing the UTC time to my local time. I took both of these off and still no joy. I really appreciate your help! If you don't know what else to do then could you formulate a question for the help desk? You seem to know what you're talking about better than I do. ~~ Dr Dec (Talk) ~~ 17:11, 17 September 2009 (UTC)
←I'm stumped, sorry. I'd think that the best thing to do for the Help Desk is to simply point here. A half decent summary would be something like: "toolserver links section on history pages disappeared while logged in", or something like that. Hopefull someone will come along who can help, though.
V = I * R (talk to Ω) 18:41, 17 September 2009 (UTC)
Maybe a note at WP:VPT too as this is a technical matter. – ukexpat (talk) 19:26, 17 September 2009 (UTC)
I've added a post to the help desk, and a post to the Village Pump's technical section. Let's hope someome comes along that knows the answer. Let me thank you all for your help... ~~ Dr Dec (Talk) ~~ 20:18, 17 September 2009 (UTC)

Community service?

What if Wikipedia granted community service time for its editors? Would this promote more editing? Would this promote more unconstructive editing? Would this be possible from a techincal standpoint? How would edits convert to 'time'? Dipotassitrimanganate (talk) 14:39, 17 September 2009 (UTC)?

We can't verify the time required to make an edit, there is no editor in chief who can legally certify the time, there is no proof which human being made an edit, so I don't think it is possible. MBisanz talk 16:23, 17 September 2009 (UTC)
You just put images in my head of Chris Brown being forced to edit articles. I can see the Scouts in my Boy Scout troop asking if editing Wikipedia fulfills the community service requirement for advancement. ---— Gadget850 (Ed) talk 19:27, 17 September 2009 (UTC)
Middle-school kids? Editing Wikipedia without supervision? WHILE BORED?! --King Öomie 20:24, 17 September 2009 (UTC)
My god, this is like saying doing homework for community service. Students write book reports and essays and use bibliographies and footnotes to reference them. Wikipedia is almost the same thing. How can you reward someone with community for doing like homework like editing? warrior4321 21:25, 17 September 2009 (UTC)

A proposed small but helpful design change

This suggestion is for the webmaster, I think. It's not a software bug, however, so I wasn't quite sure where to post it.

I would really appreciate it (and millions of other users, I believe) if you could have the Search field on the main page and subsequent pages configured so that the cursor is automatically active in the Search field when the pages open.

That way, you can start typing in your search term as soon as Wikipedia opens, instead of first having to use your mouse to click in the Search field to place the cursor there before you can type, and then switching back to the keyboard.

There's no other field in which to begin typing text anyway, so it's not like you are actually choosing among various text boxes in which to type. That's no reason to have to click to place / activate the cursor in the Search field each and every time you use Wikipedia.

Thanks very much for all the work you folks do. It's a huge service to people everywhere. —Preceding unsigned comment added by Skipjack MD (talkcontribs)

(moved from WP:VPP [1]) Shereth 22:23, 17 September 2009 (UTC)

  • Hello : This is refreshing as often websites jump to leading edge and you get all kinds of junk- I think pubmed for example went to a tabbed layout and sometimes the cute pix overlap the search box and it takes forever to render on some combinations of windoze os and browsers and it is impossoble anymore on most phones although they do have a text site. The saving grace there is that they have an eutils api facility but that doesn't help much on phones. I would go with the GEICO approach on this and continue to appeal to the primitive cavemen. encyclopedic information is often best conveyed with words and maybe limited pictures, adding extra stuff that may be fine for google earth would probably not add much here. Flash, PDF files, various equivalents ( don't want to pick on adobe as in some cases pdf is great ) would probably not help here and a fancy JS or other gui may produce much less consistent results. I'm not suggesting making a command line API for wiki although that may have some merit or restricting the navigation features but simplicity is nice. As it is, I have a hard time getting the main site to render on a cell phone( I think it leaves off the tabs on the blackberry). While you could have a separate page version for every device and OS it hardly seems helpful given the nature of the site. If anything, make it more primitive so same html runs on phone or desktop. For the particular feature requested by the user you could maybe provide a simple page that does this or just type the url into the address bar ( assumiing your search is an http get using the urlencoded query as some part of query string). Nerdseeksblonde (talk) 00:36, 18 September 2009 (UTC)

Tooltips

I'm sorry that I missed any discussion, but I really don't appreciate the addition of tooltips to my watchlist and history pages. I know what the N, m, and b mean, and there's a key at the top. It is very annoying to have a line below each of them and a question mark and text box show up when I scroll over the letters. Can I please be able to at least disable the tooltips on these pages in my preferences? Thanks, Reywas92Talk 02:30, 17 September 2009 (UTC)

I'm a JavaScript newbie (self-taught due to Wikipedia! :) ), so I'm still working on the exact code you'll need, but I figured out so far that you can use .removeAttribute('title') on the nodes of each of those letter's containers to remove the tooltips. The dotted line below is annoying as well, but CSS can accomplish that, so it's way easier. In the below CSS, I also remove the question mark cursor, which I don't mind but you seem to find annoying:
abbr.newpage, abbr.minor, abbr.bot {border-bottom: none; cursor: auto;}
I hope that helps, and I'll comment again once I've got a complete script for you that will remove the tooltips. I don't guarantee that anything will work in IE, though, so be warned… {{Nihiltres|talk|edits}} 03:04, 17 September 2009 (UTC)
Eh, I just realized that those tooltips appear on every appearance of the minor edit tag, and that I don't quite know enough JavaScript yet to do a proper job of it quickly. Try asking on the technical village pump in the meantime and perhaps someone more familiar with certain JavaScript objects can come up with an implementation. {{Nihiltres|talk|edits}} 03:11, 17 September 2009 (UTC)
What does disabling the tooltip actually affect? You don't see them unless you hover over them. If you don't want to see the tooltip... just don't run your cursor over it. :) Removing the underlines, however... I actually just did that on mine. Bleh, looks ugly. EVula // talk // // 03:40, 17 September 2009 (UTC)
Their annoying, and there's the "don't press that button!" effect. Once you know that tooltips are there, being told to just not look at them is no solution, it's just a lame excuse. Are these particular tooltips actually useful or helpful in any way? What problem do they solve?
V = I * R (talk to Ω) 16:24, 17 September 2009 (UTC)
Take a look at the help desk archives and check the number of times we have been asked what the numbers mean on the history. A legend should appear by default, but should be able to be disabled. ---— Gadget850 (Ed) talk 19:30, 17 September 2009 (UTC)
That's all that's being asked for here, is a way to turn them off. I don't see anyone saying that those tooltips aren't useful at all, it's just that once someone sees these particular tips once it's not as though thay will forget. The whole things should be dismissible right there in the watchlist. This is basic interface usability design stuff we're talking about here, it's not as though these complaints are coming out of the blue. When some (very) established users are complaining it should be obvious that something is off kilter. The underlying idea (helping new users understand the interface) is fine, it's the implementation (using tooltips, and forcing that on everyone) that is problematic.
V = I * R (talk to Ω) 20:06, 17 September 2009 (UTC)
"all that's being asked for here, is a way to turn them off" And that was provided, in the form of the CSS code to add to your monobook.css file. EVula // talk // // 20:15, 17 September 2009 (UTC)
How long have these tooltips been there, anyway? I just noticed the underlining this morning. Seems kind of redundant, there's a legend one line up... --King Öomie 20:26, 17 September 2009 (UTC)
The tooltips were added in the software update that occurred yesterday afternoon.
V = I * R (talk to Ω) 21:56, 17 September 2009 (UTC)
No one one here has provided a way to remove the tooltips, just the underlining and the question mark cursor. There is a post at WP:VPT#Legend discussing removing the legend completely, but I am yet to see a solution to remove the tooltips, as I believe Ohm's Law is specifically trying to disable. —Ost (talk) 20:33, 17 September 2009 (UTC)
And I'm left wondering what the actual problem is. The fact that the tooltips even exist strikes me as an amazingly silly thing to be upset about. EVula // talk // // 02:13, 18 September 2009 (UTC)
I too think that the underlines and the cursor question mark are extremely obtrusive and distracting. I think the title popups are a good compromise between annoying experienced users and helping newbies. I therefore propose to turn off the cursor and underline effect by default but to keep the title. Cacycle (talk) 01:31, 19 September 2009 (UTC)
I find them distracting as well, and redundant. Watchlists are very "busy"-looking pages already. Another minor point: watchlists are HTML-heavy enough, and adding dozens or hundreds of title="This edit was performed by a bot" attributes (the title is repeated at every occurrence of the mark; it's not like a reused variable) makes the page size that much larger. I have at least 200 of these on my watchlist (it's a long watchlist); that's some 8kb of added size, and Firefox says the document size is 139kb, so that's something like a 6% increase in page size. Outriggr (talk) 01:52, 19 September 2009 (UTC)

Idea

Has anyone thought of a possible group that would keep users out of the recent changes list? I know that there are many editors who are squeaky clean in their contributions, and the whole autoreviewer group is there, but why not have a whole autochange group? Kevin Rutherford (talk) 23:14, 19 July 2009 (UTC)

Note: this thread has been moved from Wikipedia talk:Village pump. ▫ JohnnyMrNinja 18:48, 13 September 2009 (UTC)
That would be an excellent idea. support from me if the techs can get it working. Ironholds (talk) 02:09, 16 September 2009 (UTC)
Chilling. Additionally, the recent changes list serves as a reader resource showing what's happening at any given time in terms of content contribution to en-wiki; restricting it would negate its utility. –Whitehorse1 02:41, 16 September 2009 (UTC)
I can't see why many readers would be interested in a scrolling list of edits. Why is it chilling, exactly? Ironholds (talk) 03:04, 16 September 2009 (UTC)
It's called the 'bot' group. –Juliancolton | Talk 02:36, 18 September 2009 (UTC)
In general, I'd oppose. All edits should be up for scrutiny by RC patrollers, else the potential for misuse is too great. ƒ(Δ)² 17:19, 19 September 2009 (UTC)

Microformats in navboxes

Andy has again requested me to make the change detailed in Template_talk:Navbox_Musical_artist#hCard_microformat. Since I'm not satisfied with his claim of consensus, I'm requesting for feedback of the community about the desirability of microformats in navboxes. Does the community see problems or advantages ? Please discuss on the relevant talkpage, so a more thorough consensus can form. —TheDJ (talkcontribs) 13:17, 18 September 2009 (UTC)

What is the hCard/vCard supposed to accomplish in a biography? And why should we make private information (phone numbers/email addresses etc) public? Wouldn't such information also fail WP:INDISCRIMINATE and WP:NOTDIR? And what method is proposed to ensure that the information doesn't go stale (which would happen quickly when artists realize that their private information is now public)? And how do we prevent abuse? (Think: want to terrorize your ex? Post her number in a public toilet)
All in all, this hCard stuff sounds like a really bad idea in an encyclopedia. We already provide a facility to link to artist's website, and that should suffice (and that is where a reader should go for contact info). -- Fullstop (talk) 13:48, 18 September 2009 (UTC)

@Fullstop: You appear to be under some misapprehensions; allow me to reassure you.

  • No vCards will be involved.
  • The hCard microformat adds semantic meaning to text data, by wrapping it in meaningful HTML class names.
  • No addresses or telephone numbers will be published. The hCard mark-up will be used solely to give semantic meaning to names.
  • In this case, specifically, they will specify that the text is either the name of a person, or a group.
  • The relevant existing HTML markup is <table><th>; this change will add two class names, to make that either: <table class="vcard"><th class="fn"> or <table class="vcard"><th class="fn org">. Nothing else will change.
  • Wikipedia already emits hundreds of thousands, probably well over a million, microformats.
  • Microformats are emitted by some of our most-used templates, including {{Coord}}, {{Infobox settlement}}, {{Infobox person}}, and the templates based on them.
  • hCards in particular are already emitted by most infobox templates, about people, places and organisations.
  • Partner organisations such as Google parse our microformats; our use of them has been praised by Yahoo.

I hope that does reassure you; please let me know if you have further questions. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:48, 18 September 2009 (UTC)

A navbox is unlikely to include "information" as an infobox does. The purpose of a navbox is to provide links to related topics, I think adding microformats to navboxes is not really helpful to add semantic data. Locos epraix ~ Beastepraix 19:11, 18 September 2009 (UTC)
Can you provide an example of an instance of this navbox which does not contain any information (bearing in mind that the name of an artist or band is a piece of information; and that a name is the only mandatory property for an hCard microformat)? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:27, 18 September 2009 (UTC)
I wasn't being that literally. Locos epraix ~ Beastepraix 23:58, 19 September 2009 (UTC)

Integrate date maintenance tagging into MediaWiki

No progress is being made with revision pruning meanwhile I'm getting tired of wading through pages of bot edits when studying an articles revision history. At least couldn't SmackBot's date maintenance tagging just be integrated as a feature into the MediaWiki software to do this automatically? What I mean is, any time someone adds a maintenance tag, the MediaWiki software can recognize this and automatically append "|date=CURRENTDATE" to the tag after the page is saved without it being logged in the revision history. Does this sound feasible? -- œ 16:31, 18 September 2009 (UTC)

No only no, but hell no! It's not that I don't agree with the underlying reasoning, but the problem is that doing something like that would create a horrendous software dependency. The effect of this suggestion would be that the type of templates that SmackBot, AWB, and other tools fix would be required, undeletable, unmovable, and even worse that the content of those templates would be unadjustable (the date parameter couldn't be removed or changed in any way).
Actually, I don't think that the underlying reasoning is that much of an issue either... although, it is. It depends on the article, really. I suggested a vandalism flag and the ability to modify the minor edit flag on revisions about a month ago. That sort of change would be the best solution to reducing the signal to noise ratio in revision histories, in my opinion.
V = I * R (talk to Ω) 19:16, 18 September 2009 (UTC)
Hmm ya, the thought just popped up.. I wasn't aware of the technicalities involved. oh well.
There is this things called configuration, this does not have to be hardcoded, it actually could be configured, with a list of all templates that should be checked and the name of the parameter that should be added per template. So that is not an argument. Actually interesting idea, a scripting interface in the code that can do a edit when it detects a pattern (regexp), so basically an addition to the current FILTERs, when filter is triggered, do action on page. Should be very possible to do, but the action now will have much higher impact, so might be questionable from that point. --Stefan talk 02:12, 20 September 2009 (UTC)
  • Those are mostly interwiki bots, why are you singling out poor Smackbot? Wasn't there some discussion a while back about optimizing and centralizing the way we do interwikis? –xenotalk 19:22, 18 September 2009 (UTC)
That was just one idea of how to reduce bot edit clutter.. I just decided to use that link as an example to emphasize the problem.. I think SmackBot's doing a wonderful job. :) I don't recall any discussion about optimizing interwikis..
Hey, hang on a second... isn't there a way to mask minor and bot edits on page histories? You can on watchlists, I don't see those links in the page history linked to above.
V = I * R (talk to Ω) 19:34, 18 September 2009 (UTC)
Ya, that's the problem.. you can't hide bot edits in revision history.. i think it's because of T13181.. apparently edits are only marked as 'bot edits' for 30 days. -- œ 02:17, 19 September 2009 (UTC)

Timelines

Seem like they would be good to use here and there and can be very effective. I think they are included in many encyclopedias if I'm not mistaken. Avoiding original research as far as what to include might be an issue. Have people used them? Are they best separated from articles? Integrated as image like illustrations? Used in section form? Comments, insights, thoughts, vitriol, welcome. Thanks. ChildofMidnight (talk) 00:15, 28 February 2009 (UTC)

Note: this thread has been moved from Wikipedia talk:Village pump. ▫ JohnnyMrNinja 18:48, 13 September 2009 (UTC)
They already exist. See Category:Timelines. --Cybercobra (talk) 21:53, 13 September 2009 (UTC)
I think timelines are a great idea and they do indeed appear in some encyclopedias and almanacs. Best, --A NobodyMy talk 02:16, 21 September 2009 (UTC)

Cite youtube template

moved from Wikipedia:Village pump (policy)#Cite youtube template 18:59, 19 September 2009 (UTC)

Can a "cite youtube" template be created, or would it be considered unnecessary? A number of networks such as Fox Business now have a youtube channel with videos, and the {{cite video}} doesn't seem well suited for citing videos on youtube.Smallman12q (talk) 17:00, 19 September 2009 (UTC)

What's wrong with {{Cite web}}?
V = I * R (talk to Ω) 18:55, 19 September 2009 (UTC)
I don't see the problem with {{cite video}}. For example:
Pershing Joins the Ranks (Documentary). United States Army. Retrieved 2009-03-04.
---— Gadget850 (Ed) talk 19:01, 19 September 2009 (UTC)
Aside from the fact that quite a large proportion of stuff on Youtube is a copyvio and shouldn't be cited anyway, the existing templates seem fine. Stifle (talk) 15:28, 20 September 2009 (UTC)
That's not inherently true, though (the copyvio comment). There are plenty of legitimate, professional sources who are utilizing YouTube now. YouTube is simply a platform, after all.
V = I * R (talk to Ω) 16:50, 20 September 2009 (UTC)
Yes— the film I cited is PD, and a number of companies and organization have official channels. ---— Gadget850 (Ed) talk 19:55, 20 September 2009 (UTC)
While there are some valid reasons to cite youtube videos occasionally, a "cite youtube" template wouldn't really help much, as youtube is only the host, not the author or the publisher. I guess you could save a little space by just having it use the video ID instead of the full URL, but that's about it. Mr.Z-man 17:07, 20 September 2009 (UTC)
It would be nice to have a separate compilation of which youtube videos have been cited.Smallman12q (talk) 18:50, 20 September 2009 (UTC)
See [2]. Wish there was a namespace filter. ---— Gadget850 (Ed) talk 19:55, 20 September 2009 (UTC)
Thanks!Smallman12q (talk) 20:34, 20 September 2009 (UTC)

Articles for Fact Check

Fact checking is one of those jobs that many people are not good at. Articles for Fact Check could be a way for editors dedicated to accuracy fact-check under-sourced articles. An article would be nominated, an editor would fact check and report back their findings. Note that something similar may exist, but I can't find it. Gosox5555 (talk) 20:16, 19 September 2009 (UTC)

Every article could always use fact checking. That's the one of the inherent problems with a site that anyone can edit. The person doing the fact-checking likely has no formal training and has no obligation to do a thorough job. Even if we ignore that, the "fact-checked" status of an article is only good until someone makes another substantial edit to it. Mr.Z-man 21:49, 19 September 2009 (UTC)
The purpose of this would be for articles with few sources, or unreliable (primary) sources. Gosox5555 (talk) 03:36, 20 September 2009 (UTC)
What do you mean by fact checking? If all the facts are true? Let me tell you, every article that isn't FA and possibly GA will have some original research or need "fact checking". More than 3,000,000 articles require "fact checking". hIf an editor wanted to this, fact checking, he/she could press the Random Article in the sidebar on the left, and check the facts for that article. warrior4321 13:07, 20 September 2009 (UTC)
I wouldn't be giving FA or GA articles a pass in the fact checking department. The simple fact is (pun intended), Wikipedia articles are not, and almost by definition cannot be, reliable. Fact checking is an inherent aspect of simply reading an article. If you're relying on a Wikipedia article for anything, then you need to check that the references actually support what they reference. It's just the nature of how Wikipedia operates.
V = I * R (talk to Ω) 16:47, 20 September 2009 (UTC)

Disambiguation

I am an academic and understand the need for formal technical terms. I also understand that the word “disambiguation” has some history in linguistics as a technical term for clearing up ambiguities between similar or identical words. I also understand the need for Wikipedia to follow high standards in presentation and procedure. There is, however, another view. Wikipedia is a kind of “peoples” encyclopaedia and should not use complex terms when adequate and perfectly clear substitutes are available that can be immediately understood by all users - including those that are young or less educated than those familiar with the word “disambiguation”. I am saying it is not a very “user-friendly” word and suggest it be replaced with something like one of the following. “Clarification”, “Different senses” “Different meanings for this entry”. I’m sure there must be a simple word or phrase which does the same job and I would be happy with any of these suggestions. A global replace would then be a relatively simple matter. Granitethighs (talk) 23:44, 8 September 2009 (UTC)

  • I'm very much not an academic, and my reaction to this is... huh? Sure, "disambiguation" isn't a common word, but it's meaning is immediately clear when it's first encountered.
    V = I * R (talk to Ω) 23:57, 8 September 2009 (UTC)
    Why say "obfuscation" when you can say "deceive"? Granitethighs (talk) 00:24, 9 September 2009 (UTC)
    And I would agree with that. However, in this case you're saying "Why say "obfuscation" when you can say... something else. What would be simpler? Do you have any suggestions?" Hey, I'm all for simpler myself, and in most cases I'd likely be on your side. This though... what else would you call a page with makes an ambiguous title not ambiguous? This is what we used to call "Nuking it"; over thinking and over analyzing a common task, process, procedure, etc.. (in this case a word) until it turns into a problem.
    V = I * R (talk to Ω) 00:36, 9 September 2009 (UTC)
    To be a pedantic academic for a moment - I think the use of the word "ambiguous" and hence "disambiguate" here is not the most appropriate word anyway. It is a subtle point but it seems to me that the the words themselves are not ambiguous, they just have different meanings ... the same words with different senses. I suppose what is "ambigious" relates to the particular meaning the enquirer is seeking. Anyway, I gave my suggestions. What is wrong with "Different senses" or “Different meanings for this entry”? If they are regarded as unnecessarily long then "Clarification" would do the trick. Do you have children? If they were using Wikipedia do you think "disambiguation" is the way to point out that the same word or phrase can have different meanings? Granitethighs (talk) 01:16, 9 September 2009 (UTC)
    Not commenting on the merits of this proposal, but WRT children and non-native speakers, we do have Simple English Wikipedia, so we really shouldn't use them as a reason to change the word. Dabomb87 (talk) 03:59, 9 September 2009 (UTC)
    Actually, I remember my first few days on Wikipedia. The first time I saw a disambiguation page, I did not know what was meant by a disambiguation page, until I actually went to more than one disambiguation page. This showed me, that a disambiguation page was merely a index to other pages. It can be confusing to all, and we've all gotten past it smoothly, others will too. It's all part of the learning process, we call life. warrior4321 04:04, 9 September 2009 (UTC)
    (edit conflict) If a user was having trouble understanding the meaning of disambiguation, they Simple English Wikipedia may be better for him or her. However, that Wikipedia even uses the word. I don't think it's an issue. hmwith 04:06, 9 September 2009 (UTC)
    This is like saying "why SMS CU4T when we all understand that it means "See you for tea" - - - learning English is part of the language learning process in life that we must all undergo so just put up with it and write "See you for tea". The point is that it is simpler, easier, and therefore more efficient and appealing to say CU4T (or "Clarification"). Granitethighs 04:15, 9 September 2009 (UTC)
I think I'd encountered the word disambiguation before I went on Wikipedia or else apprehended its meaning from etymology once I had. But that didn't tell me what it was; it just looked like more of that forest of incomprehensible technical jargon best avoided when possible. And knowing an ordinary English meaning of a word can sometimes be positively misleading, as I found out when I learned that "deprecation" didn't just mean what it had meant to me for the previous three or four decades, "deplore" or "disparage". Something like "alternative meanings" or "alternate uses" would be much clearer. And editors should forbear from "dab" as an abbreviation for diambiguation; it's certainly not intuitive. —— Shakescene (talk) 04:55, 9 September 2009 (UTC)

Granitethighs is right, and the existence of Simple English Wikipedia is not a reason to make this one inaccessible. However, I'm not sure about the suggested alternatives. --Apoc2400 (talk) 09:44, 9 September 2009 (UTC)

What I was saying is that they don't even see using the word as a problem there, and that's a simplified version of this Wikipedia. I think most young readers can establish what the word means based on its roots, or at least relate it to ambiguity or ambiguous, and gather the meaning from that with the addition of the prefix. hmwith 13:52, 9 September 2009 (UTC)

"Disambiguate" was once the answer to a question on Wikipedia on University Challenge, so let us leave things as they are! ACEOREVIVED (talk) 23:17, 9 September 2009 (UTC)

Two, four, six, eight! Time to disambiguate! Go-o-o-o-o-o-ohhh, State! —— Shakescene (talk) 03:21, 10 September 2009 (UTC)
Here are some single word alternatives:
I'm sure there are more possibilities. This is just a few minutes of brainstorming. -- SamuelWantman 01:48, 15 September 2009 (UTC)

Likely queries!

Hello! I just thought that maybe a fun section of the project could be for unanswered questions we have concerning topics. For example, we post a question on something we want an answer to as a means of seeing if we have an article on it and if not if we can have an article and then go and write one. Granted many of us just do that anyway (that is how a few articles I created were established), but maybe have a general area for it where we can help each other out and it may be a good way to come up with likely redirect search strings for topics, no? To see what I mean, I am curious on the following:

  • My father claims that a guy came up with some kind of shatter proof window for skyscrapers and tested it himself, only to fall through the window to his death. True or urban legend? Do we have an article on this man and his windows if true? Or is the rumor notable enough to justify an urban legend page on it?
  • I saw on the news a few minutes ago, something about some fetus looking bizarre creature that washed up on shore and reportedly went for children. Is it merely a newsstory and on Wikinews, or something worthy of current events on Wikipedia?

Anyway, just throwing out an idea that could be both fun and informative. Best, --A NobodyMy talk 02:11, 21 September 2009 (UTC)

Not to reply to myself, but regarding the first one, it is apparently true per snopes and yes we do have an article on him at Garry Hoy. So, one down... Sincerely, --A NobodyMy talk 03:14, 21 September 2009 (UTC)
There's a little bit of this going on, mostly for vandalism protection. Whenever Colbert mentions Wikipedia, the topic he's talking about tends to be semi-protected, etc etc. From what I understand, stories like the crazy fetus-fish-monster are Wikinews fodder, as it's unlikely to maintain the lasting notability required for Wikipedia inclusion (since it's almost definitely a hoax, like that beaked monster on the beach a few months back). --King Öomie 14:39, 21 September 2009 (UTC)

Who speaks for you and Wikimedia projects at public events?

On February 7, 2007, a list of people who are willing to speak publicly--to schools, organizations, etc.--about the goals, progress and aspects of Wikimedia projects was created over on Meta at Meta:Public speakers. For those of you unfamiliar with Meta, it exists to coordinate the inter-project activities and discussion of broad Wikimedia initiatives and goals. Suddenly, the list of Meta:Public speakers became controversial after Angela Beesley[3] and Jimmy Wales[4] were removed by a Wikimedia critic for being 'inactive', and then began adding critics of our entire project as public speakers on behalf of Wikimedia. Think having Dick Cheney speak on behalf of the goals and good work of Amnesty International. Surprisingly, for the sake of "openness", it is being argued that people looking for folks in local communities to come talk about what we do, and why, might instead stumble across anyone who is willing to air their grievances and accolades about Wikimedia. The debate has just begun, and more people who are interested in who is out there speaking about the work they do here on Wikipedia should take part Meta:Talk:Public speakers. -->David Shankbone 13:22, 21 September 2009 (UTC)

Disambiguation

I am an academic and understand the need for formal technical terms. I also understand that the word “disambiguation” has some history in linguistics as a technical term for clearing up ambiguities between similar or identical words. I also understand the need for Wikipedia to follow high standards in presentation and procedure. There is, however, another view. Wikipedia is a kind of “peoples” encyclopaedia and should not use complex terms when adequate and perfectly clear substitutes are available that can be immediately understood by all users - including those that are young or less educated than those familiar with the word “disambiguation”. I am saying it is not a very “user-friendly” word and suggest it be replaced with something like one of the following. “Clarification”, “Different senses” “Different meanings for this entry”. I’m sure there must be a simple word or phrase which does the same job and I would be happy with any of these suggestions. A global replace would then be a relatively simple matter. Granitethighs (talk) 23:44, 8 September 2009 (UTC)

  • I'm very much not an academic, and my reaction to this is... huh? Sure, "disambiguation" isn't a common word, but it's meaning is immediately clear when it's first encountered.
    V = I * R (talk to Ω) 23:57, 8 September 2009 (UTC)
    Why say "obfuscation" when you can say "deceive"? Granitethighs (talk) 00:24, 9 September 2009 (UTC)
    And I would agree with that. However, in this case you're saying "Why say "obfuscation" when you can say... something else. What would be simpler? Do you have any suggestions?" Hey, I'm all for simpler myself, and in most cases I'd likely be on your side. This though... what else would you call a page with makes an ambiguous title not ambiguous? This is what we used to call "Nuking it"; over thinking and over analyzing a common task, process, procedure, etc.. (in this case a word) until it turns into a problem.
    V = I * R (talk to Ω) 00:36, 9 September 2009 (UTC)
    To be a pedantic academic for a moment - I think the use of the word "ambiguous" and hence "disambiguate" here is not the most appropriate word anyway. It is a subtle point but it seems to me that the the words themselves are not ambiguous, they just have different meanings ... the same words with different senses. I suppose what is "ambigious" relates to the particular meaning the enquirer is seeking. Anyway, I gave my suggestions. What is wrong with "Different senses" or “Different meanings for this entry”? If they are regarded as unnecessarily long then "Clarification" would do the trick. Do you have children? If they were using Wikipedia do you think "disambiguation" is the way to point out that the same word or phrase can have different meanings? Granitethighs (talk) 01:16, 9 September 2009 (UTC)
    Not commenting on the merits of this proposal, but WRT children and non-native speakers, we do have Simple English Wikipedia, so we really shouldn't use them as a reason to change the word. Dabomb87 (talk) 03:59, 9 September 2009 (UTC)
    Actually, I remember my first few days on Wikipedia. The first time I saw a disambiguation page, I did not know what was meant by a disambiguation page, until I actually went to more than one disambiguation page. This showed me, that a disambiguation page was merely a index to other pages. It can be confusing to all, and we've all gotten past it smoothly, others will too. It's all part of the learning process, we call life. warrior4321 04:04, 9 September 2009 (UTC)
    (edit conflict) If a user was having trouble understanding the meaning of disambiguation, they Simple English Wikipedia may be better for him or her. However, that Wikipedia even uses the word. I don't think it's an issue. hmwith 04:06, 9 September 2009 (UTC)
    This is like saying "why SMS CU4T when we all understand that it means "See you for tea" - - - learning English is part of the language learning process in life that we must all undergo so just put up with it and write "See you for tea". The point is that it is simpler, easier, and therefore more efficient and appealing to say CU4T (or "Clarification"). Granitethighs 04:15, 9 September 2009 (UTC)
I think I'd encountered the word disambiguation before I went on Wikipedia or else apprehended its meaning from etymology once I had. But that didn't tell me what it was; it just looked like more of that forest of incomprehensible technical jargon best avoided when possible. And knowing an ordinary English meaning of a word can sometimes be positively misleading, as I found out when I learned that "deprecation" didn't just mean what it had meant to me for the previous three or four decades, "deplore" or "disparage". Something like "alternative meanings" or "alternate uses" would be much clearer. And editors should forbear from "dab" as an abbreviation for diambiguation; it's certainly not intuitive. —— Shakescene (talk) 04:55, 9 September 2009 (UTC)

Granitethighs is right, and the existence of Simple English Wikipedia is not a reason to make this one inaccessible. However, I'm not sure about the suggested alternatives. --Apoc2400 (talk) 09:44, 9 September 2009 (UTC)

What I was saying is that they don't even see using the word as a problem there, and that's a simplified version of this Wikipedia. I think most young readers can establish what the word means based on its roots, or at least relate it to ambiguity or ambiguous, and gather the meaning from that with the addition of the prefix. hmwith 13:52, 9 September 2009 (UTC)

"Disambiguate" was once the answer to a question on Wikipedia on University Challenge, so let us leave things as they are! ACEOREVIVED (talk) 23:17, 9 September 2009 (UTC)

Two, four, six, eight! Time to disambiguate! Go-o-o-o-o-o-ohhh, State! —— Shakescene (talk) 03:21, 10 September 2009 (UTC)
Here are some single word alternatives:
I'm sure there are more possibilities. This is just a few minutes of brainstorming. -- SamuelWantman 01:48, 15 September 2009 (UTC)

Likely queries!

Hello! I just thought that maybe a fun section of the project could be for unanswered questions we have concerning topics. For example, we post a question on something we want an answer to as a means of seeing if we have an article on it and if not if we can have an article and then go and write one. Granted many of us just do that anyway (that is how a few articles I created were established), but maybe have a general area for it where we can help each other out and it may be a good way to come up with likely redirect search strings for topics, no? To see what I mean, I am curious on the following:

  • My father claims that a guy came up with some kind of shatter proof window for skyscrapers and tested it himself, only to fall through the window to his death. True or urban legend? Do we have an article on this man and his windows if true? Or is the rumor notable enough to justify an urban legend page on it?
  • I saw on the news a few minutes ago, something about some fetus looking bizarre creature that washed up on shore and reportedly went for children. Is it merely a newsstory and on Wikinews, or something worthy of current events on Wikipedia?

Anyway, just throwing out an idea that could be both fun and informative. Best, --A NobodyMy talk 02:11, 21 September 2009 (UTC)

Not to reply to myself, but regarding the first one, it is apparently true per snopes and yes we do have an article on him at Garry Hoy. So, one down... Sincerely, --A NobodyMy talk 03:14, 21 September 2009 (UTC)
There's a little bit of this going on, mostly for vandalism protection. Whenever Colbert mentions Wikipedia, the topic he's talking about tends to be semi-protected, etc etc. From what I understand, stories like the crazy fetus-fish-monster are Wikinews fodder, as it's unlikely to maintain the lasting notability required for Wikipedia inclusion (since it's almost definitely a hoax, like that beaked monster on the beach a few months back). --King Öomie 14:39, 21 September 2009 (UTC)

Who speaks for you and Wikimedia projects at public events?

On February 7, 2007, a list of people who are willing to speak publicly--to schools, organizations, etc.--about the goals, progress and aspects of Wikimedia projects was created over on Meta at Meta:Public speakers. For those of you unfamiliar with Meta, it exists to coordinate the inter-project activities and discussion of broad Wikimedia initiatives and goals. Suddenly, the list of Meta:Public speakers became controversial after Angela Beesley[5] and Jimmy Wales[6] were removed by a Wikimedia critic for being 'inactive', and then began adding critics of our entire project as public speakers on behalf of Wikimedia. Think having Dick Cheney speak on behalf of the goals and good work of Amnesty International. Surprisingly, for the sake of "openness", it is being argued that people looking for folks in local communities to come talk about what we do, and why, might instead stumble across anyone who is willing to air their grievances and accolades about Wikimedia. The debate has just begun, and more people who are interested in who is out there speaking about the work they do here on Wikipedia should take part Meta:Talk:Public speakers. -->David Shankbone 13:22, 21 September 2009 (UTC)

Project Idea

We have featured pictures, articles, and portals. Why not have a featured project? Kevin Rutherford (talk) 01:28, 22 February 2009 (UTC)

Note: this thread has been moved from Wikipedia talk:Village pump. ▫ JohnnyMrNinja 18:48, 13 September 2009 (UTC)
Interesting idea, but how would that be different from a featured portal? I see portals as the reflection of work carried out by a Wikiproject, although others might disagree with me. Clarify, please? Thanks! Hardtofindaname 07:17, 15 September 2009 (UTC)
There are featured projects in the Signpost: Wikipedia:Wikipedia Signpost/2009-09-14/WikiProject report for example. 99.166.95.142 (talk) 16:45, 21 September 2009 (UTC)

Rename Templates for deletion to Templates for discussion

There has been unanimous support for renaming Wikipedia:Templates for deletion as "Templates for discussion", to hopefully take some of the heat out of discussions there. How should this be done? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 09:34, 16 September 2009 (UTC)

Presumably a combination of clicking "move" and "edit this page". OrangeDog (talk • edits) 09:39, 16 September 2009 (UTC)
If only; but no. There are a number of sub-pages, templates which refer to or affect that page; and bots which act upon it. A simple move may break any or all of them Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 09:56, 16 September 2009 (UTC)
At least one subpage for every day since April 1st, 2006, plus one for every TFD post, ever. --King Öomie 17:40, 16 September 2009 (UTC)
I think that the first step would be to start a conversation with User talk:Schutz, who operates Zorglbot. I'm fairly certain that he could add a task to either fix links or move all of the sub-pages. There are a lot of them, but their isn't an infinite number, so this is a perfect bot task (I'd gladly run it on my own bot if it was ready to go). User:JPG-GR seems to be someone who should be brought into these discussions, as well.
V = I * R (talk to Ω) 17:47, 16 September 2009 (UTC)
There's also the issue Andy brought up about the multitude of bots that patrol that page. An infrastructure has built around that and AFD over the last five years; moving the foundation is going to be a haul. --King Öomie 17:49, 16 September 2009 (UTC)
A redirect should take care of the immediate problem for most bots and users (and any bot that is hard-coded with the page name ought to break regardless).
V = I * R (talk to Ω) 17:53, 16 September 2009 (UTC)
Well, I just meant that the operators should be found and notified that they need to update their bots, or at least prepare them for the eventuality. A page move might rename TFD itself, but individual posts will still retain the 'Deletion' name, and any new posts created through Twinkle (and similar tools) will as well. I'd still recommend a wholesale move of every page (obviously through a bot). There's probably 4,000 pages. --King Öomie 18:04, 16 September 2009 (UTC)
I'd be inclined to leave the old pages where they are, and start again, with a suitable note to that effect. Otherwise, past discussion might look odd. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:03, 17 September 2009 (UTC)
That's not a bad idea at all.
V = I * R (talk to Ω) 20:08, 17 September 2009 (UTC)
Certainly sounds like it would reduce the amount of work involved! --RL0919 (talk) 20:17, 21 September 2009 (UTC)
Moved from Talk:Wikipedia

I feel we should add links of websites that we come across during everyday net surfing. I feel that Metallurgy field is most devoid of links to websites, but actually most of the educational articles on wikipedia have an extremely small number of links. So i think that we should add a link to a relevant wikipedia article whenever we come across a nice website, during our everyday net surfing.

cheers! —Preceding unsigned comment added by 202.3.77.11 (talkcontribs)

"It is not Wikipedia's purpose to include a comprehensive list of external links related to each topic." Wikipedia is "not a directory". Links are only appropriate when used as sources or when usable as sources. -- Fullstop (talk) 13:57, 18 September 2009 (UTC)
Ideally, there should normally be 0 external links in any article. Everything pertinent to the topic ought to be in the article.
V = I * R (talk to Ω) 15:52, 18 September 2009 (UTC)
Uh, no. Just....no. Also, no. Did I mention, no? ♫ Melodia Chaconne ♫ (talk) 16:11, 18 September 2009 (UTC)
The real problem is almost always too many links. 0 sounds a good number, 6 is too many (and I think that most/all relevant external links can be added into articles). Dougweller (talk) 16:43, 18 September 2009 (UTC)
I don't think giving a flat "x is too many" is EVER a good idea. Would you only have five ELs at World War II? How about Franz Schubert (which probably has too many, but certainly at least six of them are perfectly fine)? ♫ Melodia Chaconne ♫ (talk) 18:12, 18 September 2009 (UTC)
How would you add all of the external links on Origin of the Species into the article? Are you saying it's not useful to link to the full text? --Cameron Scott (talk) 17:04, 18 September 2009 (UTC)
What? 0 is a horrible number. EVula // talk // // 17:11, 18 September 2009 (UTC)
I did say "ideally". Achieving an ideal is rarely, if ever, practical. The vast majority of EL's in Wikipedia are completely superfluous, is the real point, and 0 external links is not at all a "horrible" ideal. Of course, naming an actual upper limit is bad as well, but that's a different subject.
V = I * R (talk to Ω) 18:36, 18 September 2009 (UTC)
I think there will always be things that are outside Wikipedia's scope, but still educational to link to. There are a lot of great science websites out there. I wish we could link to them when relevant without allowing lots of crap links in. --Apoc2400 (talk) 18:56, 18 September 2009 (UTC)
I support your view Apoc because if you really look at technological and scientific articles, then you will find that almost all of them especially, the technological articles suffer from Content Drought too. So if no one has enough time to put enough work in them as technological articles in my opinion require a lot of hard work and lot of reading to make an article knowledgable and yet lucid, so no one has found the time to enrich the wikipedia articles, but i feel that most people do find many useful and knowlegde giving fantastic websites. It is true that most portions of these websites can be junk or useless but some portions of them is really fantastic. For example the Bayer Science Website doesnt looks very useful to me for reading about technological things (at least its not very easy to find good stuff there) but i found a very lucid explanation of figures depicting Engineering Draft and i used that link for the Engineering Draft stub at [7],So my point is that when no one has enough time to write good technological articles in wikipedia, so cant we just add links to the stubs, so that someone can get all the vital information about a topic through wikipedia itself even if it is actually not on wikipedia. Afterall wikipedia's goal is to bring knowledge to a person and not to exert its supermacy and thus not providing any external links even if its articles are not good at all on tht topic.
cheers!
Cumbersomeness of having too many links attatched to a stub or even "full fledged featured article" can be avoided by attatching suitable taglines to the links. this is easy and makes the reader decide what links to click onto.
Please people, dont just take into account some few special cases. Think about the whole bunch of technological articles and scientific articles too. Because whenever i have learnt something worthwhile from a wikipedia article, it was mostly when i read the wikipedia article and also followed some of the nice links provided in those articles. It was a very satisfying experience.
cheers!— Preceding unsigned comment added by 210.212.55.3 (talk) 06:29, September 18, 2009 (UTC)
Uh, isn't that what we are encouraged to do now? Yes, Wikipedia is not a directory to the Internet, but if I find a link to a resource worth adding to Wikipedia & don't have the time to properly digest & integrate it into an article, I'll add it at the bottom as an "External link" or "Further reading". I know I'm not the only one who does this. (The problem is when someone indiscriminately adds links to articles of website which are not helpful; in those cases, the links are pruned by folks who are disappointed at this abuse -- like me.) -- llywrch (talk) 22:14, 21 September 2009 (UTC)
actually the aim here is to somehow spread the word through word of mouth to those people who create or enrich technological articles that since technological information is sometimes hard to digest for adding it to an existing wikipedia article, so they can conveniently leave suitable links in that article so that a reader can still have access to knowledge.
cheers!— Preceding unsigned comment added by 210.212.55.3 (talk) 03:58, September 24, 2009 (UTC)

NOTE: I don't really have the will to pursue this proposal (although I think it would be a positive feature for Wikipedia). Anyone is welcome to take up this proposal if they feel they can make something useful of it. GeometryGirl (talk) 23:55, 16 September 2009 (UTC)

Description

What?

Wikipedia currently uses two colours for links, namely blue for existent articles and red for nonexistent articles. This proposal suggests using yet a different colour for stubs. The goal is to engage readers in article contribution, specifically stub expansion.

Why?

Micro-opportunities for user participation currently exist, such as red links, that stimulate article creation. However, red links have become rare and the focus is nowadays on expansion and improvement, rather than creation. With most links blue, an impression of completion transpires, and not much enticement to participate is provided. This proposal attempts to address both the deceptive appearances and the lack of enticement.

Why stubs?

Because stub pages not are appropriate for an encyclopedia: "A stub is an article that is too short to contain suitably encyclopedic material". Also, in many ways, stubs are much easier to improve than developed articles.

How?

Using scripts similar to this one and this one.

For who?

Non logged-in readers will not be affected, to avoid confusion. This will be an opt-in option (i.e. not enabled by default) for registered users, advertised via a sitenotice or a watchlist notice.

Which colour?

The choice of colour will be left to the discretion of each user, according to preference and sight (e.g. colourblindness).

Which Wikipedia?

This proposal is first intended to the English Wikipedia, but other Wikipedias may be interested in a similar functionality.
Past experiences

User:Charles Edward

"I have a script like the ones mentioned above for some time and find it very helpful. Anything that encourage a growth in quality is good in my book."

User:Floydian

"Having coded my own version of this into my monobook theme, I have noticed how much of an effect the orange links have on me. They immediately stand out above things and they make me want them to be blue."
Potential problems

Stub articles are not necessarily articles that people want to edit.

The extra colour merely suggests stub editing, like red links suggest article creation.

This proposal assumes that stubs are Wikipedia's worst articles.

The extra colour focuses on undeveloped articles, no assumption of quality is made.

This adds complexity to the linking system and will cause confusion.

Only logged-in users will be affected to limit confusion, and registered users can decide not to use an extra colour.

Some undeveloped articles have no rating.

Links to these articles we be blue until appropriate rating is done.

There are potential performance problems.

No programmer has expressed his/her concern as of yet.

A different colour for stubs might prove obnoxious for some readers.

Each registered user will decide if he/she wishes a new colour for stubs.

The colourblind may not distinguish the different colours.

Each registered user will be able to decide the colour he/she wishes to use.

Discussion (new colour for stubs)

Past discussion (agreeing on the details)

Don't bite too hard. :) GeometryGirl (talk) 11:59, 9 September 2009 (UTC)

  • I admire your dedication, but I'm still not convinced that the basic underlying idea is a good thing here. What exactly is a stub article? Those articles that are less then X bytes? Articles with a {{stub}} templates on them? Without addressing the fundamental question of how to unambiguously determine the state of all articles I'm unwilling to support any of these proposals. I personally am ready and willing to discuss the addition of some sort of added "quality field", "assessment property", or some other such thing to articles, but unless and until that it implemented all of these proposals are premature.
    V = I * R (talk to Ω) 12:43, 9 September 2009 (UTC)
    Ok, let discuss this! What do you propose? GeometryGirl (talk) 12:58, 9 September 2009 (UTC)
    I tried to in the first proposal, but the bulk of that seems to have been overlooked. Before any of these can be implemented, something needs to be added to the software itself so that internal links can be given CSS classes based on article quality. Using the category system is a bad idea for two reasons:
    1. Categories are not required to be used on articles at all, which is important because we're talking about replying on some property to determine how pages are rendered. If there isn't a specific property for the software to rely on, then these proposals are pretty much dead in the water from a programming perspective.
    2. Categories are not intended to be used in this matter. They currently are, but that could be changed at any time, and then where would that leave this system (assuming that it was somehow implemented)? Assessments can currently utilize the category system because nothing in software is currently reliant on article assessment, but if that changed then something would specifically need to be done to prevent the categories from ever changing.
    Stubness suffers from the exact same issues here. This doesn't even address the concerns with the current quality assessment systems in use here on the English Wikipedia, which I think are fairly significant. The fact is that some significant groundwork is required before even considering these specific proposals.
    V = I * R (talk to Ω) 13:20, 9 September 2009 (UTC)

For who: "All readers by default." Why on earth? People have heard tales of Wikipedia's upcoming "orange text" system, adding orange links at this time would confuse readers to an INCREDIBLE degree. Leave it as a gadget, if anything (I'd certainly use it), or even a custom userscript. --King Öomie 12:48, 9 September 2009 (UTC)

I haven't heard of "tales of Wikipedia's upcoming "orange text" system". And saying that "orange links at this time would confuse readers to an INCREDIBLE degree" is highly speculative. GeometryGirl (talk) 12:58, 9 September 2009 (UTC)
Not so much. [8][9][10][11][12][13][14][15][16][17] --King Öomie 13:25, 9 September 2009 (UTC)
Ah, I see. You're mistakenly conflating these proposals with Wikitrust. Wikitrust is a completely separate issue.
V = I * R (talk to Ω) 13:57, 9 September 2009 (UTC)
I'm not making the error. I'm saying rolling out orange links after a slew of news about orange text will confuse others. --King Öomie 14:01, 9 September 2009 (UTC)
Oh, I get it... well, even if this were to suddenly gain tons of traction and everyone was onboard with implementing it, it would likely be months before an actual implementation went live on Wikipedia. By then I doubt that confusion with Wikitrust would be an issue. Or... it could still be an issue, I suppose. Regardless, the actual color used would be the last thing to consider, so specifically using orange is just a minor detail.
V = I * R (talk to Ω) 14:05, 9 September 2009 (UTC)
  • I think this is a marvelous idea and wholheartedly support it. I have a script like the ones mentioned above for some time and find it very helpful. Anything that encourage a growth in quality is good in my book. —Charles Edward (Talk | Contribs) 16:10, 9 September 2009 (UTC)
Thank you for your support Charles Edward. Since you have experienced using such a script, can you give us feedback as to what are the advantages, and what are the possible drawbacks? GeometryGirl (talk) 16:35, 9 September 2009 (UTC)
Discussion settled: By default or not by default?
  • There is some utility to this suggestion (I currently am trying it out through a little CSS hack and a preferences change). It certainly is interesting to those who have an interest in developing stubs. That said, I don't think the color change is useful enough to the general population to enable this as for all readers by default. Perhaps as a gadget, this would be nice. Shereth 17:41, 9 September 2009 (UTC)
Great. Please tell us when you are done with your hacking. GeometryGirl (talk) 17:59, 9 September 2009 (UTC)
There isn't much to add, really. There are some editors who enjoy expanding stubs, and to offer this as an option to these editors makes sense (ideally with the option to pick a color of their choosing). However, to those editors who are not generally interested in expanding stubs, the addition of another color of links could prove obnoxious. This is not something that should be enabled by default, but rather an option for interested editors. Shereth 21:17, 10 September 2009 (UTC)
I understand your concerns Shereth. May I point out however that red links have been successful precisely because they where obnoxious/annoying. Editors will want to "change links to blue". GeometryGirl (talk) 21:39, 10 September 2009 (UTC)
Some undoubtedly will; some undoubtedly will just be frustrated at multiple colors. Red links also serve to let people know that a link does not exist and that clicking on it would not result in seeing any information. Leaving links to non-existent articles undifferentiated would be disingenuous. Blue implies something exists, red implies it does not, and this is a wholly objective difference. The addition of any other colored links will result in necessarily subjective and/or arbitrary differences. Like I've said, this is a useful suggestion for those interested but it should be optional, not standard behavior. Shereth 21:44, 10 September 2009 (UTC)
If we make it a gadget then I fear this would not at all have the same impact. There is an interesting question raised here: Are the potentially massive benefits of this proposal more, or less, important than the potential frustration for some? I don't have an answer... GeometryGirl (talk) 21:51, 10 September 2009 (UTC)
I believe you are overstating the "potentially massive benefits" of this proposal. I also believe that intentionally "annoying" users as a means to an end is a wrongheaded approach to a problem. However as these are inherently subjective questions and points, and there is no objective "right or wrong" answer, it appears we are going to just have to agree to disagree, as it is apparent we have different views on the matter and we don't seem to be swaying one another. So I'll just reiterate my stance and leave the community to further discuss this issue : I think this is a fine idea for a gadget but should not be enabled by default. Shereth 21:57, 10 September 2009 (UTC)
Exactly, may the community decide. But what about an option for frustrated editors to disable the new colour? That would solve the problem, no? GeometryGirl (talk) 22:03, 10 September 2009 (UTC)
Not entirely. I am of the opinion that such a thing should be opt-in, not opt-out. Shereth 22:06, 10 September 2009 (UTC)
What about this: If and when this is implemented, for every account have a message basically saying "Coloured links for stubs is new. Do you want to enable them? YES PLEASE/NO THANK YOU". GeometryGirl (talk) 22:14, 10 September 2009 (UTC)
Something to that effect would be perfectly acceptable. Shereth 22:44, 10 September 2009 (UTC)
Awesomeness! Consensus is in fact possible. GeometryGirl (talk) 22:49, 10 September 2009 (UTC)

I support this. It encourages participation, which wikipedia certainly could use more of. I don't think orange is the right colour, but that is a later issue. Having coded my own version of this into my monobook theme, I have noticed how much of an effect the orange links have on me. They immediately stand out above things and they make me want them to be blue. I think this is useful for all signed up editors, but not for visitors, who may be unaware of the system in place. - ʄɭoʏɗiaɲ τ ¢ 18:23, 10 September 2009 (UTC)

That's great. I agree with you that orange is not the best colour and that this should probably only be for signed up editors to avoid too much confusion. What do you think of purple? I can't find any appropriate colour at HTML color names. It is a shame that green gives out the wrong impression. GeometryGirl (talk) 20:02, 10 September 2009 (UTC)
That purple is too similar to links you've already clicked on in many browsers, but another may work. I'd suggest a vibrant shade of blue (Perhaps an electric blue), or a mix between blue and green (Perhaps turquoise) that wouldn't cause a color-blind issues (Though in all reality, any color is going to be hard to see by a certain small percentage of the population who can't distinguish colours well). Another option could be bolding the text. I like the orange the best myself, but I just think it may cause confusion with others. - ʄɭoʏɗiaɲ τ ¢ 21:19, 10 September 2009 (UTC)
Orange is also my personal best. I think I have found a solution: let each user decide for themselves. GeometryGirl (talk) 23:15, 10 September 2009 (UTC)
  • Comment As I have my own css preferred link colours set, I am not sure how this would work for me. Would it interfere, against my will, with my colour preferences? (I haven't read all the stuff in the box above - too detailed and strenuous a read.) Can't anyone who wants to expand stubs just look under the thousands of stubs? Plus, the designation "stub" variies from full articles to one sentence pages. Xme (talk) 00:07, 11 September 2009 (UTC)
This is not a default option, just an opt-in option for interested users. Users who already have a preferred link colours set will not need such a feature. GeometryGirl (talk) 12:36, 11 September 2009 (UTC)
  • Question Maybe I'm missing something here, but this is already implemented, at least in the monobook skin. Go to 'My preferences', click on the 'Appearance' tab, and scroll down to 'Advanced options'. There you should see a box labelled 'Threshold for stub link formatting', where you can set the threshold in bytes for what you consider a stub. Such links will then appear in a slightly darker red than a normal red link. The actual colour is defined for the class a.stub in http://en.wikipedia.org/skins-1.5/monobook/main.css. Individual users could of course override this colour in their own monobook.css. Dr pda (talk) 02:09, 11 September 2009 (UTC)
The state of being a stub is not measured in bites. Rather, it is measured in encyclopedic content. GeometryGirl (talk) 14:44, 11 September 2009 (UTC)
  • Stubs I wanted to add a comment here about something said at User talk:Cacycle#coloured links for stubs. The quote from there is "4) Stub pages not are appropriate for an encyclopedia: "A stub is an article that is too short to contain suitably encyclopedic material".". I understand that there is probably a policy or guideline page that says that somewhere, but the fact is that it's simply not true. There are many "stubs" that do need to be expanded, but there is also a significant portion of them that really should not. I know that I'm far form the only one to have that view as well, so I'm fairly comfortable in saying it.
    V = I R (talk to Ω) 12:50, 11 September 2009 (UTC)
Thank you for raising the point. Do you have specific examples of stubs "that really should not [be expanded]"? GeometryGirl (talk) 14:40, 11 September 2009 (UTC)
After a little poking around: Fastflow. Subject has very little coverage. --King Öomie 14:47, 11 September 2009 (UTC)
A article with no sources surely should be expanded. There exist small and developed articles... The smallest featured article is not much longer than Fastflow. GeometryGirl (talk) 14:54, 11 September 2009 (UTC)
You said "expanded", not "Improved". The Fastflow article doesn't need to be longer is my point. --King Öomie 15:01, 11 September 2009 (UTC)
This is just a wording issue. There is "lengh (prose) expansion" and "sources expansion". Both are expansion. Improvement is done on something already existing. I can improve the existing prose, but I certainly can't improve the current sources, since there are none! :) GeometryGirl (talk) 15:08, 11 September 2009 (UTC)
Just as a point of information, in my experience, an article like Fastflow, with so many sentences clamoring for elaboration, could easily be doubled in size once sources are provided to support the claims made. Geometry guy 21:39, 11 September 2009 (UTC)
The other aspect of this is that I'm addressing the idea that was brought up, which is why I haven't and will not provide specific examples. As a concept, the idea that stub must be expanded is simply wrong. They are definitely good candidates, as a class of articles, for expansion (statistically, you're much more likely to find an article needing expansion by looking at stub articles).
V = I * R (talk to Ω) 15:12, 11 September 2009 (UTC)

You know that this already exists, right? Look at "stub threshold" in preferences. — Werdna • talk 13:12, 14 September 2009 (UTC)

That is not the same... be careful! A stub is not defined relative to its size, but to its encyclopedic content. GeometryGirl (talk) 23:50, 16 September 2009 (UTC)

Poll

Support

  • Support as nominator. GeometryGirl (talk) 23:12, 10 September 2009 (UTC)
  • Support This would be great. Encouraging stub expansion is something I've seen for the first time, and it makes well enough sense. warrior4321 23:38, 10 September 2009 (UTC)
  • Support only because of: "Registered users will the prompted to use a new colour". You can do what you like, and you can even advertise for it in a limited fashion and I wouldn't mind in the least. When you cross over into actively pushing me to adopt something that I'm not looking for myself, then I'm very likely to just tell you to hush and ignore whatever you're saying. Aside from that, the post above applies to myself as well. I have custom colors, and I would appreciate it if everyone else were able to respect my personal choices.
    V = I * R (talk to Ω) 00:18, 11 September 2009 (UTC)
    There is no question of enabling this by default. We shall advertise it via a sitenotice or a watchlist notice. (See Shereth's comment below.) I have rephrased the proposal to remove any confusion. GeometryGirl (talk) 12:30, 11 September 2009 (UTC)
    OK, changed to support, as long as it's understood that this is a gadget, and not a proposal to change the MediaWiki software. (I likely won't use it, but I'm certainly not going to stand in the way). Thanks.
    V = I * R (talk to Ω) 12:41, 11 September 2009 (UTC)
  • Support per my above comments. In response to Ohms plight, perhaps it could be enabled by default, but can be disabled in preferences. Current users would default off and have to enable it themselves, only new users would have it checked by default. - ʄɭoʏɗiaɲ τ ¢ 02:24, 11 September 2009 (UTC)
  • As I indicated previously, I am okay with the creation of a gadget of some kind that people can use to provide this kind of functionality. I am also okay with advertising it via a sitenotice or a watchlist notice, or the like. So long as it is opt-in and not opt-out (enabled by default) I am okay with it. Shereth 05:16, 11 September 2009 (UTC)
To clear up any confusion, this is opt-in, not opt-out. Thank you for your support. GeometryGirl (talk) 12:18, 11 September 2009 (UTC)

Oppose

  • Strong oppose. (1) This would be a usability nightmare. (2) It is technically not possible at the moment and it is completely unlikely to be implemented anytime soon. One reason for this is the enormous resource intensity to make it happen: the articles for every single link on a page would have to be retrieved and searched for a certain string for every page call. (3) The proposal conceptually mingles English-Wikipedia specific content with a function of the underlying general software. (4) We do not necessarily want stubs to become expanded, especially by people not qualified to do this, and, (5) more importantly, nobody will go and expand stubs just because their link is displayed in a different color. (6) Other triggers for a new link color would be much more useful, such as disambiguation pages[1]. (7) It is out of the question to make this the default behavior. (8) Whoever wants the functionality anyway, can already use a user script such as User:Anomie/linkclassifier.js. Cacycle (talk) 03:09, 11 September 2009 (UTC)
Replied on User:Cacycle's talk page. GeometryGirl (talk) 12:19, 11 September 2009 (UTC)
Thanks for having now clarified your proposal into a real opt-in option. But if all this fuzz is only about having a new gadget then I see no reason to vote for it here. Ask somebody to adapt an existing script and go through the approval process on Wikipedia:Gadget/proposals. Cacycle (talk) 12:49, 11 September 2009 (UTC)
It is easy to say "ask somebody to write code". Who is that somebody? Also, we need consensus that this is a worthy enough cause to have a sitewide notice. (May I also ask you to remove your "strong oppose"?) GeometryGirl (talk) 14:31, 11 September 2009 (UTC)
It has to be written before a notice can go out. Poke around WP:RQ. --King Öomie 14:38, 11 September 2009 (UTC)
The code is already there, only the category/template names need to be adjusted to stub categories/templates. User:Anomie/linkclassifier.js uses a relatively fast and resource friendly api call that (afaics) does not require full text analysis server-side. Cacycle (talk) 23:32, 11 September 2009 (UTC)
  • Oppose - 1) I don't think this is important enough for a sitewide notice. 2) If we're going to encourage as many users as possible to use this, we should be promoting the already existing "stub threshold" user preference rather than creating inefficient scripts. Mr.Z-man 17:04, 11 September 2009 (UTC)
This could be adapted from that easily by adding a colour choice to it. - ʄɭoʏɗiaɲ τ ¢ 17:16, 11 September 2009 (UTC)
I'm not entirely sure what you mean, "this," "that," and "it" in you statement are rather vague. Mr.Z-man 17:25, 11 September 2009 (UTC)
Haha, my bad. This idea could be adapted to the stub threshold preference by adding the ability to choose which colour you use instead of the default maroonish colour. Many people, myself included, have modified our theme.css to make it a different colour. - ʄɭoʏɗiaɲ τ ¢ 20:35, 11 September 2009 (UTC)
It could be, yes, but we've apparently moved from discussion to voting, and it wouldn't really be proper to change the proposal after several people have already voted. Mr.Z-man 21:11, 11 September 2009 (UTC)
  • Not with the current stub system. Currently, we have tons of stubs that are just marked as stubs because they are small. I just opened a random article: Octávio Machado. While that article could be improved, I don't see that it needs particularly more attention than any other random article. — Sebastian 15:57, 12 September 2009 (UTC)

Other

  • Indifferent as to gadget status, which is neither here nor there; Strong oppose to any mention of this being default or opt-out. (Moved, direct response to Charles Edward) --King Öomie 14:31, 11 September 2009 (UTC)
  • As above don't mind or care if it is just an optional opt-in gadget but absolutely opposed to this being a default setting for anyone and/or anyone having to opt-out to stop seeing it. Wikipedia is here for the readers first and foremost and anything that makes the experience worse for them (as I think this will by making article links more obtrusive - 3 different colours in an article is not a benefit for readers). It would also discourage people from linking to stubs (featured articles already have a de-facto no redlink policy and stub links would I'm sure be discouraged if they were a different colour). Davewild (talk) 16:27, 11 September 2009 (UTC) p.s. if the views of those in support who want this an opt-out device pervail then consider this a strong oppose. Davewild (talk) 16:29, 11 September 2009 (UTC)
"FA have already have a de-facto no redlink policy" Check out recently passed Chinese classifier. (I know of this one because I contributed a bit.) GeometryGirl (talk) 16:44, 11 September 2009 (UTC)
True but I notice the relinks did get a comment on the discussion on promoting the article to FA status and had to be defended there. I could change my statement to "relinks are viewed negatively at FA". Davewild (talk) 16:50, 11 September 2009 (UTC)
Redlinks are not disallowed in FAs (one of several misconceptions about FA and related processes), although I do agree that reviewers often like to see red links blued where possible. Dabomb87 (talk) 21:12, 11 September 2009 (UTC)
  • I honestly don't care if this is a gadget (or just a user-script), but it'd be nice if the same proposals weren't rehashed day after day after day. If I see one more blasted thread about changing link colors, I'm going to scream. EVula // talk // // 19:38, 11 September 2009 (UTC)

Current weather

I came across mw:Extension:AccuWeather a few months ago, and thought it was a neat feature. Then, after thinking about it this evening, I decided it would be an excellent idea to implement something similar that would be put into place on city articles, specifically in {{Infobox settlement}}, that would display the current temperature at a given city in both Fahrenheit and Celsius. At first this seemed like a bit of a crazy idea, but it seems like it would be a rather minor, albeit useful, addition. Additionally I expect this will be technically feasible. Any thoughts? –Juliancolton | Talk 02:51, 12 September 2009 (UTC)

Support I like this idea a lot, though I think a new extension would need to be coded for it to work. I think the best application would be to include current conditions, and perhaps the chance of precipitation in the next 24 hours in infoboxes. — Jake Wartenberg 03:04, 12 September 2009 (UTC)
Well, I don't want to include too many details, else we are in danger of entering travel-guide territory. –Juliancolton | Talk 03:08, 12 September 2009 (UTC)
I was just thinking in terms of technical functionality; it is nice to have more options than less. We can decide what to put in the articles later. — Jake Wartenberg 03:27, 12 September 2009 (UTC)
Strong support it would be awesome for our readers. - Peregrine Fisher (talk) (contribs) 03:29, 12 September 2009 (UTC)
  • I would warn on the possible issue of promotion. This would rely on an external service, presumably accuweather.com, but then what would be the appearance ? If it were silently encoded, it would be okay, but if for example a link to their website mentioning it is required... Cenarium (talk) 03:43, 12 September 2009 (UTC)
  • The weather data would be stored on a third party service compared to our servers, so it would require additional requests on page loads making things slower pluse additional issues if something was to go wrong on their end. Peachey88 (Talk Page · Contribs) 01:45, 13 September 2009 (UTC)
  • Conditional Oppose, to using an AccuWeather version of weather info. If it was anyone but AccuWeather (or any other branded commercial weather service, for that matter) I wouldn't mind one bit. Wikinews has weather info, so if we're going to do something like this it should be coming from there. I like the core idea of adding weather info, but using a commercial service to do so, here on Wikipedia, seems wrong.
    V = I * R (talk to Ω) 09:18, 12 September 2009 (UTC)
  • Encyclopedias include information about a location's climate, not weather forecast. That's more Wikinews' forte. I oppose. wodup 09:27, 12 September 2009 (UTC)
    • To be fair, comparisons between Wikipedia and traditional encyclopedias can only go so far, and this is one of the areas where a direct comparison cannot be made; it is absolutely impossible for a traditional encyclopedia to include current information about a location's weather. EVula // talk // // 14:50, 12 September 2009 (UTC)
      • Other encyclopedias that are on paper, cannot include current temperature. They print a copy maybe every 5 - 10 years? There is no plausible way to give current temperature. This is one of the advantages of using a website, instead of a book. warrior4321 14:56, 12 September 2009 (UTC)
Of course not. But that doesn't mean that a "weather right now" should be in Wikipedia just because it can be. It's simply not an appropriate thing to put in an article, here. ♫ Melodia Chaconne ♫ (talk) 16:17, 12 September 2009 (UTC)
  • Oppose including this information in articles by default. Wikipedia is an encyclopedia. The current weather is useful, but it has nothing to do with the purpose of this encyclopedia. We also don't do plane fares, local movie times, or directions. These are all useful things that the internet is very good at, and that print encyclopedias cannot do, but that doesn't mean we need to do them. These things can already be found on the rest of the internet, by people who are much better at it than we can ever be. But if you want to implement this as a Gadget, then sure. —Noisalt (talk) 16:24, 12 September 2009 (UTC)
  • Oppose - Any such service creates a dependency on a third-party site for the information. If the site goes down, the gadget breaks. If the site gets slowed down (like from having a top-10 website suddenly start getting its data for thousands of pages), then our site gets slowed down. There might also be copyright issues for the data, the way its presented, and the software the service uses. The AccuWeather extension linked above has several other problems that would pretty much guarantee it would never be enabled on Wikimedia sites in anything close to its present form. Mr.Z-man 16:44, 12 September 2009 (UTC)
  • Comment, your first few concerns could be resolved by caching the mined data. Also, the NOAA publishes its findings into the public domain. As for the AccuWeather bugs, I'm sure our developers would help us if we formed a consensus in support of this addition. –blurpeace (talk) 00:00, 14 September 2009 (UTC)
  • Cache it for how long? Current weather data is pretty much useless after a couple hours. NOAA only covers the US, presumably we would need worldwide coverage. The problem with the Accuweather extension is not only bugs (though it does have several), the problem is the design. To go into detail:
  1. It relies on JavaScript with no fallback. Users who the JS doesn't work for, or who have JS disabled will just see a big blue box.
  2. The JavaScript is just a thin wrapper around an embedded Flash object. Flash uses non-free technology, and there's also no fallback for browsers without Flash support (this is a problem with accuweather, not the extension)
  3. It gets content directly from the accuweather site, creating a potential privacy issue, by giving them the IP address of every person who visits an article that uses the extension.
  • Oppose. Mr.Z-man has succinctly characterized the core issue. And to clarify: Yes, we use some outside tools, but these are used only for maintenance and not for content.---— Gadget850 (Ed) talk 16:52, 12 September 2009 (UTC)
  • Oppose – this is an encyclopedia. No encyclopedia that I know provides up-to-the-minute tourist information. Shall we also update the status of London Underground lines? "The District line is currently closed due to a signal failure," would not befit Wikipedia, and it's precisely the same principle. ╟─TreasuryTagWoolsack─╢ 17:00, 12 September 2009 (UTC)
  • Oppose this well-intentioned idea per the valid reasons made by others above. In contrast, it makes perfectly good sense for pages about cities to state things like average yearly temperature and rainfall, but not this. --Tryptofish (talk) 17:22, 12 September 2009 (UTC)
  • Qualified support/oppose: If you had something that gave the reader an idea of the most recent weather over a reasonably long period, say the last three or six months, that might be helpful. For example, an article about New England would say that we have hot humid summers, but that hasn't been true this year and without correction a reader would have to assume that the New England summer of 2009 was also hot and humid. But 2010 might be different, so a moving or self-refreshing source that avoids the other possible problems with Accu-Weather might be useful, and the kind of Wikipedia function that printed works can't offer. —— Shakescene (talk) 23:52, 12 September 2009 (UTC)
  • Support seems like a great idea that can help improving some aspects of the articles.--Judo112 (talk) 21:03, 13 September 2009 (UTC)
  • Weak Support. It's a nice idea and useful. Will this be possible without a user having to download an applet and will it jack up the kbs of of articles? Valley2city 05:31, 14 September 2009 (UTC)
As others have mentioned, this kind of info is more of a Wikinews thing than for an encyclopedia. On the other hand, if Wikimedia wanted to better integrate the various projects, I imagine you could have a Wikinews box (maybe a template) in major city articles that could update things like weather and local news headlines on a daily/weekly basis. This kind of mini-In The News could potentially give locals a greater incentive to contribute to Wikinews if they knew their headlines would show up somewhere on WP.Joshdboz (talk) 13:39, 15 September 2009 (UTC)
  • Oppose. This belongs on Wikinews, not Wikipedia. Wikipedia is not a news site. Kaldari (talk) 18:35, 15 September 2009 (UTC)
  • Agree/Support I like User:Shakescene's suggestion has quite a bit of merit. While I agree wikipedia isn't a news service, but current weather news doesn't serve well as it happens in a relatively short amount of time. A hurricane, Major Tornado, Droughts, and Major flooding (and recovery) can happen over an extended period of time.
  • Oppose per reasons excellently expressed by Mr.Z-man. -Atmoz (talk) 04:12, 16 September 2009 (UTC)
  • Comments: I have several COI issues on this topic but I would oppose this idea based on the goal of creating an encyclopedia and the performance issues mentioned above. Further, the NWS/NOAA provides some climate data but also now seems to charge for some of it. An external link to their free stuff may not be unreasonable, much like many gene/protein articles have links to entries in pubmed. The gov sites provide a lot of useful free information on a bunch of topics but most of it is computer generated so it makes good information for an encyclopedic article but none of the sites themselves seem to be encyclopedias.
  • Strongly Support This would be cool, and yes it would be encyclopedic. If someone needed to know climate for a project, they could then have past and current climate data.Accdude92 (talk) (sign) 14:16, 17 September 2009 (UTC)
  • Oppose as being outside the scope of what an encyclopedia is. Shereth 14:34, 17 September 2009 (UTC)
  • Support as a helpful addition consistent with how we are also an almanac as well as an encyclopedia. Best, --A NobodyMy talk 02:21, 21 September 2009 (UTC)
  • Wikinews already has n:Portal:Weather, note. Uncle G (talk) 10:24, 21 September 2009 (UTC)
  • Oppose - Outside Wikipedie's scope. Garion96 (talk) 10:32, 21 September 2009 (UTC)
  • Oppose - This might work in Wikinews, but it has no place in Wikipedia. -- allennames 17:16, 22 September 2009 (UTC)
  • Strong support- While I generally agree with Mr. Z-man, I must say that he is a bit misguided on the technical portions. Certainly, wikipedia would be requesting info, but it would then be cached and served from wikipedia's end(any third party would create a serious privacy concern). It would be fairly easy to implement, the bandwidth usage would be easy to control based on how often the update is.— Preceding unsigned comment added by 65.51.38.194 (talk) 23:28, September 23, 2009 (UTC)
    • My comment was based on how the AccuWeather extension actually works right now. Doing caching locally in a way that doesn't completely break the existing caching system (which caches pages for far too long to cache weather data, 30 days or until an edit IIRC) would be far more difficult. And it would still require us to find a source for free (in terms of both price and IP) weather data that doesn't use Flash. Mr.Z-man 00:16, 24 September 2009 (UTC)

Paraphrase Robot

Would it be possible to create a robot that would paraphrase sources and actually write the articles for us? --William S. Saturn (talk) 21:12, 14 September 2009 (UTC)

According to WP:Close paraphrasing, "Copyright law forbids Wikipedia contributors from copying information directly from other sources except in limited cases and with attribution." hmwith 22:12, 14 September 2009 (UTC)

There are already such things as bots, and they are responsible for considerable amounts if edits in Wikipedia.However, I strongly oppose the above suggestion. Wikipedia gives human editors the chance to be creative and to write articles on subjects whichthey have some knowledge. We do not really want to turn Wikipedia into a purely machine-driven,robot-generated list of facts, which would most probably reduce the quality of most articles. The Wikipedia in Volapuk had many articles by a bot, but it did not appear to be superior to the English Wikipedia. ACEOREVIVED (talk) 23:00, 14 September 2009 (UTC)

Why go to all that trouble when a robot can do it instead? The content of articles is purely informational and objective, and since references are required and original research is prohibited, all the editor does is just reflect the information. This is a good task for robots, not humans. Of course there would have to be a human oversight and humans would still be able to edit, but this idea would allow for a mass production of articles and significantly help the public at large. --William S. Saturn (talk) 00:31, 15 September 2009 (UTC)
I used to do AI in school. What you're asking for would be awesome, but is currently impossible. It would require a bot that understands English, and if you can solve that problem, you've solved most robot problems by extension (and they would soon take over the world). - Peregrine Fisher (talk) (contribs) 00:55, 15 September 2009 (UTC)
That's what I was asking, and ACEOREVIVED gave me the impression that it was possible, but now I see this is currently impossible, thank you Peregrine Fisher for your insight. --William S. Saturn (talk) 01:00, 15 September 2009 (UTC)
There have been bots that extract information from a database and create articles. Recently there was one creating articles on algae, but it was more clueless than a human, and could not handle articles already existing, on the same topic or same name different topic. Another case was the mindless creation of stubs on rivers with almost no content. Graeme Bartlett (talk) 14:02, 15 September 2009 (UTC)
Even if a bot could do this, a "perfect" paraphrasing would lead to massively inconsistent articles, as they would still be in the same general tone and style of the source. It would need to be able to both paraphrase it, and convert it to Wikipedia's style. Mr.Z-man 16:33, 15 September 2009 (UTC)
On a side note, Microsoft Word has an auto-summerize feature that sort of does a bit of what you're asking for. I ran it against an article on creating a lunar DNA bank, and it actually did a pretty nice job. Of course, it doesn't aggrigate across multiple sources. A Quest For Knowledge (talk) 17:02, 15 September 2009 (UTC)
Key to the problem is plural: paraphrasing a single cohesive text is peanuts, but no robot can stitch together pieces picked from different sources. Collecting, selecting, collating and presenting multiple sources will inevitably take more time than any manual "paraphrasing" and, guess what, once the homework is done properly it's not necessary at all. NVO (talk) 18:57, 15 September 2009 (UTC)
Oh ye of little faith!
You insist that there is something that a machine can't do. If you will tell me precisely what it is that a machine cannot do, then I can always make a machine which will do just that. — John von Neumann
lol
V = I * R (talk to Ω) 20:00, 15 September 2009 (UTC)
How about a perpetual motion machine? ;) A Quest For Knowledge (talk) 16:45, 16 September 2009 (UTC)
The key word in that quote is "precisely": once you give me a precise definition of "a robot that would paraphrase sources and actually write the articles for us", I'll be happy to code up the bot. Keep in mind that you'll get exactly what you ask for, so if you're not careful in how you define "paraphrase", "sources", and "write the articles", you're likely to get a high-tech nonsense generator. --Carnildo (talk) 23:06, 16 September 2009 (UTC)
Working on it (more or less) <G>
V = I * R (talk to Ω) 23:31, 16 September 2009 (UTC)

This whole discussion seems to be pointing to one of those nightmare discussions about whether human electronic, electrical or mechanical devices will ever replicate human intelligence. Can I just say that when, in 1997, Kasparov was beaten by a computer called Deep Blue at chess, the people were saying "Oh, how clever a computer". However, a letter appeared in "New Scientist" pointing out the following. The event actually showed how intelligent humans must be to have constructed a computer that could out-smart Kasparov. ACEOREVIVED (talk) 19:21, 23 September 2009 (UTC)

Revert alert

I propose to have a feature whereby if a user's edit gets reverted, then that user would get notified (on a "revert list", or maybe on their talk page). GeometryGirl (talk) 21:54, 17 September 2009 (UTC)

Although I can see a use for this feature for legitmate edits that are reverted, I can see too many editing conflicts/wars becoming escalated due to it. Especially in articles where heated edit wars often occur (eg anti-americanism), such a tool would promote even further reverts, without little justification. Also, it would place an unnecessary weapon in the hands of vandals. Oppose Iciac (talk) 23:33, 17 September 2009 (UTC)
  • Comment. I think she means she would like a warning generated everytime somebody reverts her, just like the PROD and CSD warnings one gets if the article they created receives such a tag. warrior4321 23:44, 17 September 2009 (UTC)
Those warnings aren't generated automatically, either the tagger or a bot has to add it, having that for every revert would be extremely excessive and result in thousands more edits a day. If a user cares about the edits they make its assumed they have the page watchlisted, often if a revert is major users will talk to the user they're reverting anyway, the whole WP:BRD system--Jac16888Talk 23:50, 17 September 2009 (UTC)
Not really. You know when you tag an article for PROD or CSD with Twinkle, it automatically sends a warning to the initial contributor? If somebody reverts with Twinkle, the same warning should be able to be made, without a bot. warrior4321 00:30, 19 September 2009 (UTC)
yes but those edits are still made, by you, they are still listed in recent changes and contributions and therefore would still be excessive--Jac16888Talk 10:13, 23 September 2009 (UTC)
I don't think making things hard to force a certain behavior is ever a good idea for Wikipedia. I also want something between a watchlist and my contributions. I may want to know if someone reverts me or edits soon after, but not follow every edit to the article until I manually remove it from the watchlist. --Apoc2400 (talk) 19:06, 18 September 2009 (UTC)
In addition to the valid concerns Jac16888 and Iciac raise, this sort of thing would only support people in their efforts to control a given article. If someone cares and/or worries that much about a particular edit, I'd suggest discussing it on a talk page first. ~ Amory (usertalkcontribs) 19:22, 18 September 2009 (UTC)
On the contrary, those who OWN an article surely have on their watchlists. This would help visting editors notice if they are reverted by the article regulars. I also still hold that we shouldn't speculate on how people might use a technical feature at all. The interface should help editors find information and edit, not restrict information in an attempt to control. --Apoc2400 (talk) 01:27, 19 September 2009 (UTC)

Unhiding reference errors on User-namespace pages

(forwarded from Help talk:Cite errors#Broken refs on user pages)
A while back, the various MediaWiki messages for errors generated by broken <ref> tags were adjusted to be hidden on talk pages, after numerous complaints about how "useless" they were there. I was testing references in my sandbox, and discovered that the namespace detection also hides the error message in the User namespace.

I don't suggest adding user pages to the reference error tracking categories (that would be about 3147 of them, after all), but would anyone be opposed to making this edit so we can see the errors? Anomie 22:55, 18 September 2009 (UTC)

My suggestion on a tracking category was only to see how many pages would be affected— your API query answers the question. My only issue is if we would have a large number of readers getting confused when error messages start showing up. Could we wrap the message in a class that would normally hide it and allow editors to opt-in? ---— Gadget850 (Ed) talk 23:29, 18 September 2009 (UTC)
That would work for me, although why someone would have refs on their user page (or user subpage) and not care that they're broken is beyond me... Anomie 02:20, 19 September 2009 (UTC)
Well, we had all those references copied to talk pages without a <references /> tag. Instead of actually fixing it, folks just wanted it to go away. And that's how we got here today. Anyway, it's just a thought— let's see what others think of it. ---— Gadget850 (Ed) talk 02:47, 19 September 2009 (UTC)
I do remember seeing the complaints about talk pages, but I'm not proposing showing the errors for them. Anomie 11:46, 19 September 2009 (UTC)
Nor am I suggesting that, but simply comparing it to previous discussions. ---— Gadget850 (Ed) talk 13:25, 19 September 2009 (UTC)
Since there are no objections, I will make the change in a while. Gotta run. ---— Gadget850 (Ed) talk 12:25, 21 September 2009 (UTC)
 Done ---— Gadget850 (Ed) talk 19:56, 21 September 2009 (UTC)
I have pages in my user space with references without a <references /> tag. There are many reasons for this, not every page in userspace is a proto article. Some are just pieces that are intended to be inserted in an existing article. Some refs are just there to record where information came from, it is not necessarily desirable to clutter the page by actually displaying the information. There is one like that on my userpage which it looks like you are now going to force me to either delete or rework my page. SpinningSpark 20:00, 23 September 2009 (UTC)
If you have references for copying and pasting into different articles, put them in <pre></pre> so you don't have to view the source to copy the text. If you have an article section (rather than the whole article) on a userpage, why not throw a References section at the bottom so you can see that the references are being formatted correctly too? If you're wanting strange "refs" that go nowhere just to hide the source information in the wikitext, why not use <!-- comments --> to do it more straightforwardly?
The problem with hiding the ref errors is that people who are working on articles in their userspace then can't see the errors they do need to fix, which frankly trumps "Oh noes! My beautiful userpage is ruined!". Anomie 21:50, 23 September 2009 (UTC)
As noted, adding {{reflisthide}} will suppress the message. ---— Gadget850 (Ed) talk 22:56, 23 September 2009 (UTC)

'Questions' feature

This is not my idea, but I think it is a good one: Allow readers to ask questions if an article doesn't have what they're looking for. GeometryGirl (talk) 00:03, 21 September 2009 (UTC)

Do you mean by posting on the talk page, or in some other manner? — CharlotteWebb 00:30, 21 September 2009 (UTC)
I could see something like that. I know on many pages, when someone asks a general question they might get a reply (or even their question removed) with a terse "not a forum", but maybe through asking these questions, i.e. through that discourse we can wind up thinking of ways to improve the articles, especially if sources come up in the discussions. Sincerely, --A NobodyMy talk 02:13, 21 September 2009 (UTC)

We already have the Wikipedia:Reference desk. Uncle G (talk) 09:54, 21 September 2009 (UTC)

Exactly. We already do. ╟─TreasuryTagNot-content─╢ 10:08, 21 September 2009 (UTC)
Well I was thinking about a more local feature present for every article, complementing the talk page. GeometryGirl (talk) 20:31, 23 September 2009 (UTC)

New introduction to new editors

After some thought and after going through the experience myself of climbing the ladder from newbie to established, I can safely say that my successful climb was based purely on determination to continue despite the odds.

What I mean by this, is the difficulty of new users in learning the ropes, the policies, the rules, and the little ins and outs of the encyclopedia. While they are all linked, these policies are laid out to be stand alone policies, and thus new users have to read through a lot of information, and often give up.

I propose a page that lays out all the cornerstone policies all at once, in a simple manner. Each policy would link to its standalone article, where the user could get more specifics. However, this all-in-one page would cover all the important information in one swift blow. This page should be linked directly from WP:Introduction.

Thoughts? - ʄɭoʏɗiaɲ τ ¢ 16:49, 22 September 2009 (UTC)

WP:5P? --King Öomie 16:53, 22 September 2009 (UTC)
That mixed with Wikipedia:List of policies would be ideal. 5 pillars doesn't go in depth enough (Although I believe 5P is a thousand time better of an introduction than the crappy vandal prone WP:Introduction page, which is a sorry excuse for an introduction to a site like this). - ʄɭoʏɗiaɲ τ ¢ 16:59, 22 September 2009 (UTC)
Are you proposing a summary style page for the policies, or just a sort of list for all of them? warrior4321 00:42, 23 September 2009 (UTC)
Maybe it would help some newbies, but in my own experience I have still never after 3 years, one as an IP and two on this account, ever ever ever ever NEVER read wp:introduction or the 5 pillars, neither can I tell you what the five pillars are (1-There is one God, 2-Mohammad is his prophet, 3-pray 5 days a week....oh, I only got 3 of the five! darn!). I imagine there are more than just me who got hooked on Wikipedia (and drugs) from experimenting on a single article or group of related articles in a topic that they really care about. Are there alot of potential newbies who right now are saying "I wish I could grow up to be an administrator on Wikipedia! But how?!". I think throwing at them our policies and guidelines and trying to make them "good little editors who follow the rules" is the wrong image we want to give. We want them to have fun, experiment, learn by doing. We dont want them to have to memorize a bunch of rules first and expect them to conform right away. We and our consensus driven policies and guidelines need to evolve and grow, and they do so by having newbies who question the purpose of them and point out new ways of doing things. Do we want to crush that spirit so soon when they get here? How about this- when you first sign up an account you get a page that says "Welcome! Now have fun, if you have questions go to xxxx. We do have some policies and guidelines that we have come up with to solve most problems that may arise, you may want to check them out when you have time, this is where you may find them (wp:list of policies)" or something less corny, or maybe more corny to lighten up the mood. First and foremost any message to newbies needs to convey that we want them to have fun and that they have all the rights and responsibilities of someone who's been here 5 years.Camelbinky (talk) 03:36, 23 September 2009 (UTC)
I'm very happy to say that I actually agree with Camelbinky. The one and only real rule is: Ignore all rules. If the goal is to make new editors feel more welcome and to just help them out in osme manner, the answer is certainly not new procedures, new rules, new process, or anything like that. There is already far to much process here, far too little community, and just too much angst and drama for little purpose.
V = I * R (talk to Ω) 05:33, 23 September 2009 (UTC)
I think if thats the case then in turn we need to be more lenient on these new editors for ignoring all rules. I agree otherwise though. I didn't mean a long droning page on the rules, I meant something that sums up the wiki-lifestyle of experienced editors to help assimilate the new editors in. Too many editors join and don't become long standing, non-SPA members, which we need more of. - ʄɭoʏɗiaɲ τ ¢ 06:48, 23 September 2009 (UTC)
The thing is, there's really nothing here socially other then negative, confrontational items for editors to be involved in. I'm decidedly not advocating for some sort of attempted conversion to facebook or anything like that, but almost the only reason that anyone has to talk to each other here is to discuss how we disagree. The whole underlying structure of Wikipedia is negative.
LiquidThreads should be a fairly significant step in the right direction, but the anti-social aspects to Wikipedia are endemic in policy and guidelines as well.
V = I * R (talk to Ω) 17:27, 23 September 2009 (UTC)
WP:AGF goes a long way - or at least it should - to addressing this problem. We need to remember that most newbie editors are not ignoring rules, they are simply ignorant of them. There is certainly some merit in the idea of trying to educate them up front to try and keep them from getting involved in a firestorm down the line, but the "antisocial" aspects that you allude to need to somehow be addressed. Unfortunately, I don't know how you can force established editors and administrators to be more welcoming to newcomers and forgiving of mistakes. Shereth 17:37, 23 September 2009 (UTC)
Generally speaking people can't be forced, but they can be overwhelmed and may "see the light" (so to speak). Thre are good technical reasons to limit discussions on Wikipedia, since the software really isn't designed for forum like communication. It's (relatively) perfect for single document collaboration, but there's a good reason that no forums use wiki-style software for their underlying platform. LiquidThreads will at least remove one major problem (edit conflicts), and significantly address several more minor issues (automatic sigs, watch-listing specific conversations rather than pages, etc...), so that's a definite first step. We'll see where it goes from there.
V = I * R (talk to Ω) 18:05, 23 September 2009 (UTC)
Personally when I come to wikipedia, though there are some articles that I have personal investment in, I come with the intent of working together. I know I'm not perfect (I know my sentence structure and grammar are horrendous), and I hope to work with others to create perfect articles. We need to make an effort to work that attitude into new editors. You can't teach an old dog new tricks, but you sure can lead the puppy to success (Sorry for the really aweful metaphor) - ʄɭoʏɗiaɲ τ ¢ 03:52, 24 September 2009 (UTC)

Articles for Conversion to Redirects

What I am proposing is a procedure midway between deleting and merging an article. The proposed conversion to redirect would be discussed and if the consensus is for conversion the resulting redirect would be placed into Category:Redirects from conversion. It may also be desirable to have an administrator seal the history of the page at the point of conversion to prevent reversion. If approved this proposal will affect Wikipedia:Articles for Deletion and Wikipedia:Redirects for Discussion as the procedures for these will have to be changed. -- allennames 18:04, 22 September 2009 (UTC)

Converting to a redirect is a standard option we have have long used at AfD as one of the results of discussion. As note in the first paragraph of WP:AFD, following an overview of the process: "Then the page may be kept, merged or redirected, transwikied (copied to another Wikimedia project), renamed/moved to another title, userfied to the creator's user page or user subpage, or deleted per the deletion policy." (emphasis added) Please see these search results. Are you proposing something that would be necessary separate and apart from this existing process and if so, how is it different and needed to supplement it?--Fuhghettaboutit (talk) 18:18, 22 September 2009 (UTC)
Articles for Conversion would proceed in a manner similar to Articles for Deletion without any need for an administrator to close it. A vote to delete would require WP:AFD, and a vote to merge will simply result in the standard merge. The edit summary of a conversion would indicate if administrative involvement was desired to seal the history as I pointed out above. -- allennames 19:38, 22 September 2009 (UTC)
  • This is, and should be, an integral component of the existing AFD process. The need for admins in AFD discussions is purely technical as well, not procedural. Admins are not moderators, they are simply trusted with responsible use of the tools, and can therefore perform actual deletions. One thing that should be done though is to rename all of the "X for deletion" processes/pages as "X for discussion", simply to reinforce the point that deletion is not even remotely the only action possible from an XFD discussion. A couple of other recent (more specific) conversaitons have occured along this vein, with the largest hangup being technical (changing the archiving bots to use "discussion" in place of "deletion" seems to be the largest hurdle).
    V = I * R (talk to Ω) 19:59, 22 September 2009 (UTC)
  • There is no reason to fork this out of the AFD process, as has been stated above. WP:NAC specifically allows for non-admins to close these discussions as a redirect if the consensus indicates as much. Creating a dedicated forum for proposing an article be made a redirect is somewhat redundant and would add unecessary confusion and complexity to the process. Shereth 20:04, 22 September 2009 (UTC)
    You know, someone should probably take on the task of re-writing the deletion policy to make it clear that admin action is unnessesary for anything other then the actual deletion task.
    V = I * R (talk to Ω) 20:11, 22 September 2009 (UTC)
    AFAIK, the reason it has not is because WP:NAC is not policy, and doing so would essentially elevate it to policy. Perhaps there is some merit to the idea of refining WP:NAC and elevating it to a policy, as it seems to be fairly well adhered to. Shereth 20:15, 22 September 2009 (UTC)
    I have read WP:NAC and see that it may need editing if my proposal is approved. A closure of Articles for Conversion will not need an outside editor or administrator as long as the discussion about it is made. Otherwise the conversion can be reverted just like any other article edit. if an Article for Conversion discussion leads to conversion to redirect any reversion can be considered vandalism. -- allennames 20:32, 22 September 2009 (UTC)
    I am really not seeing the need for this process, and it strikes me rather as a solution in search of a problem. Can you elaborate on the need for it when the mechanisms for doing this already exist within AFD? Shereth 20:38, 22 September 2009 (UTC)
    The presumed goal of WP:AFD is deletion. I feel the need for a possess that neither deletes, nor requires an immediate merge. -- allennames 20:43, 22 September 2009 (UTC)
    I forgot that you are thinking of this within the AFD context. There are merges in name only out there and I hope for a formal process. -- allennames 20:50, 22 September 2009 (UTC)
    I believe the process you are looking for is called the Article Talk. If someone thinks an article should be merged or redirected, the proper thing to do is discuss it on the talk (or simply be bold per WP:BRD). There is no need for a centralized discussion on the matter. Shereth 20:56, 22 September 2009 (UTC)
    Do you know where I can find Article Talk. -- allennames 21:06, 22 September 2009 (UTC)
    I was referring to the individual article's talk page. Shereth 21:40, 22 September 2009 (UTC)
    Okay. I still think something needs to be done so we do not have to pretend we are going to merge a page's content into another when using one of the merge templates, but I withdraw my proposal. -- allennames 21:50, 22 September 2009 (UTC)
    For what it is worth, the use of a template isn't really even necessary. If it seems like an uncontroversial edit, it's probably safe to just redirect it without even initiating any discussion on the matter. If there is some room for contention, it can be brought up on the discussion pages. If you like, a version of the {{mergeto}} and {{mergefrom}} can be made to specifically address redirects. Shereth 21:55, 22 September 2009 (UTC)
    See {{R from merge}}. This template should always be placed on any redirect leftover from a merge. -- œ 03:11, 23 September 2009 (UTC)
    A "Requested mergers" task group, along the same vein as Wikipedia:Requested moves, would be worth attempting, if anyone feels up to the task. As something less then deletion, and a task which requires little if any admin activity, it could certainly be helpful.
    V = I * R (talk to Ω) 00:03, 23 September 2009 (UTC)
    Incidentally, it has since been pointed out to me that WP:PM exists, although the level of activity there seems to be... wanting.
    V = I * R (talk to Ω) 02:26, 23 September 2009 (UTC)
Just so you know, newpages patrollers routinely redirect new articles without any discussion, and as reviewing admin on some speedy deletions, after some declines I will then redirect. If discussion is needed, the talk page serves, and if it should not be a stand alone article but the redirection is reverted, then a formal decision can be sought at AFD where, if a need to protect the redirect is found, that too be implemented by an admin doing the close. In short, now that what';s sought has been clarified I see nothing that current process (or lack of process) doesn't already address.--Fuhghettaboutit (talk) 00:34, 23 September 2009 (UTC)

Upload form usability

Our upload form is quite a mess right now in terms of usability. Here are just a few things I've noticed:

  • Why is "uploading images and multimedia" linked? I would expect such text to link to an upload form, but I'm already on the upload form!
  • "Go here and here to ask..." - so which link do I click? The first link is about copyright questions, and the second link has nothing about questions at all.
  • "other questions" - so what questions am I supposed to ask here and not at the other two links?
  • "Uploading a free image or media file?" - so if I'm uploading an image that isn't free, I go to the next section?
  • "...or a historically significant fair use image" - why is this on the same line as promotional photos? And what is a historically significant fair use image, anyways?
  • "A cover or other page from a book, DVD, newspaper, magazine, or other such source" - when I click the link, I go to a page that doesn't mention books, DVD, newspapers, or magazines. Did I do something wrong?
  • Why the heck is there a question mark with a C on this page? I'm not here to ask a question!

Now, I don't know the best way to fix all these problems, but I do know the problems are there. — RockMFR 16:25, 20 September 2009 (UTC)

I agree that the upload form is very confusing for new and established editors alike. I get frustrated even looking at it, then I just go directly to Special:Upload. I'm not sure the best way to fix things, but your ideas seem like a great place to start discussion. hmwith 17:02, 20 September 2009 (UTC)
Yes, that's what I do when uploading to commons at least. {{pro-tip}} disable javascript on the upload page. — CharlotteWebb 00:06, 21 September 2009 (UTC)
Good points. I've contributed some clarification of the hatnote at the top of the page [18], but the whole thing could use a redesign - possible along the lines of the Article Wizard. Rd232 talk 11:45, 21 September 2009 (UTC)

The Foundation has received a grant from the Ford Foundation to improve the usability of uploading multimedia, and is currently hiring a full-time person to work on this project. — Werdna • talk 12:37, 21 September 2009 (UTC)

Cool. How about noting that in an infobox on the upload talk page? Rd232 talk 19:28, 21 September 2009 (UTC)

I had similar thoughts about the upload form over a year and a half ago, after getting sick of seeing people endlessly uploading unencyclopedic crap (everything from random crude thumbnails pulled from Google Images to peoples CV's in PDF format; trawling through Special:Newfiles and Special:ListFiles is (or used to be) enough to make one weep), and also being annoyed with images transferred to Commons having their histories obliterated, so tried to design a new page to better direct people to the right place from the beginning. It's in my sandbox: User:Anakin101/Sandbox. I haven't done anything with it ever since so it's probably out of date with current policies and such, but feel free to butcher any aspect of it that seems useful. • Anakin (talk) 12:59, 22 September 2009 (UTC)

I really like your new upload page Anakin. Perhaps, his page should be properly reviewed, and be proposed to change the current upload page. warrior4321 23:49, 24 September 2009 (UTC)

Sub-pages for AN\ANI

A conversation about using sub-pages at WP:AN and\or WP:ANI has been started at Wikipedia talk:Administrators' noticeboard#Sub-pages.
V = I * R (talk to Ω) 00:56, 26 September 2009 (UTC)

There needs to be a way to switch easily between Wiktionary and Wikipedia on every page...—Preceding unsigned comment added by GaryGermeil (talkcontribs) 02:43, September 26, 2009 (UTC)

You mean like {{Wiktionary}}?
V = I * R (talk to Ω) 02:54, 26 September 2009 (UTC)
Or typing into the search field "wikt:" followed by any word to access the Wiktionary definition (example wikt:callipygian)?--Fuhghettaboutit (talk) 06:36, 26 September 2009 (UTC)
I think what was meant was a link you can click on (a bit like the foreign language links, I suppose). Ordinary readers aren't going to know or remember about the "wikt" trick.--Kotniski (talk) 09:15, 26 September 2009 (UTC)
OK but... why? I could see adding an interwiki map to the sidebar. That could be useful.
V = I * R (talk to Ω) 09:19, 26 September 2009 (UTC)
You can use the " "wikt:" followed by any word" trick from Fuhghettaboutit in your wiki-markup just like any other word (eg. "wikt:cognizant|" inserted before "cognizant" within the "[[]]" gives you cognizant) Num1dgen (talk) 04:46, 7 February 2012 (UTC)

Collapse hidden cat and template lists on edit page

With regards to the edit page, can we please make it so that the hidden categories and transcluded templates are collapsible, and collapsed by default? On long pages these list can become quite unwheldly, and it seems odd that it is presumed the majority of people want to see them all the time. They are a major source of visual clutter on the edit page, and must be confusing to new users. -- Anxietycello (talk) 14:26, 26 September 2009 (UTC)

Someone could easily enough create a gadget to collapse them for you. As for the assertion that "[it] must be confusing to new users", [citation needed]. Anomie 18:12, 26 September 2009 (UTC)
The Usability Project is working on the template-collapsing thing, IIRC. --Cybercobra (talk) 20:44, 26 September 2009 (UTC)
Was the original question about collapsing templates in the edit textarea, or collapsing the list of "Templates used in this preview" at the bottom of the page (underneath the symbols box)? I know the Usability people are working on the former, but I haven't heard anything about the latter. Anomie 21:37, 26 September 2009 (UTC)
It was the latter; I'd like to see both lists that often appear on the edit page, the ones that read "Pages transcluded onto the current version of this page:" and "This page is a member of n hidden categories:" be hidden by default. In that those sentences still show, but have a [show] symbol next to them, that when clicked displays the full list to which it refers. I'd also quite like to see the wording of the template list changed, to something like "This page contains n transcluded templates:" so as to look more consistent, and to helpfully give the number of templates used.
And as for the citation, see File:Wiki feel stupid v2.ogv, from the woman who appears about 50 seconds in. -- Anxietycello (talk) 22:39, 26 September 2009 (UTC)

Adminbot brfa

Wikipedia:Bots/Requests for approval/Orphaned image deletion bot - the bot will delete orphaned fairuse images per WP:CSD#F5 --Chris 01:08, 27 September 2009 (UTC)

Can we please tidy up and simplify the warnings on the edit page?

My proposed version (right) contains all the text of the current version (left), but presents it in a more logical and clear fashion. It also includes a request that all work submitted be neutral, verifiable and encylopedic - the core of our complex rulebook. Note how it also takes up less room.

Currently, there are three sources of the warning text on the edit page: MediaWiki:Wikimedia-copyrightwarning sits between the edit window and summary box, MediaWiki:Wikimedia-editpage-tos-summary sits between the summary box and the edit tools, and MediaWiki:Edittools generates the edit tools, as well as a section of warning text that follows it. I feel this is unsightly, confusing, and unnecessarily hard to spot and read. I propose that these messages be merged -- the first two should be deleted, and the text from all three be merged into something I would call "MediaWiki:Editwarning" (or something similar) which would be placed immediately after MediaWiki:Edittools, and would contain all the most important warning text of the three old messages, and some new, equally important text that I feel is currently missing. Above is a mock-up of my idea (the code used to generate it can be found at User:Anxietycello/Interface). -- Anxietycello (talk) 18:02, 24 September 2009 (UTC)

Sounds good to me. The only quibble I have with the proposed version is the thick outline around the message text.
V = I * R (talk to Ω) 19:18, 24 September 2009 (UTC)
That's just to indicate that all these messages are important, and ideally should all be read when first spotted. I tried it with a thin grey line, but it just got lost in all the other thin grey lines around it. I also quite like the way it looks with the emboldened 'please note' header. -- Anxietycello (talk) 19:38, 24 September 2009 (UTC)
I see what you're getting at, but... meh. It's not an issue that is a deal breaker for me by any means, but I know from past experience that eye-catching formatting like this becomes annoying fairly quickly. The "Please note" text being larger and bold is fine, but the box is just too much.
V = I * R (talk to Ω) 19:50, 24 September 2009 (UTC)
A 2px black line isn't all that offensive is it? At least there's no flashing animations... I feel the (modest) border is akin to the image copyright notices. -- Anxietycello (talk) 20:38, 24 September 2009 (UTC)
I don't really have any "proof" to point to, but outlines tend to draw my eye in a similar fashion as blinking does. Well, not quite to that extent (obviously), but more then bold text does. Outlines are just not as common as text bolding is, so there's... a psychological difference? Bolded text you'll tend to pay more attention to while you're reading the actual sentence, but you'll tend to ignore it otherwise (it's not distracting). Headings draw your attention in a similar manner, in that you notice them while scanning the page but not so much while reading the prose. Outlines just seem to draw the eye to them regardless of anything else, which is what my weak objection is all about.
V = I * R (talk to Ω) 21:27, 24 September 2009 (UTC)
Is your problem with my little black line, or is it with attention-grabbing graphics in general? Because this in't really the place to wax philosophical... I'm not worring that people will be so drawn to my black line that they'll neglect to read the text. Bullet points are very easy to read. -- Anxietycello (talk) 22:52, 24 September 2009 (UTC)
As I said originally, my only quibble is with the inclusion of a heavy back outline around the whole thing.
V = I * R (talk to Ω) 23:52, 24 September 2009 (UTC)
FYI you can hide all of that crud thru your css. See mine, for example. Though I do think yours looks cleaner for those who haven't opted to do this. –xenotalk 20:01, 24 September 2009 (UTC)
Thanks, but I am not really looking to hide it, rather make it more readable and less of an eyesore. -- Anxietycello (talk) 20:38, 24 September 2009 (UTC)
Good idea re: hiding it all. I think I'm about to do that, regardless. Thans xeno!
V = I * R (talk to Ω) 21:29, 24 September 2009 (UTC)
The position of MediaWiki:Wikimedia-copyrightwarning was dictated by legal concerns: by putting the GFDL/CC-BY-SA text between the edit box and the "submit" button, it's impossible for someone to claim they didn't realize they were releasing their contributions under those licenses. I've been trying to keep that text focused on license issues, but apparently the majority of the people on this website think that the solution to notices not being read is to add more notices. --Carnildo (talk) 21:23, 24 September 2009 (UTC)
I agree that that copyright notice is a little swamped at the moment, and that was one of my main motivators; to deobfuscate and so make it all easier to read. Is having it clearly written on the page not precautionary enough? How often to people try and claim they own the rights to the text they write? -- Anxietycello (talk) 22:52, 24 September 2009 (UTC)
Having the "You agree" language before the save button is important to us as Carnildo explains. (It can possibly be shortened a bit, but we have to be careful not to lose essential meaning .) That should still allow for a lot of cleaning/neatening of the current edit screen, though.--Eloquence* 23:45, 24 September 2009 (UTC)
How about leaving "You agree to irrevocably release your contribution under CC-BY-SA 3.0 and GFDL licenses. You agree to be credited, at minimum, through a hyperlink or URL when your contributions are reused in any form. See Terms of Use for details." there, as it is currently (sans the first two sentences), merging all the other text into MediaWiki:Wikimedia-editpage-tos-summary (the warning just after the Save button), and moving the (trimmed) edittools up to sit below the the edit window? -- Anxietycello (talk) 12:16, 25 September 2009 (UTC)
Upon viewing your proposed layout, this was my concern as well, that the legality of the click-wrap could be affected. It seems to me that leaving the legal agreement in place and moving the rest would be a good improvement. 05:01, 27 September 2009 (UTC)

Uninvolved admin batsignal

Not so long ago, I copied {{adminhelp}} and the corresponding category Category:Wikipedians looking for help from administrators from their basis in {{helpme}} so that editors could quickly lure an admin to their talkpage for some uncontroversial gruntwork. The idea was to make it easier for editors needing help to find willing admins and vice versa, and to take some (relatively trivial) traffic away from the administrators' noticeboards. It seems to work well.

Perhaps it's just me, but I think our norms on what constitutes involvement for an administrator (and perhaps for others) have gotten stricter lately. I've also noticed increasing laments that various issues and venues were suffering from a dearth of uninvolved administrators. So I wonder if it would be a good idea to implement a similar system to {{adminhelp}} except for use in drama disputes on any talkpage where those involved feel that the situation could benefit from an unimplicated admin. There would be a template ({{freshadmin}}?) for editors concerned at potential admin abuse to deploy, and a category for similarly concerned administrators to monitor (perhaps also through IRC if that was deemed desirable). Again, this would make it easier for those in need of help to find appropriate helpers, and result in fewer unnecessary reports to admin boards (in this case, ANI dramafests). Like {{editprotected}}, the template should be nullified once the uninvolved admin arrived on the scene, and the category should be regularly cleared out. The template could look something like this, and include the category:

It could look something like the following (or perhaps might be better as a box at the side):

Update: Ah, after a little digging, it looks like there has been an abortive project along these very lines, at an obvious title: {{uninvolved}}. A tip of the hat to the arbitrator emeritus. Is this something we should be pushing forward?  Skomorokh  08:19, 26 September 2009 (UTC)

Can't do any harm, and I can see it being helpful. The main issue is making easy for editors to find such tools - I've been editing since autumn 2006, and have being doing GA reviews since autumn 2008, but I've never heard of {{adminhelp}} or {{uninvolved}} until a few seconds ago. --Philcha (talk) 08:43, 26 September 2009 (UTC)
Aside from my philosophical view that there cannot be such a thing as an "uninvolved administrator"... the key to these things is simple: SPAM! Start adding notifications bout the existance of the template to obvious places. ANI and AN spring immediately to mind. Sprinkle mentions of the template throughout policy and guideline documents. Mentioning it in the AFD documentation probably couldn't hurt. I'm sure there are other places as well, but the kep concept is to reach that "critical mass" point of awareness.
V = I * R (talk to Ω) 08:50, 26 September 2009 (UTC)
I can only support this if we use an actual bat signal. —Noisalt (talk) 11:51, 26 September 2009 (UTC)
It could pop up as (\/\/) on #wikipedia-en-help Gigs (talk) 05:05, 27 September 2009 (UTC)

Edit Notices

I would like to propose that we create unique div tags for each edit notice so that they can be hidden via css by users who dont want to see a particular notice. βcommand 23:47, 24 September 2009 (UTC)

Support I can certainly see this being helpful. Many pages, like AN, have edit notices that are geared toward new users and can take up more than half a page. — Jake Wartenberg 23:54, 27 September 2009 (UTC)
Support, but optionally, certain editnotices should not be dismissible (easily), for ex. in cases of editnotices used to handle edit wars. However, would this add a [hide] link (and be available to anons), or do we have to edit our css ? (I had requested optional disimissibility of editnotices in the past.) Cenarium (talk) 00:21, 28 September 2009 (UTC)
Question: "Unique div tags for each edit notice" sounds like you want a unique id per notice. I can see that this could be done based on the page name. Editors would have to hide each specific notice. ---— Gadget850 (Ed) talk 00:37, 28 September 2009 (UTC)
that was what I was thinking. The BLP edit notice could be ignored while leaving all other notices in tact, or you could ignore any others that needed it via a single line in your monobook.css .DIVNAME {display:none;} and then not have to worry about it. For Cenarium's comment it would not be a javascript function, with a "hide" button, but rather a discreet method for removing annoying edit notices that users are familiar with. βcommand 00:48, 28 September 2009 (UTC)
Why can't the <body> tag's ID be used? --MZMcBride (talk) 00:49, 28 September 2009 (UTC)
that is unique to each page while some edit notices are across multiple pages IE the BLP notice. and Im not sure how to remove just the edit notice without affecting other parts of the page. βcommand 00:57, 28 September 2009 (UTC)
What will this change\effect, exactly?
V = I * R (talk to Ω) 02:09, 28 September 2009 (UTC)
It will simply involve adding some code to the edit notice pages, and will ony effect users who add certain code to their monobook.css files. — Jake Wartenberg 02:19, 28 September 2009 (UTC)
Disambiguation and BLP pages use edit intros that use code from MediaWiki:Common.js.---— Gadget850 (Ed) talk 02:19, 28 September 2009 (UTC)
We can insert this code there, too. — Jake Wartenberg 05:43, 28 September 2009 (UTC)

So we could not have [hide] links to easily dismiss an editnotice without developer intervention ? Cenarium (talk) 16:38, 28 September 2009 (UTC)


If some new user wants to create his/her own edit notice for his/her own user page or user talk page, what affect does this have on him/her? עוד מישהו Od Mishehu 08:41, 29 September 2009 (UTC)
I don't think there is consensus to have this affect userspace. — Jake Wartenberg 20:58, 29 September 2009 (UTC)

Merchandising

How about make a spheric puzzle in the shape of Wikipedia logo and sell it somewhere (maybe not even in a site related to Wikipedia, sell it on geek gadgets and toys sites) this way the profits could help a little with the costs. There are some nice spheric puzzles in the market.

Maybe plushies of Wikipedia logo, Wikipe-tan plushie/doll, etc could be done latter. Teruo (talk) 03:59, 26 September 2009 (UTC)

This is probably something you should contact the Wikimedia Foundation about. To be frank, I doubt that interest would be high enough. I'm sure WMF buys premiums (pens with logos etc) for handing out at conferences and such, but when ordering things like you're talking about you need to order a lot at a time, and the ROI probably wouldn't be that high. → ROUX  04:01, 26 September 2009 (UTC)
While I don't believe they have puzzles, there is a cafepress store for Wikimedia. Mr.Z-man 05:02, 26 September 2009 (UTC)
seems like they already made one http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_logos#Physical_versions
All they need is to make them in comercial scale! On another note, I think that store need more advertisement. Seems like it's not much known to the public. (my usermname was deleted by the system and I had to register again, is this "normal"?)Teruo (talk) 10:27, 28 September 2009 (UTC)

Kosovo naming convention revived

Because the manual of style for Kosovo has been outdated as a result of many factors (mainly independence and heavy disagreements) there is need for a new manual that would pave the way for naming standardization on Kosovo related articles.

Here are some examples of non-standardized usage of names:

  • Pristina (the capital) in its article has the name written with an 's', not 'sh' or 'š', but in many other pages the name is written with 'sh' or 'š'. (eg. here: "...was opened as one university in Yugoslavia, in the city of Priština...", or here: "...career in Tirana and the second one in Priština...", or here: "...households (94 in Priština...") — There are more easy to find examples just on Pristina that tend to be subject of edit-waring. Other cities that have the same problem are Pejë or Pec or Peja, Djakovica or Đakovica or Gjakova or Gjakovë... basically all cities with majority Albanian population. Other cities with Serbian majority (enclaves) seem to be more likely agreeable (see: Gračanica, Kosovo).
  • Another problem is the city infobox. In some cases the first name is written International/Albanian/Serbian (eg. Pristina), in other Serbian Cyrillic/Serbian/Albanian (eg. Vitina), other Serbian/Serbian Cyrillic/Albanian (eg. Đakovica)... This has been subject of heavy edit-waring as well.

A reasonable solution would be to use UN and OSCE naming convention: OSCE and UN, considering that there is no standard formula (Search results of most names have, approximately, similar results). —Anna Comnena (talk) 17:33, 27 September 2009 (UTC)

I was under the impression that the Pristina/Prishtina/Priština issue in particular was essentially resolved by this RfC. Is there a reason why the consensus there is no longer relevant? Happymelon 21:42, 27 September 2009 (UTC)
No, Pristina/Prishtina/Priština seems to be solid. However focus is needed on standardization of names and naming style, as other cities and municipalities use different ones (as shown on request). If this (Pristina/Prishtina/Priština) style is also set as an example for other Kosovo municipalities that it would be very helpful if noted somewhere. —Anna Comnena (talk) 21:52, 27 September 2009 (UTC)

How did Wikipedia forget to put Birth of Confucius 551 B.C.E. on the This Date in History Margin

Using Metacritic and other aggregators for albums

Hello, what I am proposing is using aggregator websites in the Professional Reviews tab of album pages when there are 1) No other reliable professional reviews or 2) on albums with only one reviewer. I hope to implement this to avoid bias, as an aggregator website can often give a better impression of an album than one done by a single editor, like say Allmusic.

Here is an example article,

Live '84.

Going through the Black Flag chronology reveals where this happens several times. Such as The Process of Weeding Out, The First Four Years, etc.

I used Black Flag because they are one of the strongest examples of this occuring.

It should be noted, however, that the practice of placing several different reviews by several different critics is just as effective. However it often seems that the catch-all for albums is AllMusic. I am simply proposing that shouldn't be allowed and aggregators be encouraged.

What are your thoughts on this?

--Iron Chef (talk) 00:25, 24 September 2009 (UTC)

You can always list the actual reviews that Metacritic references, right? —Noisalt (talk) 01:12, 24 September 2009 (UTC)

Since Metacritic pulls ratings from a peer list far greater than what can fit on Wikipedia, wouldn't it be easier and more accurate to use it? For example, if I were to go onto Metacritic to find reviews for 'Album', what if the four or five I pulled up were mostly negetive, even if the album recieved mixed to positive reviews? Wouldn't that be bias?

Would it be easier to sort through reviews until I find a couple that even themselves out, or just post the MetaScore for an accurate idea of what the critical community as a whole averaged it at?

--Iron Chef (talk) 03:38, 24 September 2009 (UTC)

I am inviting further discussion on this. --Iron Chef (talk) 19:40, 26 September 2009 (UTC)

There is a related discussion at Wikipedia:RSN#Review_aggregator_sites.  Skomorokh  19:46, 26 September 2009 (UTC)

Okay, enough ignoring this. Somebody explain to me why this shouldn't be used? It's the perfect tool to fight bias and takes the responsibility to aggregate reviews off of Wikipedia's editors and onto websites that practice it as their namesake! --Iron Chef (talk) 21:59, 30 September 2009 (UTC)

Hidden pages

There has been argument at Mfd about hidden pages. I strongly agree that they shouldn't exist on Wikipedia, as they serve no beneficial purposes in the project scope. Some say it violates WP:MYSPACE, others say WP:USERPAGE. I believe it violates both and this game is beginning to be my pet peeve. Many of those hidden page games consist of multiple subpages and that crowds the encyclopedia. I propose a guideline for this situation (sign books are heading the same direction) and get rid of the nonsense. ZooFari 03:02, 24 September 2009 (UTC)

To my mind the examples up for MfD are already in violation of WP:NOTWEBHOST, but maybe we need to add "web-based games" or some such to the specific list of things mentioned as inappropriate. --RL0919 (talk) 03:22, 24 September 2009 (UTC)
I agree, to an extent, but no page is really 'hidden'. You can bring up a complete list of a user's subpages with a prefix search.
Some users utilize subpages to great effect, but others do indeed border on WP:MYSPACE content. Then again, there's no significant performance hit when you compare 200k in one page to 200k across five pages (not that we're supposed to worry about performance anyway). --King Öomie 03:28, 24 September 2009 (UTC)
The problem in these cases isn't whether the pages are truly "hidden" or not. It is that the pages are just being used to play games, rather than do anything even remotely related to the encyclopedia. --RL0919 (talk) 03:54, 24 September 2009 (UTC)
I think that a change in policy should dictate that hidden pages should not be used for playing games, as they serve no purpose to the encyclopedia at all. warrior4321 03:57, 24 September 2009 (UTC)
I am not sure that we need any new guideline or change in policy, as opposed to a change in how existing policy is implemented. There is already plenty of documentation of the fact that this sort of thing is not acceptable. The most direct mention that I know of is the following, to be found in a list of examples of unacceptable matter in the user page guideline: Games, roleplaying sessions, and other things pertaining to "entertainment" rather than "writing an encyclopedia", particularly if they involve people who are not active participants in the project. That seems to me to quite unambiguously cover this. There are also, of course plenty more relevant statements, including the much-cited WP:NOTWEBHOST: Wikipedians have their own user pages, but they may be used only to present information relevant to working on the encyclopedia etc. Thus we already have plenty to say that this sort of stuff must not go on. In fact I am against adding still more specific prohibitions of this particular thing. Trying to legislate for each individual case that comes up is, in the long run, a losing game, as people sooner or later come up with some other similar and equally unacceptable behaviour which is not quite covered, so you add legislation for yet another special case, and the process never ends. Using the general principles already in place, which quite clearly cover this case, is much better. I think what we need is a mechanism for dealing with this more effectively. I think adding this to the speedy deletion criteria could be helpful. It wouldn't work miracles, not least because certain unhelpful Wikipedians would be there removing every speedy deletion tag they saw, but it might help to get rid of some of these pages more conveniently, and it might convey the message that it is really against Wikipedia consensus. Another idea which might help is this: Instead of proposing each case for deletion as we find them, collect a list of cases and then propose deletion in one go. This might this mean saving a good deal of frustration and effort by having one deletion discussion instead of many. Conceivably it might also send a more effective message to the hidden pages fraternity, if they found that quite suddenly their plaything had been seriously hit. Some sort of task force or patrol group might be suitable. Any thoughts? JamesBWatson (talk) 08:56, 24 September 2009 (UTC)
  • I just think they're a big waste of time. We don't have a real space limitation, but as pointed out above, there's no point in making a "hidden" page game if Special:PrefixIndex will find it. Ten Pound Hammer, his otters and a clue-bat • (Many ottersOne batOne hammer) 13:11, 24 September 2009 (UTC)
One of the MfD participants has pointed out WP:UP#Games, which already contains a specific guideline against hosting games in userspace. So there shouldn't need to be any further specification required on that front. I support JamesBWatson's suggestion above that such pages should be added to the criteria for speedy deletion. Doing repetitive, lopsided MfDs for these is a waste of effort. --RL0919 (talk) 13:30, 24 September 2009 (UTC)
I would support a speedy criterion for these as well, so long as we can decide on what constitutes a game. Ten Pound Hammer, his otters and a clue-bat • (Many ottersOne batOne hammer) 13:38, 24 September 2009 (UTC)
  • Yes, I agree that WP is not MySpace or a webhost. However, when personal computers started becoming common in corporate America in the early 1990s, many managers, executives, and IT departments opposed and often removed games from Windows, especially the Solitaire game included with every copy of Microsoft Windows, claiming they were non productive. What they forgot was that playing Solitaire with a mouse increased hand-eye coordination, a Good ThingTM, as it made them more productive for real work. I was able to get my aged father to learn to use a computer by playing Solitaire. Yes, hidden pages, and awarding barnstars for finding them, is not directly related to writing articles, but if not abused, it can give newbies a chance to do some editing that doesn't hurt actual articles. I don't oppose making it a PROD criteria (I think CSD is too quick on the trigger), but lets use it sparingly, at least when a young user starts out, per WP:BITE, unless it's fairly clear the user has no intention of contributing and most likely never will. Maybe we can get some productive editors that way, rather than pushing them away. We all didn't start out knowing the WP edit window, markup language, subpages, and so forth. Playing around is learning, at least initially. So lets exercise some judgment about this rather than proscribing it arbitrarily and totally. [Full disclosure: I won one such barnstar, but it has nothing to do with my argument.] — Becksguy (talk) 15:57, 24 September 2009 (UTC)
Best of luck with this round six. bahamut0013wordsdeeds 16:00, 24 September 2009 (UTC)
These pages are not mentioned in the speedy deletion criteria now. That doesn't mean they shouldn't be, which is something for the community to decide. Consensus can and does change, so we'll see how this round of MfDs goes. One has already closed as "delete". --RL0919 (talk) 05:19, 25 September 2009 (UTC)
  • Why do we care so much about this? We are not actually paying any of these guys so it is only their own time they are wasting. There are plenty of vandals and trolls to hunt down in article space. What is going on in user space is largely irrelevant to our readers. It is even irrelevant to those editors who just want to do "serious" work. Unless it starts to interfere with article writing or an account is doing nothing but playing games it is a waste of effort to police it. SpinningSpark 16:14, 24 September 2009 (UTC)
  • That's a reasonable argument on its face, but it's an argument against WP:NOTWEBHOST in its entirety. The problem is that they're using server space and bandwidth paid for by the Foundation for their own entertainment, without regard for what the Foundation actually wants it used for. --King Öomie 16:25, 24 September 2009 (UTC)
  • Give me a break, the amount of storage required for all these pages added together is minuscule. More server resource has been used up discussing them than they are actually wasting themselves. They are all very short, text-based pages. WP:NOTWEBHOST is aimed at people using their account to set up a free web site or to host their holiday snaps or to promulgate their own POV or OR. It is not aimed at editors indulging in some harmless amusement - as is shown by its specific exception for humorous pages. SpinningSpark 16:40, 24 September 2009 (UTC)
  • Eye-rolling sarcasm really isn't required. If I've missed your point, just tell me.

    The focus of user pages should not be social networking, but rather providing a foundation for effective collaboration. Humorous pages that refer to Wikipedia in some way may be created in an appropriate namespace, however.

  • I take it you're referring to this passage. Would you care to clarify how 'hidden' userspace pages are 'appropriate namespace', or even related to Wikipedia? Links of funny diffs are one thing- userspace scavenger hunts have absolutely no relevance to the encyclopedic 'portion' of this site. --King Öomie 16:58, 24 September 2009 (UTC)
The only part of my post that could be described as unnecessary was "give me a break". I am quite good at eye-rolling sarcasm but I am fairly certain that is not it. And yes, that is the passage I was referring to, although you seem to have contrived to mistakenly omit the key words in it. SpinningSpark 17:57, 24 September 2009 (UTC)
I posted the second half of the relevant paragraph exactly as it appears, the only part that seemed relevant. The first part states specifically that userspace is only to be used for the improvement of the encyclopedia, and that any other ventures are to be taken outside wikipedia- I don't see how it agrees with your statement, unless you're misinterpreting the meaning of "hosting included with your Internet account". I certainly didn't contrive to do anything, and I really don't appreciate your attitude. --King Öomie 18:30, 24 September 2009 (UTC)
I apologize; I see I incorrectly fixed a category link when I corrected the broken URLs (omitted the leading colon)- leading to the appearance of missing text. I didn't notice at first, because the text certainly appeared in the edit window. --King Öomie 18:48, 24 September 2009 (UTC)
Thanks, that's saved me having to use my killer sarcasm again. I concede that this game cannot be argued to be directly Wikipedia useful. My point is not that; my point rather is that it really doesn't matter and we shouldn't waste our time on it. SpinningSpark 18:56, 24 September 2009 (UTC)
Do I detect sarcasm in your description of sarcasm? Wait...
Kind of like arguing the nuances of the meaning of the word "semantics". --King Öomie 19:06, 24 September 2009 (UTC)

Quite the oposit, I support WP:Secret Pages as a real rule.--Coldplay Expert 19:11, 24 September 2009 (UTC)

I can't believe this game has its own cheatsheet. That's a real shame. ZooFari 00:03, 25 September 2009 (UTC)
Support it as a rule? The essay doesn't advocate anything, it just gives the history of the debate and a summary of the supporting and opposing viewpoints. I've tried to simply tell users what the game entails as well as a neutral summary of the controversy surrounding it. I woud hardly describe an essay describing the game a cheatsheet, as that information would certainly be of interest to both supporters and opposers. bahamut0013wordsdeeds 04:51, 25 September 2009 (UTC)

See Wikipedia:Why do you care? for reasons why people worrying about productive users use of userspace is bad for the project. --SmokeyJoe (talk) 14:41, 25 September 2009 (UTC)

The bottom of this page at #The Use of the word "as," instead of because or since has degenerated into a very juvenile game of punctuation (had had had had.... buffalo buffalo buffalo buffalo.... etc etc etc etc) which is in no way connected with improving the encyclopedia and, I notice, has involved editors who in this post are vehemently opposed to the "secret pages" game. Is someone now going to propose deletion of the Village Pump page because it is being used for playing games? No, of course not; let it be, everyone plays games sometimes, even those who claim to be above it. SpinningSpark 16:14, 25 September 2009 (UTC)

No one is going to suggest that, because that would be stupid. I might toss Wikipedia:Village pump (policy)\Signbook up on MFD though. This discussion is about pages created and maintained for the sole purpose of screwing around in a manner entirely unrelated to the encyclopedia. Casting it in any other light is purely hyperbole. --King Öomie 16:19, 25 September 2009 (UTC)

(out) - "Yes, hidden pages, and awarding barnstars for finding them, is not directly related to writing articles, but if not abused, it can give newbies a chance to do some editing that doesn't hurt actual articles." (Becksguy above) I agree with this 100%, because that is what got me involved on Wikipedia in the first place (2006). Sure, I left for 1 1/2 years after that, but I came back and I hope that I am helping the project a lot now. ;-) —Ed (talkcontribs) 23:55, 25 September 2009 (UTC)

I agree. Within reason of course, we should be welcoming to newbies and allow them to get their "feel" of the place. What better way than to introduce themselves socially to other like-minded editors through guestbooks and a few hidden pages? Finding their way around this anonymous and sometimes intimidating place is for some people the first step toward great future contributions. Dr.K. logos 04:49, 26 September 2009 (UTC)
My primary concern here is the attitude of either entitlement or ignorance that often comes from the people maintaining these pages. "It's my user page I can do what I want" is the usual refrain. If these MfDs/deletions raise awareness that we actually do have policies about userspace, then I'm all for that. This is all even more important because user space remains indexed, and is a "public face" of Wikipedia. At the same time, my bar would be pretty low. A game that was related to the encyclopedia in a way other than "uses wiki markup", and was otherwise inoffensive, I'd probably say keep. Gigs (talk) 04:54, 27 September 2009 (UTC)

The Use of the word "as," instead of because or since

I have noticed a trend of using the word 'as' instead of since or because. This is improper grammar and is not scholarly, though this is what we attempt to show with it/— Preceding unsigned comment added by 137.54.26.68 (talk) 18:34, September 24, 2009 (UTC)

Then correct it where you see it. This would be more apropos for Wikipedia Talk:Manual of Style. --King Öomie 18:36, 24 September 2009 (UTC)
"Improper" grammar according to whom? And what exactly makes it "improper", anyway? Regardless, Kingoomieiii is correct, the MOS is the more appropriate venue for this sort of discussion.
V = I * R (talk to Ω) 19:16, 24 September 2009 (UTC)
I'm thinking this is anecdotal from someone's English teacher. I'd love to see a cite to this effect, though- I'd hate to think I'd been using incorrect English for years (no snarky response from the more nationalistic Brits required =P) --King Öomie 19:21, 24 September 2009 (UTC)
Damn. - Jarry1250 [ In the UK? Sign the petition! ] 19:25, 24 September 2009 (UTC)
I shall hide behind WP:ENGVAR! --King Öomie 19:29, 24 September 2009 (UTC)
I'm no prescriptivist, but I think (contrary to what the IP suggests) that "as" is a whole lot better style than "since". They're both time-related words that have been co-opted to refer to causality, but lots of serious writers use "as" for this purpose while few use "since". "Because" is also fine, of course. rspεεr (talk) 03:01, 25 September 2009 (UTC)

An example, please? Or was this an IP hit-and-run? →Baseball Bugs What's up, Doc? carrots 21:10, 24 September 2009 (UTC)

Meanwhile, punctuate this sentence:

John where Bill had had had had had had had had had had had the teachers approval.

Baseball Bugs What's up, Doc? carrots 21:13, 24 September 2009 (UTC)

John! (clap clap) Where Bill! (clap clap) HAD! HAD! HAD! HAD! HAD! HAD! HAD! HAD! HAD! HAD! HAD! (Drum fill) ...THE TEACHERS APPROVAL! (Dueling guitar solo) --King Öomie 21:24, 24 September 2009 (UTC)
Also, "He never intended to live in the woods, as he was allergic to Oak." --King Öomie 21:26, 24 September 2009 (UTC)
Yep, a good example, as I write that way all the time. :)
John, where Bill had had "had", had had "had had"; "had had" had had the teacher's approval. →Baseball Bugs What's up, Doc? carrots 23:26, 24 September 2009 (UTC)
This is a prime example of word efficiency at the expense of readability. Even with punctuation I had to read that twice. --King Öomie 12:58, 25 September 2009 (UTC)
It's just wordplay. It's not likely you'd see a sentence like that in real life. Although I've received some e-mails from the business that were less clear. →Baseball Bugs What's up, Doc? carrots 15:19, 25 September 2009 (UTC)
Which is a variant on the actual article James while John had had had had had had had had had had had a better effect on the teacherBaseball Bugs What's up, Doc? carrots 08:19, 25 September 2009 (UTC)
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo. My favorite blue link of all time. Carry on. --Jayron32 02:47, 25 September 2009 (UTC)
Vis a vis truck trucks truck trucks truck trucks truck? — Carl (CBM · talk) 02:56, 25 September 2009 (UTC)

"Causal as is a standards and acceptable alternative to because and since but is used less frequently than either." Merriam-Webster's dictionary of English usage. SpinningSpark 17:09, 25 September 2009 (UTC)

Excellent! Feeling good, as my usage is vindicated by Webster. :) →Baseball Bugs What's up, Doc? carrots 17:11, 25 September 2009 (UTC)
Damning with faint praise there, bunny. → ROUX  03:21, 26 September 2009 (UTC)
Gosh, does MW give advice on what's acceptable? It's creeping prescriptivism, I tell you! Pseudomonas(talk) 11:31, 26 September 2009 (UTC)
  • "As" is not "improper grammar" (some moralistic attachment there?): it's just a badly engineered word in English, and particularly troublesome for non-natives. Sometimes it's impossible to determine, even from the larger context, whether it means "while" or "because". Drop it, mostly, is my advice, and use "since" or "because". Tony (talk) 07:53, 1 October 2009 (UTC)

RfC to increase the default thumbnail size of images

It was set at 180px many years ago. There is prima facie evidence of considerable support to increase this, probably to 220px. Please have your say here (initial discussion above on that page). Tony (talk) 07:46, 1 October 2009 (UTC)

Arbitration Committee code of conduct

Proposal at Wikipedia:Arbitration Committee code of conduct. Input would be appreciated. SlimVirgin talk|contribs 09:48, 1 October 2009 (UTC)

Request for working group on images of biographical subjects

There are a number of biographies where, if you go to the talk page, you can see a request that a picture of the person should be inserted. At times, if one then goes to Google Images and types in the person's name, you can see a lot of pictures of the person are on the web - although some of them might be copyright, others may well be in the public domain. Can I request that a working group is formed on Wikipedia to look after insertion of images of people? Obviously, this would need to involve people who are skilful at downloading images; also, the group could ensure that any images which have been put on Wikipedia which are NOT in the public domain, i.e. are copyright, get deleted. This could be a good challenge for some technologically able Wikipedians. The group could function to ensure pictures of people are updated and do not violate any rules of copyright. ACEOREVIVED (talk) 23:03, 29 September 2009 (UTC)

Sounds to me like a Wikiproject. Every element of your idea is currently performed by some dedicated group of people - we have a copyright noticeboard for questionable images/content, for example. The only element not present is an organised group of people trawling for images. Since that's a relatively minor thing, I'd suggest you should set it up yourself as a Wikiproject if you can get others interested. Ironholds (talk) 00:07, 30 September 2009 (UTC)

Thank you, I have wondered whether this is better served as a task force within the WikiProject group on biographies (I have left a request on the talk page there). ACEOREVIVED (talk) 21:29, 2 October 2009 (UTC)

There is an open RFC dealing with the mechanics of policy creation. It needs some input. Wikipedia_talk:User_categories#Guideline status. SchmuckyTheCat (talk) 20:51, 1 October 2009 (UTC)

Video tutorials—viability?

I'm really interested in creating some tutorials on using Wikipedia. I haven't really fleshed out this idea yet, but I would probably combine screen recording with voice over, and produce short clips of a few minutes on different areas and aspects of editing. I'd start with the basics, of course, but I could move on to introducing things like adding inline citations, uploading images, DYK review, etc.

I discussed this with another editor, and he pointed out that flash would probably work best for screen capture, and that it isn't supported on WP. Hurdle number 1. Assuming that I could use an alternative to flash that would be supported on WP, would the community accept video embedded on Help pages? If it couldn't be embedded, would it be ok to host the videos elsewhere and link to them from help pages? Instead of embedding help pages with videos specific to the content (which would be restricting for me), would it be viable to create a separate help page devoted to the videos? Would the community want to vet them first? How would it be established that they were appropriate?

Another aspect I am wondering about is privacy concerns. Would there be objections to screen shots that would, inevitably, show dozens of user names and some of their associated edits? Would I have to cover up the WP logo?

Has this idea been tried or suggested before and failed?

I hope that's not too many questions for one post! I'm really curious to know if this would work and am interested in hearing feedback. I really think that videos could help us retain editors who find WP initially bewildering. Plus, it would be fun to make them! Also posting to Village pump (technical) Maedin\talk 18:40, 2 October 2009 (UTC)

Black background to save energy

I want to suggest a modification in Wikipedia's background color from white to black (and the font from black to white and from blue to yellow) as a means of saving energy. You could even also do as blackle.com does and publicly announce the amount of energy being saved.— Preceding unsigned comment added by 141.156.143.89 (talk) 00:23, September 18, 2009 (UTC)

Using black backgrounds doesn't significantly save energy, all studies show variable results. Using all upper-case letters has, however, been proven to kill unicorns. --Golbez (talk) 01:32, 18 September 2009 (UTC)
You can easily create your own custom skin by creating a css file for your login... if you login.
V = I * R (talk to Ω) 01:27, 18 September 2009 (UTC)
With modern LCD monitors, the difference is trivial — and some LCDs may actually use less power when displaying white compared to black: [19]. If you really want to save some electricity, shut down your computer and go outside — quit wasting time on Wikipedia. TenOfAllTrades(talk) 14:37, 18 September 2009 (UTC)
Pretty much a myth Five Myths and Mysteries About Black Web Surfing. --SPhilbrickT 15:35, 18 September 2009 (UTC)

That article concludes the opposite of what you seem to think it says.

As I read that article (and I'm not judging either way), it says that because Cathode Ray Tube (CRT) monitors use so much more energy overall than Liquid Crystal Display (LCD), there would be a measurable and perhaps significant overall energy savings if many popular sites (or the web in general) switched to black backgrounds. Looking at Blackle myself with old eyes on a relatively-small, unadjusted desktop Flat Screen (Compaq FS7600), I found the type too faint and small to read. And those old eyes belong to someone who's been around long enough to have used white or green on black monochrome screens at school (Tandy Radio Shack 64 - 256K) and at work as a BASS TicketMaster operator, and that contrast can be tiring to the user. In fact I often tweaked the screen to make the background light green and the type black. Much more restful, when set dimly enough. —— Shakescene (talk) 05:58, 20 September 2009 (UTC)
Someone actually made Wikipedia mirror with black background a while ago: [20]. It seems to only mirror part of the content. --Apoc2400 (talk) 19:02, 18 September 2009 (UTC)
Special:Preferences → Gadgets → User interface gadgets → Use a black background with green text on the Monobook skin. ---— Gadget850 (Ed) talk 23:34, 18 September 2009 (UTC)

I should rename this thread "black is the new mauve"… — CharlotteWebb 00:26, 21 September 2009 (UTC)

HEY GOLBEZ, I JUST KILLED A UNICORN!Camelbinky (talk) 22:36, 25 September 2009 (UTC)
Trying out the black background right now; why do I suddenly feel like James Bond? --Dylan620 (contribs, logs)help us! 00:06, 26 September 2009 (UTC)

The suggestion shouldn't be dismissed so glibly. So the difference would be "trivial" for LCD's? So what? A difference is a difference, the argument from "trivial" savings can be used with anything; in the aggregate the savings might be substantial. (people always make this kind of "it's just a drop in the bucket" argument against economy, ignoring the fact that, guess what, buckets can actually be filled by drops.) Webpages are increasingly being viewed on all sorts of displays, not just LCD's, some of them extremely large, many of them rarely shut down. Unless you can show that a dark background uses more energy, the objections to the suggestion aren't convincing. Wikipedia and Google should try dark backgrounds. They're easier on the eyes anyway.

Not only black backgrounds, but all text in green typewriter font. Nostalgia! →Baseball Bugs What's up, Doc? carrots 04:25, 27 September 2009 (UTC)
Baseball Bugs, I have an even better idea! We can all edit using BASIC in MSDOS, forget mouses and Windows! Imagine the savings in electricity if every Wikipedia editor didnt plug in a mouse!Camelbinky (talk) 23:55, 2 October 2009 (UTC)
MSDOS? That wasn't released until 1982. Use a real operating system! I learnt to program using BASIC on CP/M, and I'm only 22... --Tango (talk) 00:00, 3 October 2009 (UTC)
Actually 1982 is probably the first year I started actually using a computer, Commodore 64; used Commodores all my life right up through Amiga 3000. Then it has been Compaq or Dell ever since. I never knew someone your age who even knew what CP/M or BASIC even meant let alone used it in real life!Camelbinky (talk) 00:22, 3 October 2009 (UTC)
I learned PC's and BASIC at the then brand-new Vista College in the early 1980's on 64k–512k Radio Shack computers that used TRS-DOS. But I didn't learn much of TRS-DOS itself. Then (since the WordStar discs had all been answered for), I learned the utterly-useless MultiMate (to replicate the Wang word processor on IBM) on Peanut (IBM PCjr) terminals without the template, thus having to memorize even-more-useless codes like Alt-Shift-7 for things like "move paragraph". —— Shakescene (talk) 00:55, 3 October 2009 (UTC)
This has come up many times before. See, among others, here, here, here, here, here, here and here.--Fuhghettaboutit (talk) 01:28, 3 October 2009 (UTC)

Turning Autoconfirmed into an explicit usergroup

Please note that the software would automatically promote users with 10 edits and 4 days, and only the software.

Autoconfirmed is an implicit permission, that is, I gather, the software checks if the user meets the autoconfirmed requirements (10 edits, 4 days on enwiki) whenever a restricted action is performed, and when linking restricted actions (e.g., the move tab). So it's unlike rights like Sysop, Rollbacker, etc. Not being an explicit permission has several downsides, for example it's difficult to check if the user is autoconfirmed or not (especially for non-admins who can't see deleted contributions, and even more with the edit filter, capable of removing autoconfirmed status), we don't know easily how many users are autoconfirmed, etc. However, it is now possible for the software to automatically assign a userright when certain conditions are met. This change would offer many advantages: easier to know if an account is autoconfirmed, number of autoconfirmed accounts at Special:Statistics, the list of all autoconfirmed accounts at Special:Listusers, scripts and bots can use this information, and also, automatic promotions would be logged at Special:Log/rights (and noted in recent changes), an example entry would be:

I think the removal of the autoconfirmed permission by the edit filter, and possible restorations, could also be logged. In July, the confirmed usergroup was created to allow admins to grant permissions associated to autoconfirmed before the automatic promotion, maybe we should rename this group to "preconfirmed", as confirmed alone could be unclear. If there's consensus for this change, it'll be requested at bugzilla. Cenarium (talk) 01:53, 20 September 2009 (UTC)

*Totally, completely, irrevocably, Opposed. I dont' think that there could possibly be a good reason to do this, so admittedly I'm very biased against the idea, but I don't see any real reason given above to do this now regardless. Sorry, I'm sure you're an intelligent person and a valuable editor, but this is a Bad Idea.
V = I * R (talk to Ω) 02:11, 20 September 2009 (UTC)

  • You seem to have misunderstood, I never proposed that admins should be allowed to grant or remove Autoconfirmed. The promotions will be done automatically by the software. It's nothing but a cosmetic change. Which disadvantage would you find over the current system ? Cenarium (talk) 02:22, 20 September 2009 (UTC)
    ...OK, obviously I'm completely misunderstanding the intent here. I just re-read the original post again though, and I don't see where. You bolded a statement saying that essentially nothing would change, but then the proposal still essentially talks about removing the software mechanism to assign it. I'm confused.
    V = I * R (talk to Ω) 02:31, 20 September 2009 (UTC)
    The software checks if the user meets the autoconfirmed requirements every time an action is made, as opposed to checking if the user is in a usergroup. It's proposed that instead, the software automatically assigns the autoconfirmed userright when the conditions are first met, so it will give us all the advantages of an (explicit) permission, but change nothing in who gets the permission. So for example, we'll have (autoconfirmed) in Special:Listusers, the number of autoconfirmed users at Special:Statistics, bots and scripts will be able to use the data, we'll know when a user is granted autoconfirmed, so vandals, disruptive users, sockpuppets aiming to become autoconfirmed may be 'exposed', etc. Cenarium (talk) 02:45, 20 September 2009 (UTC)
    Ahhhhhh, got it. The thing is, this isn't really Wikipedia related (other then the fact that Wikipedia obviously runs on top of MediaWiki), which probably one reason for confusion. This seems to be a purely technical, and efficiency related, change request to me. It would change the way that Wikipedia operates slightly, but not in any really meaningful manner as far as I can tell. Just go ahead and start a bug report for it.
    V = I * R (talk to Ω) 03:17, 20 September 2009 (UTC)
    It's best to discuss beforehand, some may have objections on specific parts, for example logging because 'it would clog the user right log', although a filtering may be possible. Also if there's a definitive support, the developers will likely pay more attention and be more motivated (as I expect this change would require non-negligible technical work). Cenarium (talk) 03:46, 20 September 2009 (UTC)
    Generally I agree, but in this case it sounds like you could make an efficiency argument. I'm not that familiar with the MediaWiki internals (or PHP, to be honest), but the way that you're describing this here it sounds as though edits are currently an O(n) operation based on number of users. I'm not positive that logging the autoconfirmed property would turn that into an O(1) op, but I can't imagine that it would do anything but improve performance (obviously the actual cost of "n" is so miniscule as to be basically negligible, but still...).
    V = I * R (talk to Ω) 05:21, 20 September 2009 (UTC)
(edit conflict) Hmm... interesting. However, I see the userrights log as being just oversight to keep admins and 'crats from making improper promotions. In popups, it shows the date registered and edit count, so I can very easily see if the user is autoconfirmed. Honestly, there aren't enough not-autoconfirmed users for this to be a problem.--Unionhawk Talk E-mail Review 02:13, 20 September 2009 (UTC)
See above reply. It's a problem for bots, scripts, relying or analyzing data on autoconfirmed users, etc. Popups can't see deleted versions AFIAK, and doesn't know if the edit filter has removed the autoocnfirmed status. It would be a strong benefit for anti-vandalism purposes. Cenarium (talk) 02:22, 20 September 2009 (UTC)
Also there are something like 633,500 autoconfirmed users, compared to 10,564,920 users, so there are approximately 9,931,420 users who aren't autoconfirmed, it's a lot. Cenarium (talk) 02:45, 20 September 2009 (UTC)
So how many of them have 1–9 edits? I think the criteria are too trivial for the corresponding data to be of any practical use. Unless there is also some new option to ignore certain promotion types, the user-rights log would become completely useless—being flooded by every user's 10th-edit bar mitzvah. — CharlotteWebb 03:48, 20 September 2009 (UTC)
Well, they may not be logged at all then, if it can't be filtered, or maybe logged separately, but it would be useful for certain users in dealing with vandalism I'm certain. As for the data itself, it would be of use, for example see here (for scripts), and also for statistical purposes, and analyzing the population of autoconfirmed users (as of now, it's especially cumbersome). And it would also make sure the edit filter doesn't remove a userright and nobody knows about it except by directly checking the edit filter log; in the new configuration, a removal of autoconfirmed by the Edit filter would appear in the user right log. Cenarium (talk) 04:03, 20 September 2009 (UTC)
Well, out of those 9,000,000 not-autoconfirmed, 63 are confirmed, and probably over 8,000,000 created an account but never use it.--Unionhawk Talk E-mail Review 04:09, 20 September 2009 (UTC)
My point is that there are so many autoconfirmed users and so few things that autoconfirmation does that it has very little practical use.--Unionhawk Talk E-mail Review 04:12, 20 September 2009 (UTC)
Actually it's about 5 million accounts there were created but never used. Dragons flight (talk) 04:22, 20 September 2009 (UTC)
So it makes a little less than 5 million accounts with edits but not autoconfirmed, compared to circa 633,500 autoconfirmed users. The autoconfirmed threshold is not only additional permissions, but also clearance from anti-vandalism and anti-spam measures (edit filter, captcha, etc), it's important to be able to distinguish it. Cenarium (talk) 04:38, 20 September 2009 (UTC)
I totally agree, it is useful and important for a user's autoconfirmed status to be easily and reliably determinable by bots, scripts and humans. Happymelon 10:11, 20 September 2009 (UTC)
  • Comment. I do not see any problem with deleted contributions. As I know they do not count to autoconfirmed status. So, if a user has 10 contributions and all of them are deleted, then the user is not autoconfirmed. Ruslik_Zero 11:20, 20 September 2009 (UTC)
    Brion said here that it's based on the edit count, which counts all edits performed, even if subsequently deleted (the one in Special:Preferences). It may have changed since but I don't think so, as if only non-deleted edits counted, a user could be autoconfirmed at a time, then no longer when some of the articles they edited is deleted, then again, so it wouldn't be stable. Cenarium (talk) 12:35, 20 September 2009 (UTC)
    Here I read smth different. Ruslik_Zero 13:01, 20 September 2009 (UTC)
    I have moved a page with this account which had only two non-deleted edits at the time, so deleted edits are included in the count. However there's the TOR issue, which makes the current autoconfirmed permission unstable, in my opinion autoconfirmed should be stable. If it's granted after 90 days and 100 edits to users when using a TOR network, it won't change very much from the current situation. Cenarium (talk) 14:47, 20 September 2009 (UTC)
Well, I was mistaken about deleted contributions. Still I think it will not be helpful if promotions to autoconfirmed status are shown in the userrights log—they will simply overwhelm it. What would be useful, however, is additional information on Special:Userrights page: if an account is autoconfirmed and when, if its autoconfirmation is suspended by an abuse edit filter. This page should also have a button allowing administrators to reautoconfirm the account. (currently this is located on Special:AbuseFilter/tools.) Ruslik_Zero 18:28, 21 September 2009 (UTC)
I think the best would be to be able to hide automatic promotions, like we can hide patrols, maybe default hidden; I think it's possible if there's a specific log_action 'autopromote' for automatic promotions.
If autoconfirmed becomes a userright, it'll be shown in Special:UserRights, but we won't be able to modify it (probably best to keep using (pre)confirmed for users wishing some autoconfirmed rights before autoconfirmation, and I don't think we'd have consensus to allow admins to remove autoconfirmed). We could explain how to restore autoconfirmed when it's been suspended by the edit filter in MediaWiki:Userrights-groups-help. I don't know how the filter would remove autoconfirmed, if it suspends it like how it does now, or would remove then restore the right. It's not particularly important, though, as we don't use the action Block autopromote for now. Cenarium (talk) 17:23, 23 September 2009 (UTC)

Also, what do you think on renaming 'confirmed' to 'preconfirmed' ? Cenarium (talk) 17:23, 23 September 2009 (UTC)

  • I had a look through bugzilla and it seems we really need a consensus for this change to be completed by the devs, I'd request more comments (also on renaming confirmed to preconfirmed). Thus added to Cent. Thanks, Cenarium (talk) 23:11, 27 September 2009 (UTC)
  • Support Both ideas sound fine. But would it be possible to simply allow admins to grant the autoconfirmed right, if not remove it? — Jake Wartenberg 06:28, 28 September 2009 (UTC)
    As we have the confirmed usergroup, it wouldn't be necessary. It would no longer be 'auto' too, so it could be confusing, or we would have to rename but it may be difficult, because autoconfirmed is very much embedded in the system. It would also be safer from a security viewpoint to keep the rights separate. Cenarium (talk) 12:43, 30 September 2009 (UTC)
  • If it's not too much trouble to add, I imagine it could be handy from time to time, specifically relating to scripts, bots, and AbuseFilter actions. Discussion above already seems to cover most issues that come to mind for me, all but one: we'd be doing this in such a way that it doesn't flood the user rights log too horribly, right? – Luna Santin (talk) 23:58, 30 September 2009 (UTC)
    I'm fairly certain developers can develop a filter for autopromotions, probably using a LOG_ACTION for those, there's actually T19293 for filtering all logs by log action, and they could even hide autopromotions by default (like the patrol log); but it may take time to be finalized. Well, I think there's consensus so I'll open a bug soon for this. Cenarium (talk) 00:07, 3 October 2009 (UTC)

Introduction of de:Wikipedia:WikiProjekt Metadaten to en-WP

Hello together, are you interested in the introduction of the de:Wikipedia:WikiProjekt Metadaten (WikiProject Metadata) to en-WP? The purpose of this project to centralize often changing data (e.g. population numbers) in so calles Metadatenvorlagen (metadata templates) (e.g.: de:Vorlage:Metadaten Einwohnerzahl AT-1, see source code: [21]. By embedding these templates into articles (directly or also via infoboxes) these data are automatically updated by update of the templates. Technically the templates are based on the switch-command. Regards --Septembermorgen (talk) 11:17, 26 September 2009 (UTC)

Definitely a long-overdue idea. Hope it can be made to work.--Kotniski (talk) 11:38, 26 September 2009 (UTC)
Can someone run off a rough translation or precis it into English so us non-German-speakers know what's being discussed? The description above looks very good. Pseudomonas(talk) 13:41, 26 September 2009 (UTC)
(Technically I always feel this sort of thing shouldn't be called "metadata" though - to me that would mean data about data - but the idea's great.)--Kotniski (talk) 13:55, 26 September 2009 (UTC)

I'll try to make a rough translation until tomorrow, though my English got a little bit rusty. --Septembermorgen (talk) 19:22, 26 September 2009 (UTC)

I'd definitely be curious how this works. Hopefully we can get a translation because this does sound like a worthwhile task.↔NMajdantalk 16:25, 28 September 2009 (UTC)

Here's a rough translation: Wikipedia:WikiProject Metadata. It may serve as basis for discussion. --Septembermorgen (talk) 19:26, 28 September 2009 (UTC)

Still in the early phases of this, but progress is being made. The template {{Meta-Population}} has been created (it might be renamed) and it has been populated with Oklahoma data. So, giving {{formatnum:{{Meta-Population|USA|OK|Tulsa}}}} now returns 385,635.—NMajdantalk 23:54, 2 October 2009 (UTC)

Radical suggestion against vandalism

Hi, i have a quite radical but very effective suggestion against the vandalism on Wikipedia. Let only registered users be able to do edits. Non-registered users like it is today stands for more than 60%-70% of the vandalism here i would guess and that would be mutch less vandalism if only users with user pages could do edits. I think i have warned like 70-80 non-registered users in the last 2-3 months not and only 2-3 registered users. English wikipedia has become to big in my opinion to have no restrictions on who gets to do edits. This suggesiton would also make it a mutch better chance that the registerated user actually wants to do good for wikipedia as most vandalisers would not take the time to register.--Judo112 (talk) 16:26, 15 September 2009 (UTC)

While I'd love to see it, even for a week, this proposal will be shot down like a spy plane over China. --King Öomie 16:29, 15 September 2009 (UTC)
Not going to happen, unless I have accidentally logged in to the Mirror universe Wikipedia. Sorry. Shereth 16:31, 15 September 2009 (UTC)
Can we give admins more latitude to ban editors who are being disruptive? A Quest For Knowledge (talk) 16:39, 15 September 2009 (UTC)
This is a suggestion that is made perennially. It never has passed consensus. My guess is that it never will. One argument against this sort of restriction is that, if a user is truly bent on vandalism, they would register first. Then where would we be? At least now you can be suspicious when all you see is an IP number. --Tim Sabin (talk) 16:45, 15 September 2009 (UTC)
See Wikipedia:Perennial proposals#Prohibit anonymous users from editing. TenOfAllTrades(talk) 16:46, 15 September 2009 (UTC)
IPs are responsible for the majority of worthwhile content on this site - that bears reminding every time this comes up. Losing them would stop enWiki in its tracks. ~ Amory (usertalkcontribs) 16:49, 15 September 2009 (UTC)
I would personally be interested in hearing a serious defense towards implementing this idea. I've wondered for a while now what the big deal with vandalism really is. I mean, it occurs, and it is sort of annoying, but... so what? Why is any attempt at preventing vandalism necessary? I'm not being flippant here or anything, I'm simply interested in trying to understand this viewpoint is all.
V = I * R (talk to Ω) 19:55, 15 September 2009 (UTC)
Being proactive would mean we didn't have to be reactive, fixing damage after it's done. - Denimadept (talk) 20:02, 15 September 2009 (UTC)
That's exactly what I'm asking about though. Why should we be proactive? What's wrong with being reactive to vandalism?
V = I * R (talk to Ω) 21:09, 15 September 2009 (UTC)
Ever worked on an article that gets lots of sneaky vandalism mixed in with good edits? Just reverting everything would frustrate the good editors, but sorting through all the intermediate edits would take inordinate time. These two common reactive strategies are less-than-ideal in such a case. Gimmetrow 21:18, 15 September 2009 (UTC)
What I find amusing is that the OP didn't follow the instructions at the top of this page. :-> - Denimadept (talk) 21:28, 15 September 2009 (UTC)
Yes, I have worked on articles that are subject to vandalism, although I suspect that what you qualify as "sneaky vandalism" is more likely to often actually be content issue(s).
I should clarify that by stating that I don't recall ever talking with you prior to this, and I'm not intentionally leveling any accusations. That statement is really a more general observation then it's written as, since in my perception editors often tend to label content disputes as vandalism, likely out of a desire to win points for their position.
You're absolutely correct that reverting a series of edits is not normally a good practice (I would say that it never is, but I'm sure that there is the rare instance where it could be warranted). This still doesn't address the question that I'm posing however: why should any of us proactively try to prevent "vandalism" at all? What is wrong with being reactive? It may be difficult to straighten out occasionally, but so what?
V = I * R (talk to Ω) 21:37, 15 September 2009 (UTC)
Are you personally volunteering to do any and all work necessary to reactively handle all vandalism on this site? Nobody has any right to be generous with other people's time cleaning up vandalism. Preventing what vandalism can be prevented in the first place would be a good thing. Gimmetrow 22:03, 15 September 2009 (UTC)
I clean up vandalism all the time. I disagree with pretty much any "preventative" measures but whatever, if this is going to become some sort of emotional, personal issue, then I'd really rather just drop it. I was simply attempting to understand the other viewpoint, I wasn't trying to get yelled at.
V = I * R (talk to Ω) 22:36, 15 September 2009 (UTC)
I'm not saying the specific preventative idea here is good, but I disagree with the notion that we should never attempt any preventative measures. Gimmetrow 16:19, 16 September 2009 (UTC)

This is the proverbial "rock and a hard place". Problem: IPs create 97% of vandalism. Solution: Ban unregistered IPs from editing. Problems with solution: 1) Unregistered IPs create a huge amount of good edits (I don't remember the exact figure, except that it's somewhat north of 50%), 2) Unregistered IP vandals will now register before vandalizing, thus negating any good that would be done by this exercise. Plus, we lose that 50%+ of good edits. Our position after the exercise: Backs against the wall. Frustrated editors leaving in droves. Rampant vandalism (you think it's bad now?). Reputation of Wikipedia down the tubes. Jimbo Wales would not be proud. --Tim Sabin (talk) 00:21, 16 September 2009 (UTC)

What if we had an automatic 24 hour ban on an IP that commits vandalism? On a second offense, ban for a week. A Quest For Knowledge (talk) 16:24, 16 September 2009 (UTC)
That already can be, and often is, done. The process is simply not automatic, and for good reason. For any sort of automatic heuristic to really be effective would require non-trivial computing resources. A truly "automatic 24 hour ban" actually implies a completely "dumb" system that has no heuristic at all. Either way, the false positives would be a nightmare, and adding in the issue with dynamic IP's then makes the situation much worse (consider the fact that most editors behind temporarily banned IP's could simply release and require a new IP address, for one thing).
V = I * R (talk to Ω) 17:31, 16 September 2009 (UTC)

Obviously the whole ban IP editors is a perennial proposal, and there are some people who will never be convinced to do it, but there's the thing. Anonymous editors are 7842 times more likely to be vandals than logged-in users. So, why couldn't we do a one week trial where anonymous edits are turned off; just one week, and see what happens. As for "it's somewhat north of 50% above", that's not true, anons contribute only about 26.8% of non-vandalism edits. Cool3 (talk) 16:32, 16 September 2009 (UTC)

I didn't just make up that "north of 50%". From the Wikipedia:Perennial proposals#Prohibit anonymous users from editing page (which, BTW, I did not write): "While about 97% of vandalism comes from anonymous users, about 76% or 82% of anonymous edits are intended to improve the encyclopedia." It appears that a study has been done on this subject. --Tim Sabin (talk) 23:47, 16 September 2009 (UTC)
Because in doing so we would be telling 1 week's worth of anonymous editors "Your edits are no longer welcome here; go away." Good luck getting them back. Shereth 16:34, 16 September 2009 (UTC)
There are several very active, very proficient editors who do not log in. That is their preference. We should not require them to create accounts. 99.166.95.142 (talk) 16:50, 21 September 2009 (UTC)

A difficulty here could be that people who are new to Wikipedia, and who may be quite sincere editors, may still be learning about how to set up userpages. After all, we should remember Wikipedia: Please do not bite the newcomers. ACEOREVIVED (talk) 20:29, 25 September 2009 (UTC) And looking back few years, I see that my earliest edits were signed by a name in red letters - "ACarl" - before I had really learnt to set up a userpage on Wikipedia.(N.B. this was not sock puppetry, since "ACarl" was never the name of a userpage, hence the red letters). This proposal would probably eliminate a lot of newcomers to the Wikipedia project. ACEOREVIVED (talk) 22:51, 2 October 2009 (UTC)

I agree with Aceorevived and Ohm's Law, both of which I believe fought with me just last week against a very similar proposal, which wanted to, among other things, make having an e-mail address mandatory for creating an account. This proposal is not just a perennial one, it is one that comes up before the previous one is even closed out and archived, and shows up at multiple discussion forums, both Village Pump (proposals) and (policy). I have a better proposal- lets ban any whose proposals are to ban IP's or make it harder to create a new account and if someone proposes such a proposal then they are banned for one week. Yes, IP's do vandalism, some of that vandalism though may not be intentional vandalism, and some of that vandalism is kids who dont know better and who may not be the main users of that IP address, to ban all users of that IP address because of one's mistakes (intentional or otherwise) is wrong. So lets ban all who propose to restrict IP's or any of these proposals to restrict newbies because by constantly proposing these proposals over and over and over they are being just as disruptive. As I stated in another discussion we have the ability to make regulations that would once and for all proactively end all vandalism, but it would make us lose all the free spirit and fun that makes Wikipedia what it is, it is not worth it; just as it is possible, by giving away our democratic freedoms, we can end practically all crime in the US (or UK, France, Australia, wherever). We dont, because it is against our ethics and the core of what makes us unique. Wikipedia was founded with certain principles and those principles have evolved, let us not devolve by enacting any of these proposals that would be, in essence, a "Patriot Act" of Wikipedia. Vandalism is not killing anyone.Camelbinky (talk) 23:48, 2 October 2009 (UTC)
Oh, and has anyone noticed that the proposer of this proposal has been labeled as a potential sockpuppet? So why are we taking this serious? Ironic that one who should be banned is proposing to ban others.Camelbinky (talk) 23:51, 2 October 2009 (UTC)

Thank you, but I do not think I contributed to that proposal myself, if it is the one I am thinking of (the one about new introductions for new editors).ACEOREVIVED (talk) 23:12, 3 October 2009 (UTC)

Oh, I did not mean "fought with me" as in "fought against me" I meant it as in with me as in on the same side of the position as me. I had thought in that other discussion you were on the same side with me, and that Ohm's Law was as well, perhaps you werent involved? I get confused easily!Camelbinky (talk) 23:21, 3 October 2009 (UTC)

Thank you for clarifying this - at first, I thought you meant "fought against" but now that you have clarified what you actually meant, I feel somewhat better! However, I am still not sure which proposal you meant - if you go to the history of this page, you may find the one. ACEOREVIVED (talk) 20:07, 4 October 2009 (UTC)

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy