Forum von Schübeler Consulting
MÜ und Post-Editing: light oder full, das ist die eigentliche Frage - Druckversion

+- Forum von Schübeler Consulting (https://forum.schuebeler-consulting.de)
+-- Forum: 🧩 Technische Kommunikation (https://forum.schuebeler-consulting.de/forum-11.html)
+--- Forum: 🌍 Internationalisierung & Lokalisierung (https://forum.schuebeler-consulting.de/forum-14.html)
+--- Thema: MÜ und Post-Editing: light oder full, das ist die eigentliche Frage (/thread-64.html)



MÜ und Post-Editing: light oder full, das ist die eigentliche Frage - Johann Jörgen Schübeler - 16.09.2025

Maschinelle Übersetzung wird in vielen Häusern eingeführt und dann wundert man sich, dass die Ergebnisse schwanken. Meist liegt es an etwas anderem als der Engine: Niemand hat entschieden, was hinter der MÜ passieren soll.

Ich unterscheide hart zwischen zwei Welten:
  • Light Post-Editing: Sinn muss stimmen, grobe Fehler raus, Stil egal. Geeignet für interne Dokumente, Wissensbasen, Tickets, Recherchezwecke.
  • Full Post-Editing: Lesefluss, Terminologie, Konsistenz, rechtliche Korrektheit. Pflicht bei allem, was an den Markt geht, überall, wo Sicherheit oder Haftung im Spiel ist.

Wer beides mischt, bekommt das Schlechteste aus beiden Welten: zu teuer für den internen Gebrauch, zu unsauber für den externen Auftritt.

Mein Tipp aus der Praxis: Legen Sie pro Dokumenttyp fest, welches Niveau gefordert ist, und schreiben Sie das in die Auftragsbeschreibung an den Dienstleister. "Bitte übersetzen" ist keine Auftragsbeschreibung. "Full Post-Editing nach ISO 18587, Terminologie X verbindlich" schon.

Und bitte: Sicherheitsrelevante Inhalte und Warnhinweise gehen nie in Light. Da sehe ich Engine plus Light-Editing als nicht ausreichend.

Hinweis: Das ersetzt keine rechtliche Beratung im Einzelfall.

Wie haben Sie das in Ihrem Haus geregelt, einheitlich oder von Fall zu Fall?


RE: MÜ und Post-Editing: light oder full, das ist die eigentliche Frage - JSC_Admin - 27.09.2025

Sehr guter Punkt mit der Auftragsbeschreibung. Was bei uns half: die Kategorien einmal im Redaktionsleitfaden festhalten und dann an den Dokumenttyp koppeln, nicht an die Tagesform des Projektleiters. Das hat die Reibung mit dem LSP deutlich reduziert.