Relay365Multi-model API relay desk
← All desk bulletins
Field notes from the deskEN162 desk reads

Translate Product Copy Without Breaking Placeholders

Identify the placeholders before translating

1. Start with a small batch of product strings, such as onboarding messages or checkout notices. Identify which parts are customer-facing language and which parts belong to your application. For example, in Hello, {{first_name}}, the greeting is translatable, but {{first_name}} is an interpolation token. i18next uses this double-brace syntax by default, although applications can configure different delimiters. ([i18next.com](https://www.i18next.com/translation-function/interpolation))

Create a short inventory of the placeholder formats your project actually uses. Do not assume that every expression inside braces follows the same rules. Keep translation keys, variable names, and product identifiers separate from the text you want translated.

Prepare complete messages with useful context

2. Export each message with its stable key, source text, target locale, and a short explanation of where it appears. Include the meaning of each variable without supplying real customer information. For example, explain that {{plan_name}} contains a subscription name and must remain unchanged.

Prefer complete messages over fragments assembled around variables. The i18next guidance warns that interpolation can create grammatical problems when language-dependent words are inserted into sentences. Where possible, give translators complete alternatives rather than asking them to repair an inherently awkward template. ([i18next.com](https://www.i18next.com/principles/best-practices?utm_source=openai))

Write an explicit placeholder preservation prompt

3. Give the model a narrow contract. Specify the target locale, product tone, protected content, and required output structure. Keep instructions separate from source strings, and tell the model to treat those strings as data rather than instructions.

A reusable instruction is: Translate only customer-facing text into the requested locale. Preserve message keys and placeholder spelling, capitalization, punctuation, and occurrence counts. You may reposition named placeholders where grammar requires it. Do not add explanations or invent missing content. Return only the requested translation object.

Add one project-specific example showing an acceptable placeholder-preserving rewrite. Start with a few strings so you can inspect the results before expanding the batch.

Handle plural messages as structured syntax

4. Route ICU MessageFormat strings through a separate workflow. A message containing plural or select branches is more than ordinary prose: argument names, selectors, braces, and special characters have defined roles. The other branch is required, and plural categories depend on the locale. ([messageformat.github.io](https://messageformat.github.io/messageformat/guide/))

Do not apply a blanket rule that every plural branch must remain identical across languages. Preserve argument identities and formatting semantics while allowing locale-appropriate branches. Use a compatible parser to inspect the structure and translate message text within it; a dedicated ICU parser produces an abstract syntax tree for this purpose. ([messageformat.github.io](https://messageformat.github.io/messageformat/api/parser/))

Validate the output before accepting it

5. Make acceptance depend on automated checks, not the model's assurance that it followed instructions. For simple interpolation messages, compare the source and translated placeholder inventories, including repeated occurrences. Compare counts rather than positions so legitimate grammatical reordering remains possible.

  • Reject missing keys, unexpected keys, and values with the wrong data type.
  • Reject renamed, missing, duplicated, or newly introduced placeholders in simple messages.
  • Parse structured messages and check argument identities and valid branch structure rather than comparing raw brace counts.
  • Send failed items back with a specific error, and require them to pass validation again.

Test the translated messages inside the product

6. Render accepted strings with representative values, including long names and empty optional fields where supported. Ask a fluent reviewer to assess meaning, tone, and layout. Keep placeholder correctness and linguistic quality as separate review decisions.

Preserve your application's escaping behavior during this process. i18next escapes interpolated values by default to mitigate cross-site scripting; disabling that behavior requires appropriate handling of untrusted values. Translation is not a reason to weaken rendering protections. ([i18next.com](https://www.i18next.com/translation-function/interpolation))

Choose a relay without outsourcing quality checks

7. If you want a pay-as-you-go relay desk for comparing model families, consider Relay365 for the request-routing part of this workflow. Keep your prompt, glossary, and validation rules consistent when comparing outputs. Check current model availability, pricing, and data-handling terms before sending product content.

Create a Relay365 account when you are ready to try a small, non-sensitive batch. Whatever service you choose, retain the same release gate: preserve the application's message contract, validate the structure, and review the language before publishing.

Further desk bulletins

Curious how it runs on your own code? Sign up →