globalize steht jetzt auf dem Nimdzi Language Technology Radar

Nimdzi hat globalize.now geprüft und auf seinem Language Technology Radar gelistet, dem Katalog des Analystenhauses für Sprachtechnologie-Produkte. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur, und Nimdzi ordnet sie an zwei Stellen ein: unter „Lokalisierung für Entwickler“ und unter „lokalisierungsspezifische LLM-Tools“. Dieser Beitrag erklärt, was der Radar ist, wo globalize darauf steht und warum Code-native Lokalisierung zu einer eigenen Kategorie geworden ist.

Was ist der Nimdzi Language Technology Radar?

Der Radar ist eine Live-Datenbank für Sprachtechnologie, gepflegt von Nimdzi Insights. Er hat den älteren Language Technology Atlas abgelöst, eine jährliche Marktübersicht, und wird kontinuierlich aktualisiert. Die Ausgabe 2026 nennt mehr als 1.100 Produkte von 756 Unternehmen.

Die Produkte sind in elf Kategorien gruppiert, von Translation Management Systems und maschineller Übersetzung bis zu Spracherkennung und Dolmetschsystemen. Mehrere Kategorien haben Unterkategorien, und ein Produkt erscheint dort, wo sein Kernangebot hingehört – nicht überall, wohin sich eines seiner Features dehnen ließe.

Wie wird ein Tool geprüft?

Ein Unternehmen reicht seine Daten ein, und die Researcher von Nimdzi verifizieren sie anhand öffentlicher Informationen, Briefings mit dem Anbieter und der eigenen Nutzung der Tools. Die Aufnahme ist kostenlos. Nimdzi betont, keine Provisionen anzunehmen, um Listungen, Rankings oder Reviews zu beeinflussen – deshalb hat eine Listung bei Käufern Gewicht.

Für globalize hieß das: eine Fragerunde des Radar-Teams, bevor das Profil als vollständig markiert wurde. Auf welchen Modellen und Engines die Übersetzung läuft. Ob Qualitätsprüfungen auch außerhalb der Plattform funktionieren. Wie Korrekturen in künftige Übersetzungen einfließen. Die Kategorien spiegeln diese Antworten wider, keine Selbstbeschreibung.

Wo steht globalize auf dem Radar?

globalize erscheint in zwei Kategorien.

Translation Management Systems, Lokalisierung für Entwickler. Diese Unterkategorie umfasst Tools, die für Engineering-Teams gebaut sind statt für Übersetzerteams. Der Unterschied liegt darin, wo die Arbeit passiert. Ein klassisches TMS ist ein separater Workspace, in den Strings hinein- und wieder herausgesynct werden. globalize arbeitet im Repo, das Ergebnis ist also ein Pull Request mit Locale-Dateien und kein Export aus einem Dashboard.

Large Language Models, lokalisierungsspezifische LLM-Tools. globalize nutzt Sprachmodelle für die Übersetzung und für einen zweiten Review-Durchlauf, der in jeder Sprache Bedeutung, Platzhalter, Glossarbegriffe und Style-Guide-Konformität prüft. Die Kategorie gilt für Tools, bei denen das Modell gezielt auf Lokalisierungsarbeit angewendet wird – nicht für allgemeinen Chat.

Das Profil auf der Nimdzi-Site kannst du dir direkt ansehen.

Warum ist Lokalisierung für Entwickler eine eigene Kategorie?

Weil sich geändert hat, wer die Strings ausliefert. Vor ein paar Jahren übergab ein Produktteam Texte an eine*n Localization Manager:in, die oder der sie durch ein TMS schickte und Dateien zurückgab. Heute releast ein Solo-Founder dienstags eine mit Cursor oder Lovable gebaute Next.js-App und will sie bis Freitag auf Japanisch haben. Es gibt keine Localization-Manager:innen, und niemand will noch ein Dashboard synchron halten.

Dieser Wandel schafft eine andere Aufgabe.

classic TMS:  code  →  export strings  →  TMS workspace  →  translators  →  import files  →  code
globalize:    code  →  push  →  translated pull request  →  merge

Die Aufgabe auf Entwicklerseite hat zwei Teile. Erstens muss die Codebase überhaupt lokalisierbar sein, was bei KI-generierten Apps meist nicht der Fall ist. Sie kommen mit hartcodierten Strings in den Komponenten, ohne Schlüssel und ohne Locale-Dateien. globalize erledigt das einmalig in der App, wenn du dein Repo verbindest. Zweitens muss jede spätere Änderung übersetzt werden, ohne dass jemand daran denken muss. Nach dem Setup kommt jeder Push mit neuem oder geändertem Text als Pull Request mit den Übersetzungen zurück, vom KI-Review geprüft und bereit zum Mergen.

Ist globalize dann ein TMS?

Nein, auch wenn Nimdzi die Unterkategorie für Entwickler unter der TMS-Rubrik führt. globalize sitzt zwischen deiner i18n-Bibliothek und deiner Übersetzungs-Engine. Bibliotheken wie next-intl und i18next liefern Übersetzungen zur Laufzeit aus, und globalize arbeitet mit der Bibliothek weiter, die du ohnehin nutzt. Translation Management Systems wie Lokalise und Crowdin steuern Übersetzer-Workflows. globalize erzeugt und pflegt die Schlüssel und Locale-Dateien, sodass ein Team ohne Übersetzer:innen diese Workflow-Ebene gar nicht braucht. Wenn du beide Ansätze vergleichst, geht der Vergleich mit Lokalise die Unterschiede durch.

Was macht globalize konkret in einem Repo?

globalize verbindet sich mit GitHub oder GitLab, scannt das Repository und richtet i18n ein, falls die App es braucht. Die Änderung wird zur Prüfung auf einen Branch gepusht. Nutzt die App bereits next-intl, react-i18next, i18next oder Lingui, bleibt dieses Setup erhalten und globalize übernimmt nur die Übersetzung.

Danach lösen drei Dinge einen Übersetzungsjob aus, alle per Einstellung unter deiner Kontrolle.

1. Ein Push mit neuem oder geändertem Text auf einen überwachten Branch.
2. Ein Pull Request, wenn du diese Option aktivierst.
3. Ein manueller Job aus dem Dashboard.

Jeder Job übersetzt nur, was neu oder geändert ist. Strings, die schon im Translation Memory liegen, werden wiederverwendet und nicht erneut berechnet. Dein Glossar und die Style Guides pro Sprache gelten für jeden Job, und der Review-Durchlauf markiert alles, was ein Mensch ansehen sollte, bevor es deinen Default-Branch erreicht. Das Ergebnis landet als Pull Request, der nur deine Locale-Dateien anfasst.

Die Formate decken Web und Mobile ab, darunter JSON, gettext PO, XLIFF, YAML, Flutter ARB, Apple String Catalogs und Android-String-Ressourcen. Die Abrechnung erfolgt pro Workspace ohne Seat-Gebühren, die aktuellen Pläne stehen auf der Preisseite.

Warum zählt eine Analysten-Listung, wenn du Entwickler bist?

Für die meisten Entwickler ändert sie wenig. Du beurteilst globalize am ersten Pull Request, und genau dafür gibt es den kostenlosen Test. Die Listung ist für zwei andere Gruppen relevant.

Die erste Gruppe sind Teams mit einem Localization Lead. Wer als Localization Manager Tools evaluiert, liest Nimdzi, und ein unabhängiges, geprüftes Profil zeigt: Das Produkt existiert, funktioniert wie beschrieben und gehört zu einer Kategorie, die man kennt. Das ist ein kürzeres Gespräch als bei einer Kaltakquise-Demo.

Die zweite Gruppe sind Käufer, die ein klassisches TMS verlassen. Teams, die Lokalise oder Phrase gegen ein codenatives Setup eintauschen, wollen wissen, dass die Alternative real ist, bevor sie einen Produktivkatalog migrieren. Ein Radar-Eintrag ist eines der wenigen Signale in diesem Markt, die der Anbieter nicht selbst verfassen kann.

Was kommt als Nächstes?

Nimdzi betreibt außerdem einen TMS Feature Explorer, ein Profil pro Tool, das Funktion für Funktion aufgeschlüsselt ist. Der Eintrag für globalize ist in Arbeit. Sobald er live ist, zeigt er Punkt für Punkt, was globalize abdeckt und was bewusst nicht, etwa Übersetzer-Editoren und Vendor-Management, die außerhalb des Zwecks eines codenativen Tools liegen.

Bis dahin beurteilst du es am schnellsten an deinem eigenen Code. Verbinde ein Repo, lass globalize das Setup durchführen und lies den ersten übersetzten Pull Request.