Output Language and Locale Restriction Enforcement Prompt

This prompt is for multilingual product teams and localization engineers who need to verify that AI-generated outputs strictly adhere to a target language and regional locale conventions. The job-to-be-done is automated compliance grading: you provide a target locale specification (e.g., fr-FR, ja-JP, en-GB) and a generated text, and the prompt returns a structured locale compliance report. This report includes language detection confidence, format checks for dates, currencies, and units, and flags for mixed-language content. It is designed to be embedded in a CI/CD pipeline or a content review queue where a human spot-check is too slow or inconsistent.

Use this prompt when you are shipping AI-generated content to region-specific audiences and a locale mismatch is a product defect—for example, a French customer receiving a date in MM/DD/YYYY format or a Japanese user seeing USD currency symbols. It is also appropriate when you are evaluating a new model or prompt version and need to confirm that language constraints are being respected under load. The prompt expects two concrete inputs: a [TARGET_LOCALE] (an IETF BCP 47 language tag) and the [GENERATED_TEXT] to evaluate. You should not use this prompt for general translation quality assessment, stylistic fluency grading, or cultural sensitivity review; those require separate, specialized evaluation rubrics.

Before integrating this prompt into a production harness, define your failure thresholds. A single mixed-language word in a 5,000-word document may be acceptable, while a wrong currency symbol in a checkout flow is a hard stop. Configure your eval harness to parse the structured output and trigger a retry, a fallback model, or a human review queue based on the severity flags. Avoid using this prompt as a real-time guardrail in latency-sensitive user-facing paths without caching or asynchronous validation.

This prompt template is designed to be dropped into an evaluation harness that checks whether a generated output matches the target language and locale requirements. It accepts the output under review, the expected locale specification, and optional format rules. The model acts as a locale compliance judge, producing a structured report that flags language mismatches, incorrect regional formatting, and mixed-language content. Use this template when you need automated, repeatable locale verification before outputs reach end users or downstream systems.

textCopy
You are a locale compliance auditor. Your task is to verify that the provided output matches the target language and locale format conventions.

## INPUT
[OUTPUT_TO_AUDIT]

## TARGET LOCALE
Language: [TARGET_LANGUAGE]
Locale Code: [LOCALE_CODE] (e.g., en-US, de-DE, ja-JP)

## LOCALE FORMAT RULES
Date Format: [DATE_FORMAT]
Currency Format: [CURRENCY_FORMAT]
Number Format: [NUMBER_FORMAT]
Unit System: [UNIT_SYSTEM]
Additional Rules: [ADDITIONAL_RULES]

## INSTRUCTIONS
1. Detect the primary language of the output using language identification.
2. Check if the primary language matches [TARGET_LANGUAGE].
3. Verify that dates, currencies, numbers, and units follow the specified locale formats.
4. Flag any mixed-language segments, untranslated text, or locale-inconsistent formatting.
5. For each violation, provide the exact text snippet and explain the mismatch.
6. If the output is entirely in the wrong language, mark it as a critical failure.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "overall_compliance": "pass" | "partial" | "fail",
  "primary_language_detected": "string",
  "language_match": true | false,
  "language_confidence": 0.0-1.0,
  "violations": [
    {
      "type": "wrong_language" | "mixed_language" | "date_format" | "currency_format" | "number_format" | "unit_format" | "untranslated_text" | "other",
      "severity": "critical" | "major" | "minor",
      "snippet": "exact text from output",
      "expected": "what the locale requires",
      "actual": "what the output contains",
      "location": "approximate position or context in output"
    }
  ],
  "mixed_language_segments": [
    {
      "language": "detected language",
      "snippet": "text segment",
      "length": "character count"
    }
  ],
  "format_checks": {
    "date_format_compliant": true | false | "no_dates_found",
    "currency_format_compliant": true | false | "no_currency_found",
    "number_format_compliant": true | false | "no_numbers_found",
    "unit_system_compliant": true | false | "no_units_found"
  },
  "summary": "one-sentence compliance summary"
}

## CONSTRAINTS
- Do not evaluate content quality, accuracy, or tone beyond locale compliance.
- If no format-specific content exists (e.g., no dates in output), mark the check as "no_dates_found" rather than failing.
- Flag even a single word in the wrong language as a mixed-language violation.
- For partial compliance, list every violation; do not stop at the first one.

To adapt this template, replace the square-bracket placeholders with your specific locale requirements. The [OUTPUT_TO_AUDIT] field should contain the full text you want to verify. For [TARGET_LANGUAGE], use the ISO language name (e.g., "German", "Japanese"). The [LOCALE_CODE] should follow the standard language-region format. The format rules fields accept explicit patterns like "DD.MM.YYYY" for dates or "1.234,56 €" for currency. If your use case doesn't require certain format checks, set the corresponding rule to "N/A" and the model will skip that check. For high-risk regulated content, always route failures to human review before the output reaches customers.

This prompt is designed to be called programmatically after content generation, not as a one-off manual check. The typical integration point is a post-generation validation step: your application generates content in a target language, passes both the content and the expected locale specification to this prompt, and receives a structured compliance report. The report's overall_compliance boolean and per-check pass/fail flags should drive automated decisions—block a deployment, flag for human review, or auto-route to a localization team. Do not treat this as a conversational prompt; it should be called with temperature=0 or the lowest supported setting to maximize deterministic, repeatable judgments.

Wire the prompt into your application with a validation wrapper that handles the output schema. After receiving the JSON report, validate that all required fields are present (language_detection, locale_format_checks, mixed_language_flags, overall_compliance, compliance_summary). If the model returns malformed JSON, implement a single retry with the error message appended to the prompt context. Log every compliance report with a trace ID that ties back to the source content and generation request—this is essential for debugging false positives or missed violations. For high-volume pipelines, consider batching multiple content items into a single request with an array input to reduce API overhead, but keep batch sizes small (3–5 items) to avoid attention dilution on per-item checks.

Model choice matters. Use a model with strong multilingual capabilities and instruction-following precision. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable; avoid smaller or older models that may hallucinate language detection or miss subtle format violations. If your application handles regulated content (medical, legal, financial), route any overall_compliance: false result to a human review queue with the full compliance report and source content attached. Never auto-correct locale violations without human approval in regulated domains—the model's suggested fixes may introduce new errors. For non-regulated content, you can chain this prompt with a repair prompt that takes the violation details and regenerates compliant output, but always re-validate the repaired output through the same compliance check.

Testing and calibration are critical before production use. Build a golden dataset of 20–30 content samples with known locale violations: mixed-language text, wrong date formats, incorrect currency symbols, missing regional conventions. Run the prompt against this dataset and measure precision and recall on each check type. Pay special attention to false positives on mixed_language_flags—code snippets, brand names, and loanwords should not trigger violations. Adjust the prompt's [CONSTRAINTS] placeholder to add domain-specific exceptions. If your application targets a specific locale pair (e.g., en-US vs. en-GB), add explicit examples of acceptable differences to the [EXAMPLES] section to prevent the model from flagging regional spelling variations as violations.