El otro día, mientras revisaba un proyecto, me encontré con el sitio web de Material Design, un conjunto de normas de diseño ideado por Google para crear aplicaciones de Android, aunque a día de hoy se extiende a cualquier plataforma.
Lo curioso es que desconocía que, aparte de las normas de diseño de la interfaz de una aplicación, también había una serie de normas de redacción de Material Design, que sin duda te recomiendo que consultes.
Así pues, y como complemento a los 15 mandamientos del traductor de software inglés-español de los que hablé hace un tiempo, lo que sigue a continuación son 5 hábitos inspirados en Material Design que espero que te ayuden a traducir las cadenas de interfaz de una aplicación móvil.
Índice de contenido
1. Sé breve
Menos es más. Tu traducción debe facilitar el escaneo rápido de los diferentes elementos textuales. Asimismo, no uses demasiados conceptos en una misma cadena de texto.
Ejemplo 1
Preferible: Envía dinero a cualquier persona de España que tenga una dirección de correo electrónico. Es rápido, fácil y gratis.
Desaconsejable: Envía (y recibe) dinero a (y de) amigos y familiares que residan en España y que dispongan de una dirección de correo electrónico. Es un proceso que conlleva dos pasos y con poca latencia, y los destinatarios no tienen que pagar nada.
Ejemplo 2
Preferible: Puedes obtener más información en el sitio web de X.
Desaconsejable: Si necesitas ayuda, te recomendamos encarecidamente que te dirijas al sitio web de X y consultes la información incluida para obtener más detalles.
2. No uses palabras complejas
Recuerda siempre la prueba de la abuela al traducir: la traducción de una aplicación móvil general debe poder entenderla cualquier persona con independencia de su nivel de compresión. No se trata de escribir «para tontos» como se suele decir, sino de evitar complicar el lenguaje innecesariamente con palabras demasiado sofisticadas para una aplicación. Y recuerda que el verbo «hacer» existe.
Ejemplo 1
Preferible: Debes desactivar la opción X.
Desaconsejable: Debes inhabilitar la opción X.
Ejemplo 2
Preferible: Esta acción guardará los cambios del documento.
Desaconsejable: Esta acción realizará un guardado de los cambios del documento.
3. Evita las nominalizaciones
Al traducir del inglés, es muy habitual dejar estructuras nominales tal cual en vez de usar verbos que facilitan la comprensión en español. Esto es fácil que ocurra, así que tenlo en cuenta al revisar tu traducción.
Ejemplo 1
Preferible: Este botón permite aplicar formato al texto.
Desaconsejable: Este botón permite la aplicación de formato al texto.
Ejemplo 2
Preferible: Esta aplicación puede ayudarte a dormir mejor.
Desaconsejable: El uso de esta aplicación puede ayudarte a dormir mejor.
4. Empieza con el objetivo de la frase
Cuando una frase describe un objetivo y la acción necesaria para lograrlo, es mejor seguir el sentido lógico de indicar primero el objetivo y explicar después cómo conseguirlo y no al revés. Esto es muy habitual en tutoriales y textos de ayuda, y se nota sobre todo en frases largas. Aunque parezca lo mismo, es más fácil procesar este orden lógico.
Ejemplo 1
Preferible: Para eliminar una foto de este álbum, arrástrala a la papelera.
Desaconsejable: Arrastra una foto a la papelera para eliminarla de este álbum.
Ejemplo 2
Preferible: Para enviarnos tu opinión, haz clic en «Enviar comentarios».
Desaconsejable: Haz clic en la opción «Enviar comentarios» para enviarnos tu opinión.
5. Utiliza lenguaje inclusivo
La sociedad avanza, y hoy en día creo que es importante utilizar lenguaje inclusivo en la medida de lo posible. No me refiero a usar «bienvenidos/as», «bienvenid@s» o «todxs», soluciones que no me convencen. Tampoco hay que obsesionarse y utilizar frases rebuscadas que al final dificultan la comprensión, pero en la mayoría de los casos, al menos en el lenguaje típico de las aplicaciones móviles, suele haber una solución neutra sencilla y efectiva.
Ejemplo 1
Preferible: Te damos la bienvenida a tu cuenta.
Desaconsejable: Bienvenido a tu cuenta.
Ejemplo 2
Preferible: ¿Seguro que quieres continuar?
Desaconsejable: ¿Estás seguro de que quieres continuar?
—
¿Qué te han parecido estas recomendaciones? ¿Las sueles seguir? ¡No olvides dejarme un comentario para conocer tu opinión!
Por si te interesa, tengo un curso online sobre localización de aplicaciones móviles. Échale un vistazo si quieres. 😉
¡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!
¡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
¡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!
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
Veamos q tal sale