Budgeting for localization: the line items nobody mentions

Ask someone how much localization costs and they will usually answer with a translation rate — money per word or per thousand characters. That number is real, but it is one line in a budget that has several others, and the ones people forget are the ones that blow past the estimate. This article is a checklist for building that estimate honestly, without quoting any specific rates, because the right rate depends on your language pairs, your vendor relationship, and your market — things only you can price.

The goal here is not a number. It is a shape: the categories of cost you need to account for, and where each one tends to come from.

Start from your own word count

Every other estimate follows from one number: how many words (or characters, for logographic target languages) actually need translation. This is the first concrete step, and it is one you can do yourself before talking to anyone. Export all user-facing text — UI strings, dialogue, item and quest text, achievement copy, store page copy, marketing copy if you're localizing that too — into one place and count it.

Word count also tells you what kind of project you have. A menu-driven puzzle game with a few hundred UI strings is a different budget category from a dialogue-heavy RPG with tens of thousands of lines. Knowing which one you are early saves time spent estimating the wrong thing.

The budget line items

A complete estimate has more categories than most first drafts include. Treat this as the checklist:

• Translation — scales directly with word count; the core, most visible cost
• Review / linguistic QA — a second set of eyes checking accuracy and tone, separate from translation itself
• Engineering — building or adjusting the export/import pipeline so text can leave and re-enter your build safely
• Font and text-rendering support — covering the character sets of every target language, including ones with different line-breaking rules
• UI adjustment — layout that survives strings noticeably longer or shorter than the source, which is common when moving between language families
• Coordination — someone's time spent packaging files, answering translator questions, and tracking what's done
• In-context or functional QA — playing the localized build to catch what static review can't (truncation, overlap, broken placeholders)
• Ongoing maintenance — every patch, event, and content update after launch, indefinitely

Why maintenance is the line item that surprises teams

Launch-day translation has a clear end point: you get a quote, you pay it, the game ships in that language. Maintenance does not have an end point. Every string you add after launch needs the same pipeline run again — translation, review, and checking — for as long as you support the game in that language.

This is why it helps to think of localization less as a purchase and more as a subscription with a variable rate. Budgeting only for launch and treating post-launch translation as an afterthought is one of the more common ways teams end up shipping content in a mix of languages, which is more visible to players than almost any other localization failure.

Coordination cost is real even when it looks free

If translation is outsourced to a freelancer or agency, someone on your team still has to prepare files, answer questions about context and tone, receive the translated files back, and verify nothing broke in transit. None of that shows up on an invoice, which is exactly why it gets left out of estimates. Count it as time, even if no money changes hands for it directly.

Building a first-pass estimate

A reasonable first pass looks like this: count your words, get quotes or rate estimates for translation and review against that count, add an engineering estimate scoped to your actual export/import needs (this varies enormously by codebase, so it resists generalization), and then multiply your best-guess maintenance load — how many words you expect to add per future update — by the same per-word costs, spread across the game's expected support lifetime.

The result will not be precise, and it should not be treated as one. Its value is in making the shape of the spend visible before you commit, so the categories you forgot to plan for are not the ones that end up cutting into your schedule later.