Thanks for the feedback @Pepe_piton . Well noted, will update that as well.

In T407558#11314468, @Pepe_piton wrote:

@Rolalove Good work! Autocomplete works very well. I also liked the way you handled the styles of the autocomplete list! Just a couple of comments. Perhaps it would be better to search in the user's language, using the {{CURRENT_LANGUAGE}} variable instead of "en" in the API call. E. g.: &language={{ CURRENT_LANGUAGE }}&uselang={{ CURRENT_LANGUAGE }}
The other caveat is something I perhaps explained poorly in the instructions: the important thing isn't that the search be restricted to items with P 31, but that they be common P 31 values. For example, literary work (Q7725634) is a type of value that would need to be searched for (it doesn't have P 31 but is a common P 31 value for other items).

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

@Afanyulionel You created a really beautiful form. As for the autocomplete, when I tried it, it didn't work. The response was a HTTP 403 error (forbidden) from the server. The REST API doesn't like the JavaScript request. If an authentication token is not used, it gives this error:

status: {"error":"rest-cross-origin-anon-write","httpCode":403,"httpReason":"Forbidden"}

It's strange because the Wikibase REST API responds successfully to the exact same request when Python requests module is used. My guess is that the problem is a bug in the REST API that, for whatever reason, is taking a read-only request for a write request. I opened a bug report in the REST API workboard: T408441

Meanwhile, I think it will be better to use the Action API.

@System625 I really like your solution! A very interesting feature is that the interface displays the Q ID of the chosen option.

One question: Is there a reason why you created the /api/autocomplete-work-type API proxy? Was it necessary to solve a particular problem? What advantages did you see over calling the Action API directly from JavaScript?

@Dipanshu1223 Good work! I like very much the visual appeal of the form and the way it is organized. I have a similar question to the one above: why did you find it necessary to create the API call proxy in /autocomplete/work-type ?
It's not that it's wrong. It's just that, given that several people have come up with a similar solution, I'm wondering about the benefits this approach might have.

@Raboyusuf2024 Thanks for your contribution! The form works very well. The only detail I see is that this task was meant to assess your understanding of the problem of how to make calls to the Wikidata API for autocompletion, which you didn't do. Anyway, your contribution made me realize that, specifically for the "type of work" field, it might be preferable to provide a predefined list of options, just as you did using the type of work filter options (very well thought out!). But for other fields, such as the work's author(s), it will be necessary to use an autocomplete feature by running Wikidata API calls, since it would be impossible to predefine a complete list of options.

@Olatundeawo Nice! Simple and straightforward.

@Nurah_Wakili Good work! You went one step further and put together a complete form! Autocomplete works very well. I also liked your solution for the image. Maybe for languages dropdown I would have populated it using a different approach, but it works well. As with other participants, I'd like to know the logic behind creating a local proxy for the API calls: /api/search-wikidata-items

@shreya-bhagat Very good! Your form is very well conceived and complete. I liked how you handled the image search. As for the autocomplete using the REST API, please read my previous comment to Afanyulionel.

@Adwivedii Excellent work! A super nice form, and I really loved the preview feature. Autocomplete works very well. The only strange thing I noticed was that keyboard navigation through the autocomplete options didn't work quite right for me. It's a minor detail, though. Congrats!

In T407551#11306224, @Nat_WDU wrote:

Hello, @Afanyulionel let me ask you a tricky question... how would a Paulina user obtain the Wikidata link to a new author? Let me know if you spot why it would not be ok to ask for this field.

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!

In T405604#11300256, @Pepe_piton wrote:

@Aradhya05 Nice work! It works really well. I also liked that you used code like request.args.get('nationality', country_qid) so that, when the URL parameters for countries are present, it also prefills the country filters. Actually, Paulina still needs some polish to make all the search filters persistent, and this can be a good approach.

@Afanyulionel Your solution works very well too! And it is straightforward. The only thing I didn't understand was whether there is a need to create the country_name_for_search variable in app.py when the country_name variable already exists, which contains the same information. But that's just a side note.

@Miiswom Good work. Simple and effective. As with Dipanshu, I like your idea of focusing on the country.html template. I think since you are working on that template, which only loads when the URL includes the string /country/, there is no need to add the conditional if(location.href.includes("/country/Q"))

@Blegodwin Your contribution works very well too. Very easy to read and straightforward. Congrats!

@Dipanshu1223 It works perfect now.

@Oluwatumininu.m Now I can see the styles well.

In T407385#11300929, @Pepe_piton wrote:

@Oluwatumininu.m @Dipanshu1223 @Nurah_Wakili Perfect!

@Chumzine Very good! And very nice that you added the link on the site menu. One detail: if you set the variable wikidata_link with Jinja directly on the template, you don't need to create and pass the same variable from app.py.

@Rolalove Perfect! Don't worry about the minor changes on the term.html page.

@Adwivedii Thanks for joining. Perfect work!

@Afanyulionel You forgot to create a view function for the new page in app.py. View functions are how you tell Flask to display the corresponding template for a given route. You can see examples for existing pages, such as /about in the app.py file itself.

In the next few days I will leave feedback to the rest of the contributions.

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!

Hello @Pepe_piton, @Nat_WDU here's my output: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/114

Hello @Pepe_piton , @Nat_WDU please check my completed task here: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/113

Hello @Pepe_piton , @Nat_WDU Here's the result of my version of the task: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/112

Hello @Pepe_piton , @Nat_WDU , here's my documentation and example usage : https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/111

Hello @Pepe_piton , @Nat_WDU . Here's my contribution to the task: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/110

Hello @Pepe_piton , @Nat_WDU kindly review my contribution to this task here: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/109

Here's the link to my contribution https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/108

Hello @Pepe_piton , @Nat_WDU here is my contribution to the task. https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/106

Hello @Pepe_piton, this is a great idea, I have gone through the auth details page and also implemented the proof of concept for that and I have created a merge request at https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/103

Hello @Nat_WDU, trust you are well.

In T406994#11270828, @Miiswom wrote:

Good morning everyone,

@Pepe_piton: I have just moved the if statements so that they wrap around the div.detail-item (instead of having them inside the div).

Here my the updated Merge Request link

Best regards,
Farmata.