Over the past few months, we’ve been working on a project called PolyTalk.
The original goal was pretty simple: make real-time multilingual communication possible without depending on external translation APIs or cloud-only services.
While testing existing solutions, we noticed that many of them required sending conversations through third-party infrastructure. That works for some use cases, but it wasn’t a great fit for organizations that care about privacy, deployment flexibility, or keeping communication workflows under their own control.
So we started building a self-hosted, open-source speech-to-speech translation platform instead.
A few things we’ve focused on:
Real-time speech translation Self-hosted deployment Open-source core No external translation APIs Live audio translation
The project is still evolving, but it’s been interesting exploring the challenges of multilingual communication, local AI infrastructure, and real-time translation workflows.
I’d be curious to hear how others here approach translation.
Are you using cloud-based services, self-hosted tools, or something in between?
GitHub: https://github.com/PolyTalkIO/polytalk
Website: https://polytalk.io/
Fair point. Looking back, the title probably promised more specifics than the post delivered.
A few things we’ve learned so far:
Running speech recognition, translation, and TTS locally is absolutely possible, but latency becomes one of the biggest challenges. Supporting multiple audio sources (microphones, meetings, browser tabs, system audio, etc.) often ends up being more complex than the translation itself. Self-hosting is a much stronger requirement than we initially expected for organizations with privacy, compliance, or data sovereignty concerns. Choosing models is a constant tradeoff between quality, speed, hardware requirements, and language coverage.
Regarding AI usage: the translation pipeline itself is AI-based. For the rest of the project, we’ve used AI tools where they were helpful, for example, coding assistance, drafting documentation, brainstorming, and editing content, but all code, documentation, testing, and releases are reviewed and validated by the team before becoming part of the project.
Thanks for the feedback. You’re right that this post ended up being more of a project introduction than a lessons-learned write-up.