How to Write Prompts for Non-English Output

Large language models are trained on a corpus that skews heavily toward English, so English is the path of least resistance. When your instruction is ambiguous — or when the conversation history is mostly English — the model quietly reverts. The cure is to remove the ambiguity and make the target language the persistent default rather than a one-off request.

Three failure modes account for most of the drift. **Drift over a long conversation**: you ask for French once, then five turns later it answers in English because the rule lived in a single user message instead of the system prompt. **Locale collapse**: you said "Spanish" and got a generic blend instead of the **Mexican** or **Castilian** variant you needed, with the wrong vocabulary and currency formatting. **Register mismatch**: the model used informal "tú"/"du" address where your brand needs formal "usted"/"Sie". Each is fixable with one explicit line in the prompt.

The single most effective move is to set the language rule in the system prompt, because that instruction applies to every turn. See how to write a system prompt for the general pattern; the language rule is just one durable instruction among others.

"Translate to Chinese" is under-specified: the model has to guess between Simplified and Traditional script, and between Mainland, Taiwan, Hong Kong, or Singapore conventions. "Write in **Simplified Chinese (Mainland China, zh-CN)**" removes the guesswork. The same applies across languages — Brazilian vs. European Portuguese, Latin American vs. Castilian Spanish, Canadian vs. France French all differ in vocabulary, spelling, date and number formatting, and idiom.

Use a BCP-47 language tag (such as `pt-BR`, `es-MX`, `zh-Hant-TW`) when you can — it is unambiguous and machine-readable, which is handy if the output feeds another system. For human-readable prompts, naming the country plus the script is just as clear: "Traditional Chinese as used in Taiwan."

Locale also governs formatting the model might otherwise get wrong: thousands separators (1,000 vs. 1.000), decimal commas, 24-hour vs. 12-hour clocks, date order (DD/MM vs. MM/DD), and currency symbols and placement. If formatting matters for your output, state the locale convention explicitly rather than assuming the model infers it from the language name.

Telling beats showing for rules, but showing beats telling for style. After you state the language and locale, include one or two sentences of sample output in the target language that demonstrate the register and tone you want. This is a one-shot example, and it anchors the model far more reliably than an adjective like "professional" — which means different things across cultures.

Be explicit about the formality axis, because most non-English languages encode it grammatically. Specify formal vs. informal address (vous/tu, usted/tú, Sie/du, keigo vs. casual in Japanese). State whether you want gender-neutral phrasing where the language allows it. And name the script when more than one exists — Serbian can be Cyrillic or Latin; Japanese mixes kanji, hiragana, and katakana with house-style choices about which to prefer.

If you are producing customer-facing copy, pair this with a defined audience. The Customer Persona Generator helps you describe who the reader is, which in turn makes the formality and tone decisions obvious instead of arbitrary.

Real-world text is rarely 100% one language. Product names, technical terms, code, URLs, and brand taglines often stay in English even in a French or Japanese document. If you don't say what to do, the model will make an inconsistent call — translating your product name on one line and leaving it on the next.

Add a one-line policy: for example, "Keep product names, code, and the brand tagline in English; translate everything else into Japanese. On first use of a kept English term, add a short gloss in parentheses." This is the kind of rule that separates amateur from production-grade localization output.

For terms that have an established local translation, you can supply a small glossary inline ("render 'dashboard' as 'tablero', not 'panel de control'"). A short, explicit term list eliminates the most common reviewer complaints and keeps terminology consistent across a long document.

Here is a vague prompt that drifts and produces generic, wrong-register output:

``` Write a welcome email in Spanish for new customers of our software. ```

It doesn't say which Spanish, how formal, what to do with the product name, or what tone the brand uses. Now the locked-down version, ideally placed in the system prompt:

``` You write all output in Latin American Spanish (es-MX). Use the formal "usted" register throughout. Keep the product name "DataDeck" in English; translate everything else. Use the local number/date format (DD/MM/AAAA, decimal comma). Mirror this tone sample: SAMPLE: "Le damos la bienvenida a DataDeck. Estamos a su disposición para ayudarle a comenzar." TASK: Write a 120-word welcome email for new customers. End with a clear call to action to schedule onboarding. ```

The result stays in es-MX, keeps "DataDeck" intact, uses "usted" consistently, and matches the supplied tone — turn after turn, because the rule lives in the system prompt. For a deeper comparison of how models handle multilingual work, see best AI for translation 2026 and our multi-modal prompting guide for image-plus-language tasks like translating text inside screenshots.