La Localisation de logiciels

Groupe Eurologos Réseau de Franchises
La Localisation de logiciels
EUROLOGOS Group.
GLOBAL and
MULTILINGUAL
SOLUTIONS
Toutes les productions peuvent être
“délocalisées”... sauf celles des langues.
Le Groupe Eurologos continue à “glocaliser”
(globaliser et localiser en même temps )
la production des services multilingues et multimédias.
Nous ne cessons d’implanter d’autres sièges dans
les plus grands centres économiques vers lesquels
les entreprises de la globalisation doivent exporter.
Nos sièges "glocaux"
Arad •
Arezzo •
Brussels •
Bucuresti •
Buenos Aires •
Cyprus •
Genova •
Gliwice •
Köln •
Leipzig •
Lisboa •
Madrid •
• Malta
• Milano
• Moscow
• Paris
• San José
• São Paulo
• St Petersburg
• Tallinn
• Tel Aviv
• Tokyo
• Toronto
• Trieste
L a co m m u n i c a t i o n g lo b a le e x i g e d e s l a n g u e s “ g l o c a l i s é e s ”
TRANSLATING AND PUBLISHING WHERE THE LANGUAGES ARE SPOKEN
Intervention de Sascha Leib
(Software Localisation Manager)
Séminaire d’Eurologos-Bruxelles
à Ostende le 21 mai 2005
EUROLOGOS Group. When localization becomes « glocalization »
Localisation Departement
1/ 5
TRANSLATING AND PUBLISHING WHERE THE LANGUAGES ARE SPOKEN
La localisation de logiciels en opposition à la localisation de sites internet
A la différence de la localisation des sites internet, la localisation des logiciels d'application
requiert généralement un effort beaucoup plus important au niveau de l’internationalisation
avant de traduire.
Cela est dû en partie à cause de la différence au niveau des cycles de développement des
sites internet et des produits logiciel, tandis que le renouvellement d’un site internet impose
en général une reprogrammation complète du code HTML, le logiciel d'application évolue
généralement et sera développé davantage. Cela signifie que, toute version de produits
logiciel partagera la partie la plus importante du code source avec son prédécesseur.
Une approche commune dans la localisation de sites internet – pour créer tout simplement
une copie du site dans un sous-répertoire – n’est normalement pas acceptable pour de tels
produits. Sans quoi, le client rencontrerait des problèmes dans le cycle d’évolution suivant
de son développement de logiciel.
Produit Original
Internationalisation
LocaleIndependent
Code (Code
Générique
paramètrable)
Produit International
Langue d’origine
Traduction
Nouvelles
langues
Je considère que quiconque chez Eurologos sache traduire, c’est pourquoi je me
concentrerai sur cette partie du processus de localisation que l’on appelle
« internationalisation ».
L’évolution des techniques d’internationalisation de logiciels
Il y a un certain « art » dans la manière de bien programmer des logiciels.
Malheureusement, la plupart des programmateurs, soit n’en ont pas conscience, soit la
pression du délai leur fait oublier ces règles.
C’est évidemment une occasion pour vendre les services de valeur ajoutée au client qui,
peut-être, n’a pas conscience de la qualité du code de leur logiciel.
Expliquons l’évolution des concepts de la localisation avec un exemple très simple. Vous
avez déjà très certainement vu ce genre de messages auparavant :
Par exemple, une localisation française devrait avoir la forme suivante :
Dans les sections suivantes, vous verrez les différentes manières d’internalisationner un
dialogue :
EUROLOGOS Group. When localization becomes « glocalization »
Localisation Departement
2/ 5
TRANSLATING AND PUBLISHING WHERE THE LANGUAGES ARE SPOKEN
1.
Le « code spaghetti »
Le code source le plus simple pour une telle boîte de message pourrait être :
MsgBox "You have " + str(numDays) + " days left before this software
expires."
Avec facilité, la commande « MsgBox » affiche une simple boite à message (par défaut
simplemnt avec le bouton « ok »), et le texte entre guillemets sera par la suite affiché dans
cette boîte.
Ici, le texte à afficher est composé de trois parties : le premier texte statistique, un chiffre
(converti en un lien par la fonction « str ( ) », et un autre texte statistique pour finir la
phrase.
Puisque nous ne voulons pas que les traducteurs aient à se confronter à ce genre de choses,
nous extraierons les liens statiques pour eux, et par conséquent, à la place, ils seront
confrontés à deux segments de texte indépendants comme :
You have
days left before this software expires.
Comme ci-dessus, pensez-vous que ce « You have » a besoin d’être traduit de cette manière
« Il ne vous reste que » ? Avez-vous également remarqué le grand espace laissé en blanc à
la fin du premier texte et au début du deuxième ?
Malheureusement, puisqu’il réduit grandement la complexité qui implique un bon style de
programmation, on peut aussi constater des exemples similaires dans des manuels de
programmation, et par conséquent des programmeurs inexpérimentés ne parviennent pas à
comprendre que ce n’est PAS un bon style de programmation.
Le terme « Spaghetti Code » est souvent utilisé pour ce genre de programmation, car la
structure et la logique d’un tel programme sont plutôt compliquées et aussi
compréhensibles qu’un plat de nouilles.
2. Des textes tamponnés
Un meilleur concept serait de garder la phrase intacte dans un texte, puis réduire le niveau
de fragmentation. Par exemple :
MsgBox Replace ("Il ne vous reste que % jours avant l’expiration du programme.", ¬
"%", str(numDays))
Ici, un caractère spécial (dans cet exemple-ci un signe de pourcentage) est utilisé pour
indiquer l’endroit où la variable devrait figurer. Puis, ce paramètre substituable est
remplacé et le texte qui en résulte est mis dans la boîte à message. C’est vraiment d’une très
grande simplicité.
Après l’extraction du texte, le traducteur sera de nouveau confronté à deux textes :
Il ne vous reste que % jours avant l’expiration du programme.
%
Evidemment, le « % » en tant que tel n’est pas un gros problème, puisqu’il est clair qu’il
n’a pas besoin d’être traduit, mais au moins nous avons désormais une phrase défragmentée
que nous pouvons facilement traduire.
Bien sûr, nous sommes encore loin de la perfection. Il y a toujours quelqu’un qui doit
parcourir tout le code source et trouver les textes à traduire. Evidemment, si le texte du
EUROLOGOS Group. When localization becomes « glocalization »
Localisation Departement
3/ 5
TRANSLATING AND PUBLISHING WHERE THE LANGUAGES ARE SPOKEN
paramètre substituable est utilisé de la même manière, il pourra être exclu de l’extraction du
texte, etc. Mais c’est loin d’être parfait.
3.
Les constantes
Voici l’autre idée que les programmeurs ont soulevée : pourquoi ne pas définir tous les
textes qui ont besoin d’être traduits ensemble à un endroit, et n’utiliser que les références au
lieu de toujours devoir les retaper.
Cela pourrait être réalisé par de simples constantes de définition (par exemple au début de
chaque module), comme cela :
Const ExpirationMessage = " Il ne vous reste que % jours avant
l’expiration du programme."
Puis, il faut changer le code de la boite à message de cette façon :
MsgBox Replace(ExpirationMessage, "%", str(numDays))
Désormais, tous les textes à traduire sont regroupés à un seul endroit et le code source
actuel ne contient que ces textes qui ne nécessitent pas de traduction.
Nous pouvons également réaliser un aiguillage automatique pour la langue, tel que :
#if version_fr
Const ExpirationMessage
= "Il ne vous reste que
l'expiration du programme."
%
jours
avant
#else
Const ExpirationMessage = "You have % days left before this software
expires."
#endif
Dans cet exemple, les instructions #if, #else et #endif sont des commandes de
compilation, ce qui signifie que lorsque le programmeur réalise son application, le
programme de compilation décide (selon les paramètres) quel texte à attribuer à la
constante ExpirationMessage.
Pas de changements de code, pas de versions multiples du code source… facile.
Dans une variation comme ci-dessus, quelqu’un peut souvent voir les assignations
constantes actuelles externalisées dans un seul fichier-texte par langue. On pourra
transmettre ces fichiers-texte aux fournisseurs de services externes (par exemple des
agences de traductions) qui n’ont pas vraiment à se soucier de la logique du programme.
Tout ce qu’il y a à savoir peut être expliqué en 5 minutes (ne pas toucher à la partie devant
le signe égal et laisser les guillements à leur place).
4.
Ressources externes et déclenchement du langage d’exécution
Bien sûr, cette explication ne s’arrête pas là, il y a d’autres possibilités. Pourquoi ne pas
séparer complètement les textes (y compris les localisations) et la logique du programme ?
Dans ce cas, les textes localisés peuvent être mis dans le fichier des ressources qui navigue
avec le produit logiciel, et les textes sont chargés dans la mémoire dans le programme de
démarrage. Le programme actuel est complètement indépendant au niveau du choix de la
langue; changer le dossier des « locales » peut le transformer en une version de langue
différente. Cela représente un énorme gain de temps pour les fabricants: pas seulement
parce qu’ils n’ont qu’à mettre au point une seule version linguistique (d’autres langues sont
crées lors de l’intégration du dossier des « locales » avec la logique de programme), et les
mises à jour sont également très simplifiées. Désormais, la prochaine étape de la course
serait que le fabricant puisse juste répandre un CD-ROM avec toutes les versions
linguistiques dans le monde entier, et que les utilisateurs puissent choisir eux-mêmes la
EUROLOGOS Group. When localization becomes « glocalization »
Localisation Departement
4/ 5
TRANSLATING AND PUBLISHING WHERE THE LANGUAGES ARE SPOKEN
langue qu’ils désirent. C’est exactement la direction que suit le développement. Bien sûr, en
ayant déjà implanté la fonctionnalité qui consiste à charger des ressources de « locales »
d’exécution, le travail est facilité. Mais cela demande beaucoup d’organisation pour
s’assurer que toutes les versions linguistiques soient prêtes en même temps – et que les
fonctions principales du logiciel soient complètement indépendantes au niveau du langage (
= « locale »), (ou utiliser un mot-code : Internationalisé).
5.
Processeur d'idées
L’évolution technique n’est pas encore terminée, tout comme les techniques rigoureuses et
indépendantes citées ci-dessus. De nombreux « frameworks » d’application (la base sur
laquelle le logiciel d’application est écrit) fournissent des caractéristiques
d’internationalisation plus ou moins intelligentes – même certaines applications d’aide pour
faciliter le processus de localisation. Toutefois, tout cela est suffisant pour avoir une vision
d’ensemble.
Conclusion
L’internationalisation des logiciels en soi n’est pas simplement « l’art pour l’art ». Elle peut
permettre au client de réaliser de grosses économies à la fois dans le développement plus
poussé du produit, et au niveau du prochain « locale » qui devra s’ajouter. Bien sûr, cela
exige tout d’abord un investissement temporel et/ou financier, mais dans un environnement
purement professionnel, cela sera amorti rapidement par les coûts de développement
réduits. Si l’internationalisation est un succès, le traducteur ne sera plus confronté à ces
problèmes techniques. Ainsi, il pourra se concentrer sur la tâche qu’il ou elle réalise le
mieux : traduire. En tout cas, cela devrait pourrait être astucieux de demander à un client
(potentiel) quels techniques et « framework » il utilise afin d’estimer les options possibles,
et par conséquent d’estimer la charge de travail nécessaire pour réaliser le travail.
EUROLOGOS Group. When localization becomes « glocalization »
Localisation Departement
5/ 5