Open c0de4j0y opened 2 years ago
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.
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.
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:
chirpstack-application-server.toml
to add server locale setting.chirpstack-application-server.toml
to one of the server responses (possibly, new one). This requires an update of Chirpstack API also.go-i18n
package update backend messages with i18n where applicable.Makefile
sections.UI updates:
react-intl/formatjs
package update UI components to use i18n.Makefile
sections.Can you implement this by yourself and make a pull request?
After some discussions (if required), yes.