Short Text Language Detection Prompt for Queries

This prompt is built for platform engineers and AI infrastructure teams who need to detect the language of short text inputs before routing them to language-specific models, translation layers, or locale-aware workflows. It targets search queries, chatbot messages, and API requests under 20 words where standard language detection libraries often fail due to insufficient signal. The prompt produces an ISO 639-1 language code with a calibrated confidence score and an explicit low-confidence flag for inputs that are too short, ambiguous, or dominated by proper nouns and cross-lingual homographs. Use this when wrong-language routing would degrade downstream output quality, break retrieval pipelines, or create user trust issues in multilingual products.

Do not use this prompt when inputs are reliably longer than a full sentence, as statistical libraries like fasttext or langdetect will be faster, cheaper, and equally accurate at that length. Do not use it for detecting multiple languages within a single input—this prompt is designed for primary language detection only; for mixed-language inputs, use a dedicated mixed-language detection prompt from the same playbook series. Avoid relying on this prompt for real-time streaming applications with sub-100ms latency budgets unless you've benchmarked your model endpoint and confirmed it meets your p95 latency target. The prompt is also inappropriate for detecting regional locale variants (e.g., en-US vs. en-GB) where spelling and formatting differences are the only signal—use the locale identification prompt instead.

Before wiring this into production, run it against your eval set of single-word queries, proper nouns, and cross-lingual homographs (e.g., 'chat' which is both French and English, or 'bank' which exists in multiple Germanic languages). Measure how often the low-confidence flag fires correctly versus when the model overconfidently misclassifies. If your product has a supported language list, add a post-processing constraint that maps any detected language outside that list to a fallback or clarification flow. The next section provides the copy-ready prompt template you can adapt and test immediately.

This prompt template is designed to be pasted directly into your system instructions for a language detection node. It forces the model to return a structured JSON object containing a language code and a confidence flag, rather than a conversational guess. The template is purpose-built for short text under 20 words—search queries, chatbot messages, and API requests—where disambiguation is hardest. Before deploying, replace every square-bracket placeholder with your application's specific values, such as your supported language list and minimum confidence threshold.

textCopy
You are a language detection classifier for short text queries. Your only job is to identify the language of the input and return a structured JSON object. Do not answer the query, translate it, or provide any explanation.

## INPUT
[INPUT]

## SUPPORTED LANGUAGES
You may only return language codes from this list: [SUPPORTED_LANGUAGE_CODES]

## OUTPUT SCHEMA
Return exactly this JSON structure with no additional text, markdown fences, or commentary:
{
  "language_code": "ISO 639-1 code or 'unknown'",
  "confidence": "high" | "low",
  "detection_notes": "Brief reason for low confidence, or null if high"
}

## CONFIDENCE RULES
- Return "high" only when the language is unambiguous given the available text.
- Return "low" when:
  - The text is a single word that exists in multiple languages (e.g., 'no', 'die', 'chat').
  - The text is a proper noun, brand name, or URL with no language-specific words.
  - The text contains only numbers, emoji, or punctuation.
  - The text is a cross-lingual homograph where multiple languages are plausible.
  - The text is shorter than [MIN_CHARACTERS_FOR_HIGH_CONFIDENCE] characters.
- When confidence is "low", set "language_code" to "unknown" unless a dominant language is still clearly identifiable.

## CONSTRAINTS
- Do not guess. If the language is not clearly identifiable, return "unknown" with "low" confidence.
- Do not use the query topic or domain to infer language. Only use linguistic features.
- Ignore named entities, URLs, and code snippets when they are the only content.
- For mixed-language input, return the primary language only if it represents more than [MIXED_LANGUAGE_THRESHOLD]% of the content. Otherwise return "unknown".

## EXAMPLES
Input: "weather tomorrow"
Output: {"language_code": "en", "confidence": "high", "detection_notes": null}

Input: "banco"
Output: {"language_code": "unknown", "confidence": "low", "detection_notes": "Single word exists in Spanish, Portuguese, and Italian. Insufficient context to disambiguate."}

Input: "https://example.com"
Output: {"language_code": "unknown", "confidence": "low", "detection_notes": "URL only. No linguistic content to classify."}

Input: "café con leche por favor"
Output: {"language_code": "es", "confidence": "high", "detection_notes": null}

After copying this template, you must adapt the placeholders to match your production environment. Set [SUPPORTED_LANGUAGE_CODES] to the exact list of ISO 639-1 codes your downstream pipelines can handle—typically a JSON array like ["en", "es", "fr", "de", "ja"]. Set [MIN_CHARACTERS_FOR_HIGH_CONFIDENCE] based on your eval results; start with 5 and adjust after testing on your query distribution. Set [MIXED_LANGUAGE_THRESHOLD] to the percentage cutoff for declaring a primary language in mixed input; 70% is a reasonable default. The [INPUT] placeholder should be replaced at runtime by your application with the raw user query, stripped of any prompt injection delimiters. Do not modify the output schema without updating all downstream parsers, validators, and monitoring dashboards that consume this JSON structure.

Integrating a language detection prompt into a production system requires more than just calling an LLM. The harness must handle the prompt's inherent uncertainty, especially with short text. The core loop involves: receiving the input query, injecting it into the [INPUT] placeholder, calling a fast, cost-effective model (like GPT-4o-mini or Claude Haiku), and then strictly validating the output before the routing decision is made. The primary risk is a low-confidence or incorrect language code causing a cascading failure downstream, such as routing a query to the wrong translation model or a language-specific knowledge base that cannot process it.

The validation layer is the most critical component. You must parse the model's response and check that the language_code field is a valid ISO 639-1 code from your supported list. If the confidence_score is below a defined threshold (e.g., 0.85), or if the ambiguity_flag is set to true, the system should not proceed automatically. Instead, implement a fallback strategy: route to a default 'multilingual' or 'unknown' queue, use a higher-capability model for a second opinion, or, in high-stakes customer support scenarios, flag the item for a human reviewer. A simple retry loop with a slightly modified prompt (e.g., adding

If uncertain

respond with 'un' for unknown") can resolve transient failures but will not fix fundamentally ambiguous inputs like single-word proper nouns."

For observability, log every detection event: the raw input, the model's full response, the validated language code, the confidence score, and the final routing decision. This data is essential for calibrating your confidence threshold and identifying patterns of misclassification, such as a specific set of cross-lingual homographs that consistently fool the model. Wire these logs into your eval framework to run regression tests. A golden dataset of 100 short, ambiguous queries (e.g., 'chat', 'main', 'bank') with their correct, human-verified language labels should be run against the prompt weekly to detect drift. When a failure mode is identified, do not just add a one-off rule in application code; update the prompt's [EXAMPLES] or [CONSTRAINTS] to teach the model the correct behavior directly, keeping the logic centralized and maintainable.