Your agent answers in the language they wrote to you in.

Look at what moved, not just the words. The agent's own sentence is translated — but so is the menu underneath it, both lines of every row, and the direction of the whole bubble. That is the platform drawing the same list three ways, not the model improvising a translation.

Worth knowing what this pack's default is: Binaa is configured default_settings.locale: ar. The English pane is therefore not the pack falling back — it is detection overriding the pack's own default, on the first message, before the customer had done anything but say hello.

The detector is a local statistical model — not a call to a large language model, and not an extra round-trip. It returns a language and a real probability, and anything at or above the gate counts as confident. It is then clamped to your pack's roster: a language you ship no words for is discarded rather than stored, because storing it would point every translated string at copy that does not exist.

Those last two rows are the honest part of this page. A bare greeting is weak evidence in any script. مرحبا is five letters and the model called it Persian; had this pack shipped Persian, it would have answered in Persian. A greeting is a coin-flip; a sentence is not. Everything in the next section exists because of that.

One more rule, easy to miss and load-bearing: a button tap is never evidence. Button and list titles are text your bot wrote, in the language it already chose — detecting on one would make the current language confirm itself forever. Only the customer's own prose is ever read.

That fourth row is the whole design in one line. An English product name inside an Arabic sentence, an order reference like ACC-2291, a one-word ok — none of them can flip a customer who has been speaking Arabic for a week.

“Twice” means twice among confident readings, not twice in a row. A tap, a photo, or an unreadable reply between two Arabic sentences does not break the streak, because those turns never reach the detector at all. Most readers assume the opposite.

“The detector never ran” and “the detector declined” look identical from outside — and they have opposite fixes. One is /lang auto; the other is a message with more words in it. So the timeline records which of the two happened, rather than leaving a blank.

Declare what you speak

supported_languages: is optional, and it is a claim the platform checks in both directions against the locale files you actually ship. Declare a language you have no file for, or ship a file for a language you did not declare, and the deploy is refused.

Why declare it at all when the files are right there on disk? Because intent is not on disk. A pack that shipped Arabic and English and then lost its last English file drops to one language and looks, byte for byte, exactly like a pack that was always Arabic. The declaration is what makes the difference visible.

Ship the same keys in every language

A pack shipping two or more languages must ship the same copy in each — the same keys, interpolating the same placeholders. A missing translation now fails the deploy.

This is a gate because the runtime is forgiving, and forgiveness here is indistinguishable from correctness. A key missing from locale.ur.yaml does not error — it silently falls through to another language your pack ships. So an Urdu customer reads one Arabic line in the middle of an Urdu card, and nothing anywhere reports a problem. A pack shipping a single language is never nagged about any of this.

Setting a language from a flow — rarely

set_language exists for the cases that genuinely need it: a compliance rule, or a CRM record that already knows. It is the exception, not the pattern — a language menu asks the customer what they already answered by typing.

What makes it safe is that it cannot store a language your pack does not ship. A refusal is a port you can handle, not a silent write — so you can tell the customer what you do speak:

The previous way of doing this validated nothing: any string became explicit, detection was then blocked forever, every translated string missed, and the customer read your default while the record claimed something else. Silent, permanent, and untested — which is why the old path is gone.

Add supported_languages: to your manifest and deploy. The check runs in both directions, so it is the fastest way to find a language you meant to ship and didn't — the failure that otherwise reaches a customer as a blank line, or a sentence in a language they don't read.

Then look at the contacts on a live project. A wall of unset on a multilingual pack means your customers are sending greetings, not sentences — and greetings, as the panes above show, are the one input this feature is honestly bad at.