> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usefini.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Running multilingual AI support well
> How to decide which languages an AI support agent covers, choose between one source language and localized knowledge, and check quality per language with native reviewers.
To run multilingual AI support well, decide which languages you will fully support based on your customers and your ability to review quality, then choose per topic whether the agent answers from one source language or from localized articles. Check quality in each language with native-speaking reviewers, keep locale-specific policies in their own articles, and make sure every language has a path to a human who speaks it.
This playbook applies to any AI support agent. An agent that can produce fluent text in many languages is not the same as a support operation that is correct in many languages: the gap is in policies, terminology, review and escalation, and that is what this page covers.
## Step 1: Decide your language coverage
"We support every language the model can write" is not a coverage decision. Separate three levels:
| Level | What it means | Typical criteria |
| - | - | - |
| **Fully supported** | The agent answers end to end, knowledge is reviewed in that language, a human who speaks it is available on escalation. | Significant customer volume, a market you sell into, legal or contractual commitment to the language. |
| **Best effort** | The agent answers from source-language knowledge, translated at answer time. Quality is spot-checked, not guaranteed. Escalation may go to a team working in another language. | Low but real volume, no local policies. |
| **Not supported** | The agent replies in a default language and offers a handoff or another channel. | No volume, or topics too sensitive to risk a mistranslation. |
To build the list, pull a recent sample of tickets and group them by the customer's language, by country and by product. Then check commitments: some contracts, regulators or markets require service in a specific language. Write the result down, publish it internally, and revisit it when you enter a new market.
## Step 2: One source language or localized knowledge
This is the central design decision. There are two models, and most teams end up mixing them by topic.
**Translate at answer time.** You maintain knowledge in one source language. The agent reads it and replies in the customer's language. One article to update when a policy changes, and no version drift between languages.
**Localized articles.** You maintain separate articles per language (or per locale). Each one is written or reviewed by someone fluent, and can carry content that only applies in that market. More work to maintain, but you control the exact wording.
```mermaid theme={null}
---
title: Translate at answer time or localize the article?
---
flowchart TD
T["A topic in
your knowledge"] --> P{"Does the policy
differ by locale?"}
P -->|"Yes"| LOC["Localized article
per locale"]
P -->|"No"| W{"Is exact approved
wording required?"}
W -->|"Yes"| LOC
W -->|"No"| R{"High risk if
slightly mistranslated?"}
R -->|"Yes"| LOC
R -->|"No"| TR["One source article
translated at answer time"]
LOC --> REV["Native reviewer
approves each version"]
TR --> SPOT["Spot-check replies
per language"]
classDef source fill:#F7F7F7,color:#131415,stroke:#E8E8E8
classDef agent fill:#131415,color:#FFFFFF,stroke:#131415,stroke-width:3px
classDef human fill:#C3EE5E,color:#131415,stroke:#131415,stroke-width:2px
classDef surface fill:#FFFFFF,color:#131415,stroke:#131415
class T source
class P,W,R surface
class LOC,TR agent
class REV,SPOT human
```
Rules of thumb:
* **Localize** when the rule itself differs by market (cooling-off periods, tax, eligibility, local payment methods), when wording must match an approved translation (regulatory disclosures, terms), or when a small mistranslation would cause real harm (fees, medical or financial instructions).
* **Translate at answer time** for product how-tos, troubleshooting steps and general explanations, where the facts are the same everywhere.
* **Never let localized articles drift.** If you translate an article, record which source version it came from. When the source changes, the translations are out of date until someone updates them.
## Step 3: Build a terminology glossary
Product names, feature names, plan names and regulated terms are where multilingual answers go wrong most often. A small glossary prevents most of it.
| Source term | Spanish | German | Translate? | Notes |
| - | - | - | - | - |
| Example: "Instant Transfer" (feature name) | Instant Transfer | Instant Transfer | No | Product name, keep in English |
| Example: "chargeback" | contracargo | Rückbuchung | Yes | Use the term your local terms of service use |
| Example: "Premium plan" | plan Premium | Premium-Tarif | Partly | Match the name shown in the local app |
Keep the glossary short (the terms that matter, not a dictionary), owned by someone, and used by both the people writing localized articles and the instructions you give the agent.
## Step 4: Check quality per language with native reviewers
Aggregate quality numbers hide language problems. An agent can look excellent overall while a smaller language is quietly worse.
* **Build test cases per supported language.** Start from real conversations in that language, the way customers in that market write, including slang, typos and mixed languages. Do not just translate your English test cases; customers in different markets ask different questions.
* **Use native reviewers.** A fluent colleague reads a sample of real conversations each week and marks wrong facts, wrong terminology, awkward tone and wrong formality (for example, formal versus informal "you" in languages that distinguish them).
* **Review policy answers first.** Grammar errors are visible. A correct-sounding answer that states the wrong local policy is not, and it is the one that matters.
* **Rerun the tests after every change.** A prompt or knowledge change made for one language can affect another.
## Step 5: Handle locale-specific policies
Language and locale are not the same. A Spanish-speaking customer may be in Spain, Mexico or the US, with different rules in each. Plan for:
* **Scoping by market, not only by language.** Where policy differs, the agent needs to know the customer's market (from their account, the site they came from, or by asking), not only the language they wrote in.
* **Local legal wording.** Disclosures, complaint procedures and regulatory references often have approved local text. Store that text exactly and do not let the agent paraphrase it. Check your regulator's rules for each market.
* **Formats.** Dates, currencies, decimal separators and phone formats should follow the customer's locale.
## Step 6: Escalate to language-capable humans
An AI agent that speaks Portuguese and hands over to a team that does not is a broken experience. For each fully supported language, define:
* Which team or queue receives escalations in that language, and their hours.
* What happens outside those hours (expected wait time stated honestly, or a fallback language agreed with the customer).
* Whether the conversation summary handed to the human is in the customer's language, the team's language, or both.
For best-effort languages, say up front which language the human team works in, so the customer is not surprised.
## Step 7: Measure by language
Break every support metric down by language: resolution rate, escalation rate, customer satisfaction, reopen rate and reviewer findings. Look for:
* A language with a much higher escalation rate (often a knowledge gap or a missing localized policy).
* A language with normal resolution but low satisfaction (often tone, formality or terminology).
* Topics that resolve in one language and fail in another (often a translated article that drifted).
Report the per-language view alongside the overall number, so a regression in a smaller language is not hidden by a larger one.
## Common mistakes
* Treating fluent output as proof of correct answers.
* Translating the English test cases instead of building tests from real local conversations.
* Translating articles once and never updating them when the source changes.
* Scoping by language when the policy actually differs by country.
* Promising a language in the agent and having no one who speaks it on escalation.
## Doing this in Fini
In Fini (usefini.com), language coverage is set in these places:
* [Supported languages](/en/supported-languages) explains the three layers you control: the **Language** training preference in Sources, language folders in Articles, and language rules in [Prompts](/en/configuration/prompts) (**Main Guidelines → Role & Context**, **Channel Prompts**).
* Organize localized knowledge as language folders in [Articles](/en/knowledge/articles), and use **Translate** to create language versions that go through [Review](/en/knowledge/review) like any other change.
* Scope language content per agent with **Assign folders**, or per conversation with the folder's **Attribute Filter Builder**. See [Attribute filters](/en/knowledge/articles#attribute-filters).
* Store approved local wording, such as a regulated disclosure, as **Predefined Replies** so it is never paraphrased.
* Create [Test Suite](/en/testing/test-suite) test cases from real conversations in each language (or start a new one in that language from [Inbox](/en/testing/inbox)), and put each language in its own collection so you can run it with **Run collection**. Add an exact article check to confirm the agent used the right language folder, and an AI judgement for terminology and formality.
## Related
How language is set for knowledge, scoped per agent and controlled in replies.
Language folders, Translate and Attribute filters.
Test cases and collections you can run per language.
Audit and structure knowledge before you localize it.
## Related topics
- [How to run an AI support pilot](/en/playbooks/running-a-pilot.md)
- [Questions to ask an AI support vendor, with Fini's answers](/en/evaluate/questions-to-ask.md)
- [Testing an AI support agent before launch](/en/playbooks/testing-before-launch.md)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.