From a design discussion about supporting total beginners who need to lean on their mother tongue (MT) for content they can't yet express in the target language (TL, currently always Spanish).
The pedagogical idea: a beginner starts by speaking only the simplest TL phrases and uses MT for everything else, holding a real conversation with someone (or HablaBot) who understands both — gradually shifting more content into TL as their level grows. This is a deliberate immersion/crosstalk approach, not a bug to fix — see the existing hardcoded rule in js/ai/prompts.js:23 (Habla SOLO en español, excepto si el estudiante está completamente perdido), which this refines rather than replaces. The AI should keep replying in TL always; only the user's ability to lean on MT changes.
Ruled out: client-side MT detection/translation before sending to the model. HablaBot's live conversation pipeline is speech-to-speech over WebRTC directly to OpenAI's Realtime API — there is no point in the current architecture where HablaBot's own JS sees the user's words as editable text before the model hears them, so "translate the MT parts, forward only clean TL" isn't feasible without replacing the live audio pipeline with a very different one (local STT → text normalization/translation → inject as a text conversation item instead of audio). Not pursuing that rearchitecture for this.
What to actually build instead: rely on the model's native multilingual/code-switching understanding (large models handle mixed-language speech like "quiero un poco de water, please" reasonably well without any preprocessing), and instead:
js/utils/config.js — new setting, e.g. motherTongue (default 'English', user-overridable).js/ai/prompts.js — extend getBaseSystemPrompt()'s conversation rules with explicit crosstalk guidance parameterized by the configured MT, e.g.: the student may lean on {MT} for content they can't express yet in {TL}; understand it, but always respond in {TL} — model back the {TL} equivalent naturally rather than switching yourself, and gradually withdraw this tolerance as the student's difficulty level increases (tie into the existing difficulty tiers already in prompts.js).- Settings UI (
index.html) — a field/selector for mother tongue, likely near existing Learning Preferences.
Known, accepted limitation — not blocking, but worth noting: session.js's transcription language hint (currently hardcoded 'es', see the Issue #8 fix) only accepts a single ISO-639-1 code, so it can't represent "mostly TL, tolerate MT." This only affects HablaBot's own bookkeeping (chat history display, vocabulary-tracking transcripts) — not what the model itself hears/understands/responds to, since the model processes raw audio directly. Code-switched turns may just transcribe less accurately in HablaBot's own UI/tracking even once this is implemented.
From a design discussion about supporting total beginners who need to lean on their mother tongue (MT) for content they can't yet express in the target language (TL, currently always Spanish).
The pedagogical idea: a beginner starts by speaking only the simplest TL phrases and uses MT for everything else, holding a real conversation with someone (or HablaBot) who understands both — gradually shifting more content into TL as their level grows. This is a deliberate immersion/crosstalk approach, not a bug to fix — see the existing hardcoded rule in
js/ai/prompts.js:23(Habla SOLO en español, excepto si el estudiante está completamente perdido), which this refines rather than replaces. The AI should keep replying in TL always; only the user's ability to lean on MT changes.Ruled out: client-side MT detection/translation before sending to the model. HablaBot's live conversation pipeline is speech-to-speech over WebRTC directly to OpenAI's Realtime API — there is no point in the current architecture where HablaBot's own JS sees the user's words as editable text before the model hears them, so "translate the MT parts, forward only clean TL" isn't feasible without replacing the live audio pipeline with a very different one (local STT → text normalization/translation → inject as a text conversation item instead of audio). Not pursuing that rearchitecture for this.
What to actually build instead: rely on the model's native multilingual/code-switching understanding (large models handle mixed-language speech like "quiero un poco de water, please" reasonably well without any preprocessing), and instead:
js/utils/config.js— new setting, e.g.motherTongue(default'English', user-overridable).js/ai/prompts.js— extendgetBaseSystemPrompt()'s conversation rules with explicit crosstalk guidance parameterized by the configured MT, e.g.: the student may lean on {MT} for content they can't express yet in {TL}; understand it, but always respond in {TL} — model back the {TL} equivalent naturally rather than switching yourself, and gradually withdraw this tolerance as the student's difficulty level increases (tie into the existing difficulty tiers already inprompts.js).index.html) — a field/selector for mother tongue, likely near existing Learning Preferences.Known, accepted limitation — not blocking, but worth noting:
session.js's transcriptionlanguagehint (currently hardcoded'es', see the Issue #8 fix) only accepts a single ISO-639-1 code, so it can't represent "mostly TL, tolerate MT." This only affects HablaBot's own bookkeeping (chat history display, vocabulary-tracking transcripts) — not what the model itself hears/understands/responds to, since the model processes raw audio directly. Code-switched turns may just transcribe less accurately in HablaBot's own UI/tracking even once this is implemented.