Wikimedia Meta-Wiki

Community Wishlist Survey 2022/Reading

< Community Wishlist Survey 2022
Community Wishlist Survey 2022
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)[reply]

@Jdlrobson yes USI2020 (talk) 21:00, 31 January 2022 (UTC)[reply]
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)[reply]
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 (talk • contribs) 16:56, 7 February 2022 (UTC)[reply]
I have filed: phab:T301153 —TheDJ (talk • contribs) 17:01, 7 February 2022 (UTC)[reply]

Voting


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)[reply]

Discussion

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

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)[reply]

Voting

Collapsible subheadings on the mobile website

Discussion

Voting

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)[reply]

Discussion

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)[reply]

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)[reply]
    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)[reply]
    No problem! With your permission, I have reworded the proposal accordingly. Thanks, MusikAnimal (WMF) (talk) 22:45, 18 January 2022 (UTC)[reply]
    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)[reply]
  • 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)[reply]
  • Not articles, but also see WikiShootMe — GhostInTheMachine talk to me 22:44, 28 January 2022 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]

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)[reply]

Discussion

Voting

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)[reply]

Discussion

  • So... make the site slower to appease this aesthetic? No, no thank you. --Izno (talk) 20:13, 18 January 2022 (UTC)[reply]
    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)[reply]
    :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)[reply]
    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)[reply]
    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)[reply]

Voting

  • 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)[reply]

Discussion

Voting

  • 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)[reply]

Discussion

Voting

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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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 (talk • contribs) 13:00, 11 January 2022 (UTC)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]

Voting

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)[reply]

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)[reply]
    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)[reply]
  • 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)[reply]

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)[reply]

Discussion

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)[reply]
It appears there has been some work around using espeak, https://itinerarium.github.io/phoneme-synthesis/ Akathelollipopman (talk) 20:32, 28 January 2022 (UTC)[reply]

Voting

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)[reply]

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)[reply]
    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)[reply]
    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)[reply]
  • @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)[reply]
    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)[reply]
    @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;}

Voting

Using portal for Random Search in all wikis

Discussion

Voting