Brauchen Sie noch ein TMS, wenn Ihr Coding-Agent die App übersetzt?

Eine Übersetzungsroutine ist ein Coding-Agent-Job, der nach Zeitplan oder in der CI läuft: Er findet die geänderten Strings, entwirft sie in jeder Zielsprache, schreibt die Sprachdateien und öffnet einen Pull Request. Mit Claude Code, Codex oder einem anderen Coding-Agenten braucht es dafür eine Skill-Datei und eine Cron-Zeile, und manche Teams bauen eine solche Routine, um ihr Translation-Management-System abzulösen.

Die Frage ist also berechtigt: Brauchen Sie noch ein TMS? Für manche Teams nicht. Für die meisten lautet die Antwort nicht "das TMS statt der Routine", sondern "die Routine auf einem TMS". Dieser Beitrag zeigt, wann die Routine genügt, was sie nachbauen muss, sobald sie nicht mehr genügt, und drei Wege, sie zu behalten.

So sieht die Routine aus

Eine Routine hat meist drei Teile:

• Eine Skill- oder Anweisungsdatei mit den Regeln: Platzhalter beibehalten, jede Pluralform ergänzen, die die Sprache braucht, den Ton treffen, die Quellsprache nie anfassen.
• Ein Auslöser: ein Cron-Zeitplan, ein Merge in den Hauptbranch oder ein Label an einem Pull Request.
• Der Lauf: Der Agent vergleicht die Datei der Quellsprache mit den Zieldateien, entwirft die fehlenden Werte, schreibt sie und öffnet einen Pull Request.

Die Stärken der Routine sind real. Der Agent, der das deutsche Label eines Buttons entwirft, weiss, dass es ein Button ist, dass {{count}} eine Zahl ist und kein Name, was die Nachbar-Strings sagen und wie viel Platz das Layout lässt. Es gibt keinen Export, keine Übergabe und kein Warten auf eine Übersetzungsrunde, und Features, die früher nur auf Englisch erschienen, erscheinen jetzt in jeder Sprache des Projekts.

Wann die Routine allein genügt

Behalten Sie sie, wie sie ist, ohne TMS, solange all das zutrifft:

• das Team liest jede Zielsprache, oder es sind so wenige, dass man sie von Hand prüfen kann;
• nichts hängt am Text: kein Checkout-Ablauf, kein Rechtstext, keine regulierten Inhalte;
• ein Team verantwortet das Produkt, und niemand ausserhalb des Repositorys muss einen String ändern.

Das trifft auf viele Projekte zu. Wenn es auf Ihres zutrifft, ist der Rest dieses Beitrags die Liste dessen, worauf Sie achten sollten.

Was sie danach nachbauen muss

Jeder Lauf einer Routine ist zustandslos: Sie kennt, was heute im Repository steht und was ihr Prompt sagt. Die Lücken zeigen sich nicht in einem Pull Request, sondern über Releases hinweg. Warum jede davon driftet, steht in Wenn Coding-Agents Ihre App übersetzen; hier ist die Bauliste.

Keiner dieser Punkte ist für sich schwer. Zusammen sind sie ein Translation-Management-System, geschrieben und gewartet von dem Team, das eigentlich keines mehr betreiben wollte.

Drei Wege, die Routine zu behalten

Die Alternative zum Nachbauen: die Routine behalten und sie in ein System schreiben lassen, das diese Teile schon hat. In Locize gibt es drei Setups, von der kleinsten Änderung bis zum meisten Kontext, und alle drei laufen unbeaufsichtigt in der CI.

Welches passt:

Die Routine bezahlt weiterhin ihre eigenen Modell-Tokens; Übersetzungen, die Locize entwirft, laufen über KI-Tokens von Locize oder Ihren eigenen Anbieter-Key (Preise).

Alle drei enden am selben Ort: in einer Review-Warteschlange pro Sprache, in der jeder Entwurf wartet, bis jemand, der die Sprache liest, ihn bestätigt.

Der Needs-Review-Filter im Locize-Editor: zum Review markierte Entwürfe pro Sprache und ein offener Vorschlag mit Annehmen und Ablehnen

Was das abfängt, aus einem echten Lauf mit Setup 2: Ein Agent meldete 11 englische Keys, und die automatische Übersetzung von Locize lieferte in etwa elf Sekunden 69 Werte in sechs Sprachen zurück, jeden mit einem Konfidenzwert und einer Begründung, und mit den Pluralformen, die jede Sprache braucht (drei im Französischen, eine im Japanischen), wo das Englische zwei hat. Die Konfidenzwerte zeigten auf die wörtliche Übersetzung von "Wake up" im Deutschen, Spanischen und Japanischen. Und das Deutsche verwendete zwei Begriffe für dieselbe Aktion, was ein Konfidenzwert pro String nicht sehen kann, ein Reviewer dieser Sprache aber schon. Entwürfe, die Ihre Routine in den Setups 1 und 3 selbst schickt, kommen ohne Konfidenzwert an; ein KI-Review-Lauf bewertet sie.

1. Einen Sync-Schritt hinzufügen

Lassen Sie die Routine, wie sie ist. Nachdem sie die Dateien geschrieben hat, schicken Sie die neuen Zielwerte an Locize, zum Review markiert:

locize sync --api-key $LOCIZE_API_KEY --project-id $LOCIZE_PROJECTID \
  --reference-language-only false --needs-review true \
  --skip-delete true --auto-translate false

• --reference-language-only false vergleicht auch die Zielsprachen, sodass die Entwürfe der Routine geschickt werden.
• --needs-review true markiert jeden Wert, den der Sync schickt: Er geht live und bleibt in der Warteschlange der Reviewer, bis jemand ihn bestätigt (locize-cli 12.8.0 oder neuer). Mit --review true stattdessen kommen die Werte als Review-Vorschläge an und gehen erst live, wenn sie angenommen werden.
• --auto-translate false hält Locize davon ab, die neuen Quell-Keys selbst zu übersetzen, damit es nicht mit den Entwürfen der Routine um die Wette läuft.
• --skip-delete true verhindert, dass ein Wert gelöscht wird, den jemand in Locize hinzugefügt hat und den die Dateien noch nicht haben (Keys, die aus der Quelle entfernt wurden, bleiben dann in Locize, bis Sie sie dort entfernen).

Die Korrektur eines Reviewers macht der nächste Lauf nicht rückgängig: Locize behält den Wert, den es für einen bestehenden Key hat, und der Sync schreibt ihn zurück in die Dateien. Eines sollten Sie vor dem ersten Lauf einrichten: Wenn Ihr Team englische Texte im Repository bearbeitet, führen Sie vor der Routine locize sync --update-values true aus, sonst schreibt der Sync das Englische aus Locize über sie zurück. Der Sync vergleicht mit den veröffentlichten Dateien, nutzen Sie also eine Version mit Auto-Publish; der Rest steht in der Sync-Referenz der locize-cli.

Probieren Sie es beim nächsten Lauf der Routine aus: Starten Sie eine kostenlose 14-tägige Testphase, legen Sie ein Projekt mit Ihren Sprachen an, speichern Sie dessen API-Key als CI-Secret, fügen Sie den Befehl nach der Routine ein und öffnen Sie nach dem Lauf den Needs-Review-Filter im Editor. Der erste Sync schickt jeden Zielwert, den die Routine bisher geschrieben hat, die Warteschlange zeigt also, was die früheren Läufe ohne zweiten Blick ausgeliefert haben. Sie nutzen Locize schon? Nehmen Sie den API-Key Ihres Projekts und fügen Sie den Schritt hinzu; sonst ändert sich nichts.

Die Grenze: Die Werte kommen zum Review markiert an, sehen aber in der Historie und im Provenance-Export aus wie jeder andere Wert, der mit dem API-Key geschickt wurde. Für das Review genügt das, aber nicht, wenn die Aufzeichnung den Text eines Agenten von dem einer Person unterscheiden muss; das leistet Setup 3.

2. Locize entwerfen lassen

Die Routine schreibt weiter das Feature und den Quelltext, und der Übersetzungsschritt wandert zu Locize. Die Locize GitHub Action extrahiert die neuen Keys, synchronisiert sie, lässt sie übersetzen und lädt das Ergebnis herunter, mit demselben Projekt-API-Key:

- uses: locize/translate@v2
  with:
    project-id: ${{ secrets.LOCIZE_PROJECTID }}
    api-key: ${{ secrets.LOCIZE_API_KEY }}

• Die automatische Übersetzung nutzt Styleguide, Glossar und Translation Memory des Projekts als Kontext und prüft jedes Ergebnis vor dem Speichern gegen seine Quelle (Syntax, Platzhalter, Tags, die Pluralformen, die die Sprache braucht); KI-Ergebnisse müssen zusätzlich dem Glossar entsprechen.
• Mit Quality Estimation erhält jede KI-Übersetzung einen Konfidenzwert, und die Review-Einstellungen entscheiden, ob alle maschinellen Übersetzungen zum Review markiert werden oder nur jene, denen der Konfidenzwert nicht traut.
• In einem Pull Request übersetzt command: sync nur die Keys, die der Pull Request geändert hat.

Die Action erwartet eine i18next.config-Datei (einmal npx i18next-cli init ausführen). Ausserhalb von i18next erledigt locize sync --auto-translate true dasselbe mit der CLI. Dieses Setup passt, wenn ein Kontextsatz pro Key genügt, und es überlässt dem Agenten den Teil, den er am besten kann.

3. Die Routine zuerst das Projekt lesen lassen

Wenn ein String braucht, was nur der Code zeigt, lassen Sie den Agenten weiter entwerfen, aber über den Locize-MCP-Server statt in Dateien. Der Lauf liest, bevor er schreibt:

1. find_missing_translations pro Sprache: was fehlt oder veraltet ist.
2. get_glossary, get_styleguide und search_translation_memory: die Begriffe, die Tonalität und die früheren Entscheidungen; get_screenshot_context für einen mehrdeutigen Key.
3. Der Agent entwirft, mit dem Code im Blick.
4. update_translations mit quality: "AI": Die Entwürfe werden als KI-Output deklariert und gemäss der Projektregel zum Review markiert.

Nach Zeitplan in GitHub Actions, mit Claude Code:

name: nightly translations
on:
  schedule:
    - cron: '0 3 * * 1-5'
  workflow_dispatch:

permissions:
  contents: read

jobs:
  translate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: npm install -g @anthropic-ai/claude-code@2.1.317
      - run: |
          claude mcp add --transport http locize https://mcp.locize.app --header "Authorization: Bearer $LOCIZE_PAT"
        env:
          LOCIZE_PAT: ${{ secrets.LOCIZE_PAT }}
      - run: >
          claude -p "Translate the missing keys of the Locize project $LOCIZE_PROJECTID, version latest.
          Call get_project_stats for version latest to see its languages and namespaces (if it answers with totals only, call it again per language),
          then call find_missing_translations per language and namespace.
          Before drafting call get_glossary, get_styleguide and search_translation_memory, and reuse a translation memory match with a high score.
          Read the namespace's existing translations with get_translations to match their tone. Look up where each key is used in the code to see what it labels.
          Push the drafts with update_translations and quality AI. Never send a null value, never publish, delete or rename anything.
          End with a list of what you pushed and what you were unsure about."
          --disallowedTools "Bash,Edit,Write,WebFetch,WebSearch,Read(~/.claude.json),Read(~/.claude/**)"
          --allowedTools "mcp__locize__get_project_stats,mcp__locize__find_missing_translations,mcp__locize__get_translations,mcp__locize__get_glossary,mcp__locize__get_styleguide,mcp__locize__search_translation_memory,mcp__locize__get_screenshot_context,mcp__locize__update_translations,Read,Grep,Glob"
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          LOCIZE_PROJECTID: ${{ vars.LOCIZE_PROJECTID }}

• Der Token: Erstellen Sie einen Personal Access Token nur mit den Scopes read und write, setzen Sie ein Ablaufdatum und speichern Sie ihn als Repository-Secret. Ein Token erreicht jedes Projekt, das sein Besitzer erreicht, lassen Sie ihn also einem Nutzer gehören, der nur Mitglied dieses Projekts ist. Benennen Sie ihn nach der Routine, zum Beispiel "Nächtliche Übersetzungsroutine": Jeder Schreibvorgang über MCP trägt die Markierung des Agenten mit dem Namen des Tokens, die Historie nennt also den Agenten, und der Provenance-Export führt die Entwürfe als maschinelle Ausgabe mit dem Namen des Agenten, nicht als Bearbeitung einer Person.
• Was die Routine darf: Die Tool-Liste lässt die strukturellen Tools weg (Namespaces löschen oder umbenennen, veröffentlichen, Branches). update_translations kann einen Key trotzdem löschen, wenn ihm ein null-Wert geschickt wird, und nur der Prompt verbietet das; hat der Besitzer des Tokens die Berechtigung translate-only, lehnt der Server selbst das Löschen von Keys und strukturelle Änderungen ab.
• Was die Routine liest: Der Agent liest Text, den andere geschrieben haben (Übersetzungen, das Glossar, Key-Kontexte). Der Workflow verweigert ihm ausdrücklich die Shell, Dateibearbeitungen und das Web, weil --allowedTools nur ergänzt, was die Claude-Einstellungen bereits erlauben, auch eine .claude/settings.json im ausgecheckten Repository. Er verweigert ihm auch das Lesen seiner eigenen Konfiguration (wo claude mcp add den Token speichert), und seine Entwürfe gehen ins Review.
• Drumherum: Die Quell-Keys erreichen Locize weiterhin wie bisher (saveMissing, locize sync oder report_missing_keys), und die App bezieht die geprüften Übersetzungen vom CDN oder über ein locize download im Build. Ist die automatische Übersetzung für das Projekt aktiviert, entwirft Locize die neuen Keys zuerst, und die Routine findet wenig Fehlendes; schalten Sie sie aus, wenn die Routine entwerfen soll.
• Andere Agents: Ein Coding-Agent, der MCP über HTTP spricht, nimmt dieselbe URL und denselben Header in seine MCP-Einstellungen. Die Konventionsdateien in locize-agents bringen die Regel "erst lesen, dann entwerfen" auch in interaktive Sitzungen.

So sieht ein Lauf aus: Auf einem Testprojekt mit drei neuen Keys und Deutsch, Französisch und Russisch als Zielsprachen las die Routine die Statistiken, die fehlenden Keys, das Glossar, den Styleguide und das Translation Memory, schlug jeden Key im Code nach und schickte neun Entwürfe als KI-Output, für weniger als einen Dollar an Modell-Tokens. Am Ende stand, wobei sie unsicher war: Sie hatte "Wake up" sinngemäss als "reaktivieren" oder "fortsetzen" wiedergegeben, nicht wörtlich, wodurch die Snooze-Metapher verloren geht. Alle neun Entwürfe lagen in der Review-Warteschlange, und die Historie nannte bei jedem den Token als Agenten.

Einen kompletten interaktiven Lauf mit dem echten Output (die Konfidenzwerte, was sie übersehen haben, das Review und der Export) zeigt Ein Coding-Agent lokalisiert ein Feature, Schritt für Schritt.

Wenn Sie die Texte freigeben

Die Routine ist ein Werkzeug für Entwickler; die Frage "Wer hat diesen Text freigegeben?" landet meist bei jemand anderem: bei der Lokalisierungsverantwortlichen, beim Product Owner oder bei der Person, die der Rechtsabteilung oder dem Einkauf eines Kunden antwortet. In allen drei Setups bekommt sie Folgendes:

• Reviewer pro Sprache. Ein Reviewer kann auf seine Sprachen beschränkt werden, und mit der Berechtigung translate-only lassen sich Werte bearbeiten, ohne Keys zu löschen oder die Struktur des Projekts zu ändern (Rollen und Berechtigungen).
• Eine Warteschlange, egal, was den Entwurf geschrieben hat. Werte aus der Routine, aus der automatischen Übersetzung und von Personen landen in derselben Review-Warteschlange pro Sprache (Review-Workflow); in einem Plan mit Benachrichtigungen kann eine verschickt werden, wenn die Warteschlange einer Sprache einen Schwellenwert überschreitet.
• Eine Aufzeichnung pro String. Die Historie hält fest, wer oder was jeden Wert geschrieben hat und wer ihn bestätigt hat, und wann.
• Nachweise auf Anfrage. Der Provenance-Export (CSV und JSON pro Version, Sprache oder Namespace, ab dem Growth-Plan wie die Review-Vorschläge) verpackt den Review-Status für einen Auditor. Der Leitfaden zum Artikel-50-Workflow zeigt das Setup, und unser Erklärstück behandelt, wann Artikel 50 gilt.
• Ein zweiter Blick, auf Abruf. Ein KI-Review-Lauf über eine Version bewertet die Übersetzungen, die ein Projekt bereits hat, egal wer sie geschrieben hat, und markiert die zweifelhaften zum Review oder macht daraus Review-Vorschläge mit Begründung und Korrekturvorschlag. Ein Agent kann einen solchen Lauf mit start_ai_review und einer Budgetobergrenze starten, mit einem Token mit dem Scope manage und einer Admin- oder Manager-Rolle.

Ihr Schritt: Richten Sie das Review pro Sprache ein, wie es der Leitfaden zum Artikel-50-Workflow beschreibt, lassen Sie die Routine einmal laufen, laden Sie dann den Provenance-Export dieser Version herunter und prüfen Sie ihn gegen das, was Ihr Auditor oder Ihr Kunde verlangt. Die 14-tägige Testphase eines Projekts enthält Review und Export; danach gibt es beides ab dem Growth-Plan.

Signale, dass die Routine ein System darunter braucht

• die erste Sprache, die niemand im Team liest;
• die erste Beschwerde über Terminologie, von einem Kunden, aus dem Vertrieb oder vom Support;
• das erste "Wer hat diesen String geändert, und warum?";
• die erste Korrektur, die Nutzer vor dem nächsten Release erreichen muss;
• die erste Frage der Rechtsabteilung oder des Einkaufs eines Kunden zu KI-generiertem Text.

Der Agent entwirft weiter; dieser Teil war nie das Problem. Was er darunter braucht, ist ein Gedächtnis, ein Reviewer und eine Aufzeichnung. Wenn Ihre Routine schon läuft, starten Sie eine kostenlose 14-tägige Testphase, geben Sie der Routine einen Projekt-API-Key, fügen Sie den Sync-Befehl hinzu und schauen Sie sich nach dem ersten Lauf die Review-Warteschlange an. Sie nutzen Locize schon? Dann braucht die Routine nur den API-Key Ihres Projekts.