Weekly Internship Report

Weekly Internship Report

Weekly Internship Report

Weekly Internship Report

Weekly Internship Report

Week 9 (July 28 –  August 1) Update:

Task Progress

• Identified that missing slots like header and footer were not preserved across revisions.
• Implemented logic to restore missing slots by fetching them from previous revisions.
• Discovered the issue where each slot file was being imported as a separate revision.
• Changed the import logic to group all slot contents per page and import them in a single revision.
• Raised Pull Requests for Code Review to address import issues: PR

Challenges Faced

• The import process was overwriting previous content instead of merging slots,which was causing the header and footer to be dropped and not present in the latest imported file.
• A Lua error occurred due to incorrect module syntax (Module:Lustache/Renderer instead of Module:Lustache:Renderer),breaking page rendering.

Key Takeaways

• Feedback from my Mentors @Simontaurus and @Thomas-topway-it (e.g., missing slots and grouping all files with the same name) was instrumental in improving the the importer.
• All slot contents for a page need to be imported together in one revision to prevent slot loss.

Weekly Internship Report

Weekly Internship Report

Weekly Internship Report

Weekly Internship Report

Weekly Internship Report

Week 4 (June 23 –  June 27) Update:

Task Progress

• Discovered and explored the main repo for world.opensemantic.core and world.opensemantic.base.
• Cloned it and copied the core and base folders into a directory, then shared it as TAR archive to my mentor.
• Created a use-case example for the MwJson extension to demonstrate how it can be used to manage structured data with JSON schemas in MediaWiki.
• Studied and tested the OSLRef extension.
• Fixed import bugs in OSLRef and created a pr to fix the issue.

Challenges Faced

• Faced Import issues while testing OSLRef.
• Unable to get some pages in my mediawiki instance or on the github page as instructed by my mentor

Weekly Internship Report

Week 3 (June 16 –  June 20) Update:

Task Progress

• Wrote my second blog Everyone Struggles
• Created a directory that has the contents required by OSL using PageExchange.
• Located the Official PageExchange Package Index and Identified Required Core Packages. OSW Core and OSW Base.
• Created a PHP Script to to extract and save PageExchange package contents as individual files in the respective directory.
• Provided the TAR Archive and identified any empty files within it for review and cleanup.

Challenges Faced

• Prefix Property was missing for the files in the Directory.
• Some files were empty due to the extraction logic.

Key Takeaways

• Improved my PHP skills by creating a script that reads a PageExchange package JSON file, downloads each page’s content and slots, and saves them in a directory.
• Learnt the importance of including correct prefixes while fetching the files, as missing them can break compatibility or even prevent importing them correctly.

Weekly Internship Report

Week 2 (June 9 –  June 14) Update:

Task Progress

• Studied my OSL setup guide and reviewed it together with my mentor.
• Updated my Open Semantic Lab (OSL) Installation Guide with steps to open the editor with a schema after installation.
• Installed another Mediawiki environment with OSL using my guide to compare with my previous installation to see if data editor works.
• Checked if Special:SlotResolver/Category/OSW92cc6b1a2e6b4bb7bad470dfdcfdaf26.slot jsonschema.json is having an empty article.
• Inspected OSL demo instance to see the expected Category page if the installation is successful.

Weekly Internship Report

Thank you so much! @Gopavasanth
I'm really excited to be part of Outreachy and make meaningful impact to the wikimedia project. I appreciate the support and will definitely reach out if I have any questions. Looking forward to a great journey ahead!

@Zache
Thank you for the update to the task
I made a comment showing the step i took to recreate the bug but i didnt get any feedback on how to progress with the issue,
this recent feedback will help me tackle this issue effectively as it is related to all issues i've fixed previously.
I'm looking forward to collaborating with @Isaacbriandt and fix the bug

Changes made based on your feedback:

1. Fixed the dialog close issue: Remove the close the error dialog from top-right corner X
2. Improved mobile styling: Added left padding to the error dialog on small screens. Previously, text was flush against the screen edge. But i'm not sure if i could use mobile-responsive media query to fix that, However it worked please let me know If this complies with MediaWiki's CSS guidelines.

Thanks for the feedback so far
It was indeed helpful in fixing this bug
About the testing in BETA commons i would fix that in the description.

In T390131#10714813, @adiba_anjum wrote:

Hey! Everything works well now—great job!

At first, I was running into issues because I had loaded the script into the common.js of Wikimedia Commons, but the test category mentioned in the description is on Beta Commons, so nothing was working initially. Once I realized my mistake and loaded the script correctly, everything functioned as expected.

I think it would be helpful to mention in the description that the script needs to be loaded in Beta Commons for testing, so others also don't repeat my mistake.

Alright Noted i will fix that

In T390242#10714767, @Zache wrote:

Just some comments more. I noticed couple things when I tested the error dialog with mobile.

Dialog close bug:
I just noticed that it is possible to close the error dialog from top-right corner X. If user does so then Cat-a-lot it will be stuck as no handlers are called. The closing button in right-top corner could be removed or it could just continue similarly than in ignore and continue button.

• Mobile screen**

Visually error dialog worked OK and it was perfectly usable but there could be little padding in left side as now text starts directly from border of the screen.

Howto test different skins

You can simulate Wikimedia Commons mobile view on desktop by changing the skin as "MinervaNeye" ( Preferences -> Appearance ) and narrow the browser window. There is also url parameter useskin=minerva ( https://commons.wikimedia.org/wiki/Special:Search?useskin=minerva ) which switches the skin temporarily.

• Whitespaces**

There could be also as some whitespace tuning just for polishing the code

Whitespaces could be identical with the original so unneeded changes will go away from the diff in these.

• https://commons.wikimedia.org/wiki/User:Ademola01/Gadget-libAPI.js#L-319
• https://commons.wikimedia.org/wiki/User:Ademola01/Gadget-libAPI.js#L-551
• https://commons.wikimedia.org/wiki/User:Ademola01/Gadget-libAPI.js#L-641

Indentation should be the same as in the rest of the code so that the changes can be copied to the official version without having to fix the indentation manually

• https://commons.wikimedia.org/wiki/User:Ademola01/Gadget-libAPI.js#L-545
• https://commons.wikimedia.org/wiki/User:Ademola01/Gadget-libAPI.js#L-634
• https://commons.wikimedia.org/wiki/User:Ademola01/Gadget-libAPI.js#L-777 (ie. isEditingPaused(), pauseEditing(), continueEditing() functions)

Hello @adiba_anjum
I have updated the description for proper testing of the bug
I have made neccesary changes to fix the stop editing button
Looking forward to your feedback

Hello @Zache
I've made neccessary changes and this is ready for to merge
I changed function always() {} to var always = function ()
I removed unneccessary whitespace too
Have also updated T390131 description for proper testing.
Thanks for your guidance!

Alright Noted
I will do that and get back to you
Also can this ticket be added to Outreachy 30: Cat-a-lot javascript gadget development
I would also update T390131
Thanks for the feedback.

In T390242#10713214, @Zache wrote:

Yeah, I think functionality is OK.

Only thing what i would still clean is that in Gadget-libAPI.js diff there is unneeded var always = function () to function always() { change and then in always() function has whitespace changes which are visible in diff.

Removing unnecessary changes from the diff is so that whoever is merging the changes into the production version doesn't have to try to understand by reading the code which changes produce functional changes and which don't.

Hello @Zache
Concerning the code i'm curious and want to know if they have being test and ready to merge
Thank you.

In T390242#10704166, @Zache wrote:

Changing maxSimultaneousReq: 2, to 1 after the error has been happened doesn't effect to two error dialogs because both requests have already been started before the first error has been happened.

If the initial value of maxSimultaneousReq had been 1, then there would have been only 1 dialog as there is no parallel edits. However, we want to make multiple parallel edit requests to achieve a higher editing speed. So multiple dialogs are feature which comes from parallel editing, not a bug.

Thanks to your insight i have specified pauseOnError: true in the setup to enhance the pause running processes behavior. This update enables the system to halt further processes whenever an error occurs, giving users the opportunity to review the problem before making a decision. This guarantees a more controlled workflow and stops unwanted automated operations.
There also has to be a mechanism to resume operations once the user chose to proceed, since pauseOnError halts processing when an error occurs. Based on your feedback continueEditing() to fix this. If an error caused operations to be interrupted, this method determines it and then dequeues the subsequent request to restart execution.

Alright
I appreciate the explanation. Given that logging.wikimedia.org is unconnected, that makes logical.

Thank you for the feedback. I sincerely appreciate you taking the time to look over my edits. I addressed the main concerns about timing, scope, and state management by following the procedure you described. I made sure pausing occurred before always() was called, and added the pauseOnError setting to address these problems. In order to confirm that the system operated as anticipated, I also used a jQuery dialog to test the pause-and-continue capability.

Hello @Neyehh
Great work and nice effort
I tested the integration, and it works well , but there are some UX and functionality issues that need improvement based on my observations.
Issues Found:

1. Dark Mode Compatibility
   • The PetScan interface does not properly adapt to dark mode.
   • Some elements (buttons, input fields, and text) have low contrast, making them hard to read.
2. Bug: Adding Images to a Category
   • Some images do not get correctly processed when added to a category.
   • This might be due to event listeners not binding correctly or metadata missing when passing images from PetScan to Cat-a-lot.
3. Poor UX for Selected Images
   • The visual indicator for selected images is not intuitive.
   • The selection highlight is not clear enough, making it hard to distinguish selected images from unselected ones.(Try using clearer border color).

Inconclusion, i acknowledge your effort in implementing this feature but take note of this feedback and try fixing it, this review are based on this few tests i have done, if i see further changes that need to be made i will let you know.

Hello @Zache
I have implemented a pause/resume editing feature for MediaWiki:Gadget-libAPI.js which now prevent edits from being processed when user interaction encounters an error (i.eprotected page ). Unlike before, edits would continue processing in the background even if an interactive user input dialog was open.

Okay
Great!
I will take note of this
Thank you for the feedback.

Noted.
Thank you for the suggestion.
I'll ensure that sufficient images are available for testing to see what happens efficiently.

Thanks @Zache
I will update the edit request as suggested.
Looking forward to your feedback after confirming the behaviour from UI perspective.

Got it. I’ve started reviewing the implementation details and checking how best to integrate startEditing() and stopEditing() into Gadget-libAPI.js. I’ll update as I make progress.

Hello @Zache
I fixed the error dialog as suggested earlier.
The user can now acknowlegde the error by clicking on the ignore and continue button
I removed the stop editing button and styles.
Here:
Cat-a-lot.js - view diff

Thanks for the breakdown.
I will look into adjusting Gadget-libAPI.js and Cat-a-lot to properly handle pausing edits should be addressed separately,as you've suggested. Let me know if there are specific details i need too pay attention to.

Appreciate the feedback. However, I followed the task exactly as intended. The functionality is working as designed, so if there’s any confusion, a reread of the expected behavior should clarify it. Thanks for sharing your thoughts!

In T390131#10683373, @adiba_anjum wrote:

My only concern is that, at the moment, both buttons seem to lead to the same outcome—protected files remain unedited, while all other files are edited.

I just wanted to share my perspective as a user, as I wasn't aware of the intended functionality. Based on the button labels, I initially interpreted them as follows:

• Ignore and continue: The file causing the error will be ignored, and the rest of the edits will proceed.
• Stop all editing: All edits will be halted.

If the current functionality is correct as intended, perhaps a small adjustment to the button text—such as changing "Stop all editing" to "Stop editing protected files"—could make it clearer?

Just sharing my thoughts! Of course, I’ll leave the decision to you. :)

Hi @Zache
This sounds like an exciting task! I'd love to contribute by integrating PetScan queries into Cat-a-lot for more efficient image categorization. I’ll start by working on the minimal UI, fetching images via PetScan, and ensuring compatibility with Cat-a-lot’s selection system. Looking forward to feedback and collaboration!

Hi, @adiba_anjum
Thanks for testing the code and giving feedback! I appreciate the time taken to test the implementation.

A fix has been proposed in subtask T390131. The issue has been addressed in my user page. Review and feedback are welcome!

Hello @Zache
I have tried to reprodouce the bug again following this process and i couldnt reproduce the bug as everything was working as expect.(i.e )
My previous confirmation and documentation wasn't testing the bug by moving subcategories in the Category:Files uploaded by FinnaUploadBot and selecting following subcategories:

1. Files uploaded by FinnaUploadBot without year category
2. Files uploaded by FinnaUploadBot without street category (sortkey *)
3. Files uploaded by FinnaUploadBot without coordinates (sortkey sortkey)
4. File:"Emil i Lönneberga" Jan Ohlsson 1973 (JOKAMAL3B06-5).tif

Instead i was testing the bug in Wikimedia Commons.
Selected the following files[Media] in the Wikimedia Commons subcategories :

Noted
i will update the code base on your feedback

Bug 1
I was unable to reproduce the bug by following step 1
i cant see the button to add category "Fog in Helsinki" to the photo

@Zache
Thank you for the feedback!

@Gladchux I'm interested in this task and would love to contribute and collaborate with you on it as it is similar to other tasks i have worked on like T386779 and T387979 .

The error handling is in Cat-a-lot.js but not unhandled properly, i fix this issue in the doAPICall( ) that makes the actual API call through mw.libs.commons.api.editPage

Got it! Thank you for the feedback.
I fixed the unhandled error and notification for the error with possibility to ignore it and continue editing.

i have successfully confirmed and replicate the bug by following the procedure in the task.

Got it, thanks for the update! I’ll take a look at the revised ticket and work on adding the necessary error handling. Let me know if there are any specific details or edge cases you’d like me to consider.

I’ve started working on this ticket!
I’m currently looking into replicating the issue. If anyone has suggestions or relevant insights, feel free to share I’m open to collaboration. I’ll provide updates as I make progress.

No, the bug isnt repilcable.

Thanks for the detailed steps! I followed the exact procedure on my end, but I wasn't able to reproduce the bug either. I didn't move the subcategories here in T387979#10644300, i just tested moving files within Wikimedia Commons subcategories, and that’s when I ran into the issue!
It seems the problem might be specific to Commons subcategories. I’ll investigate further and check the JavaScript console for any errors. I’ll also share the detailed process on how i reproduce the bug with moving files to another subcategory.

Thanks for testing it on your end! From your steps, it looks like we followed a similar process, but I still encountered the issue while trying to move subcategories with sort keys.

In T388248#10644077, @FATHIA04 wrote:

Thank you very much @Ademola. much appreciated.

Bug Report: Cat-a-lot Stuck on "Editing page X of Y" When Moving Subcategories
Issue Summary:
Cat-a-lot gets stuck on "Editing page X of Y" when attempting to move subcategories that contain sort keys (e.g., * or any text after |). The issue does not occur when moving images.

Hello everyone! 👋

In T388248#10643309, @FATHIA04 wrote:

Hello Devs 🚀,
I am Fathia Adepoju from Lagos, Nigeria. I am finding it hard to understand what we have to do here. I can see that the task has been struck through. Any help will be greatly appreciated. Thanks.

In T388248#10643089, @SyedBarimanJan wrote:

I think this task is to be completed by everyone individually and recorded as a contribution.

In T388248#10642873, @Nedjwa97 wrote:

hello , i am nedjwa and i started working on this task

Hello Wikimedia community,