Wikifunctions:Status updates/2025-11-13

Wikifunctions Status updates

Getting ready for second round of voting for naming the wiki with abstract content

Next week, we will kick off the second and final round of voting for the name of the wiki with abstract content. It will be a new wiki, but pretty much a background project for Wikipedia readers.

The six proposals we are expecting to go into the second round are Abstract Wikipedia, Wikicore, Multilingual Wikipedia, Wikiabstracts, Wikigenerator, and Proto-Wiki. Starting next week, you will have the opportunity to vote for these proposals by ranking them, and then we will aggregate the votes and find out the preference of the community.

Currently, discussions about the proposals are ongoing, with the goal to summarize these discussions in a single table that will offer guidance to the voters. Please feel free to participate in the discussion and also in the summarization effort.

Furthermore we have asked the branding and legal departments of the Wikimedia Foundation to offer advice on the proposals, and are expecting to add these to the table too before the voting starts.

Again, thanks to everyone who participated in the process so far, and looking forward to finding a great name for the new project!

Rewriting the backend: Why Rust?

The Abstract Wikipedia team uses WebAssembly (WASM) for the sandboxing of user-submitted code. This has caused some tension with our services, which are written in Node.js. There are no WebAssembly System Interface (WASI) integrations for Node.js that offer the features necessary to run WASM-based interpreters for Python and JavaScript, nor do the existing integrations allow for control over the WASM sandboxing. The team has therefore been running WASI runtimes in subprocesses, via a command line interface (CLI). This has resulted in complex and brittle logic surrounding the management of nested subprocesses. It's very easy to end up in a situation where a process's parent dies, and the process is then adopted by PID 1.

A mythological and terminological note: on Unix systems, processes can have children and parents. A child process whose parent dies becomes an "orphan process," and this orphan can then be adopted by another process. However, when the orphan is adopted by PID 1 and becomes unkillable, it is referred to as a "zombie process." This is a nonstandard etiology for zombies, to say the least.

In any case, while there are ways to mitigate the zombie process problem, they are hard to integrate into the Wikifunctions service infrastructure. Better still would be to prevent zombie processes from arising at all, which means curbing our reliance on subprocesses.

For this reason, the AW team has decided to re-implement the function evaluator in Rust. Rust offers many feature-rich libraries to interact with WASI, including full WASI runtimes that run inside of Rust itself. In this way, we can avoid relying on subprocesses and instead use threads (or, technically, asynchronous tasks) in Rust. Threads/tasks are much easier to manage. Crucially, our Rust code can ensure that tasks safely shut down after a period of time and that all resources used by the task are deallocated upon exit.

Looking to the future, Rust has other benefits for the Wikifunctions backend. Rust's WASI libraries offer fine control, and can even open up possibilities for new features for native code execution. The team is also considering whether to subject the function orchestrator to the same treatment. A function orchestrator based on Rust would use significantly less memory and CPU, and also provide stronger guarantees about the behavior of the Wikifunctions composition language.

Recent Changes in the software

There's only one user-facing change this week. We have introduced a new pre-defined error, Z576, that will be emitted when the back-end evaluator service is unable to load (T408824); this specific error will now return much more swiftly rather than waiting for the timeout (T408826). These changes are part of work following-up on the Python outage (T406848).

We deployed local caching, in the orchestrator, of results from search requests to Wikidata (T408013). This will speed up calls to some functions that build on Find lexemes for a Wikidata item and/or Find lexemes for a Wikidata lexeme sense. German noun declension table is an example of such a function.

Upcoming NLG/SIG meeting on November 18: exploring design choices from the Uniform Meaning Representation compared to Ninai/Udiron

The next meeting of the NLG SIG is scheduled for Tuesday, November 18, 2025 at 16:00-17:00 UTC on Google Meet. The meeting will be recorded.

Mahir256 is presenting on exploring design choices from the Uniform Meaning Representation compared to Ninai/Udiron.

Asking for help on Wikifunctions: replacing Z28154

We are replacing Z28154 with the built-in Z851. A list of implementations that would benefit from being updated is here, so we can get rid of the duplicated function. We like to ask for help with this task.

Recording of WikidataCon presentations

There were two Abstract Wikipedia related talks at WikidataCon this year. The talks can be watched in the YouTube streams: Mad Libs with Wikidata Lexemes and Abstract Content by Mahir and Wikidata and Abstract Wikipedia: The Now and the Future by Geno. Enjoy the recordings!

Fresh Functions weekly: 33 new Functions

This week we had 33 new functions. Here is an incomplete list of functions with implementations and passing tests to get a taste of what functions have been created. Thanks everybody for contributing!

A complete list of all functions sorted by when they were created is available.