stratégie multilangues et référencement

danielsan

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

Jos

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.

danielsan

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

Jerry Wham

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

danielsan

me voilà rassuré


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!

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

danielsan

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

bg62

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!

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

danielsan

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

Stéphane

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

danielsan

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
J'ai enfin trouvé comment passer ça au nom de la boite


Le temps que la 5.1.7 soit opé, je vais temporiser le client en lui disant que j'attends les trad'

danielsan

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éphane

danielsan

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 ! ^^^
J'finis ma compta et clique sur le bouton orange

bg62

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
@+

danielsan

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éphane

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)

Stéphane

je viens de penser à la prochaine modif à faire: basculer le theme de la langue sélectionnée coté visiteur

bg62

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

danielsan

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


@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

Jerry Wham

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 !

bg62

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!

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.

danielsan

@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éphane

#danielsan: git à jour, erreurs corrigées

danielsan

effectivement merci.
avec le plugin j'ai (courage ):

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éphane

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

danielsan

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.

danielsan

@Stéphane : merci, tout est rentré dans l'ordre. J'essai d'avancer sur les autres points.

Stéphane

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