Traducción de un libro a 12 manos: mis conclusiones (y III)

Cierro el ciclo de posts sobre el proyecto de traducción poss-gl con mis conclusiones personales. Finalizo así la serie iniciada contando los procesos e infraestructura del proyecto y las tareas de cada uno de los roles implicados.

Luego de las dos primeros post donde hablaba de la infraestructura del proyecto y el día a día de las personas implicadas, toca hacer balance. Y esto es necesariamente subjetivo. Es mi visión. Otros miembros del proyecto pueden tener otra distinta.

Nuestro principal logro ha sido reunir a 12 personas que no habían trabajado previamente juntas, para traducir al gallego un libro en 1 año.

Si bien la traducción del libro en sí misma es algo que me emociona y lo que unía al grupo, a nivel personal, me quedo con todo lo que he aprendido: crear, coordinar y participar un proyecto online con gente diversa. Esto ha sido una gozada. A continuación siguen algunas reflexiones:

Liderazgo y participación a lo largo del proyecto

En nuestro caso, el proyecto tuvo 3 fases claras: los inicios, la traducción y el proceso final de edición.

Durante el impulso inicial, Pablo Sanxiao, Francisco Puga y yo mismo -con la colaboración de Adrián Chapela- estuvimos poco más que montando toda la infraestructura necesaria para dar soporte al proceso y hablando, entre cerveza y cerveza, de cómo queríamos que fuese. Aquí las tareas estaban bastante difusas y los conocimientos para realizarlas eran bastante técnicos. Contaban más nuestras ganas por construir algo colaborativo que nuestra experiencia. En esta fase, el liderazgo fue bastante compartido, y estuvimos elaborando el proyecto y dando los primeros pasos a nuestro modo. Fue todo muy sencillo porque éramos pocos. Que las tareas fuesen muy técnicas y estuviesen difusas no nos permitía agregar a más gente alrededor.

A continuación, durante la etapa de traducción, el trabajo se distribuyó entre diversas personas (hasta un total de 12!). La impresión en esta etapa es que las tareas estaban mucho más claras y requerían menos conocimiento especializado: consistía en traducir una de las partes del libro. Es verdad que, en la mayoría de los casos, la traducción se hacía usando gtranslator -un programa muy especializado de traducción de cadenas- pero su uso es muy intuitivo. Además, aquellos traductores que lo desearon, enviaron sus contribuciones en archivos ODT. Esta flexibilidad favoreció la participación de mucha gente en el proceso. El liderazgo aquí estuvo también repartido: por un lado, yo me encargaba de ver que todo el mundo tuviese cosas que hacer y que los nuevos supiesen por dónde empezar, dividiendo y sugiriendo deadlines y tareas. Por el otro, el enorme esfuerzo de los que traducíamos -principalmente Roberto Vieito- “señalizaba” al grupo y a los nuevos que existía voluntad y actividad alrededor del proyecto. Esto sin duda era igual de importante: nadie desea participar en una comunidad que está muerta.

En la fase final, las tareas volvieron a estar más difusas y se iban realizando a medida que las detectábamos. En nuestro caso, además, coincidió que esta etapa tenía mucho de contactar con proveedores, lidiar con subvenciones, etc. De nuevo liderazgo compartido: Roberto Vieito tiró del equipo realizando todas las tareas de contacto con proveedores y spónsors, demostrando un compromiso increíble con el proyecto. Por mi parte, me encargué de dividir el trabajo restante en tareas pequeñas, asumibles por cualquiera que lo desease, además de llevar a cabo las tareas de integración derivadas de ese “cortar en pedacitos” el proyecto. Y aquí -en las tareas de edición- conseguimos de nuevo una alta participación.

Qué he aprendido?

  • Cuando existen tareas claras y delegables es posible agregar a más gente en torno a tu idea. Desconozco la razón concreta. Pero mi inclino a pensar que simplemente uno tiene gratificación más temprana del trabajo hecho, que es el único pago que uno obtiene de las tareas voluntarias, el único combustible de la participación voluntaria.
  • Feedback. Disponer de mecanismos, herramientas y procesos de señalización que indiquen las tareas concretas a realizar y muestren el avance del proyecto me parecen imprescindibles. Viéndolo a posteriori, en nuestro caso creo que funcionó muy bien el timeline de avance de cada capítulo. Esto estaba tanto en la web pública como en un hilo de la lista de correo donde se iba actualizando 1) quién era el responsable de la tarea y 2) el porcentaje de completitud. Esto ayudaba -tanto a nivel público como interno- a saber dónde se podía echar una mano. También la lista de correo donde íbamos comentados cualquier cosa. El feedback, además, ayudaba a que los voluntarios recibiesen gratificación directa y rápida por su trabajo.
  • No todo el mundo colabora en el proyecto de la misma manera. Cada uno ha aportado en la medida de sus posibilidades. Hay gente que ha dedicado un par de días al proyecto, otros han traducido capítulos completos, y luego están los que han tirado del carro en momentos críticos asumiendo un gran porcentaje del trabajo. Es normal que esto ocurra, sobre todo en un proyecto donde el 100% de la gente es voluntaria. Los participantes, bien sea por interés personal, circunstancias temporales, etc se vuelcan en unas tareas u otras: el voluntariado no es una fábrica donde la gente trabaja gratis, sino una fiesta donde cada uno viene y va según sus circunstancias. Ser consciente de ello es primordial para que el proyecto no muera. Una actitud positiva con todas las contribuciones es necesaria.
  • Eventos offline. En cada una de las “crisis” (o no-avances) del proyecto tuvimos una xantanza, una comida de trabajo y confraternización. Para mí, estos fueron los momentos más divertidos. Ese cara a cara, me ayudó a superar esas mini-crisis de fé que siempre a uno le vienen, además de la enorme cantidad de trabajo que se hizo, claro. Posteriormente a esos eventos, la actividad online fue también más intensa. Sin planificarlo previamente, ésta fue de las mejores ideas que tuvimos.
  • El liderazgo es compartido y evoluciona según la energía de cada uno y el tipo de tareas a realizar. En nuestro caso, se puede comprobar claramente con la emergencia del liderazgo de Roberto Vieito -que no había participado en la fase inicial- convirtiéndose al final en una de las personas más importantes para el proyecto. Quizás por ello, para facilitar este cambio de líderes según las necesidades, las estructuras de coordinación y gobierno de proyectos con voluntarios son (y deben ser) flexibles, para dejar que los líderes en cada etapa hagan su trabajo.
  • Dejar hacer a quien lo ve claro. Para el libro, conseguimos contar con invitados de lujo en el proyecto: Karl Fogel, Suso de Toro y Yolanda Castaño. Uno de ellos me hace especial ilusión: el poema de Yolanda Castaño. Tengo que reconocer que nunca lo vi claro, tenía muchas dudas: no confiaba en que se pudiese hacer un poema sobre el software libre, no tenía claro que Yolanda fuese la persona ideal para llevarlo a cabo, … Sin embargo, Roberto y Nacho estaban convencidos. Y Roberto lo intentó. Mi posición aquí, fue de mantenerme al margen. No creía que saliese bien, pero en ningún momento transmití eso y les dejé hacer. ¿El resultado? «O corgo volveuse fonte», un poema precioso sobre el software libre (Gracias Yolanda!!). Lección aprendida: si no lo ves claro, apártate, y no dinamites los intentos de otros.
  • Identifica y elimina cuellos de botella. Nosotros no lo hicimos. El proyecto dependía de mí para integrar las contribuciones y, en unas semanas donde tuve mucha carga por otros lados (trabajo, estudios, asuntos personales, …) no pude mantener el ritmo que exigía la comunidad en torno al proyecto. Esto fue sin duda una fuente de retrasos. Por suerte lo superamos. Pero viéndolo en retrospectiva me hubiese gustado haber delegado y compartido las tareas de integración.

En resumen: si le das autonomía, herramientas y confianza a la gente, ésta te sorprende. Gracias a todos por participar y traducir al gallego un libro tan importante como éste!

Traducción de un libro a 12 manos: personas y tareas (II)

Segundo post sobre el making-of del proyecto poss-gl. Si el primero contaba los procesos e infraestructura detrás del proyecto, éste versa sobre las personas y su día a día.

Si en el anterior capítulo se explicaban las bases que ideamos para dar soporte al proyecto, en éste explicaremos el día a día de los roles que participaron en el proyecto.

Programación/infraestructura

Estas tareas fueron realizadas en una primera etapa. Básicamente consistió en:

  • tener una web que mostrase estadísticas del avance de la traducción: se escribieron unos scripts en python y bash que me permitían generar las gráficas y mantenerla actualizada de un modo muy sencillo.
  • configurar la lista de correo y programar la web.
  • otros scripts para tareas varias: sacar información de los xml y generar los po, …

Traducción

Los traductores fueron los verdaderos héroes del proyecto. Hasta 12 personas que no se conocían previamente trabajando colaborativamente sobre un mismo texto. Impresionante. Cada uno de ellos, además, usó las herramientas que mejor se adaptaban a su perfil:

  • la mayoría traducían usando gtranslator y archivos PO
  • otros con herramientas ofimáticas como openoffice, generando archivos ODT

El proceso fue coordinado todo por la lista de correo. Se envió una lista inicial de capítulos y cada uno fue cogiendo el que más le apetecía. A medida que se unía más gente al proyecto o se acababa un capítulo, cogías el siguiente. Este proceso “on-line” lo complementamos con algunas quedadas presenciales -nuestras xantanzas!– donde, además de traducir, comíamos juntos, veíamos la fórmula1 o nos echábamos unas risas.

Integración

Mi rol como integrador consistía en mantener actualizada la última versión de los contenidos, donde centralizábamos las últimas versiones. Mis tareas eran dos:

  • Velar porque con cada nueva integración no se perdiesen los cambios anteriores.
  • Introducir en el sistema las aportaciones de traductores que nos enviaban archivos ODT, no en formato PO. Un copy-paste no muy agradecido, pero que aseguraba que el número de traductores podría ser mayor (ya que no tenían que saber usar git ni gtranslator).

Revisión del texto

Evidentemente, un texto traducido a 12 manos no tiene una voz única. Para tratar de hacer que no se notase demasiado esa disparidad, tomamos una serie de medidas:

  • Aunque no realizamos un glosario estricto, la lista de correo servía para compartir por la lista de correo dudas y reglas generales de traducción.
  • El texto final fue revisado por Roberto Vieito en un maratón de 3 días una vez acabamos. Yo lo leí también en diagonal para detectar errores garrafales. Además, con el libro impreso, volvimos a echarle una ojeada.
  • Como no nos parecía suficiente, contratamos a un traductor jurado por la consellería de educación para hacer posteriormente la tarea general de unificación de estilo y corrección de grandes errores. Por suerte para nosotros, este traductor, Juan Álvarez, también había sido participante como voluntario en el proyecto, por lo que ya lo conocía internamente.

Maquetación

Una vez traducido y revisado 100%, generamos el archivo ODT y tocaba ponerlo bonito para la imprenta. Hicimos una llamada a la participación en la lista de correo del proyecto y nos pusimos a maquetar: de nuevo, cada uno se asignaba un capítulo y lo anunciaba por la lista de correo. Lo importante de este proceso para mí fue que teníamos unas normas claras y aplicables de modo sencillo. Como bases usamos las opciones que vienen por defecto en openoffice: títulos iban con el encabezado 1, los subtítulos con el 2, etc. Esto permitió que un proceso tedioso y tendente a errores fuese … un poquito menos tedioso y tendente a errores 🙂 La revisión final que hicimos sobre el texto completo arrojaba fallos mínimos que pude corregir yo mismo sin dedicarle mucho tiempo a mayores.

Gestión de los proveedores

Gracias a la subvención que conseguimos de la Xunta de Galicia así como la financiación que nos aportó la empresa Igalia, pudimos abordar cosas como: diseñar una web en condiciones, imprimir varias decenas de libros o contratar a un revisor jurado por la xunta para darle un repaso y un poco de coherencia al texto.

Para el proyecto supuso un reafirmación de que estábamos haciendo las cosas bien, pero también una carga con tareas no muy agradecidas: presentar subvenciones, seguimiento de proveedores, justificación, etc consumen un valioso tiempo, que fue necesario realizar. Por suerte, y gracias al empeño y desempeño de Roberto Vieito logramos hacerlo de un modo excelente.

Resumen

A grandes rasgos, así funcionábamos. Se podría decir que existimos a través de la lista de correo, que servía a la vez de local social, tablón de anuncios y teléfono de emergencia. Nos dotamos además de procesos e infraestructura sencillo, enfocados a no molestar en la tarea principal: traducir colaborativamente el proyecto.

Traducción de un libro a 12 manos: los inicios (I)

De cómo traducimos al gallego el libro “Producing Open Source Software”, de Karl Fogel. Los primeros pasos.

Estos días estamos cerrando el proyecto poss-gl: tenemos nueva web y los libros impresos están de camino. Ha sido un año y medio donde 12 personas hemos colaborado en distintas fases de la traducción al gallego del libro “Producing Open Source Software”, de Karl Fogel. El grupo nunca antes había trabajado junto y muchos no se conocían entre sí. Ésta es la historia de cómo nos organizamos para traducir un libro a 12 manos.

Los inicios: herramientas y procesos de participación

De los inicios, recuerdo una pregunta que iba y venía siempre en las conversaciones: “y cómo lo organizamos para que sea sencillo colaborar?“. Cuando ideamos el proyecto, teníamos claro que no podíamos hacerlo sólos y que necesitaríamos colaboración. Pero ésta tenía que ser ordenada: por nuestra cabeza, como una pesadilla, navegaba la imagen de un documento de texto con múltiples versiones enviado de un correo a otro entre cada uno de los traductores. Por suerte, teníamos experiencia trabajando al modo del software libre, con procesos y herramientas de comunidades virtuales. Y decidimos intentarlo.

  • Para empezar, partimos de una buena materia prima: el autor original del libro, Karl Fogel, lo había troceado previamente en capítulos y formateado en XML, lo que nos permitía adaptarlo automáticamente a nuestras propias necesidades.
  • Tomamos la decición de que el formato PO fuese la unidad base sobre la que trabajaríamos, aunque daríamos soporte al menos también para archivos ODT (para aquellos traductores que deseasen usar openoffice en vez de las herramientas de traducción habituales en el mundo del software libre) .
  • Decidimos que centralizaríamos los avances del proyecto en un repositorio central de información, de cara a evitarnos la pesadilla de los mails cruzados.
  • Lo anterior, de algún modo nos empujó a crear el rol de integrador: la persona técnica que ayuda a los traductores a integrar su trabajo en el repositorio central (por ejemplo, pasando de ODT a PO) y se encarga de mantenerlo actualizado. Imaginamos que no todos los traductores tendrían experiencia en el trabajo con repositorios, así que nos parecía lo más adecuado de cara a garantizar que en el proyecto participase gente del mundo de la traducción y no sólo programadores del mundo del software libre.
  • Posteriormente, trabajamos por portar a windows la herramienta gtranslator, que permite la edición sencilla de archivos PO. Aunque todos nosotros trabajamos con sistemas GNU/Linux, no queríamos cerrar la puerta a otra gente. También creamos un sencillo manual de usuario para hacer más fácil los comienzos.
  • Consideramos que una de las cosas importantes era poder ver la evolución del proyecto, los avances. Tanto para alguien que se interesara desde fuera, como para nosotros mismos, como aliciente. Para ello, creamos una web sencilla donde se podía vez el estado de completitud de cada capítulo. Con un pequeño programilla, de modo automático, extraíamos la información de los archivos PO y la publicábamos en web. Era realmente motivador ver cuándo un capítulo se acababa 🙂
  • Necesitábamos además una herramienta de comunicación para todo el grupo, nuestra “ventanilla única”: para ello instalamos una lista de correo a la que estaban suscritos todos los traductores. Nuestra idea era que sirviese como foro de dudas, comunicación de quien estaba haciendo qué, etc.

Cuando acabamos de hacer todo esto era casi Septiembre de 2009. Teníamos el proceso para colaborar y las herramientas listas. Dividimos el libro por capítulos y empezamos a publicitar el proyecto por algunas listas de correo “amigas”. Tocaba empezar a traducir.