Forum d'entraide PHPFrance

Bonjour à tous
Je vais commencer un projet de site multilingue et donc je me demande quel moyen est le plus performant, le plus rapide et le plus facile pour les traducteurs à traduire le site.

Je sais que beaucoup de CMS emploient des tableaux array (mais je pense ça un peux lourd ?)
D'autres comme Wordpress et Drupal utilisent je pense GetText
Joomla utilise des fichiers .ini (peut-être que les fichiers .ini sont pus rapides de les tableaux PHP ?)
ou en fichier .xml et encore dans une base de données (ce que je pense être le plus lourd)
Avez-vous des conseilles dans le choix ?
et qu'utilisez-vous ?
Merci d'avance

Ton fichier ini sera dans tous les cas parsé dans un array.
Le XML aussi, c'est soit de l'array soit de l'objet.

Pour ma part je ne te conseillerai pas l'un ou l'autre, car pour moi cela se vaut, mais je te déconseille tout de même grandement la bdd.

Ok,
Donc le mieux est les array en PHP puisque les fichiers .ini et xml reviennent presque à la même chose ?
Connaissez-vous GetText ?

Pour ma part je ne te conseillerai pas l'un ou l'autre, car pour moi cela se vaut, mais je te déconseille tout de même grandement la bdd.

Faut pas déconseiller la bdd car cela peut être très optimisé, pratique et efficace si l'on prend le temps de réfléchir au développement et au schéma des tables. Et c'est même très pratique à l'utilisation si tout le contenu du site - contenu des pages, ajout ou suppression de rubrique et de pages, etc. - doit être gérer depuis le site lui-même.

Par exemple ce site multilingue (entièrement administrable) a été réalisé uniquement avec une bdd et cependant les outils google indiquent qu'il est plus rapide à l'affichage que 78% des sites (toutes catégories confondues, sites mono langue et sites statiques compris). Et en plus des trois langues affichées, il y en a deux autres de plus qui sont traduites en bdd (langues polonaise et russe en attente d'affichage car le client à décidé de limiter pour l'instant la diffusion de ses produits).

Maintenant je ne dis pas non plus que c'est la seule bonne méthode (demande du travail), mais il me paraît un peu rapide de l'éliminer d'emblée d'autant plus qu'elle peut passer partout, contrairement à un GetText par exemple.

Concernant les CMS "tout fait" j'ai entendu dire il y a quelques temps que Wordpress gérait assez mal le multi langue (apparemment son seul défaut) mais peut-être cela a évolué depuis. Pour les autres je ne sais pas.

Oui comme tu le dis AB c'est surtout une question d'utilisation.
Pour ma part on m'a appris qu'il ne fallait pas utiliser un stockage en bdd pour une donnée statique (exemple tout bête pour illustrer : stocker un menu HTML dans une table, cela n'a aucun sens...).
Or les traductions ne sont pas sujettes à être changées tous les jours, à la rigueur un ajout de nouvelles mais cela ne justifie selon moi aucunement l'utilisation d'une bdd.

Y'a aussi les .res d'ICU mais c'est pas encore très implante dans le monde de PHP (extension Intl), ça te permet d'avoir les mêmes fichiers de trad pour que Java,C, C++
tu peux en plus utiliser le format XLIFF (qui est lisible par Symfony et le Zend Framework aussi)

http://www.php.net/manual/fr/resourcebundle.create.php
http://userguide.icu-project.org/locale/localizing
http://framework.zend.com/manual/en/zen ... apter.html
http://trac.symfony-project.org/wiki/Do ... trunk/i18n

Oui comme tu le dis AB c'est surtout une question d'utilisation.
Pour ma part on m'a appris qu'il ne fallait pas utiliser un stockage en bdd pour une donnée statique (exemple tout bête pour illustrer : stocker un menu HTML dans une table, cela n'a aucun sens...).
Or les traductions ne sont pas sujettes à être changées tous les jours, à la rigueur un ajout de nouvelles mais cela ne justifie selon moi aucunement l'utilisation d'une bdd.

Evidemment je parle pour un site avec CMS. Et dans le cas d'un CMS fonctionnel il doit n'y avoir aucune limitation (ou le moins possible) concernant la modification, ou l'organisation des menus et du contenu.

Or si je reprend l'exemple de ce site, le menu des pages est différent suivant la langue choisie (la page "crédit d'impôt" ne concernant que le système français, elle n'existe pas dans les autres langues) et sur le même principe certaines rubriques de produits peuvent ne pas apparaître dans certaines langues car tous les produits ne sont pas destinés à l'exportation. Par ailleurs chaque page peut être déplacée à tout moment dans une rubrique de page, ou dans le pied de page, l'ordre d'affichage des pages est également paramétrable dans les menus et les sous-menus, et l'espace "Distributeur" fait apparaître de nouvelles pages dédiées etc.
Tout ça pour dire que l'utilisation d'une bdd étant nécessaire pour gérer le système d'affichage et de droits, je ne vois pas en quoi ça me gênerait de faire une jointure pour rapatrier la langue à traduire en même temps que je fais la requête sur les menus C'est le contraire qui serait lourd.

Maintenant pour un site statique, évidemment on va pas créer une bdd pour faire la traduction. Faut juste s'adapter aux moyens qu'on utilise. Mais si l'on utilise abondamment la bdd pour tout gérer ce n'est pas une hérésie de l'utiliser aussi pour les traductions car cela peut apporter des facilités pour l'administrateur sans ralentir les performances d'affichage du site