Me gustaría ver la capacidad de realizar enlaces dinámicos en modo aot. Hay dos casos de uso en particular para respaldar por qué esto debe agregarse a la hoja de ruta.

El primero es el caso de uso básico en el que no desea aplicaciones separadas para cada idioma. Esto requiere algún tipo de lógica de redireccionamiento fuera de la aplicación y no permite el cambio dinámico del idioma sin una recarga completa del sitio.

El segundo es el caso en el que está incrustando la aplicación en un dispositivo móvil mediante cordova. Por lo que sé, su elección es jit, lo que ralentiza el sitio, crea una aplicación separada para cada idioma o incluye cada idioma en la aplicación (lo que, por supuesto, lo infla). Ninguna de estas son buenas opciones. Parece que Ionic no usa i18n, y me pregunto si esta es la razón.

@ jlutz777 esos son 2 casos de uso válidos, este tema se ha discutido internamente últimamente y también lo he estado defendiendo. Todavía no es posible dado cómo funcionan i18n y AoT en Angular, pero podría serlo en el futuro una vez que obtengamos el nuevo proceso de compilación para AoT en v5.
Lo agregaré a la hoja de ruta una vez/si tenemos algo oficial y concreto al respecto.

Estoy trabajando en la aplicación Electron + Angular 2 y ahora intento agregar soporte para localización para múltiples idiomas usando la función i18n con Angular. En realidad, la extracción de la cadena de plantilla y su conversión en diferentes formatos de archivo de idioma están claramente documentados, aunque todavía no puedo aclarar mucho y buscar:

• ¿Puedo cambiar de idioma dinámicamente? o necesito crear una aplicación por separado para diferentes idiomas.
• ¿Puedo administrar/consolidar todas las cadenas en un solo lugar (en forma de par clave/valor), para poder cambiar
  la cuerda en un lugar para efectuarse en múltiples lugares?
• ¿Puedo acceder al archivo localizado desde cualquier lugar que no sea la plantilla para obtener una cadena de idioma específica con
  clave proporcionada? (lo mismo que pregunté arriba).

Los puntos 2 y 3 se resolverán con la característica "Usar cadenas de traducción fuera de una plantilla - #11405".
Para el punto 1, vea la respuesta que le di a @ jlutz777 arriba. Por ahora, aún debe compilar la aplicación en varios idiomas o usar JIT, que puede cargar traducciones dinámicamente en el arranque (no cambia en tiempo de ejecución, pero aún es mejor que tener que empaquetarlo x veces).

el idioma de la interfaz de usuario utilizado en una aplicación debe ser algo que no requiera la creación de varias versiones de la misma aplicación. esto no debería ser de ninguna manera un problema de "compilador". si es así, el compilador está defectuoso. los problemas deberían ser hacer el diseño de la aplicación de tal manera que el texto se pueda cargar desde un archivo de datos en tiempo de ejecución. eso debe hacerse con un módulo/biblioteca que se pueda cargar y usar como cualquier otro. no haga de eso una función de compilador en absoluto.

@figuerres es algo que cambiará en el futuro, no hay promesas todavía, pero somos conscientes de este problema y estamos buscando posibles soluciones, usar un archivo externo es una de ellas.

Hola, @ocombe : parece que probablemente usaremos i18n en Angular para nuestra aplicación. ¿Hay alguna característica en los documentos que cree que podría quedar obsoleta o tener cambios importantes en los próximos meses? Cualquier información sería muy apreciada. Y gracias de nuevo por el DVD!

Hola @rjsteinert! ¡Me alegra saberlo!
Solo hay un cambio importante planeado por ahora, es la generación automática de identificaciones. El método cambiará y las ID ya no coincidirán, pero habrá una herramienta de migración cli para actualizar sus archivos de traducción (y un parámetro que puede usar para migrar solo cuando esté listo).

Busqué mucho en Google sobre este tema hoy y me pregunto si podría haber una solución "simple" como reemplazar las etiquetas i18n con una llamada a un servicio en lugar de la traducción.

Actual:
<span i18n>Hello world</span> => renderizado a <span>Hello world</span>

Mi idea:
<span i18n>Hello world</span> => renderizado a <span>{{i18nservice.translate('pass-in-the-generated-message-id')}}</span>

De esta manera, la traducción real se podría realizar dinámicamente en AOT, ya que el servicio se podría completar desde una API, un archivo, etc. e incluso cambiar de lugar no sería mucho más que i18nservice.setLocale('de-DE') con la carga de una nueva fuente.
La extracción de texto con la herramienta xi18n seguiría funcionando como antes y podríamos aprovechar los ID de mensaje generados de todos modos para usarlos como índice para el servicio de traducción.
La implementación actual también funcionaría sin problemas, ya que ngc podría simplemente buscar un indicador "--use-i18nservice" y compilar como hasta ahora.

Un problema que puedo identificar actualmente es la inyección del servicio i18n en todos y cada uno de los componentes, ya que tiene que existir en el contexto de los componentes para que se pueda llamar, pero eso debería poder resolverse de una forma u otra.

Tiene alguna idea sobre esto?

Es una de las cosas que estamos considerando. Sí, todavía existe el problema de cómo tratar los bloques de código dentro de esas traducciones cuando el compilador no está disponible en tiempo de ejecución (AOT). Significaría que no podemos usar componentes angulares/directivas/tuberías dentro de las traducciones...

Sí, no había pensado en eso.
Actualmente estoy desarrollando un POC/solución alternativa que integra todas las traducciones en el HTML en el paso de compilación (paquete web), envolviéndolas en contenedores ng con ng-switch.
Para los atributos i18n, está usando una directiva que los establece en nativeElement.
Las propias traducciones también se "representan" para reemplazar todos esos marcadores de posición <x id=".. "/> .

Es feo pero funciona... no puedo esperar a que ng lo admita de forma nativa.
Publicaré el POC más adelante esta semana, tal vez pueda ser útil para su posterior concepción.

Se me ocurrió una "solución" que se adapta a mis necesidades hasta que haya una implementación.
El precargador ahora muestra HTML para todas las configuraciones regionales antes de entregarlo al compilador, funciona de maravilla hasta ahora.

Repositorio: https://github.com/actra-development-oss/ng-i18n-aot-loader
NPM: https://www.npmjs.com/package/@actra-development-oss/ng-i18n-aot-loader

posiblemente un componente podría tener un atributo que le diga al sistema/compilador que necesita un servicio.
ese servicio luego toma una identificación y una configuración regional y devuelve el texto / marcado localizado.
todo el texto localizado se almacena en el servidor como recursos que el servicio puede leer.

si un componente no tiene el atributo no locale run-time.
si el componente lo tiene, llama a obtener los datos localizados en tiempo de ejecución.
el compilador simplemente crea los archivos de datos y conecta el servicio.

esto me parece una buena manera de manejar la necesidad más común para la mayoría de las aplicaciones y no requiere que los sitios construyan y mantengan múltiples copias de la misma aplicación.

Yo también tuve esa idea.
El problema es que las traducciones pueden contener enlaces y, por lo tanto, abrirían el sistema para la inyección de código al cargar archivos de traducción desde recursos externos.
Además, se necesitaría un compilador para resolver esos enlaces dinámicamente según la traducción.

En mi humilde opinión, una solución válida podría ser la forma en que implementé como POC (ver comentario anterior) para traducciones en línea en tiempo de compilación, solo que de una manera más elegante e integrada.
Ambos problemas mencionados anteriormente se eliminarían, el único inconveniente que puedo imaginar es posiblemente el tamaño del paquete, crecería a "paquete simple" + (traducido html-size * locales).
Eso podría reducirse con solo ng-switch ing el html etiquetado i18n en lugar de todo el documento, pero aún hay un problema para las etiquetas i18n-* .

bueno aquí está la cosa; a veces tienes limites....

desde un punto de vista práctico, podría ser mejor no tener eso, puede tener un fragmento de texto que se puede dar en varios idiomas. El final de la historia.

¿Necesitas tener un fragmento enlazado a datos? ok, pero eso no está dentro del texto internacionalizado, tiene que estar separado. aún puede usar html y css para diseñar y formatear el resultado. pero no puede incrustarlos o combinarlos de todas las formas que se le ocurran.
por ejemplo, una etiqueta div o ap puede tener una cantidad de intervalos, un intervalo es el texto y otro intervalo es una fecha vinculada, el intervalo de texto está vinculado al servicio local i18n, la fecha está vinculada a algún servicio de fecha, los dos intervalos están en un etiqueta de párrafo que les da formato.

Mantenlo simple, haz que funcione primero para el 95% de todos los usuarios y luego descubre los casos extremos.

No lo veo como un caso extremo, es lo de siempre.
Angular es un marco de nivel empresarial, por lo que muchos, si no todos, los usuarios de i18n requerirán enlaces, o al menos pluralización y selecciones, dentro de los textos.

<span i18n>Hello, {user.gender, select, m {Mr.}, f {Ms.}} {{user.name}}</span>
¿Cómo resolverías eso con cadenas separadas?
Respuesta simple: no puede, ya que no puede conocer las reglas del idioma de destino, no todos los idiomas siguen el formato 'saludo', 'género', 'nombre'.

Separar esos trozos sería:

• matar el contexto, el traductor no obtendría el significado de la oración completa
• fusionar los fragmentos en el orden correcto mediante CSS no es posible, tendría que especificar reglas para todas y cada una de las traducciones, por lo que el encargado de CSS debe conocer los idiomas de destino o el encargado de la traducción debe conocer CSS, ninguno de los dos es aceptable.

El núcleo i18n funciona en angular como se esperaba y se puede usar para aplicaciones de nivel empresarial, lo único que aparentemente falta es la compatibilidad con AOT, por lo que no entiendo su punto de vista de por qué un sistema potente y funcional debe ser reemplazado por algo que no sea la mitad de capaz. requiriendo varias veces el trabajo para hacerlo.

Tenemos una reunión mañana para encontrar una solución a este problema.

@ocombe me alegra escuchar esto, espero que esto conduzca a algunas cosas buenas para una versión futura de Angular, ¡aquí en el trabajo nos encanta cómo funciona la mayor parte para nuestras necesidades de desarrollo!

@ocombe , ¿es posible cambiar el idioma sin volver a leer todo el documento? Yo explico :
Estoy en la página llamada "acerca de", pero cuando cambio el idioma, soy redirigido a la página de entrada principal de mi aplicación.

Mientras trabajaba en mi aplicación i18n, también me encontré con el conocido "error" de que las hojas de estilo externas de, por ejemplo, @angular/material (que residen en node_modules) no se podían resolver y, por lo tanto, la ng-xi18n falló.
Implementé "ignorar archivos faltantes" - HostContext para la herramienta de extracción, también como POC pero agregado como PR #17845 para vincularlo al repositorio principal.

@ocombe , ya que parece ser muy activo en este tema, ¿le importaría echar un vistazo a las relaciones públicas y dar su opinión?

Gracias, le echaré un vistazo.

Han pasado algunos días buscando una forma de implementar la internalización en todo el proyecto, incluidos los datos dinámicos, pero no encontré nada concreto. ¿Puede sugerirme algo más que al menos me ayude por el momento? Gracias.

¡Hola @ocombe! ¿Podemos tener un seguimiento sobre el punto planteado por @ jlutz777 (sobre enlaces dinámicos, por lo tanto, no tener una aplicación por idioma)?

¡Muchas gracias por tu trabajo!

@vicb está trabajando en ello ahora mismo, estará en 5.x (no en 5.0 pero probablemente en 5.1)

@ocombe ¿Debería actualizarse la lista de verificación? Puedo ver que algunos de ellos ya se han fusionado en versiones más nuevas. Y eso reflejará mejor su arduo trabajo. 😃

sí, buena idea, lo actualizaré
editar: actualizado

Runtime i18n (un paquete para todas las configuraciones regionales con AOT) - [trabajando en ello]

¿Dónde está el tema asociado / relaciones públicas / discusión?

Sería genial tener una API para extender los formatos de fecha con nombre (por ejemplo ultraLongDate ) para que la tubería de fecha nativa lo sepa y no se necesite una tubería de fecha personalizada.

Solo tengo curiosidad sobre el progreso en "Runtime i18n (un paquete para todas las configuraciones regionales con AOT)".

Mi equipo tiene múltiples aplicaciones grandes con más de 60 idiomas. En este momento, ejecutamos N compilaciones en paralelo, de modo que N es la cantidad de idiomas. Esto requiere muchos recursos, como puede imaginar, especialmente considerando que las aplicaciones son bastante grandes y se implementan muchas veces al día en múltiples entornos.

Lo que espero es:

1. Algunos ETA aproximados en tiempo de ejecución i18n
2. Confirmación de que el tiempo de ejecución i18n hará una compilación única para todos los idiomas
3. Si cada idioma producido será o no de carga diferida o estará en un solo paquete masivo

@chcaru mientras espera que ng proporcione una solución "nativa", consulte https://github.com/actra-development-oss/ng-i18n-aot-loader/
Proporciona exactamente lo que está pidiendo, una compilación AOT con múltiples configuraciones regionales.

@chcaru :
1/ El ETA aproximado es Angular v6 (creo que la primera versión beta debería ser a fines de enero? No estoy seguro), la buena noticia es que las traducciones del código deben seguir rápidamente después de las traducciones en tiempo de ejecución, ya que casi todo el trabajo estará hecho.
2/ si
3/ las traducciones deben estar separadas del paquete, podrá cargar de forma diferida la que necesita antes de arrancar, o simplemente agrupar todo en uno, también queremos admitir las traducciones de carga diferida para los módulos, pero no estoy seguro de cuándo lo hará. estar disponible

@ocombe hasta que se publique angularv6, la opción más seria para cargar traducciones dinámicamente y/o crear una aplicación multilingüe con un solo paquete es ngx-translate.

¿Tiene algunos consejos para ayudar a las personas que comienzan a usar ngx-translate a migrar fácilmente cuando angularv6 está fuera?
¿Algún puente entre ambas aplicaciones?

No realmente, el código es bastante diferente... veremos cuando v6 sale con esas características si estoy motivado para trabajar en una herramienta de migración

Hola, gracias por la transparencia de las próximas funciones.

Sería muy útil conocer las respuestas a las siguientes preguntas:

1. ¿Alguna idea de cuán diferente será el nuevo flujo de trabajo i18n del actual descrito en https://angular.io/guide/i18n ?

2. ¿Seguirán estando disponibles en las plantillas el atributo i18n e i18n-*, por ejemplo, i18n-title con ID personalizado opcional?

3. ¿Seguirán funcionando los siguientes comandos?

ng serve --aot --locale fr

ng xi18n  --i18nFormat=xlf
ng xi18n  --i18nFormat=xlf2
ng xi18n  --i18nFormat=xmb

1. ¿Cómo se fusionarán las unidades trans de message.xlf extraídas de las plantillas con las que se usan en el código?

1. Haremos que la experiencia de actualización sea lo más fluida posible, lo más probable es que lo que funcionó antes siga funcionando al menos hasta la v7.
2. Los atributos i18n permanecerán igual
3. la extracción debe ser la misma también
4. esa es probablemente la única parte que cambiará, no estoy seguro de cómo todavía, así que prefiero no decirles las cosas que podrían cambiar, pero los mensajes se fusionarán en el tiempo de ejecución cuando se creen las vistas (por lo tanto, entre el arranque y la vista que aparece en la pantalla)

Siguiendo el comentario de @Toub , para este período de transición, nos interesaría recibir comentarios para el siguiente enfoque (mezclar el atributo i18n y ngx-translate) que queremos implementar. Nuestro objetivo es minimizar más las actualizaciones que se deben hacer en el código cuando el nuevo soporte para i18n esté listo.

(Tenga en cuenta que queremos configuraciones regionales dinámicas, es decir, no una aplicación generada por configuración regional)

• Usaremos el atributo i18n para poder aprovechar la herramienta de extracción angular.
• Según la herramienta extraída, podemos convertir archivos xliff (o con otros formatos) a contenidos con formatos que pueden ser utilizados por ngx-translate (json o po)
• Aprovecharemos el atributo translate en elementos usando el i18n para aplicar traducciones (extraído previamente)

Aquí hay una muestra:

<!-- Without parameters -->
<div i18n="hello-id" translate>HELLO</div>

<!-- With parameters -->
<div i18n="hello-id" translate [translateParams]="{value: 'world'}">HELLO</div>

¡Gracias por sus comentarios!

¿Podría abrir un problema en ngx-translate para eso? Creo que probablemente lo mejor sería actualizar la lib para admitir los atributos "i18n" como alternativa a "traducir"

@ocombe gracias por la sugerencia! Acabo de agregar un problema para esto en ngx-translate...

@ocombe , el problema que puedo ver es que los atributos i18n / i18n-* se eliminan en tiempo de ejecución (https://github.com/angular/angular/issues/11042). ¿Hay alguna manera de mantenerlos?

Revisé y, a menos que me equivoque, solo se eliminan si usa Angular i18n (lo que significa que carga las traducciones cuando está haciendo la compilación).

@ocombe entiendo pero no cargo las traducciones ya que estoy usando Angular CLI e inicié la aplicación con ng serve ...

@ocombe , nuestra empresa pronto realizará un esfuerzo para admitir i18n utilizando la estrategia de varias aplicaciones por configuración regional que se prescribe actualmente. También planeamos incluir la configuración regional en la URL y configurar el href base en la aplicación. Una vez que se complete la función de tiempo de ejecución i18n, ¿qué cambios deberíamos hacer con nuestra estrategia de configuración regional de URL? ¿Hay una mejor manera de comenzar a evitar una gran refactorización una vez que se publique el tiempo de ejecución i18n? Gracias por tu trabajo en todo esto.

⬆️ debe decir "comenzará pronto"

una aplicación/configuración regional aún debería estar funcionando como está ahora (menos el pequeño cambio para cargar el archivo de configuración regional en el arranque si no está usando la cli)

¿Podría alguien indicarme en qué archivo se eliminan los atributos i18n del paquete de plantilla durante el uso?

cc @ocombe

Se cambió en 4.2.6 (PR https://github.com/angular/angular/issues/17999)

¡Hola! Llevo mucho tiempo siguiendo este hilo. Vi que salió la primera beta para v6. Leí el registro de cambios pero no vi nada relacionado con este problema de larga data. ¿Alguna novedad en este frente? O al menos, ¿hay alguna garantía de que la interfaz sea similar a su polyfill?

¡Gracias por tu trabajo!

Va a estar en una de las últimas betas, o tal vez RC (lo sé, lo sé...).
La interfaz será similar a goog.getMsg del cierre ya que eso es lo que Google usa internamente para las traducciones de código: https://developer.pubref.org/static/apidoc/global/closure/goog/getMsg.html
Pero es posible que estemos usando un contenedor, por lo que tal vez cambie la interfaz para Angular, aún no estoy seguro.
En mi polyfill utilizo una interfaz similar, pero con la posibilidad de definir id, descripción y significado si es necesario, y creo que lo necesitaremos de una forma u otra (ya sea a través de parámetros o a través de un decorador)

¡Gracias por todo su trabajo duro! Nos estamos preparando para una reescritura desde cero de toda nuestra aplicación 1.x a partir de abril. ¿Hay algo que podamos o debamos hacer para prepararnos para estos cambios? En este momento estamos planeando usar 6.x. ¡Gracias de nuevo!

@ocombe ¿Simplemente tiene curiosidad por saber cuándo aterrizará "Ignorar los espacios iniciales y finales"?

Necesito actualizar la hoja de ruta, pero ahora mismo está un poco confundida (incluso para mí). Esta característica en particular claramente no es una prioridad, no espere que trabajemos en ella pronto.

@ocombe Sí, esto sería genial. Nosotros también estamos muy interesados ​​en el tiempo de ejecución i18n, ya que es el único punto de bloqueo para nosotros. ¿Podría tal vez dar una suposición sobre su finalización en %?

¡Muchas gracias por su arduo trabajo!

@ocombe

Esta característica en particular claramente no es una prioridad, no espere que trabajemos en ella pronto.

¿Podría aclarar de qué característica está hablando aquí? No quiero hacer suposiciones.

@ofuangka , la función "Ignorar espacios iniciales y finales" no es una prioridad.
@Karamuto difícil de adivinar por ahora, estamos trabajando en ello ahora mismo

@ocombe
¿Podría compartir su hito sobre Runtime i18n (un paquete para todas las configuraciones regionales con AOT)?

Ahora decidimos usar herramientas xi18n o bibliotecas de terceros para un gran proyecto multilingüe.
Esperamos poder utilizar herramientas canónicas, pero somos conscientes de que es demasiado básico.

También nos gustaría poder dividir archivos xlf (un archivo por módulo), ¿es posible?

Subir Subir
¿Se lanzará el tiempo de ejecución i18n en Angular 6?

gracias y feliz codificación!

Perdiendo la esperanza aquí, de que esto se termine a tiempo, ya que no queda mucho tiempo y no hubo novedades hasta ahora con respecto a esta función.

El lanzamiento de la versión 7 sería bastante tarde para nosotros.

@Karamuto #22654
Creo que se lanzará en v6, pero primero tienen que terminar con Ivy.

Deberíamos tener un hola mundo funcionando esta semana, pero con características mínimas (sin soporte para UCI, por ejemplo).
Pero dado que se lanzó con ivy, que está detrás de una bandera, seguiremos trabajando en ello y lo lanzaremos tan pronto como terminemos una nueva característica, no hay necesidad de esperar a v7.

@ocombe
¡Eso suena genial! No es necesario que esté completo con ICU desde el principio. Si avanza en las últimas versiones de v6, está completamente bien para nosotros.

Gracias por el gran trabajo de nuevo!

¡@Karamuto vea el n.º 22654 para ver un adelanto!

Pregunta tonta: ¿Hay alguna manera de tener una directiva i18n para entradas basadas en cadenas para componentes personalizados? Un ejemplo al reenviar etiquetas aria:

Envuelvo un botón personalizado que hace cosas geniales:

La plantilla del botón personalizado solo hace:

¿Hay alguna manera de hacer esto ya?

@kekraft Creo que con entradas estáticas puede usar la sintaxis del atributo i18n:

<custom-button ariaLabel="your label" i18n-ariaLabel></custom-button>

En el componente:

<button [attr.aria-label]="ariaLabel">Some button</button>

@ocombe , ¿necesita colaboradores para realizar el trabajo de i18n en tiempo de ejecución ?

Si ! v6 publicado ~~~
alguna actualización aquí?

el ejemplo i18n angular 6 está aquí
https://github.com/angular/angular/pull/23660

@sandangel , ¿quisiste decir simplemente "todo" o "todo lo que está verificado", de los planes al comienzo de este hilo?
Tenía muchas ganas de tener una sola aplicación, creo que es una de las cosas más importantes. Fue al #23660 que vinculó y luego llegó a https://pr23660-e12f469.ngbuilds.io/guide/i18n
Pero ahí todavía dice:

Cuando se internacionaliza con el compilador AOT, debe compilar previamente un paquete de aplicación independiente para cada idioma y servir el paquete apropiado en función de la detección del idioma del lado del servidor o los parámetros de URL.

¿Es posible tener una sola aplicación para varios idiomas o todavía no?

@MrCroft parece que el tiempo de ejecución i18n todavía está en progreso. Lo leí como tú, algunas opciones más, pero no un paquete para todas las localizaciones :(

Tenemos un Hello World en funcionamiento, pero es solo para el nuevo renderizador (ivy) y dado que ivy no está listo para el horario de máxima audiencia, desafortunadamente tendrás que esperar :(

@ocombe entonces, a menos que no tengamos Ivy en producción (probablemente alrededor de v7), no tendremos traducciones en tiempo de ejecución. ¿es esto correcto?

@ocombe ¿Están disponibles públicamente las cosas de hello world y ivy? Sería genial tratar de entender esta nueva implementación de i18next 😃

@fetis https://github.com/actra-development-oss/ng-i18n-aot-loader/

@fetis si :(
@feloy sí, el hola mundo simple está aquí: https://github.com/angular/angular/tree/master/packages/core/test/bundling/hello_world_i18n pero muy mínimo
puede encontrar las pruebas aquí: https://github.com/angular/angular/blob/master/packages/compiler/test/render3/r3_view_compiler_i18n_spec.ts
y algo de refactorización + extracción aquí: https://github.com/angular/angular/pull/22931

@ocombe estamos tratando de implementar i18n en nuestra aplicación, pero cada vez que lo leo, veo que necesitamos un archivo de mensajes.xlf por idioma. ¿No se convertiría en una sobrecarga para mantener considerando aplicaciones complejas con varias pantallas orientadas al cliente, etc. Estoy buscando para ver si podemos desglosar el archivo de mensajes por componente o por módulo? ¿Eso ya es compatible?

@stickler-v este archivo es solo el transporte de sus cadenas a su software de traducción. no considere traducirlo manualmente.

Ya veo, ¿dónde tenemos texto real en diferentes idiomas? Necesitamos administrar este texto manualmente en contraste con tener traductores que lo hagan.

Lo siento, pero estoy un poco perdido. Basado en la documentación original aquí https://angular.io/guide/i18n. src/app/app.component.html solo tendrá texto en inglés. message.fr.xlf es el archivo que tiene texto en francés pero se genera automáticamente y no es recomendable tocarlo.

Si quiero que app.component.html se represente usando texto en francés en lugar de inglés, ¿dónde especificaría los mensajes en francés "Bonjour", etc.?

@stickler-v está realmente fuera de tema, cree una pregunta en StackOverflow. Estaré encantado de responder allí.

¿Puedes por favor no discutir esto aquí? No es el tema aquí, gracias.
En cuanto a su pregunta @stickler-v, un archivo por módulo/componente no es posible en este momento, podría ser en el futuro, pero no está en la lista de cosas en las que estamos trabajando en este momento.

¿Algún plan para admitir traducciones de rutas?

Lo siento si esto ya se respondió, pero ¿son posibles las traducciones en JS con esta versión o sigue siendo solo para plantillas?

@santhony7 Todavía no es posible porque Ivy no está lista.

Una pregunta que tengo sobre la intención/funcionalidad del tiempo de ejecución i18n aquí es si eso significa que esencialmente podremos seleccionar el idioma en el tiempo de ejecución y "voltearlo" sin recargar la aplicación como era la funcionalidad en el antiguo ng-translate para AngularJS y en ngx-translate ? ¿O significa esto algo completamente diferente?

No, tendrás que volver a cargar la aplicación para cambiar el idioma.

Con el i18n actual, cuando crea y proporciona sus traducciones, reemplazamos las cadenas en el código del paquete, lo que significa que el paquete está localizado.
Runtime i18n significa que los archivos de traducción se cargan cuando se inicia la aplicación y no en el momento de la compilación como ahora.
Por eso, podrá cargar de forma diferida los archivos de traducción antes de que se inicie la aplicación, lo que significa que el paquete está separado del idioma, solo obtiene un paquete para su aplicación.
También puede optar por tener un paquete por idioma y agrupar el archivo de idioma con su aplicación (como lo estamos haciendo ahora), evitará la demora necesaria para cargar el archivo de traducción de forma diferida.
En un caso, realiza una solicitud http adicional y, en el otro, no, pero no creo que haya una diferencia lo suficientemente grande como para justificar tener un paquete por idioma.

Ventajas del tiempo de ejecución i18n:

• detecta el lado del cliente del idioma y carga de forma diferida el archivo de traducción que desea
• debido a que el código es independiente del idioma, obtiene un paquete para todos los idiomas
• las bibliotecas también pueden ser compatibles con "i18n"
• dado que cargamos las traducciones en tiempo de ejecución, tenemos todo lo que necesitamos para proporcionar un servicio que también puede hacer traducciones en su código (no solo las plantillas)
• podríamos dividir las traducciones por módulo (probablemente no esté disponible al principio)

Desventajas:

• traducir en tiempo de ejecución tiene un pequeño costo cuando las traducciones se extraen y transforman en nodos html, pero es de esperar que no lo note porque ivy será mucho más rápido que el renderizador actual
• el arranque de la aplicación se retrasa por el tiempo que tarda la carga diferida de las traducciones, o su paquete es un poco más grande (si incluye las traducciones)
• tenemos que agregar los serializadores a su paquete de aplicaciones para poder leer las traducciones, y eso es mucho código (probablemente podríamos "precompilar" las traducciones en algún tipo de json para evitar eso, aún no lo hemos decidido )

En teoría, podría cambiar el idioma sin recargar toda la aplicación, pero tendrá que volver a crear los componentes existentes porque las plantillas se generan cuando se crea el componente, o podría vincular el servicio en su plantilla (en lugar de usar i18n atributos) y se actualizará cuando cambie el idioma. Sería posible escribir una biblioteca que funcione como ngx-translate pero use Angular i18n internamente y le permita cambiar el idioma en tiempo de ejecución. Usaría más memoria para mantener las plantillas sincronizadas con el idioma, como es el caso de ngx-translate. Probablemente escribiré una biblioteca como esta.

también para que la gente piense en que algunos cambios de un idioma a otro pueden ser pequeños, otros pueden ser grandes, digamos que pasar de inglés a español puede ser "pequeño", pero de inglés a chino o árabe será grande.
para aclarar que para algunos idiomas no es solo el texto, es posible que también deba diseñar un diseño diferente para acomodar ese idioma y sus reglas de alineación, de izquierda a derecha o de derecha a izquierda y otros detalles.

por lo tanto, para la mayoría del uso en el mundo real, esperaría que la aplicación tenga un paso de detección de idioma en la carga de la aplicación que conducirá a la carga de los recursos correctos y algunos diseños.

@ocombe ¡ Muchas gracias por aclarar! Implementé el Angular i18n actual dentro de nuestra aplicación y me encontré con un inconveniente debido a cambios/requisitos desconocidos. También estoy usando la biblioteca https://github.com/ngx-translate/i18n-polyfill en conjunto para ayudar a cerrar la brecha actual.

Si bien los paquetes múltiples son una ligera molestia, actualmente puede solucionarlo con bastante facilidad. El inconveniente en particular es la posibilidad de que un componente (y todos sus componentes secundarios) se muestre en un idioma diferente al que se usa actualmente.

Francamente, todavía no estoy seguro de si ngx-translate puede ayudarme a lograr esto, pero quería enviarle un mensaje sobre los próximos cambios solo para asegurarme de tener la mayor cantidad de información posible antes de realizar cambios.

No tenemos ningún plan para admitir aplicaciones traducidas en varios idiomas al mismo tiempo, podría ser posible en el futuro si podemos cargar traducciones/módulo, pero sería un efecto secundario de la arquitectura, no algo que específicamente trató de lograr.

¿Hay alguna ETA para Ivy + tiempo de ejecución i18n?
Entiendo perfectamente si no es el caso, pero necesito saber si (dado el marco de tiempo de mi proyecto actual) puedo esperar o necesito comenzar a usar una de las soluciones actuales y posponer la migración a runtime i18n para una versión futura .

No intentaré dar un marco de tiempo exacto, cada vez que lo intenté fue incorrecto: D
No será antes de v7 ahora (estará disponible antes como beta)

No hay problema, todos sabemos que las estimaciones siempre son incorrectas. :D
¿Crees que será más fácil migrar desde el i18n actual (+ i18n-polyfill) al tiempo de ejecución 18n o desde ngx-translate?

probablemente del i18n actual, pero escribiré una versión de ngx-translate que use las partes internas de Angular i18n, si es posible (aún no estoy seguro)

Hola, he intentado atravesar este hilo para entender el estado actual. ¿Es el código de traducción ngx actualmente la "solución alternativa" más viable para una sola aplicación con localización dinámica?

Hola, ¿es posible cambiar la localización en tiempo de ejecución usando ngx-translate/i18n-polyfill?

@suchg No en tiempo de ejecución. Puede hacer traducciones en tiempo de ejecución, pero no puede cambiar la configuración regional utilizada.

@mjschranz gracias por la rápida respuesta
incluso las traducciones en tiempo de ejecución están bien por ahora. ¿Puedes compartir algún ejemplo de lo mismo?
Probé el ejemplo compartido en https://github.com/ngx-translate/i18n-polyfill y cambié el idioma del navegador Chrome, pero no tuve suerte.
¿Hay algún método específico para la traducción?

Por favor, mantenga la discusión aquí sobre Angular, no sobre bibliotecas externas. Si necesita ayuda con eso, publique los mensajes en sus repositorios de github

Oye, ¿hay otros problemas de seguimiento o documentos de diseño sobre cómo se verá la función en el futuro? Tal vez podamos ayudar con la implementación o prepararnos para asegurarnos de que la transición en v7 sea lo más fluida posible.

Hola, actualmente estoy ejecutando Angular 5 y necesitamos agregar varios idiomas a nuestro proyecto.
He agregado una solución que me funciona ahora, que es casi elegante. https://github.com/angular/angular/issues/24549.

Idealmente, me gustaría cargar de forma diferida los archivos de idioma en función de un servicio de rastreo de países (basado en una búsqueda de mapa de nombre de host).
Si eso fuera posible en Angular 6, sería genial.

@mattiLeBlanc ¿Cómo resuelve los mensajes dinámicos, por ejemplo, mensajes de componentes o servicios?

@zverbeta Discúlpeme por no entender completamente Angular Core o el contexto de esta discusión. Solo puedo abordarlo desde mi contexto para empezar.

En respuesta a su pregunta, asumiría que solo estamos interesados ​​en la carga diferida de los archivos de traducción (xlf) de una manera agradable, en función de una configuración regional que se puede deducir de la URL o un parámetro de consulta de idioma. (Actualmente uso un mapa de URL para decidir cuál es la configuración regional).

Un mensaje de un componente o servicio no está etiquetado como etiquetamos el marcado con i18n. Tengo algo de experiencia con i18n para Wordpress y PHP. Allí usamos el enfoque __( 'text' to translate, 'text domain' ) para obtener la traducción correcta. Este __() también podría escanearse mediante el comando CLI que crea el archivo de mensaje.

¿Es este el problema al que te refieres?

Una cosa que noté con este bloque de marcado, por ejemplo (porque era perezoso y no quería agregar i18n en cada subelemento):

<div class="eligibility-banner" i18n="@@eligbilityBanner" fxLayout="column" fxLayout.gt-xs="row" fxLayoutAlign.gt-xs="center center" fxLayoutAlign="center start">
        <div class="requirement-text" fxFlex="20">To be eligible, you:</div>

        <div fxLayout="column" fxFlex="80" fxLayout.gt-xs="row" fxLayoutAlign="center start">
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">own an Australian business (with a valid ABN/ACN)</div>
          </div>
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">are over 18 years old</div>
          </div>
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">are an Australian Citizen or Permanent Resident</div>
          </div>
        </div>
      </div>

es decir, copia todo el bloque div en mi mensaje.xlf.
Eso es mucha contaminación de marcado. (Por supuesto que podría usar i18n en cada etiqueta que contenga texto).

Para este ejemplo, creo que usar el comando _e() funcionaría bastante bien. Envolvería su texto con el comando echo y se recopilarán todos esos textos envueltos. Podrías deshacerte de toda esa copia de marcado en el xml.
Si necesita agregar algo dinámico a esa cadena, puede canalizarlo con marcadores de posición en la cadena (como lo haría con sprintf . Algo así como

<p>{{ __( 'I would like a nice %s, please', fruit ) }}</p> 

donde fruit es una variable con un valor de __( 'apple') o __( 'pear) .
Los 3 fragmentos de texto terminarían en el XML y se pueden traducir por separado.

¿Sería eso de alguna utilidad? Es bastante similar al agregar el atributo i18n, me doy cuenta después de leer de nuevo :)

Finalmente, mirando un par de formatos. XLIFF 2 se ve bastante bien, un poco más limpio que 1.2. El XMB parece una documentación confusa y horrible que parece haber sido diseñada en 1995.
Al usar XLIFF 2, me di cuenta de que el texto OBJETIVO no se representaba como en la versión 1.2.

¿Habéis mirado los archivos .pot y .mo? Formato bastante simple y también utilizado por traducido con la herramienta POEdit.

Necesito convertir mi aplicación en inglés y español usando el botón de alternancia. Hizo todos los cambios, archivo de trabajo por separado. Creé dos compilaciones en .dist/en y dist/es. ¿Alguien puede decirme qué debo hacer para la implementación y cómo cambiar entre ambas compilaciones?

Lo que debo hacer al hacer clic en el botón de alternar

@shobhit12345 , publique su solicitud de asistencia en https://stackoverflow.com

@zverbeta la solución que publiqué en #24549 no funciona cuando compilo con --prod . Algo obvio ya que estoy usando require que probablemente no esté disponible.
Sin el indicador --prod, ¿la solución funciona porque incluye código relacionado con el paquete web?

@mattiLeBlanc Encontré esta biblioteca https://github.com/ngx-translate/i18n-polyfill y resolvió mi problema con texto dinámico

Hola, ¿cómo podemos traducir valores dinámicos (interpolación) usando i 18 n?

    <source>This amount is for <x id="INTERPOLATION" equiv-text="{{policyName}}"/> policy #<x id="INTERPOLATION_1" equiv-text="{{policyGroupId}}"/></source>
    <target>Esta cantidad es para <x id="INTERPOLATION" equiv-text="{{**policyName**}}"/> política #<x id="INTERPOLATION_1" equiv-text="{{policyGroupId}}"/></target>

¡Oye! ¿Hay algún lugar donde podamos rastrear y/o ayudar con las tareas en las que se ha trabajado? (los que tienen trabajando en la etiqueta)

¿Alguna actualización sobre el marco de tiempo para el lanzamiento de una versión beta del tiempo de ejecución i18n?

@marcelnem no puedo encontrar el comentario, pero iirc ocombe mencionó que el tiempo de ejecución i18n se fusionó para ivy, por lo que probablemente pueda probarlo en la versión beta v7 con la bandera ivy

La parte del tiempo de ejecución está lista, pero no la parte del compilador, lo que significa que aún no puedes probarlo con ivy.

Hola, estoy trabajando con Angular 6 i18n. Estoy trabajando con varios idiomas, lo que significa que seguí el libro de cocina:
https://v2.angular.io/docs/ts/latest/cookbook/i18n.html#!

Mi implementación actual usa AOT, por lo que generé un archivo de mensajes.xlf y un archivo de mensajes.pt.xlf. Todo funciona bien, cuando corro

ng servir --configuration=pt

Obtengo los textos traducidos como se esperaba. Pero siento que hay algo muy malo en la forma en que funciona. Probablemente me estoy perdiendo algo. Por lo que entendí, cada vez que agrego una nueva cadena para traducir y la marco con el atributo i18n, necesito volver a generar el archivo message.xlf que ejecuta "ng xi18n" y luego actualizar manualmente el message.pt.xlf. El archivo xlf también contiene el número de línea donde está la fuente, por lo que parece que si cambia la fila, también tendré que volver a generar el archivo y actualizar manualmente mi archivo pt.

<context context-type="linenumber">16</context>

Eso no parece inteligente, me dará mucho trabajo extra para que siga funcionando. ¿Entiendes mi preocupación? ¿Me estoy perdiendo de algo?
Sé que Angular 7 i18n tendrá una gran actualización con la incorporación de Ivy, ¿debería esperar?

Atentamente,
fabio

PD Realmente espero que esto no esté fuera de tema, pero si sientes que lo está, por favor dame al menos una dirección. ¿Dónde debería estar preguntando esto, por ejemplo? O si hay un enlace que pueda responder a mis dudas.

@fabiopcarvalho Una cosa que me di cuenta es que es aconsejable usar ID personalizados para cada traducción para que sea más fácil realizar un seguimiento de los cambios en el diseño HTML.

Pero sí, deberá actualizar periódicamente el archivo de traducción.

@fabiopcarvalho uso xliffmerge para ayudarme con la fusión de las traducciones

Perfecto, usé esa herramienta y funcionó muy bien. También estoy usando los ids y
ellos ayudan
Gracias por la respuesta !!

El jueves 30 de agosto de 2018, Pedro Romero [email protected] escribió:

@fabiopcarvalho https://github.com/fabiopcarvalho Yo uso xliffmerge
https://github.com/martinroob/ngx-i18nsupport para ayudarme con la fusión
de las traducciones

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/angular/angular/issues/16477#issuecomment-417407822 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AWOWQ6vpjOb0Ntgpv7TUngRrBBsUIkVjks5uWCV7gaJpZM4NOSBk
.

Permitir mensajes ICU en atributos es fundamental para la accesibilidad porque el atributo aria-label se usa mucho en accesibilidad. ¿Hay algún problema para el seguimiento?

No creo que haya un problema para eso, ¿podrías abrir uno? Estoy trabajando en expresiones ICU para ivy en este momento, así que agregué TODO, pero una solicitud de función sería mejor

@ocombe , https://github.com/angular/angular/issues/21615

¡Perfecto, gracias (¡la búsqueda de Github es realmente mala!)!

¿Seremos capaces de realizar una carga diferida de los archivos de traducción desde una fuente externa, por ejemplo, a través de HTTP con la nueva versión de i18n?

@ocombe como dijiste que estás trabajando en Runtime i18n (un paquete para todas las configuraciones regionales con AOT). ha pasado más de un año que estamos esperando. ¿Cuándo podemos esperar que esa característica venga en la versión angular 7?

@Sef1995 es una de las cosas que queremos habilitar
@AhmadShahid requerirá ivy, que se lanzará independientemente de v7 e ivy no estará lista para el lanzamiento de v7. Algunas partes de ivy ya están en v6 detrás de una bandera, pero no es una función completa y no debe usarla en una aplicación del mundo real. Todavía no tenemos una fecha de lanzamiento para ivy.

@ocombe una pregunta rápida, si implementamos i18n a partir de hoy (angular6), que requerirá diferentes compilaciones (una para cada idioma), ¿se pierde el esfuerzo cuando sale ivy y el tiempo de ejecución de i18n? Me refiero a que la forma en que se implementaría i18n ahora diferirá de lo que viene. Intentar planificar algunos sprints con antelación y priorizar el trabajo. Gracias

No queremos crear cambios radicales si podemos evitarlo. Los identificadores de las traducciones extraídas pueden cambiar a medida que corrijamos errores que hemos tenido durante mucho tiempo, pero ofreceremos una herramienta de migración. No puedo decir con certeza que será 100% compatible, pero espero que la mayoría de las cosas funcionen igual, con nuevas opciones disponibles para usar si lo desea.

@ocombe una pregunta rápida, si implementamos i18n a partir de hoy (angular6), que requerirá diferentes compilaciones (una para cada idioma), ¿se pierde el esfuerzo cuando sale ivy y el tiempo de ejecución de i18n? Me refiero a que la forma en que se implementaría i18n ahora diferirá de lo que viene. Intentar planificar algunos sprints con antelación y priorizar el trabajo. Gracias

Hola, puede usar el paquete web requerido para cargar archivos dinámicamente (como una solución temporal) con una compilación:
El ejemplo se puede encontrar aquí: https://github.com/angular/angular/issues/24549#issuecomment -402013622

Tienes que compilar con --prod --aot=false, ya que AOT=true eliminará las cosas del paquete web.

@ocombe Hola,

La versión candidata de A7 está disponible, como prometimos, ¿probamos la traducción del tiempo de ejecución? Runtime i18n (one bundle for all locales with AOT) . ¿Cómo puedo probar esto? Por favor ayuda

Gracias

Secundo la pregunta de @sheikalthaf aunque ya se ha lanzado v7.

@sheikalthaf @Shuyinsama Como se explica en algunos comentarios anteriores y en el primer mensaje:
Runtime i18n requiere ivy, que se lanzará independientemente de v7. Algunas partes de ivy ya están en v7 detrás de una bandera, pero no es una función completa y no debe usarla en una aplicación del mundo real. Todavía no tenemos una fecha de lanzamiento para ivy.

@ocombe : ¿Qué hay de pasar la clave i18n dinámica del componente principal al secundario?

Componente hijo:
<div i18n="{{labelTextKey}}">{{labelText}}</div>

Componente principal:
<app-input [labelText]="'Second name'" [labelTextKey]="'@<strong i="13">@LabelSecondName</strong>'" ..></app-input>

Puedo pasarlo, pero como la traducción i18n ocurre en el momento de la compilación, la variable está en ese estado todavía vacía. Entonces, por lo tanto, no se produce ninguna traducción.

¿Alguna actualización para tal caso?

@bobkasbi

no necesita la etiqueta i18n en el componente secundario, solo puede usarla en el componente principal de esta manera:

<app-input i18n-labelText="@@LabelSecondName" labelText="Second name"></app-input>

@cjsase : funciona muy bien. ¡Muchas gracias! Estaba luchando con casi 2 días.

Basado en esto: https://github.com/angular/angular/issues/21706#issuecomment -430435254

• No deberíamos esperar ivy en v7. v8 está planificado para marzo/abril de 2019 . Si no deberíamos esperar ivy en v7, ¿hay alguna recomendación/consenso sobre qué usar para la internacionalización (i18n) hasta que se publique ivy en abril de 2019?

Esta es información incorrecta. El equipo central nunca dijo que IVy se lanzaría en 2019. En cambio , el equipo central dijo (énfasis mío):

debe ser lanzado en cualquier versión menor , siempre que haya sido probado y validado

Digamos que tengo una aplicación angular 7.1.0-beta.0 con ivy habilitado, ¿es posible que tenga una configuración con un cambio de idioma dinámico emitido desde el frente sin actualizar la página?

si si como? este documento: https://github.com/angular/angular/blob/master/aio/content/guide/i18n.md
y este documento: https://angular.io/guide/i18n

no cuentan con esto?

¿Dónde puedo aprender a hacer una aplicación i18n-angular moderna/futura?

@tatsujb no, no es posible, y no será posible incluso con ivy & runtime i18n. Tendrá que volver a cargar su aplicación Angular si desea cambiar el idioma, por ahora

ok, pero los documentos se aplican a una versión quimérica de angular como 4 menos.

No creo que se apliquen a mi configuración ni cubran exactamente cómo haces que el cambio surta efecto.

Supongo que el cambio tendrá que ser aplicado por el backend.

En mi caso, mi angular se sirve en modo de producción mediante un backend java-spring. ¿Cuáles son las grandes líneas de lo que sucederá cuando presione el ícono de la bandera para cambiar el idioma?

Lleva al usuario a www.yourdomain.com/cn/ donde tiene toda su aplicación Angular compilada en chino. Termina con una aplicación Angular compilada completa para cada idioma que desea admitir.

@ocombe @santhony7 ¿qué pasa con esto: https://github.com/actra-development-oss/ng-i18n-aot-loader ?

¿podría probar esto?

¿Es malamente compatible con 7.1.0-beta.0 o decentemente compatible?

@ocombe @santhony7 ¿qué pasa con esto: https://github.com/actra-development-oss/ng-i18n-aot-loader ?

¿podría probar esto?

¿Es malamente compatible con 7.1.0-beta.0 o decentemente compatible?

Recomiendo usar ngx-translate en su lugar. He usado ambos y ngx-translate es mucho más fácil de mantener.

@digismack otra diferencia entre los dos, que da un poco de miedo es que ngx-translate elimina todas las cosas oficiales de angular-i18n y no usa nada de eso. es todo su propio circuito independiente y los archivos json son mucho menos específicos sobre las fuentes de las traducciones.

Además, de las dos demostraciones, ngx-translate parece mucho más lento, ¿a qué te refieres cuando dices que era más fácil de mantener?

@tatsujb como desarrollador de th ng-i18n-aot-loader, sé que es bastante difícil de implementar, al menos integrando los cargadores.
Todo lo demás es pan comido ya que sigue los paradigmas angulares i18n originales.

Debería funcionar con v7 siempre que no haya habido cambios importantes en las estructuras de etiquetas o similares.

tratando de implementar ngx-translate, tengo que ir de lugar traducible por lugar traducible. hay cientos, es un poco ridículo para mí que no pueda usar mis etiquetas i18n que ya había planeado con anticipación.

Empiezo a pensar que confiar en ti fue una elección equivocada, @digismack

@tatsujb Hay 58 personas siguiendo este problema. Personalmente, lo sigo para conocer las actualizaciones del equipo de Angular con respecto a i18n. Le agradecería que detuviera la charla a menos que esté relacionada con lo que dice el OP:

Si desea que se agreguen nuevas funciones i18n a Angular, no dude en preguntar a continuación y le informaré si eso es factible y si debe abrir un problema para ello.
Si tiene un error, abra un problema (no es necesario discutirlo aquí).

Si tiene problemas con otras bibliotecas, le sugiero que haga una pregunta en StackOverflow.

No tengo la costumbre de escribir/comentar el problema... ¡pero lo haré!
Considerando :
@gtbuchanan y CO son personas del tipo A.
@tatsujb y otras personas que se quejan/comentan/esperan cosas son del tipo B de persona

Tipo A no te cansas de repetir siempre las mismas cosas?!?! Para mí eres más molesto que el tipo B.

debido a la falta de la función i18n en angular Tipo B, las personas están más frustradas que usted que simplemente se "suscribe" a un problema (si es para hacerse amigos, gane algunos Me gusta, vaya a Facebook, no sé, aquí no hay lugar para eso) , ¡no cambiarás de palabra ni inventarás algo diciendo eso!...)

Creo que el tipo A puede cancelar la suscripción, esperar la actualización, verificar el registro de cambios rápidamente o leer blogs/noticias, asegúrese de que el equipo angular lo pondrá en fuente grande ARIAL 72 píxeles que introducen la traducción dinámica i18n de ts + runtime i18n: ¡falta una gran característica en angular! no lo consideraron enormemente, por lo que no tenemos i18n correcto hoy, ¡esta es una estrategia de Google y esto no puede cambiar!

La gente B espera esta característica hace 2 años, https://github.com/angular/angular/issues/9104#issue -159302131 ¡sí desde angular 2.X!

Solo quiero decirles que respeten al tipo B frustrado y no sean malvados. Si nadie se queja mucho de i18n, creo que la mejora de i18n no se considerará en los próximos años, ¡esto también es de código abierto! quejarse de los críticos! ¡La estrategia puede cambiar! así que deje que la gente se queje, anule la suscripción, ¡usted es mejor que otros, puede encontrar su información sin suscribirse a este problema!

Tipo B, ¡continúe quejándose/comentando hasta que pueda! ¡Es la única mejor manera de entender las necesidades de las personas!

Huelga Huelga jajaja

@tatsujb Todo se reduce a preferencias personales. La última vez que implementé ng-i18n-aot-loader , tuve que ejecutar una compilación expulsada y personalizar la configuración del paquete web para que funcionara. Tal vez ese ya no sea el caso. Sin embargo, ejecutar una compilación expulsada significaba que las herramientas de Angular CLI ya no se podían usar. Entonces, a la larga, me resultó más fácil implementar ngx-translate y lidiar con el hecho de que funciona de manera un poco diferente.

@gtbuchanan Siento tu dolor, pero esta "charla" está directamente relacionada con el alcance de las características mencionadas en la publicación de OP. Dado que el plazo para Runtime i18n (one bundle for all locales with AOT) ha seguido disminuyendo, la gente todavía acude a este hilo para buscar soluciones actuales.

@ocombe , estamos a punto de comenzar un nuevo proyecto ahora, donde obtendremos las traducciones de una base de datos.
Nuestros módulos Angular se cargarán con pereza y también nos gustaría estar lo más cerca posible de lo que ofrece Angular con respecto a I18N.

Dado que la compatibilidad con Angular I18N no se incluyó en la última versión según lo planeado, ¿tiene alguna recomendación para nosotros y otros que están a punto de crear nuevos proyectos en este momento?

Por ejemplo, hasta que I18N esté listo, podríamos usar ngx-translate, pero luego leí en algún lugar de los problemas de github de ese proyecto, que no admitirá la carga diferida, lo que sería un problema para nosotros.

Luego, por otro lado, el soporte I18N de Angular aún no está listo para el horario de máxima audiencia.

Realmente agradecería algunos consejos que nos indiquen la dirección correcta sobre qué usar para el próximo proyecto: ¿ngx-translate vs?

Debe tener:

• carga lenta

Agradable tener:

• expresiones de la UCI

Merci

Para los seguidores de este número, @ocombe hablará sobre el tiempo de ejecución i18n en angularconnect en un par de horas. Supongo que al menos algunas de las preguntas abiertas serán respondidas allí. hay una transmisión en vivo disponible

@ctaepper - ¡Muchas gracias por la información!

@guygit esto podría ser ngx-translate o angular-l10n . aquí está la tabla de comparación creada por mí https://medium.com/@sergeyfetiskin/tools -to-translate-your-angular-app-c021e25ff26a

para nuestras aplicaciones, decidimos optar por Angular aunque tiene algunas limitaciones.

@fetis Muchas gracias, le echaré un vistazo :-)

Se pregunta sobre la elección de archivos XLIFF para los archivos de traducción: Google Translate Toolkit y Flutter/Dart i18n admiten archivos ARB y no admiten XLIFF. Escuché que el soporte de archivos ARB no está planeado, pero me pregunto si esto es algo que podría considerarse nuevamente. O si alguien (¿ @ocombe ?) Pudiera señalar dónde interactúa Angular con los archivos XLIFF para que pueda ver lo difícil que sería integrar la compatibilidad con ARB.

(Para algún contexto, vamos a usar Flutter/Dart para nuestras aplicaciones móviles y Angular para nuestra aplicación web, y realmente nos gustaría compartir nuestros archivos de traducción entre el móvil y la web si es posible. Estoy considerando escribir un Convertidor ARB -> XLIFF si no hay interés en considerar su inclusión en Angular).

@localpcguy si termina escribiendo un tipo de convertidor, es posible que le interese contribuir con https://github.com/translate/translate , que ya ofrece conversión desde/hacia muchos formatos.

En una nota al margen, ocombe dijo hace unos meses que presionaría mucho para admitir archivos PO (¿y JSON?). Con suerte, sucederá en algún momento, porque tuvimos dificultades para encontrar herramientas adecuadas para trabajar con XLIFF.

porque nos costó mucho encontrar herramientas adecuadas para trabajar con XLIFF.

@PowerKiKi eso simplemente no es cierto. Casi cualquier herramienta de gestión de traducción en línea es compatible con el formato XLIFF. E incluso hay programas de traducción de escritorio gratuitos si no desea editar .xliff manualmente

@fetis Odio salirme del tema, pero he encontrado bastante dolor con respecto al uso de XLIFF con herramientas. Vea mi comentario aquí: https://github.com/angular/angular/issues/20193#issuecomment -345755889

Proporcione referencias a tales herramientas, porque todavía no hemos encontrado nada bueno y todavía tenemos que encontrar algo que sea compatible con XLIFF 2. Smart Cat se ve bonito, pero actualizar las cadenas me da ganas de medir mis ojos.

Parece que sabes algo que nosotros no :)

Pootle usa https://github.com/translate/translate y fue realmente genial con Gettext (archivos po), pero no admite marcadores de posición/etiquetas y están esperando la contribución de alguien para agregarlo.

He estado suscrito a este número durante un largo año más o menos. Parece que el progreso en este sentido no es una prioridad para el equipo de Angular, y tener que compilar la aplicación una vez para cada idioma y pasar por aros para hacer traducciones dinámicas no es aceptable. Recomiendo, si puede hacerlo, crear una tubería personalizada que use cualquier otra biblioteca i18n que desee. Al ser pura, esta tubería será igualmente eficiente para compilar la aplicación varias veces. Además, al usar un i18n que no depende de Angular, podrá realizar traducciones dinámicas del código de manera trivial. Otra ventaja es que tus traducciones ya no dependerán de Angular, por lo que podrás empezar a migrar algunos componentes a otros frameworks si lo deseas, o incluso podrás elegir el formato de traducción y las herramientas que prefieras con total libertad. Estoy usando https://airbnb.io/polyglot.js/ y estoy muy contento con él, e incluso cuando la migración de mi aplicación de Angular i18n a polyglot todavía está en curso, no puedo estar más contento con el resultado y la eliminación. de la dependencia con Angular i18n.

Lo siento por los que recibirán esto como una notificación en su correo y no les importa mi opinión, pero dado que ha pasado tanto tiempo leyendo sus notificaciones, siento que tengo que despedirme antes de cancelar la suscripción :)

¡Salud!

Parece que el progreso en este sentido no es una prioridad para el equipo de Angular, y tener que compilar la aplicación una vez para cada idioma y pasar por aros para hacer traducciones dinámicas no es aceptable.

Runtime i18n es una gran prioridad para Angular Team. Sin embargo, el problema de bloqueo es el nuevo renderizador Ivy. El progreso del proyecto es bueno hasta ahora y probablemente podamos esperar Ivy para Angular 8. Entiendo que esta es una situación difícil para todos los involucrados. Hay planes, pero no se pueden implementar mientras Ivy no esté terminado.

Consulte las charlas de la reciente conferencia AngularConnect (2018) en Londres, especialmente "Runtime i18n" de Olivier Combe y el discurso de apertura del día 2 de Alex Rickabaugh.

De hecho, mi experiencia es similar a @intellix.

XLIFF 1.2 tiene 10 años , pero su soporte en proyectos de código abierto parece ser bastante pobre. Pootle no es compatible con titulares de plazas según https://github.com/translate/pootle/issues/4762 y https://github.com/translate/pootle/issues/1811. Weblate tampoco los admite , aunque un PR podría agregarlos pronto .

En el escritorio, Virtaal _sí_ admite marcadores de posición XLIFF, pero la última versión 0.7.1 tiene 6 años y, por lo que escuché, ya no funciona en la última versión de macOS. Desgraciadamente no da la impresión de un proyecto bien cuidado, con unos PR muy antiguos que aún esperan ser fusionados a pesar de su aparente sencillez. Y una actividad de commit muy baja en los últimos años .

Me acabo de enterar que Poedit 2.2 lanzado hace unos días es compatible con XLIFF 1.2 y 2.0. Desafortunadamente, no puedo probarlo porque recibo un error de snapcraft.io CDN cuando lo instalo en este momento. Pero esta podría ser la mejor solución para los usuarios de escritorio.

@fetis si encontró algunos proyectos de código abierto (o al menos de uso gratuito) para editar XLIFF 1.2, o mejor aún, XLIFF 2.0, con soporte para marcadores de posición, indíquelos aquí. Todo lo demás que probé no funcionaba en absoluto o era abismalmente complejo de usar.

@intellix @PowerKiKi aquí está la lista de lo que sé. Nuestro objetivo es una plataforma de traducción en línea, donde podemos colaborar con traductores/colegas de diferentes países. Pasar por el proceso de instalación de software de escritorio para cada colaborador y administrar la sincronización de archivos XLIFF no es una opción para nosotros. Entonces, no probé herramientas de escritorio, plataformas que hice.

Aplicaciones
OmegaT
https://omegat.org/

autohospedado
https://welate.org/es/ +hosting pagado
https://pootle.translatehouse.org/
https://pontoon.mozilla.org/

Plataformas
Crowdin
https://crowdin.com/
soporte CLI

WebTranslateIt
https://webtranslateit.com/
soporte CLI

Transifex
https://www.transifex.com/

FraseApp
https://fraseapp.com/

Localizar
https://lokalise.co/
soporte CLI

_Creo que terminaremos con Lokalise para nuestros proyectos, ya que proporciona suficiente funcionalidad a un precio asequible._

~Editor de PO~
https://poeditor.com/pricing/
La compatibilidad con XLIFF declarada no funciona con el formato Angular

Si está buscando una solución de código abierto, esta lista podría resultarle útil https://opensource.com/article/17/6/open-source-localization-tools

Nodos laterales
No vi una plataforma en línea compatible con XLIFF 2.0 y fue una gran sorpresa para mí. XLIFF 1.2 está oficialmente marcado como obsoleto y nadie en la industria dio soporte para v2.

Feliz de escuchar que POEdit declaró soporte XLIFF, lo usé para archivos .po y eso fue bueno.

PD: Lamento mucho hacer un tema fuera de lugar aquí, pero al mismo tiempo, obtener el archivo XLIFF de su aplicación es solo una parte del viaje, debe traducirlo y mantenerlo a lo largo del ciclo de vida de su aplicación. Entonces es una discusión importante. Sugeriría mudarme a algún lugar, puedo poner esta lista como un artículo de Medium y podemos mantener la discusión allí.

@localpcguy hay muchos formatos, pero todo se reduce a cuántos podemos admitir. Escribir y mantener un serializador lleva tiempo. Xliff 2 fue agregado como relaciones públicas por otra persona, es por eso que agregamos el soporte (de lo contrario, no nos habríamos tomado el tiempo para brindar soporte).
Necesitamos un serializador para dos cosas: extracción y fusión.
No he hablado de esto en Angular Connect, pero espero que podamos usar un serializador externo. Debería ser muy fácil hacerlo para el tiempo de ejecución (combinar) con ivy, pero la extracción aún es complicada porque el serializador debe actualizarse cuando hacemos cambios en el compilador.
Tengo algunas ideas sobre cómo hacerlo, pero tendré que hablar con el equipo al respecto una vez que llegue la hiedra. Lo que realmente me encantaría hacer sería al menos agregar soporte JSON para poder reescribir ngx-translate usando Angular i18n (y porque mucha gente lo quiere).

Gracias @ocombe (y todas las demás entradas, me gusta ver las distintas vistas). Parece que #14185 fue el PR que mencionaste, ¿sigue siendo un buen punto de partida si quiero agregar soporte ARB? ¿Es algo que potencialmente podría fusionarse si se envía?

@localpcguy tenemos una reunión mañana donde discutiremos eso (y otras cosas), les dejaré saber cómo va

ok, esto es lo que creemos que funcionaría: para la extracción, extraeremos cadenas en algún tipo de formato json (incluso podría ser ARB, ya que es un formato json oficial para traducciones) que cualquiera puede tomar y posprocesar en cualquier formato que desee usar. (json es realmente fácil de usar), y para el tiempo de ejecución proporcionaremos algún tipo de interfaz que puede usar para escribir su propio cargador que comprenda su formato.

Entonces, ¿esto significa que somos libres de usar cualquier tipo de formato para las traducciones siempre que podamos proporcionar un cargador para la aplicación?

Bueno, esto sería genial :+1:

sí, no tendría acceso a optimizaciones profundas (reemplace las cadenas en el momento de la compilación para crear un paquete por idioma, lo que significa que las traducciones se dividirían en código con sus componentes), pero podría usar cualquier tipo de solución de carga diferida que desee, siempre que cargue todas las traducciones cuando se inicia la aplicación (deben cargarse de forma sincrónica antes de crear un componente)
eventualmente, también podría codificarlos manualmente y cargarlos con el enrutador de forma asíncrona cuando cargue un nuevo componente, eso depende de usted, utilizando las nuevas funcionalidades de carga diferida que proporciona ivy (Jason hizo una demostración de eso en Angular Connect)

¿Podemos esperar una demostración beta (no archivos, solo un video o una transmisión en vivo) de cambiar de idioma sobre la marcha en Ivy? tratar de armar una hiedra pre-final de POC podría ser una excelente manera de detectar bombardeos en el futuro.

No es que no esté de acuerdo con el enfoque de esperar una hiedra de piedra más fijada antes de verter el sudor del desarrollador en live-i18n, creo que un POC a pequeña escala de un solo hombre es una pequeña cantidad de sudor para un retorno inmenso en forma de previsión y podría evitar que live-i18n sea empujado hacia 2020.

El servicio de tiempo de ejecución para usuarios externos aún no está listo, solo tenemos el código que usa el cierre ( goog.getMsg ) porque eso es lo que necesitábamos para probar ivy con las aplicaciones de Google.
Estaré trabajando en esto ahora durante los próximos meses. Esto significa que probablemente todavía no puedas usar i18n con ivy.
El código para el tiempo de ejecución i18n se fusionó ayer, y el código del compilador para i18n debería fusionarse en los próximos días (¡lo estamos logrando!). Luego, trabajaremos en el nuevo servicio para personas externas, incluidos los nuevos cargadores de los que hablé anteriormente y el servicio para usar traducciones en su código.

En cuanto a cambiar el idioma sobre la marcha, aún requeriría una recarga completa de la aplicación, o tal vez un cambio de ruta (que limpiaría todos los componentes existentes). No intentaría trabajar en un POC todavía.

En cuanto a cambiar el idioma sobre la marcha, aún requeriría una recarga completa de la aplicación, o tal vez un cambio de ruta (que limpiaría todos los componentes existentes). No intentaría trabajar en un POC todavía.

eso es justo, ... sin embargo, no requiere una recarga completa de la aplicación (o cualquier cosa que logre la fluidez a los ojos del usuario final, es decir, no perder la tienda, ni la autenticación, ni la URL (bueno... sin tener en cuenta /en/... ) y todo dentro de un plazo razonable) ... sigue siendo el plan, ¿verdad?

@tatsujb Recargar la aplicación no es recargar la página, StackBlitz recarga la aplicación en cada edición, ¿sientes que es observable a tus ojos?

Recargar la aplicación significa desmontar la aplicación y luego montarla en la misma posición, equivalente a una transición SSR-CSR (es CSR-CSR), y no debería haber tareas asíncronas en el proceso de arranque posterior si se considera una arquitectura de caché adecuada.

entonces con esta configuración correcta; almacenar valores variables y la autenticación (así como la cantidad de desplazamiento en divs desplazables) permanecería?

@tatsujb Siempre que estén almacenados fuera de la instancia creada por Angular, por ejemplo, en una variable léxica o una propiedad de ventana.

@trotyl ¿Cómo recargas la aplicación sin la página?

@saithis Siempre arranca la aplicación por platformBootstrap().bootstrapModuleFactory() (u otro equivalente) imperativamente, puede llamarla en cualquier momento y en cualquier lugar, no hay magia en la llamada (excepto que Angular CLI actualmente tiene alguna limitación para el reemplazo de código, ya no debería ser un problema en Ivy).

Bootstrap con entusiasmo en el momento de la invocación del script y mantenerlo para siempre (no desmontar) es solo una práctica común para SPA, pero nadie lo obliga a hacerlo.

EDITAR: en caso de que alguien lo haga, también es necesario destruir el NgModuleRef de arranque para evitar la pérdida de memoria. Estas son preguntas fuera de tema y es mejor discutirlas en otro canal, es mejor hacer un seguimiento de la discusión de i18n aquí.

@trotyl Gracias, no sabía que el arranque nuevamente funciona.

@ocombe , ¿podría eliminar el spam aquí? y mi comentario también.

1. a @fetis : las personas como usted deben dejar de seguir el problema y suscribirse para el lanzamiento
   

2. a @Andrulko : no nos importa

3. a @ angular: como dije, ¡entiendo perfectamente las quejas aquí! como que queríamos ivy para v7, no para vX o no vendimos una gran mejora para v7 mientras no pudiste responder o lo pondrás en 7.x solo para respetar tu fecha límite... ¡esto no es justo! sí, la opción debería ser no anunciar nada y nadie se quejará, esto también es una mala idea, necesita hacer su lugar en framwork. sí, esperamos i18n correcto desde v2, en este aspecto obligatorio para la gran aplicación no podría vender angular listo para la gran aplicación como la aplicación web internacional que contiene 50000 cadenas, por supuesto que no le gusta leer esto, pero es sin compasión y con buena Fe, en mi humilde opinión, si no consideramos i18n y el tiempo de desarrollo/construcción lento para todos los demás aspectos, puedo decir que angular es increíble. Cierta dirección debería cambiar en la parte superior, estoy hablando con los que deciden, por supuesto. Gran excepción de nuestra parte (que criticamos) porque desde Big-Google no pudimos cometer un gran error como este. Veo que a los desarrolladores de Google les gustan las personas excepcionales: gente inteligente sin duda, ¡estas cosas no deberían suceder para los desarrolladores experimentados y para los equipos de desarrollo como Google! ¡Mi opinión global no vende angular 100% para aplicaciones grandes cuando la empresa lo elige y luego vende / explica a la empresa privada qué es el código abierto!

4. @ todo especialmente para aquellos que no trabajan en una empresa comercial: no me gusta mi comentario porque ciertamente no respeto el código abierto?!?!, jajaja dile esto a mi jefe que espere... que espere... después de elegir angular porque creemos está listo (100%, no 80%) para aplicaciones grandes... ¡dependemos!

este es mi ultimo comentario aqui porque salimos del barco! cancelar la suscripción + no elegir angular en mi próximo proyecto (podría decir que es el ganador, el proyecto de código abierto no necesita personas como nosotros)

¡Qué pasión! Solo para mantener el equilibrio... reescribimos nuestra aplicación en Angular 6, la internacionalizamos en 6 idiomas y solo hemos sentido inconvenientes menores. Claro, los tiempos de compilación más rápidos y las traducciones sobre la marcha sin duda serían agradables, pero no el fin del mundo para nosotros. El 98% del marco que no es i18n es impresionante. ¡Buen trabajo chicos! Mirando hacia adelante a las nuevas características.

También tenemos una experiencia fantástica con Angular para nuestro nuevo portal empresarial. El i18n es la última característica que falta que necesitamos ya que, en Suiza, tenemos que admitir cuatro idiomas. Creo que el problema aquí es con la comunicación. Para la planificación de proyectos, si tuviéramos una mejor estimación del lanzamiento de i18 hace un año, podríamos haberlo planificado y considerar otras posibilidades. Dicho esto, estamos deseando escuchar cualquier actualización. :-)

En defensa de angular, puede usarlo de manera bastante simple en producción como esta (la mejor solución que encontré)

1. Envuelva el texto variable traducido en su propio componente para mover la lógica de traducción a algún lugar

parent-component.component.html

<app-route-translation
  [routeData]="routeData"
></app-route-translation>

route-translation.component.html

<span
  i18n="route text|Navigation text for route@@routeText"
>{
  routeData.langKey, select,

  home-1 {Home 1}
  home-1-1 {Home 1-1}
  home-1-2 {Home 1-2}
  home-2 {Home 2}
  home-2-1 {Home 2-1}
  home-2-2 {Home 2-2}
  home-root {Home root}
  lazyPage {Lazy page}
  notFound {404}

  other {Other}
}</span>

1. Configure las carpetas de configuración de compilación en angular.json como

"prod-en": {
  ...
   "outputPath": "dist/en/",
  ...
},
"prod-ru": {
  ...
   "outputPath": "dist/ru/",
  ...
}

1. Configure el archivo de compilación docker como este para compilar la aplicación para diferentes idiomas

FROM node:8 as build-stage
WORKDIR /app
COPY angular-util .
RUN npm install
RUN npm run ng build -- --configuration=prod-en
RUN npm run ng build -- --configuration=prod-ru

FROM nginx
WORKDIR /usr/share/nginx/html
COPY --from=build-stage /app/dist .
COPY nginx.conf /etc/nginx/conf.d/default.conf

1. Use este nginx.conf para servir la aplicación en subdominios (como en.site-name.com, ru.site-name.com), donde ru en set $subdomain ru; debe reemplazarse con su configuración regional predeterminada

server {
  listen 80;
  set $subdomain ru;
  if ($host ~ ^(\w+)\.) {
    set $subdomain $1;
  }
  location / {
    root /usr/share/nginx/html/$subdomain;
    try_files $uri $uri/ /index.html =404;
  }
}

Para más detalles ver aquí
https://github.com/ivanivanyuk1993/angular-util/tree/master/src/app/util/shared/route-list
https://github.com/ivanivanyuk1993/titans-shoulders-project/tree/master/container-description/ui-container-description

Quisiera un pulgar arriba por este comentario. Puede que no sea perfecto, pero sigue siendo la publicación más útil sobre este tema que encontré en la web.

Hola, todos,

Estoy usando traducciones i18n para mi proyecto. Tengo dudas en la siguiente área:

1. ¿Es posible generar diferentes archivos de origen xlf para diferentes bibliotecas (creados con el comando ng generar biblioteca libraryName)?
2. Al usar la internacionalización para seleccionar o pluralizar, el archivo fuente xlf generado crea la identificación de la unidad trans para las diferentes alternativas. ¿Es posible proporcionar una identificación a través de una plantilla también para diferentes alternativas? (como se muestra en la imagen a continuación)
   

Por favor me pueden ayudar con algunas respuestas.

@LearnersLicense :

1. Debería poder extraer un archivo de traducción por proyecto que maneja el cli. Dicho esto, las traducciones no funcionan con las bibliotecas en este momento (lo que significa que alguien que consuma su biblioteca no podrá cargar sus traducciones para esa biblioteca). Está en la parte superior de nuestra lista de tareas pendientes para las próximas funciones que implementaremos (con traducciones de código)

1. No creo que sea posible. Puede nombrar marcadores de posición con comentarios especiales: <div i18n>Some value: {{ valueA // i18n(ph="PH_A") }}</div> pero no creo que funcione con expresiones ICU, @AndrewKushnir .
   Puede realizar una solicitud de función para eso, o tal vez agregar un comentario a https://github.com/angular/angular/issues/24080 que parece ser similar (agregar descripción/significado a las expresiones ICU)

alguien que consuma su biblioteca no podrá cargar sus traducciones para esa biblioteca

Una forma de solucionar esto es:
1) hacer que la biblioteca extraiga i18n en xliff y traduzca
2) enviar archivos xliff con el paquete de la biblioteca

3) el consumidor también extrae sus propios archivos xliff
4) el consumidor carga xliff en el analizador xml. descarta cualquier unidad trans que se origine en node_modules
5) el consumidor concatena su xliff con la biblioteca xliff

lo que significa que alguien que consuma su biblioteca no podrá cargar sus traducciones para esa biblioteca

Tal vez estoy malinterpretando esta afirmación, pero sé que con la configuración de traducciones para las aplicaciones de mi empresa, cuando construyo mis archivos xlf , incluyen claves especificadas en las plantillas de otros proyectos. Uno que me viene a la mente es https://github.com/ng-bootstrap/ng-bootstrap

Esto no parece posible en este momento:

<my-button i18n-title="@@SHARED_GO_LABEL" [title]="'Go'" [button-style]="'primary'" (click)="navigateToForm()"></my-button>

Dentro del alcance de estos cambios, ¿se abordará esto (o estoy haciendo algo mal)?

@mikejr83

Eso es posible. Solo tienes que asignar el valor base de title como title="Go" y no [title]="'Go'"

gracias @ocombe y @ewok-janitor por sus respuestas y sugerencias. 👍

@ocombe , ¿hay alguna fecha tentativa para cuando las traducciones para la biblioteca estén disponibles?

Sin fecha por ahora. Para la primera versión de ivy, solo intentamos tener paridad de funciones. Trabajaremos en las nuevas funciones (incluidas las traducciones de código y la compatibilidad con la biblioteca) inmediatamente después (o, de hecho, comenzaremos a trabajar en ellas antes, pero no estarán terminadas cuando ivy se lance en versión alfa). Estará disponible antes de que ivy se convierta en el predeterminado.

¿Existe ya una solución para los archivos xliff? https://github.com/angular/angular/issues/17506
Es imposible usar el formato en absoluto mientras las referencias no sean fijas.

@ocombe ¿ Algún plan para admitir traducciones de rutas?

se ha solicitado varias veces sí, no es un plan inmediato pero está en la lista de cosas por hacer

Hola, ¿hay alguna documentación sobre cómo usar el tiempo de ejecución i18n cuando ivy se lanza en versión beta?

@marcelnem , si revisa esta URL, todos los puntos de documentación están pendientes.

https://es-angular-ivy-ready.firebaseapp.com/#/status

@ocombe gran trabajo que está haciendo en Google ahora. Angular i18n debería haber sido 'algo' como ngx-translate desde el principio. Me preguntaba si habrá una guía de migración, una herramienta automatizada, una comparación de características... para migrar de ngx-translate al estilo Angular i18n una vez que se lance Angular 8/9.

hola ocombe
Necesito consultar con usted con respecto a esta función, la que indicó anteriormente
Tiempo de ejecución i18n (un paquete para todas las configuraciones regionales con AOT) - [trabajando en ello] >> ¿Todavía está en progreso o está fuera?

¿Podría informarme, cualquier solución, si aún está en progreso?
Gracias

@ocombe , escribió anteriormente que los paquetes de idioma deben cargarse mediante la carga de encaje. ¿También será posible cargar los paquetes de idioma directamente en el index.html? Porque tenemos el caso de que nuestra aplicación se ejecuta sobre AWS Lambda y los archivos angulares compilados se almacenan en un depósito S3. En realidad, ya es una solución alternativa que esto funcione, pero no podemos usar la carga lacy porque Angular no puede cargar los archivos de otro host. Por lo tanto, todos los archivos que necesita Angular ya deben estar incluidos en el index.html (donde agregamos el host S3 a través de un script).

@nidhi8953 todavía es WIP, estará disponible con ivy, por ahora solo funciona dentro de Google (porque usamos Closure Compiler internamente para las traducciones). El servicio de tiempo de ejecución que manejará las traducciones es muy experimental para el mundo exterior. Si desea probar algunas cosas, puede consultar este ejemplo: https://github.com/angular/angular/blob/master/packages/core/test/bundling/hello_world_i18n/index.ts pero debe saber que las funciones aún son privadas por una razón, serán renombradas y modificadas en un futuro muy cercano. El objetivo actual es comenzar a trabajar en un conjunto sólido de API una vez que v8 esté disponible (al final del mes) e iterar alrededor de esto para todo el v8 hasta que v9 esté disponible, momento en el cual la API debe considerarse estable.

@vekunz si seguimos nuestros planes actuales, debería ser posible, sí, ya que de todos modos necesita tener el archivo de traducción cargado en el arranque de su aplicación

@ocombe ¿Podemos usar Ivy (actualmente 8.0.0-rc.3) e implementar i18n usando el método Angular 7 de compilaciones múltiples? ¿O debo quedarme con Angular 7 hasta que se publiquen las API i18n para Ivy? Si es posible, me encantaría aprovechar Ivy y, al mismo tiempo, usar la forma antigua de i18n hasta que esté disponible el nuevo método de tiempo de ejecución.

Actualización: después de probarlo, ni la extracción ng xi18n (ver #https://github.com/angular/angular-cli/issues/14225) ni la construcción con i18n tienen ningún efecto. No se exporta ningún archivo .xlf ni se traduce ninguna palabra. Pero con la opción enableIvy establecida en falso en tsconfig.app.json, ambos funcionan muy bien con la versión 8.0.0-rc.3. Esto significa que puedo seguir la ruta de actualización de Angular, no perder i18n, obtener algunos de los nuevos beneficios como la carga diferencial y estar listo para encender Ivy una vez que i18n funcione.

@jacobbowdoin como descubriste que no funciona con ivy, pero funciona si no está activado.
Quería hacer que el antiguo sistema de extracción/carga funcionara con ivy, pero dado que solo habría sido temporal, el equipo no lo determinó como una prioridad (lo cual es comprensible, hacer que las cosas obligatorias funcionen primero es la prioridad).

Hola @ocombe , queremos desarrollar el i18n ahora, por lo que no podemos esperar al tiempo de ejecución-i18n. ¿Aún recomendarías usar ngx-translate? ¿Tiene sentido usarlo con i18n-polyfill? ¿El uso de i18n-polyfill facilitará la migración a runtime-i18n?

Si usa ngx-translate, no use i18n-polyfill. Solo tiene sentido usarlo si usa angular i18n para las plantillas.
ngx-translate sigue siendo relevante y fácil de usar. No es necesario que instale toda la infraestructura para admitir compilaciones múltiples (una por configuración regional).

Hola @ocombe , ¿hay alguna actualización de estado en:

-Tiempo de ejecución i18n
-Usar cadenas de traducción fuera de una plantilla - #11405

Actualmente estamos debatiendo si deberíamos esperar las traducciones del código fuente o usar i18n-polyfill (ya comenzamos con i18n). Podemos esperar fácilmente algunas semanas, por lo que se agradecería una línea de tiempo aproximada. ¡Muchas gracias!

@halilovicedvin tan pronto como ivy sea el valor predeterminado en las aplicaciones de Google, comenzaremos a trabajar en el servicio de tiempo de ejecución i18n para usuarios externos, así que en algún momento entre pronto y v9
No contaría con ello hasta después del verano porque la gente se va a tomar unos días libres

@halilovicedvin comenzamos con i18n con i18n-polyfill hace algunas semanas y funciona muy bien. Espero que runtime-i18n se use de la misma manera que i18n-polyfill

@vekunz También esperaba que si usamos ngx-translate con i18n-polyfill , podremos migrar más fácilmente a runtime-i18n pero después del comentario de @ocombe (https://github.com/angular/angular/issues /16477#issuecomment-498239301) No estoy seguro de si el esfuerzo adicional para configurar el polyfill está justificado. Tal vez solo usemos ngx-translate solo.

@vekunz, ¿cuál es tu experiencia configurándolo?

@marcelnem no puede usar ngx-translate con i18n-polyfill. i18n-polyfill solo se puede usar con angular-i18n.

La configuración de i18n-polyfill fue realmente muy sencilla. Incluso la documentación no es exactamente correcta, descubrí muy rápido qué cambiar.

@vekunz Ahora entiendo, gracias. No estoy seguro de cuál es el propósito del i18n-polyfill. ¿Aún tiene que compilar la aplicación varias veces e implementarla varias veces en http://myapp/en , http://myapp/de , http://myapp/fr ,... como con angular i18n oficial?

@marcelnem sí, también necesita una compilación múltiple con i18n-polyfill. El propósito es que con angular-i18n puede usar traducciones actualmente solo dentro de las plantillas html y no dentro de su código mecanografiado. i18n-polyfill extiende angular-i18n para usar traducciones dentro de su código mecanografiado también.
Con Angular 9 (que llegará en otoño), angular-i18n también admitirá traducciones dentro de mecanografiado, pero mientras tanto, necesitamos i18n-polyfill para esto.

@vekunz , ¿puedes dar un poco más de detalle sobre esto?: "Incluso la documentación no es exactamente correcta, descubrí muy rápido qué cambiar". Probablemente mire i18n-polyfill la próxima semana, por lo que agradecería cualquier información. Gracias

@halilovicedvin @marcelnem Creé un documento de pastebin donde lo describo, porque no es el tema principal de este problema de GitHub https://pastebin.com/Xib6X6E9

@ocombe Usando la herramienta xi18n, ¿puedo restringir la ruta de entrada solo a la carpeta src (para generar las traducciones) en lugar de todo el proyecto/repositorio?

@ocombe , ¿Ivy admite varias configuraciones regionales con Angular 8 (solo la definición de configuración regional, no el archivo de idioma; por ejemplo, para las canalizaciones de fecha)? Porque otro equipo usa Angular actualmente con ngx-translate, pero un componente de terceros necesita la configuración regional correcta. Una opción sería usar el compilador JIT en modo prod, pero esto no es muy agradable. Pero tampoco pueden compilar un paquete nuevo para cada idioma, porque sería demasiado.

@vekunz no, no puede configurar varias configuraciones regionales, debe configurar la configuración regional para cada paquete compilado (se puede configurar en el archivo de configuración cli)
Sé que no es lo que querías escuchar, pero así es por ahora.

@ocombe ¿Puede decirnos algo? Sé que el equipo de Angular no lo identifica como un problema, pero ¿cree que Angular nos permitirá en un futuro previsible cambiar el idioma en tiempo de ejecución sin recargar la aplicación, por lo que tener la traducción en un solo paquete y tener la posibilidad de cargar las traducciones correctas y vincularlas con los literales de texto?

Tener un paquete, sí, pero las traducciones tendrán que cargarse en boostrap (cuando se carga la aplicación). Con la arquitectura existente sería muy complicado recargar "en caliente" las traducciones sin recargar los componentes que ya usan las traducciones.
No digo que esto sea imposible, pero lamentablemente no veo que suceda en un futuro previsible.

Gracias @ocombe por la rápida respuesta :) Sigan con el buen trabajo :+1:

En algún lado había una presentación de @ocombe de alguna conferencia de angular (creo que AngularConnect) donde hablaba de i18n e Ivy, y ahí lo describía muy bien, por qué es tan complicado esto. Puedo tratar de encontrar el video.

creo que lo encontre https://www.youtube.com/watch?v=miG-ghJhFPc

Para las personas que esperan el tiempo de ejecución i18n con ivy, el plan actual para v9 es tener traducciones que funcionen con ivy, pero solo como un paso de compilación (como lo es ahora con el motor de vista). Esto significa que todavía será 1 compilación/configuración regional por ahora, y no habrá traducciones de código (solo traducciones de plantillas).

Gorrón. Bueno, por lo que vale, ¡gracias por tu arduo trabajo!

@ocombe , ¿seguirá manteniendo el polyfill para las traducciones de código en tiempo de ejecución?

si se rompe, sí, no le agregaré cosas nuevas

Apesta que i18n haya sido un ciudadano de segunda clase durante tanto tiempo... No todo el mundo trabaja en un entorno local nativo en inglés. ):

Bueno, estoy de acuerdo, estoy tratando de encontrar algunas empresas que me patrocinen para poder desarrollar nuevas y potentes soluciones i18n para Angular (tengo un montón de ideas).
Si piensas en personas que estarían interesadas, házmelo saber en Twitter (@ocombe) o por correo electrónico ([email protected]) 🙂

@ocombe También me gustaría agradecerte por tu trabajo. 💚 Es una noticia un poco sorprendente que tengas que dejar el equipo. Como dijiste I had to ... , me guía a preguntarte directamente cuál fue el motivo principal. Odio esas sugerencias indirectas y las conjeturas, por eso te hago una pregunta tan directa.

Era un contratista externo que trabajaba con el equipo de Angular y no un empleado de tiempo completo de Google y, como tal, mi contrato puede finalizar en cualquier momento según las necesidades del equipo.
Están reclutando nuevas personas internamente para ayudar con el proyecto y confío en que encontrarán a las personas adecuadas para ayudar con i18n y otros temas, por lo que no tiene que preocuparse por el futuro de Angular :visage_légèrement_souriant: es solo un contratiempo temporal

@ocombe Gracias por tu explicación.

¿Alguien puede decirme cómo puedo usar i18n (i18n-polyfill) fuera de la clase, como enumeraciones o matrices const o algo así como archivos .model.ts?

Para las constantes, todavía las pongo en una clase. no conozco otra alternativa :/

@ocombe Muchas gracias por todo su arduo trabajo con i18n para Angular con ngx-translate, i18npolyfill y con el equipo de Angular.
Usamos su trabajo diariamente para proporcionar traducciones a nuestros usuarios, como lo requiere cualquier aplicación no trivial.
La mejor de las suertes en lo que haces para seguir adelante.

Para las constantes, todavía las pongo en una clase. no conozco otra alternativa :/

Hmm... si los muevo a la clase, entonces necesito hacer que la variable sea estática para poder usarla. Pero no puedo usar i18n para una variable estática.

clase de exportación Ejemplo {
constructor (privado i18n: I18n) {}
variable estática = i18n('texto'); // No puedo usar i18n aquí porque no es estático de clase Ejemplo
}

Triste noticia... esto "debilita" a Angular... Como dicen los demás, solo queda el gran agradecimiento a @ocombe por el gran trabajo, ¡mucha suerte!

Tengo curiosidad, ¿cuáles son las desventajas de usar ngx-translate? Parece que es capaz de ofrecer exactamente la funcionalidad que la gente busca

Diría que las desventajas son las siguientes:

• aumenta el tamaño del paquete (biblioteca externa + traducciones como archivos externos en lugar de reemplazar el código en el momento de la compilación)
• no es oficial (si muero, la lib se descontinúa y no tiene el mismo nivel de soporte)
• no es compatible con xliff/xmb (pero es compatible con json y otros formatos a través de complementos, y se podría hacer un complemento xliff/xmb para admitirlo)
• podría tener algunos comportamientos defectuosos al cargar o dividir las traducciones de forma diferida (nunca llegué a arreglar eso)
• la sintaxis es más complicada en comparación con la implementación oficial
• rendimiento (la carga inicial de las traducciones puede hacer que el texto desaparezca durante 1 segundo, y más presión de memoria porque tengo que monitorear el contenido en tiempo de ejecución para ver si algo cambió)

Dicho esto, parece ser lo suficientemente bueno para mucha gente 🙂

Es curioso como angular promueve e invierte en accesibilidad pero no incluye idiomas en ese paquete. Realmente se siente que esta es una decisión tomada desde un entorno monolingüe.

Viniendo de un entorno en el que generalmente tenemos que ofrecer 3 o 4 idiomas indistintamente, he estado esperando pacientemente el lanzamiento de esta función desde su anuncio con sus claras ventajas sobre el uso de una biblioteca externa. Con esta noticia, tendré que reconsiderar nuestra estrategia de gestión de traducciones por completo.

@ocombe ¿ No hay posibilidad de que Google no te contrate como contratista? 😉

@DmitryEfimenko Estamos usando ngx-translate actualmente y estamos muy contentos con él.

@ocombe, ¿cuál es la posibilidad de que Google acepte esta característica de un desarrollador/comunidad externo? Creo que estamos esperando demasiado tiempo.

si te lo tomas en serio y quieres dedicar tiempo a trabajar en él, diría que hay muchas posibilidades de que acepten ayuda para trabajar en esta función.

si te lo tomas en serio y quieres dedicar tiempo a trabajar en él, diría que hay muchas posibilidades de que acepten ayuda para trabajar en esta función.

@ocombe @IgorMinar Me gustaría proporcionar trabajo voluntario para Ivy i18n, avíseme si hay alguna posibilidad.

si te lo tomas en serio y quieres dedicar tiempo a trabajar en él, diría que hay muchas posibilidades de que acepten ayuda para trabajar en esta función.

Estoy dispuesto a contribuir, pero desconozco absolutamente el alcance y la complejidad de las tareas. ¿Podemos tomar la lista del mensaje original como nuestras especificaciones/requisitos?

No, esta lista ahora está obsoleta.
Le haré saber al equipo que ustedes dos están interesados ​​para que podamos ver cómo organizar esto.

@ocombe Creo que somos más de 2.

Lo que necesitamos de los equipos de Angular son

• una lista de requisitos/alguna especificación
• estimación aproximada de la complejidad
• 1-2 mentores para la comunicación

con esa comunidad podría organizar el desarrollo y dividir tareas

Hay algo de lo que tengo conocimiento en https://hackmd.io/UfFN_wyVT-Ob1p70nA3N_Q?view

@fetis Puede que no sea una buena idea dividir demasiado el trabajo, la comunicación y el intercambio de contexto también cuestan mucho, especialmente para algunos trabajos centrales que tienen una alta probabilidad de conflictos.

Todavía me sorprende que XLIFF aparezca como un profesional (o más bien, la falta de él para ngx-translate es una estafa). Google Translate y otros servicios de Google parecen estar usando archivos ARB, que es una representación JSON de cadenas de traducción. Por ejemplo, creamos nuestras aplicaciones móviles con Flutter/Dart, donde INTL se implementa con archivos ARB. Sería bueno si el equipo de Angular, al analizar esto, lo tuviera en cuenta para una mejor interoperabilidad con otros elementos en el ecosistema de Google.

Puede que no sea una buena idea dividir demasiado el trabajo, la comunicación y el intercambio de contexto también cuestan mucho, especialmente para algunos trabajos centrales que tienen una alta probabilidad de conflictos.

Estoy de acuerdo, pero no creo que todo esto pueda ser entregado por una sola persona en un tiempo razonable. El alcance es demasiado grande.

Puede que no sea una buena idea dividir demasiado el trabajo, la comunicación y el intercambio de contexto también cuestan mucho, especialmente para algunos trabajos centrales que tienen una alta probabilidad de conflictos.

Estoy de acuerdo, pero no creo que todo esto pueda ser entregado por una sola persona en un tiempo razonable. El alcance es demasiado grande.

@fetis Puedo trabajar contigo. Realmente queremos usar angular i18n en nuestros proyectos, pero es muy limitado.

Le haré saber al equipo que ustedes dos están interesados ​​para que podamos ver cómo organizar esto.

@ocombe ¿Algún comentario del equipo de Angular?

Les hice saber y parecían interesados, pero deben idear un plan concreto para todo eso antes de que puedan aceptar ayuda externa (de lo contrario, probablemente no trabajará en lo que se necesita).
@petebacondarwin tomará el relevo a partir de ahora

Hola @ocombe , estaba revisando los comentarios y entendí más o menos que todavía no existe una disposición para crear ID dinámicos para la etiqueta i18n mientras los usamos en * ngFor. ¿Hay alguna otra opción o solución? O tengo que ir solo con ngx-translate.

@swapnilvaidankar No creo que haya una solución, no

@swapnilvaidankar : ¿puede explicar qué quiere decir con esto?

crear ID dinámicos para la etiqueta i18n mientras los usamos en *ngFor

Como sabemos, para traducir el texto estático a cualquier otro idioma, debemos usar el atributo i18n en la etiqueta del elemento HTML como se muestra a continuación:

<h1 i18n = "Card Header | Title for the under construction card@@constructionheader">Under Construction</h1>

que genera el fragmento de archivo xlf como se muestra a continuación y podemos establecer el objetivo para cualquier idioma. Aquí lo he traducido al francés de la siguiente manera,

  <trans-unit id="constructionheader" datatype="html">
    <source>Under Construction</source>
    <target>En construction</target>
    <context-group purpose="location">
      <context context-type="sourcefile">src/app/app.component.html</context>
      <context context-type="linenumber">3</context>
    </context-group>
    <note priority="1" from="description"> Title for the under construction card</note>
    <note priority="1" from="meaning">Card Header </note>
  </trans-unit>

Pero en el caso de la lista desplegable, parece difícil usar el atributo i18n.
Por ejemplo, si quiero mostrar la lista de productos como tarjetas de presentación, volantes y folletos en una lista desplegable o una lista simple, ¿cómo puedo generar la identificación dinámica para eletiqueta, por lo tanto, puedo traducir los nombres de los productos al francés o a cualquier otro idioma.

He intentado de esta manera,

• 
  {{ producto }}
  

que genera el fragmento de archivo xlf como se muestra a continuación y no estoy seguro de cómo usarlo para traducir el nombre del producto a otros idiomas usandoetiqueta

  <trans-unit id="product" datatype="html">
    <source><x id="INTERPOLATION" equiv-text="{{ product }}"/></source>
    <context-group purpose="location">
      <context context-type="sourcefile">src/app/product/product.component.html</context>
      <context context-type="linenumber">6</context>
    </context-group>
    <note priority="1" from="description"> product name from List</note>
    <note priority="1" from="meaning">product name </note>
  </trans-unit>

El problema aquí, si puede ver la identificación enla etiqueta es 'producto' solamente. Sin embargo, esperaba que los identificadores se generaran dinámicamente según la lista de productos que estarán disponibles en la lista desplegable.

No estoy seguro de cómo lograr esto cuando se trata de contenido dinámico o una lista de contenido.

Perdón por la extensa explicación.
Espero que hayas entendido el problema aquí.

Gracias,
permuta

¿Puedes abrir un problema para eso, por favor? Realmente no es el tema aquí y si alguien más está buscando lo mismo, será más fácil encontrarlo.

Los atributos @swapnilvaidankar i18n están destinados a la traducción de texto estático, no a contenido dinámico. En su ejemplo, los "productos" provienen de su código fuente (se definen en su archivo ts) y necesita usar ngx-translate (o tiene nombres de productos traducidos directamente en el archivo ts), o provienen de una solicitud Http luego, su backend debe proporcionar los nombres de los productos traducidos.

No creo que necesitemos un nuevo número para eso. Es solo una solicitud de traducciones en tiempo de ejecución en archivos TS que ya se solicitó muchas veces.

@swapnilvaidankar si la cantidad de opciones es limitada y ya lo sabe, puede crear un componente con ngSwitch simple que represente el texto. Usamos esta solución, funciona a las mil maravillas.

@fetis : el problema es que es muy fácil que estos problemas generales se desvíen a discusiones sobre cosas específicas. La creación de un nuevo problema proporciona un nuevo hilo para continuar esa discusión sin distraer esta.

@fetis Sí, este problema lo he visto muchas veces en muchos lugares, sin embargo, no encontré ninguna solución adecuada. Encontré ngSwitch también, pero no una solución adecuada en mi caso. Sin embargo, gracias por la solución.

@ocombe Creo que necesito publicar esto como un problema en otro lugar para discutir lo mismo en lugar de aquí. 👍

Gracias a todos por las respuestas.

@petebacondarwin @swapnilvaidankar aquí está el problema https://github.com/angular/angular/issues/11405 que estás buscando
desde 2.0.0-rc.6 (!) por cierto

Hola @ocombe , ¿este problema sigue actualizado? Parece que Ivy será el predeterminado en Angular 9, así que me pregunto cuál es el estado de i18n. ¿Podría estimar cuándo podría estar listo para la producción? ¿Con Angular 9, 10, 11? Si no es con Angular 9, ¿se enviará Angular 9 (e Ivy) sin i18n o usará el antiguo i18n?

Puede encontrar más información sobre el estado actual en este número (https://github.com/angular/angular/issues/11405). Comentarios dignos de leer en este número sobre el estado actual:

• https://github.com/angular/angular/issues/16477#issuecomment-512290696
• https://github.com/angular/angular/issues/16477#issuecomment-506378004
• https://github.com/angular/angular/issues/16477#issuecomment-512548506

También esto vale la pena echarle un vistazo.

Aunque estamos cambiando el interruptor en v9 para que el valor predeterminado sea usar ivy, esperamos que haya una serie de escenarios que no funcionen completamente, y que esos proyectos se queden con view-engine por ahora.
Estamos trabajando para poner i18n en funcionamiento para la versión v9.0.0, pero será difícil.

¿Cuál es el estado actual de "Runtime i18n (un paquete para todas las configuraciones regionales)"?

@Ivajkin : lamento que este problema no se mantenga actualizado.

"Runtime i18n" es una función solicitada con frecuencia, pero puede significar diferentes cosas para diferentes personas.
En el nuevo enfoque i18n $localize , será posible realizar la traducción real en tiempo de ejecución.

El tiempo de ejecución en realidad puede ser bastante complicado si no solo está traduciendo todos los mensajes posibles antes de que se inicie la aplicación Angular. Si está haciendo esto, entonces el nuevo enfoque para compilar la traducción en tiempo bien podría ser lo que necesita.

En el nuevo i18n, la traducción ocurre al final de su canal de compilación, no en el compilador Angular, lo que significa que debería poder proporcionar mensajes sin traducir en bibliotecas, etc. y solo hacer la traducción cuando compila la aplicación final.

Todo esto está en proceso para v9.0.0.

Consulte https://github.com/angular/angular/tree/master/packages/localize para ver dónde estamos.

@petebacondarwin ¿Le importaría elaborar un poco sobre la nueva traducción de tiempo de compilación? ¿Nos permitirá esto construir un solo paquete (con AOT) que funcione para todas las localidades?

En el nuevo enfoque, en lugar de hacer la traducción dentro del compilador Angular, simplemente "etiquetamos" los mensajes que deben traducirse a través de un controlador de etiquetas de cadena con plantilla $localize global. Estas cadenas etiquetadas sobreviven a todo tipo de agrupación y minificación, de modo que al final de la canalización de compilación todavía están allí y se pueden detectar. ¡Estos archivos podrían ser el paquete de su biblioteca que envía a otro equipo para incluir en su aplicación!

Ahora tenemos un par de opciones:

a) ejecutar una herramienta que identifique estáticamente estos mensajes etiquetados y los reemplace con traducciones. Esto elimina efectivamente las referencias $localize del JavaScript y lo deja con un paquete de código mínimo para su distribución. Esta herramienta de "compilar tiempo en línea" puede tomar varias traducciones y generar una copia de su paquete para cada idioma que esté traduciendo. Dado que se puede ejecutar al final de su proceso de compilación, evita tener que ejecutar otros aspectos de su compilación para cada idioma que admita.

b) permitir que las etiquetas $localize terminen en el código que se ejecuta en el navegador y usar una implementación de $localize para traducir los mensajes en tiempo de ejecución. La desventaja de este enfoque es que la carga útil del navegador es mayor, ya que debe contener las llamadas $localize pero también la implementación de la traducción $localize . También debe enviar las propias traducciones al navegador. Un beneficio de este enfoque podría ser admitir la carga diferida de traducciones en tiempo de ejecución. Pero es discutible que hacer la traducción en el servidor http (o el servidor de compilación) hace que la experiencia de tiempo de ejecución sea más eficiente.

Opción de tiempo de ejecución b) por favor. Podríamos cargar traducciones como archivos JSON y cambiar de idioma en tiempo de ejecución como lo hacemos actualmente con ngx-translate .

Gracias por la explicación. Entiendo que el enfoque a) es más "angular", pero la gran ventaja del enfoque b) (y la carga diferida en general) también es la capacidad de definir/cambiar dinámicamente las traducciones de los usuarios (las traducciones modificadas para las aplicaciones se pueden usar de inmediato) . Si lo entiendo correctamente, cualquier pequeño cambio en la traducción del enfoque a) significaría una nueva reconstrucción.

Esta es la misma ventaja que cambiar de páginas generadas estáticamente con componentes angulares predefinidos a plantillas generadas por el usuario que contienen los componentes angulares definidos por el programador según lo desee el usuario (la plantilla definida de esta manera también se cargaría desde la base de datos... )

Es posible que también haya pensado en la posibilidad de que, de forma predeterminada, se utilice el enfoque a) al cargar. Si surgiera una solicitud de traducción en tiempo de ejecución (por ejemplo, el backend comenzará a enviar traducciones más nuevas), los bloques marcados (que hasta ahora contenían texto estático) comenzarían a rastrearse y reemplazarse dinámicamente, como en el enfoque b). Entonces b) solo se activará si es necesario y todas las partes traducibles se prepararán de acuerdo con el procedimiento a). Entiendo que tal enfoque sería más oneroso que el enfoque b) en sí mismo y ciertamente no es directamente factible de esta manera, pero estaría más cerca de las necesidades reales de los usuarios.

Para las opciones que enumeró, estoy dispuesto a sacrificar alrededor del 25% del rendimiento de la aplicación en ciertos casos para lograr una funcionalidad tan dinámica (por supuesto, no usaría este enfoque dinámico en todas partes). Entonces, si la plantilla AOT localizada se procesó en 0,4 segundos, en el caso de una plantilla dinámica si se generó en 0,5 segundos, aún la consideraría aceptable en aplicaciones donde necesito respuestas inmediatas al cambio de traducción.

@demisx , ambos enfoques estarán disponibles con v9, pero solo la opción a) será totalmente compatible al principio (para retrocompatibilidad), es posible que se desarrollen cosas nuevas para la opción b) antes de que el equipo de Angular la respalde por completo.
Mi biblioteca Locl proporcionará algunos ayudantes para la opción b) cuando se lance v9 para que cualquiera pueda usarla, hasta que el equipo de Angular cierre esa brecha

Tenga en cuenta que dicha traducción en tiempo de ejecución no sería "reactiva" en el sentido de que una vez que se haya renderizado un componente, no sería posible cambiar su texto dinámicamente, incluso si se cargara una nueva traducción.

Los mensajes traducidos son estáticos con respecto a las cadenas etiquetadas $localize . Por lo tanto, el componente debería volver a renderizarse. Y dependiendo del almacenamiento en caché de las plantillas en IVY, es posible que una nueva representación no sea suficiente.

Esta es una de las razones por las que la traducción en tiempo de ejecución es difícil de implementar, ya que su comportamiento no sería necesariamente intuitivo.

Con respecto al enfoque híbrido de comenzar con una traducción estática en la compilación y luego agregar la traducción en tiempo de ejecución más adelante. Esto podría ser factible si el tiempo de compilación insertado no eliminara las etiquetas $localize sino que simplemente actualizara las partes literales de la cadena con plantilla. Sin embargo, esto daría como resultado el costo del tiempo de compilación más el costo adicional del tamaño del paquete.

Ejecutar ng xi18n en Angular 9 RC1 devuelve "Lo sentimos, pero i18n aún no está implementado en Ivy", pero el registro de cambios indica que hay _algo_ de compatibilidad con i18n implementada ahora. Supongo que los archivos de traducción deben actualizarse manualmente por ahora.

@neil-119 Actualmente, la extracción no es compatible con el modo ivy. Aún necesita deshabilitar ivy para ejecutar la extracción. Pero luego puede volver a habilitarlo para consumir los archivos de traducción extraídos.

Espero que esté planeado incluir la extracción en la versión final v9.

@ neil-119 Angular CLI debería usar automáticamente VE para la extracción. No deberías necesitar hacer nada para que eso funcione. También lo probamos, así que me sorprende que esté roto. ¿Puedes abrir un problema con una reproducción, por favor?

Actualmente, la extracción no es compatible con el modo ivy.

o no, es un espectáculo tapón. Actualmente, tenemos un proceso automatizado con extracción de cadenas. ¿Cómo podemos migrar a Ivy, si no podemos extraer las traducciones automáticamente?
¿Manipular sconfig.json every time ? Esto no suena bien para mí.

@fetis - Estaba equivocado. Si está utilizando CLI, llamar a ng xi18n debería funcionar como se espera, incluso cuando ivy está habilitado.

@petebacondarwin gracias. Voy a probar a Ivy en nuestros proyectos actuales, así que espero confirmarlo pronto.

Hola, intenté usar en mi componente (angular 9.0.0-rc.1)

$localize `some string to localize`;

encontrado como doc en el código fuente de @angular/localize/init.

Cuando trato de compilar como de costumbre para mi idioma, aparece este error
No translation found for "4145296873012977836" ("some string to localize").

¿Cómo puedo proporcionar una traducción para esa cadena?
Lo que espero es que ng xi18n genere el archivo .xlf con también este texto del código del componente. ¿Es correcto o me estoy perdiendo algo?

Hola , @Ks89 : la extracción de mensajes del código de la aplicación (en lugar de plantillas) no es compatible con v9.
Pero puedes solucionarlo si eres astuto. El 4145296873012977836 es la identificación del mensaje, por lo que si proporciona una traducción en su archivo de traducción con esta identificación, se usará al traducir.

@petebacondarwin ¿ cuándo se agregará esta característica a Angular?
Creo que es muy importante hacer que las traducciones en tiempo de ejecución en el componente sean realmente útiles.

Cuando envío mi archivo .xlf a un traductor, espero agregar todas las cadenas rápidamente y luego aplicar el resultado a la aplicación muy fácilmente.

gracias por la respuesta

Lo esperaría en 9.1

Si tenemos una manera de forzar la renderización de toda la aplicación sin importar ChangeDetectionStrategy para cada componente, entonces es muy fácil resolver esos problemas dinámicos.

@petebacondarwin Angular 9 ahora se lanza con la nueva función de etiqueta $localize, pero sin extracción de los mensajes. Dijiste antes que podíamos esperar esto en Angular 9.1. ¿Este pronóstico sigue siendo válido y podemos esperar que la API de $localize sea estable?

Puede extraer traducciones de plantillas.
Si también desea usar $localize en su código, debe consultar Locl: https://github.com/loclapp/locl/
@locl/cli te permitirá extraer código y plantillas

@vekunz : el pronóstico sigue siendo válido. Además, como señala @ocombe , el mecanismo de extracción de traducción de CLI actual funciona bien para cualquier traducción que esté dentro de una plantilla Angular (es decir, cosas marcadas con las etiquetas i18n ). Lo único que no puede extraer con las herramientas principales en este momento son las llamadas a $localize dentro de su propio código (por ejemplo, en un servicio o componente).

La llamada $localize en sí misma es una API estable.

Las herramientas que realizan las traducciones y la extracción (específicamente en tiempo de compilación) aún no son públicas. Pero esto no es una preocupación a menos que esté planeando construir su propia herramienta a su alrededor (¡como lo está haciendo @ocombe en Locl!).

Gracias @petebacondarwin , con esto, pudimos duplicar los textos del código en una plantilla de componente "oculta" para su extracción. Entonces, la extracción y la traducción deberían funcionar, ¿no?

@ocombe Con el pronóstico de que la extracción funciona con Angular 9.1, nuestro gerente no pagaría por su solución. Especialmente porque no necesitamos cambiar de idioma en vivo y rutas traducidas.

podríamos duplicar los textos del código en una plantilla de componente "oculta" para su extracción

Sí, de hecho, esta solución funcionaría por ahora.

Estoy confundido: ¿La traducción en tiempo de ejecución también será posible en 9.1? ¿O simplemente la extracción fuera de las plantillas? ¿O ninguno de estos?

Para mí, las traducciones en tiempo de ejecución serían una característica excelente. Creo que implementar varios paquetes y obligar al usuario a recargar toda la página no es una buena usabilidad.

@JustDoItSascha
Creé una demostración simple, que demuestra la traducción en tiempo de ejecución.
https://stackblitz.com/edit/ivy-vjqzd9?file=src%2Fapp%2Fapp.component.ts

¡Hola! Estoy tratando de llamar a loadTranslations en main.ts porque las cadenas se traducen mientras JavaScript analiza las importaciones, pero eso no es suficiente.

main.ts importa AppModule que importa AppComponent (donde estoy usando $localize ).

Para que funcione estoy haciendo:

loadTranslations(......);
import('./app/app.module').then(m => platformBrowserDynamic(). bootstrapModule(m.AppModule);

Ahora esto funciona, pero hace que el paquete "complier.js" de Angular se incluya en el paquete del proveedor.

¿Alguna forma de evitar eso? Gracias

Actualmente, se debe llamar a loadTranslations antes de que se inicie la aplicación, por lo que se puede hacer en polyfills.ts . Y si desea cargar otro conjunto de traducciones, debe volver a cargar la página. Si quieres entender un poco más por qué, escribí https://blog.ninja-squad.com/2019/12/10/angular-localize/ para explicarlo.

Actualmente, se debe llamar a loadTranslations antes de que se inicie la aplicación, por lo que se puede hacer en polyfills.ts .

Es incluso peor que eso, debe llamarse antes de importar cualquier archivo de módulo, por eso funciona si lo coloca en polyfills.ts (que se ejecuta antes que el archivo de la aplicación principal), pero si desea usarlo en su archivo "principal", entonces necesita usar un import(...) dinámico para el módulo

@vekunz es una buena razón para no usar mi lib por ahora 😊 Dicho esto, Locl no se trata solo de extracción, tengo la intención de agregar muchas otras herramientas para simplificar i18n

¿Hay alguna intención de implementar el tiempo de ejecución i18n en Angular alguna vez? Hemos estado esperando la función durante casi tres años y ahora Ivy está aquí y todavía está a medio cocinar.

¿Hay alguna intención de implementar el tiempo de ejecución i18n en Angular alguna vez? Hemos estado esperando la función durante casi tres años y ahora Ivy está aquí y todavía está a medio cocinar.

Tengo entendido que Ivy, en muchos sentidos, es un facilitador de lo que vendrá. No sorprende que la aguja i18n se haya movido increíblemente con el lanzamiento de Ivy, pero debería desencadenar el potencial de grandes cambios en el futuro. Esa ha sido mi lectura al respecto, y mi esperanza, de todos modos.

@Karasuni : creo que debemos aclarar qué significa realmente la traducción en tiempo de ejecución para el marco Angular central porque existe bastante confusión al respecto.

Los cambios que hicimos para v9 involucran la traducción basada $localize . El objetivo principal de esto era desacoplar la traducción del compilador Angular, de modo que permitiera una serie de mejoras agradables:

El primero de ellos, que está disponible de inmediato para todos los usuarios de v9, es acelerar la generación de aplicaciones traducidas. Anteriormente, toda la canalización de compilación tenía que ejecutarse para cada idioma al que deseaba traducir su aplicación. Ahora la compilación principal de su aplicación solo tiene que ejecutarse una y el proceso de traducción final, que es significativamente más corto, se ejecuta para cada idioma en el resultado de la compilación. Para respaldar esto, existe el nuevo paquete @angular/localize , cambios dentro del compilador de Angular y una gran cantidad de trabajo dentro de la CLI de Angular para que esto sea lo más fluido y transparente posible.

En segundo lugar, dado que las etiquetas $localize se pueden dejar en el código distribuido, ahora también es posible realizar la traducción en el navegador (en tiempo de ejecución, en lugar de en tiempo de compilación). Esto es lo que queremos decir en el marco Angular central como traducción en tiempo de ejecución. Pero tenga en cuenta que el resultado final de esto es efectivamente el mismo que la traducción en tiempo de compilación. La traducción ocurre solo una vez; si desea cambiar el idioma en tiempo de ejecución, debe reiniciar toda la aplicación (por ejemplo, mediante una recarga). Esto tiene la ventaja de permitir que el proyecto implemente un solo distribuible con numerosos archivos de traducción, lo que es útil en una pequeña cantidad de casos de uso en los que no desea generar todas las diferentes traducciones por adelantado. Hay algunos problemas complicados relacionados con la carga de las traducciones lo suficientemente temprano, como lo señalaron @ocombe y otros aquí. Podría considerar https://www.locl.app/ para obtener más ayuda para hacer esto.

Tenga en cuenta que esta traducción de "tiempo de ejecución" también se puede usar en rutas con carga diferida, por lo que podría ser factible tener diferentes rutas en diferentes idiomas dependiendo de cómo configure las cosas.

Dado que no existe un enfoque único para esta carga de traducciones que funcione para todos los escenarios, aún no hemos incluido esto en la CLI ni hemos proporcionado API públicas estables para respaldarlo. Una vez que comprendamos mejor los casos de uso, podremos agregar más soporte para esto. Mientras tanto, cosas como Locl pueden ayudar si no quieres aventurarte a resolverlo por ti mismo.

Finalmente, tenga en cuenta que el marco Angular central no admite específicamente (por diseño) el cambio dinámico de cadenas traducidas en tiempo de ejecución. Conectar las cadenas traducidas al sistema de detección de cambios de Angular ejercería demasiada presión sobre la mayoría de las aplicaciones y arruinaría el rendimiento. De mis interacciones con la comunidad, apenas he visto escenarios del mundo real en los que esto sea realmente necesario además de reiniciar la aplicación en el cambio de idioma. Si este es un requisito para su aplicación, entonces podría lograrlo utilizando una canalización personalizada en sus cadenas en plantillas que extraen traducciones, y tal vez incluso llame a $localize sobre la marcha para traducir, pero no parece esto sería muy eficaz. De lo contrario, podría considerar un enfoque más dinámico como https://netbasal.gitbook.io/transloco/.

Los principales cambios que vendrán en la próxima versión secundaria de Angular serán la extracción de traducción mejorada, que podrá identificar y extraer cadenas localizadas del código TS; actualmente, la extracción CLI solo maneja cadenas localizadas en plantillas.

Los cambios para mejorar la traducción del tiempo de ejecución, como se describe anteriormente, no aparecerán hasta después de la versión 9.1 como mínimo.

Finalmente, tenga en cuenta que el marco Angular central no admite específicamente (por diseño) el cambio dinámico de cadenas traducidas en tiempo de ejecución. Conectar las cadenas traducidas al sistema de detección de cambios de Angular ejercería demasiada presión sobre la mayoría de las aplicaciones y arruinaría el rendimiento. De mis interacciones con la comunidad, apenas he visto escenarios del mundo real en los que esto sea realmente necesario además de reiniciar la aplicación en el cambio de idioma.

Puede que me equivoque, pero solo en este hilo muchas personas expresaron interés en la capacidad de cambiar el idioma en vivo, en tiempo de ejecución, sin tener que reconstruir o recargar la aplicación. ¿O todos aquí tienen una definición diferente de runtime translation ?

No quiero volver a cargar una aplicación solo para cambiar de idioma. Por ejemplo, cuando un usuario está en una página con un formulario, una recarga de página completa para un cambio en la traducción resultará molesto para el usuario.

Solo para aclarar. Lo que quise decir es que muchas personas se me han acercado para decirme que necesitan absolutamente un cambio de idioma en vivo en su aplicación. Pero cuando profundizas en las razones, resulta que no es así. No digo que no haya escenarios que lo requieran, pero en mi experiencia del último año me he encontrado con muy pocos.

Pregunta: ¿por qué un usuario necesitaría cambiar de idioma cuando vaya a un formulario en particular en su aplicación?

No creo que el cambio en vivo sea necesario también. ¿Con qué frecuencia cambia el idioma de un sitio web? Por lo general, una vez, como máximo. Y por esta vez, una recarga de página no es tan crítica. Como dijo @petebacondarwin , casi todos los escenarios para el cambio en vivo no son escenarios relevantes del mundo real, sino solo "agradables de tener".

¿O todos aquí tienen una definición diferente de traducción en tiempo de ejecución?

Absolutamente necesito traducciones en tiempo de ejecución. Nuestros clientes necesitan poder editar y actualizar las traducciones en el campo, no solo en el servidor de compilación. Entonces, tiempo de ejecución, a diferencia del tiempo de compilación.

El cambio real de idiomas después de cargar la página es agradable.

Solo para aclarar. Lo que quise decir es que muchas personas se me han acercado para decirme que necesitan absolutamente un cambio de idioma en vivo en su aplicación. Pero cuando profundizas en las razones, resulta que no es así. No digo que no haya escenarios que lo requieran, pero en mi experiencia del último año me he encontrado con muy pocos.

Pregunta: ¿por qué un usuario necesitaría cambiar de idioma cuando vaya a un formulario en particular en su aplicación?

Puede que tengas razón en que no es un requisito sólido. Podría intentar implementar traducciones en la carga, pero transformará por completo la experiencia del usuario de las aplicaciones que actualmente pueden cambiar de idioma de forma dinámica, sin recargar ni cambiar de posición en la página, con una biblioteca externa. Las traducciones han sido un tema candente durante mucho tiempo.

Tengo una pregunta importante: ¿Se pueden cargar los archivos de traducción de forma asíncrona? Todas mis traducciones se almacenan en una base de datos, ya que es importante poder actualizarlas sin una reconstrucción.

sí, se pueden cargar de forma asíncrona, pero debe retrasar el inicio de su aplicación hasta que se hayan cargado

Solo para aclarar. Lo que quise decir es que muchas personas se me han acercado para decirme que necesitan absolutamente un cambio de idioma en vivo en su aplicación. Pero cuando profundizas en las razones, resulta que no es así. No digo que no haya escenarios que lo requieran, pero en mi experiencia del último año me he encontrado con muy pocos.
Pregunta: ¿por qué un usuario necesitaría cambiar de idioma cuando vaya a un formulario en particular en su aplicación?

Puede que tengas razón en que no es un requisito sólido. Podría intentar implementar traducciones en la carga, pero transformará por completo la experiencia del usuario de las aplicaciones que actualmente pueden cambiar de idioma de forma dinámica, sin recargar ni cambiar de posición en la página, con una biblioteca externa. Las traducciones han sido un tema candente durante mucho tiempo.

Técnicamente, puede volver a cargar toda la aplicación y aún así mantener al usuario donde estaba.
"Solo" necesita tener una aplicación controlada por estado (con ngxs, ngrx o cualquier otra biblioteca de administración de estado) que se almacene en algún lugar y se recupere al inicio.

El único truco sería mantener la posición de desplazamiento, pero eso también es factible.

@petebacondarwin tengo que decir que estoy de acuerdo contigo. No conozco usuarios finales reales (excepto los probadores en la fase de desarrollo) que cambian una aplicación de forma permanente entre idiomas cuando la usan. Claro, probablemente lo hagan al principio si lo abren en otro diferente de alguna manera, pero luego, es un caso raro.

¿O todos aquí tienen una definición diferente de traducción en tiempo de ejecución?

Absolutamente necesito traducciones en tiempo de ejecución. Nuestros clientes necesitan poder editar y actualizar las traducciones en el campo, no solo en el servidor de compilación. Entonces, tiempo de ejecución, a diferencia del tiempo de compilación.

El cambio real de idiomas después de cargar la página es agradable.

No estoy seguro de lo que hacen sus clientes, pero la "edición de traducciones en vivo en el sitio web de producción" no parece un escenario común.

No veo que cambiar el idioma en vivo (_sin recargar la página_) sea un factor decisivo.
Cambiar un idioma para un usuario ocurre solo una vez;

Piénsalo, ¿cuántas veces has cambiado el idioma de tu teléfono? probablemente una vez o acabas de rodar con el idioma predeterminado.

Observar los cambios de idioma para realizar cambios en vivo sin recargar la página trae una gran penalización de rendimiento para algo que apenas se usa durante la vida de un usuario.

En última instancia, todo se reduce a 3 cosas para mí;

1. Extraiga traducciones de plantillas y archivos TS.
   
   
   
   • Actualizar recurso de idioma de origen.
   
   
   • Actualice la traducción también (_si tengo varios idiomas, fr, en, de... Quiero que todos se actualicen con nuevas claves de traducción y las eliminadas._)
   
   
2. Una compilación para todas las traducciones (_Tener 1 compilación para cada traducción también está bien, siempre que no multiplique el tiempo de compilación_)
3. Obtener los idiomas disponibles y cambiar el idioma con la recarga.

@Karasuni
Puede obtener traducciones asíncronas y solo luego cargar la aplicación angular.
Vea mi comentario anterior sobre cómo cargar app.module de forma asíncrona usando import(...) .

Personalmente, uso Wikipedia para averiguar cuál es el título de una película que sé que se "tradujo" a otro idioma.

en la actualidad, ser bilingüe o trilingüe es más que común (aparte de dentro de los EE. UU., no hay mala intención).

el usuario puede querer cambiar de idioma en vivo, es completamente plausible. el ejemplo de Wikipedia es un resultado positivo de haber habilitado esto, no veo por qué deberíamos sofocar otros usos potenciales antes de que vivan para ver la luz del día bajo el pretexto del rendimiento.

incluso ngx-translate de ocombe, que tiene que ser el ejemplo equivalente para ustedes de "traducciones de bajo rendimiento", funcionó lo suficientemente rápido para el usuario cotidiano.

Yo personalmente soy trilingüe y no me puedo conformar con usar un idioma: todos los idiomas me parecen hermosos

con todo lo dicho no puedo estar de acuerdo con esto:

Piénsalo, ¿cuántas veces has cambiado el idioma de tu teléfono? probablemente una vez o acabas de rodar con el idioma predeterminado.

Wikipedia es el peor ejemplo de esto porque los diferentes idiomas de un artículo son en realidad artículos independientes. Normalmente no necesita diferentes idiomas del mismo sitio exacto. Aunque trabajes cuatrilingüe.
Y si realmente necesita un cambio en vivo, puede usar la solución alternativa con la canalización de traducción personalizada, que mencionó @petebacondarwin o la nueva herramienta de @ocombe.

OK, entonces no creo que este sea realmente el mejor lugar para tener esta discusión. Me preocupa que (si bien todo ha sido muy razonable hasta ahora) podamos caer en una discusión negativa. Me temo que, en el futuro previsible, el marco Angular no proporcionará una solución de cambio de idioma en vivo lista para usar.

Siento que el valor de este problema ha seguido su curso. He movido los problemas abiertos y los PR que están vinculados en la descripción de este problema a https://github.com/angular/angular/milestone/101 y voy a cerrar y bloquear este PR.

Si tiene nuevos problemas de solicitudes de funciones, abra un nuevo problema y etiquéteme en él.