I built TransLee for my own family, using the same Gemini Live API that Google publishes starter code for. That raises an obvious question I hadn’t actually answered yet: does something like this already exist, built by someone else, that I could have just used?

So I searched GitHub for it.

What’s Already Out There

A few projects showed up using the same Gemini Live API for translation:

The Feature I Thought Was Unique, Wasn’t

TransLee has a “translated voice” checkbox for its conversation mode. Check it before you speak, and your Korean gets translated and spoken out loud in whatever language you picked, so you can take part in a meeting in a language you don’t speak. I wrote about how that checkbox came to be in an earlier post in this series — it took fourteen discarded attempts at automatic detection before I realized the checkbox already did the job.

I assumed that was a real differentiator. It isn’t. live-translator’s conversation mode does close to the same thing: two people talking, each hearing the other translated, no extra device needed on either side. Roughly 70 languages on my side, roughly 78 on theirs. Same idea, built independently.

So that feature is not a reason to pick TransLee over the alternative. It’s just confirmation that this is a reasonable way to solve the problem, since two people arrived at a similar design without copying each other.

The Gap That’s Still There

One thing none of these projects do: listen to a device’s own speaker output and translate it. TransLee can sit next to a phone playing a YouTube video in a foreign language, or catch what a video call’s speaker is putting out, and translate that audio directly. Every open-source project I found is built around a microphone — a person talking into the device, not the device listening to its own sound.

I wrote about building that speaker-capture feature in an earlier post in this series, back when I was chasing a “whisper” mode from the old app.

The Difference That Isn’t About Features at All

The real practical gap wasn’t a missing feature. It was setup.

live-translator’s conversation mode needs no extra hardware for either person — same as TransLee. But to use it, you have to deploy your own backend server first: a FastAPI app, run locally or on Cloud Run, with your own Gemini API key. That’s not a small ask for someone who isn’t already comfortable with cloud deployment.

There are real reasons for that design, and none of them are arbitrary. The Gemini API key has to live somewhere that isn’t a browser tab, or anyone can read it out of the page source. The Live API’s sessions expire roughly every 15 minutes, and live-translator’s backend handles that by quietly opening a new session before the old one closes — something a phone browser tab can’t reliably do once it’s in the background. And the project reads like what it actually is: a reference build from a Google Cloud developer relations engineer, meant to show other developers how the pieces fit together, not a product for someone to just open and use.

TransLee needs the same things underneath — an API key that isn’t sitting in client-side code, and the same session handling. The difference is that I already solved that once, on my own NAS, before my family ever opened the app. For them, there’s no deployment step. It’s a page that already works.

Where That Leaves TransLee

Nobody else’s project catches a device’s own speaker audio. And nobody else hands a non-technical user a translator with zero setup, because the deployment work already happened, once, on hardware I already owned.

Everything else — the conversation mode, the language count, even the checkbox — turned out to be a case of two people solving the same problem in similar ways, not a real advantage either direction. I’d rather know that than assume it.