Writing Prompts Natively Instead of Translating Them

The question is usually posed as all or nothing: translate the English prompt, or have a native speaker write a new one. Both answers are wrong, because a prompt is not one kind of text. Some of it the model reads as instruction and some of it the model reads as a sample of what to produce, and only the second kind has to be native.

The rule

Anything in the prompt that resembles the output must be written natively. Anything that is machinery can stay in whichever language the model follows best. Examples, sample answers, tone demonstrations, glossaries, source documents and quoted text are the first kind. Task descriptions, constraints, output schemas, role statements and refusal rules are the second.

This is not a compromise between two positions. It follows from what the model is doing: continuing a sequence. The parts of the context that look like the thing being continued exert far more influence on the continuation’s surface form than the parts that describe it.

The model imitates the parts that look like output

A language model has no privileged channel for instructions. Everything in the context is tokens, and the next token is conditioned on all of them. An instruction works because instruction-following behaviour was trained in, and it competes with a much older and stronger pressure: continue in the style of what came before.

So when your prompt is a translated English paragraph, you have put a piece of translationese in the context and asked for target-language output. The nearest region of the training distribution to “translated-from-English text in language X” is the enormous body of actual translated-from-English text in language X: localised software strings, dubbed subtitles, machine-translated web pages, corporate copy run through a vendor. The continuation inherits that register. The output reads translated because the input was, and no instruction in the prompt said not to.

This is testable by the reader without any special tooling: write the same task twice, once as a translation and once from scratch by a native speaker, and read the two outputs side by side rather than the two prompts. The prompts will look equivalent. The outputs usually do not.

What a translated prompt carries with it

Translation studies has a name for the residue — interference — and the specific things that come across are consistent enough to list.

• Explicit subjects that the target language drops. English needs “you”; Japanese does not, and あなた in a Japanese instruction is a strong translationese marker. Spanish, Italian, Polish and Turkish all drop subject pronouns that a literal translation keeps.
• Calqued compounds. “A 500-word blog post” translated literally into German becomes a hyphenated construction no German writer would produce; the natural form restructures it as a postmodifying phrase.
• Politeness that lands in the wrong place. English scatters “please” through instructions. Repeating it every clause in Spanish, German or Japanese reads as either machine output or sarcasm, and in Japanese the choice between plain and polite verb forms is a register decision the translation makes accidentally, without anyone deciding it.
• Sentence rhythm. English instruction-writing favours short imperative bullets. German technical writing tolerates far longer periods; Japanese puts the operative verb last. A translated bullet list preserves English information order, and the output follows.
• Terminology that is not the field’s. A general translator renders “customer support ticket” literally; the industry in that language may have settled on an English loanword or a quite different native term. The model then produces the translator’s word consistently, and it is consistently not what practitioners say.

Instructions that do not survive translation at all

Some constraints are not merely awkward in translation — they become meaningless, and this is the strongest part of the argument because it cannot be fixed by translating better.

“Write 500 words” assumes a language that delimits words with spaces. Japanese, Chinese and Thai do not, and the native unit is the character; a Japanese brief asks for a 文字数, a character count. Translating the English instruction gives the model a specification in a unit its target language does not use, and it will either guess a mapping or ignore the constraint. German has the opposite problem: compounds mean a German text conveying the same content has fewer words and more characters, so a word budget translated unchanged silently asks for more content.

“Use bullet points”, “use sentence case” and “use title case” are similarly English-shaped. Title case does not exist in German, Spanish or Russian headline conventions. Sentence case is the only case in a language without a bicameral script. Instructions about quotation style must name the target language’s marks — the low-high pair in German, the guillemets in French with their spacing rules, the corner brackets in Japanese — or the model will use the ones in the prompt. And length constraints are entangled with tokenisation, which is its own subject: see what Japanese costs in tokens.

Where translating is fine, or better

An essay that only argued one side would be dishonest here, because there are cases where the translated prompt is the right engineering answer and one where English is actively better.

• Structured output. If the model must emit JSON against a schema, the schema is not prose and nobody reads it. Keep the keys and enum values in English — they are identifiers — and let only the string values be native. Translating field names breaks your parser for no gain.
• One template, forty locales. Maintaining forty hand-written native prompts means forty things to update when the task changes, and thirty-eight of them will drift. A single English instruction block with a language variable, plus native examples per locale, is the maintainable shape — see the language as a template variable.
• Lower-resource target languages. Instruction-following behaviour is concentrated in the languages that dominated instruction-tuning data. For a language with thin coverage, an English instruction is often followed more reliably than a native one, even though the output must be native. That is the same asymmetry examined in whether system prompt language changes output quality and prompting in a low-resource language.
• When the task is translation. Then the English is the content, and native phrasing of the instruction changes nothing about the source text.

What this looks like in a template

The rule produces a prompt with a seam in it, and the seam is deliberate. English machinery, native payload:

system:
  You write product release notes. Output the language named in
  TARGET_LANGUAGE. Follow the typographic conventions of that
  language, including its quotation marks and its list punctuation.
  Length: match the example, measured in the unit the example uses.
  Return only the release note.

  TARGET_LANGUAGE: Japanese (ja-JP)

  --- EXAMPLE (written by a native speaker, do not translate) ---
  <one real Japanese release note, in the register you want,
   with 「」 quotation marks and 、。 punctuation>
  --- END EXAMPLE ---

user:
  <the changelog, in whatever language it arrives in>

Note which half a native speaker has to touch. Not the instruction block, which is written once and shared by every locale. Only the example, which is per-language, short, and the thing the output will actually resemble. That is a manageable amount of native writing, and it is where all the leverage is — the argument continued in writing few-shot examples in the target language.