Voici donc un code que je viens de pondre, parce que je pense qu'il pourra être utile, aussi bien pour vous que pour moi J'utilise ici le framework Mootools 1.2 , mais je pense que c'est facilement adaptable à d'autres. Le principe est simple, on utilise une "faille" du CSS qui consiste à récupérer le style de liens après avoir appliqué un style particulier aux liens visités ("a:visited").

Une petite démo pour commencer : checkvisited.html

On va donc commencer par faire un peu de CSS :

C'est tout pour le CSS !
Maintenant, le Javascript :

Ces deux implémentations permettent de vérifier une URL ou une liste d'URLs.

On va reprendre l'exemple des réseaux sociaux que traite Aza Raskin dans son article. D'abord, on crée un conteneur pour l'affichage du résultat :

Ensuite, on crée la liste et on la traite :

C'est fini !

Chez moi, ça fonctionne impeccablement avec Firefox 3, Opéra 9.5, IE 6, et IE 7.
Si vous avez un problème d'incompatibilité ou une suggestion, n'hésitez pas ! Par exemple, on pourrait, comme Aza, traiter pour une URL quelconque l'URL avec et sans les "www".

Merci de me faire un petit lien de retour si vous utilisez ce script quelque part

On peut faire plus simple, certes, mais contrairement à ce qu'on peut voir habituellement, cette fonction traite véritablement tous les accents existants, et fonctionne avec tous les encodages.

Avant tout, un petit exemple en PHP pour illustrer mes conventions :

Notation :
J'utilise la notation lowerCamelCase pour nommer mes variables, fonctions, classes, et méthodes.

Indentation :
Tabulation de la largeur de 4 espace.
Je prends soin de bien indenter tout les blocs. Logique diront certains, mais ce n'est pas le cas partout...

Accolades :
Accolade ouvrante à la fin de la ligne de définition de la boucle. Accolade fermante sur une nouvelle ligne, au même niveau que la définition de la boucle.
Pas d'accolades pour un bloc mono-ligne. (par exemple un if suivi d'une seule instruction).

Espaces :
Pour les virgules et les point-virgules : pas d'espace avant, un espace après.
Pas d'espace entre les noms de fonction et la parenthèse ouvrante. Idem pour les boucles.
Pas d'espace entre la parenthèse fermante et l'accolade ouvrante dans les boucles.
Pas d'espace entre le else et le if dans les else if.
Un espace de part et d'autre des opérateurs de modification (=, +=, *=, ...).
Pas d'espace pour les opérateurs de comparaison (==, <=, >=) et pour les opérateurs de modification dans les boucles (for, while, if), sauf pour les longues expressions.

Guillemets
En php, j'utilise uniquement les guillemets simples (apostrophe), sauf pour afficher des caractères spéciaux (\r, \n ...).
Dans les autres langages, des guillemets doubles.

Commentaires
En moyenne un commentaire mono-ligne toutes les 10 lignes, avant un bloc, pour expliquer ce qu'on fait. Je pense qu'ils sont important pour la compréhension générale du code, mais qu'il ne faut pas en abuser.
Pas de bloc de 30 lignes au début des pages, au pire 2 ou 3 lignes.

Allez j'ai envie de faire mon chieur, je crée une chaîne ! Je tague divarvel, Darklg, Babozor, et TomClarks qui seront obligés conviés à décrire à leur tour leurs conventions sur leur blog et faire suivre la chaîne

Certains webmasters recopient simplement l'intégralité de leur site dans un autre dossier ou sur un autre domaine, puis le traduisent. Oublions tout de suite cette solution... Il faut donc opter pour une solution dynamique, que je traiterai ici en php.

URL et détection de la langue

Avant de traduire le site, il faut être capable de détecter la langue du visiteur, de lui proposer de changer de langue, et de mémoriser son choix :

Ce code devra être appelé au tout début de chaque page du site. Nous avons maintenant notre moyen de détection et de mémorisation de la langue.

Ensuite, nous allons prendre l'exemple d'URLs du type http://www.monsite.com/lang/page.html, ce qui a l'avantage de bien référencer toutes les pages dans toutes les langues traduites. Mais nous pourrions tout aussi bien garder des URLs classiques dans le cas d'un service accessible uniquement aux utilisateurs connectés : par exemple Twitter. La langue serait alors enregistrée dans les paramètres de l'utilisateur.

Pour cela, mettons en place un .htaccess avec de l'URL Rewriting à la racine :

Proposons maintenant au visiteur de choisir sa langue tout en restant sur la même page, au cas où elle aurait été mal détecté (navigateur en anglais pour un français par exemple) :

Stockage des traductions

On peut imaginer deux solutions de stockage pour les textes traduits. J'ai retenu la deuxième :

1- Première solution : Une fonction getText choisissant entre plusieurs textes proposés. Par exemple

2- Deuxième solution : Le stockage des textes dans divers fichiers : un fichier par langue. L'avantage ici est qu'on peut traduire (ou faire traduire) le site en ajoutant simplement un seul fichier. Nous stockerons les fichiers en.php, fr.php, et it.php dans un dossiers langs. Il suffira d'ajouter cette ligne après la détection de la langue :

Ensuite, nous avons encore le choix entre plusieurs méthodes de stockage. Les deux principalement utilisées consistent soit à créer une constante par texte, soit un grand tableau avec une entrée par texte. La méthode des constantes a l'avantage d'être performante mais n'est vraiment pas propre. Celle du tableau n'est pas non plus des plus performantes. Je parle bien sûr ici pour une grande échelle : prévoyons 15 000 entrées pour voir réellement les différences entre les méthodes.

Je vais vous proposer une autre méthode, une sorte de compromis, mais performante, pratique, et plus lisible. Elle consiste à utiliser une classe pour stocker les textes sous forme de constantes. Ces constantes restent dans la classe, c'est donc propre, l'accès y est très facile, et les performances sont très bonnes (j'avais fait un benchmark il y a quelques mois, mais je ne l'ai plus sous la main...). Nous allons donner un nom très court à cette classe, par exemple "_". Voici un exemple pour le fichier fr.php, il suffit ensuite de copier le fichier et de le traduire pour les autres langues :

Puis pour afficher le texte :

Et voilà, j'espère que ce tuto pourra servir à quelqu'un. Qu'en pensez-vous ? Quelles solutions utilisez-vous ?

TagMyPod, qui réalise des gravures sur téléphones portables et lecteurs MP3 (25 € environ), était présent hier soir à la GeekChic et offrait à quiconque le voulait une gravure !

Après un court apéro au brownies, coca et jus de fruits, nous avons eu le droit à une présentation par Tristan Nitot (Président de Mozilla Europe) de l'actualité des standards web, des navigateurs et de leurs enjeux. Il a parlé par exemple des plugins propriétaires visant à obliger progressivement les utilisateurs à migrer vers un OS précis, comme pourrait le faire SilverLight.

Nous nous sommes ensuite séparés dans nos ateliers respectifs que nous avions choisis à notre inscription parmi "Accessibilité", "Javascript", "CSS". Pour ma part, j'avais choisi Accessibilité, mais ce n'est pas exactement ce à quoi je m'attendais. Je pensais plutôt qu'on allait aborder l'aspect technique, avec les problèmes que posent le javascript (Ajax...), les animations flash...etc. Mais le principal thème abordé fut la mise en place de l'application d'une loi visant à rendre totalement accessible tous les sites de la fonction publique, notamment avec le RGAA et AccessiWeb .

A part ça, j'ai eu l'occasion de rencontrer Aurélien Levy , Frédéric Petit et Kévin Chanteclair. C'était une soirée bien sympathique, et je pense que j'y retournerai la prochaine fois (dans 2 mois il parait).
Merci à toute l'équipe organisant le WaSP café

Donc au programme :

• Liste des actions possibles en rapport avec la page courante qui viendra compléter le menu déroulant en haut à gauche. Par exemple quand on sera sur la page d'un article, il y aura des liens pour modifier l'article, modifier la rubrique, créer un nouvel article dans la rubrique, ...etc. Faut-il modifier la forme ou le type du menu ? (le faire venir de la gauche, le mettre en hauteur plutôt qu'en longueur, rendre le déroulement plus rapide ?)
  
  
• Ajouter un onglet "Options" à la fenêtre d'édition des articles. J'y placerai les options qui ne sont pas indispensables, comme les tags et le choix "en ligne/hors ligne". Il me permettra aussi d'avoir plus de place pour rajouter des options supplémentaires (gestion évoluée des médias, tags...)
  
  
• Toujours dans la fenêtre d'édition des articles, proposer 2 modes d'édition du texte : un simple avec les fonctions basiques (comme le formulaire des commentaires), et un avancé (l'actuel).
  

Je vais aussi me lancer à la quête de partenaires et d'affiliés pour faire connaître la plateforme. Et si j'ai le temps, je rajouterai deux possibilités de découverte du service sur la page d'accueil d'EklaBlog : un blog démo directement modifiable, et une vidéo de démo.
D'autres idées ?

Voici les prochains modules de menu prévus, ilsdevraient arriver très vite :

• Deezer (www.deezer.com )
• Mybloglog (www.mybloglog.com )
• Criteo AutoRoll (www.criteo.com)
• Blogasty (www.blogasty.com )