Expansion vers où ?

Ça fait depuis longtemps, très longtemps même, que j'envisage l'ouverture d'une version en anglais du présent site. Le problème, c'est que dans l'état actuel des choses, il n'y a pas de place toute prête pour une nouvelle version. La question que je me pose, et que je vous pose donc dans l'espor d'obtenir de précieux conseils de votre part, est quelle relation mettre entre la version française existante et la future version anglaise.

Voici les idées qui m'ont traversé l'esprit, de la plus séparatiste à la plus fusionnelle :

Utiliser un autre nom de domaine

Je pourrais mettre les deux versions sur deux domaines différents. Garder instincitive.eu et lancer la version anglaise sur un des autres domaines que je loue.

Outre le fait qu'en termes SEO je ne sais pas trop ce que ça vaut, je trouve mes autres domaines nettement moins proches du sujet de mon site, à savoir moi-même. instinctive c'est ce que j'ai trouvé de mieux.

Alternativement, je pourrais m'acheter un nouveau domaine. Genre instinctive.fr, en supposant qu'il soit encore libre quand je me serai décidée, pour y migrer le site actuel, et lancer la version anglaise sur instinctive.eu.

Utiliser un sous-domaine

En laissant les autres domaines là où ils sont, et en renforçant ainsi le lien logique entre les deux versions, je pourrais mettre la version anglaise sur sous-domaine de instinctive.eu, par exemple en.instinctive.eu.

Ce qui m'embête avec cette idée, c'est que ça introduit une hiérarchie entre la version française et la version anglaise. S'il faut utiliser des sous-domaines, je préfèrerais avoir fr.instinctive.eu et en.instinctive.eu. Mais alors quoi mettre sur instinctive.eu ? Un menu qui précise les langues disponibles ? Une redirection automagique suivant la configuration de la langue du navigateur ? Dans tous les cas, ça implique un déménagement d'URI, ce qui ne m'a pas l'air génial pour les visiteurs réguliers et pour les robots. Est-ce que le bénéfice est vraiment à la hauteur de cet infort ? C'est pas évident…

D'un autre côté, il va quand même y avoir une hiérarchie de facto, parce que je doute d'avoir le courage de traduire tout ce que je publie, donc il va inévitablement y avoir une des versions qui sera plus fournie que l'autre.

Utiliser un sous-répertoire

En fait cette possibilité est le symétrique des sous-domaines, et aboutit aux mêmes considérations.

L'idée dans ce cas est tout laisser sur instinctive.eu, en rangeant la future version anglaise dans instinctive.eu/en/. Alors hériarchisation en laissant la version française où elle est, ou déménagement vers instinctive.eu/fr/, avec les mêmes problèmes que pour un déménagement vers un sous-domaine.

Quelque part, un domaine multilingue ça fait plus .eu qu'une séparation plus forte, mais bon…

Tout mélanger

Tant qu'à être multilingue, pourquoi ne pas l'être jusqu'au bout, en rangeant au même endroit thématique les versions anglaises et françaises ?

Une URI en instinctive.eu/weblog/ pourrait aussi bien contenir des billets en anglais que des billets en français, et comme l'URI des billets est basée sur le titre, dans la plupart des cas je n'aurai pas de problème de collision.

Ou bien pensez-vous qu'il vaut mieux avoir une indication de langue systématique dans l'URI ? par exemple en ajoutant « en » en préfixe ou en suffixe du nom du nœud, ou en mettant un sous-répertoire du style instinctive.eu/weblog/en/ ? Ça manquerait de cohérence avec les sections traduites, comme instinctive.eu/dessins/ par rapport à instincitve.eu/drawings/. Ou bien mettre la version anglaise quand même dans un chemin de section français ?

Et que faire de la page d'accueil et des index ? Trouver un moyen de faire coexister une version française et une version anglaise dans l'arborescence, avec les soucis de hiérarchisation ou déménagement qui vont avec ?

Ou bien pousser le multilinguisme jusqu'aux pages d'index et d'accueil, avec par exemple une colonne en français et une colonne en anglais ?

À vot' bon cœur, m'sieurs-dames…

Alors, qu'en pensez-vous ?

Commentaires

1. Le samedi 29 mai 2010 à 19:44, par Roberto :

Pourquoi une version en anglais ? Pour essayer d'obtenir plus de trafic ? Pourquoi ?

2. Le dimanche 30 mai 2010 à 1:48, par xavier :

cf ce modèle:

[http://public.web.cern.ch/press/pressreleases/Releases2010/List.html]

et quand tu n'auras pas le courage de pondre les deux version ben il n'y aura qu'un lien [en] ou (exclusif) [fr]

3. Le dimanche 30 mai 2010 à 16:21, par Natacha :

Roberto , le trafic ne m'intéresse pas vraiment. J'imagine qu'une écrasante majorité de sites personnelles servent plus ou moins à flatter l'ego de leur auteur, et je mentirais si je disais que ce n'est pas le cas ici. C'est juste que je n'ai que faire d'avoir dix « perdus de Google » qui arrivent sur une de mes pages après une recherche quelconque et qui repartent immédiatement, ou d'en avoir cent. Mon ego a besoin de qualité, et serait plus touché par le nombre de visiteurs réguliers, voire de commentateurs, et je ne crois pas une seconde que ce nombre puisse augmenter rien qu'en mettant une traduction à disposition.

Cette volonté de version anglaise vient en fait de la démarche inverse, non pas traduire pour faire venir des gens, mais les gens qui pourraient vouloir venir, mais qui ne sont pas francophones, m'invitent à la traduction. J'appartiens à quelques communautés anglophones, notamment par mes images de synthèse et par mon code (dont la section en français va bientôt être publique), et je ne peux décemment pas leur imposer un site en Français.

Bref, il s'agit d'améliorer l'accessibilité pour les gens qui me connaissent déjà numériquement, plutôt que d'améliorer le trafic de gens qui ne me connaissent pas.

xavier , c'est un modèle intéressant. Le CERN semble avoir opté pour ce que j'ai appelé « tout mélanger », avec seulement un suffixe 'E' ou 'F' pour distinguer les traductions d'une même entrée.

Cela dit, comme nous en avons discuté, tu semble plus préconiser une présentation qu'une gestion des URI, en pourrais mettre en place la même présentation que le CERN, avec la même clicabilité, tout en hébergeant chaque version sur un domaine séparé (ou n'importe quelle solution présenté dans ce billet). Le choix des URI n'a pas vraiment d'influence tant que les gens ne font que cliquer sur des liens hypertextes, ce qui ne résout pas mon problème.

4. Le lundi 31 mai 2010 à 17:00, par Keeh :

Vers l'infini et au delà !
J'aurais une préférence pour une solution de type regrouper tout le monde au même endroit (jusqu'aux commentaires), avec un choix de la langue servie à l'utilisateur pour là où c'est pertinent : article, titres, machins organisationnels type menus et sections, éventuellement les parties expressives des urls comme ton histoire de dessins/drawings/ ou celles construites à partir des titres d'articles, mais de manière à ce que ce soit le même endroit quelque soit la langue choisie (ce qui ne serait quasiment que visible au niveau des commentaires, j'imagine).

5. Le mardi 1^er juin 2010 à 23:30, par W :

Comprenant l'anglais et le français, je suis plutôt contre une séparation complète, qui ne se justifierait à mon avis que si aucun ou presque aucun article n'était disponible dans les 2 langues.

Pour les articles qui seront disponibles dans les 2 langues, il faudra au moins que les commentaires soient communs : il serait très casse-pieds de les voir répartis entre les 2 versions du site.
Il sera également pratique d'avoir, pour chaque article traduit, un lien direct vers la version dans l'autre langue.

En dehors de la partie blog, je pense que les pages ne sont pas assez nombreuses pour qu'il soit gênant de voir des liens en français et en anglais sur les index de section. (Je n'ai pas d'opinion sur la mise en page de ces index.)

Sur le blog, il suffirait d'ajouter des tags "Français" et "English" pour les visiteurs non bilingues. Si tu veux que les autres tags restent alors "utilisables" pour les visiteurs, ce serait peut-être le moment de permettre le filtrage selon une conjonction de tags. (Au fait, le sont-ils, utilisés, ces tags ?) Il y aurait alors automatiquement 2 sous-répertoires /weblog/tags/<lang>.
Il y aurait éventuellement un "hack" pour n'afficher qu'une seule version des articles bilingues en se basant sur un cookie / le tag utilisé / les préférences du navigateur. Dans la liste des articles, pourquoi pas une présentation en pseudo-onglets pour chaque article, où l'onglet de l'autre langue est un bout de Javascript pour remplacer l'article concerné par sa traduction sans toucher au reste ? Ou alors un "lien permanent" plus accessible (dès le titre), et le switch de langue uniquement sur la page de l'article.
((Au fait, je me suis toujours demandé d'où venait la distinction entre les informations disponibles sur la liste des article (la liste des tags) et sur la page de chaque article (date de publication, état de la bête). Il y a une vraie raison ?))

Si séparation il y a pour tout ce qui est de l'interface, il me semble que la différence entre tes 3 premières idées est cosmétique, et qu'elles ne sont pas forcément incompatibles : instinctive.fr peut être un CNAME vers fr.instinctive.eu (ou l'inverse), etc.

Enfin, je ne vois pas le problème que pose une éventuelle hierarchisation pour des raisons pratiques "en faveur de" ce qui est ta langue maternelle et celle de ce site.

6. Le mercredi 2 juin 2010 à 15:44, par Natacha :

Je ne sais pas dans quelle mesure ça se sent dans mon billet, mais je n'avais pas même pas envisagé la possibilité d'avoir du contenu en français et du contenu en anglais dans la même page. Merci Keeh et W de m'avoir les yeux.

Je n'imaginais pas non plus de ne pas mettre de lien direct entre les équivalents traduits, mais c'est une possibilité que j'aurais pu sereinement négliger. Mon idée était d'ajouter tout en haut de la colonne de droite une section « Traductions » suivie des liens en question.

Pour ce qui est des informations disponibles dans l'index du weblog ou dans les articles, c'est le résultat de la non-reproductibilité d'un template construit à la main, et que je n'avais encore jamais eu de retours dessus c'est resté en l'état. La seule exception est la liste des tags dans la colonne de droite, qui a disparu à la suite d'un souci technique, et depuis je n'ai pas arranger ça pour ne pas y gaspiller de l'énergie sachant que toute façon tout le système sera revu « Bientôt™ ». Si tu as des suggestions quant à ce qui manque ou ce qu'il y a en trop de chacune des visualisation, c'est le bon moment pour me les faire parvenir.

Je n'aime pas la hiérarchisation entre les traductions, principalement parce que ce serait une hiérarchisation statique. Il n'est pas impossible que la version en anglais vienne à prendre plus d'importance que la version en français, et je n'aime pas l'idée d'une hiérarchie dont la seule raison d'être serait historique.

Pour la quantité de page disponibles dans les deux langues, j'avoue que je suis un peu pessimiste. Ça concernera certainement la section Dessins, vu qu'il n'y a pas une grosse charge de traduction, la future section Code, vu que je vise une audience internationale avec ce contenu, et au moins les pages de présentation de la section l'Auteure, pour les non-francophones qui veulent en savoir plus. Pour les histoires, c'est à peu près certains qu'il n'y aura pas de traduction, ou au mieux très peu ; pour les écrits divers il ne faut pas s'attendre à grand chose même s'il y aura probablement des thèmes de portée internationale pour lesquels je ferai l'effort de traduire. Pour le weblog je doute d'avoir souvent la force de traduire, et la section Critique je ne suis même pas sûre qu'il y ait un public pour ça, quelque soit la langue.

Reste le « gros morceau », comment afficher sur une même page les deux traductions, sans que ce soit pénible ni pour les non-francophones, ni pour les non-anglophones, ni pour les bilingues. Je n'aime pas le javascript, mais je ne vois pas trop de façon plus à mon goût de cacher réversiblement une des traductions. Il faudra cependant prévoir quelque chose de pas trop mauvais pour les gens qui n'executent pas le javascript, voire qui n'ont pas non plus de CSS (j'en suis).

À moins de rester sur l'idée de deux pages différentes (ça fait juste un GET pour passer de l'une à l'autre), avec des commentaires communs, mais du coup la liste de commentaires est un contenu dupliqué, et ça c'est Mal™.

Que pensez-vous de l'idée d'avoir les commentaires sur une page différente du contenu (par exemple comme chez David Madore [http://www.madore.org/~david/weblog/], mais avec en plus une page dédiée à chaque billet) ?

J'imagine que ça ne change pas grand chose pour les gens qui lisent les billets depuis l'index ou depuis le flux ATOM, car ils doivent de toute façon cliquer pour accéder à la liste des commentaires ou pouvoir en poster ; il leur manquera juste le texte de l'article pendant la rédaction du commentaire. Par contre ça pourrait être pénible pour ceux qui utilisent le lien direct de la page d'accueil vers les pages des billets, qui auraient alors un clic de plus à faire. Ça concerne beaucoup de monde (c'est une vraie question, je ne crois pas avoir cette info' dans mes logs) ?

7. Le jeudi 3 juin 2010 à 19:42, par W :

En fait il faut distinguer l'interface (les colonnes de droite et de gauche, les pages "index" comme /dessins/, etc.) du "contenu".
Pour ce qui est de l'interface, il serait peut-être plus élégant d'avoir 2 sites séparés, que ce soit par le nom de (sous-)domaine ou par des sous-répertoires, plutôt que d'avoir des colonnes de gauche et de droite 2 fois plus longues contenant une liste de liens de la forme "Dessins / Drawings".
Par contre pour ce qui est du contenu, je pense que tout devrait être accessible depuis les 2 versions du site. Ainsi, /article/, qui est essentiellement une liste de lien, peut très bien contenir des liens vers des articles en français et des articles en anglais (et à une autre URL il y a la "traduction" de /articles/, qui contient exactement la même liste de liens, mais répartis en "Work", "Cooking", etc.)
Pour moi http://en.instinctive.eu/weblog/036-expansion-vers-ou est une URL valide, qui affiche au milieu "Expansion vers où ?\nÇa fait [...]" et à droite "About this article\nPublished [...]".

Je ne pensais pas a priori à du "contenu" (dans le sens "corps d'articles") dans les 2 langues sur une même page, à part dans le cas particulier de /weblog/. D'un autre côté, c'est la façon de faire qui demande le moins de travail. Si sur le blog tu publies un billet sur 10 dans les 2 langues, je pense qu'on ne t'en voudra pas si tu concatènes les 2 versions dans un même billet sans rien changer au moteur du site sur ce point, surtout pour des billets courts. Pour de plus longues (et intemporelles) pages comme /moi/, ça le ferait moins, par contre.

Pourquoi y aurait-il un bout de colonne "Traduction*s*" ? Pour mettre aussi un lien vers la page courante ? Enfin, c'est du détail.

Je ne pensais pas que le fait de mettre en commun les commentaires de 2 versions d'un article (sur la/les page(s) de l'article) poserait problème. Qu'est-ce que c'est que cette histoire de contenu dupliqué ? En quoi est-ce différent de tes articles de blog qui sont lisibles sur leur page propre et sur /weblog/ ?

Enfin, pour les "meta-informations" des billets de blog, je trouve que la date de publication est une information utile qui mériterait de figurer dans la liste des articles (plus que la liste des tags en tout cas).

8. Le lundi 14 juin 2010 à 18:09, par Natacha :

En fait à mon avis, il faut surtout distinguer l'interface de l'URI, et la différence principale est que je peux changer l'interface comme je veux et quand je veux, alors que je suis très réticente à l'idée de changer l'URI d'une ressource. C'est pour ça qu'il faut décider maintenant comment j'organiserai les URI, alors que l'interface peut apprendre que la traduction existe.

Le problème d'avoir deux sites/sous-domaines/sous-répertoires qui présentent le même contenu en ne changeant que la langue de l'interface, comme tu le proposes, est que ça revient vu de l'extérieur à dupliquer le contenu : le corps de chaque article serait accessible par deux URI différentes. Et le problème du contenu dupliqué est surtout au niveau SEO, car la répétition de contenu est un trait typique du spam, donc dupliquer c'est prendre le risque d'être mal classé pour cette raison.

L'index du weblog est effectivement déjà une duplication des billets individuels. Il semblait y avoir de la demande pour une telle page, et le confort de mes lecteurs passe à mes yeux avant la SEO, et ce d'autant plus que le référencement de mon weblog ne m'intéresse pas spécialement, contrairement au reste du site.

Pour le pluriel du titre « Traductions », c'est parce que je prenais ce mot dans le sens « instance d'une idée dans une langage particulière, en sous-entendant qu'il existe au moins une autre instance dans une autre langue ». Peut-être qu'un autre terme serait plus heureux pour désigner ce concept.

La liste sous ce titre aurait effectivement deux éléments, mais qu'un seul lien : on m'a dit qu'il ne faut pas avoir de lien vers la page consultée (pour des raisons ergonimiques cette fois-ci, et non SEO), c'est pourquoi dans toutes les listes sur le côté l'item correspondant à la page affichée non seulement a une présentation différente, mais en plus n'est pas un lieu, juste un texte simple.

Comme demandé, j'ai ajouté la date de publication dans les méta-information de l'index du weblog. S'il y a d'autres demandes sur cette page ou sur une autre, n'hésitez pas à me les faire parvenir.

9. Le mercredi 16 juin 2010 à 19:19, par W :

Ah, je n'aurais pas pensé que les moteurs de recherche se montreraient soupçonneux à partir de 2-3 pages en partie identiques, mais je ne connais rien à la SEO. Et des URLs en ?lang= , ça reviendrait au même ?

10. Le jeudi 17 juin 2010 à 14:13, par Natacha :

Le problème de la SEO, c'est que les règles utilisées par les moteurs de recherches ne sont pas publiques, donc les règles de SEO ça m'a l'air d'être toujours plus ou moins des estimations au doigt mouillé.

Du moins c'était comme ça pendant le premier semestre 2007, j'avoue ne pas m'être tenue informée des évolutions depuis, et dans le monde de l'informatique ce n'est pas si loin que ça d'une éternité.

En tout cas à l'époque, la recommendation était d'éviter même 2-3 pages contenant de grandes portions de texte identiques. De mémoire la justification était les spammeurs qui répliquaient le contenu de sites « honorables » en y mêlant leur spam, ou simplement en gagnant sur la pub' en repompant le contenu des autres. Agréger du contenu en masse leur permettait d'être plus pertinents que les sites sources sur un grand nombre de requêtes, du moins lorsque l'algorithme de classement des pages est assez peu évolué. Dans ce cas, si on n'est la source que d'un ou deux méchants de ce type, il n'y a bien que 2-3 copies du contenu.

C'était d'ailleurs pire que ça, parce qu'il y avait en plus le « problème » des commentaires qui font dériver le champ lexical de la page, et avec en plus des liens « hors-sujet » (attachés aux noms des commentateurs). Donc le weblog idéal ne contenant dans l'index qu'une ou deux phrases de chaque billet, avec un lien « lire la suite » sur une page différente et dédiée, le flux des pages ne contenant pas plus que l'index, pour éviter les duplications dans les agrégateurs genre Planet (par exemple mes billets, en plus d'être présent en deux exemplaires sur mon site, ont également une troisième copie sur [http://planet.komite.net/]), et une fois arrivé sur la page dédié avec le texte complet, il faut encore cliquer une fois pour accéder à une autre page dédiée uniquement aux commentaires.

Après il faut choisir entre le confort des moteurs de recherche et celui des visiteurs.

Cela étant, je ne sais pas du tout à quoi ressemble le SEO aujourd'hui, et en toute franchise je ne suis clairement pas assez intéressée pour suivre l'évolution de tout ça. J'ai pris deux trois "rules of thumb" à l'époque pour éviter de me plomber complètement aux yeux des moteurs de recherche ; si quelqu'un a des informations simples et à jour, je les prends volontiers.

11. Le jeudi 17 juin 2010 à 20:54, par W :

Tout en redisclaimant que je ne connais rien à la SEO, je pense qu'une simple observation de ce qu'on trouve sur le Web permet de relativiser un peu tes rules of thumb.

En effet, ce que tu appelles duplication de contenu me semble être le lot d'un très grand nombre de sites tout à fait légitimes. Un billet de blog qui apparaît une fois sur "/", une fois sur /page/1, une fois sur chaque /tags/sometag, et une fois avec des commentaires en dessous, il n'y a rien de plus courant. Et que dire d'un article d'un wiki (MediaWiki par exemple), dont l'historique consiste en une collection de pages en grande partie identiques ?
Quant aux paramètres "GET" dans une URL, parfois ils sont pertinents pour distinguer des pages (les wikis en index.php?page=ArticleName), et parfois pas du tout (?setcookie=quesaisje, etc.).

Il me semble donc qu'un moteur qui utiliserait un algo naïf à base de détection de contenu dupliqué serait en pratique un très mauvais moteur de recherche.
Si j'étais un moteur de recherche, je chercherais à repérer au sein d'un site donné les pages qui se ressemblent beaucoup et je choisirais celle qui me semble la plus pertinente comme "représentante" des autres. Cette représentante aurait un "pagerank" calculé comme si les autres n'existaient pas, et les autres n'apparaîtraient pas dans les résultats de recherche, sauf quand l'internaute demanderait à voir les "pages à contenu similaire".

Au fait, merci d'avoir mis la date des articles sur /weblog/. J'en profite pour une autre suggestion : ce serait faisable que le système de prévisualisation d'un commentaire renvoie directement, dans la page de prévisualisation, vers l'ancre dudit commentaire ? Pour l'instant et au moins chez moi, on arrive en haut de la page qu'il faut alors faire défiler.

12. Le jeudi 17 juin 2010 à 23:17, par Natacha :

Ce n'est pas parce qu'on trouve de nombreux exemples d'une certaine pratique qu'il faut la suivre. Donc le nombre de sites qui ont du contenu identique disponible par plusieurs URI n'est aucunement une indication que ce soit bon ou neutre en termes de SEO (surtout vu la quantité de webmasters complètement ignares en SEO). Cela dit je concède que ce nombre est une bonne indication que ce n'est probablement pas drastiquement handicapant.

D'ailleurs en y repensant, je ne vois aucun intérêt pour un spammeur/profiteur de dupliquer du contenu sur son propre site, et il n'y a pas de raison pour qu'il ait accès en écriture au contenu du site source (sinon on est dans un tout autre niveau de méchanceté), donc il n'y a pas de raison pour qu'un moteur de recherche pénalise la duplication de contenu au sein d'un site, même si un Planet peut encore se retrouver être collatéralement nuisible. Du coup ça répondrait à une partie des questions de mon billet, à savoir qu'il vaut mieux éviter d'utiliser un autre domaine, peut-être par précaution éviter aussi d'utiliser un autre sous-domaine, et déterminer la langue suivant le chemin dans l'arborescence d'instinctive.eu.

Ou alors laisser tomber complètement l'argument SEO en prêtant assez de complexité, sinon d'intelligence, aux moteurs de recherche pour se rendre compte qu'il n'y a pas malice. Surtout si je les aide à coups de balises <link>.

Sauf que laisser tomber des arguments ne m'aide pas vraiment à choisir, au contraire.

Le problème de la prévisualisation qui arrive en haut est malheureusement plus compliqué à résoudre, parce que comme je ne veux pas stocker la prévisualisation (et techniquement ce serait lourd d'ajouter ce stockage au code existant, ce qui est d'autant moins motivant qu'une réécriture est prévue dans les mois qui viennent) je ne peux pas répondre au POST par une redirection, je suis obligée de répondre 200 avec la page contenant la prévisualisation ; mais à ce stade l'URI est déjà fixée, et à moins de sortir l'artillerie lourde (JavaScript) je ne vois pas comment faire.

En fait il y a deux minutes je viens de trouver une idée, j'ai ajouté un fragment à l'URI à laquelle POSTer la form. Mes premiers essais ont l'air de marcher, merci de vérifier que ça a bien l'effet attendu et surtout que ça ne casse rien sur autant de navigateurs que possible (j'ai surtout peur de navigateurs qui oublient de retirer le fragment de l'URI avant de faire la requête, ce qui se terminerait (fâcheusement) en 404). Je vous conseille donc de copier/coller dans un endroit sûr vos textes avant de les prévisualiser ou de les envoyer. Même si les commentaires sont cassés le formulaire de contact [http://instinctive.eu/contact] devrait encore fonctionner, merci de me le signaler par là.

13. Le vendredi 18 juin 2010 à 0:36, par W :

Le #previewed marche impeccable dans Firefox et Konqueror pour la prévisualisation. Il y a vraiment des navigateurs qui envoient cette information ?
Par contre, je soupçonne (ceci est un test) que ça renvoie le problème à la validation. Même si c'est moins gênant, pourquoi pas un simple #commX où X est le numéro du dernier commentaire + 1 ? L'ancre existe déjà dans la prévisualisation.

Pour la perte de contenu de formulaire Web, je conseille l'extension (Firefox) Lazarus, ça marche très bien.

14. Le vendredi 18 juin 2010 à 0:42, par W :

Au temps pour moi, j'avais oublié ce qui fait qu'il n'y a pas de problème.

15. Le samedi 19 juin 2010 à 23:57, par W :

Je vais me prendre un procès antitrust pour ma présence dans les Derniers commentaires, mais j'ai encore 2 suggestions :

¤ Dans l'optique de l'utilisation de la page d'accueil du site comme tableau de bord pour voir ce qu'il y a de neuf, et vu que là où il y a le plus souvent du neuf, c'est dans les commentaires, je propose que la rubrique "Syndicalisation" disparaisse du haut de la colonne de droite et se retrouve en bas d'une des 2 colonnes.
Je pense qu'elle pourrait tenir en bas de la colonne de gauche sous une forme plus condensée du genre :
== Flux ATOM ==
* Annonces
* ...
* Toutes les pages

¤ Je suggère que dans les commentaires, le motif <star><nbsp>, de même que <star><space>, ne soit pas interprété comme le début d'une mise en valeur.

16. Le lundi 21 juin 2010 à 18:04, par Natacha :

> Le #previewed marche impeccable dans Firefox et Konqueror pour la prévisualisation. Il y a vraiment des navigateurs qui envoient cette information ?

Je suis devenue méfiante depuis que j'ai vu des fragments dans les logs serveur, alors que ça devrait être enlevé par le client. Cela dit vérification faite, ce sont à chaque fois des robots qui font cette erreur, je suppose qu'au moins les navigateurs les plus populaires ne font pas cette erreur. Quoique vu le passé d'Internet Explorer vis-à-vis des standards, il y a de quoi se méfier.

Idéalement il faudrait que le serveur détecte et supprime un éventuel fragment, pour rester dans le principe d'être laxiste sur les entrées et strict sur la sortie. Mais il faut coder, donc plutôt intégrer ça à la future nouvelle version qu'ajouter ça au code quasi-obsolète existant.

> pourquoi pas un simple #commX où X est le numéro du dernier commentaire + 1 ?

Parce que le numéro du dernier commentaire peut changer entre le moment où tu charges la page et celui où tu envoies la prévisualisation. Bon ok, vu le trafic de ce site, ça a très peu de chances d'arriver, mais par principe…

> je propose que la rubrique "Syndicalisation" disparaisse du haut de la colonne de droite et se retrouve en bas d'une des 2 colonnes.

En fait plus généralement dans cette colonne, les quatre éléments sont classés du plus statique au plus dynamique. Ce n'est pas du tout voulu, mon idée initiale était de les classer par ordre d'importance. J'imagine que dans une optique « tableau de bord » l'ordre inverse pourrait effectivement être plus pertinent. Quoique l'importance à mes yeux des ajouts non-weblog, surtout vu leur fréquence, me semble mériter d'être au dessus du reste. Ce n'est pas évident tout ça, je vais y réfléchir.

Je ne sais pas si c'est une si bonne idée que ça de le déplacer en bas de la colonne de gauche, car pour l'instant cette colonne est statique sur tout le site, seule la colonne de droite varie (et dans cette colonne, seule la première section change d'un article à l'autre d'une même section). Il me semble bon de conserver ces invariants.

L'idée de factoriser « Flux ATOM » dans le titre n'est pas mal, mais du coup je ne pourrai plus parodier les gens qui semblent croire que « syndication » existe en français.

Cela étant, j'envisageais une refonte du design, et demander l'avis du public dans un billet prochain, surtout pour le rendre plus accessible aux petits terminaux. J'envisageais de transformer la barre de gauche en un bandeau en haut pour mettre le contenu tout à gauche ; ensuite j'hésitais entre donner au contenu toute la largeur de la page (au risque de perdre en lisibilité sur les écrans classiques à cause des lignes trop longues) et mettre la colonne de droite sous forme de bandeau en bas, ou laisser une largeur fixe au contenu et découper la colonne de droite en flottants pour qu'ils se répartissent dans la place restante s'il y en a et au besoin en dessous.

> Je suggère que dans les commentaires, le motif <star><nbsp>, de même que <star><space>, ne soit pas interprété comme le début d'une mise en valeur.

Ça commence à être une réponse récurrente, mais là encore je suis réticente à changer le code existant en raison de la réécriture prochaine. Les futurs commentaires seraient formattés par un sous-ensemble de Markdown. Cela dit, dans mon implémentation de Markdown (et pour autant que je sache aussi dans toutes les autres) <star><space> ne peut pas commencer une mise en valeur, contrairement à <star><nbsp>. Par contre utiliser un moteur Markdown permet d'utiliser <backslash><star> pour obtenir une étoile littérale quelque soient les circonstances. Je ne sais pas dans quelle mesure cela répondrait à tes attentes.

17. Le lundi 21 juin 2010 à 19:37, par W :

Mes suggestions sont générales hein, elles peuvent être comprises aussi bien dans le cadre de la réécriture du site que comme d'éventuelles mises à jour de la version en production, et je ne vais pas faire la grève de ma consultation du site si elles ne sont pas implémentées dans les 48h.

Pour les flux Atom, il me semble que c'est une chose dont on n'a besoin qu'une fois, donc que ce n'est pas très grave si ce n'est pas idéalement situé, du moment que ça reste visible.
Pour info, point de vue d'un utilisateur : savoir que telle colonne est statique me semble ne m'être d'aucune utilité. En fait je crois que je n'y avais jamais pensé.

Je ne connais pas très bien Markdown, mais ça me semble assez bête de comprendre <star><nbsp> comme un début de mise en valeur vu que ça n'apporte aucune expressivité (c'est synonyme de <nbsp><star>), même si j'admets que c'est être un gros geek maniaque que de mettre des <star><nbsp> pour faire une liste à puce.
Par curiosité, pourquoi Markdown plutôt que Creole, qui est virtuellement plus connu en tant que tentative de normalisation des syntaxes wiki (et plus compact pour les liens, et plus intuitif pour ce qui est du **gras** - //italique// - __souligné__, et... bref) ?
Un backslash, pourquoi pas, du moment que ce soit documenté dans [#commformat] :-)

Pour #commX, juste pour avoir raison dans le mauvais sens de l'expression, on pourrait très bien souhaiter, tout en écrivant un commentaire, voir le cas échéant ceux qui sont postés pendant ce temps.

18. Le mardi 22 juin 2010 à 11:01, par Natacha :

Et pourquoi un nbsp plutôt qu'un U+2002 ?

Le fond du problème, c'est qu'en fait nbsp c'est un caractère qui est visuellement vide (et de largeur non-nulle) tout en n'étant pas un blanc (whitespace). J'ai tendance à penser que c'est l'essence même de nbsp, mais je concède que c'est discutable ; en tout cas c'est indubitablement une bonne approximation.

Or dans les règles de formattage actuelles, le début d'une mise en valeur est marqué par une étoile placée entre un blanc et un mot, et symétriquement la fin est marquée par une étoile placée entre un mot et un blanc. Comme nbsp n'est pas un blanc, il compte comme le premier caractère d'un mot.

Markdown est plus réactif : de base une étoile marque toujours le début ou la fin d'une mise en valeur, et les exceptions sont lorsqu'elle est échappée par un antislash, et une étoile suivie par un blanc ne peut commencer une mise en valeur, et symmétriquement pour la fin. L'idée est que la convention est de ne pas avoir de blanc au début et à la fin de la mise en valeur, et comme le même marqueur est utilisé pour marquer le début et la fin, cette règle empêche une erreur locale (étoile mal reconnue ou manquante) de se propager trop loin dans le document.

Pour le cas particulier des listes à puce, <star><nbsp> va aussi être problématique, car en Markdown une telle liste est marquée par une étoile (ou un plus ou un tiret) en début de ligne suivie d'un blanc, pour éviter la confusion avec une mise en valeur. Et comme le retour à la ligne juste avant le début de ligne est lui aussi un blanc, cette étoile ne peut pas non plus marquer la fin d'une mise en valeur, ce qui rend le tout joliement orthogonal.

Et même si on considérait philosophiquement nbsp comme un blanc authentique, ce serait très peu pratique à coder : on ne pourrait plus être agnostique sur l'encodage, donc il faudrait passer par des wchar_t, avoir une fonction externe spécifique localisée pour déterminer si un code-point est un blanc ou non. Beaucoup d'efforts de code et de machine, tout ça pour quel bénéfice déjà ? Séparer sémantiquement l'étoile du mot qui la suit ?

Quant au pourquoi de Markdown plutôt que Creole, je répondrais parce que ce dernier n'est effectivement que virtuellement plus connu. J'ai eu le temps de découvrir Markdown, ses extensions (notamment Discount), Setext, reStructuredText et il me semble quelques autres qui ne me reviennent pas ; ensuite d'hésiter sur lequel implémenter, et ceux qui me connaissent savent à quel point j'hésite longtemps ; et ensuite d'implémenter ce qui était parti pour être un convertisseur Markdown étudu vers HTML, qui s'est retrouvé être un parseur de Markdown à callbacks. Et je ne découvre ton Creole que dans ton commentaire.

Et quand bien même j'en serais encore à choisir quel système de marquage choisir, Markdown l'emporterait haut la main sur Creole, principalement parce que ce dernier est nettement plus limité que Markdown, surtout étendu. J'imagine que Creole est très bien pour quelque chose d'aussi limité qu'un wiki, et pour les lusers technophobes facilement effarouchables. Je me suis intéressée à Markdown à l'époque où j'avais jeté à un X à la poubelle [http://instinctive.eu/weblog/029-perte-de-x] et où j'étais tentée de jeter le HTML avec. D'ailleurs ça a finalement eu lieu, tous mes billets de 2010 sont rédigé dans un Markdown à peine étendu et convertis à la volée en HTML. Cela n'aurait pas été possible avec un langage qui ne permet pas d'inclure des BLOCKQUOTE, des DIV d'une classe donnée, des P avec une classe, des INS, des DEL, des SPAN avec ou sans classe, des ABBR, etc.

Je n'ai pas pris le temps de vérifier en profondeur si Creole permet d'inclure du (X)HTML brut pour pallier ce manque, mais même si c'était le cas, je ne veux pas d'un source bâtard avec des bouts de markup « humain » et des bouts de HTML. Si j'abandonne HTML c'est pour de bon (des exceptions sont possibles mais doivent être très ponctuelles, par exemple mon utilisation des balises Q est assez rare pour les faire en HTML).

Je n'aime pas trop les « liens bruts » de Creole, mais c'est personnel, par contre dans les commentaires c'est juste hors de question dans que le spam existera. J'aime beaucoup le système de liens par référence de Markdown, ça améliore nettement la lisibilité en cas de liens de répétés et en cas de terminal étroit (ce qui est mon cas, toujours 80 colonnes, le retour à la ligne automatique interagit très mal avec la plupart des URI) ; mais je ne suis pas sûre que ça compte parce que je ne l'ai découvert qu'à l'usage, ce qui est hors de l'hypothèse que j'en sois encore au choix du langage de formattage.

Cela dit ces raisons parlent surtout du Markdown pour moi, et les commentaires n'en auront qu'une version très allégée. Creole pourrait suffir, même si son manque de BLOCKQUOTE, INS et DEL pourrait m'embêter, mais les liens bruts et l'inexistance de lien interne font que de toute façon ce ne serait pas du vrai Creole. Peut-être qu'un jour il sera possible de choisir le style de formattage dans une liste déroulante, par exemple entre Markdown, Textile, Créole et rien ; le futur moteur aura tout ce qu'il faut pour que ce soit possible, il ne manquera que les moteurs de conversion. En attendant, le moteur de Markdown existe déjà, et à court terme il n'y aura que ça.

Par contre en raison de la complexité de Markdown (mais Creole est aussi trop complexe) il n'y aura plus de #commformat, le formattage sera expliqué dans une page dédiée.

19. Le mercredi 23 juin 2010 à 9:34, par W :

En fait ce que je disais pour nbsp aurait pu s'appliquer à tout caractère "visuellement vide", puisque comme tous les autres caractères on pourrait vouloir faire précéder ceux-ci d'une étoile, mais que comme l'espace et contrairement aux caractères non vide, les mettre en gras n'a aucune utilité (me semble-t-il).
Mais bon, c'est pas grave si c'est trop difficile ou casse-pieds à faire, j'ai bien posté des commentaires pendant plus d'un an sans me rendre compte du "problème".

Et ok pour Markdown, c'était juste pour savoir, c'est pas une question de religion ; il serait assez overkill d'avoir le choix du formattage.

20. Le jeudi 24 juin 2010 à 18:11, par Natacha :

J'ai la faiblesse de penser que la largeur d'une espace grasse n'est pas forcément la même que celle d'une espace maigre, mais je peux me tromper, je ne suis pas typographe :-) Cela dit, si l'utilité est douteuse, je ne vois aucun inconvénient à vouloir graisser les caractères vides en bordure de caractères non-vides. Comme HTML permet de le faire, j'aurais même tendance à voir d'un mauvais œil l'impossibilité de le faire dans un mark-up. Je n'ai choisi et embrassé la solution de mes commentaires et de Markdown pratiquement que parce qu'il s'agit d'une convention dont j'ai l'habitude (principalement à force d'utiliser quotidiennement w3m et newsbeuter et dans une moindre mesure IRC), avec l'intérêt déjà évoqué de différencier ouverture et fermeture de mise en valeur pour éviter les déphasages à longue portée.

Par contre l'implémentation concrète de « gérer de la même façon tous les caractères blancs » est tellement pénible et/ou sale que ce ne sera probablement jamais mis en place, à moins de me faire miroiter de très très bonnes raisons d'y passer.

Quant à mon Markdown, j'espère que mon argumentaire n'a pas donné l'impression qu'il s'agit d'un choix « religieux », parce que vu d'ici, il s'agit au contraire d'un des argumentaires les plus rationnels qu'il m'ait été donné de vivre, ce qui n'est plutôt pas mal pour quelqu'un d'aussi instinctive que moi. Par exemple pour Markdown vs Textile, à peu près tous les arguments rationnels que je trouve sont en faveur de Textile, et pourtant je préfère Markdown.

Le choix du formattage ne me semble pas si overkill que ça : vu la complexité de Markdown (et comme dit, malgré sa relative simplicité Creole est trop complexe pour ne pas susciter exactement les mêmes réflexions), il me semble indispensable de permettre aux commentateur de « s'en foutre » et de ne pas lire et apprendre toutes ces règles. Autrement dit, il s'agit de laisser le choix entre aucun formattage (pour être sûr que les caractères actifs ne fassent pas n'importe quoi) et Markdown. À partir de là, vu ma façon de coder, je ne vais pas me contenter de laisser le choix entre deux alternative, je vais proposer un nombre arbitraire de moteurs de conversion texte POSTé → (X)HTML. À partir de là ce n'est plus qu'une question d'interface (une case à cocher pour deux possibilités, un menu déroulant pour vingt-cinq) et d'embarquer les moteurs adaptés.

D'ailleurs ça permettra de faciliter la migration, vu qu'actuelement une partie des commentaires existants sont enregistrés en HTML, et le reste en texte POSTé avant formattage ; je n'aurai qu'à leur attribuer un moteur de rendu « copie directe » ou « formattage historique », moteurs qui coexisteront avec les deux évoqués ci-dessus. J'ajouterai probablement aussi un « Markdown débridé » pour mes commentaires perso'.

Est-ce réellement si overkill ?

Poster un commentaire

Nom ou pseudonyme :

Adresse e-mail (facultatif, ne sera pas publié) :

Site web (facultatif) :

Format de mise en forme : format historique Markdown restreint

Enregistrer ces informations dans un cookie

Commentaire (sera publié dans cette page, voir les conseils de mise en forme ci-dessous) :

Message personnel (ne sera pas publié) :

Mise en forme historique : pour mettre en valeur un mot ou un groupe de mot, tapez une étoile de part et d'autre, sans mettre d'espace entre l'étoile et le mot, comme ceci : *mise en valeur*. Pour insérer un lien, mettez le entre crochets, comme ceci : [http://instinctive.eu/].

Mise en forme markdown : voir le guide détaillé, en résumé c'est le Markdown traditionnel, sans HTML ni titres, mais avec les tables PHP-Markdown-Extra.

Attention : les balises HTML entrées dans les commentaires seront affichées telles quelles, et non pas interprétées.