Making a game work in another language involves considerably more than translating the words.
Text expansion
The same sentence occupying very different space across languages.
Which breaks user interfaces designed around one language.
Context
Translators working from spreadsheets without seeing where lines appear.
Which is the single largest cause of poor localisation.
Cultural adaptation
References, humour and imagery that do not travel.
Voice recording
Lip sync, timing and casting in each language.
Which multiplies cost substantially.
Why context is the whole problem
A translator handed a spreadsheet row containing a single word has no way of knowing whether it is a button label, a character's exclamation or an item name.
Which is how a large proportion of localisation errors happen, and it is a process failure rather than a translator failure.
Studios that supply screenshots, character notes and situational context get noticeably better results, and it costs almost nothing to do.
Gendered and inflected languages
Text assembled from parts breaking in languages with grammatical gender or cases.
Which requires design accommodation rather than translation skill.
Right to left languages
Interface layouts needing mirroring.
Which is substantial engineering work.
Regional compliance
Content restrictions varying by market.
Which can require asset changes.
Community translations
Fan efforts filling gaps for languages studios skip.
Where it goes wrong most often
Text baked into images, interfaces sized for English, string concatenation that assumes English grammar, and translation delivered without context.
Which are all engineering decisions made early that determine how expensive localisation becomes later.
Teams that build with localisation in mind from the start spend a fraction of what teams retrofitting it do.
Which languages get done
Decided by market size and expected return.
Which leaves some large linguistic communities poorly served.
Voice against text only
Subtitled localisation as a much cheaper option.
Which many games use for secondary markets.
Quality variation
Budget and process determining outcome more than translator skill.
Post-release fixes
Corrections shipped in patches after community reports.
Why it is worth doing properly
A poor localisation does not just read badly; it makes a game feel cheap, generates negative reviews in that market, and is remembered long after it has been patched.
Which is a disproportionate reputational cost for a line item that is small relative to development.
Several games with strong reputations elsewhere have performed poorly in specific markets for exactly this reason.
Working with localisation vendors
Providing glossaries, style guides and character references.
Which is the difference between a competent result and a good one.
In-game text volume
Role-playing games running to hundreds of thousands of words.
Which makes the exercise comparable to translating several novels.
Testing in language
Native speakers playing the localised build.
Which catches what a spreadsheet review cannot.
Where to learn about it
Localisation professionals write and speak about this publicly.
A note on how this industry reports itself
Games is an unusually opaque business for one with such a visible product. Budgets are rarely disclosed, sales figures are announced selectively, player numbers are quoted in whichever metric flatters, and profitability is almost never stated at all.
Most of what is publicly known comes from court filings, leaked documents, regulatory submissions and former employees speaking after the fact. That material is reliable when it exists and covers a small fraction of the industry, which means any general claim about how games perform commercially rests on a limited and non-random sample.
Why the production side is worth understanding
A great deal of frustration with games comes from decisions that look inexplicable from outside and are entirely predictable once the structure is visible. Why a game shipped unfinished, why a beloved studio was closed after a successful release, why a sequel dropped features the previous game had, why a service shut down two years in.
None of these are mysteries. They are the outcomes of funding structures, platform economics, portfolio decisions and the fact that games are made by people working to schedules set before anyone knew what the game would be. Knowing that does not make the outcomes better; it does make them legible.
Where the better information is
Developer conference archives are the single best public source on how games are actually made, and a large number of talks are freely available. Regulatory filings during acquisitions have disclosed more real financial detail than a decade of press releases. Trade publications with named industry sources are considerably more informative than consumer coverage on business questions.
One thing worth remembering
Games are made by people, mostly people who care a great deal about them, working inside commercial structures they did not design and frequently cannot change.
Criticism of a game is fair. Criticism of the decisions behind it is usually aimed at the wrong floor of the building, and the people who take it are rarely the people who made them.
Further reading
Developer conference archives, postmortems written by the people who shipped the projects, and trade reporting with named industry sources are the three places where this material is covered properly and in public. All three are freely available, and none require any technical background to follow.