kaxil opened a new pull request, #68258: URL: https://github.com/apache/airflow/pull/68258
The web UI auto-detects its display language from the browser. For users whose `navigator.languages` lists a region-qualified primary locale (for example `en-GB`) ahead of other languages, the UI loads in the wrong language. A common case: a UK English browser that also lists Hindi loads the UI in Hindi instead of English. The detected language is cached in `localStorage` (`i18nextLng`), so it persists across reloads until changed manually. My Browser setting as an example: <img width="1480" height="770" alt="image" src="https://github.com/user-attachments/assets/1620ba85-c251-4632-a84f-840018f38675"; /> ## Root cause i18next resolves the detected list with `getBestMatchFromCodes`, which runs two global passes. The first pass selects the first code that is an exact member of `supportedLngs`; only if that finds nothing does the second pass reduce a region code to its base language. `supportedLngs` mixes base codes (`en`) with region codes (`zh-CN`, `zh-TW`), so `en-GB`/`en-US` are not exact matches and get skipped, while a later exact match such as `hi` wins before `en-GB` is ever reduced to `en`. This affects any user whose top browser language is a region variant of a base-supported locale (`en-GB`, `pt-BR`, `de-AT`, ...) followed by another exactly-supported language. It surfaced in 3.1 as the locale set grew to include bare codes like `hi`; the original two-locale set (`en`, `zh_TW`) could not trigger it. ## Fix Add a `convertDetectedLanguage` hook to the detector. i18next maps it over each `navigator.languages` entry in order, before matching, so the base-language reduction happens per code in priority order: - region variant of a supported base language folds to the base (`en-GB` -> `en`) - region-specific supported locales stay exact (`zh-CN`, `zh-TW`) - Chinese without an exact match is routed by script/region subtags (`zh-Hant-TW`/`zh-HK` -> `zh-TW`; `zh`/`zh-Hans` -> `zh-CN`) ## Why this approach `nonExplicitSupportedLngs: true` and `load: "languageOnly"` strip the region from every code, which collapses the supported `zh-CN`/`zh-TW` to the unsupported `zh` and flips Chinese users to English. `convertDetectedLanguage` is the mechanism i18next recommends for a `supportedLngs` that mixes base and region codes ([i18next #2365](https://github.com/i18next/i18next/issues/2365), [#2354](https://github.com/i18next/i18next/issues/2354)), applied at the array layer where the limitation lives ([#2299](https://github.com/i18next/i18next/issues/2299)). The behavior is unchanged through the latest i18next (26.x), so a version bump does not address it. ## Notes - Region variants resolve to the base locale (`en`), so no request is made for nonexistent `en-GB` translation files. - A previously cached wrong language stays until the user changes it or clears `localStorage`; fresh detections resolve correctly. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
