navigationend - title angular 6
Internacionalización Angular 5 (2)
Estoy compilando una aplicación con la última versión de Angular5 y lo que necesito es que el usuario pueda cambiar de idioma. Nunca tuve que implementar esto en un Angular2 + (en realidad estoy usando Angular5).
Necesito establecer traducciones en dos lugares:
- Plantilla html del componente: cambie las etiquetas al idioma especificado
- En el código del archivo component.ts, es posible que deba traducir algunas cadenas que se crean dinámicamente en determinadas condiciones en el código
Estuve viendo ngx-translation y parece que hará todo lo que necesito, ya que le permite cambiar el idioma sin reconstruir su código, vea here . Sin embargo, leí here debido a que el desarrollador principal se mudó al equipo angular para desarrollar su código i18n.
También entiendo que el i18n actual no es compatible con todo lo que necesito en este momento, mira here .
Mi pregunta: ¿cuál es el estado de las traducciones en la última versión de Angular? ¿Hay otras bibliotecas que la gente recomiende en su lugar, si es que Angular en sí no tiene soporte completo hasta el momento (para cambiar el idioma sin recompilar)? ¿Es ngx-translate bueno para el futuro?
¡Cualquier orientación en esta área es muy apreciada!
Después de pasar un tiempo investigando esto, pensé en publicar las principales diferencias que encontré entre ngx-translation y i18n :
- Angular solo funciona con un idioma a la vez, tienes que volver a cargar completamente la aplicación para cambiar el idioma. El soporte 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 utiliza 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 eficiente. Pero si usa 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 característica que le permitirá usarla en su código, pero todavía es un trabajo en progreso. Esta lib funciona tanto en código como en plantillas
- Angular admite XLIFF o XMB (ambos son formatos XML), mientras que esta lib admite JSON de forma predeterminada, pero puede escribir su propio cargador para admitir cualquier formato que desee (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 admite expresiones de ICU (plurales y seleccionar), pero esta biblioteca no
- Angular admite marcadores de posición html, incluido el código angular, mientras que esta biblioteca solo admite html (porque se ejecuta en tiempo de ejecución, y no durante la compilación, y no hay compilación en $ en Angular como en AngularJS)
- La API de esta biblioteca es más completa porque se ejecuta en tiempo de ejecución y puede ofrecer más cosas (observables, eventos, ...) que Angular no tiene (pero realmente no necesita dado que no puede cambiar las traducciones). creador de ngx-translate ha dicho esto:
Ocombe (desarrollador de ngx): @josersleal eso es exactamente lo que hicieron, el equipo 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 durante 3 meses para el equipo central que puedo te digo que Angular i18n es mucho más complejo y elaborado que mi lib. Maneja muchas cosas más complejas, y lo hace sin todos los errores y fallas que tiene mi lib. Entiendo que es frustrante que el núcleo no evolucione tan rápido como lo que una biblioteca puede hacer, pero hay razones para ello, y la primera es que no puede implementar algo y cambiarlo cada vez que vea que olvidó incluir una caso de uso Todo debe ser planificado y pensado a fondo. Aún así, tendrás la mayoría de las cosas que esta biblioteca puede hacer en el núcleo en el futuro, pero podría tardar un año antes de que lleguemos desafortunadamente. La buena noticia es que va a ser mucho mejor que mi implementación ingenua.
Este es un buen artículo para discutir las principales diferencias entre ngx-translate y i18n de Angular: here
Los cambios para i18n se deben a 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 (antes de marzo de 2018). Desafortunadamente no tengo una fecha más precisa
El desarrollador de ngx-translate (y ahora colaborador principal de angular-i18n) ha publicado esto hace 12 días: here
Aquí está el documento de diseño para i18n (la sección de Arte anterior 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 las traducciones se realicen 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 utilizáramos SEO, angular-i18n sería el camino a seguir, debido a la navegación en la url. Para mi caso, no necesito esto en absoluto.
- Si necesitábamos una conmutación plural, etc. De nuevo, 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á hasta marzo de 2018 al menos. Para mí, no puedo esperar hasta entonces porque necesito construir mi aplicación ahora.
- ngx-translate no tendrá un conjunto de capacidades tan completo como angular-i18n PERO, de nuevo, 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 llegará el día en que ya no se desarrolle, si hay un problema serio que creo que podría solucionar (espero que cuando llegue el momento, se solucionen los problemas que puedan surgir).
También voy a echar un vistazo a la biblioteca Angular-l10n, ya que se ve muy bien:
- Angular-l10n - https://github.com/robisim74/angular-l10n
Sí. ngx-translate es bueno hasta ahora, y espero que lo sea en el futuro también.
Estoy usando ngx-translation en mi proyecto actual de Angular 5 con más de 5 idiomas.
Está funcionando bien para mí hasta ahora. No tuve que hacer ningún cambio personalizado, funcionó como "plug and play".
Utilicé este complemento https://github.com/ngx-translate/core