Community Wishlist Survey 2019/Reading

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Community Wishlist Survey 2019

Reading
8 proposals, 278 contributors

Go-previous.svg Programs and events  •  Search Go-next.svg

The survey has closed. Thanks for your participation :)
Here are the Community Wishlist Survey 2019 results!


View list of articles in subcategories all on one page

Edit proposal/discussion

  • 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

Discussion

Note that you can approximate this with deepcat searching: search query example. —TheDJ (talkcontribs) 10:45, 31 October 2018 (UTC)
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)
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)
  • 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)
    • 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)
  • I would like to make sure I understand this proposal MGChecker. On en.wiki, 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)
    • 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)
  • 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).
    • 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)
  • See also Community Wishlist Survey 2019/Miscellaneous/Button to show subcategories. Certes (talk) 00:03, 7 November 2018 (UTC)
    • This proposal is more like what JMatazzoni proposed in 2. --MGChecker (talk) 23:05, 13 November 2018 (UTC)

Voting

  • Support Support ديفيد عادل وهبة خليل 2 (talk) 09:09, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 12:30, 18 November 2018 (UTC)
  • Support Support Lostinlodos (talk) 03:43, 20 November 2018 (UTC)
  • Support Support Tris T7 (talk) 02:34, 21 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 13:48, 21 November 2018 (UTC)
  • Support Support NaBUru38 (talk) 18:29, 23 November 2018 (UTC)
  • Support Support Moer useful than Community Wishlist Survey 2019/Categories/Button to show subcategories because it would actually include the contents of the subcat itself. Use-case would be when I want to find a picture of a certain kind of animal or plant, I might not care which exact species, subspecies, breed or cultivar it is, so I would like a larger display of the higher-level cat rather than having to look at each specific (sub-)subcat separately even if I could see a list of all those subcats. DMacks (talk) 19:10, 26 November 2018 (UTC)
  • Support Support YFdyh000 (talk) 17:56, 27 November 2018 (UTC)
  • Support Support {Seeing that 'division' of 'subject matter' benefits ONLY when there is overview simply 'drawn' (i.e. the legend on the 'map') then individual studies become truly an area of interest rather than singular area they become part of one beautiful 'picture' -- Just my 2 cents-- }} 7petal1stalk (talk) 19:57, 27 November 2018 (UTC)
  • Support Support Ciao • Bestoernesto 01:31, 28 November 2018 (UTC)
  • Support Support Daniel Case (talk) 03:17, 29 November 2018 (UTC)
  • Support Support Dumbassman (talk) 18:08, 29 November 2018 (UTC)
  • Support Support Netanel488 (talk) 20:45, 29 November 2018 (UTC)

Night mode

Edit proposal/discussion

Discussion

  • 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)
  • 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)
  • @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)
  • 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)
  • 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)
    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)
    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)
  • Why not just use tools like this? ‐‐1997kB (talk) 10:50, 17 November 2018 (UTC)
    @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)
  • Can we do this for this page as well? Nikkimaria (talk) 22:06, 25 November 2018 (UTC)
  • Tom Ja claims it would save energy, but I doubt this is significant, as per https://skeptics.stackexchange.com/questions/4373/does-a-webpage-with-a-black-background-save-energy, unless things have changed. PJTraill (talk) 00:37, 27 November 2018 (UTC)
    @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)
    The apps do already have a dark/night theme. ESanders (WMF) (talk) 16:09, 27 November 2018 (UTC)
  • 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)
  • 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)
  • 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)

Voting

  • Support Support This would be a great usability feature for Wikipedia on the web. It would also keep the site's features consistent with the app, which has two dark themes. OverlordOdin (talk) 18:19, 16 November 2018 (UTC)
  • Support Support SEMMENDINGER (talk) 19:29, 16 November 2018 (UTC)
  • Support Support James Martindale (talk) 19:47, 16 November 2018 (UTC)
  • Support Support Badly needed, even when enwiki already has the dark mode with green text all over. George Ho (talk) 20:36, 16 November 2018 (UTC)
  • Support Support Now both Apple and Google are introducing dark mode to their products. It has even energical benefits (devices consume less power), not to mention health benefits. Tom Ja (talk) 23:50, 16 November 2018 (UTC)
  • Support Support Consulnico (talk) 23:56, 16 November 2018 (UTC)
  • Support Support Super Wang on zhwiki (Share your opinions) 00:00, 17 November 2018 (UTC)
  • Support Support DonBarredora (talk) 00:03, 17 November 2018 (UTC)
  • Support Support Yousou (talk) 00:26, 17 November 2018 (UTC)
  • Support Support Gehenna1510 (talk) 00:30, 17 November 2018 (UTC)
  • Support Support Also make one for Timeless! Enterprisey (talk) 04:13, 17 November 2018 (UTC)
  • Support Support Hiàn (talk) 04:29, 17 November 2018 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 09:09, 17 November 2018 (UTC)
  • Support Support Jo-Jo Eumerus (talk, contributions) 10:22, 17 November 2018 (UTC)
  • Support Support ZellmerLP (talk) 10:29, 17 November 2018 (UTC)
  • Support Support --Alaa :)..! 10:49, 17 November 2018 (UTC)
  • Support Support Nimrodbr (talk) 10:51, 17 November 2018 (UTC)
  • Support Support J. N. Squire (talk) 10:55, 17 November 2018 (UTC)
  • Support Support Libcub (talk) 11:20, 17 November 2018 (UTC)
  • Support Support Yeah this seems reasonable; would love to have a Wikipedia night mode. SshibumXZ (talk) 17:15, 17 November 2018 (UTC)
  • Support Support Cabayi (talk) 17:41, 17 November 2018 (UTC)
  • Support Support Amir (talk) 19:15, 17 November 2018 (UTC)
  • Support Support Yes. I modified my CSS to make the content area darker as a semi-fix for this, but a properly designed skin that is nice on the eyes would be excellent. – Ajraddatz (talk) 19:49, 17 November 2018 (UTC)
  • Support Support Nightdevil (talk) 20:00, 17 November 2018 (UTC)
  • Support Support Yamaha5 (talk) 20:35, 17 November 2018 (UTC)
  • Support Support MehdiTalk 20:37, 17 November 2018 (UTC)
  • Support SupportThanks for the fish! talkcontribs 20:39, 17 November 2018 (UTC)
  • Support Support Agusbou2015 (talk) 20:55, 17 November 2018 (UTC)
  • Support Support Oops, forgot to vote for my own topic. Premeditated Chaos (talk) 21:27, 17 November 2018 (UTC)
    Your vote is automatically counted when you propose, Premeditated Chaos. This is a double vote. George Ho (talk) 23:56, 17 November 2018 (UTC)
    Is it? I got a reminder on my talk page telling me not to forget to support it. Premeditated Chaos (talk) 00:51, 18 November 2018 (UTC)
    They automatically counted proposers as "support" votes for prior wishlists. Seems that the person who notified you was unaware of it. --George Ho (talk) 02:25, 18 November 2018 (UTC)
    By the way, I fixed the asterisk formatting on your behalf. George Ho (talk) 02:26, 18 November 2018 (UTC)
  • Support Support Darwinek (talk) 01:35, 18 November 2018 (UTC)
  • Support Support Kpgjhpjm (talk) 02:14, 18 November 2018 (UTC)
  • Support Support Wunkt2 (talk) 03:31, 18 November 2018 (UTC)
  • Support Support AHeneen (talk) 05:52, 18 November 2018 (UTC)
  • Support Support Poya-P (talk) 06:23, 18 November 2018 (UTC)
  • Support Support This would be so great. Abductive (talk) 10:01, 18 November 2018 (UTC)
  • Support Support Szalax (talk) 10:07, 18 November 2018 (UTC)
  • Support Support Jules78120 (talk) 10:19, 18 November 2018 (UTC)
  • Support Support فرهنگ2016 (talk) 10:41, 18 November 2018 (UTC)
  • Support Support Richard Nevell (talk) 10:49, 18 November 2018 (UTC)
  • Support Support Sharaky Talk 10:55, 18 November 2018 (UTC)
  • Support Support Arbeite19 (talk) 11:14, 18 November 2018 (UTC)
  • Support Support Мурад 97 (talk) 11:24, 18 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 12:28, 18 November 2018 (UTC)
  • Support Support it would be very useful more could be a Gadgets and already has an example on Minecraft Wiki in Portuguese and German (MediaWiki:Gadget-nightmode.js and MediaWiki:Gadget-nightmode.css Eduaddad (talk) 15:00, 18 November 2018 (UTC)
  • Support Support Coldbolt (talk) 15:10, 18 November 2018 (UTC)
  • Support Support — Draceane talkcontrib. 17:09, 18 November 2018 (UTC)
  • Support Support ~ Amory (utc) 17:18, 18 November 2018 (UTC)
  • Support Support stwalkerster (talk) 17:24, 18 November 2018 (UTC)
  • Support Support Fatemi 18:54, 18 November 2018 (UTC)
  • Support Support Wesalius (talk) 21:12, 18 November 2018 (UTC)
  • Support SupportMeiræ 22:28, 18 November 2018 (UTC)
  • Support Support Funkysapien (talk) 02:34, 19 November 2018 (UTC)
  • Support Support FR30799386 (talk) 07:16, 19 November 2018 (UTC)
  • Support Support — regards, Revi 07:25, 19 November 2018 (UTC)
  • Support Support Seems simple; I see no downside. Benjaminikuta (talk) 10:15, 19 November 2018 (UTC)
  • Support Support Veikk0.ma (talk) 12:48, 19 November 2018 (UTC)
  • Support Support It could even be the default! Recared (talk) 15:13, 19 November 2018 (UTC)
  • Support Support - tucoxn\talk 16:37, 19 November 2018 (UTC)
  • Support Support -Xbony2 (talk) 16:43, 19 November 2018 (UTC)
  • Support Support Unfortunately, this does not fix the blue hue at night, but it's a good start. (I'm not watching this page so please ping me if you want my attention.) Wumbolo (talk) 17:38, 19 November 2018 (UTC)
  • Support Support StringRay (talk) 22:18, 19 November 2018 (UTC)
  • Support Support Gareth (talk) 12:42, 20 November 2018 (UTC)
  • Support Support Lord van Tasm (talk) 13:22, 20 November 2018 (UTC)
  • Support Support«« Man77 »» [de] 13:34, 20 November 2018 (UTC)
  • Support Support I would be very happy to use Wikipedia and other Wikimedia wiki with night mode! Vulphere 15:08, 20 November 2018 (UTC)
  • Support Support Tim bates (talk) 21:52, 20 November 2018 (UTC)
  • Support Support CAPTAIN RAJU(T) 22:52, 20 November 2018 (UTC)
  • Support Support Terra  (talk) 03:10, 21 November 2018 (UTC)
  • Support Support Tisfoon (talk) 06:10, 21 November 2018 (UTC)
  • Support Support Laboramus (talk) 07:37, 21 November 2018 (UTC)
  • Support Support Bencemac (talk) 08:16, 21 November 2018 (UTC)
  • Support Support Penegal (talk) 08:41, 21 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 13:47, 21 November 2018 (UTC)
  • Support Support BugWarp (talk) 15:07, 21 November 2018 (UTC)
  • Support Support Gce (talk) 18:39, 21 November 2018 (UTC)
  • Support Support Topper13009 (talk) 20:05, 21 November 2018 (UTC)
  • Support Support a thousand times, yes. Nihlus 22:44, 21 November 2018 (UTC)
  • Support Support This seems like it would be really useful! TheAwesomeHwyh (talk) 12:13, 22 November 2018 (UTC)
  • Support Support CosmosAway (talk) 15:07, 22 November 2018 (UTC)
  • Support Support welcum to the dark side ーTesser4D 【🅱alk】 17:31, 22 November 2018 (UTC)
  • Support Support Encycloon (talk) 18:39, 22 November 2018 (UTC)
  • Support Support Arian Talk 19:33, 22 November 2018 (UTC)
  • Support Support Petr Kinšt (talk) 19:34, 22 November 2018 (UTC)
  • Support Support SalmanZ (talk) 21:18, 22 November 2018 (UTC)
  • Support Support Tetizeraz (talk) 23:15, 22 November 2018 (UTC)
  • Support Support Emyds (talk) 23:20, 22 November 2018 (UTC)
  • Support Support আফতাবুজ্জামান (talk) 23:49, 22 November 2018 (UTC)
  • Support Support AnuJuno (talk) 06:37, 23 November 2018 (UTC)
  • Support Support MisterSynergy (talk) 09:59, 23 November 2018 (UTC)
  • Support Support This would be really helpful, especially if it was obvious and could be users without accounts, having the ability to switch between view modes in the browser might also have some accessibility advantages. Assuming that users of Wikipedia have accounts or know how to install browser extensions is not inclusive. John Cummings (talk) 16:23, 23 November 2018 (UTC)
  • Support Support Sahaquiel9102 (talk) 17:28, 23 November 2018 (UTC)
  • Support Support Might get some media interest. Mbrickn (talk) 21:15, 23 November 2018 (UTC)
  • Support Support James F. (talk) 22:42, 23 November 2018 (UTC)
  • Support Support Vctrbarbieri (talk) 03:13, 24 November 2018 (UTC)
  • Support Support Matěj Suchánek (talk) 09:32, 24 November 2018 (UTC)
  • Support Support Hmxhmx 10:27, 24 November 2018 (UTC)
  • Support Support --SkyGazer 512 (talk) 13:41, 24 November 2018 (UTC)
  • Support Support There should be a button on all the pages, so you do not have to go to preferences. While this is approved, I'm installing High Contrast... --Mr Misterio2 (talk) 16:58, 24 November 2018 (UTC)
  • Support Support WindowPain (talk | contribs) 08:58, 25 November 2018 (UTC)
  • Support Support Soumendrak (talk) 09:00, 25 November 2018 (UTC)
  • Support Support--►Neriman2003 talk 11:12, 25 November 2018 (UTC)
  • Support Support Helder 13:24, 25 November 2018 (UTC)
  • Support Support Ranjithsiji (talk) 22:32, 25 November 2018 (UTC)
  • Support Support NankineseYang (talk) 00:48, 26 November 2018 (UTC)
  • Support Support From both a stylistic and functional standpoint, this would be awesome. — AfroThundr (u · t · c) 02:43, 26 November 2018 (UTC)
  • Support Support DerFussi 11:11, 26 November 2018 (UTC)
  • Support Support Ckoerner (talk) 15:54, 26 November 2018 (UTC)
  • Support Support Whispering (talk) 21:35, 26 November 2018 (UTC)
  • Support Support - FlightTime (open channel) 22:06, 26 November 2018 (UTC)
  • Support Support Miles.world (talk) 23:12, 26 November 2018 (UTC)
  • Support Support Louis H. G. (talk) 01:03, 27 November 2018 (UTC)
  • Support Support ifny (talk) 01:55, 27 November 2018 (UTC)
  • Support Support PJTraill (talk) 10:17, 27 November 2018 (UTC)
  • Support Support Linguistical (talk) 16:26, 27 November 2018 (UTC)
  • Support Support PrussianOwl (talk) 20:17, 27 November 2018 (UTC)
  • Support Support Qono (talk) 21:22, 27 November 2018 (UTC)
  • Oppose Oppose Ciao • Bestoernesto 01:36, 28 November 2018 (UTC)
  • Support Support Respublik (talk) 03:47, 28 November 2018 (UTC)
  • Support Support E1d4R (talk) 06:43, 28 November 2018 (UTC)
  • Support Support Bennv3771 (talk) 10:21, 28 November 2018 (UTC)
  • Support Pile-on support Daniel Case (talk) 03:15, 29 November 2018 (UTC)
  • Support Support Timendum (talk) 11:42, 29 November 2018 (UTC)
  • Support Support Delta 51 (talk) 19:11, 29 November 2018 (UTC)
  • Support Support Cymru.lass (talk) 20:35, 29 November 2018 (UTC)
  • Support Support Ldorfman (talk) 20:51, 29 November 2018 (UTC)
  • Support Support Netanel488 (talk) 20:51, 29 November 2018 (UTC)
  • Support Support JTP (talkcontribs) 01:55, 30 November 2018 (UTC)
  • Support Support NicoScribe (talk) 11:25, 30 November 2018 (UTC)
  • Support Support --OrsolyaVirág (talk) 14:23, 30 November 2018 (UTC)
  • Support Support Alucard 16 (talk) 15:31, 30 November 2018 (UTC)
  • Support Support --GrandCelinien (talk) 17:07, 30 November 2018 (UTC)

Functional and beautiful math for everyone

Edit proposal/discussion

  • 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 math.stackexchange.com 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)

Discussion

  • An example of missing mathematical notation is that required for actuarial functions. See phab:T175673 . -Stelio (talk) 20:16, 5 November 2018 (UTC)

Voting

@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)

Improve graphs and interactive content

Edit proposal/discussion

Examples of Vega and Vega-Lite graphs we can build

4StrokeEngine Ortho 3D Small.gifMongol Empire map 2.gif

  • 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:
  • Proposer: Yurik (talk) 20:59, 29 October 2018 (UTC)

Discussion

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

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)
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)
@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)

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)

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)

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

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)

A gif player that can allow pausing dynamic .gif map would be a nice feature. C933103 (talk) 06:45, 4 November 2018 (UTC)
@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)

Wikidata

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)

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)
@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)

Voting

Accessibility settings for everyone

Edit proposal/discussion

  • 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 jqueryui.com/resizable/#snap-to-grid or similar?
    • More?
  • Phabricator tickets: T91201
  • Proposer: Quiddity (talk) 21:37, 11 November 2018 (UTC)

Discussion

Voting

Create URL Shortener extension for Wikimedia wikis

Edit proposal/discussion

  • 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 tinyurl.com 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

Discussion

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

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

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)

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)

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

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 w.wiki has been acquired for this a couple years ago. It already exists in DNS and our cluster Apache config.

  1. w.wiki - upcoming URL shortener

funnel *w.wiki //meta.wikimedia.org/wiki/Special:UrlShortener

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)

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

Voting

Wikipedia-Translator for articles word by word based on Wiktionary

Edit proposal/discussion

  • Problem: Read Wikipedia articles in other languages and understand some of the words or phrases. There is not a link to a Wiktionary page or a visible translation if we mark a word or a phrase.
  • Who would benefit: All readers, who visit Wikipedia or Commons pages written in unknown languages. Our Wiktionary, if users add a new translation there, when they see that it is missing. Learners. Worldwide communication.
  • Proposed solution: I have written some words at my Commons page. Or a "Translation" button additional to "Read" "Edit" on top of articles, where you can choose a language and change in a "Translation modus", where every word shows a tooltip with translation (like a link), if you touch that word, and a link to wiktionary if you doubbleclick the mouseover tooltip then. "??? Add a translation!" tooltip if there is no entry in Wiktionary. Or show a translation for the whole text, if you mark the text with fingers or a computer mouse.
  • More comments: One step, handmade links to wiktionary in a text (example in discussion)
  • Phabricator tickets:
  • Proposer: LudwigSebastianMicheler (talk) 20:08, 6 November 2018 (UTC)

Discussion

@LudwigSebastianMicheler: In the long run, I wonder if this first needs d:Wikidata:Lexicographical_data to provide support for d:Wikidata:Wiktionary. In the short run, does w:en:MediaWiki:Gadget-GoogleTrans.js/w:en:User:Endo999/GoogleTrans.js fulfill your needs? --AKlapper (WMF) (talk) 07:23, 7 November 2018 (UTC)

My knowledge and my English is not good enough to understand all, but Google-translate is Google and the Gadget is not for all readers of Wikipedia articles. Maybe it will help developers to use Wiktionary for the translation. --LudwigSebastianMicheler (talk) 00:12, 9 November 2018 (UTC)
Word-by-word translation is often worse than reading in original. But some kint of tool: I click on the word and popup with wiktionary entry appears could be fine. But there are many blockers (first phab:T67117, then unusability ov hovercards on wiktionary...), not only technical, but also data - lack of entries on wiktionary. 07:28, 9 November 2018 (UTC)

If I look up the words in the short, simple sentence "Han springer till henne" ("He runs to her") on English Wiktionary (German Wiktionary didn't know any meaning of the word "springer" or "springa" in any of the languages it exists in), we run into a problem already on the second word: "springer" isn't translated, but explained as "present tense of springa". This is going to be true for a lot of words one encounters, unless the text is in e.g. Chinese. /Johan (WMF) (talk) 10:53, 9 November 2018 (UTC)

So in that case we need to concatenate entries? This would be useful for learning languages, just to check the odd word you don't know without breaking the flow of reading too much. HLHJ (talk) 08:20, 14 November 2018 (UTC)
I really fail to see how this would improve the Wikipedia reader experience. Word to word translations are often a complete disaster, even from one European language to the next. Needless to say the result is likely to be worse for non European languages with sometimes very different grammatical structures. --Braveheidi (talk) 02:06, 17 November 2018 (UTC)

Voting

  • Support Support Liuxinyu970226 (talk) 12:28, 18 November 2018 (UTC)
  • Support Support Jeb (talk) 16:00, 18 November 2018 (UTC)
  • Support Support Dvorapa (talk) 18:58, 18 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 13:48, 21 November 2018 (UTC)
  • Support Support Vulphere 16:58, 22 November 2018 (UTC)
  • Support Support i hope wiktionary can be extended to provide a freely licensed translation service :) Gryllida 07:17, 23 November 2018 (UTC)
  • Support Support Wikipedia App for Android has a similar feature. Matěj Suchánek (talk) 09:33, 24 November 2018 (UTC)
  • Support Support NankineseYang (talk) 00:48, 26 November 2018 (UTC)
  • Support Support Iich1960 (talk) 11:16, 28 November 2018 (UTC)
  • Support Support because I like the idea and as I told someone working on the translation tool at Wikimania this summer Wiktionary, used properly, has a lot of potential here. But, frankly, this is going to be a pretty big task. Daniel Case (talk) 03:13, 29 November 2018 (UTC)

Add buttons and keyboard shortcuts to move through category pages quickly

Edit proposal/discussion

  • Problem: English: It would be great if you could click on the forward or back arrow in the preview of the Wikimedia Commons file, causing the next or next file in the category to be loaded, respectively. I know that there is a 'Slideshow', but its launch closes the preview and access to categories, closes the panel on the left with tools and links for editors.
Original: Byłoby wspaniale, gdyby w podglądzie pliku na Wikimedia Commons można było kliknąć na strzałkę do przodu lub do tyłu powodując załadowanie odpowiednio pliku poprzedzającego lub następnego z kategorii. Wiem, że istnieje 'Slideshow', ale jego uruchomienie zamyka podgląd i dostęp do kategorii, zamyka panel z lewej strony z narzędziami i linkami dla edytorów.
  • Who would benefit: English: Commons users looking for files in the category structure.
Original: Użytkownicy Commons, poszukujący plików w strukturze kategorii.
  • Proposed solution: English: Add to the toolbar the left and right arrows displayed above the file, allowing you to load the previous and next file from the given category. The same effect should be given by pressing the "right / left" arrows on the keyboard.
Original: Dodanie do paska narzędzi wyświetlanego nad plikiem strzałek w lewo i prawo pozwalających na załadowanie pliku poprzedzającego i następnego z danej kategorii. Taki sam efekt powinno dawać naciśnięcie strzałek "prawo/lewo" na klawiaturze.
  • More comments:
  • Pharbricator tickets:

English

Arrows to navigate to next or previous file in category, visible on file description page but without opening slideshow function.

Dyskusja

Zapewne jakiś prosty gadżet mógłby to rozwiązać, ale kwestia jest taka, że musiałby wiedzieć z której kategorii wszedłeś w plik. --Wargo (talk) 23:36, 29 October 2018 (UTC)
Och, faktycznie. Zważywszy, że na stronę pliku można wejść z różnych miejsc, przeglądanie kolejnych plików wymagałoby raczej zawsze (przy uruchamianiu funkcji) wskazania kategorii, której zawartość chce się przeglądać... Kenraiz (talk) 12:40, 30 October 2018 (UTC)

I added Google translations for the proposal. I will rename the proposal as well. Thanks for submitting the proposal. -- NKohli (WMF) (talk) 21:38, 14 November 2018 (UTC)

Voting