Bilingual translation template for GLM
A template that translates while preserving tone, formatting, and domain terminology with GLM.
#writing #multilingual
What vetted this — trust report
Template
Translate the text below into {target_language}. Produce a translation a native
speaker would write — natural, not literal — while staying faithful to meaning.
Preserve exactly:
- Markdown structure, code blocks, inline code, link targets, and HTML tags. Translate link text; never translate a URL.
- Proper nouns, brand names, product names, and code identifiers.
- Numbers, units, and dates — localize the format only if
{localize_formats}= yes. Never convert a currency or unit value silently; if conversion is wanted, keep the original in parentheses. - Placeholder tokens (
{name},%s,{{count}}) character-for-character, including their order if the target grammar allows — and if it does not, flag it rather than reordering silently.
Match:
- Tone and register. Marketing stays punchy, legal stays precise, docs stay neutral. Do not upgrade casual source text into formal target text — this is the most common way a translation is technically correct and practically wrong.
- Formality level:
{formality}— where the target language grammaticalizes it (tu/vous, du/Sie, 你/您, plain/polite Japanese), state which you used.
Terminology:
- Use this glossary for domain terms, consistently throughout:
{term_a} -> {translation_a} {term_b} -> {translation_b} - For a term not in the glossary with no clean equivalent: keep the source term and add a first-use gloss in parentheses. Do not invent a calque.
- Never translate the same source term two different ways in one document.
Output:
- The translation only, formatting intact.
- Under
--- Notes ---:- any term you had to interpret, and the interpretation you chose
- any phrase that doesn't translate cleanly, and the tradeoff you made
- any place the source is ambiguous and the target forces you to disambiguate
- any placeholder whose position had to change
- Under
--- Glossary additions ---: terms you had to decide on that should be added to the glossary for next time.
Source language: {source_language}
Target language: {target_language}
Formality: {formality}
Localize formats: {localize_formats}
Text:
{paste source text here}
Why the Notes section is the point
A translation without notes is unreviewable. The reviewer sees fluent target- language text and has no way to know which sentences were judgement calls. The notes turn a black box into a diff you can argue with — and the Glossary additions section means the second document costs less than the first, because the decisions accumulate instead of being remade.
Filling the slots
{formality}— get this wrong and everything else stops mattering. German software docs are typically Sie; a startup's landing page might be du, and the choice is a brand decision, not a translation one. Ask before you guess.{localize_formats}— usually yes for marketing (dates, thousands separators, decimal commas), usually no for technical documentation where a reader may be matching the string against a log.- The glossary is the single highest-leverage input. Even five entries eliminate most of the inconsistency that makes machine translation feel machine-made. Build it once per project and reuse it.
Quality checks
- Back-translate a sample. Take three sentences, translate back to the source language in a fresh session, and compare meaning — not wording. Drifts show up immediately.
- Diff the structure. Same number of headings, list items, code blocks, and links? A structural mismatch means content was merged or dropped.
- Grep the placeholders. Every
{token}present in the source must appear in the output. Automate this; it's the most common shipping bug in localized UI. - Read the notes first. If the notes are empty on a nontrivial document, the model isn't reflecting — it's asserting.
- Have a native speaker read the first page. Not the whole document; the first page. Systemic register problems are visible in one page, and that's what you actually need a human for.
Known traps
- Expanding text. Most target languages run longer than English — German and Russian noticeably so. If the string lands in a fixed-width UI, say so in the prompt and give a character budget.
- Idioms translated literally, or worse, replaced with a target idiom that carries different connotations. The notes section is where this gets caught.
- Pluralization rules. Languages with more than two plural forms need the plural categories, not a translated sentence. Hand those to the localization framework, not to prose translation.
- Right-to-left targets mixing in LTR code identifiers. Check the rendered output, not just the string.
- Consistency across documents. Same glossary file, every time, or your product will call one feature three names.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.