En este artículo explicaré por qué probé a introducir a los diseñadores de UI a formar parte de las traducciones, y por qué he llegado a la conclusión de que no es, al menos, el momento de hacer integraciones entre sus herramientas y las de traducción.
Índice
1. De dónde surge la idea
2. Veía potenciales procesos a plantear
3. Entonces, ¿los diseñadores dan de alta las palabras?
4. ¿Puedo integrar mi herramienta de diseño con el TMS?
4.1. Sólo un idioma en la app de diseño de UI, y todo a texto plano (como toda la vida)
4.2. Los diseñadores establecen las cadenas de texto, y los programadores las cargan en el TMS.
4.3. Lo que nos ahorremos en establecer integraciones aquí, lo podremos emplear en otros procesos
5. Conclusión
De dónde surge la idea
Los diseñadores son probablemente las personas en una empresa que más conocen el valor de un Design System junto con los programadores front-end. Normalmente en estos Design System hay un apartado que trata cosas como el tono de voz y la personalidad.
¿Cuántos de vosotros no estáis hasta las 👃 de que diferentes personas os estén diciendo de cambiar los textos/copies de la interfaz o mensajes? 😀
Bueno, pues estas reglas del Design System establecen cómo han de ser los copies para mejorar la calidad y reducir la fricción de los procesos.
Entonces pensé: en las operaciones de diseño habrá que hacer algo.
Veía potenciales procesos a plantear
Unas herramientas claves en esto son las Translations Management Systems/Software o TMS, que permiten tener un punto central donde gestionar prácticamente todo el ciclo de vida de las traducciones.
Otro punto importante es tener un idioma base para todos los procesos del proyecto, ya que las cadenas de texto necesitan de un idioma base para ser traducidas al resto (luego puedes crear otros flujos de traducción para optimizar costes pero no viene al tema).
Veía que los diseñadores suelen tener un montón de páginas en herramientas como Figma, exponiendo las mismas "vistas"/"componentes" (V/C en adelante) y cuando se cambiaba alguna palabra, otras V/C quedaban desactualizadas. Luego, si había que hacer una revisión para ver que todo estaba bien, había que estar preguntando: "oye, ¿es este el copy o es este otro?"
Imagina a alguien que acaba de entrar, que no se entera de la película, viendo como hay textos distintos en la aplicación y, que en muchas ocasiones, te ahorras preguntar ya que el coste de desconcentrar a otras personas por algo así no compensa. Pero esa imagen de desorden y falta de integridad está en la calidad de proyecto y de la app. Esta problemática se encuentra más en proyectos en los que no hay un Design System.
Por eso pensé que podría haber alguna manera de que los diseñadores pudieran vincular las cadenas de texto del TMS con las que hay en los mocks/prototipos (llámese como desee) para que se viera exactamente igual en todas las V/C y también en la app, que de ser multiplataforma, entonces en todas las apps.
Esto también permitiría ver los mocks/prototipos en distintos idiomas (conforme vayan traduciéndose en el TMS), así como escalar el trabajo si se utiliza una arquitectura de componentes.
De una manera simple de dibujar, el escenario quedaría en algo tal que así (perdonad el serif del número 1 😅):
La duda que te puede saltar ahora es: ¿dónde dan de alta esas traducciones? ¿En Figma, en el TMS? ¿Acaso lo tienen que hacer ellos?
Entonces, ¿los diseñadores dan de alta las palabras?
En resumidas cuentas: sí. Creo que los diseñadores darán de alta el 99% de copies y serán responsables de optimizar el uso de estos.
Pero claro, ¿dónde los dan de alta? ¿En Figma, o en el TMS? ¿Cómo hacen cambios y dónde?
Pues para responder a eso, hay que ver primero la escena actual de integraciones.
¿Puedo integrar mi herramienta de diseño con el TMS?
Cómo hay pocos TMS (ironía), y encima no hay todavía un estándar común en estos procesos, las integraciones terminan dejando dudas. Algunas incluso ni funcionan.
He revisado más de 10 TMS y más de 30 integraciones y la conclusión es la que planteo en los siguientes puntos:
Sólo un idioma en la app de diseño de UI, y todo a texto plano (como toda la vida)
No hace falta más. Los mocks tienen que servir para que los programadores y personal de producto cuenten con una fuente de información que les permita ver cómo tiene que quedar un desarrollo.
Entre las complicaciones, nos encontramos con cómo introducir contenido dinámico (título de películas a ejemplo del mock), cómo introducir texto con placeholders (variables), plurales, ordinales, cómo mantener la app de UI rápida y ligera, cómo mantener el versionado de los diseños y cómo mantener actualizados ciertos cambios de manera bidireccional.
Se que cuesta quitar azúcar, pero el proyecto irá perfectamente aun sin disponer mocks en múltiples idiomas. Esto reducirá muchísimo la toma de decisiones que hay que hacer y por eso, este artículo será más breve 😎
Los diseñadores establecen las cadenas de texto, y los programadores las cargan en el TMS.
Los diseñadores dictaminarán las palabras en texto plano, como han hecho siempre, pero también tendrán que ser responsables de su reutilización.
Así que: colleja al que utilice "Atrás" cuando ya existe un "Volver atrás" en toda la app.
Los diseñadores tendrán un glosario de términos, donde existirán términos de tipo "actions". Serán responsables de reutilizarlos.
Y los programadores, utilizando herramientas de CI y frameworks de i18n, serán los que carguen esas cadenas de texto en el TMS para que los traductores dispongan de trabajo.
Con esta reglas básicas, los desarrolladores también podrán añadir cadenas de texto que los diseñadores no hayan tenido en cuenta por cualquier motivo. Cosas tales como plurales o asuntos relacionados con ICU. Así mismo, a ser posible, los diseñadores reflejarán estas cadenas de texto faltantes una vez sean conscientes.
Lo que nos ahorremos en establecer integraciones aquí, lo podremos emplear en otros procesos
Aún nos falta meter otras cosas en este puzzle, como por ejemplo el versionado en Figma, el versionado en el TMS, Storybooks, etc. donde sí que podemos hacer cosas muy potentes.
Conclusión
En referencia a este aspecto de la i18n y la fase de diseño, estableceremos unas normas básicas que no requerirán de integraciones programáticas y podremos lograr integrar i18n con mucha efectividad.
Espero que te haya sido de utilidad.
Top comments (0)