Wikimedia Commons has more than 100 million freely licensed media files, but many photos still lack structured metadata saying who is in the image. On Commons, that information is usually added through Structured Data on Commons, using the P180 depicts property. When those statements are missing, images are harder to find, reuse, and connect to the rest of the Wikimedia ecosystem. That problem is especially visible for photos of people, where contributors still have to identify the subject and add the metadata by hand.
I built WikiVisage to make that process easier. It is an open source Toolforge tool that helps contributors review faces in Commons images, suggest matches for a specific Wikidata item, and then write approved depicts statements back to Commons. The tool is available at https://wikivisage.toolforge.org/.
The basic workflow is simple. A contributor starts a project with a Wikidata item and a Commons category. WikiVisage crawls the category, detects faces, and asks the user a series of yes or no questions. After a small number of confirmed matches, the tool can suggest likely matches in the remaining images. Nothing is written automatically. The user still reviews the results before any edit is sent to Commons.
Yet another Jimbo shot, August 2005
by Joi Ito,
CC BY 2.0.
Building WikiVisage taught me three lessons that may be useful for other people building tools for the Wikimedia movement.
1. A simple model can still be useful
When people hear “machine learning,” they often expect a large training pipeline and a complicated model. In this case, that was not necessary. WikiVisage works well with a much simpler approach: once a contributor has confirmed a few examples, the tool compares the remaining faces against those examples and suggests likely matches.
That simplicity matters. It keeps the system easier to understand, easier to debug, and easier to run on community infrastructure. WikiVisage is not trying to solve general face recognition. It is helping with one narrow question inside one project: does this face match this Wikidata item?
2. Toolforge shapes the design
Toolforge made this project possible. It gives volunteers a place to host community tools close to the Wikimedia ecosystem, but it also comes with real constraints.
There is no GPU, so the tool has to run on CPU. Memory is limited, so each background worker needs to stay lightweight. I also ran into a less obvious issue with Python multiprocessing inside Kubernetes: over time, leaked semaphores could fill /dev/shm and crash the worker. Replacing multiprocessing.Queue with multiprocessing.Pipe made the worker much more stable.
3. Human review is essential
One thing I did not want was a tool that silently writes machine-generated claims to Commons. WikiVisage can suggest matches, but contributors still have to review them before anything is published. That matters because Commons is a shared public resource. Bad metadata affects search, reuse, and trust across projects.
What could come next
There is still a lot to improve. I would like to explore better model serving through Wikimedia’s Lift Wing platform, and there may also be future work in sharing training data across projects when contributors explicitly opt in.
For Diff readers, the main point is simple: if you are building for Wikimedia contributors, start with a narrow problem, keep the workflow understandable, and design around the realities of community infrastructure. You do not need the most advanced model to build something useful.
WikiVisage is open source on GitHub and live at https://wikivisage.toolforge.org/. If you work on Commons metadata, Toolforge tools, or human-in-the-loop workflows for Wikimedia projects, I would be happy to hear what similar problems you are working on.
Can you help us translate this article?
In order for this article to reach as many people as possible we would like your help. Can you translate this article to get the message out?
Start translation