Discussion :

[Haelle]

Bonjour,
Je travaille sur un site en ASP.NET qui a pour but de gérer l'internationalisation. Je suis parti pour utiliser le système de "Local Ressources" proposé par Microsoft mais je me pose une question. Comment faire (proprement) pour que les éléments de la base de données change aussi de langue. Il faut bien sûr que quelque part ils soit traduit.

Dans ma base de données j'ai des éléments qui correspondent à des descriptions et ce sont donc des phrases en français.

ASP :

Code :

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

1
2
3
4
5
6
7
<asp:DataList ID="DataList1" runat="server" OnItemDataBound="dlItemDataBound" 
                    meta:resourcekey="DataList1Resource1">
                    <ItemTemplate>
                        <asp:Label ID="lblName" runat="server" meta:resourcekey="lblNameResource1"/>
                        <asp:Label ID="lblInfo" runat="server" meta:resourcekey="lblInfoResource1"/>
                    </ItemTemplate>
                </asp:DataList>

C#

Code :

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

1
2
3
4
5
6
7
8
protected void dlItemDataBound(object sender, DataListItemEventArgs e)
        {
            Label lblName = (Label)e.Item.FindControl("lblName");
            lblName.Text = ((MonObjet)e.Item.DataItem).m_Name;
 
            Label lblInfo = (Label)e.Item.FindControl("lblInfo");
            lblInfo.Text = ((MonObjet)e.Item.DataItem).m_Info;
        }

Et donc j'aimerai que lblName et lblInfo soit aussi traduit...

Merci d'avance,
Haelle

[Immobilis]

Salut,

Les fichiers ressource c'est pour les parties statiques du site. Pour le faire avec une BD, tu peux t'inspirer de ceci: http://immobilis.developpez.com/arti...-base-donnees/

Pour traduire les contenus dynamiques c'est un peu différent. Est-ce ton besoin?

A+

[Haelle]

oui c'est ce que je cherchais, je me sens bête de n'avoir pas trouvé ce tuto hier...
Merci bien, cette solution est plus élégante que celle que j'allais faire.
Bonne journée
Haelle

[Davjack]

...Pour traduire les contenus dynamiques c'est un peu différent...

Pour ma part, je m'intéresse à la traduction de contenu dynamique.

En effectuant quelques recherches sur le Web, j'ai vu plusieurs possibilités dont :

• Ajouter un champs pour chaque langue dans la table (contenu_fr, contenu_en, etc.)
• Pour chaque table à traduire, créer une seconde table de traduction qui y est liée. Par exemple (de manière simplifiée) :
  

  table languages
  -- id (int)
  -- name (varchar)
  
  table categories
  -- id (int)
  
  table categories_translation
  -- id (int)
  -- category_id (int)
  -- language_id (int)
  -- title (text)
  -- content (text)

• La traduction dans une table centralisée, accessible via un index "jeton" :
  

  table languages
  -- id (int)
  -- name (varchar)
  
  table categories
  -- id (int)
  -- token (varchar),
  
  table content
  -- id (int)
  -- token (varchar)
  
  table translation
  -- id (int)
  -- content_id (int)
  -- language_id (int)
  -- content (text)

De ton côté, quelle(s) méthode(s) préconise-tu?

[Immobilis]

sALUT

De ton côté, quelle(s) méthode(s) préconise-tu?

Pour ma part, je dirai la table centralisée. C'est plus simple à maintenir. Il faut une table sous cette forme:

1. TABLE_NAME (nom de la table dans laquelle se trouve l'enregistrement)
2. FIELD_NAME (nom du champ dans lequel se trouve l'enregistrement)
3. FIELD_ID (identifiant de l'enregistrement à traduire)
4. LANGAGE_ID (identifiant de la langue)
5. TRANSLATION (traduction)

Les 4 premiers champs constituent la clef de la table). Tu peux ajouter un identifiant auto-incrémenté comme clef primaire.

A+

[Davjack]

Merci pour ta réponse!

J'ai également vu une autre solution qui consiste à faire une auto-jointure sur les tables à traduire.
Pour reprendre l'exemple avec la table catégorie, ça donnerait qqch dans le genre :

table languages
-- id (int)
-- name (varchar)

table categories
-- id (int)
-- content (varchar)
-- language_id (int)
-- main_row_id (int)

Les enregistrement ayant un main_row_id null sont les enregistrement de base (langue principale de l'application). Les traductions se réfèrent à l'enregistrement de base.

Ta solution me paraît bien. Avec une petite adaptation, il doit être possible de gérer dans cette table l'ensemble des traductions liées aux enregistrements et à la structure du site de manière à simplifier et homogénéiser le code de l'application (quelle que soit la traduction, elle se fait toujours de la même manière).

[StringBuilder]

Bonjour Davjack,

Est-ce que tu peux détailler un peu :
- ce que tu entends par "contenu dynamique"
- jeton

En effet, je ne comprends pas la structure des tables dont tu parles avec la notion de token.

[StringBuilder]

Merci pour ta réponse!

J'ai également vu une autre solution qui consiste à faire une auto-jointure sur les tables à traduire.
Pour reprendre l'exemple avec la table catégorie, ça donnerait qqch dans le genre :

Les enregistrement ayant un main_row_id null sont les enregistrement de base (langue principale de l'application). Les traductions se réfèrent à l'enregistrement de base.

Ta solution me paraît bien. Avec une petite adaptation, il doit être possible de gérer dans cette table l'ensemble des traductions liées aux enregistrements et à la structure du site de manière à simplifier et homogénéiser le code de l'application (quelle que soit la traduction, elle se fait toujours de la même manière).

Ça me semble particulièrement mauvais : tu démultiplies les lectures et le volume lu pour pas grand chose. D'autant que lorsque tu consultes les données dans la langue "de base", alors tu fais une auto-jointure inutile.

[Davjack]

- ce que tu entends par "contenu dynamique"

Je considère qu'il y a deux types d'éléments à traduire sur une application basée sur une base de données :

1. Les éléments statics : ils se trouvent généralement directement dans le code de l'application. Normalement, ces éléments ne changement pas.
2. Les éléments dynamiques : dans mon cas, ils se trouvent dans la base de données. Ce sont les textes qui peuvent être créés, modifiés et supprimés via l'application (par exemple, une liste de catégorie, des contenus d'articles, etc.)

- jeton

En effet, je ne comprends pas la structure des tables dont tu parles avec la notion de token.

Le principe de jeton est très proche de la solution proposé par Immobilis. Il est décrit ici : http://stackoverflow.com/questions/2...atabase-schema

[StringBuilder]

Je sais pas si c'est le vendredi ou l'âge, mais j'ai l'impression que mes capacités intellectuelles sont en train de s'effondrer

Est-ce que t'as un exemple simple sous la main pour que je vois ce qu'est "TokenName" et "Token". En effet, je ne trouve pas dans le texte d'élément concret, ça reste trop abstrait à mon goût, et même si j'ai bien une idée derrière la tête, je ne suis pas du tout certain que ce soit ça.

Autant je comprends parfaitement ce type de modèle :

categorie
id
nom

categorie_lan
id
lan_id
nom

=> Classique, avec présence systématique d'une valeur dans une langue par défaut. Couramment mise en place dans les applications qui deviennent multi-lingue alors qu'elles n'étaient pas prévues pour.

Celui-ci :

categorie
id

categorie_lan
id
lan_id
nom

=> Dérivé, n'utilise plus de langue par défaut, et harmonise les requêtes toutes langues confondues

Ou encore celui-ci, avec une table mutualisée pour les libellés :

categorie
id
label_code

labels
label_code
lan_id
label

=> Lourd à gérer, car la relation de clé étrangère entre labels et categorie n'est pas possible au niveau de la base de données, mais pratique dans la mesure où une unique table contient tous les textes de toutes les langues, et que cette table peut être chargée en cache et aussi être utilisée pour tous les contenus statiques de l'application.

Autant cette histoire de token, j'arrive pas à comprendre

[Davjack]

Comme j'ai compris la chose (c'est vrai que ce n'est pas limpide :-) ) TokenName est l'équivalent de Token (et je ne vois pas trop l'utilité de DescriptionToken). Il permet de lier toutes les tables que l'on voudrait traduire et la table "content" (un peu comme sur ton dernier exemple avec "label_code"). J'immagine le contenu du champ "token" comme une clé unique dans la base de donnée. C'est d'ailleurs certainement pour garantir cette unicité que la table "content" existe.
En résumé,

• j'ai une "category" dont je recherche la traduction
• je recherche sont "content" via le token de "category"
• finalement, je recherche la traduction dans la langue souhaitée dans la table translation

J'espère avoir pu t'éclaire avec ma compréhension du modèle proposé par Eric Petroelje. Maintenant... est-ce une bonne solution? En tout cas, ça semble pouvoir fonctionner.

[StringBuilder]

Hmmm, ok, en effet, il manque la notion d'unicité de LABEL_CODE.

Dans mon exemple, étant membre de la clé de "labels" (clé primaire ou alternative) il était de toute façon déjà unique, mais ok, je comprends... Et pour moi, la description doit être dans la table content et non la table category) :

category
id
label_code

label
label_code
description

label_ml
label_code
lan_id
label

Et dans category :

Code :

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

1
2
3
 
1         LBL_CAT_1
1         LBL_CAT_2

Dans label :

Code :

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

1
2
3
 
LBL_CAT_1    Libellé de la catégorie 1
LBL_CAT_2    Libellé de la catégorie 2

Dans labels :

Code :

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

1
2
3
4
5
 
LBL_CAT_1  FR  Voiture
LBL_CAT_1  EN  Car
LBL_CAT_2  FR  Vélo
LBL_CAT_2  EN  Bike

La description dans label servant juste à des fins "internes", dans l'écran de saisie des traductions par exemple.

Je trouve en effet cette méthode séduisante, et plutôt simple à mettre en place.

[Davjack]

Après avoir poussé ma réflexion un peu plus loin concernant ce modèle "token", j'y trouve un principal défaut : on ne peut traduire qu'un seul champ par enregistrement.

J'ai pensé à la solution ci-dessous pour répondre à ce problème :

Si quelqu'un a des critiques ou améliorations à me soumettre, je suis preneur

[StringBuilder]

Euh, pas besoin...

Dans ta table category, tu crées autant de colonnes "token_x" que tu as de champs à traduire :

category
id
token_category_name
token_category_description
token_couleur_du_cheval_blanc_de_henri_iv

Et chaque champ token_x référence un token dans la table label.

Et du coup, je comprends d'un seul coup pourquoi "token" et "token_description", c'est qu'il y a un champ "nom" et un champ "description" en fait dans la table de l'exemple dont tu as mis le lien

[Davjack]

Magnifique! Voilà que tout est enfin clair!

Comme quoi, ces échanges de postes sur forums sont des plus bénéfiques! Merci pour ce partage de points de vue!

Perso, je pense que je vais opter pour ce modèle pour mon développement.