
Qu'est-ce que la localisation de logiciels ?

La
localisation de logiciels comprend des étapes telles que :
- Préparation du code pour la traduction
- Exportation des chaînes logicielles
- Ajustement des stratégies d'analyse et de segmentation
- Élaboration d'une liste terminologique clé (glossaire)
- Création du projet de traduction de logiciel
- Affectation de traducteurs
- Affectation aux réviseurs
- Gestion des requêtes
- Contrôles qualité automatisés
- Réimportation des chaînes traduites
- Contrôles QA soit dans l'environnement de préproduction, soit sur des captures d'écran
- Tests
Dans cet article, nous allons explorer ces différents composants et leurs implications dans le processus de localisation global.
Préparation du code pour la traduction
Bien que certains logiciels soient codés en pensant à la traduction, il arrive souvent que la traduction soit une exigence qui apparaît lorsque le logiciel est déjà mature. Pour préparer le code pour la traduction, il faut se pencher plus près sur les variables, les dates et l'architecture globale du contenu translatable par rapport au code. Les dates, la devise et d'autres facteurs changent de format selon la région. S'ils sont codés en dur, ils devront être recodés en tant qu'entités dynamiques afin de permettre une flexibilité interculturelle. Selon la façon dont le code est écrit, il peut être très facile ou difficile d'isoler le code du texte traduisible. Cela aura une incidence sur l'étape suivante de l'exportation des chaînes, mais c'est peut-être l'aspect le plus négligé et sous-estimé de la localisation du logiciel. Chaque ondulation dans le code par rapport à la simplicité du texte entraînera d'innombrables vagues qui auront un impact sur le processus de localisation dans son ensemble. Cela peut entraîner des scénarios où il est difficile de préserver l’intégrité du code ou de le rendre convivial pour les traducteurs. Bien sûr, vous pouvez surmonter certains de ces défis grâce à des stratégies d'analyse et de segmentation, mais plus vous pourrez exporter du contenu traduisible sans interférence de code, meilleur sera (plus durable et évolutif) votre processus de localisation de logiciels.
Exportation des chaînes logicielles
L'exportation des chaînes doit être un processus simple. Mais ce n'est pas. Certains formats sont accessibles alors que d'autres devraient être évités. Exemples de formats incontournables : XML, YAML, JSON. Ils sont structurés, prévisibles, facilement analysables et relativement faciles à trouver dans le code, ce qui réduit les problèmes résultant de la traduction dans différentes langues. Exemples de formats à éviter : TXT, CSV, code mixte. Une exportation CSV par exemple peut devenir un cauchemar. Les caractères de délimitation tels que les points-virgules sont nécessaires comme outils linguistiques. Il est pratiquement impossible de faire la distinction algorithmique entre un point-virgule qui est conçu comme une rupture de code et un point-virgule qui est conçu comme un outil linguistique. Cela crée des centaines de faux positifs qui doivent être vérifiés pendant le processus d'assurance qualité ainsi que des problèmes lors de la réimportation de code, etc. Avec du code mixte, par exemple, nous nous référons à XML avec JSON comme exemple, ce qui ajoute à la complexité du processus d'analyse et de segmentation. L'encodage est également un problème clé :
- Encodage HTML
- Encodage d'URL
- Encodage Unicode
- Encodage Base64
- Encodage hexadécimal
- Encodage ASCII
Chacun de ces cadres d'encodage aura des ramifications dans le processus de localisation, y compris l'incompatibilité des caractères selon les langues concernées.
Ajustement des stratégies d'analyse et de segmentation
Si vous avez suivi les bonnes pratiques décrites ci-dessus, vos stratégies d'analyse et de segmentation seront des optimisateurs de processus. Si vous ne l'avez pas fait, l'analyse et la segmentation deviendront des activateurs de processus. En tant qu'optimiseurs de processus, une stratégie de parsfine-tunedgmentation affinée garantira que le contenu est ingéré par votre système de gestion de la traduction de manière conviviale pour les traducteurs et les réviseurs. C'est là que vous pouvez vous assurer que les variables sont protégées, que tout code restant est protégé et que le texte est cassé de manière logique pour le processus de traduction. Si vous n'avez pas fait vos devoirs, c'est l'étape où les choses peuvent devenir folles. Soit parce qu'il est tout simplement impossible de créer suffisamment d'analyse pour protéger le code et les variables, soit parce qu'il faudra un niveau d'effort insensé pour écrire suffisamment d'expressions régulières pour rendre le contenu du logiciel plus convivial pour la traduction. Dans tous les cas, il s'agit d'une étape cruciale. Si vous modifiez la stratégie d'analyse et de segmentation au fil du temps, vous subirez une perte d'exploitation de la mémoire de traduction, ce qui entraînera des coûts supplémentaires et la complexité du processus. Cela peut ne pas sembler grave jusqu'à ce qu'il explose sur votre visage. Supposons, par exemple, que l'intégralité de votre logiciel comporte 100 000 mots, que vous traduisiez dans 10 langues et que votre coût moyen par mot soit de 0,15 €. Supposons que vous avez traduit votre logiciel mais que vous réitérez maintenant votre stratégie d'analyse, mais cela entraînera une perte de 10 % de l'effet de levier (ce qui peut être le résultat attendu d'une modification mineure de l'analyse), soit 15 000 $ perdus dès le départ, sans parler du temps supplémentaire nécessaire et d'autres ramifications.
Développement d'une liste terminologique clé (glossaire)
N'importe qui peut développer un glossaire. Très peu peuvent développer un grand. Certaines personnes optent pour la voie statistique et exploitent une base de données de contenu pour la plupart des mots clés récurrents. Et bien que cela accélère les choses et capture les termes qui sont importants en fonction de la fréquence, plusieurs termes clés ne sont pas nécessairement utilisés fréquemment. Certaines personnes adoptent l'approche qualitative et demandent aux traducteurs de parcourir des tonnes de contenu et d'identifier manuellement les termes pertinents. D'autres utilisent l'IA pour rechercher des modèles linguistiques et identifier des entités et des termes qui ne sont pas nécessairement basés uniquement sur la fréquence mais sur leur pertinence sémantique globale. Quelle que soit l'approche, lorsqu'il s'agit d'un glossaire, moins c'est plus. Bien que vous vouliez vous assurer que vous avez capturé les termes essentiels, si vous marquez trop de termes comme termes de glossaire, il est presque impossible d'assurer la gouvernance d'une application correcte. Trop de faux positifs et d'alertes rendent difficile pour les traducteurs et les réviseurs de gérer les suggestions de termes et d'exécuter des vérificateurs d'assurance qualité automatisés. Une autre astuce avec les glossaires est qu'il est aussi important de signaler les termes qui ne doivent pas être traduits que ceux qui nécessitent un type de traduction spécifique.
Création du projet de traduction logicielle
Cette étape dépend fortement de la structure du système de gestion de la traduction que vous utilisez. Certains systèmes vous permettront de gérer l'intégralité du cycle de vie du projet dans le même environnement et le même projet, tandis que d'autres plates-formes nécessiteront un temps d'approche différent pouvant être basé sur des chaînes ou des fichiers. Bien que cela puisse sembler une formalité, la mise en place du projet de traduction proprement dit comporte des points de contrôle clés tels que :
- S'assurer que les fichiers ont été ingérés dans leur totalité
- S'assurer que les paires de langues sont correctes jusqu'au niveau local
- S'assurer que les dates sont correctes
- S'assurer que les étapes du workflow sont celles qui sont nécessaires
- Affectation de traducteurs
Dans cette étape, nous supposons que vous disposez déjà d'une équipe de traducteurs préalablement sélectionnés à votre disposition par paire de langues. Il est essentiel de travailler avec des traducteurs qui sont :

Comme pour les traducteurs, avec un accent supplémentaire sur le discernement critique. Vous avez besoin de réviseurs suffisamment critiques pour comprendre les différences entre le style et les erreurs. Les examinateurs qui changent trop à ce stade du processus compromettent l'intégrité du processus de traduction dans son ensemble. C'est là que le cadre de gestion de la qualité propriétaire de Bureau Works entre en jeu.
Gestion des requêtes
Un élément clé de la traduction de logiciels est de pouvoir répondre aux questions qui se posent au cours du processus de traduction. Par exemple, que signifie le bouton « X » ou vers quoi cette variable pointe-t-elle ? Il est important d'avoir un processus qui vous permette de poser des questions concernant la langue source et de mettre les réponses à la disposition de tous les traducteurs du projet, quelle que soit leur paire de langues, afin de minimiser le besoin de répondre à la même question encore et encore. Il est également essentiel d'avoir un moyen d'attribuer différents statuts à la requête, tels que nouveau, attribué, résolu, etc., afin que votre équipe de gestion de projet puisse s'assurer que les requêtes reçoivent une réponse en temps opportun.
Checks automatisés pour l'assurance de la qualité
Critiques pour tout processus de localisation du software, les contrôles automatisés pour l'assurance de la qualité veillent à ce que certains éléments clés soient signalés comme :
- Espaces de fin
- Limites de caractères
- Ponctuation incohérente
- Non-respect du glossaire
- Orthographe
- Tags incohérents (incohérences dans le code source et le code traduit)
- Réimporter des chaînes traduites
Si vous êtes arrivé jusqu'ici, vous faites quelque chose de bien ! :) Cela peut être moins douloureux, mais vous êtes là. Il est maintenant temps de réimporter les chaînes dans votre référentiel et de reconstruire le logiciel. Si vous avez manqué ou mal généficié d’une des meilleures pratiques décrites précédemment, vous risquez de vous heurter à ce stade avec des problèmes dans le processus de réimportation en raison de défaillances dans le code, d’incohérences des balises ou d’autres problèmes susceptibles d’avoir une incidence sur la reprise réussie du code.

Source : Linkedin
Vérifications QA dans l'environnement de test ou sur les captures d'écran
Cette étape peut être ignorée si elle est fusionnée avec les tests, mais il est utile de fournir aux traducteurs l'accès à un environnement de test ou des captures d'écran des écrans principaux pour s'assurer que les chaînes s'affichent correctement et qu'il n'y a pas de problèmes flagrants qui empêchent le démarrage des tests.
Testing
This is a stage that drives quality beyond the obvious bug detection and fixes. Les tests permettent un autre regard neuf sur les chaînes traduites en contexte. Certaines traductions qui semblaient parfaites pendant le processus de traduction, ne sont peut-être pas les meilleures du point de vue de l'expérience utilisateur. Il est important de travailler avec des testeurs qui s'engagent à chercher à améliorer l'expérience utilisateur et pas seulement à rechercher de manière réactive les bogues.
Conclusion
La localisation de logiciels est un processus long, coûteux et complexe. Mais il n'y a pas que ça. Il est itératif et continu, ce qui signifie que vous passerez d'innombrables fois par le même processus afin de mettre à jour votre logiciel au fur et à mesure de son évolution. Il s'agit d'un aperçu de haut niveau et superficiel d'un processus qui peut devenir infiniment plus nuancé et complexe à gérer. Mais l'essentiel à retenir est qu'il vaut chaque centime investi dans un cadre et les meilleures pratiques dès le début. Une fois que le navire a navigué, il deviendra de plus en plus difficile et coûteux de le réparer.