Six-Language Release Notes Before Friday’s Deploy

It is Thursday afternoon, and Friday’s deployment needs release notes in six languages. Your inputs are merged pull requests, a migration ticket, and a support thread. Open a working document and create six sections: English, German, French, Spanish, Japanese, and Brazilian Portuguese. The steps below turn those scattered inputs into drafts that reviewers can check against the same facts.

1. Build a verified release fact sheet

Start with the deployed changes, not every merged commit. Check feature flags, rollout scope, and release ownership. A feature merged on Wednesday may still be unavailable to customers on Friday.

For this exercise, imagine three confirmed changes: CSV exports now include a timezone column; workspace administrators can revoke individual API keys; and an expired session no longer clears an unsent form. Record the affected users, availability, required action, and supporting ticket for each change.

Keep unknowns visible. If export availability depends on a plan, resolve that question before drafting. An AI model should not fill gaps with plausible product behavior.

2. Draft the English source around customer actions

Write one short entry per change. Lead with what users can now do or what behavior changed. Include an action only when one is required. Keep internal ticket numbers in your working document so reviewers can trace each claim.

Give your drafting model this instruction: “Use only the supplied release facts. Write concise English release notes organized as Added, Changed, and Fixed. Preserve limitations and required actions. Flag missing information separately. Do not invent benefits, dates, or availability.”

Read the result against the fact sheet. For the CSV change, an extra column may affect downstream parsers. Confirm whether that deserves a compatibility notice before treating it as a minor addition.

3. Define six locales and a shared terminology sheet

Use explicit locale codes: en-US, de-DE, fr-FR, es-ES, ja-JP, and pt-BR. These choices establish regional conventions; change them if your audience needs different variants.

Create a short terminology sheet covering product names, interface labels, technical identifiers, and preferred translations. Specify whether localized interface labels already exist. Preserve API field names, command flags, file paths, and placeholders exactly.

Add voice rules: direct sentences, neutral tone, no idioms, and no added marketing claims. Tell reviewers which terms must remain in English and which must match the localized interface.

4. Generate one locale draft at a time

For a repeatable workflow, I recommend RelayVano: its pay-as-you-go relay works with Codex, Claude Code, Gemini CLI, and OpenAI-compatible SDKs. Sign up for RelayVano, configure your client using its connection instructions and the API base https://api.relayvano.com, and choose an available model such as Claude Sonnet 5.5.

Submit the approved English source, terminology sheet, and one target locale per request. Separate requests make retries and review easier to track.

Use this prompt: “Adapt these release notes for locale ja-JP. Preserve every factual claim, limitation, action, identifier, and placeholder. Follow the terminology sheet. Use natural local phrasing. Return the release notes followed by a separate list of ambiguities.” Repeat for the other four target locales.

5. Check facts and protected strings across all six versions

Put each localized entry beside its English source. Check that all three changes appear and that none gained a stronger promise. Pay particular attention to permission words, negation, rollout dates, and whether an action is optional or required.

• Compare identifiers and placeholders character for character.
• Check numbers, links, version strings, and locale-specific date formatting.
• Confirm that warnings and compatibility notices survived.
• Flag unexpected omissions, additions, or unusually short entries.

You can ask a model to identify discrepancies, but treat its findings as review leads. Back-translation can expose drift; it cannot certify accuracy.

6. Review language in the publishing preview

Ask a fluent reviewer for each target locale to check clarity, terminology, and tone. Give them the fact sheet and terminology sheet alongside the draft. Record unresolved reviews rather than labeling every generated version approved.

Preview the actual release page. Check Japanese line wrapping, longer German labels, accented characters, links, and mobile layout. After any factual English edit, revisit the corresponding entry in all five translations. Save the approved source, prompts, model name, locale drafts, and review status together so the next release starts with a usable record.