Traduire une application Java (Spring) en japonais

Ce que le japonais change dans vos messages.properties

Le japonais mêle trois écritures : les kanji pour les notions (保存, « enregistrer »), les hiragana pour la grammaire, les katakana pour les mots empruntés (ログイン, « connexion »). Il n'y a pas d'espace entre les mots et la ponctuation est en pleine chasse : 、 pour la virgule, 。 pour le point. Pour une application Spring, cela a quatre conséquences.

• L'ordre des mots s'inverse souvent. welcome=Bienvenue, {0} devient welcome={0}さん、ようこそ : la variable passe en tête, suivie du suffixe de politesse さん. Un message construit par concaténation dans le code Java ("Bonjour " + user.getName()) ne pourra jamais être remis dans le bon ordre ; il doit passer par un paramètre {0}.
• Une seule forme de pluriel. CLDR ne connaît que la catégorie other pour le japonais. Un {0,choice,0#aucun fichier|1#un fichier|1<{0} fichiers} garde sa structure, mais ses branches deviennent presque identiques ({0} 件のファイル). Le japonais compte avec des classificateurs : 件 pour des éléments, 人 pour des personnes, 枚 pour des feuilles.
• Le registre. Une interface professionnelle attend le style poli en です/ます pour les phrases (保存しました。, « enregistré ») et des formes brèves pour les boutons (保存, キャンセル). Les consignes prennent la forme 〜してください : メールアドレスを入力してください。
• Deux-points et parenthèses. Le libellé Nom : devient 氏名： ou 氏名: selon votre charte. L'important est que tous les fichiers suivent la même règle.

L'encodage, piège propre aux fichiers .properties

Pendant longtemps, Java a lu les fichiers .properties en ISO-8859-1, un jeu de caractères qui ne contient aucun caractère japonais. Deux pratiques coexistent donc dans les projets.

• Les échappements Unicode. 保存 s'écrit \u4FDD\u5B58. Toutes les versions de Java les lisent, mais un relecteur humain ne peut pas les lire.
• L'UTF-8 direct. Depuis Java 9, ResourceBundle lit les .properties en UTF-8. Spring Boot lit les messages en UTF-8 par défaut, réglable par spring.messages.encoding. Si vous déclarez vous-même un ResourceBundleMessageSource, vérifiez l'encodage qui lui est attribué.

Le fichier rendu par Manuce garde l'encodage, le BOM et les fins de ligne de l'original. Les échappements \uXXXX déjà utilisés sont conservés. Ne comptez donc pas sur la traduction pour changer l'encodage. Si votre messages.properties est en ISO-8859-1 sans échappements, enregistrez la copie destinée au japonais en UTF-8 avant de la déposer. Assurez-vous ensuite que l'application la lit bien en UTF-8. Sinon, l'écran affichera des points d'interrogation ou des suites de caractères illisibles.

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

Vous déposez messages.properties, ou une copie nommée messages_ja.properties. Vous récupérez le même fichier, avec les valeurs en japonais. L'indentation, l'ordre des clés, les commentaires et les guillemets sont conservés. Les lignes de continuation terminées par \ sont respectées.

• Variables et balises contrôlées. Chaque valeur traduite est comparée à la source : {0}, {1,number} ou <b> doivent s'y retrouver, même déplacés en tête de phrase. En cas d'écart persistant, la valeur source est gardée et le rapport le signale.
• Apostrophes de MessageFormat. Dans une valeur à paramètres, l'apostrophe se double : l''utilisateur {0}. Le japonais n'en emploie presque pas, car il cite avec 「」. Si une apostrophe subsiste, dans un nom de produit par exemple, elle est gérée.
• Laissés tels quels. Les clés, les valeurs vides, les URL, les adresses email, les nombres, les couleurs, les formats de date (dd/MM/yyyy reste identique), les identifiants et tout ce qui est marqué non traduisible ne sont pas touchés.

Le rapport liste les chaînes traduites et celles laissées telles quelles, avec la raison. Seul le fichier déposé est traité : votre code Java, vos gabarits Thymeleaf et votre LocaleResolver restent à votre charge. Manuce ne produit pas de traduction assermentée : si des conditions générales doivent exister en version certifiée, il faut passer par un traducteur expert. Le japonais est une langue à supplément (coefficient ×1,6). Le prix porte sur les mots des valeurs, clés et balises exclues.

Préparer le fichier et vérifier après livraison

• Supprimez les concaténations. Cherchez dans le code les getMessage(...) + et remplacez-les par une seule clé paramétrée. C'est la première cause de phrases japonaises dans le désordre.
• Documentez les clés ambiguës. Un commentaire # bouton : verbe au-dessus de action.open=Ouvrir aide votre relecteur japonais à trancher entre 開く (ouvrir) et オープン (statut « ouvert »). Les commentaires sont conservés dans le fichier rendu.
• Adaptez les formats de date vous-même. Au Japon, l'ordre est année-mois-jour : yyyy/MM/dd ou yyyy年M月d日. Ces motifs ne sont pas traduits. Si vous les stockez dans messages_ja.properties, modifiez-les à la main.
• Vérifiez les polices. Si l'application génère des PDF ou des images côté serveur, la police embarquée doit contenir les glyphes japonais, sinon des carrés vides apparaissent. Côté navigateur, prévoyez une police de repli japonaise dans la feuille de style.
• Testez avec la locale ja. Envoyez un en-tête Accept-Language: ja. Une clé absente de messages_ja.properties retombe sur messages.properties, ce qui donne un écran à moitié traduit.
• Contrôlez les retours à la ligne. Sans espaces, le navigateur coupe le japonais entre deux caractères. Vérifiez qu'un mot comme ダウンロード n'est pas coupé dans une colonne étroite ou un bouton.

En pratique

1. Copiez messages.properties en messages_ja.properties, enregistré en UTF-8, ou gardez les échappements \uXXXX si votre projet les utilise.
2. Remplacez dans le code Java les messages concaténés par des clés à paramètres {0}.
3. Déposez le fichier, consultez le devis et l'extrait gratuit au niveau choisi.
4. Remettez le fichier dans src/main/resources et testez l'application avec la locale ja.
5. Lisez le rapport et traitez les chaînes laissées en langue source.