Wikipedia:Village pump (proposals)/Archive 105

I guess the title says it all... proposal page on Meta -- Ypnypn (talk) 18:54, 20 August 2013 (UTC)

Hey folks, just an announcement that the evidence-based systematic review library,

I was on facebook the other day talking about very sensitive mental health topics and then I got an ad for a mental health degree pop up on my sidebar...This is going too far...Would Wikipedia foundation be able to create an open source social networking site, is it feasible, would donations be enough? When I'm on facebook I feel like I'm being watched by the NSA but it just happens to be facebook which is the actor not the NSA. It would cost a lot of money I know...I'm broke but I would still donate to the cause as much as I could...Facebook will now be going after me :-(. Thanks guys, I know this is an outlandish idea but why not..Look at what wikipedia has done in changing the way encyclopedias are structured and made a huge difference in the world...Jimmy Wales deserves a nobel prize.Dounai99 (talk) 16:36, 23 August 2013 (UTC) (talk) 15:36, 23 August 2013 (UTC)

The wiki software is free and open source. Anyone who can obtain a domain name can begin a wiki-based social media site. bd2412 T 16:42, 23 August 2013 (UTC)

I understand that but I'm talking of more like a facebook style one which would need new software..Dounai99 (talk) 17:45, 23 August 2013 (UTC)

Wikimedia Foundation is a non-profit educational foundation. Creating a social media website would be a violation of the rules under which it operates, since there is no educational purpose or value in Facebook equivalents. --Orange Mike | Talk 18:03, 23 August 2013 (UTC)

I think that it is unlikely. bd2412 T 18:03, 23 August 2013 (UTC)

That makes sense...I wasn't that familiar with the mission statement of the foundation...Just a thought and doesn't hurt to ask I guess.Dounai99 (talk) 18:29, 23 August 2013 (UTC)

Among Facebook's many competitors, Google+ is the biggest I know of that doesn't advertize much. Of course we are watched, since being watched is the main purpose of social networks and it's also an important part of what Wikipedia is about. Jim.henderson (talk) 18:42, 23 August 2013 (UTC)

Also, check out

Diaspora (software) and Identi.ca. It doesn't really seem to suit our mission, so I don't think a Foundation thing would be agood idea. Martijn Hoekstra (talk) 18:46, 23 August 2013 (UTC)

The diaspora looks amazing. It ties into facebook and twitter and google plus I think but is free of prying eyes and eerily based ads based on what you are posting and chatting about. Thanks guys, it doesn't look it's widespread yet but hopefully it will be. Identi has more users but less functions than facebook so not sure about that..Dounai99 (talk) 19:16, 23 August 2013 (UTC)

An RfC has been opened to determine community consensus for a user right or permission for AfC reviewers at Wikipedia:WikiProject Articles for creation/RfC Reviewer permission. Kudpung กุดผึ้ง (talk) 06:30, 24 August 2013 (UTC)

The Wikipedia Library is an open research hub, a place for organizing our amazing community of research and reference experts to collaborate and help improve the encyclopedia.

The Wikipedia Library (talk | edit) Get free access to research! Research tools and services Resource Exchange Reference Desk Discover open access Free Resource Guides Book Sources Journal Sources Bibliographies Free newspaper sources Online archives Find Your Local Library tips Find Your Source tips How to find sources Citation tools guide Outreach The Wikipedia Library Bookshelf (meta) Universities and Libraries Archivists Publishers Wikipedia Loves Libraries Wikidata source metadata Get involved Get free access to sources Read the Books & Bytes newsletter Help disambiguate authors of scholarly papers Be a Wikipedia Visiting Scholar Teach Library Interns Become a Coordinator Learn about TWL ...Support Open Access...

We are working together towards 5 big goals:

Connect editors with their local library and freely accessible resources

Partner to provide free access to paywalled publications, databases, universities, and libraries

Build relationships among our community of editors, libraries, and librarians

Facilitate research for Wikipedians, helping editors to find and use sources

Promote broader open access in publishing and research

Sign up to receive announcements and news about resource donations and partnerships: Sign up
Come and create your profile, and see how we can leverage your talent, expertise, and dedication: Join in

-Hope to see you there, Ocaasi ^{t | c} 14:59, 23 August 2013 (UTC)

According to a new

Hello.

Is it possible that the visual editor can insert hidden comments as we do in the source? They should appear on the page in either <!-- Comment --> notation or appear in a user-defined color, or both, all which should be definable through a dropdown menu with checkboxes, with the option to show and hide them. Thanks. 2602:304:59B8:3279:8CA0:1CFC:C72E:8DD0 (talk) 21:22, 24 August 2013 (UTC)

Several requests have been made at

WP:VE/F for the feature, but its not something the devs have gotten too. It should be a feature (in some form), but it isn't here yet. Chris857 (talk) 21:29, 24 August 2013 (UTC)

This is T51603 and is listed as "high enhancement", which I think means that we'll get it sooner rather than later... but I'm not sure what month "sooner" means. It doesn't seem like a super complicated thing to do, so maybe it will happen in the next few weeks or so. Whatamidoing (WMF) (talk) 03:59, 25 August 2013 (UTC)

There is an ongoing

Open call for questions. Cheers, Ocaasi ^{t | c} 12:39, 29 August 2013 (UTC)

I propose an "Up and Coming" class for Topics to promote improvement of quality articles.The symbol for this would be similar to the others but with an arrow pointing up. I was also thinking of it being colored to orange and yellow. This class would be if a main topic has 2/3 of its articles upto GA but not 1/3. That way the broader topics that do have significant ammount of GAs are recognized as a quality topic, and promote it on its respected wikiproject's main page so familiar editors can turn it into a featured/Good topic.

I personally find this idea really beneficial as I'm sure there are topics out their we see have large ammount of GAs but not enough to be recognized by wikipedia. This will make it official.Lucia Black (talk) 22:26, 30 August 2013 (UTC)

Anyone?Lucia Black (talk) 08:16, 31 August 2013 (UTC)

The B-class? ViperSnake151  Talk  00:06, 5 September 2013 (UTC)

It could be confused, though, with

WP:UPANDCOMING. --Orange Mike | Talk 00:21, 5 September 2013 (UTC)

A rather questionable essay...but I'm uneasy about "B-class" topic as it would imply all articles will have to be B-class or higher. The class is meant to be for any topic that has 2/3 or more GAs and the 1/3 of the topics could be any class, such as start-A. Maybe a better name such as the Ambitious-class or forthcoming-class.Lucia Black (talk) 01:07, 5 September 2013 (UTC)

Haunting talk pages as I am wont to do, I see a lot of "Why was my article deleted?" message to Admins from people whose first edits on WP is to set up an article for themselves and/or their company. They usually do not do a very good job as they don't understand about secondary sources or conflicts of interests. That is pretty consistent.

But what is also consistent is the way their inquiries are dismissed when they come to ask "What happened?" They are frequently told that their article was promotional and (in my words), don't let the door hit you on the way out. They rarely return and this is their lingering impression of Wikipedia.

Because I see this happening so frequently, I think it might be useful to create a template that we could add to SPA who come to WP for business reasons and don't really understand that WP is an encyclopedia and not a directory. It could list the most common reasons for deletions and then references to the relevant WP policies that they should consider if they want to put in the time to rewrite their articles.

It seems like this would a) save time for Admins, especially those involved in deleting articles, from having to repeat the same explanation over and over again and b) it would seek to answer the most common questions business people have and be a fuller reply that just "It was too self-promotional". It could be put on the User's Talk Page either for all business-related deletions or after they've sought out Admins to complain.

I can also see this expanded to have specialized templates for musicians whose pages are deleted, other entertainers who are not notable (yet) and other topics that have articles that are frequently created only to be deleted.

If there is support for this, I can see the first step is to learn how to create a template or have some smart editor create something suitable. Then, adoption would be a secondary issue. Liz ^{Read! Talk!} 20:12, 1 September 2013 (UTC)

I like this idea. But doesn't {{

Db-notability-notice}} and related already sorta do that? ViperSnake151  Talk  00:04, 5 September 2013 (UTC)

Please see a couple changes I proposed here. (To not lose the thread, it might be best to reply there; I'm only leaving a note here to attract audience that could be familiar with the subject). Gryllida 10:44, 3 September 2013 (UTC)

Hello. I know this is a recurring topic, but I have not heard of anything similar to the approach I drafted below, so here I go.

After spending some time on Wiktionary, I started to think about our deletion processes, specifically

• Editors, and especially new ones, often make
  WP:BURDEN
  , which is policy.
• Nobody can ever agree what "
  ad-personam
  arguments.
• The above is further fuelled by the fact that administrators, who are supposed to be assessing consensus and closing discussions, are overwhelmed. This prompts
  non-admins to do it instead
  , and non-admins are sometimes less knowledgeable about policies, and often more skewed towards inclusionism, cherry-picking arguments for "keep" to justify a speedy closure. To counter this tendency, discussion-closing rules should be more rigid and unambiguous.
• Many AfDs just lay there for a full week without even two comments from anyone other than a nominator, which leads discussions to be relisted; this further keeps the backlog from shrinking.
• The name "Articles for deletion" sends the wrong message — that the most important thing is whether this or that article be deleted, while in fact the most important issue should be whether
  "I worked on this article very hard! Please do not delete it!!!"
  ). We should be explicit about the merits on which we base deletions.

Wiktionary has two processes that can result in a deletion of a page in the main namespace: one (Requests for Deletion) is for violations of more technical policies (what constitutes a "word" with a distinct meaning, and such), while the other (Requests for Verification) deals with deciding whether a term is established in a given language, finding sources and examples of usage. I think we ought to have something similar to the latter process: a deletion venue dealing exclusively with verifiability/notability (which I, by the way, see as two ways of describing

The process will be: 0) an editor finds a poorly sourced article of doubtful notability; 1) they put a notice on the article and start a discussion on a "Requests for immediate verification" noticeboard, stating a reason (which may be optional if there are literally no or few actual sources - not just external links - in the article) and possibly a potential merge target, if a good one exists; 2) the article sits there for some period of time: editors who notice it find sources about the topic and post them in the discussion page; 3) when enough sources are found to write a sourced article of about Start-class quality, the article is kept (preferaby, the article should already improve to that point); otherwise it is merged (if there is a good target and sources only for a stub) or deleted (if not even that).

What will change (aside from the name):

• WP:BEFORE
  tells you to do anyway: finding sources to establish standalone notability.
• Head count will be much less relevant. Votes (enough of the "!vote" doublethink) like "Keep: passes
  WP:FRINGE
  here). Ideally, there would be no vote labels at all, just a bunch of sources and descriptions of what they state (or reports like "I failed to find any sources in [Google, my university library, etc.]").
• The discussion period may be longer, a few months even — although early "keep" closures should be permissible, on conditions similar to
  WP:HEY
  . Closing rules should leave little room for interpretation, to avoid arguments about justification of a particular closure.
• This verification process could also be applied to stale userspace drafts; in case of a successful verification, the article is launched.

This is a rough sketch of the idea, details may change. I will not even promise a standalone proposal page. But please tell me what you think. Keφr 15:46, 4 September 2013 (UTC)

Wouldn't every article with {{notability}} tag (i.e. "editor finds a poorly sourced article of doubtful notability") qualify for "Requests for immediate verification"? —  HELLKNOWZ  ▎TALK 16:26, 4 September 2013 (UTC)

• We also have articles like Anne Lindbergh that are unilaterally redirected with no tags or AfD.--Canoe1967 (talk) 20:10, 4 September 2013 (UTC)
• How do you reconcile this with the principle that WP:There is no deadline? WhatamIdoing (talk) 20:56, 4 September 2013 (UTC)

Hello I am Dounai99..I was a previous editor and contributor about 1.5 years ago on Wikipedia. I enjoyed it in the beginning but as time went on I noticed the only people who were neighborly were the staff of wikipedia, the tearoom and others in that light. I only met one person who was willing to give me a guiding hand (a veteran to the site) and who I could bounce ideas off and who would give me hints and tips that a wiki staff couldn't do. There were the angels or fairies whatever they're called who would come and and help fix grammar and word usage as well as to do difficult tasks in regards to graphics/graphs and the such that a beginner couldn't do. The rest of the people I met were not neighborly, overly competitive, not wanting to colloborate, mean and said they didn't want to become too "friendly" because it would hurt the mission of objectivity in case of a dispute. While this last part may be true does it really have to be this way. I sincerely hope the tone and culture of Wiki has changed since 2 years ago and that it's more of a community now..Because isn't that supposed to be what the site is all about? A beginner is so naive and wanting to get involved and then they berated by the more mean style veterans who probably look down upon them because they don't know anything. Beginners should be treated with kid gloves in many cases I think and as they grow and develop keep reducing the thickness of the gloves until they are confident, skilled and a veteran. These are just my thoughts on the subject. What do others think? I will keep updating this paragraph as I feel the current Wikipedia and see if things have changed. Dounai99 (talk) 16:32, 23 August 2013 (UTC) (talk) 14:26, 23 August 2013 (UTC)

My personal experience is quite different. When I started editing, more experienced users where watching my edits, checking that they were valuable and policing my mistakes. However, they quickly gave me their trust and were always available for discussions from then on (looking back I understand their actions very well, in particular when, as an experienced editor you have to fight frequent vandalism). Wikipedia is not a tchat website so it is true that you don't spend most of the time discussing with people (it is not the goal isn't it?) but from time to time, I have enlightened discussion with people sharing my interests and whose goal is for the common good, i.e. making articles better. Like everything in life, editing wikipedia is a question of motivation. This motivation you can draw from various sources: some people find it in making article GA or FA, others value more discussions and team work. Personally, I am proud to make article better and always think that thanks to this more of the human knowledge is freely and easily accessible everywhere. This is certainly grandiose but motivates me. And of course I like to tchat from time to time on what I edit with other people. As far as I can tell, there are very few mean people and many simply reflect your attitude to them. Because there are like you and me: most want to share, discuss and see their work recognized by their peers. Barnstars are good for that ! Iry-Hor (talk) 11:43, 30 August 2013 (UTC)

I agree that many editors can be combative and harsh, and not necessarily open / friendly. I have found that people often seem put off by friendly / good faith gestures. This is a culture thing. It's so massive that I don't have a specific suggestion as to how to fix it, but I don't think it's hopeless either. A collegial atmosphere is one I sincerely hope we achieve. Perhaps unfortunately, it is the responsibility of those who are already being nice to make things better, by setting a good example. I suggest that you continue to be nice and to spread

WikiLove to all the peoples of the wiki. I'm sure karma-related concerns come into play somewhere; if you treat others with lots of love and understanding hopefully others will do the same to you. I do think we look to one another for standards of how to act; if you place a welcoming, handwritten message on a new user's talk page, for example, other editors will notice and think about doing that in the future. So it's that typical advice about enacting change - start with yourself, set a good standard, and be confident in what you're doing. Hopefully others will take notice. CaseyPenk (talk) 16:27, 6 September 2013 (UTC)

1. At Talk:Traditional Chinese medicine, archives were done manually until MiszaBot was turned on in 2011. However the bot configuration was botched, causing new threads to be added to the very beginning of the archives starting from 2004. Such was the situation until today.
2. Recently on Talk:Rupert Sheldrake a new user added a comment to an old unrelated thread. This caused some confusion, with one other user responding thinking that the comment related to the thread topic, which it didn't.
3. This new user continued adding comments to old threads, not realizing that there was essentially no correlation between those discussions and the current article, as the article had changed significantly since then.
4. Seeing that the talk page had not been cleaned for a while, I took it upon myself to create another archive. However out of bad luck this happened during the subsequent comments by the new user; the new archive started immediately after the new user's first comment. I ended up copying the new comments individually to the cleaned talk page.

Again, all of these problems arise from the default setting of "precarious manual labor" for archiving.

It may be objected that many articles are low-discussion with little need for auto-archiving. Well that's fine, the default bot settings can conservatively target that case.

To cover the case of higher-volume discussion in a user-friendly way, there should be a note at the top of talk pages briefly describing how to tweak the relevant bot parameters. Vzaak (talk) 21:20, 1 September 2013 (UTC)

This is basically already planned. WP:Flow will change the talk page structure, and one feature is that only the most recent/unread comments will display, and the much older stuff will "fall off the page" (not display unless you click on 'load more' or scroll down to see them, or something like that). This results in essentially automagic archiving, plus has the benefit that when you link to a conversation, the link is permanently valid, because the conversation isn't hidden on some other page by a bot. WhatamIdoing (talk) 05:19, 2 September 2013 (UTC)

Thanks, I didn't know about that. I suppose this should be closed, then. Vzaak (talk) 05:59, 2 September 2013 (UTC)

I just tried the prototype; I have doubts that it will be deployed any time soon (or at all), so in the meantime perhaps enabling Misza by default is not such a bad idea after all. Vzaak (talk) 08:24, 2 September 2013 (UTC)

I think a human should be required to enable an archiving bot, simply because a bot can't tell whether a thread should be archived or not (ideally a thread with a years-old error report should remain visible until the error has been dealt with). And sometimes it can be a good idea to respond to very old comments, like at Talk:Viola#Audio Examples. Overall, I just don't think the great majority of articles change quickly enough for this to be of much use. Graham87 13:38, 2 September 2013 (UTC)

The first part of this comment is an argument against archiving bots altogether. We have to assume auto-archiving is widely used for reasons which outweigh these concerns and which are not completely mistaken. I anticipated and answered the latter objection in the OP. This is not an abstract issue; the OP shows in concrete terms problems that stem from manually archiving even for low-traffic pages. Vzaak (talk) 14:49, 2 September 2013 (UTC)

To me a nice feature to have would be an expandable banner saying X messages have been archived since MM/DD/YYYY. Expanding the banner would produce a table of contents with the last 50 archived message titles. Praemonitus (talk) 14:35, 2 September 2013 (UTC)

@Graham87: If a human is responsible for enabling auto-archiving, that doesn't mean a human is judging each thread to determine if it should be archived. Threads are then purely chosen based on age/lack of activity. Having to manually pick talk pages to be auto-archived doesn't address the issue you're describing. Yours is more of an argument for killing the archive bot altogether. You could say there are some articles more likely to develop long discussion pages with old sections of continued relevance; though I'd question that, we could simply make auto-archiving an opt-out process instead of opt-in. It's generally accepted that regular archiving is a good thing. Equazcion ^(talk) 14:41, 2 Sep 2013 (UTC)

Yeah, I guess you're right there. People are more likely to think "this is a ginormous page ... let's autoarchive it" than they are to go through each individual thread checking for unresolved issues (and I imagine many threads on active talk pages are resolved in fairly short order). Auto-archiving is an awful lot easier and less error-prone than manual archiving, despite its minor drawbacks – and I remember the days before automated archiving with dread. I think, if we're going to do this, it should be done veeeeery conservatively ... perhaps once a talk page has reached, say, 50 threads? Another thing to think about: should we use MiszaBot or ClueBot III? The latter bot has some advantages (automatic indexing, better handling of unsigned comments) but is IMO more difficult to use. I'll ping the authors of both the bots. Graham87 16:32, 2 September 2013 (UTC)

talk · contribs), has been active more recently than Misza13 (talk · contribs) so it's more likely to be maintained; (ii) it fixes incoming links to sections so that they point to the archive instead of the parent page; (iii) it updates an archive index without relying on other bots (such as Legobot (talk · contribs), which has not updated archive indexes for about six months) to do this. See here for an example where ClueBot III fixes a link and updates an index. --Redrose64 (talk) 17:53, 2 September 2013 (UTC)

• Support auto-archiving, either by
  talk · contribs). Who knows when Flow will be deployed, yet alone usable. Let's bring some more sanity to talk pages in the meantime. For new users, talk pages can be daunting - when there's so incredibly much content that it's difficult to navigate, people don't feel comfortable participating. This is an easy and straightforward way to make talk pages more reasonable. CaseyPenk (talk) 16:21, 6 September 2013 (UTC)

...is always red. Bright red, square, and nine times out of ten meaning someone has reverted your edit. The appearance of that message bubble is not the best way to start a dispute resolution! It is like a red rag, a seeming challenge burning bright against the blue-and-white color scheme of everything else. That red is very agitating and I am certain quite a few an edit war started on more raised tones than necessary, because not only was a person's contribution rejected, but the news was presented with unnecessary visual aggression way. This is a classical instance of a 'bad start'

You might think 'oh it's only a little message bubble it's not a big deal' Well that is not the mentality of an edit warrior! Little things take on an exxagerated significance in that kind of situation. An instanteneous red, small, angry start to an edit dispute will become a war. It's enough to make me not want to log in anymore, and just edit Anonymously. There is not a color that could make it worse than this, even if it were bright fuscia. — Preceding unsigned comment added by 85.211.96.68 (talk • contribs) 00:54, 31 August 2013‎

I think red was chosen because it is 1) very visible/hard to miss and 2) because it is similar to other notification design and therefor easy to understand (email notification on iphone, facebook notification). I think you make a good argument that red is agitating, but i think that those 2 reasons are even more important and hope that people are already used to red notifications ;-) Peace! --Atlasowa (talk) 10:26, 31 August 2013 (UTC)

And for those reasons, I doubt the color will be changed globally. But if anyone wants to change the color for themselves, it should work to copy the following CSS rules to your common.css and adjust the color codes however you like:

#pt-notifications .mw-echo-notifications-badge.mw-echo-unread-notifications {
    background-color: #cc0000;
}
#pt-notifications .mw-echo-notifications-badge.mw-echo-unread-notifications:hover {
    background-color: #bf0000;
}

The codes listed here are for the default red. HTH. Anomie⚔ 11:52, 31 August 2013 (UTC)

I agree that red is agitating and makes one tense before even clicking on it. I support changing it to a more soothing yet still noticeable color, such as blue. CaseyPenk (talk) 16:22, 6 September 2013 (UTC)

Isn't red the classic color for notifications? It doesn't seem that most of the notifications that people receive are revert notices, but I may be wrong. Sure, the color could be softened a little, but red should probably remain the color of the notification button.

talk!) 01:38, 8 September 2013 (UTC)

Just because it's a 'classic' notification color doesn't mean it's use is correct in this circumstance. And you just KNOW that when the notice pops up after you recently edited an article, it is almost certainly a revert notice. It could be argued that reverting is the laziest and most unconstructive way to deal with a situation, and it certainly FEELS that way when someone throws out your contribution. And Wikipedia just HAS to notify you about it, in bright RED (because it's classical). Not yellow, not orange - RED. It's not a notification anymore - it's an ALERT. And note the difference between the two, and how it is the first step to inducing the user to edit war. The user is not being notified - the user is being ALERTED, to soemthing that needs their urgent attention - their edit is reverted! — Preceding unsigned comment added by Nitrobutane (talk • contribs) 15:50, 23 September 2013 (UTC)

I was thinking maybe I should post this message at Wikipedia:Requests for comment but in the end I decided to post here. I think that the most steady way to develop Wikipedia is the bottom-up approach: First, gather the sources about that subject (article), so you have a solid foundation to build upon. Imagine we develop the Berlin article. First, we must have a comprehensive list with (more or less) all the books about Berlin: books about the history of Berlin, about monuments of Berlin, about streets of Berlin, about economy of Berlin, etc. It's not important only for developing the article, but also in order provide to the readers more valuable resources for learning about the subject. Therefore, the foundation of an article should be it's "Bibliography" (or better: "Furhter reading") section. The lists can be improved by creating (subjective, or biased if you want, because we don't need 100% consensus on this) tops with the best books and the best authors who wrote about Berlin. When someone wants to know more about history of Berlin, it will be very helpful for them to know who are those considered to be the best historians who wrote about the city.

It's looks very strange for me to see that projects like meta:Wikicite and meta:WikiScholar exist while in the same time articles like London and Paris have only two or three books in their "Bibliography" sections!

Another thing: when a reader wants to learn about his own country (in my case it's Romania), I think it's very important for them to have available tops with the best specialists in his country: List of top 20 Romanian historians, top 20 Romanian mathematicians, top 20 Romanian physicists, architects, chemistry, cybernetics, etc. The lists can be further split: Top 10 Romanian historians of the 20th century, Top 10 Romanian historians of the 19th century, and do on. The only such list I'm aware of is the 100 Greatest Romanians, where they are all mixed together. It's good as a start, but we need much more. Of course it's not the Wikipedians job to create such tops, but Wikipedia editors can try to find such tops which are very valuable (in my view).

Also in the light of the same bottom-up approach, when I find interesting newspaper articles on a subject but I have no time to add information from it into Wikipedia, or I'm not sure where in a specific article to add it, I save the link to that newspaper article (or the essential information from that link) somewhere in the article's talk page, like for example at

I have started a discussion about adding something about external links to the content disclaimer, see Wikipedia talk:Content disclaimer#External links. Thryduulf (talk) 13:59, 9 September 2013 (UTC)

From time to time a Bot informs me that I have created an unintended link to a disambiguation page, instead of to the article I had intended. For example, I may be including a list of place names where someone who is the subject of an article has lived. Usually, I click the links to check that they go to the intended article. But a month ago I missed one and it was the only one which went to a disambiguation page. The kind of unintended link would be putting a link to Birmingham assuming that the only article this would link to would be Birmingham, West Midlands, England.

Now the software developers for Wikipedia are clever people. So would it be possible for them to come up with something which will either highlight any links which go to disambiguation instead of to an ordinary article? Or an advance on this which would automatically fill in as Birmingham, England instead of Birmingham, Alabama if the article is about someone living in England and not in the USA? (A quick look in Perrennial Proposals did not show any similar suggestion.) -- Robert of Ramsor (talk) 21:36, 10 September 2013 (UTC)

• This is a great idea; I agree this would be extremely useful. MediaWiki has similar functionality for redirects (see Wikipedia:Visualizing redirects) but it requires tweaks to one's .css page to implement. Ideally there would be options in Preferences to let users choose different colors for redirects and disambiguation pages. 28bytes (talk) 21:48, 10 September 2013 (UTC)
• User:Anomie/linkclassifier.js will apparently independently color links to disambiguation pages, redirects, broken redirects, and pages up for deletion. equazcion ^(talk) 21:54, 10 Sep 2013 (UTC)
  • See User:Anomie/linkclassifier#Usage for directions, and I highly (very very strongly) recommend the "run on demand" version (otherwise long articles/talkpages take even longer to finish loading). –Quiddity (talk) 22:28, 10 September 2013 (UTC)

See mw:Extension:Disambiguator and also mw:Wikimedia_Mobile_engineering/Strategy/2013-2014_planning#Micro-Contributions and User_talk:Maryana_(WMF)#Mobile_editing. The most popular "Wikipedia game" is Wikipedia:Wiki_Game / http://thewikigame.com/ http://wikipediamaze.com/ where you have to find the minimum of wikilinks to get from article A to article B. This is very popular, but it doesn't add to or improve Wikipedia. Now if the task would be to resolve wikilinks to disambiguation pages to direct links? Done on your smartphone while waiting?

(See Wikipedia:Village_pump_(miscellaneous)/Archive_43#Disambiguation_in_crisis and Wikipedia:Wikipedia_Signpost/Newsroom/Suggestions#Recent_rise_in_disambiguation_links.) --Atlasowa (talk) 23:04, 10 September 2013 (UTC)

For precisely this reason, I have requested an edit filter that would alert editors when they are about to save an edit that creates a disambiguation link. I think there is an obvious need for this, but have yet to hear anything with respect to this request. bd2412 T 23:09, 10 September 2013 (UTC)

An edit filter can't do that. I've left a longer explanation at the request. Jackmcbarn (talk) 01:59, 11 September 2013 (UTC)

I have asked at MediaWiki talk:Bad image list‎#‎A similar function for disambiguation links? and at Wikipedia talk:Spam blacklist‎#‎A similar function for disambiguation links? whether something could be done in line with one of those functions. There must be some way, without upsetting too many applecarts, to institute this fairly straightforward function. bd2412 T 03:21, 11 September 2013 (UTC)

FYI, I've proposed an RfC on filenames, see

An RFC is under way to determine whether or not to create a new user right that would allow trusted template coders to edit fully protected templates: Wikipedia:Requests for comment/Template editor user right. equazcion ^(talk) 10:09, 11 Sep 2013 (UTC)

We have an ongoing problem with EL spam from low-mileage single-purpose editors [3]. Given that our existing infrastructure already supports limiting what low-mileage accounts can do, can we do anything to restrict their ability to add ELs (and nothing else)? I recognise that it could be a problem to distinguish EL spamming from valid reference adding, and that we might just turn overt EL spamming into more subtle ref spamming. Andy Dingley (talk) 09:05, 13 September 2013 (UTC)

(This is a repeat of an earlier notice.) Since March 2013, various individual members of the

I would like to have been able to {{ping|}} the user in that edit. Can the notification functionality be added to edit summaries? Is that being worked on? Thanks. Biosthmors (talk) 16:57, 13 September 2013 (UTC)

@Biosthmors: It is, via bugzilla:49446. –Quiddity (talk) 17:14, 16 September 2013 (UTC)

Great.

U}}) when u sign ur reply, thx 17:15, 16 September 2013 (UTC)

Some time ago I came with a proposal for asking online newspapers to come with a unified way for storing key data in their article's pages: title, author name, date and permalink (using maybe meta-info fields). It would be so nice if there would be some "Good practice" W3C standard for this, and if the newspapers would be encouraged to apply that standard in their articles. That would make it much easier for Wikipedia editors to create references and external links. But because that's not going to happen anytime soon, there is another solution for this: With a bookmarklet you can generate automatically a reference or an external link. That means the bookmarklet needs extra code added for every website in order to "learn" that particular website, and the code must be updated every time a website changes the way it's storing those key elements (title, author, date) in their HTML pages. I created such a bookmarklet, and I am using it very much (on Romanian Wikipedia), and it's saving me lots and lots of time. If more people find it useful, then we can make together such a script to handle the most well known websites. Those who would like to try it can find the script here: User:Ark25/RefScript. I know there is Wikipedia:Cite4Wiki but it seems that it doesn't work very well: didn't find author name and date in the articles I tried it, and in my Firefox it doesn't even allow me to copy the text at this moment. On the other hand, the bookmarklet can generate references in many different ways, and it also can create external links.

This is how the script works:

Say you have a link like this: http://www.bbc.co.uk/news/science-environment-23814524

The script can generate a reference like this with a single click:

<ref name="bbc.co.uk_2013-09-16">{{Citation | last=Suzi Gage| title=Sea otter return boosts ailing seagrass in California| newspaper=BBC| date= 26 August 2013| url=http://www.bbc.co.uk/news/science-environment-23814524| accessdate=16.09.2013}}</ref>

or like this:

<ref name="bbc.co.uk_2013-09-16r">[http://www.bbc.co.uk/news/science-environment-23814524 Sea otter return boosts ailing seagrass in California], 26 August 2013, Suzi Gage, ''BBC'', retrieved at 16.09.2013</ref>

Or it can generate an external link, looking like this:

* [http://www.bbc.co.uk/news/science-environment-23814524 Sea otter return boosts ailing seagrass in California], 26 August 2013, Suzi Gage, ''BBC''

The output will be like this: ^{[1] [2]}

• Sea otter return boosts ailing seagrass in California, 26 August 2013, Suzi Gage, BBC

In order to change the output of the script, you just have to change the last variable, from "sc" to "sr" or to "s".

For the moment, the script handles only a few sites (BBC, Ars Technica, TG Daily), but the good part is that everyone can teach the script how to handle a new website. —  Ark25  (talk) 01:57, 16 September 2013 (UTC)

Thanks for the heads up, Ark25. This looks like it could be a useful tool. You might want to list it at

WP:CITETOOL so we can keep a record of it. 64.40.54.128 (talk) 04:05, 16 September 2013 (UTC)

Ditto what 64.40.54.128 said.

See also User:Bazzargh/citemark, another bookmarklet - it's somewhat erratic in output (it tries to get as much info as possible, and then let the human decide which parts are wanted), but is often useful to me. (It doesn't seem to work on the BBC site currently, which is odd. It did previously!) –Quiddity (talk) 17:10, 16 September 2013 (UTC)

Thanks, I listed it on

WP:CITETOOL#User scripts and also I announced it at Help talk:Citation tools#Bookmarklet for quick creation of references and external links. Hopefully it will get more visibility, because it's really useful. —  Ark25  (talk) 02:45, 17 September 2013 (UTC)

Relatively few talk pages are archived, and many have comments going back 10 years or more, typically relating to greatly different versions of the article. Is it possible to do a one-off exercise (or an annual one) archiving everything earlier than some specified date - I would propose perhaps January 1 2009? This would have to be automated, or very largely so. Johnbod (talk) 17:23, 17 September 2013 (UTC)

What would be the advantage of archiving the article talk pages? Are they too big to navigate? I find it handy to be able to reference the talk page. Stuffing it into an archive seems to be counterproductive except in cases were the talk page has become to large to be easily navigated. -- Whpq (talk) 17:30, 17 September 2013 (UTC)

Many are very long, and confusing to newcomers. They are also just full of crap; whatever else "ain't what it used to be" the standard of talk page contributions has gone up considerably over the years. Johnbod (talk) 02:05, 18 September 2013 (UTC)

WP:Flow will probably make them obsolete next year, so I'm not sure that it's pointful to do anything now. WhatamIdoing (talk) 17:39, 17 September 2013 (UTC)

Now there's two birds in a bush. Johnbod (talk) 02:05, 18 September 2013 (UTC)

• Absolutely not. I frequently encounter articles with issues that have gone unresolved for years, yet also have old but relevant talk page discussion. Talk page archiving is a task that requires consideration of not just the age of comments, but their relevance to the current state of the article. Blindly sweeping them away is a terrible idea. —
  talk 12:46, 19 September 2013 (UTC)

Can we make the page look like a normal disambig page? I think the historically inactive thing on

U}}) while signing a reply, thx 18:54, 29 September 2013 (UTC)

Although most templates vary in importance from "critical" to Roche.svg; I personally think that, after seeing some vandalism by IP's to some navboxes lately (particularly ones for media conglomerates for some bizarre reason), maybe we should consider only allowing registered users to edit templates (they would still be allowed in Template talk, of course, and maybe we can exempt sandbox pages from it as well).

This may seem like an odd idea, the real question is, can anyone else provide justification for such an idea? ViperSnake151  Talk  18:33, 13 September 2013 (UTC)

Permanently preemptively protecting pages (even templates) flies in the face of the goals of Wikipedia. I don't think it's a good idea at all. Jackmcbarn (talk) 18:55, 13 September 2013 (UTC)

In practicality I don't think semi-protecting all templates would be such a bad thing. Almost nobody who has less experience here than the autoconfirmed requirements should be expected to know what they're doing with templates. Nevertheless, I think the fact that anyone can edit them sends an important message about Wikipedia's principles. It reminds us of those principles as well. Any preemptive restriction is a step towards another preemptive restriction. equazcion ^(talk) 19:13, 13 Sep 2013 (UTC)

We have experienced IP editors who choose not to register. Enacting such pre-emtpive restriction would affect them. -- Whpq (talk) 19:24, 13 September 2013 (UTC)

Screw IP editors! But no seriously you do have a point, I didn't think of that. :) equazcion ^(talk) 19:29, 13 Sep 2013 (UTC)

• Out of curiosity more than anything, Whpq, can you show me a template that has had many IP edits that couldn't be considered trivial or vandalism? I don't disagree with you, I would just like to see some evidence that there are actually use cases of templates being edited by IPs that goes past casual. I also wouldn't be opposed to them being semi-protected with the option to unprotect upon valid request. Technical 13 (talk) 20:06, 13 September 2013 (UTC)

• IPs routinely update some of our NHL team roster templates, such as {{Boston Bruins roster}} and {{Calgary Flames roster}}. As far as pre-emptive semi protection goes, I'd probably support it for templates with a certain number of transclusions, but not globally. Resolute 20:12, 13 September 2013 (UTC)

• Resolute, I would like to point out a couple things about the templates you have linked. {{Boston Bruins roster}} is transcluded on only three articles and contains more content than template. I would argue it belong in content space. {{Calgary Flames roster}} is also transcluded on only three articles and contains more content than template. This "template" has also been a victim of a bit of vandalism/speculation (which you yourself had to remove) and is currently broken due to template misuse. Technical 13 (talk) 20:47, 13 September 2013 (UTC)

• My comment was a general point that we deliberately have made the choice that editting as an IP is allowed, and absent very good reasons, we shouldn't be restricting their abilities to edit. Navboxes are nice to haves, so I don't see that vandalism happens on them as a sufficiently good reason to protect them in any manner. -- Whpq (talk) 21:09, 13 September 2013 (UTC)
• They are actually a template comprised of other templates, and are used to ensure synchronization between the three relevant articles. And yes, I noted the irony myself of the vandalism to the Flames template, but I think it curious that you focused on that rather than the dozens of useful updates. Resolute 00:33, 14 September 2013 (UTC)

Flys in the face of

"Ignore all Rules" reason for overriding the pillar. We're only supposed to restrict editing in the face of persistent disruption. While there may be a case for some templates that have been the target of disruption to be semi-protected, the vast majority is harmless mistakes or easily corrected through other methods (like blocking individual offenders). Hasteur (talk) 20:54, 13 September 2013 (UTC)

• Comment I'm an IP and I occasionally edit templates such as this. I've also helped a new user with their first DYK, which occurs in Template: namespace. Cheers. 64.40.54.174 (talk) 04:33, 14 September 2013 (UTC)
• No. --erachima talk 00:49, 15 September 2013 (UTC)
• Comment
  assume good faith and let them edit. Konveyor Belt ^{yell at me} 17:36, 18 September 2013 (UTC)

• Some IPs definitely are. I have seen wonderful works of IPs in templates (mainly one IP starting with 76 something). So, No. --Tito☸Dutta 18:22, 22 September 2013 (UTC)

• Comment - Templates certainly aren't content or plain text, and I think it can be safely said that most (but certainly not all) templates affect several articles and provide links or serve to automate data entry and update stats subject to frequent changes. I don't believe that restricting access to auto-confirmed editors would be a hinderance nor fly in the face of the encyclopedia being free content that anyone can edit. Conversely, I don't believe most templates are in any need of protection. Perhaps the threshold for semi-protecting templates could be set very low; otherwise this seems to be a solution in search of a problem. - Floydian ^τ _¢ 23:45, 23 September 2013 (UTC)
• Oppose, especially if this would include userspace templates (as is the case for userboxes). Protection should only be used when there is a risk of vandalism or other abuse.--Jasper Deng (talk) 02:14, 24 September 2013 (UTC)
• Oppose. Not only would this prevent IP-by-choice editors from ever experimenting with templates, it would prevent registered editors in good standing from doing regular template maintenance when they are accessing WP from an insecure location where logging in to an account is inadvisable. Also, it is a violation of a pillar. VanIsaac_{WS Vex}^contribs 06:04, 25 September 2013 (UTC)
• Oppose - if anything, the "convenience" protection of many non-critical, low- or mid-traffic templates should be lifted. Constructively editing IPs are (or can be) a valuable contribution for most Wikipedia aspects, we shouldn't risk loosing their input. What should be done, is going more consequently after vandalism-only IPs and banning earlier, if an IP doesn't manage to offer any worthwhile addition at all. GermanJoe (talk) 06:45, 25 September 2013 (UTC)
• Oppose on technical grounds. After much thought about this and reading the discussion here, there is really no technical way to distinguish between templates and drafts and otherstuff in userspace or project space, so this protection canvass could only be applied to Module: and Template: effectively. What would this mean to the project? This would mean that:

A) There would lot unconfirmed and IP editors that would be creating templates in inappropriate places to circumvent the protection.

B) There would be a lot more template submissions at

WP:AFC

that the project is currently unable to process (we only have a few reviewers capable of understanding templates and most of them either wouldn't have the time to keep up with the inflow or don't have the interest in reviewing others templates).

There are likely other scenarios that would be undesirable from this that I've not had enough coffee to think of right now, but either one that I listed here is enough for me to say "no thanks" to this proposal. Technical 13 (talk) 12:03, 25 September 2013 (UTC)

Proposal: Eliminate or rename the "Fictional Hillbillies" category, and any other article or category that employs the ethnic slur "hillbilly", using "Southern Mountaineer", "Southern Highlander", or some other, neutral term.

Argument: Wikipedia wouldn't tolerate a category of "Fictional Coons"—meaning stereotyped misrepresentations of black Americans as ignorant, boisterous, superstitious, libidinous, cowardly, and brainless—even though there are plenty of such characters, so designated when they were popular. A category of "Fictional Yids", "Fictional Dagoes", or "Fictional Micks" would, quite properly, be taken down within minutes of being posted, even though stereotyped characters appropriate for inclusion in such categories are abundant in the popular music and literature of the 19th & early 20th Centuries.

Why then does Wikipedia tolerate a category for analogous stereotypes of Southern highlanders? Like "coon", "yid", "dago", "beaner", etc., "hillbilly" is a jocularly derisive, manifestly ethnic classification, applied to Southern highlanders (or occasionally to all white Southerners)^* by others, to point out the former's membership in a despised, alien, and fundamentally inferior group; their non-membership in the speaker's own, presumably superior, group; and, at times most importantly, the speaker's non-membership in, and "appropriate" disdain for, the inferior group.

The unfortunate history of race in the United States has tended to obscure genuine ethnic distinctions (other than those deriving from relatively recent immigration) within broad racial classifications. (Wikipedia's article on

There's no reason why a slur like "hillbilly" should be any more welcome on Wikipedia than any other epithet that demeans or disparages people on the basis of race, class, ethnicity, age, or similar category.

Notes:

• I recognize that my proposed alternatives to "hillbilly" suggest a United States POV in using "Southern"; but less parochial alternatives like "Southern (U.S.A.) Mountaineer" seem awkward and contrived. I venture to predict that the average reader will readily understand "Southern" in this context to refer to the Southern United States.
• Wikipedia does have an article on the musical genre of "coon songs", while the equally offensive term, "Hillbilly music" appropriately redirects to Old-time music. Since "coon songs" are songs about stereotypical black American characters (usually presented in the persona of such a character), rather than the authentic musical expression of a group referred to as "coons" (although some "coon songs" were written by black Americans), it's appropriate for Wikipedia to cover the genre under its regrettable name. (I do, nevertheless, prefer to see the term "coon song" set off with quotation marks, as an indication that it was coined and used by others, in another time, and that its use today is in the nature of quoting those who named the genre, and not a matter of preference or choice.
• Stereotyped fictional black American characters, such as Amos 'n' Andy, who might have been referred to as "coons" in former times, are listed on Wikipedia under the rubric Fictional African-American people.

Reference:

* See, e.g., this charming remark (second-to-last comment in section) by a now-departed Wikipedian in a Village Pump discussion: "I am surprised we are even debating if the Birmingham in Alabama is as notable as the one in England, there is no debate, the UK one is more famous and important to world history unless you count lynchings or number of hillbillies."

Jdcrutch (talk) 00:48, 17 September 2013 (UTC)

I assume you mean category rather than namespace. Jackmcbarn (talk) 00:57, 17 September 2013 (UTC)