Thank you @Arcstur for the feedback. Here are the changes made:

I would like to inform you that I have updated the README and improved code readability after the deadline. Kindly consider these changes.

In T418284#11788072, @Adwivedii wrote:

One thing worth thinking about is that each type of identifier needs its own cleaning before comparing. For example, https://doi.org/10.1100/abc and 10.1100/abc are the same DOI, and 978-3-16-148410-0 and 9783161484100 are the same ISBN, just written differently. So the checker needs to clean and normalize each type separately before deciding whether two references are duplicates or not.

A trickier situation is when different identifier types refer to the same source, such as a URL and a DOI for the same article. Simple cleaning and normalization will not detect this due to different formats. Handling this would need some external lookup to see what each identifier actually points to. I'm curious whether this (cross-type matching) is in scope for first version or whether same-type matching is the right starting point. Would be better to confirm with the mentors @Arcstur @Ederporto .

Another edge case I am thinking about is when some references on a Wikipedia page are not added through the Visual Editor. They may be written directly in the wikitext or added through scripts. If the checker only analyzes references processed by Visual Editor, it might miss duplicates. Should the checker rely only on what the Visual Editor detects, or should it analyze the full page wikitext? Would love to know how you are thinking about this @Arcstur @Ederporto.

Also, once a duplicate is detected, what should happen next? Should it work like Visual Editor's existing named reference feature, where it shows the user the existing reference and asks if they want to reuse it?

One thing worth thinking about is that each type of identifier needs its own cleaning before comparing. For example, https://doi.org/10.1100/abc and 10.1100/abc are the same DOI, and 978-3-16-148410-0 and 9783161484100 are the same ISBN, just written differently. So the checker needs to clean and normalize each type separately before deciding whether two references are duplicates.

Hello @Arcstur , @Ederporto and my fellow contributors,

In T418286#11783459, @Sania231 wrote:

I liked figuring out how to handle the dead links without crashing the script. I'm assuming this kind of URL handling logic is similar to what we'll need for Wishlist #3 when the Visual Editor checks if a reference URL has already been used in an article... Looking forward to the next steps.

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

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

Kindly review my MR for this task: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/155

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.

I have created my version of this task, which can be seen at this link: https://gitlab.wikimedia.org/toolforge-repos/paulina/-/merge_requests/137

I've submitted my first contribution - a new page as mentioned in the task. Would appreciate your feedback!

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