Language Detection and Branching Prompt

This prompt is designed for localization and multilingual product teams who need to automatically detect the language of a user's input at runtime and branch to language-specific system instructions, few-shot examples, and output format constraints. The core job-to-be-done is eliminating the need for users to manually select their language or for engineers to maintain separate prompt variants for every supported locale. The ideal user is an engineering lead or AI builder integrating a multilingual feature into a product where the input language is not known in advance.

Use this prompt when you have a single entry point for user requests that can arrive in multiple languages, and you need the AI system to respond in the same language with locale-appropriate formatting, tone, and examples. It is particularly valuable when your system prompt contains behavioral policies, refusal boundaries, or output schemas that must be expressed in the user's language to be effective. The prompt requires a pre-defined mapping of language codes to language-specific instruction blocks, few-shot examples, and output constraints. You must also have a reliable language detection mechanism—either a separate classifier model, a library like fasttext or lingua, or a preliminary LLM call—that produces an ISO 639-1 code before this prompt is assembled.

Do not use this prompt when the input language is always known from user profile settings, when your product only supports one language, or when the overhead of language detection and branching adds unacceptable latency to a real-time pipeline. It is also the wrong choice if your language-specific instructions are so minimal that a single multilingual system prompt suffices without branching. In high-stakes domains like healthcare or legal intake, where a language misclassification could lead to incorrect clinical instructions or contractual misunderstandings, you must pair this prompt with a human review step and a confidence threshold on the language detection signal. If the detector's confidence falls below your threshold, route to a human or fall back to a default language with an explicit disclaimer asking the user to confirm the detected language.

Before implementing this prompt, ensure you have eval checks that specifically test for language misclassification, mixed-language inputs, and code-switching within a single request. Your test suite should include edge cases like short inputs that provide little signal for detection, inputs in languages not in your supported set, and inputs that contain technical terms or brand names in a different language than the surrounding text. The next step is to define your language-to-instruction mapping and wire the detection signal into your prompt assembly logic so the correct branch is selected before the model receives the assembled prompt.

This template provides the core logic for a language-detection-and-branching prompt. It is designed to be the single entry point for multilingual workflows. The prompt first classifies the user's input language, then dynamically selects and applies a set of language-specific rules, few-shot examples, and output format constraints. This pattern prevents the need for duplicating entire prompt templates for each supported language and centralizes the branching logic for easier maintenance and testing.

textCopy
You are a multilingual assistant. Your first task is to accurately detect the language of the user's input.

Follow these steps precisely:
1.  Analyze the user's input in [USER_INPUT] and determine its primary language. Output the language as a BCP-47 language tag (e.g., 'en', 'es', 'fr', 'de', 'ja').
2.  Based on the detected language, select the corresponding instruction block from the [LANGUAGE_RULES] provided below.
3.  Apply the selected instruction block to generate your response. This includes adhering to the specified tone, using the provided few-shot examples, and structuring your output according to the defined [OUTPUT_SCHEMA].
4.  If the detected language is not found in [LANGUAGE_RULES], default to the 'en' instruction block and note this fallback in your reasoning.
5.  If the input contains multiple languages, identify the dominant one and proceed. If you cannot determine a dominant language, default to 'en'.

--- LANGUAGE RULES ---
[LANGUAGE_RULES]

--- USER INPUT ---
[USER_INPUT]

--- OUTPUT SCHEMA ---
[OUTPUT_SCHEMA]

--- CONSTRAINTS ---
[CONSTRAINTS]

To adapt this template, you must define the [LANGUAGE_RULES] placeholder with a structured list of language-specific configurations. Each configuration should include the BCP-47 tag, a localized system instruction, a set of few-shot [EXAMPLES], and any language-specific [OUTPUT_SCHEMA] overrides. The [CONSTRAINTS] placeholder is for global rules that apply regardless of the detected language, such as safety policies or refusal boundaries. Before deploying, validate that the prompt correctly resolves all placeholders and that the branching logic is covered by your evaluation suite, specifically testing for language misclassification and mixed-language inputs.

The language detection prompt is a preflight step that runs before the main task prompt. In a production harness, you call this prompt first, parse its structured output, and use the detected language code to select the correct downstream prompt variant, system message, few-shot examples, and output schema. Do not rely on the model's implicit language detection inside the main task prompt—explicit branching gives you auditability, testability, and control over what happens when detection is uncertain or wrong.

Wrap the detection call in a thin service function that accepts the user input string and returns a language decision object with at least language_code (ISO 639-1), confidence (0.0–1.0), and detection_notes. Validate the output before branching: reject language codes not in your supported set, flag confidence below a configurable threshold (start at 0.85), and log every detection result with the input hash, detected language, confidence, and model version. If confidence is below threshold or the language is unsupported, branch to a fallback path—either ask the user to clarify, route to a human review queue, or use a default language with a disclaimer. For mixed-language inputs, check the detection_notes field for signals like 'mixed', 'code-switched', or multiple language mentions, and decide whether to extract the dominant language or escalate.

Model choice matters here. Smaller, faster models (GPT-4o-mini, Claude Haiku, Gemini Flash) handle language detection reliably at low latency and cost. Reserve larger models for the downstream task, not detection. Implement a lightweight retry with a max of two attempts: if the first call returns malformed JSON or a missing language_code, retry once with a stricter schema instruction. After two failures, log the input and fall back to your default language. Wire detection latency into your observability dashboard alongside confidence distributions and fallback rates. The most common production failure mode is not misclassification—it's the detection prompt returning a valid but unsupported language code that your downstream system silently ignores, causing the main prompt to run with wrong assumptions. Validate the code against your supported set before branching.