How to translate your Steam store page, field by field

Your store page works in your own language. You can tell that it does: the description says the right things in the right order, the tone is yours, and the people it was written for understand what the game is within a few seconds. Now you want a version that does the same job in another language, and the obvious move is to paste the whole thing into a translator and be finished in ten minutes.

What that produces is a page that is technically in the target language and still does not work. A Steam page is not one document. It is a set of separate fields, each shown to a different visitor at a different moment, with very different consequences when it reads badly. Some of them Steam already translates for you and you can leave alone entirely. The rest are worth doing in a specific order, because they are not equally valuable.

This is a walkthrough of that work, aimed at a developer doing it for the first time, before or instead of translating the game itself.

Which parts of the page are actually yours to translate

Open your page the way a visitor from your target country would see it and you will notice something useful straight away: a lot of it is already in their language. Steam builds much of the page from controlled vocabularies rather than from your writing. Tags, genres, categories, the supported languages table, the review summary, the price and its currency, the labels in the system requirements block, the buttons and section headers are all Steam's own strings, and they appear in each visitor's language whether or not you have lifted a finger.

What is yours, and therefore what needs translating, is a much shorter list: the short description, the body of the About This Game section, whatever free text you typed into the system requirements, any text baked into your capsule images and screenshots, and from that point on your announcements. On most indie pages that comes to a few hundred words plus a handful of images. It is a genuinely small job compared with the game.

That split has a second implication worth sitting with. The parts of your page that do the heaviest discovery work, tags above all, are language-independent already. A player in a country you have never thought about can be shown your game today, in a browse list, in a recommendation widget, in a search filtered by tag. What they cannot do, once they arrive, is understand what the game is. The page is not what stops them finding you. It is what stops them buying.

Work the fields in this order

If you cannot do everything at once, or you want to see whether it is worth continuing before you commit the whole budget, the order below is roughly the order of return per word.

• The short description, the one piece of your text that travels off your page
• The first paragraph and first image of About This Game, which is what a visitor reads before deciding whether to scroll
• The rest of About This Game, including feature bullets
• Text baked into screenshots and capsule art, if you have any
• Free-text notes in the system requirements and next to your language support
• Announcements from that point forward, because a translated page with an untranslated announcement feed reads as abandoned

The short description is a rewrite, not a translation

The short description sits at the top of that list because it is the only piece of your text that leaves your page. It appears next to your capsule in search results and browse lists, in recommendation widgets on other games' pages, in hover cards, and in the mail Steam sends to people who wishlisted you. Every other field is read by someone who has already decided to look at your page. This one is read by people deciding whether to.

It is also the field where literal translation fails hardest, because it is compressed. A good short description leans on conventions the reader already has: genre shorthand, a comparison they will make on their own, a tone that signals who the game is for. Translate the sentence rather than the intent and you get a line that describes what the game contains instead of why anyone would want it. It will be grammatical. It will also be inert.

Marketing adjectives are the usual casualty. Words chosen to convey feel, rather than fact, tend to come back as literal statements about physical sensation, which read as either meaningless or unintentionally funny. Genre nouns often survive better than the adjectives around them, because players in the target market frequently use the same loanword you do. It is the connective tissue between them that has to be rebuilt.

The practical instruction is to hand over the brief you wrote the original from, not just the original: genre, the hook in one line, who the game is for, and two or three comparable titles so the translator can hear the register you want. Ask for a sentence written in the target language rather than a rendering of yours, then have it translated back into your language by someone else so you can confirm it still says something true about your game. Budget more per word for this field than for anything else on the page.

What a machine-translated page looks like from the other side

The failure most developers expect is broken grammar. That is not the common failure and it is not the damaging one. Machine translation produces fluent sentences now. The damaging failure is a page that is grammatically clean and says nothing specific, an even generic surface that a reader slides off without forming any impression at all.

The concrete symptoms are recognisable once you know to look for them:

• Register that does not match the audience, so a page pitched at teenagers reads like an appliance manual, or the reverse
• Marketing adjectives rendered literally, turning a line about how the game feels into a claim about physical sensation
• Proper nouns spelled one way in the description, another in the screenshot captions, and a third inside the game
• Bullet points translated as fragments that lose a subject the source language was allowed to leave out, so each line reads as a sentence missing its start
• Formatting markup swallowed or duplicated, collapsing headers and bullets into an undifferentiated wall of text
• Line breaks preserved from the source, producing ragged short lines in a language that wraps at different points
• Control names and platform terms translated word by word instead of matched to what that platform calls them locally

You cannot check this yourself, so plan for who will

A page in a language you do not read looks fine to you by definition. That is the whole problem, and it is why a review step has to be part of the plan rather than something you get to if there is time.

The cheapest useful check does not require a professional reviewer. Find one person who reads the target language natively, show them only the translated page with the source hidden, and ask a single question: after reading this, what kind of game do you think this is, and who is it for? If the answer is vague, or wrong, or arrives only after they have studied the screenshots, the page is not finished no matter how correct its sentences are. If they can tell you the genre, the hook, and the intended player in one breath, the translation is doing its job.

Ask them a second question while you have them: is there anything here that sounds odd, dated, or like it was written by a company rather than a person? Native readers pick that up instantly and will usually not mention it unless invited.

What to hand over if you commission it

A store description is unusually hard to translate blind. It is short, dense, tonal, and full of references to things the translator cannot see. Most of the quality difference between a good store page translation and a mediocre one is decided by what you send, not by what you pay.

Send text, not screenshots of text and not a link to the live page. A translator who has to retype your description will lose your formatting and introduce typos that nobody catches. Send the images and a video, ideally a build or a key. Send the names you have already fixed in the target language and be explicit about the ones you have not, because otherwise the translator will invent spellings and you will discover the inconsistency months later in a patch note.

Store page translation brief - <Game Title>
Target language: <language>
Files: short_description.txt, about_this_game.txt  (plain text, one file each)
Length limit: short description must fit Steam's field limit
Do not translate: game title, studio name, the names listed below
Fixed spellings: <Name> = <target spelling>, <Place> = <target spelling>
Reference: trailer <URL>, screenshots in /screens, build key available on request
Register: <e.g. dry, first person, present tense, no exclamation marks>
Comparable titles for tone: <2-3 titles the audience knows>
Jokes and wordplay: <reproduce / replace with a local equivalent / drop>
Deadline: <date>    Questions to: <contact>

After it goes live, read the regional data

Steamworks reports visits, wishlist additions, and sales broken down by region. That is the closest thing you have to a measurement of whether the translated page did anything, and it is worth checking a few weeks after launch rather than the next morning.

The comparison that means something is not the before-and-after in absolute numbers, which will be contaminated by whatever else happened that month: a festival, a sale, a video, an algorithm change. It is the ratio. Of the people from that region who reached your page, how many added it to their wishlist, and how does that rate compare with the region you already sell in? A page people arrive at and leave is a page problem. A page nobody arrives at is a discovery problem, and translating it harder will not fix that.

Treat the result as the input to the next decision rather than as a verdict on the translation. If the localized page converts at something like your home rate, you have evidence that the language is worth more investment, and the obvious next step is the game itself, or a demo in that language. If it does not, you have spent a few hundred words finding that out, which is exactly why this is the experiment to run first.