Site multilingue - méthode ?

[khephren]

Bonjour à tous ,

je cherche en ce moment comment je pexu créer un site multilingue. J'ai lu plusieurs articles sur ça comme la méthode d'un dico mais elle me convient très peu.

Enfin j vous explique un peu :

Quand l'internaute arrive sur mon site il a le choix entre plusieurs langues. Après avoir cliquer celle qu'il désire il arrive sur le site traduit dans sa langue. Le problème c'est que c'est des textes entier écrit en différents languages. Je ne sais vraiment pas comment m'y prendre.

J'ai entendu parler des Templates pour des sites multilingues.

J'ai pas envie de créer x pages pour x langues . J'aimerai créer une unique page et suivant la langue choisit l'utilisateur la page va loader les parties ( menus, flash ... ) spécifique au language.

Je sais pas si vous m avez bien compris . Si ce n'est le cas , demandez moi des précisions.

merci de votre aide

[microcongo]

Envoyé par khephren

Bonjour à tous ,




J'ai pas envie de créer x pages pour x langues . J'aimerai créer une unique page et suivant la langue choisit l'utilisateur la page va loader les parties ( menus, flash ... ) spécifique au language.

Les templates ne font pas que ça.

Tu peux plutôt utiliser les bases de données puis tu met des variable sur ta page pour qui

if lang=ça

alors affiche la table x

De la même maière que fonctionne les templates.

[Oluha]

ce pendant je trouve la méthode la la base de donées très lourde si tu as beaucoup de contenu à afficher.
Mais bon, il faut voir aussi si tes données sont mises à jour souvent ou pas.

[microcongo]

Envoyé par Oluha

ce pendant je trouve la méthode la la base de donées très lourde si tu as beaucoup de contenu à afficher.

Tu as raison, il n'y a-t-il pas d'autres solution plus rapide que les base de données

[khayyam90]

bon, deja il va falloir un langage un peu plus evolue que le simple html, mais ca, tout le monde l'avait devine.

a part la base de donnees(lourde) et un grand switch($lang) decrivant la page dans chacune des langues, je ne vois pas grand chose d'autre.

La premiere methode donnera des scripts assez petits mais une base tres (trop) sollicitee. La seconde methode donnera des scripts tres gros ou bien, dans le cas ou l'on preferera dispatcher les infos dans plusieurs fichiers, des petits scripts et plein de fichiers annexes.

[microcongo]

Peut -on utilise rles fichiers textes (.txt) pour stocker les inforations ?

[nic58]

J'utilise un fichier XML par page (ou par module, selon la taille des pages) et par langue.

Donc en gros cela donne:

FR
- accueil.xml
- contacts.xml

EN
- accueil.xml
- contacts.xml


Ensuite, je parse le fichier requis et stocke les couples "clé => valeur" dans un tableau associatif (qui sera ensuite sérialisé : le résultat étant stocker dans un fichier pour faire un cache et gagner en performance).

[khayyam90]

Envoyé par microcongo

Peut -on utilise rles fichiers textes (.txt) pour stocker les inforations ?

absolument, tu peux prendre n'importe quel type de fichiers, meme le type .toto si ca te chante

[Rom_1]

Avec PHP 5 et SQLite, tu peux peut-être avoir les 2 : rapidité d'un fichier (texte simple, BBCode, xml...) et la puisance du SQL.

Il s'agit d'un mini serveur de base de donnée intégré à PHP 5. Toute ta base (dans ton cas, ton site en différentes langues) est stockée dans 1 fichier, et tu y accèdes à travers un moteur de base de donné qui fait partie de PHP, donc beaucoup plus rapide qu'un serveur 'distant'.

Par contre, SQLite ne gère pas les accès concurrents, ce qui veut dire qu'une requête bloquie toute la base pendant qu'elle sexécute. En cas de nombreuses requêtes, ça risque de devenir lourd.

Autre solution (conciliant perfs et praticité) : un script qui génère l'ensemble des pages de la abse de données. Comme ça, tu ne touches qu'à la base, ton script fait un SELECT (fr|en) FROM texts WHERE ... et enregistre le résultat dans du html.
Le serveur n'envoie que du html : aucun temps de traitement. Ca revient à mettre le résultat du script en cache, ce qui est légitime dans la mesure où le site n'est pas vraiment dynamique.

--
Rom_1

[TheMoutch]

Bonjour,

J'utilise PHP4 sur Apache et j'ai choisi pour ma part l'option "dictionnaire". J'ai donc aujourd'hui :
- un répertoire par langue
- un fichier par page du site contenant la traduction de tous les mots de ce fichier sous la forme $var = traduction.

J'aimerais bien rassembler tous ces petits fichiers en un fichier unique pour pouvoir facilement l'envoyer aux traducteurs et éviter les lignes doublons dans la traduction qui sont une grosse perte de temps.

Le fichier complet ferait plusieurs milliers de lignes, donc plusieurs milliers de variables chargées à chaque chargement de page.

Ne connaissant pas bien les histoires de cache, etc.... Je me demandais si cette solution était une bonne idée, ou risquait de ralentir considérablement mon serveur.

Je serais ravi d'avoir vos avis.

Merci beaucoup,

Cordialement,

Raphaël

[speedev]

Salut,

Je m'intéresse à ce sujet, je suis justement en train de réfléchir à un système du genre. De mon côté pour le moment je développe une solution personnelle "XML couplé avec SMARTY (moteur de templates PHP)". Celle-ci est adaptée à mon besoin.

Dans l'idée si ça vous intéresse

Je vais stocker en DB les traductions de manière "légère", une table unique (3 ou 4 champs dont la langue, la page, un libellé (genre "para01") et le texte) et donc aucune jointure. Peut-être (et même surement je pense) que je serai amené à éclaircir cette table en la découpant en deux ou en rajoutant un champ ou deux pour identifier le texte maiiiiis pour l'instant je reste sur cette idée.

Un plugin Smarty me permettera de récupérer l'information désirée qui sera rangée dans un fichier XML.
Un plugin que je m'imagine bêtement simplifié ainsi pour le moment :

Code :

getContent("accueil","para01"); // oui comme dans JS ^^

On lui passe la page en cours, et le code d'identification du texte désiré. Je numéroterai implicitement chaque libellé afin de simplifer l'agencement au niveau du code. Il suffira donc de faire des appels dans l'ordre des textes (de gauche à droite et de haut en bas lol).

TOUS les XML seront générés en une seule fois à chaque mise à jour des données de la DB. Ainsi il s'agira d'un accès fichier. Le plugin pourra, si nécessaire, récupérer les données depuis la DB directement (si c'est pratique) ou depuis le XML lui-même. La gestion de la langue se fera par $_SESSION et celle du type d'accès (fichier ou DB) directement dans le plugin smarty ou bien à l'appel du plugin (moyennant un troisième paramètre initialisé ou non), ça peut être utile pour une donnée mise à jour toutes les n secondes/minutes.

Je vous déballe ça en speed hein...rien n'est analysé encore mais le système me plait bien pour le moment.
J'en déduis ceci :

AVANTAGES :
- Code dépouillé, dépourvu de textes, chaque texte = getContent("aa","bb")
- Choix XML propre, j'aime bien le XML, c'est structuré et facile à lire et relire.
- Accès fichier ou accès DB en cas de soucis de l'un ou l'autre.
- Je peux ainsi proposer un système à la "wikipédia" ou quiconque disposant d'un droit pourra traduire toutes les pages du site. Moyennant un petit accès réservé et une pré-validation de saisie.<== C'est surtout ça qui m'intéresse dans l'idée à vrai dire, que ceux qui veulent puissent participer aux traductions.
- Interface d'administration complètement envisageable.

INCONVENIENTS :
- Textes non accessibles dans le code (on peut lire les xml cela dit)
- Omniprésence des appels du plugin (plusieurs getContent() dans le code) peut être gênante. De mon côté je ne pense pas que ça me gênera si je suis clair dans ma tête et que tout est bien numéroté dans l'ordre.
- Dans le cas d'un plantage de la DB les XML sont éventuellement faciles à maintenir si on veut rajouter du texte. Seulement après il faut prévoir une réintégration dans la base, rien de gênant en fait...
- SMARTY EST UN MOTEUR DE TEMPLATES : bah oui, smarty est fait pour ça en partie, pour avoir plusieurs templates!!...mais ce n'est pas de cette utilité là dont je me sers chez lui. Je génère plusieurs templates de design et de mise en forme et non pas de données!! Mais ça peut en faire râler quelques uns...

Voilà c'est en cours de réflexion et d'optimisation...je verrai ce que ça donne! Mais pour le moment je suis sûr que ça me plaira!

Bonne journée!