Scribe und Word: Ein docx-vermittelter Rundlauf-Prüfworkflow
Lektoren, Mitarbeiter und Verlage akzeptieren oft nur Word (oder Äquivalente). Dieser Artikel erklärt die docx-Brücke zwischen Scribe und Word, die Versionskontrolle über mehrere Prüfrunden und den richtigen Zeitpunkt, Word zu verlassen und zur Markdown-Seite zurückzukehren.
Scribe und Word: Ein docx-vermittelter Rundlauf-Prüfworkflow
Unabhängig davon, womit ein Autor schreibt, bleibt Microsoft Word im Jahr 2026 das am weitesten verbreitete »Zwischenformat« in Verlags- und Lektorats-Workflows. Lektoren, Texter, Literaturagenten, Co-Autoren, interne Prüfprozesse traditioneller Verlage – die meisten behandeln .docx nach wie vor als Lingua Franca. Selbst wenn Sie seit Jahren in Markdown schreiben, selbst wenn Sie planen, im Selbstverlag zu veröffentlichen und traditionelle Kanäle zu überspringen – sobald Ihre Pipeline eine andere Person einschließt, ist docx schwer zu vermeiden. »Word« umfasst in diesem Artikel auch vergleichbare Werkzeuge, die docx lesen und schreiben können – LibreOffice Writer, Apple Pages, Google Docs, WPS – ihr Kollaborationsmodell und die Grenzen von docx sind gemeinsam.

Catalpas Atelier Scribe hat nicht zum Ziel, Word zu ersetzen, und versucht nicht, sich mit Words Kollaborationsfunktionen zu messen. In dieser Pipeline besitzt Scribe die »Autorenseite: Prosa und fertiges Buch«, und Word besitzt auf der Lektorenseite »Kommentare, Überarbeitungen, Prozessbegleitung«. Die beiden Seiten tauschen das Manuskript über docx aus. Die Frage ist nicht »welches Werkzeug« – es ist »wann übergebe ich das Manuskript an docx, und wann hole ich es zurück«.
Die Realität: Mitarbeiter akzeptieren nur docx
Für unabhängige Autoren ist es günstiger, dies zu akzeptieren, als dagegen anzukämpfen. Selbst wenn der Lektor, mit dem Sie arbeiten, technisch versiert ist und grundsätzlich Markdown lesen könnte, braucht er in der Prüfphase nicht die Lesefähigkeit – es ist der gesamte Änderungsverfolgungs- + Kommentar-Kollaborationsritus, der um Word herum aufgebaut ist. Markdown hat kein gleichwertig ausgereiftes visuelles Prüfsystem. CriticMarkup-ähnliche Marker können in einem kleinen Kreis funktionieren, aber sie können nicht liefern: »Ich möchte, dass mein Lektor alle Überarbeitungen meines Buches innerhalb von zwei Stunden durchgehen kann.«
Der realistische Workflow sieht also normalerweise so aus: Sie schreiben den Text in Scribe, organisieren Kapitel und nehmen lokale Überarbeitungen vor; wenn das Manuskript einen Prüfdurchlauf benötigt, exportieren Sie ein docx; die andere Person arbeitet es in Word (oder LibreOffice, Pages, Google Docs) mit Änderungsverfolgung und Kommentaren durch und sendet es zurück; Sie kehren zu Scribe zurück und »übersetzen« deren Überarbeitungen zurück in den Text. Jeder Rundlauf bringt eine Formatkonvertierung mit sich, also wird die Frage: Wie machen Sie diese Konvertierung so günstig wie möglich.
Die docx-Brücke: Was übergeht, was verloren geht
Wenn Scribe ein docx exportiert (und wenn Sie ein überarbeitetes docx von jemand anderem zurück in Scribe holen), ist das Schicksal mehrerer Inhaltsarten wissenswert, bevor es passiert.
Struktur und Kapitelüberschriften bleiben relativ treu – die Zuordnung von Überschrift 1 / Überschrift 2 ist auf beiden Seiten stabil. Das bedeutet, dass Scribe es bei der Rückkehr aufnimmt, wenn jemand in Word Kapitel umordnet oder Überschriften umbenennt.
Textabsätze und grundlegende Formatierungen (fett, kursiv, Blockzitate) überleben den Rundlauf ebenfalls. Aber Absatzabstand, Zeilenabstand und Schriftgröße sind Eigenschaften der projektweiten Satzsteuerung von Scribe – sie sollten in docx nicht von Hand angepasst werden. Wenn sie es doch werden, werden sie entweder durch Scribes Satz bei der Rückkehr überschrieben oder erzeugen lokale Inkonsistenzen. Wenn Sie das docx übergeben, sagen Sie dem Lektor explizit: »Bitte ändern Sie nur Text und Struktur – den Satz vereinheitliche ich auf meiner Seite.«
Die Änderungsverfolgung ist das Wertvollste in dieser Pipeline – sie zeigt Ihnen genau, welcher Absatz bearbeitet wurde, was hinzugefügt, was gelöscht wurde, von wem und wann. Auf der Scribe-Seite behalten Sie das zurückgegebene docx als »Referenzdatei«, gehen die Überarbeitungen einzeln durch, entscheiden über Annahme/Ablehnung und wenden sie manuell in Scribe an. Versuchen Sie keine automatische Zusammenführung – kein Werkzeug erhält derzeit die Änderungsverfolgung verlustfrei über einen Markdown ↔ docx-Rundlauf, und die paar Minuten, die Sie vorne sparen, decken nicht die Zeit, die Sie später mit der Fehlersuche verbringen.
Kommentare sind ähnlich – behandeln Sie die docx-Kommentare als »Aufgabenliste« auf der Scribe-Seite, arbeiten Sie sie ab, bearbeiten Sie die Prosa in Scribe, und archivieren Sie das ursprüngliche docx, wenn Sie fertig sind. Kommentare müssen nicht – und sollten nicht – im Scribe-Projekt neben dem Textkörper leben.
Was verloren geht: komplexe Tabellen, eingebettete Objekte (Formeln, Diagramme, SmartArt), Textfelder, benutzerdefinierte Formate. Die meisten Belletristik-Manuskripte verwenden diese nicht. Wenn Sie Sachbücher mit vielen Abbildungen schreiben, müssen Sie mit dem Lektor von Anfang an vereinbaren: »Lassen Sie die Abbildungen vorerst in Ruhe, prüfen Sie nur den Text«, um ein erneutes Einfügen von Abbildungen bei jeder Runde zu vermeiden.
Versionskontrolle über mehrere Prüfrunden
Wenn Sie zwei oder drei Runden Rundlauf-Prüfung durchführen, sind Dateibenennung und Archivierung wichtiger, als es den Anschein hat. Ein zuverlässiger Ansatz:
- Beim Export von Scribe zum Lektor:
buchname_v0.3_an-lektor_20XX-MM-TT.docx - Wenn der Lektor es zurückschickt:
buchname_v0.3_vom-lektor_20XX-MM-TT.docx - Nachdem Sie die Verarbeitung abgeschlossen haben, erhöhen Sie die Version im Scribe-Projekt auf
v0.4und beginnen die nächste Runde
Der Punkt sind nicht hübsche Dateinamen – es ist, dass Sie jederzeit beantworten können: »Welche Version hat der Lektor gerade?« und »Gibt es eine Versionsabweichung zwischen uns?« Die aktuellste Version der Prosa lebt immer im Scribe-Projekt – ausgehende docx-Dateien sind Schnappschüsse, eingehende docx-Dateien sind feedbacktragende Schnappschüsse, aber keine davon ist die Quelle der Wahrheit.
Zweite Regel: Wenn die Rückmeldung des Lektors eintrifft, tauchen Sie nicht sofort in Scribe ein. Lesen Sie zuerst das zurückgegebene docx vollständig durch, treffen Sie ein Urteil zu jeder Überarbeitung und jedem Kommentar (akzeptieren / ablehnen / diskutieren), und übertragen Sie dann die Entscheidungen in einem Stapel zurück in Scribe. Das ist viel schneller als »docx lesen und gleichzeitig in Scribe bearbeiten« und reduziert Versionsabweichungen.
Wann Sie die Word-Seite verlassen sollten: Wissen kehrt zurück zu Markdown
Eine letzte Entscheidungsfrage: Wann sollten Sie aufhören, die docx-Brücke zu durchlaufen?
Wenn Sie im Selbstverlag veröffentlichen und sich noch in der persönlichen Entwurfsphase befinden, brauchen Sie die erste Runde gar nicht – schreiben Sie in Scribe bis zum Ende, lesen Sie selbst Korrektur, überarbeiten Sie, liefern Sie EPUB und Druck-PDF aus. docx ist nur seinen Aufwand wert, wenn Sie »eine andere Person brauchen, die das Manuskript ansieht und deren Änderungen Sie übernehmen«.
Wenn Sie bereits zwei oder drei Runden inhaltlicher und sprachlicher Überprüfung hinter sich haben, sollte die finale Abschlussphase vollständig auf die Scribe-Seite zurückkehren: Von nun an geschieht jede Änderung nur noch innerhalb des Scribe-Projekts, kein weiteres »ein weiteres docx zur Freigabe versenden« mehr. Jeder Rundlauf bringt ein wenig Formatierungs- und Satzrisiko mit sich, und in der Phase vor dem Druck gibt es keinen Grund, dieses Risiko weiter einzugehen.
Wann sollten Sie Word ganz überspringen? Wenn der Mitarbeiter selbst die Markdown-Zusammenarbeit akzeptiert (eine kleine Zahl technisch orientierter Lektoren, enge Co-Autoren-Gruppen) und nicht auf den Änderungsverfolgungsritus angewiesen ist – dann können Sie Änderungen über git diff oder Scribes integrierten Versionsvergleich kommunizieren, leichter als docx-Rundläufe. Aber beurteilen Sie die tatsächlichen Gewohnheiten der anderen Person ehrlich. Lassen Sie nicht »ich wünschte, sie würden Markdown verwenden« über »so arbeiten sie tatsächlich« siegen.
Das könnte Sie auch interessieren
- Der Scribe-Kollaborations-Hub — der Einstiegspunkt für Workflows mit anderen Schreib-, Notiz- und Prüfwerkzeugen
- Scribe versus Microsoft Word: Vergleich Seite an Seite — wenn Sie lieber von einem Werkzeugvergleich ausgehen möchten