the short answer
TypeSafe’s model documentation says Jev is strongest in English. It does not provide a complete per-language quality table that supports treating all languages as equivalent. Jev can receive text in other languages, but production support must be established per language, locale and criterion with native-speaker labels, calibration, boundary tests and monitored coverage. Translate or route unsupported cases explicitly rather than assuming parity.
- Official guidance
- English is strongest
- Complete language matrix
- Not published in the reviewed model docs
- Unit of validation
- Language × locale × criterion × domain
- Code switching
- Test as a separate slice
- Safe rollout
- Offline labels, shadow traffic, bounded coverage
“Accepts Text” Is Not the Same as Validated Support
A request may complete in a language even when its error rate or probability calibration is unsuitable for the application. Language support includes vocabulary, grammar, dialect, locale conventions, domain terminology and the criterion wording—not merely successful tokenization.
The only broad official statement used here is that English is strongest. Do not turn anecdotal success in one language into a product-wide support claim. Date every tested model and provider.
Define Support as a Deployment Matrix
Publish a support claim only for cells with enough representative evidence. “Spanish customer-support routing on jev-1.13.0” is testable; “multilingual Jev” is too broad.
| Dimension | Why it changes the result |
|---|---|
| Language and script | Lexical and writing-system coverage differ |
| Locale | Dates, numbers, currency and policy meaning differ |
| Domain | Legal, medical and product vocabulary differ |
| Criterion | Routing may work where nuanced safety judgment does not |
| State/question language | Translated instructions can change semantics |
| Code switching | Evidence may mix languages within one case |
Choose a Language Strategy and Test Its Failure Modes
Never hide machine translation inside preprocessing without versioning it. The translator becomes part of the evaluator and must be included in error analysis.
| Strategy | Benefit | Risk |
|---|---|---|
| Question and state in source language | Avoid translation loss | Question behavior may vary by language |
| Question in English, state in source language | One maintained rubric | Cross-language interpretation may weaken |
| Translate state to English first | Uses strongest stated language | Translation can alter evidence or protected terms |
| Route unsupported languages to review | Limits automation risk | Adds cost and delay |
Treat Translation as a Separate Measured Component
A disagreement can originate in translation or in Jev. Retain both versions so reviewers can attribute it. Test named entities, negation, politeness, idioms, dates and domain terminology with meaning-preserving and meaning-changing pairs. If translation adds more latency, cost or error than direct evaluation, route that language directly or keep it in human review.
Use Native Labels and Locale-Specific Boundary Cases
- Recruit reviewers fluent in the language and familiar with the domain.
- Preserve original text; store translations as separate versioned fields.
- Include dialect, slang, politeness, negation, transliteration and code switching.
- Test dates, decimal separators, currencies and named entities explicitly.
- Measure reviewer agreement before attributing disagreement to Jev.
- Keep each language represented in untouched release and monitoring sets.
Report Performance and Calibration per Language
An aggregate score weighted toward English can conceal severe errors in smaller languages. Report class-specific errors, Brier or log loss, action coverage, unscorable rate and review load per supported cell. Include uncertainty because small samples can make apparent rankings unstable.
Do not copy English thresholds into another language. Fit on separate calibration evidence, then evaluate once on held-out examples. The dataset guide covers grouping and leakage; monitoring covers production slices.
Store Language and Translation Lineage with Every Result
This application record makes the path reproducible; it is not a TypeSafe response schema. Keep locale separate from detected language because regional vocabulary and numeric conventions can change meaning. A code-switched message may need multiple language tags or its own slice rather than one forced label.
{
"source_language": "es-MX",
"language_method": "translated_to_en",
"translation_version": "translator-x.prompt-v3",
"original_evidence_ref": "message://m-418",
"translated_evidence_ref": "projection://m-418-en-v3",
"jev_model": "jev-1.13.0",
"question_version": "refund_request.en.v2",
"raw_answer": { "noul": 0.76 },
"threshold_version": "refund_request.es-MX.v1"
}Roll Out One Validated Language Slice at a Time
Define Support Levels from Measured Behavior
Support attaches to a language, locale, criterion, domain, projection and model version—not to the language name alone. Publish sample size, label process, error bounds and known exclusions beside the status. Reopen the gate after a model, translator, rubric or traffic change. The evaluator scorecard provides the release dimensions.
| Status | Meaning | Allowed use |
|---|---|---|
| Unsupported | No representative validation set | Do not automate; collect evidence or route elsewhere |
| Experimental | Offline evidence exists but live behavior is unmeasured | Shadow or reviewer-assist only |
| Limited | Specific criterion and slice meet release targets | Automate only the validated bands with audit sampling |
| Supported | Sustained quality, calibration, coverage and operations meet documented targets | Production use within the tested scope |
FAQ
Is Jev English-only?
TypeSafe says Jev is strongest in English, not that other text is categorically rejected. Validate every non-English deployment independently.
Should I translate all state into English?
Not automatically. Compare direct and translated paths because translation can remove or change evidence and adds another model dependency.
Can one threshold work across languages?
Do not assume so. Check calibration and error costs separately, then choose language-specific operating points if supported by evidence.
How should code-switched text be tested?
Treat it as its own production slice with representative native review, rather than assigning it to whichever language appears most often.
Sources
Checked against the sources below on September 22, 2026. Model versions, prices and limits change.
- TypeSafe AI docs: Models
- TypeSafe AI docs: State
- TypeSafe AI docs: Jev 1.13 jaggedness
- TypeSafe AI docs: Primitives
- NIST AI RMF: Measure function