Lorsque l’on se lance dans un site multilingue, on pense tout de suite, à comment va être traduit l’interface. On opte en général pour gettext ou une solution reposant sur une bdd (pas top à mon gout).
Cependant traduire le contenu de la base de données est une tout autres histoire et demande un peu plus de réflexion.
Prenons par exemple la table suivante :
videos
-id
-fichier
-duree
-nbvu
-titre
-description
Pour traduire le contenu de cette table il existe 2 méthodes très répandues mais qui présentent beaucoup de désavantages :
1- Duplication des colonnes
Dans cette méthode on va dupliquer les colonnes ayant besoin d’être traduite. Ce qui donnerait pour 2 langues :
videos
-id
-fichier
-duree
-nbvu
-titre_fr
-titre_en
-description_fr
-description_en
Cette méthode à l’avantage d’éviter la duplication de contenu, cependant elle trouve très vite ses limites. Il est difficile d’y ajouter une langue et la maintenance est une horreur si vous avez beaucoup de langue différente. Cependant cette méthode est facile à implémenter et peut être une méthode viable si vous avez seulement deux langues et ne risquez pas d’en rajouter.
2- Duplication des lignes
Pour pallier au problème de l’ajout de nouvelle langue certains préfère dupliquer les lignes plutôt que les colonnes. On se retrouve alors avec une table du type :
videos
-id
-fichier
-duree
-nbvu
-titre
-description
-langue_id
langue
-id
-code
Vous aurez donc autant de lignes pour une vidéo que vous aurez de langue.
L’ajout de nouvelle langue est donc facilité mais la duplication de contenu que cette méthode induit est à mon avis une très mauvaise chose.
Comment peut-on traduire le contenu de notre table ?
J’ai opté pour une méthode différente. Elle oblige à créer une table supplémentaire pour chaque table ayant besoin d’être traduite mais à le mérite de combiner les avantages des deux méthodes précédentes :
– Pas de duplication de contenu
– Ajout de langue simple
– Facile à interroger
Nous allons donc nous retrouver avec trois tables :
Pour chaque vidéo on aura un enregistrement dans la table vidéo auquel on associera des enregistrements de la table videos_traduction.
La sélection des données reste simple :
SELECT v.id,v.fichierFROM videos vINNER JOIN videos_traduction vt ON vt.idVideo = v.idWHERE vt.idLangue = :langue
En plus de tous les avantages précédemment cités, cette méthode apporte un niveau de normalisation tout à fait satisfaisant.
Et vous quelle méthode utilisez vous ?
Bonjour,
Je suis arrivé à la même conclusion que vous mais si vous aviez une table Vidéos, une table Photos et une table Journaux à traduire, feriez-vous une table intermédiaire pour chacune de ces tables ?
Pour ma part, j’ai pensé faire une seule et unique table de traduction avec un lien vers la table ad hoc.
Le hic, c’est que je ne peux pas mettre idVideo, idPhoto, idJournal dans la table traduction car si c’est une vidéo, ce n’est pas une photo et ce n’est pas un journal et j’aurais tendance à mettre NULL dans les id inutiles… Mais de mémoire, les intégrités référentielles n’autorisent pas à avoir un NULL…
Comment feriez-vous ?
Bonjour,
une table de traduction pour chaque table.
Cependant peut être que les tables photos et vidéos peuvent être regroupées sous une unique table « media » si elles sont identiques