Nachweis maschineller Übersetzungen festhalten

Das brauchst du, wenn jemand fragt, welchen deiner veröffentlichten Texte ein Provider oder ein KI-Agent übersetzt hat und ob eine Person ihn geprüft hat. verbatra hält das pro Key in verbatra.provenance.json fest; du holst es als Bericht zum Archivieren heraus oder als Markierungen in den XLIFF- und TMX-Dateien, die du an andere Tools weitergibst.

Was der Nachweis sagen kann und was nichtLink zu diesem Abschnitt kopieren

Jeder Wert, den verbatra schreibt, wird mit seiner Herkunft (dem Schreibweg, der ihn erzeugt hat), einer etwaigen Review-Entscheidung und dem Namen der prüfenden Person festgehalten; siehe die Lock-Datei. Für einen Nachweis fallen die Herkünfte in zwei Klassen:

• Maschinelle Klasse: machine, memory, fuzzy und agent. Der Speicher zählt als Maschine, weil er nicht festhält, wer einen Eintrag geschrieben hat.
• Menschen: human (eine Bearbeitung über Studio oder das SDK) und import (die Übergabe einer Übersetzerin).

external, unrecorded und unknown gehören zu keiner der beiden. Eine Freigabe, die vor einer Änderung des Quelltexts erteilt wurde, gilt als ungeprüft.

Denk an die Grenzen, wenn du den Nachweis weitergibst:

• Manipulationen fallen nicht auf. Wer deine Locale-Dateien bearbeiten kann, kann auch ihn bearbeiten; sein Wert kommt aus deiner Git-Historie und deinem Code-Review.
• Er hat keine Zeitstempel. Wann ein Wert geschrieben oder freigegeben wurde, steht in der Git-Historie (git log -p verbatra.provenance.json).
• Er neigt zur Maschine. Speichertreffer, unscharfe Treffer und Agent-Bearbeitungen zählen alle als Maschine, und ein maschineller Wert, den niemand freigegeben hat, zählt als ungeprüft, auch wenn sein Text in Ordnung ist.

Der HerkunftsberichtLink zu diesem Abschnitt kopieren

verbatra report provenance gibt pro Ziel-Locale aus, wie viele Werte in jede Kategorie fallen.

verbatra report provenance

Gezählt werden nur Keys mit einem Wert sowohl in der Quelle als auch in der Ziel-Locale: Ein fehlender Key hat keinen Text, über den Rechenschaft abzulegen wäre. Ein Agent liest denselben Bericht über das MCP-Tool report.provenance.

Eine Audit-Datei aus der CILink zu diesem Abschnitt kopieren

Mit --json listet der Bericht jeden Key, was ihn zu einer Audit-Datei macht, die du mit jedem Release archivierst:

verbatra report provenance --json > provenance-report.json

Ist verbatra.provenance.json beschädigt oder von einer neueren verbatra-Version geschrieben, endet der Befehl mit 1, statt einen Bericht auszugeben, der jeden Wert als unrecorded listen würde. Ein CI-Job scheitert also, statt eine leere Audit-Datei zu archivieren.

Muss jede maschinelle Übersetzung vor einem Release geprüft sein, sichere zusätzlich mit verbatra check --require-reviewed ab.

Das JSON-SchemaLink zu diesem Abschnitt kopieren

Der Bericht ist das result der üblichen JSON-Hülle, mit command auf "report". SDK-Aufrufer bekommen dasselbe Objekt von provenanceReport.

Lässt sich die Herkunftsdatei nicht lesen, ist das Ergebnis { "available": false, "reason": "provenance-unreadable" }. Später können neue optionale Felder hinzukommen; vorhandene behalten ihre Bedeutung.

Markierungen in ExportenLink zu diesem Abschnitt kopieren

Die Herkunft reist auch in die Dateien mit, die du an andere Tools weitergibst, damit die Gegenseite maschinelle Ausgabe von menschlicher Arbeit unterscheiden kann.

XLIFFLink zu diesem Abschnitt kopieren

verbatra export mit --format xliff12 oder --format xliff2 markiert jede Unit mit einem Ziel:

mt-suggestion ist der XLIFF-1.2-Wert für "von maschineller Übersetzung vorgeschlagen", den CAT-Tools auch so anzeigen, neben dem üblichen state. Ein Wert, den eine Person freigegeben hat oder für dessen Herkunft verbatra nicht bürgen kann, bekommt keinen Qualifier.

XLIFF 2.0 hat keinen Status-Qualifier, deshalb bekommt die verbatra-Metadatengruppe der Unit, die schon den Quell-Hash enthält, die vollständige Herkunft und den Review-Status:

<mda:metaGroup category="verbatra">
  <mda:meta type="source-hash">8f3a0c1e2b4d6f70</mda:meta>
  <mda:meta type="origin">machine</mda:meta>
  <mda:meta type="review-state">unreviewed</mda:meta>
</mda:metaGroup>

TMXLink zu diesem Abschnitt kopieren

verbatra tmx export schreibt auf jedes Zielsegment eine Eigenschaft x-origin und neben ein machine-Segment zusätzlich x-review:

<tuv xml:lang="de"><prop type="x-origin">machine</prop><prop type="x-review">unreviewed</prop><seg>Zur Kasse</seg></tuv>

x-origin ist machine, human, import oder unknown; x-review ist approved, unreviewed oder rejected. Ein Speichereintrag ist ein Textpaar, kein Key, deshalb ist ein Segment machine, wenn irgendein Key mit genau diesem Text zur maschinellen Klasse gehört, und approved nur, wenn das für jeden solchen Key gilt. Ein Text, den kein Eintrag beschreibt, ist unknown.

Markierte Dateien importierenLink zu diesem Abschnitt kopieren

Der Import ignoriert jede Markierung. Eine XLIFF-Unit wird nach ihrem Ziel und Status beurteilt, ein TMX-Segment nach seinem Text. Ein aus einer Übergabe importierter Wert wird als import festgehalten, und ein TMX-Import füllt nur den Übersetzungsspeicher. Eine Markierung, die ein Tool umgeschrieben, entfernt oder erfunden hat, kann deinen Nachweis also nicht ändern.

Wenn sich der Nachweis nicht lesen lässtLink zu diesem Abschnitt kopieren

Ist verbatra.provenance.json beschädigt oder von einer neueren verbatra-Version (oder lässt sich bei TMX die Lock-Datei nicht lesen), gelingt der Export trotzdem, schreibt aber keine Markierungen statt solcher, die er nicht belegen kann. Die Zusammenfassung sagt das, und das --json-Ergebnis trägt provenanceMarkers: "unavailable" statt "written".

Siehe auchLink zu diesem Abschnitt kopieren

• verbatra report: Flags, Ausgabe und Exit-Codes des Herkunftsberichts.
• In Studio prüfen: maschinelle Übersetzungen freigeben oder ablehnen, einzeln oder pro Locale.
• Datenverarbeitung und Datenschutz: was verbatra an wen sendet und was es lokal behält.