Mientras reviso traducciones, a veces me encuentro que se añaden cosas que no están presentes en el original. Aunque en algunos casos es una buena decisión del traductor, por mi experiencia es bastante más seguro no añadir nada a menos que haya una buena razón. Te lo cuento en el vídeo de hoy. 🙂
¡Felicitaciones por otro nuevo video de estos, Pablo!
Estoy completamente de acuerdo contigo en no agregar nada en las traducciones de interfaces propiamente dichas, por todas las razones que das.
Distinto considero el caso del material didáctico, incluso sobre software. En ayudas o manuales sí puede ser conveniente añadir, ya sea por un exceso de anglocentrismo en tal material o, menos frecuente pero no raro, que haya cuestiones que un desarrollador extranjero, al no ocurrir determinada circunstancia en su idioma de SO, éste simplemente no la tenga prevista.
Como ejemplo de lo último, en un tema de la ayuda de un programa de TTS ruso se indica que ciertos diccionarios se buscan en cierta subcarpeta de Program Files\Common Files. Puesto que incluso en la última versión el programa es expresamente compatible con todas las versiones de Windows desde XP a 10 y que en XP y anteriores los nombres de ciertas carpetas cual las mentadas se traducían realmente, al traducir esa ayuda consideré conveniente aportar una explicación breve de que en Windows XP los nombres de las carpetas están traducidos y es preciso escribir «Archivos de programa» y «Archivos comunes». Y es que si sin esta explicación yo dejaba «Program Files» y «Common Files», quienes usaran el programa en XP habrían recibido un mensaje de error si intentaban pegar la ruta para ir directamente en el cuadro Ejecutar; si traducía «Archivos de programa» y «Archivos comunes», este mismo problema lo tendrían en cambio quienes lo usaran en Vista o superiores, pues bien sabes que en estos últimos SO los nombres traducidos son en realidad una ilusión, cadenas que se buscan en Shell32.dll —en el idioma en uso— por medio del valor de LocalizedResourceName en los archivos Desktop.ini que hay en las carpetas.
De anglocentrismo excesivo, aunque abundan los ejemplos, puedo mencionarte el manual didáctico —distinto del avanzado a efectos de consultas puntuales— sobre el lenguaje de scripts del lector de pantalla JAWS. Por desgracia la empresa sólo traduce la ayuda del programa en sí, de modo que en cuanto a lo demás toca esperar o hacer uno mismo aportes de la comunidad. En varias secciones tuve que agregar explicaciones, por ejemplo sobre las restricciones para nombres internos en scripts, funciones, constantes, variables y referencias a mensajes: el manual dice que sólo se admiten letras, números y guiones bajos, y que al crear scripts y funciones el IDE comprueba y hace ruido si se intenta poner algún espacio u otro símbolo no admitido; el problema es que advertí que esta comprobación no salta si se escriben acentos o eñes, aunque sí producen luego un error al compilar, razón por la cual en la traducción informo (sin decir que es un problema del desarrollador pues, por muy comunitaria y de aficionado que sea la traducción, el resultado pierde seriedad si me pongo a escribir «como esto está mal hecho…») sobre dicha circunstancia. En un ejercicio de otro capítulo debí agregar una línea de código extra a la solución, sencillamente porque, como está originalmente, en español el ejemplo no funciona según lo esperado, lo cual es de toda lógica si se tiene en cuenta que ese ejercicio en concreto, en vez de con acceso mediante programación, trabaja con base en texto en pantalla de una interfaz que, a diferencia del manual didáctico, la propia empresa sí tradujo.
En los archivos de documentación que este IDE usa entre otras cosas para mostrar información de funciones en el diálogo «Insertar función» había algunas —por suerte no tantas— con referencias explícitas sólo al inglés, de modo que también les añadí la información equivalente con el dato pertinente para el español. En efecto: en la descripción de un parámetro en que se pide el idioma del texto al que hacer OCR como ejemplo sólo dice «English is 1033», así que consideré oportuno traducir esa oración —que está a punto seguido de otra más general que no plantea problemas— como «Inglés es 1033 y español 3082»; similar es el ejemplo de la sintaxis de la función SetSynthLanguage, que en inglés sólo reza «Example: SetSynthLanguage (“American English”)» y yo transformé en «Ejemplos: SetSynthLanguage (“American English”), o SetSynthLanguage (“Castilian Spanish”)». Ejemplificar con Castilian y no Latin American fue adrede, porque Castilian Spanish es la variante de voz predeterminada al usar el programa en español del mismo modo que, pese a incluirse también una variante British English, la predeterminada al usarlo en inglés es la voz con acento de EEUU.
Pero lo dicho, en lo que son las interfaces te banco a muerte en que no se agregue nada.
Nuevamente gracias por compartir desinteresadamente tantas reflexiones y perdón por el comentario tan largo. A modo de posibles sugerencias, se me ocurre que la próxima podrías hablar de «settings» o «feedback», términos que pese a parecer sencillos convendrás que, reflexionados a fondo, no lo son tanto.
¡Saludos y buena semana desde Argentina!
¡Hola, Fernando!
Muchas gracias por tu comentario. No te preocupes, que sea largo de hecho permite detallar al máximo lo que quieres decir. 🙂
En efecto, siempre hay casos particulares en los que es preciso añadir cosas, como cuando algo solo está en inglés y se advierte al lector/usuario de que no se encuentra traducido. Mi mensaje iba sobre todo porque a veces veo que alumnos míos presuponen demasiadas cosas del lector y añaden cosas que no hacen ninguna falta, y muchas veces introducen errores que se podrían haber ahorrado.
Otro amigo me comentó también al ver el vídeo que algunas veces tiene que añadir cosas porque en el inglés no están bien expresadas o son ambiguas. Mi experiencia después de trabajar con varias empresas es que en este caso siempre se debe informar al cliente de que algo está mal en el original para cambiarlo y volver a enviar el segmento cambiado a traducir, ya que afecta a todos los idiomas al ser un tema de contenido más que de estilo. Sé que a algunos clientes al final les da igual, pero por suerte la gente con la que trabajo se lo toma en serio y hacen eso: si de verdad ven que hay un fallo en el original, lo vuelven a enviar a traducir (pagando). De lo contrario, puede haber diferencias importantes de contenido entre diferentes idiomas, y si hay buen control de calidad, tarde o temprano se descubre el pastel. Me da mucha rabia cuando ves en la herramienta de informes de bugs que todo el mundo ha arreglado el problema menos un idioma, que dice que está bien en su caso porque ya lo habían detectado en una versión anterior. ¡Haber avisado entonces, hombre! 🙂
Con respecto a tus sugerencias sobre «settings» o «feedback», me lo apunto en mi lista de temas, me parece que ofrecen mucho juego. ¡Muchas gracias! 🙂
Un saludo y gracias por comentar como siempre,
Pablo
¡Hola de nuevo, Pablo!
Vaya, ahora me queda mucho más claro el ámbito de tu recomendación en este video.
Aparte de que ciertamente contribuye mucho a la calidad del producto traducido que las cadenas originales sean claras y de no serlo se pueda preguntar al desarrollador con confianza de que te contestará en un tiempo razonable y no te sacará cagando si hay que hacer algún cambio, supongo que como profesional debe serte un gusto trabajar con clientes así.
Como experiencia personal sobre la necesidad de hacer cambios, recuerdo una vez que al AIDA64 (no es confidencial que hace algunos años lo traduzco, de hecho figuran mi nombre y correo electrónico como mantenedor del archivo en español) le agregaron una cadena, destinada a mostrarse gráficamente en información de origen SMART, que literalmente decía «Power Up Time». Cuando tuve que traducirla al español no sabía si se refería al tiempo total en que un disco duro tarda en encenderse hasta alcanzar la velocidad de giro máxima, al tiempo continuo durante el que estuvo encendido o la hora de la última vez que se había encendido y, aparte de este trilema, si la respuesta a lo anterior era el tiempo durante el que estuvo encendido, si esa cadena se refería sólo a discos duros o en general a cualquier unidad que proporcione información SMART, determinante ello de si usar «encendido» (disco duro) o «encendida» (unidad en general): como ves, una cadena de lo más ambigua cuya mala traducción podía tener consecuencias poco menos que desastrosas para la percepción del usuario. Por suerte en FinalWire tienen muy buena predisposición para estas cosas y no sólo me explicaron pormenorizadamente el significado de la cadena sino que, advirtiendo la falta de claridad incluso en inglés, pese a que provisionalmente traduje la que estaba según las indicaciones que me habían dado, en una versión posterior mejoraron la propia cadena en inglés, cambio del que también se beneficiaron la traducción al español y seguramente las hechas a otros idiomas.
¡Saludos y gracias por el intercambio!
¡Qué buena anécdota, Fernando! Está bien saberlo. Y oye, ¡no sabía que traducías el AIDA64! Recuerdo que antes siempre lo usaba cuando quería estar al tanto de cómo iba todo en mi equipo. 🙂
Un saludo y estamos en contacto,
Pablo
Pues sí, Pablo, me encargo de traducirlo desde 2011. Diríase que fue casualidad, porque cuando lo descargué en una PC que hube comprado ese año y se me dio por ver más detalles que los dos o tres que en un equipo conocido compruebo con frecuencia, me di cuenta de que había muchas cadenas sin traducir y diferencias de criterio y, cuando fui a ver el archivo de idioma en español, decía que estaba desmantenido y buscaban a alguien que pudiera ocuparse de eso. Fue una decisión de que disfruto hasta hoy día, tanto más por mis aficiones a la lengua y a las TI que porque me den licencias para todas las ediciones.
¡Saludos y sigue así!