Add i18n

[c0de4j0y]

• [x] I have searched the issues of this repository and believe that this is not a duplicate.

Summary

Currently there is no way to use any other than English language on the UI/backend. So simply saying the idea is to add i18n to the application server.

What is the use-case?

Not sure what else could be added here in sense of use-case.

Implementation description

General idea is to obtain an ability to add new locale by adding a file containing translations for that locale. Also, for both UI and backend English will be preserved as the default and used as the fallback language. Locale is a server-wide setting. UI will download and apply translations from server in accordance to server's locale setting.

Backend updates:

• Update chirpstack-application-server.toml to add server locale setting.
• Add the locale from chirpstack-application-server.toml to one of the server responses (possibly, new one). This requires an update of Chirpstack API also.
• By using go-i18n package update backend messages with i18n where applicable.
• Organize storage for locale files.
• Update related Makefile sections.

UI updates:

• By using react-intl/formatjs package update UI components to use i18n.
• Update UI build process by switching to CRACO from CRA because implicit generation of messages ids requires installation/configuration of additional babel plugin. Anyway, switching shouldn't be that hard and shouldn't break anything in current UI build process.
• Organize storage for locale files.
• Update related Makefile sections.

Can you implement this by yourself and make a pull request?

After some discussions (if required), yes.

[brocaar]

If we decide on implementing i18n, then this would add a lot of additional work as on every new or changed message, we need to update the translations, or else the result would be a half translated interface which I think is worse than just an interface in EN. Personally I'm not sure if this additional work is worth it. In most commercial setups, ChirpStack is usually embedded within a different platform, and thus never exposed to the end-user.

[c0de4j0y]

On one hand it's very common for open source projects to have some localization gaps till the moment the projects are being supported by commercial organizations or localization becomes a strong requirement. It's open source. On other hand there is a lot of open source projects that are localized and localized well. It depends on many factors including projects' nature and popularity. If we would talk about the setup where ChirpStack App Server resides behind some other system it should not be an issue either to have some non-localized UI elements or UI in default language. As an opposite, if ChirpStack App Server is exposed to end user more likely localization will be fixed rather than used in half translated form. So it feels like an ability to have localization looks a bit better than the absence of that ability.