Traduciendo-en-Comunidades-de-Software-Libre

Traduciendo en
Comunidades de Software Libre
Carmen Gomez Gómez

Traduciendo en Comunidades de Software Libre
Esta obra está bajo una licencia Reconocimiento-Compartir bajo la misma licencia 3.0 España de
Creative Commons. Para ver una copia de esta licencia, visite
http://creativecommons.org/licenses/by-sa/3.0/es/
o envie una carta a Creative Commons, 171
Second Street, Suite 300, San Francisco, California 94105, USA.
Pág. 2 de 28

Índice de contenido
1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Las cuatro libertades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. La producción de software libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. El proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Una metodología para el desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Organización de las comunidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. La traducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Internacionalización y localización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Software libre & software propietario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Organización de la traducción en software libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Motivaciones para la colaboración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Índice de ilustraciones
1: Libertades del software libre............................................................................................................7
2: Modelo de desarrollo usado en la empresa Planet............................................................................9
3: Proceso de traducción de un programa...........................................................................................15
4: Herramienta propia de Webmin Asistente de traducción ..............................................................19
5: Herramienta Pootle empleada por algunos proyectos para la traducción.......................................20
6: Portal web Launchpad empleado en múltiples proyectos...............................................................20
7: Crear una cuenta en Launchpad......................................................................................................21
8: Desarrolladores del proyecto Moodle.............................................................................................23
9: Open Translation: web dedicada a la traducción del software libre...............................................24
10: Equipo de traducción del proyecto KDE al español.....................................................................25
11: Equipo de documentación de español en el proyecto Ubuntu......................................................26
Pág. 3 de 28

1. Introducción
Este artículo viene a complementar las principales ideas expuestas en la ponencia que presenté, con
motivo de las “VI Jornadas de Software Libre 2011”1, bajo el título “Traduciendo en
comunidades de software libre”.
Su propósito es el de orientar, de una manera práctica, la forma de colaborar con una comunidad de
software libre, tratando de esclarecer algunos de sus entresijos.
Se usará la Traducción como una de las formas de colaboración posible, sin que sea necesario tener
que ser un programador o experto en software. Al mismo tiempo, se plantea y trata de responder
algunas cuestiones importantes: ¿Cómo funciona una comunidad de software libre?; ¿Qué
caracteriza la traducción de software?; ¿Cuál es la motivación de las comunidades?. En definitiva,
su fin último persigue impulsar una nueva andadura en las formas colaborativas.
1 Jornadas de software libre organizadas por el Grupo Nibbler que se celebran anualmente en el mes de marzo
Pág. 4 de 28

2. Las cuatro libertades
Con el fin de contextualizar la Traducción de software libre, se hace necesario en primer lugar
hablar de los principios que lo sustentan. Principalmente, lo que se conoce en este medio como las
cuatro libertades (ver Ilustración 1), gracias a las que se puede dar la Traducción de software.
Cabe primero aclarar algo que la FSF2, Fundación creada para el software libre, hace en su propia
definición3:
“El «software libre» es una cuestión de libertad, no de precio. Para entender el
concepto, debería pensar en «libre» como en «libre expresión», no como en «barra
libre».
El software libre es una cuestión de la libertad de los usuarios de ejecutar, copiar,
distribuir, estudiar, cambiar y mejorar el software. Más precisamente, significa que los
usuarios de programas tienen las cuatro libertades esenciales. “
¿De qué cuatro libertades estamos hablando?. Aunque la FSF las numera tal y como aparecen en la
ilustración 1, me permitiré el lujo de hacer una reordenación con el fin de aclarar la “libertad de
modificación” que interesa especialmente para este artículo. Dicho esto, decimos que el software
libre está basado en cuatro principios o libertades:
Libertad de uso
“úsalo para lo que quieras”
Imaginemos que alguien se inventa una herramienta y nos la vende... ¡ah! eso sí, con la condición
de que sólo la usemos para lo que diga la licencia, por ejemplo: usar sólo para pelar patatas.
Estamos hablando en este caso de una limitación en el uso y, por tanto, de una licencia de software
propietario (eso que casi nadie se lee cuando instalas un programa). Si la herramienta es libre, esta
limitación de uso no existe. Nosotros somos responsables de elegir qué hacer con ella. Así, podemos
dar otros usos a esa herramienta que sirve para pelar patatas: hacer un juguete y ponerle unos ojitos
de papel, o si me pongo más dramática, emplearla lanzándola por la ventana para molestar al
vecino.
Libertad de estudio
En la herramienta del invento anterior, la libertad de estudiar significa que tenemos disponible el
código fuente. Esto supone que disponemos del “escrito” con la composición y todas las
instrucciones que hacen que la herramienta funcione. No se trata únicamente de un manual de uso,
sino la propia construcción de la herramienta.
Hagamos una comparación que hizo el propio Linus Tolvars para la revista BussinessWeek (2004):
2 FSF: Free Software Fundation o Fundación para el software libre
3 http://www.gnu.org/philosophy/freesw.
es.html
Pág. 5 de 28

"Yo lo comparo como Ciencia vs. Brujería. En la Ciencia, todo el sistema se basa en
personas mirando los resultados de otras personas, y construyendo sobre su trabajo.
En la Brujería, alguien tenía un pequeño secreto y lo cuidaba, pero nunca permitía a
otros entenderlo realmente y construir sobre él".
El software propietario es una caja cerrada. Lo que ésta hace es una cuestión de brujería. Podemos
ver su comportamiento y funcionalidad, pero no sabemos nada más. El desarrollador o inventor de
la herramienta se guarda el secreto de su composición. En el software libre, al igual que en la
ciencia, lo importante es que ese secreto ya no lo es, pues se convierte en público. La caja está
abierta, podemos ver el secreto, podemos ver el contenido y, si entendemos el idioma (o lenguaje de
programación), podremos estudiarlo e investigar sobre la herramienta. Brujería frente a ciencia.
Libertad de modificación
Basándonos en la libertad anterior, podemos añadir la libertad para modificar la herramienta. Si
disponemos del secreto, podemos investigar cómo hacer para añadir otras funcionalidades o hacer
mejoras. Lo que supone “reformar” la herramienta y construir sobre lo que ya alguien ha hecho.
El modelo de trabajo del software libre es, por tanto, el de compartir y el de colaborar. Los
resultados de las investigaciones se publican, se divulgan y sirven para nuevas investigaciones. Este
es principalmente el modelo sobre el que la humanidad ha innovado y avanzado.
Libertad de copia y distribución
“haz lo que quieras con la herramienta”4
Si puedes, cópiala y distribúyela con la reforma o sin la reforma, pon la herramienta en una caja de
flores y envíasela a tu amiga como regalo, distribúyela por el metro a todos, o tírala en paracaídas o
desde un avión. Hablamos entonces de licencias “copyleft” (literalmente en inglés “deja la copia”)
en contraposición al “copyright” del software propietario.
Entonces, ¿dónde quedan los derechos de autor?. Si puedes hacer lo que quieras ¿para qué necesitas
una licencia?. Aunque la explicación de los distintos tipos de licencias copyleft excede al tema de
este artículo, podemos resumir en que se debe mencionar a los autores y estás obligado a dejar la
herramienta libre para que otros puedan hacer lo mismo que tú.
4 Existen licencias con algunas restricciones, pero siempre se permite la copia y distribución. En la mayoría de los
casos se permite la distribución con fines comerciales.
Pág. 6 de 28

Para concluir este punto, podemos decir que la Traducción se considera un tipo de modificación y,
por tanto, hacemos uso de la libertad 1.
Pág. 7 de 28
1: Libertades del software libre

3. La producción de software libre
Para ilustrar las posibilidades y el funcionamiento de un proyecto de software libre, tomamos un
proyecto supuesto que nos servirá de ejemplo, al que llamamos OpenProject. A continuación, en el
desarrollo de la metodología de trabajo, trataremos los aspectos más relevantes para la puesta en
marcha del nuevo proyecto.
3.1. El proyecto
El objetivo principal de OpenProject es dirigirse a la comunidad de software libre para abrir el
código fuente de un producto propietario de la empresa “Planet”, y ofrecer servicios asociados.
OpenProject nace por requerimiento de un gran cliente, usuario del producto propietario, que por
motivos estratégicos decide utilizar software libre y migrar sus aplicaciones. Este cliente representa
el 50% de la facturación de “Planet”, además de ser una referencia internacional muy importante a
nivel comercial. Por otra parte, la mayoría de las propuestas de este cliente han sido tenidas muy en
cuenta en el avance y desarrollo del producto.
3.2. Una metodología para el desarrollo
La metodología propuesta se basa en tres de los principios que Eric S. Raymond analiza en su
artículo bien conocido “La catedral y el bazar”5:
Trata a tus usuarios como colaboradores, es el camino menos complicado para
mejorar con rapidez y depurar eficazmente un programa.
Lánzalo pronto, lánzalo a menudo y escucha a tus usuarios.
Dada una base lo suficientemente amplia de probadores y colaboradores, casi todos
los problemas se identificarán con rapidez y su solución será obvia para alguien.
En los siguientes apartados se explican de manera breve los aspectos más importantes que se
emplearán en la metodología para el desarrollo y la producción del software.
Infraestructura y canales de comunicación
Para que la empresa pueda afrontar con éxito el proyecto de software libre, prepara un sitio web
donde se proporciona una fuente centralizada de información.
Inicialmente, el proyecto cuenta con los empleados que trabajan en la empresa, con sus recursos
materiales y con algunos de sus clientes (posibles colaboradores), que siempre han proporcionado
ideas para el desarrollo del producto.
Planificación y supervisión del proyecto
Se proporciona un modelo de desarrollo válido tanto para la empresa como para la comunidad
5 http://biblioweb.sindominio.net/telematica/catedral.html
Pág. 8 de 28

(desarrolladores externos). La ilustración 2. muestra este modelo.
Los procesos coloreados en verde serán realizados y supervisados únicamente por la Empresa
Planet, mientras que los de amarillo pueden ser llevados a cabo tanto por la Comunidad de
desarrolladores externos como por la empresa. En la ilustración 2, la figura de la estrella (previa a la
“petición de cambios”) representa el inicio de un ciclo de desarrollo.
Se observa que la supervisión de las versiones corre a cargo de la Empresa Planet. Por el contrario,
cuando se trate de una revisión (cambios menos significativos del producto), puede ser llevada tanto
por la Empresa como por la Comunidad de desarrolladores externos.
Organización
La responsabilidad y la coordinación de la organización recae en un Comité de Dirección del
Proyecto, denominado CDP, que está formado por el jefe de proyecto de la Empresa y por los
desarrolladores activos en el proyecto (internos y externos). Este comité tiene la capacidad de
decisión sobre cuestiones importantes en todos los aspectos técnicos, y en la admisión de nuevos
desarroladores. Estas decisiones se tomarán por consenso, mediante una votación que se hará vía
Pág. 9 de 28
2: Modelo de desarrollo usado en la empresa Planet

email.
Uno de los componentes del Comité es designado como Administrador. Inicialmente, será el jefe de
proyecto de la Empresa. Este es el que realiza las labores administrativas que llevan consigo las
decisiones que se han tomado en el comité. Es, por tanto, el responsable de dar acceso a usuarios, de
las actualizaciones en el fichero de commiters6, y de otras gestiones relativas al control de versiones
(CVS7).
Política de aceptación de cambios
Los cambios son analizados por el Comité, cuyas decisiones son tomadas por consenso. Éste decide
si es un cambio que debe incluirse en una revisión del producto o en una nueva versión. Si se trata
de una revisión, se decide por consenso al responsable de la misma y, por tanto, también de su
desarrollo. Si es una versión, la responsabilidad recae directamente en el jefe de proyecto de la
Empresa, y será internamente donde se decida quién va a realizar el desarrollo.
Mantenimiento y control de versiones
Está claro que no hay software perfecto. Así, una vez que se hayan encontrado un número de errores
significativos, el responsable del desarrollo lanza una nueva revisión con un tercer punto (por
ejemplo: 4.10.2).
La numeración de las versiones será similar a la de Linux. De este modo, 4.10.2 se interpreta así: 4
es el número de versión (el número cambia cuando hay cambios significativos y nuevas
características); 10 es el número de revisión mayor (se incrementa casi siempre relacionada con las
funcionalidades añadidas); 2 es el número de revisión menor (las revisiones de arreglos de errores.
No hay nuevas funcionalidades en estas revisiones).
Métricas
El programa SLOCCount8 permitirá hacer un análisis del proyecto para obtener una estimación de
costes, de duración y de número de desarrolladores. Para ver la evolución del proyecto, SLOCCount
cuenta las líneas de código fuente, aunque estén escritas en diferentes lenguajes, basándose en
medios tradicionales de la ingeniería de software como el modelo COCOMO9.
Herramientas
Se usan herramientas libres como Subversión10 –para realizar el control de versiones-, y otras
propias para hacer el seguimiento de errores. Buildbot: ejecuta una serie de pruebas automáticas en
una variedad de plataformas y configuraciones para validar los cambios en el código fuente. Para
documentación y tareas de oficina: OpenOffice. Para la estimación de costes y métricas de calidad:
SLOCCount. Y como lenguajes de desarrollo se admiten: C, C++, Java y Perl.
Política de distribución de nuevas versiones
Se intenta lanzar una versión cada dos años, y una revisión aproximadamente cada 6 meses.
6 Commiter: se refiere a aquel que tiene permiso de escritura y puede modificar el código fuente de un programa
7 CVS: Concurrent Versions System: programa encargado de llevar un sistema de control de versiones
8 SLOCCount: es un programa usado para estimar costes
9 COCOMO: (COnstructive COst Model) es un modelo matemático de base empírica, utilizado para la estimación de
costes de software.
10 Subversion: es un sistema de control de versiones diseñado específicamente para reemplazar al popular CVS.
Pág. 10 de 28

Garantía y soporte a usuarios y desarrolladores
Los clientes del producto tienen la garantía de la Empresa, que pone a su disposición a su equipo de
trabajadores, además de una gran cantidad de usuarios (posibles colaboradores).
Por cada nuevo lanzamiento, se dará a conocer en la página web: la persona responsable de la
versión; las fechas próximas de formación; documentación; anuncios a conferencias; etc.
Además, siempre se mantiene en la página web estadísticas sobre la evolución del proyecto, así
como los clientes que lo estén usando, para demostrar su continuación y mantenimiento.
Licencia del producto
OpenProject tendrá licencia LGPL con el objetivo de permitir el uso, el enlace y la integración del
software con otros tipos de licencias, a veces propietarias, y escapando así de las restricciones de las
licencias GNU/GPL.
Hay que tener presente que, en gran parte, OpenProject es un programa que deberá integrarse con
las aplicaciones (propietarias o libres).
Pág. 11 de 28

4. Organización de las comunidades
En el punto anterior se ha puesto un ejemplo que ilustra el funcionamiento y los aspectos más
relevantes en la organización de un proyecto de software libre. Como se habrá podido observar, una
de las mayores diferencias entre los proyectos de software libre y los proyectos de software
propietario es el modo de organizarse de la comunidad de desarrolladores.
Aunque cada comunidad puede funcionar de forma diferente y
puede haber tantas formas como
proyectos,
vamos a presentar en este punto las principales formas genéricas que se dan en los
proyectos de software libre [1].
Así, en un proyecto de software propietario, la organización corresponde normalmente a la
organización jerárquica del equipo o el departamento que, dentro de una empresa, lleva a cabo a
cabo el desarrollo. Por el contrario, y aunque en los proyectos de software libre también puede
apreciarse en ocasiones cierta jerarquía, basada
parcialmente en los méritos de cada desarrollador,
la organización de la comunidad de desarrolladores es más flexible, y también más fuerte.
Organización basada en un "dictador benevolente"
El llamado dictador benevolente es una autoridad que toma decisiones definitivas para el proyecto.
Es el coordinador o árbitro de las discusiones, tratando de compatibilizar los distintos puntos de
vista de los desarrolladores. Suele ser un desarrollador con la suficiente experiencia en el proyecto,
aunque no es necesario que sea el más experto. Es suficiente con que sea capaz de entender el
proyecto en su totalidad y reconocer las contribuciones de más calidad.
Linus Torvalds, creador del núcleo de Linux, es un ejemplo de dictador benevolente de un equipo de
más de 1.000 programadores en todo el mundo que contribuyen a su mantenimiento.
Organización basada en el consenso
Se entiende por consenso los acuerdos que toda la comunidad acepta .
Por lo general, cada desarrollador crea o corrige una parte del software o funcionalidad en concreto.
El curso normal es que cada uno decida qué hacer y cómo. Si por cualquier motivo, esta decisión
entra en conflicto con la opinión de otro desarrollador, entonces se abrirá un tema de discusión de
tipo técnico. Esto da lugar a que todos los desarrolladores expongan sus puntos de vista y
argumentos. Se trata de llegar a un acuerdo satisfactorio para todos, es decir, de llegar al consenso.
El consenso se produce cuando todo el mundo está de acuerdo en el diseño, la implementación de la
funcionalidad o la manera de solucionar un error. La forma final que toma la discusión es la
votación, y con ella se ratifica el acuerdo. Para terminar, se realiza un informe final cuyo objetivo es
resumir lo que se ha dicho y la conclusión.
Los proyectos suelen empezar con una organización basada en un dictador benevolente, y a medida
que la comunidad crece, se van encaminando hacia una organización basada en el consenso. Esto
suele ocurrir en algún momento de la vida del proyecto, cuando el dictador benevolente abandona su
posición y su autoridad se diluye en la comunidad, especialmente entre sus miembros más
Pág. 12 de 28

respetados.
Al cabo de un tiempo, las decisiones tomadas en una comunidad van creciendo y pueden llegar a ser
muy grandes muchas. Es conveniente, por tanto, que se recojan en un documento todas estas
decisiones. En éste se incluye la forma de organización y gobierno de la comunidad, la forma de
nombrar las versiones, fechas, revisiones, así como las convenciones y recomendaciones de los
desarrolladores. Es decir, todo lo que respecta a la metodología11.
11 Se ha descrito mediante un ejemplo en el apartado 3.2. de este artículo
Pág. 13 de 28

5. La traducción
Antes de entrar en materia sobre los aspectos inherentes a la traducción de software libre, vamos a
aclarar algunos aspectos importantes relacionados con la traducción en sí misma y, en general, con
la traducción de software. Para ello, cabe preguntarse: ¿qué diferencia la traducción de software de
la traducción de un texto técnico?. En este sentido, se trata primero de aclarar los conceptos de
internacionalización y localización, para después diferenciar cómo funcionan las comunidades de
traducción de software y las herramientas que se utilizan para facilitar esta labor.
Gran parte del contenido de los puntos siguientes han sido bien aclarados y, en ocasiones,
literalmente copiados de Perea Sardón [3].
5.1. Internacionalización y localización
Vamos a utilizar los conceptos de internacionalización y localización para responder a la pregunta
anteriormente planteada: ¿Qué diferencia la traducción de software de la traducción de un texto
técnico?.
La internacionalización es la adaptación que los desarrolladores tienen que hacer a los
programas para que sea posible traducirlos y adaptarlos a distintos idiomas. Esta adaptación va más
allá de la mera traducción. Por ejemplo, de un idioma a otro, cambia el alfabeto, el signo de la
moneda, los decimales, etc. Pero además, en el código que usa el desarrollador está mezclado el
texto a traducir con el código en sí del programa. Atendamos a un ejemplo de un fragmento de
programa:
printf ( (“n Show users who are currently logged nn”));
En este caso, para los que no saben programar caso
innecesario en los traductores,
cabe decir que
printf es la función en C que sirve para imprimir mensajes por pantalla. El texto a traducir sería
“Show users who are currently logged”.
Será por tanto el autor del programa quien deberá prepararlo (separa las instrucciones del texto en
sí) para que pueda ser fácilmente traducido. Esta adaptación es lo que se denomina
internacionalización. El programador prepara su código y genera los ficheros que deberán ser
traducidos.
Posteriomente, ¿cómo sabe el sistema en qué idioma se quiere que salgan los mensajes?. Será
precisamente en el momento de la instalación y configuración del programa por parte del usuario
cuando éste elija el idioma o idiomas, así como las especificaciones locales (moneda, formato de
numeración, etc).
El sistema, siguiendo las especificaciones dadas por el usuario, se encargará de cargar los ficheros
apropiados donde se encuentren las traducciones y las localizaciones.
Pág. 14 de 28

La localización es lo que hace el traductor, gracias al trabajo previo de internacionalización.
La ilustración 3. muestra el proceso de traducción de un programa.
Para escribir programas que puedan mostrar la interfaz en varios idiomas suele utilizarse la
biblioteca de internacionalización GNU gettext. Para usar esta biblioteca, es necesario que el
programa haya sido escrito siguiendo ciertas normas que después permiten extraer del mismo todo
el texto traducible.
5.2. Software libre & software propietario
La traducción de software libre, al igual que el desarrollo, suele realizarse de manera muy diferente
a la del software propietario. La intervención de la comunidad es muy importante, tal y como
explica uno de los mayores divulgadores de la traducción de software libre en una serie de artículos
aparecidos en el año 2006 sobre la traducción de software libre, Fernández García [2] (2006a,
2006b, 2006c, 2006d, 2007).
En el caso del software propietario, la empresa creadora del software se encarga normalmente del
proceso de localización. Casi siempre, subcontratando la traducción a una empresa intermediaria
que se encarga además de realizar las guías y manuales. En ocasiones, la propia empresa tiene un
departamento dedicado a la localización. Esto dependerá de determinados intereses empresariales y
de costes.
Por el contrario, en el caso del software libre, ni siquiera es necesario que los creadores del mismo
se encarguen de ello, puesto que las licencias permiten modificar y distribuir el código fuente.
Cualquier usuario que desee traducir una aplicación a un idioma puede hacerlo. La facilidad de
llevar a cabo esta tarea dependerá de que los programadores hayan preparado adecuadamente los
archivos para su localización. Si ello no ha sido así, al traductor puede resultarle difícil distinguir los
elementos de la interfaz de usuario, o toparse con otros problemas. Sin embargo, en la mayoría de
Pág. 15 de 28
3: Proceso de traducción de un programa

los casos, en el desarrollo del software ya se ha tenido en cuenta la localización. Además, los
creadores suelen ofrecer ayuda a los usuarios que quieran traducir su software.
Algunos proyectos importantes de software libre se implican mucho en el proceso de localización de
diferentes maneras, como pueden ser la gestión directa del portal web que coordina la traducción
(como en el caso de Ubuntu), o la creación de una herramienta específica para traducir sus
productos (como es el caso de Mozilla). También participan de manera más directa en la traducción,
como ocurre con Sun, que cuenta con un departamento de traducción que ha elaborado una de las
guías de estilo de referencia en la traducción del software libre. A veces, una empresa dedicada al
software libre decide encargar algunas traducciones de mayor visibilidad (como por ejemplo, el
márketing) a una empresa de traducción convencional, aunque para otros materiales pida ayuda a la
comunidad.
5.3. Organización de la traducción en software libre
En general, para cada idioma existe un coordinador, encargado de crear unos archivos destinados
específicamente a los traductores. Este coordinador es una figura esencial. Cuando alguien quiere
participar en la traducción de un proyecto, debe ponerse en contacto con el coordinador respectivo
para esa lengua, quien le asigna los archivos que considere convenientes, según la capacidad del
usuario y, lo que suele ser de vital importancia, el tiempo que pueda dedicar a la traducción y la
revisión. Cuando el voluntario termina de trabajar con los archivos, se los envía al coordinador. Esto
es, el coordinador se encarga de remisiones y recepciones y suele comunicarse con traductores y
revisores mediante un portal o una página web que sirve como punto de encuentro, así como
diversos foros que actúan como canales de comunicación, junto con el correo electrónico. Así, en
algunos casos el coordinador realiza cierto control de calidad y después los envía a los creadores del
software, que incluyen la traducción en el producto que distribuyen.
En ocasiones, la importancia del coordinador en este modelo plantea problemas. Al no tener una
relación laboral con el proyecto en el que colabora, el tiempo y el esfuerzo que dedica a la
localización del proyecto son muy variables. Dependiendo de sus circunstancias personales y
profesionales, puede llegar un momento en que deban abandonar la coordinación, por lo que puede
romperse un importante eslabón de la cadena. Estas situaciones se producen con frecuencia, y por
este motivo, los coordinadores deben documentar su trabajo de la mejor manera posible, y encontrar
a un sustituto antes de abandonarlo a fin de que el proceso de localización resulte poco afectado.
Los principales problemas de este modelo son relativos a la calidad de las traducciones y al tiempo
que tardan en realizarse. Al depender del trabajo voluntario de un número de usuarios (que puede
llegar a ser muy elevado) no es posible fijar una estricta fecha límite para la traducción. Además,
como el desarrollo del software suele destinar poco tiempo a la traducción, con frecuencia no se
dispone de una traducción completa cuando llega el momento de lanzar el producto. Por eso, es
frecuente que en algunos de los proyectos localizados según este modelo, la traducción sea parcial y
el usuario se encuentre con elementos que permanecen en el idioma original del software. Para
paliar el problema, en el caso del sistema operativo, últimamente es frecuente que, pocos días antes
de la fecha de lanzamiento, se celebren eventos denominados “festivales de traducción”, en los que
se intenta concentrar la traducción pendiente en un evento celebrado durante un período de tiempo
muy reducido (normalmente, un fin de semana) para fomentar la participación de traductores
voluntarios.
Pág. 16 de 28

Tal vez aun más importante que la escasez de tiempo para las traducciones es su calidad. Con
frecuencia no es suficiente, pues a menudo las realizan voluntarios sin grandes conocimientos de
idiomas. Fernández [2] (2006b:81) ofrece la siguiente descripción prototípica de los voluntarios:
“ […] el perfil típico clásico del traductor voluntario es el de un estudiante de
ingeniería [...] con un conocimiento limitado del inglés, y que tampoco domina
las decisiones terminológicas a las que se haya podido llegar en el grupo. Por
uno que persiste, varios picotean (son voluntarios), y cuando el coordinador
señala los errores cometidos suelen desaparecer.”
Aunque esta descripción subraya las dificultades lingüísticas de los voluntarios, también apunta a
que sus conocimientos técnicos suelen ser elevados, frente al traductor profesional, que no suele
tener problemas de lengua pero sí de comprensión de los aspectos técnicos. Bergmann [4] opina
que, con frecuencia, los usuarios de ciertos productos de software libre –especialmente,
herramientas destinadas a los administradores de sistemas– no necesitan una traducción de gran
calidad, ya que suelen tener un elevado nivel de inglés y usan el software en esa lengua. A pesar de
ello, ante la expansión del software libre, y a medida que los productos se popularizan también en
los ordenadores domésticos, es previsible que vayan en aumento las demandas y las exigencias de
calidad a las traducciones de software libre.
5.4. Herramientas
A continuación se muestran ejemplos de editores que usan los traductores, así como las
herramientas y sitios web más empleados para la traducción de proyectos bien conocidos.
Emacs
Los archivos con extensión .po son de texto simple, por lo que pueden traducirse directamente en
cualquier editor de texto. Probablemente, el primer programa que se utilizó para traducir dichos
archivos fue Emacs, un editor de texto de Linux, que incluye una gran cantidad de funciones y es
muy popular entre programadores y usuarios técnicos.
Poedit
Como se puede intuir por el nombre, Poedit es un editor diseñado específicamente para trabajar con
los archivos .po. La característica más notoria de este editor es que es multiplataforma, por lo que
puede ejecutarse tanto en Linux como en Windows y Mac OS X.
Kbabel
Hoy en día es el editor más frecuente para trabajar con archivos .po, quizás por su gran cantidad de
funciones. Esta herramienta sólo funciona en Linux. A pesar del considerable éxito y popularidad
cosechados, el desarrollo de Kbabel se ha interrumpido recientemente, y se prevé que será sustituido
por Lokalize (anteriormente conocido como Kaider), que presenta la ventaja de permitir trabajar con
memorias de traducción y glosarios, aunque todavía no incorpora las verificaciones que incluía
Kbabel.
Pág. 17 de 28

Gtranslator
Este editor de archivos .po, sólo disponible para Linux, es similar a Kbabel, aunque está diseñado
específicamente para funcionar en el entorno de escritorio Gnome. Su desarrollo se ha detenido,
motivo por el que su uso ha disminuido considerablemente.
Mozilla Translator
Esta es la herramienta diseñada por Mozilla para traducir sus productos, entre los que destaca el
navegador web Firefox y el cliente de correo Thunderbird. Está programada en Java, por lo que es
multiplataforma y puede ejecutarse en cualquier sistema operativo que tenga instalada la
correspondiente máquina Java. Se trata de una herramienta bastante sencilla, que compensa la
escasez de funciones con una interfaz fácil de usar.
Virtaal
Virtaal es una herramienta de traducción asistida escrita en Python que pretende optimizar la
interfaz para el traductor. Aunque en un principio está eminentemente destinada a la localización,
sus desarrolladores tienen previsto ampliar su utilidad más allá de su uso para traducir software.
OmegaT
OmegaT es una herramienta de traducción asistida que no sólo se utiliza en la traducción de
proyectos de software libre, como por ejemplo NetBeans y OpenOffice, sino que cuenta con
capacidad suficiente para ejecutar la traducción de cualquier proyecto profesional de traducción.
Pootle
El editor Pootle integra tanto la gestión de las traducciones como las funciones de una herramienta
de traducción asistida, en un sitio web en el que los usuarios pueden registrarse, iniciar sesión y
trabajar. Al tratarse de un sitio web escrito en el lenguaje de programación Python, puede ejecutarse
en cualquier sistema que cuente con conexión a Internet y un navegador. Además de los archivos
.po, también admite archivos de texto simple, .properties (archivos de Java y Mozilla), HTML y
XLIFF. Entre sus funciones se encuentra la posibilidad de utilizar memorias de traducción, glosarios
y diversos tipos de validación, además de permitir al usuario fijarse metas, es decir, definir el
volumen de palabras que desea traducir en un tiempo determinado.
Se puede encontrar un vídeo [5] titulado “Traductor Pootle” en YouTube, donde se muestra el
funcionamiento de esta herramienta de forma sencilla.
Launchpad
La traducción de Ubuntu se gestiona desde el portal web Launchpad. Este portal es el punto de
acceso a la traducción de proyectos de software de todo tipo, desde sistemas operativos y
aplicaciones de ofimática hasta juegos. Los usuarios pueden registrarse gratuitamente y solicitar una
cuenta que les permite utilizar las funciones de esta página.
Una vez que se dispone de una cuenta de Launchpad, todo usuario puede acceder a una página en la
que aparecen tanto los archivos traducidos como los que están por traducir. Los archivos aparecen en
orden decreciente de relevancia, para que los usuarios presten mayor atención a los archivos más
importantes. Una vez seleccionado un archivo, el usuario puede traducir los segmentos que desee
Pág. 18 de 28

utilizando las herramientas del portal, o bien descargar el archivo, traducirlo sin conexión como
desee en su ordenador personal y después subirlo utilizando el mismo portal de traducción.
Herramientas propias
Algunos programas usan sus propias herramientas para la traducción. Un ejemplo de ello es el
programa de administración Linux llamado Webmin, que usa un asistente de traducción creado
específicamente para ello.
Este asistente de traducción se instala como un módulo más en webmin. Se puede encontrar una
serie de vídeos [6] titulados “Traducir Webmin” en YouTube, donde se muestra el funcionamiento
de una herramienta propia del programa webmin.
Pág. 19 de 28
4: Herramienta propia de Webmin Asistente de traducción

5: Herramienta Pootle empleada por algunos proyectos para la traducción
Pág. 20 de 28
6: Portal web Launchpad empleado en múltiples proyectos

Pág. 21 de 28
7: Crear una cuenta en Launchpad

6. Motivaciones para la colaboración
Falsos mitos y realidades
Algunos “fans” (y otros no tanto) del software libre han creado algunos mitos acerca de éste. Así, no
es difícil escuchar, en relación a la gente que colabora en software libre, cosas como:
– Son unos “frikis” fanáticos de Internet que se aburren y no tienen otra cosa mejor que hacer.
– Son una especie de ONG que por bondad o por “ideales” quieren compartir lo que hacen.
Estos falsos mitos no se corresponden con una realidad que va más allá de la idea altruista de
“compartir” o de estar “aburrido” en casa.
No parece extraño que si uno usa muchas veces un programa le incomode verlo en inglés. Al final,
cuando no se es bilingüe, siempre se prefiere tener la facilidad de verlo escrito en la propia lengua.
Tampoco parece extraño imaginar que un programador tenga tentaciones de cambiar algo en un
programa cuando ve algún error, o simplemente quiere que le sea más útil, o le resulte más fácil de
usar para su trabajo. Este tipo de tentaciones pueden verse satisfechas con el software libre, pues el
usuario es realmente libre de realizar las modificaciones oportunas, tanto en el funcionamiento
como en la traducción.
Por ello, es fácil que se hable de una iniciativa o motivación relacionada con los requerimientos del
usuario final, puesto que esta es la filosofía del software libre: “el usuario final”. Los programas se
piensan y orientan hacia el que lo usa.
Además, puede hablarse también de otras motivaciones de tipo práctico, como en el caso de
estudiantes de ingeniería informática y de escuelas de traducción. El software libre les permite ver el
código de los programas y poner en práctica sus conocimientos de lenguajes de programación. O
realizar traducciones mas allá de ejemplos empleados en la docencia que, por lo general, no tienen
mucho que ver con casos reales.
Una oportunidad
El software libre nos ofrece una tremenda oportunidad para salir de una relación de intercambio
puramente comercial, así como la oportunidad de hacer prácticas reales: publicidad gratuita de una
empresa, curriculum o simplemente por el narcisismo de ver tu nombre escrito en Internet.
Pág. 22 de 28

¡Participa!
Existe un gran número de proyectos de software libre en los que se puede colaborar, tanto
traduciendo como revisando las traducciones que otros han hecho, o incluso, ayudando al
mantenimiento y la gestión de las traducciones de un proyecto.
En la página web OpenTranslation [7] puede encontrarse información bastante detallada acerca de la
traducción de algunos proyectos como: gnome, kde, mozilla, openoffice, ubuntu, xfc.
Así, se puede saber cuál es la página principal del proyecto de traducción, qué tipo de español se
realiza en la misma, qué materiales se proporcionan, qué herramientas se utilizan, qué lista de
correo utiliza un proyecto, y otras informaciones de interés.
¿Y ahora qué queda? ¡Participa!
Pág. 23 de 28
8: Desarrolladores del proyecto Moodle

Pág. 24 de 28
9: Open Translation: web dedicada a la traducción del software libre

Pág. 25 de 28
10: Equipo de traducción del proyecto KDE al español

Pág. 26 de 28
11: Equipo de documentación de español en el proyecto Ubuntu

7. Referencias
[1] Albos Raya, Amadeo y Sánchez Jimenez, Oscar David (2005). “Implantación, proyectos, y
empresas de software libre”. UOC
[2] Fernández García, Juan Rafael, en Linux-Magazine.es. Serie de artículos publicados en 2006 y
2007:
• (2006a): Oportunidad de colaborar. Linux-Magazine, 19: 76-80. Málaga: Linux New Media
Spain S.L.
• (2006b): Trabajo en equi/po. Linux-Magazine, 20: 79-83. Málaga: Linux New Media Spain
S.L.
• (2006c): Memorias compartidas. Linux-Magazine, 21: 77-81. Málaga: Linux New Media
Spain S.L.
• (2006d): Cambio de herramientas. Linux-Magazine, 22: 74-78. Málaga: Linux New Media
Spain S.L.
• (2007): Cerrando el ciclo. Linux-Magazine, 23: 73-76. Málaga: Linux New Media Spain
S.L.
[3] Perea Sardón, Jose Ignacio. (2010): Tesis doctoral “Revisión asistida por ordenador de
traducciones. Aplicación práctica a la revisión del sistema operativo libre Ubuntu como ejemplo” .
[4] Bergmann, Frank. (2005): Open-source software and localization – An introduction to OSS and
its impact on the language industry. Multilingual Computing & Technology, 70. MultiLingual
Computing, Inc. Sandpoint.
[5] Carmen Gómez. 2010. Video “Traductor Pootle” y “Traducir Zentyal” en YouTube.
• http://www.yout ube.com/watch?v=tbQLmcrGEe8
• http://www.youtube.com/watch?v=-c-c5lWh5fo
[6] Carmen Gómez. 2010. Serie de Videos “Traducir Webmin” en YouTube.
• http://www.youtube.com/watch?v=qM47cR5BANw
• http://www.youtube.com/watch?v=5ZEWMt5Ewn8
• http://www.youtube.com/watch?v=PNaVfwh75ek
[7] OpenTranslation. Página de colaboración en varias traducciones.
• http://www.opentranslation.es
Pág. 27 de 28

Carmen Gómez Gómez
Profesora, autora y traductora de software
menchu@nibbler.es
Abril 2011
Esta obra está bajo una licencia ReconocimientoCompartir
bajo la misma
licencia 3.0 España de Creative Commons.
Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/bysa/
3.0/es/ o envie
una carta a Creative Commons, 171 Second Street, Suite 300, San Francisco, California 94105,
USA.
Pág. 28 de 28

Traduciendo-en-Comunidades-de-Software-Libre

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (11)

Similar a Traduciendo-en-Comunidades-de-Software-Libre

Similar a Traduciendo-en-Comunidades-de-Software-Libre (20)

Traduciendo-en-Comunidades-de-Software-Libre