Why Context-Aware Translation Changes Everything

"Bank" means a financial institution or the side of a river. "Crane" is a bird or a machine. "Set" has over 400 definitions in English. Traditional machine translation handles these by picking the statistically most likely meaning — which works until it doesn't.

Google Translate translating "I went to the bank to fish" into German might produce "Ich ging zur Bank, um zu fischen" — which literally means going to the financial institution to fish. A context-aware system that reads the full paragraph about a fishing trip would pick "Ufer" (riverbank) instead.

This isn't a contrived example. Polysemy — words with multiple meanings — is one of the top sources of machine translation errors, and it affects every language pair.

The scale of the ambiguity problem

English has an unusually high number of polysemous words compared to other European languages. Some common ones that cause translation errors:

• "right" — correct, direction, legal entitlement (German: richtig, rechts, Recht)
• "match" — game, to correspond, fire starter (Japanese: 試合, 一致する, マッチ)
• "spring" — season, water source, coil, to jump (Spanish: primavera, manantial, resorte, saltar)
• "draft" — rough version, air current, military conscription, beer from tap
• "charge" — accusation, electrical, cost, attack, responsibility

Sentence-level NMT picks the most common translation in its training data. For "draft," that's usually "rough version" (Entwurf in German). So "there's a draft in here" about a cold air current gets mistranslated.

How LLMs solve disambiguation

LLMs don't translate word by word or even sentence by sentence in the traditional sense. They process the full input as a coherent text and generate the translation with full awareness of context. This means:

Surrounding sentences disambiguate. If the previous sentence mentions a river and a fishing rod, the model knows "bank" means riverbank.

Domain context narrows options. A document about banking software uses "bank" financially 99% of the time. The model picks up on this from the overall content.

Stylistic consistency follows naturally. If the first paragraph uses formal language, the model continues in formal register.

But there's a catch: the LLM only has the context you give it. If you send individual strings for translation — which is how most i18n workflows work — you're throwing away all the context that makes LLM translation better than NMT.

API patterns for providing context

The simplest approach is to send surrounding text alongside the string you're translating:

{
  "text": "Check your balance",
  "context": "This button appears on the banking dashboard where users can view their account balance and recent transactions.",
  "targetLanguage": "de"
}

Without context, "Check your balance" could be about physical balance (equilibrium), a checkbook balance, or checking one's emotional balance. With the context, it's unambiguously "Kontostand prüfen."

Some translation APIs support structured context:

{
  "text": "Spring cleaning sale",
  "context": {
    "domain": "e-commerce",
    "category": "seasonal promotions",
    "tone": "casual, friendly",
    "previousText": "Welcome to our annual spring event!"
  },
  "targetLanguage": "ja"
}

auto18n accepts a context field on every translation request specifically for this reason. Even a short phrase describing where the string appears improves translation accuracy measurably.

Practical examples of context fixing real errors

Example 1: "Post"

Without context, translating "Post" to German gives "Post" (mail) or "Beitrag" (contribution/article) with roughly equal probability.

• Context: "Social media dashboard" → "Beitrag" (social media post)
• Context: "Blog editor publish button" → "Veröffentlichen" (to publish — the action)
• Context: "Mail delivery tracking" → "Sendung" (postal delivery)

Three completely different translations for the same English word, all correct in their context.

Example 2: "Save"

• In a document editor → 保存する (hozon suru — save to disk) in Japanese
• In a banking app → 貯蓄する (chochiku suru — save money)
• In a game → セーブする (seebu suru — save game progress)
• In a rescue context → 救う (sukuu — to rescue)

Example 3: "Table"

• In a restaurant app → mesa (Spanish)
• In a database UI → tabla (Spanish)
• In a furniture store → mesa (Spanish, same word but different mental model)
• In statistics → tabla/cuadro (Spanish, depends on formality)

Beyond single words: sentence-level ambiguity

The disambiguation problem isn't limited to individual words. Full sentences can be ambiguous:

"I saw her duck." — Did you see her duck (the bird) or see her duck (the action of ducking)?

"The chicken is ready to eat." — Is the chicken prepared as food, or is the chicken hungry?

"Visiting relatives can be boring." — Is visiting them boring, or are the relatives who are visiting boring?

English is particularly prone to this because of its lack of case markings and flexible word order. Languages with more grammatical structure (German, Russian, Japanese) force the translator to resolve these ambiguities. Without context, translation engines guess.

Implementing context in your i18n pipeline

For UI strings, the most practical way to add context is at the source:

{
  "save_button": {
    "message": "Save",
    "context": "Button in document editor toolbar to save current file"
  },
  "save_money_label": {
    "message": "Save",
    "context": "Label in banking app for savings account section"
  }
}

ICU MessageFormat and many i18n libraries support description/context fields. These get passed to translators (human or machine) and dramatically improve accuracy.

For longer content (docs, marketing copy, support articles), send the full document or at least the surrounding paragraphs. Don't chop content into individual sentences before translating — you're actively destroying the information that makes good translation possible.

# Bad: translating sentences individually
for sentence in split_sentences(document):
    translated = translate(sentence, target="de")
# Good: translating with paragraph context
for paragraph in split_paragraphs(document):
    translated = translate(paragraph, target="de")
# Best: translating the full document
translated = translate(document, target="de")

The tradeoff is cost and latency — translating a full document in one API call uses more tokens than translating just the changed sentence. A cache that stores segment-level translations but sends paragraph-level context for new segments is the right balance.

Comparing context-aware vs context-free translation

I ran an informal test: 200 ambiguous English sentences translated to German, Japanese, and Spanish. Each sentence had at least one word with multiple possible translations depending on context.

Results (accuracy judged by native speakers):

| System | No context | With 1-sentence context | With paragraph context | | ---------------- | ---------- | ----------------------- | ---------------------- | | Google Translate | 64% | N/A (no context input) | N/A | | DeepL | 71% | N/A | N/A | | GPT-4 (bare) | 73% | 85% | 91% | | Claude (bare) | 72% | 86% | 92% |

The jump from "no context" to "1-sentence context" was the biggest improvement. Adding a full paragraph helped but with diminishing returns. The key takeaway: even a short context description eliminates most ambiguity errors.

Google Translate and DeepL don't accept context inputs at all (as of early 2026), which puts a hard ceiling on their accuracy for ambiguous content. That's the fundamental architectural limitation of traditional NMT — it wasn't designed for this.

The bottom line

If you're translating anything beyond simple, unambiguous strings like "Cancel" and "OK," context is the single highest-impact thing you can do to improve quality. It doesn't cost much extra (a few additional tokens), it doesn't require human involvement, and it addresses the most common category of machine translation errors.

The shift from context-free to context-aware translation is the real reason LLM-based translation outperforms traditional MT — it's not that the models are better at language (though they are), it's that they can actually use the context you provide.