Discussion :

[Raphael1980]

Bonne rencontre,

Nous sommes une petite équipe et nous avons toujours gérer ce cas un peu à la 6-4-2.

Ici, on souhaite prendre le temps de bien faire les choses et ce pose des questions sur l'aspect multilingue des données dans la base de données. Surtout les tables de références, le reste peut être gérer du côté applicatif.

Exemple avec une table villes : Paris, Parijs, Parigi, etc

Comment définir les champs de cette table ?

Idée 1 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

TR_City (id,name_fr,name_nl,name_it,lat, lng,enabled)

Idée 2 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
TR_City (id,lat,lng,enabled)
TR_Translation (id,id_city,code_translation,translation)

--> code_translation = fr_FR, nl-BE, es-ES, etc

Voilà en gros, on ne sait pas quel chemin prendre. On voit beaucoup Internationalisation au niveau de l'application mais pas au niveau de la DB.

J'ai vu beaucoup de posts ici mais je ne trouve pas LA réponse.

D'avance, merci pour votre aide.

Amicalement,
Raphaël.

[Raphael1980]

Personne n'est confronté à ce genre de problématique ?

Je ne trouve pas réellement pas bonne solution. Je ne suis pas fan du côté traduction du côté applicatif.

[SQLpro]

1) c'est bien à la base de données de fournir les traductions.
2) il y a deux types de cas : les libellé (dans ce cas c'est à l'application de s'en occuper) et les données (dans ce cas c'est bien à SQL de traiter le problème).
3) la gestion du versionnement des langues doit être indépendante des données fonctionnelles

Ce qui signifie que :

• vos tables fonctionnelle doivent être inchangée par le versionnement des langues.
• On utilise alors une série de tables spécifiques à ces méta traductions, qui doivent figurer dans un schéma SQL spécifique

A +