Community Wishlist Survey 2022/Reading

Reading
14 proposals, 209 contributors, 378 support votes
The survey has closed. Thanks for your participation :)



Page Previews show an error message on all links to Anexo: namespace in Spanish Wikipedia

Discussion

FYI, page previews currently runs on anything that's been identified as content in mw:Manual:$wgContentNamespaces. Would it be useful to add this namespace to the list of namespaces that are content ? Jdlrobson (talk) 04:25, 31 January 2022 (UTC)

@Jdlrobson yes USI2020 (talk) 21:00, 31 January 2022 (UTC)
I can help make this happen. Could you follow the guidelines on https://wikitech.wikimedia.org/wiki/Wikimedia_site_requests and discuss it on your wiki?
Note enabling page previews on this namespace would also lead this namespace to show up on different pages https://m.mediawiki.org/wiki/Manual:$wgContentNamespaces#Details so I want to make sure this was properly discussed. Jdlrobson (talk) 21:28, 31 January 2022 (UTC)
Something else seems wrong to me, as Anexo IS a content namespace. The console of mw.config.get().wgContentNamespaces reports [104, 0] and there is https://phabricator.wikimedia.org/T41866. So this seems like a Popups bug in that case. I will open a ticket. —TheDJ (talkcontribs) 16:56, 7 February 2022 (UTC)
I have filed: phab:T301153TheDJ (talkcontribs) 17:01, 7 February 2022 (UTC)

Voting

  •   Neutral You can file a bug in Phabricator. Thingofme (talk) 13:40, 1 February 2022 (UTC)

Pop-up upon selecting text

  • Problem: Sometimes, an article doesn't include a Wikilink for an important word. This isn't a huge problem but it would be nice to have the pop-up wiki box when selecting a word or term.
  • Proposed solution: When selecting a word while reading a pop-up appears with some options like: Select paragraph/section - Copy - Search Wikipedia/Wikimedia - Quote in discussion - Translate - etc.
  • Who would benefit: Readers
  • More comments:
  • Phabricator tickets:
  • Proposer: Omar.idma (talk) 08:12, 21 January 2022 (UTC)

Discussion

I personally would not like this, so I hope it would be implemented as optional. Libcub (talk) 23:17, 30 January 2022 (UTC)

I suspect this is intended to be an option in preferences similar to page preview preference is now. Kimdorris (talk) 03:43, 31 January 2022 (UTC)

Voting

  •   Support Useful! Lectrician1 (talk) 04:24, 29 January 2022 (UTC)
  •   Support It could be an interesting system - if it was also implemented as like when you select text you have the option to search Wikipedia or Wiktionary for it Ed6767 (talk) 15:33, 29 January 2022 (UTC)
  •   Support If this is implemented the way page preview popup is available under preferences I would definitely use it. Kimdorris (talk) 03:45, 31 January 2022 (UTC)
  •   Support Mohammad ebz (talk) 08:00, 1 February 2022 (UTC)
  •   Support Thingofme (talk) 13:30, 1 February 2022 (UTC)
  •   Support Thanks, EDG 543 (message me) 14:42, 1 February 2022 (UTC)
  •   Support Wargo (talk) 22:08, 1 February 2022 (UTC)
  •   Support Rotavdrag (talk) 11:25, 3 February 2022 (UTC)
  •   Support As an opt-in reader preference. Daniel Case (talk) 19:39, 3 February 2022 (UTC)
  •   Support - Darwin Ahoy! 00:37, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 03:28, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 09:37, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 00:49, 7 February 2022 (UTC)
  •   Oppose i think this would get annoying. Besides right click, long tap already brings up "Lookup" for me, a OS native option which basically does the same. —TheDJ (talkcontribs) 17:20, 7 February 2022 (UTC)
  •   Support Tom Ja (talk) 17:59, 7 February 2022 (UTC)

Collapsible subheadings on the mobile website

  • Problem: Pages with long sections get hard to skim
  • Proposed solution: Subheadings will be collapsible.
  • Who would benefit: Mobile website readers
  • More comments:
  • Phabricator tickets:
  • Proposer: NightWolf1223 (talk) 22:19, 10 January 2022 (UTC)

Discussion

  • @NightWolf1223: Expand and collapse all sections of the article text. Brilliant idea and probably not too difficult to implement. Could help in many situations. Got used to have this in Microsoft Word. I feel some sections could be collapsed by default, especially the references, which could be recognised any sections containing {{Notelist}}, {{Reflist}} {{Refbegin}}. Or this could be indicated by the editor by placing a special tag {{Collapse}}. Some problems would need to be sorted out however, as is discussed under WP:DON'T HIDE, which would have to be revised. Best regards, Johannes Schade (talk) 21:23, 11 January 2022 (UTC)
    Adding on, this could definitely be added to bigger articles like Elvis Presley or Dr. Martin Luther King Jr. Rzzor (talk) 22:39, 11 January 2022 (UTC)
    I do a lot of reading on mobile. This would be very useful if we could expand/collapse all as well as make lower subheadings expandable/collapsible. Kimdorris (talk) 03:51, 31 January 2022 (UTC)
  • I support this proporsal. In mw:Extension:MobileFrontend and mw:Skin:Minerva, only the whole level-2 headings are collapsible, and if the heading is expanded, the whole section is expanded, which causes inconvenience. --SolidBlock (talk) 10:05, 12 January 2022 (UTC)
  • Agreed. Would make things much neater for mobile users.
  • Given how collapsing in MobileFrontend works, this might not be sufficiently small for CommTech to deal with. --Izno (talk) 20:15, 18 January 2022 (UTC)
  • Thank you! This is very annoying. SSneg (talk) 21:12, 29 January 2022 (UTC)
  • (!)Advertising: See also FoldSection.js. NguoiDungKhongDinhDanh 20:14, 6 February 2022 (UTC)

Voting

  •   Support Gfombell (talk) 18:57, 28 January 2022 (UTC)
  •   Support One of the few features mobile has that would be useful to import to desktop. DMacks (talk) 22:12, 28 January 2022 (UTC)
  •   Support --𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 07:14, 29 January 2022 (UTC)
  •   SupportSHEIKH (Talk) 14:31, 29 January 2022 (UTC)
  •   Support Warmglow (talk) 17:05, 29 January 2022 (UTC)
  •   Support --SSneg (talk) 21:10, 29 January 2022 (UTC)
  •   Support czar 23:48, 29 January 2022 (UTC)
  •   Support Pelagic (talk) 01:02, 30 January 2022 (UTC)
  •   Support TheInternetGnome (talk) 08:23, 30 January 2022 (UTC)
  •   Support HynekJanac (talk) 17:19, 30 January 2022 (UTC)
  •   Support Kimdorris (talk) 03:51, 31 January 2022 (UTC)
  •   Support the wub "?!" 14:35, 31 January 2022 (UTC)
  •   Support Thingofme (talk) 13:36, 1 February 2022 (UTC)
  •   Support A.S. Universal (talk) 07:51, 2 February 2022 (UTC)
  •   Support I once top-leveled a section that semantically should have been lower in the hierarchy just in order to allow mobile users to collapse the section easily. YBG (talk) 07:23, 3 February 2022 (UTC)
  •   Support As a user preference, yes, not the default. Daniel Case (talk) 19:43, 3 February 2022 (UTC)
  •   Support - Darwin Ahoy! 20:55, 4 February 2022 (UTC)
  •   Support either way, but I'd like to note that it'd be better if subheadings are expanded by default - some subsections are little more than a sentence. Xurizuri (talk) 07:39, 5 February 2022 (UTC)
  •   SupportKPFC💬 11:13, 5 February 2022 (UTC)
  •   Support Hanif Al Husaini (talk) 12:09, 5 February 2022 (UTC)
  •   Support I almost always check "Desktop site" for Wikipedia on mobile, since everything being collapsed annoys me. paul2520 (talk) 20:14, 5 February 2022 (UTC)
  •   SupportThanks for the fish! talkcontrib (he/him) 21:56, 5 February 2022 (UTC)
  •   Support --Ytpks896 (talk) 00:52, 6 February 2022 (UTC)
  •   Support Toadspike (talk) 03:18, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 09:30, 6 February 2022 (UTC)
  •   Support --SmallJarsWithGreenLabels (talk) 11:50, 6 February 2022 (UTC)
  •   Support Pretty much every website I know has this feature, why not Wikipedia? InterstateFive (talk) 20:12, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 00:07, 7 February 2022 (UTC)
  •   Support Tom Ja (talk) 17:59, 7 February 2022 (UTC)
  •   Support Throast (talk) 15:45, 8 February 2022 (UTC)
  •   SupportDaxServer (t · c) 13:04, 9 February 2022 (UTC)
  •   Support At61 (talk) 14:32, 9 February 2022 (UTC)
  •   Support Gaurav (talk) 03:26, 11 February 2022 (UTC)
  •   Support DSparrow14 (talk) 17:55, 11 February 2022 (UTC)

floating table headers

  • Problem: when scrolling a long list, the header label of a column of data scrolls up out of view
  • Proposed solution: implement a feature where, for long lists, column headers (labels) are still visible (floating) as you scroll down.
  • Who would benefit: millions of people
  • More comments: this is a common feature on modern websites. example would be a table that includes country name, population, area in km, area in miles. but it's 100 lines long. so you scroll down & now you don't know which column is miles and which is km. you have to scroll back up & this degrades user experience. Think of freezing a line at the top of a spreadsheet in excel or google docs. this is the same principle, but of course implementing this on wikip will be more dynamic because a table is not the entire document on wikip.
  • Phabricator tickets: T42763
  • Proposer: Skakkle (talk) 23:50, 17 January 2022 (UTC)

Discussion

  • See w:MediaWiki:Gadget-StickyTableHeaders.js and w:MediaWiki:Gadget-StickyTableHeaders.css — Draceane talkcontrib. 22:07, 28 January 2022 (UTC)
    Agreed. This is already an available option in preferences, but apparently many people are unaware this option exists. —The preceding unsigned comment was added by Kimdorris (talk) 30 January 2022‎
    The gadget adds sticky column headers to all non-scrolling tables:
    See: w:Special:Preferences#mw-prefsection-gadgets. Search for "sticky" to find: "Make headers of tables display as long as the table is in view, i.e. 'sticky' (requires Chrome v91+, Firefox v59+, or Safari)." Unfortunately, it doesn't do sticky side headers, though. That would be helpful in tablets, and smaller notebooks. I tested the gadget again just now in Firefox, Edge, and Chrome. It works in all 3 in Windows 10 on my desktop PCs. Only problem is in Firefox where the internal header borders are missing. Here is a page to test it on that has complicated headers:
    w:List of U.S. states and territories by incarceration and correctional supervision rate.
    In desktop view while on my iPhone SE 2020 the gadget makes the column headers sticky. In mobile view while on my iphone the gadget does not make those column headers sticky.
    There are scrolling Covid-19 tables with a template style that makes both column and row headers sticky. The sticky headers work in desktop and mobile browsers. Tested in Safari, Edge, Chrome, and Firefox. For more info see:
    w:User:Timeshifter/Sandbox169. --Timeshifter (talk) 17:00, 2 February 2022 (UTC)
  • Let's not forget to make row headers left sticky so all relevant headers are always in view when scrolling large tables on small devices. Jroberson108 (talk) 05:01, 2 February 2022 (UTC)

Voting

Add a map to Special:Nearby

  • Problem: The w:Special:Nearby feature does not show a map, only a list of articles. A map is useful because you can visually make your way to notable sites near you such as landmarks, historic buildings, public art, moments, etc., and then read about them on Wikipedia. This used to be a feature in the Android app, but it was removed due to low usage and maintenance burden.
  • Proposed solution: Improve w:Special:Nearby to show a map. This could potentially then be loaded by the mobile applications without imposing a maintenance burden on the developers.
  • Who would benefit: Travelers, and everyone who enjoys maps and the Nearby feature.
  • More comments: See also: Talk:Community_Wishlist_Survey#"Nearby"_feature
  • Phabricator tickets:
  • Proposer: Another Believer (talk) 20:04, 17 January 2022 (UTC)

Discussion

  • @Another Believer: Unfortunately, as Tacsipacsi points out at Special:Diff/22626483, this feature was intentionally removed by the Android team due to low usage. This normally means a hard "no" from Community Tech, since we explicitly do not undo actions of other teams. However, I may see a path forward here. Tacsipacsi also helpfully pointed out that the Nearby feature in the app is not the same as w:Special:Nearby, which lacks a map (and possibly other things, not sure?). So, what if we were to change this proposal to be about adding a map to the existing web-based Special:Nearby? Then, if the Android team is okay with it, they can load this in a "frame" in the app, basically just loading the Special:Nearby page from the mobile website. This is similar to what happens when you click on "View history" for example; that page isn't built into the app, it's just serving the mobile website version. While this isn't perfect and won't perform as smoothly as the original in-app Nearby experience, it will ensure the Android team doesn't have to worry about maintenance burden, which was their reasoning for removing it. How does that sound? MusikAnimal (WMF) (talk) 21:42, 18 January 2022 (UTC)
    I don't exactly follow, but sure! I'd rather something come from this discussion than nothing. I just appreciated having the ability to pull up a map and make my way to notable sites in the area. If there's any way to do something like that, or even get us one step closer, I'm down. Thanks! -Another Believer (talk) 21:45, 18 January 2022 (UTC)
    No problem! With your permission, I have reworded the proposal accordingly. Thanks, MusikAnimal (WMF) (talk) 22:45, 18 January 2022 (UTC)
    As someone who built this feature (and recently rebuilt it again as the soon to be deployed Extension:NearbyPages), I'd love to see this, but I assure you I would have done it already if we had the means to do so.
    Our maps infrastructure is just not good enough to handle the kind of traffic this would bring. I think there's a lot of work to be done on the operations side to make this even feasible.
    Perhaps if this does get voted, this could live on tools lab or something. The newly built Nearby, can be used as a standalone app: https://wikipedia-nearby.netlify.app/ Jdlrobson (talk) 04:21, 31 January 2022 (UTC)
  • Another, IMO even more important limitation of the browser solution is that it requires that the browser tells it the location of the device and it shows articles around that area, while in the app I was able to move around on the map and thus see articles around arbitrary places (or even use the Nearby feature without granting access for the app to the location). Probably this functionality naturally comes from the map-based implementation, but I’d like to mention it explicitly, just to make sure. —Tacsipacsi (talk) 22:54, 19 January 2022 (UTC)
  • Not articles, but also see WikiShootMeGhostInTheMachine talk to me 22:44, 28 January 2022 (UTC)
  • Would have supported if I had known voting ended at 18 UTC. Also make it usable without granting GPS access per Tacsipacsi. ~~~~
    User:1234qwer1234qwer4 (talk)
    19:50, 11 February 2022 (UTC)
  • Since this wish was not ranked very high, thus I don’t hope CommTech will work on it, I created two tickets (phab:T303813 and phab:T303814) in the hope that other teams will fulfill the wish. Feel free to subscribe the tickets to track the development. —Tacsipacsi (talk) 11:45, 15 March 2022 (UTC)

Voting

Mobile app lists feature on desktop version

  • Problem: The lists feature on the mobile app, which allows you to save and group articles for later reading, is missing from the desktop version.
  • Proposed solution: I propose that the lists feature on the mobile app is brought to the desktop version of Wikipedia.
  • Who would benefit: I think that everyone would benefit, as being able to organize articles on the mobile app has certainly helped me expand my knowledge of certain subjects by grouping related articles in one place.
  • More comments:
  • Phabricator tickets:
  • Proposer: Owen1962 (talk) 19:47, 20 January 2022 (UTC)

Discussion

  • @Owen1962: Have you tried en:User:BrandonXLF/TodoList? NguoiDungKhongDinhDanh 19:48, 20 January 2022 (UTC)
    Awesome! I'll try that out. But I think the apps' Reading Lists are a different use case. Pelagic (talk) 00:58, 30 January 2022 (UTC)
  • You can install a browser extension for this as well. See Chrome and FirefoxTheDJ (talkcontribs) 17:23, 7 February 2022 (UTC)
    • That browser extension (at least the Firefox version, but I don’t think the Chrome one would be different) can only add articles to the reading list, not even remove articles, let alone displaying the list. It can be further developed to fulfill this wish, but in its current state it doesn’t. —Tacsipacsi (talk) 21:27, 8 February 2022 (UTC)
  • Would have supported if I had known voting ended at 18 UTC. ~~~~
    User:1234qwer1234qwer4 (talk)
    19:52, 11 February 2022 (UTC)

Voting

  •   Support extending Reading Lists for mobile web and desktop web. Pelagic (talk) 00:54, 30 January 2022 (UTC)
  •   Support HynekJanac (talk) 17:16, 30 January 2022 (UTC)
  •   Support Jmaxx37 (talk) 18:40, 30 January 2022 (UTC)
  •   Support Libcub (talk) 23:11, 30 January 2022 (UTC)
  •   Support As someone who wrote a gadget to do this, a lot of the hard work here has been done. This would be a useful feature and very achievable. Jdlrobson (talk) 04:16, 31 January 2022 (UTC)
  •   Support Thingofme (talk) 13:38, 1 February 2022 (UTC)
  •   Support ~ Amory (utc) 20:50, 2 February 2022 (UTC)
  •   Support Daniel Case (talk) 06:01, 4 February 2022 (UTC)
  •   SupportBilorv (talk) 19:34, 4 February 2022 (UTC)
  •   Support - Darwin Ahoy! 20:53, 4 February 2022 (UTC)
  •   Support paul2520 (talk) 20:09, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 03:31, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 09:33, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 00:26, 7 February 2022 (UTC)
  •   Support Toadspike (talk) 01:27, 7 February 2022 (UTC)
  •   Support Tacsipacsi (talk) 21:28, 8 February 2022 (UTC)
  •   Support β16 - (talk) 08:51, 9 February 2022 (UTC)
  •   Support Meiræ 22:21, 10 February 2022 (UTC)
  •   Support Jl sg (talk) 10:10, 11 February 2022 (UTC)

Automatically visit the corresponding URL without the section

  • Problem: When one visits "Page#Section", links to "Page" will still be colored blue (unvisited) rather than purple (visited).
  • Proposed solution: When one visits a section of a page directly (from the address bar or browser history, whether it be MS Edge, Google Chrome, or Mozilla Firefox), via a redirect or link from another page, or after saving a section edit, briefly redirect to the URL without the "#Section" part before jumping to the section. Such brief redirection should not be done if the link is to another section of the same page (in particular, if the link is from the TOC).
  • Who would benefit: Everyone
  • More comments:
  • Phabricator tickets:
  • Proposer: GeoffreyT2000 (talk) 16:49, 15 January 2022 (UTC)

Discussion

  • So... make the site slower to appease this aesthetic? No, no thank you. --Izno (talk) 20:13, 18 January 2022 (UTC)
    I do understand the idea of the wish and also agree that it would be beneficial for user experience to know which sections one has already visited and read through. @Izno do you know of any additional performance limitations that come with this? My worry would be, assuming this is a CSS change using the :visited pseudo class, that this would be privacy issue like described in https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector KSiebert (WMF) (talk) 10:41, 19 January 2022 (UTC)
    :visited already does display a different color for non-section links. The specific issue I have is the "add in a redirected page", which is decidedly a performance degradation (visiting 3 pages instead of 2 to get to the final location of the section). Izno (talk) 18:39, 19 January 2022 (UTC)
    We could perhaps add a click handler to "Page#Section" links and use History.pushState() to simulate "Page" as having been visited, and that would come with no performance degradation. However then hitting the browser's back button would first go to "Page" and would require a subsequent click to actually go back to where you were previously, which would be pretty odd from a user perspective. I'm not sure if using History.replaceState() or something else could get around that problem. MusikAnimal (WMF) (talk) 20:41, 27 January 2022 (UTC)
    I ran some tests and this seems doable. The better route I think would be to use History.replaceState() after the page has loaded, first replacing the URL without the hash ("Page") then quick re-replacing it so the URL is where you currently are ("Page#Section"). This avoids polluting the browser's history but still registers the URL as if it were visited. It feels a little hacky, but it seems to work! I'm not certain if this will fly as a feature built right into MediaWiki Core, but we could at the very least offer a gadget or something to do this. MusikAnimal (WMF) (talk) 00:30, 28 January 2022 (UTC)

Voting

  •   Oppose I prefer the current functionality. Libcub (talk) 23:21, 30 January 2022 (UTC)
  •   Oppose Also like Libcub Thingofme (talk) 13:32, 1 February 2022 (UTC)
  •   Oppose KingAntenor (talk) 06:55, 2 February 2022 (UTC)
  •   Oppose per above. I prefer as it is now.- Darwin Ahoy! 00:45, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 03:29, 6 February 2022 (UTC)
  •   Oppose Ayumu Ozaki (talk) 00:45, 7 February 2022 (UTC)
  •   Support We could make such functionality optional and configurable in user preferences if wanted. Lectrician1 (talk) 05:26, 6 February 2022 (UTC)
  •   Oppose DSparrow14 (talk) 17:56, 11 February 2022 (UTC)

Document symbols in external links

  • Problem: External links that do not link to https pages currently show the same icon as links to e.g. pdf's, either in the reference section or in the external links section. The reader should be aware that clicking on the link will result in downloading a document or open a reader or other program, rather than evoke a webpage. Especially PDF's may be large files.
  • Proposed solution: implement CSS resembling the en-wiki. May include docs like Word and Excell.
  • Who would benefit: All readers
  • More comments:
  • Phabricator tickets: phab:T298433
  • Proposer: Wickey (talk) 15:58, 12 January 2022 (UTC)

Discussion

  • @Wickey: Are you asking to have this implemented on nl.wikipedia? You need only to speak with one of the users at nl:Speciaal:Gebruikerslijst/interface-admin. It should be possible to make icons for Word and Excel docs, too, but only your local interface admins can implement this. Unless you are proposing this be changed on all wikis? MusikAnimal (WMF) (talk) 16:03, 12 January 2022 (UTC)
    The problem is valid for everyone on each wiki and the right icons do harm no one, so this simple solution should be implemented for all. I only see a benefit, so why would every wiki do the work that can be done once in Wikimedia? --Wickey (talk) 16:51, 12 January 2022 (UTC)
  • phab:T298433 seems highly relevant. --Izno (talk) 20:43, 18 January 2022 (UTC)

Voting

Display links to sister projects on mobile

  • Problem: When you view a Wikipedia article on mobile, the links to Commons and the other sister projects that appear in the sidebar are not visible in the mobile interface. This means that the links have to be manually displayed within the article (using en:Template:Commons category and the like), rather than using MediaWiki/Wikidata sitelinks.
  • Proposed solution: Display the links in a similar way to how the interlanguage links are displayed
  • Who would benefit: Readers using the mobile interface who want to access content from Wikipedia's sister projects
  • More comments: This was proposed on Phabricator, but was declined "as part of backlog upkeep". It is a critical issue for raising visibility of the sister projects on the mobile interface.
  • Phabricator tickets: phab:T219392, phab:T297327
  • Proposer: Mike Peel (talk) 20:28, 15 January 2022 (UTC)

Discussion

Voting

  •   Support Agree, but put this in mobile and apps section MrMeAndMrMeLet's talk 22:11, 28 January 2022 (UTC)
  •   Support Izno (talk) 23:55, 28 January 2022 (UTC)
  •   Support Daud Iffa (talk) 00:32, 29 January 2022 (UTC)
  •   Support Lectrician1 (talk) 05:29, 29 January 2022 (UTC)
  •   Support 𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 07:16, 29 January 2022 (UTC)
  •   Support Aca (talk) 15:03, 29 January 2022 (UTC)
  •   Support Nw520 (talk) 23:55, 29 January 2022 (UTC)
  •   Support Pelagic (talk) 00:26, 30 January 2022 (UTC)
  •   Support JAn Dudík (talk) 13:15, 31 January 2022 (UTC)
  •   Support Uanfala (talk) 13:52, 31 January 2022 (UTC)
  •   Support the wub "?!" 14:36, 31 January 2022 (UTC)
  •   Support Trey314159 (talk) 00:21, 1 February 2022 (UTC)
  •   Support Ok, because mobile users only see languages (it's hard to see) Thingofme (talk) 13:38, 1 February 2022 (UTC)
  •   Support Wargo (talk) 22:08, 1 February 2022 (UTC)
  •   Support Daniel Case (talk) 06:01, 4 February 2022 (UTC)
  •   Support - Darwin Ahoy! 01:04, 5 February 2022 (UTC)
  •   SupportKPFC💬 11:11, 5 February 2022 (UTC)
  •   Support paul2520 (talk) 19:59, 5 February 2022 (UTC)
  •   Support--Vulp❯❯❯here! 08:12, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 09:32, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 01:21, 7 February 2022 (UTC)
  •   Support Tom Ja (talk) 18:00, 7 February 2022 (UTC)
  •   Support At least on mobile web, but if possible, also in apps. Tacsipacsi (talk) 21:09, 8 February 2022 (UTC)
  •   Support · · · Peter (Southwood) (talk): 12:57, 9 February 2022 (UTC)
  •   SupportDaxServer (t · c) 13:06, 9 February 2022 (UTC)
  •   Support ~Cybularny Speak? 23:34, 9 February 2022 (UTC)
  •   Support Gaurav (talk) 03:18, 11 February 2022 (UTC)
  •   Support 4nn1l2 (talk) 12:40, 11 February 2022 (UTC)

Show disambiguation hatnotes only on redirect

  • Problem: Many disambiguation hatnotes are confusing and unnecessary.
  • Proposed solution: Only display disambiguation hatnotes when users are redirected from that term.
  • Who would benefit: All readers of Wikipedia.
  • More comments: If you visit the English Wikipedia article about the band Pink Floyd, the very first thing it says is:
"The Tea Set" and "The T-Set" redirect here. For tea service, see tea set. For the Dutch band, see Tee-Set. For other uses, see T Set (disambiguation).
There are two scenarios here:
1) You typed "The Tea Set" or "Tee-Set" into the Wikipedia search bar because you were looking for tea sets or the Dutch band, and not Pink Floyd. Great! This hatnote will help you find what you need.
2) You arrived at the article by any other means – from Google, say, or a link from another Wikipedia article, or by typing "Pink Floyd" into the Wikipedia search box. In this case, you definitely weren't looking for information about tea sets or Dutch bands, and the hatnote serves no function. It's confusing (it looks like you've been redirected), it's distracting, and it takes up prime real estate right at the top of the article.
I've written some more detail about this problem here.

Discussion

  • I do a bunch of maintenance and development of the hatnote infrastructure on English Wikipedia. Hatnotes are on-wiki constructs, rather than made by the MediaWiki software, so this proposal would require some sort of flag that templates or Lua modules could retrieve and act on. Mightn't that have caching implications? More generally, I think the benefits of this change are tenuous enough that they're outweighed by the work required to make it happen. {{Nihiltres |talk |edits}} 00:05, 11 January 2022 (UTC)
    • To avoid caching issues, this would probably best be accomplished with a CSS class that is only set to visible by the Mediawiki software when the mw-redirectedfrom message is being displayed. -- Ahecht (TALK
      PAGE
      ) 23:14, 11 January 2022 (UTC)
  • There are also instances that are more complicated than you describe that would need accommodating, including
    • Where hatnotes for redirects and the general page names are combined (e.g. at w:Barack Obama: "Barack" and "Obama" redirect here. For other uses, see Barack (disambiguation), Obama (disambiguation), and Barack Obama (disambiguation).)
    • Where multiple similar searches redirect to the same place but not all are shown, so fuzzy matching (prone to false positives and false negatives) or a hidden list of redirects maintained (ongoing maintenance requirement).
    • Where no specific redirects are shown, ("multiple terms redirect here...").
    • Pages that use non-standard hatnotes.
    So there would be a lot of work required for this, and I'm not really convinced that the "problem" is actually a problem that needs solving, let alone this much effort. Thryduulf (talk: meta · en.wp · wikidata) 01:41, 11 January 2022 (UTC)
  • I personally don't like the wordy part of these notices they should just be: "For similar topics, visit the topic disambiguation page." done... —TheDJ (talkcontribs) 13:00, 11 January 2022 (UTC)
    That's fine when the only link is to a disambiguation page that matches (or nearly matches) the title of the page. In the example the OP gives the "X redirects here" portion exists to:
    • explain why people are seeing the hatnote
    • to minimise the surprise of people who arrived via one of the redirects
    • to reassure those people that their search did work correctly and inform them that repeating it will just lead back to the same place.
    These are all important functions that cannot be done away with just because of simple dislike. Thryduulf (talk: meta · en.wp · wikidata) 14:33, 11 January 2022 (UTC)
  • I think it can be possible, like short description; and only be edited by source mode. However we have to code a lot to show that. Thingofme (talk) 07:12, 20 January 2022 (UTC)
  • A good idea in theory but impractical. Such hatnotes often silently cover a number of similar redirects. For example, Tilde's hatnote about ~ also applies to '~' and ∼ which redirect there too. Certes (talk) 01:42, 29 January 2022 (UTC)

Voting

  •   Support * Pppery * it has begun 18:53, 28 January 2022 (UTC)
  •   Oppose I create and edit a lot of hatnotes and I want to see, what kind of hatnote (if any) the article has. Taivo (talk) 20:35, 28 January 2022 (UTC)
  •   Oppose I'm not sure I agree with the fundamental premise that users coming from off-wiki will never benefit from hatnotes. I've certainly come in from Google before and found that it's brought me to the wrong biography. — OwenBlacker (Talk) 11:08, 30 January 2022 (UTC)
  •   Oppose Libcub (talk) 23:10, 30 January 2022 (UTC)
  •   Oppose Orange disambigs are not enough? Thingofme (talk) 13:39, 1 February 2022 (UTC)
    Not sure how colour-coding disambigs is related to displaying redirect-related hatnotes. And particularly when this proposal is placed in the "reading" category. ~~~~
    User:1234qwer1234qwer4 (talk)
    19:55, 11 February 2022 (UTC)
  •   Oppose Spurious KingAntenor (talk) 06:54, 2 February 2022 (UTC)
  •   Oppose We should not be making too many assumptions about what readers come for. This sounds like one of those proposals from editors who find hatnotes distracting and think we have entirely too many of them. If that's a problem, tech is not the solution. Daniel Case (talk) 19:42, 3 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 03:27, 6 February 2022 (UTC)
  •   Oppose Ayumu Ozaki (talk) 01:18, 7 February 2022 (UTC)
  •   Support This could be a very useful option for articles to have, assuming anyone figures out a way to make this technically feasible. I suspect that doing so would be quite difficult, however. Yair rand (talk) 07:24, 11 February 2022 (UTC)
  •   Oppose per the comments above from Certes' and myself above and the comments from OwenBlacker and Daniel Case in this section. Thryduulf (talk: meta · en.wp · wikidata) 14:11, 11 February 2022 (UTC)

User-defined bookmarks in articles.

  • Problem: Longer articles read on screen are often not read in one go; it therefore might be useful to be able to save the current position (section) in an article; should have to be done actively by the user; who also needs the possibility to remove the bookmark.
  • Proposed solution: Add user-manageable bookmarks (at the moment: one per article); and if the user returns to an article with a bookmark, directly jump to the bookmark.
  • Who would benefit: People reading longer articles on screen.
  • More comments:
  • Phabricator tickets:
  • Proposer: Eptalon (talk) 23:50, 21 January 2022 (UTC)

Discussion

  • Could also be useful to editors who want to come back and fix something, but must doe something else first. It would be handy to be able to delete the placeholder in situ, like select opens dialogue box with option keep or delete. This would probably be stored in a cookie or some other user linked place? · · · Peter (Southwood) (talk): 07:28, 24 January 2022 (UTC)
    There are different ways how to do it technically. Probably the easiest would be an "invisible label", linked to a section of the article. I also recon that it won't be a long term solution, because what if the article noticeably changes before you come back? - Also, I'd probably opt for something stored as part of the "user profile", not as a cookie. This would of course mean that unregistered users would not be able to use the feature. As stated: technical details to be worked out.--Eptalon (talk) 20:22, 31 January 2022 (UTC)
  • I hope the capability would be both intuitive and dynamic; it's great how some wiki-like software like Confluence will automatically have an anchor link option you can click when you hover on/near a section header (and it disappears when you scroll/navigate elsewhere). = paul2520 (talk) 20:02, 5 February 2022 (UTC)

Voting

IPA audio renderer

  • Problem: Not everyone can read IPA markup (e.g. /ˈbɜːrmɪŋəm/ for "Birmingham")
  • Proposed solution: A tool or gadget that takes IPA as input and outputs an audio file or stream.
  • Who would benefit: Anyone wanting to know how a word is pronounced, but who cannot read IPA
  • More comments: The Phabricator ticket includes various examples of third party tools that do this, as proofs of concept.
  • Phabricator tickets: phab:T298950; phab:T33221
  • Proposer: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:40, 15 January 2022 (UTC)

The Community Tech project page for this wish is at: Community Wishlist Survey 2022/Generate Audio for IPA

Discussion

  • Great idea. After all, the whole point of IPA is that it can be machine-rendered with reasonable accuracy. Rollo (talk) 19:04, 16 January 2022 (UTC)
    The idea does sound good, I want to add though that we are kind of depending on having a open source library the provides audio rendering of IPA markup. Is anyone aware of one? KSiebert (WMF) (talk) 13:58, 19 January 2022 (UTC)
I support this solution. When I read biographies in other Wikipedia, I want to hear how the name and surname are pronounced. IPA is unreadable to me. A reading machine would help a lot.--Rosewood (talk) 09:46, 21 January 2022 (UTC)
It appears there has been some work around using espeak, https://itinerarium.github.io/phoneme-synthesis/ Akathelollipopman (talk) 20:32, 28 January 2022 (UTC)
  • Aren't there 2-3 variants of IPA? (Only different in certain symbols)? - no idea, not a linguist.-Eptalon (talk) 23:54, 21 January 2022 (UTC)
    Hi Eptalon. Yes, mostly with tonal indication, but it is not such a big deal, there is several systems but no overlapping between them. Something else: A language with a large diffusion could have more than one way to capture the phonological representation, I mean the most systematic one despite local changes. This could still be conflictual between contributors when a phonetic change is typical in a large area such as a change on the sound of the letter d in Canadian French. Well, that was a serious answer. I hope you got the point (I am kind of a linguist). A shorter answer could have been: Yes, one IPA is a beer, the other one a script   Noé (talk) 13:33, 25 January 2022 (UTC)
  • I dare to say we have overlapping proposals here Community Wishlist Survey 2022/Wiktionary/Get free pronunciation data :) Xavier Dengra (MESSAGES) 23:56, 21 January 2022 (UTC)
  • This would be awesome and would be especially useful when learning new words on wiktionary.org Akathelollipopman 20:24, 28 January 2022 (UTC)
  • I am not favorable to this idea, I think a human voice is more accurate and give a useful warming touch. Noé (talk) 22:26, 28 January 2022 (UTC)
    You are not obliged to listen to IPA pronunciations. I look forward to hearing your plan for having a human voice on every article currently using IPA. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:22, 4 February 2022 (UTC)
  • @Sebastian Berlin (WMSE): Is this something WikiSpeech could solve? Ainali talkcontributions 15:42, 29 January 2022 (UTC)
    It should be able to, to some extent. It would help if there is a consistent markup for IPA (don't know if this is the case). As discussed above, IPA can be written a bit differently and with varying levels of detail. Having a TTS that can pronounce all possible IPA may not be realistic and some conversion will likely have to be implemented. E.g. when I did a quick test now I had to convert to /ˈbɝmɪŋəm/ for the TTS used by Wikispeech. Sebastian Berlin (WMSE) (talk) 09:07, 31 January 2022 (UTC)
  • Can IPA actually do this? The enwiki IPA help pages are full of indications that the same IPA is pronounced differently in different accents or dialects of English, warnings that the symbols aren't directly equivalent in other languages etc. If it can work reliably, this would be a useful feature, as IPA is incomprehensible to most readers. But we don't want a system that pronounces every word in (say) a mid-Atlantic accent, as if that's the only correct pronunciation. Modest Genius (talk) 20:49, 31 January 2022 (UTC)
    • Yes. See the linked proofs-of-concept, on the Phabricator ticket. Also note that at least one of them offers a choice of voices. Even so, better to have "every word in (say) a mid-Atlantic accent" than no audio pronunciation at all. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:20, 4 February 2022 (UTC)
  • Would have supported if I had known voting ended at 18 UTC. ~~~~
    User:1234qwer1234qwer4 (talk)
    19:58, 11 February 2022 (UTC)

Voting

  •   Support --Nachtbold (talk) 18:35, 28 January 2022 (UTC)
  •   Support Support this over the "get free data" one, this is already machine-ready data - just needs a rendering engine. — xaosflux Talk 19:26, 28 January 2022 (UTC)
  •   Support Femke (talk) 19:35, 28 January 2022 (UTC)
  •   Support Wskent (talk) 19:36, 28 January 2022 (UTC)
  •   Support Bischnu (talk) 20:26, 28 January 2022 (UTC)
  •   Support Akathelollipopman (talk) 20:33, 28 January 2022 (UTC)
  •   Support Vis M (talk) 21:08, 28 January 2022 (UTC)
  •   Support --YodinT 21:11, 28 January 2022 (UTC)
  •   Support --Matěj Suchánek (talk) 21:45, 28 January 2022 (UTC)
  •   Support - MrMeAndMrMeLet's talk 22:01, 28 January 2022 (UTC)
  •   Support UV (talk) 23:25, 28 January 2022 (UTC)
  •   Support Daud Iffa (talk) 00:34, 29 January 2022 (UTC)
  •   Support Huji (talk) 01:47, 29 January 2022 (UTC)
  •   Support Helpful to readers. {{u|Sdkb}}talk 03:23, 29 January 2022 (UTC)
  •   Support Ottawajin (talk) 05:42, 29 January 2022 (UTC)
  •   Support Lectrician1 (talk) 05:52, 29 January 2022 (UTC)
  •   Support --𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 07:15, 29 January 2022 (UTC)
  •   Support So useful. Tranhaian130809 (talk) 11:02, 29 January 2022 (UTC)
  •   Neutral Forgive me if I'm being arrogant here, but I don't feel IPA is too hard. I worry an automated voice could be difficult for some, especially with dialect differences. Celerias (talk) 11:15, 29 January 2022 (UTC)
  •   Support Meiræ 11:41, 29 January 2022 (UTC)
  •   Support --Spiros71 (talk) 12:59, 29 January 2022 (UTC)
  •   Support NguoiDungKhongDinhDanh 13:02, 29 January 2022 (UTC)
  •   Support Javiermes (talk) 14:02, 29 January 2022 (UTC)
  •   Support Aca (talk) 15:03, 29 January 2022 (UTC)
  •   Support Dexxor (talk) 15:27, 29 January 2022 (UTC)
  •   Support Ed6767 (talk) 15:34, 29 January 2022 (UTC)
  •   Support //Lollipoplollipoplollipop::talk 18:13, 29 January 2022 (UTC)
  •   Support would be really helpful. — Omnilaika02 (talk) 19:51, 29 January 2022 (UTC)
  •   Support ToBeFree (talk) 23:13, 29 January 2022 (UTC)
  •   Support Nw520 (talk) 23:54, 29 January 2022 (UTC)
  •   Support Pelagic (talk) 00:24, 30 January 2022 (UTC)
  •   Support Wostr (talk) 00:26, 30 January 2022 (UTC)
  •   Support Gusfriend (talk) 00:28, 30 January 2022 (UTC)
  •   Support Ali Imran Awan (talk) 07:17, 30 January 2022 (UTC)
  •   Support TheInternetGnome (talk) 08:22, 30 January 2022 (UTC)
  •   Support OwenBlacker (Talk) 11:03, 30 January 2022 (UTC)
  •   Support --Minorax«¦talk¦» 11:07, 30 January 2022 (UTC)
  •   Support«« Man77 »» [de] 13:42, 30 January 2022 (UTC)
  •   Support NightWolf1223 (talk) 15:08, 30 January 2022 (UTC)
  •   Support HynekJanac (talk) 17:20, 30 January 2022 (UTC)
  •   Support czar 19:42, 30 January 2022 (UTC)
  •   Support KevinL (aka L235 · t) 20:58, 30 January 2022 (UTC)
  •   Support Libcub (talk) 23:23, 30 January 2022 (UTC)
  •   Support if technically possible – Teratix 07:03, 31 January 2022 (UTC)
  •   Support Penalba2000 (talk) 07:27, 31 January 2022 (UTC)
  •   Support Is not big problem to read IPA (because characters are letter-like), but is problem to write it and understand every nuance. JAn Dudík (talk) 13:03, 31 January 2022 (UTC)
  •   Support Lrkrol (talk) 14:53, 31 January 2022 (UTC)
  •   Support Sadads (talk) 15:50, 31 January 2022 (UTC)
  •   Support Bencemac (talk) 18:04, 31 January 2022 (UTC)
  •   Support Mbkv717 (talk) 20:10, 31 January 2022 (UTC)
  •   Support stwalkerster (talk) 23:43, 31 January 2022 (UTC)
  •   Support Dave Braunschweig (talk) 00:05, 1 February 2022 (UTC)
  •   Support Trey314159 (talk) 00:22, 1 February 2022 (UTC)
  •   Support Labdajiwa (talk) 03:30, 1 February 2022 (UTC)
  •   Support Characters to write IPA for different supporters Thingofme (talk) 13:33, 1 February 2022 (UTC)
  •   Support * Pppery * it has begun 00:07, 2 February 2022 (UTC)
  •   Support Hiàn (talk) 04:28, 2 February 2022 (UTC)
  •   Support good one Paradise Chronicle (talk) 05:13, 2 February 2022 (UTC)
  •   Support Serg!o (talk) 12:07, 2 February 2022 (UTC)
  •   Support Camillu87 (talk) 13:00, 2 February 2022 (UTC)
  •   Support Geert Van Pamel (WMBE) (talk) 16:12, 2 February 2022 (UTC)
  •   Support Would be fabulous, I imagine it would be a welcome feature for the wider group of readers as well. ~ Amory (utc) 20:51, 2 February 2022 (UTC)
  •   Support Aimwin66166 (talk) 06:08, 3 February 2022 (UTC)
  •   Support Rotavdrag (talk) 11:27, 3 February 2022 (UTC)
  •   Support Paucabot (talk) 15:42, 3 February 2022 (UTC)
  •   Support WikiAviator (talk) 16:13, 3 February 2022 (UTC)
  •   Support Daniel Case (talk) 19:44, 3 February 2022 (UTC)
  •   Support Wutsje (talk) 20:46, 3 February 2022 (UTC)
  •   Support Ninepointturn (talk) 17:02, 4 February 2022 (UTC)
  •   SupportBilorv (talk) 19:15, 4 February 2022 (UTC)
  •   Support Pi.1415926535 (talk) 21:59, 4 February 2022 (UTC)
  •   Support - Darwin Ahoy! 01:02, 5 February 2022 (UTC)
  •   Support Feoffer (talk) 07:53, 5 February 2022 (UTC)
  •   Support Tomastvivlaren (talk) 08:47, 5 February 2022 (UTC)
  •   Support Kpjas (talk) 10:30, 5 February 2022 (UTC)
  •   Support SD0001 (talk) 17:31, 5 February 2022 (UTC)
  •   Support Lambsbridge (talk) 17:51, 5 February 2022 (UTC)
  •   Support paul2520 (talk) 20:07, 5 February 2022 (UTC)
  •   Support Waldyrious (talk) 23:28, 5 February 2022 (UTC)
  •   Oppose --Ciao • Bestoernesto 03:31, 6 February 2022 (UTC)
  •   Support Michael Barera (talk) 06:10, 6 February 2022 (UTC)
  •   Support--Vulp❯❯❯here! 08:12, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 09:39, 6 February 2022 (UTC)
  •   Support Emaus (talk) 17:49, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 00:23, 7 February 2022 (UTC)
  •   Support KnowledgeablePersona (talk) 23:43, 8 February 2022 (UTC)
  •   Support β16 - (talk) 08:52, 9 February 2022 (UTC)
  •   Support Bodhisattwa (talk) 09:38, 9 February 2022 (UTC)
  •   Support · · · Peter (Southwood) (talk): 11:20, 9 February 2022 (UTC)
  •   SupportDaxServer (t · c) 12:57, 9 February 2022 (UTC)
  •   Support ~Cybularny Speak? 23:30, 9 February 2022 (UTC)
  •   Support Quiddity (talk) 08:45, 10 February 2022 (UTC)
  •   Support Sunpriat (talk) 02:07, 11 February 2022 (UTC)
  •   Support I would also prefer human recordings instead of audio rendering, but issues of scale aside, I think doing something like this (1) would provide an immediate benefit to many, many users on many, many articles and (2) might stimulate people to say to themselves, hey, I can record a better pronunciation than that -- and then hopefully they'll do that and upload it to the Commons. Gaurav (talk) 03:22, 11 February 2022 (UTC)
  •   Support Jl sg (talk) 10:10, 11 February 2022 (UTC)
  •   Support evrifaessa (talk) 16:58, 11 February 2022 (UTC)
  •   Support Valerio Bozzolan (talk) 17:15, 11 February 2022 (UTC)
  •   Support -BRAINULATOR9 (TALK) 17:22, 11 February 2022 (UTC)

Color Coded Sections

  • Problem: Due to how articles currently are (at least, in enWiki, I don't know what they look like in other wikis) they're hard to read in a single sitting for those who have a hard time looking at a screen for long periods of time.
  • Proposed solution: My solution is color code the sections (or at least have slightly different colored backgrounds for each different section). Doing this can make it so the words don't blend together as much and make articles much easier to read. I will provide my perspective on this in the "More comments" section.
  • Who would benefit: Those who have a hard time focusing on a screen for long periods of time
  • More comments: I myself have Autism and so I have a shortened attention span. Despite this when I get into something I stay focused on it. However, I have a hard time reading articles because all the words just blend together or I lose track of where I am (as far as I know I am not dyslexic). However, if the sections were color coded (or at least, have a lightly colored background) I would be able to read articles easier. THis can just be something in preferences and wouldn't be enabled by default (we don't want Wikipedia to look like it's meant for children with all the pretty colors in articles by default) and would be an accessibility feature, making Wikipedia all the more accessible.
  • Phabricator tickets:
  • Proposer: Blaze Wolf (talk) 15:02, 11 January 2022 (UTC)

Discussion

  • @Blaze Wolf: would it be enough if the section headers were brightly background colored to help break up the page? An example of that can be seen on this testwiki page. If that suffices, it is something that can be done with a personal css file (or a community gadget that does the same thing if it was popular enough). — xaosflux Talk 19:42, 11 January 2022 (UTC)
    Sort of... there are a few issues with that. 1. the color isn't limited to just be around the word and instead goes all the way across the screen making it a tad distracting and 2. It doesn't make longer sections of the article (which that example of the Moon article doesn't have any sections long enough to be difficult to read) any easier to read as once you get past the header, there's still text there. Also, it being a solid color makes it even more distracting. I was thinking of still using colors but making them partially transparent. Blaze Wolf (talk) 19:46, 11 January 2022 (UTC)
    OK, no worries - this idea can certainly still be discussed, was thinking of a "quick fix" for you in the meantime! — xaosflux Talk 19:49, 11 January 2022 (UTC)
  • @Blaze Wolf: How about something like THIS EXAMPLE? The colors are certainly adjustable, just made for example. — xaosflux Talk 20:03, 11 January 2022 (UTC)
    That's definitely more along the lines of what I was thinking. Wasn't necessarily thinking of a different color for each paragraph but that does certainly still work and help break up the text and make it more readable. Again, I was thinking of having the colors being slightly transparent so as to not distract from the text (And also make it readable if a darker color happens to be used, although regardless a darker color might still have to be avoided). Blaze Wolf (talk) 20:39, 11 January 2022 (UTC)
    @Blaze Wolf: I see you are mostly on the English Wikipedia, you can experiment with colors and this going to this page: w:en:User:Blaze Wolf/common.css and putting this code in it:
.mw-parser-output > p:nth-child(odd) {background-color: coral;}
.mw-parser-output > p:nth-child(even) {background-color: green;}
  • You can set the colors the same if you don't want odd/even for a test, you can use any color from this list: w:en:Web colors, or even use hex codes. What that code is doing is adding you own style to the "p" elements (paragraphs) that are part of the body of the page. If this solves your need, we can probably document this a bit more and close this proposal out as not needing software. — xaosflux Talk 21:30, 11 January 2022 (UTC)
    It doesn't appear that it allows for the background color to be transparent. IF there's a way to do that though please tell me as I'm not familiar with how CSS works or how to write code in it. Blaze Wolf (talk) 21:40, 11 January 2022 (UTC)
    @Blaze Wolf: try this one, it uses rgba opacitiy, code is here: testwiki:MediaWiki:Tritontest4.css. — xaosflux Talk 22:35, 11 January 2022 (UTC)
    That should work. Only issue is if you don't understand how CSS works you wouldn't know what to change to achieve the effect you're looking for (like increasing or decreasing the opacity of the colors or changing the colors). Blaze Wolf (talk) 16:09, 13 January 2022 (UTC)
    @Blaze Wolf: ok that's good news - something like that can easily be made in to a "gadget", it would mean someone could turn it on or off in preferences - though they would be stuck with whatever color scheme their project decided on. So even if this doesn't get voted up on the wishlist survey, it could still be locally implemented with minimal fuss. — xaosflux Talk 16:16, 13 January 2022 (UTC)
    Can't gadgets still have preferences? Cause i'm fairly sure Twinkle is a gadget on enWiki but it has preferences you can change. Blaze Wolf (talk) 16:17, 13 January 2022 (UTC)
    @Blaze Wolf: they can, but then either someone needs to build a preference handler in to it as well (now moving it from a pure CSS gadget to a JS gadget) and/or it will require end users to update their bespoke values somewhere. In the meantime, if you want that latest version to go live for yourself, just copy the two lines of code from testwiki:MediaWiki:Tritontest4.css to w:en:User:Blaze Wolf/common.css and click publish. The rgba(255, 0, 0, 0.2) takes 4 numbers, 0-255,0-255,0-255,0.00-1.00). Some external tools such as <https://rgbacolorpicker.com/> can help you pick the colors that work best for you. — xaosflux Talk 16:36, 13 January 2022 (UTC)
  • This does seem like a very interesting idea, especially from a accessibility perspective, I would like to discuss this one with a group of wikimedians that discuss accessibility frequently. KSiebert (WMF) (talk) 11:22, 19 January 2022 (UTC)
  • If somebody needs a specific color scheme due to their impairment (mental, visual or anything else), they should have access to a wiki skin with proper colors. But there is definitely no need to impose this on every user. SSneg (talk) 21:13, 29 January 2022 (UTC)
  • I think it would be beneficial to add more accessible style/template choices for the average user who isn't familiar with CSS. Kimdorris (talk) 04:03, 31 January 2022 (UTC)

Voting

  •   Support Klein Muçi (talk) 00:54, 29 January 2022 (UTC)
  •   Support Javiermes (talk) 13:58, 29 January 2022 (UTC)
  •   Support but as an opt-in accessibility feature. Many people could also find the different colours overwhelming if enabled by default and it could present printing issues. Ed6767 (talk) 15:36, 29 January 2022 (UTC)
  •   Oppose SSneg (talk) 21:12, 29 January 2022 (UTC)
  •   Support This seems like it could be relatively simple to implement as an opt-in accessibility skin that we could highlight to all users through an Accessibility sidebar option. Personally I'd hate it, but if it could prove useful to other users, that seems worth doing. OwenBlacker (Talk) 11:12, 30 January 2022 (UTC)
  •   Support I do not have visual or learning disabilities (beyond needing glasses), and I would quite like this. Libcub (talk) 23:16, 30 January 2022 (UTC)
  •   Support JPxG (talk) 00:57, 31 January 2022 (UTC)
  •   Support Uanfala (talk) 13:42, 31 January 2022 (UTC)
  •   Support Thingofme (talk) 13:43, 1 February 2022 (UTC)
  •   Oppose KingAntenor (talk) 06:57, 2 February 2022 (UTC)
  •   Support the CSS solution works well if you know how to adjust css and copy it, but making a gadget with some default colors themes would be good for various use cases, people with various color-blindness etc.. and improving reader experience is at the heart of what we should strive for. Shushugah (talk) 21:31, 2 February 2022 (UTC)
  •   Support: specifically, the idea I'm supporting is an opt-in customisable skin like xaosflux has mocked up (maybe linked in the main sidebar) with some default options that are provably useful to neurodiverse people (I'm thinking of perceptual processing difficulties like Irlen syndrome). If this was for editors I'd say "write a gadget yourself", but the target audience is all readers, so it would really need to be built-in. — Bilorv (talk) 19:33, 4 February 2022 (UTC)
  •   Support paul2520 (talk) 20:10, 5 February 2022 (UTC)
  •   Support--Vulp❯❯❯here! 08:12, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 03:55, 7 February 2022 (UTC)
  •   Support Jl sg (talk) 10:10, 11 February 2022 (UTC)

Using portal for Random Search in all wikis

Discussion

  • @Anupamdutta73: Are you aware of Special:RandomInCategory? So to get a random living person on English Wikipedia, for instance, you could use w:Special:RandomInCategory/Living people. For more fine-grained topics, on English Wikipedia you could go by a WikiProject. The only issue there is the categories go on the talk page, so you'll have to click through to read the actual article. Nonetheless it usually works quite well, for instance w:Special:RandomInCategory/WikiProject Geography articles for Geography. I say "usually" because there are bugs such as phab:T202204 and more importantly, phab:T200703. So maybe your proposal could be about improving Special:RandomInCategory. How does that sound? Or is there a different solution you were looking for? MusikAnimal (WMF) (talk) 18:10, 13 January 2022 (UTC)
    Dear @MusikAnimal (WMF), what you have explained is for seasoned Wikimedians... and a bit troublesome. :) What I propose is anybody on wanting to click the Random Page can have a choice to have a Random Page in his/her choice of Category..... Have an additional button with filter options... Anupamdutta73 (talk) 05:52, 14 January 2022 (UTC)
    @Anupamdutta73 Got it! Then I think what you need is what I was proposing. Basically a Special:RandomInCategory (your local wiki can put the link on the sidebar next to "Random page" if they want to) that allows you to enter a category, and even restrict it to a namespace (probably just articles in your case). With your permission I'd be happy to reword your proposal to be about this, adding the few technical details some people will need in order to decide on whether or not to support. Let me know! Thanks, MusikAnimal (WMF) (talk) 06:02, 14 January 2022 (UTC)
    Dear @MusikAnimal (WMF), you nailed it.... Please go ahead and reword it for maximum effect... so that a first timer can use it effectively.... Anupamdutta73 (talk) 06:10, 14 January 2022 (UTC)

Voting

  •   Support for more precise searching. on Wikisource i often got page: instead of main namespace. JAn Dudík (talk) 13:15, 31 January 2022 (UTC)
  •   Support Thingofme (talk) 13:37, 1 February 2022 (UTC)
  •   Support: more interesting to the average reader who currently presses "Random article" every so often, and a much improved experience for any editor working through a backlog of some kind. — Bilorv (talk) 19:40, 4 February 2022 (UTC)
  •   Support I like the idea that this could be automatically linked on a given Category page. paul2520 (talk) 20:06, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 03:27, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 00:08, 7 February 2022 (UTC)