Localisation (informatique)

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher
Page d'aide sur l'homonymie Pour les articles homonymes, voir Localisation et Régionalisation.

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.

Problèmes liés à la régionalisation[modifier | modifier le code]

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 traduit. 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écifiques pour ne pas les traduire, ou bien les déplacer 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, stocke-t-on le mot dans la langue cible, ou bien stocke-t-on un code ou le mot en langue source pour le traduire seulement à l'affichage ? C'est le cas par exemple pour les noms des fonctions dans 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 avoir à ajuster la taille des boîtes de texte et celle des boutons.

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

Une démarche à prévoir dès la conception[modifier | modifier le code]

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[modifier | modifier le code]

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 original des messages systèmes avec leurs équivalences traduites les remplaçant.

Voir aussi[modifier | modifier le code]

Articles connexes[modifier | modifier le code]

Liens externes[modifier | modifier le code]