Localisation logicielle

Ce service diffère de la localisation de site web. Sur un site web, les textes sont le plus souvent fluides et de contexte explicite ; dans un logiciel, ils se présentent au contraire sous forme de fragments courts, dispersés et détachés de leur contexte, à l’intérieur des fichiers sources. Des mots isolés comme « Save », « Open » ou « None » sont traduits sans que l’on voie où ils apparaîtront à l’écran. Cette rupture est la difficulté la plus déterminante de la localisation logicielle.

Le texte est séparé du code

Dans un logiciel localisable, tous les textes visibles par l’utilisateur sont extraits du code et regroupés dans des fichiers sources distincts. Le traducteur travaille sur ces fichiers et non sur le code. Ces fichiers contiennent toutefois des éléments particuliers : les espaces réservés destinés aux variables, les marques du pluriel, les signes de formatage. S’ils sont modifiés, l’application plante. La localisation logicielle suppose donc de savoir ce qui se traduit et ce à quoi il ne faut pas toucher.

Dans une langue agglutinante comme le turc, les suffixes de pluriel et de cas posent un problème à part. Une formule qui s’ajoute simplement à la fin d’une variable en anglais varie en turc selon le dernier son du mot. Les conceptions qui insèrent une variable au milieu d’une phrase donnent donc souvent un résultat défectueux ; ces endroits doivent être repérés pendant la localisation et signalés au développeur.

Comment se déroule le processus ?

Le processus de localisation logicielle tient moins de la traduction que d’une discipline d’ingénierie ; à chaque étape, l’exactitude linguistique et l’exactitude technique sont surveillées ensemble. Le flux ci-dessous part du fait que les textes arrivent sous forme de fragments détachés de leur contexte : rassembler le contexte est donc une étape aussi importante que la traduction elle-même. La préservation des espaces réservés et des codes de formatage est une règle qui ne change pas tout au long du processus. Le test qui vient à la fin des étapes est le maillon le plus déterminant du processus, car on ne peut savoir si une traduction est réellement juste qu’en la voyant dans l’application.

1. Réception des fichiers sources. Les fichiers de langue contenant les textes sont rassemblés, ainsi que les captures d’écran ou les notes de contexte s’il y en a.
2. Guide terminologique et stylistique. Les termes fondamentaux du produit sont fixés ; on décide de l’équivalent retenu pour des notions proches comme « delete », « remove » ou « cancel ».
3. Traduction. Les textes sont traduits en respectant les espaces réservés et les limites de caractères ; une question est ouverte auprès du développeur pour les fragments au contexte incertain.
4. Test sur la version compilée. La traduction est intégrée à l’application et observée sur les écrans réels ; les textes qui débordent, qui se placent au mauvais endroit ou qui perdent leur contexte sont corrigés.
5. Maintenance des versions. Dans une nouvelle version, les textes modifiés sont repérés et seuls ceux-là sont mis à jour ; on ne repart pas de zéro à chaque version.

Forme de livraison

La livraison prend la forme de fichiers sources dans lesquels la traduction a été intégrée ; le développeur peut les passer directement à la compilation. Les espaces réservés, les codes de formatage et la structure des fichiers sont conservés intacts. Si une phase de test a été demandée, la liste des problèmes constatés à l’écran et les corrections proposées sont également rapportées. Si la documentation et les textes d’aide du produit doivent aussi être traduits, ils sont traités en cohérence terminologique avec l’interface.

Points de vigilance propres à ce service

Le risque le plus grand est l’absence de contexte. Un mot traduit sans que l’on voie où il apparaîtra à l’écran peut prendre un sens erroné : « close » signifie aussi bien « fermer » que « proche » ; seul le contexte indique lequel des deux. Les captures d’écran et un canal de questions ouvert avec le développeur sont donc l’élément le plus déterminant de la qualité. Dans un projet où le contexte n’est pas fourni, le taux d’erreur augmente inévitablement.

Le deuxième point est de ne pas conclure sans avoir vu le résultat dans l’interface réelle. Une traduction qui paraît correcte sur le papier peut ne pas tenir dans un menu étroit ou se lire de travers à cause d’une variable placée au milieu d’une phrase. Ces problèmes ne se voient qu’en testant sur la version compilée. Si le site web doit être localisé en même temps que votre application, les deux travaux sont menés avec une terminologie unifiée dans le cadre de nos services de traduction.

Internationalisation et cycle de test

Le succès d’une localisation logicielle dépend d’une étape franchie avant la traduction : l’internationalisation. Si l’application n’a pas été construite pour accueillir différentes langues, le résultat sera défectueux quelle que soit la qualité de la traduction. La séparation du texte et du code, la possibilité de régler les formats de date et de nombre et la place laissée par l’interface à un texte qui s’allonge sont des conditions à réunir avant la traduction. Si elles manquent, c’est d’abord le côté développement qu’il faut corriger.

Le deuxième facteur déterminant est le cycle de test. La localisation n’est pas une livraison à sens unique mais un processus qui se répète : la traduction est intégrée, observée dans la version compilée, les problèmes sont signalés puis corrigés. À mesure que de nouvelles versions arrivent, seules les chaînes modifiées sont traitées et le même cycle se répète à plus petite échelle. Les projets menés sans cette organisation repartent de zéro à chaque mise à jour, coûtent cher et perdent leur cohérence. Une localisation solide définit ce cycle comme un flux dès le départ.

Qu’est-ce qui détermine le prix ?

Le premier facteur de coût est le volume réel du texte à traduire ; dans les fichiers sources, ce volume dépasse souvent ce qu’il paraît, car les messages d’erreur et les textes d’aide passent inaperçus. Le deuxième est l’état du contexte : un projet accompagné de captures d’écran et de notes avance vite, un projet mené à l’aveugle ralentit. Le troisième est l’étendue des tests ; si un contrôle sur la version compilée est demandé, il représente un travail distinct. Un prix ne peut pas être donné de façon fiable sans avoir vu les fichiers sources.

Vous pouvez nous transmettre vos fichiers sources et les langues cibles via le formulaire de devis. Vous trouverez les paliers tarifaires sur la page des tarifs et les langues dans lesquelles nous travaillons sur les pages de langues.

Situations fréquentes

• Liste de textes sans contexte. Un tableau de mots envoyé sans capture d’écran ; c’est la situation qui accroît le plus le risque de contresens.
• Altération d’un espace réservé. Une modification accidentelle des marques de variables ; elle fait planter l’application, c’est pourquoi elles sont conservées.
• Texte qui déborde. Un texte qui s’allonge dans la langue cible et ne tient pas dans une interface étroite ; cela ne se voit qu’avec un test sur la version compilée.
• Désordre entre les versions. Retraduire l’intégralité du texte à chaque mise à jour ; or seules les chaînes modifiées doivent être traitées.

Ce contenu donne le cadre général ; les détails propres à chaque dossier peuvent varier. La pratique pouvant évoluer, référez-vous aux conditions en vigueur au moment de votre demande.