Hi @Zache thank you for recreating this task. Please note that it is currently hidden as per Outreachy's requirements; it will become publicly visible once the application period begins. You may continue to update it and any subtasks in the meanwhile. Thanks!

Hi @Zache thank you for submitting your proposal to the Outreachy site! It seems to be missing your co-mentor Teromakotero, could you please add them? Thanks!

Thanks! Afaik, co-mentors could be added only after the project was approved, but yes. I will ask Teromakotero to add himself.

Thanks @Zache I've approved him on the Outreachy site. Could you ask him to update the question "What is the contributor's mentorship style (how do they expect to interact with accepted interns)?" This is intended to ask about communication methods, frequency, etc. "Friendly" is great but more specifics would be helpful :)

Side note for Phab, just confirming he is @Teromakotero ? Let me know so I can add him to have access to the mentor group and this task.

In T387982#10614259, @LGoto wrote:

Thanks @Zache I've approved him on the Outreachy site. Could you ask him to update the question "What is the contributor's mentorship style (how do they expect to interact with accepted interns)?" This is intended to ask about communication methods, frequency, etc. "Friendly" is great but more specifics would be helpful :)

Side note for Phab, just confirming he is @Teromakotero ? Let me know so I can add him to have access to the mentor group and this task.

Yes, confirming that he is Teromakotero.

Just FYI for everybody.

As other users in Wikimedia Commons don't automatically know why you are changing categories when you are testing Cat-a-lot, it can look to them like you are vandalizing photos or doing random test edits when you are debugging it. Because of this, they may give warning that you should not be doing this kind of edits or admins can block you. So if there is no specific reason to test edits to certain files it is better to use test images.

In Wikimedia Commons safe images for doing test edits are images under the category "Test images"
https://commons.wikimedia.org/wiki/Category:Test_images

There is also the specific category:
https://commons.wikimedia.org/wiki/Category:Cat-a-lot_test_images

Third safe imageset is the images uploaded by FinnaUploadBot and its tracking categories (ie. these are images uploaded by my bot)
https://commons.wikimedia.org/wiki/Category:Files_uploaded_by_FinnaUploadBot

About creating categories It is also OK to create your own test categories for these images as long as the category names are distinct from real categories (i.e., a category name like "Zache's test category" is perfectly OK).

If you are doing test edits on images or categories outside the test images categories, ensure your edits either clearly improve categorization or revert your edits immediately after your test is complete. This helps avoid confusion and ensures other users understand your intentions.

Hi @Zache i'm interested in taking up this task as an active developer in maintaining this project and fixing bugs would you be willing to mentor me on this?

In T387982#10651813, @Gutopro911 wrote:

Hi @Zache i'm interested in taking up this task as an active developer in maintaining this project and fixing bugs would you be willing to mentor me on this?

Hi, I assume that there is multiple persons who are interessed and selection will be done based on contributions (ie. see https://www.outreachy.org/apply/project-selection/ ).

Hi @Zache. I have been working on the task and after setting up my environment and completing the steps, my changes are not effecting, I added a yellow background to the cat-a-lot to test and it did not display so i think I did something wrong in setting up. Could you help me with the issue please when you have the chance.

@Neyehh: Based on the code, it could be that the yellow color change is executed just before the CSS styles are loaded later in the init. When CSS loads, it overrides the color. Try moving the color change into run(), so when the cat-a-dialog opens, it should turn yellow and you know that your changes are effective.

• example

I will try this. Thank you! @Zache

@Neyehh FYI, we found the problem. There was typo in my guide on filename when script is loaded from user:username/common.js the pagename is Gadget-Cat-a-lot.js and not Gadget-cat-a-lot.js (ie. difference is upper case C ) ( see T389760#10669795

In T387982#10669966, @Zache wrote:

@Neyehh FYI, we found the problem. There was typo in my guide on filename when script is loaded from user:username/common.js the pagename is Gadget-Cat-a-lot.js and not Gadget-cat-a-lot.js (ie. difference is upper case C ) ( see T389760#10669795

I have been able to complete my Set-up. thank you!

@Zache A number of potential interns for this project are requesting Toolforge membership to work on tasks. I would like clarification from you of things like T390661: Django backend API for Cat-a-lot year filter being considered pre-selection microtasks or not. Historically WMCS has tried to discourage microtasks on Toolforge as they have generally been found to leave a trail of abandoned projects consuming compute resources for the indefinite future in their wake.

Noted, and yes, it is listed as a microtask. As far as I know, currently two persons (@Kooya3 and @RitaNamono) have said they're interested in doing it. If you like, we can do it so that they will do the local version first, I will check the code, and after that give access to Toolforge and create the Toolforge project then?

Basically, regarding the Outreachy selection, I don't need that the code be hosted on Toolforge. I can obtain the necessary information from valid efforts, code published on GitHub or GitLab too. I can also create the Toolforge project myself and set it up if needed. However, I think that it is good to get as much of the code as possible into use (merged into the official Cat-a-lot, real web services etc), as I feel it's important that contributors see their work having an impact. Additionally, I thinked that gaining hands-on experience with Toolforge might also be interesting and useful for them.

With the year filter in general, the goal is to create a dataset and a proof-of-concept to test whether year-based filtering could be an easily achievable enhancement for Wikimedia Commons. Most likely, Cat-a-lot itself isn't the ideal place for this feature—it would fit better as filter in Special:MediaSearch—but gadget-script works well as a prototype environment. This idea wasn't initially intended as a microtask; rather, it was part of broader ideas I've considered but haven't had time to implement. However, since I was somewhat short on microtasks, I decided to modify the idea so that suited as one.

In T387982#10728258, @Zache wrote:

Noted, and yes, it is listed as a microtask. As far as I know, currently two persons (@Kooya3 and @RitaNamono) have said they're interested in doing it. If you like, we can do it so that they will do the local version first, I will check the code, and after that give access to Toolforge and create the Toolforge project then?

If you can defer the need for Toolforge until the active internship phase that would be helpful to the Toolforge admins. That would relive us of needing to guess if a brand new SUL account is authentically a constructive contributor to the projects or just someone looking for free compute. It also ideally reduces the number of abandoned tools using the compute resources.

Additionally, I thinked that gaining hands-on experience with Toolforge might also be interesting and useful for them.

I hope it will be, and I really don't want to exclude anyone who is trying to contribute to the vast needs of technical contributors in the Wikimedia movement. If these candidates or any others in the future legitimately need Toolforge access to help with this project or others you mentor one helpful thing would be giving them some acknowledgement from you that they can link to from their Toolforge membership requests. It took me a bit of thinking time to connect the requests that @Kooya3 and @RitaNamono submitted to this Outreachy project. Having the internship relation with a known mentor explained makes it easier for Toolforge admins to reason about granting access to folks who seem extremely new to the movement.

I went ahead and approved @Kooya3 and @RitaNamono as new Toolforge members.

In T387982#10728312, @bd808 wrote:

In T387982#10728258, @Zache wrote:

Noted, and yes, it is listed as a microtask. As far as I know, currently two persons (@Kooya3 and @RitaNamono) have said they're interested in doing it. If you like, we can do it so that they will do the local version first, I will check the code, and after that give access to Toolforge and create the Toolforge project then?

If you can defer the need for Toolforge until the active internship phase that would be helpful to the Toolforge admins. That would relive us of needing to guess if a brand new SUL account is authentically a constructive contributor.

Sure and no problem. If we need toolforge hosting for the API I can set it up after they have it working locally so there is no need for toolforge accounts just now.

Thank you so much @Gopavasanth ! I’m incredibly excited to be part of the Outreachy program and grateful for this opportunity.
I’ll make sure to actively engage during the community bonding period, and I’ll refine my project timeline accordingly.
Looking forward to learning, contributing, and collaborating with the community! I’ll definitely reach out if I have any questions.

Weekly Internship Report
Week 1: June 2 - June 6

Overview of Tasks Completed:

• Created a blog post about myself where I introduced myself. Blog prompt: "Introduce yourself"
• Tested the consolidated file of all applicant contributions and created a comprehensive reference document. Identified and began resolving a UI resizing bug.
• Fixed the resizing issue and improved responsiveness across different layouts.
• Submitted the consolidated code for review, monitored user feedback, and proposed a fix for the settings UI bug affecting wikis like Beta Commons and Enwiki.
• Investigated Cat-a-lot’s behavior when handling a large number of files to assess performance under heavy load.

Challenges Faced:

• Debugging layout inconsistencies introduced by varied contributions.
• Inconsistent behavior of the settings UI across wikis made troubleshooting more complex.

Learnings and Skills Gained:

• Improved debugging and UI testing skills.
• Gained insights into large-scale gadget behavior and cross-wiki compatibility.
• Strengthened skills in collaborative code review and integration.

Weekly Internship Report
Week 2: June 9 – June 14

Overview of Tasks Completed:

• Worked on the Simulation Mode feature for Cat-a-lot to let users test actions without making real edits.
• Added a new preference setting to enable simulation mode and connected it with the main edit logic.
• Tested how Cat-a-lot handles a large number of files to check performance and UI behavior.

Challenges Faced:

• Unstable internet connection caused delays in testing and committing changes.
• Simulation flag wasn't being picked up as expected due to timing and scoping issues in initialization.

Learnings and Skills Gained:

• Learned how to debug timing issues and work with preferences in gadgets.
• Improved understanding of how Cat-a-lot handles edits and API calls.

Weekly Internship Report
Week 3: June 16 – June 20

Overview of Tasks Completed:

• Explored how Cat-a-lot could be extended to support large batch editing by integrating it with the QuickCategories tool.
• Successfully created a minimal script to generate a PagePile using PetScan and extract the PagePile ID programmatically.
• Tested different ways to send POST requests and parse HTML responses, using both plain JavaScript and jQuery.
• Opened a pull request to add support for URL parameters (actions and title) in QuickCategories for PagePile batches.
• PR was reviewed, merged, deployed, and even announced on Mastodon!

Challenges Faced:

• Had trouble capturing the PagePile ID initially due to the way PetScan returns its response.
• Couldn't get the PagePile API to work dirrectly so had to find a work around through PetScan.

Learnings and Skills Gained:

• Learned how to use jQuery and form-based POST requests to interact with external tools like PetScan.
• Gained hands-on experience with contributing to external tools, opening PRs, and working through CI issues.
• Understood how to structure incremental features when the full workflow isn't yet possible.

Weekly Internship Report
Week 4: June 23 – June 27

Overview of Tasks Completed:

• Added a toggle in Cat-a-lot to enable QuickCategories for large categories.
• Included an info dialog and visual highlighting when enabled.
• Preserved hybrid mode for large manual selections.
• Refactored title generation logic for QuickCategories.
• Reported QuickCategories slowness (linked to Toolforge issue).
• Shared demo video with mentor for feedback.

Challenges Faced:

• Ensuring only files are highlighted, not pages or subcategories.
• Debugging slow QuickCategories loading.

Learnings:

• Improved UI logic, modular functions, and toolchain debugging.

Weekly Internship Report
Week 5: June 30 – July 4

Overview of Tasks Completed:

• Enabled HotCat to work on Data namespace pages.
• Parsed and displayed existing categories using mediawikiCategories.
• Implemented category addition/removal without breaking the JSON structure.
• Ensured changes result in valid and properly formatted JSON.

Challenges Faced:

• Had to get familiar with the HotCat codebase while previously working only on Cat-a-lot.

Learnings:

• Understood how HotCat integrates with different content models in MediaWiki.
• Learned to parse, modify, and safely update JSON-based pages.
• Got more comfortable working with a new legacy codebase and debugging across tools.

Weekly Internship Report
Week 6: July 7 – July 11

Overview of Tasks Completed:

• Built a Codex-based PetScan UI userscript with tabs: Basic, Categories, Templates, Saved Queries, and Settings.
• Integrated Codex components like tabs, sliders, fields, and buttons.
• Constructed dynamic PetScan query URLs based on user input.
• Fetched and displayed matching file thumbnails in a responsive image grid.
• Implemented saving, loading, and deleting custom queries.

Challenges Faced:

• Codex has minimal documentation for userscripts, so setup required trial and error.
• Ensuring layout adapted correctly to dynamic thumbnail sizes.

Learnings:

• Learned how to use Codex with Vue in on-wiki userscripts.
• Gained experience building structured UI with Codex components.
• Understood how to work with PetScan’s API and filter valid file results.

Weekly Internship Report
Week 7: July 14 - July 18

Overview of Tasks Completed:

• HotCat Enhancements:
  • Made error messages translatable for Data namespace edits.
• Cat-a-lot Sort Key Fixes:
  • Fixed issues with sort keys failing in JSON mode by updating regex logic, normalizing category inputs, and ensuring consistent handling across wikitext and JSON. Improved error handling and added documentation.
• PetScan + Cat-a-lot UI Integration:
  • Finalized Codex-based UI with support for categories, templates, saved queries, and deep linking via URL hash params.
  • Integrated Cat-a-lot selection into the image grid and resolved timing issues with selection detection.
  • Added a “Copy query link” button and live summary of active filters.

Challenges:

• Debugged Cat-a-lot selection issues due to image grid structure and timing.
• Handled edge cases like missing thumbnails for non-image files.
• Codex lacks clear docs for use in on-wiki userscripts.

Learnings:

• Learned how sort keys behave in MediaWiki’s JSON model.
• Got hands-on with Codex + Vue inside userscripts.
• Improved debugging strategies for legacy tools like Cat-a-lot.

Weekly Internship Report
Week 8: July 21 – July 25

Overview of Tasks Completed:

• Added localStorage support to remember Cat-a-lot’s open/closed state across page loads and namespace changes.
• Cleaned up cookie-based logic and fixed back navigation issues.
• Ensured search key is remembered using cookies and auto-restored on reload.

Challenges:

• Handling state persistence across namespaces and browser history.
• Deciding when *not* to restore UI to avoid confusion.

Learnings:

• Learned how to manage session state in legacy scripts.
• Improved debugging strategies for UI behavior across MediaWiki pages.

Weekly Internship Report
Week 9: July 28 - August 1

Overview of Tasks Completed:

• Added support for remembering Cat-a-lot’s window position and size using localStorage.
• Introduced a rememberPos setting to toggle this feature.
• Worked on fixing sort key issues for better category organization.

Challenges:

• Restoring position before UI renders to avoid jumpiness.
• Handling resize via right border and deciding when to reset position.

Learnings:

• Improved handling of persistent UI state in legacy gadgets.
• Better understanding of event-driven resizing and layout quirks.

Weekly Internship Report
Week 10: August 4 – August 8

Overview of Tasks Completed:

• Tested sort key edit functionality.
• Tested position and size updates to the Cat-a-lot UI dialog.
• Attended all four days of Wikimania and wrote a blog summarizing my key learnings.

Learnings:

• Gained deeper understanding of sort key editing and how it impacts categorization workflows.
• Learned how UI dialog properties (position and size) can be updated and tested for better user experience.
• Broadened my perspective on Wikimedia projects, GLAM initiatives, Wikidata, and AI applications in cultural heritage through Wikimania sessions.

Weekly Internship Report
Week 11: August 11 – August 15

Overview of Tasks Completed:

• Set up Cat-a-lot development with Tampermonkey, first using localhost and then GitHub.
• Documented the setup process here: GitHub repo.
• Tested the fix for the result window to handle long content better.

Learnings:

• Learned how to use Tampermonkey and GitHub for smoother script testing.
• Gained insights into how the result window behaves with different widths/heights across browsers and mobile.
• Understood the importance of testing beyond Chrome to ensure broader compatibility.

Weekly Internship Report
Week 12: August 18 – August 22

Overview of Tasks Completed:

• Looked into adding sort key support for QuickCategories integration with cat-a-lot.
• Investigated a bug reported by a user where Cat-a-lot did not handle empty sort keys ([[Category:Foo| ]]) correctly.

Learnings:

• Learned the challenges of extending sort key support to integrations like QuickCategories, especially where category handling logic may differ.
• Gained a deeper understanding of edge cases in sort key handling and how small parsing differences can break expected behavior.
• Improved skills in writing normalization logic to keep category edits consistent and bug-free.