Scribe y Word: un flujo de revisión de ida y vuelta con docx

Scribe y Word: un flujo de revisión de ida y vuelta con docx

Sin importar lo que use un autor para escribir, Microsoft Word sigue siendo, en 2026, el «formato intermedio» más común en los flujos de trabajo de edición y publicación. Los editores adquirientes, correctores de estilo, agentes literarios, coautores, procesos de revisión interna de editoriales tradicionales — la mayoría sigue tratando .docx como la lengua franca. Incluso si ha escrito en Markdown durante años, incluso si planea autoeditarse y saltarse los canales tradicionales, en el momento en que su proceso involucra a otra persona, docx es difícil de evitar. «Word» en este artículo también cubre herramientas comparables que pueden leer y escribir docx — LibreOffice Writer, Apple Pages, Google Docs, WPS — su modelo de colaboración y los límites de docx son compartidos.

Catalpas Atelier Scribe no pretende reemplazar a Word, ni intenta competir directamente con las funciones de colaboración de Word. En este proceso, Scribe posee «el lado del autor: prosa y libro terminado», y Word, en el lado del editor, posee «comentarios, revisiones, gestión del proceso». Ambos lados intercambian el manuscrito a través de docx. La pregunta no es «qué herramienta» — es «cuándo entrego el manuscrito a docx, y cuándo lo recupero».

La realidad: los colaboradores solo aceptan docx

Para los autores independientes, aceptar esto es más barato que luchar contra ello. Incluso cuando el editor con el que trabaja tiene inclinaciones técnicas y en principio podría leer Markdown, para cuando está realmente en la fase de revisión, lo que necesita no es capacidad de lectura — es todo el ritual de colaboración de Control de cambios + Comentarios construido alrededor de Word. Markdown no tiene un sistema de revisión visual igualmente maduro. Los marcadores de CriticMarkup pueden funcionar dentro de un círculo pequeño, pero no pueden proporcionar «quiero que mi editor adquirente lea todas las revisiones de mi libro en dos horas».

Por lo tanto, el flujo de trabajo realista suele verse así: escribe el cuerpo en Scribe, organiza los capítulos y hace revisiones locales; cuando el manuscrito necesita una pasada de revisión, exporta un docx; la otra persona lo trabaja en Word (o LibreOffice, Pages, Google Docs) con Control de cambios y comentarios, y luego lo devuelve; usted vuelve a Scribe y «traduce» sus revisiones de vuelta al cuerpo. Cada intercambio implica una conversión de formato, por lo que la pregunta es: cómo hacer esa conversión lo más barata posible.

El puente docx: qué cruza, qué se pierde

Cuando Scribe exporta un docx (y cuando importa un docx revisado de otra persona de vuelta a Scribe), vale la pena conocer de antemano el destino de varios tipos de contenido.

La estructura y los encabezados de capítulo se mantienen relativamente fieles — la correspondencia de Título 1 / Título 2 es estable en ambos lados. Eso significa que cuando alguien reordena capítulos o renombra encabezados en Word, Scribe lo recogerá al regresar.

Los párrafos del cuerpo y el formato básico (negrita, cursiva, citas en bloque) también sobreviven al intercambio. Pero el espaciado entre párrafos, la altura de línea y el tamaño de fuente son propiedades que controla la maquetación a nivel de proyecto de Scribe — no deberían ajustarse manualmente en docx. Una vez que se ajustan, serán sobrescritos por la maquetación de Scribe al regresar o crearán inconsistencias locales. Cuando entregue el docx, dígale al editor explícitamente: «Por favor, cambie solo el texto y la estructura — la maquetación está unificada en mi lado».

El Control de cambios es lo más valioso de este proceso — le dice exactamente qué párrafo se editó, qué se añadió, qué se eliminó, por quién y cuándo. En el lado de Scribe, guarde el docx devuelto como «archivo de referencia», recorra las revisiones una por una, decida aceptar/rechazar y aplíquelas manualmente dentro de Scribe. No intente una fusión automática — ninguna herramienta preserva actualmente el control de cambios sin pérdidas a través de un intercambio Markdown ↔ docx, y los pocos minutos que ahorre al principio no cubrirán el tiempo que pasará solucionando problemas después.

Los comentarios son similares — trate los comentarios del docx como una «lista de tareas» en el lado de Scribe, trabájelos, edite la prosa en Scribe y archive el docx original cuando termine. Los comentarios no necesitan — y no deberían — vivir en el proyecto de Scribe junto al cuerpo.

Lo que se pierde: tablas complejas, objetos incrustados (fórmulas, gráficos, SmartArt), cuadros de texto, estilos personalizados. La mayoría de los manuscritos de ficción no usan estos elementos. Si está escribiendo no ficción con muchas figuras, necesitará acordar con el editor desde el principio: «deje las figuras en paz por ahora, revise solo la prosa», para evitar tener que reinsertar figuras en cada ronda.

Control de versiones en las rondas de revisión

Cuando hace dos o tres rondas de revisión de ida y vuelta, la nomenclatura de archivos y el archivo importan más de lo que parece. Un enfoque fiable:

• Al exportar de Scribe al editor: nombre-libro_v0.3-para-editor_AAAA-MM-DD.docx
• Cuando el editor lo devuelve: nombre-libro_v0.3-de-editor_AAAA-MM-DD.docx
• Después de terminar el procesamiento, aumente la versión en el proyecto de Scribe a v0.4 y comience la siguiente ronda

El objetivo no son nombres de archivo bonitos — es que en cualquier momento pueda responder «¿qué versión tiene el editor ahora?» y «¿hay deriva de versiones entre nosotros?». La versión más reciente de la prosa siempre vive en el proyecto de Scribe — los archivos docx salientes son instantáneas, los archivos docx entrantes son instantáneas con comentarios, pero ninguno es la fuente de la verdad.

Segunda regla: cuando llegue la devolución del editor, no se sumerja en Scribe de inmediato. Lea primero el docx devuelto, tome una decisión sobre cada revisión y comentario (aceptar / rechazar / discutir), luego lleve las decisiones de vuelta a Scribe en un lote. Esto es mucho más rápido que «leer docx y editar Scribe al mismo tiempo», y reduce la deriva de versiones.

Cuándo dejar el lado de Word: el conocimiento se asienta de vuelta en Markdown

Un último punto de decisión: ¿cuándo debería dejar de pasar por el puente docx?

Si se está autoeditando y todavía está en la etapa de borrador personal, no necesita la primera ronda en absoluto — escriba hasta el final en Scribe, reléase usted mismo, revise, publique EPUB y PDF de imprenta. docx solo vale su costo cuando «necesita que otra persona mire el manuscrito y acepte sus cambios».

Si ya ha hecho dos o tres rondas de revisión sustantiva y de corrección de estilo, la etapa final de cierre debe volver completamente al lado de Scribe: a partir de aquí, cada cambio ocurre solo dentro del proyecto de Scribe, sin más «enviar otro docx para que alguien lo apruebe». Cada intercambio introduce un poco de riesgo de formato y maquetación, y en la etapa previa a la impresión no hay razón para seguir asumiéndolo.

¿Cuándo debería saltarse Word por completo? Cuando el colaborador mismo acepta la colaboración en Markdown (un pequeño número de editores con inclinaciones técnicas, grupos de coescritura muy unidos) y no depende del ritual de Control de cambios — en ese punto puede comunicar los cambios a través de git diff o la comparación de versiones integrada de Scribe, más ligero que los intercambios de docx. Pero evalúe honestamente los hábitos reales de la otra persona. No deje que «ojalá usaran Markdown» anule «así es como trabajan realmente».

Abra Scribe para ver cómo se combina con el flujo de trabajo docx de su editor/colaborador →

También le puede interesar leer

• El centro de colaboración de Scribe — el punto de entrada para flujos de trabajo con otras herramientas de escritura, toma de notas y revisión
• Scribe frente a Microsoft Word: comparación lado a lado — si prefiere empezar desde una comparación de herramientas