Angular 6 - i18n vs. ngx-translate
Je travaille sur un grand projet utilisant angular 6. Ce projet nécessite une intégration importante dans i18n. J'essaie de prendre la bonne décision quant à la façon de procéder.
Selon moi, je peux choisir entre:
- ngx-translate ( https://github.com/ngx-translate/core )
- Angular i18n ( https://angular.io/guide/i18n )
Je penche pour choisir l'option 2; Angular's i18n. Ceci est dû au fait qu’il s’agit d’un package intégré à Angular, qui me convient mieux. Apparemment, il est également préférable pour le référencement et légèrement pour la performance sans aucun travail autour. En outre, maintenant il est publié, je pense que ngx-translate pourrait être obsolète. Beaucoup d’informations ici: Internationalisation angulaire 5 .
Cependant voici mes réservations:
- Apparemment, la version d'Angular est assez récente/en train de rattraper son retard ( https://github.com/ngx-translate/core/issues/495 ). Est-ce trop nouveau pour prendre?
- Apparemment, je dois avoir un site Web distinct pour chaque langue ( https://angular.io/guide/i18n#template-translations ) ??? Je ne pense vraiment pas que ce serait une bonne chose. Est-ce correct? ou s'agit-il d'un cas où les fichiers de modèle sont insérés dynamiquement à chaque fois? Je sais qu'avec ngx-translate les mots traduits sont simplement stockés dans des fichiers .json - j'aime la propreté de cela. Je ne pense pas que nous voulions un ensemble de versions différentes de sites Web.
Existe-t-il un moyen de changer de langue en direct avec i18n angulaire? Changer de langue sur la page sans recharger/récupérer les données du serveur? Est-ce ce qu'ils appellent JIT?
Est-ce que quelqu'un a essayé https://github.com/robisim74/angular-l10n ? semble très bien aussi.
Merci beaucoup et meilleures salutations.
Est-ce trop nouveau pour prendre?
Ceci est basé sur l'opinion, et donc hors sujet
Apparemment je dois avoir un site web séparé
Vous avez besoin d’une application distincte (c’est-à-dire index.html + bundles). Mais vous pouvez servir toutes ces applications à partir d'une seule URL, en choisissant celle à servir sur le serveur. Cela changera (espérons-le) avec Angular 7, lorsque la nouvelle interface dynamique i18n, construite sur Ivy, sera disponible.
est-il vrai que les fichiers modèles sont insérés dynamiquement à chaque fois?
Pas sûr de ce que vous voulez dire. Les traductions des paramètres régionaux pour lesquels vous avez créé sont stockées dans les classes de modèles générées lors de la compilation par le compilateur AOT angulaire.
Existe-t-il un moyen de changer de langue en direct avec i18n angulaire?
Non, et cela ne sera plus possible avec la prochaine version d'i18n. La même application unique pourra s'exécuter dans plusieurs langues, mais la langue devra toujours être choisie au démarrage et vous devrez redémarrer l'application pour choisir une autre langue.
Existe-t-il un moyen de changer de langue en direct avec i18n angulaire?
Non, pas efficacement au moins.
Est-ce ce qu'ils appellent JIT?
Le compilateur JIT compile vos modèles HTML en JavaScript au démarrage, dans le navigateur. En production, vous utilisez le compilateur AOT (qui est également utilisé pour intégrer les traductions dans les classes JS générées), qui effectue une compilation similaire des modèles, mais au moment de la construction plutôt que de l'exécution.
La discussion est toujours en cours et vous pouvez trouver ici des réponses et des avis, même directement des développeurs Angular: https://github.com/ngx-translate/core/issues/495
Personnellement, je structurerais l'application avec l'i18n officiel et ajouterais éventuellement une traduction dédiée dans le code avec la bibliothèque ngx-translate.
Existe-t-il un moyen de changer de langue en direct avec i18n angulaire?
En fait, il y a. Vous devez créer différentes versions de votre application, mais vous pouvez ensuite basculer en direct après le déploiement complet:
Il est compréhensible que les développeurs aiment une bibliothèque semblable à ngx-translate pour s'occuper de l'internationalisation. Après tout, cela facilite tellement notre vie en rendant le problème de traduction un mappage 1v1. Malheureusement, ce n'est pas comme ça que ça marche avec les langues humaines. Une personne sur deux connaît plus d'une langue pour mieux comprendre les lacunes de cette approche.
Voici un petit exemple: Supposons que vous avez une application pour les frais de déplacement, vous avez une vue tabulaire dans laquelle le titre d’une colonne est "fois" indiquant le moment où la dépense a été déclarée. Ensuite, imaginez que, dans une telle application, vous disposiez d’une mini-calculatrice pour effectuer une vérification de base de vos dépenses, qui dispose d’un bouton de multiplication x avec une escale disant «temps». Lorsque vous effectuez une traduction ngx, vous extrayez les deux avec la même clé "TIMES", ce à quoi le traducteur vous restituera une traduction. Mais la première occurrence de "time" n'est pas nécessairement traduite de la même manière que la seconde dans toutes les autres langues. Prenez l'espagnol par exemple:
- "deux fois trois" (comme dans la calculatrice) -> "dos POR tres"
- "temps de dépense" (comme dans la vue tabulaire) -> "TIEMPOS de gasto"
C’est en fait la raison pour laquelle l’internationalisation tend à utiliser un format plus sophistiqué, tel que XLF, pour prendre en charge le sens, la description (dans le cas de Angular) plutôt que l’ancien style JSON à une profondeur qui ne permet pas la traduction par rapport au contexte.
Vous pouvez maintenant dire que cela peut être résolu en enregistrant deux clés différentes pour des "temps" qui en anglais correspondent à la même chose, mais cela nécessite que vous, en tant que développeur, sachiez toutes les langues que votre application prend en charge pendant le développement. parcourez une autre itération (le temps, c'est de l'argent!) pour obtenir les commentaires des clients, puis ajouter une clé distincte, alors que si vous fournissez une description et une signification pour votre message (texte), le traducteur s'en charge pour vous sans que vous ayez aucune connaissance de l'autre la langue (si vous connaissez l’espagnol, songez à quel point cela peut être compliqué avec des formes de verbe subjonctives et indicatives identiques en anglais mais pas en espagnol).
Pour répondre à votre autre question "Y at-il un moyen de changer de langue en direct avec i18n angulaire?": Oui, il y en a. Jetez un coup d'œil à cet article génial à propos de la gestion d'état dans les applications. Pour résumer, il faut que vos états client et persistant soient reflétés dans une URL. Ensuite, tout ce que vous avez à faire est d’ajouter un préfixe de paramètres régionaux à votre chemin, afin que votre serveur Web vous fournisse la construction de paramètres régionaux appropriée. Ensuite, quel que soit l'état de votre application avant la modification de l'action de modification des paramètres régionaux, il est récupérable à partir d'une URL (car "il reflète l'état persistant et l'état du client").
L'un des grands avantages de Angular I18N est que son impact sur les modèles est minime. Vous devez seulement ajouter l'attribut i18n sur chaque élément que vous souhaitez localiser. Alors
<p>Hello World<p>
devient
<p i18n>Hello World<p>
Pas besoin de changer beaucoup le balisage ni de maintenir manuellement le fichier de ressources. Si vous utilisez une autre bibliothèque I18N pour Angular ou React, vous devez beaucoup modifier votre balisage, tel que
<p>Translate("Hello World")<p>
et vous devez ajouter manuellement la chaîne dans le fichier de ressources neutre tel que
"Hello World": "Hello World"
Ensuite, si vous souhaitez modifier la chaîne, vous devez également vous rappeler de mettre à jour la clé et la valeur dans le fichier de ressources.
Avec Angular I18N, vous utilisez un outil d’extraction pour créer et gérer les fichiers de ressources neutres.
Ce qui manque actuellement dans Angular I18N, c'est la possibilité de localiser une chaîne dans le code source. Cependant, cette fonctionnalité apparaîtra bientôt.