Not long ago, I was just starting out on Wikipedia—learning how to edit, understanding the rules, and slowly building my confidence. I never imagined that one day I’d be guiding others. But recently, I had the chance to do just that at a Wikipedia workshop held at the American University of Iraq in Baghdad, organized by Wikimedia Iraq.

It was my first time mentoring in this kind of setting, and it was both exciting and a little nerve-wracking. I helped participants learn how to create impactful articles and walked them through important sections like introductions, structure, and referencing. It felt amazing to share what I’ve learned so far and see others get excited about contributing too.

One of the highlights of the event was listening to Ali Khalil, who shared eye-opening insights about Wikipedia’s role in spreading free knowledge. His words inspired everyone, including me, and reminded us why this work matters so much—especially for underrepresented languages and regions.

Even though I still consider myself in the middle of my learning journey, this experience showed me that you don’t have to be an expert to make a difference. Sometimes, sharing what you know is enough to help someone else get started.

Mentoring gave me a new kind of motivation. I now feel even more connected to the mission of Wikipedia: making knowledge accessible, inclusive, and reflective of all cultures—including ours.

I look forward to growing more, learning more, and hopefully encouraging more people to join this amazing community.

How does one transition from a Wikipedia reader to a Wikipedia contributor? Since 2024, Wikimedia Ukraine has been working on “Wikipedia for 55+”, a program for engaging senior citizens with Wikipedia inspired by similar projects in the Czech Republic and other countries. After a successful offline course in the city of Poltava last autumn, we launched a similar one in Kyiv.

In the capital city, we partnered with “Let’s help”, a national charity dedicated to senior citizens, which runs a University of the Third Age. Our partners connected us with engaged participants who regularly attend their events and took care of venues for our offline events.

In early February, we held an introductory meeting for the students, attended by 22 people. After the introduction, we split the students into two offline groups, each led by a trainer – Ukrainian Wikipedia editor Natalia Lastovets and Wikimedia Ukraine’s programs coordinator Anton Protsiuk. The groups met for six weekly lessons.

14 participants finished the course. They created Wikipedia accounts, learned how to edit existing articles and upload images – and created a new article of their own.

Let’s look back at the course from the perspective of one of its most active participants, Natalia Huhlenko. 

“Ever since I was in school, teachers noted my innate literacy. When I read any text, grammatical errors immediately catch my eye. When I first encountered Wikipedia (first in Russian, and then in Ukrainian), I was struck by the errors in articles, especially those translated from other languages. This was shocking! After all, this is an ENCYCLOPEDIA! And everything in it should be with encyclopedic accuracy.

When I heard about the ‘Wikipedia for 55+’ course, I realized that this was my chance to contribute to an important cause: properly written and edited articles of the world-famous online encyclopedia. And also to satisfy my inner editor.

Natalia’s enthusiastic speech at the introductory lecture made me want to study even more. She is incredibly passionate about Wikipedia, despite all life circumstances. In addition to the course, I listened to several webinars held by Wikimedia Ukraine at the same time. I was most impressed by the webinar on writing a good article on Wikipedia. The webinar host, Viacheslav Mamon, spends a whole month searching for sources and actually writing an article! I’m not ready for such a feat yet. But translating articles from other languages is for me. It’s really interesting and enlightening.

During the course, I even took part in an article contest about women artists organized by Wikimedia Ukraine.

While working on these articles, I had a lot of questions that I asked my instructor Anton Protsiuk even at 3 am (what can you do? age, insomnia). I always received specific answers with links to training videos. During offline classes, Anton very patiently and thoroughly explained all the technical aspects of using the tools available on Wikipedia.

Thanks to everyone involved for the opportunity to join such a significant project”.

• More info about the course (in Ukrainian)

Today, April 18, the International Day of Momuments and Sites, is the perfect date to present the winners of the special prizes of Wiki Loves Momuments 2024.

In 2024 nearly 240,000 images have been contributed by more than 4,500 photographers in 56 national contests. From this vast collection of pictures documenting monuments and world heritage around the globe the winners were chosen by the juries on national and international level. A warm thank-you from the international coordination team to all who made this competition possible and contributed!

Special prize for Previously Undocumented Monuments

The goal of Wiki Loves Monuments is the documentation of heritage sites. While many places have been covered thanks to all the contributors since the first contest in 2011, there are still monuments that are missing images. To reward photographers who dedicate their work to such sites special prizes are awarded in this category.

Special prize for Places of Worship

Among the oldest, the most impressive and most revered monuments that have been erected over the centuries, many places of worship can be found all over the world. With this special prize we would like to highlight some of the images of such places that have been contributed in 2024.

I applied for the Africa wiki women (AWW) Leadership and Fellowship program because I was eager to gain new skills and knowledge on wikimedia space. The fellowship was designed to:

• Develop leadership skills
• Provide mentorship
• Increase visibility
• Offer real-world Experience
• Promote sustainability

My Fellowship journey

The selection process for the fellowship was competitive, but I was thrilled to be selected as a fellow. The program was structured to last for 6 months. One of the highlights of the program was when I was selected as a project assistant for the Africa wiki women technical research, focus group discussions and to facilitate trainings on Wikidata.

Skills acquired

During the fellowship, I gained new skills that involve sourcing raw qualitative research data, using Google Drive and similar tools to enhance communication and collaboration with my fellows, co-authoring documentation on Diff, and improving my confidence and editing abilities on Wikipedia and Wikidata.

Impact and outcome

The fellowship has had a significant impact on my Wikimedia and organizational work. My communication skills have improved—such as sending bulk emails to international contacts, understanding the Wikimedia mailing list, and creating Wikidata queries. I’ve also had the opportunity to collaborate with others to achieve shared goals.

Overall, my experience as a fellow was incredibly valuable. I gained new skills, made meaningful connections, and developed a deeper understanding of Wikipedia, Wikidata, management, and collaboration. I would highly recommend the Africa Wiki Women Leadership and Fellowship to anyone looking to gain new skills and knowledge within and beyond the Wikimedia space.

The first Wikipedia editing course for neurodivergent people in Ukraine successfully concluded at the end of 2024. It was implemented by Wikimedia Ukraine in partnership with the organization “MH4U – Mental Health for Ukraine.” Let’s look at why we conducted this course, the results we achieved, and what comes next.

🧠 Who are neurodivergent people?
These are individuals whose way of thinking and processing information differs from the generally accepted norm. This includes people with autism, ADHD, dyslexia, anxiety disorders, and other unique neuroprocesses. They may have unique approaches to processing information, learning, and interacting with the world. Most educational programs do not account for such differences, which is why we developed a course adapted to various information perception styles to make learning comfortable and accessible.

“The idea that Wikipedia can be a great hobby platform for neurodivergent people is not new. Wikipedia and its sister wikiprojects offer tasks for both editors with scattered attention and those with focused attention; they support both in-depth work on a single topic and minor edits here and there; here, one can either collaborate with others or avoid interaction altogether, and it’s always possible to take a break without explaining it. It’s said that the proportion of people on the autism spectrum among Wikipedia editors is higher than the average in the general population. Mostly, those who work on Wikipedia discovered it on their own. Not all of this experience has been equally positive. But if we can guide new people who might benefit from it, why not do it🙂,” comments the course trainer (and 2024 Functionary of the Year), Vira Motorko.

📚 What was covered in the course?
Participants learned how Wikipedia works, how to create and edit articles, and how to interact with the Wikipedia community.

💡 The course format included:
✅ Five webinars explaining the basics of editing
✅ Practical homework assignments
✅ Individual feedback from the course trainer

The course was led by Vira Motorko, a volunteer and Wikipedia editor with 15 years of experience.

👥 How did the course go?
38 participants registered for the course, though not all reached the finish line. However, 5 people successfully completed all tasks and received certificates. This is a great result, as for many, editing Wikipedia became a new skill that allows them to expand their knowledge and make the world more open to diversity! 🎓👏

“I think this was a good test run: 5 webinars, 3 homework assignments, answering questions in the chat. I’m grateful to everyone who showed interest and joined. The hardest part for me was sticking to the time limits because I tried my best to keep the webinars short, but I love talking about Wikipedia so much, and there’s so much to say 😇,” comments Vira.

🌍 This course is one of the first in the world!
The idea of a specialized course for neurodivergent people is not entirely new, but so far, it has only been implemented in a few countries. Such a course was held in Israel, and its implementation is ongoing in South Korea. Ukraine is one of the first countries to adapt this approach for its Wikipedia community. We learned about this opportunity during Wikimania 2024, the largest international gathering of Wikipedia volunteers. Inspired by the experience of others, we decided to create our own course and expand opportunities for neurodivergent people in Ukraine to participate in Wikipedia.

A course participant, Polina Abrazhevych, comments:
“I’ve long dreamed of writing and editing articles on Wikipedia but constantly faced technical difficulties and the fear of doing something wrong. Thanks to the course, I figured out the basic principles of how it works and gained the confidence I needed. I especially want to thank you for the inclusive format—despite my ADHD, I was able to complete all the tasks.”

📌 Why is this important?
Editing Wikipedia is not only an opportunity to develop writing and information search skills but also a way to influence the accessibility of knowledge worldwide. We want more people, regardless of their differences, to join the Wikipedia community!

Course results (in Ukrainian) https://blog.wikimedia.org.ua/2025/03/02/neurodivergent-people-and-wiki-results/

What comes to mind when you hear the word ‘hackathon’? Innovation. Collaboration. Code. Now picture doing all of that virtually with over 500 participants from different time zones, more than 10 projects, spoken languages, cultures, situational challenges and internet speeds. That was my recent experience with WMAHack25.

As technical lead for this ambitious three-day Wiki mentor Africa hackathon, I had the honor (and sometimes the discomposure) of witnessing everything that goes into executing a massive event like this. Spoiler alert: it’s a mix of well-planned pandemonium, last-minute choices, and a whole lot of collaboration.

In this writeup, I’ll share what happened during the three day online event, along with everything I had to navigate, the insights I gained, and recommendations for organizers or mentors from my experiences managing such events in or out of the Wikimedia community.

Setting the Stage: Weeks Before the Event

Organizing a hackathon requires a considerable amount of pre-work. For my team and I, it started months prior to the event:

• Defining the target of the event and the participants
• Looking at various event options (online, offline, hybrid)
• Creating Zoom and Telegram groups.
• Spotting interesting projects and their repositories (e.g Gerrit, Github, etc).
• Preparing various onboarding documents (Developer pack, requirements, environment setup, etc)
• Ensuring cross regional document and event access through multiple devices.

Lesson 1: Documenting tasks through a checklist is crucial. Not recalling all arrangements in advance would have undoubtedly been devastating. For instance, we ran through facilitation demos with mentors, which was incredibly rewarding in the end.

Day 1: Let the Hack Begin (And the Glitches Too)

The very first day of the event fed me with a rush of adrenaline. My job was to make sure that mentors, organizers, and participants were able to navigate the virtual space without any problems. Funnily enough, I had to mentor projects too!

From letting participants into Zoom breakout rooms to providing real-time solutions to login challenges, I rapidly discovered that:

• Some users attempting to access Zoom through a web browser face issues that are absolutely infuriating.
• Mentors might be running late or come to the meeting unequipped – unreasonable, but still somewhat explainable.
• Multilingual rooms with no interpreters? That’s begging for distraction and complaints.

Lesson 2: Don’t forget to assign at least one individual to oversee tech support for each session. Also, make sure that there are other communication channels like Telegram that are easily accessible for quick issue resolution.

Day 2: Scaling Support While Keeping the Energy Alive

On the second day, the technical team became the glue holding many moving parts together.

My key tasks included:

• Updating the mentor list and sharing detailed project briefs
• Tagging easy tasks as “Good First Tasks” to onboard beginners
• Conducting check-ins with teams and mentors every 30 minutes
• Monitoring Zoom, Gerrit, and Telegram for any technical hiccups

Challenges? Oh, plenty. To name a few critical ones:

• Some mentors were overwhelmed by the number of groups.
• Others didn’t respond to check-ins.
• A few participants got completely lost in the system.

Lesson 3: Tag floating mentors and create a check action report to track the various teams’ health. When people don’t speak up, proactive support makes a difference.

Day 3: Demos, Deadlines, and Deliverables

The final day was all about showcasing. We created Etherpads to curate demo submissions, shared grading templates, and stayed on-call for technical emergencies.

But it wasn’t smooth sailing:

• Some mentors didn’t update task statuses and didn’t reply to the calls made in their channels early enough to explain why.
• Collaboration requests for final touch-ups were missing causing a bit of distortion in the showcase process.
• Participants needed help figuring out Phabricator task submissions.

Lesson 4: Create a “demo-day toolkit” and run a dry-run. Even a 15-minute walk-through can save hours of confusion.

Post-Hackathon: The Work Isn’t Over

Once the hackathon ended, we shifted to cleanup mode:

• Closing tasks on Project boards (Phabricator) and moving curating incomplete tasks for follow up
• Following up with mentors for task reviews and participants
• Migrating unfinished work to new boards for future tracking
• Creating documentation pages for new projects

Final Thoughts: Leading with People, Not Just Platforms

Lesson 5: Designate post-event stewards. Momentum can easily fade. Having a dedicated follow-up team ensures continued progress.

WMAHack25 was more than a hackathon — it was an opportunity to explore more, and to strengthen leadership, empathy, collaboration and improvisation.

Yes, we handled Zoom links and Phabricator boards. But we also became a bridge between overwhelmed mentors, confused participants, and platforms that occasionally failed us. We had to work all throughout the night during the most active days with highly motivated participants. And through it all, I learned that no tool is more valuable than good communication and a prepared team.

If you’re ever tasked with leading the tech side of a virtual event, remember: prepare for things to break, people to get lost, and timelines to shift. But if you’re ready, calm, and flexible, you’ll be the reason things come back together.

We have a curation of the documents which were used by the technical committee before, during and after the event. An interesting place to start is the “common issues” tab. If you’re able to tackle those, then the rest is, as one of my collaborators would say, “Follow Come” (i.e history).

You can watch the showcase session of the hackathon to have a foretaste of all the projects we worked on. Enjoy!

As the go-to encyclopedia, Wikipedia’s content should reflect the diversity of the real world, but in areas like gender representation, it still falls short. 

The gender gap on Wikipedia extends across subjects and biographies to its contributors themselves – a gap that individuals, organized groups of editors, and organizations like Wiki Education are tackling head on.

In celebration of Women’s History Month, I had the pleasure of bringing together four scholars from across the country to explore the ongoing efforts to close the gender gap on Wikipedia. As part of Wiki Education’s monthly Speaker Series, the event “Persistence & Progress: Confronting Wikipedia’s gender imbalance” sparked meaningful dialogue between the panelists and our global audience.

Despite the ongoing and concentrated efforts of individuals and organizations alike, why do these gaps continue? One key reason is the precarity of labor as it relates to who contributes to Wikipedia, explained panelist Kira Wisniewski, Executive Director of Art + Feminism.

“It’s truly incredible that Wikipedia is the effort of millions of volunteers, but who actually has the ability to volunteer?” asked Wisniewski. “[For example], there have been many studies about how women, and particularly women of color, have been disproportionately affected by COVID. When you think of the factors of who is even able to volunteer, it helps reveal more answers on how these gaps appear and persist.”

Information activism and the work to support new editors is more important now than ever, emphasized Wisniewski: “What do people edit about? They edit about things they know…so that’s why working with students and getting people editing is so important.”

And there’s no doubt that professors like panelist Caroline Smith and her students are making significant progress in filling these gaps. Through their Wikipedia assignments, Smith’s students have collectively contributed 100,000 words to Wikipedia – and their work has been viewed more than 8 million times!

From the first time Smith incorporated the assignment into her Communicating Feminism course at The George Washington University, she noted how the coursework on Wikipedia resonated with her class. When her students looked for gender gaps in the online encyclopedia, they were surprised by just how much was missing – and that surprise created a sense of urgency to improve it, Smith observed.

“[They] found it so interesting and rewarding, and I think it spoke to some of the historical issues we were discussing throughout the semester in a really real, tangible way,” said Smith, who shows her students Wikipedia articles about their own institution to highlight gender gaps. “They were shocked to find that the amount of space devoted to the [Women’s Leadership] program is much less than some of the other things that happen on George Washington’s campus. Students see that and realize, even in this space I’m occupying right now, we’re seeing these imbalances.”

Like Smith, panelist Siobahn Day Grady also teaches with Wikipedia with free support from Wiki Education, empowering her students to add notable women and other historically excluded figures to the encyclopedia. Initially unsure about bringing a Wikipedia assignment into her course, Grady ultimately found the experience rewarding, just like her students.

“There are so many times when people don’t even recognize that they are worthy to have a Wikipedia article, that their contributions matter,” said Grady, a professor at North Carolina Central University. “I really take these moments as pure joy to celebrate the achievements of women doing amazing things that may not have an opportunity to have their work shared, if not through this work that we do with Wiki Education.”

Panelist Whitney James enrolled in a Wiki Education editing course in summer 2024 to learn how to contribute to Wikipedia herself, then incorporated Wikipedia assignments into her first-year writing courses. 

But the University of Notre Dame professor didn’t stop there – she joined two more of our editing courses to improve Wikipedia’s coverage of women herself. As a new editor, James worked to improve existing content and created new Wikipedia articles for notable women including investor Tracy Gray and corporate sustainability expert Esther An.

“I feel like this work has a low barrier for entry and a really high impact,” said James. “It’s also very rewarding for me personally, which is an important self-care thing to think about. This is a really important space right now, and I’m happy to be part of it.”

As we wrapped up the discussion, I asked the panelists if they had advice for anyone who found our conversation interesting and liked the idea of a more inclusive Wikipedia, but didn’t feel like their individual efforts could make a difference on closing the gender gap. Smith kicked us off with a simple answer and a laugh.

“I would just say, no, that’s wrong,” said Smith. “Every voice matters and can make a difference. Maybe that’s oversimplifying, but I feel like it takes a lot of little movements to create broader change.”

Catch up on our Speaker Series on our YouTube channel and join us for our next webinar on Tuesday, April 22!

En “abling” Change: How Wiki Education is tackling disability on Wikipedia

Tuesday, April 22, 2025
11 am Pacific /  2 pm Eastern
REGISTER NOW

Interested in incorporating a Wikipedia assignment into your course? Visit teach.wikiedu.org to learn more about the free resources, digital tools, and staff support that Wiki Education offers to postsecondary instructors in the United States and Canada. 

Visit learn.wikiedu.org to explore our editing courses for subject matter experts.

Connect with Art + Feminism at artandfeminism.org.

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Weekly highlight

• Later this week, the default thumbnail size will be increased from 220px to 250px. This changes how pages are shown in all wikis and has been requested by some communities for many years, but wasn’t previously possible due to technical limitations. [1]
• File thumbnails are now stored in discrete sizes. If a page specifies a thumbnail size that’s not among the standard sizes (20, 40, 60, 120, 250, 330, 500, 960), then MediaWiki will pick the closest larger thumbnail size but will tell the browser to downscale it to the requested size. In these cases, nothing will change visually but users might load slightly larger images. If it doesn’t matter which thumbnail size is used in a page, please pick one of the standard sizes to avoid the extra in-browser down-scaling step. [2][3]

Updates for editors

• The Wikimedia Foundation are working on a system called Edge Uniques which will enable A/B testing, help protect against Distributed denial-of-service attacks (DDoS attacks), and make it easier to understand how many visitors the Wikimedia sites have. This is so that they can more efficiently build tools which help readers, and make it easier for readers to find what they are looking for.
• To improve security for users, a small percentage of logins will now require that the account owner input a one-time password emailed to their account. It is recommended that you check that the email address on your account is set correctly, and that it has been confirmed, and that you have an email set for this purpose. [4]
• “Are you interested in taking a short survey to improve tools used for reviewing or reverting edits on your Wiki?” This question will be asked at 7 wikis starting next week, on Recent Changes and Watchlist pages. The Moderator Tools team wants to know more about activities that involve looking at new edits made to your Wikimedia project, and determining whether they adhere to your project’s policies.
• On April 15, the full Wikidata graph will no longer be supported on query.wikidata.org. After this date, scholarly articles will be available through query-scholarly.wikidata.org, while the rest of the data hosted on Wikidata will be available through the query.wikidata.org endpoint. This is part of the scheduled split of the Wikidata Graph, which was announced in September 2024. More information is available on Wikidata.
• The latest quarterly Wikimedia Apps Newsletter is now available. It covers updates, experiments, and improvements made to the Wikipedia mobile apps.
• View all 30 community-submitted tasks that were resolved last week.

Updates for technical contributors

• The latest quarterly Technical Community Newsletter is now available. This edition includes: an invitation for tool maintainers to attend the Toolforge UI Community Feedback Session on April 15th; recent community metrics; and recent technical blog posts.
• Detailed code updates later this week: MediaWiki

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

The long-awaited Semantic MediaWiki 5 is here! Discover the improvements it brings.

As maintainers of Semantic MediaWiki (SMW), Professional Wiki is responsible for releasing new versions. We are pleased to announce that both Semantic MediaWiki 5 and Semantic Result Formats 5 are now available.

Highlights

Version 5 brings support for MediaWiki 1.43, the latest LTS release. It also brings support for the latest versions of PHP, up to version 8.4. The minimum required versions have been raised to MediaWiki 1.39 and PHP 8.1. For more detailed information, see the compatibility matrix.

Various of the SMW user interfaces have been refreshed. They are now more consistent, look better on mobile devices, and integrate better with MediaWiki's new Codex system. A good example is the overhauled DataTables format, depicted below.

Various front-end performance improvements have been made, improving page load speed.

You can find the full list of changes in the SMW 5 release notes and the Semantic Result Formats 5 release notes.

Professional Semantic MediaWiki Services

At Professional Wiki, we provide Semantic MediaWiki services, including SMW hosting, SMW software development, SMW consulting, and various MediaWiki services.

You can try out Semantic MediaWiki via the free trial on ProWiki.

For those deeply involved with Wikidata, the richness of its interconnected data is both a blessing and a challenge when it comes to programmatic access. While the standard wbgetentities API endpoint is fundamental, retrieving the complete set of properties, including labels and values, for a given item often leads to a cascade of recursive API calls. For example, suppose we fetch all properties for Q42 using wbgetentities API - https://www.wikidata.org/w/api.php?action=wbgetentities&ids=Q42. In the response, if well lookup the “country of citizenship” (P27) for Q42 (Douglas Adams): the initial response only provides the target QID (Q145), necessitating further queries to resolve both P27 and Q145 into human-readable labels. This quickly becomes inefficient for comprehensive data extraction.

The need to retrieve all information visible on a Wikidata item’s page – properties, statements, qualifiers, and their corresponding labels – is a common requirement. However, the inherent limitations of the standard API make this a cumbersome process.

The standard API’s approach of returning only the QID for properties and values means that developers often find themselves in a loop of making multiple API calls to resolve these IDs into meaningful labels. This not only increases the complexity of the code but also leads to performance issues due to the high number of requests made to the API.

The solution lies in leveraging the expressive power of SPARQL. A carefully constructed SPARQL query can efficiently fetch all the required details in a single request. The following query demonstrates this capability:

SELECT
  ?property
  ?propertyLabel
  ?statementValue
  ?statementValueLabel
  ?statementValueImage
  ?qualifierProperty
  ?qualifierPropertyLabel
  ?qualifierValue
  ?qualifierValueLabel
  ?unitOfMeasure
  ?unitOfMeasureLabel
  ?statementRankLabel
WHERE {
  VALUES ?item {wd:%s}
  ?item ?propertyPredicate ?statement .
  ?statement ?statementPropertyPredicate ?statementValue .
  ?property wikibase:claim ?propertyPredicate .
  ?property wikibase:statementProperty ?statementPropertyPredicate .
  ?statement wikibase:rank ?statementRank .
  BIND(IF(?statementRank = wikibase:NormalRank, "Normal", IF(?statementRank = wikibase:PreferredRank, "Preferred", IF(?statementRank = wikibase:DeprecatedRank, "Deprecated", "Unknown"))) AS ?statementRankLabel)
  OPTIONAL { ?statementValue wdt:P18 ?statementValueImage . }
  OPTIONAL { ?statement ?qualifierPredicate ?qualifierValue . ?qualifierProperty wikibase:qualifier ?qualifierPredicate . }
  OPTIONAL { ?statement ?statementValueNodePredicate ?valueNode . ?valueNode wikibase:quantityUnit ?unitOfMeasure . }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "%s, en" . ?property rdfs:label ?propertyLabel . ?statementValue rdfs:label ?statementValueLabel . ?qualifierProperty rdfs:label ?qualifierPropertyLabel . ?qualifierValue rdfs:label ?qualifierValueLabel . ?unitOfMeasure rdfs:label ?unitOfMeasureLabel . }
}
ORDER BY ?property ?statementValue ?qualifierProperty ?qualifierValue

Executing this query (replace %s with the desired QID, e.g., Q42) on the Wikidata Query Service yields the raw data.

Example for Q42: query

qjson

While the SPARQL query provides the necessary data, the direct output often requires significant post-processing to achieve a usable, structured format. To address this, I’ve developed qjson, a Toolforge API designed for efficient and structured retrieval of all properties for a given Wikidata item.

qjson simplifies this process by handling the SPARQL query execution and structuring the response into a clean JSON format, complete with labels in the specified language.

Usage Examples:

• Fetching all data for Q405 (Moon) in English: https://qjson.toolforge.org/Q405.json
• Retrieving the same data in French: https://qjson.toolforge.org/Q405.json?lang=fr

To minimize unnecessary load on the Wikidata infrastructure, qjson implements response caching with a defined TTL. This ensures efficient data retrieval for frequently accessed items.

Source code: https://gitlab.wikimedia.org/santhosh/qjson. This tools is written in Go programming language.

Disclaimer

I work at the Wikimedia Foundation. However, this project, exploration, and the opinions expressed are entirely my own and do not reflect my employer’s views. This is not an official Wikimedia Foundation project.

GitHub has always been a great code host. But GitHub’s code review system was an afterthought. Even now, Pull Requests still lag behind.

Oh yeah, there’s pull requests now

– GitHub blog, Sat, 23 Feb 2008

When GitHub launched, it had no code review.

GitHub’s Pull Request model—“GitHub flow”—was never designed. It emerged.

But over time Pull Requests became the default way to collaborate via Git, and we’re all still suffering the consequences.

First-generation Pull Requests

GitHub never used git’s built-in git request-pull.

According to Linus Torvalds—Git’s creator—GitHub “decided to replace it with their own totally inferior version.”

When the Pull Request debuted in 2008 it worked like this:

1. Create a fork and click “Pull Request.”
2. Send a message to someone¹ with a link to your fork, asking them to merge it.

But while git request-pull generates a nicely formatted message with a diff stat and changelog, GitHub hamstrung Pull Requests.

GitHub provided only a small, empty <textarea>—Pull Requests were little more than unstructured emails to other GitHub users.

And Pull Requests still lacked any way to see changes via the web.

“Code Review = Discussion + Code”?

It took two years for GitHub to show the git diff between two repos on GitHub.

In 2010, “cross repository compare view” coupled with an unthreaded comments section and became Pull Requests 2.0².

Of course, the code and the comments were still on two different pages. It took another year before you could comment in the code.

03/04/2025-09/04/2025

Mapping

• Please cast your vote in the proposal to map grab rails in (wheelchair accessible) toilets.
• Comments are being requested for these proposals:
  • A tagging scheme proposal for windmills and watermills that aims to clarify the distinction between building=windmill and man_made=windmill. It also proposes the introduction of a new key, windmill=*, to further refine the classification of these structures.
  • armrest:*=* for tagging whether of not a toilet is equipped with arm rests.

Community

• Pedro Tharg wrote ►, in his diary, about using MapBiomas data in OpenStreetMap and suggested tagging for different land cover and land use classes. MapBiomas is a collective project that officially began in Brazil in July 2015 and is organised collaboratively by NGOs, universities, laboratories, and technology start-ups.
• Looking for a holiday destination for hiking or cycling? How about a region where many paths in OpenStreetMap don’t yet have any surface information? Nakaner’s presentation at FOSSGIS 2025 and the maps he produced will show you where your help is needed. The slide deck from the presentation and the map are available, and you can watch his video.

OpenStreetMap Foundation

• Michael Spreng, from the OpenStreetMap Foundation’s Membership Working Group, announced that OSMF members will now need to renew their memberships manually, as the foundation has temporarily halted automatic renewals via PayPal. The decision follows ongoing issues with the automated system, where payments often fail to register correctly.

Events

• Dani Waltersdorfer, a board member of the OpenStreetMap Foundation, has shared her insights following her participation in the State of the Map Latin America 2024 conference, held in Belém, Brazil.
• FOSSGIS announced ► the successful completion of the 2025 FOSSGIS Conference, held in Münster from 26 to 29 March. Co-organised with the OpenStreetMap community and the University of Münster’s Institute for Geoinformatics, the event took place at Münster Castle, with a large tent on the castle square accommodating attendees and hosting exhibits and posters. Over 1000 participants joined, including 750 on-site and more than 350 online.
• The recordings of the FOSSGIS 2025 conference are available . These include vehicle localisation in DB Regio [1] , coordinate reference systems for D-A-CH [2] and 2.5D indoor maps based on OpenStreetMap data [3] .
• Séverin Ménard will conduct a virtual workshop, in English, on mapping building damage using post-disaster imagery in OpenStreetMap on Thursday 17 April at 7:00 PM UTC via BigBlueButton. The session will cover mapping techniques using JOSM and mark the kick-off of a mapathon focused on the French overseas department of Mayotte, which was damaged by Cyclone Chido at the end of 2024.
• Volker Krause shared his insights and personal notes on OSM indoor navigation, the Transitous public transport routing service, and OpenTransport, following his participation in the FOSSGIS Conference 2025.
• The State of the Map Organising Committee has launched a travel grant programme, aimed at enhancing accessibility for participants attending the State of the Map 2025 Conference, set to take place in Manila from 3 to 5 October. Applications for the grant are now open and will be accepted until Friday 16 May at 12:00 UTC.

Education

• Mapeducação, a programme that aims to map public and private schools and educational institutions has started ► in the Municipality of Jacobina, Bahia, Brazil. The programme aims to facilitate access to the schools’ data, helping to facilitate the enrolment process, for example.

Maps

• OpenLocalMap is a map of Catalonia originally created [ca] from a project run [ca]► by the non-profit association la Konfraria de la Vila del Pingüí, from la Palma de Cervelló. Now maintained by OSM-Catalan, the map incorporates data from la Palma de Cervelló and Vilanova i la Geltrú from OpenStreetMap. The code is available on GitHub.

OSM in action

• ^[1] Herr Voeglein tooted that the latest issue of Fahrrad Zukunft featured ► an in-depth article on BRouter, a customisable, elevation-aware bike routing app that uses OSM data. The article also outlined how to connect the BRouter Android app to Osmand, OruxMaps, or LocusMap.

Software

• Jake Low’s pull request has resulted in OSMCha now getting changes from an OSM adiff service, rather than using the Overpass API. This code change should result in OSMCha being able to handle displaying larger changesets more quickly.
• Ralph Straumann reported that Fabian Rechsteiner has developed a performance benchmark comparing six open-source vector tile servers that are used to deliver tiles from a PostgreSQL/PostGIS database.

Programming

• Nick Walker has added Overpass QL syntax highlighting support for .overpassql files on GitHub. It is based on the Overpass QL syntax VS Code extension and was made possible by standardising the file extension (we reported earlier).
• Kumakyoo continued his series on his new OMA file format with a description of how relations are handled.

Releases

• MapLibre has published its March Newsletter with notices about new releases for the MapLibre GL JS and the Martin Tile Server.
• Version 2.1.0 of osm2pgsql has been released, bringing several enhancements aimed at better integration with connection poolers and other database middleware.

Did you know that …

• … the OSM welcome tool can be used to monitor and message new contributors in your region? It’s a great help to send a welcome message to new OSM members and inform them about local chat groups and such. Messages like this can increase the likelihood of those users sticking around and continuing to contribute to OSM.

Other “geo” things

• Between science and art, the ‘Forest Cartographies’ exhibition is showcasing ► HD LiDAR data, from the Marne forests, from 8 April to 28 June in Reims (France).
• Several car accidents linked to Google Maps have occurred ► during Indonesia’s recent Mudik season, a massive annual homecoming ahead of Eid al-Fitr, involving millions of travellers. A driver in Ponorogo ended up stranded in a rice field after following Google Maps directions onto what turned out to be a non-public road. In a separate incident in Gresik, a BMW sedan drove off the edge of an unfinished ► toll road.
• EOS Landviewer offers users free access to 10 satellite imagery scenes per day, including recent high-resolution data from Sentinel-2 L2A and Landsat 8 RT.
• Christopher Beddow discussed the distinction between discovery and rediscovery, arguing that the act of digitising elements of the physical world constitutes a form of rediscovery. By transforming tangible realities into digital formats, knowledge once confined to a select few becomes accessible to all, unlocking the potential for instant, widespread awareness.
• Texty.org.ua has published ► an analysis on the disappearing snow in Ukraine, noting that the last snowy winter across much of the country occurred in 2020–2021, with the most widespread and heavy snowfall recorded in 2016–2017. Citing data from MODIS satellite imagery, they highlight a cyclical trend; snowier winters tend to follow several years with little to no snow.
• The BnF (French National Library) has been backing up ► French websites since 2006 by automated collection, in a similar way to the Internet Archive. Pierre Bonneau and Dorothée Benhamou-Suesser (from the BnF) noted that this method is very effective for many sites but not for dynamic sites such as OSM. Even when queries are programmed, the collection and output are generally of poor quality or even non-existent. Christian Quest replied that it has been proposed in the past to provide VMs (virtual machines) of the tile generator, with the data frozen at 1 January and using the map style of the time, as demonstrated in this prototype. The rest of the discussion identified the most suitable solution as a VM for each past and future year, using an LXC container.
• Charlie Plett has created an interactive historical map of Mennonite villages powered by OpenHistoricalMap and MapLibre.

Upcoming Events

Where	What	Online	When	Country
København	OSMmapperCPH		2025-04-13
Delhi	15th OSM Delhi Mapping Party		2025-04-13
Grenoble	Atelier adressage dans OpenStreetMap		2025-04-14
中正區	OpenStreetMap x Wikidata Taipei #75		2025-04-14
	Missing Maps London: (Online) Mid-Month Mapathon [eng]		2025-04-15
Lyon	Réunion du groupe local de Lyon		2025-04-15
Bonn	187. OSM-Stammtisch Bonn		2025-04-15
San Jose	South Bay Map Night	✓	2025-04-16
Lubbock	A Synesthete’s Atlas: Cartographic Improvisations		2025-04-16
Lüneburg	Lüneburger Mappertreffen	✓	2025-04-15
Amsterdam	Maptime Amsterdam: Springtime Mapping Party		2025-04-16
Marche-en-Famenne	OpenStreetMap Belgium au salon Municipalia		2025-04-17 – 2025-04-18
	MapRVA Map & Yap		2025-04-18
	Workshop – mapathon: post-cyclone assessment of building damage		2025-04-17
	OSMF Engineering Working Group meeting		2025-04-18
Mumbai City	2nd Mumbai Mapping Party		2025-04-20
Aketi	Mapathon for Kinshasa City,		2025-04-21 – 2025-04-25
Hannover	OSM-Stammtisch Hannover		2025-04-22
Kiel	Kieler Mapper*innentreffen		2025-04-22
Derby	East Midlands pub meet-up		2025-04-22
	Missing Maps – DRK & MSF Online Mapathon		2025-04-23
	[Online] OpenStreetMap Foundation board of Directors – public videomeeting		2025-04-24
Zaragoza	Mapatón Humanitario Universidad de Zaragoza		2025-04-24
	Atelier – mapathon: évaluation post-cyclonique des dommages aux bâtiments		2025-04-24
	SOSM Annual General Assembly		2025-04-25
	OSMF Affiliation Focus Group Discussion: Thematic and non-geographical groups		2025-04-26

Note:
If you like to see your event here, please put it into the OSM calendar. Only data which is there, will appear in weeklyOSM.

This weeklyOSM was produced by MatthiasMatthias, Raquel Dezidério Souto, SeverinGeo, Strubbl, TheSwavu, YoViajo, barefootstache, derFred.
We welcome link suggestions for the next issue via this form and look forward to your contributions.

At Fosdem 2025 I had the opportunity to arrange the Web Performance developer room together with Dave, Julien and Nazim from Mozilla.

FOSDEM is a completely free and open conference held annually in Brussels, Belgium, dedicated to promoting free and open-source software and knowledge sharing. One thing I particularly like about FOSDEM is that all speakers volunteer their time and expertise, making it truly community-driven. All sessions were recorded, so I'm excited to share the videos here for those who couldn't attend.

Our developer room was fully packed during several sessions, it was great to see that people still care about web performance.

Here are the talks from our Web Performance room this year:

• How browsers REALLY load Web pages - Robin Marx (video)
• Making Sense of the Long Animation Frames (LoAF) API - Andy Davies (video)
• Scheduling HTTP streams - Alexander Krizhanovsky (video)
• Chromium on Android: How we doubled Speedometer & developed the LoadLine benchmark - Eric Seckler, Gurj Bahia (video)
• Collaborate using the Firefox Profiler - Nazım Can Altınova (video)

Enjoy watching the talks!

The Wikimedia Foundation is committed to investing in the digital rights ecosystem by supporting civil society organizations advocating public policies that support human rights online. For the fourth consecutive year, we are championing the work of Paradigm Initiative and supporting their annual conference, the Digital Rights and Inclusion Forum (DRIF).

Paradigm Initiative is a nongovernmental organization dedicated to advancing digital rights across Africa and providing digital opportunities for young people. Their commitment to promote an open, accessible, and affordable internet for all aligns closely with our mission to enable a world in which everyone, everywhere, can contribute to free knowledge. DRIF is emblematic of Paradigm Initiative’s objectives: it provides a space for diverse voices to discuss digital rights, internet governance, and inclusive technology policies.

This year, DRIF25 will have the theme “Promoting Digital Ubuntu in Approaches to Technology” and take place in Lusaka, Zambia, from 29 April to 1 May. Ubuntu is an African concept and philosophy that emphasizes interconnectedness and mutual support between individuals and societies. These values are at the core of Wikimedians’ work, and are also an inherent through line in our DRIF sessions this year: not only are we advocating open knowledge and digital equity, but we’re also addressing critical issues—from systemic biases in AI regarding gender representation to strengthening digital rights and electoral participation across the African continent.

DRIF25 will be held in person and live-streamed on Paradigm Initiative’s YouTube channel. Whether you’ll be in Lusaka or staying at home, join our sessions!

Wikimedia and Digital Human Rights in Africa. Empowering Communities: The Role of Wikimedia in Advancing Digital Human Rights in Africa

Wednesday, 30 April, 14:00–15:00 Central Africa Time (CAT), Room 2

As Africa’s digital landscape expands, the intersection of knowledge sharing and human rights has become critical. Wikimedia projects, such as Wikipedia, Wikidata, and Wikimedia Commons, are powerful tools for democratizing access to information, fostering digital inclusion, and promoting freedom of expression. However, barriers such as unequal internet access, language representation, and digital literacy hinder the full potential of these projects. In the African context, digital human rights—including the right to access information, participate in cultural and educational life, and enjoy online freedom of expression—are often compromised by structural inequalities, restrictive policies, and lack of localized content. Wikimedia’s open knowledge platforms provide an avenue for addressing these challenges while empowering communities to contribute to and access free, reliable, and diverse information. This session explores how Wikimedia aligns with digital human rights in Africa and its role in promoting inclusive, equitable access to knowledge.

Participants: Levy Syanseke (Ramah Designs); Emmanuel Oruk (Wikimedia Community User Group Uganda); Sandra Aceng (WOUGNET); Kanguya Isaac (Wikimedia User Group Zambia).

Empowering Women and Communities: Digital Rights, Inclusion, and the Role of Wikimedia in Africa’s Future

Wednesday, 30 April, 15:40–16:00 Central Africa Time (CAT), Room 4

The digital revolution has great potential to empower women and other marginalized communities; yet, it is equally plagued by serious problems of access, rights, and representation. This session will examine the critical points of digital rights and inclusion, with a focus on the role and agency of women in shaping Africa’s digital future. We will discuss how initiatives like Wikimedia go about closing the gender gaps in digital platforms by creating spaces for women to contribute toward the creation, sharing, and protection of knowledge in digital spaces. The session will examine the impact of digital rights on women’s freedom of expression, privacy, and access to information, with a focus on the need for policies that protect these rights. Then it will share knowledge on how platforms like Wikimedia are creating an inclusive, gender-equitable digital space by equipping women and underrepresented communities with the skills to create, edit, and preserve digital knowledge. This session will paint a vision of a future where women are not just consumers of technology, but active agents of change through addressing barriers to digital inclusion and advocating for gender-sensitive digital policies. 

Participants: Candy Khohliew (Wikimedia Botswana).

Inclusive Electoral Participation in Africa: Lessons from the Ghana Polls Project

Thursday, 1 May, 9:50–10:50 Central Africa Time (CAT), Room 1

Ghana has long been celebrated as a beacon of democracy in West Africa. As Ghana approached the 2024 general elections, upholding that legacy motivated the Open Foundation West Africa (OFWA) to launch an initiative that combined digital innovation and community engagement to help foster a climate of peace, tolerance, and respect among political parties, candidates, and voters. The Ghana Polls Project aligns with global efforts such as UNESCO’s #SocialMedia4Peace initiative, which has been implemented in regions as far-reaching as Indonesia, demonstrating the universal need for combating misinformation and promoting informed electoral participation through digital tools. This session combines a demonstration of the Ghana workshop and a panel discussion to explore the intersection of digital resources, civic education, and governance. It focuses on how technology bridges gaps in electoral information access for underrepresented groups like women and rural populations.

Presenters: Jael Serwaa Boateng (Open Foundation West Africa); Felix Nartey (Wikimedia Foundation); Emmanuelle Kakou (Wikimedia Côte d’Ivoire); Paul Mandele (Wikimedia Community User Group Tanzania).

Bridging Gender Gaps in AI: Advancing Equity Through Open Knowledge

Thursday, 1 May 01, 12:10–13:10 Central Africa Time (CAT), Room 2

This workshop explores how open knowledge platforms, such as Wikimedia, can address systemic biases in artificial intelligence (AI) and promote gender equity in digital spaces. AI technologies often replicate societal inequalities due to biased data sources, leading to the underrepresentation of marginalized voices. By leveraging inclusive, diverse, and accessible knowledge practices, we can ensure AI systems reflect and empower the full spectrum of human experiences.

Wikimedia has played a critical role in advancing gender equity by addressing systemic gaps in representation across its platforms. Through impactful initiatives like Whose Knowledge?, Art+Feminism, Let’s Connect, and She Said, and partnerships with WOUGNET, Wikimedia highlights the power of open knowledge to challenge biases and amplify underrepresented voices. Programs focus on diversifying data sources, creating inclusive content, and fostering equitable storytelling to build a foundation for AI systems that are ethical and just. Participants will engage in interactive discussions and hands-on activities, including creating inclusive content on Wikipedia. The session will also explore Wikimedia’s strategies for gender-responsive governance, equity in AI development, and ethical digital practices. By fostering collaboration between local Wikimedians and global platforms, this workshop aims to inspire participants to become advocates for open knowledge and digital equity.

Presenters: Candy Khohliwe (Wikimedia Botswana), Bridgit Kurgat (Wikimedia Foundation); Felix Nartey (Wikimedia Foundation).

The Wikimedia Foundation’s continued support for DRIF underscores our commitment to engaging in critical digital rights conversations and advancing the Wikimedia 2030 Movement Strategy.

By supporting this convening, we contribute to a broader ecosystem of digital rights activists and civil society organizations working to shape inclusive and rights-respecting policies for the internet. At the same time, DRIF25 provides a vital opportunity for Wikimedians across Africa to connect, collaborate, and strengthen their networks with key policy stakeholders in their respective countries.

This year’s theme, “Promoting Digital Ubuntu in Approaches to Technology,” resonates deeply with our movement’s mission to foster inclusion and equity online, ensuring that youth, women, and Indigenous communities are represented in the digital space.

Be sure to follow along, engage with your fellow Wikimedians, and be part of the conversation. We look forward to seeing you there!

In WikiAfrica Hour’s 44th Episode, aired live on 26th March 2025, guest host Isla Haddow-Flood discusses the main challenges that affect women’s participation and contribution, the ideal ratio of women’s participation, what role our community initiatives play in empowering women and what we need furtherly.

I was shocked to discover that most of Wikipedia and other project readers are male. Only about 20-30% of women actually read Wikipedia, and we know that there is a funnel from readers to editors to admins and other online activities. So because Wikipedia was started by men, they are interested in male content. So there are a lot of articles about football clubs and cars and everything, but there are virtually no articles about designers, fashion and cosmetics, whatever. So women are looking for content online and finding it in other places, and that’s already reducing the number of women that look at the content. – Victoria Doronina

In my opinion, the mentorship could be a mediation tool between this person’s desire and community to bring the communication between the two and say to one person, okay, this is not going to be possible. You are not going to be able to put all the fairy tales on Wikipedia, but you will be able to write about the authors of the fairy tales and bring data into wiki data. – Natacha Rault

This WikiAfrica Hour episode’s guest host is Isla Haddow-Flood,  the chair and the co-leader of Wiki In Africa. She is also the co-founder of our Wiki Loves Women initiative that has both developed a cohort of female leaders across Africa through our programs and the on-going Focus Group. Wiki Loves Women has brought gender-focused initiatives such as SheSaid, the Inspiring Open podcast, and the ISA Tool’s Tell Us About Her to the movement. 

Our guests include:

• Victoria Doronina: She started contributing to Russian Wikipedia in 2006, became an admin, and twice served on the Arbitration Committee. In 2021, she was elected to the WMF Board of Trustees and re-elected in 2024.
• Bukola James: certified librarian. Sub-Saharan Liason of Let’s Connect. Co-founder pf Africa Wiki Women. Vice Chair of Wikipedia+Education User Group. Chairman of Learnovation Network Foundation
• Franziska Heine: Executive Director of Wikimedia Deutschland
• Natacha Rault: Director of les sans pagEs

The WikiAfrica Hour In Focus segment was a recorded inspiring open interview with Victoria Doronina (one of the guest speakers) to shed light on her journey in the open wikimedia movement.

This WikiAfrica Hour episode aired live: check out our Website or the WikiAfrica Hour meta page to watch this or previous episodes.  All WikiAfrica Hour episodes are available on YouTube.

In my previous post, we got to the point of being able to create a new Wikibase Entity, it is stored in the MediaWiki database as a page, however we can’t actually view it via any interface currently.

In this post, we will work through another set of code changes, tackling each issue as we see it arise, until we can see the entity represented in the various places that users might expect.

Viewing the page

The provided entity serialization is neither legacy nor current

When clicking on one of the links on Special:RecentChanges to a phrase page that we have created, we get our first error.

/wiki/Phrase:Phrase66900b01937842.29097733 MWContentSerializationException: The provided entity serialization is neither legacy nor current
from /var/www/html/w/extensions/Wikibase/lib/includes/Store/EntityContentDataCodec.php(253)

The full stack trace is a little large, but you can find it in a paste bin.

This error is very similar to an issue we saw in the creation blog post, but this time the codec class can not deserialize what we have stored in the database, as we have not registered a deserializer for phrases.

Adding a deserializer to the entity registration file is very simple:

Def::DESERIALIZER_FACTORY_CALLBACK => static function ( \Wikibase\DataModel\Deserializers\DeserializerFactory $deserializerFactory ) {
        return new PhraseDeserializer();
},

And the serializer itself can look something like this:

<?php

namespace Wikibase\Repo\Phrase;

use Deserializers\TypedObjectDeserializer;

class PhraseDeserializer extends TypedObjectDeserializer {

        public function __construct() {
                parent::__construct(PhraseDocument::TYPE,'type');
        }

        public function deserialize( $serialization ) {
                return new PhraseDocument(
                        new PhraseId($serialization['id']),
                        $serialization['language'],
                        $serialization['phrase']
                );
        }

}

This deserializer relies on the id and type being part of the serialization, which is not something that I added to the serialization in the previous post. So I’ll need to add that to the PhraseSerailizer in order for TypedObjectDeserializer to function correctly.

The serialize method should look something like this:

public function serialize( $object ) {
        return [
                'id' => $object->getId()->getSerialization(),
                'type' => $object->getType(),
                'language' => $object->getLanguage(),
                'phrase' => $object->getPhrase(),
        ];
}

This also means that the previous entities that we have created that lack this id and type in serialization, will not be deserializable moving forward. If we try to load one of these, we will continue getting the exception noted above, however if we create a new entitiy with the new serializer, we can continue to the next error.

I expect with some refactoring this requirement of including the type and ID within the serialization may be possible, but it seems this is the status quo currently, and is the easiest to copy for now.

After fixing this error, our code is at 49afe2026a8914c79bc034ef4166a8dff41b2410.

No EntityDocumentView is registered for entity type ‘phrase’

/wiki/Phrase:Phrase669100fbb322c4.15128648 OutOfBoundsException: No EntityDocumentView is registered for entity type 'phrase'
from /var/www/html/w/extensions/Wikibase/repo/includes/ParserOutput/DispatchingEntityViewFactory.php(51)

Again, another large stack trace, but you can find it in a paste bin.

Once again, at the line that is causing this error, we see another case where some part of our entity registration is missing, in this case it is entityViewFactoryCallbacks.

The registration of a View service is simple:

Def::VIEW_FACTORY_CALLBACK => function(
        \Language $language,
        \Wikibase\Lib\TermLanguageFallbackChain $fallbackChain,
        \Wikibase\DataModel\Entity\EntityDocument $entity
) {
        return new PhraseView();
},

And the PhraseView implementation itself we can keep nice and simple for now.

This code should just output a small string on the page, showing both the language and the phrase that is set.

<?php

namespace Wikibase\Repo\Phrase;

use Wikibase\View\EntityDocumentView;
use Wikibase\View\ViewContent;

class PhraseView implements EntityDocumentView {

        function getTitleHtml(\Wikibase\DataModel\Entity\EntityDocument $entity) {
                return "Title of " . $entity->getId()->getSerialization();
        }

        function getContent(\Wikibase\DataModel\Entity\EntityDocument $entity, $revision): ViewContent {
                /* @var PhraseDocument $entity */
                return new ViewContent(
                        "Language: " . $entity->getLanguage() . "<br>Phrase: " . $entity->getPhrase(),
                        []
                );
        }
}

Reloading the page that we are trying to view, we do now see our content rendering, however we also see another large error presented above.

At the end of this section, our code is at 3aa7aa2bedd3c17c1c66536fc4f66924551a7d66

Failed to parse EntityId config var

This is actually only a warning, and I am only seeing this as I have development mode etc turned on, otherwise at this point, things would appear to be working from a user perspective.

wfLogWarning( $msg = 'Failed to parse EntityId config var: Phrase669100fbb322c4.15128648', $callerOffset = ???, $level = ??? )       
.../OutputPageEntityIdReader.php:52

The warning once again comes from a section of code that is looking for something in the entity registration, which I have not yet defined.

In this case, the entityIdParser in Wikibase, doesn’t know how to parse IDs for phrase entities.

Looking at the stacktrace, this parser is needed in the Wikibase hook for OutputPageBodyAttributes, which is adding some HTML class attributes to the body of the page, based on the entity type.

And looking at what the Wikibase ID parser requires us to do, we must define some EntityIdBuilders. Continuing down the rabbit hole, we see that these builders actually depend on the ENTITY_ID_PATTERN and ENTITY_ID_BUILDER parts of entity registration.

This one is a very simple addition to the definitions:

Def::ENTITY_ID_PATTERN => '/^Phrase[0-9a-z]+\.[0-9]+/i',
Def::ENTITY_ID_BUILDER => static function ( $serialization ) {
        return new PhraseId( $serialization );
},

Reloading the page one more time, and we have a fully functional (in the fact that there are no errors) page for the phrase.

At the end of this section, the code is now at 52a94cde6c5e50cd2a27e9d2b7cc70d0dea9c7c4.

Special:RecentChanges

Interestingly, as part of the above changes, Special:RecentChanges is now broken for display. (I was actually expecting this, as it happened in my 2022 branch too).

LogicException: Unable to find Wikibase\DataAccess\PrefetchingTermLookup

/wiki/Special:RecentChanges LogicException: Unable to find Wikibase\DataAccess\PrefetchingTermLookup Service callback for Entity Type phrase for Source local
from /var/www/html/w/extensions/Wikibase/lib/includes/ServiceBySourceAndTypeDispatcher.php(54)

So, something along this code path has changed, and now requires an extra service to be defined (I did have a quick look but didn’t come to any concrete conclusion about what changed and don’t think it’s worth staring at too much.)

This is another point that highlights some of the bad assumptions that still exist within the Wikibase entity system, as my entity doesn’t have any terms, so why do I need to define something relating to them for my entity?

So, let’s try adding a Def::PREFETCHING_TERM_LOOKUP_CALLBACK service to our definition. Conveniently, Wikibase provides a NullPrefetchingTermLookup that we can shove in there for now if we don’t want to worry about prefetching.

Def::PREFETCHING_TERM_LOOKUP_CALLBACK => static function () {
        return new \Wikibase\DataAccess\NullPrefetchingTermLookup();
},

LogicException: Unable to find Wikibase\Lib\Store\EntityUrlLookup

Very similar to the error above, another service that is required somewhere for recent changes now, despite it working before?

/wiki/Special:RecentChanges LogicException: Unable to find Wikibase\Lib\Store\EntityUrlLookup Service callback for Entity Type phrase for Source local
from /var/www/html/w/extensions/Wikibase/lib/includes/ServiceBySourceAndTypeDispatcher.php(54)

You can find the full stack trace in a pastebin.

Again, Wikibase provides a fairly basic service already for this service that I don’t need to modify at all, which can be dropped right in.

Def::URL_LOOKUP_CALLBACK => static function () {
        return new \Wikibase\Lib\Store\TitleLookupBasedEntityUrlLookup( WikibaseRepo::getEntityTitleLookup() );
},

LogicException: Unable to find Wikibase\Lib\Store\EntityExistenceChecker

Again very similar to the two errors above, yet another service is required now that wasn’t before…

/wiki/Special:RecentChanges LogicException: Unable to find Wikibase\Lib\Store\EntityExistenceChecker Service callback for Entity Type phrase for Source local
from /var/www/html/w/extensions/Wikibase/lib/includes/ServiceBySourceAndTypeDispatcher.php(54)

You can find the full stack trace for this error in a pastebin.

And once again, Wikibase already provides a drop in service for this that we can use.

Def::EXISTENCE_CHECKER_CALLBACK => static function () {
        $services = \MediaWiki\MediaWikiServices::getInstance();
        return new \Wikibase\Lib\Store\TitleLookupBasedEntityExistenceChecker(
                WikibaseRepo::getEntityTitleLookup( $services ),
                $services->getLinkBatchFactory()
        );
},

LogicException: Unable to find Wikibase\Lib\Store\EntityTitleTextLookup

Now for one, that didn’t happen at this point in my 2022 branch, so something must have changed within Wikibase to now require this service for the recent changes page.

/wiki/Special:RecentChanges LogicException: Unable to find Wikibase\Lib\Store\EntityTitleTextLookup Service callback for Entity Type phrase for Source local
from /var/www/html/w/extensions/Wikibase/lib/includes/ServiceBySourceAndTypeDispatcher.php(54)

Once again, the full stack trace can be found in a pastebin.

The fact that I don’t already know the answer to this error allows me to explore how I found the services for the above fixes. Ultimately, I have been looking at the various existing entity type definitions for items, properties, lexemes, mediainfo and using them as examples.

If we have a look at the item entity type definition, we can see that item also provides a very basic, and already provided default service.

Infact, properties, lexemes, forms, senses and mediainfo all use this same service, but all also must explicitly provide it to function as a wikibase entity (maybe good maybe bad, certainly worth thinking about).

So let’s shove this templated code in:

Def::TITLE_TEXT_LOOKUP_CALLBACK => function () {
        return new \Wikibase\Lib\Store\TitleLookupBasedEntityTitleTextLookup(
                WikibaseRepo::getEntityTitleLookup()
        );
},

And tada, recent changes works again

And at the end of this section the code is at 5b085f3c29cd8950608eb90508785f8aa6a4a19f.

wbgetentities

Next, I’ll take a little look at the action API that is provided by Wikibase for entities out of the box.

The following URL should present me with a JSON representation of my phrase entity.

http://default.mediawiki.mwdd.localhost:8080/w/api.php?action=wbgetentities&ids=Phrase669100fbb322c4.15128648

Instead, it presents me with an error!

{
    "error": {
        "code": "internal_api_error_Serializers\\Exceptions\\UnsupportedObjectException",
        "info": "[ac565d7c5c4b33e90c81a405] Exception caught:",
        "errorclass": "Serializers\\Exceptions\\UnsupportedObjectException",
        "*": "Serializers\\Exceptions\\UnsupportedObjectException at /var/www/html/w/vendor/serialization/serialization/src/Serializers/DispatchingSerializer.php(46)\nfrom /var/www/html/w/vendor/serialization/serialization/src/Serializers/DispatchingSerializer.php(46)\n#0 /var/www/html/w/extensions/Wikibase/repo/includes/Api/ResultBuilder.php(395): Serializers\\DispatchingSerializer->serialize()\n#1 /var/www/html/w/extensions/Wikibase/repo/includes/Api/ResultBuilder.php(335): Wikibase\\Repo\\Api\\ResultBuilder->getModifiedEntityArray()\n#2 /var/www/html/w/extensions/Wikibase/repo/includes/Api/GetEntities.php(351): Wikibase\\Repo\\Api\\ResultBuilder->addEntityRevision()\n#3 /var/www/html/w/extensions/Wikibase/repo/includes/Api/GetEntities.php(196): Wikibase\\Repo\\Api\\GetEntities->handleEntity()\n#4 /var/www/html/w/includes/api/ApiMain.php(1952): Wikibase\\Repo\\Api\\GetEntities->execute()\n#5 /var/www/html/w/includes/api/ApiMain.php(928): ApiMain->executeAction()\n#6 /var/www/html/w/includes/api/ApiMain.php(899): ApiMain->executeActionWithErrorHandling()\n#7 /var/www/html/w/includes/api/ApiEntryPoint.php(158): ApiMain->execute()\n#8 /var/www/html/w/includes/MediaWikiEntryPoint.php(200): MediaWiki\\Api\\ApiEntryPoint->execute()\n#9 /var/www/html/w/api.php(44): MediaWiki\\MediaWikiEntryPoint->run()\n#10 {main}"
    },
    "servedby": "34649244130e"
}

This error appears to be talking about Serializers once again, which we have already defined as part of the entity type definition, however some additional definition must be missing.

Looking at the stacktrace, the issue comes from ResultBuilder (a class I wrote 11 years ago) which ultimately takes in a different serializer for presentation to users than is used for database storage.

This comes from WikibaseRepo::getAllTypesEntitySerializer which ultimately makes use of the SERIALIZER_FACTORY_CALLBACK key from the entity type definitions.

For convenience, as there is currently no need to have different presentation and storage serialization, we can just provide the same PhraseSerailizer here.

Def::SERIALIZER_FACTORY_CALLBACK => static function ( \Wikibase\DataModel\Serializers\SerializerFactory $serializerFactory ) {
        return new PhraseSerailizer();
},

Reloading the wbgetentities API, we can now see our presented serialization (combined with the additional spec that the current action API adds to the JSON).

At this point in the post, the code is at ec64885a7b3b4cb205f025056a5c2a2f025f8864.

Special:EntityData

Here I immediately started to regret a change that I made between my 2022 branch, and this new 2024 branch.

IDs with .s in them

In the 2022 branch I was using bin2hex(random_bytes(16)) to generate my entity ID with. In my 2024 branch I decided to move to uniqid( 'Phrase', true ). The side affect of this is that the IDs are generated with a . character in them, such as Phrase669100fbb322c4.15128648, vs the old IDs that would look like a2ce04965e4a9dcb03939d7c87f71dc4.

This is a small lesson in either “if it aint broke don’t fix it”, or “don’t make unnecessary changes at the same time as doing something else”.

Trying to load Special:EntityData for the first time the error message looks a bit odd, and also different to what I saw in 2022.

http://default.mediawiki.mwdd.localhost:8080/wiki/Special:EntityData/Phrase669100fbb322c4.15128648.json

The error seems to have chopped off part of the ID.

Rather than figure out where within Wikibase this is happening, I instead opted to change my ID generation so that this . was no longer present. This can be seen in 8585316e668e80490889ad21a4d60280d57937d6.

It would be great if this were either documented earlier, or enforced by something in code if the “framework” of wikibase can not handle .s in IDs. Just another possible pain point highlighted :)

ID Capitalization

I created a new phrase, which has a fresh ID with no . within it, and when trying to retrieve this via Special:EntityData another odd thing happens.

I request:

http://default.mediawiki.mwdd.localhost:8080/wiki/Special:EntityData/Phrase6691235471660120190320.json

However, my URL gets rewritten to:

http://default.mediawiki.mwdd.localhost:8080/wiki/Special:EntityData/PHRASE6691235471660120190320.json

And I get an error that says the entity can not be found…

This is the error I was expecting that also happened in 2022, and this change in case can be traced back to EntityDataUriManager which makes an assumption that app characters in an entity ID MUST be upper case (code from 11 years ago).

I roughly remember the reason code like this exists. Back in the day, particularly in statement GUIDs there was a case where GUIDs would be created with a lowercase P or Q id, such as q63 instead of Q63. Since then, for the entities that generally exist today, and because there is no reason not to, all entity IDs have all characters upper case.

There are two approaches to “fix” this for my branch.

1. Only uppercase the Int32EntityId IDs, allowing the PhraseId to have different handeling in this case
   • This is what I did back in 2022
   • Pros: My phrase ID can stay the same
   • Cons: There might be even more places in Wikibase that make this assumption that I will have to fix moving forward
2. Make my PhraseId generation always be uppercase
   • This is going to be my chosen approach for this case
   • Pros: I don’t have to touch Wikibase code for this
   • Cons: PHRASE looks ugly? & I once again change my ID (but i just did that anyway…)

After this ID generation change my code is at 3a74ae4829ed72c0ee5285b32c105fd43e411057.

And now making a request for the JSON of the entity via Special:EntityData works, and makes use of the same presentation based entity serializer defined above for wbgetentities.

RDF mapping

Requesting another format such as RDF or TTL also works at this stage, although the mapping of the content itself is lacking.

...

data:PH6691283689E56137095964 a schema:Dataset ;
        schema:about wd:PH6691283689E56137095964 ;
        cc:license <http://creativecommons.org/publicdomain/zero/1.0/> ;
        schema:softwareVersion "1.0.0" ;
        schema:version "7"^^xsd:integer ;
        schema:dateModified "2024-07-12T12:57:26Z"^^xsd:dateTime .

wd:PH6691283689E56137095964 a wikibase:Phrase .

In order to add additional RDF mapping for the phrase entity, I need to define a Def::RDF_BUILDER_FACTORY_CALLBACK.

The service definition is once again very simple:

Def::RDF_BUILDER_FACTORY_CALLBACK => static function (
        $flavorFlags,
        \Wikibase\Repo\Rdf\RdfVocabulary $vocabulary,
        \Wikimedia\Purtle\RdfWriter $writer,
        $tracker,
        $dedupe
) {
        return new PhraseRdfBuilder(
                $vocabulary,
                $writer
        );
},

As is the service itself (if you know enough about RDF etc…)

<?php

namespace Wikibase\Repo\Phrase;

use Wikibase\Repo\Rdf\EntityRdfBuilder;
use Wikibase\Repo\Rdf\RdfVocabulary;
use Wikimedia\Purtle\RdfWriter;
use Wikibase\DataModel\Entity\EntityDocument;

class PhraseRdfBuilder implements EntityRdfBuilder {

    private $vocabulary;
    private $writer;

        public function __construct(
                RdfVocabulary $vocabulary,
                RdfWriter $writer
        ) {
                $this->vocabulary = $vocabulary;
                $this->writer = $writer;
        }

        public function addEntity( EntityDocument $entity ){
                // Stolen from TermsRdfBuilder::getLabelPredicates
                $labelPredicates = [
                        [ 'rdfs', 'label' ],
                        [ RdfVocabulary::NS_SKOS, 'prefLabel' ],
                        [ RdfVocabulary::NS_SCHEMA_ORG, 'name' ],
                ];

                for ( $i = 0; $i < count( $labelPredicates ); $i++ ) {
                        $this->writer->say( $labelPredicates[$i][0], $labelPredicates[$i][1] )->text( $entity->getPhrase(), $entity->getLanguage() );
                }
        }
}

Reloading the TTL output, we now see our additional data that shows the phrase content.

...

data:PH6691283689E56137095964 a schema:Dataset ;
        schema:about wd:PH6691283689E56137095964 ;
        cc:license <http://creativecommons.org/publicdomain/zero/1.0/> ;
        schema:softwareVersion "1.0.0" ;
        schema:version "7"^^xsd:integer ;
        schema:dateModified "2024-07-12T12:57:26Z"^^xsd:dateTime .

wd:PH6691283689E56137095964 a wikibase:Phrase ;
        rdfs:label "Phrase with new ID again"@en ;
        skos:prefLabel "Phrase with new ID again"@en ;
        schema:name "Phrase with new ID again"@en .

After this RDF mapping change, the code is now at 84c6e127912ef763501fff6ca1a32d27fb57d085.

A summary

We can now actually view the phrase in a few different ways and formats (UI, action API, RDF).

There are still many errors dotted around the place to fix, for example, simply trying to load the MediaWiki action API documentation currently results in an error, search doesn’t work other than for “Page title matches” and there is currently no way to edit the phrase at all..

These 2 posts bring me mostly to the end of my 2022 branch, except there I also messed around with fingerprints a little, and added a non JS termbox to the experimental entity, both of which I won’t be covering in this series.

Although it has taken 2 blog posts, 19 files, and 535 line additions to get to this point, in essence all I have defined at this stage is the following 15 lines of information for Wikibase and MediaWiki to do things with.

mediawiki:
 - namespace:
   - id: 4269
name:
 - human: Phrase
 - internal: phrase
id:
 - format: /^PH[0-9A-Z]+/
 - generation: strtoupper( str_replace( '.', '', uniqid( 'PH', true )))
fields:
 - language: string name:Language,validation:languageCode
 - phrase: string name:Phrase,validation:len<=1000
rdf:
 - labels:
   - language: phrase

I wrote a post in February 2025 looking at what the Wikibase ecosystem (might) look like, according to the data that had at that point been collected on wikibase.world. Now that data has had some time to evolve and expand, we can take a little look at how it has changed throughout the last 2 months.

In the future, I’ll try to remember to write something up every quarter or so (for now), until someone else feels like taking this over ;)

The latest notebooks for generating this are in git, and the latest XML file dumped from wikibase.world is on archive.org.

Site count and status

We have gone from tracking 777 sites, up to 873, so an increase of nearly 100 in 2 months.

However, we need to look at the tracked status to determine how big the current ecosystem actually might be. So I added a little extra counting to the notebook previously used to count the wikis based on P13 (availability status).

Back in Feb, there were 774 online, and only 3 marked as offline. This was primarily as Addbot was not often marking sites as offline, however I added automatic detection of deleted sites for wikibase.cloud and went through and checked a bunch of sites that the scripts were failing to lookup.

Looking at the April data, we have ~847 online, and ~26 offline, so an increase of around 3%.

Graph

Most of the growth in sites seems to come from wikibase.cloud, however many sites on wikibase.cloud are test sites and may not have much content.

So when displaying the graph this time, I’ll filter out everything that doesn’t have a highest Item ID of at least 25, this roughly cuts the size of the graph in half.

Picking another arbitrary cutoff to show a graph for, ignoring everything that has not at some point reached Q250, we end up with an even lighter graph.

Hosts

Due to me cleaning up some of the offline wikibases from wikibase.world, we end up with some slightly different percentage splits for the different hosts.

• A lower % from wikibase.cloud, which likely sees high turn over of test sites (was 91%, now 72%)
• 10% independently hosted, up from 3%
• 14% unknown, up from 3%

One of the next jobs will be to try to track down more of these unknown hosts, or align them with existing hosts!

And now that we have 2 data points, we can start to visualize some of this information over time…

Versions

wikibase.cloud hosted sites continue to dominate the view of the wikibase versions used.

However, if you click on 1.39.7 in the key, you can hide it!

The number of different versions is again quite long, so we can benefit from only looking at the major and minor parts…

Again you can click on 1.39 in the key to hide the large cloud count.

And as raw data….

Version	2025-02-16	2025-04-11	Delta
1.44	3	3	0
1.43	3	3	0
1.42	5	7	2
1.41	3	4	1
1.4	2	3	1
1.39	734	803	69
1.38	6	6	0
1.37	0	1	1
1.36	1	1	0
1.35	10	9	-1
1.34	3	3	0
1.33	1	1	0
1.32	1	2	1
1.28	1	1	0
1.27	1	0	-1

Goodbye 1.27! 1.28, you are next (I think that’s 2016)…

Wikimedians are familiar presenters at RightsCon, the world’s leading conference to tackle pressing issues at the intersection of human rights and technology. This year, Wikimedians traveled for RightsCon 2025 to Taipei, Taiwan. They demonstrated there how the work of the open knowledge movement and its bottom-up model are more important than ever to understand human rights in a landscape that is rapidly shifting. Our sessions covered best practices to advocate policies that ensure the integrity of online content, preserve cultural knowledge in moments of crisis, and promote underrepresented languages for a more representative online experience. 

In this blog post, we reflect on key takeaways from the event, share insights from Wikimedia Foundation staff and Wikimedians who attended, and highlight the significance of our participation in RightsCon 2025.

Wikimedia Foundation Takeaways

The need for close collaboration to ensure that digital rights are safeguarded across various sectors has never been more urgent than in this era of shifting geopolitical dynamics and accelerating technological change. That collaboration extends to the Wikimedia movement. At RightsCon, Wikimedia Foundation staff joined affiliate partners from the global community of volunteers, who contribute to and govern the Wikimedia projects. Here are the Foundation’s key takeaways:

1. Geopolitical shifts demand stronger alliances: The discussions at RightsCon highlighted the critical need for more and closer collaborative action in today’s geopolitical climate. The tone of conversations conveyed a profound anxiety regarding the changing narrative from key players of the digital ecosystem. At the same time, the discussions showed a strong collective resolve, and an unmistakable shared commitment to defend digital rights in this complex context. 
2. Bridging the gap between AI regulation and media literacy: AI retained its position as a core topic in digital rights and internet governance discussions. Concerns that were raised included the tension between open and closed AI models, the consequences of both on the future of the internet, and their potential negative impact on media literacy skills. The thread connecting governance and media literacy was strong. A broader understanding of AI systems and their implications is essential: otherwise, regulatory frameworks risk being ineffective or misinterpreted. To ensure AI regulations are practical and people-centered, developing media literacy initiatives alongside regulatory efforts is imperative. Stronger digital literacy empowers individuals to evaluate information critically, navigate digital spaces responsibly, and meaningfully participate in discussions about the role of AI in society.
3. Reimagining sustainable funding for digital rights organizations: A significant discussion point was the urgent need to rethink how digital rights organizations sustain themselves. Many participants expressed concerns about the long-term viability of their work, given funding challenges and shifting donor priorities. Conversations explored alternative funding models, collective strategies, and ways to ensure that organizations advocating a free and open internet remain resilient despite financial uncertainty. This moment calls for creative approaches.
4. Promoting a positive vision for information integrity: Discussions on information integrity revealed a shift in focus: there is a growing recognition of the need to build a more trustworthy and resilient online information ecosystem. Instead of reacting to the harms of mis- and disinformation, stakeholders emphasized the importance of fostering environments that incentivize creating and disseminating reliable, high-quality information. This proactive approach requires collaboration across platforms, policymakers, and digital rights communities to develop frameworks that encourage a healthier digital space.
5. Location, location, location: The host location for RightsCon remains significant in adding valuable insights and actors to global discussions. Local organizations shared their experiences with internet censorship, infrastructure challenges, and threats to digital freedoms. These insights enriched global discussions on digital rights, demonstrating the importance of learning from diverse regional perspectives and applying those lessons worldwide.

At a time when collaboration is urgently needed, Wikimedia’s history of community-centered work will be ever more critical in turning discussions into shared priorities and action. In the words of Amalia Toledo, our Lead Public Policy Specialist for Latin America and the Caribbean:

“We must contribute our expertise and strategize collectively to advance our vision of a free and open internet. By doing so, we will ensure the public interest remains protected within the evolving digital landscape.”

RightsCon 2025 in retrospect: Questions and answers with Wikimedians

Wikimedians had much to say about their time at RightsCon, and the role that creating, sharing, and curating free and open knowledge plays in digital rights conversations globally. 

In the words of Vanj Padilla (Shared Knowledge Asia Pacific), RightsCon exposed her to inspiring best practices and lessons that are valuable for Wikimedians’ work:

“I was inspired by the workshops on: digital safety; fighting fraud and cybercrime; navigating online safety for children and youth; data privacy; and, policy development towards ethics in technology. I am working on sharing these insights with my local community in the Philippines, so that we can embed these lessons into our strategic partnerships with actors in academia, government, and civil society.”

Here is what other Wikimedians told us about their experiences at RightsCon 2025.

1. What motivated you to present at RightsCon? Why did you think it was important to Wikimedia’s mission?

Belinda Spry (Wikimedia Australia): Wikimedia Australia recognised the need to bring First Nations voices and perspectives to global digital rights discussions following our recent commissioned research report. At RightsCon, we shared the challenges that Aboriginal and Torres Strait Islander peoples face on Wikipedia, including concerns around cultural sensitivity and trust. Our presentation addressed the need for Wikipedia to be more inclusive, particularly for those whose knowledge systems have historically been marginalised. This is an essential step in advancing Wikimedia’s mission of free knowledge for all. 

Ceslause Ogbonnaya (Africa Knowledge Initiative): I have always advocated that Wikimedians shouldn’t work in silos, because our work touches all the spheres of life. I saw RightsCon as an opportunity for the Africa Knowledge Initiative to connect with like-minded people, learn what they are doing, and identify opportunities to collaborate. The potential for shared advocacy initiatives related to the Africa Knowledge Initiative motivated my RightsCon submission, for I believe such collaborations have the potential to catalyze the project’s impact across the African continent and the open knowledge movement at large. Attending RightsCon was a chance to connect with various advocacy groups and learn about their strategies. 

Daria Cybulska (Wikimedia UK, Churchill Fellowship): I was keen to share the findings of my field research on Central Asia civil societies. Initially, the project aimed to raise awareness of a little-known region, but now digital rights organizers in the West have a lot to learn from those who have operated in political contexts where civic spaces are shrinking and closed off. Wikimedia projects and communities are experiencing unprecedented pushback and criticism. We must learn from others who have found ways of maintaining resilience in a context where the majority are against their work. 

Liang-chih Shang Kuan (Wikimedia Taiwan): I was motivated to present at RightsCon because I believe in the power of an open internet as an infrastructure that empowers and improves the lives of individuals and communities. My involvement in the Wikimedia Movement’s 2030 vision and the creation of the Asia-Pacific (ESEAP) Hub has deepened my understanding of the role Wikimedia plays in shaping a more diverse and connected digital future. Wikipedia, as one of the top 10 most visited websites globally, has a unique influence in promoting free and open knowledge. RightsCon offered a valuable platform to engage with key stakeholders, including human rights activists and journalists, whose work aligns with Wikimedia’s mission. This event provided an opportunity to strengthen the movement and contribute to the vision of a more open and accessible internet.

Sandra Aceng (Women of Uganda Network (WOUGNET)): RightsCon’s primary focus has been human rights in the digital age, which closely aligns with WOUGNET’s focus on women’s rights online and also with my work at Wikimedia Community User Group Uganda, which aims to close the gender digital divide across Wikimedia initiatives. The global attendance at RightsCon motivated me to amplify WOUGNET’s impact through sessions such as “Missing the full Picture: Challenging gender-blind responses of platforms to disinformation.” RightsCon was also a key space to connect with other Wikimedians and learn from what they are doing to promote open access. Networks of Wikimedians built from RightsCon continue to shape our work at Wikimedia Community Usergroup Uganda locally, which in turn informs Wikimedia global advocacy work.

2. How do you think other RightsCon attendees benefited from learning about your work?

Belinda: RightsCon attendees benefited by gaining insight into the challenges Aboriginal and Torres Strait Islander Peoples and communities face on Wikipedia, particularly around cultural sensitivity and trust. We highlighted the need for more inclusive and culturally safe digital spaces and facilitated discussions on decolonizing knowledge platforms, which should inspire and inform the work of digital rights actors beyond the Wikimedia movement.

Ceslause: At RightsCon I was able to connect with organizations who share my passion for protecting Indigenous data rights. I was able to promote provisions developed in Africa like the Nwulite Obodo Creative Licence for licensing Indigenous people’s datasets—developed by the Centre for Intellectual Property and Information Technology Law (CIPIT) in Kenya. I know this has provided a useful template for Wikimedia Australia as they work on the Protocol for Indigenous Cultural and Intellectual Property (ICIP) and Indigenous Data Sovereignty (IDSov) for Aboriginal and First Nations communities. I also connected with two attendees, one from an Indigenous community in Asia, and another from the Ogiek community of Kenya. We are currently in discussion with the Ogiek Peoples’ Development Program (OPDP) to bring their language to Wikimedia projects, starting with Wikipedia.

Daria: I presented a few ways to safely help civil society players develop a “critical or oppositional mindset”, which my research indicates can help to make civil societies with restrictive contexts more resilient. This mindset is key to democratic societies, a critical attitude that provides awareness between how things are and how they can be. I believe RightsCon participants benefited from this information, regardless of the contexts in which they operate, since it also helps to consider how critical mindsets can be fostered in any civil society.

Liang-chih: I was able to educate RightsCon participants about how Wikimedia projects and communities work, from our advocacy around open licenses to our contributions in terms of engineering. 

Sandra: My participation provided RightsCon attendees with insights from the Global South on online gender-based violence. This included reviewing patterns, motivations, and socio-political drivers of online violence, especially during political events like elections. Additionally, attendees gained critical insights into how social media platforms fail to address gender-specific disinformation and the impact of these knowledge gaps on women, especially in politics and journalism.

3. What key lessons and insights will you be sharing back with your community?

Belinda: We’ll share insights into how other countries and groups are approaching self-determination in digital spaces, the need for stronger cultural safety measures on Wikipedia, and how continuing global conversations on digital rights can support First Nations knowledge and data sovereignty. RightsCon reinforced that our work must center on community-led solutions, such as models like Licensing African Datasets, which prioritise Indigenous control over knowledge. These approaches highlight pathways for ensuring more equitable and respectful representation online. 

Ceslause: My exchange with Wikimedia Australia at RightsCon inspired me to try to implement the Nwulite Obodo Creative at the national level throughout Wikimedia communities. I will be sharing this ambitious goal with my local Wikimedia community and the entire Wikimedia space at large.

Daria: I was encouraged by how many organisations in attendance work on narrative change, including through art, and on seeking hopeful and positive narratives in a context that is anything but uplifting. Connecting with DAKILA was a particular highlight. This chimes with the efforts within the Wikimedia movement to lead our comms and narratives with a positive vision for the internet and stress how we add to the information ecosystem. 

Liang-chih: I was inspired to consider how my insights from RightsCon can be incorporated into ongoing Wikimedia projects. One way is to consider how to build better-connected infrastructure at a time when the political environment is increasingly unstable. What kind of infrastructure investments are most important, and what advocacy is necessary to protect the resilience of future infrastructure? Another way is preserving Indigenous languages. It was motivating to see how Wikimedians’ work on this issue resonates with a global audience, which highlights the need to continue investing in building linguistically inclusive online communities.

Sandra: After my RightsCon session, Wiki Activate Africa offered me to be a guest speaker for a virtual discussion: “Wikipedia’s Role in Fighting Misinformation and Fake News.” A colleague was able to accept the speaking engagement from Wikimedia Uganda, and we’re now working together to ensure that lessons from RightsCon are passed on! 

From 14 April to 16 May, the Ukrainian Institute, the Ministry of Foreign Affairs of Ukraine, and the NGO Wikimedia Ukraine will host the annual information campaign Ukraine’s Cultural Diplomacy Month 2025 on Wikipedia. This initiative aims to expand and enhance articles about Ukraine and its culture on Wikipedia in multiple languages, making knowledge about the country more accessible worldwide.

Now in its fifth year, the campaign has resulted in over 7,000 unique articles on Ukrainian culture across various foreign languages, including Arabic, Basque, Welsh, Indonesian, Berber, Urdu, Tagalog, and Gujarati.

‘Since 2021, Ukraine’s Cultural Diplomacy Month on Wikipedia has been bringing together Wikipedia contributors from around the world to increase interest in Ukraine and its cultural heritage. In the context of Russia’s full-scale war against Ukraine, which is accompanied by Russian disinformation, it is extremely important to defend the truth and ensure the dissemination of verified, fact-based narratives. This cultural initiative significantly helps to strengthen the Ukrainian voice globally and counteract information threats’, – says Mariana Betsa, Deputy Foreign Minister of Ukraine. 

For the second year in a row, decolonising Ukrainian culture remains one of the project’s key themes. Russia’s full-scale invasion has intensified global interest in Ukrainian cultural heritage, much of which remains understudied. At the same time, there is a growing demand for reliable information about Ukraine. By creating new articles and expanding existing ones, participants not only help to spread knowledge but also strengthen Ukraine’s presence in the global information space.

‘The decolonisation of culture is not just about restoring historical justice – it is about ensuring that nations have the right to tell their own stories. For centuries, Ukraine has been subjected to Russia’s cultural expansion, which sought to appropriate our achievements and erase our identity. Now, our task is not only to reclaim our cultural heritage but also to make it visible to the world,’ says Volodymyr Sheiko, Director General of the Ukrainian Institute. 

The decolonisation of culture is not just about restoring historical justice – it is about ensuring that nations have the right to tell their own stories. For centuries, Ukraine has been subjected to Russia’s cultural expansion, which sought to appropriate our achievements and erase our identity. Now, our task is not only to reclaim our cultural heritage but also to make it visible to the world.

As the world’s largest and most accessible source of information, Wikipedia must feature accurate and diverse materials about Ukraine in multiple languages. The campaign encourages contributors from around the globe to create and improve Wikipedia articles in their native languages, helping to expand knowledge about Ukraine and its cultural heritage. The project also includes a competitive element, with active Wikipedia editors eligible for prizes.

‘Over the past five years, Ukraine’s Cultural Diplomacy Month on Wikipedia has brought people from around the world together, helping to share Ukraine’s story in multiple languages. And this effort continues – now more important than ever. Last year, 200 participants contributed over 1,200 new articles and set a record by adding and improving content in 66 different language sections of Wikipedia. This year, we aim to engage even more Wikimedians who are eager to explore new topics and join the initiative. Every article written is another step towards raising awareness and understanding of Ukraine,’ says Ilya Korniyko, Chairman of the Board of the NGO Wikimedia Ukraine.

We invite everyone to take part in the project!

Find full details about the competition, the list of recommended articles, and the participation rules on the project page.

UCDMysec #UEWikipedia #UkraineEverywhere