Traduciendo en Comunidades de Software Libre. Carmen Gomez Gómez

Transcripción

1 Traduciendo en Comunidades de Software Libre Carmen Gomez Gómez

2 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 o envie una carta a Creative Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA. Pág. 2 de 28

3 Índice de contenido 1. Introducción Las cuatro libertades La producción de software libre El proyecto Una metodología para el desarrollo Organización de las comunidades La traducción Internacionalización y localización Software libre & software propietario Organización de la traducción en software libre Herramientas Motivaciones para la colaboración Referencias Í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 : Herramienta propia de Webmin Asistente de traducción : Herramienta Pootle empleada por algunos proyectos para la traducción : Portal web Launchpad empleado en múltiples proyectos : Crear una cuenta en Launchpad : Desarrolladores del proyecto Moodle : Open Translation: web dedicada a la traducción del software libre : Equipo de traducción del proyecto KDE al español : Equipo de documentación de español en el proyecto Ubuntu...26 Pág. 3 de 28

4 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 , 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

5 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 sw.es.html Pág. 5 de 28

6 "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

7 1: Libertades del software libre 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

8 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 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 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 Pág. 8 de 28

9 (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. 2: Modelo de desarrollo usado en la empresa Planet 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

10 . 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: ). La numeración de las versiones será similar a la de Linux. De este modo, 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

11 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

12 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 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

13 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ía Se ha descrito mediante un ejemplo en el apartado 3.2. de este artículo Pág. 13 de 28

14 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] 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 \n\n )); 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

15 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. 3: Proceso de traducción de un programa 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

16 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 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

17 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 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

18 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

19 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. 4: Herramienta propia de Webmin Asistente de traducción Pág. 19 de 28

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

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