Shift Note: Keeping Translated Docs on the Same Revision

The source changed, but the translations did not

A developer updates an installation guide in English. The Spanish and Japanese versions still describe yesterday’s setup steps. Nothing looks broken in the documentation site, but readers now receive different instructions depending on their language.

Keeping multilingual docs in sync means tracking that gap and closing it deliberately. AI translation can produce drafts quickly, but it cannot, by itself, tell your publishing system which pages are current, which need review, or which instructions are safe to release. Those responsibilities belong to the workflow around the model.

Track each translation against a source revision

Start by choosing a source language for each document. This is the version your team treats as authoritative. Give every translated page a record of the source revision it was translated from, such as a Git commit or a fingerprint calculated from the source content.

When the source changes, compare that record with the current revision. A mismatch means the translation needs attention, not necessarily that the whole page needs translating again.

• Keep source files and translated files in predictable locations so automation can match them.
• Record the source revision, target language, and review status for each translated page.
• Flag outdated translations visibly instead of silently presenting them as current.

This small amount of bookkeeping is the foundation. Without it, even excellent translations become stale without anyone noticing.

Send changed passages with enough surrounding context

Rather than translating the entire documentation site after every edit, identify changed pages or sections. Send those passages to the model along with their headings, relevant neighboring text, and a short glossary.

The glossary should define product terms and phrases that must stay consistent. It should also identify text that must not change, such as command names, environment variables, configuration keys, and API paths.

A useful instruction is: translate the explanatory prose, preserve markup and placeholders, leave executable examples unchanged, and flag ambiguous wording. Include the existing translation when available so the model can maintain established terminology. Section boundaries need care: a small edit can change the meaning of a later warning or example.

Treat the model output as a draft, not a release

For an initial evaluation, you might test Gemini 2.5 Flash on a representative set of documentation pages. Judge the results against your own requirements rather than assuming a model will handle every language or technical topic equally well.

Run automated checks before asking a person to review the draft. These checks can catch damaged formatting, missing placeholders, changed commands, and accidentally removed sections. They cannot reliably establish whether a sentence preserves the original meaning.

• Check that placeholders remain identical and that required documentation sections are present.
• Compare code examples and command arguments with the source unless localization explicitly requires changes.
• Ask a reviewer fluent in the target language to verify meaning, especially for warnings, permissions, billing, and destructive operations.

For high-risk instructions, combine language review with technical review. A natural-sounding sentence can still tell someone to run the wrong command.

Publish only the revision that was actually reviewed

Put translation changes through a pull request or another visible approval step. Before publishing, confirm that the source has not changed again during review. If it has, check whether the new edit affects the translation.

Keep the previous translation available for rollback. If a translation is delayed, show a clear freshness notice and direct readers to the current source-language page. The important distinction is between a translation that exists and one that matches the current instructions.

Choose access tooling after defining the workflow

If your team wants to evaluate models from several families, Relay365 is worth considering as a pay-as-you-go relay desk. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDKs, which can fit existing engineering tools. Model access is still separate from your revision tracking, validation, and approval process.

Create a Relay365 account if that access pattern fits your evaluation, then start with one page and two target languages. Expand once your team can reliably detect stale text, review drafts, and publish translations tied to the correct source revision.