# Serve customers in a second language

Language is set in three places for three different reasons: the written channels take it as behaviour instruction, the phone takes it as a session parameter that can be pinned or left to detection, and Knowledge has to carry the material in that language or answers will be translated approximations of English source text. Configure all three, then test each one on its own.

- **Status:** Available
- **Audience:** both
- **Channels:** email, whatsapp, phone
- **In the app:** #/rules, #/calls
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/how-to/set-up-a-second-language/

## Three settings, three failure modes

| Surface | What you set | How it fails |
|---|---|---|
| Email and WhatsApp | Behaviour instruction: which language to reply in, and when to switch | Replies in the wrong language, or a mid-thread switch nobody asked for |
| Phone, engine side | A pinned language code, or detection left on | The voice answers in the wrong language and never recovers, because the code was pinned |
| Phone, steering side | Accent, pronunciation and the regional speaking style | Understandable but wrong-sounding — a register mismatch rather than a language error |
| Knowledge | Source material in that language | Fluent replies containing terminology translated on the fly, which is where product names go wrong |

Treating these as one setting is the usual mistake. A workspace that sets the written channels and nothing else gets correct email and an English phone line; one that pins a phone language code and nothing else gets a line that cannot switch when a caller opens in a different language.

## Setting it up

1. Write the language rule into the behaviour text: which language to answer in by default, and what to do when the customer writes in another.
   - Result: This is one instruction covering the written channels. Say what should happen on a mixed-language message explicitly — code-mixing is normal in several markets and the default choice is not obvious.
2. On the phone, decide between pinning a language code and leaving detection on.
   - Result: Pinning is more reliable for a line whose callers are consistent; detection is right for a line that genuinely receives both. Pinning a code on a mixed line is the setting that produces a call the caller cannot steer.
3. Set the regional speaking style for that line.
   - Result: This changes register, pacing and idiom rather than the language itself. It is a steering layer, so treat it as a request the model follows rather than a guarantee.
4. Add Knowledge in the target language — at minimum the product names, the service descriptions and anything with a fixed wording.
   - Result: Grounded answers now quote material that was written in that language instead of translating English on the fly.

## Testing each channel separately

These channels share nothing about language except the intent behind it, so a passing test on one says nothing about another. Three short tests, in this order, cover it.

1. **Written.** Send a message into the mailbox in the target language and read the draft before approving it. Check terminology, not fluency — fluency is rarely the problem.
2. **Phone, controlled.** Run a Voice Lab test call and speak the target language. The resolved settings are snapshotted on the call, so the review tells you which language configuration actually applied.
3. **Phone, mixed.** Open in one language and switch mid-call. This is the test that finds a pinned code, and it is the one people skip.

> **Note** Read the call review afterwards rather than judging by ear. Findings such as an unheard caller or a false stop are often a language problem wearing a latency costume — end-of-speech detection behaves differently when the speech is not what was expected.

## What does not change

- Autonomy. A second language does not relax what Connect may send without asking.
- Compliance. Suppression, unsubscribe and do-not-contact are checked in the same single place regardless of language.
- The record. One person writing in two languages is one person, one timeline and one memory — language is not an identity.
- Commercial safety. A price the material does not support is refused in every language.

## Questions

### Can different channels use different languages?

Yes. The written instruction and the phone's language setting are separate, so a workspace can answer email in one language and take calls in another. That is a deliberate configuration rather than a fault, but it surprises people, so write it down where the team can see it.

### Does adding a language need a second workspace?

No. It needs behaviour text, a phone setting and Knowledge in that language. A second workspace would split the relationships as well, which is almost never what a bilingual business wants.

### Why does the phone sometimes answer in the wrong language on the first turn?

Detection needs speech to work from, so the opening line is decided before the caller has said anything. Pinning the code fixes the greeting and costs you the ability to switch; the trade is real and depends on the line.

## Related

- [Multilingual calling](https://connectbyjbrh.com/docs/phone/multilingual-calls/)
- [Detecting the caller's language](https://connectbyjbrh.com/docs/phone/language-detection/)
- [Regional speaking style](https://connectbyjbrh.com/docs/phone/regional-speech/)
- [Light code-mixing and slang](https://connectbyjbrh.com/docs/phone/code-mixing/)
- [Knowledge sources](https://connectbyjbrh.com/docs/knowledge/sources/)
- [The voice answered in the wrong language](https://connectbyjbrh.com/docs/troubleshooting/wrong-language-on-call/)

## What this page is based on

- Connect source pack: phone (docs-source/sources/PHONE.md §6 — engine and steering knobs)
- Connect source pack: channels (docs-source/sources/CHANNELS.md §1 — draft generation)
- Connect capability registry (docs-source/facts.py — regional_speech_style)