bbovenzi commented on code in PR #68258:
URL: https://github.com/apache/airflow/pull/68258#discussion_r3381742092
##########
airflow-core/src/airflow/ui/src/i18n/config.ts:
##########
@@ -63,6 +63,64 @@ const baseHref = document.querySelector("head >
base")?.getAttribute("href") ??
const baseUrl = new URL(baseHref, globalThis.location.origin);
const basePath = new URL(baseUrl).pathname.replace(/\/$/u, "");
+const supportedCodes: Array<string> = supportedLanguages.map((lang) =>
lang.code);
+
+// i18next resolves navigator.languages with two global passes: it only reduces
+// a region code ("en-GB") to its base ("en") when NO exact match exists
anywhere
+// in the list. So a browser list like ["en-GB", "hi-IN", "hi", "en-US", "en"]
+// matched the exact "hi" before "en-GB" was ever reduced to "en", and the UI
+// loaded in Hindi. The detector maps this function over each
navigator.languages
+// entry (preserving order), so normalising per code makes the base-language
+// match happen in priority order. Preferred over nonExplicitSupportedLngs /
+// load:"languageOnly", which strip the region from every code and so collapse
+// "zh-CN"/"zh-TW" to the unsupported "zh".
+export const convertDetectedLanguage = (lng: string): string => {
Review Comment:
I feel like we should use `Intl.Locale` instead of manually parsing the
string ourselves.
--
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]
