Translation

Translate text, documents, and content between languages with attention to context, tone, and cultural nuance.

When to Use

• User wants text translated between languages
• User needs a document, email, or webpage localized
• User wants to understand foreign-language content
• User needs culturally adapted content (not just word-for-word translation)
• User wants multilingual versions of their content

When NOT to Use

• Code localization / i18n implementation (use create-artifact skill)
• Writing original content in a specific language (use content-machine skill)

Methodology

Step 1: Understand the Context

Before translating, clarify:

• Source and target language(s)
• Content type: Casual text, business document, marketing copy, technical/legal, creative/literary
• Audience: Who will read the translation? (formal vs. informal register)
• Purpose: Information transfer, marketing impact, legal accuracy, or cultural adaptation?
• Tone: Should the translation match the original tone or adapt for the target culture?

Step 2: Translation Approach

Choose the right approach for the content type:

Step 3: Translate

Translation principles:

• Translate meaning, not words — convey the intent, not a word-for-word mapping
• Preserve tone and register — formal stays formal, casual stays casual
• Handle idioms properly — find equivalent expressions in the target language, don't translate literally
• Maintain formatting — preserve bullet points, headers, bold/italic, links
• Keep proper nouns as-is unless there's a standard localized form
• Preserve technical terms — use established translations from the field, don't invent new ones

Formality — The T-V Distinction

Many languages force you to pick a formality register for "you." Get this wrong and the whole translation reads off. Ask the user or default to formal for business.

Locale Data — Don't Guess, Use CLDR

Dates, numbers, and currencies follow Unicode CLDR (Common Locale Data Repository — what every OS and browser uses). Don't hardcode formats; look them up per locale:

In Python:

babel.dates.format_date(d, locale='de_DE')

Text Expansion — Plan for It

English → other languages changes length. Critical for UI strings, button labels, and anything with character limits:

Eingabeverarbeitungsfunktionen

UI rule of thumb: design with 35% horizontal slack. Tell the user if their 12-char button label becomes 22 chars in German.

Tooling — When to Use What

deep-translator

deepl

translate-toolkit

QA — Back-Translation

For high-stakes content (legal, medical, safety warnings): translate source→target, then independently translate target→source, then diff semantically against the original. Divergences flag ambiguity or drift. Don't use the same model/prompt for both directions — you'll get confirmation bias. This catches errors but is NOT proof of correctness; it's a smell test.

Glossary Injection

For multi-document projects, build a termbase (JSON of

{source_term: target_term}

Best Practices

1. Specify the locale, not just the language —

   es-MX

   ≠

   es-ES

   ≠

   es-AR

   (vocabulary, formality, vos vs tú)
2. Flag transcreation — when you significantly adapt rather than translate (slogans, jokes), tell the user what you changed and why
3. Preserve placeholders exactly —

   {name}

   ,

   %s

   ,

   {{count}}

   must survive unchanged and in grammatically valid positions
4. Pluralization is hard — English has 2 forms (1 item / 2 items); Russian has 3; Arabic has 6. CLDR plural rules define these.
5. RTL is layout, not translation — Arabic/Hebrew/Persian text is RTL but numbers and embedded Latin stay LTR. Flag it; don't try to "fix" it in the text.

Limitations

• AI translation may miss subtle cultural nuances a native speaker would catch
• Legal and medical translations should be reviewed by a certified professional
• Poetry, humor, and wordplay may lose their effect — note this when it happens
• Cannot verify pronunciation for audio/speech contexts
• Some specialized terminology may not have established translations