The 36% problem: two-thirds of Steam isn't playing in English
Picture the Steam audience in your head. Now ask yourself what share of it plays games in English.
If your gut said most of it, you're wrong by a factor of two. Only 36% of games on Steam are played in English. The other 64% — roughly two thirds of the largest PC gaming audience in the world — is playing in something else.
These numbers cut against the default mental model — we'll ship in English, and if the game does well, we'll add languages — which treats localization as a reward for success rather than a condition for it.
So the question isn't whether to localize — the numbers settle that. The question is where to start, which locales reward the investment, how the math shifts by game type, and what an indie budget actually looks like.
Before you localize the game: localize the store page
Before you spend a cent localizing the game itself, translate the store page and the trailer. Without touching a single in-game string, you can drive 30 to 50% more interest from non-English markets — wishlists, click-throughs, conversions on the storefront. The game stays English-only at launch. The discovery layer is what changes.
The mechanics are invisible from the dev side. Steam serves regional storefronts — a player browsing from Germany sees the German Steam, with the German capsule, the German trailer, and the German short description surfaced automatically. The regional store handles the routing. You just upload the assets.
Store-page localization sits in a different category than in-game localization:
- In-game localization is about the player's experience once they've already bought.
- Store-page localization is about whether they find you and decide you're worth their time in the first place. The cost-to-impact ratio is the most favorable in the whole localization stack.
Beyond discovery, there's another subtle mechanic at play that quietly impacts your downloads. When a player lands on your store page and sees it in their language, they read it as a sign that you care enough to show up for them. Yana puts it this way:
Localization is really a lot about caring. Most people can play games in English. But when they see localization, they understand that the developer really cares about the immersion, the emotional connection, the comfort of the player.
That changes wishlist behavior. A player who feels seen clicks the wishlist button, drops the link in their Discord, and comes back when the game launches. Caring becomes a discovery mechanism too.
The combined effect makes store-page localization the right place to start: a measurable lift in discovery from the regional storefront mechanics, plus a softer lift from the trust signal, both achievable for a fraction of what full game localization costs.
Bottom line: if you've got budget for one localization move, start with the store page.
Three markets to pay attention to: Chinese, Brazilian Portuguese, Russian
Three markets came up most often in the conversation with Yana, and each one matters for a different reason.
Chinese: the biggest share, the most complicated path
Chinese is 27% of Steam play. That's not a tier-two market — it's almost the size of English. For most indie devs, that number alone reframes the priority list.
The complication is that Chinese isn't a clean translation job the way European locales are. To get into Chinese stores properly — the in-China distribution, the local discovery surfaces, the audience that buys through domestic channels — you typically need a local publisher relationship. That's a business-development conversation, not a localization conversation, and it has its own timeline and its own cost.
The honest read for an indie team: you can serve Chinese-speaking players on global Steam without a Chinese publisher, and that's still a meaningful audience. Simplified Chinese on your global store page and in-game will earn its keep. But the ceiling on what you can reach is lower than the 27% headline number suggests. Treat Chinese as two decisions: do we localize for Chinese-speaking players globally (yes, almost always), and do we pursue a publisher path into China itself (a bigger, slower question).
Brazilian Portuguese: the engagement data lies to you
Brazilian Portuguese is the rising star, and it's the rare locale where the historical signal is the opposite of the forward signal.
For years, BR-PT localizations on Steam were patchy at best. Translations were rushed, machine-driven, or skipped entirely. Brazilian players adapted: they got used to playing in English, and that became the default. Devs looking at engagement data saw Brazilian players happily playing English-language games and concluded the locale wasn't a priority. The localizations stayed bad, and the cycle reinforced itself.
That cycle is breaking now:
Brazilian Portuguese localizations were not that good historically, and many players just historically played in English. But the situation started to change recently, and now it's a rising market — a good thing to consider.
The reframe matters for indie devs reading their own data. If you look at your Brazilian audience and see them playing in English, the naive read is “they don't need localization.” The accurate read: they've been trained to accept English because no one served them well, and the first wave of devs to do BR-PT well are picking up demand that was always there.
Russian and CIS: the quiet 9%
Russian sits at 9% of Steam play in 2025 — smaller than the headline locales but bigger than most devs assume. It's the lingua franca across CIS countries, and the player base is engaged. It's not the locale that earns the most page time in this article — the share is steady rather than dramatic — but it's the one that quietly rewards inclusion when your priority list extends past the first three.
Functional text vs. narrative text: two different jobs
There's a line running through every game's text, and which side of that line your game sits on changes the cost, the timeline, and the kind of work involved.
- On one side: UI strings, menu labels, button text, tutorial prompts, error messages. Functional text, where the goal is information transfer. The player needs to know that this button cancels, that menu opens settings, that tutorial step ends when they pick up the item. Translation has to be accurate and fit the space — but as long as it's accurate, it works.
- On the other side: dialogue, narration, character voice, jokes, puns, references, world-building flavor. Text doing emotional and cultural work. Here, accuracy isn't enough. A line that translates correctly but lands flat has failed at its job, even if every word is technically right.
This is the difference between translation and localization:
Translation is word-to-word. Localization is adapting to the culture and perception of the locale.
For example, Spanish localization is particularly important because of regional variations. For narrative games, Spanish for Spain and Spanish for Latin America carry different idioms, different humor registers, and different cultural references — sometimes enough that you'd treat them as two localizations rather than one.
That logic extends more broadly to jokes and references:
If you have small puns or references, they should be adapted to be understood by the target audience. So they get them and enjoy them.
This is also where AI translation hits the limit. AI works fine for UI strings and menu text, where the job is information transfer — but it doesn't deliver on narrative content where the job is effect. AI can render a joke literally and accurately and still produce something that isn't funny in the target language, because current models don't do well with comedic timing, cultural reference, or idiomatic flow. For a story-led game, the cost savings from AI translation are real on the UI layer and roughly zero on the narrative layer.
The counter-intuition: systems-led games still localize
The framing so far might suggest that if your game isn't narrative-heavy, you can skip localization. It doesn't. Every game has a functional layer, and the functional layer earns its localization regardless of how much story you're shipping.
A systems-led game — top-down shooter, roguelike, puzzle game, building sim — still has a UI, menus, a tutorial, onboarding flows, error states, and store-page copy.
All of that benefits from localization, just with a different cost profile:
- The word count is lower.
- AI translation handles more of it cleanly.
- There's no transcreation work on jokes because there are no jokes.
But the player who lands in your game and immediately understands which button does what is having a meaningfully better first session than the one squinting at English at 60% comprehension.
The shape of the decision, then, isn't narrative game = localize, systems game = don't. It's narrative game = budget for human adaptation on the story layer, systems game = lean on AI-assisted translation for the functional layer, both = localize the store page first.
Let's take a look at how that looks in practice.
How to phase localization on an indie budget
The decision to localize feels big because the cost — money, ops, time — feels big, and the cost feels big because the mental model is translate everything in the game into N languages.
That's not how it has to work. The cleaner model is: localization isn't one decision, it's three, and each one is small enough to make on its own. The dev never commits to a guess. Each phase produces data that pays for the next.
Phase 1: localize the storefront
Pick two or three priority languages. Localize the store page — capsule, short description, screenshots — and the trailer. The game itself stays English-only.
Choosing the languages is the only judgment call here. Sample starting points: a European tier (German, French, or Spanish — pick based on your genre's audience), Simplified Chinese if your game doesn't lean heavily on Western cultural references, and Brazilian Portuguese if you have any signal at all from Brazilian players.
Because the word count is small, the cost of being wrong at this phase is low enough that you don't need to overthink it. You're buying yourself wishlist data from non-English markets — early signal on which ones are responding.
Phase 2: read the wishlist signal
Steam shows wishlist data by country. After Phase 1 has been live for a few weeks or months (depending on your traffic), that data tells you which of your priority languages is actually pulling.
Sometimes the answer matches what you'd have guessed. Sometimes it doesn't. The point of Phase 2 is to let the market tell you where to deepen, instead of guessing and committing.
Phase 3: deepen where the wishlists pulled
For the languages that showed real wishlist momentum, localize the in-game UI, menus, and tutorial. This is the player-experience layer that makes a player who installs the game play it past the first session.
Note that this phase doesn't necessarily mean localizing the whole game. For a narrative-heavy title, dialogue and story content come in a later pass. For a systems-led title, this phase might cover most of what the game needs. The distinction we drew earlier — UI on one side of the line, narrative on the other — applies here. Phase 3 handles the UI side. The narrative side is a separate decision, with separate cost.
After launch, two new data sources open up: sales by country, and player feedback in reviews, Discord, and support tickets. These tell you which locales to add next. Someone mentions in the reviews they'd play in Polish, you check the wishlist data, the share turns out to be bigger than you assumed, and Polish goes into the next content patch.
The teams that listen pick up serious additional audiences from places they wouldn't have predicted.
The precondition: your strings have to be portable
The whole progression assumes your codebase is internationalized — strings externalized, no hardcoded text, placeholders used correctly for variables like character names and item counts. If a dev tries to start at Phase 1 without that groundwork, Phase 3 stalls because the in-game strings can't be cleanly swapped per language. The phased approach isn't a substitute for the technical prep — it's what the technical prep enables.
So zooming out: localization isn't a bet you place once. It's a sequence — each phase justified by the data the previous one produced.
Game localization cost: what indie devs can expect to pay
Three pricing scenarios below cover most of what indie devs are building. The figures come from Yana's pricing as described on the show, and are representative of what an indie team would pay a vendor — your specific quote will vary by word count, language tier, and game type.
Scenario 1: the systems-led game
A roguelike, a puzzle game, a building sim. Mostly UI, menus, tutorials, and onboarding (~2,500 words). Narrative is minimal or absent.
Per-language cost: $80–150 for human translation. Three European languages — say German, French, and Spanish — come in around $240–450. Add 15–20% on top for LQA (the quality-assurance pass that catches truncated strings, broken placeholders, and translations that don't fit the UI), bringing the total to roughly $280–540 for three languages with QA included.
This is also the scenario where machine translation post-editing makes the most sense. MTPE — AI does the first pass, a human linguist proofreads — cuts cost by 40–50% on games like this. Same three languages drop to roughly $140–270 with LQA.
Scenario 2: the narrative-heavy game
A story-driven RPG, an adventure game, anything where the dialogue and flavor text are doing emotional work. Word count is higher, often by an order of magnitude. The narrative layer needs human adaptation rather than AI-assisted translation, because the AI ceiling we touched on earlier is real and the cost of bad jokes in your story is high.
The math here is harder to make a clean range for, because the variable is your word count. As a rough orientation: a 20,000-word narrative game in three languages, scaling from the small-game baseline, lands somewhere in the low-thousands range plus LQA. A 50,000-word game scales accordingly. Your specific quote will depend on language tier and how complex the source text is — the kind of estimate worth getting from a vendor directly rather than working off averages.
The honest framing for narrative-heavy titles: yes, the budget is bigger — but for these games, localization quality ties directly to player retention, review scores, and word-of-mouth. Narrative localization done on a UI-localization budget shows up fast in the review section and in player communities.
Scenario 3: the AI-eligible game
Some games sit in a middle space. Enough text that translation cost matters, but not so much narrative weight that the AI ceiling becomes a dealbreaker. Survival games, simulation titles, strategy games with light story framing. For these, MTPE often does the job at 40–50% off the human-translation rate, and the saved budget can fund deeper LQA or one additional language.
The decision-rule to keep in mind: if your game is full of puns and references, MTPE struggles and you'll need human translation. If it isn't, MTPE is a real cost lever.
Language tiers affect all three scenarios
Rates vary by language because they partly track the cost of living where translators work.
- The most expensive tier includes Japanese and Northern European languages — Swedish, Finnish, Norwegian, Danish.
- The cheapest tier includes CIS languages (Russian, Ukrainian) and parts of Central Europe.
- The middle tier — French, Spanish, Italian, German.
The middle tier has come down recently: AI engines have learned these languages well enough that MTPE is reliable, which has compressed the human-translator rate.
Simplified Chinese sits in its own conversation. The translation cost itself is tier-typical, but the publisher question we raised earlier is its own line item if you pursue the in-China path.
How long game localization takes
A 2,000-word game translates in two to three business days per round. LQA adds another two to three business days. End to end — including the back-and-forth on linguist questions and the developer implementing the strings into the build — you're looking at roughly a week, sometimes a bit more if your team is responsive on questions and a bit less if the prep was thorough.
Languages run in parallel up to about ten or fifteen before timezone friction starts adding days. For an indie team running three to five languages from Phase 1, adding more languages doesn't add time.
Beyond translation time, budget a week for prep on your side: character descriptions, item names, the style guide. A good localization brief lets the translation week run at full speed. Without it, even a strong vendor gets slowed by back-and-forth questions.
Ready to start?
If you've read this far, you've probably already done the math on your own game. The question now is which two or three languages to start with, and how to set up the prep so the first round actually goes smoothly.
That's a conversation Alconost is built for. Our team localizes indie games every week, knows the regional Steam mechanics from the inside, and can scope the budget for your specific word count and language mix in a single call. Get in touch →
Frequently Asked Questions
If most Steam players understand some English, why localize the store page?
Which languages should a small indie prioritize after English?
Does this apply to narrative-heavy games differently?
Where does professional localization fit in a tight ship date?
Alexander founded Alconost after years building and shipping software for global markets. He works with game and product teams that want localization baked into how they ship — not parked at the end of the roadmap as someone else’s problem.
