Software localisation: software, apps and machine controls in the target language
- ISO 17100 and ISO 9001, audited by DEKRA
- strings.xml, .strings, .resx, .po, XLIFF, JSON and YAML
- Placeholders, plural forms and string lengths are checked
- A translation memory per product: releases only as a delta
For software companies and machinery and plant engineering
Industry software and web applications usually come with ongoing releases, machine controls together with the operating instructions in one terminology base. Marketing website and online shop belong to website localisation.
The resource file is checked before the quote
- Check and quote
Review of the resource file: placeholders, plural forms, concatenated strings, texts not yet moved out of the code. Then a quote per language, with a delivery date, usually the same working day.
What you supplyResource file, if possible screenshots for ambiguous strings
- Terminology
Define product terms, lock names that stay untranslated, align with existing documentation
What you supplyGlossary, if available; translated manual, if available
- Translation in the format
Directly in the resource file, with automated checks of placeholders, lengths and special characters
What you supplyNothing
- Revision and sign-off
Mandatory revision to ISO 17100 by a second specialist, text against text. The visual check in the localised build or on screenshots per language lies with your team.
What you supplyFeedback from your visual check, for example strings that have to be shortened
For follow-up releases only new and changed strings are handled and charged; terminology and translation memory grow with them. A delta export is enough, or the full file from which we determine the delta.
Placeholders and string lengths are checked by machine
Translation happens directly in the resource file, with automated checks of placeholders, lengths and special characters. A second specialist then revises text against text, as ISO 17100 requires. The visual check in the localised build or on screenshots per language lies with your team. The process is certified to ISO 17100 and ISO 9001 and audited by DEKRA.
Send the file or a sample with the target language and purpose, and you will usually have a quote on the same working day.
Strings already translated lower the cost
The price depends on the language combination, the number of languages, the effort needed to clarify context and the share of strings already translated in earlier releases. Whether the software is internationalised belongs before the quote, because it changes the effort.
- Billing is per standard line (Normzeile) of 50 to 55 characters including spaces, not per file size
- Urgent deadlines: agreed with the quote; same-day delivery is possible only in exceptional cases, because the mandatory revision to ISO 17100 by a second specialist takes time.
The general basis of billing is explained under specialised translations.
L10n adapts interfaces to the target market
Software localisation, abbreviated L10n, is the adaptation of software, an app or a machine control to the language, conventions and technical requirements of a target market. It differs from document translation at three points: the text does not come as running text but as individual strings in resource files; each string has a length limit set by the layout; and placeholders, plural rules and date formats have to work in the target language, not just sound right. Eurolingua handles localisation to ISO 17100 with mandatory revision by a second specialist, directly in the resource format and with a translation memory across all releases. Websites and online shops with legal texts, search terms and shop strings belong to website localisation.
Show table: localised content, formats, checks and quoteHide table
| Criterion | Details |
|---|---|
| What is localised | User interfaces (menus, buttons, dialogues), error and status messages, onboarding and help texts, machine controls and operator panels (HMI), firmware display texts, app store descriptions, web front ends of SaaS applications |
| Formats | strings.xml (Android), .strings and String Catalogs (iOS/macOS), .resx (.NET), .po/.pot (gettext), JSON (i18next and similar), .properties (Java), XLIFF 1.2 and 2.x, CSV/Excel exports from CMS and shop systems |
| Checks | Placeholders and variables unchanged, plural forms complete per language, string lengths against the limit, special characters and escape sequences, consistency with the operating manual and help |
| Certification | ISO 17100 and ISO 9001 (DEKRA, valid until 2 January 2028 and 7 March 2027 respectively) |
| Reuse | Translation memory and terminology database per product; for releases only new and changed strings are charged |
| Scope | Websites and online shops: website localisation. Operating manual and handbook: technical translation. Campaigns and slogans: business translation |
| Location | Hohe Straße 45, 44139 Dortmund, Germany; personal consultation Mon–Thu 8:30–15:30, Fri 8:30–14:30 |
| Quote | Without obligation, once we have seen the resource file |
Translation or localisation: the difference at three points in the code
A translation carries over text. A localisation makes sure that the translated text works at the point where the software outputs it. The difference is not a degree of care but a different working basis: the localiser does not see the sentence but the string, with its key, its length limit and its variables. Internationalisation (i18n) is the upstream step on the development side that makes the software localisable in the first place: moving texts out of the code, not hard-wiring formats, providing for plural rules.
| Step | Who does it | In practice | If it is missing |
|---|---|---|---|
| Internationalisation (i18n) | Development | Move strings into resource files, output date, number and currency through locale functions, set up plural forms as categories, allow in the layout for longer texts and right-to-left script | The software cannot be localised, only reprogrammed. No translation agency can make up for that |
| Translation | Specialist translator | The meaning of each string in the target language, with context (Where does it appear? Button or heading? Which variable goes into the placeholder?) | “Save” becomes “Sparen” (economise) instead of “Speichern” (store), “Order” becomes “Reihenfolge” (sequence) instead of “Bestellung” (purchase order) |
| Localisation (L10n) | Specialist translator and reviser; your development team does the visual check in the build | Keep to string lengths, fill in plural forms per language, preserve placeholders, check sort orders and keyboard shortcuts, identify images with text, look at the result in the build | Text overflows the button, “1 files”, a crash caused by a damaged placeholder, a screenshot in the help shows the German interface |
Check before the quote whether your software is internationalised. If date formats or messages are assembled in the code, the effort is different, and we say so before the first string is translated.
Strings, placeholders and plural forms: what is different in software compared with documents
Three properties of software text create errors that do not occur in documents: strings expand in the target language, and the shorter they are, the more they expand; placeholders such as %1$s, {count} or %d have to be preserved exactly and stand in the grammatically correct place; and the number of plural forms differs by language, which the software has to provide for before the translator can fill them in.
Text expansion: why buttons break and paragraphs do not
When translated from English, German text grows by around 30 per cent on average. For the interface, though, the average is irrelevant. What matters is that short strings grow most in percentage terms: a word of five characters can double or triple in the target language, while a paragraph of 500 characters grows by a third. That is why menu items, buttons and table headers break while help texts fit without trouble.
| Length of the English string | Additional space to allow for | Typical place |
|---|---|---|
| up to 10 characters | 100 to 200 per cent | Buttons, menu items, tab labels |
| 11 to 20 characters | 80 to 100 per cent | Field labels, table headers |
| 21 to 30 characters | 60 to 80 per cent | Status messages, tooltips |
| 31 to 50 characters | 40 to 60 per cent | Dialogue texts, warnings |
| 51 to 70 characters | 51 to 70 per cent | Longer messages, notes |
| over 70 characters | around 30 per cent | Help texts, descriptions |
For German as the source language the reverse applies: English becomes shorter, Romance languages and Russian become longer, Chinese and Japanese need fewer characters but more line height. If you supply a length limit per string, it is checked during translation; if not, only the build shows where text overflows.
Plural forms: a question to settle before translation
German and English have two plural categories (one file, two files). Many target languages have more, and the category depends on the number:
| Language | Categories | Example for “n files” |
|---|---|---|
| German, English, Dutch, Swedish, Turkish | 2 (one, other) | 1 file / 2 files |
| French, Portuguese (Brazil) | one and other in everyday use, with 0 and 1 counted as singular; CLDR adds a many category for millions | 0 fichier, 1 fichier / 2 fichiers |
| Polish, Russian, Ukrainian, Czech, Croatian | 3 to 4 (one, few, many, other) | 1 plik / 2 to 4 pliki / 5 to 21 plików, 22 pliki |
| Arabic | 6 (zero, one, two, few, many, other) | Separate forms for 0, 1, 2, 3 to 10, 11 to 99, 100 and above |
| Chinese, Japanese, Vietnamese | 1 (other) | No plural inflection, the number stands alone |
Software that forms “files” as one string with a number inserted (“%d files”) cannot be localised correctly into Polish or Arabic, regardless of translation quality. The plural categories have to exist as forms in the resource file (Android plurals, iOS stringsdict or String Catalog, ICU MessageFormat, gettext Plural-Forms) so that the translator can fill them in. We settle this question at the quote, not at the complaint.
Placeholders and word order
%1$s saved %2$d files in %3$s may rearrange the placeholders in the target language, but not change them. Languages with a different word order need numbered placeholders; without numbering (%s has %d files) the order is fixed, and the translation becomes grammatically wrong or the software crashes if a type does not match. We check this automatically before delivery; unnumbered placeholders are reported back to you before work starts.
Resource files and handover: strings translated directly in their format
The most frequent avoidable effort in localisation projects is the detour via Word or Excel: strings are exported, translated as running text and carried back by hand. Keys, comments and placeholders get lost on the way, and every transfer back is a source of error. We translate directly in the resource file; keys, structure and comments stay unchanged, only the target text changes.
Show table: resource formats with platform and handover notesHide table
| Format | Platform | What matters at handover |
|---|---|---|
| strings.xml | Android | Supply plurals and string-array as well; set translatable="false" for product names and keys that are not to be translated |
| .strings, .stringsdict, String Catalog (.xcstrings) | iOS, macOS | Developer comments in the catalog are the most important context; create plural variants in the catalog before translation |
| .resx | .NET, Windows | Culture-specific files per language (.de-DE.resx, .pl-PL.resx); use the comment column |
| .po / .pot | gettext (PHP, Python, WordPress, Linux) | Set the Plural-Forms header correctly per language; msgctxt for identical strings with different meanings |
| JSON | Web front ends (i18next, Vue I18n, Angular) | Keep ICU syntax for plural and select; do not flatten nested keys |
| .properties | Java | Preserve Unicode escapes and line breaks; state the encoding |
| XLIFF 1.2 / 2.x | Exchange format from TMS, CMS and development environments | The best handover format, because source, target, context and status sit in one file; re-import without manual work |
| CSV, Excel | Shop systems, CMS exports, machine controls | Only as a last resort: add a column for the key, a column for the length limit and a column for context; do not wrap cell contents |
Your resource format is not in the table? Tell us the format or send us a sample file. Send a file
What you should supply so that the translation fits first time: the resource file in the original, developer comments or screenshots for ambiguous strings, the length limits where they exist, a glossary of product terms that are not translated and, if available, the already translated operating manual, so that software and documentation use the same terms.
Website or software: which service fits your project
The line does not run between browser and desktop but between resource file and page content. Everything a visitor calls up as a page, meaning corporate sites, online shops, product copy, metadata, legal texts and transactional emails, belongs to website localisation, with its own rules for search terms, hreflang and the target market’s language requirements. Everything that sits as a string with a key in a resource file belongs here, even if it runs in the browser: the interface of a SaaS application is software, its marketing website is a website. If you have both, you place two jobs with a shared terminology base.
Three classes of error in localisation projects
Three classes of error are typical in localisation jobs. None of them is a translation error in the narrow sense; all three arise at the boundary between text and software.
Error class 1: software and manual name the same function differently
The operating manual was translated two years ago, the control software now, by another provider or without the manual as a reference. The menu item has a different name in the software than in the manual that refers to it. The user looks on the machine for a term that does not exist there. It is the same error that the technical translation page describes from the opposite direction. Remedy: the software’s display texts are the leading terminology and the manual follows them; both in one translation memory.
Error class 2: concatenated messages
The software builds a message from parts: "File" + name + "was" + status. Each part is translated correctly. In the target language, the grammar requires a different order or an inflection that depends on the inserted value. The result is a message made of the right words in the wrong order. This cannot be fixed by translation, only by a complete string with placeholders. We report such places back before work starts, because the decision lies with development.
Error class 3: nobody looks at the build
The resource file is completely and correctly translated. The file is signed off, not the running software. In the build, text overflows buttons, a date appears in German notation because it is formatted in the code, and a screenshot in the help shows the German interface. Remedy: a check in the localised build or with screenshots per language as a fixed step of your sign-off. Revision to ISO 17100 checks text against text; the visual check in the running software is a separate step that only your team can carry out with the build.
Process and continuous localisation: how releases stay multilingual without a new commission
Software has no final deadline, only releases. Continuous localisation means that after the first complete run, only new and changed strings are translated for each release, and everything unchanged comes from the translation memory. This requires an exchange format from which the delta can be determined, usually XLIFF or the export of a translation management system.
Software and website localisation in Dortmund and the Ruhr region
From Dortmund, one of the larger IT locations in North Rhine-Westphalia with its Technical University, technology park and Fraunhofer institutes, we localise software for software houses, IT service providers and the region’s machinery and plant engineering, whose control software has to go into the same languages as its operating manuals.
Typical jobs from the region:
- Machine controls and HMI texts from machinery and plant engineering, together with the operating manual in one terminology base
- Industry software and web applications from Dortmund software companies for clients across Europe, mostly with ongoing releases
- SaaS interfaces and web front ends with JSON resources, where the marketing website runs separately under website localisation
- App store texts and onboarding for consumer-facing apps, with an eye on accessible labels since the German Accessibility Strengthening Act (BFSG)
Personal consultation: Hohe Straße 45, 44139 Dortmund (Kreuzviertel district), Mon–Thu 8:30–15:30, Fri 8:30–14:30. Underground station Saarlandstraße (U46). For localisation projects, meeting in person is most useful at the start, when terminology and handover format are set.
Common questions on software and website localisation
What is localisation, and how does it differ from translation?
Localisation is the adaptation of software, an app or a machine control to the language, conventions and technology of a target market. Translation is the part of it that carries over text. On top of that come string lengths, placeholders, plural forms, date and number formats, sorting, right-to-left script and the check in the running program. The upstream step on the development side that makes all this possible is called internationalisation (i18n); localisation is abbreviated L10n, after the number of letters between L and n.
Can you translate strings directly in our resource file?
Yes, that is the normal case. strings.xml, String Catalogs, .resx, .po, JSON, .properties and XLIFF are handled in their format; keys, comments and placeholders stay unchanged. The re-import into your project works without manual transfer. An export to Word or Excel is not necessary and would be the route with the most errors.
How does continuous localisation work?
After the first complete run, only new and changed strings are translated for each release. Everything unchanged comes from the translation memory and is not charged again. This needs an exchange format from which the delta can be determined, usually XLIFF or the export of your translation management system. The delivery rhythm follows your release cycle; with short cycles we agree fixed handover dates.
Who checks whether the translation displays correctly in the software?
Revision to ISO 17100 by a second specialist is mandatory and checks text against text. What it does not see only shows in the running software: text overflows, truncated labels, wrongly formatted dates, images with text. This visual check in the localised build or on screenshots per language lies with your team; we deliver the file, and your development team looks at the result. Report back to us any strings that have to be shortened or adapted.
What does software localisation cost?
Billing is per word or standard line (Normzeile) of the strings to be translated, not per file size. The price depends on the language combination, the number of languages, the effort needed to clarify context and the share of strings already translated in earlier releases. With ongoing localisation, the cost per release falls markedly because only the delta is charged. You receive a quote per job, without obligation. The general basis of billing is explained under specialised translations.
Which languages are requested most often for software localisation?
English covers the entry point; the languages of the neighbouring markets, Dutch, French and Polish, follow depending on the sales region. For machine controls, the languages of machinery export markets follow, often Spanish, Italian, Czech and Chinese, with character limits on the panel as the deciding factor. For Arabic and Hebrew, the right-to-left display of the interface also has to be checked, which the software has to support. Language details: languages we translate.
Send the file or a sample with the target language and purpose, and you will usually have a quote on the same working day.