LLM-Assisted and Machine Translation in Localization

NMT quality is highly content- and language-pair-dependent — "good enough for most content" is not good enough for all content.

NMT performs well for: high-frequency UI strings (short, in-context, high TM leverage), informational content with simple structure, and high-resource language pairs (en→fr, en→de, en→ja). NMT struggles with: creative marketing copy (tone and cultural adaptation), legal text (precise terminology, jurisdiction-specific terms), domain-specific jargon (new product features, technical specifications), and low-resource language pairs (en→Swahili, en→Kazakh). The industry standard today is risk stratification: MT + light MTPE for UI strings, MT + full MTPE for support content, human translation for marketing and legal. No localization engineer should recommend replacing all human translation with NMT without a quality assessment by category.

Key vocabulary:
• NMT (Neural Machine Translation) — deep learning-based MT; current industry standard (DeepL, Google Translate NMT, ModernMT)
• content risk stratification — categorising content by quality risk to determine appropriate MT+human mix
• MT hallucination — MT generating plausible-sounding but factually incorrect translations for domain terms

Full vs. light MTPE is a quality level decision — full MTPE targets human-equivalent quality; light MTPE targets "good enough to understand."

Use cases: full MTPE is appropriate for customer-facing product UI (users notice awkward phrasing), marketing content, and any content that will be published without further review. Light MTPE is appropriate for internal documentation, support knowledge base articles, and content that will be read once and discarded (transactional emails, order confirmations). The cost difference is significant: full MTPE takes 30-50% of the time of pure human translation; light MTPE takes 15-25%. The risk: using light MTPE quality for customer-facing content can damage brand perception in subtle ways — the text is technically correct but doesn't sound like the brand voice.

Key vocabulary:
• full MTPE — all errors corrected; output equivalent to human translation quality
• light MTPE — only critical errors fixed; style and minor fluency issues accepted
• post-editing effort — the amount of editing needed to bring MT output to the required quality level

QE enables intelligent routing: high-confidence MT output goes to light MTPE, low-confidence output goes to full MTPE or human translation — reducing total cost without sacrificing quality.

QE models (e.g., COMET-QE, TransQuest) are trained on parallel data with human quality annotations. They output a score (typically 0-1) for each segment. Integration in a TMS workflow: MT engine translates a batch → QE model scores each segment → TMS creates three queues: (1) >0.85 score → light MTPE queue; (2) 0.60-0.85 → full MTPE queue; (3) <0.60 → human translation queue (MT suggestion shown as a hint only). This saves 30-40% in total translation cost versus sending everything to full MTPE. The limitation: QE scores are probabilistic — some high-QE segments may still have subtle errors.

Key vocabulary:
• QE (Quality Estimation) — automated MT quality prediction without a reference translation; predicts post-editing effort
• QE score — confidence metric (0-1) for an MT segment; used to route to appropriate post-editing tier
• intelligent routing — using QE scores to direct segments to light MTPE, full MTPE, or human translation queues

MT engines treat unknown words as candidates for translation or transliteration — DNT lists prevent product and brand names from being incorrectly adapted.

Real examples of MT errors without DNT: "Firebase" → "Feuerbasis" (German, literal translation of fire+base), "Slack" → "Schlaff" (German, meaning "sluggish" — a valid German translation of the English word), "Notion" → "Vorstellung" (German). These are embarrassing product quality issues. DNT lists can be implemented in MT engines as terminology constraints (modern NMT engines like ModernMT and DeepL API support terminology injection). The TMS usually provides a DNT glossary field for each term — the MT engine is instructed to pass these terms through unchanged. The same mechanism works for technical terms that must remain in English (kubectl, npm, API endpoints).

Key vocabulary:
• DNT (Do Not Translate) — a list of terms the MT engine must preserve unchanged in the output
• terminology injection — feeding a glossary to an NMT engine at inference time to constrain translations of specific terms
• transliteration — adapting a word to the target script's phonetic representation (Firebase → Файербейс in Russian Cyrillic)

LLMs excel at nuanced, context-rich translation but are slow and expensive at scale — the right tool depends on content type, volume, and quality requirements.

LLM advantages for translation: they handle implicit context ("this button is in a mobile app confirmation dialog"), can be prompted with brand voice guidelines, adapt register (formal/informal) consistently, and handle idioms and cultural adaptation better than NMT. LLM disadvantages: (1) cost — 10-100x more expensive per segment than NMT at scale; (2) speed — 2-10 seconds per segment vs. milliseconds for NMT; (3) terminology control — harder to reliably enforce DNT and glossary constraints vs. NMT with terminology injection; (4) consistency — LLMs may produce slightly different translations for the same source segment in different API calls. Emerging workflow: NMT → QE scoring → LLM post-editing for low-QE or high-value segments.

Key vocabulary:
• LLM for translation — using generative AI models for translation; better at nuance, worse at scale economics
• tone adaptation — adjusting formality, voice, and style to match brand guidelines during translation
• hybrid MT pipeline — combining NMT (speed/cost) with LLM (quality/nuance) based on content type and QE scores