Wikipedia:Village pump (proposals)/Archive 103

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.

Overview

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

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)

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)

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)

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

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: [1] 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 Wikipedia: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)

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

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)

WP:WQA was closed down for being ineffectual.

The consensus of the closure discussion was:

• Close WQA.
• Find an alternative.
• Not redirect it to ANI.
  

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)

My first thought is that you should review Wikipedia:PEREN#Hierarchical_structures 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. --Jayron32 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. --Jayron32 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)

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#Question re RfC on main page issues. Herostratus (talk) 03:15, 25 May 2013 (UTC)

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#Suggest merge. 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)

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)
• Wikipedia:Perennial proposals#Hierarchical structures. 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 Wikipedia:Perennial proposals#Hierarchical structures already? smtchahal^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)

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

All right, we already do. Never mind. smtchahal^talk 11:11, 25 May 2013 (UTC)

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, @Edokter:. –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 Wikipedia:Customizing watchlists#Styling of recently updated pages, 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)
• CommentSupport - 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)#Green highlighting of changes since last visit doesn't work anymore. --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. -
  

→Davey2010→→Talk to me!→ 00:19, 26 May 2013 (UTC)

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 ".updatemarker {display: none;} 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. Ignatzmice•talk 21:36, 25 May 2013 (UTC)
• Please bring back the green text highlighting (see Wikipedia:Village pump (technical)#Green highlighting of changes since last visit doesn't work anymore)... 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:

span.updatedmarker {
    background-color: transparent;
    color: #006400;
    display: inline;
}

— 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. Ignatzmice•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. Ignatzmice•talk 22:45, 25 May 2013 (UTC)

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. Ignatzmice•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)

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. — HHHIPPO 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)

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)

I'm proposing that we add a new link to the sidebar — "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. Ignatzmice•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 Wikipedia:Village pump (proposals)/Archive 92#My subpages 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.  — TORTOISEWRATH 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. — 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. smtchahal^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)

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 Wikipedia:Help desk/Archives/2013 May 25#Background and Style Changing)

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:

@import url('/w/index.php?title=User:Ignatzmice/colorswitch.css&action=raw&ctype=text/css');

Hope this helps. Ignatzmice•talk 03:50, 30 May 2013 (UTC)

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)

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)

I have just been assisting a new editor, who was adding {{Reflist}} to an article that already included <references />. 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 <references /> can go, and while we're at it, why not change {{Reflist}} into {{reflist|30em}}? 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)

{{reflist}} is implemented in terms of <references />. (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 {{reflist|2}} into {{reflist|30em}} 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, {{reflist|2}} and {{reflist|30em}} 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 Favor {{reflist}} as it is well featured, mature and simpler to use for advanced cases. As to {{reflist|30em}}, see Template:Reflist/doc#Practices. We can't eliminate <references />, but we can remove it from help pages and error messages, which will reduce confusion for new editors. --  Gadget850 ^talk 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. --  Gadget850 ^talk 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 <references />— it will always work. {{reflist}} is a wrapper for <references />. We can simplify documentation for new users. --  Gadget850 ^talk 15:31, 29 May 2013 (UTC)

• It would be acceptable if you encouraged new users to use {{reflist}} by changing help pages. Deprecating <references /> 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 <references/>, it's simple and works. The last thing we want is to see lots of people going around just to replace it with {{reflist}} to no benefit. The solution to the original problem is to help educate the new user, not to try to change all of Wikipedia. — Carl (CBM · talk) 18:07, 29 May 2013 (UTC)
  • You are correct. This will not pass and we should delete {{reflist}}. --  Gadget850 ^talk 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 decker^talk 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 decker^talk 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 decker^talk 19:33, 29 May 2013 (UTC)

  The proposal is really just to decrease the prominence the simple version (<references />) currently has in documentation. -- As Gadget850 says above, "We can't eliminate <references />, 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 decker^talk 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 <references /> can't be removed (see #Explanation, 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)

• I am going to take exactly one stab at this:
  • We can not remove <references />, it is integral to Cite, the software that runs the Footnotes system.
  • {{Reflist}} is merely a wrapper for <references /> that adds support for columns, List-defined references, groups and predefined groups with list style. All of this can be accomplished with just <references />, 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.
  • <references /> is so much simpler; here is how to do columns:

<div class="reflist references-column-width" style="-moz-column-width: 20em; -webkit-column-width: 20em; column-width: 20em;">
<references />
</div>

• I don't really expect this to get through, and I anticipate yet another devolving discussion. --  Gadget850 ^talk 00:55, 30 May 2013 (UTC)

• • To rephrase, then, I oppose the need to write a line of CSS when 2c is desired. It would be impenetrable to most of our readers, and as this would be the inevitable consequence of deprecating Reflist, I oppose said deprecation. Templates are for hiding complexity. Reflist does that job just fine. --j⚛e decker^talk 01:02, 30 May 2013 (UTC)
    • This proposal is the direct opposite. We want to deprecate <references /> and make {{reflist}} the main thing in documentation and etc. I cry now. –Quiddity (talk) 09:06, 30 May 2013 (UTC)
      • I don't object to deprecating <references /> in theory, I just think it'd be a mess to implement. If you can get it implemented, more power to you. *hands you a tissue* --j⚛e decker^talk 20:04, 30 May 2013 (UTC)
• The example given seems to directly refute the claim that "<references /> is so much simpler". MartinPoulter (talk) 12:20, 4 June 2013 (UTC)

• This will go no where. Move to close discussion. GenQuest ^{"Talk to Me"} 23:00, 4 June 2013 (UTC)

• Yes. Ed has shown that <references /> cannot be deprecated per se, so there is no point discussing that any further. We are left with deprecating in the documentation any suggestion of using it. That seems to be a good idea. ~ J. Johnson (JJ) (talk) 23:44, 4 June 2013 (UTC)

We currently have 48 US states at "Statename", and the exceptions are Washington and Georgia, which consensus has determined not to be the primary topics for those titles; both Washington and Georgia are disambiguation pages. Unfortunately, these two states aren't disambiguated the same way — we have Washington (state) and Georgia (U.S. state), and while Washington (U.S. state) is a redirect to Washington (state), Georgia (state) redirects to the Georgia disambiguation page.

With this in mind, I'd like to propose that we move one to the other's naming convention. I don't care if we end up with "Washington (U.S. state)" or "Georgia (state)" — although I'd prefer that we use one or the other; any third option would be inferior — but I don't see a good reason to have separate names for them. Please note that this proposal encompasses much more than just the state articles; should my proposal pass, it will result in changes to all pages in which the disambiguation appears, including articles such as Category:Cities in Washington (state) and Government of Georgia (U.S. state). I'll notify the two states' wikiprojects as well as leaving notes at the state talk pages. Nyttend (talk) 16:08, 1 June 2013 (UTC)

The simplest possible identifier was used for both articles. The problem is that the country of Georgia is also a state in the broad sense of the word, but there's no other state in the world named "Washington". —Designate (talk) —Preceding undated comment added 16:12, 1 June 2013 (UTC)

But by being simple in that way, we're making it more complex for typical readers, who won't know why the two are different. Nyttend (talk) 16:19, 1 June 2013 (UTC)

Just saw this on my watchlist. I've often wondered why Wikipedia uses Georgia instead of the name used by the people of the country, Sakartvelo (the Name section). I understand that Georgia is the Westernized name, and this is the English Wikipedia, but it seems logical to me to use the name that the people of the country use. Reb (talk) 16:38, 1 June 2013 (UTC)

Like you said: This is the English Wikipedia. Same reason España redirects to Spain, Bhārat Gaṇarājya redirects to India, ایران‎ redirects to Iran... Ignatzmice•talk 16:48, 1 June 2013 (UTC)

• I strongly oppose both proposed moves. As Designate noted, the current titles comply with our naming conventions. "Georgia (state)" is insufficiently precise (because the country is a state) and "Washington (U.S. state)" is overly precise (because no other state is called "Washington").
  Wikipedia contains many similar disparities, such as titles with "(TV series)" appended and others with "(U.S. TV series)" appended. The fact that we have exactly two instances of parenthetical disambiguation among the fifty U.S. state articles is immaterial (and in no way dictates that we ignore a meaningful distinction for the sake of forcing parity). —David Levy 17:09, 1 June 2013 (UTC)
  • What he said. As Ralph Waldo Emerson once wisely quipped "A foolish consistency is the hobgoblin of little minds." There's always a balance to be played between any number of factors when deciding how to name an article, and while consistency within Wikipedia is one of those factors, it should not be elevated above all other concerns, and in situations where being consistent runs into conflict with other, valid concerns, we need to consider that sometimes, being inconsistent is necessary. --Jayron32 17:56, 1 June 2013 (UTC)

• I think consistency is important. However, in order for both articles to have the same parenthetical disambiguation, one of the two would have to be inconsistent in the application of WP:PRECISION, and I think being consistent with following Wikipedia policy is important than having the disambiguation match just because they are different, since being different doesn't seem to present any sort of issue other than not matching. - SudoGhost 05:54, 2 June 2013 (UTC)

• Support as both are U.S. states: After thinking about the issues for a few years, I finally realized "Washington (state)" is actually "Washington (state (U.S.))" when explaining the state, or just "Washington (U.S. state)" as the same type of disambiguation as "Georgia (U.S. state)". Now, for people thinking about the United States only, then the terms are "Washington state" and "Georgia" but from a global perspective, the term "Washington (U.S. state)" is more logical when considering "Georgia (U.S. state)" as the same level of disambiguation. I guess a similar problem would occur with "Rome" for "Rome (apple)" or "Macintosh (apple)" or "Macintosh (Apple)" (as the Apple Mac computer), where the term "apple" versus "Apple" could confuse people over 2 different meanings. Currently it does seem confusing to have "Washington (state)" mean "state (U.S.)" while "Georgia (state)" means "state (nation) or state (U.S.)" to choose. So, "Washington (U.S. state)" should be the article title, but within the United States, then "Washington state" would be the local-common title, as a redirect. -Wikid77 (talk) 16:29, 2 June 2013 (UTC)

I agree with Wikid's logic that putting just (state) does seem to be American-centric; BUT I have a question (for anyone to answer)- Would an Australian (to keep it English-language, but substitute Brazil state or Canada and province) state with a disambiguated title be xy (Australian state) or just xy(state)? If the first, then yes Washington (state) is an American-centric title and conformity with Georgia (US state) should be instituted; since now the argument that it would violate policy for the sake of conformity would be thrown out in favor of not violating the spirit of policy on English Wikipedia being a GLOBAL perspective and not AMERICAN-ENGLISH Wikipedia. If the answer is the second that it would just be disambiguated with xy (state) then there is no proof of an American-centric bias. — Preceding unsigned comment added by Camelbinky (talk • contribs) 15:54, 4 June 2013 (UTC)

Belgorod and Belgorod Oblast do not mention the country name. Neither do Lublin and Lublin Voivodeship. Just a few examples. The U.S. examples use the parenthetical because the common names of those locales do not include the word "State", except in contrast with other similar names, for example the phrase "Washington State" is only used when context is necessary to avoid confusion with the city of Washington, when context does not lead to confusion, the word "State" is never used. In the case of Georgia, it is never called "Georgia State". --Jayron32 16:03, 4 June 2013 (UTC)

Both of those examples oblast and voivodeship are Russian specific words. In this case state is an English word with the problem of being both a US subdivision (or Australian or any number of nations) and also a commonly used word for "nation" as in State of Israel. Is it possible to take that into consideration?Camelbinky (talk) 16:17, 4 June 2013 (UTC)

We should take into consideration that Victoria (Australia) exists as the title for the Australian state of Victoria. This shows that there does seem to be an American-centric bias in using the disambiguation of (state) instead of (US state) and that this would trump any idea of it being against policy of "simplest disambiguation". Unless we now have consensus to move Victoria (Australia) to Victoria (state). Of course please let me know if there is already more than one state in the world named Victoria, in which case why is it not Victoria (Australia state) in keeping with Georgia (US state)?Camelbinky (talk) 16:27, 4 June 2013 (UTC)

Don't know. Your line of questioning assumes that there's some previously hidden master plan which has resulted in the current situation; that is the fact that Victoria, Washington, and Georgia have the parentheticals they do is because of some well-planned, deliberate method which you are not privy to. I'd instead point out that the current situation is the result of different editors at different times making different decisions and not because there is any plan at all. Remember, not everything is because people are deliberately trying to be nefarious. Lots of things (most things) happen because of chance or for arbitrary reasons that do not have ill-intent. --Jayron32 16:39, 4 June 2013 (UTC)

Is there a particular reason why you believe that the Australian article sets the standard? Other articles about subnational states whose titles contain "(state)" for disambiguation include:

Austria

• Salzburg (state)
• Tyrol (state)

Germany

• Bremen (state)

Mexico

• Hidalgo (state)

(To avoid confusion with the country, Mexico (state) was moved to State of Mexico, a translation of the state's official name.)

Sudan

• Al Jazirah (state)
• Al Qadarif (state)
• Blue Nile (state)
• Kassala (state)
• Khartoum (state)
• Lakes (state)
• Northern (state)
• Red Sea (state)
• River Nile (state)
• Sennar (state)
• Unity (state)
• Upper Nile (state)
• Warrap (state)
• White Nile (state)

Venezuela

• Miranda (state)

(For reasons that are unclear to me, other articles' titles were changed to the "[State Name], Venezuela" format.)

I copied this list from the 2011 proposal to move Victoria (Australia) to Victoria (state), which failed to achieve consensus. —David Levy 22:37, 4 June 2013 (UTC)

I'm not quite sure where to propose this, but I've seen this a lot and don't know if I should fix them by hand (with help?), look for a bot or have Wikipedia do it automatically. For example: in Category:Lists of chapters of United States student societies by society, most of the articles start with "List of". They should *not* be sorted by the name of the article, but almost always by the name of the article with the "List of" deleted so List of Sigma Alpha Epsilon chapters should be sorted as 'Sigma Alpha Epsilon'. Possible answers

• Wikipedia software does it automatically (If Category starts with 'Lists of' and article (or subcat?) starts with 'List of' then 'List of' is deleted from the sorting criteria
• Have a bot automatically in the 'List of' article a sort key in the category entry (which starts with lists of) which deletes 'List of' from the sort key. (Would do nothing if sort key already exists.
• Get a listing from the Wikipedia database of how often this occurs (Category starting with "Lists of", article or subcategory starting with 'List of' and no manual sort key) to see if this occurs 50 times or 50,000 times.

Ideas?Naraht (talk) 16:21, 4 June 2013 (UTC)

The safest thing I'd say for now it that it could be set up as an AWB general fix.  Hazard-SJ  ✈  05:42, 5 June 2013 (UTC)

This idea was proposed back in 2011, and I repeat the proposer's rationale:

Any bot that has not made a single edit within the past two years or, in the case of bots with sysop permissions, logged a single action within the past two years are subject to immediate stripping of their flag.

Pro: Throughout most of the MediaWiki software regarding any form of feeds, such as Special:RecentChanges and Special:Watchlist, edits under the bot flag are automatically hidden from view. Compromised bot accounts, with perhaps some malicious code accidentally inserted into their system, would most likely be able to surreptitiously damage several Wikipedia articles en masse without any administrators aware, since the bots have been inactive and the administrators would have ceased to watchlist their retired operators after a certain amount of time. Without the bot flag, any bots that could possibly be compromised would have their edits visually seen in RecentChanges, and sysops monitoring the page can more easily spot the pattern, block on sight and revert any potential damage dealt to articles the bot had edited. If bot operators choose to restart their bot, they can easily do it via the Wikipedia:Bots/Requests for approval process again.

Contra: Nothing that I'm aware of.

The 2011 proposal failed, partially because people likened it to the perennially failed proposal to remove administrative rights from admins who hadn't used them. Since 2011, we've approved a process to remove administrative rights from inactive admins. Why can't we do the same for inactive bots? Nyttend (talk) 23:35, 22 May 2013 (UTC)

• Support - I would suggest applying the same criteria as is applied to inactive admins. If they haven't edited in a year, remove the flag. If the bot op wants to start the bot back up all they need to do is ask. Kumioko (talk) 00:19, 23 May 2013 (UTC)
• Comment – How would these bots be detected? It would be useful to get a look at the types of bots being targeted before assessing this proposal. Praemonitus (talk) 00:21, 23 May 2013 (UTC)

• Targeted: I meant bots of all sorts. We have a bot that currently figures out which admins are active and which aren't; presumably we could have it apply the same criteria to all users with the bot flag, or we could write another bot to perform such a task. Nyttend (talk) 00:28, 23 May 2013 (UTC)
  • By that I meant: could we see what bots would be rendered inactive if this were implemented today? Praemonitus (talk) 01:04, 23 May 2013 (UTC)
    • The point is that my proposal would only affect bots that are already inactive. A few, chosen at random, are AlnoktaBOT, EBot, KittyBot, People-n-photo-bot, RobotJcb, SunCreatorBot, and Yonidebot. I expect that you'd need a bot or database report to see a list of all of them. Nyttend (talk) 01:39, 23 May 2013 (UTC)
      • • Just be careful about User:Joe's Null Bot when you do that database report....  ;-) --j⚛e decker^talk 01:55, 23 May 2013 (UTC)
          • I'm imagining that our bot would make reports to WP:BN (where I've left a note about this discussion) listing inactive bots, like it does for inactive admins. Presumably the bot operator could instruct it (1) to notify users who are identified as operators by {{bot}} on bot userpages, and (2) to ignore certain bots, such as yours, that need the flag but appear to be inactive. Nyttend (talk) 03:19, 23 May 2013 (UTC)
            • Indeed, can't imagine that that would be a problem, mostly I still find the Null Bot thing rather hilarious. --j⚛e decker^talk 16:09, 24 May 2013 (UTC)

• Weak Support I don't know if this is an active problem, but it's probably a good practice in any case. --j⚛e decker^talk 01:55, 23 May 2013 (UTC)
• Support - Nothing really big to worry about, but it would be a good change. (X! · talk)  · @130  ·  02:07, 23 May 2013 (UTC)
• Support. I should add that whilst codifying a policy on inactive bots helpful, bureaucrats have previously removed flags from inactive bots at the request of BAG. I certainly see it as within BAG's scope to revoke approval on groups of inactivity and would continue to do remove flags if so asked regardless of whether a 2 year cut-off is specifically agreed. "The BAG giveth, and the BAG taketh away..." WJBscribe (talk) 10:06, 23 May 2013 (UTC)
• Weak support as long as the owner (if they are active) is notified and the bot is actually inactive (i.e. exclude read-only bots). "Weak" as this isn't really a problem as far as I'm aware. Also there shouldn't be any hassle to have the flag reinstated. —  HELLKNOWZ  ▎TALK 12:56, 23 May 2013 (UTC)
• Conditional support: Not all bots have visible activity. Accounts can also be bot-flagged to get access to the higher API limits that bots are allowed, or because (as in the case of User:Joe's Null Bot) they make null edits. Any de-flagging procedure needs to take these cases into account. --Carnildo (talk) 00:37, 24 May 2013 (UTC)
• Might as well. though I suppose this means my bot is going to lose its flag, too. If the bot isn't operating, it really doesn't need a flag. – Philosopher ^{Let us reason together.} 00:43, 24 May 2013 (UTC)
• Support but be careful not to accidentally remove the flag from non-editing bots per Carnildo. -- King of ♥ ♦ ♣ ♠ 01:44, 24 May 2013 (UTC)
• Given there seems to be some initial support, here are a few unanswered questions:
  • What will happen if bot owners wish to regain the bot flag for their bot? My User:TTObot is approved for a task that runs "as requested", but it has not been used for years. Even so, it is still approved to run, so I shouldn't need to go back to BRFA. If I want to run that same task once TTObot is de-flagged, I feel as if a simple request at WP:BN should be enough to get the flag back.
  • Will users need to express an intent to actually run their bot if requesting the return of the bot flag?
  • What will happen if a de-flagged bot randomly starts up again, making legitimate edits for which it was approved? Just give it back its flag without question? This scenario is unlikely, but if it does ever happen, we should be prepared for it (so RecentChanges flooding can be mitigated quickly).
  • I am particularly worried about bots which are "silently" used for purposes that do not need BAG approval. For example, I sometimes use TTObot for performing one-off high-volume API requests, something which does not require approval, but is a perfectly legitimate use of the bot flag. Am I entitled to keep TTObot's flag for this purpose?
• — This, that and the other (talk) 08:04, 24 May 2013 (UTC)

• Hadn't thought about several of these points. My proposal was not meant to affect Joe's Null Bot, your TTObot, or any other bot that uses its bot flag to do things that don't show up at Special:Log or Special:Contributions. I'm imagining a situation in which operators are notified that their bots are about to be de-botted, and they're given the opportunity to explain why the bot should retain its flag, with "This bot is used for things that don't get logged" being considered a great reason not to de-flag. The purpose for requesting this policy change is for site security and to reduce the chance that a hacker could "hide" from Special:Recentchanges via the bot flag; as a result, if the bot should return and again edit in the way for which it was approved, I'd suggest that a simple note at WP:BN would be sufficient reason to restore the flag. Nyttend (talk) 00:54, 25 May 2013 (UTC)

• From my point of view requiring people to scan over a list of bot flags identifying what is active and inactive is a waste of time. Leaving the bot flags on bots has not broken anything to date that I know of and I do not expect it to break anything in the future. I don't think this should be a part of the policy although It might be an idea for a member of BAG to try and contact some of the older bot flag holders to identify if they still need the flag and then request a removal depending upon their response. ·Add§hore· ^{Talk To Me!} 09:28, 27 May 2013 (UTC)

• We already have a bot that scans over a list of admins identifying who is active and inactive. Doing the same for bot flags wouldn't waste time. Nyttend (talk) 16:00, 1 June 2013 (UTC)

I wouldn't go and make this policy, but I will happily try and clear out some old bots :) ·Add§hore· ^{Talk To Me!} 17:37, 27 May 2013 (UTC)

• I'm going to stay neutral with this for now. I somewhat agree with Addshore, but if in the case that the flags would be removed, I'd prefer that someone notify each affected operator from a reasonable time in advance before the flag may be removed. In such a case, if the operator fails to respond, and the bot has still not been started for any visible purpose, or if the operator responded saying it may be deflagged, it could be deflagged, with a request to any bureaucrat (not limited to WP:BN, perhaps) to reflag it. Also, in such a case, what is considered an "inactive bot" (in time period)?  Hazard-SJ  ✈  01:11, 28 May 2013 (UTC)

• That makes complete sense. I agree that we should remove the flag from inactive bots but they aren't hurting anything at the moment either so taking a little extra time to contact the bot ops makes sense. Worse case scenario they don't respond. Best case they come back and start the bot back up. Kumioko (talk) 01:31, 28 May 2013 (UTC)

So, contact bot op, inform them of what I am doing, wait a week or so, request deflagage. ? ·Add§hore· ^{Talk To Me!} 08:45, 28 May 2013 (UTC)

Just an idea but would it be possible to have 2 separate bot flags? One which would allow the bot such permissions as high API requests and the second to allow to hide recent changes from the RC page. Every bot that had an approved task would have the first flag, those that needed to be hidden from the RC page would have both. This would make managing bots on enwiki so much easier in my opinion. Every active bot with an approved task would have a flag, if a bot did not have a flag it would mean it were not approved. Pluses include that would always be able to identify all bots on wiki, and we would actually have a full active bot list. Also we could allow the regular bot flag to be granted by admins and the second flag allowing bots to be hidden from RC to crats? Thoughts Nyttend, Joe_Decker, X!, King_of_Hearts, Hazard-SJ? (thought I would try out this new ping thing ;p) ·addshore· ^{talk to me!} 09:22, 30 May 2013 (UTC)

Sensible enough, and I'd support, although I don't know that we need to let admins like myself in on the flagging fun. For enabling them, I'd imagine it'd be simplest to hit either or both at the same time. And admins could still block bots when there's urgent cause, so there'd be no hurry with regard to unflagging. *shrug* I tend towards liking granular permission models, but I realize some people find them a form of bloat. --j⚛e decker^talk 15:16, 30 May 2013 (UTC)

Just saw this — for some reason the ping thing didn't work. The sole reason for this proposal was the RC hiding, so I wouldn't at all oppose splitting that function from all other features of the bot flag; I don't know of any features except the RC hiding that would potentially have any significant effect on site security. Nyttend (talk) 16:00, 1 June 2013 (UTC)

The individual flags can be seen here and for a bot are bot, ipblock-exempt, autoconfirmed, autopatrol, autoreview, noratelimit, suppressredirect, nominornewtalk, skipcaptcha, apihighlimits, writeapi. The plan could be to have one permission containing exactly this and a second permission containing all but 'bot' which is what allows them to avoid the recent changes feed. Potentially a larger RFC with more detailed options might be worth it? *pings User:Nyttend lets see if this works* ·addshore· ^{talk to me!} 18:50, 1 June 2013 (UTC)

Got the ping this time; not sure what the difference was. I like the idea, but I don't want to ask to have this proposal put on hold; what if we went ahead with this proposal and then started the new RFC upon this proposal's closure? Re Joe — as I see it, people oppose granular permission because they think that they turn Wikipedia into a kind of caste system for different users, and I doubt that this would be a reason for people to oppose splitting the userrights for bots. Nyttend (talk) 19:33, 1 June 2013 (UTC)

Sounds good User:Nyttend! I don't see the community having any issue with this as nothing is really changing, bots are not going to have any extra permissions (unless we split the flag in some sort of funky way). ·addshore· ^{talk to me!} 19:45, 1 June 2013 (UTC)

User:Nyttend, I have started a draft here, still working on it and will announce here once the RFC is ready and actually starts. ·addshore· ^{talk to me!} 19:21, 2 June 2013 (UTC)

Please see the now open RFC here ·addshore· ^{talk to me!} 10:23, 6 June 2013 (UTC)

A request for comment has been started at Wikipedia:Requests for comment/The bot flag regarding removing the bot flag from inactive bots and potentially modifying the bot flag itself. The RFC started after the discussion above. ·addshore· ^{talk to me!} 10:26, 6 June 2013 (UTC)

I suggest that people, perhaps once per week, get in the habit of checking for unusual problems in the Wikipedia pageview counts, such as reported by stats.grok.se. Any issues could be noted here, and then if critical, then others could be notified of the issues.

All during May 2013, I carefully checked the pageview counts, and confirmed that almost all pageviews logged at day's end, logged after 23:00 UTC, will be added to the next day, or 2 days later, when viewed by stats.grok.se, rather than added for the actual day with the earlier pageviews which were made between hours 00:00-22:59. -Wikid77 (talk) 16:33, 1 June 2013 (UTC)

Yes, you're welcome to do this, and I thank you for your diligence, but...a proposal? Why? Theopolisme (talk) 21:42, 1 June 2013 (UTC)

Let's see: stats.grok.se, that'd be .se, which is Sweden, which is one hour off from UTC. Why does it surprise you that a Swedish website would use the Swedish timezone? WhatamIdoing (talk) 21:42, 7 June 2013 (UTC)

Hello,

There is currently a proposed addition to the Conflict of Interest guidelines that we currently have regarding existing users and publicly-disclosed COI editors.

You are requested to see that discussion, and give your views on the same.

TheOriginalSoni (talk) 19:07, 7 June 2013 (UTC)

A very useful information page, use as an guideline of Wikipedia:Proposed mergers. Asiaworldcity (talk) 01:05, 8 June 2013 (UTC)

I had a dream where I was using Wikipedia and I came across a special page that listed all of the users who were going to be unblocked today. You could use this, or perhaps a list of users who were recently unblocked rather than towards block expiration. Just thought that I'd suggest it before I forget. --66.190.69.246 (talk) 07:05, 2 June 2013 (UTC)

Manually unblocked or block expiry (like this)? I don't think there is one... --Krenair ^{(talk • contribs)} 18:58, 2 June 2013 (UTC)

• What would be the purpose of this? The block log contains all unblocking events.--Jasper Deng (talk) 19:03, 2 June 2013 (UTC)
  • It's not particularly easy to see which editors have had blocks expire recently. There's been many a time that I would like to see what IP and range blocks have recently expired to see if I can correlate them with renewed disruption.—Kww(talk) 19:06, 2 June 2013 (UTC)
    • Maybe a bot could update a page with this? Theopolisme (talk) 15:17, 8 June 2013 (UTC)

Five days ago, User:B left the following message at WP:VPT, but nobody's yet responded:

Can we get a bot to go through and substitute the "migration" flag of images with the {{GFDL}} template? Right now, today, if someone uploads a {{GFDL}} image, it shows the {{License migration}} template. Now that it is four years after the license migration, I think it makes sense to change the default to be not eligible for migration. But in order to change the default, we would need a bot to do a one-time addition of something like migration=not-reviewed to all existing uses of the GFDL template. So if you have {{GFDL}} or {{self|GFDL}}, the template would add "migration=not-reviewed" to the template. After that is done, we can make the default "not-eligible" instead of the default being pending review. --B (talk) 00:16, 2 June 2013 (UTC)

Would anyone object to this idea? I left a note at WP:BOTR and was given a response of I'm willing to do so, but I'm not sure if this needs wider discussion, per WP:NOCONSENSUS. Also, for clarification, it would be adding |migration=not-reviewed 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)

How many transclusions are we talking about? That means: How often is {{GFDL}} 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)

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

Discuss below: "#Discuss: Simple fixes of edit-conflicts".

Earlier: "User_talk:Jimbo_Wales/Archive_134#Let's fix edit-conflict problems"

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 "Sn") to consider:

• 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.

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.

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.

• 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 "{{ec}}" template (which says: "(edit conflict)") 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 "{{ec}}" even if the article main-namespace hid the message "(edit conflict)" 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.

That is the status. -Wikid77 (talk) 07:20/17:11, 25 May 2013 (UTC)

This subthread is for discussion of extensive edit-conflict issues, explained above ("#Auto-correct more edit-conflicts"). 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)

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 meta:Concise Wikipedia‎ which User:Dr. Blofeld created months ago, and has a thread about (at #Concise wikipedia proposal) 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#Concise version of wikipedia (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#Concise wikipedia proposal (November 2012)
• User talk:Jimbo Wales/Archive 135#Concise wikipedia proposal (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)

• 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#Length ("In most cases, the proper length is between two and twelve words") descriptions for everything.
  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 meta:Concise Wikipedia#Related projects/proposals 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)

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

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)

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)

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:

  Jimmy Wales (talk | History) This page will be removed in 3 days [change]
  Wikipedia (talk | History) This page will be removed if the article is deleted [change]

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? Deadbeef 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. Deadbeef 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.--Launchballer 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 雲‍水 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 {{Facepalm}}? WhatamIdoing (talk) 15:18, 26 April 2013 (UTC)
    • Yes, thanks. Lectonar (talk) 12:41, 29 April 2013 (UTC)
  • They did. Discussions from 2007: Wikipedia:Village_pump_(proposals)/Archive_AB#Watchlist_enhancement_-_.22temporary_watch.22_feature.3F and 2011: Wikipedia:Village_pump_(proposals)/Archive_69#Expiry_of_watchlist_items. Idea mentioned in 2002: Wikipedia:Phase_II_feature_requests#My_watchlist. 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. • • • Peter (Southwood) ^(talk): 09:34, 27 April 2013 (UTC)
• Support Great idea! Feedback ^☎ 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. —/Mendaliv/^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 | 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. Lukeno94 (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. PamD 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! — 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". Ignatzmice•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. '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 · 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 <notes> 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. Martin451 (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. SpinningSpark 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. Cabe6403 ^{(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. 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. --ELEKHH^T 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. smtchahal^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. var j = JSON.parse( mw.user.options['userjs-tempwatchlist'] || '{}' ), d = +new Date;for ( i in j ) { if ( j[ i ] < d ) { /* $.get the watch tokens, use action=watch&unwatch= to unwatch the page, action=options to remove the page from the userjs-tempwatchlist option list, yadda yadda */. --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. —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. It Is Me Here ^{t / c} 17:13, 3 June 2013 (UTC)
• Support.  . Herostratus (talk) 17:58, 3 June 2013 (UTC)
• Support - Fantastic idea. Red Phoenix ^{build the future...}_{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. —Mikemoral♪♫ 22:44, 11 June 2013 (UTC)

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: 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. Ignatzmice•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···Vanischenu^「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.--  Gadget850 ^talk 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:

bugzilla:5231

Wikipedia:Gadget/proposals/Archive 3#Sidebar translate links

Wikipedia:Village pump (proposals)/Archive 78#Add language names in English as tooltip in language links

Wikipedia:Village pump (technical)/Archive 94#Feature request

Wikipedia:Help desk/Archives/2011 August 24#Interlanguage map?

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. Saudade7 21:42, 14 May 2019 (UTC)

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".[2] 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!  :-) — 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. ∴ 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. ∴ 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. • • • 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 #Translation of language names, and the ongoing work at mw:Universal Language Selector which is highly related. –Quiddity (talk) 03:39, 13 June 2013 (UTC)

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

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)

Please see Help talk:Citation Style 1#RFC: Consistent date location 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)

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)

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, Ocaasi ^{t | 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, Ocaasi ^{t | 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)

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&^{(Je vous invite à me parler)} 05:16, 16 June 2013 (UTC)

I agree that Wikipedia:Edit filter is the first place to look. WhatamIdoing (talk) 03:46, 18 June 2013 (UTC)

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)

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. --Cyclopia^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. --Jayron32 02:54, 20 June 2013 (UTC)

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. Graham87 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. Graham87 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 m: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 logged like this and there will be 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. Graham87 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&^{(Je vous invite à me parler)} 02:23, 14 June 2013 (UTC)
  • Actually, that's a good point; that edit seems to be permanently gone. I've added an explanation about it to Wikipedia:Wikipedia's oldest articles. Graham87 02:59, 14 June 2013 (UTC)
• Support. 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)

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 ^{[dubious – discuss]} 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 Wikipedia: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. elektrikSHOOS (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? smileguy91^talk 03:35, 22 June 2013 (UTC)

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)

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. Steven Walling (WMF) • 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. Steven Walling (WMF) • talk 02:09, 19 June 2013 (UTC)

And Wikipedia:Why_create_an_account? which is linked from quite a few places (including the templates you linked to). —TheDJ (talk • contribs) 13:02, 19 June 2013 (UTC)

Where I just did a bit of cleanup. —TheDJ (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 _Talk^Done 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. Steven Walling (WMF) • 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. Steven Walling (WMF) • 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. --Jayron32 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)
• @Anthony Appleyard: 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. @TheDJ: @Quiddity: 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? Steven Walling (WMF) • 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   Done Steven Walling (WMF) • 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. Steven Walling (WMF) • 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. Steven Walling (WMF) • 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)

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. Wikipedia: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)