TranslateBooksWithLLMs: ganze Bücher über LLM-APIs übersetzen, ohne Formatverlust

Welches Problem TBL löst und für wen es gedacht ist

Ein Roman hat schnell 400 Seiten. Kein Modell verarbeitet das in einem Aufruf, und wer seitenweise kopiert, verliert Kapitelstruktur, Kursivsetzungen und bei Untertiteln die Zeitcodes. Genau diese Lücke adressiert TBL: Die Anwendung nimmt eine vollständige Datei entgegen, zerlegt sie intern und setzt das Ergebnis wieder zusammen. Das README nennt als Formate EPUB, SRT, DOCX und TXT und verspricht, dass EPUB-Formatierung, Stile und Struktur erhalten bleiben und SRT-Zeitcodes synchron bleiben. Die Zielgruppe sind nicht Entwickler, die eine Bibliothek einbinden wollen, sondern Anwender, die eine fertige Datei besitzen. Der Quick Start beschreibt den Ablauf als Archiv entpacken, TranslateBook.exe oder ./TranslateBook starten und http://localhost:5000 im Browser öffnen. Das ist eine Desktop-Anwendung mit lokalem Webserver, kein Dienst, den man irgendwo hostet. Wer nur ein paar Absätze braucht, ist hier falsch: Der Aufwand für Installation, Provider-Auswahl und Modell-Download steht in keinem Verhältnis zu einem einzelnen Textabschnitt.

Chunking, Checkpoints und der Kontext zwischen den Segmenten

Das README beschreibt ein intelligentes Chunking-System, das unbegrenzte Inhaltslängen verarbeitet und den Kontext zwischen den Segmenten bewahrt. Wie die Segmentgrenzen genau berechnet werden, geht aus dem Material nicht hervor; das ist eine der Stellen, an denen die Dokumentation dünn bleibt. Sichtbar ist dagegen die Konsequenz für den Betrieb: Weil die Übersetzung über viele einzelne Modellaufrufe läuft, ist ein Abbruch nach mehreren hundert Aufrufen der Normalfall, nicht die Ausnahme. Hier greift das Checkpoint-System, das den Fortschritt laut README automatisch speichert, sodass ein unterbrochener Lauf an derselben Stelle fortgesetzt werden kann. Ein zweiter Mechanismus betrifft die Konsistenz über Segmentgrenzen hinweg. Es gibt Glossare und sogenannte Style-Presets, die auf jeden Chunk angewendet werden, damit Register, Rhythmus und Bildsprache über das gesamte Werk gleich bleiben. Wer keine dieser Vorgaben vorbereitet hat, kann im Dropdown Auto wählen. Dann leitet die Anwendung laut README Glossar und Preset direkt aus dem zu übersetzenden Dokument ab, jeweils mit einem zusätzlichen LLM-Aufruf vor dem eigentlichen Start, und speichert nichts davon dauerhaft.

Provider-Auswahl: lokal über Ollama oder Cloud per API-Schlüssel

TBL zwingt nicht auf einen Anbieter. Die Anbieterliste umfasst Ollama lokal, OpenAI-kompatible Endpunkte wie llama.cpp, LM Studio, vLLM und LocalAI, sowie die Cloud-Dienste OpenAI, Gemini, Mistral, DeepSeek, NVIDIA NIM, OpenRouter und Poe. Der Unterschied liegt nicht nur im Preis, sondern in der Datenhaltung: Bei Ollama verlässt der Buchtext die Maschine nicht, bei den Cloud-Anbietern wird er pro Chunk an einen fremden Endpunkt geschickt. Für verlagseigene Manuskripte oder unveröffentlichte Übersetzungen ist das die erste Frage, die zu klären ist, nicht die Modellqualität. OpenRouter und Poe sind Aggregatoren; OpenRouter nennt das README mit über 200 Modellen. Das klingt nach Auswahl, verschiebt aber nur die Entscheidung: Man muss trotzdem wissen, welches Modell die Zielsprache gut trägt. Dafür verweist das README auf ein Wiki mit Übersetzungsqualitäts-Benchmarks. Diese Benchmarks sind die einzige im Material genannte Grundlage für die Modellwahl, und sie liegen außerhalb des Repositorys.

Installation aus dem Quellcode und die wichtigsten CLI-Aufrufe

Neben den fertigen Archiven für Windows, macOS Intel und macOS Apple Silicon lässt sich TBL aus dem Quellcode betreiben. Die Voraussetzungen laut README sind Python 3.8 oder neuer, Ollama und Git. Der Ablauf ist: git clone https://github.com/hydropix/TranslateBooksWithLLMs.git, dann cd TranslateBookWithLLM, dann ollama pull qwen3:14b für ein Modell, danach start.bat unter Windows oder chmod +x start.sh && ./start.sh unter Mac und Linux. Die Weboberfläche erscheint auf http://localhost:5000. Für Skripte gibt es translate.py. Der einfachste Aufruf lautet python translate.py -i book.epub -sl English -tl Chinese und erzeugt laut README automatisch eine Datei namens book (Chinese).epub. Die Parameter wiederholen sich über die Anbieter: -i für die Eingabe, -sl und -tl für Ausgangs- und Zielsprache, --provider für den Dienst, ein anbieterspezifischer Schlüssel und -m für das Modell. Für OpenRouter sieht das so aus: python translate.py -i book.txt --provider openrouter --openrouter_api_key YOUR_KEY -m anthropic/claude-sonnet-4 -tl French. Für Gemini entsprechend --provider gemini --gemini_api_key YOUR_KEY -m gemini-2.0-flash, für DeepSeek --provider deepseek --deepseek_api_key YOUR_KEY -m deepseek-v4-pro, für NVIDIA NIM --provider nim --nim_api_key YOUR_KEY -m meta/llama-3.1-8b-instruct. Beim ersten Start legt die Anwendung einen Ordner TranslateBook_Data mit den Einstellungen an.

Wo TBL an Grenzen stößt

Die größte Einschränkung ist struktureller Natur. Eine Übersetzung über viele Chunks hinweg kann an den Nahtstellen abweichen: Pronomen, Anredeformen und wiederkehrende Begriffe können zwischen zwei Segmenten kippen, wenn das Modell den vorherigen Kontext nicht sieht. Glossar und Style-Preset sind der vorgesehene Gegendruck, aber sie sind eine Vorgabe an das Modell, keine Garantie. Wer ein literarisches Werk mit dichter Motivik übersetzt, sollte mit einem Probelauf über mehrere Kapitel prüfen, ob die Nahtstellen tragen, bevor der ganze Roman durchläuft. Ein zweites Problem ist die Modellwahl selbst. Das README verweist für Qualitätsvergleiche auf das Wiki, liefert aber keine eigene Aussage darüber, welche Modelle für welche Sprachpaare geeignet sind. Wer eine seltene Zielsprache braucht, muss diese Prüfung selbst übernehmen. Drittens die Betriebsform: TBL ist ein lokaler Server auf Port 5000. Für Einzelpersonen am eigenen Rechner ist das unproblematisch, für eine Gruppe, die dieselbe Übersetzung parallel bearbeiten will, ist im Material keine Mehrbenutzerverwaltung erkennbar. Und schließlich der Kostenpunkt bei Cloud-Anbietern: Jeder Chunk eines 400-Seiten-Buchs ist ein eigener API-Aufruf, plus bei Auto-Modus zwei zusätzliche Aufrufe für Glossar und Preset. Die Rechnung ist linear zur Buchlänge, nicht pauschal.

Alternative: LibreTranslate und der Unterschied im Ansatz

Wer keine LLM-Abhängigkeit will, landet bei klassischen Übersetzungs-Engines wie LibreTranslate oder Argos Translate. Der Unterschied liegt nicht in der Lizenz oder der Oberfläche, sondern im Mechanismus. Diese Systeme übersetzen Satz für Satz mit speziell trainierten Modellen und liefern dadurch einen gleichmäßigeren Stil über lange Texte, weil sie keinen Prompt-Kontext brauchen und nicht zwischen Segmenten schwanken. Sie sind außerdem deutlich schneller und lokal ohne GPU betreibbar. Was sie nicht können: auf ein Glossar oder ein Stil-Preset reagieren, eine Anredeform konsistent durchhalten, wenn das Trainingsmaterial sie nicht vorgibt, oder eine im Prompt beschriebene Registerebene einhalten. TBL setzt genau dort an, wo statistische Engines scheitern, und bezahlt dafür mit Geschwindigkeit, Hardwarebedarf und der Notwendigkeit, ein Modell auszuwählen. Für einen technischen Bericht mit klarer Terminologie ist LibreTranslate oft die vernünftigere Wahl. Für einen Roman, in dem eine Figur durchgehend in einer bestimmten Tonlage spricht, ist der LLM-Ansatz mit Style-Preset der passendere Hebel.

Wartung, Updates und was AGPL-3.0 bedeutet

Die Release-Historie im Material zeigt drei Versionen innerhalb weniger Wochen: v1.5.8 und v1.5.9 am 24. August 2026, v1.5.10 am 6. September 2026. Das deutet auf eine aktive Pflege mit kurzen Intervallen hin. Für Anwender heißt das: Die Archiv-Downloads für Windows und macOS werden regelmäßig ersetzt, und wer aus dem Quellcode installiert, sollte vor einem großen Übersetzungslauf aktualisieren, weil Fehlerkorrekturen im Chunking oder in der Provider-Anbindung genau den Lauf betreffen, der Stunden dauert. Die Lizenz ist AGPL-3.0. Das ist keine Rechtsberatung, aber die praktische Konsequenz sollte man kennen: Wer TBL verändert und als Netzwerkdienst betreibt, wird von der AGPL typischerweise zur Offenlegung des Quellcodes verpflichtet. Für den privaten Gebrauch am eigenen Rechner ist das irrelevant. Für den Fall, dass jemand die Anwendung in ein kommerzielles Produkt einbetten will, ist das die erste Frage an die Rechtsabteilung, noch vor der Modellwahl. Das Repository selbst enthält keine Hinweise auf kommerzielle Lizenzoptionen.

Redaktionelles Fazit

Wer EPUB- oder SRT-Dateien mit einem selbst gewählten Modell übersetzen will und Python 3.8 sowie Ollama oder einen API-Schlüssel bereits hat, findet hier einen direkten Weg über die Kommandozeile. Wer eine gehostete Lösung ohne lokale Installation braucht oder Übersetzungen als Closed-Source-Produkt weitergeben will, sollte wegen AGPL-3.0 und des lokalen Servers auf Port 5000 Abstand nehmen. Vor dem ersten produktiven Lauf zu klären: ob das gewählte Modell die Zielsprache im Wiki-Benchmark abdeckt, wie sich die Checkpoint-Dateien im TranslateBook_Data-Ordner bei einem Abbruch verhalten und ob die Lizenz der eigenen Weitergabe entspricht.

Offizielle Quellen

1. hydropix/TranslateBooksWithLLMs on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases