Support multiple languages without losing clarity

Responding in a visitor’s language is only the beginning of multilingual support. The difficult part is preserving meaning: plan names, legal terms, product labels, error messages, and instructions must stay consistent even when the sentence structure changes.

Chatty can make the first interaction feel local, but the underlying content and operating rules still need deliberate design.

Decide what should and should not be translated

Create a terminology policy before translating the knowledge base. Mark each term as one of:

• Translate: general explanations and instructions
• Keep unchanged: product names, plan names, URLs, code, and UI labels that must match the product
• Translate with a glossary term: legal, technical, or industry language where consistency matters

For example, a plan called Standard should remain Standard if that is the label in the checkout interface. The surrounding explanation can be translated.

Detect language, then confirm when needed

Short messages such as “Hi” or a product name are ambiguous. Chatty should not overreact to a single token. Use the conversation’s strongest signal, and ask a lightweight confirmation when the language is unclear:

I can continue in English or Spanish. Which would you prefer?

Once the visitor chooses, keep the language stable unless they switch naturally.

Keep source content authoritative

A translated article is not automatically an authoritative article. If the English source says a feature is available on Business but the translated copy still says Pro, the assistant has conflicting evidence. Choose a source-of-truth model:

1. Maintain one canonical source and translate at response time.
2. Maintain approved localized sources with owners and review dates.
3. Use a hybrid: localized product copy plus a canonical technical reference.

The right model depends on how often your product changes and how much legal or regional variation exists.

Test meaning, not grammar alone

Native review should cover whether the answer is correct and natural for the audience. Test:

• Numbers, dates, currencies, and time zones
• Formal versus informal address
• Product and plan names
• Negative instructions such as “do not share”
• Ambiguous technical terms
• Links and code snippets
• The fallback path when content is missing

An answer can be grammatically perfect and still mislead because a qualifier disappeared in translation.

Use examples that reflect real phrasing

Customers do not all ask textbook questions. Include regional spelling, abbreviations, mixed-language messages, and voice-transcript imperfections in your evaluation set. The purpose is not to imitate every dialect; it is to make sure the intent is recognized without forcing visitors to rewrite their question.

Keep the handoff language-aware

If a visitor asks for a human, preserve their preferred language in the handoff summary. Tell the support team when translation may be needed, and avoid promising that a specialist is immediately available unless that is true.

I’ll pass this to the team with the conversation context. A team member may reply in English if a specialist for your preferred language is not available.

Clarity about the next step is better than a warm but inaccurate promise.

Review by language and intent

Do not evaluate multilingual quality only with one average score. A language can look healthy overall while failing on one high-value intent such as billing or cancellation. Break reporting down by:

Multilingual support becomes manageable when it is treated as an operating system: clear terminology, approved sources, realistic tests, and an honest handoff. Chatty can then be conversational without becoming inconsistent.