Localización de Angular, ¿usarla o no?

Por si no es de conocimiento general, aclararé que Angular tiene una localización. Es decir, tiene un sistema para administrar multi-idiomas. ¿Mi opinión sobre el sistema de Angular i18n? Es muy bueno, bastante automatizado (dentro de lo posible) y muy funcional, lo recomiendo mucho. No obstante, me han preguntado por qué no lo estamos utilizando para el multi-idiomas de nuestra app Codize, y cuál es exactamente la forma en la que estamos haciendo las traducciones. Y un poco de eso vengo a hablarles. 

¿Qué tiene de malo la localización de Angular?

Insisto, no tiene nada de malo, funciona muy bien. Entonces, ¿por qué no la usamos? Esa es otra pregunta, iré respondiendo de a partes. El sistema de "internacionalización" (localización) de Angular es semi-automático. Se deciden que tags de HTML serán las que llevarán contenido "traducible" y mediante un comando se genera un archivo XML que se utiliza para designar las distintas traducciones. Acá ya empiezan los problemas, la escalabilidad con un sistema asi es posible pero es rara. Imagino que si se tienen grandes volúmenes de textos entonces puede resultar ser útil, pero en el caso de Codize necesitábamos traducir algunos títulos y placeholder, no pensamos traducir párrafos enteros. Para colmo, el i18n de Angular tiene algunos problemas cuando se utilizan datos variables (que necesitan ser traducidos) y en las pruebas me resultó tan cómodo. En Codize actualmente estamos creando nuevos componentes a cada rato, y en todos hay títulos o instrucciones que necesitan estar, al menos, en Español e Inglés. Con el sistema de Angular habría que generar esas traducciones todo el rato, y para colmo si hay un término repetido hay que volver a cargar la traducción (ya que es un término nuevo, obviamente). Si bien es un gran modelo no es el que quería en lo personal para la App de Codize.

¿Cómo funciona la localización en Codize?

Yo lo que quería era algo como los sistemas de traducción más viejos, que simplemente eran un archivo JSON por defecto (en inglés) y una copia por cada idioma. Entonces cualquier persona podía generar su traducción particular o contribuir. Con algo así en el caso de existir términos repetidos es tan simple como llamar en esa ubicación al mismo término traducido. Y básicamente eso hice, no tiene gran misterio. Decidí generar dos archivos de TypeScript, uno para Español y otro para Inglés, que sean una réplica y que organicen la información en forma de árbol (datos del menú, datos de determinados módulos, etc). Esos archivos exportan un objeto de tipo JSON y son cargados de forma global, luego cada componente de Odoo lo carga en una variable llamada l18n (para diferenciarla sutilmente de i18n) y ya tienen acceso. Con una simple lógica lo que hace es cambiar la variable global dependiendo si se selecciona el código "es" o "en". Y no hay más misterio, multi-idioma rápido sin recurrir al sistema de Angular ni a la traducción del propio Odoo.