Un jeu polyglotte - Oui, mais comment ?

[joshua]

Je te l'ai dit séphi: Cherche a module d'internationalisation php sur google et tu verras qu'il existe des classes toutes faites

[Sephi-Chan]

Les classes c'est OO.

C'est pourquoi ma méthode 2 me convenait tout à fait. C'est tellement plus simple de ne changer que la ligne de connexion.


Sephi-Chan

[naholyr]

Concernant le système de BdD, comment formeer la requête pour que ça ne sélectionne que le nom anglais ?

Si on part sur un système «fait maison» avec les tables que je t'ai indiquées, une simple jointure externe te permet de tout récupérer

Par exemple (en reprenant les tables que j'ai données précédemment) pour récupérer les objets d'ID 1 et 2 :

Code :

SELECT
  objets.*,
  objets_i18n.nom aSi18n_nom
FROM  objets
LEFT OUTER JOIN objets_i18n
  ON objets.id = objets_i18n.id
    AND objets_i18n.langue = 'en'
WHERE objets.id IN (1,2)

Résultat:

Code :

id  nom      valeur  i18n_nom
1   couteau  41      knife
2   papier   5       NULL

En compliquant un tout petit peu la requête à coup de IF, tes données deviennent totalement équivalentes à la version sans localisation, la traduction se fait de manière totalement transparente :

Code :

SELECT
  objets.id,
  IF(objets_i18n.nom IS NULL, objets.nom, objets_i18n.nom) AS nom,
  valeur
FROM objets
LEFT OUTER JOIN objets_i18n
  ON objets.id = objets_i18n.id
    AND objets_i18n.langue = 'en'
WHERE objets.id IN (1,2)

Résultat:

Code :

id  nom      valeur
1   knife    41
2   papier   5

Bilan :
- Nombre de requête identique (aucune différence de perf)
- Code final identique (le format des données de sortie ne change pas)

--> Localisation transparente


Et au niveau liberté pour tes joueurs c'est bien plus sympa, au lieu d'avoir deux petites communautés, tu en auras une seule grande, un poil plus pratique tout de même, et bonjour le gain de place par rapport à la duplication des données sur deux bases différentes (sans compte toutes les galères que cette dernière solution pourrait apporter, en particulier le fait de devoir d'un coup vraiment gérer deux sites au lieu d'un seul)

[Sephi-Chan]

Ok pour la jointure c'est comme ça que je le voyais, j'avais sorti mon bouquin SQL pour y réfléchir.

L'idée pour la communauté est LE point qui me tente le plus. Je vais donc tenter comme ça lors du développement de la première version.

En y réfléchissant, j'arrive à un petit listing de ce que je devais internationaliser à même la BdD. Il s'agit toujours du nom, de la description des effets et compagnie :

• Objets,
  
• Compétences,
  
• Altérations d'état,
  
• Quêtes,
  
• Créatures & PNJs.
  

On verra bien ce que ça donne.


Sephi-Chan

[joshua]

tiens j'ai retrouvé le truc que je cherchais. Ca s'appelle gettext.
Je te laisse regarder sur le net ^^

[Nel Morane]

Je pense que je ferrai 1 base pour 1 site.
On finit toujours par se mordre les doigts lorsqu'on duplique des environnements similaires.
Ne serait ce pour les id automatique, les bugs de version, le poids de la base (tout les champs ne seront pas à traduire, mais tous seront dupliqué)...

Alors qu'avec une base, il suffit de créer une table 'traduction' : idMot, Langue, traduction. Et c'est tout, en plus il suffira de compléter la table pour créer autant de traduction que tu voudras.

[zzarbi]

tiens j'ai retrouvé le truc que je cherchais. Ca s'appelle gettext.
Je te laisse regarder sur le net ^^

Gettext c'est pas mal, c'est un module à rajouter à php qui gère des fichier de langue en les "compilant" ce qui est sensé être plus rapide qu'une base de donnée et prendre moins de place en mémoire, ensuite c'est une simple fonction qui te permet de récupérer la traduction d'un mot... Cependant la documentation sur ce module est assez limité... Faut bien chercher...

Enfin j'ai fait différents test pour l'internationalisation sur plusieur façon de stocker et récupérer des données pour les langues...
La méthode consiste à avoir fichier de langue par page/objet (au sens de caractéristique pas objet au sens programmation)/action, ca dépend de comment on veut l'utiliser...
L'architecture ressemblerai à :
-Lang/
|-french.php contient des variables de langue général au site/jeu
|-english.php idem mais en anglais
|--french/ dossier contenant plusieur fichier de langue
|--english/ idem mais en anglais

Ensuite dans chaque fichier on peut utiliser:
- soit define('TITLE', 'Le titre du jeu');
- soit $lang['TITLE'=> 'Le titre du jeu', etc];
- soit $TITLE = 'Le titre du jeu';
- soit on utilise gettext et l'arhitecture du dessu devient inutile evidement

Donc des test sur plusieurs centaine de mots, avec des appels aléatoires (dans le sens ou on prend une donnée au début du tableau $lang, au milieu et à la fin)

Les résultat du plus rapide au plus lent :
- define
- $lang[]
- gettext()
- $TITLE

Je pense que gettext utile moin de mémoire quand même vu que c'est unfichier ou il vire tous les espace inutile etc... et qu'il réduit etc...

Cependant j'ai pu voir bon nombre de developpement se tourné vers define... En tous cas pour toute la partie fixe. Par exemple pour un site ou il y a des catégorie dynamique, le mieux est de faire des jointure sur une table lang Mais pour mon jeu, moi j'utiliserai des define ^^

A noter quand même qu'il y a quelqu'un qui m'a dit (je crois que c'est sur ce forum), que le tableau lang peut être interessant si on modifie la valeur...
Imaginons un "bonjour %s" à stocker aussi en "Hello %s" ou on veut remplacer %s par le nom du joueur, avec les tableaux ou les variables d'ailleurs on pourrait faire le remplacement et le stocker directement dans le tableaux ce qui permettrai de ne plus re faire ce remplacement... Aprés ça reste limité mais ça peut être bien

++

Edit : Les fichier "compilé" par gettext son utilisable avec d'autre langage notament le C et le c++ (gettext étant écrit en c....)

[naholyr]

gettext n'est pas la panacée en PHP, mais il a le mérite d'y exister.
Mais un site web doit pouvoir être éditable rapidement, et les fichiers compilés de gettext ne permettent pas ça. Je le réserve à des utilisations bien spécifiques qu'on voit rarement dans un site web

Mais attention gettext n'est pas seulement bon parce qu'il propose des fichiers compilés, il est bon parce que son format de fichiers source est un excellent choix, parce qu'il offre des fonctionnements standards intéressants pour intégrer des variables dans un texte, et parce qu'il gère les pluriels (par exemple pour traduire "X œufs", si X = 0, on aura du pluriel en Français mais pas en Anglais, gettext permet de formaliser ça).

Enfin de toute façon les tableaux de langue, les fichiers XLIFF, gettext, ou toute autre solution de traduction est bonne pour les intitulés ou les contenus semi-statiques. Mais pour tout ce qui est dynamique (ici les objets de l'univers), c'est quasiment toujours la base de données qui est utilisée.

[Roworll]

De mon coté, je travaille toujours avec mon système XML/XSL que j'ai expliqué ailleurs sur le site.

Petit rappel du fonctionnement :
- Mon code PHP ne génère que du XML
- J'inclus dans ces pages XML le fichier de traduction correspondant à la page en cours
- En fonction du navigateur, soit je fais la transformation XSL en local (Opera) soit je laisse le navigateur se débrouiller (IE/FF)

Accessoirement, le serveur travaille moins car sur FF/IE, la mise en page se fait par XSL sur le poste client.
De plus, le XSL bénéficiant du système de cache sur la machine cliente, il y a économie de bande passante car seule les données XML transitent la plupart du temps (vérifié avec HTTPWatch).
- Une petite démo
- Le fichier XSL
- Fichier XML FR
- Fichier XML EN
Ce système me permet de traduire toutes les données statiques (Menu, éléments de mise en page, etc).

Les données dynamiques (news, forum, etc) sont mises dans une seule base avec un champ pour indiquer la langue utilisée.

[zzarbi]

De mon coté, je travaille toujours avec mon système XML/XSL que j'ai expliqué ailleurs sur le site.

Ca c'est une bonne alternative, mais faut tout faire en XML/XSL faudrat qu'un jour je pense à essayer et intégrer ça