Multilingual Reasoning

Multilingual Reasoning

This skill helps the agent perform at its highest level across all languages — not just translation, but genuine reasoning, instruction-following, and knowledge retrieval in the target language.

Core Philosophy

Do not "think in English, translate out."
This is the single biggest source of degradation in multilingual tasks. When a user writes in Arabic, solve the problem in Arabic. When they write in Japanese, reason in Japanese. Treat the input language as the language of thought, not just the language of presentation.

The goal is native-quality reasoning in the user's language, not high-quality English reasoning with a translation wrapper.

Step 1: Language Detection and Calibration

When you receive input, immediately identify:

1. Primary language of the task (use the language of the question/instruction, not any quoted examples or source material within it)
2. Script and dialect signals — distinguish e.g. Simplified vs Traditional Chinese, Brazilian vs European Portuguese, Egyptian vs Modern Standard Arabic
3. Register — formal, colloquial, academic, legal, etc. Match the user's register in your response.

If the language is ambiguous (e.g. a math problem with only symbols), default to the language of any surrounding instructions.

See references/language-calibration.md for script/dialect disambiguation guides.

Step 2: Instruction Parsing (Especially for Multi-Step or Constrained Tasks)

Multilingual instruction-following degrades primarily because constraint-tracking weakens in non-English. Combat this explicitly:

1. Extract all constraints first — before attempting the task, list every requirement embedded in the instructions. Do this in the target language to avoid losing nuance.
2. Number the constraints — even implicitly. "Respond in exactly three sentences" is constraint #1. "Do not mention price" is constraint #2. Etc.
3. Check against the constraint list before finalizing your response. This is the step most often skipped, and it's the most valuable.
4. For long or nested instructions: use a brief internal scratchpad (in the target language) to track what's been satisfied and what hasn't.

Common failure modes to avoid:

• Ignoring a constraint because it appeared mid-sentence rather than as a bullet
• Satisfying a constraint in the wrong language
• Over-satisfying one constraint while violating another (e.g. being too verbose to satisfy a length limit while trying to be thorough)

Step 3: Knowledge Retrieval — Cultural and Regional Grounding

For questions that touch on local knowledge (laws, customs, geography, history, institutions, cuisine, social norms), apply these principles:

1. Anchor to the specific country/region, not a generic global default. "How does inheritance work?" has very different answers in Japan, Egypt, Brazil, and Germany.
2. Prefer endonyms and local terminology when writing in the local language. Use the local name for institutions, places, and concepts unless the user uses the exonym.
3. Don't anglicize — avoid translating local concepts into their rough English equivalents when writing in the local language. Use the actual term.
4. If uncertain about region-specific facts, say so explicitly rather than defaulting to a Western or globally dominant answer.
5. Temporal sensitivity: laws, political structures, and social norms change. If the answer depends on a recent or potentially changed fact, flag this.

See references/regional-knowledge-anchors.md for region-specific knowledge flags.

Step 4: Mathematical and Logical Reasoning in Non-English Languages

Math and logic problems in non-English languages are harder not because the math changes, but because:

• Number words and quantifiers behave differently across languages
• Logical connectives ("if", "only if", "unless", "neither/nor") have language-specific nuances
• Word problems contain cultural context that must be interpreted correctly

Protocol for math/logic problems:

1. Parse the problem fully in the source language — identify all givens, unknowns, and constraints using the original terminology.
2. Translate only the mathematical structure (equations, logical form) into a universal representation — symbols, not words. Keep the symbolic work language-neutral.
3. Narrate the solution back in the source language, using natural mathematical phrasing for that language (e.g. Japanese uses different conventions for showing work than French).
4. Watch for false cognates and misleading translations — e.g. "billion" means different magnitudes in some European languages vs. American English.
5. For logic problems: explicitly formalize each premise before reasoning. Don't rely on intuitive parsing of ambiguous logical language.

Number system notes:

• Some languages use non-Western numeral systems or different place-value conventions in formal writing (Arabic-Indic, Devanagari, etc.) — use the system appropriate to the context.
• Large number naming: "万" (10,000) in Chinese/Japanese, "lakh/crore" in South Asian languages, "milliard" in some European languages. Never silently convert.

Step 5: Response Calibration

Before writing your final response:

Checklist:

• Is my response in the correct language and dialect?
• Have I matched the register (formal/colloquial/academic)?
• Have I satisfied all stated constraints from Step 2?
• Have I used locally appropriate terminology and cultural framing?
• Is my mathematical/logical work clearly shown and narrated in the target language?
• Have I avoided "translated English" phrasing (calques, awkward syntax from English structure)?

Translated English is the hardest failure to self-detect. Signs include:

• Passive voice overuse in languages that prefer active
• Sentence-final verb placement violated in verb-final languages
• Overly literal rendering of English idioms
• Missing politeness markers / honorific levels

When in doubt, ask yourself: Would a native speaker of this language write this?

Special Cases

When the task language and response language differ

E.g. "Here is a French text. Summarize it in English."

• Parse and understand in the source language
• Produce output in the requested output language
• Don't let the translation step lose meaning — check key terms

Code-switching and mixed-language input

• Respect the user's own code-switching choices
• Respond in the dominant language of the message
• Don't "correct" natural code-switching

Romanization and transliteration

• Use the romanization system most natural for the user's region/context
• Hepburn for Japanese (default), Pinyin with tones for Mandarin, etc.
• If the user uses a different system, match theirs

RTL scripts (Arabic, Hebrew, Persian, Urdu)

• Ensure proper logical ordering of mixed numeric/text content
• Parentheses, brackets, and quotation marks follow RTL conventions

Reference Files

Read these when needed — don't load all at once: