/**
 * Which language is this reply actually in? (BOFF-7107)
 *
 * The assistant reads replies aloud by choosing a voice for `useI18n().locale` —
 * the UI language. That is the wrong signal the moment the model answers in the
 * language the USER wrote in rather than the one the chrome is set to, which is
 * exactly what the language directive in `assistantPrompt` now asks it to do.
 * A Tamil reply read by an English voice is confident nonsense, and it is the
 * one failure the speech module is built to make impossible.
 *
 * So playback keys on the reply text instead. Deliberately by SCRIPT, not by a
 * statistical language detector:
 *
 *  - it is deterministic, dependency-free and costs no bundle;
 *  - for the languages HealthyBowl actually serves beyond English — Tamil,
 *    Hindi, Arabic, Chinese — the script IS the language, unambiguously;
 *  - a detector that can separate en/es/fr/de (`franc` and friends) is ~40KB and
 *    still guesses on short strings.
 *
 * The honest limitation: **Latin-script languages cannot be told apart this
 * way.** A Spanish reply in an English UI still gets an English voice. That is a
 * far smaller failure than the cross-script one (an English voice reading
 * Spanish is accented but intelligible; an English voice reading Tamil is
 * noise), and closing it needs a real detector — a deliberate later choice, not
 * an oversight.
 */
/**
 * The locale whose voice should read `text`, or `null` when the script does not
 * decide it (empty, no letters, or Latin — see the module note).
 */
export declare function detectScriptLocale(text: string): string | null;
/**
 * The locale to speak `text` in: the script when it decides, else the app locale.
 *
 * Falling back to the app locale (rather than refusing) keeps every Latin-script
 * reply behaving exactly as it did before this existed.
 */
/**
 * ⚠️ `appLocale` is the caller's best available signal for "which language did
 * the user mean", and it is only as good as that signal.
 *
 * With the interface language alone it is a weak proxy: an English-UI user who
 * writes in Urdu produces an Urdu reply, but `appLocale` says `en`, so a shared
 * Arabic script falls back to the family default and picks an Arabic voice.
 * BOFF-7108 is what fixes this properly — it lets the user state the language
 * they are speaking, independently of the interface, and passes THAT here.
 *
 * Callers should therefore hand in the most specific language they know: the
 * user's declared conversation language if there is one, the UI locale only as a
 * last resort.
 */
export declare function resolveSpeechLocale(text: string, appLocale: string): string;
//# sourceMappingURL=replyLanguage.d.ts.map