Writing patch notes and announcements in more than one language

Your game ships in six languages. Your patch notes ship in one. That gap is extremely common, and it is easy to see why: the game's text goes through a planned localization process with a budget attached, while an announcement gets written the morning it goes out, by whoever is closest to the release.

The result is a strange asymmetry from the player's side. Someone who bought the game because it was available in their language now watches updates arrive as a wall of text they cannot read. They can see that something changed, they cannot see what, and over time the impression forms that the version they own is a translated copy of a game that is really being made for someone else.

This article is about making that side of the operation repeatable: what an announcement is actually for, where to draw the line on what gets translated, how to write the source text so translating it costs almost nothing, and how to keep the terminology in your announcements matching the terminology in your game.

What an announcement is actually doing

It helps to be precise about the job, because only part of it is informational. A patch note does three things at once, and they have different language requirements.

The first is telling current players what changed, which is the part everyone thinks about. The second is signalling that the game is alive and maintained — a player scrolling a list of recent posts is reading the rhythm, not the contents, and a steady cadence of updates is reassuring even to someone who reads none of them closely. The third is re-engagement: pulling back players who stopped and giving them a reason to reinstall.

The second and third jobs are relationship work, and relationship work performed in a language someone cannot read does not merely fail, it can actively signal exclusion. A player who sees a lively announcement feed they cannot read learns something about where they sit in your priorities.

There is a fourth audience worth naming: people who have not bought the game yet. Announcements are public, they sit on the store page, and they get indexed by search engines. A prospective buyer checking whether a game is still supported reads the announcement list before they read anything else — which makes announcements a store surface, not just a community one.

Decide the line, and then hold it

Translating every word of every post is not realistic for a small team, and pretending otherwise is how the process collapses after three updates. Decide in advance which categories always get translated, which usually do, and which never do — then apply that consistently, because an inconsistent line is worse than a conservative one. Players notice when the big announcements are multilingual and the apology for a broken build is not.

The categories that should never be exceptions are the ones with consequences: anything about money, availability, data loss, breaking changes, or server outages. If a player could lose progress, lose access, or be charged something because they did not understand a post, that post gets translated regardless of how small it is.

For everything else, a summary-plus-detail structure buys you most of the value for a fraction of the cost. Translate a short summary of what changed into every supported language, and keep the exhaustive bug-fix list in one language below it. Almost nobody reads a hundred-line fix list closely in any language; almost everybody reads the first paragraph.

Be explicit when a post is partially translated. One honest line — full notes are available in English only — costs nothing and reads far better than silence, which players interpret as an oversight. The same applies to channels: it is entirely reasonable to publish store announcements in all supported languages while running your community server mostly in one, as long as that is a stated policy rather than something people have to discover.

• Always translate — pricing changes, availability, data loss risk, outages, breaking changes, anything about refunds
• Usually translate — major feature updates, seasonal events, roadmap posts, anything you want lapsed players to come back for
• Rarely translate — exhaustive fix lists, minor hotfix details, developer commentary posts
• Never leave silent — say which parts are translated and which are not, in the languages that are affected

Write the source so it survives translation

The single biggest lever on the cost of multilingual announcements is not who translates them, it is how the original is written. An announcement written with translation in mind can be turned around in minutes and machine-translated with far less risk; one written as a stream of jokes and references cannot be, at any price.

Use a fixed structure so every post looks the same. A stable skeleton means translators and tools see a familiar shape, headings repeat verbatim across posts, and readers know where to look. It also means the parts you always translate are mechanically separable from the parts you sometimes do.

Keep sentences short and complete. Fragments that make sense under an English heading often become ambiguous once the heading is translated separately from the line under it. Avoid puns, memes, and culture-specific references in headings especially — a heading is the part most likely to be translated without its surrounding context.

Keep text out of images. A banner with the update name burned into it will never be translated, and it is usually the largest, most visible element in the post. If the image must carry text, keep it to the version number and put the meaning in the body.

• One idea per bullet — do not chain three changes into one sentence with semicolons
• Numbers, version strings, and dates written the same way every time, and never spelled out inside prose you plan to machine-translate
• No text baked into banners or screenshots that carries meaning
• Headings reused verbatim from the template rather than rewritten creatively each time

Build a phrase bank and stop paying for the same sentences

Announcements repeat themselves enormously. Across a year of updates you will write some version of the client must be restarted, save data remains compatible, and we are aware of this issue and a fix is in progress dozens of times. Translating those from scratch each time is pure waste, and worse, it produces a different wording every time — which makes the same information look like different information.

So translate them once, properly, and store them. A phrase bank is nothing more than a file of reusable sentences with a stable key per sentence, translated into every language you support. New announcements are assembled largely from existing rows, which means the marginal translation cost of a routine hotfix post approaches zero and the wording stays identical across releases.

Keep the template beside it, in the same folder, under the same version control as everything else. The point is that writing an announcement becomes a matter of filling in a known shape rather than composing from a blank page under deadline pressure.

announcements/
  template.md       fixed section order — every post starts from this
  phrases.tsv       reusable sentences, translated once per language
  glossary.tsv      item, skill and mode names, pulled from the game's strings

# template.md
<version> - <one line summary>
## What is new        (always translated)
## Changes            (always translated)
## Fixes              (translated per your tier rule)
## Known issues       (always translated - this is where trust is won)

# phrases.tsv
restart_required   The client must be restarted for this update to apply.
saves_compatible   Save data from previous versions remains compatible.
hotfix_intro       This is a hotfix for an issue reported after the last update.
server_downtime    The servers will be unavailable while the update is applied.
known_issue        We are aware of this issue and a fix is in progress.
thanks_reports     Thank you to everyone who reported this.

The glossary is the part that actually breaks

Here is the failure that does the most damage and gets caught the least: the patch notes name things differently from the game. A note says a skill was rebalanced, using a translated name that a translator invented on the spot for the announcement, while the game itself calls that skill something else entirely in the same language. The player reads the note, goes looking, and cannot find what changed.

This happens because announcements usually travel down a different path from in-game text. The game's strings went through a translator with the full context and a glossary; the announcement was machine-translated in a rush by someone who did not have either. Every proper noun in your game is a landmine on that path — item names, skill names, mode names, area names, character names, currency names.

The fix is mechanical. Extract the proper nouns from your game's own localization files and keep them as a glossary next to the template. Whoever writes or translates the announcement uses that file as the source of truth, and never invents a rendering for a term that already exists in the game.

Check this specifically during review. Reading a translated announcement for fluency will not catch it, because a wrong item name reads perfectly well — it is only wrong in relation to the build, which means the only way to catch it is to compare against the glossary term by term.

Machine translation, review, and the timing problem

Machine translation is a reasonable tool for announcements, more so than for in-game narrative, because the register is plain and the structure is repetitive. It is not a reasonable tool without a review step, and the review does not have to be a full read for style — it has to be a check on the specific things machine translation gets wrong in this format.

That check is short and always the same: every proper noun matches the glossary, every number and version string survived intact, every date is unambiguous, and nothing about money, refunds, or data loss was paraphrased into something that means something slightly different. Those four items catch the overwhelming majority of real damage.

Then there is the timing problem, which is the reason most teams give up on this. The announcement has to go out the moment the patch does, but translation takes time and the patch is not final until shortly before release, so the text you would translate does not exist yet when you would need to start translating it.

The way out is the same summary-plus-detail split. The summary — what this update is about — is usually knowable days in advance and stable, so it can be translated ahead of time. The detail section, the part that changes up to the last hour, either goes out in one language or follows in an edit shortly after. That converts an impossible schedule into a normal one, and it is the difference between a process that survives twelve updates and one that quietly stops after the third.

Finally, check what your publishing surfaces can carry. Steam's events and announcements tooling can hold per-language versions of a post so players see it in their own store language rather than a mix; the current Steamworks event documentation is the place to confirm how translations are entered. Publishing the same information as several separate posts in different languages is a workable fallback, but it clutters the feed and splits the comment threads, so use the platform's own mechanism where one exists.