@Nat_WDU @Pepe_piton I'd like to pick up this task.

@Pepe_piton I just went through the tasks and I think the standing tasks are taken.
Can I create a tasks to work on?

In T392429#11256302, @Ezra_yendau wrote:

@Pepe_piton I just went through the tasks and I think the standing tasks are taken.
Can I create a tasks to work on?

You can contribute even to the taken ones... no one should claim any tasks.

Hello @dikshya_shahi all tasks should remain open for all contributors to work on.. Assigning tasks to specific individuals may discourage others from participating..

@Pepe_piton @Nat_WDU could you please assign it to me?
i am working on this task.

seems all tasks have already been assigned

Yeah. I have been to this site after creating the accounts but all tasks
seem to be already assigned

@dikshya_shahi @Kimbrene-kakande

Don't worry if you enter a task from the list and you see it says it's assigned to someone else. From now on, all tasks from the list will remain open for all contributors to work on. Anyone can choose the tasks they like best and submit their contribution to that task. You can simply complete the task, submit the merge request, and let the mentors know you did by leaving a comment on the Phabricator task. In summary, from now on, it's okay if more than one person does a task.

Thank you, I will do just that.

Guys my gitlab is saying am pending approval :

Your account is pending approval from your GitLab administrator and hence blocked. Please contact your GitLab administrator if you think this is an error.

Would appreciate it if i am approved. thanks

In T392429#11275681, @Kimbrene-kakande wrote:

Guys my gitlab is saying am pending approval :
Your account is pending approval from your GitLab administrator and hence blocked. Please contact your GitLab administrator if you think this is an error.

Have you linked your LDAP account?
Have you been marked as a trusted contributor by a mentor?

These 2 reasons are why your gitlab is pending approval.

You may need to check the telegram group and tag Jorge or Nat to mark you as a trusted contributor.

If you haven't linked your LDAP, I made a screen recording of how I did mine in the telegram group. I can tag you to it.

Hi @Pepe_piton @Nat_WDU ,
I'm Anjali Dwivedi, interested in contributing to the Paulina project for Outreachy. I'd like to request trusted contributor status to approve the Gitlab account.
LDAP usrename:adwivedii

Hi @Pepe_piton @Nat_WDU ,
I'm Rabo Yusuf, interested in contributing to the Paulina project for Outreachy. I'd like to request trusted contributor status to approve the Gitlab account.
My account details are as follows:
Account name: Rabo Yusuf
Username: rabobahago20

Hey Xup Guys @Pepe_piton && @Nat_WDU . I just created a PR/MR (am a github dude) on the responsiveness of the footer on 2XL screens and when a search returns very few. If you could please look at it. thank you

Bug:

Fix:

Hello, @Raboyusuf2024! you have been added as a trusted contributor

I’ve successfully implemented the Wikimedia OAuth login flow in the Flask application.
This feature enables users to securely authenticate with their Wikimedia accounts and access personalized functionality within the app, the user have the ability to edit author's details.

This is my merge request https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/128

@Nat_WDU could you please look into the MR request i made on footer responsiveness (details like 3 comments up stream). I know your prolly busy thus the reminder. its at https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/98 , if you could please review it for me . Thanks Alot

Hello @Kimbrene-kakande I'm proritizing the review for PRs related to the listed microtasks. Thanks for understanding,

Weekly Internship Report
Week 1: December 8 - December 12

Task 1: Implemented OAuth 1.0a authentication with Wikimedia, including login/logout routes and secure session management.

Task 2: Designed and integrated user authentication UI (login button, user dropdown, contribute banner) matching Paulina's design system.

Task 3: Added rate limiting protection with Flask-Limiter and created comprehensive OAuth setup section in README.md.

2. Key Accomplishments: Successfully completed full OAuth implementation with proper error handling, translatable messages, and config.py configuration for dev/production.

3. Challenges Faced:

Challenge 1: OAuth callback failing due to RequestToken type errors.
Solution: Converted session-stored dicts back to RequestToken objects before completing handshake.

4. Learnings and Skills Gained
   • Gained deep understanding of OAuth 1.0a flow (request token, handshake, access token exchange) and session management in Flask.
   • Learned production-ready patterns: rate limiting strategies, environment-based configuration, internationalization with Flask-Babel, and writing contributor documentation.

5. Feedback and Support Needed:
   • Please review the OAuth implementation PR when possible - I'm ready to address any requested changes.
   • Guidance on Wikidata API best practices for creating items (Phase 2) - any recommended resources or examples would be helpful.

6. Goals for Next Week:

Goal 1: Address PR feedback and get OAuth implementation merged into main branch.
Goal 2: Begin implementing Wikidata item creation functionality (build_author_payload, validators, API integration) once OAuth PR is approved.

Weekly Internship Report

Week 2: December 15 – December 19

Task 1: Implemented the Add Author feature across both frontend and backend, including form structure, field validation, and submission flow.

Task 2: Designed and refined the Add Author form UI, improving usability, clarity of labels, helper text, and alignment with Paulina’s existing design patterns.

Task 3: Began structuring the backend logic for author creation, including preparing the payload format to be sent to the Wikibase REST API and mapping form fields to Wikidata properties.

Key Accomplishments:
Complete Add Author form on the frontend and laid the foundation for backend integration with Wikidata, ensuring the form is ready to submit structured, validated data once the API payload logic is finalized.

Challenges Faced:
Challenge 1: Determining the correct mapping between form fields and Wikidata properties while keeping the UI intuitive.
Solution: Reviewed Wikidata data modeling patterns for human items (Q5) and aligned form fields with expected property structures, leaving room for future validation and references.

Learnings and Skills Gained:

Gained deeper understanding of Wikidata data modeling for authors (items, statements, properties).

Improved skills in designing contributor-friendly forms that balance flexibility with data quality.

Learned how to structure backend payloads incrementally to match the Wikibase REST API expectations.

Feedback and Support Needed:

Feedback on the Add Author form UX and field choices.

Confirmation that the proposed payload structure aligns with Wikidata best practices for creating author items.

Goals for Next Week:
Next week will be a holiday break, but once work resumes, the goal is to begin implementing the Add Work form, following a similar frontend + backend approach and reusing shared validation and payload logic where possible.

Weekly Internship Report

Week 3: December 22 – December 27

Task 1: Conducted research on making authenticated requests to Wikimedia and Wikidata APIs using OAuth, focusing on understanding the OAuth 1.0a flow and REST API requirements.

Task 2: Made minor UI fixes to the Add Author form to improve clarity and usability.

Task 3: Updated required and optional fields on the Add Author form based on earlier discussions with mentors about minimum data requirements and Wikidata best practices.

Key Accomplishments:
Used the holiday period productively to build foundational understanding of OAuth-based authenticated requests and refine the Add Author form in preparation for full implementation work.

Challenges Faced:
No major technical challenges this week due to reduced development activity during the holiday break.

Learnings and Skills Gained
Gained early familiarity with Wikimedia OAuth authentication concepts and how authenticated requests interact with Wikimedia REST APIs.
Improved understanding of Wikidata data requirements and how to balance data quality with contributor experience at the form design level.

Feedback and Support Needed:
None at this stage.

Goals for Next Week:
Goal 1: Resume full development work on the Add Author form, completing both frontend and backend functionality.
Goal 2: Introduce environment-based configuration to safely support testing on test.wikidata.org without impacting production Wikidata.

Weekly Internship Report

Week 4: December 30 – January 5

Task 1: No development tasks were completed this week due to the holiday break.

Key Accomplishments:
No project updates to report this week, as it was a holiday period.

Challenges Faced:
No challenges encountered during this week.

Learnings and Skills Gained
No new technical learnings this week due to the holiday break.

Feedback and Support Needed:
None at this stage.

Goals for Next Week:
Goal 1: Resume active development on January 5.
Goal 2: Continue implementation of the Add Author functionality, focusing on completing the backend logic and Wikidata API integration.

Weekly Internship Report

Week 5: January 5 – January 10

Work Completed:

Improved the Add Author form UX by implementing form data retention on validation errors and clean reset behavior after successful submission.

Introduced environment-based configuration to safely support testing on test.wikidata.org, including separate property ID mappings and configuration files for test and production environments.

Migrated authentication from OAuth 1.0a to OAuth 2.0 by replacing the mwoauth-based implementation with requests-oauthlib, enabling modern authentication flows and automatic token refresh handling.

Key Outcomes:

Better contributor experience through safer form handling, fewer interruptions, and clearer feedback during form submission.

Robust testing infrastructure that prevents accidental edits to production Wikidata by cleanly separating test and production environments.

More secure and future-proof authentication aligned with Wikimedia’s recommended OAuth 2.0 standard.

Challenges & Solutions:

Form state persistence issues:
Solved by explicitly clearing both client-side form data and server-side session data during form resets.

Different property IDs in test vs production:
Addressed by centralizing property ID mappings and switching them dynamically based on environment flags.

API endpoint and authentication flow confusion during OAuth migration:
Resolved by aligning implementation with official Wikibase REST API specifications and adopting requests-oauthlib’s built-in OAuth 2.0 session and token refresh mechanisms.

Skills & Learnings:

Advanced Flask session management for complex form workflows.

Environment-based configuration patterns for multi-deployment systems.

Practical OAuth 2.0 implementation, including access token expiry handling and refresh token workflows.

Designing safer contribution flows for open-source tools interacting with live data platforms.

Feedback Needed:

Review of testing documentation for clarity and completeness.

Validation of test Wikidata property ID mappings.

Review of the Add Author form functionality and OAuth 2.0 integration.

Goals for Next Week:

Complete end-to-end testing of the Add Author feature on test.wikidata.org.

Write contributor documentation covering OAuth setup, environment configuration, and testing workflows.

Begin implementation of the Add Work form.

Weekly Internship Report

Week 6: January 12 – January 16

Work Completed:

• Updated Wikidata edit comments to use Wikitext, allowing comments to link back directly to Paulina for better traceability.
• Updated the README documentation to include instructions for adding the test Wikidata OAuth callback URL.
• Fixed the JavaScript image preview issue, ensuring selected images display correctly before submission.
• Resolved a URL input bug where links without a protocol caused failures:
• Improved placeholder text to clearly request the full URL.
• Added backend validation to automatically prepend http:// when missing.
• Applied the same validation logic to reference URLs.
• Fixed an issue where gender dropdown options were not repopulated after form validation errors by ensuring options are always passed back to the form.

Key Outcomes:

• Improved data quality and reliability by preventing malformed URLs from being submitted.
• More resilient form behavior, reducing user frustration during validation errors.
• Clearer documentation for contributors setting up OAuth testing environments.
• Better edit transparency on Wikidata through linked edit comments.

Challenges & Solutions:

• Broken image preview behavior: Solved by correcting the JavaScript logic handling file input changes.
• Invalid or incomplete URLs causing submission issues: Addressed through a combination of clearer UI guidance and defensive backend validation.
• Form dropdown state loss on validation errors: Resolved by ensuring form option data is consistently passed regardless of validation outcome.

Skills & Learnings:

• Using Wikitext effectively in Wikidata edit comments.
• Defensive backend validation for user-generated input.
• Debugging and improving frontend JavaScript behavior.
• Designing more fault-tolerant Flask form-handling workflows.
• Writing clearer contributor-facing technical documentation.

Feedback Needed:

• Additional testing to confirm all fixes work as expected across different scenarios.
• Review of the updated README section for OAuth test callback clarity.
• Validation of form behavior during edge cases and error states.

Goals for Next Week:

• Address feedback from testing and refine fixes where needed.
• Begin working on Add work form

Weekly Internship Report

Week 7: January 19 – January 23

Work Completed:

• Incorporated mentor feedback from the completed Add Author feature to improve accuracy, usability, and maintainability.

• Refactored the date input system by replacing the built-in HTML date picker with controlled numeric inputs to support Wikidata’s needed date precision rules.
  • Added support for less precise dates, including:
    • Year only (YYYY)
    • Month + year (MM/YYYY)
    • Full date (DD/MM/YYYY)

• Cleaned up the configuration structure by keeping config.py focused on user-provided values and moving non-user global variables into the main app setup for clearer separation of concerns.

• Added keyboard navigation improvements to key components to improve accessibility and make form interactions smoother for contributors.

• Implemented special edge case handling for image submission, including validation and formatting improvements for Wikimedia Commons links to reduce submission errors.

• After completing testing and refinements for Add Author, began implementing the frontend for the Add Work form as the next major feature milestone.

Key Outcomes:

• More accurate handling of Wikidata-compatible dates, including support for partial dates without forcing unnecessary precision.

• Cleaner configuration and app setup structure, improving maintainability and making onboarding easier for new contributors.

• Improved contributor experience through better keyboard navigation and more robust form behavior.

• More reliable image handling through better validation and edge case support for Commons links.

• Smooth transition into the next phase of the project with Add Work form development now underway.
  
  Challenges & Solutions:

• Built-in date picker limitations: The default HTML date input could not support partial dates like “year only” or “month + year.” Solution: Replaced it with numeric inputs and custom validation to fully control accepted formats and precision rules.

• Configuration becoming cluttered: The config file started mixing user inputs and internal app constants, making it harder to reason about. Solution: Refactored by keeping config.py strictly for user-configurable values and relocating global variables into the app initialization layer.

• Image link edge cases: Commons links could vary in format and sometimes failed validation unexpectedly. Solution: Added extra validation logic and formatting safeguards to handle common input patterns more reliably.

Skills & Learnings:

• Designing validation logic for partial date precision that aligns with Wikidata requirements.

• Refactoring Flask configuration patterns for better separation of user settings vs internal app constants.

• Improving accessibility through keyboard navigation support in form components.

• Handling real-world input edge cases with defensive validation strategies.

• Planning feature development incrementally while incorporating feedback without breaking existing functionality.

Feedback Needed:

• Review of the updated date input format and validation rules, especially around partial date support.

• Confirmation that the config cleanup aligns with project preferences and improves contributor setup clarity.

• Testing of the image handling improvements with different Wikimedia Commons link formats.

Goals for Next Week:

• Continue implementing the Add Work form frontend

• Begin building the Add Work backend logic, including payload structure and validation rules.

Weekly Internship Report

Week 8: January 26 – January 30

Work Completed:

• Fixed a bug in the reference handling logic where adding references did not correctly restore or maintain the expected index, leading to inconsistent reference behavior during form interactions.
• Refactored the reference handling flow to ensure indexes are preserved correctly when references are added, removed, or revalidated.
• Continued development of the Add Work form frontend, building reusable components aligned with patterns established in the Add Author feature.
• Began integrating backend logic for the Add Work form, including early payload structuring and validation groundwork for Wikidata-compatible submissions.

Key Outcomes:

• Reliable reference handling with correct index restoration, reducing errors and improving data consistency during submission.
• Steady progress on the Add Work feature, with frontend structure largely in place and backend integration underway.
• Improved overall form stability by addressing a subtle but critical edge case in reference management.

Challenges & Solutions:

Reference index mismatch bug:
The reference list did not restore the correct index after new references were added, causing validation and submission issues.
Solution: Traced the issue to how indexes were being recalculated during state updates and refactored the logic to preserve reference ordering and state consistently.

Balancing frontend progress with backend integration:
Building the UI while simultaneously thinking about backend payload requirements required careful coordination.
Solution: Started backend integration early, allowing frontend decisions to stay aligned with Wikidata payload constraints.

Skills & Learnings:

• Debugging complex state and index management issues in dynamic forms.
• Designing more resilient reference-handling logic for Wikidata-style statements.
• Incrementally integrating frontend and backend logic to reduce rework later in development.
• Thinking ahead about data structure requirements while building user-facing components.

Feedback Needed:

• Review of the reference handling fix to confirm correct behavior across edge cases.
• Early feedback on the Add Work form frontend structure and backend integration approach.

Goals for Next Week:

• Complete the Add Work form backend implementation.
• Perform thorough testing of Add Work form submissions, including references and validation behavior.
• Refine payload structure and error handling based on test results.

Weekly Internship Report

Week 9: February 2 – February 6

Work Completed:

• Completed the Add Work form functionality by finalizing backend implementation and integrating it fully with the frontend components.
• Implemented dynamic form logic that conditionally displays fields based on the selected work type, ensuring contributors only see fields relevant to the entity they are creating.
• Developed and integrated comprehensive validation rules to ensure submitted data aligns with Wikidata schema requirements and maintains data quality standards.
• Successfully implemented end to end functionality that allows contributors to create new works directly from the Paulina interface and submit them to Wikidata.

Key Outcomes:

• Fully functional Add Work feature capable of creating new work entities with structured and validated data.
• Improved contributor experience through dynamic form rendering that reduces cognitive load and prevents overwhelming users with irrelevant fields.
• Stronger data quality assurance through schema aligned validation and structured payload handling.
• Completion of a major milestone in integrating Wikidata editing features into Paulina.

Challenges & Solutions:

Dynamic field rendering complexity:
Different work types required different field combinations, which increased form complexity and validation logic.
Solution: Implemented conditional rendering patterns and modular validation rules that adapt based on selected work type.

Balancing flexibility with schema enforcement:
Allowing optional fields while maintaining Wikidata compatibility required careful validation design.
Solution: Designed validation logic that enforces required schema properties while allowing optional enrichment fields when available.

Backend payload coordination:
Ensuring dynamically generated form inputs correctly mapped to Wikibase REST API payload structures required careful testing and debugging.
Solution: Performed iterative testing using test.wikidata.org to confirm payload accuracy and submission reliability.

Skills & Learnings:

• Building dynamic form architectures that adapt to schema driven data models.
• Designing scalable backend validation systems for multiple entity types.
• Strengthening experience with Wikibase REST API payload structuring and submission workflows.
• Improving end to end feature integration across frontend and backend layers.

Feedback Needed:

Review of Add Work form functionality across different work types.
Validation of dynamic field logic and schema alignment.
Testing feedback on overall contributor experience and form usability.

Goals for Next Week:

• Review and incorporate mentor and community feedback on the Add Work feature.
• Implement required fixes or improvements based on testing results.
• Begin development of editing and missing statement addition functionality for existing entities on Paulina.

Weekly Internship Report

Week 10: February 9 – February 13

Work Completed:

• Incorporated mentor feedback on the Add Work form to refine usability, structure, and overall contributor experience.
• Fixed minor UI inconsistencies to improve layout clarity and form alignment.
• Replaced placeholder images in both Add Author and Add Work forms with Bootstrap icons to create a cleaner and more consistent interface.
• Resolved a bug where changing the selected work type retained previously entered field values, causing incorrect data submission.
• Outlined detailed functional requirements for the Edit Statements feature for both Author and Work entities.
• Began implementing the frontend structure for the Edit Statements functionality.

Key Outcomes:

• Improved form reliability by ensuring field values are cleared when a work type is changed, preventing unintended or invalid submissions.
• Cleaner and more professional UI through consistent use of Bootstrap icons instead of placeholder images.
• Clear functional roadmap for Edit Statements development, reducing ambiguity before deeper implementation.
• Initial frontend foundation established for editing existing statements on both Author and Work pages.

Challenges & Solutions:

Work type state retention bug:
When users selected a work type and later changed it, some previously entered field values were retained and submitted incorrectly.
Solution: Implemented logic to reset and clear dependent fields whenever the work type selection changes, ensuring only relevant data is preserved.

Maintaining UI consistency across forms:
Placeholder images created visual inconsistency and felt temporary.
Solution: Standardized both Add Author and Add Work forms by replacing placeholders with Bootstrap icons for better visual coherence and maintainability.

Defining edit functionality scope:
Editing Wikidata statements introduces complexity around existing values and validation rules.
Solution: Worked with mentors to clearly outline requirements before implementation, ensuring alignment on expected behavior and user flow.

Skills & Learnings:

• Managing dynamic form state transitions to prevent hidden data persistence issues.
• Improving UI consistency using Bootstrap components and icon systems.
• Translating feature discussions into concrete implementation requirements.
• Designing editing workflows for structured knowledge systems like Wikidata.

Feedback Needed:

• Review of field clearing logic when switching work types to confirm correct behavior across edge cases.
• Input on any additional requirements before backend implementation begins.

Goals for Next Week:

• Complete the frontend implementation for Edit Statements functionality.
• Begin and complete backend integration for editing statements on both Author and Work pages.
• Test editing workflows thoroughly.

Weekly Internship Report

Week 11: February 16 – February 20

Work Completed:

• Implemented the inline editing feature for the Author page, allowing contributors to edit existing statements directly within the interface.
• Completed both the frontend components and the corresponding backend endpoint to support inline updates.
• Integrated validation and payload handling to ensure edited statements are submitted correctly to Wikidata.
• Debugged and resolved a QID to label mismatch issue affecting multi value statement rendering.

Key Outcomes:

• Fully functional inline editing system for Author entities.
• Improved contributor workflow by enabling faster and more intuitive statement updates without navigating away from the page.
• Resolved a critical data mapping bug that could have led to incorrect label display and submission inconsistencies.

Challenges & Solutions:

QID and label mismatch bug:
When calling squeries.retrieve_query() to fetch labels for multiple QIDs, the returned results did not always preserve the same order as the QIDs sent in the request. SPARQL queries do not guarantee result ordering unless explicitly specified using ORDER BY. This caused incorrect pairing when labels were zipped together with the original QID list.

Solution:
Instead of relying on array order, I refactored the logic to explicitly map QIDs to labels by first building a dictionary from the query results. Then I reconstructed the label list using the original QID order retrieved from Wikidata. This ensured that each label correctly corresponded to its QID regardless of query return order.

Inline editing state coordination:
Managing editable states, validation, and submission feedback within the same interface required careful frontend state management.
Solution: Structured the inline edit components to isolate editable fields and implemented clear success and error feedback flows tied to backend responses.

Skills & Learnings:

• Understanding SPARQL result behavior and the importance of explicit ordering.
• Designing safer data mapping logic by avoiding reliance on implicit array order.
• Building interactive inline editing workflows that balance usability with structured data constraints.
• Strengthening backend endpoint design for partial statement updates.

Feedback Needed:

• Review of the inline editing user experience and interaction flow.
• Confirmation that the QID to label mapping approach aligns with best practices for handling SPARQL results.
• Testing feedback on multi value statement editing scenarios.

Goals for Next Week:

• Implement feedback for inline editing feature
• Begin implementation of the Add Missing Information feature for Author and Work entities.
• Plan backend support for safely adding new structured statements to existing entities.

Weekly Internship Report

Week 12: February 23 – February 27

Work Completed:

• Completed development of the Add Missing Information feature, implementing both the frontend interface and backend functionality.
• Updated the interface for the feature after mentor feedback so that all missing fields are displayed simultaneously, allowing users to contribute any relevant information in one interaction instead of adding fields one at a time.
• Fixed a bug where form values remained in the input fields after submission, which could cause confusion for users submitting multiple entries.
• Implemented logic to properly clear and reset the form state after successful submissions.
• Began updating the Paulina software documentation to include all newly implemented features from this internship.

Key Outcomes:

• Fully functional Add Missing Information feature, enabling contributors to add structured data that may be missing from Author or Work items.
• Improved contributor experience by allowing users to view and fill multiple missing fields in a single form interaction.
• Enhanced form reliability by ensuring submitted values are cleared, preventing accidental duplicate or incorrect submissions.
• Initial documentation updates started to ensure future contributors can easily understand and maintain the newly integrated features.

Challenges & Solutions:

Single-field interface limitation:
The initial design allowed users to submit only one missing field at a time, which limited usability and slowed down contributions.
Solution: Updated the interface to dynamically display all missing fields, enabling users to select and submit any information they wish to add.

Form values persisting after submission:
After submitting information, the form fields still contained the previously entered values, creating potential confusion.
Solution: Implemented logic to clear and reset form inputs after submission, ensuring a clean state for the next contribution.

Skills & Learnings:

• Designing flexible UI workflows that improve contributor efficiency.
• Managing frontend form state to avoid unintended data persistence.
• Understanding how structured data contribution workflows can be optimized for better user experience.

Feedback Needed:

• Review of the Add Missing Information interface to confirm the multi-field approach aligns with expected contributor workflows.
• Input on whether additional validation or UI adjustments are needed before finalizing the feature.

Goals for Final Week:

• Continue and complete software documentation updates for all newly implemented features in Paulina.
• Perform final testing to ensure stability and reliability across all editing and contribution workflows implemented during the internship.

Please close this task as Resolved if complete. Thanks!