Wikifunctions:Status updates/2025-05-09

Wikifunctions Status updates

Abstract Wikipedia and the Wikimedia AI Strategy

Last week, the Wikimedia Foundation’s AI Strategy brief was announced. The diff post announcing the brief gives a great summary: our AI strategy is to double down on supporting the volunteers behind the Wikimedia projects.

How does this fit with Abstract Wikipedia? Is there a place for AI technology in Abstract Wikipedia?

A quick sidenote: a few years ago, our plans for Abstract Wikipedia would have been considered use of AI technologies, when topics such as Knowledge Representation and Natural Language Generation were considered sub-fields of AI. But we recognize that times and languages change, and that today the term AI is almost exclusively used to refer to large language models and other machine-learned models. For this text, we accept this terminology.

Right from the start in the paper introducing Abstract Wikipedia in 2020, we sketched out a three-panel UX mock-up about how the editing workflow could work (compare to the mock-up on the right):

The panel on the left is a text box, allowing contributors to write and edit text in their language freely.
The panel in the middle shows an interpretation of the text being entered in the left panel. This is a Wikifunctions object, and the contributor can edit the object directly, in order to fix errors or refine the content. It updates automatically when the text in the left panel is being modified.
The panel on the right shows the text that results from rendering the object in the middle panel. It updates automatically as the middle panel is being modified. It shows the result in a number of languages as selected by the contributor.

To the right is a new mock-up, based on the current interface designs. The idea remains the same.

The step from the middle panel to the right panel is what we are currently working on with Wikifunctions: helping our community write functions that generate natural language text based on abstract content objects. But how do we get from the free text in the left panel to the object in the middle panel?

That’s where we expect language models will come in. A language model would translate the text in the left panel to the abstract representation for the middle panel, prompting the human using the tool to consider if the generated output is what they expect. In 2020, we were merely hopeful that this would work; five years later, the incredible progress in language models are giving us great confidence that this will work, and thus allow us for a feasible UX for Abstract Wikipedia.

Such a usage of AI is exactly aligned with the AI strategy of supporting contributors, by making it easier, faster, and simpler for them to contribute to Abstract Wikipedia. Contributors will not need to learn and remember the constructors we have, or understand how they fit together: the AI will propose that conversion. At the same time, the right panel will allow for an immediate check whether the AI got it right. In the cases it didn’t, the contributor can choose to tweak their input, directly modify the object, or choose one of the alternative interpretations the AI came up with. By seeing the feedback in the form of results in several languages, we can reduce issues with ambiguity and increase confidence that the abstract representation is indeed what a human wanted. This is an iterative, human-in-the-loop approach in which the contributor verifies the content before publishing, making sure to centre the human factor — the many people in our communities who are the key to Wikimedia's success.

The Wikimedia AI strategy also calls for a nuanced approach to multi-lingual support. Here, Abstract Wikipedia has a unique advantage: using Wikifunctions, we can automatically create abstract content and text generated from it, in all languages we have functions and lexemes for! This approach would allow us to train an LLM specifically for Abstract Wikipedia as far as the generation functions support the given language. We hope to get usable interpretations even for languages the foundational model has not been trained on – especially given the human-in-the-loop approach of the user experience.

Thanks to Leila Zia and Chris Albon for their amazing work on the AI strategy brief!

Recent Changes in the software

Our first new embedded-call editing feature lands this week: We now show a "preview" of the result in the dialog as you create or adjust your Function call (T391336). We hope that this helps people use the tool more fluidly.

We've also now added some information to Special:Statistics about the number of Functions, Types, Implementations, Test cases, and overall Objects on the wiki, and also provided these as wikitext magic words, which can be used on the Main Page (T345477).

We adjusted the handler for cross-wiki Function calls to handle invalid JSON input more gracefully, such as when a user tries to call the URL with manually-given (poorly-encoded) input. We extended the visual diffing code we registered with the visual editor to work better, and not leave behind debugging comments.

Our test code was adjusted by User:Umherirrender to be forwards-compatible with PHPUnit 10 by converting our data provider to be static (T332865). We refactored some of our code around errors, dropping a now-unused parameter, and simplified a potential infinite recursion in the test stack by always registering the Z504/Object not found error, so when an Object is not found we only get one level of errors.

As a measure to unbreak the system when a test case triggers an error, we now (at least, temporarily) no longer pass a resultant error into the test-checker, but instead the return value, which will be void (T393156). The system was intended to allow test cases to be written that check that the correct error is returned when bad user input happens (e.g. a user tries to divide by zero, or gets the seventh result from a list of six items), but in practice the error response would sometimes be so large that it would cause the system to choke. In future, we'll consider different ways that we might want to test errors in such cases.

Hackathon 2025 in Istanbul

Members of the Abstract Wikipedia team attended the Wikimedia Hackathon 2025 in Istanbul.

It was great to speak with many people who are curious, excited, intrigued about Wikifunctions and Abstract Wikipedia — and some who are concerned. We hope we answered your queries and sparked further ideas about what will come next. Certainly, we found it hugely valuable to discuss issues like how well natural language generation might scale across the huge range of different languages and content types, possible future uses like rich text or even video output, and the future of citations at Wikimedia and how Abstract Wikipedia might be able to use them most powerfully. We're grateful for everyone's time, and look forward to the next event where we might meet more community members, at Wikimania 2025 in Nairobi.

Virtual community meetings

No recording of this Monday's Volunteers’ Corner has been made, because we decided with the volunteers to have more private conversations and not record.

We are planning the next NLG SIG meeting for May 20, if we get proposed topics for the agenda. Please add your topics here. Otherwise we will cancel the meeting.

Knowledge Graph Insights podcast

Larry Swanson interviewed Denny for Episode 32 of his podcast Knowledge Graph Insights, talking about Wikifunctions, Abstract Wikipedia, and Wikidata. You can listen to the episode from the podcast's website, or wherever you listen to podcasts.

Fresh Functions weekly: 38 new Functions

This week we had 38 new functions. Here is a list of functions with implementations and passing tests to get a taste of what functions have been created. This week, a lot of arithmetic functions in the mix! Thanks everybody for contributing.

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