Est-ce que Smartling a un connecteur préassemblé 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 du 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 Centre de Contenu sont traduisibles, et modéliser les variantes de la langue cible (propriétés localisées ou entités liées) afin que le contenu traduit ait une place définie où atterrir. 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 de statut du cycle de vie), afin que la traduction commence à partir d’un événement éditorial au lieu d’une exportation manuelle.
• Couche intermédiaire — un composant Azure Functions (ou un composant sans serveur équivalent) reçoit le déclencheur, lit l'entité via l'API REST de Content Hub et encapsule les champs traduisibles. L'intergiciel permet de séparer les informations d'identification, les tentatives de reconnexion et la conversion de format 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 machines ou humains fonctionnent 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 — à la fin, 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 un modèle d’intégration personnalisé 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 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 — à l’intérieur de Smartling, le travail passe par la même mémoire de traduction, les glossaires et les flux de travail machine ou humain utilisés par 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 appropriées dans Content Hub via l’API, puis met à jour l’état du flux de travail de l’entité pour que les éditeurs puissent le relire et publier.

Cette approche convient aux équipes qui...

• Gérez de grands volumes d’actifs marketing, de contenu produit ou de textes de campagne dans Sitecore Content Hub et transférez dans plusieurs sites de façon 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.
• Mettre en place des exigences de gouvernance qui interdisent l'envoi ponctuel de fichiers par courriel ou la traduction par copier-coller du contenu du système de gestion des ressources numériques.

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éassemblés de Smartling là-bas, où aucune construction personnalisée n’est nécessaire.
• Le volume de traduction de votre Content Hub est faible ou occasionnel ; exporter le contenu et télécharger les fichiers directement dans un TMS peut suffire sans avoir besoin d’un 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 que le modèle de contenu traduisible se sera stabilisé, ou planifiez une refonte.

Liste de vérification d’évaluation : questions à poser avant de créer un pipeline de traduction Content Hub

Quelles entités et domaines nécessitent réellement une traduction?
Scope détermine tout ce qui se passe en aval. 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éveloppement l'intégration nécessitera-t-elle ?
L’effort évolue avec le nombre de types d’entités cartographiés, la complexité de la logique de déclenchement, le nombre de lieux cibles, ainsi que la quantité de réessayages et de gestion des erreurs que le middleware nécessite. Un seul type d’entité avec quelques emplacements est une construction beaucoup plus petite qu’un pipeline couvrant des définitions d’entités personnalisées et des métadonnées d’actifs — élargissez 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 tombent 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 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 d’évaluation en version écrite afin que les évaluateurs ou éditeurs locaux approuvent les traductions dans le Centre de contenu plutôt que dans les fils de courriel.

Ce pipeline partagera-t-il les ressources linguistiques avec la traduction de votre CMS ?
Si le contenu de Sitecore XP ou XM Cloud transite déjà par un TMS, le fait de diriger le pipeline Content Hub vers la même mémoire de traduction et les mêmes glossaires permet d'assurer la cohérence de la terminologie sur 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 de fichiers et de jobs qui alimentent les connecteurs préconstruits de Smartling — donc un pipeline Content Hub personnalisé obtient un accès complet aux tâches de traduction, à la mémoire de traduction, aux glossaires et aux flux de travail de traduction machine ou humaine sans aucun comportement personnalisé du côté 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 offre une couverture préconçue : le Sitecore XP Connector s’installe dans votre environnement Sitecore et permet aux équipes de demander une traduction à l’intérieur de 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 flux de travail 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 les plateformes CMS headless comme Contentful, Sanity et Storyblok se comparent-elles?