Application PHP multilingue (interface et contenu)

[TribalDev]

Bonsoir,

Je suis en phase d'analyse sur la conception d'un site multi-lignue, pour une application PHP/MySQL.
Et nombreuses sont du coup les questions qui me viennent à l'esprit, tant dans un soucis de rapidité de traitement des données que de maintenance des contenus.

J'ai le sentiment qu'il serait judicieux de coupler deux techniques pour développer un site multilingue, l'une pour l'interface "statique" (menus, boutons, ...), l'une pour les contenus dynamiques (description de produits, ...)

Pour l'heure, avec des connaissances basiques qui évoluent au fil des lectures, j'ai pensé à deux systèmes :

• gettext pour toute la gestion de l'interface de l'appli (ce qui ne sera pas amené à évoluer)
• XML, pour stocker les intitulés de produits, de catégories de produit, ... (ce qui sera amené à changer au fil du temps)

Parallèlement à cela, j'ai une base MySQL, donc je me demandais quel serait le choix le plus judicieux. MySQL me semble peu judicieux pour gérer diverses langues. Cela étant MySQL conserverait cependant toutes les données concernant ces fameux produits, seul leur libellé serait présent dans le XML, en différentes langues.

• Cette approche (gettext + XML) semble-t-elle intelligente ?
• Auriez-vous des idées plus intéressantes ? (plus rapide en accès aux données, en maintien, etc ?)
• Une idée éventuelle de la manière de structurer les données dans XML ? (un noeud langue avec description de tous les produits ? ou des noeuds produits avec description par langue ? ou autre ?)

Je me demandais si récupérer le XML complet via PHP (& dom, à coups de XPath par la suite pour récupérer les traductions) n'est pas trop gourmand ?

Réelle envie de discuter de cela, pour parfaire mon approche.
Merci bien !

[zyongh]

Les objets étant plus rapides et moins gourmands que les tableaux ou les fichier XML via XPath (ou autre), la première idée qui me vient à l'esprit est l'utilisation d'une classe par langue dans laquelle tu déclares des variables publiques et statiques (qui ne peuvent donc être changées). Tu peux également mettre la classe en final (aucune autre classe ne peut en hériter).

Ensuite, pour peu que ton site soit programmé en MVC, tu place dans ton index.php une variable de session avec la langue par défaut si la variable de session n'est pas définie ou la langue sélectionnée par l'utilisateur.

Puis tu appelles les textes statiques ou les images de la façon suivante:

Code :

1
2
3
 
$oTxt = new $_SESSION['langue'];
echo $oTxt->textAccueil;

Et les classe seraient par exemple:

Code :

1
2
3
4
5
6
7
final class French {
    public $testAccueil = 'Bienvenue';
}
 
final class English {
    public $textAccueil = 'Welcome';
}

En espérant avoir pu t'aider (ainsi que d'autres peut-être)

[TribalDev]

Bonsoir,

Et merci pour cette première réponse.
Au final, aucune de mes idées étaient donc judicieuses, niveau rapidité si j'ai bien compris.

Cela étant, dans un soucis de maintenabilité, l'idée d'instancier une classe et recourir à des assesseurs pour obtenir les traductions, à partir du nom de variables qui sont une nouvelle fois une "traduction casse pascal" des données à afficher c'est sensiblement perturbant et peu pratique pour des mises à jour quelconques et s'y retrouver facilement je trouve.

Le principe de gettext ( echo _('Une phrase en langage par défaut'); ) est intéressant à ce niveau là, et pour les traductions des outils fort pratique existe (pour dériver les fichiers dans d'autres langues).

je suis tout ouïe si tu veux me donner un avis sur cela, et avoir si possible l'avis d'autres personnes pour confronter un peu tout ceci.

Merci en tout cas !

[zyongh]

PHP fait aussi l'écriture/lecture de fichiers. Donc pour la maintenance, rien de plus simple, juste un peu plus à programmer.

Tu fais un back-office avec un formulaire HTML qui te permet de rechercher dans toutes les classes de langues une variable précise et d'afficher pour chaque langue le contenu de la variable dans un formulaire avec un textarea pour chaque langue, ce qui fait que tu as toutes les traduction pour le même texte sur le même formulaire HTML et ce dans la même page HTML.

Tu apportes les modifications et tu valide et tu traites le formulaire afin de modifier dans les classes (modification des fichiers PHP) la variable modifiées via le formulaire HTML.

Suis-je bien clair ?

[TribalDev]

Bonjour,

Oui parfaitement clair, je vois parfaitement ce dont tu veux parler, merci.

En ce qui concerne l'interface (plutôt figée) de l'application, je trouve que la méthode est bonne, du moins aisée à mettre en place.

Mais pour les données amenées à évoluer, si l'on reste dans l'esprit d'une gestion de catégorie (et sous-categ illimitée) de produits et produits, ça invite lors d'ajout/suppression/modification à regénérer dynamiquement le fichier de la classe (qui peut être "include()" dans la page du backoffice à ce moment) avec des variables de types "desc_categ_X", "desc_pdt_X", ..., tant pour l'intitulé, que pour la description, des conditions diverses liées au produit, etc)

Une page intéressante au passage, avec un benchmark gettext-php, gettext, string ID : benchmarking-php-localization-is-gettext-fast-enough/

Ils n'ont fait de tests ni avec de l'objet ni avec XML, mais je partirais du principe que ce premier est plus rapide que ce second comme tu le spécifiais dans ton 1er post.

[SphynXz]

Personellement quand j'ai pour projet de réaliser un site multilingue, je me base sur les constantes

en base de données une table Langue, avec un code pays.

-Pour chaque code pays un repertoire dans ton /www

-un url rewriting por traduire une url du style : www.developpez.net/en/ en ?langue=en

et on inclut le bon fichier langue

tu traite la superglobal $_get['langue'] et les require iront chercher les bon fichier de langues

un fichier de langue sera de la forme suivante :

define('BJR','Hello!!!!!!!!!!!!!!!!!!!!!');

et coté affichage un petit echo BJR , ou echo bjr si tu fais tes define comme ceci :

define('BJR','Hello!!!!!!!!!!!!!!!!!!!!!', TRUE); rendant la casse insensible (déconseillé)

Voilà ce n'est qu'une manière en plus de fonctionner

[zyongh]

Je faisais comme cela auparavant, jusqu'au jour où j'ai testé mon site avec Xdebug et là... j'ai connu la pire constatation. Quand tu appelles le fichier, toutes tes variables sont définies et donc placées en mémoire, imagine la place quand tu as plusieurs centaines de constantes !!!!

Alors qu'en fonctionnant avec les classes, seules les variables appelées par l'objet sont placées en mémoire, d'où gain de temps et gain de place en mémoire.

[grunk]

Envoyé par david drapeau

Je faisais comme cela auparavant, jusqu'au jour où j'ai testé mon site avec Xdebug et là... j'ai connu la pire constatation. Quand tu appelles le fichier, toutes tes variables sont définies et donc placées en mémoire, imagine la place quand tu as plusieurs centaines de constantes !!!!

Alors qu'en fonctionnant avec les classes, seules les variables appelées par l'objet sont placées en mémoire, d'où gain de temps et gain de place en mémoire.

Je fait comme ca aussi , mais à la place des define j'utilise un tableau du genre :

$lang_menu = array(
'home'=>'acceuil',
'lab1'=>'label1',
...
...
);

Du coup dans chaque dossier langue j'ai plusieurs fichier comportant un ou plusieurs tableau de langue.

Pour ce qui est des classe , je vois pas l'intérêt d'écrire une classe si c'est pour n'y placer que des attributs. Après si c'est pour rester dans une logique tout objet pourquoi pas.

Pour en revenir au problème de TribalDev , tout les texte fixe sont à mon avis à placer dans un ficheir de langue comme ca déjà été dis.
Pour les texte dynamique c'est plus délicats. En effet si tu n'as que deux langue et quelques item , tu peut te permettre de doublé les champs de ta bdd.
Par exemple un titre , deviendra titre_fr et tire_en par exemple. En revanche niveau évolutivité c'est pas top je pense.

[zyongh]

Envoyé par grunk

Je fait comme ca aussi , mais à la place des define j'utilise un tableau du genre :

$lang_menu = array(
'home'=>'acceuil',
'lab1'=>'label1',
...
...
);

Ce qui revient au même que d'utiliser des define() dans le sens où la totalité de ton tableau est appelé en mémoire. Alors qu'avec un objet seul la variable nécessaire est appelée en mémoire. Teste ta façon de faire avec Xdebug et tu vas voir ce que ça donne. Tu vas vraiment être surpris.

[TribalDev]

Merci pour vos réponses respectives.

Stockage en base de données ça m'intéresse peu (j'aspire à essayer de "penser flexible" au maximum).

L'objet étant plus rapide que les tableaux c'est ce vers quoi je me dirigerai si je ne trouve pas une Xème alternative plus satisfaisante (dont je viendrais faire part si ça ne tarde pas)

- gettext pour la partie interface pour l'heure !

Merci pour vos avis, et si d'autres personnes sont emballées pour partager leur vécu à nouveau je reste tout ouïe

[zyongh]

Je ne vois aucune utilité à utiliser gettext() si tu choisis la méthode objet et réciproquement. Les deux méthodologies sont totalement différentes.

[eilijah]

Bonsoir,

J'aurais voulu savoir si cette approche multilingue par classes etait viable pour des site avec beaucoup d'info traduite (genre wikipedia)?

ca me parait un peu bizar de faire 1 fichier fr.class.php pour 1000 pages de wiki !

quel genre de systeme adopter pour ce genre de projet?

J'espere que vous pardonnerez la naiveté de ma question mais j'avoue que je rame entre tous les moyen dispo pour faire un site multilingue.

[Rizzen]

Si tu regarde les sources d'un forum comme phpBB, tu verras qu'il utilise des fichiers pour définir des constantes comme explique SphynXz. Je trouve cette solution très pratique et rapides à modifier ou pour ajouter des données ou encore pour les traductions.

Pour le problèmes d'espaces mémoires relevé, tu peux découper ton fichier en plusieurs plus petits et appeler uniquement la partie utile. Cela évite de charger trop de données. Ensuite tu fais les require nécessaire pour utiliser le fichier.

De plus en écrivant tes constantes en majuscule elle sont assez repérable dans le code et celui-ci reste assez lisible. Et quelqu'un de nom développeur aura plus de facilité à modifier les données que modifier dans une classe.