Language Detection for Translation Layer Routing Prompt

This prompt is for platform engineers who need to automatically detect the source language of user-generated text and route it to the correct translation model before downstream processing. Use it when your application ingests multilingual content and must decide: is translation needed? Which translation model should handle this? Is the detection confidence high enough to proceed automatically, or should this text be flagged for human review? This playbook assumes you have a translation layer with multiple language-pair models and need a reliable classification step that produces structured, machine-readable routing decisions.

The ideal user is an AI infrastructure engineer or backend developer building a multilingual product where wrong-language routing degrades output quality and user trust. You should have a defined set of supported language pairs, translation models mapped to those pairs, and a routing mechanism that can consume the structured output this prompt produces. The prompt expects raw text input and returns a language code, a confidence score, a translation-needed boolean, and a recommended model identifier. Wire this into your request pipeline before any translation API call, and use the confidence score to gate automated translation: high-confidence results route directly, while low-confidence results trigger clarification or human review.

Do not use this prompt for general language identification without translation routing, for locale detection (use the Locale Identification Prompt), or for detecting languages in code-switched utterances where per-segment routing is required (use the Code-Switching Segment Identification Prompt). Avoid this prompt when your pipeline handles only monolingual content in a known language, when you need script detection without language classification, or when your translation layer is a single catch-all model that doesn't require routing decisions. For short queries under 10 characters, expect degraded confidence and plan a fallback path—this prompt works best on inputs with at least a full sentence of context.

This template is the core instruction set you will send to the model. It is designed to be stateless and deterministic: given the same input and parameters, it should produce the same routing decision. The prompt forces the model to output a structured JSON object containing the detected language code, a confidence score, and a routing action. Before integrating this into your application, you must replace every square-bracket placeholder with your specific values, such as your supported language list, your translation model identifiers, and your minimum confidence threshold.

codeCopy
SYSTEM:
You are a language detection router for a translation pipeline. Your only job is to analyze the provided text and output a strict JSON object. Do not translate the text. Do not answer questions. Do not explain your reasoning.

INPUT_TEXT:
[USER_INPUT]

SUPPORTED_SOURCE_LANGUAGES:
[SUPPORTED_LANGUAGES_LIST]

TARGET_TRANSLATION_LANGUAGES:
[TARGET_LANGUAGES_LIST]

TRANSLATION_MODEL_MAP:
[MODEL_ROUTING_MAP]

MINIMUM_CONFIDENCE_THRESHOLD:
[CONFIDENCE_THRESHOLD]

OUTPUT_SCHEMA:
{
  "detected_language": "ISO 639-1 code or 'unknown'",
  "confidence_score": 0.0-1.0,
  "requires_translation": true/false,
  "routing_target": {
    "translation_model": "model_id or null",
    "target_language": "ISO 639-1 code or null",
    "action": "translate | skip | escalate_to_human"
  },
  "ambiguity_flag": true/false,
  "rationale": "Brief, single-sentence explanation of the routing decision."
}

RULES:
1. If the confidence_score is below [CONFIDENCE_THRESHOLD], set action to 'escalate_to_human'.
2. If the detected language is already in [TARGET_LANGUAGES_LIST], set action to 'skip'.
3. If the detected language is not in [SUPPORTED_LANGUAGES_LIST], set action to 'escalate_to_human'.
4. For mixed-language input, set ambiguity_flag to true and base the primary language on the majority proportion.
5. For inputs under 20 characters, automatically set confidence_score to a maximum of 0.7 unless the language is unambiguous.

To adapt this template, start by defining your [SUPPORTED_LANGUAGES_LIST] and [TARGET_LANGUAGES_LIST]. These lists directly control the routing logic. Next, populate the [MODEL_ROUTING_MAP] with the specific model identifiers your application uses for each language pair (e.g., {'es':'model-es-v2', 'de':'model-de-v3'}). Finally, set the [CONFIDENCE_THRESHOLD] based on your risk tolerance; a threshold of 0.85 is a common starting point for automated pipelines, but for high-stakes content like legal or medical text, you should lower the threshold for escalation to ensure more human review. After replacing the placeholders, test the prompt with the eval cases described in the 'Testing and Evaluation' section of this playbook before any production deployment.

The language detection prompt is not a standalone utility; it's a decision point in a translation routing pipeline. The harness must accept raw text, invoke the prompt, validate the output against a strict schema, and use the result to either route to a translation model, skip translation, or escalate for human review. The core contract is simple: the prompt returns a JSON object with detected_language (ISO 639-1 code), confidence (0-1 float), requires_translation (boolean), and recommended_model (string or null). Everything downstream depends on this contract being honored.

Start with input preprocessing. Strip leading/trailing whitespace but preserve internal formatting. If the input is shorter than [MIN_CHARACTER_THRESHOLD] characters, prepend a system note: [SHORT_TEXT_WARNING] so the model knows to lower confidence. For inputs exceeding [MAX_CHARACTER_THRESHOLD] characters, truncate to the first [TRUNCATION_LENGTH] characters and append [TRUNCATION_NOTICE] to avoid token waste while preserving enough signal for detection. Validate the model's JSON response with a schema validator before any routing decision. The schema must enforce: detected_language as a string matching ^[a-z]{2,3}(-[A-Z]{2})?$, confidence as a float between 0 and 1, requires_translation as a boolean, and recommended_model as either null or a string from your approved model registry. Reject any response that fails schema validation and retry once with the error message appended to the prompt.

Build a routing decision tree that gates on confidence and requires_translation. If confidence is below [CONFIDENCE_THRESHOLD] (start with 0.85 and tune based on eval results), route to a human review queue with the original text, the model's best guess, and the low-confidence flag. If confidence is above threshold and requires_translation is false, bypass translation and pass the original text to the downstream processing pipeline. If requires_translation is true and recommended_model is populated, route to that specific translation model. If recommended_model is null despite requires_translation being true, fall back to your default general-purpose translation model and log the anomaly for later investigation. Log every routing decision with the input hash, detected language, confidence score, routing path taken, and latency for observability.

Implement retry logic carefully. A single retry on schema validation failure is reasonable. Do not retry on low confidence; that's a signal to escalate, not to ask the model again. If the model returns a valid schema but an unsupported language code, map it to the nearest supported language using a static lookup table rather than asking the model to correct itself. For language pairs known to produce poor translation quality (maintain this list in configuration, not in the prompt), force requires_translation to false and route to a human-in-the-loop workflow regardless of the model's recommendation. This prevents automated translation of language pairs where your translation models consistently underperform.

Model choice matters for this prompt. Smaller, faster models (e.g., Claude Haiku, GPT-4o-mini) are usually sufficient for language detection and cost far less than frontier models. Reserve larger models for cases where the smaller model returns confidence below threshold and you want a second opinion before escalating to a human. Run periodic eval batches comparing the small model's language detection against a larger judge model to measure drift. If the small model's accuracy drops below [ACCURACY_THRESHOLD] on your eval set, switch to the larger model or retrain your routing thresholds.

The most common production failure is overconfident misclassification on short text. A three-word input in Spanish might share vocabulary with Italian, and the model will confidently pick one. Your harness must treat short inputs differently: lower the confidence threshold programmatically for inputs under 20 characters, and consider adding a clarification step that asks the user to confirm the detected language before routing to translation. A second failure mode is mixed-language inputs where the model detects only the dominant language and misses a significant minority language segment. If your use case requires per-segment routing, this prompt is insufficient; you need the code-switching segment identification prompt instead. Wire your harness to detect when the model's confidence is high but the input contains script or vocabulary markers from multiple languages, and flag those cases for review.