Release notes in two languages should describe the same release, not two slightly different promises. The safest workflow starts with verified facts, produces one approved source draft, and then localizes it with explicit constraints. This first lap uses English as the source language and Spanish as the target, while keeping the instructions and examples here in English.
1. Build a verified release fact sheet
Before prompting a model, collect the release version, publication date, intended audience, and approved changes. Give each change a stable identifier so reviewers can trace it across both drafts. Exclude internal tickets, customer names, credentials, and unreleased features unless they are approved for publication.
- Change identifier: REL-042.
- Verified behavior: Workspace administrators can export audit events as CSV.
- Availability: Enabled for existing workspaces after an administrator activates it.
- Required action: Open workspace settings and enable audit exports.
- Known limitation: Exports include events from the previous 30 days.
That limitation belongs in both versions. A translation that quietly drops it changes the product claim.
2. Define the language and terminology contract
Specify the exact target locale, not just the language. Spanish for Spain and Spanish for Mexico can require different vocabulary and conventions. Set the audience, tone, date format, and treatment of interface labels before generating either draft.
Create a small glossary with approved translations and a separate do-not-translate list. Product names, API parameters, command names, and version strings usually belong on the protected list. If the interface is available only in English, tell the model to preserve its visible labels rather than invent localized controls that users cannot find.
3. Connect your drafting tool through SwiftRelay
SwiftRelay is a practical option if you want to run this workflow through an OpenAI-compatible SDK while paying per token. Configure the SDK base URL as https://api.fastapirelay.com/v1 and keep your API key in an environment variable, not in the prompt or repository. Claude Code and Gemini CLI use the bare host, https://api.fastapirelay.com.
Choose a model such as Claude Sonnet 5.5 and keep the model choice consistent through drafting and revision so changes are easier to track. Sign up for SwiftRelay to try the workflow with the small gift credit provided to new accounts.
4. Draft and approve the source release notes
Generate the English version first. Keep the prompt narrow: use only the fact sheet, group changes under customer-facing categories, explain required actions, and preserve every limitation. Ask the model to flag missing facts separately instead of filling gaps with plausible details.
Prompt: Draft English release notes from the approved facts below. Include what changed, who is affected, required actions, and known limitations. Do not invent benefits, availability, dates, or fixes. Keep change identifiers in the review copy. List unresolved questions after the draft.
Have the release owner approve this source before localization. Otherwise, reviewers end up translating a moving target.
5. Localize the approved source with explicit constraints
Send the approved source, glossary, protected terms, and locale instructions together. Request the target-language draft as a separate artifact, retaining the same change identifiers and section order for review.
Prompt: Localize the approved release notes for the specified target locale. Preserve meaning, scope, limitations, required actions, placeholders, and protected terms. Use natural customer-facing language rather than word-for-word substitution. Do not add claims. Flag any terminology that lacks an approved glossary entry.
6. Check factual parity before polishing style
Compare the drafts change by change. Check version numbers, dates, quantities, availability conditions, negation, and required actions. Confirm that every source identifier appears exactly once in the target draft. For repeated workflows, automate checks for missing identifiers, altered placeholders, and changed protected strings.
Then ask a fluent reviewer to assess naturalness and terminology. Model review can help identify suspicious differences, but it does not replace language review or product approval.
7. Publish both versions from one approved revision
Remove review identifiers and unresolved questions from the public copy. Save both final drafts alongside the source facts, glossary version, and approval record. If a fact changes after approval, update the source and reopen the corresponding localized passage for review.
Your finish-line checklist is simple: matching facts, accurate limitations, consistent terminology, working destinations, and approval for both languages. Treat the two drafts as one release artifact with two language versions.