salut à tous,

Je suis entrain de faire un site mutilingue. Je ne sais pas si la méthode que j'utilise est la bonne. pouvez-vous me donner votre avis.

j'ai une page index.htm contenant les liens suivants:

Fr Eng Nl
Lorsque l'utilisateur clique sur Fr les fichiers suivants sont utilisés:
Page1_fr,Page2_fr.....

Lorsque l'utilisateur clique sur Eng les fichiers suivants sont utlisés:
page1_eng.htm,Page2_eng.htm.....

Idem pour Nl

de tel sorte que j'ai trop de fichiers. Y -a- t-il une méthode plus simple.

Bien à vous

Tu es sur le forum de PHPFrance...
PHP est un langage dynamique...
PHP est un langage qui communique très bien avec MySQL...
MySQL est une base de données...

Je continue ou tu as compris ?

je n'ai pas compris pourquoi tu dis cela.

À la seule exception du texte que tu y affiches,
les 3 exemplaires de tes pages sont identiques : structure, images, objets, css, etc.

Faire chaque page en 3 exemplaires (français, rosbif et gebruik)
est une perte de temps, comme tu l'as d'ailleurs deviné.

L'idée est la suivante :

• crée tes pages en PHP contenant la strucuture, les images,... sauf les textes !
• crée une table dans MySQL avec 4 champs : num, fr, en et nl
• à chaque endroit où tu as besoin d'afficher un texte dans une des 3 langues,
  affiche la donnée enregistrée dans ta BD.

merci pour les conseils. Je me mets au travail

Ce que te suggères Albat par l'entremise de messages subliminaux que certains diront évident (ceci parce qu'ils sont tombés dans la marmitte de code quand ils étaient petits), c'est de restreindre ton code à un seul fichier à chaque fois, et d'aller chercher dans une base de données les libellés dont tu as besoin, dans la langue dans laquelle tu en as besoin

Tu n'aurais ainsi qu'un seul fichier à modifier quand tu fais une évolution au lieu de la faire en 3 exemplaire, et tu pourras gérer les traductions des libellés facilement dans ta table.

Personnellement je penche plus pour un fichier include par langue avec les libellés dont tu as besoin, c'est un peu plus rapide à exécuter, mais c'est aussi un peu moins simple à maintenir ou à modifier

ceci parce qu'ils sont tombés dans la marmitte de code quand ils étaient petits

Et pourtant, on en reprend régulièrement...

Personnellement je penche plus pour un fichier include par langue avec les libellés dont tu as besoin,
c'est un peu plus rapide à exécuter, mais c'est aussi un peu moins simple à maintenir ou à modifier

Serait-ce la solution proposée par PHPdebutant ?
http://phpdebutant.org/article107.php

Et pourtant, on en reprend régulièrement...

Ah ben tant que la température est bonne, on a pas de raison d'en sortir

Pour la solution, ouep, c'est la même idée.. sauf que je fais pas ça avec des cookies mais avec une session, pis que j'utilise de simples variables, mais les constantes ne sont pas une mauvaise idée... ça permet de les utiliser dans des fonctions sans avoir à mettre une tonne de global au début

Ceci dit, ça implique donc 3 à n fichiers à modifier pour insérer un nouveau libellé, contre une ligne à insérer dans une base... donc faut essayer d'estimer la quantité de modification qui auront lieu et voir ce qui est le plus interessant
Dans les deux cas, l'ajout d'une nouvelle langue se fait simplement, une colonne supplémentaire d'un côté, un fichier de l'autre...

Bonjour,

Il y a QQ temps j'avais fait un squelette pour une internationalisation.

Je suis parti sur l'idée de faciliter l'évolution (sans avoir à toucher à la structure de la base)
Je suis parti sur deux tables et une relation

Et le source de création des tables

CREATE TABLE zonesHTML (
  id_zone VARCHAR(30) NOT NULL COMMENT 'Correspond a l''id HTML',
  desc_zone VARCHAR(255) NULL COMMENT 'Description de la zone',
  PRIMARY KEY(id_zone)
)
ENGINE=InnoDB;

CREATE TABLE langues (
  code_lang VARCHAR(3) NOT NULL COMMENT 'Selon la norme ISO 3166-1 A3',
  langue VARCHAR(50) NULL,
  drapeau VARCHAR(255) NULL COMMENT 'Chemin du fichier, nom image idem code_lang.gif',
  PRIMARY KEY(code_lang)
)
ENGINE=InnoDB;

CREATE TABLE contenus (
  id_zone VARCHAR(30) NOT NULL,
  code_lang VARCHAR(3) NOT NULL,
  contenu LONGTEXT NULL COMMENT 'Texte dans la langue pour cet id',
  PRIMARY KEY(id_zone, code_lang),
  FOREIGN KEY(id_zone)
    REFERENCES zonesHTML(id_zone)
      ON DELETE NO ACTION
      ON UPDATE NO ACTION,
  FOREIGN KEY(code_lang)
    REFERENCES langues(code_lang)
      ON DELETE NO ACTION
      ON UPDATE NO ACTION
)
ENGINE=InnoDB;

Il y avait une autre partie qui associait les pays et les langues pour proposer en tête de liste des langues celle(s) parlées dans le pays, mais c'est pas le propos du post.

Bonjour,

Comme l'a si bien expliqué Cyruss dans son magnifique bouquin, c'est vrai que les constantes restent une excellente solution pour faire un site multilingue, avec un include et des cookies.

Passer par une bdd, ca reste lourd et fastidieux je pense...

Enfin voilà ^^

ça peut être vrai dans le cas d'une information statique et de menus d'action dans une page Web mais pas dans le cas d'information dynamique issue d'une base de données identifiant des données métier.

Exemple, quand il s'agit de traduire les options d'un menu comme "contactez-nous", "Accueil", "qui-sommes-nous?", .... ou le texte figé dans une page Web, le plus simple est de prévoir la traduction dans des constantes ou fichiers à charger selon la langue choisie : l'accès est rapide car le premier (constantes) est réalisé dans la RAM du serveur et l'autre (fichiers) via le système de fichiers.
Par contre, s'il s'agit de traduction de données métier : un catalogue de produit par exemple, celui-ci est situé dans une base de données, la traduction aussi, l'accès SQL serveur Web/SGBD est inévitable.