Localisation logicielle

La régionalisation de logiciel concerne le processus de traduction de l'interface utilisateur d'un logiciel d'une langue vers une autre et en l'adaptant à la culture locale. On utilise parfois le terme localisation, qui est une transposition du mot anglais localization (faux ami). On écrit parfois l10n car le mot localization est composé de dix lettres encadrées par un l et un n.

Avant qu'un logiciel ne soit régionalisé, il faut au préalable qu'il ait été internationalisé, c’est-à-dire qu'il ait été écrit pour pouvoir être traduit dans différentes langues et cultures.

Ce processus demandant beaucoup de travail et d'efforts de la part des équipes de développement, des outils ont été créés pour simplifier le processus de régionalisation. Un grand nombre de ces projets sont sous-traités à des entreprises spécialisées afin de réduire les coûts.

La régionalisation d'un logiciel concerne également le fait de l'adapter à une culture. Les paramètres régionaux sont généralement partagés par les différentes applications. Certaines applications spécialisées nécessitent leurs propres paramètres. Le consortium Unicode travaille sur une normalisation de ces paramètres régionaux, le projet Common Locale Data Repository.

Sommaire 1 Problèmes liés à la régionalisation 2 Une démarche à prévoir dès la conception 3 Outils d'aide à la régionalisation informatique 4 Voir aussi 4.1 Articles connexes 4.2 Liens externes

Problèmes liés à la régionalisation

Le premier problème de la régionalisation est celui du contexte des phrases traduites. En effet, dans l'interface, les phrases sont parfois composées de plusieurs entités assemblées en fonction du contexte, et qui vont apparaître séparées et hors contexte dans le logiciel de traduction. Par exemple, une phrase du type

Impossible d'exécuter la tâche x : l'objet y n'est pas un objet conforme aux spécifications z.

pourra être composée de deux chaînes apparaissant séparément : « Impossible d'exécuter la tâche x : » et « l'objet y n'est pas un objet conforme aux spécifications z. » Selon les cas, cela pourra être une autre phrase qui apparaîtra après les deux-points. Par ailleurs, les noms x, y et z sont eux-mêmes stockés à part et peuvent varier. Le traducteur se retrouve donc à traduire des phrases partielles sans savoir la manière dont elles vont s'assembler.

Se pose aussi un problème de cohérence, et de mise en forme : l'association des phrases a-t-elle un sens dans la langue cible ? Faut-il mettre un espace avant le premier ou après le dernier caractère ?…

La plupart des programmes disposent de « raccourcis », c'est-à-dire que les commandes les plus fréquentes sont accessibles de manière rapide, par exemple par une combinaison de touches [Ctrl]+lettre ou [Alt]+lettre ; ce moyen est peu intuitif, mais facilite le travail des utilisateurs chevronnés. La lettre en question est en général en relation avec le nom de la commande (initiale en général). Faut-il alors utiliser une autre lettre dans la langue cible afin de garder le caractère mnémotechnique ? Cela pose le problème de la cohérence (il faut faire attention à ce que la lettre choisie n'ait pas un autre sens) et des possibilités du traducteur : l'interface de traduction permet-elle de faire cette opération ou faut-il modifier le code ?

S'il n'est pas possible de changer cette lettre, il faudrait alors indiquer le moyen mnémotechnique dans la documentation. Par ailleurs, lorsque cette commande est présente dans un menu, la lettre est parfois soulignée. Si l'on utilise la même lettre de raccourci mais que ce n'est pas l'initiale, alors il faut penser à dé-souligner l'initiale, et éventuellement à souligner la lettre si elle est présente à un autre endroit du mot.

Concernant le traducteur, dans l'idéal, il doit maîtriser parfaitement la langue de destination, donc être locuteur de la langue et avoir fait des études de cette langue, il doit bien connaître le domaine technique afin d'en connaître le vocabulaire spécifique, et aussi maîtriser le logiciel afin de comprendre le contexte des phrases. Cela pose le problème des ressources allouées à la traduction : dans les cas pointus, soit il faut une équipe, soit il faut une perle rare. Dans tous les cas, le traducteur devrait pouvoir dialoguer avec les développeurs.

Par ailleurs, certaines chaînes n'ont pas de sens mais sont des indications de mise en forme (retour de ligne, format d'une variable…), le traducteur doit donc être formé à reconnaître ces chaînes spécifique afin qu'il ne les traduise pas, où les déplace selon le contexte. Il faut aussi se méfier des chaînes qui ont un rôle particulier, par exemple qui sont détectées par le logiciel et déclenchent telle ou telle action ; ceci est plutôt un problème de programmation en amont, dans la perspective d'une internationalisation, aucun mécanisme ne devrait faire intervenir la recherche d'un mot ou d'une phrase, ou tout du moins de telles chaînes ne devraient pas être « codées en dur » mais être mises dans des variables… à traduire de manière pertinente.

Un cas particulier est celui des langages de macro-instruction. Une macro écrite avec le logiciel dans une langue est-elle utilisable avec le logiciel dans l'autre langue ? Cela pose essentiellement le problème de la représentation des instructions : si les instructions sont traduites, est-ce alors le mot dans la langue cible qui est stocké, ou bien est stocké de manière différente (dans la langue originelle, ou bien sous forme d'un code) et le mot est juste traduit à l'affichage ? Le cas s'est par exemple posé pour les macros de Microsoft Excel.

Vient ensuite le problème de l'interface : les messages n'ont pas la même longueur selon les langues, le traducteur peut donc avoir à retailler les boîtes de texte et les boutons.

Enfin, certaines langues s'écrivent de gauche à droite, d'autres de droite à gauche, d'autres de haut en bas. Dans ce contexte, où le texte accompagnant un contrôle (bouton, case à cocher, curseur, zone de saisie…) doit-il se positionner ?

Une démarche à prévoir dès la conception

La régionalisation devrait être prévue dès la conception du logiciel et faire partie du cahier des charges. Les concepteurs devraient s'astreindre à des normes de développement facilitant la tâche. Par exemple :

• comme mentionné ci-dessus, ne pas utiliser de mot (du langage naturel) codé en dur mais de les mettre systématiquement dans des variables (par exemple une chaîne qui serait recherchée dans un texte pour déclencher une action, cas typique de mots comme « none ») ;
• espacer les objets dans l'interface graphique afin de permettre d'allonger l'espace réservé aux textes ;
• lorsqu'un objet a un titre accolé, mettre le titre au-dessus de l'objet, ce qui évite de devoir bouger ou retailler l'objet en fonction de la taille du titre ;
• …

Outils d'aide à la régionalisation informatique

Sous Linux, le format po est utilisé pour permettre la réalisation de programmes informatiques multilingues. Un fichier po est un fichier texte comportant la version anglaise des messages systèmes avec leurs équivalences traduites les remplaçant.

• Lingobit Localizer , outil de localisation pour .Net, MFC et Java
• Gettext, qui est utilisé par la plupart des logiciels libres tournant sous Linux ;
• Codito (projets Delphi) ;
• Multilizer (projets Delphi).
• Visual Localize (AIT), pour les projets Visual Studio et .NET de Microsoft Windows
• Loc@le™ d'Accent Software, pour Microsoft Windows (apparemment plus distribué)

Voir aussi

Articles connexes

• Traduction
• Traduction technique

Liens externes

• Traduction : le métier n'est plus ce qu'il était, André Abou, OFIL (2004)
• Société Française des Traducteurs, syndicat national des traducteurs professionnels

• Portail de l’informatique