Sie haben Ihre Quellen eingereicht und der Job läuft. Die Engine-ID kam im 202 zurück, und ihre Konfiguration füllt sich nun. Diese Seite beantwortet die Frage, von der abhängt, ob Sie dem Ergebnis vertrauen: Was genau füllt sich hier eigentlich?
„Eine KI hat meine Engine konfiguriert“ ist genau der Satz, bei dem Ingenieur:innen skeptisch werden – und diese Skepsis ist berechtigt. Dahinter könnte eine Blackbox stecken, die Sie nicht prüfen können. Es könnte bedeuten, dass Datensätze über Sprachen verstreut sind und sich nicht sauber nachvollziehen lassen. Es könnte auch heißen, dass der Agent eine magere Quelle gelesen, nichts Relevantes gefunden und stillschweigend fast nichts erstellt hat. Deshalb wird diese Seite bei allen drei Punkten konkret: Der Agent erzeugt drei Arten von Konfiguration, jede wird nach einer nachvollziehbaren Regel Ihren Sprachen zugeordnet, und der Job liefert eine Zusammenfassung zurück, die jeden erstellten Datensatz namentlich aufführt. Die Ausgabe besteht aus ganz normalen Datensätzen, die Sie lesen und bearbeiten können – nicht aus einem Urteil, das Sie einfach auf gut Glück akzeptieren müssen.
Neu bei der asynchronen Bereitstellung? Starten Sie mit dem Überblick über die Async Provisioning API, um das Grundmodell zu verstehen, und mit Quelltypen, um zu sehen, was eine Quelle überhaupt einreichenswert macht. Auf dieser Seite geht es darum, was am Ende dabei herauskommt.
Auf dieser Seite
- Die drei Komponenten
- Wie jede einer Sprache zugeordnet wird
- Die Ausgabezusammenfassung
- Eine knappe Zusammenfassung lesen
- Nächste Schritte
Die drei Komponenten#
Der Agent liest alles – gecrawlte Seiten genauso wie Rohinhalte – und erstellt drei Arten von Engine-Konfiguration. Das ist kein neues Format, das nur für die Bereitstellung gilt. Es sind genau dieselben Grundbausteine, die Sie sonst manuell auf einer Engine anlegen würden. Genau deshalb lässt sich alles, was der Agent erstellt, anschließend im Dashboard bearbeiten – genauso wie alles, was Sie selbst angelegt haben.
| Komponente | Wonach gesucht wird | Beispiel |
|---|---|---|
| Markenstimmen | Ton, Stil, Formalitätsgrad, Schreibkonventionen | „Verwenden Sie formelles Deutsch (Sie-Form). Halten Sie Sätze knapp und direkt.“ |
| Glossareinträge | Produktnamen, Fachbegriffe, markenspezifische Übersetzungen, nicht übersetzbare Begriffe | „Acme“ → nicht übersetzbar, „workspace“ → „Arbeitsbereich“ (de) |
| Anweisungen | Formatierungsregeln, kulturelle Konventionen, domänenspezifische Richtlinien | „Datumsangaben in deutschen Übersetzungen immer als TT.MM.JJJJ formatieren.“ |
Diese drei Dinge sorgen dafür, dass eine Übersetzung nach Ihrem Produkt klingt und nicht nach einer beliebigen Standardfassung – die von Ihnen gewählte Formalität, die Namen, die Sie nie übersetzen, das Datumsformat, das Sie immer verwenden. Die Aufgabe des Agenten ist es, solche Entscheidungen überall dort in Ihren Quellen zu finden, wo sie ausdrücklich genannt werden, und sie als Datensätze festzuhalten.
Eine Konsequenz sollte man klar benennen, weil sie die Obergrenze dessen festlegt, was Sie als Ergebnis erwarten können: Der Agent extrahiert, was ausdrücklich gesagt wird, nicht das, was nur implizit mitschwingt. Eine Quelle, die eine Regel klar benennt, führt zu einem Datensatz; eine Quelle, die nur einen guten Ton vormacht, ohne eine Regel zu formulieren, liefert wenig. Das ist eine Eigenschaft der Quellen, nicht der Engine – Quelltypen erklärt, wie Sie Quellen auswählen, die ihre Regeln ausdrücklich benennen.
Wie jede einer Sprache zugeordnet wird#
Die Konfiguration einer Lokalisierungs-Engine ist nach Ziel-Sprachen organisiert. Ein Datensatz beschreibt also nicht nur, was eine Regel ist, sondern auch, wo sie gilt. Der Agent weist jedem Datensatz anhand einer nachvollziehbaren Regel eine Sprache zu, und das Platzhalterzeichen * sollten Sie verstehen, bevor Sie die Ausgabe lesen.
- Markenstimmen und Anweisungen verwenden
*, wenn sie für alle Sprachen gelten. Eine Tonregel wie „Sätze knapp und direkt halten“ ist nicht spezifisch für Deutsch; so schreibt Ihr Produkt in jeder Sprache. Der Agent weist ihr die Ziel-Sprache*zu, und sie gilt für jede Sprache, in die die Engine übersetzt. Eine Regel, die tatsächlich sprachspezifisch ist („Verwenden Sie im Deutschen die Sie-Form“), wird stattdessen dieser Sprache zugewiesen. - Glossareinträge werden pro Sprachpaar erstellt, denn eine Übersetzung erfolgt immer von einer Sprache in eine ganz bestimmte andere – „workspace“ → „Arbeitsbereich“ ist eine Aussage über Deutsch und nur über Deutsch.
- Nicht übersetzbare Begriffe sind die Ausnahme und verwenden
*. Ein Markenname, den Sie nie übersetzen – „Acme“ – ist in jeder Sprache nicht übersetzbar und wird deshalb einmal unter*gespeichert, statt für jedes Sprachpaar neu eingetragen zu werden.
Wenn Sie also in einem vom Job erstellten Datensatz * sehen, ist das weder ein Platzhalter noch eine Lücke. Es bedeutet: „Das gilt überall“ – eine globale Tonregel, eine globale Anweisung oder ein Begriff, der in keiner Sprache übersetzt wird. Ein konkreter Sprachcode bedeutet das Gegenteil: Diese Regel gilt nur für genau diese Sprache.
Warum der Platzhalter ein Feature ist – und kein Standard, den man überschreiben sollte
Eine skeptische Lesart von * wäre: „Der Agent hat sich nicht die Mühe gemacht herauszufinden, zu welcher Sprache das gehört.“ Tatsächlich ist das Gegenteil der Fall. Eine Markenstimme oder ein nicht übersetzbarer Begriff, der in jeder Sprache korrekt ist, sollte global sein – würde man ihn an eine einzelne Sprache binden, würde er für alle anderen stillschweigend nicht greifen. Der Platzhalter ist die Art, wie die Konfiguration sagt: „Das gilt unabhängig von der Sprache“ – und genau das trifft auf eine Tonregel oder einen Markennamen meistens zu.
Die Ausgabezusammenfassung#
Wenn der Job abgeschlossen ist, liefert er eine Zusammenfassung zurück, die alles aufführt, was der Agent erstellt hat. Das ist die Quittung: jeder Datensatz, gezählt und identifiziert, plus eine Liste mit allem, was fehlgeschlagen ist.
{
"brandVoices": {
"count": 3,
"ids": ["bv_A1b2C3d4", "bv_B2c3D4e5", "bv_C3d4E5f6"]
},
"glossaryItems": {
"count": 12,
"ids": ["gi_A1b2C3d4", "gi_B2c3D4e5", "..."]
},
"instructions": {
"count": 5,
"ids": ["ins_A1b2C3d4", "ins_B2c3D4e5", "..."]
},
"errors": []
}Jede Komponente meldet ein count und die ids der erstellten Datensätze – bv_ für Markenstimmen, gi_ für Glossareinträge, ins_ für Anweisungen. Das sind keine vagen Bestätigungen, sondern die IDs echter Datensätze auf der Engine. Sie können jede gi_ aus dieser Liste nehmen, im Dashboard öffnen und genau nachlesen oder ändern, was der Agent extrahiert hat. Die Zusammenfassung macht aus „Die KI hat irgendetwas gemacht“ ein „Hier sind die zwanzig konkreten Dinge, die sie gemacht hat“ – und genau das ist der Unterschied zwischen einer Blackbox und ganz normalen Datensätzen, die Sie lesen und bearbeiten können.
Die Zusammenfassung erreicht Sie über den Kanal, den Sie beim Erstellen des Jobs eingerichtet haben: in der Payload des webhook, die Ihre Callback-URL bei Abschluss erhält, wo sie als Feld summary ankommt. Wenn Sie den Job über das WebSocket beobachten, ist das ein Live-Feed – er streamt den Fortschritt beim Crawlen und Konfigurieren, nicht dieses Zusammenfassungsobjekt. Die Zusammenfassung kommt mit dem Abschluss-Webhook; das WebSocket sagt Ihnen nur, wann Sie sie abrufen können.
Ein fehlgeschlagenes Element lässt nicht den ganzen Job scheitern.
Wenn ein einzelner Datensatz nicht erstellt werden kann, reißt das nicht den Rest mit. Der Fehler wird im Array errors vermerkt, die erfolgreich erstellten Datensätze werden trotzdem auf die Engine angewendet, und der Job wird dennoch abgeschlossen. Sie erhalten eine teilweise konfigurierte Engine plus eine präzise Liste dessen, was Sie noch einmal prüfen sollten – nicht eine leere Engine und einen Stacktrace. Der Job schlägt als Ganzes fehl, wenn der Lauf nichts Verwertbares liefert – zum Beispiel, wenn alle Quellen beim Crawlen scheitern; dieser Fehlerfall und seine Payload provisioning.failed sind unter Webhook delivery beschrieben.
Eine knappe Zusammenfassung lesen#
Die Zusammenfassung zeigt Ihnen nicht nur, was erstellt wurde, sondern anhand ihrer Zählwerte auch, ob sich der Lauf gelohnt hat. Ein count von 0 für eine Komponente ist kein Fehler – die Zusammenfassung ist korrekt aufgebaut und die Engine existiert –, aber es ist ein klares Signal. Drei Markenstimmen und zwölf Glossareinträge ergeben eine konfigurierte Engine. Überall null und ein leeres Array errors bedeuten dagegen eine Engine, die fast leer zurückkam – und der Agent sagt Ihnen damit, dass er nur wenige Regeln zum Extrahieren gefunden hat.
Wenn das passiert, liegt die Ursache fast immer weiter vorn im Prozess: Die Quellen haben nur wenige konkrete Regeln formuliert, die der Agent übernehmen konnte. In der Zusammenfassung sehen Sie das; in Quelltypen beheben Sie es. Die ehrliche Erwartung für den ersten Lauf lautet: Die Quittung spiegelt nur wider, was Ihre Quellen tatsächlich gesagt haben – eine umfangreiche Zusammenfassung bedeutet ergiebige Quellen, eine knappe bedeutet, dass es wenig zu finden gab.
Genau deshalb ist die Zusammenfassung genauso wichtig wie die Engine selbst: Sie können die Konfiguration prüfen, statt sie einfach vorauszusetzen. Lesen Sie die Zählwerte, öffnen Sie einige Datensätze über ihre IDs und vergewissern Sie sich, dass der Agent erfasst hat, was Sie erwartet haben – ganz normale Datensätze, die Sie lesen und bearbeiten können, mit einer Quittung, die Ihnen präzise sagt, was Sie prüfen sollten.
