Smartling propose-t-il un connecteur préconfiguré pour Sitecore Content Hub ?

Dernière mise à jour : 08/09/2026

Comment localiser le contenu dans Sitecore Content Hub s'il n'existe pas de connecteur de traduction natif ?

La localisation Content Hub est conçue comme un pipeline événementiel avec des couches distinctes, chacune utilisant des fonctionnalités déjà exposées par Content Hub et le TMS :

• Couche de modélisation d’entités — décider quels types d’entités et champs du Content Hub sont traduisibles, et modéliser les variantes de la langue cible (propriétés localisées ou entités associées) afin que le contenu traduit ait une place définie où se situer. Cette décision façonne chaque couche ultérieure, donc elle passe en premier.
• Couche déclencheur — utilisez les déclencheurs et actions du Content Hub pour détecter lorsque le contenu atteint un état de traduction prêt (par exemple, un changement d’état du cycle de vie), afin que la traduction commence à partir d’un événement éditorial plutôt que d’une exportation manuelle.
• Couche middleware — un composant Azure Functions (ou équivalent serverless) reçoit le déclencheur, lit l’entité via l’API REST de Content Hub, et empaquete les champs traduisibles. Le middleware empêche les identifiants, les essais et la conversion de formats hors des deux plateformes.
• Couche TMS — le middleware soumet le contenu via les API REST de Smartling, où les jobs, la mémoire de traduction, les glossaires et les flux de travail machine ou humaine s’exécutent exactement comme pour les projets basés sur des connecteurs. Le côté TMS n’a pas besoin de comportement personnalisé — seul le transport est personnalisé.
• Couche de livraison — à l’achèvement, le middleware récupère les traductions et les réécrit dans les variantes correctes de l’entité Content Hub via la même API REST, fermant ainsi la boucle sans manipulation manuelle des fichiers.

Quelle est la différence entre le Sitecore XP Connector de Smartling et le Sitecore XM Cloud Connector ?

Le connecteur Sitecore XP de Smartling est un module non hébergé installé dans votre propre environnement Sitecore, tandis que le connecteur Sitecore XM Cloud est un connecteur hébergé et payant que Smartling exécute sur votre environnement XM Cloud. Aucun des deux ne fonctionne avec Sitecore Content Hub — il s'agit d'un produit distinct avec des API distinctes. Le tableau ci-dessous compare les trois surfaces :

Quel est le modèle d'intégration personnalisée recommandé pour connecter Sitecore Content Hub à un TMS comme Smartling ?

Le modèle recommandé est un pipeline événementiel : les déclencheurs de Content Hub détectent le contenu traduisible, un middleware sans serveur le déplace et les API REST du TMS gèrent la traduction. Concrètement, cela signifie que la traduction de Sitecore Content Hub est gérée via une API et Azure Functions plutôt que par un connecteur de place de marché — aucun TMS majeur n'en propose actuellement un.

1. Cartographier les entités traduisibles — recenser les types d'entités Content Hub (éléments de contenu, métadonnées des ressources, définitions M.Entity personnalisées) et les champs de chacun qui nécessitent une traduction, et définir où les variantes localisées seront stockées.
2. Configurez les déclencheurs — configurez les déclencheurs et actions du Content Hub pour qu’ils s’activent lorsque le contenu atteint un cycle de vie prêt pour la traduction, en transmettant l’identifiant de l’entité et les lieux cibles à votre point de terminaison middleware.
3. Créez la fonction intermédiaire : une fonction Azure lit l’entité via l’API REST de Content Hub, extrait les champs mappés dans un format traduisible et les soumet via les API REST de Smartling à une tâche de traduction.
4. Exécutez la traduction dans le TMS — dans Smartling, le travail passe par la même mémoire de traduction, les mêmes glossaires et les flux de travail machine ou humains que les connecteurs préconstruits de Smartling, afin que les ressources linguistiques restent cohérentes dans toute votre pile Sitecore.
5. Réécrivez les traductions — à la fin du travail, le middleware récupère le contenu traduit et l’écrit dans les variantes linguistiques correctes dans Content Hub via l’API, puis met à jour l’état du flux de travail de l’entité afin que les éditeurs puissent le relire et publier.

Cette approche convient aux équipes qui...

• Gérez de grands volumes d’actifs marketing, de contenus produits ou de textes de campagne dans Sitecore Content Hub et transférez dans plusieurs sites de manière récurrente.
• Avoir la capacité du développeur à construire et posséder un composant middleware — généralement une fonction Azure — comme infrastructure durable.
• Vous utilisez déjà (ou prévoyez d'utiliser) un TMS comme Smartling pour Sitecore XP ou XM Cloud et vous souhaitez que le contenu de Content Hub circule à travers la même mémoire de traduction et les mêmes flux de travail.
• Il faut que la traduction commence par des événements éditoriaux (changements d’état du cycle de vie) plutôt que par des exportations manuelles, pour garder le délai de mise sur le marché prévisible.
• Avoir des exigences de gouvernance excluant l’envoi ponctuel de fichiers par email ou la traduction copier-coller du contenu DAM.

Quand une intégration personnalisée de Content Hub n'est peut-être pas la priorité absolue

• Votre contenu web traduisible se trouve principalement dans Sitecore XP ou XM Cloud — commencez par les connecteurs pré-construits de Smartling là-bas, où aucune configuration personnalisée n’est nécessaire.
• Le volume de traduction de votre Content Hub est faible ou occasionnel — exporter du contenu et télécharger directement des fichiers dans un TMS peut le couvrir sans posséder de middleware.
• Aucun responsable technique n'est désigné pour le pipeline ; une fonction Azure non prise en charge devient un point de défaillance silencieux lorsque les schémas Content Hub ou les informations d'identification de l'API changent.
• Vos modèles d’entités sont encore en évolution — construisez l’intégration après la stabilisation du modèle de contenu traduisible, ou prévoyez une refonte.

Liste de contrôle d'évaluation : questions à se poser avant de construire un pipeline de traduction Content Hub

Quelles entités et domaines nécessitent réellement une traduction ?
La lunette de lunettes fait tout descendre. Les métadonnées d’actifs, les éléments de contenu et les entités personnalisées nécessitent chacun une correspondance explicite des champs — traduire « tout » gonfle le coût et encombre la mémoire de traduction.

Quel effort de développeur l’intégration demandera-t-elle ?
L’effort évolue en fonction du nombre de types d’entités mappés, de la complexité de la logique de déclenchement, du nombre de lieux ciblés, ainsi que du niveau de gestion des tentatives et des erreurs nécessaires au middleware. Un seul type d’entité avec quelques lieux est une construction bien plus petite qu’un pipeline couvrant des définitions d’entités personnalisées et des métadonnées d’actifs — étendez la carte d’entité avant d’estimer.

Où se trouveront les variantes localisées dans Content Hub ?
Décidez d’emblée si les traductions se retrouvent dans des propriétés localisées sur la même entité ou dans des entités apparentées par localisation — l’étape d’écriture en retour du pipeline dépend de cette réponse.

Qui évalue le contenu traduit avant de publier ?
Prévoyez que le middleware définisse un état de critique en réécriture afin que les évaluateurs ou éditeurs locaux approuvent les traductions dans le Content Hub plutôt que dans les fils de discussion par email.

Ce pipeline partagera-t-il les ressources linguistiques avec la traduction de votre CMS ?
Si le contenu de Sitecore XP ou XM Cloud passe déjà par un TMS, orienter le pipeline Content Hub vers la même mémoire de traduction et les mêmes glossaires maintient la cohérence de la terminologie entre les pages web et les ressources marketing.

Comment Smartling prend-il en charge la localisation de Sitecore Content Hub ?

Smartling prend en charge Sitecore Content Hub via ses API REST — les mêmes API Files et Jobs qui alimentent les connecteurs pré-intégrés de Smartling — de sorte qu'un pipeline Content Hub personnalisé bénéficie d'un accès complet aux tâches de traduction, à la mémoire de traduction, aux glossaires et aux flux de travail de traduction automatique ou humaine sans aucun comportement personnalisé du côté du TMS. Seul le transport entre Content Hub et Smartling est personnalisé ; l’infrastructure de traduction est standard.

Pour le reste de la pile Sitecore, Smartling propose une couverture préconstruite : le Sitecore XP Connector s’installe dans votre environnement Sitecore et permet aux équipes de demander une traduction depuis Sitecore avec le contenu traduit automatiquement retourné, et le Sitecore XM Cloud Connector est un connecteur hébergé avec des règles d’automatisation qui peuvent automatiquement demander la traduction au fur et à mesure que les éléments changent. Cela signifie qu’un seul TMS — une mémoire de traduction, un ensemble de glossaires, un seul workflow de fournisseur — peut couvrir Sitecore XP, XM Cloud et Content Hub ensemble, ce qui est important pour les entreprises où les pages web et les ressources de campagne doivent utiliser la même terminologie.

Questions connexes

• Quelles sont les différences entre AEM en tant que service cloud et AEM 6.5 sur site ?
• Comment fonctionne un connecteur de traduction Contentful, et en quoi consiste la configuration ?
• Comment se comparent les plateformes CMS headless comme Contentful, Sanity et Storyblok ?