[web] translation override

[exalate-issue-sync]

Description

Current state: Translations are maintained in transifex and are written to the web repo every night, resulting in one translations.json file for each package in packages/ that has an l10n/.tx/config file. All of those translations.json files get loaded and merged at runtime in the web runtime.

This "one fits all" solution doesn't work in some cases. Customers want to be able to overwrite certain strings with something that's not compatible with the product.

User Stories

• As a german company I want to get rid of Anglicisms, like the word "Space", in the web ui so that my employees don't get confused on a daily basis.

Value

Acceptance Criteria

• allow loading additional translation json files that don't come in via our transifex process but are added in the deployment (i.e. independent hosting of the translation json files by the sysadmin, not part of the web bundle)
• strings in the additional translation json files need to take precedence over the translations from the product
• add config key/value to the web config struct in ocis

Technical notes:

• build config structure similar to the structs for additional scripts and styles
• structure of a translations.json file is as follows:

{
  "de": {
    "\"%{fileName}\" was created successfully":"\"%{fileName}\" wurde erfolgreich erstellt",
    "Create a new space":"Neuen Space erzeugen"
  },
  "bg": {
    "\"%{fileName}\" was created successfully":"\"%{fileName}\" е създаден успешно",
    "Create a new space":"Създаване на ново пространство"
  }
}

the structure of additional translations.json files is expected to be the same. As a matter of fact this means, that additional translations break in the same way as translations on transifex if the english string in the code base changes. We do accept that for now.

Definition of ready

[ ] everybody needs to understand the value written in the user story
[ ] acceptance criteria has to be defined
[ ] all dependencies of the user story need to be identified
[ ] feature should be seen from an end user perspective
[ ] user story has to be estimated
[ ] story points need to be less then 20

Definition of done

• Functional requirements
  [ ] functionality described in the user story works
  [ ] acceptance criteria are fulfilled
• Quality
  [ ] code review happened
  [ ] CI is green
  [ ] critical code received unit tests by the developer
  [ ] automated tests passed (if automated tests are not available, this test needs to be created and passed
• Non-functional requirements
  [ ] no sonar cloud issues