Software Localisation One interface, usable in every language.
Software localisation translates the UI strings, error messages and notifications that sit inside resource files and code. We return the translated strings in the original format, with placeholders and plural rules preserved, ready for your next build. Request a quote.
Four ISO certificationsTranslation partner for demanding companies
- What it is: Adapting an application to a language market: UI strings, messages and in-app text, done linguistically, culturally and technically.
- Formats: Working directly in resource files such as JSON, XLIFF, PO, RESX, .strings, Android XML, ARB and Properties.
- Integration: Continuous localisation via API and system integration, timed to your releases.
- Scope: For your public web presence in the CMS, website translation is the right service; here it is about the product itself.
File formats and platforms
We work where your strings live
Software text rarely arrives as a finished document. It sits in resource files that separate key and value and keep code apart from language. We translate directly in these files, without breaking structure, tags or placeholders, and return them in the same format. That way the result drops into your next build with no rework.
| Platform / environment | Typical formats | Notable point |
|---|---|---|
| Web apps & SaaS | JSON (i18next), XLIFF, YAML, PO | Key-based strings, often without context |
| iOS & macOS | .strings, .stringsdict, XLIFF | Plural rules via stringsdict |
| Android | strings.xml, XLIFF | Plurals and placeholders in the XML |
| .NET / Windows | RESX, XLIFF | Resources per culture (de-DE, fr-FR) |
| Java / Flutter / other | .properties, ARB, XML, YAML | ICU MessageFormat for plurals |
We also localise embedded systems, firmware interfaces and industrial controls. If your format is not listed here, we will place it in the initial call. More on the technical side under tolingo API and system integration. For background on a specific format, see our article on YAML localisation.
The common pitfalls
Where software localisation goes wrong when it is treated like document translation
Translate software like a document and you produce errors that only surface in the live product. Five points come up again and again, and this is exactly where our process starts.
- String length overruns the interface
German is often 30% longer than English, Japanese noticeably shorter. A button that fits in the original gets truncated once translated. We check lengths in context and shorten where the interface demands it.
- Placeholders and variables get lost
In a string like "Hello, {name}" or "%d items", the placeholder must not be translated or moved, or the display crashes. Our translators know this syntax and leave the code untouched.
- Plural rules get ignored
Other languages have other plural forms. Arabic distinguishes six, Polish three. A file with a single plural form is simply wrong in the target market. We localise via ICU MessageFormat and each platform's own plural mechanisms.
- Missing context leads to wrong choices
A single "Open" can be a verb or a state. Without context, the translation guesses. We work with key names, comments and, on request, screenshots or a test build, so every string lands right.
- Reading direction and format go unaddressed
For Arabic and Hebrew the interface has to be mirrored, plus local date, number and currency formats. For us this cultural and technical adaptation is part of localisation, and not something left to rework.
Internationalisation and continuous localisation
Localisation as an ongoing cycle that keeps pace with every release
Software never stands still: every release changes strings. To keep localisation in step, internationalisation (i18n) first separates text from code. After that it runs as a cycle: new strings go into translation automatically via API and come back ready to use. A translation memory cuts follow-up costs by up to 70%.
From resource file to localised app
Three steps, from export to a ready-to-use build
Strings & context
Your resource files, the target languages and the platform. On request, screenshots or a test build, so every string sits in context.
Translation plus LQA
Native-speaker specialist translators carry over the strings, with placeholders and plural rules kept intact. In Linguistic Quality Assurance we check length and context.
Files in the original format
The localised resource files in the same format you supplied, ready for deployment or the next build. Automated via API on request.
Natively usable in the target market An application that feels, in every language, as if it was built for it. The basis is clean specialist translation to ISO 17100.
Ready to make your software work globally?
Describe your project: platform, formats, target languages and release rhythm. We recommend the right route and give you scope and price.
Free · No obligation · Response in ~10 minutes (within business hours)Frequently asked questions about software localisation
Scope, formats, context, AI and cost
What is software localisation?
Software localisation is the adaptation of an application to a language market. What gets translated is the text in the software itself, that is UI strings, error messages, onboarding and notifications. On top of that come cultural and technical adaptations such as date and number formats, units, plural rules and reading direction. The work happens directly in resource files, not in a text document.
What is the difference from website translation?
Website translation carries over your public web presence in the CMS, that is pages, product text, blog and meta data. Software localisation concerns the product itself, that is the text in the application. A SaaS product often has both: a marketing website and the actual app. Then the two projects run in parallel, each with its own process.
Which file formats and platforms do you support?
We work in JSON, XLIFF, PO, RESX, .strings and .stringsdict, Android strings.xml, ARB, Properties and YAML. That covers web apps and SaaS, iOS and macOS, Android, .NET, Java and Flutter as well as embedded systems. If your format is not listed here, we will place it in the initial call.
How does the translator get context for individual strings?
Key-based strings are ambiguous without context, an "Open" can be a verb or a state. We use key names, developer comments and, on request, screenshots or a test build. In the final Linguistic Quality Assurance we check the strings in the context of the interface.
Does my software have to be prepared for localisation?
Ideally, yes. In internationalisation (i18n), text is separated from code, moved into resource files, and room is planned for longer translations. Once that is done, localisation runs predictably. We advise on the preparation if the separation is not yet complete.
Can AI localise my software?
Machine translation helps with large, uniform sets of strings, but often fails on missing context, placeholders and plural rules. For visible, interactive text we recommend post-editing to ISO 18587 or plain specialist translation. That keeps the speed of AI without breaking the interface.
What does software localisation cost and how long does it take?
It is billed per word: post-editing from €0.05/word, specialist translation from €0.12/word. Via translation memory you save up to 70% on recurring strings. Duration and price depend on scope, platform and target languages. After a short analysis we prepare a timeline and quote, usually within a few minutes during business hours.
Glossary
Terms around software localisation
- Internationalisation (i18n)
- Technical preparation of software for multiple languages: text is separated from code, moved into resource files, and room is planned for longer strings.
- Localisation (L10n)
- Adaptation of the prepared software to a specific market: translation of the strings plus formats, plural rules, reading direction and cultural conventions.
- String / resource file
- A text unit addressed by a key, and the file those units sit in, such as JSON, XLIFF or strings.xml.
- Pseudo-localisation
- A test method that artificially lengthens strings and adds special characters to find space problems and missing externalisation before the real translation.
Software that feels at home everywhere.
Send us your resource files and target languages. We localise strings, formats and interface and return everything ready to use in the original format.
ISO 17100 · ISO 18587 · Translation Memory included · Response in ~10 minutes (within business hours)