In T405412#11336032, @Pepe_piton wrote:

@Sopzy You did a great job implementing everything we asked for in a very straightforward way. Perhaps the only thing missing is the ability to exit editing without saving, but that''s something I didn't explicitly ask for.

In T406949#11335865, @Pepe_piton wrote:

@Afanyulionel @Sopzy Excellent work. You catched the logic of the task.

@Dipanshu1223 You also did a good job, but it seems to me that when you added the work_inception_date field to the HTML template, you inadvertently removed the work_language field.

This really helped me get a much clearer understanding of the property codes and 'Q' item identifiers

In T406949#11264837, @Pepe_piton wrote:

@Sopzy Hi! Good questions.

Can both publication date and inception date appear on the same work’s page?

Generally not. But there is another microtask for addressing this issue: T406994

Do we have a comprehensive list of work types?

Not yet. We only have a very basic filter for searching by type of work, that you can find in filters.py, and it's not comprehensive. But that's because, currently, for Paulina, a "work" is just any item that has one or more of the properties in the dictionary keys_for_types_of_author. The logic is that if an item has any kind of author, it's a work. Anyway, I think that with task T406994, it won't be necessary to map each type of work with their corresponding property (inception or publication date). Just by showing the property only when it is present should be enough.

In T407385#11304937, @Pepe_piton wrote:

@System625 Perfect! And thanks for detecting and coding a fix for the JavaScript errors!

@shreya-bhagat @Blegodwin @Atlas0007 @Raboyusuf2024 Excellent!

@Sopzy Excellent. And what you did with Flask-Babel to get the translations was impeccable.

@Afanyulionel Now it's all right. Nice page!

I'd appreciate your feedback on this task.

In T406989#11283609, @Pepe_piton wrote:

Hi!

@Oluwatumininu.m Great work, I really like your solution! It works just as expected. I like that you also included code to hide the button when all fields are complete. Congrats!

@NinaTakang You also did a very good job. May be the only minor detail is that when an author has all the fields complete, the "add information button" is hidden but the surrounding card borders are shown. Look for example what happens with Louis Armstrong: /author/Q1779

@System625 Thanks for your contribution! The only problem I see, at least on my local environment, is that the "Choose a field" box is already shown before the user clicks on the "Add information" button, so the button has no real use.

@Sopzy I'm sorry I didn't see your question before. It's a good question. Ideally, the "Add information" button should not appear when all fields are filled out. You solved the problem very well by adding the text "All available fields are already complete" in cases where all the information is there. One detail is that the author page has a field that is hidden if not explicitly stated: "ethnicity." It would be nice to add this field to the logic for the "Add information" button.
Finally, I found the code added to app.py interesting, and I understand its use, but I think that, since all the necessary variables were already passed to the template, the missing fields could be directly inferred with JavaScript.

@Nurah_Wakili Good work! And sorry I didn't answer your question before. A field should not be present in the select box if it is not missing in the page. That's because we are thinking about a different approach to edit existing values (see T405412). This feature is planned with the "Add information" button and not with the pencil icon because in the future, all the fields with empty values will be hidden (see T406909).
The feature works very well, except that, at least in my local environment, the dates feature didn't work: when I selected "date of birth" or "date of death", the input box didn't change to <input type="date">, and it didn't recognize any value as a date, so the Publish button never activated. Anyway, the idea of recognizing dates is super useful, thanks for thinking about that!

I'll continue commenting on the rest of the MRs in the coming days. Thanks for your contributions!

In T397554#11288085, @Sopzy wrote:

In T397554#11269589, @Nat_WDU wrote:

Hello @Sopzy, @Oluwatumininu.m and @Dipanshu1223 , the three of you managed to make a good working implementation of this, congrats!

@Dipanshu1223 I really like that your implementation is so simple! However, the query is not formatted, so the user ends up seeing a query all in one line, which is hard to read

Also, I think its better for the links’ wording to read “View this query at the Wikidata Query Service” since WQS is not a familiar term for all Paulina’s users

This task is still open if you want to submit improvements for your MRs, and for new applicants to submit their own. Thankseveryone!

@Nat_WDU Thank you for this feedback.

I'll update the hyperlink text to show "View this query at Wikidata Query Service"

Kindly review my attempt at this task: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/138

I'd appreciate your feedback on this: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/132

In T399974#11288618, @Oluwatumininu.m wrote:

In T399974#11288599, @Miiswom wrote:

Ok! Thank you @Oluwatumininu.m ! I understand better now what was happening.

Anytime 🙌🙌

In T399974#11287925, @Miiswom wrote:

Hi everyone!

Really glad to be sending a Merge Request for this task.
Phew, it has been a real struggle to make pagination work and look somewhat nice ^^

I had to:

• Understand how to add query parameters to the URL
• Implement a correct formula to offset the results by 10
• Not to use plural at all in my variables (if you know, you know :D)
• Making sure that all the variables from app.py are being returned so I can use them in results.html

Looking forward to your feedback and comments: @Pepe_piton and @Nat_WDU

Edit: I also wanted to share with you an error that I've had coming up multiple times from the updateDropdown function inside the <script> tag in layout.hml (see picture attached).
It came up multiple times while I was trying to implement the pagination, even though I was only working on app.py and results.html files.

I am not sure what the issue was, but I guess it was due to the empty value of dropdown.innerHTML or possibly an incorrect URL I was sending...

Error message :

Has anyone encountered this error?

In T399974#11286195, @Afanyulionel wrote:

In T399974#11286184, @Sopzy wrote:

@Pepe_piton @Nat_WDU

I took my time working on this task. Initially, I planned to implement the pagination logic directly in the main SPARQL query. However, I realized that the results are fetched from the Wikidata API (wikidata.org), so I implemented it using a utility function instead.

• I have a utility function for the pagination logic
• I added pagination controls as well as a "Go to page" button, which allows direct navigation to any page to the markups
• When navigating search/works-list pages, the filters (e.g language) persist across those pages.
• I considered using AJAX to update only the HTML content without reloading the entire page when switching pages of a search/works-list page. I'd love to hear your thoughts on that approach.

Here's my PR: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/120. I'd really love your feedback

Thanks!

Nice one @Sopzy

In T397554#11269589, @Nat_WDU wrote:

Hello @Sopzy, @Oluwatumininu.m and @Dipanshu1223 , the three of you managed to make a good working implementation of this, congrats!

@Dipanshu1223 I really like that your implementation is so simple! However, the query is not formatted, so the user ends up seeing a query all in one line, which is hard to read

Also, I think its better for the links’ wording to read “View this query at the Wikidata Query Service” since WQS is not a familiar term for all Paulina’s users

This task is still open if you want to submit improvements for your MRs, and for new applicants to submit their own. Thankseveryone!

I took my time working on this task. Initially, I planned to implement the pagination logic directly in the main SPARQL query. However, I realized that the results are fetched from the Wikidata API (wikidata.org), so I implemented it using a utility function instead.

Thank you for this clarification @Pepe_piton

Here's link to my merge request https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/42

Just for clarification: In a case where all the fields have corresponding values, should there still be an "Add information" button? @Pepe_piton

I'd love to work on this. Thanks

I've been looking into this task for quite some time now and studying the Paulina codebase to gain some clarity, but I have some questions and I'd appreciate your thoughts on them @Pepe_piton, @Nat_WDU, other mentors and colleagues.

@Pepe_piton @Nat_WDU I'd really love to get a feedback on this PR: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/11

This is the PR link: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/11 @Pepe_piton @Nat_WDU

@Nat_WDU @Pepe_piton I'm done with this task.

@Nat_WDU @Pepe_piton I'd like to work on this task.

Yes, I am

Hi, I'd love to work on this task.