Fix: crash on /books/add check page that prevents selecting matches o…

[dvvrtmshra]

Closes #12974

Technical

add-book.js parsed i18nStrings from form[name=edit]'s data-i18n attribute at module scope, so it ran immediately on import rather than when the module's exported function was called. index.js loads this module on any page with id="addbook" in the DOM — that includes templates/books/check.html (the "possible matches found" page), not just templates/books/add.html. But check.html's form doesn't have a data-i18n attribute, so .dataset.i18n is undefined, and JSON.parse(undefined) threw a SyntaxError before initAddBookImport() could ever run. That meant the click handlers for match-list links and the "Continue" button — which are registered inside initAddBookImport() — never got attached on check.html.

Fix: moved the addBookForm lookup and i18nStrings assignment inside initAddBookImport(), placed after the click-handler registrations. i18nStrings stays declared at module scope (as let, assigned rather than initialized) since validatePublishDate() — a separate function outside initAddBookImport() — also reads from it. This means the click handlers now always get wired up regardless of whether data-i18n is present, while ID-validation/publish-date logic (which only applies on add.html, where the relevant fields exist) is unaffected.

No functional change to add.html's existing behavior.

Testing

1. Go to /books/add and start adding a book likely to have existing matches (e.g. a well-known ISBN or title).
2. Submit the form so the check page (check.html) is shown with potential matches listed.
3. Click on one of the listed matches — confirm it now submits the form and navigates, instead of doing nothing.
4. Repeat from step 1, this time click "Continue" instead of a match — confirm it submits with none-of-these instead of doing nothing.
5. Separately, verify add.html still works unaffected: go to /books/add, enter an ISBN, confirm validation/auto-complete for ISBN/LCCN/OCLC fields still works, and confirm the publish-date-in-future validation still fires correctly on blur.

Screenshot

Stakeholders

@mekarpeles

[openlibrary-bot]

Thanks for the PR, @dvvrtmshra!

@mekarpeles is assigned to this PR and currently has:

• 2 open PR(s) of equal or higher priority to review first

PR triage checklist (maintainers / Richy)

• PR description — not empty; explains what the change does and how to verify it
• References an issue — PR body contains a #NNN reference
  • Linked issue is triaged — has a Priority: * label (not just Needs: Triage)
  • Linked issue is assigned — has at least one assignee
• Commit history clean — no WIP/fixup/conflict noise; commit messages are meaningful
• CI passing — no failing check-runs
• Test cases present — if the change touches substantive logic, test coverage exists or is explained
• Proof of testing — PR body includes a description of what was tested, a screenshot, or a video

Note

This comment was automatically generated by PAM, Open Library's Project AI Manager. PAM provides status visibility, performs basic project management functions, and gives actionable feedback so contributors aren't left waiting.