Cal.com hat sich zum Ziel gesetzt, bis 2031 eine Milliarde Menschen über eine Open-Source-Infrastruktur für Terminplanung zu verbinden. Dafür muss das Produkt Nutzer in jeder Sprache erreichen – und genau das bremste die Engineering-Geschwindigkeit über Jahre hinweg spürbar aus.
Das Problem: ständig hinterher#
Cal.com hatte jeden gängigen Ansatz ausprobiert. Community-basierte Übersetzer über ein Translation-Management-System. Lokalisierungsagenturen. Jeder davon brachte zusätzliche Kosten und mehr Koordinationsaufwand mit sich – das Ergebnis blieb jedoch gleich: Selbst die wichtigsten Sprachen waren dauerhaft nicht auf dem neuesten Stand.
„Wir waren bei der Internationalisierung immer hinterher“, erinnert sich Keith Williams, Head of Engineering. „Trotz Investitionen in Agenturen und Crowdsourcing über Translation-Management-Systeme waren selbst unsere wichtigsten Sprachen nicht synchron. Die Kosten waren hoch, und die manuelle Arbeit hielt unsere Engineers davon ab, Features zu bauen.“
Dieses Muster ist typisch. Klassische Lokalisierungsplattformen verwalten die Workflows menschlicher Übersetzer – sie beseitigen den Koordinationsaufwand nicht, sondern strukturieren ihn nur. Jeder Release-Zyklus bedeutete eine weitere Übergabe an ein externes Team, eine weitere Wartezeit, eine weitere Runde der Prüfung. Das Engineering-Team konnte ein Feature an einem Tag shippen; die Lokalisierung dauerte bis zu zwei Wochen.
Der Wandel: Lokalisierung als Infrastruktur#
2025 führte Cal.com eine Lokalisierungs-Engine auf Lingo.dev ein. Eine ist eine zustandsbehaftete Übersetzungs-API: Sie speichert die Produktterminologie von Cal.com, das Vokabular rund um Terminplanung und die Konfiguration pro Sprache über sämtliche Übersetzungsanfragen hinweg. Trifft die Engine in einem englischen String auf „Workspace“ oder „Booking“, bestimmt das Glossar den korrekten Begriff je Sprache, bevor das Modell auch nur ein einziges Token generiert.
Wegen der Open-Source-Codebase und der breiten Contributor-Community von Cal.com waren für die Integration zunächst ein paar Anpassungen nötig. Das Team von Lingo.dev hat diese direkt gemeinsam mit ihnen umgesetzt.
„Ihre Reaktionszeiten waren unglaublich“, sagt Williams. „Wenn wir Anpassungen brauchten, kamen die Fixes schneller, als ich es je bei einem Anbieter erlebt habe.“
Ergebnisse#
Sobald die Lokalisierungs-Engine eingerichtet war, verband Cal.com sie mit der eigenen CI/CD-Pipeline. Jeder Code-Push startet die Engine – und die Übersetzungen werden automatisch in allen 36 Sprachen aktualisiert.
- Das Engineering-Team muss keine Übersetzungs-Workflows mehr verwalten
- Alle 36 Sprachen bleiben mit jedem Release synchron
- Deutlich geringere Lokalisierungskosten im Vergleich zu Agenturausgaben
- Keine Übergaben mehr – Übersetzungen laufen in derselben Pipeline wie Code-Deployments
„Das Beste daran? Unsere Engineers denken gar nicht mehr über Lokalisierung nach“, erklärt Keith. „Sie bauen einfach Features, und die Übersetzungen laufen automatisch. Genau das haben wir gebraucht, um Cal.com für Menschen auf der ganzen Welt zugänglich zu machen.“
Was als Nächstes kommt#
Cal.com erweitert die Lokalisierungs-Engine jetzt auf E-Mail-Vorlagen – den letzten verbleibenden Bereich, in dem Übersetzungen noch separat gehandhabt werden. Ist das abgeschlossen, läuft jeder nutzerseitige String im Produkt durch dieselbe Lokalisierungsinfrastruktur.
Für ein Team, das auf eine Milliarde Verbindungen hinarbeitet, zählt der kumulative Effekt: Jeder Glossarbegriff, der heute konfiguriert wird, wird bei jedem neuen Feature, jedem neuen Release und jeder neuen Sprache konsequent richtig angewendet.
