Pseudolocalisation

Traditionnellement, la localisation d’un logiciel ne dépend pas du développement. De manière générale, le logiciel est développé et testé dans un langage source (tel que l’anglais), les éléments localisables étant stockés dans les ressources externes. Ces ressources sont envoyées à l’équipe de localisation qui se charge de la traduction vers les différentes langues cibles[1].

Différents problèmes concernant l’apparence des textes écrits en plusieurs langues peuvent se présenter lors de la localisation :

• les textes traduits sont considérablement plus longs que les textes sources; ils ne respectent donc plus les contraintes de l'Interface ou les blocs ne sont plus cohérents ;
• les glyphes d’une police sont considérablement plus larges que l’autre ou possèdent des signes diacritiques qui n’apparaissaient pas dans la langue source et qui peuvent être coupés verticalement ;
• les langues pour lesquelles le sens de lecture n’est pas de gauche à droite sont particulièrement problématiques pour les entrées utilisateur ;
• les codes de programme qui assument que l’ensemble des caractères rentre dans un jeu de caractère limité tel que le jeu ASCII ou ANSI peuvent générer des erreurs de logique.

De plus, la procédure de localisation peut révéler des éléments localisables qui sont codés en dur dans la langue source. De la même façon, il est possible qu’il y ait des éléments qui aient été conçus pour être localisés mais ne nécessite pas de localisation (par exemple, des noms dans un document XML ou un document HTML)[2].

La pseudolocalisation est conçue pour détecter tous ces types d’erreurs pendant le cycle de développement, en remplaçant automatiquement l’ensemble des éléments localisables par un pseudo-langage compréhensible par les locuteurs natifs, mais qui comprend la plupart des éléments problématiques des autres langages et scripts. On peut donc considérer la pseudolocalisation comme un instrument d’internationalisation ou d’ingénierie et non un instrument de localisation.

La pseudolocalisation avec Microsoft fut mise en place lors du cycle de développement de Windows Vista [3]. Un pseudo-langage décrit par les techniciens Windows comme « pseudo locale » fut inventé. Les paramètres régionaux de ce pseudo-langage furent conçus pour utiliser un jeu de caractère et des polices d’écriture sélectionnés parmi une des trois catégories de langages modernes utilisés par Windows à ce moment-là : basique (« Occidental »), inversé (« Proche-orient ») et CJC («Extrême-orient ») [1]. Avant Vista, chacun des trois langages avait sa construction distincte sur Windows, avec parfois des bases de code différentes (et donc, des comportements et bugs différents). Les pseudo locales créées pour chacune de ces familles de langages généraient du texte lisible en anglais qui était cependant composé de scripts d’autres langages. Par exemple, la chaîne de caractère

Edit program settings

est traduite, selon les pseudo locales « basiques », par

[!!! εÐiţ Þr0ģЯãm səTτıИğ§ !!!]

Ce procédé génère des traductions de chaînes de caractères plus longues, contenant des caractères qui ne font pas partie de l’ASCII et qui, pour les pseudo locales « inversées », sont écrits de droite à gauche[3].

Les crochets dans l’exemple précédent permettent de détecter les erreurs suivantes :

• les textes coupés (coupure) ;
• les chaînes de caractères qui se sont assemblées (concaténation) ;
• les chaînes de caractères qui ne sont pas localisables (code dur).

Michael Kaplan (un gestionnaire de logiciel Microsoft) considère que le processus de pseudolocalisation est similaire à : « un interne localiseur passionné et travaillant dur, mais naif, désireux de faire ses preuves, qui va traduire chacune des chaînes de caractères pour lesquelles vous n’avez pas spécifié qu’elles ne doivent pas être traduites »[2].

La pseudolocalisation a pour avantage de se faire automatiquement, pendant le cycle de développement, au sein d’un assemblage automatique. Le processus est quasiment identique à celui utilisé pour créer de véritables assemblages localisés, ce dernier étant cependant effectué avant que l’assemblage soit testé et donc bien plus tôt dans le cycle de développement. Cela laisse du temps pour la correction des bugs détectés dans le code de base, ce qui est bien plus simple que de corriger un bug peu de temps avant la sortie du logiciel[1].

Les assemblages qui sont produits par la pseudolocalisation sont testés avec le même cycle d’assurance qualité que les assemblages non localisés. Puisque les pseudo locales sont des copies des textes anglais, ils doivent être testés par une personne anglophone. Récemment, des versions bêta de Windows (7 et 8) ont été publiées avec des chaines de caractères pseudolocalisées intactes [4]^,[5]. Pour ces versions récentes de Windows, les assemblages pseudolocalisés constituaient la première version de l’assemblage (celle créée systématiquement pour les tests). La version finale en anglais de l’assemblage est une version localisée de la première version[2].

En plus des instruments utilisés en interne par Microsoft, d’autres instruments d’internationalisation comprennent désormais des options de pseudolocalisation : Alchemy Catalyst, conçu par Alchemy Software Development, et SDL Passolo, conçu par SDL. Ils incluent la possibilité de visualiser directement des dialogues pseudolocalisés et des formulaires dans l’instrument. Le processus de création d’un assemblage pseudolocalisé est relativement simple et peut être effectué en lançant un script de pseudolocalisation personnalisé sur les ressources de textes externes.