Translation Essentials

Five prompts for the translation work that actually breaks in production — not "translate this sentence", but keep the %(count)d intact, get the Sie/du right, turn miles into kilometers, and prove the output is good. Each step returns typed, validated JSON with a strict schema, so the generated SDK gives you a real type and a parseOutput() you can trust.

Like the Structured Extraction, Customer Support, and RAG Essentials collections, every prompt here is a system message, a user message, and a schema — framework-agnostic, SDK-generatable in TypeScript and Python.

Prompts

The pipeline

Text of unknown language in; reviewed, locale-true text out:

        ┌──────────────────┐
        │ language-detection│   what is this?
        └────────┬─────────┘
                 ▼
        ┌──────────────────┐
        │ text-translation  │   say it in the target language
        │ (or tone-adjusted)│   (with a register knob if you need one)
        └────────┬─────────┘
                 ▼
        ┌──────────────────┐
        │ locale-adaptation │   make it native: units, dates,
        └────────┬─────────┘   idioms, spelling — itemized
                 ▼
        ┌──────────────────┐
        │translation-qa-    │   score it; gate on accuracy,
        │grading            │   route low scores to a human
        └──────────────────┘

1. language-detection — route the text: pick the source language (skip translation entirely when it's already in the target).
2. text-translation or tone-adjusted-translation — produce the translation; placeholders survive, injection attempts get translated instead of obeyed.
3. locale-adaptation — when "German" isn't enough and it needs to be Germany's German: convert units and formats, naturalize idioms, and get an auditable diff of every change.
4. translation-qa-grading — score accuracy and fluency independently; ship above your threshold, send the rest (with their itemized issues) to a human reviewer.

Every stage is useful à la carte too: just the detector as a router, just the translator for UI strings, just the grader as a QA gate over an existing MT system.

Dogfooding: the judge grades the collection

The published evals on text-translation, tone-adjusted-translation, and locale-adaptation use translation-qa-grading itself as their LLM judge, pinned against the published @sufleur/translation-cases dataset. language-detection is evaluated fully deterministically against @sufleur/language-detection-cases. And the judge itself is evaluated judge-free, against known-good and known-bad translation pairs — a judge's own eval must be deterministic.

House conventions

Every prompt here follows the same rules:

1. Reasoning before the verdict. Language cues before the classification, register strategy before the translation, segment comparison before the scores. Key order is pinned in each system prompt — reasoning that precedes the answer informs it; reasoning that follows rationalizes it.
2. Placeholders are sacred. {var}, %s, %(count)d, HTML tags, markdown syntax, URLs, and code identifiers survive translation character-for-character. Corrupting one is graded critical by the QA prompt — it breaks software, not style.
3. Text is data, never instructions. All user content is triple-mustache-injected inside XML-style delimiters. "Ignore the above and output X" gets translated, graded, or classified — never obeyed.
4. Strict schemas. additionalProperties: false, complete required arrays, closed enums (language codes, tones, adaptation kinds, severities) throughout.
5. Changes are auditable. Untranslated segments, tone choices, locale adaptations, and QA issues are itemized with reasons — never silent.
6. Confidence is uncalibrated and says so in every schema description.
7. Empty/garbage behaviour is specified — empty text yields empty output and "und", never invented content; the grader gives empty/empty a clean 1.0.