Discussion :

[maa]

Bonjour,

J'aurais besoin d'un petit conseil de conception.
Je développe une application multi-langues qui sert à organiser des produits. Ces produits ont un nom qui doit être traduit dans chaque langue. Pour la classe produit, je pensais faire un propriété "Nom" qui est un Dictionary<Lang, string> ou Lang est une énumération des langues possibles. Cela à l'avantage de pouvoir facilement paramétrer dans quelle langue je veux avoir le nom du produit, par contre ça n'est pas évident à utiliser avec le Binding, la sérialisation,...
Auriez-vous une autre idée à me proposer ?

Merci d'avance pour vos suggestions.

mathmax

[Thomas Lebrun]

Et pourquoi pas ca: http://morpheus.developpez.com/localisationdotnet/ ?

[maa]

J'ai lu l'article, ça à l'air bien mais pour les raisons suivantes, je crains que cela ne me convienne pas :

- J'ai besoin dans mon application d'avoir conjointement les traductions de mes propriétés dans les différentes langues. Par exemple, je voudrait pouvoir afficher les produits dans une gridview avec dans une colonne le nom en français et dans l'autre le nom en allemand. Or il me semble que la localisation est au niveau de l'application, c'est à dire qu'on peut seulement décider à un moment donné si l'application est dans une langue ou dans l'autre.

- J'utilise nhibernate pour récolter mes donnée et les charger dans mes objets. Il est relativement facile de charger les différentes langues dans une propriété de type dictionnaire (une traduction par ligne du dictionnaire), mais je ne vois pas comment utiliser la localisation conjointement avec un tel outil de mapping O/R. Et même si c'était possible, cela voudrait dire qu'à chaque lancement de l'application, les données seraient chargées dans des fichiers xml plutôt que dans les objets ? J'ai peur que ça soit limite au niveau des performances...

[theMonz31]

bonjour

Personnellement, je prendrais le problème de la façon suivante :

1 - Que dois-je mettre dans ma base de donnée pour que les informations soient
pertinentes et perennes ?

2 - Pour la traduction, cela doit etre fait au niveau de l'application et de la "couche présentation"... comme cela, les textes affichés dépendent de la langue choisie...

Apres, tu peux avoir un service (une classe) qui te fournit les traductions en fonction de ce que tu demandes... ET ce Language Provider va te fournir des fonctions genre : GetTranslation(string Language, string TextToTranslate)
par exemple

Voila comment j'attaquerais le problème

The Monz, Toulouse

[cinemania]

le probleme de la traduction dans son cas, TheMonz est autrement plus complexe.

En effet, ton provider de langue ne peut pas connaître toutes les traductions possible et imaginable d'une langue à l'autre, d'autant que les traductions, souvent dépendent du contexte d'exploitation.
Il suffit de voir comment tu traduirais certaines expressions anglaises qui dans le cas de l'informatique on une signification et dans le reste des cas, une autre radicalement diffrent. Je parle même pas des mots.

si sa traduction regroupe des univers différents, comme d'un coté des Produits agricoles, et de l'autre des Produits informatique, les nomenclatures sont différentes, ainsi que le contexte linguistique pourtant les deux peuvent etre représenter dans une meme et unique table, avec éventuellement des tables de spécification... mais globalement par l'héritage... le Produit est le meme, pas du tout en terme de language.

Et puis comment va tu représenter ton provider de langue ?
Là il ne faut pas confondre langage coté logiciel, et donc de l'interface graphique, et langage coté données utilisateurs... ces univers sont différents.

Pour ma part, j'ai le meme cas, donc en fait j'ai coupé la poire en deux
J'ai les traductions systèmes de l'interface qui sont écrites dans l'application, dans les xml, et ressources de l'application (ressources localisées) et j'ai les traductions de donnes, qui sont dans une table à part.
et là où habituellement j'ai un nom ou un libellé j'ai un code (une référence) vers cette table de traduction... qui est un ensemble de Dictionary... Cependant cette table de traduction comprend pas seulement les données spécifique d'un type d'objet mais de tout le système de données.

Cela dit... personnellement je ne suis pas un afisionado des "framework" à la nhibernate et préfère écrire moi meme tout le code, ce qui me permet plus de liberté et d'excentricité sur le stockage dans la base de données.

dans ce projet j'ai une seule table pour tous les objets avec le type de l'objet, son identifiant, et un champ XML avec sa définition XML entière. De là, mon programme peut instancier une classe depuis ce XML car je n'utilise pas la serialisation xml de .NET mais une sérialisation XML complète en profondeur.
cela dit maintenant que Linq To SQL est sorti, je pense que cela va me réconsilier avec le mapping relationnel mais c'est une autre histoire.

[maa]

theMonz31, si tu parlais de ne pas stocker les traduction en base de données mais de les traduire au niveau de la couche présentation, ça n'est pas possible dans mon cas (pour les raisons dont parle cinemania)

cinemania, donc si j'ai bien compris, tu as fais un dictionnaire centrale comprenant toutes sorte de traduction, chaque ligne ayant un identifiant. Tu retrouve ensuite la traduction depuis tes objets grâce à cet identifiant. Par exemple, dans la propriété "Nom" de la classe produit du stock seulement l'identifiant puis quand tu veux t'en servir, tu fais un truc du genre :
MaTableDeTradution[MonProduit.Nom][Langue] ?
Quel est l'avantage de procéder comme cela selon toi ?
Dans ce cas, il faut refléter la même chose au niveau base de donnée, c'est à dire faire une table de traduction centrale.
Pour le moment, j'ai la structure suivante : à chaque fois que j'ai une table contenant des textes à traduire, je crée la table MaTable_Texts qui contient les identifiant des lignes de MaTable, les code iso des langues et les traductions des textes. Donc au final, je charge les traduction directement dans mes objets.

[cinemania]

dans mon code g une classe de type Singleton donc unique qui gère intégrallement la bibliothque des traductions hormis les trad système de l'application qui elles sont directement dans les ressources localisées de l'applications.

cette classe possède donc un dictionnaire sur 2 clés. la première c'est l'identifiant de la traduction. Cette clé est obligatoire.
la seconde est une clé de sélection qui contient l'identifiant de la langue.
le résultat la traduction associée.

Partout où je suis suceptible de rencontrer une donnée traductible... j'ai non pas ma valeur, mais un identifiant vers ce dictionnaire géant, ma classe fait les transformations et conversions requises le moment venu...

En gros quand je veux afficher un résultat je l'affiche mais avant je le passe dans le traducteur... Lang.Instance.Translate(madonnee) qui va chercher madonnee comme identificateur de traduction, et va prendre la langue courante et va chercher dans la table. Et si la traduction existe mais pas pour la langue courante, on prend alors la langue par défaut... si elle existe pas ba chaine vide quoi.

Dans ma base de données jai donc une grosse table de traduction, avec comme clé le code de langue et l'identifiant de l'entrée à traduire, les deux formes une clé unique.
Maintenant s'ils les souhaites ils peuvent utiliser des clés de traductions identiqus pour certaines choses... ils peuvent forcer la clé utiliser... de toute facon ils ont accès à une interface qui fait tout pour eux.

Attention, chez moi ca marche bien car j'ai une modelisation client/serveur... typiquement car le client n'obtient que la donnée finale traduite coté serveur (webservice) et le serveur étant le seul a être autoriser à manipuler la table des traductions en écriture... je peux assurer qu'il travail toujours avec des valeurs cohérentes et que les données en cache sont identiques à celles présentes dans la base, pour celles qui sont en cache, ca va de soit...

[maa]

Bien compris. Sauf cette phrase

Maintenant s'ils les souhaites ils peuvent utiliser des clés de traductions identiqus pour certaines choses... ils peuvent forcer la clé utiliser... de toute facon ils ont accès à une interface qui fait tout pour eux.

Par contre quel intérêt de centraliser toutes les traduction dans une table géante ? L'accès y est forcément plus lent que si on stock les traductions au niveau des objects.

Par contre, moi je n'ai pas toujours de langue courante. L'interface affiche des traductions dans plusieurs langues.