Internacionalización de Angular 5

Después de pasar tiempo investigando esto, pensé en publicar las principales diferencias que encontré entre ngx-translate y Angular-i18n :

• Angular solo funciona con un idioma a la vez, debe recargar completamente la aplicación para cambiar el idioma. El soporte de JIT solo significa que funciona con JIT, pero aún tiene que proporcionar las traducciones en bootstrap porque reemplazará el texto en sus plantillas durante la compilación, mientras que esta lib usa enlaces, lo que significa que puede cambiar las traducciones en cualquier momento. La desventaja es que los enlaces toman memoria, por lo que la forma Angular es más performante. Pero si utiliza OnPush para sus componentes, probablemente nunca notará la diferencia
• Angular solo admite el uso de i18n en sus plantillas por ahora, estoy trabajando en la función que le permitirá usarlo en su código, pero todavía es un trabajo en progreso. Esta lib funciona tanto en código como en plantillas
• Soportes angulares XLIFF o XMB (ambos son formatos XML), mientras que esta lib soporta JSON por defecto pero puedes escribir tu propio cargador para soportar cualquier formato que quieras (hay un cargador para archivos PO por ejemplo). Personalmente, los archivos Json son bastante sencillos de leer en lugar de estos otros formatos, pero eso no es un gran inconveniente.
• Angular soporta expresiones ICU (plurales y select), pero esta biblioteca no
• Angular soporta marcadores de posición html incluyendo código angular, mientras que esto la biblioteca solo soporta html normal (porque se ejecuta en tiempo de ejecución, y no durante la compilación, y no hay compile compile en Angular como había en AngularJS)
• La API de esta biblioteca es más completa porque se ejecuta en tiempo de ejecución puede ofrecer más cosas (observables, eventos,...) que Angular no tiene (pero realmente no necesita dado que no puede cambiar las traducciones) El creador de ngx-translate ha dicho esto:

Ocombe (desarrollador de ngx): @josersleal eso es exactamente lo que hicieron, el equipo de angular me contrató para mejorar i18n para todos, pero no hay forma de integrar mi lib directamente en el núcleo, después de trabajar para 3 meses para el equipo central puedo decirte que Angular i18n es mucho más complejo y elaborado que mi lib. Maneja mucho más complejo cosas, y lo hace sin todos los errores y deficiencias que mi lib ha. Entiendo que es frustrante que el núcleo no evolucionar tan rápido como lo que una biblioteca puede hacer, pero hay razones para eso, y la primera es que no se puede implementar algo y cámbielo cada vez que vea que olvidó incluir un caso de uso. Todo tiene que ser planificado y pensado a fondo. Todavía, tener la mayoría de las cosas que esta lib puede hacer en el núcleo en el futuro, pero podría tomar un año antes de que lleguemos allí, desafortunadamente. La buena noticia es que va a ser mucho mejor que mi ingenuo aplicación.

Este es un buen artículo para discutir las principales diferencias entre ngx-translate y Angular i18n: https://github.com/ngx-translate/core/issues/495

Los cambios para i18n son debidos en la versión 6 de angular. Hoy, estamos actualmente en la versión 5:

• No será para 5.0, debería ser antes de 6.0 (por lo tanto, antes de marzo de 2018). Desafortunadamente no tengo una fecha más precisa

• El desarrollador de ngx-translate (y ahora un main contributor to angular-i18n) ha publicado esto hace 12 días: https://github.com/angular/angular/issues/20193

• Aquí está el documento de diseño para i18n (la sección de estado de la técnica es interesante): https://docs.google.com/document/d/1LH7lJ1GjRgpGUjzNb6Eg4xrPooRdi80QOTYYh8z_JyY/edit#

Algunos pensamientos...

• Angular-i18n es más eficiente a medida que compila su aplicación en el idioma que necesita (en lugar de que se realicen traducciones en tiempo de ejecución). También puede ser un inconveniente, ya que es posible que necesite tener varias compilaciones de su aplicación en diferentes idiomas.
• Si estuviéramos usando SEO, angular-i18n sería el camino a seguir, debido a la navegación de url. Para mi caso, no necesito esto en absoluto.
• Si requerimos el cambio plural, etc. Una vez más, no necesito esto, solo necesito un cambio de lenguaje de tiempo de ejecución bastante sencillo en las plantillas y el código.
• Angular-i18n no se lanzará al menos hasta marzo de 2018. Para mí no puedo espera hasta entonces, ya que necesito crear mi aplicación ahora.
• ngx-translate no tendrá un conjunto tan completo de capacidades como angular-i18n, PERO nuevamente, solo necesito traducciones simples en tiempo de ejecución, así que creo que está bien para lo que necesitamos.
• ngx-translate es de código abierto y llega el día en que ya no se está desarrollando, si hay un problema grave, supongo que podría arreglarlo yo mismo (espero que para cuando llegue, cualquier problema que pueda surgir se solucionará).

También voy a echar un vistazo en la biblioteca Angular-l10n, ya que se ve muy bien:

• Angular-l10n - https://github.com/robisim74/angular-l10n