How to Build a Loc Kit Translators Can Actually Use

Core summary of an ideal Loc Kit

1) Recommended column schema

Keep the same column layout across every sheet/tab (UI, Dialogue, System). Even on a UI sheet with no speaker data, leave the speaker column empty — do not delete it.

String IDs are required later when you merge translations back into the game. Lines with order — dialogue, narration, sequential copy — must follow in-game output order. Dialogue often branches, so use Next_String_ID (or an equivalent marker) to show which line follows after each branch.

2) A 10-second Loc Kit checklist

Before you hand the file to a translator or agency, check these seven items:

Universal format: Can someone open it without a paid specialty tool?
Cover / README tab: Are global rules included (tone, tag rules, contact path)?
Chronological order: Is dialogue sorted in real in-game output order?
Unified column schema: Do all tabs share the same columns (Source, Target, ID, etc.)?
UI / ambiguous words: Do short strings like Play or Save carry a Context label?
Speaker marked: Is Speaker filled on dialogue lines?
Tags & variables preserved: Do codes like {0} and <Color> remain inside the Source cell?

The first job in game localization is extracting in-game source text into a workable file. For that file to function as a real localization kit (Loc Kit), you need to know what a Loc Kit is — and how to build one so localization specialists can work efficiently.

This article lays out a practical Loc Kit baseline that studios, agencies, and community teams can share regardless of which localization tools they use. There is no single required format — Google Sheets, Excel, or CSV can all work. What decides whether a Loc Kit is good is whether it is structured so each line’s output context is readable. This feature walks through what that structure looks like in practice.

What a Loc Kit is for

A Loc Kit is a working table of translatable strings plus the metadata needed to translate them correctly. Freelancers and localization teams use different CAT (Computer-Assisted Translation) tools and pipelines, so a universal format anyone can open is the safer default. It is also common to keep everything in one spreadsheet document so people do not have to bounce between many files. (This article assumes a spreadsheet-style Loc Kit.)

Translation happens row by row, but meaning is not finished inside a single row. What a line means depends on the scene where it appears, whether it is UI or dialogue, who is speaking and listening, and what comes before and after. A short example: in one Loc Kit, Back arrived with no extra context, so the translator rendered it as a UI “go back” action — when in-game it meant the equipment slot on a character’s back. In dialogue, missing speaker or addressee often lets tone and nuance drift. Even a short line like Hey can go in different directions depending on who says it to whom, and in what situation — which is why output order and readable context matter.

How to build each column

A Loc Kit should present its data clearly, with each kind of information living in its own spreadsheet column.

At minimum you need Source and Target. Target is empty before localization work begins; the other columns exist to raise the quality of what fills that blank. One rule is non-negotiable: every line must stay in chronological order — real output / reading order. When dialogue branches, mark what follows after each branch using line numbers or similar identifiers. If a source sentence is split across multiple strings, those fragments must stay contiguous in time order. (If you care about multilingual support, splitting one sentence across strings is better avoided from the start.) When one unit is scattered across the Loc Kit, sentence-level translation becomes impossible. A Loc Kit with no readable output order cannot be translated properly by anyone; translators end up jumping between corrections and in-game checks, which raises cost and lowers quality.
Beyond Source and Target, a few columns almost always earn their keep. Row Key / String_ID identifies each row. When file, scene, or quest cues live in the key, translators can often infer context from the ID alone without opening a build.
For dialogue files, a Speaker column improves quality a great deal. Some teams split each character onto a separate sheet. Even then, if a scene has two or more NPCs, keep the other speakers’ lines on that same sheet — it helps translation quality far more than isolating one voice.
A Context column, filled when needed, also helps. Useful notes include a short situation blurb at the start of a dialogue chunk, a reminder that a line is UI (often the sheet name is enough for that), or — in games with character portraits — the expression set when the line plays.
Helpful extras include Addressee, scene notes, and Max length when a string has a byte/character cap (that reduces later LQA effort). Utterance type (monologue, thought, conversation, and so on) also helps. Addressee can often be inferred when order is solid and Speaker is filled, so it is sometimes optional — but if three or more people share a scene, or branching makes roles easy to confuse, fill it when you can.
Put global rules and useful links on the cover sheet or README. Tag / variable preservation rules must be explicit. Tone, honorifics, banned terms, terminology and lore, a contact channel, and a short “how to read this Loc Kit” note are strong additions.

Once you know this structure, you also know what to avoid: putting non-source information in the Source column, shipping a Loc Kit with no headers, or sorting lines by filename or alphabet. That last pattern is especially common when the extraction pipeline is weak.

Many sheets are fine — mismatched structure is not

Working Loc Kits often have multiple sheets in one file. One sheet is nicer when possible, but multiple sheets are not a problem by themselves. Changing the column layout sheet by sheet usually is. Keep the same column structure across every sheet; leave unused cells empty, but keep the columns. An empty Speaker column on a UI sheet is better than a missing one. Freeze one template per project. Different columns per sheet create avoidable work in CAT migration, QA, and handoff.

Game translation often uses CAT tools to protect placeholders/tags and terminology consistency. Design the Loc Kit so Source and Target map cleanly for that workflow. Keep one Source–Target structure throughout the file. If the kit is multilingual, give each language the same Target column layout across every sheet.

Context as a label, not a novel

Unless more detail is truly needed, keep Context short. Simple labels like UI or Setting are often enough. Add thicker notes only when a string can be read more than one way.

Dialogue needs a little more care. At the start of each dialogue chunk, note what is happening, and briefly mark when — or under what condition — each line fires. When lines are in time order and chunk notes are present, translators can often follow the flow without launching the game.

Fill Speaker, and put a one-line voice summary for each character on the cover. Addressee helps a lot when localizing into languages with speech hierarchy (Korean, Japanese, Russian, and others).

A good Loc Kit shows in the cover and headers

Put together, a well-built Loc Kit usually has these traits: (1) it is shared in a universal format, (2) the cover carries global guidance, (3) every sheet uses the same structure, (4) dialogue follows in-game output order and marks where each branch continues, with split sentences kept together, (5) String IDs are present, (6) short or ambiguous UI has Context, (7) dialogue chunks open with a situation note, (8) Speaker is present so character voice stays consistent, and (9) tag, variable, and length rules are documented.

Weak Loc Kits show the opposite patterns: output order ignored, keys or context accidentally sitting in Source, mismatched sheet structures, missing tags or placeholders (which can crash the game on reimport or break intended display). Among these, chronological collapse is the most common extraction failure — and a leading cause of mistranslation.

Loc Kit quality sets the ceiling on localization quality

A good Loc Kit is more than extracted strings in one file. It is a context blueprint that lets translators work without staring at the screen — seeing where a string appears and what surrounds it. Keep in mind that Loc Kit quality steers localization quality.

To put it plainly: Loc Kit quality sets the upper bound on localization quality. Meet the conditions above and you raise the ceiling of the final result — and you greatly reduce the chance that freelancers, translation teams, or agencies will say they cannot start without more context or extra resources.