Le scénario
Vous êtes propriétaire d'une boutique en ligne située en Pologne. La majorité de vos clients viennent de Pologne et parlent polonais. Mais vous souhaitez également vendre vos produits à l'étranger et vos clients internationaux parlent principalement anglais. Vous souhaitez donc que votre boutique en ligne soit disponible à la fois en polonais et anglais . Vous vous attendez également à ce que vos produits se vendent bien en France, vous prévoyez donc que vous devrez préparer un français version du magasin également (et peut-être en espagnol aussi, parce que pourquoi pas ?).
Vous souhaitez que vos utilisateurs puissent passer de la version polonaise
à la version anglaise et retour.
Et évidemment, vous voulez que les détails du produit passent du polonais à l'anglais.
Comment créer une application Web multilingue ?
Il existe deux types de texte dans votre application. L'un est statique données :libellés des boutons, en-têtes de tableau, graphiques (qui contiennent souvent du texte). L'autre est défini par l'utilisateur données, telles que le nom du produit, le prix du produit, la description du produit, etc. Les données sont normalement extraites de la base de données.
Les données statiques sont ce que vous voudriez écrire sous forme de littéral de chaîne dans votre sortie. Les données définies par l'utilisateur sont des données que vous extrayez de votre base de données.
Je ne parlerai pas de données statiques aujourd'hui. Tout framework Web raisonnable gérera l'internationalisation des données statiques. Consultez la documentation de votre infrastructure d'application Web pour plus de détails. Recherchez des mots clés tels que "internationalisation", "i18n", "localisation" ou "traductions".
Aujourd'hui, je vais parler de la structure de base de données que nous utilisons habituellement ici à e-point pour gérer les données multilingues. Dans la base de données de votre boutique, vous avez probablement le product table qui stocke des informations sur tous les produits disponibles dans le magasin.
Le product la table a des colonnes comme name , description , et price . Lorsque vous traduisez les informations sur le produit dans d'autres langues, vous n'avez qu'à traduire certaines colonnes. Ici, vous ne traduiriez que le name et description , mais le price ne change pas lorsque vous changez de langue.
Lorsque nous ajoutons la prise en charge de plusieurs langues, nous ajoutons une nouvelle table appelée language_version , qui stocke toutes les versions linguistiques disponibles dans le magasin. Nous ajoutons généralement une colonne appelée code et un appelé is_default (avec une contrainte appropriée :une seule version peut être la version par défaut).
Ensuite, nous divisons le product table en deux tables :table product et tableau product_lv . Pour chaque produit, il y aura une ligne dans le product table et plusieurs lignes dans le product_lv table; une ligne pour chaque version linguistique. Le tableau product_lv ne contient que des colonnes à traduire :name et description . Les colonnes indépendantes de la langue (comme price , parce que vous vendez au même prix peu importe si votre client parle anglais ou polonais) restez dans le tableau product .
Nous faisons de même pour chaque table contenant des données traduites. Les données traduites vont dans le table_lv table, les données indépendantes de la langue restent dans la table principale.
Avantages et inconvénients
Un inconvénient évident est que toutes les opérations de création, de récupération, de mise à jour ou de suppression (CRUD) deviennent un peu plus compliquées. Vous devez toujours joindre une table de version linguistique supplémentaire pour obtenir la bonne description.
L'avantage de cette conception est que vous n'avez pas à modifier le schéma de votre base de données lorsque vous ajoutez une nouvelle version linguistique. Je ne dis pas que l'ajout d'une nouvelle version linguistique est facile. Après tout, vous devez traduire TOUTES les descriptions de produits. C'est un défi organisationnel, mais du point de vue de la base de données, c'est assez simple :beaucoup d'insertions.
Comment concevez-vous vos bases de données multilingues ?
