Accept full URLs any place an identifier can be entered

[tfmorris]

Any place that the user is asked to enter an identifier for which OpenLibrary has a URL template, they should be allowed to paste the full URL and have the identifier extracted from it.

UI Changes:

• Authors
  • Good first candidate because it's already written in Vue
• Editions
  • Identifiers
  • "What work is this an edition of?" field should accept URL. Edit: It already does! :)
• Works
  • IDs blocked by Add UI for adding work IDs #3430
  • The author autocomplete field on the work edit. Edit: It can do this now

Next Steps:

• Setup Author Identifiers component to accept url match patterns (client side only)
• Create a mapping between our identifiers and Wikidata Identifiers (spreadsheet first, then code)
• Setup Wikidata integration to access Properties (currently only pulls QIDs)
• Plan/implement for how we'll load the url match patterns into Identifiers.
  • I would propose we have an endpoint that aggregates them that the edit pages can call on load. But not cached too aggressively so we if people update patterns in Wikidata they get the changes fairly fast.
• Start using url match patterns in Authors, Editions, Works etc.

We should use the URL Match Pattern from Wikidata instead of maintaining it ourselves. See https://www.wikidata.org/wiki/Property:P214 for an example.
If we do that this is blocked by: #8236

[LeadSongDog]

From a UX perspective is makes sense, they copypaste an URL from wherever they find the edition. From antispam and data validation perspectives, it might be best to have a separate way of testing that the target page refers to this edition before any overwrite of existing data.

[RayBB]

@tfmorris @cdrini @mekarpeles
I've updated this this issue is now updated with a plan that someone could take on.

[tfmorris]

@RayBB Thanks, but all the Wikidata stuff adds, in my opinion, unnecessary complexity and undesirable external coupling. The system already has URL templates for the purposes of converting identifiers into clickable links. It should be possible to leverage those for building extraction regexs.

[Freso]

If it can be any help, MusicBrainz has an extensive blob of JavaScript code that is used to auto‐assign types (and so some cleanup) for URLs (MusicBrainz generally stores URLs rather than IDs):
https://github.com/metabrainz/musicbrainz-server/blob/master/root/static/scripts/edit/URLCleanup.js

I know BookBrainz (which does store IDs and not URLs themselves) also has some autodetection, but I am not familiar enough with BookBrainz’s code to know where to find this.