Traduire une application Angular en anglais

Ce que contient messages.xlf et ce qui est traduit

La commande ng extract-i18n rassemble tous les textes marqués i18n dans les gabarits et toutes les chaînes $localize du code TypeScript dans un seul fichier, messages.xlf, au format XLIFF 1.2 (par défaut) ou XLIFF 2.0. Chaque texte y devient une unité avec un identifiant, une source et, une fois traduite, une target.

Une interpolation n'apparaît pas sous la forme {{ user.name }} mais comme une balise. En XLIFF 1.2 :

<source>Bonjour <x id="INTERPOLATION" equiv-text="{{ user.name }}"/> !</source>

En XLIFF 2.0, la même chose s'écrit avec <ph name="INTERPOLATION" .../>. La cible attendue en anglais est Hello <x id="INTERPOLATION" .../>! : la balise reste identique, seul le texte autour change. Il en va de même pour les balises qui encadrent un lien ou un <b> dans le gabarit (START_LINK, CLOSE_LINK, START_BOLD_TEXT…).

Ne sont pas traduits : les identifiants d'unité (y compris vos ID personnalisés @@loginButton), les valeurs vides, les URL, les adresses email, les nombres, les couleurs, les formats de date et tout ce qui est marqué non traduisible. Le prix porte sur les mots des valeurs, clés et balises exclues.

Du français à l'anglais : ce qui change dans les chaînes Angular

Les pluriels ICU. Le français connaît les catégories CLDR one, many et other, l'anglais seulement one et other. Surtout, 0 est au singulier en français (« 0 fichier ») et au pluriel en anglais (« 0 files »). Une expression comme {count, plural, one {1 fichier} other {{{count}} fichiers}} devient {count, plural, one {1 file} other {{{count}} files}} ; si vous voulez un message propre pour zéro (« No files »), la branche =0 doit déjà exister dans la source. Une branche many héritée du français ne sera simplement jamais sélectionnée en anglais.

La ponctuation. Les espaces insécables du français disparaissent : Nom : devient Name:, Supprimer ? devient Delete?, et les guillemets « » deviennent des guillemets anglais.

Les majuscules. Les interfaces américaines mettent volontiers une majuscule à chaque mot d'un titre ou d'un bouton (« Save Changes ») ; l'usage britannique préfère souvent la seule majuscule initiale (« Save changes »). Décidez une règle et tenez-la.

La longueur. L'anglais est en général 10 à 15 % plus court que le français : « Enregistrer les modifications » devient « Save changes ». Les débordements sont rares, mais un bouton dimensionné au texte français peut paraître vide.

Britannique ou américain. L'orthographe (colour/color, cancelled/canceled, organisation/organization) se joue dans la traduction ; l'ordre des dates (JJ/MM ou MM/JJ) et le format des montants, eux, ne viennent pas de messages.xlf mais des données de locale chargées par Angular pour DatePipe, CurrencyPipe et DecimalPipe. Choisir en-GB ou en-US dans la configuration fixe donc les dates, pas l'orthographe.

Ce que Manuce rend exactement, et ce qu'il ne fait pas

Vous récupérez le même fichier XLIFF, dans la même version (1.2 ou 2.0), avec les cibles anglaises remplies. Indentation, ordre des unités, guillemets, commentaires, fins de ligne, encodage et BOM sont conservés : seules les valeurs changent, et un diff avec l'original ne montre que les cibles.

Chaque valeur traduite est comparée à la source : mêmes balises INTERPOLATION, ICU, START_TAG_SPAN, mêmes variables. En cas d'écart persistant, la valeur source est gardée et le rapport l'indique. Ce rapport liste les chaînes traduites, celles laissées telles quelles et la raison (URL, nombre, valeur vide, balise non retrouvée…).

Ce que Manuce ne fait pas :

• il ne modifie ni angular.json, ni vos composants, ni les données de locale ;
• il ne voit pas les textes écrits en dur sans attribut i18n ni $localize : ils ne sont pas dans messages.xlf ;
• il ne réorganise pas les branches d'une expression ICU : la structure reste celle de la source ;
• il ne lance pas le build et ne teste pas l'application.

Préparer l'extraction et vérifier le build anglais

Avant d'extraire :

• Donnez des ID personnalisés aux textes importants (i18n="@@checkout.pay"). Sans eux, l'ID est calculé à partir du texte : corriger une faute dans la source française change l'ID et fait perdre la traduction anglaise.
• Ajoutez une description aux chaînes courtes ambiguës (i18n="bouton de fermeture|Fermer@@dialog.close") : « Ouvert » peut être Open (verbe) ou Opened, « Libre » peut être Free ou Available. La description est écrite dans le fichier, utile à quiconque relit.
• Vérifiez la locale source : si votre application est écrite en français, déclarez "sourceLocale": "fr" dans la section i18n du projet, sinon Angular suppose en-US.

Après livraison :

• enregistrez le fichier sous un nom explicite, par exemple src/locale/messages.en-GB.xlf, et déclarez-le dans les locales du projet ;
• lancez ng build --localize : une balise manquante ou mal fermée y provoque une erreur ou un avertissement ;
• parcourez les écrans contenant des pluriels avec 0, 1 et 2 éléments ;
• relisez dans le rapport les chaînes laissées en français et vérifiez l'orthographe selon la variante visée.

En pratique

1. Marquez les textes avec i18n ou $localize, ajoutez des ID @@ stables, puis lancez ng extract-i18n.
2. Déposez messages.xlf sur Manuce : le devis s'affiche aussitôt, calculé sur les mots des valeurs.
3. Lisez l'extrait gratuit au niveau choisi, puis payez pour lancer la traduction.
4. Enregistrez le fichier rendu sous messages.en-GB.xlf (ou en-US), déclarez-le et lancez ng build --localize.
5. Consultez le rapport et testez les écrans à pluriels et à interpolations.