# Community Wishlist Survey 2021/Reading

13 proposals, 236 contributors, 346 support votes
The survey has closed. Thanks for your participation :)

## "Favourite" or "Followed pages" button

• Problem: Watchlist not so reader-friendly
• Who would benefit: everyone
• Proposed solution: either a new"Favourites" button or a button which would lead the reader directly to the read version of the watchlist pages, ordered alphabetically.
• Phabricator tickets:
• Proposer: cristixav (talk) 09:05, 17 November 2020 (UTC)

### Discussion

I think it would be helpful to have either a "Favourite pages" button, which would lead the readers straight to a list of pages they like/constantly need for reference etc, which would be internal, i.e. once a wikimedia project is accessed, and not relying on the "favourite" feature of the browser. Alternatively, one could create a button for the existing watchlist, which would lead the reader directly to the read version of the article. The list of favourites/watched pages should be alphabetical and not dependent upon the chronology of updates. All the existing features would remain in place. Ideally, such a button should also work across languages and projects. cristixav (talk) 09:05, 17 November 2020 (UTC)

I don't see what benefits this would bring over the bookmark feature or the session/tab-saving feature every browser I know of has. Silver hr (talk) 11:53, 17 November 2020 (UTC) Actually, I thought of one - storing the data remotely would make it work across devices. But then again, cloud services for storing bookmarks/browser sessions exist. I guess I'm neutral on this. Silver hr (talk) 12:00, 17 November 2020 (UTC)
• I'm merging a very similar proposal here. It was Add a "favorite this page" in the "watch this page" star:
• Problem: The most important articles to a particular editor get lost in a big watchlist
• Who would benefit: Editors who watch a lot of stuff
• Proposed solution: Add the possibility to "favorite this article". A favorite article would be represented by a golden star where the blue star currently is. Favorite articles (or pages in general) would always appear at the top of the watchlist. A favorite page would also include all the other characteristics of a watched page.
• Proposer: Bageense (talk) 16:49, 24 November 2020 (UTC)
@Bageense: I hope this is okay! Sam Wilson 02:35, 25 November 2020 (UTC)
• This sounds similar to the way the Wikipedia app is set up, with its saved and reading list features. An importation of that sounds good. IntegralPython (talk) 21:43, 27 November 2020 (UTC)

### Voting

•   Strong support This proposal is a duplicate of another proposal for bookmarks, however, I will support this, Wikipedia needs bookmarks. MarioSuperstar77 (talk) 20:43, 8 December 2020 (UTC)
•   Support Redactedentity (talk) 23:44, 8 December 2020 (UTC)
•   Support-BALA. RTalk 01:26, 9 December 2020 (UTC)
•   Support PianistHere (talk) 01:55, 9 December 2020 (UTC)
•   Support Hanif Al Husaini (talk) 01:59, 9 December 2020 (UTC)
•   Support Most views (iP users can also vote? Why is there a user like this on it?)Wiok (talk) 02:54, 9 December 2020 (UTC)
•   Support Omda4wady (talk) 07:34, 9 December 2020 (UTC)
•   Support Browk2512 (talk) 17:51, 9 December 2020 (UTC)
•   Support TheAmerikaner (talk) 20:31, 9 December 2020 (UTC)
•   Support P.Marlow (talk) 01:30, 10 December 2020 (UTC)
•   Support JPxG (talk) 06:05, 10 December 2020 (UTC)
•   Support Nonahg (talk) 08:59, 10 December 2020 (UTC)
•   Support Strong support, bc promote usability and easiness. BoldLuis (talk) 18:08, 11 December 2020 (UTC)
•   Support Wikianer (talk) 09:54, 12 December 2020 (UTC)
•   Support Rdyornot (talk) 22:36, 12 December 2020 (UTC)
•   Support Déjà croisé des nouveaux qui pensaient que la liste de suivi est une page pour mettre ses favoris et qui ducoup s'étonnaient de ne pas les voir ensuite car la page en question n'était pas modifier. Je pense qu'on pourrait intégrer ça dans Spécial:Homepage du projet croissance par exemple. -- Nemo Discuter 10:51, 13 December 2020 (UTC)
•   Support SeGiba (talk) 18:07, 15 December 2020 (UTC)
•   Support Jstalins (talk) 04:28, 16 December 2020 (UTC)
•   Support Wolfmartyn (talk) 13:59, 16 December 2020 (UTC)
•   Support Épico (talk)/(contribs) 23:17, 16 December 2020 (UTC)
•   Support EasyKL (talk) 03:49, 17 December 2020 (UTC)
•   Support Станислав Кондратьев (talk) 23:12, 17 December 2020 (UTC)
•   Support Xhs 唯心而为 10:22, 18 December 2020 (UTC)
•   Support Anomlia (talk) 09:42, 20 December 2020 (UTC)
•   Supporttyseria 01:53, 21 December 2020 (UTC)

## Find a more satisfactory display of LaTeX formulas

(Machine translation from French to English.)

• Problem: The current system for displaying and exporting mathematical formulas leaves much to be desired. The formulas are converted into images where the text appears in black on a transparent background, then inserted into the text thread. For this reason, mathematical formulas more or less clash with the surrounding text:
- on the site, the formulas are always black, whatever the color of the surrounding text (see this page, the note); the same on the e-reader, where the problem even more annoying for people who use an e-reader with a dark background: the formulas are properly illegible;
- the alignment of the mathematical text on the line is not perfect, nor its size;
- more anecdotally, the font differs from the ambient font.
This also causes purely typographical problems, in particular the rejection of punctuation on the next line when the formula is at the end of the line (cf. the same example, in the second paragraph, or the next page, first line).

I would therefore like to see the formulas rendered in a more coherent manner with the surrounding text, and above all in such a way as not to violate the most basic rules of typography.

• Who would benefit: All readers of scientific texts, especially those who export them from Wikisource.
• Proposed solution: For display on website: solutions, like MathJax for example? For export: we could offer several export options, one that would keep the current state, with conversion of formulas into images; another with export of the TeX syntax directly (well rendered under Caliber for example); etc.
• Other comments: Please note that the request does not concern the input of mathematics by contributors, but their display and export.
• Proposer: ElioPrrl (talk) 18:25, 23 November 2020 (UTC)

## Alt-Texts and Image Descriptions

• Problem: There are many images without alt-texts and/or image descriptions for visually impaired people. Images without that are not accessible for blind people. Texts related to undescribed pictures aren’t fully accessible as well.
• Who would benefit: Visually impaired people
• Proposed solution: Add a field in media-uploader on Commons via structured data to raise awareness and to supply images with alt-texts and image descriptions.
• More comments: Existing descriptions on Commons and Wikipedia f. e. are not descriptions as mentioned above.
• Proposer: Conny (talk) 05:52, 27 November 2020 (UTC)

### Discussion

• Good proposal. Also it would be helpful to explicitly describe what an alt text should be, as I suspect many people do not know (considering what I've seen in those instances where there is an alt text). On a related note, would it be possible to add default alt text automatically by a image recognition software (that can then be improved by humans)? --Ita140188 (talk) 04:24, 2 December 2020 (UTC)
• If this is a proposal to centrally store alt text for images, to be used on projects, then I strongly oppose it, for the reasons given when it has been previously suggsted elsewhere, and rejected. At the very least, please do not progress this proposal without first consulting with screen reader users and/or accessibility professionals. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:39, 10 December 2020 (UTC)
• Yet another field? Why not just use the image's plain old description? --NaBUru38 (talk) 21:04, 10 December 2020 (UTC)
These are two different things. Alt text is a substitute for the seeing: it describes things that many readers have already seen in the image. A description explains something above and beyond what you’re seeing, it serves both sighted and blind readers, and it may be useless unless you can see the image or read the alt text. (I am not an expert, but I’m sure I can provide an example or two if this is still unclear.) Michael Z. 2020-12-11 23:14 z 23:14, 11 December 2020 (UTC)
• A proposal shall suggest that a particular problem needs to be solved, but it should refrain from requiring implementation details. It is up to research and broader considerations which approach is finally chosen to reach the target.
An older plan for global storage of descriptive texts which will be delivered every time an image is transcluded on any page has been:
<alternatetext lang="fr">…</alternatetext>
<alternatetext lang="pt">…</alternatetext>
Those would be located on description page, and best match for user language including finally fallback to English if present will be added to image presentation by the server. It is not limited to Commons and some Commons-only structured data, but will work on every wiki even out of WMF for local media as well.
BTW, the technicalities about alt text and screen readers and accessibility started with HTML.4 in 1998, and were further developed by ARIA. It is quite clear what is to be delivered within the HTML document.
--PerfektesChaos (talk) 16:42, 12 December 2020 (UTC)
• I fully support the general idea of the proposal but it has some major flaws. First of all, this proposal would have huge impact on the Commons community's workload (manually adding structured text) and should therefore ask for their support at Commons:Requests and votes. Also, I agree with PerfektesChaos and Andy Mabbett. Chances are there is a different solution that serves people with a vision impairment better and faster. Any such solution needs to be based on actual user needs and their standard accessibility technology. I would rather support a community request to the Wikimedia Foundation asking they generally update their websites to meet current accessibility standards. --Martina Nolte (talk) 19:12, 12 December 2020 (UTC)
Thank you for your general support. The Image Description is an optional additional information, so it should grow in a slow way. It would make sence to have new authors for reviewing these texts. Conny (talk) 10:59, 13 December 2020 (UTC).
• As explained in the linked tasks, having a place in UploadWizard to enter alt text is part of the work needed to get it to users, but we'd also need a mechanism to transfer the data from Commons to the wikis using the image. I agree with PerfektesChaos that this proposal could use some more generic phrasing. --Tgr (talk) 00:26, 13 December 2020 (UTC)
• What the proposal actually wanted to express:
Implement a mechanism to deliver alternate texts with every image transclusion in user language that are stored and maintained centrally together with the image media, if the current transclusion does not provide an alt= parameter.
However, the first proposal is too explicit and specific on the following keywords:
Commons – what about images on local wikis? What about non-WMF MW installations?
structured data – this is one particular storage mechanism, but quite limited to Commons and WMF at least. The proposal should not prejudice one solution only.
Uploading – what about 100,000,000 images present on Commons and local wikis when roll out date of the new mechanism arrived? Really a feature for uploading future images only?
The proposal sounds a bit as if everybody uploading a new image shall be forced to provide a description for blind people, even more as a mandatory requirement?
✦ Sounds like a further threshold to make uploading forms and procedure more difficult.
✦ It needs some understanding what visually impaired people need, and in opposite to a common legend. That was already raised in this section. The traditional legend is specifying which things are presented by the image. The alternate text is telling what is visible, and rather pointless for those who can see the image. Writers must have a deeper concept which information blind people require to imagine the image from text.
✦ The uploader could have taken a picture of the it:colosseo and provided an alternate text in mother tongue, Italian. Readers of a Wikipedia article in Japanese or Spanish might want to hear a concise description, not really a machine generated one, in their native language.
✦ However, if ever working current automatic translations are pretty smart and might create a version in user language on the fly. But this is step 2+x far off.
There is already an implementation for the tag extension approach <alternatetext> running: TemplateData are creating a compressed JSON description of the <templatedata> element which is stored as page property of the template page. That might be a role model how <alternatetext> can be evaluated when saving an image description page and create a similar page property of the media. When delivering an image transclusion within a particular HTML page in a particular user language that page property may be evaluated by fallback cascade. If cache administration is complaining then page language is acceptable.
✎ Rather than delivering to everybody with all HTML pages, a page property could be evaluated and add alt text on client side to the document in user language by a MW gadget for those who have a preference for this feature. However, screenreaders are reluctant to execute JavaScript.
Greetings --PerfektesChaos (talk) 18:29, 13 December 2020 (UTC)
The "user language" part is debatable (everything else about the article, including the image caption, is in content language; why would the alt text be an exception? Architecturally, it wouldn't really fit into our current caching model); otherwise this is a good description. Using structured data is a no-brainer, but certainly doesn't have to be stated explicitly in the proposal. --Tgr (talk) 23:57, 13 December 2020 (UTC)
I wrote “If cache administration is complaining”.
Looking at my last point delivering later on client side for a very small minority rather than for everybody but ignored by >99% of visitors and consuming bandwidth, on client side the user language is known, and of course the description would be told in user language if available even when visiting an article in a different wiki but the environment around the article is in user language.
How does “structured data” fit into local and non-WMF wikis?
Greetings --PerfektesChaos (talk) 17:06, 14 December 2020 (UTC)
• As a screen reader user, I think this is a good idea in theory, but I tend to agree with the concerns of Andy Mabbett, PerfektesChaos, etc. The correct alt text for an image (as opposed to its description) can depend on context as well. Graham87 (talk) 13:04, 16 December 2020 (UTC)
• To echo want Graham87 says, alt text will often depend on context. When images are used in Wikipedia articles, they are intended to convey information relevant to the article; and it is the pieces of that information visible to a sighted reader (but not to a screen reader) that need to be conveyed by alt text. If we use the image File:Washington and Lafayette at Valley Forge.jpg in an article about Valley Forge, we probably intend to convey the winter conditions depicted, but the colour of the brown horse is immaterial, so the alt text describes the conditions and not the horse. If we use the image in an article about George Washington's horses, we will probably take the opposite course.
I'm sorry, but I don't see how a central repository like Commons can anticipate every possible use of their images and be able to usefully suggest alt text for them. Writing good alt text is very often a bespoke job for editors at individual articles, not an automated process. --RexxS (talk) 21:26, 16 December 2020 (UTC)
When I reformulated the proposal, I wrote: if the current transclusion does not provide an alt= parameter.
If an individual text is provided with transclusion, that one will take precedence.
If not and it happens that a text is available in a fallback language, the one from local or commons image description page is offered in current page.
Looking at 100,000,000 images when the proposal has been implemented and perhaps 10,000 local alt as starting point (those might be collected and made available for all pages on all wikis) we are at 0,01 % of the images with one single language. The issue of context dependant description is probably the least problem.
Greetings --PerfektesChaos (talk) 14:35, 18 December 2020 (UTC)
• Please excuse me if this is a stupid question, but can you tell me, how many images do already have alt-texts? Or how many percent? --KH32 (talk) 12:02, 18 December 2020 (UTC)
This is no stupid question at all.
German Wikipedia has 2,500,000 articles, 500,000 with at least one image transclusion, about 4,000 with at least one non-empty alt parameter, most of them insufficient since stupidly repeating legend but no visual description; perhaps 1,000 or 2,000 meaningful alternate texts. IIRC enWP and others have no better ratio.
One of the ideas is to collect all existing alternate texts by gadget, check them manually whether they are a visual description and not confusing, and populate the linked media description page (local or commons) with that entry for that language. Then they are available on all other pages and wikis where the same image is transcluded. Further descriptions and languages may be added later.
Commons has 66,988,373 media files right now.
Greetings --PerfektesChaos (talk) 14:35, 18 December 2020 (UTC)
• Thank you very much. And on the other hand most most most images in articles get a caption there that is delivering context. So what would we loose if we would introduce alt-texts that mostly deliver a short image description, a translation of the visual content for blind users? The context would still be added article by article in the captions. This way we would avoid duplication and would allow automatic translation. --KH32 (talk) 12:00, 19 December 2020 (UTC)
• PS I'm just about to expand the article on alt-texts in the German Wikipedia. Maybe someone here is on the same track? Maybe we could join forces then. In any case I would be happy for your response:-) --KH32 (talk) 12:08, 19 December 2020 (UTC)

### Voting

•   Support Strong support! This is a essential step to make Wikimedia following Web Content Accessibility Guidelines. GeorgHH (talk) 19:38, 8 December 2020 (UTC)
•   Support That feature would greatly help people who are blind. MarioSuperstar77 (talk) 20:40, 8 December 2020 (UTC)
•   Support Strong support, alt-text is absolutely vital for visually impaired users. ASpacemanFalls (talk) 21:08, 8 December 2020 (UTC)
•   Support Why not. YFdyh000 (talk) 23:05, 8 December 2020 (UTC)
•   SupportThe Editor's Apprentice (talk) 23:12, 8 December 2020 (UTC)
•   Support Martinkunev (talk) 23:39, 8 December 2020 (UTC)
•   Support Hanif Al Husaini (talk) 02:01, 9 December 2020 (UTC)
•   Support AnotherOnymous (talk) 03:20, 9 December 2020 (UTC)
•   SupportAmmarpad (talk) 04:27, 9 December 2020 (UTC)
•   Support --Ita140188 (talk) 04:52, 9 December 2020 (UTC)
•   Support TrudiJ (talk) 09:44, 9 December 2020 (UTC)
•   Support Thomas Kinz (talk) 11:40, 9 December 2020 (UTC)
•   Support 𝑷𝒂𝒛 𝒆 𝒄𝒐𝒏𝒄𝒐́𝒓𝒅𝒊𝒂 What's up? 12:39, 9 December 2020 (UTC)
•   Strong support. --Wikinade (talk) 13:40, 9 December 2020 (UTC)
•   Support Browk2512 (talk) 18:00, 9 December 2020 (UTC)
•   Supportputnik 19:17, 9 December 2020 (UTC)
•   Support P.Marlow (talk) 01:29, 10 December 2020 (UTC)
•   Support SunDawn (talk) 04:12, 10 December 2020 (UTC)
•   Support JPxG (talk) 06:05, 10 December 2020 (UTC)
•   Support. Meiræ 15:28, 10 December 2020 (UTC)
•   Support --Mathieugp (talk) 18:08, 11 December 2020 (UTC)
•   Support Susanna Giaccai (talk) 18:18, 11 December 2020 (UTC)
•   Support But just use the existing description, no extra field. Wutsje (talk) 19:59, 11 December 2020 (UTC)
•   Support  Michael Z. 2020-12-11 23:06 z 23:06, 11 December 2020 (UTC)
•   Comment if done by community committee I strongly support. If mandated for uploading I strongly oppose. Few people have the actual understanding to add alt text to imagesLostinlodos (talk)|
•   Support Tom Ja (talk) 10:14, 12 December 2020 (UTC)
•   Support --Jensbest (talk) 16:29, 12 December 2020 (UTC)
•   Support Fuchs B (talk) 18:05, 12 December 2020 (UTC)
•   Strong oppose As per the discussion. --Martina Nolte (talk) 19:13, 12 December 2020 (UTC)
•   Support Nehaoua (talk) 20:18, 12 December 2020 (UTC)
•   Support Tgr (talk) 03:13, 13 December 2020 (UTC)
•   Support Sargoth (talk) 07:52, 13 December 2020 (UTC)
•   Support TeKaBe (talk) 14:33, 13 December 2020 (UTC)
•   Supportviciarg414 19:41, 13 December 2020 (UTC)
•   Support - It's bad that the community not only has to beg for something like this, but that it has to compete with other important things as well. A poor certificate for the site operator. - Marcus Cyron (talk) 18:14, 14 December 2020 (UTC)
•   Support, including what Ita140188 said about informative instructions. Most people can't tell the difference between alt and caption and tend to put the same content in both, when they use both at all.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:46, 15 December 2020 (UTC)
•   Support β16 - (talk) 09:46, 15 December 2020 (UTC)
•   Support Even though editors can add alt-texts when writing articles, they can be made universal by integrating them into structured data. WindowPain (talk) 02:45, 16 December 2020 (UTC)
•   Support H78c67c (talk) 06:04, 16 December 2020 (UTC)
•   Support B20180 (talk) 09:50, 16 December 2020 (UTC)
•   Support Strong Support. For diversity and inclusivity. - Filipinayzd (talk) 09:59, 16 December 2020 (UTC)
•   Strong support- Rajeeb (talk) 10:18, 16 December 2020 (UTC)
•   Strong supportCheckingfax (talk) 11:28, 16 December 2020 (UTC)
•   Support Vikrantkorde (talk) 12:08, 16 December 2020 (UTC)
•   Support IASturgeon42 (talk) 15:36, 16 December 2020 (UTC)
• I'm sorry, but although the problem is very real, the proposed solution won't work. The real solution is to educate editors how to write good alt text. --RexxS (talk) 21:30, 16 December 2020 (UTC)
•   Support Kku (talk) 07:09, 17 December 2020 (UTC)
•   Support I understand the concerns of the opposite votes. However, accessibility is crucial and very urgent in our community and it needs to be addressed and to start somehow -- even if it is not yet in the 100% best way. GiFontenelle (talk) 17:30, 17 December 2020 (UTC)
•   Support Toter Alter Mann (talk) 21:13, 17 December 2020 (UTC)
•   Support Kunokuno (talk) 09:20, 18 December 2020 (UTC)
•   Support Xhs 唯心而为 10:21, 18 December 2020 (UTC)
•   Support Though it will be a problem if this implemented globally Astronommica (talk) 08:34, 19 December 2020 (UTC)
•   Support KH32 (talk) 12:02, 19 December 2020 (UTC)
•   Support Yamen (talk) 15:46, 21 December 2020 (UTC)

• Problem: The content of any page of Wikivoyage is constantly increasing. Although we have the Pagebanner directory function, when the page moves down, Pagebanner will not follow it. So I think we can add the Back to Top function to the lower right corner of the page, which is convenient After clicking, return to the top Pagebanner block.
• Who would benefit: Reader and editor
• Proposed solution:Add a function for Back to Top or Pagebanner can move down with the page in Wikivoyage desktop version
• More comments: This feature will help readers find the Pagebanner directory they want to query faster.
• Phabricator tickets:
• Proposer: ✈IGOR 〒 Tell Me What?! ． Wikivoyager 16:27, 20 November 2020 (UTC)

### Discussion

• I wouldn't mind seeing the menu bar remain in place when scrolling down the page. Don't know if we need the whole banner. However, I don't see the point to a "back to top" link; Ctrl+Home works just fine. LtPowers (talk) 21:09, 20 November 2020 (UTC)
• I like the idea of the menu bar and tabs staying in place when scrolling down a page. Acabashi (talk) 18:45, 8 December 2020 (UTC)
• Not all Wikivoyage versions use pagebanners. But a sticky TOC at the top could be useful, but could be implemented with some CSS/JS locally on the wiki. 19:51, 8 December 2020 (UTC)

### Voting

•   Support However, I believe it is possible to replicate something like that by using templates. MarioSuperstar77 (talk) 20:24, 8 December 2020 (UTC)
•   Oppose The Home button on keyboards already does this. No button is necessary on the screen. Martinkunev (talk) 23:44, 8 December 2020 (UTC)
•   Comment Phones don't have a home button. MarioSuperstar77 (talk) 10:43, 9 December 2020 (UTC)
•   Comment This suggestion is about the desktop version. The desktop version is by definition something not designed to work on phones. Martinkunev (talk) 11:32, 9 December 2020 (UTC
•   Support Omda4wady (talk) 07:35, 9 December 2020 (UTC)
•   Support sticky banner menu --Andyrom75 (talk) 19:40, 11 December 2020 (UTC)
•   Support Jstalins (talk) 04:28, 16 December 2020 (UTC)
•   Support S8321414 (talk) 14:36, 21 December 2020 (UTC)

## Bookmarking

• Problem: There are no bookmarking if reader is on break or sleep.
• Who would benefit: Everyone
• Proposed solution: To resume reading if reader takes break.
• Phabricator tickets:
• Proposer: Farpen (talk) 05:32, 17 November 2020 (UTC)

### Discussion

• If you need to save an article, you can press the star button and it is added to your watchlist, if you want to save the section of the article you are reading, you can click that section on the content table and save it as a browser bookmark.WikiAviator (talk) 13:56, 17 November 2020 (UTC)
• A list of "Saved pages" could be really useful, if readers were informed of the feature. Browser bookmarks can be hard to navigate through, and have limited scalability; Watchlists serve a different purpose. — Bilorv (talk) 20:02, 17 November 2020 (UTC)
• I’d really welcome such a feature. In contrast to client-side, most browser’s bookmarks functionality our implementation could (and should) take account of collections, i.e. books on Wikibooks. I usually only have one bookmark in physical/paper books. Setting a new bookmark should override the last bookmark in the same collection/Wikibook. (I mean, in addition to that, sometimes I mark individual pages by putting sticky notes on them, but those aren’t really bookmarks, rather mere labels.) Kays (talk) 23:09, 20 November 2020 (UTC)
• fwiw, this is a feature in the native smartphone app, so sounds like a matter of bringing it to desktop/browser. This said, I agree with the comments above—browsers already have ample built-in and extension-based methods for saving links across the Internet and there is little benefit in competing with that unless there is something about bookmarking behavior specific to browsing Wikimedia properties. czar 05:31, 23 November 2020 (UTC)
• Problem: It's hard to keep track of what you want to read. Sometimes you're in the middle of an article, and see a link to an interesting page, but forget about it because there's no easy way to save it.
• Who would benefit: Everyone who does a lot of in-depth research on WikiPedia!
• Proposed solution: Implement a library of reading lists, similar to the one present on the mobile versions of WikiPedia
• Proposer: Raven rs (talk) 01:12, 18 November 2020 (UTC)

### Discussion

In My Library you make your categories and save articles to the section. Favorites are star marked and head each category or overview page.

Ldorigo95 (talk) 09:52, 18 November 2020 (UTC) I added some details on this submissions as I would also like it to see the day. The functionality is already present on mobile, I feel like it's really missing on the online version.

• I appreciate that this proposal suggests the user's Reading List should sync across all devices (mobile and web browsers). - ZuluKane (talk) 17:46, 24 November 2020 (UTC)

— The preceding unsigned comment was added by Raven rs (talk) 08:38, 25 November 2020 (UTC)

### Voting

•   Strong support I have basically used the watchlist button to bookmark articles, something more standard should be created for readers. MarioSuperstar77 (talk) 20:28, 8 December 2020 (UTC)
•   Support It's Been Emotional (talk) 20:31, 8 December 2020 (UTC)
•   Support I feel a book mark system separate from inbuilt browser book marks would be very useful for readers All hail Armok (talk) 23:20, 8 December 2020 (UTC)
•   Strong support The watchlist is way too clunky to be used as a bookmarking techniuque. A new feature must be added. Mihir Narayanan (talk) 23:31, 8 December 2020 (UTC)
•   Oppose This functionality is already available in practically every browser. If someone is unhappy with how their browser's bookmarks function, this is a browser problem (also it could be solved with a browser add-on). Martinkunev (talk) 23:34, 8 December 2020 (UTC)
•   Comment I have already a lot of bookmarks on my browser which are all cluttered, I use them to remember web pages that I find informative and there are a lot of them. If Wikipedia adds a bookmark feature that is distinct from the watchlist, I and many other users will be very happy, particularly since, like I said, my browser's bookmarks are cluttered enough already. MarioSuperstar77 (talk) 10:48, 9 December 2020 (UTC)
Comment If your bookmarks are cluttered, I would suggest organizing them. Adding a second place to store bookmarks doesn't actually solve the problem you're describing. It just provides you with another place that will eventually get cluttered as well. Martinkunev (talk) 14:29, 9 December 2020 (UTC)
•   Support I encourage anyone borderline on supporting this to do so, because this would primarily be a feature for the readers who aren't editors, but they won't get a voice in this conversation. — Bilorv (talk) 01:42, 9 December 2020 (UTC)
•   Support Hanif Al Husaini (talk) 02:04, 9 December 2020 (UTC)
•   Support Yeenosaurus (talk) 03:33, 9 December 2020 (UTC)
•   Support TSK201911 (talk) 04:04, 9 December 2020 (UTC)
•   Support Omda4wady (talk) 07:38, 9 December 2020 (UTC)
•   Support Browk2512 (talk) 17:52, 9 December 2020 (UTC)
•   Support dwf² (talk) 23:06, 9 December 2020 (UTC)
•   Support JPxG (talk) 06:07, 10 December 2020 (UTC)
•   Support. Meiræ 15:26, 10 December 2020 (UTC)
•   Support Strong support. It makes easier to return to Wikipedia and sister projects. BoldLuis (talk) 18:11, 11 December 2020 (UTC)
•   Support Rdyornot (talk) 22:35, 12 December 2020 (UTC)
•   Support HAL333 (talk) 21:14, 13 December 2020 (UTC)
•   Support Kays (talk) 16:39, 14 December 2020 (UTC)
•   Oppose Totally redundant with both built-in browser functionality, and user-space list making.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:54, 15 December 2020 (UTC)
•   Support OPlibertad (talk) 17:06, 15 December 2020 (UTC)
•   Support SeGiba (talk) 18:09, 15 December 2020 (UTC)
•   Support Stephan Hense (talk) 22:55, 16 December 2020 (UTC)
•   Support Xhs 唯心而为 10:17, 18 December 2020 (UTC)
•   Support Uanfala (talk) 00:01, 21 December 2020 (UTC)
•   Supporttyseria 01:53, 21 December 2020 (UTC)

## Increased accessibility

• Problem: Some readers find Wikipedia pages difficult to read due to sight and other reading issues involving colours.
• Who would benefit: Those with sight and reading difficulties.
• Proposed solution: Have an accessibility section on the left-hand side of the page (where Community, Beyond the Web and Tools are located). This would allow readers to quickly and easily change the size of the text in the article, change the font colour from black to a range of other colours and allow the changing of blue links to an alternate colour. You could have Accessibility at the top, then the clickable links underneath: Font size, Font colour, Link colour (and any other accessibility options people wish to add to this). The default font size and colours would still remain as they currently are. If an article has a spoken version this could also be listed in this accessibility section.
• Phabricator tickets:
• Proposer: Helper201 (talk) 22:57, 25 November 2020 (UTC)

### Discussion

In the years 2016-2019 we've replaced the colors in Wikimedia products to comply with Web Content Accessibility Guidelines 2.0/2.1 level AA. Colors are part of a palette defined with these considerations in mind. For a discussion around settings beyond, you're probably looking for something similar to what's described in phab:T91201 – (easily accessible) accessibility settings --Volker E. (WMF) (talk) 20:00, 29 November 2020 (UTC)

### Voting

•   Support Hopefully, that feature gets implemented. MarioSuperstar77 (talk) 20:41, 8 December 2020 (UTC)
•   Oppose Such functionality is already available in browsers. It makes more sense to have centralized configuration of accessibility for the entire browser (or the entire system), not some functionality specific to wikimedia. Martinkunev (talk) 23:48, 8 December 2020 (UTC)
•   Oppose I support accessibility, but the proposer has not explained how browser/operating system support for this is inadequate. Silver hr (talk) 23:55, 8 December 2020 (UTC)
•   Support. Meiræ 15:28, 10 December 2020 (UTC)
•   Support Libcub (talk) 20:20, 10 December 2020 (UTC)
•   Support Goultard59 (talk) 17:29, 11 December 2020 (UTC)
•   Support Fuchs B (talk) 18:13, 12 December 2020 (UTC)
•   Support in spirit, but the proposal is too vague. I do think the mentioned Phabricator ticket should get attention.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:01, 15 December 2020 (UTC)
•   Support DarkGlow (talk) 21:30, 17 December 2020 (UTC)
•   Support S8321414 (talk) 14:36, 21 December 2020 (UTC)

## Automatic switch from mobile view to desktop view for desktops after following a mobile link

• Problem: In my humble opinion, it is most likely that people using PCs when following a link of format https://en.m.wikipedia.org/w/... would probably want to switch back to desktop view to read it, since they used to it. Currently, users have to find the small button of desktop version in the very bottom of the page.
• Who would benefit: I think most of the desktop users following mobile links.
• Proposed solution: Detect the way of browsing and based on that switch to a corresponding view type.
• More comments: Of course there might be people who want to use the mobile version on PC, but this function should be switchable then.
• Phabricator tickets:
• Proposer: Stanislav Kondratev Станислав Кондратьев (talk) 12:59, 20 November 2020 (UTC)

### Discussion

• For me, it's the reverse: I want easy access to the switch to desktop link at the bottom, when viewing a mobile view on a mobile phone. I only ever use Desktop view on a mobile phone. See this proposal. Mathglot (talk) 02:38, 24 November 2020 (UTC)
• This will be appreciated. I use Firefox both on mobile and desktop and Firefox Sync allows me to syncronize bookmarks. This is very helpful in my workflow but I end saving a lot of mobile versions to be later edited on desktop. When I start a session in my desktop, I have to manually update the links to make it more comfortable to read/edit. However, I see an issue with automatically redirecting to the desktop version. Since the url are different, the browser does treat changes as redirect and does not recognize the page as bookmarked (since the bookmark url is different). That means that once I'm finished I'd need to manually go to my bookmark list to remove the bookmark from my to do list. --FAR (talk) 09:49, 29 November 2020 (UTC)

### Voting

•   Support Martin m159 (talk) 19:13, 8 December 2020 (UTC)
•   Support Trang Oul (talk) 20:07, 8 December 2020 (UTC)
•   Support MarioSuperstar77 (talk) 20:25, 8 December 2020 (UTC)
•   Support Зефр (talk) 20:49, 8 December 2020 (UTC)
•   Support Ponor (talk) 22:20, 8 December 2020 (UTC)
•   Support Redactedentity (talk) 23:40, 8 December 2020 (UTC)
•   Support Martinkunev (talk) 23:46, 8 December 2020 (UTC)
•   Support Abductive (talk) 23:56, 8 December 2020 (UTC)
•   Support Hanif Al Husaini (talk) 02:00, 9 December 2020 (UTC)
•   Support * Pppery * it has begun 02:09, 9 December 2020 (UTC)
•   Support Keepcalmandchill (talk) 02:20, 9 December 2020 (UTC)
•   Support NMaia (talk) 03:17, 9 December 2020 (UTC)
•   Support Yeenosaurus (talk) 03:32, 9 December 2020 (UTC)
•   Support —— Eric Liu留言百科用戶頁 04:42, 9 December 2020 (UTC)
•   Support SunDawn (talk) 05:02, 9 December 2020 (UTC)
•   Support Cherryblossom000 (talk) 07:18, 9 December 2020 (UTC)
•   Support Omda4wady (talk) 07:33, 9 December 2020 (UTC)
•   Support 𝑷𝒂𝒛 𝒆 𝒄𝒐𝒏𝒄𝒐́𝒓𝒅𝒊𝒂 What's up? 12:38, 9 December 2020 (UTC)
•   Support MilkyDefer (talk) 12:51, 9 December 2020 (UTC)
•   Support Mannivu · 15:17, 9 December 2020 (UTC)
•   Support Baltakatei (talk) 17:01, 9 December 2020 (UTC)
•   Support TheImaCow (talk) 17:12, 9 December 2020 (UTC)
•   Support Browk2512 (talk) 17:50, 9 December 2020 (UTC)
•   Support Netjeff (talk) 19:15, 9 December 2020 (UTC)
•   Weak support it would have to be for larger tablets too. I'm not so keen on it being automatic, because I don't always feel like going right from a mobile view to a desktop view. Sometimes a mobile view makes it easier to stay organized visually when you are on a desktop. I don't see a problem with making it the kind of settings option which can be toggled, though. Tyrekecorrea (talk) 19:31, 9 December 2020 (UTC)
•   Support JAn Dudík (talk) 20:14, 9 December 2020 (UTC)
•   Support Supernonodunet (talk) 07:44, 10 December 2020 (UTC)
•   Support Titore (talk) 23:48, 10 December 2020 (UTC)
•   Support but with an easy choice maybe with a button Cryout (talk) 10:07, 11 December 2020 (UTC)
•   Support OosWesThoesBes (talk) 17:28, 11 December 2020 (UTC)
•   Support J. N. Squire (talk) 21:09, 11 December 2020 (UTC)
•   Oppose it being automatic. Sometimes on the helpdesk we get questions that are specific to the mobile view, and I want to see the page as the person who posted the question saw it. I wouldn't mind, however, a pop-up of some sort that says, "It looks like you are using a desktop. Would you like to switch to the desktop view?" ONUnicorn (talk) 21:50, 11 December 2020 (UTC)
•   Support Vince789 (talk) 22:22, 11 December 2020 (UTC)
•   Support --Alaa :)..! 01:22, 12 December 2020 (UTC)
•   Oppose per ONUnicorn--Strainu (talk) 10:27, 12 December 2020 (UTC)
•   Support Imetsia (talk) 16:47, 12 December 2020 (UTC)
•   Support SkSlick (talk) 19:28, 12 December 2020 (UTC)
•   Support Michel Bakni (talk) 14:01, 14 December 2020 (UTC)
•   Support Poupou l'quourouce (talk) 14:16, 14 December 2020 (UTC)
•   Support in principle, but desktop mobile views should still be viewable on desktop, and vice versa ·addshore· talk to me! 16:43, 14 December 2020 (UTC)
•   Support Pinage404 (talk) 22:37, 14 December 2020 (UTC)
•   Support, but especially the other way around. As Mathglot says, it's much more often a problem that one needs to get the full desktop version of the page while on a mobile device.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:57, 15 December 2020 (UTC)
•   Support SeGiba (talk) 18:09, 15 December 2020 (UTC)
•   Support -- Llywrch (talk) 07:04, 16 December 2020 (UTC)
•   Support Nelson Ricardo (talk) 11:26, 16 December 2020 (UTC)
•   Support Álvaro056 (talk) 13:50, 16 December 2020 (UTC)
•   Support Lt2818 (talk) 03:32, 17 December 2020 (UTC)
•   Oppose and as per ONUnicorn - I've had to try to debug/investigate mobile oddities and figure out how to demonstrate those to others. As a setting you could default to realign links with current platform, but do not impose unconditionally. Breaking how people fix things is uncool. Shenme (talk) 06:37, 17 December 2020 (UTC)
•   Support Vega (talk) 14:00, 17 December 2020 (UTC)
•   Support Given that mobile detection automatically does the inverse of this, I have been frustrated for years that this does not happen. I have a browser extension that auto redirects, but it would be nice for this to be standard. Brvman (talk) 14:54, 17 December 2020 (UTC)
•   Support GiFontenelle (talk) 17:57, 17 December 2020 (UTC)
•   Support Yes please! Astronommica (talk) 08:37, 19 December 2020 (UTC)
•   Supporttyseria 01:52, 21 December 2020 (UTC)
•   Oppose Each URL should always send identical data, otherwise confusion arise. MobileReader_A:"Hey, this page's wierd" -> PCEditor_B:"What? I see no problem" --Wotheina (talk) 10:08, 21 December 2020 (UTC)
•   Support S8321414 (talk) 14:37, 21 December 2020 (UTC)
•   Support Ladnerg310 (talk) 14:50, 21 December 2020 (UTC)

## Show Wiktionary definitions in Page Previews

čeština: Pohodlné a příruční propojení projektů wiki, zejména wikipedie a wikislovníku

• Problem: the connection between Wiktionary and Wikipedia (which in my opinion should never have been separate) is awkward, and it is necessary to switch and search them separately
čeština: propojení wikislovníku a wikipedie (které podle mého neměly být nikdy oddělené) je nešikovné a je nutné přepínat a hledat samostatně
• Who would benefit: all users, especially those who explore the interpretation in more depth - about the meaning of terms, including synonyms and their origin (etymology)
čeština: všem uživatelům, zejména těm, kteří zkoumají výklad hlouběji - o významu pojmů včetně synonym a jejich původu (etymologie)
• Proposed solution: to expand the speech bubble (Page preview) with the introduction of the Wikipedia article by a link to or even better a similar citation from the Wiktionary and possibly some other wiki projects
čeština: na odkazy rozšířit bublinu s citací úvodu hesla wikipedie o odkaz nebo ještě lépe obdobnou citaci z wikislovníku a možná i nějakých jiných projektů wiki
• Phabricator tickets:
• Proposer: Tosek (talk) 18:52, 17 November 2020 (UTC)

### Discussion

• What about something similar to the dictionary functionality in the Kindle e-reader? If a word is highlighted, a small window opens displaying its definition. You can find examples by searching "kindle dictionary" on Google images. It may be turned on or off as an option. --Ita140188 (talk) 01:15, 4 December 2020 (UTC)
• That functionality is already provided by default by macOS and iOS for several years I think.... right click or hold and "Lookup <word>". —TheDJ (talkcontribs) 13:22, 4 December 2020 (UTC)
• Yes, it could work this way: highlighting by user some (one or more) word(s) should produce bubble or window with introduction from wiktionary and links to other dictionaries. (I don't know macOS and iOS and Kindle.) Tosek (talk) 23:52, 5 January 2021 (UTC)

## Possibility to expand subsections, button to expand all/collapse all

• Problem: Scrolling long articles is a bit difficult. Skipping chapters or subsection is a lot of down scrolling.
• Who would benefit: anyone
• Proposed solution: possibility to collapse not only first level section but any level and button to collapse all/Expand all
• More comments: not sure if that's already being worked at, sorry!
• Phabricator tickets:
• Proposer: Gfombell (talk) 05:47, 17 November 2020 (UTC)

### Discussion

• Are you proposing this for mobile, sektop or both?-- 08:49, 17 November 2020 (UTC)
I read this as being for mobile, not for desktop. Anyone using desktop already has access to standard browser functions and the table of contents. --Izno (talk) 05:03, 18 November 2020 (UTC)
Mobile already has this, doesn't it?--Strainu (talk) 09:30, 19 November 2020 (UTC)
• If the proposal refers to desktop, enwp has User:BethNaught/hideSectionDesktop.js. Certes (talk) 01:46, 23 November 2020 (UTC)

### Voting

•   Oppose just because this is aleready implemented on the mobile version-- 18:31, 8 December 2020 (UTC)
•   Support --NGC 54 (talk / contribs) 20:24, 8 December 2020 (UTC)
•   Oppose This feature is pointless if it already exists and is not an issue for computers which have it missing. MarioSuperstar77 (talk) 20:33, 8 December 2020 (UTC)
•   Support always good to improve usability Leftowiki (talk) 00:40, 9 December 2020 (UTC)
•   Oppose. -BALA. RTalk 01:25, 9 December 2020 (UTC)
•   Support The existing mobile web only collapses the == Level 2 heading ==. This proposal is for any level of sections. Hanif Al Husaini (talk) 01:58, 9 December 2020 (UTC)
•   Support Omda4wady (talk) 07:38, 9 December 2020 (UTC)
•   Support P.Marlow (talk) 01:28, 10 December 2020 (UTC)
•   Support JPxG (talk) 06:06, 10 December 2020 (UTC)
•   Support Supernonodunet (talk) 07:44, 10 December 2020 (UTC)
•   Support BoldLuis (talk) 18:10, 11 December 2020 (UTC)
•   Oppose with alternative. Allowing it as an option. Lostinlodos (talk) 23:52, 11 December 2020 (UTC)
•   Support Rdyornot (talk) 22:34, 12 December 2020 (UTC)
•   Support Pinage404 (talk) 22:37, 14 December 2020 (UTC)
•   Support SeGiba (talk) 18:07, 15 December 2020 (UTC)

## Enable sticky table headers

• Problem: In tables with many lines, the header scrolls out of the reader's view and is no further visible for him. That could cause confusion of column contents (for example for tables with numeric data).
• Who would benefit: everyone reading articles with large tables
• Proposed solution: implement the position:sticky attribute for table headers natively in MediaWiki through a class, e.g. mw-stickyhead.
• More comments: This can be realized through templatestyles (example) but interferes the native wikitable styling which requires extra workarounds.
• Phabricator tickets: phab:T42763
• Proposer: hgzh 13:52, 18 November 2020 (UTC)

### Discussion

• I use mediawiki software for documentation outside of the wikimedia environment. We have a lot of tables and this would be very useful Tenbergen (talk) 01:32, 19 November 2020 (UTC)
• Yes yes yes, this would be fantastic to have. And it's a good example of a wishlist item that puts the reader first, benefiting the multitudes of non-editing readers, rather than just prioritizing ourselves. {{u|Sdkb}}talk 03:07, 19 November 2020 (UTC)
• Per the phab ticket, there is a live gadget for this under Preferences > Gadgets > Testing and development, if useful (not watching, please {{ping}}) czar 01:34, 22 November 2020 (UTC)
• Yes please! I often find a faulty item on row 1234 of a huge table and have to scroll up for miles to find out what the column should contain. I just installed the gadget, which is just what I needed but hard to discover. Certes (talk) 01:36, 23 November 2020 (UTC)
• To see examples: There are 3 scrolling tables with sticky headers in the statistics section of w:COVID-19 pandemic by country and territory. Some of that CSS, etc. can be used. --Timeshifter (talk) 20:42, 27 November 2020 (UTC)
• See: w:Help talk:Table/Archive 8#Sticky table headers?. There is a collapsed example table added today that is very good. Scroll down in the discussion to see it. The table is sticky both vertically and horizontally. Narrow your browser window to see. --Timeshifter (talk) 21:07, 7 December 2020 (UTC)

### Voting

•   Support Seems convenient. MarioSuperstar77 (talk) 20:30, 8 December 2020 (UTC)
•   Support The gadget suffices for me but this change will help those who have not discovered it. Certes (talk) 21:18, 8 December 2020 (UTC)
•   SupportThe Editor's Apprentice (talk) 23:15, 8 December 2020 (UTC)
•   Support Martinkunev (talk) 23:42, 8 December 2020 (UTC)
•   Support Silver hr (talk) 23:50, 8 December 2020 (UTC)
•   SupportAmmarpad (talk) 04:29, 9 December 2020 (UTC)
•   Support --Ita140188 (talk) 04:53, 9 December 2020 (UTC)
•   Support Åntøinæ (talk) 08:56, 9 December 2020 (UTC)
•   Support Matěj Suchánek (talk) 09:08, 9 December 2020 (UTC)
•   Support {{u|Sdkb}}talk 10:15, 9 December 2020 (UTC)
•   Support Thomas Kinz (talk) 11:39, 9 December 2020 (UTC)
•   Support Ulanwp (talk) 12:41, 9 December 2020 (UTC)
•   Support MilkyDefer (talk) 12:53, 9 December 2020 (UTC)
•   Support --Satirdan kahraman (talk) 18:26, 9 December 2020 (UTC)
•   Support JAn Dudík (talk) 20:15, 9 December 2020 (UTC)
•   Support Supernonodunet (talk) 07:45, 10 December 2020 (UTC)
•   Support --Timeshifter (talk) 07:46, 10 December 2020 (UTC)
•   Support - yona B. (D) 08:11, 10 December 2020 (UTC)
•   Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:38, 10 December 2020 (UTC)
•   Support Can I keep hitting support all day? That might get close to how much I think this would be useful & reader-friendly. Cabayi (talk) 12:59, 10 December 2020 (UTC)
•   Support. Meiræ 15:27, 10 December 2020 (UTC)
•   Support Tim bates (talk) 15:49, 10 December 2020 (UTC)
•   Support Libcub (talk) 20:19, 10 December 2020 (UTC)
•   Support Srđan (talk) 22:35, 10 December 2020 (UTC)
•   Support Titore (talk) 23:53, 10 December 2020 (UTC)
•   Support Jc86035 (talk) 12:01, 11 December 2020 (UTC)
•   Support MichaelSchoenitzer (talk) 14:15, 11 December 2020 (UTC)
•   Support czar 16:22, 11 December 2020 (UTC)
•   Support James Martindale (talk) 17:24, 11 December 2020 (UTC)
•   Support Goultard59 (talk) 17:30, 11 December 2020 (UTC)
•   Support Akela NDE (talk) 17:53, 11 December 2020 (UTC)
•   Support --Mathieugp (talk) 18:07, 11 December 2020 (UTC)
•   Support same concept could be use for Wikivoayge banner menu --Andyrom75 (talk) 19:34, 11 December 2020 (UTC)
•   Support J. N. Squire (talk) 21:07, 11 December 2020 (UTC)
•   Support Vince789 (talk) 22:20, 11 December 2020 (UTC)
•   Support  Michael Z. 2020-12-11 23:04 z 23:04, 11 December 2020 (UTC)
•   Support Tom Ja (talk) 10:12, 12 December 2020 (UTC)
•   Support TheLatentOne (talk) 19:48, 12 December 2020 (UTC)
•   Support Trizek from FR 20:57, 12 December 2020 (UTC)
•   Support Rdyornot (talk) 22:35, 12 December 2020 (UTC)
•   Support 23:50, 12 December 2020 (UTC)
•   Support   ฅ • ω • ฅ 03:48, 13 December 2020 (UTC)
•   Support -- the wub "?!" 18:35, 13 December 2020 (UTC)
•   Support Pinage404 (talk) 22:37, 14 December 2020 (UTC)
•   Support in theory, but this will require significant accessibility research.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:59, 15 December 2020 (UTC)
•   Support — Draceane talkcontrib. 13:36, 15 December 2020 (UTC)
•   Support Thanks, EDG 543 (message me) 15:48, 15 December 2020 (UTC)
•   Support Lasse Ramson (talk) 20:42, 15 December 2020 (UTC)
•   SupportTeratix 06:42, 16 December 2020 (UTC)
•   Support Crissov (talk) 09:07, 16 December 2020 (UTC)
•   Support Femkemilene (talk) 12:01, 16 December 2020 (UTC)
•   Support Vikrantkorde (talk) 12:07, 16 December 2020 (UTC)
•   Support Wolfmartyn (talk) 14:00, 16 December 2020 (UTC)
•   Support IronSprings (talk) 02:01, 17 December 2020 (UTC)
•   Support Lt2818 (talk) 03:20, 17 December 2020 (UTC)
•   Support Jdpipe (talk) 05:43, 17 December 2020 (UTC)
•   Support Shenme (talk) 06:40, 17 December 2020 (UTC)
•   Support Yes!!!!! Risk Engineer (talk) 15:48, 17 December 2020 (UTC)
•   Support Shinkolobwe (talk) 16:53, 17 December 2020 (UTC)
•   Support LM150 (talk) 22:35, 19 December 2020 (UTC)
•   Support Kaartic [talk] 17:36, 20 December 2020 (UTC)
•   Support Uanfala (talk) 00:03, 21 December 2020 (UTC)
•   Support and don't forget to enable fixed columns as well, not only rows. Both for mobile view too. Wotheina (talk) 09:37, 21 December 2020 (UTC)
•   Support as proposer -- hgzh 10:57, 21 December 2020 (UTC)
•   Support2d37 (talk) 11:00, 21 December 2020 (UTC)
•   Support S8321414 (talk) 14:36, 21 December 2020 (UTC)

## Add Preference setting to offer Desktop view as default for mobile

• Problem: switching to Desktop view on mobile every time is annoying; plus, the link is at the bottom.
• Who would benefit: everyone who often, or always (my case) uses Desktop view on mobile
• Proposed solution: 1st choice: a Preference setting allowing me to select my default view while on mobile. 2nd: just remember my last mobile view, and use that (cookie). Optimal: 3-way radio button: Default view on mobile: 🔘 mobile view ⭕ desktop view ⭕ same as previous view
• More comments: Inspired by Stanislav's proposal above.
• Phabricator tickets: phab:T173527
• Proposer: Mathglot (talk) 02:56, 24 November 2020 (UTC)

### Discussion

• @Mathglot: After you click 'Desktop' in the mobile footer and go to the desktop view, you should be able to follow any links and it'll stay in the desktop view (even with 'open in new tab' etc.). Is that much working for you? Is it when you open a link from e.g. an email that you're having to manually switch views? i.e. when you've ended up at the en.m.wikipedia.org domain? —Sam Wilson 03:23, 1 December 2020 (UTC)
, thank you for your questions. Yes, following links is not a problem. The problem can be either a Wikipedia link on a website (or email, or note on the phone, etc.) Sometimes, even when I'm already in desktop view, it flips back into mobile when other tabs are involved; I'll have to observe more carefully next time it happens to make sure I'm reporting it correctly, but I believe it's something like when I touch-hold to get a context menu (right-click equivalent) and then choose 'open in new tab' or similar. Let's call that "hearsay" for the time being, until I observe it and get a more accurate report. If you have specific use-cases or scenarios, definitely list them, and I will check them out and report back. Also, I switch between sister projects including foreign wikipedias, either via typed search such as fr:# if I just want to change languages, or an article, if I want to go somewhere specific, and I *think* it might be happening sometimes then, also, but I need to make sure. Mathglot (talk) 03:58, 1 December 2020 (UTC)
@Mathglot: hmm interesting, well if you do figure out specifics let us know. I've been experimenting and things like 'open in new tab' and even opening a blank new tab and typing in the URL work fine. Could be vagaries with different browsers and things though. —Sam Wilson 04:17, 1 December 2020 (UTC)

### Voting

•   Weak support Why not? MarioSuperstar77 (talk) 20:25, 8 December 2020 (UTC)
•   Support Assuming Mathglot's hearsay is correct, this seems like a worthy cause. —The Editor's Apprentice (talk) 22:42, 8 December 2020 (UTC)
•   Weak support Agree with MarioSuperstar77 Redactedentity (talk) 23:34, 8 December 2020 (UTC)
•   Support * Pppery * it has begun 02:09, 9 December 2020 (UTC)
•   Oppose Omda4wady (talk) 07:37, 9 December 2020 (UTC)
•   Strong support. Thanks for this proposal. The "always desktop" choice existed a few years ago, bring it back please! --Wikinade (talk) 13:31, 9 December 2020 (UTC)
•   Support TohaomgTohaomg (talk) 10:03, 10 December 2020 (UTC)
•   Support. Meiræ 15:27, 10 December 2020 (UTC)
•   Comment: The problem is that the desktop view has the font sizes all wrong. On my phone, the page text is reasonably small, but the left and top bars are incredibly small. That must be fixed first. --NaBUru38 (talk) 21:03, 10 December 2020 (UTC)
That will be fixed over time as more skins support responsive design. Vector soon, and Timeless and Minerva already. --Izno (talk) 15:23, 11 December 2020 (UTC)
Monobook skin is very great for mobile. Enjoyer of World (talk) 10:11, 21 December 2020 (UTC)
•   Support Izno (talk) 15:24, 11 December 2020 (UTC)
•   Support BoldLuis (talk) 18:09, 11 December 2020 (UTC)
•   Support ONUnicorn (talk) 21:48, 11 December 2020 (UTC)
•   Support I hate the mobile version of the site, and would certainly have no use for it on a larger mobile device like a tablet. But I don't even like it on my phone.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:03, 15 December 2020 (UTC)
•   Support H78c67c (talk) 06:02, 16 December 2020 (UTC)
•   Support Sashatrk (talk) 10:12, 16 December 2020 (UTC)
•   Support Álvaro056 (talk) 13:51, 16 December 2020 (UTC)
•   Support Absolutely, without doubt! Adam78 (talk) 10:48, 17 December 2020 (UTC)
•   Support2d37 (talk) 10:58, 21 December 2020 (UTC)
•   Support S8321414 (talk) 14:37, 21 December 2020 (UTC)

• Problem: We've all been there. We look up a term in Wikipedia only to be enticed by another term and another term until we have spent three fascinating, caffeine-filled hours discovering things we knew, things we didn't know, and things we probably should have left alone. At this point, we may have forgotten why we even came to Wikipedia in the first place. Or perhaps we wanted to follow up on the seventh son of the third king from that weird country in a link an hour back.
• Who would benefit: (A lot of) people that does that
• Proposed solution: Wouldn't it be nice to be able to click a link at the top of the page which would expand a Link Tree showing how you got to where you were and the links past you may want to visit again?
• Phabricator tickets:
• Proposer: Spiel 02:53, 17 November 2020 (UTC)

### Discussion

• Wouldn't browser history be adequate enough to solve this problem of ours? James Goner (talk) 06:12, 17 November 2020 (UTC)
• I don't think so. The browser history contains links from other sources and is very cluttered (from my own experience). שוקו מוקה (talk) 09:34, 17 November 2020 (UTC)
• I think this would work best as a simple history of visited pages. Keepcalmandchill (talk) 11:07, 17 November 2020 (UTC)
Which would be a serious privacy problem. Browser history, on your own machine, exists for a reason and there are many tools for managing it.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:48, 15 December 2020 (UTC)
• This can be achieved by using a browser extension that structures tabs into trees, and opening links in new tabs. See Tree Style Tab for Firefox. Silver hr (talk) 11:47, 17 November 2020 (UTC)
Yes, I saw this one just the other day. It seems like exactly what the user is looking for. --Izno (talk) 18:46, 17 November 2020 (UTC)
Must say it is technically possible. It is quite easy through something like ?from=China+Hong%20%Kong+1997%20%Handover, something like that. There's no limit really on the length of the articles, and surely can be done through some easy site engineering.--1233 T / C 18:21, 19 November 2020 (UTC)
• Even though browser history keeps being mentioned as being good enough, being able to see a path form at the top of your browsing page or something like that would be pretty cool! Then again, some people often just open a new tab/window to keep their original page so any link tree of some kind might have to be able to work with that too.

### Voting

•   Support MarioSuperstar77 (talk) 21:43, 8 December 2020 (UTC)
•   Strong support I have wanted this for a long time. --Redactedentity (talk) 23:40, 8 December 2020 (UTC)
•   Support PianistHere (talk) 01:57, 9 December 2020 (UTC)
•   Support OrCer (talk) 11:02, 9 December 2020 (UTC)
•   Oppose it seems nice enough at first, but with so many articles linking to so many other pages in so many categories, things could get messy, and we'd be looking at a link rainforest. It ultimately wouldn't help, because we'd end up spending all day looking at the rainforest and not the trees. Tyrekecorrea (talk) 19:27, 9 December 2020 (UTC)
•   Support P.Marlow (talk) 01:31, 10 December 2020 (UTC)
•   Support Alexcalamaro (talk) 05:52, 11 December 2020 (UTC)
•   Support AEbrahimiB (talk) 11:28, 11 December 2020 (UTC)
•   Support BoldLuis (talk) 18:05, 11 December 2020 (UTC)
•   Support Susanna Giaccai (talk) 18:17, 11 December 2020 (UTC)
•   Support Rdyornot (talk) 22:34, 12 December 2020 (UTC)
•   Support Pinage404 (talk) 22:38, 14 December 2020 (UTC)
•   Oppose Too many privacy and complexity issues, and redundant with user-controlled browser history.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:49, 15 December 2020 (UTC)
•   Oppose Same as above, plus the "back" button of you browser already does what is requested here. Vega (talk) 14:10, 17 December 2020 (UTC)
•   Support 郑洲扬 (talk) 11:57, 20 December 2020 (UTC)

## Hiding References

• Problem: The list of references can be very long, and distort the expectation of how much article is remaining. Yes, this is a first world problem, I know. But it is also trivially easy to fix ;)
• Who would benefit: Anyone who treats the length of the scroll bar as a ballpark figure of how much there is (left) to read.
• Proposed solution: A user setting "Collapse/Hide resources by default"
• More comments: For PC/desktop users, the sources are mostly visible/to be consulted by hovering over the reference to them, so more often than not you do not need the list at the bottom anyhow.
• Phabricator tickets:
• Proposer: Irresistance (talk) 17:15, 17 November 2020 (UTC)

### Discussion

• I would oppose this. For instance, on Wikipedia I would like more readers to be seeing the references section as an integral part of the article, for further reading and research (rather than treating Wikipedia as an authoritative source). I think the scrollbar will never be more accurate than a ballpark guess (there could be long external links, navboxes, categories; the article could contain a long table containing names which you'll want to skip past etc.) — Bilorv (talk) 19:59, 17 November 2020 (UTC)
• I see this proposal as a way of bridging mobile and desktop versions. Mobile already has collapsing sections, and this proposal is suggesting the same, but for desktop. JMVR1 (talk) 21:13, 17 November 2020 (UTC)
• Mobile's collapsing sections relate to the fact that there is a smaller screen and more limited scrolling capabilities, so ease of navigating between different sections is more important. There are many ways in which I support bridging mobile and desktop versions, but not this one. — Bilorv (talk) 00:32, 18 November 2020 (UTC)
• Web format is much richer than paper format, and unless you're interested in reference list itself, you should never need to open the reference section, and should never scroll down and back up to find that information. A click on an inline citation should open a pop-up window (baloon) with all the information you need. I'd support the proposal. And I am proposing in another category the pop-up references should be further developed. Ponor (talk) 04:54, 18 November 2020 (UTC)
Pop-ups are disabled by default on many web browsers for security reasons, and certainly would be less convenient for me as a reader. — Bilorv (talk) 09:20, 21 November 2020 (UTC)
These are not full windows, just a div element that shows up when citation number is hovered. They're already in place on en.wiki, even for anonymous users, they just don't work properly for all citation styles.
• I'd actually a prefer a way to do this when in the wikitext editor - ref-heavy articles can be really hard to find the actual text because references take up so much space in that position. However, it seems fairly unneeded on an article-reading approach Nosebagbear (talk) 15:27, 18 November 2020 (UTC)
• There are articles that limit the heights of the references section and one can limit the height of the section from the individual CSS settings.--Strainu (talk) 09:28, 19 November 2020 (UTC)
• Counterproposal: Move the references list to a separately scrolling panel on the right. Similar to the format used by some academic journals (E.g. journals published by Annual Reviews and Biomed Central). This solves the above problem and actually emphasises WP's strong focus on sources. T.Shafee(Evo﹠Evo)talk 10:01, 20 November 2020 (UTC)
Really like this, when responsive design/screen size permits. Otherwise I wonder which wikis would be in favor of hiding reference by default? If I recall correctly, at least one of the major language wikis does this, I'm but forgetting which. To the original proposal, I hesitate at the thought that we might reinforce for readers that it's okay to not read through to the reliable source. We need that kind of literacy now more than ever. czar 05:28, 23 November 2020 (UTC)
• Being able to set the references as hidden by default does not mean they are not interesting, nor that the reader does not care about them; not all readers use Wikipedia as an academic research aid, and at any rate, you can always not hide them by default ;) This is not some slippery slope towards unsourced/made up content - rather, a simple matter of convenience. I agree references are an integral part of the article. - re counterproposal - that may also be useful in some cases, so instead of having the options "Show References" or "Hide References" you could add a third choice "Show references in sidebar" - the only thing I'd add is that hiding or showing by default is very simple to do and already an existing mechanism, whereas a scroll-along sidebar is not and is considerably more work due to the revival of the browser-wars :( — Irresistance (talk)
not all readers use Wikipedia as an academic research aid - this isn't the only reason to check a reference. If you encounter content that is surprising or counter-intuitive, it is good practice to verify the content in the source given as it could be false. — Bilorv (talk) 09:20, 21 November 2020 (UTC)
Exactly.. and it's as much education (information literacy) as it is to actually provide some sort of reliability trace for user generated content. There are way too many places that DONT quote and source the content they publish. —TheDJ (talkcontribs) 22:37, 25 November 2020 (UTC)
I don't see how this feature conflicts with verifying sources. The sources section will just be collapsed until you click on a reference (as per my understanding). Martinkunev (talk) 14:26, 9 December 2020 (UTC)
• If I want to print article for my children, make pdf or read about place I am currenty, I do not need references. And when I want to s find book about, I can enable them again. Collapsible reference section (before print) should be fine. JAn Dudík (talk) 11:50, 25 November 2020 (UTC)
I have a userscript on English Wikipedia which allows you to customize the printability of certain elements btw, including the presence of references. —TheDJ (talkcontribs) 22:37, 25 November 2020 (UTC)