Faire un site statique sans javascript

[hydrargyrum]

Il est fort dommage que le site bitoduc.fr ne fonctionne absolument pas sans javascript, alors que son contenu est très statique, et que github utilise jekyll, qui permet de définir des modèles HTML remplis par des fichiers JSON.

Ayant des capacités de développeur toile très limité, considérez cette fusio-demande comme une simple preuve de concept. Le résultat (fort laid, car comme indiqué, je suis une bille en CSS et HTML) peut-être admiré ici : https://hydrargyrum.github.io/bitoduc.fr

[p0nce]

Ami de la collaboration, avec un petit « c », bonjour et bienvenue sur notre gestionnaire de bogues. Un lieu de conflits et de passion dont vous serez, je l'espère, un contributeur actif.

Je prends pleinement la mesure de vos inquiétudes. A SoulakLabs, nous ne sommes pas de grands partisans d'ECMAScript, fut-il 5 ou 6, 2015 ou 2016. Disons-le tout net : il s'agit certes d'un moindre mal. Mais d'un mal tout de même. Vivre avec Javascript, c'est laisser s'installer un malaise, une micro-tumeur qui contient la misère du monde en puissance. En tant que langage, il n'est pas non plus culturellement neutre : chaque mot-clef nous rappelle une certaine domination anglo-saxonne et notre propre duplicité.

Or, comment s'en passer ? Nous avons effectivement besoin d'un index bidirectionnel (Français vers Anglais et vice versa) ; ainsi que d'une fonction de tri (trium functare) pour regrouper les termes par première lettre.

Javascript est actuellement ce qui nous permet de ne pas dupliquer l'information. Dans nos pages francisées, il apparait dans sa simplicité non-impérialiste et dénué d'intention, au point qu'on pourrait parlait d'un ECMAScript « Libre ».

Comme vous vous y attendiez peut-être, nous ne pouvons donc que refuser votre aimable proposition, à moins que l'information, qui a envie d'être unique en sa source, le reste effectivement. Ce sont donc des raisons technologiques qui viennent avec leur propres contraintes.

Un schéma qui conviendrait bien, serait d'avoir la liste de mots en XML et d'afficher un site en XSLT. Non seulement c'est plus compliqué, mais personne ne le fait, et ça marche peut-être encore sur les butineurs actuels. C'est une idée que je devrais soumettre, si le temps était moins rare.

Je reste à vos côtés suite à ce rejet informel, et vous adresse, avec un seul « d », mes salutations.

[chmduquesne]

J'ajoute que même si nous pourrions maintenir deux pages, l'une français vers anglais et l'autre anglais vers français, en faisant une telle manipulation nous mettrions en péril les applications tierces utilisant le fichier json qui contient la source des traductions.

Il existe en effet des robots irc qui consomment ce fichier pour corriger les fautes au fil de la conversation. Nous avions aussi le projet de faire un automate twitter qui ferai la même chose aux tweets des afficionados de l'anglicisme. Tout ceci serait rendu impossible par votre contribution.

[chmduquesne]

Le plugin supybot concerné (je ne sais pas s'il y en a d'autres).

[hydrargyrum]

Vous n'avez, semble-t-il, pas pris le temps de regarder ma contribution.

En effet, le fichier JSON contenant les traductions est bien conservé. La page ang-fra.html se contente de lire le JSON. Une page similaire fra-ang.html peut être écrite, elle aussi en lisant le même fichier JSON, donc sans engendrer de duplication, ni casser quoi que ce soit. L'étape d'intégration du JSON dans le HTML est fait par l'outil jekyll à la génération pour un serveur web uniquement. Le JSON peut continuer d'être servi comme fichier séparé.

[chmduquesne]

Cela obligerait à faire tourner Jekyll avant chaque publication. Si vous trouvez un moyen que ce processus soit automatisé avec Travis, je n'y suis pas opposé. La contrainte imposée est qu'une contribution soit pouvoir se limiter à la modification de ce JSON, sans étape supplémentaire pour le contributeur ni pour l'intégrateur. Ce n'est que mon avis, il faut attendre celui d'autres contributeurs réguliers avant de prendre une décision.

Notez que nous perdrions aussi le JavaScript français de bitoduc, que j'affectionne particulièrement et dont je vous recommande la lecture.

On Fri, Nov 4, 2016, 16:58 hydrargyrum notifications@github.com wrote:

Vous n'avez, semble-t-il, pas pris le temps de regarder ma contribution.

En effet, le fichier JSON contenant les traductions est bien conservé. La page ang-fra.html se contente de lire le JSON. Une page similaire fra-ang.html peut être écrite, elle aussi en lisant le même fichier JSON, donc sans engendrer de duplication, ni casser quoi que ce soit. L'étape d'intégration du JSON dans le HTML est fait par l'outil jekyll à la génération pour un serveur web uniquement. Le JSON peut continuer d'être servi comme fichier séparé.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/soulaklabs/bitoduc.fr/pull/119#issuecomment-258471637, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOUMA7oZDmhVmbXxaS9l0_cucEM6Anyks5q61YvgaJpZM4KppaZ .

[chmduquesne]

Question subsidiaire: pouvez-vous expliquer pourquoi vous trouvez dommage que le site ne fonctionne pas sans JavaScript? Le JavaScript en question n'est pas d'une lourdeur incroyable, et pour moi la seule raison d'invoquer un outil ne sachant pas exécuter JavaScript sur celui-là serait afin d'effectuer une tâche de programmation, chose pour laquelle le fichier JSON à été prévu. Du coup dans le cas présent je trouve l'argument invoqué, « c'est dommage », un peu faible s'il n'est pas étayé d'une explication.

On Nov 4, 2016 17:06, "Christophe-Marie Duquesne" chmd@chmd.fr wrote:

Cela obligerait à faire tourner Jekyll avant chaque publication. Si vous trouvez un moyen que ce processus soit automatisé avec Travis, je n'y suis pas opposé. La contrainte imposée est qu'une contribution soit pouvoir se limiter à la modification de ce JSON, sans étape supplémentaire pour le contributeur ni pour l'intégrateur. Ce n'est que mon avis, il faut attendre celui d'autres contributeurs réguliers avant de prendre une décision.

Notez que nous perdrions aussi le JavaScript français de bitoduc, que j'affectionne particulièrement et dont je vous recommande la lecture.

On Fri, Nov 4, 2016, 16:58 hydrargyrum notifications@github.com wrote:

Vous n'avez, semble-t-il, pas pris le temps de regarder ma contribution.

En effet, le fichier JSON contenant les traductions est bien conservé. La page ang-fra.html se contente de lire le JSON. Une page similaire fra-ang.html peut être écrite, elle aussi en lisant le même fichier JSON, donc sans engendrer de duplication, ni casser quoi que ce soit. L'étape d'intégration du JSON dans le HTML est fait par l'outil jekyll à la génération pour un serveur web uniquement. Le JSON peut continuer d'être servi comme fichier séparé.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/soulaklabs/bitoduc.fr/pull/119#issuecomment-258471637, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOUMA7oZDmhVmbXxaS9l0_cucEM6Anyks5q61YvgaJpZM4KppaZ .

[p0nce]

Est-ce que nous débarrasser de JavaScript signifie devoir installer Ruby? Dans ce cas j'ai bien peur que l'on soit dans un jeu à somme nulle.

[hydrargyrum]

@chmduquesne github lance eux-mêmes jekyll, vous n'avez donc rien à faire. J'en veux pour preuve le lien que j'ai mis précédemment, on consulte le fichier HTML final avec les mots français et anglais, alors que vous constaterez que je n'ai soumis qu'un modèle HTML sur ma fusiodemande. Il suffit de modifier le fichier JSON et jekyll (lancé par github) s'occupera des fichiers HTML finaux.

Qu'appelez vous le "javascript français" ?

Quant à la question de pourquoi faire sans javascript, sachez tout d'abord que je pense que bitoduc peut conserver du javascript, mais uniquement pour des fonctionnalités supplémentaires, comme des infobulles, qui ne sont pas indispensables à la lecture. Maintenant, pourquoi ne pas rendre javascript obligatoire pour la partie essentielle du site ? Il y a de multiples raisons. Javascript est désactivé chez un nombre croissant de personnes à cause de problèmes de sécurité et de vie privée (voir le succès de l'extension noscript). Dans un tout autre domaine, javascript n'est pas forcément interprété par les "lecteurs d'écrans" que sont les navigateurs pour personnes malvoyantes. Ensuite, les moteurs de recherche ne l'interprètent pas non plus et le contenu de bitoduc ne sera donc pas indexé.

@p0nce un contributeur n'a pas besoin d'installer jekyll pour ajouter une traduction. Seul ceux qui voudront modifier le modèle HTML pourraient en avoir besoin pour tester leur modèle. Quant à troquer javascript contre jekyll, ils ne sont pas au même niveau : l'un est imposé au visiteur, l'autre est utile à un type de contributeur. Les programmes doivent être au service de l'utilisateur (le visiteur), c'est pourquoi il faut pencher du côté de jekyll plutôt que javascript à mon avis.

[hydrargyrum]

Pour l'index bidirectionnel, je dois avouer n'avoir pas pris la peine de faire la page de démonstration français-anglais. Je corrigerai ce manque quand j'aurais accès à un ordinateur avec un véritable clavier et la démonstration de la non-duplication sera plus évidente.

[p0nce]

Cher @hydrargyrum

Il semble en effet que nous ayons évalué un peu vite votre proposition. Non seulement le fichier JSON de traductions est bien en place, mais ce système de patrons permet de ne plus générer le "DOM" dynamiquement.

Le bouton pour passer de Français à Anglais et inversement a toujours été bancal, voire indécouvrable. Je pense qu'une seule page statique avec les deux sens de traduction dans des sections successives serait plus lisible et indexable comme vous le dites. De plus <dt> et <dd> peuvent fournir une information sémantique qui manque cruellement en l'état. Il faut penser à la Toile sémantique !

<dl>
{% for trad in site.data.traductions['vrais mots'] %}
<dt>{{ trad['anglais'] }}</dt>
<dd>{{ trad['français'] }}</dd>
{% endfor %}
</dl>

Si on applique cette boucle 26 fois, avec un filtre Jekyll approprié qui sélectionne telle ou telle première lettre (je ne l'ai pas trouvé dans https://jekyllrb.com/docs/templates/), alors on aura le meilleur des deux mondes.

Toute proposition qui complique notre pile technologique est bonne à prendre. Peut-être êtes-vous celui (ou celle) qui parviendra à contribuer à bitoduc.fr?

J'émet donc un avis positif, conditionné par le fait que l'on trouve un moyen Jekyll de regrouper par première lettre.

[progval]

J'émet donc un avis positif, conditionné par le fait que l'on trouve un moyen Jekyll de regrouper par première lettre.

Ceci pourrait aider : http://stackoverflow.com/a/19104574/539465

[chmduquesne]

Par JavaScript français, j'entends JavaScript écrit en bon français, correctement accentué et orthographié. Les programmes d'aujourd'hui ont trop souvent tendance à être écrits en anglais. Combattons les anglicismes!

https://github.com/soulaklabs/bitoduc.fr/blob/gh-pages/js/principal.js https://github.com/soulaklabs/bitoduc.fr/blob/gh-pages/js/prototypes-fr.js

On Sat, Nov 5, 2016, 08:47 Valentin Lorentz notifications@github.com wrote:

J'émet donc un avis positif, conditionné par le fait que l'on trouve un moyen Jekyll de regrouper par première lettre.

Ceci pourrait aider : http://stackoverflow.com/a/19104574/539465

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/soulaklabs/bitoduc.fr/pull/119#issuecomment-258596906, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOUMODjE2eJRVxNDdI0Ov_eDX-fZGPWks5q7DSRgaJpZM4KppaZ .

[hydrargyrum]

Merci @ProgVal pour le lien.

Voici une nouvelle version avec les traductions dans les 2 sens sur la même page ainsi que l'index des lettres : https://hydrargyrum.github.io/bitoduc.fr C'est très laid car je n'ai appliqué aucun CSS. Comme dit précédemment, un peu de Javascript est tout à fait possible, mais pour des fonctionnalités dispensables.

Un point regrettable cependant : le tri des lettres appliqué par Jekyll place le "É" après le "Z"...

[p0nce]

En effet la version Javascript enlève les accents avant de regrouper. C'est regrettable qu'il n'y ait rien de tel dans votre version Jekyll. Peut-être faut-il enlever les accents des traductions en attendant ?

Ca m'a l'air bien mais il faut encore faire le travail de porter le reste de la page. Mais qui va le faire?

[chmduquesne]

La fonction qui enlève les accents a été écrite en se servant de la liste exhaustive des diacritiques utilisés en français. Je vous suggère de vous en inspirer (à moins que jekyll ne dispose d'une fonction de type unidecode, une librairie python incroyable qui ne trouve malheureusement pas son pendant javascript).

[chmduquesne]

Je continue à me ranger du côté des non convaincus. Le fait que github support Jekyll vous permet de passer outre l'étape de génération, mais cela rend le site dépendant de la plateforme. Aujourd'hui nous pouvons déployer le html statique en local sur notre machine ou sur n'importe quel hôte munit d'un serveur web. Après une telle modification, ce ne sera plus le cas.

[chmduquesne]

On peut arguer du fait que le site est déjà dépendant de github (le fichier CNAME), mais cette dépendence est minime et le travail pour changer d'hôte n'est en rien comparable avec celui lié à avoir Jekyll. Par ailleurs quitte à compiler le site, ça me gêne qu'on prenne Jekyll sans concertation plutôt que d'étudier les alternatives. Par exemple, un template jinja pourrait aussi faire l'affaire.

[p0nce]

En effet, il serait de bon ton d'évaluer nos alternatives.

[hydrargyrum]

@chmduquesne Je n'ai pas grand chose à ajouter à mon message précédent. L'un favorise le plus grand nombre, le simple visiteur du site, que ce soit un humain ou un moteur de recherche, l'autre ne favorise qu'un éventuel contributeur, et encore... Le site a un ton humoristique mais le sujet est pourtant réellement utile, je pense qu'il gagnerait à être plus accessible et plus diffusé.

[p0nce]

Cette FD est rendue obsolète par #137, quoique supérieure en quantité de prose.