Claude Opus 5
9fbaeb559b
All checks were successful
`apps/web/index.html` carries a hard `lang="en"`. The app corrects it at runtime (#163), but nginx answers every SPA route with that same file, so a crawler or a no-JS visit — `/public/...` on prod is exactly that — saw `en` for German content, permanently. WCAG 3.1.1 is about the delivered document, not the one JavaScript later fixes. nginx-only, no backend involved: a `map` on `Accept-Language` and a `sub_filter` in the index.html path. Only the FIRST tag decides, which is what "the browser's preferred language" means and mirrors #163 — `de-CH` counts as German, `en-US,de` does not. `Vary: Accept-Language` is new. The response now genuinely depends on a request header, and without it a shared cache could hand one language's copy to the other. Everything else in the location is untouched: same CSP, same `Cache-Control: no-cache`, same `nosniff`. The known limit is documented in the config rather than worked around: nginx cannot read `instance.defaultLocale`, so an unlisted or absent Accept-Language yields `en` even on a German instance. For public content that is not the authoritative rendering anyway — the api's server shell (`/api/v1/public/...`) already renders those with the instance locale. Verified against a real nginx 1.27 (the image the stage runs) with the config mounted as-is: `de-DE,de;q=0.9,en;q=0.8` and `de` yield `lang="de"`; `en-US,en;q=0.9`, `en-US,en;q=0.9,de;q=0.8`, `fr-FR,fr` and a request with no header yield `lang="en"`; an SPA route (`/public/teich/seite`) negotiates the same way; the gzipped response is rewritten too, and a JavaScript asset comes through byte-identical. |
||
|---|---|---|
| .. | ||
| e2e | ||
| public | ||
| src | ||
| Dockerfile | ||
| index.html | ||
| nginx.conf | ||
| package.json | ||
| playwright.config.ts | ||
| tsconfig.json | ||
| vite.config.ts | ||
| vitest.config.ts | ||