Praxis-Erfahrungen mit OmegaT im Sommer 2026

Seit April dieses Jahres habe ich das Open-Source CAT-Tool OmegaT im produktiven Einsatz, um den kommerziellen Platzhirsch Trados Studio zu ersetzen. Nach dem Wechsel von Vollzeit-Freelancing zur Nebentätigkeit ergab es für mich keinen betriebswirtschaftlichen Sinn mehr, mir die Folgeversion zu kaufen oder mich auf das jetzt angebotene Abo-Modell einzulassen. Für andere mag diese Kalkulation nach wie vor attraktiv sein, insbesondere bei Kollegen, die Agenturkunden haben, welche Trados voraussetzen (Stichwort: Trados Projektpakete). Über meinen Wechsel und erste Eindrücke habe ich in Wege von Trados zu OmegaT im Frühling 2026 berichtet.

Nach einigen Monaten im Produktiveinsatz kann ich nun sagen: Läuft!
Das gilt sowohl für MS Office-basierte Projekte mit Word- und Excel-Dateien, als auch für Projekte mit Adobe RoboHelp XLIFF-Dateien. Da XLIFF (.xlf) ein Standardformat für den Austausch von Übersetzungsstrings ist und RoboHelp sich im Gegensatz zum WordPress-Plugin WPML sauber daran hält, klappt das ohne Vor- und Nachbereitung hervorragend.

Was nervt mich mehr oder weniger als ursprünglich gedacht?

Im Frühjahr habe ich vier Schmerzpunkte identifiziert, die sich teils erhalten und teils in Wohlgefallen aufgelöst haben:

1. Eine richtige Termbank statt einem einfachen Glossar.
   Das fehlt mir immer noch. Die Einbindung von .TBX-Daten in OmegaT’s Glossar-Panel zeigt einfach alles aus dem TBX-Eintrag ohne jedes CSS-Styling an – Terme sind nicht hervorgehoben oder werden wie Glossareinträge für die Autovervollständigung genutzt, jeder Eintrag von Auswahlfeldern wie “Wortart” oder “Qualität” wird immer angezeigt, womit sie ihren Sinn verlieren, Medien wie technische Zeichnungen, Screenshots oder Produktvideos können nicht angezeigt werden.
2. Autovervollständigung aus TM- und MT-Quellen.
   Diese Funktion vermisse ich inzwischen weniger als gedacht. Das liegt aber womöglich am insgesamt geringeren Volumen als zu Zeiten, in denen ich 100% Übersetzer war.
3. Weniger rudimentäre Projekt-, Datei- und Matchstatistiken.
   Da habe ich inzwischen etwas mehr herausgefunden, also behandle ich das unten etwas ausführlicher, denn manches fand ich nicht direkt intuitiv.
4. Die etwas altbackene Java-Optik …
   … finde ich inzwischen auch nicht mehr so schlimm. Am Ende ist es ein Werkzeug – und es tut, was es soll: Mir die Arbeit als Übersetzer erleichtern, Konsistenz und Qualitätssicherung sicherstellen und mir die Abrechnung auch mit Matchrabatten für technische Übersetzungen ermöglichen.

Erkenntnis 1: Das Projektverzeichnis richtig befüllen

Bei Trados fügt man alle möglichen Ressourcen (Translation Memories, Machine Translation Provider, Wörterbücher, MultiTerm Termbanken, Autosuggest Dictionaries, etc.) über die “Projekteinstellungen” per Klick hinzu. Bei OmegaT kopiert man hingegen alle benötigten Ressourcen in die entsprechenden Ordner des Projektverzeichnisses. Das ist weder einfacher noch aufwändiger, nur anders.

• dictionary: Hier landen Wörterbücher im StarDict-, Hunspell- oder Myspell-Format. OmegaT kann aber auch Wörterbücher aus einer vorhandenen LibreOffice-Installation mitnutzen.
• glossary: Hier kommt die von OmegaT schreibbare glossary.txt unter, ebenso wie meine aus MultiTerm nach .TBX konvertierten Termbanken.
  Dem Vorschlag eines LLMs folgend habe ich die auch alle mit diesem fix gevibecodeten Python-Script ins JSON-Listenformat .JSONL konvertiert – angeblich könne OmegaT sie dann schneller auslesen. Allerdings scheinen mir die Daten, die ich im Glossary-Fenster in OmegaT sehe, eher auf die komplexe .TBX als die einfacher gestrickte .JSONL hinzudeuten. Der Vorschlag mag also eine Halluzination gewesen sein. Wer mehr dazu weiß, darf mich und alle Leser/-innen gerne in den Kommentaren erleuchten.
• script_output: Hier muss man nichts hineinkopieren, aber OmegaT-Groovy-Skripte wie Write Notes legen dort ihre Ergebnisse ab. Im Fall von Write Notes landen hier z. B. die Übersetzer-Notizen in Form einer HTML-Tabelle zusammen mit Segmentnummer und Segmenttext.
• tm: In den TM-Ordner kann man seine vorhandenen Translation Memories im .TMX-Format ablegen, damit OmegaT sie zusätzlich zu den eigenen projektspezifischen TMX-Dateien zu Rate zieht.
  Auch hier riet dasselbe LLM zu einer Konvertierung nach JSONL, also gibt’s auch dafür ein TMX2JSONL-Python-Skript mit ebenfalls noch unbewiesenem Nutzen.
  Tipp: Hier lohnt sich ein Blick in die Dokumentation, denn der tm-Ordner hat die Unterordner auto, enforce, mt, penalty-xx (xx umbenennen in eine Zahl!) und tmx2source, die alle eine besondere Bewandtnis haben. Beispielsweise gelten TMX-Dateien im auto-Ordner als 100 % vertrauenswürdig und werden direkt ohne eine Markierung für TM-Matches eingefügt.

Von innerhalb des Programms geschieht hingegen unter anderem …

• die Konfiguration der Benutzeroberfläche,
• die Einbindung und Aktivierung von Groovy-Skripten wie Write Notes für den Export von Übersetzer-Notizen/-Kommentaren in eine HTML-Tabelle oder Character Limiter, um bei UI-Strings in der Übersetzung nicht länger als das Quellsegment oder ein Fixwert zu werden und
• die Einbindung von Maschine Translation-Providern wie DeepL.

Erkenntnis 2: Der Trick mit der Statistik und der Matchrabatt-Abrechnung

Wenn man ein neues OmegaT-Projekt anlegt, erzeugt OmegaT automatisch die Datei project_stats.txt im Projekt-Unterordner ./omegat. Das ist die Statistik-Datei, die ich zuerst gefunden habe und auf der das Normzeilen-Script aus dem letzten Artikel basiert. Die Informationen darin waren auf den ersten Blick zu rudimentär und nicht geeignet, eine Abrechnung mit Match-Rabatten zu erzeugen.

Über die Menüpunkte Tools → Match-Statistiken und Match-Statistiken pro Datei kann man jedoch die benötigen Berichte generieren. Sie werden im Projekt-Unterordner ./omegat/ abgelegt: project_stats_match.txt bzw. project_stats_match_per_file.txt.

Diese Dateien enthalten einen Kopfbereich und einen Tabulator-separierten Statistikteil. Man kann sie also einfach* in LibreOffice Calc oder einer anderen Tabellenkalkulation laden.

*: Stichwort “Einfach”: Bei MS Excel hat es sich für mich als stabiler erwiesen, eine leere Tabelle per Daten → Importieren aus CSV zu importieren als die Textdatei direkt mit Excel öffnen zu wollen. Genauso bei LibreOffice Calc: Wegen der Dateiendung .txt (statt .tab oder .csv) muss ich erst Calc öffnen und die Textdatei dann hineinziehen, damit sie von Calc anstatt Writer geladen wird.

Den _per_file-Statistiktabellen aus OmegaT kopiere ich dann aus einer Vorlage folgende Formeln hintan (Beispielhaft für eine Zeile 147 “Wiederholungen innerhalb dieser Datei”):

• Spalte G “Normzeilen” =AUFRUNDEN(E147/55;0) → Den Wert der Spalte E “Zeichen (mit Leerzeichen)” in deutsche Normzeilen umrechnen
• Spalte H “Match-Rabatt” 97% → Der anzuwendende Matchrabatt für den Match-Bereich “Wiederholungen”
• Spalte I “Zeilenpreis” für de “Neu/Kein Match” z. B. 1,95 EUR in Zelle I154 und für die anderen Matchbereiche eine Verrechnung dieser Basispreis-Zelle mit dem anzuwendenden Matchrabatt z. B. in der Form =I147*(1-H154)
• Spalte J “Netto” =G147*I147 für den Nettopreis in Euro, Spalte K “MwSt_19%” =I147*0,19 für die Mehrwertsteuer und Spalte L “Brutto” =SUMME(J147;K147) für den Bruttobetrag.
• Ans Ende der Liste kommt dann noch eine Summenformel für die Netto/MwSt/Brutto-Spalten zum Zusammenzählen der Einzelbeträge, denn hier ist Vorsicht geboten:
  Die Zeile “Gesamt” jedes Blocks (im Bild hellgelb) und den gesamten Block “Alle Dateien” lasse ich grundsätzlich außer Acht. Ich benutze stattdessen Summenformeln (im Bild knallgelb), um die korrekten (Honorar-)Summen zu erhalten, ansonsten summieren hier Rundungseffekte zum Nachteil des Übersetzers auf.

Tipp: Wenn man vergessen hat, die Matchstatistik direkt am Anfang auszulösen und schon ein paar Zeilen oder auch alles übersetzt hat (was diesem hier natürlich nie passieren würde! *hüst, hüst*), dann gibt es einen Trick, doch noch zur korrekten Matchwert-Statistik zu kommen, ohne das Projekt neu anzulegen:

1. OmegaT schließen.

2. Die project_save.tmx im ./omegat Projekt-Unterverzeichnis in project_save.tmx.bak umbenennen.

3. OmegaT öffnen und via Tools > Match-Statistiken pro Datei ausführen.

4. OmegaT schließen.

5. Die neu erzeugte project_stats_match.txt irgendwo sichern, die neu ohne jede Übersetzung erzeugte project_save.tmx durch die zuvor gesicherte project_save.tmx.bak ersetzen.

6. OmegaT neu starten: Alle Übersetzungen sind wieder da.

Abrechnungsprobleme nach dem Wechsel von Trados Studio

Es gibt allerdings zwei Probleme, die mich ein paar Stunden Kalkulation gekostet haben:

1. In Trados Studio hatte ich die Möglichkeit, die Matchwert-Spannen selbst festzulegen. OmegaT gibt die Matchwert-Spannen jedoch fix vor. Ich musste also neu austarieren, welche Rabatte ich für welche Spannen gewähre.

2. Dazu kommt, dass OmegaT nicht übersetzbare Inhalte (Tags und andere sogenannte Placeables) anders setzt als sie in den aus Trados Studio übernommenen Translation Memories enthalten waren.
Die Folge: Segmente, die eigentlich Perfect Matches/Context Matches bzw. Exakte Matches und 95-100% Matches sein sollten, werden um 1 Klasse, bei sehr vielen Tags im Segment manchmal auch um 2 Klassen abgestuft.

Das kann man je nach Geschäftsphilosophie als willkommenen Geldsegen betrachten oder als etwas, das man den eigenen Kunden nicht zumuten möchte, nur, weil man sein Werkzeug wechselt. Ich jedenfalls habe, sobald ich das bemerkte, noch einmal an den Matchrabatten geschraubt.
Immerhin: Mit fortwährender Arbeit in OmegaT wird sich das Problem von selbst ausgleichen, weil dann wieder passende Matches im Translation Memory gespeichert sind.

Was sind eure Eindrücke und Stolperfallen – oder Tipps und Tricks mit OmegaT? Ich freue mich über eure Kommentare.