Inhaltsverzeichnis
Wenn Sie damit beauftragt wurden, Lokalisierungstools für Ihr Team zu evaluieren, haben Sie wahrscheinlich schon bemerkt: Der TMS-Markt ist verwirrend. Marketing-Seiten versprechen „nahtlose Workflows" und „KI-gestützte Übersetzung", sagen aber kaum etwas darüber aus, wie Übersetzungen tatsächlich in Ihre App gelangen, wer was bezahlt oder wie schmerzhaft die Migration sein wird.
Dieser Leitfaden räumt damit auf. Wir behandeln, was ein TMS tatsächlich tut (und nicht tut), die drei Architekturmodelle, denen Sie begegnen werden, eine 10-Kriterien-Evaluierungs-Checkliste und ein Entscheidungsframework, das Ihnen hilft, die richtige Kategorie für Ihre Situation zu wählen.
Was ein TMS tatsächlich tut (und nicht tut)
Ein Translation-Management-System sitzt zwischen Ihrem Quellinhalt und Ihren Endbenutzern. Im Kern löst es drei Probleme:
- Verfolgen, was übersetzt werden muss — neue Strings, geänderte Strings, gelöschte Strings
- Koordinieren, wer was übersetzt — Übersetzer zuweisen, Review-Workflows verwalten
- Übersetzte Inhalte ausliefern — die fertigen Übersetzungen in Ihre App bringen
Die meisten Engineering-Teams konzentrieren sich stark auf Punkt 3 und unterschätzen Punkte 1 und 2. Das ist ein Fehler. Wo ein TMS bei Tracking und Koordination versagt, entstehen in der Regel Lokalisierungs-Backlogs.
Was ein TMS nicht tut, trotz dem, was manche Anbieter implizieren: Es ersetzt nicht Ihren Quellcode, macht Ihre App nicht automatisch mehrsprachig und eliminiert nicht die Notwendigkeit menschlicher Reviews bei kritischen Inhalten. KI-Übersetzung hat sich dramatisch verbessert, aber „gut genug für eine App-Store-Beschreibung" und „gut genug für ein juristisches Dokument" sind unterschiedliche Maßstäbe.
Die drei TMS-Architekturen
Das Verständnis des Liefermodells ist die wichtigste Architekturentscheidung, die Sie treffen werden. Jedes TMS auf dem Markt fällt in eine von drei Kategorien.
File-Sync TMS
Das älteste und verbreitetste Modell. Ihre App enthält Locale-Dateien (JSON, YAML, PO usw.) in einem Verzeichnis wie /locales oder /public/lang. Das TMS zieht diese Dateien, schickt sie zur Übersetzung und pusht übersetzte Dateien über einen Sync-Mechanismus zurück in Ihr Repo — typischerweise ein CLI-Tool, eine GitHub-Integration oder ein CI/CD-Schritt.
So funktioniert es in der Praxis: Sie führen tms pull aus, um die neuesten Übersetzungen abzurufen, committen sie und deployen. Oder das TMS öffnet nach einem Zeitplan einen PR mit aktualisierten Locale-Dateien.
Vorteile:
- Funktioniert mit jedem Stack — wenn Ihre App eine Datei lesen kann, funktioniert es
- Einfach zu verstehen und zu prüfen — Übersetzungen sind nur Dateien in Ihrem Repo
- Ausgereifte Tooling- und große Ökosysteme
- Keine Laufzeitabhängigkeit von einem externen Service
Nachteile:
- Locale-Dateien wachsen schnell und erzeugen laute Diffs
- Übersetzungsaktualisierungen erfordern einen Deploy-Zyklus
- Branching-Strategien werden kompliziert — welcher Branch hat die „echten" Übersetzungen?
- Key-Management über mehrere Dateien wird fehleranfällig
- Keine Typsicherheit — fehlende oder umbenannte Keys schlagen zur Laufzeit still fehl
API-First TMS
Anstatt Dateien zu synchronisieren, ruft Ihre App Übersetzungen zur Laufzeit von einem TMS-API-Endpunkt ab. Dadurch entfallen Locale-Dateien aus Ihrem Repo. Das TMS ist eine Laufzeitabhängigkeit.
So funktioniert es in der Praxis: Beim App-Start (oder bei jeder Anfrage) ruft Ihr Client eine API wie GET /translations?locale=de&namespace=checkout auf. Das TMS gibt ein JSON-Objekt mit den aktuellen Übersetzungen zurück.
Vorteile:
- Übersetzungsaktualisierungen sind sofort — kein Deploy erforderlich
- Keine Locale-Dateien, die Ihr Repo verschmutzen
- Einfachere Verwaltung einer großen Anzahl von Keys
Nachteile:
- Cold-Start-Latenz, wenn nicht sorgfältig gecacht
- Netzwerkabhängigkeit zur Laufzeit — ein TMS-Ausfall kann Ihre App beschädigen
- Caching-Strategien sind Ihr Problem
- SDK-Qualität variiert stark — Typsicherheit oft nicht vorhanden
- Per-Request-Preismodelle können bei großem Maßstab teuer werden
CDN-First TMS
Eine neuere Architektur, die die Liefervorteile von API-first mit den Performance-Eigenschaften statischer Dateien kombiniert. Übersetzungen werden kompiliert und als unveränderliche, versionierte Bundles in ein CDN veröffentlicht. Ihre App ruft ein Locale-Bundle einmal ab (in der Regel beim Start oder beim Locale-Wechsel) und cached es aggressiv.
So funktioniert es in der Praxis: Sie veröffentlichen im TMS, das ein Bundle kompiliert und an Edge-Standorte pusht. Ihre App ruft https://cdn.example.com/v42/de.json ab und verwendet es für die Session. Die URL-Struktur macht die Cache-Invalidierung deterministisch.
Vorteile:
- Keine Locale-Dateien in Ihrem Repo
- Sofortige Cache-Invalidierung bei Übersetzungsveröffentlichung
- Vorhersagbare, latenzarme Auslieferung — CDN Edge ist schneller als Ihre API
- Übersetzungsaktualisierungen erfordern keinen Deploy
- SDKs können aus dem Schema generiert werden, was Typsicherheit ermöglicht
Nachteile:
- Etwas komplexeres mentales Modell als File-Sync
- Bundle-Versionierungsstrategie erfordert etwas Planung
- Weniger ausgereiftes Ökosystem im Vergleich zu File-Sync-Tools
10 Kriterien zur Evaluierung eines TMS
Verwenden Sie diese Checkliste bei Ihrer Evaluierung. Bewerten Sie jeden Kandidaten mit 1–5 für jedes Kriterium.
1. Developer-Workflow-Integration
Passt das TMS zu der Art, wie Ihr Team bereits arbeitet? Achten Sie auf: native Git-Integration (PR-basierte Workflows, Branch-Erkennung), ein CLI, das in CI/CD-Pipelines funktioniert, und Extraktionstools, die Ihr Framework verstehen (React, Vue, Swift, Android usw.).
Warnsignal: Wenn die TMS-Integration einen separaten Deployment-Schritt erfordert, der nicht in Ihrer bestehenden Pipeline enthalten ist, wird er übersprungen.
2. Übersetzungsliefermodell
Welche Architektur verwendet es? Passen Sie es an Ihre Anforderungen an: Wenn Sie sofortige Aktualisierungen ohne Deploys benötigen, funktioniert File-Sync nicht. Wenn Sie P99-Latenz unter 50 ms für das Laden von Übersetzungen benötigen, funktioniert auch ein ungecachter API-first-Ansatz nicht. Fragen Sie Anbieter konkret: „Wie gelangen Übersetzungen Schritt für Schritt von Ihrem System in eine Produktions-App?"
3. KI-Übersetzungsfähigkeiten
Das Spektrum ist hier breit. Am einen Ende: rohe maschinelle Übersetzung (nur Strings an einen MT-Anbieter weiterleiten). Am anderen Ende: kontextbewusste Übersetzung, die Ihre UI versteht, Ihr Glossar durchsetzt, Platzhalter korrekt behandelt und auf Ihre Markenstimme abgestimmt werden kann.
Wichtige Fragen:
- Berücksichtigt die KI-Übersetzung Ihr Glossar und Translation Memory?
- Kann sie Pluralisierungsregeln für Zielsprachen verarbeiten?
- Wie geht sie mit dynamischen Variablen in Strings um (z.B.
Hello, {name})?
4. Typsicherheit und SDK-Qualität
Für Engineering-Teams wird dies oft unterschätzt, bis der erste Laufzeitabsturz durch einen fehlenden Übersetzungs-Key auftritt. Gute SDKs generieren Typen aus Ihrem Übersetzungsschema, sodass t('checkout.cta.button') zur Kompilierzeit fehlschlägt, nicht in der Produktion.
Evaluieren Sie das SDK hinsichtlich: TypeScript-Unterstützung, Key-Autovervollständigung, Pluralbehandlung, Interpolations-Typsicherheit und framework-spezifischen Integrationen.
5. Transparenz des Preismodells
TMS-Preisgestaltung ist notorisch undurchsichtig. Gängige Modelle:
- Pro Sitz (Redakteure/Übersetzer)
- Pro übersetztes Wort (MT oder menschlich)
- Pro Key (Anzahl der verwalteten Strings)
- Plattformgebühr + Nutzung
Erstellen Sie eine konkrete Schätzung basierend auf Ihren tatsächlichen Zahlen: wie viele Keys, wie viele Locales, wie viele Übersetzer, wie viele Wörter pro Monat übersetzt. Fragen Sie dann, was passiert, wenn Sie das Limit überschreiten.
Siehe unsere Preisseite für unseren Ansatz dazu.
6. Glossar und Translation Memory
Translation Memory (TM) speichert frühere Übersetzungen, damit konsistente Strings nicht zweimal übersetzt werden. Glossardurchsetzung stellt sicher, dass Markenbegriffe, Produktnamen und Fachterminologie nie falsch übersetzt werden.
Diese Funktionen sparen Geld und verbessern die Konsistenz. Fragen Sie Anbieter: „Wenn ich 'dashboard' in einem Kontext übersetze, wird das automatisch über alle Locales hinweg wiederverwendet?"
7. Kollaborationsfunktionen
Wenn Sie interne Übersetzer haben oder mit einer Lokalisierungsagentur arbeiten, muss das TMS auch deren Workflow unterstützen. Achten Sie auf: visuellen Editor (Übersetzungen im Kontext der tatsächlichen UI bearbeiten), Review-/Genehmigungsworkflows, Kommentar-Threads zu spezifischen Keys und rollenbasierte Zugriffskontrolle.
Wenn Ihr Team nur aus Entwicklern besteht und Sie KI-Übersetzung + externe Reviews verwenden, ist leichtgewichtiges Tooling hier in Ordnung. Zahlen Sie nicht für Enterprise-Kollaborationsfunktionen, die Sie nicht nutzen werden.
8. Skalierbarkeit
Wie sieht das TMS beim 10-fachen Ihres aktuellen Maßstabs aus? Konkret:
- Keys: Wie verschlechtert sich die Performance bei 100.000+ Übersetzungs-Keys?
- Locales: Gibt es ein praktisches Limit für die Anzahl der Zielsprachen?
- Teamgröße: Können Sie mehrere Projekte/Namespaces mit separaten Teams verwalten?
- Anfragedurchsatz: Wenn Sie ein API-first- oder CDN-first-Modell verwenden, was sind die Durchsatzgrenzen?
9. Migrationsaufwand
Den TMS-Anbieter zu wechseln ist schmerzhaft. Seien Sie ehrlich über die Kosten, bevor Sie sich verpflichten. Evaluieren Sie:
- Kann das neue TMS Ihre vorhandenen Locale-Dateien oder Ihr TM importieren?
- Was ist der SDK-Migrationspfad? Muss jede Übersetzungsaufrufstelle in Ihrer Codebase geändert werden?
- Gibt es Ausfallzeiten während der Umstellung?
- Was passiert mit Ihren vorhandenen Glossar- und TM-Daten?
10. Vendor-Lock-in-Risiko
Dies hängt mit dem Migrationsaufwand zusammen, verdient aber ein eigenes Kriterium. Fragen Sie: „Wenn ich Ihre Plattform in zwei Jahren verlassen möchte, was nehme ich mit?" Sie sollten in der Lage sein, Ihr Translation Memory, Ihr Glossar und alle übersetzten Inhalte in Standardformaten zu exportieren. Wenn die Antwort vage ist, ist das ein Signal.
Vergleichstabelle
| Kriterium | File-Sync TMS | API-First TMS | CDN-First TMS |
|---|---|---|---|
| Developer-Workflow | Git-freundlich, PR-basiert | API/SDK-fokussiert | Git + SDK, typsicher |
| Übersetzungsauslieferung | Deploy erforderlich | Laufzeit-API-Aufruf | CDN-Bundle, edge-gecacht |
| Aktualisierungsgeschwindigkeit | Langsam (Deploy-Zyklus) | Sofort | Sofort |
| Laufzeitabhängigkeit | Keine | Hoch | Gering (gecachtes Bundle) |
| Typsicherheit | Selten | Möglich | Nativ (schema-gesteuert) |
| Locale-Dateien im Repo | Ja | Nein | Nein |
| KI-Übersetzung | Variiert | Variiert | Kontextbewusst |
| Latenz | Entfällt (gebündelt) | Abhängig vom Caching | Gering (Edge CDN) |
| Keys skalieren | Wird unübersichtlich | Generell gut | Generell gut |
| Lock-in-Risiko | Mittel | Mittel–Hoch | Abhängig vom Anbieter |
Entscheidungsframework
Wenn Sie ein kleines Team sind, das schnell ohne viel Lokalisierungskomplexität entwickelt, ist File-Sync wahrscheinlich in Ordnung. Es ist einfach, gut verstanden und hat keine Laufzeitabhängigkeiten. Der Schmerz kommt später, wenn Sie viele Locales und häufige Übersetzungsaktualisierungen haben.
Wenn Sie sofortige Übersetzungsaktualisierungen ohne Redeploys benötigen und ein API-Budget zur Verfügung haben, ist API-first ein Schritt nach oben. Stellen Sie nur sicher, dass Sie keine Zuverlässigkeitsabhängigkeit einführen — wenn Ihre TMS-API um 2 Uhr nachts nicht verfügbar wird, ist das nun Ihr Bereitschaftsproblem.
Wenn Sie eine moderne Frontend-App mit TypeScript entwickeln, schnelle Time-to-Interactive benötigen und möchten, dass Übersetzungsaktualisierungen unabhängig von Ihrer Deploy-Pipeline veröffentlicht werden, ist CDN-first der Weg, in den sich das Ökosystem entwickelt. Die Kombination aus Typsicherheit, Edge-Auslieferung und Deploy-Unabhängigkeit ist schwer zu widersprechen, wenn man einmal damit gearbeitet hat.
Wenn Sie ein Engineering-Manager sind, der für ein Team evaluiert, das über 3–4 Locales hinausgewachsen ist und beginnt, den Schmerz von Locale-Dateien im Repo, langsamen Übersetzungs-Deploys und fehlenden Keys in der Produktion zu spüren — das ist genau der Wendepunkt, an dem ein TMS-Architekturwechsel sich auszahlt. Upgraden Sie nicht einfach innerhalb der gleichen Architektur. Evaluieren Sie alle drei.
Sehen Sie, wie verschiedene Architekturen in der Praxis abschneiden, auf unseren Vergleichsseiten, oder lesen Sie über entwicklerorientierte Funktionen.
Migrationsüberlegungen: Was man vor dem Wechsel fragen sollte
Bevor Sie sich für ein neues TMS entscheiden, gehen Sie diese Checkliste mit dem Anbieter durch:
Datenportabilität
- Kann ich alle übersetzten Strings im TMX- oder XLIFF-Format exportieren?
- Kann ich mein Glossar als Standard-CSV- oder TBX-Datei exportieren?
- Gibt es einen Migrationsleitfaden für den Import von [meinem aktuellen Tool]?
SDK-Migration
- Wie sieht der Wechsel des Client-SDK aus? Ist es ein Drop-in-Ersatz oder ein vollständiges Umschreiben aller Übersetzungsaufrufstellen?
- Haben Sie ein Codemod oder ein Migrationsskript?
- Kann ich beide SDKs parallel während eines stufenweisen Rollouts betreiben?
Umstellung
- Gibt es einen Zeitraum, in dem beide Systeme gleichzeitig aktiv sind?
- Wie gehen Sie mit Inhalten um, die in Bearbeitung sind (Strings, die zur Übersetzung geschickt, aber noch nicht zurückgekommen sind)?
Preisgestaltung während der Migration
- Gibt es einen Migrations-Testzeitraum?
- Was ist das Kostenmodell während einer Parallelbetriebsphase, in der ich für zwei Systeme zahle?
Das Fazit
Der TMS-Markt hat mit der modernen Frontend-Architektur nicht Schritt gehalten. Die meisten Tools gehen immer noch davon aus, dass Locale-Dateien in Ihrem Repo leben, dass ein Deploy ein akzeptabler Weg für eine Übersetzungsaktualisierung ist, und dass „Typsicherheit" bedeutet, Ihre Key-Benennungskonvention in einer README zu dokumentieren.
Diese Annahme war 2015 sinnvoll. Sie gilt nicht mehr in einer Welt, in der Ihr Frontend ein CDN-deployed statisches Bundle ist, Ihr Team mehrmals täglich deployed und ein fehlender Übersetzungs-Key einen Checkout-Flow für einen lokalisierten Markt still beschädigen kann.
Wenn Sie Tools evaluieren, beginnen Sie mit dem Liefermodell. Alles andere — KI-Qualität, Kollaborationsfunktionen, Preisgestaltung — ist zweitrangig gegenüber: Wie gelangen Übersetzungen tatsächlich in meine App, und wie schnell?
Wenn Sie sehen möchten, wie ein CDN-first-Ansatz in der Praxis aussieht, erkunden Sie unsere Funktionen oder sehen Sie, wie wir uns vergleichen mit den Tools, die Sie wahrscheinlich bereits evaluieren.
Better i18n ist eine entwicklerorientierte Lokalisierungsplattform, die für moderne Frontend-Teams entwickelt wurde. Typsichere SDKs, Git-basierte Workflows, CDN-Auslieferung und KI-Übersetzung mit Glossardurchsetzung — ohne Locale-Dateien in Ihrem Repo.
