Pipeline konfigurieren

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.

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 Phase außer Localization hat einen eigenen Schalter – und jede Änderung wird sofort gespeichert. Du kannst jede beliebige Kombination aktivieren: keine, alle oder alles dazwischen. Ein Auftrag durchläuft die Phasen in dieser Reihenfolge:

• Vorbearbeitung – bereinigt den Quelltext vor der Übersetzung.
• Localization – der zentrale Übersetzungsschritt. Er ist mit Immer aktiv gekennzeichnet und hat keinen Schalter.
• Umformulierung – formuliert so um, dass es wie von Muttersprachlern klingt. Unabhängig von den anderen Phasen.
• Menschliche Prüfung – leitet an die interne oder externe Prüfung weiter. Über die Einstellungs-Schaltfläche dieses Schritts öffnest du Anbieter, Timeout und Qualitätsschwelle.
• Nachbearbeitung – gleicht menschliche Bearbeitungen mit deinen Engine-Regeln ab. Sie lässt sich erst aktivieren, wenn Menschliche Prüfung aktiviert ist. Wenn du Menschliche Prüfung deaktivierst, wird sie ebenfalls ausgeschaltet.
• Inhaltslänge – hält die Übersetzung innerhalb eines Breitenbudgets, gemessen in Anzeigespalten statt in Zeichen. Über die Einstellungs-Schaltfläche dieses Schritts öffnest du Budget: Unter einem festen Limit bleiben (mit Maximale Länge), Nicht länger als das Original oder Der Originallänge entsprechen (mit Zulässige Abweichung in Prozent).
• Rückübersetzung – stellt sicher, dass die Bedeutung den Hin- und Rückweg überstanden hat. Unabhängig von den anderen Phasen.

Eine Phase, die in deinem Tarif nicht enthalten ist, trägt das Tag Enterprise und lässt sich nicht aktivieren.

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,
    "qualityThreshold": 85
  },
  "postEdit": { "enabled": false },
  "rephrase": { "enabled": false },
  "contentLength": {
    "enabled": true,
    "mode": { "_tag": "fixedCap", "maxColumns": 40 }
  },
  "backTranslation": { "enabled": true }
}

Was die einzelnen Felder steuern – welcher Anbieter für die Prüfung verwendet wird, welche Übersetzungen die Prüfung überspringen und wie lange gewartet wird – ist auf der jeweiligen Phasenseite 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 pipelineConfig``POST /jobs/localization ein -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 genau sie hält Overrides schlank: Eine Phase, die du angibst, wird überschrieben; eine Phase, die du auslässt, übernimmt den Engine-Standard. Die Anfrage oben schaltet rephrase für genau diesen Auftrag ein und backTranslation aus. preEdit, humanEdit, postEdit und contentLength werden nicht angegeben und laufen deshalb exakt so, wie sie in der Engine konfiguriert sind. Du gibst also nur an, was abweicht.

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.
• Die phaseneigenen Laufzeitregeln werden dadurch nicht gelockert. Nachbearbeitung läuft nur, wenn die menschliche Prüfung ein Ergebnis geliefert hat. Wenn du postEdit aktivierst, hat das also bei einem Auftrag ohne menschliche Phase zum Abgleichen keine Wirkung – unabhängig davon, auf welcher Ebene du sie aktiviert hast.

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.