Community Wishlist Survey 2019/Reading

8 proposals, 278 contributors, 406 support votes
The survey has closed. Thanks for your participation :)

View list of articles in subcategories all on one page

  • Problem: Many projects use categories in a sense where subcategories mean subsets of categories (in a mathematical way). Hence, articles in subcategories are actually content of the supercategory as well, but not sorted this way to gain better overview.
  • Who would benefit: Editors and readers trying to get an overview over the articles about a given topic.
  • Proposed solution: Add an option to show all pages and files in subcategories as well. There could maybe be a cache of this information, that is updated regularly or on categorization, to make this work reasonably well. Maybe this cache wouldn't have to contain all pages contained in a category or its subsets, but only subcategories. A limit of a few 10 000 pages could make sure that the amount of pages is manageable for the software with reasonable effort.
  • More comments:
  • Phabricator tickets: T4725


Note that you can approximate this with deepcat searching: search query example. —TheDJ (talkcontribs) 10:45, 31 October 2018 (UTC)Reply[reply]
While this is a workaroung, it doesn't provide the same user experience as category pages. It's a bit like suggesting to drop category pages entirely, as you can use incategory seacrhing instead. --MGChecker (talk) 21:56, 31 October 2018 (UTC)Reply[reply]
I would ask the reverse proposal: change the search page to allow users to select views: default, compact (as per this proposal) and image (as per this proposal). --NaBUru38 (talk) 19:10, 7 November 2018 (UTC)Reply[reply]
  • Could you share some examples of categories with subcategories used in the way you describe? It might help others, including me, better understand this proposal's goals. AEzell (WMF) (talk) 19:33, 31 October 2018 (UTC)Reply[reply]
    • While enwiki doesn't use categories this way, dewikis whole category system is organized this way. It might be more useful to provide an example for what would be never done there: en:Köln-Düsseldorfer is indirectly part of en:Category:Rivers of Switzerland, even though it is neither a river nor in Switzerland. This leads to two concepts roughly translatable as "Topic category" and "Object category", where the latter is only allowed to contain articles that satisfy d:Property:P31: „Article is a Category“. en:Category:Rivers of Switzerland wouldn't be allowed to contain articles that aren't rivers of Switzerland, not even in subcategories. Using a system like this for categories renders viewing lists of articles in subcategories all on one page much more useful than it would be in enwiki. --MGChecker (talk) 21:56, 31 October 2018 (UTC)Reply[reply]
  • I would like to make sure I understand this proposal MGChecker. On, as I'm sure you know, subcategories do not inherit from supercategories. So, paradoxically, the broader the category one searches by, the fewer results one gets. E.g., a search by Category:Rivers of the United States would find almost no actual river articles—and any it did find would turn up only because they were mis-categorized (because they should have been filed in various sub-categories). So are you saying 1) that you want to change the category system so that articles in subcategories do inherit from parent categories? Or are you saying 2) that you want a special page that shows you a hierarchically organized view of categories and subcategories, where each is subcategory openable so that you can see the actual articles in the subcategory, instead of simply seeing a count of them, as now? —JMatazzoni (WMF) (talk) 00:56, 2 November 2018 (UTC)Reply[reply]
    • With this proposal I want 1, but you would be free to chose: There should be a button to chose between these two modes so everyone who is happy with the current system won't complain. --MGChecker (talk) 23:05, 13 November 2018 (UTC)Reply[reply]
  • I also am not sure of what you are proposing. Would a category tree map, draggable and with local zoom possiblity, be a solution? Jürgen Eissink (talk) 01:01, 4 November 2018 (UTC).Reply[reply]
    • This would not really be a solution, as this isn't about the subcat structure itself, but about the articles in there. You would gain the possibility to view the articles/files in a category and its subcategories at the same time without the need to use Cirrus. --MGChecker (talk) 23:05, 13 November 2018 (UTC)Reply[reply]
  • See also Community Wishlist Survey 2019/Miscellaneous/Button to show subcategories. Certes (talk) 00:03, 7 November 2018 (UTC)Reply[reply]
    • This proposal is more like what JMatazzoni proposed in 2. --MGChecker (talk) 23:05, 13 November 2018 (UTC)Reply[reply]


Night mode

Projects, results

Dark mode user script by WMF

Section added for those interested in the developments after the survey concluded.

Experimental Dark theme on Timeless skin, English Wikipedia main page
  • Skin themes – dark and gray themes for Timeless and Vector skins. Custom color palette, similar to discord's colors. Experimental volunteer project: there is some content that's hard to read with it.


  • You should consider downloading an app or software that will adjust the tint and brightness on your computer. I currently use Flux and am looking at a rather-orange page. --Izno (talk) 02:15, 6 November 2018 (UTC)Reply[reply]
  • Windows 10 has a night mode (called "night light") that removes much of the blue from the screen, which is easier on the eyes. However, I agree that a dark-theme night mode would be nice. Most WMF wikis are a wall of white/off-white background (Commons, where the page you're viewing often has large images filling the screen is somewhat of an exception). Removing the blue hue from the display is only a partial fix to the problem...a dark theme would be much better. AHeneen (talk) 08:43, 6 November 2018 (UTC)Reply[reply]
  • @Premeditated Chaos: The 2017 survey item offers several existing solutions. Could you elaborate what blocks you from using functionality provided by your operating system, by a separate application, or by using StylishThemes/Wikipedia-Dark ? Thanks! --AKlapper (WMF) (talk) 11:18, 6 November 2018 (UTC)Reply[reply]
  • I didn't make this request, but in reply to @AKlapper (WMF):, Wikipedia-Dark doesn't support Safari and Stylish doesn't officially support Safari either. Stylish has also had security issues in the past. Personally, I'm not going to install a browser extension just to get dark mode for one site, and I imagine a lot of other people are in the same camp. Plus, many people likely aren't aware that's even an option. Additionally, while flux and similar are useful (I have flux installed and tuned to be more aggressive than normal), I still find Wikipedia difficult to use at night. Flux or similar apps simply do not do enough to make Wikipedia comfortable to use at night. A native dark theme would really be appreciated and I don't think it's an unreasonable request, especially considering the mobile app for Wikipedia already has this. --OverlordOdin (talk) 20:15, 8 November 2018 (UTC)Reply[reply]
  • I use mw:Skin:Vector-DarkCSS. Works pretty well; could be made into a gadget pretty easily.. Galobtter (talk) 18:54, 16 November 2018 (UTC)Reply[reply]
    Would it be imaginable to add this CSS in the option of Special:Preferences#mw-prefsection-rendering? It would make it more visible to users. Cheers, VIGNERON * discut. 14:58, 25 November 2018 (UTC)Reply[reply]
    VIGNERON, Isarra seems to be working in regards to adding the ability to choose variants for skins (such as a dark version). Galobtter (talk) 08:38, 28 November 2018 (UTC)Reply[reply]
  • Why not just use tools like this? ‐‐1997kB (talk) 10:50, 17 November 2018 (UTC)Reply[reply]
    @1997kB Darkreader seems pretty awesome, better than the 'High Contrast' Chrome extension that I was using previously. I also agree that this is somewhat unnecessary and would be a waste of resources when there are so many good other tools available. That being said, as this is likely already in the top 10, it should be done with Automatic sliders for when you want it enabled and disabled (you can set your time zone on WP, why not). Moreover, it should add the option to add a 'dark' theme as the alternate to any theme selected, (e.g. dark Vector, dark timeless) and then give an option to enable this for certain parts of the day/night or as a toggle. — Insertcleverphrasehere (or here) 15:44, 23 November 2018 (UTC)Reply[reply]
  • Can we do this for this page as well? Nikkimaria (talk) 22:06, 25 November 2018 (UTC)Reply[reply]
  • Tom Ja claims it would save energy, but I doubt this is significant, as per, unless things have changed. PJTraill (talk) 00:37, 27 November 2018 (UTC)Reply[reply]
    @PJTraill It would not save energy for LCD screens (the vast majority of computer monitors), which have a backlight that is on regardless of whether the pixels are black (blocking the backlight) or white (letting the backlight shine through). However a lot of TVs and an increasing percentage of new smartphones have OLED screens, where the little diodes each release light themselves (thus less light=less power use). I would highly suggest that the night mode is also developed for wiki-mobile and the app as well for this reason. — Insertcleverphrasehere (or here) 09:09, 27 November 2018 (UTC)Reply[reply]
    The apps do already have a dark/night theme. ESanders (WMF) (talk) 16:09, 27 November 2018 (UTC)Reply[reply]
  • Huge support for this. I already use f.lux and other blueblockers to mitigate a vision disability, as well as some dark themes for browsers. However blanket colour inversion is sometimes impractical for many reasons, especially when online and/or working with images. Native night modes are far superior to 'wall-of-white' for users like myself. Wiki night mode would be lovely imo. ifny (talk) 01:55, 27 November 2018 (UTC)Reply[reply]
  • Note that my very similar proposal (Community Wishlist Survey 2019/Reading/Accessibility settings for everyone) basically includes this feature, and a bit more. It is also intended to be available to logged-out users. Please consider building this, with an eye towards future expand-ability for those other accessibility/usability aspects. Quiddity (talk) 06:45, 1 December 2018 (UTC)Reply[reply]
  • See also mw:Requests for comment/Themes in core which is very relevant if it moves forward. Quiddity (talk) 23:57, 9 December 2018 (UTC)Reply[reply]


Functional and beautiful math for everyone

  • Problem:The math extension has a lot of bugs, missing features and deficiencies due to the output being images rather than text-like. Most math related websites like use "MathJax out of the box" and do not have these problems. Re-submission of Community Wishlist Survey 2017/Reading/Functional and beautiful math for everyone
  • Who would benefit: Readers and editors of mathematical articles, books etc.
  • Proposed solution: In a commission of interested volunteers we came up with a road-map to remove the problematic conversion of "texvc" to standard LaTeX syntax. For a state-of-the-art rendering system we also need to improve the output format. Making it more like "MathJax out of the box" might need additional infrastructure (e.g. to supply web-fonts), needs a long-term maintenance concept and has to work together with almost all software components, so we would like WMF staff to help us.
  • More comments:
  • Phabricator tickets: phab:T195861
  • Proposer: Debenben (talk) 19:29, 4 November 2018 (UTC)Reply[reply]



@Bestoernesto: Why oppose? Do you have concerns regarding the roadmap or because you think the other wishes here are more important than providing a math extension that works properly?--Debenben (talk) 19:03, 28 November 2018 (UTC)Reply[reply]

Improve graphs and interactive content

Examples of Vega and Vega-Lite graphs we can build
  • Problem: Wikipedia would benefit from more animations, interactive content, and self-updating infographics
When we discuss historical changes, we should be able to view those changes interactively, e.g. side by side. Statistical data should be represented as easy to understand charts, and when the new data becomes available, those charts should update. We already have some of the tools for this (the <graph> tag, the shared data on commons, maps), but the current tools are hard to use, not maintained, and need improvements. The comprehensive vision was presented several years ago in a short I Dream of Content paper.
The Graph extension has many advantages for Wikimedia projects. In brief, it allows data to by displayed by generating graphs on-the-fly (we do not need a picture file anymore, and so we do not need to create a new picture each time the data are updated). However, the Graph extension is currently not widely used, probably partly because the code is not really user-friendly.
  • Who would benefit: Readers and content creators
  • Proposed solution: Upgrade the Vega library, add Vega-Lite support, and add multilingual support to Graphs.
Develop a GUI Visual-Editor-like tool to help contributors to create nice graphs. This tool could look a bit like those in spreadsheet software (the user selects the data to plot and the type of graph, then fine-tunes it). This tool could be integrated with the Data namespace on Wikimedia Commons (example) and with the Wikidata Query Service. The latter already offers different visualisation methods, with the ability to export results to several formats (html, json, svg). See this example. Adding customizable Vega code as an output would be nice.
Community Wishlist Survey 2016/Categories/Multimedia#Support SVG interactivity and animation in Media Viewer discussed making animation and interactivity easier for SVGs.
  • More comments:


Yes, I wish there was improved documentation for mw:Extension:Graph. Gryllida 23:00, 30 October 2018 (UTC)Reply[reply]

Hmmm, actually I wrote a similar proposition here (I did not see this one before). Should we merge both proposals? Pamputt (talk)
Pamputt, yep, makes sense. Want to port your info to here, and just leave a redirect? Feel free to change the proposal. --Yurik (talk) 15:56, 1 November 2018 (UTC)Reply[reply]
I modified the text above. Feel free to edit it. I also copied the discussion from the other proposal below in order to keep a record. Finally, I redirected the other proposal to this one. Pamputt (talk) 18:18, 2 November 2018 (UTC)Reply[reply]
@Gryllida: the Vega official documentation page has tons of great documentation, but unfortunately it is for Vega 3,4+. MW is still on Vega 2, two major versions behind. If we upgrade and add Vega-Lite, it will be far easier to use (Vega-Lite has much simpler syntax), and we will be able to use the proper documentation site. --Yurik (talk) 22:54, 2 November 2018 (UTC)Reply[reply]

One of the Vega-Lite authors and Vega contributors here. I'd like to express my full support for this effort and offer my help with any issues that come up. Dominik Moritz (talk) 18:25, 24 November 2018 (UTC)Reply[reply]

Discussion from the other proposal

From Community Wishlist Survey 2019/Miscellaneous/Graph extension before merging

So I think one of the problems here is that Graph simply allows you to do too much... People want full flexibility but full flexibility turns out to be really hard to use if you are not an expert (nor interested in becoming one). I think many people are looking for simple graphs. I was thinking if it was perhaps an idea to add simple "graph" buttons to the Data namespace on Wikimedia Commons for instance. Like with spreadsheet software, select your data, choose a graph type, generate graph (Vega spec) and done... That would make creating simple graphs much easier, helping 80% of the people. And then when people want to get really down and dirty, they can modify those results etc. If you have similar ideas or thoughts on how to do this for data sources other than the tabular data, I would welcome them. I think that having a better insight into what would work is important to convince the foundation to work on issues like this. —TheDJ (talkcontribs) 16:08, 1 November 2018 (UTC)Reply[reply]

Also, this is another "Fix all da things" wishlist item. I advise rewording it to be more specific and limiting the scope to the most useful tickets, in order to increase the changes of the item being successful and not to be excluded from voting by the team due to scope issues, please read Community_Wishlist_Survey_2019#proposalsphase. —TheDJ (talkcontribs) 16:10, 1 November 2018 (UTC)Reply[reply]
Actually there are two points. First, the graph extension has been developed and now it has no support anymore. This is a global issue of Mediawiki. Some nice tools are developed at some time and finally they are not maintained on a long term and so they are not used because bugs that are reported are not fixed and contributors understand that no one is in charge of these tools. This was the basic idea of this proposal, just assign a developer to this tool to improve and fix it. Actually there was already a proposal about this and I think it is better written.
The second point is what you wrote above. The graph extension is rather difficult to use and a user friendly tool would help to use this nice extension. What you propose, a tool allowing to generate graph in a spreadsheet-like way, would be really nice.
So it looks like this is two proposals (one for upgrading Vega version and implementing lolisation) and the other one to provide user-friendly tools to generate graphs. Pamputt (talk) 09:18, 2 November 2018 (UTC)Reply[reply]

There is a "Vega-Lite" version of Vega - it is by far easier than the full Vega, and can work together with the full Vega. Please update graphs/interactive content proposal with your thoughts. Ideally, I would even consolidate these two, as it seems a single proposal gets more votes, and attracts more attention than multiple ones. Thx! --Yurik (talk) 16:43, 2 November 2018 (UTC)Reply[reply]

A gif player that can allow pausing dynamic .gif map would be a nice feature. C933103 (talk) 06:45, 4 November 2018 (UTC)Reply[reply]
@C933103: sure - essentially GIF and Video player should be one and the same, and it could be a good addition. Unfortunately that wouldn't solve the fundamental problem - ability to easily generate data-driven content/visualizations. One would have to be a video editor to create either one. The <graph> driven vis is different because it relies on data sources, thus when data changes, the visualization is updated. Plus it also means that the visualization can be translated without recreating the whole thing (unlike a gif/video). But I do like your idea for the simple GIFs! --Yurik (talk) 22:19, 7 November 2018 (UTC)Reply[reply]


How do Vega graphs fit in with interactive-graph Wikidata queries like Number of museums per country? HLHJ (talk) 08:31, 14 November 2018 (UTC)Reply[reply]

I do not know for such complex case but in principle it works. You can see this graph that uses data from Wikidata. Pamputt (talk) 09:05, 14 November 2018 (UTC)Reply[reply]
@HLHJ: Vega graphs can already get the data from Wikidata directly. The process right now is not very user friendly (you have to URL-encode the query), but it can be made far easier, e.g. "url": { "sparql": "SELECT ..." }. Thanks Pamputt for the link! --Yurik (talk) 17:46, 14 November 2018 (UTC)Reply[reply]


Accessibility settings for everyone

  • Problem: We should offer a satisfying user-interface experience to as many people as possible. Anything accessibility & usability, that is purely reading-related could be moved to a simple site-style menu, and thereby become available to logged-out users, too.
    We have been striving for a one-size-fits-all interface. In contrast this solution offers users with very common disabilities and impairments, which we know the current interface doesn't offer best experience, an easy way to adapt the interface to their needs and to serve them the best we could. We’re talking about flexibility in changing basic settings like (any of):
    • font size & styling,
    • day/night modes,
    • photophobia,
    • grayscale,
    • fixed/full width layouts for widescreen options,
  • Who would benefit: For all readers including not-logged-in ones. (Note: Technical limitation to support it for every user is, that it has to be implemented client-side in JavaScript to avoid cache fragmentation.)
Napkin sketch concept - more details at phab:M17.
  • Proposed solution: Phab:M17 (at right) offers a napkin sketch type wireframe idea of how it might work (ignore the aesthetics!) and Phab:M57/149/ shows a proof-of-concept prototype (old install notes).
  • More comments: Relevant examples:
    • Wikiwand's settings flyout - (screenshot1 - screenshot2)
    • NYTimes 3-level font-size options - (screenshot)
    • GMail's 3-level interface-density options - (screenshot, details)
    • Southampton University accessibility panel - (screenshot, live)
    • Battlefield's 3 color-blind options - (4 screenshots)
    • Fixed-width experiments in Typography Refresh and Flow - Some users love this (example); Some like the idea but want to be able to change the default width; Some want (the current) full-width. We should make it user-configurable. One possibility is to make it "resizable", just like the editing-text-box currently is (which also has a hard-override in Preferences->editing for columns and rows). Maybe or similar?
    • More?
  • Phabricator tickets: T91201
  • Proposer: Quiddity (talk) 21:37, 11 November 2018 (UTC)Reply[reply]



Create URL Shortener extension for Wikimedia wikis

  • Problem: I think it would be great if we had URL shortener for Wikimedia websites 3rd party services aren't a great idea due to privacy concerns and for example in WDQS is used and that website have a limit so many queries can't be shortened.
  • Who would benefit: Anyone who is using Wikimedia websites.
  • Proposed solution: Currently, there is Extension:ShortUrl, but the URLs generated by this aren't much shorter than the existing URLs, so probably the best way would be to create a new short domain for this.
  • Related Phabricator tickets: T112715


I agree. Good and usefull thing. Acamicamacaraca (talk) 11:47, 4 November 2018 (UTC)Reply[reply]

Acamicamacaraca, Sabas88 Thanks, if you liked it you can now support it. --Walter Klosse (talk) 09:41, 17 November 2018 (UTC)Reply[reply]

I agree, I commented the related ticket some months ago and did a bit of research but never found a nice solution. --Sabas88 (talk) 14:52, 9 November 2018 (UTC)Reply[reply]

Walter Klosse The link you put under More comments does not work. Did you mean to put in this link instead? -- NKohli (WMF) (talk) 20:05, 16 November 2018 (UTC)Reply[reply]

Yes, thanks! --Walter Klosse (talk) 09:21, 17 November 2018 (UTC)Reply[reply]

The following would be particularly important to me: In the lower section of every Wikipedia article, every Wikimedia Commons image and so on, the corresponding (as permanent as possible) short link is shown (see also) --Molgreen 05:17, 17 November 2018 (UTC)

The domain has been acquired for this a couple years ago. It already exists in DNS and our cluster Apache config.

  1. - upcoming URL shortener

funnel * //

I wanted to point this out because i see a reference to "a new domain" above and it can already be more specific and should save us time bikeshedding over the domain. That has already happened in the past. Mutante (talk) 14:06, 17 November 2018 (UTC)Reply[reply]

Doesn't this already exist at Special:UrlShortener and just needs to be enabled? --Terra  (talk) 03:11, 21 November 2018 (UTC)Reply[reply]