The i18n assets are currently built into the application at compile-time, so a translation change in any of the ".json5' files requires a rebuild of the application. We are maintaining our translations since DSpace6 using a CSV format for easy editing, and for dspace-angular we adapted the process to generate the '.json5' files as well as the compressed json files as required. These assets (browser and server) are side-loaded into the dspace-angular container using volume mounts. So, if it would be possible to configure the actual languageHases during startup no rebuild of the application would be necessary, allowing to stage translations by anyone with ease.

This could be achieved by introducing a configuration to the instance's config.yaml:

languageHashes:
  - lang: de
    md5: 0fd7b78448093f8ce05fd9bd4f1edc83
  - lang: en
    md5: 4ed2840c555bc6830fceaf517b2bfbda

In our case, a modified entrypoint would iterate over the side-loaded i18n assets and create the .yaml accordingly. (this is not part of the issue, as this entrypoint modification will depend on how someone passes the assets into the container)

The code inside the angular application must be changed to also consider the environment for obtaining the languageHashes instead of only considering the process.env.languageHash variable prepared by webpack.