Intégrer la traduction dès le départ : conseils pour la phase de conception  

La traduction ne peut pas être une simple mise à jour. Lorsque vous réalisez que l’architecture conçue pour votre logiciel ne prend pas en charge le contenu multilingue, ce n’est pas une mise à jour qui vous attend, mais une refonte importante. 

Préparer les logiciels au contenu multilingue demande une solide base technique. Le système doit permettre de gérer les processus de traduction : pouvoir extraire le contenu à traduire et réimporter les textes validés, prendre en charge les caractères Unicode, adapter les formats de date, les unités monétaires et la mise en page pour différents marchés. Sans cette base, la croissance multilingue entraîne généralement une refonte longue et coûteuse. Les paragraphes suivants abordent les défis techniques les plus courants qui se posent lorsque la phase de conception n’a pas correctement préparé le terrain. 

Les défis techniques des logiciels multilingues 

Au-delà des questions d’organisation et de processus de travail, nombre de défis techniques sont propres au développement de logiciels multilingues. Ci-dessous, nous listons quelques-uns des plus courants.  

Caractères spéciaux et polices compatibles 
Toutes les langues n’utilisent pas l’alphabet latin. Le japonais, le chinois, le coréen, l’arabe, l’hébreu, le grec et de nombreuses autres écritures nécessitent des plages spécifiques de caractères Unicode ainsi que des polices les prenant en charge. Les polices choisies doivent prendre en charge toutes les plages de caractères que vous prévoyez d’afficher. 
Outre les caractères pris en charge, les langues qui se lisent de la droite vers la gauche (RTL) comme l’arabe ou l’hébreu nécessitent une mise en page en miroir. Si votre logiciel est susceptible d’être déployé dans un marché RTL, il faut inclure cette fonctionnalité dès le début. 
Les accents, les trémas, les cédilles et autres caractères similaires, fréquents dans certaines langues, doivent être gérés correctement par toutes les couches. Un rapport de validation qui affiche un point d’interrogation à la place d’un tréma n’est pas un document acceptable dans un cadre réglementé. 

Longueur des textes et mise en page de l’UI 
Un défi qui est souvent oublié lors d’une traduction est la variation dans la longueur des textes. Une phrase qui s’affiche parfaitement sur un bouton en anglais peut être 30-40% plus longue en français ou en espagnol, ou 60% plus courte en chinois. Si votre UI est conçue avec des éléments à largeur fixe, adaptés au texte anglais, les interfaces traduites ne s’afficheront pas correctement : le texte dépassera, sera tronqué, ou s’ajustera d’une manière qui rend l’interface inutilisable. 

Date, heure, nombres et unités 
Les différences géographiques ne s’arrêtent pas à la langue. Le format de date (JJ/MM/AAAA, MM/JJ/AAAA ou AAAA-MM-DD), le séparateur décimal (point ou virgule), le séparateur de milliers ou encore les unités utilisées varient selon le lieu. Dans les domaines réglementés, particulièrement les dispositifs BPF/BPC et les logiciels IVD, un format de nombre ou d’unité incorrect n’est pas qu’un enjeu esthétique : il pose un problème d’intégrité des données. Il est recommandé d’utiliser une bibliothèque de mise en forme adaptée aux variations géographiques, et de vérifier que tous les nombres s’affichent correctement dans toutes les langues.