Every multilingual Claude deployment juggles three languages that are usually conflated: the language of the input (what your users or documents arrive in), the language of the instructions (your system prompt and rules), and the language of the output (what you send back). They don't have to match — and in most enterprise systems they shouldn't all match. Systems that leave any corner of this triangle implicit end up with German answers to French questions, or English boilerplate leaking into Japanese emails. The fix is unglamorous: decide each corner explicitly and write it down.
Corner 1: input language — take it as it comes, but label it
Claude handles multilingual input without preprocessing, so the practical work is structural. Wrap incoming text in its own XML tag (<customer_message>) per Anthropic's documented structuring guidance, so language switches inside the prompt read as data boundaries rather than instruction changes. If your application already knows the input language from user settings, say so ("the message below is in Portuguese") rather than making detection Claude's job; if it doesn't, asking Claude to identify the language first — and act on it — is a reasonable single step.
Corner 2: instruction language — pick one and stay there
Many teams write instructions in English even when inputs and outputs are not, keeping one canonical prompt that every engineer can review, version, and test. That's a sound default. What matters more than the choice is consistency and clarity: the official golden rule — if a colleague with minimal context would be confused by your prompt, Claude will be too — applies doubly when the colleague is also switching languages mid-read. Avoid mixing instruction languages within one prompt, and remember that culture rides along with language: "professional tone" means different things in Tokyo and Texas. Encode the specifics ("use formal address — Sie, vous, usted — unless the customer uses informal address first") instead of hoping a one-word adjective translates.
Corner 3: output language — the one you must never leave implicit
This is where unmanaged systems fail. Without an explicit rule, the output language is inferred — usually from the input, sometimes from the instructions — and inference wobbles precisely on the hard cases: mixed-language input, quoted English text inside a Spanish email, code snippets. State the rule as policy, with the reason attached (Claude generalizes from explanations, per the best-practices docs):
<customer_message>, because the customer may not read any other language. If the message mixes languages, use the language of the majority of the text. Product names and code snippets stay untranslated."For fixed-language pipelines ("input in any language, output always in English for the case-management system"), say exactly that — and add a few-shot example or two showing a non-English input producing an English output, which anchors the behavior far better than the rule alone.
Quality and cost vary by language — measure both
Don't assume that an eval passed in English holds everywhere. Build a small per-language test set — real inputs, native-speaker-reviewed expected outputs — and run it before launch and after every prompt change, exactly as you would any regression suite. Formatting rules deserve special attention: dates, decimal separators, currency, and honorifics are where "correct but wrong for the market" answers hide.
Cost also shifts with language: the same sentence tokenizes to different token counts in different languages and scripts, so per-request costs are not uniform across markets. Rather than guessing, measure with the free token-counting endpoint (POST /v1/messages/count_tokens) using your real prompts in each target language — and note the official caveat that counts are model-specific, so recount if you change models. One related trap from the official guidance: never estimate Claude token counts with OpenAI's tiktoken tokenizer — it undercounts, and the gap widens on non-English text.
Same triangle on every platform
Language behavior is a property of the model, not the platform: the triangle works identically through Amazon Bedrock, Google Vertex AI, Microsoft Foundry, and Claude Platform on AWS. A multilingual system prompt is static by design, which also makes it cacheable everywhere. For deeper coverage of the surrounding workflow, the official documentation is the reference — the specifics of per-language model behavior aren't something to assume from a guide like this one.
Where to go next
See translation and localization workflows for the full use case, and the evaluation framework for building those per-language test sets.