The Software Localization Process: Steps, Cost Drivers and What to Send Your Provider
The software localization process has eight steps: make the code ready for other languages, extract strings into translatable files, give translators context, agree terminology, translate and revise, test with pseudo-localization and in-context review, release, then repeat for every update. Cost depends mostly on new versus repeated text, the number of languages and how often you release. DEMA Solutions localizes software and its documentation for European technology companies.
Who this guide is for
This guide is for the people who have to ship a product in several languages without slowing development down: product managers planning a first multilingual release, development leads who will own the string files, and localization managers who have inherited a process that works most of the time. It is also for manufacturers whose products now come with software, such as a configuration tool, a customer portal or a companion app, and who are discovering that software does not translate like a manual.
The questions are practical: what has to happen in the code first, which files to send, how to test the result, and why quotes differ so much. The sections below follow the process in order.
What is software localization, and how is it different from translation?
Software localization adapts a program’s user-facing text, formats and behaviour so that it feels native to users in another language and market. Translation is the central part, but only one part. A localized product also shows dates, numbers, currencies and units the way local users expect, handles plural forms that English does not have, fits longer text into the same buttons and dialogs, and uses the same terms in the interface, the help centre and the documentation.
The localization vs translation distinction matters because it changes who is involved. A document can be translated by linguists alone. Software cannot: developers decide how strings are stored and assembled, designers decide how much space a label gets, and product owners decide which markets ship when. When those decisions are made with other languages in mind, translation is fast and predictable. When they are not, translators receive fragments without context, and the problems surface late, on a release build, in a language nobody on the team reads.
Internationalization comes first
Before localization comes internationalization, the engineering work that makes a product ready for any language. It is the most frequent cause of slow and expensive localization, and it sits almost entirely with the development team.
Externalize every user-facing string. Text hard-coded in the source cannot be extracted or updated without a code change. Labels, messages, tooltips, email templates and error texts belong in resource files, referenced by stable keys.
Never build sentences from pieces. Code that concatenates “You have ” + count + ” new messages” assumes English word order. Use complete sentences with named placeholders and let each language arrange them.
Support plural rules. English has two plural forms; many languages have more, with different categories. Message formats that support plural categories, such as the ICU message syntax, let translators supply every form the language needs.
Leave room for text expansion. Translated text is often longer than English, and short labels expand proportionally the most. Flexible layouts, and agreed character limits where space really is fixed, prevent most truncation.
Use locale-aware formatting and Unicode throughout. Dates, numbers and sorting should come from locale settings, and every layer, from database to fonts, must handle the characters your target languages use.
None of this is translation work, but every gap becomes a translation problem. A good provider will point out internationalization issues it finds in your files; it cannot fix them in your code.
The software localization process, step by step
From the outside, localization looks like “send strings, receive strings”. The software localization process that works in practice has more steps, and most of them happen before or after translation.
1. Define scope and languages. Decide which components (interface, onboarding, notifications, help centre, documentation) ship in which language and release.
2. Extract strings. Export resource files the provider can process without manual copying, with keys, structure and encoding intact.
3. Pseudo-localize. Test the build with generated, lengthened text before real translation starts.
4. Prepare context. Screenshots, string comments and character limits tell the translator where each string appears.
5. Agree terminology and style. Prepare or update the glossary and style guide, approved by someone who knows the product in that market.
6. Translate and revise. Native linguists translate new and changed strings, reusing approved translations, and a second linguist revises the result.
7. Test in context. Check the translated strings on the real screens for meaning, truncation and consistency.
8. Release and maintain. Feed every fix back into the translation memory and glossary so the next release starts from the corrected version.
The following sections look at the steps where most projects go wrong.
String files and formats: what your provider should receive
Resource formats differ by platform, and each has its own risks. The provider does not need to know your build system, but it does need files it can open, translate and return in exactly the same structure. The formats teams send most often are:
- XLIFF, the XML exchange standard for localization, which keeps source, target and notes together;
- JSON, common in web and mobile front ends, often nested and without a native comment field, so context must travel separately;
- RESX for .NET applications, with a comment element for each string;
- PO files from gettext, which support translator comments, message context and plural forms;
- .strings and .stringsdict files for iOS apps and XML string resources for Android, each with its own plural syntax.
Whatever the format, certain elements must come back untouched: keys, placeholders such as {name} or %s, markup tags, escape characters and the file encoding. Placeholders may move within a sentence, because word order changes, but they must never be translated, dropped or duplicated. Automated checks catch most of these errors before delivery, and asking how a provider detects a damaged placeholder is a quick test of its process.
One habit saves a great deal of time: send only new and changed strings, or mark clearly what changed since the last delivery. Re-sending complete files without that information forces someone to rediscover what is new, and that is where accidental changes to approved strings creep in.
Context: screenshots, comments and character limits
Most localization errors are context errors, not language errors. “Open”, “Update” or “Save” can be a verb on a button or a noun in a menu, and many languages need different words for each. A string reading “%d items” could mean products in a basket or entries in a log. Without context, even a careful translator has to guess.
Three kinds of context make the difference. Screenshots show where a string sits and how much space it has. String comments explain what a key does and what each placeholder will contain. Character limits for buttons, table headers and notifications tell the translator when a shorter wording is required, before a tester finds a truncated label.
You do not need all three for every string. A note on ambiguous keys, current screenshots per release and limits where space is genuinely fixed remove most of the guesswork, and teams that comment keys as they create them rarely face translator queries later.
Terminology and style: one voice in every language
An interface is a small vocabulary used thousands of times. If “workspace” is translated three ways across the app, the help centre and the onboarding emails, users assume they are three different things. A glossary of product terms, with the approved translation per language and a note on terms that stay in English, prevents that drift. Our article on keeping technical terminology consistent across translators and suppliers explains how to build such a glossary and keep it maintained.
Style matters as much. Does the interface address users formally or informally? Are button labels verbs or nouns? How are error messages phrased? A short translation style guide per language answers these questions once, for every translator and reviewer. For larger product families, a structured terminology management service turns the glossary into a maintained term base that every supplier and internal team can use.
Translation and revision
With files, context and terminology in place, translation is the most predictable step. Native linguists who know software conventions translate the new and changed strings, approved translations from the memory are reused wherever the source has not changed, and a second linguist checks each translation against the source for meaning, terminology, placeholders and length.
Machine translation has a place, particularly for large help centres, knowledge bases and documentation updates. It works best on your own glossary and approved memory, with a qualified linguist post-editing the output. Interface strings are short, ambiguous and visible on every screen, so they usually need a human translator from the start. Our machine translation post-editing services page explains how we decide which content is suitable.
Pseudo-localization and in-context linguistic QA
Two kinds of testing protect a localized release, and they find different problems.
Pseudo-localization runs before translation and tests the code, not the language. A script replaces every source string with a lengthened, accented version wrapped in markers, so “Save changes” might become [Šåvé çhåñgéš !!!]. Clicking through that build shows at a glance which text is hard-coded (it stays in plain English), which labels truncate (the closing marker disappears) and which characters break. It costs little, needs no translators and catches the bugs that are most expensive to find in ten languages at once.
In-context linguistic QA runs after translation, on a build or staging environment with the real strings. A linguist or in-market reviewer works through the main user journeys and checks what no file-based review can see: whether a translation fits its context, whether text is cut off, whether dates and numbers display correctly and whether each term is the same on every screen. Fixes go into the translation memory, not only into the build, so they do not reappear next release.
For a first launch, do both in every language; for routine releases, automated checks plus in-context review of new features usually suffice.
Continuous localization for frequent releases
Products that ship every week or two cannot localize in occasional large batches; by the time a batch comes back, the source has changed again. Continuous localization replaces the batch with a steady flow: new and changed strings are picked up at each release and translated while the sprint is still running, so every language ships with the source rather than weeks behind it.
That depends less on speed than on discipline. Strings should be marked as stable before they go to translation, otherwise the same text is translated three times while the wording settles. Context must travel with each batch, because the translator did not see your feature demo. Terminology decisions need an owner who answers quickly, and the memory must be updated with every delivery.
The payoff is real: small batches are easier to review, errors are corrected before they spread, and each release costs only what actually changed. This is where most software localization best practices converge: localize little and often, with context, on one memory and one glossary.
Keeping the interface, help and documentation consistent
Users do not distinguish between the interface and the documentation. If the button says one thing and the help article another, they lose trust in both. Yet these texts are often written by different teams, in different formats, on different schedules, sometimes by different suppliers.
The fix is to treat them as one body of content. The same glossary and translation memory should serve the interface, help centre, release notes, API documentation and, for manufacturers, the user manual. Manuals and installation guides that accompany a software product follow the same logic as the rest of your technical translation: they should reuse the interface terminology, not reinvent it.
If your existing translations live in old files rather than in a memory, they can still be recovered. Translation memory alignment pairs earlier translations with their sources so that approved wording is reusable from the first release with a new provider.
What drives the cost of software localization
Software localization is usually quoted per word, but the rate explains less of the final cost than most buyers expect. These factors move the number.
New versus repeated text. Strings already approved in the memory, or repeated across the product, cost far less to process than new text, with partial matches in between. On a mature product most of each release is reuse; on a first launch almost everything is new.
Memory leverage. A provider that starts from your existing memory charges for what is genuinely new; one that cannot use it charges for everything again. That is why owning your translation memory matters as much as the rate.
Number of languages. Cost scales almost linearly with languages, so check whether every component really needs every language.
Release frequency and batch size. Each batch carries fixed effort for file handling, checks and project management. Regular, planned batches are efficient; strings sent one at a time are not.
Context, file quality and testing scope. Clean files with comments and screenshots are translated faster and with fewer queries. Missing context is paid for twice, once in queries and again in fixes after testing. In-context QA and in-market review add effort that should be planned, not discovered.
A simple example shows why leverage dominates. Suppose a release changes 2,000 words of interface text: 1,200 new, 500 partial matches and 300 already in the memory. Across ten languages that is 12,000 new words to translate, 5,000 to adjust and 3,000 to check, not 20,000 translated from scratch. A provider that reports this split for every delivery makes each release’s cost explainable.
Common pitfalls and what they cost
Translating before strings are stable. Text still being rewritten is translated, retranslated and changed again, and each round is paid for.
Sending strings without context. Ambiguous labels are guessed, the guesses look plausible, and customers find the errors before testers do.
Letting each supplier keep its own memory. When you change provider, or the app and the manual go to different suppliers, approved wording is lost and terminology diverges.
What to send your provider, and how to choose one
A complete brief, often called a localization kit, lets a provider quote accurately and start without a round of questions. For a software release it should contain:
- the resource files, with new and changed strings identified, plus any help or documentation in scope;
- target languages and locales, and which components each one needs;
- context: screenshots or access to a test build, string comments and character limits;
- your glossary, style guide and existing translation memory, if you have them;
- the release schedule, batch frequency and who answers questions on your side.
When you compare providers, ask questions that reveal how they work. Can they process your file formats natively and return them without broken keys or placeholders? What automated checks run before delivery? Is every translation revised by a second qualified linguist? Will they start from your existing memory, can you export it at any time, and how do they report what was new and what was reused? Our guide to choosing a technical translation company adds further questions, and our checklist on how to check a supplier’s quality before you hire them explains what evidence to ask for.
How DEMA Solutions handles software localization
Our software localization services are built for product teams that release continuously. New and changed strings are translated per release, matched to your sprint cadence rather than batched into occasional large projects. JSON, XML and other resource files are returned in their original structure, without manual extraction and without broken keys, and automated checks look for damaged variables, truncated strings and formatting errors before anything reaches a release build.
Translators are native technical linguists who work with software and developer terminology, and the process is ISO 17100 certified, with a second qualified linguist revising every translation, as described on our quality page. Your engineers and product managers can review directly in the translation environment rather than in exported spreadsheets, so corrections reach the memory immediately. The memory and glossaries stay yours, exportable at any time in portable formats such as TMX and TBX, and leverage reporting shows how much of each release was reused. Our teams in Italy, Serbia and Spain also handle help content, API documentation, release notes and manuals, with an in-house DTP team for layout formats, so interface and documents share one terminology.
Where TUBE fits
For products that release continuously, TUBE is our solution for keeping each localization cycle under your control. Your glossary and translation memory control machine translation, every approved translation goes into a memory you own and can export, and leverage reporting shows how much of each update comes from text you have already approved.
Frequently asked questions
Internationalize the code, extract strings, run pseudo-localization, prepare context, agree terminology and style, translate and revise, test the translated build in context, then release and feed corrections back into the translation memory. With frequent releases, the cycle repeats on new and changed strings only.
Internationalization makes the product ready for any language: externalized strings, plural support, locale-aware formats and flexible layouts. Localization adapts it to a specific language and market, including translation and testing. The first is done once and maintained; the second is repeated for every language and release.
The one your build system produces reliably and that keeps keys, placeholders and context intact. XLIFF is the most robust exchange format; JSON, RESX, PO and platform string files work well when placeholders are consistent and context is supplied.
It replaces source strings with lengthened, accented text in visible markers, so hard-coded text, truncation and encoding problems show up before real translation starts. Use it before the first languages and whenever large new features are added.
It depends on how much text is genuinely new, how much can be reused from a translation memory, the number of languages, release frequency and testing scope. Ask for quotes that show new, partially matched and reused text separately, so you can compare providers on the same basis.
It can support larger, repetitive content such as help centres and documentation, when it runs on an approved glossary and memory and a qualified linguist post-edits the output. Short interface strings are ambiguous and highly visible, so they generally need a human translator and a reviewer.
Mark strings as stable before translation, send only new and changed strings with context, keep one memory and glossary for all content, and agree a fixed turnaround per batch with your provider.
Plan your next multilingual release
If you are preparing a first localized release, or your current process struggles to keep up with your sprints, tell us about your product, file formats and target languages. We will look at your files and propose a localization workflow that fits your release cycle.
How can we help?
Tell us what you need and we’ll get back to you with the solutions.