stratégie multilangues et référencement

danielsandanielsan Member
décembre 2012 modifié dans Entraide
Bonjour à vous,


Dans un site multi-langues, il y a le contenu et le template qui doivent être traduits.
Pour ce qui est du template, PluXml sait le faire et le plugin jumpLang permet de basculer d'une version à l'autre.


Pour le contenu, on a 3 possibilités de gérer le multilangue:
1/ installer autant de PluXml qu'il y a de langue ( et on partage les dossiers communs ).
2/ rajouter des champs dans les articles pour les traductions et faire des tests de condition pour l'affichage de la version appropriée.
3/ rajouter des articles/catégories/statiques, et modifier automatiquement les menus et liens en fonction de la langue.


Hors je me demandais avec la solution n°2, les url seront dans la langue principale.
Comment réagit le référencement dans un tel cas ?
Autre point, les urls ne seront pas compréhensibles par les étrangers à cette langue principale. Est-ce que cela pose un problème ?


J'aimerai avoir votre avis sur la stratégie de référencement à avoir pour le référencement d'un site multi-langue, et quelle stratégie adopter.


Cordialement,
_____
D.San
«13

Réponses

  • Je ne fais pas de site multil-angues, mais ma logique me dirait d'opter pour la solution 1. Au moins, la questions des url ne se pose pas. En terme de référencement, les url sont importantes. Parcontre, cette solution sera plus longue à mettre en place, mais je pense qu'au final çà payera.
  • Merci pour ton avis.


    A mon sens je pense qu'au contraire cette solution est la plus rapide et fiable dans le cas d'un site où il y a peu de mise à jour.
    Je vais continuer à faire des tests car chacune des solutions ont leur avantages et inconvénients :(
  • Je me suis déjà posé la question mais je n'ai pas la réponse. L'installation de plusieurs pluxml est valable si tu as une équipe de traducteurs mais il faut qu'il puisse y avoir partage des articles pour les traduire et être sûr d'avoir la même information d'une version à l'autre.


    Ajouter des champs, je ne suis pas convaincu non plus. Si tu as énormément de langues à traduire et que tes articles sont d'une longueur conséquente, tu vas te retrouver avec des fichiers énormes.


    La troisième solution me semble la plus pertinente mais je ne suis pas totalement convaincu. Peut-être un mix des 2 solutions avec un champ supplémentaire qui afficherait l'article de la langue principale, la traduction s'écrivant dans le champ déjà existant, le choix de la langue se faisant par les catégories?

    Reste le problème des url. C'est pas gagné...
  • me voilà rassuré :D


    je travaille effectivement avec une équipe de traducteurs.
    Les fichiers sont exportés avec le plugin XML2TXT.
    Le site en question a un nombre fixe d'article/contenu/static.
    Donc la solution 1 a l'air d'être la plus simple et adéquat.
    Faut juste que je rajoute un champ pour y insérer l'adresse du dossier image de la version principale.


    Je ne suis pas convaincu non-plus pour rajouter des champs pour les meta/chapo/contenu/titre ... ça va être énormissime.


    Dans l'idéal, j'aurai bien vu qu'en cliquant sur le petit drapeau, ça affiche la page active dans la langue associée ... mais ça voudrait dire des liens en back-office qui relient le tout :(


    Pas facile cette affaire ... et j'en ai marre, j'aimerai arriver au bout !


    Si tu as d'autres pistes de réflexion, e suis preneur !
  • zakar!zakar! Member
    décembre 2012 modifié
    Faudrait dans ce cas detecter/définir les langues disponible, et lors de la création de l'article ajouter un petit drapeau pour chaque langue sur tout les champs.


    Pour l'enregistrement de l'article, il suffirais d'ajouter la langue en paramètre et ainsi charger uniquement l'article correspondant a la langue.


    En faut cela me fait penser a un plugin pour joomla qui traite le multilingue de cette manière (fait tellement longtemps joomla que je ne c'est plus le nom du dit plugin sorry).


    Donc en somme j'opterais pour la solution 3, étant donné que tu renseigne aussi ton doctype (fr,en...) ca ne pose aucun problème pour le référencement qui justement tiendras compte du doctype ;)
  • ah oui le doctype ... faut que je note ça !
    mais la solution 3 ne le prend pas nativement car avec cette solution j'ai une langue principale du site dans lequel je crée du contenu d'une autre langue ... on voit encore qu'il y a des avantages et inconvénients pour chaque approche ...
  • en tous cas il est plus que rare de voir quelqu'un se poser la question ... avant !
    bravo :)
    de par expérience, au niveau du référencement futur des différentes versions, je te répondrai que TOUT doit être différent et là aucun problème ...
    un petit résumé de tests que j'avais fait:
    http://www.unesourisetmoi.info/pages/internationalisation.php
    et en poussant le bouchon encore plus loin :
    - lorsque tu convertis une page dans une autre langue, introduis en plus quelques variantes ou 'différences'
    - lorsqu'il y aura référencement, là aussi penser que tout se passe dans 'x' domaines différents ( x = nbr de langues )

    finalement :
    - codage
    - contenu
    - etc ...
    et se souvenir que Google par exemple est un moteur de recherches avec ses propres règles qui en plus varient dans le temps, rien à voir par exemple avec le W3C ou autre ...
    @+
  • zakar!zakar! Member
    décembre 2012 modifié
    La vrai question qu'il faut ce poser et:

    Est ce qu'un moteur de recherche sait différencier UN site multilingue ?


    Mais je suis d'accord avec bg62 sur le fait que tout doit être différents.


    Dans ce cas avec cette reflection, l'option 1 serait la plus adapter, a savoir un pluxml pour différente langue.


    Car si de plus tu as une équipe de traducteur, autant que chaque langue soit traité directement sur un pluxml différent.


    A toi ensuite de contrôler que tout soit 'identique' niveau contenus et pages ;)
  • okayyyyy.


    Est-ce que je risque un duplicate-content si la structure des pages et la même et s'il y a les mêmes images aux mêmes endroits (sachant que les atl/title sont aussi traduits), ou le fait de faire des variations (un exemple ?) et juste pour favoriser le référencement des langues étrangères ?


    Les traducteurs ne vont pas toucher à PluXml, je leur envoie les fichiers au format .txt et moi je place les contenus aux bons endroits (j'ai prévu de dupliquer le site français et après de remplacer les contenus, et donc de refaire les url ).


    Mon client a acheté un max d'extension à son nom de domaine. Faudrait donc que je fasse pointer un .fr vers le dossier /fr, le .com vers le /en et ainsi de suite ? Sacré bordel. Je ne sais pas comment je vais m'en sortir là ...


    Je note l'attribut lang. Il faut donc qu'il soit au moins placé dans les drapeaux :D
  • StéphaneStéphane Member, Former PluXml Project Manager
    Bonjour
    Je t'ai fait une trame pour un plugin multilingue.
    http://my-pluxml.googlecode.com/files/plxMyMultiLingue.zip
    Le principe est d'avoir coté admin un lien fr et en pour switcher entre le français et l'anglais (lien en haut à droite de l'admin). Ainsi les articles sont sauvegardés dans data/articles/fr ou dans data/articles/en
    Coté visiteur rajoute dans la sidebar
    <?php eval($plxShow->callHook('MyMultiLingue')) ?>
    
    ça affichera de la même façon que dans l'admin un lien fr ou en pour afficher les articles rédigés en français ou en anglais.
    Ce plugin ne fonctionne qu'avec la version 5.1.7 en cours de dev sur le github de PluXml car j'utilise un hook qui ne sera dispo qu'à partir de cette version.
    Pour les différentes langues gérées, c'est à partir du tableau aLangs.
    J'ai fait très simple et c'est loin d’être finalisé, car sur le même principe il faudrait gérer les pages statiques, les catégories, etc...
    Bon après pour aller plus loin faudra sortir le carnet de chèques... :D

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • danielsandanielsan Member
    décembre 2012 modifié
    ok merci Stéphane, je regarde ça.

    Stéhane a écrit:
    Bon après pour aller plus loin faudra sortir le carnet de chèques...
    je voulais te faire la surprise
    mais tu vas déjà avoir un don vu que le site est en ligne :D
    J'ai enfin trouvé comment passer ça au nom de la boite :p


    Le temps que la 5.1.7 soit opé, je vais temporiser le client en lui disant que j'attends les trad' ;)
  • bon j'ai trouvé un pluxml-master et testé le plugin ... ah ouaiiiiis okayyyyyyy
    Quand stéphane débarque, il envoie une nouvelle approche !!! mortel.
  • StéphaneStéphane Member, Former PluXml Project Manager
    ;)

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • danielsandanielsan Member
    décembre 2012 modifié
    bon on va s'y coller car il est vraiment génial ce plugin.


    Si j'arrive à résumer les choses à faire:
    1/ appliquer le principe aux catégories et statics
    2/ gérer la gestion du changement de langue au thème (en s'inspirant de JumpLang ?)
    3/ trouver un moyen de gérer l'ajout du plugin APRES la conception du site (déplacer les data dans le bon dossier)
    4/ tester la compatibilité avec les autres plugins
    5/ j'ai un doute sur les statics contenant du code (formulaire et autre)
    6/ doit-on repartir à l'entrée du site ou sur la page concernée lorsqu'on clique sur les boutons ? ( faire une redirection dynamique)


    En tout cas bravo, en moins de 100 lignes le bazar ! J'suis jaloux ! ^^^ :D
    J'finis ma compta et clique sur le bouton orange :p
  • pas testé, désolé, mais si le plugin sert à 'tout traduire' cela reviendra un peu au même style que 'google translate' ... c'est ça ?
    un peu comme ici :
    http://www.unesourisetmoi.info/net/index.php
    (avec toutes les langues ..)
    http://www.unesourisetmoi.info/gifs/index.php
    (avec anglais et allemand)
    dans ces cas ce n'est pas le top car rien ne vaut une réelle traduction littérale :)
    - soit le plugin est au top du top niveau traduction et peut alors servir pour la faire
    - soit l'idéal serait d'avoir un 'switcher' qui renvoie vers les différents domaines ( .fr, .en, .de etc ...)
    - le top de l'déal ( ;) ) surtout pour le ref restant bien sur des sites totalement distincts et référençables dans chacune des langues utilisées ( faisable pour un site statique ... énorme pour un blog qui se voudrait vraiment 'synchrone' !!!)

    pour exemple :
    http://www.commentcamarche.net/ = français
    http://en.kioskea.net/ = anglais

    et pour la petite histoire : le français du québec ... ils rédigent dans leur langue ???
    ;)
    mais ce n'est que mon avis
    @+
  • aucun rapport avec google translate ...


    au lieu d'enregistrer l'article dans le dossier data/articles, il l'enregistre dans data/articles/fr ou data/articles/en suivant la version sélectionnée.
    Il ne traduit donc pas, ne fait que répartir les données aux bons endroits
  • StéphaneStéphane Member, Former PluXml Project Manager
    Une petite mise à jour du plugin multilingue
    http://my-pluxml.googlecode.com/files/plxMyMultiLingue.0.1.zip

    recupere la derniere version de la 5.1.7 sur github (en date du 15/12) sinon le plugin ne fonctionnera pas, j'ai fait des modifs dans le core de PluXml pour pouvoir gérer le multilingue.

    si une version précedente du plugin est installée, il faut le désactiver, puis le réactiver, pour que le code d'init soit executé. J'ai déporté du code dans la fonction OnActivate du plugin, pour l'optimiser et éviter des tests inutiles à chaque chargement du plug.

    Donc le plugin maintenant gère:
    - toujours que le français et l'anglais uniquement pris en compte (tableau aLangs) car c'est encore du work in progress. A terme on mettera ça dans l'écran de config du plugin
    - rédaction indépendantes des articles en français et en anglais dans les dossier data/articles/fr et data/articles/en
    - gestion des commentaires dans les dossiers data/commentaires/fr et data/commentaires/en
    - gestion du contenu des pages statiques dans data/statiques/fr et data/statiques/en
    - gestion des tags, catégories, pages statiques (tags.xml, categories.xml, statiques.xml) dans data/configuration/fr et data/configuration/en

    Après activation du plugin dans l'admin 2 liens en haut à droite (fr et en) permettent de switcher entre le francais et l'anglais

    Coté visiteur, dans le fichier sidebar.php du theme il faut rajouter la ligne suivante pour avoir également un lien fr et en.
    <?php eval($plxShow->callHook('MyMultiLingue')) ?>
    

    Pour le coté visuel on paufinera plus tard pour avoir par exemple des drapeaux :).
    On se concentre sur le moteur pour le moment.
    Si tu vois des choses qui manqueraient...
    Voilà pour 150 lignes de code seulement (avec les commentaires dans le code) :D

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • StéphaneStéphane Member, Former PluXml Project Manager
    je viens de penser à la prochaine modif à faire: basculer le theme de la langue sélectionnée coté visiteur

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • danielsan a écrit:
    aucun rapport avec google translate ...


    au lieu d'enregistrer l'article dans le dossier data/articles, il l'enregistre dans data/articles/fr ou data/articles/en suivant la version sélectionnée.
    Il ne traduit donc pas, ne fait que répartir les données aux bons endroits
    ok ;)
    dans ce cas tout va rester sur le même ndd ...
    mais au niveau des langues se sera totalement différent
    ... compris
    super boulot !
    reste à tester ce que ça donnera avec 1 seul ndd ...
    là seul le contenu et l'avenir nous le dirons, tiens-moi au courant en tous cas, car je suis bien curieux d'en voir le résultat ;)
  • danielsandanielsan Member
    décembre 2012 modifié
    argggg ! ça me rend dingue.
    Merci Stéphane pour l'avancée !


    j'veux bien t'aider pour le peaufinage.


    j'ai déjà fait pour JumLang tous les petits drapeaux et le fichier config dans lequel on sélectionne les langues voulues à partir de celles supportées par PluXml.
    Mais je n'ai par contre pas réussi à intégrer ce qui concerne le changement de langue du thème (pas compris pourquoi d'ailleurs ... ) mais je m'y repenche dans le WE, entre 2 randos (j'ai croisé cet aprem mes premiers chevreuils ! 6 d'un coup qui ont déboulé à 20m de moi, le pied ! :p )


    @bg62 : les urls sont du type article1/contactez-nous ou article1/contact-us
    c'est vrai qu'une url du type /fr/article1/contactez-nous ou en/article1/contact-us aurait été mieux mais c'est déjà ça. Moi ça me va quand-même.


    @suivre
  • Mais qu'est-ce qui se passe ? Je m'absente deux secondes (jours :-°) et voilà ce que je rate !!!
    Et je ne peux même pas tester avant lundi !!! Arg, vais-je tenir ???

    J'avais eu une idée de ce style mais je n'avais pas su trouver comment la mettre en place. Et Stéphane, en 150 lignes y arrive. Mister Master sans aucun doute !
  • danielsan a écrit:
    @bg62 : les urls sont du type article1/contactez-nous ou article1/contact-us
    c'est vrai qu'une url du type /fr/article1/contactez-nous ou en/article1/contact-us aurait été mieux mais c'est déjà ça. Moi ça me va quand-même.
    sur que la seconde serait plus 'expressive' à tous niveaux ;)
    mais 'ma curiosité' se porte surtout sur le fait que tout partira du même ndd ... (il y a aussi l'histoire de géolocalisation de l'ip, du serveur,, etc ... si l'on veut encore aller plus loin ...)
    donc 'curieux' pour 'apprendre' ;)
    @+
  • zakar!zakar! Member
    décembre 2012 modifié
    bg62 a écrit:
    sur que la seconde serait plus 'expressive' à tous niveaux ;)
    mais 'ma curiosité' se porte surtout sur le fait que tout partira du même ndd ... (il y a aussi l'histoire de géolocalisation de l'ip, du serveur,, etc ... si l'on veut encore aller plus loin ...)
    donc 'curieux' pour 'apprendre' ;)
    @+
    Je suis tout autant curieux que toi bg62 :)


    Si on regarde les gros site assez bien référencé en multilingue, on voit bien que c'est 1 site 'dupliquer' en x langues qui le comporte.


    Que ce passe t'il de ta configuration de pluxml (metas) ?


    Tout ça pour dire que la solution la plus propre serait autant de pluxml que de langue car trop de modifications pour ton nds.


    Et bon pour ce que pèse pluxml, c'est vite vue est surmontable comparer aux usines à gaz de plusiers Mo.
  • danielsandanielsan Member
    décembre 2012 modifié
    @Stéphane : avant d'installer la dernière version, j'ai
    Notice: Use of undefined constant XMLFILE_PARAMETERS - assumed 'XMLFILE_PARAMETERS' in C:\xampp\htdocs\5.1.7-master\install.php on line 47
    

    et une fois installé:
    Notice: Use of undefined constant XMLFILE_PARAMETERS - assumed 'XMLFILE_PARAMETERS' in C:\xampp\htdocs\5.1.7-master\index.php on line 20
    
    Notice: Use of undefined constant XMLFILE_PARAMETERS - assumed 'XMLFILE_PARAMETERS' in C:\xampp\htdocs\5.1.7-master\core\lib\class.plx.motor.php on line 54
    
    Notice: Use of undefined constant XMLFILE_PLUGINS - assumed 'XMLFILE_PLUGINS' in C:\xampp\htdocs\5.1.7-master\core\lib\class.plx.motor.php on line 99
    
    Notice: Use of undefined constant XMLFILE_CATEGORIES - assumed 'XMLFILE_CATEGORIES' in C:\xampp\htdocs\5.1.7-master\core\lib\class.plx.motor.php on line 107
    
    Notice: Use of undefined constant XMLFILE_STATICS - assumed 'XMLFILE_STATICS' in C:\xampp\htdocs\5.1.7-master\core\lib\class.plx.motor.php on line 108
    
    Notice: Use of undefined constant XMLFILE_TAGS - assumed 'XMLFILE_TAGS' in C:\xampp\htdocs\5.1.7-master\core\lib\class.plx.motor.php on line 109
    
    Notice: Use of undefined constant XMLFILE_USERS - assumed 'XMLFILE_USERS' in C:\xampp\htdocs\5.1.7-master\core\lib\class.plx.motor.php on line 110
    
  • StéphaneStéphane Member, Former PluXml Project Manager
    #danielsan: git à jour, erreurs corrigées

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • effectivement merci.
    avec le plugin j'ai (courage :D ):
    Strict Standards: Declaration of plxMyMultiLingue::getLang() should be compatible with that of plxPlugin::getLang() in C:\xampp\htdocs\5.1.7-master\plugins\plxMyMultiLingue\plxMyMultiLingue.php on line 152
    
  • StéphaneStéphane Member, Former PluXml Project Manager
    ha oui en effet, c'est maladroit de ma part d'avoir appelé une fonction getLang dans plxMyMultiLingue, classe dérivée de plxPlugin qui contient aussi une fonction getLang.
    Edite plxMyMultiLingue.php et remplace partout getLang par getCurrentLang.
    Il n'y aura plus de conflit comme ça

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • zakar! a écrit:
    Que ce passe t'il de ta configuration de pluxml (metas) ?
    faut imaginer que les articles n'ont que l'id de commun, tout le reste est propre à chaque version, y compris les metas.
  • @Stéphane : merci, tout est rentré dans l'ordre. J'essai d'avancer sur les autres points.
  • StéphaneStéphane Member, Former PluXml Project Manager
    danielsan a écrit:
    zakar! a écrit:
    Que ce passe t'il de ta configuration de pluxml (metas) ?
    faut imaginer que les articles n'ont que l'id de commun, tout le reste est propre à chaque version, y compris les metas.

    les articles sont gérés indépendamment donc tu peux avoir des id différents pour 2 articles, meme si l'un n'est que la traduction de l'autre. ce n'est qu'une histoire d'organisation au niveau de la rédaction.


    le seul point qui peut etre bloquant pour le moment ce sont les metas du site (description, keywords).
    le plugin peut gérer ça très facilement. à mettre sur la todo du plugin

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

Connectez-vous ou Inscrivez-vous pour répondre.