Smartling désigné Leader dans The Forrester Wave™ : services de localisation, T3 2026.
Smartling nommé Leader dans la Vague™ Forrester
Lire le rapport

Comment localiser une base de données, et en quoi cela diffère-t-il de la localisation des données ?

La localisation des bases de données est le processus de traduction et d'adaptation du contenu stocké dans les champs de la base de données (noms de produits, descriptions, libellés d'interface utilisateur, catégories, articles d'aide) afin qu'une seule application puisse fonctionner dans toutes les langues à partir du même modèle de données. La localisation des données est un concept différent, mais portant un nom similaire : une obligation légale de stocker, et parfois de traiter, certaines données à l’intérieur des frontières d’un pays spécifique. Les deux ne se recoupent que par leur vocabulaire. L'un est un problème de flux de travail de traduction résolu par la conception de schémas, l'extraction de contenu et une plateforme de traduction ; l'autre est une décision de conformité et d'hébergement qui détermine l'emplacement des serveurs, et non la langue des lignes.

Dernière mise à jour : 10 septembre 2026

Quels défis pourrais-je rencontrer lors de la localisation de données pour plusieurs pays ?

Le principal défi de la localisation du contenu de base de données pour plusieurs pays est qu’une ligne de base de données est une donnée, et non une chaîne : elle n’a pas de marqueur intégré indiquant quelles colonnes sont tradusibles, lesquelles sont des identifiants et lesquelles sont des variables qui doivent passer sans être modifiées. Ce fossé structurel engendre cinq problèmes récurrents.

  • Aucune séparation entre texte traduisible et données — un products tableau mélange un SKU, un prix, un identifiant de catégorie et une description dans une seule ligne. Un fichier de ressources tel qu'un fichier JSON ou un fichier .properties sépare les clés des chaînes par conception ; une exportation de base de données ne le fait pas, donc chaque effort de localisation commence par décider, colonne par colonne, ce qui est contenu et ce qui est donnée.
  • Des valeurs dynamiques intégrées dans le texte — des messages comme « Merci, votre numéro de commande est 56783 » ou « Vous avez 4 articles dans votre panier » — sont générés en combinant un modèle avec une valeur. Envoyée en traduction telle quelle, chaque variante est une nouvelle chaîne ; Les règles de correspondance de motifs de Smartling existent spécifiquement pour que le texte statique soit traduit une fois et que le nombre passe comme un espace réservé tel que {0}.
  • Décisions de schéma qui ne s’étendent pas — ajouter une description_fr, description_de, description_ja colonne par langue fonctionne pour trois lieux et s’effondre à vingt. Une table de traduction distincte indexée par l’identifiant de l’entité et le code local évolue linéairement, mais l’adaptation d’une table sur un schéma en direct est une migration, pas une configuration.
  • Contenu qui évolue en permanence — un catalogue, un centre d'aide ou un tableau de contenu généré par les utilisateurs sont mis à jour quotidiennement. Une exportation et une importation ponctuelles ne prennent pas en compte tout ce qui a été ajouté après l'exportation ; le flux de travail doit donc détecter les modifications et n'acheminer vers la traduction que les lignes nouvelles ou modifiées.
  • Types de contenu mixtes et absence de contexte visuel — une seule colonne de texte peut contenir du texte brut sur une ligne et du HTML sur la suivante, et les traducteurs travaillant à partir d'une exportation ne voient aucune partie de l'interface où apparaît la chaîne. Les deux problèmes concernent la qualité du code : balisage incorrect et traductions qui ne correspondent pas au bouton, à l’étiquette ou au champ pour lequel elles ont été écrites.

Un autre défi se cache derrière cette même expression. Si « localiser les données pour plusieurs pays » signifie conserver les données personnelles ou réglementées à l'intérieur des frontières de chaque pays — l'exigence de conformité en vertu de lois telles que la PIPL de la Chine ou la 242-FZ de la Russie — il s'agit de résidence des données, et non de traduction, et les exigences sont entièrement couvertes par la question de la souveraineté des données par rapport à la résidence des données par rapport à la localisation des données.

Comment puis-je localiser efficacement une base de données pour différentes régions ?

Une localisation efficace de la base de données divise le problème en cinq couches, chacune avec un propriétaire différent : schéma, extraction, traduction, livraison et formatage. Les équipes qui tentent de résoudre les cinq à l’intérieur de la base de données — stockant des dates formatées, codant en dur les colonnes du langage, traduisant à la main dans un tableur — se retrouvent avec un schéma qui ne peut pas ajouter de lieu sans migration.

  • Couche de schéma : une table de traduction indexée par les paramètres régionaux — stockez le texte traduisible dans une table indexée par l'ID de l'entité plus un code de paramètres régionaux utilisant les balises IETF BCP 47 (en-US, fr-CA, zh-Hans), et conservez la ligne de la langue source comme solution de repli. Configurez le jeu de caractères sur UTF-8 (utf8mb4 dans MySQL, UTF8 dans PostgreSQL) afin que les scripts CJK, les caractères accentués et les émojis soient conservés lors du stockage et de l'exportation. Cela transforme « ajouter du japonais » d'une modification de schéma en une insertion.
  • Couche d'extraction : un transfert reproductible, et non une exportation ponctuelle — décidez comment les lignes traduisibles parviennent à la plateforme de traduction. Les deux modèles sont une exportation programmée vers un fichier structuré (JSON, CSV ou XLSX, tous acceptés par Smartling avec des directives au niveau du fichier jusqu'à 10 Mo par fichier) ou un envoi direct des chaînes sources via l'API. Dans tous les cas, le transfert doit associer chaque chaîne à son identifiant d'entité et à ses paramètres régionaux afin que la valeur traduite puisse être réécrite sur la ligne correspondante sans correspondance manuelle.
  • Couche de traduction : mémoire, terminologie et placeholders — faire passer les chaînes de caractères via une mémoire de traduction afin qu’une description apparaissant dans 400 lignes de produit soit traduite une fois, appliquer un glossaire pour les noms de produits et les termes à ne pas traduire, et masquer les valeurs dynamiques comme des placeholders pour que les traducteurs voient Welcome, {First Name} au lieu de dix mille variantes personnalisées. Cette couche est celle où le coût est contrôlé ; la couche schéma détermine seulement si le coût peut être contrôlé du tout.
  • Couche de livraison : écriture en retour avec repli — les lignes traduites retournent à la table de traduction, et l'application lit la locale demandée avec une chaîne de repli (fr-CA → fr → en) pour tout ce qui n'a pas encore été traduit. Pour les applications qui ne peuvent pas attendre un cycle de traitement par lots, une API de diffusion à faible latence qui renvoie la traduction sur demande, ou le texte source lorsqu'il n'existe pas encore, remplace entièrement l'étape de réécriture.
  • Couche de mise en forme : règles de localisation au moment du rendu, jamais dans la ligne — les dates, les monnaies, les séparateurs de nombres et les formes plurielles sont des fonctions du lieu, pas du contenu, et appartiennent à la couche de présentation utilisant les données Unicode CLDR via une bibliothèque comme l’ICU. Stockage « 1 234,56 € » car une chaîne dans une base de données verrouille le format d’un lieu dans chaque lecteur de cette ligne.

Localisation de la base de données : chiffres clés de la documentation publique de Smartling

Figure Valeur Pourquoi c'est important pour le contenu des bases de données
Types de contenu acceptés par l'API de diffusion de traduction de Smartling HTML, JSON, XML, JavaScript, and mixed payloads (JSON+HTML, XML+HTML) Une exportation de base de données sérialisée au format JSON peut être envoyée directement, y compris les lignes dont les champs de texte contiennent du HTML.
Copies d'une chaîne de caractères stockées par l'API de distribution de traductions, quel que soit le nombre de charges utiles qui la contiennent. 1 Une description répétée sur des milliers de lignes est ingérée et traduite une seule fois, et chaque ligne reçoit la même traduction.
Taille maximale des fichiers JSON, CSV, XML, XLIFF et XLSX pour les chargements sur Smartling 10 Mo par fichier Les exportations de grandes tables doivent être fragmentées par tableau, catégorie ou plage de dates modifiées plutôt que de les faire en un seul fichier.
Il est temps qu'une traduction nouvellement publiée parvienne au fichier de traduction de Dynamic Content Support. Jusqu'à 20 minutes Définit les attentes quant à la rapidité de mise à jour d'une page web traduite, basée sur une base de données, sans déploiement.
Projets GDN avec prise en charge du contenu dynamique activée par défaut Tous les projets créés après août 2023 Les anciens projets GDN qui affichent du contenu de base de données via des frameworks JavaScript ont besoin d’un plan de migration pour bénéficier de la même couverture.
Période d'inactivité après laquelle une règle de correspondance de modèles est automatiquement désactivée 6 mois sans nouvelle ficelle assortie Dans les zones à faible trafic, les règles relatives aux numéros de commande, aux noms et aux quantités doivent être revues périodiquement.

À quoi ressemble, étape par étape, un flux de travail de localisation de base de données ?

Un flux de travail de localisation de base de données qui survit aux changements de contenu en cours fonctionne en boucle de cinq étapes plutôt qu’en une migration unique.

  1. Inventez et classez les colonnes — listez chaque tableau avec du texte destiné à l’utilisateur et marquez chaque colonne comme contenu, identifiant ou variable traduisible. Les descriptions de produits et les noms de catégories sont le contenu ; les SKU, slugs et clés étrangères sont des identifiants ; les prix, les comptes et les dates sont des variables à formater au moment du rendu, pas à traduire.
  2. Normalisez le schéma et l'encodage — déplacez les colonnes traduisibles dans une table de traduction indexée par les paramètres régionaux (ou vérifiez que la table existante utilise les codes régionaux BCP 47 et UTF-8), et enregistrez explicitement les paramètres régionaux source afin que la logique de repli ait un point de départ défini.
  3. Extraire les lignes modifiées selon une planification ou lors de l'écriture — interroger les lignes créées ou modifiées depuis la dernière exécution et les sérialiser au format JSON (ou CSV/XLSX) indexées par ID d'entité, ou les envoyer à une API de livraison au moment de leur écriture. Masquez les valeurs dynamiques comme espaces réservés avant que le texte ne quitte la base de données.
  4. Traduisez avec mémoire, glossaire et revue — faites passer d’abord les chaînes extraites dans la mémoire de traduction afin que le texte répété ne coûte rien de nouveau, appliquez le glossaire aux termes produit et marque, et alignez le reste par traduction automatique, revue humaine, ou les deux, selon la visibilité du contenu.
  5. Réécrire, vérifier et utiliser en dernier recours : insérer les valeurs traduites dans la table de traduction sous l’ID d’entité et la langue appropriés, exécuter une vérification automatisée que les espaces réservés et le balisage ont été conservés intacts, et servir la langue source pour toute langue encore en cours plutôt qu’un champ vide.

Un flux de travail dédié à la localisation des bases de données convient aux équipes qui...

  • Stockez les textes destinés aux utilisateurs (catalogues, listes, contenu d'aide, notifications) dans des tables de base de données plutôt que dans des fichiers de ressources ou un CMS doté de son propre connecteur de traduction.
  • Vous devez desservir plus d'une poignée de localités, ou du moins vous prévoyez de le faire, et vous ne pouvez pas continuer à ajouter une colonne de langue par marché.
  • Ajoutez ou modifiez le contenu quotidiennement, de sorte qu'une exportation unique serait obsolète avant même le retour des traductions.
  • Générez du texte à partir de modèles plus de variables (confirmations de commande, salutations personnalisées, comptages) et il faut des espaces réservés pour maintenir le volume de traduction stable.
  • Exécutez des applications web ou mobiles qui doivent afficher de nouvelles traductions sans cycle de compilation ni de déploiement.

Quand la localisation de la base de données n'est peut-être pas la priorité absolue

  • L'exigence concerne la localisation des données au sens juridique du terme — c'est-à-dire le maintien des données personnelles ou réglementées à l'intérieur des frontières d'un pays. Il s'agit d'une décision relative à l'hébergement, au mécanisme de transfert et à la gouvernance du fournisseur, traitée dans le cadre de la souveraineté des données par rapport à la résidence des données, et aucun flux de travail de traduction ne la modifie.
  • Le texte traduisible se trouve dans un CMS ou une plateforme de commerce doté d'un connecteur de traduction natif (Contentful, Salesforce Commerce Cloud et similaires). La traduction via le connecteur préserve le modèle de contenu propre à la plateforme ; l’exportation de la base de données sous-jacente le contourne.
  • Le texte correspond à l'interface utilisateur de l'application (boutons, menus, messages d'erreur) déjà externalisée au format JSON, .properties. iOS .strings, ou XML Android. La localisation des fichiers de ressources est la voie établie pour ce contenu, et son déplacement dans une base de données ajoute une couche sans apporter d'avantage.
  • Les données correspondent à des textes marketing web destinés au public et rendus côté serveur. Un proxy de traduction tel que le réseau de distribution mondial de Smartling le traduit en transit, y compris le contenu basé sur une base de données, sans toucher du tout au schéma.

Quels sont les meilleurs outils de localisation de bases de données, et comment les évaluer ?

Les meilleurs outils pour la localisation de bases de données sont les plateformes de traduction qui peuvent ingérer le contenu de la base de données par programmation — sous forme d'exportations de fichiers structurés ou de chaînes de caractères envoyées via une API — dédupliquer le texte répété, préserver les espaces réservés et renvoyer des traductions liées à la ligne d'origine. Évaluez tout candidat, Smartling inclus, en fonction de ces questions.

Peut-il accepter les formats d'exportation produits par la base de données ?
JSON, CSV et XLSX sont les cibles de sérialisation courantes pour les exportations de tables. Un outil devrait les analyser avec des directives qui marquent les colonnes clés, les colonnes sources et les champs contenant du HTML, plutôt que de traiter chaque cellule comme du texte brut.

Peut-il prendre des chaînes directement via une API, sans fichier ?
Les applications qui écrivent du contenu en continu bénéficient de la publication des chaînes de caractères au moment de l'écriture et de la lecture des traductions au moment de la requête. L'API de livraison de traductions de Smartling est un point de terminaison unique qui ingère le contenu source et renvoie toute traduction disponible dans la même réponse ; ses API Files et Strings couvrent le modèle de téléchargement asynchrone.

Stocke-t-il une seule copie d'une chaîne de caractères répétée ?
Le contenu des bases de données est répétitif par nature. Un outil qui ingère une chaîne de caractères une seule fois, quel que soit le nombre de lignes ou de charges utiles la contenant, maintient le volume de traduction lié au texte unique, et non au nombre de lignes.

Comment gère les valeurs dynamiques dans le texte ?
Recherchez des règles de soutien temporaire et de correspondance de motifs qui masquent les numéros d’ordre, les noms et les comptages afin que « Page 3 sur 10 » soit traduit une fois par « Page {0} out of {1}». Sans cela, chaque variante est présentée comme une nouvelle corde.

Est-ce qu’il applique automatiquement la mémoire de traduction et un glossaire ?
Une mémoire de traduction permet de récupérer gratuitement les segments précédemment traduits ; un glossaire assure la cohérence des noms de produits et des termes à ne pas traduire dans chaque tableau. Ces deux éléments sont plus importants pour les catalogues que pour les textes marketing, car le texte des catalogues se répète.

Est-il possible de réécrire les traductions en les indexant à la ligne source, avec une solution de repli ?
La traduction retournée doit porter l’ID de l’entité et la localisation à laquelle elle appartient, et l’outil ou l’intégration doit renvoyer le texte source lorsqu’aucune traduction n’existe encore, afin que l’application ne rende jamais un champ vide.

La localisation des données peut-elle améliorer les performances de mon application ?
Au sens de l’infrastructure — stocker les données dans une région proche de ses utilisateurs — oui, car des chemins réseau plus courts réduisent la latence ; c’est une décision d’hébergement et de résidence, couverte par la souveraineté des données versus la résidence des données. La localisation de la base de données au sens de la traduction affecte différemment les performances : une table de traduction lue à chaque requête ajoute une jointure, donc les applications à fort trafic mettent généralement en cache ou les récupèrent depuis un paquet de traduction hébergé sur CDN plutôt que d’accéder à la base de données par page vue.

Comment Smartling localise-t-elle le contenu des bases de données ?

Smartling localise le contenu de la base de données via trois voies documentées, choisies selon la manière dont l’application expose ses données : une API de livraison à faible latence pour le contenu exporté depuis le code, des téléchargements structurés de fichiers pour les exportations programmées, et un proxy de traduction pour les sites pilotés par la base de données qui ne doivent pas du tout être modifiés.

  • API de diffusion de traductions pour le contenu publié depuis l'application — L'API de diffusion de traductions (TD) de Smartling est un point de terminaison à haute disponibilité et non bloquant qui accepte le contenu source dans le corps de la requête (HTML, JSON, XML, JavaScript ou charges utiles mixtes) et renvoie immédiatement toutes les traductions disponibles ; lorsqu'aucune n'existe, elle renvoie le texte source et ingère la chaîne à traduire. La documentation de Smartling décrit la plateforme comme agissant dans ce mode comme une base de données de traduction, stockant une copie de chaque chaîne quel que soit le nombre de charges utiles la contenant, de sorte qu'une description de produit répétée sur des milliers de lignes n'est traduite qu'une seule fois. Certains clients utilisent l'API TD pour générer un package de traduction mis à jour et déployé sur un CDN, afin que les applications mobiles et web puissent lire les nouvelles traductions sans compilation ni déploiement. L'API TD est un produit payant, nécessite un projet GDN pour sa configuration et prend en charge les espaces de noms, les variantes, les espaces réservés et le contexte visuel.
  • API de fichiers et directives pour les exportations planifiées — pour les équipes qui exportent des tableaux selon un calendrier, Smartling accepte les fichiers JSON, CSV, XLSX et XML jusqu'à 10 Mo chacun, avec des directives au niveau du fichier qui identifient les colonnes clés, les colonnes sources, les instructions du traducteur et les champs qui doivent être analysés comme du HTML. Les fichiers traduits sont renvoyés dans la même structure pour la réécriture, et les mêmes chaînes de caractères transitent par la mémoire de traduction et le glossaire de Smartling comme tout autre contenu.
  • Réseau de distribution mondial et prise en charge du contenu dynamique pour les sites pilotés par base de données — pour les applications Web, le proxy de traduction du réseau de distribution mondial (GDN) de Smartling capture le contenu en transit vers le navigateur, y compris le contenu appelé depuis la base de données, et effectue des échanges de traductions sans aucune modification du schéma. La prise en charge du contenu dynamique, activée par défaut sur les projets GDN créés après août 2023, étend cela au texte rendu dans le navigateur par des frameworks JavaScript tels que React, et les nouvelles traductions atteignent la page environ 20 minutes après leur publication. Les règles de correspondance de modèles masquent les valeurs dynamiques — numéros de commande, noms, nombres d'articles — de sorte que « Merci, votre numéro de commande est 56783 » est stocké une seule fois sous la forme « Merci, votre numéro de commande est {0}», ce qui est le mécanisme qui empêche le texte généré par la base de données d'augmenter le volume de traduction.

Concrètement, pour une équipe qui doit choisir entre les trois options : l’API TD convient aux applications qui possèdent déjà une passerelle API et qui souhaitent des traductions à la demande ; les exportations de fichiers conviennent aux catalogues par lots et au contenu back-office ; et le GDN convient aux sites web publics où le moyen le plus rapide est de ne pas toucher à la base de données. Les trois processus écrivent dans la même mémoire de traduction, de sorte qu'un terme traduit pour le site web est réutilisé lorsque la même chaîne de caractères provient d'une exportation de base de données.

Questions connexes

Prêt à voir Smartling en action ?

Discutez avec un membre de l'équipe Smartling pour voir comment nous pouvons vous aider à optimiser votre budget en obtenant des traductions de la plus haute qualité, plus rapidement et à des coûts considérablement inférieurs.

Programmer un entretien