Closes#7622.
The renderer's `loadLocale()` was strictly a localStorage-or-English
fallback — non-English speakers had to dig into Settings after every
fresh install. This change consults `navigator.languages[0]` (or
`navigator.language` when the ordered list is missing) ONLY when no
stored preference exists, so:
- first visit on a zh-CN browser → UI lands on `zh` immediately
- first visit on an en-US browser → still `en` (regression guard)
- first visit on a kl-GL browser (unsupported) → falls back to `en`
- any second visit (or after the user picked a language in
Settings) → the stored value wins, the browser hint is never
consulted again for that browser profile
Tests (8/8 pass): a node driver loads the real `static/i18n.js`,
mocks `localStorage` and `navigator`, and asserts the language
that `loadLocale()` ultimately passes to `setLocale(lang)`. The
test covers the four core happy/sad paths plus two pinning tests for
the 'stored wins' contract.
`resolveLocale()` already strips the region subtag (zh-CN → zh,
en-US → en, fr-FR → fr), so the `navigator.language` value is
reduced to a key in `LOCALES` without any extra work in this PR.
The fix is strictly additive: `loadLocale()`'s precedence chain
becomes (navigator hint) → (stored) → 'en' on first visit, and
remains (stored) → 'en' on every subsequent visit.
happy5318
b471e7d1b8
