Quel CMS pour un site multilingue ?

Marie-Aude

J'ai fait de la compta, de la finance, du juridique, j'ai été chef de projet SAP, j'ai fait de la photo, des voyages. Depuis 2007, je fais avec amour des sites webs pour les utilisateurs, qui se référencent bien et je vous aide à acquérir du trafic pertinent.

Vous aimerez aussi...

14 réponses

  1. anw dit :

    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” ;)

  2. Marie-Aude dit :

    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 ?

  3. anw dit :

    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) :-)

  4. Marie-Aude dit :

    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 ?

  5. anw dit :

    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 !

  6. Marie-Aude dit :

    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.

  7. anw dit :

    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…)

  8. Marie-Aude dit :

    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.

  9. anw dit :

    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).

  10. Mélodie dit :

    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

  11. 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.

  12. Solène dit :

    Bonjour et merci pour ces infos.
    Et en 2014, quel CMS pour un site multilingue?

  13. Solène dit :

    Merci. Après avoir lu l’autre discussion concernant les thèmes WordPress, j’ai pensé que c’était la solution d’aujourd’hui.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *