L'Internet a brisé les frontières des pays depuis des années. L'information publiée sur un site devient aussitôt accessible à des millions de vos compatriotes comme à l’ensemble de la planète.
Nous parlons des langues différentes, cela ne facilite pas les échanges. L'information que nous publions doit s'adapter non seulement à la langue de notre interlocuteur mais aussi à son référentiel et à sa culture.
Dans les sociétés multinationales, les applications web locales sont très rapidement propagées au niveau international, les problèmes traditionnels liés au multilingue se posent naturellement, mais la complexité est différente dans le contexte du Web. Les applications web sont dynamiques et doivent être disponibles en temps réel quelle que soit la langue.
L'objectif de cet article est de vous présenter l'analyse générale des problèmes posés par l'application multilingue et de vous proposer des solutions techniques adaptées à l'environnement de l'application.
Acteurs
Quels sont les acteurs de l'application web multilingue ?
Naturellement, en premier lieu l'utilisateur. Il reçoit les informations statiques et dynamiques et émet des informations dynamiques. Sans formation spécifique à l'application, il doit pouvoir indiquer la langue de consultation des informations et d'émission des messages.
Le Deuxième acteur de l'application multilingue est le réalisateur. Il dispose des moyens de mise en place des informations, programme la logique de déroulement des événements, contrôles de saisie etc. Notre tâche est d'organiser et de faciliter son processus de développement en veillant en particulier aux points suivants :
ne pas perturber ses règles et ses habitudes de développement.
ne pas lui imposer de coder deux fois la même information (que ce soit les pages statiques, dynamiques ou des macros client)
ne pas rendre le code source de l'application "aveugle" en lui permettant de retrouver rapidement l'endroit à modifier dans la page concernée.
Le troisième acteur, souvent oublié,est le traducteur. Il assure légalité absolue des informations d'une langue à l'autre. Son rôle est essentiel, il comble les lacunes des outils de traduction automatique qui sont des assistants certes pratiques mais limités. Notre objectif est de lui permettre de consacrer toute son énergie à la tâche délicate de la traduction sans lui imposer d’appréhender et de maîtriser les concepts techniques. La encore nous organisons le processus.
sans lui expliquer les bases de html, asp, jsp, jscript, vbscript et autres mots qu'il ne comprend pas
lui laisser le temps de réfléchir sur la traduction
minimiser les coûts techniques de sa participation.
rémunérer sa tâche.
Quels sont les cas d'utilisations que nous pouvons distinguer dans notre application :
Cas d'utilisation
L’utilisateur accède à l'application web en tapant son url dans la barre des adresses. Son regard parcourt l'écran, des images et des mots défilent, il ne parvient pas à en comprendre la signification. Normal, l'application est écrite en chinois. Nous sommes dans le cas d'utilisation "Open page"
Il parvient à repérer dans un coin de l'écran un drapeau symbolisant un pays dont la langue lui est connue. il se précipite et clique précipitamment. Les images et les mots forment maintenant un ensemble compréhensible. Le choix de la langue est un élément essentiel de l'application web que nous avons définis dans le cas d'utilisation "Choose site language". Il est naturel que nous ne puissions choisir la langue du site que sur la page du site, c'est pourquoi cette situation suit en général le cas précédent (sauf quelques exceptions, quand l'utilisateur indique une adresse url paramétrable, permettant de définir la langue dès la première page de l'application)
Le cas "Open page" ne sert pas uniquement à afficher la page de démarrage. Il sert également à l'affichage de toutes les pages de l'application dans la langue de l'utilisateur. C'est pourquoi un objet "fwa_trd" est constamment présent. Il assure que toutes les informations statiques et dynamiques seront affichées dans la langue demandée. Pour préciser la différence entre les informations statiques et dynamiques, voici un exemple :
Les titres des pages, libellé des champs de formulaires, texte de présentation et autres informations créées lors de construction de la page web sont des informations statiques.
Les messages des utilisateurs, descriptions des visites, mots clés définis pour de documents, en résumé tout ce que l'utilisateur a produit comme informations dans l'application sont des infos dynamiques.
Le cas d'utilisation "CreateMLinformation" permet à l'utilisateur de créer une information dynamique. L'objet "fwa_trd" joue le rôle d’assistant dans cette création.
L'objet "BatchServer" constitue le pont entre les informations présentes dans les bases de données de l'application et le base des traductions. L'utilisateur s'est limité à la création de l'information dynamique en une seule langue. Le but de "BatchServer" est d'assurer la présence de ce libellé sur les écrans des utilisateurs de langues différentes. Le cas d'utilisation "UpdateMlDatabase" permet de parcourir périodiquement la base de l'application web (ou les bases de l'application web) et constituer un ensemble de libellés nécessitant une traduction.
Ce schéma permet de mieux visualiser l'ensemble des cas :
Le cas d'utilisation "GetAutoTranslation" est un petit plus que nous nous sommes permis d'imaginer. Le développement rapide des moteurs de traduction en ligne nous a donné cet espoir. Supposons que le BatchServer, avec la permission d'administrateur, puisse se connecter sur les sites de traductions et récupérer les résultats de leur travail directement dans notre base de traduction.
Cela ne remet en aucun cas en cause le travail des traducteurs, au contraire nous en tirons deux avantages substantiels :
Les informations deviennent consultables très rapidement en toutes les langues.
Les traducteurs bénéficient d'une version traduite facile à manipuler pour atteindre la traduction exacte. (cela permet de réduire le coût de traduction).
Le réalisateur administrateur ne fait d'actions apparentes sur notre image des cas d'utilisation. Il code les pages de l'application, constitue des macros « poste client » multilingues. Toutes ces techniques seront exposées dans la deuxième partie de notre article. Un cas d'utilisation lui est quand même accessible : "OpenPageA" ce qui signifie l'ouverture de page de l'application en mode administrateur.
Pourquoi ce cas ? Supposons que votre page est constituées d’une multitude d'informations (ce qui est en général le cas). Votre application est multilingues, il est probable qu'aucune information n'est stockée sur la page : tout est dans la base de données (ou dans un objet particulier, bref c'est ailleurs). Notre réalisateur reçoit une demande urgente de modification de la présentation du texte "Espace d'accueil" : il faut rapidement le mettre en caractères gras.
Le réalisateur est confus, il lui est très difficile de trouver rapidement l'endroit dans le code, car au lieu de d’un texte "Espace d'accueil" il faut rechercher une instruction du type : Response.write(GetStaticLabel(144, Session("id_lng")))
Le cas d'utilisation "OpenPageA" permet d'afficher la page avec tous les libellés et leurs codes. Le texte "Espace d'accueil" apparaîtra alors ainsi : "Espace d'accueil (144, fr)". Cela permettra au réalisateur de trouver rapidement l'endroit dans le code et de le modifier ainsi :
Response.write("" & GetStaticLabel(144, Session("id_lng")) & "")
Le même cas d'utilisation sera également très apprécié par notre troisième acteur , le traducteur, qui remarquera les incohérences de traduction et voudra les corriger. Or, il n'a pas d'accès au code source, donc il lui faut trouver un moyen de connaître de quel libellé il s'agit pour l'appeler et le corriger.
Le cas d'utilisation "SetHumanTranslation" met un point final à notre présentation. Le composant "Connectable application" permettra au traducteur de récupérer les libellés en local, de les traduire tranquillement sans être connecté au site et d'envoyer les traductions achevées. Notez que les libellés présentés au traducteur seront libérés de tous code html ou autre. Le traducteur n'aura pas à se soucier si le libellé fait partie d'un menu, si c'est un message de macro javascript ou si c'est un libellé dynamique.
Bien sûr, les utilisateurs de l'application web ne sont pas tous très disciplinés. Certains créeront des messages en anglais pendant qu'ils consultent l'application en français arrive. Un autre cas d’erreur se produit quand la base de l'application n'a pas été conçue pour stocker la langue dans laquelle les informations ont été créées. Le traitement de "BatchServer" se trouve alors aveugle et attribue à toutes les nouvelles informations la valeur de la langue par défaut de l'application.
Dans ce cas, la tâche du traducteur consiste à corriger les erreurs en remettant les choses à leur place. Le cas d'utilisation "Correct errors" sera en charge d'effectuer ces corrections.
N'oublions pas que le composant "Connectable application" est également nécessaire pour suivre le travail du traducteur et quantifier la charge (temps) de traduction.
Nous présenterons par la suite le modèle objet correspondant aux cas d'utilisations cités dans l'article et étudierons des différentes solutions techniques.
Boutique |
Sites |
Bar |
Forum |
PhpBB |
Actu |
Glossaire |
Codes |
Tips |
Liens |
Livres |
Lettre
