La graine de Marcimat

Vœux 2020

Matthieu Marcillaud — 2020-01-06T23:41:22Z

Je nous souhaite des petits plaisirs
et de grandes passions
de longs et tendres câlins
des rires écarlates à foison
de raviver les bons souvenirs
de flâner ça et là sans raison
d'être guillerets dès le matin
en profitant de chaque saison

Je nous souhaite une force démesurée
pour braver tous les soucis,
et danser pieds nus dans les jardins
accompagné de ses amis
l'esprit tranquille, le cœur en paix
en exprimant ses ressentis
et de prendre un magistral soin
et de ses proches et de la vie

Vœux 2018

Matthieu Marcillaud — 2018-01-05T13:35:14Z

Je vous espère quelques tendres moments, quelques destinations imprévues, quelques rêves ébouriffants, quelques sottises farfelues, et embrasser dans chaque instant une passion même saugrenue, de celles qu'on se livre en chantant, rien ne serait trop superflu.

Je nous espère un avenir meilleur, une Terre choyée sans démesure, des rires humains bravant les peurs, de l'entraide entre chaque culture, et accepter ces changements, et tous ces défis d'envergure, ce climat fou hantera tant, rien de nos gestes n'est fioriture.

Crayon de mots pour un article

Matthieu Marcillaud — 2014-01-21T11:15:27Z

Pour les besoins d'un projet en SPIP 3 (utilisant spipr-dist), nous voulions sélectionner les mots clés attribués à un article depuis l'interface publique de SPIP, de façon rapide via les crayons, et cela pour plusieurs groupes de mots clés.

La problématique est assez proche de l'article « Un crayon listant des liaisons », mais actualisé pour SPIP 3 et avec quelques subtilités. Vous aurez tout intérêt à le relire si vous vous intéressez aux crayons. Nous ferons également ici un plugin pour pouvoir réutiliser la chose un peu plus simplement.

Problématique

Comme indiqué, nous devons pouvoir éditer ici des liaisons entre les mots clés d'un certain groupe et un article. Ce n'est pas, donc, la fonction première des crayons qui permettent, sans rien faire d'autre, d'éditer un champ d'une ligne d'une table connue.

Ici, il nous faut éditer des liaisons entre une ligne d'une table connue (un article dans notre cas) et une autre table (des mots d'un certain groupe), ce qui concrètement revient à remplir ou modifier la table SQL spip_mots_liens. Pour cela, nous créerons des fonctions et squelettes spécifiques pour gérer notre crayon.

Créer le plugin

Un plugin très sommaire peut être créé pour commencer. Ce n'est évidemment pas obligatoire car ce que nous construisons pourrait être mis en partie dans config/mes_options.php et en partie dans le répertoire squelettes.

Pour ce faire, le plus rapide est de créer avec la Fabrique un plugin minimal, ayant un fichier d'option.

Dépendance à Crayons

Pour fonctionner, nous aurons besoin de la version 1.17 minimum de crayons, qui permet ce dont nous aurons besoin sans afficher de notices PHP [1].

On ajoute donc dans paquet.xml la dépendance :

<necessite nom="crayons" compatibilite="[1.17.0;]" />

Dépendance à Chosen

On ajoute ensuite une dépendance au plugin Chosen qui permettra d'améliorer l'interface de sélection des mots clés dans notre crayon. Cette dépendance n'est pas réellement obligatoire, le crayon fonctionnerait sans.

<necessite nom="chosen" compatibilite="[1.0.5;]" />

Une fois le plugin chosen actif, il faut le configurer pour indiquer qu'il doit s'activer dans l'espace public, et sur les select.chosen :

Configuration possible de Chosen

Il ne reste plus qu'à créer les fichiers et fonctions de travail.

Inclusion de travail

Dans un premier temps, nous créons une inclusion – qu'il suffira de charger dans une colonne de navigation par exemple – qui affichera les mots clés des groupes de mots que nous aurons choisis pour un article donné.

L'inclusion est appelé ici inclure/selection_mots_article_colonne.html et comporte le simple code suivant, qui liste les mots d'un article et groupe donné :

<BOUCLE_groupe(GROUPES_MOTS){id_groupe}> <div class="liste mots groupe#ID_GROUPE"> <h2 class="h2">#TITRE</h2> <ul class="liste-items"> <BOUCLE_mots(MOTS) {id_groupe} {id_article} {par num titre, titre}> <li class="item"><a href="#URL_MOT" rel="tag">#TITRE</a></li> </BOUCLE_mots> <li class="item"><:crayonsmots:aucun_mot_present:></li> <//B_mots> </ul> </div> </BOUCLE_groupe>

Pour tester, nous surchargeons un fichier de spipr-dist (extra/article.html) dans notre dossier squelettes, et ajoutons, dans la boucle article l'inclusion avec les groupes de mots clés désirés, par exemple avec ce code :

<BOUCLE_extra2_article(ARTICLES){id_article}> <INCLURE{fond=inclure/selection_mots_article_colonne, id_article, id_groupe=1} /> <INCLURE{fond=inclure/selection_mots_article_colonne, id_article, id_groupe=2} /> <INCLURE{fond=inclure/selection_mots_article_colonne, id_article, id_groupe=3} /> [...] </BOUCLE_extra2_article>

À partir de maintenant, en allant sur un article dans l'espace public, nous pouvons voir, en colonne les groupes de mots choisis (ici d'identifiant 1, 2 et 3), et les mots qui y sont associés (ou non).

Exemple de colonne avec les mots

Sur ce site de test, les titre des mots clés n'ont pas beaucoup de sens !

Commencer les crayons

Nous ajoutons alors de quoi afficher un crayon sur notre sélection en modifiant l'inclusion. Nous ajoutons la balise #EDIT sur la ligne :

<div class="liste mots groupe#ID_GROUPE">

Qui devient :

<div class="liste mots groupe#ID_GROUPE #EDIT{mots_article-#ID_ARTICLE}">

Il faut noter la subtilité ici avec #EDIT{mots_article-#ID_ARTICLE} : habituellement, on ne passe aucun identifiant à ce genre de balise, #EDIT retrouvant l'objet et l'identifiant de la boucle parente. Cependant ici nous avons dans la boucle parente le groupe et son identifiant, mais ce n'est pas suffisant pour connaître l'article de la liaison. On transmet donc – en fourbant – cet identifiant d'article, que l'on pourra ensuite récupérer dans les fonctions spécifiques du crayon.

Indiquer comment récupérer les valeurs du champ

Pour calculer la signature du champ, calculé à partir des données présentes dans celui-ci – ici une liste de mots clés —, il nous faut créer une fonction spécifique. On l'ajoute dans le fichier d'options du plugin :

function valeur_champ_mots_article($table, $ids, $champ) { return valeur_champ_mots_objet($table, $ids, $champ); }

En prévision de proposer d'autres objets (pourquoi pas les mots liés à des auteurs), notre fonction spécifique appelle une fonction plus générique :

function valeur_champ_mots_objet($table, $ids, $champ) { list($id_objet, $id_groupe) = explode('-', $ids); list(, $objet) = explode('_', $champ); $valeurs = sql_allfetsel("m.id_mot", "spip_mots AS m, spip_mots_liens AS ml", array( "m.id_groupe=" . sql_quote($id_groupe), "m.id_mot = ml.id_mot", "ml.id_objet=".sql_quote($id_objet), "ml.objet=".sql_quote($objet) )); $valeurs = array_map('array_shift', $valeurs); return $valeurs; }

Il y a des subtilités ici.

d'une part le champ $ids contient du texte, tel que « 348-2 » où le premier nombre est l'identifiant de l'article, le second du groupe. On sépare en 2 pour récupérer ces 2 nombres. [2]
d'autre part on récupère le type d'objet dans le nom du contrôleur, sous entendant que nos contrôleurs s'appellent « mots_T » où T est le type d'objet, tel qu'ici « mots_article ».

Ces astuces permettent d'avoir un code assez générique et réutilisable.

Le code HTML du contrôleur

Le contrôleur affiche le formulaire de saisie. Son code, placé dans le fichier controleurs/mots_article.html de notre plugin est le suivant :

#CACHE{0} #SET{ids,#ENV{id_groupes_mot}|explode{-}} #SET{id_groupe,#GET{ids/1}} #SET{id_article,#GET{ids/0}} #SET{name,#ENV{name_#ENV{crayon_modele}}} <BOUCLE_groupe(GROUPES_MOTS){id_groupe=#GET{id_groupe}}> #SET{mots,#ARRAY} <BOUCLE_mots_actifs(MOTS){id_groupe}{id_article=#GET{id_article}}> #SET{mots,#GET{mots}|push{#ID_MOT}} </BOUCLE_mots_actifs> <ul> <li> <label for="#GET{name}">#TITRE</label> <select name='#GET{name}\[\]' class='crayon-active chosen' multiple='multiple' id="#GET{name}" style="width:[(#ENV{largeur}|moins{40})]px"> <BOUCLE_mots(MOTS){id_groupe}{par num titre, titre}> <option value="#ID_MOT" [(#ID_MOT|in_array{#GET{mots}}|oui) selected="selected"]> #TITRE </option> </BOUCLE_mots> </select> </li> </ul> </BOUCLE_groupe>

De la même façon que dans le code PHP précédent, on doit retrouver l'identifiant de l'article et l'identifiant du groupe transmis, en utilisant le filtre explode.

Le reste est un formulaire pour crayons assez standard. Il faut faire attention à bien récupérer le name attendu pour ce champ, indiquer que c'est un champ multiple. Nous forçons aussi une largeur sur le sélecteur pour qu'il prenne à peu près toute la largeur disponible.

En cliquant le crayon, nous avons maintenant son contrôleur (le formulaire) qui s'affiche.

Contrôleur ouvert

Le crayon a été cliqué et affiche les mots clés actifs. En cliquant la zone blanche, la liste des mots clés possibles s'ouvre, permettant d'en sélectionner de nouveaux.

Les traitements à enregistrer

Les traitements se passent dans la fonction de révision. De même que pour les valeurs du champ, on passe par une fonction plus générique et par l'API d'édition de liens de SPIP 3. Cela peut s'écrire ainsi :

function mots_article_revision($ids, $colonnes, $type_objet) { return mots_objet_revision($ids, $colonnes, $type_objet, 'mots_article'); } function mots_objet_revision($ids, $colonnes, $type_objet, $champ = '') { if (!$champ) return false; list($id_objet, $id_groupe) = explode('-', $ids); list(, $type_liaison) = explode('_', $champ); // actuellement en bdd $old = valeur_champ_mots_objet($type_objet, $ids, $champ); // ceux qu'on veut maintenant $new = explode(',', $colonnes[$champ]); // les mots à supprimer $del = array_diff($old, $new); // les mots à ajouter $add = array_diff($new, $old); include_spip('action/editer_liens'); if ($del) { objet_dissocier(array('mot'=>$del), array($type_liaison => $id_objet)); } if ($add) { objet_associer(array('mot'=>$add), array($type_liaison => $id_objet)); } return true; }

Le code HTML de la vue (affichage des nouvelles valeurs)

La vue est très simple et reprend en grande partie, dans le fichier vues/mots_article.html, notre première inclusion :

#SET{ids,#ENV{id_groupes_mot}|explode{-}} #SET{id_groupe,#GET{ids/1}} #SET{id_article,#GET{ids/0}} <BOUCLE_groupe(GROUPES_MOTS){id_groupe=#GET{id_groupe}}> <div class="liste mots groupe#ID_GROUPE"> <h2 class="h2">#TITRE</h2> <ul class="liste-items"> <BOUCLE_mots(MOTS) {id_groupe} {id_article=#GET{id_article}} {par num titre, titre}> <li class="item"><a href="#URL_MOT" rel="tag">#TITRE</a></li> </BOUCLE_mots> <li class="item"><:crayonsmots:aucun_mot_present:></li> <//B_mots> </ul> </div> </BOUCLE_groupe>

À ce stade, le crayon est entièrement fonctionnel.

Bonus pour le centre de page

Nous avions surtout besoin de pouvoir éditer quelques groupes de mots dans la partie centrale de la page. Il y a dans le plugin un autre crayon « tags_article » et une autre inclusion « selection_mots_article_grille » qui peut afficher plusieurs groupes de mots sur la grille 12 colonnes de bootstrap, par exemple avec :

<h2>Tous les groupes</h2> <INCLURE{fond=inclure/selection_mots_article_grille, id_article, colonnes=4} /> <h2>Autre sélection précise</h2> <INCLURE{fond=inclure/selection_mots_article_grille, id_article, groupes=#LISTE{2,3}, colonnes=6} />

Ce qui donne cet affichage :

Mots au centre de la page

Présentation légèrement différente, d'où un nouvelle vue et un autre nom pour le crayon.

[1] Voir la révision r80169

[2] Cela vient du fait que nous avons ajouté l'identifiant de l'article à la balise #EDIT (la fameuse fourberie). Cette balise crée une classe CSS avec le nom de la table (groupes_mots), le texte transmis à la balise #EDIT (mots_article-248), précédé et suivi par un signe - puis suivi de l'identifiant de la table (le id_groupe), soit au total la classe CSS « groupes_mot-mots_article-348-2 » dans notre exemple.

Crayons attend 3 données séparées par des - : la table, le champ, l'identifiant. Tout signe - supplémentaire est mis dans l'identifiant, considérant que c'est une donnée particulière. Nativement dans crayons ces nommages complexes – qui ajoutent des moins en plus ! – servent pour crayonner les champs des tables ayant des clés primaires composées, tel que les tables de liens. Ils ont été introduits en révision r46818. Ici nous en détournons l'usage.

Un crayon listant des liaisons

Matthieu Marcillaud — 2012-11-14T18:25:33Z

Les crayons, c'est facile d'utilisation, surtout quand on veut modifier des éléments de la table en cours de lecture. Mais lorsqu'il s'agit d'éléments liés, comme des mots clés sur des auteurs, le parcours est plus délicat !

Cet article présente une solution pour obtenir cela. Le code mériterait d'être amélioré, mais il présente une base de travail pour ceux qui aimeraient copier :)

Sommaire

Tout d'abord, précisons que cet exemple concerne SPIP 2.1. Certaines parties mériteraient d'être réadaptées pour SPIP 3 (mais devraient aussi fonctionner).

Nous avions besoin d'un listing d'auteurs où il serait facile de choisir des mots d'un groupe de mots donné (le numéro 40) avec un crayon. Dans notre cas le nombre de mots du groupe est limité (environ 10 mots) ce qui permet une interface assez simple : on liste tous les mots du groupe dans un sélecteur multiple.

Nous avons une liste d'auteurs (les lignes), et la colonne montrée indique les mots clés attachés (des métiers) aux auteurs. C'est eux que l'on veut éditer avec un crayon.

Liste d'auteurs avec les mots associés

Commençons par montrer le code permettant d'amener l'icone de crayon sur la liste :

<td class="categorie #EDIT{ctags}"> <BOUCLE_cat(MOTS){id_auteur}{id_groupe=40}{', '}>[(#TITRE|supprimer_numero)]</BOUCLE_cat> --- <//B_cat>
</td>

Nous sommes à l'intérieur d'une boucle auteur (non présentée ici) et notre colonne est affichée grâce à une boucle sur les mots de même auteur, du groupe 40. Sur la balise td du tableau, nous appelons le crayons nommé ctags avec #EDIT{ctags}, comme n'importe quel crayon habituel, sauf qu'ici, la colonne « ctags » n'existe pas dans notre table auteurs.

Il va falloir indiquer à crayons :

comment obtenir les données du formulaire à afficher, via une fonction PHP
quel formulaire afficher, via un contrôleur et une saisie
comment enregistrer les données saisies, via une fonction PHP
comment réafficher le résultat, via une vue

Le plugin crayons sait gérer des formulaires traitant plusieurs types de champs d'un coup ; par exemple le crayon « introduction » affiche 3 champs : description, chapeau et texte (de mémoire) et gère leur enregistrement. Il utilise pour ça 1 contrôleur, qui obtient les données des 3 champs et affiche les 3 champs de formulaire.

Nous, nous avons besoin d'1 contrôleur, pour obtenir 1 champ de formulaire, mais les données du champ sont obtenues et enregistrées en plusieurs endroits ensuite. Le fait d'avoir 1 seul champ nous dispense de devoir créer un contrôleur PHP en plus du HTML, qui serait indispensable pour déclarer les champs utilisés dans le contrôleur sinon. Ici, Crayons comprend que le champ souhaité porte le même nom que le contrôleur.

Commençons par le plus simple.

Le contrôleur et sa saisie

Il affiche le formulaire et porte le nom indiqué dans la balise #EDIT, soit ici controleurs/ctags.html. Il contient :

#CACHE{0} #SET{mots,#ARRAY}
<BOUCLE_mots_actifs(MOTS){id_groupe=40}{id_auteur}>
#SET_PUSH{mots,#ID_MOT}
</BOUCLE_mots_actifs> <ul>
[(#SAISIE{ctags, content_#ENV{key}_ctags, id_groupe=40, class=crayons-active, valeur=#GET{mots}, label=<:utilisateurs:label_categorie:>})]
</ul>

La première partie s'amuse à retrouver les mots déjà associés à l'auteur et les stocke dans une variable « mots » qui est passée, ensuite comme valeur de la saisie « ctags ». Cette saisie va lister les mots du groupe 40 et sélectionner ceux qui sont déjà associés à l'auteur.

Il est important de noter que la saisie crée un attribut name de nom : content_X_ctags où X est un identifiant attribué par crayons.

La saisie saisies/ctags.html est simple (enfin c'est relatif, mais c'est juste un copié collé adapté d'une autre saisie) :

[(#REM) defaut peut être une chaine (plusieurs valeurs ou pas) qu'on sait décomposer ]
#SET{defaut, #ENV{defaut}|saisies_chaine2tableau} [(#REM) valeur peut être une chaine (plusieurs valeurs ou pas) qu'on sait décomposer ]
#SET{valeur, #ENV{valeur}|saisies_valeur2tableau} <select name="#ENV{nom}[]" multiple="multiple" class="#GET{type}[ (#ENV{class})]" size="#ENV{size,15}" id="champ_[(#ENV{nom}|saisie_nom2classe)]"[ value="(#ENV{valeur_forcee,#ENV{valeur}})"][ disabled="(#ENV{disable})"][ (#ENV*{attributs})]>
[(#ENV{cacher_option_intro}|non) <option value="">[(#ENV{option_intro})]</option>]
<BOUCLE_mots(MOTS){par id_groupe, num titre, titre}{id_groupe ?}> [<optgroup label="(#TYPE|unique|attribut_html)" />] <option value="#ID_MOT" [(#ID_MOT|in_array{#ENV{valeur_forcee,#GET{valeur,#GET{defaut}}}}|oui) selected="selected"]>[(#TITRE|supprimer_numero)]</option>
</BOUCLE_mots>
</select>

En gros, c'est une saisie affichant une sélection multiple, bouclant sur les mots du groupe de mot demandé.

Ajoutons un rien de CSS pour enlever le label de notre saisie (sinon le crayons est 2 fois plus large) :

.crayon-html .saisie_ctags label {display:none;}
.crayon-html .saisie_ctags {padding-left:10px;}

Déjà, nous arrivons maintenant à un formulaire lorsqu'on édite ressemblant à cela :

Crayon ouvert

Faisons la vue.

La vue

La vue d'un crayon, c'est ce qui s'affiche après avoir modifié un élément. Il y a des vues par défaut, mais on peut les personnaliser. Nous, nous souhaitons le même affichage que dans notre tableau à l'origine. Il nous suffit de recoller le même code dans vues/ctags.html :

#CACHE{0}
<BOUCLE_cat(MOTS){id_auteur}{id_groupe=40}{', '}>[(#TITRE|supprimer_numero)]</BOUCLE_cat>
---
<//B_cat>

Simple et efficace :)

Voyons maintenant comment faire pour que crayons enregistre les données !

Préparation et enregistrement des données

Crayons, pour savoir si une donnée a été modifiée par la personne qui valide le formulaire fait envoyer par le formulaire une signature des données qu'il avait calculé au moment de l'affichage dudit formulaire. Chaque champ possède 2 signatures : une signature identifiant le champ (le key de tout à l'heure), une autre identifiant le contenu des données (un md5 de celles-ci).

Comme SPIP dans l'espace privé, Crayons n'acceptera de modifier une donnée que si sa signature envoyée par le formulaire est la même que celle actuellement en base. Le cas contraire indique que quelqu'un d'autre a modifié les données entre temps. Si les signatures correspondent, il regarde si les données envoyées sont différentes également (sinon pas la peine d'enregistrer la même chose). Si tel est le cas l'enregistrement se fait, pour uniquement les données modifiées.

Le corollaire est que Crayons doit connaître les données en créant le formulaire ! Comme notre champ n'est pas standard, il va falloir lui indiquer comment l'obtenir.

C'est ce que fait la fonction suivante (à placer, par exemple dans un fichier d'option - il y a certainement mieux, mais je n'ai pas regardé plus en détail encore) :

// obtenir la liste des identifiants de mots clés liés à notre objet...
function valeur_champ_ctags($table, $id, $champ) { $valeurs = sql_allfetsel("m.id_mot", "spip_mots AS m, spip_mots_${table}s AS ma", array("m.id_groupe=40", "m.id_mot = ma.id_mot", "ma.id_${table}=".sql_quote($id))); $valeurs = array_map('array_shift', $valeurs); return $valeurs;
}

La fonction valeur_champ_X où X est le nom du champ souhaité (c'est aussi personnalisable en fonction du nom de la table) reçoit 3 arguments : le type de table (ici auteur), son identifiant (le numéro d'auteur), et le nom du champ désiré (le X, soit « ctags » ici).

La fonction doit retourner la valeur du champ. Ici, on retourne un tableau de tous les identifiants de mots clés associé à l'objet et son identifiant. Une fonction d'API spécifique en SPIP 3 pourrait obtenir ces données (cf API éditer liens), mais j'étais en SPIP 2.1.

Ceci fait, il faut maintenant indiquer le traitement à réaliser pour notre contrôleur, puisque ce n'est pas un traitement automatique. Cela se passe avec la fonction X_revision où X est le nom du contrôleur.

// la révision du crayon ctags doit supprimer ou ajouter des liaisons de mots clés
function ctags_revision($id_objet, $colonnes, $type_objet){ // actuellement en bdd $old = valeur_champ_ctags($type_objet, $id_objet, 'ctags'); // ceux qu'on veut maintenant $new = explode(',', $colonnes['ctags']); // les mots à supprimer $del = array_diff($old, $new); // les mots à ajouter $add = array_diff($new, $old); // actions ! if ($del) { sql_delete("spip_mots_${type_objet}s", array(sql_in("id_mot", $del), "id_$type_objet=$id_objet")); } if ($add) { $adds = array(); foreach ($add as $a) { $adds[] = array( "id_$type_objet" => $id_objet, "id_mot" => $a, ); } sql_insertq_multi("spip_mots_${type_objet}s", $adds); } return true;
}

Ici la fonction reçoit 3 arguments : l'identifiant de l'objet, les couples de données à enregistrer, le type d'objet. Ici, SPIP 3 simplifierait aussi le code avec son API d'édition de liens.

Le principe est simple : on récupère ce qu'on veut enregistrer dans la clé 'ctags' de la variable $colonne. Elle contient la liste des identifiants de mots pour notre auteur. On fait ensuite la différence entre ce qui est déjà stocké et les nouvelles données pour savoir ce qu'on doit enlever et ajouter en BDD.

Voilà :)

Bon, tout n'est pas très propre, mais c'est une belle base !

Espéranto, genre et sexisme

Matthieu Marcillaud — 2012-08-29T14:15:39Z

Un des points les plus génants actuellement j'ai l'impression pour l'esperanto (enfin c'est moins pire que le français) est sa non distinction pour certains mots entre le neutre (enfin d'un sexe indéterminé) et le masculin, alors que passer un mot au féminin se fait par l'usage d'un suffixe. Du coup, beaucoup de personnes s'interrogent sur comment rendre cette langue non-sexiste. Il y a beaucoup de propositions, mais pas encore de choix établi.

Sommaire

Le français (la langue) est dit discriminant, par exemple lorsqu'il accorde un adjectif au masculin pluriel dès qu'il y a un élément masculin dans un groupe comme « L'homme et les 99 femmes sont beaux ». Une proposition de réforme du français est d'accorder avec le nom le plus proche. C'est la règle de proximité (et c'était comme ça il y a quelques siècles en ancien français). Ce qui donnerait « L'homme et les 99 femmes sont belles » ou « Les 99 femmes et l'homme sont beaux » selon le nom le plus proche de l'adjectif.

En espéranto les noms en eux-mêmes sont non-genrés (ni masculin, ni féminin) et il n'y a pas d'accord à faire de ce type. « La table blanche et le piano blanc » peut se traduire par « La tablo blanka kaj la piano blanka ». Par contre ils peuvent se référer à quelqu'un (ou un animal) qui est lui sexué, mais ça ne change pas les accords. « Nigra katino ronronas » signifie « Une chatte noire ronronne »

En esperanto, il y a des problèmes qui ne portent pas sur l'accord de l'adjectif (qui ne marque que le pluriel et non le féminin), mais sur la question du sexe attribué à un nom ou un pronom désignant une personne.

Prenons un nom simple : « la knabo », qui signifie le garçon. En ajoutant le sufixe -in- on obtient le féminin : « la knabino » signifie la fille. C'est là que ça devient embêtant : par le fait qu'il y ait un suffixe pour désigner le sexe féminin, on s'attend à l'existence d'un suffixe pour désigner le sexe masculin, mais il n'en est rien. On peut s'attendre aussi à l'existance d'un neutre, où le sexe est indéterminé (j'ai l'impression que ça se nomme épicène dans ce cas là).

De la même manière les pronoms personnels de la 3è personne sont :

li : il (masculin ou indéterminé)
ŝi : elle (féminin)
ĝi : il neutre pour un objet/animal tel que « la hundo... ĝi estas... » (Le chien... il est...)

On voit aussitôt que « li » est employé pour désigner ce qui est masculin ou indéterminé. Là encore ça pose le problème d'une sorte de prédominance du masculin. Dans « La kuracisto eniras. Li estas granda. » (Le médecin entra. Il est grand). On ne sait normalement pas le sexe du médecin. Pourtant, « li » indique, ou incite à penser que c'est un homme (c'est le même problème en français d'ailleurs).

Pour ces raisons de nombreuses propositions d'espérantistes visent à trouver des solutions à ces 2 problèmes. Aucune n'a encore été validée et c'est peut être ça le plus embêtant : chaque solution risque de vivre sa propre vie, mélangée aux autres simplement parce qu'une n'a pas été retenue et validée.

Voyons un peu les propositions faites.

Des explications complètes sont disponibles en anglais là

Pour le masculin et neutre des noms

Il faut savoir qu'il existe déjà un préfixe (vir-) pour désigner le « mâle » chez les animaux, par exemple « virbovo » pour taureau. Le préfixe vir- et le suffixe -in- comme la plupart en espéranto peuvent être utilisés seuls : viro = de sexe masculin, ino = de sexe féminin. On voit déjà encore un autre problème : parfois il y a vir- pour spécifier le masculin, dès fois pas (on ne dit pas « virpatro » ou « virkuracisto » pour dire le père ou le médecin homme). Et ce n'est pas symétrique, il y a un suffixe et un préfixe.

Il semble qu'il y ait un certain consensus pour proposer un suffixe en plus indiquant le sexe masculin, et à rendre non sexué les mots qui le sont par défaut tel que « patro » (père), « knabo » (garçon).

Les suffixes proposés sont -un-, -ol- et -iĉ-, et c'est ce dernier le plus utilisé actuellement à cette fin. De la sorte, avec cette modification introduisant -iĉ- comme suffixe de masculin, on obtiendrait :

patro : un parent (père ou mère)
patrino : mère
patriĉo : père

En fait, -iĉ- est employé parce qu'il se rapproche du suffixe déjà existant exprimant une relation tendre -ĉj- (comme il y a -nj- pour le féminin) :

patrino : mère. panjo : maman
patro : père. paĉjo : papa

Pour les pronoms

Le cas des pronoms semble poser beaucoup plus de difficultés. Certains veulent complêtement enlever le genre, par exemple en indiquant que « li » peut signifier soit masculin, soit féminin et en supprimant ŝi. D'autres préfèrent ajouter un autre pronom soit pour désigner le sexe indéfini (li devenant alors masculin), soit pour désigner le masculin (li devenant alors de sexe indéfini).

Il n'est pas facile de faire le tri de toutes les propositions. Je retiens que « ri » ne va pas en tant que pronom à cause de la confusion avec tous les verbes commençant par « ri » tel que « rigardi »

Après, j'aime bien la proposition de dire que « ĝi » désigne, en plus du neutre et d'un animal, quelqu'un de sexe indéterminé. « ŝli », contraction de « ŝi aŭ li » (elle ou il) est aussi intéressant mais plus difficile à prononcer (chli). Il y a aussi « gi » qui ferait tout autant l'affaire. Pas simple.

En résumé

Disons que lorsque je saurais l'écrire et le parler correctement, j'utiliserais vraissemblablement les formes suivantes :

-iĉ- pour les noms désignant des individus masculins. « patro » devenant un parent dont on ne précise pas le sexe, soit parce qu'on ne le connait pas, n'est pas important, ne veut pas le dire ou parce qu'il est déjà connu dans la phrase,
gi comme pronom indiquant une personne dont, de la même manière, on ne connait pas le sexe (ou ce n'est pas important, ou on veut pas le dire...)

Ça donnerait. Avant :

La patrino salutas min. Ŝi ridetas.
La patro iras hejmen. Li piediras.
Iu krias mian nomon. Li estas forega.

Après :

La patrino salutas min. Ŝi ridetas.
La patriĉo iras hejmen. Li piediras.
Iu krias mian nomon. Gi estas forega.

Ce qui peut se traduire par :

La mère me salue. Elle sourit.
Le père se dirige chez lui. Il est à pied.
Quelqu'un crie mon nom. Il est très loin.

Peut être que d'ici là une petite réforme de l'esperanto aura eu lieu :)

Ressources pour l'apprentissage de l'espéranto

Matthieu Marcillaud — 2012-08-29T14:13:20Z

Parce que même s'il est plus facile que d'autres langues, l'espéranto nécessite un apprentissage ! Et c'est relativement intéressant d'avoir quelques cours sous la main !

Commençons déjà par présenter une boutique où il est possible d'acheter de nombreuses revues, manuels, livres d'espéranto, par correspondance ou directement à Paris : chez Esperanto-france.

En général, découvrir l'espéranto passe par le site Lernu. Dedans il y a de quoi apprendre tout de l'espéranto ainsi que des exercices à faire. L'interface n'est pas toujours des plus agréables à regarder mais le site est très pratique, notamment avec le formulaire de recherche dans le dictionnaire présent dans la colonne qui permet à tout moment de nous remémorer les mots oubliés.

Il y a une très bonne émission de radio à Toulouse qui donne des cours d'Espéranto. J'avais toutes leurs archives, mais ils ont (malheureusement pour nous) refait leur site et seules les nouvelles archives depuis la refonte sont disponibles là

Le site Tatoeba permet de trouver des phrases traduites dans différentes langues. La diversité des phrases permet de découvrir pas mal de vocabulaire.

Il est possible d'écouter de la musique chez Muzaiko et plus généralement des documents sonores en espéranto sur Esperanto Radio et de la même manière des vidéos en esperanto sur Esperanto TV

Certains cours se retrouvent en vidéo, par exemple avec cette pièce de théâtre expliquée « La Passporto al la tuta mondo » (16 parties je crois, 4 * 2h).

On trouve également quelques jolis contes sous forme de courts métrages d'animation, traduits et sous-titrés sur le site Bookbox destiné à l'apprentissage des langues. Il faut choisir « esperanto » dans le sélecteur.

Le site Facila vento propose des textes simples pour débuter l'esperanto, que l'on peut également écouter.

Enfin difficile de passer au travers des outils de Google : la recherche en espéranto, et les traductions

Voilà déjà de quoi occuper la découverte de l'espéranto !

Réflexions sur l'espéranto

Matthieu Marcillaud — 2012-08-29T14:10:13Z

Cela fait quelques années déjà que je m'intéresse de près ou de loin à l'espéranto. Force est de constater que je n'ai pas encore poussé mon étude assez loin pour savoir suffisamment le parler. Cependant, aussi étrange que cela puisse me paraître, je comprends déjà mieux des textes d'espéranto que d'anglais. Je croise pourtant l'anglais presque tous les jours de part mon activité et je l'ai normalement appris à l'école. De ce regard là, il y a comme un mystère qui émane de l'espéranto et de sa facilité. Qu'est-ce qui me motive dans l'espéranto ? est-ce viable de l'apprendre ? peut elle réellement devenir une langue pont, une langue de travail, auxiliaire, de compréhension entre les cultures sur une plus grande population ? sa facilité peut elle survivre aux évolutions de toutes langues vivantes ? Je vais plus ou moins faire mon bilan de ces différentes questions que me parcourent l'échine ces jours-ci.

Sommaire

Motivations

J'ai précisément des difficultés à observer clairement quelles sont mes motivations envers l'espéranto. Plus clairement, je suis certain que son développement pourrait faciliter beaucoup l'échange de connaissances entre personnes de langues différentes, avec un minimum d'effort d'apprentissage des différentes parties. En tout cas un apprentissage bien plus rapide que l'anglais (150 heures d'espéranto apportent l'équivalent de 2000 heures de cours d'anglais) pour une efficacité bien meilleure : la prononciation, compréhension phonétique, régularité de l'espéranto apportent des bases solides, fiables sur la connaissance de la langue là où avec l'anglais, même avec beaucoup de pratique, il restera toujours difficile d'écrire une phrase correcte, de prononcer des mots correctement et inversement de comprendre le bon mot lorsqu'il est prononcé, tellement les subtilités phonétiques de cette langue sont grandes.

Le souci est que, actuellement, ce n'est pas encore l'espéranto qui est utilisé pour travailler entre les personnes d'horizons différents. S'ils n'ont pas une langue commune, c'est l'anglais qui est pris. C'est particulièrement vrai dans une des activités pour lesquelles je suis impliqué : le développement d'un logiciel (SPIP). Dans ce cadre là, notre logiciel - enfin son code source - est développé, écrit, exprimé en français (son interface d'utilisation et son usage est traduit, mais pas le code source ou ses gabarits). Nombreuses sont les remarques nous disant à peu près, le plus naturellement du monde : « Il y aurait bien plus de monde sur votre projet si vous passiez à l'anglais ». C'est peut être vrai, mais dans ce cas, pourquoi juste l'anglais, ou pourquoi l'anglais uniquement ?

L'anglais est devenu tellement la routine que de nombreux projets ne se donnent même plus la peine de se faire traduire. Ils restent en anglais, peut être supposant que tout le monde comprend ou doit comprendre cette langue. C'est le cas de la plate-forme de travail collaboratif « GitHub » permettant à des développeurs de logiciels de travailler ensemble.

Cette présence extrêmement grande de l'anglais comme langue de travail en informatique fait que j'arrive maintenant à comprendre à peu près le sens d'écrits techniques dans cette langue, au prix de beaucoup de fatigue psychique. Mais mon problème reste entier dès que je veux m'exprimer dans cette langue. J'ai l'impression systématique que je vais faire des erreurs et que je ne vais pas être compris. C'est d'autant plus frustrant que je n'ai rien contre le fait de savoir l'anglais et que j'aimerais bien pouvoir m'exprimer facilement dans cette langue, mais le constat est là : c'est difficile.

Je me suis souvent dit que je devais être un incompétent en langues étrangères, surtout en anglais, mais je me dis maintenant que ça ne vient peut être pas que de moi ! Particulièrement le visionnage des 10 présentations « Les langues : un défi » de Claude Piron apporte un éclairage différent. Malgré pour certains des études poussées en anglais, des erreurs d'interprétations, de mauvaises compréhension des mots sont présentes. En clair, ça dit que l'anglais est mal adapté comme langue de travail internationale.

Et donc l'espéranto est une solution très plaisante, à partir du moment où suffisamment de personne s'y mettent ! C'est bien là un problème. Certes il y a des locuteurs, assez nombreux en espéranto, mais on les trouve lorsqu'on veut voyager ou apprendre l'espéranto. Rarement dans la vie de tous les jours dans le cadre d'une de ses activités ou en se promenant sur internet. Et c'est là une baisse de motivation.

Lorsque j'ai appris à frapper au clavier avec la disposition de clavier bépo, à rouler en vélo couché ou fait des buttes de culture, la satisfaction de ces alternatives est immédiate : un grand confort d'utilisation et des améliorations aussitôt visibles, pratiques.

C'est un peu différent pour l'espéranto car c'est un changement qui implique d'autres personnes : il ne peut devenir utile quotidiennement que si suffisamment de gens s'y mettent afin que l'anglais ne soit plus considérée comme la langue naturelle de travail international, et que les ressources soient traduites !

Espéranto, le choix dans les langues construites

La question peut aussi se poser du choix de l'espéranto en lui-même alors qu'il existe de nombreuses autres langues régulières et langues construites, souvent plus compliquées, mais parfois extrêmement plus simple comme le récent Toki pona.

Il n'est pas évident de répondre à une telle question. On peut dire que l'espéranto a fait ses preuves car il est réellement une langue vivante auxiliaire pour une frange de la population mondiale et ce depuis plus d'un siècle.

On peut dire que le choix de l'espéranto plutôt qu'une langue appartenant à un peuple comme langue de travail internationale permet une égalité linguistique : chaque peuple est obligé de l'apprendre et n'a pas, dès lors, l'avantage de sa langue natale.

Mais qu'adviendrait-il, si l'espéranto était choisie comme langue auxiliaire internationale, et que plus tard, suite par exemple à une guerre entre 2 états, ces peuples choisissent l'espéranto comme langue nationale. Cet argument de la non-langue natale n'aurait plus de sens, et l'espéranto ne serait plus alors une langue « auxiliaire » pour eux. C'est embêtant car ce n'est pas le but que s'est fixé l'espéranto : servir de langue pivot, auxiliaire, de travail, mais absolument pas remplacer des langues natales.

Disons peut-être deux choses en sa faveur :

pour le moment c'est communément la langue auxiliaire la plus acceptée et parlée
apprendre l'espéranto facilite l'apprentissage d'autres langues ensuite. En fait c'est le cas de tout apprentissage de langue étrangère mais, comme le dit wikipedia :

Lorsque l'on a déjà appris une langue étrangère, l'apprentissage d'une nouvelle langue étrangère est plus facile, d'où l'intérêt de commencer par une langue étrangère facile.

Disons aussi que beaucoup de langues construites sont des tentatives de différents linguistes (le plus souvent) de créer ou tendre vers une langue « parfaite ». Là encore ce n'était pas l'objectif de l'Esperanto qui dit dans son fundamunto vouloir « rester intangible avec ses imperfections ». Cela dit, toute langue évolue.

L'esperanto comme langue vivante

De nombreux linguiste le soulignent : toute langue vivante évolue avec le temps, souvent régionalement. Est-ce que ce serait pareil pour l'espéranto ? C'est encore une question fort intéressante.

On peut certainement séparer en 2 les évolutions : d'une part le vocabulaire, et d'autre part la construction de la langue. Le risque avec le vocabulaire est l'entrée de mots issus du pays où le groupe espérantiste se trouve. Par exemple l'introduction de mots français chez les espérantistes parlant français. Si chacun fait cela à sa sauce il risque rapidement d'y avoir soit cacophonie, soit de nouveau hégémonie d'une culture sur une autre. Toujours est-il qu'au bout d'un siècle d'espéranto je n'ai pas l'impression que de nouveaux mots l'ont entaché, d'autant plus que sa nature même de langue agglutinante permet bien plus de constructions, comme des briques, que notre français ou anglais.

L'autre partie est sur la construction même de la langue. Une langue évolue avec la société et si elle reste figée il risque d'y avoir un décalage entre les envies de la société et les possibilités de la langue. C'est peut être le point le plus difficile à gérer. Effectivement les motivations politiques ne sont pas forcément les mêmes d'une région à une autre et là où certains veulent du changement, il n'est pas certain que d'autres le veuillent aussi. Il y a déjà une évolution sociétale forte qui pointe son nez depuis quelques temps en espéranto : l'envie d'avoir une langue « non-sexiste » (j'y reviendrais dans un prochain article). Chacun y va de sa solution et si une des propositions n'est pas acceptée par la fédération d'espéranto, elle risque néanmoins d'être utilisée, de fait par les locuteurs !

Mais même si ces changements auront lieu, ils n'entameront pas la volonté initiale de l'espéranto qui est d'être une langue facile, accessible au plus grand nombre, permettant de dialoguer entre différentes autres langues. Puis même si la langue évolue, on aura au moins fait mieux, l'espace de quelques années, que toutes les tentatives précédentes suggérant une langue internationale compliquée.

La présence de l'esperanto

L'espéranto a connu un regain d'intérêt avec internet. Aussi on ne peut pas nier que cette langue existe et est utilisée ! Il y a de nombreuses associations de promotion de l'espéranto de part le monde et on peut au moins citer ici 2 beaux projets où l'espéranto est loin d'être anecdotique :

Wikipedia, où il est la 27è langue d'après leurs statistiques avec 168 912 articles,
Tatoeba, où il est la 2è langue d'après leurs statistiques avec 177 367 phrases.

Le prochain article présente des sites de ressources pour apprendre l'espéranto.

SPIP 3, Documents, Mots

Matthieu Marcillaud — 2012-06-12T10:10:51Z

SPIP 3 permet d'attacher des mots à des documents, et il permet également de taguer des documents avec des mots clés. Fort pratique certainement, ce qui devient plus délicat, c'est ensuite les boucles à réaliser pour retrouver tout cela. Au vu des nombreuses questions sur les listes d'utilisateurs, voici un petit peu d'explication du fonctionnement.

Sommaire

Un énième message d'un utilisateur de SPIP et concepteur de squelette ne comprenait pas pourquoi sa boucle documents ne retournait rien.

<BOUCLE_doc(DOCUMENTS){id_mot}>...

En fait il s'attendait à ce que la boucle retourne la liste des documents qui ont un mot clé donné (les mots clés taguent des documents donc). C'est une compréhension fort logique, vu que c'est ce que fait la boucle :

<BOUCLE_art(ARTICLES){id_mot}>

Les tables de liaisons

Mais ce n'est pourtant pas ce qui se passe avec la boucle documents. La différence est simple, il existe une table SQL « spip_documents_liens » qui sert de pivot (on parle souvent de table de liaison) où est stockée donc l'information disant tel document est lié à ceci, cela, c'est à dire à des objets éditoriaux (articles, rubriques, mots, tout ce que l'on veut).

Il existe la même table « spip_mots_liens » qui sert de pivot pour indiquer que tel mot est attaché à tel objet éditorial, lorsqu'on tague des articles, des documents d'un mot clé.

Mais il n'existe pas de table « spip_articles_liens ».

Cas non ambigus

Lorsqu'on écrit dans une boucle ARTICLES le critère {id_mot}, SPIP recherche comment il peut faire pour honorer la demande. Il cherche donc si la table SQL spip_articles possède un champ « id_mot » (ce qui n'est pas le cas), et du coup tente de trouver une construction de liaison entre tables SQL (on parle de jointure) qui permet d'obtenir ce id_mot qui est demandé. SPIP remarque que spip_mots_liens possède un champ « id_mot » et va donc demander une jointure avec cette table.
Il pourrait aussi rechercher une table ayant le couple de champs « objet » et « id_objet » et faire une jointure dessus en indiquant, du coup, que objet=mot et id_objet=l'identifiant.

Pour aller plus loin, disons simplement que s'il y a plusieurs possibilités de jointure pour obtenir id_mot, SPIP choisira la jointure la plus courte, c'est à dire qui nécessite d'interroger le moins de tables SQL possibles.

Cas ambigus

Indiquer un critère {id_mot} sur une boucle DOCUMENTS est plus ambigu. Effectivement, SPIP peut choisir de prendre le mot soit sur la liaison spip_documents_liens, soit sur la liaison spip_mots_liens. Les deux étant corrects, mais ils n'ont pas la même signification.

Il faut donc savoir que dans ce cas, SPIP choisit de préférence une liaison avec la même table que celle de la boucle, c'est à dire que comme nous sommes dans une boucle DOCUMENTS, SPIP choisira de préférence la liaison avec spip_documents_liens.

Alors, pourquoi y a t'il deux tables de liaisons possibles avec les documents ou avec les mots ? et à quoi servent-elles ? qu'est-ce qui les différencient ?

Des mots sur des documents, des documents sur des mots

Pour expliquer ce qui se passe :

Les documents en SPIP 3 peuvent être sur n'importe quel objet (y compris les mots) (des mots peuvent avoir des documents attachés)
Les mots en SPIP 3 peuvent être mis sur n'importe quel objet (y compris les documents) (des documents peuvent être tagués par dés mots)

On voit bien ici que c'est délicat pour SPIP de comprendre ce que signifie (DOCUMENTS){id_mot} : est-ce qu'on veut ?

les documents d'un mot clé ?
les documents tagués d'un mot clé ?

Il faut donc faire un peu d'analyse de fonctionnement de SPIP pour comprendre ce qui va se passer :

Lorsqu'on lie un document à un objet, la liaison est stockée dans la table spip_documents_liens
Lorsqu'on lie un mot à un objet, la liaison est stockée dans la table spip_mots_liens

Ce que SPIP va décider lorsqu'il y a ambiguïté, c'est à dire comme ici (DOCUMENTS){id_mot} alors qu'il existe les 2 tables spip_documents_liens et spip_mots_liens, c'est qu'il va préférer interpréter cela comme une liaison sur la table de lien de la boucle en cours, c'est à dire sur spip_documents_liens, ce qui signifie donc que ça va retourner « les documents attachés à un mot clé »

Pour lever les ambiguïtés, on peut indiquer, donc, la relation du lien de plusieurs manières, lorsqu'on veut l'autre relation :

Soit en l'indiquant comme table : (DOCUMENTS mots_liens){id_mot}
Soit en l'indiquant dans le critère (DOCUMENTS){mots_liens.id_mot}

Il faut noter que mettre simplement (DOCUMENTS){mots.id_mot} n'est pas suffisant pour lever l'ambiguïté.

D'autres exemples :
Liaison spip_documents_liens (Les documents attachés à un mot)

<BOUCLE_1(DOCUMENTS){id_mot}>#ID_DOCUMENT</BOUCLE_1>

Liaison spip_mots_liens (Les documents tagués d'un mot)

<BOUCLE_2(DOCUMENTS mots_liens){id_mot}>#ID_DOCUMENT</BOUCLE_2> <BOUCLE_3(DOCUMENTS mots_liens){mots.id_mot}>#ID_DOCUMENT</BOUCLE_3> <BOUCLE_4(DOCUMENTS){mots_liens.id_mot}>#ID_DOCUMENT</BOUCLE_4>

Attraper les documents tagués avec un mot clé appartenant à un certain groupe :

<BOUCLE_doc_groupe(DOCUMENTS mots_liens) {mots.id_groupe=1}> #ID_DOCUMENT </BOUCLE_doc_groupe> <BOUCLE_doc_groupe_type(DOCUMENTS mots_liens) {mots.type=Nom}> #ID_DOCUMENT </BOUCLE_doc_groupe_type>

Livre libre « Programmer avec SPIP »

Matthieu Marcillaud — 2010-05-18T17:12:53Z

Tôt ce matin a été proposée officiellement la première version du livre « Programmer avec SPIP » pouvant être achetée en ligne chez un imprimeur « à la demande ». Cette « Édition Troglo2 », sous licence libre (cc-by-sa), est un export complet du site http://programmer.spip.org en date du 16 mai 2010. Il est diffusé chez Lulu dans un format A5 à spirale. Retours sur cette expérience.

Sommaire

L'idée a germé un jour de fin 2008 où l'on m'a rémunéré quelques jours pour écrire des pages d'une documentation technique, peu de temps après la sortie de SPIP 2.0. Il y avait des trous béants sur des absences de documentation de certaines fonctionnalités qu'il était intéressant de combler.

Puisque mon éditeur de texte favori est l'interface privée de SPIP, j'ai commencé une série d'articles en local, sous SPIP. Je les voulais cohérents, se suivant logiquement, courts pour mettre peu d'idées sur une même page et ne pas effrayer le lecteur de la quantité de texte à lire, et actualisés pour la dernière version de SPIP.

Un squelette SPIP pour lire plus agréablement cette suite d'articles et de rubriques a été élaboré dans le même temps, rendant la navigation plus agréable. Puis le tout a été mis en ligne début 2009 (je ne me rappelle plus précisément).

Au fil des jours, sur mon temps libre, je complétais ces premières pages par d'autres, puis par d'autres encore. Un nom de domaine fut alors attribué au projet : programmer.spip.org ... L'idée germait de non seulement avoir en ligne « comme » un livre, mais d'un jour aussi réussir à en proposer une véritable version papier.

Technique autant que rédactionnel

Ce qu'il est difficile d'imaginer en parcourant les 338 pages de l'exemplaire spécial « Troglo SPIP » que j'ai sous les yeux, c'est que sa création a nécessité presque autant de temps pour la technique sur le site et pour générer le livre que pour l'écriture en elle-même. Au fil de la progression du site, de nouvelles contraintes à résoudre apparaissent.

C'est d'abord un niveau de sous-rubriques à prendre en compte en plus, c'est une meilleure lisibilité par là, c'est de l'AJAX à mettre ici pour éviter des pages trop volumineuses, c'est d'installer un système pour que les visiteurs puissent proposer des améliorations, c'est gérer les balises sur 2 langues et quelques dizaines de rubriques lorsque des traducteurs anglais investissent l'espace éditorial... puis il y a trop de rubriques et cela devient invivable alors c'est encore mettre un niveau de sous-rubriques en plus pour gérer les langues, puis c'est permettre de déclarer des traductions entre rubriques via un plugin (tradrub), puis c'est fournir des outils aux traducteurs pour suivre les modifications un rien plus simplement (tradsync), en même temps, c'est ajouter des mots clés pour que le livre puisse générer un glossaire, c'est créer les outils pour exporter le contenu entier du site, et exporter le résultat dans un format PDF convenable (via PrinceXML), et adapter la CSS d'impression pour rendre les textes encore plus contrastés que sur l'écran, et patati... et patata... et j'en passe et des meilleures.

Tout cela aurait certainement été plus facile en écrivant directement dans OpenOffice ou dans un logiciel spécialisé. Mais.

De la relecture aux traductions

Mais l'immense avantage d'une interface de rédaction collaborative en ligne, telle que celle de SPIP, c'est de permettre à tous les visiteurs de participer, tant sur la rédaction d'articles que sur les relectures.

Et heureusement ! Combien de fautes ou de tournures de phrases lourdes, ou d'idées mal exprimées ont pu être corrigées grâce à la vigilance et à la participation des différents lecteurs. Elles furent nombreuses ; nul n'est à l'abri d'un coup de fatigue :). Il y a un regard multiple sur le contenu et c'est en cela que c'est très intéressant : apporter ce que l'on peut, ou même dire « je ne comprends pas » permet d'améliorer au final l'ensemble du livre.

Ma plus grande surprise, peut-être, dans cette histoire, est l'arrivée spontanée de traducteurs. Une envie de faire découvrir la technique de SPIP par delà les frontières. Nous avons volontairement bridé les tentations dans un premier temps, puis autorisé les traductions en une première langue, l'anglais, pour tester le fonctionnement des squelettes (ça a nécessité diverses expérimentations), puis le multilinguisme semblant fonctionner, nous avons ouvert récemment la porte à une seconde langue, l'espagnol.

Passer d'un site monolingue à un site multilingue implique des choix techniques qui ne sont pas évidents à trancher. Je suis encore à l'heure actuelle très sceptique sur certaines difficultés tel que « comment traduire un mot clé ? ». Pour l'instant ça fait des titres avec des balises contenant 3 langues... mais cela va vite être difficile s'il y a 8 langues à gérer... On a évacué très fièrement ce problème avec les rubriques en créant [1] un plugin (tradrub) permettant de créer et gérer des traductions entre rubriques. Mais il reste ces maux, ou mots... Affaire à suivre de ce côté. Mais revenons aux traducteurs...

En anglais, au début est arrivé Gilles, puis Thomas qui ont tranquillement réalisé plus de 40 traductions. Et un jour Mark Baber a débarqué ! Et... quelques semaines plus tard tout était traduit en anglais. C'est quelque chose de fabuleux. Quelques relecteurs attentifs comme Paolo éliminent les derniers coquilles anglaises et on se retrouve à très prochainement proposer la première, toute première édition d'un livre SPIP dans une autre langue que le français.

C'est là, à ce moment là, qu'on s'aperçoit de la force d'une communauté multilingue et d'un logiciel SPIP parfaitement adapté à presque toutes les problématiques de traduction.

D'un fichier pdf à un livre

Réaliser un livre lorsque l'on a qu'une page HTML à la base semble un rien difficile. Les imprimeurs à la demande, qui sont vraiment très adaptés pour de petites séries de livres, réalisent des impressions numériques à partir de fichiers au format PDF. L'enjeu consiste donc à transformer un contenu au format HTML en un contenu au format PDF mis en page. Cela semble très simple au premier abord.

On peut avoir comme idée de générer une page HTML et de l'importer dans OpenOffice (ou de le générer directement en .odt avec le plugin SPIP adapté), d'insérer table des matières et pieds de page, puis d'enregistrer le tout en PDF. Oui... mais... Voici quelques problèmes rencontrés : comment gérer les renvois et afficher sur les liens internes au document les numéros de pages auxquels ils correspondent ? comment faire prendre en compte la coloration syntaxique des codes HTML sans que cela fasse une liste extrêmement vilaine de morceaux de mots ? comment générer automatiquement des sections (au sens OpenOffice) à partir du HTML pour que le titre des chapitres apparaisse bien dans l'entête de toutes les pages du chapitre concerné ? Au bout du compte on remarque qu'on ne maitrise pas assez OOo pour cela.

Une autre idée, est d'utiliser les compétences de CSS3. Car CSS3 est en outre prévu pour gérer des impressions papiers. On donne le format, on crée des types de pages, indique quel texte placer dans l'entête, on peut aussi ajouter des renvois vers les numéros de page correspondant sur les liens internes... C'est extrêmement puissant.

Mais voilà... Qui gère ces propriétés de CSS3 suffisamment correctement ? aucun navigateur ! Ils en connaissent quelques-unes, comme la prise en compte des sauts de page souvent, mais pas toutes. Peu se débrouillent avec les marges, les formats du papier, les entêtes et pieds de page comme il faut.

Je n'ai croisé à ce jour qu'un seul logiciel capable de prendre en entrée un fichier HTML, de récupérer sa CSS3, et de générer le PDF attendu. C'est PrinceXML, logiciel qui n'est malheureusement pas libre, mais dont l'usage sur une machine locale est autorisée, du moins pour la version 7.0 que j'utilise, mais je vois aujourd'hui qu'ils ont sorti ce mois-ci une version 7.1 et que la licence me semble différente de ce qu'elle était en restreignant bien plus l'usage de la version gratuite... C'est très ennuyant ! Bref, ça serait bien de trouver ou créer une alternative libre ! Ou utiliser d'autres mécaniques, quitte à se passer de la coloration syntaxique...

Des déceptions...

Outre la difficulté de mise en œuvre technique – mais j'aime ces défis – c'est l'organisation et la cohérence des chapitres que je trouve complexe à trouver. J'avais lancé sur la liste de discussion spip-devel un sujet, en demandant « s'il existait un livre sur la programmation avec SPIP, quelle serait sa table des matières idéale ». J'ai été finalement déçu par le peu de réponses apportées ou qui disaient que l'organisation du site était déjà très bien comme ça. J'imaginais qu'à plusieurs on arriverait à trouver un chapitrage qui me/nous conviendrait et ce ne fut pas vraiment le cas. Du coup, je ne suis pas spécialement satisfait de l'ordre des chapitres de cette version 1, de leur enchevêtrement. Cela manque, je trouve, de fil conducteur, de lien.

L'autre élément d'insatisfaction c'est que cette version sort alors que j'ai le sentiment de n'avoir pas tout dit, qu'il reste plein de zones d'ombres, que certaines parties ne sont pas claires ou à réécrire, qu'il y a des absences, des chapitres commencés mais pas finis comme « développer des plugins » où l'on a de quoi rester sur sa faim.

Je suis triste de cela, et en même temps, je pense que je n'arriverai jamais à être 100% satisfait. Ce livre est une photo du site à un instant t et à cet instant là, des parties sont excellentes et d'autres à terminer, mais c'est toujours mieux que s'il n'y avait rien. Il faut savoir à un moment dire (merci BennyB) : « bon, on y va ? »

... aux perspectives

L'avenir est soumis à bien des incertitudes. Déjà : ce livre va-t-il plaire ? était-il attendu ? sera-t-il utilisé ? Nous verrons les retours dans quelques temps... Mais déjà nous avons réussi un beau défi : oui, on peut réaliser un livre libre, rédigé partiellement de manière collaborative, proposer à tous le pdf, le faire imprimer et le commercialiser. Cela marche. Même pour les traductions. On peut donc imaginer de nouveaux défis, d'autres perspectives :

sortir une version anglaise (99,9% est déjà traduit)
sortir une version espagnole (13% traduit) : souhaitons courage aux hispanophones et à Sylvano qui a démarré sur les chapeaux de roues !
ajouter pour la prochaine version des divertissements, par des illustrations ou strips horizontaux, pour alléger le côté très formel du texte
créer une trilogie « Publier | Personnaliser | Programmer » ou encore « Utiliser | Créer son site | Programmer », bref, quelque chose par type d'utilisateurs : du rédacteur/administrateur/traducteur, puis le bidouilleur/installateur/webmestre , et enfin pour les webmestres qui triturent les codes et autres développeurs...

À vous aussi, lecteurs, de proposer des améliorations. Ne pas oublier qu'il y a des tas de manières de participer à son échelle sur la galaxie SPIP, entre l'organisation d'évènements locaux, les traductions, les retours d'expérience, les rapports de bugs, les contributions sur les forums, les encouragements verbaux, de l'écriture de documentation, de contributions. Partage et ouverture. Ah, et si possible avec un peu de tendresse :)

Couverture du livre « Programmer avec SPIP »

Première version officiellement en vente, l' « Édition Troglo2 » de mai 2010.

J'en profite pour dire un GRAND MERCI à tous ceux qui de près ou de loin ont apporté leur pierre, leur regard, leur savoir, leur temps pour le site Programmer.spip.org ou pour le livre. Il y a de beaux et braves gens derrière tous ces textes et codes informatiques. Les Troglos2 pour ceux qui ont pu s'y déplacer, est un excellent évènement qui soude, motive, donne du soleil, et je suis heureux d'avoir croisé certains d'entre vous à cette occasion.

[1] enfin en le mettant à jour « from scratch »

Présence

Matthieu Marcillaud — 2008-09-12T08:49:00Z

La foule se lie ou se délie

De gens mouvants aux quatre vents

La fourmilière de Paris

Au matin fuit toujours le temps

Chacune des galeries emplies

Dans le flux de tous les instants

Promène quelques âmes fleuries

Et nombre de visages absents

Et c'est ainsi que je surgis

A Montparnasse comme un enfant

Je m'y élève et je grandis

Jusqu'à son parc verdoyant

Dans les douceurs de ce jardin

Où coule un calme reposant

L'esprit qui capte ces parfums

Oublie, oublie, oublie le temps.

Texte écrit dans le train juste après un passage au jardin Atlantique. Ce petit bout de verdure m'avait déjà appelé il y a deux ans : Paradis sur gare