# Definición proceso de traducciones <!-- Version del documento --> ## Control de Versiones | Versión | Fecha | Autor | Revisor | Descripción del Cambio | |--|--|--|--|--| |1.0|20210513|Sergio Ñustes|Jed Horne / Manuela Castro|Emisión| ​ ## 1 Introducción <!-- párrafo corto que explica qué estas proponiendo --> El presente documento explica el funcionamiento de las traducciones a nivel técnico y producto. ​ ## 2 Motivación <!-- ¿qué motiva esta decisión y por qué es importante? ¿Por que construirlo? el propósito de esta sección es articular de una manera sencilla el valor de la decision que vamos a tomar --> Ya habíamos realizado una definición de traducciones utilizando [Lokalise](/giih9iU7RNqH817Yv9h-_A) sin embargo en dicha solución no se exploró la solución creada por Juan Parra para las aplicaciones en mobile. Adicionalmente tampoco se exploró en ambas propuestas la posibilidad de realizar cambios de traducciones en runtime, es decir, sin necesidad de tener que generar una nueva versión de las aplicaciones. ​ ## 2.1 Lluvia de Ideas - La propuesta de Juan que utiliza esta [librería](https://pub.dev/packages/flutter_sheet_localization_generator), se encontraron los siguientes puntos: - Positivo: - Tiene muy buena documentación - No incurre en costos adicionales, utiliza por debajo Google Sheets - Realiza generación de código automático que permite a tiempo de compilación encontrar errores en los keys. - Actualmente se está utilizando no nos implica un desarrollo nuevo. - Negativo: - No permite actualizar en runtime los textos de las traducciones. - No hay propuesta para manejar traducciones de calidad. - La propuesta desarrollada por Yitsy, evaluó diferentes plataformas de terceros y entre todas la más sobresaliente es Lokalise, en esta se encontraron lo siguientes: - Positivo: - Tiene una UI muy buena para importar, exportar traducciones - Tiene integraciones con todos los lenguajes que manejamos - Permite manejar diferentes proveedores para realizar traducciones (tanto automático, como personas) - Está respaldada por varias aplicaciones en la industria - Provee APIs que nos permiten integrarlo en diferentes fases del proceso. - Negativo: - Tiene un costo mensual que no es nada despreciable - Tiene limitaciones en cuanto a número de keys (más costo) - El punto de inflexión es que no tiene un sdk o algo que actualice en tiempo real los keys, y aunque provee una API consume el mismo esfuerzo hacerlo con lokalise que con Google Calendar. ​ ## 3 Propuesta de implementación Teniendo en cuenta las ideas anteriores, para la creación de la solución se tuvieron las siguientes premisas importantes: - Mejorar los puntos negativos de la propuesta de Juan, y ahorrarnos los costos de lokalise. - Encontrar una buena solución para poder contratar traducciones de calidad. - Poder hacer que la propuesta de Juan con Google Sheets, pudiera tener actualización de keys en runtime, sin necesidad de realizar despliegues adicionales. Respecto a la propuesta de poder realizar traducciones en runtime, se detalle en la sección 3.1 Respecto a la propuesta de contratar traductores de calidad se plantea utilizar Gengo, que es uno de los proveedores que utiliza lokalise por debajo, y que tiene buenos precios para traducciones por palabra. Esto se detalla en la sección 3.2 Adicional se propone de cara a producto un proceso de gestión de traducciones que se detalla en la sección 3.3. ### 3.1 Sincronizar traducciones en runtime - Se hizo el desarrollo de este lambda ([lambda](https://console.aws.amazon.com/lambda/home?region=us-east-1#/functions/update-translations?tab=code), [repo](https://github.com/MiAguila/serverless-update-translations)) - Este lambda se encarga de leer el google sheet específico, y generar diferentes JSON en el cdn.miaguila.com para cada lenguaje ([ejemplo](https://cdn.miaguila.com/translations/1661222639_dev_es.json)). - La actualización es configurable de momento se dejó con una actualización de ~2 minutos en entornos de desarrollo, y ~2 horas para el resto de ambientes (de momento funciona con backoffice) Adicional se realizó la siguiente implementación en dart para el backoffice [link](https://github.com/MiAguila/backoffice-flutter/pull/7). La cual tiene un funcionamiento tradicional como cualquier otra librería de internacionalización: ![](https://i.imgur.com/WxH1sur.png) Tiene un proceso interno automático para descargar de nuevos los idiomas por si han tenido cambios cada 1 minuto para develop y 1 hora para otros ambientes. Y soporta el mismo archivo y características de la propuesta de Juan como manejo de plurales, géneros e interpolación de variables. Exceptuando la generación de archivo de traducciones que es algo más deseable que obligatorio (Buena parte de las librerías estandarizadas utilizan keys en strings). ### 3.2 Contratar traducciones profesionales Este fue un punto importante en el desarrollo de la propuesta y es más allá de la parte tecnológica, cómo aseguramos traducciones de calidad. Para esto se recomienda utilizar herramientas como Gengo.com (que es utilizada por lokalise), la cual subiendo un archivo xls con una columna y una frase por fila, nos permite tener traducciones de alta calidad a un costo aceptable. A continuación se detalla el proceso para solicitar las traducciones con ellos: ![](https://i.imgur.com/IqZMRqU.png) ![](https://i.imgur.com/IMcS9g8.png) ![](https://i.imgur.com/GvBVE1D.png) ![](https://i.imgur.com/WsR0PiN.png) ![](https://i.imgur.com/GiPBZaa.png) Un punto importante a tener en cuenta y es que es mucho mejor en lo posible tener las traducciones en inglés, dado que hay más opciones de traducción a más lenguaje. Se puede traducir directamente del español, pero dado que no hay tantos traductores profesionales de este lenguaje a otros en la plataforma, toca realizar contactando a soporte. Adicional a esto, podemos manejar traductores independientes si se considera pertinente. ### 3.3 Gestión de traducciones Para realizar este proceso contamos con el siguiente [Google Sheet](https://docs.google.com/spreadsheets/u/1/d/1vZjQDs-PT7GUcTR_VOpMaKWlYoK3yepEvdRvFGFHtW8/edit?pli=1#gid=1661222639) desde el cual podemos gestionar las traducciones de todas las plataformas. **Precaución:** - El acceso al documento de Google Sheet, sólo debe estar permitido al equipo de tecnología y producto. - Borrar keys puede afectar la experiencia de los usuarios. - Los traductores deben recibir copias del google sheet, y cuando tengan las traducciones el equipo de producto se debe encargar en copiar dichas traducciones. Cómo manejar el google sheet: En la pestaña README se dejan instrucciones para manejo de colores que deben ser manejadas tanto por el equipo de producto como tecnología. ![](https://i.imgur.com/y6ePLHC.png) - El equipo de tecnología cada vez que cree una traducción debe crearla en amarillo. - Es el desarrollador que define el key siguiendo la estructura recomendada. - Es responsabilidad del equipo de producto garantizar la calidad de las traducciones y la consecución de las mismas. - Producto basado en la necesidad de negocio, define los tiempos de sincronización de las traducciones. - Para agregar dialectos o más idiomas se debe sincronizar tecnología y producto para garantizar compatibilidad, pues en la integración actual, no se ha agregado.​ <!-- Este es el núcleo de tu propuesta, y su proposito es ayudarte a pensar en la solución. Esto debe ser un wireframe, no un documento perfecto con todos los detalles. ​ Escribir es pensar https://medium.learningbyshipping.com/writing-is-thinking-an-annotated-twitter-thread-2a75fe07fade ​ - usa diagramas para ilustrat tus ideas o flujos - inluye ejemplos de código si estas proponiendo una interfaz o contrato de sistemsa nuevo - agrega links con las especificaciones de proyectos - Competidores e inspiración de productos - Mockups ​ El proposito de esta sección se resume en: "Esta es la dirección en la que nos voy a llevar, alguién ve huecos en mi propuesta o tiene comentarios sobre cómo mejorarla? ​ --> ​ ## 4 Métricas (N/A) ## 5 Riesgos e inconvenientes Malas configuraciones en el Google Sheet por parte del equipo de producto o tecnología pueden afectar la experiencia del usuario y que no pueda utilizar la aplicación correctamente. Esto se puede mitigar utilizando la herramienta de gestión de versiones de Google Sheet, para volver una versión anterior del documento específica: ![](https://i.imgur.com/dYALqqA.png) <!-- ¿Hay razones por las que no deberiamos hacer esto? ¿Qué riesgos estamos tomando? Por ejemplo, no tenemos experiencia con esta tecnología nueva o no entendemos la escala aún. --> ​ ## 6 Alternativas (N/A) <!-- ¿Hay otras formas de resolver éste problema? --> ## 7 Impacto potencial y dependencias <!-- ¿Qué otros sistemas se verán afectados con esta propuesta? ¿Qué consideraciones de seguridad debemos tener?¿Como pueden explotar esta parte del sistema? ¿Que impacto tiene esta decision sobre soporte al cliente? Aquí buscamos ser concientes del ambiente en el que operamos y generar empatía hacia otros que pueden verse afectados por nuestra decisión. --> Esta solución debería implementarse en todos los proyectos que son usados por los usuarios. ## 8 Preguntas sin resolver (N/A) ## 9 Ideas futuras <!-- ¿ Qué preguntas no hemos resuelto? --> - Integrar esta propuesta en los demás proyectos ecommerce-flutter e ecommerce-web. - En el caso de web, desarrollar un servicio parecido al de dar, para realizar esta gestión de las traducciones. - Realizar la implementación de esta propuesta en microservicios. ​ ## 10 Conclusión - Se realiza la definición de una propuesta para gestión de traducciones en todos los proyectos MiÁguila. - Esta propuesta reune los principales puntos positivos de la propuesta desarrollada por Juan con Google Sheets, y elaborada por Yitsy para el uso de lokalise. - Adicional, se agrega la característica de actualización de traducciones en runtime, la cual agrega mucho valor para solucioner errores de traducciones en caliente y la no necesidad de incluir tecnología para cambiar un texto. - [Video revisión propuesta equipo producto](https://drive.google.com/file/d/1XhxJJzXp4R_AmXNpCynI2Xxxp-5gz6Gp/view?usp=sharing)