fastclemmy.com

Non ce n'est pas un SimpleQuiz, un ToughQuiz ou un AccessQuiz, mais juste une interrogation que j'aimerais partager avec vous.

Parmi les bonnes pratiques du web, il est de bon ton de réfléchir à la structure de son site avant de se lancer afin de pouvoir avoir des URLs sympas. L'idée générale c'est qu'il est plus cool d'avoir des http://www.mondomaine.com/produits/jardinage/desherbants/ que des http://www.mondomaine.com/cgi-bin/processShop.nsf?relatedPath=//820871exBV47/desJ_43/. Meilleure lisibilité, meilleur référencement, mémorisation facilitée, y'a pas à dire, c'est vraiment sympa les Cool URLs.

Seulement une autre bonne pratique consiste à penser également à l'internationalisation de votre site. Peut-être que pour le moment votre site n'est qu'en français, mais quand votre audacieux business model séduira les investisseurs, il faudra voir plus grand et surtout dans d'autres langues !

Votre http://www.mondomaine.com/produits/jardinage/desherbants/ qui avait l'air si cool tout à l'heure devient nettement moins tripatif maintenant que vous voulez acheter un spot de 30 secondes pendant le Super Bowl...

Alors, quelle solution privilégiez-vous pour l'URL anglaise de votre site ?

  • http://www.mondomaine.com/produits/jardinage/desherbants/?lang=en
  • http://www.mondomaine.com/products/gardening/grass-killer/ avec un super système sous le capot qui gère intelligemment le contenu
  • Une solution intermédiaire ni vraiment anglaise, ni vraiment française pour faire illusion dans les deux langues
  • ou une autre idée géniale ?

N'hésitez pas à donner vos retours d'expérience en la matière dans les commentaires, notamment avec les détails techniques sur la gestion des URLs côté serveur (solutions avec mod_rewrite, etc.).

#conceptionWeb

Vos commentaires

Nima -
A priori, moi je prendrai ta seconde solution. Par contre, tu parles d'un "super système sous le capot", je ne pense pas qu'il y ait besoin d'u système tellement plus super que pour la première solution, si ?
Sinon, j'aime bien aussi ta troisième idée ;) Une version en schtroumph ?

virtualblackfox -
http://www.mondomaine.com/0E5F46B02/0EF8A9B277/

Pourquoi faire simple quant on peut faire compliqué !

Titus - site -
J'ai récemment lu ça : http://www.blog.adifco.fr/index.php/2005/04/01/48-structurer-site-langue-referencement

Je ne sais pas vraiment ce que ça vaut, just my 2 cts :)

frenchFred - site -
Humm,

pourquoi pas :
http://www.mondomaine.com/produits/jardinage/desherbants/
pour la version francaise s'il s'agit de la langue primaire du site.

puis
http://www.mondomaine.com/[LANGUAGE_CODE]/products/gardening/grass-killer/
ou LANGUAGE_CODE serait le code iso de la langue et le reste de l'uri dans la langue appropriee
(en anglais dans cet exemple avec en pour le code langue)

frenchFred - site -
Une petite variante pour la gestion des pays:
www.domaine.com/[code_pays]_[code_langue]/blob/...

exemple type: la belgique ou l'on parle de francais, l'allemand, le flamand, ...

j'ai utilise cette technique dans le cadre de l'internationalisation pour societe de cosmetique de luxe.

Benoît Meunier -
Les bonnes pratiques sont, entre autres, mise en places afin de procurer une visite du site web plus agréable et plus efficace. Et si nous ne tapons plus 182.291.237.182 pour aller sur le un site web, c'est beaucoup pour rendre le web plus accessible. Dans cette logique, refaire les différents url selon les langues est donc la chose à faire.

Il ne faut pas oublier que le promotion d'un produit se fait souvent comme ceci : www.monsiteweb.com/produitxyx/. L'adresse est donc importante pour bien soutenir le contenu et adapter le tout à l'utilisateur. S'il faut se casser la tête pour développer une double arborescence pour deux langues, cassons nous la tête. Notre travail est d'offrir un produit simple pour les visiteurs, pas de simplifier notre travail.

Ganf -
Déjà, bien penser qu'une très grande majorité des sites n'est pas internationalisé. Dans ceux qui le sont, même pour les très grosses sociétés, c'est souvent deux sites gérés indépendament, même s'ils repiquent en partie les mêmes contenus et l'architecture. Du coup pour l'essentiel du Web la question ne se pose pas.

Pour les quelques sites qui restes, qui ont effectivement un contenu unique présenté sous plusieurs traductions :
- dans l'idéal je prendrai /produits/jardinage/desherbants/ et /products/gardening/grass-killer/, avec un système qui permet d'avoir plusieurs URI à chaque ressource. En soit ce n'est pas dramatiquement compliqué. Il suffit de traduire les composantes de l'adresse en même temps que le contenu. Et si les composantes de l'adresse sont des catégories ou composantes similaire, c'est déjà traduit, il suffit de savoir les relire. Ca demande des outils qui savent gérer les URI autrement que de bêtement considérer ça comme une adresse de fichier mais c'est largement faisable.
- Si besoin alors mettre un répertoire principal /en/ ou /fr/ (ou avec un (/xx_YY/ pour les puristes) qui contient tout le reste, afin de symboliser la langue, avec le reste de l'url identique sur les deux langues. L'avantage de ce système c'est qu'on n'a pas à réécrire les liens suivant la langue, il suffit de faire des liens relatifs.
- encore une solution : bêtementfaire la différence sur le nom de domaine (.fr pour le français, .com pour l'anglais, .it pour l'italien ...) ou sur le sous domaine (ce que fait yahoo par exemple)
- La solution du ?lang=XX est pour moi batarde, elle cumule les inconvénients des deux : devoir réécrire toutes les url pour que ça reste dans la même langue et pourtant ne pas avoir d'uri sympa.

Pour ceux que ça intéresse, Karl Dubost m'avait dans le temps fait passé des liens qui montrait l'utilisation en Asie : les gens s'échangent des URL qui ressemblent à des code barre et qu'ils prennent en photo avec leurs téléphones pour les échanges. Et *vlan* dans la figure des uri significatives (par contre ça résoud le problème des traductions).

David Duret - site -
Je suis d'accord avec les commentaires de frenchFred ou Ganf et je complète avec une réflexion de Anne van Kesteren : http://annevankesteren.nl/archives/2004/08/uri-design

Dans l'ordre de priorité, je ferais ca (suivant les possibilités du serveur et du porte-monnaie):

1/ www.domaine.(com|fr|de|it)/uri : plusieurs domaines à acheter,

2/ (www|fr|de|it).domaine.tld/uri : en sous-domaine avec "www" pour la langue principale,

3/ www.domaine.tld/(en|fr|de|it)/uri (un seul domaine, le plus simple à gerer)

Pour les puristes du [code_pays]_[code_langue], je prendrais plutôt l'option 3 avec une forme [code_pays]-[code_langue] en minuscule (en-gb ou fr-ca par exemple).

Pour finir, je ne crois pas trop en l'option du www.domaine.tld/uri avec une uri qui ne contiendrait pas explicitement le code de la langue ; c'est tout de même bien de savoir à quelle sauce on va être mangé et l'indication de la langue dans l'url permet de savoir si ça "vaut le coup" d'ouvrir le lien (par exemple, si je vois "ru" ou "jp" dans un lien, je sais que je n'y comprendrais rien).

Nima -
Je me trompe peut être, mais j'avais l'impression que les URL cool avaient pour but de permettre une mémorisation plus simple par les internautes...mais dans leur cerveau.
Or je ne suis pas sur qu'un code iso de langue soit facilement mémorisable. Pour nous, oui, c'est facile, on les connaît par cœur car on les utilise tous les jours, c'est comme les codes d'encodages genre iso8859-1, ça nous parait trivial. Mais pour l'internaute de base, il aura déjà du mal à se souvenir du tld (et on voit que c'est très récent que les gens mettent par défaut .fr à la place de .com et donc qu'ils ont fait le rapport entre le tld et la langue) alors leur demander de mémoriser ensuite une code langue XX-xx ça me semble un peu utopique.
En revanche si les url cool n'ont pour but que d'être utilisées en liens et non d'être mémorisées dans sa petite tête, je vois pas trop l'intérêt en dehors du référencement. S'il suffit de cliquer, qu'est-ce que ça change pour l'internaute qu'il y ait un id à rallonge derrière ou pas ?
Et puis, si la personne lit une adresse dans sa langue, par exemple dans un journal papier, elle n'a pas besoin qu'on lui précise que ce qu'elle lit est dans sa langue, elle n'est pas bête non plus, elle voit bien si elle comprends ou non ce qu'elle lit...
Dans ce cas, le souci vient plutôt des mots ayant la même orthographe mais des sens différents selon la langue. Par exemple le mot "basket" qui ne signifie pas la même chose en français et en anglais, même si c'est un anglicisme en français... si on a l'url française (hypothèse du nom de domaine unique) : domaine.com/produits/basket
et anglaise : domaine.com/products/basket
on pourrait croire (si on est bête, je sais...) que c'est le même produit, et on risque d'avoir des surprises... Au niveau logiciel, je ne pense pas que ça pose ici de problème car le fait de demander d'abord "produits" ou "products" cible la langue à utiliser. Mais ça complique tout de même. La confusion est par contre à craindre si on utilise en premier un mot de l'url un mot qui peut exister avec deux significations différentes dans deux langues comme "basket". Pour cela je pense que les exemples 1 et 2 de Davis ou on utilise le TLD ou un sous-domaine sont les meilleurs solutions.
Le choix entre l'un et l'autre dépend à mon avis de la politique du site. Si le site est celui d'une organisation, il prendra sûrement une TLD en .org et ce serait tout à fait justifié dans ce cas d'utiliser un sous-domaine pour la langue, même si on a les moyens de se payer un TLD national. Ou par exemple un site gouvernemental en .gouv.fr pourra avoir es.xxxx.goug.fr pour les hispanophones, mais doit garder le TLD en .fr pour signifier de quel gouvernement il s'agit. En revanche, une entreprise international comme coca-cola par exemple a tout à gagner à spécifier la langue avec le TLD et éventuellement à avoir un site portail en .com

Fvr -
En réaction au commentaire de Nima, il faut ne faut pas oublier que la langue de l'URL ne suffit pas à gérer l'internationalisation. On peut par exemple vouloir servir un contenu différent à un belge, un français ou un suisse qui consulteront une même page en français. Internationalisation signifie la prise en compte des couples pays/langue et pas seulement langue.
Ma remarque étant faite, je n'ai pas pour autant de solution miracle à proposer :(

David Duret - site -
> Fvr : une facon de faire peut être de gérer les url du site avec le code de langue seulement mais par contre de se baser sur le header HTTP_ACCEPT_LANGUAGE pour fournir de maniere transparente du canadien, du belge ou du suisse au visiteur (s'il a bien entendu correctement configuré son navigateur : fr-ca, fr-be, fr-ch). Une autre solution pourrait être de se baser sur une solution IP2Country pour déterminer le bon pays mais là c'est une autre histoire...

Concernant l'option 3/ que j'ai exposé plus haut (pour rappel : www.domaine.tld/(en|fr|de|it)/uri), je me pose la question de savoir si quand on arrive sur la page d'accueil du site, on affiche le site (dans la langue determinée pour le visiteur) ou si l'on redirige dans tous les cas sur l'url www.domaine.tld/(en|fr|de|it)/ (même pour la langue par défaut) ; ca évite le cas d'avoir 2 url pour la page d'accueil : www.domaine.tld et www.domaine.tld/fr/ pour le francais par exemple. Un avis là dessus ?

David Duret -
En fait, ma question précédente se pose pour les 3 cas et finalement, je pense qu'une redirection automatique depuis www.domaine.tld vers la vraie page d'acceuil pour la langue (avec un statut HTTP 307 Temporary Redirect, comportement par defaut de header('Location') en php) est préférable pour être cohérent ; c'est la solution qu'adoptent Google ou Yahoo par exemple.

Nima -
Effectivement, je n'avais pas pris en compte le fait qu'on puise parler une même langue dans plusieurs pays ou qu'on veuille servir différents contenus selon le pays, même si la langue est identique...oups.
En ce qui concerne l'IP2contry, c'est pas si compliqué que ça - un coup de whois et c'est bon-, c'est juste pas très fiable car les plages d'IP n'appartiennent pas forcement à un ISP du pays en question.
Pour la config du navigateur concernant le HTTP_ACCEPT_LANGUAGE, vous avez quelque part des stats sur le nombre de personen qui ont un navigateur configuré correctement ?

David Duret -
> Nima : je n'ai pas de stats pour HTTP_ACCEPT_LANGUAGE mais je suppose que les gens "normaux" possedent ou installent un navigateur dans leur langue maternelle, ce paramètre est donc probablement bien configuré par défaut - pour la langue principale (fr) mais, OK, par forcément pour la langue du pays (fr-ca).

Fvr -
La prise en charge de HTTP_ACCEPT_LANGUAGE est, à mon sens, une très bonne option pour choisir un couple pays/langue à afficher à l'utilisateur par défaut. Mais je pense qu'il est important que l'utilisateur puisse choisir, via l'interface du site web, un autre couple pays/langue de son choix. Dans ce cas la présence du couple pays/langue choisi dans l'URL devient indispensable...

David Duret -
Oui Fvr, il faut pouvoir changer de langue manuellement quand la négociation a échoué ; voir à ce propos l'article "quand faut-il utiliser la négociation de langue ?" du W3C (http://www.w3.org/International/questions/qa-when-lang-neg) qui utilise bien entendu la négociation (fr et en) :) L'article donne une idée assez claire sur la question, en gros qu'il faut utiliser la négociation "presque toujours, mais pas toute seule".

Un réflexion demandant plus ample développement : les liens (ou boutons) changement de langue doivent mener sur la page d'accueil dans la langue sélectionnée ou sur la même page mais traduite ? A priori, le deuxième cas doit être utilisé quand toutes les pages du site sont traduites ; le cas "page d'accueil" étant plutôt réservé aux sites qui sont disponibles dans plusieurs langues sans être identiques. Par contre, je suppose que l'on implémente l'une ou l'autre de ces deux méthodes mais pas les deux mélangées au risque de perdre nos visiteurs.

Dernier lien pour la route : Internationalisation: Spécifier la ou les langues d'un document Web (http://blog-and-blues.org/weblog/2004/10/20/319-internationalisation-specifier-la-ou-les-langues-document-web) qui se penche plutôt sur la déclaration de la langue dans la page elle-même.

karl - site -
On pratique le mélange des genres.

= Les URLS sympas
* Permanence des URIs
* Cacher son application toto.pl?something

= l'Internationalisation
La possibilité d'utiliser sa propre langue pour une application quelconque.

Ce que tu démontres, et qui sera démontrer de plus en plus souvent... C'est que les URIS ne sont pas significatives. C'est à dire qu'il n'y a aucune sémantique logique dans une URI.

http://example.org/love

http://example.org/amour

http://example.org/?

n'ont aucune valeur propre à cause des mots utilisés à l'intérieur de l'URI. Le fait de croire qu'une URI a un sens est une chimère, que beaucoup de gens veulent conserver.

L'association d'une URI a un contenu, cela a du sens, pas l'URI elle même.

Le fait d'utiliser un mot que l'on peut taper ou lire, cela a du sens d'un point de vue ergonomie pour certaines catégories de personnes. MAIS l'URI n'est pas destiné à être un système de compréhension ou de navigation d'un site.


karl - site -
rha tu ne gères pas l'UTF-8. La dernière URL contenait le graphe amour en chinois.

David Duret -
> Karl : dans ce cas, on oublie tout ce que l'on vient de dire, on efface tout et on regarde ça d'un oeil externe (je veux dire, non informaticien, en tant que "commun des mortels". Que veut-on réellement ? Pour reprendre ton argumentaire, on veut des urls "cools" (ce terme me fait rire), disons des urls propres et le plus court possible, dans ce cas restons basique dans nos urls : http://www.domaine.tld/ avec des paramètres ésotériques derrière qui nous permettent de retrouver les bonnes pages ; http://www.domaine.tld/?page_id=x ; ce paramètre page_id étant l'idendifiant unique de notre page toutes langues confondues, la langue étant stockée dans les propriétés de cette page. En ajoutant un peu de rewriting, on obtient http://www.domaine.tld/x ; y'a pas plus cool comme url ! Par contre, pas forcement facile à rester cool quand le système de gestion du site est remplacé par un autre, ces ids ne veulent plus forcément dire grand chose... On peut alors se dire que pour certaines pages "importantes", on va associer des noms à ces id pour un accès plus rapide quand on a besoin d'envoyer les gens directement dessus et on retombe éventuellement sur le sujet dont il est fait question ici. Avec un id - arbitraire - on se retrouve à accéder aux sites via les IP et non les noms de domaines... Une autre solution pourrait être de se dire que l'on garde quand même l'idée des urls "lisibles" mais en restant sur une seule langue pour ces url (et pas le contenu associé), cette langue étant l'anglais. On y ajoute quelque part une indication de langue (domaine, sous-domaine, répertoire virtuel, extension de fichier : products.fr, products.en, products.nl ou n'importe quoi d'autres) et le tour est joué. Peut-être une idée à étudier ?...

David Duret -
En fait, on peut faire une analogie avec la structure d'une page HTML et le nommage des div pour ceux que le nom des id donnés est important du point de vue logique et sémantique de cette structure de page : #header, #content, #search au lieu de #haut, #gauche, #droite... Je m'emploie - inconsciemment peut-être - à choisir des noms significatifs (on y revient) et cohérent quand à leur fonctionnalité réelle ; je reste sur des mots en anglais (langue la plus usitée même si je suis loin d'être un expert) ; du coup, la gestion des urls via cette méthode (urls en anglais + indication de langue facultative) ne semble pas si fausse que çà...

Une question subsidiaire aux experts : le fait d'avoir une url comme celle de l'exemple de virtualblackfox : http://www.mondomaine.com/0E5F46B02/0EF8A9B277/ est-il pénalisant par rapport à une url plus lisible qui pourrait être http://www.mondomaine.com/products/gardening/grass-killer/ du point de vue du référencement ?

Pour finir pour aujourd'hui, voici un exemple qui illustre nos propos, est-ce la bonne solution ou pas ? : http://www.microsoft.com/athome/ pour la version anglaise et http://www.microsoft.com/france/chezvous/ pour la version francaise... et d'un autre coté on a http://www.mozilla-europe.org/(en|fr|de|es|...)/products/ ... votre choix ? :)

frenchFred - site -
Bonjour,

Je suis loin d'etre un expert mais je peux te repondre concernant le referencement.
Le fait d'avoir des urls contenant des mots clef est important.
Dans l'absolu, le domain est important. Vient ensuite l'url, puis le contenu de la page

Je suis en train de realiser un site sur mes photos de voyage.
Dans un premier temps seul la version francaise sera disponible.
J'ai donc choisi la solution suivante:
domain.tld/(langue)/(continent)/(pays)/(ville)/...

Au fait Clement, quel est ton point de vue ?

David Duret -
frenchFred : dans ton domain.tld/(langue)/(continent)/(pays)/(ville)/, continent, pays et ville seront "traduits" pour chaque langue ? /fr/afrique/maroc/marrakech/ et /en/africa/maroco/marrakech/ ?

frenchFred -
David:
Oui, les urls sont dans la langue indiquee par le premier parametre (langue).
J'utilise un outil de gestion de contenu fait maison.
Cela me permets plus de liberte ;)

Des la phase de reflexion, j'ai voulu gerer differentes langue.
Donc pour le lancement seule la version francaise sera disponible et sera de la forme suivante:
domaine.tld/fr/....

Fred Bird - site -
Un bien beau debat, comme en aimerait en voir sur exgobz ;o)
La question se pose déjà de savoir si le site multilingue propose réellement les mêmes contenus pour chaque langue, ou si les contenus diffèrent selon les langues auquel cas chaque contenu devrait avoir sa propre uri dans la langue qui lui est associée. Dans le cas ou on suppose que chaque contenu est traduit, et que ce n'est pas le cas, on s'expose à des inconsistances dans la navigation.
"MAIS l'URI n'est pas destiné à être un système de compréhension ou de navigation d'un site."
Karl, je ne suis pas d'accord avec toi sur ce point; l'uri _est_ le système central de navigation et de compréhension d'un site/application web, l'element pivot de son interface et de sa structuration. Depuis les débuts du web une bonne partie des utilisateurs les "hackent" et se servent de la barre d'adresse du navigateur comme controle principal de leur navigateur.

Pilok - site -
Salut,
Eh ben, un blog francophone aussi riche et aussi bien écrit, c'est un perle à conserver... bravo!

J'ai un magasin de meuble avec un site internet et j'ai directement opté pour la réécriture d'URL afin de garantir un référencement efficace du site.

Les avantages de la réécriture d'url sont nombreux mais je vois deux points, sur base de ma propre expérience, 2 points importants liés à son utilisation:

1. Ne pas réécrire l'url vers un répertoire. Cela vous oblige à toujours employer des url absolues et c'est très pénibles
ex: http://www.pilok.com/index.php?page=2&menu=3
devient http://www.pilok.com/introduction.html et pas http://www.pilok.com/introduction
Je sais que les avis sont partagés sur cette règle, mais chaque fois que j'ai opté pour une réécriture sous forme de répertoire "virtuels", ça a coincé quelque part.

2. Dans l'optique d'une traduction en d'autres langues, je ne sais pas qu'elle est la meilleure méthode parmis tout ce que s'est dit ici. Je serai plus tenté d'employer des .htaccess différents par langue en structurant le site par répertoire linguistique et en gardan un répertoire core qui reprendrait les scripts de gestion du site et non le contenu... exemple:
www.pilok.com/index.php
serait la page d'accueil avec un choix de langue et des infos dans la langue principale du site...

www.pilok.com/english/index.php renverrait au template anglais mais le contenu et les scripts (login, basket case, etc...) serait géré dans un répertoire du genre www.pilok.com/core/script.php via un include et on pourrait même envisager du multilinguisme dans le scripte via une variable lang=en contenue dans le template anglais.

Le contenu des articles en Anglais serait de toute façon soit stocké dans le répertoire /english/ dans le cas de fichier ou sur une DB avec variable en.

Au final on aurait soit:
http://www.pilok.com/english/welcome.html
ou
http://www.pilok.com/francais/bienvenue.htm

selon la langue choisie... parce que je suis convaincu qu'imposée la langue n'est pas une bonne idée et nuit à la liberté d'action de l'internaute... le choix doit être évident mais doit être là.

Je ne sais pas si ce que j'ai dit aide un peu à la réflexion, n'hésitez pas à me faire part de vos remarques...

chocoku - site -
C'est sans doute une coïncidence,
mais je viens de réaliser un site et j'arrive effectivement à la conclusion que les urls doivent être traduite en fonction de la langue que l'on utilise.
http://chocoku.concours-referencement.net/amis/ en francais correspond à
http://seo-contest.info/chocoku/friends/.

A noter que le nom de domaine est également traduit. (un nom de domaine par langue donc)

Kao - site -
Super intéressant ce débat sur les urls. Merci à tous pour les infos!

Ajouter votre commentaire