Community Wishlist Survey 2022/Archive

This page is an archive for Community Wishlist Survey 2022 proposals that won't go on to the voting phase. Proposals may be archived for various reasons, including: the proposal is too vague, the idea is technically unfeasible, the problem has already been solved, an existing product team is already working on it, the proposal is a social/community change rather than a technical one, or the proposal is asking to remove features that WMF product teams have built.

Only members of the Community Tech or Community Relations teams should move proposals into or out of the Archive. If your proposal has been archived and there's still time before the voting phase starts, please continue the discussion on your proposal! You may be able to fix a problem with the proposal, and get it back in the survey. Once the voting phase starts on January 28, we can't move any proposals out of the Archive.

Adopt the new design faster

 N Incomplete proposal / On roadmap of another team


  • @Betseg: There are two issues here. First, you didn't fill out the "Problem" statement. I think from the title your concern is the Desktop Improvements project is taking too long to deploy to wikis? The team responsible for this is deliberately taking it slow in coordination with each of the communities. The second problem here is that you're asking us to work on something that is already being planned by another team, which is something we strictly do not do. For this reason I'm going to archive this proposal. You can learn more the survey and how to create a good proposal by reading our FAQ. Thanks for participating! MusikAnimal (WMF) (talk) 19:06, 10 January 2022 (UTC)

Non-admin user group that can block users

 N Proposes a social/policy change, does not requiring engineering resources

  • Problem: Some users vandalize and it takes time before actions occurs.
  • Who would benefit: All users in Wikipedia, page creators, admins, and generally all people.
  • Proposed solution: A new role named Blockers. They temporally block vandals and wait for an admin to come to take action.
  • More comments: The role just doesn't allow an editor or vandal to edit until an admin reviews it. And the requirments for the role is to have more than 700 edits, to be in Wikipedia for more than 60 days, and a non-questionable background.
  • Phabricator tickets:
  • Proposer: Yodas henchman (talk) 19:55, 10 January 2022 (UTC)


  • This is basically asking for a new user group with the block permission. This can be set up now with a simple configuration change. On English Wikipedia, for instance, the idea has intensely and repeatedly been rejected. However if your community has consensus to introduce such a user group, simply request it on Phabricator, tagging with #Wikimedia-Site-requests. I'm going to archive this proposal since there's no engineering work required. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 20:03, 10 January 2022 (UTC)
@Yodas henchman and MusikAnimal (WMF): this sounds like a possible request that would require engineering work, along the lines of phab:T128328 - while it is true that projects can already make a new group that has the "(block)" permission - that task and a recurring discussion has been to make a new permission that can only block IP's , or can only place time-limited blocks. If so, development of that workflow would be needed. Yodas henchman, is that functionality something you are looking at needing here? — xaosflux Talk 22:07, 10 January 2022 (UTC)
Not really just proposed the user rights group Yodas henchman (talk) 22:08, 10 January 2022 (UTC)
@Yodas henchman: ok then, this is something that can already be done, even on WMF wikis - just start a community discussion to create a new group that contains the "block" permission, be sure the community discussion is well attended and result in a strong support - then drop a configuration request to enable it. Non WMF-wiki's sysadmins can just enable this in the configuration already. — xaosflux Talk 22:29, 10 January 2022 (UTC)
I don't understand well Yodas henchman (talk) 17:32, 11 January 2022 (UTC)

Hungarian language Wikipedia

 N Proposes a social/policy change rather than a technical feature

  • Problem: Some users with "privileges" on the Hungarian Wikipedia think they own the whole Wikipedia. They hardly provide any real help, and if they do, it is only in their own interests. If anyone has any suggestions, they are ignored. Some of the patrollers do not even do their job because they think that if they are not obliged to do it, they don't have to. Unfortunately, the Hungarian Wikipedia has a high rate of bias and discrimination. Both against foreigners and Hungarians.
  • Who would benefit: The Hungarian Wikipedia as a whole, because in addition to the shortage of editors, some members sometimes seem to be intentionally generating fluctuation. And several former members can testify to this.
  • Proposed solution: Withdrawing the rights of certain members, And appointing new members to the post. Also, requiring patrollers members to use their privileges. In a word: Re-election of certain administrators would be the best way forward. Because that way, they will only bring shame to the Hungarian Wikipedia. The numbers are just numbers, that's not all, and anyone who hasn't been an editor there doesn't really know what kind of wolves in sheep's clothing are in charge.
  • More comments: Unnecessary votes are taken on things to leave 8-10 word stub articles, all just to make the "counter" show a more core value. But all this stub is worthless, because no one knows anything about them.
  • Phabricator tickets:
  • Proposer: ᕵᗩᑘᒪ_ᖶᕼᘿ_ᑢᖻᑢᒪᓰSᖶ from Hungarian Wiki Post 20:36, 10 January 2022 (UTC)


  • Out of scope: This is a request for a global (steward) action against a local community. You're probably looking for RFC, which may be a suboptimal idea as well but is at least a possible venue for such requests. ToBeFree (talk) 20:46, 10 January 2022 (UTC)
  • Per above. Please see the FAQ for more information on what this survey is for. Thanks for participating, MusikAnimal (WMF) (talk) 21:23, 10 January 2022 (UTC)

Adding of a needed line in river templates and/or infoboxes, Añadidura de una línea necesaria en plantillas de ríos.

 N Does not require engineering resources

  • Problem: Lack of information about river mouths.
  • Who would benefit: Users, readers of the Wikipedia.
  • Proposed solution: Please, in river templates and/or infoboxes, add another line in the format so any collaborator / user / editor can specify / type / add the geographic COORDINATES of the mouth of any and all of the rivers featured in the Wikipedia –not only those ones corresponding to the river source–. This lacking of geographic coordinates may affect some readers. 20220110 (Monday).
  • More comments:
  • Phabricator tickets:
  • Proposer: Heterotrofo (talk) 21:15, 10 January 2022 (UTC)
  • Problema: Falta de información acerca de los respectivos nacimientos de ríos.
  • Quiénes se beneficiarían: Usuarios, lectores de la Wikipedia.
  • Solución propuesta: Por favor, en las plantillas de ríos, añadid otra línea en el formato para que cualquier colaborador / usuario / editor pueda especificar / escribir / agregar las COORDENADAS geográficas de la desembocadura de cualesquiera y todos los ríos que aparecen en la Wikipedia, no solo aquellas correspondientes al nacimiento del río. Esta falta de coordenadas geográficas puede afectar a algunos lectores. 20220110 (lunes).
  • Más comentarios:
  • Boletos Phabricator:
  • Proponente: Heterotrofo (talk) 21:15, 10 January 2022 (UTC)


  • You can do this now. Just have your community make the necessary changes to the relevant templates. You may need to seek broader input from your community and/or have someone with the appropriate editing rights implement it, however. Either way unless I'm missing something, this doesn't require any engineering help from the WMF, so I'm going to archive this proposal. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 21:42, 10 January 2022 (UTC)

Change NHL player infobox to make it similar to NFL,MLB,NBA player formats

 N Does not require engineering resources

  • Problem:
  • Who would benefit:
  • Proposed solution: Change NHL player infobox formats to make it similar to NFL,NBA,MLB player infobox formats
  • More comments:
  • Phabricator tickets:
  • Proposer: Black roses124 (talk) 22:19, 10 January 2022 (UTC)


  • This can be done now. Simply consult template editors on your wiki to adjust the relevant templates as desired. You can read our FAQ for more information on what this survey is for. Thanks for participating, MusikAnimal (WMF) (talk) 22:25, 10 January 2022 (UTC)


 N Proposes an existing solution

  • Problem: There is to my knowledge no manner to know the number of times an article has been read.
  • Who would benefit: Creators of new articles; editors who have significantly contributed to an article
  • Proposed solution: There could be a number in the footer of the page indicating the number of times that article has been visited since its creation.
  • More comments: I know this is a problem of very minimal importance, if it can even be considered a "problem;" however, following the creation of an article, I am always curious to know at least an approximate number of visits made to it. Furthermore, I have no idea how this could be done, but it is just an idea I wanted to "put out there."
  • Phabricator tickets:
  • Proposer: Meduer (talk) 01:22, 11 January 2022 (UTC)


  • We already have Pageviews and XTools that can be used to see not only the number of views but also more detailed statistics. And article history pages in many projects have links to this tools. — putnik 02:27, 11 January 2022 (UTC)
  • Per above, there are multiple ways to get this data already. I see your home wiki is English Wikipedia. There, and on most other large wikis, you will probably find a "Pageviews" link on the revision history page (example). On all wikis, you can click on the "Page information" link in the left sidebar under "Tools" (example for Community Wishlist Survey), then look for "Page views in the past 30 days" which has a link to a graph. We can make these links more prominent, such as how is done on German Wikipedia (they show the links at the bottom of the article), but it is up to your local community to decide that. For English Wikipedia, you could propose the idea at w:Wikipedia:Village pump (idea lab) for instance. As there is an existing solution, I'm going to archive this proposal. Thanks for participating! MusikAnimal (WMF) (talk) 04:51, 11 January 2022 (UTC)

Unbiased admins

 N Describes a social/policy change and not a technical feature

  • Problem: Many admins are clearly radicals (leftist extremists). They often allow no debate on what can be published and their word is last, regardless of whether they are right or wrong. I have experienced this dozens of times over the last two years. Sometimes, they are not ideological radicals, but are so high on their admin horse that they can't find it in them to admit they've made a mistake and they simply disregard others' opinions with the stance, 'I'm an admin and anything you 'plebs' say doesn't really matter'. This is the main reason I have stopped donating to Wikipedia. If you let any group (regardless of which side of the political spectrum they may be standing on) hijack a website, especially an encyclopedia, then its objectivity is questionable at best and, in this case, that is slowly opening the doors to Wikipedia's demise. That door needs to be shut proper and any biased and prejudicial admin (left, center, or right) should never be allowed to become an admin again.
  • Who would benefit: All users and especially Wikipedia itself (if Jimmy still cares about this being a reputable site).
  • Proposed solution: There needs to be a better system of supervision and an easy way to report such cases, so that such admins are scrutinized and have their admin privileges taken away from them if appropriate.
  • More comments:
  • Phabricator tickets:
  • Proposer: NoWikiNoLife (talk) 11:05, 11 January 2022 (UTC)


  • I share the description of the situation. However, only a small part of Wikipedia is influenced by activists with administrator rights. It could be that there is no better system than the existing one. A perceived 99 percent of the pages are unaffected in my view. The remaining percent is the honeypot I stay away from. The type of administrators is determined by democratic election. What might increase the turnout of voters? — Aktenstapel (talk) 13:31, 11 January 2022 (UTC) (in Wikipedia a non-voter).
  • Unfortunately Community Tech can't help with this. I think the best course of action would be to get a conversation going here, such as at Stewards' noticeboard. I'm going archive this proposal since it doesn't ask for any explicit technical changes (reporting systems like SR already exist). Even if you wanted a new reporting system built from the ground up, it needs a lot of community discussion first. Community Tech can't set goals like "fewer biased admins" and we certainly can't be responsible for monitoring admin activity. You can learn more about what this survey is for by reading our FAQ. Thanks for participating, MusikAnimal (WMF) (talk) 14:39, 11 January 2022 (UTC)
  • Yeah, as expected. First, one of the comments (of another Wikipedia user) has been deleted. Then, the discussion is immediately shut down using an excuse (that it's not a tech issue). I expected as much. Wikipedia is becoming more and more user unfriendly. The attitude we get from those of you who are in charge is that we should all butt out and leave you to run Wikipedia the way you want. Fine. But you are losing loads of people in the process. I used to be a huge proponent of Wikipedia and promoted it whenever I could. No more. For the last two years, I have been telling everyone about my experiences here and I will continue to do so. NoWikiNoLife (talk) 23:23, 11 January 2022 (UTC)

Commons specific: editor permission to undelete categories

 N Describes a social problem rather than a technical feature

  • Problem: Some time ago I created a veritable cathedral of categories for an artist for whom I had written a en.WP article, and for whom I had uploaded a large number of images to Commons. In order for myself to find anything in all those pictures, I had to create multiple categories, including the countries featured in the pictures (China, UK, etc.), which important national collections had which pictures (UK Royal Collection, British Museum etc.), the subject of the pictures (ships, buildings, views etc.), and more, with all the categories mentioning the artist's name, to keep the whole pattern together. It took a long time do do this carefully and in a logical manner, so that anyone could find anything. Then along came an eager editor who had not read the article and did not know the artist, and they rearranged the whole thing, deleting all my categories, and possibly losing some images from the set in the process, who knows. That editor did not stop when I asked them, and did not respond to my messages. I could not repair the mess because as a non-admin I cannot undelete all those categories. Explaining all this to an admin and getting them to undelete them one by one as I worked through it would waste their time and mine, so I have hesitated to repair this mess. I did alert an admin, but the eager editor was working so fast that they had done most of it by the time a couple of categories were saved from deletion. Those saved categories still stand there, empty, waiting for me to do the mass repair.
  • Who would benefit: Anyone who needed to sort out the same sort of time-consuming category deletion mess. A good way to start to undo the very complicated mess that I am faced with, would be to go through the history of each image filepage, and undo the category deletion history as shown there. That way, every image filepage would be dealt with, if you dealt with them all in careful order. (I still don't know how I would track down any images which were accidentally lost from the set by the rampaging editor, though).
  • Proposed solution: So what we need is a system where an ordinary non-admin editor like me can get permission (if only temporary for a specific task) to undelete categories (complete with also-deleted parent categories if possible?) where that job is needed.
  • More comments:
  • Phabricator tickets:
  • Proposer: Storye book (talk) 12:20, 11 January 2022 (UTC)


  • There isn't really such a thing as "category deletion". All that involves is removing all pages from a category, then deleting the category page itself. You can always re-add the categories to the pages, and re-create the category page (unless the admins create-protected the category page). That's the only technical way to undo the "category deletion". Either way there's no concept of undeleting a category. Admins don't have this "permission", either. They likely de-categorized the pages en masse using c:Help:Gadget-Cat-a-lot, which you should have access to as well (though I'm not encouraging you to start and edit war). I'm sorry you experienced what you did, but the best solution I would think is communication with editors and reaching out to the broader community for assistance. Since I don't see any technical way we could help you, I'm going to decline this proposal. Thanks for participating in the survey, nonetheless! MusikAnimal (WMF) (talk) 14:58, 11 January 2022 (UTC)

Preview tab

 N Overlaps with existing Real Time Preview project

  • Problem: Editors cannot switch between source editing and preview promptly. Also, some shortcut keys such as Ctrl/Command-Z do not work to undo/redo an edit after entering the preview mode.
  • Who would benefit: All editors who use source editor of MediaWiki software.
  • Proposed solution: Implement the "Edit" tab and "Preview" tab in the source editing mode. You can refer to or try testing en:User:Ykhwong/Gadget-tabPreview.js that I created in JavaScript to demonstrate the idea. (For testing, turn off New wikitext mode in Beta features)
  • More comments:
  • Phabricator tickets:
  • Proposer: Ykhwong (talk) 04:03, 11 January 2022 (UTC)


  • @Ykhwong: It's hard to tell what your script does by just looking at the code, but two things you may not be aware of: There is an existing preference called "Show previews without reloading the page" available in your preferences. This will show a preview and your undo commands will still work. Secondly, you'll be pleased to know Community Tech is already working on a Real Time Preview feature for source editing. We're somewhat far into that project, so we should have more updates to share on that soon. Stay tuned! :) That said, do these upcoming/existing features satisfy your wish, or is there something else you're looking for? MusikAnimal (WMF) (talk) 04:13, 11 January 2022 (UTC)
Thanks for the info. I have been using the preference "Show previews without reloading the page" for months, but I forgot that I can still use the undo/redo shortcut keys while keeping the option turned on. My suggestion is to implement a new tab that is somewhat different from the real-time preview feature to preview the page in real-time when editing (simultaneously). However, if you consider the wish a duplicate, you may archive it. :) Ykhwong (talk) 04:40, 11 January 2022 (UTC)
preview the page in real-time when editing (simultaneously) is exactly what we're going to offer. The UI I think may differ from your script, but something tells me you'll enjoy what's coming. With your word, I'll go ahead and archive this wish as it overlaps with existing work. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 15:27, 11 January 2022 (UTC)

Allow ancient languages' wikis

 N Does not request a technical feature

  • Problem: Many active ancient languages' test wikis are blocked for creating new articles at the Wikimedia Incubator in 2021, though editing already created pages is allowed.
  • Who would benefit: All the participating editors as well as all the readers.
  • Proposed solution: The solution to the problem is allowing the creation of ancient languages' wikis if they have the same potential like those of succeeding modern languages' test wikis. For this, please allow the creation of new articles in their test wikis.
  • More comments: There are many ancient languages' test wikis at Wikimedia Incubator in which creation of new articles is blocked but editing already created articles is allowed. This issue started in the year 2021.

    These test wikis do not have little quantity of contributions like 1 or 2 pages, but with a relatively large number of articles just like those of living/spoken languages' test wikis at Wikimedia Incubator, the same platform. The ancient languages' test wikis' contributors are interested in expanding articles as well as creating new articles. If a test wiki has a potential (actively participating editors with significant contributions) to become a wiki, please allow them, without specifying if they are ancient or modern. When we just have a look at the already created ancient languages' wikis like Latin Wikipedia or Sanskrit Wikipedia or Old English Wikipedia, they work normally like every living languages' test wikis, without any shortage of active contributors. Same potential, same volume of contributors and contributions are explicitly seen in many ancient languages' test wikis at Wikimedia Incubator. So, please allow them to be approved for independent wiki status if their test wikis fulfill all the criteria for approval like their succeeding modern languages' test wikis at the incubator. For this, please allow the creation of new articles in their test wikis.

  • Phabricator tickets:
  • Proposer: Haoreima (talk) 14:47, 11 January 2022 (UTC)


@MusikAnimal (WMF): Do you mean it can't be ammended from here? What if I change the category from "Editing" to "Miscellaneous"? Haoreima (talk) 17:21, 11 January 2022 (UTC)
@Haoreima I mean the decision on whether or not to approve a new language or project rests solely on the governing body (Language committee it seems?). You will need to consult them and/or go through the established processes to get the new wikis created. The Community Wishlist Survey is about making technical software improvements. It sounds like the wikis you attempted to have created in the past were rejected for some reason or another, which is not something we can change. Is that correct? Could you provide links to the prior discussions? MusikAnimal (WMF) (talk) 17:37, 11 January 2022 (UTC)
@MusikAnimal (WMF): If you mean links, it is Requests for comment/Start allowing ancient languages. It's not proposed by me, though I supported it. Well, I misunderstood the wishlist curriculum. Well, I have to search for other ways but I don't know how and what to do now! Haoreima (talk) 17:44, 11 January 2022 (UTC)
So it seems the RfC is still in process. We will have to let that run its course, and if the consensus is no, there's nothing we (Community Tech) can do to change that. Sorry! You could solicit broader input by reaching out through the Languages mailing list, or even Wikimedia-l if you have the appetite for very far reach. Best of luck and apologies we cannot help you further, MusikAnimal (WMF) (talk) 17:57, 11 January 2022 (UTC)

Surtout, ne rien changer !

 N Does not request a technical feature

  • Problème: ca change sans arrêt
  • Qui en bénéficierait: tout le monde
  • Solution proposée: ne rien changer en 2022
  • Autres commentaires: merci par avance
  • Tâches sur Phabricator:
  • Proposant: Paul.schrepfer (talk) 06:08, 11 January 2022 (UTC)


  • Tu trolles, Paul.schrepfer ? En quoi les améliorations faites les années précédentes grâce à cette consultation annuelle t’ont-elles gênées ? --Pols12 (talk) 20:28, 11 January 2022 (UTC)
    Seems like trolling. We'll of course archive it. MusikAnimal (WMF) (talk) 01:31, 12 January 2022 (UTC)
  • Pols12, je suis gêné par le fait que je doit, à chaque connexion, faire un clic de trop depuis que, en haut à droite de l'écran le menu a été modifié. Je suis gêné dans les discussions des pages à supprimer quand les utilisateurs utilisent le bouton répondre au bout de mon avis au lieu de discuter dans le chapitre discussion....... Et là je suis gêné quand, à priori et donc sans échange préalable, on évoque un possible trollage de ma part. On m'a demandé mon avis, j'ai donné mon avis, et je pense qu'il est aussi respectable qu'un autre. Je n'aime pas qu'on change mes habitudes, et je ne dois pas être le seul, alors une année sans changement serait une juste prise en compte de cette tendance, à mon avis. Amicalement. - Paul.schrepfer (talk) 06:16, 12 January 2022 (UTC)
    Bonjour MusikAnimal (WMF), vous pouvez archiver mon avis, il n'y a aucun problème. Le fait que mon avis soit différent de ce que j'imagine être généralement attendu dans le cadre d'une telle consultation, sinon pourquoi avoir écrit ce que vous avez écrit, est-il en problème en soi ? Nous sommes dans la phase de proposition, je propose ! Si mon avis est retenu, j'en serai satisfait, si ça n'est pas le cas, j'aurai fait entendre une voix dont je ne suis certainement pas le seul tenant. Comme je l'ai précisé ci-dessus à Pols12 : "Je n'aime pas qu'on change mes habitudes, et je ne dois pas être le seul, alors une année sans changement serait une juste prise en compte de cette tendance, à mon avis". Cet avis n'est pas nouveau et je l'ai déjà exprimé à plusieurs reprises sur le bistro de la Wikipédia francophone, et il n'a rien de provoquant ou de trollesque, puisque c'est de cela que je suis soupçonné. J'avoue être surpris du ton des remarques qui me sont faites. Amicalement. - Paul.schrepfer (talk) 07:41, 12 January 2022 (UTC)
    Ma question était sincère, parce que ton message « ça change tout le temps », sans expliciter quels changements posent problème me semblait trollesque ; alors que je te sais contributeur pertinent dans la discussion.
    Cette consultation permet de créer ou corriger de nouveaux outils facultatifs, elle ne vise pas à changer l’interface. Le fait que le bouton Répondre apparait au mauvais endroit sur les PàS est par exemple un problème que l’équipe pourrait corriger si quelqu’un en faisait le souhait. Tu vois donc bien qu’il y a des changements que tu souhaites. (Ceci dit, les gens répondaient aux avis bien avant l’apparition du bouton Répondre…)
    Estimer que « tout le monde » gagnerait à ce qu’il n’y ait aucun changement me parait naïf, de mauvaise foi ou égocentré. Cette consultation n’est pas faite que pour les contributeurs de Wikipédia en français, mais aussi pour ceux de Wiktionary en malayalam, par exemple. -- Pols12 (talk) 12:36, 12 January 2022 (UTC)
    Pols12, désolé si mon message un peu télégraphique a pu être mal interprété. Pour les PàS j'ai déjà échangé là dessus avec Whatamidoing, pour le menu de connexion, avec Patafisik, (sans certitude), ....... quand j'ai un problème, je l'évoque sur le bistro, je n'ai donc pas vu l'intérêt de revenir dessus ici. Le bouton répondre n'apparait pas au mauvais endroit pour certains (dont moi qui ne le voit pas, j'ai été informé de son existence quand j'ai fait remarquer à un utilisateur que j'avais exprimé le souhait qu'il réponde ailleurs que sur mon avis et qui m'a répondu qu'il ne faisait que cliquer sur le bouton répondre qui se trouvait au bout de mon avis), mais pour d'autres, il apparait et ils l'utilisent, nous avons donc des versions différentes en terme de fonctionnalité qui coexistent simultanément et qui créent, à mon avis, des problèmes. Si j'ai écrit que tout le monde y gagnerait, c'est en terme de stabilité. Le menu de connexion a été modifié il y a plusieurs mois, et je ne suis pas encore habitué. Nous ne sommes pas tous doués de la même manière. Une année de calme me semblerait de nature à pouvoir digérer les modifications récentes. Et désolé si je ne suis pas adressé au bon service, je ne sais pas qui fait quoi. J'espère que nous avons purgé le sujet !? Amicalement. - Paul.schrepfer (talk) 13:28, 12 January 2022 (UTC)

Levels of Relevance

  • Problem: Articles which are incomplete, in development or of claimed irrelevance are often unceremoniously deleted (esp. in the de.wikipedia). This has already caused lesser acceptance among editors and fewer contributions.
  • Who would benefit: some Readers (as there is more content about more topics available), many editors (as they won't write into the bin that often), all exclusionists (as they don't have to bother debating relevance), everyone (as stub articles are accessible to anybody, so more people can contribute to completion which will lead to generally more valuable content).
  • Proposed solution: Articles get a publishing rating of three or more degrees, so whoever feels uncomfortable with the lower levels will simply not activate them, as they are hidden per default. Levels could be:
    L1: Articles of undisputed relevance and with no major information missing; are shown to everyone (as it is now)
    L2: Articles of a formerly disapproved but generally significant lemma or of relevance lesser than L1 but still considered high; incomplete articles. L2 articles must not cover in more detail any existing section of a corresponding L1 article (to avoid content intereferences).
    L3: Articles of relevance like L2 but with content extending an existing article section. As interference with a corresponding main article is tolerated the L3 content is supposed to be frequently reviewed for integration in an upper level.
    L2 and L3 is shown only to logged in users who set them to unhide.
  • More comments: The technical implementation shouldn't bee to hard and the logical integration of the current structure isn't touched. Yet it would meet the demands of the inclusionists without change the wikipedia for the others.
  • Phabricator tickets:
  • Proposer: Robbit (talk) 22:33, 11 January 2022 (UTC)


This is primarily a social issue rather than a technical one, as it is primarily asking for a fundamental restructure of how Wikipedia is structured. * Pppery * it has begun 04:59, 12 January 2022 (UTC)

Isn't that just semantics. Organizations are constantly restructuring themselves. The question is, is the stated issue real, and does this proposal help. — The preceding unsigned comment was added by Herostratus (talk) 05:18, 12 January 2022 (UTC)

I might have been not specific enough. 😊 I really do propose a technical solution to the problem: it demands an additional flag of the article pages. It demands not only approval for the method of separating contents but also a technical logical way allowing to distinguish the types/levels of articles. --Robbit (talk) 09:30, 13 January 2022 (UTC)

Add ability to search by user agent from CheckUser interface

  • Problem: CheckUsers cannot search for users based on their user-agent; they can only search by IP. In some cases, the user-agent is quite distinctive and searching by it can more quickly reveal socks (specially when the user is IP-hopping using proxies).
  • Who would benefit: CheckUsers on every project with local CUs, stewards on all projects.
  • Proposed solution: User:Kaldari has made a detailed proposal including mock-ups in phab:T146837.
  • More comments: One major hold-up has been phab:T147894 and the decision on which index to create. This will require contribution from someone with DBA access so they can run a bunch of test queries on various projects.
  • Phabricator tickets: phab:T146837
  • Proposer: Huji (talk) 01:11, 11 January 2022 (UTC)


  • @Huji: Thank you for proposing this. Unfortunately, this work conflicts with the future deprecation by Chrome and other browsers of the UA string in favor of Client Hints. There are already a few tasks to figure out how to deal with it, and CheckUser is a known affected extension by this change. I can see you've already participated in T242825. Here are these other tasks relevant to Client Hints T258592, T258591. Sorry to have to archive this proposal. DMaza (WMF) (talk) 14:43, 12 January 2022 (UTC)
    @DMaza (WMF): I am well aware of that. However, we are still months (if not years) away from Client Hints impacting us widely, the proposal here has been waiting for several years, and when Client Hints ultimately take over we would need similar functionality for them too so I am hoping that some of the work here (i.e., simply determining what queries need to be run to convince DBAs to create a new index per phab:T147894) would similarly apply then. Time spent on this proposal will not be wasted time. It will add a feature that we use now, and pave the way for a similar feature we would be using later for Client Hints. Huji (talk) 15:02, 12 January 2022 (UTC)
    @Huji There is a team already looking into Client Hints adoption and UA strings deprecation. Unfortunately, any work related to UA strings will likely overlap with what they are doing or be considered tech debt since it will need to be reverted or reworked at some point.
    Your other proposal on the other hand is totally valid and ready for voting. Let me know if you have any other concerns. Thank you again! DMaza (WMF) (talk) 18:18, 25 January 2022 (UTC)
    @DMaza (WMF): what if we rewrite this proposal to be inclusive of Client HInts, or specifically about Client Hints? Huji (talk) 18:41, 25 January 2022 (UTC)
    I'm afraid that until T295073 is completed our team can't really do anything about it unfortunately. DMaza (WMF) (talk) 14:12, 26 January 2022 (UTC)

Add 'Open Access' tickbox to RefToolbar

 N Does not require engineering resources

Add a tick box to this?
  • Problem: When adding references there is no option to flag them as open access.
  • Who would benefit: Primarily the readers and editors of scientific articles and anyone else committed to 'open access'
  • Proposed solution: Add a tickbox to RefToolbar (or just it's 'journal citation' section). When ticked |doi-access=free is added to the string produced
  • More comments: Scientific articles mostly use academic journals as references and >90% of these are pay-walled, however many editors focus on finding the 10% which are Open Access. Journal which are open access are clearly shown as such on the publisher website - we know what we're adding. Currently OA tags mostly end up getting added by 'Citation bot' but this is resource heavy.
  • Phabricator tickets:
  • Proposer: Project Osprey (talk) 21:29, 10 January 2022 (UTC)


  • This seems like something that should be requested at en:Wikipedia talk:RefToolbar first. If there's consensus, it could be trivially enacted by any interface administrator without the need for WMF intervention or taking up one of the wishlist slots. Ahecht (TALK
    ) 15:17, 11 January 2022 (UTC)
    A fair point. I've requested it at RefToolbar. I'll note the outcome here (assuming it's swift). --Project Osprey (talk) 09:56, 12 January 2022 (UTC)
    Since this requires no engineering resources from WMF and is something only the community can implement, I'm going to archive this proposal. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 15:48, 12 January 2022 (UTC)

Intermediary Editor Dispute Board

 N Withdrawn by proposer

  • Problem: Editors -- even experienced ones, will clash with another editor at least once during their time on Wikipedia. Most editors can come to agreements on talk pages if disagreements or problems persist/occur (for example, taking issues with editing styles, mass deletions, etc.). However, there are some instances where some editors can get so entrenched into their positions, that editing wars occur, problems may get escalated to noticeboards and so on. Usually when things get escalated to noticeboards, punishments can be handed down in one form or another, which is not ideal. What is missing is an intermediary board before it gets to this point: A non-binding problem/issue discussion board or forum, where some disagreements can be worked out with a larger group of editors -- almost like a mentoring session or group therapy. Such a board may dissuade any further escalation between hot-headed editors via a spread out with cooler heads (editors) -- and perhaps reaching non-binding consensus, which is always the best outcome in the long run, before things get any worse. If such disagreements can be headed off before having to go to admin boards, this may help the admins in avoiding petty disagreements, saving their time for real issues that need addressing.
  • Who would benefit: Editors who find themselves in perpetual disagreement with another editor or editors. It would also help admins avoid such disagreements.
  • Proposed solution: Creating a non-binding board/forum where editors can work out differences with the help of other editors - when most admin boards do not fit the bill and just before taking the issue to official admin noticeboard action.
  • More comments: Since we all edit Wikipedia virtually and never really see anyone face-to-face, this forum might be a good place where editors can come together to work out differences before things get heated -- just like in real life. This board would be situated right below the dispute boards, admin boards, etc... but above talk pages and any other lower boards (if applicable).
  • Phabricator tickets:
  • Proposer: Hanyou23 (talk) 20:36, 11 January 2022 (UTC)


  • Project can create any pages and processes they want already, what technology do you think is lacking that would need to be developed for this? — xaosflux Talk 00:22, 12 January 2022 (UTC)
    Made a mistake this morning before caffeine and didn't see where I was at -- my bad... proposal withdrawn. Hanyou23 (talk) 05:17, 12 January 2022 (UTC)
See mw:Anti-Harassment Tools. That project even goes farther than your proposal with an global editquette.--Snævar (talk) 11:31, 12 January 2022 (UTC)

Accept more credible references from YouTube

 N Proposes a social/policy/licensing change rather than a technical feature

  • Problem: YouTube is currently not accepted as a credible source, blanket ban
  • Who would benefit: Wikipedia quality and all its readers
  • Proposed solution: Accept YouTube videos on a case-by-case basis, to include credible ones
  • More comments:
  • Phabricator tickets:
  • Proposer: Fredericknoronha (talk) 22:39, 12 January 2022 (UTC)


  • Sorry, only your local community can decide that. This survey is for proposing improvements to software tools. You can learn more in our FAQ. I'm going to have to archive this proposal, but thanks for participating, anyway! MusikAnimal (WMF) (talk) 22:56, 12 January 2022 (UTC)

More Admin from the Global South

 N Proposes financial/cultural change rather than a technical feature

  • Problem: Blind spot currently towards large areas of the world.
  • Who would benefit: Everyone accessing the Wikipedia, Wikipedians who get more incentives to participate from the Two-Thirds World, and the Wikipedia itself.
  • Proposed solution: Get more participation from the Global South. Make sure all Admin are sensitive to issues from here.
  • More comments:
  • Phabricator tickets:
  • Proposer: Fredericknoronha (talk) 22:37, 12 January 2022 (UTC)


  • As much as we'd like to help with this, Community Tech develops software. What you need is a good outreach program. Perhaps some new software could be built to assist with that, and if you're able to come up with a concrete proposal for such a tool, please do :) Unfortunately as written this is not something we can allow to go into voting, since there's no actionable from a technical standpoint. You can learn more about what this survey is for by reviewing our FAQ. Thanks for participating in the survey, nonetheless! MusikAnimal (WMF) (talk) 23:56, 12 January 2022 (UTC)

Dyslexic font

  • Problem: Dyslexic users can't read articles
  • Who would benefit: Dyslexic users
  • Proposed solution: When creating an account and in account settings, you can change the font of the Wikipedia text to a dyslexic font for dyslexic users.
  • More comments: If there already is an optional dyslexic font, ignore this
  • Phabricator tickets:
  • Proposer: Rzzor (talk) 21:08, 11 January 2022 (UTC)


At the location where the interlanguage links are located is an gear icon. Underneath it is an option to enable fetching fonts and then you can choose the "OpenDyslexic" font. This tool is called mw:Universal Language Selector So, invalid proposal, I guess.--Snævar (talk) 11:35, 12 January 2022 (UTC)

@Snævar Yeah, you're right. I think it was a good idea though. Rzzor (talk) 17:54, 12 January 2022 (UTC)

Commonist update

  • Problem: Commonist and all other similar upload tools have been non-functional for months now after some software change at the Commons, with no remedy in sight.
  • Who would benefit: All power uploaders to Commons.
  • Proposed solution: Write a small program that can do what Commonist can. Probably not rocket science, but someone needs to do this ASAP.
  • More comments:
  • Phabricator tickets: phab:T293543
  • Proposer: Anvilaquarius (talk) 08:10, 11 January 2022 (UTC)


This is a duplicate of Community Wishlist Survey 2022/Multimedia and Commons/Mass uploader * Pppery * it has begun 05:02, 12 January 2022 (UTC)

Thanks for marking my original wish as a duplicate for another one that came later... *sigh* --Anvilaquarius (talk) 08:58, 13 January 2022 (UTC)

@Anvilaquarius: I'm sorry! :-( I just figure that that one is more general but still covers the same ground. I didn't look at creation times. SWilson (WMF) (talk) 06:29, 14 January 2022 (UTC)
Neither did I. I happened to see the "Mass Uploader" proposal first. * Pppery * it has begun 22:23, 14 January 2022 (UTC)

Automatically mark stupid admins

 N Proposes a social/policy change rather than a technical feature

  • Problem: Often, precious time and efforts could be saved if admins which have previously behaved in a problematic way (e.g. not wanting to understand an issue, not following procedures, or being plain stupid and/or drunk) could be marked in some way. Then, according to the user's preferences, Mediawiki would either display their user name with yellow highlighting, not display their contributions at all.
  • Wem würde dieser Wunsch helfen: All Wikipedians, but especially non-admins.
  • Lösungsvorschlag: See above. Additionally, Mediawiki could highlight admin's user names in red if they have previously issued bans during stupid and/or drunk phases.
  • Weitere Kommentare: Not really necessary, but this proposal is both a worthy and useful one.
  • Phabricator-Tickets:
  • Antragsteller: Keimzelle (talk) 16:53, 13 January 2022 (UTC)


@Keimzelle, please don't revert MusikAnimal's edits. He's a member of the Community Tech team and he can decide to archive proposals.

In the case of this one, we think you're pointing at a social problem and suggesting a technical solution. MusikAnimal has archived your wish because this social problem doesn't necessarily require technical solutions, so it doesn't need the CommTech's work. It may begin with you changing how you think about and address to others. This proposal will stay archived. Take a look at how to make a good proposal and maybe look for problems that are technical in nature? Thanks for your understanding and participation in the Survey. SGrabarczuk (WMF) (talk) 18:48, 13 January 2022 (UTC)

@SGrabarczuk (WMF): I invest a lot of my free time, my language abilities and also my scientific expertise into Wikipedia. I have also spent countless hours fruitlessly discussing issues with administrators so that I grew extremely frustrated with them. Since more than a year I have not seen any administrator that I can entrust with making a justified, somewhat conscious and, err... sober decision. I guess I will have to discuss this issue with @MusikAnimal:, as he is the person in charge. Thankyouverylittle, --Keimzelle (talk) 19:22, 13 January 2022 (UTC)
@Keimzelle, both MusikAnimal and I are members of Community Tech. This issue is something neither of us can work on, sorry. We welcome issues that are technical in nature, though. SGrabarczuk (WMF) (talk) 19:57, 13 January 2022 (UTC)
@SGrabarczuk (WMF):, I proposed a technical solution. Username highlighting helps Wikipedia contributors to avoid interactions with problematic administrators, and thus it improves the usability of Wikipedia as a whole. We can steer clear of problematic individuals and invest much more time in fruitful collaboration. If you have any criticism regarding my proposal, I'm very happy to improve it. But if you cannot see that my proposal proposes a useful technical solution then I'm sorry for Wikipedia. It's the best social project there is, but yet dealing with Wikipedia admins is the most soul-sucking and nerve-wrecking thing I've ever experienced.--Keimzelle (talk) 21:26, 13 January 2022 (UTC)
A glance at Keimzelle's block-log will show you, he's a very problematic user, usually because of massive violations of de:WP:KPA.
Of course this is a solely social problem, and I don't think there will ever be any consensus about who to flag that way, especially as admins can be voted out of adminship if a small amount of users wants it this way. Keimzelle is currently on a destructive mission against the deWP, this is part of it. Grüße vom Sänger ♫(Reden) 05:17, 14 January 2022 (UTC)
He's just be infinited for his massive antisocial behaviour in deWP, it was overdue. Grüße vom Sänger ♫(Reden) 09:51, 14 January 2022 (UTC)

Uniformisation des commandes de base

 N Outside the scope of Community Tech

  • Problème: Difficile de contribuer sur les différentes applications de Wikimédia car les commandes wikicode ne sont pas les mêmes. Par exemple la procédure de saisie d'un ouvrage dans WP, wiktionnaire, ou wikiquote, ou wikiversité, est très différente. Cela peut rebuter les contributeurs non réguliers qui doivent "repasser le permis de conduire" pour ajouter ou modifier...
  • Qui en bénéficierait: les contributeurs en général et les non réguliers en particulier...
  • Solution proposée: Standardiser les commandes pour toutes les applications : ici dans mon exemple {Ouvrage}} et {harvsp}}
  • Autres commentaires:
  • Tâches sur Phabricator:
  • Proposant: Guy6631 (talk) 08:58, 11 January 2022 (UTC)


  • @Guy6631: Si je vous comprends bien, ce que vous demandez, ce sont des "modèles globaux". Malheureusement, nous (Community Tech) ne pouvons pas vous aider. C'est un énorme projet qui prendra des années à résoudre. La bonne nouvelle, cependant, est que WMF pourrait former une équipe pour aider à résoudre ce problème. Il faudra encore beaucoup de temps avant que cela ne soit corrigé, mais il y a de l'espoir :) Étant donné que cela n'est pas à la portée de notre équipe, je vais archiver cette proposition. Merci d'avoir participé à l'enquête ! MusikAnimal (WMF) (talk) 00:17, 14 January 2022 (UTC)

Allow option to see all dates and times as user's own time

 N Withdrawn by proposer

  • Problem: It is quite frustrating to edit from my home in the U.S. Eastern Time Zone after 7:00 pm/1900 hours (8:00 pm/2000 hours during Daylight Savings Time) and see my edits get stamped with the next day's date. It would be good to add an option in which users see all dates and times in their own time zones. Internally, all dates and times would be UTC/Greenwich Mean Time/Z Time.
  • Who would benefit: Anyone not in the same time zone as UTC/Greenwich Mean Time/Z Time.
  • Proposed solution: For logged-in users, set a preference to see all dates and times in their own time zone. Nice to have but not necessary - Choose 12-hour or 24-hour clock.
  • More comments: I have wished for this since I first discovered Wikipedia in 2006!
  • Phabricator tickets:
  • Proposer: RSLitman (talk) 20:12, 11 January 2022 (UTC)


We already have such setting for system dates in Preferences. — putnik 20:52, 11 January 2022 (UTC)
Thanks. I just found this and set it to Americas/New York. It did not affect what I am seeing on this page. I am still seeing 20:12 (8:12 pm) for the time I proposed this, which was actually at 3:12 pm. I am also seeing 23:22 (11:22 pm) for the time I am posting this reply, while it is actually 6:22 pm. (It may be a minute or so later by the time I finish and save this reply.) Would I need to exit, perhaps even log out of, Wikimedia for this to take effect. And by the way, I do want that 12-hour clock, but it's not shown as an option for me.
It turns out that I did already set this to Americas/New York on Wikipedia. Back in twenty-oh-six, this was not an option, but somewhere along the line, I learned about setting it in Preferences. I just forgot that I did so. Now I'll have to test to see if it works for me there. RSLitman (talk) 23:27, 11 January 2022 (UTC)
  • @RSLitman: verifying, you are referring to system-generated dates and times only here, not any date or time that happens to be in prose correct? If so, with the notes above, is this already resolved? — xaosflux Talk 14:18, 12 January 2022 (UTC)
    This is resolved for me. Is there a way I can delete my proposal? RSLitman (talk) 22:05, 13 January 2022 (UTC)
    @RSLitman: thanks for confirming! Someone clerking will move this to "Archived" before voting begins. Best regards, — xaosflux Talk 15:20, 14 January 2022 (UTC)

Pattypan fixing

 N Merged with Mass uploader

  • Problem: Pattypan is a very useful tool to upload images to Wikimedia Commons. It stopped working for months, returning error message login failed
  • Who would benefit: It is beneficial to anybody wishing to upload a lot of files to Wikimedia Commons. Many users depend on this tool.
  • Proposed solution: Login failed error need be fixed, a discussion to that effect is happening at github for long, but no solution arrived. Wikimedia may have to fund the process.
  • More comments: Please make a fix at the earliest, there seems no working bulk uploaders at Wikimedia Commons.
  • Phabricator tickets: phab:T293543
  • Proposer: Vinayaraj (talk) 13:47, 11 January 2022 (UTC)


From commons:Commons:Pattypan: "Pattypan has been used to upload 1,186,912 images to Wikimedia Commons which are viewed over 80 million times a month across Wikimedia projects." This tool has proven to be powerful and successful. If it is a matter of just updating software to turn it back on, then doing so would bring back the success this tool already is demonstrated to have. Blue Rasberry (talk) 01:34, 12 January 2022 (UTC)

  • Underlining the importance, there are Wikimedians In Residence, employed in museums, libraries and other partner organisations, for whom bulk-uploading images to Commons is part of their job; one which they can not do while the most appropriate tool is not working. Having this tool down for one month is bad; having it down for several months, and no suitable replacement, is actually undermining Wikimedia's relationships with partners. MartinPoulter (talk) 11:22, 12 January 2022 (UTC)
  • +1 to this, mine and everyone I know's upload projects are stopped until this is fixed. John Cummings (talk) 12:47, 12 January 2022 (UTC)
  • @Vinayaraj: You mention Please revive or patch or repair the issue with Pattypan in your Mass uploader wish as well. Does "Pattypan fixing" need to be a separate wish, then? The "Mass uploader" wish seems to be more encompassing, and is getting more input from the community, so preferably we'd redirect this page there. Is that alright with you? MusikAnimal (WMF) (talk) 23:13, 13 January 2022 (UTC)
Yes, I would like this to be redirected to the Mass uploader section, thank you.--Vinayaraj (talk) 13:53, 15 January 2022 (UTC)
I've archived this one, so please make sure Mass uploader reflects all concerns. Thanks! SWilson (WMF) (talk) 06:25, 17 January 2022 (UTC)
  • Since Pattynan no longer works (early October 2021), with a group of WP-fr users we have still continued to generate thousands of additional geographical maps with a GIS software (Geographic information system) feeded by many Open Data. These maps make it possible to illustrate several hundred Wikipedia articles for French towns. Pattypan is our best tool to easily upload all these maps into Commons. We have been stuck for more than 3 months, our project is stopped. We hope that a solution will be found soon. --Poudou99 (talk) 06:31, 15 January 2022 (UTC)

Every user on Wikimedia commons should be able to remove files, not just admins

 N Proposes a social/policy change, does not requiring engineering resources

  • Problem: Only admins are able to remove files
  • Who would benefit: Every user
  • Proposed solution: Allowing every user to remove files
  • More comments: That would be great
  • Phabricator tickets:
  • Proposer: PopperPeachesCoconut2022 (talk) 23:56, 15 January 2022 (UTC)


If commonswiki wanted to do this, they could already - they would just need to request that the "delete" permission be added to the all users group, no technical development is required. Feel free to bring this up at commons:Commons:Village pump, but there is 0% chance that commonswiki is going to approve that any user can delete every file. — xaosflux Talk 00:44, 16 January 2022 (UTC)

Yes, delete should only be done for admins, because of so many abuse potential and a lot of users can abuse this tool. I think if delete, it would need to not be used in "many" projects, you are the only contributor, or in your userspace. Thingofme (talk) 01:38, 16 January 2022 (UTC)

This request seems fairly similar to Community_Wishlist_Survey_2022/Admins_and_patrollers/Add_ability_to_delete_your_own_files_without_needing_an_admin, but obviously has worse outcomes. --Izno (talk) 00:16, 17 January 2022 (UTC)

@PopperPeachesCoconut2022: This is something that can be done with a configuration change on the wiki. It does not require any engineering work. Therefore, I will archive. As mentioned, you can request configuration change on commons:Commons:Village pump. Thanks for taking part in the survey. DWalden (WMF) (talk) 13:36, 17 January 2022 (UTC)

Making Cat-a-lot available for other changes in files

  • Problem: If you want to make the same changes in a lot of files, now you have to make these changes file by file. It may be about a mistake in the description, a licence, or a template (for the Netherlands thousands of photos of RCE are categorized with a template instead of a real category, see Category:RCE suggested categories; when I want to remove the template and change it to a real category, I have to do it file by file; I would like to get rid of all these RCE suggested categories in a two-step action per category: 1) add the right category to all the files in a RCE suggested category (already possible with Cat-a-lot) and 2) remove the template from the same files). It may, for instance, also apply to changing files with Category:County X photographs taken on yyyy-mm-dd to Date={{Taken on|jjjj-mm-dd|location=Country X}}.
  • Who would benefit: Editors
  • Proposed solution: Make a tool like Cat-a-lot, or make Cat-a-lot also available for other changes than categories. I understand that administrators of the Volunteer Response Team has a possibility to add a VRT tiket to all the files in a category, so perhaps that tool may be a base as well.
  • More comments:
  • Phabricator tickets:
  • Proposer: JopkeB (talk) 06:31, 14 January 2022 (UTC)


This sounds a lot like c:Help:VisualFileChange.js -FASTILY 07:02, 14 January 2022 (UTC)

FASTILY, Thanks a lot! Visual File Change indeed does the trick. Uptill now I only used it for deletion requests. Now I found out it can also be used for this kind of changes.
I withdrawn this proposal. JopkeB (talk) 14:01, 14 January 2022 (UTC)
I've archived it. SWilson (WMF) (talk) 14:12, 17 January 2022 (UTC)

Adding a Deletion Administrator on Commons WikiProject

 N Proposes a social/policy change, does not requiring engineering resources

  • Problem: The deletion backlog on Commons WikiProject is endless, and very less administrators compared to the backlog.
  • Who would benefit: The deletion backlog being less.
  • Proposed solution: To make a user group naming Deletion Administrator
  • More comments: There is so much deletion requests on Wikimedia Commons. Many requests go unattended for months or even years. As there are only 250 admins available and atleast 100 requests flooding everyday, it is physically impossible for admins to attend every request.

If a user group named "Deletion Administrator" is made, they will be focused on one thing and thus will reduce the backlog by a lot.


  • @Contributers2020: no software changes or technical development work is needed to do this, if the commonswiki community wants this they just need to establish a local process and consensus for it and place a request. You should follow up on this at: commons:Commons:Village pump. — xaosflux Talk 14:20, 17 January 2022 (UTC)
  • @Contributers2020: As Xaosflux mentions, this is not something that requires engineering input. Therefore, I am archiving this. Thank you for taking part in the survey. DWalden (WMF) (talk) 17:28, 17 January 2022 (UTC)

"Literals" in Citations

 N Proposes an existing solution

  • Problem: Lots of websites contain things like "|", "{", "<" or other characters in their titles or website names, but Wikipedia can't count them as an actual part of the title. This can mess up links or cause errors to appear in the syntax.

    For example, adding a vertical bar in a citation doesn't work because a vertical bar counts as Wiki syntax, so the webpage can't be shown because the link doesn't work.

  • Who would benefit: All editors of Wikipedia.
  • Proposed solution: Add "literal" indicators(There's a name for this that I forgot). For example, use something like "&137%#" to indicate a vertical bar in the title, or use "&{]5990" for a closing curly bracket as a couple of examples.
  • More comments: No point of this because {{!}} already does this.
  • Phabricator tickets:
  • Proposer: MrMeAndMrMeContributions 21:56, 11 January 2022 (UTC)


  • my experience is that VE toolbar transforms "|" to "{{!}}" for autofill fields, so a transform after Preview seems doable. .-0mtwb9gd5wx (talk) 10:48, 12 January 2022 (UTC)
  • @MrMeAndMrMe: I'd really appreciate some links to specific edits where this occurred, that makes it easy to see what is happening and maybe how to counter it. —TheDJ (talkcontribs) 11:03, 12 January 2022 (UTC)
  • Are you talking about escape sequences? You can use templates, the <nowiki> tag and HTML markup for it. For example, you can type either {{)}}, &#125; or <nowiki>}</nowiki> to insert a closing curly bracket. Kleinpecan (talk) 17:33, 13 January 2022 (UTC)
    @MrMeAndMrMe: English Wikipedia appears to be your home wiki, so the templates mentioned above like {{)}} are already at your disposal. Do these solutions work for you? MusikAnimal (WMF) (talk) 21:34, 13 January 2022 (UTC)
    Yes, Thanks. MrMeAndMrMeContributions 23:49, 13 January 2022 (UTC)
  • @MrMeAndMrMe: As there appears to be an existing solution to this problem, I am archiving. Thank you for taking part in the survey. DWalden (WMF) (talk) 18:21, 17 January 2022 (UTC)

Add admin-ability to salt article titles allowing page mover creation

 N Withdrawn by proposer

  • Problem: Currently, when article titles are create protected, they are overwhelmingly fully protected. This unnecessarily hampers the forward momentum of Wikipedia growth when lessor protection levels (while being higher than semi protection) could satisfy the need for the protection if they were available for admins to use (this applies to move protection as well). Ostensibly, the extended confirmed user group was created for similar reasons regarding edit protection just as template editor was for template protection (and they have had a positive effect). In my opinion, page movers should be available protection levels for create and move protected pages.
  • Who would benefit: Admins, by not having to perform these, often trivial, tasks, page movers by being further empowered to fulfill the task of moving pages which they are trusted to do, and the editing community at large by having more opportunities to overcome these technical restrictions.
  • Proposed solution: Allow admins the ability to choose page mover protection as a protection level when create/move protecting a page.
  • More comments: As a page mover, I, too often, see legitimate requests where the pages are create/move protected with full protection. This hampers my ability to perform the page moves I have been entrusted to perform. While some pages should clearly be fully create/move protected, many others could as easily be satisfactorily protected by page movers if it was an optional protection level for admins to choose.
  • Phabricator tickets:
  • Proposer: --John Cline (talk) 15:59, 15 January 2022 (UTC)


  • Custom protection levels can already be implemented via the Requesting wiki configuration changes process, if there is community consensus to do so. Majavah (talk!) 16:59, 15 January 2022 (UTC)
    Yes, I think this is probably something that could be done today with a simple-enough phab request and community consensus. Izno (talk) 23:31, 16 January 2022 (UTC)
  • @John Cline: additionally, as to your request, Allow admins the ability to salt titles that requires lessor user groups than admin to create - this is already possible, create protection can be set to any of the protection levels. For example see this list. — xaosflux Talk 00:59, 17 January 2022 (UTC)
    To any tech people reading this, that isn't the exact tech reasoning - just using the same terms that the requester did. — xaosflux Talk 01:00, 17 January 2022 (UTC)
    Thank you Xaosflux, for your reply and the additional information given. If not disallowed, I have modified my technical wish to align with the new information (new to me) that you provided and expanded it to include move protection as well. If the modifications are not proper, someone can close this request and I'll submit another request anew. Also, if my comments in this section are disallowed, remove them with my apologies. If my comments are allowed in this section, the internal comment in the document source that says: <!-- DO NOT EDIT BELOW THIS LINE -- DO NOT EDIT BELOW THIS LINE --> should be removed. I can imagine that others could be confused by such an internal comment as well. kind regards. --John Cline (talk) 03:37, 17 January 2022 (UTC)
    @John Cline: so yes, basically this is something that can already happen technically - I would think it is extremely unlikely that it will be done for "every WMF project" or for mediawiki core, as "page mover" (extendedmover) is a bespoke usergroup that only exists on a few WMF wikis (enwiki, enwiktionary, fawiki, urwiki). Of those, you only seem to be involved with enwiki. This will pretty much never happen as-is, so you have a couple of options:
    1. Continue discussion at w:en:Wikipedia:Village pump (proposals) along the path of "Create a new protection level on the English Wikipedia that can be used when create-protecting pages, and allow extendedmovers to edit in that level".
    2. Here, you could propose a new permission model, something along the lines of change the create-page workflow to split the permission checking to allow a new permission for overriding edit-create protection if the page does not exist and the user has access to a new permission. Once all that was done, a project could assign said new permission to a usergroup.
    Cheers, — xaosflux Talk 11:07, 17 January 2022 (UTC)
    Thanks again @Xaosflux:. Based on the things I now know, I think it would be best for the entire "wish" process for me to withdraw this request and for it to be either removed or wrapped in an appropriate manner that indicates finality and closure. I'm not familiar with the wishlist protocols so if you, or someone else could proxy that on my behalf, I'd be grateful and the process here: better served. My thanks, to all, again.--John Cline (talk) 15:33, 17 January 2022 (UTC)
    @John Cline: sure, it will get moved to "Archives" before the voting stage opens - thank you for your idea! — xaosflux Talk 15:37, 17 January 2022 (UTC)

Add a way to tell the user if he is copywrite infringing before submitting the edit

 N Technically infeasible

  • Problem: Add a way to tell the user if he is copywrite infringing before submitting the edit
  • Who would benefit: All editors of wikipedia
  • Proposed solution:
  • More comments:
  • Phabricator tickets:
  • Proposer: Omar102 (talk) 11:40, 17 January 2022 (UTC)


  • @Omar102: This is a great idea! Unfortunately, we've looked into this before and it's just not feasible to run the copyright-detecting system at the time when a page is saved. It's too time-consuming. However, we do have the CopyPatrol tool, which ensures that all edits are (after saving) checked for plagiarism. — SWilson (WMF) (talk) 02:37, 18 January 2022 (UTC)

Extend the template "Infobox data structure" to 3 columns

 N Does not requiring engineering resources

  • Problem: The template "Infobox data structure" offers the 2 columns "Average" (induced by _avg) and "Worst-case" (induced by _worst), but for some algorithms there are known 3 columns, namely also "Amortized".
  • Who would benefit: Mainly the WP-reader, because s/he would read information which is closer to the relevant literature.
  • Proposed solution: Currently available are the columns _avg and _worst, so _amort should be added. And this for all the keywords space_, search_, insert_, delete_, update_ etc. Maybe, if there are only 2 columns mentioned, e.g. _amort and _worst, it suffices to show only "Amortized" and "Worst-case". If all 3 are used, it is proposed to show "Amortized" between the other two.
  • More comments:
  • Phabricator tickets:
  • Proposer: Nomen4Omen (talk) 16:17, 12 January 2022 (UTC)


@Nomen4Omen: This does not seem like something that requires the assistance of developers, but can instead easily be implemented by anyone with some template skills on the wiki in question. Please reach out to the commnity via a talk page or via their community fora. —TheDJ (talkcontribs) 16:41, 12 January 2022 (UTC)

  • Ditto. Since there are no engineering resources needed, I am archiving the proposal. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 04:22, 18 January 2022 (UTC)

Category history

Merged with Community Wishlist Survey 2022/Categories/Improve tracking of categorization changes.

  • Problem: There is no way to see what pages were previously in a category, nor when the pages currently there were placed there.
  • Who would benefit: Anyone monitoring specific categoties.
  • Proposed solution: Create a "category history", which will allow users to see the history of wbat entered and exited the category. This won't be perfect (changes to categorization via template, lack of history before implementation), but would help in most situations.
  • More comments:
  • Phabricator tickets:
  • Proposer: Animal lover 666 (talk) 20:59, 13 January 2022 (UTC)


  • I agree that this is very practical, because there is a situation in our community, that is, "remove all the pages in the category, and then apply for deletion to delete the category page". Although it is possible to monitor the category page immediately, and then view it through "RecentChanges" or "Watchlist", it is not efficient. And if it is found vandalism, it is not easy to restore (don't know which pages were originally in this category). This requires a more convenient way to see what pages have been added or removed from categories. --Cwek (talk) 00:59, 14 January 2022 (UTC)
  • This is highly related to Community Wishlist Survey 2022/Categories/Improve tracking of categorization changes but seems to propose a solution, when it would be better to propose the problem to be solved as that one does. --Izno (talk) 02:11, 17 January 2022 (UTC)
  • Seems related to phab:T6366 from way back in the dawn of time. — xaosflux Talk 15:32, 17 January 2022 (UTC)
  • Hello there, thanks for writing this proposal! We've identified that this is a duplicate wish of Community Wishlist Survey 2022/Categories/Improve tracking of categorization changes.We are therefore archiving this one! Feel free to chime in with thoughts or improvements on the wish that has been accepted for voting when the phase begins. Thanks and regards, NRodriguez (WMF) (talk) 14:02, 18 January 2022 (UTC)

Visual Editing for talk pages and other non-mainspace pages

 N Does not require engineering resources / proposes existing feature

  • Problem: Talk pages and a lot of other namespaces only allow editing in source mode.
  • Who would benefit: People who prefer to use the Visual Editor, who can therefore use it on most non-mainspace pages.
  • Proposed solution: Allow Visual Editing on these pages.
  • More comments:
  • Phabricator tickets:
  • Proposer: Skarmory (talk) 14:15, 11 January 2022 (UTC)


Hello @Skarmory,

  1. Have you used the Discussion tools? Maybe this is a solution to the talk page part of the issue?
  2. What other namespaces do you mean? If I'm correct, it's up to the local community to decide and then request for the VE in specific namespaces.

SGrabarczuk (WMF) (talk) 14:37, 11 January 2022 (UTC)

There is also exists the Convenient Discussions (CD) gadget with the same purpose. — putnik 18:32, 11 January 2022 (UTC)
See phab:T151854 for context. As I understand it, VisualEditor simply doesn't work well on talk pages, and there's not much hope that it will. Fortunately Discussion Tools fills the need very well for many people, so do give it a try if you haven't already! These days I almost never see wikitext on talk pages thanks to Discussion Tools :)
As for enabling on specific namespaces, I believe that is up to the community to decide, provided that namespace is free of discussions. For example, VE can't (or won't) be enabled for the Wikipedia namespace on English Wikipedia because w:Wikipedia:Village Pumps and many other venues are basically talk pages. Pinging @Jdforrester (WMF): in case they have input or corrections to make to what I've said. MusikAnimal (WMF) (talk) 19:54, 11 January 2022 (UTC)
Obviously this is a call for the Editing team and not me personally. :-) Jdforrester (WMF) (talk) 00:17, 12 January 2022 (UTC)
I think VE should be used for all the content namespaces except for Template, Module, MediaWiki. And in talk namespaces, VE shouldn't be enabled, instead is the Discussion tools and the CD gadget by JWBTH. Thingofme (talk) 11:51, 13 January 2022 (UTC)
I'm going to be bold and go ahead and archive this for reasons stated above. @Skarmory If you disagree with this, please give a timely response so we can refine your proposal into something workable before the voting phase starts on January 28. Thanks! MusikAnimal (WMF) (talk) 21:28, 18 January 2022 (UTC)
I'm fine with this being archived. Sorry for the late response. Skarmory (talk) 21:44, 18 January 2022 (UTC)

RedWarn to become a gadget

 N Requires community consensus / does not require engineering resources

  • Problem: Twinkle as a helpful tool is a gadget, RedWarn is a helpful tool also but it is not a gadget.
  • Who would benefit: all editors
  • Proposed solution: making RedWarn as a gadget
  • More comments:
  • Phabricator tickets:
  • Proposer: Ctrlwiki (talk) 08:30, 15 January 2022 (UTC)


  • Yes, I agree, and Ed6767 has resigned on developing the RedWarn. Also, this is made in user scripts as Ed6767 is not an interface-admin; but hopefully some interface administrators to get this to a gadget, similar to Twinkle. Thingofme (talk) 10:23, 15 January 2022 (UTC)
  • This kind of request is one that needs community consensus but could be done today, meaning it's not in CommTech scope. --Izno (talk) 00:41, 17 January 2022 (UTC)
  • This isn't a community watchlist thing as it can be done on enwiki by opening a RFC at the appropriate village pump, nor do I speak for the current RedWarn team, however, for some background:
    We did open a proposal, but we decided against making RedWarn a gadget as we don't think the format is appropriate for something like RedWarn and would give us far less flexibility, especially in updating. One of the last things I did as part of the RedWarn team was add a one-click installer to the enwiki page, which I could argue makes it even easier to install than scrolling through a list of gadgets. Ed6767 (talk) 01:47, 17 January 2022 (UTC)
  • Moving to the archives per above. Gadgets can be added without WMF assistance, and the developers of RedWarn apparently are against the idea anyway. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 22:52, 18 January 2022 (UTC)

Access Tags on External Links

 N Does not require engineering resources

An Inaccessible Website to those who don't have a subscription
  • Problem: Citations that are only accessible through paid subscriptions or login are marked through the usage of "url-access=". This is useful as members of the community can go through and find these, subsequently fixing the problem so that members can find a more accessible source. Exernal links, however, do not have this option.
  • Who would benefit: Members of Wikipedia who will be able to find certain links more easily.
  • Proposed solution: Add syntax to Wikipedia External Links, similar to citations. An example would be this:|access=subscription
  • More comments:
  • Phabricator tickets:
  • Proposer: MrMeAndMrMeContributions 18:06, 12 January 2022 (UTC)


  • I don't think changing the MediaWiki Core syntax for external links is the right solution. Instead, your community should simply create a template to serve this purpose. For example, w:Template:URL on English Wikipedia could be changed so you call it like {{URL||access=subscription}}. MusikAnimal (WMF) (talk) 18:28, 12 January 2022 (UTC)
    I think the websites like arxiv already have their own separate templates that do this. Izno (talk) 22:04, 18 January 2022 (UTC)
  • Sites requiring a paid subscription should not be linked in the "External links" section anyway per ELREG. —Dexxor (talk) 13:01, 16 January 2022 (UTC)
    True, but also as per ELREG, there is an exception if the link is the topic of the article MrMeAndMrMeContributions 18:10, 18 January 2022 (UTC)
  • Per above, I'm going to archive this as a template-based solution would seem to make the most sense. It would also be much simpler and quicker to implement, while allowing your community to customize how you handle these URLs (for instance, you may want to put any URL with |access=subscription in a tracking category). Thanks for participating in the survey, MusikAnimal (WMF) (talk) 02:44, 19 January 2022 (UTC)

Concept of Bi-head-ral, bipolar wikitable

 N Duplicate of Community Wishlist Survey 2022/Reading/floating table headers

  • Problem: Long list needs a header repeated at less than page interval or better still a header in place (floating header with scrolling ) and the list scrolls below- a concept of bi or multiheadral table would suffice meanwhile. The printout on paper electronic pages can have a header on each page.
  • Who would benefit:
  • Proposed solution:
  • More comments: Though this is best taken up at the w:Village pump, it is listed herewith for info and the advanced Wikipedian can work on a solution Bi and Multi headral use is demonstrated in:[1]. Long list needs a header repeated at less than page interval or better still a header in place (floating header with scrolling) and the list scrolls below- a concept of bi or multi-headral table would suffice meanwhile. The printout on paper electronic pages can have a header on each page. Let the engineers work on floating header is only for viewing; for printing page length and header lines to be accommodated at each page breaks.
  • More comments:
  • Phabricator tickets: T42763
  • Proposer: Patelurology2 (talk) 20:30, 11 January 2022 (UTC)


  • That gadget link led me to gadget page and that will be explored but when people create these tables there is no freq gadget that may help with the table. The call is to automatically associate a gadget with such tables and function seamlessly in the background without looking for gadget
  • @Patelurology2: - main English Wikipedia
  • I think keeping the table header always on top of screen is extra important on mobile web/app with limited screen size, while it is also useful on desktop. C933103 (talk) 23:49, 15 January 2022 (UTC)
  • This is Community Wishlist Survey 2022/Reading/floating table headers I believe. --Izno (talk) 22:23, 18 January 2022 (UTC)
  • I'm going to archive this in favor of Community Wishlist Survey 2022/Reading/floating table headers which seems identical and is more clearly described. Please let me know if I'm missing anything, Patelurology2. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 03:45, 19 January 2022 (UTC)
  • Can have floating table for view but need header at the end also;in essence a header should print on each page of printout

@Patelurology2: - main English Wikipedia

Add more types of citations

 N Does not require engineering resources

  • Problem: Universities often release studies and thesis essays that are not published in journals, or which don't mention that they are also published in journals. This can make citing things fiddly using the manual citations templates - with the Journal template being the closest approximation. There are often valid sources that do not fit neatly into the allowed categories, making them difficult to cite using the form.
  • Who would benefit: Everyone
  • Proposed solution: Add a generic citations template, a university or organisation template, or allow us to edit the titles when posting. For example, changing "Journal" to "University". Also, if a field (such as archive URL) has a required second component (archive date) it would be good if both were added at once (though I think those should be on there by default tbh).
  • More comments:
  • Phabricator tickets:
  • Proposer: TiggyTheTerrible (talk) 11:42, 12 January 2022 (UTC)


  • @TiggyTheTerrible: There's nothing stopping you and your community from creating more templates. What software changes are you proposing that you are unable to do yourself? Perhaps you mean exposing those new templates in VisualEditor, or something else? MusikAnimal (WMF) (talk) 15:23, 12 January 2022 (UTC)
I was saying to add these to the 'Manual' part of the citations button. Are you saying there's a way for me to do that myself? TiggyTheTerrible (talk) 15:55, 12 January 2022 (UTC)
Yes and no. Yes this is configurable, but not per user, it is defined per wiki by each individual wiki (because the templates used for these citations differ on each wiki). For configuration steps see mw:VisualEditor/Citation_tool#Citation_tool_definition (add templates to VE) and mw:Citoid/Enabling_Citoid_on_your_wiki#Step_2:_Configure_Citoid (Map citoid information retrieval to template fields). —TheDJ (talkcontribs) 16:09, 12 January 2022 (UTC)
  • @TiggyTheTerrible: As mentioned, this can be done on-wiki and via configuring VE's Citation tool. I'll archive this proposal. SWilson (WMF) (talk) 04:03, 19 January 2022 (UTC)

Make Discussion pages more like proper forums

 N Proposes existing solution

  • Problem: Discussion pages, AKA talk pages, use the same Mediawiki software as articles. But discussions are not articles. Discussions do not have beginnings, middles and ends. Discussions are not documents to be perfected over time. A tool should be appropriate to the job.
  • Who would benefit: Editors.
  • Proposed solution: Adapt the wiki software used on talk pages to suit their real-life usage as discussion forums, by any means necessary. Integrate the Discussion Tools beta feature as standard. Revive the LiquidThreads project. Anything would be progress.
  • More comments: This is obviously a big wish, and unfathomably controversial among the many reflexive conservatives here. I personally believe it to be Wikipedia's original sin. A discussion is not a document, it is a discussion. To newcomers, to go to a talk page is very often to confront a mass of jumbled undifferentiated text. The indenting convention sprang up to fix the problem, but on most pages it is difficult to see the boundaries between comments - and therefore to be certain who is even talking, on a supposed "talk" page. There is no way to vote up useful comments, or get replies in one's inbox. Just an opaque wall of text and impenetrable code, accompanied by diffs - entirely appropriate to articles and inappropriate to discussions. Incidentally, this "paradigm capture" of wiki software on Wikipedia has a parallel on the Stack Exchange network, where they abuse their signature Q&A software for their own "meta" discussion pages! Talk pages are, de-facto, forums. The software used for them on Wikipedia is all but completely inappropriate. It is too late to junk and replace it, but I personally would welcome all and any improvements offered.
  • Phabricator tickets:
  • Proposer: Rollo (talk) 20:21, 16 January 2022 (UTC)


  • @Rollo: Have you tried mw:Extension:StructuredDiscussions? NguoiDungKhongDinhDanh 20:24, 16 January 2022 (UTC)
    Looks great, just like LiquidThreads. It should be integrated, not abandoned. This wishlist is for Wikipedia and its future, not for my personal needs. The solution of setting up a dev environment and a stack of software is not really a solution, unfortunately. Rollo (talk) 20:52, 16 January 2022 (UTC)
  • New Discussion Tool? --Liuxinyu970226 (talk) 14:42, 17 January 2022 (UTC)
    Also looks great! Lets integrate it. Anything at all would be an improvement. Rollo (talk) 17:58, 17 January 2022 (UTC)
    It's being integrated, just not rolled out to everyone yet. Izno (talk) 22:34, 18 January 2022 (UTC)
  • Per above, I'm going to archive this proposal. The mw:Talk pages project (aka Discussion Tools) is the official solution to this problem and will eventually be enabled for all users. MusikAnimal (WMF) (talk) 04:39, 19 January 2022 (UTC)

Somekind of linking of referred books to the

  • Problem: to made easier to readers to find info about the books referred in the articles, as could be the lybraries where to find it.
  • Who would benefit: readers who want more info about sources
  • Proposed solution: to made somekind of link to services/databases as could be or others
  • More comments:
  • Phabricator tickets:
  • Proposer: Carmallola (talk) 15:22, 12 January 2022 (UTC)Carmallola


Show a floating Search box on all pages

 N Withdrawn by proposer

  • Problem: Having to scroll to the top of the page to get at the Search window takes too much time.
  • Who would benefit: All users.
  • Proposed solution: Create a 'floating' "Search Window" that would follow the user up or down the page.' See also "Back to Top" suggestion above.
  • More comments:
  • Phabricator tickets:
  • Proposer: Shir-El too 13:28, 12 January 2022 (UTC)


  • @Shir-El too: I'm assuming you're proposing this for the default Vector skin? If so, are you aware of the Desktop Improvements project? It is a redesign of Vector that is slated to feature a sticky header with a search bar, among many other visual improvements. It's a project that you can enable into now in your Special:Preferences (uncheck "Use Legacy Vector"). Does this suit your needs?

    You might also be interested in trying out mw:Skin:Timeless, which already has a floating search bar. See here for a live example.

    If you just want to improve the old Vector, let's make that clear in the proposal. I can help if you need any. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 04:31, 13 January 2022 (UTC)

  • @MusikAnimal (WMF): Thank you for your suggestions - although I have no idea what most of them mean; I am not into programming. My thought was for something that would be usable across all Wikis by any Wiki user, a universal tool applicable to any Wiki page, with a minimum of fuss. How it would be implemented I honestly don't know. Stay Safe and Well! Cheers! Shir-El too 14:20, 13 January 2022 (UTC)
    @Shir-El too What I am trying to do is find out if the existing solutions work for you. These are already available to all wiki users, you just have to enable it. I will ask again: Does the Timeless skin work for you? Notice it has a floating search bar. You can change your skin permanently in your preferences, and for all wikis in your global preferences. If you don't like Timeless, try the new Vector (uncheck "Use Legacy Vector" in your preferences). This does not have a floating search bar yet, but it will eventually.
    If any of these solutions work for you, then there's no need for this proposal to go into voting. If you want to continue to use Legacy Vector, I'm afraid we can't offer a floating search bar for all users that is enabled by default (many people will not like this). But we could write a user script or gadget. We will need to reword the proposal to say this, which I can help you with.
    Let us know how you'd like to proceed, or if you're okay withdrawing the proposal now that you know about the existing/upcoming solutions. Best, MusikAnimal (WMF) (talk) 16:33, 13 January 2022 (UTC)
    * @MusikAnimal (WMF): I thank you for your ideas - it's just that your suggestions are almost complete 'Double Dutch' to me. Seriously. I'm guessing that you are writing about alternate versions of WP, but after trying one I decided to stick with the original. Meanwhile the community discussion here "Community Wishlist Survey 2022/Reading/Button to scroll to top of page" has come up with some simpler ideas that I'll try first. Again, Thank You for your time and effort. Stay Safe and Well!!! Shir-El too 19:36, 19 January 2022 (UTC)
    * @MusikAnimal (WMF):PS Yes, I'm OK with withdrawing the proposal. Thank You, Shir-El too 19:54, 19 January 2022 (UTC)
    Alright, with your word I will archive this as withdrawn by proposer. I'm sorry we couldn't help here. In my opinion getting used to Desktop Improvements may be worth the while. It will have many nice new features that won't be available in Legacy Vector. Anyways, thanks for participating in the survey! MusikAnimal (WMF) (talk) 19:59, 19 January 2022 (UTC)

Carry Wikipedia logon over to this Wishlist survey

 N Duplicate of Community Wishlist Survey 2022/Miscellaneous/Automatically log in to all projects if you are logged in to one

  • Problem: When I clicked on the invitation to the Wishlist Survey from a logged-in Wikipedia page, my logged-in status didn't transfer over with me. I had to do password recovery before I could log in here, by the way. Once I was in, I did check the box to remember me here.
  • Who would benefit: People who appreciate staying logged in.
  • Proposed solution: Carry the logged-in information to this section.
  • More comments:
  • Phabricator tickets:
  • Proposer: RSLitman (talk) 16:39, 11 January 2022 (UTC)


Improve visibility of proposed solutions in this survey

 N Not a technical proposal

  • Problem: Proposals in this survey have a "Who would benefit" field which interferes with the natural flow of reading the proposals.
  • Who would benefit: All users of this survey.
  • Proposed solution: Move the "Who would benefit" field below "Proposed solution".
  • More comments: Discourse has a natural issue/response (or Q and A) flow. In this survey, reading of the proposed solution, the response to the problem, is interrupted by a less significant "who would benefit" field before it. Enjoyability and ease of reading would be improved by moving this field elsewhere.
  • Phabricator tickets:
  • Proposer: Danbloch (talk) 23:33, 17 January 2022 (UTC)


  • This... this didn't need an actual proposal. --Izno (talk) 22:32, 18 January 2022 (UTC)
  • Indeed, the talk page would have been the best place to raise this. I'll bring up your idea with the team. MusikAnimal (WMF) (talk) 20:43, 19 January 2022 (UTC)

Time Machine mode

 N Technically infeasible

  • Problem: Wikipedia doesn't allow someone to easily go back and view the entirety of Wikipedia as it existed in the past
  • Who would benefit: The community, researchers
  • Proposed solution: Implement a Time Machine mode where you can choose any date in Wikipedia's existence, and any wikified link you click within articles will take you to a revision that existed on that day (if there's multiple revisions for that given day, the algorithm could just choose a random one) - integration could be made available for external links that are no longer live
  • More comments:
  • Phabricator tickets:
  • Proposer: TheNewMinistry (talk) 22:34, 11 January 2022 (UTC)


  • I don't really see the point of this and this can be fixed with the "view history" tab. There is no reason for this edition, along with the fact that Wikipedia has "nostalgia" pages for a couple of decades ago. --MrMeAndMrMeContributions 05:29, 12 January 2022 (UTC)
    @MrMeAndMrMe: not really - view history is fine for viewing the wikitext of a page at any point in time, but if the page uses anything at all external to the wikisource (images, tempaltes, wikidata integrations, etc) - you will not see what that page looked like as of a timestamp. This proposal would likely require maintaining prior rendered versions of a page (such as what can be seen in a cache). This would also require a method to delete and suppress such cached versions. — xaosflux Talk 15:39, 12 January 2022 (UTC)
    Some Common files are removed for legal reasons (copyvio, etc). These cannot be shown, so there will be holes. Links to wikipedia articles can also be problematic, as the old content can be moved or reorganized to other parts of articles. The whole environment of related articles can be different and not reproduceable.Smiley.toerist (talk) 14:45, 13 January 2022 (UTC)
    @Xaosflux I suppose that is true, but I still don't see a particular reason for this. MrMeAndMrMeContributions 18:07, 15 January 2022 (UTC)
  • Per above, I'm going to archive this proposal as it proposes an idea that is technically infeasible. Yes, with significant effort we may be able to simulate what a page looked like given a timestamp, but there are so many ways this could break or otherwise not accurately reflect what the page looked like at that time. For instance, if templates used on the page have changed since the timestamp, the software would have to know to render those older versions of the templates. Also, what if the older version of the article used a template that is now deleted? Then we'd have to surface deleted content, which is a no-no. Finally, the MediaWiki software itself and how things are rendered has changed over time, so that would somehow need to be accounted for as well. The solution? The Wayback Machine. This will accurately bring you back in time to how things look and behaved then. Of course not every version of every page has been archived, but it's as good as we'll get for this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:00, 19 January 2022 (UTC)

References to existing page in other language, instead of just showing missing page in current language

 N Withdrawn by proposer

  • Problem: Articles sometime exist in a large language (e.g. English), but are missing in a small language (e.g. Danish). When such a missing article is referenced in a small language, then the link just leads to a page for creation of the missing article This is rather useless when wanting to read about the subject. Many users can read article in multiple languages, and even seeing the images and article contents in an unknown language is often more useful than getting a page for creating an article about a subject that the reader would rather learn something about. An example is the Danish page about Apollo 11 (DA), where the article about "National Air and Space Museum" is not written yet, in which case a link to the English article at National Air and Space Museum (EN) would be useful.
  • Who would benefit: In particular readers in smaller languages, where some articles are not created yet.
  • Proposed solution: Allow creation of link to an article in another language. The Wiki system could then present a link to the top article in any language, a link to an article in a language preferred by the user.
  • More comments:
  • Phabricator tickets:
  • Proposer: MortenZdk (talk) 13:05, 17 January 2022 (UTC)


Are you aware of the interlanguage link template? en:Template:Interlanguage link? This displays both a red link (invitation to create), and a link to an article in the language specified. The foreign-language link disappeared when the article is created. The template exists in 85 languages, including in Danish. Femke (talk) 18:22, 17 January 2022 (UTC)

Thanks a lot; I was not aware of that template. I have applied it to the Danish article, and it already looks much better. That template is actually an answer to my suggestion, so I guess that I should delete my suggestion. However, I don't know how to do that, since simply deleting the text does not work (gives an warning about wrong behaviour). MortenZdk (talk) 19:22, 17 January 2022 (UTC)
It will be archived by the team sometime in the next couple weeks before voting starts. Izno (talk) 22:42, 18 January 2022 (UTC)

Stop allowing site bans to render editors ineligible to vote in WMF board elections

 N Proposes a social/policy change rather than a technical feature

  • Problem: Currently site bans render an editor ineligible to vote in WMF board elections. This is despite the growing realisation by the WMF that on some of its site – particularly smaller and outlying sites – indeffs are handed out to users who might, for example, have a disagreement with an admin, or might criticise attitudes of other editors, might be wrongly suspected of being a sockpuppet (surprisingly difficult to disprove), or take sides in political ructions such as the China–Hong Kong imbroglio and the Croation WP issue. There must be quite a few other examples.
  • Who would benefit: The whole community benefits if the WMF stops outsourcing voter eligibility to single admins on any site. Some blocks might well target vandals and others who probably are not going to make positive contributions to the movement; but we all know that blocks are multi-faceted and sometimes unjust – and typically resistant to appeal, without representation but in full public view in the manner of a show trial. It's difficult to see why editors who are blocked on one or even more than one site while having contributed and continuing to contribute positively on others for many years should be caught up in this one-size-fits-all net.
  • Proposed solution: End the criterion that denies suffrage in this way.
  • More comments:
  • Phabricator tickets:
  • Proposer: Tony (talk) 09:03, 19 January 2022 (UTC)



 N Proposer did not respond

  • Problema:
  • A quiénes beneficiaría:
  • Solución propuesta: Ayudar a los usuarios tener una mejor experiencia respecto a la ortografía y evitar las ediciones arbitrarias.
  • Más comentarios:
  • Informes de Phabricator:
  • Proponente: IDRR12345 (talk) 04:58, 11 January 2022


.CSV data upload

  • Problem: Many graphs are uploaded to Wikimedia and not updated because of lack of data
  • Proposed solution: Be able to upload a .CSV file to the Wikimedia summery section
  • Who would benefit: Everyone
  • More comments:
  • Phabricator tickets:
  • Proposer: Wikideas1 (talk) 06:47, 11 January 2022 (UTC)

 N Does not require engineering resources


mw:Extension:Graph's Vega does understand CSV, even in the version installed on WMF wikis. Whether it has access to the file system, I do not know. So, at least, that way a CSV based graph could be made.

Currently, you can make an graph from json data.--Snævar (talk) 09:53, 11 January 2022 (UTC)

  • FYI: You can also drag and drop a CSV into VE and it will automatically turn it into a wikitable. —TheDJ (talkcontribs) 12:53, 11 January 2022 (UTC)
  • FYI: And on Commons you can enabled the Tabular import/export gadget to import and export xlsx and csv into mw:Help:Tabular data.
  • @Wikideas1: Have you tried the CSV import gadget on Commons? Does this fulfil your wish? If not, could you clarify what more is required? Thanks! — SWilson (WMF) (talk) 13:02, 19 January 2022 (UTC)
I guess I’m just not smart enough to figure that out. I just wish there was a way to add data to a Wikimedia Commons document.--Wikideas1 (talk) 21:47, 19 January 2022 (UTC)
Thanks for this proposal! Let us know if you run into any trouble trying out the CSV import gadget. If it there are any difficulties while using it, those themselves could be a wish. For now, we will archive this wish since the functionality is available via that tool. Regards, NRodriguez (WMF) (talk) 12:52, 20 January 2022 (UTC)

Built - In Graphic Tools

  • Problem: To create diagrams such as maps like this one, parliament diagrams like this one, or chronological scales like the one in the infobox of Ordivician, you have to use 3rd party and often difficult to use sites that often require downloads or payment.
  • Who would benefit: More casual editors without sophisticated technical skills.
  • Proposed solution: Make built - in, simpler, more limited alternatives for sites such as Adobe Illustrator or Toolforge.
  • More comments:
  • Phabricator tickets:
  • Proposer: PtolemyXV (talk) 00:58, 11 January 2022 (UTC)


  • @PtolemyXV: As it stands, this proposal is a bit broad; would you be able to add some specific graphics tools that you feel are missing or inadequate? For example, what problems do you find with the Parliament Diagram tool (it seems to be reasonably frequently used but does have some open issues), or you could propose extending the SVG Map Maker tool to support more than just the USA. Also, I'd just note that Toolforge is not usually considered "3rd party", despite being outside the main wiki interface: it's the usual home for features that are ancillary to wiki-editing but which support that editing (perfect for things like graphics tools). Thanks! SWilson (WMF) (talk) 02:31, 11 January 2022 (UTC)
    • @SWilson (WMF): I didn't know that toolforge was associated with Wikimedia; thanks for letting me know. In that case, I would both propose that some commonly used toolforge features be integrated into the standard editing interface, and that the mapmaking and parliament tools be expanded so that they can be used in more contexts than just the US. What I'm specifically talking about, also, is that it took me quite a while to find the toolforge tools, and even longer to figure out how to connect them to Wikipedia. PtolemyXV (talk) 23:54, 11 January 2022 (UTC)
      • @PtolemyXV: Okay, great, sounds good! The Parliament Diagram tool isn't really US-centric, but perhaps there are diagram types that you wish it supported — could you list them? Or would you rather focus on the SVG Map Maker? And which specific tools need more exposure on-wiki? I guess what I'm saying is that it's best if proposals can focus on one well-defined thing (and don't forget that you can create up to five proposals!). Note also that the Toolhub now exists, as the primary catalogue of all tools. — SWilson (WMF) (talk) 06:37, 17 January 2022 (UTC)
        I'll archive this, but please feel free to create separate proposals with smaller scopes for any particular graphics tools that you think should be worked on. Thanks! SWilson (WMF) (talk) 13:00, 20 January 2022 (UTC)
  • I agree of that information; however, if we want to create maps or graphics without uploading to Commons, we need to have a template/module containing the content of the graph, and codes are very hard to write and store in articles. Thingofme (talk) 13:04, 12 January 2022 (UTC)

Improve integration with YouTube

 N Does not require engineering resources

  • Problem: YouTube enforces a limit regarding the number of requests a single IP adresses makes in a given time frame. When this limit is reached, all requests fail with an HTTP 429 error (too many requests). This causes problems for tools being hosted on toolforge as they all share a single IP address. In particular, users who try to import YouTube videos using video2commons regularly face this error, forcing them to download the video from their computer before uploading it to video2commons. It affects citoid too, preventing it to get metadata from the page to cite youtube videos in references. A phabricator ticket is stalled since May 2020 despite WMF discussions with Google.
  • Who would benefit: Anyone who wants to retrieve from YouTube a video (for Wikimedia Commons) or metadata (for Wikipedia).
  • Proposed solution: I don't have the whole picture but I can think of two solutions:
    • Sign an agreement with Google to that Wikimedia IP addresses are allowed to bypass this limit
    • Change Toolforge infrastructure to get a pool of public IP addresses, with enough of them to no longer reach the limit
  • More comments:
  • Phabricator tickets: phab:T236446, phab:T254700.
  • Proposer: Don-vip (TALK
    ) 22:15, 10 January 2022 (UTC)


  • According to phab:T236446#7363298, YouTube won't make an exception for the WMF, which is unsurprising at best, given that it's explicitly against YouTube's terms of service to rip videos from the site. Now assuming you don't care about the TOS, there are open source programs such as youtube-dl-gui and yt-dlp which make downloading videos from the site easy. -FASTILY 02:36, 12 January 2022 (UTC)
    But I think sometimes for the computers, storing a large number of videos can take up a lot of computer spaces. Thingofme (talk) 15:50, 18 January 2022 (UTC)
  • Well, phab:T236446#7363298 as Fastily points out pretty much says it all. This entirely depends on YouTube cooperating with us, which they are not. Change Toolforge infrastructure to get a pool of public IP addresses, with enough of them to no longer reach the limit There is a pool of public IP addresses (I don't have them off-hand but it is a decently sized range). I'm not sure about video2commons, but in the case of production Citoid, we gave YouTube the range and they said it was too big (phab:T254700#6359644). That suggests doing the same for Cloud Services would be futile. We can leave this proposal here for now for further input, but I don't think this should go into voting because sadly, no amount of community support will change the situation :( MusikAnimal (WMF) (talk) 23:25, 13 January 2022 (UTC)
  • @Don-vip: There is nothing the Community Tech team can do about this at this time. Therefore, I am archiving. Thank you for taking part in the survey. DWalden (WMF) (talk) 13:39, 20 January 2022 (UTC)

UploadWizard improvement

 N Functionality already exists.

  • Problem: There's no ability to set same summaries, descriptions, categories, and/or dates for files in UploadWizard. For example, I'd like to upload 30 files that are simply variants of one file and I'd like them to have the same summary, description, category, and date. I would need to go through and put in the summary, description, category, and date for each file which takes way too long! Well yes, many other file uploading tools exist, but Special:UploadWizard is official.
  • Who would benefit: People who upload lots of similar files
  • Proposed solution: On the "is this self work then select license" step in UploadWizard, add 4 checkboxes: "Give same summaries for each file", "Give same descriptions for each file", "Give same categories for each file", and "Give same dates for each file". For example, checking "Give same descriptions for each file" then going to the next step (label the files step) will only cause 1 description textbox to appear instead of one for each file. The description put in the description textbox will apply to all files.
  • More comments: Nothing
  • Phabricator tickets: No tickets
  • Proposer: Anpang01 (talk) 02:10, 11 January 2022 (UTC)


It is already possible to copy summaries, descriptions, categories, and/or dates (and more, even titles with automatic numbering) to other files in the UploadWizard. Simply click on "Apply data to all uploads below" (might be slightly different text, translation from Dutch) just under the first upload, tick the appropriate boxes and click on the button <Copy>. That is all. --JopkeB (talk) 06:19, 11 January 2022 (UTC)

  • @Anpang01: Thanks for your proposal! As JopkeB mentions, the copy-metadata feature already exists in UploadWizard. It might be that this feature isn't readily discoverable, so feel free to make a new proposal about how to make it better. Thanks. SWilson (WMF) (talk) 13:57, 20 January 2022 (UTC)

Ability to mass revert article deletion through AfC/AfD process by specific editors/administrators

 N Requires community consensus / rudimentary scripting

  • Problem: According to my memory, about 10-15 years ago, a large number of Japan-related articles on Chinese Wikipedia were deleted through Article for Deletion process, with editors/administrators involved in relevant procedures stated that their reason for proposing deletion of those articles being anti-Japan nationalism, although the official reason of those articles being submitted to AfD was their lack of notability and/or lack of sources and/or lack of third party reference. The amount of articles was too large at the time for concerned editors to pick up those articles and refurbish them according to guidelines at the time. Chinese Wikipedia guidelines have subsequently improved and adminsitrator position as well as users involved in actively editing Chinese Wikipedia have also changed as time goes, however many of the articles being deleted back then especially some of the more niche ones were still not being rewritten and they still only exists in the deletion log of the site.
  • Who would benefit: Any one who consume information from Wikipedia
  • Proposed solution: Provide a tool, to allow bureaucrat after gathering community consensus, to mass revert deletion depending on an array of conditions, for example identity of AfD proposer, the reason behind such proposal, the identity of administrator closing AfD discussion, and the stated reason behind such decision by them.
  • More comments: As I don't want to turn this into a debate of what should or should not stay in Wikipedia, the focus of this wish is to provide a tool for Bureaucrat to use it, after gathering community consensus and after definition of new rules, or after learning about factors that have influenced pass AfD processes, instead of trying to accuse anyone from actually conducting any of such events, and the intention of this wish is not to directly ask for re-installation of those deleted articles directly either, but rather the goal is to provide a tool where such option can be utilized when such situation surface.
  • Phabricator tickets:
  • Proposer: C933103 (talk) 14:15, 18 January 2022 (UTC)


This sounds like a one-time script to run, that can likely be done via the undelete API already? — xaosflux Talk 16:19, 18 January 2022 (UTC)

If this is true then I would like to withdraw this wish? Since I am not an administrator who have access to such tool to tell how they perform C933103 (talk) 13:29, 19 January 2022 (UTC)
Yes, if you create a list of pages it should be rather straightforward to mass undelete them with a rudimentary user script. This does require some engineering skills but it's so small I don't think there's a point in it going through the survey, so with your word I will archive this wish. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 16:17, 20 January 2022 (UTC)
Wait, it seems like creating a list of page, especially by proposed deletor and by the deletion reason, would be the difficult part of the task, when we are talking about multi-year worth list of AfC from decade ago. And there doesn't seems to have a clear technical way to make a list out of this other than manual sorting each items one by one. C933103 (talk) 13:22, 21 January 2022 (UTC)

Require new user to disclose their affiliation at registration/first edits

 N Requires community consensus

  • Problem: A number of users in Wikipedia are paid/affiliated contributors for some organization/companies/nations, and it would be desirable if they can disclose it themselves if those users are in such position, to reduce the chance of conflict of interest in editing went under radar
  • Who would benefit: Everyone who consume Wikipedia content.
  • Proposed solution: Add an option that ask user to state their affiliation at account creation and/or at their first editing, as well as related option in user preference, and automatically display such information at the account's user page, to indicate the nature of such account clearly.
  • More comments: It might be desirable to automatically link the claim to relevant categories in Wikipedia, and when users try to edit a page in the relevant categories, they should be presented with an additional warning, as well as have their edits be tagged by additional abuse filter. The setting should be in Global Preference by default.
  • Phabricator tickets:
  • Proposer: C933103 (talk) 04:03, 17 January 2022 (UTC)


  • This seems like a community consensus needed request. --Izno (talk) 18:58, 17 January 2022 (UTC)
    At least in English Wikipedia, w:en:Wikipedia:Paid-contribution_disclosure is a policy that must be followed by those who conduct such behavior. And the wish would merely be a way to better enable the implementation and declaration by editors falling under the category specified in such policy as required by the policy. But I guess English Wikipedia isn't representative of all wikis? Then I guess this is not appropriate for global implementation into the MediaWiki software? Although it can also be made into an optional function I guess? C933103 (talk) 13:38, 19 January 2022 (UTC)
    Telling new users to disclose their affiliation if they have such is something we could say on the login page today. That we don't should indicate there is either not a local need or want to do this, or we believe (as a community) that this will scare off editors, and so on and so forth, extrapolated to 900 some odd wikis, most of which don't have the same policy as English Wikipedia.
    Ideally, changes that come from this survey benefit every one of those. Some do and some don't, but either way, a change like this would require significantly more study and community outreach than I would prefer for this team to perform, even if I thought the change was needed (which I also don't think it is needed). Izno (talk) 22:52, 19 January 2022 (UTC)
    Then I guess I should start a RFC on this instead? But while I have previously tried to start RFC on meta, none of them gained significant discussion nor major follow up by any official actions. How to improve chance of a successful RFC? (This question is maybe a bit off topic) C933103 (talk) 13:06, 20 January 2022 (UTC)
    Indeed, this would need broader input before any engineering work could go into it. For this reason I'm going to archive this proposal as needing community consensus. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 17:45, 20 January 2022 (UTC)
    You can try picking a wiki that you are specifically interested in to see if they want to add something like this. I expect that on English Wikipedia, you would not have consensus to change the login page, so you might try somewhere else instead. Izno (talk) 05:57, 21 January 2022 (UTC)


 N Duplicate of Community Wishlist Survey 2022/Editing/Grammar editor

  • Problem: Grammatical errors and issues
  • Who would benefit: Page creators
  • Proposed solution: Make an auto correct function to correct spelling issues or punctuation
  • More comments: Not sure if it should be a bot or a new function in the editor
  • Phabricator tickets:
  • Proposer: Rzzor (talk) 22:02, 11 January 2022 (UTC)


Actually you can do it as a gadget or just for yourself. Kind of. See: We have this on plwiki as a gadget. You can add custom sequences see: #example-sequences. Obviously if want to use that for grammar or spelling then it would be very specific to a language you write in. Also not sure how would this work if you have something like 100 sequences. --Nux (talk) 23:22, 11 January 2022 (UTC)

What are sequences? Rzzor (talk) 00:34, 12 January 2022 (UTC)
  • It's like a function, a way like Grammarly or some auto-correct software. However, I think it should be a opt-in gadget for other languages, because Grammarly mostly focus in English. Thingofme (talk) 00:46, 12 January 2022 (UTC)
    Oh, ok. I just thought it would be a good idea to implement this because some users might be skeptical when downloading online, so I thought it would be easier to do it without downloading anything and having it implemented into the editor instead. I can understand that this would be hard to implement, though. Rzzor (talk) 00:50, 12 January 2022 (UTC)
  • See also Community Wishlist Survey 2022/Editing/Grammar editor. — putnik 10:18, 12 January 2022 (UTC)
  • Hello there and thanks for this proposal. As putnik mentioned, this seems to be a duplicate. I am archiving and you can follow the discussion inside Community Wishlist Survey 2022/Editing/Grammar editor Thanks for understanding and regards, NRodriguez (WMF) (talk) 18:14, 20 January 2022 (UTC)

My problem in RedWarn

 N A small bug

  • Problem: Adding editors talk page to my watchlist after I warned them, which I do not like. No rollback links in page history.
  • Who would benefit: Editors of course
  • Proposed solution: I hope there is a option that disabling userpages to watch after warning them. And there is rollback links at the page history like Twinkle
  • More comments:
  • Phabricator tickets:
  • Proposer: Ctrlwiki (talk) 08:37, 15 January 2022 (UTC)


I see you've already made these suggestions on the RedWarn talk page. Not sure what you expect Community Tech to do about it :) -FASTILY 00:25, 16 January 2022 (UTC)

Thanks for this proposal and for reporting the bugs, we are declining it since it is a smaller bug request. Thanks for understanding, NRodriguez (WMF) (talk) 18:46, 20 January 2022 (UTC)

Bot cataloger of images

 N Functionality exists

  • Problem: it is often not easy to find well-cataloged images
  • Who would benefit: anyone who wants to use them to enrich the voice with images
  • Proposed solution: It is a bot that automatically searches for images on Commons and groups and signals them to simplify their consultation and use. I know that it is not easy due to the difficulties inherent in the versions of the various languages, but in my opinion it would enhance the opportunity to decorate the page more with a graphic support.
  • More comments:
  • Phabricator tickets:
  • Proposer: ImPERtinente (talk) 23:53, 11 January 2022 (UTC)ImPERtinente


  • That sounds a whole lot like categories. H78c67c (talk) 04:58, 12 January 2022 (UTC)
  • In addition to categories, the new MediaSearch is very powerful since it uses structured data. I'm not sure building something new would be a good idea. MusikAnimal (WMF) (talk) 05:08, 12 January 2022 (UTC)
    @ImPERtinente Have you tried using categories and the new MediaSearch, as others have suggested? Asking for a bot to catalog images is a huge feat, and is better solved with the existing solutions of categories and structured data. MediaSearch is now the default search engine on Commons and in my experience works quite well. For instance, try search for red car or person holding a sign. MusikAnimal (WMF) (talk) 21:18, 13 January 2022 (UTC)
    Ok, I'll try it. Sound very interesting. Thanks a lot. ImPERtinente (talk) 23:47, 13 January 2022 (UTC)
  • Categories is similar, and we also have already got Structured data, which is a bit similar to Wikidata; so we can search contents based on Wikidata property, like MediaSearch. Thingofme (talk) 00:56, 13 January 2022 (UTC)
  • ImPERtinente: If Image A is used in 6 articles (global usage) and Image B is in 5 articles, then in a list, Image A should be first and Image B second?--Snævar (talk) 07:01, 15 January 2022 (UTC)
    Not necessarily: the use is only a statistic. I was interested in finding the data relating to a certain object or segment ImPERtinente (talk) 15:24, 15 January 2022 (UTC)
  • Per above, I'm going to archive this as the problem you describe is solved with structured data, which already exist and can be searched via commons:Special:MediaSearch. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 19:16, 20 January 2022 (UTC)

Reference importation tool, as in French Wikipedia

 N Withdrawn by proposer

  • Problem: Inserting references is too time-consuming
  • Who would benefit: All Wikipedia editors on the English site (French site already has this tool)
  • Proposed solution: Develop a tool based on the French Wikipedia site tool
  • More comments: I am very surprised to see that the English Wikipedia site is far behind the French site, technologically speaking. Not only is the French interface to edit in general more user-friendly, but most importantly, it includes a great tool to generate the reference from a publication's DOI, URL, or title (among others). I highly recommend that you take a look and develop a similar tool (conceivably, the code from the French Wikipedia site could be re-used). This is now standard in other web sites. For instance, HAL, the French "Archives ouvertes" of the CNRS, also has a similar tool. This is where French scientists are supposed to reference their publications and whenever possible, enter the unformatted drafts of their papers. See: But my point is that at least two web sites (and possibly many more) have great tools to generate references from identifying information, and the main (English) Wikipedia web site lacks this. The difference in user (editorial) experience is such that I am now reluctant to work on the English pages and prefer to concentrate on the French pages, where I don't waste my time typing or pasting information that a code could do far more efficiently than me. Please consider this request seriously!
  • Phabricator tickets:
  • Proposer: Michel Laurin (talk) 09:39, 16 January 2022 (UTC)


Example of reference insertion (Cite) toolbar of WikiEditor
Example of reference insertion (Cite) toolbar of Visual Editor
  • @Michel Laurin: Both the visual editor and the old WikiEditor have features for this. They look as presented to the right. Can you clarify how these are not satisfying your needs? —TheDJ (talkcontribs) 14:26, 16 January 2022 (UTC)
  • Response: Thanks DJ; I had not edited much in the English Wikipedia site for a while. I tried this tool and it works reasonably well. This item can be removed from the wish list.
    Per above, I'm archiving this proposal as withdrawn. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 22:18, 20 January 2022 (UTC)

Templates with editorial warning support

 N Duplicate of Better warning display for mobile users and/or Alert View

  • Problem: When displaying Wikipedia articles, service templates such as "sources are needed", "contents appear not to be neutral" and so on do not display on mobile devices
  • Who would benefit: All users who could improve the contents
  • Proposed solution: Add an option to enable the visibility of such service templates when reading an article on a mobile device
  • More comments:
  • Phabricator tickets:
  • Proposer: L736Etell me 17:49, 12 January 2022 (UTC)



 N Does not require engineering resources (machine translation: 不需要工程资源)

  • 問題: 希望可以把請求校對的條目({{proofreader needed}})照其知識領域分類
  • 有益於哪些群體: 有意願幫助校對的人
  • 提案的解決方案:
  • 更多評論:
  • Phabricator請求:
  • 提案者: 杏子雨 (talk) 15:46, 12 January 2022 (UTC)


  • Thanks for your proposal. It sounds like the required categorization can be done by editing the relevant template on-wiki, and as such it isn't necessary for this to be voted on in the wishlist survey. If you don't know about editing templates, please ask on your wiki's Village Pump. (Machine translation: 谢谢你的提议。 听起来所需的分类可以通过编辑维基上的相关模板来完成,因此没有必要在愿望清单调查中对此进行投票。 如果您不知道如何编辑模板,请在您的 wiki 的 zh:维基百科:互助客栈 上提问。) — SWilson (WMF) (talk) 03:11, 21 January 2022 (UTC)

Pings for e-mail notifications

 N Proposes existing feature

  • Problem: When someone emails a user using wikipedia they often have to leave a message on their talk page saying "You've got mail!"
  • Who would benefit: Wikipedians who use emails on their page
  • Proposed solution: A solution to this could be a ping in their notifications saying "You've got mail" instead of the person sending the notification to write that on their talk page that might not be checked often but there also needs to be a captcha check so it isn't spammed by bots and to stop spamming from others it should be limited to one email every 15-30 minutes
  • More comments: No extra comments
  • Phabricator tickets:
  • Proposer: The furret lover (talk) 20:48, 19 January 2022 (UTC)The furret lover ( aka Akari)


Disruptive edit notification watchdog

  • Problem: Some disruptive edits may go unnoticed for months or years, simply because there is no convenient means of detecting them as they occur.
  • Who would benefit: Admins and editors engaged in protecting the content of large wikis.
  • Proposed solution: Introduce a generic, user-configurable watchdog feature to obtain notification of certain types of rare edits to any page or object. This is similar to the watchlist feature, but while the watchlist feature is selective as to which pages it tracks, this watchdog is meant to be selective with respect to the types and characteristics of the edits it tracks.
  • More comments: Please see a longer write-up for more details of this proposal.
  • Phabricator tickets:
  • Proposer: SM5POR (talk) 07:49, 18 January 2022 (UTC)


  • I just found mw:Help:New filters for edit review which may help tracking changes like the one that inspired this proposal. However, I haven't had the time to find out whether it makes the entire proposal redundant, wherefore I'm not withdrawing it, but I'm leaving it in place just in case it may help improve the functionality of the filtering mechanism. --SM5POR (talk) 06:02, 19 January 2022 (UTC)
  • @SM5POR: communities can already configure many filters that check targeted, or even every, edit(s) via the Special:AbuseFilter - which produces a public log: Special:AbuseLog that editors can review. I think that takes care of most of your request? As far as getting a "notification" for such hits - that seems quite cumbersome - where would it "send" these? To all users, to all opt-in users? If a notification went to say 1000 editors, would you expect that they all spend time reviewing it? — xaosflux Talk 15:30, 20 January 2022 (UTC)
    @Xaosflux: Thank you for pointing me to the alternative solution. The AbuseFilter mechanism however appears targeted at willful abuse of a fairly frequent kind, and I haven't found out how to create such a filter yet. While my proposed watchdog might catch those cases of abuse as well, it's not them I'm looking for, but supposedly quite rare changes, more likely done by mistake than by intent.
    Take the case I wanted to report as an example. A restore is typically used to revert a recent series of bad edits in bulk I believe. It should be done swiftly in order not to destroy good edits as well. Yet there is a restore link next to the undo link on every line in the revision history. The restore I found was far from swift; for no apparent reason it hit a revision that was already eight months old, destroyed 15 good intermediate edits, and remained unnoticed for another 15 months while editors gradually cancelled out some of the effects of the restore, probably unaware that they were redoing edits already done but lost, like ants repairing an anthill for the Nth time without knowing the value of N.
    As to the notifications, they should be sent to users requesting them only. If you are looking for events happening maybe once a month in the entire wiki, you will hardly check a log file on an hourly basis (which you would have to do to attend to those cases in due time). It's just like the page-specific watchlists in that regard. If two users happen to watch the same page, then I would expect both to review the notifications they get as well. -- SM5POR (talk) 08:52, 21 January 2022 (UTC)
  • My bad -- The restore feature appears limited to Wikidata only! Then I understand why this proposal makes little sense elsewhere, and I should probably withdraw it as the remaining functionality may well be served by the AbuseFilter mechanism as suggested by @Xaosflux: (thanks for making me find out). Now, where is the "cancel" button..? --SM5POR (talk) 09:40, 21 January 2022 (UTC)
    @SM5POR: there is a category of wikidata-specific wishes, so you can just tweak it with more details and it can be moved to that category if you could still find it useful there. — xaosflux Talk 11:05, 21 January 2022 (UTC)
    That could be an option, thanks, but since the cross-platform usefulness was a significant part of my motivation for writing that proposal in the first place, it would require a major rewrite to fit the more limited Wikidata context, and I simply don't have the time to do that. Another option would be to repurpose it to add some notification feature to the Abuse filter processing, if that doesn't exist today, but same thing there, I don't have the time this weekend, and I'm not familiar enough with the filter system to do it anyway. If anybody else sees some potential use for this entry, I will gladly offer it for them to work on (if that's permissible). -- SM5POR (talk) 11:50, 21 January 2022 (UTC)
    Hello there, thanks for taking the time to write the proposal and engage in conversation! I do agree it makes sense to cancel given what you learned. Will archive this! Regards, NRodriguez (WMF) (talk) 13:23, 21 January 2022 (UTC)


 N Functionality exists

  • Проблемы: Нет качественного сервиса по визуализации исторического развития Земли
  • Кто выиграет: Люди
  • Предлагаемое решение: Создать сервис, наподобие, но на движке Вики и с меньшими ограничениями на публикацию фото
  • Дополнительные комментарии: Очень важно, чтобы ограничения были минимальными — не только архитектуры и городских пространств, как на, но и пейзажей, примечательных мест, интерьеров помещений, праздников, национальных атрибутов и т.д. И чтобы все это было привязано к карте и страницам Википедии. Возможно создание такого сервиса на базе Викимедиа.
  • Ссылка на задачу в Фабрикаторе:
  • Предложил(а): Pavljenko (talk) 12:08, 11 January 2022 (UTC)


Hello there, and thanks for taking the time to write this proposal! This request sounds a lot like the existing platform, Commons We will be archiving this wish for that reason! Thanks and regards,

Здравствуйте, и спасибо, что нашли время, чтобы написать это предложение! Этот запрос очень похож на существующую платформу Commons. По этой причине мы заархивируем это желание! спасибо и привет, NRodriguez (WMF) (talk) 13:50, 21 January 2022 (UTC)

Embeding images rather than uploading them

 N This proposal contradicts an established policy

  • Problem: Lack of creative commons images
  • Who would benefit: Readers
  • Proposed solution: Since there is a constraint on the upload of images to Wikipedia, why not simply embed the images via a link. For example, Google doesn't host images on its servers, yet when searching for a certain topic it presents images (I'm not talking about Google images) and when clicking on an image it takes you to the host website. I think Wikipedia should allow for such a feature because there is a lack of quality images with proper licensing and it will significantly improve the reading experience.
  • More comments: And maybe create a bot that deletes dead links to images or provide links.
  • Phabricator tickets:
  • Proposer: Omar.idma (talk) 10:09, 20 January 2022 (UTC)


  • This is generally not a secure practice and will likely be declined accordingly. --Izno (talk) 16:37, 20 January 2022 (UTC)
  • @Omar.idma: Thank you for participating. Unfortunately, this proposal contradicts an established policy. I'm sorry to have to archive it. DMaza (WMF) (talk) 17:19, 21 January 2022 (UTC)

Purely adding keywards on Abusefilter

 N Duplicate of Community Wishlist Survey 2022/Anti-harassment/Expose more detailed diff information to the AbuseFilter

  • Problem: For anti-vandalism, we want to create an abusefilter to check purely adding keywords on the article, which means that the keywardA is being added by the user. Currently we need to check both of added_lines and removed_lines with contains_any() (e.g. contains_any(added_lines, "keywordA", "keywordB", "keywordC") & !contains_any(removed_lines, "keywordA", "keywordB", "keywordC") or rewrite it with regex (e.g. keywords := (keywordA|keywordB|keywordC); (added_lines regex keywords) & !(removed_lines regex keywords)) to avoid false-positive because added_lines by editing "This keywardA is good" to "This keywardA is good, I am added" contains "keywardA" even though the edit does not add "keywardA". Such workarounds make our maintainance difficult, especially by not-so-technically-skilled users. Since it is very efficient and widely used for anti-vandalism, supporting easy-to-use function to check purely adding (and also removing) a keyward by abusefilter would be helpful.
  • Who would benefit: Users trying anti-vandalism
  • Proposed solution: I have two ideas. Other solution idea is also welcome.
    • The lighter one is that contains_any() supports array of keywords as its arguments (i.e. keywords := ["keywordA", "keywordB", "keywordC"]; contains_any(added_lines, keywords), which currently supports only variadic arguments contains_any(added_lines, "keywordA", "keywordB", "keywordC").
    • The other one is to implement a new variable including only purely added/removed words. Note that extracting words is a little difficult on the language which does not leave space between words (e.g. CJK). This sample is one of the simplest.
  • More comments:
  • Phabricator tickets:
  • Proposer: aokomoriuta (talk) 02:58, 12 January 2022 (UTC)


Easy switching among Wikipedia language versions of each article

 N Proposes existing feature

  • Problem: When reading an article in I often want to read the corresponding article in, which may have more complete information - as it often does when the subject is specific to that country. A direct link would be faster than redoing the search in,, etc., currently the only option.
  • Who would benefit: All Wikipedia users, especially those who are multilingual.
  • Proposed solution: Add an options drop-down at the head of each article with links to the corresponding article in other languages' Wikipedias. Ideally this should be automated so authors do not have to manually populate the drop-down for each article.
  • More comments: This is NOT a request to translate the article to another language but to link to an existing article in that language's Wikipedia, which may have different or more thorough information.
  • Phabricator tickets:
  • Proposer: Billfalls (talk) 23:02, 19 January 2022 (UTC)


  • This already exists as a list of interwiki links. You should have it in the left hand column, in new Vector at the top of the page, and in mobile a little language button. --Izno (talk) 23:23, 19 January 2022 (UTC)
    Yes @Billfalls, I also am aware of many wikis where this already works well, are you referring to any specific wiki where this isn't the case? KSiebert (WMF) (talk) 09:52, 21 January 2022 (UTC)
  • @Billfalls: If you haven't already, try unchecking "Use Legacy Vector" in your preferences (or global preferences). This will give you the new Desktop Improvements, which includes a language switcher at the top of every article just as you describe. If you prefer Legacy Vector, look towards the bottom on the sidebar on the left, and you should see a list of other Wikipedias for which the article exist. If you don't see any, then it may only be available in English. Because what you're proposing already exist, I'm going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 18:16, 21 January 2022 (UTC)

Improved math and chemistry formula insertion

 N Outside the scope of Community Tech

  • Problem: There are problems with inserting a math or chemistry formula into Wikipedia, such as the length of time it takes to write a formula or the difficulty of writing a formula with existing tools; Computing websites like Microsoft Math Solver, wolframalpha, and symbolab use several different models for inserting formulas and do not have the current problems with Wikipedia. If other modes on these sites are added to Wikipedia or Wikimedia software, the speed of writing and text correction will be very high.
  • Who would benefit: All Wikipedia users, especially editors, will benefit
  • Proposed solution:
  • More comments: It is now possible to add a formula in the Insert tab, but the simplicity and speed of working with it does not reach the level of the mentioned websites and needs to be improved.
  • Phabricator tickets:
  • Proposer: Mohammad ebz (talk) 15:35, 11 January 2022 (UTC)


  • Hello and thanks for this proposal, we are moving this to the Archive because we are unable to integrate with proprietary software when building solutions. The LaTex syntax is more common than other open source alternatives. Thanks for your time! Regards, NRodriguez (WMF) (talk) 01:43, 18 January 2022 (UTC)

"cite book" ISBN database

 N Functionality exists

  • Problem: Frequently in editing one article and having to enter all the details for a "cite book", one finds that related articles already have a "cite book" for the same book. Not only does this seem unnecessary duplication of detail, but it introduces the possibility of errors, either new or cloned.
  • Who would benefit: Anyone creating, using or maintaining a "cite book" type of entry in an article
  • Proposed solution: (Note: I'm considering this from a top-down perspective.) User interface could be, for instance, an enhanced "cite book" template or perhaps a "cite isbn" template or similar. Implementation would involve some sort of database, or perhaps an API to an external ISBN database.
  • More comments: This proposal is something like a database of books, so that the extended book information can be in a single place, referenced by multiple articles.
Instead of a user interface of:
  • "{{cite book |isbn=<ISBN> |lots... |of... |these}}" with lots of long details of authors (potentially many), authorlinks, title, publisher, year, place, etc.
one would imagine using:
  • "{{cite isbn |isbn=<ISBN> |...}}", supplemented only with this-instance details
as a higher-level version that fills in most of the details from that database-like entity.
It would, of course, still need some flexibility for details such as page numbers in particular usage-instance. For example, imagine two articles referencing the same simple book. One article might reference page 'p', another page 'q'. The first article would reference "{{cite isbn |isbn=<ISBN> |page=p}}"; the second "{{cite isbn |isbn=<ISBN> |page=q}}". Note how simple this is compared to each instance having to flesh out lots of additional detail.


  • I could see this using the Open Library API. That said, I could see a case for a database of on-wiki book citations since we would potentially have info Open Library (or any other API) doesn't track (author/editor wiki links, etc.). = paul2520 (talk) 21:49, 10 January 2022 (UTC)
  • This already exists to some degree. Using the source editor and the en:Wikipedia:RefToolbar gadget (which is enabled by default on enwiki), if you go to the Cite tab, choose "cite book" from the "Templates" drop down, fill in the ISBN, and hit the magnifying glass icon, it fills in the rest of the book details automatically. Similarly, with Visual Editor, when you hit the Cite button, you can paste in the ISBN on the "Automatic" tab and hit generate, and it will fill in the rest of the details automatically. Finally, the en:Wikipedia:Citation expander gadget can add a button to expand citations of the format {{cite book |isbn=978-1-23-456789-0}} with automatically generated data from the Google Books API. Ahecht (TALK
    ) 22:32, 10 January 2022 (UTC)
  • Not a good idea. See w:Template talk:Cite doi#RfC: Should cite doi template be deprecated?. There was a similar discussion about deprecating w:Template:Cite isbn, but it is on a currently deleted page. * Pppery * it has begun 00:04, 11 January 2022 (UTC)
  • Would a template such as {{Cite Q}} help with this? It means that most of the work's metadata can be stored on Wikidata (the "database of books" mentioned above) and still allows individual citations to add their own parameters. For example, rather than using the ISBN as the identifier, the Wikidata ID is used: {{Cite Q|Q15625490|page=42}}. SWilson (WMF) (talk) 01:20, 11 January 2022 (UTC)
@SWilson (WMF): That {{Cite Q|Q15625490|page=42}} simplicity of style looks great. But most casual editors, however, would come along with an ISBN as the desired database key. I suspect few would come with even a vague notion of a Wikidata "Q". The ready familiarity of ISBN to almost all editors would be a major advantage. Does that database offer some sort of secondary index based on ISBN? Feline Hymnic (talk) 18:02, 14 January 2022 (UTC)
@Feline Hymnic: I guess it depends on how they'd be inserting the citation. If it were via the Citoid-based automatic process, then perhaps it could find a unique ID (e.g. ISBN) and check to see if there's a matching item on Wikidata, and if there's also an appropriate citation template parameter — so, yeah, maybe there's a bit of complexity there and different options! But I'm sure we could figure out some sort of helpful thing. There are lots of discussions about this topic, of course, and they go back quite a few years. As it stands, I'd say that this proposal should be archived because we do have a database of citable works (Wikidata). Could you rewrite it a bit to focus more on some smaller part of the process? Thanks! SWilson (WMF) (talk) 13:33, 17 January 2022 (UTC)
@SWilson (WMF): Thanks for the reply. What further rewrite is needed? My proposal is from the top down. The editor-focussed interface would be something like {{cite book |isbn=978-1-23-456789-0}} or {{cite isbn |978-1-23-456789-0}} Behind the scenes it would get the data from a central database. (Perhaps, but not necessarily, this might be Wikidata. That's an implementation decision, admittedly a big one, by those who have captured the vision and are in a position to implement it.) It would probably also allow some additional data, such as page numbers, and perhaps some overrides. I hope my proposed solution and more comments above are sufficient, clear and concise; but if not, could you explain what you would like me to provide, and where, please? Thanks. Feline Hymnic (talk) 17:56, 29 January 2022 (UTC)
@Feline Hymnic: The reason this was archived this is that it looks like the crux of the problem you describe is already fixed: we do have a database of books, and a means of citing them multiple times without repeating the bulk of the information. The remaining part of this looks to be to have a way to cite via the ISBN rather than Wikidata ID, and that's what I was referring to when I said to focus on a smaller part of this. That said, there is another proposal (Accessing items with particular statements via Lua) which would enable the ISBN-lookup process to work as you describe. SWilson (WMF) (talk) 02:32, 1 February 2022 (UTC)
  • Yes, yes, and yes again. Literally the number-1 missing feature for editing Wikipedia. No hyperbole from my perspective. It is unbelievable that editors are still doing all this completely unnecessary work. This missing feature alone has put me off working on articles, again and again. Rollo (talk) 18:50, 16 January 2022 (UTC)
  • WikiCite is probably too large for CommTech. And has some obvious detractors as above. --Izno (talk) 02:20, 17 January 2022 (UTC)
  • See also WikiCite/Shared Citations.--GZWDer (talk) 21:12, 21 January 2022 (UTC)
Thanks for that link. I have just added my support there. Feline Hymnic (talk) 17:45, 29 January 2022 (UTC)

Mass adding a category

  • Problem: Going to each page, clicking edit and adding a category/categories, hitting save, repeat!
  • Who would benefit: People keeping the project tidy and organized
  • Proposed solution: One can simply select the pages to be added to the same category instantly!
  • More comments:
  • Phabricator tickets:
  • Proposer: Filipinayzd (talk) 02:02, 20 January 2022 (UTC)

 N Proposes existing solution


Cool! Thanks, it exists! --Filipinayzd (talk) 15:33, 22 January 2022 (UTC)
I'm going to take that as wish resolved! I see you messaged me on my talk page, I can follow up with you there. Best, MusikAnimal (WMF) (talk) 16:58, 22 January 2022 (UTC)

Redesign wiki software for specific needs of a dictionary

 N Merged with Adapt MediaWiki to the needs of Wiktionaries

  • Problem: Wiktionary does not dominate online the way Wikipedia does, despite its strengths in accurately documenting evolving language and despite numerous translations which cannot be found together at a single other source. (Compare our newest definitions to the random garbage at Urban Dictionary, or open up a translation section in one of our entries, and see for yourself!) This shortcoming is evident from online searches for definitions, synonyms, rhymes, or other such purposes, none of which tend to ever give hits for Wiktionary, whether looking for slang, jargon, archaic terms, or anything else. This lack of renown stems fundamentally from a design that has been pounded into the existing wiki software developed to enable discussions on long articles. These namespaces do not work well for dictionary purposes, so though editors have made do, ultimately it's the user experience that suffers. For example, it's difficult to use Wiktionary and Wiktionnaire together as a strictly French-English dictionary because of the need to jump around amidst all the clutter from other languages. Yet together the two sites are much more complete and reliable than other resources.
  • Who would benefit: New and existing users in both their native language, most importantly, and in foreign languages, most extensively.
  • Proposed solution: Re-envision what a wiki dictionary would look like from the ground up, then use that concept to propose extention or branch of the wiki software. Although its completion must combine the unilingual dictionary with translations and a phrasebook, this is not a proposal to re-imagine how dictionaries work, rather to capture the essence of a dictionary in a wiki format. For instance, the fundamental unit stems from a definition line, traditionally grouped by etymology, but there is currently no way to tie images, usage notes, or long lists of synonyms and translations to a definition in a way that's transparent within the wiki software. Consider use cases for definitions of different types of terms like newly attested slang, technical jargon, and acronyms in living languages, for quotations in and derivations from archaic languages, for synonyms, antonyms, hypernyms and such, for rhymes, for anograms and scramble searches, for translation work and language acquisition, and for whatever else falls under the scope of the project. Then consider combining all the Wiktionaries into one service, using the domain name only as a selection of the interface, and the tabs for specifically selected languages (like English and French) plus Other Languages, instead of Entry and Talk. This would in effect create much more than a dictionary, rather a single reference with unilingual dictionaries in every language. Again, the idea is not to redefine the basic tenents of a dictionary, but to establish strong traditional dictionaries first, in such a way that they can then reference each other. As this is intended to update rather than replace the existing Wiktionaries, the re-envisioning needs to occur within the Wiktionary communities themselves, but principally from a user standpoint first. If the Wiktionaries are to be combined into a single reference, then the prototype needs to derive from existing content as evidence of the feasibility of transition.
  • More comments: TL;DR This is Wiktionary. Let's replant it.


  • Phabricator tickets:
  • Proposer: DAVilla (talk) 06:29, 16 January 2022 (UTC)


  • @DAVilla: I'll archive this and link to that one in preference (that one was proposed first). SWilson (WMF) (talk) 06:34, 24 January 2022 (UTC)
  • This seems like it would go straight into the "too large" bucket. --Izno (talk) 02:47, 17 January 2022 (UTC)
    • It's true, but it can still be voted on as a way of determining importance. SWilson (WMF) (talk) 06:34, 24 January 2022 (UTC)

ALlow to link references and notes more easily

 N Duplicate of Community_Wishlist_Survey_2022/Citations/Automatic_duplicate_citation_finder

  • Problem: Many artricles have a refrences section, with the actual works, and notes, wher the works are cited with page number. It would be nice to be able to link the two automatically. So suppose I have a reference: "Foo, Bar: The Foos of Bar (..)", and I want to add a footnote, that the text cites is in that wotk on page 123, the tool should allow me to do that. If I add a second reference to the same work, say, page 234-345, I'd expect the reference to be moved to the references section, and to have two notes, with the work linked. Whether to dispaly the full reference twice, or to have a notes and a references section would then be one of the options the user could set.
  • Who would benefit: Readers/Editors of larger articles with many references
  • Proposed solution: Manage page numbers of a referenced work separately, provide logic to split the citation, if the user so desires. At the same time, provide a default setting for users without accounts.
  • More comments:
  • Phabricator tickets:
  • Proposer: Eptalon (talk) 10:18, 23 January 2022 (UTC)


Parameter to suppress notifications

  • Problem: Users may want to revert others' edits en messe, which will cause notification spam. Unwanted notifications may also caused by other edits, such as mass creation of Wikidata items.
  • Who would benefit:
  • Proposed solution: Introduce a parameter to suppress all notifications caused by this edits (including revert, ping, page link, connection with Wikidata, etc.)
  • More comments:
  • Phabricator tickets: phab:T52393
  • Proposer: GZWDer (talk) 21:00, 10 January 2022 (UTC)


  • This strikes me as potentially open to abuse. It would make malicious edits harder to detect. How would you counteract that danger? ONUnicorn (talk) 14:33, 11 January 2022 (UTC)
    I suspect this would be an user-based option, so each user would be free too choose what they follow. Strainu (talk) 08:27, 12 January 2022 (UTC)
  • Sometimes it is meaningful to revert others' edit en messe, see d:Wikidata:Edit groups.--GZWDer (talk) 14:39, 11 January 2022 (UTC)
  • Isn't this already controlled by the notification options (bottom options from Special:Preferences#mw-prefsection-echo)? If not, maybe this could be implemented by reusing the saved filters in RC and watchlist (e.g. a notification config for each saved filter).--Strainu (talk) 08:30, 12 January 2022 (UTC)
    Did you see the task I mentioned? This is a per-edit suppression of notifications, by users who will make a notification. GZWDer (talk) 12:58, 12 January 2022 (UTC)
    Ah, I misunderstood the proposal then. Letting the editor control the notifications seems indeed like a door for abuse. Of course there are many cases where notification pollution might occur, but it is far more important to have eyes on all changes.
    One solution would be to limit the feature to a few trusted users, but on Wikidata that would seriously limit its usability, since any user can do batch edits using automated tooling. Strainu (talk) 23:42, 13 January 2022 (UTC)
  • It’s not up to the users to make sure that others don’t receive spam. People decide for themself which notifications they want and which not, and that’s exactly how it should be. And as others already mentioned, there is a very high risk of abuse. Such a feature would make a devastating weapon for edit wars and would lower the inhibition towards treacherous behavior. --Nachtbold (talk) 18:07, 17 January 2022 (UTC)
  • This is what the bot flag is for, I think. --Tgr (talk) 22:05, 23 January 2022 (UTC)
  • @GZWDer: Thank you for your proposal but like others have already mentioned this feature will open a door for abuse. I'm sorry but I'm afraid I have to archive this. DMaza (WMF) (talk) 16:16, 24 January 2022 (UTC)

knowing who is following a page

 N Requires community consensus

  • Problem: sometimes there may be hundreads of people following a certain page, but there is a risk that none of them is really watching/active on wiki.
  • Who would benefit: patrollers
  • Proposed solution: when you look at page information, patrollers would be able to click on the number of page watchers and get a list of people who follow the page and people who looked at the last edits from those people.
  • More comments: the reason I believe this should be only for patrollers is for the same reason only they can see how many follow a page that has less than 30 followers-To avoid abuse of the watchlist information...
  • Phabricator tickets: phab:T6524
  • Proposer: Omer abcd (talk) 04:58, 12 January 2022 (UTC)


  • Similar proposal from last year's wishlist: Allow administrators to access the user list that watches over a particular page. SWilson (WMF) (talk) 06:58, 12 January 2022 (UTC)
  • I don't think this is good idea. There might be articles I watch, but I want nobody knows about it. Now I can see Number of page watchers = 13; Number of page watchers who visited recent edits = 5 and this is enough information. But will be useful, when patrollers can see more detailed info - without names; and when inactive watchers are not counted in (also for special:unwatched pages). JAn Dudík (talk) 07:37, 12 January 2022 (UTC)
    @JAn Dudík what exactly do you mean by "more detailed info - without names"? Strainu (talk) 08:45, 12 January 2022 (UTC)
    @Strainu: E.g. if this page was visited by watcher in last 24 hours or last week. If there was some watcher for admin/patroller usergroup. If they simply visited pages or looked to diff. I don't know how exactly this works and how is it counted, but often ahppens that some vandalism remains in frequently visited page, because nobody seen diff where was this edit made and vandalism is not easily visible. JAn Dudík (talk) 09:36, 12 January 2022 (UTC)
  • get a list of people who follow the page and people who looked at the last edits from those people is a violation of users' privacy. --Matěj Suchánek (talk) 09:33, 12 January 2022 (UTC)
  • @Omer abcd: before this very quickly gets voted down - "WHY" do you think this would be useful? What is a usecase? Say you could do this, what positive thing would you do with the information? — xaosflux Talk 15:54, 12 January 2022 (UTC)
    If I knew it, and I saw that the only ones who follow the page are not active at all on wikipedia, I know that the amount of watchers is helpless and I know I should follow the page. Maybe some followers follow a page for fun and not for patrolling it and then the amount of those who looked at the last edits is not telling the truth. There is no way to know why someone follows a page. I get the idea that this violates privacy, so maybe this abillity should work only for checkusers... Omer abcd (talk) 16:07, 12 January 2022 (UTC)
  • Omer abcd: Maybe instead of getting a list of users, get a count over how many active users are watching this page?--Snævar (talk) 07:07, 15 January 2022 (UTC)
  • @Omer abcd: Thank you for participating. As mentioned above, a similar proposal was made last year and it was not very well received for a number of reasons. I'm afraid I have to archive this. DMaza (WMF) (talk) 16:44, 24 January 2022 (UTC)

Diff finder

 N Withdrawn by proposer

  • Problem: Reports to administrative noticeboards often require many diffs of talk page posts or noticeboard comments. Finding diffs for specific content is a time-consuming process involving many clicks, particularly for prolific users and popular venues.
  • Who would benefit: Any editors initiating reports on administrative noticeboards
  • Proposed solution: A gadget which creates a "view diff" link at the end of every signed comment.
  • More comments: In an ideal world, I would be able to read a discussion on an administrative noticeboard, and click on/copy links to diffs in which each comment was added, just as I currently have the option to reply to any individual signed comment. This may not entirely eliminate the problem I describe, but it will lighten the burden considerably.
  • Phabricator tickets:
  • Proposer: Vanamonde93 (talk) 01:52, 11 January 2022 (UTC)


A tool for finding who entered specific text on a page already exists. —Ivi104 02:32, 11 January 2022 (UTC)

c:User:JWBTH/CD already exists which adds a button to view the diff and copy the permalink from the comment. (Wikiblame is more suitable for articles.) SD0001 (talk) 04:38, 11 January 2022 (UTC)

Without commenting on the usefulness of the tool itself, the logical way to implement it would be using the timestamp on each comment: transforming the timestamp into a diff link for that comment. The timestamp-based link could be used either to shorten the search for the revision (if purely a gadget) or to provide the diff link directly (if implemented as a MediaWiki feature). {{Nihiltres |talk |edits}} 06:11, 11 January 2022 (UTC)

Not sure what you mean, it's quite possible for a pure gadget as well to provide the diff directly, see example implementation in en:User:Evad37/TimestampDiffs.js. SD0001 (talk) 08:23, 11 January 2022 (UTC)

A similar tool which extends the new built-in DiscussionTools was introduced very recently: mw:Topic:Wmredg44lh8v9x9i. The link it generates after comments with signature doesn't redirect to the diff, though, but generates an anchored link within the page. Per phab:T249893, some work has also begun on adding the "thanks" button to comments which by coincidence also requires inferring the revision id from the comment. So this wish might actually be implemented into DiscussionTools (@User:PPelberg (WMF)). --Matěj Suchánek (talk) 12:54, 11 January 2022 (UTC)

phab:T249893#7605130 implies this probably will not be part of Discussion Tools. phab:T249893#7604339 does a good job at explaining how Convenient Discussions does it, and our solution would probably have to work in a similar manner. This is because a single comment could be made up of several diffs (say they made some copy edits in a subsequent edit). As mentioned above, there's also en:User:Evad37/TimestampDiffs.js. That's two gadgets that offer this functionality. Do either of these work for you, @Vanamonde93? MusikAnimal (WMF) (talk) 22:43, 20 January 2022 (UTC)
@MusikAnimal (WMF) I was unaware of both of these, thank you for pointing them out. I will try both tools, and report back. TimestampDiffs does seem to be what I'm looking for. It doesn't seem to be very commonly used (based on a what-links-here check); I do wonder if more advertising could be helpful. Vanamonde93 (talk) 17:07, 21 January 2022 (UTC)
Based on a random sampling of ~20 timestamps so far, TimestanmDiffs has the functionality that I was looking for, so thanks again for alerting me to it. Within this small sample, it has generally performed well, but has troubles with ANI comments on occasion, suggesting there may be room for improvement; nonetheless, the tool clearly exists, so perhaps I should withdraw this? Vanamonde93 (talk) 17:17, 21 January 2022 (UTC)
@Vanamonde93 The thing is, as you've noticed, inferring the revision ID from a comment is not always possible. Any tool WMF builds will come with the same caveats the existing solutions do. If you want, we can see this proposal through voting, but I don't think we'd be able to offer an "official" 100% foolproof solution. This is simply not possible due to the fragile and unstructured nature of wikitext. MusikAnimal (WMF) (talk) 19:04, 21 January 2022 (UTC)
@MusikAnimal (WMF) I do understand that, believe me, and I'm neither expecting nor asking for perfection. I suppose the important question to ask is whether WMF resources will make this a better tool, or if it's already good enough that further investment isn't worthwhile. I am not qualified to answer this, as I've neither used this tool very much nor had any coding experience of this sort. So perhaps voting on this will be helpful, and if the community indicates it isn't a priority (either because it's already good enough, or because it's just not that important), that's fine by me. I don't know how you're going to structure these proposals for a vote, but I think if this does go to a vote, the existing tools should be mentioned. Vanamonde93 (talk) 19:12, 21 January 2022 (UTC)
If you say en:User:Evad37/TimestampDiffs.js works well enough for you (and I suspect it's about as good as it will get, knowing the strength of the engineer who wrote it), then I think it's safe to archive this proposal. What we don't want is community expectation that they will get something better. Discoverability of the script would be nice, though. Pining Evad37 with a suggestion to promote it on Toolhub. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 22:25, 24 January 2022 (UTC)

Ability to find articles by what categories they are in

 N Proposes existing solution

  • Problem: There is no way to search Wikipedia articles by categories
  • Who would benefit: People who want to find articles based on a certain criteria, without having to cross reference which articles are in what category.
  • Proposed solution: A way to find articles by what categories (one or more) they are in.
  • More comments:
  • Phabricator tickets:
  • Proposer: MCMax05 (talk) 18:30, 12 January 2022 (UTC)


  • There are already petscan:.--GZWDer (talk) 21:53, 12 January 2022 (UTC)
  • @MCMax05: Per above, Petscan allows you to find articles by one or more categories that they are in. Does that satisfy your needs? If not, could you explain what else you're looking for that Petscan can't do? MusikAnimal (WMF) (talk) 21:25, 13 January 2022 (UTC)
  • And cirrussearch provides the deepcat: keyword. See mw:Help:CirrusSearch#Deepcategory. —TheDJ (talkcontribs) 23:12, 13 January 2022 (UTC)
    Or the simple incategory if you know what category you want. Izno (talk) 00:42, 17 January 2022 (UTC)
    And the deepcat search is available in the "Advanced search" section of Special:Search. the wub "?!" 16:55, 23 January 2022 (UTC)
  • Per above, I'm going archive this as there are multiple ways to accomplish what is being proposed. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 23:54, 24 January 2022 (UTC)

Cambios que usuarios ponen e inmediatamente suprimen (revierten)

 N Duplicate of Community Wishlist Survey 2022/Watchlists/Hide reverted edits

  • Problema: a veces un usuario (normalmente no registrado) realiza un cambio, e inmediatamente después lo suprime.
  • A quiénes beneficiaría: a cualquiera que sigue páginas para ver si hay cambios no pertinentes o vandalismo, para ahorrarse tiempo (no tener que ver si realmente uno quitó bien algo que antes puso, normalmente como vandalismo). Ahorro de tiempo.
  • Solución propuesta: en el caso de que alguien ponga algo e inmediatamente después lo quite, que esas dos acciones no aparezcan como cambios recientes de las páginas que uno vigila (es decir, esas dos acciones no se computen como cambios recientes)
  • Más comentarios:
  • Informes de Phabricator:
  • Proponente: Tenan (talk) 08:25, 19 January 2022 (UTC)


Need for a dev, specialized on wikisource interface... at least part time

 N Does not require engineering resources

  • Problem: many recent evolutions are incomptatible with wikisource interface, or broke the "proofreadpage" tools... Problem is that, even on big ws projects, there is generally only 1 technical volunteer admin, part time, with less and less free time (I think of @Tpt (fr) ou @Samwilson (en) or @Alex Brollo (it)) - and it is very difficult to have problems fixed, since the specific wikisource structure is difficult to comprehend.
    • examples are VisualEditor (still completely breaking Proofreadpage), Zoom recent changes, Syntax colorisation - that completely inhibits scripts that we can't do without..., recent break of Hocr (shared script), etc.
  • Who would benefit: All wikisource communities.
  • Proposed solution: Have a specialized dev', devoted (part time) to specific wikisource problems, to avoid the total breakdown of wikisource tools...
  • More comments:
  • Phabricator tickets: T224355,
  • Proposer: Hsarrazin (talk) 19:02, 16 January 2022 (UTC)


  • Hello and thanks for taking the time to write this proposal. We reviewed this proposal as a team and have determined that this is out of scope for our team because it does not ask for specific tool changes and asks for people resources. While we agree sincerely that wikisource should be better resourced, we have to archive due to the rules of what qualifies as a proposal. Thanks again! Regards, NRodriguez (WMF) (talk) 00:45, 25 January 2022 (UTC)
  • This doesn't really express a specific wish of a problem or improvement to make very well/at all. What is most problematic right now? --Izno (talk) 02:41, 17 January 2022 (UTC)
    The most problematic is that, often, the main tools of Wikisource (e.g. Proofreadpage) are modified without warning our interface admins, except via the tech news, which contains very brief and cryptic summaries of the modifications — remind that our interface admins are not coding experts! Moreover, even when these modifications succeed in solving some issue, they also often have "side effects" that developers have not foreseen, but that everyday contributors would have seen. For example, when the OCR tool was implemented on Wikisource (which is a great improvement, asked here in 2020, and I thank the Community Tech for that!), its button partly hid the scan in edition mode; another example, the zoom command have been modified recently, but it triggers bad highlighting in the scan; etc. etc. To avoid that, we would like our interface administrators to be informed with human-readable summaries when important modifications are made, and, before implementing them, our community to be invited to participate to the tests. This could be made by a specialised developer, which has thorough knowledge of Wikisource functioning. This proposal is relevant here, because the biggest modifications are often made to solve a problem raised during a Wishlist Survey (cf. the precited example of OCR tool). — ElioPrrl (talk) 13:40, 17 January 2022 (UTC)
    Yeah, this is still out of scope for CommTech then. Izno (talk) 19:27, 17 January 2022 (UTC)
    I guess you’re right but what solution do you propose when a page no more behaved as it used to. There is no revert button to regain the features we’ve lost last december or when something like Code Mirror is deployed and years after each time a newcomer asks for help to solve a sudden problem, the first thing to check is if he activated the Syntax colorisation or when an api like #wpTextbox1 is not adapted to the Page Namespace and breaks an important tool. Protection of the Wikisource environment may be out of scope but, in a user perspective, it will remain a priority. --Denis Gagne52 (talk) 18:31, 23 January 2022 (UTC)
    I totally agree with what ElioPrrl and -Denis Gagne52 said. --Zyephyrus (talk) 15:34, 29 January 2022 (UTC)


Ambiguous time-related words

 N Functionality exists

  • Problem: Words like 'now', 'recently', 'currently', 'this year', 'last year', etc. are meaningless in an encyclopedia.
  • Who would benefit: All readers who read an article several years after an edit containing ambiguous time-related words.
  • Proposed solution: After clicking 'Publish page', a warning should alert editors of ambiguous time-related words, and force return to edit mode.
  • More comments: An warning should be displayed. Example: "Your edit contains ambiguous time-related word(s), like 'now', 'recently', 'currently', 'this year', 'last year', etc., that are meaningless in an encyclopedia article, which may be read several years after your edit. Please edit the ambiguous time-related word(s) with a specific year or date."
  • Phabricator tickets:
  • Proposer: Chris goulet (talk) 07:54, 23 January 2022 (UTC)


Make enWiki templates available in deWiki as Vorlage

 N Duplicate of Editing/Having an international / cross-wiki library of templates

  • Problem: Many enWiki-templates are unavailable in deWiki or have to be used with a strange syntax.
  • Who would benefit: Every editor who works in both Wikis.
  • Proposed solution: Simply take over the complete syntax of enWiki templates to deWiki Vorlagen.
  • More comments:
  • Phabricator tickets:
  • Proposer: Nomen4Omen (talk) 08:19, 12 January 2022 (UTC)


Tracked in Phabricator:
task T121470

I'm not sure it's useful only to make en-wiki -> de-wiki convert easy, this is more like a global templates. Stryn (talk) 08:26, 12 January 2022 (UTC)

Yes; see also Phab:T121470. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits

I think this proporsal can be, "globalising some templates and modules", and they may allow some local configurations. --SolidBlock (talk) 10:10, 12 January 2022 (UTC)~

Global templates need translation, and it's like writing the code and adding some translation marks. There can be global templates, in mediawikiwiki to translate, and a bot would update it crosswiki. The documentation should say "This is a template updated from (or a site like by a bot. Do not edit this and edits/translations should be made in" Thingofme (talk) 10:36, 15 January 2022 (UTC)

This was declined in a previous survey, as it was simply too large of a project for our team. See our FAQ for more information. This is however an ideal candidate for the new Larger suggestions category, where we advertise and allow voting on wishes for other teams and the broader movement's benefit, with the understanding there's no guarantee they will be implemented. I can say with great confidence, tough, that global templates is a very much wanted feature from pretty much everyone and their entire families. There were technical conferences with lots of people wearing "Global Templates" t-shirts :) But nonetheless there's good in showing our support to express it's urgency. I just think the proposal needs some rewording, first. @Nomen4Omen: Do you mind if I reword your proposal to be more technically sound? Also pinging Amire80 in case he wants to help. Thanks, MusikAnimal (WMF) (talk) 05:27, 18 January 2022 (UTC)

As we have not heard back from Nomen4Omen, we're going to select Having an international / cross-wiki library of templates as our "Global templates" wish and will put that into the Larger suggestions category. As such I'll be archiving this proposal as a duplicate. Thanks, MusikAnimal (WMF) (talk) 04:12, 25 January 2022 (UTC)

Croping pictures from PDF & DjVu files in Wikisource without needing to re-upload them

 N Functionality exists

  • Problem:
  • Who would benefit:
  • Proposed solution:
  • More comments:
  • Phabricator tickets:
  • Proposer: AlwynapHuw (talk) 03:44, 23 January 2022 (UTC)


I don't understand computer programming any more, was a whizz at it in the 1980's, so sorry if this is a silly proposal. When I upload a DjVu or PDF file to Commons, it contains every image in the book, is there any way that the images could be extracted /cropped automatically from the pages under the same licence / description as the book upload? 03:44, 23 January 2022 (UTC)

Good proposal. I am not aware of any current auto cropper, croptool does crop pdfs and djvus with help from the user. Full page images can be linked to, like so: [[File:image name|thumb|page=pageno]]. These are the steps: 1. figuring out where the images are, 2. cropping out the empty space/text, 3. uploading the image.
This is how I see it, there are probably different methods. 1. The machine kind of knows where images are due to OCR. 2. Imagemagick, which we use, does allow to auto crop out an empty area, 3. re-uploading with same licence is defiantly possible.--Snævar (talk) 10:10, 23 January 2022 (UTC)
And oh, AlwynapHuw, please fill in the proposal. This wishlist does get translated into other languages than english, and that translation does not include the discussion.--Snævar (talk) 10:11, 23 January 2022 (UTC)
  • @AlwynapHuw: As Snævar says, extracting images from PDFs and DjVus can be done with the CropTool. This makes sure that the resulting files have the correct metadata. It doesn't detect the bounds of the images automatically, but that's usually a manual process that requires some editorial control. — SWilson (WMF) (talk) 05:35, 25 January 2022 (UTC)

Lepší vyhledávání

 N Proposal too broad

  • Problem: (English)Bad searching
    (Czech)Špatné vyhledávání
  • Who would benefit:(Czech) všichni
  • Proposed solution: (Czech) když hledám určité slovo a nevím ve kterém článku slovo je, vyhledávač ho nenajde. To samé je to s obrázky. Když chci vložit obrázek a nevím, pod čím obrázek je (např. ulice.jpg) a zadám ho jen slovem ulice, vyhledávač ho nenajde.
    (English) when I search some word and I don't know the artice where this word is, searching wouldn't find it. And the same with images. When I want to add image and I don't know the name (ulice.jpg) and write only ulice, searching wouldn't find it.

2) (Czech) Vložení mapy je zbytečně složité, co použít pro vkládání odkaz ze Seznam mapy nebo z Google mapy?
(English)Insertinhg of map is too complicated, what about to use for this ling to or ?

  • More comments:
  • Phabricator tickets:
  • Proposer: --08:36, 19 January 2022 (UTC)Mojmir13 (talk)


@Mojmir13: Vyhledávání má spoustu možností, viz též cs:Nápověda:Hledání. Můžeš lépe popsat problém, třeba tím, co se konkrétně snažíš najít a nenacházíš? JAn Dudík (talk) 10:08, 20 January 2022 (UTC)

Dobrý den, mám na mysli tohle: když třeba někdo hledá loď Francisco a zadá to do vyhledávání na české Wiki, vyhledávač to nenajde, přestože tato loď je na stránce Lodě na alternativní pohon. A když chcete vložit obrázek této lodi, nestačí zadat např. ship Francisco, ale nutno zadat název toho obrázku
na Wikimedia a to je hsc Francisco. Mojmir13 (talk) 14:05, 21 January 2022 (UTC)
@Mojmir13: při zadání "loď francisco" na české wikipedii mám ve výsledcích jako první článek cs:Lodě na alternativní pohon#Vysokorychlostní loď HSC Francisco. A pokud uložím obrázek kočky jako pes.jpg, logicky vyhledávání nic nenajde.
Ale přijde mi jako použitelná část dotazu lepší vyhledáván obrázků dle klíčového slova. Když zadám Kočka domácí, chtěl bych dostat i obrázky, které mají vyplněné depicts (P180)= house cat (Q146). JAn Dudík (talk) 20:16, 23 January 2022 (UTC)
(English): Probably this part of propoosal can be used: When I search for image with house cat, I want to have between results pictures with depicts (P180)= house cat (Q146). too. JAn Dudík (talk) 20:16, 23 January 2022 (UTC)
  • @Mojmir13: Thank you for participating. Unfortunately your proposal is too broad and for that reason I'm afraid I have to archive it. See the Community_Wishlist_Survey/FAQ for more details on our process and how to ensure your proposal have the best chance at being selected for completion. DMaza (WMF) (talk) 13:24, 25 January 2022 (UTC)

Buttons instead of links

 N Outside the scope of Community Tech and interferes with another team's work.

  • Problem: Wikimedia's projects' overall interface uses a lot of links instead of buttons
  • Who would benefit: Everyone
  • Proposed solution: Convert links to buttons
  • More comments: This is pretty straightforward: The sidebar and the topbar (?) in all Wikimedia's projects are comprised almost solely of links, at least in the Vector skin. The lack of buttons causes many new users not to use most of the links there until they gain some trust in their "wiki-abilities", which can mean many months, if not years in some cases. In many wiki-workshops I've been present, a lot of users weren't aware of the preferences tab and had never opened it before even after being an editor for quite some time, to give just an example. Buttons give the urge to press them which helps in engagement and site exploration so maybe it would be beneficial in converting many of the links mentioned above in buttons (they don't need to be necessarily icons, words can be retained).
  • Phabricator tickets:
  • Proposer: Klein Muçi (talk) 01:30, 20 January 2022 (UTC)


  • @Klein Muçi: Have you tried the new Vector skin? Is that better for you? For example, DWalden (WMF) (talk) 10:11, 25 January 2022 (UTC)
    @DWalden (WMF), I had actually forgotten about it. I remember trying it for some days and being really excited for the general upcoming changes. Then I switched back to the old version, promising myself to check it again in the future but eventually I had stopped to see updates about it around and forgot about that. Now that you mentioned it, I navigated the site a bit with that and it is very close to what I had in mind (at least in regard to the "topbar"). But... It has that mobile feel overall view that makes me uncomfortable to use it for long. (I hate to say it but I'm not a fan of the overall mobile view and I always switch to the desktop view.) Starting with the changes in regard to the top of the page and the logo, with many icons being gathered together instead of being collapsed on its own, etc. - Klein Muçi (talk) 10:54, 25 January 2022 (UTC)
  • @Klein Muçi: From what I am understanding, you would like a significant redesign of the Vector skin? I am afraid this would be out of scope for the CommTech team and would interfere with the work of the Readers Web Team, in particular the Desktop Improvements project. But, I am sure they would welcome any feedback you have. You may also be interested in the work of the Design Systems Team. I am archiving this wish. Thank you for taking part in the survey. DWalden (WMF) (talk) 14:29, 25 January 2022 (UTC)
    @DWalden (WMF), I wouldn't dare call it "a significant redesign" but thank you anyway for the links provided! Appreciated! :) - Klein Muçi (talk) 19:57, 25 January 2022 (UTC)

Button to scroll to top of page

 N Incomplete proposal / On roadmap of another team

Example of a wordpress page with a floating button in the bottom right corner to enable navigate to top op page
  • Problem: When reading long articles or specific chapters in the middle or at the bottom of such articles, I often wish to go to the top of the page to use the search field and must then scroll the whole way up.
  • Who would benefit: Every reader
  • Proposed solution: A (floating) button to scroll up to the top of the page as it appears in the low right corner of WordPress pages as soon as you scroll down a page.
  • More comments:
  • Phabricator tickets:
  • Proposer: Christian Ries (talk) 08:06, 12 January 2022 (UTC)


  • Christian Ries Hey there, thanks for submitting this proposal! Could you share screenshots of the problem and describe more details about the instances in which you find yourself wanting to navigate to the top? The details about the pain points always make a proposal stronger! NRodriguez (WMF) (talk) 04:57, 13 January 2022 (UTC)
    I was about to propose this too. If you are reading far down in a long article and want to go back to the top (say to revisit the Table of Contents or the tab bar or whatever), not every user device and/or browser has a "Home" key or similar. Where this is lacking you have to scroll, scroll, scroll back up. A "^Top" button fixed in one corner of the screen would go there instantly. A screenshot without such a button would not really illustrate the issue. Steelpillow (talk) 10:23, 14 January 2022 (UTC)

Copied from duplicate proposal at Special:PermaLink/22597779:

  • @Shir-El too: something like: w:en:Template:Skip to top and bottom perhaps? Note, while that exists as a template that could be placed on a page, it is not in the software - and for the English Wikipedia, does not have community support for use on articles currently. — xaosflux Talk 19:15, 12 January 2022 (UTC)
  • @Xaosflux: I didn't know about the template and don't know how it works - if it does. The idea is for a tool that would be available everywhere, just as the scroll-bars are, and would save some of the up-and-down schlep. Cheers! Shir-El too 21:31, 12 January 2022 (UTC)
  • @Shir-El too: I understand, look at: w:en:Wikipedia:WikiProject Academic Journals/Journals cited by Wikipedia/Num1 (bottom right corner) - just to see if this is an example of what you are proposing for all pages, or if you are thinking of something else. — xaosflux Talk 23:12, 12 January 2022 (UTC)
    I think a user script is better of doing this, enabling it for opt-in. Thingofme (talk) 11:36, 13 January 2022 (UTC)
    I just looked at the 'Academic Journals' page and it looks like a good solution. Meanwhile I'll try using the Home and End Buttons to see what happens. Thank you and Stay Safe and Well!!! Shir-El too 19:46, 19 January 2022 (UTC)
  • @MusikAnimal (WMF):, @Xaosflux: and @Thingofme: Thank you for your suggestions - although I have no idea what most of them mean; I am not into programming. My thought was for something that would be usable across all Wikis by any Wiki user, a universal tool applicable to any Wiki page, with a minimum of fuss. How it would be implemented I honestly don't know. Stay Safe and Well! Cheers! Shir-El too 14:24, 13 January 2022 (UTC)
  • @Christian Ries: I just re-read that your only problem was wanting a quick way to go to the "top of page" - the Home button on most keyboards should provide this functionality in most browsers. — xaosflux Talk 02:09, 14 January 2022 (UTC)
    Not every user device or browser UI has a "Home" function or equivalent. Steelpillow (talk) 10:23, 14 January 2022 (UTC)
  • Technical implementation: Probably the easiest way to implement this would be to add the button to the boilerplate HTML for the page wrapper. It then needs only a little CSS to position the button. (I have begun to do this on my own web site, and it works well). Steelpillow (talk) 10:23, 14 January 2022 (UTC)
    It would be necessary to make it selectable in the user Preferences, as users who do have a built-in Home function would be irritated by it. One might also consider including positioning options. Steelpillow (talk) 10:23, 14 January 2022 (UTC)
  • commons:MediaWiki:Gadget-scrollUpButton.js might help you. Copy and paste the code in your common.js. – Kwj2772 (msg) 14:37, 16 January 2022 (UTC)
    I will check in with the Web team to see if that's something they have been considering and if not why not? In any case I also feel like this could be implemented quickly with CSS. KSiebert (WMF) (talk) 10:51, 19 January 2022 (UTC)
    Dear everyone who contributed here,
    when checking in with the Web team, who would normally work on related tasks, they said it will get less necessary to work on a feature like that since we'll soon have a sticky table of contents (TOC) as a part of the UI which will allow to jump to all sections from all scroll positions. To go back to the top you could click on the first section in the TOC for example. If you are curious how this could work there's a prototype you can access here:
    Furthermore you can read about the Desktop improvements here:
    It's great to see that until we can use these new features there's a gadget to this as well. Thanks for all your efforts! To make sure we are not working on a wish that will soon be solved otherwise we will archive this wish and hope this makes sense. KSiebert (WMF) (talk) 16:20, 21 January 2022 (UTC)

Changing font and size as desired

 N Incomplete proposal / On roadmap of another team

  • Problem: Some people are dyslexic and can't read unless the text is displayed at a specific font at a specific size.
  • Who would benefit: Lots of people, especially those with dyslexia and Arabic readers (me included)
  • Proposed solution: The body text is too small in Arabic and having the option to change font size and style would improve reading experience. I think there are addons for browsers to achieve this goal but an integrated option would be nice, especially if tailored to Wikipedia.
  • More comments:
  • Phabricator tickets:
  • Proposer: Omar.idma (talk) 14:38, 20 January 2022 (UTC)


  • There are multiple ways to do this in a browser, so I don't think this would be time well-spent. --Izno (talk) 16:38, 20 January 2022 (UTC)
    Hello @Omar.idma, we think this is an interesting accessibility feature and wanted to tell you that the Web team has something on their roadmap, but they can not specify when they will be working on this together with a series of features called "reader settings". Since another will be implementing this, we sadly have to archived this wish. KSiebert (WMF) (talk) 12:40, 21 January 2022 (UTC)

Integrate Wikipedia categories into Wikidata

 N Requires community consensus

  • Problem: Current categories were created in local Wikipedia. This uncentralized situation caused lots of redundant categories and confusion in each languages, some articles was categorized into upper category and lower category at the same time, and it is impossible to deal it totally with manual fix.
  • Who would benefit: Wikidata, and all project which used category.
  • Proposed solution: There may be two solution.
  1. Create a property in Wikidata and included all categories. The category on other project will show their category with Wikidata support.
  2. Divided each current categories into structured data, and showed categories automatically if the item fulfill the definition.
For Example: Category:1911 births (Q9704085) could be translated as "date of birth" (P569) with value "1911". Thus all item with matched property and value will showed the former category automatically.
Current category on Wikipedia could also translated into structured data and imported to Wikidata either.
  • More comments:
  • Phabricator tickets:
  • Proposer: Koala0090 (talk) 06:26, 13 January 2022 (UTC)


  • The Wikidata community has plenty of tools already that solve this need. I don't see a reason to implement this request. --Izno (talk) 01:49, 17 January 2022 (UTC)
    • Maybe I didn't say it clearly enough. I mean that clear all the category tags on Wikipedia, and totally supported by Wikidata. The tools on Wikidata didn't help anything on Wikipedia's categorization. ---Koala0090 (talk) 05:58, 17 January 2022 (UTC)
      That seems more like a local community consensus needed then and to just do it. Izno (talk) 19:29, 17 January 2022 (UTC)
  • The Category tree on different languages doesn't really match. Also, sometimes people on a language choose a different category for a good reason (becaus it better fits their tree). -Eptalon (talk) 22:41, 17 January 2022 (UTC)
  • Much of the effort involved here would be gaining support for the idea itself, and we don't think the Survey is the most appropriate place for this. In addition, a large-scale replacement of traditional categories to be auto-populated by Wikidata items (where applicable) is a massive ask that by itself would be outside the scope of our team, I think. I'm happy to put this in our Larger suggestions category if you wish but I feel like this idea, as genuine and sensible as it may seem, needs broader discussion beyond what the Survey can provide. I hope that makes sense... thanks for participating in the survey, MusikAnimal (WMF) (talk) 20:54, 25 January 2022 (UTC)

Make it easier to push several pages down the category tree at the same time

 N Proposes existing solution

  • Problem: Given that many categories are overpopulated (but decent subcategories exist), it would be useful to "select" a number of pages from a category, and then move all of them down the category tree at once.
  • Who would benefit:
  • Proposed solution:
  • More comments:
  • Phabricator tickets:
  • Proposer: Eptalon (talk) 23:46, 18 January 2022 (UTC)


  • @Eptalon: I believe this is possible now with Cat-a-lot. It's quite powerful when it comes to mass-categorizing things. See commons:Help:Gadget-Cat-a-lot#Install on other projects on how to install it if it's not already available as a gadget on your wiki. Does this satisfy your wish? MusikAnimal (WMF) (talk) 22:38, 20 January 2022 (UTC)
  • I have also discovered cat-a-lot and am very satisfied with this as a helper tool to exactly the use-case of the proposer. Check it out, please! --Enyavar (talk) 10:30, 23 January 2022 (UTC)
  • @Eptalon: As time is running out and we have not heard from you, I'm going to be bold and archive this as it would seem Cat-a-lot provides the required functionality and then some. Please ping me or someone on the team if you disagree, but we must act fast as we only have three days until voting. MusikAnimal (WMF) (talk) 20:57, 25 January 2022 (UTC)

Add a way to tell the user if he is copywrite infringing before submitting the edit (duplicate)

 N Technically infeasible

  • Problem: Add a way to tell the user if he is copywrite infringing before submitting the edit
  • Who would benefit: All editors of wikipedia
  • Proposed solution:
  • More comments:
  • Phabricator tickets:
  • Proposer: Omar102 (talk) 11:39, 17 January 2022 (UTC)


  • @Omar102: What kinds of copyright infringement are you referring to? Uploading copyrighted images? Or plagiarism of text? Or something else? DWalden (WMF) (talk) 18:29, 17 January 2022 (UTC)
    Infringement is a legal term, so this may be hard - quotes or media may have fair use exceptions - it would be hard for a tool to tell if "infringement" has occurred. Best change may be "possible infringement", but interrupting the save process may be hard here as any such check will be time consuming to hold up every edit for. There are some copyvio detection bots, perhaps they could trigger some notification to the author of revisions that they tag? — xaosflux Talk 23:51, 19 January 2022 (UTC)
  • This is the same as Add a way to tell the user if he is copywrite infringing before submitting the edit. To repeat what was said there: Your proposal is a great idea, but unfortunately we've looked into this before and it's just not feasible to run the copyright-detecting system at the time when a page is saved. It's too time-consuming. However, we do have the CopyPatrol tool, which ensures that all edits are (after saving) checked for plagiarism. If CopyPatrol is not available for your language, you can request it be enabled. See CopyPatrol#Requesting new wikis for more info. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:16, 25 January 2022 (UTC)
    Err, actually this is a exact duplicate! I'll just archive under a different title. MusikAnimal (WMF) (talk) 21:18, 25 January 2022 (UTC)

Enable Citoid on all wikis

 N Does not require engineering resources

  • Problem: Citoid isn't found in many Wikis including Meitei Wikipedia (mni wiki), Assamese Wikipedia (as wiki), Fiji Hindi Wikipedia (hif wiki) and many others. Many wikis, like Simple English Wikipedia, have malfunctioning citation tools also.
  • Who would benefit: Everyone who use citation tools
  • Proposed solution: Please allow every wikis to access citation tool. And please fix the malfunction of the citation tools in the already supported wikis.
  • More comments: In Simple English Wikipedia, though the citation tool is present, it is not working for every reference links. In this Wikipedia, citation tool converter works for book reference links like links of Google Books, archive org, etc. However, the citation tool doesn't work for news links, web links, and others. For frequent citation tool users like me, we have to convert the citations from bare url to well maintained non bare url, all by manual edits. Manual edits take a lot of efforts as well as a lot of time. However, such malfunctioning of the citation tool isn't found in Arabic Wikipedia, Spanish Wikipedia, etc. as I had observed. Their citation tools can convert any links of any kind.
  • Phabricator tickets:
  • Proposer: Haoreima (talk) 16:07, 11 January 2022 (UTC)


  • @Haoreima: Which citation tool are you referring to? Do you mean Citoid that is built into VisualEditor, or w:Wikipedia:RefToolbar/2.0, or something else? Also note that there are existing tools like reFill that make it easier to convert bare URLs into references. There are issues with these tools, however, which is what the New reference-filling tool proposal is about. MusikAnimal (WMF) (talk) 17:08, 11 January 2022 (UTC)
    @MusikAnimal (WMF): According to looks, I mean this one:
    ok, a citoid. Haoreima (talk) 17:18, 11 January 2022 (UTC)
    Thanks for clarifying! I'm going to retitle your proposal and reword it to be more clear that we're talking about Citoid. By the way, phab:T294236 may effect the feasibility of this proposal, as it seems currently there is no maintainer of Citoid. Community Tech might still be able to help, though. We'll review this proposal more closely and let you know if we have any concerns. MusikAnimal (WMF) (talk) 17:22, 11 January 2022 (UTC)
    @MusikAnimal (WMF): I've had a lot of truble with the same citaiton tool @Haoreima is mentioning on Simple English Wikipedia. Got to the citation stage with students on a grade-level-wide annual Wikipedia project and discovered that both the auto citation and the webpage citation tool were broken (autocite comes back with inability to formulate citation and web page manual citation cannot offer the form at all). Led to a host of other problems with the project.
    To @Haoreima's other point, I am enthusiastic about making it easier for Wikipedians on less-populous-language Wikis to add to our global understanding of the world around us by building up content with notable topics that may be less-recognized or less-honored in en:Wiki or other more populated versions. Citation tools would absolutely help with that process.
    Thank you Castilibrary2 (talk) 15:26, 12 January 2022 (UTC)
  • Citoid is already enabled on all wikis. It just needs to be configured by the users of the wiki, see mw:Citoid/Enabling Citoid on your wiki. --Matěj Suchánek (talk) 18:14, 11 January 2022 (UTC)
    However, configuration needs to be done by an interface-admin, and some don't willing to do this. Thingofme (talk) 12:41, 12 January 2022 (UTC)
    Smaller wikis can ask Global interface administrators for assistance via Steward requests/Miscellaneous or Tech Forum. —TheDJ (talkcontribs) 16:17, 12 January 2022 (UTC)
    Anyone who can make edits in the MediaWiki namespace can configure Citoid, not just interface admins. Tgr (talk) 22:02, 23 January 2022 (UTC)
  • I have created mni: ꯃꯦꯗꯤꯌꯥꯋꯤꯀꯤ:Visualeditor-cite-tool-definition.json as user Haoreima contact me through WhatsApp. A Mangang (talk) 04:07, 13 January 2022 (UTC)
    Per above I'm going to assume this issue is now resolved as Citoid merely needed to be configured on the wiki. Please ping me if I've misunderstood. Thanks, MusikAnimal (WMF) (talk) 21:20, 25 January 2022 (UTC)

Mobile editing

 N Incomplete proposal

  • Problem: Many people are facing problem in mobile editing
  • Who would benefit: All users of wikipedia.
  • Proposed solution:
  • More comments:
  • Phabricator tickets:
  • Proposer: M. Abhilash 16:01, 22 January 2022 (UTC)


  • this really needs a better an more specific description. as it is formulated right now its just not actionable in my opinion. —TheDJ (talkcontribs) 23:05, 22 January 2022 (UTC)
  • Not enough information was provided, so we're going to archive this. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:44, 25 January 2022 (UTC)

Tool for viewing the history of a section

 N Proposes existing solution

  • Problem: While reading the article, sometimes I found wrong information or unconstructive edit. To make any changes I have to go on the page history tool. In page history, I can see the difference between the revision but it takes lot of time in doing, so I either left if I not known or do it manually.
  • Who would benefit: All editors
  • Proposed solution: Provide a tool to view history in the section or to separate the history of the page.
  • More comments:
  • Phabricator tickets:
  • Proposer: I ame shears (talk) 04:44, 11 January 2022 (UTC)


  • Looks like this could be complicated to implement. Some people open the whole page for editing to change one section, sometimes an edit spans several sections. Does VE not open the whole page every time? Are the edits saved by section? What happens when a section is renamed, or merged, or split? Does "Who wrote that" not provide similar functionality? It takes a long time to load but seems to work quite well. · · · Peter (Southwood) (talk): 07:13, 11 January 2022 (UTC)
  • @I ame shears: Could you elaborate on the problem statement? Why do you need to go to the revision history to edit? I assume, as Pbsouthwood did, that you are trying to find an edit that added some problematic content. mw:Who Wrote That?, mw:XTools/Blame and WikiBlame all offer this functionality. Additionally, I find RevisionSlider to be helpful for this, too. When viewing any diff, you should see a "Browse history interactive" panel at the top. Do any of these solutions work for you? MusikAnimal (WMF) (talk) 20:54, 11 January 2022 (UTC)
  • @I ame shears, Pbsouthwood, and MusikAnimal (WMF): My suggestion for checking edits to an article and finding malicious editing or malicious user, etc. is to add a tool in the history section to video the evolution and expansion of the article (step-by-step animated images with highlighted added text). Show the user or the administrator or ... and can stop it in any part to examine that particular part more. Mohammad ebz (talk) 14:39, 13 January 2022 (UTC)
    I think the edit history of a section is very hard. Just now, we should only see in the diff section, to see the difference between revisions. I agree with @Pbsouthwood, as this is very complicated to implement, and one edit can span cross-sections. Thingofme (talk) 07:43, 14 January 2022 (UTC)
  • @Mohammad ebz:. What would such a video/animation actually show the user in a way that would not be achieved by simply manually clicking through the diffs, which gives one time to read the changes? · · · Peter (Southwood) (talk): 07:40, 14 January 2022 (UTC)
    Increases the speed and ease of reviewing the history of article changes (meaning reviewing the entire history of an article) Mohammad ebz (talk) 14:43, 14 January 2022 (UTC)
  • The way I personally deal with this is with an offline tool, which I called "wikiblame" and can be found at . It converts the history of the article into a git repository and then one can easily navigate thru it with their favorite tool to view changes (mine is emacs with vc-annotate). Could that, or something like that, be useful here? --Jordi Burguet Castell (talk) 01:04, 23 January 2022 (UTC)
  • @I ame shears: Since we have not heard back from you, we're going to archive this proposal since it seems to propose a feature that already has multiple solutions. If you truly wanted a dedicated revision history just for a single section, I'm afraid that's also out of scope and possibly technically infeasible, as others have mentioned above. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:53, 25 January 2022 (UTC)

VisualFileChange should have a possibility for large categories

 N Does not requiring engineering resources

  • Problem: VFC shows initially only the first 100 items, with another 100 each "more"
  • Who would benefit:
  • Proposed solution: a possibility to show all items of the category/user/
  • More comments:
  • Phabricator tickets:
  • Proposer: Sarangbot (talk) 13:33, 15 January 2022 (UTC)


  • @Sarangbot and Sarang: The amount of images displayed at once can be done by changing "loadBatchSize":100 on your c:Special:MyPage/common.js under VISUAL FILE CHANGE CONFIGURATION. Not sure how recommended that is, but it is possible to increase it. Josve05a (talk) 04:24, 16 January 2022 (UTC)
  • I assume this refers to the VisualFileChange tool. I think the title should be changed to avoid confusion with the visual editor for articles, but I don't know if I can do that without messing up the wishlist. Matma Rex (talk) 02:10, 17 January 2022 (UTC)
  • @Sarangbot: As we have not heard back from you, we're going to go by our assumptions that you are talking about VisualFileChange which apparently already has a means to change the batch size (see above). Please let us know if we're misunderstanding you. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:57, 25 January 2022 (UTC)
    Sorry that I forgot to answer! I made good experiences with loadBatchSize. When I tried for a special case to set it to a high number, its maximum seems to be 500. But it works fine, thank you for the hint -- Sarangbot (talk) 16:18, 26 January 2022 (UTC)

Share script between diffrent languages.

 N Duplicate of Community Wishlist Survey 2022/Larger suggestions/Global templates and modules

  • Problem: Divide script templates between languages. Annoyed writing article English first send trying to create article in another language later. Must learn new template or create template for that language.
  • Who would benefit: All
  • Proposed solution: Share code between different wiki pages
  • More comments:
  • Phabricator tickets:
  • Proposer: Stonewall1992 (talk) 18:45, 14 January 2022 (UTC)


Category:Unidentified locations - Můžete prosím založit stejnou složku i zde na Category:Cuisine of the Czech Republic. Děkuji Pohled 111

 N Proposal not complete

  • Problémy:
  • Komu by to prospělo:
  • Navrhované řešení:
  • Více komentářů:
  • Ticket na Phabricatoru:
  • Navrhovatel: Pohled 111 (talk) 16:01, 11 January 2022 (UTC)


Cześć Pohled 111, czy możesz napisać jeszcze raz "Problémy" i "Komu by to prospělo"? SGrabarczuk (WMF) (talk) 18:49, 11 January 2022 (UTC)

Who would benefit. For those who do not know Czech cuisine perfectly. And assigns pictures somewhere else. — The preceding unsigned comment was added by Pohled 111 (talk)
  • @Pohled 111: We'll archive this for now, but if you'd like to explain more fully in the sections above please do so and we can always unarchive it. Thanks! — SWilson (WMF) (talk) 01:04, 26 January 2022 (UTC)

Connexion unique pour toutes les applications Wikimédia

 N Duplicate of Automatically log in to all projects if you are logged in to one

  • Problème: J'ai connu une époque où la saisie de mes données de connexion dans l'une quelconque des applications Wikimédia (Wikiquote par exemple) me permettait d'éviter de me connecter à l'ouverture de Wikipédia ou wiktionnaire... Depuis ce n'est plus le cas et j'enrage à chaque fois...
  • Qui en bénéficierait: Toustes les contributeurs.trices.
  • Solution proposée: retrouver la situation d'une connexion unique pour la session en cours
  • Autres commentaires:
  • Tâches sur Phabricator:
  • Proposant: Guy6631 (talk) 09:34, 11 January 2022 (UTC)


  • @Guy6631: Thanks for your proposal! This looks like it's a duplicate of an existing proposal to fix the log-in process on multiple projects. (Machine translation: Merci pour votre proposition ! Il semble qu'il s'agisse d'un doublon d'une proposition existante visant à corriger le processus de connexion sur plusieurs projets.) SWilson (WMF) (talk) 01:14, 26 January 2022 (UTC)

Donner un statut prépondérant à l'ISBN d'un ouvrage

 N Functionality exists

  • Problème: La saisie des ouvrages est très disparate. Le modèle ouvrage n'est pas systématisé. Le stock saisi est donc non harmonisé et les nouvelles saisies ne sont pas uniformisées. La situation se dégrade et se dégradera encore !!!
  • Qui en bénéficierait: Toustes les contributeurs.trices qui ont à cœur de bien saisir leurs sources et références.
  • Solution proposée: Donner à l'ISBN un statut qui permette à un robot de remettre tout en ordre dans les articles déjà saisis et modifier la prodécure de saisie des nouvelles sources et référence pour que la seule saisie de l'ISBN donne le remplissage de tous les champs utiles à partir des données de l'éditeur ou autre base de référence.
  • Autres commentaires: Former les contributeurs au modèle harvsp qui permet d'alléger le § notes et références !!!
  • Tâches sur Phabricator:
  • Proposant: Guy6631 (talk) 09:24, 11 January 2022 (UTC)


Danke fürs Sichten & Dank an IP

  • 1. Wenn man noch nicht über Sicherberechtigung verfügt, müssen andere das Sichten übernehmen. Das kann sehr zeitaufwendig sein. Diesen Sichtern würde ich gerne Danke können. UND 2. IPs kann man nicht danken:
  • Dem guten Miteinander in der Community:
  • 1. "Sichtungs-Danken"-Schaltfläche in der "Versionsgeschichte" für "Sichtungen" UND 2. in der "Versionsgeschichte" einen Zähler einfügen, wie oft es einen Dank für eine Bearbeitung gab, so dass IPs dies in der Versionsgeschichte sehen können (Sie können ja nicht benachrichtigt werden.):
  • Weitere Kommentare:
  • Phabricator-Tickets:
  • Antragsteller: Armin Krejsa (talk) 06:25, 16 January 2022 (UTC)


  • @Armin Krejsa: Leider ist dies ein mehrjähriger Vorschlag, an dem wir nicht arbeiten können. Es wurde wiederholt abgelehnt, sowohl aus technischen als auch aus sozialen Gründen. Sie können mehr darüber unter phab:T284214 lesen. Aus diesem Grund müssen wir dieses Angebot archivieren. Es tut uns leid! Vielen Dank für Ihre Teilnahme an der Umfrage (und Entschuldigung für die maschinelle Übersetzung), MusikAnimal (WMF) (talk) 02:25, 26 January 2022 (UTC)

Presencia en redes sociales para reclutar editores e instruirlos en las guías.

 N Content-creation proposal.

  • Problema: Wikipedia año con año está descendiendo en cantidad de editores.
  • A quiénes beneficiaría: Lectores y reclutas editores.
  • Solución propuesta:

Crear un canal en Youtube (En principio uno en inglés y luego más en otros idiomas) donde un personaje o una voz en off lea guías como "Wikipedia NO es" e instruya a su audiencia en neologismos como "Wikificar". Algo similar a los archivos de audio incrustados en un artículo de Wikipedia con una voz que lee el artículo en cuestión. También leería artículos calificados como "buenos", sirviendo al mismo tiempo para la divulgación de conocimiento en general pidiendo amablemente a su audiencia que aporte sus conocimientos a y así tenga nuevos artículos que narrar.

  • Más comentarios:

Se tendrá que contratar a un actor o actriz de voz para que sea la voz de wikipedia. Para ser más atractivo el proyecto se podría usar a un personaje como Wikipe-tan, aunque sugeriría cambiar el diseño del personaje para que la actriz de voz no tenga que agudizar tanto la voz y pueda entonar una voz más natural y menos exigente.


@Christian Alexis Arroyo Ortiz: Thanks for your proposal. Creating content is outside the scope of the Wishlist Survey, so I'll archive this. You might be interested in projects such as Spoken Wikipedia and Communications/Sound Logo. (Traducción automática: Gracias por tu propuesta. La creación de contenido está fuera del alcance de la Encuesta de lista de deseos, así que lo archivaré. Puede que le interesen proyectos como la Wikipedia hablada y Communications/Sound Logo.) SWilson (WMF) (talk) 03:16, 26 January 2022 (UTC)

Oh, muchas gracias por leer mi propuesta. Echaré un vistazo a esos proyectos. Tenga linda noche. Christian Alexis Arroyo Ortiz (talk) 04:34, 26 January 2022 (UTC)

Importer les données à partir du SIREN sur wikidata

 N Does not require engineering resources

  • Problème:
  • Qui en bénéficierait: French society on wikidata
  • Solution proposée:
  • Autres commentaires:
  • Tâches sur Phabricator:
  • Proposant: LibreCR (talk) 23:58, 10 January 2022 (UTC)


  • @LibreCR: Hello! We unfortunately don't generally accept content requests. You can instead use Mix'n'match or OpenRefine to bulk import data into Wikidata. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 03:21, 26 January 2022 (UTC)
    Salut! Malheureusement, nous n'acceptons généralement pas les demandes de contenu. Vous pouvez à la place utiliser Mix'n'match ou OpenRefine pour importer en masse des données dans Wikidata. Merci d'avoir participé à l'enquête, MusikAnimal (WMF) (talk) 03:21, 26 January 2022 (UTC)

Genealogy database

 N Outside the scope of Community Tech

  • Problem: Many genealogy websites compete with each other, are chargeable and do not prove filiations.
  • Who would benefit: All those interested in their genealogy will be able to benefit from the research of amateurs, and they themselves will be able to cross ascending trees and accelerate their work.
  • Proposed solution: An open database in which proof of parentage must be provided by a scanned document may link all databases. A name, few informations (limited list of information : dates, job and location), links to other names and at least one scanned document for each link.
  • More comments: Discussions will be about scanned documents interpretations, they will have to be re-written and a discussion page is mandatory. The biggest workload will be in the representation of family trees.
  • Phabricator tickets:
  • Proposer: Bertrouf (talk) 10:01, 11 January 2022 (UTC)


  • This sounds like an entire new WMF site project (wikigeneology), far outside the scope of this survey and more suited for Proposals for new projectsTheDJ (talkcontribs) 13:29, 11 January 2022 (UTC)
    • It is however meaningful to improve tools about genealogical data. See phab:T254082.--GZWDer (talk) 15:03, 11 January 2022 (UTC)
Agreed, therefore instead of asking for a "Genealogical database", I would encourage people to log ideas to implement features that would enable a genealogical database. There's a lot of features that would help, so one step at a time. Supertrinko (talk) 19:22, 11 January 2022 (UTC)
Yeah "build something big it surely will be useful" is an easy description but unlikely to succeed in the end. See Community_Wishlist_Survey/FAQ#Pick_one_specific_problem_and_describe_it_in_detail for suggestions on scoping of a wishlist item. —TheDJ (talkcontribs) 13:26, 12 January 2022 (UTC)
  • There is various discussion and information about this topic at Wikimedia genealogy project. As it stands, this doesn't sound like a proposal that is within scope — but it does sound like there might be some particular technical tasks that the Community Tech team could undertake to improve working with genealogical data on Wikimedia sites. @Bertrouf, as the others say above, this could be targetted a bit more specifically to one problem. (For example, something about Gedcom import/export on Wikidata, or family tree diagram generation, or some other small concrete tool or task…) —SWilson (WMF) (talk) 12:44, 12 January 2022 (UTC)
    I don't think importing GEDCOM is good, as they are usually unsourced. However we may research existing functions of other genealogical websites and see what feature is missing. GZWDer (talk) 12:57, 12 January 2022 (UTC)
    @GZWDer: good point about importing. Exporting to Gedcom (along with references) could be useful though. SWilson (WMF) (talk) 23:41, 12 January 2022 (UTC)
    An advanced GEDCOM import could request sources for each "fact" that is being imported from a GEDCOM. Supertrinko (talk) 09:48, 13 January 2022 (UTC)
    However it may be a challenge to convert those reference to Wikidata-readable format. GZWDer (talk) 13:15, 13 January 2022 (UTC)
  • @Bertrouf: A genealogy project would be outside of the scope of what CommTech could do. Therefore, I am archiving this. Thanks for taking part in the survey. DWalden (WMF) (talk) 15:32, 26 January 2022 (UTC)
    Thanks. Bertrouf (talk) 08:45, 27 January 2022 (UTC)

Wikimedia Commons: Add upload option to mobile website

 N Proposer did not respond

  • Problem: I contribute images through the mobile website ( from a smartphone via the mobile website (I can not download any mobile App for that purpose). When I log in with the smartphone to the mobile website there is no "upload files" button in the menu on the left
  • Who would benefit: Everybody who contributes to files to Commons with their mobile phone
  • Proposed solution: Just add a link to the regular upload pages
  • More comments:
  • Phabricator tickets:
  • Proposer: Hangman'sDeath (talk) 11:37, 18 January 2022 (UTC)


    Upload button on commons mobile
    @Hangman'sDeath: Can you be more specific, there is a giant "Upload" button on mobile commons as soon you go to the link you mentioned above. See image below, which I uploaded via commons mobile after following that link. — xaosflux Talk 15:18, 20 January 2022 (UTC)
    They mention the "menu on the left" which I assume is the hamburger flyout menu. Links there can't easily be configured there (phab:T65459), but it's still doable with JavaScript with the help of an interface admin in commons:MediaWiki:Minerva.js with something like mw.util.addPortletLink('p-navigation', '/wiki/Special:Upload', 'Upload'). There'll be a slight delay before it gets added but this should be fine because the sidebar menu isn't shown without first tapping the hamburger icon. MusikAnimal (WMF) (talk) 00:26, 21 January 2022 (UTC)
    Gothca, perhaps this user story can be further explained, maybe they want the "upload" button on more pages? If the fix is about adding to "mobile-frontend-*" menu, phab:T65459 seems like the best fix to me, and would fix any similar issues! — xaosflux Talk 15:55, 21 January 2022 (UTC)

Alcaldes de España

 N Functionality exists

  • Problema: Cuando se celebran elecciones en España cada uno de los más de 7000 municipios elige a un nuevo alcalde. El Instituto Nacional de Estadística publica un archivo que lo incluye en cada provincia. Se incluye el código de identificación del municipio, también incluido en Wikidata. A simple vista se podría automatizar la tarea. Me parece que para la revisión anual del padrón el dato lo incorpora un bot. Opinión al respecto del usuario Strakhov: Supongo que habrá que usar OpenRefine y/o Quickstatements?
  • A quiénes beneficiaría: lectores de España
  • Solución propuesta:
  • Más comentarios:
  • Informes de Phabricator:
  • Proponente: Hampcky (talk) 18:53, 17 January 2022 (UTC)


Hola y gracias por tomarte el tiempo de escribir esta propuesta. Estamos archivando este deseo debido a la falta de aclaración. Necesitábamos una aclaración para que pudiéramos aceptar este deseo y marcarlo para su traducción para que pudiera someterse a votación. ¡Gracias de nuevo! Saludos, NRodriguez (WMF) (talk) 18:21, 26 January 2022 (UTC)

Nested numbering / enumerating

 N Does not require engineering resources

  • בעיה: אין קינון ברשימות ממוספרות
  • מי ירוויח מההצעה: כולם, בייחוד ערכים בתחומי המדע, ההנדסה, הטכנולוגיה, האלגוריתמיקה והמשפטים
  • הצעת פתרון: יצירת קינון ברשימות ממוספרות (סעיף 1, סעיף 1.1, סעיף 1.2, סעיף 1.3, סעיף 2, סעיף 2.1 וכו'
  • הערות נוספות:
  • כרטיסים בפבריקטור:
  • מציע: MathKnight (talk) 15:55, 23 January 2022 (UTC)


  • The style of bulleted list items can be changed with CSS. See for example of how to do this. You can change it in your common.css or in your global.css to make it take effect on all wikis. Because this does not requiring engineering resources from WMF, we're going to archive this proposal. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 20:48, 26 January 2022 (UTC)
    עִברִית: ניתן לשנות את הסגנון של פריטי רשימה עם תבליטים באמצעות CSS. ראה לדוגמא כיצד לעשות זאת. אתה יכול לשנות את זה ב-common.css שלך או ב-global.css שלך כדי שזה ייכנס לתוקף בכל ה-Wiki. מכיוון שזה לא מצריך משאבים הנדסיים מ-WMF, אנחנו הולכים לאחסן את ההצעה הזו. תודה על ההשתתפות בסקר! MusikAnimal (WMF) (talk) 20:48, 26 January 2022 (UTC)

Built in google engine to find citations

 N Proposer did not respond

  • Problem: To avoid having to leave a Wikipedia article to find a source for an article in the chance that you might close the article, lose connection, or it refreshes the page on its own.
  • Who would benefit: Any editor, especially those who are interested in including lots of citations in articles.
  • Proposed solution: A search engine built into the wiki editor that lets you find citations by searching.
  • More comments:
  • Phabricator tickets:
  • Proposer: SoyokoAnis (talk) 12:47, 11 January 2022 (UTC)


  • It's not clear to me how this would work because you'd need more than just search engine results; you'd need to actually read those web pages and make sure they support the claim you're trying to make. How would you view those pages without leaving the article? It would seem simply opening a new tab to do your research is the easiest workflow. @SoyokoAnis: Could you elaborate a little more on what you had in mind? MusikAnimal (WMF) (talk) 14:46, 11 January 2022 (UTC)
  • I sort of have an idea of how this would work (I'm not the one who made this proposal) but I think it would be very complicated to implement. I'm thinking it would just bring up an overlay of some kind that is basically a browser you can use to find citations for Wikipedia and also look at the pages to see if they support the claim. There may need to be some kind of limitation to this (Such as a blacklist for websites you can't visit such as ones that are considered deprecated sources) to prevent someone from abusing it if it can be implemented. Overall I don't see how just opening up a new tab to find citations is an issue in the first place (the user said, "In the chance you might close the article, lose connection, or refreshes its page on its own", however this wouldn't really solve any of those issues since if you close the article, then you are still losing the work you did, if you lose connection same thing, if it refreshes, same thing). Blaze Wolf (talk) 18:27, 11 January 2022 (UTC)
  • To see whether a website is a reliable source or not, I think we need to open another tab (I agree with Blaze Wolf). Or, most of the people write texts on the Draft, or the page, or saving them to prevent errors. Thingofme (talk) 00:50, 12 January 2022 (UTC)
    en:User:Syced/Wikipedia Reference Search? Shizhao (talk) 02:56, 12 January 2022 (UTC)
  • @SoyokoAnis: Since we have not heard back from you and your proposal is unclear as written, we're going to have to archive it. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:42, 26 January 2022 (UTC)

Improve regex support in search engines and textual editor assistant

 N Proposes existing functionality

  • Problem: Regex support is poor both in the embedded search engine and in the textual editor assistant tool
  • Who would benefit: Everyone
  • Proposed solution: Provide full regex support, including the most sophisticated patterns
  • More comments:
  • Phabricator tickets:
  • Proposer: L736Etell me 17:45, 12 January 2022 (UTC)


Hello @L736E:, thanks for this proposal. Would it be possible for you to elaborate on what would you like to see? What limits have you experienced? What would you like to do that is impossible now? SGrabarczuk (WMF) (talk) 04:16, 13 January 2022 (UTC)

  • I think the regex is like the title blacklist regex, but it's hard to understand. Maybe we should create a help page for advanced searches. Thingofme (talk) 11:05, 13 January 2022 (UTC)
  • @SGrabarczuk (WMF): A simple example: if I write in the search form say of "([2-7]+2)nd Academy Awards" I would expect as most relevant results "22nd Academy Awards", "32nd Academy Awards" and on and the other less relevant not listed afterwards if not listed at all. Today I see that "2nd Academy Awards", that is "not" matching the regex used for searching, is displayed as "most relevant result". That's not correct or at least what an user would expect.--L736Etell me 11:13, 13 January 2022 (UTC)
    Thanks! I've instructed by a fellow Wikipedian whom I consider to be a regex expert that the search is a bit different from the regex feature in the editing mode. He says that in the case you've provided as an example, you need to type intitle:/([2-7]+2)nd Academy Awards/ or even intitle:/[2-7]+2nd Academy Awards/. Have you maybe taken a look at Help:CirrusSearch? SGrabarczuk (WMF) (talk) 17:51, 13 January 2022 (UTC)
    Re-pinging @L736E in case they missed the reply. MusikAnimal (WMF) (talk) 21:46, 20 January 2022 (UTC)
    @L736E Since we have not heard back from you, and what you're proposing appears to already exist, we're going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:44, 26 January 2022 (UTC)
    Maybe I'm wrong, but that's because plain searches (Full text search in Cirrus help) doesn't support the use of regex at all (it uses its own set of regex-like characters).
    You need to use it with insource/intitle or with other modifiers. MarMi wiki (talk) 15:45, 22 January 2022 (UTC)

AJAX on page editing

 N Proposer did not respond / proposal unclear

  • Problem: When Wikipedians are editing, they have to reload the entire page to the editor.
  • Who would benefit: Wikipedians who do a lot of minor edits or having slow internet connection
  • Proposed solution: AJAX editing!
  • More comments: No
  • Phabricator tickets:
  • Proposer: Emojiwiki (talk) 02:46, 11 January 2022 (UTC)


  • An AJAX editor exists now as the 2017 wikitext editor. @Emojiwiki: Have you tried it yet? Look for "New wikitext mode" in your Beta features preferences. Does this satisfy your need? MusikAnimal (WMF) (talk) 15:04, 11 January 2022 (UTC)
    @MusikAnimal (WMF) 2017 wikitext editor also have some limitations in the source code. They can't use highlight as easily as the normal source code. Thingofme (talk) 11:24, 14 January 2022 (UTC)
    Why not ? Please provide accurate descriptions of problems you encounter. Many people have many different experiences, ppl cannot guess what you mean. —TheDJ (talkcontribs) 14:53, 16 January 2022 (UTC)
    @Thingofme I, too, am curious why you say the 2017 wikitext editor "can't use highlight as easily as the normal source code"? Are you sure you have syntax highlighting enabled (settings menu > Syntax highlighting)? This should for the most part appear exactly the same as the older wikitext editor. MusikAnimal (WMF) (talk) 02:40, 18 January 2022 (UTC)
    Thank you, I am sure of this. Thingofme (talk) 02:45, 18 January 2022 (UTC)
  • A lightweight "AJAX editor" already exists and can be enabled in Preferences → Editing → Show previews without reloading the page. Matma Rex (talk) 02:06, 17 January 2022 (UTC)
    It sounds like they're talking about loading the editor, not previewing, but indeed they would most certainly appreciate the "Show previews without reloading the page" preference too.
    Pinging @Emojiwiki so you see this. See also my question about about the 2017 wikitext editor, which provides the functionality you're requesting. MusikAnimal (WMF) (talk) 02:41, 18 January 2022 (UTC)
    @Emojiwiki Since we still not have heard back from you and the proposal is unclear, we're going to have to archive it. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:54, 26 January 2022 (UTC)

Easier addition of wikilinks to table content

 N Needed more user clarification

  • Problem When adding or deleting Wikilinks in a table using the Edit This Page function, it is a cumbersome process. You have to open the template, scroll to the text box and open it, then manually add or delete brackets around the words.:
  • Who would benefit Any editor who adds or deletes Wikilinks from articles:
  • Proposed solution Make it possible to add or delete a wikilink from table text without opening the table template:
  • More comments:
  • Phabricator tickets:
  • Proposer: Rogermx (talk) 16:09, 11 January 2022 (UTC)


Hello there and thanks for your proposal! We looked at this wish as a team and we had a couple of questions about what you meant here. Do you mind telling us which editor are you using? Can you link us to an example table that is hard to edit? A screenshot could also be helpful. It's hard for us to see what is meant here. Thanks in advance, NRodriguez (WMF) (talk) 01:10, 18 January 2022 (UTC)

Pinging @Rogermx so they see this. I think I might understand what you mean; it sounds like you're using a wikitext editor. Removing links from items in a table is a bit easier with VisualEditor, if you haven't tried it yet. You can click directly within the table, move the cursor on the link, then click on the "unlink" icon. Does that work for you? I'm not sure what solution we could devise for wikitext editing. MusikAnimal (WMF) (talk) 22:58, 20 January 2022 (UTC)
Since we still not have heard back from you, we're going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:58, 26 January 2022 (UTC)

Add translate button to mobile web

 N Proposes existing solution

  • Problem: The second most annoying thing in Wikipedia, after trolls, is that mobile users have to switch to desktop to move (translate, an error in title).
  • Who would benefit: All mobile users that aren't multiplataform
  • Proposed solution: Add a sixth button in mobile web interface, which allows to move articles. A simple solution.
  • More comments:
  • Phabricator tickets:
  • Proposer: Goodlucksil (talk) 19:39, 21 January 2022 (UTC)


  • @Goodlucksil: The default mobile experience is intentionally stripped down. If you enable "Advanced mode" in your mobile settings, you will get the "Move" function along with most other native functionality you enjoy in your desktop. Since the feature you propose already exists, I'm going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 22:34, 26 January 2022 (UTC)

Adding options on mobile view

 N Proposer did not respond / proposes existing solution

  • Problem: If you are a mobile user, and you want to view your userpage or others, you need to click the three long bar at the top left of the article. There are options there including your userpage, your contribs, your watchlist etc. The problem is, there are no options "preference" and "sandbox" and if I want yo to see them, I need to search special:preference and my user sandbox at the searchbox of Wikipedia.
  • Who would benefit: all mobile experienced editors
  • Proposed solution: add "Preference" and "Sandbox" options.
  • More comments:
  • Phabricator tickets:
  • Proposer: Ctrlwiki (talk) 00:30, 11 January 2022 (UTC)


  • @Ctrlwiki: Are you aware of the advanced mode on mobile? Go to your settings to turn it on. Then you will have an person icon at the top-right, which when tapped reveals all the "personal" links such as the Sandbox. There is no way to get to Special:Preferences but I believe this is intentional since most of the preferences don't apply to mobile anyway. MusikAnimal (WMF) (talk) 17:50, 14 January 2022 (UTC)
    Since we still have not heard back from you, and this appears to propose a feature that already exist, we're going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 22:36, 26 January 2022 (UTC)

Supress user talk page notification in case of revert

 N Technically infeasible

  • Problem: At times, someone may vandalize or spam user talk pages. The user may or may not see his/her talk page before some third party reverts the edit. After this revert, the user will get a "you got a new message" which he/she may not want.
  • Who would benefit: Any user whose user page was vandalized/spammed.
  • Proposed solution: Allow a user to supress the user talk page notification in case of a revert. This will only apply if reverted to a version which the user had already seen.
  • More comments:
  • Phabricator tickets: phab:T48689
  • Proposer: Animal lover 666 (talk) 15:31, 12 January 2022 (UTC)


@Animal lover 666: does phab:T48689 describe this behavior? (It is fine if it does, just means we can link to it and encourage people to work on it!) — xaosflux Talk 15:44, 12 January 2022 (UTC)

It should work along with the "reverted" tag; if the tag algorithm can recognize manual reverts, so should this feature. Animal lover 666 (talk) 15:52, 12 January 2022 (UTC)
Here is the default current workflow on this:
Scenario 1
  1. Someone edits user_talk:xxx (lets assume it is a vandal)
    The "new messages" indicator is set / echo notification triggered
  2. Someone makes any reversion edit on the user talk page
    The "new messages" indicator is set / echo notification triggered
Scenario 2
  1. Someone edits user_talk:xxx (lets assume it is a vandal)
    The "new messages" indicator is set / echo notification triggered
  2. The user visits their userpage, clearing the indicator/notification
  3. Someone makes any reversion edit on the user talk page
    The "new messages" indicator is set / echo notification triggered
So is the use case you want to change to just remove the last step from scenario 2? This seems like a problem to build around the "revert" tagging job - see this reversion for example - if someone did that to my page I certainly would not want the notification to be suppressed. — xaosflux Talk 16:11, 12 January 2022 (UTC)
Actually, what triggered me requesting this was a scenario #2 from a spammer. He left me a request to edit a specific article; I saw this message; and then it was reverted. I really would have preferred not to be notified about this revert. Animal lover 666 (talk) 20:33, 13 January 2022 (UTC)
@Xaosflux I think the idea is that we'd only make the first user talk page notification disappear if the edit that caused it is reverted, and the user hasn't seen the notification yet (and if they have email and app notifications disabled, since we can't "undo" those). If the user has already seen the user talk page notification, this special behavior would not happen. Matma Rex (talk) 04:37, 22 January 2022 (UTC)
We feel like this is changing the way to notifications work a bit so it so it's seems too complex to be implemented by us in a wishlist cycle. Sorry, that therefore we will have to archive this wish. KSiebert (WMF) (talk) 14:28, 26 January 2022 (UTC)

Dynamic summary in the left pane

 N On another team's roadmap

  • Problem: Difficulty to read and keep an overview on long articles
  • Who would benefit: Any reader
  • Proposed solution: Generate summary in the left pane, for example between "Babel" and Community. Make it always visible with the title of the section currently read in the middle of the screen and highlighted in color
  • More comments: Somewhat similar to the navigation pane in MS Word, hopefully better
  • Phabricator tickets:
  • Proposer: Gfombell (talk) 21:25, 10 January 2022 (UTC)


I mused about wanting this sort of UI feature last month (en:Wikipedia:Village pump (idea lab)#Redesigning and simplifying the English Wikipedia website) and User:Qwerfjkl pointed me to this prototype. DMacks (talk) 21:33, 10 January 2022 (UTC)
I think that prototype is a brilliant addition to readers, and also makes use of the blank space in the new vector Ed6767 (talk) 22:27, 10 January 2022 (UTC)
Yep, this is already being undertaken by the Desktop Improvement Team. {{u|Sdkb}}talk 00:51, 11 January 2022 (UTC)
The TOC just takes up the left half of the screen, squeezing the text for me. (I'm on mobile, desktop mode.) Qwerfjkl (talk) 07:15, 11 January 2022 (UTC)
It's a demo, it would be a finished product if it had already reached perfection. —TheDJ (talkcontribs) 13:01, 11 January 2022 (UTC)

I believe this is somewhat covered in the "new Vector" project: mw:Reading/Web/Desktop_Improvements/Features#Table_of_contents--Strainu (talk) 08:38, 12 January 2022 (UTC)

Yes, Sdkb and Strainu! Thanks for these links. If anyone (I'm looking at Gfombell and Ed6767) is intersted in learning more or getting more involved, check the Participate page. Also:
Did you know ...
...that "new Vector" is in fact just (the) Vector, and (the currently default on most wikis) "Vector" is in fact "Legacy Vector"? So instead of "current vs. new" it's "frozen vs. the new basic one". This is because Vector with the new changes is the only currently evolving version, and the version without the changes is "frozen" and only maintained. That's a DYK for geeks. If you'd like to read more, check this FAQ question. SGrabarczuk (WMF) (talk) 04:57, 13 January 2022 (UTC)
Somehow super glad to see that the wishes contributors have are already in the workings by other foundation teams, will have to archive this for this reason, thanks for proposal in any case! KSiebert (WMF) (talk) 16:24, 21 January 2022 (UTC)

Thanks for sharing the prototype, looks precisely like what I had in mind! Gfombell (talk) 13:49, 2 February 2022 (UTC)

Restoring previous version in mobile

 N Proposer did not respond

  • Problem: It is currently not possible for restoring back to a previous version in the mobile site version. This is especially hard for mobile editors who wants to revert multiple edits and bring back a stable version of an article for stopping vandalism. The editors have to switch to the desktop version in order for doing that.
  • Who would benefit: Editors who use mobile phones to edit.
  • Proposed solution: Have a restore this version button on top of the version of the article just like the desktop mode.
  • More comments:
  • Phabricator tickets:
  • Proposer: A Simple Human (talk) 21:12, 10 January 2022 (UTC)


If I need to use desktop version when I found vandalism, It's useless to mobile user. So, I support this wish. ロックル (talk) 01:33, 11 January 2022 (UTC)
Thank you, totally support this proposal ;) CrafterNova (talk) 03:45, 12 January 2022 (UTC)
Comment: The simple solution can be written by script, something like w:en:User:Sun8908/js/MobileRevert.js. Sun8908 (talk) 20:26, 12 January 2022 (UTC)
Thank you for this ;) CrafterNova (talk) 06:05, 13 January 2022 (UTC)
Hello @A Simple Human, @ロックル, @CrafterNova, have you used the Advanced mobile contributions (AMC)? This may be the solution to your problem. I encourage to try the AMC out and say if you think something still needs to be improved. (Anything other than the awareness of the AMC ^^). SGrabarczuk (WMF) (talk) 03:12, 13 January 2022 (UTC)
AMC is a good choice if the user has the rollback access and want to revert an edit, because AMC has a rollback link, but if the user has no access to the tool, they will still revert it manually, and manual revert on mobile and AMC are the same. Gadgets like Twinkle on mobile devices are very helpful. Ctrlwiki (talk) 05:51, 13 January 2022 (UTC)
@Ctrlwiki: But Twinkle is accessible only through the desktop site. We have to switc