Locale Identification Prompt for Regional Routing

This prompt is for AI infrastructure teams who need to route user-generated text to region-specific models, translation layers, or content workflows. It detects the regional locale (e.g., en-US vs. en-GB, pt-BR vs. pt-PT, es-MX vs. es-ES) by analyzing vocabulary, spelling conventions, date and number formatting, and other textual markers. Use this when language detection alone is insufficient because two locales share the same language code but require different downstream processing—for example, routing a customer support ticket to a Brazilian Portuguese queue versus a European Portuguese queue, or selecting between an American English and British English text-to-speech model.

The prompt works best on inputs of at least 15 words where locale signals are dense enough to be reliable. It expects a language code to already be known or detected upstream; its job is to refine that language classification into a specific regional locale. The output includes a locale code (e.g., en-US, pt-BR), a confidence score, and the specific markers that informed the decision. This traceability is critical for debugging misroutes and for building eval datasets that measure the cost of locale confusion. Wire this prompt after your language detection step but before model selection, translation routing, or content policy enforcement. For high-stakes routing—such as legal, healthcare, or financial content—always include a confidence threshold below which the input is flagged for human review rather than silently misrouted.

Do not use this prompt for general language identification (use a language detection prompt instead), for inputs under 15 words where locale signals are too sparse, or for cases where the language itself is unknown. Also avoid using it when the downstream system does not actually differentiate between regional variants—adding unnecessary locale detection creates routing complexity without value. Before deploying, test against near-identical locale pairs (e.g., es-MX vs. es-ES, en-US vs. en-GB) using a golden dataset that includes edge cases like mixed-locale documents, formal vs. informal register, and inputs where the locale is deliberately ambiguous. Measure misrouting cost in terms of downstream quality degradation, not just classification accuracy.

This prompt template is designed to be pasted directly into your system instructions for a locale identification step in a regional routing pipeline. It instructs the model to analyze input text for vocabulary, spelling, and formatting conventions that distinguish regional variants of the same language—such as en-US versus en-GB, pt-BR versus pt-PT, or es-MX versus es-ES. The prompt is structured to produce a consistent JSON output that your application can parse and act on, with explicit handling for ambiguous or underspecified inputs where a regional signal cannot be reliably detected.

textCopy
You are a locale identification engine for regional routing. Your job is to analyze the provided text and determine the most likely regional locale based on vocabulary, spelling, formatting conventions, and cultural references.

## INPUT
[INPUT]

## TARGET LOCALES
[LOCALE_LIST]

## OUTPUT SCHEMA
Return a JSON object with the following fields:
- "detected_locale": The most likely locale code from the target list, or "unknown" if no clear signal exists.
- "confidence": A float between 0.0 and 1.0 indicating your confidence in the detection.
- "signals": An array of strings listing the specific textual clues that informed your decision (e.g., "color spelled without 'u'", "date format DD/MM/YYYY", "term 'lorry' detected").
- "alternative_locales": An array of other possible locales from the target list that share some signals, ordered by likelihood. Empty if confidence is above [CONFIDENCE_THRESHOLD].
- "rationale": A brief explanation of your reasoning, including why you ruled out other locales.

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## RULES
1. Base your decision only on textual evidence present in the input. Do not guess based on topic or subject matter alone.
2. If the input is too short or generic to determine a regional locale, set "detected_locale" to "unknown" and "confidence" to 0.0.
3. When multiple locales are plausible, list them in "alternative_locales" and keep "confidence" below [CONFIDENCE_THRESHOLD].
4. Prioritize spelling differences (e.g., color/colour, realize/realise) and vocabulary differences (e.g., truck/lorry, apartment/flat) over formatting conventions.
5. Do not confuse language detection with locale detection. Assume the language is already known and focus only on regional variation.

To adapt this template for your system, replace the square-bracket placeholders with your specific values. [LOCALE_LIST] should contain the exact locale codes your routing system supports, such as ["en-US", "en-GB", "en-AU", "en-CA"]. [CONSTRAINTS] can include additional rules like domain-specific terminology handling or known ambiguous cases for your application. [EXAMPLES] should provide few-shot demonstrations covering clear cases, edge cases, and ambiguous inputs relevant to your locale pairs. [CONFIDENCE_THRESHOLD] sets the boundary below which the system should route to a default or clarification path rather than trusting the detection. Wire the output into your routing middleware by parsing the detected_locale field and using confidence to decide whether to proceed automatically, flag for review, or fall back to a default locale. For high-stakes routing where misdirection has significant cost, add a human review step when confidence falls below your threshold or when alternative_locales is non-empty.

This prompt is designed to sit at the routing layer of a multilingual AI platform, immediately after language detection but before region-specific model dispatch, translation, or content policy application. The prompt expects a pre-detected language code (e.g., en, pt, es) and the raw user input text. Its job is to resolve the regional locale variant—such as en-US vs. en-GB or pt-BR vs. pt-PT—using orthographic, lexical, and formatting signals. The output is a structured locale tag (IETF BCP 47 format) and a confidence score, which downstream systems use to select the correct embedding model, response template, currency format, or compliance policy. Wire this prompt as a synchronous call within your request preprocessing pipeline, invoked only when the detected language belongs to a known set of regionally variant languages. Do not call this prompt for languages without meaningful regional divergence, as it will waste latency and compute.

The implementation harness must enforce a strict output contract. Parse the model response into a JSON object with locale (string, BCP 47), confidence (float, 0-1), and markers (array of strings indicating which signals drove the decision). Validate that locale matches the expected language family of the input language code—if the language detector returned pt but the locale prompt returns en-GB, flag this as a misrouting event and fall back to a default locale for the detected language. Set a confidence threshold (we recommend 0.7 for automated routing, 0.5 for flagging for human review). When confidence falls below the threshold, route to a clarification prompt or a human review queue rather than silently dispatching to the wrong regional model. Log every decision with the input hash, detected language, resolved locale, confidence, markers, and latency. This log becomes your primary dataset for measuring misrouting cost and tuning the threshold.

Model choice matters for this task. Use a fast, cost-efficient model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small model) because this prompt runs on every request in the hot path. Latency budget should be under 500ms for real-time chat applications; if you cannot meet that, consider caching locale decisions per user session or account region setting. Implement a retry strategy with a single retry on parse failure or schema validation error, using a stricter temperature setting (0.0 or 0.1) on the retry. If the retry also fails, fall back to the most common locale for the detected language in your user base. For high-stakes domains like healthcare or finance, where misrouting could expose data to the wrong jurisdiction, add a human approval step for any locale decision with confidence below 0.9 or where the detected markers conflict with the user's declared region. Build an eval harness that tests near-identical locale pairs (e.g., en-US vs. en-GB with spelling variants like 'color'/'colour', 'center'/'centre') and measures both accuracy and the cost of false positives—routing a British user to a US-specific workflow may be worse than routing to a neutral English fallback.