Prestashop et la gestion du multilingue

LE MULTILINGUE C’EST NUL SUR PRESTASHOP !

Surtout si vous le gérez mal ! Voilà, c’est dit. Votre petit cœur fait des bonds ? Tant mieux. Maintenant que j’ai votre attention, je vais m’expliquer.

Beaucoup de personnes pensent qu’un site multilingue va leur ouvrir les portes de l’international rapidement, et se préparent à livrer dans des pays exotiques, ce grâce à une traduction chèrement payée, ou avec l’outil Google Traduction qui – malgré son amélioration – se fait fi de toute logique grammaticale et ignore totalement le sens des phrases.

Attention, je critique ici Prestashop, mais en ce qui concerne WordPress – WooCommerce, j’en ai également vu des vertes et des pas mûres, essentiellement des pas mûres. L’outil de gestion des langues de Prestashop a le mérite d’être très bien conçu, natif, mais il souffre toutefois de pas mal de défauts, majoritairement si vous le considérez comme une simple option à tester à l’occasion.

Partons du principe que vous avez bien traduit l’intégralité de votre site, en une langue, disons l’anglais. Et je dis bien TOUT traduit, sans aucune exception.

 

Le hreflang

Ah bien évidemment, vous avez pensé à mettre en place le hreflang. Cool, et peut-être avez-vous acheté un module sur Prestashop Addons qui est directement inspiré de mon tutoriel disponible ici, sauf que vous avez d’emblée commis une erreur : les modules sur Prestashop Addons n’incluent pas toujours la balise x-default (que notre module disponible gratuitement ici inclus pourtant… C’est dommage !). Le thème Classic sous Prestashop 1.7 ne l’inclut pas davantage, et ce manque est fort dommage, ne manquera pas d’être précisé par différents outils d’analyse du hreflang sur internet.

Mais bon, vous avez les hreflangs, Google l’a remarqué, et sincèrement, c’est un sacré travail que vous avez abattu. Pour anecdote, deux élèves que j’ai eu en organisme de formation ont eu à traduire un site dans une langue slave dont rien qu’à lire les trois premiers caractères, ma tête tourne. Certains ont autant de courage que de patience !

Si vous voulez voir ce que vaut de bonnes balises hreflang (et trèèèès loin de moi l’idée faire de la religion ou de la politique), mais jetez un oeil au site des témoins de Jéhova, regardez dans le code source la quantité de balises hreflangs présentes.  Je crois qu’ils ont plus d’une centaine de traductions impeccables, avec tout autant de hreflangs.

Bon, c’est un peu avec ce genre d’anecdotes qu’il ne viennent plus me démarcher, mais c’est un autre débat  😆 et je peux « témoigner » du travail réalisé sur leur site !

 

Vous pouvez cependant télécharger notre module gratuit intégrant les balises hreflang en cliquant ici

 

Les traductions

Okay donc vous avez tout traduit. VRAIMENT tout traduit.

…

Vraiment ?

Donc, vous avez traduit le thème, à supposer que celui-ci l’autorise (oui oui, j’ai fréquemment des surprises à ce sujet), les modules, les mails, les notifications, les URL, les titles, les meta descriptions, etc ?

Si c’est le cas, je tire bien bas mon chapeau tel un Cyrano en fin de vie (cherchez pas, y’a pas plus bas). Si vous avez un doute…

Un site disponible dans une autre langue devrait vous interpeller, rien que l’expression. Il s’agit d’une alternative, la balise HTML le prouvant : link alternate.

Pour résumer, oui vous serez bien visible pour les étrangers en France, cherchant à accéder à du contenu dans leur langue (et encore). D’ailleurs, c’est quand la dernière fois que vous êtes tombé sur un site brésilien, tout simplement parce que vous l’êtes ? Ou anglais ?

Sur certains emplacements, le hreflang est extrêmement utile, par exemple vers Toulouse, autour de Blagnac, car AirBus a tendance à importer de la main d’oeuvre issue d’Irlande et du Royaume-Uni. Là, ok. Allons donc encore plus loin.

 

L’extension de domaine & GTmetrix

Donc, hreflang ok, site intégralement traduit. Je pense qu’à ce niveau, pas mal de sites ne sont plus présents dans mon déroulé, je vais en éliminer encore pas mal d’autres.

 

Votre site est en .com, .org ou autre

Super, vous avez un site tellement généraliste, que vous passez après les sites possédant l’extension de domaine associée réellement au pays. Comme .uk, puisque depuis peu l’extension de domaine .co.uk est en cours d’abandon. Donc, en .com, niveau visibilité, pas top, encore pire si votre site est hébergé sur un serveur en Pologne par exemple. Imaginer avoir un bon SEO revient à dire que la note de GtMetrix est excellente, alors que de base l’outil analyse depuis… Vancouver ! Et par pitié, arrêtez de vous plaindre de la vitesse de chargement de votre site. Si celui-ci est hébergé chez OVH à Roubaix, il est tout à fait normal que celui-ci rame outre mesure si quelqu’un en Australie cherche à le visualiser. Imaginez un peu amener par avion vos données. Cela prendrait combien de temps ?

L’emplacement du serveur de votre site est un choix primordial. Critiquer OVH pour les downs qu’ils ont une fois par an est en un sens une aberration niveau SEO, leurs serveurs sont dans la même ville que ceux de la Team, à Roubaix, en France (non nous ne louons pas nos machines chez OVH, avec tout le respect que je dois à Mister Klaba 🙂 )

Paramétrez vos tests GtMetrix sur des zones plus proches, plus en rapport avec la localisation de votre activité. Faites des tests correspondant le plus possible à la situation réelle, et si quelqu’un est en train de travailler sur votre site, ne faites pas de tests, cela ne sert à rien : cette personne videra plus que probablement le cache, ce qui ralentira votre site, c’est on ne peut plus normal.

 

Vous avez une extension de domaine liée à votre pays

Cool. Donc vous pouvez être bien visible dans votre pays. Un site en .fr par exemple, c’est super !

Sauf à l’étranger.

Sincèrement, un site .fr en multilingue, ça n’est pas un site bien visible aux USA. La géolocalisation est depuis très longtemps un critère SEO des moteurs de recherche. D’ailleurs, il suffit de rechercher « garage auto » sur Google pour voir que ce dernier vous propose les garages alentours, pas aux USA. Oubliez la considération des pages Google My Business. Google sait où vous êtes.

Un .fr pour l’international ?

Mouais.

 

Les cas d’internationalisation

La Suisse notamment ! Quel bel exemple de pays justement multilingue… Les langues locales, très bien prises en compte par les balises hreflang, sont également un très bon exemple, quoi que moins utiles (c’est quand la dernière fois que vous avez parlé un patois provençal, ou en catalan ?)

Un pays ou une région multilingue, voilà à mon avis la plus grande utilité du multilingue (mais cela demeure un avis plutôt personnel, suite à des formations que justement j’ai été amené à réaliser dans des villes très proches de la Suisse).

 

Mais comment être visible à l’étranger ?

Hé ben, très simple !

Une balise hreflang notamment permet n’importe quelle URL. N’importe laquelle, même un autre domaine. L’idéal est d’avoir respecté tous les points cités précédemment (location serveur, traductions, etc), et de disposer d’une copie de son site initial, dans une autre langue, avec une autre extension de domaine. Comme votresite.uk, ou votresite.it.

Certes, cela double le coût de gestion et d’hébergement, mais les plus grands font de même.

Vous ne serez bien visible à l’étranger que si vous y êtes.

Avec des sites en .com, .fr, .uk, .it, .de, vous êtes définitivement à l’étranger 🙂 Désormais vous allez pouvoir travailler votre site selon chaque pays, et si l’un d’entre eux est en « carafe », tous les autres fonctionneront (contrairement à un multiboutique qui lui s’effondrera en entraînant la totalité des sites, ce qui est en conséquent bien plus grave).

 

Les bugs Prestashop sur le multilingue

Allez, dernier point qui va vous surprendre, autant sur Prestashop 1.6 que 1.7 (et probablement aussi les versions précédentes).

Cas de figure : vous envisagez de traduire votre site en anglais. Vous installez donc la langue en-gb (Royaume-Uni) mais finalement, au vu du travail à réaliser, vous faites marche arrière après avoir traduit la moitié de votre catalogue (ou peu s’en faut).

Quelques temps plus tard, vous revenez sur votre idée, cette fois-ci vous êtes prêt.

Puis vous vous désistez, pour une raison ou une autre. Vous faites ce genre d’opérations disons… Dix fois. Cela paraît beaucoup, mais détrompez-vous, le record homologué en ce qui me concerne est une boutique qui a installé plus de dix-neuf fois des langues. A chaque installation d’une langue, Prestashop l’ajoute sans se souvenir qu’elle a déjà été installée. Il vous dira sur suppression que vous perdrez tout, mais c’est totalement faux.

Prestashop les conserve toutes, sans exception, sans que vous puissiez les visualiser dans votre back-office.

Seul la langue est supprimée, aucunement les traductions. Bonjour le poids des tables en database ! Je crois avoir connu des pachydermes moins lourds…

Donc, pour une à deux traductions, vous pouvez avoir jusqu’à vingt fois vos fiches produits en base de données ! Alors, besoin d’un serveur dédié, vraiment ? Ce souci a été détecté par notre module de référencement complet Ever SEO, qui relève en-dehors de toute considération Prestashop à la fois le multilingue et le multiboutique. Imaginez un peu dix langues, sur un multiboutique de dix boutiques… Chaque fiche produit est multipliée par 100 en base de données ? J’ai donc dû développé des boutons de suppression de chaque contenu inutilisé en database, nommé « correcteur de contenu multilingue inutilisé »… Ah bravo !

 

Pour finir

Le multilingue n’est pas une chose simple, ça n’est pas léger, pas à prendre en considération sans y avoir pleinement réfléchi. Chaque contenu se voit multiplié par deux, l’erreur est deux fois plus facile.

Désindexez le contenu mal ou pas traduit. Un multilingue coûte cher, encore plus s’il est pris à la légère.

 Imprimer