Discussion :

[adri5656]

Salut !

Je suis en train de réfléchir concernant la traduction franco-anglaise d'un site, sachant que tous les textes dans les deux langues doivent êtres modifiable via l'administration.
Pour l'instant j'ai crée une bdd avec 3 colonnes (id, fr, en). Et j'enregistre chaque mot avec sa traduction. Après sur le site j'appelle chaque texte avec une requête selon l'id du texte.
Cependant cela nécessite donc une requête par mot à afficher sur chaque page !!! Ce qui est énorme et risque de ralentir le site.
Je pense donc créer un fichier : fr.php et en.php contenant tous les mots ex:

dans le fr.php :
$1 = "La nouvelle façon de naviguer";
$2 = "Rechercher";

dans le en.php :
$1 = "The new way to sail";
$2 = "Search";

En cas de modification de la bdd, ces fichiers seraient mis à jour depuis la base de donnée, par exemple tous les jours à minuit (tâche cron).

Donc après sur une page on fait un include fr.php ou en.php en fonction de la langue choisie (enregistrée dans un cookies).

Que pensez-vous de cette méthode ? Est-il plus efficace d'inclure un énorme fichier contenant plusieurs centaines de variables, ou alors de faire 30-40 requêtes sql sur la table à chaque chargement de page? Ou alors est-il possible de faire autrement, tout en sachant qu'il faut que tous les textes soient modifiables via une administration?

Merci

[Exia_]

Bonsoir,

pourquoi stocker chaque mot dans chaque langue et pas des articles ou contenu complet ?

Par exemple un article complet en Anglais et une version Française.

[ericd69]

salut,

et regarde ce qu'on appelle la recherche fulltext, je crois que tu feras un grand pas

[grunk]

Si il sagit de traduction pour l'interface du site et d'élément statique , utilise simplement un format standard du type TMX ou Gettext

Charge ensuite à toi de faire une interface d'édition pour ces fichier. Le plus simple étant ici TMX puisqu'il n'y a pas besoin de recompiler le fichier après modification.

Pour ce qui est des traductions des contenus dynamiques (genre article , news ...). Il faut passer par une table supplémentaire pour chaque entité.

Par exemple une table news :

Code :

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

1
2
3
4
5
6
7
8
news
--------------
-id
-idAuteur
-date
-titre
-texte
---------------

Deviendras :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
news
----------------
-id
-idAuteur
-date
----------------
 
news_trans
----------------
-id
-id_news
-id_lang
-titre
-texte

on ajoute donc une table supplémentaire pour gérer les langues. De cette manière on peut potentiellement ajouter une infinité de langue sans toucher à la structure de la base.
La méthode un peu plus en détail ici

[RunCodePhp]

Salut

@grunk +1

Pour l'instant j'ai crée une bdd avec 3 colonnes (id, fr, en).

Je ne te conseil pas (tout comme grunk) de prendre cette voie là, même si c'est déjà trop tard, ou partiellement fait.

La conception d'une BDD repose sur des normes où il bon de respecter.
Ceci dit, il n'est pas rare de ne pas tout respecter, mais cela se fait (ou doit se faire) en toute connaissance de cause.
En somme on fait pas bien volontairement, et cela se fait pour des raisons d'optimisation bien souvent.


Ta structure ne respecte pas ce qu'on appel la "3ème forme normal", c'est à dire qu'on y voit un phénomène de répétition de colonnes très caractéristique.
table (..., fr, en, es, it, etc ...).
-> Forme normale (bases de données relationnelles)

En fait, tu occultes totalement une donnée qui pourtant est évidente : la langue.
Pour se dire la chose suivante :
Pour 1 news on aura plusieurs contenu différents -> un contenu pour chaque langue.
On a bel est bien une relation de 1 à plusieurs (plus exactement des cardinalités 1:n) quelque part.
Donc cela sous-entend que les données devraient se faire sur au moins 2 tables.
Sans compter qu'on sait qu'il y aura plusieurs langues, donc cela sous-entend qu'il devra (ou devrait) avoir une liste de langue quelque part.

Tout est là, tout est une question de relation entre chaque donnée.

[ericd69]

ce qui est renforcé par le fait que tu n'auras pas forcément une traduction de toutes les news dans toutes les langues...

il ne faut pas avoir peur des jointures qui sont les opérations les plus optimisées des sgbd...

les formes normales sont en effet à respecter le plus possible si tu veux avoir une bd efficace

ici ça te permet de faire une recherche fulltext sur une seul colonne: texte dans la table news_trans

au passage n'utilise que de l'utf8 proscris les encodage latin... surtout pour un site multilingue...