Traduire un fichier XLIFF en arabe sans casser balises ni variables

Ce que l'arabe change dans un XLIFF

L'arabe s'écrit de droite à gauche, avec des lettres liées dont la forme change selon leur position dans le mot. Dans le fichier, le texte est stocké dans l'ordre logique, celui de la lecture : c'est l'affichage qui l'inverse. Un segment comme Cliquez sur <g id="1">Enregistrer</g> devient en arabe une cible où la balise <g> entoure حفظ, au même rang logique. Ouvert dans un éditeur de texte, le résultat paraît « à l'envers » : c'est normal, il ne faut pas le corriger à la main.

• Texte bidirectionnel : un nom de marque latin ou un espace réservé <x id="INTERPOLATION"/> au milieu d'une phrase arabe peut déplacer visuellement la ponctuation voisine si le conteneur de l'application n'est pas déclaré en dir="rtl".
• Ponctuation propre : virgule ،, point-virgule ؛, point d'interrogation ؟. Un ? latin en fin de chaîne arabe est un signe de traduction négligée.
• Chiffres : les nombres ne sont pas traduits, ils restent en chiffres occidentaux. Si votre public (Égypte, Golfe) attend les chiffres orientaux ٣, c'est le formatage de la locale qui doit s'en charger, pas la chaîne.
• Polices : l'interface doit charger une police qui couvre l'écriture arabe ; un espacement entre lettres forcé en CSS casse les liaisons.

Pluriels et messages ICU : six formes au lieu de deux

L'arabe a six catégories de pluriel CLDR : zero, one, two, few, many, other. Pour « fichier », on écrit ملف (1), ملفان (2), ملفات (3 à 10), ملفًا (11 à 99), et la forme change encore à partir de 100. Un message extrait d'un projet en anglais ou en français ne prévoit souvent que deux branches :

{count, plural, =1 {1 file} other {{count} files}}

Avec ce seul modèle, la cible arabe hérite de deux branches et affichera une forme fausse pour 2, pour 3 ou pour 11. Le plus sûr est d'ajouter les branches dans la source avant l'export : dupliquez le texte de other dans zero, two, few et many. La langue source ignore les catégories qu'elle n'utilise pas, et la cible arabe dispose de toutes les cases à remplir.

Le contrôle de Manuce porte sur les variables et les balises : {count} doit se retrouver dans chaque branche traduite, sinon la valeur source est gardée et le rapport le signale.

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

Vous récupérez le même fichier, dans le même format, prêt à remettre dans le projet :

• XLIFF 1.2 ou 2.0 : la source est traduite dans la cible, l'attribut state est mis à jour ;
• les unités marquées translate="no" sont respectées, les notes du fichier servent de contexte au traducteur ;
• les balises en ligne (<g>, <x/>, <ph>…) sont conservées dans le même ordre ; une chaîne qui les perdrait est refusée et signalée ;
• indentation, ordre, guillemets, commentaires, fins de ligne, encodage et BOM sont conservés : seules les valeurs changent ;
• un rapport : chaînes traduites, chaînes laissées telles quelles et pourquoi.

Ne sont pas traduits : identifiants, valeurs vides, URL, adresses email, nombres, couleurs, formats de date et tout ce qui est marqué non traduisible. Manuce ne règle pas l'affichage de droite à gauche de votre application (attribut dir, miroir des icônes, alignements) : cela se fait dans le code. Le prix porte sur les mots des valeurs, balises exclues, avec le coefficient ×1.6 propre à l'arabe.

Registre et formulation d'une interface en arabe

Une interface se traduit en arabe standard moderne, compris de tous les pays arabophones, et non en dialecte. Deux points méritent l'œil d'un relecteur arabophone :

• Le genre de l'utilisateur : un impératif comme احفظ (« enregistre ») s'adresse à un homme. Les boutons emploient souvent le nom d'action, حفظ (« enregistrement »), qui évite la question.
• L'ordre des mots autour des variables : {user} a partagé {file} peut changer d'ordre en arabe, où la phrase commence volontiers par le verbe. Les variables restent présentes, mais leur position bouge : c'est voulu.

Les notes du XLIFF sont votre meilleur levier : une note « bouton, 12 caractères maximum » ou « sujet : le compte » aide à choisir la bonne forme. Le niveau Professionnel convient à une interface livrée à des utilisateurs ; l'extrait gratuit permet de juger le registre avant de payer.

Préparer et vérifier le fichier

1. Avant l'export : vérifiez que la langue cible déclarée dans l'en-tête est bien ar (ou ar-SA, ar-EG…), que les termes à ne pas traduire portent translate="no", et que les messages de pluriel contiennent les six branches.
2. À la réception : lisez le rapport ; une chaîne gardée en source signale souvent une variable ou une balise ambiguë dans l'original.
3. Dans l'application : testez les écrans avec un nombre égal à 0, 1, 2, 5, 11 et 100 pour voir chaque forme du pluriel, et contrôlez les chaînes qui mêlent arabe et texte latin.
4. Mise en page : les glyphes arabes ont des hampes et des points plus hauts ; vérifiez que les boutons à hauteur fixe ne coupent pas le texte.

En pratique

1. Exportez le XLIFF avec la langue cible ar et les six branches de pluriel en place.
2. Déposez le fichier : le devis s'affiche aussitôt, sur les seuls mots des valeurs.
3. Lisez l'extrait gratuit pour juger le registre et la ponctuation arabe.
4. Payez, puis récupérez le XLIFF traduit et son rapport dans votre espace client.
5. Réimportez le fichier et testez l'affichage de droite à gauche et les pluriels.