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)
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)
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)
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)
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.
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. =)
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)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)
{{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)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:
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
Hey folks. I recently stumbled across the fact that there are literally thousands of un-substituted {{ unsigned}}-templates across many namespaces. I've been thinking about BRFA-ing for that, as I've always been interested in doing some mass bot work. Now, I realize that, given that it hasn't been done yet, it is probably not "extremely needed". I'm also aware that we're not supposed to worry about performance. But it certainly couldn't hurt, could it? What to you guys think? Cheers. ~ | twsx | talk cont | ~ 12:36, 21 January 2014 (UTC)
{{
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)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)
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)
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
Instead of the current adrenaline-prompting message --
-- how about if we change to something less martial. Here are some suggestions:
EEng ( talk) 19:40, 20 January 2014 (UTC)
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... Reh man 04:58, 26 January 2014 (UTC)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
I noticed Wikispecies is already wikilinked in its sister Wikimedia project template, but Wikimedia Commons is not. I thought it was non-controversial to suggest this be fixed, but it was deemed I need consensus for it.
Examples on the RHS.
Looking at all the templates that use Sister (you need to manually change to only see Templates) I see it wikilinking the sister site is somewhat inconsistent in general.
Mark Hurd ( talk) 01:53, 2 February 2014 (UTC)
(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)
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:
Thoughts? -- Nick Penguin( contribs) 00:27, 12 February 2014 (UTC)
This page in a nutshell: Wikipedia articles cover notable topics—those that have gained sufficiently significant attention by the world at large and over a period of time, and are not outside the scope of Wikipedia. We consider evidence from reliable and independent sources to gauge this attention. The notability guideline does not determine the content of articles, but only whether the topic may have its own article. |
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)
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)
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)
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)
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)
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)
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)
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:
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)
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)
23:59, 2 February 2014
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)
{{ 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)
I have requested comments from others at /info/en/?search=Talk:Persecution_of_Hindus#Request_for_comments. Please support or oppose the survey going on there.— Khabboos ( talk) 17:16, 24 February 2014 (UTC)
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)
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)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)
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)
This proposal will allow someone visiting //en.wikipedia.org/?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)
[[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)[[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)
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)
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)
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
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
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)
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:
|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)
{{
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)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)
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)
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)
{{{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).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)
|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)
|orphan=
still will.
GoingBatty (
talk) 20:02, 2 January 2014 (UTC)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)
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)
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)
"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 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)
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)
"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.
@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)
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)
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)
.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)@ 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)
display: inherit !important;
as the style you are trying to override in inline. —
Edokter (
talk) — 16:19, 5 February 2014 (UTC)
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.
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)
( ←) 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)
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)
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)
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)
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)
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)
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)
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)
Countries that participated in 2010, but not 2014 | Countries participating in 2014, but did not in 2010 |
---|---|
Countries that participated in 2010, but not 2014 | Countries participating in 2014, but did not in 2010 |
---|---|
Let's compare two more, then. Which of these is easier to read?
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)
Participating National Olympic Committees (number of qualifying athletes) | |||||
---|---|---|---|---|---|
|
|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){{
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.{{
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.{{
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)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)
{{
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)NaBUru, do you really think that three columns is always better? Compare these:
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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.
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. =)
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)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)
{{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)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:
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
Hey folks. I recently stumbled across the fact that there are literally thousands of un-substituted {{ unsigned}}-templates across many namespaces. I've been thinking about BRFA-ing for that, as I've always been interested in doing some mass bot work. Now, I realize that, given that it hasn't been done yet, it is probably not "extremely needed". I'm also aware that we're not supposed to worry about performance. But it certainly couldn't hurt, could it? What to you guys think? Cheers. ~ | twsx | talk cont | ~ 12:36, 21 January 2014 (UTC)
{{
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)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)
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)
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
Instead of the current adrenaline-prompting message --
-- how about if we change to something less martial. Here are some suggestions:
EEng ( talk) 19:40, 20 January 2014 (UTC)
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... Reh man 04:58, 26 January 2014 (UTC)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
I noticed Wikispecies is already wikilinked in its sister Wikimedia project template, but Wikimedia Commons is not. I thought it was non-controversial to suggest this be fixed, but it was deemed I need consensus for it.
Examples on the RHS.
Looking at all the templates that use Sister (you need to manually change to only see Templates) I see it wikilinking the sister site is somewhat inconsistent in general.
Mark Hurd ( talk) 01:53, 2 February 2014 (UTC)
(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)
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:
Thoughts? -- Nick Penguin( contribs) 00:27, 12 February 2014 (UTC)
This page in a nutshell: Wikipedia articles cover notable topics—those that have gained sufficiently significant attention by the world at large and over a period of time, and are not outside the scope of Wikipedia. We consider evidence from reliable and independent sources to gauge this attention. The notability guideline does not determine the content of articles, but only whether the topic may have its own article. |
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)
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)
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)
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)
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)
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)
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)
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:
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)
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)
23:59, 2 February 2014
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)
{{ 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)
I have requested comments from others at /info/en/?search=Talk:Persecution_of_Hindus#Request_for_comments. Please support or oppose the survey going on there.— Khabboos ( talk) 17:16, 24 February 2014 (UTC)
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)
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)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)
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)
This proposal will allow someone visiting //en.wikipedia.org/?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)
[[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)[[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)
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)
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)
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
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
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)
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:
|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)
{{
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)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)
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)
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)
{{{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).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)
|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)
|orphan=
still will.
GoingBatty (
talk) 20:02, 2 January 2014 (UTC)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)
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)
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)
"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 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)
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)
"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.
@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)
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)
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)
.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)@ 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)
display: inherit !important;
as the style you are trying to override in inline. —
Edokter (
talk) — 16:19, 5 February 2014 (UTC)
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.
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)
( ←) 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)
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)
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)
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)
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)
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)
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)
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)
Countries that participated in 2010, but not 2014 | Countries participating in 2014, but did not in 2010 |
---|---|
Countries that participated in 2010, but not 2014 | Countries participating in 2014, but did not in 2010 |
---|---|
Let's compare two more, then. Which of these is easier to read?
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)
Participating National Olympic Committees (number of qualifying athletes) | |||||
---|---|---|---|---|---|
|
|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){{
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.{{
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.{{
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)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)
{{
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)NaBUru, do you really think that three columns is always better? Compare these:
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)
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)
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)
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)
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)
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)