graphdb-workbench

Internationalization (i18n)

Rules for adding or changing translations.

Where translations live: per-package src/assets/i18n/*.json and no duplicate keys.
Naming keys: group by feature, name by meaning, one message per key.
Validating: npm run validate and translation-report.json.
Runtime translations in the workbench: pointer to Transloco.

Keep translations under each package’s src/assets/i18n/*.json. Exception: packages/legacy-workbench keeps them in src/i18n/locale-<lang>.json.
The src/assets/i18n files are merged into one bundle per language at build time; the legacy files are loaded separately.
Avoid duplicate keys across modules for the same language — the merge plugin throws on conflicts.

Group keys by feature, then component: visual.*, page.info.documentation_link, components.dialog.unsaved_changes.confirmation.message. Add a new key to its feature’s existing section.
Name a key after its meaning (missing_graph_configuration), not after its English text.
One message, one key: keep the sentence whole and pass the dynamic parts as parameters. Don’t assemble it from fragment keys or create one key per state.
One key per use: two actions that share wording still get separate keys.
An input’s placeholder and its aria-label describe the same thing: use the same key for both.
Translate where the text is shown: in the template (pipe/filter) or at the moment you emit it. Don’t keep translated strings in fields or $scope that then need a language-change subscription to stay current.

After adding or changing translations, run:

npm run validate

If validation fails, inspect the generated translation-report.json.

The Angular workbench renders translations via Transloco — see frontend-angular.md.