Languages

Language Support

The platform can be presented in more than one language.

Where to find it

Architect Panel → Internationalisation:

• Languages — the configured languages and their files

Architect Panel → Data:

• Datastores — the content, which is a separate question

Two different things

The distinction that determines the size of the job:

• The interface — buttons, menus, labels, messages. Finite, and translated once.
• Your content — the records people create. Unbounded, and never finished.

Translating the interface is a project. Translating content is an ongoing operational commitment, and organisations frequently agree to the first while assuming they have solved the second.

Be honest about which you are offering

A service whose buttons are in Welsh and whose case notes are in English is partly translated, and a user will discover that at the point it matters to them.

Decide what you are promising and say so, rather than letting somebody find out.

What translation actually involves

• The interface strings.
• Your field labels and help text.
• E-mail and letter templates.
• Documents you generate.
• Validation and error messages.
• Anything a person wrote into a dropdown.

The last two are the ones consistently forgotten, and they surface at the worst moment — somebody in the middle of a form receiving an error in the wrong language.

It is not only translation

Date formats, number formats, name order, address shape and how somebody is politely addressed all vary. A form assuming a UK address shape is not fixed by translating its labels.

Text expands

Translated text is frequently longer than the English — sometimes considerably. Interfaces designed tightly around English wording break: buttons wrap, labels truncate, columns misalign.

Check the actual layout in each language rather than assuming the strings simply drop in.

Start with one

Adding a second language teaches you what your application assumes about language. Learn that once, with one, before committing to several.

Plan for maintenance

Every new feature adds strings, and every untranslated string appears in the wrong language. A translation is not finished when it ships — it needs updating whenever the application changes.

Worked example

An organisation offering Welsh translates the interface, its field labels, its templates and its dropdown values, and commits to Welsh case correspondence with a bilingual team. It does not claim case notes are bilingual, and says so. Layout was checked in Welsh, which caught three buttons wrapping.

Recommendations

• Separate interface from content when scoping.
• Say what is and is not translated.
• Check layout in each language, not just strings.
• Budget for maintenance — it is not a one-off.

Adding a Language

A language is a record naming it and pointing at its translation file.

Where to find it

Architect Panel → Internationalisation:

• Languages — the languages and their files

Setting one up

1. Add the language with its name and file.
2. Translate the strings.
3. Check the interface in that language.
4. Translate your own labels, templates and dropdown values.
5. Check again with somebody who speaks it.

Step four is where the work is, and step five is where the errors are found.

Use a speaker, not a tool

Machine translation is a reasonable starting draft and a poor finished product for an interface. Software language is full of terms with specific conventional translations, and a literal rendering reads as obviously machine-produced — which undermines trust in the service.

Somebody who speaks the language should review everything before it is offered.

Context matters more than words

"Open" is a verb on a button and an adjective on a status. A translator working from a list of strings without context will get some wrong, and the errors are frequently invisible to a monolingual reviewer.

Give the translator the interface, not a spreadsheet, if you possibly can.

Do not launch partial

An interface half in each language is worse than one language done properly — it reads as broken rather than as multilingual, and users lose confidence in the parts that are translated.

Finish before offering it.

Check the layout

In the language, on a real screen. Longer strings break tight layouts, and the failure is visual rather than functional so nothing will report it.

Do not forget the edges

Error messages, validation text, empty states, confirmation dialogs, e-mail subjects, document headings. These are the strings nobody thinks to translate and exactly the ones a user meets at a moment of difficulty.

Test with a real user

Somebody who speaks the language and does not know the application. They will find the awkward phrasing and the untranslated corner in ten minutes, and a monolingual team will not find either.

Worked example

An organisation adds Welsh, drafts with a tool, then has a Welsh-speaking colleague review everything in context rather than as a list. That review changed about a fifth of the strings, mostly where a word had been translated in the wrong sense. Layout checking found three truncations, and it was not offered to the public until all of it was complete.

Recommendations

• Have a speaker review it before offering it.
• Translate in context, not from a list.
• Never launch partially translated.
• Test with a real speaker who does not know the system.

Translating Your Own Content

The platform's own interface is one thing. Everything you have added — labels, help text, dropdown values, templates — is yours.

Where to find it

Architect Panel → Internationalisation:

• Languages — the configured languages

Architect Panel → Data:

• Datastores — field labels and help text

Architect Panel → Layout & Pages:

• E-mail Templates — templates needing a translated version

This is usually the larger half

The platform's strings are finite and translated once. Your labels, dropdown values, help text and templates grow with the application, and each addition is a translation somebody must do.

Organisations budget for the first and are surprised by the second.

The parts most often missed

• Dropdown values. A form with translated labels and English options is a common and jarring failure.
• Help text — the guidance sitting under a field, which is precisely what somebody struggling will read.
• Validation messages you wrote yourself.
• E-mail and letter templates, which need a version per language.
• Document templates.

Templates need a version per language

And a way to choose the right one when sending. That means knowing each recipient's language — a field on the person's record — and selecting accordingly.

Decide this early, because retrofitting a language preference onto an existing contact base means asking everybody or guessing.

Record the preference, do not infer it

Guessing from a name, an address or a browser setting gets it wrong often enough to offend. Ask, store the answer, and let people change it.

New fields need translating too

Every field added after launch arrives untranslated and appears in the wrong language until somebody notices. Make translation part of adding a field rather than a periodic clean-up — the clean-up never quite happens.

Keep terminology consistent

The same concept should use the same word throughout. Two translators, or one translator at different times, will produce two words for "case" — and a user reading both concludes they are different things.

Keep a short glossary of your key terms and their agreed translations.

Check what a real record looks like

Not an empty form. A completed record with real values, in the language, is where you see the untranslated dropdown value and the English status sitting among translated labels.

Worked example

An organisation translates its labels, help text and every dropdown value, and maintains Welsh versions of eleven templates selected by a language field on the contact record. A short glossary keeps its case-management vocabulary consistent, and adding a field now includes its Welsh label as a matter of course.

Recommendations

• Budget for your own content — it is the larger half.
• Do not forget dropdown values and help text.
• Record language preference, never infer it.
• Keep a glossary for consistent terminology.