Version imprimable
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.
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+
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).
@++ ;)
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.
:ccool:
elsuket,
Est-ce que tu utiliserais une seule table pour toutes les applications?
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 ?
Une application par langue?Citation:
pour toutes les applications
Vos applications sont 'elles réellement multilingue (c'est à dire une même application pouvant afficher plusieurs langues différente en même temps)?
A vrai dire je crois que je créerais une table contenant le nom de l'objet de l'application qui peut être traduit.Citation:
Est-ce que tu utiliserais une seule table pour toutes les applications?
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 ;)
@++ ;)
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...
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??
Valable pour les données non modifiables (dans un site web j'entends...)Citation:
des fichiers ressources (un par langue)
Sinon galère lié au multiuser en perspective:ccool:
Merci pour ces précisions.