In T409205#11350029, @Pepe_piton wrote:

@Mind_Booster_Noori Thank you for your suggestion about this important feature, and @Oluwatumininu.m @System625 thank you for your contributions! Date of birth and date of death filters are something I've been considering for quite some time, but until now I haven't been able to implement it precisely for performance reasons. Since searches with "haswbstatement" using the Action API don't allow the "date" data type, we have to use SPARQL, which significantly impacts performance. Some weeks ago I left a comment on an old ticket about this, asking for the date data type to be added to haswbstatement: T238498

I'm very interested in studying the solutions you propose. Using date ranges in the SPARQL query, instead of the YEAR function, is highly recommended to save a few seconds, and it's something I already had in mind. But I'd like to take the time to review the details of your solutions and test them in different cases.

The most important case I'm interested in testing is searching for authors leaving the search box blank, applying the nationality filter for a country with many author entries in Wikidata (for example, the United States, France, the UK), and then applying the "year of death" filter. This use case is the one raised in the ticket and I'm sure it's quite common, since many people want to obtain lists of authors from a country rather than searching for specific names of authors. But it's a case where performance can be particularly affected.

I fixed this issue. Kindly have a look to check if I'm on the right track.

In T397963#11339197, @Aklapper wrote:

Hi, everyone please see https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines so PRs get automagically linked in Phabricator tasks (though that page is about Gerrit and not GitLab). Thanks.

@Oluwatumininu.m Thanks, very good contribution! I really liked the work you did giving priority to the autocomplete suggestions that are actually types of works.

Thank you very much for the feedback 🙌

In T407385#11300929, @Pepe_piton wrote:

@Oluwatumininu.m @Dipanshu1223 @Nurah_Wakili Perfect!

Thank you very much for the feedback!

In T405621#11299190, @DidiCoronel wrote:

In T405621#11287742, @Oluwatumininu.m wrote:

In T405621#11284544, @DidiCoronel wrote:

In T405621#11261016, @Oluwatumininu.m wrote:

I discovered a new issue while solving this issue and I have fixed it. I will include the before and after videos whilst creating a new PR.

The "Country of Origin" dropdown type-to-select feature currently matches countries anywhere in the name (e.g., typing "N" shows Afghanistan before Nigeria).

I have improved this behavior so that the filter prioritizes countries that START with the typed letters.

What I did:

1. Found the code responsible for filtering or matching country names in the dropdown.
2. Updated the logic so that countries whose names start with the typed query appear first.
   • Used toLowerCase().startsWith(query.toLowerCase()) to check for prefix matches.
   • Optionally, I still included other matches (that contain the query later), but listed them after the prefix matches.
3. Ensured the alphabetical order of countries remains consistent.
4. Tested that typing "N" now shows countries like "Namibia", "Nepal", "Nigeria" first.

@Oluwatumininu.m, I think this is an improvement for the behavior of the combobox and was able to verify it work as intended. Although I do have a question about the PR, there are two divs with class "combobox-container" added here. Are both actually needed? May have more questions or comments later.

Thank you very much for the feedback!

This was a duplication issue that I missed.

I have removed the duplicate div and made a commit. I'll be expecting more comments and feedback.

Hi @Oluwatumininu.m, I see the <div> is commented out. If it's not actually needed I'd recommend you remove/delete it completely.

In T399974#11288599, @Miiswom wrote:

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

In T399974#11288563, @Miiswom wrote:

@Oluwatumininu.m : Oh that makes sense now! Thank you for this!

If I understand correctly: when my code wasn't right, it will go straight to except: abort(404) and display the 404 error page.
However, because the <script> was still executing and calling the updateDropdown() function, it throws that TypeError because it couldn't find the dropdown in the page.
Is that right?

In T405604#11288023, @Pepe_piton wrote:

@Oluwatumininu.m Good work! The feature works well. The only minor detail is that when the user switches between Author and Work, the country dropdowns have different styles (one with yellow background and the other with white background). As for app.py, the two new variables you created are interchangeable with each other.

My bad!
Thank you so very much for the feedback!

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 T405621#11284544, @DidiCoronel wrote:

In T405621#11261016, @Oluwatumininu.m wrote:

I discovered a new issue while solving this issue and I have fixed it. I will include the before and after videos whilst creating a new PR.

The "Country of Origin" dropdown type-to-select feature currently matches countries anywhere in the name (e.g., typing "N" shows Afghanistan before Nigeria).

I have improved this behavior so that the filter prioritizes countries that START with the typed letters.

What I did:

1. Found the code responsible for filtering or matching country names in the dropdown.
2. Updated the logic so that countries whose names start with the typed query appear first.
   • Used toLowerCase().startsWith(query.toLowerCase()) to check for prefix matches.
   • Optionally, I still included other matches (that contain the query later), but listed them after the prefix matches.
3. Ensured the alphabetical order of countries remains consistent.
4. Tested that typing "N" now shows countries like "Namibia", "Nepal", "Nigeria" first.

@Oluwatumininu.m, I think this is an improvement for the behavior of the combobox and was able to verify it work as intended. Although I do have a question about the PR, there are two divs with class "combobox-container" added here. Are both actually needed? May have more questions or comments later.

@ObediObadiah , @Oluwatumininu.m, @Sandijigs & @Nurah_Wakili
According to your .md you are using an authentication token. Can you better describe how did you get your access token? Either describe it or provide a link to official documentation that explains it. Do the editions appear as done by your username in the Wikidata item’s history?

@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!

@ObediObadiah , @Oluwatumininu.m, @Sandijigs & @Nurah_Wakili
According to your .md you are using an authentication token. Can you better describe how did you get your access token? Either describe it or provide a link to official documentation that explains it. Do the editions appear as done by your username in the Wikidata item’s history?

I have worked on this issue. Here is the link to my MR: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/107
For the Work Type field, I implemented real-time autocomplete using the Wikibase REST API search endpoint — it fetches suggestions from Wikidata as the user types.

Hi @Pepe_piton @Nat_WDU
I have fixed this issue. Also added the add-author route to the app.py file.
Here is the link to my MR: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/104

@Oluwatumininu.m I really liked the addition of css styles. Very nice! The feature works very well. The only minor detail I found is that if the user clicks outside the input box, the interface saves the input. May be it's better to leave the input box editable until the user clicks on the publish button or hits the "Enter" key.

Thank you very much for the feedback.
I have made corrections to the input box. It is editable until the user clicks on the publish button.

I fixed this issue.
Here is the link to my merge request: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/92

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.

I worked on this issue
Here is the link to my MR: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/88

@Oluwatumininu.m I tried your contribution but I couldn't make it work as you provided here: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/48/diffs
I think the error is in the syntax for appending to a list using Jinja. Jinja doesn't generally have a very user-friendly syntax for such things. But this task doesn't actually require you to do list appending. You can use a more minimalist approach, like you used for example in T406909

Thank you very much @Pepe_piton for the feedback. I have now removed the complex list appending mechanism that was causing failures. I also added the "No details available" feature that @Aradhya05 suggested.

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!

In T406950#11269488, @Pepe_piton wrote:

@Oluwatumininu.m Thanks for your contribution! You managed to place the Wikidata link very well. However, with your current solution, the Wikimedia Commons link isn't displayed. This is because the work.html template doesn't receive a variable named "work_commons_link." For a clue on how to resolve this issue, it might be helpful to revisit the task of adding the "inception" field to the work page: T406949

Thank you so much for the feedback! I have made changes and a new commit. Here is the link: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/23/commits

I worked on this issue.
Link to MR: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/71

In T405603#11269238, @Nat_WDU wrote:

Hello, everyone!

@shreya-bhagat & @Oluwatumininu.m
good implementation, good job with the SPARQL query

In T406949#11269232, @Pepe_piton wrote:

@Oluwatumininu.m Thanks for your contribution! I think there are some changes from other tasks included in the MR diff and the commit diff, but I was easy to identify the changes corresponding to this task, so don't worry. You did a good job, finally identifying the necessary changes to the Work class in pdclasses.py, the work route in app.py, and the template. I tried your code and it works fine.

Thank you very much for the feedback. @Pepe_piton

@Oluwatumininu.m
As requested in the ticket description, we’d like to show the wikidata item’s description at the page

@Oluwatumininu.m
good implementation
If you can include the name if the ticket in the name of the PR that’s helpful for us to keep things tidy

Thank you very much for the feedback. I will take note for my next tasks.

In T406909#11266034, @Pepe_piton wrote:

@Oluwatumininu.m, Thanks for your contribution. You catched the essence of the task: adding if statements with Jinja2 in the author.html page. Simple and readable. Congrats!

Hi @Nat_WDU @Pepe_piton
I have fixed this issue.
Now each page shows a proper explanation of the term, pulled straight from the corresponding Wikidata item right under the page title. The style matches the paragraph on the Countries and Terms page for consistency
Here is the link to my merge request: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/64

I fixed this issue.
Here is the link to my MR: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/63

I have fixed this issue.
Here is the link to my merge request: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/62/commits

Hi @Pepe_piton @Nat_WDU
I have completed the proof of concept for editing statements in Paulina. The interface now allows inline editing of fields with pencil and check icons. Please have a look when you can. 😊
Here is the link to my MR: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/54

I have fixed this issue. Here is the link to my MR: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/53

I have fixed this issue. Here is the link to the MR: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/52

I have fixed this issue.
Here is the link to the merge request:
https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/48

Hi @Pepe_piton @Nat_WDU
I have fixed this issue.
Here is the link to my MR: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/35

I fixed my mistakes. Took me a while but I did. It's my first time getting familiar with git and actively writing codes.
https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/22

I have worked on this issue. Here is the link to the MR:
https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/31

Thank you @shreya-bhagat
I was making the mistake of pushing to just one PR.

I have fixed this issue.

Hi @Pepe19294a
I have fixed this issue

I have fixed this issue.
Before:

After implementation

Before implementation{F66740375}

I discovered a new issue while solving this issue and I have fixed it. I will include the before and after videos whilst creating a new PR.

Hi @Pepe_piton @Nat_WDU I have completed the task and made a pull request. Could you help look through?
https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/14

https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/14

I have gone through the “Nationality” filter implementation (Task: T393278) and noticed that the type-to-select functionality is already available in the codebase.