Comment concevoir un système prêt pour la localisation

À l'ère de la mondialisation, les entreprises, y compris les développeurs de logiciels, sont toujours intéressées à se développer sur de nouveaux marchés. Cela signifie souvent localiser leurs produits pour différents domaines. Dans cet article, nous expliquerons quelques approches de conception de votre modèle de données pour la localisation, en particulier pour la gestion de contenu dans plusieurs langues.

Qu'est-ce que la localisation ?

La localisation est le processus d'adaptation d'un produit à différents marchés. C'est un facteur important pour atteindre une part de marché maximale en termes de ventes de produits. Lorsque la localisation est effectuée correctement, les utilisateurs auront le sentiment que le produit a été conçu pour leur langue, leur culture et leurs besoins.

Dans les endroits où l'anglais n'est pas une première langue commune, des enquêtes ont prouvé que les langues locales sont de loin préférées pour un produit logiciel. Cet article de MediaPost contient quelques chiffres intéressants sur le besoin de langues autres que l'anglais en matière de ventes internationales.

Que pouvez-vous perdre si vous ne localisez pas ?

Prenons un exemple malheureux de non-localisation. Pour la commodité des clients, un portail de commerce électronique permettait aux clients de regrouper des achats individuels en un groupe de quatre. Malheureusement, la prononciation du mot "quatre" en japonais ressemble à leur mot pour "mort". Les Japonais évitent généralement tout ce qui est associé à ce nombre car il est considéré comme malchanceux. Inutile de dire que les ventes de ces produits ne se sont pas bien déroulées sur le marché japonais.

Ainsi, en réponse à la question ci-dessus, vous pourriez perdre beaucoup si vous ne planifiez pas soigneusement votre marché cible.

Traduction de contenu comme localisation

Lorsque nous pensons à la localisation, la traduction de contenu est souvent la toute première pensée qui nous vient à l'esprit. La deuxième réflexion est « Nous avons besoin d'un modèle de base de données robuste et efficace pour stocker le contenu traduit dans plusieurs langues ».

Supposons qu'on nous demande de concevoir un modèle de données pour une application de commerce électronique multilingue. Nous aurions besoin de stocker des champs de texte comme product_name et la description des produits en plusieurs langues. Nous aurions également besoin de stocker des champs de texte dans d'autres tables, telles que le customer tableau, dans toutes ces langues.

Pour comprendre comment concevoir notre modèle de données avec la traduction de contenu à l'esprit, nous examinerons différentes approches en utilisant ces deux tableaux. Chacune de ces approches a des avantages et des inconvénients. Les approches présentées ci-dessous peuvent être étendues à d'autres tables de votre modèle de données. Bien sûr, l'approche exacte que vous choisirez sera basée sur vos propres exigences.

Approche 1 – Ajout de colonnes de langue distinctes pour chaque champ prévu

C'est l'approche la plus simple en termes de développement. Il peut être implémenté en ajoutant une colonne de langue pour chaque champ.

Avantages

Il est très facile à mettre en œuvre.
Il n'y a aucune complexité dans l'écriture de SQL pour récupérer les données sous-jacentes dans n'importe quel langage. Supposons que je veuille écrire une requête pour récupérer les détails du produit et du client pour une commande particulière en français. Le code ressemblerait à ceci :
```
Sélectionnez p.product_name_FR, p.description_FR, p.price, c.name_FR, c.address_FR, c.contact_name from order_line o, product p, customer c Où o.product_id =p.id et o.customer_id =c .id Et id = ;
```

Inconvénients

Il n'y a pas d'évolutivité :chaque fois qu'une nouvelle langue est ajoutée, des dizaines de colonnes supplémentaires doivent être ajoutées dans les tableaux.
Cela peut prendre du temps, surtout si de nombreux champs doivent avoir plusieurs langues.
Les développeurs finissent par écrire la requête ci-dessous pour gérer toutes les langues existantes. Ainsi, tous les SQL de votre application doivent changer lorsqu'un nouveau langage est introduit. (Remarque : @in_language signifie la langue actuelle de l'application ; ce paramètre provient du front-end de l'application, tandis que le back-end récupère les enregistrements.)
```
SELECT CASE @in_language WHEN 'FR' THEN p.product_name_FR WHEN 'DE' THEN p.product_name_DE DEFAULT THEN p.product_name_EN, p.price, CASE @in_language WHEN 'FR' THEN c.name_FR WHEN 'DE' THEN c .name_DE DEFAULT THEN c.name_EN, c.contact_nameFROM order_line o, product p, customer c WHERE o.product_id =p.id AND o.customer_id =c.id AND id = ;
```

Approche 2 – Création d'un tableau séparé pour le texte traduit

Dans cette approche, une table séparée est utilisée pour stocker le texte traduit; dans l'exemple ci-dessous, nous avons appelé cette table translation . Il contient une colonne pour chaque langue. Les valeurs qui ont été traduites à partir des valeurs de champ dans toutes les langues applicables sont stockées sous forme d'enregistrements. Au lieu de stocker le texte traduit réel dans des tables sous-jacentes, nous stockons sa référence à la translation table. Cette implémentation nous permet de créer un référentiel commun de texte traduit sans apporter trop de modifications au modèle de données existant.

Avantages

C'est une bonne approche si la localisation doit être mise en œuvre sur un modèle de données existant.
Une seule colonne supplémentaire dans la translation table est le seul changement nécessaire lorsqu'une nouvelle langue est introduite.
Lorsque le texte d'origine est le même dans tous les tableaux, il n'y a pas de texte traduit redondant. Par exemple :supposons qu'un nom de client et un nom de produit soient identiques. Dans ce cas, un seul enregistrement sera inséré dans la table de traduction, et le même enregistrement est référencé à la fois dans le customer et product tableaux.

Inconvénients

Cela nécessite toujours une modification du modèle de données.
Il peut y avoir des valeurs NULL inutiles dans la table. Si 1 000 champs sont nécessaires pour une seule langue prise en charge, vous finissez par créer 1 000 enregistrements, et de nombreux NULL.

La complexité de l'écriture de SQL augmente à mesure que le nombre de jointures augmente. Et lorsqu'il y a beaucoup d'enregistrements dans la translation table, les temps de récupération sont plus lents.

Écrivons à nouveau un SQL pour l'énoncé du problème de gestion du langage :

SELECT CASE @in_language WHEN 'FR' THEN tp.text_FR WHEN 'DE' THEN tp.text_DE DEFAULT THEN p.product_name_EN, p.price, CASE @in_language WHEN 'FR' THEN tc.text_FR WHEN 'DE' THEN tc .text_DE DEFAULT THEN c.name_EN, c.contact_nameFROM order_line o, product p, customer c, translation tp, translation tc WHERE o.product_id =p.id AND o.customer_id =c.id AND p.name_translation_id =tp.id AND c.name_translation_id =tc.id AND id = ;

Une variante de l'approche de la table de traduction

Pour obtenir de meilleures performances lors de la récupération du texte traduit, nous pouvons diviser la translation tableau en plusieurs tableaux. Nous pouvons regrouper les enregistrements en fonction du domaine, c'est-à-dire une table pour customer , un autre pour product , etc.

Approche 3 – Un tableau de traduction avec des lignes pour chaque langue

Cette implémentation est assez similaire à la seconde approche, mais elle stocke les valeurs du texte traduit dans des lignes plutôt que dans des colonnes. Ici, la translation l'ID de table reste le même pour une valeur de champ dans n'importe quelle langue traduite. Une clé primaire composite {id , language_id } est stocké dans la table de traduction, et il stocke le même translation_id pour chaque champ contre plusieurs language_id .

Avantages

Cette mise en œuvre permet aux développeurs d'écrire assez facilement des SQL de récupération de données.
Il est également facile d'écrire OEM pour ce modèle.
Aucune modification du modèle de données n'est nécessaire lorsque vous ajoutez une nouvelle langue ; insérez simplement les enregistrements pour la nouvelle langue.
Il n'y a pas de consommation de mémoire inutile lorsqu'un ensemble de champs ne s'applique pas à une langue.

La complexité des SQL de récupération de données est réduite. Regardez l'exemple ci-dessous :

SELECT tp.text, p.price, tc.text, c.contact_nameFROM order_line o, product p, customer c, translation tp, translation tc, language l WHERE o.product_id =p.id AND o.customer_id =c .id AND p.name_translation_id =tp.id AND c.name_translation_id =tc.id AND tp.language_id =l.id AND tc.language_id =l.id AND l.name =@in_language AND id = ;

Inconvénients

Un nombre relativement élevé de jointures est nécessaire pour récupérer les données traduites.
A terme, un grand nombre d'enregistrements peuvent potentiellement être stockés dans la translation table. Puisqu'il n'y a qu'une seule table de traduction, tout le texte traduit y sera déversé. Lorsque vous avez des millions de champs à traduire et que votre application prend en charge un grand nombre de langues, interroger une table pour une traduction serait une activité chronophage. Cependant, vous pouvez diviser la table de traduction en fonction des langues ou des domaines, comme nous l'avons souligné à la fin de la deuxième approche.

Et si nous combinions les approches 2 et 3 ?

Plus précisément, nous combinerons la variante de l'Approche 2 - en divisant la translation table - avec l'idée d'utiliser des lignes dans une table. Nous pouvons facilement surmonter l'inconvénient d'avoir d'énormes enregistrements dans la translation table en créant plusieurs tables basées sur un domaine, comme nous l'avons fait dans la variante de l'approche 2. S'il existe un nombre considérable d'enregistrements dans la table de traduction basée sur le domaine, nous pourrions diviser davantage les tables en fonction de champs individuels.

Approche 4 – Créer des couches d'entités pour les champs traduits et les champs non traduits

Dans cette solution, les tables d'entités qui contiennent un ou plusieurs champs traduits sont divisées en deux couches :une pour les champs traduits et une autre pour les champs non traduits. De cette façon, nous créons des calques séparés pour chacun.

Avantages

Il n'est pas nécessaire de joindre des tables de traduction si seuls les champs non traduits sont concernés. Par conséquent, les champs non traduits obtiennent de meilleures performances.
Un nombre relativement inférieur de jointures est nécessaire pour récupérer les textes traduits.
C'est facile d'écrire OEM.
Les SQL pour récupérer le texte traduit sont simples.
Il s'agit d'une approche éprouvée pour l'intégration de plusieurs langues dans les entités.

Pour illustrer ce point, voici un exemple de requête qui récupérera le texte traduit :

SELECT pt.product_name, pt.description, p.priceFROM order_line o, product p, product_translation pt, language l WHERE o.product_id =p.id AND AND p.id =pt.product_non_trans_id AND pt.language_id =l. id AND l.name =@in_language AND id =;

Localisation – Aller au-delà de la traduction de contenu

La localisation ne consiste pas seulement à traduire le contenu de votre application dans une autre langue. Certains paramètres culturels et fonctionnels doivent également être pris en compte. Par exemple, une valeur de date est formatée en tant que « MM/JJ/AAAA » en Amérique du Nord, mais dans la plupart des pays d'Asie, elle est écrite sous la forme « JJ/MM/AAAA ».

Un autre exemple concerne l'affichage des noms sur l'en-tête de l'application. Aux États-Unis, appeler quelqu'un par son prénom est acceptable, voire préféré; dans cette culture, le prénom du client s'affiche sur le header dès que le client se connecte. Au Japon, cependant, les choses sont inversées :appeler quelqu'un par son prénom est impoli voire plutôt insultant. La localisation en tiendrait compte et éviterait l'utilisation de prénoms pour le public japonais de l'application.

Les paramètres de localisation peuvent devoir être stockés à l'arrière de l'application. C'est tout à fait le cas lorsque vous devez concevoir une logique de programme autour de la localisation. Nous pouvons probablement classer tous ces paramètres en catégories culturelles et fonctionnelles, et construire le modèle de données autour d'eux.

Encore une réflexion sur la localisation

La localisation est nécessaire lorsqu'une marque mondiale pénètre sur les marchés locaux. Pour localiser une application, regardez la situation dans son ensemble. La localisation est plus qu'une simple performance techniquement parfaite. C'est aussi avoir la maîtrise des cultures locales, des comportements, voire des modes de pensée et de vie.

Que peut-on faire d'autre pour rendre une application adaptable localement ? Faites-nous part de vos réflexions dans les commentaires.