Legen Sie auf zwei Ebenen fest, welche Pipeline-Stufen ausgeführt werden: als Standard auf der Engine und optional als Überschreibung für eine einzelne Anfrage.
Sie haben entschieden, welche Stufen den eigentlichen Übersetzungsschritt flankieren sollen. Jetzt stellen sich zwei Fragen: Wo wird diese Entscheidung festgelegt, und was tun Sie, wenn ein Job etwas anderes braucht als alle übrigen? Die Antwort lautet: zwei Ebenen. Die Engine trägt den Standard, den jeder asynchrone Job übernimmt. Ein pipelineConfig-Objekt bei einer einzelnen Übermittlung überschreibt diesen Standard nur für diese Übermittlung. Stufen, die Sie in der Überschreibung weglassen, werden von der Engine übernommen, sodass eine Anfrage nur die Abweichungen angibt.
Neu bei der Pipeline? Starten Sie mit dem Pipeline-Überblick, um zu verstehen, was jede Stufe macht. Auf dieser Seite geht es darum, sie zu aktivieren und zu überschreiben – nicht darum, was sie nach der Aktivierung tun.
Nur für asynchrone Jobs
Die Pipeline-Konfiguration gilt für Jobs, die über die Async Localization API erstellt werden. Der synchrone /localize-Endpunkt führt nur den eigentlichen Übersetzungsschritt aus und ignoriert Pipeline-Einstellungen vollständig – auf beiden Ebenen.
Standards auf Engine-Ebene#
Öffnen Sie im Dashboard den Tab Pipeline der Engine und schalten Sie jede Stufe unabhängig voneinander ein oder aus. Diese Konfiguration ist der Standard für die Engine: Jeder asynchrone Job, der dorthin geroutet wird, läuft mit diesen Stufen, sofern eine Anfrage sie nicht überschreibt. Einmal festlegen – und Sie müssen die Pipeline nicht bei jedem Aufruf erneut angeben.
Jede Stufe hat ihren eigenen Schalter. Sie können jede beliebige Kombination aktivieren – keine, alle oder alles dazwischen:
- KI-Bearbeitung vor der Lokalisierung – bereinigt den Ausgangstext vor der Übersetzung.
- Menschliche Prüfung nach der Lokalisierung – leitet an eine interne oder externe Prüfung weiter. Modus, Stufe und Timeout wählen Sie im selben Bereich aus.
- KI-Bewertung nach der Lokalisierung – bleibt deaktiviert, bis die menschliche Prüfung aktiviert ist; sie gleicht die menschliche Bearbeitung mit Ihren Engine-Regeln ab.
- Für natürlich klingende Texte umformulieren – formuliert so um, dass der Text wie von Muttersprachlern klingt. Unabhängig von den anderen Stufen.
- Rückübersetzungsprüfung – prüft, ob die Bedeutung den Hin- und Rückweg unbeschadet überstanden hat. Unabhängig von den anderen Stufen.
Kernlokalisierung ist kein Schalter – sie läuft immer. Die anderen Stufen liegen darum herum.
Der Standard ist das, was jeder Job übernimmt. Die Engine-Konfiguration ist also die Struktur, in die eine pipelineConfig-Überschreibung eingefügt wird. Jede Stufe ist ein eigener Schlüssel:
{
"preEdit": { "enabled": true },
"humanEdit": {
"enabled": true,
"provider": "internal",
"tier": "standard",
"timeoutHours": 48
},
"postEdit": { "enabled": false },
"rephrase": { "enabled": false },
"backTranslation": { "enabled": true }
}| Schlüssel | Felder | Auf der Stufenseite festgelegt |
|---|---|---|
preEdit | enabled | KI-Bearbeitung vor der Lokalisierung |
humanEdit | enabled, provider (internal | gengo), tier (standard | pro), timeoutHours | Menschliche Prüfung |
postEdit | enabled | KI-Bewertung |
rephrase | enabled | Für natürlich klingende Texte umformulieren |
backTranslation | enabled | Rückübersetzungsprüfung |
Was jedes Feld steuert – welcher Prüfungsanbieter, welche Stufe, wie lange gewartet wird – ist auf der jeweiligen Stufenseite dokumentiert. Auf dieser Seite geht es darum, wo die Konfiguration liegt und wie die beiden Ebenen zusammenspielen.
Überschreibung pro Anfrage#
Die meisten Jobs sollten mit dem Standard der Engine laufen. Die Ausnahme ist eine einzelne Übermittlung, die eine andere Pipeline braucht – etwa ein einmaliges Paket Marketingtexte, das die Umformulierungsstufe nutzen soll, die Ihre Engine normalerweise deaktiviert lässt, oder eine juristische Nutzlast, die sie überspringen sollte. Die Engine für einen einzelnen Batch anzupassen, würde auch alle anderen Jobs verändern.
Stattdessen übergeben Sie die Abweichung direkt in der Anfrage. Fügen Sie dem Body von POST /jobs/localization ein pipelineConfig-Objekt hinzu, und es überschreibt den Standard der Engine nur für diese Übermittlung. An der Engine selbst ändert sich nichts; der nächste Job ohne Überschreibung läuft wieder mit dem Standard.
{
"sourceLocale": "en",
"targetLocales": ["de", "fr"],
"data": { "headline": "Ship in every language." },
"pipelineConfig": {
"rephrase": { "enabled": true },
"backTranslation": { "enabled": false }
}
}Das ist die Vererbungsregel – und sie sorgt dafür, dass die Überschreibung schlank bleibt: Eine Stufe, die Sie angeben, wird überschrieben; eine Stufe, die Sie auslassen, übernimmt den Standard der Engine. Die obige Anfrage schaltet rephrase für diesen einen Job ein und backTranslation aus. preEdit, humanEdit und postEdit werden nicht genannt und laufen deshalb genau so, wie die Engine sie konfiguriert hat. Sie geben nur an, was abweicht.
Wenn Sie eine Stufe angeben, müssen Sie sie vollständig angeben
Die Überschreibung gilt pro Stufe, nicht pro Feld. Jede Stufe, die Sie einschließen, muss das vollständige Objekt für diese Stufe sein – Sie können nicht humanEdit: { "tier": "pro" } senden, um nur die Stufe zu ändern und den Rest zu übernehmen. Geben Sie die komplette Stufe an, um sie zu überschreiben, oder lassen Sie sie weg, um den Standard der Engine zu übernehmen. Es gibt keine partielle Zusammenführung innerhalb eines einzelnen Stufenobjekts.
Noch zwei Dinge, die die Überschreibung nicht tut – klar gesagt, weil das der Teil ist, der so wirkt, als könnte er alles:
- Sie ändert nur diese Übermittlung. Sie schreibt nichts in die Engine zurück und ist daher nicht der Weg zu einer dauerhaften Konfigurationsänderung – dafür ist der Tab „Pipeline“ da. Nutzen Sie die Überschreibung für den Einzelfall; nutzen Sie den Tab für den neuen Standard.
- Sie lockert nicht die eigenen Laufzeitregeln einer Stufe. KI-Bewertung nach der Lokalisierung läuft nur, wenn die menschliche Prüfung ein Ergebnis geliefert hat; das Aktivieren von
postEditbewirkt also nichts bei einem Job ohne menschliche Stufe, mit der etwas abgeglichen werden könnte – unabhängig davon, auf welcher Ebene Sie sie aktiviert haben.
Prüfen, was ausgeführt wurde#
Die Konfiguration legt fest, welche Stufen ausgeführt werden sollen; der Job-Datensatz selbst zeigt Ihnen, welche tatsächlich gelaufen sind. Der Job enthält ein steps[]-Array, und über dieses Array prüfen Sie, dass eine Überschreibung pro Anfrage tatsächlich wirksam wurde – nicht nur, dass Sie sie gesendet haben.
Wie Sie diese Datensätze lesen – das stepId für jede Stufe, was ein skipped-Schritt bedeutet und wo unkritische Fehler auftauchen – wird auf einer eigenen Seite behandelt.
Nächste Schritte#
Sie können den Standard auf der Engine festlegen und ihn in einer Anfrage überschreiben. Als Nächstes können Sie einen Job mit Überschreibung übermitteln oder die Schritte auslesen, um zu prüfen, welche Stufen ausgeführt wurden.
