Discussion :

[remy67]

Bonjour,

Je m'interroge actuellement sur la "meilleur" façon de gérer le multi langue dans un logiciel, et notamment dans la base de données.

Les solutions que je peux imaginer ne me semblent pas propres, or je ne me souviens pas avoir rencontré ce cas dans les livres.

Les solutions que j'ai en tête sont pour le moment :

- J'ai la solution d'avoir une base par langue, mais je n'aime pas cela, dans la mesure où cela fait des doublons.

- Avoir tout dans une langue, et traduire pour l'utilisateur, mais je ne vais pas convertir des saisies utilisateurs dans la langue de la base.

- Rajouter une référence locale à plus ou moins tous les champs de la base, avec des tables de traduction.

Vu que je ne pense pas être le premier avec cette interrogation, il existe certainement une solution de référence ?

Merci

[tatayo]

Bonjour,
Pour gérer cette problématique nous avons une table des langues dans la base, et chaque donnée qui doit être traduite est dans une table avec l'id de la langue.
Par exemple pour les désignations des articles, nous avons une table ART_ML avec comme colonne l'id de l'article, l'Id de la langue et la désignation. Ainsi on peut traduire la désignation dans autant de langues que nécessaire, sans rien dupliquer.

Tatayo.

[SQLpro]

Aujourd'hui le coup de la table des langue est très désuet par rapport à une approche XML par exemple. L'idée est d'avoir dans une colonne XML toutes les traductions pour les littéraux.

Après il faut faire des requêtes XQuery / XPath dans SQL pour retrouver la langue souhaitée

A +

[Michel.Priori]

L'approche XML est potentiellement plus longue pour faire des recherches du type :
- lister les traductions qui manquent en québécois
bien valider avec votre SGBD la bonne prise en charge du type XML et notamment l'indexation.

Si vous utilisez SQL server vous n'êtes pas dans le bon forum

Bon c'est vrai que dans le même temps c'est pas une requête hyper fréquente.

Le cas le plus fréquent est de retrouver le texte dans la langue voulue, et à défaut, dans la langue "de base".
Et dans ce cas le traitement XML est correct.

Attention toutefois à la mécanique de validation du flux XML, la mise à jour est parfois lourde.

[SQLpro]

Potentiellement, tout dépend si le SGBDR utilisé est capable d'index le XML ou pas. Par exemple dans SQL Server c'est beaucoup plus rapide qu'une solution à base de multi sets par ce qu'il index le XML et que l'on peut le valider grammaticalement via des XSD et que cela évite une jointure avec une table de traduction. Par contre sur PostGreSQL c'est indubitablement plus lent... pas de validation XSD et pas d'index XML !

Enfin, pour gérer correctement le multilinguisme il faut un SGBDR qui supporte correctement les collations et à ce stade il n'y en as pas 36. Seul SQL Server et IBM DB2 permettent de traiter correctement toutes les opération COLLATE à ce jour.... Même Oracle est très en retard venant en fin de comprendre dans la version 12 l'intérêt de la gestion des collations...

A +

[remy67]

Merci pour vos retours.
Je vais voir comment intégrer cela à mon projet.

[StringBuilder]

SQL Server supportant depuis les dernières versions JSON, est-ce possible d'utiliser ce type plutôt que XML ?

En effet, cette syntaxe est à la fois plus succinte et plus lisible, mais aussi et surtout peut être utilisée "telle quelle" pour produire des objets côté applicatif.

Quel serait l'équivalent du XSD pour une colonne JSON ? On peut indiquer une classe JS comme modèle ?

[SQLpro]

Oui et NON !

JSON n'est pas un type de données contrairement à XML. JSON repose sur du texte.
Ce qui implique différentes choses, prenant l'exemple de SQL Server (mais même chose dans Oracle) :
1) pas de typage fort (une colonne XML peut être contretypée par une collection de schéma XML)
2) pas d'indexation possible (une colonne XML peut être doté de 1 à 4 types d'index suivant les besoins)
3) des méthodes de manipulation qui peuvent utiliser les index et le parallélisme, pour l'accès aux composantes du XML (nœuds, éléments, attributs, balises…)

Il va s'écouler beaucoup de temps avant le jour ou le JSON ne devienne efficace, c'est à dire que les pôles de R&D des grand éditeurs ne découvrent les moyens de résoudre ces problèmes de performance…
Je crains hélas que les effets de mode ne tournent les développeurs un peu trop vite vers le JSON sans en mesurer pleinement les conséquences….

A +

[StringBuilder]

C'est surprenant cette différence entre JSON et XML.
Car tout ce que permet de faire XML peut être fait en JSON, au détail près du schéma (qui peut avantageusement être remplacé par une définition de classe pour le JSON).

J'imaginais donc naïvement que JSON = XML au niveau du moteur de stockage/requête, mais que seule la représentation changeait (et le langage d'interrogation).

[SQLpro]

Pour information en ce qui concerne l'indexation, la méthode la plus efficace concerne les valeurs scalaire de type unipoint comme nombre, date ou chaine (binaire ou caractères), tout simplement parce qu'il suffit d'un tri de ces valeurs et une méthode dichotomique pour y accéder efficacement.
Dès que l'on a affaire avec autre chose qu'une collections de "points" pour lesquels il existe une fonction de classement, il faut trouver, et l'organisation apte à créer un ordonnancement et la méthode de recherche dans l'organisation.
Par exemple pour le spatial (des données à deux points en X/Y) l'organisation est un pavage (en anglais tesselation) et la méthode d'accès peut être un QuadTree (solution adopté par PostgreSQL) par exemple.
Pour ce qui concerne le XML, les éditeurs (IBM, Oracle, MS SQL Server) créent, et leurs organisations qui leurs sont propres, et les méthodes d'accès qu'ils ne peuvent breveter, mais dont ils conservent jalousement le secret.
C'est pourquoi PostgreSQL ne sait pas du tout indexer le XML et recoure à un artifice plus que limite pour indexer un p'tit bout du XML, via une fonction qui expose un élément littéral extrait du XML. Autrement dit, rien du tout….

Donc, je pense que la similitude apparente entre les deux formes (XML et JSON) dont l'organisation diffère, nécessite hélas de nouvelles investigations en R&D pour trouver un moyen d'accès efficace et l'organisation qui va avec et sera propre au JSON…. Mais peut être qu'entre temps, nous aurons eu une nouvelle mode et donc une nouvelle forme… ou bien une ancienne comme SGML !

A +