Jeu vidéo de gestion d'entreprise steampunk

Le problème de l'internationalisation...

Imprimer E-mail

InternationalisationFirmLife est un jeu qui sera disponible en plusieurs langues. Cela implique de gérer le changement de langue en direct ainsi que le contenu du site.

Ce travail peut être simplifié pour les contenus statiques en fonction du moteur que l'on utilise, cependant pour les contenus dynamiques cela peut être bien plus compliqué, surtout lorsque nous souhaitons garder une base de données pour les joueurs commune à toutes les langues.

Dans cet article, je vais tâcher de vous expliquer comment nous nous y sommes pris et quelles solutions nous avions.

Ce que nous souhaitons faire

Pour commencer, voici un petit schéma de ce que nous souhaitons faire:

Firmlife DBComme vous pouvez le voir nous souhaitons avoir une base de données commune contenant quelques tables (comme les utilisateurs) et nous souhaitons avoir des bases de données qui ont la même structure mais avec des données différentes (comme les langues).

Pour choisir quelle base de donnée nous souhaitons utiliser nous utiliserons une fonction appelée à chaque requête et retournant la valeur de la base de donnée (par exemple, en retournant la langue actuelle de l'utilisateur pour qu'il voit les données venant de la base de données française).

Les différentes possibilités

Pour gérer l'internationalisation des contenus dynamiques, il existe plusieurs possibilités ; je vais vous décrire ici les principales ainsi que leurs avantages et inconvénients par rapport à notre jeu et au moteur que nous utilisons.

Un site par langue

Avec cette technique, il y a un site à part entière par langue, la séparation des langues y est alors bien faite, cependant il ne nous est pas possible d'avoir des données communes à toutes les langues. De plus, ce genre de site est beaucoup plus difficilement maintenable car tout le code est répété pour chaque langue.

Un champs langue pour les tables de la base de données

Cette technique nous permet de séparer les langues et de continuer à avoir des données communes à toutes les langues, elle aurait donc pu être une bonne solution si la récupération des données par langue n'était pas aussi peu pratique. En effet, avec cette solution, pour afficher le contenu pour une langue il faut filtrer les données par rapport à la langue, ce qui veut dire des requêtes au serveur plus lourdes et un risque d'oubli (et donc d'erreur) plus élevé !

Une base de données par langue 

Une autre solution serait d'avoir une base de données par langue et garder une base de donnée pour les données communes à toutes les langues. Cette technique a l'avantage de fonctionner très bien, d'être performante et pratique mais elle n'est pas simple à implémenter.

La solution retenue et les difficultés

La dernière solution étant la meilleure, c'est elle que nous avons choisie malgré sa complexité d'intégration car nous avons besoin d'un système robuste pour gérer l'internationalisation du site.

L'intégration de cette solution ne fut pas de tout repos et plusieurs difficultés ont été rencontrées. En effet, le moteur que nous utilisons pour le site ne prévoyait pas ce genre de système dans sa version actuelle, nous avons donc dû anticiper un peu et apporter nous même quelques modifications à la dernière version du code du moteur. Ensuite, il nous a fallu écrire un plugin nous permettant d'automatiser le processus du choix de la base de données et de la connexion, impliquant encore quelques difficultés.

Après tout ce travail, nous sommes finalement parvenus à intégrer notre système d'internationalisation nous permettant de garder des données communes à toutes les langues. Avec ce système nous pouvons avoir différents types de bases de données : pas uniquement la base de données commune et les base de données des langues, mais aussi par exemple des bases de données pour chaque instance du jeu, etc... Pour cela rien de plus simple, il nous suffit d'annoter nos modèles pour préciser à quel type de base de données ils appartiennent et pour chaque type, une base de données sera créée pour chacune des valeurs/langues possibles avec les modèles concernés. Le choix de la bonne valeur/langue pour chaque type de base de données est défini au début de chaque requête par un appel à une méthode d'une instance de classe spécifique à chaque type.

Ce système nous permet donc de gérer nos bases de données de manière très flexible et très automatisée. Ainsi la sélection de la bonne base de données pour la requête en cours en fonction du modèle utilisé est transparente et fonctionnelle !

FirmLife ne sera pas limité à l'anglais et au français et l'ajout d'une nouvelle langue pourra se faire très facilement avec ce nouveau système ! 

Postez votre commentaire...

  • Sylvain Pollet-Villard

    Ecrit le 2012-08-30 15:51:36

    Hello,

    C'est pas un peu bizarre de mettre tous les champs texte du jeu en base de donnée ? Le contenu de vos pages, les noms des éléments, tout ça est censé être relativement fixe non ? Généralement on met en bdd toutes les données dynamiques et dans des fichiers (typiquement les properties en Java) les données statiques.

    Je connais assez mal le PHP, mais je voyais plus un truc de ce style : http://www.codeursolitaire.com/php/comment-creer-un-site-multilingue-en-php/ ; sauf si vous avez des raisons particulières de tout mettre en BDD mais là, je vois pas.

    Répondre à ce commentaire

    • Fabien Henon

      Ecrit le 2012-08-30 14:32:54

      Hello,

      C'est pas un peu bizarre de mettre tous les champs texte du jeu en base de donnée ? Le contenu de vos pages, les noms des éléments, tout ça est censé être relativement fixe non ? Généralement on met en bdd toutes les données dynamiques et dans des fichiers (typiquement les properties en Java) les données statiques.

      Je connais assez mal le PHP, mais je voyais plus un truc de ce style : http://www.codeursolitaire.com/php/comment-creer-un-site-multilingue-en-php/ ; sauf si vous avez des raisons particulières de tout mettre en BDD mais là, je vois pas.


      Nous n'avons aucune raison particulière de tout mettre en BDD car ce n'est pas ce que nous faisons.

      Ce travail peut être simplifié pour les contenus statiques en fonction du moteur que l'on utilise

      Ceci sous entendait en fait que le moteur que nous utilisons (qui au passage n'est pas en PHP) gère très bien les langues pour les contenus statiques.

      En revanche, notre problème était bien présent pour les contenus dynamiques comme les actualités qui sont ajoutées dynamiquement et qui sont différentes pour chaque langue.

      Répondre à ce commentaire

Newsletter

Image aleatoire

Qui est en ligne ?

Nous avons 159 invités et aucun membre en ligne

Calendrier

<< < octobre 2017 > >>
Lu Ma Me Je Ve Sa Di
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

Twitter

Twitter