Traductions PrestaShop et vente à l'international

Ce que nous ferions

Nous partirions de la boutique existante : version de PrestaShop, thème, modules, intégrations, données du catalogue, marchés visés et personnes qui entretiendront les traductions et les prix. Conservez les sélecteurs natifs de langue et de devise qui fonctionnent, sauf si un besoin testé exige autre chose. Convenez des langues, devises et destinations de livraison prises en charge avant de modifier les réglages de localisation.

Effectuez les changements de configuration sur une copie de préproduction protégée avec les mêmes modules concernés et le même thème. Isolez les e-mails clients, les paiements réels et les exports logistiques, puis répétez le parcours complet avec des traductions relues et des données représentatives. Conservez les anciens réglages et les exports de traduction, convenez d’un créneau de bascule et consignez la procédure de retour arrière. Transférez les changements validés à la boutique de production actuelle ; remplacer sa base par une ancienne copie de préproduction pourrait faire perdre les commandes reçues entre-temps.

Pour une liste convenue de tâches de configuration variées, le PrestaShop Full-Day Store Setup Service peut couvrir les travaux prioritaires ; la production des traductions et les vérifications fiscales ou juridiques par pays restent des tâches distinctes.

Choisir la configuration adaptée à vos marchés

Proposer plusieurs devises ne nécessite pas à lui seul le multiboutique. Si les marchés exigent des configurations opérationnelles distinctes, étudiez le multiboutique et confirmez les données qui restent partagées.

Évaluez les conséquences opérationnelles avec le guide du multiboutique avant de choisir des boutiques séparées.

Ajouter une langue et auditer le contenu copié

Sur PrestaShop moderne, utilisez International > Localisation pour examiner les imports de localisation et l’onglet Langues. Vérifiez les éléments sélectionnés avant d’appliquer un pack pays : taxes, états, devises et unités sont des changements distincts. Importez uniquement ce que vous souhaitez modifier.

Ajouter une langue ne traduit pas votre catalogue. Dans PrestaShop 1.7.8 et 9, la création d'une langue remplit les lignes _lang manquantes à partir de la langue par défaut de chaque boutique. Vous pouvez donc voir du contenu anglais renseigné dans une langue allemande nouvellement ajoutée. Le texte copié constitue un travail de traduction à effectuer, pas une preuve que la version allemande est prête.

1. Installez la langue ou le pack approprié. Gardez la langue destinée aux clients désactivée pendant sa préparation.
2. Examinez le code ISO, language_code, la locale et les champs de format de date. Leurs rôles diffèrent. Le formatage moderne des nombres et devises utilise les règles de la locale ; un champ de format de date ne définit pas les séparateurs décimaux.
3. Vérifiez les réglages d'écriture de droite à gauche et la mise en page réelle du thème et des modules, le cas échéant. Un indicateur RTL ne valide pas à lui seul chaque composant.
4. Associez la langue aux boutiques prévues en multiboutique.
5. Inventoriez le contenu copié ou non traduit et remplacez-le par des traductions relues. Conservez les champs obligatoires au lieu de les laisser délibérément vides.

PrestaShop 1.6 utilise les anciens menus Localisation et mécanismes de traduction. N'y appliquez pas telles quelles les instructions modernes relatives à CLDR, aux domaines Symfony ou aux modules de sélection. Pour les versions actuelles, comparez votre environnement au tableau officiel de compatibilité.

La langue du back-office de vos employés est un réglage de profil distinct. Activer l'allemand pour les clients n'oblige pas l'équipe de l'entrepôt à travailler en allemand.

Traduire le catalogue, les politiques, l'interface et les e-mails

Les éditeurs peuvent proposer un sélecteur de langue commun, notamment pour les produits, plutôt qu'un drapeau à côté de chaque champ. Confirmez la langue d'édition sélectionnée avant de modifier un texte.

Tenez un registre des traductions indiquant l’article ou la page, la langue, la boutique, le relecteur et le statut de publication. Incluez les liens de menu, les bannières et le contenu enregistré dans la configuration des modules, qu’un export du catalogue peut omettre. Convenez d’un glossaire pour les termes produit récurrents, puis consignez comment les changements du texte source seront transmis au traducteur après le lancement. Une traduction terminée peut devenir obsolète lorsqu’un import modifie les spécifications.

Préparez les informations de livraison, de retour, de confidentialité et les conditions, puis les principales catégories et les produits importants. Traduisez les attributs, spécifications techniques, tailles, matériaux et instructions aussi soigneusement que les textes commerciaux. Testez les messages de validation du passage de commande, les textes des modules de paiement et chaque module actif. Envoyez de vrais messages de test pour les événements de commande, de compte et d'expédition dans chaque langue ; vérifiez les textes longs, les liens, l'encodage et la mise en page mobile.

La traduction automatique peut servir de premier jet. Vérifiez l’exactitude, la terminologie, les mesures, le ton de la marque et le sens propre au marché avant publication. Les pages traduites automatiquement peuvent être indexées ; vérifiez l’exactitude et l’utilité du contenu publié. Privilégiez la relecture humaine lorsque des erreurs affectent l’achat, l’utilisation ou le sens contractuel.

Corriger les textes des modules ou de l'administration restés en anglais

1. Reproduisez la chaîne exacte, la page, la boutique et la langue. Vérifiez la langue de l'employé pour les textes de l'administration et celle du client pour les textes de la boutique.
2. Sélectionnez le bon module ou thème et la bonne locale dans International > Traductions. Une traduction destinée à un autre thème ou domaine ne s'applique pas nécessairement.
3. Recherchez le texte exact dans le code source et identifiez son appel de traduction. Les anciens appels Smarty tels que {l s='Text' mod='modulename'} diffèrent des appels modernes par domaine tels que {l s='Text' d='Modules.Modulename.Shop'}.
4. Pour les modules historiques, vérifiez modules/modulename/translations/xx.php et les surcharges de traduction des modules dans le thème actif. Le fichier propre au module n'est pas la seule source prise en charge.
5. Pour les domaines modernes, vérifiez les catalogues XLIFF et les surcharges en base de données. Exportez un catalogue fonctionnel pour conserver ses noms de fichiers de domaine et ses identifiants au lieu d'inventer manuellement des clés de traduction.
6. Pour le JavaScript codé en dur, examinez le mécanisme de traduction du module entre serveur et navigateur. Modifier un fichier de traduction PHP ne change pas un texte anglais quelconque dans un fichier JavaScript statique.
7. Videz les caches de traduction et Smarty concernés, puis retestez. Ne purgez un CDN que s'il met en cache la réponse HTTP obsolète. Les modèles Smarty compilés sont des fichiers côté serveur, pas des objets conservés par le CDN.

Des textes anglais dans un back-office par ailleurs français peuvent venir d'une traduction manquante, d'une mauvaise locale ou d'un mauvais domaine, d'un texte codé en dur, d'un problème de chargement de catalogue ou d'un défaut. Ne concluez pas systématiquement que « ce n'est pas un bug ». Une phrase absente de l'éditeur de traduction peut aussi présenter des problèmes d'extraction ou de chaîne dynamique.

Fournissez au développeur la phrase visible, l’URL de la page, la langue sélectionnée, la boutique actuelle et les étapes de reproduction. Demandez quel catalogue ou champ de contenu la fournit réellement et comment la correction résistera à la prochaine mise à jour du module. Une capture seule ne distingue pas une valeur de réglage non traduite d’une chaîne de template traduisible.

Les surcharges propres au thème peuvent primer sur les textes des modules. Sauvegardez ou exportez vos traductions avant les changements de thème ou mises à niveau, puis vérifiez-les après. Pour les noms de fichiers des domaines du thème enfant et leur recherche, consultez le chapitre sur les traductions du thème enfant.

Configurer la devise, la conversion et les prix locaux

La langue et la devise sont indépendantes. L'anglais avec le PLN et l'allemand avec le CHF sont des préférences client valides. Ajoutez les devises dans International > Localisation > Devises, avec le vrai code de devise et les associations aux boutiques appropriées. Le formatage des locales modernes fournit les formats de nombres et les symboles. Les formulaires de devises de PrestaShop 1.7.8 et 9 proposent un paramètre Décimales pour la précision.

Les taux sont des multiplicateurs relatifs à la devise par défaut. Avec l'EUR par défaut et un taux GBP de 0,85, une base de 100 devient 85 GBP avant les autres règles de prix. Le taux par défaut est 1. Vérifiez le sens de conversion avec un produit connu avant d'activer une devise.

Les prix de base des produits sont interprétés dans la devise par défaut de la boutique. Modifier celle-ci est une opération de migration : ne vous attendez pas à ce que le seul réglage de localisation recalcule les prix du catalogue. Planifiez sur un environnement de préproduction la conversion des prix des produits et déclinaisons, des réductions en montant, des tarifs de livraison, des autres valeurs monétaires enregistrées et des taux. Conservez les informations de devise des anciennes commandes.

Pour fixer volontairement un montant local, utilisez Prix > Prix spécifiques sur le produit, avec la devise cible et un prix fixe. Un prix fixe propre à une devise peut remplacer la conversion automatique pour les conditions correspondantes. Vérifiez la base fiscale, les déclinaisons, la quantité, les groupes, les pays, les dates et la priorité des règles. La précision décimale ne transforme pas 47,83 PLN en un prix choisi de 49,90 PLN.

Un prix fixe de 42 GBP au lieu d'un prix converti automatiquement de 41,73 GBP est un choix commercial. Il ne prouve pas un gain de conversion. Envisagez des imports ou un outil de tarification testé lorsque vous gérez de nombreux prix propres à des devises.

Maintenir les taux et tester les arrondis

L'écran Devises propose une action de mise à jour des taux. PrestaShop 9 propose également le point d'accès d'administration protégé cron_currency_rates.php, qui appelle l'outil de mise à jour des devises dans le contexte de chaque boutique. Suivez les instructions officielles d'actualisation des taux pour construire l'URL de votre installation, gardez sa clé confidentielle et planifiez son exécution avec le planificateur de votre serveur. Ne publiez pas de jeton ou de chemin d'administration supposé.

Surveillez la bonne exécution et les taux obtenus. Désignez un responsable et une fréquence de contrôle adaptés à votre risque commercial ; notez qui intervient lorsqu’une mise à jour échoue. Une requête HTTP réussie ne prouve pas à elle seule que toutes les devises ont changé. Vérifiez des valeurs plausibles non nulles, les devises prises en charge par le flux, la dernière exécution réussie et des prix de test convertis. Une correction manuelle d’un taux de change peut être écrasée au prochain rafraîchissement. L’outil natif de mise à jour des taux ne réécrit pas les prix fixes propres à une devise ; vérifiez séparément si les imports du catalogue ou les outils tarifaires les écrasent. Comparez à part les frais de traitement et les écarts de change au règlement.

La précision des devises, le mode d’arrondi global et le type d’arrondi global sont des réglages différents. Sur PrestaShop moderne, le mode et le type d’arrondi se trouvent sous Paramètres de la boutique > Paramètres généraux (clés de configuration PS_PRICE_ROUND_MODE et PS_ROUND_TYPE). Le type d’arrondi choisit un calcul par article, par ligne ou sur le total. Aucun choix ne garantit que toute somme de nombres affichés arrondis égale le montant final.

Exemple avec un arrondi à deux décimales : un prix unitaire HT de 0,335 avec 20 % de taxe donne 0,402 TTC. Trois unités TTC arrondies individuellement donnent 0,40 × 3 = 1,20. Arrondir la ligne TTC non arrondie donne 1,206, soit 1,21. Les résultats réels de PrestaShop dépendent aussi de la précision de calcul configurée, des remises et de la répartition des taxes. Testez les quantités, les taux de taxes mixtes, les réductions et les remboursements sur de vraies factures.

Choisissez le comportement comptable adapté à votre activité et vérifiez sa conformité à vos exigences comptables. Ne considérez pas un mode d’arrondi comme une règle universelle des administrations fiscales. Examinez tout changement en préproduction avant qu’il n’affecte de nouvelles commandes.

Répéter l’ajout d’une devise

Supposons que votre boutique utilise l’EUR et que vous souhaitiez proposer la GBP sans changer la devise par défaut. Utilisez un produit connu et notez sa base fiscale, ses déclinaisons et ses remises actuelles pour ne pas confondre une différence de règle de prix avec une erreur de taux.

1. En préproduction, ajoutez la GBP dans le contexte de boutique prévu et vérifiez le sens du taux. Avec le taux d’exemple précédent de 0,85, un prix de base de 100 doit être converti en 85 GBP avant les autres règles.
2. Choisissez si ce produit suivra la conversion ou aura un prix fixe en GBP. Vérifiez le résultat avec le groupe client, la quantité, la déclinaison et l’adresse de livraison correspondants.
3. Changez de devise depuis la page produit, ajoutez au panier et poursuivez jusqu’au passage de commande. Comparez les produits, remises, frais de livraison, taxes et montant final plutôt que de vérifier uniquement le symbole d’en-tête.
4. Utilisez la procédure de test prise en charge par le prestataire de paiement, puis vérifiez que la commande, la facture et l’enregistrement du prestataire indiquent les mêmes montant et devise. Si l’option de paiement disparaît, examinez les restrictions de devise et les conditions du prestataire avant de changer les prix.
5. Testez un remboursement pris en charge et vérifiez son montant et sa devise dans la boutique et chez le prestataire. Confirmez séparément avec celui-ci les modalités de règlement bancaire et de conversion.
6. Lancez la mise à jour des taux et répétez les contrôles de prix. Confirmez quels produits doivent suivre le taux, quels prix fixes doivent rester inchangés et si le prochain import du catalogue préserve les règles prévues.

Conservez les résultats attendus avec la liste de contrôle de mise en production. Vous pourrez ainsi vérifier un changement de taux, une mise à jour de module ou un import avec le même panier, sans vous fier à votre mémoire.

Rendre les choix de langue et de devise utilisables

Les boutiques modernes utilisent souvent ps_languageselector et ps_currencyselector. Vérifiez leurs versions installées, leur activation, leurs associations à la boutique actuelle et leur emplacement dans le thème. Classic utilise souvent displayNav2 ; un autre thème peut utiliser un autre hook ou emplacement de widget. PrestaShop 1.6 utilisait blocklanguages et blockcurrencies avec ses anciens hooks de thème.

Si un sélecteur est absent, confirmez que plusieurs choix sont actifs dans la boutique actuelle, puis vérifiez Apparence > Positions, le rendu du modèle et le CSS. Ne supposez pas que la solution consiste à réécrire le thème.

Gardez les sélecteurs repérables sur les pages produit, catégorie, panier et les autres pages d’entrée, comme sur l’accueil. Sur mobile, affichez la langue et la devise actuelles dans une commande d’en-tête reconnaissable avant l’ouverture d’un menu. Utilisez les noms des langues dans leur propre langue, comme Deutsch ou Français. Les drapeaux représentent des pays et peuvent donc être ambigus. Des commandes purement textuelles peuvent être pleinement accessibles ; les commandes en image nécessitent un nom accessible. Quand le texte nomme déjà la langue, le drapeau peut être décoratif. Vérifiez l’utilisation au clavier, le focus et les cibles tactiles mobiles.

Affichez les codes de devise lorsque les symboles sont ambigus. Confirmez que la devise choisie persiste entre le produit, le panier, le passage de commande et le transfert vers le paiement. PrestaShop enregistre la devise de commande, mais l'intégration de paiement doit la prendre en charge ; le règlement bancaire et la conversion sont déterminés par le prestataire et le compte. Passez une commande de test, lisez la facture et comparez la transaction de la passerelle et le règlement.

Testez un sélecteur de pays combiné avant de l'activer. Il peut proposer une langue et une devise correspondantes, mais doit permettre des préférences mixtes. Gardez les choix explicites accessibles lorsque vous utilisez des suggestions basées sur la langue du navigateur ou la localisation. La détection IP peut être erronée pour les voyageurs et les VPN.

Garder le client sur la page correspondante

Ouvrez directement un produit traduit, changez de langue et confirmez que le sélecteur mène à l’URL traduite de ce produit plutôt qu’à l’accueil. Répétez sur une catégorie et une page hors produit, puis vérifiez que le changement de devise préserve la page et le panier actuels. Si une traduction ou une destination est indisponible, définissez un repli explicite plutôt que d’envoyer chaque changement vers une page sans rapport.

Si le sélecteur de langue natif ne répond pas à vos besoins de présentation, Language Switcher, Flag Selector propose un changement sur la même page avec noms de langues et drapeaux ; si vous souhaitez une autre commande de devise, Currency Selector utilise le mécanisme de devise de la boutique tout en conservant la page actuelle. Testez chaque remplacement dans votre thème et confirmez que seule la commande prévue est affichée.

Pour tester des préférences mixtes, choisissez l’allemand avec le CHF et un pays que vous livrez réellement. Changer de langue ne doit pas sélectionner silencieusement une autre devise ou adresse. Changer l’adresse de livraison doit appliquer les règles de livraison et de taxes configurées pour cette adresse, sans les déduire du texte allemand. Répétez en tant que client récurrent pour révéler une préférence enregistrée qui prendrait le pas sur le nouveau choix.

La configuration GeoIP de PrestaShop 9 attend GeoLite2-City.mmdb dans app/Resources/geoip/. Vérifiez les exigences de la version installée, l’accès à la base, sa licence et sa procédure de mise à jour avant d’activer la géolocalisation. Évitez les redirections forcées qui masquent les variantes linguistiques ou remplacent le choix du client.

Publier des URL et métadonnées utilisables pour chaque langue

Relisez les noms de produits et catégories, les descriptions, les métadonnées et les slugs localisés dans chaque langue. Les métadonnées CMS relèvent de cms_lang, tandis que meta_lang décrit les pages et contrôleurs enregistrés. Rédigez naturellement pour le marché visé et gardez les liens internes dans la langue prévue.

Utilisez des URL distinctes et stables pour les versions linguistiques. Le routage natif des URL simplifiées peut utiliser des préfixes de langue lorsque plusieurs langues sont actives. Modifier la structure des URL nécessite un plan de redirection testé. Les domaines propres à une langue ne se résument pas à un champ URL par langue dans une boutique ; ils nécessitent une configuration multiboutique ou un routage personnalisé adapté.

Un contenu principal entièrement traduit n’est pas du contenu dupliqué du seul fait de sa traduction. Hreflang aide les moteurs à identifier les versions linguistiques ou régionales équivalentes ; il ne traduit pas les pages et ne garantit pas de classement. Chaque page linguistique entièrement traduite et indexable doit désigner sa propre URL dans la même langue comme canonique ; ne faites pas pointer toutes les canoniques vers la langue source et vérifiez les correspondances hreflang réciproques entre les URL canoniques. Consultez le guide hreflang.

Si le thème ou le module SEO existant présente une lacune de correspondance confirmée, Hreflang Tags Manager fournit des correspondances linguistiques et un aperçu d’audit. Examinez le rendu avant et après activation afin que des générateurs concurrents ne publient pas des ensembles contradictoires.

Le contenu copié dans la langue source doit rester dans votre inventaire de traduction. N'affirmez pas qu'une pénalité SEO est inévitable et ne recommandez pas de laisser les champs obligatoires vides comme solution de remplacement. Publiez une langue lorsqu'elle offre un parcours d'achat cohérent et incluez les URL admissibles dans la solution de sitemap choisie.

Vérifiez les liens d’en-tête, de pied de page, CMS et promotionnels après un changement de langue ; des URL absolues copiées peuvent encore renvoyer les clients à la langue source. Ouvrez un échantillon d’anciennes URL enregistrées après tout changement de slug ou de préfixe et confirmez que chaque redirection mène à la page équivalente prévue sans boucle.

Effectuer les vérifications du lancement international

1. Vérifiez les traductions, le contenu de repli copié, les taux de change, les prix fixes et le formatage des nombres et dates dans la boutique prévue.
2. Examinez les unités de mesure, les conventions de tailles, les termes techniques et les images pour le public visé.
3. Vérifiez les services de paiement adaptés et les devises de commande prises en charge.
4. Testez la disponibilité de la livraison, les taxes de destination, les frais d'importation et les conditions annoncées de livraison et de retour. Obtenez des conseils fiscaux propres aux destinations si nécessaire, au lieu de déduire les taxes de la langue.
5. Testez une commande complète dans chaque combinaison de langue et de devise proposée, y compris la confirmation, l'e-mail d'expédition, la facture et les remboursements.
6. Vérifiez les mises en page mobile et RTL, les textes longs, les sélecteurs, les URL canoniques, hreflang et les entrées du sitemap.
7. Activez la langue terminée et surveillez les chaînes manquantes, les échecs du passage de commande et les retours des clients. Revérifiez les modules actifs après les installations ou mises à jour.

Questions à poser à votre développeur ou agence

• Quelles versions de boutique, thème, modules et intégrations ont été testées, et où sont les résultats pour chaque parcours proposé ?
• Quelles traductions, quels prix fixes et quelles URL linguistiques le prochain import ou la prochaine mise à jour peuvent-ils écraser, et qui les entretient ?
• Comment les changements validés seront-ils transférés en production sans perdre de nouvelles commandes, et quelles sont les étapes de retour arrière ?
• Qui vérifie les premières commandes réelles et mises à jour des taux, et qui traite une traduction manquante, un paiement échoué ou un écart de remboursement ?

Validez la bascule en production uniquement lorsque les parcours convenus passent les tests et que leurs responsables disposent des résultats. Consignez les changements de configuration et conservez des sauvegardes avant de les appliquer. Après activation, vérifiez les premières commandes concernées et les messages clients ; si un parcours échoue, suspendez-le pendant l’enquête et conservez ses enregistrements de commande et de paiement.

Questions des commerçants

Peut-on commencer par une gamme traduite plus restreinte ?

Uniquement si les clients peuvent terminer les parcours que vous proposez, y compris la navigation, les produits liés, les conditions et le passage de commande. Ne supposez pas qu’une langue activée masque les produits non traduits. Convenez du traitement des contenus inachevés dans votre boutique réelle avant publication.

Notre traducteur peut-il travailler avec la langue désactivée ?

Il peut préparer le contenu modifiable, mais prévoyez séparément la vérification en boutique. Activez la langue sur la copie de préproduction protégée pour tester la présentation et les commandes avant de la rendre disponible en production.

Un nouveau sélecteur rétablira-t-il un paiement absent en GBP ?

Vérifiez d’abord les restrictions de devise du module de paiement, la prise en charge par le prestataire et le compte marchand. Un sélecteur ne peut pas ajouter une capacité de paiement que l’intégration ne prend pas en charge.

Faut-il désactiver ou supprimer une devise abandonnée ?

Préférez la désactiver pour les nouveaux achats tout en préservant ses enregistrements historiques. Vérifiez les paniers existants, paiements en attente, remboursements et exports comptables avant de changer sa disponibilité.