Ce billet, Inventing as we go: building a visual editor for MediaWiki, a été écrit par James Forrester et publié sur le blog de la Wikimedia Foundation sous licence CC-BY, et a été traduit en français par Jean-Frédéric, Ælfgar, Emeric, R et Cha_Matou.
La Wikimedia Foundation et Wikia, travaillent sur un Éditeur visuel (VisualEditor), pour Wikipédia et tous les autres sites utilisant le logiciel MediaWiki. Cela prend beaucoup de temps, et on nous demande souvent ce que le travail implique, si c’est difficile, et pourquoi c’est aussi long. Il nous semble donc utile d’expliquer quelques-unes des subtilités du projet de développement logiciel le plus ambitieux de la Wikimedia Foundation.
Qu’essayons-nous de faire ?
Nous créons un logiciel qui permettra aux utilisateurs de charger, de modifier et d’enregistrer les articles Wikipédia en mode visuel, en remplacement du système actuel qui requiert l’apprentissage d’une syntaxe wiki compliquée. Avec le nouveau système, les articles qu’ils éditeront se présenteront de la même manière que ceux qu’ils lisent : les modifications qu’ils feront seront visibles avant même de sauvegarder, à la manière de l’édition d’un document dans un traitement de texte.
Personne n’avait fait cela avant ?
Oui et non. De nombreux éditeurs de texte en mode visuel existent, certains d’entre eux sont même open source et capables d’éditer de manière assez satisfaisante des pages web. Mais ils demeurent insuffisants par rapport à nos besoins, pour plusieurs raisons.
Il est particulièrement important que notre éditeur puisse fonctionner dans de nombreuses langues. Il ne s’agit pas simplement d’intégrer les langues qui s’écrivent de droite à gauche, ou avec des idéogrammes, mais bien d’être compatible avec chacune des 290 langues que nous proposons actuellement. Nous voulons également permettre l’utilisation de plusieurs langues dans un même document, de manière entièrement transparente, pour mieux servir nos communautés multilingues. Certaines des langues que nous nous sommes engagés à proposer ont un support logiciel très faible, et nous sommes souvent l’une des plus importantes, sinon l’une des seules, sources de contenu écrit pour elles.
Le développement de la syntaxe wiki au cours des douze dernières années constitue un autre problème : elle intègre désormais de nombreuses fonctionnalités riches et complexes, qui ne sont pas « du HTML simplifié ». Nous pensions que la plupart ne seraient utilisées que de manière ponctuelle, mais elles ont souvent évolué pour se retrouver au cœur de la façon dont les pages MediaWiki sont maintenant écrites, par des utilisateurs toujours plus nombreux.
Parmi ces fonctionnalités avancées : la transclusion de contenu (insérer une copie en temps réel d’une page dans une autre), les modèles (transclusion dont certaines parties sont définies dans la page de destination plutôt qu’à la source), et les parser functions (pages affichant différentes choses en fonction de centaines d’options, comme le jour de la semaine ou l’existence d’une autre page). Essayer d’adapter un éditeur existant à ces fonctionnalités aurait été extrêmement difficile, et plus compliqué que de partir de rien.
Qu’est-ce que le parseur ?
Au bout du compte, il ne s’agit pas seulement de modifier les pages, mais de lire et sauvegarder les pages wiki existantes dans l’ancien wikitexte, et de continuer à travailler avec en parallèle du nouvel éditeur. Nous ne pouvons mettre à la poubelle l’immense travail accompli par nos communautés durant ces douze dernières années, aussi nous faut-il réécrire ce « traducteur ». Ce qui veut dire réaliser un « parseur » (ou analyseur syntaxique) à double sens : un logiciel qui convertit le wikitexte en HTML et inversement. Jusqu’à présent, nous n’avions qu’un parseur à sens unique ; la deuxième étape, convertir ce que l’on souhaite écrire en wikitexte, c’était aux contributeurs de le faire dans leur tête.
Cela signifie que nous avons dû créer un projet à part − le Parsoid − capable de traduire dans un sens comme dans l’autre : de la syntaxe wiki aux pages web et inversement. C’est loin d’être une tâche facile : il faut être très prudent lorsque l’on change de parseur, car il est de la plus haute importance de ne rien casser ! Le vieux parseur, et la syntaxe wiki qu’il interprète, se sont développés au fil des idées des contributeurs, sans véritable idée directrice. Il y a près de deux milliards de versions des pages dans les seuls projets Wikimedia, et ce manque de vision d’ensemble a donné naissance à un très grand nombre de petites règles que le Parsoid doit suivre pour éviter des « dirty-diffs » – des cas où la syntaxe wiki ne serait pas interprétée par l’éditeur visuel.
Nous utilisons du test automatique pour transformer en « aller-retour » 100 000 pages prises au hasard dans la Wikipédia en langue anglaise (soit un bon échantillon de contenu wiki en alphabet latin) : prendre le wikitexte, le convertir en HTML, puis à nouveau en wikitexte, et comparer le résultat avec le document original. Cela nous aide à identifier de nombreux problèmes à résoudre pour que l’utilisation du Parsoid ne casse pas les articles. Nous en sommes aujourd’hui à 80% d’articles transformés en « aller-retour » sans aucune différence (au lieu de 65% en octobre), 18 % supplémentaires ne présentent que des différences mineures (espaces, guillemets, etc.), et les 2 % restants présentent des différences qui restent à résoudre (15% en octobre).
En savoir plus
Comme vous pouvez le voir, créer l’éditeur visuel dont ont besoin nos utilisateurs représente beaucoup de travail. Aucune technologie existante ne peut faire ce que nous voulons, nous devons donc travailler très dur pour y arriver. Nous attendons avec impatience les prochains mois pour montrer aux contributeurs comment ils pourront utiliser l’éditeur visuel et Parsoid. Pour leur permettre une meilleure expérience, libre de l’apprentissage des syntaxes compliquées, leur permettant de se concentrer sur le contenu et non sur les outils qu’ils utilisent pour écrire.
Si vous êtes intéressé, nous avons une brève présentation sur la façon dont l’éditeur visuel et le parseur fonctionnent, et ce à quoi ils ressembleront dans Wikipédia.
James Forrester
Product Manager, VisualEditor et Parsoid
Information de droit d’auteur : “VisualEditor-logo” Public Domain, ™Wikimedia Foundation, Inc., “Parsoid HTML-RDFa content model” par Jdforrester (WMF), sous CC-BY-SA 3.0, “VisualEditor-ModuleStack” par Trevor Parscal, sous CC-BY-SA 3.0