Dialect Classification Prompt Template

This prompt is for platform engineers who need to route user inputs to dialect-specific models, translation layers, or knowledge bases where a standard language classifier is too coarse. The core job-to-be-done is distinguishing between high-stakes dialect pairs—Egyptian versus Levantine Arabic, European versus Brazilian Portuguese, or Latin American versus Peninsular Spanish—where misrouting directly degrades output quality, user trust, or downstream task accuracy. The ideal user is an AI infrastructure engineer or technical decision maker building multilingual routing middleware who already has a working language detection layer but needs finer granularity for specific language families.

Use this prompt when lexical, syntactic, and orthographic markers can reliably separate dialects and when the cost of misclassification justifies the additional latency and token spend of a dedicated classification step. Concrete triggers include: you are routing Arabic queries to separate fine-tuned models for Gulf, Egyptian, and Levantine dialects; you are selecting between pt-BR and pt-PT translation models and need to catch vocabulary differences like 'trem' versus 'comboio'; or you are dispatching Spanish-language support tickets to region-specific agent queues where Peninsular 'vosotros' forms versus Latin American 'ustedes' usage changes the entire tone of the response. The prompt includes explicit confidence scoring and a mandatory fallback to the standard language variety when dialect signals are weak, ambiguous, or contradictory.

Do not use this prompt when a simple locale code from the application layer (browser navigator.language, Accept-Language header, user profile setting) is sufficient. Do not use it for language families where dialect variation is primarily phonological rather than textual, or where the available training data for the target models does not actually differ by dialect. Avoid this prompt for inputs under roughly 15 words where lexical markers are too sparse to disambiguate reliably—short queries, single-word searches, and social media posts with heavy slang or code-switching will produce low-confidence results that fall through to the standard variety fallback anyway. If your routing logic can tolerate that fallback, the prompt may still be useful; if every misroute creates a compliance or user-experience incident, you need additional signals beyond text alone.

This prompt template is designed to be the core instruction set for a dialect classification step in your AI pipeline. It accepts raw text and a target language family, then returns a structured classification result. The template uses square-bracket placeholders for all dynamic inputs, making it straightforward to populate programmatically before sending it to the model. The primary goal is to produce a reliable, machine-readable output that can trigger downstream routing to dialect-specific models, translation layers, or knowledge bases.

textCopy
You are a precise dialect classification engine. Your task is to analyze the provided text and identify its specific dialect within the [TARGET_LANGUAGE_FAMILY] family.

INPUT TEXT:
"""
[USER_INPUT]
"""

INSTRUCTIONS:
1. Analyze the text for lexical, syntactic, and orthographic markers that distinguish dialects within the [TARGET_LANGUAGE_FAMILY] family.
2. Identify the most likely dialect. If no single dialect is clearly indicated, default to the standard or most widely understood variety for the family (e.g., Modern Standard Arabic, US English, Castilian Spanish).
3. Provide a confidence score between 0.0 and 1.0 for your classification.
4. List the top 3 key markers that led to your decision.

OUTPUT_SCHEMA:
{
  "detected_dialect": "string",
  "confidence_score": "float",
  "key_markers": ["string", "string", "string"],
  "fallback_applied": "boolean"
}

CONSTRAINTS:
- If the confidence score is below [CONFIDENCE_THRESHOLD], set `fallback_applied` to true and `detected_dialect` to the standard variety.
- Do not classify the text into a language outside the [TARGET_LANGUAGE_FAMILY] family. If the text is not in this family, set `detected_dialect` to "OUT_OF_SCOPE" and `confidence_score` to 0.0.
- Respond only with the valid JSON object. Do not include any explanatory text outside the JSON.

To adapt this template, replace the bracketed placeholders with your specific parameters. [TARGET_LANGUAGE_FAMILY] should be a string like "Arabic", "Spanish", or "English". [USER_INPUT] is the raw text you need to classify. [CONFIDENCE_THRESHOLD] is a critical control; set it based on your system's tolerance for misrouting. A threshold of 0.8 is a common starting point for high-stakes routing, while 0.6 might be acceptable for analytics. Before deploying, run this prompt against a golden dataset of known dialect samples to calibrate the threshold and identify systematic confusion pairs (e.g., Moroccan vs. Egyptian Arabic). The next step is to integrate this template into an implementation harness that validates the JSON output and handles the OUT_OF_SCOPE and fallback cases gracefully.

The Dialect Classification prompt is designed to sit inside a routing middleware layer that inspects incoming text before it reaches a downstream model, translation service, or locale-specific workflow. The harness should call the prompt only after a primary language detection step has confirmed the language family (e.g., Arabic, Spanish, Chinese) with high confidence. Running dialect classification on inputs where the language itself is ambiguous wastes tokens and produces unreliable results. The harness must therefore enforce a precondition: the language label from an upstream detector must match one of the families this prompt supports, and its confidence must exceed a configurable threshold (typically 0.85 or higher). If the precondition fails, the input should be routed to the standard variety for that language or escalated for human review rather than passed to this prompt.

The implementation should wrap the prompt call in a function that accepts the raw input text, the detected language code, and an optional locale hint from the application context. The function constructs the prompt by injecting the input into the [INPUT] placeholder and the detected language family into the [LANGUAGE_FAMILY] placeholder. The [OUTPUT_SCHEMA] placeholder should be replaced with a strict JSON schema requiring dialect_code (a controlled enum per language family), confidence (a float between 0.0 and 1.0), and markers (an array of strings citing the lexical, syntactic, or orthographic evidence used). The model should be instructed to return only valid JSON without markdown fences. After the model responds, the harness must validate the output against the schema, confirm the dialect_code belongs to the expected enum for the detected language family, and check that confidence is a number in range. Any validation failure should trigger a single retry with the error message appended to the prompt as additional context. If the retry also fails, the harness should log the failure, fall back to the standard variety for the language family, and emit an observability event so the routing failure can be tracked.

For model choice, a fast and cost-efficient model (such as a small Claude Haiku, GPT-4o-mini, or Gemini Flash variant) is usually sufficient for dialect classification, since the task relies on surface-level lexical and orthographic patterns rather than deep reasoning. Latency is critical in routing middleware, so the harness should set a strict timeout (500-800ms is a reasonable starting point) and treat timeouts as a fallback-to-standard-variety event. The harness must also log every classification decision—including the input hash, detected language, classified dialect, confidence score, and whether the result was used, overridden by a fallback, or escalated. These logs feed into offline evaluation pipelines where you can measure dialect misrouting rates, identify overconfident misclassifications on short or noisy text, and calibrate the confidence threshold. If the downstream workflow carries regulatory or customer-facing risk (e.g., legal document routing, healthcare intake), the harness should require human review for any classification where confidence falls below 0.80, rather than silently routing to a dialect-specific model that may produce inappropriate output.