Un CMS headless donne à l’ingénierie ce qu’elle veut. Une source de contenu alimente le site web, l’application et tous les autres canaux. Et les versions sont livrées via une API au lieu d’une file de publication.
Malheureusement, ce découplage rend la localisation plus difficile. Les traducteurs perdent le contexte au niveau de la page sur lequel ils comptent, les ingénieurs sont entraînés dans des cycles manuels d’exportation et d’importation, et les transferts de traduction qui prenaient autrefois une journée commencent à bloquer les sorties pendant une semaine.
Aucun de ces résultats n’est inévitable. La localisation des CMS sans interface graphique peut être résolue avec les bonnes décisions d’architecture.
Ce guide explique comment automatiser le pipeline de traduction via votre API CMS et restaurer les traducteurs de contexte perdus, afin que la localisation s’exécute d’elle-même après l’intégration initiale et cesse de transférer les développeurs, traducteurs et plannings de publication dans des transferts manuels.
Qu’est-ce qui rend la localisation des CMS sans interface différente
Le contenu et la présentation sont découplés, ce qui signifie qu’il n’y a souvent pas de page rendue unique à laquelle un traducteur peut se référer. Une chaîne qui se lit clairement sur la maquette de conception tombe de manière ambiguë dans un champ de contenu brut, et les hypothèses de longueur des caractères intégrées dans une mise en page ne s’accompagnent pas de la copie.
Les modèles de contenu sont réutilisés sur plusieurs canaux. Une chaîne CTA stockée une fois dans le CMS se rend à l’intérieur d’un héros, d’une carte et d’un modal à l’exécution, ce qui signifie qu’une entrée doit tenir dans trois contextes visuels que le traducteur ne voit jamais.
La publication est continue et pilotée par API plutôt que par lots, donc la traduction doit suivre le rythme de votre sortie au lieu de s’exécuter comme un projet séparé. Un train de sorties hebdomadaire sur 15 marchés ne correspond pas à un flux de travail manuel.
Là où la localisation headless casse sans la bonne configuration
L’exportation manuelle et l’importation sont le premier point de défaillance. Un ingénieur scripte un pull de contenu, envoie des fichiers pour traduction, puis renvoie les résultats par langue, par version. Chaque étape nécessite un travail d’ingénierie, et les scripts se cassent à chaque changement de modèle de contenu.
Le contexte manquant est la seconde. Les traducteurs fonctionnent à partir de courtes chaînes ou de champs composants, sans moyen de voir comment la copie sera affichée, ce qui provoque des erreurs qui n’apparaissent qu’après publication, lorsque la correction est un correctif rapide plutôt qu’une modification de chaînes.
Le décalage de synchronisation est le troisième. Les changements de contenu dans le CMS ne se propagent pas automatiquement au flux de traduction, donc la mise en scène et la production dérivent d’un marché à l’autre. Finalement, quelqu’un remarque que le site allemand est un lancement en retard.
La flexibilité qui rend le CMS sans interface graphique attrayant pour l’ingénierie est précisément ce qui casse un processus de traduction manuelle.
Construire un pipeline automatisé de localisation headless
La solution comporte quatre composantes. Les connecteurs basés sur une API synchronisent automatiquement le contenu, la capture visuelle du contexte donne aux traducteurs ce que l’architecture découplée supprime, les flux de travail de localisation continus redirigent le contenu dès sa publication, et l’automatisation des flux assigne chaque type de contenu au bon niveau de révision. Chacune est une décision d’intégration que vous prenez une seule fois.
Connecteurs basés sur API
Les connecteurs détectent le contenu nouveau ou modifié dans le CMS, l’envoient pour traduction, puis réécrivent le contenu fini sans étape d’exportation ou d’importation. Vous intègre une fois au niveau CMS, et chaque version suivante passe par le même pipeline au lieu de déclencher une nouvelle série de transferts de fichiers par marché.
Smartling maintient Connecteurs préassemblés pour plus de 50 plateformes, y compris des options CMS headless comme Contentful, Contentstack et Sanity.
Pour un CMS personnalisé ou un système non pris en charge, API REST de Smartling gère l’autorisation, la soumission et la livraison, avec des SDK pour Java, Python et PHP ainsi qu’une ligne de commande pour la gestion des fichiers. Les terminaux de fichiers, chaînes et jobs sont directement mappés sur les opérations qu’un pipeline manuel écrit à la main, ce qui permet de réduire le chemin de migration.
Lyft a réalisé la traduction via l’intégration Contentful de Smartling et a éliminé presque tout travail manuel du processus de localisation. C’est le schéma à suivre. Une fois que le connecteur maîtrise la synchronisation du contenu, ajouter un langage est un changement de configuration, pas un projet de réingénierie.
Capture du contexte visuel
Le contenu headless n’a pas de page naturelle à prévisualiser, c’est pourquoi la capture de contexte est plus importante ici que dans un CMS traditionnel. Les outils contextuels enregistrent comment un composant ou une chaîne se rend réellement, donc les traducteurs n’inférent pas le sens à partir d’un nom de champ.
La méthode de capture dépend de la façon dont votre interface se rend. Smartling prend en charge, une API de prévisualisation CMS, une bibliothèque de capture de contexte JavaScript, des téléchargements HTML statiques, des captures d’écran, une extension Chrome, ainsi que les surfaces d’aperçu capturées dans l’outil CAT où travaillent les traducteurs.
Considérez la capture comme faisant partie de l’intégration initiale. Câbler la bibliothèque de capture de contexte dans une compilation de staging est une tâche petite et ponctuelle, et cela évite aux traducteurs de devoir reconstruire des pages à partir des noms de champs sur chaque tâche par la suite.
Le contexte compte le plus pour les séries courtes. Les boutons, les étiquettes et les appels à l’action sont les plus sujets à l’erreur sans cette formule, car une chaîne de deux mots a des significations différentes selon l’endroit où elle est affichée.
Un aperçu rendu coupe aussi la boucle de révision, car les erreurs sont détectées lors de la traduction, lorsque la correction est un changement de chaîne plutôt qu’un retour en arrière.
Flux de travail de localisation continus
La localisation continue aroute automatiquement le contenu vers la traduction au fur et à mesure de sa publication ou de sa mise à jour, de sorte que la traduction s’exécute en arrière-plan en parallèle avec le développement plutôt que comme une porte avant le lancement.
À Smartling, Règles d’automatisation des emplois Regrouper le contenu en emplois, appliquer les langues cibles et autoriser le travail sans que personne ne reconstruise le processus à chaque version.
Coinbase déployait du contenu dans 21 langues en moins de deux mois en maintenant la traduction continue plutôt que de la regrouper, en faisant passer le programme via une intégration Contentful et des connecteurs de dépôt.
Coinbase considère également les glossaires centralisés comme essentiels, car la localisation continue ne fonctionne que lorsque la couche terminologique reste synchronisée avec le contenu.
Automatisation et routage des flux de travail
Tous les types de contenu ne méritent pas le même traitement. Automatisation des flux de travail Que ce soit vers le bon niveau de contenu ou de contenu modifié, que ce soit Traduction par l'IA, IA Human Translation (AIHT), ou revue humaine complète, basée sur le type de contenu et les mêmes règles de gouvernance applicables à l’ensemble de la plateforme.
Workflows dynamiques évaluent les propriétés des chaînes à l’exécution et se branchent automatiquement, de sorte que les chaînes à faible risque passent par un chemin d’IA automatisé tandis que le contenu à haute visibilité ou régulé mène à la validation humaine, sans triage manuel par chaîne.
Netskope, une entreprise de sécurité d’entreprise, a acheminé le contenu en masse via Le centre d'intelligence artificielle de Smartling et réduire le délai d’exécution d’environ 95 % tout en économisant des centaines de milliers de dollars en une seule année.
Le routage à cette précision est ce qui rend le contenu multicanal durable. Une description de produit, une bannière promotionnelle et une divulgation réglementaire entrent tous dans le même pipeline et sortent par le niveau de traduction approprié à chacun.
Localisation manuelle sans interface vs. pipeline automatisé
Les deux approches produisent du contenu traduit, mais le profil opérationnel diverge sur tous les axes importants pour l’ingénierie.
|
Facteur |
Localisation sans interface graphique manuelle |
Pipeline automatisé |
|---|---|---|
|
Synchronisation du contenu |
Exportation/importation manuelle par version |
Détection automatique via des connecteurs API |
|
Contexte pour les traducteurs |
Champs déconnectés, pas de référence visuelle |
Aperçus capturés de contenu rendu |
|
Évoluer vers de nouveaux marchés |
Nouveaux scripts et processus à chaque fois |
Le même pipeline s’étend aux nouveaux langages |
|
Frais généraux d’ingénierie |
En cours, lié à chaque sortie |
En phase de démarrage lors de l’intégration initiale |
|
Il est temps de publier |
Verrouillé par des transferts de traduction manuelle |
Fonctionne en parallèle avec le développement |
Que se passe-t-il sans pipeline automatisé
Les ingénieurs deviennent le goulot d’étranglement de la traduction. Le temps qui devrait être consacré au travail produit est utilisé pour déposer les exportations et importations, et plus l’équipe ajoute de marchés, pire est le ratio.
Le contenu dérive entre les marchés à mesure que les étapes de synchronisation manuelle sont manquées ou retardées. La mise en scène et la production cessent de correspondre, et la solution est une réconciliation manuelle entre tous les types de contenu concernés.
Les lancements retardent pendant que les équipes attendent des transferts de traduction qui auraient dû se dérouler en parallèle avec le développement. Le CMS sans interface était censé accélérer les versions, et maintenant chaque version est verrouillée par un cycle de traduction qui n’a rien à voir avec le code déployé.
Sans automatisation, l’avantage de vitesse d’un CMS headless disparaît dès que la localisation entre en jeu.
Localisez le contenu headless en fonction de la façon dont vous publiez déjà
La localisation du CMS sans interface graphique donne le même schéma que vous appliqueriez à n’importe quel problème de pipeline. Intégrez une fois au niveau du CMS, capturez le contexte à la source, et laissez les règles de routage gérer le reste.
Commencez par Documentation API de Smartling pour associer les fichiers, chaînes et terminaux de jobs à votre modèle de contenu, et voir jusqu’où le connecteur préconstruit de votre CMS vous mène avant d’écrire une ligne de code personnalisé.
FAQ sur la localisation du CMS headless