El lenguaje es un instrumento cognitivo; es el vehículo para aprender y construir nuestro mundo; y también puede transformarse en una fuente de exclusión.
La ciencia de datos afecta la vida de muchas personas globalmente. Esta práctica utiliza herramientas tecnológicas desarrolladas bajo ciencia, software y educación abiertas globales, pero la mayoría de los recursos son construidos y publicados en inglés.
El inglés es la lengua franca de la ciencia de datos, lo cual crea una barrera significativa para quienes no son angloparlantes y quieren unirse a la disciplina: no podemos participar si no entendemos el idioma. [^3] Las autoras hemos experimentado esta barrera de primera mano. Ambas nacimos en un país de Sudamérica en el que el lenguaje oficial es el castellano, y necesitamos usar tecnología y ciencia de datos para enseñar e investigar adecuadamente en nuestras carreras.
Entonces, ¿qué acciones podemos tomar ante esta situación? Podemos usar nuestros privilegios para cambiarla, y aquí es donde entran en juego las traducciones impulsadas por comunidades.
El camino comunitario
Las traducciones substituyen a los textos originales. Las usas en lugar de trabajos escritos en un lenguaje que no podés leer [^5] o que tenés dificultades en leer: incluso si tienes dominio de un segundo idioma, aprender nuevo contenido en un lenguaje extranjero aumenta tu carga cognitiva. Las traducciones son uno de los esfuerzos que podemos hacer para crear una ciencia de datos más diversa. Sabemos que la creación de contenido voluntaria y colaborativa es posible. El software de código abierto o Wikipedia son grandes ejemplos de como cada persona puede aportar su granito de arena. La ventaja principal de trabajar colaborativamente es distribuir el trabajo (con suerte) entre personas diversas. En 2017, el Código de Conducta de R-Ladies se tradujo al español y portugués. En 2018, la comunidad de R de Latinoamérica colectivamente tradujo el libro R for Data Science (R4DS) a español, incluyendo los paquetes datos y dados (en español y portugués, respectivamente) [^6]. Después la comunidad tradujo Enseñar Tecnología en Comunidad (T3, del título original Teaching Teach Together) y contribuyó a traducir hojas de guíaheat de R y lecciones The Carpentries’ y The Programming Historian. La comunidad hispanoparlante activa y en crecimiento impulsó a rOpenSci a realizar la primera revisión por pares de código en español y a traducir al español del libro de rOpen Scisobre las mejores prácticas para desarrollo de software, revisión de código y contribución a projectos de código abierto.[^7] Los siguientes diez consejos resumen lo que hemos aprendido en estas traducciones conducidas por comunidades, por ser coordinadoras, traductoras, revisoras y editoras de libros y materiales usados por decenas de miles de personas.
1. Motivación
La traducción de material técnico de documentos vivos es un proceso largo, con dos etapas bien definidas que involucran distintos recursos. La primera etapa es alcanzar una versión completa del material traducido, y la segunda es mantener el material actualizado y sincronizado entre los idiomas. El tipo de proyecto, los objetivos, estadío, motivación y expectativas deben ser claros desde el inicio para tener la mejor chance de tener éxito. En las traducciones colaborativas hay diferentes niveles de motivación:
- Motivaciones comunitarias; por ejemplo, hacer accesible el material a personas de Latinoamérica y usarlo en talleres específicos.
- Motivaciones personales de las personas involucradas en el proyecto, tales como aprender y discutir el contenido con las participantes mientras se traduce.
Antes que las personas puedan decidir participar, debemos detallar los tipos de beneficios que pueden obtener, tales como aprender habilidades técnicas que les serán útiles más allá de este proyecto, devolverle algo a su comunidad, ganar experiencia trabajando en colaboración en equipos internacionales y de código abierto, conectarse con gente de intereses similares, ampliar sus redes y mentorear a otras personas durante el proyecto.
2. Consentimiento de las autoras o autores del texto
La mayoría de los materiales tienen una licencia y para las traducciones, la licencia debe permitir trabajos derivados. Tanto las/los autoras/es como la editorial pueden tener derechos sobre el material. Solicitá su consentimiento y haz que sean parte del proceso para realizarles consultas y pedirles su opinión. En un texto técnico las/los autores pueden haber definido nuevos términos, por lo que poder mantener un intercambio con estas personas es esencial para que la traducción sea lo más fiel posible al texto original.
Desde el punto de vista de las/los autoras/es, este intercambio invariablemente mejora el texto original, desde corrección de errores hasta encontrar ejemplos más diversos o lagunas en el contenido. Si se desea promover las traducciones, se puede crear el contenido teniendo esto en mente, por ejemplo publicando el texto en lenguaje de marcado, en un repositorio público, o crear el texto con una estructura para múltiples lenguajes. Si el material fue publicado por una organización, ésta puede asignar fondos a iniciativas de traducción comunitarias.
3. Comparte y documenta tu proceso y acuerdos
Tener guías escritas claras para contribuir y tomar decisiones hace más sencillo todo el proceso de traducción. En esta sección, nos enfocamos en el aspecto técnico del proyecto; ver la sección 10 para detalles sobre construir un documento de gobernanza para formalizar el proceso de toma de decisión y cómo interactúan quienes participan del proyecto.
Para tu proyecto, necesitas discutir, usar y actualizar varios instrumentos, tales como:
- Roles y responsabilidades: qué personas traducen, revisan, editan, lideran el proyecto, realizan el diseño gráfico, etc. Ayuda a designar responsables y dar crédito por sus contribuciones (ver secciones 6 y 10).
- Una agenda tentativa con plazos, tareas asignadas y seguimiento del proceso. Ayuda a mantener el proyecto en marcha (ver sección 6).
- Una guía con los acuerdos sobre el uso del lenguaje, detallando: – Uso de la voz (e.g., conversacional, no científica o formal) – Variedad dialectal (ver secciones 7 y 8 ). – Reglas gramaticales, ortográficas y de puntuación. – Guía de lenguaje inclusivo y no sexista. – Traducción de figuras y texto alternativo (accesibilidad, ver sección 5) – Glosario técnico bilingüe (ver sección 9). – Palabras no técnicas a ser traducidas, como los nombres de las personas o las ciudades en los ejemplos (ver localización en la sección 4). – Estos productos del proyecto son tan importantes y útiles como el texto principal traducido. Compártelos con una licencia abierta.
4. El foco es la traducción
La internacionalización se refiere a la tecnología y diseños que permiten que el software se adapte a varias regiones sin cambios en el código fuente. La solución técnica nos permite localizar nuestro contenido. [^8] La localización hace más accesible y adecuado a un contenido para otra región, país o público. [^8] Esto incluye al idioma, formato de fechas, monedas, unidades de medición y compatibilidad con distintos caracteres de texto.
Hay muchas soluciones para internacionalizar y localizar contenidos. Entre estos esfuerzos, la traducción es típicamente el componente que más tiempo demanda. [^8]
Muchos proyectos enfocan sus esfuerzos en la internacionalización, escogiendo la herramienta adecuada para el trabajo, por ejemplo, sistemas de manejo de traducción (Crowdin, Transifex, Weblate), traductores automáticos (Google Translate, DeepL); y sistemas de control de versiones (GitHub, GitLab), lenguajes de marcado (LaTeX, Markdown) y herramientas para escribir estos lenguajes (Overleaf, RStudio).
Sea cual sea la herramienta de traducción y lenguaje de marcado que seleciones, no deberían ser una barrera para el equipo. Elige las herramientas que mejor se ajusten a tu equipo y al material. Por ejemplo, ¿Cuán importante es priorizar el control de versiones? ¿Las actualizaciones? ¿Realizar previsualizaciones? ¿El formato de salida? ¿Qué nivel de conocimientos básicos es necesario para contribuir?
Adicionalmente, crea procesos que ayuden a aquellas personas del equipo que no puedan utilizar alguna herramienta debido a la accesibilidad o a sus habilidades. Entrena al equipo en la infraestructura del proyecto, desarrolla instructivos (videos, tutoriales) sobre cómo usar las herramientas, crea oportunidades de traducción entre pares y organiza reuniones de trabajo conjunto y de incorporación de nuevos miembros al equipo.
5. Lenguaje inclusivo y no sexista
Muchos idiomas utilizan indicadores de género femenino y masculino. El uso de lenguaje no sexista o que no realice distinción de género en la traducción tiene por objetivo evitar elecciones léxicas que son sesgadas, discriminatorias o excluyentes. En las comunidades de tecnología y ciencia de datos, usar lenguaje no sexista ayuda a luchar contra los estereotipos sobre los roles de género y a promover la representación femenina y de personas no binarias.
Estudia las recomendaciones de uso de lenguaje no sexista en el idioma que quieras traducir, busca consejos de personas expertas, discute con el equipo y documenta la decisión para ser consistente a través de los capítulos (y proyectos). Por ejemplo, The Carpentries decidió usar siempre el femenino en sus traducciones al español. En T3 y rOpenSci, ajustamos la redacción para evitar asignar un género. En caso de no poder evitar una marca de género, utilizamos divisiones femenino/masculino o masculino/femenino. Por consistencia a lo largo del texto y para mostrar que no hay una jerarquía en particular, alternamos el uso de estas divisiones entre capítulos, siendo consistentes dentro de cada capítulo. Otra posibilidad es el uso de pronombres, sustantivos y adjetivos no binarios (en español, usar la e o la x son las opciones más comunes). ¿Cuál es la mejor opción para tu comunidad?
6. Pasito a pasito: seguimiento del progreso y contribuciones
Divide el trabajo en actividades menores e hitos para mejorar la asignación de tareas y el seguimiento. Para las traducciones de libros, un capítulo es una buena unidad de división. Pero otros ítems deben ser traducidos también, como figuras, textos alternativos, ejemplos de código y conjuntos de datos. Hay también actividades extra, tales como comprobar el uso correcto del lenguaje no sexista o inclusivo, revisar la ortografía y gramática, evaluar referencias externas alternativas que estén disponibles en el idioma de la traducción, entre otras.
Mantener un registro de estas actividades te permitirá intervenir, asistir, discutir un proceso, buscar reemplazos o más participantes, buscar una herramienta alternativa y realizar reportes períodicos del progreso (¡incluso si no se ha avanzado!). En T3, informábamos el progreso semanalmente en el canal de Slack de la traducción, detallando las tareas completadas y agradeciéndoles a quienes participaron de ellas. Para la traducción de R4DS, las tareas completadas se actualizaban en un repositorio GitHub.
El seguimiento y la elaboración de informes permite que todas las contribuciones sean reconocidas adecuadamente, no sólo los roles más comunes (traducción, revisión, edición) sino también los de quienes aconsejan en asuntos específicos, resuelven problemas técnicos o realizan tareas de diseño gráfico.
La herramienta que uses para registrar esta información estará relacionada con la herramienta usada para las traducciones. Por ejemplo, puedes usar proyectos de GitHub e issues, como hicimos en R4DS y rOpenSci; o una planilla compartida e issues de GitHub, como hicimos en T3. Algunos sistemas de gestión de traducciones registran los progresos, pero no quién contribuye. Cualquiera sea el conjunto de herramientas que elijas, mantén tu progreso actualizado, registra la información necesaria para dar créditos adecuadamente, y conoce cuánto tiempo lleva cada una de las tareas. Esta información será beneficiosa para este y otros proyectos.
7. Flexibilidad: no seas literal y acerca el mensaje a tu público
Este punto está relacionado directamente a la localización. Examina los ejemplos, código fuente, datos, expresiones idiomáticas, poemas, canciones, deportes, metáforas y analogías incluidas en tu material fuente. Se trata de ítems que no pueden ser traducidos literalmente (y en ellos usualmente fallan las aplicaciones de traducción por inteligencia artificial). ensu lugar, haz una propuesta de traducción que permita entender el significado de la expresión y que, a la vez, sea lo más fiel posible al significado del texto original para tu público destinatario. Puedes preguntarle a una persona bilingüe o a quien escribió el trabajo por el significado de la frase. También, puedes adaptar los ejemplos usando datos regionales y artistas o ejemplos culturales locales.
En el libro T3 hay un ejemplo que usa la geografía de Canadá, el cual decidimos reemplazar por un ejemplo de Latinoamérica:
En un fragmento de código de R4DS para enseñar bucles, reemplazamos la canción “Ten green bottles” (traducción literal “Diez botellas verdes”) por “Cinco ranitas verdes” que es la versión en español de la canción. También tradujimos todos los datos de los propios ejercicios, incluyendo los nombres de las variables, las monedas, el formato de las fechas y las unidades de medición. En T3, usamos un poema de María Elena Walsh en un código para enseñar funciones.
8. Diversidad lingüística
Un idioma diverso necesita un equipo de traducción diverso. Algunas lenguas tienen dialectos o variaciones regionales. Por ejemplo, el término en inglés “green beans” podría traducirse de muchas formas posibles en países hispanoparlantes: chauchas, porotos verdes, ejotes, vainitas, vainicas, judías verdes, habichuelas, alubias verdes… En algunos países se usan más anglicismos en los textos técnicos que en otros. Con personas de distintos países traduciendo y revisando un mismo texto original, estas diferencias idiomáticas surgirán durante el proceso y, trabajando en comunidad, podrán tomar la decisión que mejor se adapte al público al que va dirigido.
Parte de los acuerdos que harás será decidir qué dialecto o variación regional del lenguaje se utiliza (R4DS, T3 y rOpenSci usan convenciones latinoamericanas para las traducciones al español) y qué palabra usar cuando el término tiene más de una opción posible (es una buena idea votar en el equipo y/o en la comunidad). También tienes que decidir en detalles como el género gramatical a usar en conceptos técnicos que no tienen una traducción (o sí la tienen, pero han decidido no traducir); por ejemplo, ¿el operador del lenguaje R “pipe” es la pipe o el pipe?
Los acuerdos deben ser documentados (ver sección 3) para construir una memoria de la traducción y localización que pueda ser reutilizada y mejorada.
9. Crea un glosario bilingüe
Un glosario bilingüe contribuye a la memoria de localización de la comunidad. Puede ser tan simple como un archivo CSV con el listado de términos en el idioma de origen y su equivalente en el idioma de destino, o también puede contener las definiciones en uno o más lenguajes. Existen varias iniciativas: para T3, construimos un diccionario inglés-español de términos de educación y pedagogía para la tecnología [^10]; para rOpenSci, estamos elaborando un glosario inglés-español de términos sobre desarrollo de software de investigación; y The Carpentries cuenta con el proyecto glosario, un diccionario de términos de ciencia de datos en más de 20 idiomas.
10. Construye una comunidad alrededor de la traducción
El documento de gobernanza mencionado en la sección 3 describe los roles, estructura, organización del trabajo y todos los documentos necesarios para realizar las traducciones. Por ejemplo, en T3 organizamos el equipo de traducción con una coordinadora, dos editoras, una traductora por capítulo y dos revisoras por capítulo. También decidimos discutir los conflictos de traducción en un canal de Slack. Si no llegábamos a un consenso, le consultábamos a la comunidad a través de redes sociales o de issues en GitHub. Además de los roles de quienes participan, necesitas acordar y documentar:
- Un espacio para que la comunidad interactúe: puede ser un canal o equipo de trabajo de Slack/Discord o el repositorio GitHub/Gitlab del proyecto. También puedes tener reuniones sincrónicas para trabajar y para compartir logros del proyecto y de cada integrante del equipo.
- Declaraciones de accesibilidad y diversidad: por ejemplo, asegurarse de que las imágenes tienen texto alternativo, utilizar paletas de colores que consideren la ceguera de color, permitir el acceso abierto, usar un formato abierto compatible con tecnología de asistencia como los lectores de pantalla.
- Un código de conducta: y una forma clara de reforzarlo.
- Citas, atribuciones y licencia. Las personas que traducen tienen autoría sobre los contenidos traducidos. En T3, mencionamos quiénes fueron las traductoras y revisoras debajo del título de cada capítulo y agregamos al libro un capítulo “Sobre la traducción” [^11] con una breve descripción del proyecto y de todas las participantes. También publicamos las “Guías de traducción” con todas las personas que contribuyeron como autoras [^12]. Finalmente, agregamos una cita sugerida para la versión en español del libro, de acuerdo a las contribuciones relativas a lo largo del proceso de traducción [^11].
Por último, pero no menos importante, construir una comunidad también significa priorizar el bienestar del grupo y que las personas participen en proyectos laterales derivados de la traducción. Algunas de las formas en que puedes ayudar a construir una comunidad, además de discutir la gobernanza, trabajar en la traducción en sí misma y tener reuniones sociales, pueden ser ponerle un nombre al grupo y crear un logo, compartir nuestras preocupaciones y apoyar a las demás personas, difundir el proceso de traducción en redes sociales y dar y recibir retroalimentación. Sin olvidar los consejos anteriores sobre la motivación y sobre que la traducción sea el foco, es genial si el grupo puede realmente disfrutar y aprender durante el proceso, divertirse mientras trabaja, celebrar los logros y, ¿por qué no?, ¡hacer nuevas colaboraciones y amistades!
Conclusiones finales
El trabajo hacia una ciencia de datos multilingüe a través de traducciones y localizaciones es un paso crucial para eliminar las barreras lingüísticas y garantizar que el conocimiento y las innovaciones en ciencias de datos no estén restringidas a un grupo selecto de individuos que hablan un determinado lenguaje. Esta información debe estar al alcance de todas las personas!. Los materiales multilingües y los procesos de traducción comunitarios ayudan a avanzar el campo de la ciencia de datos y permiten colaboraciones mayores y globales, así como el intercambio de ideas entre cientistas de datos con diferentes antecedentes y orígenes y de diferentes regiones, mejorando a la disciplina en su conjunto.
Ahora piensa en tu libro o material preferido de ciencia de datos: ¿eres consciente de la importancia de que otras personas accedan a ese contenido? ¿Cómo puedes ayudar a hacerlo disponible para ellas? Al trabajar en conjunto, podemos crear una comunidad de cientistas de datos más diversa e inclusiva, y fomentar un sentido de comunidad y de colaboración en la disciplina.
Bio: Yanina Bellini Saibene es Community Manager de rOpenSci y directora del proyecto R-Ladies. Enseña técnicas de programación desde 1993. Es cofundadora de MetaDocencia y LatinR y miembro del Consejo Ejecutivo de The Carpentries. Dirige el proyecto multilingüe de rOpenSci y es coeditora de la traducción de Teaching Tech Together. Es voluntaria para llevar R4DS, las lecciones de The Carpentries, el material de R-Ladies y Posit Cheatsheets al público hispanohablante.
Natalia Soledad Morandeira es doctora en ciencias biológicas e investigadora del Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) y actualmente trabaja en el Instituto de Investigación e Ingeniería Ambiental de la Universidad Nacional de San Martín (Buenos Aires, Argentina). Sus temas de investigación incluyen la ecología de humedales, la ecología del paisaje y la teledetección. Es profesora de un curso de Ecología para Ingeniería Ambiental. Fue coeditora de la traducción al español del libro Teaching Tech Together y también forma parte de la comunidad latinoamericana de R. También es escritora de ficción. Referencias
- Richter, F. English is the internet’s universal language. Statista https://www.statista.com/chart/26884/languages-on-the-internet/ (2022).
- Carter, H and J. Groopman, “Diversity, Equity, and Inclusion in Open Source: Exploring the Challenges and Opportunities to Create Equity and Agency Across Open Source Ecosystems,” foreword by Jim Zemlin, The Linux Foundation, December 2021.
- Odilli Uchidiuno, J. , Ogan, A., Yarzebinski, E. & Hammer, J. Going Global: Understanding English Language Learners’ Student Motivation in English-Language MOOCs. International Journal of Artificial Intelligence in Education vol. 28 528–552 Preprint at https://doi.org/10.1007/s40593-017-0159-7 (2018).
- Pigott, D.. HOPL, the history of Programming Languages. Wikipedia, The Free Encyclopedia https://en.wikipedia.org/w/index.php?title=Non-English-based_programming_languages&oldid=1130348995 (2006).
- Bellos, D. Is That a Fish in Your Ear?: Translation and the Meaning of Everything. (Macmillan, 2011).
- Quiroga, R. ‘The development of {datos} package for the R4DS Spanish translation’. https://rivaquiroga.cl/es/charlas/2020-rstudio-conf.html (2020).
- Multilingual Publishing. https://ropensci.org/multilingual-publishing/.
- Wikipedia contributors. Internationalization and localization. Wikipedia, The Free Encyclopedia https://en.wikipedia.org/w/index.php?title=Internationalization_and_localization&oldid=1125663076 (2022).
- Guía para el uso de un lenguaje no sexista e igualitario en la Honorable Cámara de Diputados de la Nación Argentina. https://www4.hcdn.gob.ar/dependencias/dprensa/guia_lenguaje_igualitario.pdf
- Bellini Saibene, Y. English-Spanish dictionary of educational technology terms. https://yabellini.shinyapps.io/T3Glossary/.
- Wilson, G. 2021. “Enseñar tecnología en comunidad. Cómo crear y dar lecciones que funcionen y construir una comunidad docente a su alrededor” [Teaching Tech Together. How to create and deliver lessons that work and build a teaching community around them] (Spanish translation: Y. Bellini Saibene, N.S. Morandeira, P. Corrales, L. Acion, M. Dermit, Y. Sosa, J. Benitez Saldivar, Z. Bazurto, S. Canelón, L. Canaviri Maydana, M. Alonso, A. Bellini, P. Minotti, R. Chirinos, P. Rojas, N. Stroud, R.N. Villafañe, P. Loto, A.L. Diedrichs, Y. Terrazas-Carafa & L. Rodríguez Planes). https://teachtogether.tech/es/ (Original English work published in 2019).
- Bellini Saibene, Y, N.S. Morandeira; P. Corrales; L. Acion; M. Dermit; Y. Sosa; J. Benitez Saldivar; Z. Bazurto; S. Canelón; L. Canaviri Maydana; M. Alonso; A. Bellini; P. Minotti; R. Chirinos; P. Rojas Saunero; N. Stroud; R.N. Villafañe; P. Loto; A.L. Diedrichs; Y. Terrazas-Carafa; L. Rodríguez Planes. 2022. “Orientaciones para la traducción al español de Enseñar Tecnología en Comunidad”. doi:10.5281/zenodo.7261895