Meilleures pratiques pour la conception de bases de données multilingues

Pour implémenter la prise en charge multilingue dans votre modèle de données, vous n'avez pas besoin de réinventer la roue. Cet article vous montrera les différentes façons de le faire et vous aidera à choisir celle qui vous convient le mieux.

Le concept de localisation est essentiel au développement d'une application logicielle, en particulier lorsque la portée de cette application est mondiale. La prise en charge de plusieurs langues est le principal aspect à prendre en compte; une conception de base de données qui prend en charge une application multilingue vous permet de diversifier vos marchés cibles et ainsi d'atteindre beaucoup plus de clients. En outre, une telle conception de base de données pourrait faire partie de votre stratégie à long terme de conception de systèmes prêts pour la localisation.

La clé pour intégrer le support multilingue dans votre application est de le faire d'une manière qui n'augmente pas considérablement les coûts de développement ou de maintenance. Comme la modélisation de base de données est une partie indissociable du processus de développement logiciel, vous devez réfléchir à la meilleure stratégie de conception de modèle de données pour donner à votre application un support multilingue.

Un modèle de données approprié doit vous permettre de modifier l'application ou d'ajouter de nouvelles fonctionnalités tout en conservant la prise en charge multilingue, sans effort ni coût supplémentaire. Il doit aussi vous permettre d'intégrer de nouvelles langues sans toucher à l'application; il vous suffit d'ajouter les données de traduction correspondantes à la base de données.

Mise en œuvre simple contre flexibilité et fonctionnalité

Il existe différentes approches pour créer une conception de base de données pour les applications multilingues. Chacun a ses avantages et désavantages. Ceux qui sont plus faciles à mettre en œuvre offrent moins de flexibilité et moins de fonctionnalités; ceux qui offrent plus de flexibilité et de fonctionnalité ont des implémentations plus complexes.

Mon conseil ici est de toujours opter pour ceux qui offrent plus de fonctionnalités et de flexibilité , même s'ils sont plus coûteux à mettre en œuvre. Parfois, nous commettons l'erreur de penser qu'une application est trop petite, qu'il ne vaut pas la peine d'implémenter des schémas complexes pour résoudre des problèmes tels que le support multilingue. Mais à terme, cette application va se développer et on regrettera d'avoir opté pour l'approche "rapide et sale" qui semblait plus simple et moins chère.

L'idéal pour implémenter des fonctionnalités accessoires dans une application - qu'il s'agisse de la prise en charge multilingue, de la journalisation des modifications, de l'authentification des utilisateurs ou autre chose - est que cette fonctionnalité ait son propre sous-schéma et sa logique encapsulée dans des composants réutilisables. De cette façon, la fonctionnalité accessoire et son sous-schéma peuvent être intégrés dans toute nouvelle application avec un minimum d'effort.

Un outil intelligent de conception de base de données et de modélisation des données comme Vertabelo est d'une grande aide pour la gestion efficace de vos schémas et sous-schémas. Consultez également ces conseils pour une meilleure conception de base de données et assurez-vous de les suivre tous. Avant de commencer à dessiner votre diagramme ER, je vous suggère de considérer cette série essentielle de conseils de modélisation de base de données.

Quelques solutions de conception de bases de données multilingues attrayantes (mais déconseillées)

Le plus simple - mais le moins recommandé

Commençons par le moyen le moins recommandé mais le plus simple d'implémenter une base de données d'applications multilingues. Il vous permet de résoudre rapidement le besoin de prendre en charge une application multilingue, mais cela vous posera des problèmes lorsque l'application se développera en fonctionnalités ou en couverture géographique.

Cette stratégie simple consiste à ajouter une colonne supplémentaire pour chaque colonne de texte à traduire et pour chaque langue dans laquelle les textes doivent être traduits.

Par exemple, dans les Movies tableau ci-dessous, il y a un OriginalTitle domaine. Une colonne de titre supplémentaire est ajoutée pour chaque langue à traduire :

L'application doit obtenir les données de description de la colonne correspondant à la langue sélectionnée par l'utilisateur. Lorsque vous avez besoin d'ajouter une nouvelle langue, vous devez ajouter une colonne supplémentaire au tableau pour contenir les textes traduits dans la nouvelle langue. Vous devez également adapter l'application pour reconnaître la langue et les colonnes ajoutées.

Cette solution ne nécessite pas de JOIN compliqués pour obtenir les textes traduits, ni d'enregistrements dupliqués - uniquement la réplication des colonnes de contenu de texte. Mais son applicabilité est limitée aux situations où seuls quelques tableaux doivent être traduits.

Par exemple, supposons que vous ayez un Products table et un Processes table. Chacun d'eux a un champ Description qui doit être traduit; semble assez facile, non? Mais si l'ensemble de l'application (y compris toutes ses options de menu, les messages d'erreur, etc.) doit être multilingue, cette solution est inapplicable.

Plus polyvalent, mais également déconseillé

Toujours dans l'idée de conserver les traductions dans le même tableau, une alternative à l'option précédente consiste à agrandir les champs de texte. Cela nous permettrait de stocker toutes les traductions dans le même champ, en les organisant dans une structure de données (par exemple, un document XML ou un objet JSON). Ci-dessous, nous avons un exemple :

Cette option ne nécessite pas de colonnes supplémentaires, mais ajoute de la complexité. Les requêtes de données doivent désormais pouvoir traiter et interpréter correctement la structure de données utilisée pour la prise en charge multilingue. Par exemple, si JSON ou XML est utilisé pour stocker les traductions, les requêtes SQL doivent utiliser une version SQL qui prend en charge le type de données choisi.

La commande SQL suivante utilise le serveur MS SQL OPENJSON() fonction pour utiliser le contenu des Translations champ en tant que table subordonnée :

SELECT
	m.MovieId,
	m.OriginalTitle,
	t.TranslatedTitle
FROM
	Movies AS m
	CROSS APPLY OPENJSON(m.Translations)
		WITH (
			language char(2) '$.language',
		TranslatedTitle varchar(100) '$.title’
		) AS t
WHERE t.language = 'fr';

Puisqu'il n'y a pas de fonctions ou d'opérateurs pour manipuler les données au format JSON ou XML en SQL standard, vous êtes obligé d'écrire vos requêtes pour un SGBDR particulier si vous souhaitez utiliser cette technique pour stocker les textes traduits. Par exemple, la requête précédente n'est pas prise en charge par MySQL. Si vous avez besoin de lire les données JSON dans les Movies table avec MySQL, vous écririez cette requête :

SELECT
	m.MovieId,
	m.OriginalTitle,
	JSON_EXTRACT(m.Translations, '$.title') AS TranslatedTitle
FROM Movies AS m
WHERE JSON_EXTRACT(m.Translations. '$.language') = 'fr';

Stocker le texte traduit dans différents enregistrements

Vous pouvez également choisir d'utiliser des enregistrements différents pour chaque langue. Il faut cependant se résigner à perdre la normalisation :les mêmes données se répètent dans plusieurs enregistrements, dont seule la traduction varie.

Avec cette option, vous pouvez créer des vues de chaque table qui ne renvoient que les lignes dans une langue donnée :

CREATE VIEW Movies_en AS
SELECT MovieId, Title
FROM Movies
WHERE LanguageId = 'en';

CREATE VIEW Movies_sp as
SELECT MovieId, Title
FROM Movies
WHERE LanguageId = 'sp';

Ensuite, pour interroger la table, vous pouvez utiliser une vue différente selon la langue de traduction cible. Mais la normalisation du modèle est perdue et la maintenance des tables est inutilement complexe.

Stocker le texte traduit dans des tableaux séparés

Une façon de stocker les textes traduits sans casser le modèle relationnel est d'avoir une table de détails pour chaque table contenant des textes à traduire. La table subordonnée contenant les traductions doit avoir les mêmes champs clés que la table mère, plus un champ indiquant la langue de traduction.

Une table subordonnée avec des traductions doit avoir les mêmes champs clés que la table mère, plus un champ indiquant la langue de traduction.

Cette option permet d'intégrer de nouvelles langues sans modifier la structure de la table. Il ne nécessite pas de générer des informations redondantes ou de casser la normalisation du modèle.

L'inconvénient de cette option est qu'elle nécessite la création d'une table subordonnée pour chaque table stockant des données textuelles nécessitant une traduction. Cependant, l'idée de stocker les traductions dans des tables liées nous rapproche de la manière la plus conseillée de concevoir une base de données multilingue.

La solution universelle :un sous-schéma de traduction

Pour qu'une application et sa base de données soient véritablement multilingues, tous les textes doivent avoir une traduction dans chaque langue prise en charge, et pas seulement les données textuelles d'une table particulière. Ceci est réalisé avec un sous-schéma de traduction où toutes les données avec un contenu textuel pouvant atteindre les yeux de l'utilisateur sont stockées.

Dans les applications Web destinées à être utilisées dans différentes langues, un sous-schéma de traduction est une nécessité, pas une option. Tout le reste conduira à des complexités qui rendront impossible la maintenance correcte de l'application.

La clé pour conserver les traductions dans un schéma séparé est de maintenir un catalogue indexé avec tous les textes à traduire, qu'il s'agisse de descriptions d'entités, de messages d'erreur ou d'options de menu. L'idée est qu'aucun texte pouvant atteindre les yeux de l'utilisateur n'est stocké dans une table en dehors de ce sous-schéma.

Une façon d'organiser le catalogue de traduction consiste à utiliser trois tables :

• Un tableau maître des langues.
• Un tableau de textes dans la langue d'origine.
• Un tableau des textes traduits.

Schéma pour un catalogue de traduction universel.

Dans la table maître des langues, nous insérons simplement un enregistrement pour chaque langue supportée par le modèle de données. Chacun a un identifiant et un nom :

La table de texte enregistre tous les textes nécessitant une traduction. Chaque enregistrement a un ID arbitraire, le texte d'origine et l'ID de la langue d'origine.

Dans le TextContent table, le texte d'origine et l'identifiant de la langue d'origine ne sont pas strictement nécessaires. Mais ils simplifient les requêtes qui ne nécessitent pas de traduction. Par exemple, lors d'analyses statistiques ou de requêtes de contrôle de gestion (qui ne sont généralement disponibles que pour les utilisateurs qui comprennent la langue d'origine), les requêtes peuvent être simplifiées en utilisant les textes par défaut (non traduits).

Les textes originaux sont également utiles pour ceux qui doivent remplir le tableau des textes traduits. La saisie des données de traduction peut être effectuée au moyen d'une mini-application affichant le texte original et les traductions dans toutes les langues disponibles. Il est également possible de générer des informations pour le sous-schéma de traduction via un processus automatique utilisant une API de traduction.

Lien avec le schéma principal

Dans le schéma principal de l'application, les colonnes contenant des valeurs textuelles à traduire sont remplacées par des identifiants pointant vers la table des textes traduits :

Le schéma principal est lié au schéma de traduction par le biais de tables contenant des textes à traduire.

Vous pouvez laisser le champ de texte d'origine dans certaines des tables de schéma principales pour faciliter les requêtes où la traduction n'est pas requise, même si cela génère des informations redondantes. Par exemple, nous pouvons conserver le ProductDescription dans le champ Products table pour faciliter les requêtes statistiques ou pour remplir les dimensions d'un entrepôt de données, en laissant de côté le sous-schéma de traduction lorsqu'il n'est pas nécessaire.

• Conception de base de données multilingue :faites-le une fois et faites-le correctement

Nous avons vu plusieurs alternatives pour créer une conception de base de données multilingue. Certains sont plus faciles et plus rapides à mettre en œuvre. La dernière solution est un peu plus complexe, mais elle vous donne beaucoup plus de flexibilité. Cela vous évitera également des ennuis lorsque viendra le temps de maintenir l'application et la base de données. Ainsi, à long terme, ce sera beaucoup moins cher.

Parfois, le chemin le plus court dans la conception de bases de données vous donne envie de croire que vous économiserez du temps et des efforts. Mais lorsque vous le choisissez, vous oubliez le fait que vous devrez probablement le descendre plusieurs fois. Si vous ignorez les meilleures pratiques de conception de bases de données multilingues, vous finirez probablement par refaire le même travail encore et encore.