Should You Translate First or Prompt Natively for a Non-English Task

The usual advice is a blanket one — either “always translate to English, models are better at English” or “never translate, you lose nuance”. Both are defensible and both are wrong as general rules, because they answer a question about language when the decision actually turns on what the output has to be true to.

The question is not which is better

Pivoting through English adds a step, and every step adds error. The argument for adding it anyway is that models are demonstrably stronger in English, so the second step is more reliable than the single native step would have been. Whether that trade pays depends on something the usual framing leaves out: whether errors in the pivot compound with the task, or merely accompany it.

Consider the same input under two tasks. Take a French customer email containing an order number, a date and a complaint.

Task A — extraction:
  Return the order number, the date, and a complaint category.
  Output: {"order": "FR-88213", "date": "2026-03-04",
           "category": "late_delivery"}

Task B — generation:
  Write a reply the customer will read.
  Output: several sentences of French prose.

In Task A the output does not contain any French. In Task B the output is entirely French. That structural difference, not the difficulty of French, is what decides the pipeline.

Extraction: translate first

For extraction, classification, routing, tagging and structured output, translating to English first is usually the better pipeline, and the reason is that translation errors mostly do not survive into the output.

The fields being extracted are largely language-invariant. An order number is a string; a date is a date; a category comes from a closed list you defined. A translation that renders a phrase awkwardly, drops a politeness marker, or picks a slightly wrong synonym changes none of them — the information is still there and still findable. The translation is a lossy channel, and extraction is robust to exactly the kind of loss it introduces.

Meanwhile the gain is real. The instruction-following behaviour that extraction depends on — obeying a schema, returning valid JSON, choosing from an enumerated set, refusing to add fields — is trained far more heavily in English than elsewhere. Schema adherence degrades in lower-resource languages before comprehension does, so a native pipeline can understand the email perfectly and still return malformed output. That is the failure the pivot avoids.

There is a specific exception worth carving out: extraction of names, addresses and other proper nouns. Translation systems translate things that should have been transliterated, and a name that arrives as a translated common noun is unrecoverable. If proper nouns are among the fields, extract them from the source text and only pivot for the rest — the general form of that problem is in transliterating rather than translating names.

Generation: prompt natively

For anything a human will read in the target language, prompt natively. Here the translation error does not stay in the middle of the pipeline; it is the product.

Generating in English and translating out produces text with a recognisable quality often called translationese: correct grammar, correct vocabulary, and sentence structures that are calques of the English. Register is where it fails hardest. English business writing has a directness that maps badly onto Japanese, where the level of politeness is grammatically encoded and choosing it is not optional; a translation step must pick one, and it picks from context it does not have. German formal address, Korean speech levels and the Spanish tú/usted distinction all have the same problem: the source text did not encode the distinction, so the translator guesses, and the guess is visible to every reader.

Native generation also gets the conventions right for free — the greeting and closing formulae, the ordering of information, the placement of the ask. These are cultural rather than linguistic, they are present in the model’s training data for that language, and a translation step cannot introduce them because they were never in the English draft to begin with. The prompt-side version of this argument is in writing prompts natively rather than translating them.

The rule, and the cases it does not cover

The decision rule that falls out: pivot when the output is language-independent; stay native when the output is the language. Reformulated as a question you can ask about any task — does a translation error in the middle appear in the final output? If no, pivot. If yes, do not.

Two families of task sit awkwardly against it.

Summarisation is genuinely split, because it is extraction and generation at once. A summary must be faithful to a source in one language and readable in another. The resolution is to split it: read and summarise in the source language, then translate the summary if the reader needs another language. Summarising a translation compounds two lossy steps in the same direction, and the result reliably drops the details the translation weakened.

Reasoning tasks in low-resource languages are the case where the rule can be overridden by capability. If a model is weak enough in the language that it cannot follow a chain of reasoning, no amount of nativeness helps; translating the problem to English, solving it, and translating the answer back can genuinely win even for generation. This is the practical content of chain-of-thought language mismatch. It is an override for a specific capability gap, not a refutation — and it should be verified on the model in front of you rather than assumed.

Note that the rule never mentions how good the model is at the language. That is deliberate. Model capability is the tiebreaker, not the primary axis, and treating it as primary is what produces the blanket advice this page is arguing against.

The third option most people skip

Both branches assume the prompt and the content share a language. They need not. An English prompt with native-language content, and an explicit instruction to answer in the content’s language, is frequently the strongest configuration available and is rarely tried.

system: You extract structured data from customer emails.
        The email may be in any language. Do not translate it.
        Return JSON with keys: order_id, date_iso, category.
        category must be one of: late_delivery, damaged,
        wrong_item, billing, other.

user:   [the original French email, untouched]

This keeps the instruction-following in the language where it is strongest while leaving the source text unaltered, so nothing is lost in a pivot that never happens. It works because instruction adherence and content comprehension are separable capabilities — a model can obey an English schema instruction while reading French, and it usually does this better than it obeys a French schema instruction.