Should you translate your Steam demo before the full game?

You are about to put a demo out, and the question is how many languages it should be in. Translating the full game is a real commitment — thousands of lines, real money, and a decision made largely on hope, because nobody can tell you in advance how many players a language will bring. The demo sits in front of that decision, and it is small enough that you can afford to be wrong about it.

That is the useful way to think about a demo in this context: not as a marketing asset that happens to contain text, but as a scaled-down rehearsal of the whole localization problem. Same pipeline, same fonts, same UI that has to hold longer strings, same store page — at a fraction of the word count. Whatever breaks in the full game will break in the demo first, for far less money.

This article covers when translating the demo is worth it, what exactly it asks you to translate, how to keep the work from being thrown away, and what you can honestly conclude from the response.

A demo is the cheapest full-scale rehearsal you get

Most of the painful parts of localization are not proportional to word count. Getting text out of the build and back in, finding a font that covers the target language's characters, discovering that your dialogue box was designed around the exact length of your source language, dealing with a placeholder that mangles a translated sentence, wiring up a language selector that survives a save and reload — that work is roughly the same amount whether the game has two thousand words or two hundred thousand.

This is the strongest argument for translating a demo. You pay the fixed engineering cost once, while the text volume is small enough that mistakes are cheap to redo. If your export process turns out to lose line breaks, you find out on a few hundred strings instead of on the entire script. If your UI cannot hold German or Russian at their natural length, you find out on the menus rather than after committing to a full translation.

The demo also forces the parts of the pipeline that teams postpone. It is easy to say the language selector will get built later; it is much harder to ship a translated demo without one. Getting that infrastructure standing while the stakes are low is worth something on its own, independent of how the demo performs.

What a demo actually asks you to translate

Before deciding, count. The instinct is to imagine a demo as a small version of the game, but its text profile is different: it is unusually heavy on the strings that get read by everyone and unusually light on the narrative bulk that dominates a full game's word count.

Break the inventory into pieces that will survive into the full game and pieces that exist only for the demo. That split changes the calculation completely — most of a demo's text is not throwaway. Menus, options, system messages, control prompts, and tutorial text are the same strings the finished game will ship, so translating them for the demo is not an experiment at all. It is the full game's translation, started early.

Demo text inventory — count these before deciding

  ui.*          menus, buttons, options, key rebinding    reused by the full game
  system.*      save/load, errors, quit confirmations      reused forever
  tutorial.*    onboarding prompts, control hints          highest read rate in the demo
  dialogue.*    the slice you actually ship                may or may not survive
  store         short description, About, capsule text     read by everyone, played by some

When translating the demo is the right call, and when it is not

The case for it is strongest when you already have a signal and want to confirm it before spending. If wishlists, reviews of your previous game, or requests in your community keep pointing at one language, a translated demo turns a vague signal into something testable: people in that language can now actually play, and whether they do is a fact rather than a guess.

It is also the right call when a demo is going into a moment of concentrated attention — a festival, a bundle of demos, a publisher showcase. Concentrated traffic is worldwide traffic, and the same translation reaches many more people during those windows than it would in a quiet month.

The case against is mostly about instability. If your game's direction is still moving, the demo's dialogue will be rewritten before launch and translating it now means paying twice. In that situation, translate the durable half — the UI, systems, and store page — and leave the narrative slice in your source language, or leave it out of the demo entirely.

There is also a plain budget answer. If you can only afford one thing in a given language, the store page beats the demo every time, because a player who cannot read the page will never reach the demo at all. The page is a few hundred words; the demo is a few thousand. Do them in that order, not in parallel, when money is tight.

• Translate the demo when: you have a concrete demand signal, the text is stable, or the demo is heading into a high-traffic event
• Translate only the durable parts when: the narrative is still being rewritten but the UI and systems are settled
• Translate the store page only when: budget is the binding constraint, or you want the cheapest possible read on a new language
• Do not translate the demo when: you are not yet sure the demo represents the game you are actually making

Keep the demo's text as the game's text, not a fork

The most common way to waste demo translation is to let the demo build have its own copy of the strings. It happens naturally: the demo is branched off, someone edits a line in the main project, and now two versions of the same sentence exist in every language. By launch, nobody knows which translation is current, and the demo's translated text quietly stops being an asset and becomes a liability.

The fix is boring and effective. The demo pulls from the same string files, with the same keys, as the full game — it simply ships a subset. A key that exists in the demo means exactly the same thing in the finished game, so when a translator returns the demo batch, that work is already in the full game's translation, permanently.

Keep the returned translations somewhere durable, too. Whether that is a translation memory, a spreadsheet, or just the versioned files in your repository, the point is that when you commission the full game later, the demo's lines are already done and can be handed to the translator as existing material to stay consistent with rather than translated again from scratch.

One more trap worth naming: text that only exists in the demo, such as the end-of-demo screen asking players to wishlist the full game. It is a handful of strings, it is the last thing every player who finishes the demo reads, and it is the single most conversion-relevant sentence in the whole build. It gets forgotten constantly because it is not part of the game proper.

Be honest on the store about the demo's language state

A demo can end up in a partial language state very easily — menus translated, dialogue not; or the demo translated while the store page is not, or the reverse. None of those states is shameful, but all of them need to be represented accurately where players look before downloading.

Steam separates supported-language claims into interface, subtitles, and audio, and lets a demo carry its own store presence in addition to appearing alongside the main game. Check the current Steamworks documentation for exactly how the supported-languages settings apply to a demo versus the main app, because getting this wrong is not a cosmetic issue: it is the difference between a player who chose to try something in their second language and a player who feels misled.

If a language is partially supported, say so plainly somewhere the player will see it — a line in the About section is enough. In practice, players are notably tolerant of an honest partial state on a demo and notably harsh about a claim that turns out to be false. The demo is where you get to be transparent about being mid-process, which is a freedom the finished game does not have.

What the demo tells you, and how to act on it

The signal you want is not raw download counts by country — that number is mostly a reflection of how many players each region has, and it will look similar for almost every game. What is informative is the change: how a region's behaviour differs before and after a language went live, and how it differs from regions you did not translate for.

Watch the conversion steps rather than the top of the funnel. Page visits tell you about discovery; demo downloads tell you the page persuaded someone; wishlist adds after playing tell you the game itself landed. A language where visits are healthy but almost nobody downloads points at the page. A language where downloads are healthy but few people wishlist afterwards points at the build — sometimes at the game, and sometimes at a translation that was rough enough to break the experience.

Qualitative feedback from a demo is worth as much as the numbers here, and it arrives in a form the full game will never give you this cheaply. Players reporting overflowing text, awkward phrasing, or an untranslated screen are doing free localization QA on a small surface, and every one of those reports is a bug you will not ship in the finished game.

Whatever you conclude, write the decision down with its reason: this language earned the full translation because of X, that one did not because of Y. Six months later, when someone asks why the game ships in four languages and not seven, the answer should be a record of what the demo showed rather than a memory of how the week felt.