Every patch,
in every language.

A game string rarely arrives with its context. “Charge” could be a battery, a cavalry attack or a price. It may contain variables like {playerName} or markup that must survive translation, a plural that German and Polish handle differently, a gendered form that depends on the player’s choice, and a button that holds twelve characters. Generic machine translation fails on exactly these, and the failures surface as crashes, overflowing UI or jokes that no longer land.

So the system translates with context: the speaker, the scene, a screenshot where you have one, your glossary of names and terms, and the character’s voice from earlier approved lines. It then runs mechanical checks that machines are reliably good at, such as placeholder and tag integrity, length against UI limits and glossary consistency, before a human translator sees the string.

It works where your localisation team already works: string tables exported from Unity or Unreal, XLIFF or JSON files, and translation management systems like Crowdin, Lokalise, Phrase or memoQ, with translation memory respected and updated.

We measure against your own shipped translations. A held-out sample of approved strings is translated blind and scored by your linguists for accuracy, fluency and voice, alongside a count of how much each draft needed editing. That decides, per language and per content type, whether AI drafting saves time at all; in some pairs and some genres it will not, and we would rather know before rollout.

Voice is a separate decision. Synthetic voice for localised dialogue involves performer consent and agreement terms, and we treat it as out of scope unless your team has those settled.