Localize ATS PDF export to the active UI language#108
Merged
Conversation
The ATS PDF export is generated entirely server-side via PDFKit, so its contents didn't pick up the client-side i18n translations that the admin UI already has. Section headings, the "Present" label, the "Technologies:" prefix, the PDF document language tag, and PDF metadata (Title, Subject) all appeared in English regardless of the user's selected language. This change adds a small server-side i18n loader that reads the existing public/shared/i18n/*.json files at startup, and updates /api/export/ats-pdf to translate all user-visible strings using the locale the client sends in the request body (falling back to the stored language setting, then English). The PDF's /Lang metadata also now matches the active locale for screen-reader accessibility. Adds four new keys (ats.technologies_label, ats.pdf_title_suffix, ats.pdf_subject, ats.name_fallback) across all 8 locales, preserving key parity enforced by the frontend tests.
The ATS export regression slipped through because the existing i18n checklist only covered frontend code. Server-generated output (PDFs, file downloads, metadata tags) had no rule, no example, and no test that could catch hardcoded English strings in src/server.js. CLAUDE.md additions: - New "enumerate every string the feature emits" lead-in to the i18n checklist so future features aren't audited only through the frontend lens. - New checklist item #3 covering server-generated output, with a concrete serverT()/resolveLocale() example and a note about setting PDF /Lang metadata for accessibility. - New checklist item #7 making the test expectation explicit: any new server-rendered artifact needs a regression test that compares output across two locales. tests/backend.test.js — new "ATS PDF export localization" describe block with four tests: 1. /Lang metadata matches the requested locale for all 8 supported languages, and the response is a well-formed PDF. 2. EN and DE PDFs differ in content after normalizing /Lang and also differ in byte length. This is the key regression guard — if a future change drops serverT() calls, the two bodies would only differ in the /Lang tag, which this test normalizes away. 3. Unknown locales fall back to English. 4. Requests without a locale still return a valid PDF (server reads the stored language setting or falls back to English). No version bump: per CLAUDE.md, docs-only and test-only changes don't bump versions.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The ATS PDF export is generated entirely server-side via PDFKit, so its
contents didn't pick up the client-side i18n translations that the admin
UI already has. Section headings, the "Present" label, the
"Technologies:" prefix, the PDF document language tag, and PDF metadata
(Title, Subject) all appeared in English regardless of the user's
selected language.
This change adds a small server-side i18n loader that reads the existing
public/shared/i18n/*.json files at startup, and updates /api/export/ats-pdf
to translate all user-visible strings using the locale the client sends
in the request body (falling back to the stored language setting, then
English). The PDF's /Lang metadata also now matches the active locale
for screen-reader accessibility.
Adds four new keys (ats.technologies_label, ats.pdf_title_suffix,
ats.pdf_subject, ats.name_fallback) across all 8 locales, preserving
key parity enforced by the frontend tests.