Traduire une application Angular en japonais

Ce que le japonais change dans un messages.xlf

Le japonais mêle trois écritures : les kanji pour les notions (設定, « réglages »), les hiragana pour la grammaire (を, が, ます), les katakana pour les mots empruntés (ダウンロード). Il n'y a pas d'espace entre les mots et la ponctuation est pleine chasse : 、 pour la virgule, 。 pour le point, ？ et ： en fin de libellé. Une cible japonaise ne garde donc aucune espace autour des signes, contrairement à la typographie française.

L'ordre des mots est sujet-objet-verbe. La chaîne Supprimer {{ fileName }} ? devient {{ fileName }}を削除しますか？ : la variable passe en tête. Dans le XLIFF, la balise <x id="INTERPOLATION" equiv-text="{{ fileName }}"/> (ou <ph name="INTERPOLATION"/> en XLIFF 2.0) change de place dans la cible. C'est normal : Angular reconstitue la phrase à partir de la position des balises, pas de leur ordre dans la source.

Le registre compte. Dans une interface professionnelle, les messages se terminent en forme polie (-masu, -desu) : 保存しました plutôt que 保存した pour « Enregistré ». Les boutons restent des noms ou des verbes courts : 保存, キャンセル, 閉じる. Les messages de validation des formulaires suivent la même logique : « Ce champ est obligatoire » se rend par この項目は必須です.

Pluriels ICU et formats : ce que la locale ja fait d'elle-même

Le CLDR ne connaît qu'une catégorie de pluriel pour le japonais : other. Une expression {count, plural, =0 {Aucun fichier} one {1 fichier} other {{{count}} fichiers}} reste valide, mais avec la locale ja, Angular n'utilise jamais la branche one : pour une quantité de 1, c'est other qui s'affiche. La cible utile est donc other {{{count}}件のファイル}, correcte pour toutes les quantités. Les cas explicites comme =0 ou =1, eux, restent appliqués.

Le japonais ne marque pas le genre grammatical : une expression select sur le genre aboutit souvent à des branches identiques. Ce n'est pas une erreur, et la structure ICU doit rester intacte pour que le fichier compile.

Les dates, nombres et devises ne passent pas par la traduction : DatePipe et CurrencyPipe les formatent selon la locale. Avec ja, le format longDate donne 2025年3月14日 et le yen s'affiche sans décimales. Un format écrit en dur comme 'dd/MM/yyyy' dans un gabarit ne sera pas modifié : préférez les formats nommés avant l'extraction.

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

Vous déposez le fichier produit par ng extract-i18n, en XLIFF 1.2 ou 2.0. Manuce remplit les cibles et vous rend le même fichier : indentation, ordre des clés, guillemets, commentaires, fins de ligne, encodage et BOM sont conservés ; seules les valeurs changent. Renommé messages.ja.xlf, il se replace dans le projet.

Chaque valeur japonaise est comparée à la source : mêmes balises, mêmes variables. Si un écart persiste, la valeur source est gardée et le rapport le dit. Vous savez ainsi quelles unités sont restées dans la langue d'origine et pourquoi, au lieu de le découvrir à la compilation.

Ne sont pas traduits : les identifiants d'unité (y compris vos @@id personnalisés), les valeurs vides, URL, adresses email, nombres, couleurs, formats de date, identifiants et tout ce qui est marqué non traduisible. Le prix porte sur les mots des valeurs, clés et balises exclues ; le japonais est une langue à supplément (coefficient ×1,6).

Manuce ne touche ni à angular.json, ni à vos gabarits, ni à vos feuilles de style : la déclaration de la locale, la compilation et le contrôle visuel restent de votre côté. Il ne produit pas non plus de traduction assermentée, si un texte juridique de l'application devait être certifié.

Préparer le fichier et vérifier le rendu

• Donnez du contexte dans les attributs : i18n="bouton|Ferme la fenêtre de dialogue@@closeDialog". « Fermer » une fenêtre se dit 閉じる, mais un ticket « Fermé » se rend par 完了 ou クローズ. Le sens et la description passent dans le XLIFF et lèvent l'ambiguïté.
• Ne découpez pas les phrases. Un texte réparti en trois éléments i18n (Bonjour, <b>{{ name }}</b>, bienvenue) ne peut pas être réordonné. Gardez la phrase dans un seul élément, balises internes comprises : le japonais placera le nom et la formule de politesse là où il le faut ({{ name }}様、ようこそ).
• Évitez la concaténation en TypeScript : 'Page ' + n + ' sur ' + total ne deviendra jamais {{ total }}ページ中{{ n }}ページ目. Utilisez $localize avec des placeholders, que ng extract-i18n place dans le même fichier.
• Prévoyez les polices : ajoutez au font-family des polices japonaises de repli (Hiragino Sans, Yu Gothic, Noto Sans JP) et vérifiez que la page porte lang="ja", faute de quoi certains systèmes affichent les kanji avec des glyphes chinois.
• Testez la longueur : 設定 est plus court que « Paramètres », mais les katakana allongent vite (« Télécharger » → ダウンロード) et chaque caractère est pleine chasse. Sans espaces, le navigateur coupe les lignes presque partout : contrôlez les boutons, les onglets et les colonnes étroites.

En pratique

1. Lancez ng extract-i18n et récupérez messages.xlf (XLIFF 1.2 ou 2.0).
2. Déposez le fichier : devis immédiat sur le nombre exact de mots et extrait gratuit d'un paragraphe au niveau choisi.
3. Récupérez le fichier rempli et le rapport, puis renommez-le messages.ja.xlf.
4. Déclarez la locale ja dans le projet, compilez et vérifiez le rendu des écrans.