Sommaire
L’idée du projet Abstract Wikipédia est de créer l’équivalent d’articles de Wikipédia sur un peu tous les sujets dans une sorte de « langue pivot », puis de traduire cette langue grâce à du code dans toutes les langues du monde Médiawiki. C’est un vieux rêve d’un des créateurs de Wikidata, qui quitte Google et rejoint la Wikimedia Foundation pour mener le projet.
Abstract Wikipédia s’intégrera à terme dans Wikidata, et utilisera en partie ses données. Le tout s’articulera autour de trois axes principaux : le contenu abstrait, la langue abstraite et le code de traduction. Ce dernier volet sera incarné par un « projet dans le projet » de « Wikipédia du code » si l’on peut dire : Wikilambda. Oui, parce que créer une langue et du contenu universel ce n’était pas déjà suffisamment ambitieux ⸮1
L’existant
Le projet précédent, Wikidata, est maintenant bien lancé et permet de collecter et d’utiliser des données sur une grande quantité d’éléments. Chaque entité dispose d’un identifiant sur Wikidata, par exemple Paris est Q90, Denny est Q18618629, la philosophie Q5891, ou encore la fabrication de polymère est Q453762, pour faire un inventaire à la Prévert. Chaque entité a un « libellé » dans plein de langues (ou pas).
Pourquoi détailler ce point ? Pour deux raisons :
- la première, cette idée d’avoir des entités identifiées par un code universel descriptible dans plusieurs langues est une des fondations techniques d’Abstract Wikipédia, et on va la retrouver absolument partout ; elle est généralisée dans la notion « d’entités » Wikidata, dont les éléments ne sont qu’un exemple, il existe également les « propriétés » et les « lexèmes » ;
- la seconde, ces éléments vont être utilisés comme une sorte de « vocabulaire abstrait » pour l’écriture de la Wikipédia abstraite ; ce vocabulaire est extensible à l’envi, avec la simple limite qu’il doit avoir un besoin d’un projet Médiawiki, c’est donc très souple.
Plus récemment, Wikidata s’est également doté de possibilités de stockage d’informations lexicales dans toutes les langues, de manière structurée, avec une base de données des mots dans les différentes langues, les Lexical Masks. Un masque va déterminer, pour une langue donnée, les formes possibles d’un mot, selon son type (nom, adjectif, etc.). Ces masques permettront de valider, pour chaque entité Wikidata, la complétude de ses données dans une langue, en fonction de son type.
Wikidata est déjà un très beau projet multilingue, qui continue de se développer et est très édité, et qui permet déjà de décrire du contenu sur les entités de manière indépendante de la langue. Mais les données associées sont une collection de faits sur l’entité, données en vrac sans ordre ni hiérarchie particulière et pas des articles rédigés et éditorialisés à part entière. Il s’agissait donc d’aller plus loin.
La future langue abstraite
Le plus parlant je pense en ces lieux est de commencer par lire des exemples tirés de https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Examples. Voici un exemple « d’article abstrait » :
Article(
content: [
Instantiation(
instance: San Francisco (Q62),
class: Object_with_modifier_and_of(
object: center,
modifier: And_modifier(
conjuncts: [cultural, commercial, financial]
),
of: Northern California (Q1066807)
)
),
Ranking(
subject: San Francisco (Q62),
rank: 4,
object: city (Q515),
by: population (Q1613416),
local_constraint: California (Q99),
after: [Los Angeles (Q65), San Diego (Q16552), San Jose (Q16553)]
)
]
)
Ce qui une fois converti donnera en anglais :
San Francisco is the cultural, commercial, and financial center of Northern California. It is the fourth‑most populous city in California, after Los Angeles, San Diego and San Jose.
et en allemand :
San Francisco ist das kulturelle, kommerzielle und finanzielle Zentrum Nordkaliforniens. Es ist, nach Los Angeles, San Diego und San Jose, die viertgrößte Stadt in Kalifornien.
C’est assez parlant pour un informaticien. Un article abstrait ressemblera à une sorte d’arbre de syntaxe abstrait d’un langage de programmation. Les nœuds de cet arbre seront constitués de « constructeurs » , qui seront des entités avec, comme les éléments, un identifiant comme Z1033 pour le constructeur « Instanciation » (fictif, rien de toute cela n’existe encore bien sûr), et aura une signification décidée par la communauté, un libellé dans les différentes langues… Chaque constructeur aurait des « paramètres » (comme « object » dans l’exemple).
Les utilisateurs auront à disposition une interface qui ne les forcera pas à écrire nécessairement du code textuel mais permettra d’utiliser une interface d’édition graphique de cet arbre abstrait, avec complément et propositions des différentes valeurs possibles. Il est également évoqué, à un horizon lointain, un système d’aide à la saisie qui permettra de taper dans sa langue et de voir une proposition abstraite correspondante préremplie.
Wikilambda : le Wikipédia du code ?
Pour le code qui sera chargé de la traduction, mais pas que, un nouveau sous projet sera lancé. Un nouveau type d’entité sera introduit : les fonctions, et un langage de programmation permettra de les écrire. Ce langage sera a priori exécutable, mais des implémentations seront réalisées dans d’autres langages, tels que Lua, déjà présent dans la galaxie Wikimédia comme langage utilisé pour les modèles, JavaScript ou d’autres, pour profiter de meilleures performances.
Il y a fort à parier que ce nouveau langage aura des mots clés qui seront traduits dans toutes les langues. On dirait presque un nouveau langage autant destiné à être une spécification des fonctions qu’un langage de programmation.
On peut se demander la raison de la création d’un nouveau langage, alors qu’il en existe tant d’autres, y compris ceux déjà utilisés par la communauté Wikimédia dans les wikis. La raison est peut‑être de faire rentrer le code dans un cadre similaire au reste de Wikidata : une entité par fonction, les noms des fonctions traduisibles pour un maximum d’accessibilité dans chaque langue tout en garantissant un code commun, le code accessible à tous à partir d’une simple adresse et d’une API… C’est une approche assez originale en tout cas. Est‑ce un pas de plus vers l’interopérabilité des systèmes ?
Il semble qu’une autre motivation soit aussi d’obtenir de la souplesse au niveau de l’infrastructure d’exécution du code.
Le rôle des données lexicographiques ?
Il y a quelque temps Wikidata a lancé une base de données lexicographiques, qui permet par exemple de trouver les mots qui signifient « eau » dans plein de langues ou encore les lexèmes décrivant une couleur (exemples tirés des exemples de requêtes Wikidata).
Ces données ne sont pas encore très développées, un des soucis étant sans doute que ce projet a déjà une contrepartie dans la galaxie Wikipédia, le Wiktionnaire évidemment. Ces deux projets n’ont, à ma connaissance, pas réellement réussi à travailler ensemble et à collaborer. Gageons que si les données lexicographiques de Wikidata deviennent une part importante d’Abstract Wikipédia et lui fournissent les mots, les accords, les conjugaisons, etc., la communauté aura une forte motivation à les améliorer.
État actuel du projet
Les choix du nom et du logo du futur site Web ne sont pas encore définis. Des discussions ont déjà commencé sur ces sujets : sur la page Web définissant le plan de développement et sur forum de discussions.
Les questions
Tout cela pose plein de questions qui pourront lancer la discussion !
L’approche au multilinguisme en vogue en ce moment est celle de la traduction automatique, avec comme socle, l’apprentissage automatique. Des projets comme DeepL se nourrissent de plein d’exemples issus d’Internet et d’autres corpus de textes « parallèles » qui sont proches dans plusieurs langues. Wikipédia indique que les textes de l’Union européenne, disponibles en plusieurs langues, ont, par exemple, servi à Linguee, ainsi que des articles de Wikipédia (on peut le voir en faisant une requête). Les exemples de traductions de ces mots, expressions et phrases de même sens dans deux ou plusieurs langues sont mises en correspondance sont ensuite données à manger à des algorithmes d’apprentissage automatique, par exemple pour les réseaux de neurones profonds, pour donner des programmes comme DeepL.
C’est très différent de l’approche d’abstract Wikipédia basée sur la construction d’un langage commun, qui ne nécessite pas d’exemple de traduction de chacune des langues dans toutes les autres, ainsi que de contenu commun, pour potentiellement fédérer les contenus disponibles dans différentes langues sans avoir à traduire un à un les articles dans toutes les langues. On peut également se demander si ces réseaux de neurones (ou autre modèle) sont ou seront, à terme, capables de créer un tel modèle « pivot » encodé dans la configuration de leurs neurones, et seront tout de même capables d’avoir de bonnes performances de traduction dans des paires de langues pour lesquelles on a peu de textes équivalents disponibles.
La création d’une langue abstraite, et du code pour la traduire, est sans doute aussi un défi. Traditionnellement, les wikis fonctionnent par petits incréments successifs, que la masse des contributions finit par améliorer. Est‑ce une approche qui peut fonctionner pour créer une langue et la faire évoluer ?
Un gros morceau du projet sera évidemment la génération du texte dans toutes les langues, qui dépendra de la langue créée par la communauté et du nombre de locuteurs de la langue concernée. Ça contraint les possibilités d’évolution ; par exemple, s’il y a plus de deux cents traducteurs, il faut conserver ce nombre, sinon ça risque de devenir compliqué en cas de changement majeur.
La communauté saura‑t‑elle gérer tous ces obstacles ? Les différentes communautés linguistiques sauront‑elles collaborer ? Le projet profitera‑t‑il des communautés Wiki(p|m)édiennes existantes ou devra‑t‑il créer sa propre communauté ?
En guise de conclusion
C’est encore une fois un projet intéressant et avec de la suite dans les idées de Denny, qui a montré qu’il savait mener à bien ce genre de chose. Adossé aux communautés Wikimédias, le potentiel de main d’œuvre est là et potentiellement aussi l’enthousiasme communautaire indispensable à la réussite d’un tel projet ! C’est rafraîchissant de voir une approche différente de l’approche purement « apprentissage automatique » actuellement en vogue.
Quelques bémols, car il y en a :
- c’est un projet qui va demander des compétences techniques avec une barrière importante à la contribution, n’importe qui ne pourra pas se plonger dans l’écriture du code de génération des textes dans une langue, et de bonnes connaissances en matière de linguistique seront demandées à ces codeurs. Le projet réussira‑t‑il à fédérer une communauté autours de ces projets, y compris pour les langues avec peu de locuteurs ? L’avenir le dira, mais dans tout les cas c’est à tenter ;
- il y a un recouvrement avec les projets Wikipédia, est‑ce qu’un Wikipédia « parallèle » réussira à attirer des contributeurs, qui rédigeront dans une langue exotique ?
Le projet a aussi quelques curiosités qui pourraient être intéressantes même si son objectif ambitieux n’est pas totalement atteint. Wikilambda, par exemple, semble être un projet avec un intérêt propre. Bon vent !
