AI App Localization: Locale Contracts, RAG, Tools, and Release Gates

TL;DR

An AI application does not have one locale string. It has a locale contract owned by the application:

language + region + jurisdiction + time zone + currency
+ units + product market + terminology + policy + fallback

These fields influence different decisions and must not be inferred from one another. fr-CA can express a language preference, but it does not by itself establish a person's location, tax status, legal jurisdiction, currency, or consent.

Production localization means making prompts, retrieval, tools, safety rules, output formatting, and evaluation obey that contract. Translation is one activity inside that system.

Key Takeaways

• Use BCP 47 for language tags, not for facts it does not encode.
• Use CLDR-backed libraries for locale data and formatting. Handwritten date, plural, number, and currency rules do not scale.
• Keep task intent stable while localizing behavior. A single base-language string is not the source of truth.
• RAG and tools need locale policy. The wrong law, price, API, date parsing, or unit can turn fluent text into a product failure.
• Release markets independently. Each locale needs native tasks, safety probes, tool tests, and rollback ownership.

Replace the Locale String with a Contract

Fields and Responsibilities

W3C recommends choosing language tags according to BCP 47 and using the shortest tag that conveys the necessary distinction. More subtags are not automatically more accurate.

Locale Resolution Precedence

A defensible default is:

1. explicit preference for the current operation;
2. workspace or tenant policy;
3. account preference;
4. validated application context;
5. Accept-Language for presentation;
6. documented product default.

IP-derived country can be a weak operational signal, but it is not reliable proof of language, identity, residence, or jurisdiction. Preserve the source of every resolved field so downstream systems can distinguish user choice from a default.

Go Example: Application-Owned Locale Resolution

The example uses a strict allowlist of already canonicalized BCP 47 tags. A production platform should use a standards-aware language-tag library and CLDR-backed formatter rather than splitting tags manually.

package main

import (
	"errors"
	"fmt"
)

type LocaleContract struct {
	LanguageTag       string
	Region            string
	Jurisdiction      string
	TimeZone          string
	Currency          string
	Units             string
	Market            string
	Terminology       string
	PolicyVersion     string
	RetrievalFallback string
	Source            string
}

type RequestContext struct {
	OperationLanguage string
	WorkspaceLanguage string
	AccountLanguage   string
}

var supported = map[string]bool{
	"en-US": true,
	"de-DE": true,
	"ja-JP": true,
	"pt-BR": true,
	"zh-CN": true,
}

func resolveLanguage(ctx RequestContext) (string, string, error) {
	candidates := []struct {
		tag    string
		source string
	}{
		{ctx.OperationLanguage, "operation"},
		{ctx.WorkspaceLanguage, "workspace"},
		{ctx.AccountLanguage, "account"},
		{"en-US", "product_default"},
	}
	for _, candidate := range candidates {
		if candidate.tag == "" {
			continue
		}
		if supported[candidate.tag] {
			return candidate.tag, candidate.source, nil
		}
	}
	return "", "", errors.New("no supported language")
}

func main() {
	tag, source, err := resolveLanguage(RequestContext{
		OperationLanguage: "pt-BR",
		WorkspaceLanguage: "en-US",
	})
	fmt.Println(tag, source, err)
}

The resolver returns only language preference and provenance. Region, jurisdiction, currency, and time zone must come from their own trusted inputs or approved defaults.

Prompt Localization: One Task Contract, Multiple Realizations

Separate Invariants from Locale Modules

A task contract should define language-independent behavior:

task_id
required inputs
permitted tools
success criteria
facts that require evidence
prohibited side effects
output schema
global safety invariants

Locale modules can then define:

instruction realization
approved terminology
register and politeness
examples and counterexamples
formatting constraints
local escalation wording
local policy overlays
evaluation cases

This avoids two bad extremes:

• one English prompt translated literally for every market;
• unrelated prompts whose behavior drifts without a common contract.

Prompt Release Evidence

For each task and locale, keep:

• task-contract version;
• locale-module version;
• translator or author and reviewer;
• terminology source;
• prompt diff;
• model snapshot and decoding settings;
• native evaluation result;
• unresolved linguistic or policy exceptions.

A bilingual reviewer should assess meaning, while native task users assess whether the behavior is useful and natural. Fluency alone is not enough.

Locale-Aware RAG Is Source Governance

Filtering by language is necessary but insufficient. Retrieval metadata should include:

Retrieval Decision Order

1. Determine what scope the question actually requires.
2. Apply tenant and authorization filters.
3. Apply jurisdiction, product, and effective-date constraints.
4. Retrieve in the requested language.
5. If evidence is incomplete, apply the configured fallback.
6. Preserve source language and translation path in citations.
7. Tell the generator what is authoritative, conflicting, or missing.

The BordIRLines research shows why multilingual retrieval is not simply "retrieve documents in the query language": source-language composition can affect consistency and geopolitical bias, and retrieval systems may prefer particular languages. Evaluate cross-lingual source selection as a system behavior.

Never Use Silent Market Fallback

When a local source is missing, choose one explicit outcome:

• stop: high-risk legal, medical, or financial task;
• warn and use global guidance: low-risk documentation;
• cross-lingual retrieval: approved authoritative sources exist in another language;
• escalate: human or local expert review is required.

Record which policy fired. A confident US answer silently substituted for an EU or Japanese policy is worse than a visible "local evidence unavailable."

Tools and Agents Need Locale-Aware Contracts

Localization changes actions, not just prose:

Parse, Normalize, Confirm

For consequential actions:

1. parse input under the locale contract;
2. normalize to a typed internal representation;
3. display the normalized interpretation;
4. require confirmation when ambiguity remains;
5. send typed arguments to the tool;
6. verify the final state and preserve unrelated state.

Do not ask an LLM to emit a free-form date string and pass it directly to an API.

Safety Policy: Global Invariants with Local Implementation

Localization must not reduce core safety. Use layers:

1. Global invariants: prohibited harms and non-negotiable controls.
2. Jurisdiction rules: legally required differences.
3. Cultural and linguistic realization: terminology, examples, escalation, tone.
4. Product policy: market availability and support path.

Test:

• euphemisms, dialect, code-switching, and transliteration;
• non-English prompt injection;
• mixed-language tool arguments;
• refusal consistency and over-refusal;
• protected-class and culturally specific harms;
• cross-language leakage of restricted content.

Do not create a weaker translated safety prompt and call it local adaptation.

Multilingual Evaluation That Measures the Product

Three Complementary Test Sets

Translated parity sets isolate language effects. Native-market sets reveal assumptions that translation cannot create. WorldBench illustrates this distinction by using culturally grounded workflows and checking both task completion and preservation of surrounding state.

Metrics

• task success and final-state correctness;
• preservation of non-target state;
• factual claims supported by authoritative evidence;
• terminology consistency;
• date, number, currency, name, and unit accuracy;
• tool selection and typed argument accuracy;
• safety false-positive and false-negative rates;
• fallback and escalation correctness;
• p50/p95 latency and token/cost distribution by locale;
• human acceptability from qualified native reviewers.

Aggregate scores can hide one failing language or market. Release gates should be per locale and per high-risk task class.

Release and Rollback

Locale Readiness Gate

1. Canonical tag and supported variants are documented.
2. Locale fields have authoritative sources and precedence.
3. CLDR-backed formatting is used for user-visible values.
4. Task and locale modules are versioned separately.
5. Retrieval sources have scope, authority, and effective dates.
6. Missing-evidence fallback is tested.
7. Tool arguments are parsed into typed values and confirmed where ambiguous.
8. Native and parity evals pass.
9. Safety probes include code-switching and local abuse patterns.
10. Monitoring, owner, feature flag, and rollback exist for this locale.

Roll Back Behavior, Not User Data

Version:

• prompt and terminology modules;
• retrieval indexes and source policies;
• model routes;
• tool schemas;
• safety overlays;
• evaluation sets.

A rollback should restore the last approved behavior while preserving auditable events and user data under the applicable retention policy.

Common Failure Modes

FAQ

Is Accept-Language enough?

It is useful for presentation, not for jurisdiction, currency, time zone, or product entitlement. It is also a preference list, not proof of identity or location.

Should one master prompt be maintained in English?

Maintain one task contract. A reference-language realization can aid collaboration, but each released locale needs reviewed prompt modules and behavioral evidence.

Can machine translation be used?

Yes, as a drafting or runtime component with provenance and quality controls. High-impact instructions, policies, terminology, and evaluations require appropriate human review.

Should RAG always prefer same-language documents?

Not always. Prefer sources based on authority, scope, freshness, and policy. Cross-lingual retrieval may add important evidence, but translation path and conflicts must remain visible.

Why measure state preservation for localized agents?

An agent can complete the requested action while damaging unrelated files or records. Locale-specific parsing and tool errors make final-state and non-target preservation checks essential.

Primary Sources

• W3C Internationalization, Choosing a Language Tag — practical BCP 47 tag selection and the principle of using only necessary subtags.
• Unicode Consortium, Unicode Locale Data Markup Language, UTS #35 — CLDR locale identifiers, data, matching, dates, numbers, units, and related conventions.
• Li et al., Multilingual Retrieval Augmented Generation for Culturally-Sensitive Tasks — cross-lingual retrieval composition, consistency, and bias evidence.
• Ranaldi et al., WorldBench: Culturally Grounded Benchmark for Multilingual Agents — native-language, culturally grounded agent tasks and final-state preservation evaluation.
• AI Product Privacy Engineering — jurisdiction, purpose, vendor, and data-lineage controls used by the locale contract.

Related Learning Path

• AI SaaS Pricing — market, currency, entitlement, and price-book localization.
• Prompt Engineering — structured task instructions and behavior constraints.
• Retrieval-Augmented Generation — the retrieval architecture behind multilingual evidence.
• Context Engineering — assembling locale, policy, evidence, and tool context.

Summary

AI localization is the engineering of locally correct behavior. The application must own an explicit locale contract, use standards for tags and formatting, govern multilingual evidence, constrain locale-sensitive tools, and evaluate each market with both shared invariants and native tasks.

The product is ready for a locale only when it can explain which assumptions it used, which evidence it retrieved, which policy it applied, and how it verified the final state.