Community Wishlist Survey 2022/Bots and gadgets

Bots and gadgets
13 proposals, 252 contributors, 418 support votes
The survey has closed. Thanks for your participation :)

Fix ListeriaBot memory issues

  • Problem: Since the release of ListeriaBot v2, there is a problem with lists with many links to big entities (for example, links to countries), which make the list generation fail. See some previous discussions: 1, 2. The issue is reported in the official repository: magnusmanske/listeria_rs#66.
  • Proposed solution: Fix the issue with loading big external entities, possibly a caching problem.
  • Who would benefit: ListeriaBot is used to automatically maintain lists of Wikidata items in various Wikipedias. It is used intensively by Women in Red in various languages, as well as other projects (3,204 lists in English, 1,152 in French).
  • More comments:
  • Phabricator tickets:
  • Proposer: MarioGom (talk) 19:49, 10 January 2022 (UTC)


  • I'm afraid this might be out of scope, although I'm not sure. Listeria is a tool by Magnus Manske. If the issue is the tool running low on memory or resources, this should probably be addressed by Toolforge and/or Cloud VPS admins (if it runs there) and ask them to increase the memory quotas. If the issue is with the tool code itself, however, I'm afraid this can only be fixed by Magnus. I note that the repository does not have any license (Issue #80) so contributing patches over there might not be possible or advisable either. CC: MusikAnimal (WMF). Best regards, —MarcoAurelio (talk) 12:27, 11 January 2022 (UTC)
    I haven't done much investigation but I assume we'd be able to help in some way, either assisting the bot operator or building something new from scratch, if we have to. Perhaps a job queue system needs to be introduced, or assuming it lives on Toolforge, maybe this is deserving to move to VPS where we have more memory to work with. Or maybe it's a simple as giving the bot more memory on Toolforge. So while there is a reliance on Magnus Manske, I wouldn't necessarily say this is out of scope, in my view. MusikAnimal (WMF) (talk) 14:27, 11 January 2022 (UTC)
    I agree, this should go to the bot operator himself to correct the code. Some bots are controlled by the community, I think... Thingofme (talk) 02:36, 12 January 2022 (UTC)
    most bots are —TheDJ (talkcontribs) 10:52, 12 January 2022 (UTC)


  •   Support Listeria is a really useful tool, it would be great if it was better supported and more reliable. Thanks. Mike Peel (talk) 18:12, 28 January 2022 (UTC)
  •   Support Bluerasberry (talk) 19:53, 28 January 2022 (UTC)
  •   Support At cswiki we introduced several listeria lists in mainspace. Some of them are not updated because of memory issues, which is pretty embarrassing. Jklamo (talk) 21:19, 28 January 2022 (UTC)
  •   Support -sasha- (talk) 13:47, 29 January 2022 (UTC)
  •   Support No problem Thingofme (talk) 14:31, 29 January 2022 (UTC)
  •   Support This is a key way Women in Red helps participants find topics to work on, so it would be really great especially for newer users if the lists updated reliably. Innisfree987 (talk) 19:13, 29 January 2022 (UTC)
  •   Support josecurioso ❯❯❯ Tell me! 00:13, 30 January 2022 (UTC)
  •   Support lists with country statistics are of especial interest as they are tidious to manually update. Tomastvivlaren (talk) 08:31, 5 February 2022 (UTC)
  •   Support - Darwin Ahoy! 14:06, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 03:02, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 05:09, 6 February 2022 (UTC)
  •   Support Suonii180 (talk) 11:46, 9 February 2022 (UTC)
  •   Support Ecritures (talk) 22:42, 9 February 2022 (UTC)

Give gadgets the option to read current timezone used on wiki

  • Problem: Many wiki's use other timezones than UTC, some of them even alternate with daylight saving time (DST). As a result, some gadgets that use the current time on the wiki (Twinkle for example) have to be modified when ported to another wiki. Also, JavaScript does not have a nice solution to detect when a wiki goes in to DST. (An example is nlwiki switching between CET and CEST).
  • Proposed solution: Create a JavaScript variable (eg. mw.currenttimezone) with the time difference from UTC as its value.
  • Who would benefit: All wiki's that do not use UTC as their timezone.
  • More comments:
  • Phabricator tickets:
  • Proposer: Bas dehaan (talk) 21:15, 22 January 2022 (UTC)


  • You can use parseInt( mw.user.options.get( 'timecorrection' ).split( '|' )[ 1 ] ) to get the time offset of the current user in minutes (this came up during code review recently, thanks to SD0001 for tracking down the solution). Not sure if there's an easy way to get the default time offset of the wiki, though (without making an API request). --Tgr (talk) 19:35, 29 January 2022 (UTC)
    @Tgr and @Bas dehaan I just happen to come across this today. You can actually retrieve the default time offset of a wiki by retrieving the site info. For instance: will show that the timezone is Europe/Berlin and the time offset (on this specific day in the summer) is 120 minutes from GMT/UTC. —TheDJ (talkcontribs) 14:42, 9 August 2022 (UTC)
    Well, yes, by using the API, but that's not very practical. Tgr (talk) 17:45, 9 August 2022 (UTC)


  •   Support Fazart (talk) 00:44, 29 January 2022 (UTC)
  •   Support it could also be handy if this were to be accessible through the API (for example for Toolforge-hosted tools) --Daniuu (talk) 11:09, 29 January 2022 (UTC)
  •   Support clear quality of life improvement. Natuur12 (talk) 16:56, 29 January 2022 (UTC)
  •   Support Not every wikis, especially smaller regional language wikis, use the UTC as their timezone. Thingofme (talk) 02:20, 30 January 2022 (UTC)
  •   Support —— Eric LiuTalk 07:56, 30 January 2022 (UTC)
  •   Support Matěj Suchánek (talk) 11:31, 30 January 2022 (UTC)
  •   Support --g (talk) 15:17, 30 January 2022 (UTC)
  •   Support Jmaxx37 (talk) 18:39, 30 January 2022 (UTC)
  •   Support 🌸 Sakura emad 💖 (talk) 15:52, 31 January 2022 (UTC)
  •   Support WikiAviator (talk) 09:54, 3 February 2022 (UTC)
  •   Support Growthsakup (talk) 12:57, 4 February 2022 (UTC)
  •   Support - Darwin Ahoy! 01:03, 5 February 2022 (UTC)
  •   Support paul2520 (talk) 19:32, 5 February 2022 (UTC)
  •   Support Vulp❯❯❯here! 03:39, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 05:02, 6 February 2022 (UTC)
  •   Support Toadspike (talk) 16:02, 6 February 2022 (UTC)
  •   SupportEric0892 02:20, 7 February 2022 (UTC)
  •   Support ~~~~
    User:1234qwer1234qwer4 (talk)
    22:12, 7 February 2022 (UTC)
  •   Support Hanif Al Husaini (talk) 00:39, 8 February 2022 (UTC)
  •   Support --evrifaessa (talk) 15:52, 11 February 2022 (UTC)

Add option to insert category before current category in Cat-a-lot

  • Problem: Suppose you are browsing a certain category on Wikimedia Commons. Using Cat-a-lot, you decide to pick a couple of files and add another category to them. The new category will be automatically added next to the category you are browsing. But you might wish that the new category will be inserted before the category you are currently browsing, instead of after it, if you think the order of categories of files important. Currently, Cat-a-lot doesn't allow you to do this.
  • Proposed solution: Make it possible for a user to choose that a new category be inserted either before or after the current category.
  • Who would benefit: All Wikimedia Commons users.
  • More comments:
  • Phabricator tickets:
  • Proposer: トトト (talk) 20:36, 10 January 2022 (UTC)


  • I think the people who benefit from this idea is not only the Commons users, but also some users who use Cat-a-lot on other wikis. However, the order of categories is sometimes important for big-small category. Thingofme (talk) 00:51, 11 January 2022 (UTC)
  • Today I learned categories are actually displayed in the order they appear on the page, so this proposal has an actual purpose. I was sure categories are sorted alphabetically in the parser output. ToBeFree (talk) 06:22, 11 January 2022 (UTC)
  • It would be nice if categories displayed in alphabetical order. It saves time when checking if a page is in a specific category, or in each of a set of categories. It would also be nice if a category editing tool collected and sorted the categories in the wikitext automatically when used. Also useful on Wikipedias · · · Peter (Southwood) (talk): 07:43, 11 January 2022 (UTC)
    • en:User:Alex_21/script-categoriessort is "a script that sorts categories in an article alphabetically." It makes an edit and saves the changes to the live article. Apparently it's contentious whether cats should be alphabetized vs organized in other ways. But it seems like it wouldn't be hard to write a .js that simply operated on the display (reader-level) rather than changing the article source itself for those who wanted it. DMacks (talk) 10:45, 11 January 2022 (UTC)
    • The order of categories is VERY contentious within the WP projects. In German WP, biographies are categorized by "field of profession", "all other categories", "birth by...", "death by...", "gender", just for example. Contrary, on Commons I don't think there is any preferred order - instead we are glad if correct categories exist at all. --Enyavar (talk) 12:04, 11 January 2022 (UTC)
      Additionally, some scripts/bots are definitely re-ordering them alphabetically along with other non-cosmetic changes – changing the behaviour within Cat-a-lot would be contrary to this apparently non-controversial kind of generic cleanup. ~~~~
      User:1234qwer1234qwer4 (talk)
      22:17, 7 February 2022 (UTC)
  • I would support this. Daniel Case (talk) 06:01, 13 January 2022 (UTC)
  • Categories represent relations. So the order of cat entries on a page is a purely cosmetical thing. --Achim55 (talk) 18:44, 17 January 2022 (UTC)
  • You haven't explained why you think the order in which the categories are displayed is important, or why it would be useful to have some subjective ordering of categories. Since categories are basically a poor man's ontology (unlike proper ontologies like Wikidata is becoming), and a category simply denotes a class of an instance, specifying subjective category orderings makes no sense, in general. I suppose I might support the ability if it only applied to the user, i.e. if a particular user wants categories on a page to be displayed in a particular arbitrary order for them, so be it. But having some global subjective category ordering is undefined and meaningless. Silver hr (talk) 17:35, 1 February 2022 (UTC)


  •   Support — Draceane talkcontrib. 22:59, 28 January 2022 (UTC)
  •   Support In Wiktionaries, as pages displayed a content about several languages, the order of categories do matters. Noé (talk) 00:25, 29 January 2022 (UTC)
  •   Oppose Precious time of the Community Tech can be spend better on other projects. The order of (parent) categories in a file, category or other page is of no importance. --JopkeB (talk) 04:37, 29 January 2022 (UTC)
  •   Support It depends in wikis, but it's a good idea for importance Thingofme (talk) 02:29, 30 January 2022 (UTC)
  •   Support —— Eric LiuTalk 07:55, 30 January 2022 (UTC)
  •   Support A serious shortcoming in the tool currently IMO Daniel Case (talk) 05:03, 31 January 2022 (UTC)
  •   Oppose too marginal, no need for it. See also User:JopkeB --Havang(nl) (talk) 15:17, 31 January 2022 (UTC)
  •   Support Alain Artivalys (talk) 13:14, 1 February 2022 (UTC)
  •   Oppose per my comment in the Discussion section. Silver hr (talk) 17:35, 1 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 03:01, 6 February 2022 (UTC)
  •   Support Vulp❯❯❯here! 03:40, 6 February 2022 (UTC)
  •   Oppose --Achim55 (talk) 09:15, 8 February 2022 (UTC)
  •   Support I support, because this is a good user interface issue. Many people think, intuitively, that right position = subcat. Others don't. So why not let them put new cat whichever side it means to them? G41rn8 (talk) 23:25, 10 February 2022 (UTC)

A bot or gadget to publish public Git repo to a gadget or user script

  • Problem: It is hard to develop JavaScript scripts and gadgets within MediaWiki. No build tools (especially transpilation), no way to push out changes to many files in one go. Also no review tools (like pull requests).
  • Proposed solution: Provide a publishing tool that would effectively publish a script from e.g. GitHub or GitLab to one of Wikipedia sites. I would assume that the code repository would need to be public (to avoid authentication). On the other hand the tool would publish as the user using it. So the tool would need to have Wikimedia OAuth or use Bot passwords. The publishing tool would be setup using:
  1. Some title of the gadget.
  2. Source and destination URL(s).
  3. Additional info like e.g. default publish message (e.g. providing source URL in the description but also attribution).
  4. Note that I assume the person creating the publisher do not have to be the author of the script.
  5. Once the gadget-publisher is set up, one can publish with one click (optionally adding info to the default publish message to e.g. add version info).
  • Who would benefit: Gadget developers and their users
  • More comments: So at the time of writing Gadgets only support ES5. It is nice that some work on ES2015 is starting, but you know this is kind of all figured out in the frontend world. I think it would all just be easier if wiki developers would use things most other frontend devs use and just quickly publish to Wikipedia. It shouldn't be too hard. The hardest part would probably be making a decent GUI and auth. Other then that you just download one text file and push the text to wiki.
  • Phabricator tickets: (related)
    • phab:T36958: User-level gadget repositories
    • phab:T71445: Implement a sane code-review process for MediaWiki JS/CSS pages on Wikimedia sites.
  • Proposer: Nux (talk) 00:22, 19 January 2022 (UTC)


Come to think of it probably more then one file per gadget would need to be published in some cases. For example build.js (could be a result of Babel transpilation or simple Gulp concatenation) and build.css (maybe built with Less or Sass). And probably some meta like name/title and maybe a project description. Default publish message would be a good thing too. --Nux (talk) 00:48, 19 January 2022 (UTC)

This task probably wants ES6 to be fully supported in gadgets based on the motivation, which is probably phab:T75714 (and phab:T178356?), so that might be a good separate wish. Izno (talk) 05:03, 19 January 2022 (UTC)
A proposed bot could easily implement babel to transpile ES6 code to ES5 Ed6767 (talk) 10:53, 19 January 2022 (UTC)
meh. I don't think naive ES6 is critical, babel and rollup or web pack or whatever can take care of that just as part of the build process.. What I do think would be pretty cool is if we had some sort of NPM package and json standard that would allow you to map dist/ paths to pages on a wiki and then would automatically publish it for you (if you have the credentials). —TheDJ (talkcontribs) 09:33, 19 January 2022 (UTC)
Yes, something like that. But not with JSON as I would prefer a GUI. That would make this more independent and easier to extend. When you have some description standard then adding new fields and references is getting complicated and progresses slowly. Also there really is no need for the tool to be published just by the author of the script. I think it would be good if anyone could update the script. Nux (talk) 11:17, 19 January 2022 (UTC)
This request seems to mix easy publishing and a request for ES2015 and I really think those are two separate things that should not be in one request. "but you know this is kind of all figured out in the frontend world" Cool and all, but as long as there is no PHP implementation of an ES2015 parser, that's irrelevant to us, since we are NOT frontend and NOT nodejs, and shelling out to other languages for essential functionality is problematic (see parsoid which was in nodejs but is now in php again, because it was too problematic). —TheDJ (talkcontribs) 09:41, 19 January 2022 (UTC)
I'm proposing easy publishing instead of tools for building stuff. And I would argue that gadgets are from frontend world. I did some changes in popups a few years back and it was... well a bit of a headache. It would be so much easier if I could just fork a repository for plwiki and the changes I need. Maybe add a pull request for some of them. Then just compile and click to publish. Nux (talk) 11:24, 19 January 2022 (UTC)
@Nux I agree with TheDJ and others that the wording of the proposal seems to imply you want (a) ES2015+ support in gadgets/user scripts and (b) essentially a deploy script from a GitHub repo to the wiki. I think focusing on just (a) would be more appropriate. For (b), it might be difficult to come up with a standardized system that works for everyone. Many gadgets such as MoreMenu and Twinkle are written in ES2015+ and transpiled it to ES5 as a build step. That build step can vary based on developer preference. Some like GruntJS, others like Webpack, etc. A configurable deploy script, with a CLI interface (give it your BotPassword credentials, the JS file and the wiki page to deploy it to) is something I think we could make, and quite easily at that. But I don't think it's good to mix both ideas of build steps and deployment, since this varies.
Do you think you could reword this proposal to focus on either (a) native ES2015+ support in gadgets/user scripts or (b) a configurable deploy script (that does not include build steps like ES5 transpiling)? MusikAnimal (WMF) (talk) 18:58, 20 January 2022 (UTC)
@MusikAnimal (WMF) OK, I re-worded the problem description. ES2015+ was just an example of things that are hard because of how MW works. I also added some more info in the Proposed solution part. Let me know if you think it is still not clear yet. --Nux (talk) 22:25, 20 January 2022 (UTC)
This looks great, thank you! The problem statement I think is more clear now. We can definitely deliver on the deploy script. Rethinking this, as a CLI tool (pass in BotPasswords credentials) or even a Toolforge tool (where you login with OAuth), we should be able to offer build steps as options, such as ES5 transpiling. We can iterate on it together :) Thanks for putting all this work into your proposal! I'm going to mark it for translation now. MusikAnimal (WMF) (talk) 05:03, 21 January 2022 (UTC)
I also trimmed down the proposal a tiny bit to aid translators (hope this is okay!), and removed the mentions of phab:T75714 and phab:T178356. These are going to happen anyway, and are about ES2015+ support in gadgets (which is what I originally thought you were talking about in your proposal). Anyways again, your problem statement is clear, and that's all that matters. Together we'll come up with the best solution! MusikAnimal (WMF) (talk) 05:30, 21 January 2022 (UTC)


  •   Support Qwerfjkl (talk) 22:30, 28 January 2022 (UTC)
  •   Support Izno (talk) 22:48, 28 January 2022 (UTC)
  •   Support JakobVoss (talk) 07:25, 29 January 2022 (UTC)
  •   Support Aca (talk) 12:22, 29 January 2022 (UTC)
  •   Support Douglasfugazi (talk) 21:08, 29 January 2022 (UTC)
  •   Support Thingofme (talk) 02:22, 30 January 2022 (UTC)
  •   Strong support FWIW, the Bulgarian Wikipedia has been using a custom Python daemon to synchronize its JS/CSS, the Module NS, and the spam and title blocklists to Git for more than 3 years, which allows us to do code review in GitHub (e.g. for JS/CSS). There's a lot to desire of the codebase (I was still quite a Python newbie when I wrote most of it) and there are some outstanding bugs, but it does the job. References: synchronization daemon code, JS/CSS repo, Module NS repo.
    — Luchesar • T/C 11:02, 30 January 2022 (UTC)
    I should've added that part of the complexity of our solution is due to the requirement to support continuous (as opposed to “on demand”) bidirectional (i.e. also Wiki->Git) synchronization, as some of our interface admins didn't like the idea of GitHub repos and requested the bot to handle gracefully the local JS/CSS edits in Wikipedia itself. Preventing and resolving possible edit conflicts between the live Wikipedia code and the GitHub repos turned out to be quite the task, but the bot seems to handle this well so far.
    — Luchesar • T/C 11:16, 30 January 2022 (UTC)
  •   Support --Nux (talk) 13:16, 30 January 2022 (UTC)
  •   Support Titore (talk) 17:13, 30 January 2022 (UTC)
  •   Support Nw520 (talk) 22:53, 30 January 2022 (UTC)
  •   Support Daniuu (talk) 23:53, 30 January 2022 (UTC)
  •   Support This would make my workflow far easier, and I suspect the same is true of almost everyone who writes userscripts. JPxG (talk) 00:30, 31 January 2022 (UTC)
  •   Support Matma Rex (talk) 16:31, 31 January 2022 (UTC)
  •   Support Krzysiek 123456789 (talk) 08:42, 1 February 2022 (UTC)
  •   Support Msz2001 (talk) 10:49, 1 February 2022 (UTC)
  •   Support Alain Artivalys (talk) 13:16, 1 February 2022 (UTC)
  •   Support Rdrozd (talk) 17:53, 2 February 2022 (UTC)
  •   Support DannyS712 (talk) 03:06, 3 February 2022 (UTC)
  •   SupportAmmarpad (talk) 15:51, 3 February 2022 (UTC)
  •   Support AtlasDuane (talk) 18:38, 3 February 2022 (UTC)
  •   Support ·addshore· talk to me! 22:42, 4 February 2022 (UTC)
  •   Support paul2520 (talk) 18:54, 5 February 2022 (UTC)
  •   SupportThanks for the fish! talkcontrib (he/him) 21:23, 5 February 2022 (UTC)
  •   Support Vulp❯❯❯here! 03:43, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 05:04, 6 February 2022 (UTC)
  •   Support ~Cybularny Speak? 20:10, 7 February 2022 (UTC)
  •   Support ~~~~
    User:1234qwer1234qwer4 (talk)
    22:28, 7 February 2022 (UTC)
  •   Support Quiddity (talk) 07:26, 10 February 2022 (UTC)
  •   Support Helder 22:00, 10 February 2022 (UTC)
  •   Support Yair rand (talk) 23:47, 10 February 2022 (UTC)
  •   Support --evrifaessa ❯❯❯ talk 15:49, 11 February 2022 (UTC)

Gadget: Who is active

  • Problem: Sometimes you look for any active user on a list of users (campaigns, WikiProjects, experts etc.) to make a request. Often you have to check many of them until you find one active. Sometimes no one on a given list has been active for years and only time is wasted.
  • Proposed solution: There is a script that allows to see, after entering the user's page, when the user made the last edit. Perhaps we could build a tool that would present such information next to the link to the user page, just like the gadget "Replies with links" does. The displayed information could be the date of the last edition, or the active / inactive icon, if the user also set in their .css the range to which someone is considered as active (X minutes, X hours, X days, etc.).
  • Who would benefit: Organizers, Wikimedians looking for active users on various lists
  • More comments:
  • Phabricator tickets:
  • Proposer: Hedger z Castleton (talk) 17:16, 20 January 2022 (UTC)


Navigation popups will show the date of a user's first and latest edits. Reywas92 (talk) 20:58, 3 February 2022 (UTC)

Supported: but please keep the privacy safe. 🌸 Sakura emad 💖 (talk) 19:01, 7 February 2022 (UTC)
  Comment: Similar script to the one linked in the description available at de:Benutzer:Schnark/js/letzteredit (multilingual). ~~~~
User:1234qwer1234qwer4 (talk)
22:26, 7 February 2022 (UTC)


  •   Support This would have sped up the cross-wiki climate denial review quite a bit. Looking in the translator category, I came across many users how had stopped editing. Femke (talk) 19:52, 28 January 2022 (UTC)
  •   Support short and sweet EpicPupper (talk) 22:38, 28 January 2022 (UTC)
  •   Support Sea Cow (talk) 22:46, 28 January 2022 (UTC)
  •   Support Daud Iffa (talk) 23:50, 28 January 2022 (UTC)
  •   Support --𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 01:01, 29 January 2022 (UTC)
  •   Support Would benefit all communities immensely. Lectrician1 (talk) 02:10, 29 January 2022 (UTC)
  •   Support --JopkeB (talk) 04:25, 29 January 2022 (UTC)
  •   Support Ottawajin (talk) 05:30, 29 January 2022 (UTC)
  •   Support 3aFW (talk) 05:51, 29 January 2022 (UTC)
  •   Support --Флаттершай (talk) 06:25, 29 January 2022 (UTC)
  •   Support Respublik (talk) 08:19, 29 January 2022 (UTC)
  •   SupportBruce1eetalk 08:27, 29 January 2022 (UTC)
  •   Support Aca (talk) 12:24, 29 January 2022 (UTC)
  •   SupportSHEIKH (Talk) 12:33, 29 January 2022 (UTC)
  •   Support ElBe 1 | 2 | WP 17:27, 29 January 2022 (UTC)
  •   Support — Jules* Talk 18:10, 29 January 2022 (UTC)
  •   Support quite-useful. 🌸 Sakura emad 💖 (talk) 18:13, 29 January 2022 (UTC)
  •   Support Douglasfugazi (talk) 21:09, 29 January 2022 (UTC)
  •   Support 𝗩𝗶𝗸𝗶𝗽𝗼𝗹𝗶𝗺𝗲𝗿 23:55, 29 January 2022 (UTC)
  •   Support Thingofme (talk) 02:39, 30 January 2022 (UTC)
  •   Support Ali Imran Awan (talk) 07:10, 30 January 2022 (UTC)
  •   Support TheInternetGnome (talk) 07:24, 30 January 2022 (UTC)
  •   Support —— Eric LiuTalk 07:54, 30 January 2022 (UTC)
  •   Support --g (talk) 15:18, 30 January 2022 (UTC)
  •   Support Andrewredk (talk) 16:41, 30 January 2022 (UTC)
  •   Support Titore (talk) 17:17, 30 January 2022 (UTC)
  •   Support Rusalkii (talk) 23:28, 30 January 2022 (UTC)
  •   Support I think it would be relatively easy for me to write something like this, and I'd enjoy the challenge. JPxG (talk) 00:31, 31 January 2022 (UTC)
  •   Support BugWarp (talk) 02:23, 31 January 2022 (UTC)
  •   Support Daniel Case (talk) 05:04, 31 January 2022 (UTC)
  •   Support Qazwsx777 (talk) 09:28, 31 January 2022 (UTC)
  •   Support Nice to have, as far as a way to appear offline even if online is provided. Trizek from FR 11:59, 31 January 2022 (UTC)
  •   Support IAmChaos (talk) 17:58, 31 January 2022 (UTC)
  •   Support Bencemac (talk) 17:59, 31 January 2022 (UTC)
  •   Support IOIOI (talk) 20:37, 31 January 2022 (UTC)
  •   Support Dave Braunschweig (talk) 22:20, 31 January 2022 (UTC)
  •   Support Alain Artivalys (talk) 13:17, 1 February 2022 (UTC)
  •   Support Thanks, EDG 543 (message me) 14:27, 1 February 2022 (UTC)
  •   Support Ju Mdz (talk) 16:13, 1 February 2022 (UTC)
  •   Support KingAntenor (talk) 06:07, 2 February 2022 (UTC)
  •   Support (talk) 11:14, 2 February 2022 (UTC)
  •   Support Geert Van Pamel (WMBE) (talk) 16:06, 2 February 2022 (UTC)
  •   Support Rdrozd (talk) 17:51, 2 February 2022 (UTC)
  •   Support ~ Amory (utc) 20:38, 2 February 2022 (UTC)
  •   Support AnonymousStackOverflow (talk) 20:51, 2 February 2022 (UTC)
  •   Support HouseBlaster (talk) 01:07, 3 February 2022 (UTC)
  •   Support Aimwin66166 (talk) 05:59, 3 February 2022 (UTC)
  •   Support Paucabot (talk) 06:18, 3 February 2022 (UTC)
  •   Support Szoltys (talk) 16:11, 4 February 2022 (UTC)
  •   Support Salicyna (talk) 16:13, 4 February 2022 (UTC)
  •   Support Kenraiz (talk) 16:17, 4 February 2022 (UTC)
  •   Support Ciacho5 (talk) 16:23, 4 February 2022 (UTC)
  •   Support Gdarin | talk 16:27, 4 February 2022 (UTC)
  •   Oppose The navigation popups provide the last edited date. I don't see an additional time would benefit this proposal. While it could be helpful to see who is active based on last x timeframe as said in the proposal, I do not support any of the developments that could one day might be exploited in a breach of privacy. Wikimedia already publishes a lot of public logs, any further from the software is not recommended. Users who're interested can use the scripts. DaxServer (talk) 18:19, 4 February 2022 (UTC)
  •   Support Bibeyjj (talk) 20:11, 4 February 2022 (UTC)
  •   Support --ToprakM 00:56, 5 February 2022 (UTC)
  •   Support Djdj5050 (talk) 03:30, 5 February 2022 (UTC)
  •   Support - Darwin Ahoy! 14:41, 5 February 2022 (UTC)
  •   Support SD hehua (talk) 15:06, 5 February 2022 (UTC)
  •   Support Exilexi (talk) 17:25, 5 February 2022 (UTC)
  •   Support I'm trying out the linked script, which is neat. But this proposal would be an easier option for some editors. paul2520 (talk) 19:21, 5 February 2022 (UTC)
  •   Support //Lollipoplollipoplollipop::talk 21:22, 5 February 2022 (UTC)
  •   Oppose --Ciao • Bestoernesto 03:04, 6 February 2022 (UTC)
  •   Support Vulp❯❯❯here! 03:44, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 05:04, 6 February 2022 (UTC)
  •   Oppose I have several privacy concerns regarding this. Additionally, Wikipedia is not social media. Nave do Conhecimento (talk) 11:53, 7 February 2022 (UTC)
  •   Support Mohammad ebz (talk) 14:48, 7 February 2022 (UTC)
  •   Support Krzysiek 123456789 (talk) 15:40, 7 February 2022 (UTC)
  •   Support ~Cybularny Speak? 20:11, 7 February 2022 (UTC)
  •   Support DontWannaDoThis (talk) 09:18, 9 February 2022 (UTC)
  •   Oppose I don't believe that it has any advantages over the already existing scripts. IMO, we should focus on real problems and try not to reinvent the wheel. --Ján Kepler (talk) 19:21, 9 February 2022 (UTC)
  •   Support Gaurav (talk) 03:53, 11 February 2022 (UTC)
  •   Support DerFussi 12:17, 11 February 2022 (UTC)
  •   Support Yep. Many users are not here anymore, but they are still in lists/categories. Carn (talk) 14:54, 11 February 2022 (UTC)

Add built in API to add buttons for editing gadgets

  • Problem: It's hard to add buttons for editing tools in a single, visible group.
  • Proposed solution: Basically want I want is a replacement for this toolbar library. It allows adding buttons but it is kind of hard to maintain especially when new editor is added/removed. Same with VE editor (code and non-code) -- don't really have a simple, unified API that would allow adding buttons to toolbars.
  • Who would benefit: Gadget creators and gadget users.
  • More comments: Also it is hard to add something else then an image. Like and image with text which would be less confusing then just an image. Or add a button with an input (the code adds the button to advanced section which kind of sucks and is said to be bad, but I see no other way).
  • Phabricator tickets:
  • Proposer: Nux (talk) 00:06, 12 January 2022 (UTC)


  • @Nux: Could you say a bit more about the shortcomings with adding new buttons to the toolbar? The existing system for adding a button in a gadget (to the existing top-level 'insert' group) is something like this:
    		mw.hook( 'wikiEditor.toolbarReady' ).add( function ( $textarea ) {
    			$textarea.wikiEditor( 'addToToolbar', {
    				section: "main",
    				group: "insert",
    				tools: {
    					strikethrough: {
    						type: "button",
    						label: "Strike-through",
    						oouiIcon: "strikethrough"
    			} );
    		} );
    This seems reasonable, but I'm probably missing some context of your proposal.
    For the second part, would T286759 Allow arbitrary HTML for buttons solve for what you're trying to do? It certainly would be good to be able to add things other than icon-buttons (CommTech might even get to doing this quite soon as part of the Real Time Preview for Wikitext wish).
    SWilson (WMF) (talk) 06:06, 12 January 2022 (UTC)
    That is just a bad API for me, at least for gadgets:
    1. A section is not added if its is missing.
    2. A group is not added if its is missing.
    3. The image must be a square.
    4. No way to provide a text beside the image or instead of the image (or at least none that I know of).
    Nux (talk) 19:49, 14 January 2022 (UTC)
  • Gadgets and user scripts are having some codes for this, and I think we don't need to add buttons. Thingofme (talk) 11:03, 13 January 2022 (UTC)
  • "don't really have a simple, unified API that would allow adding buttons to toolbars." I'll also note that part of this is because a lot of (requested) complexity has been added over the years. VE and the old editors are very different in design and capabilities. Wrapping a 'button' to work in multiple, much more advanced editors (which I think is what you want) is just not that easy to do and doesn't actually make it much easier to work with. —TheDJ (talkcontribs) 23:07, 13 January 2022 (UTC)
    Sure, I can understand it is not easy. That's why I would prefer not to do that 😉. We (at plwiki) always figured some way to do that. But lately there is this discussion about using API rather then hacking into classes or relaying on structure. I'm all for using APIs if they are good enough. In all of the editors you basically need: an icon, maybe text, a handler and a container for all that. Most of the time that should be enough.
    Adding stuff like "action: encapsulate" might be fun for doing something for yourself, but seems to simple for a gadget. At least I don't have any gadgets like that... Well I think I added one button like that on plwiki, but not as a gadget.
    BTW. Making an easier API for manipulation text and selection in an editor would be great, but that is another problem. Nux (talk) 20:07, 14 January 2022 (UTC)


Improvement to the AIV helper bot

  • Problem: Currently, the AIV helperbot (HBC AIV helperbot5) on enWiki only removes entries itself if the user gets blocked or if the entry is x amount of hours old (from what I've seen the number is usually around 4). Unfortunately, not all entries on AIV end up with the user blocked, sometimes the user simply gets warned or the user's edits are determined not to be vandalism, or the user stops editing before getting reported to AIV meaning the user isn't blocked because blocking is only used as a preventative measure and not as punishment. The issue comes when the user starts vandalizing again and the report hasn't been removed. Most admins will probably see that the user has been determined to no longer be an issue and the user is able to continue vandalizing. If someone re-reports the user and the previous entry for the user has not been removed, the bot will automatically combine them, making it harder for the user to properly be reported. There's also the issue of admins not checking the AIV regularly enough and some vandals being able to get away with their vandalism because their report became stale.
  • Who would benefit: Anyone who reports users to AIV and also admins who manage AIV.
  • Proposed solution: Add to the functionality of the bot by having the stale timer for each reported user only decrease if they aren't editing after X amount of time, and also having the bot remove any unactionable reports (i.e user being warned, edits not being vandalism) automatically after a bit and if the user vandalizes again, they can be reported again without the new report being merged into the older report that was determined to be unactionable.
  • More comments: I had discussed this before with Alexis Jazz here, however they told me doing so is not feasible for the time being since the creator of another one of the bots at AIV (Mdaniels bot) has health issues and wasn't the one who wrote the AIV function for the bot. If this isn't something that is able to be done let me know.
  • Phabricator tickets:
  • Proposer: Blaze Wolf (talk) 18:28, 10 January 2022 (UTC)


  • This is a proposal to minimally improve a bot running on a single page on one specific community, to fix a rare issue involving many assumptions that are often not true. I personally would prefer the team to address issues that affect many communities on many pages, ideally not only for Wikipedia, but for everyone using MediaWiki. Just to show what kind of proposals I mean, at least one such proposal exists at Community Wishlist Survey 2022/Miscellaneous/Enhanced Move Logs. If you compare these two, you may see the issue I have with this one here. ToBeFree (talk) 18:40, 10 January 2022 (UTC)
    @ToBeFree: So are you saying this isn't a relevant proposal here? If so I can remove it. The FAQ related to what out of scope things were be wasn't very helpful in me knowing what is and isn't in the scope. Blaze Wolf (talk) 18:50, 10 January 2022 (UTC)
    Community_Wishlist_Survey/How_to_create_a_good_proposal does explicitly mention "creating bots" and "modifying existing bots" as good examples, so I can't really recommend against proposing it – I just think the rare chance to let the WMF work on important community-wished features in the software should ideally be used for MediaWiki- or Wikimedia-wide improvements. That's rather a personal preference than a policy. ToBeFree (talk) 18:53, 10 January 2022 (UTC)
    Ah ok. I don't often use metawiki if it wasn't already obvious. Blaze Wolf (talk) 18:57, 10 January 2022 (UTC)
    It's technically in scope, but I suspect this would receive few votes for the reasons ToBeFree explains. You decide whether you want it to stay :) Also if you want to give any feedback on how we can improve our FAQ, please do so at Talk:Community Wishlist Survey. Thanks, MusikAnimal (WMF) (talk) 18:55, 10 January 2022 (UTC)
  • I think reports with comments in response should be left to human admins like myself to decide whether or not to remove. We can review them and see whether the vandal has resumed or attempted to discuss; I'm not sure bots are at the point where we trust them to do that. Daniel Case (talk) 05:31, 11 January 2022 (UTC)
    Blocked vandals are stated as finished, but vandals that admins say shouldn't be blocked must be commented by an admin or further discussion before it's removed. Thingofme (talk) 00:52, 12 January 2022 (UTC)


Edit summary assistant

  • Problem: Regarding edit summaries, many edits do not include them, some editors do not leave them with their edits, and many summaries that are left are less helpful than is possible, often lacking links to supporting information, and being written in a wide range of varied styles.
  • Proposed solution: It would be useful to have means easily available while using edit windows, maybe via drop down menu, maybe from the "Edit summary" field, to help editors to leave helpful standardized edit summaries. Such a capacity could save time and improve quality. I have compiled a page of edit summaries which can provide an initial source of standardized summaries. That page is linked in my User page, in the section titled "Edit summaries". Feel free to copy anything on that page and edit it elsewhere in any way desired, but please do not edit that page. Thank you.
  • Who would benefit: All editors, even the most expert.
  • More comments:
  • Phabricator tickets:
  • Proposer: Jerryobject (talk) 09:55, 22 January 2022 (UTC)


Convenience link to the page mentioned in the description: w:User:Jerryobject/Edit summaries.

I think it would be useful to have a few standardised edit summaries available, translated into different languages. I only speak English but there's quite a lot of small maintenance tasks on other wikis that are actually easy to perform without much knowledge of a language (other than wikitext). However what always puts me off is not knowing what to put in the edit summary. the wub "?!" 16:48, 23 January 2022 (UTC)

This is w:Wikipedia:Canned edit summaries. It could be useful, but there are concerns it'd help facilitate vandalism, so it's necessary to tread cautiously. {{u|Sdkb}}talk 19:00, 28 January 2022 (UTC)
We actually have something like this on almost since forever :pl:MediaWiki:Gadget-edit-summaries.js. There aren't as many as on the above list. I'm not sure if such a long list could be done in a useful way. We have a short and pretty universal list with buttons divded into groups (about 30 buttons). You can see it in action as green buttons: example edit in Polish (buttons are only shown in Polish).
Note that users can add their own summary-buttons in their vector.js or common.js (just a simple function call). The script kind of works in VE even, layout is not perfect, but it mostly works. Nux (talk) 13:05, 30 January 2022 (UTC)
Many projects have a variation of this, but standardising them into a single tool (not necessarily enabled by default) seems helpful. ~~~~
User:1234qwer1234qwer4 (talk)
22:22, 7 February 2022 (UTC)
Predictive typing may be nicest solution: a drop-down takes 1 click,which requires additional user attention, but getting the right item by typing a couple first characters may make it super-fast (or at least faster than typing out or clicking around). It could a drop-down that filters itself as you type. Cryout (talk) 14:55, 11 February 2022 (UTC)


  •   Support --NGC 54 (talkcontribs) 23:00, 28 January 2022 (UTC)
  •   Support Daud Iffa (talk) 23:49, 28 January 2022 (UTC)
  •   Support --𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 00:58, 29 January 2022 (UTC)
  •   Support Ottawajin (talk) 05:32, 29 January 2022 (UTC)
  •   Support SCIdude (talk) 07:49, 29 January 2022 (UTC)
  •   Support Perhaps a similar feature to one that the OpenStreetMap editor iD uses would be helpful, where it offers a dropdown of your recent changeset comments to select from on the right side of the text input box. It's a slick UI trick that works well in my opinion. Mbrickn (talk) 15:30, 29 January 2022 (UTC)
  •   Support We should analyse existing summaries, identify statistically popular ones and then create a few options (maybe checkboxes like the "Small edit" one) that can be quickly ticked. I guess "grammar", "references", "proofreading", "data update" could be the top ones. I also assume that AI could identify the nature of the edit (especially in the above categories) but probably not at the current sad level of Wiki tech. --SSneg (talk) 20:43, 29 January 2022 (UTC)
  •   Support Thingofme (talk) 02:18, 30 January 2022 (UTC)
  •   Support TheInternetGnome (talk) 07:25, 30 January 2022 (UTC)
  •   Support —— Eric LiuTalk 07:54, 30 January 2022 (UTC)
  •   Support SD hehua (talk) 10:14, 30 January 2022 (UTC)
  •   Support I would support adding a nice API for adding buttons in groups. That would have to be an easy to use API so that users could easily use it. I don't think it is feasible to add universal buttons that would work for all wikis, so there would have to be some per-site configuration. --Nux (talk) 13:13, 30 January 2022 (UTC)
  •   Support --g (talk) 15:17, 30 January 2022 (UTC)
  •   Support Titore (talk) 17:21, 30 January 2022 (UTC)
  •   Support Libcub (talk) 21:32, 30 January 2022 (UTC)
  •   Support Daniel Case (talk) 05:04, 31 January 2022 (UTC)
  •   Support Qazwsx777 (talk) 09:29, 31 January 2022 (UTC)
  •   Support Some solutions already exist and would indeed be nice to have as core features! Trizek from FR 11:58, 31 January 2022 (UTC)
  •   Support IAmChaos (talk) 17:57, 31 January 2022 (UTC)
  •   Support I used the cache information of my web browser in the past and that helped to spare time, I remember years ago that I pointed out how we needed something like that on a local Wiki. Nobody was interested, it's time we handle this at the central level. I hope it can by customized as well.--Alexmar983 (talk) 01:59, 1 February 2022 (UTC)
  •   Support Alain Artivalys (talk) 13:17, 1 February 2022 (UTC)
  •   Support have some problems myself at times, an assistant is sure good. Paradise Chronicle (talk) 04:45, 2 February 2022 (UTC)
  •   Support Zippybonzo (talk) 17:34, 2 February 2022 (UTC)
  •   Support ★NealMcB★ (talk) 23:35, 2 February 2022 (UTC)
  •   Support Paucabot (talk) 06:15, 3 February 2022 (UTC)
  •   Support HyperDrive05 (talk) 17:10, 3 February 2022 (UTC)
  •   Support Fernando Archuby (talk) 17:44, 3 February 2022 (UTC)
  •   Support And make it mandatory too! =) Vega (talk) 18:00, 3 February 2022 (UTC)
  •   Support.Need it.-- MASUM THE GREAT (talk) 11:26, 4 February 2022 (UTC)
  •   Support SlowByte (talk) 18:42, 4 February 2022 (UTC)
  •   Support - Darwin Ahoy! 20:57, 4 February 2022 (UTC)
  •   Support Sir Proxima Centauri (talk) 10:41, 5 February 2022 (UTC)
  •   Support I'm definitely guilty of forgetting to leave a summary every so often, or hitting the enter key too soon. And this would help with edits from anonymous users. paul2520 (talk) 19:05, 5 February 2022 (UTC)
  •   Support Vulp❯❯❯here! 03:42, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 05:11, 6 February 2022 (UTC)
  •   Support Eric0892 (talk) 02:18, 7 February 2022 (UTC)
  •   Support Hulged (talk) 02:20, 7 February 2022 (UTC)
  •   Support LRFtheLion (talk) 02:20, 7 February 2022 (UTC)
  •   Support Mohammad ebz (talk) 14:49, 7 February 2022 (UTC)
  •   Support ~~~~
    User:1234qwer1234qwer4 (talk)
    22:23, 7 February 2022 (UTC)
  •   Support Captainroz (talk) 06:28, 8 February 2022 (UTC)
  •   Support KnowledgeablePersona (talk) 23:32, 8 February 2022 (UTC)
  •   Support I think that becoming useful for write fixed-ID (ex:permanent version). --Mario1257 (talk) 16:55, 10 February 2022 (UTC)
  •   Support if, after editing, it was proposed to fill in structured data, as on the Commons after uploading a file, it would be more interesting than now. Sunpriat (talk) 23:10, 10 February 2022 (UTC)
  •   Support Gaurav (talk) 03:52, 11 February 2022 (UTC)

Add data namespace support to ListeriaBot or fix TabulistBot

  • Problem: Generate datasets from SPARQL-queries which can be shared between wikimedia wikis
  • Proposed solution: Add Wikimedia Commons data namespace support to ListeriaBot or fix TabulistBot
  • Who would benefit: All wikimedia wikis
  • More comments: Wikimedia wikis should have some useful way to generate data files that could be shared between multiple wikis. For example list of populations or locations. With federated SPARQL-queries data sources could be wider than just Wikidata. Also when the results are stored in pre-generated JSON files which are used in wiki pages it is not a problem if the query phase is slow.
  • Phabricator tickets:
  • Proposer: Zache (talk) 14:59, 22 January 2022 (UTC)


  • automated list generation may provide semi-permanent machine-readable result set of specific queries.--GZWDer (talk) 21:23, 22 January 2022 (UTC)
  • This would be a good way to implement ListeriaBot/co. --Izno (talk) 22:51, 22 January 2022 (UTC)


Tool that reviews new uploads for potential copyright violations

  • Problem: There are so many uploads on Wikimedia Commons that are copyright violations. Some of them are snapshots of some computer screen or some other image like a poster. I estimate that about 3-6% of all files on Commons (most of them probably images) are copyright violations. I already had some files around the time when Commons started that were copyright violations and nobody ever noticed.
  • Proposed solution: A bot or tool that checks uploaded files and flags them if they are potentially copyright violations
  • Who would benefit: Wikimedia Commons as such as well as admins
  • More comments:
  • Phabricator tickets: phab:T120453
  • Proposer: --D-Kuru (talk) 14:00, 18 January 2022 (UTC)


In my opinion copyright violations share one or more of these features:

  • EXIF data: Copyvios usually do not have EXIF info. Not said that they can not include them.
  • Size: Copyvios are usually small in size (usually websize like around 800 px for the long length). Not said that they can't be larger.
  • Account edits: Copyvios are often uploaded by what I call hit and run accounts. So the account is created, uploads one copyvio and is never to be used ever again.
  • Can be found in the web: Copyvios can often be found on other websites. Not said that they can not be freely shared by other people on sites like flickr.
  • Author: No matter how impossible it is, the file is tagged with "own work" and the upload as the author name
  • Percentage of useruploads: When a hit and run account uploads three images and two of them are speedy deleted because of copyright violation, the third one should may be checked.
  • Content: Copyvios usually look better than the average image on Wikimedia Commons. All other parts are probably possible to check rather easy. But this one would need a highly specialised AI that can tell good from bad quality. For a project like Wikimedia I guess this is next to impossible if nobody like Google steps in to help out.

There are also hints that indicate a file is a legit one: GPS data (not possible for every file), upload by a user with many edits over many years, user who has a global account with more profiles on different projects, etc.

My suggestion is NOT to have a bot run wild and delete files it deems as copyvios, but to have a bot that assigns a (public?) score to an image and checks how likely it is that some file could be a potential copyvio so that less of them slipp by.

I thought about creating something like a Trusted Author who has to meets certain criteria to ensure that people can use uploads by this user. There is a tiny story behind this: I was asked by somebody via Mail if they can use my image in a school book and what they would have to do to use it. I said of course and told them all they would have to do is to credit me and the licence. They ended up not using my image (even I own the copyright and have it licenced under a free licence) because they can't be sure for 100% and they could potentially get into legal troubles if they use the image without having a real permission. This might not be a big deal for a website, but can be a huge deal for a (school) book that is printed and sold over many years. --D-Kuru (talk) 20:21, 20 January 2022 (UTC)

  • @D-Kuru: This is a valid proposal, but it's a bit wordy. phab:T120453 is basically what you're asking for (a bot to flag Commons uploads that are possible copyvios). Is that correct? If so, with your permission, may I simplify the wording of your proposal? It will eventually be marked for translation, so putting in fewer words will make it easier on the translators. For instance, the symptoms you mention in "More comments" such as looking at EXIF data, size, etc., are helpful but not really necessary to understanding the wish. We could move that here to the discussion section. Thanks, MusikAnimal (WMF) (talk) 19:06, 20 January 2022 (UTC)
@MusikAnimal (WMF): I did not have the time to check the ticket, but from your description this sounds about right. I moved the More comments section as suggested. --D-Kuru (talk) 20:21, 20 January 2022 (UTC)
Ok thanks. I have done some slight rewording of your proposal for better translatability, which I hope is okay :) Best, MusikAnimal (WMF) (talk) 22:07, 20 January 2022 (UTC)
  • Files are also legit ones if there is a VRT ticket or when the VRT request is pending, please ignore them in this gadget (perhaps obvious, but let's not forget it). --JopkeB (talk) 04:53, 29 January 2022 (UTC)
  • Note that such a tool can list the images corresponding of the features listed above in galleries such as it was done by c:User:OgreBot/Uploads by new users that stopped and was very useful, as an administrator I found a lot of content to be deleted tanks to those galleries. A pity it have stopped. Christian Ferrer (talk) 12:17, 30 January 2022 (UTC)
This had a lot of support, so I have made a bot solution that can be expanded that should fulfil some of the needs of this wishlist. You can read the bot request here: Ed6767 (talk) 19:21, 9 February 2022 (UTC)

I wonder if calculating hashes on uploaded files could help... there's not likely a database we could bump against, but we could probably track hashes of uploaded files over time, and if a file with the same hash is uploaded again, that could be one factor into such a score. Alternatively, it could help indicate if the file exists already, under a different name? = paul2520 (talk) 19:37, 5 February 2022 (UTC)

I would suggest on upload always use the "This file is not my own work." -upload form. If it is own work, they should declare that they are the author. Many people just use the simpler form, which leads to copyvio. If they declare author and source it is easier to detect copyvios, than images wrongly taged as own work.  — Johannes Kalliauer - Talk | Contributions 18:41, 16 February 2022 (UTC)


Readability scores gadget

  • Problem: Many of our articles are (accidentally) written for an academic audience, leaving behind our average reader (see for instance this journal).
  • Proposed solution: Made a gadget that can show (various) readability scores of article(s), and paragraphs within. Most readability scores like the Flesch reading ease score are based on word and sentence length. Others like Dale-Chall readability formula are based on how familiar (or common) the used words are. I think it is good to have at least one of both categories. The weighting of these tests typically varies by language, so maybe it would only be feasible to do this for the biggest 10-20 languages. Smaller wikis that translate would benefit indirectly.

    Available tools are often insufficient. Readability of Wikipedia is English-only, and quite buggy. Copy-pasting it to websites like Hemingway is time-consuming as citations need to be manually removed.

  • Who would benefit: Readers with an average education level. On simplewiki, English-language learners and younger readers.
  • More comments: Add some basic statistics about article/section/paragraph being translated is a similar proposal focused on translated text.
  • Phabricator tickets:
  • Proposer: Femke (talk) 20:08, 20 January 2022 (UTC)


Yes "Readability of Wikipedia" does not seem to tell you what is hard to read. And it sometimes comes up with the confusing "Some errors were detected in the mark-up of the Wikipedia article, which could affect the Flesch score" even for featured articles, which seems unlikely. There does not seem to be a way to report bugs. If it is no longer being maintained maybe the creators would give it to us for someone to improve and integrate in as a tool? Chidgk1 (talk) 13:14, 26 January 2022 (UTC)

  • This could also be used to identify articles in English Wikipedia that are already (almost) simple enough to be included in the Simple English Wikipedia. Ottawajin (talk) 05:38, 29 January 2022 (UTC)
  • Readers can easily determine that an article is too difficult. Excess complexity is a real issue. Editors might be interested in a metric that would encourage them to simplify difficult articles. Lfstevens (talk) 05:45, 31 January 2022 (UTC)
  • I just have a very basic question: is this actually portable to other languages easily? - I mean given a list of "difficult words", can it be applied to Arabic, Afrkaans, or Chinese, for example (Note: I am the person who proposed the translation issue linked above)--Eptalon (talk) 22:04, 31 January 2022 (UTC)
    There is some scientific literature on the topic, such as this 2019 paper, and this 2021 paper. The first compares 6 languages (including Basque), the second one is a machine learning application that seems to be extendable more generally. It's not a trivial task, but I believe it is possible to find 'conversions' in the literature. Femke (talk) 21:11, 4 February 2022 (UTC)
  • @Femkemilene: I suggested something a bit like this, a few years ago: phab:T135321 "Vocabulary assistant for Simple Wikipedia, based on Upgoer Text Editors". Hope that helps! Quiddity (talk) 07:39, 10 February 2022 (UTC)
    Thanks. I now see there is phab:T91338 too, which is even closer to this proposal. Femke (talk) 20:33, 10 February 2022 (UTC)


Improve Mix'n'Match performance

  • Problem: Mix'n'match has poor performance, even when searching in only one catalog. Descriptions often fail to load.
  • Proposed solution: Give the tool better hardware and/or rewrite code to improve performance.
  • Who would benefit: Any Mix'n'match user
  • More comments:
  • Phabricator tickets:
  • Proposer: Bargioni (talk) 09:36, 15 January 2022 (UTC)


  • Mix'n'Match is hosted in Toolforge; Magnus previously written an 2.0 version of Mix'n'Match hosted in Cloud VPS, but this is quickly abandoned. See Wikirecords for my idea of the ideal long-term future replacement.--GZWDer (talk) 19:26, 16 January 2022 (UTC)
  • See also d:Topic:Wpbqdk3e1nk4irvz about the problem of slowness. --Epìdosis 09:34, 9 February 2022 (UTC)


  •   Support a good idea Thingofme (talk) 02:16, 30 January 2022 (UTC)
  •   Support Alain Artivalys (talk) 13:14, 1 February 2022 (UTC)
  •   Support Mix'n'Match's performance seems to be getting worse and worse in my experience. Just the other day I had to wait several minutes after clicking "Confirm" in a bunch of matches, until they finally were marked as done. Waldyrious (talk) 16:01, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 03:00, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 05:10, 6 February 2022 (UTC)
  •   Support --Epìdosis 13:37, 7 February 2022 (UTC)
  •   Support Ecritures (talk) 22:39, 9 February 2022 (UTC)
  •   Support Sunpriat (talk) 23:13, 10 February 2022 (UTC)

Get Twitter ID

  • Problem:
    Flagged Suggestion In Wikidata
    There is constraint/suggestion against "Twitter username" asking for the "Twitter user numeric ID" and "start time", but if it's not easy, people don't often do it
  • Proposed solution: Have a bot that crawls for missing "Twitter user numeric ID" and "start time" then using data from the Twitter API fills them in
  • Who would benefit: With Twitter currently such a ubiquitous identifier of people and things, using fixed numeric id (rather than the changable text name) improves quality
  • More comments:
  • Phabricator tickets:
  • Proposer: Back ache (talk) 10:19, 21 January 2022 (UTC)


  • A bot (BorkedBot) already exists, but a gadget may also help.--GZWDer (talk) 10:51, 21 January 2022 (UTC)


  •   Support I highly support this, because it would help when adding Twitter handles CrystalLemonade (talk) 19:35, 28 January 2022 (UTC)
  •   Support Biographies are the biggest category of article in every language Wikipedia, and Twitter is the off-wiki social media platform which the wiki community finds most tolerable and useful for connecting Wikipedia to other public identity records. There are so many sketchy "look up twitter ID" tools and websites. Considering the scale that Wikidata and the Wikipedia platform use these ID records, we could use our own copy of this tool or just automatic lookup. Bluerasberry (talk) 19:57, 28 January 2022 (UTC)
  •   Support Corn cheese (talk) 20:27, 28 January 2022 (UTC)
  •   Support Seems natural. Honestly, I'm surprised that currently in the numeric ID isn't generated automatically when a twitter username is entered, at least in WikiData.CLalgo (talk) 22:09, 28 January 2022 (UTC)
  •   Support EpicPupper (talk) 22:36, 28 January 2022 (UTC)
  •   Support Sea Cow (talk) 22:45, 28 January 2022 (UTC)
  •   Support Legowerewolf (talk) 00:58, 29 January 2022 (UTC)
  •   Support Ottawajin (talk) 05:31, 29 January 2022 (UTC)
  •   Support Aca (talk) 12:29, 29 January 2022 (UTC)
  •   Support Mbrickn (talk) 15:25, 29 January 2022 (UTC)
  •   Support HLFan (talk) 15:55, 29 January 2022 (UTC)
  •   Support Douglasfugazi (talk) 21:07, 29 January 2022 (UTC)
  •   Support OwenBlacker (Talk) 22:05, 29 January 2022 (UTC)
  •   Support Thingofme (talk) 02:17, 30 January 2022 (UTC)
  •   Support —— Eric LiuTalk 07:55, 30 January 2022 (UTC)
  •   Support HynekJanac (talk) 17:35, 30 January 2022 (UTC)
  •   Support BugWarp (talk) 02:20, 31 January 2022 (UTC)
  •   Support Mbkv717 (talk) 20:19, 31 January 2022 (UTC)
  •   Support Alain Artivalys (talk) 13:18, 1 February 2022 (UTC)
  •   Support Bietels (talk) 20:17, 1 February 2022 (UTC)
  •   Oppose KingAntenor (talk) 06:09, 2 February 2022 (UTC)
  •   Support WikiAviator (talk) 09:54, 3 February 2022 (UTC)
  •   Support SlowByte (talk) 18:41, 4 February 2022 (UTC)
  •   Support Bibeyjj (talk) 20:10, 4 February 2022 (UTC)
  •   Support SD hehua (talk) 15:07, 5 February 2022 (UTC)
  •   Support Waldyrious (talk) 15:55, 5 February 2022 (UTC)
  •   Support Exilexi (talk) 17:25, 5 February 2022 (UTC)
  •   Support paul2520 (talk) 18:56, 5 February 2022 (UTC)
  •   Oppose --Ciao • Bestoernesto 03:01, 6 February 2022 (UTC)
  •   Support Vulp❯❯❯here! 03:38, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 05:12, 6 February 2022 (UTC)
  •   Support Lentower (talk) 22:09, 6 February 2022 (UTC)
  •   SupportEric0892 02:21, 7 February 2022 (UTC)
  •   Support Ryse93 (talk) 12:22, 7 February 2022 (UTC)
  •   Support Meiræ 22:07, 10 February 2022 (UTC)
  •   Support Jl sg (talk) 09:13, 11 February 2022 (UTC)
  •   Support evrifaessa ❯❯❯ talk 15:47, 11 February 2022 (UTC)
  •   Support Nehaoua (talk) 16:21, 11 February 2022 (UTC)