Translation and localization

What this category covers

Translating a product and keeping every language in step: string management, translation memory, glossaries, machine translation, review workflow and the connections to code and content systems.

Two jobs sit here. Translating an interface, where the unit is a string with context and constraints. Translating content, where the unit is a page and tone matters as much as accuracy.

Content authoring belongs in CMS and blogging, and drafting with a model sits in AI writing.

Strings, keys and the source of truth

Interface localization succeeds or fails on how strings are managed.

A string needs a stable key, the source text, a note explaining where it appears, and a limit if the space is fixed. Without context, translators guess, and a word that is a verb in one place becomes a noun in another.

Ask how the platform handles plurals, gendered forms and variables inside a sentence. Those are where naive systems produce output that reads as machine-generated even when a human wrote it.

Then ask how strings arrive. A connection to your repository or content system, with new text appearing automatically and translations returning without a copy-and-paste step, is what keeps languages from drifting apart.

Memory and glossaries, which is where the savings are

Translation memory stores approved translations and reuses them when the same sentence appears again.

The benefit compounds. A product updated frequently retranslates only what changed, and the wording stays consistent across releases. Confirm that the memory is yours, exportable in a standard format, and not held hostage when you change supplier.

A glossary does the same job for terminology. Product names, feature names and words with a specific meaning in your domain need one agreed translation per language, decided once rather than reinvented by each translator.

Machine translation and human review

• Machine first, human review, the common arrangement for volume.
• Human translation for marketing, legal and anything customer-facing at high value.
• Post-editing rates, cheaper than translation from scratch and priced differently.
• Quality checks, automated for placeholders, numbers and length.
• In-context review, so a translator sees the screen rather than a spreadsheet row.

Raw machine output published without review is the standard way a product embarrasses itself in a language nobody on the team reads. The errors are not random: terminology, tone and cultural specifics are where it fails, and those are exactly the parts customers notice.

Testing, layout and the things that break

Translated text behaves differently from the original.

Expansion is the first problem. Text can grow by a third or more in some languages, and interfaces designed around English wording break quietly. Contraction causes its own layout oddities.

Then there are formats: dates, numbers, currency, address order, name order, and sorting rules that differ by language. Right-to-left scripts need layout support rather than a translated string.

Test with real translated content early. Placeholder text of uniform length hides every one of these problems until release.

Cost, coverage and what to translate

Pricing runs by hosted words or keys, by seats, by project, or a mixture, and each additional language multiplies rather than adds.

That arithmetic should shape scope. Interface strings and high-demand pages usually justify translation. An archive of old material usually does not, and translating everything by default is how localization budgets disappear without a corresponding increase in traffic.

Check search visibility handling as well, since translated pages need correct language annotation and stable addresses to be found at all. Related pricing habits across the market are set out in what pricing pages hide.

Deciding what to localize first

Translation budgets are finite, and spreading them evenly across everything is the least effective way to spend them.

Interface strings come first, because a product a person cannot operate in their own language will not be bought regardless of how good the marketing pages are.

Then the pages that carry intent: pricing, the main product description, the signup path, and whatever your analytics show people reading before they buy.

Support material follows, prioritised by the articles that actually get opened rather than by the order they were written.

Archived content usually never justifies the cost, and translating it by default is how a localization project spends a year producing pages nobody requested. Measure demand per language before extending scope. The second market rarely behaves like the first.