Allow adding translation without build

[cpvalente]

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.ts into a new file zulu.ts
• translate object values to zulu
• add file to translationsList in TranslationProvider.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

[asharonbaltazar]

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?

[cpvalente]

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