Structure de table pour supporter les paramètres régionaux

**Passepoil** · 02/05/2011, 15h34

Bonjour,

J'aimerais savoir comment créer une bonne structure de tables afin de supporter le multi-langue.

Par exemple, les valeurs d'un combobox sont fournies par une table SQl et je veux que les valeurs soient traduites selon la langue (paramètres régionaux).

Merci.

**hmira** · 02/05/2011, 20h27

Un des moyens le plus simple et le plus sûr, pour la mise œuvre consiste à créer, dans la table concernée, une colonne pour chaque langue (généralement de 2 à 4 colonnes au plus, c.à.d gérer 4 langues au maximum), puis pour chaque colonne, donc en fonction de la la langue et de la culture, choisir la collation la mieux appropriée.

A+

**elsuket** · 03/05/2011, 05h12

Bonjour,

Je ne suis pas un défenseur de ce type d'approche, et je préfèrerai toujours un table très "longue" que très "large".

En conséquence je créerai plutôt une table avec l'identifiant de l'item à traduire, l'identifiant de la langue, et la traduction.
De cette façon vous pouvez rajouter autant de langues que vous voulez sans changer :

- ni la définition de vos entités
- ni la structure physique de vos tables (je pense notamment aux index, full-text ou pas)
- ni votre code

La collation ne permet pas de stocker un jeu de caractères.
Elle dicte seulement l'ordre de tri.
Si l'on souhaite stocker des caractères autres que les caractères latins (varchar), il faut utiliser Unicode, c'est à dire le type de données nvarchar.

En revanche, sous ce dernier type de données, il en coûte deux octets par caractère au lieu d'un en varchar (ASCII).

@++

**Passepoil** · 03/05/2011, 14h20

Merci à vous deux,

ça me confirme que j'étais pas trop à côté de la traque car c'est les 2 approches que j'avais déjà utilisées.

elsuket,
Est-ce que tu utiliserais une seule table pour toutes les applications?

**WOLO Laurent** · 03/05/2011, 17h41

Si tu veux partager les données de cette table dans plusieurs applications ?
Si tu n'as pas de contraintes de sécurité, ni d'isolations pourquoi ?

**iberserk** · 03/05/2011, 19h24

pour toutes les applications

Une application par langue?
Vos applications sont 'elles réellement multilingue (c'est à dire une même application pouvant afficher plusieurs langues différente en même temps)?

**elsuket** · 04/05/2011, 05h29

Est-ce que tu utiliserais une seule table pour toutes les applications?

A vrai dire je crois que je créerais une table contenant le nom de l'objet de l'application qui peut être traduit.

Créer donc :

- une table avec tous les types d'objets qui peut être traduits, par exemple bouton, checkbox, colonne, barre de titre, étiquette, lien, ...
- une table avec tous les noms de tous les objets, qui référence la table précédente
- une table avec la liste des langues que votre application doit supporter
- une table qui donne toutes les traductions disponibles pour tous les objets. Elle référencerait donc la table des objets et de langues, avec une colonne en plus pour la traduction.

Le tout bien indexé, avec les quelques procédures stockées qui vont bien, je vous garantis que vos le tout est souple, robuste et rapide

@++

**iberserk** · 04/05/2011, 07h55

Ok avec elsuket...

Pensez également au cache ASP.NET si c'est une application WEB qui permet de stocker les données de faible volumétrie fréquemment utilisés tels que les données issues des tables de paramétrage mais aussi les tables de références ou même les traductions...

**Passepoil** · 04/05/2011, 15h55

Je ne connais pas l'ASP.NET, je travaille plutôt en WinForms, et je vais bientôt migrer vers WPF, mais je croyais que pour la traduction de l'interface, on utilisait des fichiers ressources (un par langue) et pour les données provenant des tables, là j'avais besoin d'une telle structure??