Community Wishlist Survey 2017/Miscellaneous

27 proposals, 416 contributors

Get feedback using a yes/no microsurveyingEdit

  • Problem: At the moment, it is not possible to have feedback from a majority of people, because:
    • they are not following community discussions boards
    • go to a given page is an effort, and everyone can have very good reasons not to express how they feel about something
    • there is no way to collect their opinion in a given context
    Some examples :
    • to leave feedback about a feature you have to be experienced. Users/readers have to understand the structure of the whole wiki to try to search for a page where they can leave some feedback (find it is not guaranteed).
    • help pages maintainers do their best to write Help pages (so as Editors on pages). But they don't know if those pages are useful for their audience, unless if someone understands there is a Talk tab and leave a message there (hint: it never happens).
    • ...
  • Who would benefit: Anyone, because the cases are multiple:
    • People who don't know they can express their opinion about something or help improving it.
    • People improving stuff, to get direct input about something very specific, on a given context.
    • Help pages writers to create better pages and people looking for more information, to give feedback about the page they are reading and then benefit about that improvement.
    • Developers and users for an easier feedback about a given feature.
    • Editors who want to know if a part of the page they are working on is easy to understand.
    • ...
  • Proposed solution:
    Have a way for anyone to be surveyed about something specific. It can be to say if they have found what they were expecting, how they feel about a given feature...
    It is just a yes/no question. This is the case for some on line documentation, like on Google help pages where you can say if you have found the page helpful. In the case there is a minority of no, a link should be added to point to a topic where people can explain what they were expecting.
  • More comments:
    • That task was first drafted as "have a way to know if people find what they are looking for on Help pages" but has been extended a but to have that yes/no solution as an unified practice
    • Some people may recall the Article feedback tool. That tool was very useful to collect feedback on help pages. That extension was not perfect, the wording used was prompting people to deliver unuseful feedback, and its focus was on articles. Removing comments curation would simplify the task a lot.


  • This would be super useful but also a lot of work. I imagine the controls would end up of similar complexity to CentralAuth, except that you'd also have to collect/display results. Not really a wishlist level thing IMO. --Tgr (talk) 07:36, 28 November 2017 (UTC)
    Tgr, it can also be simpler, with a script called by a template, to leave opinions and comments on a sub-page. Maybe like the Support button used on this page, but as an extension. Trizek from FR 10:00, 28 November 2017 (UTC)
  • Salut Trizek,
    Ça fait un temps que je me dis qu'il faudrait un outil simple permettant d'obtenir du feedback des lecteurs. En effet, la plupart d'entre-eux ne connaissent pas la page de discussion des articles et ne savent pas comment y intervenir. Cependant, comme souligné dans les votes ci-bas, l'article feedback a été un retentissant échec à ce niveau.
    En quoi penses-tu que l'initiative que tu proposes aura un meilleur succès ? Simon Villeneuve 15:48, 29 November 2017 (UTC)
    Salut Simon, je pense qu'un outil plus simple, avec un usage non-systématique et ponctuel aidera a collecter des retours plus pertinents. Également, comme noté plus bas, la manière dont les choses étaient formulées a amené à pas mal de retours inutiles. Bref, un système auquel on répond par oui/non sera a mon avis utile et gagnant. Trizek from FR 20:53, 30 November 2017 (UTC)
  • Very good tool to have, indeed. Two comments-suggestions. •(1) As a user, I am always pleased to give my opinion, especially in a quick and easy manner. And therefore, I find a yes-no question proposition, a clever feature... as long as I am to reply "yes"; if it's a "no" for me, I feel frustrated if I can't explain my disproval or disagreement, since there are so many ways to not be "aligned" with a given solution (the one stated by the question) and only one to agree (welcome in our Ā-world (null-A)). This means I can't really participate to correction or improvment, and I feel this "no" like a useless "bark" ; simply adding the possibility to add a (discrete) link toward a discussion page or something equivalent, eventualy more user-friendly, in order to collect a few words of explanation, comment, growl, or of gratefulness, why not, would be fine ; a click toward a new window/dialog/ is not a puzzle when you are ready to type few words. •(2) As a potential user of the tool, making it a bit more universal, such as allowing for a quiz, a multiple choice question, would be really great, probably with not a great supplementary effort. Examples: completing the yes-no alternative by one or several (not semantically equivalent) choices such as "maybe", "no_opinion", "unconcerned", or a graduated answer such as "positively yes"-"yes"-"mostly agreing"-"balanced, undecided"-"mostly against"-"non"-"strongly no", or a "0 to 10" scale of agreement (but programing a slider is quite different than just a bunch of radio buttons, i guess). Whatever the answer, a level-0 tool, simple "yes-or-no" alternative, will be a great addition. --Eric.LEWIN (talk) 01:35, 30 November 2017 (UTC)
    Thanks Eric.LEWIN! Your to have a link to a talk page where you can expand what you think of the feature and explain your vote is definitely something to consider into the product definition. Have a dialog input may encounter the same problems the article feedback tool has, with usefulness comments. I also like your idea of having multiple choices, or a scale; that would be nice! Maybe for an iteration? Yes/No would be great as a first step that can go beyond. Thanks! Trizek from FR 20:53, 30 November 2017 (UTC)
  • There are a few hurdles with this onde, even if it is quite nice. There are even research papers about it! First, there must be a cost with a system like this, otherwise it turns into a like-system. Then the users must be allowed to vote on a scale to express how they feel about the question. Because different people express their feelings differently the votes must be normalized somehow. Lastly the scales are for different dimensions, which might be overlapping or duplicated, so they must be folded into a lower dimension to make sense. This folding to a lower dimensional space is non-trivial. (Yes you can use PCA, but it will most likely create a mess.) — Jeblad 00:02, 11 December 2017 (UTC)


  •   Support Strainu (talk) 22:56, 27 November 2017 (UTC)
  •   Oppose We've tried this with mw:Article feedback/Version 5; it turned into a glorified like button. No. MER-C (talk) 01:40, 28 November 2017 (UTC)
  •   Support Helpful for assistance pages. --Omnilaika02 (talk) 10:46, 28 November 2017 (UTC)
  •   Support, provided we don't revert to Article feedback (as MER-C, I felt Article feedback was just some kind of oversized "Like" button, all the more as Talk Pages and Good/Featured Articles procedures are much more effective to advance articles, at different stages of their development). But some easy feedback for new technical features, for instance, would probably be helpful. Still, I have some doubts about the exact scope as well as practical issues. --Azurfrog (talk) 11:49, 28 November 2017 (UTC)
  •   Support --Liuxinyu970226 (talk) 13:12, 28 November 2017 (UTC)
  •   Support A good way to give new contributors an opportunity to express there needs, and thus stay at task in Wikipedia... Salix (talk) 13:33, 28 November 2017 (UTC)
  •   Support Kurt Jansson (talk) 21:44, 28 November 2017 (UTC)
  •   Support Thomas Obermair 4 (talk) 21:56, 28 November 2017 (UTC)
  •   Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 10:22, 29 November 2017 (UTC)
  •   Support MichaelSchoenitzer (talk) 19:57, 29 November 2017 (UTC)
  •   Support I think the success of such a tool lies in the semantics of its use, in the phrasing and the wording of the question and its answers, not in the tool by itself. --Eric.LEWIN (talk) 01:42, 30 November 2017 (UTC)
  •   Support Exilexi (talk) 15:07, 30 November 2017 (UTC)
  •   Support Goodship11 (talk) 16:18, 30 November 2017 (UTC)
  •   Support Yes ! Gonzolito (talk) 14:36, 1 December 2017 (UTC)
  •   Support Simon Villeneuve 16:01, 1 December 2017 (UTC)
  •   Support Pamputt (talk) 18:54, 1 December 2017 (UTC)
  •   Support Lofhi (talk) 19:48, 1 December 2017 (UTC)
  •   Support Ckoerner (talk) 21:51, 1 December 2017 (UTC)
  •   Support Whats new? (talk) 00:16, 2 December 2017 (UTC)
  •   Support --Benoît Prieur (talk) 12:51, 2 December 2017 (UTC)
  •   Support enL3X1 ¡‹delayed reaction›¡ 15:53, 3 December 2017 (UTC)
  •   Support FULBERT (talk) 19:16, 3 December 2017 (UTC)
  •   Support like articlefeedback5? Gryllida 00:54, 4 December 2017 (UTC)
  •   Support Excellent idea —— DePlusJean (talk) 17:22, 4 December 2017 (UTC)
  •   Support WhatamIdoing (talk) 18:14, 4 December 2017 (UTC)
  •   Support Elitre (talk) 17:00, 5 December 2017 (UTC)
  •   Oppose per MER-C, and not a development priority. Kudpung (talk) 20:40, 6 December 2017 (UTC)
  •   Support Ahm masum (talk) 21:40, 7 December 2017 (UTC)
  •   Support Spinster (talk) 21:17, 10 December 2017 (UTC)
  •   SupportJeblad 00:03, 11 December 2017 (UTC)
  •   Support Psychoslave (talk) 08:06, 11 December 2017 (UTC)
  •   Support Yohannvt (talk) 11:50, 11 December 2017 (UTC)

Word count on statisticsEdit

  • Problem: We don't have an actual word count since 2014, and this is a basic statistic to calculate Wikipedia's size
  • Who would benefit: Statistic-lovers and everyone who want to show the size of Wikipedia
  • Proposed solution: Having a word count from the dump would be the solution
  • More comments:


This is relatively straight forward, we already have the per-article word counts broken out (they are in search results), there just isn't a public way to ask for a sum. FWIW a sum on content index currently reports: 3.049711774E9 EBernhardson (WMF) (talk) 03:17, 18 November 2017 (UTC)

Where did you find this number? -Theklan (talk) 17:57, 20 November 2017 (UTC)
I wrote a custom query against the elasticsearch cluster to aggregate the stored word count (as I'm a developer working on search at WMF). I've put up a patch in code review to integrate this into Special:Statistics. I would expect this to be merged and roll out sometime in December. This is only the raw word count of pages considered articles, not any of the more advanced things discussed below. EBernhardson (WMF) (talk) 19:09, 28 November 2017 (UTC)
@Theklan: This has now rolled out to all wiki's, you can get the counts from the Special:Statistics page. 2601:648:8402:C015:307E:5334:1490:C6B9 19:09, 15 December 2017 (UTC)
@EBernhardson (WMF): Are you sure that this number is correct? The number was considerably higher in 2014 according to Wikistats. -Theklan (talk) 00:57, 16 December 2017 (UTC)
@Theklan: Wikistats may have been calculating something different, would have to dig into what they counted. This particular count takes the content (main namespace), removes some non-content portions (tables, hatnote's, etc) and then counts the number of individual words (as determined by tokenization with lucene, the same used for full text search). If we were to include non-content pages the value would increase from 3.1 billion to 11.3 billion. EBernhardson (WMF) (talk) 17:58, 17 January 2018 (UTC)

I would suggest taking this further with basic readability statistics. there are various well-established metrics, but even simple things like average words-per-sentence and syllables-per-word would be helpful. T.Shafee(Evo﹠Evo)talk 11:02, 18 November 2017 (UTC)

Readability metrics are misleading and bullshit. Source: I built one. --Dispenser (talk) 18:03, 20 November 2017 (UTC)

Note: This idea was also suggested at wikitech-l a few days ago, and a reply pointed out a userscript that does a very simple version. Quiddity (WMF) (talk) 19:52, 20 November 2017 (UTC)

User:Dr pda made a byte and word counter years back and lists issues with counting "article text". The reason why people like word count is "100 words = 1 minute of reading" (without regard to textual difficulty). Naturally excludes infoboxes, tables, images, navboxes, etc. --Dispenser (talk) 21:10, 20 November 2017 (UTC)
Yes, but I don't want a script that measures the word count of a given article, but the global number of words in the whole Wikipedia project. There's a difference there! -Theklan (talk) 12:03, 21 November 2017 (UTC)


Responsive CSS/Template Framework for Media WikiEdit

  • Problem:

Most of the help and meta pages are in Wikipedia and other WikiProjects are cobbled with strange copy'n'paste constructions of Templates, HTML and InlineStyles. This leads to an inconsistent, hard to maintain interface, that fails on many platforms. A lot of the editors maintaining these pages are not programmers. Since there is no simple comprehensible library where they can find all the buttons, boxes, grids and teasers. Most of them copy just what they find on other meta-pages - often without really understanding how it works.

  • Who would benefit:

Readers and Editors alike

  • Proposed solution:
    Create a simple but effective library of CSS-Styles (like Bootstrap) and MediaWiki-Templates, that enables editors to quickly create interfaces that work on all devices and screen sizes and has a consistent look and feel. Possible components are:
    • Buttons
    • Teaser-Boxes
    • Form-Elements
    • A Grid-System
  • More comments:
  • Phabricator tickets:


If I understand correctly, this would be like T90687, except scoped for the content area, not the software/skin area. That would be a great thing to have, although potentially a lot of work (it would have to take into account different devices, different skins, RTL...) Developers would probably benefit just as much editors/readers as it would be easier to make assumptions about how articles look / wrangle the content to be appropriate for mobile screens.

@Martin Kraft:: The proposal could do with a less handwavy list of use cases IMO (forms and buttons are barely used in wikitext-generated content, and I imagine a grid and boxes would not be the only things to standardize; see also the various subtasks and blockers of T483).

For performance reasons this might depend on TemplateStyles (although if it's not too much overhead we might just prefer to load such a framework on all pages; especially if the original, software-interface-oriented version of T90687 does get done and uses the same rules). --Tgr (WMF) (talk) 02:09, 21 November 2017 (UTC)


Making Mediawiki MOOC-readyEdit

  • Problem: The Wikiversity missed the massive open online course (MOOC) train. Even the WikiMOOC, which teach how to contribute to Wikipedia, wasn't hosted on Wikiversity. For our movement to gains acceptance in the educational field, and eager of people to learn through MOOC platforms, Mediawiki needs a serious upgrade. This could be in the form of an upgrade to the MW:Extension:Quiz extension.
  • Who would benefit: The Wikiversity communities, of course, but also anyone looking for an inhouse MOOC platform. Plus, more contributors and content on a single linguistic Wikversity version make it far more likely to find benevolent translators through its skilled community and its already well tooled translation environment.
  • Proposed solution:
    • enable users to follow their progress by giving ability to record result of evaluation form
    • provide
      • ease publication of existing courses
      • possibly, way to validate knowledge/skill acquisition
        • online, with some strong identity control and avoidance of least elaborated cheat
        • offline, with tool which ease coordination of exam sessions in dedicated places
    • establishing a list of feature that a MOOC platform must have to be successful is part of this proposal, please feed the proposal
  • More comments:
  • Phabricator tickets:


  • See also Wikimedia MOOC platform and related Phabricator project for an on-going discussion on this matter. — The preceding unsigned comment was added by Noé (talk)
    This could also just be an improvement of MW:Extension:Quiz to allow the exercises results persistence and consultation. JackPotte (talk) 18:03, 8 November 2017 (UTC)
    That's indeed one aspect to improve it. But it also should be improved in UX terms, so users might create forms with the VE for example. Also I don't remember if it's already possible to have a larger set of question than the one displayed so the user might face different set of questions each time. Adding a difficulty score to each question, one might also adapt questions to the user previous results. Probably a large bunch of that might be implemented with modules and templates which takes care of all the adaptive behaviour, but data persistence and form edit UX are less likely implementable without dedicated development in the extension. --Psychoslave (talk) 11:12, 9 November 2017 (UTC)
    The MOOC module has been implemented on Wikiversity in Portuguese, and we are now developing our first course. We have relied on the modules that were released on Wikiversity in English, for instance the course on Web Science. I agree these modules would benefit with some improving. --Joalpe (talk) 03:47, 9 November 2017 (UTC)
    Thank you I wasn't aware of that. I think that we should spread the word within versions of Wikiversity. --Psychoslave (talk) 11:12, 9 November 2017 (UTC)
  • I'd like to note that this proposal as it currently stands is very vague. What exact changes are you proposing? The community tech team works on software development, not partnerships with institutions. Is there consensus for what you're asking for? -- NKohli (WMF) (talk) 21:39, 20 November 2017 (UTC)
@Psychoslave: please see my above comment. -- NKohli (WMF) (talk) 00:24, 22 November 2017 (UTC)

Hi @NKohli:,

What exact changes are you proposing?
I think that the less vague demand is an improvement of the Quiz extension
  • it should allows users to keep a record of their previous results. The legal team should also take a look at this for privacy consideration I think.
    • A board which enable to have an overview of progress would be fine too.
  • editors should be able to use only visual editor to build quiz forms

For institutional partners, we actually already have some, at least on the French Wikiversity we have courses which were provided by the CNED like Mise en œuvre de l’accessibilité numérique and Convertir une formation existante au format MOOC. So no one seems against this kind of partnership. Providing more suited tools will only help to attract more release of courses by institutional structures.

Does this answer your demand? --Psychoslave (talk) 07:56, 22 November 2017 (UTC)

Yes, sorry for the late reply. You pinged the wrong person. I'll update the proposal description a bit according to your revised version. Thanks. -- NKohli (WMF) (talk) 23:38, 27 November 2017 (UTC)

Feels like Not Invented Here syndrome. Surely it is easier and more productive to fix an exiting, high-quality MOOC framework to use MediaWiki authentication, design and stats, than to implement some half-baked MOOC functionality in an extension... --Tgr (talk) 08:24, 28 November 2017 (UTC)


  •   Support --Liuxinyu970226 (talk) 13:12, 28 November 2017 (UTC)
  •   Support Thomas Obermair 4 (talk) 21:57, 28 November 2017 (UTC)
  •   Support Sebastian Wallroth (talk) 07:30, 29 November 2017 (UTC)
  •   Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 10:21, 29 November 2017 (UTC)
  •   Support —— DePlusJean (talk) 09:17, 30 November 2017 (UTC)
  •   Support Exilexi (talk) 14:54, 30 November 2017 (UTC)
  •   Support Risk Engineer (talk) 23:28, 30 November 2017 (UTC)
  •   Support Wolbo (talk) 13:15, 2 December 2017 (UTC)
  •   Support Yair rand (talk) 22:24, 3 December 2017 (UTC)
  •   Support Gryllida 00:55, 4 December 2017 (UTC)
  •   Support Improving Q and A support across our platforms would be good. Doc James (talk · contribs · email) 02:31, 5 December 2017 (UTC)
  •   Support Zerabat (discusión) 06:29, 7 December 2017 (UTC)
  •   Support Training, be it from the WMF to Affiliates and program leaders, or from one Affiliate to its local context is going to be evermore a need. If we can integrate it to the Wikimedia platform, perhaps grafted on top of Wikiversity, we won't be depending on external tools. This means tracking participants' achievements, and eventually certifying those. VMasrour (WMF) (talk) 16:46, 8 December 2017 (UTC)
  •   Support #Unknown (talk) 16:53, 8 December 2017 (UTC)
  •   Support Tiputini (talk) 10:49, 10 December 2017 (UTC)
  •   Support Psychoslave (talk) 08:07, 11 December 2017 (UTC)
  •   Support, this would make Wikiversity more useful and more used — NickK (talk) 16:59, 11 December 2017 (UTC)

Add filters to history pagesEdit

  • Problem: On some of the high traffic pages, due to volume of activity, it is difficult to identify true authors or find other editing patterns.
  • Who would benefit: Admins and editors investigating page histories.
  • Proposed solution: Add ability to filter/sort page histories, by for example:
    • Show/hide IP edits
    • Show/hide reverted edits and their reverts
    • Show/hide banned user edits
    • Show/hide bot edits
    • Show/hide minor edits
    • Show/hide edits by number of bytes added/subtracted
    • Show/hide my edits – definitely a necessity
    • Show/hide selected user's edits (if this is deemed uncontroversial)
    • Show/hide deleted edits (for administrators only?)
  • More comments:


  • Nice idea.
    • I had similar plans in background, since that wish came up once in a year in German Wikipedia.
    • There was no broad cry for such a feature.
    • I already mantain w:en:User:PerfektesChaos/js/listPageOptions modifying watchlists and “recent changes”, and I might extend that to history pages with similar options a watchlist already offers. Or mw:User:PerfektesChaos/js/resultListSort which is sorting about 30 special pages.
    • What is a “banned user edit”?
    • “reverts” are edits as any other; they bear no special mark and only full rollback uses a project dependant summary. Simple reverts offer editable summary.
    • IP / registered user, user him/herself edit, bot edit, minor edit, number of bytes less greater than, no summary, personal list of suspicious/interesting users (will need to be stored outside public pages for privacy reasons) – those may be subject to be shown or hidden; or, more likely, to be sorted, showing interesting things in one block together.
    • If this wish is not picked up, I ponder if and how I might implement this.
Greetings --PerfektesChaos (talk) 11:00, 16 November 2017 (UTC)

Added some possible filter options. --Vachovec1 (talk) 22:43, 18 November 2017 (UTC)

Ad PerfectedChaos comments:

  • Reverts: what? "Normal" revert (clicking on "undid" in diff interface) has editable summary, sure, but if not completely overwritten, the summary every times begins with words like "Undid revision (number) by (user)" (for English) or similar predefined sequence for other languages. But you probably can't indentify reverts made with "save this old version of page" method.
  • Banned user: I can imagine A) currently blocked user or B) user marked with template en:Template:Banned user (or with something similar).

--Vachovec1 (talk) 22:43, 18 November 2017 (UTC)

Introducing the edit filters already used elsewhere seems like a logical step UX-wise (although not sure how well the database would cope for large articles without major changes to our infrastructure). For reverts, see also T152434. --Tgr (WMF) (talk) 23:46, 18 November 2017 (UTC)

There is also c:MediaWiki:Gadget-rightsfilter.js. Helder 23:38, 29 November 2017 (UTC)
  • The essential tool I always needed and didn't realise it was missing untill this poll. Would really save a lot of time. Very useful for COIN, SPI, and research into other persistent disruption. Up till now I have to copy an entire page history into a regex propgram and do it from there (and I'm not a regex or a Quarry expert like much of Wikipedia expects every normal user and admin to be. Kudpung (talk) 20:51, 6 December 2017 (UTC)
  • The efficient way to identify reverts is by using the digest. Anyway, the history should be collapsed when a revert is detected. It should also be collapsed for consecutive edits. Note also that "to identify true authors" is extremely difficult. What is a true editor. — Jeblad 01:09, 11 December 2017 (UTC)


  •   Support Definitely needed. Vachovec1 (talk) 20:25, 27 November 2017 (UTC)
  •   Support β16 - (talk) 11:08, 28 November 2017 (UTC)
  •   Support --Liuxinyu970226 (talk) 13:12, 28 November 2017 (UTC)
  •   Support Like AdvancedSearch, show/hide edit summary contains specified words, and same user edits combining (continuous/non-consecutive), even added/removed text filter. YFdyh000 (talk) 15:03, 28 November 2017 (UTC)
  •   Support — Draceane talkcontrib. 18:18, 28 November 2017 (UTC)
  •   Support Yiyi (talk) 18:52, 28 November 2017 (UTC)
  •   Support Rcsprinter123 (talk) 20:02, 28 November 2017 (UTC)
  •   Support Thomas Obermair 4 (talk) 21:57, 28 November 2017 (UTC)
  •   Support Really needed feature. Jules78120 (talk) 00:19, 29 November 2017 (UTC)
  •   Oppose "Banned users" can also include prolific editors such as Kevin Rutherford and INeverCry whose edits appear in a lot of pages, note that not every banned user is banned because of vandalism, a good content editor who got permabanmed because of edit-warring isn't the same as someone who actually vandalised an article but both are called "trolls". --Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 10:20, 29 November 2017 (UTC)
  •   Support Swpb (talk) 20:54, 29 November 2017 (UTC)
  •   Support Seb26 (talk) 21:53, 29 November 2017 (UTC)
  •   SupportMeiræ 22:11, 29 November 2017 (UTC)
  •   Support Bardia90 (talk) 22:16, 29 November 2017 (UTC)
  •   Support Sounds very useful for the Poirots amongst us Nick Moyes (talk) 22:58, 29 November 2017 (UTC)
  •   Support - Evad37 (talk) 23:56, 29 November 2017 (UTC)
  •   Support Kaganer (talk) 08:53, 30 November 2017 (UTC)
  •   Support קובץ על יד (talk) 12:11, 30 November 2017 (UTC)
  •   Support Daniel Case (talk) 03:09, 1 December 2017 (UTC)
  •   Support JAn Dudík (talk) 06:25, 1 December 2017 (UTC)
  •   Support CosmosAway (talk) 16:41, 1 December 2017 (UTC)
  •   Support --Superchilum(talk to me!) 20:58, 1 December 2017 (UTC)
  •   Support Ckoerner (talk) 21:51, 1 December 2017 (UTC)
  •   Support Jo-Jo Eumerus (talk, contributions) 11:24, 2 December 2017 (UTC)
  •   Support ديفيد عادل وهبة خليل 2 (talk) 14:56, 2 December 2017 (UTC)
  •   Support Termininja (talk) 17:39, 2 December 2017 (UTC)
  •   Support Matěj Suchánek (talk) 10:33, 3 December 2017 (UTC)
  •   Support Tacsipacsi (talk) 12:26, 3 December 2017 (UTC)
  •   Support enL3X1 ¡‹delayed reaction›¡ 16:07, 3 December 2017 (UTC)
  •   Support Giraffedata (talk) 22:27, 3 December 2017 (UTC)
  •   Support Sorely needed. TheNavigatrr (talk) 01:21, 4 December 2017 (UTC)
  •   Support Yes, yes, yes, yes, and more yes.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  07:35, 4 December 2017 (UTC)
  •   Support Yes please. --Anthonyhcole (talk) 11:45, 4 December 2017 (UTC)
  •   Support Nice idea! Pau Colominas (talk) 16:22, 4 December 2017 (UTC)
  •   Support --Tractopelle-jaune (talk) 18:13, 4 December 2017 (UTC)
  •   Support Guycn2 · 19:31, 4 December 2017 (UTC)
  •   Support Vincent Simar (talk) 11:50, 5 December 2017 (UTC)
  •   Support Elmidae (talk) 18:49, 5 December 2017 (UTC)
  •   Support Thisisnotcam (talk) 06:03, 6 December 2017 (UTC)
  •   Support Excellent idea. Kudpung (talk) 20:46, 6 December 2017 (UTC)
  •   Support Me-123567-Me (talk) 21:51, 6 December 2017 (UTC)
  •   Support Hide reverted edits and hide bot edits sound like they would be particularly useful. the wub "?!" 00:39, 7 December 2017 (UTC)
  •   Support --Jarekt (talk) 14:23, 7 December 2017 (UTC)
  •   Support Ahm masum (talk) 21:30, 7 December 2017 (UTC)
  •   Support Uanfala (talk) 16:04, 9 December 2017 (UTC)
  •   Support X:: black ::X (talk) 10:31, 10 December 2017 (UTC)
  •   Support Ruslik (talk) 18:12, 10 December 2017 (UTC)
  •   Support Jack who built the house (talk) 21:39, 10 December 2017 (UTC)
  •   Support Salpynx (talk) 10:47, 11 December 2017 (UTC)
  •   Support, I think edit filters on article histories are even more useful than on recent changes (have you ever tried to identify what was the correct statement before some vandal changed it a few years ago?) — NickK (talk) 17:00, 11 December 2017 (UTC)

Overhaul spam-blacklistEdit

  • Problem: The current blacklist system is archaic; it does not allow for levels of blacklisting, is confusing to editors. Main problems include that the spam blacklist is indiscriminate of namespace (an often re-occurring comment is that it should be possible to discuss about a link in talkspaces, though not to use it in content namespaces). The blacklist is a black-and-white choice, allowing additions by only non-autoconfirmed editors, or only by admins is not possible. Also giving warnings is not possible (on en.wikipedia, we implemented XLinkBot, who reverts and warns - giving a warning to IPs and 'new' editors that a certain link is in violation of policies/guidelines would be a less bitey solution).
  • Who would benefit: The community at large
  • Proposed solution: Basically, replace the current mw:Extension:SpamBlacklist with a new extension based on mw:Extension:AbuseFilter by taking out the 'conditions' parsing from the AbuseFilter and replace it with only parsing regexes matching added external links (technically, the current AbuseFilter is capable of doing what would be needed, except that in this form it is extremely heavyweight to use for the number of regexes that is on the blacklists). Expansions could be added in forms of whitelisting fields, namespace selectors, etc.
expanded solution
The following discussion has been closed. Please do not modify it.
  1. Take the current AbuseFilter, rename it to SpamFilter, take out all the code that interprets the rules ('conditions').
  2. Make 2 fields in replacement for the 'conditions' field:
    • one text field for regexes that block added external links (the blacklist). Can contain many rules (one on each line, like current spam-blacklist).
    • one text field for regexes that override the block (whitelist overriding this blacklist field; that is generally simpler and cleaner than writing a complex regex, not everybody is a specialist on regexes).
  3. Add namespace choice (checkboxes like in search; so one can choose not to blacklist something in one particular namespace, with addition of an 'all', a 'content-namespace only' and 'talk-namespace only'.
    • Some links are fine in discussions but should not be used in mainspace, others are a total nono
    • Some image links are fine in the file-namespace to tell where it came from, but not needed in mainspace
  4. Add user status choice (checkboxes for the different roles, or like the page-protection levels)
    disallow IPs and new users to use a certain link (e.g. to stop spammers from creating socks, while leaving it free to most users).
  5. Leave all the other options:
    • Discussion field for evidence (or better, a talk-page like function)
    • Enabled/disabled/deleted - not needed, turn it off, obsolete then delete
    • 'Flag the edit in the edit filter log' - maybe nice to be able to turn it off, to get rid of the real rubbish that doesn't need to be logged
    • Rate limiting - catch editors that start spamming an otherwise reasonably good link
    • Warn - could be a replacement for en:User:XLinkBot
    • Prevent the action - as is the current blacklist/whitelist function
    • Revoke autoconfirmed - make sure that spammers are caught and checked
    • Tagging - for combining certain rules to be checked by RC patrollers.
    • I would consider to add a button to auto-block editors on certain typical spambot-domains (a function currently taken by one of Anomie's bots on en.wikipedia).

This should overall be much more lightweight than the current AbuseFilter (all it does is regex-testing as the spam-blacklist does, only it has to cycle through maybe thousands of AbuseFilters). One could consider to expand it to have rules blocked or enabled on only certain pages (for heavily abused links that actually should only be used on it's own subject page). Another consideration would be to have a 'custom reply' field, pointing the editor that gets blocked by the filter as to why it was blocked.

Possible expanded features:

  1. block or whitelist links matching regexes on specific pages (disallow linking throughout except for on the subject page)
  2. block or whitelist links matching regexes when added by specific user/IP/IP-range (disallow specific users to use a domain)
  • More comments:
  • Phabricator tickets: task T6459 (where I proposed this earlier)


  • I agree, the size of the current blacklists is difficult to work with; I would be blacklisting a lot more spam otherwise. A split of the current blacklists is also desired:
  • I still want to see a single, centralized, publicly available, machine readable spam blacklist for all the spammers, bots, black hat SEOs and other lowlifes so that they can be penalized by Google and other search engines. This list must continue to be exported to prevent spam on other websites. Autoblocking is also most useful here.
  • The same goes for URL shorteners and redirects -- this list would also be useful elsewhere. This is one example where the ability to hand out customized error messages (e.g. "hey, you added a URL shortener; use the original URL instead") is useful.
  • The remaining domains might belong on a private list with all the options described above.
  • Please consider integrating the extension into core MediaWiki; it is already bundled with the installer. MER-C (talk) 11:57, 14 November 2017 (UTC)
    • Do note that there are a lot of domains on the blacklist which are not due to 'lowlifes' - quite a number of pornographic sites are blacklisted because of uncontrollable abuse, not because of them being spammed, let alone by site-owners or their SEOs. Also URL shorteners are blocked because of nature and abuse, not because of themselves being spam. In those cases I actually agree with complaints that these sites are penalized for being on the blacklists. I do agree that a full list of those domains that are due to the SEO/spammers/bots and other lowlifes should be publicly visible (note: COIBot and LiWa3 collect all the blacklists in off-wiki files for referencing purposes, it would be rather easy to publish those collective records on-wiki as public information). --Dirk Beetstra T C (en: U, T) 12:12, 14 November 2017 (UTC)
  • Another suggestion: one needs to have the option to match against norm(added_lines) instead for continued spamming of blacklisted links. I've seen forum spam that needs this solution, we need to have an equivalent here as well. MER-C (talk) 12:28, 14 November 2017 (UTC)
    • Check, but I think that that type of parsing is (partially?) in the current blacklist. I have seen XLinkBot-evasion by using hex-codes (which I subsequently coded into the bots). --Dirk Beetstra T C (en: U, T) 12:31, 14 November 2017 (UTC)
  • @Beetstra: For the sake of clearance: you want to replace AbuseFilter extension or you want to add a new extension based on AbuseFilter? --Vachovec1 (talk) 21:20, 14 November 2017 (UTC)
    • This proposes to replace mw:Extension:SpamBlacklist with this functionality. MER-C (talk) 03:03, 15 November 2017 (UTC)
    • @Vachovec1: I want add a new extension based on AbuseFilter (that seems to me the most logical start, as functionality in the AbuseFilter is quite appropriate, but too heavy for this), to replace the current spam-blacklist. --Dirk Beetstra T C (en: U, T) 05:22, 15 November 2017 (UTC)

My issue with this (as I have with supposed “spam-fighting”) is that it takes way too much collateral damage both when it comes to users as when it comes to content, many useful sites are blacklisted purely because a user is banned, and if a user gets globally banned the link 🔗 gets globally blacklisted and removed from any Wikimedia property even if it were used as a source 100% of the time, now let's imagine a year or so later someone wants to add content using that same link (which is now called a “spamlink”) this user will be indefinitely banned simply for sourcing content. I think 🤔 that having unsourced content is a larger risk to Wikimedia projects than alleged “spam” has ever been. This is especially worrisome for mobile users (which will inevitably become the largest userbase) as when you're attempting to save an edit it doesn't even warn you why your edit won't save, but simply says “error” so a user might attempt to save it again and then gets blocked for “spamming”. Abuse filters currently don't function 100% accurately, and having editors leave the project forever simply because they attempted to use “the wrong 👎🏻” reference is bonkers. Sent 📩 from my Microsoft Lumia 950 XL with Microsoft Windows 10 Mobile 📱. --Donald Trung (Talk 🤳🏻) (My global lock 😒🌏🔒) (My global unlock 😄🌏🔓) 10:15, 15 November 2017 (UTC)

Also after a link could be blacklisted someone might attempt to translate a page and get blocked, the potential for collateral damage is very high, how would this "feature" attempt to keep collateral damage to a minimum? --Donald Trung (Talk 🤳🏻) (My global lock 😒🌏🔒) (My global unlock 😄🌏🔓) 10:15, 15 November 2017 (UTC)
@Donald Trung: that is not going to change, actually, this suggestion is giving more freedom on how to blacklist and whitelist material. The current system is black-and-white, this gives many shades of grey to the blacklisting system. In other words, your comments are related to the current system.
Regarding the second part of your comment - yes, that is intended use of the system, if it is spammed to page one, then translating that page does not make it a good link on the translation (and actually, this situation could actually also be avoided in the new system). --Dirk Beetstra T C (en: U, T) 10:39, 15 November 2017 (UTC)
  • The blacklist currently prevents us from adding a link to a site, from the article about that site. This is irrational. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:03, 15 November 2017 (UTC)
    • @Pigsonthewing: What do you mean, do I have an unclear sentence? If it is what I think, is that I would like per-article exceptions (though that is a less important feature of it). --Dirk Beetstra T C (en: U, T) 14:29, 15 November 2017 (UTC)
    • Ah, I think I get it, you are describing a shortcoming of the current system - that is indeed one of the problems (though there are reasons why sometimes we do not want to do that (e.g. malware sites), or where the link gets more broadly blacklisted (we blacklist all of .onion, which is then indeed not linkable on .onion, but also not on subject X whose official website is a .onion .. ). But the obvious cases are there indeed. I would indeed like to have the possibility to blanket whitelist for specific cases, like <subject>.com on <subject> (allowing full (primary) referencing on that single page, it is now sometimes silly that we have to allow for a /about to link to a site on the subject Wikipage to avoid nullifying the blacklist regex, or a whole set of specific whitelistings to allow sourcing on their own page), or on heavily abused sites really allow whitelisting only for a very specific target ('you can only use this link on <subject> and nowhere else'). --Dirk Beetstra T C (en: U, T) 14:35, 15 November 2017 (UTC)

Or just add an option to AbuseFilter to compare against a regexp list that's on a wikipage. (Would require some thought in that we might want to expose the matching rule in the error message and logs, but otherwise easy.)

More generally, it would be nice if we could standardize on AbuseFilter instead of having five or six different anti-abuse systems with fractured UX and capabilities. That's a bit beyond CommTech's scope though. --Tgr (WMF) (talk) 23:54, 18 November 2017 (UTC)

No, User:Tgr (WMF), using the current AbuseFilter for this is going to be a massive overload of the servers, it will still interpret the whole rule and we would probably have hundreds if not thousands of separate filters for this. It also would not allow for whitelisting (unless, again, you write a full rule with even more overload), namespace exclusion (unless ..), user-level exclusion (unless ..).
Making the AbuseFilter more modular may be an idea .. please read my suggestions above as a detailed request for capabilities. I am not familiar with the coding of the AbuseFilter to see how far this would need to go. --Dirk Beetstra T C (en: U, T) 11:00, 20 November 2017 (UTC)


  •   Support per my comment above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:47, 27 November 2017 (UTC)
  •   Support MER-C (talk) 01:54, 28 November 2017 (UTC)
  •   Support --Liuxinyu970226 (talk) 13:12, 28 November 2017 (UTC)
  •   Support Sadads (talk) 13:43, 28 November 2017 (UTC)
  •   Support Thomas Obermair 4 (talk) 21:57, 28 November 2017 (UTC)
  •   Support Darylgolden (talk) 14:24, 29 November 2017 (UTC)
  •   Support MGChecker (talk) 22:14, 29 November 2017 (UTC)
  •   Support --Dirk Beetstra T C (en: U, T) 08:01, 30 November 2017 (UTC)
  •   Support Jo-Jo Eumerus (talk, contributions) 11:25, 2 December 2017 (UTC)
  •   Support Galobtter (talk) 12:48, 3 December 2017 (UTC)
  •   Support enL3X1 ¡‹delayed reaction›¡ 16:10, 3 December 2017 (UTC)
  •   Support This will fix multiple problems at once.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  07:37, 4 December 2017 (UTC)
  •   Support Doc James (talk · contribs · email) 02:32, 5 December 2017 (UTC)
  •   Support blacklist support needs some attention to make sure the system scales well and allows discussing individual links, etc. Also In the past I had issues with pages that had Public Domain images downloaded from website which was latter added to a black list. As a result, it was impossible to add and remove categories to the file without tripping the blacklist. Even for an admin. That issue might have been fixed, but we need a flexible system that can recognize new text from an old one and objection can be overruled if needed. --Jarekt (talk) 14:34, 7 December 2017 (UTC)
    @Jarekt: I guess what you mention has been resolved (pages with blacklisted links are editable, as long as one does not add the link again). What you describe is however one of the examples I had in mind - there are certain links which are fine on talkpages or on file-description pages, but not in mainspace (though those cases are limited). --Dirk Beetstra T C (en: U, T) 12:46, 10 December 2017 (UTC)
  •   Support Ahm masum (talk) 21:27, 7 December 2017 (UTC)
  •   Support X:: black ::X (talk) 10:42, 10 December 2017 (UTC)
  •   Support — Luchesar • T/C 13:51, 11 December 2017 (UTC)
  •   SupportNickK (talk) 17:01, 11 December 2017 (UTC)

Allow filtering of recent changes and user contributions by whether they have been reverted or supersededEdit

  • Problem: Vandalism fighting in Wikidata is tougher than in other WMF projects because edits tend to be small and numerous. The Recent Changes page has plenty of filters to focus in on things like unpatrolled changes and whether the change is still the "latest version". However, if a piece of vandalism is not the "latest version" there is no way to tell if it has already been reverted or not, leading to unnecessary duplication of effort by users trying to fight vandals.
  • Who would benefit: All wikidata users would benefit from better vandalism-fighting. Those who work on patrolling would have a much easier job.
  • Proposed solution: When an "undo" action is taken on an edit, that should be indicated in Recent Changes and user contributions, and filterable. When a "restore" action is done to an earlier version than the edit, that should similarly be indicated and filterable (the same indicator would be fine). Similarly for rollbacks. Ideally any subsequent edit that deletes or changes the value of a statement (if that was what the edit was) or the label or description (if the edit was to a label or description) or sitelink (similarly) would also show that the original edit action was overridden.
  • More comments:
  • Phabricator tickets:


I don't see why this should be a Wikidata specific filter. Other projects might also benefit from being able to filter out reverted edits. ChristianKl (talk) 16:43, 9 November 2017 (UTC)

Yes I do think it would be a generally useful filter, but particularly useful with wikidata given the quantity of edits we have to deal with. Also the "superceded" portion of this is wikidata-specific (it's hard to judge on a general wiki page whether a damaging edit has just been replaced instead of an editor using 'undo' or 'restore', but in principle it could be done in wikidata). ArthurPSmith (talk) 18:14, 9 November 2017 (UTC)
I think in many cases it would be possible to judge also on Wikipedia that an edit is undone automatically. ChristianKl (talk) 20:16, 15 November 2017 (UTC)

ArthurPSmith: This is a good proposal, thanks for posting it. I think it would work for other projects as well as Wikidata, so I'm going to move it into the Miscellaneous category. Let me know if you think there's a different category where you think it would fit best. Thanks! -- DannyH (WMF) (talk) 18:21, 21 November 2017 (UTC)


Filter user contribution page by number of bytes changedEdit

  • Problem: It is difficult to identify "major" contributions of an editor, particularly if they are prolific editors and their edit history spans years and thousands of edits.
  • Who would benefit: Admins and editors reviewing user's contributions.
  • Proposed solution: Add a filter on user contribution pages to filter by the changes by number of bytes added/deleted. That way, for example, one could get a listing of user's contributions to the main space where they added more that 500 bytes.
  • More comments:
  • Phabricator tickets:


  • I wouldn’t say that this would be a particular benefit, profanity is usually added in smaller edits, and page blankings are already caught by various abuse filters. How would this benefit people more? --Donald Trung (Talk 🤳🏻) (My global lock 😒🌏🔒) (My global unlock 😄🌏🔓) 12:56, 10 November 2017 (UTC)
    • Good idea - you could identify the authors of larger changes more easily. I had this problem several times, i.e. when you want to propose a change or addition. --Bernd.Brincken (talk) 19:04, 14 November 2017 (UTC)
  • My tool mw:User:PerfektesChaos/js/resultListSort already offers sorting by page name/title of contributions.
    • As soon I find time I will extend this to sort contribution page alternatively back by date-time, by size, by summary.
    • Sorting is nearly the same as filtering but leaves the smaller number below. The page will be kept locally, but changes entry order as often as desired.
    • Note that this would work on existing result, not retrieving results from the server matching a condition.
    • There is already a filtering form, by namespace, by date, by minor, by current, by new accounts, by page creation. That might be extended by min/max size.
Greetings --PerfektesChaos (talk) 10:15, 16 November 2017 (UTC)
  • This is less useful, adding an infobox will bring a big change, and make translate or refine may be small or even reduced bytes. Period and sorting may be useful.--YFdyh000 (talk) 15:13, 28 November 2017 (UTC)
There is also c:MediaWiki:Gadget-rightsfilter.js. Helder 23:39, 29 November 2017 (UTC)


Provide a tool to efficiently analyze the usage of a templateEdit

  • Problem: Like last year, again I want to raise your attention to the fact that working with often used templates and making changes to them is a mess. Why? There is no tool or handy way to get to grips how the template has actually been used and which options one has to consider (or which pages where the template is used need to be edited) when rewriting a template. The tool written by User:Kolossos has been helpful for many years, but instead of providing live information it is based on dumps (most half a year old, some two years or even more), and there is no interface (you need to know how to manipulate the URL to filter the information). As someone wrote in last year's survey: While I have big respect to Kolossos' instrument, it's just not enough.
  • Who would benefit: Primarily users who curate and amend templates, secondarily authors who use templates in their articles
  • Proposed solution: Don't know if it is more likely to get Kolossos' tool improved or to get a whole new tool. Solutions that I'd like to see anyway:
    • For the timeliness of data: It'd be nice and a good start if there were at least a monthly update / a monthly dump that reliably gets fed into the tool. Having live data, of course, would be even more helpful.
    • Improving UX and usability: Please provide some interface to facilitate for example searching for a certain text in a certain template parameter, make the table sortable by mouseclick. The dream solution is an interface like the one we know from petscan.
  • More comments:
  • Proposer: → «« Man77 »» [de] 19:16, 14 November 2017 (UTC)


  • This is a useful tool. Also ping en:User:Bgwhite who might be able to help with updating Enwiki dump to a recent version. Looking at Tools in /data/project/templatetiger/public_html .. there is no entry for enwiki in einspielen.sql .. is this due to disk space constraints on Tools? -- GreenC (talk) 19:58, 14 November 2017 (UTC)
  • If I want to update the data I have the problem that I lose the database connection after short time. I don't know why.
    We have also a problem with some complex templates in German Wikipedia, which kill the checkwiki script. For my motivation as a user from Germany it would be nice to find a solution for this problem. --Kolossos (talk) 09:42, 15 November 2017 (UTC)
  • templateparam by Bambots does something similar/related right ? —TheDJ (talkcontribs) 13:43, 15 November 2017 (UTC)
    • Related: Probably yes. Similar: Not too much. → «« Man77 »» [de] 16:42, 19 November 2017 (UTC)
      • @Man77: Can you clarify how your request is different than the information provided by templateparam? (I'm not familiar with templatetiger and couldn't figure out how to use it.) Kaldari (talk) 21:01, 20 November 2017 (UTC)
        • To be honest, I did not know that this tool existed when I posted my request, and so far I have not really understood how to work with it. Stalemate. A tool that only works with the English Wikipedia is, however, absolutely not what I am looking for. → «« Man77 »» [de] 21:32, 20 November 2017 (UTC)
          • bambots tool only starts collecting information upon request and then only parsing the pages that transclude the actual template. This might require you to wait a bit after initially requesting the information for the first time for a particular template, but afterwards, its more up to date and as a benefit takes significantly fewer resources. The tool also allows you to check validity of param keys and values, by matching them with their TemplateData where possible. Not sure why it's only available for en.wp. Templatetiger seems a more brute force solution that parses all template usage. Both have their advantages, I guess, but both have commonalities as well. It should be noted however, that templatetiger is excluded from backups (quite rare) because of its size. —TheDJ (talkcontribs) 14:59, 21 November 2017 (UTC)
            • For my purposes having the template information "on request" would be enough, but the support of templates without TemplateData is not a mere nice-to-have. → «« Man77 »» [de] 17:23, 22 November 2017 (UTC)


  •   Support Dvorapa (talk) 09:26, 28 November 2017 (UTC)
  •   Support --Liuxinyu970226 (talk) 13:09, 28 November 2017 (UTC)
  •   Support Matěj Suchánek (talk) 14:59, 28 November 2017 (UTC)
  •   Support YFdyh000 (talk) 15:27, 28 November 2017 (UTC)
  •   Support — Draceane talkcontrib. 18:20, 28 November 2017 (UTC)
  •   Support Thomas Obermair 4 (talk) 21:58, 28 November 2017 (UTC)
  •   SupportTheDJ (talkcontribs) 14:35, 29 November 2017 (UTC)
  •   Supportputnik 01:33, 30 November 2017 (UTC)
  •   Support Would much help deprecation or deletion of unused functionalities, or ones which shouldn't be used but are. --Izno (talk) 03:54, 30 November 2017 (UTC)
  •   Support - yona B. (D) 08:18, 30 November 2017 (UTC)
  •   Support Sunpriat (talk) 16:19, 30 November 2017 (UTC)
  •   Support Ninovolador (talk) 22:09, 30 November 2017 (UTC)
  •   Support DonBarredora (talk) 01:19, 1 December 2017 (UTC)
  •   Support Theklan (talk) 18:42, 1 December 2017 (UTC)
  •   Support Nabla (talk) 23:16, 1 December 2017 (UTC)
  •   Support SEMMENDINGER (talk) 23:45, 1 December 2017 (UTC)
  •   Support Wostr (talk) 10:55, 2 December 2017 (UTC)
  •   Support ~Cybularny Speak? 12:23, 2 December 2017 (UTC)
  •   Support Wolbo (talk) 13:14, 2 December 2017 (UTC)
  •   Support«« Man77 »» [de] 14:01, 2 December 2017 (UTC)
  •   Support Termininja (talk) 17:05, 2 December 2017 (UTC)
  •   Support Waldir (talk) 10:44, 3 December 2017 (UTC)
  •   Support Galobtter (talk) 12:50, 3 December 2017 (UTC)
  •   Support Tacsipacsi (talk) 17:42, 3 December 2017 (UTC)
  •   Support JAn Dudík (talk) 09:24, 4 December 2017 (UTC)
  •   Support Anthonyhcole (talk) 11:52, 4 December 2017 (UTC)
  •   Support Trockennasenaffe (talk) 20:51, 4 December 2017 (UTC)
  •   Support Tools for analyzing template use would be great. I would also like to see some way of distinguishing direct and indirect use of the template. We have many "helper" templates which were not meant to be ever used directly but only by other templates. It is often not possible to find templates used directly in the wrong namespace. For example, find commons files that directly call c:Template:Creator or one of the templates that redirects to it. Some of the changes might need changes to the database tables where the data is stored. --Jarekt (talk) 14:49, 7 December 2017 (UTC)
  •   Support bdijkstra (talk) 20:00, 8 December 2017 (UTC)
  •   Support --jdx Re: 20:06, 8 December 2017 (UTC)
  •   Support X:: black ::X (talk) 11:22, 10 December 2017 (UTC)
  •   Support Ruslik (talk) 18:15, 10 December 2017 (UTC)
  •   Support Jack who built the house (talk) 21:34, 10 December 2017 (UTC)
  •   Support Serhio Magpie (talk) 21:34, 10 December 2017 (UTC)
  •   Support Lone Guardian (talk) 22:12, 10 December 2017 (UTC)
  •   Support Psychoslave (talk) 08:09, 11 December 2017 (UTC)
  •   Support Facenapalm (talk) 12:50, 11 December 2017 (UTC)
  •   Support --Meno25 (talk) 15:45, 11 December 2017 (UTC)
  •   Support Yes please! As someone actively developing templates I want to know how many articles use a given parameter or which articles have a local value instead of one from Wikidata — NickK (talk) 17:03, 11 December 2017 (UTC)

Vertical writing supportEdit

  • Problem: Scripts that are written vertically are not supported by Wikipedia interface.
  • Who would benefit:
    Users of language with vertically written script, include:
    1. American Sign Language SignWriting users and the ASL test wiki on incubator. The vertical writing support will also allow the ASL wikipedia to be actually created.
    2. Traditional Mongolian Script users, including general Mongolian user in Inner Mongolia as well as various different situation the could be used by usersin Republic of Mongolia.
    3. Historical scripts like Manchu, Tangut, Meroitic Monumental Hieroglyphic are also vertically written, supporting vertical writing will allow them to be more easily inputted into wikisource.
    4. Some Chinese/Japanese users might also prefer reading content in vertical writing direction.
  • Proposed solution: Support vertical writing direction in Mediawiki.
  • More comments: See also mw:Requests for comment/Vertical writing support.
    The ASL incubator wiki have already implemented their own custom way to try to display vertical writing onto their site.
    Some Traditional Mongolian script users for Mongolian language have also started their own mediawiki site that have already implemented their own method to support vertical writing onto their site.
  • Phabricator tickets: phab:T353, phab:T11436
  • Proposer: C933103 (talk) 06:56, 7 November 2017 (UTC)


  • I endorse this demand which is clearly a must have for the global goal of our community. --Psychoslave (talk) 11:01, 9 November 2017 (UTC)
  • I am not sure if I am allowed to call myself a member of "the community", but I fully endorse this idea 💡. Personally I created a similar idea for only vertical reading but this one would be a lot better, in fact I find it somewhat odd that the Classical Chinese Wikipedia 🏛 isn't written this way as there are no ancient texts written "left-to-right and up-to-down. --Donald Trung (Talk 🤳🏻) (My global lock 😒🌏🔒) (My global unlock 😄🌏🔓) 11:19, 10 November 2017 (UTC)
    I have archived the other proposal as a duplicate. Please feel free to copy over your comments here in the discussion MusikAnimal (WMF) (talk) 19:22, 10 November 2017 (UTC)


Mark red links to other WMF wikisEdit

  • Problem: Link to not existing page in the same wiki is marked red. But link to not existing page on Commons, Wikisource etc. is not red and there is only one way how to recognize it - click on it..
  • Who would benefit: All editors adding links to other wikis (like {{commonscat}}), readers, maintenace editors.
  • Proposed solution: Now exists script, which marks links to pages without Wikidata item. Maybe somethink like that would serve to this request. Another possibility is checking all these links during page rendering, usually there is not more than one or two per page. This link then can have eg. class="dead-wikisource-link" in HTML.
  • More comments:
  • Phabricator tickets:


  • It should be noted that they are also not "blue" (aka 'exists') links. They are light blue and indicate "external to this wiki". —TheDJ (talkcontribs) 14:29, 15 November 2017 (UTC)
  • Doing this might be a performance concern, as each wiki linked to would require opening a separate database connection to that wiki's database. There might also be edge cases of pages that don't exist directly in the database but "exist" thanks to an extension, language variants, or something like that. And, of course, it would only work for local wikis unless you went one step worse and did an API query like third-party wikis do when using Commons images. Anomie (talk) 15:01, 15 November 2017 (UTC)
  • This would probably require some kind of global links table, similar to how GlobalUsage works. Personally I doubt the benefits would be anywhere near the effort required. --Tgr (WMF) (talk) 00:15, 19 November 2017 (UTC)


Allow 'thanks' notification for a log entryEdit

  • Problem:

Users can not send 'thanks' notifications to one user who made a useful action only shown by a log.

  • Who would benefit:

Registered users.

  • Proposed solution:
  • More comments:

The Phabricator ticket phab:T60485 has been created almost 4 years ago: its development is a big task.

  • Phabricator tickets:

phab:T60485 (and its duplicates phab:T74601, phab:T112483, phab:T139443, phab:T152218...)



Implement deferred changesEdit

  • Problem: Aside from edits blocked by the edit filter, vandalism and other damaging edits can still be viewed on pages for a short amount of time before they are reverted. According to a 2012 study by the Signpost, around 10% of damaging edits are seen by more than 100 readers, affecting the credibility of Wikipedia. The persistence of vandalism and BLP violations on low traffic biographies of living people is a lingering problem. Despite anti-vandalism bots and semi-automated tools, a substantial proportion of those damaging edits is not identified and reverted in a timely manner. (w:Wikipedia:Deferred changes).
  • Who would benefit:

Readers, as they are less likely to view vandalized pages. Vandal patrollers, who will have more time to revert edits.

  • Proposed solution:

Implement w:Wikipedia:Deferred changes, delaying suspicious edits from being viewed by readers until they have been reviewed by an editor, or reverted, similar to w:Wikipedia:Pending changes. Classification of suspicious edits can be done with edit filters, m:ORES and ClueBot NG's classification system.

  • More comments:

This project has been previously developed mainly by w:User:Cenarium, and has gained near unanimous support (except for one oppose) in a 2016 RfC on enwiki. Development appeared to have been active in December last year, however the project seems to be inactive as no changes have been made since then. Cenarium themselves have not made an edit on the English Wikipedia since April this year.

  • Phabricator tickets:



The finished commits are struck out.

Basic commits
For notification
For simultaneous use of regular patrol
  • gerrit:328111 Make patrol of reviewed changes optional
  • gerrit:315109 Don't autopatrol autoreviewed users in protection-based configs
For easier reviewing
Required for change tags support
  • gerrit:315344 Change tags support (in FlaggedRevs)
  • gerrit:190656 Allow patrolling of tagged changes with minimalist RC patrol (this adds 'problem' tags)

(copied from w:Wikipedia:Deferred_changes/Implementation)



  •   Support Tgr (talk) 08:25, 28 November 2017 (UTC)
  •   Support Mahir256 (talk) 08:38, 28 November 2017 (UTC)
  •   Support --Liuxinyu970226 (talk) 13:09, 28 November 2017 (UTC)
  •   Support --Ymblanter (talk) 16:21, 28 November 2017 (UTC)
  •   Support Thomas Obermair 4 (talk) 21:59, 28 November 2017 (UTC)
  •   SupportAmmarpad (talk) 06:48, 29 November 2017 (UTC)
  •   Support Ermahgerd9 (talk) 21:14, 29 November 2017 (UTC)
  •   Support Gulumeemee (talk) 09:35, 30 November 2017 (UTC)
  •   Support קובץ על יד (talk) 12:15, 30 November 2017 (UTC)
  •   Support Nabla (talk) 23:21, 1 December 2017 (UTC)
  •   Support Termininja (talk) 17:09, 2 December 2017 (UTC)
  •   Support It has not been explained why this well-supported proposal was droppedNoyster (talk) 20:09, 2 December 2017 (UTC)
  •   Support Galobtter (talk) 12:35, 3 December 2017 (UTC)
  •   Support Tacsipacsi (talk) 13:31, 3 December 2017 (UTC)
  •   Support I think this would improve our CV measures along with existing tools and new features like the Recent Changes Filters. enL3X1 ¡‹delayed reaction›¡ 15:41, 3 December 2017 (UTC)
  •   Support LikeLifer (talk) 18:32, 3 December 2017 (UTC)
  •   Support Giraffedata (talk) 22:24, 3 December 2017 (UTC)
  •   Support Ciao • Bestoernesto 01:03, 4 December 2017 (UTC)
  •   Support Doc James (talk · contribs · email) 02:34, 5 December 2017 (UTC)
  •   Support Also make it easier to review changes from watchlist NessieVL (talk) 19:18, 5 December 2017 (UTC)
  •   Support PamD (talk) 10:32, 7 December 2017 (UTC)
  •   Support --Jarekt (talk) 14:55, 7 December 2017 (UTC)
  •   Support Dolotta (talk) 17:56, 7 December 2017 (UTC)
  •   Contra Although I share the concern on the problem, I don't agree with what I understand of the proposal. Rather than hiding this changes, it would also be possible to show a little banner "this version as not yet been reviewed and my contain false claim that such a review could clean", plus a toggle button to highlight on/off text which wasn't marked as reviewed and a link to the last "marked reviewed" version. This is rather close with some feature already in production, for example in the Esperanto version, but take the reverse approach to show possibly problematic last version by default. So, this is a soft "against", I do   Support to address the problem. — The preceding unsigned comment was added by Psychoslave (talk) 08:20, 11 December 2017 (UTC)
  •   Support — Luchesar • T/C 13:56, 11 December 2017 (UTC)
  •   Weak support. I like the idea but please avoid creating one more patrolling/reviewing system. In my view it might be a good idea to start with matching FlaggedRevisions with ORES — NickK (talk) 17:12, 11 December 2017 (UTC)

Allow additional password recovery methodsEdit

  • Problem: Right now the only way to recover your password is via email, while it is not even necessary to save an email address with your user settings at all.
  • Who would benefit:
    • Occasional authors who forgot their password and did not supply an email address or whose email address has changed meanwhile.
    • The Volunteer Response Team that quite frequent gets inquiries for lost passwords and can often only respond with "you will have to create a new account".
  • Proposed solution:
    • Create a password hash that can be saved separate from the email address.
    • Create other recovery methods, e.g. by "secret questions".
  • More comments:
  • Phabricator tickets:


IMHO "secret questions" make everything more insecure, as finding the answer to "What's the birth name of your mother?" etc. is simple social engineering to break into someone else's account. "Password hashs": w:en:Template:Committed identity might be pretty close to that? Have you considered w:Multi-factor authentication? --AKlapper (WMF) (talk) 20:47, 8 November 2017 (UTC)

Two-factor authentification... Would a "normal user" (one of those who forget to update their email address in the settings) do that? --Reinhard Kraasch (talk) 21:48, 8 November 2017 (UTC)
Since the possible "secret questions" are often the same across many different sites, seems relevant too. Anomie (talk) 15:23, 9 November 2017 (UTC)
Two-factor makes account recovery harder, not easier. --Tgr (WMF) (talk) 04:52, 19 November 2017 (UTC)
I only read about it in its early days. It was confusing enough to make *everything* harder... I hope it improved. Gotta read about it again someday. - Nabla (talk) 23:32, 1 December 2017 (UTC)
  • Most of this is easily solvable by just more strongly encouraging people to register and verify their email address. Have you seen those websites where once a year they ask "is this still your email address?". Similar reminders and encouragements can be given. In my opinion not registering an email address should be an active opt-out, not a lazy default situation. —TheDJ (talkcontribs) 20:48, 9 November 2017 (UTC)
    • That's a good point, sending a reminder to said folks should be pretty easy. And yeah, we should encourage it more heavily on the registration page. Not an a hard failure, but at least a "HEY ARE YOU REALLY F'ING SURE? HAVING AN EMAIL IS A GOOD IDEA YO" would encourage people to not skip out. 😂 (talk) 00:27, 10 November 2017 (UTC)
    • Maybe specifically when an online email service provide is known to terminating or terminated their service, a reminder can be given to those people? C933103 (talk) 20:04, 11 November 2017 (UTC)
  • Maybe send a person who doesn't register their email every 3 months a central notice asking them to fill out their email address? ChristianKl (talk) 17:29, 11 November 2017 (UTC)
    • But the proposal was about email address that have been registered but changed.C933103 (talk) 20:04, 11 November 2017 (UTC)

A password hash is basically a password, except it's impossible to remember. How would that help? If you care about your account being lost, set an email address and keep it up to date. If someone can't be trusted to do that, it's hard to imagine they would keep better track of their identity hash. +1 to nagging people with significant editcount to set/update their email address instead. (Also, maybe allow setting a secondary recovery email address?) --Tgr (WMF) (talk) 04:52, 19 November 2017 (UTC)

I'm not a fan of the proposed alternative recovery methods. Perhaps something like adding a phone number might make sense, although that's also not without its flaw in terms of people stealing other people's phone numbers. BWolff (WMF) (talk) 22:49, 28 November 2017 (UTC)

It is now well established that SMS is not secure enough for 2FA, but using it (or voice calls) for password recovery would be even more dangerous as not even the password would be required to break into an account. Admittedly, intercepting and redirecting messages or calls may be well beyond the abilities of a regular script-kiddie, but that's not the only group of possible attackers. This may in particular put people living in countries with oppressive regimes under especially high risk. Of course, entering a phone number may (and should) be optional, but still not everyone would be aware of the security implications, with many people happily assuming that nobody else should be able to read their text messages or hear their voice calls. Last but not least, by implementing something like this, we'll be going in the exact opposite direction of where everyone else is going nowadays (or should/will sooner or later be going, anyway).
— Luchesar • T/C 23:18, 28 November 2017 (UTC)
  • Better look into how proofs are done at Keybase. You can use multiple proofs to verify an identity, and if the proofs gives a sufficiently high trust, then revoke of credentials can be initiated. Please don't use SMS, but if you do, ask for an alternate return path. Note also that if an attacker asks for new credentials, then he already has a working attack vector for the special page at Wikipedia. — Jeblad 01:18, 11 December 2017 (UTC)


  •   Support David1010 (talk) 11:03, 28 November 2017 (UTC)
  •   Support --Liuxinyu970226 (talk) 13:09, 28 November 2017 (UTC)
  •   Oppose Regular reminders of emails and messages are good, the answer or hash to restore is not safe. Third party login (OAuth) can be reviewed. There is no more reason to retrieve a lost account.--YFdyh000 (talk) 14:51, 28 November 2017 (UTC)
  •   Oppose While I recognize the issue, the suggested alternatives are not safe. I would be much more in favour of a solution where (selected) admins / power users can directly set a new password for users who cannot request a new password via mail. --Rcdeboer (talk) 15:23, 28 November 2017 (UTC)
  •   Support Thomas Obermair 4 (talk) 22:00, 28 November 2017 (UTC)
  •   Strong oppose “Secret questions” are a disaster from security standpoint, especially if they would be mandatory. +1 for promoting use of e-mails and possibly also committed identity. The latter should also help when an account had already been overtaken by an adversary, though, admittedly, it's not exactly very user friendly (extending the documentation might help somewhat here). After all, the only safe user is the one who is aware of the security hazards around and makes reasonable effort to protect themselves. If they can't be bothered to do this, well, it's an indication that they don't value their (current) account that much anyway. And Wikipedia isn't like a cloud storage or web-based e-mail where a lost account means also lots of lost information, too (users with special rights, e.g. sysops, are obviously a different case, but the elevated rights do also come with an expectation of an elevated level of responsibility, so such users actually have no excuse to be lazy about keeping their accounts safe). — Luchesar • T/C 22:27, 28 November 2017 (UTC)
  •   Support Sebastian Wallroth (talk) 07:31, 29 November 2017 (UTC)
  •   Support (only Two factor authentication) ZellmerLP (talk) 22:18, 29 November 2017 (UTC)
  •   Oppose Not safe! --Kusurija (talk) 22:21, 29 November 2017 (UTC)
  •   Support קובץ על יד (talk) 12:37, 30 November 2017 (UTC)
  •   Support Support the concept (better recovery), not any particular implementation. Nabla (talk) 23:27, 1 December 2017 (UTC)
  •   Oppose the proposed solutions, but do support the idea of finding other ways for people to reset their accounts. 😂 (talk) 01:32, 2 December 2017 (UTC)
  •   Oppose (  Support reminding users about their email and stressing that they should add an email tho.) --Terra  (talk) 07:04, 2 December 2017 (UTC)
  •   Oppose --Termininja (talk) 17:10, 2 December 2017 (UTC)
  •   Strong oppose, as secret questions would compromise the security of the accounts using them and the project itself when used by users holding relatively advanced permissions. --Kostas20142 (talk) 18:30, 3 December 2017 (UTC)
  •   Support Could consider GPG keys verification, SSH key pair verification, or other methods, passwords are a bit 1990s perhaps? Gryllida 00:47, 4 December 2017 (UTC)
  •   Oppose per above - It's not hard to find someone on a website and even if they don't have their Mums name on a website it can still be found by other means. –Davey2010Talk 17:14, 4 December 2017 (UTC)
  •   Oppose no 'secret' questions. I'd support if it were sending password recovery by text or something. NessieVL (talk) 19:26, 5 December 2017 (UTC)
  •   Support the general concept of improved password reset options, but like others, concerned about some of the specific solutions, so not necessarily supporting any specific solution.--Sphilbrick (talk) 15:16, 6 December 2017 (UTC)
  •   Oppose secret question makes account more prone to be compromised because people will use simple family/personal/work related answers so as not forget and these data is easier to be compromised by several methods. This is good faith proposal, but its effect will create more problem than it intend solves. Ammarpad (talk) 10:50, 7 December 2017 (UTC)
  •   Strong oppose, As I already had many unrecoverable problems with all these methods (secret questions, mobile etc.) in other communities and sites. We just have to warn user that without email is probably unlike to recover hers/his password. --Xoristzatziki (talk) 20:51, 9 December 2017 (UTC)
  •   Oppose Klaas `Z4␟` V:  22:23, 10 December 2017 (UTC) one would create a possibility to hack user/pw combinations
  •   Support Ldorfman (talk) 16:54, 11 December 2017 (UTC)
  •   Oppose, I think my mother's maiden name or my father's middle name are way easier to find out (our harassers have found information that was hidden much better) than to hack my email — NickK (talk) 17:16, 11 December 2017 (UTC)

Only show mainspace pages in Special:WantedPagesEdit

  • Problem: As part of the Special Pages in every wiki, there is a section called Special:WantedPages. There, it lists non-existing pages by number of incoming links, in order to know which of these are the most desired. One problem is that non-articles are shown. The list includes files, Talk pages, project pages, etc., that are not useful to most people.

    On some wikis, when these pages are actually created, they are still shown at Special:WantedPages. This has caused the wanted pages list to become more and more useless over the years.

    Additionally, the places that the incoming links originate are also not necessarily legitimate links. Pages that are mentioned in a template are counted as a link with every template transclusion. It would be more useful to count actual direct links. To make matters worse, pages that are checked with {{#ifexist: are also counted as a link (that is the subject of this proposal). This causes false positives to show up. For instance, at w:en:Special:WantedPages, the top result (at the time of writing) is w:en:Talk:Jay Obernolte/GA1. In reality this is not really a wanted page at all, rather a popular template is checking whether or not it exists.

  • Who would benefit: Users who are looking for articles to write, or are interested to know what popular topics are not covered on the wiki.
  • Proposed solution: Only include mainspace pages, or at least offer options to pick a namespace. Secondly, only direct incoming links from the matching namespace should be counted. Finally, assuming the queries of this Special page can be made more efficient, it should refresh the list more often so that pages that now exist are removed.


@Pencho15: Could you update the summary of this proposal by summarizing the current issues that you see? "Solve Wanted Pages issues" is a bit vague as it could be any issues... Thanks in advance! --AKlapper (WMF) (talk) 20:50, 8 November 2017 (UTC)

  • @AKlapper (WMF): Done, I hope its better. --Pencho15 (talk) 00:53, 9 November 2017 (UTC)
    • @Pencho15: This still needs further explaining. Let's take a look at en-wiki: there we have en:Special:WantedPages, en:Special:WantedFiles, en:Special:WantedTemplates and en:Special:WantedCategories. The pages are still updated (despite some of their headers claiming otherwise), the WantedPages list was lastly updated on 2017/10/26. So what do you exactly propose? More frequent actualization of WantedPages to eliminate newly created pages? And filtering out everything outside the Main namespace? --Vachovec1 (talk) 11:18, 11 November 2017 (UTC)
      • @Vachovec1: Sorry, my first language is not english. Perhaps you may help me on how to make this clearer.
  • In the case of the pages you mention, en:Special:WantedFiles, en:Special:WantedTemplates and en:Special:WantedCategories all work perfectly fine, and I don't think they need any improvement, they are useful and updated adequately. I understand it is the same on every other wiki, and I know it is the case in the Spanish one.

    My only request is with en:Special:WantedPages, if you look at the english page, all the top entries and most of the page is full of Talk Pages and Assessments. Those are not encyclopedical pages and are not actually needed in the Wikipedia. If they are sometime, then they will be done, but should not appear on this list which is meant to indicate us the pieces of information missing from Wikipedia.

    Besides Talk pages and assessments, you also find some wanted files that should not be there, as, since you have indicated, they have their own section. A further problem is that those listed files that have already been created do not dissapear from this list after it is updated, and they remain there forever. Spam reports and user pages also appear in some wikis, making all this section pretty useless, when it could be very useful as the Wated Categories, Wanted Templates and Wanted Files pages are.

    If you look at the current list in the english wiki, the first entry that should actually be there is the number 14 of the list, Rehavia Rosenbaum, and only that one and articles number 15, 16, 21 and 24 are actual encyclopedical entries that should be listed.

    So my proposition is to update that single en:Special:WantedPages section in all wikis to make it useful changing its configuration so that Files, Talk Pages, Assessments, Spam reports, Categories, Templates, User Pages and all other kind of special entries that are not actual articles dissapear from it. Perhaps you could help me on how to phrase this in a simpler way in english so my proposition is clear? --Pencho15 (talk) 06:09, 12 November 2017 (UTC)

    So, problem: In Special:WantedPages, wanted article are entangled together with other type of wanted pages, including talk pages, templates, non-content pages and Wikipedia pages.

    Thus, proposed solution: Make a new special page that would only display wanted pages from the main namespace. C933103 (talk) 21:21, 12 November 2017 (UTC)

    • @C933103:. Hello. I wasn't notified of your answer, sorry I did not see it before, but yes, your edition is perfect, thank you very much for making it. --Pencho15 (talk) 02:32, 30 November 2017 (UTC)
  • @Pencho15: I am familiar with the issues with Special:WantedPages, so I have copyedited your proposal to make it more clear what the issue is, and how it could be fixed. Hope this is okay!

    To elaborate on what I know: A while back I actually looked at the code for Special:WantedPages. It suffers from many problems, but the main one is that the query is very inefficient. If we narrowed it down to the mainspace, that should help. The other major issue is elaborated at the proposal Stop ifexist checks from appearing in Special:WhatLinksHere. This causes false positives to show up in the list.

    Also note that if we fix WantedPages as proposed, we should probably also add the necessary options to WhatLinksHere, too (exclude ifexist checks). Otherwise the number of links that are shown in WantedPages will not match the number of links shown at WhatLinksHere. MusikAnimal (WMF) (talk) 01:45, 21 November 2017 (UTC)

imo, We should allow filtering by namespace for all query special pages (That is do the query once for each namespace, and store the results for each namespace, and then add an index on qcc_namespace so we could efficiently show them). Bawolff (talk) 22:51, 28 November 2017 (UTC)


  •   Support Jenks24 (talk) 09:23, 28 November 2017 (UTC)
  •   Support But the previous functionality should be preserved as well. Sometimes users wants to know also missing/redlinked help pages and other namespaces. maybe there should be better a namespace filter or something. Dvorapa (talk) 09:29, 28 November 2017 (UTC)
  •   Support --Liuxinyu970226 (talk) 13:09, 28 November 2017 (UTC)
  •   Support Sadads (talk) 13:42, 28 November 2017 (UTC)
  •   Support Stryn (talk) 16:20, 28 November 2017 (UTC)
  •   Support Thomas Obermair 4 (talk) 22:00, 28 November 2017 (UTC)
  •   Support --Pencho15 (talk) 02:29, 30 November 2017 (UTC)
  •   Support - yona B. (D) 08:20, 30 November 2017 (UTC)
  •   Support Dromedar61 (talk) 21:05, 30 November 2017 (UTC)
  •   Support Ninovolador (talk) 22:02, 30 November 2017 (UTC)
  •   Support Metrónomo-Goldwyn-Mayer 22:04, 30 November 2017 (UTC)
  •   Support DonBarredora (talk) 01:15, 1 December 2017 (UTC)
  •   Support --Superchilum(talk to me!) 20:54, 1 December 2017 (UTC)
  •   Support enL3X1 ¡‹delayed reaction›¡ 15:43, 3 December 2017 (UTC)
  •   Support Ciao • Bestoernesto 01:05, 4 December 2017 (UTC)
  •   Support With namespace filtering per Dvorapa JAn Dudík (talk) 09:12, 4 December 2017 (UTC)
  •   Support or maybe show non-mainspace counts on the side? NessieVL (talk) 19:36, 5 December 2017 (UTC)
  •   Support Jmmuguerza (talk) 20:00, 8 December 2017 (UTC)
  •   Support Jack who built the house (talk) 21:07, 8 December 2017 (UTC)
  •   Support Serhio Magpie (talk) 21:49, 8 December 2017 (UTC)
  •   Support adding a namespace filter NaBUru38 (talk) 22:44, 9 December 2017 (UTC)
  •   Support adding a namespace filter --Kaganer (talk) 22:47, 9 December 2017 (UTC)
  •   Support for either adding a namespace filter or create a separate page that lists only the redlinks (and their number!) for pages in the article-namespace (maybe also only those which are placed in the article-namespace, i. e. also are linking from there). If a filter is used, also further filter options would be interesting (filtering out IPs or subpages) X:: black ::X (talk) 13:59, 10 December 2017 (UTC)
  •   Support Ruslik (talk) 18:23, 10 December 2017 (UTC)
  •   Support adding a namespace filter. I might be interested in wanted Help namespace pages either, for example — NickK (talk) 17:18, 11 December 2017 (UTC)

Use map for NearbyEdit

  • Problem: Special:Nearby is not really useful in its current form – it displays a list with some articles, but the user can neither broaden the area nor select a completely other place (or select any place if the browser doesn’t have the necessary API).
  • Who would benefit: Users not having the Android or iOS app who want to use Nearby.
  • Proposed solution: Use a map on Special:Nearby (or let the user chose between the list and map format).
  • More comments: Maybe a search field with traditional GET request could be added to make this function usable at all for JavaScript-less users.
  • Phabricator tickets:
  • Proposer: Tacsipacsi (talk) 16:33, 17 November 2017 (UTC)


I'd also would just love to make it possible to easily enable this layer when you click on a coordinate in an article. I see it as just another navigation method. If you want, you should be able to just keep clicking on, deeper and deeper into Wikipedia. An article, a map, annotations in an image, or a timeline, it shouldn't have to be an article if I want to go to a related article ! —TheDJ (talkcontribs) 14:12, 18 November 2017 (UTC)

I think it should be opt-in in articles, as it might not be useful everywhere (e.g. if there’s a map with the US national parks, there should be only the national parks on the map, not every article about places in the US). Also it’s less useful as wikis may not use Kartographer, and it’s nearly impossible to develop it for all existing map techniques. Otherwise it would be great, but wikis should change to Kartographer to let it work. —Tacsipacsi (talk) 14:30, 18 November 2017 (UTC)

As a kind of straw man demo, i worked up a bare bones example of putting search results on a map combined with using search's nearcoord keyword to restrict results to the area currently being viewed some time ago when we first released the geo keywords for search. This is of course not a solution to this request, but perhaps something to start thinking about how much data we have available (although this limits markers to 50 at a time so they don't overlap so much, and it's currently hard coded to enwiki but could be changed). EBernhardson (WMF) (talk) 21:58, 28 November 2017 (UTC)

What about linking the wiwosm/osm-on-ol-tool (description) and metawikimedia:WikiMiniAtlas? --X:: black ::X (talk) 14:57, 10 December 2017 (UTC)

I would rather imagine a Kartographer-based solution as it’s already on-wiki (and its map looks much better IMO). —Tacsipacsi (talk) 22:39, 10 December 2017 (UTC)


Remember site notice dismissalsEdit

  • Problem: When browsing Wikipedia with Firefox in private mode, the same site notices pop up again in each new session after logging in, presumably because dismissing site notice(s) is recorded in (a) cookie(s) that get discarded after closing Firefox. This also happens when using multiple browsers or devices.
  • Who would benefit: Registered users using session cookies and/or multiple browsers or devices.
  • Proposed solution: Record the dismissal of a site notice on the server as part of the user data so that this information is preserved between sessions and identical in multiple browsers and devices.
  • More comments:
  • Phabricator tickets:


  • The dismissal works for me. Do you have some browser add-on installed that deletes cookies at the end of the session? Anomie (talk) 00:34, 20 November 2017 (UTC)
  • Storing the dismissal as part of user data would be useful even to those of us who don't use private mode. I view Wikipedia on a dozen browsers spread across nearly as many devices, and playing whack-a-banner gets tiring after a while. --Carnildo (talk) 23:31, 28 November 2017 (UTC)