Page MenuHomePhabricator

Proof of concept: add work form, with autocomplete
Open, Needs TriagePublicFeature

Assigned To
None
Authored By
Pepe_piton
Oct 16 2025, 7:49 PM
Referenced Files
F67886680: image.png
Oct 28 2025, 7:13 AM
Restricted File
Oct 23 2025, 8:20 AM
Restricted File
Oct 23 2025, 8:20 AM
Restricted File
Oct 23 2025, 8:20 AM

Description

Feature summary: Create another page, add-work.html, similar to the ones created in T407385 and T407551, this time containing a basic form for creating a new work's item. The form should contain at least the fields "Title," "Description," and "Work type." However, unlike task T407551, the work type input field must implement autocomplete, searching Wikidata in real time for values ​​of the P31 (instance of) property. For implementing autocomplete, you can try the item search endpoints of the Wikibase REST API: https://doc.wikimedia.org/Wikibase/master/js/rest-api/#/item%20search
Another way could be using the wbsearchentities action of the Mediawiki Action API: https://www.wikidata.org/w/api.php

If you discover a better approach, it's also valid. Please note that, whenever possible, we prefer to use the Wikibase REST API for interacting with Wikidata. While it's still under development and lacks several features, it's the most recent API, is undergoing significant development, and is likely more future-proof.

As with T407551, for now there's no need to add an action attribute to the form or make the form submission affect the Paulina website. This is a proof of concept. You just need to create the form and implement the real-time autocomplete for the "Type of work" input field.

Benefits: To make creating Wikidata items through Paulina user-friendly, it is important that the user does not have to enter the Wikidata QID of each statement's value, but can instead start typing the label, leaving Paulina the task of autocompleting and associating the label with a Wikidata QID, similar to what happens when adding or editing statements in Wikidata itself.

Event Timeline

Hello @Nat_WDU @Pepe_piton

I worked on this task, implemented the “Add Work” form with Wikidata autocomplete for the work type field.
The autocomplete filters entities having P31 (instance of) claims and selects the QID when chosen.

Thank you for the review.

Hello @Pepe_piton @Nat_WDU

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 and @Nat_WDU
i made a merge request related this issue:-https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/118
Changes made:

  • Added add-work.html page with form for creating works.
  • Implemented autocomplete for Work Type field.
  • Added form reset functionality.

Please review my work and provide feedback so I can improve.

{F66784635}

{F66784634}

{F66784633}hi @Pepe_piton and @Nat_WDU
I made a merge request related T407558 Feature/add work: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/130
Feature: Add Work Section
Implemented the Add Work feature allowing users to add new work entries.
Fixed the navigation alignment issue for the Add Work tab to match other nav items.
Updated UI components and styles for consistent look and feel.
Included validation and form handling for work input.

I will be waiting for your correction and suggestions if there is any. Thanks.

I’ve submitted a Merge Request for the implementation of the Add Work page.

This feature introduces a simple, responsive form for creating new Work items in Paulina.

What I Implemented:

Created a new add-work.html template extending layout.html.

Added fields for:

Title

Description

Work Type (with real-time autocomplete powered by the Wikidata API).

Used the wbsearchentities endpoint of the MediaWiki Action API for autocomplete.

Added basic form validation, toast notifications, and automatic form reset after validation.

Made the form fully responsive.

My MR: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/134

@Pepe_piton @Nat_WDU apologies for the delay due to holiday weekend in India.

Have completed the task, ready for review! https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/143
thanks!

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

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

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

Hi @Pepe_piton Thanks for raising the question. I've refactored the code to call the Wikidata API directly from JavaScript, removing the proxy endpoint. Why I initially used a proxy: I assumed it was needed to handle CORS restrictions and followed a common backend-for-frontend pattern I've seen in other projects. I also thought it would provide flexibility for future features like caching or rate limiting. After going through your feedback and checking the codebase thoroughly, I realized the Wikidata Action API explicitly supports CORS and is designed for direct browser use. For this proof-of-concept, the proxy added unnecessary complexity without real benefits. The direct approach is simpler, reduces server load, and aligns with how Wikidata's API is intended to be used. Thanks for the feedback, it prompted me to think more critically about the architecture!

This comment was removed by Adwivedii.

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

@Pepe_piton, Thank you so much for the feedback! I’ll work on improving the keyboard navigation part. Could you please share a bit more about the issue? What did you expect to happen when using keyboard navigation, and what actually happened instead?

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

Thank you for your feedback! @Pepe_piton
I created the /autocomplete/work-type API proxy to avoid loading a large predefined list of work types directly in the HTML.
This way, the page loads faster and stays lightweight.
The proxy allows fetching real-time results from Wikidata only when the user types something, which also keeps the form responsive and reduces unnecessary data transfer.

Than

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

Thanks for the feedback @Pepe_piton. I have fixed the issue now and it now sends the request without 403 Issues or CORS.
Output:

image.png (649×908 px, 42 KB)

The Merge request: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/108

I will also take a look at the issue T408441 to see how we can utilize both methods.

Thanks!
Regards,
Lionel A,

@Pepe_piton thanks for the feedback!
Needed some clarifications regarding my PR:

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.

  1. Reading up on MediaWiki Manual CORS, I wonder if this is an intended behaviour? Because when browser JS (origin = user's browser) calls the API without a bearer token, it’s both cross-origin and unauthenticated. while using the same functionality in python module (origin: flask server), there’s no CORS layer at all — it’s a straight network request. while using bearer token with javascript, the request is still cross origin, but authenticated, hence wikidata allows it (I try and understand it in simpler terms: as if authentication with a bearer token overrides the CORS issue). Your thoughts on this?
  1. In the hindsight, I think using bearer token on the client side and making API calls from the client is a bad idea security wise, as it exposes the bearer token to the user. I had earlier added a field to put in the auth token in config.py and imported in in my Jinja template, which I have now subsequently removed.

we prefer to use the Wikibase REST API for interacting with Wikidata

  1. I used the REST API instead of Action API because you stated the above. any particular reason for this: Meanwhile, I think it will be better to use the Action API.? I found the REST API item search is already used here: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/blob/main/pdclasses.py?ref_type=heads#L109, and hence did not the change the REST API to Action API to maintain consistency. If you need me to, I can make changes and use the Action API instead of the REST API.
  1. Finally, I have made the following changes to my PR: Calling REST API from the Python Module (using an API proxy in python /api/wikidata/suggest), and removing the need for a bearer token entirely. I'd also like some feedback on choosing Author for the work (I implemented a tag select functionality) and some clarity as to how we specify the copyright status of the work (for now I implemented a very simple check box - need some clarity on this)

Updated changes: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/143/diffs?commit_id=e7e6261436514f28bca8dcae7179995c7edab044

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

Let me know your thoughts on it!

@Pepe_piton I used the local proxy for the API calls because it's best practice in terms of CORS compliance, performance ( Caching and optimization ), and better security because it hides credentials and validates requests. It also allows for more flexibility when it comes to modification or extending functionality in the future.
I would love to know your recommended approach for implementing the language dropdown. As always, thank you for your time and feedback!

Hi everyone,

@Pepe_piton and @Nat_WDU :

Please find attached my Merge Request for this task.

Best regards,
Farmata.

@Miiswom Good work! The solution you implemented works very well, congrats! I noticed that you implemented the feature using an API proxy, and this gives me the opportunity to make a general comment:

The responses from several of you to my question about the API proxy helped me better understand the problem. Clearly, the REST API and the MediaWiki Action API are applying different policies for unauthenticated and cross-origin requests.

My impression is that there's a bug in the REST API, since the response error for Javascript unauthenticated requests is: "rest-cross-origin-anon-write", which suggests that the API is confusing a read-only request with a write request.

Thanks to your responses and contributions, I now understand that to use the REST API securely, it's best to always make the request from the server (and not the user's browser), using Python, by implementing the API proxy. This isn't necessary for the MediaWiki Action API, due to what we discussed earlier regarding its different CORS policy.

Thinking ahead (this is something I ask you not to do now, but rather something the intern will focus on), when we work on implementing the actual Wikidata item creation and editing feature, it will be necessary to make authenticated write requests, regardless of the API we ultimately decide to use. Therefore, now I understand why the proxy solution is an excellent contribution.

All this is to say that thanks to all of you, I'm learning a lot.

Regarding the specific questions:

@Adwivedii, don't worry, my comment about dropdown keyboard navigation is a very minor detail. It's not important; the feature works super well.

@shreya-bhagat, when implementing the complete form, each field will have its own peculiarities. Just out of curiosity (I'm not asking you to do this now), the author field will need to accept multiple authors (as you have done) but also multiple author types. Regarding the work's public domain status, values for the Wikidata property P 6216 are used. Comparing the Wikidata item for Metropolis with Paulina's page for the same work might give you some clues.

@Adwivedii, don't worry, my comment about dropdown keyboard navigation is a very minor detail. It's not important; the feature works super well.

Okayy!!

But I've already fixed it. You can look at the changes here : https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/155#13cce7fd076299c81b4986166f3d822791c9490e