Valéry-Xavier Lentz.eu

To content | To menu | To search

Sunday 29 August 2010

En chantier : le redesign du Taurillon

Le Taurillon est un magazine en ligne édité par l'association Les Jeunes Européens. Fondé en septembre 2005, afin de capitaliser sur l'expérience de publication online acquise par l'association au cours de la campagne référendaire, et de participer à la promotion des idées européennes et fédéralistes, il est devenu depuis multilingue en ajoutant de nouvelles versions linguistiques qui sont en fait autant de magazines distincts, chacun ayant sa propre rédaction, dans le cadre des Jeunes Européens Fédéralistes.

Une nouvelle version est actuellement en cours de réalisation. L'objectif est de mieux valoriser le contenu en se débarrassant autant que possible des éléments divers venus encombrer sa page d'accueil, mais aussi de mettre en valeur les différentes versions linguistiques ou encore de mieux prendre en compte les médias sociaux. Enfin, il s'agit aussi d'intégrer dans les squelettes les innovations des dernières versions de SPIP, son outil de publication de contenu.

Le Taurillon - version 1 (2005) :

Le Taurillon - version 2 (2008) :

Le Taurillon - version 3 (en chantier) :

Et vous qu'est-ce que vous amélioreriez sur ce site ?

Sunday 14 March 2010

Un domaine par langue pour un site SPIP

Ce billet rassemble quelques notes sur les manipulations que j'ai mis en oeuvre pour permettre l'utilisation de plusieurs domaines sur le site du webzine Le Taurillon, construit en SPIP. N'hésitez pas à faire part en commentaire de vos observations sur la méthode retenue.

SPIP propose tout ce qu'il faut pour construire un site web éditorial de type magazine. C'est même ce qu'il fait le mieux. De même il dispose de nombreuses possibilités pour la construction d'un site multilingue.

Le Taurillon, conçu initialement en français, rapidement pendant l'été 2005, est un site désormais publié en quatre langues. Chaque langue correspond en réalité à une publication différente car, même si de nombreux articles sont traduits, les équipes éditoriales sont distinctes.

  • Le Taurillon est publié par JEF-France, en français, utilise taurillon.org ;
  • The New Federalist est édité par JEF-Europe en anglais, a pour domaine thenewfederalist.eu ;
  • Eurobull est publié par JEF-Italie, en italien, avec eurobull.it ;
  • Treffpunkt Europa, enfin, est publié par JEF-Allemagne, en allemand, donc, avec treffpunkteuropa.de.
Le site est organisé à l'aide d'un secteur par langue. Chaque secteur (rubrique de premier niveau) ne contiens donc que des articles dans la même langue.
Les articles et rubriques ayant une langue, il est possible au sein de la boucle ARTICLE, ou RUBRIQUE, d'utiliser la balise #LANG pour récupérer la langue du contexte. Pour le reste du site il faut utiliser un paramètre de langue dans l'URL : &lang=fr que l'on récupère à l'aide de #ENV{lang}. Le critère {lang} permet ensuite dans les boucles l'acceptant de filtrer le contenu par langue. Pour en savoir plus lire la rubrique "Multilinguisme" sur site "Programmer avec SPIP 2.0".
C'est ainsi le cas de la page d'accueil. Ainsi, http://www.taurillon.org/?lang=fr affiche la page d'accueil du Taurillon, mais http://www.taurillon.org/?lang=de affichera la page d'accueil... de Treffpunkt Europa.

Un domaine par langue

La première étape a été de demande aux propriétaires des domaines de les configurer avec les NS de OVH, l'hébergeur du site. Chez ce dernier, j'ai pu faire pointer tous les domaines vers le même répertoire, celui où est installé le site, à l'aide d'enregistrements DNS de type A.
Par défaut, c'est la page francophone (langue par défaut du site) qui s'affiche. Pour que chaque domaine retrouve la page d'accueil correspondante c'est le fichier .htaccess qui est appelé à l'aide :
RewriteCond %{HTTP_HOST}  ^www.thenewfederalist\.eu$
RewriteRule (.*) spip.php?lang=en [QSA,L]
Jusqu'à la page d'accueil, tout vas bien, donc. Le problème est qu'un clic vers un article dans une autre langue conserve le nom de domaine actif. On se retrouve donc avec des articles en français ou en allemand sous le domaine anglophone.
Et c'est mal.
Pour parer à cette situation j'ai mis en place deux systèmes :
1) Indiquer l'URL canonique de la page : afin de ne pas troubler les robots (c'est fragile ces engins), j'ai ajouté dans le head une ligne indiquant l'URL canonique de la page, c'est à dire l'URL que je leur demande de prendre en compte pour chaque page. Un article en allemand aura donc dans le code de la page une ligne du type : 
<link rel="canonical" href="http://www.treffpunkteuropa.de/Chronik-eines-angekundigten-Todes" />
2) Pour les humains, et les robots malcomprenants, je modifie les #URL_ARTICLE et #URL_RUBRIQUE, qui génèrent un lien relatif, pour proposer un lien absolu avec le domaine.
Pour ce faire j'avais envisagé d'utiliser le plugin "Multidomaines". Celui-ci permet, à l'aide d'un champ Extra (oui il faut installer aussi ce plugin), d'associer un domaine à une rubrique. Je ne l'ai pas utilisé pour trois raisons : je n'ai pas besoin de toutes ses fonctions, je n'aime pas (plus) installer trop de plugins (impact sur lesperformances, complique la maintenance et l'évolutivité du site), enfin, quand je l'ai activé j'ai eu un message d'erreur et je n'ai pas insisté.
J'ai utilisé les chaines de langue de SPIP : j'ai créé une chaine <:domaine:> et indiqué dans chaque fichier de langue le domaine correspondant. Je peux donc utiliser cette chaine partout où j'ai besoin du domaine, car je dispose de la langue dans le contexte partout, soit dans la boucle, soit dans l'URL (paramètre lang).  Par exemple dans une boucle ARTICLES, j'indique comme lien href="<:domaine:>/#URL_ARTICLE". 

Les limites de l'approche retenue

Naturellement, cette méthode a des limites.
  • elle implique de modifier tous les squelettes. C'est également le cas avec le plugin qui propose ses propres balises. Pour l'instant je n'ai traité que les squelettes essentiels. J'adopterai l'approche systématiquement lors d'une refonte, et au fur et à mesure d'ici là.
  • elle ne peut avoir d'effet pour une boucle affichant des contenus en plusieurs langues (une boucle FORUM par exemple, celle-ci n'acceptant pas le critère lang) : les URL utilisent alors le domaine en cours.
  • les statistiques de fréquentation sont en partie faussées, chaque URL étant comptabilisée comme un site référent tiers. Il faut que j'étudie les configurations possibles dans Google analytics 

Méthodes alternatives

Plusieurs autres méthodes sont à étudier.
  • le mutualisé : plusieurs sites SPIP (dans des répertoires différents) qui pourraient partager une même base de données (pour permettre la gestion des liens de traduction ou des auteurs communs). À vérifier: cette solution permet-elle de partager un même jeu de squelettes ?). 
  • Utilisation du htaccess pour réécrire l'URL en fonction du paramètre lang pour y placer le bon domaine : je ne suis pas sur que ce soit possible, il faut que j'étudie plus la syntaxe pour RewriteCond
Un billet à mettre à jour donc, si je découvre une meilleure méthode. Mais pour l'instant l'essentiel semble fonctionner.

Mise à jour

31/03/2010 : Le carnet-SPIP propose différentes méthode, notamment à base de php. Cf. http://www.spip-contrib.net/MultilinguismeExemple6

Friday 28 August 2009

@font-face à la place des images typographiques

La sortie de Firefox 3.5 et sa généralisation progressive (la mise à jour est désormais proposée aux utilisateurs de la version 3), signifie notamment que le public pouvant bénéficier des sites utilisant la propriété CSS @font-face va connaître une explosion démographique.

Avant : les créateurs de sites web ne pouvaient utiliser que des polices de caractère installées sur les postes des utilisateurs. Concrètement ça limitait la typographie web à une poignée de polices, essentiellement Times New Roman, Georgia, Arial, Verdana... (qui a dit Comic Sans ?!).

Maintenant : en fait c'est pareil si l'on souhaite le même rendu sur tous les navigateurs (pour quoi faire ?) mais si l'on veut aller plus loin il est désormais possible d'utiliser la police de son choix... enfin si la licence d'utilisation de celle-ci l'autorise, il faut donc préciser : la police de son choix parmi les quelques-unes l'autorisant Oui aussi surprenant que cela puisse paraître à beaucoup de monde, les typos s'achètent aussi, probablement pour faire vivre les typographes.

Donc si vous avez eu le bon goût de vous doter de Safari 4, Firefox 3.5 ou la RC d'Opéra 10, vous ne verrez plus le web de la même façon. Installez l'un de ces navigateurs si ce n'est déjà fait et visitez ces quelques sites ou encore désormais valeryxavierlentz.eu ou dirtyclubber.com. Vous ne remarquez rien ? Parfait. Mais c'est plus joli.

Alors naturellement, il existait et il existe des moyens d'afficher des typos exotiques et sophistiquées aujourd'hui. Flash et Javascript sont mis à contributions dans des techniques pittoresques de remplacement d'images comme sIFR par exemple. On peut également utiliser des images dynamiques générées par le serveur. Le CMS SPIP (par exemple, au hasard) propose ce type d'images typographiques nativement. Cette technique est en pratique limitée aux titres mais permet des traitements que @font-face ne permettra pas à ma connaissance (cf. les techniques proposées par Arnaud Martin pour SPIP).

Il reste la question des performances web. C'est à dire ce qui permet d'éviter la formation de toiles d'araignées sur la souris de vos visiteurs attendant lle chargement de vos pages web. Une typo ça pèse... 153 ko pour celle que je viens d'installer sur taurillon.org, la très discrète LiberationSerif. Sur zzz.rezo.net, Fil a deux typos pour ce poids là.

Alors qu'est-ce que ça donne sur la page d'accueil de l'animal (cache navigateur vide) ? Selon Firebug :

  • avec les images typographiques : 76 requêtes (oui, je sais...), 624 ko
  • avec @font-face : 65 requêtes (nettement moins pire déjà),738 ko
  • avec du Georgia : 64 requêtes (bah oui, une de moins forcément) et 584 ko (le poids de la typo en moins, donc).
Même si la page d'accueil comportait onze titres en images, elle pèse moins qu'avec le chargement de la typo (10 ko chacune environ). Toutefois, la multiplication des requêtes (c'est à dire les échanges entre le navigateur et le serveur pour charger l'ensemble des éléments constituant la page) augmente les délais. À la louche (car c'est difficile à dire avec les widget tiers), deux secondes de plus qu'avec @font-face. Sans cette dernière c'est encore deux secondes de moins environ.

Il reste à trouver une typo plus jolie pour ce site, et pas trop lourde. Demander l'avis des 4 rédacteurs en chef aussi, peut être.

Thursday 27 August 2009

L'espace fine insécable sur le web, ce n'est pas pour demain

Ayant travaillé plusieurs années durant dans une agence print avant de passer au web (oui, je suis vieux comme ça), j'avais fait du Lexique des règles typographiques en usage à l'Imprimerie Nationale un de mes livres de référence (soit dit en passant, pourquoi la dite imprimerie met-elle une majuscule à l'adjectif ?) .

Naturellement, en travaillant sur le web, je veille aussi autant que faire ce peut au respect des règles typographiques, même si il faut s'adapter au média. Ainsi, pendant longtemps, l'italique était peu lisible à l'écran (à présent les lettres sont lissées la plupart du temps donc il est envisageable à nouveau de l'utiliser pour les titres d'ouvrages ou les citations par exemple). Lire par exemple ce billet : Typographie et web. Pour l'italique il y a bien sur le bug de rendu des vieux Internet Explorer (je n'ai pas testé sur les nouveaux) à prendre en compte.

J'utilise souvent l'outil de publication SPIP notamment car, conçu par des développeurs français dans une optique "presse", il prend en compte avec attention les règles typographiques française. Saisir par exemple un point d'interrogation ou un point virgule provoque l'insertion automatique d'un espace insécable &nbsp; qui évite de retouver son point d'interrogation à la ligne. L'outil Couteau Suisse dispose aussi d'une option pour permettre le remplacement des guillemets"anglais" (cf. l'article Wikipedia Quotation marks) par des guillemets « à la française » (cf. l'article Wikipedia Guillemets). 

Sur la prise en charge de ces règles par les CMS, et comment lesprendre en compte en leur absence, lire : Entités HTML et typographie française  Naturellement, même SPIP ne fait pas tout... Le « œ » peut être pris en compte en partie grâce à une lame du "Couteau suisse" qui procède à des remplacements par expression régulière sur les mots courants l'utilisant, mais c'est un pis aller. Attention à l'encodage de la page pour le e dans l'o qui ne passe pas systématiquement.

Je faisais remarquer sur spip.org que le &nbsp; n'était pas le bon caractère à placer devant les doubles ponctuations mais qu'il fallait en réalité une espace fine insécable. Naturellement, on m'a signalé qu'il s'agit d'un choix technique qu'explique cet article : Espaces unicode et navigateurs web selon lequel "parmi les navigateurs testés, seul Firefox sous Linux et Safari sous OS X 10.5 affichent correctement les espaces insécables étroites". Mise à jour : j'ai testé de mon côté, ça fonctionne très bien dans Firefox 3 sur Windows (Vista). Échec cuisant dans Internet Explorer 7, Safari 4et Chrome 2 (un carré s'affiche...).

Dans ces conditions, ce n'est pas pour demain. Naturellement il se trouve des gens qui ne se résignent pas et pondent des hacks tarabiscotés : Gestion des espaces fines et insécables. N'est-ce pas beaucoup de code pour faire plaisir aux puristes ?

P.S. : l'article signale aussi cette extension pour Dotclear.

Sunday 1 February 2009

Lectures du weekend