Creamos un traductor de documentos que no rompe el formato (y por que llevo mas tiempo de lo esperado)

Hay un tipo muy concreto de frustracion que cualquiera que trabaje con documentos conoce demasiado bien. Pasas horas dejando una propuesta limpia. Los encabezados estan alineados. Las tablas se ven bien. El espaciado entre bloques transmite orden. Luego pasas ese archivo por un servicio de traduccion, descargas el resultado y de pronto todas las decisiones cuidadas sobre estructura desaparecen. Los titulos se mueven, las celdas colapsan, las imagenes saltan a lugares raros y los saltos de linea se multiplican sin motivo. El documento traducido contiene tus palabras en otro idioma, si, pero ya no se siente como tu documento.

Mucha gente acepta ese dolor porque casi todas las alternativas son peores. Puedes contratar una traduccion manual y esperar dias. Puedes copiar y pegar texto por bloques y rehacer el layout a mano. Puedes pagar herramientas caras que prometen respetar el formato y aun asi devuelven artefactos raros. Normalmente solo eliges la opcion menos mala.

Nosotros decidimos que eso no bastaba. No porque persigamos la perfeccion, sino porque nos encontramos con este problema demasiadas veces. CSS-Zone esta hecho para gente que se fija en los detalles. Nuestros usuarios son disenadores, developers y autores tecnicos que notan cuando un radio de sombra esta dos pixeles fuera de sitio. Por supuesto tambien notan cuando un documento traducido vuelve con el aspecto de haber pasado por una trituradora de texto. Si ibamos a lanzar un traductor dentro de CSS-Zone, tenia que respetar de verdad el trabajo que ya existia en el documento.

El reto tecnico es mas sutil de lo que parece. Traducir no es solo cambiar palabras de un idioma a otro. Es mantener la estructura invisible que hace que el documento siga siendo legible. Esa estructura vive repartida entre XML, estilos, relaciones internas, imagenes embebidas, encabezados, pies de pagina y un monton de piezas que Word conecta de una manera poco amable. Un archivo DOCX no es una pagina de texto. Es casi un pequeño sistema de archivos comprimido en ZIP donde el contenido real esta disperso por varios XML que se referencian entre si.

La solucion ingenua consiste en sacar todo el texto, traducirlo y volver a meterlo. Eso sirve si solo te importa ver palabras traducidas en pantalla. Falla en cuanto te importa algo mas. El negrita se pierde. La cursiva desaparece. Las tablas se rompen. Las listas se convierten en parrafos planos. Los encabezados y pies dejan de existir. El archivo sigue siendo “un documento”, pero ya no es el mismo documento.

Dmytro Hulak
Founder & CEO of CSS-Zone

"La mayoria de traductores trata el formato como decoracion opcional. Nosotros lo tratamos como la estructura que hace util un documento."

Esa fue la idea central del desarrollo. El formato no es maquillaje. Es informacion. Cuando una palabra va en negrita dentro de un contrato, no es por estetica: estas marcando importancia. Cuando un manual usa una lista numerada, no esta adornando el contenido: esta indicando una secuencia que alguien necesita seguir bien. Cuando una tabla financiera esta alineada, no se ve bonita por casualidad: permite comparar datos de un vistazo. Si todo eso se pierde al traducir, no solo se pierde estilo. Se pierde claridad.

La primera version de nuestro traductor fue demasiado simple. Usamos JSZip para abrir el DOCX, encontramos el XML principal, extrajimos nodos de texto, los mandamos a un modelo de IA y los escribimos de vuelta. Funcionaba en el sentido minimo de producir salida. En todo lo demas fallaba. Parrafos fusionados, estilos rotos, imagenes convertidas en placeholders absurdos. Teniamos que ver fracasar esa version para entender donde estaba la complejidad real.

El problema de fondo no era sacar texto. Era conservar la relacion entre contenido y estructura. Un DOCX no guarda el formato en linea como HTML. Lo guarda en definiciones de estilo aparte y luego lo referencia mediante IDs. Si quieres que un parrafo siga en negrita despues de traducir, no basta con recordar que estaba en negrita. Tienes que mantener el ID del estilo, comprobar que siga existiendo en la salida y reconectar todo bien. Lo mismo aplica a tablas, imagenes, headers, footers, hipervinculos y marcadores.

Las imagenes fueron especialmente molestas. Word no las inserta “dentro” del texto de forma simple. Crea archivos separados dentro del paquete DOCX, genera relationship IDs y guarda metadatos de posicion y tamaño. Traducir el texto de alrededor es facil. Mantener la imagen en el mismo sitio, con el mismo tamaño y la misma relacion interna fue otra historia. Tuvimos que reescribir esa parte varias veces antes de dejarla estable.

Las tablas fueron incluso peores. No son cuadrículas limpias. Tienen celdas combinadas, tablas anidadas, bordes condicionales, paddings especificos y anchos dependientes del margen de pagina. Cuando traduces el contenido de una celda, el largo del texto cambia. Una frase corta en ingles puede convertirse en algo bastante mas largo en espanol o aleman. Si no ajustas el ancho con un minimo de inteligencia, la tabla se rompe o queda forzada. Terminamos construyendo una pequena logica de recalculo que estima la longitud del texto traducido y reajusta el espacio.

Los encabezados y pies de pagina son conceptualmente simples pero tecnicamente traicioneros. Viven en XML separados y dependen de relaciones internas. Si traduces el contenido pero te olvidas de una referencia, Word puede abrir el archivo mal o directamente mostrar un error. Perdimos demasiado tiempo persiguiendo esos fallos porque en previsualizacion todo parecia correcto, pero Word fallaba por un enlace interno perdido en los archivos de relaciones del documento.

La parte de IA fue casi facil comparada con todo eso. Usamos Gemini para la traduccion. El prompt es claro: conservar etiquetas, mantener formato, traducir solo el texto y respetar el tono. Para documentos de negocio y materiales tecnicos, el resultado es lo bastante bueno como para trabajar de inmediato sin limpieza manual pesada. Eso era mas importante para nosotros que “sonar inteligente”.

Tambien anadimos deteccion automatica del idioma para reducir errores humanos. Si alguien sube un documento en ruso pero marca por accidente otro idioma de origen, el resultado puede quedar destrozado. La deteccion no es perfecta, pero evita gran parte de esos fallos tontos. Y si hace falta, el usuario siempre puede corregir el idioma manualmente.

La cuota gratuita esta pensada para ser util, no decorativa. Cinco documentos al dia cubren un uso casual razonable. Si alguien traduce contratos, propuestas, guias o informes todo el tiempo, entonces el plan Pro tiene sentido porque ofrece uso ilimitado. No queriamos convertir esta herramienta en un muro artificial; solo necesitabamos un limite que evitara abuso y mantuviera el coste del servicio bajo control.

Tuvimos otra discusion importante: si debiamos soportar PDF desde el primer dia. El problema es que PDF es un formato hostil para editar. Sirve para mostrar, no para conservar estructura reutilizable. Extraer texto es posible. Mantener layout de forma fiable es muchisimo mas dificil. Por eso empezamos con DOCX: es editable, se usa de verdad en contextos profesionales y su estructura, aunque incomoda, es trabajable.

Otra decision consciente fue no llenar la herramienta de opciones. Pudimos anadir controles para tono, formalidad, variantes regionales, glosarios, logs, revisiones y flujos colaborativos. Pero cada opcion nueva es una decision extra antes de recibir valor. Recortamos el flujo al minimo: subir documento, elegir idioma de destino, traducir.

El resultado es una herramienta que hace una sola cosa bien. Subes un DOCX. Se traduce manteniendo el formato. Descargas el archivo y sigues trabajando. No es magia y todavia hay edge cases: tablas complejas, fuentes muy personalizadas o documentos con macros pueden dar problemas. Pero para la mayoria de propuestas, manuales, contratos y materiales de trabajo, el resultado ya es util de inmediato.

Construir esta herramienta tambien obligo a mejorar la infraestructura general. Tuvimos que reforzar procesamiento en servidor, manejo de errores, colas y estabilidad del backend. Ese trabajo no solo mejora el traductor. Tambien hace que el resto de CSS-Zone sea mas solido.

El traductor ya esta en marcha en css-zone.com/document-translator. Soporta doce idiomas y la interfaz tambien esta localizada, porque no tenia sentido pedirle a alguien que traduzca documentos importantes mientras navega una UI en un idioma que no domina.

No es la feature mas vistosa que hemos sacado. Probablemente tampoco sea la mas “viral”. Pero resuelve un problema real y lo hace sin pedirle al usuario que sacrifique el trabajo que ya habia invertido en el documento. Eso, para nosotros, ya justifica haber tardado mas de lo previsto.

Si traduces documentos con frecuencia y ya estas harto de que romper el layout parezca el precio obligatorio del trabajo multilingue, pruebalo. Y si encuentras casos raros o formas de romperlo, mejor: eso nos da material real para seguir afinandolo.