Compte-rendu de conférence

est un auteur, développeur, formateur et speaker depuis plus de 20 ans d'expérience dans le software engieniering.
Il a localisé des applications sur quatre plateformes de développement dont le framework .Net. Il a participé à de nombreuses conférences sur plusieurs continents et a même été élu deux fois Meilleur Speaker.
Aujourd'hui il écrit des livres sur la localisation des applications et continue de donner des conférences dont les TechEd.

Aujourd'hui, il est de plus en plus facile de localiser une application aussi bien pour les applications Winforms que les applications web et il est possible de le faire de différentes manières selon vos besoins (oui les fichiers langues de ressources ne sont pas toujours l'unique et la meilleure solution à votre problème) et c'est donc plein d'entrain que je me suis posé dans cette salle plutôt vide (à croire que tout le monde ne s'intéresse pas à l'internationalisation ou croit savoir la maitriser). Je suis quasi sûr que la majorité de ces personnes auraient changé d'avis sur leurs compétences après cette présentation de main de maitre de la part de Guy. En quelques points, il a su répondre à la plupart des questions que j'ai pu me poser par le passé lorsque je cherchais à produire une application multilingue.


Voici les dix points abordés et leur résumé en (très :)) condensé:
1- L'interface visuelle schizophrène
Qui n'a jamais remarqué que lorsqu'il traduisait une application, les boites de dialogues dites "communes" comme l'OpenFileDialog, la ColorDialog, etc. restaient dans la langue du système. Pas la peine de vous dire qu'une fenêtre non traduite qui se balade au milieu de votre application n'est pas la meilleure des choses.
Il existe plusieurs solutions à ce problème:

2- localisation les composants ASP .Net 2.0
En ASP .Net, il existe des contrôles tous faits comme les contrôles de Login, de Password ou de formulaire d'inscription. Par défaut, ces

3- l'affichage des Forms (layouts)
Voici un point important. Qui ne s'est jamais rendu compte que le placement de ses contrôles en anglais n'avait plus du tout la bonne tête une fois traduits en allemand.
Voici ce que la plupart des développeurs font (ce qui est une erreur!):

D'autres plus intelligents se doutant que la longueur des labels variant, les champs vont devoir être redimensionnés vont utiliser la technique suivante (qui est aussi fausse :))


Mais quelle est la bonne solution me direz-vous? La réponse se trouve dans le TableLayout contrôle. C'est en effet l'équivalent du <TABLE> en html et il permet en plaçant chaque paire de contrôles (labels/Textbox) dans une cellule de toujours avoir un bon affichage car adapté.
Même en cas de redimensionnement, pas besoin de jouer avec les ancres des contrôles, c'est le table selon des pourcentages définis par le développeur qui va se charger de tout redimensionner correctement.

4- les ressources fortement typées
Bon là je n'ai pas tout compris (ou écouté :D) mais en résumé, il est déconseillé d'appeler une ressource d'un fichier langue par son nom.
Plutôt que faire appel au ressource manager et de passer le nom de la ressource et prendre le risque de se tromper, il convient d'appeler le fichier ressources puis la propriété correspondante car chaque chaîne littérale sera de toute façon automatiquement transformée en propriété (Get/Setter).
Vous obtenez quelque chose de la forme:

Messagebox.Show(Form1Resources.Monchamp);

5- localiser les messages d'exception
Eh oui, il ne faut pas les oublier ceux-là, car malheureusement ils sont toujours présents qu'importe le niveau du développeur de l'application. Néanmoins, si vous faites en lançant des exceptions vous-même pour les faire remonter au niveau supérieur, vous verrez que ces derniers changent de langue en fonction que nous leur donniez un argument ou non. En effet, pour la même exception, le fait de lui passer l'argument null ou une chaine "toto" ne donnera pas la même langue pour l'erreur. Néanmoins ce comportement correspond à certaines règles du Framework et les connaitre permet de savoir quelle langue nous aurons (ou voulons avoir) au final.

En règle général, l'exception se base sur la culture actuelle du système et la solution pour contrôler ceci (car vous voulez peut-être des messages anglais (pour les logs par exemple) bien que le système soit en eskimo)) est de créer une classe de création d'exception (ExceptionFactory) et de lui passer en paramètre la culture désirée et générer une exception de la forme voulue.

6- étendre la classe CultureInfo
Simplement pour résumé, vous n'être pas sans savoir que les différentes cultures peuvent ne pas utiliser les mêmes formats d'heures, les distances, les volumes, températures, etc. Ce qui peut amener à des incohérences à l'affichage selon la culture de l'utilisateur. 20 °C n'aura pas la même signification pour lui que 20 °F et à moins que vous ne désiriez tout recalculer vous-même dans le code, une solution est de créer une classe CultureInfoEx, héritant de CultureInfo avec la culture de votre choix et de l'appliquer à votre application lorsque cela est nécessaire.


7- utilisation de cultures personnalisées
Ceci est une suite au problème précédent. Imaginons que votre application affiche l'heure de façon 10 A.M de façon digitale (un écran LCD recodé). Que se passe-t-il lorsque la culture impose par défaut une heure de la forme 22:00? Et bien votre écran risque de ne plus aussi bien marcher.
La solution est ici soit de créer une nouvelle CultureInfo, soit de modifier celle existante et forcer un format spécifique. Attention, les modifications sont enregistrées au niveau de l'ordinateur et la culture sera modifiée pour toutes les applications de la machine.


8- pseudo translation
Désolé mais ce point était trop rapide.

9- machine translation
Ici Guy nous a parlé d'utiliser des logiciels tiers de traduction, comme des moteurs "locaux" ou des services web (worlingo, systran, etc.). Nous le savons tous, ces traducteurs sont de médiocre qualité (tous autant que les autres) quand il s'agit de termes spécifiques, encore plus sur des termes informatiques aussi simples que "log off" qui ne sera bien traduit par aucun traducteur.
Alors quel intérêt de les utiliser? Selon Guy, un seul intérêt: bien implémenté, le système de traduction via un moteur web permet de rapidement traduire une application pour par exemple en faire une démonstration rapide au patron ou simplement pour avoir une grossière idée de la tête de l'application avec telle ou telle langue.


10- testing internaionnalization
Pour Guy, c'est la partie la plus importante d'une localisation et il donne même des formations de plusieurs heures uniquement sur ce point-là. Pourtant, toujours selon lui, cette étape se résume en gros à l'utilisation de FxCop et à la correction des erreurs de localisation détectées. Plutôt que de vous énumérer les erreurs communes, voici une capture des règles FxCop sur lesquelles il faut faire spécialement attention.

Pour ma part, je suis très satisfait de cette présentation, peut-être même l'une de mes préférées car aussi "basique" soit-elle, elle répond à un problème concret et surtout elle y répond très bien. Plus encore, ça me conforte dans l'idée que la création d'une application multilingue n'est pas seulement une affaire de traduction de labels, mais plus une stratégie et un processus mûrement réfléchi.

Site général sur la localisation en .Net: ici