Wikipedia:Village pump (proposals)/Archive 103

Linking subjects to books at your local library (Forward to Libraries)
This Request for Comment is seeking proposals from the community to decide how to use the newly created Forward to Libraries (FTL) service that is running on Wikimedia Labs.

We now have a new tool on Wikimedia Labs called Forward to Libraries (FTL).
 * Overview

The same way coord provides readers with a helpful resource (finding the location of things), FTL provides a helpful resource to readers by helping them find books, reference material and other reliable sources on a subject at their local library. The service not only helps readers find detailed information from reliable sources, it can also be used by editors to expand and cite our articles.

This RfC is to determine how to make the best use of this new tool. 23:58, 19 May 2013 (UTC)

How FTL is implemented
The library templates produce links to a server script on Wikimedia Labs that redirects to searches in a local library's online catalog or other discovery system, so that users can find appropriate reading materials there. (Users can register their preferred library target for "your library" links; otherwise they can choose from the overall list of libraries. There are currently over 200 local library catalogs known to the service, along with larger catalog aggregations like WorldCat, as well as a catalog of free online books.  More libraries are added regularly, and users can also go to a form (linked further down this page) to request specific libraries be added.  The data on library links is published at Github, and I'm preparing scripts and documentation so that other Wikimedia developers can import and update this data as needed if I'm not available.)

The server script tries various techniques to formulate appropriate library catalog searches. If VIAF or Library of Congress identifiers or terminology are available, the forwarder will normally issue a search based on the corresponding subject or author headings, since those are what are commonly used in library catalogs. The forwarder can also try to convert the Wikipedia article title to a standard library heading based on algorithms and data that I will be be publishing in the near future as well. If no officially "authorized" library heading can be found, the forwarder will generally try a keyword search based on the Wikipedia article title.

I'd be happy to give more information to folks who might be interested in improving the implementation or helping maintain the Wikimedia forwarder. JohnMarkOckerbloom (talk) 01:32, 21 May 2013 (UTC)

How should FTL links be presented
The Forward to Libraries (FTL) tool is currently used in various templates as both boxes and inline links. The box template is Library resources box, and the two main inlined link templates are Library resources about and Library resources by. There are some lower-leval templates for single links Library link about and Library link by, which are normally not used directly.


 * Use in infoboxes The obvious place for links would be the External links section, but that's not how we use coord. We put that at the top where people will see it because it's a benefit. Similarly, I think the FTL link would be better used in a library resources sub-section of our infoboxes. That's where readers naturally look for information. 64.40.54.57 (talk) 23:58, 19 May 2013 (UTC)

What articles should use FTL

 * Use in most articles Perhaps not current events or popular culture subjects, but most everything else would probably benefit from having an FTL link. 64.40.54.57 (talk) 23:58, 19 May 2013 (UTC)

FTL discussion
Wikipedia was not meant to be a final destination for readers. It was meant to provide an overview and to point readers to reliable sources with more detailed information about a subject. Linking a reader to books down the street at their local library seems like a benefit to both our readers and editors. 64.40.54.57 (talk) 23:58, 19 May 2013 (UTC)
 * I think the proposal is that an extra field be added to many infoboxes, although discussion is invited on any other suggestions. Is there an example of how it would appear? Johnuniq (talk) 01:18, 20 May 2013 (UTC)


 * Frankly the list of libraries signed up is way too small, and this form of search will not produce good results for a vast number of articles. Premature. Johnbod (talk) 02:03, 20 May 2013 (UTC)
 * @Johnuniq, my particular proposal was for the link to be used in an infobox, something like this.


 * This is just a quick and dirty example that could be changed in as many ways as infobox will allow. Editors are already using the FTL tool in Library resources box, etc.. 64.40.54.57 (talk) 02:16, 20 May 2013 (UTC)
 * Johnbod, the libraries don't need to sign up, all that needs to happen is for the url of the library OPAC to be added to the database, which is being done by request at this point. I don't know if there's any limit to the number of institutions that can be added to the service. The libraries in BC are there because I added a request, which you could do for your locals.  The Interior  (Talk) 02:38, 20 May 2013 (UTC)
 * Here's the request page:  The Interior  (Talk) 03:43, 20 May 2013 (UTC)


 * Comment. I don't think FTL is helpful. I tried using it moments ago and found out that Google books search was much more helpful.  Mohamed CJ  (talk)  11:23, 20 May 2013 (UTC)
 * Comment I really don't think 'further reading' should be in the infobox. And can we restrict searches so that it finds relevant books? Edgepedia (talk) 18:46, 20 May 2013 (UTC)
 * Comment, why in the infobox? Wouldn't this be more of an external link, or a see also item similar to how we treat wikicommons, or wikisources templates?--RightCowLeftCoast (talk) 06:52, 21 May 2013 (UTC)
 * Sounds good This is a definitely a good idea. I have just seen Bird article and there it is working wonderfully. The point Mohamed CJ has mentioned is valid too— most of the readers of Wikipedia will not need/never check those "find in your library" links. But, I personally strongly endorse the idea to provide an option to learn more about a subject. For example, I don't think not too many readers check Special:BookSources, but, that's a superb option! FTL can be a good alternative of "External links" and "Further reading" (since I can see it is providing "online books" lists too). About Johnbod's comment, that is correct, I am specially worried about WikiProject India articles and libraries, but, it can not be grows, until it is started. In my opinion, infobox should be the best place to add these links only if there are really some good material in the database! --Tito Dutta (contact) 02:35, 22 May 2013 (UTC)
 * Comment - Is there any way to automatically match&update the list of libraries that FTL needs, with the extensive list that we already have compiled at Book sources? The auto ISBN linking that we have works wonderfully, (eg ISBN 9780441012039), most of the time, and it would be a shame to have to manually replicate that entire list of libraries. –Quiddity (talk) 02:51, 22 May 2013 (UTC)
 * Thanks for your comment. I'm starting to go through that list now, when I don't have other explicit requests, concentrating primarily on the English-language libraries (since subjects and author names, unlike ISBN's, are language-specific).  So I'm hoping that before too long lots of libraries in one will be in the other.  I do need more detailed catalog linking information than just ISBN searches, but it may be possible for my templates and the BookSources service to draw on the same unified datasets down the line.  I'd be interested in hearing more from anyone who's involved with or knowledgeable about the BookSources implementation. JohnMarkOckerbloom (talk) 18:28, 22 May 2013 (UTC)
 * Comment2 - Using a random article example, George Carteret, I'd disagree with placing a link in the infobox (because we generally prefer to avoid external links within the body of an article as much as possible), plus not all articles have, or will ever have, an infobox, but.... possibly "Search Libraries" in the lefthand sidebar's Toolbox section? –Quiddity (talk) 02:51, 22 May 2013 (UTC)
 * In case FTL data is really helpful, in my opinion, placing it in infobox will make it more prominent and increase chance of getting noticed. In Infobox, article body ISBN links are placed which finally take to external sites. But, the only factor is— the amount and value of the data we are presenting! --Tito Dutta (contact) 03:04, 22 May 2013 (UTC)


 * Comment - should be like any-other external link. That is - in the external links section only.Moxy (talk) 17:29, 22 May 2013 (UTC)


 * This looks very much like an attempt to reinvent the Worldcat wheel. There is no chance of this ever being as comprehensive as Worldcat. Phil Bridger (talk) 18:59, 22 May 2013 (UTC)
 * Support. I can't understand Phil's objection; as I read it, this is completely different from Worldcat.  Rather than helping readers find all the locations of one work, it's meant to help readers find all the works in one location that deal with a specific subject.  It seems to be good for saying "Since you want to learn more, go to your local public library and borrow Title1 or Title2 on this subject", and that's a wonderful thing for us to be able to provide — basically like a geo-located and automated ==Further reading section.  Nyttend (talk) 23:20, 22 May 2013 (UTC)
 * "Rather than helping readers find all the locations of one work, it's meant to help readers find all the works in one location" that is an excellent description of the difference between WP:Forward to Libraries and WorldCat. Thanks very much for that, Nyttend. 64.40.54.104 (talk) 02:11, 23 May 2013 (UTC)
 * Worldcat has keyword search of book titles, just as FTL appears to, and for each book will order the list of libraries by distance from your indicated location, so will not only find what is in your local library but will also tell you the closest library that has a book. Phil Bridger (talk) 12:15, 23 May 2013 (UTC)
 * Although WorldCat fits my individual needs better (because I use several libraries, and would have to set this to one of them only--WC goes by area code, if you're willing to supply it) I very strongly think that for most people the proposed link is the best way to go. Having it directly part of our interface would be very  good.  BTW, I note that WorldCat is relatively useless outside the US and Canada, listing only the very largest national and university libraries. This proposal should be usable anywhere, as long as the library is listed. It's the basic function we   need, and considerations of what else individual might want should not interfere with adopting it. .   DGG ( talk ) 22:26, 24 May 2013 (UTC)
 * I find it very useful here in the UK. Phil Bridger (talk) 22:37, 24 May 2013 (UTC)
 * Yes, its use is expanding there. Similarly in Australia. DGG ( talk ) 04:12, 25 May 2013 (UTC)


 * Comment I'm a supporter of this template, and I don't think it replicates the WorldCat service; OCLC is great way to determine where to find a specific item in my preferred libraries, but this template offers something different - the ability to see what my library holds on a topic with a single click. The benefit to readers is huge, and we need to start working more on libary/WP synergy.  As far as placement goes, I always pictured this link in the Further reading section, seems to be a good fit, and a good place to "roll out" this template as it evolves.  Kudos to JM Ockerbloom for his initiative on this!  The Interior  (Talk)

Request for SWF Functionality
As I'm sure we're all aware, SWFs are not available for upload to Wikipedia or Commons, and there are many good reasons for this, the proprietary formatting being a major reason. However, I recently received a grant to create Adobe Captivate tutorials to assist new editors in editing the Wikimedia sites constructively. The project page is located at WP:VIDTUT. I have one prototype out that has received feedback (more is always appreciated) even though I haven't opened the RfC, yet, and I have two that I'm going to roll out any day, now. I plan on making this a continuous project, and I'd love to have interactivity and incorporate it into a CVUA or Adoption training program. However, I can't do that without the ability to upload SWF files, and, to the best of my knowledge, nobody can do that. I propose that we enable a select group (perhaps administrators or file movers) to upload SWFs. --Jackson Peebles (talk) 04:11, 23 May 2013 (UTC)
 * I'd like to see us permit any useful file format, but since we're blindly dedicated to the free software movement, I can't see this succeeding: even if we get consensus here, WMF will say "We don't care; it's eeeeevil because it's proprietary". Nyttend (talk) 04:24, 23 May 2013 (UTC)
 * I understand your point, Nyttend, and I ran into that in the deliberations over my grant proposal(s), but they did give me the grant, and I'm 'assuming' they knew it would come out in SWF. I'd love to get consensus here for this particular project or right and bring it to the WMF Board.  I'd like to keep this conversation going, if possible.  Interactive video tutorials, especially when static close-equivalents are available for those with limited resources, are better than none at all.  --Jackson Peebles (talk) 04:36, 23 May 2013 (UTC)
 * Oh, I misunderstood. In that case...


 * definite support, since it would seem to be helpful without drawbacks. Nyttend (talk) 04:40, 23 May 2013 (UTC)
 * "SWF" is SWF, that Adobe Flash file format? There are some other meanings...  WhatamIdoing (talk) 06:42, 23 May 2013 (UTC)
 * This is really a Commons issue, not a local issue. --Rschen7754 10:14, 23 May 2013 (UTC)
 * He does say "upload to Wikipedia or Commons"; we could always upload locally if it were enabled here but not at Commons. Nyttend (talk) 11:57, 23 May 2013 (UTC)
 * Indeed. --Jackson Peebles (talk) 21:18, 24 May 2013 (UTC)


 * Oppose I expect that issues with being able to upload untrusted code that will run in users' browsers will not be easily overcome. I also disagree with so blithely dismissing the concerns about it requiring non-free software. Anomie⚔ 21:10, 23 May 2013 (UTC)
 * Anomie, thanks for your comments. I agree with your concerns.  Do you have a recommendation?  --Jackson Peebles (talk) 21:18, 24 May 2013 (UTC)


 * Why do your SWF files have to be hosted on-wiki? Couldn't you put them somewhere like Wikimedia Labs (successor to Toolserver)? (I'm not saying there is no reason why they must be on-wiki, but I haven't been able to see one.) Also, even if SWF files were enabled for upload here, there doesn't seem to be any MediaWiki support for displaying Flash objects in wiki pages, without installing an extension (the SWF extensions on all look pretty dodgy, and I don't think the devs will want to install them here). — This, that and the other (talk)  08:11, 24 May 2013 (UTC)
 * This, that, how do I do this? Forgive me for my ignorance. — Preceding unsigned comment added by Jackson Peebles (talk • contribs)
 * It's not easy. You'd do well to ask someone who already uses Labs - perhpas one of the users listed here who you recognise as an English Wikipedia user. To be honest, I think we need a bigger discussion about how MediaWiki and Wikipedia supports video and interactive content, but any changes could take a very long time to materialise. — This, that and the other (talk) 01:04, 25 May 2013 (UTC)


 * Speaking as someone who primarily edits and views Wikipedia with an iPad I'd like to see some sort of video/animation that actually works on mobile devices. Flash isn't it, it requires too much memory and is not supported by many mobile platforms. The whatever it is we have now doesn't work for me either. Beeblebrox (talk) 21:05, 24 May 2013 (UTC)
 * Beeblebrox, would we somehow be able to implement HTML 5? I can do that, too... — Preceding unsigned comment added by Jackson Peebles (talk • contribs)

Proposal to adjust special page
The page that comes up after one sends an email via the Special:EmailUser page displays the following text:

Your email message has been sent.

You can notify users that you have emailed them by leaving a talk page message. The you've got mail template is available for this purpose.

Return to User:NAMEOFUSER. (with link)

I would propose that the link in the final sentence go the emailed user's talk page instead of their user page, seeing as the ygm template is for user talk pages. It is a very minor issue, but why not improve it? Support as proposer. AutomaticStrikeout ?  22:50, 23 May 2013 (UTC)
 * FWIW re: technical implementation, the interface message MediaWiki:Emailsenttext only defines the first two lines; it looks like the "Return to User:NAMEOFUSER" change would be a mediawiki change.  Theopolisme ( talk )  14:06, 24 May 2013 (UTC)

WQA replacement - Finding an alternative.
WP:WQA was closed down for being ineffectual. The consensus of the closure discussion was: The first point was obviously followed through. As was the last to a decent extent. Finding an alternative was not... The admins here obviously have alot on their plates as it is. And the other forums all require the opposing user to want to take part, which isnt always the case. Dropping the requirements for adminship likely isnt palatable to many editors Perhaps there is another way... Another class of editors in between regular users and admins. The moderator. My idea of these editors would be they would essentially be standard editors with some powers in regards to general civility and conduct. All enforcements would be temorary in nature, and they should not have block rights. They would have no power to decide the outcome on content issues. any severe cases should be passed onto admins as they already are at this stage. The exact details would need to be decided by the community, but, perhaps there is promise in the idea. Of course, other users may have similarly interesting ideas, which could turn out even better than this one that I thought of in only 5 minutes or so... I think we need something along these lines as new editors get driven away by the poor behaviour of some editors, and occasionally so do long term editors aswell. Thoughts? - Nbound (talk) 10:42, 24 May 2013 (UTC)
 * Close WQA.
 * Find an alternative.
 * Not redirect it to ANI.

My first thought is that you should review PEREN before making any such proposals. This type of idea has been proposed and rejected many, many times, and I don't see anything is this very vague idea that seems like it would overcome the issues that have led the community to reject such an idea over and over. Beeblebrox (talk) 20:55, 24 May 2013 (UTC)


 * Its also just one idea, and if other people have better ones, than I'm all ears. Just seeing if I can create some discussion on replacing WQA, and replacing it with something more effectual. Whether that be through moderators, or something else. I hold no particular loyalty to the idea I've suggested, just trying to get the ball rolling. -- Nbound (talk) 23:06, 24 May 2013 (UTC)


 * The problem is that there's some division at Wikipedia on what counts for civility violations, and what to do about them. There are some people who believe that rudeness, direct attacks against others, calling people names, etc.  creates a poisonous work environment that drives away volunteers who have a lot to offer to Wikipedia but would rather not deal with all that mess, and so don't.  Then there are other people who believe that it's OK to call someone rude names, insult their character, call into question their intelligence, use creative circumlocution to avoid violating the letter of WP:NPA, or otherwise try to bully them out of Wikipedia so long as they have a different opinion from you.  The first group, who think that the difficult social environment is the major problem with editor retention and recruitment, and the second group who believes that those people are just the Civility Police and need to "grow up" are never going to see eye to eye, and as such there will never be any way to implement a process which satisfies the first group in maintaining a positive and productive working environment, and which also allows the second group to still call people rude names or insult them whenever they want.  -- Jayron  32  23:48, 24 May 2013 (UTC)


 * Surely the first group would strongly outnumber the second, allowing a consensus to be formed, given the right proposal. -- Nbound (talk) 00:22, 25 May 2013 (UTC)
 * Well, it depends on what you mean by outnumber. Across the entirety of Wikipedia, I have 100% confidence you are correct.  However, in any specific discussion dealing with civility issues at Wikipedia, whether it is about a specific user or incident, or about handling incivility issues as a Wikipedia-wide issue, there are always roughly an equal number of people from both camps who comment.  Thus, while it may be true that most Wikipedians want a way to maintain a positive work environment, most discussions about doing so result in a 50-50 split of actual participants in that discussion between "lets do something to make it better" and "grow up and just deal with it".  Which is why we always end up here.  Having this same discussion.  Over and over.  -- Jayron  32  00:37, 25 May 2013 (UTC)
 * Fair enough, hopefully the greater community stands up for itself before the editor drain gets too bad, and before Wikipedia's name gets tarnished by the behaviour of some editors. -- Nbound (talk) 02:44, 25 May 2013 (UTC)

Preventing RfC's on DYK's
Get this: some mook has now initiated an RfC on a DYK, for crying out loud. There's no telling what this sort of thing might lead to, so a suggestion to add text preventing this type of behavior in future has been made, here: Wikipedia talk:Requests for comment Herostratus (talk) 03:15, 25 May 2013 (UTC)

Hatnote proposal
A few months ago I wrote an “Introduction to” article and an “Overview of” article to complement an existing article. I notice that neither or these two articles are getting many hits compared to the original article. A similar observation was made at Talk:Angular momentum. Could this be because the hatnote associated with the original article is not particularly prominent. I designed an alternative hatnote which is shown below:

I would like to try this out for a week or so on the article Metric system to see whether there is an increase in the hit rate of the “Outline of” and “Introduction to” articles. If this does result in an increased hit rate, then it would not be difficult to create a template with a few standard messages. Any comments? Martinvl (talk) 19:44, 16 May 2013 (UTC)
 * I think it isn't an inherently bad idea, although the notice is a bit large--although that is kind of the point. :P In moderation, though, I personally don't have a problem with a trial, although maybe a slightly smaller size would be preferable.  Theopolisme ( talk )  20:46, 16 May 2013 (UTC)


 * Hatnotes and notices are part of the interface, so their very presence takes away space from the article. Presumably viewers came to read the article, so anything that detracts from that experience is not a positive. I think we need smaller hatnotes, not big distracting banners. Praemonitus (talk) 23:22, 17 May 2013 (UTC)
 * No to this specific proposal, we don't need a hatnote that looks like a maintenance template. I have no opinion on some other kind of hatnote. Anomie⚔ 21:09, 19 May 2013 (UTC)


 * @User:Praemonitus: Yes, I agree that readers came to read this article, (in this case Metric system). However many readers might find it too technical, so I want to tell them that they might find Introduction to the metric system more appropriate to their needs.
 * @Everybody: Taking on board what others said, here is an alternative layout.


 * Martinvl (talk) 21:01, 22 May 2013 (UTC)
 * Still looks too much like a maintenance template to me. Anything with an mbox style will. Anomie⚔ 21:02, 23 May 2013 (UTC)


 * Another proposal:


 * I have tried using small text to enable the crucial question to be highlighted. Also the use of blue rather than red or orange is less "hostile".
 * Martinvl (talk) 13:51, 24 May 2013 (UTC)


 * Oppose: This template adds unnecessary clutter to address a problem for a small minority of viewers. Just no. Praemonitus (talk) 16:45, 25 May 2013 (UTC)

File-nuker as user-right..
I'd like to request that 'file-nuker' (i.e. File deletion) be split from sysop rights and implemented as it's own user right.

This is so that it could be granted (or removed) independently, without needing to confer full admin powers, on individuals that for the most part only handle images.

It would also conversely allow for the removal of image deletion rights from admins (without affecting other powers) in the event of a disputes about those admins interpretation of image policy.Sfan00 IMG (talk) 07:03, 24 May 2013 (UTC)
 * Do you have any examples where the current situation has led to problems? Phil Bridger (talk) 20:42, 24 May 2013 (UTC)


 * No. Deletion and blocking rights should not be unbundled, much less weapons of mass deletion. The potential damage is simply to high and, just like Phil, I am not aware of any actual current problem in this area that would necessitate such a drastic change. Beeblebrox (talk) 20:59, 24 May 2013 (UTC)
 * Perennial proposals. I'm surprised to see a long-time editor like you even propose this.  WhatamIdoing (talk) 01:25, 25 May 2013 (UTC)


 * Thank you for the responses, Although I have to ask for a clarification as to why allowing the revocation of image deletion rights separate from other rights would be a bad thing. Sfan00 IMG (talk) 08:48, 25 May 2013 (UTC)
 * I don't know if revocation of image deletion rights separate from other rights would be a bad thing, but unbundling these rights from admins is clearly not justified. Did you read Perennial proposals already?  smt cha hal  talk 09:26, 25 May 2013 (UTC)
 * Sfan00 IMG, you first need to explain why this would be a good idea, to give us something to base the discussion on, before asking others to explain why it would be a bad idea. After all, you are the one who started this discussion. Phil Bridger (talk) 12:52, 25 May 2013 (UTC)


 * Oppose. No clear indication  why  this is necessary. IMO a solution  looking  for a problem and a possible  back-door attempt  at  unbundling  the admin  tools -  for which  all  discussions have failed to  meet consensus. Kudpung กุดผึ้ง (talk) 16:26, 25 May 2013 (UTC)

Pending changes reviewing log
Why don't we have a pending changes reviewing log, that shows whether a pending change was accepted or denied by the reviewer?  smt cha hal  talk 06:24, 25 May 2013 (UTC)

All right, we already do. Never mind.  smt cha hal  talk 11:11, 25 May 2013 (UTC)

Qworty clean-up
There has been repeated desire signaled for organizing editors to review User:Qworty's article contributions for any issues following recent revelations regarding his editing. As of now there has been a lot of ad-hoc discussion, some of it on the article talk page of Qworty's bio, but it would be much more appropriate to have a centralized area in userspace or projectspace for this sort of coordination. Any ideas or suggestions are welcome.-- The Devil's Advocate tlk. cntrb. 20:24, 25 May 2013 (UTC)


 * Much of the cleanup has already taken place. I performed some, others performed a lot; there have been many eyes looking for the possibility of problems. Let me hazard a guess that we no longer need a cleanup project. Perhaps someone who is interested could create a list of fixes. Binksternet (talk) 20:34, 25 May 2013 (UTC)
 * I don't think a formal wikiproject is necessary, but just some place in userspace or projectspace where people can resolve any outstanding issues.-- The Devil's Advocate tlk.  cntrb. 20:50, 25 May 2013 (UTC)
 * Of course you don't think a formal project is necessary. And of course it probably is. We have no idea really how much of the vandalism we've addressed. Given the scope of his activity, I suspect we're still in tip-of iceberg territory. And the overwhelming communal will to cover this up needs countering every step of the way. NaymanNoland (talk) 20:58, 25 May 2013 (UTC)

Without a list of his known sock-puppets, editors will have no way of knowing how much damage was done by Robert Clark Young. I think that saying "it's fixed now" is a poor way to treat editors who have been subjected to years of abuse by Qworty and his unknown number of sock-puppets -- and who, like me, may have very little trust in the authority-figures who told them "nothing's wrong" in the first place and are now telling them to "move on, it's all over." Please publish the list of of Robert Clark Young's sock-puppets. Please publish links to the purported 13,000 edits he made. Let us judge the scope of the problem and the extent of the repairs that have been made for ourselves. Thank you. 70.36.137.19 (talk) 21:06, 25 May 2013 (UTC)
 * It's pretty clear that Devil's Advocate has moved the discussion here in hopes that it will get lost and die out. Which isn't going to happen. Is there an appropriate place for this, where the conversation can continue properly without being subject to constant diversionary tactics? NaymanNoland (talk) 21:12, 25 May 2013 (UTC)


 * List of sockpuppets:
 * Sockpuppet investigations/Qworty/Archive
 * Basically, Young performed many different edits to Wikipedia on a score of accounts, many of them used only briefly, and a bunch of IPs, especially ones starting with 4.246.120. I have spent hours combing through these edits and I think most of the problems are fixed. It is not lightly that I conclude we do not need a cleanup project. Binksternet (talk) 21:15, 25 May 2013 (UTC)
 * Well, Young performed a series of major revenge edits on the Barry Hannah entry. Very few of these appear to have been fixed. And if that entry is still a mess, then we've dealt with almost NOTHING. NaymanNoland (talk) 21:35, 25 May 2013 (UTC)
 * WP:SOFIXIT if you think more clean up needs to be done, just do it. The Pedia regularly has people get together and do such things when there is a problem editor, but it hardly ever serves a purpose to complain that someone else should do it, and TDA was correct to get it off the subject article talk page, as that is not a forum for that discussion. Alanscottwalker (talk) 21:44, 25 May 2013 (UTC)
 * As I say, I HAVE been doing it. But we don't even know what needs addressing. Fine: let's not use the talk page, if it's inappropriate. But let's face it, the conversation will be bounced from this page as well - it already has been from other pages, because there's a concerted effort to bounce it into oblivion. So let's find it a permanent home, where the various people researching this complex business can weigh in. That's the only way it's going to get fixed. NaymanNoland (talk) 21:58, 25 May 2013 (UTC)
 * Knock yourself out: User:NaymanNoland/Qworty Clean-up Project. It's a little strange to argue that it's been moved so much that it needs to be moved again, though.&mdash; alf laylah wa laylah (talk) 22:03, 25 May 2013 (UTC)
 * Alf, I'm surprised that you're not on my side here - you've been one of the few consistently sane voices in this debate. If you think that this really is an appropriate PERMANENT place for this discussion, then by all means let's keep it here. I suspect it isn't, but I don't feel like initiating the cleanup project myself, for reasons I've discussed on my own talk page and elsewhere. What's important is that it get done.  You saw the inactivity on the Brad Vice entry - I'm fairly sure that nobody would have gotten around to it had we not taken the initiative. There has to be a central place to list what needs doing, so that this kind of thing happens in a rigorous way. NaymanNoland (talk) 22:17, 25 May 2013 (UTC)
 * I'm not not on your side. Just click the red link and start a discussion.  Stay out of it after that if you want to. You don't need permission. If you don't feel like initiating but you think it's essential that it be done you're kind of at an impasse since it doesn't seem like anyone else wants to start it.&mdash; alf laylah wa laylah (talk) 22:23, 25 May 2013 (UTC)
 * Well, I hope it's not because of my remark about your baffling sentence: I was joking. (It's what happens when you're editing Wikipedia pages - I've concocted much weirder ones.) Anyway, I've set up the Project. Will announce it below. NaymanNoland (talk) 22:37, 25 May 2013 (UTC)

Thank you. Is this list complete? Are there more? 70.36.137.19 (talk) 21:53, 25 May 2013 (UTC)
 * List of sockpuppets:
 * Sockpuppet investigations/Qworty/Archive
 * (reposted from below) There are no confirmed sockpuppets on that list. It is useless as such.  Unscintillating (talk) 22:50, 25 May 2013 (UTC)


 * Qworty Cleanup Project Now Initiated:
 * Okay, we're up and running. Let's deal with the Qworty vandalism/sockpuppetry in one place: http://en.wikipedia.org/wiki/User:NaymanNoland/Qworty_Clean-up_Project Note: I'd rather not have my name as the name of the page itself - I did that per Alf's suggestion, but is this necessary?  I've never set one of these up before. Is it perhaps simply the way to get it started, after which it gets moved to a page with the proper title? (Man I'm sick of the constant page bouncing.) NaymanNoland (talk) 22:47, 25 May 2013 (UTC)
 * There are no confirmed sockpuppets on that list. It is useless as such.  Unscintillating (talk) 22:50, 25 May 2013 (UTC)
 * The list is here: Wikipedia:Sockpuppet_investigations/Qworty/Archive Should I simply copy and paste it into the new page? NaymanNoland (talk) 22:53, 25 May 2013 (UTC)
 * Sorry for the confusion, I have moved the comment to where it was supposed to go. I have also posted at WP:ANI#Qworty follow-up.  Unscintillating (talk) 00:12, 26 May 2013 (UTC)

"Updated since last visit" markers
It has been over a year since watchlist notification was turned on, only to be hidden immediately after. Now that the CSS has long been changed to allow better control over how to show changed watchlist items, I proposed to change the bullets back then, which met no opposition, but I never got around to implement it. So if there are no objection, I can put CSS in place the will replace the standard bullets ( and ) with green bullets ( and ), and re-enable the reset button. — Edokter  ( talk ) — 11:12, 6 May 2013 (UTC)


 * Questions What do you mean by reset button, what would that be doing? Regarding the bullets, I don't really see the benefit of having the green bullets over having the grey ones. --  Toshio   Yamaguchi  12:08, 6 May 2013 (UTC)
 * The green bullets lets you see that pages have changed since you last visited them. The reset button appears above the list to reset the green bullets to their default state. — Edokter  ( talk ) — 12:40, 6 May 2013 (UTC)
 * Are there different green bullets, something not 3D? ~ Amory ( u  •  t  •  c ) 13:44, 6 May 2013 (UTC)
 * No. — Edokter  ( talk ) — 22:42, 7 May 2013 (UTC)
 * Toshio, do you have a watchlist at any other Wikimedia sister projects? This is just the "Pages that have been changed since you last visited them are shown in bold" feature, but improved, because bold is not the only option. (We can now: just color the background, or change the bullet, or keep it just bold, anything. Individually, with css.). –Quiddity (talk) 05:58, 8 May 2013 (UTC)
 * So the green bullets are just another watchlist customization like
 * '' .mw-changeslist-line-watched {
 * font-weight: normal;
 * font-style: italic;
 * } ''
 * I am using in my common.css that shows you changed pages with a green bullet? Well, if that's the case, then I support turning it on by default, as long as it doesn't interfere with using another customization (like the italics I am using). --  Toshio   Yamaguchi  22:14, 12 May 2013 (UTC)
 * I believe so. Please confirm, . –Quiddity (talk) 20:08, 15 May 2013 (UTC)
 * Confirmed. — Edokter  ( talk ) — 21:40, 15 May 2013 (UTC)


 * Support. I like the minimal plan. Just remember to update the docs at Customizing watchlists, and all should be fine. –Quiddity (talk) 05:58, 8 May 2013 (UTC)
 * Strong oppose as before. This marker is completely redundant with my watchlist. I don't visit the vast majority of the pages on my watchlist anyways - many are on the list only to keep track of discussions without actually reading them.--Jasper Deng (talk) 06:11, 8 May 2013 (UTC)
 * You don't want it, and that's fine. Why do you not want anyone else to have it? –Quiddity (talk) 21:43, 8 May 2013 (UTC)
 * Support I like the idea a lot. Please go ahead. --Anthonyhcole (talk · contribs · email) 06:20, 8 May 2013 (UTC)
 * Question What is the benefit of making this the default? Why can't we just list it as another customization at WP:CUSTOMWATCH? If there is a convincing reason to make this the default, I am willing to support it, but right now I don't see what that would be. Now of course everybody could argue I want customization XYZ as the default, but why bother? Anybody not satisfied with the default one can customize his own. I smell featuritis here. --  Toshio   Yamaguchi  13:04, 16 May 2013 (UTC)
 * What we have now is a "customization" that is being forced on all users by default. If you wanted to have "plain", then we'd go to the Mediawiki default (which is bold-faced text), just like the CENT-listed RFC here supported back in December 2011, and tell the couple dozen power users who immediately freaked out over the change that they're the ones who have to go to the trouble of changing their settings to get the old, non-standard style.  Using the Mediawiki default has the notable advantage of being consistent with what all users see at all the other WMF websites as well as at most non-WMF wikis that are running the same software.  Using a non-standard default has no inherent advantages, although using a visible non-standard default is better than using a default that effectively disables the feature.  WhatamIdoing (talk) 16:39, 16 May 2013 (UTC)
 * The default of bolded new things is hardly unique to mediawiki default, either - it's standard across a lot of software and applications, especially email clients, where new message subjects will be bolded until they're opened. So using the default also has the advantage of being consistent with the users' experiences on entirely other apps. -— Isarra ༆ 18:54, 19 May 2013 (UTC)
 * Oppose - arbitrary colour changes aren't good for differentiating things unless their consistency can be widely guaranteed, and when these only support specific skins on a single project, these cannot. Please just restore the default and list this as a customisation option for those who prefer it. -— Isarra ༆ 18:54, 19 May 2013 (UTC)
 *  Comment Support - Honestly, I think that much of this will be resolved with the new "flow" (or whatever they're calling it) system WMF will soon be implementing. Check out wikimedia-l if you have no idea what I'm talking about, or let me know if I totally misunderstood the proposal.  With my current understanding, though, this would be a waste of valuable time right now if it's going to be replaced, regardless.  ---Jackson Peebles (talk) 04:21, 23 May 2013 (UTC)
 * Not really. Flow is just for user talk pages, and maybe other discussion pages in the future. This is still useful for articles and other types of pages. Anomie⚔ 21:01, 23 May 2013 (UTC)
 * Thank you for the explanation, Anomie. I have amended to support.  --Jackson Peebles (talk) 21:13, 24 May 2013 (UTC)
 * Support Although I agree with those above that really we should just go back to the default bold. Anomie⚔ 21:01, 23 May 2013 (UTC)

OK, let me get my meltdown-suit. — Edokter  ( talk ) — 16:54, 25 May 2013 (UTC)
 * ...and you did so without consensus. The above discussion is definitely insufficient for this; the markers are already rather annoying for me and I don't see a way to disable it.--Jasper Deng (talk) 18:17, 25 May 2013 (UTC)


 * Oppose. It creates eyestrain to even see it, and I strongly agree with Jasper Deng. There is now discussion also at WP:Village Pump (technical). --Tryptofish (talk) 21:22, 25 May 2013 (UTC)


 * Opt out - After the Watchlist War of a year ago many users had a custom script to hide these notification gimmicks entirely. Today's change has overridden that opt-out script so we need a new opt-out mechanism.  When are the code writers going to learn that on en.WP you do nothing that doesn't have an opt-out switch built into it right from the start? You ask what makes en.WP so special? The fact that it has over 4 million articles and a commensurately very large number of other pages; that there is a large "core" of highly active editors who have thousands of pages watchlisted, not a few dozen. If I watchlist every single page on the entire Afrikaans Wikipedia (the only other one I work on) my watchlist there would still have only a tiny fraction of the activity that my en.WP watchlist does. I don't ever look at probably 90% of the entries on my en.WP watchlist as they are obviously trivial changes. Thus the green lights, bolding, underlining, dancing leprechauns, or whatever other "you haven't looked at this terribly important(NOT!) change yet" notification gets dreamt up, are all just visual clutter. I don't want it, so where is the off switch? Do we really have to fight the exact same battles over and over and over and over and over and over and over and over and over and over and over and over and over again? Roger (Dodger67) (talk) 22:01, 25 May 2013 (UTC)
 * Correction: It was made opt-in a year ago by those peoaple that did not want any change. One had to install a script to enable it in the first place. That was an unacceptable situation because it is a default function of the software. Now that that has finally been remedied, we can focus on a proper opt-out option. There will be new a script/gadget to opt out. — Edokter  ( talk ) — 22:35, 25 May 2013 (UTC)
 * Comment It has always been my feeling that a change like this one will need broader community input. I remember that I opened an RfC on the day of the software opt-in change by the system administrators and I mostly saw opposes.--Jasper Deng (talk) 22:59, 25 May 2013 (UTC)
 * Which overrode a huge community consensus to have the feature enabled in the first place. I'll never forgive you for that. — Edokter  ( talk ) — 23:13, 25 May 2013 (UTC)
 * In my opinion, that proposal wasn't advertised properly, and that "huge" consensus was probably 1/3 of the participation I would've expected for that change.--Jasper Deng (talk) 23:24, 25 May 2013 (UTC)
 * I find you opinion of no importance; you killed a usefull feature for the wrong reasons. I've re-enabled it (now that it is possible without the bold) and so far, you're the only one complaining, again wihtout any concrete argument. — Edokter  ( talk ) — 23:36, 25 May 2013 (UTC)
 * Opt out - IMO it's awful & a pain to keep resettiing especially if you have WP:Noticeboards in your watchlist. -


 * →Davey 2010→ →Talk to me!→  00:19, 26 May 2013 (UTC)

proposal vs. implementation
the actual implementation of the proposal had some "side effects" which were not mentioned in the proposal itself, and should be reverted, at least until they are discussed and agreed on. specifically, the text "changed since your last visit" in the history was hidden. i could not understand from the original proposal that this will be so, and i daresay that maybe some of the people who Supported it did not understand this also. i ask that this part of the change will be reverted (basically it's the line that adds " to Mediawiki:Common.css. peace - קיפודנחש (aka kipod) (talk) 21:33, 25 May 2013 (UTC)
 * Yes, totally, someone please do this. In the meantime, the discussion linked above has fixes one can implement personally.  Ignatz mice•talk 21:36, 25 May 2013 (UTC)
 * Please bring back the green text highlighting (see Village pump (technical))... AnonMoos (talk) 22:00, 25 May 2013 (UTC)
 * OR we can discuss first without panic-reverting. Yes the side effect of removing the 'Updated since last visit' was a last minute change. I did that because the history page basically shares the same default styling (bold) and classes as the watchlist. The 'Update...' seemed a bit redundant with the bullet now indicating a change, and it gave me a change to remove a whole lot of clutter on a line of history.
 * But to cut to the chase; to restore it, use this:


 * — Edokter  ( talk ) — 22:06, 25 May 2013 (UTC)
 * I don't agree that the bolding/dotting and the "updated since last visit" are the same at all. For example, I quite often use those to figure out where to start looking at diffs, if there have been five or ten edits to separate discussions on a page. You may or may not have had consensus to change the dots (I don't care either way), but you didn't say anything about the updatemarkers.  Ignatz mice•talk 22:13, 25 May 2013 (UTC)
 * Error on my part. Still, the saving in real estate should count for something. — Edokter  ( talk ) — 22:22, 25 May 2013 (UTC)


 * The problem with such a fundamental change like removing the updatedmarker is that it destroys cross Wiki experience. I have updatedmarkers on dewiki, commons, meta and mediawiki, etc. so it's inappropriate to have them removed on English Wikipedia. If you want the colored bullets that's OK, since it doesn't change content substantially. Removing the text at the same time is not OK, especially since it can be done easily by a user CSS or a gadget.
 * Customizations to the default WMF MediaWiki appearance should always be kept at a minimum, especially when removing content (that should probably never be done! --Patrick87 (talk) 22:18, 25 May 2013 (UTC)
 * I'm sorry, but when watchlist notifications was turned on over a year ago after a major consensus, and subsequently disabled by a vocal 'opt-in' faction, crosswiki experience was already killed back then. We would not have this discussion if the default styling was left enabled. — Edokter  ( talk ) — 22:29, 25 May 2013 (UTC)
 * What kind of argumentation is that? "We broke it so I can break it further"? I don't know what you mean by "watchlist notifications" but until a few hours ago everything looked consistent for me, then I started searching missng updatedmarkers on English Wikipedia (that got lost without even a notification). --Patrick87 (talk) 22:33, 25 May 2013 (UTC)
 * As far as I'm concerned, I repaired the watchlist. The updated marker on history pages are a side effect that can be restored if so desired. — Edokter  ( talk ) — 22:38, 25 May 2013 (UTC)
 * And several other people think otherwise. The color difference is almost noticeable once I know to look there; the text is noticeable period. Please restore it. People can get rid of it if they care enough to figure out how.  Ignatz mice•talk 22:45, 25 May 2013 (UTC)

(Changed since your last visit)
I know I may have been hasty in replacing this aspect with the green bullets, and will restore it if so desired. But I would like to make a case for the real-estate saved in this change; one line in a history page is already so cluttered that I thought this might be a welcome change. So let's put the pros and cons together here. — Edokter  ( talk ) — 22:42, 25 May 2013 (UTC)
 * There is indeed a strong argument to be made about reducing clutter. But for people who use screenreaders, or can't differentiate colors well, or don't see well generally, or just plan like the more obvious one, this is terrible. There's nothing wrong with changing the colors. But there needs to be something much more than that as well. Perhaps just the word "updated" next to the bullet in the history page? I don't know if that would work. Seems to me the "updated since last visit" text is best, and removing it is fixing (debatable) something that is barely broken, if at all.  Ignatz mice•talk 22:51, 25 May 2013 (UTC)
 * Good point about screenreaders; I'm restoring those markers now. — Edokter  ( talk ) — 23:05, 25 May 2013 (UTC)
 * Thank you! --Patrick87 (talk) 23:12, 25 May 2013 (UTC)

Enhanced watchlists
So there's now a notice at the top of my watchlist that says "Pages that have been changed since you last visited them are shown with a green bullet." But this isn't the case, because I'm using the enhanced watchlist, which has little arrows instead of bullets. This is fine – I don't want the green bullets – but I'm just pointing out that this notice is confusing. I don't suppose it's possible to detect whether I have the enhanced watchlist enabled, and if so, hide the notice? Or else just expand the notice to say "(unless enhanced watchlist is enabled)". DoctorKubla (talk) 09:40, 26 May 2013 (UTC)
 * OK, that's a challenge. Default styling would be bold page titles, as with the regular watchlist. The enhanced watchlist uses tables, but the page has no classname to indicate it is the enhanced watchlist, so I can't hide the buttom in CSS. What I could do is a opt-out gadget reverting everything to the prior default state. — Edokter  ( talk ) — 10:22, 26 May 2013 (UTC)
 * OK, gadget is in place. — Edokter  ( talk ) — 11:13, 26 May 2013 (UTC)
 * Doesn't seem to work as intended; it turns off the green bullets, but doesn't remove the notice or reset button. I hate to be a pain, though, so I'll add that it doesn't matter that much to me – I can live with it. :) DoctorKubla (talk) 20:52, 26 May 2013 (UTC)
 * Works on my end. Note the reset button will re-appear if you also have the bold option selected. — Edokter  ( talk ) — 21:04, 26 May 2013 (UTC)

Shouldn't Gadgets add functionality instead of removing it? Wouldn't it be more logical to create a gadget that adds the green bullets (could be enabled by default, I like the green bullets, not that you get me wrong), and remove the custom code from common.css? That's the way gadgets are meant to be. Not blowing up common.css with functionalities that you have to write opt-out gadgets afterwards. Especially in case of a code changes that could potentially break the new styling, currently one has to change both, common.css and the opt-out gadget. The other way round only the gadget had to be adapted. --Patrick87 (talk) 14:05, 26 May 2013 (UTC)
 * I concidered making the green bullets a default gadget, but that would not solve the problem of the enhanced watchlist still showing the reset button. Either way, it would require users with the enhanced watchlist to change the option to remove the button. I'm open to better solutions. — Edokter  ( talk ) — 14:54, 26 May 2013 (UTC)
 * The reset button is still useful with enhanced watchlists, if you have 'mark unvisited pages in bold' enabled. It's just the description of the green bullets that's wrong then. But I guess it's not trivial to remove only that. &mdash;&thinsp; H HHIPPO  15:48, 26 May 2013 (UTC)
 * I agree with you, Patrick87. Let's remove all the extraneous CSS affecting this feature and go back to the MediaWiki default bolding. Anomie⚔ 23:16, 28 May 2013 (UTC)
 * I kind of like the green dots (now that the green text is back, too), but I would support a return to the default on the watchlist itself. Perhaps the thing to do is to write a "make it go away forever, no matter what changes are made to the CSS" script for use by the couple of dozen opponents from last year's override-the-RFC debacle to use, and then (having given them a bit to install it) to go back to the default on the watchlist.  This won't affect me, since I've already installed the script to mimic the normal system even if someone mucks with the CSS, but I think it would be preferable to have the crosswiki default experience match for the thousands of multi-project users who will expect it.  WhatamIdoing (talk) 23:40, 28 May 2013 (UTC)

Concise wikipedia proposal
If anybody reading this hasn't commented here I really need some input on here whether you support or not.♦ Dr. ☠ Blofeld  12:47, 27 May 2013 (UTC)

Proposed addition to the toolbox
I'm proposing that we add a new link to the sidebar &mdash; "Subpages". This would appear in the toolbox menu on any editor's userpage, project namespace pages, or anywhere else that the subpage policy applies. Right now, the quickest way to access a page's subpages is to click "page information" in the toolbox and follow the link in the bottom of the first table. But unless people have actually read the subpage policy in its entirety, they may not even be aware of this function; until just recently, I looked for subpages by checking an editor's contribution log, scrolling to the bottom, and clicking the relevant link in the footer. I didn't even know there was such a matrix for project namespace subpages (nor any other namespace, for that matter). A "Subpages" link in the toolbox itself would be faster and more accessible, both for new users and experienced editors. It has already been in use over at Wikimedia Commons for roughly six years now, where it's proven itself convenient.

As far as I'm aware, this was proposed only once before, yet received absolutely no attention at the time. Thoughts? Kurtis (talk) 09:59, 6 May 2013 (UTC)
 * Support. I would find that very useful.  Ignatz mice•talk 11:48, 6 May 2013 (UTC)
 * Fine by me. I've occasionally found it useful on Commons. Rd232 talk 11:49, 6 May 2013 (UTC)
 * Support. I am supportive of anything that encourages more use of subpages. Although I currently have code in my common.js to create a link to my subpages at the top of pages where Preferences, Watchlist etc are, I don't mind the redundancy (which would be only for me). (See also the proposal Village pump (proposals)/Archive 92 I made). --  Toshio   Yamaguchi  12:01, 6 May 2013 (UTC)
 * Support, great idea. It's been forever since I noticed the box you mention at the bottom of Special:Contributions — the only way of checking subpages that I know is Special:Prefixindex, and I've been here since 2006.  Nyttend (talk) 12:15, 6 May 2013 (UTC)
 * Sure. I've had one in my personal js for ages, hugely useful. ~  Amory ( u  •  t  •  c ) 13:40, 6 May 2013 (UTC)
 * Strong support. I would find this incredibly useful. &mdash; TORTOISE  WRATH  21:06, 8 May 2013 (UTC)
 * Strong support seems like a very sensible suggestion. AutomaticStrikeout ?  03:11, 15 May 2013 (UTC)
 * Support: I like ideas like this that make the web sites that I frequent easier to use.  —&thinsp;RandomDSdevel (talk) 21:43, 21 May 2013 (UTC)
 * Support I'd use it more if i were reminded about it this way; it would also make it easier to spot problems hidden there.  DGG ( talk ) 20:35, 24 May 2013 (UTC).
 * Support. Even though I don't have much use for it, it surely will save the few seconds it takes for me to type Special:PrefixIndex/ in the browser address bar.  smt cha hal  talk 09:07, 25 May 2013 (UTC)
 * Strong support This would be incredibly useful to me. ö   Brambleberry  of   RiverClan  23:22, 25 May 2013 (UTC)
 * That's a page tool, not a site tool. Should be a tab or whatever the skin does with its page action stuff. Although I'm not sure why I'm complaining since the sidebar is already a horrible confusing mess in this regard; the link itself is certainly useful regardless of where it is. -— Isarra ༆ 01:14, 30 May 2013 (UTC)

Background and Style Changing
Hello my friends, I posted this suggestion on the Help desk and referred me to here. (My question & User answers copied to here!): Dear Sir / Madam

Please accept my sincere gratitude for your efforts.

Is there any way to change white background of Wikipedia Pages to black or a gray color for better reading (for eyes) and charge saving on AMOLED mobile devices, like fast "Style Options" (that changes text and background colors proportionally) on Yahoo!?

I searched and asked it on your good live-chat help service and suggested link below: http://meta.wikimedia.org/wiki/Help:User_style

Thanks, it's OK, but i mean a simple and fast way for every user in any level. I wanted to suggest that but first for sureness asked it! Please if not exists, suggest it to site developers, i think it is an important thing for readers and it's necessary for reading in different situations: Day, Night, Indoor, Outdoor, Different eyes, ... apart from display contrast changing. Please dedicate a simple button for fast style changing, PLZ!

With best regards, Your user — Preceding unsigned comment added by Laginto (talk • contribs) 10:20, 25 May 2013 (UTC)
 * WP:Village pump (proposals) is probably the best place to make this sort of suggestion.


 * If you go to user preferences at the top right of any page there is a 'gadgets' section choice that puts green text on black if you have the 'Monobook' skin selected in the 'appearance' tab of the same preferences pages. I don't know if this will be any better.--Canoe1967 (talk) 19:00, 25 May 2013 (UTC)
 * (End of copy, from Help desk/Archives/2013 May 25)

I'm not sure how useful this is, but I've cobbled together something that changes the background of the main article bodies to black and the text to white. It also changes the links to orange, as blue is too hard to see. It is very preliminary—for example, for some reason it doesn't change the text of section headers, so those show up as black-on-black. If you want to use it, paste this line to you common.css page:  Hope this helps.  Ignatz mice•talk 03:50, 30 May 2013 (UTC)

Move, not merge, Meta to the Commons

 * The following discussion is closed. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
 * This discussion needs to take place at Meta and at Commons, with the involvement of both their communities, which are largely distinct from our community as they include editors from different projects and those who do not speak English. The proposal needs to be translated so it's available to as wide an audience as possible and it absolutely has to be where interested parties can find it. That place is not leaving it tucked away on the English Wikipedia, at the bottom of the relative backwater that is the Village Pump (proposals) page. Nick (talk) 13:53, 31 May 2013 (UTC)

Meta would still exist if it were moved to, not merged with, the Commons. Meta would still be Meta. It would just be located on the Commons. Instead of Meta-Wiki, it would be the Meta Project, or Meta Coordination, or some similar name. All the documents would still exist. Everything would continue on: board elections, steward elections, chapter documentation, translations, Wikimania bidding, policy drafting, committee work, GAC/FDC, etc.. The only difference would be that they occur on the Commons. Outreach, strategy, and useability projects could occur on the Commons too. The Commons watchlist would tie them all together. Far more editors from around the world would participate. --Timeshifter (talk) 04:46, 31 May 2013 (UTC)
 * Oppose - Commons and Meta serve very different purposes: Commons is a file repository, and Meta is Wikimedia's administrative center - so it only makes sense to keep them on different wikis. Besides, this is not for the English Wikipedia's community to decide.--Jasper Deng (talk) 05:03, 31 May 2013 (UTC)
 * The Commons can be whatever we want it to be. --Timeshifter (talk) 05:48, 31 May 2013 (UTC)
 * No. It can be what it's community and/or the foundation wants it to be.--Jasper Deng (talk) 05:57, 31 May 2013 (UTC)
 * We all are part of Commons and Meta. Discussion occurs everywhere, not just on Meta. The Foundation listens to all of us everywhere (theoretically). --Timeshifter (talk) 06:00, 31 May 2013 (UTC)
 * Well, my point is, it's for their community to decide and not ours. Commons and Meta do actually have distinct communities separate from this one.--Jasper Deng (talk) 06:02, 31 May 2013 (UTC)
 * But you're disenfranchising the rest of the Wikimedia community by having it over here - what about people who do not speak English? --Rschen7754 06:03, 31 May 2013 (UTC)
 * I am for more discussion, not less. Please start discussions on other-language Wikipedias. --Timeshifter (talk) 06:06, 31 May 2013 (UTC)
 * That would be your responsibility, as the proposer. However, what's important is that the Commons and Meta communities are notified and discuss this.--Jasper Deng (talk) 06:08, 31 May 2013 (UTC)
 * I will notify the Commons. I see Meta people here already. --Timeshifter (talk) 11:13 pm, Today (UTC−7)
 * Speaking as a "Meta person", it still needs to be advertised to the whole community.--Jasper Deng (talk) 06:18, 31 May 2013 (UTC)
 * I notified the Commons via the Village Pump. I will notify Meta. --Timeshifter (talk) 06:25, 31 May 2013 (UTC)
 * I notified Meta at the Wikimedia Forum and Meta:Babel. --Timeshifter (talk) 06:29, 31 May 2013 (UTC)


 * Oppose this is not something that enwiki has control over. --Rschen7754 05:05, 31 May 2013 (UTC)
 * The discussion has to start somewhere. Explain to me why you guys on Meta closed discussion on a similar topic the same day it was proposed by the respected editor, User:Rd232, here: Proposals for closing projects/Closure of meta-wiki. It was a proposal to move Meta to another wiki, or to its own namespace: "a Meta: namespace which is accessible across all Wikimedia projects (in the same way that Commons files are accessible everywhere in the File: namespace." --Timeshifter (talk) 05:48, 31 May 2013 (UTC)
 * The functionality isn't there. Besides, Meta has various namespaces of its own, so this would only confuse matters.--Jasper Deng (talk) 05:57, 31 May 2013 (UTC)


 * This will never happen for many reasons. But as much as any other reason, this will never happen for the same reason that the Simple projects, Wikiquote, and Wikinews will never be closed or merged: it's required that you notify and discuss this with the local community. A discussion here quite simply cannot decide an issue of this nature. It would have to take place on Meta-Wiki. But I imagine you already knew that. :-) I agree that we need crosswiki watchlists. I think taking baby steps toward that would be a better use of time than debating whether to move Meta-Wiki anywhere. --MZMcBride (talk) 05:07, 31 May 2013 (UTC)
 * Baby steps on WP:Integrated watchlists does not seem to be adequate so far. See my reply above to Rschen7754. Also, Meta would not be merged with Commons. It would be moved to the Commons. Meta pages would have their own URLs: Something like commons.wikimedia.org/meta --Timeshifter (talk) 05:48, 31 May 2013 (UTC)
 * I've had an integrated watchlist userbox for some time. This is not the way to proceed with it, however.--Jasper Deng (talk) 05:57, 31 May 2013 (UTC)
 * I created that userbox. It is not enough. See: User:Timeshifter/Userboxes/Integrated watchlists. --Timeshifter (talk) 06:11, 31 May 2013 (UTC)
 * I support the concept. However, I think you need to review the purposes of Meta and Commons. Merging the two is the wrong approach to this idea.--Jasper Deng (talk) 06:16, 31 May 2013 (UTC)

Comment. Some of this has been discussed in various locations. For example; see the comments from many editors here: Wikipedia Signpost/2013-01-07/Op-ed, "Op-ed. Meta, where innovative ideas die". --Timeshifter (talk) 06:04, 31 May 2013 (UTC)
 * Comment I must note that when you put one wiki's content on another, it's by definition called merging. There's no such thing as "moving".--Jasper Deng (talk) 06:08, 31 May 2013 (UTC)
 * It is called redirecting the URL. It is moving. --Timeshifter (talk) 06:11, 31 May 2013 (UTC)
 * No. When two wikis' contents come together, it's merging, regardless of anything else. Just for example, their admin systems would have to be unified.--Jasper Deng (talk) 06:14, 31 May 2013 (UTC)
 * Admins would have to be merged, but Meta pages would be in separate directory, such as:
 * commons.wikimedia.org/meta --Timeshifter (talk) 06:23, 31 May 2013 (UTC)
 * That would not work on a technical level (firstly, because commons.wikimedia.org/wiki is the root of all Commons URLs, and secondly, all Wikimedia wikis use the /wiki subdirectory). You've just demonstrated that your proposal is about merging the two projects, because their communities would have to merge and agree on policies.--Jasper Deng (talk) 06:30, 31 May 2013 (UTC)
 * No, it is not difficult for people to think of more than one thing. And as someone who has edited on many websites, I know that URLs are easy to redirect. I have had webmasters do it. It is very simple for them. Meta would have a separate URL such as commons.wikimedia.org/wiki/meta --Timeshifter (talk) 06:38, 31 May 2013 (UTC)
 * No. MediaWiki does not work that way - that would simply be a subpage system under "meta". Again, you're missing the point here, which is that you cannot just mix those two websites without their communities having to accommodate it. Their communities must develop consensus for this proposal and have to be willing to do the work here.--Jasper Deng (talk) 06:40, 31 May 2013 (UTC)
 * They are called directories or folders. Nothing that complicated. The Meta admins would actually get a lot of help for all the work, because far more people go to the Commons. --Timeshifter (talk) 06:45, 31 May 2013 (UTC)
 * Again, no. Do you not know how URL rewrite rules work on Wikimedia sites? You can't nest one wiki's directory inside another's.--Jasper Deng (talk) 06:47, 31 May 2013 (UTC)
 * I edit regularly on Wikipedia, Commons, Wikia, Shoutwiki, and have edited on Meta, Strategy, Mediawiki, Bugzilla, Wikibooks, Wikisource, Wikiversity, Wikiquotes, etc... I am a bureaucrat at Wikia, and a steward on Shoutwiki. It wouldn't be one wiki nested inside another. It would be a project inside the Commons. See my original post in this topic: "Instead of Meta-Wiki, it would be the Meta Project, or Meta Coordination, or some similar name. All the documents would still exist." I grant that the technicalities for URL rewrites when moving pages on MediaWiki are different. But I don't believe it will be that difficult. --Timeshifter (talk) 06:55, 31 May 2013 (UTC)
 * You have not considered how these two wikis differ on a technical aspect.--Jasper Deng (talk) 07:17, 31 May 2013 (UTC)
 * Please see my reply to billinghurst below. --Timeshifter (talk) 07:20, 31 May 2013 (UTC)


 * Can we stop this short-sighted and under-developed proposal, it is not appropriate to have this discussion on a back-water wiki like this.  Put simply that enWP is not the place for this discussion> It belongs at RFC if it is to be had at all.
 * It won't work, meta is setup specifically to have a unique and different foot print. An example includes the ability for blocked IP addresses to be separately controlled to the global so that blocked users can contact stewards. There are a range of these settings controlled that would have consequences for Commons functionality or dynamics.
 * There are a number of global settings to which you simply do not want newbie admins to have access
 * With regard to your reflections about the meta community, it is what you make of it. While you have your opinion on what you consider better, there are clear technical reasons why it is not a good idea. — billinghurst  sDrewth  06:34, 31 May 2013 (UTC) and to fully declare I am an admin here, commons and meta, (among others) so have some knowledge and equal CoI
 * English Wikipedia is hardly a "back-water wiki". I am sure there are a few technical services that might need further protecting, revising, or moving elsewhere. But nearly everything else would easily move to the Commons. --Timeshifter (talk) 06:42, 31 May 2013 (UTC)
 * Oh feisty. The discussion simply doesn't belong here. Though it seems that you aren't listening, and too busy fighting paper tigers. Give it up, it is an ill-judged proposal, and your continued conversation just exposes your lack of knowledge. — billinghurst  sDrewth  07:00, 31 May 2013 (UTC)
 * The discussion needs to happen in multiple locations. It has happened in bits and pieces already here and there. English Wikipedia has by far the largest number of editors worldwide that check its watchlist. So this is a good place for some of the discussion. As to my lack of knowledge, I edit regularly on Wikipedia, Commons, Wikia, Shoutwiki, and have edited on Meta, Strategy, Mediawiki, Bugzilla, Wikibooks, Wikisource, Wikiversity, Wikiquotes, etc... I am a bureaucrat at Wikia, and a steward on Shoutwiki. --Timeshifter (talk) 07:03, 31 May 2013 (UTC)
 * That's not particularly relevant if you are getting basic Wikimedia cross-wiki concepts wrong.--Jasper Deng (talk) 07:17, 31 May 2013 (UTC)
 * For example? --Timeshifter (talk) 07:20, 31 May 2013 (UTC)
 * You should know very well, for instance, that Commons is what its community decides, not what our community decides. You should also know that the place to propose something like this isn't a project that will see very little effect from such a change, rather than the projects being affected. You also get the roles of Meta and Commons and how Wikimedia organizes its sister projects grossly wrong.--Jasper Deng (talk) 07:25, 31 May 2013 (UTC)
 * That is why we are discussing it. Discussion happens first. I notified the Commons and Meta about this discussion via their Village Pump and Community Forum. --Timeshifter (talk) 07:30, 31 May 2013 (UTC)
 * That is why we are discussing it. Discussion happens first. I notified the Commons and Meta about this discussion via their Village Pump and Community Forum. --Timeshifter (talk) 07:30, 31 May 2013 (UTC)


 * Latest Signpost discusses Meta. See: Wikipedia Signpost/2013-05-27/Foundation elections. Meta: "a specific kind of mess"? --Timeshifter (talk) 07:23, 31 May 2013 (UTC)
 * Oh the oracle has spoken, you read it in Signpost. Anything to do with the Foundation elections is related to the elections, not the technical configuration or purpose of meta. You conflate issues and put forward ill-conceived ideas as solutions. I'll move on, you aren't listening. — billinghurst  sDrewth  07:32, 31 May 2013 (UTC)
 * Well, I read the Signpost article, and commented. And you are incorrect about the Signpost article. It discusses the purposes of Meta, and more. --Timeshifter (talk) 07:36, 31 May 2013 (UTC)


 * "English Wikipedia has by far the largest number of editors worldwide that check its watchlist." So? That means you can decide whether meta should be merged/moved/whatever? First of all I fully agree with Billinghurst. There are lots of good reasons why meta should be a separate project: for global blocks - and the appeal of it; the global spam blacklist, local and global rights changes etc. Second, why do so many people dislike meta? I know of Ignore Meta ... but I still don't get it. We try to be as helpful as possible, but it clearly doesn't work everywhere and for everyone. Ow, and eh, oppose of course. It should (and may) never happen. Trijnstel talk 08:45, 31 May 2013 (UTC)
 * Please read the Signpost articles and comments. I note that you are coming from Dutch Wikipedia. Feel free to discuss this idea there. Just as you don't understand why many people dislike Meta for its parochialism due its relatively small number of editors that look regularly at its watchlist, I do not understand why you would dislike doing Meta activities using the Commons watchlist. Meta would get far more editors involved from many more countries if people could use the Commons watchlist. Do you not want more editors from more countries involved in Meta activities? --Timeshifter (talk) 09:07, 31 May 2013 (UTC)
 * You don't seem to understand the role of meta... We don't need a large community as it's only a hub project used for global stuff. Trijnstel talk 09:23, 31 May 2013 (UTC)
 * Global stuff needs global involvement. I looked again at Ignore Meta and I don't agree with some of it. But its talk page is interesting. It points out that admins on Meta don't get scrutinized as thoroughly as on other wikis. There are more Commons admins, and they deal frequently with the global community far more often than Meta admins. So they generally seem to understand better the points of view of people from other countries. Commons admins seem much friendlier than Meta admins. I have over 19,000 edits on the Commons, and over 26,000 on English Wikipedia. Meta was moved from English Wikipedia long ago. I bet countering systemic bias had something to do with it. But the Commons, in my experience, is very good at dealing with people of all types from around the globe. --Timeshifter (talk) 09:34, 31 May 2013 (UTC)
 * "Commons admins seem much friendlier than Meta admins." Luckily I'm both. ;) Trijnstel talk 11:01, 31 May 2013 (UTC)

'''Comment. Wikimedia Foundation elections.''' There would be a lot more community feedback and questioning of candidates if candidate discussion occurred on the Commons or on English Wikipedia, instead of only on Meta as a separate wiki. See: Wikimedia Foundation elections/Board elections/2013/Candidates and Questions. Few people check the Meta watchlist. Many more people from many more countries check the Commons and English Wikipedia watchlists. So move Meta to the Commons as a sub-entity called Meta Central. I like this question from Nemo: Dozens WMF private wikis and "no place to work together". --Timeshifter (talk) 10:53, 31 May 2013 (UTC)


 * The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Additional global bot right request on meta
Hi! There is currently a request for global editinterface rights for Addbot open on meta wiki here to allow the bot to edit protected pages to remove interwiki links that are already on wikidata. It has been proposed that a second global bot group be created that includes the following flags (edit, editprotected, autoconfirmed). This is not something stewards want to rush into as the flag would allow the bot to operate on protected pages and would prefer to have a wider participation in the request for approval before any action is taken. All comments should be posted at (meta:Steward_requests/Global_permissions#New_global_permissions_group) ·addshore·  talk to me! 14:55, 1 June 2013 (UTC)

Proposal: Move long-term proposals from PUMPTECH to VPR
As a method to extend longer periods of discussion about long-term issues, I suggest people move lengthy topics from wp:PUMPTECH, to here quickly, to encourage practical proposals, as solutions to really solve problems, and check back here with the follow-up details. Otherwise, the overall discussions at PUMPTECH tend to get bloated as too detailed for that forum, or to get rushed to archive when people are too busy to reply, or the solution is just a limited quick fix, or another thread is started with no links to the previous threads archived earlier. If the PUMPTECH proposals, moved here, get too massive, then I suggest to create another Pump page, as Pump Extra (VPEXTRA), to retain those long-term, detailed topics moved from PUMPTECH. -Wikid77 (talk) 16:33, 1 June 2013 (UTC)

Deprecate one of two ref methods
I have just been assisting a new editor, who was adding  to an article that already included. The existence of two methods is redundant, and confusing. Can we deprecate one or the other? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 13:01, 29 May 2013 (UTC)
 * Yes I agree with you, and I think  can go, and while we're at it, why not change   into  ?  Lova Falk   talk  13:38, 29 May 2013 (UTC)
 * "Deprecating" is not the same as "getting rid of". We could use bare HTML like this as well; recommending against it is not the same as eliminating it.  Curly Turkey (gobble) 23:00, 29 May 2013 (UTC)
 * is implemented in terms of . (The code actually calls it indirectly using the #tag magic word.) How do you want to let the latter go while retaining the former? The software has to provide the functionality in one way or another, and if it can be called from a template like reflist, it can also be called directly.—Emil J. 14:31, 29 May 2013 (UTC)
 * Personally, I hate it when people convert into  since I find two-column reference lists for articles with many refereneces to look far cleaner and easier to follow than the mess that 30em creates.  I don't see the latter as being an improvement, and would not support making it the default. Resolute 15:36, 29 May 2013 (UTC)
 * What kind of "mess" is being created? For most users,  and  produce the same thing.  (It depends on the font size and screen width, but that seems to be the commonest result.)  WhatamIdoing (talk) 18:11, 29 May 2013 (UTC)
 * On a widescreen with reasonable resolution, I often end up with three or four column lists, references crossing three or four indivdual rows and what becomes a massive wall of text. IMO, it decreases readability. Resolute 20:28, 29 May 2013 (UTC)
 * When an editor uses short references, the problem is the opposite: hard columns result in massive amounts of white space on a wide-screen monitor. Perhaps the recommendation should be the same as for other aspects of referencing: whoever does it first gets to chose the formatting.  That way, those of us who prefer column widths get to keep them, and those who prefer a hard number of columns get to keep them, too.  Curly Turkey (gobble) 23:04, 29 May 2013 (UTC)


 *  support don't care  Favor reflist as it is well featured, mature and simpler to use for advanced cases. As to, see Template:Reflist/doc. We can't eliminate , but we can remove it from help pages and error messages, which will reduce confusion for new editors. --   Gadget850talk 15:03, 29 May 2013 (UTC)
 * As usual, this has become a discussion of off tangent discussions. It might as well be closed because the point is being entirely overlooked and I am certainly not facile enough to cut through the bullshit. --  Gadget850talk 23:28, 29 May 2013 (UTC)


 * oppose. Don't try to make dogs of any age learn new tricks when they are perfectly content with the old ones. GeorgeLouis (talk) 15:18, 29 May 2013 (UTC)
 * We would not, and can not remove — it will always work. reflist is a wrapper for . We can simplify documentation for new users. --  Gadget850talk 15:31, 29 May 2013 (UTC)


 * It would be acceptable if you encouraged new users to use by changing help pages. Deprecating   is a bad idea since it's a core function of MediaWiki (and we probably never should deprecate any of them). --Patrick87 (talk) 17:40, 29 May 2013 (UTC)
 * There's nothing wrong with &lt;references/>, it's simple and works. The last thing we want is to see lots of people going around just to replace it with to no benefit. The solution to the original problem is to help educate the new user, not to try to change all of Wikipedia. &mdash; Carl (CBM · talk) 18:07, 29 May 2013 (UTC)
 * You are correct. This will not pass and we should delete reflist. --  Gadget850talk 19:17, 29 May 2013 (UTC)
 * I wonder how much any of this will matter when WP:VisualEditor is running (beta becomes default for all users in about six weeks!).  WhatamIdoing (talk) 18:13, 29 May 2013 (UTC)
 * Good point! Do we know about any sort of integration planned thus far?  Theopolisme ( talk )  18:27, 29 May 2013 (UTC)
 * Does it support references at all yet? --j⚛e deckertalk 18:29, 29 May 2013 (UTC)
 * AFAIK, no--right now they're not at all editable. However, I imagine there must be a roadmap somewhere...  Theopolisme ( talk )  18:32, 29 May 2013 (UTC)
 * If AfC deploys without it, I predict that it will have signficant, negative effects on several processes on Wikipedia. But I can only complain about this fact so many times, so ... *sigh* --j⚛e deckertalk 19:27, 29 May 2013 (UTC)
 * I believe that the devs have already promised not to make VE the default unless and until it provides basic support for editing refs. There are updates about once every two weeks.  I'm not sure what features appeared in the last one.  WhatamIdoing (talk) 07:06, 30 May 2013 (UTC)
 * Oppose deprecating the fuller-featured Reflist due to functionality. I can't imagine it's worthwhile making the effort getting rid of the core MW equivalent, but I wouldn't hate it if somehow we ended up with only the template.  Just seems like a lot of work for little gain.  --j⚛e deckertalk 19:33, 29 May 2013 (UTC)
 * The proposal is really just to decrease the prominence the simple version currently has in documentation. -- As Gadget850 says above, "We can't eliminate, but we can remove it from help pages and error messages, which will reduce confusion for new editors". –Quiddity (talk) 23:43, 29 May 2013 (UTC)
 * I support that. --j⚛e deckertalk 06:30, 4 June 2013 (UTC)
 * Support a minor simplification of the documentation. That's all that's really being proposed. –Quiddity (talk) 23:43, 29 May 2013 (UTC)
 * Comment. As can't be removed (see, below), perhaps the "deprecation" ought to be understood as applying to the documentation.  (Strong support on that.)  If the existing instances are troublesome, perhaps they can be "bot fixed". ~ J. Johnson (JJ) (talk) 20:17, 30 May 2013 (UTC)
 * Definite support making things less confusing for newcomers at little or no cost, as clarified by Quiddity. MartinPoulter (talk) 12:18, 4 June 2013 (UTC)
 * Support simplification of the documentation per Gadget850 -- John of Reading (talk) 04:36, 5 June 2013 (UTC)

Explanation
 to all transclusions of GDFL in every transclusion, provided that there was no value set for migration?'' Would anyone object to a bot using this technique to fulfill B's request? Nyttend (talk) 02:12, 7 June 2013 (UTC)
 * I am going to take exactly one stab at this:
 * We can not remove, it is integral to , the software that runs the system.
 * Reflist is merely a wrapper for that adds support for columns,, groups and predefined groups with list style. All of this can be accomplished with just , but it requires more markup.
 * The proposal has nothing to do with columns and the eternal debate over which number is correct.
 * The proposal is to favor one method over the other through documentation change.
 * is so much simpler; here is how to do columns:
 * How many transclusions are we talking about? That means: How often is transcluded and how many of the transclusions are not already migrated (e.g. still without any parameter)? --Patrick87 (talk) 13:20, 8 June 2013 (UTC)
 * Did someone go and do this already? I see Category:Wikipedia license migration candidates is almost empty. Anomie⚔ 14:40, 8 June 2013 (UTC)

software proposal
> I've been using Wikipedia for years like most of the people in this world. I was wondering have you ever though to enable users/writers to also give a kind of video explanation. Let's say additional tool which would make  Wikipedia  the most complete on line encyclopedia. Video Toll that will enable users/writers to compete on the same matters, so that viewer can choose by voting ,(maybe by voting ,not good idea) the best possible option,obviously among ,already exsiting written option.The toll which will complete the already written information >my software mmDevice® software is a Combination of video, audio, slides/text/graph and provides flexibility to create both on-the-fly and more sophisticated presentation/lesson/news pieces.It enables   simple creation of any kind of presentation using web cam and or external video footage supported by slides in harmony with video  on line and in real time' 'exactly how Wikipedia users are doing right now for written information(.Using four simple buttons users is able to create an interactive and creative presentation on line, depends on user creativity. NO POST PRODUCTION -REAL TIME example some one is looking  for Integer sequence normally will find a text in Wikipedia, explaining what is Integer sequence and if you can give additional explanation ,let's say how to resolve Integer sequence with this kind of sample ,it will complete information. http://www.dailynewpost.com/BreakingNews/Education/Articles/242226907/sat---mathematics---numbers-a.aspx

second sample Root canal you have text in Wikipedia http://www.dailynewpost.com/BreakingNews/Education/Articles/221626212/root-canal-treatment-and-tooth.aspx

and so on... Obviously platform has necessary tools to control/flag/shade/cancel   abuse articles/users My platform has a self produced ad platform which can be taken away for your purposes. Technology is now implemented in social journal. Thanks for your attention — Preceding unsigned comment added by Mmdevice (talk • contribs) 07:32, 8 June 2013 (UTC)

Auto-correct more edit-conflicts

 * Discuss below: "".
 * Earlier: "User_talk:Jimbo_Wales/Archive_134"
 * Note: This is an extensive analysis of edit-conflict problems.

Proposal: I propose that more simple edit-conflicts should be auto-corrected, to merge the 2nd editor's changes for obvious cases. Earlier discussions treated edit-conflicts as "inevitable" or low-priority for WMF. However, edit-conflicts in section-based editing, or in separate parts of a page, are already auto-merged. So, let's fix more problems, and the more we discuss the issues, then perhaps we can reach consensus on how to merge multiple changes. The rationale is simple: as more people join Wikipedia, then more edit-conflicts are likely, and we need to prepare to reduce them before the crowd arrives. I think we should just start talking about various scenarios, and suggest patterns to auto-fix the edit-conflicts. Some scenarios (numbered as "S n ") to consider: In the initial analysis of edit-conflict problems, it can be easily seen that many talk-pages involve mainly the accumulated additions of multiple replies, as perhaps the easiest type of auto-correction during an edit-conflict. So then, merely retro-insert the 2nd reply, as inserted before line n+1, to appear after the 1st reply. In fact, the auto-correction of talk-pages might use some different (simpler) rules, as compared to the auto-correction of article edit-conflicts. The more we discuss these various issues, then the more we can find a consensus where the 2nd edit should override the first, or perhaps the auto-correction should warn of numerous changes, as if trying to edit after vandalism, or hack edits, which should most-likely be halted, to allow totally reverting the prior edit, not auto-merging of the changes which might conceal the prior hack edits. The auto-correction could be kept simpler, at first, then improved later. For example, by treating long lines of text as "auto-lines" or sub-lines of 50-character segments, then the auto-correction could be treated as simple line-for-line recombinations of changes, even with thousand-character lines, if that were easier to verify. Start with simple ways to auto-correct the text. Anyway, let's fix those many, many simple edit-conflict problems.
 * S1: Two replies after same message: I think this might be the most-common fear, and I suggest to insert the 2nd reply after the 1st reply, so the logic would be to insert an edit-conflict reply not exactly after line n, but rather, insert the 2nd reply before old line n+1. In practice, it is often easy to spot the original line n+1 after the message, and hence to auto-correct, then insert reply_2 after that message+reply_1.
 * S2: Two edits change the same line: A simple fix would be to treat a line as two halves, and simply combine changes to each half deleting/adding text, else the latter change overrides the first change. However, I think, with a little analysis, the removal/addition of text could be combined in subtle cases, as perhaps matching 10 characters either before/after the changed text, else use the line contents from the 2nd edit (as replacing that line).
 * S3: Line(s) deleted during 2 edits: When the 1st edit deletes the lines, then small changes to those lines in the 2nd edit should be ignored, but conversely, lines deleted by the 2nd edit take precedence and should be removed. As in S1, new text lines (or replies) should be inserted before line n+1, after the deleted lines. To re-sync with the original line count, then deleted lines should perhaps be considered as empty text at those old line numbers, until the page is saved. The software might need to have extra internal line-counters to skip the deleted lines after combining the texts.
 * S4: Lines to change already deleted: When only a few words would be changed, then ignore 2nd editor's requested change to lines already deleted, else raise edit-conflict because 2nd editor might want to restore/change the many deleted lines.
 * S5: Numerous lines differ: In cases where perhaps, 50-100 lines differ, then I am wondering if the software should issue a warning, where the prior revision was hacked wildly, or the text might actually be editing a different page, so treat that as a major edit-conflict (not auto-merged).
 * S6: Changes could be interpreted in 2 ways: In some cases, the software might judge a change as 2 different possibilities of changes, and in such cases, perhaps look-ahead and choose the simplest path which avoids multiple differences after that point. Often the easiest solution is to merely count the number of "unchanged" lines after that point, and the "right" path will have far fewer mismatched lines.

Conclusions so far: Most of the talk-page edit-conflicts are very easy to auto-correct, and I see no excuse for having edit-conflicts in busy talk-pages. It indicates a serious failure to correct a very common, easy problem, as perhaps due to fears about more-complex edit-conflicts within articles. So, let's fix them separately, not let fears of complex cases then paralyze the fixes for simple cases. That is the status. -Wikid77 (talk) 07:20/17:11, 25 May 2013 (UTC)
 * Further considerations about edit-conflicts: Some areas of Wikipedia have numerous edit-conflicts, such as the wp:Help_desk, where I have tried to assist in answering questions several times, but the edit-conflicts seemed to happen in "85%" of all help-replies (although edit-conflicts in 55% might be more accurate). Anyway, it did not take long to realize how answering the questions at the Help_desk involves redo for numerous edit-conflicts. Now it might seem the edit-conflicts merely show, hey, "that question was already answered" so just focus on the next question, but in practice, very many Help_desk questions could have 5 alternate answers, and so edit-conflict does not really stop duplicate answers, it typically rejects alternate solutions to those same questions. In short, the "only good edit-conflict is a vandal being thwarted". As for new articles about a major event, or recent tornado, or shipwreck, then I dread trying to help the editors update those articles.
 * Further analysis of edit-conflict pages: Fortunately, for years, many people have been logging the actual incidents, of each edit-conflict event, by embedding the "" template (which says: "") into many of the affected pages. So now, there is ample edit-conflict data to analyze, in WhatLinksHere/Template:ec as "9,936" links (10 thousand pages). A quick breakdown of the first 3,000 edit-conflict pages: 31% article-talk pages, 22% user-talk (like this page), 13% Wikipedia-talk (about policies or guidelines), 5% help-desk, 5% reference-desk, 2% village-pump edit-conflicts, but I will check more edit-conflict pages and refine the counts somewhat. Anyway, 31% (as article-talk conflicts) then means 69% of edit-conflicts were logged in user-talk (this page), policy-talk or other forums. Of course, people cannot mark live articles with "" even if the article main-namespace hid the message "" then other editors would continually remove the "ec" tags cluttering the text. I think to simulate the actual edit-conflict of article "xx" then check for "Talk:xx" in the WhatLinksHere, because the edit-conflict levels are likely to be similar, where conflicts in talk-pages would tend to reflect conflicts in the related article text.
 * Current support does Edit-merge but also Edit-clobber: To double-check the current handling of edit-conflict scenarios, I have re-tested as two editors concurrently changing top or bottom of the same page, where edit-conflict does auto-correction to edit-merge different areas of a page. So, the good news is that potential edit-conflicts were properly auto-corrected as edit-merge when the changes were in separate portions of the page, so a prior edit to page-top (infobox format) was then edit-merged with changes to page-bottom, as combining both edits. However, trying to re-edit the page-top (infobox) was reported as "Edit-conflict" until those attempted changes were removed, and then the SAVE was accepted as auto-correction to edit-merge the top/bottom of the 2 conflicting editors. However, when the same username ran 2 edits together for the page, then the 2nd edit (in conflict with infobox changes) caused an implict override, or "edit-clobber" of the first saved edit and removed all prior changes to the infobox, with no warning. So, that is a condition to beware, if a user edits the same page from multiple windows, then a 2nd edit might override the first edit (not warn edit-conflict), so be very careful to re-run a 2nd edit using the current revision.
 * Recent edit-conflict about major tornado article: As evidence of more edit-conflicts in current events, the page Talk:2013_Moore_tornado (Oklahoma, US) has the phrase "(Edit conflict)" posted on 21 May 2013. The phrase does not use the template {ec}, so that woke me to searching the talk-pages for text as "(edit conflict)" rather than just WhatLinksHere to the {ec} template, as tallied below.
 * Wikisearching "edit conflict" lists 36,014 tagged pages: So, beyond WhatLinksHere to template {ec}, when also counting people just putting phrase "edit conflict" in discussion pages, then the counts are: 8,664 (24%) article talk-pages; 14,069 (39%) user talk-pages; 8,374 (23%) Wikipedia-project pages; 3,363 (9%) Wikipedia-talk; 1,190 (3%) user pages; 250 (.7%) template-talk; or 330 other pages. Overall, 36,000 pages directly mention edit-conflicts, including 11,200 links to {ec} templates.

Discuss: Simple fixes of edit-conflicts
This subthread is for discussion of extensive edit-conflict issues, explained above (""). In prior discussions, some people noted the upcoming wp:FLOW features would avoid edit-conflicts in talks, but this proposal would also fix simple article edit-conflicts, such as when 2 editors insert into the same list, at the same line. Also, the proposal here is to fix more simple edit-conflicts, but not all. So, editor1 changes a top infobox, while editor2 changes a lower paragraph, and currently that triggers an edit-merge of both versions, but editor1 could also re-change some top infobox lines and save the whole edit without conflict. Any other thoughts? -Wikid77 (talk) 07:20, 25 May 2013 (UTC)
 * I just wanted to say that this analysis could be very useful for a developer who is interested in improving the handling of edit conflicts. You should consider linking to the oldid of this page in a relevant bugzilla report (you probably already know which one or ones to refer to). — This, that and the other (talk) 09:18, 25 May 2013 (UTC)
 * Beyond contacting current developers, there was also a request to show consensus to make changes, as needing to know many people consider the edit-conflicts a major problem, because the developers tend to prioritize changes, where an issue of wider concern might get fixed sooner. -Wikid77 17:11, 25 May 2013 (UTC)
 * I think that the devs already know that edit conflicts are a problem. I believe that the reason we have edit conflicts is because the problem is difficult, not because the devs don't think anyone cares. WhatamIdoing (talk) 23:46, 28 May 2013 (UTC)
 * Well, it's not so much difficulty, but rather choice of where to put a 2nd reply, originally intended at the line before 1st reply. I have noted the age-old "FIFO" (first-in, first-out) rule, where people queue-up at a window, and the first person is served first in order of the line of people. There is no need to post a queue "arrival-conflict" because there is a rule to resolve the conflict, and so use a similar rule for edit-conflicts. If the 1st editor deletes a line, then the changes intended for that line by a 2nd editor would be ignored, unless a threshold of numerous changes re-triggered a manual edit-conflict preview screen. -Wikid77 16:47, 1 June 2013 (UTC)


 * Edit-conflicts are numerous at wp:Help_desk or anywhere multiple people are encouraged to reply quickly to the same topics. To prevent edit-conflicts, it seems necessary to read-lock the page for a second, to insert changes, then unlock to synchronize the next update as reading from that latest page revision. -Wikid77 (talk) 15:58, 7 June, 01:12, 10 June 2013 (UTC)

Proposal: Have micro-pages as Micropedia-style articles
To support a quick, concise view of major topics (which tend to have massive articles), then I propose to create short summary-style pages in the style of Micropaedia, on English Wikipedia, with name format "Xxx (micro)". The suffix "(micro)" would indicate a micro-page format, and hence a page such as "Canada (micro)" would describe the nation as in page "Canada" but in concise, summarized form. The articles would allow complex vocabulary, as wikilinked to explain, but remain quite short, as compared to longer pages on the Simple English Wikipedia which can elaborate any topic using simple English sentences. Later, various templates, or navboxes, would link the various micro-pages, so the users could read each, back-to-back, when many concise micropages were ready for view. -Wikid77 (talk) 16:33, 1 June 2013 (UTC)


 * I can see the appeal, but isn't this what the lead of an article is for? ItsZippy (talk • contributions) 17:59, 1 June 2013 (UTC)
 * Micro-pages would be separate summaries, not intro/lead texts, with no intention to "lead" into a larger article. -Wikid77 20:04, 1 June 2013 (UTC)
 * Exactly. Not to put too fine a point on it, but it makes one suspect that you are not putting a lot of thought into proposals when you make three of them simultaneously. See my essay on policy proposals for more detail on that. Beeblebrox (talk) 18:13, 1 June 2013 (UTC)
 * I don't really see the appeal of this on-wiki-fork. Doomed to fail, not gonna happen. BTW: skimzee.com, Twick.it, Shortipedia.org. --Atlasowa (talk) 18:36, 1 June 2013 (UTC)
 * The micro-pages would be nutshell summaries, not a fork any more than "Talk:Canada" would be a fork of "Canada", however a fork/spoon analogy might be as a "shotglass" to digest the whole in an instant, rather than forked away from the main article. -Wikid77 20:04, 1 June 2013 (UTC)
 * Generally support: There are existing alternatives, such as the lede (opening paragraph[s]) and Overviews, as well as overall history articles written in summary style, such as World War II and History of New York City. But for non-historical or non-chronological topics, such alternatives often don't exist or don't work. In fact I've done significant work on some very long articles without reading them all the way through (e.g. War of 1812); I only just finishing reading Queen Victoria from start to finish. And I can't remember how long it's been since I read all of New York City at one sitting. (All three of these, by the way, are now or once were Featured or Good Articles). War of 1812 has long tried squeezing a summary into its lede or various Overviews without fully satisfactory results. ¶ For a counter-example, where the lede seems to do this job quite well, see Solar System (on the other hand, as a non-astronomer and non-physicist who hasn't read the whole article, I can't fully judge how well the lede balances the most important points.) See also Pi. ¶ An article where I've done most of the work (although I didn't create it), and which I'd gladly summarize for a Micropedia is New York City mayoral elections. I tried to create a couple of summary tables at the beginning, but for a Micropedia-type article, I'd probably omit the borough results and/or some of the percentages. For those, for example, who just want to check Fiorello La Guardia's opponents and margins of victory or loss, that would probably suffice. —— Shakescene (talk)
 * Good point on lede wording as different style with perhaps no main article: Each micro-page would function as a complete, separate nutshell, with perhaps a collapsed References section, and would not be restricted to rules for wp:LEDE, and so footnotes would be common inside the short micro-page. Also, a micro-page might exist without a like-named main article, and not act as a stub, but always remain a nutshell summary of each topic. Otherwise, a micropage could be considered a rewrite of a lede section, where it does not "lead" anywhere, and instead it must not rely on later text to expand details. Perhaps the clearest description would be, "A micro-page is a non-leading, self-contained summary of a topic". -Wikid77 (talk) 20:04, 1 June 2013 (UTC)
 * It may be difficult to keep the article and the micro-page consistent with each other. I'm also unclear why this is even needed. Praemonitus (talk) 20:35, 1 June 2013 (UTC)
 * Yeah, i think that is the problem a lot of us are having. It might be good if there were a clear explanation of why this would be desirable. Beeblebrox (talk) 21:23, 1 June 2013 (UTC)

See Concise Wikipedia‎ which User:Dr. Blofeld created months ago, and has a thread about (at ) halfway up this page... I see you've commented at meta, so you know about it. Why are you reframing his proposal without mentioning it? –Quiddity (talk) 21:31, 1 June 2013 (UTC)


 * See also:
 * User talk:Jimbo Wales/Archive 77 (June 2011) ("I know we have Simple English and WP:LEAD but the vast majority of articles do not provide an effective summary." Dr. Blofeld)
 * User talk:Jimbo Wales/Archive 120 (November 2012)
 * User talk:Jimbo Wales/Archive 135 (May 2013)
 * I see no point in discussing this again. If you build a tool to improve readability of WP articles, if you write better ledes on Wikipedia, if you contribute to simple english Wikipedia - that would be great. Or you can start building a concise fork (on wikia or somewhere else) and see how this works out. --Atlasowa (talk) 13:02, 2 June 2013 (UTC)

The wikipedia mobile site effectively does 95% of this proposal right now. You get the infobox then the lead followed by links to other sections. Get out your phone and try it out (or click 'mobile view' at the bottom of any page, even this one).

Starting a whole new project to get the last 5% hardly seems worth doing while when the same could be achieved by minor improvements to the lead paragraphs. filceolaire (talk) 18:59, 5 June 2013 (UTC)

In Wikipedia articles, we have the first sentence, and first paragraph, and entire introduction, (ie WP:LEAD in its various parts) which should be able to account for the rest of the required/desired lengths. Hence there are various Concise Wikipedia which are already trying to utilize that. Improving the Leads to our existing articles, for both in-article purposes, as well as re-use purposes, seems like a win-win situation. Starting an entirely new project (when we're already needing more volunteers for existing projects) seems like it wouldn't be helpful overall, at this time. Ideally, yes, we could have a synopsis of every topic in different limited lengths (120 characters. 400 characters. 1200 characters (the average MainPage FA blurb size), etc). Pragmatically, we don't have the human resources, and we should try to work with what we have. –Quiddity (talk) 17:16, 9 June 2013 (UTC)
 * WP:Lead sections lead to more, but micropages would not: Although the concept of micropages is simple, as very short, non-leading summaries of topics, many people imagine related ideas, such as forcing the wp:Lede section of articles to somehow summarize the topic with no leading images or wikilinked headers, and to seem self-sufficient as non-leading lead sections. That just is not it. Also, the micropages are not introductory tutorials to explain "what is calculus and why is it useful" nor are micropages like Simple Wikipedia with short sentences and limited vocabulary. Instead, micropages are short, non-leading summaries of topics which can contain complex terms wikilinked to other pages. They would exist as part of Wikipedia, not a "fork project". -Wikid77 (talk) 07:36, 9 June 2013 (UTC)
 * We will soon have Wikidata:Help:Description ("In most cases, the proper length is between two and twelve words") descriptions for everything.

Alternate Proposal

 * Since it's apparent we're probably not going to be forking into another project because of the nature of the issues, why don't we change WP:LEAD to address that concern? I think it would be more sensible if we alter that policy so "The Lead of the article acts as a effective summary for the entire article"? We could also have a drive to clean up on that, and help make sure thats the case in most our articles. TheOriginalSoni (talk) 19:33, 7 June 2013 (UTC)
 * Isn't that what WP:LEAD already says? Phil Bridger (talk) 19:42, 7 June 2013 (UTC)

Unify and centralize category systems through Wikidata
Hi all. I leave a link to a proposal I just made at Wikidata about the possibility of unifying and centralizing the category systems of all the Wikipedias through Wikidata. Take a look! --Felipe (talk) 16:23, 2 June 2013 (UTC)
 * Not another nail in the coffin of Wikipedia: Thank you for warning us about another power struggle in the Wikipedia/Wikidata bureaucratic expansion, which is predictable as clockwork, such as having a Wikidata citation catalogue, or Wikidata-infobox repository. The recent 2011 ex-editor survey revealed that about half of editors have quit due to the complexity of editing articles (which new editors do not realize yet), versus unbearable disputes with other editors, unless they leave for personal reasons. The only thing lacking, to drive more people away, is a requirement to submit request forms, handwritten in triplicate, to each department, plus of course, please take a number and be seated. Most categories are very language-specific, although that probably indicates that there are far too many categories being created. Hence, I fear that forcing all the categories to become interwiki Wikidata entries would be auto-spamming the wp:indexspam to spread even faster, into smaller other-language wikipedias where their editors would be overwhelmed by all the indexspam arriving so fast. Please understand that regular editors in the German Wikipedia have rejected new illustrated articles which contained only 95% typical German-language text, as being "too much work" to revise the awkward text. Plus, the Swedish Wikipedia has rejected new incoming articles as being "machine translation" (termed "Babelfish") when the Swedish text was too stiff, or stilted, in tone compared to typical articles. Forcing all the categories into Wikidata, even to gain a bureaucratic advantage to expand Wikidata infiltration, would tend to drive away the regular editors who act as watchdog guardians to deter rapid growth of unreviewed materials. I ask people to please set aside the Wikidata plans, for total world domination, and instead consider what the editors need to write articles much faster, which I am sure will be seen as a greater priority ya right. -Wikid77 (talk) 17:48, 2 June 2013 (UTC)
 * Wikid, this is an incredibly bad-faith statement. You're accusing the Wikidata contributors (and the proposer) of trying to "infiltrate" Wikipedia? I have a suggestion for you, in future: before you hit save, check to see if you're denigrating the good intentions of the person you're talking to. If the answer is 'yes', close the window and take a walk or something. It's genuinely hard to take you seriously when you're making statements about a Wikidata Occupied Government. Ironholds (talk) 00:30, 5 June 2013 (UTC)
 * @Ironholds, I am not an optimist nor a pessimist, but a realist. In future: before you hit save, check to see if you're accusing someone of denigrating the intentions of others, who is actually being realistic in warning them about potential problems of flooding other wikipedias with hundreds of thousands of categories they do not want. And talking about "Wikidata Occupied Government" is a far stretch beyond "bureaucratic expansion" of Wikidata to complicate more aspects of Wikipedia, rather than helping editors to write articles much faster. -Wikid77 (talk) 01:12, 10 June 2013 (UTC)


 * While I don't subscribe to Wikid's interpretation, I also don't thin this is a good idea. And without active participation by every single project I also don't think this can or should be forced on us. Each project should be able to control its own category structure. While it is true that some portions of our current structure are a shambles, I don't believe handing control over to a centralized authority is a reasonable or desirable way to try and improve it. Sites like Meta and Wikidata are supposed to be here to serve the other projects, and i don't see how giving control of our categories over to them is helpful to this project. Beeblebrox (talk) 03:11, 6 June 2013 (UTC)
 * If I were going to do something like this, I'd probably start with Commons' cat structure, which has many fewer loops than ours, and first clean that up and then start a merge process that adjusts theirs and ours to whichever seems more sensible or complete, section by section. However, it would require a massive amount of work just to merge ours with Commons, and by "massive", I mean something like "hire a dozen reference librarians to work on this full-time for at least a year".  If Wikidata took this on now, the only result would be failure.  WhatamIdoing (talk) 21:56, 7 June 2013 (UTC)

Reader comments in article
I personally dislike the way the reader's comment shown here Tom and Jerry. And the comment is not very detailed and meaningful too and does not deserve to be a Featured Comment! Many other websites display comments, but, generally not at the top of the article like this! --Tito Dutta (talk • contributions • email) 12:12, 5 June 2013 (UTC)
 * OMG, what kind of silly feature is that again. I'm not against the ArticleFeedback tool itself, but it should be a slight hint to the editors and not be prominently shown directly beneath the page title. --Patrick87 (talk) 14:53, 5 June 2013 (UTC)
 * The feature is documented here, and went live on 29 May. Apparently, the feedback link is only displayed to logged-in editors, and only when there are featured comments. You can turn off all the feedback paraphernalia in the "Appearance" section of your preferences. DoctorKubla (talk) 16:06, 5 June 2013 (UTC)
 * Yet another interface change implemented without appropriate discussion. It should be off by default.--ukexpat (talk) 19:18, 5 June 2013 (UTC)
 * I suggest that you read WP:CONEXCEPT: the editor community isn't in charge of the developer community.
 * But as it happens, I understand that this was discussed, and the change was made to address our complaints that the link to AFT comments was buried on the talk page. WhatamIdoing (talk) 22:04, 7 June 2013 (UTC)
 * Correct me if I'm wrong, but doesn't User:Jimbo Wales/Statement of principles state that software development changes (such as this) be minimal steps, not big changes, and that they always change things in a manner that the Community accepts? All these changes going on with these surveys and the removing the message bar to me have violated Jimbo's original version of software changes. Of course it was his statement and if he thinks that these changes are not in a manner that violates what he originally meant then disregard me.Camelbinky (talk) 11:51, 9 June 2013 (UTC)
 * The appearance of a small link saying "3 reader comments" at the top of article sounds exactly like something that is "gradual and reversible" and its appearance after community requests to make that feedback more visible sound like "in full consultation with the community consensus" to me.
 * It's possible that he's changed his mind in the last 12 years, especially as it has become obvious that some very major changes need to be made. There is no "gradual" series of changes that will allow the edit window to become WYSIWYG.  If he doesn't support the general direction that the software is taking, though, then he's on the Board and can (with his fellow Board members) see about stopping them.  WhatamIdoing (talk) 21:11, 9 June 2013 (UTC)

Temporary Watchlist
Hello Wikipedia. One of my biggest annoyances on Wikipedia is logging onto Wikipedia, clicking on my watchlist, and seeing several dozen entries for articles that I don't remember at all. Then, when I go to clear those entries from my watchlist, I see a wall of many, many more articles that I don't remember at all. Clearing all of those articles out is a pain, and takes near forever. This problem is compounded because I watch a lot of articles for vandalism in the short term that I have no interest for in the long term. I suggest a simple solution: an expiration function for the user watchlist. This has been suggested several times before (not recently), with the conversation fizzling out or failing to occur both times; however, I believe it deserves a more serious look. The UI side of it would be simple: if you want to watchlist an article, when you hover over the star icon at the top, a dropdown list could appear that offers several watchlist expiry options (think favoriting pages on Chrome), such as general expiration (delete this page from my watchlist after __ days), edit-dependent (delete after __ days since my last article edit), or action-dependent (delete if this article [ ] becomes a redirect [ ] is deleted (think PRODed and CSDed articles)). You could continue to add pages to your watchlist indefinitely by clicking the star at the top, as usual. This would also add pages indefinitely even if your preferences default was non-infinite (see expansion below); you would always add articles that you wanted to expire via the dropdown menu. However, this would make your watchlist much more navigable and less daunting. This could also reflect in your watchlist entries themselves; a couple of sample entries could read as: which would invoke the same dropdown list. I know this is a bad time to suggest a newT watchlist overhaul with the whole new notification system coming in, but is there any reason this can't be implemented at some point? This could even be a new notification class, like "Wikipedia was just removed from your watchlist." I think this would help me (and many other watchlist-weary editors) immensely.

So, Wikipedia, what do you think? Dea db  eef  02:21, 26 April 2013 (UTC) (ironically, now watching this page)

Expansion: You could also make a section in the preferences page to prefill default selections in the dropdown menu. This would make it so that simply clicking the star would still add a page to the watchlist normally, but the dropdown menu could have certain items set by default, depending on your preferences page. That way you wouldn't have to spend time every page picking the same watchlist expiry options, but you could still change them for a single page and have the options default back for the next one. Dea db  eef  21:50, 26 April 2013 (UTC)


 * I think your general motive is good.  Hazard-SJ  ✈   04:52, 26 April 2013 (UTC)
 * No: This will make it very complex. Already the watchlist page is very complex with many many links. I suggest you to remove pages from watchlist periodically using this script --Tito Dutta (contact) 04:55, 26 April 2013 (UTC) Tito Dutta (contact) 00:22, 30 April 2013 (UTC)
 * I'd love this and have asked for it before. I'd be happy with a 30-day option:  click "watch" for indefinite listings and "watch for a month" for a temporary listing.  (Maybe a drop-down menu from the usual star?)  AFAICT the script Tito links is irrelevant.  I want "my watchlist will never again show me the dozens of user pages that ended up on my watchlist because I left one message on them two years ago" and it gives "only display pages that have changed since the last time you looked" (which is not very different from what I've got now, with changed pages listed in bold).  There are currently more than 300 user pages on my watchlist.  I want my watchlist itself to contain only those that I care about, or at least only those that I've edited this year.  WhatamIdoing (talk) 05:37, 26 April 2013 (UTC)
 * Strong support. I don't know if that is technically possible, but if it is, I fully support it. I am an NFCC enforcer and have Watch this page enabled by default to not miss any comments or edits regarding the non-free content in question. However that doesn't necessarily mean I am interested in the specific article and so yes, my watchlist gets rather long quickly as well. --  Toshio   Yamaguchi  07:23, 26 April 2013 (UTC)
 * This is awesome. Brilliant idea. Not so sure about technical implementation, but I support wholeheartedly as a frequent WP:NPPer. — Theopolisme ( talk )  11:24, 26 April 2013 (UTC)
 * Support though I suspect it would be hard to implement. I'd love to see this integrated with the Twinkle preferences: eg add an article to my watchlist for 14 days (only) when reverting vandalism, watch someone's talk page for 3 days (only) after leaving a warning message. Otherwise the watchlist just gets bigger and bigger. -- John of Reading (talk) 12:45, 26 April 2013 (UTC)
 * One of the best suggestions to come out the site.-- Laun  chba  ller  12:52, 26 April 2013 (UTC)
 * Strong support, although I suspect the technical changes may be too major for it to actually get implemented. I'd also like some way of applying the options for folk (like me) who set their prefs to automatically watchlist any page they edit; whilst that's generally useful, it does clutter up one's list somewhat (currently 2,318 pages and counting, in my case). Prehaps there could be a default 30 days setting for such users, with override options for individual pages... However it's done, it strikes me as a very good idea. Yunshui 雲 &zwj; 水  13:01, 26 April 2013 (UTC)
 * Yes, of course. I do not know how to do that facepalm thingie, but that would be one occasion to use it as in: why did no one think of this before. Lectonar (talk) 13:08, 26 April 2013 (UTC)
 * Do you mean ? WhatamIdoing (talk) 15:18, 26 April 2013 (UTC)
 * Yes, thanks. Lectonar (talk) 12:41, 29 April 2013 (UTC)
 * They did. Discussions from 2007: Village_pump_(proposals)/Archive_AB and 2011: Village_pump_(proposals)/Archive_69. Idea mentioned in 2002: Phase_II_feature_requests. Ah, found the bug: Bugzilla:6964 - Watch pages for a few days only (add an expiry time). It's from 2006. Rd232 talk 15:40, 26 April 2013 (UTC)
 * Must have escaped my notice, or I just do not remember. Also many thanks. Lectonar (talk) 12:41, 29 April 2013 (UTC)
 * Support This would be helpful for 'vandal fighters', 'mergists', and admins especially. GenQuest  "Talk to Me" 20:18, 26 April 2013 (UTC)
 * The downside of a drop-down type thing is that this would make watchlisting a little more time consuming every single time anyone watchlisted an article. That's not insignificant; it adds up. But I still think the upside of a more useful watchlist for everyone would outweigh the downside.  I support this as written, and would wholeheartedly support it if there was a way to make "forever" the default value if you just click "watch", so those who don't want to mess with it don't have to. And on Utopiapedia, the user could set what the default duration was in their preferences... --Floquenbeam (talk) 20:39, 26 April 2013 (UTC)
 * I love your utopian vision. WhatamIdoing (talk) 20:48, 27 April 2013 (UTC)
 * Conditional support. I don't want to risk losing the pages I watch permanently, but if a page can be added to the watchlist for a nominated period, say 1 month, It would be fine. &bull; &bull; &bull; Peter (Southwood) (talk): 09:34, 27 April 2013 (UTC)
 * Support Great idea! Feed   back   ☎ 16:26, 28 April 2013 (UTC)
 * Comment Honestly I'd rather just have a script that prunes from my watchlist pages that were added because I was using Huggle and Twinkle. I would not use something like this. &mdash;/M endaliv /2¢/Δ's/ 23:22, 28 April 2013 (UTC)
 * Support as long as it's optional, since I have absolutely no use for such a thing and definitely wouldn't want it. Use a dropdown as Deadbeef proposes, or have something in Special:Preferences, or do anything else to permit either opt-in or opt-out, and I'll happily support.  Nyttend (talk) 23:53, 28 April 2013 (UTC)
 * Support as a useful addition, provided there's a way of making "forever" the default value, per Floquenbeam above. It really is far from insignificant to have to mess with a dropdown every time one clicks "Watch". A default would be needed anyway for the pages I start to watch by editing them/moving them, etc, without even having to click "Watch", wouldn't it? (Per Preferences —> Watchlist —> Advanced options, surely useful and common choices). Bishonen &#124; talk 12:43, 29 April 2013 (UTC).
 * Support - obviously a useful option for some, at least some of the time. But as so often with interface changes, it would need to be done in such way that those people who want to stick with the status quo can. Rd232 talk 18:10, 29 April 2013 (UTC)
 * Support It'd be bloody useful. Even better would be to have a little Ajax flyout come out after I 'star' a page asking me how long I want it watchlisted. This (plus cross-wiki watchlists, obviously) would make me very happy. —Tom Morris (talk) 14:45, 1 May 2013 (UTC)
 * Actually one thing I was going to say but forgot: be careful on the "until deleted" thing. There may be a reason why an admin deletes something and then brings it back a few minutes later (revdel/oversight, history merge, etc.) It might be advisable to either not have the "until deleted" feature, or to strongly discourage its use. —Tom Morris (talk) 14:47, 1 May 2013 (UTC)
 * Support - As it's optional, this is a fantastic idea. Luke no 94  (tell Luke off here) 20:12, 1 May 2013 (UTC)
 * Strong support I love it. I'd definitely use it. Can't come soon enough. --BDD (talk) 20:15, 1 May 2013 (UTC)
 * Strong support: I've often thought how useful this would be, but waited for someone else to articulate it. I stub-sort a lot, and come across a lot of articles where I've got no particular long-term interest but would like to see whether anyone does anything in the immediate future in response to my actions or talk page messages. A 30-day watchlist option would be great (there are 5k items on my watchlist at present). As a Second proposal: it would be wonderful to be able to watchlist a section of a page, specifically a user talk page or a project talk page. If I've left someone a comment, I'm interested in their, or anyone else's, replies on that topic, but I may or may not want to be alerted every time someone else leaves a message on their talk page. But perhaps I should make that a separate proposal.  Pam  D  08:58, 2 May 2013 (UTC)
 * Support: As stated here on Bugzilla, your second request has been blocked by a few technical difficulties.  Otherwise, though, I would love to see it happen along with the main topic of this thread!  —&thinsp;RandomDSdevel (talk) 15:57, 10 May 2013 (UTC)
 * Strong support Great idea. And as it would be optional, how could anyone reasonably object? Edwardx (talk) 13:24, 2 May 2013 (UTC)
 * Support, so long as the default "default" option is "forever".  Ignatz mice'•talk 16:01, 2 May 2013 (UTC)
 * Strong support Great idea. I would use it for all user pages, especially ip-users that I have given a welcome or a warning. They are on my watchlist because I want to know if they answer me but it's a drag having them on my watchlist half a year or two years after I posted them a message. Lova Falk   talk  16:09, 2 May 2013 (UTC)
 * Very strong support I wonder why I never thought of this myself. As with others, most of my watchlist is new editors, ip or otherwise,  whom I need to track for a month or two.  I think there's essentially unanimous support for this, and we could snow close the rfc.  &#39;DGG (at NYPL) (talk) 19:56, 2 May 2013 (UTC)
 * Support - Yes, for a long time I've wrestled with either being very restrained of what I put on my watchlist or putting a lot on and having to do regular cleanouts which can get tiresome. Having the option of setting an expiry would be very helpful. CT Cooper · &#32;talk 21:02, 3 May 2013 (UTC)
 * Support and idea - There are a few some many articles on my watchlist that are meant to be gotten rid of as soon as the article passes a certain standard (GA, FA, etc.) so I suggest the following:
 * 24 hours
 * 3 days
 * 1 week
 * 1 month
 * 2 months
 * 3 months
 * 6 months
 * 1 year
 * 2 years
 * If page is deleted
 * If page reaches GA
 * If page reaches FA ö   Brambleberry  of   RiverClan  02:10, 4 May 2013 (UTC)
 * Support - I have a whopping 8,224 pages on my watchlist, most are for articles I patrolled or users I warned. I had already been thinking of "purging" my watchlist of unneeded pages for quite some time, but this would work as well. Narutolovehinata5 tccsdnew 15:09, 5 May 2013 (UTC)
 * I did this a little while ago. Grabbed the title of every page I had edited, then copied the ones I had edited at least twice into the raw watchlist feature.  Dropped something like 7000 pages immediately, and nothing of value was lost. ~  Amory ( u  •  t  •  c ) 23:18, 5 May 2013 (UTC)
 * Support This is a great idea. I have hundreds of pages on my watchlist, many of which were added as the result of seeing some posting at a community noticeboard, but I have no real interest in editing long term. A Quest For Knowledge (talk) 15:30, 5 May 2013 (UTC)
 * Neat idea, would like to see it implemented. ~ Amory ( u  •  t  •  c ) 23:15, 5 May 2013 (UTC)
 * Yes. And it would be great if this was− implemented on wikia as well. --Shabidoo | Talk 00:44, 6 May 2013 (UTC)
 * I would suggest different strategies.
 * First multiple watchlists e.g. add a page to your main watch list, or BLP list etc.
 * Second to put on the watch list e.g. Barack Obama <BLP issues>.
 * Third to be able to categorise your watchlist entries e.g. I can have a list of 16 or so definable cats that I add to watchlisted items, I can then display my watchlist per category e.g. BLP, temporary, articles I created, etc.
 * I would personally prefer the second and third options. I don't like the idea of articles being automatically expired, especially deleted articles. I keep some deleted articles on my watchlist in case they are recreated. Martin 4 5 1  (talk) 00:15, 7 May 2013 (UTC)
 * Strong Support I have 11,000 pages on my watchlist (and that is net of several sessions of pruning, which is tedious and boring). Many on my watchlist because I made some minor change or left a comment, and would like to watchlist for a few days. In most cases, I would be happy if the item dropped off my watchlist after some period of time. While I see some clever conditions suggested (drop if article reaches GA) I'm worried that adding cleverness will delay the implementation so I urge that this be done in two steps. Step one, agree on a single termination measure, and Step Two, after step one is implemented, look into more robust measures. As a straw man for a single termination date, I suggest 3 months. I'll also suggest a slight modification, which may be even easier. Allow users to add to a watchlist list with a temporary flag. Once a quarter, a bot removes all entries that are more than three months old. This means is might last up to six months, but might be easier to implement, as the bot could be run four times a year.-- SPhilbrick  (Talk)  13:41, 8 May 2013 (UTC)
 * Support Wow I like this idea. -DJSasso (talk) 13:48, 8 May 2013 (UTC)
 * Yes, I would like this for the "watchlist all articles I edit" option, but I would want certain classes to be exempt from timing out otherwise it would be useless to me. Exemptions should include articles I created, articles to which I added more than x bytes, pages in my own userspace, and articles which I explicitly watchlist.  Spinning  Spark  14:44, 8 May 2013 (UTC)
 * Support per proposal. Now let's see what the developers have to say about this. --Jackson Peebles (talk) 23:27, 9 May 2013 (UTC)
 * Support - Would be very handy. Cabe  6403  (Talk•Sign) 09:32, 10 May 2013 (UTC)
 * Support as long as there is a way to do it without making everyone's watchlist public ... that is the main reason why a bot or script would not be helpful here, since everyone would be able to see you adding and removing things from your watchlist if the watchlist were just a normal subpage that could be edited by a script or bot. — Soap — 03:08, 12 May 2013 (UTC)
 * Support, nice idea, good implementation suggestions.Tazerdadog (talk) 04:33, 13 May 2013 (UTC)
 * Strong support if it can be implemented. AutomaticStrikeout ?  03:04, 15 May 2013 (UTC)
 * Support if this is possible, it wouldn't make sense not to allow it. <font face="Arial"> Hot Stop  03:06, 15 May 2013 (UTC)
 * comment perhaps it is time to close this as almost unanimous support, and figure out how to get it added.  DGG ( talk ) 01:19, 18 May 2013 (UTC)
 * Support Excellent idea, would make the work of long terms editors easier and more effective. -- ELEKHHT 02:56, 18 May 2013 (UTC)
 * Oppose. Unneeded interface complexity. Wikipedia's interface is already too complicated, IMO. Adding more features for edge cases seems like a bad idea. Kaldari (talk) 19:24, 18 May 2013 (UTC)
 * Support. Looks like a great idea to me.  I would default to the current behavior (for now, at least), with an option to set the default length in one's preferences. NinjaRobotPirate (talk) 15:35, 19 May 2013 (UTC)
 * Support I support this one. Watchlist, Watchlist, Watchlist, watchlist is the answer of so many problems we need more of it... I suggest the following:
 * 24 hours
 * 3 days
 * 1 week
 * 1 month
 * 3 months
 * 6 months
 * 1 year
 * and of course the default watchlist which we have already is still there.KhabarNegar (talk) 19:05, 19 May 2013 (UTC)
 * Strong Support One of the best ideas I've seen yet. Ramaksoud2000 (Talk to me) 20:48, 20 May 2013 (UTC)
 * Wow! Support First Light (talk) 02:47, 21 May 2013 (UTC)
 * May be superseded As noted above, I love this idea.  But I want to add that WP:Flow (the eventual replacement for talk pages) is going to obviate some (not all) of the need by giving you the option of watching one conversation, rather than a whole page.  So I'm still fully supportive, because I want to temporarily watch articles, but no matter what happens here, there is hope on the horizon for those of you who need to watch pages briefly due to warning users about something.  WhatamIdoing (talk) 04:56, 21 May 2013 (UTC)
 * Strong support: Even though it seems complex, it's not at all a bad idea. For those who want to avoid complexity there could be an option in Preferences to "disable temporary watchlist" or something (or maybe the same could happen on your watchlist itself). By default, this temporary watchlist should be disabled, of course, and any articles added to the watchlist using the star should get added 'permanently'. There could be an option in that little message with round curves (that's the best way I could describe it) to "configure the watchlist settings of this page" or something. For those who have the setting on to watchlist every page they edit (like myself), the thing should be as it is; you tick "Watch this page" and save, it gets watched permanently. You don't, it doesn't.  smt cha hal  talk 08:59, 25 May 2013 (UTC)
 * Interesting idea. The time-based stuff sounds fairly simple to do as a gadget: have the script edit a userjs- option to contain the json list of temporarily watched pages along with their expiration timestamps, and whenever the user is at their watchlist, quickly run through the list, and if any pages are past their end-watch date, remove them from the users watchlist and from the option list. . --Yair rand (talk) 10:49, 28 May 2013 (UTC)
 * Support - My watchlist is so full of stuff I don't care about; anything that will stop this accumulating will be appreciated. Also, even if some people like the system the way it is, there's no reason why just clicking the star can continue to function as normal (indefinitely watching a page), with the drop-down for those who want the additional options. Then everyone's happy. ItsZippy (talk • contributions) 10:34, 30 May 2013 (UTC)
 * Strong support – As an admin I would find this extremely useful for a variety of reasons (keeping an eye on vandalized pages, articles with recent edit warring, editors I've recently assisted, etc. etc.) As it is, I barely use my watchlist, and almost never for these purposes, because of the overhead in maintaining the entries on the list. Alternatively, if this turns out to be technically difficult or too resource-intensive, since every page has an atom feed, it would be entirely possible for an interested third-party developer to create a web or desktop application that serves a similar purpose. &mdash;Darkwind (talk) 04:25, 31 May 2013 (UTC)
 * Support. I won't rehash the above arguments, but flexibility in following pages is a plus. As it were my solution is to limit severely the pages I watch, but that could incite users like me to help with some pages more consistently.Truth or consequences-2 (talk) 21:34, 2 June 2013 (UTC)
 * Support; let's hope it's technically feasible. An option, if this does get implemented, to mass-move pages from your permanent watchlist to your temporary one would also be a plus IMO. <font color="#006600">It Is Me Here  <font color="#CC6600">t / <font color="#CC6600">c 17:13, 3 June 2013 (UTC)
 * Support. Bulbgraph.svg. Herostratus (talk) 17:58, 3 June 2013 (UTC)
 * Support - Fantastic idea. <font color="#FF0000">Red Phoenix  <font color="#FFA500">build the future...<font color="#FFDD22">remember the past... 02:45, 6 June 2013 (UTC)
 * Support This is a great idea. My watchlist has become increasing clutter over time and having a way of keeping stuff on temporarily without having to manually remove it is great. — Mike moral  ♪♫  22:44, 11 June 2013 (UTC)

Translation of language names
I would like to propose that language names in the list at the left of each Wikipedia page are displayed in the language of the host Wikipedia on mouseover. For example, if I am looking at en.wikipedia.org, then on mouseover of "日本語" I would see "Japanese". This information is of interest even to people who can't read the target language. 86.167.19.205 (talk) 20:59, 8 June 2013 (UTC)
 * The problem is that on mouseover the tooltip already shows the page name. This information has to go somewhere else I'm afraid.
 * Anyway this isn't a bad request at all. I already found myself googling for the language code of a specific language to get to the correct language version, because I couldn't understand or not even read the native language name. --Patrick87 (talk) 21:12, 8 June 2013 (UTC)
 * Oh, actually, I made this suggestion based on the operation of the Main Page, which currently does not have any mouseover text. I forgot that the article pages worked differently. However, would there be a problem putting the language name say in brackets after the article name? 86.167.19.205 (talk) 21:47, 8 June 2013 (UTC)
 * Yes, I like that idea. The tooltip could read something like "Wikipedia:Verbesserungsvorschläge" on German Wikipedia (example for the German language link on this page) were the tooltip could (should?) be localized depending on user settings. When switching to German it would read "Wikipedia:Verbesserungsvorschläge" auf der deutschen Wikipedia.
 * I think it looks good like in this example: <span title="&quot;Wikipedia:Verbesserungsvorschläge&quot; on German Wikipedia">Deutsch --Patrick87 (talk) 23:15, 8 June 2013 (UTC)


 * Strong support, with the language probably appearing before or after the article title in the other language.  Ignatz mice•talk 03:43, 9 June 2013 (UTC)
 * Support Patrick87's suggestion.  Theopolisme ( talk )  03:48, 9 June 2013 (UTC)
 * Shouldn't this go to the Village Pump or some place else?Camelbinky (talk) 11:54, 9 June 2013 (UTC)
 * This is a proposal and this page is the proposal section of Village Pump. What page could be better suitable? I think the request is perfectly fine here. --Patrick87 (talk) 12:00, 9 June 2013 (UTC)


 * Support, definitely. Great idea ···V ani s che nu「m/Talk」 12:41, 9 June 2013 (UTC)
 * comment Why not just show it as the English name? User:Manishearth/sidebartranslinks.js does this and adds a Google Translate link. It could readily be turned into a gadget.--  Gadget850talk 12:51, 9 June 2013 (UTC)
 * I thought about that, too, but actually I like every language name being shown in its native language. On the one hand it is something that is a characteristic of Wikipedia, on the other hand it helps people to find the article in their native language (when they do not understand the interface language currently set). --Patrick87 (talk) 13:22, 9 June 2013 (UTC)
 * Yep. Good point.   GenQuest  "Talk to Me" 00:05, 10 June 2013 (UTC)


 * Support per above.  GenQuest  "Talk to Me" 00:05, 10 June 2013 (UTC)
 * Support; I just wonder why no one thought of this before now... Ypnypn (talk) 23:30, 10 June 2013 (UTC)


 * Here are some links to previous related discussions:
 * 5231
 * Gadget/proposals/Archive 3
 * Village pump (proposals)/Archive 78
 * Village pump (technical)/Archive 94
 * Help desk/Archives/2011 August 24
 * PrimeHunter (talk) 00:44, 11 June 2013 (UTC)


 * As seen on the bugzilla page, a patch has been submitted but it just hasn't been approved. We've had a consensus for this change for years but MediaWiki's a little technically understaffed. —Designate (talk) 00:57, 11 June 2013 (UTC)
 * I asked a dev to glance at this thread, and magic. Hopefully this will arrive in a future mediawiki update. –Quiddity (talk) 23:20, 11 June 2013 (UTC)

I guess this has been archived so it doesn't matter, but this is the only discussion I found and I just wanted to say Strong support for this from me in 2019. I have also been drinking wine which may explain why I cannot do any more research to be on the correct discussion, but I do know this issue still exists. <font color="#ff004f">S<font color="#ff001f">a<font color="#ff1000">u<font color="#ff4000">d<font color="#ff6000">a d e 7  21:42, 14 May 2019 (UTC)

Languages on sidebar
On the left hand side of any Wikipedia page, on the toolbar, there is a section devoted to interwiki links to other language versions of an article. I want to propose a small change to the mediawiki software wording here. At current it is simply named "Languages", which is rather ambiguous and vague name. I think that when somebody less experienced at Wikipedia, usually a reader or newbie, sees that and the links below it, that if they click it they can get the whole of Wikipedia translated into that language. I propose it is changed to something short but similar to "View this page in other languages". This clears up any confusion to what you may consider to be a very minor thing but could be very hard to get their head round for readers.  Rcsprinter  (talkin' to me?)  @ 11:27, 26 October 2012 (UTC)


 * "In other languages" would probably fit. But your solution does not solve the stated problem. I'm as likely to think I'll see a trasnslation of the EN page if we say "View this page in other languages" ... the operative problem being "this page". The interwiki link allows us to view the treatment of this subject in other languages. "Other language versions" might work. "Articles on other languages" also. But we're swapping brevity for perceived accuracy, which still might not be parsed by the user. --Tagishsimon (talk) 11:53, 26 October 2012 (UTC)


 * Why not "Other languages"? Tony   (talk)  12:14, 26 October 2012 (UTC)


 * Funny, in my toolbar it shows as "in other languages". Lectonar (talk) —Preceding undated comment added 12:20, 26 October 2012 (UTC)


 * Are you using any custom code that might be overriding the default? —David Levy 12:59, 26 October 2012 (UTC)


 * Not that I am aware of; but still, it shows "In other languages", even on this page here. Lectonar (talk) 13:03, 26 October 2012 (UTC)


 * I guess you have selected "en-GB - British English" as language at Special:Preferences. Then you see MediaWiki:Otherlanguages/en-gb instead of MediaWiki:Otherlanguages. en-gb is not recommended at the English Wikipedia. See Help:Preferences. The page history of MediaWiki:Otherlanguages shows some variation years ago but not since 2007. David Levy used the Simple English Wikipedia as reason for not saying "In other languages". PrimeHunter (talk) 13:38, 26 October 2012 (UTC)


 * Thank you for that; I guess I must have chosen it when I started may account, some 7 years ago. Never had any problems, though. Cheers. Lectonar (talk) 13:54, 26 October 2012 (UTC)


 * I just harmonized MediaWiki:Otherlanguages/en-gb and MediaWiki:Otherlanguages/en-ca with MediaWiki:Otherlanguages.
 * If the British English and Canadian English options are to remain available, we should apply the various customizations (with changes in spelling/wording where appropriate). For the messages in which no English variety issues exist (presumably most), we could use redirects.  —David Levy 17:15, 26 October 2012 (UTC)


 * One of the Wikipedias is written in simple English. —David Levy 12:59, 26 October 2012 (UTC)


 * Keep "Languages". Apart from linking to this subject in another language, it also links to the whole Wikipedia in that language (with "whole" admittedly being smaller than English). You stay in that language if you follow wikilinks there, use the search box, click the logo, and so on. "Languages" is brief and about as clear or open to misunderstanding as alternatives that are not ridiculously long. PrimeHunter (talk) 12:38, 26 October 2012 (UTC)
 * Keep "Languages". Agree with PrimeHunter - it is ambiguous, but it's short and it won't take the reader long to find out what is meant once he actually follows the link... --Philosopher Let us reason together. 19:41, 26 October 2012 (UTC)




 * The WMF is developing a huge button that says "English" on the right corner, so readers will find the articles in other languages easily. --NaBUru38 (talk) 20:09, 15 November 2012 (UTC)


 * I want what NaBUru38 mentioned, and I want it now, Daddy! :-)  —&thinsp;RandomDSdevel (talk) 22:00, 21 May 2013 (UTC)

Why not have it say "On Other Wikipedias"? Then it encompasses, say, Simple English, while avoiding the implication of translations. &there4; <span style="font: bold 1em Courier, monospace;">ZX95 [ discuss ] 01:00, 8 December 2012 (UTC)
 * My preference is languages because that is more explanatory than other wp's. Technically simple is a subset of English. Apteva (talk) 02:53, 8 December 2012 (UTC)
 * The issue was raised, however, that "Languages" is likely to make some people think that the linked articles are translations of the English one; that was why I suggested "On Other Wikipedias", which is much less ambiguous. &there4; <span style="font: bold 1em Courier, monospace;">ZX95 [ discuss ] 15:29, 11 December 2012 (UTC)

Note to keep archiving bot away.  Rcsprinter  (yak)  @ 21:43, 14 February 2013 (UTC)


 * Will this be affected by WikiData or will the wording change we are proposing still be changeable?  Rcsprinter  (whisper)  @ 15:59, 14 February 2013 (UTC)
 * This is unrelated to Wikidata. I believe this is somewhere in Mediawiki and can be changed if there is consensus to do it.--Ymblanter (talk) 16:08, 14 February 2013 (UTC)

Redirects don't work on MediaWiki interface pages, but you can transclude one into another. --— Gadget850 (Ed) talk 16:18, 14 February 2013 (UTC)


 * The links are to the same topic on other language Wikipedias, not to other languages, or translations of the same article. Unless the sidebar section header mentions that the links are to similar articles on other Wikipedias it will remain ambiguous. &bull; &bull; &bull; Peter (Southwood) (talk): 07:38, 30 March 2013 (UTC)
 * Note: This thread wasn't being archived because Rcsprinter signed with a fake date further up. I'll fix that, during this edit, so that this thread will be properly archived within 7 days.
 * Note also: A related thread about languages in the sidebar below, at, and the ongoing work at Universal Language Selector which is highly related. –Quiddity (talk) 03:39, 13 June 2013 (UTC)

Request for SWF Functionality
As I'm sure we're all aware, SWFs are not available for upload to Wikipedia or Commons, and there are many good reasons for this, the proprietary formatting being a major reason. However, I recently received a grant to create Adobe Captivate tutorials to assist new editors in editing the Wikimedia sites constructively. The project page is located at WP:VIDTUT. I have one prototype out that has received feedback (more is always appreciated) even though I haven't opened the RfC, yet, and I have two that I'm going to roll out any day, now. I plan on making this a continuous project, and I'd love to have interactivity and incorporate it into a CVUA or Adoption training program. However, I can't do that without the ability to upload SWF files, and, to the best of my knowledge, nobody can do that. I propose that we enable a select group (perhaps administrators or file movers) to upload SWFs. --Jackson Peebles (talk) 04:11, 23 May 2013 (UTC)
 * I'd like to see us permit any useful file format, but since we're blindly dedicated to the free software movement, I can't see this succeeding: even if we get consensus here, WMF will say "We don't care; it's eeeeevil because it's proprietary". Nyttend (talk) 04:24, 23 May 2013 (UTC)
 * I understand your point, Nyttend, and I ran into that in the deliberations over my grant proposal(s), but they did give me the grant, and I'm 'assuming' they knew it would come out in SWF. I'd love to get consensus here for this particular project or right and bring it to the WMF Board.  I'd like to keep this conversation going, if possible.  Interactive video tutorials, especially when static close-equivalents are available for those with limited resources, are better than none at all.  --Jackson Peebles (talk) 04:36, 23 May 2013 (UTC)
 * Oh, I misunderstood. In that case...


 * definite support, since it would seem to be helpful without drawbacks. Nyttend (talk) 04:40, 23 May 2013 (UTC)
 * "SWF" is SWF, that Adobe Flash file format? There are some other meanings...  WhatamIdoing (talk) 06:42, 23 May 2013 (UTC)
 * This is really a Commons issue, not a local issue. --Rschen7754 10:14, 23 May 2013 (UTC)
 * He does say "upload to Wikipedia or Commons"; we could always upload locally if it were enabled here but not at Commons. Nyttend (talk) 11:57, 23 May 2013 (UTC)
 * Indeed. --Jackson Peebles (talk) 21:18, 24 May 2013 (UTC)


 * Oppose I expect that issues with being able to upload untrusted code that will run in users' browsers will not be easily overcome. I also disagree with so blithely dismissing the concerns about it requiring non-free software. Anomie⚔ 21:10, 23 May 2013 (UTC)
 * Anomie, thanks for your comments. I agree with your concerns.  Do you have a recommendation?  --Jackson Peebles (talk) 21:18, 24 May 2013 (UTC)


 * Why do your SWF files have to be hosted on-wiki? Couldn't you put them somewhere like Wikimedia Labs (successor to Toolserver)? (I'm not saying there is no reason why they must be on-wiki, but I haven't been able to see one.) Also, even if SWF files were enabled for upload here, there doesn't seem to be any MediaWiki support for displaying Flash objects in wiki pages, without installing an extension (the SWF extensions on all look pretty dodgy, and I don't think the devs will want to install them here). — This, that and the other (talk)  08:11, 24 May 2013 (UTC)
 * This, that, how do I do this? Forgive me for my ignorance. — Preceding unsigned comment added by Jackson Peebles (talk • contribs)
 * It's not easy. You'd do well to ask someone who already uses Labs - perhpas one of the users listed here who you recognise as an English Wikipedia user. To be honest, I think we need a bigger discussion about how MediaWiki and Wikipedia supports video and interactive content, but any changes could take a very long time to materialise. — This, that and the other (talk) 01:04, 25 May 2013 (UTC)


 * Speaking as someone who primarily edits and views Wikipedia with an iPad I'd like to see some sort of video/animation that actually works on mobile devices. Flash isn't it, it requires too much memory and is not supported by many mobile platforms. The whatever it is we have now doesn't work for me either. Beeblebrox (talk) 21:05, 24 May 2013 (UTC)
 * Beeblebrox, would we somehow be able to implement HTML 5? I can do that, too... — Preceding unsigned comment added by Jackson Peebles (talk • contribs)

Unarchived RfC. 64.40.54.29 (talk) 05:03, 14 June 2013 (UTC)

Automated harvesting OAC finding aid links and adding to EL section of relevant Wikipedia articles
At UC Irvine Libraries, we are interested in adding links to our finding aids published in Online Archive of California to the External links section of relevant Wikipedia articles. The list of finding aids can be found here, http://www.oac.cdlib.org/institutions/UC+Irvine. There are about 400 finding aids and these are trusted and quality information created by the archivists to inform researchers across the globe and help them locate primary-source materials for their research topics. These materials are unique to UC Irvine and the region. Some or majority of the persons, families, organizations, or topics will have matches in Wikipedia content. After reading the EL guidelines, I think these links we are planning to add fit the "What can normally be added" criteria. A few of our libraries' staff including me wonder whether there is a way to automate this process. I posted the question in Teahouse and user ColinFine suggested me seeking consensus on the proposal here first before diving into the tech details. What does everybody think?Pandashu (talk) 16:44, 13 June 2013 (UTC)

RFC: Consistent date location in citation templates
Please see Help talk:Citation Style 1 where I ask if the location of the date in the most popular citation templates should always be consistent. At present, the date is immediately after the authors if authors are given in the citation, but near the end if not. Jc3s5h (talk) 10:35, 13 June 2013 (UTC)

RfC: WP:AURDNAME as a guideline
I would like to invite the editors here to comment on a proposal to promote WP:AURDNAME (Wikipedia:Naming conventions (Australian roads) to guideline status. Please visit the WP:AURDNAME talkpage and discuss.

-- Nbound (talk) 12:01, 15 June 2013 (UTC)

The Wikipedia Library now offering accounts from Cochrane Collaboration (sign up!)
Cochrane Collaboration is an independent medical nonprofit organization consisting of over 28,000 volunteers in more than 100 countries. The collaboration was formed to organize medical scholarship in a systematic way in the interests of evidence-based research. The group conducts systematic reviews of randomized controlled trials of health-care interventions, which it then publishes in the Cochrane Library.

Cochrane has generously agreed to give free, full-access accounts to 100 medical editors. (Individual access would otherwise cost between $300 and $800 per account).

'''Thank you Cochrane! If you are an active medical editor, come and sign up!'''

Cheers, Ocaasit &#124; c 19:39, 16 June 2013 (UTC)
 * Just a general note. As I have mentioned before, the general problem with these reference accounts is that it requires a Username and password to see the reference. So anyone who is verifying these references for GA, A, FA, etc. need to have an account if the article is to be properly reviewed. Additionally, readers likely will not have access so it restricts the readers ability of verifying the source. What this means is that someone can simply use this as a way to insert potentially incorrect information behind a restricted use reference. Kumioko (talk) 20:44, 16 June 2013 (UTC)
 * It's not really any different than just citing a book. I had one of those free Highbeam accounts last year, and my only regret was that I don't do more content work as it was very useful on the rare occasions when I took a break from admin work. Beeblebrox (talk) 20:52, 16 June 2013 (UTC)
 * Thanks for the feedback Kumioko. There's a balance here, and a trade-off between ease of verifiability and quality of references.  It's simply an unfortunate reality that many of the most scholarly published sources, especially in science and academia, are behind paywalls.  For all of these Wikipedia Library accounts users are instructed to provide the full original citation information so that any reader can attempt to access the source in the easiest (and freest) way possible for them.  I'm a big supporter of the open access movement; meanwhile, we have an encyclopedia to write and we need up to date and authoritative publications--no place moreso than our medical content, in my opinion. WP:PAYWALL, is also the policy that has guided my thinking about these efforts. I do appreciate the input.  Cheers, Ocaasit &#124; c 21:22, 16 June 2013 (UTC)
 * Someone is doing something nice for Wikipedia, presumably because they believe in what we are doing. Content will almost certainly be improved as a result of this. That's a good thing. Beeblebrox (talk) 21:55, 16 June 2013 (UTC)
 * Oh I know. I think its probably a net positive and I am a bit luckier because I am a mile from the Library of Congress but I wanted to make mention of it. Its also good advertisement for them. If we use it and drop these refs all over, then not only are they here but they are sucked into the mirror sites, linked through google and facebook etc. So a lot more people will learn about their product. I have to admit I never heard of Highbeam or Credo before they became available to use here. I imagine that's true of a lot of other people too. Its just a bit of a double edged sword to me that's all. The only way to get the data is to go to these sites that require payment to access. They give us access to add the references to the articles but only a few of us get access so the readers are forced to either pay or assume that the reference is true. Kumioko (talk) 22:24, 16 June 2013 (UTC)

Automatic edit summary for unexplained changes of numbers and statistics?
I've been really enjoying the auto edit summaries for "new editor", "blanked section", "possible vandalism", etc. It's made it a lot easier to scan through my Watchlist. Sure, someone could make up a false ES and get around those, but a huge portion of vandals and tamperers don't bother, so these auto-ESs help.

There is one especially pernicious form of tampering/vandalism that, to my knowledge, we don't have auto-ES'ed currently: changes in numbers with few/no other changes made and no explanation. I particularly see this problem in demographic sections. For nationalist, ethnic, or sectarian reasons there are plenty of IPs and SPAs that like to duck in and go "hmmm, 55% of my hometown are believers in Fooism? I hate those guys, let's bump it down to 35%" It's been an ongoing issue in Shia Islam to the point that I really don't trust any of the stats in the big table anymore, and at some point we'll have to break down and put all those stats into a locked display template (not like anyone has a legit reason to change 2002 census numbers routinely anyway).

For folks like me, it'd be a big help to have an auto-ES for edits which mostly change numbers around and give no explanation. I don't know it math or science folks have similar prankeries, but in geo/demo topics emotions run high as to whose group has more people where, so it'd really help diminish the tampering if it could be swiftly identified. Thanks for any help! MatthewVanitas (talk) 19:27, 15 June 2013 (UTC)
 * Small note that there's a difference between an automatic edit summary and an AbuseFilter tag. AES's are the ones like "blanked section", and I believe those are defined by the software; AbuseFilter tags are the "possible vandalism" type ones, and those can be set by any edit filter manager. So you probably want the latter, not the former, especially since the latter will work with or without an edit summary supplied. — PinkAmpers  &#38;  <sup style="color:#000;">( Je vous invite à me parler )  05:16, 16 June 2013 (UTC)
 * I agree that Edit filter is the first place to look. WhatamIdoing (talk) 03:46, 18 June 2013 (UTC)

Search Feature.
I love Wikipedia but find it easier to go back to Google to search for my next topic. Why? Because the Search window is small, far to the right and unattractive. Please place you search window large and centre and make it desirable to use. This will help you and me.

Thank you, Damien Pierce. Ireland.


 * Click on the magnifying glass, then you get a search page. — Edokter  ( talk ) — 09:44, 16 June 2013 (UTC)


 * Wait, what? You know where the search box is, but because you find it to be in the wrong place and unattractive you just don't use it? It would work the same if it were three times as large and in the middle of the page. Beeblebrox (talk) 20:56, 16 June 2013 (UTC)


 * Why don't you just alter how it looks to you in your account's appearance preferences? --The Vintage Feminist (talk) 09:27, 19 June 2013 (UTC)

Disability swimming redirects to Paralympic swimming. It shouldn't.
I'm not active in the English Wikipedia, and don't know exactly what to do, so now I'm here. I hope this is the right section and if it isn't, please move it. The redirect mentioned in the headline should be deleted because disability swimming is much more than just a Paralympic sport. After deletion the topic should be added to the list of requested articles. Thank you. Memasa (talk) 14:20, 17 June 2013 (UTC)
 * Hi. You are looking for WP:RFD. I have no experience in that, but you may look at the instructions and ask on the talk page if you're unsure on how to nominate. -- Cycl o  pia  talk  14:24, 17 June 2013 (UTC)
 * Even better yet, just edit the redirect and change it to a proper article. Wikipedia only gets better because people who care make it better.  Since you care, there is no one in the world more qualified to make it better than you. -- Jayron  32  02:54, 20 June 2013 (UTC)

Request for import user right
I would like to obtain the import user right, so I can import long-lost revisions from old Wikipedia database dumps (primarily the January 2003 dump) to the current Wikipedia database. Most Wikipedia revisions from February 2002 onwards have survived, but a few have not. I have collected a list of these cases at User:Graham87/Page history observations; some of the article histories I could fix with the import user right are Glasgow, Canberra, and New York City. I will also be able to restore some edit history from 2001 and early 2002.

If this discussion reaches consensus, I will ask the stewards to grant me this user right. I previously started a similar discussion about the wider question of whether it would be a good idea to import long-lost revisions to the Wikipedia database. I cited this discussion in a request to the stewards for this right, but they asked me to create a new discussion to obtain consensus about whether *I* should be given the import right.

To head off a few concerns that some people may have, here are a few points to consider:
 * Admins can already import edits into the English Wikipedia, but only from nominated wikis connected to the Wikimedia Foundation (i.e. transwiki imports). What I am proposing is to allow me to import edits from my computer (importupload), which means I could import edits from pretty much *anywhere*.
 * The transswiki import procedure sometimes requires me to move pages across namespaces, which causes problems with Page Curation. The import procedure that I could use with this right means that I would never have to move pages across namespaces again, thus solving this problem.
 * Some people have changed their usernames between 2003 and 2013. I will endeavour to make sure that the newly imported edits would be attributed to an editor's current username rather than their previous one (especially in cases where the username change involves a person's real name).

Thanks for your consideration. Graham 87 03:14, 13 June 2013 (UTC)
 * I can't see a problem with this. It's obvious from your past work in this area that you know what you are doing, and as an admin you already have the trust of the community to carry out cross-wiki imports. This would just help you to carry out your existing work in a better fashion, as I see it. I trust you would take care of the pitfalls, particularly changes of username as you mention. Do you plan to continue using cross-wiki importation for most of this work, or will you switch over to importupload as your primary technique? — This, that and the other (talk) 03:44, 13 June 2013 (UTC)
 * I plan to use importupload unless cross-wiki import can be used without changing the namespace of a page or doing other hacky things. So yes, importupload would be my primary technique. Graham 87 06:03, 13 June 2013 (UTC)
 * Thank you for undertaking this endeavor. I strongly support your request. :) Legoktm (talk) 03:46, 13 June 2013 (UTC)
 * I'd strongly support this. I've seen many of your page-history-merges over the years, and I'm familiar with your diligent Wikiarchaeologist habits and skills, so it would be a pleasure to have you furthering the comprehensiveness of our fuzzy and broken early years. You reinstill my enthusiasm for this community on a regular basis. –Quiddity (talk) 03:48, 13 June 2013 (UTC)
 * I'm generally wary of revision tagging, but I think it'd be good to tag each of the imported revisions. I trust you and I can tell this is something you're diligent about and dedicated to, however rewriting history (even broken history) carries some risk that I think would be mitigated by tagging imported revisions. That said, generally, history merges (such that they are...) can leave an awful mess in page histories. The import user right being discussed here allows for complete manipulation of the historical record, as I understand it. And the "tools" involved in doing this kind of work are basically hacks, as I understand it. I suppose my view is that I don't really disagree with the intent (or even the actions), it's mostly the process (undeletion, deletion, XML...) and pieces of the final result (lack of revision tagging or other indication that the history has been tampered with) that make me cringe a little. --MZMcBride (talk) 04:33, 13 June 2013 (UTC)
 * I understand these concerns, and I know you've expressed similar sentiments in the past. All imports will be [//en.wikipedia.org/w/index.php?title=Special%3ALog&type=import&user=&page=Tullio+Liblik&year=&month=-1&tagfilter=&hide_patrol_log=1&hide_review_log=1 logged like this] and there will be [//en.wikipedia.org/w/index.php?title=Tullio_Liblik&diff=555487920&oldid=555484954 an entry showing the import in the page history like this]. The imported edits can be distinguished from the native edits because they will have a higher revision ID number reflecting when they were imported) – that isn't really a tag as such, but it is a distinguishing feature. I can't stand history merges that generate overlapping edits either, and I do my very best to prevent that. I plan to import only the revisions that are required, so no deletions or undeletions will be involved in the process. Graham 87 06:03, 13 June 2013 (UTC)
 * Ha! I'd completely forgotten about that discussion. Thanks for referencing that. --MZMcBride (talk) 17:02, 13 June 2013 (UTC)
 * Support this request. Technical 13 (talk) 12:10, 13 June 2013 (UTC)
 * Support I've noticed Graham87 good work on importing old revisions and he could use the permissions.--Salix (talk): 23:16, 13 June 2013 (UTC)
 * Support. Anything to improve errors in our attribution of edits is important, and if we can't trust Graham to do this right, we can't trust anybody. Also, early Wikipedia stuff is fascinating—bonus points if you can track down whatever happened to the edit mentioned here. — PinkAmpers  &#38;  <sup style="color:#000;">( Je vous invite à me parler )  02:23, 14 June 2013 (UTC)
 * Actually, that's a good point; that edit seems to be [//lists.wikimedia.org/pipermail/foundation-l/2010-December/063088.html permanently gone]. I've added an explanation about it to Wikipedia's oldest articles. Graham 87 02:59, 14 June 2013 (UTC)
 * Support. <small style="font: 12px Courier New; color: #000000; display:inline;border:#009 1px dashed;padding:1px 3px 1px 4px;background-color:#fff">mabdul 06:29, 14 June 2013 (UTC)
 * Steward MF-Warburg has now granted the userright in question.  Snowolf How can I help? 00:43, 21 June 2013 (UTC)

The ability to tag an edit as suspicious, allowing tools to allow people to review tagged edits
It would also make them stand out more in page histories.TeeTylerToe (talk) 00:04, 16 June 2013 (UTC)


 * Well, the edit filter already does this, and we have for article content. What exactly are you proposing that would be above and beyond that? Beeblebrox (talk) 01:00, 16 June 2013 (UTC)


 * There is already a system that does this; see Tags. This is an automatic feature used by Wikipedia's edit filter. Huggle also has a similar process that can help to tag dubious edits, though this is specific to that software and is not a wiki feature. A system to manually tag edits would be redundant to what we already have; if one has a problem with a dubious edit, they should probably either tag the content in question using existing processes or just fix it themselves.  elektrik SHOOS  (talk) 04:32, 16 June 2013 (UTC)
 * If it's a useful feature of huggle, which I assume is some kind of wp related tool, why not add it to wp itself so people don't have to use huggle to use the tag feature.TeeTylerToe (talk) 13:49, 16 June 2013 (UTC)

I think what he means is the ability to tag an edit as "vandalism" or similar, the same way we normally tag edits as "minor". Honestly, I don't see the point. I mean, if minor edits are subjective in nature, then vandalism (i.e. an edit in which another user disagrees with) is the exact same thing. --MuZemike 05:53, 16 June 2013 (UTC)
 * Plus the capability itself may be subject to vandalism. Praemonitus (talk) 15:30, 16 June 2013 (UTC)

I think the old WP:SOFIXIT applies here--if you see vandalism, revert it, don't just "tag" it. If you've made a mistake in your reversion, following the WP:BRD cycle, another editor should theoretically call you on it at some point.  Theopolisme ( talk )  22:28, 16 June 2013 (UTC)


 * There isn't really a point in tagging - why not revert the vandalism right then and there? smileguy91talk 03:35, 22 June 2013 (UTC)

Linking subjects to books at your local library (Forward to Libraries)
This Request for Comment is seeking proposals from the community to decide how to use the newly created Forward to Libraries (FTL) service that is running on Wikimedia Labs.

We now have a new tool on Wikimedia Labs called Forward to Libraries (FTL).
 * Overview

The same way coord provides readers with a helpful resource (finding the location of things), FTL provides a helpful resource to readers by helping them find books, reference material and other reliable sources on a subject at their local library. The service not only helps readers find detailed information from reliable sources, it can also be used by editors to expand and cite our articles.

This RfC is to determine how to make the best use of this new tool. 23:58, 19 May 2013 (UTC)

How FTL is implemented
The library templates produce links to a server script on Wikimedia Labs that redirects to searches in a local library's online catalog or other discovery system, so that users can find appropriate reading materials there. (Users can register their preferred library target for "your library" links; otherwise they can choose from the overall list of libraries. There are currently over 200 local library catalogs known to the service, along with larger catalog aggregations like WorldCat, as well as a catalog of free online books.  More libraries are added regularly, and users can also go to a form (linked further down this page) to request specific libraries be added.  The data on library links is published at Github, and I'm preparing scripts and documentation so that other Wikimedia developers can import and update this data as needed if I'm not available.)

The server script tries various techniques to formulate appropriate library catalog searches. If VIAF or Library of Congress identifiers or terminology are available, the forwarder will normally issue a search based on the corresponding subject or author headings, since those are what are commonly used in library catalogs. The forwarder can also try to convert the Wikipedia article title to a standard library heading based on algorithms and data that I will be be publishing in the near future as well. If no officially "authorized" library heading can be found, the forwarder will generally try a keyword search based on the Wikipedia article title.

I'd be happy to give more information to folks who might be interested in improving the implementation or helping maintain the Wikimedia forwarder. JohnMarkOckerbloom (talk) 01:32, 21 May 2013 (UTC)

How should FTL links be presented
The Forward to Libraries (FTL) tool is currently used in various templates as both boxes and inline links. The box template is Library resources box, and the two main inlined link templates are Library resources about and Library resources by. There are some lower-leval templates for single links Library link about and Library link by, which are normally not used directly.


 * Use in infoboxes The obvious place for links would be the External links section, but that's not how we use coord. We put that at the top where people will see it because it's a benefit. Similarly, I think the FTL link would be better used in a library resources sub-section of our infoboxes. That's where readers naturally look for information. 64.40.54.57 (talk) 23:58, 19 May 2013 (UTC)
 * Don't use in infoboxes For a very long time, perhaps forever, the level of usage will be far too low to justify yet more infobox bloat. External links. Johnbod (talk) 13:07, 11 June 2013 (UTC)

What articles should use FTL

 * Use in most articles Perhaps not current events or popular culture subjects, but most everything else would probably benefit from having an FTL link. 64.40.54.57 (talk) 23:58, 19 May 2013 (UTC)
 * Use with caution As far as I can see, FTL works on simple matching of publication titles with article titles (am I wrong there? - it's not very clear what Forward_to_Libraries means in practice). The number of articles where this will produce suitable matches is relatively low - biographies, species, places & other discrete objects of various sorts, but relatively few topic articles. Johnbod (talk) 13:11, 11 June 2013 (UTC)

FTL discussion
Wikipedia was not meant to be a final destination for readers. It was meant to provide an overview and to point readers to reliable sources with more detailed information about a subject. Linking a reader to books down the street at their local library seems like a benefit to both our readers and editors. 64.40.54.57 (talk) 23:58, 19 May 2013 (UTC)
 * I think the proposal is that an extra field be added to many infoboxes, although discussion is invited on any other suggestions. Is there an example of how it would appear? Johnuniq (talk) 01:18, 20 May 2013 (UTC)


 * Frankly the list of libraries signed up is way too small, and this form of search will not produce good results for a vast number of articles. Premature. Johnbod (talk) 02:03, 20 May 2013 (UTC)
 * @Johnuniq, my particular proposal was for the link to be used in an infobox, something like this.


 * This is just a quick and dirty example that could be changed in as many ways as infobox will allow. Editors are already using the FTL tool in Library resources box, etc.. 64.40.54.57 (talk) 02:16, 20 May 2013 (UTC)
 * Johnbod, the libraries don't need to sign up, all that needs to happen is for the url of the library OPAC to be added to the database, which is being done by request at this point. I don't know if there's any limit to the number of institutions that can be added to the service. The libraries in BC are there because I added a request, which you could do for your locals.  The Interior  (Talk) 02:38, 20 May 2013 (UTC)
 * Here's the request page:  The Interior  (Talk) 03:43, 20 May 2013 (UTC)


 * Comment. I don't think FTL is helpful. I tried using it moments ago and found out that Google books search was much more helpful.  Mohamed CJ  (talk)  11:23, 20 May 2013 (UTC)
 * Comment I really don't think 'further reading' should be in the infobox. And can we restrict searches so that it finds relevant books? Edgepedia (talk) 18:46, 20 May 2013 (UTC)
 * Comment, why in the infobox? Wouldn't this be more of an external link, or a see also item similar to how we treat wikicommons, or wikisources templates?--RightCowLeftCoast (talk) 06:52, 21 May 2013 (UTC)
 * Sounds good This is a definitely a good idea. I have just seen Bird article and there it is working wonderfully. The point Mohamed CJ has mentioned is valid too— most of the readers of Wikipedia will not need/never check those "find in your library" links. But, I personally strongly endorse the idea to provide an option to learn more about a subject. For example, I don't think not too many readers check Special:BookSources, but, that's a superb option! FTL can be a good alternative of "External links" and "Further reading" (since I can see it is providing "online books" lists too). About Johnbod's comment, that is correct, I am specially worried about WikiProject India articles and libraries, but, it can not be grows, until it is started. In my opinion, infobox should be the best place to add these links only if there are really some good material in the database! --Tito Dutta (contact) 02:35, 22 May 2013 (UTC)
 * Comment - Is there any way to automatically match&update the list of libraries that FTL needs, with the extensive list that we already have compiled at Book sources? The auto ISBN linking that we have works wonderfully, (eg ISBN 9780441012039), most of the time, and it would be a shame to have to manually replicate that entire list of libraries. –Quiddity (talk) 02:51, 22 May 2013 (UTC)
 * Thanks for your comment. I'm starting to go through that list now, when I don't have other explicit requests, concentrating primarily on the English-language libraries (since subjects and author names, unlike ISBN's, are language-specific).  So I'm hoping that before too long lots of libraries in one will be in the other.  I do need more detailed catalog linking information than just ISBN searches, but it may be possible for my templates and the BookSources service to draw on the same unified datasets down the line.  I'd be interested in hearing more from anyone who's involved with or knowledgeable about the BookSources implementation. JohnMarkOckerbloom (talk) 18:28, 22 May 2013 (UTC)
 * Comment2 - Using a random article example, George Carteret, I'd disagree with placing a link in the infobox (because we generally prefer to avoid external links within the body of an article as much as possible), plus not all articles have, or will ever have, an infobox, but.... possibly "Search Libraries" in the lefthand sidebar's Toolbox section? –Quiddity (talk) 02:51, 22 May 2013 (UTC)
 * In case FTL data is really helpful, in my opinion, placing it in infobox will make it more prominent and increase chance of getting noticed. In Infobox, article body ISBN links are placed which finally take to external sites. But, the only factor is— the amount and value of the data we are presenting! --Tito Dutta (contact) 03:04, 22 May 2013 (UTC)


 * Comment - should be like any-other external link. That is - in the external links section only.Moxy (talk) 17:29, 22 May 2013 (UTC)


 * This looks very much like an attempt to reinvent the Worldcat wheel. There is no chance of this ever being as comprehensive as Worldcat. Phil Bridger (talk) 18:59, 22 May 2013 (UTC)
 * Support. I can't understand Phil's objection; as I read it, this is completely different from Worldcat.  Rather than helping readers find all the locations of one work, it's meant to help readers find all the works in one location that deal with a specific subject.  It seems to be good for saying "Since you want to learn more, go to your local public library and borrow Title1 or Title2 on this subject", and that's a wonderful thing for us to be able to provide — basically like a geo-located and automated ==Further reading section.  Nyttend (talk) 23:20, 22 May 2013 (UTC)
 * "Rather than helping readers find all the locations of one work, it's meant to help readers find all the works in one location" that is an excellent description of the difference between WP:Forward to Libraries and WorldCat. Thanks very much for that, Nyttend. 64.40.54.104 (talk) 02:11, 23 May 2013 (UTC)
 * Worldcat has keyword search of book titles, just as FTL appears to, and for each book will order the list of libraries by distance from your indicated location, so will not only find what is in your local library but will also tell you the closest library that has a book. Phil Bridger (talk) 12:15, 23 May 2013 (UTC)
 * Although WorldCat fits my individual needs better (because I use several libraries, and would have to set this to one of them only--WC goes by area code, if you're willing to supply it) I very strongly think that for most people the proposed link is the best way to go. Having it directly part of our interface would be very  good.  BTW, I note that WorldCat is relatively useless outside the US and Canada, listing only the very largest national and university libraries. This proposal should be usable anywhere, as long as the library is listed. It's the basic function we   need, and considerations of what else individual might want should not interfere with adopting it. .   DGG ( talk ) 22:26, 24 May 2013 (UTC)
 * I find it very useful here in the UK. Phil Bridger (talk) 22:37, 24 May 2013 (UTC)
 * Yes, its use is expanding there. Similarly in Australia. DGG ( talk ) 04:12, 25 May 2013 (UTC)

Unarchived RfC. 64.40.54.29 (talk) 05:00, 14 June 2013 (UTC). Requested closure at WP:ANRFC. 64.40.54.196 (talk) 02:19, 20 June 2013 (UTC)
 * Comment I'm a supporter of this template, and I don't think it replicates the WorldCat service; OCLC is great way to determine where to find a specific item in my preferred libraries, but this template offers something different - the ability to see what my library holds on a topic with a single click. The benefit to readers is huge, and we need to start working more on libary/WP synergy.  As far as placement goes, I always pictured this link in the Further reading section, seems to be a good fit, and a good place to "roll out" this template as it evolves.  Kudos to JM Ockerbloom for his initiative on this!  The Interior  (Talk)
 * Comment I appreciate people's thoughts about this template, as well as their requests for more libraries.  (We're now at 270 and growing, and I've been working on adding the libraries already in Wikipedia's special Book Sources page.)  One reason for keeping the links in their own box, or in inlined text (as opposed to in the main infobox) is that there are multiple links possible, which might end up cluttering the main infobox.  (By default there's 2 links, one for checking the user's preferred library, and one for checking other libraries.  But adding links for resources by as well as resources about a subject, and adding links to online books, can yield as many as 6 distinct links.  Of course, those extra links should only be added when appropriate for the subject of the article.)  It sounds like if the links are in their own box, the preference would be to have it in the external links section; though if there is a clean way to add all the appropriate links to the main infobox, I'm open to ideas on how to do that.  JohnMarkOckerbloom (talk) 18:11, 20 June 2013 (UTC)

Possibly free files?
Well, I see we have a discussion board for disputing whether free files are potentially unfree, but we seem to have no real page for doing the opposite; determining whether an unfree file is actually free.

Do you think we need an entire Possibly free files page, or should we modify PUF to do both? ViperSnake151  Talk  16:37, 16 June 2013 (UTC)


 * Those cases can be discussed at WP:NFCR. --  Toshio   Yamaguchi  16:53, 16 June 2013 (UTC)
 * But that's for discussing whether the file is eligible for fair use. ViperSnake151   Talk  17:48, 16 June 2013 (UTC)


 * It is the proper venue for discussing whether a non-free file satisfies the non-free content criteria. If a freely licensed version of a file exists, then it cannot be used as non-free content, so that would be exactly a non-free content issue that can be discussed there. For some non-free files reviewed at NFCR it turns out that for example it doesn't meet the threshold of originality for copyright protection and is thus in the public domain, which means it is free content for Wikipedias purposes. --  Toshio   Yamaguchi  19:07, 16 June 2013 (UTC)


 * I think that WP:PUF would be the best venue for this. PUF is already used to determine the copyright status of "free" files, and determining the copyright status of "unfree" files is essentially the same thing, with the caveat that files tagged as "unfree" normally shouldn't be deleted whereas files tagged as "free" very often are deleted. We should consider making some separate templates for these files as the templates shouldn't mention deletion as a possible outcome. --Stefan2 (talk) 09:59, 22 June 2013 (UTC)
 * We'd have to reconfigure PUF in order to use it this way — go there with an image that's currently tagged as nonfree, and AnomieBOT will immediately close the discussion with a message of "This is already marked as nonfree". Presumably it wouldn't be hard to reconfigure it, but we can't do it instantly.  Nyttend (talk) 12:03, 25 June 2013 (UTC)
 * It looks like these are already being handled at WP:NFCR. Why change things? Anomie⚔ 21:10, 25 June 2013 (UTC)

Let's figure out a little bit more about how new editors are signing up
Every day we get around 3-4,000 people signing up for Wikipedia. The majority of these people (~70%) do absolutely nothing with their accounts. With work like GettingStarted, VisualEditor, and others we're trying to change that, but we still know very little about what people who are signing up every day want to do. My team recently just finished the redesign of the signup and login pages, and that includes a tool that has been around in some form before: the ability to add a campaign name to a link, so we know how many people sign up via it. (It only works on the account creation page, and it's not publicly logged anywhere.)

Anyway, of the many experiments my team might run, some are aimed specifically at the kind of editor who is trying to edit a page but doesn't yet have an account. We'd like to get a handle on this by adding campaigns to the anon edit notice and the view source notice for semi-protected pages. I've dropped notes at both those pages (here and here) but they're not very high-visibility, so I'm cross-posting. Please comment there if you're interested. If we can learn how many new signups happen because pages they are trying to edit are semi-protected, or because they decide to signup after clicking Edit on any other page, that helps us know how much effort we should be spending on this area, as opposed to say, new article creators.

Let me know if you have any questions. Campaigns are easy to set up and are potentially something that could be of use to WikiProjects or groups like the Teahouse, so if you're curious please speak up. <span style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; talk   01:27, 19 June 2013 (UTC)
 * Could/should we add campaign links to the various anon-specific welcome templates ? Possibly we're already tracking this? –Quiddity (talk) 02:05, 19 June 2013 (UTC)
 * Not a bad idea. We're not already tracking that, to my knowledge. <span style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; talk   02:09, 19 June 2013 (UTC)
 * And Why_create_an_account%3F which is linked from quite a few places (including the templates you linked to). —Th e DJ (talk • contribs) 13:02, 19 June 2013 (UTC)
 * Where I just [//en.wikipedia.org/w/index.php?title=Wikipedia%3AWhy_create_an_account%3F&diff=560604590&oldid=557994965 did] a bit of cleanup. —Th e DJ (talk • contribs) 13:30, 19 June 2013 (UTC)
 * Has anyone thought of the possibility that the accounts being signed up and then not used are spam or bot accounts, similar to the accounts that are signed up on forums? I don't know the inner workings of MediaWiki all too well, but bots that invade forums have been able to bypass both their captcha and re-captcha, so I don't doubt the same is possible here. Adversly, I believe it has been discovered that spam "people"/companies are hiring humans to bypass the captcha and then turning the accounts over to a machine to use for malicious purposes. I don't mean to discourage the efforts to introduce potential editors to the encyclopedia, just thinking of all of the possibilities that we have so many accounts being signed up but hardly any used. Jguy TalkDone 15:41, 19 June 2013 (UTC)
 * Historically, there have been a lot of spam/vandal throwaway accounts registered. However, before the edit filter it was quite easy to see what proportion of those actually became spam/vandal accounts, since they inevitably went on to do so - but this still left a lot of registered-but-never-edited accounts. Andrew Gray (talk) 20:32, 21 June 2013 (UTC)
 * Not sure how to find out the statistics, but I would surmise that many of these 70% of new users never record and promptly forget their password after changing from the initial random one. A gentle reminder ("Please record or memorize your new password") shortly after password changes would seem like an easy way to avoid much of this. Also, was the 70% figure based on all the connected wikis, or just the English-language Wikipedia? LeadSongDog come howl!  18:01, 19 June 2013 (UTC)
 * Also consider accounts of readers who never edited, but changed their user preferences. Are they being counted in the 70%? Kilopi (talk) 10:57, 20 June 2013 (UTC)
 * Yes, I mean all new accounts. <span style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; talk   21:11, 20 June 2013 (UTC)
 * It's definitely a mix of reasons. Some of the people are actually trying to edit, but wikitext scares them away. Others are trying to upload a file, and find out they need to be autoconfirmed. But yeah, I think some of them are forgetting their password and failed to register an email address. The new signup form still marks it as optional, but we know that more people register with an email address in the new form though, so it helps combat the "I lost my password and have no way to recover it" problem. <span style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; talk   21:05, 19 June 2013 (UTC)


 * It could also be because people may (mistakenly) believe they need an account to read Wikipedia, or otherwise may be missing some content by not registering. Many people may just create accounts to every website that allows them to do so, including Wikipedia, and they may never have any immediate desire to edit Wikipedia.  They likely either mistakenly believe they need to to read it, or they simply register for everything, unthinkingly, and semi-automatically.  -- Jayron  32  21:26, 20 June 2013 (UTC)
 * Support I understand this proposal as a request to conduct A/B testing on advertisements which would make offers to help new users become engaged to follow through with their motivation for registering an account. I hope that the tests are documented a bit and that you continue to maintain good communication about the research, but this kind of testing and research needs to be done and I support this completely.  Blue Rasberry    (talk)   05:51, 21 June 2013 (UTC)
 * If a username is unused after (say, a year), cancel it and free it for re-use? (How many total usernames are listed for Wikipedia?) Anthony Appleyard (talk) 07:32, 21 June 2013 (UTC)
 * Special:Statistics says there are 19,181,153 registered accounts, of which only 124,793 have edited in the past 30 days. I make that that only 0.65% of all user accounts are active. I agree something needs to be done about this - a large number of usernames are ties up, that could otherwise be of use. Mdann52 (talk) 10:09, 21 June 2013 (UTC)
 * There is also a number of accounts that will 'automatically' get registered here due to existing on another wiki, I imagine this number is rather high. I am all for adding campaign links to all of the welcome templates! Would be great to be able to see!  ·addshore·  talk to me! 10:48, 21 June 2013 (UTC)


 * Update: TheDJ has gone ahead and added campaigns to the two MediaWiki messages I mentioned before.  et al. We haven't yet added any to the anonymous welcome templates. I'm happy to do that whenever, but I have a logistical question... do we want individual campaigns for each template, or one campaign for them all? I would suggest we start with the latter, and get a sense of overall, how many new registered editors signup because of an anonymous welcome template. Once we have that overall baseline, we can talk about whether it's necessary to know which individual templates are most popular. Thoughts? <span style="font-family:Georgia, serif;">Steven Walling (WMF) &bull;  talk   19:02, 21 June 2013 (UTC)
 * That sounds good to me. Relatedly, I made some comments about welcome-templates over at mw:Talk:Flow Portal/Welcome Module. We might want to consider updating some of the templates, whilst we're adding links to them? (Though I do like your minimal welcome template, too ;) –Quiddity (talk) 19:16, 21 June 2013 (UTC)
 * Okay ✅ <span style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; talk   21:31, 22 June 2013 (UTC)


 * I'm not sure the specifics of what this proposal is, but I'm interested. As one of the users involved in testing it, i also make an obligatory canvass for WP:Snuggle, which is an interface designed at providing easier looking into and interacting with promising newcomers and dealing with new-account vandals. TheOriginalSoni (talk) 19:08, 21 June 2013 (UTC)
 * We could try confirming an e-mail address, like a lot of on-line sites do. That would do two things, cut down on the number of usernames, and give them a second chance to retrieve a lost password. Right now it is really a bit too easy for someone to register a hundred new usernames. Whatever we do, though, the real goal is to encourage more people to click edit. As to usernames with no edits, bear in mind that they can be usurped, but that is not an easy process. I would recommend against deleting accounts with no edits in a year, but none in five years might be okay. I see a lot of editors who seem to think about editing, and get as far as creating a username, and their first few edits are years apart. And if to keep an account all you had to do was make one edit, that is pretty easily gamed. Apteva (talk) 19:54, 24 June 2013 (UTC)
 * We already do ask that people confirm their email address. <span style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; talk   21:44, 24 June 2013 (UTC)
 * But as far as I remember it is not necessary to confirm the email address to be able to edit but only recommended? As for cleaning up old accounts I'd propose to remove those that never did any edits and were not logged into for over a year. This way probably no harm is done. --Patrick87 (talk) 22:28, 24 June 2013 (UTC)
 * Right, confirming your email address is only required to get emails, not anything else. Regarding clearing out old accounts: we should discuss it, but right now we actually don't have an ability to "delete" or reset accounts as far as I know. <span style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; talk   03:59, 25 June 2013 (UTC)
 * Hehe! Other than rename them to some random name "lskjafjahoiuhfjkn"  ·addshore·  talk to me! 11:09, 25 June 2013 (UTC)
 * If anyone cares, it took me 5 attempts before I was able to register a few days ago. It seem that everything was taken except for random strings, arbitrary numbers, or very long phrases. 20 million is far more than words in the dictionary, probably including all common names. This is exacerbated by the fact that the software considers a pretty wide range of names similar, so the number of actually prohibited user names is probably around 100 million to a billion. Someone not using his real name (talk) 13:50, 27 June 2013 (UTC)
 * One problem with recycled user-names is that a new user can be confused with the previous user. Having said that, it might make sense to derive a formula whereby a username is deleted after 1 + a + b years where a = time that the account was active and b = a function of the number of edits made by the person.  We do of course have to look at the problems caused  by sockpuppets - their names should never be recycled as they are tainted. Martinvl (talk) 14:35, 27 June 2013 (UTC)
 * On the other hand, since a majority of them "do absolutely nothing with their accounts", we could reclaim a large number of names simply by releasing the zero-edit/zero-action accounts after a year or two (or five, if you want to be conservative). An account that has never been used is not going to be an account that was used for socking.  WhatamIdoing (talk) 15:21, 27 June 2013 (UTC)
 * We should not delete Accounts with edits (even if only few were made). I think by deleting accounts without edits we would already free a large enough amount of usernames, without the need for any controversial formulas or the problems of "recycled user-names" Martinvl mentioned. --Patrick87 (talk) 15:40, 27 June 2013 (UTC)
 * I agree with the "1 + a + b" formula, but I disagree with the "...sockpuppets - their names should never be recycled as they are tainted." Technical 13 (talk) 16:04, 27 June 2013 (UTC)

Proposal to add a template to medical article talk page
WikiProject Medicine has discussed and reached consensus on a plan to add a template, Reliable sources for medical articles near the top of the talk pages of many medicine related articles. Discussion here.

The template provides links to search results to help editors find reliable sources. User:Anomie has agreed to add this template to about 12000 article talk pages via his bot, but we would first like to get broader community input.

Some precedents for this kind of template are:
 * 1) User talk:VIAFbot - This bot went to biographies and if WorldCat had an authority control identifier for the subject of the article, then it put a template linking the article to their library listing
 * 2) GLAM/smarthistory - a project to apply templates which link out to Khan Academy videos on art and culture
 * 3) Template:Library resources box - John Mark Ockerbloom's proposal to add a link to all Wikipedia articles which could connect any user to resources in their local library

Comments? Klortho (talk) 02:34, 21 June 2013‎ (UTC)


 * Support, same as I did when the idea was floated at WT:MED.   02:45, 21 June 2013 (UTC)
 * Support, given the importance of WP:MEDRS, this seems similar to BLP to me, and should be equally prominent. Chris857 (talk) 03:03, 21 June 2013 (UTC)
 * Support These are great links to high quality sources. Should help fellow editors improve Wikipedia. Doc James  (talk · contribs · email) (if I write on your page reply on mine) 03:08, 21 June 2013 (UTC)
 * Support per WP:NOTBURO, WP:BOLD, etc. -- Jayron  32  03:10, 21 June 2013 (UTC)
 * Support I am from WikiProject Medicine and while I do not believe that standardized infoboxes would work for most fields, in medicine there are a small number of repositories which contain copies of the majority of published articles. Linking to these sources on the talk page does not directly modify Wikipedia articles themselves, but will give talk page visitors the option to automatically perform searches based on an article's title in document repositories. Guidance for users to find the research in those repositories is critical the development of articles and these repositories are irreplaceable as catalogs of the best available publications.  Blue Rasberry    (talk)   05:41, 21 June 2013 (UTC)
 * Support Opens the door for more improvement in articles! smileguy91talk 03:38, 22 June 2013 (UTC)
 * Comment Pointing people to good sources is a good thing. However, WP:MEDRS is an overbearing policy used to exclude interesting research and ideas from articles, and anything that helps it therefore does a lot of harm.  I am also quite skeptical of the "review article" filter in NCBI - my feeling is that it points you to a lot of obscure little commercialistic journals with odd POVs that are not accessible in your university library, while typically missing the "good stuff".  It would be better to find or build a NCBI results filter that points people to the big guns (everything from Nature to PLOS), though selecting them is quite subjective. Wnt (talk) 18:12, 22 June 2013 (UTC)
 * Support. This template won't be a panacea.  No combination of policies, guidelines, templates, and search filters can substitute for cautious, contemplative, informed editorial judgement, nor supplant the role of competent subject-matter experts in building some of our most technical content.  Nevertheless, this looks like it provides some useful tools for our content builders, and equally importantly offers a constructive reminder of how we should approach writing medical articles.  Well done.  TenOfAllTrades(talk) 02:23, 23 June 2013 (UTC)
 * Support the general idea, but the template shouldn't use click here links. Unfortunately I can't think of an elegant solution to this problem at the moment. Graham 87 12:53, 26 June 2013 (UTC)
 * Support. Could help. Can't hurt. --LukeSurlt c 00:43, 28 June 2013 (UTC)

Wikipedia is too big. Please make it smaller.
There is way too much to keep track of here. I propose reducing Wikipedia's size by at least 50%. <font face="Century Gothic" style="text-shadow:1px 1px 3px #999;"> Equazcion ( talk )  06:06, 12 Jun 2013 (UTC)
 * Well, I suppose we could take out all the vowels. Would that help? Herostratus (talk) 06:13, 12 June 2013 (UTC)
 * Nt rlly! Jhn f Rdng (tlk) 07:14 12 Jn 2013 (TC)
 * No, because that was only a 30% reduction in size. HiLo48 (talk) 07:17, 12 June 2013 (UTC)
 * cmbn t wth thr sltns! Fram (talk) 07:34, 12 June 2013 (UTC)
 * I’m lost. Sultans? Slutness? Solitons?—Emil J. 10:31, 12 June 2013 (UTC)
 * Sultanas, clearly. We should bake it and turn it into cookiepedia for easier digestion MChesterMC (talk) 10:37, 12 June 2013 (UTC)
 * Actually, Equazcion has my total admiration for being able to keep track of something 50% the size of Wikipedia. HiLo48 (talk) 07:38, 12 June 2013 (UTC)
 * So, just delete all BLP's, and make all articles need at least 40 references? Mdann52 (talk) 12:15, 12 June 2013 (UTC)
 * 50% was just a conservative estimate. I probably couldn't break, say, 45%. But really it's just getting out of hand here. We have to have some limits. Mdann seems to have the right idea. Or maybe if we narrowed the focus, like delete all articles that don't have to do with cat breeds. <font face="Century Gothic" style="text-shadow:1px 1px 3px #999;"> Equazcion ( talk )  08:03, 13 Jun 2013 (UTC)
 * Let's just remove the letter "e". Big space savings...  GenQuest  "Talk to Me" 00:07, 14 June 2013 (UTC)
 * Or you could just join Citizendium, which only has a few thousand articles and a dozen or so active contributors. It was founded by Larry Sanger, co-founder of Wikipedia. Ypnypn (talk) 13:58, 13 June 2013 (UTC)
 * I recommend using a smaller font on your web browser. Resolute 14:02, 13 June 2013 (UTC)
 * I'm not sure if its just articles or total size you are referring too but here are some suggestions for elimination.
 * Get rid of WikiProjects. There are thousands of them, most with multiple pages, most are inactive or have low activity. Most do nothing but cause more drama and problems than they fix. We are better off without them. The only one I might consider keeping would be Biography because its used to track BLP's, catgorize the names and a few other things.
 * Change the categorization rules so that we don't create a new category unless there are at least 10 articles. The current policy is 3.
 * Get rid of the Book namespace. It doesn't provide anything useful and never really took off.
 * Get rid of the Topics. Another area where we don't get any return for the effort invested.
 * Modify the criteria for sports figures. How many international soccer/football players do we really need to identify.
 * Modify the criteria for films and movies
 * Modify the criteria for actors and acresses.
 * This is just a start. Kumioko (talk) 14:17, 13 June 2013 (UTC)

I hope Equazcion is joking, but anyway, no, Wikipedia is not too big. Wikipedia is way too small. Despite the number of articles may look impressive, we're far, far from having covered all notable subjects. Knowledge is a big thing. We have no limits, we're not a paper encyclopedia, we must strive to be bigger, not smaller, in article number and size. Nobody forces you to keep all of WP on your hard drive, so size limits are not a concern. Deletionism is already rampant enough, please let's avoid slashing even more of the knowledge thousands of editors managed to accumulate. -- Cycl o  pia  talk  14:34, 13 June 2013 (UTC)
 * The bigger it gets, the less accurate the information becomes, at least in my experience. Maybe a from-scratch approach to what might be considered notable? <font face="Century Gothic" style="text-shadow:1px 1px 3px #999;"> Equazcion ( talk )  16:04, 13 Jun 2013 (UTC)
 * If you ask me a from-scratch approach to what might considered notable, I'd replace notability with mere verifiability (except perhaps for BLPs). About accuracy, well, please provide data on this creeping inaccuracy and prove it is causated by the increase in the number of articles. Hint: even in case you find an objective measure of inaccuracy rising in time, remember that correlation is not causation. And even if it was the case, the solution would be to attract more editors (something WP is indeed remarkably inept at), not stomping on valuable content. -- Cycl o  pia  talk  18:36, 13 June 2013 (UTC)
 * Hello Cyclopias, when you say "we must strive to be bigger not smaller in article number and size", are you stating a personal opinion or a policy on this encyclopedia? I would be interested to hear. Thank you! Horatio Snickers (talk) 19:08, 20 June 2013 (UTC)

Dear Mr. President, There are too many states nowadays. Please eliminate three. I am not a crackpot. --Golbez (talk) 16:08, 13 June 2013 (UTC)
 * THANK you. Exactly. Many = bad, in most cases. I look at the rising total article count, and I'm like, d'oh! <font face="Century Gothic" style="text-shadow:1px 1px 3px #999;"> Equazcion ( talk )  16:17, 13 Jun 2013 (UTC)
 * It's a pleasant fantasy, isn't it? Let's dump all the articles on people, organizations (businesses, schools, government agencies, etc.), and products unless four or more proper books (not just newspaper articles) have been written about them plus the articles get at least 100 page views a day.  If we maybe add merging settlements containing nothing more than routine bot-added data into lists, then we might have a "manageable" number of articles.


 * But I don't think we would have actually improved any content in this process. It's fun to think about it as I struggle with my watchlist, but it's not something I'd support doing.  WhatamIdoing (talk) 18:48, 13 June 2013 (UTC)

The amount of unreliable content almost certainly grows as Wikipedia grows, but the amount of reliable content also grows, and, as our systems get more sophisticated, the reliable content should be growing at a faster rate than the unreliable content. This proposal seems to be based on the premise that a single editor should be able to monitor everything, which goes completely against the croudsourcing wiki model, which relies on articles being monitored, but not all by the same person. Phil Bridger (talk) 18:58, 13 June 2013 (UTC)

Too large? Not even close. Most of the storage for Wikipedia is probably taken up by the pictures. The actual text isn't that big: I can easily fit it on a corner of my laptop hard drive. Praemonitus (talk) 03:12, 15 June 2013 (UTC)


 * I personally think that Wikipedia will inevitably fork into more than one website at some point, but I don't think the community is ready for that just yet. Something like one site for topics involving history, the sciences, and so forth and another for all the biographies of marginally notable people, Pokemon episodes, and other pop-culture topics. The rules we apply for an article on a topic like, say Tibet during the Ming Dynasty probably don't need to be applied to an article on a topic like Fifteen Minutes of Shame. Beeblebrox (talk) 21:08, 16 June 2013 (UTC)


 * It is hilarious that keeping all cat breed articles is mentioned. I just signed on for WikiProject Fishes. How many articles do we have on fishes? 17,108. I mean, how can we possibly have this quantity of unsupervised fishes swimming through Wikipedia? We definitely need more cats. ツ  <font color="#595454">Fylbecatulous  <font color="#DB7093">talk  02:01, 19 June 2013 (UTC)
 * My cat regularly tries to eat the fish out of my fish tank. I don't have 17,108 fish, but maybe I'll make an article on my specific cat so that maybe some of the fishy articles will go away. In all seriousness, though, most of the space seems to be taken up by Projects (that are inactive) and images. Text is rather small and the goal of Wikipedia is to collect knowledge. Wikipedia is overwhelming with the amount of namespace articles, but most editors focus on one thing they're interested in and ignore most of the rest. The only exception is someone who fights vandalism (darn that ClueBot). :P Jguy TalkDone 14:21, 19 June 2013 (UTC)

When I first saw this I was wondering if I'd missed something, but then what Humioko said made me realise why this was serious. Okay the idea of getting rid of many of the WikiProjects isn't a bad idea. We should have a sweep of deleting pages where the user has been gone for say, 5 years? Just a base idea since I know that at least one user returned after about 3 years or something. (I think User:Yunshui adopted him so he could find out what was new about the wiki). Deletion of user pages and user talk pages of long gone users would definitely do its bit in cutting things down. MM (Report findings)  (Past espionage) 08:21, 28 June 2013 (UTC)

Generic images
We currently have tons of generic images, such as File:Map.jpg, File:Image.jpg, and File:Photo.jpg. They're all the same image (purely a little text, "Please don't upload files with this title. Use a more precise name."), and they're all protected to prevent people from uploading other images on top of them, which is good. However, having lots of them clogs up the list of identical images. What if we chose one as the "official" name and redirected all of the others to it? This is basically what they do at Commons; File:Name.jpg is the "official" name, and as you can see at http://commons.wikimedia.org/w/index.php?title=Special:WhatLinksHere/File:Name.jpg&hidelinks=1, most or all of the other generic image names are redirected to it. Of course I'm not suggesting that we unprotect anything or change the way we decide what to regard as generic; this is simply a housekeeping proposal. Nyttend (talk) 03:33, 19 June 2013 (UTC)
 * Seems reasonable, though I'm unaware of any other reason not to do it. --M ASEM (t) 03:55, 19 June 2013 (UTC)
 * Sure. I don't see a problem. Jguy TalkDone 21:29, 19 June 2013 (UTC)
 * Unlike Commons, however, we should protect those files that have redirects. It seems that commons does not do this for every file. :P Case in point: http://commons.wikimedia.org/w/index.php?title=File:Photo003.jpg&action=edit Jguy TalkDone 21:32, 19 June 2013 (UTC)
 * They have no need to do it — the point of the protection is simply to prevent uploads, and at Commons I don't believe that it's possible to upload on top of redirects. It's definitely not possible with that image: I tried to upload a one-pixel image (complete with a speedy-deletion tag) at File:Photo003.jpg and got a big warning message from Commons:Titleblacklist-custom-filename.  No real need to protect what's already been uploaded, since nothing can be uploaded on top of it.  Nyttend (talk) 04:53, 20 June 2013 (UTC)

Support It reduces how much unneccessary text Wikipedia holds. It's only a speck of it granted but it is a part of it and even a part of it can make a difference. MM (Report findings)  (Past espionage) 13:19, 25 June 2013 (UTC)
 * Support There are no added benefits and multiple drawbacks to the current practices as compared to your proposal. Nyttend, what you propose is exactly how things should be.  Blue Rasberry    (talk)   05:46, 21 June 2013 (UTC)
 * Support See Blue Rasberry above. smileguy91talk 03:33, 22 June 2013 (UTC)
 * Comment If this goes through and consensus is reached (I don't see a reason why it wouldn't), we should construct a list of what needs to be redirected. I'd be glad to help with adding redirects to those files in accordance with your proposal. Jguy TalkDone
 * You can't do the actual redirect adding — MediaWiki's page-protection setup makes it impossible to prevent uploads without preventing editing, so these files are unredirectable except by admins. List-constructing help would be appreciated, of course.  Nyttend (talk) 21:09, 26 June 2013 (UTC)
 * Aw, sad day. I'd be happy to help with lists, though :). Jguy TalkDone 21:26, 28 June 2013 (UTC)