Der Browser kann Ihre App jetzt übersetzen. Hier ist, was er nicht kann.

Im Juni 2026 bekam die Frage "Brauche ich überhaupt noch ein Übersetzungstool?" eine neue Schärfe. Am 2. Juni kündigte Microsoft an, dass Microsoft Edge 148 eine eingebaute Translator-API mitbringt, gestützt auf geräteinterne Modelle für mehr als 145 Sprachen, kostenlos und privat. Googles Chrome hat dieselbe API stabil seit Chrome 138 (Juni 2025), heute mit 37 Sprachen und Sprachvarianten. Zwei der meistgenutzten Browser der Welt können jetzt jede Seite lokal und kostenlos übersetzen.

Es lohnt also, ehrlich zu fragen: Wenn der Browser Ihre App kostenlos übersetzt, brauchen Sie dann noch ein Translation-Management-System?

Die kurze Antwort: Der Browser übersetzt, das TMS governt. Sie konkurrieren nicht um dieselbe Aufgabe. Dieser Beitrag ist die ehrliche Fassung des Warum, mit einem lauffähigen Rezept, das den Browser als sanktionierten Fallback einspannt, während Ihre Übersetzungen governt bleiben.

Was der Browser tatsächlich tut, und gut tut

Ehre, wem Ehre gebührt. Die eingebaute Translator-API ist ein wirklich schönes Stück Plattform-Engineering, und die Demo ist kurz. Per Feature-Detection prüfen, ob die API da ist, prüfen, ob das Sprachpaar verfügbar ist, einen Translator erzeugen, übersetzen:

// Progressive Enhancement: läuft nur, wo die API existiert.
if ('Translator' in self) {
  const pair = { sourceLanguage: 'en', targetLanguage: 'de' }

  const availability = await Translator.availability(pair)
  // 'unavailable' | 'downloadable' | 'downloading' | 'available'

  if (availability !== 'unavailable') {
    const translator = await Translator.create({
      ...pair,
      monitor (m) {
        m.addEventListener('downloadprogress', (e) => {
          console.log(`Modell-Download: ${Math.round(e.loaded * 100)}%`)
        })
      }
    })

    const out = await translator.translate('Where is the nearest bus stop?')
    console.log(out) // "Wo ist die nächste Bushaltestelle?"

    translator.destroy() // Modell freigeben, wenn fertig
  }
}

Das ist alles. Das Modell für ein Sprachpaar wird einmal heruntergeladen, bleibt dann seitenübergreifend verfügbar, und die API funktioniert in Edge genauso (hier dokumentiert), inklusive einer translateStreaming()-Variante für Token-für-Token-Ausgabe. Was Sie bekommen, ist echt:

• Sofort. Nach dem einmaligen Modell-Download passiert die Übersetzung lokal ohne Netzwerk-Roundtrip.
• Kostenlos. Keine API-Keys, keine Abrechnung pro Zeichen, kein Kontingent.
• Privat. Der Text verlässt nie das Gerät und wird nicht zum Trainieren von Modellen gesammelt.
• Offline. Ist das Modell einmal heruntergeladen, funktioniert es ohne Verbindung.

Für "eine Besucherin landet auf einer Seite in einer Sprache, die Sie nie ausgeliefert haben, und will sie trotzdem lesen" ist das ausgezeichnet. Es ist die moderne, geräteinterne Version der Übersetzungsleiste, verfügbar für Ihren Code. Wenn das Ihr Bedarf ist, nutzen Sie sie und hören Sie hier auf zu lesen.

Aber das ist ein anderer Bedarf, als ein lokalisiertes Produkt zu betreiben. Hier verläuft die Grenze.

Die Governance-Lücke

Ein Translation-Management-System ist nicht im Geschäft, einen String in einen anderen zu verwandeln. Es ist im Geschäft, Übersetzung zu einem kontrollierten, prüfbaren, auslieferbaren Prozess über ein Team und über die Zeit hinweg zu machen. Die Browser-API tut nichts davon, bauartbedingt, und es lohnt, konkret statt abfällig zu sein, was genau fehlt.

Keine Keys, keine Struktur. Die API übersetzt einen String, den Sie ihr übergeben. Sie hat keine Ahnung, dass dieser String checkout.pay_now ist, dass er im Namespace checkout lebt, dass er ein Plural-Geschwister hat oder dass er bereits eine freigegebene französische Übersetzung hat, für die Sie Geld ausgegeben haben. Sie übersetzt Text, nicht Ihr Content-Modell. Alles unterhalb von "wir haben einen strukturierten Katalog aus Keys" existiert hier schlicht nicht.

Kein Review-Status, kein Freigabe-Nachweis. Es gibt keinen Nachweis, dass ein Mensch die deutsche Übersetzung Ihrer Rückerstattungsrichtlinie angesehen und abgesegnet hat. Dieser Nachweis ist zunehmend nicht optional: Unter dem EU AI Act führt der Pfad, der maschinell übersetzte Inhalte von öffentlichem Interesse aus der sichtbaren Offenlegungspflicht heraushält, durch dokumentiertes menschliches Review, und eine frisch im Browser der Besucherin erzeugte Übersetzung hat per Definition kein solches Review angehängt (wir haben diese Pflicht und die Review-Workflow-Ausnahme separat aufgeschrieben). Compliance-Prüfung kann nicht client-seitig im Nachhinein stattfinden.

Keine Terminologie- oder Brand-Voice-Kontrolle. Ihr Produkt nennt es "Workspace", nicht "Büro", und Ihr Ton ist das informelle "du", nicht das förmliche "Sie". Das Browser-Modell kennt Ihr Glossar oder Ihren Styleguide nicht, und es gibt keine Möglichkeit, sie ihm mitzuteilen: Die Translator-API ist ein abgeschlossenes, aufgabenspezifisches Übersetzungsmodell, kein instruierbares LLM, also hat sie keinen Prompt- oder System-Instruktions-Kanal, über den sich Terminologie, Ton oder Translation Memory einschleusen ließen. Jede Besucherin kann eine leicht andere, nicht markenkonforme Wiedergabe desselben Buttons bekommen.

Keine Quality Estimation. Wenn das Modell eine Übersetzung falsch macht, kennzeichnet nichts das. Es gibt keinen Konfidenzwert, kein Routing der zweifelhaften Fälle an einen Menschen. Quality Estimation und ein Review-Workflow sind genau das Sicherheitsnetz, das geräteinterne Übersetzung entfernt.

Keine Formattreue. Plurale, Genusformen, Interpolation ({{count}} items, {{name}}), verschachtelte Komponenten innerhalb eines Satzes: das sind i18n-Probleme, keine Satzübersetzungs-Probleme. Übergeben Sie einem Modell einen String mit einem Platzhalter, wetten Sie darauf, ob der Platzhalter an der richtigen Stelle überlebt. ICU-Pluralregeln sind nichts, worüber ein Übersetzungsaufruf zur Anzeigezeit nachdenkt.

Kein SSR, kein SEO. Das ist das Große für eine öffentliche Seite. Der Browser übersetzt das DOM nachdem es gerendert wurde, im Browser der Besucherin. Suchmaschinen-Crawler, Link-Vorschauen und Ihr eigenes serverseitiges Rendering sehen nur die Originalsprache. Eine vom Browser übersetzte Seite ist für Google eine nicht übersetzte Seite. Sie können in einem Markt, dessen Sprache nur jemals client-seitig existiert, nicht ranken.

Mobile-Abdeckungslücken. Chromes Translator- und Language-Detector-APIs sind als Desktop-only dokumentiert; auf Mobilgeräten funktionieren sie nicht. Ein großer Anteil Ihrer Nutzer ist auf dem Smartphone, wo dieser ganze Mechanismus derzeit fehlt.

Kein gefestigter Standard. Nur die beiden Chromium-Browser bringen sie mit. Mozilla hat eine negative Position zur Web Translation API hinterlegt und verfolgt einen Gegenvorschlag, und WebKit hat keine Position bezogen. Die API wird in der W3C Web Machine Learning Working Group inkubiert, ihre Form kann sich also noch ändern. Eine Kernerfahrung darauf zu bauen heißt heute, auf der Vorschau einer einzigen Engine-Familie zu bauen, nicht auf der Webplattform.

Nichts davon macht die Browser-API schlecht. Es macht sie zu einer Anzeige-Technologie. Der Fehler wäre, eine Anzeige-Technologie als Content-Management-Technologie zu behandeln.

Die Architektur: Der Browser übersetzt, das TMS governt

Stellen Sie beide dorthin, wo sie hingehören, und sie hören auf zu konkurrieren:

• Der governte Kern. Ihre echten Übersetzungen leben in einem TMS: strukturiert nach Key und Namespace, übersetzt von KI und maschineller Übersetzung mit Ihrem Glossar und Styleguide als Kontext, bewertet von Quality Estimation, geprüft von Menschen dort, wo es zählt, versioniert und an jeden Browser, jeden Crawler und jedes Smartphone per CDN ausgeliefert. Das ist der Inhalt, hinter dem Sie stehen, der rankt, den ein Auditor nachverfolgen kann.

• Der sanktionierte Fallback. Für die Lücken, die Sprachen, die Sie noch nicht ausgeliefert haben, den brandneuen Key, der vor einer Stunde live ging, die Long-Tail-Sprache, die Sie nie besetzen werden, lassen Sie den Browser einspringen. Sofort, kostenlos, für die Besucher, deren Browser kann. Es ist eine elegante Degradation, nicht das Produkt.

Der Trick ist, beide so zu verdrahten, dass der Fallback temporär und selbstheilend ist: Jedes Mal, wenn der Browser etwas übersetzen muss, wird diese Tatsache zu einem Signal, das in den governten Kern zurückfließt und ihn fürs nächste Mal ordentlich übersetzen lässt.

Das Rezept: i18next-Missing-Key-Fallback, selbstheilend nach Locize

Hier ist diese Schleife, konkret, mit i18next und Locize. Die Idee:

1. Ein Key hat keine Übersetzung in der aktiven Sprache. i18next rendert den Quelltext (sein normaler Fallback) und feuert saveMissing.
2. saveMissing meldet den Key an Locize, wo automatische Übersetzung und Quality Estimation loslegen und ein Mensch prüfen kann.
3. Währenddessen übersetzt für Besucher auf einem unterstützenden Browser die geräteinterne Translator-API den Fallback-Text direkt vor Ort, sodass sie sofort ihre Sprache sehen statt Englisch.
4. Beim nächsten Publish ist die ordentliche, geprüfte Übersetzung in Locize und auf dem CDN. Der Key existiert nun in der Zielsprache, der Fallback feuert nicht mehr, und die governte Übersetzung hat die geräteinterne Vermutung still ersetzt.

Zuerst die i18next-Seite. Das Locize-Backend meldet fehlende Keys für Sie:

import i18next from 'i18next'
import { initReactI18next } from 'react-i18next'
import Backend from 'i18next-locize-backend'

i18next
  .use(Backend)
  .use(initReactI18next)
  .init({
    fallbackLng: 'en',
    saveMissing: true, // in der aktiven Sprache fehlende Keys an Locize melden
    backend: {
      projectId: '<your-project-id>',
      version: 'latest',
      // Ein Write-API-Key wird NUR zum MELDEN fehlender Keys gebraucht. Liefern
      // Sie ihn nie an Endnutzer aus. Siehe die Vorbehalte unten: Melden Sie in
      // Dev/Staging oder hinter Ihrem eigenen Endpoint, nicht im Production-Bundle.
      apiKey: import.meta.env.DEV ? '<dev-only-api-key>' : undefined
    }
  })

Nun der Anzeigezeit-Fallback. Ein kleiner Hook liest einen Key; musste i18next auf eine andere Sprache zurückfallen, bittet er den Browser, den Fallback-Text geräteintern zu übersetzen, und tauscht ihn ein, sobald er bereit ist:

import { useEffect, useState } from 'react'
import { useTranslation } from 'react-i18next'

// Eine fehlende Übersetzung geräteintern und kostenlos füllen, während Locize
// den Key richtig übersetzen lässt. Reines Progressive Enhancement: wo die
// Translator-API fehlt (Mobile, Firefox, Safari), gibt das einfach den
// Fallback-Text zurück.
export function useGovernedT (key) {
  const { t, i18n } = useTranslation()

  // returnDetails sagt uns, welche Sprache i18next tatsächlich genutzt hat.
  const details = t(key, { returnDetails: true })
  const target = i18n.language
  const source = details.usedLng        // die Sprache, auf die zurückgefallen wurde
  const fallbackText = details.res      // Text in dieser Fallback-Sprache
  const missingInTarget = !!source && source !== target

  const [onDevice, setOnDevice] = useState(null)

  useEffect(() => {
    setOnDevice(null)
    if (!missingInTarget) return
    if (typeof self === 'undefined' || !('Translator' in self)) return

    let cancelled = false
    ;(async () => {
      const pair = { sourceLanguage: source, targetLanguage: target }
      const availability = await Translator.availability(pair)
      if (availability === 'unavailable') return

      const translator = await Translator.create(pair)
      const translated = await translator.translate(fallbackText)
      translator.destroy()

      if (!cancelled) setOnDevice(translated)
    })().catch(() => { /* bei jedem Fehler beim Fallback-Text bleiben */ })

    return () => { cancelled = true }
  }, [key, source, target, fallbackText, missingInTarget])

  // Die geräteinterne Übersetzung rendern, sobald sie bereit ist, bis dahin den Fallback-Text.
  return missingInTarget && onDevice ? onDevice : fallbackText
}

Und in einer Komponente liest er sich wie jede andere Übersetzung:

function CheckoutButton () {
  const label = useGovernedT('checkout.pay_now')
  return <button className='btn-primary'>{label}</button>
}

Ein brandneuer checkout.pay_now, der nur auf Englisch existiert, wird: für alle sofort "Pay now" rendern, einen Moment später "Jetzt bezahlen" für eine Besucherin auf Desktop-Chrome oder -Edge zeigen, und sich an Locize melden, sodass innerhalb eines Publish-Zyklus jede Besucherin, auf jedem Browser, jedem Smartphone und jedem Crawler, eine geprüfte, qualitätsbewertete deutsche Übersetzung vom CDN bekommt. Der Fallback heilt sich selbst.

Ehrliche Vorbehalte

• Nur Desktop-Chrome 138+ und Edge 148+. Alle anderen (Firefox, Safari, jedes Smartphone) bekommen den Fallback-Text, was in Ordnung ist, genau das ist der Sinn von Progressive Enhancement. Lassen Sie nichts Wichtiges davon abhängen, dass der geräteinterne Pfad feuert.
• Halten Sie den Write-Key aus dem Client. Das Melden fehlender Keys braucht ein Write-Credential. Führen Sie saveMissing in Development oder Staging aus, oder proxen Sie es über Ihren eigenen Endpoint, statt einen API-Key in ein Production-Bundle auszuliefern. Die geräteinterne Übersetzung selbst braucht keinen Key und ist sicher auszuliefern.
• Es ist ein Notbehelf, nicht die Übersetzung. Die geräteinterne Ausgabe ist ungeprüft, unbewertet und off-Glossar. Sie verschafft Ihnen einen besseren ersten Eindruck, während die governte Übersetzung entsteht. Behandeln Sie sie nie als final.
• Die erste Nutzung lädt ein Modell. Die allererste Übersetzung für ein Sprachpaar löst einen einmaligen Modell-Download aus, sodass die erste Besucherin einer Session den Fallback-Text einen Tick länger sieht. Der monitor-Callback lässt Sie den Fortschritt anzeigen, wenn Sie wollen.

Ein vorausschauender Hinweis, und nur ein Hinweis: Genau diese Verdrahtung von Missing-Key zu Fallback ist die natürliche Naht, an der On-Demand-Übersetzungsfunktionen tendenziell wachsen, also ist es ein nützliches Muster, das man parat hat, unabhängig davon, wo die Browser-APIs landen. Keine Versprechen, nur ein guter Standpunkt.

Wo Locize ins Bild kommt

Der Browser ist ein guter Übersetzer. Er ist kein Ort, um Übersetzungen zu verwalten, und das hat er nie versucht zu sein. Locize ist der governte Kern, in den der Fallback zurückheilt: strukturierte Keys und Namespaces, automatische KI-Übersetzung mit Ihrem Glossar und Styleguide, Quality Estimation bei jeder KI-Übersetzung, ein Review-Workflow und vollständige History für die Übersetzungen, hinter denen Sie stehen, und CDN-Auslieferung, sodass das Ergebnis jeden Browser, jedes Smartphone und jeden Crawler erreicht, nicht nur die Besucher, die zufällig auf Desktop-Chromium sind.

Nutzen Sie den Browser für das, worin er wirklich gut ist, sofortige, kostenlose, private Übersetzung zur Anzeigezeit, und behalten Sie die Governance dort, wo sie hingehört.

Wenn Sie den governten Kern unter diesem Fallback wollen: Erstellen Sie ein kostenloses Locize-Konto, aktivieren Sie automatische Übersetzung und Quality Estimation, und verdrahten Sie saveMissing, um Ihre fehlenden Keys zu melden. Der Browser übersetzt. Ihr TMS governt.