Die meisten Ihrer Inhalte können live gehen, sobald die Engine sie zurückliefert. Manche aber nicht. Regulatorische Hinweise, medizinische Anweisungen oder eine Headline, die Ihre Marke trägt – hier soll ein Mensch die Übersetzung lesen und freigeben, bevor sie veröffentlicht wird, nicht erst nachdem sich ein Kunde beschwert hat.
Einen Menschen in einen automatisierten Ablauf einzubinden, ist sonst meist mühsam: die Anfrage offen halten, während jemand liest, eine eigene Prüfungswarteschlange bauen oder die API eines Übersetzungsdienstleisters manuell verdrahten. Diese Stufe erledigt das direkt im Job. Wenn humanEdit aktiviert ist, führt der asynchrone Job die Engine aus und pausiert dann für einen Menschen – Ihr eigenes Team oder ein externer Profi – und setzt den Lauf mit dessen Bearbeitung fort. Dieses Ergebnis wird anschließend an alle folgenden Stufen weitergereicht.
Sie ist die dritte Stufe der Lokalisierungs-Pipeline und gilt wie jede Stufe nur für Jobs, die über die asynchrone Lokalisierungs-API erstellt wurden. Neu bei der Pipeline? Starten Sie mit dem Überblick.
Auf dieser Seite
So funktioniert die Pause#
Nach dem eigentlichen Übersetzungsschritt übergibt der Job die KI-Übersetzung an einen Menschen zur Prüfung. Der Prüfer liest sie und gibt sie entweder unverändert frei oder reicht eine bearbeitete Version ein. Erst dann läuft der Job weiter. Das menschliche Ergebnis – freigegeben oder bearbeitet – wird zur Eingabe für alle nachfolgenden Stufen und am Ende zum outputData des Jobs.
Der naheliegende Einwand gegen das Pausieren eines Jobs für Minuten, Stunden oder einen ganzen Tag ist der Kostenfaktor: Eine offen gehaltene Anfrage bindet Ressourcen, obwohl nichts passiert. Genau so funktioniert diese Stufe nicht.
Die Wartezeit ist ereignisgesteuert, keine offen gehaltene Verbindung
Der Workflow wird durch ein Ereignis fortgesetzt – etwa wenn ein Prüfer im Dashboard etwas einreicht (Interne Prüfung) oder wenn ein Callback des Übersetzungsanbieters eingeht (Externe Prüfung). Es wird nicht in einer engen Schleife gepollt und auch keine Verbindung offen gehalten. Deshalb verbraucht ein langes Timeout im Hintergrund keine Rechenleistung. Ein Job kann 48 Stunden auf einen Menschen warten, genauso wie auf ein Modell: Er ist geparkt, nicht dauerhaft aktiv.
Es gibt zwei Prüfungsmodi, die pro Engine ausgewählt werden. Sie unterscheiden sich nur darin, wer die Übersetzung liest – Pause, Fortsetzung und Weitergabe des Ergebnisses verhalten sich identisch.
Interne Prüfung#
Ihr eigenes Team prüft Übersetzungen direkt im Lingo.dev-Dashboard. Ausstehende Prüfungen landen auf der Seite Human Reviewer Ihrer Organisation (/orgs/<org-id>/human-reviewer), und Prüfer werden benachrichtigt, sobald neue Elemente eintreffen. Ein Prüfer übernimmt ein Element und gibt die Übersetzung dann entweder unverändert frei oder reicht eine bearbeitete Version ein. Der Job wird sofort mit diesem Ergebnis fortgesetzt.
Ein zweiter Prüfer kann kein Element übernehmen, an dem bereits jemand arbeitet. Übernahmen sind exklusiv – immer nur ein Prüfer bearbeitet ein Element gleichzeitig, sodass nie zwei Personen dieselbe Übersetzung bearbeiten und sich unbemerkt gegenseitig überschreiben. Die Zeichenkette bleibt für die Person gesperrt, die sie übernommen hat, bis sie sie freigibt oder einreicht.
Interne Prüfung ist der Standardmodus für neue Engines. Nutzen Sie ihn, wenn Ihr Team die sprachliche Expertise im Haus hat und Sie die volle Kontrolle über die finale Formulierung behalten möchten – ganz ohne Dritte im Prozess.
Berechtigungen#
Die interne Prüfung steht nicht allen in der Organisation offen – die Seite Human Reviewer ist durch Berechtigungen geschützt, sodass eine Übersetzung in Prüfung nur für die Personen sichtbar ist, denen Sie Zugriff gewähren. Ein Organisationsadministrator vergibt diesen Zugriff über Rollen (Einstellungen → Rollen):
| Berechtigung | Was sie freischaltet |
|---|---|
Übersetzungen prüfen (engine:review_translations) | Die Prüfungswarteschlange sehen und bearbeiten – eine ausstehende Übersetzung übernehmen, bearbeiten, unverändert freigeben oder die bearbeitete Version einreichen |
Prüfungen verwalten (org:manage_reviews) | Prüfungsverlauf und Prüferstatistiken für alle internen Prüfungen in der gesamten Organisation |
Die beiden Berechtigungen sind bewusst getrennt. Ein Prüfer braucht nur Übersetzungen prüfen – diese eine Berechtigung deckt den gesamten Ablauf ab: übernehmen, bearbeiten, freigeben, einreichen. Prüfungen verwalten ist für diejenigen gedacht, die den Prozess steuern; sie ergänzt den organisationsweiten Blick auf Verlauf und Statistiken, umfasst aber nicht automatisch den Zugriff auf die Warteschlange. Weisen Sie beide Berechtigungen einer leitenden Person zu, die prüft und reportet; vergeben Sie nur die erste an jemanden, der ausschließlich in der Warteschlange arbeitet.
Externe Prüfung#
Wenn Sie für eine Sprache keine internen Prüfer haben, wird die Übersetzung stattdessen über einen externen Anbieter an einen qualifizierten professionellen Übersetzer übergeben. Der Job pausiert auf dieselbe Weise und wird fortgesetzt, sobald der Anbieter die bearbeitete Übersetzung zurückliefert. An Ihrem Code ändert sich nichts – der Unterschied liegt nur darin, wer die Zeichenkette liest, nicht darin, wie sich der Job verhält.
Die externe Prüfung gibt es in zwei Stufen. Der Unterschied richtet sich danach, wie hoch die Anforderungen an die Genauigkeit des Inhalts sind:
| Stufe | Am besten geeignet für |
|---|---|
| Standard | Präzise Übersetzung mit menschlicher Stimme – Marketingtexte, UI-Zeichenketten, Hilfsinhalte |
| Pro | Professionelle Nutzung mit nochmals höherem Anspruch an Genauigkeit – rechtliche, medizinische und regulierte Inhalte |
Das sollte man ganz offen sagen: Externe Prüfung bedeutet, dass auf der anderen Seite ein echter menschlicher Übersetzer sitzt – mit der entsprechenden Bearbeitungszeit und den entsprechenden Kosten. Es ist nicht einfach ein schnelleres Modell. Nutzen Sie sie dort, wo menschliches Urteilsvermögen entscheidend ist – bei regulierten Texten oder besonders sensiblen Inhalten – und setzen Sie für den Großteil Ihrer Inhalte, die das nicht brauchen, auf den reinen KI-Pfad.
Timeout#
Eine menschliche Stufe bringt ein Risiko mit sich, das KI-Stufen nicht haben: Der Mensch antwortet möglicherweise nie. Ein Prüfer ist im Urlaub, der Anbieter überlastet oder das Element wird schlicht vergessen. Ohne Begrenzung würde der Job endlos warten.
Deshalb ist die Wartezeit begrenzt. Sie legen fest, wie lange der Workflow auf das menschliche Ergebnis wartet – dieselbe Einstellung timeoutHours gilt für beide Prüfungsmodi. Läuft das Timeout ohne Antwort ab, wird die Stufe als skipped markiert und der Job läuft mit der KI-Übersetzung als endgültiger Ausgabe weiter. Standardmäßig sind 48 Stunden eingestellt.
Sprechen wir den Preis dafür offen an: Bei einem Timeout veröffentlichen Sie die ungeprüfte KI-Übersetzung. Für die meisten Inhalte ist das der richtige Fallback – eine veröffentlichte Übersetzung ist besser als ein Job, der auf unbestimmte Zeit hängen bleibt –, aber es ist ein echter Trade-off. Für Inhalte, die in jedem Fall die Freigabe durch einen Menschen brauchen, setzen Sie ein großzügiges Timeout und schlagen Sie Alarm, wenn die Stufe übersprungen wird. Für Inhalte, bei denen Prüfung nur ein Plus ist, hält ein kurzes Timeout die Pipeline in Bewegung.
Das Timeout gilt pro Stufe, nicht pro Job
Das Timeout steuert nur, wie lange diese Stufe auf ein menschliches Ergebnis wartet. Es ist unabhängig davon, wie lange der Rest des Jobs dauert. Weil die Wartezeit ereignisgesteuert ist, kostet Sie ein langes Timeout bei einem langsamen Prüfer nur zusätzliche Latenz bis zum Endergebnis – niemals Rechenleistung im Hintergrund.
Die Stufe aktivieren#
humanEdit wird wie jede Pipeline-Stufe konfiguriert: als Standard auf Engine-Ebene im Tab Pipeline der Engine und optional mit einer Überschreibung pro Anfrage. Das vollständige Zwei-Ebenen-Modell finden Sie unter Pipeline konfigurieren; die speziell für diese Stufe relevante Form ist:
{
"humanEdit": {
"enabled": true,
"provider": "internal",
"tier": "standard",
"timeoutHours": 48
}
}provider wählt den Modus – internal für Ihr eigenes Team, andernfalls den externen Anbieter. tier (standard oder pro) gilt für Externe Prüfung und wird für Interne ignoriert. timeoutHours ist die Begrenzung aus dem obigen Abschnitt. Wenn Sie dies für eine einzelne Übermittlung überschreiben möchten, übergeben Sie diesen Block innerhalb von pipelineConfig im create call; lassen Sie ihn weg, übernimmt der Job die Einstellung der Engine.
Wenn die Stufe ausgeführt wird, protokolliert sie sich im Job unter stepId: "humanEdit" mit einem Status von completed, failed oder skipped – derselbe Schrittdatensatz, den jede Stufe erzeugt. Wie Sie diese Datensätze lesen, erfahren Sie unter Pipeline-Ausführungen beobachten.
Eine menschliche Bearbeitung kann von Ihren Engine-Regeln abweichen
Ein menschlicher Übersetzer kann etwas so formulieren, dass es mit Ihrem glossary, Ihrer Markenstimme oder Ihren Anweisungen kollidiert – er übersetzt gut, nicht indem er Ihre Konfiguration auswendig lernt. Um die menschliche Bearbeitung automatisch wieder an die Regeln Ihrer Engine anzugleichen, aktivieren Sie die nächste Stufe: KI-Bewertung. Sie läuft nur nach einer menschlichen Stufe, die tatsächlich ein Ergebnis erzeugt hat.
