Traduire un fichier JSON i18n en arabe

Ce que l'arabe change dans vos chaînes

Une chaîne qui tient en deux formes en français ou en anglais en demande souvent six en arabe. Le pluriel arabe distingue zéro, un, deux, un petit nombre (3 à 10), un grand nombre (11 à 99) et le reste (100, 101…). Un message ICU source comme {count, plural, one {# message} other {# messages}} devient ainsi :

{count, plural, zero {لا توجد رسائل} one {رسالة واحدة} two {رسالتان} few {# رسائل} many {# رسالة} other {# رسالة}}

Le duel (رسالتان, « deux messages ») est une forme à part entière, écrite sans chiffre : la catégorie two ne peut donc pas être remplacée par other.

D'autres différences touchent directement les valeurs :

• Le genre : verbes et adjectifs s'accordent avec la personne à qui l'on parle. « Vous êtes connecté » s'écrit أنتَ متصل pour un homme et أنتِ متصلة pour une femme. Si votre application connaît le genre de l'utilisateur, un message {gender, select, female {…} other {…}} évite d'imposer le masculin.
• La ponctuation : virgule ،, point-virgule ؛ et point d'interrogation ؟ remplacent leurs équivalents latins. « Supprimer ce fichier ? » devient حذف هذا الملف؟, sans espace avant le signe.
• Pas de majuscules : l'alphabet arabe n'a pas de casse. Un text-transform: uppercase sur un bouton reste sans effet, et un letter-spacing casse la liaison entre les lettres.
• Le registre : les interfaces s'écrivent en général en arabe standard moderne, compris dans tous les pays arabophones. Si votre public attend autre chose, vérifiez-le sur l'extrait gratuit.

Droite à gauche, variables et chiffres dans le JSON

Ouvert dans un éditeur de code, un fichier arabe paraît souvent désordonné : une valeur qui mêle texte arabe et variable latine, comme "deleted": "تم حذف {count} ملفات", peut s'afficher avec l'accolade à un endroit inattendu. C'est l'algorithme bidirectionnel de l'éditeur, pas une erreur du fichier. Ne déplacez pas les variables à la main pour « remettre dans l'ordre » : l'ordre logique des caractères est correct, et c'est lui que lit votre bibliothèque.

La position des variables change aussi réellement : la phrase arabe se construit autrement, et {name}, placé en tête en français, peut se retrouver au milieu ou à la fin. Ce qui compte, et que Manuce contrôle, c'est que chaque variable soit présente autant de fois que dans la source.

Pour les chiffres, on écrit 0-9 (chiffres arabes occidentaux, plus courants au Maghreb) ou ٠-٩ (chiffres arabes orientaux, plus répandus au Proche-Orient et dans le Golfe). Manuce ne traduit pas les nombres : un 42 écrit en dur dans une valeur reste 42. Le réglage se fait dans le code : passez les nombres en variables et formatez-les avec la locale voulue (ar-EG, ar-MA…) via Intl.NumberFormat ou le formateur de votre bibliothèque.

Enfin, la direction n'est pas stockée dans le JSON : c'est à l'application de poser dir="rtl" et lang="ar", et d'employer des propriétés CSS logiques (margin-inline-start plutôt que margin-left) pour que la mise en page se retourne.

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

Vous déposez un JSON plat ou imbriqué, avec ou sans tableaux de chaînes, tel qu'il sort d'i18next, react-intl, vue-i18n, next-intl ou ngx-translate. Vous récupérez :

• le même fichier : indentation, ordre des clés, guillemets, commentaires, fins de ligne, encodage et BOM conservés ; seules les valeurs passent en arabe ;
• des clés intactes : "checkout.button.pay" reste "checkout.button.pay" ;
• des variables vérifiées : {name}, {{count}}, %s et les messages ICU plural et select sont comparés chaîne par chaîne à la source ;
• des pluriels ICU complétés : les catégories zero, two, few et many sont ajoutées là où la source n'avait que one et other ;
• un rapport : chaînes traduites, chaînes laissées telles quelles et pourquoi. Si une valeur traduite garde un écart de variables ou de balises avec la source, la valeur source est conservée et le rapport le signale.

Restent tels quels : valeurs vides, URL, adresses email, nombres, couleurs, formats de date, identifiants et tout ce qui est marqué non traduisible.

Ce que Manuce ne fait pas : il ne crée pas de clés. Si votre projet gère le pluriel par suffixes i18next (items_one, items_other), le fichier rendu garde exactement ces clés, sans _zero, _two, _few ni _many. Pour l'arabe, les messages ICU sont la voie la plus sûre. Manuce ne règle pas non plus la direction de l'interface, la police ou le choix des chiffres. L'arabe porte un coefficient ×1,6 sur le prix au mot, compté sur les seuls mots des valeurs.

Préparer le fichier et tester le résultat

Quelques précautions avant le dépôt, puis quelques tests avant la mise en production :

• Encodage : enregistrez la source en UTF-8 ; l'encodage est conservé à l'identique, et l'arabe exige un encodage Unicode.
• Pas de concaténation : t("you_have") + n + t("messages") ne peut pas donner une phrase arabe correcte, puisque le nom change de forme selon le nombre. Une seule chaîne ICU avec {count} règle le problème.
• Termes à garder : nom de produit, marque, sigle en caractères latins. Marquez-les non traduisibles quand votre format le permet, puis vérifiez l'extrait gratuit et la traduction.
• Pluriels : affichez chaque message avec 0, 1, 2, 3, 11 et 100 ; ces six nombres couvrent les six catégories arabes.
• Polices et hauteur : l'arabe a des signes au-dessus et au-dessous de la ligne ; vérifiez que la police contient les glyphes arabes et que les boutons à hauteur fixe ne coupent rien.
• Rapport : traitez chaque chaîne restée en langue source avant de livrer.

En pratique

1. Déposez votre fichier JSON en UTF-8 : le devis s'affiche, calculé sur les mots des valeurs.
2. Choisissez le niveau et lisez l'extrait gratuit traduit en arabe.
3. Payez, puis récupérez le fichier JSON arabe et son rapport.
4. Lisez le rapport et testez les pluriels avec 0, 1, 2, 3, 11 et 100, interface en mode droite à gauche.