Script Detection Prompt for Multilingual Input

Use this prompt when your ingestion pipeline processes text that may contain multiple writing systems, code-switched content, or visually similar scripts that confuse downstream language detectors. Script detection is a pre-language step that narrows the candidate language set and prevents misrouting of text that shares character sets across unrelated languages. For example, a string written in Cyrillic could be Russian, Ukrainian, Serbian, or Mongolian—detecting the Cyrl script first constrains the language classifier to a manageable subset rather than forcing it to consider all possible languages. This prompt is essential for platforms handling user-generated content from global audiences, multilingual document processing systems, and any pipeline where wrong-language routing degrades output quality or user trust.

Deploy this prompt when you observe language classifiers failing on short strings, mixed-script documents, or inputs where the writing system itself is the strongest signal. Common failure cases include: Arabic script text misclassified as Persian or Urdu because the classifier overweights vocabulary; Chinese text written in Latin script (Pinyin) routed to English models; and code-switched social media posts where script boundaries mark language boundaries. The prompt produces ISO 15924 script codes (e.g., Latn, Arab, Cyrl, Hans, Hant, Deva) with per-script proportion estimates and a primary script designation, giving your routing middleware structured data to make deterministic decisions. Wire the output into a script-to-language mapping table that feeds your language classifier a constrained candidate list rather than the full set of supported languages.

Do not use this prompt when your input is already known to be monolingual, single-script, or when your language classifier has proven reliable on your specific input distribution. Adding script detection to a pipeline that only processes English-language support tickets adds latency and cost without improving routing accuracy. Similarly, skip this step when you are using a modern multilingual embedding model or LLM that handles script variation natively—many production models now encode script information internally and do not benefit from an explicit pre-classification step. The prompt is most valuable when you control the routing logic between models and need deterministic, auditable decisions rather than relying on a single model's internal representations. Before deploying, run eval checks on visually similar script pairs (Arabic vs. Persian, Chinese Simplified vs. Japanese Kanji, Latin-script languages with heavy diacritic use) and measure whether script detection actually improves downstream classification accuracy for your specific input mix.

This prompt template is designed to be pasted directly into your system instructions for a script detection task. It identifies the writing system(s) present in [INPUT] text, returning standardized ISO 15924 script codes. This is a critical pre-processing step before language classification, as many languages share scripts, and misidentifying the script can cascade into downstream routing errors. The prompt is built to handle single-script, multi-script, and code-switched inputs, and it explicitly instructs the model to reason about visually similar scripts (e.g., Cyrillic vs. Latin) and script mixtures.

textCopy
You are a script detection engine. Your task is to analyze the provided text and identify the writing system(s) used, returning only ISO 15924 script codes.

[INPUT]
"""
[USER_TEXT]
"""

[OUTPUT_SCHEMA]
You must respond with a single, valid JSON object conforming to this schema:
{
  "primary_script": "string (ISO 15924 code for the dominant script)",
  "detected_scripts": ["string (list of all unique ISO 15924 codes found)"],
  "script_mixture": "boolean (true if more than one script is detected)",
  "confidence": "float (0.0 to 1.0, your confidence in the primary script classification)",
  "rationale": "string (brief explanation of the character analysis, noting any ambiguity)"
}

[CONSTRAINTS]
1. Use only valid ISO 15924 four-letter codes (e.g., 'Latn', 'Cyrl', 'Arab', 'Hans', 'Hant', 'Jpan', 'Kore').
2. For CJK characters, distinguish between 'Hans' (Simplified Chinese), 'Hant' (Traditional Chinese), 'Jpan' (Japanese, including Kanji and Kana), and 'Kore' (Korean, including Hangul and Hanja).
3. If the text contains digits, punctuation, or emoji that are script-agnostic, do not include them in the script detection logic unless they are the only characters present.
4. If the input is empty or contains only whitespace, set 'primary_script' to 'Zyyy' (Undetermined) and 'confidence' to 0.0.
5. Prioritize precision on short strings. A single word in a new script should be detected.

[EXAMPLES]
Input: "Hello, how are you? 你好吗？"
Output: {"primary_script": "Latn", "detected_scripts": ["Latn", "Hans"], "script_mixture": true, "confidence": 0.99, "rationale": "Predominantly Latin script with a phrase in Simplified Chinese at the end."}

Input: "Москва"
Output: {"primary_script": "Cyrl", "detected_scripts": ["Cyrl"], "script_mixture": false, "confidence": 0.99, "rationale": "All characters are Cyrillic."}

Input: "data-base"
Output: {"primary_script": "Latn", "detected_scripts": ["Latn"], "script_mixture": false, "confidence": 0.95, "rationale": "All letters are Latin script; the hyphen is script-agnostic."}

To adapt this template, replace the [USER_TEXT] placeholder with the input string from your application. You can hardcode the [OUTPUT_SCHEMA] and [CONSTRAINTS] into your system prompt for a fixed use case, or keep them as variables if you are building a more general script-detection microservice. The [EXAMPLES] section is crucial for calibrating the model's behavior on edge cases like CJK disambiguation and mixed-script text. For high-stakes routing, you must pair this prompt with a post-processing validation step that checks the returned codes against a known list of ISO 15924 codes and flags any confidence score below your operational threshold for human review or a fallback model.

The script detection prompt is designed to be a lightweight, stateless classifier that sits at the ingress layer of a multilingual ingestion pipeline. It should be called before language identification, as script classification narrows the candidate language set and prevents downstream models from attempting to parse text in unsupported writing systems. In a typical implementation, raw text arrives from an API endpoint, message queue, or batch job, and the prompt is invoked as a synchronous step whose output determines the next processing stage. The prompt expects a single text input and returns an ISO 15924 script code, a confidence score, and a list of any additional scripts detected. This output should be logged alongside the request ID for traceability and later evaluation.

To wire this into an application, wrap the prompt call in a thin service function that handles validation, retries, and fallback. Validate the model's response against a strict schema: the script field must be a valid ISO 15924 four-letter code, confidence must be a float between 0 and 1, and additional_scripts must be an array of valid codes or an empty list. If validation fails, retry once with the same input and a slightly lower temperature (e.g., 0.0 on retry vs. 0.1 on the initial call). If the retry also fails, log the raw response and route the text to a manual review queue rather than guessing. For model choice, a fast, inexpensive model like GPT-4o-mini or Claude Haiku is sufficient for most scripts; reserve larger models for edge cases involving visually similar scripts like Cyrillic vs. Latin or Arabic vs. Persian, where you may want to add a second-pass verification prompt. Do not use this prompt as the sole gate for compliance-critical routing—always pair it with a human review path when script misclassification could cause regulatory exposure.

Observability is critical because script detection failures cascade into language misclassification, wrong embedding model selection, and broken downstream processing. Log the detected script, confidence score, input length, and whether the result passed validation on every call. Set an alert if the validation failure rate exceeds 2% over a rolling window, as this often indicates a model behavior change or a new script pattern in production traffic. For eval, maintain a golden dataset of 200+ samples covering single-script text, multi-script mixtures, code-switched content, and edge cases like emoji-only strings or text composed entirely of punctuation. Run this eval suite on any prompt or model change before deployment. When confidence falls below 0.85, consider routing to a secondary classifier or flagging for human review rather than silently accepting a low-confidence script assignment.