Los que somos fanáticos del software libre y de código abierto ya conocemos las ventajas de este modelo de desarrollo: es transparente, colaborativo, libre de ataduras corporativas, promueve la seguridad y la privacidad del usuario, y permite innovar más rápidamente. Pero además, si contribuyes con él te permite desarrollar habilidades que te servirán en un futuro para conseguir un trabajo, tal vez; sin importar si eres programador, ingeniero, diseñador de interfaces/gráficos… o traductor.

La localización (calco del inglés localization, o «l10n» como se la abrevia comúnmente) es el proceso que permite que el software se adapte no solo a la lengua nativa de una región determinada, sino que también adapta el dialecto, las maneras de escribir números y otros datos, entre otros cambios. Si la localización se realiza correctamente, los usuarios jamás tendrán la sensación de que están utilizando un programa o sistema operativo creado en otro idioma u otro país; al contrario, lo sentirán propio, lo harán suyo. Esto mejora muchísimo la experiencia del usuario (UX, por sus siglas en inglés). Considero que este es el objetivo al que todo programa debería llegar, si quiere alcanzar una base de usuarios multinacional: el usuario tiene que sentirse cómodo con el programa, que a fin de cuentas debe facilitarles una tarea.

La traducción, pues, es uno de los pasos más importantes para alcanzar esta meta. Sin embargo, no basta con que conozcas un idioma para llevarla a cabo correctamente. Es menester tener en cuenta:

• Convenciones ortográficas y ortotipográficas de la lengua de destino. Evitar calcarlas del texto en el idioma original, pues cada idioma cuenta con sus formas de utilizar los signos de puntuación, las mayúsculas e incluso el espaciamiento. Por ejemplo, en el inglés estadounidense se pone el punto final de una frase entrecomillada por dentro de las comillas de cierre, pero en español van por fuera. Otro ejemplo es la utilización del Title Case — utilizar mayúsculas iniciales en todas las palabras importantes, aun cuando no son nombres propios — , que Se Ve Rotundamente Ridículo en Español Cuando se Calca.
• Palabras traducidas directamente que tienen una connotación distinta en cada lengua. Hay que cuidarse de no utilizar falsos cognados, aunque estos sean muy comunes: por ejemplo, command no significa «comando» (‘grupo de soldados o guerrilleros’), sino «orden» (‘instrucción que los usuarios dan a la PC’). Otra confusión común es el término inglés event: aunque podría parecer obvio que significa «evento», también puede denotar «suceso», «caso», «ocasión», «encuentro» o «incidencia», según la situación particular. Es frecuente que en una lengua una voz tenga más acepciones que en la otra, y en frases tan comunes como in the event that… (‘en caso de que…’) no tendría sentido emplear la palabra «evento».
• Respetar la sintaxis de la lengua de destino. En una ocasión me tocó revisar la traducción de una frase que, aunque a primera vista parecía correcta, sonaba forzada e innatural. Era esta: Los subdocumentos nunca se modifican por cambios realizados en el patrón de documento. Cuando vi el texto original (Subdocuments never get changed by changes made to the master document), me di cuenta de que se copió hasta el orden de las palabras. Una vez que quité la innecesaria voz pasiva, pude producir con facilidad una traducción que sonaba más natural y resultaba más fácil de entender: Las modificaciones realizadas en el patrón del documento nunca repercuten en los subdocumentos. Es útil leer lo que hemos escrito y preguntarnos: «¿Suena a traducción? ¿Es algo que saldría de mi boca?»
• Regionalismos. En especial en idiomas tan extendidos por el mundo como el español, se necesita utilizar una terminología lo más neutral posible. Este es el motivo por el que, por ejemplo, Microsoft traduce computer como «equipo», dado que a lo largo y ancho de la hispanofonía se utilizan indistintamente los términos «computador», «computadora» y «ordenador», todos válidos, pero que para los propósitos de la traducción excluyen a las demás regiones, a menos que podamos costearnos preparar varias traducciones específicas para cada zona.
• Por último, procurar un tono adecuado. Por el mismo motivo que el inciso anterior. Usar coloquialismos en un programa probablemente hará que se sienta más personal y amigable… en una región determinada del mundo. El resto podría malinterpretar incluso las bromas más inocentes. Por eso el software bien traducido al español utiliza siempre un registro formal, incluso cuando en la lengua de origen el lenguaje no lo es tanto.

Si bien estas condiciones no se cumplen todo el tiempo, la ventaja del software libre es que permite que cualquiera aporte su granito de arena para mejorarlo.

Es laudable que contribuyas algo de ti a un software que te ha facilitado la vida. Si no tienes la posibilidad de aportar dinero para sus desarrolladores, ¿por qué no inviertes un poquito de tu tiempo contribuyendo con una traducción bien hecha? Y si los idiomas no son tu fuerte, hay más que hacer: puedes informar de errores, responder preguntas de otros usuarios, contribuir diseño gráfico… Con el software libre, las posibilidades son infinitas.

https://medium.com/@hackingdiem/c%C3%B3mo-y-por-qu%C3%A9-traducir-software-libre-b170c7aeb8bb