Software localization is the work of making a software product usable in a locale other than the one it was written in: translating its strings, giving each language the plural forms it needs, formatting dates, numbers and currencies the way the locale expects, fitting the longer text into the same screens, and proving with a locale build that all of it holds. Localization of software is distinct from translation, which is one field of it, and from internationalization, which is the engineering that makes localization possible at all. This page sets out what software localization is for the team that owns the string table, how localizing software runs through a release, and where the free worksheets on this site fit.
The four things a locale changes
A locale changes the text, which is the translation; the grammar, because a language may need three or six plural forms where English needs two; the formats, because dates, numbers, currencies and units are written differently and sort differently; and the layout, because German runs a third longer than English and Japanese needs different fonts and line breaks. Localization in software is the discipline of handling all four for every string in the catalog, in every locale the product ships in, on every release. A team that handles only the first ships a product that reads translated and behaves foreign.
How a release is localized
The strings that changed or were added since the last release are frozen and counted, and the release is costed from the translation memory's leverage, the share of those words the memory already holds. The handoff goes to the translator as XLIFF, one file per locale, and comes back to be read against the same keys. The locale build is then checked for untranslated strings, truncation, hardcoded text and plural or format failures against the team's ship threshold. The translation memory leverage sheet on this site works the first step and the localization testing checklist the last, with no account; Xlifflane Pro keeps the catalog, the memory and the handoff between them.
What the team has to keep to do it again next release
Localizing software once is a project; doing it every release is a record. The record is the string catalog, every key with its source text, its translation per locale and a status, the translation memory that makes the next release cheaper than the last, and the handoff generated from the catalog rather than assembled from files. A team that keeps the strings in resource files, the translations in the translator's folder and the status in a spreadsheet does the reconciliation by hand every sprint, which is where the English string in the German build comes from.
Questions people ask about what is software localization
Is software localization the same as translation?
No. Translation renders a string in another language; localization is the whole of adapting the product for the locale, the plurals, formats, layouts and tests included. Translation is one field in the localization record.
What is the difference between localization and internationalization?
Internationalization, i18n, is the engineering that makes a product localizable: strings in a catalog rather than in code, locale-aware formatting, layouts that stretch. Localization, l10n, is doing it for each locale. The first is done once; the second every release.
Where should a team start localizing software?
With the catalog: every string out of the code and into a keyed catalog with a source text, then a pseudo-locale build to find what was missed. The cost of the first locale follows from the word count, and the leverage sheet on this site works it from your own figures.
Sources
- W3C Internationalization, Localization vs. Internationalization: what each term covers and why the second has to come first
- OASIS, XLIFF Version 2.1: the XML Localisation Interchange File Format the handoff is generated in
- Microsoft Learn, Pseudolocalization: padding and accenting catalog strings to expose truncation and hardcoded text