Discussion :

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Et les classe seraient par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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