The Igala Wikimedia Campus Outreach was successfully implemented across three higher institutions in Kogi State:

• Kogi state Polytechnic Lokoja
• Federal Polytechnic Idah
• Prince Abubakar Audu University, Anyigba

The outreach served as a capacity-building initiative designed to recruit, train, and mentor new Wikimedia contributors while promoting the documentation of Igala language, culture, history, and notable personalities on Wikimedia platforms. Through practical editing sessions, mentorship, and collaborative learning, participants gained the skills required to contribute quality knowledge to Wikipedia and related Wikimedia projects.

Project Objectives

The primary objective of the outreach was to increase the number of active Igala Wikimedia editors and improve the availability of Igala-related knowledge on Wikipedia and other Wikimedia projects. Specifically, the project sought to:

• Train new editors in Wikipedia editing and Wikimedia policies.
• Increase the number of contributors to the Igala Wikimedia community.
• Document and preserve Igala language, culture, history, and notable personalities.
• Improve the quality and accessibility of Igala-related content online.
• Build a sustainable campus-based Wikimedia community through mentorship and continuous engagement.

Project Activities

• Attah Igala – Traditional rulership and the history of the Igala Kingdom.
• Igala Language – Grammar, dialects, and language usage.
• Idah, Kogi State – Historical significance, culture, and landmarks of the ancestral home of the Igala people.

Participants also improved existing Wikipedia articles and enhanced Wikidata items relating to Igala language, places, and distinguished personalities. These contributions help bridge the existing knowledge gap affecting indigenous Nigerian languages on Wikimedia platforms.

Mentorship and Community Growth

Mentorship remained a central component of the outreach. Experienced Wikimedia volunteers provided continuous guidance throughout the training sessions, ensuring that participants understood editing standards and best practices.A significant outcome of the mentorship process was the growth in participants’ confidence and editing skills. Many attendees joined with little or no prior Wikimedia experience but successfully progressed to independently creating and improving articles by the end of the outreach. This demonstrates the importance of sustained mentorship in retaining new editors and strengthening the local Wikimedia community.

Experience

The outreach was both impactful and inspiring. Participants showed enthusiasm throughout the training sessions and demonstrated a genuine interest in preserving and promoting Igala knowledge online. The collaborative atmosphere encouraged peer learning, teamwork, and active participation.It was particularly rewarding to observe participants transition from beginners to confident contributors capable of independently editing Wikipedia. The project also strengthened relationships among the participating institutions and laid the foundation for future Wikimedia activities within the campuses.

Benefits and Impact

The outreach produced several positive outcomes, including:

• Increased awareness of Wikimedia projects among students and academic communities.
• Development of new editing skills among participants.
• Improved representation of Igala language, culture, and history on Wikipedia.
• Strengthened collaboration among campus communities and the Igala Wikimedia user community.
• Contribution towards reducing the content gap affecting indigenous Nigerian languages.
• Establishment of a growing network of volunteers committed to documenting Igala knowledge.

These contributions will continue to benefit researchers, students, and the wider public by making reliable information about the Igala people more visible and accessible globally.

Challenges Encountered

Despite the success of the outreach, several challenges were experienced during implementation:

• Inconsistent internet connectivity affected editing sessions in some locations.
• Limited availability of laptops among participants reduced hands-on participation.
• Power supply interruptions occasionally delayed training activities.
• Some participants required additional time to fully understand Wikipedia editing guidelines and policies.
• Time constraints limited the depth of practical editing during some sessions.

These challenges were addressed through mentoring, flexible training schedules, collaborative editing, and continuous follow-up support after the events.

Outcomes and Contributions

The outreach successfully expanded the Igala Wikimedia community while increasing the quantity and quality of Igala-related content across Wikimedia projects.

Project Metrics Indicator

• Campuses Reached 3
• New Editors Trained 102
• Articles Created 514
• Articles Improved 516
• Total Edit Contributions 2.64k
• Commons upload 266

See also: https://meta.wikimedia.org/wiki/Event:Building_Igala_Wikipedia_Community_Through_Campus_Engagement

Next Steps

The Igala Wikimedia Outreach continues to play an important role in promoting language equity and representation within the Wikimedia movement. Future activities will focus on:

• Sustaining mentorship for newly recruited editors.
• Organizing advanced editing workshops and edit-a-thons.
• Expanding the outreach to additional tertiary institutions and communities.
• Encouraging regular contributions to Wikipedia and Wikidata.
• Building long-term partnerships with educational institutions to strengthen the Igala Wikimedia community.

Conclusion

The Igala Wikimedia Campus Outreach successfully achieved its objective of empowering new contributors to document and preserve Igala knowledge on Wikimedia platforms. Through training, mentorship, and collaborative editing, participants contributed meaningful content that enriches Wikipedia and improves global access to information about the Igala people, their language, history, traditions, and achievements.The project represents a significant step toward addressing the underrepresentation of indigenous Nigerian languages online while building a sustainable community of editors committed to preserving Igala heritage for future generations. Continued mentorship, institutional collaboration, and community engagement will further strengthen the impact and sustainability of this initiative..

From Tsuvadi to Shingini: Building a Wikimedia Community for the Kambari Language in Nigeria

What began as an outreach project focused on the Tsuvadi language grew into a broader initiative to introduce Wikimedia projects to speakers of the Kambari language and lay the foundation for a sustainable Kambari Wikimedia community.

The project was initially designed around Tsuvadi, but consultations with the Language Development Translation and Initiative (LDTI), traditional leaders, and community members revealed that Tsuvadi is one of the varieties of the broader Shingini (Kambari) language. Based on these consultations, the project was expanded to include three major varieties: Tsishingini, spoken in the Salka area; Cishingini, spoken in the Agwara area; and Tsikimba, spoken in the Auna area.

This change made the project more representative of the Kambari-speaking community and provided contributors with the opportunity to work in the variety they were most familiar with.

Bringing Wikimedia to the Kambari Community

The outreach took place over three days in Salka, Niger State, and brought together community members interested in language preservation, digital knowledge, and Wikimedia projects. Attendance exceeded the original expectation of 43 participants, with 46 on the first day, 36 on the second, and 37 on the third. In total, 45 editors participated in the project. Danjuma Anthony coordinated the project. Experienced Wikimedia facilitators Kambai Akau and Kuyet Friday Musa guided participants through editing on the Wikimedia Incubator and introduced them to Wikimedia’s broader ecosystem. Additional support from the community, Danladi Matthew and Dr. Aliyu Dantata, also helped make the event successful. Participants received practical training, learning materials, internet support, meals, transportation assistance, and follow-up support to help them participate effectively.

The support of the Language Development Translation and Initiative (LDTI) and traditional leaders, including the Mogono Salka, was particularly important in building trust within the community. Their involvement helped encourage participation and demonstrated the value of combining local community leadership with Wikimedia activities.

More Than Expected

The results went far beyond the project’s original targets. The initial plan was to create 200 new articles, improve 200 existing articles, upload 100 images, and recruit 40 new editors. Instead, participants created 647 new articles, improved 736 existing articles, and made 2,980 edits. They also uploaded 430 images to Wikimedia Commons, while contributing approximately 71,700 words and 53 references.

These contributions provided a substantial amount of new Wikimedia content in the Kambari language varieties and helped establish a foundation for continued work toward a Kambari Wikipedia. The project also created a Kambari Wikipedia Post-Outreach Engagement Program, allowing participants to continue receiving support and contributing online after the physical training ended.

What We Learned

Several factors contributed to the project’s success. Working closely with local language organizations and traditional leaders helped the organizers understand the community’s linguistic situation and encouraged people to participate. Experienced facilitators also provided the mentorship needed to help new contributors understand Wikimedia editing.

Providing internet access, transportation reimbursement, meals, learning materials, and follow-up data support helped participants remain engaged during the outreach. At the same time, the project faced some challenges. The poor road between Abuja and Salka made transportation difficult. The original venue was also changed from Kontagora to Salka after consultations showed that Salka provided better access to speakers, language experts, and literacy materials.

The team also planned to introduce participants to Translatewiki, but contributors could not begin practical translation work because the necessary permissions were not granted before the event. After the physical outreach, some participants also struggled to continue editing because of the cost of internet data. These challenges highlighted the importance of beginning technical preparations earlier, extending post-event mentorship, and providing dedicated internet support for contributors after physical training.

Building for the Future

One of the most encouraging outcomes was the community’s commitment to continue the work. During the closing discussions, Kambari-speaking participants expressed their willingness to continue translating and developing content for the Kambari Wikipedia Incubator.

Community members also asked facilitators to be patient during the rainy season, when many participants are busy with farming and may have less time for editing. They explained that activity may increase during the dry season, when participants expect to have more time to contribute.

The experience showed that Wikimedia outreach can do more than create articles. It can bring together language experts, community leaders, new editors, and experienced Wikimedians to build the foundations of a sustainable digital language community.

The Kambari project is only a beginning. With continued mentorship and community participation, the contributors who started editing during this outreach can continue expanding Kambari-language content and help bring a future Kambari Wikipedia closer to reality.

If you speak a Shingini (Kambari) language variety or are interested in helping preserve Kambari knowledge online, you can join the community, learn Wikimedia editing, and contribute to the growing body of content in Tsishingini, Cishingini, and Tsikimba.

The Developer Outreach team is happy to announce that we will be migrating the Tech Blog into Diff. This move will allow us to provide better support and more visibility for the incredible work of the technical community. Diff is the community news and event blog supported by the Movement Communications team. Diff sees about 20,000 visits a month and has 1,200 email subscribers. 

• What will happen to the Tech Blog content?
  • All Tech Blog posts will be accessible on Diff, clearly tagged with “techblog”. Old links will automatically redirect to their new location. New posts with a technical focus will be tagged with “techblog” so they will be easily discoverable.You’ll be able to find all techblog posts – old and new – on the landing page at https://diff.wikimedia.org/techblog 
• When is this happening?
  • The migration should be complete in April 2026.
• How do I submit a blog post with a technical focus?
  • For now, please hold your post until we complete the migration.
  • After the migration is done: The process remains the same. For WMF staff, talk to your manager about your interest in writing a blog post so they are not surprised when you ask them to approve it once it is written. For folks outside WMF, if you are part of a team or other larger organization, be sure they are aware and approve. Then, see the Diff submission process and select the category “Technology” and the tag “techblog” when writing your draft. After you submit, the Developer Outreach team will review your draft. When it’s ready to go, we will schedule your post to be published.

We’re excited for the Tech Blog to evolve and thank the Movement Communications team for helping us make this possible!

Wikipedia is coming up on its 25th birthday, and that would not have been possible without the Wikimedia technical volunteer community. Supporting technical volunteers is crucial to carrying forward Wikimedia’s free knowledge mission for generations to come. In line with this commitment, the Foundation is turning its attention to an important area of developer support—the Wikimedia web (HTTP) APIs. 

Both Wikimedia and the Internet have changed a lot over the last 25 years. Patterns that are now ubiquitous standards either didn’t exist or were still in their infancy as the first APIs allowing developers to extend features and automate tasks on Wikimedia projects emerged. In fact, the term “representational state transfer”, better known today as the REST framework, was first coined in 2000, just months before the very first Wikipedia post was published, and only 6 years before the Action API was introduced. Because we preceded what have since become industry standards, our most powerful and comprehensive API solution, the Action API, sticks out as being unlike other APIs – but for good reason, if you understand the history.

Wikimedia APIs are used within Foundation-authored features and by volunteer developers. A common sentiment surfaced through the recent API Listening Tour conducted with a mix of volunteers and Foundation staff is “Wikimedia APIs are great, once you know what you’re doing.” New developers first entering the Wikimedia community face a steep learning curve when trying to onboard due to unfamiliar technologies and complex APIs that may require a deep understanding of the underlying Wikimedia systems and processes. While recognizing the power, flexibility, and mission-critical value that developers created using the existing API solutions, we want to make it easier for developers to make more meaningful contributions faster. We have no plans to deprecate the Action API nor treat it as ‘legacy’. Instead, we hope to make it easier and more approachable for both new and experienced developers to use. We also aim to expand REST coverage to better serve developers who are more comfortable working in those structures.

We are focused on simplifying, modernizing, and standardizing Wikimedia API offerings as part of the Responsible Use of Infrastructure objective in the FY25-26 Annual Plan (see: the WE5.2 key result). Focusing on common infrastructure that encourages responsible use allows us to continue to prioritize reliable, free access to knowledge for the technical volunteer community, as well as the readers and contributors they support. Investing in our APIs and the developer experiences surrounding them will ensure a healthy technical community for years to come. To achieve these objectives, we see three main areas for improving the sustainability of our API offering: simplification, documentation, and communication.

Simplification

To reduce maintenance costs and ensure a seamless developer experience, we are simplifying our API infrastructure and bringing greater consistency across all APIs. Decades of organic growth without centralized API governance led to fragmented, bespoke implementations that now hinder technical agility and standardization. Beyond that, maintaining services is not free; we are paying for duplicative infrastructure costs, some of which are scaling directly with the amount of scraper traffic hitting our services.

In light of the above, we will focus on transitioning at least 70% of our public endpoints to common API infrastructure (see the WE 5.2 key result). Common infrastructure makes it easier to maintain and roll out changes across our APIs, in addition to empowering API authors to move faster. Instead of expecting API authors to build and manage their own solutions for things like routing and rate limiting, we will create centralized tools and processes that make it easier to follow the “golden path” of recommended standards. That will allow centralized governance mechanisms to drive more consistent and sustainable end-user experiences, while enabling flexible, federated API ownership. 

An example of simplified internal infrastructure will be introducing a common API Gateway for handling and routing all Wikimedia API requests. Our approach will start as an “invisible gateway” or proxy, with no changes to URL structure or functional behavior for any existing APIs. Centralizing API traffic will make observability across APIs easier, allowing us to make better data-driven decisions. We will use this data to inform endpoint deprecation and versioning, prioritize human and mission-oriented access first, and ultimately provide better support to our developer community.  

Centralized management and traffic identification will also allow us to have more consistent and transparent enforcement of our API policies. API policy enforcement enables us to protect our infrastructure and ensure continued access for all. Once API traffic is rerouted through a centralized gateway, we will explore simplifying options for developer identification mechanisms and standardizing how rate limits and other API access controls are applied. The goal is to make it easier for all developers to know exactly what is expected and what limitations apply.

As we update our API usage policies and developer requirements, we will avoid breaking existing community tools as much as possible. We will continue offering low-friction entry points for volunteer developers experimenting with new ideas, lightly exploring data, or learning to build in the Wikimedia ecosystem. But we must balance support for community creativity and innovation with the need to reduce abuse, such as scraping, Denial of Service (DoS) attacks, and other harmful activities. While open, unauthenticated API access for everyone will continue, we will need to make adjustments. To reduce the likelihood and impact of abuse, we may apply stricter rate limits to unauthenticated traffic and more consistent authentication requirements to better match our documented API policy, Robot policy, and API etiquette guidelines, as well as consolidate per-API access guidelines to reduce the likelihood and impact of abuse.

To continue supporting Wikimedia’s technical volunteer community and minimize disruption to existing tools, community developers will have simple ways to identify themselves and receive higher limits or other access privileges. In many cases, this won’t require additional steps. For example, instead of universally requiring new access tokens or authentication methods, we plan to use IP ranges from Wikimedia Cloud Services (WMCS) and User-Agent headers to grant elevated privileges to trusted community tools, approved bots, and research projects. 

Documentation

It is essential for any API to enable developers to self-serve their use cases through clear, consistent, and modern documentation experiences. However, Wikimedia API documentation is frequently spread across multiple wiki projects, generated sites, and communication channels, which can make it difficult for developers to find the information they need, when they need it. 

To address this, we are working towards a top-requested item coming out of the 2024 developer satisfaction survey: OpenAPI specs and interactive sandboxes for all of our APIs (including conducting experiments to see if we can use OpenAPI to describe the Action API). The MediaWiki Interfaces team began addressing this request through the REST Sandbox, which we released to a limited number of small Wikipedia projects on March 31, 2025. Our implementation approach allows us to generate an OpenAPI specification, which we then use to power a SwaggerUI sandbox. We are also using the OpenAPI specs to automatically validate our endpoints as part of our automated deployment testing, which helps ensure that the generated documentation always matches the actual endpoint behavior. 

In addition, the generated OpenAPI spec offers translation support (powered by Translatewiki) for critical and contextual information like endpoint and parameter descriptions. We believe this is a more equitable approach to API documentation for developers who don’t have English as their preferred language. In the coming year, we plan to transition from Swagger UI to a custom Codex implementation for our sandbox experiences, which will enable full translation support for sandbox UI labels and navigation, as well as a more consistent look and feel for Wikimedia developers. We will also expand coverage for OpenAPI specs and sandbox experiences by introducing repeatable patterns for API authors to publish their specs to a single location where developers can easily browse, learn, and make test calls across all Wikimedia API offerings. 

Communication

When new endpoints are released or breaking changes are required, we need a better way to keep developers informed. As information is shared through different channels, it can become challenging to keep track of the full picture. Over the next year, we will address this on a few fronts. 

First, from a technical change management perspective, we will introduce a centralized API changelog. The changelog will summarize new endpoints, as well as new versions, planned deprecations, and minor changes such as new optional parameters. This will help developers with troubleshooting, as well as help them to more easily understand and monitor the changes happening across the Wikimedia APIs.

In addition to the changelog, we remain committed to consistently communicating changes early and often. As another step towards this commitment, we will provide migration guides and, where needed, provide direct communication channels for developers impacted by the changes to help guarantee a smooth transition. Recognizing that the Wikimedia technical community is split across many smaller communities both on and off-wiki, we will share updates in the largest off-wiki communities, but we will need volunteer support in directing questions and feedback to the right on-wiki pages in various languages. We will also work with communities to make their purpose and audience clearer for new developers so they can more easily get support when they need it and join the discussion with fellow technical contributors. 

Over the next few months, we will also launch a new API beta program, where developers are invited to interact with new endpoints and provide feedback before the capabilities are locked into a long-term stable version. Introducing new patterns through a beta program will allow developers to directly shape the future of the Wikimedia APIs to better suit their needs. To demonstrate this pattern, we will start with changes to MediaWiki REST APIs, including introducing API modularization and consistent structures. 

What’s Next

We are still in the early stages – we are just making the first steps on the journey to a unified API product offering. But we hope that by this time next year, we will be running towards it together. Your involvement and insights can help us shape a future that better serves the technical volunteers behind our knowledge mission. To keep you informed, we will continue to post updates on mailing lists, Diff, TechBlog, and other technical volunteer communication channels. We also invite you to stay actively engaged: share your thoughts on the WE5 objective in the annual plan, ask questions on the related discussion pages, review slides from the Future of Wikimedia APIs session we conducted at the Wikimedia Hackathon, volunteer for upcoming Listening Tour topics, or come talk to us at upcoming events such as Wikimania Nairobi. 

Technical volunteers play an essential role in the growth and evolution of Wikipedia, as well as all other Wikimedia projects. Together, we can make a better experience for developers who can’t remember life before Wikipedia, and make sure that the next generation doesn’t have to live without it. Here’s to another 25 years!