J'aimerais voir la possibilité de faire des liaisons dynamiques en mode aot. Il existe deux cas d'utilisation en particulier pour justifier pourquoi cela devrait être ajouté à la feuille de route.

Le premier est le cas d'utilisation de base où vous ne voulez pas d'applications distinctes pour chaque langue. Cela nécessite une sorte de logique de redirection en dehors de l'application et ne permet pas le changement dynamique de la langue sans un rechargement complet du site.

Le second est le cas où vous intégrez l'application dans un mobile à l'aide de Cordova. Autant que je sache, votre choix est de jit, ralentissant ainsi le site, créant une application distincte pour chaque langue ou incluant chaque langue dans l'application (ce qui, bien sûr, la gonfle). Aucune de ces options n'est bonne. Il semble que Ionic n'utilise pas i18n, et je me demande si c'est la raison.

@ jlutz777 ce sont 2 cas d'utilisation valides, ce sujet a été discuté en interne ces derniers temps et j'ai également plaidé pour cela. Ce n'est pas encore facilement possible compte tenu du fonctionnement d'i18n et d'AoT dans Angular, mais cela pourrait l'être à l'avenir une fois que nous aurons le nouveau processus de compilation pour AoT dans la v5.
Je l'ajouterai à la feuille de route une fois / si nous avons quelque chose d'officiel et de concret à ce sujet.

Je travaille sur l'application Electron + Angular 2 et j'essaie maintenant d'ajouter la prise en charge de la localisation pour plusieurs langues en utilisant la fonctionnalité i18n avec Angular. En fait, l'extraction de la chaîne de modèles et leur conversion dans différents formats de fichiers de langue sont clairement documentées, bien que je ne sois toujours pas en mesure de clarifier et de rechercher :

• Puis-je changer de langue dynamiquement ? ou dois-je créer une application séparément pour différentes langues.
• Puis-je gérer/consolider toutes les chaînes à un seul endroit (sous la forme d'une paire clé/valeur), afin de pouvoir modifier
  la chaîne à un endroit doit être effectuée à plusieurs endroits ?
• Puis-je accéder au fichier localisé à partir de n'importe où autre que le modèle pour obtenir une chaîne de langue spécifique avec
  clé fournie ? (comme je l'ai demandé plus haut).

Les points 2 et 3 seront résolus avec la fonctionnalité "Utiliser les chaînes de traduction en dehors d'un modèle - #11405".
Pour le point 1 voir la réponse que j'ai donnée à @jlutz777 ci-dessus. Pour l'instant, vous devez toujours créer l'application dans plusieurs langues ou utiliser JIT qui peut charger dynamiquement les traductions au démarrage (ce n'est pas la commutation au moment de l'exécution, mais c'est toujours mieux que de devoir la regrouper x fois).

le langage d'interface utilisateur utilisé dans une application ne doit pas nécessiter la création de plusieurs versions de la même application. cela ne devrait en aucun cas être un problème de "compilateur". si c'est le cas, le compilateur est défectueux. les problèmes devraient consister à concevoir l'application de telle sorte que le texte puisse être chargé à partir d'un fichier de données au moment de l'exécution. cela devrait être fait avec un module / bibliothèque qui peut être chargé et utilisé comme n'importe quel autre. n'en faites pas du tout une fonction de compilateur.

@figuerres c'est quelque chose qui sera changé dans le futur, pas encore de promesses mais nous sommes conscients de ce problème et nous étudions les solutions possibles, l'utilisation d'un fichier externe en fait partie

Salut @ocombe - Il semble que nous allons probablement utiliser i18n dans Angular pour notre application. Selon vous, y a-t-il des fonctionnalités dans les documents qui pourraient devenir obsolètes ou subir des modifications importantes dans les mois à venir ? Toute information serait grandement appréciée. Et merci encore pour le DVD !

Salut @rjsteinert ! Content de le savoir!
Il n'y a qu'un seul changement de rupture prévu pour l'instant, c'est la génération automatique d'identifiants. La méthode changera et les ID ne correspondront plus, mais il y aura un outil de migration cli pour mettre à jour vos fichiers de traduction (et un paramètre que vous pourrez utiliser pour migrer uniquement lorsque vous serez prêt).

J'ai beaucoup cherché sur ce sujet sur Google aujourd'hui et je me demande s'il pourrait y avoir une solution "simple" comme remplacer les balises i18n par un appel à un service au lieu de la traduction ?

Courant:
<span i18n>Hello world</span> => rendu à <span>Hello world</span>

Mon idée:
<span i18n>Hello world</span> => rendu à <span>{{i18nservice.translate('pass-in-the-generated-message-id')}}</span>

De cette façon, la véritable traduction pourrait être effectuée dynamiquement dans AOT car le service pourrait être rempli à partir d'une API, d'un fichier, etc. et même le changement de paramètres régionaux ne serait pas beaucoup plus que i18nservice.setLocale('de-DE') avec le chargement d'une nouvelle source.
L'extraction de texte avec xi18n-tool fonctionnerait toujours comme avant et nous pourrions tirer parti des identifiants de message générés de toute façon pour les utiliser comme index pour le service de traduction.
L'implémentation actuelle fonctionnerait également parfaitement car ngc pourrait simplement rechercher un indicateur "--use-i18nservice" et autrement compiler comme jusqu'à présent.

Un problème que je peux actuellement identifier est l'injection du i18nservice dans chaque composant car il doit exister dans le contexte des composants pour être appelable, mais cela devrait pouvoir être résolu d'une manière ou d'une autre.

Des pensées à ce sujet?

C'est l'une des choses que nous envisageons oui, il y a toujours le problème de savoir comment traiter les blocs de code à l'intérieur de ces traductions lorsque le compilateur n'est pas disponible au moment de l'exécution (AOT). Cela signifierait que nous ne pouvons pas utiliser de composants/directives/tuyaux angulaires à l'intérieur des traductions...

Oui, pas pensé à ça.
Je développe actuellement un POC/une solution de contournement qui intègre toutes les traductions dans le HTML à l'étape de construction (webpack), en les enveloppant dans des conteneurs ng avec ng-switch.
Pour les attributs i18n, il utilise une directive les définissant sur nativeElement.
Les traductions elles-mêmes sont également "rendues" pour remplacer tous ces espaces réservés <x id=".. "/> .

C'est moche mais ça marche... j'ai hâte que ng le supporte nativement.
Publiera le POC plus tard cette semaine, peut-être qu'il peut être utile pour votre conception ultérieure.

Je suis venu avec une "solution" qui convient à mes besoins jusqu'à ce qu'il y ait une mise en œuvre.
Le pré-chargeur rend maintenant le HTML pour tous les paramètres régionaux avant de passer le relais au compilateur, fonctionne comme un charme jusqu'à présent.

Dépôt : https://github.com/actra-development-oss/ng-i18n-aot-loader
NPM : https://www.npmjs.com/package/@actra-development-oss/ng -i18n-aot-loader

éventuellement un composant peut avoir un attribut qui indique au système/compilateur qu'il a besoin d'un service.
ce service prend ensuite un identifiant et un paramètre régional et renvoie le texte/le balisage localisé.
tout le texte localisé est stocké sur le serveur en tant que ressources que le service peut lire.

si un composant n'a pas l'attribut no locale run-time.
si le composant l'a, il appelle obtenir les données localisées au moment de l'exécution.
le compilateur construit simplement les fichiers de données et connecte le service.

cela me semble être un bon moyen de gérer le besoin le plus courant pour la plupart des applications et de ne pas obliger les sites à créer et à gérer plusieurs copies de la même application.

J'ai eu cette idée aussi.
Le problème est que les traductions peuvent contenir des liaisons et ouvriraient ainsi le système pour l'injection de code lors du chargement de fichiers de traduction à partir de ressources externes.
De plus, un compilateur serait nécessaire pour résoudre ces liaisons dynamiquement en fonction de la traduction.

À mon humble avis, une solution valable pourrait être la façon dont j'ai implémenté en tant que POC (voir le commentaire ci-dessus) les traductions en ligne au moment de la compilation, juste d'une manière plus élégante et intégrée.
Les deux problèmes mentionnés ci-dessus seraient éliminés, le seul inconvénient que je peux imaginer est peut-être la taille du paquet, il deviendrait "plain bundle" + (traduit html-size * locales).
Cela pourrait être réduit en n'utilisant que ng-switch le html i18n -tagged au lieu de l'ensemble du document, mais il y a toujours un problème pour les balises i18n-* .

bien voici la chose; parfois tu as des limites....

d'un point de vue pratique, il serait peut-être préférable de ne pas avoir cela, vous pouvez avoir un morceau de texte qui peut être donné en plusieurs langues. fin de l'histoire.

vous avez besoin d'un morceau lié aux données? ok mais ce n'est pas à l'intérieur du texte internationalisé, il doit être séparé. vous pouvez toujours utiliser html et css pour styliser et formater le résultat. mais vous ne pouvez pas les intégrer ou les combiner de toutes les manières imaginables.
comme par exemple une balise div ou ap peut avoir un certain nombre de plages une plage est le texte et une autre plage est une date liée la plage de texte est liée au service de paramètres régionaux i18n, la date est liée à un service de date les deux plages sont dans un balise de paragraphe qui les formate.

Restez simple, faites-le fonctionner pour 95% de tous les utilisateurs d'abord, puis déterminez les cas extrêmes.

Je ne vois pas cela comme un cas marginal, c'est comme d'habitude.
Angular est un framework de qualité professionnelle, de sorte que de nombreux utilisateurs d'i18n, sinon tous, auront besoin de liaisons, ou du moins de pluralisation et de sélections, à l'intérieur des textes.

<span i18n>Hello, {user.gender, select, m {Mr.}, f {Ms.}} {{user.name}}</span>
Comment résoudriez-vous cela avec des chaînes séparées?
Réponse simple : vous ne pouvez pas, car vous ne pouvez pas connaître les règles de la langue cible, toutes les langues ne suivent pas le format 'salutation', 'genre', 'nom'.

Séparer ces morceaux permettrait :

• tuer le contexte, le traducteur n'obtiendrait pas le sens de la phrase complète
• fusionner les morceaux dans le bon ordre par CSS n'est pas possible, vous devez spécifier des règles pour chaque traduction, donc soit le gars CSS doit connaître les langues cibles, soit le gars de la traduction doit connaître CSS, non plus est acceptable.

Le noyau i18n fonctionne angulairement comme prévu et est utilisable pour les applications professionnelles, la seule chose qui manque apparemment est la compatibilité AOT, donc je ne comprends pas pourquoi un système puissant et fonctionnel devrait être remplacé par quelque chose qui n'est pas à moitié capable nécessitant plusieurs fois le travail pour le faire.

Nous avons une réunion demain pour trouver une solution à ce problème.

@ocombe heureux d'entendre cela, j'espère que cela mènera à de bonnes choses pour une future version d'Angular, ici au travail, nous aimons vraiment comment cela fonctionne pour nos besoins de développement!

@ocombe , est-il possible de changer de langue sans recharger tout le document ? J'explique :
Je suis sur la page "à propos" mais lorsque je change de langue, je suis redirigé vers la page d'accueil principale de mon application.

En travaillant sur mon application i18n, j'ai également rencontré le "bogue" connu selon lequel les feuilles de style externes de par exemple @angular/material (résidant dans node_modules) ne pouvaient pas être résolues et donc l'outil ng-xi18n -tool a échoué.
J'ai implémenté un "ignorer les fichiers manquants" -HostContext pour l'outil d'extraction, également en tant que POC mais ajouté en tant que PR # 17845 pour le lier au référentiel principal.

@ocombe , comme vous semblez être très actif sur ce sujet, cela vous dérangerait-il de jeter un coup d'œil au PR et de donner votre avis ?

Merci, je vais y jeter un oeil.

Cela fait quelques jours que je cherche un moyen d'implémenter l'internalisation sur l'ensemble du projet, y compris les données dynamiques, mais je n'ai rien trouvé de concret. Pouvez-vous s'il vous plaît me suggérer quelque chose d'autre qui m'aide au moins pour le moment. Merci.

Bonjour @ocombe ! Pouvons-nous avoir une suite concernant le point soulevé par @jlutz777 (sur les liaisons dynamiques, donc ne pas avoir une application par langue) ?

Merci beaucoup pour votre travail !

@vicb travaille dessus en ce moment, ce sera en 5.x (pas 5.0 mais très probablement 5.1)

@ocombe La liste de contrôle doit-elle être mise à jour ? Je peux voir que certains d'entre eux ont déjà été fusionnés dans des versions plus récentes. Et cela reflétera mieux vos efforts acharnés. 😃

oui, bonne idée, je vais le mettre à jour
édit : mis à jour

Runtime i18n (un bundle pour tous les paramètres régionaux avec AOT) - [travailler dessus]

Où est le problème / PR / discussion associé ?

Ce serait cool d'avoir une API pour étendre les formats de date nommés (par exemple ultraLongDate ) afin que le tuyau de date natif en soit conscient et que le tuyau de date personnalisé ne soit pas nécessaire.

Juste curieux de connaître les progrès sur "Runtime i18n (un bundle pour tous les paramètres régionaux avec AOT)."

Mon équipe a plusieurs grandes applications avec plus de 60 langues. À l'heure actuelle, nous exécutons N builds en parallèle de sorte que N soit le nombre de langues. Cela nécessite beaucoup de ressources, comme vous pouvez l'imaginer, d'autant plus que les applications sont assez volumineuses et se déploient plusieurs fois par jour dans plusieurs environnements.

Ce que j'espère c'est :

1. Quelques ETA approximatifs sur le runtime i18n
2. Confirmation que le runtime i18n effectuera une seule génération pour toutes les langues
3. Si oui ou non chaque langue produite sera chargeable paresseux ou sera dans un seul paquet massif

@chcaru en attendant que ng fournisse une solution "native", jetez un œil à https://github.com/actra-development-oss/ng-i18n-aot-loader/
Il fournit exactement ce que vous demandez, une version AOT avec plusieurs paramètres régionaux.

@chcaru :
1/ L'ETA approximatif est Angular v6 (la première bêta devrait être d'ici fin janvier je crois ? pas sûr), la bonne nouvelle est que les traductions de code devraient suivre rapidement après les traductions d'exécution puisque presque tout le travail sera fait
2/ oui
3/ les traductions doivent être séparées du bundle, vous pourrez charger paresseusement celle dont vous avez besoin avant le démarrage, ou tout simplement regrouper tout en un, nous voulons également prendre en charge les traductions de chargement paresseux pour les modules, mais pas sûr quand ça va être disponible

@ocombe jusqu'à la sortie d'angularv6, l'option la plus sérieuse pour charger dynamiquement les traductions et/ou créer une application multi-langues avec un seul package est ngx-translate.

Avez-vous des conseils pour aider les personnes qui commencent à utiliser ngx-translate à migrer facilement lorsque angularv6 est sorti ?
Un pont entre les deux applications ?

Pas vraiment, le code est assez différent... on verra quand la v6 sortira avec ces fonctionnalités si je suis motivé pour travailler sur un outil de migration

Salut, merci pour la transparence des fonctionnalités à venir.

Il serait très utile de connaître les réponses aux questions suivantes :

1. Avez-vous une idée de la différence entre le nouveau flux de travail i18n et celui actuel décrit dans https://angular.io/guide/i18n ?

2. Les attributs i18n et i18n-*, par exemple, i18n-title avec un identifiant personnalisé facultatif seront-ils toujours disponibles dans les modèles ?

3. Les commandes suivantes fonctionneront-elles toujours ?

ng serve --aot --locale fr

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

1. comment les trans-unités messages.xlf extraites des templates seront-elles fusionnées avec celles utilisées dans le code ?

1. Nous rendrons l'expérience de mise à jour aussi fluide que possible, très probablement ce qui fonctionnait avant fonctionnera toujours après au moins jusqu'à la v7.
2. Les attributs i18n resteront les mêmes
3. l'extraction doit être la même aussi
4. c'est probablement la seule partie qui va changer, je ne sais pas encore comment donc je préfère ne pas vous dire ce qui pourrait changer, mais les messages seront fusionnés au moment de l'exécution lors de la création des vues (donc entre le bootstrap et la vue apparaissant sur l'écran)

Suite au commentaire de @Toub , pour cette période de transition, nous serions intéressés d'avoir des retours pour l'approche suivante (mélangeant l'attribut i18n et ngx-translate) que nous souhaitons mettre en place. Notre objectif est de minimiser au maximum les mises à jour à faire dans le code lorsque le nouveau support i18n sera prêt.

(Notez que nous voulons des paramètres régionaux dynamiques, c'est-à-dire pas une seule application générée par paramètre régional)

• Nous utiliserons l'attribut i18n afin de pouvoir tirer parti de l'outil d'extraction angulaire.
• Sur la base de l'outil extrait, nous pouvons convertir des fichiers xliff (ou avec d'autres formats) en contenus avec des formats pouvant être utilisés par ngx-translate (json ou po)
• Nous tirerons parti de l'attribut translate sur les éléments en utilisant celui i18n pour appliquer les traductions (précédemment extraites)

Voici un exemple :

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

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

Merci pour vos commentaires !

Pourriez-vous ouvrir un problème sur ngx-translate pour cela ? Je pense que la meilleure chose serait probablement de mettre à jour la bibliothèque pour prendre en charge les attributs "i18n" comme alternative à "traduire"

@ocombe merci pour la suggestion! Je viens d'ajouter un problème pour cela sur ngx-translate...

@ocombe le problème que je peux voir est que les attributs i18n / i18n-* sont supprimés au moment de l'exécution (https://github.com/angular/angular/issues/11042). Y a-t-il un moyen de les garder ?

J'ai vérifié et sauf erreur de ma part, ils ne sont supprimés que si vous utilisez Angular i18n (ce qui signifie que vous chargez des traductions lorsque vous faites la compilation).

@ocombe Je comprends mais je ne charge pas les traductions puisque j'utilise Angular CLI et que j'ai démarré l'application avec ng serve ...

@ocombe , notre société va bientôt s'efforcer de prendre en charge i18n en utilisant la stratégie d'applications multiples par paramètres régionaux actuellement prescrite. Nous prévoyons également d'inclure les paramètres régionaux dans l'URL et de définir le href de base dans l'application. Une fois la fonctionnalité d'exécution i18n terminée, quels changements devrions-nous apporter à notre stratégie d'url locale ? Existe-t-il un meilleur moyen pour nous de commencer à éviter un grand refactor une fois que le runtime i18n est publié ? Merci pour votre travail sur tout cela.

⬆️ devrait dire "va bientôt commencer"

une application/locale devrait toujours fonctionner telle quelle (moins le petit changement pour charger le fichier de paramètres régionaux au démarrage si vous n'utilisez pas la cli)

Quelqu'un pourrait-il me cibler, s'il vous plaît, dans quel fichier les attributs i18n sont supprimés du bundle de modèles ?

cc @ocombe

Il a été modifié en 4.2.6 (PR https://github.com/angular/angular/issues/17999)

Salut! Je suis ce fil depuis longtemps. J'ai vu que la première bêta de la v6 est sortie. J'ai lu le changelog mais je n'ai rien vu de lié à ce problème de longue date. Des news sur ce front ? Ou du moins, y a-t-il une garantie que l'interface sera similaire à votre polyfill ?

Merci pour votre travail !

Ça va être dans l'une des dernières bêtas, ou peut-être RC (je sais je sais...).
L'interface sera similaire à goog.getMsg depuis la fermeture puisque c'est ce que Google utilise en interne pour les traductions de code : https://developer.pubref.org/static/apidoc/global/closure/goog/getMsg.html
Mais nous utilisons peut-être un wrapper, donc cela changera peut-être l'interface pour Angular, pas encore sûr.
Dans mon polyfill, j'utilise une interface similaire, mais avec la possibilité de définir l'identifiant, la description et la signification si nécessaire, et je pense que nous en aurons besoin d'une manière ou d'une autre (soit via des paramètres, soit via un décorateur)

Merci pour tout votre travail acharné! Nous nous préparons à une réécriture complète de l'ensemble de notre application 1.x à partir d'avril. Y a-t-il quelque chose que nous pouvons/devons faire pour nous préparer à ces changements ? En ce moment, nous prévoyons d'utiliser 6.x. Merci encore!

@ocombe Juste curieux de savoir quand "Ignorer les espaces de début et de fin" atterrira ?

J'ai besoin de mettre à jour la feuille de route mais c'est un peu confus en ce moment (même pour moi). Cette fonctionnalité en particulier n'est clairement pas une priorité, ne vous attendez pas à ce que nous y travaillions de si tôt

@ocombe Ouais, ce serait génial. Nous aussi sommes très intéressés par le runtime i18n, car c'est le seul point bloquant pour nous. Pourriez-vous peut-être donner une estimation de son achèvement en % ?

Merci beaucoup pour votre travail acharné!

@ocombe

Cette fonctionnalité en particulier n'est clairement pas une priorité, ne vous attendez pas à ce que nous y travaillions de si tôt

Pourriez-vous préciser de quelle fonctionnalité vous parlez ici ? Je ne veux faire aucune hypothèse.

@ofuangka la fonctionnalité "Ignorer les espaces de début et de fin" n'est pas une priorité.
@Karamuto difficile à deviner pour l'instant, nous y travaillons en ce moment

@ocombe
Pourriez-vous s'il vous plaît partager votre jalon sur Runtime i18n (un bundle pour tous les paramètres régionaux avec AOT)

Maintenant, nous décidons d'utiliser les outils xi18n ou d'utiliser des bibliothèques tierces pour un énorme projet multilingue.
Nous espérons pouvoir utiliser des outils canoniques, mais conscients qu'ils sont trop bruts.

Aussi nous aimerions pouvoir scinder les fichiers xlf (un fichier par module), est-ce possible ?

haut Haut
le runtime i18n sera-t-il publié dans Angular 6 ?

merci et bon codage !

Perdre espoir ici, que cela sera terminé à temps, car il ne reste plus beaucoup de temps et il n'y a pas eu de réalisations jusqu'à présent concernant cette fonctionnalité.

La sortie de la version 7 serait assez tardive pour nous.

@Karamuto #22654
Je pense qu'il sortira en v6, mais ils doivent d'abord terminer Ivy.

Nous devrions avoir un hello world qui fonctionne cette semaine, mais avec des fonctionnalités minimales (pas de support ICU par exemple).
Mais comme il est sorti avec le lierre qui est derrière un drapeau, nous continuerons à travailler dessus et publierons dès que nous aurons terminé une nouvelle fonctionnalité, il n'est pas nécessaire d'attendre la v7

@ocombe
Cela sonne bien ! Il n'a pas besoin d'être complet avec ICU dès le départ. S'il avance dans les dernières versions de la v6, cela nous convient parfaitement.

Merci encore pour l'excellent travail !

@Karamuto voir #22654 pour un avant-goût !

Question stupide : Existe-t-il un moyen d'avoir une directive i18n pour les entrées basées sur des chaînes dans des composants personnalisés. Un exemple lors de la transmission d'étiquettes aria :

J'enveloppe un bouton personnalisé qui fait des choses sympas :

Le modèle de bouton personnalisé ne fait que :

Existe-t-il déjà un moyen de le faire?

@kekraft Je pense qu'avec des entrées statiques, vous pouvez utiliser la syntaxe d'attribut i18n :

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

Dans le composant :

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

@ocombe avez-vous besoin de contributeurs pour effectuer le travail d' exécution i18n ?

Ouais ! v6 publié ~~~
une mise à jour ici?

l'exemple i18n angulaire 6 est ici
https://github.com/angular/angular/pull/23660

@sandangel vouliez -vous dire simplement "tout" ou "tout ce qui est vérifié", d'après les plans au début de ce fil ?
J'avais vraiment hâte d'avoir une seule application, je pense que c'est l'une des choses les plus importantes. Je suis allé au # 23660 que vous avez lié, puis vous avez atteint https://pr23660-e12f469.ngbuilds.io/guide/i18n
Mais là, il est toujours écrit :

Lorsque vous internationalisez avec le compilateur AOT, vous devez pré-construire un package d'application distinct pour chaque langue et servir le package approprié en fonction de la détection de langue côté serveur ou des paramètres d'URL.

Est-il possible d'avoir une seule application pour plusieurs langues ou pas encore ?

@MrCroft semble que le runtime i18n est toujours en cours. J'ai lu comme vous quelques options supplémentaires mais pas un seul bundle pour toutes les localisations :(

Nous avons un bonjour qui fonctionne mais c'est uniquement pour le nouveau moteur de rendu (ivy) et comme ivy n'est pas prêt pour les heures de grande écoute, vous devrez malheureusement attendre cela :(

@ocombe donc, à moins que nous n'ayons pas Ivy en production (probablement vers la v7), nous n'aurons pas de traductions d'exécution. est-ce correct?

@ocombe est-ce que le monde hello et les trucs de lierre sont accessibles au public ? Ce serait cool d'essayer de comprendre cette nouvelle implémentation i18next😃

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

@fetis oui :(
@feloy oui, le simple hello world est ici : https://github.com/angular/angular/tree/master/packages/core/test/bundling/hello_world_i18n mais très minimal
vous pouvez trouver les tests ici : https://github.com/angular/angular/blob/master/packages/compiler/test/render3/r3_view_compiler_i18n_spec.ts
et un peu de refactoring + extraction ici : https://github.com/angular/angular/pull/22931

@ocombe, nous essayons d'implémenter i18n dans notre application, mais partout où je lis à ce sujet, je vois que nous avons besoin d'un fichier messages.xlf par langue. Cela ne deviendrait-il pas un surcoût à maintenir compte tenu d'applications complexes avec divers écrans orientés client, etc. Je cherche à voir si nous pouvons ventiler le fichier de messages par composant ou par module? Est-ce déjà supporté ?

@stickler-v ce fichier c'est juste le transport de vos chaînes vers votre logiciel de traduction. n'envisagez pas de le traduire manuellement.

Je vois, où avons-nous du texte réel dans différentes langues? Nous devons gérer ce texte manuellement au lieu de le faire faire par des traducteurs.

Désolé, mais je suis un peu perdu. Basé sur la documentation originale ici https://angular.io/guide/i18n. src/app/app.component.html n'aura que du texte en anglais. messages.fr.xlf est le fichier qui contient du texte en français mais il est généré automatiquement et il n'est pas conseillé d'y toucher.

Si je veux que app.component.html soit rendu en utilisant du texte français au lieu de l'anglais, où dois-je spécifier les messages français "Bonjour" etc. ?

@stickler-v c'est vraiment hors sujet, veuillez créer une question sur StackOverflow. Je me ferai un plaisir d'y répondre.

Pouvez-vous s'il vous plaît ne pas en discuter ici, ce n'est pas le sujet ici, merci
En ce qui concerne votre question @stickler-v, un fichier par module / composant n'est pas possible pour le moment, cela pourrait l'être dans le futur mais ce n'est pas sur la liste des choses sur lesquelles nous travaillons en ce moment

Avez-vous prévu de prendre en charge les traductions d'itinéraire ?

Désolé si cela a déjà été répondu, mais les traductions en JS sont-elles possibles avec cette version ou est-ce toujours uniquement des modèles ?

@santhony7 Ce n'est toujours pas possible car Ivy n'est pas prête.

Une question que j'ai sur l'intention/fonctionnalité de l'exécution i18n ici est de savoir si cela signifie que nous pourrons essentiellement sélectionner la langue lors de l'exécution et la "retourner" sans recharger l'application, comme c'était le cas dans l'ancien ng-translate pour AngularJS et dans ngx-translate ? Ou est-ce que cela signifie tout à fait autre chose ?

Non, vous devrez recharger l'application pour changer la langue.

Avec l'i18n actuel, lorsque vous créez et fournissez vos traductions, nous remplaçons les chaînes dans le code du bundle, ce qui signifie que le bundle est localisé.
Runtime i18n signifie que les fichiers de traduction sont chargés au démarrage de l'application et non au moment de la construction comme c'est le cas actuellement.
Pour cette raison, vous pourrez charger paresseusement les fichiers de traduction avant le démarrage de l'application, ce qui signifie que le bundle est séparé de la langue, vous n'obtenez qu'un seul bundle pour votre application.
Vous pouvez également choisir d'avoir un bundle par langue, et regrouper le fichier de langue avec votre application (comme nous le faisons actuellement), vous éviterez le délai nécessaire au chargement paresseux du fichier de traduction.
Dans un cas, vous faites une requête http supplémentaire, et dans l'autre non, mais je ne pense pas qu'il y aura une différence suffisamment importante pour justifier d'avoir un bundle par langue.

Avantages de l'environnement d'exécution i18n :

• détectez le côté client de la langue et chargez paresseux le fichier de traduction que vous souhaitez
• comme le code est indépendant de la langue, vous obtenez un bundle pour toutes les langues
• les bibliothèques peuvent également être compatibles "i18n"
• puisque nous chargeons les traductions au moment de l'exécution, nous avons tout ce dont nous avons besoin pour fournir un service qui peut également effectuer des traductions dans votre code (pas seulement les modèles)
• nous pourrions diviser les traductions par module (probablement pas disponible au début)

Désavantages:

• la traduction au moment de l'exécution a un petit coût lorsque les traductions sont extraites et transformées en nœuds html, mais j'espère que vous ne devriez pas le remarquer car ivy sera beaucoup plus rapide que le moteur de rendu actuel
• le démarrage de l'application est retardé par le temps qu'il faut pour charger paresseusement les traductions, ou votre bundle est un peu plus gros (si vous regroupez les traductions)
• nous devons ajouter les sérialiseurs à votre app bundle pour pouvoir lire les traductions, et c'est beaucoup de code (nous pourrions probablement "pré-compiler" les traductions dans une sorte de json pour éviter cela, nous n'avons pas encore décidé )

Théoriquement, vous pouvez changer la langue sans recharger toute l'application, mais vous devrez recréer les composants existants car les modèles sont générés lors de la création du composant, ou vous pouvez lier le service dans votre modèle (au lieu d'utiliser i18n attributs) et il sera mis à jour lorsque vous changerez de langue. Il serait possible d'écrire une bibliothèque qui fonctionne comme ngx-translate mais utilise Angular i18n en interne et vous permet de changer la langue au moment de l'exécution. Cela utiliserait plus de mémoire pour garder les modèles synchronisés avec la langue, comme c'est le cas avec ngx-translate. Je vais probablement écrire une bibliothèque comme celle-ci.

aussi pour que les gens réfléchissent, c'est que certains changements d'une langue à une autre peuvent être petits, d'autres peuvent être importants, disons que passer de l'anglais à l'espagnol peut être un "petit" mais de l'anglais au chinois ou à l'arabe sera important.
pour clarifier pour certaines langues, ce n'est pas seulement le texte, vous devrez peut-être également concevoir une mise en page différente pour s'adapter à cette langue et ses règles d'alignement, de gauche à droite ou de droite à gauche et d'autres détails.

donc pour la plupart des utilisations dans le monde réel, je m'attendrais à ce que l'application ait au chargement de l'application une étape de détection de langue qui conduira au chargement des bonnes ressources et de certaines mises en page.

@ocombe Merci beaucoup d'avoir clarifié ! J'ai implémenté l'actuel Angular i18n dans notre application et j'ai rencontré un problème en raison de modifications/d'exigences inconnues. J'utilise également la bibliothèque https://github.com/ngx-translate/i18n-polyfill en conjonction pour aider à combler le fossé actuel.

Bien que les multiples bundles soient un léger ennui, vous pouvez le contourner assez facilement actuellement. Le hic, en particulier, est la possibilité d'avoir un composant (et tous ses composants enfants) à afficher dans une langue différente de la langue actuellement utilisée.

Franchement, je ne sais pas encore si ngx-translate peut m'aider à accomplir cela pour moi, mais je voulais vous envoyer un message sur les changements à venir juste pour m'assurer d'avoir autant d'informations que possible avant de faire des pivots.

Nous n'avons aucun plan pour prendre en charge les applications traduites dans plusieurs langues en même temps, cela pourrait être possible à l'avenir si nous pouvions charger des traductions/modules, mais ce serait un effet secondaire de l'architecture, pas quelque chose que nous avons spécifiquement essayé d'atteindre.

Existe-t-il un ETA pour Ivy + runtime i18n ?
Je comprends parfaitement si ce n'est pas le cas, mais j'ai besoin de savoir si (compte tenu de la durée de mon projet actuel) je peux l'attendre ou si je dois commencer à utiliser l'une des solutions actuelles et reporter la migration vers le runtime i18n pour une future version .

Je ne vais pas essayer de donner un délai exact, à chaque fois que j'ai essayé c'était faux :D
Ce ne sera pas avant la v7 maintenant (sera disponible avant en version bêta)

Pas de problème, nous savons tous que les estimations sont toujours fausses. :RÉ
Pensez-vous qu'il sera plus facile de migrer de l'actuel i18n (+ i18n-polyfill) vers le runtime 18n ou depuis ngx-translate ?

probablement à partir de l'i18n actuel, mais j'écrirai une version de ngx-translate qui utilise les composants internes d'Angular i18n, si c'est possible (pas encore sûr)

Salut, j'ai essayé de traverser ce fil pour comprendre l'état actuel. Le code de traduction ngx est-il actuellement la "solution de contournement" la plus viable pour une seule application avec localisation dynamique ?

Salut, Est-il possible de changer la localisation au moment de l'exécution en utilisant ngx-translate/i18n-polyfill ?

@suchg Pas au moment de l'exécution. Vous pouvez effectuer des traductions au moment de l'exécution, mais vous ne pouvez pas modifier les paramètres régionaux utilisés.

@mjschranz merci pour la réponse rapide
même les traductions d'exécution sont bonnes pour l'instant. pouvez-vous partager un exemple pour le même.
J'ai essayé l'exemple partagé sur https://github.com/ngx-translate/i18n-polyfill , et j'ai changé la langue du navigateur chrome mais pas de chance.
existe-t-il une méthode spécifique pour la traduction ??

S'il vous plaît, gardez la discussion ici sur Angular, pas sur les bibliothèques externes. Si vous avez besoin d'aide pour cela, publiez les messages sur leurs dépôts github

Hé, y a-t-il d'autres problèmes de suivi ou des documents de conception sur ce à quoi ressemblera la fonctionnalité à l'avenir ? Peut-être pouvons-nous aider à la mise en œuvre ou nous préparer pour nous assurer que la transition dans la v7 sera aussi fluide que possible.

Bonjour, j'utilise actuellement Angular 5 et nous devons ajouter plusieurs langues à notre projet.
J'ai ajouté une solution qui fonctionne pour moi maintenant, qui est presque élégante. https://github.com/angular/angular/issues/24549.

Idéalement, je voudrais charger paresseux les fichiers de langue basés sur un service de renifleur de pays (basé sur une recherche de carte de nom d'hôte).
Si cela était possible dans Angular 6, ce serait formidable.

@mattiLeBlanc Comment résolvez-vous les messages dynamiques, par exemple les messages de composants ou de services ?

@zverbeta Veuillez m'excuser de ne pas bien comprendre Angular Core ou le contexte de cette discussion. Je ne peux l'aborder qu'à partir de mon contexte pour commencer.

En réponse à votre question, je suppose que nous ne sommes intéressés que par le chargement paresseux des fichiers de traduction (xlf) de manière agréable, en fonction d'une locale qui peut être déduite de l'URL ou d'un paramètre de requête de langue. (J'utilise actuellement un mappage d'URL pour décider des paramètres régionaux).

Un message d'un composant ou d'un service n'est pas étiqueté comme nous étiquetons le balisage avec i18n. J'ai une certaine expérience avec i18n pour Wordpress et PHP. Là, nous utilisons l'approche __( 'text' to translate, 'text domain' ) pour obtenir la traduction correcte. Ce __() peut également être analysé par la commande CLI créant le fichier de messages.

Est-ce l'un des problèmes auxquels vous faites référence ?

Une chose que j'ai remarquée avec ce bloc de balisage par exemple (parce que j'étais paresseux et que je ne voulais pas ajouter i18n sur chaque sous-élément):

<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>

c'est-à-dire copier tout le bloc div dans mon message.xlf.
C'est beaucoup de pollution de balisage. (Bien sûr, je pourrais utiliser i18n sur chaque balise contenant du texte.)

Pour cet exemple, utiliser la commande _e() fonctionnerait plutôt bien, je pense. Vous envelopperiez votre texte avec la commande echo et tout ce texte enveloppé sera collecté. Vous pouvez vous débarrasser de toute cette copie de balisage dans le xml.
Si vous avez besoin d'ajouter quelque chose de dynamique à cette chaîne, vous pouvez la diriger avec des espaces réservés dans la chaîne (comme vous le feriez avec sprintf . Quelque chose comme

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

où fruit est une variable avec une valeur de __( 'apple') ou __( 'pear) .
Les 3 morceaux de texte se retrouveraient dans le XML et pourraient être traduits séparément.

Cela servirait-il à quelque chose ? C'est assez similaire avec l'ajout de l'attribut i18n, je m'en rends compte après avoir relu :)

Enfin, en regardant quelques formats. XLIFF 2 a l'air plutôt sympa, un peu plus propre que la 1.2. Le XMB a l'air déroutant, une documentation horrible qui semble avoir été conçue en 1995.
J'ai remarqué lors de l'utilisation de XLIFF 2 que le texte TARGET n'était pas rendu comme dans la version 1.2.

Avez-vous regardé les fichiers .pot et .mo ? Format assez simple et également utilisé par traduit avec l'outil POEdit.

j'ai besoin de convertir mon application en anglais et en espagnol en utilisant le bouton bascule. A fait toutes les modifications, fichier de travail séparément. J'ai créé deux builds sous .dist/en et dist/es. Quelqu'un peut-il me dire ce que je dois faire pour le déploiement et comment basculer entre les deux builds ?

Ce que je dois faire en cliquant sur le bouton bascule

@ shobhit12345 veuillez poster votre demande d'assistance sur https://stackoverflow.com

@zverbeta la solution que j'ai postée au # 24549 ne fonctionne pas lorsque je construis avec --prod . Un peu évident puisque j'utilise require qui n'est probablement pas disponible ?
Sans l'indicateur --prod, la solution fonctionne-t-elle car elle inclut le code lié au webpack ?

@mattiLeBlanc J'ai trouvé cette bibliothèque https://github.com/ngx-translate/i18n-polyfill et cela résout mon problème avec le texte dynamique

Salut, comment pouvons-nous traduire les valeurs dynamiques (interpolation) en utilisant 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>

Hé! Y a-t-il un endroit où nous pouvons suivre et/ou aider avec les tâches sur lesquelles nous avons travaillé ? (ceux avec une étiquette de travail dessus )

Des mises à jour sur un calendrier pour la sortie d'une version bêta du runtime i18n ?

@marcelnem je ne trouve pas le commentaire mais iirc ocombe a mentionné que le runtime i18n est fusionné pour ivy afin que vous puissiez probablement le tester sur la version bêta v7 avec le drapeau ivy

La partie runtime est terminée mais pas la partie compilateur, ce qui signifie que vous ne pouvez pas encore la tester avec ivy

Salut, je travaille avec Angular 6 i18n. Je travaille avec plusieurs langues, ce qui signifie que j'ai suivi le livre de cuisine :
https://v2.angular.io/docs/ts/latest/cookbook/i18n.html#!

Mon implémentation actuelle utilise AOT, j'ai donc généré un fichier messages.xlf et un messages.pt.xlf. Tout fonctionne bien, quand je cours

ng servir --configuration=pt

Je fais traduire les textes comme prévu. Mais j'ai l'impression qu'il y a quelque chose qui ne va pas dans la façon dont cela fonctionne. Il me manque probablement quelque chose. Pour autant que j'ai compris, chaque fois que j'ajoute une nouvelle chaîne à traduire et que je la marque avec l'attribut i18n, je dois regénérer le fichier messages.xlf en exécutant "ng xi18n", puis mettre à jour manuellement le messages.pt.xlf. Le fichier xlf contient également le numéro de ligne où se trouve la source, il semble donc que si je modifie la ligne, je devrai également regénérer le fichier et mettre à jour manuellement mon fichier pt.

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

Cela n'a pas l'air intelligent, cela me donnera beaucoup de travail supplémentaire pour le faire fonctionner. Comprenez-vous mon inquiétude ? Est-ce que je manque quelque chose?
Je sais que Angular 7 i18n aura une grosse mise à jour avec l'incorporation d'Ivy, dois-je l'attendre ?

Meilleures salutations,
fabio

ps J'espère vraiment que ce n'est pas hors sujet, mais si vous pensez que c'est le cas, donnez-moi au moins une direction. Où devrais-je demander cela par exemple? Ou s'il y a un lien qui pourrait répondre à mes doutes.

@fabiopcarvalho Une chose que j'ai réalisée est qu'il est sage d'utiliser des identifiants personnalisés pour chaque traduction afin de faciliter le suivi des modifications de la mise en page HTML.

Mais oui, vous devrez régulièrement mettre à jour le fichier de traductions.

@fabiopcarvalho J'utilise xliffmerge pour m'aider avec la fusion des traductions

Parfait, j'ai utilisé cet outil et cela a très bien fonctionné. J'utilise également les identifiants et
ils aident.
Merci pour la réponse !!

Le jeudi 30 août 2018, Pedro Romero [email protected] a écrit :

@fabiopcarvalho https://github.com/fabiopcarvalho J'utilise xliffmerge
https://github.com/martinroob/ngx-i18nsupport pour m'aider avec la fusion
des traductions

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/angular/angular/issues/16477#issuecomment-417407822 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AWOWQ6vpjOb0Ntgpv7TungRrBBsUIkVjks5uWCV7gaJpZM4NOSBk
.

Autoriser les messages ICU dans les attributs est essentiel pour l'accessibilité car l'attribut aria-label est beaucoup utilisé dans l'accessibilité. Y a-t-il un problème pour le suivi ?

Je ne pense pas qu'il y ait un problème pour cela, pourriez-vous en ouvrir un? Je travaille actuellement sur les expressions ICU pour le lierre, j'ai donc ajouté un TODO, mais une demande de fonctionnalité serait préférable

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

Parfait merci (la recherche Github est vraiment mauvaise !) !

Sera-t-il possible de charger paresseux les fichiers de traduction depuis une source externe par exemple via HTTP avec la nouvelle version d'i18n ?

@ocombe comme vous l'avez dit, vous travaillez sur Runtime i18n (un bundle pour tous les paramètres régionaux avec AOT). ça fait plus d'un an qu'on attend. quand pouvons-nous nous attendre à ce que cette fonctionnalité arrive dans la version angulaire 7?

@Sef1995 c'est l'une des choses que nous voulons activer
@AhmadShahid , il faudra lierre qui sera publié indépendamment de la v7 et lierre ne sera pas prêt pour la sortie de la v7. Certaines parties de lierre sont déjà en v6 derrière un drapeau, mais ce n'est pas complet et vous ne devriez pas l'utiliser dans une application du monde réel. Nous n'avons pas encore de date de sortie pour Ivy.

@ocombe une question rapide, si nous implémentons i18n à partir d'aujourd'hui (angular6), qui nécessitera différentes versions (une pour chaque langue), l'effort est-il perdu lorsque ivy sort et que l'exécution i18n? Je veux dire que la façon dont i18n serait implémenté maintenant sera différente de ce qui s'en vient ? Essayer de planifier des sprints à l'avance et de prioriser le travail. Merci

Nous ne voulons pas créer de changements de rupture si nous pouvons l'éviter. Les identifiants des traductions extraites peuvent changer à mesure que nous corrigeons des bogues que nous avons depuis longtemps, mais nous proposerons un outil de migration. Je ne peux pas dire avec certitude qu'il sera 100% compatible, mais attendez-vous à ce que la plupart des choses fonctionnent de la même manière, avec de nouvelles options disponibles à utiliser si vous le souhaitez.

@ocombe une question rapide, si nous implémentons i18n à partir d'aujourd'hui (angular6), qui nécessitera différentes versions (une pour chaque langue), l'effort est-il perdu lorsque ivy sort et que l'exécution i18n? Je veux dire que la façon dont i18n serait implémenté maintenant sera différente de ce qui s'en vient ? Essayer de planifier des sprints à l'avance et de prioriser le travail. Merci

Salut, vous pouvez utiliser le webpack pour charger dynamiquement des fichiers (comme solution de contournement temporaire) avec une seule version :
Un exemple peut être trouvé ici : https://github.com/angular/angular/issues/24549#issuecomment -402013622

Vous devez construire avec --prod --aot=false, car AOT=true supprimera les éléments du webpack.

@ocombe Bonjour,

La release candidate A7 est sortie, comme promis allons-nous tester la traduction d'exécution ?. Runtime i18n (one bundle for all locales with AOT) . Comment puis-je tester cela. S'il vous plaît aider

Merci

Je seconde la question de @sheikalthaf bien que la v7 soit déjà sortie.

@sheikalthaf @Shuyinsama Comme expliqué quelques commentaires ci-dessus et dans le premier message :
Le runtime i18n nécessite ivy qui sera publié indépendamment de la v7. Certaines parties de lierre sont déjà dans la v7 derrière un drapeau, mais ce n'est pas complet et vous ne devriez pas l'utiliser dans une application du monde réel. Nous n'avons pas encore de date de sortie pour Ivy.

@ocombe : Qu'en est-il du passage de la clé i18n dynamique du composant parent au composant enfant.

Composant enfant :
<div i18n="{{labelTextKey}}">{{labelText}}</div>

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

Je peux le passer, mais comme la traduction i18n se produit au moment de la construction, la variable est à cet état toujours vide. Donc, par conséquent, aucune traduction ne se produit.

Une mise à jour pour un tel cas?

@bobKasbi

vous n'avez pas besoin de la balise i18n dans le composant enfant, vous pouvez simplement l'utiliser dans le parent comme ceci :

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

@cjsase : fonctionne très bien. Merci beaucoup! Était aux prises avec près de 2 jours.

Basé sur ceci : https://github.com/angular/angular/issues/21706#issuecomment -430435254

• Il ne faut pas s'attendre à du lierre dans la v7. La v8 est prévue pour mars/avril 2019 . Si nous ne devrions pas nous attendre à ce que lierre soit dans la v7, existe-t-il une recommandation/un consensus sur ce qu'il faut utiliser pour l'internationalisation (i18n) jusqu'à la sortie de lierre en avril 2019 ?

Ce sont des informations incorrectes. L'équipe principale n'a jamais dit que IVy serait publié en 2019. Au lieu de cela , l'équipe principale a déclaré (c'est moi qui souligne):

il devrait être publié dans n'importe quelle version mineure , chaque fois qu'il a été testé et validé

Disons que j'ai une application angulaire 7.1.0-beta.0 avec lierre activé, est-il possible pour moi d'avoir une configuration avec un changement de langue dynamique émis depuis l'avant sans rafraîchissement de page?

si oui comment ? cette doc : https://github.com/angular/angular/blob/master/aio/content/guide/i18n.md
et cette doc : https://angular.io/guide/i18n

ne présente pas cela ?

où puis-je apprendre à créer une application i18n-angular moderne/future ?

@tatsujb non ce n'est pas possible, et ce ne sera pas possible même avec ivy & runtime i18n. Vous devrez recharger votre application Angular si vous souhaitez changer de langue, pour l'instant

ok mais les docs s'appliquent un peu à une version chimérique d'angular comme 4 moins.

Je ne pense pas qu'ils s'appliquent à ma configuration et qu'ils ne couvrent pas exactement la façon dont vous faites en sorte que le changement prenne effet.

Je suppose que le changement devra être appliqué par le backend.

Dans mon cas, mon angular est servi en mode production par un backend java-spring. quelles sont les grandes lignes de ce qui va se passer lorsque j'appuie sur l'icône du drapeau pour changer de langue ?

Vous dirigez l'utilisateur vers www.yourdomain.com/cn/ où l'intégralité de votre application Angular est compilée en chinois. Vous vous retrouvez avec une application Angular compilée entière pour chaque langue que vous souhaitez prendre en charge.

@ocombe @santhony7 qu'en est-il : https://github.com/actra-development-oss/ng-i18n-aot-loader ?

pourrais-je essayer ça?

est-il mal compatible avec 7.1.0-beta.0 ou décemment compatible ?

@ocombe @santhony7 qu'en est-il : https://github.com/actra-development-oss/ng-i18n-aot-loader ?

pourrais-je essayer ça?

est-il mal compatible avec 7.1.0-beta.0 ou décemment compatible ?

Je recommande d'utiliser ngx-translate à la place. J'ai utilisé les deux et ngx-translate est beaucoup plus facile à entretenir.

@digismack une autre différence entre les deux, ce qui est un peu effrayant, c'est que ngx-translate supprime tous les éléments officiels angular-i18n et n'en utilise aucun. c'est son propre circuit indépendant et les fichiers json sont beaucoup moins précis sur les sources des traductions.

aussi sur les deux démos ngx-translate semble beaucoup plus lent, que voulez-vous dire quand vous dites que c'était plus facile à maintenir ?

@tatsujb en tant que développeur du ng-i18n-aot-loader, je sais que c'est plutôt difficile à mettre en œuvre, du moins en intégrant les chargeurs.
Tout le reste est un jeu d'enfant car il suit les paradigmes i18n angulaires originaux.

Cela devrait fonctionner avec la v7 tant qu'il n'y a pas eu de changements majeurs dans les structures de balises ou similaires.

essayant d'implémenter ngx-translate je dois aller lieu traduisible par lieu traduisible. il y en a des centaines, c'est un peu ridicule pour moi de ne pas pouvoir utiliser mes balises i18n que j'avais déjà planifiées.

Je commence à penser que te faire confiance était le mauvais choix, @digismack

@tatsujb Il y a 58 personnes qui suivent ce problème. Personnellement, je le suis pour les mises à jour de l'équipe Angular concernant i18n. J'apprécierais que vous arrêtiez le bavardage à moins qu'il ne soit lié à ce que l'OP déclare:

Si vous souhaitez que de nouvelles fonctionnalités i18n soient ajoutées à Angular, n'hésitez pas à demander ci-dessous et je vous ferai savoir si cela est faisable et si vous devez ouvrir un problème pour cela.
Si vous avez un bug, ouvrez un ticket (pas besoin d'en parler ici).

Si vous rencontrez des problèmes avec d'autres bibliothèques, je vous suggère de poser une question sur StackOverflow.

Ce n'est pas dans mes habitudes d'écrire/de commenter... mais je le ferai !
Considérant :
@gtbuchanan et CO sont de type A de personne.
@tatsujb et les autres personnes qui se plaignent/commentent/attendent des choses sont de type B de personne

Type A tu n'es pas fatigué de répéter toujours les mêmes choses ?!?! Pour moi, tu es plus ennuyeux que le type B.

en raison de la fonctionnalité manquante d'i18n dans le type angulaire B, les gens sont plus frustrés que vous qui vous contentez de "s'abonner" à un problème (si c'est pour vous faire des amis, gagner des likes, allez sur facebook je ne sais pas, ici ce n'est pas la place pour ça , tu ne changeras pas de mot ni n'inventeras quelque chose en disant ça !...)

Je pense que le type A peut se désinscrire, attendre la mise à jour, consulter rapidement le journal des modifications ou lire le blog/les actualités, assurez-vous que l'équipe angulaire le mettra en grande police ARIAL 72pixel qu'ils introduisent i18n traduction dynamique à partir de ts + runtime i18n : grande fonctionnalité manquante dans angular ! ils n'y ont pas énormément pensé donc nous n'avons pas le bon i18n aujourd'hui, c'est la stratégie de google ou autre et ça ne peut pas changer !

Les gens B attendent cette fonctionnalité il y a 2 ans, https://github.com/angular/angular/issues/9104#issue -159302131 oui depuis angular 2.X !

Je veux juste dire s'il vous plaît, respectez le type B frustré et ne soyez pas méchant. Si personne ne se plaint beaucoup d'i18n, je pense que l'amélioration d'i18n ne sera pas envisagée dans les années à venir, c'est aussi de l'open source ! se plaignent des critiques ! la stratégie peut changer ! alors laissez les gens se plaindre, désabonnez-vous, vous êtes mieux que les autres vous pouvez trouver vos informations sans vous abonner à ce numéro !

Type B, veuillez continuer à vous plaindre/commenter jusqu'à ce que vous le puissiez ! c'est la seule meilleure façon de comprendre les besoins des gens !

Frappe Frappe lol

@tatsujb Tout dépend de vos préférences personnelles. La dernière fois que j'ai implémenté ng-i18n-aot-loader , j'ai dû exécuter une version éjectée et personnaliser la configuration du webpack pour qu'elle fonctionne. Peut-être que ce n'est plus le cas. Cependant, l'exécution d'une version éjectée signifiait que les outils CLI angulaires n'étaient plus utilisables. Donc, j'ai trouvé plus facile à long terme d'implémenter ngx-translate et de gérer le fait que cela fonctionne un peu différemment.

@gtbuchanan Je ressens votre douleur, mais ce "bavardage" est directement lié à la portée des fonctionnalités mentionnées dans le message d'OP. Étant donné que le délai pour Runtime i18n (one bundle for all locales with AOT) a continué de glisser, les gens viennent toujours sur ce fil pour rechercher des solutions actuelles.

@ocombe , nous sommes sur le point de démarrer un nouveau projet maintenant, où nous obtiendrons les traductions à partir d'une base de données.
Nos modules angulaires seront chargés paresseusement et nous aimerions également rester aussi proches que possible de ce que propose Angular concernant I18N.

Étant donné que la prise en charge d'Angular I18N n'a pas été intégrée à la dernière version comme prévu, avez-vous des recommandations pour nous et d'autres qui sont sur le point de créer de nouveaux projets en ce moment ?

Par exemple, jusqu'à ce que I18N soit prêt, nous pourrions utiliser ngx-translate, mais j'ai ensuite lu quelque part dans les problèmes github de ce projet, qu'il ne prendrait pas en charge le chargement paresseux, ce qui serait un obstacle pour nous.

D'un autre côté, le support I18N d'Angular n'est pas encore prêt pour les heures de grande écoute.

J'apprécierais vraiment quelques conseils nous orientant dans la bonne direction sur ce qu'il faut utiliser pour le projet à venir - ngx-translate vs ?

Incontournables:

• chargement paresseux

Bon d'avoir:

• Expressions ICU

Merci

Pour les adeptes de ce numéro, @ocombe parlera du runtime i18n sur angularconnect dans quelques heures. Je suppose qu'au moins certaines des questions ouvertes y trouveront une réponse. il y a un livestream disponible

@ctaepper - merci beaucoup pour l'info !

@guygit cela pourrait être ngx-translate ou angular-l10n . voici le tableau de comparaison créé par moi https://medium.com/@sergeyfetiskin/tools-to-translate-your-angular-app-c021e25ff26a

pour nos applications, nous avons décidé d'aller vers Angular même si cela a quelques limitations.

@fetis Merci beaucoup - je vais jeter un œil :-)

Vous vous interrogez sur le choix des fichiers XLIFF pour les fichiers de traduction - Google Translate Toolkit ainsi que Flutter/Dart i18n prennent en charge les fichiers ARB et ne prennent pas en charge XLIFF. J'ai entendu dire que la prise en charge des fichiers ARB n'est pas prévue, mais je me demande si c'est quelque chose qui pourrait être à nouveau envisagé. Ou si quelqu'un ( @ocombe ?) pourrait indiquer où Angular interagit avec les fichiers XLIFF afin que je puisse voir à quel point il serait difficile d'intégrer le support ARB.

(Dans un certain contexte, nous allons utiliser Flutter/Dart pour nos applications mobiles et Angular pour notre application Web, et aimerions vraiment partager nos fichiers de traduction entre mobile et Web si possible. J'envisage d'écrire un Convertisseur ARB -> XLIFF s'il n'y a pas d'appétit pour envisager son inclusion dans Angular.)

@localpcguy si vous finissez par écrire un genre de convertisseur, vous pourriez être intéressé à le contribuer à https://github.com/translate/translate qui propose déjà la conversion depuis/vers de nombreux formats.

En passant, ocombe a déclaré il y a quelques mois qu'il ferait tout son possible pour prendre en charge les fichiers PO (et JSON ?). J'espère que cela arrivera à un moment donné, car nous avons eu du mal à trouver des outils ockay-ish pour travailler avec XLIFF.

parce que nous avions du mal à trouver des outils ockay-ish pour travailler avec XLIFF.

@PowerKiKi , ce n'est tout simplement pas vrai. Presque tous les outils de gestion de traduction en ligne prennent en charge le format XLIFF. Et il existe même des programmes de traduction de bureau gratuits si vous ne souhaitez pas modifier manuellement .xliff

@fetis Je déteste sortir du sujet mais j'ai trouvé beaucoup de douleur en ce qui concerne l'utilisation de XLIFF avec des outils. Voir mon commentaire ici : https://github.com/angular/angular/issues/20193#issuecomment -345755889

Veuillez fournir des références à ces outils, car nous n'avons toujours rien trouvé de bon et n'avons pas encore trouvé quelque chose qui prend en charge XLIFF 2. Smart Cat a l'air joli mais la mise à jour des chaînes qu'il contient me donne envie de jauger mes yeux.

Il semble que vous sachiez quelque chose que nous ignorons :)

Pootle utilise https://github.com/translate/translate et était vraiment génial avec Gettext (fichiers po) mais il ne prend pas en charge les espaces réservés/tags et ils attendent une contribution de quelqu'un pour l'ajouter

Je suis abonné à ce numéro depuis un an environ. Il semble que les progrès à cet égard ne soient pas une priorité pour l'équipe Angular, et devoir compiler l'application une fois pour chaque langue et passer par des étapes pour effectuer des traductions dynamiques n'est pas acceptable. Je recommande, si vous en êtes capable, de créer un tube personnalisé qui utilise l'autre bibliothèque i18n de votre choix. Étant pur, ce tuyau sera tout aussi efficace pour compiler l'application plusieurs fois. De plus, en utilisant un i18n qui ne dépend pas d'Angular, vous pourrez faire des traductions dynamiques à partir de code de manière triviale. Un autre avantage est que vos traductions ne dépendront plus d'Angular, vous pouvez donc commencer à migrer certains composants vers d'autres frameworks si vous le souhaitez, ou vous pouvez même choisir le format et les outils de traduction que vous préférez en toute liberté. J'utilise https://airbnb.io/polyglot.js/ et j'en suis très satisfait, et même lorsque la migration de mon application d'Angular i18n vers polyglot est toujours en cours, je ne peux pas être plus satisfait du résultat et de la suppression de la dépendance avec Angular i18n.

Désolé pour ceux qui recevront cela sous forme de notification sur votre courrier et ne se soucient pas de mon opinion, mais comme cela fait si longtemps de lire vos notifications, je sens que je dois dire au revoir avant de me désabonner :)

Acclamations!

Il semble que les progrès à cet égard ne soient pas une priorité pour l'équipe Angular, et devoir compiler l'application une fois pour chaque langue et passer par des étapes pour effectuer des traductions dynamiques n'est pas acceptable.

Runtime i18n est une grande priorité pour l'équipe angulaire. Cependant, le problème de blocage est le nouveau moteur de rendu Ivy. L'avancement du projet est bon jusqu'à présent et nous pouvons probablement nous attendre à Ivy pour Angular 8. Je comprends que c'est une situation difficile pour toutes les personnes impliquées. Il y a des plans mais ils ne peuvent pas être mis en œuvre tant qu'Ivy n'est pas terminé.

Voir les présentations de la récente conférence AngularConnect (2018) à Londres, notamment "Runtime i18n" d'Olivier Combe et le keynote du Jour 2 d'Alex Rickabaugh.

En effet mon expérience est similaire à @intellix.

XLIFF 1.2 a 10 ans , mais sa prise en charge dans les projets open source semble assez médiocre. Pootle ne prend pas en charge les palceholders selon https://github.com/translate/pootle/issues/4762 et https://github.com/translate/pootle/issues/1811. Weblate ne les supporte pas non plus , bien qu'un PR puisse ajouter un support bientôt .

Sur le bureau, Virtaal _prend_ en charge les espaces réservés XLIFF, mais la dernière version 0.7.1 a 6 ans et ne fonctionne plus sur le dernier macOS d'après ce que j'ai entendu. Il ne donne malheureusement pas l'impression d'un projet bien entretenu, avec quelques RP très anciens qui attendent encore d'être fusionnés malgré leur apparente simplicité. Et une activité d'engagement très faible ces dernières années .

Je viens d'apprendre que Poedit 2.2 sorti il ​​y a quelques jours supporte XLIFF 1.2 et 2.0. Je ne peux malheureusement pas le tester car je reçois une erreur de snapcraft.io CDN lors de l'installation pour le moment. Mais cela pourrait être la meilleure solution pour les utilisateurs de bureau.

@fetis si vous avez trouvé des projets open source (ou du moins gratuits) pour éditer XLIFF 1.2, ou mieux encore XLIFF 2.0, avec prise en charge des espaces réservés, veuillez les lister ici. Tout le reste que j'ai testé ne fonctionnait pas du tout ou était extrêmement complexe à utiliser.

@intellix @PowerKiKi voici la liste de ce que je sais. Notre cible est une plateforme de traduction en ligne, où nous pouvons collaborer avec des traducteurs/collègues de différents pays. Passer par le processus d'installation d'un logiciel de bureau pour chaque collaborateur et gérer la synchronisation des fichiers XLIFF n'est pas un choix pour nous. Donc, je n'ai pas testé les outils de bureau, les plates-formes que j'ai faites.

Applications
OmégaT
https://omegat.org/

Auto-hébergé
https://weblate.org/fr/ +hébergement payant
https://pootle.translatehouse.org/
https://pontoon.mozilla.org/

Plateformes
Crowdin
https://crowdin.com/
Prise en charge de l'interface de ligne de commande

WebTranslateIt
https://webtranslateit.com/
Prise en charge de l'interface de ligne de commande

Transifex
https://www.transifex.com/

PhraseApp
https://phraseapp.com/

Localiser
https://lokalise.co/
Prise en charge de l'interface de ligne de commande

_Je pense que nous finirons avec Lokalise pour nos projets car il offre suffisamment de fonctionnalités à un prix abordable._

~Éditeur PO~
https://poeditor.com/pricing/
La prise en charge XLIFF déclarée ne fonctionne pas avec le format Angular

Si vous recherchez une solution open-source, cette liste pourrait m'être utile https://opensource.com/article/17/6/open-source-localization-tools

Nœuds latéraux
Je n'ai pas vu de plate-forme en ligne prenant en charge XLIFF 2.0 et ce fut une grande surprise pour moi. XLIFF 1.2 est officiellement marqué comme obsolète et personne dans l'industrie n'a pris en charge la v2.

Heureux d'apprendre que POEdit a déclaré le support XLIFF, je l'ai utilisé pour les fichiers .po et c'était bien.

PS Je suis vraiment désolé de faire un hors-sujet ici, mais en même temps, obtenir un fichier XLIFF à partir de votre application n'est qu'une partie du voyage, vous devez le traduire et le maintenir tout au long du cycle de vie de votre application. C'est donc une discussion importante. Je suggérerais de déménager quelque part, je peux mettre cette liste en tant qu'article Medium et nous pouvons continuer la discussion là-bas.

@localpcguy il existe de nombreux formats, mais tout dépend du nombre que nous pouvons prendre en charge. L'écriture et la maintenance d'un sérialiseur prennent du temps. Xliff 2 a été ajouté en tant que PR par quelqu'un d'autre, c'est pourquoi nous avons ajouté le support (sinon nous n'aurions pas pris le temps de le supporter).
Nous avons besoin d'un sérialiseur pour deux choses : l'extraction et la fusion.
Je n'en ai pas parlé chez Angular Connect, mais j'espère que nous pourrons utiliser un sérialiseur externe. Cela devrait être très facile à faire pour l'exécution (fusionner) avec ivy, mais l'extraction est toujours compliquée car le sérialiseur doit être mis à jour lorsque nous apportons des modifications au compilateur.
J'ai quelques idées sur la façon de le faire, mais je devrai en parler à l'équipe une fois que le lierre aura atterri. Ce que j'aimerais vraiment faire serait d'ajouter au moins le support JSON afin que je puisse réécrire ngx-translate en utilisant Angular i18n (et parce que tant de gens le veulent).

Merci @ocombe (et toutes les autres entrées, j'aime voir les différentes vues). Il semble que # 14185 était le PR que vous avez mentionné, est-ce toujours un bon point de départ si je veux envisager d'ajouter le support ARB ? Est-ce quelque chose qui pourrait potentiellement être fusionné s'il est soumis ?

@localpcguy nous avons une réunion demain où nous discuterons de cela (et d'autres choses), je vous ferai savoir comment ça se passe

ok donc voici ce que nous pensons fonctionner: pour l'extraction, nous allons extraire des chaînes dans une sorte de format json (peut-être même ARB puisque c'est un format json officiel pour les traductions) que n'importe qui peut prendre et post-traiter au format que vous voulez utiliser (json est vraiment facile à utiliser), et pour l'exécution, nous fournirons une sorte d'interface que vous pourrez utiliser pour écrire votre propre chargeur qui comprend votre format.

Cela signifie donc à peu près que nous sommes libres d'utiliser n'importe quel type de format pour les traductions tant que nous pouvons fournir un chargeur pour l'application ?

Et bien ce serait génial :+1:

oui, vous n'auriez pas accès à des optimisations approfondies (remplacez les chaînes au moment de la construction pour créer un bundle par langue, ce qui signifie que les traductions seraient divisées en code avec vos composants), mais vous pourriez utiliser n'importe quel type de solution de chargement paresseux que vous voulez, tant que vous chargez toutes les traductions au démarrage de l'application (elles doivent être chargées de manière synchrone avant la création d'un composant)
vous pouvez également éventuellement les diviser manuellement en code et les charger avec le routeur de manière asynchrone lorsque vous chargez un nouveau composant, cela dépend de vous, en utilisant les nouvelles fonctionnalités de chargement paresseux fournies par ivy (Jason en a fait une démonstration à Angular Connect)

peut-on s'attendre à une démo bêta (pas de fichiers juste une vidéo ou un livestream) de changement de langue à la volée sur Ivy ? essayer de mettre en place un lierre pré-finale POC pourrait être un excellent moyen de détecter les barrages en aval.

non pas que je ne sois pas d'accord avec l'approche consistant à attendre un lierre de pierre plus incrusté avant de verser la sueur du développeur dans live-i18n, je pense qu'un POC à petite échelle pour un seul homme est une petite quantité de sueur pour un immense retour sous la forme de prévoyance et pourrait potentiellement éviter que live-i18n ne soit repoussé en 2020.

Le service d'exécution pour les utilisateurs externes n'est pas encore terminé, nous n'avons que le code qui utilise la fermeture ( goog.getMsg ) car c'est ce dont nous avions besoin pour tester ivy avec les applications Google.
Je vais travailler là-dessus maintenant pour les mois à venir. Cela signifie que vous ne pouvez probablement pas encore utiliser i18n avec ivy.
Le code pour le runtime i18n vient d'être fusionné hier, et le code du compilateur pour i18n devrait être fusionné dans les prochains jours (nous y arrivons !). Ensuite, nous travaillerons sur le nouveau service pour les personnes externes, y compris les nouveaux chargeurs dont j'ai parlé juste au-dessus, et le service pour utiliser les traductions dans votre code.

Quant au changement de langue à la volée, cela nécessiterait toujours un rechargement complet de l'application, ou peut-être un changement d'itinéraire (qui nettoierait tous les composants existants). Je n'essaierais pas encore de travailler sur un POC.

Quant au changement de langue à la volée, cela nécessiterait toujours un rechargement complet de l'application, ou peut-être un changement d'itinéraire (qui nettoierait tous les composants existants). Je n'essaierais pas encore de travailler sur un POC.

c'est juste, ... mais ne nécessitant pas un rechargement complet de l'application (ou tout ce qui accomplit la transparence aux yeux de l'utilisateur final, AKA ne perd pas le magasin, ni l'authentification, ni l'url (enfin ... ne compte pas pour /en/... ) et le tout dans un délai raisonnable) ... c'est toujours le plan, n'est-ce pas ?

@tatsujb Recharger l'application ne recharge pas la page, StackBlitz recharge l'application à chaque modification, pensez-vous que c'est observable à vos yeux ?

Recharger l'application signifie démonter l'application, puis monter l'application dans la même position, ce qui équivaut à une transition SSR-CSR (c'est CSR-CSR), et il ne devrait y avoir aucune tâche asynchrone dans le processus d'amorçage suivant si une architecture de cache appropriée est envisagée.

donc avec cette configuration correcte ; stocker les valeurs variables et l'authentification (ainsi que le montant de défilement sur les divs défilants) resterait-il?

@tatsujb Tant qu'ils sont stockés en dehors de l'instance créée par Angular, par exemple dans une variable lexicale ou une propriété de fenêtre.

@trotyl Comment recharger l'application sans la page ?

@saithis Vous démarrez toujours l'application par platformBootstrap().bootstrapModuleFactory() (ou autre équivalent) impérativement, vous pouvez l'appeler n'importe quand n'importe où, il n'y a pas de magie à l'appel (sauf que Angular CLI a actuellement une limitation pour le remplacement de code, ne devrait plus être un problème dans Ivy).

Amorcer avec impatience au moment de l'invocation du script et le conserver pour toujours (ne pas démonter) n'est qu'une pratique courante pour SPA, mais personne ne vous oblige à le faire.

EDIT : si quelqu'un le fait, il est également nécessaire de détruire le NgModuleRef amorcé pour éviter les fuites de mémoire. Ce sont des questions hors sujet et il vaut mieux en discuter sur un autre canal, mieux vaut suivre la discussion i18n ici.

@trotyl Merci, je ne savais pas que le bootstrap fonctionnait à nouveau.

@ocombe pourriez-vous svp supprimer le spam ici ? et mon commentaire aussi.

1. à @fetis : les personnes comme vous devraient ne plus suivre le problème et s'abonner pour la publication
   

2. à @Andrulko : on s'en fiche

3. à @ angular : comme dit je comprends parfaitement les plaintes ici ! comme nous voulions du lierre pour la v7 pas pour la vX ou ne vendons pas de grosse amélioration pour la v7 alors que vous ne pouviez pas répondre pour cela ou vous le mettrez en 7.x juste pour respecter votre délai... ce n'est pas juste ! oui, l'option devrait être de ne rien annoncer et personne ne se plaindra, c'est aussi une mauvaise idée, vous devez faire votre place dans le cadre. oui nous attendons i18n correct depuis la v2, dans cet aspect obligatoire pour les grandes applications, vous ne pouvez pas vendre angulaire prêt pour les grandes applications comme l'application Web internationale qui contient 50000 chaînes, bien sûr vous n'aimez certainement pas lire ceci mais c'est sans compassion et avec bon foi, à mon humble avis, si nous ne considérons pas i18n et le temps de construction / de développement lent pour tous les autres aspects, je peux dire que angular est génial. une certaine direction devrait changer au sommet, je m'adresse bien sûr aux décideurs. grande exception de notre part (qui critique) car de big-google nous ne pouvions pas faire de grosse erreur comme celle-ci. Je vois des développeurs Google comme des personnes exceptionnelles - intelligentes sans erreur, cela ne devrait pas arriver pour des développeurs expérimentés et pour des équipes de développement comme Google ! mon opinion globale ne vend pas angulaire à 100% pour les grandes applications lorsque l'entreprise la choisit, puis vend/explique à l'entreprise privée ce qui est open source !

4. @ tous, surtout pour ceux qui ne travaillent pas dans une entreprise : je n'aime pas mon commentaire parce que je ne respecte certainement pas l'open source ?!?!, lol va dire ça à mon patron pour attendre. il est prêt (à 100 % et non à 80 %) pour une grande application... nous dépendons !

ceci est mon dernier commentaire ici car nous quittons le navire ! se désabonner + ne pas choisir angulaire dans mon prochain projet (vous pourriez dire que vous êtes gagnant, le projet open source n'a pas besoin de gens comme nous)

Quelle passion ! Juste pour équilibrer... nous avons réécrit notre application en Angular 6, internationalisée en 6 langues, et n'avons ressenti que des inconvénients mineurs. Bien sûr, des temps de construction plus rapides et des traductions à la volée seraient certainement bien mais pas la fin du monde pour nous. Le 98% du framework qui n'est pas i18n est génial. Excellent travail les gars ! Dans l'attente de nouvelles fonctionnalités.

Nous avons également une expérience fantastique avec Angular pour notre nouveau portail d'entreprise. L'i18n est la dernière fonctionnalité manquante dont nous avons besoin car, en Suisse, nous devons prendre en charge quatre langues. Je pense que le problème ici est lié à la communication. Pour la planification du projet, si nous avions eu une meilleure estimation de la sortie d'i18 il y a un an, nous aurions pu le planifier et envisager d'autres possibilités. Cela dit, nous attendons avec impatience toute mise à jour. :-)

À la défense d'angular, vous pouvez assez simplement l'utiliser en production comme celle-ci (meilleure solution que j'ai trouvée)

1. Enveloppez le texte variable traduit dans son propre composant pour déplacer la logique de traduction quelque part

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. Configurez les dossiers de configuration de construction dans angular.json comme

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

1. Configurez le fichier de construction Docker comme celui-ci pour compiler l'application pour différentes langues

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. Utilisez ce nginx.conf pour servir l'application sur des sous-domaines (comme en.site-name.com, ru.site-name.com), où ru dans set $subdomain ru; doit être remplacé par vos paramètres régionaux par défaut

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;
  }
}

Pour plus de détails voir ici
https://github.com/ivavanyuk1993/angular-util/tree/master/src/app/util/shared/route-list
https://github.com/ivanivanyuk1993/titans-shoulders-project/tree/master/container-description/ui-container-description

Je voudrais un pouce bleu pour ce commentaire. Ce n'est peut-être pas parfait, mais c'est toujours le message le plus utile sur ce sujet que j'ai trouvé sur le Web

Bonjour à tous,

J'utilise les traductions i18n pour mon projet. J'ai des doutes dans le domaine suivant :

1. Est-il possible de générer différents fichiers source xlf pour différentes bibliothèques (créés à l'aide de la commande ng generate library libraryName) ?
2. Lors de l'utilisation de l'internationalisation pour select ou pluralization , le fichier source xlf généré crée l'identifiant trans-unit pour les différentes alternatives. Est-il également possible de fournir un identifiant via un modèle pour différentes alternatives ? ​​(comme indiqué dans l'image ci-dessous)
   

S'il vous plaît pouvez-vous m'aider avec quelques réponses.

@learnersLicense :

1. Vous devriez pouvoir extraire un fichier de traduction par projet géré par la CLI. Cela étant dit, les traductions ne fonctionnent pas avec les bibliothèques pour le moment (ce qui signifie que quelqu'un qui utilise votre bibliothèque ne pourra pas charger vos traductions pour cette bibliothèque). C'est en haut de notre liste de tâches pour les prochaines fonctionnalités que nous allons implémenter (avec traductions de code)

1. Je ne pense pas que ce soit possible. Vous pouvez nommer des espaces réservés avec des commentaires spéciaux : <div i18n>Some value: {{ valueA // i18n(ph="PH_A") }}</div> mais je ne pense pas que cela fonctionne avec les expressions ICU, @AndrewKushnir ?
   Vous pouvez faire une demande de fonctionnalité pour cela, ou peut-être ajouter un commentaire à https://github.com/angular/angular/issues/24080 qui semble être similaire (ajouter desc/signification aux expressions ICU)

quelqu'un qui consomme votre bibliothèque ne pourra pas charger vos traductions pour cette bibliothèque

Une façon de contourner ce problème est la suivante :
1) faire extraire la bibliothèque i18n en xliff et traduire
2) expédier les fichiers xliff avec le package de bibliothèque

3) le consommateur extrait également ses propres fichiers xliff
4) le consommateur charge xliff dans l'analyseur XML. supprime toutes les trans-unités provenant de node_modules
5) le consommateur concat c'est xliff avec la bibliothèque xliff

ce qui signifie que quelqu'un qui consomme votre bibliothèque ne pourra pas charger vos traductions pour cette bibliothèque

Peut-être que je comprends mal cette déclaration, mais je sais qu'avec la configuration des traductions pour les applications de mon entreprise, lorsque je crée mes fichiers xlf , ils incluent des clés spécifiées dans les modèles d'autres projets. Celui qui me vient à l'esprit est https://github.com/ng-bootstrap/ng-bootstrap

Cela ne semble pas possible pour le moment :

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

Dans le cadre de ces modifications, cela sera-t-il résolu (ou est-ce que je fais quelque chose de mal) ?

@mikejr83

C'est possible. Il vous suffit d'attribuer la valeur de base de title à title="Go" et non [title]="'Go'"

merci @ocombe et @ewok-janitor pour vos réponses et suggestions . 👍

@ocombe y a-t-il une date provisoire à laquelle les traductions pour la bibliothèque pourraient être disponibles ?

Pas de date pour l'instant. Pour la première version d'ivy, nous essayons simplement d'avoir la parité des fonctionnalités. Nous travaillerons sur les nouvelles fonctionnalités (y compris les traductions de code et le support de la bibliothèque) juste après (ou en fait nous commencerons à travailler dessus avant, mais cela ne sera pas terminé lorsque ivy sera publié en alpha). Il sera disponible avant que le lierre ne devienne la valeur par défaut.

Existe-t-il déjà un correctif pour les fichiers xliff ? https://github.com/angular/angular/issues/17506
Il est impossible d'utiliser le format du tout tant que les références ne sont pas fixes.

@ocombe Avez -vous l'intention de prendre en charge les traductions d'itinéraire ?

ça a été demandé plusieurs fois oui, ce n'est pas un plan immédiat mais c'est sur la liste des choses à faire

Salut, existe-t-il une documentation sur la façon d'utiliser le runtime i18n lorsque Ivy est publié en version bêta ?

@marcelnem , si vous cochez cette URL, tous les points de documentation sont en attente.

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

@ocombe excellent travail que vous faites chez Google maintenant. Angular i18n aurait dû être "quelque chose" comme ngx-translate depuis le début. Je me demandais s'il y aurait un guide de migration, un outil automatisé, une comparaison de fonctionnalités,... pour migrer de ngx-translate vers le style Angular i18n une fois Angular 8/9 sorti ?

salut ocombe
Besoin de vérifier avec vous concernant cette fonctionnalité, celle que vous avez indiquée ci-dessus
Runtime i18n (un bundle pour tous les paramètres régionaux avec AOT) - [y travailler] >> Est-ce toujours en cours, ou est-il sorti

Pourriez-vous me faire savoir, tout travail autour, si c'est toujours en cours
Merci

@ocombe vous avez écrit ci-dessus que les packages de langue doivent être chargés par lacy loading. Sera-t-il également possible de charger les modules linguistiques directement dans le fichier index.html ? Parce que nous avons le cas où notre application s'exécute sur AWS Lambda et les fichiers angulaires compilés sont stockés dans un compartiment S3. C'est en fait déjà une solution de contournement que cela fonctionne, mais nous ne pouvons pas utiliser le chargement en dentelle car Angular ne peut pas charger en dentelle les fichiers d'un autre hôte. Par conséquent, tous les fichiers dont Angular a besoin doivent déjà être inclus dans le fichier index.html (où nous ajoutons l'hôte S3 via un script).

@nidhi8953 c'est toujours WIP, il sera disponible avec ivy, pour l'instant cela ne fonctionne qu'à l'intérieur de google (car nous utilisons Closure Compiler en interne pour les traductions). Le service d'exécution qui gérera les traductions est très expérimental pour le monde extérieur. Si vous voulez tester quelques choses, vous pouvez regarder cet exemple : https://github.com/angular/angular/blob/master/packages/core/test/bundling/hello_world_i18n/index.ts mais vous devez savoir que les fonctions sont toujours privées pour une raison, elles seront renommées et modifiées dans un avenir très proche. L'objectif actuel est de commencer à travailler sur un ensemble solide d'API une fois la v8 sortie (à la fin du mois) et d'itérer autour de cela pour toute la v8 jusqu'à la sortie de la v9, moment auquel l'API devrait être considérée comme stable

@vekunz si nous suivons nos plans actuels, cela devrait être possible oui, car vous devez de toute façon charger le fichier de traduction au démarrage de votre application

@ocombe Pouvons-nous utiliser Ivy (actuellement 8.0.0-rc.3) et implémenter i18n en utilisant la méthode Angular 7 de plusieurs versions ? Ou dois-je m'en tenir à Angular 7 jusqu'à ce que les API i18n pour Ivy soient publiées ? Si possible, j'aimerais vraiment profiter d'Ivy, tout en utilisant l'ancienne méthode d'i18n jusqu'à ce que la nouvelle méthode d'exécution soit disponible.

Mise à jour : Après l'avoir essayé, ni l'extraction ng xi18n (voir #https://github.com/angular/angular-cli/issues/14225) ni la construction avec i18n n'ont d'effet. Aucun fichier .xlf n'est exporté et aucun mot n'est traduit. Mais avec l'option enableIvy définie sur false dans tsconfig.app.json, les deux fonctionnent très bien avec la version 8.0.0-rc.3. Cela signifie que je peux suivre le chemin de mise à niveau d'Angular, ne pas perdre i18n, bénéficier de certains des nouveaux avantages tels que le chargement différentiel et être prêt à activer Ivy une fois que i18n fonctionne.

@jacobbowdoin comme vous l'avez découvert, cela ne fonctionne pas avec le lierre, mais cela fonctionne s'il n'est pas activé.
Je voulais faire fonctionner l'ancien système d'extraction/chargement avec du lierre, mais comme cela n'aurait été que temporaire, il n'a pas été déterminé comme une priorité par l'équipe (ce qui est compréhensible, faire en sorte que les choses obligatoires fonctionnent en premier est la priorité).

Salut @ocombe , nous voulons développer le i18n maintenant, nous ne pouvons donc pas attendre le runtime-i18n. Recommanderiez-vous toujours d'utiliser ngx-translate ? Est-il judicieux de l'utiliser avec i18n-polyfill ? L'utilisation d'i18n-polyfill facilitera-t-elle la migration vers runtime-i18n ?

Si vous utilisez ngx-translate, n'utilisez pas i18n-polyfill. Cela n'a de sens que si vous utilisez angular i18n pour les modèles.
ngx-translate est toujours d'actualité et facile à utiliser. Vous n'avez pas besoin de mettre toute l'infrastructure en place pour prendre en charge plusieurs builds (un par paramètre régional).

Salut @ocombe , y a-t-il une mise à jour de statut sur :

-Exécution i18n
-Utiliser des chaînes de traduction en dehors d'un modèle - #11405

Nous débattons actuellement si nous devons attendre les traductions du code source ou utiliser i18n-polyfill (nous avons déjà commencé avec i18n). Nous pouvons facilement attendre quelques semaines, donc un délai approximatif serait apprécié. Merci beaucoup!

@halilovicedvin dès que le lierre sera la valeur par défaut dans les applications Google, nous commencerons à travailler sur le service d'exécution i18n pour les utilisateurs externes, donc quelque part entre bientôt et la v9
Je n'y compterais qu'après l'été parce que les gens vont prendre quelques jours de repos

@halilovicedvin nous avons commencé avec i18n avec i18n-polyfill il y a quelques semaines et cela fonctionne très bien. J'espère que runtime-i18n sera utilisé de la même manière que i18n-polyfill

@vekunz J'espérais aussi que si nous utilisions ngx-translate avec i18n-polyfill , nous pourrons migrer plus facilement vers runtime-i18n mais après le commentaire de @ocombe (https://github.com/angular/angular/issues /16477#issuecomment-498239301) Je ne sais pas si l'effort supplémentaire pour configurer le polyfill est justifié. Peut-être que nous utiliserons simplement ngx-translate seul.

@vekunz quelle est votre expérience de mise en place ?

@marcelnem vous ne pouvez pas utiliser ngx-translate avec i18n-polyfill. i18n-polyfill est uniquement à utiliser avec angular-i18n.

La configuration de i18n-polyfill a en effet été très simple. Même la documentation n'est pas tout à fait correcte, j'ai compris très vite ce qu'il fallait changer.

@vekunz Je comprends maintenant, merci. Je ne sais pas quel est le but du i18n-polyfill. Devez-vous toujours créer l'application plusieurs fois et la déployer plusieurs fois sous http://myapp/en , http://myapp/de , http://myapp/fr ,... comme avec l'angular i18n officiel ?

@marcelnem oui, vous avez également besoin de plusieurs builds avec i18n-polyfill. Le but est qu'avec angular-i18n, vous ne puissiez utiliser des traductions actuellement qu'à l'intérieur de modèles html et non à l'intérieur de votre code dactylographié. i18n-polyfill étend angular-i18n pour utiliser également les traductions à l'intérieur de votre code dactylographié.
Avec Angular 9 (à venir à l'automne), angular-i18n prendra également en charge les traductions à l'intérieur du tapuscrit, mais en attendant, nous avons besoin de i18n-polyfill pour cela.

@vekunz pouvez-vous donner un peu plus de détails à ce sujet : "Même la documentation n'est pas tout à fait correcte, j'ai compris très rapidement ce qu'il fallait changer." Je vais probablement me pencher sur i18n-polyfill la semaine prochaine, donc toute information serait appréciée. THX

@halilovicedvin @marcelnem J'ai créé un doc pastebin où je le décris, car ce n'est pas le sujet principal de ce GitHub Issue https://pastebin.com/Xib6X6E9

@ocombe En utilisant l'outil xi18n, puis-je restreindre le chemin d'entrée au seul dossier src (pour générer les traductions) plutôt qu'au projet/dépôt complet?

@ocombe Ivy prend-il en charge plusieurs paramètres régionaux avec Angular 8 (juste la définition des paramètres régionaux, pas le fichier de langue ; par exemple pour les canaux de date) ? Parce qu'une autre équipe utilise actuellement Angular avec ngx-translate, mais un composant tiers a besoin des paramètres régionaux corrects. Une option serait d'utiliser le compilateur JIT en mode prod, mais ce n'est pas très agréable. Mais ils ne peuvent pas non plus compiler un nouveau bundle pour chaque langue, car ce serait beaucoup trop.

@vekunz non, vous ne pouvez pas définir plusieurs paramètres régionaux, vous devez définir les paramètres régionaux pour chaque bundle compilé (il peut être défini dans le fichier de configuration cli)
Je sais que ce n'est pas ce que tu voulais entendre, mais c'est comme ça pour l'instant

@ocombe Pouvez-vous s'il vous plaît dire quelque chose, je sais que l'équipe d'Angular ne l'identifie pas comme un problème, mais pensez-vous qu'Angular nous permettra dans un avenir prévisible de changer la langue en cours d'exécution sans recharger l'application, donc avoir la traduction dans un seul paquet et avoir la possibilité de charger les bonnes traductions et de les lier avec les littéraux du texte ?

Avoir un bundle oui, mais les traductions devront être chargées à boostrap (lorsque l'application se charge). Avec l'architecture existante il serait très compliqué de recharger "à chaud" les traductions sans recharger les composants qui utilisent déjà les traductions.
Je ne dis pas que c'est impossible, mais je ne vois malheureusement pas cela se produire dans un avenir prévisible.

Merci @ocombe pour la réponse rapide :) Continuez votre bon travail :+1:

Il y avait quelque part une présentation de @ocombe d'une conférence angulaire (je pense AngularConnect) où il a parlé d'i18n et d'Ivy, et là il l'a très bien décrit, pourquoi c'est si compliqué. Je peux essayer de retrouver la vidéo.

Je pense l'avoir trouvé https://www.youtube.com/watch?v=miG-ghJhFPc

Pour les personnes qui attendent le runtime i18n avec ivy, le plan actuel pour la v9 est d'avoir des traductions fonctionnant avec ivy mais uniquement en tant qu'étape de construction (comme c'est le cas actuellement avec le moteur de vue). Cela signifie qu'il y aura toujours 1 build / locale pour le moment, et qu'il n'y aura pas de traductions de code (uniquement des traductions de modèles).

Dommage. Eh bien, pour ce que ça vaut, merci pour votre travail acharné !

@ocombe maintiendrez -vous toujours le polyfill pour les traductions de code d'exécution ?

si ça casse oui, je n'y ajouterai pas de nouvelles choses cependant

C'est un peu nul qu'i18n soit un citoyen de seconde classe depuis si longtemps... Tout le monde ne travaille pas dans un environnement local anglophone. ):

Eh bien, je suis d'accord, j'essaie de trouver des entreprises pour me sponsoriser afin que je puisse développer de nouvelles solutions i18n puissantes pour Angular (j'ai une tonne d'idées).
Si vous pensez à des personnes qui seraient intéressées, faites le moi savoir sur Twitter (@ocombe) ou par mail ([email protected]) 🙂

@ocombe Je tiens également à vous remercier pour votre travail. 💚 C'est une nouvelle un peu surprenante que vous deviez quitter l'équipe. Comme vous l'avez dit I had to ... , cela m'amène à vous demander directement quelle était la raison principale. Je déteste ces indices indirects et ces conjectures, c'est pourquoi une question aussi directe pour vous.

J'étais un sous-traitant externe travaillant avec l'équipe Angular et non un employé à temps plein de Google. En tant que tel, mon contrat peut se terminer à tout moment en fonction des besoins de l'équipe.
Ils recrutent de nouvelles personnes en interne pour aider au projet et je suis convaincu qu'ils trouveront les bonnes personnes pour aider avec i18n et d'autres sujets, vous n'avez donc pas à vous soucier de l'avenir d'Angular :visage_légèrement_souriant : c'est juste un recul temporaire

@ocombe Merci pour votre explication.

Quelqu'un peut-il me dire comment utiliser i18n (i18n-polyfill) en dehors de la classe comme des énumérations ou des tableaux const ou quelque chose comme des fichiers .model.ts ?

Pour les constantes, je les mets toujours dans une classe. Je ne connais pas d'alternative :/

@ocombe Merci beaucoup pour tout votre travail acharné avec i18n pour Angular avec ngx-translate, i18npolyfill et avec l'équipe Angular.
Nous utilisons quotidiennement votre travail pour fournir des traductions à nos utilisateurs, comme l'exige toute application non triviale.
Bonne chance dans ce que vous faites pour aller de l'avant.

Pour les constantes, je les mets toujours dans une classe. Je ne connais pas d'alternative :/

Hmm .. si je les déplace vers la classe, je dois rendre la variable statique à utiliser. Mais je ne peux pas utiliser i18n pour une variable statique.

classe d'exportation Exemple {
constructeur (i18n privé : I18n) {}
variable statique = i18n('texte'); // Je ne peux pas utiliser i18n ici car il n'est pas statique de la classe Exemple
}

Triste nouvelle... cela "affaiblit" Angular... Comme les autres disent, il ne reste que le grand merci à @ocombe pour le super travail, bonne chance !

Je suis curieux, quels sont les inconvénients d'utiliser ngx-translate ? Il semble qu'il est capable d'exactement la fonctionnalité que les gens recherchent

Je dirais que les inconvénients sont les suivants :

• augmente la taille du bundle (lib externe + traductions en tant que fichiers externes au lieu de remplacer le code au moment de la construction)
• pas officiel (si je meurs, la bibliothèque est interrompue, et pas le même niveau de support)
• ne prend pas en charge xliff/xmb (mais prend en charge json et d'autres formats via des plugins, et on pourrait créer un plugin xliff/xmb pour le supporter)
• peut avoir des comportements bogués lors du chargement / fractionnement paresseux des traductions (je n'ai jamais pu résoudre ce problème)
• la syntaxe est plus compliquée par rapport à l'implémentation officielle
• performance (le chargement initial des traductions peut faire disparaître le texte pendant 1s, et plus de pression sur la mémoire car je dois surveiller le contenu à l'exécution pour voir si quelque chose a changé)

Cela étant dit, cela semble être assez bon pour beaucoup de gens 🙂

Il est curieux de voir comment angular promeut et investit dans l'accessibilité mais n'inclut pas les langues dans ce package. On a vraiment l'impression que c'est une décision prise dans un environnement monolingue.

Venant d'un environnement où nous devons généralement servir 3 à 4 langues de manière interchangeable, j'attends patiemment la sortie de cette fonctionnalité depuis son annonce avec ses avantages évidents par rapport à l'utilisation d'une bibliothèque externe. Avec cette nouvelle, je vais devoir revoir complètement notre stratégie de gestion des traductions.

@ocombe Pas de chance que Google ne t'embauche pas en tant qu'entrepreneur ?😉

@DmitryEfimenko Nous utilisons actuellement ngx-translate et en sommes très satisfaits.

@ocombe quelle est la probabilité que Google accepte cette fonctionnalité d'un développeur/communauté externe ? Je pense qu'on attend tropoooo longtemps.

si vous êtes sérieux avec cela et que vous voulez passer du temps à travailler dessus, alors je dirais qu'il y a de fortes chances qu'ils acceptent de l'aide pour travailler sur cette fonctionnalité

si vous êtes sérieux avec cela et que vous voulez passer du temps à travailler dessus, alors je dirais qu'il y a de fortes chances qu'ils acceptent de l'aide pour travailler sur cette fonctionnalité

@ocombe @IgorMinar J'aimerais fournir du travail bénévole à Ivy i18n, faites-le moi savoir s'il y a des chances.

si vous êtes sérieux avec cela et que vous voulez passer du temps à travailler dessus, alors je dirais qu'il y a de fortes chances qu'ils acceptent de l'aide pour travailler sur cette fonctionnalité

Je suis prêt à contribuer mais je ne connais absolument pas l'étendue et la complexité des tâches. Pouvons-nous prendre la liste dans le message d'origine comme nos spécifications/exigences ?

Non, cette liste est désormais obsolète.
Je ferai savoir à l'équipe que vous êtes tous les deux intéressés afin que nous puissions voir comment organiser cela.

@ocombe je pense que c'est plus que 2 d'entre nous.

Ce dont nous avons besoin des équipes angulaires sont

• une liste d'exigences/des spécifications
• estimation approximative de la complexité
• 1-2 mentors pour la communication

avec cette communauté pourrait organiser le développement et répartir les tâches

Il y a ce que je sais sur https://hackmd.io/UfFN_wyVT-Ob1p70nA3N_Q?view

@fetis Ce n'est peut-être pas une bonne idée de trop diviser le travail, la communication et le partage de contexte coûtent également cher, en particulier pour certains travaux de base présentant un risque élevé de conflits.

Toujours surpris, XLIFF est répertorié comme un pro (ou plutôt, son absence pour ngx-translate est un inconvénient). Google Translate et d'autres services Google semblent utiliser des fichiers ARB, qui sont une représentation JSON des chaînes de traduction. Par exemple, nous avons construit nos applications mobiles avec Flutter/Dart, où l'INTL est implémenté avec des fichiers ARB. Ce serait bien si l'équipe Angular, lorsqu'elle examine cela, en tient compte pour une meilleure interopérabilité avec d'autres éléments de l'écosystème Google.

Ce n'est peut-être pas une bonne idée de trop diviser le travail, la communication et le partage de contexte coûtent également très cher, en particulier pour certains travaux de base ayant un risque élevé de conflits.

Je suis d'accord mais je ne pense pas que tout cela puisse être livré par une seule personne dans un délai raisonnable. La portée est trop grande

Ce n'est peut-être pas une bonne idée de trop diviser le travail, la communication et le partage de contexte coûtent également très cher, en particulier pour certains travaux de base ayant un risque élevé de conflits.

Je suis d'accord mais je ne pense pas que tout cela puisse être livré par une seule personne dans un délai raisonnable. La portée est trop grande

@fetis je peux travailler avec toi. Nous voulons vraiment utiliser angular i18n dans nos projets, mais c'est très limité.

Je ferai savoir à l'équipe que vous êtes tous les deux intéressés afin que nous puissions voir comment organiser cela.

@ocombe des commentaires de l'équipe Angular ?

Je leur ai fait savoir et ils semblaient intéressés, mais ils doivent élaborer un plan concret pour tout cela avant de pouvoir accepter une aide extérieure (sinon vous n'allez probablement pas travailler sur ce qui est nécessaire).
@petebacondarwin prendra désormais le relais

Salut @ocombe , je parcourais les commentaires et j'ai à peu près compris qu'il n'y avait toujours pas de disposition pour créer des identifiants dynamiques pour la balise i18n pendant que nous les utilisons dans *ngFor. Existe-t-il une autre option ou solution de contournement ? Ou je dois utiliser ngx-translate uniquement.

@swapnilvaidankar Je ne pense pas qu'il existe une solution de contournement, non

@swapnilvaidankar - pouvez-vous expliquer ce que vous entendez par là ?

créer des identifiants dynamiques pour la balise i18n pendant que nous les utilisons dans *ngFor

Comme nous le savons, pour traduire le texte statique dans une autre langue, nous devons utiliser l'attribut i18n dans la balise d'élément HTML comme ci-dessous,

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

qui génère l'extrait de fichier xlf comme ci-dessous et nous pouvons définir la cible pour n'importe quelle langue. Ici, j'ai traduit pour le français comme ci-dessous,

  <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>

Mais en cas de liste déroulante, il semble difficile d'utiliser l'attribut i18n.
Par exemple, si je veux afficher la liste des produits tels que les cartes de visite, les dépliants et les livrets dans une liste déroulante ou une liste simple, comment puis-je générer l'identifiant dynamique pour letag donc je peux traduire les noms des produits en français ou dans toute autre langue.

j'ai essayé de cette façon,

• 
  {{ produit }}
  

qui génère l'extrait de fichier xlf comme ci-dessous et vous ne savez pas comment l'utiliser pour traduire le nom du produit dans d'autres langues en utilisantétiqueter

  <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>

Le problème ici, si vous pouvez voir l'identifiant dansla balise est 'produit' uniquement. Cependant, je m'attendais à ce que les identifiants soient générés dynamiquement selon la liste des produits qui seront disponibles dans la liste déroulante.

Vous ne savez pas comment y parvenir lorsque vous traitez avec du contenu dynamique ou une liste de contenu.

Désolé pour l'explication détaillée.
J'espère que vous avez compris le problème ici.

Merci,
Échange

Pouvez-vous ouvrir un sujet pour cela s'il vous plait ? Ce n'est pas vraiment le sujet ici et si quelqu'un d'autre cherche la même chose, il sera plus facile de le trouver

@swapnilvaidankar Les attributs i18n sont destinés à la traduction de texte statique et non au contenu dynamique. Dans votre exemple, les "produits" proviennent soit de votre code source (sont définis dans votre fichier ts) et vous devez utiliser ngx-translate (ou avoir traduit les noms de produits directement dans le fichier ts), soit proviennent d'une requête Http alors les noms de produits traduits doivent être fournis par votre backend.

Je ne pense pas que nous ayons besoin d'un nouveau numéro pour cela. C'est juste une demande de traductions d'exécution dans les fichiers TS qui a déjà été demandée à plusieurs reprises.

@swapnilvaidankar si le nombre d'options est limité et que vous le savez déjà, vous pouvez créer un composant avec un simple ngSwitch qui rend le texte. Nous utilisons cette solution de contournement, fonctionne comme un charme.

@fetis - le problème est qu'il est très facile pour ces problèmes généraux d'être détournés dans des discussions sur des choses spécifiques. La création d'un nouveau problème fournit un nouveau fil pour continuer cette discussion sans distraire celle-ci.

@fetis Ouais, j'ai vu ce problème plusieurs fois dans de nombreux endroits, mais je n'ai trouvé aucune solution appropriée. Je suis également tombé sur ngSwitch mais pas la solution appropriée dans mon cas. Cependant merci pour la solution de contournement.

@ocombe Je crois que je dois publier cela comme un problème ailleurs pour en discuter plutôt qu'ici. 👍

Merci à tous pour les réponses.

@petebacondarwin @swapnilvaidankar voici le problème https://github.com/angular/angular/issues/11405 que vous recherchez
depuis 2.0.0-rc.6 (!) d'ailleurs

Bonjour @ocombe , ce problème est-il toujours d'actualité ? On dirait qu'Ivy va être la valeur par défaut sur Angular 9, donc je me demande quel est le statut d'i18n ? Pourriez-vous s'il vous plaît estimer quand il pourrait être prêt pour la production ? Avec Angulaire 9, 10, 11 ? Si ce n'est pas avec Angular 9, Angular 9 (et Ivy) sera-t-il livré sans i18n ou utilisera-t-il l'ancien i18n ?

Quelques informations supplémentaires sur l'état actuel peuvent être trouvées dans ce numéro (https://github.com/angular/angular/issues/11405). Commentaires à lire dans ce numéro sur l'état actuel :

• 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

Cela vaut également la peine d'être vérifié.

Bien que nous basculions le commutateur dans la v9 afin que la valeur par défaut soit d'utiliser ivy, nous nous attendons à ce qu'un certain nombre de scénarios ne fonctionnent pas entièrement et que ces projets restent avec le moteur de vue pour le moment.
Nous travaillons pour que i18n soit opérationnel pour la version v9.0.0, mais ce sera serré.

Quel est l'état actuel de "Runtime i18n (un bundle pour toutes les locales)" ?

@Ivajkin - désolé que ce problème ne soit pas mis à jour.

"Runtime i18n" est une fonctionnalité fréquemment demandée, mais elle peut signifier différentes choses pour différentes personnes.
Dans la nouvelle approche i18n $localize , il sera possible de faire la traduction réelle au moment de l'exécution.

L'exécution peut en fait être assez compliquée si vous ne traduisez pas simplement tous les messages possibles avant le démarrage de l'application Angular. Si vous faites cela, la nouvelle approche pour compiler la traduction du temps pourrait bien être ce dont vous avez besoin.

Dans le nouveau i18n, la traduction se produit à la toute fin de votre pipeline de construction - pas dans le compilateur Angular - cela signifie que vous devriez être en mesure de fournir des messages non traduits dans les bibliothèques, etc. et de ne faire la traduction que lorsque vous construisez l'application finale.

Tout est en préparation pour la v9.0.0.

Consultez https://github.com/angular/angular/tree/master/packages/localize pour voir où nous en sommes.

@petebacondarwin Cela vous dérangerait-il d'élaborer un peu sur la nouvelle traduction du temps de compilation ? Cela nous permettra-t-il de créer un seul bundle (avec AOT) qui fonctionne pour tous les paramètres régionaux ?

Dans la nouvelle approche, au lieu de faire la traduction à l'intérieur du compilateur Angular, nous "marquons" simplement les messages qui doivent être traduits via un gestionnaire de balises de chaîne global $localize . Ces chaînes étiquetées survivent à toutes sortes de regroupements et de minifications, de sorte qu'à la fin de votre pipeline de construction, elles sont toujours là et détectables. Ces fichiers pourraient être le bundle de votre bibliothèque que vous envoyez à une autre équipe pour l'inclure dans leur application !

Nous avons maintenant deux options :

a) exécuter un outil qui identifie statiquement ces messages balisés et les remplace par des traductions. Cela supprime efficacement les références $localize du JavaScript et vous laisse avec un ensemble de code minimal pour la distribution. Cet outil "d'intégration du temps de compilation" peut prendre un certain nombre de traductions et générer une copie de votre bundle pour chaque langue que vous traduisez. Puisqu'il peut être exécuté à la toute fin de votre pipeline de build, il évite d'avoir à exécuter d'autres aspects de votre build pour chaque langue que vous prenez en charge.

b) permettre aux balises $localize de se retrouver dans le code exécuté dans le navigateur et utiliser une implémentation de $localize pour traduire les messages au moment de l'exécution. L'inconvénient de cette approche est que la charge utile du navigateur est plus importante puisqu'elle doit contenir les appels $localize mais aussi l'implémentation de la traduction $localize . Vous devez également envoyer les traductions elles-mêmes au navigateur. L'un des avantages de cette approche pourrait être de prendre en charge le chargement différé des traductions au moment de l'exécution. Mais on peut soutenir que faire la traduction sur le serveur http (ou le serveur de construction) rend l'expérience d'exécution plus efficace.

Option d'exécution b) s'il vous plaît. Nous pourrions charger des traductions sous forme de fichiers JSON et changer de langue au moment de l'exécution, comme nous le faisons actuellement avec ngx-translate .

Merci pour l'explication. Je comprends que l'approche a) est plus "angulaire" mais le grand avantage de l'approche b) (et du chargement paresseux en général) est également la possibilité de définir/modifier dynamiquement les traductions par les utilisateurs (les traductions modifiées pour les applications pourraient être utilisées immédiatement) . Si je comprends bien, tout petit changement de traduction dans l'approche a) signifierait une nouvelle reconstruction.

C'est le même avantage que de passer de pages générées statiquement avec des composants angulaires prédéfinis à des modèles générés par l'utilisateur contenant les composants angulaires définis par le programmeur comme souhaité par l'utilisateur (le modèle ainsi défini serait également chargé à partir de la base de données... )

Vous avez peut-être aussi pensé à la possibilité que, par défaut, l'approche a) soit utilisée lors du chargement. Si une demande de traduction d'exécution survenait (par exemple, le backend commencerait à envoyer des traductions plus récentes), les blocs marqués (contenant du texte statique jusqu'à présent) commenceraient à être explorés et remplacés dynamiquement, comme dans l'approche b). Ainsi b) ne sera activé que si nécessaire et toutes les parties traduisibles seront préparées selon la procédure a). Je comprends qu'une telle approche serait plus lourde que l'approche b) elle-même et n'est certainement pas directement réalisable de cette manière, mais cela serait plus proche des besoins réels des utilisateurs.

Aux options que vous avez énumérées, je suis prêt à sacrifier environ 25 % des performances de l'application dans certains cas pour obtenir une telle fonctionnalité dynamique (bien sûr, je n'utiliserais pas cette approche dynamique partout). Donc, si le modèle localisé AOT était rendu en 0,4 seconde, dans le cas d'un modèle dynamique s'il était généré en 0,5 seconde, je le considérerais toujours comme acceptable dans les applications où j'ai besoin de telles réponses immédiates au changement de traduction.

@demisx les deux approches seront disponibles avec la v9, mais seule l'option a) sera entièrement prise en charge dans un premier temps (pour la rétrocompatibilité), de nouvelles choses pourraient être développées pour l'option b) avant qu'elle ne soit pleinement approuvée par l'équipe Angular.
Ma bibliothèque Locl fournira quelques aides pour l'option b) lorsque la v9 sera publiée afin que tout le monde puisse l'utiliser, jusqu'à ce que l'équipe Angular comble cet écart

Sachez qu'une telle traduction d'exécution ne serait pas "réactive" dans le sens où une fois qu'un composant a été rendu, il ne serait pas possible de modifier son texte dynamiquement, même si une nouvelle traduction était chargée.

Les messages traduits sont statiques par rapport aux chaînes balisées $localize . Donc, le composant devrait être rendu à nouveau. Et selon la mise en cache des modèles dans IVY, il se peut qu'un nouveau rendu ne soit même pas suffisant.

C'est l'une des raisons pour lesquelles la traduction à l'exécution est délicate à mettre en œuvre puisque son comportement ne serait pas nécessairement intuitif.

En ce qui concerne l'approche hybride consistant à commencer par une traduction statique dans la construction, puis à ajouter une traduction d'exécution ultérieurement. Cela pourrait être faisable si l'intégration au moment de la compilation ne supprimait pas les balises $localize mais mettait simplement à jour les parties littérales de chaîne modélisées. Cependant, cela entraînerait le coût du temps de compilation plus le coût supplémentaire de la taille du bundle.

L'exécution ng xi18n sur Angular 9 RC1 renvoie "Nous sommes désolés mais i18n n'est pas encore implémenté dans Ivy", mais le journal des modifications indique qu'il y a _some_ support i18n implémenté maintenant. Je suppose que les fichiers de traduction doivent être mis à jour manuellement pour l'instant ?

@neil-119 Actuellement, l'extraction n'est pas prise en charge en mode ivy. Vous devez toujours désactiver Ivy pour exécuter l'extraction. Mais vous pouvez ensuite le réactiver pour consommer les fichiers de traduction extraits.

J'espère qu'il est prévu d'inclure l'extraction dans la version finale v9.

@ neil-119 Angular CLI devrait automatiquement utiliser VE pour l'extraction. Vous ne devriez rien faire pour que cela fonctionne. Nous testons également cela, donc je suis surpris qu'il soit cassé. Pouvez-vous ouvrir un problème avec une repro s'il vous plaît?

Actuellement, l'extraction n'est pas prise en charge en mode lierre.

ou non, c'est un bouchon de spectacle. Actuellement, nous avons un processus automatisé avec extraction de chaînes. Comment pouvons-nous migrer vers Ivy, si nous ne pouvons pas extraire les traductions automatiquement ?
Manipuler sconfig.json every time ? Cela ne me semble pas bon.

@fetis - je me suis trompé. Si vous utilisez CLI, l'appel ng xi18n devrait fonctionner comme prévu, même lorsque Ivy est activé.

@petebacondarwin merci. Je vais essayer Ivy dans nos projets en cours, alors j'espère que je le confirmerai bientôt

Bonjour, j'ai essayé d'utiliser dans mon composant (angular 9.0.0-rc.1)

$localize `some string to localize`;

trouvé en tant que doc dans le code source de @angular/localize/init.

Lorsque j'essaie de construire comme d'habitude pour ma langue, j'obtiens cette erreur
No translation found for "4145296873012977836" ("some string to localize").

Comment puis-je fournir une traduction pour cette chaîne ?
Ce que j'attends, c'est que ng xi18n générera le fichier .xlf avec également ce texte à partir du code du composant. C'est bien ou j'ai raté quelque chose ?

Salut @Ks89 - l'extraction des messages du code d'application (plutôt que des modèles) n'est pas prise en charge pour la v9.
Mais vous pouvez contourner cela si vous êtes sournois. Le 4145296873012977836 est l'identifiant du message, donc si vous fournissez une traduction dans votre fichier de traduction avec cet identifiant, il sera utilisé lors de la traduction.

@petebacondarwin quand cette fonctionnalité sera ajoutée à Angular ?
Je pense qu'il est vraiment important de rendre les traductions d'exécution dans le composant vraiment utiles.

Lorsque j'envoie mon fichier .xlf à un traducteur, je m'attends à ajouter toutes les chaînes rapidement, puis à appliquer très facilement le résultat à l'application.

Merci d'avoir répondu

Je m'y attendais en 9.1

Si nous avons un moyen de forcer l'intégralité du rendu de l'application, quel que ChangeDetectionStrategy pour chaque composant, il est si facile de résoudre ces problèmes dynamiques.

@petebacondarwin Angular 9 est maintenant disponible avec la nouvelle fonction de balise $localize, mais sans extraction des messages. Vous avez dit précédemment que nous pouvions nous attendre à cela dans Angular 9.1. Cette prévision est-elle toujours valable et pouvons-nous nous attendre à ce que l'API $localize soit stable ?

Vous pouvez extraire des traductions à partir de modèles.
Si vous souhaitez également utiliser $localize dans votre code, vous devriez jeter un œil à Locl : https://github.com/loclapp/locl/
@locl/cli vous permettra d'extraire du code et des modèles

@vekunz - les prévisions sont toujours valables. De plus, comme le souligne @ocombe , le mécanisme d'extraction de traduction CLI actuel fonctionne très bien pour toute traduction qui se trouve dans un modèle angulaire (c'est-à-dire ce qui est marqué par les balises i18n ). La seule chose que vous ne pouvez pas extraire à l'aide des outils de base pour le moment, ce sont les appels à $localize dans votre propre code (par exemple, dans un service ou un composant).

L'appel $localize lui-même est une API stable.

L'outil qui effectue les traductions et l'extraction (en particulier au moment de la compilation) n'est toujours pas public. Mais ce n'est pas un problème à moins que vous ne prévoyiez de construire votre propre outillage autour de lui (comme le fait @ocombe à Locl !).

Merci @petebacondarwin , avec cela, nous pourrions dupliquer les textes du code dans un modèle de composant "caché" pour l'extraction. Ensuite, l'extraction et la traduction devraient fonctionner toutes les deux, n'est-ce pas ?

@ocombe Avec la prévision que l'extraction fonctionne avec Angular 9.1, notre responsable ne paierait pas pour votre solution. Surtout parce que nous n'avons pas besoin de changer de langue en direct et d'itinéraires traduits.

nous pourrions dupliquer les textes du code dans un modèle de composant "caché" pour l'extraction

Oui en effet, cette solution de contournement fonctionnerait pour le moment.

Je suis confus : la traduction d'exécution sera-t-elle également possible dans 9.1 ? Ou simplement l'extraction en dehors des modèles ? Ou aucun de ceux-ci?

Pour moi, les traductions d'exécution seraient une fonctionnalité qui tue. Déployer plusieurs bundles et forcer l'utilisateur à recharger toute la page n'est pas une bonne ergonomie je pense.

@JustDoItSascha
J'ai créé une démo simple, qui démontre la traduction d'exécution.
https://stackblitz.com/edit/ivy-vjqzd9?file=src%2Fapp%2Fapp.component.ts

Salut! J'essaie d'appeler loadTranslations dans main.ts car les chaînes sont traduites pendant que JavaScript analyse les importations, mais cela ne suffit pas.

main.ts importe AppModule qui importe AppComponent (où j'utilise $localize ).

Pour que ça marche je fais :

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

Maintenant, cela fonctionne mais entraîne l'inclusion du bundle "complier.js" d'Angular dans le bundle du fournisseur.

Un moyen d'éviter ça ? Merci

Actuellement, loadTranslations doit être appelé avant le démarrage de l'application, donc cela peut être fait dans polyfills.ts . Et si vous souhaitez charger un autre ensemble de traductions, vous devez alors recharger la page. Si vous voulez comprendre un peu plus pourquoi, j'ai écrit https://blog.ninja-squad.com/2019/12/10/angular-localize/ pour l'expliquer.

Actuellement, loadTranslations doit être appelé avant le démarrage de l'application, donc cela peut être fait dans polyfills.ts .

C'est encore pire que cela, il doit être appelé avant l'importation de tout fichier de module, c'est pourquoi cela fonctionne si vous le mettez dans polyfills.ts (qui est exécuté avant le fichier principal de l'application), mais si vous voulez l'utiliser dans votre "main" alors vous devez utiliser un import(...) dynamique pour le module

@vekunz c'est une bonne raison de ne pas utiliser ma lib pour l'instant 😊 cela étant dit Locl n'est pas qu'une question d'extraction, j'ai l'intention d'ajouter plein d'autres outils pour simplifier i18n

Y a-t-il une intention d'implémenter le runtime i18n dans Angular? Nous attendions la fonctionnalité depuis près de trois ans et maintenant Ivy est là et elle n'est encore qu'à moitié cuite.

Y a-t-il une intention d'implémenter le runtime i18n dans Angular? Nous attendions la fonctionnalité depuis près de trois ans et maintenant Ivy est là et elle n'est encore qu'à moitié cuite.

Je crois comprendre qu'Ivy, à bien des égards, est un catalyseur pour les choses à venir. Il n'est pas surprenant que l'aiguille i18n ait bougé incroyablement avec la sortie d'Ivy, mais cela devrait libérer le potentiel de grands changements sur la route. Cela a été ma lecture de celui-ci, et mon espoir, de toute façon.

@Karasuni - Je pense que nous devons clarifier ce que la traduction d'exécution signifie réellement pour le framework Angular de base car il y a pas mal de confusion à ce sujet.

Les modifications que nous avons apportées à la v9 impliquent la traduction basée $localize . L'objectif principal était de découpler la traduction du compilateur Angular, afin qu'il permette un certain nombre d'améliorations intéressantes :

Le premier, immédiatement disponible pour tous les utilisateurs de la v9, est d'accélérer la génération d'applications traduites. Auparavant, l'intégralité du pipeline de build devait être exécutée pour chaque langue dans laquelle vous vouliez traduire votre application. Désormais, la compilation principale de votre application ne doit être exécutée qu'une seule fois et le processus de traduction final, qui est beaucoup plus court, est exécuté pour chaque langue sur la sortie de la construction. Pour prendre en charge cela, il y a le nouveau package @angular/localize , des modifications à l'intérieur du compilateur Angular et toute une charge de travail à l'intérieur de la CLI Angular pour rendre cela aussi transparent et transparent que possible.

Deuxièmement, étant donné que les balises $localize peuvent être laissées dans le code distribué, il est désormais également possible de faire la traduction dans le navigateur (au moment de l'exécution, plutôt qu'au moment de la compilation). C'est ce que nous entendons dans le framework Angular de base en tant que traduction d'exécution. Mais s'il vous plaît, notez que le résultat final de ceci est effectivement le même que la traduction au moment de la compilation. La traduction n'a lieu qu'une seule fois ; si vous souhaitez changer la langue au moment de l'exécution, vous devez redémarrer l'ensemble de l'application (par exemple via un rechargement). Cela a l'avantage de permettre au projet de déployer un seul distribuable avec de nombreux fichiers de traduction, ce qui est utile dans un petit nombre de cas d'utilisation où vous ne souhaitez pas générer toutes les différentes traductions à l'avance. Il y a quelques problèmes délicats concernant le chargement des traductions assez tôt, comme l'ont souligné @ocombe et d'autres ici. Vous pouvez envisager https://www.locl.app/ pour plus d'aide pour ce faire.

Notez que cette traduction "d'exécution" peut également être utilisée sur des routes chargées paresseusement, il peut donc être possible d'avoir différentes routes dans différentes langues selon la façon dont vous configurez les choses.

Puisqu'il n'y a pas une seule approche de ce chargement de traductions qui fonctionne pour tous les scénarios, nous n'avons pas encore intégré cela dans la CLI ni fourni d'API publiques stables pour le prendre en charge. Une fois que nous aurons une meilleure compréhension des cas d'utilisation, nous pourrons peut-être ajouter plus de support pour cela. En attendant, des choses comme Locl pourraient vous aider si vous ne voulez pas vous aventurer à le résoudre par vous-même.

Enfin, notez que le changement dynamique des chaînes traduites au moment de l'exécution n'est spécifiquement pas pris en charge (par conception) par le framework Angular de base. Accrocher les chaînes traduites au système de détection de changement d'Angular mettrait trop de pression sur la plupart des applications et ruinerait les performances. D'après mes interactions avec la communauté, je n'ai vu pratiquement aucun scénario dans le monde réel où cela est réellement nécessaire au-delà du redémarrage de l'application lors du changement de langue. S'il s'agit d'une exigence pour votre application, vous pouvez y parvenir en utilisant un canal personnalisé sur vos chaînes dans des modèles qui extrait les traductions, et peut-être même appelle $localize à la volée pour traduire, mais cela ne ressemble pas à ce serait très performant. Sinon, vous pourriez envisager une approche plus dynamique comme https://netbasal.gitbook.io/transloco/.

Les principaux changements à venir dans la prochaine version mineure d'Angular seront l'amélioration de l'extraction de la traduction, qui pourra identifier et extraire les chaînes localisées du code TS - actuellement, l'extraction CLI ne gère que les chaînes localisées dans les modèles.

Les modifications visant à améliorer la traduction d'exécution, comme décrit ci-dessus, n'apparaîtraient pas avant la version 9.1 au plus tôt.

Enfin, notez que le changement dynamique des chaînes traduites au moment de l'exécution n'est spécifiquement pas pris en charge (par conception) par le framework Angular de base. Accrocher les chaînes traduites au système de détection de changement d'Angular mettrait trop de pression sur la plupart des applications et ruinerait les performances. D'après mes interactions avec la communauté, je n'ai vu pratiquement aucun scénario dans le monde réel où cela est réellement nécessaire au-delà du redémarrage de l'application lors du changement de langue.

Je peux me tromper, mais dans ce seul fil de discussion, de nombreuses personnes ont expressément manifesté leur intérêt pour la possibilité de changer la langue en direct, lors de l'exécution, sans avoir à reconstruire ou à recharger l'application. Ou est-ce que tout le monde ici a une définition différente de runtime translation ?

Je ne veux pas recharger une application juste pour changer de langue. Par exemple, lorsqu'un utilisateur est sur une page avec un formulaire, un rechargement complet de la page pour un changement de traduction sera choquant pour l'utilisateur.

Juste pour être clair. Ce que je voulais dire, c'est que beaucoup de gens sont venus me dire qu'ils avaient absolument besoin d'un changement de langue en direct dans leur application. Mais quand on creuse les raisons, il s'avère que ce n'est pas le cas. Je ne dis pas qu'il n'y a pas de scénarios qui l'exigent, mais d'après mon expérience de l'année dernière, j'en ai rencontré très peu.

Question : pourquoi un utilisateur aurait-il besoin de changer de langue lorsqu'il accède à un formulaire particulier sur votre application ?

Je ne pense pas que la commutation en direct soit également nécessaire. À quelle fréquence changez-vous la langue d'un site Web ? Généralement une fois, au maximum. Et pour cette fois, un rechargement de page n'est pas si critique. Comme @petebacondarwin l' a dit, presque tous les scénarios de commutation en direct ne sont pas des scénarios pertinents du monde réel, mais seulement "agréables à avoir".

Ou est-ce que tout le monde ici a une définition différente de la traduction d'exécution ?

J'ai absolument besoin de traductions d'exécution. Nos clients doivent pouvoir modifier et mettre à jour les traductions sur le terrain, pas seulement sur le serveur de build. Donc, le temps d'exécution, par opposition au temps de compilation.

Le changement réel de langue après le chargement de la page est un avantage.

Juste pour être clair. Ce que je voulais dire, c'est que beaucoup de gens sont venus me dire qu'ils avaient absolument besoin d'un changement de langue en direct dans leur application. Mais quand on creuse les raisons, il s'avère que ce n'est pas le cas. Je ne dis pas qu'il n'y a pas de scénarios qui l'exigent, mais d'après mon expérience de l'année dernière, j'en ai rencontré très peu.

Question : pourquoi un utilisateur aurait-il besoin de changer de langue lorsqu'il accède à un formulaire particulier sur votre application ?

Vous avez peut-être raison de dire que ce n'est pas une exigence solide. Je pourrais essayer de déployer des traductions au chargement, mais cela transformera complètement l'expérience utilisateur des applications qui sont actuellement capables de changer de langue de manière dynamique - sans recharger ni changer de position dans la page - avec une bibliothèque externe. Les traductions ont été un sujet brûlant pendant très longtemps.

J'ai une question importante : les fichiers de traduction peuvent-ils être chargés de manière asynchrone ? Toutes mes traductions sont stockées dans une base de données car il est important de pouvoir les mettre à jour sans les reconstruire.

oui, ils peuvent être chargés de manière asynchrone, mais vous devez retarder le démarrage de votre application jusqu'à ce qu'ils aient été chargés

Juste pour être clair. Ce que je voulais dire, c'est que beaucoup de gens sont venus me dire qu'ils avaient absolument besoin d'un changement de langue en direct dans leur application. Mais quand on creuse les raisons, il s'avère que ce n'est pas le cas. Je ne dis pas qu'il n'y a pas de scénarios qui l'exigent, mais d'après mon expérience de l'année dernière, j'en ai rencontré très peu.
Question : pourquoi un utilisateur aurait-il besoin de changer de langue lorsqu'il accède à un formulaire particulier sur votre application ?

Vous avez peut-être raison de dire que ce n'est pas une exigence solide. Je pourrais essayer de déployer des traductions au chargement, mais cela transformera complètement l'expérience utilisateur des applications qui sont actuellement capables de changer de langue de manière dynamique - sans recharger ni changer de position dans la page - avec une bibliothèque externe. Les traductions ont été un sujet brûlant pendant très longtemps.

Techniquement, vous pouvez recharger l'intégralité de l'application tout en gardant l'utilisateur là où il se trouvait.
Vous avez "juste" besoin d'avoir une application pilotée par l'état (avec ngxs, ngrx ou toute autre bibliothèque de gestion d'état) qui est stockée quelque part et récupérée au démarrage.

Le seul truc serait de garder la position de défilement mais c'est faisable aussi.

@petebacondarwin Je dois dire que je suis d'accord avec vous. Je ne connais pas de vrais utilisateurs finaux (à l'exception des testeurs en phase de développement) qui changent une application en permanence entre les langues lors de son utilisation. Bien sûr, ils le font probablement au début s'ils l'ouvrent dans un autre d'une manière ou d'une autre, mais plus tard, c'est un cas rare.

Ou est-ce que tout le monde ici a une définition différente de la traduction d'exécution ?

J'ai absolument besoin de traductions d'exécution. Nos clients doivent pouvoir modifier et mettre à jour les traductions sur le terrain, pas seulement sur le serveur de build. Donc, le temps d'exécution, par opposition au temps de compilation.

Le changement réel de langue après le chargement de la page est un avantage.

Je ne suis pas sûr de ce que font vos clients, mais "l'édition des traductions en direct sur le site Web de production" ne ressemble pas à un scénario courant.

Je ne vois pas le changement de langue en direct (_sans rechargement de page_) comme un tel facteur de rupture.
La modification d'une langue pour un utilisateur ne se produit qu'une seule fois ;

Pensez-y, combien de fois avez-vous changé la langue de votre téléphone ? probablement une fois ou vous venez de rouler avec la langue par défaut.

Surveiller les changements de langue afin d'effectuer des changements en direct sans recharger la page entraîne de nombreuses pénalités de performance pour quelque chose qui est à peine utilisé pendant la durée de vie d'un utilisateur.

En fin de compte, cela se résume à 3 choses pour moi ;

1. Extrayez les traductions des modèles et des fichiers TS.
   
   
   
   • Mettre à jour l'élément de langue source.
   
   
   • Mettre à jour la traduction également (_si j'ai plusieurs langues, fr, en, de... Je veux qu'elles soient toutes mises à jour avec de nouvelles clés de traduction et celles supprimées._)
   
   
2. Un build pour toutes les traductions (_Avoir 1 build pour chaque traduction est bien aussi, tant qu'il ne multiplie pas le temps de build._)
3. Obtenir les langues disponibles et changer la langue avec le rechargement.

@Karasuni
Vous pouvez récupérer des traductions asynchrones et ensuite seulement charger l'application angulaire.
Voir mon commentaire ci-dessus sur la façon de charger le app.module asynchrone en utilisant import(...) .

personnellement, j'utilise Wikipédia pour savoir en quoi le titre d'un film que je connais a été "traduit" dans une autre langue.

de nos jours, être bilingue ou trilingue est plus que banal (mis à part aux États-Unis, pas de mal).

l'utilisateur peut vouloir changer de langue en direct, c'est tout à fait plausible. l'exemple de Wikipédia est un résultat positif d'avoir permis cela, je ne vois pas pourquoi on devrait étouffer d'autres utilisations potentielles avant qu'elles ne vivent pour voir le jour sous prétexte de performance.

même ngx-translate d'ocombe, qui doit être pour vous l'exemple équivalent de "traductions aux performances médiocres", a fonctionné parfaitement assez rapidement pour l'utilisateur de tous les jours.

Je suis personnellement trilingue et je ne peux pas me contenter d'utiliser une seule langue : toutes les langues sont belles pour moi

avec tout ce qui a été dit, je ne peux pas être d'accord avec ceci :

Pensez-y, combien de fois avez-vous changé la langue de votre téléphone ? probablement une fois ou vous venez de rouler avec la langue par défaut.

Wikipédia en est le pire exemple car les différentes langues d'un article sont en fait des articles indépendants. Normalement, vous n'avez pas besoin de différentes langues pour le même site. Même si vous travaillez quadrilingue.
Et si vous avez réellement besoin d'une commutation en direct, vous pouvez utiliser soit la solution de contournement avec le canal de traduction personnalisé, mentionné par @petebacondarwin , soit le nouvel outil de @ocombe.

OK, donc je ne pense pas que ce soit vraiment le meilleur endroit pour avoir cette discussion. Je crains que (bien que tous aient été très raisonnables jusqu'à présent) nous ne glissions dans une discussion négative. Je crains que dans un avenir prévisible, le framework Angular ne fournisse pas de solution de changement de langue en direct prête à l'emploi.

Je pense que la valeur de cette question a suivi son cours. J'ai déplacé les problèmes ouverts et les PR qui sont liés dans la description de ce problème vers https://github.com/angular/angular/milestone/101 et je vais fermer et verrouiller ce PR.

Si vous avez de nouveaux problèmes de demandes de fonctionnalités, veuillez ouvrir un nouveau problème et m'y identifier.