Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:VPPRO)
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  

New ideas and proposals are discussed here. Before submitting:

« Older discussions, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138
Centralized discussion
Proposals: policy other Discussions Ideas

For a listing of ongoing discussions, see the dashboard.

Renaming Category:WikiProject Infoboxes[edit]

I just want to alert people that there is currently a proposal at CFD for renaming Category:WikiProject Infoboxes to Category:Wikipedia infoboxes [1]. Personally, I have opposed this, as this is obviously a maintenance category. I don't understand the rationale behind the proposal. ---Steve Quinn (talk) 18:04, 15 January 2017‎ (UTC)

RfC: Linking to details regarding the offline Medical Wikipedia app[edit]

The offline app allows you to download all of Wikipedia's medical articles in an app to access them when you have no Internet.
Wikipedia's health care articles can be viewed offline with the Medical Wikipedia app.

Should we allow a {{sister project}} style sidebar, i.e. Template:Offline in the form of {{offline|med}}, to be placed within the external links section of medical articles for the purpose of promoting Wikipedia:WikiProject Medicine/App? — Godsy (TALKCONT) 17:36, 29 March 2017 (UTC)


  • Support Prior discussion here. Part of our efforts include "giving free access to the sum of all human knowledge" to all people. This should not be restricted to just when people have a functional Internet connection (something those in the developed world take for granted). Part of our work is to improve access to knowledge in the language of people's choice and in formats that they can use. For many of those in the developing world Internet access is only avaliable for a couple of hours a day or only when they visit larger urban centers. Offline content address these limitation. We know our online content struggles to reach those in the developing world. Our offline medical apps however have been downloaded by more than 150,000 people of which about 80% are from the developing world. Doc James (talk · contribs · email) 17:50, 29 March 2017 (UTC)
  • Support I wasn't a great fan of a huge banner for this, but I can't see any problems with this template, and Doc James makes a compelling case for the apps usefulness. Sam Walton (talk) 17:57, 29 March 2017 (UTC)
  • support per reason [2]--Ozzie10aaaa (talk) 17:58, 29 March 2017 (UTC)
  • Support: The Offline Medical Wikipedia app is an application that allows Wikipedia's medical content to be downloaded in a choice of languages in compressed ZIM format (as well as a free, open-source offline browser, Kiwix, that will natively display the compressed data, if required). Its principal purpose is to allow mobile phone users in parts of the world where internet access is restricted, intermittent, or unreliable to have constant access to our medical content. As an additional means of distribution of our content, I'd personally prefer it to be a sidebar link (like "Download as PDF" is), but I'll certainly support a link somewhere in the footers of medical articles to the WikiProject Medicine page where it is documented. --RexxS (talk) 18:24, 29 March 2017 (UTC)
  • Support. There are more than a million billion of people in developing countries that only have access to the Internet for a limited time. This banner is useful for million billion of readers who can use it when they are not online. The banner is the sum of all human knowledge at your fingertips for people who don't have unlimited Internet access or who want to use it while offline. Is there a better solution? QuackGuru (talk) 19:03, 29 March 2017 (UTC)
User:QuackGuru I think you mean more than a BILLION :-) Doc James (talk · contribs · email) 19:06, 29 March 2017 (UTC)
Yep. QuackGuru (talk) 19:17, 29 March 2017 (UTC)
  • Support - I had thought this debate had already been resolved satisfactorily in the deletion discussion. Yes, the sidebar is non-intrusive and helping users access our articles is an important part of our mission. Sizeofint (talk) 19:35, 29 March 2017 (UTC)
  • Support The debate had already been resolved to almost everyone's satisfaction, and this RFC appears to be unnecessarily pointy. • • • Peter (Southwood) (talk): 19:57, 29 March 2017 (UTC)
  • Support I also support this. I think anyone working in a developing countries context knows how important it is to have Wikipedia content available offline. I wonder if the people opposing this have ever lived in an area with poor internect access and poor public health, few doctors available, no access to healthcare etc.? For people like that having the offline version of medical content (in several languages) is wonderful. Due to the fact that not many people are aware of this app yet, I strongly support having the template (or any other form of awareness raising for this app) in an appropriate place of many related Wikipedia articles. Having it at the bottom right seemed like a perfect solution to me! EMsmile (talk) 20:01, 29 March 2017 (UTC)
  • support is a related WMF project, and will be limited to medical articles. Jytdog (talk) 00:18, 30 March 2017 (UTC)
  • Support - would also support the "inline" type being discussed below. Note, this support is contingent on the format that has already been debated multiple times - primarily that it links to an editor-controlled page. — xaosflux Talk 00:22, 30 March 2017 (UTC)
  • Support - the proposal is similar to other boxes that we have, so should be understandable to people who consult Wikipedia for a variety of topics. I would particularly note that the template should also display on mobile devices (I was disappointed to find that {{Library resources box}} does not). -- (talk) 00:55, 30 March 2017 (UTC)
This template should also be included in {{Sister project links}} if this goes ahead. -- (talk) 01:05, 30 March 2017 (UTC)
  • Support. This really is a very worthwhile initiative for the purpose of helping more people become readers of Wikipedia – which after all should be what we all want. In previous versions, there have been problems with potential advertising or with overly-large banners, but those problems have now been solved. And putting it in EL is the right way to do it. I think this RfC helps tie up loose ends from previous discussions, by spelling out where and how the box will be used. I also would support the inline idea described below. --Tryptofish (talk) 01:10, 30 March 2017 (UTC)
  • Support. Seems like a worthwhile cause that could be very helpful in regions of the world with poor internet infrastructure. ---- Patar knight - chat/contributions 02:29, 30 March 2017 (UTC)
  • Support Wikipedia's health care articles are generally high quality and it is helpful to inform readers about the app which displays that content. Johnuniq (talk) 10:45, 30 March 2017 (UTC)
  • Support, it's a good way to give the app visibility. Icebob99 (talk) 15:39, 30 March 2017 (UTC)
  • Support per Doc James. Gestrid (talk) 04:53, 31 March 2017 (UTC)
  • Support for the same reasons as at the XfD I commented at. jcc (tea and biscuits) 12:31, 2 April 2017 (UTC)
  • Support — There really are no reasons to oppose beyond simply being obstructionist and wanting to hinder any improvement to the encyclopedia. It always ends up being the same people starting these pointless RfCs or who take it upon themselves to be the sole arbiters of guidelines and interpreters of policy. Carl Fredrik talk 00:37, 4 April 2017 (UTC)
  • Support - Addresses offline content issues for those in the developing world with limited internet access. SW3 5DL (talk) 04:44, 7 April 2017 (UTC)
  • Support seems pretty obvious per above arguments, Sadads (talk) 22:45, 11 April 2017 (UTC)
  • Support, conditional on the template a) being restricted to the "see also" or "external links" sections as proposed, and b) linking to a Wikimedia-site page about the app rather than directly to one or more app stores. It's a great idea as long as its implementation follows the same principles as our other article meta-content. {{Nihiltres |talk |edits}} 15:05, 12 April 2017 (UTC)
    • @Nihiltres: One other possibility that I've previously suggested is hosting the page about the app on Meta, probably at a subpage of m:WikiProject Med Foundation (because the app is available in many other languages besides English). As you mention linking to "a Wikimedia-site page about the app", am I right in thinking that you'd still be in favour if the landing page were moved to the Meta-Wiki instead? --RexxS (talk) 18:14, 12 April 2017 (UTC)
      • @RexxS: Yes, definitely. {{Nihiltres |talk |edits}} 18:22, 12 April 2017 (UTC)
        • Will get to the move to meta shortly. Agree with the other comments by User:Nihiltres aswell.Doc James (talk · contribs · email) 05:34, 13 April 2017 (UTC)
          • There are downsides of a move to meta; namely, keeping it local means it remains in our jurisdiction (i.e. it is governed by our local policies and guidelines). I'm curious what Xaosflux thinks, due to "support is contingent on the format that has already been debated multiple times - primarily that it links to an editor-controlled page", does it matter which contingent of editors control the page? — Godsy (TALKCONT) 15:22, 13 April 2017 (UTC)
            • @Godsy: It doesn't matter to me if it is a w:en: link or a meta: or a link; main point being that it leads somewhere under volunteer editorial control (as opposed to the original link to an external commercial website). — xaosflux Talk 18:00, 13 April 2017 (UTC)


  • Oppose. Use formatting similiar to {{dmoz}} instead. KATMAKROFAN (talk) 20:28, 29 March 2017 (UTC)
    • Possibly an unfortunate analogy as DMOZ has just closed down. Nevertheless it's an interesting suggestion, so could you give an example of how this might look on an article like Pneumonia, please? --RexxS (talk) 21:05, 29 March 2017 (UTC)
External resources

KATMAKROFAN (talk) 21:35, 29 March 2017 (UTC)
Thank you. So essentially, you'd prefer the content of the template as plain text among the external links, rather than in a box floated to the right of the page with the sister projects? That seems a possible alternative. --RexxS (talk) 22:05, 29 March 2017 (UTC)
We also have Template:Commons-inline. The two are not exclusive of each other. Doc James (talk · contribs · email) 22:09, 29 March 2017 (UTC)
(edit conflict)Seems a strange way to do it. The links placed there are almost always links external to the Wikimedia projects, whereas we tend to put links to Wikimedia related places (Commons for example) in a side box like the one being proposed here. Sam Walton (talk) 22:09, 29 March 2017 (UTC)
  • I'm going to oppose.

    I'm sympathetic to the view that "offline reading" should be enabled.

    I do not, however, believe this is the way to do it. A systematic way, which relies not on en.WP's hack of a template, nor one which advertise a particular reader or viewer, is a) much better and b) provides the functionality for all pages, without c) the mess of a template addition to every article (within a certain scope) for d) every reader, mobile or not. To that end, there is a phabricator task for this funcitonality at phab:T113396. My final opinion: Just be patient. It's on the (WMF) radar. Courtesy ping to AGomez (WMF) who looks to have been editing the page at meta:New Readers/Offline. --Izno (talk) 12:58, 30 March 2017 (UTC)

  • Yup more options for reading Wikipedia offline are coming :-) The page this template links to will discuss that option as soon as it is avaliable. The template is not specific to raising awareness about a single app but about raising awareness about offline options generally (options of course need to be free and under an open license). Doc James (talk · contribs · email) 13:16, 30 March 2017 (UTC)
  • Oppose: it is not the job of each individual wiki article to make "meta" announcements of "other things that are available" related to Wikipedia. Articles are already at the borderline of being a mess in this sense, and if every special interest group within Wikipedia proceeded to add such "meta" announcements within individual articles, the result would clearly be untenable. I'm not sure why this particular announcement deserves an exception. Aureliano Babilonia (talk) 01:55, 3 April 2017 (UTC)
    • Because we see it as part of our mission to provide content to those in the developing world in a format that they can use. And also this appears to have consensus. Doc James (talk · contribs · email) 23:05, 9 April 2017 (UTC)
    • I'm sympathetic to your (Aureliano Babilonia's) argument; it is superficially good. The problem is that it relies on skewed priorities. At least in the short term the significant benefit (people with poor Internet access having access to Wikipedia's medical content) arguably outweighs the minor cost (us volunteers having slightly more work and slightly less organization), and in the longer term we can push for better ways to surface this sort of meta-content to users, to reduce or eliminate that cost. {{Nihiltres |talk |edits}} 15:37, 12 April 2017 (UTC)



Relevant discussions preceding this RfC: Wikipedia:Miscellany for deletion/Wikipedia:WikiProject Medicine/App/Sidebar, Wikipedia talk:WikiProject Medicine/App#Sidebar, and Wikipedia talk:WikiProject Medicine/Archive 94#Sidebar. — Godsy (TALKCONT) 17:36, 29 March 2017 (UTC)

it seems s support vote is best for everyone, not clear what(or why) your position is such given prior general opinion[3]--Ozzie10aaaa (talk) 18:10, 29 March 2017 (UTC)
Discussion about titling the RfC
The initial heading was "non neutral". Have adjusted it so that it is.[4]. And here is the link to policy requiring the statement of the RfC to be neutral[Wikipedia:Requests_for_comment#Statement_should_be_neutral_and_brief] Doc James (talk · contribs · email) 18:19, 29 March 2017 (UTC)
@Doc James: Advertising, i.e. "the act or practice of calling public attention to one's product or service", is not inherently non-neutral. However, raising awareness is inherently non-neutral. — Godsy (TALKCONT) 18:32, 29 March 2017 (UTC)
Godsy you appear to dislike the app. Can you explain why? I was under the impression that we address your concerns. Doc James (talk · contribs · email) 18:34, 29 March 2017 (UTC)
@Doc James: Would you find "Publicizing the offline Medical Wikipedia app" or "Promoting the offline Medical Wikipedia app" agreeable for the RfC title? — Godsy (TALKCONT) 18:40, 29 March 2017 (UTC)
We could use "Linking to details regarding the Offline Medical Wikipedia app" Doc James (talk · contribs · email) 18:43, 29 March 2017 (UTC)
 Done. I'll fix the existing links. — Godsy (TALKCONT) 18:46, 29 March 2017 (UTC)
Godsy, although you're a relative newcomer, you must know very well by now that this encyclopedia is strongly opposed to any advertising. It is inconceivable that you do not understand that calling other editors' contributions "advertising" is rude and and offensive to them. To then edit-war your calumny back into this RfC is beyond acceptable behaviour, and I shall be considering seeking administrative assistance to ensure that you do not repeat that behaviour in future. --RexxS (talk) 18:56, 29 March 2017 (UTC)
@RexxS: Changing it to raising awareness was no better. I reverted twice, then came here to discuss; Doc James changed it thrice. If you do choose to seek administrative assistance, it will likely be fruitless, as I've done nothing inappropriate. — Godsy (TALKCONT) 19:07, 29 March 2017 (UTC)
@RexxS: I misspoke, I reverted twice. I was concerned about the link at {{cent}}. Best Regards, — Godsy (TALKCONT) 19:13, 29 March 2017 (UTC)
Changing it to raising awareness was no better - That's simply untrue. "Raising awareness" on Wikipedia carries none of the pejorative implication of "advertising" and it's not the "euphemism" that you claimed in your edit summary, ... if you euphemize inappropriately again, I expect you to check my contributions and fix all the existing links. You don't seem to understand edit-warring either. You called the template "Advertising the Medical Wikipedia app"; Doc James changed it to "Raising Awareness of the Offline Medical Wikipedia app". That's the point where you take it to talk, not after forcing your preferred version back into this page twice more. I understand your concern about having to update links at Cent, but that's a small price to pay for not offending other good-faith editors. Quite honestly, I'd much prefer not to have to waste my time at ANI, but I remain concerned that you're not willing to own up to mistakes like 22 reverts with no reason other than the edits you reverted didn't seek consensus beforehand and calling an RfC with a non-neutral title. --RexxS (talk) 19:33, 29 March 2017 (UTC)
Euphemize wasn't the best description, though it is not necessarily inaccurate; it and the rest of my edit summary was a reaction to behavior that I've come to expect from some wp:med participants. I created it at Title X (creation), Doc James changed it to Title Y (Bold), I revered it back to X (Revert) - that is the point where discussion should have taken place. Doc James shouldn't have changed it a second time (Discuss), especially as the title they changed it to was not any better neutrality-wise. The over 20 reverts you mention: Doc James added {{offline|med}} to a group of articles (Bold), I reverted the additions notifying them that the change was contentious and suggesting a venue for discussion (Revert), Doc James ignored that and restored them all (Discuss). History is important for context: Wikipedia:WikiProject Medicine/App/Banner was added to the top of a few articles, some about a year ago, and at least one with the edit summary "one week trial". I'm not sure if there was any local consensus at that point, but editors removed the banners, and they were restored by members of the WikiProject. Wikipedia:Miscellany for deletion/Wikipedia:WikiProject Medicine/App/Banner began. It was closed as "Keep, but not to be inserted into articles without obtaining consensus to do so." Editors removed the banners from the articles for a second time per that consensus, but again, members of the WikiProject restored them. Wikipedia:Village pump (proposals)/Archive 138#Use of Wikipedia:WikiProject Medicine/App/Banner on articles is opened, and finally 3 months later, the banners were removed after being present at the top of articles all that time (since the MfD) against community consensus. That's all I have to say on the matter here, as not to further detract from the RfC. — Godsy (TALKCONT) 04:26, 30 March 2017 (UTC)

I think it would be worth showing the actual template in question, to allow those unfamiliar with the previous debates to get an idea of what we are discussing. --RexxS (talk) 18:29, 29 March 2017 (UTC)

Thanks User:RexxS have moved to the top of the RfC. Doc James (talk · contribs · email) 18:38, 29 March 2017 (UTC)

If it is advertising, then it is advertising for something benign. The real offender is the link to the "Wikipedia Shop" selling T-shirts which appears on every page. Matthew Ferguson (talk) 18:51, 29 March 2017 (UTC)

The app is developed by volunteers at WPMED and Wikimedia CH. It is free and without advertising. The development cost (paying for programmers) is covered by movement funds. We are not "selling" anything so the user of the term "advertising" IMO is inaccurate. Doc James (talk · contribs · email) 19:15, 29 March 2017 (UTC)
agree--Ozzie10aaaa (talk) 19:40, 29 March 2017 (UTC)
Promotion/advertising/raising awareness/etc. It's semantics. I feel the reason this is an issue with some is that it represents placing a link on encyclopedia pages to a program which is not directly related to any given encyclopedia topic. Matthew Ferguson (talk) 20:40, 29 March 2017 (UTC)
It's more placing a link to the data - i.e. the compressed Wikipedia content. Surely the program (offline browser) is incidental. Wouldn't the reason you suggest be as logical as having an issue with the [Download as PDF] link, which is on every article page, because Adobe Acrobat "is not directly related to any given encyclopedia topic"? --RexxS (talk) 20:48, 29 March 2017 (UTC)
Invalid analogy really. 1. PDFs can be read with many programs, 2. downloading the article as PDF does not require you to download any program in particular, 3. the link gives you a PDF of the article you were on, I assume the link to the medical app will not directly link you to the article you were originally on. Matthew Ferguson (talk) 21:10, 29 March 2017 (UTC)
Not really. 1. ZIMs can be read by many programs; 2. downloading the data does not require you to download any program in particular – especially as ZIM is an open and standardized file format, unlike PDF; 3. the link gives you all of Wikipedia's medical content, including the article you are on, which allows you to go to all of the other medical articles that the article has wikilinks to (unlike a PDF). --RexxS (talk) 22:16, 29 March 2017 (UTC)
Yup exactly. The main WP app should be reading ZIMs soon aswell.Doc James (talk · contribs · email) 22:48, 29 March 2017 (UTC)
Clicking the "download as PDF" gives me a PDF of the article I was on. Clicking this link takes me to a description page about an app which I would have to download, which I would then have to navigate to find the article again. This is what is meant by not directly related to any given encyclopedia topic. Matthew Ferguson (talk) 19:54, 30 March 2017 (UTC)

Abolish sidebar navigation templates[edit]

We now have hundreds of sidebar navigation templates that are identical (or nearly identical) to corresponding footer navigation templates. For example {{Conservatism US}} and {{Conservatism US footer}}. It is common practice to include both in any articles related to the subject. See, for example, Paleoconservatism. I don't see any point in including the same content twice in the same article. However, it is virtually impossible to keep people from adding these templates to the articles, even when one of the two templates is already present. The only practical solution, IMO, is to abolish the practice of having sidebar navigation templates. I'm not sure what purpose these templates were designed to address that isn't already handled by footer navigation templates. For anyone opposing this proposal, please explain why we need both. Kaldari (talk) 02:01, 6 April 2017 (UTC)

  • They're helpful in several ways. They're more likely to be seen than the templates at the bottom of articles. They often include images, so they contribute to the article not being a wall of text. And they help to shorten the long lines of text we have because we have no fixed width. If they're being added a lot, it means people like them. SarahSV (talk) 05:57, 6 April 2017 (UTC)
  • I'm very conflicted about these sidebar navigations. There indeed is a lot of duplication here, but there has always been a space for both of these. I think the problem is that if a series box becomes a 'let's link to everything' navbox with multiple levels of 'by default' collapsing (which ppl really need to start learning means 'only-collapsed-on-desktop'), then it's no longer working as it was intended. —TheDJ (talkcontribs) 10:43, 7 April 2017 (UTC)
  • The sidebar navigation should only have a few simple links without options to expand more links. Save that for the footer. Graeme Bartlett (talk) 01:53, 10 April 2017 (UTC)
  • I oppose any abolishment of these things. Or any rule that prohibits their use. Definitely WP:CREEP if you ask me and some of these work fine. I use the {{forensic science}} sidebar on almost every single article I care about. There is no bottom navbar for that topic. And I also agree with SarahSV. They break up the walls of text that are in the top of articles that don't have infoboxes. --Majora (talk) 02:00, 10 April 2017 (UTC)
  • Whether we need both or not, I see no harm in having them and therefore oppose a blanket abolishment of them. I would suggest that attempting to craft a more nuanced policy on nav templates may be more helpful than just trying to delete an entire category of them. Beeblebrox (talk) 02:58, 10 April 2017 (UTC)
  • We should stick with navbars and scale back on sidebars IMO. Doc James (talk · contribs · email) 09:25, 10 April 2017 (UTC)
  • Would there be any benefit in combining the templates for navboxes and navbars so that there is only one for any given subject, but it can be selected to display as either. This would allow user choice of output format, or could be linked to skin, etc. • • • Peter (Southwood) (talk): 09:35, 10 April 2017 (UTC)
    • Some more clarity around which should be used when would be useful. Doc James (talk · contribs · email) 10:32, 10 April 2017 (UTC)
  • The more links a sidebar navigation template has, the less valuable it becomes. They should be used for tightly focused topic areas. Praemonitus (talk) 20:17, 13 April 2017 (UTC)
  • Since many complain about sidebars becoming bloated with too many links, we should think about devising and enforcing guidelines on the appropriate level of comprehensiveness of sidebars. – Finnusertop (talkcontribs) 20:25, 13 April 2017 (UTC)
  • Oppose – 1) options are a good thing, 2) enables navigation from the top of articles. North America1000 21:31, 16 April 2017 (UTC)
  • Oppose - side bar templates are more noticeable than footer templates. Although, both are useful because if one scrolls all the way to the bottom, he/she would not need to come up to navigate. Same for those who just read the lead..Yashovardhan (talk) 11:41, 19 April 2017 (UTC)
  • Oppose Sidebar templates are much handier and easier to use. Dlohcierekim 18:00, 20 April 2017 (UTC)

Clicking on images[edit]

Another proposal of mine (also for all Wikipedia versions, if possible) would be to make sure that after clicking on an embedded file in an article and entering the Commons page of that file, you get back right to the position of that image in the article when using the back-button of your browser. Up to now, this is not the case at least for the current Firefox, but instead you always end up at the beginning of the article once you have entered Commons. Would this also be worth forwarding to Phabricator in your view?--Hubon (talk) 15:31, 12 April 2017 (UTC)

You'd better ask this question on Wikipedia:Village_pump_(technical). Ruslik_Zero 20:15, 12 April 2017 (UTC)
Do you have "Enable Media Viewer" at Special:Preferences#mw-prefsection-rendering? Media Viewer is known to mess with the normal functioning of the back button. PrimeHunter (talk) 21:52, 12 April 2017 (UTC)
@Ruslik0: Thanks for your advice! @PrimeHunter: Yes, I do, but still: If we take the article Nazi plunder and click twice on image no. 5, we get to this site. Now, if we click "back", we end up at the very beginning of the article instead of the relevant section. And it's the same with all the other Wikipedias! As recommended by Ruslik, I will now refer the issue to Wikipedia:Village_pump_(technical).--Hubon (talk) 22:30, 13 April 2017 (UTC)
If Media Viewer is causing problems for you, then disable it. It's crap quality, buggy code, and I recommend against using it. -FASTILY 22:42, 15 April 2017 (UTC)
@Hubon: Preservation of scroll state is a browser function (I have no trouble with Chrome or Safari). Which browser are you using ? —TheDJ (talkcontribs) 13:06, 17 April 2017 (UTC)
@TheDJ: Thanks for your interest! I use the latest Firefox version. Now, do you think it would be very difficult for Phabricator to modify Media Viewer in a way that would render it compatible with all common broswers regarding preservation of scroll state? Greetings--Hubon (talk) 13:11, 18 April 2017 (UTC)
I can confirm that this is a problem with Firefox. You should report it in phabricator. —TheDJ (talkcontribs) 09:55, 20 April 2017 (UTC)

Note: Unfortunately, nobody answered on Wikipedia:Village_pump_(technical)... :-(--Hubon (talk) 21:04, 19 April 2017 (UTC)

user:TheDJ: Many thanks for your interest! Would you mind reporting the issue on Phabricator? As I've already communicated before, I'm admittedly not at all familiar with this platform... Thus, I'd be very grateful for any help with passing on the the request to the institutions responsible. Best--Hubon (talk) 19:28, 23 April 2017 (UTC)

Redirect talk pages with only banners[edit]

Some pages like WT:NJournals are tagged only with a banner and nothing else. I think it's pretty reasonable to say that people who link to WT:NJournals expect to have people be taken to the same place Wikipedia talk:Notability (academic journals). [This is true in Wikipedia talk space, just like in any other talk spaces, whether mainspace, category space, etc... This can be confusing to editors, because they are told "comment here", and the page doesn't redirect to the discussion they were meant to be taken.

So I propose that we have a bot with the following logic

For an example where this is already done, see WT:NJOURNALS. Headbomb {t · c · p · b} 09:37, 14 April 2017 (UTC)


  • Support, as proposer. Headbomb {t · c · p · b} 09:38, 14 April 2017 (UTC)
  • Support to avoid confusion, the page and talk page should both redirect. AD 09:55, 14 April 2017 (UTC)
  • Comment are you referring to articles that were merged, but there were previous discussion on the talk page of the merged article? In that case, the talk page should be preserved and not redirected, any project banners on the talk page should be reclassed as Redirect to indicate to the projects that the articles were merged, but there were previous discussions preserved. —Farix (t | c) 13:33, 15 April 2017 (UTC)
    • No, this would be restricted to pages that only have banners on it, and nothing else. Pages with discussions would be skipped by the bot. Headbomb {t · c · p · b} 22:07, 15 April 2017 (UTC)
      • And what about talk pages where the only "discussions" are bot messages? Should those also be redirected as well? —Farix (t | c) 11:48, 21 April 2017 (UTC)
  • Support. Seems sensible enough. Gestrid (talk) 04:45, 16 April 2017 (UTC)
  • Support. Letting the talk page contain only banners will be confusing, while any other ways of linking to the redirect (like using {{Talk page of a redirect}}) would be roundabout and with no benefit that I can think of. – Uanfala (talk) 13:43, 17 April 2017 (UTC)
  • Support - page and talk page should both redirect.. SW3 5DL (talk) 04:53, 18 April 2017 (UTC)
  • Support per nom. Yashovardhan (talk) 11:49, 19 April 2017 (UTC)
  • OK. You have my axe. Herostratus (talk) 13:37, 20 April 2017 (UTC)
  • Support with emphasis on the first step in the bot logic (nothing but banners, if there's anything else it should not be auto-redirected). Respectfully, InsaneHacker (💬) 19:48, 21 April 2017 (UTC)
  • Support. I didn't know redirecting with the banner was possible, or I'd have been doing it this way all along. Good idea. Ks0stm (TCGE) 19:54, 21 April 2017 (UTC)
I discovered this fairly recently myself, otherwise I'd have proposed this years ago! Headbomb {t · c · p · b} 11:35, 22 April 2017 (UTC)
Support if all revisions of the talk page are nothing but banners. עוד מישהו Od Mishehu 21:16, 22 April 2017 (UTC)

Citations Archive[edit]

Wikipedia doesn't do entropy as well as we could. If you look at an article created several years ago there is a good chance that most of the sources are now redlinks or worse may have completely different content.

Should we develop a citations archive such as detailed at WP:Citation Archive? It is now technically feasible, and I suspect the Wikimedia Foundation could afford it.


  • Support as proposer ϢereSpielChequers 10:03, 15 April 2017 (UTC)
  • Something like WP:WEBCITE? —  crh 23  (Talk) 18:13, 15 April 2017 (UTC)
    • Yes a little like it, but while WEBCITE is optional and manual this would be automated and used on everything that isn't paywalled. ϢereSpielChequers 19:57, 15 April 2017 (UTC)
  • Might the better solution be to have a system where some kind of automated process follows every added link and within a few minutes of it being added, goes to the wayback machine and requests a capture, then adds that archived URL on Wikipedia? Not convinced we need to duplicate the actual archival process. Sam Walton (talk) 22:52, 15 April 2017 (UTC)
  • Either way, we don't want to overwhelm whatever bot would do this (because a bot would probably be the one adding those links) or Wikipedia's servers (which may be overwhelmed with eiher archiving basically the entire web or edits from the bot, both because we have hundreds or thousands of edits with links being added every minute). I remember that a few months ago, we had a bunch of people over at WP:THQ complaining they couldn't see their page edits right away. I found out it was related to a bug being tracked on Phabricator which eventually made its way to "Unbreak Now" status. I envision something similar happening if this isn't implemented correctly. Gestrid (talk) 04:58, 16 April 2017 (UTC)
  • We average a hundred edits a minute on the English Language Wikipedia. I don't know what proportion of these include a cite, but I'm pretty sure it is much less than half. Especially as the code will have to understand the concept of a revert and not update the citations archive when someone reverts to "the last cited version". So I don't think this should add such a burden as to slow things down, most of the time it will be simply reading edits that have taken place and the pedia and other sites. Adding links should be much later when the cited sight has gone dark. Yes it will be by bot, but the bot can be throttled and could even run at quiet hours. ϢereSpielChequers 12:09, 16 April 2017 (UTC)
  • Support an automated process. It does not have to be immediate, and need not affect the save. It would be OK not to archive if the item is already archived, but that might require more work to check if currently archived version is the same as the referenced version than to just do it again. Dead link fixing is tedious, and not always possible, when people use bare urls for references. • • • Peter (Southwood) (talk): 09:57, 16 April 2017 (UTC)
  • Unnecessary—the Internet Archive has already automated the archival of links in use on Wikipedia, and there is a bot that already (InternetArchiveBot) that works to add these links to articles. In short, the automated process you seek already exists. Imzadi 1979  10:09, 17 April 2017 (UTC)
    This. If you need the bot on some pages, users can use the linked in the revision history of any page, or can summon the bot on a collection of pages using this tool.—CYBERPOWER (Chat) 11:11, 17 April 2017 (UTC)

Save MYO Wikilove[edit]

It's simple. Sometimes I make Wikilove that I want to save and be able to use again. I don't want to have to make the same ones over again. Thanks!

@Creeperparty568: Just create it in a subpage of your userspace and transclude it wherever you want to reuse it, like any other template (except you need the full name of the page like this: {{User:RexxS/Shakespearean insults}}. --RexxS (talk) 12:58, 17 April 2017 (UTC)
@RexxS: I know, but I just want to be able to access it from the wikilove menu to make it easier and more convenient. — Preceding unsigned comment added by Creeperparty568 (talkcontribs)
@Creeperparty568: The feature already exists. See mw:WikiLove#How to customize. PrimeHunter (talk) 22:34, 17 April 2017 (UTC)

Experiment to see if training modules are helpful for new users[edit]

I'd like to run a controlled experiment with pointing new users toward these training modules, to see if providing such training modules makes newcomers more likely to stick around and become effective editors. We've done such things occasionally before — inviting 10,000 users to try The Wikipedia Adventure, for example — to mixed results, and we haven't yet found anything that actually makes a demonstrably positive difference, in terms of automated welcomes. However, I think there are a few differences that make it worth trying again with these training modules. First, the user experience is much more streamlined than any on-wiki intros / tutorials we've tested before. New users are typically overwhelmed with the abundance of links and places to go when they get started on Wikipedia. Second, compared to The Wikipedia Adventure, these training modules are much more practical, aimed at efficiently teaching the basics of how Wikipedia works and how to edit it. They've also been through a lot of iterations based on user tests and feedback from Wiki Ed classroom program student editors, to make sure they are clear and address the most common problems that new editors run into.

You can see a little more detail about what I'm proposing here: Wikipedia:Bots/Requests for approval/RagesossBot 3.--ragesoss (talk) 17:52, 18 April 2017 (UTC)

  • I support this proposal. I ran the experiments for Teahouse and Wikipedia Adventure invites, and I think it is a great low-impact/high-value method for testing out new approaches to onboarding newcomers. J-Mo 17:58, 18 April 2017 (UTC)
  • I'm all for initiatives like this but when I click through to an introductory module and see it's going to take me nearly half an hour to complete, I nope right out of there. I'm skeptical that someone who registers an account (presumably with some particular edits in mind that they want to make soon after account creation) would generally be up for completing hours of training modules. That said, I'm not opposed to a trial that might prove me wrong! Sam Walton (talk) 18:00, 18 April 2017 (UTC)
  • Yeah, I'm quite certain that most users will not go through them. But part of the design is to offer the whole set, each with a specific topic, so that if a user is actively interested in (say) learning about how to make edits, or learn about the rules, they'll have an accessible way to dive in.--ragesoss (talk) 18:05, 18 April 2017 (UTC)
  • Please gods yes. The pain point of new users getting smashed on their first article creation experience is something that needs our greatest efforts. --joe deckertalk 18:06, 18 April 2017 (UTC)
  • @Ragesoss: I think this is a great idea! New user retention is a huge challenge for us, but we've done comparatively little testing of strategies to address it (J-Mo and Aaron Halfaker's work being a big exception, of course). Unfortunately, I don't have much time to offer help, since I'm in the middle of preparing for a different research project about new editor success :) My one observation is that you may want to focus specifically on testing the hypothesis that it's not just offering help information, but offering a limited, manageable set of help information that makes the difference. That would be an even more useful result. So perhaps you could use a standard welcome template, instead of or alongside nothing, as a control.—Neil P. Quinn-WMF (talk) 20:23, 18 April 2017 (UTC)
  • The default situation for new users is no template at all, so I think we should at least have a control group where we do no intervention at all. I'm not opposed to a third group that gets a more standard template, but I was thinking to just start as simply as possible.--ragesoss (talk) 20:39, 18 April 2017 (UTC)
  • I'm not going to oppose a trial - we don't know if this will work until it has been tried. However, this is not support of the whole deployment, that has to come after reviewing evidence of the trial. I am not too keen on automated welcoming, they seem a bit artificial, and fake. A personal note with some helpful links or even templates I feel are much more useful, as they are more encouraging to the new user. I hope that I am wrong in this - let's give a trial and see. However, this idea of training is a great one and should be incorporated into existing welcome templates. TheMagikCow (T) (C) 19:44, 21 April 2017 (UTC)

Archiving weblinks[edit]

I would like to propose the development of a bot or program for all projects and languages that turns outdated weblinks into archived version links like in Wayback Machine. Would that be feasible and has there been an identical proposal here or at Phabricator yet?--Hubon (talk) 21:02, 18 April 2017 (UTC)

@Hubon: I don't think the WMF would do this for all projects and languages, given that there are more than 700 WMF sites (translation requirements and different templates; some projects just might be too small or not important enough and a bot might be unnecessary). InternetArchiveBot is currently running on the English and Swedish Wikipedias, and Wikiwix archive links seem to be automatically added on the French Wikipedia. I'm not sure about other projects though, but IABot is apparently "in ongoing development, to support additional wikis". Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
11:55, 21 April 2017 (UTC)
InternetArchiveBot is a project that is now in the process of being deployed to other wikis. If you have a Wikipedia in, start a discussion there and link to that discussion by creating a new ticket with this tool.—CYBERPOWER (Chat) 12:01, 21 April 2017 (UTC)
@Jc86035: Thanks for the information! @Cyberpower678: I'm sorry, but I'm afraid I didn't quite get your message. Apart from English Wikipedia, I mainly edit in the German project. And, in fact, I already asked there about this issue but didn't really receive a proper reaction... What now?--Hubon (talk) 19:20, 23 April 2017 (UTC)
@Hubon: This may interest you. I opened a discussion there, but go no response so far. Try to attract some editors to that thread. I have dewiki on my radar to deploy IABot.—CYBERPOWER (Around) 19:56, 23 April 2017 (UTC)

Recategorizing all medicine and biology articles using the more specific MeSH hierarchy[edit]

MeSH is a very important database created by the United States National Library of Medicine (NLM) to index books and journal articles in medicine and biology. It is updated annually. For 2017, it contains more than 55000 categories (they call them descriptors) which can very specifically categorize any article of biology or medicine. My idea is to import this tree hierarchy to Wikipedia. This could be achieved using AWB tool and an approved Bot account. I got already a *.xlsx file listing these descriptors from the official MeSH website. I have then converted it to a text file which is ready for mass category creation using CSV Loader Plugin of AWB. Some of these categories are already on Wikipedia, but I believe the majority are not yet. Each MeSH category will contain the following text:

Template:empty category
Template:MeSH category, including the unique MeSH ID as a key.
template:cat main
MeSH definition:
category:Medical Subject Headings, including the tree number as a key.

Examples of such MeSH categories are: Category:Anatomic Landmarks, Category:Body Regions

I think also that this idea, if applied, will reveal hundreds of new red links.

Previous discussions:

Tools needed:


  • Support Doc James (talk · contribs · email) 23:27, 18 April 2017 (UTC)
  • support--Ozzie10aaaa (talk) 00:07, 19 April 2017 (UTC)
  • Support - AWB and bot usage to automate the organisation of already created categories into the MesH hierarchy, and future categories at a reasonable interval. I think the automated creation of (potentially 50,000+) categories needs a more thorough proposal with a more advanced bot or significant user interaction. PriceDL (talk) 12:27, 20 April 2017 (UTC)
    • Would also support the automated creation of currently nonexistent categories necessary to represent the MesH hierarchy. PriceDL (talk) 12:31, 20 April 2017 (UTC)


  • This seems a misuse of the categorization system. Finding which articles are missing is not the purpose of categories (or else they should be maintenance categories, hidden from sight), normally one would create one or more lists in project space for this where the redlinks can be listed. Having 55,000 categories for this is serious overkill (do we really need Category:Peptidyl-Prolyl Cis-Trans Isomerase NIMA-Interacting 4, which has two different codes to boot?). Creating a category system using a higher level of grouping from this tree hierarchy seems a potentially good thing though, with just a few thousand categories. I also don't see how you propose to differentiate between categories with the same MeSh name (e.g. "Superficial Musculoaponeurotic System" is A01.456.505.875 and A01.598.500). The actual benefit you propose (" It will ease access to medical articles from categories.") can better be achieved by a somewhat smaller category tree than the massive one you propose. Fram (talk) 07:17, 20 April 2017 (UTC)
    • @Fram: Would you suggest a way to remove very very specific categories like Category:Peptidyl-Prolyl Cis-Trans Isomerase NIMA-Interacting 4 from the hierarchy? Regarding categories with the same Mesh name, they are basically the same category but subcategorized under two different categories, that's why they have different tree numbers, but you can notice that they have the same "unique" ID number. --Brainist (talk) 07:29, 20 April 2017 (UTC)
      • I don't know a way whereby a bot can decide which categories are too specific, and which aren't. It isn't as easy as saying "lowest level is not used, all higher levels are used". Perhaps something like "only go three levels deep" may be a (simplistic) solution. Or perhaps this simply isn't a good bot task after all. Creating thousands of empty mainspace categories seems like a bad idea in any case. Fram (talk) 08:48, 20 April 2017 (UTC)
        • Thanks for making me aware of the duplicates, which after exclusion, the unique categories came out to be almost exactly the half, just 27900 categories. I don't think this number for categorizing all articles related to whole medicine, dentistry, veterinary medicine, biology is massive. They will be temporarily empty till I fill them. Notice that out of those 27900, there are already thousands of medical categories out there in Wikipedia which will be skipped by the bot. --Brainist (talk) 09:39, 20 April 2017 (UTC)
        • Category:Peptidyl-Prolyl Cis-Trans Isomerase NIMA-Interacting 4 would be almost empty today containing just "PIN4", but after let's say 3 years, with the encyclopedia expanding, this category will contain articles about diseases caused by malfunction of this enzyme or drugs acting on it, etc. This hierarchy will be the last categorization needed for medical and biological articles, and it will be updated annually with the release of a newer version of MeSH database by NLM. --Brainist (talk) 09:51, 20 April 2017 (UTC)
          • We've had PIN4 for 9 years now, and no articles link to it. I see no reason to share your optimism that in a few years time, these categories will be populated with more articles suddenly. Subdividing categories when they turn out to be overpopulated is natural; creating thousands of empty and near-empty categories in the hope that they will magically become more populated in a few years time is not something I can support though. I also note that this is much wider than just medicine: your proposal would create categories like Category:Alouattinae, which owuld be a duplicate of Category:Howler monkeys. I don't see in your proposal how you wuold deal with the many, many similar cases where we already have a category for the common name and you would create one for the MeSH name. Basically, the more I look at this, the less erason I see to do this by bot or en masse. Fram (talk) 10:33, 20 April 2017 (UTC)
  • Oppose - we do need human judgement on which categories need to be created. For example, we have Category:Bonobo, so we don't need Category:Pan paniscus (on List of MeSH codes (B01)#MeSH B01.150.900 --- vertebrates, number B01.150.900.649.801.400.112.400.600); nor do we necessarily need Category:Papio anubis or its likely name Category:Olive baboon (number B01.150.900.649.801.400. While both of these items come from the organism subtree, I think similar attention would need to be given to the other subtrees. עוד מישהו Od Mishehu 11:41, 20 April 2017 (UTC)
  • I'm not going to use bold in this oppose, but is this not better done at Wikidata, which already has Mesh IDs? --Izno (talk) 12:20, 20 April 2017 (UTC)
  • Oppose We do not usually need this degree of specialization. There is no virtue in overly narrow categories-. For many of the MESH categroies, the WP search function will work quite well. Categoriews also normally use generally accessible terminology,; MESH is specialized. Our articles are intended for general readers. DGG ( talk ) 14:09, 20 April 2017 (UTC)
  • Oppose The human touch works well for creating needed categories. We do not need more elaboration in the form of over-specialization and creating overly narrow, contra-intuitive categories. If anything, the current tree needs pruning. Dlohcierekim 18:11, 20 April 2017 (UTC)
  • Please don't add them all, as it will result in many empty or useless categories, that will just have to be deleted. I think some human house will be required evaluate which ones are useful , and where they should be added into the already existing category tree. Graeme Bartlett (talk) 08:17, 21 April 2017 (UTC)
  1. Oppose we have already had very poor experiences using alternate category and tree categorisation systems in the anatomy space. Problems that we encounter are trying to morph our existing content to match systems that don't match our unique scope, style or notability or requirements. The fact is, we are a unique encyclopedia and we do not need to duplicate other categorisation systems. Wikidata would be a more appropriate mechanism to deploy MeSH data, and then link that to articles.--Tom (LT) (talk) 11:29, 22 April 2017 (UTC)


How will the bot identify which categories to give to each article? Chiswick Chap (talk) 21:37, 18 April 2017 (UTC)

The bot will be used to create the categories. Categorizing article I will then do manually. Do you have a better idea to do this using a bot? --Brainist (talk) 21:43, 18 April 2017 (UTC)
Some articles already have a MeSH code, so they could be classified automatically by a bot. But there are already 2,600 categories and over 30,000 articles in the scope of WikiProject medicine. Is it actually your intention to make use of all 55,000 MeSH descriptors and manually assign each of the 30,000 articles into categories based on those descriptors? --RexxS (talk) 21:54, 18 April 2017 (UTC)
@User:RexxS, I think the hardest part is creating 55,000 new categories. This must be done using a bot. It is ok if I do the categorization part manually, even if it takes a while.--Brainist (talk) 23:03, 18 April 2017 (UTC)
What is the benefit? Doc James (talk · contribs · email) 22:28, 18 April 2017 (UTC)
@User:Doc James, the same benefits of categorization in general. It will ease access to medical articles from categories. For example without Category:Amygdala, it would be hard to find all Wikipedia articles related to amygdala's anatomy, histology, physiology, diseases, and surgeries. And as I mentioned before, It will reveal the shortage in medical content. I noticed that many MeSH descriptors don't have a corresponding Wikipedia article. --Brainist (talk) 23:03, 18 April 2017 (UTC)
Okay sounds reasonable. This will also incorporate articles related to anatomy, molecular and cell biology, and physiology etc. Doc James (talk · contribs · email) 23:27, 18 April 2017 (UTC)

Is the source for this bot available so we can confirm it won't break everything? Also, how will the task be separated between the bot and AWB? PriceDL (talk) 17:23, 19 April 2017 (UTC)

@PriceDL: using the CSV loader plugin, the column header:
Bot using AWB tool in CSVLoader plugin
for example:
  • I should mention than unsued categoriwes can be speedily deleted; categories
##Category:Cavernous Sinus##$$##D002426##$$##An irregularly shaped venous space in the dura mater at either side of the sphenoid bone.##$$##A07.231.908.224.334##

will be used, with the general text:

template:empty category
template:MeSH category|##Unique_ID## 
template:cat main
MeSH definition: ##Description##
category:Medical Subject Headings|##treenumb##

The AWB tool is semi-automated, namely it can find the column headers within a text and replace it, but it needs a user to click the save button for each category. In order to avoid clicking the save button 50,000+ times manually, I want a bot with AWB permission to automatically click the save button (see the picture). After creating all categories, the bot will use very simple pywikibot scripts to categorize them inside each other and form the MeSH tree.--Brainist (talk) 04:07, 20 April 2017 (UTC)

  • I should mention that it is part of general Deletion Policy for empty categories to be speedy deleted. Categories containing only very few items are routinely brought for discussion at WP:CFD, and almost always upmerged or removed. There is also a formal procedure for renaming categories. If anyone should add several tens of thousands of empty or almost empty categories, I expect it will be considered unconstructive. DGG ( talk ) 14:17, 20 April 2017 (UTC)

Change WP:NPROF[edit]

I think NPROF should redirect to WP:PROF, and a new redirect created for non-profits. Perhaps WP:NONPROF or WP:NPROFIT? We already have WP:NONPROFIT, so it is possible to free up NPROF. Many more times I will be looking for NSCHOLAR than NONPROFIT, and it took me a few extra minutes to guess at NADADEMIC which got me to the correct policy page. I created NSCHOLAR because I saw that many other editors had referenced SCHOLAR as that, and N is used ot denote the Notability guideline as opposed to some other guideline, or a sub-section of BLP. Any thoughts? L3X1 (distant write) 00:36, 22 April 2017 (UTC)