Custom translation overrides

[lache-melvin]

Is your feature request related to a problem? Please describe 👀

A way for users to configure custom translations on the OMS central server.

The user should be able to:

• Override existing translation strings
• Add new translation keys, e.g. for use in custom JSON form schemas

Describe the solution you'd like 🎁

• Only on OMS Central
• Server admin only
• Always serve custom.json along with common.json (would be empty object by default)
• useTranslation hook adds the custom.json namespace overrides
• Somewhere in the UI - server settings, add a text box to copy and paste the custom.json object
  • Simple validation - valid JSON object
  • Write this data - new table? Columns: id, language, data
  • Custom endpoint, to serve the custom.json
  • Sync to remote sites
• Add query to this table from the reports translation method

QUESTIONS:

• Do we need to support custom translations for multiple languages? Probably more complete if we do

Describe alternatives you've considered 💭

• Key value store?
• Custom translations override all languages, as opposed to per language
• Translation editor - with more feedback about available translations, changes to common.json translations, keys that have inputs e.g. {{ count }}

Additional context 💌

Moneyworks Jobcode 🧰

[roxy-dao]

TODO: Check with report JSON form translations to make sure we're not doubling up on any work etc

[mark-prins]

Always serve custom.json along with common.json (would be empty object by default)

to clarify: custom.json would be empty by default, right? The proximity made me think the brackets relate to common.json

[mark-prins]

Alternatively - the server combines custom.json and common.json and serves up a single file. This would be easier to code for on the front end as no change would be required. If we have two files then we need to either combine the json files (during the i18n initialisation? ) or modify the useTranslation hook to always use the custom namespace while using common as the default or ..?

Do we need to support custom translations for multiple languages?

that would be more comprehensive as a solution, so I'd prefer to support that. In practice though - countries have only used a single language and would therefore only require a single language in the custom namespace. So we're adding complexity which would be unused.

[lache-melvin]

modify the useTranslation hook to always use the custom namespace while using common as the default

Yeah that was the thinking... just seeing as the useTranslation hook already has the "merging" functionality baked in, why not make the most of it! Not sure if that's a little safer too, keeping common.json separate so we know the fallbacks are definitely available?

Though yes, combining on the server is also a nice solution, and could be shared by both frontend and backend (for reports) 👀