Allow adding translation without build
Currently, we ship with ontime a list of translated strings.
These files are maintained manually in collaboration with users. The process for adding a new string is something like
- copy paste
en.tsinto a new filezulu.ts - translate object values to zulu
- add file to
translationsListinTranslationProvider.tsx - add language to select component in
GeneralPanelForm.tsx - make PR and wait for next release
Feature description
We would like to facilitate that users can maintain their own translations. This means that
- the user does not need to wait for a release
- the user does not need to maintain their own build of the app
- they can leverage this to tweak the wording if needed
Potential caveats
Having the translations in our codebase means that they are always in sync with the code, by extracting them, it is possible that the user provided translations could be out of sync as we add more strings. We could solve this by creating an interface for the translations and keep this up-to-date as the app changes.
Implementation details
We consider this as an advanced features for people who would know their way around the code. While we dont want them to have to wait for a release cycle, or built the app themselves. We feel it is OK to not create a custom build interface for this (at least for now)
Additional context
A possible outcome is that we need that there is no way to achieve this with reasonable cost. In which case, we can still improve the developer documentation for how to add translations based on the steps above
We consider this as an advanced features for people who would know their way around the code. While we dont want them to have to wait for a release cycle, or built the app themselves. We feel it is OK to not create a custom build interface for this (at least for now)
Would having a table with the strings and translations somewhere in settings make sense?
Hi @asharonbaltazar, I think a table is a passable solution. However it commits us to maintain UI to change app internals
We feel it is OK to not create a custom build interface for this (at least for now)
I would prefer looking for a solution that doesnt abstract the dataset, which would likely come at cost of convenience Such solution could also provide a good heuristic on how to let users modify files such as the css override
Closing this as completed and released with Ontime v4