Feature/implement i18n for Dashboard and SideBar

[RoyLee1224]

Related Issue

#9864
cc: @bbovenzi

Summary

This is the initial phase of internationalization (i18n) for the Dashboard and Navigation (Nav) components.

Changes Made

• Integrated react-i18next to enable translation of static text.
• Enabled automatic language detection and persistence using i18next-browser-languagedetector:
• Enabled caching of the user's selected language directly into localStorage.
• Added translation json files for English (en) and Traditional Chinese (zh-TW) within the relevant i18n namespaces ("common", "dashboard").
• Refactored the affected React components in the Dashboard and Nav sections to utilize the useTranslation hook and the translate() function for rendering localized text.

i18n file structure

i18n/
├── config.ts               
├── locales/
│   ├── en/
│   │   ├── common.json        
│   │   └── dashboard.json     
│   └── zh_TW/
│       ├── common.json        
│       └── dashboard.json     

Screen recording

i18n-demo.mp4

Future Work

This submission represents the first step in internationalizing these UI areas. Several more complex translation tasks are planned for subsequent PRs:

• History: Implementing translations that correctly handle states in Runs and TIs .
• Assets: Adding translations with appropriate pluralization rules for asset counts and related texts.
• Alerts & Labels: Extending translations to other common UI elements like system alerts, form labels, etc.
• Lazy Loading: Implementing lazy loading for translation files (e.g., using i18next-http-backend) to improve initial application load times, especially as more languages are added.

Points for Discussion

As this is an initial step towards comprehensive UI internationalization, I would appreciate community feedback and discussion on the following topics to ensure the approach aligns with project standards and future needs:

• Translation File Format & Structure:
  The current implementation uses JSON files.(Note: i18next-http-backend expects JSON as its default resource format) Are there any preferences or established best practices within the Airflow community for this format, or should alternatives be considered?
• Icon for Language Selection:
  The current "Select Language" icon is same as the "Browse" icon. I'm open to suggestions from the project's available icon sets.
• Specific Terminology Translations:
  For certain domain-specific terms (e.g., "Pool Slots"), arriving at an accurate translation can be challenging. I've made initial translations but would welcome discussion to establish a consensus for such terms. (需要懂繁體中文的人幫忙！)

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[RoyLee1224]

update: enabled translation for states

[pierrejeambrun]

Nice, thanks for the pull request.

Maybe we can introduce i18n for the full application but only in english.

And then in a second different PR the full traduction for chinese ?

This will separate the discussions from introducing an i18n structure in the project vs Specific Terminology Translations for chinese.

I am not super confortable merging a PR that will partially have english and chinese implemented, with places not using i18n at all and other places that do.

Also we might want to check pluralize function. (That will most likely need to be adapted)

[RoyLee1224]

Hi @pierrejeambrun ,

Thanks for your guidance and the clear path forward!

I completely agree that separating the "Terminology Translations for Chinese" into a distinct PR is the best approach.
I also agree with your point that it's better to fully apply the i18n infrastructure before merging other translations.

However, in my opinion, temporarily retaining the "Traditional Chinese" option in the language switcher might be beneficial.

If zh_TW is selected, any text that hasn't correctly wrapped with translate() would fall back to English. This would make it very easy to visually identify which areas are indeed i18n-ready and correctly wired up, as demonstrated in the screen recording.

What are your thoughts on this specific point about retaining the switcher option for review?

Please let me know how you'd like me to proceed regarding the visibility of the zh_TW option.

Thanks!

[bbovenzi]

This is a solid start. Thanks so much for taking this on!

Do we need to manually handle the user's preferred language in localStorage I thought react-i18next already handles that?

We should look into linting tools to detect when we have any hardcoded strings or if a translation file is missing any entries: https://www.npmjs.com/package/eslint-plugin-i18next. We can have them warn for now and switch to error when ready.

I also want to look more into Shopify's formats. They seem to have good pluralization rules: https://github.com/Shopify/i18next-shopify

[bbovenzi]

Actually, I think I'm leaning towards Pierre's side now. I would like to encourage discussion on how to translate Airflow topics separate from the system setup. We can fully test the switching languages in that second PR too. Filling in every spot that's missing will still take time and we can add that linting rule in later too

#protm

[Lee-W]

I can't really help with the frontend side, but I can contribute to the discussion on the translation side

[Lee-W]

@josix I know you have been working on Python translation for a long time and understand Airflow well. Would you be interested in helping on this and the following ones 🙂

[RoyLee1224]

Update: Fully implemented i18n for Nav Bar and dashboard.

i18n-nav-and-home.mp4

[jscheffl]

Very cool! Looking forward to contribute German translation!
Will be a challenge in the future that whenever the UI is extended that all languages are considered later to translate DIFFs... me might need a small tool to check for missing texts to that some native-speaker volunteers can check prior a release if some leftovers require translation. I opt-in for German then... so maybe we need to add some CODEOWNERS here.... once this is merged.

[Lee-W]

Very cool! Looking forward to contribute German translation! Will be a challenge in the future that whenever the UI is extended that all languages are considered later to translate DIFFs... me might need a small tool to check for missing texts to that some native-speaker volunteers can check prior a release if some leftovers require translation. I opt-in for German then... so maybe we need to add some CODEOWNERS here.... once this is merged.

I can help with Mandarin 🙂

[bbovenzi]

Very cool! Looking forward to contribute German translation! Will be a challenge in the future that whenever the UI is extended that all languages are considered later to translate DIFFs... me might need a small tool to check for missing texts to that some native-speaker volunteers can check prior a release if some leftovers require translation. I opt-in for German then... so maybe we need to add some CODEOWNERS here.... once this is merged.

After this PR we should add two linting rules:

• Check if there are any plain text strings in the UI and throw an error
• Check to see if a language is missing a translation string and throw a warning

I also like the idea of CODEOWNERS. Perhaps we should go as far as to make sure someone is willing to be a CODEOWNER to maintain a language before we accept a new one?

[jscheffl]

After this PR we should add two linting rules:

* Check to see if a language is missing a translation string and throw a warning

Mhm, if we have 15 languages and you add some small piece to a screen this would be a blocker if you need to take care for translations prior merge. That would slow-down a lot of UI changes. I assume at least this needs to be satisfied for PRs that are back-ported (in future to 3.1) or before a release is made to close all translation gaps. Ah, but you say "Warning" not a blocking check... this is OK!

I also like the idea of CODEOWNERS. Perhaps we should go as far as to make sure someone is willing to be a CODEOWNER to maintain a language before we accept a new one?

So raise my hand for German.

[choo121600]

If there's anything I can help with translating Korean, I'd love to participate! 🙌

[bbovenzi]

After this PR we should add two linting rules:

* Check to see if a language is missing a translation string and throw a warning

Mhm, if we have 15 languages and you add some small piece to a screen this would be a blocker if you need to take care for translations prior merge. That would slow-down a lot of UI changes. I assume at least this needs to be satisfied for PRs that are back-ported (in future to 3.1) or before a release is made to close all translation gaps. Ah, but you say "Warning" not a blocking check... this is OK!

Yes just a warning, do not block, if a language is missing a translation after we added a new feature.

[bbovenzi]

This looks like a good start to me. Great work!

I made some sub-issues to handle linting and codeowners. After those we can start work on adding more languages