Nous avions dressé un panorama des microformats dans un précédent article intitulé « microformats : republier et donner du sens aux contenus ». Nous avions notamment conclu que leur intégration était rapide, peu coûteuse et surtout bénéfique tant pour le visiteur que pour la visibilité du contenu.

Nous nous intéresserons cette fois-ci à une partie plus pratique des microformats : leur intégration. Toutefois ce rapide apprentissage sera didactique puisque nous apprendrons à identifier visuellement quels contenus d’une page peuvent être microformatés mais aussi comment microformater du code HTML déjà existant.

Des sites déjà microformatés

Intéressons-nous toutefois à des sites ayant déjà microformaté leurs contenus. Nous pourrons ainsi éveiller notre curiosité et préparer le travail de réflexion de la prochaine étape.

Exemple avec Google Maps :

Google Maps est un service de recherche cartographique accessible via un simple navigateur Web. Le moteur donne un accès à des recherches de lieux, de calculs d’itinéraires mais aussi d’emplacement d’entreprises.

Le support des microformats sur Google Maps est relativement léger mais suffisant pour être utile.
Contrairement à ce que l’on aurait pu penser, Google n’a pas intégré le microformat geo pour exporter les coordonnées GPS d’un point. La société s’est concentrée sur les données personnelles au moyen de deux microformats combinés :

• microformat hCard (correspond à la réunion des encadrés bleu et vert)
• microformat adr (correspond à l’encadré vert uniquement)

Cette combinaison facilite l’extraction des adresse postales et des entités (individus ou entreprises).

Exemple avec Yahoo ! Upcoming :

Yahoo ! Upcoming est un service gratuit cataloguant tous les évènements à venir par pays, ville, date et même par catégories (cinéma, concerts, expositions etc.).

Le microformat par excellence à adopter était bien évidemment le microformat hCalendar. Chaque occurence microformatée est représentée par un rectangle vert et peut contenir ces différents attributs, entre autre :

• date de début de l’évènement
• date de fin de l’évènement
• titre de l’évènement
• description de l’évènement
• le lieu de l’évènement (sous forme d’adresse complète ou pas)
• une URL menant à un descriptif plus approfondi de l’évènement

Ce microformatage permet d’aller au-delà d’une lecture classique puisque de manière simple, elle permet au visiteur de récupérer les évènements qui l’intéresse pour les ajouter à son gestionnaire de temps favoris, qu’il soit logiciel ou en ligne.

Identifier visuellement les microformats à intégrer

Identifier des microformats déjà implémenté est assez simple avec les outils adéquats. En revanche pour décider de microformater du contenu, deux outils sont indispensables :

• la documentation des microformats pour savoir quoi implémenter
• un peu de jugeotte pour savoir comment implémenter

Avec un peu de pratique et de connaissance des différents microformats, il ne faut pas plus de 5 à 10 minutes pour identifier les contenus microformatables. La difficulté d’intégration dépendra uniquement de la structure technique affichant les données : plus elle sera complexe, plus le microformatage pourra être long … au même titre que toute autre modification basique.

Exemple avec Wikia Search :

Wikia Search est un moteur de recherche lancé au tout début de l’année 2008 par un des fondateurs de l’encyclopédie en ligne Wikipédia. Ce moteur en reprend d’ailleurs le principe du wiki pour contribuer à l’élaboration et la notation de meilleurs résultats.

Il est d’ailleurs étonnant de voir qu’aucun microformat ne soit présent malgré de tels objectifs. La capture d’écran ci-dessus découpe la page en 3 zones microformatables distinctes :

1. le lien sur logo aurait pu se voir agrémenter d’un rel-home pour signifier un retour vers la page d’accueil ;
2. les résultats auraient pu quant à eux embarquer :
   • le microformat hAtom pour faciliter la syndication de contenu et l’extraction des résultats.
   • le microformat hReview ou VoteLinks sur les encadrés orangés identifiant les zones de votes.
3. enfin le microformat hCard aurait été le bienvenu sur la liste des résultats correspond à des personnes.

On peut constater que plus il y a d’emplacement représentant des contenus différents sur une page, plus on a de chances qu’un microformat corresponde.

Exemple avec Clever Age :

J’ai dénombré pas moins de 5 zones pouvant accueillir des microformats :

1. les dernières actualités pourraient utiliser le microformat hAtom. Un flux RSS est déjà disponible sur la page mais ce serait offrir un chemin de traverse pour les visiteurs et les moteurs d’indexation ;
2. le microformat hCalendar aiderait à la réutilisation des données dans les gestionnaires de temps. Imaginez un chef d’entreprise affairé désireux de transmettre à ses collaborateurs une ressource contenant toutes les informations de leur future formation : peu d’effort et un gain de communication ;
3. ajouter facilement Clever Age dans votre carnet de contacts et de prestataires serait également facilité si le microformat hCard redistribuait le nom et les moyens de contact de la société ;
4. en complément au moyen de contact, l’emplacement géographique des agences serait à portée de clic avec le microformat geo. Après tout, Google Maps proposera peut-être un jour d’importer des URL microformatée en plus des fichiers KMZ (Google Earth) ;
5. enfin, le microformatage de la dernière partie dépend de ce qu’on aimerait redistribuer :
   • le microformat hAtom pour offrir 3 flux de syndication mais le peu d’éléments (2 à chaque fois) tende à infirmer la pertinence de ce microformat dans le cas présent ;
   • le microformat XOXO est adapté à décrire des types de contenus embarqués dans une page ; ici des flux RSS. Il serait à placer sur chaque lien pointant vers les flux RSS ;
   • le microformat Xfolk est adapté aux collections d’URL plus communément appelés « favoris » ou « marque-pages »

Avec ce dernier exemple, nous venons de voir que le microformatage était facilement adaptable à un site Web de société. Dans ce cas précis, il y a énormément de contenu republiable mais pas systématiquement de manière pertinente.

Intégrer les microformats dans du (X)HTML

Les précédents exemples, sur de l’existant et ce qui pourrait exister, avaient pour but de former notre esprit à reconnaitre des zones susceptibles d’être microformatées.

La difficulté de l’exercice est d’ajouter du balisage sans altérer la présentation actuelle. Je traiterai du site de Clever Age dont nous avons parlé précédemment.

Microformater des données d’entités

Voici le code de départ, repris tel quel :

Clever Age - Siège social : 01.53.34.66.10

Comme nous avons pu le voir, la gestion d’identités passe par le microformat hCard :

<span class="vcard">
<span class="fn org">Clever Age</span> - Siège social : <span class="tel"><span class="value">01.53.34.66.10</span></span>
</span>

La balise span est une balise en-ligne neutre au sens où … n’en a pas justement. div est son pendant de type bloc.

Microformater des ressources syndiquées
Voici le code de départ (simplifié par rapport à l’exemple afin de réduire le code à lire) :

<dl>
<dt><a href="/rss/blog.xml">derniers billets du blog</a></dt>
<dd>...</dd>
<dt><a href="/rss/publications.xml">dernières publications</a></dt>
<dd>...</dd>
<dt><a href="/rss/cleverlink.xml">derniers Clever Links</a></dt>
<dd>...</dd>
</dl>

Le microformat XOXO nous permet de définir une liste d’éléments en fonction des modules XHTML :

<dl class="xoxo">
<dt><a href="/rss/blog.xml" rel="feed" type="text/xml">derniers billets du blog</a></dt>
<dd>...</dd>
<dt><a href="/rss/publications.xml" rel="feed" type="text/xml">dernières publications</a></dt>
<dd>...</dd>
<dt><a href="/rss/cleverlink.xml" rel="feed" type="text/xml">derniers Clever Links</a></dt>
<dd>...</dd>
</dl>

Le microformatage a été rendu possible uniquement en utilisant de manière standardisée des attributs définis par XHTML.
Malgré cet aspect de simplicité, il faut s’investir dans la compréhension des spécifications XHTML. Ce n’est un problème que pour les personnes produisant du code XHTML non-conforme.

Valider l’intégration des microformats

La question qui se pose toujours après avoir produit un code quelconque c’est comment le tester ? Il existe à l’heure actuelle trois outils gratuits :

• la relecture manuelle avec la documentation à côté
• l’extension Operator pour Firefox. Elle n’est toutefois pas complète et ne permettra pas de tester tous les microformats existants. Cette extension propose dans ses options un mode débogage très utile ;
• le service en ligne Optimus. Ce service polyvalent est capable de retourner sous forme de flux XML ou JSON les microformats présents dans une page Web. Il propose également un validateur, toujours pour une page Web, décrivant les erreurs de microformatage.

Conclusion

Il est difficile d’infuser en un article la manière de microformater du contenu. Fort heureusement la documentation des microformats abonde d’exemples en traitant des cas de figure concrets. Les spécifications restent là pour savoir quels sont les attributs, obligatoires ou pas.

De manière générale l’intégration des microformats est relativement aisée mais il existe 3 difficultés principales à l’intégration des microformats :

• difficultés liées à la plate-forme technique d’intégration ;
• difficultés liées à un manque de données. Certaines spécifications exigent la présence de données particulières que l’on n’a pas ou que l’on ne peut afficher, rendant invalide le contenu ;
• difficultés liées à un code HTML désorganisé. L’abus de div et le non-respect de hiérarchie est une source de problèmes et si elle rend pénible l’intégration des microformats, elle pose problème à la maintenance du code et des CSS.

Intégrer les microformats c’est finalement mener une réflexion sur la qualité du code produit. Un bon code, respectueux des standards et sémantique sera pérenne dans le temps, facilitera le microformatage et aura davantage de chances d’être accessible.

J’étais impatient de pouvoir accéder à la beta privée de Netvibes pour bénéficier de ses nouvelles fonctionnalités. Je n’attendais pas grand chose si ce n’est plus de confort d’utilisation. Tout le bruit généré par cette beta privée et ces Ginger c’est trop bien me laissaient à croire que j’avais de bonnes raisons d’avoir attendu.

Hélas au final ce n’est que déception et maigre consolation.

Netvibes Ginger : la critique ergonomique

La sympathique Jacinthe Busson s’est déjà chargée de dresser une analyse ergonomique rapide de Netvibes Ginger alors je ne vais pas spolier son travail. D’autant plus que je suis plutôt d’accord avec elle : c’est réussi même si on est loin du sans faute.

À vrai dire, certaines fonctionnalités comme le glisser-déposer de widgets dans l’espace privé ou public sont loin d’être flagrantes. À tel point que si on ne le tente pas, on ne peut pas se douter de sa présence. Dommage car c’est un gain de temps.

La navigation et les widgets

L’intégration de l’écosystème directement dans une barre escamotable est une bonne idée … sauf qu’elle ne contient pas les onglets ni même les univers publics. Ces derniers étant une des nouveautés de Netvibes, le minimum aurait été de pouvoir en chercher.
La recherche est fluide et bien guidée mais manque de catégorisation : impossible de trouver facilement un flux RSS dans la catégorie jeux vidéo par exemple. Il y a encore un sentiment de fouilli et d’inachevé.

Côté gestion de widgets … c’est simple, c’est pareil (ou presque) ! Notre page privée se gère comme avant, les options sont comme avant, les problème sont comme avant (essayez de recharger un widget dont le titre est trop long). Bref pas de quoi sauter au plafond : c’était bien avant, ça l’est aussi maintenant.

Les univers publics

Si jusqu’à ce niveau on était loin de pouvoir crier Ginger c’est trop bien, on pouvait espérer que ça soit le cas avec les univers publics (exemple avec mon Univers), LA grosse nouveauté tant attendue. En clair c’est une page Netvibes mais que l’on conçoit pour que ça soit les autres qui la regardent, pas nous. L’idée est franchement bien : c’est idéal pour donner une image de soi et communiquer autour de flux et de widgets qu’on apprécie.

Sauf qu’en pratique c’est ingérable.
On ne peut en effet pas s’abonner à un univers public, que ce soit via RSS ou via Netvibes. Non, la seule possibilité c’est d’envoyer un widget vers sa page privée ou son URL à un ami par email. Donc autant dire que la consultation d’un univers sera sporadique, si ce nombre dépasse celui des doigts d’une main.

Ce faisant, l’intérêt d’entretenir un univers devient très restreint. On affirme une présence certes, mais réduite.

La dimension sociale

Les univers publics sont un bon moyen de se faire des amis par affinité. La tissage du réseau d’amis se fera cependant dans des douleurs minimes grâce aux différents systèmes d’import depuis Twitter, Facebook ou son carnet d’adresse Gmail, Hotmail ou Yahoo! Mail. Pour le coup on ne peut que les féliciter car Dieu sait si la création d’un réseau est douloureuse quand on en est à son énième « réseau social ».

Car de sociale, la dimension n’en a que le nom : à part écrire dans le vide son statut (à la Facebook) et lire celui des autres, toute autre interaction est plus que limitée. Impossible de proposer un onglet à un de ses contacts, impossible de transmettre quoi que ce soit en fait. Les contacts sont juste là pour faire jolis … et pour voir l’adresse de leur univers et de finalement se rendre compte qu’il n’y a rien à faire socialement sur Netvibes … pour l’instant.

Pour le coup, le panneau escamotable est une tare car l’ouvrir et le fermer juste pour voir ce qu’ont fait nos amis, c’est pas génial. Du coup un widget a été créé pour suivre tout ça dans … Netvibes. Amusant : Netvibes pour suivre Netvibes. La boucle est bouclée.

Mon avis rien qu’à moi sur Netvibes Ginger

En attendant, le grand bruit généré par la sortie de la version beta aura été effectivement … du bruit. Je respecte totalement le travail des gens de Netvibes car je sais à quel point il est difficile de sortir un produit de qualité, fonctionnel et résistant à une forte utilisation.

Je pense cependant qu’il aurait préférable de ne pas emballer la machine marketing avant que le produit soit réellement fini … ou apporte en tous cas davantage d’avancées significatives. Parmi celles-ci on pourrait citer le Drive qui permettrait de stocker toutes sortes de fichiers en ligne. L’idéal serait de pouvoir partager certains fichiers uniquement avec certaines personnes mais la difficulté serait du même coup de faire s’inscrire des gens sur Netvibes sans qu’ils en aient un réel intérêt. À voir.

Pour l’instant c’est pas chaud du tout : Netvibes Ginger c’est du Coriander+.

Si j’ai pris précisément cet exemple c’est parce que je viens de le rejoindre après avoir été sollicité. Concrètement ça ne me demandera pas de travail supplémentaire mais tous mes billets placés dans la catégorie Linux seront automatiquement ajoutés en ce lieu. Une manière comme une autre d’évangéliser la bonne parole

Voici pour ma part une petite sélection de Planet sympathiques à suivre dans votre aggrégateur de flux ou à placer dans vos favoris :

• Google Blogs ‘n More (blogs Google, Yahoo! et Microsoft) ;
• Planète Accessibilité (accessibilité des sites Internet) ;
• Planet Libre (logiciels libres) ;
• Planet Ubuntu-fr (Ubuntu en français).

N’hésitez pas à signaler en commentaire d’autres Planet que vous consultez et pouvant en intéresser d’autres

Pour mesurer l’utilisation des flux RSS d’Emu Nova, j’ai décidé d’utiliser Feedburner dans sa version gratuite. Je l’utilise déjà pour ce blog et j’en suis très satisfait, que ce soit pour les données fournies, les personnalisations possibles ou encore la qualité du service.

La problématique du jour : comment utiliser Feedburner sur des flux RSS déjà existants ? Le changement doit être transparent pour les utilisateurs.

Créer son flux Feedburner

Avant de faire quoi que ce soit, il convient de créer son flux Feedburner à partir d’un flux déjà existant (qu’on souhaite rediriger tant qu’à faire). L’étape la plus simple.

Modifier les liens vers les flux

Une fois le flux créé, pensez à mettre à jour tous vos liens pointant vers ce fichier (balises <link />, liens hypertextes, boutons personnalisés etc.). Ceci a pour but d’unifier toute les adresses et éviter qu’il y aient plusieurs adresses visibles pour accéder à la même information.

Rediriger les flux existants

Arrivé à ce stade, il faut bien comprendre que nous avons 2 cas de figure :

• les anciens abonnés : ceux qui ont souscrit au flux avant que la modification précédente n’ait eu lieu. Le changement doit être transparent pour eux et ils ne doivent pas avoir à modifier la configuration de leurs agrégateurs actuels
• les nouveaux abonnés

L’intérêt est d’auditer tous les abonnés et donc pas seulement les nouveaux. C’est là que la redirection s’avère indispensable.
On est bien d’accord qu’il faudrait créer une redirection renvoyant l’ancienne adresse du flux vers la nouvelle adresse (celle fournie par Feedburner).

Le plus simple consiste à créer un fichier .htaccess (ou d’éditer directement les directives de votre serveur virtuel) dans le même répertoire que celui du fichier XML. Il contiendrait ce code :

RewriteEngine on
RewriteRule ^votreFlux\.xml$ http://feeds.feedburner.com/votreFluxFeedburner [R=301,L]

On teste, ça marche. Un peu trop bien puisqu’en suivant ce principe, quiconque appelle la véritable URL de votre flux sera redirigé vers le flux Feedburner. Si en soi ça ne pose pas problème majeur, ça l’est pourtant pour le robot d’indexation Feedburner qui, lui, a besoin d’accéder au véritable flux pour en extraire les informations.

Feedburner ayant bien fait les choses, leur robot d’indexation se signale en envoyant une entête User Agent FeedBurner/1.0 (http://www.FeedBurner.com). Ca tombe bien, il existe un filtre RewriteCond dans le module mod_rewrite. Ce dernier va nous servir à exclure le robot Feedburner de notre redirection précédente.

Juste au-dessus de notre RewriteRule, il suffit d’insérer la ligne suivante :

RewriteCond %{HTTP_USER_AGENT} !FeedBurner

L’utilisation de cette condition est d’ailleurs la seule raison pour laquelle une règle de réécriture a été employée en lieu et place d’un RedirectPermanent.
Attention cependant, le RewriteCond est à spécifier à chaque règle de réécriture. La documentation est assez explicite à ce sujet : la condition n’est effective que pour une seule règle de réécriture.

Le résultat final

Et plutôt qu’un long discours, voici le résultat final obtenu pour Emu Nova. Les fichiers RSS étaient placés dans le répertoire go/rss/. J’y ai donc placé un fichier .htaccess contenant le code suivant :

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteRule ^news\.xml$ http://feeds.feedburner.com/emunovaNews [R=301,L]
RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteRule ^veda\.xml$ http://feeds.feedburner.com/emunovaVedaTests [R=301,L]
RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteRule ^veda_commentaires\.xml$ http://feeds.feedburner.com/emunovaVedaCommentaires [R=301,L]

Pas difficile et tellement pratique

Cela faisait un mois que j’étais passé sous Netvibes et je ne pensais pas changer de sitôt malgré à part 2-3 défauts acceptables.
J’ai eu envie de tester Google Reader après avoir lu qu’il était le lecteur Web le plus utilisé ainsi que l’avis d’une personne ayant préféré Google Reader à Netvibes. Malheureusement je ne retrouve plus le lien et c’est bien dommage car c’est ce dernier qui m’en a convaincu.

Quoiqu’il en soit après une semaine d’utilisation, le verdict est sans appel.

Basculer de Netvibes à Google Reader

Avec plus de 90 abonnements, autant dire qu’il aurait été très pénible de les rajouter manuellement dans Google Reader. Heureusement qu’il existe l’export universel au format OPML. En 2 clics, j’ai pu basculer toutes mes lectures. Simple comme bonjour.

Avant-propos sur Google Reader

Avant de m’avancer sur l’utilisation de Google Reader, je vais expliquer son fonctionnement. De manière générale, un lecteur RSS (que ce soit logiciel ou Web, à quelques exceptions près) récupère les différents flux lorsqu’il est lancé. Si vous partez une semaine loin d’un ordinateur, votre lecteur RSS ne fournira donc logiquement pas toute l’activité qui s’est passée.

Google Reader ne fonctionne pas comme ça. Au lieu d’aller vérifier les nouveautés sur demande (lorsque vous affichez Google Reader donc), un robot se charge d’aller régulièrement interroger les flux auxquels vous êtes abonnés. Cette subtile différence anéantit le plus gros défaut des RSS, à savoir le côté éphémère évoqué plus tôt.

Google Reader au quotidien

Du fait de cette approche différente (mais totalement pertinente), le chargement de l’interface est incroyablement rapide. C’est notamment dû au fait que la page n’a pas à aller interroger tous les flux auxquels vous êtes abonnés puisque c’est systématiquement fait, que vous soyiez connecté(e) ou pas. A l’inverse sur Netvibes, plus j’avais de flux, plus la page était longue et lourde à charger.

Je sais également que maintenant je ne suis plus obligé de tout lire le plus vite possible de peur de rater des titres puisque tout s’accumule sans limite, que je sois là ou pas. Lorsque certains sites publient plus d’une dizaine de titres quotidiennement, ça devient vite ingérable avec Netvibes. Et quand on a plusieurs flux de ce genre à surveiller, autant dire que ne pas s’en occuper ne serait-ce qu’une journée consiste à se couper du monde (j’exagère un peu mais l’idée est là).

Les autres points forts que j’ai apprécié :

• marquer les éléments comme lus / non-lus : très pratique car ça n’oblige pas à lire l’élément original pour s’en débarasser
• éléments marqués comme lus au fil de la lecture : au fur et à mesure que l’on lit ses articles, ils sont marqués comme lus. Ca évite des clics à répétition pour les marquer comme lus. Cette fonctionnalité est désactivable.
• l’archivage dans le temps des éléments : on peut remonter dans l’histoire de tous les flux. Excellent pour voir ce qui s’était passé il y a 1 mois ou même 1 an (même s’il faut y aller à la main, il manque une facilité de déplacement dans le temps)
• la facilité de lecture : on peut lire les titres et/ou les titres + le contenu, toutes les nouveautés, toutes les nouveautés pour un groupe de flux, toutes les nouveautés pour un flux donné. C’est tout simplement excellent : on module sa lecture comme on le souhaite, en toute liberté
• le partage des éléments : le gadget pratique. On peut choisir de partager des éléments à la demande (accessible via une page et un flux RSS ; oui, un flux de flux ) ou systématiquement tous les éléments d’un dossier donné. Sachant qu’on peut placer un même flux dans plusieurs dossiers, les possibilités de partage sont très souples. Il existe aussi un petit module à insérer sur son blog / site Web.

Je comprends mieux pourquoi ce lecteur RSS en ligne a conquis les foules aussi rapidement. Il agrège avec facilité n’importe quel flux RSS, le restitue dans le navigateur de son choix, permet d’exporter ce qu’on veut. Bref on joue avec l’actualité et j’adore ça.

Google Reader est particulièrement adapté dans les cas suivants :

• nombreux flux
• flux fréquemment mis à jour (plusieurs fois par jour)
• flux peu mis à jour : on peut se les garder dans un coin facilement vu qu’ils n’occupent pas de place à l’écran

A l’inverse, Netvibes suffit pour les cas suivants :

• vue d’ensemble simple et globale de ses abonnements
• peu de flux (moins d’une vingtaine)
• rater un élément ne gêne pas (en cas d’absence, d’indisponibilité)
• quand on a besoin d’une page personnalisable sur laquelle placer d’autres éléments que des flux RSS (mais y’a Google IG pour ça)

Après son ajout discret dans Google News, on continue doucement à tirer le site vers le haut. Tout ça est devenu possible grâce au travail quotidien de l’équipe ainsi que depuis la suppression des roms.

Dans le billet ENES : Open Source ? j’expliquais les bases du renouveau du projet. Renouveau important car aux yeux du « public », et même aux notres, on en reste sur une impression de stagnation. Pendant que jeandubois s’occupe de la partie développement et matériel, je refonds le site Web. Bientôt à mi-parcours et à moins d’un mois de son relancement, que retenir ?

Petit rappel pour celles et ceux qui ont eu la flemme de suivre le lien ci-dessus : ENES est initialement un projet de conservation de jeux NES, ceux qui ne l’étaient pas encore. On élargit notre vocation désormais en proposant une plateforme matérielle d’extraction de données (de cartouches de jeu) ainsi que les logiciels nécessaire à l’extraction. En clair, avec un peu de connaissances, on peut aussi bien dumper de la Super NES comme de la Neo Geo (en théorie).

Le nouveau site d’ENES sera bien plus axé communication : de notre côté il sera plus facile de rédiger des brèves et d’en générer des exports RSS (format de fichier adapté à l’actualité car il peut être « interprété » par de nombreux navigateurs, des lecteurs de news et même des sites Web.
L’avantage pour les visiteurs et autres personnes intéressées par le projet c’est que l’actualité du groupe ira directement à eux : pas besoin de passer n-fois sur le site pour repérer des mises à jour; une actualisation du fil RSS suffit pour lister les dernières entrées. Comble du bonheur, ces fils sont disponibles en français et en anglais.

Bilinguisme

Oui tiens d’ailleurs, dans mon dernier billet sur ENES je parlais d’utiliser un blog pour l’actualité. Ben en fait non pour la simple et bonne raison qu’apparemment, avoir un même article en 2 langues différentes c’est impossible. Soit les blogs sont monolingues soit ils faut écrire 2 articles (1 pour chaque langue) dans 2 catégories (1 catégorie = 1 langue). Sans parler du côté usine à gaz et nullement intuitif. Bref une fois de plus j’ai opté pour la solution maison en reprenant les principaux principes du premier site d’ENES.
Physiquement, ENES n’a qu’un seul site mais dans la pratique, il y en a 2 : le site français et anglais. La langue principale du navigateur est automatiquement détectée; dans le cas contraire, la langue par défaut est choisie (l’anglais). Le visiteur (ou moteur de recherche) est donc gentiement guidé vers le site en question avec bien entendu la possibilité de basculer à tout moment d’une langue à l’autre.

Actualité

Quand on poste un billet d’information, on le rédige à la fois en anglais et en français. Les titres peuvent être totalement différents : ça ne pose pas de problèmes pour les adresses naturelles. En effet les adresses sont dites « naturelles » et canoniques : leur arborescence a un cheminement logique, comme si vous aviez des dossiers, sous-dossiers, sous-sous-dossiers etc.
Exemple : http://monsite/news/2005/09/22/titre-de-la-news.htm.
En lisant l’adresse, on devine que l’on se trouve dans la rubrique d’actualité du site, au cours de l’année 2005, dans son mois de septembre du jour 22 et pour une brève intitulée « Titre de la news ». Ca c’est une adresse naturelle.
Canonique parce que si on supprime « titre-de-la-news.htm », on tombera sur toutes les brèves du 22 septembre 2005. Si on poursuit le raisonnement, en supprimant en plus le chiffre 22, on aura toutes les brèves du mois de septembre 2005. Clair, net et précis.

Tellement clair que peu de systèmes fonctionnent comme ça, encore moins en gérant 2 langues. Là oui : l’adresse anglaise aura le titre anglais tandis que l’adresse française le titre français. Difficile de faire mieux et plus clair. Encore une fois, il aurait été impossible d’avoir ça sur un système de blogs préconçu.

La même page, en anglais ce coup-ci

Fils RSS

Une fois qu’une brève est ajoutée ou éditée, vu qu’il n’y a pas non plus 36 000 actualités par jour, le mieux est de générer directement à la suite le fil RSS. Ou plutôt LES fils RSS, anglais et français. C’est pas bien compliqué, suffit de lire la documentation, générer un fichier texte et … et quoi d’ailleurs ? La meilleure solution est-elle de générer dynamiquement un fichier à chaque appel (donc refaire n-fois la même routine alors que le contenu n’a pas changé) ou bien générer une fois pour toute un fichier « statique » ?
Je suis plutôt un partisan de l’économie (on appelle ça parfois la « flemme ») : c’est à dire produire le même résultat avec le mimimum d’effort. Donc en principe, pour moi, je préfère générer un fichier à chaque news éditée puis l’enregistrer en dur comme un fichier classique. Seulement voilà , sur l’hébergement fourni par notre hébergeur de projet, on ne peut pas créer de fichier comme ça. Verdict : tout dynamique ?

Ouaip ben non : on va faire comme prévu sauf qu’au lieu de générer le résultat dans un fichier, on va le stocker … dans la base de données. A première vue c’est débile (car on solicite aussi la base de données) mais c’est la meilleure alternative : la requête est simple (une ligne à chercher contre plusieurs dans le cas du tout dynamique), quasiment aucun traitement à effectuer (requête SQL + affichage au lieu d’une requête « moyenne », l’assemblage puis l’affichage). C’est donc plus rapide que du tout dynamique, un poil plus lent que la version statique (lire un fichier c’est toujours plus rapide qu’accéder à une base de données).

Même si c’était un peu technique, j’explique au moins la logique de fonctionnement : le tout dynamique est débile car il ne sert à rien de générer n-fois un contenu strictement inchangé : ça bouffe des ressources (RAM, processeur) pour pas grand chose. Ca fait juste très style mais c’est là le seul intérêt (sauf quand il est impossible d’agréger le contenu et que là , le fichier est effectivement dynamique).
La prochaine étape sera la nouvelle liste de dumps avec un moteur de recherche intégré afin de rechercher en 2 clics si un jeu en notre possession a bel et bien été sauvegardé.

Petite note : j’ai pris un peu de retard dans la rédaction de mes billets, j’ai 3 films à commenter (La moustache, Collision et la déchirure), la fin de mes vacances et c’est déjà pas mal En attendant j’vais un peu me reposer pardi.