Localisation is treated as translation and is a considerably broader process, most of which has to be planned for during development rather than added afterwards.
Internationalisation first
The engineering work that makes localisation possible.
Separating text from code, so that strings can be replaced without touching logic.
Supporting variable text lengths, since translations differ substantially in length — some languages expand considerably over English.
Supporting different character sets and text directions.
Handling grammatical structures that differ, particularly where sentences are assembled from fragments, which frequently breaks in languages with gendered nouns or different word order.
Retrofitting this is expensive, which is why localisation decisions are effectively made at the start whether or not anyone realises it.
The string assembly problem
The most common technical failure.
Building a sentence by concatenating fragments works in one language and produces nonsense in others.
Which means every dynamic sentence must be structured as a template with substitution points, and translators must be able to reorder those points.
Games that assembled text without this produce the characteristic broken grammar that players notice immediately.
Context
Translators working from a spreadsheet of strings without knowing where they appear produce errors that are unavoidable.
A single word can be a verb or a noun, and the correct translation differs.
Which is why providing context — screenshots, character information, notes on tone — measurably improves output, and why it is frequently omitted under schedule pressure.
Culturalisation
Beyond language, adapting content for different markets.
Gestures, colours, symbols and references carry different meanings, and some carry legal risk.
Content restrictions vary by market — depictions of certain symbols, blood, gambling mechanics and other elements are regulated differently.
Which means some markets require content changes rather than only translation, and those changes must be built as options rather than as forks.
Age ratings
Different rating bodies apply different criteria, and a rating in one region does not transfer.
Which requires separate submissions and can require content adjustment to achieve a target rating in a specific market.
Ratings affect where a game can be sold and advertised, which makes this commercially significant rather than procedural.
Voice
Recording in additional languages requires casting, direction and studios in each, and it must wait until the script is final.
Lip synchronisation is a further problem, with approaches ranging from accepting mismatch, to generic mouth movement, to per-language animation.
Which is why many games ship with subtitled rather than dubbed audio in most languages, and full voice localisation is reserved for the largest markets.
Testing
Linguistic testing checks that translations appear correctly in context, which catches truncation, overflow, wrong strings in wrong places and untranslated fragments.
It requires playing the game in each language, which is a substantial time cost and is frequently the first thing cut.
Which is why localisation problems visible within minutes of starting a game reach release.
For small teams
Community translation has produced good results for some games and requires management, review and a means of handling contributions.
Machine translation has improved substantially and remains unreliable for the register and context games require, and it is a reasonable starting point for a human editor rather than a substitute.
Regional storefronts and pricing
Beyond language, releasing in a market involves pricing decisions and platform requirements.
Regional pricing set to local purchasing power expands the addressable audience substantially, and it creates arbitrage that platforms restrict in various ways.
Store page text, screenshots and trailers all require localisation, and they are frequently forgotten because they sit outside the game build.
Fonts
A practical problem that catches small teams.
A font chosen for style may lack characters for target languages, particularly for scripts with large character sets.
Which means either licensing a font with broad coverage or accepting a different typeface in some languages, and the second is generally the pragmatic answer.
Update cadence
Games updated frequently must localise each update, which is an ongoing cost rather than a one-off.
Which is why some live games ship updates in fewer languages initially, and why translation pipelines are automated where possible.
Player-facing quality signals
Poor localisation is noticed immediately and affects reception disproportionately.
Which means a game with excellent design and bad translation is reviewed as a bad game in that market.
Reviewers in the affected language will say so, and the coverage persists after any later correction.
Right-to-left languages
Supporting these requires mirroring interface layout rather than only changing text direction.
Which affects menus, progress bars, icons implying direction and anything positional.
Engines vary in how much they support this automatically, and retrofitting it is substantial work.
Cost and sequencing
Localisation cost scales with word count, which makes text-heavy games disproportionately expensive to translate.
Launching in fewer languages and adding more if sales justify it is the standard approach for small teams, and it delays access rather than denying it.
Deciding target languages early affects font choice, interface layout and string handling, which is why the decision belongs at the start.