Classic298 d603b57995 fix: FireFox regional setting (#30377) ... * fix: keep en-US as the last i18n fallback when a stored locale has no bundle Settings labels rendered as raw keys such as settings.admin.connections.title instead of "Connections" from the second page load on, while every other label looked fine. On the first visit the language detector saves whatever the browser reports into localStorage, including bare codes like "en" that have no locale bundle. The same value is saved by ?lang=en or DEFAULT_LOCALE=en. On the next load that stored value became the only fallback language, so the missing bundle left nothing to fall back to. Plain keys still looked right because the key is the English text; only the settings.* keys have a distinct value. en-US now stays at the end of the fallback list whenever a stored locale is passed in. The stored locale keeps precedence, real locales are unaffected, and the en-US bundle was already loaded for every language for the settings merge, so there is no extra request. Fixes #30348 * fix: match browser language codes to a locale bundle Firefox reports German, Dutch and Polish as bare codes (de, nl, pl), both Chrome and Firefox report Japanese as ja, and Chrome in Latin America reports es-419. No bundle is keyed by any of these. The page layout used to match them on the first visit, but since 67ac1a4e9 (0.11.4) awaits the i18n init, the detector has already cached the raw code by the time that check runs, so it never does. Those users get an English interface, a language dropdown with nothing selected and English date formats, and the cached code keeps them there. The detector now maps a reported code onto a bundle before anything else sees it. A code we ship stays as it is, matched case-insensitively. Otherwise the language's xx-XX bundle is used when there is one, so de and de-AT become de-DE, es-419 becomes es-ES, and fr becomes fr-FR even though fr-CA comes first in the list. A bare code with no xx-XX bundle takes the first one for its language, so ja becomes ja-JP. Any other regional code passes through untouched, so zh-HK is not sent to Simplified zh-CN, and no locale that works today changes. Restoring the layout check would leave every browser that cached a raw code under 0.11.4 stuck. Matching in the detector migrates them on their next load, because the matched code is what gets cached. {{USER_LANGUAGE}} reports that matched code too, so es-419 users now send es-ES. Verified against the real bundles on first and repeat loads, including the untouched cases fr-CA, pt-BR, zh-TW, zh-HK, ar-BH, en-GB and uz-Latn-UZ.		2026-09-22 16:46:58 -04:00
..
lib	fix: FireFox regional setting (#30377)	2026-09-22 16:46:58 -04:00
routes	fix: emit the resolved file path in terminal file events (#30282)	2026-09-21 00:31:14 -04:00
app.css	refac	2026-09-10 19:05:36 -04:00
app.d.ts	chat feature added	2023-10-08 15:38:42 -07:00
app.html	refac	2026-07-27 19:39:36 -04:00
tailwind.css	chore: format	2026-08-31 10:48:28 -04:00