Quelle est la meilleure structure de base de données pour conserver les données multilingues?

Question

Double Possible:
Schéma d'une base de données multilingue

Voici un exemple:

[ products ]
id (INT)
name-en_us (VARCHAR)
name-es_es (VARCHAR)
name-pt_br (VARCHAR)
description-en_us (VARCHAR)
description-es_es (VARCHAR)
description-pt_br (VARCHAR)
price (DECIMAL)

Le problème: à chaque nouvelle langue aurez besoin de modifier la structure de la table.

Voici un autre exemple:

[ products-en_us ]
id (INT)
name (VARCHAR)
description (VARCHAR)
price (DECIMAL)

[ products-es_es ]
id (INT)
name (VARCHAR)
description (VARCHAR)
price (DECIMAL)

Le problème: à chaque nouvelle langue aurez besoin de la création de nouvelles tables et le champ "prix" est dupliqué dans chaque table.

Voici un autre exemple:

[ languages ]
id (INT)
name (VARCHAR)

[ products ]
id (INT)
price (DECIMAL)

[ translation ]
id (INT, PK)
model (VARCHAR) // product
field (VARCHAR) // name
language_id (INT, FK) 
text (VARCHAR)

Le problème: fuc*ing dur?

Answer 1

Similaire à la méthode 3:

[languages]
id (int PK)
code (varchar)

[products]
id (int PK)
neutral_fields (mixed)

[products_t]
id (int FK)
language (int FK)
translated_fields (mixed)
PRIMARY KEY: id,language

Donc, pour chaque table, faire une autre table (dans mon cas avec "_t" suffixe) qui détient la traduction des champs. Lorsque vous SÉLECTIONNEZ * à PARTIR de produits, il suffit de JOINTURE GAUCHE products_t SUR products_t.id = produits.id ET products_t.langue = CURRENT_LANGUAGE.

Pas difficile, et vous permet de rester libre de maux de tête.

Answer 2

Afin de réduire le nombre de de la JOINTURE, vous pouvez garder à l'écart de l'traduits et non traduits dans 2 tables distinctes :

[ products ]
id (INT)
price (DECIMAL)

[ products_i18n ]
id (INT)
name (VARCHAR)
description (VARCHAR)
lang_code (CHAR(5))

Answer 3

À mon $DAYJOB nous utiliser gettext pour l'I18N. J'ai écrit un plugin pour xgettext.pl que des extraits de tous les texte en anglais à partir de la base de données les tables et les ajouter à la maîtrise des messages.pot.

Il fonctionne très bien - les traducteurs travaillent avec un seul fichier lors de la traduction - le fichier po. Il n'y a pas de bricoler avec les entrées de base de données lorsque vous faites des traductions.

Answer 4

[languages]
id (int PK)
code (varchar)

[products]
id (int PK)
name
price
all other fields of product
id_language ( int FK )

J'utilise cette méthode, mais dans mon cas, ce n'est pas un produit de point de vue, pour les différentes pages de mon CMS, ce travail est tout à fait bien.

Si vous avez beaucoup de produits, il pourrait être un casse-tête pour mettre à jour un seul en 5 ou 6 langues... mais c'est une question de travailler la mise en page.