Una de las decisiones que uno debe tomar al comenzar un desarrollo es si va a utilizar internacionalización (I18n) para los textos. Es decir, que la aplicación pueda ser traducida y adaptada a las necesidades de diferentes culturas (formato de fecha, moneda, etc) e idiomas sin requerir cambios significativos en el código fuente.
A mediados del año pasado, nos encontramos en esta situación cuando arrancamos un nuevo proyecto. El cliente nos comentó que a futuro “podíamos” llegar a ofrecer la aplicación en múltiples idiomas así que no lo dudamos y decidimos usar I18n para todos los textos.
Hoy, después de casi un año, la aplicación sigue estando en un solo idioma y puedo concluir que nos equivocamos. Caímos en el “por las dudas” y terminamos complicando nuestro día a día, haciendo mucho más difícil el desarrollo.
Se que es muy fácil hablar con el diario del lunes, pero hay cosas que deberían ser muy sencillas y por utilizar I18n terminaron siendo muy frustrantes. Aquí te menciono algunas de ellas 👇.
Code reviews
Las revisiones de código se tornaron muy complejas. Sobre todo la revisión de las vistas, que se tornaron muy difíciles de seguir porque están plagadas de referencias a textos en lugar de los textos en sí.
Durante la revisión nos encontramos yendo y viniendo a los archivos con las traducciones para entender bien qué cambios se están aplicando.
Manejo de vistas
Encontrar un archivo asociado a una vista se ha convertido en una tarea muy tediosa. Localizar un archivo solo teniendo como referencia lo visto en el navegador requiere de al menos dos pasos.
Para graficar el problema veamos un ejemplo. Imaginemos que estamos navegando el sistema y vemos una pantalla que tiene el texto “Panel de control”.
Si no tuviésemos I18n, podríamos buscar el texto en nuestro código fuente y encontrar fácilmente la vista. Pero con internacionalización, al buscar “Panel de control” caemos en algún archivo de traducciones. Esto hace que luego, a partir de la referencia de la traducción, tengamos que buscar la vista. Es decir, generamos una indirección que podría evitarse.
Tests
En nuestros tests hacemos referencia a las traducciones en lugar de usar los textos reales, lo que los hace muy difíciles de seguir y tenemos que estar adivinando qué es lo que hacen.
Los tests tienen expectations con esta forma:
Quizás no fue la mejor decisión usar las referencias y podríamos haber usado los textos reales en los tests, pero arrancamos de ese modo y ahora todos los tests están así.
Además, por usar internacionalización, en los tests no se detectan traducciones mal hechas o incluso traducciones no hechas. Si en la traducción escribimos sin querer “Panol de control” en lugar de “Panel de control” el test pasa igual.
Soy un convencido de que de todo se aprende y creo que esta no fue la excepción. Las ventajas de usar internacionalización son muy claras, te permiten mantener un sistema en múltiples idiomas, pero si no estamos seguros de si un proyecto va a estar disponible en múltiples idiomas, ¿vale la pena el esfuerzo? Yo creo que no.
