Cuando hablamos de control de calidad, conocido en el sector como QA (de Quality Assurance/Assessment), LQA (Quality Assurance/Assessment), testing o QC (Quality Check), la verdad es que podemos pensar en muchas cosas, y de hecho cada empresa tiene su manera particular de llamar a este proceso.
Quizás estés pensando ahora en lo importante que es utilizar herramientas específicas como Xbench o las herramientas de QA integradas en SDL Trados Studio o memoQ.
Por supuesto, estas comprobaciones automatizadas están realmente bien y considero que son esenciales.
Sin embargo, yo aquí me refiero a ver el producto final con la traducción que se ha hecho en contexto, porque es aquí donde incluso incluso una buena traducción se puede perfeccionar más todavía, por no hablar de que una mala traducción al menos puede quedar decente así.
Además, por muy buena que sea la traducción, siempre hay errores imprevisibles, como fallos funcionales, textos cortados, etc.
De todo esto ya hablé en ¿De quién es la culpa de una mala traducción?, pero espero que el vídeo de hoy te ayude a tener en cuenta qué es y por qué es tan importante el proceso de control de calidad en traducción y localización. 🙂
¡Enhorabuena por este video nuevo, Pablo!
En este caso encuentro mucho más enriquecedora la entrada a que enlazas que el video, pero en los tiempos que corren está bueno el video para llamar la atención de aquellos que, a raíz del mismo, decidan interiorizarse más.
Es verdad que, como usuario, uno no tiene que ser traductor para darse cuenta de que muchas cosas son fallos. La diferencia es que el usuario medio, quien cree que una traducción de software/juego/web se reduce a pasar el texto de un idioma a otro, piensa que la culpa es del traductor, pues no leyendo a gente como tú no concibe, por ejemplo, que en los archivos de recursos no se dé suficiente contexto o que haya cadenas compartidas; ese usuario medio, si es que se indigna, más bien pensará «¡Hijos de puta, son profesionales y escriben esta burrada!».
Sin entrar en el extremo de Microsoft con las teclas rápidas que más a menudo de lo deseable están pasando al inglés sin modificar las escritas en los menús (p. ej. un «Abrir» que funciona con CTRL+O pero sigue diciendo CTRL+A cuando lo ves en el menú «Archivo»), en software de multitud de fabricantes me da la impresión de que al sacar nuevas versiones los traductores pareciera que reciben cadenas aisladas, porque en menús se repiten letras subrayadas en distintas opciones y por ende activarlas no es lo rápido que en las versiones en inglés. Peor es cuando en algunas áreas se superpone la letra subrayada de algún control con otro acelerador metido en el código y una de las dos cosas —el acelerador codificado rígidamente o la opción con que entra en conflicto en un área dada— no se puede activar con teclas de acceso, aunque por suerte esto es menos frecuente. Claramente estas cosas, como dices, se evitarían si se hiciere más control de calidad.
En el terreno de los juegos, puedo aportarte dos problemas que he visto con cierta frecuencia en los audiojuegos:
Muchas veces, para ambientar estos juegos y que las voces propias de los mismos no se superpongan con los lectores de pantalla para ciegos —y de paso permitir descargarlos temporalmente para que no interfieran queriendo interceptar ciertas pulsaciones de teclas de forma que ralentizarían la jugabilidad—, tanto las opciones de menús como indicaciones respecto de los escenarios se leen con voces pregrabadas. A menudo lo único que se puede hacer es crear carpetas con los archivos de audio para un idioma determinado y encima para ahorrar espacio en disco hay veces que se forman frases en tiempo de ejecución concatenando varios archivos de audio, con lo que no es raro escuchar indicaciones con las palabras en el orden propio del inglés, por no hablar en estos casos de la imposibilidad de crear archivos distintos para adjetivos según el género del sustantivo al que acompañan. Así es que de repente uno puede escuchar, por ejemplo, «Requerido, amarillo, llave» por concatenarse pensando en el inglés «Required, yellow, key», sin que el traductor pueda cambiarlo pese a ser consciente del problema. El caso más flagrante de esto es el del número 1, que de traducirlo «uno» pensando en alguna opción de menú para especificar la cantidad de algo queda mal a la hora de emplearse el mismo archivo y leerse, por ejemplo, «uno hora».
El otro tema que cada tanto veo en los audiojuegos es que a nivel de código se le ocurre al desarrollador implementar el tiempo que debe transcurrir mientras se reproduce un archivo de audio dado antes de continuar con lo que sigue, en vez de simplemente esperar a que la reproducción termine. Cuando pasa esto y un archivo traducido dura más que el original, se trunca y obviamente ello arruina la experiencia. Recuerdo un programador de audiojuegos que en un «tower defense» necesitaba tener calculado cuánto duraba cada archivo de audio. Lo que hacía para permitir traducciones de la comunidad y evitar este problema era recomendar fervientemente no sobreescribir los archivos wav a mano y ofrecer, como parte del paquete del juego, un programa que permitía ir escuchando y actualizando los distintos audios y que se encargaba, al irlos actualizando, de anotar —en un fichero de texto plano con sintaxis especial— cuánto duraba cada archivo después de vuelto a grabar traducido con el micrófono.
En este sentido es mil veces preferible traducir audiojuegos que recurren para leer las cosas a motores TTS instalados en el sistema, porque cuando pueden traducirse tienen archivos de recursos como cualquier software y ello permite cambiar el orden de las variables o, si no es posible, intentar reformular ciertas frases. Reformular frases, por el contrario, es inconcebible en archivos de audio que se concatenan, encima en un orden anglocéntrico que a menudo no se puede controlar.
¡Un saludo y gracias por todo lo que compartes!
Hola, Fernando!
Sí, es normal que la entrada sea más completa, pero como bien dices, creo que es bueno ampliar el mensaje con otros formatos como el vídeo. 🙂
En efecto, el problema es que los que no son traductores, que son los usuarios que importan de verdad, no saben nada de lo que hay detrás de una traducción. Precisamente por eso también creo que tenemos que divulgar el mensaje lo máximo posible para que les llegue a ellos también.
Lo de las combinaciones de teclas y aceleradores es de órdago. Entiendo las primeras buenas intenciones, pero personalmente casi siempre me equivoco en Word pulsando Ctrl + F para buscar, o Ctrl + B para la negrita, y algo me dice que no soy el único… Pero bueno, entiendo que es difícil cambiar eso porque sí que habrá usuarios que solo usen Office y les chocará. A saber si tienen hecho un estudio o algo…
Qué curioso lo que comentas de los lectores de pantalla y los videojuegos. Parece que hay un gran margen de mejora, y espero que así sea en el futuro, pues hoy en día está bastante de moda el procesamiento de lenguaje natural para que se genere audio supernatural, como hacen Siri, Alexa o el Asistente de Google. Requiere un trabajo de ingeniería y lingüística brutal por lo que sé, así que si no es una prioridad ahora mismo, imagino que habrá que tener paciencia, pero todo se andará para el campo de los videojuegos…
Menuda historia lo de los audiojuegos que necesitan archivos que duren exactamente lo mismo, madre mía. Sé que alguna vez pasa con los juegos normales, pero como bien dices, sería mucho mejor confiar en un TTS. Si es que a veces la gente se complica de una manera…
En fin, ¡muchas gracias como siempre por comentar tus inquietudes y experiencias! La verdad es que tu comentario aporta muchas cosas al vídeo y a la entrada original. 🙂
Un saludo,
Pablo