5 buenos hábitos al traducir aplicaciones móviles

5 comentarios

1. Fernando Gabriel Gregoire dice:

   29-10-2018 al 22:34 pm

   ¡Qué bueno que hayas vuelto a escribir, Pablo!
   Sí, las normas Material Design están muy bien, incluidas las partes relativas a la redacción y buenas prácticas de localización. Es una lástima que Google si las tiene no publique, como hacen por ejemplo Microsoft y Facebook, guías de estilo específicas para cada idioma, y ni hablar de cuánto es de lamentar que de productos de Google no exista —para ser consistentes con el SO en nuestras traducciones— una base de datos terminológica como la del portal lingüístico de Microsoft.
   Respecto del lenguaje inclusivo, para las frases superhabituales cual la del segundo ejemplo es mucho más factible en aplicaciones móviles, dada su informalidad. En aplicaciones para PC enfocadas a la productividad que son más formales ello es más difícil, porque prescindir del verbo (¿Seguro que…?) tiene cierto aire coloquial.
   Respecto de enunciar primero el objetivo y después la manera de lograrlo, en general es la mejor aproximación. Hay una excepción notoria bastante común, que es la de mensajes de ayuda emitidos por lectores de pantalla, donde —para el caso de dispositivos sin teclado físico— a menudo el usuario no necesita ayuda sobre qué hace determinado control porque ésta la dan la etiqueta o el propio contexto de la interfaz, sino sobre cuál es el equivalente de determinado gesto estándar cuando un programa de accesibilidad tiene «secuestrada» la pantalla. En otras palabras, si en la app se respeta el punto 4 de esta entrada, cada control y el resto de elementos de interfaz que lo rodean deja claro lo que hace, de ahí la conveniencia de invertir este orden en la información específica de accesibilidad que, en el curso del uso normal, se anuncia después de aquella de carácter general. Cuando en las últimas versiones uno recibe una llamada de WhatsApp, por ejemplo, puesto que la etiqueta del botón dice «Botón para responder la llamada», el mensaje que no se ve en pantalla pero que emite TalkBack al llegarse a este botón es «Toca dos veces para aceptar la llamada», pues al acabarse de decir «Botón para responder la llamada» haría perder tiempo que el mensaje de ayuda empezase «Para aceptar la llamada,…». Para accesibilidad de Android en general, así como en casos muy específicos dentro de aplicaciones de la propia Google —entre los que ahora recuerdo el suplicio que supone atender una llamada telefónica normal—, se aplica el mismo principio.
   Un error que veo bastante en cuanto a este punto 4 en aplicaciones para Android es que traducen etiquetas accesibles —que en principio no son descripciones de cómo se activan— de los controles incluyendo primero el tipo de control (botón, cuadro de edición etc.) y después el nombre. Si bien esto parece lógico pensando en la gramática, por defecto es práctica común de muchos lectores de pantalla —TalkBack incluido— leer primero el nombre del control y después el tipo, por ejemplo, «Aceptar botón», pues cuando uno explora una interfaz lo primero en que se fija es en que haya algo relacionado con lo que busca, recién después cómo debe interactuar con eso que haya encontrado. Si bien en controles estándares TalkBack atiende a esto según los «ajustes de verbosidad» de cada usuario, en el caso de controles personalizados que el desarrollador debe ocuparse de hacer accesibles hay que introducir toda la etiqueta a mano y ello incluye traducirla. Así, por ejemplo: si algún día en un juego que el desarrollador se haya ocupado de hacer accesible te encuentras con un icono de diario o tarjeta de memoria que en el archivo de cadenas se describa como «Save Game button», no caigas en la tentación de traducirlo «Botón para guardar la partida» y en su lugar ponle «Guardar partida, botón». La coma en este caso no es práctica extendida en otros lectores de pantalla, pero TalkBack sí la incluye en la salida entre el nombre de un control y el tipo para que la síntesis haga una pequeña pausa.

   ¡Abrazo desde Argentina y no dejes de escribir!

   Responder
2. Pablo Muñoz Sánchez dice:

   31-10-2018 al 7:58 am

   ¡Hola, Fernando!

   Me apetecía escribir una entrada en esta ocasión en vez de hacer un vídeo. Hay que variar un poco. 🙂

   Sí, es cierto que es una lástima que Google no publique sus guías de estilo ni su terminología. Para Android, en su día publiqué un glosario al que se puede acceder libremente en realidad, pues las cadenas las tomé del repositorio que hay de AOSP: https://algomasquetraducir.com/glosario-de-android-ingles-espanol-y-memoria-de-traduccion-en-tmx/. A ver si lo actualizo cuando saquen Android 10, ja, ja, ja.

   En cuanto a lo del lenguaje inclusivo, yo creo que si el tratamiento es de usted, en realidad es más fácil no equivocarse, pues “usted” vale para masculino y femenino en muchos casos. Pero sí, entiendo lo que dices.

   No había contemplado el caso de los lectores de pantalla, así que te agradezco que lo hayas mencionado y lo hayas explicado tan bien. Tú mejor que nadie para razonar esto mismo, je, je. Intentaré tenerlo en cuenta si me salen cadenas de texto de accesibilidad. Ahí me parece mejor ser mucho más directo, como en los ejemplos que has mencionado. Como digo, tomo nota. 🙂

   Tampoco me había planteado para nada que se prefiera “Aceptar, botón” en lugar de “Botón aceptar”, aunque no sé por qué juraría que alguna vez he activado el TalkBack sin querer y he escuchado precisamente esa misma estructura que recomiendas. A lo mejor en realidad se combinan cadenas para evitar ponerlo mal, al menos en las aplicaciones en las que he trabajado. Desde luego, nunca he recibido recomendaciones o instrucciones como esta en un proyecto de cadenas de accesibilidad.

   Sin duda, me has ayudado mucho con tu comentario a entender mejor las necesidades de accesibilidad al traducir cadenas de una aplicación móvil. Seguro que me acuerdo de ti cuando me salgan nuevas cadenas de este tipo. 🙂 Muchas gracias por tu ayuda, y espero que los lectores también hayan aprendido de ti. Como siempre digo, al final a veces se aprende más de los comentarios que de la entrada original, je, je.

   Un saludo,

   Pablo

   Responder
   • Fernando Gabriel Gregoire dice:

     31-10-2018 al 23:03 pm

     ¡Hola de nuevo, Pablo!
     Pues vaya, no me había puesto a pensar en que en cierto modo fuese más fácil utilizar lenguaje inclusivo en cadenas que ustedean, pero no te falta razón.
     Respecto de que las cadenas de accesibilidad se combinen, justamente así proceden en tiempo de ejecución los lectores de pantalla ante controles de alguna clase estándar, que como las propias herramientas de accesibilidad manejan por sí mismas no hace falta contemplar específicamente en el código. Este error de traducción que te cuento ocurre ante controles de clases no estándares que, para que sean accesibles, el desarrollador tiene que codificar información de accesibilidad a mano. Lo ideal sería, como dices, que fuera práctica común combinar cadenas en tiempo de ejecución para esto y, en vez de incluirlo en los archivos de recursos traducidos, incluir en éstos sólo tipos de control aislados que se combinen de la manera que tenga configurada el usuario, pues si miras los ajustes de verbosidad de TalkBack verás que para el «Orden de descripción de los elementos» hay varias alternativas… pero bueno, con que al menos se tenga en cuenta el orden estándar predeterminado estamos bastante bien.

     Menudos minutos de frustración te habrás llevado cuando activaste TalkBack sin querer, sobre todo si no leíste bien el mensaje de advertencia que antes de aceptar te explica cómo desactivarlo una vez que cambiaron todos los gestos, ja ja. A poco que busques en YouTube verás que no eres el único al que le ha pasado y es más, varios conocidos que trabajan en atención al cliente de operadoras de celular me contaron que ya tuvieron varias veces gente que como el teléfono no les respondía igual pensaban que se les había roto, ja ja. Para colmo, aunque no sé cómo andará eso en Android 7 y versiones posteriores, al menos hasta la 6 inclusive viene desactivada por defecto la posibilidad de suspender TalkBack rápidamente manteniendo apretadas las teclas de volumen tres segundos, de modo que quien no sepa moverse por el sistema con TalkBack o al menos llegar al «menú contextual global» (deslizamiento hacia abajo y la derecha) para elegir en éste la opción «Pausar notificaciones» de modo que se desactive de manera temporal a fin de hacer lo propio permanentemente desde los ajustes de la manera normal, la tiene dificilísima.

     Pues muchas gracias si piensas que a veces se aprende más con los comentarios que con las entradas propiamente dichas, aunque más bien hay que agradecerte a ti en la medida que no es nada fácil plantear un tema con tanto rigor como lo sueles hacer.

     ¡Un abrazo como siempre!

     Responder
3. Pablo Muñoz Sánchez dice:

   05-11-2018 al 16:58 pm

   Hola, Fernando:

   Ja, ja, ja, sí, la verdad es que tardé un tiempo en lograr desactivar lo de TalkBack. 😛 Pero bueno, ¡eso que aprendí! Hay que verlo de forma positiva. De hecho, alguna que otra vez me ha tocado volver a desactivarlo, ja, ja.

   Gracias de nuevo a ti por compartir tu sabiduría. 🙂

   Un abrazo,

   Pablo

   Responder
4. Edgar dice:

   23-08-2019 al 4:32 am

   Veamos q tal sale

   Responder