Software and SaaS Application Localisation (Multilingual)

Making a software product or SaaS application multilingual is about far more than translating words. Here is how to approach the localisation of a digital product: the difference with translation, the technical workflow, the challenges specific to SaaS, and the priority languages for the Belgian and European market.

📖 Also read: website localisation · technical translation · sworn translation guide

Translation or localisation: what is the difference?

Translation renders a text from one language into another. Localisation adapts the whole product to a market: interface labels, date and time formats, currencies, thousands separators, reading direction (RTL languages such as Arabic or Hebrew), plural rules specific to each language, and string length. A 6-character « Submit » button becomes « Indienen » or « Verzenden »: if the layout has not allowed for this expansion, the interface breaks. Localisation therefore handles both the text and the display context. It is the same logic as website localisation, applied to an application.

The software localisation workflow

Clean localisation relies on externalising the strings: the displayed text does not live in the code but in resource files (JSON, .po, XLIFF, .strings, .resx). Each string carries a stable i18n key, which allows translation without touching the code and the automatic re-injection of the translated versions. On the process side, you connect translation to continuous integration: with each release the new keys go out for translation, then come back into the right language file. A translation memory and a product glossary ensure that the same term (« dashboard », « workspace », « billing ») stays identical everywhere, release after release.

The challenges specific to SaaS

A SaaS evolves continuously, which creates specific constraints:

• Terminological consistency : without a glossary, the same concept ends up translated three different ways depending on the screen and the release.
• Frequent updates : strings arrive in small incremental batches; you need a flow able to handle a few dozen words as cleanly as a large delivery.
• In-context linguistic testing : proofreading the strings in the real interface reveals the truncations, misplaced variables and mistranslations that a raw file does not show.
• Brand tone : the level of formality and the product vocabulary must stay consistent in every language.

Which languages should you prioritise for the Belgian and European market?

For a product targeting Belgium, Dutch and French are essential, with English often serving as a pivot language and an international version. Germanopens up Belgium's third national language as well as the DACH market (Germany, Austria, Switzerland). Depending on your target, Spanish, Italian and Portuguese then broaden European coverage. It is better to launch three languages that are perfectly localised and tested than ten approximate versions. For highly specialised content, see our approach to technical translation.

Preparing a product ready for international markets

Internationalisation (i18n) is prepared from the design stage: externalise 100% of the strings, never concatenate fragments of a sentence, allow for text expansion in the layout, handle plurals and local formats in the code, and ban text baked into images. A product designed this way localises quickly and without technical debt; a product that has not planned for it imposes a costly rework before the first translation even begins.