Game localization is software localization with three complications: the strings carry far more context, because a line of dialogue, an item name and a menu label need different treatment from the same translator; the volume is larger and arrives in bursts, at a milestone rather than a sprint; and the locale build has to be played, not just viewed, because a truncated string in a dialogue box breaks the scene. Video game localization is done by studios of every size, and localizing games well on a small team comes down to the same record a SaaS keeps, the catalog, the memory and the handoff, with the context carried alongside the string. This page sets out what games localization keeps, how a milestone is costed and handed off, and where the free worksheets on this site fit.
The catalog carries context, or the translation is wrong
A string in a game is rarely just a string: the same word is an item, a verb and a menu label, and the translator needs to know which, who says it, to whom, and how long the box is. Game localization keeps that context against the key, speaker, scene, character limit, so that the handoff carries it and the translation comes back fitting the box and the character. A catalog that holds only the source text is where the mistranslated item name and the truncated dialogue line come from, and the pseudo-locale build the localization testing checklist counts is where they are found before a player does.
A milestone is costed from the memory like any release
Localizing games arrives in bursts, the vertical slice, the beta, the launch, the patch, and each burst is a release: the changed and added strings frozen and counted, and the memory's leverage read before the vendor quotes. A studio with several titles builds a memory that carries across them, so the second title's menus and system messages cost a fraction of the first's. The translation memory leverage sheet on this site works the milestone's cost per locale and the leverage from your own figures, with no account.
The locale build is played, and the defects are counted
A video game localization is tested by playing the locale build: the text has to fit the boxes, the plurals have to be right in every language, the placeholders have to render, and the fonts have to carry every script the locales use. The defects are the same four the checklist counts, untranslated, truncated, hardcoded and format, and the ship threshold per locale is the studio's own. Xlifflane Pro keeps the results against the locale and the milestone so the patch starts from a known catalog rather than a bug list.
Questions people ask about game localization
Is game localization different from app localization?
In degree rather than kind: more strings, more context per string, bigger bursts and a locale build that has to be played. The record is the same, the catalog, the memory and the handoff, with the context fields carried.
How does a studio handle character limits per locale?
As a field on the key, carried in the handoff so the translator sees the box size, and as a check in the locale build. A limit the translator never saw is a truncation the player finds.
Does a memory carry across games?
Yes, and it is one of the larger savings a studio has: system messages, menus, settings and store text repeat across titles, and a memory kept by the studio rather than the vendor leverages them on the next title.