Runtime i18n Loading for Theme Translations (no build-time merge for i18n files)

[kanasznagyzoltan]

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

When operating DSpace Angular using multiple themes for multiple instances, each with their own theme and theme-specific translation overrides, the current workflow requires running the merge-i18n script before building. This script merges each theme's i18n files (src/themes/<theme>/assets/i18n/*.json5) into the base location (src/assets/i18n/*.json5) so they get picked up by the TranslateLoader.

This causes several pain points:

1. One Docker image per theme. Because translations are baked into the base i18n files at build time, you cannot produce a single image that serves multiple instances — each customer needs a dedicated build with their own merged translations.
2. One Git branch per instance. The merged files live in src/assets/i18n/ and must not be committed (they'd overwrite upstream base translations for everyone). This forces maintainers to keep per-customer branches or carefully manage uncommitted local state in CI.
3. Easy to accidentally commit merged output. If the merged files are pushed to the main branch, they pollute base translations and cause conflicts on every upstream merge.
4. Theme inheritance is not fully leveraged. Even though DSpace supports extends for themes (so a theme can inherit components from a parent), the i18n system has no equivalent — child themes must duplicate parent translations at merge time.
5. Extra build step that has to be remembered and re-run whenever any theme translation changes.

In short: the build-time merge ties theme selection and translation content to build output, which makes multi instance deployments of a single DSpace Angular image impossible without rebuilding.

Describe the solution you'd like

Make the TranslateLoader theme-aware so that theme translations are loaded and merged at runtime, exactly the way themed components are resolved today.

Benefits

• One Docker image serves many instances — theme selection (and therefore translations) becomes a runtime decision driven by config.yml or env. vars.