Traduire une application React ou Next.js en anglais

Les fichiers de messages d'un projet React ou Next.js

Dans un projet React ou Next.js, le texte de l'interface se trouve dans des fichiers JSON, un par langue\u00a0: public/locales/fr/common.json avec i18next et react-i18next, messages/fr.json avec next-intl, un fichier de messages ICU, souvent à clés plates, avec react-intl. C'est ce fichier que vous déposez, tel qu'il est dans le dépôt.

Manuce prend en charge ces trois syntaxes\u00a0: les clés imbriquées ("checkout": { "cta": "Payer" }), les interpolations i18next ({{name}}) et les messages ICU de react-intl et next-intl ({count, plural, one {# article} other {# articles}}). Les clés, les noms de variables et la structure ICU restent intacts\u00a0; seul le texte est traduit.

Le prix porte sur les mots des valeurs, clés et balises exclues\u00a0: un fichier très imbriqué, aux clés longues comme dashboard.settings.notifications.title, ne coûte pas plus cher qu'un fichier plat. L'anglais est au tarif de base (coefficient ×1).

Une limite propre à React\u00a0: seul le texte présent dans ces fichiers est traduit. Les chaînes écrites en dur dans les composants .tsx, ou directement dans generateMetadata sous Next.js, n'y figurent pas. Si vous voulez qu'elles passent en anglais, déplacez-les d'abord dans le fichier de messages.

Ce qui change en passant du français à l'anglais

• Pluriels. Le français utilise les catégories one, many et other\u00a0; l'anglais n'en a que deux, one et other. Elles ne se recouvrent pas\u00a0: en français, 0 relève de one («\u00a00\u00a0fichier\u00a0»), en anglais de other («\u00a00 files\u00a0»). Avec i18next, chaque clé doit avoir sa forme _other\u00a0: items_one donne «\u00a0{{count}} item\u00a0», items_other donne «\u00a0{{count}} items\u00a0». Une clé _many venue du français reste dans le fichier anglais\u00a0; la locale en ne la sélectionne jamais.
• Ponctuation. L'espace avant les deux-points, le point d'interrogation ou le point d'exclamation disparaît\u00a0: «\u00a0Total\u00a0:\u00a0» devient «\u00a0Total:\u00a0». Les guillemets français cèdent la place aux guillemets anglais.
• Britannique ou américain. La différence tient à quelques mots (colour/color, cancelled/canceled, organise/organize) et au code de locale, en-GB, en-US ou simplement en. Décidez de la variante visée et vérifiez-la dans l'extrait gratuit.
• Longueur. L'anglais est en général 10 à 15\u00a0% plus court\u00a0: «\u00a0Enregistrer les modifications\u00a0» devient «\u00a0Save changes\u00a0». Les boutons gagnent de la place, mais un libellé d'un seul mot peut devenir ambigu\u00a0: «\u00a0Order\u00a0» désigne aussi bien une commande qu'un ordre de tri.
• Ordre des mots. Une phrase découpée en plusieurs clés («\u00a0Bonjour\u00a0», puis le nom, puis «\u00a0bienvenue\u00a0») se traduit mal. Préférez une seule chaîne avec {{name}}, ou le composant Trans, pour que l'anglais place la variable où il le faut.

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

Vous récupérez le même fichier, au même format\u00a0: indentation, ordre des clés, guillemets, commentaires, fins de ligne, encodage et BOM conservés. Seules les valeurs changent. Le fichier se place tel quel dans public/locales/en/, ou sous le nom en.json à côté de messages/fr.json. Une comparaison avec la version française ne fait apparaître que des lignes de valeurs.

Chaque valeur traduite est comparée à la source\u00a0: si un {{count}}, un {name} ou une balise de rich text comme <0> ou <b> manque ou change, l'écart est détecté. S'il persiste, la valeur française est conservée et le rapport le signale. Une chaîne restée en français se repère en recette\u00a0; une variable mal écrite casserait l'affichage.

Ne sont pas traduits\u00a0: les clés, les valeurs vides, les URL, les adresses email, les nombres, les couleurs, les formats de date ("dateFormat": "dd/MM/yyyy" reste tel quel), les identifiants et tout ce qui est marqué non traduisible. Le rapport liste les chaînes traduites et celles laissées telles quelles, avec la raison.

Manuce n'extrait pas les textes de vos composants, ne configure pas les locales de votre routage Next.js, n'ajoute pas de clés de pluriel absentes de la source et n'adapte pas vos formats de date à l'usage américain\u00a0: ces réglages restent de votre côté.

Préparer le fichier et vérifier après intégration

• Partez du fichier français le plus récent et assurez-vous qu'il s'agit d'un JSON valide (pas de virgule après le dernier élément).
• Vérifiez que chaque clé plurielle française a bien sa forme _other\u00a0: sans elle, la version anglaise n'en aura pas non plus.
• Regroupez en une seule valeur les phrases découpées en fragments.
• Après intégration, affichez les écrans concernés avec 0, 1 et 2 éléments pour contrôler les pluriels.
• Formatez dates et nombres avec Intl.DateTimeFormat et Intl.NumberFormat selon la locale\u00a0: «\u00a01\u00a0234,56\u00a0» devient «\u00a01,234.56\u00a0», et le 03/04 se lit 3\u00a0avril en en-GB mais 4\u00a0mars en en-US.
• Sous Next.js, vérifiez que la page anglaise porte lang="en" sur la balise html, puis relisez le rapport pour traiter les chaînes restées en français.

En pratique

1. Récupérez dans le dépôt le fichier de messages français (fr.json, common.json ou équivalent).
2. Déposez-le sur Manuce, consultez le devis et l'extrait gratuit en anglais.
3. Téléchargez le fichier anglais et le rapport des chaînes traduites ou conservées.
4. Placez le fichier dans le dossier de la locale anglaise et testez pluriels, variables, dates et nombres.