Localiser les chaînes d’une application arabe : contexte et variables

La localisation de chaînes d’application en arabe commence bien avant la traduction d’un bouton. Une même expression peut désigner une action, un état ou un objet selon l’écran. Une variable peut contenir un nom, un nombre ou une référence latine. Sans ces informations, une traduction grammaticalement correcte risque d’induire l’utilisateur en erreur ou de casser le message affiché. Le bon livrable associe donc le texte, son contexte et les règles qui permettent au produit de le construire.

Ce guide explique comment préparer un kit de localisation exploitable, protéger les paramètres, traiter les variantes et valider les messages dans l’interface. Il s’adresse aux responsables produit, développeurs et réviseurs qui souhaitent organiser une version arabe durable, plutôt qu’un simple tableau rempli de traductions isolées.

Localisation de chaînes d’application : expliquer ce que le texte fait

Décrivez d’abord l’action attendue. Un libellé équivalent à « ouvrir » peut ouvrir un fichier, développer un panneau ou autoriser une nouvelle session. Le traducteur doit savoir quelle conséquence suit le clic, si l’action est réversible et quel objet est concerné. La précision du contexte permet souvent d’obtenir un texte plus court, parce qu’elle évite une formule générale inutilement prudente.

Ajoutez le type de composant : bouton, titre, aide, notification ou message d’erreur. Une phrase destinée à expliquer une opération ne convient pas automatiquement à son bouton de confirmation. Indiquez également qui parle à qui. Le produit peut s’adresser au titulaire du compte, à un administrateur ou à un collègue invité ; cette relation influence le ton et certaines constructions arabes.

Pour un projet de localisation de site et d’application, un contexte documenté aide aussi à distinguer les demandes linguistiques des évolutions fonctionnelles. Si le texte source décrit mal le comportement réel, le problème doit revenir au responsable produit avant d’être reproduit dans les autres langues.

Conserver des identifiants stables et lisibles

Une clé de message sert de repère commun aux développeurs, traducteurs et testeurs. Choisissez un identifiant stable qui permet de retrouver le composant sans faire dépendre toute l’organisation de la phrase anglaise actuelle. Lorsque le texte évolue, la discussion doit pouvoir continuer à citer le même emplacement et la même fonction.

Évitez de réutiliser une clé uniquement parce que deux libellés se ressemblent. Le mot « terminé » peut signifier qu’une tâche a réussi ou que l’utilisateur souhaite fermer une fenêtre. Une traduction unique impose alors une confusion au produit. Séparez les usages dès que leur sens, leur rôle grammatical ou leur comportement divergent.

Inversement, ne créez pas plusieurs traductions concurrentes pour une même action récurrente. Reliez les composants qui doivent partager un libellé validé et expliquez les exceptions. Une cartographie des clés est plus utile qu’une cohérence obtenue en remplaçant aveuglément tous les mots identiques.

Assembler un kit qui répond aux questions du réviseur

Le fichier source doit inclure la clé, le texte, le commentaire produit, les paramètres et l’emplacement de l’écran. Ajoutez une capture quand la mise en page ou la relation avec les composants voisins modifie l’interprétation. Un lien vers une maquette peut compléter la capture, mais le kit doit rester compréhensible lorsque le lien devient indisponible.

Précisez le statut des chaînes : nouvelle, modifiée, supprimée ou inchangée. Joignez les formulations déjà approuvées lorsqu’elles servent de référence. Une livraison qui mélange des versions anciennes et nouvelles sans les signaler oblige le réviseur à reconstituer le changement, avec un risque de laisser passer une incohérence importante.

Indiquez enfin les contraintes réellement vérifiées. Une limite de caractères n’équivaut pas à une largeur d’affichage. Les lettres arabes se combinent différemment selon la police et le rendu. Un bouton sur téléphone doit donc être testé dans son composant, même si la traduction respecte une limite annoncée dans le tableau.

Protéger les paramètres sans figer l’ordre de la phrase

Un paramètre représente une valeur fournie par le produit. Il peut s’agir du nom d’une personne, du nombre de fichiers ou d’une heure. Documentez sa nature et fournissez des exemples plausibles, sans données personnelles réelles. Le traducteur doit préserver l’identifiant technique tout en pouvant placer la valeur là où la phrase arabe l’exige.

La documentation officielle ICU sur les messages explique l’intérêt de traduire des unités complètes avec leurs variables. Le principe utile pour le projet est simple : le texte doit laisser la langue organiser sa phrase. Le format précis dépend toutefois de la bibliothèque effectivement utilisée par votre application.

Demandez au développeur quels éléments sont modifiables et lesquels doivent rester identiques. Accolades, balises ou noms de variables ne sont pas des mots à traduire. Une vérification automatique peut repérer leur disparition, mais elle ne remplace pas la lecture d’un message construit avec de vraies valeurs et affiché à l’utilisateur.

Éviter les phrases assemblées à partir de fragments

Une interface peut fabriquer une phrase en collant un préfixe, un nombre et un nom d’objet. Cette architecture paraît économique dans la langue source, mais elle limite la possibilité de réorganiser la phrase et de choisir une forme grammaticale adaptée. Demandez si le message peut devenir une unité complète, plutôt qu’une succession de morceaux imposés.

Prenons un exemple fictif : une notification assemble « vous avez », une quantité et « nouvelle demande ». La traduction ne doit pas seulement trouver des équivalents pour ces segments. Elle doit exprimer naturellement le résultat pour les valeurs prévues. La résolution concerne la structure du message autant que son vocabulaire.

Si la correction technique n’est pas immédiate, notez la limite dans le journal de livraison. Évitez de présenter une formulation provisoire comme une solution générale pour tous les nombres ou tous les objets. Une exception identifiée peut être suivie ; une limitation cachée réapparaîtra dans les fonctionnalités suivantes.

Définir les variantes et tester les valeurs utiles

Les variations numériques ne se résument pas nécessairement à un singulier et un pluriel. Les règles de pluriel du projet Unicode CLDR donnent le cadre linguistique utilisé par de nombreux outils. Vérifiez cependant les catégories et la syntaxe prises en charge par le moteur choisi, plutôt que de supposer un comportement identique partout.

Préparez des cas d’essai couvrant les branches du message réellement configurées, ainsi que l’absence de résultat. Une phrase qui annonce qu’aucun document n’est disponible peut être plus utile qu’un compteur artificiel. La décision revient au produit : le texte doit expliquer l’état et proposer une suite cohérente.

Les variables de genre ou de personne demandent la même attention. N’inférez pas une information personnelle à partir d’un prénom pour sélectionner une variante. Examinez les données disponibles et cherchez, lorsque c’est possible, une formulation neutre qui reste claire. Documentez les décisions pour éviter des traitements contradictoires entre écrans.

Exemple de fiche de contexte pour une chaîne

Cette fiche est un modèle de travail, pas un format obligatoire. Adaptez ses colonnes à l’outil utilisé. Sa valeur tient aux réponses qu’elle conserve : une capture spectaculaire ne compense pas un paramètre inexpliqué, et une liste exhaustive de clés ne suffit pas si leur fonction reste inconnue.

Prévoir les valeurs latines et les textes longs

Une chaîne arabe peut contenir une adresse électronique, une référence commerciale ou un code de commande. Ajoutez des valeurs mixtes aux essais pour observer leur ordre, leur ponctuation et leur interaction avec le texte environnant. Une prévisualisation qui utilise uniquement un prénom court en arabe ne couvre pas ces situations.

Testez également une donnée longue : nom d’organisation, document à titre étendu ou chemin fourni par l’utilisateur. Le composant doit expliquer le résultat sans masquer la seule information distinctive. La manière de couper ou de développer cette donnée relève du design et du développement ; la révision linguistique doit rendre visible le besoin.

Les textes saisis par l’utilisateur ne doivent pas être réécrits silencieusement pour arranger la traduction. Clarifiez ce qui est affiché, ce qui est transformé et ce qui sert d’identifiant. Un message de confirmation doit permettre à la personne de reconnaître sa propre action, même lorsque certaines valeurs conservent leur graphie source.

Faire de la capture une preuve de recette

Une capture utile montre le composant dans son écran, avec la version de l’application et le scénario qui l’a produit. Le réviseur peut alors distinguer une mauvaise traduction d’un texte remplacé par la mauvaise clé. Ajoutez les étapes pour reproduire un état rarement visible, comme une invitation expirée ou une opération interrompue.

Contrôlez ensemble les titres, boutons et notifications d’un parcours. Leur cohérence ne se voit pas toujours dans l’ordre alphabétique d’un export. Un utilisateur qui clique sur « envoyer » doit retrouver une confirmation qui nomme la même opération, sans changement soudain de vocabulaire entre l’écran et le message reçu.

La révision linguistique peut établir ces corrections, puis la recette visuelle confirme leur intégration. Gardez un responsable pour chacun de ces deux contrôles. Valider un fichier de traduction ne signifie pas que l’application finale a effectivement chargé ce fichier et présenté chaque état correctement.

Dans une recette fictive, une notification correctement traduite affiche pourtant le nom de fichier à la place du nom de son propriétaire. Corriger les mots ne résout rien : il faut vérifier la correspondance entre la clé et les valeurs injectées. Conservez alors le message modèle, les données de test et la capture du résultat dans le même signalement. Cette association permet à l’équipe technique de reproduire le défaut, puis au réviseur de confirmer que la correction restitue bien la relation prévue.

Organiser les modifications après la première livraison

Une application change régulièrement. Préparez un export différentiel qui montre les chaînes nouvelles et les changements de contexte, y compris lorsque le texte source reste identique. Un bouton déplacé vers une opération plus sensible peut demander une nouvelle formulation sans qu’un outil de comparaison de texte le détecte.

Conservez les décisions du glossaire et les raisons des exceptions. Quand une nouvelle équipe reprend le produit, elle doit pouvoir comprendre pourquoi un terme a été choisi. Les services linguistiques gagnent en continuité lorsque les connaissances du projet sont accessibles, plutôt que dispersées dans des conversations anciennes.

Avant la publication, comparez l’export approuvé à la version intégrée. Signalez les clés manquantes, les retours à une langue de secours et les messages encore provisoires. Une livraison complète comporte les traductions et un relevé clair des réserves ; elle n’affirme pas que des écrans non accessibles ont été testés.

Checklist avant d’envoyer les chaînes en traduction

• Chaque texte possède une fonction, un emplacement et un identifiant retrouvable.
• Les paramètres sont décrits, avec leurs formes techniques préservées.
• Les variantes prévues sont visibles et accompagnées de valeurs de test.
• Les captures couvrent les erreurs, les états vides et les confirmations.
• Les limites d’affichage distinguent caractères et largeur du composant.
• Les textes réutilisés partagent réellement le même sens dans chaque écran.
• Le responsable produit peut répondre aux ambiguïtés avant validation.

Utilisez cette liste pour repérer les informations manquantes, non pour bloquer inutilement un projet. Certaines chaînes simples se traduisent avec un contexte bref. Concentrez l’effort de documentation sur celles dont la mauvaise interprétation modifie une action, un résultat ou une relation entre l’utilisateur et le produit.

Questions fréquentes sur les chaînes arabes

Une capture suffit-elle pour traduire un bouton ?

Elle montre la place du bouton, mais pas forcément son comportement. Ajoutez l’action déclenchée et le résultat attendu. Si le bouton peut supprimer une donnée ou valider une décision, précisez cette conséquence. Une brève description fonctionnelle est souvent plus utile que plusieurs captures presque identiques.

Faut-il traduire le nom des variables ?

Non, lorsqu’il s’agit d’un identifiant reconnu par le code. Traduisez le texte destiné à l’utilisateur et conservez la syntaxe nécessaire au moteur. Si les règles d’édition ne sont pas claires, demandez un exemple valide au développeur. Le contrôle doit ensuite vérifier le message produit, pas seulement son modèle.

Peut-on imposer la même longueur que le texte anglais ?

Une contrainte doit correspondre à un besoin d’affichage réel. La même quantité de caractères ne garantit pas la même largeur ni la même lisibilité. Fournissez une limite utile, puis prévoyez une recette dans la police et le composant utilisés. Si le sens ne tient pas, examinez aussi la conception de l’écran.

Comment traiter les chaînes rarement affichées ?

Documentez le scénario et fournissez un moyen de le reproduire avec des données fictives. Les erreurs et les états d’exception sont précisément ceux où l’utilisateur a besoin d’aide. Ne les laissez pas sans contexte parce qu’ils ne figurent pas dans le parcours de démonstration habituel.

Que transmettre pour lancer le projet ?

Envoyez l’export structuré, le glossaire existant, quelques parcours et les contraintes du moteur de messages. Ajoutez les captures significatives et la personne responsable des questions produit. Vous pouvez présenter votre projet de localisation en indiquant les écrans concernés et le mode de validation attendu.