Real-time speech translation · Indic languages
Two, three or four people, each on their own device. Everyone speaks normally and hears everyone else in their own language. Nobody selects what they are about to speak — the system works that out.
Every translation tool starts by asking a question the speaker cannot reliably answer: what language are you about to speak?
In a real bilingual conversation the answer changes sentence by sentence. People code-switch mid-thought. A Hindi speaker drops English nouns into a Hindi sentence; a Tamil speaker answers an English question in Tamil. Asking each person to reach for a dropdown before every utterance is not a small friction — it is the reason these tools get abandoned after the first minute.
Removing that question sounds like a small product decision. It is actually the constraint that determines the entire architecture, because automatic source-language detection over a live audio stream, across Indian languages, is a capability very few services offer at all.
The design rule: nobody picks their own language. Each person chooses only what they want to read and hear. Whoever speaks, the system detects it, translates it into the other person's language, shows both texts, and speaks the translation aloud.
No install, no accounts, no sign-in. Two links and a shared room code.
One opens Speaker A, the other Speaker B, on separate devices. Both enter a name and confirm they show the same room code.
You set only your own language. You never declare what you are about to speak — that is detected on every utterance.
Speech is segmented as you talk. The moment you stop, the utterance is transcribed, its language identified, and it is translated for the other person.
They hear it spoken in their own language and see both texts — the original and the translation — with the detected language and the round-trip time.
Both browsers stream raw audio to one server. That server does all the work and holds all the credentials, so no provider key ever reaches a browser.
Why a server in the middle at all. The browser could call a model provider directly, but that would ship the account key to every client. One server hop keeps every credential server-side and costs 20–60 ms against a roughly 1.5-second budget. It is verified: every deployed client asset is scanned for key prefixes on each release, and the count is zero.
Every requirement, mapped to its real state. Partial means the capability exists but has not been fully proven; roadmap means it is designed and not yet built. Nothing here is marked complete on the strength of intent.
| Requirement | What exists today | Status |
|---|---|---|
| Nobody selects their source language | Language is detected on every utterance; a manual override exists for when detection is wrong | Built |
| Several people, each on their own device | Two to four independent stations pairing on a shared room code; the lobby asks how many | Built |
| Everyone hears everyone, each in their own language | One utterance is translated once per distinct language in the room and delivered to everyone reading it; the passes run concurrently, so the last person does not wait for the first | Built |
| Speak and be heard in the other language | Full path: segment, transcribe, detect, translate, synthesise, deliver | Built |
| Conversational latency | ~3.0s end to end, measured on the live deployment in both directions | Built |
| No credential reaches the browser | Server-side only; verified by scanning every deployed asset each release | Built |
| People appear by name, not by slot | Names entered at the lobby, carried to the other side, sanitised server-side | Built |
| Both texts visible, not just the translation | Transcript shows original and translation, detected language pair, and round-trip time | Built |
| Works without an account | No sign-in anywhere; open the link, share the room code, talk | Built |
| The opening word is never clipped | An 800 ms pre-roll buffer is implemented; proven with synthetic audio only, where a stream has no lead-in to buffer | Partial |
| Speech synthesis in every supported language | Verified for the languages exercised so far; synthesis coverage is narrower than transcription coverage across every vendor surveyed | Partial |
| Survives a long silence mid-conversation | The idle-cancellation default is disabled in code; a multi-minute idle test has not been run | Partial |
| Always-on hosting, independent of any laptop | Container image and service definition are written and committed; the managed service is not yet created | Roadmap |
| Long turns start playing before they finish | Sentence-level pipelining is designed; the current path translates the whole utterance first | Roadmap |
| Accuracy numbers you can trust | A benchmark harness with error rates, detection accuracy and cost per utterance exists; its corpus is synthesised speech, so no accuracy figure from it should be quoted yet | Roadmap |
The same codebase, flipped by environment variables alone. No code changes between the lanes.
The tunnel runs on your own machine or your own network. Audio from both speakers passes only through a process you control, and the provider key never leaves it.
The identical server on a small container host, with the pages on a static host in front. Up around the clock, reachable from any browser, and the one you are pointed at from this page.
On access. The live demo is deliberately open — there is no sign-in and no gate. TalkBridge stores no accounts, keeps no conversation history on the server, and holds no user data for a gate to protect; a room code is all that separates one conversation from another. We would rather say that plainly than claim a protection the link does not have.
It takes at least two people and about thirty seconds. One device each — two tabs on one machine works, but you will hear yourself.