por Usamos un programa libre, encontramos un botón mal traducido o seguimos una ayuda que ya no coincide con lo que aparece en pantalla. Lo habitual es buscar cómo salir del paso y continuar. Pero ese pequeño problema también puede ser nuestra primera contribución al proyecto, aunque no sepamos escribir una línea de código.
A mí me parece que, cuando hablamos de colaborar con el software libre, ponemos demasiado pronto la programación en el centro. Una persona que consigue explicar bien un fallo, revisar una traducción o corregir un paso de la documentación puede ahorrar bastante trabajo a quienes mantienen el programa. Vamos a ver cómo hacerlo, empezando por algo que tengamos delante y podamos terminar.
Empezar por un programa que ya utilizamos
No hace falta buscar el proyecto más conocido ni apuntarnos a cinco comunidades. Es más fácil ayudar en una aplicación que conocemos: sabemos qué intentábamos hacer, reconocemos sus menús y podemos comprobar si una explicación se entiende. Quien utiliza un programa para una tarea concreta también ve problemas que quizá no aparecen en las pruebas de sus desarrolladores.
Desde la web oficial buscamos el apartado de comunidad o colaboración. Si nos lleva a un repositorio, leemos su archivo CONTRIBUTING o sus instrucciones para participar. Allí debería quedar claro dónde se comunican los errores, quién revisa las traducciones y cómo proponer cambios. GitHub es una posibilidad, pero también encontraremos GitLab, Bugzilla, foros y listas de correo.
Antes de abrir una incidencia, conviene distinguir una duda de uso de un fallo. «¿Cómo exporto este documento?» suele encajar en el foro de ayuda. «Al exportar este documento desaparece una imagen» puede necesitar un informe de error. Si no sabemos cuál de las dos cosas está ocurriendo, preguntar en el canal de soporte es un buen comienzo.
Cómo informar de un error para que puedan investigarlo
Decir que un programa va mal deja muchas preguntas pendientes: qué versión tenemos, qué hicimos antes, qué esperábamos y qué pasó. La guía de Mozilla para informar de errores da mucha importancia a los pasos para reproducirlos. Es una buena referencia aunque el problema esté en otro programa.
Imaginemos que un visor se cierra cuando intentamos abrir una segunda imagen. En vez de escribir «el visor no funciona», podemos preparar un informe como este. Es un ejemplo de redacción; los datos entre corchetes se sustituyen por los de nuestro caso:
Título: El visor se cierra al abrir una segunda imagen PNG Programa y versión: [nombre y versión exacta] Sistema: [distribución y versión] Instalación: [repositorio, Flatpak u otra procedencia] Pasos: 1. Abrir el visor sin ningún archivo cargado. 2. Abrir la primera imagen PNG desde el menú Archivo. 3. Sin cerrar el visor, abrir la segunda imagen del mismo modo. Resultado esperado: Se muestra la segunda imagen y podemos continuar usando el visor. Resultado observado: La ventana se cierra al seleccionar la segunda imagen. Frecuencia: [Siempre, algunas veces o sólo con estos archivos.] Archivos adjuntos: [Ejemplos sin información privada que permitan repetir el problema.]
El detalle de abrir desde el menú importa. Hacer doble clic en el gestor de archivos puede seguir otro camino. Tampoco es lo mismo que desaparezca la ventana a que siga abierta pero no responda. Describimos lo que vemos; si sospechamos una causa, la dejamos como sospecha.
Antes de enviarlo, buscamos si ya existe un informe parecido, incluyendo incidencias cerradas. Las instrucciones de GNOME también piden comprobar la versión afectada y mantener cada informe centrado en un problema. Si encontramos el mismo fallo, añadimos información nueva al hilo correspondiente en vez de repartirla entre varios informes.
Reducir el ejemplo y comprobar una corrección
Si el fallo depende de un documento, podemos trabajar sobre una copia y quitar lo que no haga falta. Volviendo al visor, interesa comprobar si ocurre con cualquier pareja de imágenes o sólo con dos archivos concretos. En una hoja de cálculo, quizá podamos eliminar varias pestañas y dejar la celda que da problemas. Después de cada cambio repetimos los pasos: un archivo pequeño que ya no provoca el fallo ha dejado de servir como ejemplo.
No adjuntamos una factura de un cliente ni un documento de trabajo para ahorrar tiempo. Preparamos datos de ejemplo, revisamos los metadatos y miramos lo que aparece en las capturas. Una ventana de error puede mostrar nuestro nombre de usuario, rutas o direcciones que no necesitamos publicar. Si se trata de una posible vulnerabilidad, buscamos el canal de seguridad del proyecto antes de subir detalles a una incidencia pública.
También podemos ayudar sin descubrir un error nuevo. Si alguien propone una corrección, repetimos los pasos del informe en la versión que nos indique y contamos el resultado. Es mucho más útil escribir «con esta versión y estos dos archivos ya no se cierra» que «parece que todo funciona». Una comprobación concreta no demuestra que el programa entero esté libre de fallos, pero permite avanzar en ese problema.
Traducir al español sin romper lo que traduce el programa
Una traducción no consiste únicamente en cambiar palabras del inglés al español. Necesitamos saber dónde aparece el texto. Open puede ser la acción «Abrir», pero en otro contexto puede describir algo «Abierto». Si sólo vemos una frase aislada, buscamos una captura, la explicación de la cadena o el comentario del equipo antes de decidir.
En proyectos que utilizan Weblate podemos encontrar cadenas pendientes y proponer traducciones desde el navegador, según los permisos del proyecto. Su documentación para traductores explica las sugerencias, el contexto y las comprobaciones. No todos los equipos trabajan igual: GNOME utiliza Damned Lies y su guía de traducción recomienda consultar las normas del equipo de idioma y escoger un módulo pequeño que no esté reservado.
Hay que conservar los marcadores que el programa sustituye por datos. Por ejemplo, si el original es Could not open {filename}, una propuesta sería No se ha podido abrir {filename}. Escribir {nombrearchivo} puede parecer una traducción más completa, pero cambia el nombre de una variable que la aplicación espera encontrar.
Revisamos también singular y plural, espacio disponible y vocabulario del proyecto. Si todos sus menús dicen «carpeta», introducir «directorio» en un botón sin necesidad puede confundir. Un traductor automático o una IA puede ayudarnos a preparar una propuesta, pero antes de enviarla hay que leerla en contexto y comprobar los marcadores. Prefiero cinco cadenas bien revisadas a una tanda enorme que otra persona tenga que corregir.
Corregir una ayuda que ya no coincide con la pantalla
La documentación suele dar por sabidos pequeños pasos que quien empieza todavía no conoce. Una indicación como «exportar desde el menú correspondiente» resulta cómoda para quien lleva años usando el programa, pero no ayuda a localizar ese menú. Podemos proponer el recorrido concreto, indicar el formato que debe elegirse y explicar cómo reconocer que el archivo se ha guardado.
Si encontramos una instrucción antigua, anotamos la página, el apartado y la versión con la que la hemos comprobado. Por ejemplo: «La ayuda indica pulsar Guardar, pero para obtener un PDF en esta ventana hay que elegir Exportar». Adjuntar el párrafo de sustitución y una captura de esa ventana permite revisar la corrección con menos preguntas.
No es necesario dominar Git para señalar ese cambio. El proyecto puede aceptar una incidencia de documentación, una propuesta en su wiki o un mensaje al equipo. Lo importante es comprobar el procedimiento con la versión adecuada. Si hacemos una captura nueva, cuidamos que los menús se lean y que no muestre archivos personales.
Dónde podemos empezar: LibreOffice, GNOME y GNU
La página de colaboración de LibreOffice reúne vías de documentación, traducción, diseño y control de calidad. También propone tareas pequeñas, como comprobar informes de errores o revisar sus preguntas frecuentes. Si ya utilizamos Writer o Calc, podemos empezar por una función que conozcamos y elegir una tarea en ese ámbito.
En Welcome to GNOME podemos buscar una aplicación y consultar sus vías de colaboración. Para una traducción conviene acudir al equipo de español; para un error, al proyecto que mantiene la aplicación. Así evitamos enviar un problema de un programa concreto a un canal general donde nadie tenga la información necesaria.
GNU también explica cómo ayudar con las traducciones de su web y otras tareas. Si nos interesa la parte más relacionada con las libertades del usuario, es una forma de participar en el proyecto que impulsó buena parte del movimiento. Para situarnos, tenemos en la web una historia del movimiento del software libre.
Elegir una tarea pequeña y dejarla terminada
Yo empezaría por una sola cosa: reproducir una incidencia que ya esté abierta, proponer una traducción con contexto o corregir un paso de una ayuda. Leemos las instrucciones, comprobamos que nadie esté trabajando en lo mismo y preparamos una aportación que otra persona pueda revisar sin tener que adivinar qué intentábamos hacer.
Después conviene volver al hilo. Quizá nos pidan la versión exacta, un archivo más pequeño o cambiar una palabra para mantener el criterio del equipo. Esa respuesta forma parte de la colaboración. Tampoco hace falta insistir cada día: el proyecto puede tener más trabajo pendiente que personas disponibles.
Las libertades que explicamos al hablar de qué es el software libre permiten estudiar, modificar y compartir los programas. Podemos aprovecharlas para participar sin convertirnos primero en desarrolladores. Si esta semana encontramos una ayuda equivocada o un texto que cuesta entender, ya tenemos por dónde empezar.
Y si ya habéis colaborado con algún proyecto sin programar, contadlo en los comentarios. Puede ser una buena pista para quien todavía no sabe dónde dar el primer paso.
