When a localization comes out wrong, your assistant can reproduce the issue, inspect the engine's state, and identify the root cause — all in one conversation.
The workflow#
"The German localization of 'data processing agreement' came out as 'Datenverarbeitungsvereinbarung' but our legal team requires 'Auftragsverarbeitungsvertrag'. Why?"
What happens:
- The assistant localizes the source string through your engine to reproduce the issue
- Pulls the glossary to check if the term is covered
- Checks scorer verdicts and glossary compliance for recent requests
- Reports the root cause: "The term isn't in your glossary — the model chose a valid but non-standard localization"
- Recommends the fix: "Add a glossary entry to enforce the legal team's preferred term"
When to use this#
- A user or reviewer reports a bad localization
- A scorer pass rate drops unexpectedly
- You notice inconsistent terminology across localizations
- A localization request failed and you need to understand why
What the assistant inspects#
| Signal | What it checks |
|---|---|
| Wrong terminology | Glossary coverage — is the term defined? Was it matched? |
| Wrong tone/register | Brand voice configuration — does the locale have one? |
| Rule violation | Instruction review logs — did the rule apply? Did it pass? |
| Model failure | Request logs — did the primary model fail? Did fallback trigger? |
| Scorer failure | Scorer run logs — which scorer flagged it? What was the reasoning? |
Triage → Fix#
Triage identifies the cause. The fix depends on what's broken:
- Missing glossary term → "Add 'data processing agreement' → 'Auftragsverarbeitungsvertrag' to the glossary for
de" - Wrong brand voice → "Update the German brand voice to use formal register"
- Missing instruction → "Add an instruction for
deabout legal terminology conventions" - Model limitation → "Try a different primary model for
en → delegal content"
Your assistant can apply the fix immediately after you approve it — one conversation from bug report to resolution.