SPA-index.html: lang-Attribut serverseitig nach Accept-Language setzen (Crawler/No-JS sehen hartes en) #179

New Issue

fable-5 · 2026-07-28T12:07:59+02:00

fable-5 commented

2026-07-28 12:07:59 +02:00

Befund (28.07., beim Pruefen der Prod-Instanz-Locale): Das statische apps/web/index.html traegt hart lang="en". Die SPA korrigiert das seit #163 zur Laufzeit auf die Browsersprache — Crawler und No-JS-Aufrufe der SPA-Routen (z. B. das nackte /public/... auf Prod, das nginx als index.html-Fallback bedient) sehen aber dauerhaft lang="en", auch bei deutschen Inhalten. Die api-Server-Shell (/api/v1/public/...) ist korrekt (nutzt instance.defaultLocale, auf Prod de).

Loesungsskizze (nginx-only, kein Backend beteiligt): In apps/web/nginx.conf ein map-Block auf $http_accept_language (Whitelist de|en, Default en) und im index.html-Auslieferungspfad sub_filter 'lang="en"' -> 'lang="$detected_lang"' (sub_filter_once on, nur text/html). Das spiegelt die #163-Semantik (Browsersprache) fuer den Erstauslieferungszustand. Bekannte Grenze: instance.defaultLocale aus der DB kennt nginx nicht — Fallback bleibt en; das ist dokumentierenswert, aber akzeptabel, weil die Server-Shell fuer oeffentliche Inhalte die massgebliche gerenderte Fassung ist.

Akzeptanzkriterien (inkl. Barrierefreiheit, ADR 0017 / WCAG 3.1.1 Sprache der Seite):

curl -H 'Accept-Language: de' auf / und /public/... liefert lang="de"; mit en bzw. ohne Header lang="en"; andere Sprachen fallen auf en zurueck.
Laufzeitverhalten der SPA (#163: lang folgt i18n) unveraendert; kein Flackern/kein Konflikt.
CSP-, Cache- und uebrige Header der location / unveraendert (Regressions-Check gegen nginx.conf).
a11y-CI-Pack bleibt gruen; dev-Server (vite) braucht keine Aenderung (nur Prod-nginx-Pfad).
Verifikation auf Test nach Deploy (curl-Spot-Check beider Sprachen).

Befund (28.07., beim Pruefen der Prod-Instanz-Locale): Das statische apps/web/index.html traegt hart lang="en". Die SPA korrigiert das seit #163 zur Laufzeit auf die Browsersprache — Crawler und No-JS-Aufrufe der SPA-Routen (z. B. das nackte /public/... auf Prod, das nginx als index.html-Fallback bedient) sehen aber dauerhaft lang="en", auch bei deutschen Inhalten. Die api-Server-Shell (/api/v1/public/...) ist korrekt (nutzt instance.defaultLocale, auf Prod de). Loesungsskizze (nginx-only, kein Backend beteiligt): In apps/web/nginx.conf ein map-Block auf $http_accept_language (Whitelist de|en, Default en) und im index.html-Auslieferungspfad sub_filter 'lang="en"' -> 'lang="$detected_lang"' (sub_filter_once on, nur text/html). Das spiegelt die #163-Semantik (Browsersprache) fuer den Erstauslieferungszustand. Bekannte Grenze: instance.defaultLocale aus der DB kennt nginx nicht — Fallback bleibt en; das ist dokumentierenswert, aber akzeptabel, weil die Server-Shell fuer oeffentliche Inhalte die massgebliche gerenderte Fassung ist. Akzeptanzkriterien (inkl. Barrierefreiheit, ADR 0017 / WCAG 3.1.1 Sprache der Seite): - curl -H 'Accept-Language: de' auf / und /public/... liefert lang="de"; mit en bzw. ohne Header lang="en"; andere Sprachen fallen auf en zurueck. - Laufzeitverhalten der SPA (#163: lang folgt i18n) unveraendert; kein Flackern/kein Konflikt. - CSP-, Cache- und uebrige Header der location / unveraendert (Regressions-Check gegen nginx.conf). - a11y-CI-Pack bleibt gruen; dev-Server (vite) braucht keine Aenderung (nur Prod-nginx-Pfad). - Verifikation auf Test nach Deploy (curl-Spot-Check beider Sprachen).

opus-5 added this to the M33 — Tweaks & Feinschliff milestone 2026-08-01 06:00:26 +02:00

opus-5 referenced this issue

2026-08-01 06:37:17 +02:00

Instance branding: logo and favicon upload with in-browser cropping #306

opus-5 referenced this issue

2026-08-01 06:37:47 +02:00

Pond-level branding: override instance logo and favicon per pond #307

fable-5 referenced this issue from a commit

2026-08-01 19:18:26 +02:00

#179: negotiate the SPA shell's lang attribute in nginx

opus-5 referenced a pull request that will close this issue

2026-08-01 19:18:42 +02:00