Comparaison des stratégies de localisation de Contentful

La localisation ne se limite pas à la simple traduction d'un texte dans une autre langue ; elle façonne l'expérience globale pour un marché spécifique. Dans Contentful, cette différence se reflète dans la manière dont vous structurez les types de contenu et les entrées.  

Contentful décrit quatre grands modèles ou approches de localisation – au niveau des champs, au niveau des entrées, au niveau des types de contenu et au niveau des espaces –, mais ne précise pas lequel choisir ni à quel moment passer de l'un à l'autre. Opter trop tôt pour un modèle inadapté peut enfermer vos équipes dans des flux de travail peu flexibles, entraîner des doublons de contenu et nécessiter des refontes coûteuses dès que vous ajoutez un troisième marché ou un deuxième canal.

Ce guide vous présente en détail chaque stratégie, le fonctionnement des paramètres régionaux et des solutions de repli dans l'API, ainsi que les compromis à prendre en compte pour votre modèle de publication. Nous vous montrerons également comment associer Contentful à un outil de traduction de sites web basé sur l'IA tel que Weglot vous permet de créer plus rapidement un site multilingue.

En synthèse

• Commencez par choisir votre stratégie Contentful : chacune correspond à un modèle de gouvernance et de publication différent.
  
• Décidez dès le début si vous souhaitez une séparation stricte des marchés ou un contenu partagé avec des solutions de secours ; modifier ce paramètre après avoir défini votre troisième locale implique généralement une nouvelle compilation.
  
• Considérez les chaînes de repli comme un choix conceptuel délibéré : elles déterminent quels marchés héritent du contenu des autres et à quel moment.
  
• Déterminez clairement où les traductions doivent être stockées : dans Contentful pour une réutilisation multicanal, ou au niveau du site web si votre priorité est de mettre en ligne rapidement un site multilingue.
  
• Un outil de traduction basé sur l'IA comme Weglot vous offre automatisation, référencement naturel (SEO) et une plus grande flexibilité en gérant tout le travail technique dans le cloud.

Comment Contentful organise le contenu multilingue

Dans Contentful, tout commence par les paramètres régionaux: chacun correspond à une paire langue-région, comme « en-US » ou « de-AT », et chaque espace dispose d'un paramètre régional par défaut que l'API de diffusion de contenu (CDA) renvoie lorsque vous n'en spécifiez pas. Les paramètres régionaux sont gérés au niveau de l'environnement, et vous pouvez en avoir jusqu'à 500 par environnement, sous réserve des conditions de votre forfait.

Vous gérez la localisation au niveau des champs au sein d'un type de contenu. Tout champ marqué avec « localized: true » stocke des valeurs distinctes pour chaque locale, tandis que les champs non localisés conservent une seule valeur commune à toutes les langues. Cette approche est idéale pour des éléments tels que les références produit, les identifiants ou les dates globales. Vous pouvez modifier et ajouter des locales via l'API de gestion de contenu, y compris des codes et des noms personnalisés ; vous n'êtes donc pas limité à une liste ISO stricte, à condition que chaque code soit unique.

Lorsque vous configurez une locale, l'option « Autoriser les champs vides pour cette locale » permet aux éditeurs de publier même si certains champs localisés ne contiennent pas encore de valeurs, ce qui s'avère pratique lorsque les différents marchés évoluent à des rythmes différents. Les valeurs manquantes peuvent alors être renseignées par défaut selon votre hiérarchie de locales personnalisée ; vous décidez ainsi si la locale « de-CH » doit hériter de « de-DE », de « en-US » ou de rien du tout.

Comparaison entre la localisation au niveau du champ, au niveau de l'entrée, au niveau du type de contenu et au niveau de l'espace

Contentful propose quatre stratégies principales pour l'architecture multilingue: la localisation au niveau des champs, au niveau des entrées, au niveau des types de contenu et au niveau des espaces. Chacune d'entre elles répond à un besoin différent en matière de gouvernance, d'autonomie de publication et de degré de séparation souhaité entre les marchés.

Voici une comparaison générale :

‍

La localisation au niveau des champs permet de regrouper toutes les langues dans une seule entrée. Les champs localisés stockent des valeurs distinctes pour chaque paramètre régional, tout en conservant la publication par paramètre régional, les solutions de secours et la gouvernance basée sur les rôles. Pour la plupart des équipes, c'est le meilleur point de départ, car cela permet de garder le modèle bien organisé tout en vous laissant publier par paramètre régional lorsque cela s'avère nécessaire.

La localisation de base utilise une entrée « globale » qui renvoie vers des entrées localisées distinctes. Cette approche convient lorsque les équipes régionales ont besoin de plus d'autonomie, d'un contenu légèrement différent ou de leurs propres processus de validation. Vous conservez le comportement de secours sur le champ de référence, mais vous ne bénéficiez pas d'autorisations strictement limitées à une locale, car les traducteurs modifient des entrées différentes plutôt que différentes locales d'une même entrée.

La localisation au niveau des types de contenu duplique les types de contenu pour chaque langue au sein d'un même espace, tandis que la localisation au niveau de l'espace duplique l'ensemble du modèle de contenu dans des espaces distincts pour chaque langue ou région.

Ces deux solutions vous offrent une séparation claire et une publication totalement indépendante, mais vous perdez les solutions de secours automatiques et devez vous charger en permanence de la synchronisation des schémas et du contenu. Nous ne les recommandons que dans le cadre d'une conformité stricte ou pour les marchés où le contenu juridique, produit ou de marque doit être totalement différent de celui de votre site principal.

«Weglot contourne tous ces compromis liés à la modélisation en traduisant l’interface utilisateur via un snippet JavaScript snippet ou côté serveur lorsque cela est pris en charge), ce qui vous permet de lancer rapidement un site Contentful multilingue sans avoir à repenser au préalable votre modèle de contenu. »

– Christophe Garcia, responsable du service d'assistance chez Weglot

{{quote-cta-banner}}

Configuration des chaînes de repli et le piège des valeurs vides

L'ajout d'une locale dans Contentful se fait en trois étapes : la créer, configurer les solutions de secours, puis l'activer sur les champs. Vous ajoutez la locale via l'API de gestion de contenu (ou l'application web), définissez son fallbackCode pour créer une chaîne telle que de-CH → de-AT → de-DE, puis marquez les champs souhaités avec localized: true afin qu'ils puissent stocker des valeurs par locale. Cette chaîne définit la manière dont le CDA remonte vers une locale parente lorsqu'aucune valeur n'est définie.

Ce qui est subtil, c'est la manière dont Contentful détermine qu'une valeur est manquante. Le CDA traite trois états de champ différemment :

• Absent : aucune valeur n'est définie pour cette locale ; le CDA suit donc la chaîne de remplacement configurée.
  
• Null (défini via CMA) : le CDA renvoie la valeur null pour cette configuration régionale et n'essaie pas d'utiliser la chaîne de secours.
  
• Chaîne vide "" (définie via CMA) : le CDA renvoie "" pour cette locale et n'essaie pas d'utiliser la chaîne de secours.

Vous ne pouvez créer ces états « null » ou « » que par programmation via le CMA – l'application web empêche les éditeurs de les enregistrer –, ce qui explique pourquoi ce bug se cache souvent dans les scripts de migration et les intégrations personnalisées.

La case à cocher « Autoriser les champs obligatoires à rester vides pour cette locale » concerne la validation. Elle permet aux éditeurs de publier des entrées dans lesquelles certains champs localisés n'ont effectivement pas encore de valeur, mais le CDA continuera d'appliquer les mêmes règles de repli lorsqu'il rencontrera ces locales non définies au moment de la lecture.

Publication indépendante des paramètres régionaux et gestion des droits d'accès des traducteurs

Pour cibler une langue spécifique dans votre interface utilisateur, vous devez utiliser le paramètre de requête « locale » avec l'API de diffusion de contenu.

Exemple : locale=de-AT renvoie les champs en allemand d'Autriche avec la chaîne de repli que vous avez configurée, tandis que locale=* renvoie toutes les variantes localisées de chaque champ dans un seul flux de données.

En arrière-plan, l'API Sync fonctionne toujours comme le mode générique et inclut toutes les paramètres régionales, quelle que soit celle que vous demandez ; les systèmes en aval doivent donc prendre en charge l'ensemble complet des paramètres de localisation.

La publication par locale est une option activable au niveau de l'environnement, disponible uniquement sur certaines formules payantes, qui permet aux éditeurs de publier ou de retirer de la publication une ou plusieurs locales d'une entrée de manière indépendante. Elle fonctionne pour la publication manuelle dans l'éditeur d'entrées, mais la publication programmée et les mises à jour s'appliquent toujours à l'ensemble de l'entrée.

Grâce à la localisation des flux de travail, les étapes et les tâches peuvent désormais cibler des paramètres régionaux spécifiques. Ainsi, lorsque la publication par paramètre régional est activée, un blocage au niveau du paramètre régional « Français » ne vous empêche plus de publier séparément le paramètre régional « Anglais ».

Les rôles des traducteurs peuvent être limités par locale pour la localisation au niveau des champs, mais avec la localisation au niveau des entrées, il faut souvent recourir à des solutions de contournement concernant les autorisations d'accès au contenu, car les traducteurs modifient techniquement des entrées différentes plutôt que des locales différentes d'une même entrée.

La publication par langue ne modifie pas le fonctionnement des API, mais détermine le contenu pouvant être diffusé. Une fois cette fonctionnalité activée, vous pouvez voir l'état (brouillon, publié, modifié) par langue dans l'interface utilisateur, mais les API CDA et Sync continueront de fournir les versions localisées actuellement publiées pour les langues que vous demandez.

Comparatif des outils de traduction pour Contentful

Contentful vous propose deux grandes options pour la traduction :

1. Conservez les traductions au sein de Contentful en connectant un outil qui synchronise le texte traduit vers vos champs localisés (par exemple, Lokalise, Crowdin, Phrase) et en utilisant les fonctionnalités de traduction et de localisation propres à Contentful pour gérer le flux de travail.
2. Conservez les traductions en dehors de Contentful en utilisant un outil de traduction de sites web tel que Weglot qui fonctionne sur le site rendu, stocke les traductions dans sa propre interface utilisateur cloud et ne nécessite aucune écriture dans votre modèle de contenu.

Voici un comparatif des principales options :

‍

En résumé :

• Lokalise, Crowdin et Phrase extraient le contenu de Contentful, le traduisent, puis réinjectent les traductions dans vos champs localisés via leurs applications. Contentful reste la source de référence, et votre interface utilisateur lit simplement les champs localisés comme d'habitude.
• Weglot et traduit le site généré (HTML) et stocke les traductions dans le cloud, et non dans les champs Contentful. Il met ensuite à disposition les versions traduites via des URL spécifiques à chaque langue, avec une gestion automatique du référencement.

Comme Contentful ne stocke que la langue source, Weglot des lancements plus rapides, allège la charge pesant sur votre modèle de contenu et simplifie la gestion globale.

{{ai-banner}}

Choisir la bonne approche de localisation pour votre équipe

Optez pour une stratégie Contentful adaptée au mode de fonctionnement réel de vos équipes. Privilégiez la localisation au niveau des champs pour le contenu principalement partagé. N'utilisez la localisation au niveau des entrées, des types de contenu ou même des espaces que lorsque les régions ont besoin d'une réelle liberté éditoriale, ou lorsque les exigences de conformité et les grandes différences entre les contenus régionaux rendent difficile la gestion d'un modèle partagé.

Une fois cela mis en place, il faut ensuite décider où stocker les traductions. Si Contentful sert de plateforme centrale pour les applications mobiles, les API et plusieurs interfaces utilisateur, vous pouvez conserver toutes les langues au sein de vos entrées.

Si vous avez principalement besoin d'un site web alimenté par Contentful et disponible en plusieurs langues, une couche de traduction côté client est généralement plus rapide et beaucoup plus légère sur le plan architectural. Weglot particulièrement bien Weglot cette approche, car il traduit votre site une fois rendu, crée des URL spécifiques à chaque langue et gère SEO multilingue modifier votre modèle de contenu existant.

Prêt à découvrir le résultat sur votre propre plateforme ? Commencez dès aujourd'hui un Weglot gratuit de 14 jours Weglot et lancez un site Contentful multilingue en quelques minutes.