Page 1 sur 1

Site multilangue

Posté : 21 juil. 2008, 16:22
par bio-azar
Bonjour,

Je suis en train de faire un site multilingue (Allemand, Espagnole, Anglais, français et Chinois) , je voudrais stocké mon contenu dans une base de donnée.

J'aimerais savoir si cela est possible, et si oui quel jeu de caractère sélectionner (UTF-8 ?).
Puis je mettre toutes les langues dans une même table?

Voila je sais pas trop si c'est comme cela que l'on fait, et surtout si c'est faisable comme cela.

Je vous remercie par avance.

Guillaume

Posté : 21 juil. 2008, 19:22
par Patriboom
Pour ma part, j'avais opté pour des fichiers texte avec des variables. Ça ressemblait davantage aux programmes que j'utilisais. C'est un peu fastidieux à gérer, mais si tu prends la peine de faire lire toutes les variables dans une langue (par défaut), tu n'as pas vraiment à te soucier que ce la langue de l'usager soit prête à l'emploi ou non, la variable ayant été déifinie, il n'y pas d'erreur provoquée. Je classai mes fichiers d'interface usager (différentes langues) dans un sous-réprtoire nommé langue dans lequel on trouve des sous-sous-répertoire aux codes des langues désignées. Les pages, dans ces sous-sous répertoires portent les mêmes noms que les pages qui les appellent et le utilisent. Ainsi, la page banane.php en français trouve son contenu texte dans le document /langue/fr/banane.php, en anglais dans /langue/en/banane.php Il suffit alors d'avoir un petit script inclus en début de chaque page qui fait lire la langue par défaut (langue/fr/banane.php), puis la langue de l'usager et le tour est joué. Ce-dit script peut être appelé automatiquement pour toutes les pages, simplement parce qu'il porte le même nom que la page ( $_SERVER['PHP_SELF'] )

Si je le faisais avec une BdD, j'aurais une table spécifique pour l'interface linguistique. Dans cette table, j'aurais les champs suivants:
id
nom_page (une zone texte où noter les principales pages utlisant ces textes)
fr
en
es
ch (c'est quoi le code du chinois?)
timestamp (pour garder en note la date de la mise à jour)

Il suffirait alors de l'exploiter en fonction d'un code langue choisi par l'usager et utilisé avec mysql_fetch_array
$ContenuLinguistique[$ChxLng]

Posté : 21 juil. 2008, 20:34
par chrislabricole
Moi je ferais un fichier langue que j'inclurai en fonction de la langue choisie, genre :

un répertoire langues, et dans ce répertoire :
fr.php, en.php, es.php, cn.php, de.php

Et dans chaque fichier, des variables :
pour le fichier FR:
$LANG['bienvenue'] = "Bienvenue !";
ES :
$LANG['bienvenue'] = "¡Hola!";
EN :
$LANG['bienvenue'] = "Hello !";
etc etc...

Et dans ton fichier index.php, tu inclus une de tes langues, et comme les variables on le même nom dans chaque fichier, alors tu pourras faire un
<?php echo $LANG['bienvenue']; ?>
qui va t'afficher donc le mot (ou le texte) correspondant :)

Posté : 21 juil. 2008, 23:12
par MainMa
D'une manière générale, je dirai qu'il y a trois façons de faire la chose (du moins, les trois les plus courants) :
  • - En codant la chose directement dans un fichier PHP.
    - En mettant les chaînes de caractères dans un fichier à part, type INI ou XML.
    - En utilisant une base de données.
A voir les langues que tu comptes utiliser (à savoir surtout le chinois), la première solution n'est pas envisageable, vu qu'un fichier .php avec les caractères unicode, c'est un peu... :roll:

Pareil pour INI, c'est pas très bien lorsqu'il est question d'unicode. En revanche, ça peut marcher, je pense, avec un XML. L'avantage, ensuite, c'est que c'est facilement gérable, et tu peux définir la structure qui te convient le mieux à ton XML (à savoir, soit un élément avec les différents langues, ou bien inversement un élément pour chaque langue...).

Finalement, la version SQL me semble être la plus raisonnable. C'est, a priori, plus rapide que de lire à chaque fois un fichier XML ; de plus, c'est facilement gérable par la suite. Quant à ta question concernant l'encodage à sélectionner, s'il y a UTF-8, c'est bon.

Si je le faisais avec une BdD, j'aurais une table spécifique pour l'interface linguistique. Dans cette table, j'aurais les champs suivants:
id
nom_page (une zone texte où noter les principales pages utlisant ces textes)
fr
en
es
ch (c'est quoi le code du chinois?)
timestamp (pour garder en note la date de la mise à jour)

Il suffirait alors de l'exploiter en fonction d'un code langue choisi par l'usager et utilisé avec mysql_fetch_array
$ContenuLinguistique[$ChxLng]
Je doute que c'est la meilleure solution ; je conseillerai plutôt le tableau avec les champs :
  • - id (PRMARY)
    - language (VARCHAR(5))
    - body (TEXT) ou (VARCHAR...)
L'avantage, c'est que, déjà, si on doit changer ou ajouter une langue, c'est plus facile de faire et on a pas à changer la structure du tableau par la suite ; en plus, le même site n'a pas forcement les mêmes chaines de caractères en toutes les langues. (Exemple : la mention CNIL en chinois, j'vois pas trop l'intérêt. :wink: ) Et finalement, c'est plus élégant d'avoir la langue en WHERE plutôt qu'en nom de colonne d'un tableau (par exemple, si on retire les chaines de caractères avec une stored procedure, c'est vraiment moche de passer le nom de colonne en paramètre de la procédure).

Posté : 21 juil. 2008, 23:22
par Sékiltoyai
Exemple : la mention CNIL en chinois, j'vois pas trop l'intérêt. :wink:
Que tu voies l'intérêt ou non de la mettre en chinois tu n'as pas le choix, si tu es obligé de la mettre en français, tu es obligé de la mettre en chinois. La langue ne rentre à aucun moment dans les conditions d'application de la loi…

Posté : 22 juil. 2008, 01:03
par MainMa
C'est pas faux. Bon. L'exemple était mauvais.

Il n'empêche que souvent, le contenu ne sera pas le même selon la langue, même si à l'origine, on a l'intention de faire un site à l'identique pour toutes les langues choisies. C'est encore plus vrai si on a l'intention d'ajouter des pages ou des fonctionnalités pour un seul ou plusieurs langues seulement (heu... l'interface d'une vente en ligne disponible uniquement sur le territoire de l'UE, par exemple ? :wink:)

Posté : 22 juil. 2008, 04:17
par Patriboom
MainMa, t'as bien raison sur la structure de la table, c'est plus souple comme tu le proposes.
Tu as aussi raison de te rétracter sur le commentaire que je n'ose citer.

Posté : 22 juil. 2008, 05:14
par chrislabricole
Rassurez vous, bientôt plus de tracas avec les encodages, avec PHP6 :)
Il tournera en UTF-8 :)

Posté : 22 juil. 2008, 08:24
par zeus
Rassurez vous, bientôt plus de tracas avec les encodages, avec PHP6 :)
Il tournera en UTF-8 :)
Non, en unicode ... :roll:

Posté : 22 juil. 2008, 09:42
par lux
Moi je propose :

1° Un fichier xml par langue, contenant tout le texte "statique".
2° Une bdd normale, pour le texte dynamique, avec p.ex pour les news les champs : text_fr,text_es,text_de etc...

:wink: