Localizing release notes: shipping updates in every language your product speaks

Plenty of products are properly localized — settings screens, onboarding, docs, error messages all translated — right up until release day, when “What’s new” arrives in English only. For a routine bug-fix note, nobody minds much. But when the entry says “we’re removing the legacy exporter — action required by June 30,” English-only means the users least comfortable reading English get the least warning, in a product that promised to speak their language everywhere else.

Localizing release notes is a different problem from localizing UI strings. Interface text is written once and translated over sprint cycles; release notes are written at the last minute, ship at release velocity, and have a shelf life of weeks. Treating them like any other string resource either slows every release or produces permanently-lagging translations. This guide covers what’s actually worth translating, how to write source text that survives translation, the terminology rule that most teams miss, and honest guidance on machine translation.

Not every entry deserves the same treatment

The most useful localization decision is admitting that release notes come in tiers, and budgeting per tier instead of per release.

Tier 1 — must be localized: anything requiring reader action. Breaking changes, deprecations with deadlines, security fixes with an upgrade instruction, pricing or legal changes. Comprehension here isn’t a nicety — it’s the difference between a user who migrated in time and one who found out when the thing broke. If you localize nothing else, localize these, and treat a missing translation as a release blocker exactly the way you’d treat a missing UI string.

Tier 2 — worth localizing in your top languages: launch-grade announcements. A feature announcement is marketing, and marketing in the reader’s language converts better. Translate these into the languages that carry your revenue; skip the long tail without guilt.

Tier 3 — honestly optional: routine fixes and small improvements. A clear English entry beats a bad translation, and users forgive untranslated fix notes in a way they never forgive an untranslated removal notice. Skipping tier 3 is a defensible, consistent policy — state it once (“detailed fix notes are published in English”) and spend the budget where it matters.

The clock problem

Translation takes days; release notes are often written hours before the release. That mismatch, not cost, is why most teams give up. Four fixes:

  • Write entries when the change merges, not when the release ships. The same discipline that fixes release-day scramble in general buys your translators their lead time. An entry written at merge has days or weeks to be translated; an entry written at tag time has none.
  • Freeze tier-1 and tier-2 copy a few days before release. Late wording tweaks to a translated entry cost a full round trip in every language. Treat copy freeze like code freeze: exceptions exist, but they’re exceptions.
  • Ship all languages together. Drafts plus scheduled publishing let you stage every language and flip them live at once. A locale that goes live a week late reads as an afterthought — which is exactly what it was.
  • Exploit repetition. Release notes are the most repetitive text you ship: “Fixed a bug where…”, “You can now…”, “Improved the speed of…”. If you keep sentence patterns consistent, translation memory makes your tenth release dramatically cheaper than your first. Inconsistent phrasing resets that meter every time.

Write source text that survives translation

Most localization failures are authored in the source language. The craft rules for tone apply double when the text will pass through a translator — human or machine — who has no access to your intent:

  • Short, declarative sentences, one idea each. Ambiguity multiplies in translation; a sentence with two readings in English has four in the target language.
  • No idioms, no wordplay. “Squashed a pesky bug” either costs a translator ten minutes or ships as literal nonsense about insects. Humor is the first casualty of translation — budget it accordingly, or spend it only in languages where a human you trust can rewrite the joke rather than translate it.
  • Concrete verbs over vibes. “Improved reliability” translates easily precisely because it says nothing. “The app no longer signs you out when the network drops” takes one more clause and survives every language intact.
  • Mark what must not be translated. Product names, feature flags, CLI commands, version numbers. A do-not-translate list is one shared doc and saves you from discovering your product’s name means something unfortunate when helpfully translated.

The terminology rule: match the localized product, not the English one

A Spanish-speaking user’s button is Ajustes, not Settings. A translated release note that says “ve a Settings” — or worse, fluently translates a screen name into words that appear nowhere in the actual UI — describes a product that doesn’t exist. This is the single most common defect in localized release notes, and it comes from translating notes ad hoc, disconnected from the string catalog the product itself is translated with.

The fix is mechanical: whoever translates release notes uses the same glossary and translation memory as the product UI, and every screen, button, and setting named in a note is looked up, not re-translated. The inverse case matters too — if a new feature’s surface ships English-only at first (a beta screen, say), the localized note should name it in English and say so, rather than translating a label the reader will never find.

Machine translation: where it’s honest, where it’s dangerous

Modern machine translation is genuinely good at short, declarative product sentences — which is what well-written release notes are. So use it, with two hard rules.

Raw MT never rises above tier 3, and it gets labeled. A small “machine translated” note is honest and sets expectations. Unlabeled MT claims a fluency you didn’t verify.

Anything with a deadline, a removal, or a CVE gets human review. Here’s the asymmetry: an untranslated English entry at least signals “this wasn’t localized — read carefully or find help.” A fluent-but-wrong machine translation signals nothing; the reader has no cue to distrust it. A mistranslated negation in a security note — “you do not need to rotate keys” where the source said the opposite — is strictly worse than English. Fluency without accuracy is a trap you build for your most trusting users.

Channel mechanics

App stores. Both major stores take per-locale “What’s new” text and fall back to your default locale when a translation is missing — so partial coverage degrades gracefully rather than failing. Two store-specific catches: translated text runs long (German or Finnish commonly +30%), so English copy written to the Play Store’s 500-character limit may not fit after translation — write short and leave headroom; and review clocks differ per store, so “ship all languages together” means staging them before submission, not translating after approval.

Email. Segment by locale and send each language its own version. A bilingual email doubles the length and halves the reading; update emails earn their send by respecting the reader’s time, and nothing disrespects it like 400 words in a language they don’t read before the part they do.

Your changelog page. Pick one canonical language for the page itself and be explicit about it. Three structures exist: a canonical-language page with localized push channels for tier 1 and 2 (the right default for small teams); fully parallel per-locale streams (only if you can keep them in lockstep — see the anti-patterns); and mixed languages in a single stream, which is never right, because readers can’t subscribe to the part they can read.

What travels without translation

Structure is free. ISO dates (2026-07-28) are unambiguous in every locale in a way “07/06/2026” never is. Version numbers, tag semantics (new, fix), permalinks, and feeds work identically in every language — which is an argument for carrying meaning in structure rather than prose wherever you can: a reader with weak English can still parse a dated, tagged, consistently-formatted entry. The more your changelog’s meaning lives in its structure, the less translation it needs.

Anti-patterns

  • The English-only removal notice in a localized product. The exact users who most needed warning get the least. If the product speaks their language, tier-1 news must too.
  • Raw machine translation on a security notice. Fluent-but-unverified text about key rotation or forced upgrades — see above; this is the highest-stakes text you publish.
  • Translating the joke. Wordplay ships as gibberish, or occasionally as an accidental insult. Rewrite or cut; never translate humor literally.
  • Locale streams that lag. A Spanish changelog whose latest entry is three versions old tells Spanish-speaking users you stopped caring — visibly, on the record. Worse than not having one.
  • The mixed-language feed. Alternating languages in one stream means every subscriber skims past half the entries. One language per stream, always.
  • Translated prose, untranslated terms. “Settings” floating in a Spanish sentence — or a fluently-translated name for a button that’s labeled something else in the actual localized UI.

How this works on Wakelog

Honest scoping first: Wakelog doesn’t translate anything, and a project is a single stream in whatever language you write it. What the primitives support: keep your canonical changelog in your product’s primary language, and for each language you’re prepared to keep in lockstep, run a per-locale project (acme, acme-es, acme-ja) — each gets its own public page, RSS/JSON feed, and embeddable widget, so readers subscribe in their language and your app can point each locale’s build at the matching widget. Because posting is one API call, publishing N translated variants is a loop in your release script, not an afternoon of pasting — and drafts with publish_at let you stage every language and have them go live together. What we won’t pretend: nothing cross-links the locale variants automatically, and keeping them in lockstep is a promise you make, not one the tool enforces.

Start your free changelog   Next: app store release notes →

Related guides

Last updated 2026-07-28 · All guides