El objetivo inmediato de esta serie de artículos es lograr la incorporación de voluntarios a los equipos de traducción, vamos a conocer estos equipos un poquito más de cerca. Por Juan Rafael Fernández García.
| Historial de versiones | ||
|---|---|---|
| Revisión 0.1 | 2007-04-01 | jrf |
| Primera versión CC 2.0 del artículo de Linux Magazine. | ||
Está usted leyendo Cerrando el ciclo, quinto de una serie de cinco artículos sobre la traducción en el mundo del software libre publicado por primera vez en el número 23 de la revista Linux Magazine, de enero de 2007 (pero escrito en noviembre de 2006). La versión pdf del artículo puede descargarse en el enlace http://www.linux-magazine.es/issue/23/.
La versión «canónica» del artículo, la única mantenida por el autor, se encuentra en http://people.ofset.org/jrfernandez/edu/n-c/traducc_5/index.html. Está publicada por contrato con la editorial bajo licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.0 (-sa-by-nc 2.0).
Índice de la quinta parte
I. Apuntes para una conclusión técnica
II. Conclusión personal
III. Conclusión práctica: ¿por dónde empezar, entonces?
IV. Y en el próximo número...
Cuadro 1: Los grupos de traducción
Imágenes
Notas
Una oPOrtunidad de colaborar
(Primera parte del artículo)
Los problemas de PO y el abrazo fuerte
(Segunda parte del artículo)
Memorias compartidas
(Tercera parte del artículo)
¿El momento de cambiar de herramientas?
(Cuarta parte del artículo)
Durante cuatro entregas hemos analizado las herramientas y la tecnología disponible en el mundo de la traducción libre. Es el momento de volver a tierra después del detallado examen de propuestas, de mirar al traductor, de preguntarnos cómo se relaciona con el resto de traductores y con los desarrolladores, y sobre todo cómo asume la tarea que se impone, cómo se incorpora a un grupo y cómo trabaja en su interior.
Nos habíamos reservado para la entrega final de la serie el análisis de los distintos papeles (traductor, revisor, responsable de equipo) posibles en el sistema y de cómo se enfrentan los equipos al problema del control de calidad del proceso.
¿Cómo se coordinan los equipos? Tradicionalmente los grupos de traducción tienen su sitio web, con un objetivo informativo y para la captación de nuevos traductores; estas webs suelen incluir además una interfaz para el seguimiento del estado de las traducciones y otras estadísticas. Se comunican y plantean dudas y debates en listas de correo específicas. Definen normas de estilo y glosarios para la unificación de estilo y de terminología[1], pero no utilizan herramientas especializadas que fuercen o faciliten su utilización. Los ficheros traducidos suelen guardarse con un sistema de seguimiento de versiones (cvs o svn), aunque no en todos los proyectos todos los traductores tienen permiso de escritura en él (es habitual que los ficheros se envíen por correo a la lista).
Creo que son necesarios algunos ejemplos para ilustrar el resumen anterior. En la figura 1 tenemos una captura de distintos correos procedentes de las listas de traductores. ¿De qué se habla en estos correos? Se reservan traducciones, se piden revisiones, se plantean dudas y se acuerdan normas, etc.
A: debian-l10n-spanish@lists.debian.org Asunto: Re: Saludos > He leido la pagina http://www.debian.org/international/spanish/ y no he > acabado de entender el funcionamiento así que si algún coordinador desea > ayuda que me lo diga y comenzaré por ahí. Muchas gracias Bueno, pues haremos una cosa. Como necesitamos ayuda en varios frentes, vamos a ponerte a traducir páginas web del sitio de Debian.
O
A: debian-l10n-spanish@lists.debian.org Asunto: El dardo en la palabra: «A nivel de». Aquí van otras que casi con toda seguridad hay que reescribir: http://www.google.es/search?hl=es&q=%22a+nivel+de%22+site%3Awww.debian.org Salvo cuando se trata específicamente de niveles (y eso casi nunca sucede), hay que utilizar expresiones como «según» o «grado de».
O bien
A: Lista para el apoyo a la traducción de software <spanglish@uma.es> Asunto: [Spanglish] courseware Me podrían confirmar si "programa o software didáctico" es la traducción usual de la palabra del asunto. En francés "didacticiel".
Y las respuestas propuestas (y discutidas) en el hilo: material de estudio o material didáctico; sistema de administración de cursos; material, programa o software educativo; software didáctico. A propósito, la lista Spanglish[2] es un recurso excepcional para un traductor.
¿Y el reparto de tareas? Se reparten en las listas de correo (aunque las asignaciones se puedan seguir mediante la interfaz web, como en la figura 2). Y normalmente los traductores no tienen acceso al almacén de traducciones; es el coordinador o un número reducido de responsables los que tienen cuentas cvs o svn.
Se han desarrollado varios robots para mejorar el proceso. Un ejemplo sería el robot del Proyecto de traducción libre, que se encarga de comprobar la corrección de la cabecera y de la sintaxis de los ficheros PO enviados (ya lo hemos descrito en varias ocasiones en esta serie)[3]. No hay que explicar que un correo a la lista es@li.org, remitente Translation Project Robot <translation@iro.umontreal.ca>, y con hello-2.1.96 (94%, 2 untranslated) como tema nos está informando a los miembros del equipo español que el robot ha recibido y aceptado el fichero PO correspondiente al programa hello, versión 2.1.96, traducido en un 94% de sus cadenas, y que el fichero en ese estado ha sido añadido al almacén de ficheros PO que aloja el Proyecto de Traducción.
Otro ejemplo destacable es el robot utilizado por el grupo de traducción al castellano de Debian; el robot, creado por Ricardo Javier Cárdenes Medina y puesto en funcionamiento en febrero de 2004[4], procesa mensajes como el siguiente
Subject: [ITT] po-debconf://exim4
que equivaldría a decir
Me hago cargo de la traducción po-debconf de exim4
[ITT] po-debconf://exim4 es un ejemplo de pseudo-url. Los pseudo-urls son el texto que se incluye en el asunto del mensaje para que el robot pueda discriminarlo del resto del tráfico en la lista. Tienen el siguiente formato:
[(ITT|RFR|RFR2|LCFC|BTS#<num_bug>)] (po-debconf|po|debian-installer|man|wml)://<name>
El estado (entre corchetes) puede ser ITT (Intent To Translate, Intención de traducción), RFR (Request For Review, Solicitud de revisión), ITR (Intent To Review, Intención de revisión), LCFC (Last Chance For Comment, última oportunidad para enviar comentarios). El tipo puede ser po-debconf (para plantillas de debconf), debian-installer (para partes del instalador), po, man (para páginas de manual) o wml (para ficheros plantilla del servidor de web).
¿Para qué sirve este sistema frente al uso del lenguaje natural? Para permitir la comunicación entre traductores en la lista y además que el robot pueda elaborar estadísticas del estado del ciclo de traducción: automáticamente se puede comprobar si un fichero ha sido traducido o no, si ha sido revisado (figura 3)... Sin embargo, a diferencia del robot del FTP, este robot no se encarga de subir el PO al almacén de traducciones completadas; serán los desarrolladores Debian con permisos suficientes los que podrán hacerlo.
El experimento de una serie larga de artículos, pese a sus inconvenientes (el director se pone nervioso, ¿no estaremos perdiendo el tono periodístico con tanta profundización?), tiene también sus ventajas; la primera es que el desarrollo, que no se detiene, se hace perceptible. Dos ejemplos: gtranslator renace de sus cenizas y tiene nueva versión, la 1.1.7, anunciada el 28 de noviembre de 2006 a la lista gtranslator-list@gnome.org; «Churro», el servidor de internacionalización del proyecto Debian[5], está disponible desde octubre y, entre otras interesantes cosas, aloja un servidor pootle experimental (figura 4; se anunció que también se harán pruebas con transdict).
No obstante la principal ventaja es que cuando escribimos las últimas entregas tenemos ya cierto feedback sobre la recepción de las primeras. ¿Qué nos decían? Entre otras cosas se nos preguntaba (ah el mito de la letra impresa, ¡qué apariencia de autoridad da al que se esconde detrás!) qué tecnología o forma de organización aconsejábamos para un proyecto. Mi respuesta no puede ser otra: depende. Depende del tipo de proyecto, y de las personas implicadas. Si se trata de una traducción puntual, dependerá del formato, y se podrá utilizar la herramienta que haga más fácil el trabajo. Si el número de ficheros es más grande, el proyecto va a tener una continuidad (que exija actualizaciones y permita la reutilización de traducciones) o van a participar varias personas, dependerá de las personas implicadas. Si los conocimientos de la tecnología de la traducción (el tema de esta serie) son homogéneos, y la complejidad del proyecto no es alta, es posible plantearse una organización entre iguales, en la que todos se encargan un poco de todo, de aplicar los filtros de conversión, de tomar decisiones consensuadas en la lista de distribución, de subir las traducciones al repositorio subversion, de publicarlas...
¿Y los proyectos complejos, con miembros que entran y salen, y distintos niveles de conocimiento e implicación? Para estos proyectos es imprescindible una organización jerárquica (meritocrática, of course). En cuanto a las personas es conveniente seguir algunos de los modelos vistos de asignación de tareas, y aplicar procedimientos de control del ciclo nueva traducción — revisión — publicación — actualización — nueva traducción... En cuanto a la tecnología es la oportunidad de poner en práctica las herramientas que ayudan al control del proceso, a la homogeneidad y la calidad del producto. Para un proyecto complejo yo probaría a utilizar un servidor pootle.
En resumen, no creo que el debate sea personas o herramientas. Sintetizando un par de frases, de Christian Perrier y de Bill Clinton, «no son las herramientas, son las personas, estúpido». Si las personas no asumen y siguen un sistema no hay nada que hacer, por eficaces que sean las herramientas para la organización del grupo. Un equipo organizado puede (de hecho ocurre desde hace años) funcionar utilizando herramientas rudimentarias. ¡Incluso hemos trabajado en un proyecto utilizando una moodle! Sin embargo, es la otra cara siempre presente de la realidad, hay herramientas que tienen influencia directa en la calidad y en la fluidez del proceso: una terminología coherente y la reutilización y la armonización de las traducciones que permiten las memorias de traducción, junto con una interfaz que facilite las revisiones y el seguimiento continuo del estado del flujo de trabajo son hoy realidades posibles que deben convertirse en habituales.
Bien, autor de artículos, me rindo: quiero contribuir con mis traducciones. ¿Por dónde empiezo? ¿a quién me dirijo? Bien, en principio tienes nociones sobre el proceso (en esta escena imaginaria me permito el tuteo porque nos acabamos de convertir en compañeros de equipo), conoces suficientemente los dos idiomas y se te ha proporcionado información sobre las herramientas y los recursos disponibles. A partir de este momento también tendrás los datos del cuadro 1. ¿Qué más necesitas? Ah claro, algo que traducir.
Son necesarias unas cuantas precisiones. Sería posible (de hecho no es infrecuente que alguien haga mejoras de una aplicación o de la traducción disponible y se las guarde para sí ¡qué difícil es abandonar los viejos hábitos!) traducir sólo para uno mismo: basta con (1) descargar los fuentes del programa (apt-get source Paquete), (2) traducir, corregir o completar el fichero PO, (3) generar el MO correspondiente
msgfmt -v -c -o NombreDelFichero.mo NombreDelFichero.po
y (4) copiar el nuevo fichero generado en /usr/share/locale/es/LC_MESSAGES/. Pero esto sólo lo vamos a hacer para probar nuestras traducciones antes de compartirlas, ¿verdad?
El siguiente paso es preguntarse si no nos proponemos traducir algo que ya esté traducido. Hay que tener en cuenta el desfase entre las aplicaciones incluidas en la versión de GNU Linux que utilizamos y el trabajo de los desarrolladores y traductores. Por poner un ejemplo actual, los traductores de Gnome tienen prácticamente terminada la versión 2.16 y deben de estar iniciando las de Gnome 2.18; en cambio es fácil que en el escritorio tengamos una 2.10, 2.12 o con suerte 2.14[6]. Si Gnome saca nueva versión cada seis meses, ¡estamos hablando de traducciones de hace un año o año y medio que aún no han llegado a nuestros escritorios!
Otro problema es saber con qué grupo contactar. Que una aplicación esté en Debian, en Guadalinex o en Ubuntu Edgy Eft no significa que sea original de estas distribuciones y haya sido traducida por sus equipos. En primer lugar hay que averiguar si pertenece a los proyectos Gnome o KDE o a algún otro proyecto específico... o si es una aplicación GPL que ha decidido utilizar los servicios del Proyecto de Traducción Libre. o es un proyecto de documentación independiente, o el propio desarrollador se encarga de reunir las traducciones por su cuenta.
Una vez identificado el grupo que ha asumido la tarea de traducir la aplicación, no conviene dirigirse a él para realizar las preguntas realizadas cientas de veces. Es posible que preguntas como ¿cómo se trabaja en este grupo? ¿quién me asigna una traducción? ¿dónde y cómo subo las traducciones hechas? estén respondidas en la página web y/o en la omnipresente lista de distribución del grupo. Entra dentro de la etiqueta de un nuevo miembro familiarizarse con los debates pasados y presentes antes de intervenir, leer su documentación, sus normas de estilo, sus glosarios. Y por supuesto atenerse un tiempo a las normas de actuación antes de ponerlas en cuestión.
La continuación dependerá de cómo trabaje el grupo: ¿se reparten los ficheros PO y cada cual traduce con su kbabel o con su poedit? ¿le corresponde a cada uno generar los PO o XLIFF (o TMX de OmegaT) a partir de los documentos que van a traducirse y volver a regenerar los formatos originales ya traducidos? ¿se encarga de esta tarea un coordinador? ¿o se utiliza la interfaz web de algunas de las plataformas de traducción que ya analizamos?
Si a pesar de todos los matices y complicaciones de esta serie has llegado leyendo hasta aquí has superado la fase más difícil, la de la mentalización. Realmente, y nos vamos a poner personales, aconsejo la experiencia de aportar algo al software libre. Tanto si es por ver tu nombre escrito en un rinconcito escondido de una distribución, como si es por la satisfacción de poder devolver algo a una comunidad que nos ha aportado miles de horas de trabajo desinteresado, y de ese modo convertirte en un miembro de pleno derecho, este es el momento y la oportunidad de actuar.
Desde que en abril de 2005 decidimos hacer una panorámica del estado de la accesibilidad en GNU Linux ha pasado año y medio, una eternidad en términos de desarrollo dada de la velocidad de la evolución del software libre. ¿Qué ha ocurrido en el ámbito de la accesibilidad? ¿Ha sido el desarrollo igual de veloz? Hay una novedad fundamental que nos obliga a retomar el tema: Gnome 2.16 incorpora una nueva generación de interfaz de usuario de accesibilidad, Orca, básicamente un lector de pantalla con salida braille que está ilusionando a mucha gente. A Orca y a las novedades con respecto a la accesibilidad dedicaremos la siguiente entrega.
| Los grupos de traducción |
|
¿Cómo contactar con los grupos de traducción? Los grupos se presentan y explican en páginas web. Tengamos en cuenta que se trata de grupos de voluntarios organizados a través de internet, en los que normalmente sólo unas cuantas personas son fijas, y muchas hacen sus aportaciones más o menos importantes y desaparecen por falta de tiempo, o porque la tarea es más exigente de lo que esperaban... De hecho algún texto disponible en internet refleja una mentalidad curiosa, heredera de una tradición elitista que es hora de romper: según el razonamiento, si no tienes los conocimientos o el tiempo para ser desarrollador, al menos puedes contribuir al software libre con traducciones. No sé si contribuye mucho a que los procesos de traducción y creación de documentación sean más profesionales y rigurosos considerarlos tareas de segundo nivel. Bueno, sí lo sé. También sé que hay desarrolladores de paso, o chapuceros, o con pocos conocimientos, y que eso no descalifica al conjunto de los desarrolladores. El Proyecto de Traducción Libre de François Pinard es quizás el proyecto de traducción libre vivo más antiguo. Data de 1995, y nació para la traducción de documentos del proyecto GNU (posteriormente se ha generalizado a la traducción de documentos GPL que utilicen gettext). El coordinador español de toda la vida es Santiago Vila Doncel (sanvila EN unex.es) y el proyecto se encuentra alojado en http://www.iro.umontreal.ca/translation/HTML/; allí se encontrará información sobre el equipo español, el modo de inscribirse en la lista de traductores, etc. http://developer.gnome.org/projects/gtp/ nos presenta el Gnome Translation Project, el proyecto de traducción de Gnome. La página del equipo de localización de GNOME al español es http://live.gnome.org/SpanishTeam (que al parecer y de forma más o menos definitiva sustituye a http://wiki.hispalinux.es/moin/TraductoresFAQ). El coordinador es Francisco Javier Fernández Serrador y se comunican a través de la lista https://listas.es.gnome.org/mailman/listinfo/traductores. El proyecto de traducción de KDE en español se coordina a través de una lista de correo en la que deben estar inscritos todos los colaboradores, http://kybs.de/mailman/listinfo/kde-es. En ella se debaten temas correspondientes a la traducción, modificaciones de la web, asignaciones de trabajos y todo lo relacionado con este proyecto. El coordinador actual es Jaime Robles, jaime EN kde.org, y la página de contacto es http://es.l10n.kde.org/. En http://www.es.debian.org/international/spanish/ se describe y dan instrucciones sobre cómo colaborar con las traducciones del proyecto Debian. El coordinador de la tarea de traducción al castellano del Proyecto Debian es Javier Fernández-Sanguino Peña, jfs EN computer.org. El equipo se coordina en la lista de distribución que se archiva y se puede consultar (y a la que los interesados pueden suscribirse) en http://lists.debian.org/debian-l10n-spanish/. Por supuesto estos son sólo algunos grupos, y hemos dejado de mencionar importantes iniciativas de documentación relacionada con el software educativo que necesitan voluntarios. Pero tratar de ser exhaustivo en una revista es un pecado grave (el debate y las reflexiones pueden cambiar de medio, cualquier interesado podrá encontrarnos sin dificultad en google). |
[1] Fernández Serrador ha redactado lo que llama «cursillo del traductor» de Gnome, http://www.openshine.com/Members/serrador/gnome_l10n_es.pdf/download; puede consultarse además como predecesora la «Guía general de estilo» de Sun, v.1, de febrero de 1999: http://developer.gnome.org/projects/gtp/style-guides/pdf/styleguide-es.pdf. Glosario de KDE: http://es.l10n.kde.org/glosario.php. Debian: http://www.es.debian.org/international/spanish/notas.
[2] Archivo y formulario de inscripción en http://delfos.sci.uma.es/mailman/listinfo/spanglish.
[3] No sé si es exactamente la versión en funcionamiento, pero en http://www.iro.umontreal.ca/translation/bin/tp-robot puede leerse el código fuente (en python) de una versión del robot del TP (la fecha del fichero es 4 de enero de 2006).
[4] El robot de Debian-es: http://www.es.debian.org/international/spanish/robot. Sobre las pseudo-urls, http://people.debian.org/~jfs/debconf6/html/x613.html#pseudo_urls.
[5] Lo anunció públicamente Christian Perrier en varias listas de Debian el 21 de octubre de 2006. El servidor http://i18n.debian.net está alojado en el centro de proceso de datos de la Junta de Extremadura, en Badajoz.
[6] Si el lector es curioso puede examinar una comparativa de distribuciones educativas españolas en http://speeches.ofset.org/jrfernandez/rmll2006/edu_distros.html. Se trataría de las respuestas a la pregunta 1.3.