Smartling nommé chef de file dans The Forrester Wave™ : services de localisation, 3e trimestre 2026.
Smartling nommé Leader dans The Forrester Wave™
Lire le rapport

Comment localiser une base de données, et en quoi cela diffère-t-il de l'emplacement 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 d'une 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 de caractères : elle ne comporte aucun marqueur intégré permettant de distinguer les colonnes traduisibles, les identifiants et les variables qui doivent être transmises sans modification. Ce fossé structurel engendre cinq problèmes récurrents.

  • Aucune séparation entre le texte traduisible et les données — un tableau products mélange une référence (SKU), un prix, un identifiant de catégorie et une description sur une seule ligne. Un fichier de ressources comme un fichier JSON ou un fichier .properties Un fichier sépare par conception les clés des chaînes de caractères ; une exportation de base de données ne le fait pas, donc tout effort de localisation commence par la détermination, colonne par colonne, de ce qui constitue le contenu et de ce qui constitue les données.
  • 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 marque-place, comme {0}.
  • Des décisions de schéma qui ne sont pas évolutives — l'ajout d'une colonne description_fr, description_de, description_ja par langue fonctionne pour trois langues et s'effondre à vingt. Une table de traduction distincte, indexée par l'ID d'entité et le code de langue, évolue de manière linéaire, mais son intégration a posteriori à un schéma en production constitue une migration, et non une configuration.
  • Le contenu qui change continuellement — un catalogue, un centre d’aide ou une table de contenu généré par les utilisateurs — se met à jour quotidiennement. Un export et importation unique manque tout ce qui est ajouté après l’exportation, donc le flux de travail doit détecter les changements et ne rediriger vers la traduction que les nouvelles lignes ou les lignes 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 un lieu sans migration.

  • Couche de schéma : une table de traduction à clé locale — stocker le texte traduisible dans une table clé par identifiant d’entité plus un code local à l’aide des balises IETF BCP 47 (en-US, fr-CA, zh-Hans), et garder la ligne de la langue source comme solution de secours. Mets le jeu de caractères en UTF-8 (utf8mb4 dans MySQL, UTF8 dans PostgreSQL) pour que les scripts CJK, les caractères accentués et les emojis survivent au stockage et à l’exportation. Cela transforme « ajouter du japonais » d’un changement de schéma en un insert.
  • Couche d’extraction : un transfert répétable, pas une exportation unique — décider comment les lignes traduisibles atteignent la plateforme de traduction. Les deux patrons sont une exportation planifiée vers un fichier structuré (JSON, CSV ou XLSX, tous acceptés par Smartling avec des directives au niveau du fichier allant jusqu’à 10 Mo par fichier) ou une poussée directe de l’API des chaînes sources. Dans tous les cas, le transfert devrait indexer chaque chaîne sur son identifiant d’entité et son emplacement afin que la valeur traduite puisse être écrite à la bonne ligne sans correspondance manuelle.
  • Couche de traduction : mémoire, terminologie et espaces réservés — acheminer 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 seule fois, appliquer un glossaire pour les noms des produits et les termes à ne pas traduire, et masquer les valeurs dynamiques comme des espaces réservés pour que les traducteurs voient Welcome, {First Name} au lieu de dix mille variantes personnalisées. C’est dans cette couche que 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 retourne la traduction sur demande, ou le texte source lorsqu'il n'existe pas encore, remplace complètement 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 devises, 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 € » sous forme de chaîne de caractères dans une base de données, le format d'une langue est figé pour 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, peu importe 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 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 grandes exportations de tableaux doivent être fragmentées par tableau, catégorie ou plage de dates modifiées plutôt que de les déposer 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 le support du contenu dynamique activé par défaut Tous les projets créés après août 2023 Les anciens projets GDN qui affichent le contenu de la base de données via des cadres 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 corde assortie Dans les zones à faible trafic, les règles relatives aux numéros de commande, aux noms et aux quantités doivent être révisées périodiquement.

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

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

  1. Inventez et classifiez 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 des catégories sont le contenu; les SKU, les slugs et les clés étrangères sont des identifiants; les prix, les décomptes et les dates sont des variables à formater au moment de l’affichage, 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 sur un calendrier ou à l’écriture — requête des lignes créées ou modifiées depuis la dernière exécution et sérialiser les lignes en JSON (ou CSV/XLSX) par identifiant d’entité, ou les publier sur une API de livraison au moment où elles sont écrites. Masquez les valeurs dynamiques comme des espaces réservés avant que le texte ne quitte la base de données.
  4. Traduisez avec mémoire, glossaire et révision — 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 acheminez le reste par traduction automatique, revue humaine ou les deux, selon la visibilité du contenu.
  5. Réécrire, vérifier et replier — 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 de 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.
  • Servir plus d’une poignée de sites, ou s’y attendre, et ne pas continuer à ajouter une chronique linguistique par marché.
  • Ajoutez ou modifiez le contenu quotidiennement, de sorte qu'une seule exportation serait désuè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 ou de déploiement.

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

  • L’exigence est la localisation des données au sens légal — garder des données personnelles ou réglementées à l’intérieur des frontières d’un pays. C’est une décision d’hébergement, de mécanisme de transfert et de gouvernance des fournisseurs, couverte par la souveraineté des données versus 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 sont des textes marketing web publics rendus côté serveur. Un proxy de traduction tel que le Global Delivery Network de Smartling le traduit en transit, y compris le contenu piloté par la base de données, sans toucher au schéma.

Quels sont les meilleurs outils pour la localisation de bases de données, et comment les évaluez-vous?

Les meilleurs outils pour la localisation de bases de données sont les plateformes de traduction capables d’absorber le contenu de la base de données de façon programmatique — sous forme d’exportations de fichiers structurés ou de chaînes postées sur une API — de dédupliquer le texte répété, de préserver les espaces réservés et de retourner les traductions liées à la ligne originale. Évaluez n’importe quel candidat, y compris Smartling, 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-elle recevoir des chaînes de caractères 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 retourne toute traduction disponible dans la même réponse ; ses API Files et chaînes 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 de la base de données est par nature répétitif. Un outil qui ingère une chaîne une fois, peu importe le nombre de lignes ou de charges utiles qu’elle contient, garde le volume de traduction lié à un texte unique, et non au nombre de lignes.

Comment gère-t-il les valeurs dynamiques dans le texte?
Cherchez 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} sur {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 retourne les segments déjà traduits sans frais frais supplémentaires; un glossaire impose les noms des produits et ne traduit pas les termes sur chaque table. Les deux comptent plus 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 rechange ?
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 retourner 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 la performance 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, traitée dans la section souveraineté des données vs résidence des données. La localisation de la base de données au sens de la traduction affecte les performances différemment : la lecture d’une table de traduction à chaque requête ajoute une jointure, de sorte que les applications à fort trafic mettent généralement les traductions en cache ou les récupèrent à partir d’un paquet de traduction hébergé sur un CDN plutôt que d’interroger la base de données à chaque page vue.

Comment Smartling localise-t-il le contenu de sa base de données ?

Smartling localise le contenu de la base de données à travers trois voies documentées, choisies selon la façon dont l’application expose ses données : une API de livraison à faible latence pour le contenu exporté à partir du code, des téléchargements de fichiers structurés pour les exportations planifiées, et un proxy de traduction pour les sites web pilotés par la base de données qui ne devraient pas être modifiés du tout.

  • API de livraison de traduction pour le contenu publié à partir de l’application — l’API Translation Delivery (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 retourne immédiatement toutes les traductions disponibles; lorsqu’aucune n’existe, elle retourne le texte source et ingère la chaîne pour la traduction. La documentation de Smartling décrit la plateforme agissant comme une base de données de traduction dans ce mode, stockant une copie de chaque chaîne peu importe le nombre de charges utiles qu’elle contient, de sorte qu’une description de produit répétée sur des milliers de lignes est traduite une seule fois. Certains clients utilisent l’API TD pour générer un paquet de traduction mis à jour déployé sur un CDN, donc les applications mobiles et web lisent 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, variantes, placeholders et 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 reviennent dans la même structure pour l’écriture, et les mêmes chaînes circulent dans la mémoire de traduction et le glossaire de Smartling que 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 cadres 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.

L’implication pratique pour une équipe choisissant parmi les trois : l’API TD convient aux applications qui possèdent déjà une passerelle API et souhaitent des traductions au moment de la demande; les exportations de fichiers correspondent aux catalogues batch et au contenu back-office; et le GDN convient aux sites web publics où le chemin le plus rapide est de laisser la base de données intacte. Les trois écrivent dans la même mémoire de traduction, donc un terme traduit pour le site web est réutilisé lorsque la même chaîne arrive 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 fournissant des traductions de la plus haute qualité, plus rapidement et à des coûts nettement inférieurs.

Prendre un rendez-vous