Language Detection for Content Moderation Routing Prompt

This prompt is designed for trust and safety engineers who need to route user-generated content to language-specific moderation pipelines. The core job-to-be-done is to accurately detect the primary language of an input text so that downstream toxicity classifiers, policy engines, and human review queues—which are often trained or configured for specific languages—receive content they can process correctly. The ideal user is a platform engineer integrating this detection step into an existing content moderation architecture, where a misrouted piece of content in Hindi sent to an English-only classifier creates a critical safety gap.

Use this prompt when the cost of a misclassification is high, such as failing to catch hate speech or policy violations because the content was routed to a model that couldn't understand it. The required context is the raw, unmodified user input string. You should not use this prompt as a standalone language identification tool for analytics or general localization; it is specifically tuned for the adversarial and noisy conditions of content moderation, where users actively attempt to obfuscate language to evade detection. It is also not a replacement for a dedicated locale detection step if you need to distinguish regional variants like pt-BR versus pt-PT for policy reasons.

Before implementing, define your supported language set and the exact routing destinations for each language code. The prompt's value is in its integration with a routing harness that validates the output against this allowed set. If the detected language is unsupported, your application must have a pre-defined fallback queue, not just a log message. The next step after reading this section is to review the prompt template and plan your validation layer, as the prompt's raw output requires strict schema checks before it can be trusted to make a routing decision in production.

The prompt template below is designed to be copied directly into your application code or prompt management system. It accepts raw user-generated text and returns a structured language detection result suitable for consumption by a moderation routing middleware. The template uses square-bracket placeholders for all dynamic inputs, ensuring you can wire it into your specific trust and safety pipeline without modifying the core instruction logic.

textCopy
You are a language detection system for a content moderation pipeline. Your output will determine which language-specific toxicity classifier, policy engine, and human review queue receives the content.

Analyze the following user-generated text and determine its primary language. The text may contain slang, typos, code-switching, emoji, hashtags, or deliberate obfuscation.

[INPUT]

Return a JSON object with the following structure:
{
  "primary_language": "ISO 639-1 code",
  "language_name": "English name of the language",
  "confidence_score": 0.0 to 1.0,
  "additional_languages_detected": ["ISO 639-1 code"],
  "is_mixed_language": true or false,
  "contains_obfuscation": true or false,
  "routing_target": "queue identifier from [ROUTING_TABLE]",
  "requires_human_review": true or false
}

[CONSTRAINTS]
- If confidence_score is below [CONFIDENCE_THRESHOLD], set requires_human_review to true.
- If multiple languages are present and no single language exceeds [DOMINANCE_THRESHOLD] proportion, set is_mixed_language to true and route to the mixed-language moderation queue.
- If the text contains deliberate obfuscation patterns (leet speak, homoglyph substitution, character scrambling), set contains_obfuscation to true and escalate to human review.
- For CJK characters, use character frequency and script markers (kana, hangul) to disambiguate Chinese, Japanese, and Korean.
- For Latin script text, use diacritic patterns, common words, and character n-grams to distinguish between languages.
- If the text is fewer than [MIN_TEXT_LENGTH] characters, flag as low-confidence and require human review.

[ROUTING_TABLE]
{
  "en": "moderation-en-queue",
  "es": "moderation-es-queue",
  "ar": "moderation-ar-queue",
  "zh": "moderation-zh-queue",
  "mixed": "moderation-mixed-queue",
  "unknown": "moderation-review-queue"
}

[EXAMPLES]
Input: "you are so stupid lol"
Output: {"primary_language": "en", "language_name": "English", "confidence_score": 0.98, "additional_languages_detected": [], "is_mixed_language": false, "contains_obfuscation": false, "routing_target": "moderation-en-queue", "requires_human_review": false}

Input: "eres un idiota jajaja"
Output: {"primary_language": "es", "language_name": "Spanish", "confidence_score": 0.97, "additional_languages_detected": [], "is_mixed_language": false, "contains_obfuscation": false, "routing_target": "moderation-es-queue", "requires_human_review": false}

Input: "y0u @r3 $0 dUmB"
Output: {"primary_language": "en", "language_name": "English", "confidence_score": 0.72, "additional_languages_detected": [], "is_mixed_language": false, "contains_obfuscation": true, "routing_target": "moderation-en-queue", "requires_human_review": true}

Input: "انت غبي wallah"
Output: {"primary_language": "ar", "language_name": "Arabic", "confidence_score": 0.85, "additional_languages_detected": ["en"], "is_mixed_language": true, "contains_obfuscation": false, "routing_target": "moderation-mixed-queue", "requires_human_review": false}

To adapt this template for your environment, replace the placeholders with your operational values. Set [CONFIDENCE_THRESHOLD] based on your tolerance for misrouting—0.85 is a common starting point for moderation pipelines where false negatives carry high risk. Set [DOMINANCE_THRESHOLD] to define what counts as a mixed-language input; 0.7 works well for most platforms. Set [MIN_TEXT_LENGTH] to the character count below which language detection becomes unreliable; 15 characters is typical. The [ROUTING_TABLE] should map every language code your platform supports to a real queue identifier in your moderation infrastructure. Add entries for languages common in your user base and always include a fallback unknown queue. The examples demonstrate expected behavior for clean text, obfuscated text, and code-switched inputs—replace them with examples drawn from your actual moderation logs to improve few-shot accuracy on your specific abuse patterns.

Integrating this prompt into a production moderation pipeline requires treating language detection as a deterministic routing decision, not a best-effort annotation. The prompt should sit at the ingress layer, after basic input sanitization but before any toxicity classifier, policy engine, or human review queue is invoked. The application must capture the raw input, the detected language code, the confidence score, and the ambiguity flag in a structured log entry before routing proceeds. This audit trail is essential for debugging misrouted content, measuring classifier performance per language, and demonstrating to trust and safety reviewers that the correct language-specific policy was applied.

The implementation harness should enforce a strict output contract. Parse the model response into a typed object with fields: language_code (ISO 639-1 string), confidence (float 0-1), is_ambiguous (boolean), and alternative_codes (array of strings). If the model returns a language code not in your supported language list, route to a default fallback queue and flag for review. If confidence falls below a configurable threshold (start at 0.85 and tune per language pair), treat the input as ambiguous and route to a manual review queue or a multi-language classifier. Never silently route low-confidence detections—this is the most common failure mode in production, where short text, mixed-language inputs, or adversarial obfuscation produce plausible but wrong language codes that cascade into incorrect moderation decisions.

For model choice, prefer fast, cost-efficient models for this classification task. A lightweight model like GPT-4o-mini, Claude Haiku, or a fine-tuned open-weight classifier will handle most language detection with low latency and cost. Reserve larger models for the ambiguity resolution path: when is_ambiguous is true, you may invoke a more capable model with additional context or a specialized disambiguation prompt. Implement retry logic with exponential backoff for transient API failures, but cap retries at 2 attempts—language detection failures should fail open to a review queue, not block the moderation pipeline. Log every detection event with the input hash, detected language, confidence, model version, and routing decision. This log becomes your evaluation dataset for measuring detection accuracy and drift over time.

Adversarial inputs require special handling in the harness. Users attempting to evade language-specific moderation may use homoglyph attacks, mixed scripts, or deliberate misspellings. Before passing input to the language detection prompt, normalize Unicode (NFC or NFKC), strip zero-width characters, and apply a basic script consistency check. If the input contains scripts from multiple language families with no clear dominant script, flag it for manual review regardless of the model's confidence score. Additionally, maintain a blocklist of known obfuscation patterns and a running list of inputs that produced high-confidence but incorrect language detections—these become your adversarial eval set for regression testing prompt updates.

Wire the detection output directly into your moderation router. Map each supported language code to a specific toxicity classifier endpoint, policy configuration, and human review queue. For unsupported languages, route to a general-purpose moderation model with a flag indicating the detected language so reviewers have context. If the prompt returns is_ambiguous: true, route to a multi-language review queue and include the alternative_codes in the routing metadata so reviewers can apply the correct policies manually. Avoid the temptation to add a 'clarification' step that asks the user what language they're using—this creates friction and gives bad actors an opportunity to lie. The harness should make a best-effort decision and escalate when uncertain, not delegate the decision to the user.