{Site multiLingue} Meilleur moyen de stockage pour les clés de langues

[pierrehs]

Bonjour,
Je vais commencer un 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.

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

[Fabllot]

Bonjour,

Beaucoup de CMS emploient des tableaux array (mais je pense ça un peux lourd ?)

Pas plus qu'une autre méthode.

Joomla utilise des fichiers .ini (peut-être que les fichiers .ini sont pus rapides de les tableaux PHP ?)

Pour les fichiers ini, ça dépend de comment est fait le parsing, pour le xml, je déconseillerais justement à cause du parsing qui est plus lourd...
ou en fichier .xml

et encore dans une base de données (ce que je pense être le plus lourd)

Si c'est des traductions d'éléments de la base non, car tu récupères tes traductions en même temps que les valeurs dans une même requête.

Nous de manière plus basique, on utilise à la fois des traductions en base de données, quand il s'agit de traduire des éléments de la base, et pour les textes mêmes des sites webs, un fichier php par langue (lang_fr.php, lang_en.php, etc...) où sont définies des variables globales pour chaque texte...

Après toutes les méthodes ont des avantages et inconvénients... A toi de voir selon tes besoins et contraintes spécifiques, quelle est la meilleure (ou moins pire) solution.

[grunk]

J'utilise gettext pour plusieurs raisons :

- Extrêmement facile à traduire pour des non informaticien grace au soft type poedit.

- Traduction mise en cache automatiquement par Apache (c'est par contre pénalisant en développement)

- Très lisible dans le code :

Code :

echo _('ceci est mon texte en français');

- Supporter par le moteur de template que j'utilise (Twig)

- Solution performante et éprouvée

Envoyé par Fabllot

Pas plus qu'une autre méthode.

Justement si , car avec les tableaux tu vas charger en mémoire beaucoup de variable pas forcément utilisée; idem pour les fichier avec des globals. Alors que les autres solutions sont bien plus précise.

[Fabllot]

Envoyé par grunk

Justement si , car avec les tableaux tu vas charger en mémoire beaucoup de variable pas forcément utilisée; idem pour les fichier avec des globals. Alors que les autres solutions sont bien plus précise.

Pardon, effectivement je n'était pas clair. Je prenais le "lourd" de manière plus générale... "lourd en mémoire" mais aussi "lourd en traitement"...
Si les variables et tableaux sont plus lourds en mémoire, les fichiers xml, ini, les bases de données vont être plus "lourdes" en traitement suivant les cas.
Je ne connais pas gettext, donc je ne pourrais émettre un avis dessus, cependant, quelque soit la méthode il y a un juste milieu mémoire/traitement à trouver. Pour gettext il faut voir si justement cela n'encombre pas trop Apache ou quelles sont les situations optimales pour l'utiliser.

Je regarderai cela pour mon prochain site !

[grunk]

Gettext travail avec un fichier compiler contenant un index des traduction disponible.
Donc un appel du type

Code :

_('texte à traduire');

- Ouvre le bon fichier en fonction de la langue
- Cherche dans l'index 'texte à traduire'
- Affiche la valeur associé à cette clé.

L'un des gros avantage de gettext c'est que tu n'as pas besoin de construire le fichier de langue au fur et à mesure. Il existe un outils qui va venir parser tous tes fichiers et extraire les chaines à traduire pour construire le premier fichier de langue.

En revanche gettext est assez contraignant à utiliser au départ car il nécessite quelques prérequis pour fonctionner. Si on ne les a pas , c'est la galère.

Un article qui compare plusieurs façon de faire : http://insidetags.com/php/techniques-site-multilingue/

[stealth35]

Y'a aussi les .res d'ICU mais c'est pas encore très implémenté dans le monde de PHP (extension Intl), ça te permet d'avoir les mêmes fichiers de trad 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/...e.adapter.html
http://trac.symfony-project.org/wiki...ook/trunk/i18n

[pierrehs]

Merci beaucoup pour vos réponses
@grunk est-ce que Gettext support-il aussi Smarty (puisque c'est ce moteur de template que j'utilise)
Et avez-vous une idée si la plupart des hébergeurs mutualisés activent gettex dans le php.ini ?

[ABCIWEB]

Envoyé par pierrehs

Et avez-vous une idée si la plupart des hébergeurs mutualisés activent gettex dans le php.ini ?

gettex est la solution la moins portable bien que très performante.


EDIT :

Sinon, pour des petits projets, la solution des tableaux est performante (et pas lourde si ton code est optimisé).

La traduction en bdd est aussi très performante si tu utilise la bdd par ailleurs pour ton application. Niveau backoffice la seule petite limitation que j'ai constaté pour la traduction vient du fait que le nombre de post d'un formulaire est limité à environ 200 (réglage standard sur un mutualisé). Mais bon ça limite juste le nombre de lignes à traduire à 200 pour chaque envoi du formulaire de traduction, ce qui n'est pas vraiment gênant.

[grunk]

@grunk est-ce que Gettext support-il aussi Smarty (puisque c'est ce moteur de template que j'utilise)

C'est smarty qui doit supporter gettext et pas l'inverse

Il existe un plugin pour : http://smarty.incutio.com/?page=SmartyGettext