Hi, thanks for submitting your GSoC 2026 project proposal with Wikimedia!

Please make sure you’ve also submitted your proposal on the official Summer of Code website: https://summerofcode.withgoogle.com. The deadline for both submission and any edits is the same, so ensure everything is finalized before March 31, 18:00 UTC, as changes won’t be possible after that.

We strongly recommend completing any updates at least 30 minutes before the deadline to avoid last-minute glitches or unexpected technical issues.

Wishing you all the best for your application. Hope to see you as part of the program soon! 🚀

Hi! @Gopavasanth Thank you very much for the reminder and the well wishes. I am continuing to stay active on Gerrit and following the project discussions closely. I'm looking forward to the next steps!

Hi mentors (@theprotonade, @SGill)

I am very happy to have the opportunity to contribute to the Wikisource Bulk OCR Improvements project this summer. Thank you for accepting my proposal!

I am looking forward to the Community Bonding phase and learning more about the community's practices. I am ready to start refining the project plan and milestones whenever you are available to discuss them.

Happy to be part of the team!

Hi mentors (@theprotonade @SGill)

I have updated the project timeline in the description to reflect my focus for the bonding period.

Updated project timeline for Weeks 3–5 to reflect mentor feedback regarding existing access controls and the feedback model design phase.

Hi team I have finished setting up everything for the community bonding period. My environment is up and running smoothly with Docker and I'm done reviewing BulkOcrWidget.js and the OCR API. I put together the full report showing the completed tasks, challenges and next steps on my MediaWiki subpage here: Hussein m mmbaga
Everything is ready for the coding phase to start. @theprotonade @SGill please take a look when you have a moment.

Hello @theprotonade @SGill
Week 1 Weekly Report -May 25 – May 31, 2026

Reproduced T411157 visually in a working local environment. I uploaded a book 8-page PDF (L'Homme Spermatozoaire 1907) created a ProofreadPage Index page and clicked Bulk OCR. I observed exactly the behavior described in T411157.

1. A GREEN Bulk OCR executed successfully notification appears . At the same time 8 RED Failed to process OCR for Page notifications appear. The success notification displays even though every single page failed.
2. I identified that my previouse submitted patch 1252657 does NOT fully fix the bug.
3. I also found a secondary bug the OCR error notification uses a hardcoded English string Failed to process OCR for pageTitle instead of an i18n message key.

Challenges I Faced
1.Explore huge extension config flags and JavaScript code

What I Learnings This Week
1.MediaWiki mw.notify only accepts specific type strings.
2.For Wikimedia extensions all user facing strings MUST go through mw.msg() with a key defined.
3.The banana-checker tool

Plan for Week 2 (June 1 – June 10)
1.Confirm Patch 1 approach with mentors. Get their thoughts.
2.Address any reviewer feedback on Gerrit change 1252657.
3.Fix the warning to warn issue in Patch 1 if not already amended push new patch.
4.explore the new Phabricator task for the OCR-failure-tracking scope.
5.implement ocrFailedPages tracker
6.fix i18n violation write QUnit tests for both success and warning paths.
7.fix T413556 rotate option in parallel

Week 2 Report

Period: June 1 – June 7, 2026

Hello @theprotonade, @SGill

Tasks completed

• T411157: Patchset 2 of 1252657 pushed. The patch now covers eight changes in one focused commit:
  • OCR-step failure tracking (this.ocrFailedPages)
  • Correct parameter substitution in the with-failures message
  • OOUI notification type corrected from 'warning' to 'warn'
  • i18n violation fixed via new message key wikisource-bulkocr-process-failed
  • Single summary notification no more per-page red boxes
  • Persistent notifications with custom close (X) button
  • Cancel on first error behaviour
  • New message key registered in extension.json ResourceModules

• T413556 skipped per mentor guidance - another active contributor is already working on it.

Challenges faced

• Docker DNS configuration , OCR service cannot reach localhost - needed Commons hosted file to test the success path. This was not easy to see or understand. until @theprotonade @SGill directed me to go and read https://www.mediawiki.org/wiki/Manual:$wgUseInstantCommons.

Learning and skills gained

• MediaWiki foreign file repository system and how $wgUseInstantCommons lets a local wiki proxy Commons files transparently.
• JavaScript message bundles are separate from PHP message bundles
• The Rockstar Programmer workflow with Gerrit: git commit --amend preserves Change-Id across iterations one Change = one conceptual fix commit messages should explain WHY.

Plan for Week 3

• Address any reviewer feedback on PatchSet 2 of 1252657.
• Start the feedback modal design phase per @theprotonade @SGill suggestion.
• Audit the existing user-group restrictions implementation.

Week 3 Report

Period: June 8 – June 15 2026
Mentors: @theprotonade, @SGill

Tasks completed

1. Studied how MediaWiki user group permissions work. Read the official documentation Understood how rights propagate from default groups user, autoconfirmed, sysop and how extensions add custom rights.

2. Reviewed the existing Bulk OCR usergroup restriction code. Located the permission check in the Wikisource extension traced how the Bulk OCR button is hidden from nonauthorized users and verified the implementation matches the design described on Phabricator.

3. Tested the restriction locally created a regular test users with and without sysop or bureaucrat rights. Confirmed the Bulk OCR button is hidden for that user and visible for my admin account.

4. Reviewed the feedback modal design Studied the design notes provided on the project task and identified the key components

5. Searched for existing design references.

Challenges faced

1. Finding where the permission check actually lives in the code

Learnings and skills gained

1. MediaWiki user rights system on how rights are checked how to expose those decisions.

2. OOUI patterns for review modals and how Wikimedia projects typically structure approval workflows.

Plan for next week - June 16 – June 22

1. Address any reviewer feedback that arrives on Patchset 2 of 1252657.
2. Continue review the feedback model design

Week 4 Report

Tasks completed

1. Reviewed the existing codebase restricting Bulk OCR to authorized users to verify security and ensure the logic works as intended.

2. Analyzed the relationship between global configuration structures, user rights, hook registrations and dynamic logic validation

Challenges faced

1. Docker image broke local Xdebug configuration

Learnings and skills gained

1. Learning how core MediaWiki dynamically builds and resolves default user permissions

2. Learn database layers on mediawiki.

3. Learned how to translate conceptual UI feedback model

Plan for next week

1. Continue review the feedback model design

Week 5 Weekly Report

Tasks completed

• Studied how MediaWiki user group permissions work. Read the official manual on user rights.
• Started identifying edge cases the feedback modal must handle

Learnings and skills gained

• MediaWiki permission system is simple but powerful. Every action is a named and groups bundle.
• The importance of reading before writing.
• How to present open source work publicl and invite community feedback.

Plan for next week

• Continue the feedback modal design.
• Address any reviewer feedback on Patchset 2 of 1252657.

Hi! Hope you're doing well and that your project has been progressing smoothly. We also hope you've had a great experience collaborating with your mentors, the org admins, and the wider Wikimedia community so far.

Just a friendly reminder to keep your weekly reports up to date on the MediaWiki GSoC 2026 page. This helps the mentors, org admins, and the community stay informed about your project's progress and makes it easier for everyone to follow your work throughout the program.

Please refer to the participant guidelines here:
https://www.mediawiki.org/wiki/Google_Summer_of_Code/Participants#Accepted_participants

You can update your weekly updates and monthly reports here: https://www.mediawiki.org/wiki/Google_Summer_of_Code/2026#Accepted_projects

Thank you, and keep up the great work!

Hi! Thanks for the reminder. Everything is going great and I have really enjoyed working with my mentors and the community. I will make sure to keep my weekly reports up to date on the MediaWiki page.

Week 6 Weekly Report

Tasks completed

• Verified and tested the existing OCR engine selection in the Bulk OCR widget. Confirmed that the engine dropdown correctly loads the available engines and passes the chosen engine to the OCR request.
• Tested engine and language selection end to end. Ran Bulk OCR on the Commons hosted test book with different engine and language combinations and confirmed the resulting OCR text matched the selected settings.

Learnings and skills gained

• How the Bulk OCR widget stores selected engine and language values and how these values reach the actual OCR request.
• The value of writing tests that already works so future changes do not break silently.

Plan for next week

• Begin implementing the feedback modal structure using the OOUI Dialog component.
• Prepared the video demo for non-technical readers to follow along.

Week 7 Weekly Report

Tasks completed

• Studied the OOUI Dialog component documentation including the Process dialog, Booklet layout and Progress bar widget sections.
• Read the three existing Process dialog implementations in the codebase to learn the established patterns example Download dialog, Save options dialog and Page list input widget dialog in ProofreadPage
• Designed the feedback modal structure and layout based on the requirements and the patterns from the three existing dialogs.
• Built a static HTML/CSS/JavaScript prototype of the feedback modal and published it to GitHub Pages so mentors and community members can interact with it directly in the browser.
• Prototype live at: https://sseinmmbaga.github.io/bulk-ocr-prototype/
• Documented all design decisions: https://sseinmmbaga.github.io/bulk-ocr-prototype/README.md

Challenges faced

• Making the prototype feel like a real MediaWiki interface without pulling in the OOUI library. I used Vector 2010 styling conventions to match the reference environment.

Learnings and skills gained

• Deep understanding of the OOUI Process dialog
• How Booklet layout with outlined structures the sidebar and content pane pattern.
• How Message dialog styling differs from browser popups and why using the OOUI pattern matters for a consistent Wikimedia user experience.

Plan for next week

• Wait for and address mentor feedback on the prototype design.

Week 8 Weekly Report

Tasks completed

• Shared the feedback modal prototype with mentors for review and received design feedback.
• Re-read the OOUI Booklets and Pages and Indeterminate ProgressBar documentation in preparation for the real implementation.
• Studied T394130 to understand the parent Bulk OCR flow the feedback dialog must integrate with.

Learnings and skills gained

• Deeper understanding of OOUI Indeterminate progress patterns for long-running background operations.

Plan for next week

• Apply mentor feedback and finalise the design.
• Start real implementation using OO.ui.ProcessDialog, BookletLayout, and an indeterminate progress bar.

Week 9 Weekly Report

Tasks completed

• Received mentor confirmation on the feedback dialog design and the child-task breakdown. Linked the sub-tasks to the parent GSoC task T415145 for visibility.
• Created 9 sub-tasks under T394131 on Phabricator each with a clear title, description, acceptance criteria and OOUI component references:
  • T433033 — Show image and OCR text side by side
  • T433167 — Wrap the split view in BookletLayout with 5 pages
  • T433172 — Add safety banner at the top of the dialog
  • T433174 — Add indeterminate progress bar
  • T433181 — Make OCR text editable using Multiline Text Input Widget
  • T433182 — Set the Approve action to write OCR text to page text layer
  • T433183 — Set the Cancel action with unsaved-changes warning
  • T433190 — Add error handling for pages where OCR failed
  • T433191 — Update Index pagelist to reflect approved page status

Learnings and skills gained

• Phabricator sub-task creation and parent linking conventions.
• Writing task descriptions that give reviewers enough context without over specifying implementation details.
• Coordinating with community members who show interest in overlapping work.

Plan for next week

• Begin implementation starting with the foundation task Push the first patch to Gerrit and link it to its sub-task.

Week 10 Weekly Report

Tasks completed

• Implement and pushed T433033 to Gerrit the foundation patch that adds the Process dialog hooks into the ocr-complete event and shows OCR text and page image side by side. link.
• Implement and pushed T433167 to gerrit this patch wrapped the split view in Booklet layout with an outline sidebar so users can navigate between all complete OCR pages. link.

Challenges faced

Debugging the Booklet layout integration due to layout and page visibility issues. After investigating and testing multiple solutions I identified the cause and implemented a working fix.

Learnings and skills gained

• The interaction between Process dialog, getbody height and Booklet layout
• Using browser DevTools console diagnostics to verify events

Plan for next week

• Address any reviewer feedback on T433033 and T433167.
• Start implementation of T433172 - safety banner at the top of the dialog.
• Start implementation of T433174 - indeterminate progress bar.

Week 11 Weekly Report

Tasks completed

• The foundation patch merged T433033 (feedback dialog showing OCR results side by side) received Code-Review +2 from Sam Wilson and Sohom passed CI and merged to master. This is the base the rest of the feedback dialog builds on.

• Rebased the whole feedback-dialog stack onto master after the foundation merged resolving the changes cleanly so each patch sits on current master with no conflicts.

• Addressed mentor feedback on the BookletLayout patch (T433167) pages in the sidebar are now sorted in book order and mirrors correctly on right-to-left wikis example: Arabic, Persian and Hebrew.

• Implemented and pushed the open at start design (T433174) and follow the discussion with Sam Wilson. The feedback dialog now opens as soon as untranscribed pages are found it shows an indeterminate progress bar with a counting label and streams pages into the sidebar in book order as each page OCR completes. Approve is disabled until processing finishes and error on failures show inside the dialog.

• The read-only text panel is now an editable. Edits are saved on Approve instead of the original OCR text and persist while navigating between pages in the same session.

Patches in review

• T433167 Wrap the feedback dialog in BookletLayout: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikisource/+/1319941
• T433172 Add safety banner to the feedback dialog: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikisource/+/1323091
• T433174 Open the dialog at start with progress bar and streaming pages: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikisource/+/1323786
• T433181 Make the OCR text editable: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikisource/+/1323863

Merged patch

• T433033 Add feedback dialog showing OCR results before saving: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikisource/+/1318153

Learnings

• Learned to rebase a stack of dependent patches onto master after a base patch merges and to verify message keys.
• Learning OOUI (Object-Oriented User Interface) a component-based JavaScript UI library used in Wikimedia projects. I’m learning how to work with its widgets, layouts, dialogs, classes, mixins, themes, icons, internationalization and accessibility features.

Next steps

• T433190 Error handling for pages where OCR failed
• Verify T433182 (Approve saves to pages) and T433191 (pagelist status update) against the existing implementation and mark them resolved.
• Begin preparing the final Work Product page.