# Traduire une marketplace WooCommerce : ce que les plugins ne prévoient pas

> Une marketplace à plusieurs vendeurs indépendants a révélé que les extensions multilingues classiques ne couvrent pas ce cas. Voici les angles morts rencontrés et les contournements adoptés.

- Auteur : Clément Hadrot
- Publié le : 2026-08-12
- Mis à jour le : 2026-08-12
- Catégorie : Multilingue
- URL : https://wpmoderne.dev.wordpress-developpement.fr/multilingue/traduire-marketplace-woocommerce-multi-vendeurs/

## L’essentiel

- Les vendeurs eux-mêmes publient du contenu que WPML ne traite pas comme un contenu du site
- Chaque vendeur ne devrait pas avoir à gérer la traduction de ses propres fiches
- La solution repose sur un flux de traduction automatique déclenché à la publication vendeur

Une plateforme de vente d'artisanat régional a ouvert sa marketplace WooCommerce, propulsée par une extension multi-vendeurs, à des acheteurs de quatre pays européens. Le problème est apparu presque immédiatement : les vendeurs, des artisans indépendants publiant eux-mêmes leurs fiches produit, ne rédigent leur contenu qu'en français, et seuls 15 % d'entre eux déclarent maîtriser une autre langue suffisamment pour traduire leurs propres fiches. Les extensions multilingues classiques, WPML comme Polylang, sont pensées pour un contenu géré par l'équipe éditoriale du site, pas pour un contenu produit en continu par des centaines de tiers externes sans compétence en gestion de traduction.

Cet article ne revient pas sur le cas du catalogue simple traité pour un autre projet la même année, mais sur les angles morts spécifiques rencontrés dans le contexte d'une marketplace multi-vendeurs, où le contenu échappe en grande partie au contrôle direct de l'équipe du site.

## Angle mort n° 1 : le vendeur ne voit pas l'interface de traduction

Le tableau de bord vendeur, fourni par l'extension multi-vendeurs, ne donne accès qu'à la gestion de ses propres fiches produit dans la langue par défaut du site. L'interface avancée de traduction de WPML, pensée pour des rôles éditoriaux internes (traducteur, relecteur), n'est tout simplement pas exposée dans ce tableau de bord vendeur, et il n'est ni souhaitable ni réaliste de former chaque artisan indépendant à une interface d'administration WordPress complète.

## Angle mort n° 2 : la mise à jour de stock ne doit pas attendre la traduction

> L'essentiel à retenir : Les vendeurs eux-mêmes publient du contenu que WPML ne traite pas comme un contenu du site ; Chaque vendeur ne devrait pas avoir à gérer la traduction de ses propres fiches ; La solution repose sur un flux de traduction automatique déclenché à la publication vendeur

Second problème, plus subtil : un vendeur qui met à jour le stock ou le prix de sa fiche produit ne doit surtout pas voir cette modification bloquée ou retardée par un processus de traduction en attente. Or, par défaut, certaines configurations de WPML proposent de marquer une traduction existante comme obsolète dès que la source change, ce qui aurait affiché un bandeau « traduction en cours de mise à jour » sur les versions anglaise, allemande et néerlandaise à chaque modification mineure de stock, créant une gêne disproportionnée par rapport à l'ampleur réelle du changement.

## La solution retenue : un flux de traduction automatique déclenché à la publication

Face à ces deux angles morts, la solution construite pour ce projet contourne complètement l'interface de traduction manuelle pour les fiches vendeurs. Un hook est déclenché à chaque publication ou modification significative d'une fiche produit par un vendeur, qui traduit automatiquement le titre et la description via l'API DeepL, sans jamais bloquer la publication ni exposer d'interface de traduction au vendeur :

```
add_action( 'woocommerce_new_product', 'traduire_fiche_vendeur_automatiquement' );
add_action( 'woocommerce_update_product', 'traduire_fiche_vendeur_automatiquement' );

function traduire_fiche_vendeur_automatiquement( $product_id ) {
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_schedule_single_event(
            time() + 60,
            'ldc_traduire_fiche_differee',
            array( $product_id )
        );
    }
}
```

Le traitement est différé d'une minute via `wp_schedule_single_event` plutôt qu'exécuté en synchrone, afin de ne jamais ralentir la réponse perçue par le vendeur au moment de la publication. La tâche planifiée traite ensuite la traduction en tâche de fond, gérée par le cron WordPress standard, avant de créer ou mettre à jour les versions traduites via l'API de traduction native de WPML :

```
add_action( 'ldc_traduire_fiche_differee', function ( $product_id ) {
    $titre       = get_the_title( $product_id );
    $description = get_post_field( 'post_content', $product_id );

    foreach ( array( 'en', 'de', 'nl' ) as $langue ) {
        $traduction_titre = $GLOBALS['client_deepl']->translateText( $titre, null, strtoupper( $langue ) );
        $traduction_desc  = $GLOBALS['client_deepl']->translateText( $description, null, strtoupper( $langue ) );

        // Création ou mise à jour de la traduction via l'API WPML
        do_action( 'wpml_set_element_translation', $product_id, $langue, array(
            'post_title'   => $traduction_titre->text,
            'post_content' => $traduction_desc->text,
        ) );
    }
}, 10, 1 );
```

## Angle mort n° 3 : signaler au vendeur que sa fiche est traduite, sans lui donner de contrôle dessus

Un troisième problème s'est posé une fois le flux automatique en place : plusieurs vendeurs, en visitant le site depuis un VPN ou après un changement de langue de leur navigateur, sont tombés par hasard sur leur propre fiche traduite automatiquement, et ont mal interprété une formulation maladroite de traduction comme une erreur du site. Une simple mention discrète, ajoutée sur la fiche traduite (« Description traduite automatiquement à partir du français »), a suffi à désamorcer ces remontées, en fixant une attente réaliste côté acheteur international plutôt que de laisser croire à une traduction professionnelle irréprochable.

## Ce qui reste un vrai compromis assumé

- La qualité de traduction des fiches vendeurs reste strictement celle d'une traduction automatique brute, sans relecture humaine possible à cette échelle et à ce rythme de publication ;
- Les vendeurs les plus actifs, identifiés via un rapport de ventes mensuel, se voient proposer, en option payante par la plateforme, une relecture humaine ponctuelle de leurs fiches les plus vendues ;
- Aucun mécanisme ne permet à ce stade à un vendeur de corriger lui-même une traduction automatique qu'il jugerait mauvaise, ce qui reste une limite assumée du système en l'état actuel du projet.

> Sur une marketplace multi-vendeurs, la traduction ne peut pas reposer sur un processus éditorial classique : elle doit devenir un service invisible rendu au vendeur, jamais une tâche supplémentaire qu'on lui demande d'accomplir.

## En résumé

Les extensions multilingues classiques, pensées pour un contenu maîtrisé par une équipe éditoriale interne, ne couvrent tout simplement pas le cas d'un contenu produit en continu par des tiers externes sans compétence linguistique ni formation à l'outil. La solution qui a fonctionné ici n'est pas une configuration plus poussée de WPML, mais un flux automatisé construit par-dessus, invisible pour le vendeur, avec un compromis de qualité assumé et documenté auprès du client.