Localisation (localisation strategy): what localisation is for a software product, the UK term for the discipline, and how a team decides which locales to ship

Localisation, spelt with an s in the United Kingdom and a z in the United States, is the discipline of adapting a software product for each locale it ships in: the strings translated, the plurals and formats made right for the language, the layouts made to fit, and the locale build tested before release. Localisation strategy is the set of decisions a team makes before any of that happens, which locales to ship, in what order, with what memory and what vendor, and at what cost per release. This page sets out what localisation is for the team that owns the strings, how a localisation strategy is argued from the figures rather than from a wish list, and where the free worksheets on this site fit.

Localisation is the release loop, not the first translation

A product is localised once when the first locale ships and then again every release, because every release changes strings. The discipline is therefore a loop: freeze the strings, cost the release against the translation memory, hand off the XLIFF, read the translations back against their keys, test the locale build and ship at the threshold. A team that treats localisation as the first translation discovers the loop at the second release, usually as an English string in the German build.

Localisation strategy is argued from three figures

Which locales to ship, and in what order, is decided by the demand in each market, the cost per release for that locale and the quality bar the team can hold in it. The first is the market's figure; the second is the word count times the effective rate after the memory's leverage, which the translation memory leverage sheet on this site works from your own figures; the third is the defect rate per locale the localization testing checklist returns. A strategy that names locales without those three figures beside each is a wish list.

What the strategy has to keep to survive the next release

The catalog with every key and its translation per locale, the memory in an open format so the leverage is the team's, and the handoff generated from the record. With those a locale added this quarter is costed from the memory next quarter; without them each release is costed from scratch and the strategy is only as good as the last spreadsheet. Xlifflane Pro keeps the three as one record.

Questions people ask about localisation

Is localisation different from localization?

Only in spelling: British English writes localisation and American English localization, and the discipline is the same. This site uses both because the teams it is written for do.

What comes first, localisation or internationalisation?

Internationalisation: the engineering that puts every string in a catalog, formats by locale and lets layouts stretch. Localisation is doing each locale on that foundation, and a product that was not internationalised cannot be localised without a rewrite.

How does a team choose its first locale?

By the market's demand against the cost per release and the quality it can hold. A locale with a good memory and a reviewer on the team is cheap and safe; one with neither is neither, whatever the market says.

Sources

Related answers

Start Xlifflane ProKeep the string catalog, not the spreadsheet of strings