Last week’s _php2shell_ PHP vulnerability and breakneck updates caused the WMF to turn off all tools on Toolforge and cloud infrastructure. As the first updates came in, non-PHP tools were reactivated first; for me, that was basically my Rust-based tools. PHP-based tools were reactivated later, but only for PHP 8.x, with tools written for previous versions requiring updates. I took this as an opportunity to take some stock. Some of my PHP tools are single-purpose, but a few are “collections” with small sub-tools. First and foremost among those is (or was) magnustools, which serves as a landing page for all my tools, and also hosts “meta-tools”, to check on the state of my other tools, manage bug reposts etc.. But it also contained several “sub-tools”, in various states of breakage; written for older PHP versions, accessing the wrong Wikidata or Commons database replicas (which had tables moved to other databases), and general bitrot had rendered many of them fully or partially broken. So I decided to do some triage, rescue what I can, and put the dead ones to rest in PHP^W peace. I also wanted to update them visually, give them a more consistent and modern look-and-feel. But the key piece of this transformation was stability and security, and that could only mean Rust. I worked with an LLM, which is surprisingly good at “translating” between programming languages, especially for the relatively small tool scripts, and targeting Rust. When that work was completed, and I had successfully deployed the Rust version as a drop-in replacement, I added the (rescue-able) tools from the “magnus-toolserver” sub-tool group, which are even older and in worse state; some had not been worked on since the original Toolserver was shut down. When PHP-based tools were allowed on Toolforge again, I found several standalone tools (missingtopics, add-information, makeref, and templator, to be specific) that could not be easily upgraded to PHP 8, so I migrated them as sub-tools in the same manner. They are now Rust as well, using the same UI style. All the sub-tools have a drop-down with the others, so you can have a look what else is there. As a side effect, some tools have gained considerable speed, thanks to the fearless concurrency of Rust. If there are problems with these tools (from the rewrite or otherwise), the issue tracker is linked in the footer. The next candidate for rewrite would be wikidata-todo, which also hosts many sub-tools. If you have thoughts about this, or other tools that should be RIIRed (“Rewrite It In Rust”), please let me know on the usual channels!

Match external catalogs (museums, libraries, archives, databases) to Wikidata items. Hundreds of millions of entries across thousands of catalogs.

QuickStatements is a tool for batch processing structured data assertions. Generate a set of command lines, review the proposed batch, and this tool will propagate the data to Wikidata or Wikimedia Commons.

I have ~350 tools running on Toolforge (and on-wiki scripts), so some years ago, I wrote a tool to ~~rule~~ manage them all. That included core to scour my talk pages (and my tools talk pages) on various wikis, github, bitbucket, codeberg, etc. for issue reports, keyword-guess (on wikis) which tool they belong to, and unify the issue reports. As it’s aggregating bug reports, I called it buggregator. I recently thought about the various long-running Rust services I have running on Toolforge, including web pages with compute (e.g. PetScan), background jobs (e.g. Listeria), web APIs (e.g. wd-infernal), and both (Mix’n’match). These are different from the usual PHP-based webservices, which just spawn a script on demand, and forget about once it has run its course. To keep an eye on the Rust services, I added a **dashboard** to buggregator. It tracks all 8 (9 if you count Mix’n’match webservice and background jobs as two separate ones) long-running Rust services, records minutely metrics, and logs restarts and their causes (manually/planned, out-of-memory, crash, killed by the Toolforge watchdog, etc.). It also shows a quick summary of the state of the services. This is primarily for myself, but if you ever find a service of mine unresponsive, feel free to have a look.

In May 2026, I travelled to Milan, Italy, for the Wikimedia Hackathon 2026. It was my first international trip, and an opportunity I had never imagined for myself. I arrived with a project idea, a few days to work on it, and no idea that I would leave with the beginnings of something I would continue building months later. Looking back, Milan was not just about attending an international event. It was about discovering how a community of people with different backgrounds, skills, and interests can turn an idea into something others can use. ## One project finished, another just beginning I arrived in Milan planning to work on a Wikidata watchlist filtering script. The idea was to make reviewing edits more manageable by allowing users to filter their watchlist by categories. I completed the script on the first day. With time left, I joined an unconference session by Satdeep Gill and Silvia Gutiérrez. Their discussion introduced me to WikiLinkua, a language-learning platform built around Wikidata Lexemes and Wiktionary. The idea caught my attention: **what if people could learn a new language using languages they already know, while also helping improve the free knowledge that makes this possible?** Language learning tools often focus on helping people consume content. WikiLinkua offered another possibility: helping learners discover gaps in open language data, such as missing pronunciations or meanings, and creating opportunities for them to contribute back. I started building a prototype in Milan and presented an early version during the hackathon. It was only a beginning, but the project had found its direction. ## Taking the project home Returning to India did not mean leaving the project behind. At the Indic Wikimedia Hackathon 2026 in Hyderabad, organised by the Indic MediaWiki Developers community, I continued working on WikiLinkua. This time, I also had the opportunity to mentor contributors working on the project. Working alongside my mentee, Advait Dintakurti, we developed and deployed Version 0 on Toolforge. Seeing an idea that began as a prototype in Milan become an accessible web application was a rewarding milestone. Just as importantly, the process became an opportunity to collaborate, share what I had learned, and help someone else contribute to the project. You can explore the current version at wikilinkua.toolforge.org or browse the code on GitHub. There is still a great deal to do. WikiLinkua is an evolving project, and feedback, contributions, and ideas from the community will be essential to its growth. ## A journey that began closer to home My involvement with Wikimedia began in 2024, when I had the opportunity to volunteer at the Wikimedia Technology Summit. That experience introduced me to the people and communities behind the technical side of the Wikimedia movement. Since then, I have contributed to Wikimedia-related tools, participated in hackathons, and learned from developers and community members who have been generous with their time and guidance. My journey has also been shaped by the support of the International Institute of Information Technology Hyderabad, which has been an important part of my academic life. I am grateful to everyone who helped make these opportunities possible, including the Wikimedia Foundation for supporting my participation in Milan, the organisers and participants who welcomed me, and the Indic MediaWiki Developers community for providing a space to learn, contribute, and mentor others. ## More than a prototype For me, the most valuable part of this journey has been seeing how participation can grow into contribution, and how contribution can create opportunities for others. I went to Milan intending to build a small technical tool. I returned with a new project, new collaborators, and a better understanding of what it means to build for an open knowledge movement. In Hyderabad, I had the chance to pass on some of what I had learned while working with another contributor. WikiLinkua is still at an early stage, but I hope it can become more than a language-learning platform. I hope it can help connect language learners with the people, data, and communities working to make knowledge available in more languages. If you are interested in language learning, Wikidata, or improving multilingual knowledge, I would love for you to try WikiLinkua and share your feedback. The prototype is only the beginning. What happens next depends on what we build together.

BaGLAMa2 has been collecting view data for Wikipedia pages that contain image from a Commons category tree since March 2010. If your organisation “donated” images, audio, or video to Commons, this kind of data gives highly valuable feedback. Look, out images were viewed 20 million times on Wikipedia last month! There are over 1200 category tree “roots” in the database already. However, this tool has had problems for a long time now, which started with Toolforge moving from grid computing to k8s. The initial version of the tool was written in PHP, and a single grid job would process one category tree and generate a TSV file. Later, I changed that to write all data directly to MySQL, resulting in a 20GB database, which did not scale well. Then I changed it back to storing the main data in files, sqlite3 this time. Meanwhile, the old TSV format and the MySQL data were both kept and supported. However, the k8s switch made the one-script-one-category approach impossible, and so I rewrote the tool in Rust, to run one single job To Rule Them All™. This worked in principle, but database connections and pageview API requests both did not scale well. I then tried a new, more efficient MySQL table approach, which also never took off. Sadly, BaGLAMa2 was stuck in a broken state for years. Now, I tried a new, radically different approach (while staying in Rust, building on existing code). First, I (and my useful slop generator) designed a new, bespoke, and highly optimized format to store results. As before, one file would keep the wiki sites, pages, images, and view counts for one category tree, for one month. However, where the dataset for a whole month would use something like 16GB (sqlite3 files, October 2022), the new format uses ~0.5GB in total for a month. Then, I switched from using the pageview API, to reading the pageview data dump, which is conveniently available on the file system on Toolforge. All site/image/page data gets prepared in advance, which takes ~1h. Then, the compressed pageview dump file is read in its entirety, keeping the relevant view counts, which takes another 15 minutes. In contrast, the previous PHP or Rust processing took several days, and usually left some failed groups for re-run behind. I have already back-filled July, August, and September of 2026. I have also converted all TSV and sqlite3 files to the new format. This has now saved almost half a TB of disk space on Toolforge. I will also convert the MySQL datasets into that format, to be able to retire the backwards-compatible reading (and writing!) code, and reduce the database size from 20GB to almost nothing. The total disk space for storing all BaGLAMa2 data will then be <35GB, with 0.5GB added every month. At this speed, it will take many decades to again occupy the space it did a few days ago, in the old formats. Last not least, the new code will run automatically on the 3rd of each month, processing the pageview data from the previous month.