17 proposals, 56 contributors
The proposal phase has ended.
Come back on December 8 at 18:00 UTC to vote on proposals!

## 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:
• 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)

• Problem: In mobile versions (and desktop versions), if you want to access the table of contents bar, it is quite hard.
• Proposed solution: Implement a TOC quick access button at pages that have Table of Contents. This can be done across mobile and desktop, where if the TOC is inaccessable at page location (at desktop), a button appears, where when clicked, shows the table of contents as a popup box.
• More comments: This have been achieved across various methods that hijack the magic word __TOC__ to be put into a <html> tag. However, this workaround requires user scripts, and is definitely not anything that can be called accessability. This should be considered as an accessability tool.
• Phabricator tickets:
• Proposer: 1233 T / C 10:27, 22 November 2020 (UTC)

## Trouver un affichage plus satisfaisant des formules LaTeX

• Problème: Le système actuel d'affichage et d'export des formules mathématiques laisse grandement à désirer. Les formules sont converties en images où le texte apparaît en noir sur fond transparent, puis insérées dans le fil du texte. Pour cette raison, les formules mathématiques jurent plus ou moins avec le texte environnant :
— sur le site, les formules sont toujours noires, quelle que soit la couleur du texte environnant (voyez cette page, la note) ; de même sur liseuse, où le problème encore plus gênant pour les gens qui utilisent une liseuse avec arrière-plan foncé : les formules sont proprement illisibles ;
— l'alignement du texte mathématique sur la ligne n'est pas parfait, ni sa taille ;
— plus anecdotiquement, la police diffère de la police ambiante.
Cela entraîne par ailleurs des problèmes purement typographiques, notamment le rejet de ponctuation sur la ligne suivante quand la formule se trouve en fin de ligne (cf. le même exemple, au second paragraphe, ou la page suivante, première ligne).

Je souhaiterais donc voir rendues les formules de manière plus cohérente avec le texte ambiant, et de façon surtout à ne plus enfreindre les plus élémentaires règles de la typographie.

• Qui en bénéficierait: Tous les lecteurs de textes scientifiques, et notamment ceux qui les exportent à partir de Wikisource.
• Solution proposée: Pour l'affichage sur site web : des solutions, comme MathJax par exemple ? Pour l'export : on pourrait proposer plusieurs options d'export, l'une qui conserverait l'état actuel, avec conversion en image des formules ; une autre avec export de la syntaxe TeX directement (bien rendue sous Calibre par exemple) ; etc.
• Autres commentaires: Bien noter que la demande ne concerne pas la saisie des mathématiques par les contributeurs, mais leur affichage et leur export.
• Tâches sur Phabricator:
• Proposant: ElioPrrl (talk) 18:25, 23 November 2020 (UTC)

### Discussion

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

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

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

## Increased accessibility

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

## Translation Improvement Needed

• Problem: There are several pages which are untranslated. Sometimes it is needed to use Google Translator which is not so well for readers.
• Who would benefit: Instant readers who have no time to copy-paste for Microsoft Bing Translator.
• Proposed solution: An option is needed to show where readers can choose an option from external translators drop-down box.
• More comments: Bing is better than Google. Translation must be done within sections and/or the article, not to the whole pages.
• Phabricator tickets:
• Proposer: Ssudipta (talk) 19:20, 23 November 2020 (UTC)

## "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)
• 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)

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

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

## Open linked article preview within page

• Problem: Reading an article is made difficult if you need (or want) to read articles in link, for example to understand where the action takes place, etc. You keep opening and closing new tab,s or clicking the "back" arrow of the browser, which by the way seldom bring you back where you were.
• Who would benefit: any one reading
• Proposed solution: give an (optional) possibility to open article preview integrated as insert in the article. How needs to be clarified (right click?)
• Phabricator tickets:
• Proposer: Gfombell (talk) 05:44, 17 November 2020 (UTC)

### Discussion

• Are you describing mw:Page Previews? Logged out users see these by default, and logged in users can enable them, at least on the English Wikipedia, in their Preferences (under Appearances there is a "Reading preferences" section). — Bilorv (talk) 19:52, 17 November 2020 (UTC)
• I think mw:Page Previews could be expanded. For example, you could control how big the popup is, and thus how much content appears. The way I understand this proposal, an insert of the linked page would appear directly in the page. This would be helpful to compare information between two pages, as well as in sections, as you could still scroll. Other ideas include a popup pane that remains open and follows as you scroll, a scrollable insert page, a popup with clickable index, and a side-by-side or multipage view. — Dr.Wiki0 (talk) 13:01, 20 November 2020 (UTC)
• @Gfombell: Does mw:Page Previews do what you want, or would you like to see improvements to this feature? MusikAnimal (WMF) (talk) 21:24, 2 December 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)

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

## Option to Switch between Metric and Imperial Units Site-wide

• Problem: Current implementations of unit measures in Wikipedia are inconsistent at best and confusing at worst.
• Who would benefit: Any users trying to get consistent units for things such as climate data, distance information, etc. One would not see imperial units preferred for articles in the United States or targeted at Americans or metric units preferred for non-American articles.
• Proposed solution: Offering a site-wide option to switch between metric and imperial units in settings or in articles themselves.
• Phabricator tickets:
• Proposer: Benjamin (talk) 14:48, 19 November 2020 (UTC)

### Discussion

I wonder how this would be implemented: currently someone may simply type 'this stuff has a length of 200m' ... How to identify for sure that the notation 200m is a length unit, or if the editor want to say something else? Maybe add some sort of tag, mentioning an amount and an unit ? Something like 'this stuff has a length of $\[unit amount:100 unit:meters$\]'? AlexanderPicoli (talk) 16:31, 19 November 2020 (UTC)

A lot of instance go through en:Template:Convert which could add metadata to help with this.
This is really only relevant to en.wikipedia.org, which unfortunately is the largest site. Maybe there should be an autogenerated variant at en-us.wikpedia.org for non-metric use. Crissov (talk) 10:54, 20 November 2020 (UTC)
My thoughts on utilizing an en-us vs an en-uk, etc to denote unitary measurements wouldn't be very helpful for someone like me, who is an American who uses metric over imperial, although I like the idea of splitting the Wikis up by dialect. For a feature like this it might just need to be slowly implemented over time as people update articles with a new formatted text like AlexanderPicoli mentions above. Benjamin (talk) 16:10, 22 November 2020 (UTC)
There are also UK people who use imperial units: our road signs show miles rather than km. One implementation might be for Convert, when showing the same value in both metric and other units, to wrap them in different classes, and to create a gadget allowing a reader to hide either of them easily with CSS. Certes (talk) 01:53, 23 November 2020 (UTC)
I considered this in the past. It will be helpful to be able to define certain user preferences (currency, unit system, etc) so a template like that will be better targeted (i.e. I may want to only use kilometers whilst an american may want miles. Default users may be shown both). I see no need to integrate the conversion in text parsing. It may only provide a variable to templates. It will be human work (or bot work) to put the {{Convert}} when needed.--FAR (talk) 09:54, 29 November 2020 (UTC)
• This is a good idea, although it would require semantically tagging all instances of quantities in article text. However, it would be immediately useful for data that's pulled from Wikidata. Silver hr (talk) 02:02, 1 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)

## Bookmarking

• Problem: There are no bookmarking if reader is on break or sleep.
• Who would benefit: Everyone
• 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)