I read through my task feedback, and it was such a great reality check. I used to think writing tons of comments made me a better coder, but the mentor reminded me that good code should just speak for itself.
I also learned a lot about tunnel vision and over-engineering. On Task 1, I was so focused on fixing a timezone bug that I hardcoded the month names, completely missing that using Intl.DateTimeFormat would solve both the bug and localization at once. And on Task 2, I built a GET fallback for 403 HEAD errors, not realizing that servers blocking HEAD almost always block GET too. It was a great reminder to truly understand how protocols work in the real world instead of just writing complex workarounds.
I have submitted the final application:)

Hi @Arcstur For Wish #3, are there any specific files or GitHub repos you'd recommend to understand how it is structured?

In T418286#11785359, @Adwivedii wrote:

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.

You make a good point, the URL handling we built, is related to what Wishlist #3 needs.
But duplicate detection is trickier than just comparing URLs, because different identifiers, (DOI, URL, ISBN ) can point to the same source.

For cases where the same identifier type is used twice (like two DOIs written in slightly different formats), simple cleaning and normalization can catch the duplicates. But when two or more different types of identifiers points to same source, normalization isn't sufficient. We'd need to know what each one actually points to before we can call them duplicates.

So I think the approach for Wishlist#3 would need to work in layers, first normalize within each identifier type (DOI, ISBN, URL each have their own cleaning rules), then handle cross-type matching.
Would be better to confirm with the mentor how far the cross-type matching needs to be handled.

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.

I have just completed task 2. i recommend running your script against the full csv before submitting..because some URLs behave in unexpected ways and it's worth seeing how your code handles them

I have completed task 1 and now i will proceed to task 2. I was reading about the wishlist and wish #8 really stood out to me. Right now if someone edits Wikidata during a contest, those edits just don't count in Wikiscore so their work basically goes unrecognized. That seems like such a fixable problem and fixing it would actually motivate more people to contribute structured data. i am really excited to work on something like this.

In T418285#11733584, @Arcstur wrote:

Hi @KimFarida and @Sania231, all Outreachy applicants can submit both tasks. There is no need to assign them here on Phabricator. Hi @Deeksha_09, thanks for sharing! Best regards to all of you.

All the applicants can submit these tasks or only the assigned applicants? Could you please clarify this? @Arcstur @Ederporto