i18n - Load translation files from a backend

[bbovenzi]

Description

Right now all of the translation json files are in the UI js bundle at runtime. We should move them to the server and only load the translation currently being used.

The initial PR for i18n left TODO comments for the places we need to change in the UI to handle this.

Use case/motivation

Prevent unnecessary bundle size bloat.

Related issues

No response

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[choo121600]

I'd like to help on this issue. Could you assign it to me? 👀

[bbovenzi]

@choo121600 go for it!

[choo121600]

I'm planning to move the i18n translation files from the UI bundle (airflow-core/src/airflow/ui/src/i18n/locales/{lang}/{ns}.json) to the backend.
I’d like to get input on the best place to put the directory.

For example:

1. api_fastapi/core_api/i18n/locales/{lang}/{ns}.json
2. api_fastapi/common/static/i18n/locales/{lang}/{ns}.json

Or would it be better to manage them as a core Airflow resource like airflow-core/src/airflow/i18n/locales/?
@bbovenzi Do you already have any preferred location in mind?

[potiuk]

Good idea.

[potiuk]

If I also may suggest - should we use yaml maybe instead of json? It's simple enough to fix all the scripting we have, and I Find json in this context overly verbose and prone to errors (especially when you copy lines and there is a dangling comma).

[bbovenzi]

They are just static files so I think option 1 makes sense to me. What do you think @pierrejeambrun ?

[choo121600]

Thanks for the suggestion @potiuk !
I totally agree that yaml is more human-friendly and reduces the risk of syntax errors compared to json, especially when translators manually edit the files.

Currently, the reason we use json is that i18next by default expects translation files in json format on the client side, and loading yaml directly in the browser would require bundling a yaml parser, which would increase the frontend bundle size something we want to avoid for performance reasons.

To get the best of both worlds, I’m considering the following approach:

• Store and maintain translation files in yaml format on the backend (making it easier for contributors to edit and review)
• Serve the translations through an API endpoint that loads yaml files, parses them on the server, and returns json responses
• Let the frontend continue to load translations as JSON via i18next’s standard HTTP backend without extra yaml parsing in the client

This way, we keep the translation source files developer and contributor-friendly with yaml, while preserving frontend performance and compatibility with existing i18next tooling.

Would love to hear your thoughts or concerns on this approach!

[potiuk]

Yep. 100%. I'd do it exactly the same I figured that Json was because of the client side