This is very needed. The Pageviews tool in many – probably most – cases isn't really quite useful because the display of the data is flawed whenever there is/are some spike(s). Found this issue after asking here https://meta.wikimedia.org/wiki/Talk:Pageviews_Analysis#Please_add_a_moving_average_&_enable_clipping_spikes and here's how it could look like:

And when it comes to specifically this issue "create a Mix'n'Match catalog for Toolhub entries", I've now finished working on the catalog so there are barely any correctly-matched preliminary matches and I point to 1, 2, 4 in my earlier comment which is the technical work on the catalog now missing and 5 for when that is done since I won't work on that updated catalog.

The QID field in Toolhub is meant to be the link between the two projects. I'm not currently sure how we would match random QIDs to Toolhub tools in the reverse direction, but if someone can come up with a reasonably robust algorithm then I would say that this is another good job for a tool

• Isn't that different from how it was outlined in the mock-ups? Not sure if requiring swiping cards is a good idea – in virtually all successful feeds and social media apps, you don't need to swipe each item and just scroll/swipe downward.
• Moreover, having 4 articles relating to one specified interest and then 4 relating to another is a bad idea I think. It's much better in the Recommended reading list where it's a mix. That it's mixed/diverse is a great advantage that makes it more interesting. It could be best to make it an option whether items should come bundled or just be a mix (and/or to have an A/B test to see which layout users like most where I suspect the one they are familiar with – ie a uniform mix without bundling – will be more liked/used/appreciated/impactful).
• Lastly, isn't there some combinatorics where feed items are chosen based on multiple interests? If not now, then probably this will be added at some point I suspect since this can be useful to surface more-likely to be interesting / more-interesting articles. For example, X+Y+Z in interests + V in reading history and also many users with <200 articles in interests but >10 articles that are the same than this user also added this article to their interests or bookmarks. Or just X+Y in interests.
• The info why an article shows in the feed to many is clutter that's not useful and just cramming more info onto the page resulting in information overload and a nonsmooth experience so it would be good to enable hiding this info.

Still happens in v50574-r-2026-03-20. And have a lot of free storage space available so that's not the cause either. I open the app and navigated very quickly to the recommended reading list. I tried it again where I open the app, let it load 1 sec so the images display and only then go to the recommended reading list and the images are there.

1. Could the existing catalog please be updated?
2. Can it be updated without losing the work on the preliminary matches (where preliminary matches have been declined etc)?
3. Going through the catalog, I found several entries which are now dysfunctional are probably inappropriate – could the Toolhub be cleaned up and get data on status of functionality be added?
   1. For example, this is offline and this just shows hello world and this would benefit from a status about it being currently dysfunctional (just shows no data). Further items in Toolhub that are 404: one, two, three, four, five, six, seven, eight; and these seem inappropriate too: one, two, three, four, five, six, seven, eight, nine, ten, eleven, twelve, thirteen, fourteen (don't know if these have all been removed by now or if this is just an issue with the catalog but not Toolhub).
4. How to go from an entry in the catalog to the Toolhub page? It links to the tool itself and I tried to find a link to the Toolhub entry (example) at least on the catalog entry page (example) but couldn't find it there either. If the catalog is updated, it would be good to enable going to the Toolhub page (assuming it's indeed not yet possible).
5. Please help completing the catalog by going through the preliminary matched items – so far very few users contributed, mostly just TiagoLubiana and me (be careful though since there's gadgets & scripts with the same name).
6. It would be nice if Toolhub categories could be interlinked with meta and Commons categories such as https://commons.wikimedia.org/wiki/Category:Wikimedia_projects_and_maps with Geography&Mapping so that one can find the tools page from the Meta/Wikipedia/Commons category page and vice versa (note however that many Toolhub items lack that data and that maybe it would be best to postpone this until TH is in better shape).
7. Would be good to add a field for forks, e.g. this is a fork of this (this is useful for example to find newer/actively developed versions of a given script or to find similar tool; currently such are just two distinct items with no info about / link to the other).
8. Lots of useful tools are on GitHub etc but not documented within [any of the scraped] Wikimedia sites – maybe a somebody could scrape GitHub+codeberg+gitlab and get these onto the Toolhub too – the value/usefulness of Toolhub increases nonlinearly with the level of completion; it's very useful to have everything in one place (searchable, sharability, favoriting, queryable, etc).
9. Could data from/via Toolhub be added into Wikidata – e.g. this only had instance of://Wikimedia project page but it should also have Wikimedia tool// (or a subclass thereof) and some Wikidata items don't have a link to the source code where Toolhub has it etc.
10. Likewise, please load data from Wikidata into Toolhub – this includes the QID which I manually entered for this tool but also the other data in WIkidata such as license, programming language, image/screenshot, etc

@SGautam_WMF Looks good, thanks. 1) It would be good if for a while after the feature is introduced there is a small hint on the settings wheel icon that informs users about this functionality, e.g. with 'You can now pin languages'. 2) I think some users may like to be able to pin more than 4 languages.

This is already possible with the deepcategory search operator. That's a hacky way and often does not work; it doesn't solve this issue but so far it wasn't mentioned here. Further info on missing things and available ways & tools here.

This has now wish in the Community Wishlist: W516: Sortable table columns in the Wikipedia app.

Please don't delete any notifications (5 years or older or any other) before this tool has been functional for at least a while!

@Ladsgroup This depends on how one uses notifications and varies per case or types of cases. I can guarantee you 5-years old notifications can have a large value. I'm using unread notifications as basically a form of todos so for example if I made a post about some technical need on Commons VP/Technical and got a notification about it being archived, I'll get back to it for example by creating a Community Wishlist wish for the functionality if I think it would be very useful to many or ask about it at a more suitable place like say Wikidata request a SPARQL query or build the tool myself or whatever. That's just one example. It's important to not mistake how one thinks people are using a feature or how one is using a feature oneself (eg just to track Wikipedia article talk page discussions) with the actual complete usefulness/use of sth for all contributors. Notifications don't just have ephemeral value.

That's great news regarding the count limit, thanks. (The 5 years limit is still an issue for people who stay off or largely off the sites for some years but then come back.) Is there any tool that can check whether one has any unread notifications that are approaching 5 years of age or the 10,000 notifications ago limits (or to see how far from these one is)? If not, it would be useful but maybe would go into a separate issue as a feature request.

So notifications not marked as read can get lost if one has more than 2000 notifications?! That's a huge problem. Is there a way to at least see if one is affected? I'd like to prevent this data loss because I need to get back to many of my unread notifications and not lose them.

It used to be the case that the Places map was accessible with one tap on its icon in the bottom panel; now it's hidden away and needs tapping around. A widget to open the Nearby Places map would help as well by the way but it should still be customizable. I don't need the Activities page since I'm not logged in and even if I was I prefer to have the Places map in that panel no matter which thing I need to move.

Thanks! Amazing to see such a fast reaction and a new dev getting started on MediaWiki issues (much development needed here). However, I have text size set to Small in the appearance settings so I don't know whether this fixes it nevertheless. The issue exists even if I change font size to standard. Maybe it's some browser font-size thing (Firefox).

This is not fixed. Screenshot is in v50569-r-2026-03-03 when opening the Recommended reading list by going to Saved then Discover so apparently not just "when opening app via recommended reading list notification" (will remove that from the issue title):

It's not always "bypassed". Currently, the actual file page is bypassed by some unnecessary intermediary Wikipedia page that is an historic remnant and nothing of use but causing lots of very large disadvantages. If you have an example where bypassing the actual file page would be good, please elaborate. No problem with excluding POTD but even there the advantage seems to be the display of the POTD display underneath the file which is not that useful since it's largely self-explanatory when the file gets opened from POTD and additionally there are templates for this on Commons too. See for example here or here – that it has been a FP on ENWP is shown there too along with additional info. And regarding local categorization there also is Category:Featured pictures on Wikipedia, English set on these files. There are just very few local ENWP file categories and topical cats there are not useful as they don't actually have 99.99% of the files, where the files are on Commons and the users don't know so it's misleading and not actually useful. If there are exceptions it would be good maybe identify which and then make sure the extra data/info is not lost but added to the Commons pages or people can migrate it there.

Despite of the explanations by Bugreporter I remain a bit skeptical as to whether something matching what's outlined here is a feasible or better approach than improvements to and around Listeria.

A common example is featured pictures on wikipedia. I would suggest maybe linking to commons only if the local page does not exist.

@IKhitron Hello, the wish is here: https://meta.wikimedia.org/wiki/Community_Wishlist/W459 It hasn't been linked much yet

I've now turned this into a wish in the Community Wishlist: W528: Automatically add the language category to translated SVG files or after translating file (with SVG Translate) (voting open) which I think describes things better or is better scoped.

Wouldn't this be useful on desktop too (and more so since more people upload there)? See wish Guidance/facilitation of categorization of files at upload in UploadWizard. Especially if code developed here could be used for that, it would be nice if you could comment on the talk page there, thanks.

Is this issue also about showing wish titles on category pages and if not is there an issue about that? Maybe "Category membership" and "on lists (like on Wikidata)" would be good to edit for things to be clearer because these two got me wondering if this issue is maybe not about that (categories aren't really lists or at least not "like on Wikidata").

Is there an explanation somewhere why this would be useful or needed despite that users can just store them in their local text-editor / notes / todos app?

Is this also about properties proposed that were then created? And maybe one could also separate these by how often they're used, e.g. properties created used less than 100 times, more than 100 times, more than 1000 times.

Could somebody please answer this question?

Can this be solved from the cat-a-lot side or maybe even need to be implemented on that end? The gadget could add the category to the description field.

The main problem of this is not described in the issue which makes it difficult to see the importance and urgency of this. My task about that was closed as duplicate so I'll put the explanation about the main problem for why a change is needed as well as the proposed solution below:

This is an issue like T400022: 2025 Commons SEO review T54647: MediaWiki images and image pages are not being indexed properly by external search engines etc. It needs some investigation to see if other pages are affected too and if so how big of an issue it is. Should be part of eg '2026 Wikimedia SEO review' or sth like it.

"How am I supposed to know which exact questions to ask, before I even run into issues?" Strange question; you don't need to know it before.

I think this is solved via the glamorous tool that better than what's described here can also differentiate between which projects it's used in and whether it's mainspace (one can adjust the filters)

I've noticed I had a disambig page in my selected interests – maybe that's the cause and also it should be impossible to add disambig pages to it.

Thanks you two! That's surprisingly few files Amdrel. If that's close to all they could be fixed manually. It would be great if you could put that on a new Commons report page where the file links are clickable and things are in columns of a wikitable. However, it seems to be very incomplete as all of the four example files list above (+this) are not included. yt-dlp does get the higher-res version for these so maybe you could adjust how the checking works. If there still are some issues, it would be great if you could file a corresponding yt-dlp issue. No, by default everybody can upload new file revisions and a script that uploads new versions of lots of files at once would be very useful – also for other issues if they occur.

@Legoktm Interesting, this link is useful, thanks. Do you have a suggestion or hint where it would best to ask about this on Commons and/or what they could do? The ENWP list seems manually compiled. I guess one could search/query for all users with "bot" in the username without bot flag but it would miss some, probably have some false positives, and most importantly one could still not exclude them readily from the linked table. So I think it needs or the optimal solution involves adding some flag to the database (maybe into a new field) such as maybe to 'wasBot' (or 'inactiveBot') or simply readding the bot flag to accounts since I don't think any bot accounts turn to regular accounts.

What would be really cool is if one could enable users to make the DIY tile use the selected interests. For the recommended reading list one can select articles one is interested in and the recommendations work quite well.

This already works pretty well at the recommended reading list so maybe the better approach is (or a good way to interpret this) would be T418049: Enable seeing the recommended reading list articles in the home feed in app (that is: integration of the recommended reading list feature into the feed or adaptation of the RRL for a new feed component).

@Peachey88 I included the concrete example of use to better illustrate how this flag can be useful. To that table it doesn't matter if the bot hasn't edited in years. One may want to create a separate query/list with just human users and that's currently not possible. I don't know how https://commons.wikiscan.org/?menu=userstats does it because there one can exclude bots. So for example maybe add an additional user flag that shows whether a user is a bot regardless of how long ago the last bot edit was. How to get this information and how to request a change that makes it possible to see which users are or aren't bots if not here? I'm looking for a pragmatic/actual solution, thanks,

@Legoktm You mean this would have to be solved by Commons admins? Or by who? And that was just an example, lots and lots of bot accounts do not have that flag. It does look like a technical issue. How to solve this?

How it could look like:

Thanks for looking it and sorry for not providing a set of affected files right away; here are some from the list of my uploads also linked at the talk page:

• 640x but 1920x when downloaded
• 640x but 1920 at source
• 640x but 854 at source
• 640x but 1920 at source

@ABorbaWMF I don't know what caused this so I couldn't make a screen video. My tabs are now simply at 1 or 0 because the dozens of tabs got closed somehow.

Reasonable zoom level (eg plan your next destination during a city tour) but clustered:

Thanks, I'll attach a screenshot if you can tell me how to see the initial Special:Homepage that is shown when no interests are selected. I can't get this view anymore.

Here's an illustration of how this could look like and how it would function. It would be super useful (surprising it's not there).
Wish in the Community Wishlist (voting open).

It may be easier to see if tabs can get lost anyhow than reproducing it or at least I'm aware I don't have precise info how this occurred: I was just browsing around in the app to investigate for the backup issue such as whether there is a setting option to backup saved interests (settings, and interests page). It may have to do with opening an article of the interests and then one from the main feed, maybe it wasn't the Main page that I opened. If you let an LLM check the code maybe it does find what could be the cause for tabs being lost. Anyway it's a bit frustrating to have lost all my tabs and I imagine for some this can be big issue (most of my tabs weren't things I meant to continue reading or saving somewhere but this can be different for others). My reading history is still there but it's too many pages to go through them all to try to recreate which tabs were open. They aren't still there anymore when pressing back either - it had only 5 tabs still open of the many that I had and I think opening the Main page and/or article from the Most read tile on the Explore feed and pressing back also closed these few.
It's important to make sure data loss does not occur in apps. Nevertheless, I'd first of all top-prioritize making it possible to backup (and restore) other data of the app to some file. I really need to backup my saved interests and bookmarks but this is not possible.

@Amdrel Yes, that's a good point. I was aware of this caveat but thought this would be best addressed later on separately. Usually, it's most useful to exclude the videos that are not CCBY videos from the multiselect. Sometimes as with your examples that's different. As a solution I'd propose to exclude them by default but somewhere in the UI there include a toggle button eg 'Show non CCBY' which also shows these (maybe unselected by default with the rest being selected by default). Or something similar to this. I think this would be much better than showing all videos of the channel excluding only the ones already uploaded by somebody to Commons. With such a toggle option one can use the appropriate approach per channel. The warning message box would be useful.

I wasn't sure if I correctly understood the question and I thought you were asking what would be shown when the user configures labels after configuring their multiple watchlists. So my answer was that the new labels would need to be added to watchlists before their items show or they could be configured to be autoassigned to a specified watchlist on the GW. Could you clarify or rephrase the question? For example I don't know what you mean with "choose some of them [the labels] for collapsing" if this still applies – instead of allowing the user to collapse labels every time anew when opening the GW, they would configure multiple watchlists. So maybe 4 Watchlists for en.wikipedia, one with just pages that have the discussionpages label, one with todo label, one with x label and y label as well as all newly created labels, one with all items without label. Including a label in one of the watchlist like adding label z to watchlist 2 could be done by pressing the watchlist-configs button at the header of the watchlist and then selecting the label like one can select the tags here (dropdown with possible values and autocomplete).

Great to see progress on this and thanks for asking. I think some users at the other task may have more input. Haven't tested/used the labels yet and will probably be able to give some better input after I did. I think a good way to implement this would be allow the user to create new custom watchlists where they can include one or multiple labels (and one could also include unlabelled items in one of these watchlists per Wikimedia project such as en.wikipedia).

@Doc_James Great, thanks! Closing but please reopen if this is not fully solved. Also don't know how to find more cases of this so if you know how to find more please fix these too. Hopefully this was the only article with this bug.

This also applies to portal pages. Wouldn't set the priority to Lowest here since the main feed is pretty boring and one can bookmark Main page, various portals (especially the Current events one), and maybe some pages like it for starting points of discovery. Edit: I changed the priority since it was set before the task scope was rechanged from categories to all non-article namespace pages which is far less narrow and the priority does make some sense when this was just about category pages.

@Dbrant Thanks for clarifying. But the issue is the articles for which no short description is available. Did they also decide against that? Do you have a link? I couldn't find the RfC. If they decided against it, a new RfC imo would make sense because so many articles do not have a short description but do have a Wikidata description. Maybe Wikidata description changes for the given language (no other changes to the item) could be shown in the Wikipedia Watchlist to mitigate the concerns too.