Preparing a localization kit: what to send before you send the text

A localization kit — often shortened to lockit in the industry — is the bundle of material a team sends alongside the text itself when handing work to a translator, studio, or agency. It exists because the text file alone is never enough: a spreadsheet of strings tells a translator what to translate, not how to translate it correctly for the game it lives in.

A well-built kit answers the questions a translator would otherwise have to ask, one email at a time, spread across the whole project. The cost of building it once is consistently lower than the cost of answering the same questions repeatedly, string by string, as they come up.

What belongs in a kit

Each item in the list below exists to prevent a specific, predictable failure mode — that is the test for whether something belongs in the kit at all.

• The text files themselves, in the format the translator will actually work in, with stable keys so nothing gets matched by guesswork
• A glossary — the fixed terms (item names, character names, faction names, mechanics terminology) that must translate consistently everywhere, preventing the same term from drifting across files or across translators
• A style guide — tone, formality level, register per character or per UI area, so the whole text reads as one voice rather than a patchwork of individual translators' defaults
• Character notes — who each speaking character is, their personality and relationships, so dialogue lands with the right tone even without full scene context for every line
• Screenshots or video of the UI and key scenes, so a translator can see where and how a string actually appears rather than imagining it
• Placeholder documentation — what each token expands to and its grammatical role, prepared once instead of answered per string
• A do-not-translate list — proper nouns, brand terms, or UI elements that must stay in the source language, so a translator does not have to guess which strings are exceptions
• A deadline and word-count summary, so the translator or agency can plan capacity honestly instead of discovering scope partway through
• A Q&A contact — a named person or channel for questions that the kit did not anticipate, because no kit anticipates everything

A short example

A glossary entry does not need to be elaborate to prevent drift — it needs to be unambiguous and easy to check against while translating:

term: "Ember Blade"
type: item name, do-not-translate-as-generic
ja: エンバーブレード (do not translate to 「燃える刃」 or similar)
note: proper noun; used in item tooltip, quest text, and NPC dialogue

A good kit answers questions before they are asked

The value of a kit is front-loading. Every question a translator would otherwise ask mid-project — what does this character sound like, is this name translatable, how long can this button label be — has an answer sitting in the kit instead of waiting in an inbox. That does not eliminate questions entirely; it removes the predictable ones, leaving the Q&A channel for genuinely novel cases the kit could not have anticipated.

The practical effect shows up in review, not just in the translation itself: fewer strings come back inconsistent with each other, fewer need a second pass for tone, and the first draft is closer to final because the translator was working with the same information the original writer had.

Building it once, reusing it

A kit is not a one-time document written for a single handoff — the glossary and style guide in particular should be treated as living references that carry forward to every future update, expansion, or new language added to the project. Teams that rebuild context from scratch for every batch of text are paying the cost of an incomplete kit over and over, one project at a time.