web-dev-qa-db-fra.com

Angular 5 internationalisation

Je construis une application en utilisant la dernière version d'Angular5 et ce dont j'ai besoin, c'est qu'un utilisateur puisse changer de langue. Je n'ai jamais eu à implémenter cela dans un Angular2 + (en fait, j'utilise Angular5).

Je dois définir des traductions à deux endroits:

  • Template du composant html - change les étiquettes dans la langue spécifiée
  • Dans le code du fichier composant.ts, il se peut que je devrais traduire certaines chaînes construites dynamiquement dans des conditions particulières du code.

Je cherchais ngx-translation et il semble pouvoir faire tout ce dont j'ai besoin, car cela vous permet de changer de langue sans reconstruire votre code, voir ici . Cependant, j'ai lu il allait probablement être obsolète car le développeur principal s'est déplacé vers l'équipe angular pour développer son code i18n.

Je comprends aussi que le courant i18n ne supporte pas tout ce dont j'ai besoin pour le moment, voir ici .

Ma question - Quel est l'état d'avancement des traductions dans la dernière version d'Angular? Existe-t-il d'autres bibliothèques que les gens recommanderaient à la place, si en effet, Angular lui-même n'a pas encore de support complet (pour changer de langue sans recompiler)? Est-ce que ngx-translate est bon pour l'avenir?

Toute orientation dans ce domaine est grandement appréciée!

angularinternationalizationngx-translateangular5angular-i18n
43
Rob McCabe

Après avoir passé du temps à regarder cela, j'ai pensé poster les principales différences que j'ai trouvées entre ngx-translate et Angular-i18n :

  • Angular ne fonctionne qu'avec une langue à la fois, vous devez recharger complètement l'application pour changer de langue. Le support JIT signifie seulement qu'il fonctionne avec JIT, mais vous devez toujours fournir les traductions à bootstrap car il remplacera le texte de vos modèles lors de la compilation, alors que cette bibliothèque utilise des liaisons, ce qui signifie que vous pouvez changer les traductions à tout moment. L'inconvénient est que les liaisons utilisent de la mémoire, de sorte que la méthode Angular est plus performante. Mais si vous utilisez OnPush pour vos composants, vous ne remarquerez probablement jamais la différence.
  • Angular ne prend en charge que l'utilisation d'i18n dans vos modèles pour l'instant, je travaille sur la fonctionnalité qui vous permettra de l'utiliser dans votre code, mais le travail est toujours en cours. Cette bibliothèque fonctionne à la fois dans le code et les modèles
  • Angular prend en charge les formats XLIFF ou XMB (les deux formats XML), alors que cette bibliothèque prend en charge JSON par défaut, mais vous pouvez écrire votre propre chargeur pour prendre en charge le format de votre choix (il existe un chargeur pour les fichiers PO, par exemple). Personnellement, les fichiers Json sont assez simples à lire plutôt que ces autres formats, mais ce n’est pas un inconvénient majeur.
  • Angular prend en charge ICU expressions (pluriels et sélection), mais cette bibliothèque ne
  • Angular prend en charge les espaces réservés HTML, y compris le code angular, alors que cette bibliothèque ne prend en charge que le code HTML normal (car il est exécuté au moment de l'exécution, pas lors de la compilation, et il n'y a pas de $ compile dans Angular comme il y avait dans AngularJS)
  • L’API de cette bibliothèque est plus complète car elle est exécutée à l’exécution, elle peut offrir plus de choses (observables, événements, ...) que Angular n’a pas (mais n’a pas vraiment besoin de ne peut pas changer les traductions) Le créateur de ngx-translate a dit ceci:

Ocombe (développeur de ngx): @josersleal c'est exactement ce qu'ils ont fait, l'équipe angular m'a embauchée pour améliorer i18n pour tout le monde. Mais il n'y a aucun moyen d'intégrer ma bibliothèque directement dans le Noyau, après avoir travaillé pendant 3 mois pour l’équipe principale, je peux vous dire que Angular i18n est beaucoup plus complexe et élaboré que mon livre. Il gère beaucoup de choses plus complexes et le fait sans tous les bugs et toutes les lacunes de ma bibliothèque. Je comprends que c’est frustrant que le noyau n’évolue pas aussi rapidement que ce qu’une bibliothèque peut faire, mais il y a des raisons à cela, et la première est que vous ne pouvez pas implémenter quelque chose et le modifier à chaque fois que vous voyez que vous avez oublié d’inclure un cas d'utilisation. Tout doit être soigneusement planifié et pensé. Néanmoins, vous aurez la plupart des choses que cette bibliothèque peut faire dans le noyau à l'avenir, mais cela pourrait prendre un an avant que nous y arrivions malheureusement. La bonne nouvelle est que ça va être bien meilleur que mon implémentation naïve.

C’est un bon article pour discuter des principales différences entre ngx-translate et i18n d’Angular: https://github.com/ngx-translate/core/issues/495

Les modifications pour i18n sont dues à la version 6 de angular. Nous sommes actuellement sur la version 5:

Quelques idées…

  • Angular-i18n est plus performant lorsque vous compilez votre application dans la langue de votre choix (plutôt que les traductions effectuées à l'exécution). Cela peut aussi être un inconvénient, car il se peut que vous ayez besoin de plusieurs versions de votre application dans différentes langues.
  • Si nous utilisions le référencement, angular-i18n serait la voie à suivre en raison de la navigation sur les URL. Pour mon cas, je n’ai pas besoin de ça du tout.
  • Si nous avons besoin de plusieurs commutations, etc. Encore une fois, je n’ai pas besoin de cela - j’ai juste besoin d’un commutateur de langue d’exécution assez simple dans les modèles et le code.
  • Angular-i18n ne sera pas publié avant mars 2018 au moins. Pour moi, je ne peux pas attendre jusque-là, car je dois créer mon application maintenant.
  • ngx-translate n’aura pas un ensemble de fonctionnalités aussi complet que angular-i18n MAIS, encore une fois, je n’ai besoin que de traductions simples, alors pensez que c’est bien pour ce dont nous avons besoin.
  • ngx-translate est open source et arrive le jour où il n’est plus développé, si j’imagine qu’un problème grave se pose et que je pourrais le réparer moi-même (d’ici à ce que tout soit résolu, tout problème éventuel sera résolu).

Je vais aussi jeter un oeil à la bibliothèque Angular-l10n qui a l’air très belle:

55
Rob McCabe

Oui. ngx-translate est bon jusqu'à maintenant, et j'espère que ce le sera également à l'avenir.

J'utilise ngx-translate dans mon projet actuel Angular 5 avec plus de 5 langues.

Cela fonctionne bien pour moi jusqu'à présent. Je n'ai pas eu à apporter de modifications personnalisées, cela a fonctionné comme du plug-and-play.

J'ai utilisé ce plugin https://github.com/ngx-translate/core

5
Sangwin Gawande

Rob McCabe, il y a d'autres préoccupations importantes en plus de celle que vous avez énumérée ci-dessus. Je l'ai expliqué ici .

0
Wildhammer