A mid-sized software company translates its product into six languages, ships the release, and waits. Three months later the numbers are flat everywhere except Germany, where support tickets have doubled. The strings were all translated correctly. What went wrong was everything around them: a date field that read the wrong way round, an address form that refused German postcodes, and a checkout that quoted prices in dollars with a euro symbol bolted on.
That gap is the reason localization services exist as a category separate from translation. Translation handles the words. Localization handles the product the words live inside, and the second job is usually the larger one.
What Localization Services Actually Cover
A serious localization brief starts with an inventory rather than a word count. Someone goes through the product and marks every element that carries an assumption about the user: how dates and times are written, how numbers are punctuated, which currency and tax display applies, how names and addresses are structured, how lists are sorted, which paper size a printed document assumes, which images contain culturally specific content, and which legal notices change per jurisdiction.
Only then does anyone translate. Working the other way round, which is what happens when a spreadsheet of strings is emailed to an agency, produces exactly the release described above. The standards side of this is unusually well documented, and the W3C's internationalization guidance is the reference most engineering teams should have read before writing a single translatable string.
The Layer Underneath the Words
Text expansion is the classic trap. German runs roughly thirty percent longer than English, Finnish can run further, and a button sized to fit Submit will not fit its German equivalent. Arabic and Hebrew reverse the entire interface, including icons that imply direction and progress bars that fill the other way. Japanese and Chinese need line-breaking rules that Latin-script layout engines get wrong by default.
Then there is sorting. A list that looks alphabetical in English falls apart in Swedish, where three extra letters sit after Z rather than among the vowels they resemble. None of this is translation work. It is engineering work that only becomes visible once a translator has been anywhere near the product, which is why the two disciplines are contracted together. The general shape of the field is set out clearly in the overview of language localisation.
Website Localization Is Half a Marketing Job
For a website the calculation changes again, because a localized page that nobody finds has achieved nothing. Website localization has to account for how the target market actually searches, which is rarely a direct translation of how the home market searches. Keyword demand, competitor pages and the format Google chooses to rank all shift by country, and an international seo strategy that skips fresh research in each language usually produces beautifully worded pages sitting on page four.
The practical consequence is that not every page deserves localizing. Translating the twenty pages that already earn traffic, with proper research behind them, beats translating four hundred pages nobody was looking for.
Localization goes beyond swapping words because it has to account for formats, expectations and the way a market actually reads. Handling that at scale means routing files, chasing reviewers and tracking versions, which is where most language teams lose their evenings. A growing number of agencies now push that coordination onto ai automation so their linguists spend their time on judgement calls instead of admin.
Apps and Games Break in Their Own Ways
App localization services deal with a constraint that web work does not: store metadata. Titles, subtitles and keyword fields are ranking surfaces with hard character limits, and they are frequently left in English long after the app itself has been localized. Screenshots are another blind spot, since a store listing showing English interface shots undermines every claim the translated description makes.
Game localization services sit at the far end of the spectrum. Dialogue has to fit voice timing, humour has to survive, names and puns often need reinvention rather than translation, and age rating boards in different territories react to different content. A line rendered accurately but two seconds too long for the animation is a defect, not a translation choice.
Where Transcreation Takes Over
At some point on this scale, faithfulness to the source stops being useful. Marketing copy, taglines and campaign concepts are built to produce a reaction in a specific audience, and reproducing the words reliably fails to reproduce the reaction. That is the territory of transcreation, where the brief is the intended effect rather than the original sentence. PoliLingua's piece on why marketing translation fails and transcreation fixes it is a good primer on where that line sits and how to brief for it.
Scoping the Work Without Overbuying
The most common mistake is treating every market as identical. Start with one, ideally the one where you already see unexplained traffic or sign-ups. Localize the product surfaces a user cannot avoid (onboarding, checkout, error messages, support content) before touching the marketing site. Fix the technical layer once, because text expansion and date formatting are solved permanently or not at all.
And ask any prospective supplier a single diagnostic question: what do they do when a source string is ambiguous. A vendor who says they make a sensible choice is selling translation. A vendor who says they raise a query and hold the string is selling localization, and the difference between those two answers is worth more than any per-word rate.