Traduire un fichier JSON i18n en anglais

Ce qui change quand les valeurs passent en anglais

L’anglais ne connaît que deux catégories de pluriel CLDR : one et other. Le piège vient du zéro. En français, one couvre 0 et 1 (« 0 fichier ») ; en anglais, one ne vaut que pour 1, et 0 tombe dans other (« 0 files »). Concrètement :

• Message ICU : {count, plural, one {# fichier} other {# fichiers}} devient {count, plural, one {# file} other {# files}}. Si vous voulez un texte propre à zéro (« No files »), c’est une branche =0 à prévoir dans la source.
• Clés à suffixe i18next : files_one et files_other restent telles quelles, seules leurs valeurs sont traduites. En anglais, la valeur de files_one ne s’affichera plus que pour 1.
• Si votre fichier français contient une branche many ou des clés _many (catégorie que le CLDR attribue au français pour les grands nombres ronds), l’anglais ne la sélectionnera jamais : c’est sans effet à l’affichage.

La typographie change aussi. « Mot de passe : » devient Password:, sans espace avant les deux-points ; « 10 % » devient 10%, et les espaces insécables (\u00a0) du français disparaissent. Les guillemets « » laissent place aux guillemets anglais ; à l’intérieur d’une valeur JSON, un guillemet droit doit rester échappé (\").

Enfin, le texte anglais est en général 10 à 15 % plus court que le français : les boutons et onglets tiennent sans peine. En revanche, un libellé d’un seul mot comme « Ouvrir » ou « Partager » perd son contexte une fois isolé ; un nom de clé explicite (menu.file.open) aide à lever l’ambiguïté.

Anglais britannique ou américain : ce que le fichier ne tranche pas

Une interface en anglais vise souvent un marché précis. Les écarts se voient dans les chaînes courtes : colour/color, cancelled/canceled, organise/organize, postcode/ZIP code. Regardez l’orthographe retenue dans l’extrait gratuit avant de payer, et confrontez-la au nom de votre fichier de destination (en.json, en-GB.json ou en-US.json).

Les formats de date stockés comme valeurs, par exemple "dateFormat": "DD/MM/YYYY", ne sont pas traduits. Pour un public américain, c’est à vous de passer à MM/DD/YYYY, ou mieux, de laisser Intl.DateTimeFormat formater selon la locale. Même chose pour les séparateurs décimaux écrits en dur dans une chaîne.

Autre point à surveiller : la casse des titres. Une interface anglaise peut écrire « Save changes » (casse de phrase) ou « Save Changes » (casse de titre). Le français n’a pas cette distinction : décidez de la convention de votre produit et vérifiez qu’elle est tenue d’un écran à l’autre.

Le registre, lui, se simplifie : tutoiement et vouvoiement deviennent tous deux you. Un select sur le genre (« Vous êtes connecté » / « connectée ») garde toutes ses branches et sa variable, même si le texte anglais y devient identique : Signed in.

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

Le fichier rendu est le même que celui que vous avez déposé : indentation, ordre des clés, guillemets, commentaires, fins de ligne, encodage et BOM conservés. Seules les valeurs changent. JSON plat ou imbriqué et tableaux de chaînes sont pris en charge.

• Les variables {name}, {{count}}, %s et les messages ICU (plural, select) sont vérifiés chaîne par chaîne : mêmes variables, autant de fois.
• Les catégories de pluriel ICU que réclame l’anglais (one, other) sont présentes ; si l’une manque, elle est ajoutée.
• Chaque valeur traduite est comparée à la source (variables, balises). En cas d’écart persistant, la valeur source est gardée et le rapport le signale.
• Ne sont pas traduits : clés, valeurs vides, URL, adresses email, nombres, couleurs (#1A73E8), formats de date, 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. Le prix porte sur les mots des valeurs seulement, clés et balises exclues ; l’anglais est au tarif de base (coefficient ×1).

Ce que Manuce ne fait pas : renommer ou réorganiser les clés, adapter vos formats de date au marché visé, recevoir un glossaire ou une liste de termes. Il ne produit pas non plus de traduction assermentée, ce qui n’a de toute façon pas de sens pour un fichier d’interface.

Préparer le fichier et vérifier au retour

Avant le dépôt :

• Assurez-vous que le fichier se charge sans erreur dans votre projet : une virgule en trop casse la lecture.
• Supprimez les clés obsolètes : vous payez les mots des valeurs, inutile de traduire des écrans disparus.
• Marquez comme non traduisibles les valeurs qui doivent rester en l’état (nom de produit, code de plan).
• Si un terme doit être rendu d’une seule façon (« Se connecter » en Sign in plutôt que Log in), contrôlez-le dans l’extrait gratuit puis dans la traduction livrée.

Au retour :

1. Comparez les deux versions avec un outil de différence (git diff) : seules les valeurs doivent bouger, aucune clé.
2. Lancez l’application avec la locale en et testez un compteur à 0, 1 et 2 pour voir les branches one et other.
3. Lisez le rapport : chaque valeur gardée en français y figure, avec sa raison, et se corrige à la main.
4. Relisez les chaînes d’un mot dans leur écran réel, là où le contexte manquait.

En pratique

1. Exportez le fichier JSON de la locale source et vérifiez qu’il se charge sans erreur.
2. Déposez-le sur Manuce : le devis est calculé sur les mots des valeurs seulement.
3. Lisez l’extrait gratuit en anglais (orthographe, termes clés), puis choisissez le niveau.
4. Récupérez le même fichier traduit et le rapport, comparez-les avec git diff, puis testez l’application en locale en.