How do you publish release notes in several languages without retranslating them every release?

You don't retranslate release notes: you translate a list of facts established once, and each language carries only the form. When the English text is the source for the other languages, every release forces you to retranslate sentences, and any correction made on one side only creates a gap no reader can see. When the source is the list of what changed, the languages can no longer drift apart on substance.

This piece is about languages. For readers of one language (customer, team, support), see release notes for multiple audiences.

What drift looks like: one note, two weeks later

Take a fictional release from a product that publishes its release notes in French and English. The content is illustrative. The gap it describes is commonplace.

Neither note is wrong by itself. Each is incomplete, in a different way. The English reader has the warning about imports the French reader lacks; the French reader has the VAT field the English reader will never see. Nobody made a translation mistake: there was no translation, there were two write-ups.

Why retranslating each release is a trap

The mechanism is always the same. One language is the source, often the product team's. The others are produced afterward by a person, a vendor or a tool that receives text and sees neither the release nor the code. Three things follow.

1. The source text is already an interpretation. The writer chose what to keep. The translator inherits that selection without being able to challenge it.
2. Corrections don't travel back. When support reports that "the VAT field only applies to new invoices" and the French note is fixed, the English one is rarely reopened.
3. Delay creates parallel worlds. For two days, there is a single published truth, in a single language.

Same logic as for other surfaces: a text written once, away from the source of the facts, ages on its own. It's the mechanism described in documentation drift, applied to languages.

Three ways to proceed, and what each guarantees

A translation memory is a good tool and worth keeping: it fixes consistency of words. It does not fix completeness of facts, because it can't know what is missing from the text it is given. Only the third column attacks the gap in the table above.

The principle: facts first, form second

A release note contains two things of a different nature. The facts: which object changed, what it did before, what it does now, who is affected, from when. The form: tone, order, length, politeness, idioms. Facts are universal. Form is local.

Translating well means holding that separation:

• Establish the list of facts once, independent of language.
• Derive from it, for each language, a write-up that may neither add nor remove any fact.
• Keep a shared glossary for the product's words (the name of a screen, a field, a plan), so that "export" doesn't become three different things in three languages.
• Have the form reviewed by someone who reads the language; don't ask them to recheck the facts.

The test is simple: you should be able to lay the release notes of all your languages side by side and find, line by line, the same list of changes.

Where the list of facts comes from

The question that matters remains: who establishes this list, and from what? If it's a writer rereading pull requests, we're back to an individual interpretation, just moved upstream. Commit messages aren't enough either: they tell what the author chose to write that day.

The material that depends on neither a language nor a writer already exists: the diffs. That is DeployIt's principle. DeployIt reads the real code (resynchronized on every push), the git history (commits + diffs) and the customer's data through its own MCP servers, and checks the code before asserting. The question "what changed in this release?" then gets a sourced answer, the same whatever language you write it up in afterward. For the repository-side mechanics, see release notes derived from real diffs.

What DeployIt doesn't do: it doesn't translate your release notes and doesn't drive your translation tool. It provides the base of facts; translation stays with your team, your vendor or the tool of your choice. The MCP server is in early access / design partner program: the entry point is here. For the documentation side, see the help center generated from the code.

"Our vendor translates very well"

Probably, and it isn't the point. A good translator renders faithfully the text they are handed; they can't render what isn't in it. The gap in the opening table (the warning about imports, present on one side and absent on the other) is not a translation fault, and no improvement in translation will make it appear. It is fixed upstream, by what you send.

"Machine translation will do the job"

For the form, often. Current models translate a short technical note well, especially with a glossary. Their limit lies elsewhere: they are as faithful to an error as to the truth. A note that forgets a fact will be translated without it, in excellent style. Automation speeds up the second half of the work; it doesn't remove the first.

Mini-FAQ

Which language should come first? None, in fact: the list of facts comes first. If one language has to be written first, write it from that list, not from a draft.

Should every language ship on release day? Ideally yes, and the list of facts makes it possible. Otherwise, put the note's date in the late language, so the reader knows which release they are reading.

What about a note already published in two diverging versions? Fix both from the real changes, not by copying one into the other: copying would spread the error of whichever language you took as the reference.

In short

Languages drift because we retranslate texts, not because we translate badly. Establish the facts once, translate the form, keep a glossary, and check by laying the versions side by side. DeployIt can provide the base of facts (MCP server in early access, through the design partner program); it is free during early access, with paid plans arriving in January 2027.