Format d'URL pro.

Bonjour,

je voudrai quelques renseignements SVP, car je vais bientôt publier mon site.

Dans un premier temps il y aura seulement une version Française. Mais vu que je sais que plus tard j'ajouterai une version Anglaise, je me doit donc d'adapter mon projet des aujourd'hui, y compris mes URL. Vu que c'est mon 1er site multi-lingue, je ne sais pas trop ce qui est le mieux comme format d'URL.

Je pensais à des URL comme ceci :

Version Française :

www.mon-site.com/fr/slug-article

Et le jour où j'ajouterai une version Anglaise, j'ajouterai donc des URL comme ceci :

www.mon-site.com/en/slug-article

_Est ce que ça risque de poser problème(s) que l'URL de ma page d'accueil soit comme ceci ? :

www.mon-site.com/fr/

Je pense que non étant donné que des gros site (OVH par exemple) ont des URL comme ceci.

Mais vu que je vois que dans Google les sites (y compris multi-lingue) ont des URL comme ceci :

www.mon-site.com/

Je préfère donc demander vos avis.

PS : J'ai configuré mon Router que si un visiteur aissaie tout de meme d'accéder à cette URL :

www.mon-site/

qu'il soit redirigé en 301 à cette URL :

www.mon-site.com/fr/

Merci beaucoup.

As-tu vraiment besoin de garder la langue sur l'URL ?

Car ton navigateur est très poli, il se présente aux serveurs avant d'envoyer les paramètres de la requête HTTP. Tu as un header Accept-Language, avec les valeurs suivantes fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3.

Après, l'inconvénient de ne pas avoir la langue dans l'URI peut se faire sentir si les utilisateurs partagent une URI d'une langue à l'autre. Ainsi, si on se base sur Accept-Language, partager l'URI site.com/article-gnagna permettra à celui qui reçoit l'URI de l'avoir dans sa langue, mais l'empêchera par-là même d'avoir exactement ce que l'autre voit.

Donc, si la page en question contient (par exemple) des commentaires sur un article (commentaires qui seront donc spécifiques à chaque langue de l'article), alors le partage de l'article à quelqu'un parlant une autre langue sera problématique.

Je crois que certains sites se basent sur Accept-Language uniquement pour rediriger l'utilisateur depuis site.com vers fr.site.com ou en.site.com. C'est une autre piste, qui évite d'avoir des sous-dossiers dans l'URI.

Note que je n'aurai pas utilisé une 301 Moved Permanently, mais plutôt une 302 Found car cette redirection n'est pas définitive, mais dépend de ce que le navigateur envoie (Accept-Language).

Ok, merci pour vos réponses.

J'ai pensé au sous-domaines, mais je préfère le format que j'ai prix. C'est vrai qu'au début ça ma posé quelques problèmes de "relativité" à cause des sous-dossiers dans l'URL.

_En fait, à la base j'hésiter entre ce format :

Version Française (langue par défaut) :

www.mon-site.com/slug-article

Version avec une langue étrangère (Anglaise par exemple) :

www.mon-site.com/en/slug-article

_Et ce format :

Version Française :

www.mon-site.com/fr/slug-article

Version avec une langue étrangère (Anglaise par exemple) :

www.mon-site.com/en/slug-article

L’avantage de la 2ème solution par rapport à la 1ère, c'est que j'aurai pas de problème de lien relatif étant donné que peut importe la langue choisis, il y aura toujours un sous-dossier dans L'URL. J'aissai d'utiliser un maximum possible les liens absolues, mais parfois je suis obligé d'utiliser des liens relatif (Dans des fichiers JS par exemple).

Merci.

Salut,

as tu envisagé la solution à la wikipédia ? en.mon-site.com/slug ou fr.mon-site.com/slug ?

Après, je ne sais pas trop ce que tu attends de ce topic, c'est bien à toi de choisir quel format te plait le mieux…

Oui merci. j'ai envisagé, mais je préfère le format que j'ai montré dans mon précédant post.

@Xenos Oui c'est vrai qu'une redirection 302 c'est mieux que la 301.

Merci.

Ne fais pas de cas discriminant, car cela "particularisera" l'une des langues (le FR), ce qui sera toujours chiant à gérer.

Passer par les paths, je trouve cela bof pour cette même raison (cela t'oblige à le prendre en charge partout, et donc, les URIs du type /gnagna/foo/bar seront aux oubliettes. De plus, cela va rajouter également de la complexité dans les cookies, qui sont nativement séparés d'un sous-domaine à l'autre mais pas d'un path à l'autre (il faudra donc faire cette séparation toi-même).

Si les deux sites sont vraiment liés, et qu'il s'agit grosso modo d'un même site dans deux langues, pourquoi pas. Dans le cas contraire, c'est à dire si les pages FR ne sont pas strictement identiques aux pages EN (par exemple, parce qu'il y a des commentaires), alors les sous-domaines me semblent plus appropriés (puisqu'on gère alors bien deux sites distincts).

Autre argument pour le fr.monsite.com, c'est que tu pourras le transformer simplement en monsite.fr, monsite.de, monsite.jp etc.

Oui, il s'agit d'un même site dans deux langues (par exemple, dans mon dossier "lang" de mon MVC pour les contenus en dur que j'affiche dans mes vues, j'ai des sous-dossier "fr" et "en". et pour les contenus en BDD, j'aurai des tables avec par exemples des préfixes "fr_nom-de-ma-table" et "en_nom-de-ma-table").

Bon du coup, j'hésite entre 2 solutions. Je me donne encore quelques jours de réflexion. Et la solution des sous-domaine ne me plait pas (question de goût).

J'hésite entre ceci :

www.mon-site.com/fr/slug-article-francais

www.mon-site.com/en/slug-article-english

Et ceci :

www.mon-site.fr/slug-article-francais

www.mon-site.com/slug-article-english

La 1ère solution est pour moi la + simple, et c'est celle que je trouve là + élégante. J'ai fait pas mal de lecture. Il y en a qui disent qu'en ".fr" et ".com" sans sous-dossiers ça sera mieux référencé (surtout en France avec ".fr" c'est mieux que ".com/fr/". Et d'autre disent que non car avec les attributs HTML lang et hreflang ça suffit pour indiquer à Google la langue et le pays du site.

Si il y a des spécialistes du SEO parmis vous, je suis preneurs d'avis.

Merci.

Si il y a des spécialistes du SEO parmis vous, je suis preneurs d'avis.

Ils me semble que c'est ressorti quatre ou cinq fois, tu devrais utiliser [langue].mon-site.com. Tu n'aurais clairement pas un TLD pour toutes les langues (en tout cas, qui sera libre), et de plus, ça sera bien moins bien indexé – et c'est clairement moins explicite.

Et de toute façon, ce n'est pas [langue].mon-site.com/abc ou mon-site.com/[langue]/abc qui va changer du noir au blanc ton indexation.

Maintenant, tu fais ce que tu veux. Mais ça ne sert à rien de poser 10 fois la même question.

Edit: Je viens de lire ça.

j'affiche dans mes vues, j'ai des sous-dossier "fr" et "en".

Ce n'est pas la bonne façon de faire. Renseigne-toi sur l'i18n.

. et pour les contenus en BDD, j'aurai des tables avec par exemples des préfixes "fr_nom-de-ma-table" et "en_nom-de-ma-table").

Non plus, je t'invite à lire ce sujet sur SO.

Edit: Je viens de lire ça.

j'affiche dans mes vues, j'ai des sous-dossier "fr" et "en".

Ce n'est pas la bonne façon de faire. Renseigne-toi sur l'i18n.

Merci pour ton avis. En fait , je me suis mal expliqué. J'ai un dossier "resources", dans ce dossier j'ai un dossier "trans", et c'est dans ce dernier sous-dossier que j'ai des sous-dossiers "en", "fr".

Et pour récupérer une translation, par exemple pour le titre h2 de ma page d'accueil, je fait ceci :

1

<?php echo trans('home.h2'); ?>

Je me suis un peu inspiré de laravel 5.

Merci.

Très bien. Mais pas très intelligent si tu changes ton HTML; c'est pour ça qu'usuellement, on utilise le texte en anglais comme référence. (;

Bonjour,

J'ajoute ma pierre au débat, il y a aussi l'exemple du paramètre GET pour passer le code de la langue comme le fait Google avec le Play Store.

En allant sur https://play.google.com/store/apps/details?id=com.king.candycrushsaga tu tomberas certainement sur un contenu français, géré par Accept-Language (je suppose) comme déjà évoqué plus haut dans le topic.

Si tu veux accéder malgré tout à la version anglaise, tu peux ajouter ?hl=en en fin d'URL : https://play.google.com/store/apps/details?id=com.king.candycrushsaga&hl=en

Cela t'évite de changer ta structure, que ce soit au niveau du sous-domaine, du domaine ou du path.

Un petit middleware qui définit la langue selon la présente de hl fait l'affaire. Contrairement à ce que l'on peut penser, c'est une solution élégante.

Oui, tu peux faire un mécanisme multiple:

• Si GET[hl] alors tu le prends
• Sinon, c'est SESSION[lang] (définis dans le panneau de contrôle du compte du visiteur connecté)
• Sinon c'est COOKIE[lang] (préférence sans enregistrement)
• Sinon c'est le path ou le domaine
• Sinon c'est Accept language
• Sinon c'est anglais

Pour le reste, perso, le gettext c'est bien, mais cela ne constitue pas la localization du site: un site FR et un site JP n'ont pas juste des textes différents, mais tout un agencement différent. Du coup, je trouve cela cohérent d'avoir plusieurs vues, une dans chaque langue (quitte à ce que la vue EN et la vue FR fasse un include d'une vue "EUROPE" généraliste, qui fait du gettext).

Oui, tu peux faire un mécanisme multiple:

• Si GET[hl] alors tu le prends
• Sinon, c'est SESSION[lang] (définis dans le panneau de contrôle du compte du visiteur connecté)
• Sinon c'est COOKIE[lang] (préférence sans enregistrement)
• Sinon c'est le path ou le domaine
• Sinon c'est Accept language
• Sinon c'est anglais

C'est tout sauf une bonne idée d'afficher des informations contradictoires, ce que tu fais en ne mettant pas le chemin/domaine en premier critère. De plus

• Le paramètre d'URL est redondant avec le chemin/ou le domaine
• Je crois que tu confonds les cookies et les sessions. De toute façon, si l'utilisateur est connecté, cela ne doit pas aller dans ses cookies, mais en base de données.
• Accept-Language et «anglais» sont redondants.

Pour le reste, perso, le gettext c'est bien, mais cela ne constitue pas la localization du site: un site FR et un site JP n'ont pas juste des textes différents, mais tout un agencement différent. Du coup, je trouve cela cohérent d'avoir plusieurs vues, une dans chaque langue (quitte à ce que la vue EN et la vue FR fasse un include d'une vue "EUROPE" généraliste, qui fait du jettent).

Je ne connais pas de site qui fasse une différence d'interface entre les langues, et je prends si tu as des exemples. C'est globalement une mauvaise idée au niveau de l'expérience utilisateur si, par exemple, un utilisateur japonais utilise le site en anglais avant que la traduction soit mise ne place. Si tu penses aux langues écrites de droite à gauche, comme l'arabe par exemple, cela se fait très bien sans modifier le patron.

Pas faux, c'est tard, et le GET redonde avec le domaine donc oui, l'un ou l'autre seulement.

En revanche, non, je ne confond pas session et cookies: l'idée est de considérer que si le visiteur est inscrit et connecté, il a un compte et que ce compte est définit dans une langue. Dès lors, s'il se connecte n'importe où ailleurs sur ce compte, boum, on lui donne la langue associée à son compte. En revanche, s'il n'est pas connecté, il peut choisir sa langue et celle-ci est stockée (en session ou dans un cookie, peu importe, mais les sessions expires alors qu'un cookie de choix de langue n'a pas de raison d'expirer).

Pour la localisation, je n'ai pas d'exemple non plus, mais j'ai cru comprendre au taff que le Polonais (et d'autres langues slaves) avaient une pléiade de pluriels (genre 2 objets, 5 objets, 10 objets, et des centaines d'objets, ce sont 4 formes de pluriel différents). Pour ce qui est de faire ce genre de choses à coup de gettext, cela devient assez infernal. Bon, après, dans la pratique, je n'ai jamais appliqué ce genre de localization intégrale et elle s'est souvent limitée à du gettext et à la simple traduction mot-à-mot des textes.

En revanche, non, je ne confond pas session et cookies: l'idée est de considérer que si le visiteur est inscrit et connecté, il a un compte et que ce compte est définit dans une langue. Dès lors, s'il se connecte n'importe où ailleurs sur ce compte, boum, on lui donne la langue associée à son compte. En revanche, s'il n'est pas connecté, il peut choisir sa langue et celle-ci est stockée (en session ou dans un cookie, peu importe, mais les sessions expires alors qu'un cookie de choix de langue n'a pas de raison d'expirer).

Oui. Mais dans ton message, tu dis «SESSION» dans les préférences de l'utilisateur connecté, et «COOKIE» comme préférence qui n'est pas enregistrée. Le fait que tu utilises le mot «session» porte à confusion: on peut (et c'est ce que j'ai pensé), que tu voulais associer cela à la session courante.

Pour la localisation, je n'ai pas d'exemple non plus, mais j'ai cru comprendre au taff que le Polonais (et d'autres langues slaves) avaient une pléiade de pluriels (genre 2 objets, 5 objets, 10 objets, et des centaines d'objets, ce sont 4 formes de pluriel différents). Pour ce qui est de faire ce genre de choses à coup de gettext, cela devient assez infernal. Bon, après, dans la pratique, je n'ai jamais appliqué ce genre de localization intégrale et elle s'est souvent limitée à du gettext et à la simple traduction mot-à-mot des textes.

Oui, et basiquement toutes les langues qui possèdent un duel, mais c'est un problème qui se règle de la même façon que le pluriel en général.

Même si ça ne répond pas directement à la question, ça peut être intéressant comma article : http://sametmax.com/linternationalisation-cest-long-et-dur-et-ca-racle-le-fond/