Architecture d'un site multilingue - Bonnes pratiques ?
Bonjour,
Je dois réaliser pour un ami programmeur un petit site pour présenter ses programmes (classés en différentes catégories. Par programme : une fiche, des captures et téléchargements + éventuelle partie "communautaire", commentaires, forum, etc). Le but est un truc qui reste simple, donc exit frameworks, cms, etc, mais multilingue.
N'ayant jamais été confronté en pratique à la réalisation d'un site multi-lingue, avant de me lancer dans la tâche, j'aurais aimé avoir vos retours d'expérience, et vos points de vue sur quelques idées que je vais développer ci-après.
Tout d'abord, au niveau du php (quelques "squelettes" [pas de templates type smarty, php simple, éventuellement converti en pages statiques mise à jour seulement lors des modifications], + formulaires, etc.), je pensais m'orienter vers une solution de type gettext. Problème éventuels :
- gettext pas forcément présent sur tous les hébergeurs (hébergeur indéterminé pour le moment),
- peut-être pertes au niveau des performances (je n'ai pas encore évalué ce point),
- si je souhaite laisser à l'administrateur la possibilité de modifier certains intitulés, cela risque d'être difficile d'automatiser tout ça à cause des fichiers .po/.mo
Peut-être est-ce envisageable vu que le site reste à une échelle modeste de séparer les squelettes par langue :
- problème de la redondance éventuelle, peu satisfaisante,
- conséquence directe : mise à jour des gabarits doit se faire sur tous, possibilités d'oublis, cochonneries résiduelles, etc.
Un autre problème se pose également, celui du fallback vers une langue par défaut en cas de traduction manquante, car toutes les traductions ne seront pas effectuées de concert. Y-a-t-il des gens qui ont eu à traiter ce cas en pratique ?
Côté SQL maintenant, il y a plusieurs façons d'envisager la chose :
- doubler les champs dans les tables (façon text_fr, text_en, etc.),
- conserver un seul champ, mais avec un balisage particulier (ou un array serializé),
- sortir les textes de la table avec les tables de liens qui vont bien.
La première méthode, simple à implémenter, peu couteuse en ressources BDD et PHP, me semble toutefois assez peu satisfaisante en termes de structure de données. Problèmes également de l'ajout/suppr. de langues, et du fallback évoqué plus haut (à moins que ce soit possible en SQL..).
La seconde me semble la plus raisonnable, mais peut introduire des pertes de performances au niveau SQL,
La troisième quant à elle déporte le traitement vers PHP (qui peut rester léger dans le cas d'une sérialisation), mais au final, les données sont plus obscures, et dans l'éventuel cas d'un changement de langage, introduiraient un travail de portage un peu plus pénible).
Voilà un peu ce qui me préoccupe en ce moment. Je vous serai très reconnaissant de commenter ces problématiques du point de vue de votre expérience. N'hésitez pas à me reprendre où à me suggérer des choses auxquelles je n'ai pas pensé, je préfère envisager un maximum de cas avant de me retrouver bloqué par un choix structurel défaillant. Merci d'avance.
