How Game Localization Works: A Guide for Indie Publishers

The Localization Workflow, Step by Step

How does a project start?

It starts with a request, not a contract. The client team sends us the project details—languages, volume, platform, deadlines—and we put together a quote. Once that quote is confirmed, pre-production begins right away.

That’s the whole first step. No lengthy onboarding, no separate discovery call required before pricing. To make that part easier, we’ve put together a full breakdown of typical localization rates and real project examples, so you always know roughly what to expect going in.

One thing worth doing well here: the more complete your request, the more accurate the quote. Target languages, approximate word or string count, file format, and platform go a long way toward a quote you won’t need to revise later.

What happens during pre-production?

This is the part clients rarely see, and it’s where a lot of the eventual quality gets decided.

Once a quote is confirmed, our team runs a pre-translation analysis (PTA) of the file, checking structure, formatting, repetitions, and anything technically tricky. Depending on the client and the project, this is sometimes also when we start building a glossary, ahead of the kick-off meeting rather than after it. We also pre-fill the project’s Style Guide, draft project-specific kick-off questions, and put together a dedicated team of linguists who fit the project—an MMO and a visual novel don’t need the same translators. Files get prepared for localization too, including custom QA settings.

Once all that’s done, a kick-off meeting gets scheduled.

Who needs to be in the kick-off meeting?

Four people, ideally: the person responsible for localization on the client’s team, a representative of the developers, and—on our side—the account manager or team lead plus the project manager.

The developer’s presence matters more than it might seem. They’re usually the only ones who know both the technical structure of the files and the creative vision behind the game’s narrative. Skip them, and you’ll end up answering the same questions twice, later, over email.

During the meeting, the team fills in the Style Guide with everything the localization team needs going forward—tone, terminology, and formatting decisions included. It becomes the reference point for the rest of the project.

Why does Style Guide confirmation get its own step?

Because developers and publishers don’t always have the same picture of a project, and it’s cheaper to catch that gap now than during production.

After the kick-off meeting, we send a follow-up message with the filled-in Style Guide to both the client’s team and the developers. Production only starts once both sides confirm it. It’s a short step, but skipping it—or rushing it—is one of the more common reasons a project needs reworking later.

What happens during production?

This is where translation happens—but it’s rarely a silent process.

How do you speed up localization for large volumes of text?

If you’re working with a genuinely large volume—the kind of scope you have with MMOs or narrative-heavy games—and speed matters as much as accuracy, standard production isn’t always the quickest path. That’s what run.loc is for: a hybrid workflow that combines machine translation with targeted human review. Linguists focus their attention on the segments that actually need it instead of re-reading everything from scratch. It’s how we localized 1.4 million words across four languages for Blue Protocol: Star Resonance in about a month. We’ve also written about how the run.loc workflow itself is structured, if you want to see how it fits together.

Building the Perfect Localization Kit (LocKit)

What is a LocKit?

The LocKit is the file—or set of files—with the actual text to be localized. It’s the single most useful thing you can hand a localization vendor, because everything downstream depends on how it’s built.

Which file formats work best?

We can work with most formats, but a few work best:

• Google Sheets or .xlsx. The most convenient overall, since they structure information clearly and make collaboration easy.
• .txt and .json. Both are workable, especially for structured game text exports.
• .po files, for teams working in Unreal Engine. As long as the file includes a key, source location, and context comments alongside the source and target text.

What makes a LocKit good, not just workable?

A few things separate a good LocKit from one that’s merely workable:

• Logical order beats alphabetical order. Strings should follow the order they appear in-game—lines from the same dialogue placed one after another—not sorted by ID or speaker.
• More context is always better. IDs, character limits, who’s speaking in a given line, comments on tone or setting—all of it helps linguists get things right the first time.
• Character limits belong in the LocKit itself, not discovered after the fact. If a string has a length restriction, flag it before localization starts. Fixing it afterward often means changing a term everywhere it appears in the game, since consistency matters to players.

What Reference Materials Help Most?

A playable build, more than anything else. Beyond that, the materials that consistently help linguists produce better localization are as follows:

• A list of in-game items with reference images
• A character guide—or “bible”—with images
• Art or reference images for locations
• A document describing the game’s lore
• A design document
• If strings are built from multiple parts, the logic behind how those composite rows combine

You don’t need all of these to see a difference—a build plus a character guide already removes a lot of guesswork. This matters most for the kind of games we work on most often for indie and mid-size publishers: large, text-heavy titles—MMOs, visual novels, and narrative-driven games where dialogue and lore carry the experience.

What Slows Down Localization Projects?

Rarely is it ever translation quality. It’s almost always communication. A few patterns come up often enough to call out directly:

• Leaving the Style Guide or glossary unconfirmed before production starts. This is the one behind most “that’s not what we meant” moments. The linguist wasn’t wrong—they just weren’t told. It could be a stylistic preference, a terminology choice, or something cosmetic, like whether emojis are allowed in the localized text. If it isn’t written down somewhere both sides agreed on, it isn’t a shared decision yet.
• Not sharing naming conventions for each platform. PlayStation, Xbox, Nintendo, and Steam each enforce their own terminology rules, and in most cases you can’t translate a term once and reuse it everywhere. That usually means duplicating strings and translating them differently per platform. Skip this, and you risk failing certification, not just an awkward translation. We’ve written more about how naming conventions work across platforms here.
• Reverting translated or proofread strings without notice. It desynchronizes the vendor’s records from your live file. If something needs to go back to the original, tell the localization team first.
• Changing source text without flagging it. Send a direct link to whatever was changed. Source and target need to stay in sync on both sides.
• Forgetting to mention text that lives outside the LocKit, such as hard-coded strings. If it’s not in the kit, tell us it exists.
• Altering structure, line order, IDs, or keys mid-process. It complicates importing the localization back into the file and adds time nobody budgeted for.
• Adding new strings quietly. If you’re both working in the same shared sheet, add new strings at the end and highlight them, and let the localization team know before you do.
• Not mentioning ongoing or completed voice-over work. Text and VO can fall out of sync fast if the vendor doesn’t know VO is happening.
• Sharing milestones late, or not at all. LQA dates, VO dates, QA dates, and the release date—share them before the task starts, and update the vendor if any of them move.