Traduire une application React ou Next.js en japonais

Ce que le japonais change dans vos fichiers de langue

Le japonais mêle kanji, hiragana et katakana. Il n'utilise pas d'espace entre les mots et place le verbe en fin de phrase. Dans un fichier JSON d'i18next, de react-intl ou de next-intl, ces trois traits se voient immédiatement.

• Les variables changent de place. "deleteFiles": "Supprimer {{count}} fichiers ?" devient "{{count}} 件のファイルを削除しますか？". La variable passe en tête, le verbe en fin, et le point d'interrogation devient pleine chasse. C'est normal, tant que {{count}} reste intacte.
• Les phrases découpées en plusieurs clés ne fonctionnent plus. Si votre composant assemble t('youHave'), puis un nombre, puis t('unreadMessages'), aucune traduction japonaise correcte ne tient dans cet ordre. Il faut une seule clé : "unread": "Vous avez {{count}} messages non lus".
• Les nombres prennent un classificateur. On compte les fichiers ou les éléments en 件 ou 個, les personnes en 人 et les feuilles en 枚. Une clé nommée count sans contexte laisse le traducteur deviner. Des noms comme membersCount ou invoiceCount l'orientent.

Le pluriel, lui, disparaît : le japonais n'a qu'une catégorie CLDR, other. Avec i18next (format v21 et suivants), la paire items_one / items_other reste dans le fichier japonais, mais seule items_other est lue. Dans un message ICU comme {count, plural, one {# article} other {# articles}}, c'est la branche other qui s'affiche. Une correspondance exacte comme =0 reste prioritaire et utile pour « aucun article ».

Registre, ponctuation et conventions japonaises

Une interface japonaise destinée à des clients s'adresse à eux en style poli (です／ます) et recourt au keigo dans les messages sensibles. On écrira par exemple "保存しました" pour une confirmation et "入力内容をご確認ください" pour une erreur de formulaire. Les boutons restent courts et nominaux : 保存, 送信, キャンセル. Les termes empruntés s'écrivent en katakana (ダッシュボード, ログイン) ; vérifiez qu'un même terme garde la même graphie d'un écran à l'autre.

• Ponctuation pleine chasse : la virgule devient 、 et le point 。 ; ？ et ！ s'écrivent sans espace avant. Les guillemets « » deviennent 「」 et les espaces insécables du français disparaissent.
• Dates : l'ordre japonais est année, mois, jour (2025年3月14日 ou 2025/03/14). Une valeur comme "dateFormat": "DD/MM/YYYY" n'est pas modifiée par Manuce. Changez-la vous-même, ou formatez les dates avec Intl.DateTimeFormat('ja-JP').
• Monnaie : le yen s'affiche sans décimales, ce que Intl.NumberFormat('ja-JP', { style: 'currency', currency: 'JPY' }) gère pour vous.
• Noms : le nom de famille précède le prénom, et l'on s'adresse au client avec {{name}} 様. L'ordre des champs d'un formulaire relève du composant, pas du fichier de langue.

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

Vous déposez le fichier JSON source (locales/fr/common.json, messages/fr.json…). Manuce rend le même fichier, dans le même format, prêt à devenir locales/ja/common.json ou messages/ja.json.

• Les clés imbriquées, les interpolations {{name}} et les messages ICU sont conservés ; seules les valeurs changent.
• L'indentation, l'ordre des clés, les guillemets, les commentaires, les fins de ligne, l'encodage et le BOM restent ceux de la source. Une comparaison de fichiers ne montre donc que des valeurs.
• Chaque valeur traduite est comparée à la source (variables, balises comme <strong>). Si {{count}} ou une balise manque et que l'écart persiste, la valeur source est gardée et le rapport le signale.
• Ne sont pas traduits : les clés, les valeurs vides, les URL, les adresses email, les nombres, les couleurs, les formats de date, les identifiants et tout ce que vous marquez non traduisible.

Le rapport liste les chaînes traduites et celles laissées telles quelles, avec la raison. Manuce ne touche pas à votre code. Il n'ajoute pas ja à la configuration de Next.js ou d'i18next, ne règle ni les polices ni le CSS, et ne réordonne pas les champs de formulaire. Le prix porte sur les mots des valeurs, clés et balises exclues, avec le coefficient ×1,6 propre au japonais. Pour des conditions générales ou des mentions légales destinées au Japon, notez que Manuce ne fournit pas de traduction assermentée.

Préparer les fichiers et vérifier l'affichage en japonais

Avant l'envoi :

• regroupez les phrases concaténées en une seule clé avec variable ;
• donnez à vos clés des noms parlants, car le traducteur ne voit pas l'écran (checkout.payButton plutôt que btn3) ;
• repérez les noms de marque ou de produit à garder en alphabet latin, et marquez-les non traduisibles.

Après intégration, quelques vérifications sont propres au japonais :

• Attribut de langue : déclarez <html lang="ja">. Sans lui, le navigateur peut choisir une police chinoise et donner à certains kanji un tracé qui paraît étranger à un lecteur japonais.
• Police : prévoyez une pile comme "Hiragino Sans", "Yu Gothic", "Noto Sans JP", sans-serif. Les fichiers de polices japonaises sont lourds ; surveillez le temps de chargement.
• Retours à la ligne : sans espaces, une chaîne peut se couper entre deux caractères quelconques. line-break: strict évite qu'un 。 ou un petit kana ouvre une ligne. Testez en particulier les titres et les boutons étroits.
• Longueur : le japonais compte souvent moins de caractères que le français, mais chaque caractère est plus large. En très petit corps, les kanji deviennent illisibles ; contrôlez les badges et les légendes.
• Italique : la plupart des polices japonaises n'en ont pas de véritable. L'emphase passe plutôt par le gras ou par les crochets 「」.

En pratique

1. Regroupez les phrases découpées en une clé avec variable et marquez les termes à ne pas traduire.
2. Déposez votre fichier JSON source et choisissez le japonais : le devis s'affiche aussitôt et un extrait gratuit vous est proposé.
3. Récupérez le fichier traduit et le rapport, puis placez-le dans le dossier de la locale ja.
4. Ajoutez ja à la configuration de votre projet, déclarez lang="ja" et une police japonaise.
5. Testez les écrans : retours à la ligne, boutons, dates, montants en yens et messages avec compteur.