Is there a wikiproject for archiving wepages? I think there should be one so it can be convenient for editors who have no idea how to archive pages, and for those who simply don't have the time.So that those who are always or most often available can archive it for the other editor. if this already exists, i'm sorry for bringing this up again. I checked WP:ARCHIVE, and WP:WEBCITE.

I'm not sure what name its under if it exists, but if it doesn't exist, i believe this would be helpful and would save alot of other editors time in moving onto other edits, while other editors who like to archive other sites would be able to help the other's workload and improving wikipedia even more.Lucia Black (talk) 02:25, 11 January 2014 (UTC)[reply]

Do you mean something like archiving a talk page? There's already a help page for this. I don't think there needs to be an entire Wikiproject devoted to archiving pages. -Well-rested^Talk 06:54, 11 January 2014 (UTC)[reply]

I don't think Lucia is talking about wikipedia pages, but rather things like source pages. VanIsaac_{WS Vex}^contribs 09:18, 11 January 2014 (UTC)[reply]

If Lucia is talking about archiving source pages, this may be of interest. Novusuna ^talk 09:38, 11 January 2014 (UTC)[reply]

I'm asking for help archiving sources that we used in articles so that readers don't have any doubt. however, i thought if a group of editors wanted to dedicate to it, then maybe this will streamline the archiving page simply by request. i will inform those editors on the current proposal, if their active.Lucia Black (talk) 09:54, 11 January 2014 (UTC)[reply]

@Lucia Black: please see Wikipedia:Using the Wayback Machine and Template:Wayback's documentation. I hope this will be helpful. --Rezonansowy (talk • contribs) 13:31, 12 January 2014 (UTC)[reply]

@Rezonansowy: this proposal is to create wikiproject is intended to those who simply don't have the time to do or are too forgetfull to do it, and other members who are willing to archive pages, will help out. Similar to a place to request for grammar help.Lucia Black (talk) 23:59, 12 January 2014 (UTC)[reply]

I think Lucia is some how right in his sense. Archiving sources may be helpfull to readers Nechlison (talk) 18:02, 12 January 2014 (UTC)[reply]

A definite improvement would be a BACK TO TOP option at the bottom of your pages ! Thanks — Preceding unsigned comment added by 66.27.220.198 (talk • contribs)

@66.27.220.198: Here you are - User:Numbermaniac/goToTop.js. --Rezonansowy (talk • contribs) 13:26, 12 January 2014 (UTC)[reply]

I tried this and it works well. Thanks, Rezonansowy. GenQuest ^{"Talk to Me"} 01:16, 14 January 2014 (UTC)[reply]

As an alternate, non-Javascript solution, there is also the "home" key on the keyboard. Novusuna ^talk 20:34, 12 January 2014 (UTC)[reply]

Or, for Mac users, ⌘ Cmd and ↑. Killiondude (talk) 00:21, 14 January 2014 (UTC)[reply]

Hi all,

I'm organising Wikimania 2014 in London. It'll be the largest Wikimania ever by quite some way (we're expecting 4000+), and an excellent opportunity for outreach and awareness raising about the projects. Recognising London as increasingly a hub for technology, I'm especially keen to recruit new technical contributors. I've tried to do that by picking conference themes that would be enticing to people interested in tech, and I'll be heavily publicising in those circles; if you can help me improve The Wikimania London Wiki in any way, especially with suggesting interesting technical projects people could get involved with and generally improving the way that the technical details are described, that would be really helpful. Particularly, take a look at the 5 "theme" articles on the front page, and please, be bold! This is a great opportunity to recruit some really skilled new people, who I think have never really considered Wikimedia as an open source project before.

Any questions or if you're interested in helping out in some other way, please feel free to get in touch with me directly. EdSaperia (talk) 23:45, 13 January 2014 (UTC)[reply]

Everybody should have the option of setting up their own Wikipedia account in such a way that every time anyone writes a proposal, they get notified. It should also be possible to be possible to make it so that you get notified when ever an article gets created but since there are about 4,000,000 articles, that might be too often so maybe they should only be notified of the ones that get created while using Wikipedia. In addition to that, it should be possible to make it so that you get notified every time somebody edits a talk page of a specific WikiProject so that you can respond to the suggestions and edit many articles really fast to make them better.

Some people are really good at editing all sorts of Wikipedia articles. Just below the link Random article should be another link Random stub. In addition to that, everybody should be able to set up their own account in such a way that when ever anyone adds a stub tag to any article, they get notified by the notification box at the top of the Wikipedia web page they're on. There should also be a method of picking a random article from a specific category or a specific WikiProject so that people who are good at editing articles in that WikiProject can keep on editing more and more articles in that category to make them better. There should also be a method of picking a random uncategorized article so that people will be able to keep on going to random uncategorized articles to add categories to make other people who are good at editing articles in that category find that article more easily. It should even be possible to set up your own account in such a way to get notified every time anything happens in any subset of the subset of the following list that's mathematically possible: An edit to certian labs of community portal, an edit to the Teahouse, an edit to an article or talk page in a specific category or Wikiproject, creation of a new section for any of the above except for an article itself, creation of an article, requesting an article, and creating a previously requested article, creation of one's own requested article, closing of a discussion, an edit to one's own created article or its talk page, and creation of a red link in an article in hope of an article for that link getting created. For anybody with a Wikipedia account, every time any section with a part that was signed by them gets edited, they should automatically get notified. It's such a hassle for me to keep on going back and looking at all the talk pages I ever edited that I never got an answer to and be unable to remember all of them making it so that some answers I got, I might never go back and see because I forgot about that article entirely. Blackbombchu (talk) 04:20, 7 January 2014 (UTC)[reply]

You can do pretty much do all this now. Use the "Watchlist". View "Recent Changes" (on the left menu panel) of any page. Type in any combination of letters in the search bar and hit enter for a list of random articles. Review "Categories" for maintenance needs. Join a "Projects" page. These are all in place now. GenQuest ^{"Talk to Me"} 05:41, 7 January 2014 (UTC)[reply]

Is it also possible to watch just one section of a talk page? Blackbombchu (talk) 20:02, 7 January 2014 (UTC)[reply]

No, it's not; that is a perenially-requested feature, but it has been deemed to technically difficult to implement, given how sections work. Writ Keeper ⚇♔ 20:05, 7 January 2014 (UTC)[reply]

@Blackbombchu: You can get part of the way there by setting your Preferences to Group changes by page in recent changes and watchlist and Expand watchlist to show all changes, not just the most recent. You can then see the section header for each edit in your watchlist for pages such as this one, and only come visit when a section you're interested in is added/updated. Hope this helps! GoingBatty (talk) 21:30, 7 January 2014 (UTC)[reply]

It looks like it somebody else has already done me the favour of setting up my account in that way because I actually got a notification about an edit to this section of Wikipedia:Village pump (proposals). Blackbombchu (talk) 21:40, 7 January 2014 (UTC)[reply]

Not really; you got notified about that because GoingBatty explicitly pinged you, which caused the notification. Not all edits to this section will notify you; only ones which include a link to your userpage (as the template {{ping|Blackbombchu}} that GoingBatty used does) will. Observe: my earlier reply did not generate a notification, but now that I include the ping thusly: @Blackbombchu:, you will get a notification for this. Writ Keeper ⚇♔ 21:46, 7 January 2014 (UTC)[reply]

A think it would be really great if Wikipedia also made a change where every time a link from a Wikipedia article to an article somebody's watching gets created, they get notified because the article that the link was created from could be a stub and that would bring a lot of attention to the stub, helping it get improved really fast. In fact, which people had the stub brought to their attention would probably further improve the stub because somebody knowledgeable about the topic of an article is more likely to be knowledgable about an article similar to it than an article on a totally separate topic and articles tend to link other articles that are similar to themselves. Blackbombchu (talk) 03:29, 8 January 2014 (UTC)[reply]

This has also already been done. Check the notifications section of your Preferences, you should find an option to be notified of page links. Novusuna ^talk 03:43, 8 January 2014 (UTC)[reply]

The "page-linked" Notification only works for pages that you are the original creator of. There's no way to add pages to the list of pages it will ping you about (although there's a request to be able to remove items from the list, somehow). However, see below... –Quiddity (talk) 19:11, 14 January 2014 (UTC)[reply]

I was watching the page Wikipedia:Articles for deletion/Google Feedback and an extra bullet has been added to the bottom of that page since the last time I looked at it and I still didn't get a notification of that edit. Blackbombchu (talk) 18:13, 11 January 2014 (UTC)[reply]

• You might also want to WP:transclude {{Centralized discussion}} onto your user or user talk page, where you can keep an eye on important discussions. That template is also transcluded at the top of this page. Wbm1058 (talk) 18:19, 7 January 2014 (UTC)[reply]
• Also you might want to subscribe to the Wikipedia:Feedback request service or transclude Wikipedia:Dashboard/Requests for comment. And, are you aware that you can watch pages? Alas, there is way more happening here than any one human can keep track of, so you need to pick and choose what you want to pay attention to. I tend to gravitate to things I find that aren't getting much attention from other editors, alas, there's a lot of that. Wbm1058 (talk) 18:42, 7 January 2014 (UTC)[reply]

I don't know how to subscribe on Wikipedia. Is it possible to subscribe in such a way that a get notified by the message symbol at the top of any Wikipedia page instead of by email? Blackbombchu (talk) 20:02, 7 January 2014 (UTC)[reply]

I encourage you to read the information at Wikipedia:Feedback request service. The idea of this service is to draw in editors for comments in discussions of more specific article-related issues. You can pick and choose which area(s) you want to get notifications in, and how many notices you want to get. A robot randomly selects editors who opted into a topic and posts messages like the following on their talk pages.

Please comment on Talk:Genocide of indigenous peoples

Greetings! You have been randomly selected to receive an invitation to participate in the request for comment on Talk:Genocide of indigenous peoples. Should you wish to respond to the invitation, your contribution to this discussion will be very much appreciated! If in doubt, please see suggestions for responding. If you do not wish to receive these types of notices, please remove your name from Wikipedia:Feedback request service. — RFC bot (talk)

Of course, anytime a message is posted to your talk page you get the notification at the top of any Wikipedia page you're on at the time. Note that I just randomly picked an example from archives. Sorry it happened to be such a depressing topic. I wish that kind of stuff never happened, but it does. Wbm1058 (talk) 20:57, 7 January 2014 (UTC)[reply]

@Blackbombchu: The WP:Flow project aims to implement or solve many of the issues you raise - from "subscribing" to specific threads (eg just this thread, rather than the entire Village Pump page), to improving a variety of the other workflows we all use. It's starting off with a basic user-to-user discussion system (which has an initial implementation of automatic-Notifications any time you get replied to), and will be building in complexity over the coming months.

There's some extreme complexity (and varying personal preferences) for how it can/should integrate with watchlists. "Multiple watchlists" have been widely requested for years (see bugzilla:5875 and bugzilla:33888 which link to everything related). Building Flow, Echo (the current/new Notifications system), and Watchlists, so that they harmonize with each other, and work well for all the different types of editor, is going to take a while (slow & steady wins the race), and much experimentation and user-feedback, over the coming months.

However, for random uncategorized pages, see Special:UncategorizedPages. See also the specific WikiProject task pages that you're interested in, via User:Svick/WikiProject cleanup listing, eg Veterinary medicine.

HTH. Quiddity (WMF) (talk) 19:13, 14 January 2014 (UTC)[reply]

The Wikipedia Library has grown from a collection of donations to paywalled sources into a broad open research portal for our community. New partnerships have been formed, new pilot programs started, new connections made with our library experts and likeminded institutions. We have tried to bring people together in a new sense of purpose and community about the importance of facilitating research in an open and collaborative way. Here's what we've done so far:

• Increased access to sources: 1500 editors signed up for 3700 free accounts, individually worth over $500,000, with usage increases of those references between 400-600%
• Deep networking: Built relationships with Credo, HighBeam, Questia, JSTOR, Cochrane, LexisNexis, EBSCO, New York Times, and OCLC
• New pilot projects: Started the Wikipedia Visiting Scholar project to empower university-affiliated Wikipedia researchers
• Developed community: Created portal connecting 250 newsletter recipients, 30 library members, 3 volunteer coordinators, and 2 part-time contractors
• Tech scoped: Spec'd out a reference tool for linking to full-text sources and established a basis for OAuth integration
• Broad outreach: Wrote a feature article for Library Journal's The Digital Shift; presenting at the American Library Association annual meeting

We've proposed a 6 month renewal request to continue and deepen this work and would appreciate your comments, concerns, thoughts, questions, or endorsements.

Cheers, Jake Ocaasi ^{t | c} 12:32, 16 January 2014 (UTC)[reply]

Want to gain free access to a top research university's library so you can improve Wikipedia articles? Apply to be a Wikipedia Visiting Scholar!. George Mason University's position is now open: Application. Cheers! Ocaasi ^{t | c} 15:53, 18 January 2014 (UTC)[reply]

While looking at trending articles on the English Wikipedia I noticed that the island of Java tops the list. This isn't the first time I've noticed something like this. You can see the list here. At over 8.5 million views, it far exceeds most articles. If you look down the list to #4, you see that it's Hypertext Transfer Protocol (HTTP).

Is it possible that millions of people are being directed to the wrong article and that what they are really looking for is Java (programming language), which is why it's not surprising that HTTP is #4 on the list.

Although the island of Java has a large population, it is not an English speaking country. Regarding potential English speaking tourists searching for this location, the Java article only mentions the word tourism once so I'm not sure how substantial that industry is. But that still wouldn't explain why that one article would far outweigh any other potential tourist destination with an article on the English Wikipedia. Where are the searches for Java originating from?

Please offer your feedback. Thanks. -- Somedifferentstuff (talk) 17:49, 18 January 2014 (UTC)[reply]

• Procedural close: Wrong venue. Jackmcbarn (talk) 17:54, 18 January 2014 (UTC)[reply]

The Talk Page at Java has ample evidence that Java as a term starts with the island and that everything else is derivative, and as a consequence hat notes/redirects et al should in fact acknowldge the stubject, not the geographically or terminologically challenged. satusuro 02:34, 19 January 2014 (UTC)[reply]

This is not the place to make your argument. There is currently a discussion taking place on the Java talkpage entitled, "Possible proposal to redirect people searching for Java." -- Somedifferentstuff (talk) 03:31, 19 January 2014 (UTC)[reply]

There's a proposal to roll out {{DYK topicon}}; which has also been nominated for deletion. The proposal is to recognize DYK-recognized content with a topicon, similar to how GA and FA class articles are currently recognized with a pictoral element on the article page. For the discussion, please see WT: Did you know -- 70.50.148.122 (talk) 14:29, 19 January 2014 (UTC)[reply]

Moved to Wikipedia talk:Did you know

I think we should develop a gadget to allow users to choose the reference format, like in Special:Cite. --Rezonansowy (talk • contribs) 12:50, 11 January 2014 (UTC)[reply]

That presumes we have a standard method of formatting references. Citation Style 1 templates are popular, but not pervasive. --  Gadget850 ^talk 15:28, 11 January 2014 (UTC)[reply]

Yes, quite unlikely to come about. A better use of time and resources, and of greater service to the readers, would be adding references, or cleaning them up. ~ J. Johnson (JJ) (talk) 21:32, 11 January 2014 (UTC)[reply]

Can someone else could comment? Cite format option would be very necessary, please post in this thread comments only about this. --Rezonansowy (talk • contribs) 13:26, 12 January 2014 (UTC)[reply]

This is unlikely to happen globally, because we have more than 1 reference format. CS1 is prevalent, but not exclusive. We could only format one of them, like CS1, but that's pretty much forcing users into either using it or readers won't be able to format. We would need to allow to format all styles, but that's impossible. Hand-written references, for example, cannot be "re-styled" autoamtically. —  HELLKNOWZ  ▎TALK 14:13, 12 January 2014 (UTC)[reply]

I see, but I mean only these generated by Template:Citation which can be easily done, I think. --Rezonansowy (talk • contribs) 14:36, 15 January 2014 (UTC)[reply]

I can't imagine how a template could read a global setting and then apply the formatting. --  Gadget850 ^talk 14:50, 15 January 2014 (UTC)[reply]

Yes. Reader-controlled formating only where it "can be easily done" seems to be a null set, perhaps even intrinsically contradictory. Unless Rezonansowy can otherwise enlighten us I would reiterate my initial comment: quite unlikely to come about. ~ J. Johnson (JJ) (talk) 22:06, 20 January 2014 (UTC)[reply]

I previously proposed this at the idea lab, but it has not received any feedback there, so I am bringing it here instead. I am proposing that everything that has either been closed (in the case of deletion discussions and requests for adminship) or archived (as in the case of ANI and other noticeboards, as well as all of the village pumps) be fully protected indefinitely, as there is no reason for anyone to edit them. Also, such discussions are occasionally a target of lots of trolling (e.g. WP:Articles for deletion/Brian Peppers and WP:Articles for deletion/Gay Nigger Association of America), so this would prevent this from happening. Jinkinson talk to me 02:06, 15 January 2014 (UTC)[reply]

Oppose Bots and AWBs fix stuff in archives sometimes, and once in a while a template is converted to subst-only. I don't see why semi-protection wouldn't work. Jackmcbarn (talk) 02:16, 15 January 2014 (UTC)[reply]

Don't see the need. Very rarely have I seen such a page edited when it shouldn't be and it's usually a mistake of venue that's easily corrected with a reversion and a friendly message. The pages just aren't siginficant targets for vandalism as they aren't read or of interest. Which leaves legitimate edits which too happen rarely but often enough (Deletion Review notices for AfDs, bot actions, fixes of closure errors) that protection would be an inconvenience. Individual pages which are heavy vandalism targets can be individually protected but I see no need for a blanket change.--JohnBlackburne^words_deeds 02:30, 15 January 2014 (UTC)[reply]

Oppose: It's not really necessary. Yes, people should not be editing those pages, but nothing problematic will happen if they do (but, in the vast majority of cases, it won't happen at all anyway). If there is a closed AFD and I add my opinion, and nobody notices and reverts it... what? It won't change what happened, the article will still be deleted. Cambalachero (talk) 02:31, 15 January 2014 (UTC)[reply]

I don't see the need for blanket protection, but I wonder if {{noindex}}ing all AFDs (as part of a closing template) would reduce the problem. Individual "attractive nuisances" could always be protected as needed. WhatamIdoing (talk) 20:24, 15 January 2014 (UTC)[reply]

AfD's are already noindexed because MediaWiki:Robots.txt blocks them. Jackmcbarn (talk) 20:34, 15 January 2014 (UTC)[reply]

• How many cases are there where this would have been of use? Looks like a solution without a real problem. Peridon (talk) 15:54, 19 January 2014 (UTC)[reply]
• There are many reasons to edit such pages. Incidentally, also user talk archives shouldn't be fully protected but stay open for image rename, template substitution, bypassing redirects before deletion/repurposing and username-change-to-remove-real-name type edits. All of these reasons apply to closed discussions as well. In general, any change from the default "anyone may edit any page" should have a specific reason. —Kusma (t·c) 16:02, 19 January 2014 (UTC)[reply]
• Oppose. Too much effort with little benefit. -- King of ♥ ♦ ♣ ♠ 01:10, 20 January 2014 (UTC)[reply]

Hi,
I understand that this might be hard to do/not desired, but I had the idea that if a user was inserting over a certain number of bytes of text--say, 50,000--that the edit would be treated as if it was to a page that had pending changes level 1 protection applied. I am proposing this because I find it hard to believe that there would be very many non-vandalism edits that fufill these criteria, and that it would be a good check on certain kinds of vandalism. Anybody else think this makes sense?
Thanks!
Cogito-Ergo-Sum (14) (talk) 17:49, 18 January 2014 (UTC)[reply]

That's currently not technically feasible. Jackmcbarn (talk) 17:53, 18 January 2014 (UTC)[reply]

Thanks! Sorry for wasting your time!Cogito-Ergo-Sum (14) (talk) 18:20, 18 January 2014 (UTC)[reply]

You could probably get an WP:Edit filter or tag that made a list of such edits, so that they could be checked by people who patrol Special:RecentChanges. That might be almost as good. WhatamIdoing (talk) 20:06, 21 January 2014 (UTC)[reply]

That way, people who specialize in a specific WikiProject will be able to find an article that's part of that WikiProject that they otherwise wouldn't have been able to find and either improve it or watch that article to notice when somebody writes on the talk page of that article and then from from the talk page, judge how to improve the article. The article Linear induction motor got so little attention that I'm the only person who ever wrote on its talk page and it probably would have gained alot more attention and become a better article faster if the WikiProject Engineering had given a list of all articles that are part of that project. Blackbombchu (talk) 03:28, 20 January 2014 (UTC)[reply]

See Category:WikiProject Engineering articles, and equivalent categories for other WikiProjects. bd2412 T 03:39, 20 January 2014 (UTC)[reply]

That's already done. The WikiProject Engineering tag on Talk:Linear induction motor was placed in 2012. It adds three categories for the WikiProject. Just click the category links at the bottom. PrimeHunter (talk) 03:44, 20 January 2014 (UTC)[reply]

You can also get the whole list at http://tools.wmflabs.org/enwp10/cgi-bin/list2.fcgi?run=yes&projecta=Medicine&limit=250&offset=1 (just change the name of the project). WhatamIdoing (talk) 20:10, 21 January 2014 (UTC)[reply]

I use the Android app and thought it would be nice to see a random page feature on it Thetiesthatbind (talk) 09:23, 21 January 2014 (UTC)[reply]

Please discuss at User:Gryllida/Handling new article submissions; I've placed the thing there, to evade archival bots. Thanks. --Gryllida 09:46, 21 January 2014 (UTC)[reply]

Hey folks. I recently stumbled across the fact that there are literally thousands of un-substituted {{unsigned}}-templates across many namespaces. I've been thinking about BRFA-ing for that, as I've always been interested in doing some mass bot work. Now, I realize that, given that it hasn't been done yet, it is probably not "extremely needed". I'm also aware that we're not supposed to worry about performance. But it certainly couldn't hurt, could it? What to you guys think? Cheers. ~ | twsx | ^talk_cont | ~ 12:36, 21 January 2014 (UTC)[reply]

• Anomie already has a subst bot... You could gain a consensus and just add it to the list of templates AnomieBOT is supposed to subst. Good luck! Technical 13 (talk) 12:59, 21 January 2014 (UTC)[reply]

Per Category:Wikipedia templates to be automatically substituted, it appears you could add {{substituted|auto=yes}} to Template:Unsigned to get AnomieBot to do the substituting. Looks like Template:Unsigned/doc already says the template should always be substituted. (Maybe someone should see which documentation pages contain {{subst only}}, and check that the associated templates have {{substituted}}.) GoingBatty (talk) 02:52, 22 January 2014 (UTC)[reply]

Are readers already aware of full protection on an article? We have "view source" and a protection lock icon/banner; visibility comes in mind. For indefinitely fully-protected articles, shall we mostly (if not always) use banner ("big") or a small lock (small top icon)? What about treating temporarily fully-protected articles? --George Ho (talk) 07:45, 17 January 2014 (UTC)[reply]

• It's not a maintenance issue, so a banner is not appropriate. There's already an edit notice, so there's really nothing else to do. Is there a specific problem you are having? VanIsaac_{WS Vex}^contribs 07:49, 17 January 2014 (UTC)[reply]

It's just.... going to find a page to copy-and-paste {{edit protected}}... how else can we immediately notify the editors without finding the template if we can't use big banner? --George Ho (talk) 08:05, 17 January 2014 (UTC)[reply]

• I don't understand why readers would need to be aware that an article is protected. What are you trying to achieve? Do you have some specific indefinitely protected articles in mind? - Pointillist (talk) 10:19, 17 January 2014 (UTC)[reply]

Perhaps you mean editors rather than "readers"? - Pointillist (talk) 21:44, 17 January 2014 (UTC)[reply]

• No offense, but it seems like an unnecessary waste. If they miss the lock and try to edit it, they can't. If they don't need to edit it, does it really make a difference? Supernerd11 (talk) 15:14, 17 January 2014 (UTC)[reply]

I realized that the way to edit is clicking "View Source" and then a button to request edit. Sounds about right? George Ho (talk) 20:28, 17 January 2014 (UTC)[reply]

• When the user clicks view source, there is a huge banner there George with very clear instructions and a big "request an edit" button. I suppose, it might be condusive to encourage editing by changing to color of that button to blue or green (to offset it a bit, the gray does kind of blend in for those with color blindness issues). The only other thing that I could think of to do, which would be a bit of work to create, is make a userscript/gadget that allows non-sysops to edit in the "view source" window, show preview, show changes, but instead of a save page button, it could be changed to request edit. The script would then create a very accurate "please change X to Y" style edit request and apply the request properly on the talk page. This is a script that I might be interested in trying to write if no-one beats me to it. I'll have to get back to you on that. Technical 13 (talk) 21:03, 17 January 2014 (UTC)[reply]

• Simple solution would be to leave a note at the "Page notice" link whenever a page has been protected. Then all editors would need to do is get into the habit of checking to see if it is still a red link, then reading the notice lft there. Ideally, this would then allow other editors & admins to determine if a page protection is still appropriate. -- llywrch (talk) 20:46, 23 January 2014 (UTC)[reply]

Please comment at Wikipedia talk:Article Feedback Tool/Version 5#RfC: Should article feedback be restricted to articles?. Jackmcbarn (talk) 20:30, 24 January 2014 (UTC)[reply]

There should be some simple way one can count/track/manage number of articles a person reads (over a period of time). This can be done with Wikipedia App with great ease. How nice if Wikipedia app could be used as a personal Wikipedia diary! To achieve this QR code can do the trick. Consider there is a link saying on every article - "Show QR Code for this article" which will show a Dialog box with QR code for link. Mobile devices and apps are ubiquitous these days, so one can take snap of qr code while the are reading the article and get the link saved in their personal library as articles visited/articles read, arrange them in user created folders, download them for later reading. swarnkar rajesh kumar r

I'll bite. Why not just bookmark the URL? The only use-case I see for this is someone with a mobile device handy who is reading a paper copy of the article. Hardly a core demographic. That said, if there is a real use-case, the permalinked version ID is already generated in the printfooter, so morphing that to make a QR code shouldn't be too tough. There are MIT-licensed javascript implementations available, e.g. this on github, which generate the QR code in the browser. LeadSongDog come howl! 22:26, 17 January 2014 (UTC)[reply]

Agreed. Thanks for the input. swarnkar rajesh kumar r

Another possible use would be if someone starts reading an article on a PC, has to go somewhere, and wants to open the page on a mobile to finish with it. —rybec 12:27, 25 January 2014 (UTC)[reply]

Instead of the current adrenaline-prompting message --

Edit conflict!!!

-- how about if we change to something less martial. Here are some suggestions:

Too many cooks spoil the broth!

There seems to a minor disagreement here

No doubt they didn't mean it...

Oh! Bad luck!

Remember: Two heads are better than one.

Rejoice! Another editor is doing you the compliment of choosing to help Wikipedia in the same place you are!

EEng (talk) 19:40, 20 January 2014 (UTC)[reply]

Tough crowd, I guess. EEng (talk) 04:46, 22 January 2014 (UTC)[reply]

I think that the current version is better. עוד מישהו Od Mishehu 06:23, 28 January 2014 (UTC)[reply]

Does anyone know of an existing template, where if you give in a particular time and date, and the template would automatically converts that to the timezone set in Special:Preferences (for logged-in users) or from the reader's IP region (for IPs)? For example (I'm editing from Sri Lanka): The hypothetical template {{Template|2014|01|26|17|30|PST}} would show: 26 January 2014 17:30 PST (27 January 2014 06:30 Sri Lanka Time). Further, the dating format could also be made to fetch from the user's preferences.

Does anyone know if this exists? If not, can we get a few template experts and work on creating this? I'm strongly towards expanding an existing template ({{Time}}?) rather than creating yet another one... Rehman 04:58, 26 January 2014 (UTC)[reply]

Try the following that I got from another user, just adjust hour differential to Sri Lanka (mine is -6):

<!--beginclock--><center> <div style="padding:10px; text-align: justify;"> <div style="float: left; border:solid #aaa 1px; margin: 1px;"> {| cellspacing="0" style="width: 238px; background: #333;" | style="width: 45px; height: 45px; background: white; text-align: center; font-size: {{{5|{{{id-s|14}}}}}}pt; color: {{{id-fc|black}}};" |[[Image:Crystal Clear app clock.svg|42px]] | style="font-size: {{{info-s|8}}}pt; padding: 4pt; line-height: 1.25em; color: {{{info-fc|white}}};" | It is approximately '''{{#time:g:i A|{{CURRENTHOUR}}:{{ {{{|safesubst:}}}#time:i}} <includeonly>{{{1}}}</includeonly><noinclude>-6</noinclude> hours}}''' where this user lives. |}</div> <noinclude><br> <!--endclock--><br></center>

Goodluck! GenQuest ^{"Talk to Me"} 06:40, 26 January 2014 (UTC)[reply]

Hi folks! For the past 18 months we've been building an interactive guided tour for new editors called The Wikipedia Adventure (TWA). We just finished our beta test and had some very nice results, both quantitatively and qualitatively.

One issue has come up and I'd like some guidance. The TWA game takes place in an editor's userspace, at user and user talk subpages. This allows a modicum of verisimilitude--it looks and feels like Wikipedia--without actually burdening articles with test edits and vandalism. So that's good.

The challenge is that these new userspace pages are still patrolled by some hardworking editors, and they have asked if it would be possible to mark those pages as autopatrolled.

These pages are generally created using a mediawiki guided tour that pushes an edit through the mediawiki API. In other words, it's the editor themselves making an edit, but the TWA guided tours engine actually puts it on Wikipedia (it shows up in the page history as though the editor made it themselves, but is edit-summary tagged as part of TWA).

After these pages are created, the editor is asked to interact with and improve them, as part of the learning process. So, here's my question: would it be appropriate to mark only those userpages created automatically through TWA as autopatrolled, and if so, is there a way to do that using the API:EDIT?

• The Wikipedia Adventure
• Phase 1 impact metrics and results
• Mission 1 (the mediawiki code including the API)

Cheers! Ocaasi ^{t | c} 14:13, 26 January 2014 (UTC)[reply]

Interesting question. I'm not sure that can be done through the API because then anyone could edit through the API and have all their edits marked as patrolled and it would be a hole in the system. I would think the better possibility would be for an edit filter (the one that tags them as TWA edits in the first place might be good, if there is one as your introduction to the question implies to me) to mark those edits as patrolled. Technical 13 (talk) 16:21, 26 January 2014 (UTC)[reply]

Hey Technical 13, thanks for the feedback. The code lives in the mediawiki namespace and only admins can access it. Not sure if that leaves a more secure API option. I like your edit filter idea, too. I'd want to autopatroll any new page created with the edit summary:

New Message (simulated automatically as part of The Wikipedia Adventure)

Any idea how I go about this? Cheers, Ocaasi ^{t | c} 17:01, 27 January 2014 (UTC)[reply]

• Where the code for this tour lives would have no bearing on the ability for someone to maliciously use the API in other ways. We can ping legoktm as I know he is an edit filter creator/maintainer, and I'll look into the docs and see what might be needed to pull this off (it may require a patch to the edit filter extension to make it work) but I see this as likely the best option here. Technical 13 (talk) 18:09, 27 January 2014 (UTC)[reply]

Dear Colleagues English Wikipedia, I am a representative Ukrainian Wikipedia. I invite you to join the strike UkrViki (as did Georgian colleagues) in connection with the recent developments in Ukraine.Jphwra (talk) 09:09, 27 January 2014 (UTC)[reply]

I support adding a black banner to the top. --NaBUru38 (talk) 18:57, 28 January 2014 (UTC)[reply]

This says that the 721-VII law has been repealed. The New York Times [1] and NBC News [2] reported about it without mentioning the specific law. —rybec 21:21, 28 January 2014 (UTC)[reply]

I don't fully know the Wikipedia code and I want to be able to make sure what I'm asking at the Teahouse is exactly the way I want even if the question includes complex stuff like a hyperlink to a section of another Wikipedia page or a mathematical expression. Blackbombchu (talk) 01:18, 29 January 2014 (UTC)[reply]

That's a good idea; it should be doable. Writ Keeper ⚇♔ 01:38, 29 January 2014 (UTC)[reply]

Hi folks, I know we have lots of neat userscripts in our community but they are somewhat foreign for new editors to use. I built one that has a 1-click install feature using mw:Guided tours and the mw:API:EDIT. It requires a script in the English Wikipedia mediawiki namespace which only admins can access. I could make it pretty easy to adapt this method for any/all userscripts. Would that be appropriate? Would there be interest in setting up such a page?

Example: Wikipedia:FindDPLA

Thoughts? Ocaasi ^{t | c} 12:21, 29 January 2014 (UTC)[reply]

This might be problematic from a security standpoint. Currently, one has to go through a mildly thought-requiring process, together with receiving a big red warning about what malicious code might do. If something allows users to just start turning on and off loads of scripts (that haven't been checked by admins prior to gadgetizing), well... --Yair rand (talk) 13:37, 29 January 2014 (UTC)[reply]

Because the scripts are in mediawiki namespace, an admin would have to approve each one, so there'd be oversight. Ocaasi ^{t | c} 14:56, 29 January 2014 (UTC)[reply]

• How does your script differ from Equazcion's User:Equazcion/ScriptInstaller script? Technical 13 (talk) 14:46, 29 January 2014 (UTC)[reply]

  Well, for one, it doesn't require installing a userscript to work :) !! That's kinda the whole point, avoiding people having to copy and paste code places they don't understand. Ocaasi ^{t | c} 14:56, 29 January 2014 (UTC)[reply]

• That doesn't really explain how it technically differs. If Equazcion's script was turned into an on by default gadget, it also wouldn't require installing a userscript to work. So, I ask again, how does it technically differ as to what the end result of what it does goes? Technical 13 (talk) 15:45, 29 January 2014 (UTC)[reply]

On a related point, I'd like a one-click link to change prefs. Then you could say, "I think you've encountered that bug with 'Near this page' Beta feature. Click here to turn it off and see if that helps" instead of saying, go to prefs, switch tabs, find this item, tick it, don't forget to save.... WhatamIdoing (talk) 17:11, 29 January 2014 (UTC)[reply]

Good work, Ocaasi. There are lots of security issues and other details to sort out, but I feel like wikipedia needs a lot more '1-click" options. The "Add this line to your css/js file" method just isn't realistic for our userbase. --HectorMoffet (talk) 20:59, 30 January 2014 (UTC)[reply]

You are invited to join the discussion at Wikipedia talk:Changing username #Username requests from users who have RfA page(s), etc.. -- Trevj (talk · contribs) 13:38, 30 January 2014 (UTC)[reply]

I propose that a new very minor permission be created, either separately or as part of one of the existing permissions, to allow experienced and trusted editors to delete and undelete their own userpage and subpages only. It would involve about the same level of trust as given to users with autopatrolled rights, and could possibly be included as part of autopatrolled rights. I would expect there to be a minimum thrsehold, perhaps requiring 1,000 edits, but I'm open to suggestions for a minimum limit.

This permission would also help reduce the workload of administrators, albeit miniscually, so that editors would not have to request deletion through speedy criteria WP:U1, although I've no way of finding out how many U1 requests are made in any timeframe. As with U1 currently, I wouldn't envisage it being extended to user talkpages (unless the user was the only contributor to the talkpage) and obviously blocked userpages would not be deletable in this way. Admins would still be able to undelete such pages if necessary, and obviously the permission could be withdrawn for bad behaviour. Note also that I'm not proposing getting rid of speedy criteria U1. Green Giant (talk) 14:49, 26 January 2014 (UTC)[reply]

A snag is that this would provide an illicit means of deletion. You could move a page to your userspace and then delete it. I suspect this could escape scrutiny. The remaining redirect would likely get speedy-deleted as WP:CSD#G8 or WP:CSD#R2. Perhaps there could be technical ways of blocking such deletions. Thincat (talk) 15:20, 26 January 2014 (UTC)[reply]

U1s are not a significant part of admin workload. —Kusma (t·c) 15:25, 26 January 2014 (UTC)[reply]

• Thincat, I had considered that and that's why it would only be granted in the same way as the other permissions are. I think it could be coded in such a way that deleting pages from cross-namespace moves would still need U1.
• Kusma, I suspected that U1 isn't a major group of requests but it is a trivial task that doesn't really need two people to perform it i.e. a requesting editor and an admin. It occurred to me recently when I wanted to delete one of my subpages and thought it would be so much simpler if I could do it myself in two clicks i.e. select a tab and click OK. Instead I had to click the CSD tab, click on U1, click on Submit Query and then wait for an admin to perform the task. I think the admins have more important tasks than this.

• I've never waited more than a few minutes for a U1 to be granted for me. I suppose there could be an adminbot to delete U1's if there were no moves involved. Honestly though, I believe this is a solution in search of a problem. Technical 13 (talk) 23:59, 26 January 2014 (UTC)[reply]

• Technical 13, to be honest, the speed of the response is not the problem. Everyones experience is going to be different, and personally I've had some responses for U1 within minutes and other times it's taken a couple of hours. However the main reason for proposing this was that it doesn't make sense to have two people to carry out such a trivial request. Even a bot wouldn't really make much difference, because it would just be simpler to be able to do it with two clicks. Green Giant (talk) 09:31, 27 January 2014 (UTC)[reply]

I'd support a bot to handle U1 cases which don't have moves in their history (trivial enough to check this), but I don't see the need to create this new user right (which would also require changing the software, since the current ine doesn't distinguish between deletiung user pages and other pages). עוד מישהו Od Mishehu 06:20, 28 January 2014 (UTC)[reply]

This is a brilliant solution. If you're the only contributor, you shouldn't have to ask permission to delete content you're done with. I appreciate the speedy response admins give, but it's plainly a waste of their time. Three lines of code ought to do it-- we don't need to waste a human mind on this. --HectorMoffet (talk)

• I agree with Kusma. I do a good many deletions from CAT:CSD, and U1s are not a significant part of the work. There is not enough benefit from this proposal to make software changes or creation of new user-rights worthwhile. JohnCD (talk) 11:41, 28 January 2014 (UTC)[reply]

• Seriously overdue software feature. As a general rule, trusted editors should have a 1-click path to deletion of their own sandboxes. It's a small matter, but U1 is a job for a script, not a human being, and definitely not worth the attention of an especially valuable human being like an admin. --HectorMoffet (talk) 11:49, 28 January 2014 (UTC)[reply]

• JohnCD, the major benefit would be to trusted editors, not to admins, because this feature would make it just that bit easier to start an article in the userspace and be able to delete it when necessary, e.g. the article was moved into article space or you've realised that perhaps there just aren't enough sources to make a worthwhile article. Right now, I generally avoid creating subpages, precisely because it is easier to delete a document on my desktop than it is to delete a subpage. If, as you say, U1's are not a significant portion of the admins work, having such a feature would encourage more editors to work on articles in userspace instead of doing it offline. As for a bot, Od Mishehu, it is not much different to having an admin do the deletion, because you would still need somebody to operate the bot; as HectorMoffet says, it is something a script could do. Ultimately it would help the project because we already have trust-dependent permissions like filemovers, reviewers, autoreviewers and rollbackers, and having this small but useful feature would let editors feel that they are trusted to delete their own userpages and subpages. Green Giant (talk) 12:44, 28 January 2014 (UTC)[reply]

A bot could run completely automated and would be no work beyond writing it in the first place, which would probably be far less work than proposing and implementing a software change. I think the issue Thincat mentioned would be a major impediment, if not a complete blocker, to adding support for this in the MediaWiki software. Mr.Z-man 15:20, 28 January 2014 (UTC)[reply]

I think a bot would have the same effect as a Mediawiki change, and would probably be alot easier to implement. The important thing is that we don't send a highly skilled human to manually execute a very simple "if-then" statement. --HectorMoffet (talk) 01:49, 29 January 2014 (UTC)[reply]

• Mr.Z-Man, the issue of moved articles is easily dealt with by checking the move log and by the fact that most articles are on someone's watchlist. Although I would prefer a simple script, I'd accept a bot too. Green Giant (talk) 03:21, 30 January 2014 (UTC)[reply]

Checking the move log will not always give you the correct result. Say Article is moved to User:Example/A, which is then moved to User:Example/B, then User:Example/A is re-purposed for something else. Just checking the move log would prevent you from deleting User:Example/A, which should be allowed, but might allow deleting User:Example/B (because in the move log, it was just a move from one subpage to another within the same userspace), which shouldn't be allowed. To really be foolproof without being overly conservative, it would have to scan through the history and potentially follow the move log across multiple pages, which is probably too inefficient to build into the software. Mr.Z-man 04:12, 30 January 2014 (UTC)[reply]

• Scanning the history is something done by several tools at the moment, such as the edit counters, the contribution checker and the "DYKChecker". Certainly it would take time to check a history with hundreds of edits but articles that have been moved recently to user space would still indicate in the history that a cross-namespace move had been done. Malicious users would probably try to delete a moved article almost immediately, so how much scanning would be needed? It wouldn't be difficult to code the script or bot to refuse to delete a recently moved cross-namspace article. It wouldn't be long before other users notice the move in their watchlist and raise the issue. The malicious page moves of the past are much more difficult to do these days, when high-risk articles have pagemove protection and numerous watchers. Bear in mind that this feature wouldn't be automatically available to everyone, just trusted editors via WP:PERM, a process that has resulted in 3,000 autopatrollers, 6,000 reviewers, and 5,000 rollbackers, although obviously some editors have multiple permissions. It would take a really dedicated vandal to make hundreds of good edits including significant userpage edits, just so they could get any of these permissions and then cause havoc. The vast majority of vandals simply don't have that kind of patience. Anyone misusing the privilege could easily have it removed and damage can always be repaired, because the deletion permission would not mean that admins couldn't undelete something if necessary. Green Giant (talk) 06:14, 30 January 2014 (UTC)[reply]

Yes, and all of those tools are separate software, like a bot. I didn't say it was impossible, just not feasible to do in MediaWiki where performance is more critical. You keep mentioning a "script", but I'm not really sure what you mean by that. If you mean something the user uses in their browser like Twinkle or Popups, that would require a change to the MediaWiki software to support it and "close enough" isn't good enough for a feature in the core software. Dedicated vandals and sockpuppeteers have managed to get adminship a couple times in the past, so if we add a new, much easier way to get a limited subset of admin tools, with a known security hole that would allow them to delete almost anything, you can bet some people would start working right away. You mention another thing that is potentially problematic, which is that any mistakes or misuse would require an admin to undo. This would actually be a fairly significant departure from how things have generally worked, which is that any action can be easily undone by any user with the same level of permissions. Of course, giving users the ability to undelete content in their userspace could lead to even more problems, as it would allow them to do history merges, which can be very tedious to undo. Mr.Z-man 15:35, 30 January 2014 (UTC)[reply]

• Had Sublimeharmony (talk · contribs) had this permission, I might not have noticed that there was something unusual about User:Sublimeharmony/sandbox11. —rybec 07:27, 30 January 2014 (UTC)[reply]

• How would Sublimeharmony have gained this permission, because it wouldn't have come automatically with a new account? That group of puppets is a good example of malicious editing, but look at their method of operating. The sandbox was in an account with just a few hundred edits. Requesting the proposed permission would have mean't exposing their activities because an admin would definitely have checked their contribution history and noticed that they had edited almost exclusively in the userspace. The vast majority of the other accounts only made sure that they got autoconfirmed status and very few of them made more than a hundred edits. Would it have helped them if they had had the proposed permission, when their entire work seems to have depended on having copies of their articles stored in the history of Sublimeharmony's sandbox separated by blankings? Hypothetically, Sublimeharmony could have deleted the sandbox loads of times, but what good would that have done for their cause because they needed to have the code ready to copy and modify? There is no reason that we couldn't have a flag being raised if a user deletes and undeletes a page several times, alerting admins to this activity. Green Giant (talk) 10:11, 30 January 2014 (UTC)[reply]

So you envisage that this permission wouldn't be granted by the software, like (or as part of) autoconfirmed status, but instead an editor would have to request it, after which an administrator would review the account's history, and a few hundred edits wouldn't be enough to justify having it? It might take more effort to do such a review than to handle several deletion requests. Also, what if this were more like WP:G7? Then one could delete pages in one's own user-space--or anywhere--so long as no one else contributed to them. That seems less questionable than deleting others' writing that happens to be in one's user-space. —rybec 21:49, 30 January 2014 (UTC)[reply]

Oh no, definitely not granted by the software. It would be approved by an admin in the same way as the other trust-based permissions on WP:PERM. For example, autopatrolled requires 50 articles to have been created by the user before being given that permission, whilst template editor is even more stringent, generally requiring users to have been registered at least 1 year, made at least 1,000 edits including 150 to templates, no behaviour blocks or 3RR for the previous 6 months. I was thinking along similar lines. As for the G7 suggestion, I would be equally supportive of that, but I was hestitant about mentioning that because it extends to pretty much anything a user might have created. Green Giant (talk) 15:57, 31 January 2014 (UTC)[reply]

There are, on occasion, instances where a U1 deletion request might not be granted by the reviewing admin; for example, a user subpage that contains a widely-transcluded message or userbox, a user's talkpage (though I think I'm right in assuming that this is treated as a separate namespace, and could therefore be excluded from this proposal), or a page which is being used as evidence in some sort of investigation. U1 deletions are a privilege, not a right (remember that userspace still technically belongs to the community), and so having an admin cast an eye over them before removing them is only appropriate. Speaking as someone who does a fair number of these deletions, I can honestly say that the work involved is usually minimal; this solution isn't going to suddenly free up hours of admin time. Besides, they're about the only deletions we ever actually get thanked for... Yunshui 雲‍水 15:56, 30 January 2014 (UTC)[reply]

• Good points Yunshui, that would have to be added as a check in any bot written (as this is the way this seems to be leaning). There would have to be no transclusions or protections on the page (I'm assuming, of course, if the page was evidence in an investigation that it would be protected in some way, perhaps cascading protection from the investigation?). I think the proposal is less about freeing up admin time (as valuable as that is) and more about expediting the process to be able to "re-use" sandboxes. To that I say, subpages are cheap, make a new one for each draft (shameless self promo: there are even templates that you can use to keep track of them and make the process easier like {{User:Technical 13/SandBox/DraftHeader}} (which is almost ready to move into template space for all to use)). Technical 13 (talk) 16:49, 30 January 2014 (UTC)[reply]

Y Shamelessness noted. Template added to List Of Things To Try Out. As for cheapness of subpages, very true, but pretty much everything here is done on the cheap → volunteers for editing, sainted volunteers for janitorial work, bots for tedious edits, begging bowls regularly sent out by the WMF... Green Giant (talk) 15:57, 31 January 2014 (UTC)[reply]

• Indeed the U1 cases are among the easiest to handle. The admin time savings would be negligible. Another permission for hat collectors would just create more red tape and complexity, not lessen administrative burdens. We could unbundle and grant the entire delete/undelete machinery to trusted users who could then process deletions for others, not just limited to one namespace or their own user area. Just a part of admin's mop, but mainly without protection and block tools. jni ^(delete)_{...just not interested} 20:35, 30 January 2014 (UTC)[reply]

• Yunshui, I agree that examples such as widely transcluded templates and user talkpages shouldn't come under this proposal. I'm all for admins casting their eyes about the place, which is why I think it should be granted by admins in a similar way to autopatrolled and rollbacker. Jni, I have been thinking about suggesting that admins could have helpers somewhat like the bureaucrats have their clerks for account renaming. As for red tape and complexity, I don't think the project will ever become simpler; indeed I foresee a great expansion in the future when the noble knight Sir Jimbo, returns from his holy quest, to fight the dragons of ignorance and the ogres of vandalism. :) Green Giant (talk) 15:57, 31 January 2014 (UTC)[reply]

How about disabling the link denoting currently selected list size on Special:Contributions? Currently, newest (ordering) and newer 100 (pagination) are disabled depending on the currently selected options and position within the contributions list, for example; disabling the currently selected list size would be like a cherry on top.

Hope it makes sense. Thoughts? — Dsimic (talk | contribs) 00:29, 31 January 2014 (UTC)[reply]

Any thoughts? — Dsimic (talk | contribs) 02:32, 3 February 2014 (UTC)[reply]

Given that only logged-in users can create articles in the article namespace, I don't see exactly why we allow IP addresses to create any page in the Talk: namespace they want, and I think that it would be more consistent if we only allowed logged-in users to create either articles or talk pages. Jinkinson talk to me 16:57, 30 January 2014 (UTC)[reply]

A solution looking for a problem IMO. Is there a issue with IPs mass creating talk pages without a article page? KonveyorBelt 17:10, 30 January 2014 (UTC)[reply]

• This limit would prevent anons from requesting edits on talk pages if the talk page didn't exist. Against the spirit of the 5 pillars... Technical 13 (talk) 17:13, 30 January 2014 (UTC)[reply]
• I can see the point, and we do get occasional flurries of fakearticles posted in talk by IPs. I don't think it's enough of a problem to require blocking the space for IPs, however. Peridon (talk) 17:12, 3 February 2014 (UTC)[reply]
• What would work, IMO, is preventing IPs from creating talk pages which neither have an asociated non-talk page, nor are subpages of existing talk pages. However, I don't think it's enough of a problem to bother with. עוד מישהו Od Mishehu 04:31, 6 February 2014 (UTC)[reply]

Talk pages without an associated article are already speedy deletable under WP:G8, so it's moot anyway. VanIsaac_{WS Vex}^contribs 06:48, 6 February 2014 (UTC)[reply]

Per the discussions on Henrik's talk page, it appears as though the page periodically going down is bugging people from many different wikis. Due to the fact that we are relying on one person to be our fail point, are people up to discuss moving the site's available data and start recording this information on Labs? I know that we would be leaving a lot of the material behind, but right now Henrik hasn't edited in over three months, so if he continues with this, the complaints will continue to land on deaf ears, and we risk losing more data. When or if he returns, we could move any remaining information over, and clean up any remaining lose ends. What do others think, as I would love to have something more stable than a page that is going down more than once a week. Kevin Rutherford (talk) 01:29, 3 February 2014 (UTC)[reply]

Support: Totally makes sense, and to me it's unclear why it hasn't been part of the Labs since day one. — Dsimic (talk | contribs) 02:31, 3 February 2014 (UTC)[reply]

The source code for it is freely available, so if anyone wants to set it up on labs, they're free to do so, regardless of the outcome of this proposal. Unless you're proposing the WMF do it, in which case, get in line. Note that there already is a tool on labs that already replicates most, if not all, of the functionality - https://tools.wmflabs.org/wikiviewstats/ Mr.Z-man 03:35, 3 February 2014 (UTC)[reply]

It appears to do that, and more. I guess we could just start unlinking the stats page on all of the major sites, but I am unsure of how to do it for the DYK template. Kevin Rutherford (talk) 15:13, 3 February 2014 (UTC)[reply]

Proposal : Make the timestamp portion of the signature link to a diff of the post (or a highly filtered subset of the history page for the relevant time period?). This would break down for posts which are updated retroactively, but would make linking to a particular post much easier. Gaijin42 (talk) 20:01, 3 February 2014 (UTC)[reply]

A proposal has been made to create a Live Feed to enhance the processing of Articles for Creation and Drafts. See Wikipedia:WikiProject Articles for creation/RfC to create a 'Special:NewDraftsFeed' system. Kudpung กุดผึ้ง (talk) 05:18, 4 February 2014 (UTC)[reply]

I noticed Wikispecies is already wikilinked in its sister Wikimedia project template, but Wikimedia Commons is not. I thought it was non-controversial to suggest this be fixed, but it was deemed I need consensus for it.

Examples on the RHS.

Looking at all the templates that use Sister (you need to manually change to only see Templates) I see it wikilinking the sister site is somewhat inconsistent in general.

Mark Hurd (talk) 01:53, 2 February 2014 (UTC)[reply]

• Support I see no reason why we shouldn't link to this. Also, I can make the edit if consensus is established, as I have the rights to edit that template. Kevin Rutherford (talk) 01:33, 3 February 2014 (UTC)[reply]
• Controversial? No way. Feel free to invoke WP:IAR. OhanaUnited^{Talk page} 04:44, 7 February 2014 (UTC)[reply]
• Support linking all of the sister projects' articles from the template. This is helpful to readers, who might be unfamiliar with them.
  WP:IAR seems irrelevant, as I'm not aware of any rule from which such links would deviate. —David Levy 05:01, 7 February 2014 (UTC)[reply]

• Just waiting for an admin to carry it out since that template is apparently so important it is cascade protected... — {{U|Technical 13}} ^{(t • e • c)} 05:07, 7 February 2014 (UTC)[reply]

• From a user interface standpoint, I don't know if I agree with the idea. The wikilink to information about commons will end up having greater prominence than the link to the commons search that is the primary purpose of the template. I've provided a sandboxed version to the side. Monty₈₄₅ 05:19, 7 February 2014 (UTC)[reply]

• Personally, the reason I initially closed the request saying there should be a consensus is because I think that it might be confusing to readers to have extra wikilinks not pertaining to the topic. I wouldn't mind if all of the "project" words were unlinked and instead the icons were the links. However, it seemed as it often does I was alone in thinking this based on the responses above, so I reactived the request. That's really all I've got to say about that. — {{U|Technical 13}} ^{(t • e • c)} 07:22, 7 February 2014 (UTC)[reply]

• Not helpful It's overlinking and the result may mislead a reader. Look at the "Cats" sample box above—I would expect the "Cats" link to go to some article telling me what a cat is (and would not click it), and would tend to click the first link. Johnuniq (talk) 22:50, 7 February 2014 (UTC)[reply]

• Oppose The extra link just causes confusion about where to click. These don't link the article either: {{Wikibooks}}, {{Wikiquote}}, {{Wikiversity}}, {{Wikivoyage}}, {{Wikinews}}. But {{Wikidata}} does. {{Wikisource}} links but {{Wikisourcecat}} doesn't. We are not completely consistent but linking seems like the exception and not the norm. PrimeHunter (talk) 00:31, 8 February 2014 (UTC)[reply]

(also posted on Wikisource) Hi! I am a Kindle user. I use Kindle in any my free time available because of its convince and feel. It uses e-ink, the look of which is very close to ordinary ink on paper. Sometimes, I use it to read some long Wikipedia article, but I have to convert it manually because the clumsy PDF format works poorly on my kindle, and I believe it's also works badly on other portable devices when compared to .mobi. If Wikimedia projects support this format natively, I think it will be very continent for Kindle and other e-readers users like me, and promote wiki content to be read by users in a further depth. What is your opinion?--The Master (talk) 15:46, 3 February 2014 (UTC)[reply]

Unfortunately, the MOBI file format is not an open standard. In general, wikimedia projects refrain from supporting closed and proprietary standards, since they can require licensing and expose the foundation to copyright and patent claims. The Kindle does not support the newer PDF reflow feature, which means that even if Wikipedia produces PDF files that are technically able to be displayed easily on e-readers, the Kindle still won't display them correctly. The way to do this might be to instead support the open EPUB standard for wikipedia output, which can easily be converted to many standards, including MOBI. VanIsaac_{WS Vex}^contribs 16:30, 3 February 2014 (UTC)[reply]

Thank you for replying. But one user at Bugzilla pointed out "the wikimedia foundation will replace mwlib with their own rendering pipeline. epub, zim and odf output will be removed.", which means the conversion were to be more difficult. And I've wrote a letter to Amazon to urge them to authorize Wikimedia Foundation to use that format for free. Although the chance of their approval may be small. --The Master (talk) 18:10, 3 February 2014 (UTC)[reply]

The software itself is free to use. But it is proprietary/closed source. The WMF will only use proprietary tools "where there is currently no open-source tool that will effectively meet our needs." (see Gratis versus libre) Since PDF and EPUB exist as widely-adopted open standards, chances of the WMF deciding to support Mobipocket are pretty slim. The community doesn't even want to support mp4 video files, and the free alternatives to that have much less support than EPUB. If you want to contact Amazon about it, complain that they don't support any open formats on their devices. Even the normal kings of walled gardens, Apple, support EPUB in the iBooks app. Mr.Z-man 19:40, 3 February 2014 (UTC)[reply]

There are FLOSS options to explore, such as calibre (software) on the user's side, or Writer2ePub (an OpenOffice.org extension) or Scriba ebook maker (a Java program) on the publisher's side. Some work would clearly be necessary to implement, but it looks possible in principle. LeadSongDog come howl! 21:51, 6 February 2014 (UTC)[reply]

No. The newer kindles, which have been around 2+ years at the time I wrote this, which use a real operating system, already support EPUB by installing free software on them. The native out-of-the box Kindles do not have the free software, you just have to get it. Chuckr30 (talk) 10:54, 11 February 2016 (UTC)[reply]

Not sure if this already exists, but a brief check suggests it does not. So here it is, in a nutshell:

{{nutshell}} would be modified to have an "external publish" flag. A page with a name like "Policies and guidelines in a nutshell" would be created, with subsections. Each subsection would contain the nutshell for the relevant core policies/guidelines. A bot would update the nutshell page regularly for any changes to any policy/guideline nutshells.

The benefits of this would be:

• Users could read one page and get the main idea of all policies/guidelines
• Page would be updated only by a bot, meaning that it would not have to be policed individually like other pages
• Content could be organized in a hierarchy, so sub-policies are associated closely with their parent policy

Thoughts? --NickPenguin_(contribs) 00:27, 12 February 2014 (UTC)[reply]

Not sure about that last bullet, but sounds neat to me. --Izno (talk) 00:30, 12 February 2014 (UTC)[reply]

I was thinking of cases like how WP:BIO or WP:NBOOK are subpolicies of WP:N. --NickPenguin_(contribs) 00:37, 12 February 2014 (UTC)[reply]

• Seems Wikipedia:List of policies does something along these lines wrt info but not automated. Alanscottwalker (talk) 01:01, 12 February 2014 (UTC)[reply]
  • Ditto for Wikipedia:Nutshell. Merge/improve those 2, if anything. Definitely don't create a 3rd (or more) location! –Quiddity (talk) 01:43, 12 February 2014 (UTC)[reply]

We could also consider to use Help:Labeled section transclusion to transclude nutshells so they can be shown anywhere. But it requires each nutshell to be marked in the page source. It isn't possible to make the marking in the template {{nutshell}}, and my testing indicates it doesn't work when the marking is done in the parameter to {{nutshell}}. It apparently has to be marked outside the {{nutshell}} call (diff), so the box with image and "This page in a nutshell" is included. That would make it ugly to display many on one page, but here is an example with only one. The nutshell of Wikipedia:Notability is:

PrimeHunter (talk) 02:54, 12 February 2014 (UTC)[reply]

@Quiddity and Alanscottwalker: I don't want to duplicate effort, so having one instantly updated overview page makes sense to me. Every policy nutshell has been carefully worded by years of discussion, and they are closely monitored. The kind of transcluding @PrimeHunter: has come up with is brilliant. It would make sense to put this system in place on some existing page, and redirect duplicate pages there. --NickPenguin_(contribs) 03:13, 12 February 2014 (UTC)[reply]

• Are you sure that the tags of the page can't be transcluded through the template? Please give me a few hours to look into that, I had thought I had done it on another wiki with LST. — {{U|Technical 13}} ^{(t • e • c)} 12:41, 12 February 2014 (UTC)[reply]

• Prime Hunter suggested the page would be ugly, I don't know, perhaps, Nick, you should partially mock something up using one of the existing pages talk pages or a sandbox. (As an aside, if I recall correctly, there has been discussion about how comprehensive to make those pages -- because we have so many policies and guidelines, and the page would be long. Note the WP:TOU nutshell, if you click through to it, is quite long by itself. However, what would it mean if a policy (or "important" guideline) is not set out on this proposed page -- is also something to think about) Alanscottwalker (talk) 13:01, 12 February 2014 (UTC)[reply]

As it stands, my proposal wouldn't necessarily look much different from the current versions of WP:LOP and WP:LGL, just that they would always be up to date. If length is the primary concern, then we could collapse certain subsections. We could have WP:N, and then a show/hide box that has all the specific subguidelines beneath it WP:NBOOK, WP:NMUSIC, WP:NEVENTS ect. --NickPenguin_(contribs) 17:38, 12 February 2014 (UTC)[reply]

I am not sure if this could work, but I think it would be highly pernicious if it did. Nutshells usually oversimplify and not infrequently misstate the pages they are supposed to summarize. That is a problem when nutshells are on the page, but at least the user has only to scroll down to get the full text. A page listing the contents of the various nutshells will be taken by may as listing the sole significant aspects of the relevant policy and guideline pages. This is not a good thing. Indeed I would propose any such page for deletion as a misstatement of policy. DES ^(talk) 18:12, 12 February 2014 (UTC)[reply]

This kind of content already exists at WP:LOP and WP:LGL (and Wikipedia:Nutshell, which should be deleted). I would just like to see it kept up to date. --NickPenguin_(contribs) 18:26, 12 February 2014 (UTC)[reply]

I didn't know those pages. Thanks for the tip! --NaBUru38 (talk) 22:02, 13 February 2014 (UTC)[reply]

Deleting a list of summarized policies because there are inaccuracies in the summaries would be the definitive example of throwing the baby out with the bathwater (or if you prefer, treating the symptom rather than the cause). As Nick notes, this kind of content already exists, and needs manual frequent manual attention to prevent it going out of sync. — Scott • talk 16:21, 14 February 2014 (UTC)[reply]

Also, yes, I agree that Wikipedia:Nutshell should be deleted. — Scott • talk 16:38, 14 February 2014 (UTC)[reply]

I may or may not have seen something similar proposed before, but my logic and methodology for this is a little different. This would be a sort of variation of DYK, as they would apply to recently created articles that are related to recent, encyclopedic occurrences. But this would be tailored more to viral, but encyclopedic subjects, so we can help direct curious readers towards them to learn more about potentially popular subjects as Doge, Flappy Bird and Dumb Starbucks when they become relevant.

This would be handled like a cross between In the news and Did you know; they would be more "long-term" like what we see in In the News, but the articles themselves wouldn't need to be "new" (like the DYK, and the hooks, if any, could be more like DYK.

This is just a rough concept, but it could be expanded upon. Any critique? ViperSnake151  Talk  00:13, 13 February 2014 (UTC)[reply]

In the news has the perennial problem of localism, things with a really big hype in the local news, but that nobody abroad cares about. It is already hard to select news of international interest, and this proposal would simply make things more complicated. Cambalachero (talk) 01:39, 13 February 2014 (UTC)[reply]

Unless we keep the In the news we've got now, then you can expand it to see news stories in Iowa or Kamchatka or Gibraltar. Once you click it, it shows you something along the lines of "Recent news articles in [Belize], [New Delhi], [Chihuahua]..." (the brackets show WikiLinks to the pages with the news articles). It wouldn't cover everything, that'd be way too unfeasable, but the big stories in those places would show up. Supernerd11 :D Firemind ^_^ Pokedex 02:57, 13 February 2014 (UTC)[reply]

There have been various ideas regarding displaying the top ten (or so) viewed Wikipedia articles on the main page. Seems like a pretty good idea to me..--Coin945 (talk) 02:17, 13 February 2014 (UTC)[reply]

The two questions that come to mind are: how would find trending articles and how would we present them? I assume that we'd want to have this generated automatically, rather than by hand. Getting the data about articles recently increasing in pageviews or edits is one challenge, but far from impossible. Presenting this data on the Main Page would probably require a rethinking of how the Main Page actually works however. Right now it's a wiki page no different than an article, primarily constructed from templates. In the long run, we're probably going to need to transition to having the Main Page be constructed from proper code, and have it import/use certain kinds of editable modules based on what each community prefers. It sounds big and scary, but other projects, like translatewiki.net and wikiHow, have done this in similar forms. Steven Walling (WMF) • talk 03:08, 13 February 2014 (UTC)[reply]

ITN would be kept. What I thought would work could be a weekly, curated list of "hot" articles, with explanations of the thing that made it popular/notable recently, if any. ViperSnake151  Talk  03:36, 13 February 2014 (UTC)[reply]

• Would the Main page be listed in the top ten viewed pages (since it is the top viewed by page hits)? — {{U|Technical 13}} ^{(t • e • c)} 04:08, 13 February 2014 (UTC)[reply]

If this happened, we'd definitely exclude it from itself. Jackmcbarn (talk) 04:12, 13 February 2014 (UTC)[reply]

"Main Page: The English Wikipedia's home page continues to receive mainstream attention from internet users" ViperSnake151  Talk  06:46, 13 February 2014 (UTC)[reply]

Heh. Herostratus (talk) 22:40, 13 February 2014 (UTC)[reply]

I imagine that a few hours after an automatic thing was implemented we'd see people scheming to artificially inflate the views of various pages to get them in this new Main Page section. You may want to consult with the people behind The Signpost's traffic report for the issues seen when number of pageviews isn't something in the public eye. Anomie⚔ 13:23, 13 February 2014 (UTC)[reply]

• Support. I always find the top-ten articles in the Signpost interesting, I'll bet readers would too. This would allow us to leverage our synergy to create a new paradigm. Herostratus (talk) 22:40, 13 February 2014 (UTC)[reply]

• Support as long as it doesn't become an excuse to mass-create permastubs about a single hashtag or the like. KonveyorBelt 16:27, 14 February 2014 (UTC)[reply]

• Comment I'm not sure how this would be useful. Wikipedia articles are already invariably among the top hits when someone searches for info on the latest fad. --NeilN ^{talk to me} 16:37, 14 February 2014 (UTC)[reply]

Currently Cite errors show only on article, template, category, help and file pages. I propose to add portal, wikipedia and draft pages. I am in the process of updating namespace detection for {{broken ref}}. --  Gadget850 ^talk 14:46, 16 February 2014 (UTC)[reply]

Here and here, you can see that on our friendly project, Wikia, has been launched some kind of digital protest against massive surveillance by the U.S. National Security Agency (NSA). Maybe we should start something like that and send a good message to the world. Please post your opinions and ideas how that could be realised. Also, we should probably vote on this? Alex ^{discussion ★} 21:01, 16 February 2014 (UTC)[reply]

There were proposals to participate in The Day We Fight Back on February 11. However, like that protest in general, it failed to materialize. - Floydian ^τ _¢ 22:04, 16 February 2014 (UTC)[reply]

Maybe we could try again? What is needed for that protest to materialise here? Alex ^{discussion ★} 22:59, 16 February 2014 (UTC)[reply]

I've recently done a user script - FloatHead. It makes your Wikipedia headbar floating and I think it really enhances the navigation across the wiki, especially on long pages.

Cheers! --Rezonansowy (talk • contribs) 12:49, 20 January 2014 (UTC)[reply]

Does it only work for Vector? Neither this nor Equazcion's script works for me (using Monobook). — Huntster (t @ c) 23:40, 20 January 2014 (UTC)[reply]

I think I have vector, and it's great! Dlohcierekim 01:25, 21 January 2014 (UTC)[reply]

I use Vector and it works. It does constrict the field of view a bit (top-bottom) when editing, which will take a little getting used to. I'm giving it a try. I like having the tabs available, especially on loooooong articles. Thanks again. GenQuest ^{"Talk to Me"} 02:41, 21 January 2014 (UTC)[reply]

Perfect! This way, people who used to say Wikipedia sucks can now say it gives great head! EEng (talk) 04:48, 22 January 2014 (UTC)[reply]

I would use it if it got disabled when editing a page. But I totally agree, having the top bar there is very helpful. --NaBUru38 (talk) 18:54, 28 January 2014 (UTC)[reply]

I've got no complaints. The slightly smaller space'll take some getting used to, but that's a small price to pay for this! Two questions, tho: Are there other things like this? And if so, how do I find them? Supernerd11 :D Firemind ^_^ Pokedex 04:42, 13 February 2014 (UTC)[reply]

I was looking for this. Now al it need is a pin/unpin button. — Edokter (talk) — 16:28, 5 February 2014 (UTC)[reply]

See also the Winter prototype. —TheDJ (talk • contribs) 09:48, 19 February 2014 (UTC)[reply]

Winter sports are often played autumn-spring, making one "year" span two half-years. Shouldn't they be treated that way in the year categories too? So the "year" is not like 1990 but like 1989/90 and 1990/91? Bandy boy (talk) 08:46, 17 February 2014 (UTC)[reply]

To editor Bandy boy: By winter sports, do you mean snow and ice sports, or sports that are traditionally not played in the summer?

It is already done for some sports. See for example Category:1996–97 in English football.

What changes to which categories do you propose?

--Hroðulf (or Hrothulf) (Talk) 15:14, 17 February 2014 (UTC)[reply]

I mainly thought of snow and ice sports, particulary the categories under Category:Years in bandy, but I suppose the same would go for any sport where the traditional season is autumn-spring rather than spring-autumn. Bandy boy (talk) 21:54, 17 February 2014 (UTC)[reply]

For hockey, we put (e.g.) 2012–13 NHL season into both Category:2012 in ice hockey and Category:2013 in ice hockey. The league seasons often cross two calendar years, but most tournaments are in one or the other. Resolute 20:18, 20 February 2014 (UTC)[reply]

Is there a better page for this? Anyway the Android app has a nice feature to read our GPS location and show a map of nearby articles. Handy, but it could be far more useful:

1. Atlantic Ocean. The first thing that comes up is a sea of blue. That's because it hasn't read GPS yet, and assumes we are at Longitude Zero, Latitude Zero, mid-Atlantic. If you're indoors or for some other reason GPS isn't giving a location, it stays that way. Needlessly confusing, hence wrong. Should show a world map until it finds a location, or at least a "No GPS yet" indicator.
2. True GPS only. I generally keep GPS turned off because it drains my battery too fast. Google Maps for Android still knows where we are, presumably due to cell tower triangulation and WiFi footprints. Wikipedia app should do the same, or ask GM.
3. Battery. Wikipedia app drains my battery even faster than GM does when GPS is on.
4. Desert. If we're in an area that has no Wikipedia articles, it shows nothing. Or if it thinks we're in mid-Atlantic. Should adjust zoom level until there's a reasonable number of points to show, say five to thirty or some such range.
5. Comeback. It's useful to tap on an article, find out that it's not one we want to visit, and use the back arrow to go back to the map for another go. Except, the map shows mid-Atlantic again because the app has already totally forgotten where we are. Should be able to remember for, like, even a whole minute.
6. Nearby what? We're looking at an article when we hit the menu key, right? If the article has coords, the menu should ask something like, "Near to you, or where this article is?" If it's a list of a hundred coords, show them all and let us zoom and pan for the right ones.
7. Pictures. Should have an option to see where the Commons pictures are in this neighborhood, with a different and preferably smaller icon.

Again, I hope someone can direct me to a forum or discussion place for this kind of thing. Jim.henderson (talk) 22:36, 17 February 2014 (UTC)[reply]

You are looking for the Mobile team. In general their active discussion happens on their mailing list, but i'll ping them on IRC to read their feedback page. —TheDJ (talk • contribs) 09:45, 19 February 2014 (UTC)[reply]

EFF and Demand Progress have written an open letter to the members Wikipedia community asking them to re-open Wikipedia:Surveillance awareness day, which failed to reach consensus. I'd appreciate hearing some responses from the community to this! Thanks, ParkerHiggins ( talk contribs ) 20:42, 5 February 2014 (UTC)[reply]

• With less than a week to go before the date, i don't think there is enough time for a valid RfC on such a major issue. If one were opened I would oppose on those grounds alone. And that is leaving aside the issue of whether that kind of advocacy is proper here. DES ^(talk) 20:46, 5 February 2014 (UTC)[reply]
• While Wikipedia's participation would undoubtedly give a substantial boost to this campaign, which is something many of us might like, political activism is something pretty much impossible to do while remaining neutral. If SOPA hadn't been an existential threat to Wikipedia, we probably wouldn't have done anything about it. We might like to think of Wikimedia as a major player in the activities of the "freedom"-oriented online community, but our policy of neutrality gives us far less freedom of action in these areas than other communities, even those that are corporate-run. And, as DES said above, the amount of time left wouldn't be enough for a valid RfC even if it was something widely supported. Good luck with the protest. --Yair rand (talk) 22:27, 5 February 2014 (UTC)[reply]
• (edit conflict) Oh how cute... the advocates for internet rights are attempting to bully/shame us into participating in their demonstration. Perhaps if the awareness day is celebrated again next year we can hold a "Re-call the question" RFC to close no less than 2 weeks before the event to see if there is a consensus to participate in the demonstration, as Consensus can change. Hasteur (talk) 22:28, 5 February 2014 (UTC)[reply]
• Are we not here to write an encyclopedia? Period? Take the POV social-activism to a blog or somewhere else. It does not belong here. GenQuest ^{"Talk to Me"} 03:39, 6 February 2014 (UTC)[reply]
• It became clear what was going to happen (nothing) when I posted Wikipedia talk:Surveillance awareness day/Archive 2#Proposal: Endgame Timeline and most of those participating didn't bother to respond. It was a bog-standard project management proposal for meeting a deadline: figure out what needs to be done before the deadline and start negotiating a schedule by working backwards. I had a rough draft of additional previous steps but didn't bother posting them once it became clear that there was no significant interest in making a schedule, much less meeting it. Everything I wrote in that proposal is still true. No matter what the EFF desires (full disclosure: I am a regular contributor to the EFF) we as a community blew right past the 23:59, 2 February 2014 deadline, and at that moment it became impossible to make up the lost time and meet the deadline. --Guy Macon (talk) 15:24, 6 February 2014 (UTC)[reply]

23:59, 2 February 2014

• Full disclosure, I oppose wikipedia taking sides in protests. However repeatedly I (among others)said If you want to get this done, there needs to be a centralized community discussion on the basic question, does the community support taking action. Weeks ago I (among others) said that, and not one supporter started that community discussion. It's too late now, and if you support it, when casting blame look first in the mirror for not even bringing this to the community.--Cube lurker (talk) 17:23, 6 February 2014 (UTC)[reply]

• The US conducts drone strikes in Yemen, some of which are acknowledged to be errors-- that is, killing of innocent civilians based of false conclusions. If there's a 13 year old student in Yemen who wants to read Wikipedia, I can't in good conscious recommend that they should feel free to read all our articles on chemistry without fear of becoming a 'false positive' killed by US drones for reading something suspicious.
  We didn't spend 10+ years making an encyclopedia that some parts of the world should be afraid to read!!!!
  I don't know precisely what we should do in response, but I'm confident that doing nothing is the wrong answer. --HectorMoffet (talk) 11:37, 7 February 2014 (UTC)[reply]

If you're that confident you should have taken my advice weeks ago.--Cube lurker (talk) 13:20, 7 February 2014 (UTC)[reply]

...or mine, which was posted much later and also largely ignored. These things don't just happen by magic. They require organization and cooperation. --Guy Macon (talk) 18:39, 7 February 2014 (UTC)[reply]

Hey, I make a lousy leader, what can I say. I've never read main page criteria before, I don't hang out at ANI, I'm not even an admin-- I'm a gnome who wound up in a position no gnome should be in. A true organizer could have done things a lot better-- most of the time I thought Jehochman was the leader who was going to organize cooperation, but he turned out an absentee leader. There was advice from all sides, obviously I should have taken more of it. Ya got me-- someone better than me should have handled this, and I still hope somebody better than me WILL. --HectorMoffet (talk) 03:00, 8 February 2014 (UTC)[reply]

• It's all about domestic American politics, thus outside the scope of the global Wikipedia community. SCOPA was a threat to Wikipedia's existence, this issue isn't. I really don't care if the NSA/FBI/CIA/<insert alphabet-soup de jour> wastes their time to read everything I have ever written here - they'll find it ridiculously boring (in the national security sense). Roger (Dodger67) (talk) 11:55, 7 February 2014 (UTC)[reply]

Yeah, but what if you lived in a place where killer robots controlled the skies. Would you really feel free to read whatever you wanted? --HectorMoffet (talk) 12:11, 7 February 2014 (UTC)[reply]

Is there any credible evidence that the "killer drones" have ever targeted anyone based purely on what Wikipedia articles they have read? AFAIK the only people who kill other people because they read "politically incorrect" literature are the radical Islamists - they kill people for possessing un-Islamic books. This is not a defence of US military policy, I'm simply pointing out the absurdity of your scenario. AFAIK the innocents killed in drone strikes have been due to simple target misidentification, none of them were actually intended targets (as your scenario requires). I'm done here - as non-American of a non-Islamic persuasion this is a total non-issue for me. Roger (Dodger67) (talk) 12:26, 7 February 2014 (UTC)[reply]

There is a lack of evidence because the targeting is secret. However, it is publicly known that militants can be selected by these things based on "behavioral characteristics" [3]. These characteristics can include (as that source explains) being a medical professional going to the aid of someone injured in a drone strike. So no, killing people for what they read on Wikipedia would not seem beyond the controlles' moral capabilities. Wnt (talk) 17:34, 7 February 2014 (UTC)[reply]

So, "killer robots" and "killer drones" have become buzzwords for surveillance awareness? That's pleasant, and yes, I'm in favor of awareness. Awareness of the world is the purpose of Wikipedia. And yes, more surveillance can also promote awareness of the world and there ought to be more well organized surveillance webcams. That way, millions of people can be more aware of millions of places. However, promoting awareness through surveillance is not in our purview. The most we should do is link to a few of the webcams that are surveilling a particular place, from our articles about a place. Jim.henderson (talk) 16:29, 7 February 2014 (UTC)[reply]

That is correct. "Killer robots" and "killer drones" have indeed become buzzwords for surveillance awareness, and rightly so. See The NSA’s Secret Role in the U.S. Assassination Program. --Guy Macon (talk) 08:12, 11 February 2014 (UTC)[reply]

I've taken the liberty of redirecting WP:Surveillance Awareness Day to WP:WikiProject Mass Surveillance. The EFF may have been misled by the "rejected" tag formerly at this page, which wasn't really the result of a consensus and applied only to some of the ideas discussed on the page. The "historical" tag doesn't belong on a page at all unless you don't blank the contents. Clearly those interested need to be redirected to the ongoing efforts. Bottom line: Surveillance awareness is no longer one day. Wnt (talk) 17:43, 7 February 2014 (UTC)[reply]

• Too Late Without even addressing the serious issue of whether Wikipedia should get involved, the timing issue is persuasive. Doing something right would take far more than a week, and doing something half-baked is worse than doing nothing.--S Philbrick(Talk) 15:53, 10 February 2014 (UTC)[reply]
• Too little, too late. Interesting, but Wikipedia does those things very, very slowly. Maybe if they keep on bringing this up we will have time to hold a wider discussion about doing this by next year. Also, it would be good if their activists would join Wikipedia:WikiProject Mass surveillance and help improve related content. Someone suggested that the best way to deal with such proposals is to write and feature related articles as DYKs/FA. I think it would be easiest to do just that, --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 15:58, 10 February 2014 (UTC)[reply]

• Bummer. I'm not knowledgeable about how the Wikipedia politics work but I read an article today discussing major websites supporting The Day We Fight Back and it described only Google and Wikipedia as being notably absent among those who participated in the SOPA protest (and even Google may be participating now according to a Facebook spokesperson who is part of joint task force with Google and other companies). Anyway, kinda disappointing that Wikipedia couldn't get its act together to do something as simple as add a few lines of javascript to the home page for one day. I certainly would have voted for it if there had been some kind of notice to editors. Took a good bit of searching and asking around to even find this page... :( Steevithak (talk) 02:54, 11 February 2014 (UTC)[reply]

• The Wikians have voted more than 95% for Wikia to join the Day We Fight Back protests. You can too. See Jimbo's talk page. The URL for voting is http://community.wikia.com/wiki/User_blog:Semanticdrifter/Digital_Protest_Against_the_FISA_Improvements_Act —Neotarf (talk) 18:29, 11 February 2014 (UTC)[reply]

You can tell it's accurate because it lets you vote even if you don't have a wikia account.--Cube lurker (talk) 18:38, 11 February 2014 (UTC)[reply]

• After getting a few requests from the EFF and similar groups to get engaged in this sort of activity, we started writing a draft guide on how organizations should approach working with Wikimedians -- you can find it at Asking Wikimedians To Support Advocacy on Meta. If you are interested in the topic, your input would be very helpful! Stephen LaPorte (WMF) (talk) 22:33, 21 February 2014 (UTC)[reply]

Is there a way to add multiple pages to your watchlist at once, i.e. all the links in a template on the bottom of a page? This could really come in handy for if you're into a topic that has a lot of subtopics, like Pokemon. Supernerd11 :D Firemind ^_^ Pokedex 01:34, 16 February 2014 (UTC)[reply]

The closest way would be to edit your raw watchlist. Alternatively, you might try Special:Recentchangeslinked/Template:Pokémon (for example). --Izno (talk) 02:41, 16 February 2014 (UTC)[reply]

These work, as well as what I was doing before (hovering over each one in the navbox on the bottom of the page and selecting "Watch" from the mouseover box), but I was hoping for something like "Watch all subpages". I don't have the developer know-how, is there someone who can do that? Supernerd11 :D Firemind ^_^ Pokedex 03:18, 16 February 2014 (UTC)[reply]

The "Related changes" feature reports all changes to pages linked from a given page. See Help:Related changes for more information. DMacks (talk) 05:05, 22 February 2014 (UTC)[reply]

{{Non-free review}} is a template used to tag non-free files which are being discussed at WP:NFCR. The template had been changed to be usable for tagging articles with multiple non-free files as well. That functionality has been removed from the template (see discussion at Template talk:Non-free review#RfC: Should the non-free review template be added to articles?). I propose to add that functionality again. Informing the visitors or watchers of a page that non-free content on the page is being discussed at NFCR seems to be useful. Not all editors watching a specific article might be watching all the files used in the article. -- Toshio Yamaguchi 15:25, 23 February 2014 (UTC)[reply]

• Support Several times recently I've noticed (via my watchlist) files being removed from articles, they had been deleted after failing a NFCR - but the first that I knew of the NFCR was the removal from the article. I had no opportunity to comment. --Redrose64 (talk) 23:07, 23 February 2014 (UTC)[reply]
• Comment as a point of note: there was a small discussion at NFCR to adapt the current non-free review template to include page-notification functionality about a year ago. About 4-5 months ago, after the template was tagged on a page, editors of that page and its related project questioned the consensus of that template and initiated an RFC which ended that there was no consensus to make the initial change to include notifying the page (via the article page itself). This RFC thus can be seen as (if agreed by consensus) validating the initial decision to add the page notification function. --MASEM (t) 03:43, 24 February 2014 (UTC)[reply]
• Support as this seems useful to me. User:Technical 13/+3 Would've commented sooner but didn't notice the proposal. — {{U|Technical 13}} ^{(t • e • c)} 22:19, 7 March 2014 (UTC)[reply]

I have requested comments from others at https://en.wikipedia.org/wiki/Talk:Persecution_of_Hindus#Request_for_comments. Please support or oppose the survey going on there.—Khabboos (talk) 17:16, 24 February 2014 (UTC)[reply]

When talk pages get too long, the older comments are usually archived to subpages either manually or by a bot, with a name like Talk:PageName/Archive 1 or Talk:Pagename/Archive February 2014. There are some other pages that get archived too, but mainly it is talk pages. Archiving usually results in a redlink mainspace, which has often been redirected back to the article/userpage etc. Occasionally people add comments to these archived pages despite notices asking them to add new comments to the parent talkpage.

I propose the creation of a new set of associated namespaces called "Archive:", to serve as more organized locations for all archived pages. It would probably require a software change but I was thinking it could be attached to the talk pages, for example as a tab next to the history tab, or there could be a link from the top of the talkpage and/or the history.

The format for mainspace would be either "Archive:PageName 1" or "Archive talk:PageName 1" or "Talk archive:PageName 1". For the other namespaces it would be Archive User:, Archive W:, Archive File:, Archive MediaWiki:, Archive Template:, Archive Help:, Archive Category:, Archive Portal:, Archive Book:, Archive Draft:. Alternatively the styles could be User archive:, Wikipedia archive and File archive etc. However I'm not opposed to the idea of leaving userspace out of this proposal.

A rudimentary search suggests there are approximately 156,000 article archives, 178,000 user archives, 23,000 Wikipedia archives, and just under 8,000 for the other namespaces, although these numbers should be taken with a pinch of salt because the search includes any use of the word "archive". Green Giant (edits) (talk) 14:22, 17 February 2014 (UTC)[reply]

There's a product under active development, called WP:Flow, that aims to create an improved "discussion and collaboration" system. Making topics (threads) archive automatically, without the incoming links breaking when the topic is archived as they do now, is just one of the core goals. (Currently they're using an "infinite scroll" model, with auto-pagination for non-js users, but active/ongoing testing and feedback from us, may lead in different directions, in the future). It is a massively complicated and long-term project, and everyone's input/suggestions/feedback (at the talkpage there, not here, to avoid more fragmentation!) is encouraged and appreciated, over the months. HTH. Quiddity (WMF) (talk) 19:37, 17 February 2014 (UTC)[reply]

I don't see much benefit to this proposal over the current subpage method, since subpages are typically linked from the main talk page, and are often searchable. Subpage archives can be protected at user request to prevent other uses from responding to an archive. That alone isn't enough for me to oppose this proposal, but with Flow being developed to replace the current talk page system, I'm not sure it's a good time to make this change. Novusuna ^talk 21:01, 17 February 2014 (UTC)[reply]

Flow is still a long way from being implemented wiki-wide, because even now there is a tentative date of "2015 and beyond". In the explanation in WP:Flow/FAQ, the stated intention is to archive current talkpages and link to the archives from the header. After Flow is implemented, the idea will be to summarise topics. With the best will in the world, there will only be so much summarizing of topics before people start asking for archiving. I am in favour anything that improves the systems but it isn't realistic to think that archives won't be needed in the long term. That's why I'm proposing that archives be given a formal space. I don't think search functionality will decrease just because they aren't subpages, on the contrary you'd be able to refine a search to the archive namespace. Green Giant (edits) (talk) 01:14, 18 February 2014 (UTC)[reply]

I think it's more important and useful to keep "current and archive" together (page and subpages) than to keep "all archives" together. The present system makes it easy to delete/rename the whole lot of them. Is it often the case that one would want to search all archives but not the current pages? But even still, the "search only archives of a page" feature already exists: prefix:Talk:Foo searches Talk:Foo and all Talk:Foo/* subpages whereas prefix:Talk:Foo/ only searches in subpages. Could you explain what "Archiving usually results in a redlink mainspace" means? DMacks (talk) 05:02, 22 February 2014 (UTC)[reply]

The problem that this proposal is attempting to address is the red links that are created when content is archived. I don't see how moving the content to another namespace rather than to a subpage solves that problem. There is a "bot with a clue" that knows how to solve the problem, see this diff for an example. But User:ClueBot III doesn't find all of these, and I often manually make link updates of this sort. Wbm1058 (talk) 14:06, 25 February 2014 (UTC)[reply]

Fairly recently, a change was made to the MediaWiki core that allows for content to be displayed on #REDIRECT pages. This change and a discussion that was started on Template talk:Isp has prompted me to start this RfC to see if there is support to allow these templates (Category:Redirect templates) that are designed to provide information to anyone who happens upon a redirect page and isn't redirected for some reason or visits the page directly using &redirect=no. Should these templates be modified to allow use on any redirect page as long as the categorization provided by the templates are restricted to the essence of the category. — {{U|Technical 13}} ^{(t • e • c)} 23:11, 21 February 2014 (UTC)[reply]

• The relevant software change was in mw:MediaWiki 1.23/wmf10 (about a month ago). --Redrose64 (talk) 23:28, 21 February 2014 (UTC)[reply]

This proposal will allow someone visiting //en.wikipedia.org/w/index.php?title=Template:Isp&redirect=no to see the message "This is a redirect from a title with another method of capitalisation. It leads to the title in accordance with the Wikipedia naming conventions for capitalisation, and can help writing, searching, and international language issues." — {{U|Technical 13}} ^{(t • e • c)} 23:11, 21 February 2014 (UTC)[reply]

• I just finished (mostly) clearing out Category:Pages with templates in the wrong namespace, and will need help from an administrator to finish up some of the rest. There were hundreds of pages in this category, which T-13 didn't notice until he stalked my protected edit requests. There was a fair amount of garbage on these redirect pages and the task was made very tedious, even with the aid of WP:AutoWikiBrowser by the fact that editors insist on creating two dozen cryptic aliases for each of these redirect templates. I suppose now we can open up these pages for editors to post phone numbers and email addresses. I won't be volunteering to help clean them up, frankly I'm a little sick of redirect templates right now. I think they're mostly pointless. But at least these aren't throwing spurious {{error}}s now. Wbm1058 (talk) 00:42, 22 February 2014 (UTC)[reply]

• Redirect category templates (rcats) are just used to sort redirects into maintenance categories not into article categories. Please imagine how many more redirects will be sorted to Category:Redirects from other capitalisations if its rcat were allowed to tag all such redirects instead of just the ones from mainspace. The R from other capitalisation rcat has always sorted only mainspace "other capitalisations" to its category, so for redirects in other namespaces that are plurals or other capitalisations, I've always used {{R from modification}} (used for any-namespace redirect) to sort them, which is, I believe, how I've seen it done in the past. There are several rcats that either sort just to one namespace, or sort to all but one namespace, or sort to two either/or namespaces and so on. These sorts were initially set up for certain reasons. If we cannot figure out what those reasons are, then by all means, there is no reason why specialized sorts should exist. To me, the reasons are fairly obvious, aren't they? In the case where they sort into "mainspace only", the reason is that it is the article-space "other capitalisations", "plurals", "singulars", etc., that are tracked from those maintenance categories, and only the article ones. – Paine Ellsworth ^CLIMAX! 02:13, 22 February 2014 (UTC)[reply]

• None, that's my proposal. Show "just the text" if used outside of article space. Zero categorization. outside of redirects in article. This means there would be 0 more redirects will be sorted to Category:Redirects from other capitalisations if its rcat is allowed to be used to tag all such redirects instead of just the ones from mainspace. — {{U|Technical 13}} ^{(t • e • c)} 02:21, 22 February 2014 (UTC)[reply]

• Then you may be looking for a different thing, like documentation of some kind. The redirect category templates are designed to both categorize and to be read by those who come to the page. To use them to do only one or the other would overcomplicate things when all that is necessary would be text and not categorization. The main job of rcats has always been to categorize, in fact their only job up until January. Now that text appears on redirects, the only text that should appear that's generated by an rcat is the text that explains why it has been thusly categorized.
• Also, wouln't it be so much better and easier if {{R from modification}} were made more informative in the way you suggest? – Paine Ellsworth ^CLIMAX! 03:09, 22 February 2014 (UTC)[reply]

• I'm saying that redirect category templates should designed to both categorize on article pages and to be read by those who come to the page. This is a simple change. It's basically as simple as changing [[Category:Redirects from foo]] to {{#ifeq:{{NAMESPACENUMBER}}|0|[[Category:Redirects from foo]]}}. This will ensure that only article pages are categorized, and only the text portion of it is show anywhere else. — {{U|Technical 13}} ^{(t • e • c)} 03:36, 22 February 2014 (UTC)[reply]

• That sounds good to me. Why not just sandbox it at {{R from other capitalisation/sandbox}} to see if it works the expected way? There aren't that many rcats that would need it. – Paine Ellsworth ^CLIMAX! 03:55, 22 February 2014 (UTC)[reply]

• I'll sandbox it tomorrow. It's 11PM here now and I'm exhausted.  :| — {{U|Technical 13}} ^{(t • e • c)} 03:58, 22 February 2014 (UTC)[reply]

• See T16323 ("Redirect pages should render all text"), Move redirect rendering into WikitextContent and Use WikitextContent to render redirects. This is nice in that it allows the meaning of the cryptic redirect-template-shortcuts to be translated into English, put I wouldn't want to divert project resources into further editing of these redirect pages when WP:WikiProject Merge and WP:WikiProject Orphanage are still so much needing help. And "supporting it" would only encourage editing in this area. – Wbm1058 (talk) 02:41, 22 February 2014 (UTC)[reply]

• Divert "what" resources? An hour of my time to change [[Category:Redirects from foo]] to {{#ifeq:{{NAMESPACENUMBER}}|0|[[Category:Redirects from foo]]}} on all of the Category:Redirect templates? Seems fairly minimal to me... — {{U|Technical 13}} ^{(t • e • c)} 03:56, 22 February 2014 (UTC)[reply]
  • I'm not worried about the hour of your time taken to edit templates. I'm concerned with the hours that other editors will then take to actually use those, creating junk like this, this and this, that someone like me will spend hours cleaning up. I'd rather channel editors into doing something more productive. The hour of your time would be better spent on finding links for orphans. Wbm1058 (talk) 04:33, 22 February 2014 (UTC)[reply]

• Now that the initial "cleaning" is done (thank you), and the core has changed to display text (and in those cases the redlinked templates indicating there was screwup), I don't see any reason these templates can't be used to add this text description to the redirect page, as that is partly what the template is designed for in the first place. The other part of the design is categorizing articles, and it can still do that and it being used on non-articles has 0 impact on that with my proposal. Now, I'm going to finish my midnight cookies and milk, take my midnight tinkle, and go back to sleep. — {{U|Technical 13}} ^{(t • e • c)} 05:40, 22 February 2014 (UTC)[reply]

To editor Technical 13: Just FYI, I have transferred the discussion that prompted this RFC to Template talk:ISP#Protected edit request on 21 February 2014. Also, since there are other rcats that the redirect needs, I will modify Wbm1058's request a little. – Paine Ellsworth ^CLIMAX! 17:35, 25 February 2014 (UTC)[reply]

I propose using wiki to post about current elections, candidates, policies, and other relevant information. The purpose: to give young voters a source for information about who and what they vote for in elections.— Preceding unsigned comment added by ‎173.161.194.242 (talk • contribs)

Why young voters in particular? Actually, never mind that, but do read WP:WORTHYCAUSE. You may also find WP:POLITICIAN informative. --Demiurge1000 (talk) 22:16, 24 February 2014 (UTC)[reply]

Sounds more like something for WikiNews. Supernerd11 :D Firemind ^_^ Pokedex 22:17, 24 February 2014 (UTC)[reply]

See Ballotpedia (website) -- Ypnypn (talk) 22:22, 24 February 2014 (UTC)[reply]

We already do that to a large extent. For national elections in English-speaking nations at least, there's usually a pretty well-developed article on each candidate by the time of the actual vote. But "discussion" of politics or pushing an agenda would run afoul of core content policies like Wikipedia:No original research and Wikipedia:Neutral point of view. Mr.Z-man 22:23, 24 February 2014 (UTC)[reply]

There's some proposals for new Wikimedia projects for that, and I would support it given the right circumstances. See meta:VotersWiki. --NaBUru38 (talk) 18:22, 25 February 2014 (UTC)[reply]

I think it might be a good idea for there to be a project page that lists all other project pages with a few exceptions as discussed later, other than those anyone is supposed to be able to create when ever they want. For example, it should include Wikipedia:No original research, Wikipedia:Size of Wikipedia, Wikipedia:Teahouse, and Wikipedia:You don't need to cite that the sky is blue but not Wikipedia:Articles for deletion/Java update virus. That way, fewer people will be asking questions about Wikipedia's policies at the teahouse or the help desk. I guess Wikipedia:Teahouse/Questions shouldn't be listed either because it's so obvious how to get there from Wikipedia:Teahouse and not Wikipedia:Village pump either because it's obvious how to get there from Wikipedia:Community portal. There should also be another project page that lists all help pages and that project page should categorize the list of all help pages where one of the sections is only for help pages that discuss how to make edits, such as Help:Using talk pages and Help:Referencing for beginners but not for ones that discuss which edits comply with Wikipedia's policies, such as Help:Edit conflict unless they both teach how to make certain types of edits and which types of edits comply with Wikipedia's policies. Blackbombchu (talk) 02:23, 25 February 2014 (UTC)[reply]

There are thousands of project pages. Wikipedia:You don't need to cite that the sky is blue is one of around 1500 in Category:Wikipedia essays, and that count excludes subcategories. Many pages already list a selection of project pages and sometimes other pages. Wikipedia:Editor's index to Wikipedia is probably the largest. I don't think any page should attempt to list nearly all project pages, but if it did then it would be very strange to omit the important Wikipedia:Village pump just because it's one of many pages linked at Wikipedia:Community portal. PrimeHunter (talk) 03:03, 25 February 2014 (UTC)[reply]

See Wikipedia:Project namespace for an overview of all project pages. If you really want to see all other project pages, work your way through Wikipedia:Quick project index. There have been several attempts to organize project pages to make it easier to find a topic, but in my opinion Wikipedia:Editor's index to Wikipedia is the best effort to date. Perhaps that needs better exposure over at the teahouse and help desk. Wbm1058 (talk) 14:29, 25 February 2014 (UTC)[reply]

When I search for an article, such as Augustus, I find a very well organized article, but then when I search for something else relating to the Roman Empire, I find that it doesn't match up to the standards of Augustus. What if we can put together groups that work on 5-10 pages all dealing with the same general theme and cohesively make all of them nicer.

Also, while doing this we can get 10 or so pages that have very little content, but are part of the same theme and make them all a lot nicer. This way Wikipedia can be good all around.

Right now when I look up a topic I might find two good pages about it, but then the rest are bad and sometimes more are good and sometimes none of them have any real information — Preceding unsigned comment added by 108.41.85.73 (talk) 15:28, 25 February 2014‎

Good news! Wikipedia already has groups of editors who collaborate to improve Wikipedia. These groups are called WikiProjects. Some WikiProjects are centered around a particular task, and others center around a topic. There's even an existing WikiProject that seeks to improve articles about ancient Greece and Rome. If you want to help them, or if you just want to bring some articles to their attention, I'm sure they would appreciate a message on the their talk page. Novusuna ^talk 20:50, 25 February 2014 (UTC)[reply]

Hey guys,

I was wondering if you thought of the following added feature to Wikipedia.

There are many controversial articles out there and although I've heard that Wiki's approach is to avoid them, it is clearly not the case. To mitigate this problem and offer additional service consider having a polling mechanism as an option for certain articles.

In this system, one could have different classes of polls. For example men and women; the public and experts; or Wikipedians and non-users. Clearly certifying credentials would be difficult, but one approach would be to have users authenticate each other. For example if we had a group of experts in a specific field, to add an expert to that field he/she would need a vote of confidence from the majority of the existing experts.

Any ways I think this would be an informative tool --even if the poles were only from Wikipedians. This would allow us a clearer picture on confidence levels about controversial topics.

Thanks

.orphan{
    display: inherit !important;
}

HJ Mitchell, will you agree there is also no longer a consensus to move the tags (which is technically impossible to maintain) to the talk page? I believe that there should be some clarification in the closing. Yes, everyone agrees readers shouldn't have to see this tag, but few seem to be of the opinion the tag should be moved. — {{U|Technical 13}} ^{(t • e • c)} 23:06, 3 February 2014 (UTC)[reply]

Technical 13, I've become really frustrated with this situation. The viability of your alternate proposal is contingent on you or someone else being able to actually implement it. My last message at Module talk:Message box has not been responded to for over a week now. There is absolutely no consensus for the status-quo, and I see no evidence that you are able to hide the orphan message except when inside {{multiple issues}}. You had a solution which hid the message in all situations, including inside {{multiple issues}}, that I confirmed worked but for a cosmetic glitch which nobody had a solution for. Rather than look for a solution for the cosmetic glitch you have attempted to find a more complex solution involving a "hidden" parameter, but I cannot confirm that this more complex solution works. Hence we are now on the verge of a train-wreck here. I believe from the spirit of the earlier consensus that there is de facto consensus for your basic solution. Arguably a consensus could be obtained for the more complex solution, but that is a moot point if it can't be delivered. I believe that the consensus at this point would be to let Yobot 23 proceed with trial, if that would actually move us off the status-quo that there is no consensus for. Further delays in that bot's trial might well be considered disruptive at this point. Wbm1058 (talk) 18:50, 4 February 2014 (UTC)[reply]

• (edit conflict) Due to my personal lack of knowledge with Lua at this point, I will admit it is a slower than should be process. I've reached out for help in this, and haven't gotten much response. As a result of this, I've been trying to learn Lua on my own by practicing on building new modules to learn the basics of it before digging into some of the complexities in the modules that would require adjustments here. Yes, this could simply be done via MediaWiki:common.css and a new class introduced for orphan tags, but I think that adding such a thing to the core css file is a hackish solution, and am trying my hardest to learn the language needed to make the proper adjustments that I think would best serve the community. I again make a plea to those knowledgeable in lua (Theopolisme—Mr. Stradivarius—Anomie—MSGJ—Jackmcbarn) to make the changes or offer whatever assistance that they can to move this along. Thanks. — {{U|Technical 13}} ^{(t • e • c)} 19:02, 4 February 2014 (UTC)[reply]

• What am I supposed to be fixing exactly? Jackmcbarn (talk) 19:06, 4 February 2014 (UTC)[reply]

A new version of Module:Message box went live 01:04, 27 January 2014. It's supposed to "allow ({{ambox}}) boxes to be hidden" but I can't figure out how it's supposed to work. I asked (Module talk:Message box) if this could be tested before it went live, and was assured that "it has been tested enough." Can you figure it out? Wbm1058 (talk) 19:23, 4 February 2014 (UTC)[reply]

• Hello Jack, quite simply, {{Orphan}} is suppose to have class="hidden-ambox" style="display: none;" or something of that nature when used by itself, but not if it is used inside of {{Multiple issues}}. — {{U|Technical 13}} ^{(t • e • c)} 20:34, 4 February 2014 (UTC)[reply]

  @Technical 13: How is self:addClass('infobox editsection') supposed to hide anything? Jackmcbarn (talk) 20:44, 4 February 2014 (UTC)[reply]

• That's a good question Jack, I honestly do not remember how I decided that was the best to use. I had found that was a class at the time that was defined something like .infobox .editsection{ display: none;} in one of the existing skin main.css files, but I don't remember which. Might be worth checking with Edokter for an update on his proposal and progress on re-writing MediaWiki:Common.css to be more modular and developer friendly. — {{U|Technical 13}} ^{(t • e • c)} 21:32, 4 February 2014 (UTC)[reply]

• Not much progress so far, and I never thought about any show/hide mechanism. If that is a usefull feature, feel free to add it to Wikipedia:New CSS framework. — Edokter (talk) — 22:27, 4 February 2014 (UTC)[reply]

@Edokter:, @Jackmcbarn: – please give your opinions on the viability of this interim stopgap solution which could be used while the more robust module techniques are still in development. The only template change is to {{orphan}}, per this diff. By default this hides the orphan messages, both when the template is used stand-alone and when it is sandwiched inside {{multiple issues}}. Using User:Wbm1058/common.css overrides the hidden feature and makes the messages visible again. See Template:Orphan/testcases for a demo. The only issue I've seen is that the bullets don't line up inside {{multiple issues}}; the orphan messsage is a bit too far to the left. Do you know how to fix that? Is this viable—at least as a temporary solution—or is it in anyway an unacceptable hack? Thanks, Wbm1058 (talk) 00:12, 5 February 2014 (UTC)[reply]

• Given that a solution is apparently technically difficult, i would favor simply deleting the template and removing it by bot from all current placements. Frankly I don't see that it adds any value, since for any given article What-links-here will supply the identical data. Failing that, a move to the talk page as originally suggested would be better -- I wasn't higjhly impressed with the reasons asserted for not doing this as the original RfC had consensus to do. DES ^(talk) 00:48, 5 February 2014 (UTC)[reply]
  • I like T13's proposal. I don't really like DES's. Anyway, using list-item or inline (not sure which, one should work) instead of inherit should fix the misalignment. Jackmcbarn (talk) 01:11, 5 February 2014 (UTC)[reply]

There is no need for the extra class "orphan" (there is already "ambox-Orphan"). The question is how to enable (show) it again for those that want it. Personal CSS would work, or a gadget. On the bigger picture though, I don't personally really see a need to hide it in the first place. These kind of messages are there to show all issues and motivate readers to become editors. If some particular message is not effective, it should be removed. — Edokter (talk) — 09:27, 5 February 2014 (UTC)[reply]

Thanks, Edokter. Yes, that was setting off my "hack-alarms" but it wouldn't work without it. I changed that as you suggested, so this is the only change needed (add | style = display: none). Then the light-bulb went on; I needed this in my common.css to make it work. Jackmcbarn, I tried changing inherit in my common.css to both list-item and inline, and each had an effect, but not the desired one. Any other ideas on how to make the bullets line up? I don't really know css. I think the idea of making this a gadget, so that editors need only check a box, rather than install their own custom common.css, once we have this working right and confirm consensus for it, is an excellent idea. Thanks, Wbm1058 (talk) 15:48, 5 February 2014 (UTC)[reply]

You must use display: inherit !important; as the style you are trying to override in inline. — Edokter (talk) — 16:19, 5 February 2014 (UTC)[reply]

Right, that is what I am using, see here. That is indeed overriding the line | style = display: none in {{orphan/sandbox}}, but it is also having the undesired side-effect of overriding something else as well as it is also effecting the live {{orphan}} template by causing the bullets to mis-align. Where is "ambox-Orphan" defined? There must be some other characteristic of that which I want to avoid overriding. Wbm1058 (talk) 17:11, 5 February 2014 (UTC)[reply]

Oh, I see. class = ambox-Orphan was added here, for the benefit of Twinkle. Wbm1058 (talk) 19:31, 6 February 2014 (UTC)[reply]

I must have dreamed about this last night, because when I woke up this morning a light-bulb turned on in my head. I'm optimistic now that I can come up with a solution, maybe later today. So hang tight for a bit, more later. Wbm1058 (talk) 16:08, 7 February 2014 (UTC)[reply]

After beating on this for over two days I have found a technical solution which makes T13's proposal to hide the orphan message only when it is not part of {{multiple issues}} possible. It's not pretty, but I think it works. Implementing a more elegant solution requires another redesign of {{multiple issues}}. That template has already been redesigned once, and the need to continue supporting the legacy design contributes to the complexity of the solution.

• First, I have cleared the backlog of edit requests for {{orphan}} and brought the template documentation up to date, so, before reading further you may want to review the template:Orphan documentation.
• To support the old syntax of {{multiple issues}}:
  • Modify {{Orphan}} per this diff which adds a new parameter multi, which when set, displays the orphan message rather than hide it.
  • Modify {{Multiple issues/message}} per this diff to pass the parameter multi when calling {{orphan}}.
  • Modify {{Multiple issues}} per this diff to set multi = multi and pass it to {{Multiple issues/message}}
• To support the new and current syntax of {{multiple issues}}:
  • Further modify {{Multiple issues}} per this diff to support display of orphan messages in {{multiple issues}} when using the new syntax.
• Review the test cases at Template:Orphan/testcases (I added more test cases to cover all the scenarios)
• Install this code in your personal common.css file to un-hide the hidden orphan messages.
• We will probably want to file a request at Wikipedia:Gadget/proposals to make this special code a gadget, so that the orphan patrol can simply check a box at Special:Preferences#mw-prefsection-gadgets to show the hidden orphan messages.
• I still see the "cosmetic glitch" in both Chrome and Internet Explorer after I activate the special "gadget code", which misaligns the bullet for the orphan message in {{multiple issues}}. I am mystified about what is causing it. I went so far as to save the html source from a page to compare the differences between the displayed html when the bullets align to when they don't. Here is the diff from that test, which leaves me clueless. But, as this glitch is only cosmetic, and would only effect those editors who opt-in to the gadget, I suppose we can live with this issue.
• Kudos to Jackmcbarn for pointing me in the right direction when I got stuck.
• No Lua required; no new CSS class required.

Please review this solution and comment on whether it is good enough. I suppose if it passes technical review then the next step would be to take it back to the general editor population to see if there is a consensus for it. Thanks, Wbm1058 (talk) 17:17, 10 February 2014 (UTC)[reply]

As there seem to be no technical issues with my solution, I will begin composing a third Request for Comments, which should hopefully finally settle the matter of orphan tags. Wbm1058 (talk) 01:36, 13 February 2014 (UTC)[reply]

Regarding the "technical glitch", if I remove the !important from .ambox-Orphan{display:inherit!important;} then the bullets line up, but the override to show the orphan template doesn't work. Wbm1058 (talk) 22:24, 13 February 2014 (UTC)[reply]

Here is a screenshot taken by Mr. Stradivarius demonstrating the glitch. I'm guessing that perhaps somewhere along the cascade, something isn't correctly specified, and thus slightly incorrect display specs are being inherited by the override. Wbm1058 (talk) 16:17, 14 February 2014 (UTC)[reply]

• I updated the progress section on the Category:Orphaned articles page. The one-year reduction from 122,500 orphans on 13 February 2013 to 121,092 orphans on 13 February 2014 is not much of a reduction. We are just treading water. Most of the tagging is done by bots and tools such as AWB and Twinkle. I am concerned that if we hide all tags from day one then that could have a negative effect on de-orphaning; rather than continue treading water we could begin to drown in orphans. I know, we probably already are. Better de-orphaning tools are needed. But I'm thinking that we shouldn't hide the orphan message from day one, but rather put a time limit on it. Perhaps hide the message after three months? I'm thinking that most tagging is done to newly created articles, and the editors most motivated to find links are the editors who created the articles. If they never see the bold message at the top of their new articles, then how would they ever be motivated to help find links to it? Wbm1058 (talk) 15:09, 21 February 2014 (UTC)[reply]

• Wbm1058, if the tag can only be seen when used inside multiple issues or if specifically set to be seen, then why does it need a time limit? — {{U|Technical 13}} ^{(t • e • c)} 16:00, 21 February 2014 (UTC)[reply]

  In cases where it is the only issue, it will not be seen as part of multiple issues, and thus would only be seen if it was set to be seen by a dedicated patroller. Perhaps these are the only editors who find links, but we would be removing the notice and opportunity from the new editors who created the orphan (often about a person or organization) to find links for their newly created article. Maybe these new editors so typically create articles with multiple issues that most all of these will be tagged multiple for some time after creation. I was just thinking that it might be a good idea to let the tag stay up for a short time so that the article creator is made aware of the problem and has a chance to solve it if they are so inclined. If they, or a gnome, don't solve it within a given time limit, then hide the tag as a longer-term problem unlikely to be addressed in the short term. There would still be no time limit on showing it inside multiple issues, and those opting into the orphan-display gadget would always see the message. Wbm1058 (talk) 16:28, 21 February 2014 (UTC)[reply]

• I see. While I personally think the tag should always be visible to everyone except those who specifically hide the tag because they don't want it, the consensus is the opposite. As such, the current consensus is that the tag should never be seen by anyone unless they specifically want to see it (opt-in with css or a userscript), or if it is placed inside {{Multiple issues}} with at least one other issue. I believe there is currently a lot of frustration by people on both sides of whether this tag should be displayed on articles, and think the best course of action is to wait at least six months before proposing what you would like it to do here (I'd wait a year personally based on my perceived sense of the amount of tension surrounding the issue). — {{U|Technical 13}} ^{(t • e • c)} 16:49, 21 February 2014 (UTC)[reply]

(←) Bump. Sorry, I've let myself get pulled into working in other areas. I do intend to get to the third RfC that I promised, and certainly don't think it would be fair to make those who supported the original consensus to move to the talk page wait six months for action. Ideally I would like to do some more analysis of de-orphaning in practice. I will get back to this. Wbm1058 (talk) 03:37, 28 February 2014 (UTC)[reply]

Those feedback pages seem to be getting ever so little attention. It should also be possible to add hyperlinks to those pages unlike Special:ArticleFeedbackv5/Cavitation. Blackbombchu (talk) 18:29, 24 February 2014 (UTC)[reply]

Feedback is being completely disabled in the next few days. There's no sense in making improvements to it now. Jackmcbarn (talk) 19:28, 24 February 2014 (UTC)[reply]

I think it would be better if it wasn't disabled because it helps people who have no idea how to edit Wikipedia suggest how to make an article better. Without it, some articles might never start including some of the useful information that some people read in hope of finding it. Blackbombchu (talk) 00:07, 25 February 2014 (UTC)[reply]

You can: Special:ArticleFeedbackv5/Cavitation/05116d63c59d6e4204b390b11c28d715 is the comment you left. Click "details" to find the link. WhatamIdoing (talk) 21:57, 26 February 2014 (UTC)[reply]

I visited the State Reserves Bureau copper scandal article and since I am from Germany and speak german, I seeked the "Deutsch"(german in german) link and found none. I know that the German Wikipedia have a long translation wish page where i can add this article, but I think it should be easier to wish a translation and maybe this can be included into Wikidata ("article pending translation request"). 78.35.202.16 (talk) 21:53, 27 February 2014 (UTC)[reply]

There have been some changes proposed to the manual of style guideline regarding trademarks in order to provide more rigid criteria that reflects recent consensus, and provide some harmonization with WP:COMMONNAME. Please feel free to join the discussions. ViperSnake151  Talk  06:27, 1 March 2014 (UTC)[reply]

I think just like each Wikipedia article, for each reference in an article, it should be possible to see a list of all the articles that list that reference and it should be done by clicking the number itself just to the left of the ^ symbol if a better way can't be found. The page that lists all Wikipedia articles that use that reference should also state the number of articles that use that reference. In addition to that, Wikipedia's source code should change to make it so that in any list of more than one reference that's made using a Reflist template, there's automatically a link at the top of the list of references to click to switch between listing them in the order of information in the article they're citing and listing them in the order from used in the most articles to used in the least. That way, people reading Wikipedia will have a really easy time finding a very good source to read, either for their own interest of learning more or to be a good Wikipedian. If it's an online reference, it can probably be built straight into the code to list all articles that use it, but if it's a book, it might require a bot to hunt for all articles that use it and recognize it as the same book since it won't be listed exactly the same way in every article, and it might have to be a complex bot that can recognize spelling mistakes. In addition to that, knowing the number of articles that use a specific reference makes people less likely to make a mistake and buy a book reference thinking it's really good and it isn't. For example, I assume Griffiths, David J. (2004), Introduction to Quantum Mechanics (2nd ed.) to be a good book with lots of information because I saw it in more than one article. Blackbombchu (talk) 22:12, 1 March 2014 (UTC)[reply]

You're asking for a lot, about which much could be said.

You ask for a bot to identify all instances of a reference, allowing for variations of spelling. For various reasons I think this is not likely to happen, that you would have to accept the more limited scope of references that have been templated. Even this is problematical. However, you might look at the {{doi}} template and its database to see how feasible such a feature might be. ~ J. Johnson (JJ) (talk) 22:39, 1 March 2014 (UTC)[reply]

I have started an RfC to determine whether WP:ER should be closed and marked as historical. You are invited to contribute to the discussion. Wikipedia talk:Editor review#RfC: Should we mark WP:ER as historical?. Thank you. —/Mendaliv/^2¢/_Δ's/ 01:47, 2 March 2014 (UTC)[reply]

I don't want to cause issues and get anyone in trouble if I'm on the wrong page, but I want to discuss an issue with the use of columns. I think it causes annoyance to anyone who uses computers and laptops, regardless of what others who use cell phones and iPods say about them. I proposed that we should setup a special program that would allow anyone who uses cell phone, iPods and such mobile devices to see articles that would allow them to see sub-sections and tables without going long hauls to look over them and anyone using computers and laptops won't have to see short tables and sub-sections due to unnecessary size of columns which would annoy and frustrate many readers who use computers and such. Think about that. If I wrote this proposal on the wrong page, tell me where to put it at. BattleshipMan (talk) 03:13, 19 February 2014 (UTC)[reply]

I don't think I understand your proposal. There is a separate mobile site, so it might be possible. But do you want to use columns for desktop computers and not on mobile, or the other way around? WhatamIdoing (talk) 04:41, 19 February 2014 (UTC)[reply]

Count me among the confused as well. I can't tell what exactly is being proposed here. Novusuna ^talk 04:45, 19 February 2014 (UTC)[reply]

What I meant to say is that columns should only be used in mobile and not on desktop computers. The unnecessary size use of columns is becoming an annoyance to anyone using desktop computers and some users are unnecessarily using columns sizes to cut down larger sub-sections and tables for mobile users, which is becoming smaller for anyone using desktop computers. BattleshipMan (talk) 05:13, 19 February 2014 (UTC)[reply]

Still confused. Are you saying columns are not rendering properly somewhere? I haven't seen that on my laptop. Or phone, for that matter. GenQuest ^{"Talk to Me"} 05:25, 19 February 2014 (UTC)[reply]

I apologize for the confusion here. I'll figure it out later. BattleshipMan (talk) 07:55, 19 February 2014 (UTC)[reply]

It sounds like the problem you are having is that users have previously specified the number of columns in an embedded list (using something like {{col}}), usually 2, and you're noting that that does not render on today's larger screens very well. Is that correct? --Izno (talk) 14:33, 19 February 2014 (UTC)[reply]

So you don't like the columns at Lists of cathedrals (for example)? I would think that would be bad on a smartphone (or any small or narrow screen), but it looks okay to me on my laptop.

Or is there a better example of your concern? WhatamIdoing (talk) 15:17, 19 February 2014 (UTC)[reply]

Yes, that's my problem with the use columns. When people use the huge number of columns for size on mobile devices, it's not good for anyone using desktop computers. That's why we need to do something about that problem. BattleshipMan (talk) 17:04, 19 February 2014 (UTC)[reply]

Comment I recommend using {{Div col}} for columns. It allows the number of columns to adjust dynamically based on resolution and text size. Obviously it's a bad idea to hard code the number columns, unless of course it's a table that specifically requires a set number of columns. That cathedral list could easily be reconfigured using Div col and the reader's browser settings would dtermine the number of columns. Betty Logan (talk) 18:02, 19 February 2014 (UTC)[reply]

Let me show you guys thtee diffs on 2014 Winter Olympics. This one here and that one here shows the width of the Participating nations shows the size of it, which is not okay on desktop computers. The one I did here was the one that was originally there before the two diffs I showed you guys. This is why hard code of number of columns and size is an annoyance for anyone using desktop computers and laptops. BattleshipMan (talk) 19:35, 19 February 2014 (UTC)[reply]

You're talking about the tables at 2014_Winter_Olympics#Participating_National_Olympic_Committees?

Let's start with the fact that your column templates are mismatched, so you're accidentally producing invalid HTML. Go read the notes at Template:Multicol about the need to use matching column template families.

I don't like the narrow, fixed-width approach to the second table. What if my screen were narrower than 600px? If you don't want it to be full-width (which I actually liked), then let the table pick its own size.

Secondly, look at the bigger table. Now make your browser window really narrow (or increase your font size a lot). See what a mess you get? Now look at the same table but with this formatting. See how it automagically makes fewer columns to accommodate your shrinking screen width? That's really a better solution. (It could also IMO be improved upon by using the same suggested column widths for both tables, and by making the suggested width be a bit wider than it is.) WhatamIdoing (talk) 23:01, 20 February 2014 (UTC)[reply]

My issues with unnecessary use of columns is that they cause some problems with anyone using desktop computers and such. Sometimes the unnecessary amount of dividing columns on any sub-section and table can annoyed and frustrate many readers using desktop computers, regardless what it does for anyone using mobile devices. The hard code of number of columns can obviously be a bad idea for anyone using desktop computers, which is why someone will have to work on proposal recommend browser settings for anyone using desktop computers and mobile devices to make sure the amount of columns wont cause issues with anyone using desktop computers. BattleshipMan (talk) 22:34, 21 February 2014 (UTC)[reply]

I'm using a desktop computer, too, BattleshipMan. I actually think this problem would be worse for a mobile device.

What you did was hardcode the number of columns. What you took away was a system that dynamically set the number of columns according to how much space there was on the screen.

This is the old system (the one that you took away):

Now look at this table as it would appear on a narrow desktop computer screens (you know, for people who don't own expensive widescreen monitors?):

See how the number of columns automatically changed? There are no longer "too many" columns, because it automagically made fewer columns when it was given less space to display the table in. WhatamIdoing (talk) 23:07, 21 February 2014 (UTC)[reply]

Some people just don't see it that way. The size of columns has always been an issue for desktop computers and mobile device, WhatamIdoing. People need to do something about that problem so it won't be an issue for desktop users and mobile users. BattleshipMan (talk) 23:18, 21 February 2014 (UTC)[reply]

Well, most people see it that way. Static columns present a great problem for small screens, making it near impossible to read. That is the exact reason why template like {{div col}} exist; to have dynamic columns that fit all screens. Please do not remove them again. — Edokter (talk) — 23:48, 21 February 2014 (UTC)[reply]

The problem with dividing columns for larger screens is make it too difficult for them to deal with smaller tables and such. That is why we need to balance columns for larger desktop computers and small screens and this kind of columns isn't the answer. BattleshipMan (talk) 01:00, 22 February 2014 (UTC)[reply]

Let's compare two more, then. Which of these is easier to read?