Site bilingue - variable session ou get?

Version imprimable

10/07/2011, 02h39
helpcomm

Site bilingue - variable session ou get?

Je veux intégrer une deuxième langue dans mon site.
Techniquement, je pourrais le faire en utilisant les sessions pour y stoker la langue courante, mais aussi en utilisant les variables $_GET. C'est quoi le pour et le contre de chacune des méthodes?

Merci
10/07/2011, 09h57
okoweb

Un utilisateur lamda ne pourra jamais voir ton source php pour changer de langue. Par contre à partir d'un select d'un formulaire ou d'un lien coté client, l'utilisateur pourra choisir sa langue du site et en méthode GET, les informations seront transmises au code PHP qui à son tour va renvoyer le site dans la langue choisie par l'utilisateur. En fait les sessions serviront uniquement pour conserver et transmettre les informations de langue d'une page à l'autre.
10/07/2011, 12h18
BByani

Citation:

Par contre à partir d'un select d'un formulaire ou d'un lien coté client, l'utilisateur pourra choisir sa langue du site

Partant de la tu pourrais imaginé des petits drapeau (liens) qui vont recharger la page par exemple, du coter serveur tu peux utiliser les sessions pour sauvegarder la "langue" choisi. Et tu peux également utiliser les cookies pour stocker la "langue" sur la machine du client. Comme sa si ton utilisateur ferme sont navigateur et reviens le lendemain, il ne devra pas recommencer la procédure de "sélection de la langue".
10/07/2011, 20h15
helpcomm

Je vais expliciter plus ce que je voulais dire. Certains sites choisissent de garder tout le temps la langue dans l'url de toutes le pages dans une variable get. D'autres choisissent de ne pas le garder tout le temps dans l'url et utilisent les sessions pour cela. C'est quoi les pour et contre de ces 2 approches.
10/07/2011, 21h17
thebarbarius

3 ieme option que j'utilise, la détection de langue automatique (même si je propose toujours l'option de changer la langue)
10/07/2011, 21h57
Eric2a
Salut,

L'avantage avec la méthode GET c'est au niveau du réferencement.

Par exemple, si tu as 2 liens (les fameux drapeaux) :
1. page.php?lang=fr
2. page.php?lang=en
Les moteurs de recherches réferenceront les deux pages ce qui te permettra de reçevoir des visiteurs Francophones ou anglosaxons.

Sans cela, les moteurs de recherche ne verront que les pages avec la langue par défaut.
11/07/2011, 01h43
helpcomm

J'avoue que ça va faire une grande différence côté référencement. Et dans ce cas, on n'aura plus besoin de la session pour cela.
Est ce qu'il existe un design pattern particulier pour la gestion de la langue pour le site multilingues. De mon côté ça sera seulement bilingue. Mais j'imagine que pour les sites qui gèrent une dizaine de langues, ça sera plus compliqué. C'est pour ça que je suis curieux de avoir s'il y a des design patterns adapté à ça.
11/07/2011, 01h55
Eric2a

Tu peux éventuellement t'inspirer de la réponse que j'avais donné :arrow: ici.
11/07/2011, 01h56
niehu

Tout en gardant l'avantage du référencement, tu peux également utilisé l'url-rewriting pour que tes urls soient plus "esthétiques".

Un lien concernant google et le référencement multilingue
11/07/2011, 10h01
Benjamin Delespierre

Personnellement je fais ainsi:
- si aucun paramètre n'existe ni sur la session ni sur $_GET, on détermine la langue la plus appropriée parmi les langues disponibles selon l'user agent (j'ai le code si tu veux) et si une aucune langue ne convient, on utilise la langue par défaut.
- si le paramètre existe sur la session, on charge la langue qu'il indique
- si le paramètre existe sur $_GET, on change la langue dans $_SESSION et on charge cette langue.

Ainsi tu es toujours sûr d'avoir la bonne langue.
11/07/2011, 15h05
okoweb

Citation:

Envoyé par Benjamin Delespierre

j'ai le code si tu veux

On peut voir ce code ? Cela m'interesse.

Merci d'avance..

Par contre je sais plus à qui je l'ai piqué, j'avais ~~la flemme~~ pas tellement envie de refaire un parser pour ça:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
        $httplanguages = $_SERVER['HTTP_ACCEPT_LANGUAGE'];
        $languages = array();
        if (empty($httplanguages)) {
            return $languages;
        }
 
        foreach (explode(',', $httplanguages) as $accept) {
            $result = preg_match('/^([a-z]{1,8}(?:[-_][a-z]{1,8})*)(?:;\s*q=(0(?:\.[0-9]{1,3})?|1(?:\.0{1,3})?))?$/i', $accept, $match);
 
            if (!$result) {
                continue;
            }
            if (isset($match[2])) {
                $quality = (float)$match[2];
            }
            else {
                $quality = 1.0;
            }
 
            $countries = explode('-', $match[1]);
            $region = array_shift($countries);
            $country_sub = explode('_', $region);
            $region = array_shift($country_sub);
 
            foreach($countries as $country)
                $languages[$region . '_' . strtoupper($country)] = $quality;
 
            foreach($country_sub as $country)
                $languages[$region . '_' . strtoupper($country)] = $quality;
 
            $languages[$region] = $quality;
        }

la référence $languages est un tableau clé valeur avec en clé les régions (fr, FR_fr, FR_ca) et en valeur la qualité (ou préférence).

18/07/2011, 00h22
ehben

Moi qui était parti sur une gestion avec COOKIES (sans changement d'URL), c'est mal parti apparemment...

Citation:

And last but not least, keep the content for each language on separate URLs - don't use cookies to show translated versions.
21/07/2011, 08h34
thebarbarius

Des cookies pourquoi pas ?

L'important c'est de stocker la langue quelque part.

Imagine dans un des cas tu aurai pu stocker les preference du visiteur dans un XML aussi...

L'important c'est de stocker quelque part.