Wikipedia

Wikipedia:Village pump (proposals)/Archive 109

< Wikipedia:Village pump (proposals)

A webpage archiving wikiproject (?) edit

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-restedTalk 06:54, 11 January 2014 (UTC)[reply]
I don't think Lucia is talking about wikipedia pages, but rather things like source pages. VanIsaacWS Vexcontribs 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]

Back to top edit

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]

Technical Outreach at Wikimania 2014 edit

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]

Proposal for a Template Documentation: namespace edit

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
There is a clear consensus against the creation of a separate namespace. Anomie's idea at the bottom seems like it might have gotten traction had it been proposed earlier or more prominently, but right now there is not enough commentary on it for me to issue a formal close one way or the other, so it's "no consensus - needs more discussion". Sven Manguard Wha? 19:56, 14 January 2014 (UTC)[reply]
This proposal is moved from the Idea Lab. That discussion may be found at Wikipedia:Village pump (idea lab)/Archive 12#Proposal for a Template Documentation: namespace. Update this link if it moves!

Any template with even a shard of complexity has a corresponding documentation file... the end result being that AllPages for templates is chock full of /doc, /doc, /doc. For such a ubiquitous feature, I feel that it would be very justified for a new Template Documentation: namespace to contain all of these documentation pages. This way, we could have a clear dichotomy between template code to be transcluded, as opposed to whatever needs to be said or explained about the template (but, of course, not transcluded with the template).

Let's also consider taking the idea a few steps further. By its direct association with an existing Template: namespace, the new TD namespace has potential for some features not usually found in a run-of-the-mill new namespace.

Automatic transclusion
We could make the function of the {{Documentation}} template automatic: a Template: page, requiring no individually-paged code or template to do so, could automatically check for a corresponding Template Documentation: page and display that on the bottom of the Template page, with a little explanatory divider/footer separating the two - explanation similar to the format currently in place on {{Documentation}}. And of course, none of that documentation or divider explanation would be transcluded onto any pages using the Template page. If we did this, it would be very feasible for a fully-developed, fairly complex template, complete with documentation, to use zero includeonlies, and zero noincludes. None of that crap. {{Documentation}} could become a thing of the past.
No documentation exists? "No documentation exists for this template. Click here to write some! <link>"
Special pages
Hard-coded associations between Template: pages and their Template Documentation: pages would enable us to look into additional Special pages: "Special:WithoutDocumentation", et cetera.
Intelligent categories
An infobox template about birds might be in Category:Infobox templates. It might transclude Category:Birds onto host pages which use it. This is logical, but to restrict the application in those ways we need more include rules. Ugly! My understanding is you simply must have include rules to use categories on a template page - because honestly, how often do categories apply to both templates and their host pages?
A better system: we could declare that categories in the Template: page's code would only apply to host pages, while categories one wishes to apply to the Template: page itself are placed in the Template Documentation: page.

I think that this would be a really useful thing to have on Wikipedia, and if it's adequately implemented it opens the door for similar features on other wikis. =)

Support edit

  • As proposer: − Elecbullet (talk) 06:34, 12 December 2013 (UTC)[reply]
  • See no reasons to object thus far; anyone who has worked on templates know how unwieldy the /doc subpage workaround system is for documentation. Not sure how much of this would also apply to Modules though. TeleComNasSprVen (talk • contribs) 07:04, 12 December 2013 (UTC)[reply]
    • I know very little about Modules, in fact I learned they existed in the process of writing this proposal, so I have little ability to comment. I foresee much commentary about how if we can have documentation for user scripts, CSS, modules, et cetera, why should templates have special treatment?
If a decision is made to implement Template Documentation as I have proposed, then (due to the bold-faced features I listed) my meager understanding of the software indicates it would probably require the writing of an extension, rather than just a simple new namespace. I think this extension could very easily have the capacity to work for every kind of namespace, and it could implement a system by which the individual installation selects which namespaces are document-able. So we could enable it for Templates if the consensus is as much, and if it is decided to apply to Modules as well, we could enable it there too. And if someone chooses to install the extension on their own wiki, the webmaster can implement documentation on whichever namespaces they please. Maybe I'm just rambling though. − Elecbullet (talk) 07:33, 12 December 2013 (UTC)[reply]
As in something like a new super-namespace in the hierarchy? Like Documentation: Documentation\Template: Documentation\Modules: etc... (Well for now I mean we should just concentrate on Template Documentation: )TeleComNasSprVen (talk • contribs) 07:38, 12 December 2013 (UTC)[reply]
Modules could already use such a system by changing MediaWiki:scribunto-doc-page-name if the target namespace existed. And if I were to implement such a thing more generically I'd do it along the lines of MediaWiki:ns10-doc-page-name. Personally, I'd recommend a pattern along the lines of "Documentation:Template:Foo" and "Documentation:Module:Foo" for a documentation namespace. Anomie⚔ 12:56, 12 December 2013 (UTC)[reply]
That honestly sounds really great. An administrator here suggested to me a master "Documentation:" namespace, which I kinda brushed aside 'cause I never thought of it like that.
Maybe that would be a better way to go about it. − Elecbullet (talk) 17:52, 12 December 2013 (UTC)[reply]
Going one step further, I note we already have a "Help" namespace, and both Special:PrefixIndex/Help:Template: and Special:PrefixIndex/Help:Module: are empty. OTOH, Patrick87 does have a good point below about /doc subpages matching with /sandbox and /testcases subpages. Anomie⚔ 19:48, 12 December 2013 (UTC)[reply]
Help: was mentioned in Idea Lab. I thought that it would be wise to keep generic, wide-scoped help pages like "Help:Editing" distinguished from specific, definitively page-associated documentation like "Template:Infobox bird/doc", which is why I didn't much like the idea of extending the use of Help. − Elecbullet (talk) 02:52, 14 December 2013 (UTC)[reply]
  • Support, although the technical details need to be discussed and ironed out first. The namespace could have the same relationship to Template: space as the Template talk: namespace has, or it could be a new Documentation namespace, where identically-named Template, Module, and perhaps MediaWiki pages would automatically tie to -- similar to the way edit notices are handled. There should be a discussion on the pros and cons of each. equazcion → 02:38, 13 Dec 2013 (UTC)
Part of me thinks that a master Documentation namespace with "Documentation:Template:Infobox" as name format would be best. But part of me thinks also that if that were the case, why would it not be at "Talk:Template:Infobox" too?
It seems that everyone seems to agree that the basic idea of segregating template documentation in some more intelligent manner is a good idea - if I interpret his message correctly, even the fellow under "oppose" (but feel free to correct me). If we can move toward that goal in some form or fashion I think it'd be really good. − Elecbullet (talk) 22:15, 13 December 2013 (UTC)[reply]
  • Support the spirit of the proposal. It would be nice it there were a simple, obvious, 1-click way to add documentation to a template. I'd support the idea of asking the foundationy/experty types for their advice on how to implement an improvement in the workflow. Maybe they'll say namespace, maybe they'll say gadget. But Elecbullet is making a useful point here. --HectorMoffet (talk) 04:49, 2 January 2014 (UTC)[reply]

Oppose edit

  • Support the idea behind it, but oppose the proposed implementation. A new namespace for everything (I still have the whole "Draft" NS discussion in mind) will clutter up the UI to a point were it becomes impractical and it will definitely not improve clarity, especially for beginners. A documentation page is a fixed part of a template and should therefore be a subpage of it (I love logical hierarchical structures were appropriate!). The same goes for template sandboxes and everything else linked to the template.
TL;DR: I would favor an implementation similar to WP:Editnotices. – as long as it is technically feasible. {{Documentation}} offers some functionality that would probably need some thought to carry over to the proposed system. Other projects have much more sophisticated documentation templates, e.g. commons:Template:Documentation which automatically creates WP:TemplateData, takes care of translations and much more. All this has to be considered and made available, too, which I currently have no idea how it could be done in a clear and easy way (without recreating the same problem - that this proposal aims to avoid - again) --Patrick87 (talk) 09:20, 12 December 2013 (UTC)[reply]
  • This seems pointless when there is already a help: namespace for documentation. Graeme Bartlett (talk) 11:25, 14 December 2013 (UTC)[reply]
  • Help: is very broad when it comes to Wikipedia, and covers mainly How to Write X (where X = article, redirect, portal, etc), How to Join the Education Program, How to Use the Watchlist, How to File a Username Change, in short how to use Wikipedia's front end. This namespace is used to document the code or the backend for the MediaWiki software among other things. (And then the really really far backend of this is on mediawiki.org) Sort of like when Help: was split from Wikipedia: as a namespace. I'll still take Help: into consideration as another place for documentation. TeleComNasSprVen (talk • contribs) 11:51, 14 December 2013 (UTC)[reply]
  • Oppose we don't need another namespace. Documentation works fine the way it is. This is a solution in search of a problem. -- Ross Hill • Talk • Need Help? • 17:00, 15 December 2013 (UTC)[reply]
  • Oppose The reasons for this are unconvincing. /doc pages represent only 5% of the template namespace. What is preventing AllPages from being an effective way to search through templates is the fact that we have half a million templates, making an alphabetical list an inefficient way of searching. Not having to use noinclude to transclude the documentation seems like a pretty trivial benefit, when you consider the tens of thousands of pagemoves and edits it will require to implement this. We could already do things like Special:WithoutDocumentation as a database report. You will still need include rules for categories to avoid categorizing the template itself in article categories. Saying that categories on the template page don't apply to the template is confusing and would require even more thousands of edits to create documentation pages for the thousands of templates that are categorized, but undocumented. As I mentioned, only around 5% of templates have a /doc page, but 90% have at least 1 category. Mr.Z-man 18:05, 15 December 2013 (UTC)[reply]
  • Oppose. The benefits do not even come close to the cost in time; energy; resources; effort; etc. to implement this. GenQuest "Talk to Me" 18:10, 15 December 2013 (UTC)[reply]
  • Oppose. This should be implemented properly as a MediaWiki extension, if it is to be done at all. — This, that and the other (talk) 06:31, 16 December 2013 (UTC)[reply]
  • Well I'd imagined that anything beyond a simple addition of a namespace would require as much. I figured that if the great Wikipedia showed interest in a system, an extension would soon follow. − Elecbullet (talk) 08:21, 16 December 2013 (UTC)[reply]
  • Oppose. While I could see some advantage to it, it seems to be a huge cost in maintenance and conversion, for very little gain, and it introduces rules that bring in a whole new set of issues with common documentation pages. It ain't broke, so why are we trying to fix it? VanIsaacWS Vexcontribs 06:42, 16 December 2013 (UTC)[reply]
  • Oppose per Patrick87. I think the idea of moving documentation transclusion out of community edited templates and into something supported by mw is valuable. It likely doesn't need to be a namespace, but we should push toward hand-rolling less of the template infrastructure as time goes on. Protonk (talk) 18:05, 16 December 2013 (UTC)[reply]
  • Oppose the method, but Support the desire to make it easier to manage template documentation. Is this something that could be done with a template that automatically transcludes the documentation page "Foo Template/doc" within "Foo Template"? I agree that the whole include/noinclude syntax is a bit daunting for moderately experienced article editors who are trying to figure out how templates work and how to improve their function or documentation. I also agree with the proposer that it should be easier to add missing documentation to a template. – Jonesey95 (talk) 16:07, 19 December 2013 (UTC)[reply]
  • Oppose – per Ross Hill. United States Man (talk) 02:17, 21 December 2013 (UTC)[reply]
  • Oppose – per above. — MusikAnimal talk 00:37, 30 December 2013 (UTC)[reply]

Comment edit

− Elecbullet (talk) 06:39, 12 December 2013 (UTC)[reply]
Similar things have been mentioned in other sections. An outline of proposals put forth:
  1. Template:Foo/doc (unchanged, ofc)
  2. Template documentation:Foo
  3. Documentation:Template:Foo
  4. Help:Template:Foo
Of the four, I am afraid that I must see #4 as the least desirable, because I think that the Help: namespace, which is currently reserved for broad subjects such as Help:Editing, does so very well, but would not do well to be mixed with individual-page-specific documentation such as "Template:Infobox/doc". I honestly don't know if I would prefer that over no change at all. − Elecbullet (talk) 06:34, 15 December 2013 (UTC)[reply]
  • I note there are really two separate issues here: (1) Automatically transcluding documentation (which could do /doc subpages) like in the Module namespace, and (2) a separate namespace for documentation. Anomie⚔ 20:01, 15 December 2013 (UTC)[reply]
    When you put it that way, simply having /doc be auto-transcluded without a new namespace really doesn't seem like a terrifically bad option. If we could find a way to move toward that it would be very good. − Elecbullet (talk) 03:49, 23 December 2013 (UTC)[reply]
    I think we have a winner for the technical implementation in Anomie's proposal. It seems most people agree that template documentation has room for improvement, but namespace isn't quite the right tool for the job. Auto-transclusion of a /doc subpage looks like the perfect tool for the job. --HectorMoffet (talk) 05:00, 2 January 2014 (UTC)[reply]
    I agree, Anomie's proposal is the winner here. We don't need to make a new namespace when we can simply auto-transclude a /doc subpage. On a side note, this solution seems so simple that I have to wonder how we didn't think of it before now. Novusuna talk 19:50, 3 January 2014 (UTC)[reply]
Brilliant, elegant, acceptable. Motion to close as 'problem solved' --NickPenguin(contribs) 20:16, 3 January 2014 (UTC)[reply]
  • Anomie's solution would also help small wikis, as they would get /doc support without all the template infrastructure that is currently required. \o/ John Vandenberg (chat) 11:26, 8 January 2014 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

How to make all the proposals from now on get more attention edit

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]
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 seeks renewal (please comment) edit

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]

Wikipedia Visiting Scholar (please apply now) edit

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]

Possible proposal to redirect people searching for Java edit

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]

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]

Topicon DYK edit

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]

Allow user preferences in References section edit

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]

Fully protect closed AFDs, MFDs, RFAs, etc edit

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.--JohnBlackburnewordsdeeds 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]

Pending Changes for large amounts of text insertion edit

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]

Have WikiProjects give a list of all articles that are part of that WikiProject edit

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]

Random Article on Google Android App edit

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]

Handling new article submissions edit

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]

Substituting {{unsigned}} templates edit

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 | talkcont | ~ 12:36, 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]

Increasing visibility of full protection edit

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? VanIsaacWS Vexcontribs 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]
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]

RfC: Should article feedback be restricted to articles? edit

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]

Integrating QR Code with Each article and with Wikipedia Android app edit

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]

A Modest Proposal edit

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]

Mentioned time in my timezone edit

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]

The Wikipedia Adventure, new page patrol edit

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?

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]

Strike UKrViki and support Ukraine edit

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]

Make in possible to show a preview in the Teahouse edit

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]

One-click install for userscripts edit

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

CHU requests from users who have RfA page(s), etc. edit

  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]

Userpage deletion permission edit

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]

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

User contributions and list size edit

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]

Limit creation of talk pages to logged-in accounts edit

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. VanIsaacWS Vexcontribs 06:48, 6 February 2014 (UTC)[reply]

Proposal to move stats.grok.se to Wikimedia Labs edit

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]

diffs in signatures edit

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]

Live feed for submissions at Articles for Creation edit

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]

Wikimedia Commons wikilinked in templates edit

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.

 
Wikimedia Commons has media related to Village pump (proposals)/Archive 109.
 
Wikispecies has information related to Village pump (proposals)/Archive 109.

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. OhanaUnitedTalk 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]
 
Wikimedia Commons has media related to Cats.
  • 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. Monty845 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]

Do you think Wikipedia/Wikisource should have a Kindle (.mobi) putout? edit

(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. VanIsaacWS Vexcontribs 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]

Proposal to create page listing all nutshells edit

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

Front page idea: Trending topics? edit

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]

Cite errors: add namespaces edit

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]

Protest proposal edit

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]

Wikipedia head is now floating! edit

 
FloatHead on Flower article

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 in Category:Sports by year edit

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]

Android Nearby edit

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]

Open letter from EFF, Demand Progress on re-opening Wikipedia:Surveillance awareness day edit

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

Add multiple pages to your watchlist at once edit

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]

Reimplementing functionality to tag articles with Template:Non-free review edit

{{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]

Talk:Persecution_of_Hindus#Request_for_comments edit

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]

Proposed new Archive namespace edit

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]

RfC: should the templates in Category:Redirect templates be modified now that the text is rendered on redirect pages. edit

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]

Discussion edit

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

Using Wiki for Political Discussion and Change edit

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]

Have a list of all project pages edit

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]

Organize Sections better edit

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]

Polling edit

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

On Orphan tags again edit

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

There is no consensus to overturn the previous consensus. I believe, though, that this RfC was started in good faith and that no disruption was envisaged or intended by the initiator. There may be some merit in some of the other proposals tacked onto the end of this RfC, but these have not been sufficiently discussed here or a consensus to emerge. HJ Mitchell | Penny for your thoughts? 20:24, 3 February 2014 (UTC)[reply]

This is a followup discussion to the earlier discussion at #Proposal to move the Orphan tags to the talk page.

I apologise for missing the discussion above and the Request for Comment but I would like to give some arguments that oppose the move to the talk page. Before starting I would like also to note that I am ready to follow any consensus reached. I already filled a BRFA in case the consensus reached is finally implemented.

So, I start:

  1. The main argument on moving the orphan tag is a general argument against all tags and has already failed many times. SeeWikipedia:Perennial_proposals#Move_maintenance_tags_to_talk_pages
  2. Distinguishing editors from readers is completely out of the idea I have for Wikipedia. Wikipedia is the encyclopaedia everyone can edit. Every reader is a potential editor. We should encourage readers to become editors. Tags promote the idea of editing. Almost all Wikipedia articles are incomplete and need expansion.
  3. Connectivity between pages is a big deal. We should rely on the fact that an article is searchable via the Search engine. We should connect articles between each other. In the past the Russian Wikipedia went a step further and checked for articles only linking from one to each other with no other connections. We should not want dead ends in Wikipedia. Reading is an endless adventure.
  4. 120,000 pages with no incoming links, not even from lists of pages is an issue. Not a small issue. Think that from these lists we xclude disambiguation pages, SIAs etc etc.
  5. Things are getting better. That things are stale is a myth. Per progress described in Category:Orphaned articles: In January 2013, there were 175,000 orphan articles and in November 121,725 articles. 50,000 less. everytime there was some effort to reduce the list we had results. If we exclude pages with 1 or 2 incomings links from the list things may be much better. In the past we were very strict about it. Now maybe it is time switch a bit and remove tags if there is at least 1 incoming link. -- Magioladitis (talk) 11:37, 23 December 2013 (UTC)[reply]
A Bad Boy Can Be Good For a Girl, A Fort of Nine Towers, Aachen penny of Charlemagne, Abaareey, ABC Cinema, Wakefield, Abdol Ghadar, Abdul Wali Khan University Mardan, Abhay Gohil, Gerardo Ablaza, and Michael Abraham (chemist)
I could only link three. I linked Abdul Wali Khan University Mardan in Mardan. I also removed the tag on Gerardo Ablaza since he had been linked already. I linked A Fort of Nine Towers in And the Mountains Echoed, since both books are mentioned as being reviewed in one of the references of the latter. I won't contest it if it is reverted. Three out of ten, and all of them could only be linked once (which I think still makes them orphans, but I removed the tags anyway). The seven will retain their orphan tags indefinitely.-- OBSIDIAN†SOUL 16:33, 23 December 2013 (UTC)[reply]
Not indefinitely. Until Wikipedia is expanded further enough. Now I am running against all articles and checking they are already linked by other pages. Still 60,000 pages to check. -- Magioladitis (talk) 17:07, 23 December 2013 (UTC)[reply]
@Magioladitis: Yesterday I ran BattyBot over all articles tagged as orphans and removed hundreds of tags. I check the current month's articles almost daily. GoingBatty (talk) 19:04, 23 December 2013 (UTC)[reply]
@GoingBatty: and then why I did these today: [4], [5], [6], [7] and more... -- Magioladitis (talk) 19:12, 23 December 2013 (UTC)[reply]
@Magioladitis:
1 & 4 - My bot runs autotagging and then skips any articles that still contain "orphan" - these contains "orphan" in the text.
2 - Link was added yesterday from Phalia
3 - Unknown, but glad you're finding them. GoingBatty (talk) 19:28, 23 December 2013 (UTC)[reply]
Nope. Indefinitely. We have 58,662 orphans from 2006 to 2010. These are articles which had the tag for 3 to 7 years. That's 1.3% of our total number of articles. It's very clear from that alone, that readers either don't know how to fix them, or don't care to fix them. Fixing orphans are the concern of experienced editors not drive-by readers. They're the only ones with enough know-how to do it properly. All of you here who support retaining the tag as is are bot, tool, or script users. Even without the tag, you can still accomplish these tasks. But you are not anymore the average reader, and to equate yourselves with them is a mistake.-- OBSIDIAN†SOUL 00:11, 24 December 2013 (UTC)[reply]
Additionally, saying "Until Wikipedia is expanded further enough" is basically saying it can't be fixed. That's counter-intuitive to the purpose of maintenance tags. What's the use of those tags on top of the article urging everyone to fix the orphan status if it can't be fixed anyway? And it's not the minority either. That was 7 out of 10 that couldn't be fixed. It will just waste everyone's time every time they attempt to de-orphan it, only to find out they can't.-- OBSIDIAN†SOUL 01:39, 24 December 2013 (UTC)[reply]
@Obsidian Soul: Just curious why you didn't add |att=December 2013 to the seven articles you could not deorphan, which hides the article message box. GoingBatty (talk) 04:14, 25 December 2013 (UTC)[reply]
Because like our regular readers, I had no idea that I could or should hide the tags for undeorphanable files that way. It is not mentioned in the template itself. And even if it was (which would make the template even larger and more alarming than it already is), I doubt a regular reader would actually understand how to add that properly or think they have the "rights" to. The only people who know that attribute and use it, are those who do dedicated maintenance work, and they don't need the tag to tell them it's an orphan. They usually access the orphan list through the category directly.-- OBSIDIAN†SOUL 05:18, 25 December 2013 (UTC)[reply]
  • Oppose as original proposer of previous discussion.
  1. The previous proposal explicitly only applies to orphan tags. I have no problems with other maintenance templates (except when people are tagbombing to make a point). As pointed out, the assumption that there is a preexisting consensus not to move maintenance templates is not based on anything other than they were first implemented that way in the first place.
  2. Wikipedia's primary goal is to educate, not to turn everyone into Wikipedia editors. While we should encourage new editors as much as possible, we should never lose sight of the fact that we are an encyclopedia, not the borg collective. We are meant to be read first, edited second. Otherwise we might as well just display Wikipedia as an etherpad in permanent edit mode.
  3. Not everything can be connected. Much less connected two to three times. Several subjects (e.g. taxon articles) already had to explicitly be excluded from being orphan-tagged because of their highly-specialized nature. There are other articles like that that can't be categorized as easily, but are nonetheless similarly unlinkable to more than one other article (or none at all) even though they are undoubtedly notable. For example: non-western notable people, places, ideas, or organizations. Or companies and products even, where adding it to other articles would constitute spamming. And while they may not have incoming links, they would usually still have outgoing links, thus still fulfilling part of the connectivity requirement. To put it in analogy: when you're solving a jigsaw puzzle, you will always find instances of difficult pieces which do not fit yet or can only be slotted to one other piece. And the best way to solve that is not to force them to fit, but to find other easier pieces to work on until you eventually link up with it.
  4. It's a minor issue because it does not concern our readers. Again, most readers arrive through the topic through search engines, not by clicking on a link from another article. They can still find the article very easily if they wanted to.
  5. The fact that more orphans remain than are fixed seems indicative that a fair amount of them are permanent members of the category. As in they can't be linked yet or at all, unless someone forcefully adds it on See alsos of vaguely related articles. And I don't see that as ideal either.-- OBSIDIAN†SOUL 12:32, 23 December 2013 (UTC)[reply]
  • I have argued a few times to create a "page tags" extension to MediaWiki, which would make maintenance tags (and maybe WikiProject banners and things like {{ArticleHistory}}) out-of-band (separately displayed and separately editable from article content, possibly with different permissions). And by the way, it would render this whole discussion moot, since everyone could choose to hide or show tags wherever they want, as they please. Keφr 13:52, 23 December 2013 (UTC)[reply]
  • Support Keeping all of the tags on the same page. Considering the technical in-feasibility of fragmenting the tags with some on the article page or some on the talk page, it jut does not seem sensible to do so. Twinkle, AWB, AFCH, and some other scripts/tools are all having difficulties accomplishing this because it requires adding an entire new section to the code and quite frankly it's not worth it. Let's not pad a bunch of editors edit counts to fragment the maintenance tags, seems entirely counter productive. You don't like the way the tag looks on the articles page, we can change the way it looks without getting rid of it. Technical 13 (talk) 17:47, 23 December 2013 (UTC)[reply]
  • Here's my thinking:
    1. The main argument on moving the orphan tag is that it's about a problem on a different page. No amount of editing Orphan is going to de-orphan it. You have to edit some other page. I support reducing the prominence of this particular tag (e.g., moving, hiding, or re-sizing it). I do not support doing this for any other tag.
    2. I agree that every reader is a potential editor. Let's focus them on tasks that can be achieved by editing the article they're reading.
    3. I agree that we should not want dead ends in Wikipedia—but orphans are not {{dead end}} articles.
    4. I agree that having 120,000 pages with no incoming links is an issue. Maybe, in addition to manually de-orphaning some, we should be looking at whether all of these articles actually belong here. We had a spate of spam-articles about Alaskan dermatologists a couple of years ago. How many of them really belong here? Do you realistically think that we can de-orphan every single article about every single dermatologist that paid someone to create an article, without creating something silly like a "List of Alaskan dermatologists"?
    5. I agree that things are getting better, but this doesn't imply that we need these tags to be the first thing that the reader sees on the page. Things can still get better even if the orphan tag is moved to the bottom and made small like a {{stub}} tag, or moved to the talk page, or turned into a hidden maintenance category. WhatamIdoing (talk) 18:29, 23 December 2013 (UTC)[reply]
Comment I'm more likely to attempt to deorphan an article if I see the tag. Moving the tag to the talk page makes it less likely that I'll see it, which means I'm less likely to attempt deorphaning. GoingBatty (talk) 19:32, 23 December 2013 (UTC)[reply]
Note that the broader consensus of the previous discussion was to move it somewhere other than at the top of the article where it breaks article layout and is the first thing that the readers see. It doesn't necessarily have to be the talk page. A hidden category on the same page or somewhere at the bottom like {{Uncategorized}} or {{Stub}} were all proposed as alternatives. All of those are functionally fine, and editors have no problem sorting through them and fixing them.-- OBSIDIAN†SOUL 01:52, 24 December 2013 (UTC)[reply]
  • Comment if we switch the minimum links to deorphan from 3 to 2 I believe many pages will be detagged with us making no extra effort. -- Magioladitis (talk) 22:32, 31 December 2013 (UTC)[reply]
  • Oppose Compare Wikipedia:WikiProject Medicine/RFC on medical disclaimer. The current orphan banner is absurdly WP:UNDUE when compared to our disclaimers which are buried at the foot of the page. I'm not too fussy how it is made inconspicuous but if I can still see it then it's going onto the talk page. Andrew (talk) 19:14, 3 January 2014 (UTC)[reply]
  • Move for an immediate close of this RfC as it is disruptive (see below) -- PBS (talk) 12:50, 6 January 2014 (UTC)[reply]
  • Oppose. The only argument I see here with any level of merit is the fact that some of our automated tools would require recoding. That, however, is not a justifiable reason to overturn the original consensus. It would set a very dangerous precedent to accept that consensus should be set aside for the convenience of the people who maintain the tools. As to the original comment: 1. "Past proposals failed, therefore we should treat this one as failed even though it succeeded." Uhh, no. 2. Citation needed. 3. Agreed, but I've seen no evidence that the existence of orphan tags causes people to clear them on any noticeable scale. Especially from new editors. 4. Appeal to emotion that fails to rebut the original consensus. 5. "Every time there was some effort to reduce the list we had results" - implies that some editors have dedicated some time to dealing with the issue. I commend and thank these editors, but I also know they weren't finding orphaned articles by hitting "Random Article". Ergo, the existence of the Orphan template in mainspace is not driving reduction efforts. Resolute 14:49, 6 January 2014 (UTC)[reply]

Oppose overturning the recent RfC. The proposer's arguments don't convince me. Argument 1, that the Orphan tag is like other tags, isn't true: it's not. Argument 2, that the Orphan tag is particularly good, or even any good, at getting readers into editing, is arguable. My guess is that it's probably mostly not true, but nobody knows for sure. Arguments 3, 4, and 5 are all addressed by having the tag continue to exist, but on the talk page. Against that is the argument that won the day at the original RfC: it's a big honken ugly thing that degrades the article's appearance, degrades the reader's experience, and warns the reader of nothing useful, all for little benefit. However, I'm all for a clean RfC on the question of whether the tag should appear on the talk page or just be invisible altogether. Herostratus (talk) 21:32, 6 January 2014 (UTC)[reply]

Proposal: Delete template, turn into hidden category edit

Here's an idea: Why don't we just delete the template and turn it into a hidden category. I do agree that the template itself can incite panic in new users, but moving it to the talk page helps no one if you can't see it. If you want to do maintenance in this category under the above proposal, you either have to be a user with a sophisticated understanding of how categories work (surprisingly, this is less common than most people think), or you give up because you have no idea where the template went. How about we just delete the template itself and replace it with hidden categories, so that way it can be seen on the user page, and we won't have a maintenance template appearing on a talk page. Kevin Rutherford (talk) 07:11, 24 December 2013 (UTC)[reply]

I have no problems with that. A fair amount (most?) of deorphanings are done naturally over time as more articles are created that start linking to them anyway.-- OBSIDIAN†SOUL 05:23, 25 December 2013 (UTC)[reply]
  • This makes sense to me. Putting the tag on the talkpage makes even less sense than putting it on the article page. Like others, I have also tried to de-orphan an article on seeing that tag. After all, I want to help. But it's a difficult and frustrating task that leaves me dissatisfied. As a temptation to turn readers into editors it is more likely to achieve the opposite. A reader taking up the challenge would equally find it difficult and frustrating, and from that experience may decide not to bother editing Wikipedia again. May even spread the bad news among friends and colleagues: "I tried to help out on Wikipedia once. Wasted an hour of my life and achieved nothing. Editing Wikipedia is for weird geeks who don't have a life". SilkTork ✔Tea time 16:05, 3 January 2014 (UTC)[reply]
I agree, this solution is brilliant, is inline with the perennial concensus about maintenance tags on the talk page, and should be acceptable to all sides. I can think of no reason not to do this. --NickPenguin(contribs) 19:27, 3 January 2014 (UTC)[reply]
Support. 90+% of de-orphaning work is done through scripts and bots these days. There is no reason for a glaring notice at the top of each page, especially when at least half of these articles are impossible to de-orphan. Kaldari (talk) 08:10, 4 January 2014 (UTC)[reply]
@Kaldari: I'm aware of bots that remove {{orphan}} from articles that have already been de-orphaned. Could you please give an example of a bot that actually does the de-orphaning work? Thanks! GoingBatty (talk) 00:27, 5 January 2014 (UTC)[reply]
I guess I was thinking of the bots that remove the tag. It looks like you're correct that these don't actually perform the de-orphaning. Oh well, guess you can ignore my comment then :) Kaldari (talk) 00:41, 5 January 2014 (UTC)[reply]
I wonder how much of the de-orphaning is done by people using the "suggestions may be available" script that's is linked in the template that we're now hiding.... GoingBatty (talk) 01:22, 5 January 2014 (UTC)[reply]

Alternate idea? edit

Moving the orphan tag is an inelegant and needlessly complicated process upon which the validation and ultimate removal becomes unworkable. An alternate and better option is to remove the banner portion of the template and make it function like Template:Coord missing. The end result allows direct and no-mess tagging of orphaned articles and resolves the issue of those supporting the talk page move. I personally did not know about the RFC or would have commented - others have come to the same conclusion, but were also unaware. I believe that this resolves both parties issues with a more optimal solution in terms of those who place, check and remove the tags. To put it bluntly: The tag is gone from view and the banner won't choke the talk page where validating and removing won't occur. ChrisGualtieri (talk) 06:03, 28 December 2013 (UTC)[reply]

Question: With your suggestion, would {{orphan}} still reside within {{multiple issues}}, or be moved somewhere else? If moved, where would it reside? Thanks! GoingBatty (talk) 06:13, 28 December 2013 (UTC)[reply]
It would no longer be a banner, the most simple solution is to make it a hidden category and that would mean it would no longer be in {{multiple issues}} unless specifically requested. At this time, I think making it completely hidden is justified given the RFC, it would still be functional and check-able like any other tracking category. ChrisGualtieri (talk) 06:24, 28 December 2013 (UTC)[reply]
I understand that the solution proposed here is to remove the visible banner. My question relates to the code that editors use. If it would no longer be in {{multiple issues}} unless specifically requested (by whom?), where should editors add {{orphan}} in the page layout in the future? GoingBatty (talk) 18:16, 2 January 2014 (UTC)[reply]
  • I would prefer to have the banner hidden if only tag on the page, otherwise it should be inside the multiple issues and display a one line note. this is very technically feasible and seems like common sense to me. Technical 13 (talk) 21:50, 28 December 2013 (UTC)[reply]
  • Technical 13, I like this idea. -- Magioladitis (talk) 22:35, 31 December 2013 (UTC)[reply]
  • This idea also sounds good to me. Ramaksoud2000 (Talk to me) 06:47, 1 January 2014 (UTC)[reply]
  • Piling on to say that I like the sound of this. Novusuna talk 07:58, 1 January 2014 (UTC)[reply]
  • This is a great idea. I'll reiterate that the original proposal to move Orphan Tags to the Talk Page is a bad, bad idea. While we're at it, are there any other maintenance tags—that are not needed to be announced to every reader—that should be considered as well? (May help cleanup the article pages somewhat.) Just a thought. GenQuest "Talk to Me" 08:17, 1 January 2014 (UTC)[reply]
  • Support this, which I feel doesn't violate the spirit of the original consensus. Sorry these great technical minds were late to join the party (better late than never!), the idea that the orphan patrol can use a custom MyPage skin to still see the template is the missing piece to the puzzle that should keep it easy for the orphan patrol to still use Find link and make everyone happy (except those who want to encourage readers to become editors by fixing orphans, but that ship has already sailed). – Wbm1058 (talk) 21:34, 2 January 2014 (UTC)[reply]
  • Okay then... What I am thinking is to wrap the meta "issues" template (haven't dug in to see what it is yet) in a span with an id of whatever the calling issue is (in this case id="orphan"). The next step is to add a style="display: none;" to the span conditionally based on if:{{{hidden}}}|true. This will give us the option to add |hidden=true to the orphan template (or whatever other templates we deem it would be appropriate to hide by default) which will hide it from normal view and those users that still want to see that notice can simply add some code to their common.css or skin.css like #orphan{display: inherit !important;} which will override the fact that the tag is hidden for that specific user. Everyone okay with this? Technical 13 (talk) 23:16, 1 January 2014 (UTC)[reply]
Okay, based on Mr. Stradivarius's suggestions, I've made some changes to {{Orphan/sandbox}} with examples on the testcases page. If no-one sees anything I missed there, this will be moved live in about three days. For those that wish to override the hidden nature, all you need to do is add the following to your common.css or skin.css: 
.orphan{
    display: inherit !important;
}

I hope this satisfies what everyone wants without having to make a mess out of trying to move it to the talk page. Technical 13 (talk) 13:50, 2 January 2014 (UTC)[reply]

If I recall chances to templates with a large set of transclusions won't pull through the changes until the update pass has happened or an edit (Even a null edit) has occured on the page. Therefore I'd like to suggest that a null edit bot be attached and set free over the Category:Orphaned articles category and it's children so that the nag disappears sooner rather than later. Hasteur (talk) 14:36, 2 January 2014 (UTC)[reply]
It would still get run through the job queue like any other change, but that could in fact take weeks depending on how far down the queue it is. I wouldn't oppose a null bot running through the list, perhaps a ping to Joe Decker for his insight on running his Joe's Null Bot through it (yes, I know you can make a null bot for it too Hasteur, just getting another opinion on it.)? Technical 13 (talk) 14:54, 2 January 2014 (UTC)[reply]
It appears that this solution would take care of articles that use the {{orphan}} template. Would this solution mean that we also need to convert any {{multiple issues}} templates with the old |orphan= parameter to the {{orphan}} template (and potentially relocate it to another part of the article)? Thanks! GoingBatty (talk) 18:16, 2 January 2014 (UTC)[reply]
@GoingBatty: I though the consensus was to leave the Orphan template in the multiple issues wrapper so that if there were multiple issues, we'd draw attention to it. i.e. Not the primary cause for failure, but contributing to the failure. Hasteur (talk) 19:52, 2 January 2014 (UTC)[reply]
@Hasteur: I'm not sure what the consensus is, so I'm asking. Note that I've updated Template:Orphan/testcases to show the difference between how the proposed {{orphan}} template does NOT appear within {{multiple issues}}, but the old style |orphan= still will. GoingBatty (talk) 20:02, 2 January 2014 (UTC)[reply]
@Technical 13: BattyBot 19 was approved to change the old style parameters to the new style ONLY when the old style was not displayed properly. GoingBatty (talk) 20:02, 2 January 2014 (UTC)[reply]
@GoingBatty: I read the consensus proposed at 21:50, 28 December 2013 by Technical 13, and then endorsed and agreed to below that post. Personally, I like that methodology myself. Hasteur (talk) 20:09, 2 January 2014 (UTC)[reply]
{{Multiple issues}} is one of those templates that is way overcomplicated and I have had the time to sort through and figure out how it works internally yet. Perhaps Theopolisme (who has written a Lua version of the template) or Mr. Stradivarius can help figure out why it doesn't show inside of Multiple issues? Technical 13 (talk) 21:28, 2 January 2014 (UTC)[reply]
@Technical 13: In general, when an template is inside {{multiple issues}}, it displays the first sentence of the template text. Getting {{orphan}} to show nothing when on its own but a sentence when inside {{multiple issues}} will be new functionality. GoingBatty (talk) 23:34, 2 January 2014 (UTC)[reply]
See Template talk:Orphan#Is it possible to have the functionality provided in the Toolbox? for a description of how {{orphan}} behaves inside {{multiple issues}}, where a shorter message is displayed. Wbm1058 (talk) 00:28, 3 January 2014 (UTC)[reply]
Looking at this more closely, it looks like we might need a new rule in MediaWiki:Common.css to make this work. The current {{multiple issues}} magic happens by using the class hide-when-compact in all {{ambox}} text fields except |issue=. This class is defined in common.css. However, to do what is being proposed here we would need to do the opposite, i.e. show text only when it is compact. Perhaps propose this on MediaWiki talk:Common.css? — Mr. Stradivarius ♪ talk ♪ 03:42, 3 January 2014 (UTC)[reply]
And interesting technical point, if this is a barrier to its implementation then perhaps its resolution will result in a net positive because it could be extended to more or less the same type of tags in the future. This is definitely a more complex way to resolve the problem, but it does stand to be better than merely hiding it altogether - hide when compact is that functionality that seems like a great idea. ChrisGualtieri (talk) 13:42, 6 January 2014 (UTC)[reply]
  • So far I see no discussion about this at MediaWiki talk:Common.css. Given that the wolves are demanding action and not foot-dragging, and the idea of keeping the message visible inside the {{multiple issues}} wrapper is the piece of this that might still be contentious and arguably against the spirit of the earlier consensus, can we just implement the solution that always hides the message? We can always revisit making it visible inside the wrapper later. Only downside I see is if there are only two issues, readers will just see one, leaving them wondering, "so what's the other issue?" - Wbm1058 (talk) 18:18, 6 January 2014 (UTC)[reply]
  • Question. What's wrong with having the tag on the talk page? I haven't seen any compelling argument to that effect, except that it uglifies the talk page (so what, since it's useful) and that no one will see it (but even fewer people see it if it's not there, right?). Putting the page in a hidden category and also tagging the talk page would be OK with me, though. As to the original statement of this section, I actually can't even figure out what it means. "Moving the orphan tag is an inelegant and needlessly complicated process upon which the validation and ultimate removal becomes unworkable." Sorry, but what?. It looks like the sentence is talking about the actual process of moving the tags, which is relatively trivial I assume and I don't understand why it would be impossible to validate that this had been done properly? Herostratus (talk) 21:48, 6 January 2014 (UTC)[reply]
  • To answer your question, all of the tools and applications that editors currently use to place the tag are unable to place the tag on the talk page (it would take a LOT of coding to be able to edit two pages instead of one for this, and is technically infeasible). This means that requiring this tag to be on the talk page instead of just hidden is essentially forcing the tag into deletion which was strongly against consensus in the discussion. Technical 13 (talk) 22:02, 6 January 2014 (UTC)[reply]
Oh. Well, in that case, hmmmm. This seems odd to to me, since there are templates on talk page -- lots of them. So there must me some way place to templates there. I mean, it seems like an elementary thing -- you already know the name of the page, and the name of the talk page is very similar, the variance following a regular pattern. And I think it's possible to write to a page you're not editing, since various actions do that -- for instance, putting a speedy tag on a page (with Twinkle) writes a message to a user talk page. Are you sure you've drilled all the way down on this?
But if it's the case that this can't be done, it is what it is and we have to move forward from there. I'd be leery of being driven too much by the technology. Heck, the tools are just conveniences). I put tons of templates on pages by hand for years. It's not that hard, so I wouldn't worry about it too much. There are tables to look these things up and it's a simple copy-and-paste operation. And anyway if these tools are that limited in how they can be configured to meet our needs, another good reason for not paying them too much mind.
Again, if the case can be made and accepted that the Orphan tag ought not be on talk pages, that's different. But I haven't seen that case made very well.
So I think we need to talk and think about this some more. One thing that comes to mind right off is allow the tools to operate as they do and just run [Wikipedia:Bots/Requests for approval/Yobot 23 Yobot 23] regularly; that'd solve the problem I guess. But this might degrade system performance, don't know. Another would be have the tools place the article in a hidden category, and have (as a separate thing) the visible Orphan tag remain as a talk page to be added by hand, if it really can't be automated. Probably there are other ways to deal with this.
There's no hurry. It might be good to run a clean RfC with the two best options presented as binary choice, but I don't think we're there yet. Herostratus (talk) 01:07, 7 January 2014 (UTC)[reply]
Your comparison is in the right direction, but for the wrong reason. When you put a speedy tag on a talk page to notify the user who created, you are doing a task with a very specific purpose. This is a notification and its a one-shot. The orphan tag on a page needs to meet a certain criteria to be applied (checked by AWB and some other tools including the AFC helper script). The article itself is checked, and if it was forced on the talk page, the talk page would receive the tag. This, by itself, is not too helpful, but possible. The real issue comes in knowing when the issue has been resolved - an AWB or other person who goes to the page will automatically check and remove the tag in the process of doing any other task. This will not be done if its on the talk page and to load up the talk page and load up the article to check would be a much more confusing and complex operation that is technically infeasible and inefficient. Completely hiding or having its concealment for editors who do not "opt in" is a great option, because it allows those who use the tools and do the tasks to resolve the orphan tag issue without loading up the talk page and flipping back, confirming on the article and re-loading the talk page to do the task. Or the other option would be load the talk page to check for the orphan and then the article itself, just to resolve this one issue... it creates more problems than it resolves and Coord missing is something with the exact same functionality and is a precedent that works. This is demonstrated and functional and it resolves the main issue - I don't think such an objection to forcing the talk pages to take the banner represents a net positive. ChrisGualtieri (talk) 18:29, 7 January 2014 (UTC)[reply]

This rfC is disruptive edit

The RfC that is now archived Wikipedia:Village pump (proposals)/Archive 108#Proposal to move the Orphan tags to the talk page, came to a clear consensus which was summed up by the closing admin. The alternative options being discussed here were discussed at the time and did not gain a consensus. To start another RfC over this issue so soon after a consensus was reached is disruptive. -- PBS (talk)

  • Considering multiple people called for it be hidden or given reduced notice in the original RFC, this is actually addressing the very concerns that were not fully explored. It became clear when preparing to do the actual letter of the consensus that it was infeasible for many more reasons. The spirit of it is being preserved and it will accomplish the original intended result in a far better way than discussed in the original RFC. ChrisGualtieri (talk) 13:47, 6 January 2014 (UTC)[reply]
  • It is quite feasible to implement it as the consensus dictated. Which concerns were "not fully explored"? "actual letter of the consensus that it was infeasible for many more reasons" what are those reasons? -- PBS (talk) 14:19, 6 January 2014 (UTC)[reply]
  • If you read the later comments closely, most support the removing of the banner, but ambivalent as to where it ends up, either category only on bottom of the article or on the talk page. My comment of "Oppose the move to talk page, Support hiding it away someway. From many years of doing maintenance backlog and tracking some of the progress, very little maintenance happens by drive by editors. Almost all happens by project or individual drives to clean out a cleanup cat. Whatever we do, the category must remain on the page, so that tools like the svick tool pick them up and catscan can be used to sort them. Moving the tag to the talk page just adds an unnecessary complexity to the sorting tasks - and will be a big task to do, compared to simply changing the contents of the {{orphan}} template. The-Pope (talk) 07:36, 30 November 2013 (UTC)" was supported by the RFC originator, but coming two weeks into the voting period, I doubt many others would have read it (TL:DR). If there are real technical issues with doing a move, rather than a template appearance change, then it is very valid to revisit it with the current knowledge. The-Pope (talk) 16:12, 6 January 2014 (UTC)[reply]
For the record, I'm the closer of that discussion (I'm not an admin by the way) and I support this alternative idea, it even cropped up in the first discussion, but it came too late, and there wasn't a consensus at the time. Ramaksoud2000 (Talk to me) 22:32, 6 January 2014 (UTC)[reply]

I agree that technical means to hide the orphan tag on the main page would satisfy the spirit of the consensus. Our process isn't a legislative one, and closures are not usually meant to be literally binding except in extreme cases. PBS, if you have good reasons to prefer the original solution, you should just raise those for everyone to consider, rather than raising a procedural objection. Gigs (talk) 17:03, 6 January 2014 (UTC)[reply]

"The alternative options being discussed here were discussed at the time" is not true. The currently favored solution to hide the template message, but to allow overriding the hidden nature by adding specific text to your common.css or skin.css (anyone on orphan patrol will want to do this) is a key  B idea that was not brought up in the original discussion and will make the largest possible number of editors happy. To suggest otherwise is to imply that consensus would want to move {{coord missing}} to the talk page because editors, not readers, find it disruptive. Wbm1058 (talk) 17:51, 6 January 2014 (UTC)[reply]

It's not disruptive IMO. If you look at the previous RfC, the concern of most all of the commentors was getting the ugly thing off the article pages. The idea that having it on the talk page as a positive good did not really come into play. So this is a refinement that's reasonable to discuss. Herostratus (talk) 21:39, 6 January 2014 (UTC)[reply]

OK, I see some concern from editors who (1) don't want to see anything on the article page, (2) want to help with de-orphaning, (3) don't want to install the custom skin that would show them the template message, so (4) need to be able to see the message on the talk page, so they can help de-orphan. Sorry, I'm dubious about the idea that tagging the talk pages will increase de-orphaning, but this issue is easily solved by just asking the bot that was going to move tags to the talk page to copy them there instead, where they could display a talk page version of the message and would not be categorized. – Wbm1058 (talk) 22:18, 6 January 2014 (UTC)[reply]
This bot would need to run on a regular basis to pick up the new ones. Wbm1058 (talk) 22:24, 6 January 2014 (UTC)[reply]
  • I would be opposed to replicating the tag on talk pages as redundant, disruptive, and unecessary. I would be more than happy to make a simple script that those people could import into their css/js in addition to it also placing the pages in a category that they could use to find orphans. I'm still working on the technical aspects of hiding the template and making it show in multiple issues... I'll work on it at the end of the week as I have a final in sociology to get done this week (a really weak subject for me). Technical 13 (talk) 23:12, 6 January 2014 (UTC)[reply]
    • I agree with you, T-13. I neglected to mention above that such theoretical editors wanting to fix orphans also refuse to check Category:Orphaned articles as that's too much bother, as well as opting in to see the message is too much bother. But, somehow, checking the talk page isn't too much bother, in spite of the fact that after checking the talk page they will need to return to the article to run "what links here" and they won't be taking advantage of the tool that's built into the visible template unless they go out of their way to do so. And we are supposed to assume that such theoretical editors are so numerous as to outweigh the burden on those using the cat, opting in to see the template, using the tools... having to make a special trip to edit the talk page to remove the template, which is totally unnecessary except to fulfill the needs of theoretical editors. Sorry if I'm sounding harsh, but I'm a little annoyed that this argument continues. Wbm1058 (talk) 19:17, 7 January 2014 (UTC)[reply]
  • The issue is not "theoretical editors", but simply the common practice that the eventual resolution without tag removal is not a small minority. I often remove orphan tags with AWB and I also PLACE them with AWB. Moving it to the talk page means I'd have to stop and load up the talk page to place it (a function AWB does not have) and I'd have to check the talk page to see if I could remove the orphan tag (assuming one needs to). I'll run a operation this weekend (its been awhile since I last did the task) and show why the technical matter warrants this. It has never been about checking a category - it is part of the upkeep and maintenance of Wikipedia itself. The matter of "seeing" the tag has been secondary to me because I need the actual ability to detect, check and remove the tag all at once. And the result of moving it to the talk page splits the detect, check and removal up in two minimum edits and results in lots of needless reloading and processing. ChrisGualtieri (talk) 17:14, 8 January 2014 (UTC)[reply]
I do see what you guys are saying. But: going back to the very top of this section (not this subsection), you see an editor initiating this discussion (on the grounds of Hold on, we haven't discussed this enough), and she is an Old Believer -- she wants the tags to remain on the article page.(Her second point is "Distinguishing editors from readers is completely out of the idea I have for Wikipedia. Wikipedia is the encyclopaedia everyone can edit. Every reader is a potential editor. We should encourage readers to become editors. Tags promote the idea of editing...".) In the original RfC and earlier discussions, a not insignificant number of editors adhered to that view.
So we have rump minority holding that view. They have lost their point, and I think they're wrong but not unreasonable. It's a good idea to compromise to acommodate minority views, when possible, I would say. Moving the tag to the talk page rather than deleting it from view altogether is a way to do that. So I think we should keep thinking about a way to do that. Herostratus (talk) 13:19, 10 January 2014 (UTC)[reply]
  • You've acknowledged the point that some of us (including me) have made. Yes, there was a consensus to not have this tag viewed by default on article pages, the majority of people that supported that wanted them moved to the talk page, this was what the RfC was closed as for consensus. However, what was not introduced into that RfC was the fact that this is technically impossible within reasonable limits to accomplish as many of the tools (userscripts, gadgets, bots, other programs) would have to open and edit two pages instead of one and that is more trouble than it is worth to code. According to the count in All orphaned articles the {{Orphan}}, the tag is on 59,226 pages and according to Template:Orphan's transclusion count transcluded on 123,169 pages. That is a lot of needless busy work some editor would have to do to move them by hand, and would create more work for editors that want to de-orphan pages, as they would now have to visit an extra page. Hidden by default on the article page if it is the only tag and categorized was also supported by consensus by all that felt something needed to be changed about this tag, and I think that is the correct path to now follow. Technical 13 (talk) 16:10, 10 January 2014 (UTC)[reply]
Well hmmmm. How about this: would it be possible to end up with a situation where:
  1. The current {{Orphan}} tag is made invisible on the page, and Category:Orphaned articles becomes a hidden category, AND
  2. There is a new template created -- let's call it {{OrphanForTalkPages}} or whatever, which populates a category called Category:Orphaned articles (via talk page tag) or whatever -- which looks much like the current Orphan tag?
Is that possible? Surely that's possible?
And then the people responsible for maintaining the tools can do whatever they think best. I gather that the code for placing the (newly made invisible) {{Orphan}} tag and populating Category:Orphaned articles would remain in place. If the people who maintain the tools want to figure out some way to add some interface with {{OrphanForTalkPages}} and Category:Orphaned articles (via talk page tag) to their tools, fine, but apparently this is not reasonably possible, so then {{OrphanForTalkPages}} remains something that is listed in the lists of templates and is only put on by hand, which means it won't be used too much I guess.
I would suppose that someone might be interested in the intersection of Category:Orphaned articles and Category:Orphaned articles (via talk page tag), and I guess someone could handle this is some manner, by some sort of query, or maybe by having a master category Category:All orphaned articles of which the other two categories are subcategories. Or something like that. Is that possible? (Ideally for parallelity we would rename Category:Orphaned articles to something like Category:Orphaned articles (via tool) and similarly rename the {{Orphan}} tag, but not if it's a big hassle.)
The question then would be whether the bot -- Yobot 23 or whatever -- moves the tags to the talk page and populates Category:Orphaned articles (via talk page tag) or not. One thing to consider here is the political angle, in that (as seems likely) there is a general hue and cry of "What the heck happened to my Orphan tags" the answer "Moved to the talk page!" might play better than "Invisibilized them!".
Another question is what about articles that for whatever reason end up in both Category:Orphaned articles and Category:Orphaned articles (via talk page tag). My guess is that this is not a huge deal although not optimal and perhaps can be handled by a bot that runs on now and again, or by a human, or just shrugged off.
And there may be other repercussions that I'm not thinking of, of course. So anyway, is this possible? Herostratus (talk) 16:24, 11 January 2014 (UTC)[reply]
It is most certainly "possible" to create a second set of templates/categories that would run in parallel to the existing set, but this would be a redundant nightmare to maintain and keep in sync. A better solution is those that want to see it on the talk page instead of the article page use a gadget or userscript that detects that the template is on the article and displays it on the talk page instead. The actual code would still be on the article page, which would make it a little harder to remove (unless a special link inside the display was added by the script displaying the information to remove the tag). This gadget could even be the default so that all users see it on the talk page, unless you turned that gadget off. Technical 13 (talk) 18:37, 11 January 2014 (UTC)[reply]
FYI, Category:Orphaned articles is already a hidden category, as are the categories that appear on the articles themselves: Category:All orphaned articles and monthly categories such as Category:Orphaned articles from January 2014‎. GoingBatty (talk) 18:41, 11 January 2014 (UTC)[reply]
Using a gadget or userscript is not going to happen for the vast majority of our readers. The vast majority of our readers do not have accounts, and I'm sure are unaware of the existence of gadgets and userscripts. So I don't see this as too helpful. So then how about this. Let's run a clean RfC saying something like this: The Orphan template is not going to be visible on the article talk pages anymore. That's been decided. There are two mutually exclusive ways to implement this. Vote for the one you prefer:
  1. The {{Orphan}} tag continues as before, except it is not visible to readers. Category:Orphaned articles continues to exist, and the {tl|Orphan}} tag may be still be placed and removed by tools by automated tools such as Twinkle, as before.
  2. The {{Orphan}} tag remains visible to readers, but is moved to the talk page. Category:Orphaned articles will continue to exist, but will consist only of talk pages. For complicated technical reasons, Twinkle and other automated tools will not be able to place and remove the {{Orphan}} tag or interface usefully with Category:Orphaned articles, and the option to place the {{Orphan}} tag will have to be removed from the automated tools. All placing and removal of the {{Orphan}} tag and maintenance associated with Category:Orphaned articles will have to be done by hand in future. (Or however it should be phrased; not sure if I have that right.)
Or something like that. I'd be reluctant to run this RfC until we're sure we've exhausted all reasonably possible alternatives. RfC's like this run best when there's a binary option, and we're going to get some number of "Neither, keep on article page" for starters, and we're sure to get some number of "Neither, instead do both" and "Neither, instead do such-and-such" and so on, so I want to be sure that such-and-such can be easily disposed of, at least. It may well be (probably is) that Option 1 up there is the better option and if that's true hopefully the arguments for it will win the day, although I don't want to just assume that either. And if it does we'll be much better off if we can point to a clear decision if and when people start wondering what happened to the tag. There's no hurry if there's more to think about, but if and when there's not, how about a clean RfC along those lines? Herostratus (talk) 21:42, 11 January 2014 (UTC)[reply]
That is the beauty of javascript and gadgets, they can be loaded by default for all users so user do not have to log in or know anything about them or how they work for them to do their job. Those that don't like the look will be able to simply disable them for themselves (if they have an account). The tags can not go directly on the talk pages, it is technically not possible to do. Saying they have to go on the talk page essentially kills the entire orphan project and there is no consensus for that. The tags themselves have to go on the article page, but they don't have to display there. Technical 13 (talk) 02:40, 12 January 2014 (UTC)[reply]
Well, if they're locked in by default such that the tag appears by default, then the tag appears for the great majority of our readers, and so nothing has been accomplished. Getting an account and futzing with javascript or even clicking to enable gadgets is not in the cards for most of our readers.
I know that tags can be placed on talk pages and that talk pages can be in categories, such as {{WikiProject Biography}} and Category:Unassessed biography articles and many others. I've always assumed that a talk page category such as Category:Unassessed biography articles has some use to someone in some way, otherwise they would not exist.
So you're telling me that {{WikiProject Biography}} and Category:Unassessed biography articles have some use and value but that {{Orphan}} and Category:Orphaned articles would, if moved to talk pages, have no value, and no reasonable amount of computer sciencey effort expended on the problem could cause them to have value. This seems... kind of magical...
But OK. I accept that. I grant that. So fine.
So then the question is over two competing claims to primacy:
  1. The needs of the orphanage project, and
  2. The desire to engage the general readership in dealing with orphaned articles, albeit in significantly reduced way since the tag is now only on talk pages.
Thinking about this, for my part, in the case of orphaned articles, I'm willing to concede that the needs of the orphanage project probably do have primacy. I don't know that for sure, and to some extent it's a matter of opinion and can't be proved. But for my part I withdraw my objection to leaving the Orphan tag on the article pages and just making it invisible.
I'm not too happy about that, since we are then moving the problem of orphaned articles entirely (instead of just mostly) into the realm of "let the relevant group of experienced and interested editors handle this, step aside please" and away from the purview of the general readership, which is a getting a little bit away from the general approach we take here.
However, it's been pointed out and accepted that there's not really a whole lot that the general reader can usually do about orphanage, especially if the "find links" button comes up blank. Which is a good part of the reason the visible Orphan tag is being removed from the article pages. So in this case it might be better to leave it to the orphan project. (And BTW thank you guys for your service in this useful task; sorry to be obstreperous.)
I say I remove my personal objection and for my part will cease disputing the matter. Others might feel differently though, and although I'm not going to do this I strongly recommend that you guys run a clean RfC along these lines:
It's been accepted that the Orphan tag will no longer appear visibly on article pages. For the purposes of this RfC consider that a given and off the table. However, the original solution was to move the tag to the article talk pages. Further consideration has revealed that this would make it impossible for the orphanage project to use the tag, for technical reasons. We are thus presented with two choices. Please state your preference.
  1. Move the Orphan tag to the talk pages, where it will be visible (although only to readers who access the talk page), and shut down the orphanage project.
  2. Keep the tag on article pages, but invisible, and allow the orphanage project to continue as before.
And be prepared to explain the technical problem clearly and succinctly, and to argue cogently why keeping the orphanage project is the better choice. I'd probably vote for #2 and I think most editors will also and so you'll be good to go, everyone will be satisfied, and you'll be protected from future sniping over the matter. And if not, then not. But if you chose not to run an RfC like this, better be prepared for some backlash. Herostratus (talk) 05:19, 12 January 2014 (UTC)[reply]


@Gigs if you read the original debate I gave detailed reasons for moving to the talk page. If you need me to link to provide links to those reasons, I can do so.

@Technical 13 "I would be opposed to replicating the tag on talk pages as redundant, disruptive, and unecessary." talk pages are for editor to editor communications, article space is for information about the subject of the article. The agreement was to remove the template from article space, so there is no "replicating the tag on talk pages".

Nothing I have seen in this section to date, changes the fact that "To start another RfC over this issue so soon after a consensus was reached is disruptive". -- PBS (talk) 10:35, 11 January 2014 (UTC)[reply]

It might well have been disruptive as first posted, but anyway the discussion has shifted, the original poster's concern has fallen off the table, and we are now having a lively and useful discussion about how to best implement the intent of the previous RfC in light of new information re technical limitations. I wouldn't worry about it. Herostratus (talk) 16:24, 11 January 2014 (UTC)[reply]
Of all of the proposed solutions to this problem, the least disruptive to the existing system, and the simplest to implement (besides, of course, changing nothing) is simply moving the orphan tag to the bottom of the article with the no-categories tag. The two are often worked on at the same time, and wouldn't interfere with the reading of the article. Also, if some of the automated processes which had not yet been updated were to continue putting the tag at the top because they hadn't been updated, it wouldn't be a big deal, whereas if some totally different process for identifying orphans began to be used, these processed would all have to be found and fixed right away. —Anne Delong (talk) 04:29, 12 January 2014 (UTC)[reply]
It does not matter much where on the article page it is, as long as it is on that page directly... I'm still working on the modifications to the lua module itself to make the template hidden by default. I'm not very good with lua yet, and this is a fairly abstract template to be learning on. I've recruited what assistance I can, but it is slow going. Technical 13 (talk) 05:08, 12 January 2014 (UTC)[reply]

This rfC is not disruptive edit

  • I disagree that the "RFC" was disruptive, the talk on the AWB page showed multiple concerned editors over the technical implementation and work are the people who regularly clean up and manage the Orphan tags. Technical13 has worked his butt off for Wikipedia and the hidden aspect of the orphan tag was not solely my idea, another user proposed it independently and it was agreed by several others before returning to this. The discussion resulted in a clear option that resulted in the same effect (no orphan warnings on the article page) and several other editors agreed that it was the intention and spirit of the original RFC. We are having a lively debate about it, but few of us can implement either of these changes and Technical 13 seems to be the only one to do so. If it were so simple as blindly following the RFC, I could do the 100,000 articles by hand or if someone with a bot did it, but the fact it broke every method and way of checking and fixing the orphans showed that it was a net negative instead of a net positive. The coord missing tag (which is invisible to readers) was the most elegant and proper solution I found that represented the least amount of work to implement. And I think we all owe Technical 13 a big thank you for working on the ultimate solution for so long. ChrisGualtieri (talk) 15:38, 15 January 2014 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Continuation on orphan tags edit

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]
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}}:
  • 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]

Find a way to have almost all comments on article feedback pages get resolved or marked as not useful. edit

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]

other Wikipedia languages section edit

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]

MOS:TM proposed changes edit

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]

Show what links to a reference edit

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]

RfC to mark WP:ER as historical edit

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]

Issue with the use of Columns edit

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):
Countries that participated in 2010, but not 2014 Countries participating in 2014, but did not in 2010
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?):
Countries that participated in 2010, but not 2014 Countries participating in 2014, but did not in 2010
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?

Participating National Olympic Committees (number of qualifying athletes)
Participating National Olympic Committees (number of qualifying athletes)

On my screen, one is a four-column unreadable mess, and the other is two neat, wide columns. What do you see? WhatamIdoing (talk) 02:54, 22 February 2014 (UTC)[reply]

Well, the number one is a not readable for sure. The second is very neat as well. BattleshipMan (talk) 03:06, 22 February 2014 (UTC)[reply]
There you have it then. The unreadable mess is your method, the second table is using adaptive columns, which changes the number of column according to the available space on the screen. — Edokter (talk) — 03:14, 22 February 2014 (UTC)[reply]
Hey, man. That was uncalled for on what you said to me. That wasn't my idea, nor I came up with the mess with the other tables on that page. These columns at times can cause problems with larger desktop computers, regardless of what others might say. So cut that kind of attitude with me, alright. BattleshipMan (talk) 06:10, 22 February 2014 (UTC)[reply]
  • Let's compare two more, then. Which of these, based on a "normal" 800×600 screen resolution with a 186px sidebar (I measured it) is easier to read?
Participating National Olympic Committees (number of qualifying athletes)
Participating National Olympic Committees (number of qualifying athletes)
  • I'd say the difference between the two is minimal and honestly, the top one looks better when I view it on my Android Galaxy Axiom's screen in desktop mode (800x480 pixel WVGA resolution). — {{U|Technical 13}} (t • e • c) 04:06, 22 February 2014 (UTC)[reply]
    • Hmm...I like the bottom one since just about almost every country is listed without jamming up space like some of the countries with larger names on the top table. BattleshipMan (talk) 06:16, 22 February 2014 (UTC)[reply]
      • Guess what? The one you like better is the method that you took away. It's okay; everyone knows that you wouldn't have done that, except that you just didn't know about all of the dozens of permutations possible here. That's why we work together, with people who have different computers as well as different skills.  
        I don't like cramming lists into narrow columns, either. But the way to make sure that nobody has them crammed into narrow columns (not just that it looks okay on my own computer) is to use {{div col|colwidth=15em}} instead of a fixed number of columns (with the {{multicol}} template). And if you find someone using the proper div col system, and it still feels crowded, then you increase the "colwidth" amount, rather than replacing the whole system. "15em" means (at the absolute minimum) "the size needed to type 'mmmmmmmmmmmmmmm'" (15 copies of the letter m). So if that seems crowded on a page (there are some people who really like to cram it in...), then you just change the div col template to a larger number of "ems", so it says |colwidth=17em, or whatever is needed. Edokter has already fixed this table. You should feel free to adjust the "ems" if you think it needs it. WhatamIdoing (talk) 22:24, 22 February 2014 (UTC)[reply]
There is another issue here: accessibility. If you use a technique like {{Div col}}/{{Div col end}} (as seen at Wikipedia:Meetup/UK#London which does it through the redirects {{colbegin}}/{{colend}}), all of the columns form one single list. But if you use a technique where the breaks between columns are hard-coded - such as with the {{Col-break}} and {{Multicol-break}} templates - what happens is that instead of a single list, there are several: one for each column. This causes screen reader software to announce multiple lists when only one was intended.
There is a known downside to {{Div col}}/{{Div col end}}: it doesn't work with Internet Explorer 9 or earlier, for exactly the same reason that multi-column {{reflist}} don't work with IE9 and earlier. Instead, the columnisation is ignored, and it all displays as a single column.
But whichever technique is used, please don't mix templates from different groups. That is, {{col-begin}} goes with {{col-break}} and {{col-end}}; {{multicol}} goes with {{multicol-break}} and {{multicol-end}}. Mixing them will cause an imbalance in the number of open <div>, <table> and other structures. Some of the examples above do mix the groups, which might have contributed to the difficulties. Also please don't omit the appropriate closing marker - {{div col end}}, {{col-end}} or {{multicol-end}} - and none of these are equivalent to the table end marker |}, so that shouldn't be used as a shorthand for any of them. --Redrose64 (talk) 23:44, 22 February 2014 (UTC)[reply]

Folks, I don't understand your points of view. I think that any list should never use more than 3 columns. --NaBUru38 (talk) 18:19, 25 February 2014 (UTC)[reply]

Here's another reason not to mix {{multicol}} with {{Col-break}} and to use the appropriate end marker: if you do mix them up, it breaks the TOC in mobile view. See Wikipedia:Village pump (technical)/Archive 123#The table of contents problem in mobile version. --Redrose64 (talk) 10:29, 26 February 2014 (UTC)[reply]

NaBUru, do you really think that three columns is always better? Compare these:

  • a
  • b
  • c
  • a
  • b
  • c
  • a
  • b
  • c
  • a
  • b
  • c
  • a
  • b
  • c
  • a
  • b
  • c
  • a
  • b
  • c
  • a
  • b
  • c

versus this:

Imagine that second one on a really wide screen. Would that really be easier for everyone to read? I think those second two columns would just get lost. WhatamIdoing (talk) 21:54, 26 February 2014 (UTC)[reply]

I don't really know what to think about that. But I do think the second one is better for desktop users. We need to set up a consensus regarding size of columns for desktop users and mobile users for balance reasons. BattleshipMan (talk) 01:03, 27 February 2014 (UTC)[reply]
If you do not know what is better for people with really wide computer screens, then you do not know what is best for desktop users. Really wide screen = always a desktop user. A computer screen that is three feet (one meter) wide is not "mobile" in any meaningful sense. WhatamIdoing (talk) 16:31, 27 February 2014 (UTC)[reply]

Move Pending Changes dropdown in header 20 pixels to the left edit

Currently, the Pending Changes dropdown sits 80 pixels from the right of the page in the Vector skin, and 55 pixels in the Monobook skin. (Other skins currently don't specify its position at all and/or don't support these types of icons.) I propose changing this to 100 pixels in the Vector skin and 75 in the Monobook skin to make room for additional protection icons. Currently, it doesn't leave enough room for all of the possible icons, so some pages require a decision on which icon to display. With this change, all valid combinations of icons will be able to be displayed on any page. This doesn't seem to me to be controversial, so I'm going to request it to be implemented in a few days unless there is any objection. Jackmcbarn (talk) 19:50, 25 February 2014 (UTC)[reply]

  • Strong support, as one of the participants in the discussion upon which this proposal came. — {{U|Technical 13}} (t • e • c) 21:09, 25 February 2014 (UTC)[reply]
  • Since there's been no opposition in 6 days, I've submitted the edit requests. Jackmcbarn (talk) 21:34, 3 March 2014 (UTC)[reply]

Keeping additional information helpful for extracting data (e.g. from list) within Wiki articles edit

Hi all, we are currently thinking about parsing lists and tables within Wikipedia to extract the information. Well it turns out that this is a really difficult task. The only feasible solution seems to be to keep some extra information, e.g. in List_of_Nazi_concentration_camps column one is the "name as article URL", 5th column is a date range, 6th column is a number signifying "estimated total number of prisoners during the complete in use time (5th column)". What do you think is the best place to keep such information? Maybe a subpage List_of_Nazi_concentration_camps/data ? or an invisible template/comment? What do you think? This could be a GSoC project for DBpedia [8] SebastianHellmann (talk) 15:08, 4 March 2014 (UTC)[reply]

ah yes, before I forget. this is the current state. Here is the query that gets geocordinates of all concentration camps [9] . Auschwitz is missing. With the additional information we could improve the results of the DBpedia database a lot in terms of precision and coverage SebastianHellmann (talk) 15:14, 4 March 2014 (UTC)[reply]

Proposal to have a bot delete stale warnings from after certain period of time edit

As you know, Wikipedia is a non-profit organization. Therefore, it relies on the donations from the public. There are a lot of IP addresses that have been used for vandalism and they get warned. Once certain period of time passes by, the warnings become stale and unfortunately, stale warnings take up a lot of space. It costs money to obtain and manage additional storage space. When I am patrolling Recent Changes, I notice that some IP talk pages have lots of stale warnings, some from as early as 2006. Likewise, there are times where I deleted stale warnings in a single talk page and deleted more than 50,000 bytes of stale warnings.

What I am suggesting is that Wikipedia should have a bot that detects old warnings from, maybe, like at least 1-2 months old, and delete them. If the {{OW}} tag isn't tagged, then this bot should tag it as well. This way, the space saved by deleting stale warnings can be used to generate useful articles.

Human editors may not have a lot of time manually deleting stale warnings from old IP talk pages, even if they do try. Just like how vandalism is very common and ClueBot is here to revert vandalism and warn the users, which would reduce the amount of human editors needed to fight vandalism.

If you have any questions about my thoughts about this bot, please feel free to contact me. NHRHS2010 RIP M.H. (1994-2014) 16:34, 1 March 2014 (UTC)[reply]

It may be a good idea to have a bot remove stale warnings but your point about storage space is actually working against your argument. As Wikipedia keeps a copy of every version of every page, making a change to a page would actually take up more space as both versions would be stored. Also, the WMF has never indicated storage space is an issue. --NeilN talk to me 16:46, 1 March 2014 (UTC)[reply]
That's great that Wikipedia never had an issue with storage space as I never heard of such issue. However, either way I still think that IP talk pages should be cleaned from time to time. Maybe human editors who patrol Recent Changes and warn vandals, should be encouraged to remove stale warnings. This practice can also allow vandals to see new warnings more clearly. NHRHS2010 RIP M.H. (1994-2014) 16:55, 1 March 2014 (UTC)[reply]
Another note is that back when I first joined Wikipedia in 2007, I remember indef blocked accounts got tagged with {{indefblockeduser}} a lot more commonly than these days. After a certain period of time, administrators would delete these old indef blocked users' pages (such as ST47 deleting a userpage with the summary "Temporary page, too old"). NHRHS2010 RIP M.H. (1994-2014) 16:59, 1 March 2014 (UTC)[reply]
How do you define stale? As far as I am concerned every warning is a further clue to the prior performance of an account or IP and should be retained indef. Leaky Caldron 17:02, 1 March 2014 (UTC)[reply]
They are retained indef in the talk page history. I don't see the point of displaying warnings from 2010 if the IP hasn't edited during the interval. --NeilN talk to me 17:09, 1 March 2014 (UTC)[reply]
  • (edit conflict) NHRHS2010, the best person to answer your concern about storage space is likely Reedy, and I'll leave that at that (he only seems to be checking that account once a week, so his reply may be slow). As for your other suggestion that those talk pages should be cleared from time to time, I agree on a case to case basis. What I mean by that, is there are some IP talk pages with no comments on them for multiple years, and the warnings on them may be harsh and likely no longer apply to whomever may next use that page. I have no problem with such pages being deleted per consensus at a MfD discussion, nor do I have any objection to those talk pages simply being blanked by a bot after a year of inactivity on the talk page if the IP hasn't been defined as any of a set of special cases (School IP, IP of a known sock, otherwise tagged by CU, etc) because this leaves the content available in the page history for anyone who really wants to know. Such blanked pages should also be placed in a maint cat so that people will know that is why it is blank and think to check the history. — {{U|Technical 13}} (t • e • c) 17:19, 1 March 2014 (UTC)[reply]
Note: Wikipedia:Don't worry about performance may be applicable to this proposal as well... — {{U|Technical 13}} (t • e • c) 17:30, 1 March 2014 (UTC)[reply]

No I'm not concerned about storage space. I am just trying to give suggestions that would be supportive to Wikipedia, the free encyclopedia that anyone can edit. Of course, we will continue to expect people to vandalize due to our freedom to edit. Though I have noticed some preventative measures (such as disallowing curse words, the word "poop"...). I have even witnessed my one best friend vandalize (and at least once I have personally reverted his edits without his knowledge). Wikipedia is not my own website, and we are just contributors. Also, like I mentioned before, I would tag {{OW}} on IP talk pages where the stale warnings were removed, regardless of whether it is personal or shared IP. The OW tag actually reads "Older warnings and/or other comments on this page have been removed, but are still viewable in the page history." whereas the word "page history" is linked to the page history of the IP talk page. Alternatively {{old IP warnings top}} have been placed on top of stale warnings while {{old IP warnings bottom}} have been placed under the last old/stale warning in order to hide the stale warnings (where people can click on the Show button to see the hidden warnings). NHRHS2010 RIP M.H. (1994-2014) 18:17, 1 March 2014 (UTC)[reply]

There may be some legitimate reasons to remove warnings from talk pages of dynamic IPs, but disc space or other WP:PERFormance issues should not among those reasons. Besides, editing a page to remove stale warnings doesn't decrease the size of the database, but increases it instead when the revision is saved. If you simply want to remove the clutter on a talk page, archiving would be a better option. 24.149.117.220 (talk) 21:40, 1 March 2014 (UTC)[reply]
Though rather than traditional archiving, for cleaning up the warnings on a dynamic IP's talk page, it's more appropriate to collapse the warnings with the {{Old IP warnings top/bottom}} templates. Which, as NHRHS2010 sorta suggested, could maybe be done by a bot. Certainly, there could be benefits both to IP users and patrollers to cleaning up very old warnings, particularly for dynamic IP addresses and school IP addresses where the current user of the IP is unlikely to be the person the warnings were for. Novusuna talk 22:01, 1 March 2014 (UTC)[reply]
I think that it is preferable to delete stale warnings altogether, and replace them with the {{OW}} tag. This reduces unnecessary link load in the "What links here" space. For example, if you look at a randomly picked article like Banana, you will see that there are literally dozens, if not hundreds, of IP addresses from which it is linked. Many of them are nothing more than this eight-year-old warning, basically saying "your edit to Banana was reverted". Putting the warnings in a collapsed template conceals them on the IP page, but retains this clutter on the "what links here" page for any article mentioned, as well as to the various policy pages that are routinely linked in such warnings. bd2412 T 17:38, 6 March 2014 (UTC)[reply]

Wikipedia:WikiProject Articles for creation/RfC for AfC reviewer permission implementation edit

This proposal has been around quite a bit longer than 30 days. Is this where I should report it for possible closure? —Anne Delong (talk) 19:47, 6 March 2014 (UTC)[reply]

I think the right place to request closure is here, but that page has such a monstrous backlog at the moment that this notice on the village pump might work faster. Novusuna talk 20:42, 6 March 2014 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_109&oldid=1151047918"