Profile
Name: Eileen Blessing Mbong Kabi
Username: EileenBlessing
GitHub: https://github.com/Kabi12Blessing/
Location: Kigali, Rwanda
Timezone: UTC+2 (Central Africa Time)
My ideal working hours: 2pm to 10pm UTC+2 (approximately 40 hours per week)
Synopsis
The Lusophone technological wishlist is a community-driven survey carried out among editors, readers and researchers of Wikimedia projects in Portuguese. Its goal is to identify and prioritize the technological improvements that would most meaningfully benefit this community. The wishlist connects directly to community wishes 17 and 192 in the global Community Wishlist, the Contributor Experiences (WE1) subbucket of the WMF Annual Plan, and more specifically to Lusophone wishlist wishes 3 and 8.
For this internship, I intend to implement both wishes from the 2025 Lusophone wishlist. I will start with Wish 3 and move to Wish 8 in the second half of the internship.
Wish 3: Automatic Duplicate Reference Detection in the Visual Editor
When editing a long Wikipedia article using the Visual Editor, it can be difficult to know whether a reference you are about to add has already been used somewhere else in the article. Editors, especially newer ones, frequently end up adding the same URL, DOI, or ISBN more than once without realizing it. This creates redundant references that clutter the article source and make the citation structure harder to maintain.
Wish 3 proposes solving this by building a feature directly into the Visual Editor that checks a reference identifier against all existing references in the article the moment an editor adds one. If a match is found, the editor sees a clear notification telling them the reference already exists and offering them the option to reuse it instead of creating a duplicate. The feature should also include an autocomplete suggestion when typing a DOI, ISBN, or URL, showing the editor any matching references already in the article. Additionally, if an editor has already accidentally created a duplicate, there should be a merge option to consolidate them cleanly.
I have strong JavaScript skills and have worked extensively with DOM manipulation and API interactions across web projects. I am also very particular about user experience and interface design, so I want to build this in a way that feels non-intrusive inside the Visual Editor.
Wish 8: Wikidata Scoring Support for WikiScore
WikiScore is a tool built by Wikimedia Brasil to track and score user contributions during edit-a-thons and editing contests. It currently only counts Wikipedia edits, which means that when a contest includes Wikidata contributions, organizers have to count those manually or rely on workarounds that are slow and error-prone.
Wish 8 proposes adding full Wikidata support to WikiScore so that contributions to Wikidata are automatically fetched, scored, and displayed alongside Wikipedia contributions. This makes contests more inclusive, more accurate, and less stressful for organizers. Wikidata is increasingly becoming an entry point for new contributors to the Wikimedia ecosystem, so having proper tooling for Wikidata-inclusive contests is a meaningful step forward for the community.
I will implement this using Python, where I have extensive experience building scripts that interact with APIs, parse structured data, and handle edge cases like rate limiting and inconsistent response formats. My goal would be to integrate Wikidata scoring cleanly into WikiScore's existing architecture.
Mentors
Artur Corrêa Souza (Arcstur)
Éder Porto (Ederporto)
Timeline
The Outreachy internship runs from May 18, 2026 to August 17, 2026. I am committing 40 hours per week throughout this period, working from 2pm to 10pm UTC+2. This timeline is flexible. Since I am dedicating this entire period exclusively to this internship, I am able to adjust, speed up, or shift tasks based on mentor feedback, unexpected technical challenges, or opportunities to go deeper on any particular feature.
Throughout the internship I will send weekly progress reports to mentors covering what I worked on, what I completed, what blockers I encountered, and what I plan to do the following week. Feedback from mentors will be actively incorporated at the end of each major phase before moving to the next.
Weeks 1 through 8 focus on Wish 3 (Visual Editor duplicate reference checker). Weeks 9 through 12 focus on Wish 8 (WikiScore Wikidata support). Week 13 is dedicated to final documentation, handover, and the closing blog post.
| Period | Tasks | ||
| Week 1 (May 18 - May 22, 2026) | This week is fully dedicated to understanding and setup so that implementation can begin without interruption from Week 2. Kick-off meeting with mentors to align on goals, communication style, and confirm the timeline. Read through all Lusophone wishlist proposals in detail, particularly Wish 3 and Wish 8, including all community discussions and vote reasoning. Study MediaWiki's reference system documentation and trace the full lifecycle of a reference in the Visual Editor from when the user clicks Cite to when it is saved to the article. Understand how the VE stores reference data internally and how it communicates with the MediaWiki API. Set up the complete development environment: configure a local MediaWiki instance, install Node.js tools for Visual Editor development, set up Wikimedia developer account, and create the project GitHub repository with a README and clear folder structure. Document all findings. Write and publish Blog Post 1: Introduction to the internship. Send first weekly report to mentors. | ||
| Week 2 (May 25 - May 29, 2026) | Begin implementation immediately. Write JavaScript functions to extract all existing references from a Wikipedia article and normalize their identifiers: strip hyphens and spaces from ISBNs, normalize URL formats handling http vs https and trailing slashes, and handle DOI case sensitivity. Build the core comparison engine that checks a newly entered reference identifier against all existing ones in the article. Write unit tests for all normalization and comparison functions and make sure they pass across a variety of real Wikipedia articles. Document progress and send weekly report to mentors. | ||
| Week 3 (Jun 1 - Jun 5, 2026) | Implement the user-facing alert system. When the comparison engine detects a duplicate reference, display a clear and non-intrusive notification inside the Visual Editor telling the editor exactly which reference is duplicated. Offer two clear options: reuse the existing reference, or proceed with adding a new one. Make sure the alert UI matches the Visual Editor's existing design patterns so it feels like a native part of the editor and not something bolted on. Test across different article structures, reference types, and article lengths. Send weekly report to mentors. Write and publish Blog Post 2: Getting into the Visual Editor codebase. | ||
| Week 4 (Jun 8 - Jun 12, 2026) | Implement the autocomplete feature. When an editor begins typing a DOI, ISBN, or URL in the citation dialog, the tool queries all existing references in the article and shows matching suggestions in real time. Handle edge cases carefully: very long articles with hundreds of references, references with missing or incomplete identifiers, and articles using mixed reference styles. Test across a wide range of Wikipedia articles. Send weekly report to mentors and document progress. | ||
| Week 5 (Jun 15 - Jun 19, 2026) | Add the reference merge feature. If an editor has already accidentally added a duplicate reference, they should be able to select both and merge them into one without losing any citation locations in the article. This requires updating all instances of the duplicate reference tag throughout the article to point to the canonical one. Carry out extensive testing across long articles with complex citation structures. Fix bugs found during testing and refine all edge case handling. Send weekly report to mentors. Write and publish Blog Post 3: Building for real users. | ||
| Week 6 (Jun 22 - Jun 26, 2026) | Performance review and optimization of the entire duplicate checker feature. Measure how it performs on very long articles with 500 or more references. Optimize the comparison algorithm where needed to make sure it does not slow down the editing experience. Share the current state of the tool with mentors for a full review session. Incorporate all feedback received. Send weekly report and post detailed update. | ||
| Week 7 (Jun 29 - Jul 3, 2026) | Finalize all technical documentation for the duplicate reference checker. Write clear documentation for future MediaWiki contributors explaining how the feature works, how to extend it, and the reasoning behind key design decisions. Carry out usability testing by sharing the tool with actual Wikipedia editors where possible and collecting feedback. Make final UI and logic adjustments based on feedback. Send weekly report to mentors. Write and publish Midpoint Progress Blog Post. | ||
| Week 8 (Jul 6 - Jul 10, 2026) | Final code review and cleanup for the complete Wish 3 implementation. Ensure all code meets MediaWiki contribution standards. Write and submit the patch through Gerrit. Respond to code review comments from the community. Make sure all tests pass. Mentor feedback session to confirm Wish 3 is complete and ready before shifting focus. Send weekly report. Write and publish Blog Post 4: What open source taught me about collaboration. | ||
| Week 9 (Jul 13 - Jul 17, 2026) | Shift full focus to Wish 8. Study the WikiScore codebase thoroughly: understand its architecture, how it currently fetches Wikipedia edit data, how it calculates scores, and how it displays results. Study the Wikidata API in detail, specifically the RecentChanges and Contributions endpoints. Understand how Wikidata edits differ structurally from Wikipedia edits and what metadata is available. Write up the full integration plan and share it with mentors for review and approval before any implementation begins. Send weekly report. | ||
| Week 10 (Jul 20 - Jul 24, 2026) | Begin implementation of Wikidata support in WikiScore. Write Python functions to connect to the Wikidata API, fetch contributions for a specific user within a given time range, and parse the response into a clean structured format that WikiScore can work with. Handle API rate limiting properly so the tool remains stable during large edit-a-thons with many participants. Write unit tests for all data fetching and parsing functions. Set up a local testing environment using sample edit-a-thon data. Send weekly report and document progress. | ||
| Week 11 (Jul 27 - Jul 31, 2026) | Implement the full scoring logic for Wikidata contributions. Define clearly how different types of Wikidata edits are scored: adding claims, adding references to claims, creating new items, adding labels and descriptions across multiple languages. Integrate the Wikidata scores into WikiScore's existing interface so that contest organizers can see both Wikipedia and Wikidata contributions clearly in one unified view. Test thoroughly using real edit-a-thon scenarios. Incorporate mentor feedback. Send weekly report. Write and publish Blog Post 5: Building tools that communities actually need. | ||
| Week 12 (Aug 3 - Aug 7, 2026) | Performance testing and optimization of the WikiScore Wikidata integration. Test with large datasets from past edit-a-thons to make sure the tool handles scale well. Fix all bugs found. Carry out a full review session with mentors. Finalize the implementation and make sure it is stable and ready for real use. Send weekly report and post final Wish 8 update. | ||
| Week 13 (Aug 10 - Aug 17, 2026) | Final code cleanup and complete documentation for both tools. Make sure all code is properly commented, all documentation is accurate and accessible to future contributors, and everything is deployed and publicly accessible. Prepare detailed handover notes for mentors covering what was built, how to maintain each tool, known limitations, and ideas for future improvements. Write and publish the Final Progress Blog Post summarizing the full internship experience. Send final weekly report. | ||
| Post-Outreachy | Continue contributing to Wikimedia. Monitor both tools for bugs and respond to feedback from Wikipedia editors and WikiScore users. Stay involved in the Wikimedia technical community and mentor future Outreachy applicants where possible. | ||
Contributions
GitHub Repository: https://github.com/Kabi12Blessing/Outreachy-wikimedia
Task 1 (JavaScript): https://kabi12blessing.github.io/Outreachy-wikimedia/Task%201%20-%20Intern.html
Task 2 (Python): https://github.com/Kabi12Blessing/Outreachy-wikimedia/blob/main/task2.py
Prototype - Duplicate Reference Checker (Live Demo): https://kabi12blessing.github.io/Outreachy-wikimedia/prototype/refchecker.html
Demo Video: https://youtube.com/shorts/o2f7z-q3Pc4
After the Internship
I intend to stay involved in the Wikimedia technical community after the internship ends. Both tools I will build during this project are things communities depend on, and I want to be around to maintain them, respond to bug reports, and keep improving them based on editor and organizer feedback. I also plan to mentor future Outreachy applicants and continue contributing to open source as a regular part of my work as a developer, Thank you.