Operational Dashboard Translation Customisation

Use camelCase for keys

Consistent casing improves readability and reduces typos.

Match key to value where possible

This improves readability for developers and translators, makes it easier to find keys and reduces the chance of unintentionally duplicated values.

Avoid:

title.bankFilteringHomeTitle = "Bank Filtering Rule Settings"

Use:

title.bankFilteringRuleSettings = "Bank Filtering Rule Settings"

If the value is long or descriptive, use a clear, semantic key, e.g.:

text.noBankFilteringRulesFound ="No bank filtering rules were found for the search criteria"

Avoid acronyms in keys

This improves clarity for developers and translators and prevents unintentional duplication of values.

Avoid:

formField.uowId

Use:

formField.unitOfWorkId

Extract shared terms to the global file

Avoids duplication; prevents bloated translation sheets; maintains consistency across modules.

If a term is used across multiple modules, define it in the global translation file. If in one module a different value is needed, it can be overridden in a scoped sheet.

Avoid:

htm.button.confirm = "Confirm"

ods.button.confirm = "Confirm"

processingSettings.button.confirmExcited = "Confirm!"

Use:

button.confirm = "Confirm"

processingSettings.button.confirm = "Confirm!"

Repeat values for different contexts

Clarifies intent for developers and is essential for translators, as even if the same value is repeated in English, the context may change the grammar or tone required in another language.

Use:

formField.agentAddress = "Agent Address"

columnHeader.agentAddress = "Agent Address"

heading.agentAddress = "Agent Address"

Avoid deeply nested keys

Over-nesting ties keys too closely to the module or component structure, making refactoring more fragile, limiting re-usability and bloating translation files. In the IPF Operational Dashboard, deeply nested keys also prevent global translations from being used effectively.

If nesting seems necessary to manage complexity, it’s usually a sign that the translations should be moved to a separate scope instead.

Avoid:

settings.form.agentSettings.user.accountName

Use:

formField.accountName

Avoid sentence fragments as values

Ensures grammatically correct sentences in all languages.

Avoid:

noUserExistsWithThisName = "No user exists with this name"

wouldYouLikeToCreateOne = "would you like to create one?"

Used together:

{{ t('noUserExistsWithThisName') }}, {{ t('wouldYouLikeToCreateOne') }}

Use:

userNotFound = "No user exists with this name, would you like to create one?"

Use interpolation instead of concatenation

Ensures grammatically correct sentences in all languages.

Avoid:

welcome = "Welcome "

toHomePage = "to the home page!"

Use:

welcomeMessage = "Welcome to the {{page}}!"

Avoid coupling keys to models or component structures

Prevents fragile, hard to maintain dependencies.

Translation keys should be semantic and agnostic - not directly derived from the code’s internal model structure. Model fields may change or be inconsistent between modules, don’t assume they’re safe or meaningful for i18n.

Avoid:

t(model.key)

Don’t use translation keys to drive layout or structure

Translations are meant for text content only — not layout or configuration. Relying on them for structure creates tight coupling, which can lead to brittle code and hard-to-diagnose issues when either the UI or translations change.

Avoid: