Explication de la différence entre l'internationalisation (i18n) lors de la compilation et lors de l'exécution dans Angular

L'internationalisation dans Angular peut s'effectuer selon deux modèles différents : au moment de la compilation ou au moment de l'exécution. L'approche officielle utilise @angular/localize, ce qui génère une version distincte pour chaque langue. Cette configuration est stable et rapide lors de l'exécution, mais elle nécessite de prévoir plusieurs déploiements et ne permet pas de changer de langue au sein de l'application.

Pour mettre cela en œuvre, vous sélectionnez du texte dans les modèles et dans TypeScript, vous extrayez les traductions dans des fichiers, puis vous compilez une version de l'application par locale. Chaque langue est accessible via sa propre URL ; les utilisateurs changent donc de langue via la navigation plutôt qu'à l'aide d'un bouton de basculement intégré à l'application.

Si vous avez besoin d'une commutation dynamique sans rechargement, ce sont les bibliothèques d'exécution qui s'en chargent. Parmi les options les plus courantes, on trouve ngx-translate et angular-i18next. Celles-ci chargent les traductions à la demande et mettent à jour l'interface utilisateur instantanément, avec des compromis différents en matière de configuration, de performances et de prise en charge du SSR.

Dans cet article, nous expliquons le fonctionnement du workflow d'internationalisation (i18n) intégré à Angular, comment le déployer et dans quels cas une bibliothèque d'exécution constitue une meilleure solution.

Comment @angular/localize œuvres

La fonctionnalité d'internationalisation intégrée à Angular repose sur un processus de compilation. Vous préparez les traductions avant le déploiement, puis vous publiez une version compilée de l'application pour chaque langue.

Il n'y a pas de changement de langage à l'exécution ; la configuration porte donc principalement sur l'extraction et la configuration de la compilation.

Passons en revue l'ensemble du processus:

1. Marquez le texte à traduire dans les modèles et en TypeScript. Utilisez l'attribut `i18n` pour le contenu et les attributs HTML, et utilisez $localize en TypeScript, de sorte que les chaînes de caractères soient incluses dans le même processus d'extraction.
2. Extrayez les messages dans un fichier de traduction à l'aide de l'Angular CLI. Cela génère par défaut un fichier XLIFF, avec des options pour d'autres formats en fonction de votre configuration, contenant les identifiants des messages et le texte source.
3. Traduisez le fichier extrait et conservez les identifiants inchangés. Ajoutez des identifiants personnalisés si nécessaire afin que les modifications apportées au texte source n'altèrent pas les traductions existantes et ne provoquent pas de divergences invisibles.
4. Créez et déployez une version de l'application par paramètre régional. Configurez les paramètres régionaux dans le fichier angular.json, puis générez des paquets spécifiques à chaque langue, qui seront mis à disposition via des routes ou des domaines distincts.

La pluralisation utilise les expressions ICU. Vous définissez des cas tels que =0, =1, ou autre, et Angular sélectionne le formulaire approprié en fonction des paramètres régionaux actifs. Le nombre de formulaires requis varie d'une langue à l'autre ; il est donc conseillé de planifier la structure des messages dès le début.

Les expressions ICU imbriquées suivent le même schéma, mais augmentent la complexité ; veillez donc à ce qu'elles restent lisibles et testez-les dans différentes locales.

Création et déploiement d'applications Angular prenant en charge plusieurs langues

Avec la fonctionnalité d'internationalisation (i18n) d'Angular au moment de la compilation, le déploiement dépend directement de la manière dont vous configurez le fichier angular.json. Vous définissez une locale source et un ensemble de locales cibles, chacune étant associée à un fichier de traduction.

Lors de la compilation, Angular compile l'application une seule fois, puis applique les remplacements localisés lors d'une étape de post-traitement. Cela signifie que vous n'effectuez pas de compilation complète pour chaque langue, mais que vous obtenez tout de même des paquets de sortie distincts pour chaque locale.

Chaque locale génère sa propre version de l'application, généralement accessible via un sous-chemin ou un domaine. Une configuration courante utilise des chemins tels que /fr/ et /fr/, chacun renvoyant vers le résultat de compilation correspondant. Cette structure est nécessaire car le contenu traduit est intégré aux fichiers ; ainsi, changer de langue implique de charger une compilation différente.

La configuration du serveur fait désormais partie intégrante de la configuration de l'internationalisation (i18n). Vous devez définir des règles de routage qui redirigent les requêtes entrantes vers la version adaptée à la locale correspondante.

La mise en œuvre varie considérablement selon l'environnement – des règles de réécriture brutes dans Nginx contre quelques lignes déclaratives dans Firebase Hosting –, mais l'objectif reste le même. Les requêtes doivent être redirigées vers le bon ensemble localisé en fonction de la structure de l'URL ou de la logique de redirection.

Angular prend également en charge la détection automatique de la langue lors du rendu côté serveur. Le serveur peut lire la Accept-Language en-tête, puis rediriger les utilisateurs vers le chemin correspondant à leur paramètres régionaux. Cela améliore l'expérience lors de la première visite, mais entraîne tout de même le chargement complet de la page lors d'un changement de langue ultérieur.

En phase de développement, le serveur de développement Angular peut prendre en charge plusieurs paramètres régionaux à l'aide de sous-chemins. Cela facilite les tests, mais le passage d'une langue à l'autre nécessite tout de même un rafraîchissement de la page, car chaque paramètre régional correspond à une version distillée distincte.

Ce modèle a des implications évidentes en matière d'infrastructure. Vous gérez plusieurs artefacts de compilation, configurez le routage pour chaque locale et gérez les redirections au niveau du serveur. Les pipelines d'intégration continue (CI) doivent tenir compte des mises à jour de traduction et recompiler les sorties localisées lorsque le contenu change.

Une autre approche permet d'éviter cette complexité. Un modèle de proxy inverse, tel que Weglot, s'intercale entre le serveur et le navigateur. Il traduit le contenu à la volée et diffuse toutes les langues à partir d'un seul déploiement. Cela évite d'avoir à créer plusieurs versions et à définir des règles de routage. Nous reviendrons plus en détail sur Weglot !

Comparaison des bibliothèques d'exécution : ngx-translate, Transloco et angular-i18next

Les bibliothèques d'exécution répondent à un besoin différent de celui de la fonctionnalité d'internationalisation (i18n) intégrée à Angular. Au lieu d'intégrer les traductions lors de la compilation de l'application, elles les chargent au moment de l'exécution et mettent à jour l'interface utilisateur sans nécessiter un rafraîchissement complet de la page.

Cela en fait une solution plus adaptée lorsque les utilisateurs doivent changer de langue au sein de l'application ou lorsque le contenu évolue fréquemment.

ngx-translate C'est l'option la plus couramment utilisée. Elle permet de changer de langue instantanément grâce à trans.use(), avec des traductions chargées à partir de fichiers JSON ou d'API. Cette solution fonctionne bien dans les petites applications et constitue la seule option proposée ici dont l'efficacité a été confirmée Ionique Compatibilité. Le SSR est possible avec TransferState ainsi que des chargeurs personnalisés, même si cela nécessite une configuration. Les versions récentes ont intégré une API basée sur des fournisseurs, qui s'adapte mieux aux composants autonomes.

Transloco met l'accent sur la structure et l'évolutivité. Il offre une prise en charge intégrée du SSR et une configuration plus simple grâce à la commande `ng add`. Il prend également en charge les traductions par portée, ce qui vous permet de charger les fichiers de langue de manière différée, fonction par fonction. Cela réduit la taille des paquets et facilite la maintenance des applications volumineuses. Le changement de langue s'effectue via setActiveLang() et actualise immédiatement l'interface utilisateur.

angular-i18next intègre l'écosystème i18next. Il s'avère utile si votre équipe utilise déjà i18next dans d'autres frameworks et souhaite garantir la cohérence entre les différents projets. Il prend en charge les plugins du noyau i18next, y compris la gestion d'ICU. Le changement de langue nécessite généralement un rechargement de la page, ce qui limite son utilisation dans les applications qui exigent des mises à jour instantanées.

Voici une comparaison plus directe :

Le choix dépend de la manière dont votre application gère les changements de langue et l'évolutivité :

• Utilisez ngx-translate si vous avez besoin d'une configuration simple ou d'une prise en charge d'Ionic.
• Utilisez Transloco pour les applications SSR ou les applications volumineuses nécessitant une traduction modulaire.
• Utilisez angular-i18next si vous souhaitez assurer la cohérence avec i18next sur plusieurs plateformes.

💡 Si le changement de langue à l'exécution n'est pas nécessaire et que vous préférez une logique côté client minimale, la fonctionnalité d'internationalisation (i18n) intégrée à Angular reste la meilleure option.

Traduire des applications Angular sans modifier le code

Il existe une troisième option en plus des bibliothèques d'internationalisation (i18n) et d'exécution intégrées à Angular : les outils externes de traduction de sites web. Ces outils fonctionnent en dehors de l'application Angular et traduisent le contenu affiché plutôt que les chaînes de caractères présentes dans le code source.

Comme indiqué précédemment, Weglot un modèle de proxy inverse. Il s'interpose entre le serveur et le navigateur, détecte la réponse HTML, puis fournit des versions traduites aux visiteurs. Cela signifie que vous n'avez pas besoin de marquer les chaînes avec i18n, de gérer des fichiers de traduction JSON ni de recompiler l'application pour chaque locale. La mise en place est plus rapide, car la couche de traduction est gérée en dehors d'Angular.

Cette approche modifie également le lieu où s'effectue le travail de traduction. Au lieu de modifier des fichiers dans le projet, les traducteurs utilisent un tableau de bord visuel. Ils peuvent relire les pages et appliquer les règles du glossaire sans avoir à intervenir sur les modèles ni sur le TypeScript. Pour les sites marketing riches en contenu, cela permet de réduire l'intervention des développeurs.

Le changement de langue peut également s'effectuer de manière plus fluide. Weglot un sélecteur basé sur JavaScript qui met à jour la langue affichée sans nécessiter de processus complet de reconstruction Angular. Cela facilite la mise en ligne rapide de contenus multilingues.

Le compromis réside dans le contrôle. La traduction ayant lieu après le rendu de la page par Angular, ce modèle ne prend pas en charge la logique applicative qui dépend de la langue au sein de TypeScript. Il est également moins adapté aux applications Ionic et aux applications « offline-first », où le contenu doit résider au sein même de l'application plutôt que derrière un proxy.

Le référencement naturel dépend également de la configuration. La traduction via un proxy inverse permet d'obtenir des pages traduites indexables, mais un simple snippet JavaScript ne suffit pas snippet à créer des URL localisées optimisées pour le référencement naturel. C'est un aspect important si l'on souhaite générer du trafic issu du référencement naturel.

Ce modèle est particulièrement adapté aux équipes qui souhaitent disposer de pages multilingues sans modifier le code de l'application. Il est en revanche moins adapté lorsque la langue a une incidence sur le routage ou la logique métier. Il nécessite également un abonnement actif, car le contenu traduit reste lié au service.

Choisir la bonne approche pour l'internationalisation (i18n) dans Angular

La bonne approche en matière d'internationalisation avec Angular dépend de la manière dont votre application gère concrètement les langues.

L'internationalisation (i18n) au moment de la compilation privilégie les performances et la stabilité, tandis que les bibliothèques d'exécution mettent l'accent sur la flexibilité au sein de l'interface utilisateur. Les outils externes éliminent la majeure partie du travail de mise en œuvre, mais transfèrent le contrôle en dehors de la base de code.

Choisissez @angular/localize lorsque les performances d'exécution sont essentielles et que votre équipe maîtrise la gestion de versions localisées distinctes dans le cadre de l'intégration continue (CI). Cette solution est particulièrement adaptée lorsque le changement de langue s'effectue via la navigation plutôt qu'au sein même de l'application.

Optez pour ngx-translate lorsque les utilisateurs doivent changer de langue sans avoir à actualiser la page et que vous recherchez une solution d'exécution largement adoptée. C'est la solution la plus adaptée dans ce contexte pour les projets Ionic et les petites applications Angular.

Optez pour Transloco si vous avez besoin d'une commutation à l'exécution et d'une structure plus robuste pour vos applications de grande envergure. Cette solution est particulièrement adaptée aux configurations SSR et aux équipes qui souhaitent disposer de fichiers de traduction limités à un certain périmètre et chargés de manière différée.

Optez pour Weglot votre objectif est de créer un site web multilingue sans avoir à intégrer de logique de traduction dans le code Angular. Cette solution est idéale pour la diffusion de contenu et les déploiements rapides, mais ne convient pas aux applications dans lesquelles le comportement de TypeScript doit varier en fonction de la langue.

{{bannière-démo}}