Quick answer — Translate the customer-facing summary of a release, not the full changelog. Notes age within days, so the workflow has to run on the release rather than as a separate project.
Vitra.ai Universe ships product and customer content in every language.
The cycle is the problem
A release ships Tuesday. Notes go to a translation queue. They come back the following week, by which time there has been another release. So most teams either stop translating notes or publish them weeks late, and neither serves the customer who wanted to know what changed.
Two documents, not one
Most release notes try to serve engineers and customers at once, which is why they are hard to translate usefully.
| Item | Audience | Translate |
|---|---|---|
| Customer-visible changes | Users | Yes |
| New features and UI changes | Users | Yes |
| Breaking changes | Both | Yes, carefully |
| Bug fix IDs and internal refs | Engineers | No |
| Dependency bumps | Engineers | No |
| Security advisories | Both | Yes, and prioritise |
Splitting the customer summary from the technical changelog cuts the volume sharply and makes the translated version genuinely readable rather than a list of ticket numbers.
Write for translation at source
Release notes are drafted quickly, which is where the cost gets added.
Short sentences, no idiom, feature names exactly as they appear in the product, and no jokes — humour is the first thing to fail across languages and the last thing anyone budgets to fix.
Feature names come from the glossary rather than from whoever wrote the note, which is the difference between a recognisable release and a confusing one.
Run it on the release, not beside it
The publish event should trigger the translation, with memory handling the parts that repeat between releases — and a great deal does repeat, because the phrasing around fixes and improvements is formulaic.
Breaking changes and security notes gate for review; everything else publishes once quality control clears it.
Hardware runs the same pattern on a firmware cadence, where the version string itself must survive untouched — firmware release notes.
Do not let a language fall behind
The failure that damages trust is uneven publishing. A customer reading notes in German who finds the last three releases missing concludes the product is not maintained for them.
Publish every language together or publish the summary line in every language and link to the English detail. Both are honest. Silence is not.
FAQ
Should full changelogs be translated? No. Translate the customer-facing summary and leave bug IDs, dependency bumps and internal references in English. Splitting the two documents cuts the volume and makes the translated version readable.
Why do translated release notes arrive late? Because they go through a separate translation cycle while releases keep shipping. Triggering translation from the release itself, rather than treating it as a project, is what keeps them current.
How can release notes be made cheaper to translate? By writing them for translation: short sentences, no idiom or humour, and feature names taken from the glossary rather than invented by whoever drafted the note.
What if a language cannot keep up? Publish the summary line in every language and link to the English detail. Uneven publishing is worse — a customer who finds three releases missing in their language assumes the product is not maintained for them.
