Quel CMS pour un site multilingue ?
Une petite définition avant de commencer : l’internationalisation, que les geeks abrègent en i8n, c’est préparer un logiciel pour qu’il puisse être traduit. C’est donc un travail sur la structure de ce logiciel, et le traitement des chaines des caractères, qui permet ensuite de passer à la localisation (l10n) qui est elle, la véritable traduction. On peut donc très bien avoir un CMS internationalisé, mais pas localisé.
Le CMS a t il été internationalisé ?
Question de base à se poser, la réponse est dans 99% des cas, “oui”.
Question suivante : dans quelle mesure, et selon quelle logique ? Cette question va permettre de voir si toutes les fonctionnalités de votre CMS peuvent être traduites.
Il faut regarder à la fois le core du système, mais aussi les extensions, en tout cas celles que vous prévoyiez d’utiliser.
Il faut aussi regarder comment sont gérées les urls des articles traduits, si vous pouvez faire ce que vous voulez ou si vous êtes contraints par un système rigide (et dans ce cas là, ces contraintes vous conviennent-elles ?
Des localisations existent-elles ?
Si la traduction du core du système est faite pour les trois CMS en question, (et très rapidement pour WordPress grâce à l’équipe de WordPress-fr), il faut aussi regarder ce qu’il en est pour les thèmes et les modules ? Sont-ils le plus souvent déjà internationalisés, voir traduits, ou aurez vous tout le travail de les préparer pour la traduction et de les traduire ?
Et y a-t-il une communauté dans votre/vos langue(s) qui assure rapidement ces traductions ?
Testez, retestez, et recommencez les tests
Dans ce domaine plus qu’ailleurs, “Der Teufel steckt im Detail”.
Pour donner un exemple récent, je suis en train de préparer un site trilingue, allemand – anglais – français. Le client est allemand, donc la page d’accueil par défaut doit être en allemand. Mais comme je ne parles pas parfaitement allemand, et que le client devait fournir les textes dans cette langue, j’ai naturellement commencé par faire le site en anglais, notre langue commune.
Seulement gros problème au moment d’activer l’internationalisation (dans ce cas WPML pour WordPress) : le plugin fonctionne en attribuant l’url “de base” à la langue par défaut, et les “autres” url aux autres langues (que ce soit sous-répertoire, sous-domaine ou un autre système). Donc il fallait repasser à travers tous les articles et catégories pour indiquer qu’ils étaient écrits en anglais, et pas en allemand.
Cela n’est pas un problème sur un site de test… sur un gros site, si.
J’ai par ailleurs découvert d’autres limitations du plugin, qui font que je ne compte pas l’utiliser. J’en parlerai dans l’article sur WordPress.
Tester en configuration complète
Il est essentiel de vérifier que les plugins, modules ou extensions que vous voulez utiliser sont compatibles avec le système de traduction. Si ce n’est pas le cas, et que vous n’arrivez pas à trouver une solution de remplacement, vous pouvez être amenés à développer certaines fonctionnalités vous-mêmes, ce qui à un impact certain sur votre budget.
Pour cela, il faut donc connaitre le CMS avec lequel vous voulez travaillez, connaître la configuration souhaitée. On ne commence pas la prise en main d’un CMS avec l’internationalisation (enfin si, c’est ce que j’ai fait avec Drupal, mais il est clair que cela prend plus de temps. Par ailleurs j’ai eu la chance d’identifier tout de suite ce qui était bloquant dans Joomla, et donc de partir vers “la bonne solution”. Mais c’est de la chance).
La configuration doit donc comprendre l’url rewriting, selon ce qui aura été décidé pour le site. Notamment, si vous souhaitez travailler avec des sous-domaines, et que vous êtes sur un serveur mutualisé, vérifiez bien que c’est possible.
Pour finir
Les prochains articles traiteront de Joomla, Drupal et WordPress. Cette revue n’est pas exhaustive. Lumière de Lune n’est pas une agence Web avec un personnel pléthorique pouvant se permettre de maîtriser de nombreux outils. Certains CMS, comme TYPO3, par exemple, ont été éliminés parce que le backend est extrêmement lourd, d’autres comme CMS Made Simple, parce que il ne semblait pas y avoir de solution – en gros si au bout d’une demi heure je ne trouve pas de début de piste, je laisse tomber.
La présélection a donc été faite sur les CMS que j’étais disposée à utiliser, pour des tas de raisons, et en excluant d’office certains. Si le sujet vous intéresse mais que vous ne trouver pas votre CMS préféré, pas la peine de m’incendier, mais faites le même travail.
Ma conclusion a été de choisir Drupal. C’est basé sur mes propres critères, et mes propres besoins. C’est un choix qui peut être différent pour vous, et cela ne vous dispense donc pas de tester !
La solution définitive : WordPress et WPML
En 2010, j’ai effectivement travaillé sur Drupal. Néanmoins, j’ai été découragée par la lourdeur de l’outil, absolument inutile pour des petits sites comme ceux que je faisais pour les hôtels.
J’ai finalement préféré me concentrer sur un seul outil, WordPress avec WPML, et faire avec ses limitations. Aujourd’hui je ne regrette pas ce choix. WPML a énormément évolué et permet de rendre multilingue des sites complexes, avec un “cost of ownership” nettement plus bas qu’avec Drupal.
Le plus dûr avec un site multilingue, c’est souvent de maintenir les différentes traductions à jour, au fil des mises à jour de contenus…
Et cela, très peu de systèmes permettent de le faire efficacement.
Pour répondre à cette problématique, jetez un oeil aux fonctionnalités de synchronisation multilingue offertes par “Anwiki” ;)
Drupal est pas mal pour cela, avec un certain nombre de fonctionnalités de suivi, et notamment la possibilité de “détacher” un article de sa traduction si elle doit être révisée.
Je suis passée voir les descriptions de votre votre “wiki / cms”, disons qu’en dehors de l’édition Ajax avec la mise en évidence des modifications, pour le reste ça a l’air assez “normal”.
En revanche, cette mise en évidence des modifs est un gros plus, effectivement.
Question…
Imaginons un contenu FR, traduit en anglais et espagnol.
Il est mis à jour une première fois. Le traducteur anglais fait son boulot tout de suite, pas le traducteur espagnol.
L’article fr est mis à jour une deuxième fois. Que montre t on quand on se trouve dans la version espagnole ?
Par ailleurs, quand je vois qu’il n’y a pas de langue maitre, je le comprends comme “je peux créer une nouvelle traduction à partir de n’importe quelle traduction”
(mon contenu d’origine est en français, je le traduis en anglais, mon traducteur allemand ne connait pas le français, il travaille donc par rapport à l’anglais, mais son texte est automatiquement répertorié comme une traduction du français), est ce cela ? Et comment cela se passe pour l’info sur les modifs ?
Tout d’abord, l’idée fondamentale est de totalement dissocier :
– l’édition, qui vise à ajouter ou mettre à jour une information, et est suceptible de toucher à la structure même du contenu
– la traduction, qui se fait via un formulaire ajax-like, et qui ne fait que traduire un “bloc” d’un contenu existant sans en altérer la structure
Lors de édition d’un contenu, les changements sont répercutés “intelligement” sur l’ensemble des traductions, ce qui signifie que chaque traduction est forcément à jour avec la dernière information (soit dans la langue à l’origine de l’édition, soit dans sa version traduite).
Lors de la traduction d’un contenu, les changements n’ont aucun impact sur les autres traductions.
Pour répondre à votre question, prenons en exemple le contenu traduit dans les langues suivantes:
FR: “TitreParagraphe”
EN:”TitleParagraph”
ES:”TítuloPárrafo”
Après édition par un éditeur français (ajout d’une phrase à la fin):
FR: “TitreParagrapheLa conclusion”
EN:”TitleParagraph[untr]La conclusion[/untr]”
ES:”TítuloPárrafo[untr]La conclusion[/untr]”
(le texte encadré par [untr]..[/untr] signifie qu’il n’est pas traduit, mis en évidence par surlignage et accès facilité pour les traducteurs – une liste + flux rss des contenus à traduire est à dispo pour chaque langue).
Le traducteur anglais fait son boulot, pas le traducteur ES :
FR: “TitreParagrapheLa conclusion”
EN:”TitleParagraphThe conclusion”
ES:”TítuloPárrafo[untr]La conclusion[/untr]”
Autre édition par l’éditeur français (mise à jour du titre):
FR: “Nouveau titreParagrapheLa conclusion”
EN:”[untr]Nouveau titre[/untr]ParagraphThe conclusion”
ES:”[untr]Nouveau titre[/untr]Párrafo[untr]La conclusion[/untr]”
La version espagnole est donc à jour avec les dernières informations disponibles, mais partiellement traduite. Malgré les différentes éditions, aucune traduction qui ne soit pas obsolète n’a été perdue.
Le fait qu’il n’y ait pas de langue maître permet effectivement de “démarrer” une traduction à partir de n’importe quelle langue. Mais cela n’a au final aucune d’importance, car le traducteur peut choisir sur son formulaire de traduction dans quelle langue afficher les textes d’origine à traduire. C’est techniquement possible, vu que les traductions restent synchronisées en permanence !
Pour voir tout cela en action, une vidéo explicative est dispo (rubrique screenshots) :-)
Non là vous avez triché ^^ le cas qui est intéressant (et très fréquent) c’est quand la nouvelle édition est
FR: « titreParagrapheLa pas tout à fait conclusion »
Par ailleurs, autant ce concept est intéressant en théorie, autant en pratique j’ai un peu de mal à voir la solution technique pour gérer des traduction sur un site de taille moyenne, disons 4.000 à 5.000 pages sur 4 ou cinq langues ?
Hé, mais c’est que vous essayez de me coincer !! ;-)
Nous en sommes donc là :
FR: « TitreParagrapheLa conclusion »
EN: »TitleParagraphThe conclusion »
ES: »TítuloPárrafo[untr]La conclusion[/untr] »
Si l’éditeur français met à jour la deuxième phrase :
FR: « TitreParagrapheLa pas tout à fait conclusion »
EN: »TitleParagraph[untr]La pas tout à fait conclusion[/untr] »
ES: »TítuloPárrafo[untr]La pas tout à fait conclusion[/untr] »
C’est le même fonctionnement, en mode édition, la modification se répercute sur toutes les traductions, qu’elles aient été traduites ou non entre temps…
En pratique, c’est extrèmement efficace, d’autant plus sur un site de grande envergure avec un grand nombre de langue et d’acteurs : autant on peut arriver à se coordonner en petite équipe pour quelques contenus, autant on ne peut pas improviser cette coordination pour plusieurs milliers de pages.
Une synchronisation logicielle est alors nécessaire, et c’est ce que propose le système !
C’est pas mal, c’est pas mal.
Et comment vous gérez les traductions partielles, incomplètes, genre “j’ai commencé à traduire mais c’est pas fini”, quand la “chaine” à traduire est longue.
Parce que là vous donnez un exemple simple, mais sur un long texte, dans la vraie vie, il n’y a pas de correspondance un pour un entre les phrases.
Donc sur le contenu typique d’un post de mon blog, typiquement entre 1.500 mots et 2.500, comment vous faites ? C’est “une phrase” ? Comment vous repérez ce qui a déjà été traduit ou pas ? Un traducteur ne pas pas travailler “phrase à phrase”. C’est quoi la règle ? Parce que si la chaine “la conclusion” fait en réalité 250 mots et qu’elle est déjà à moitié traduite, notre espagnol, qui n’est pas paresseux, mais a simplement des problemes de traduction, n’appréciera peut être pas de voir son travail réduit à néant.
Ah, en voilà une bonne question ! :)
C’est bien là le point délicat, et vous soulevez le problème qui peut se poser si le contenu n’est pas suffisamment “sectionné” en “phrases”, à savoir la perte des traductions en cas de mise à jour.
Je n’ai à vrai dire pas trouvé de définition universelle permettant de reconnaître une “phrase”. Le concept de phrase, à l’écrit, c’est vague. Cela peut varier complètement d’une langue à une autre…
Le système n’étant pas encore doté d’une “super-intelligence” capable de décider par lui-même où “couper” le contenu pour en identifier les “phrases”, il utilise…
…les balises XML (ou XHTML) du contenu comme délimiteurs !
Si vous connaissez le principe du HTML (j’en suis convaincu), vous constaterez qu’en général, les contenus HTML sont suffisamment régulièrement “coupés” par des balises, et ce de manière assez logique vis à vis du sens du contenu : paragraphes, éléments des listes, titres, passages en gras, liens, retours à la ligne… Vu que toutes ces balises sont structurantes et font partie intégrante de la plupart des contenus, alors pourquoi ne pas s’en servir comme délimiteur de “phrases”…
A vrai dire, j’avais inclus des balises dans mon exemple mais elles en ont été mystérieusement évincées de mon commentaire :-)
En reprenant mon exemple, mais en utilisant les caractères “[” et “]” pour délimiter les balises HTML afin qu’elles soient visibles, cela donne :
FR: « [h1]Titre[/h1][p]Paragraphe[/p][p]La pas tout à fait conclusion[/p] »
Enfin, dans les cas où un long contenu est saisi sans qu’aucune balise ne soit pertinente, une balise speciale, “[fix/]”, a été prévue pour “couper” le contenu de manière invisible (la balise est supprimée à l’affichage). On peut donc “manuellement” forcer le découpage du contenu comme bon nous semble…
Ce raisonnement n’est évidemment pas limité aux contenus HTML, il est extensible à tout contenu XML (fichiers de traduction, contenu structuré, etc…)
Oui je shunte volontairement pas mal de balises.
Je suis désolée d’avoir mis le doigt sur le “point faible”, mais disons que c’est un peu le résultat de pas mal de pratique sur la traduction.
En fait, le point auquel je voulais venir est le suivant :
– soit on saucissonne à un tout petit niveau, et on peut arriver effectivement à synchroniser ‘finement’, mais cela ne me parait pas praticable.
– soit on saucissone à un niveau moyen comme par exemple le paragraphe (ou tout autre “truc” comme votre balise [fix]), et dans ce cas là vous vous heurtez au problème des traductions partielles, du versionning, et vous allez grosso modo retourner vers un système de gestion à la gettext couplé à PO Edit ou autre.
D’ailleurs, d’une manière générale, vous ne semblez pas gérer la validation de la traduction. Comme sait on qu’une chaine est traduite de façon valide ?
En revanche sur des sites où le contenu existant est rarement mis à jour, ou bien avec des contenus de petite taille (dictionnaire, base produit), ça peut être pas mal.
Disons que le niveau “moyen” est en général amplement suffisant pour une bonne synchronisation des contenus multilingues. Concrètement, cela donne un niveau de finesse d’environ 1 à 2 phrases (au sens linguistique), au delà, cela devient contre-productif de gérer des “traductions partielles” sur des morceaux de phrases.
Le versioning est bien géré, comme dans n’importe quel wiki. La validation n’est effectivement pas encore implémentée, mais ne serait pas compliquée à mettre en place.
Le système offre effectivement les possibilités d’une approche “à la gettext” couplé avec un formulaire de traduction, mais avec des avantages non négligeables :
Alors que gettext nécessite du développement à chaque création et mise à jour de la structure des contenus, cela est géré en automatique sur Anwiki, via des algorithmes XML.
Ces mêmes algorithmes permettent par ailleurs de réorganiser un document (inversion de blocs, remise en forme, etc) sur l’ensemble des traductions.
Au final, la comparaison qui me semble la plus juste serait le cas que vous citez dans votre article “Faire un site multilingue, les contraintes du multilinguisme” : “On peut tout de suite oublier les sites faits en HTML pur et dur. A moins qu’ils n’aient que quelques pages, la tâche de traduction, et de mise à jour simultanée des pages en cas de changement d’un élément, sera tout simplement impossible.”
Le système offre la flexibilité des pages HTML pures et dures, tout en assurant la mise à jour automatique et simultanée de toutes ces pages en cas d’édition. Le meilleur des deux mondes.
Il est donc d’autant plus adapté aux projets avec un grand nombre de contenus qui évoluent fréquemment et qui font intervenir un grand nombre de collaborateurs (il a d’ailleurs déjà fait ses preuves sur de tels projets).
Bonjour,
À propos de WPML, que je trouve absolument génial dans le principe, j’ai été confrontée à quelques kms d’erreurs php venant de lui. J’ai déposé un rapport de bug chez eux. J’espère que ça contribuera à le faire améliorer. J’ai aussi trouvé que d’autres plugins faisaient souci, ce sera l’objet aussi de quelques mails ou visites sur les bugzillas.
Cela dit… je vais aller voir ce anwiki… :)
Cela pourrait bien m’intéresser !
Bonne fin d’année, Joyeux Noël Marie-Aude, et anw !!!
Joyce
Au dire de beaucoup d’utilisateurs, les sites sous SPIP se référencent efficacement et le script est développé et maintenu en permanence par une équipe dynamique, qui améliore régulièrement les fonctionnalités.
Bonjour et merci pour ces infos.
Et en 2014, quel CMS pour un site multilingue?
WordPress avec WPML ou un autre, tout dépend de vos besoins précis…
Merci. Après avoir lu l’autre discussion concernant les thèmes WordPress, j’ai pensé que c’était la solution d’aujourd’hui.