Skip to main content
logo logo
Cours de localisation de logiciels 5

5. Sources de problèmes lors de la localisation

Pour la traduction des logiciels, les traducteurs ont affaire à d’autres formes de textes que celles qu’ils traitent habituellement. Par exemple, le texte à traduire dans une interface utilisateur diffère du texte correspondant à l’aide en ligne et aux manuels sous forme papier. Cette variété de textes pose des challenges aux traducteurs chargés de la localisation, notamment en raison du fait qu’ils sont confrontés à plusieurs sources possibles de problèmes. Toutefois, les traducteurs ne peuvent qu’être conscients de ces problèmes potentiels. Il revient aux spécialistes en logiciels et aux développeurs de tenter d’éviter ces sources de problèmes ou de les gérer.

Pour éviter ou gérer ces sources de problèmes, il convient dans un premier temps, avant même de lancer le processus de localisation, d’internationaliser le logiciel. L’internationalisation constitue la première étape pour s’assurer que le produit peut être localisé et qu’il sera opérationnel et accepté sur le marché international.

La localisation d'un logiciel non internationalisé peut engendrer de nombreuses sources de problèmes. Par exemple :

    [FR: Problèmes 2]
    Exemples de références locales et de symboles locaux dans un logiciel
    [FR: Problèmes 2]
    Exemples d'icônes représentant des personnes dans différents logiciels. Notez les différences : les couleurs et les styles de coiffures sont les différences les plus frappantes

    Terminologie : terminologie employée de façon inconsistante par les développeurs de logiciels et les rédacteurs techniques (par ex. utilisation de synonymes pour le même processus ou concept).

    Ambiguïtés : emploi du même terme pour différents processus ou concepts dans le même contexte (par ex. emploi du même terme pour des actions différentes dans l'interface utilisateur).

    Emploi de références locales : les exemples fournis ne doivent pas contenir de références locales, en particulier lorsque les textes rédigés s'adressent à un public cible international, comme c'est souvent le cas des textes d'un logiciel. Dans cette optique, les symboles ne doivent pas contenir de références locales.

    [FR: Texte dans un graphique]
    Exemple de texte dans un bouton

    Texte dans les graphiques : le fait de traduire le texte implique que les graphiques doivent être traités, ce qui peut constituer une tâche très chronophage.

     

    [FR: Problèmes 3]
    Dans la ligne sous "Basic:" l'espace disponible pour le message d'erreur est plus important que dans la ligne sous "C:"

    Abréviations : en raison du manque d'espace disponible, il est fréquent d'employer des abréviations, ce qui peut être problématique si elles ne sont pas employées de façon consistante par les développeurs ou les rédacteurs techniques.

    Espace disponible : concernant les interfaces utilisateur, les développeurs ou rédacteurs techniques doivent garder à l'esprit que la longueur des textes traduits est différente de celle des textes originaux. Par conséquent, il doit être possible de modifier la taille des éléments (par ex. boutons), les boîtes de dialogues doivent pouvoir contenir des passages de texte plus longs et/ou le programme doit réserver de la mémoire pour les messages d'erreurs plus longs.

    [FR: Problèmes 3]
    Dans cet exemple, la variable correspond à "tape" et "disk" en anglais. Mais est-ce que cela va fonctionner dans les autres langues dans lesquelles la forme de ces mots peut changer en fonction du cas, du genre et du nombre ?

    Absence de séparation entre code et texte : bien souvent, le texte à traduire est imbriqué dans le code de programme. Cela pose problème car lorsque l'application est mise à jour, tous les segments doivent à nouveau être traités. Le traducteur risque alors de modifier ou de supprimer le code par erreur. Il est également plus difficile pour un traducteur d'identifier le texte à traduire si celui-ci est imbriqué dans du code de programme. Pour vérifier que le texte et le code sont séparés, les développeurs et les rédacteurs techniques peuvent utiliser des outils d'évaluation (par ex. outils de développement, d'internationalisation, de localisation, etc.).

    Variables : concernant l'emploi de variables dans les messages, les développeurs et rédacteurs doivent tenir compte de la grammaire de la langue cible qui nécessitera éventuellement un ajustement des paramètres. Par exemple dans le message "% files last saved on % at % by %", le caractère "%" devra être placé ailleurs dans dans la langue cible en fonction de l'ordre correct des mots. En outre, la forme grammaticale (genre, nombre, cas) de ces éléments remplacés par des variables peut être différente :

    [FR: Problèmes 3]
    Formats de la date et de l'heure
    [FR: Problèmes 3]
    Format des nombres

    Formats de la date, de l'heure et des nombres : les développeurs et rédacteurs techniques doivent également savoir que les conventions concernant les formats de la date, de l'heure et des nombres peuvent varier en fonction de la langue ou de la culture cible. Il faut alors penser à les adapter.

    (Adapté de Esselink, 2000 et Ottmann, 2002)

     

     

    suivant