Bonjour à tous,
Lors de la mise en place de
mon site web, j’ai mis en place une architecture pour la gestion du multilingue, que je vais essayer d’expliquer ici.
L’idée de départ est la même que la
méthode du wiki: avoir un répertoire par langue, nommé par le code ISO de 2 lettres (fr, en, de, etc).
Cependant, mon objectif était que la gestion soit aisée pour le non informaticien.
Voici les points que j’ai voulu traiter:
1) L’idée majeure est qu’il y a une langue de référence.
Pour rajouter une langue, il suffit de dupliquer le dossier de la langue de référence, puis de traduire.
Pour rajouter une seule page dans une autre langue, on duplique le document, on modifie son parent, puis on traduit.
2) Dans la solution du wiki, lorsqu’on ajoute une traduction, il faut mettre à jour tous les documents dans les autres langues pour rajouter dans la TV la référence de la nouvelle traduction.
Dans ma solution, on n’a pas à modifier les autres documents: on indique simplement dans la nouvelle traduction la référence du document dans la langue de référence (pour les documents de la langue de référence, on ne met rien)
3) Toute page de la langue de référence n’est pas nécessairement traduite dans la langue de référence, et vice versa: dans ce cas, on ne met rien comme référence.
4) Il fallait aussi gérer la traduction des templates utilisés dans les snippets (dans mon cas, AjaxSearch, Eform et WebLoginPE). Or, je ne voulais pas utiliser des fichiers de langue car je voulais que tout le processus de traduction passe par le manager pour que ce soit uniforme.
Description de la solution
1) Créer une TV pour indiquer la référence du document dans la langue de référence (dans mon cas le français). Pour les documents de la langue de référence, on laisse cette TV vide.
Afin que ce soit plus ergonomique, j’ai créé cette TV avec le
snippet ddTree, mais on peut se contenter d’une TV de type nombre.
2) Créer un snippet de gestion des aspects multilingues, qui utilise
Ce snippet peut:
- récupérer la langue d’un document, en récupérant le nom du dossier parent avec le
snippet GetField
- récupérer l’ID d’un document qui est la traduction d’un document dans une langue donnée, grâce à un algorithme basé sur la TV créée précédemment
3) Créer un template vide constitué uniquement de TV, afin de contenir les éléments textuels du template général (ex: une TV pour le pied de page, ...).
Chaque dossier de langue doit contenir un document avec ce template (document publié, mais masqué dans le menu et non recherchable).
4) Créer le template général qui est commun à toutes les langues, et lui appliquer la TV définie en 1). Ce template utilise le snippet de gestion des aspects multilingues pour tous les aspects liés à la langue.
Exemple:
[tt]<html xmlns="
http://www.w3.org/1999/xhtml" lang="{{DocLang}}" xml:lang="{{DocLang}}" dir="ltr">[/tt]
avec dans le chunk DocLang, l’appel suivant, qui récupère la langue du document courant:
[tt][!MultiLingual? &action=`getLang` !][/tt]
Autre exemple, pour le pied de page:
[tt]<div id="footer">
[!GetField? &docid=`[!MultiLingual? &action=`getTranslation` &docId=`2` !]` &field=`SiteFooter` !]
</div>[/tt]
où 2 est le document dans la langue de référence qui contient les éléments textuels du design général, et SiteFooter est la TV associée au pied de page.
5) Créer les documents dans la langue de réference
6) Dupliquer le répertoire de référence et traduire
Gestion des liens de traduction
J’ai créé un snippet dédié, appelé ainsi dans mon template:
[tt][!TranslationLink? &languages=`fr,en` !][/tt]
Pour chaque langue passée en paramètre, ce snippet:
- vérifie s’il s’agit de la langue du document en cours, auquel cas il n’affiche pas de lien
- vérifie si le document courant est dans la liste des documents ne devant pas avoir de liens de traduction, auquel cas il n’affiche pas de lien
- constitue l’URL de la traduction du document courant en utilisant le snippet de gestion des aspects multilingues
- récupère le texte du lien dans une TV du document qui contient les éléments textuels du design général
Snippet AjaxSearch
1) Les textes affichés dans le template font l’objet de TV dans le document qui contient les éléments textuels du design général.
Dans mon cas, il s’agit uniquement du texte par défaut du champ de recherche. J’ai utilisé un template personnalisé pour $asTemplates[’form’] et $asTemplates[’layout’], qui récupère la valeur de la Tv grâce au snippet GetField et au snippet de gestion des aspects multilingues.
2) Le paramètre &language attend un nom complet tel ’english’ et non le code de 2 lettres ’en’. Pour résoudre ce problème, j’ai modifié le snippet de gestion des aspects multilingues afin qu’il puisse renvoyer le nom complet de la langue lorqu’on l’appelle ainsi:
[tt][!MultiLingual? &action=`getLang` &byName=`true` !][/tt]
3) Comme j’utilise l’option non-Ajax, j’ai une page de résultat dans chaque langue. Pour le paramètre &AS_landing, j’utilise donc encore une fois le snippet de gestion des aspects multilingues.
Snippet EForm
J’ai une page de contact par langue. Pour conserver le principe que tout le processus de traduction passe par le manager sans mettre en péril la mise en forme du formulaire, j’ai adopté la solution suivante.
1) J’ai défini un template spécifique aux pages de contact:
- le contenu est le même que le template général
- il s’y ajoute une TV pour chaque texte du formulaire
2) Pour le paramètre &tpl, j’ai créé un chunk pour le formulaire de contact, qui utilise les TV définies.
Extrait du chunk:
[tt]<div class="form_textfield">
<label for="contact_name">[*ContactFormNameLbl*]* :</label>
<input type="text" name="contact_name" id="contact_name" eform="[*ContactFormNameLbl*]::1" />
</div>[/tt]
où ContactFormNameLbl est une TV
3) Le paramètre &language a le même fonctionnement que celui d’AjaxSearch
