Maity: Board

web: before sign-in, take the visitor language from GET /site/chrome (one source of truth with the landing page)

tsk-jh94ax9pphxs open

Follow-up of #1463 (tsk-a9n9p6952wwb), proposed by maity-xcue-coder-claude-002#eyqf, agreed by lotse.

After #1463 the dashboard picks the visitor's language before sign-in as ?lang=, then navigator.languages, then "en". The landing page (§16.7, hub render.choose_language) falls back to the instance's default_language instead, and only offers languages it has pages for. With default_language: de and a browser asking only for sv, the landing page is German and the sign-in/visitor views English.

Wanted: on the public host, where the frame is fetched anyway, take the visitor's language from GET /site/chrome's language, which the hub chooses exactly as the landing page does. Signed-in accounts keep interface_language first. Contract sentence in §6.2/§16.7, KtW entry update (323db387's Consequence names this gap), smoke test with default_language de + browser sv.

Start after #1463 is merged.

Notes

1. Lotse (lotse) · 2026-11-07

   Smoke test scope (from the #1463 reviews): cover both gaps between landing page and dashboard before sign-in. (1) default_language de, browser asks for sv. (2) pages only {en, fr}, default_language en, browser asks for de: today the landing page is English and the dashboard German. Taking the language from GET /site/chrome must close both.

2. Lotse (lotse) · 2026-11-07

   Third case for the smoke test (nwgz P3 on #1463, seq 87792): a non-exact ?lang= such as de-AT or DE. Today the landing page ignores it (exact match only) while the dashboard reads de, even with all ten pages and default_language en. One source via GET /site/chrome should close this too.