Wikimedia Meta-Wiki

Wikipédia abstraite/Plan

< Abstract Wikipedia
This page is a translated version of the page Abstract Wikipedia/Plan and the translation is 100% complete.
Other languages:

Ceci est une version en une seule page des sections individuelles qui sont y incluses. Cliquez sur les titres pour aller vers les pages individuelles.

Résumé

Dans la Wikipédia abstraite, le « Contenu abstrait » est représenté dans un format indépendant de la langue qui est directement modifiable par la communauté. Les Wikipédias locales peuvent accéder et enrichir leur propre contenu contrôlé localement avec ce « Contenu abstrait » (de la Wikipédia abstraite). De cette façon, les éditions localisées de Wikipédia peuvent sans grand effort fournir davantage de contenu à leurs lecteurs, un contenu qui est davantage exhaustif, plus actualisé et mieux passé en revue que ce que la plupart des Wikipédias locales peuvent fournir.

Étant donné les résutlats de recherche et les prototypes dans le domaine de la génération automatique de textes, il est malheureusement vrai que la génération en langue naturelle à partir du “Contenu abstrait” indépendant de la langue nécessite un système “Turing-complet” pour fonctionner. Mais afin de couvrir le nombre de langues que doit couvrir Wikipédia, ce système doit être sourcé par le plus grand nombre. C’est pourquoi nous introduisons Wikifunctions, un projet pour créer, cataloguer et maintenir une bibliothèque (ou un dépôt) ouverte de « fonctions », qui a de nombreux cas d’utilisations possibles.

La principale motivation de la Wikifunctions est le développement de « moteurs de rendu » (c’est-à-dire une partie des fonctions référencées ou hébergées dans Wikifunctions) qui transforme le « Contenu abstrait » en langue humaine, en utilisant les connaissances linguistiques et ontologiques disponibles de Wikidata (ou les connaisances venant d’autres sources de données ouvertes ayant des conditions de licence compatibles et utilisables dans Wikipédia, y compris les possibles données des autres projets Wikimedia comme le Wiktionnaire ou Wikispecies).

Le projet commencera par créer le projet Wikifunctions, puis il l’utilisera afin de permettre la création de la Wikipédia abstraite. Wikifunctions sera lancé dans la première année et nous ajouterons le développement de la Wikipédia abstraite dans la seconde année. Après deux ans, nous aurons créé un écosystème qui permettra la création et la maintenance d’un « Contenu abstrait » et l’intégration de ce contenu dans les éditions de Wikipédia, ce qui accroîtra significativement l’étendue, l’actualité, la pertinence et la précision de nombreuses éditions individuelles de Wikipédia. Ceci nous rapprochera significativement d’un monde où chacun peut partager la somme de toutes les connaissances.


Nom

Tous les noms mentionnés ici – Wikipédia abstrait et Wikilambda – sont préliminaires et n’ont été principalement nécessaires que pour écrire cette proposition et en discuter.

Les noms actuels sont basés sur l’idée suivante :

  • Wikipédia abstraite : le contenu dans Wikipédia abstraite est formalisé loin de toute langue humaine concrète.
  • Wikilambda : ceci est basé sur la notion que toute fonction peut être fondée dans le lambda-calcul. Également, Wλ semble quelque peu technophile (geek), avec le risque d’être perçu comme ne visant pas à élargir le public attendu et qu’il ne soit géré avec un biais que par des spécialistes déjà favorisés par un accès aux connaissances les plus larges dans leur propre culture.

Notez que le nom "Wikipédia abstraite" ne sera pas, en fait, affiché partout. Quand le projet sera réalisé, la Wikipédia abstraite ne sera qu’une partie de Wikidata. Il s’agit juste d’un nom pour le travail de développement et, par conséquent, sno nommage n’est pas crucial. Wikilambda en revanche sera un nouveau projet Wikimedia et donc le nom aura une bien plus grande visibilité. Ce serait bien qu’il arrive sous un bon nom pour le désigner.

Objections

Il y a déjà eu trois bonnes raisons de s’opposer au nom Wikilambda jusqu’à présent :

  • C’est réellement dur à épeler (avec ou sans le b ?) pour de nombreuses personnes (dit Effeietsanders).
  • Certaines personnes continuent à le lire incorrectement comme Wikilambada (dit Jean-Frédéric).
  • Il est également lu incorrectement comme WikiIambda / Wikiiambda (c’est-à-dire, un autre i/I au lieu du l/L), aussi ce devrait être au moins WikiLambda avec un L majuscule (suggéré par Fuzheado).

Autres noms suggérés

D’autres noms ont alors été considérés ou suggérés :

Ceci est une archive. Les nouveaux noms devraient être proposés dans Concours de nom du wiki des fonctions.

D’autres suggestions sont bienvenues.

En fait la première tâche P1.1 pour le projet sera de décider ensemble avec la communauté d’un nom et d’un logo. Ceci a déjà prévalu pour de précédents projets (logo de Wikidata, nom de Wikivoyage).


Objectifs

Le projet s’est fixé d’ambitieux objectifs prioritaires et un large ensemble d’objectifs secondaires.

Objectifs prioritaires

  • Permettre à plus de personnes de lire davantage de contenu dans la langue qu’elles choisissent.
  • Permettre à plus de personnes de contribuer du contenu destiné à davantage de lecteurs et donc accroître la portée des contributeurs sous-représentés.

Objectifs secondaires

Les objectifs secondaires incluent, mais sans s’y limiter :

  • La génération de textes en langue humaine, réutilisable et bien testée.
  • Permettre aux communautés de Wikimedia et aux tierces parties de créer des contenus dans davantage de langues.
  • Améliorer la communication et l’accessibilité aux connaissances bien au delà des projets Wikipédia.
  • Développer une approche innovante et beaucoup plus exhaustive pour la représentation des connaissances.
  • Développer une approche innovante pour repésensenter le résultat de la compréhension des langues humaines.
  • Une bibliothèque de fonctions.
  • Permettre de développer et partager les fonctions dans les langues natives des utilisateurs, au lieu de leur demander d’apprendre l’anglais dabord.
  • Permettre à chacun de partager des fonctions et de les exécuter.
  • Introduire une nouvelle forme de bien de connaissance pour un projet Wikimedia à gérer.
  • Introduire des composants innovants dans Wikipédia et d’autres projets Wikimedia qui permettent des fonctionnalités interactives.
  • Créer des fonctions fonctionnant au dessus de la base de connaissances de Wikidata, donc ajouter une capacité d’inférence afin de considérablement accroître la couverture des données de Wikidata.
  • Catalyser la recherche et le développement en démocratisant les interfaces de codage.
  • Permettre aux scientifiques et analystes de partager et travailler collaborativement sur des modèles.
  • Partager les spécifications et tests pour les fonctions.
  • La possibilité de référencer la sémantique des fonctions par des identificateurs bien définis.
  • Développement plus rapide de nouveaux langages de programmation du fait de l’accès à une bibliothèque (ou un dépôt) plus large et standard de fonctions sur un nouveau wiki dédié.
  • Définir des algorithmes et approches pour les standards et descriptions techniques.
  • Fournir l’accès à des fonctions puissantes afin de les intégrer dans des systèmes innovants d’apprentissage par la machine.

La liste n’est pas exhaustive.


Organisation

Nous supposons une équipe de base, employée par une seule organisation d'hébergement, qui travaillera exclusivement sur Wikifunctions et la Wikipédia abstraite. Elle sera soutenue par d'autres départements de l'organisation d'hébergement, tels que les ressources humaines, le département juridique, etc.

L’équipe sera mise en place afin d’être ouverte et accueillante pour les contributions externes au code de base. Elles pourront être bénévoles ou payées (par ex. par des subventions aux corps du mouvement ou par d’autres organisations et sociétés). Nous visons à offrir aux bénévoles un traitement privilégié afin d’accroître les chances de créer les communautés saines de bénévoles dont nous avons besoin pour un projet d’une telle ambition.

Le projet sera développé en pleine transparence. Les canaux de communication de l’équipe seront publics autant que possible. Les lignes directrices de communication seront publiques. Ceci aidera à créer une équipe de développement qui communique publiquement et qui permet d’intégrer les contributions externes au code de base.


Prérequis

Les prérequis importants suivants sont basés sur les principes et pratiques du mouvement Wikimédia :

  1. La Wikipédia abstraite et Wikifunctions seront des projets Wikimédia, maintenus et gérés par la Fondation Wikimédia. Ceci impose que la Wikipédia abstract et Wikilambda suivront les principes fondateurs et les lignes de conduite du mouvement Wikimédia.
  2. Le logiciel pour exécuter la Wikipédia abstraite et Wikifunctions seront développés sous une licence de code source ouvert et ne dépendra que de logiciels en code source ouvert.
  3. L’installation de la Wikipédia abstraite et de Wikifunctions s’intégrera dans l’infrastructure Wikimédia abstraite aussi facilement que possible. Ceci signifie que nous devrions tenir aussi loin que possible dans la même infrastructure de déploiement, de maintenance et d’opérations.
  4. Tout le contenu de la Wikipédia abstraite et de Wikifunctions sera rendu disponible sous des licences libres.
  5. Le succès de la Wikipédia abstraite et de Wikifunctions sera mesuré pour la création de communautés saines et par la quantité de connaissance disponible dans des langues qui n’avaient auparavant pas accès à cette connaissance.
  6. La Wikipédia abstraite suivra les principes définis par de nombreuses éditions individuelles de Wikipédia : en particulier, la neutralité de point de vue, la vérifiabilité, la notoriété et l’absence de recherche originale (principes développés dans Développement de la capacité communautaire et par les communautés de chaque wiki local).
  7. La Wikipédia abstraite et Wikifunctions seront entièrement internationalisés et seront disponibles et modifiables dans toutes les langues des projets Wikimédia. Que ceux-ci soient entièrement localisés dépendra des communautés.
  8. Le principal objectif est de soutenir les éditions locales de Wikipédia, Wikidata et les autres projets Wikimédia, dans cet ordre. L’objectif secondaire est de faire croître nos propres communautés. Les derniers objectifs seront de soutenir le reste du monde.
  9. Les communautés Wikipédia locales doivent avoir le contrôle de l’étendue par laquelle la Wikipédia abstraite les affecte. Si elles ne veulent pas être affectées par ceci, elles peuvent l’ignorer entièrement et rien ne changera pour elles.

Les développeurs de la Wikipédia abstraite ne décident pas de son contenu, de même que les développeurs de MediaWiki ne décident pas du contenu de Wikipédia. Au contraire des autres projets Wikimédia, les développeurs prendront une part active dans l’installation et le démarrage du jeu initial de types et de fonctions, ainsi que dans la création des fonctions nécessaires dans Wikifunctions pour la Wikipédia abstraite et pour aider à faire démarrer les communautés pour le rendu linguistique. Au contraire des autres projets, l’équipe de développement de la Wikipédia abstraite et du wiki des fonctions sera au départ plus impliquée dans les projets mais visera à passer la main sur tout cela aux communautés le plus tôt possible.

Les prérequis suivants sont utilisés comme lignes directrices fortes que nous appliquerons dans la conception et le développement de la Wikipédia abstraite :

  1. La Wikipédia abstraite et Wikifunctions sont un système socio-technique. Au lieu de tenter de développer une intelligence excessive, nous dépendrons des communautés Wikimédia.
  2. L’objectif premier de la Wikipédia abstraite et de Wikifunctions est de servir des cas d’utilisation réelle dans Wikipédia, et non de permettre une certaine forme de perfection hypothétique dans la représentation de la connaissance ou pour représenter la totalité du langage humain.
  3. La Wikipédia abstraite et Wikifunctions devront garder l’équilibre entre la facilité d’utilisation et l’expressivité. L’interface utilisateur ne devrait pas être compliquée pour ne couvrir que quelques cas frontaliers exceptionnels d’utilisation.
  4. Ce qui relève de situations exceptionnelles sera défini en fonction de sa fréquence d’apparition dans Wikipédia. Plutôt que de s’appuyer sur des preuves anecdotiques ou des cas isolés nous analyserons Wikipédia et observerons la fréquence des cas spécifiques.
  5. Soyons pragmatique avant tout. Pouvoir déployer est préférable à chercher la perfection.
  6. La Wikipédia abstraite et Wikifunctions fourniront de nombreuses données innovantes qui pourront soutenir la recherche, les développements et les cas d’utilisation externes. Nous voulons nous assurer que cela sera facilement utilisable.
  7. Wikifunctions fournira une interface API pour appeler chacune des fonctions qui y sont définies. Mais il y aura une limite sur le coût en terme de capacité de calcul que cela offrira.
  8. La Wikipédia abstraite et Wikifunctions seront modifiables aussi bien par des humains que par des robots. Mais les personnes qui pilotent les robots doivent être conscientes de leur responsabilité plus élevée afin de ne pas surcharger la communauté.


Architecture

Les principaux composants du projets sont les trois suivants :

  1. Constructeurs – définitions des constructeurs et leurs emplacements, y compris ce qu’ils signifient et les restrictions sur les types pour les emplacements et le type de retour du constructeur (par ex. définir un constructeur rang qui prend un élément, un type d’élément, le rang en tant que nombre, selon quoi il est classé, et une contrainte locale).
  2. Contenu – appels abstraits aux constructeurs y compris les valeurs par défaut pour les emplacements (par ex. rang(San Francisco, ville, 4, population, Californie))
  3. Rendus – fonctions qui prennent un contenu et une langue et retourne un texte résultant dans la langue humaine donnée pour representer la signification du contenu (par ex. dans l’exemple donné, cela donne « San Francisco est la quatrième plus grande ville la plus peuplée en Californie. »)

 

Il existe quatre possibilités principales pour le lieu de mise en œuvre des trois différents composants principaux :

  1. Les constructeurs, le contenu et les rendus sont mis en œuvre dans Wikidata.
  2. Les constructeurs et les rendus sont mis en œuvre dans Wikifunctions, alorts que le contenu le sera dans Wikidata aux côtés de l’élément correspondant.
  3. Les constructeurs, le contenu et les rendus sont mis en œuvre dans Wikifunctions.
  4. Les constructeurs et le contenu sont mis en œuvre dans Wikidata, et les rendus dans les éditions locales de Wikipédia.

La solution 4 a le désavantage que de nombreuses fonctions peuvent être partagées enre les différentes langues : en déplaçant les rendus et fonctions vers les éditions locales de Wikipédia, nous retirons cette possibilité. Également, en relégant les moteurs de rendus vers les Wikipédias locales, nous passons à côté du potentiel qu’un catalogue indépendant de fonctions pourrait permettre.

Nous pensons qu’il est avantageux pour la communication et la construction communautaire d’introduire un nouveau projet, Wikifunctions, pour une nouvelle forme de biens de connaissance, les fonctions, qui incluent aussi les moteurs de rendus. Ceci milite alors en faveur des solutions 2 et 3.

La solution 3 nous demande de créer un nouvel emplacement pour chaque article Wikipédia possible dans le wiki des fonctions. Étant donné que la place naturelle pour ceci existe déjà dans Wikidata avec ses éléments , il serait plus pratique de l’utiliser et de stocker le contenu conjointement avec les éléments dans Wikidata.

Pour ces raisons, nous favorisons la solution 2 et la supposons pour le reste de la proposition. Si nous basculons à uneautre, le plan du projet peut facilement être accomodé (hormis pour la solution 4, qui nécessiterait nombre de réécritures). Notez que la solution 2 nécessite l’accord de la communauté de Wikidata avant de procéder. Si elle n’est pas daccord, la solution 3 est l’option de repli la plus proche.

L’architecture proposée pour la Wikipédia multilingue ressemble à ce qui suit. Wikipédia appelle le Contenu qui est scoaké dans Wikidata à côté des éléments. Nous appelons Wikipédia abstraite cette extension de Wikidata. Notez qu’il ne s’agit que d’un nom pour le projet de développement, et que ne s’attend pas à ce que ce soit un nom affiché un peu partout – il n’y aura pas un nouveau wikiprojet de ce nom. Avec un appel aux Rendus dans Wikifunctions, le Contenu abstrait est traduit en langue humaine. Les Rendus dépendent des autres Fonctions, Types, et Constructeurs dans Wikifunctions. Wikifunctions peut également se servir de la connaissance lexicographique présente dans les Lexèmes de Wikidata, qui peuvent être utilisés pour traduire le Contenu abstrait en texte. Wikifunctions sera un nouveau projet à part entière, au même titre que Commons, Wikidata ou Wikisource.

 

(Les composants nommés en italique doivent être ajoutés par cette proposition, les composants en gras existent déjà. Les boîtes du haut sont des projets Wikimedia, les boites internes sont des parties des projets Wikimedia indiqués.) ("Wikilambda" était le nom de travail de ce qui est maintenant connu sous le nom de "Wikifonctions").


Composants

Nous avons besoin d’étendre les wikis des projets de Wikimédia dans trois domaines :

  1. dans les éditions locales de Wikipédia et d’autres projets clients en utilisant les nouvelles capacités offertes,
  2. dans Wikidata pour créer le contenu (de la Wikipédia abstraite) et
  3. dans un nouveau projet, Wikifonctions (Wikifunctions en anglais), qui vise à créer une bibliothèque de fonctions.

Extensions pour les éditions locales de Wikipédia

Chaque édition locale de Wikipédia peut choisir, selon sa communauté locale, une des trois options suivantes :

  1. l’intégration implicite avec la Wikipédia abstraite ;
  2. l’intégration explicite avec la Wikipédia abstraite ;
  3. aucune intégration avec la Wikipédia abstraite.

L’extension pour les éditions locales de Wikipédia a les fonctionnalités suivantes : une nouvelle page spéciale, deux nouvelles fonctionnalités et trois nouveaux mots-clés magiques.

F1 : nouvelle page spéciale : Abstract

Une nouvelle page spéciale sera disponible sur chaque édition locale de Wikipédia, qui sera utilisée avec un Q-ID ou le nom de l’article locale et une langue facultative (qui sera par défaut la langue de l’édition locale de Wikipédia). Des exemples d’URL de page spéciale devraient ressembler à ce qui suit :

https://en.wikipedia.org/wiki/Special:Abstract/Q62
https://en.wikipedia.org/wiki/Special:Abstract/Q62/de
https://en.wikipedia.org/wiki/Special:Abstract/San_Francisco
https://en.wikipedia.org/wiki/Special:Abstract/San_Francisco/de

Si la page spéciale est appelée sans paramètres, alors un formulaire est affiché qui permet la sélection d’un Q-ID et d’une langue (préremplie avec la langue locale du wiki).

La page spéciale affiche le Contenu du Q-ID sélectionné ou au Q-ID lié au site de l’article respectif et en fait le rendu dans la langue sélectionnée.

F2 : création explicite d’un article

Si l’édition locale de Wikipédia choisit l’option d’intégrer la Wikipédia abstraite au moyen d’une création explicite d’article, c’est de cette façon qu’elle le fera.

Le contributeur va sur un élément de Wikidata qui n’a pas encore de lien de site vers l’édition locale de Wikipédia. Il ajout un lien vers une page qui n’existe pas encore. De cette façon, il spécifie le nom de l’article à créer. Par exemple, si Q62 n’a pas encore d’article en français, et donc aucun lien de site Wikipédia, il peut ajouter le lien de site San Francisco pour fr.wikipedia.

Sur l’édition locale de Wikipédia, ceci crée un article virtuel dans l’espace de noms principal. Cet article a le même contenu que la page spéciale décrite ci-dessus, mais il peut être trouvé par l’URL habituelle, par ex.

https://en.wikipedia.org/wiki/San_Francisco

Les liens vers cet article, qui utilisent le nouveau nom spécifié, ressemblent exactement aux autres liens, c’est-à-dire qu’un lien vers [[San Francisco]] pointera vers l’article virtual, sera bleu, etc. De tels articles sont indexés pour la recherche dans l’édition donnée de Wikipédia et également pour les recherches externes.

Si un utilisateur clique sur le lien pour modifier l’article, il peut choisir soit d’aller vers Wikidata et modifier le Contenu abstrait (méthode préférée), soit de démarrer un nouvel article dans la langue locale depuis rien, soit matérialiser la traduction actuelle en texte et alors commencer à le modifier localement.

Si un article local existant avec un lien de site est supprimé, un article virtuel est automatiquement créé (puisque nous connaissons le nom et pouvons conserver les liens).

Afin de supprimer un article virtuel, le lien de site dans Wikidata doit être supprimé.

Toutes les modifications dans l’édition locale de Wikipédia doivent être réalisées explicitement, c’est pourquoi nous appelons cette option la création explicite d’article. Nous nous attendons à faire de cette option celle par défaut pour les éditions locales de Wikipédia, à moins qu’elles choisissent soit la création implicite d’article, soit aucune intégration.

Voir également la discussion au sujet de l’intégration.

F3 : création implicite d’un article

Si une édition locale de Wikipédia opte pour la création implicite d’article depuis Wikidata, alors le résultat de l’appel de la page spéciale abstraite sur tout élément de Wikidata qui n’a pas de lien de site vers l’édition de Wikipédia donnée mais qui effectuerait le rendu du contenu dans la langue donnée sera indexé comme si l’article était présent dans l’espace de noms principal et rendu disponible lors de la recherche comme s’il était présent dans l’espace de noms principal.

Un nouveau mot-clé magique est introduit pour créer un lien vers des articles virtuels depuis des articles normaux, voir F6 LINK_TO_Q. Ceci peut être intégré de façon invisible dans l’éditeur visuel.

Ceci implique, et de loin, le moins d’effort pour la communauté afin de gagner de nombreux articles et ce serait une bonne option pour les petites communautés.

F4 : liens ou onglets

Chaque article sur une édition locale de Wikipédia qui est connectée à un élément sur Wikidata reçoit un nouveau lien, soit en tant qu’onglet en haut de l’article, soit comme un lien dans la barre latérale. Suivre ce lien affiche le Contenu pour l’élément de Wikidata connecté, rendu dans la langue locale. Les articles virtuels n’ont pas cet onglet, mais leur bouton Modifier va directement modifier le Contenu dans la Wikipédia abstraite.

F5 : nouveau mot-clé magique : ABSTRACT_WIKIPEDIA

Le mot-clé magique est remplacé par le wikitexte résultant du rendu du Contenu sur l’élément Wikidata connecté à cette page par les liens de site.

Le mot-clé magique peut être utilisé avec deux paramètres facultatifs, l’un étant un Q-ID, l’autre une langue. Si aucun Q-ID n’est donné, le Q-ID par défaut est l’élément Wikidata auquel cette page est connecté par les liens de sites. Si aucune langue n’est donnée, la langue par défaut est celle du wiki donné.

Exemples d’appels :

{{ABSTRACT_WIKIPEDIA}}
{{ABSTRACT_WIKIPEDIA:Q62}}
{{ABSTRACT_WIKIPEDIA:Q62/de}}

Si aucun Q-ID n’est donné ou choisi par défaut, un message d’erreur apparaît.

Plus tard, cela permettra de sélectionner des sections nommées du Contenu.

Les éditions de Wikipédia qui choisissent de n’avoir aucune intégration de la Wikipédia abstraite peuvent cependant utiliser ce nouveau mot-clé magique.

Notez que l’introduction d’un nouveau mot magique est un plan préliminaire. La tâche 2.3 étudiera si nous pouvons obtenir ces fonctionnalités sans avoir à le faire.

F6 : nouveau mot-clé magique : LINK_TO_Q

Ce mot-clé magique transformera un lien soit vers l’article local qui est lié au site pour le Q-ID donné, soit si aucun n’existe , vers la page spéciale abstraite pour le Q-ID donné. Ceci permettra d’écrire des articles avec des liens vers des articles virtuels, qui seront remplacés automatiquement une fois qu’un contenu local est créé.

Exemples d’appel :

{{LINK_TO_Q:Q62}}

ce qui résultera en :

[[San Francisco]]

si l’article existe, sinon cela produira :

[[Special:Abstract/Q62|San Francisco]]

Notez que l’introduction d’un nouveau mot magique est un plan préliminaire. La tâche 2.3 étudiera si nous pouvons obtenir ces fonctionnalités sans avoir à le faire.

F7 : nouveau mot-clé magique : LAMBDA

Ceci appelle une fonction spécifiée dans Wikidata en lui fournissant ses paramètres et effectue le rendu de la sortie sur la page.

Par exemple l’appel suivant :

{{LAMBDA:capitalize("san francisco")}}

produira la sortie de « San Francisco » sur la page (en supposant qu’il existe une fonction ayant la clé locale et avec la définition et la mise en œuvre attendues). Cela utilise la langue du wiki local pour analyser l’appel.

Nous devons également considérer l’option d’appel d’une version spécifique d’une fonction afin de réduire les dysfonctionnements ultérieurs.

Notez que l’introduction d’un nouveau mot magique est un plan préliminaire. La tâche 2.3 étudiera si nous pouvons obtenir ces fonctionnalités sans avoir à le faire.

Extensions pour Wikidata

Nous ajoutons un nouvel espace de noms auxiliaire à l’espace de noms principal de Wikidata. C’est-à-dire que chaque page d’élément sous la forme www.wikidata.org/wiki/Q62 recevra également une page de contenu accompagnante www.wikidata.org/wiki/Content:Q62. Cette page contient le contenu abstrait, indépendant de la langue, et permet sa modification et sa maintenance.

Des pages spéciales supplémentaires pourraient être nécessaires. Ceci sera étendu dans la seconde partie du projet. Ceci nécessite l’accord de la communauté Wikidata afin que le projet puisse être utilisé pour stocker le contenu abstrait, et un autre projet hôte sera utilisé si elle s’y oppose.

F8 : nouvel espace de nom : Content

Un nouvel espace de noms avec de nombreuses fonctionnalités complexes interactives pour la modification. Fournit des composants d’interface utilisateur et la mise en page permettant de créer et maintenir les contenus abstraits, de même que les fonctionnalités pour évaluer ces contenus (par ex. afficher quelle partie est affichée par langue, etc.) Ceci est essentiellement un sous-ensemble de la fonctionnalité F11 pour l’espace de noms Function.

F9 : nouveau type de données : Content

Un nouveau type de données qui contient un (court) Contenu. Le principal cas d’utilisation est pour les Descriptions dans les Éléments et pour les Gloses dans les Sens des Lexèmes.

F10 : indexation et utilisation des Descriptions dans les Éléments et des Gloses dans les Lexèmes

Indexer et surfacer les linéarisation des champs de Description pour les Éléments et les Gloses dans les Lexèmes, également s’assurer que pour les champs de Description des Éléments il n’y a pas paires Libellé / Description en doublon. Permettre de corriger celles-ci par des modifications manuelles.

Extensions pour les autres projets de Wikimédia

D’autres projets Wikimédia recevront aussi les mots-clés magiques F7 LAMBDA et F5 ABSTRACT_WIKIPEDIA, mais aucune des autres fonctionnalités, puisque cela ne leur semble pas particulièrement utile. Ceci pourrait changer à la demande des communautés données.

Extensions pour le nouveau wiki des fonctions

Wikifonctions (Wikifunctions) sera un nouveau projet Wikimédia sur un nouveau domaine. L’espace de noms principal sera le nouvel espace Function. Le reste de Wikifonctions sera un wiki traditionnel de Wikimédia.

F11 : nouvel espace de noms : Function

Cela doit permettre le stockage de fonctions, types, interfaces, valeurs, tests, etc. Il y a un unique espace de noms qui contient des constants (telles que des types ou des valeurs simples), des interfaces de fonction, des mises en œuvre de fonction et donc également des constructeurs et moteurs de rendu. Les entités dans cet espace de noms sont nommés par des Z-ID, semblables aux Q-ID des éléments de Wikidata, mais commençant par un Z et suivi d’un numéro.

Il y a de nombreux types différents d’entités dans l’espace de noms Z. Ceux-ci incluent des types et d’autres constantes (qui sont essentiellement des fonctions d’arité nulle, c’est-à-dire sans paramètre), ainsi que des fonctions classiques d’arité positive.

Les contributeurs peuvent créer de nouveaux types de fonctions dans l’espace de noms Function et ensuite les utiliser.

Les fonctions peuvent avoir des paramètres. Les fonctions avec leur paramètres donnés peuvent être exécutées et retourner une valeur dont le type est donné par la définition de la fonction.

L’espace de noms Function est complexe et aura des vues très différentes selon le type de la fonction, par ex. pour les interfaces, les mises en œuvre, les tests, les types, les valeurs, etc. Il y aura différentes interfaces utilisateur pour les représenter, même si elles sont toutes stockées en interne comme des Objets-Z. Éventuellement, les différentes vues seront toutes générées par des fonctions dans Wikifonctions.

Il sera possible de geler et dégeler des entités dans l’espace de nom Function. Ceci est similaire à une page protégée, mais ne restreint que la modification de la partie valeur de l’entité, par le libellé, la description, etc.

F12 : nouvelles pages spéciales et nouveaux modules d’API

De nouvelles pages spéciales et de nouveaux modules d’API seront créés pour prendre en charge le nouvel espace de noms Function. Ceci inclura, en particulier, une page spéciale et un module d’API qui permet d’évaluer des fonctions avec les paramètres données. À côté de ça, il inclura diverses pages spéciales et APIs qui soutiendront la maintenance du contenu (tels que les recherches par nombre et types de paramètres, des pages statistiques sur la fréquence d’appel de certaines mises en œuvre, des pages de test, etc.). L’objectif est de mettre en œuvre le plus possible de ces possibilités au sein de Wikifonctions.


Tâches

Le développement est divisé en deux parties principales. La partie P1 est destinée à mettre en place Wikifonctions, le faire fonctionner, afin qu’il soit suffisamment développé pour soutenir la création de contenus requise pour la partie P2. La partie P2 concerne alors la création de contenu dans Wikidata et à permettre aux éditions de Wikipédia d’accéder à ce contenu. Après ceci, le développement se poursuivra pour améliorer à la fois Wikifonctions et la Wikipédia abstraite. La poursuite de ce développement n’est pas couverte par ce plan. Notez que tout le calendrier dépend de la quantité de ressources humaines avec laquelle nous pourrons travailler.

Dans la première année, nous travaillerons exclusivement sur la partie P1. La partie P2 ne démarrera que dans la deuxième année et demandera d’affecter des ressources supplémentaires au projet. Les parties P1 et P2 pourront être développées en parallèle durant les 18 mois qui suivent. Selon les résultats et succès du projet, le personnel affecté au développement ultérieur sera décidé autour du 24e mois, puis réévalué régulièrement à partir de cette date.

Ce plan couvre les 30 premiers mois de développement. Les principaux produits livrables seront :

  1. Wikifonctions, un nouveau projet et wiki de la Fondation Wikimédia, avec sa propre communauté et sa propre mission, qui vise à fournir un catalogue de fonctions et à permettre à chacun de partager dans ce catalogue et à lui donner du pouvoir en démocratisant l’accès à la connaissance informatique.
  2. Un dépôt interwiki pour partager des modèles et modules entre les projets de la Fondation Wikimédia, ce qui répondra au souhait longtemps attendu des communautés. Ceci fera partie de Wikifonctions.
  3. La Wikipédia abstraite, un projet inter-wiki qui permet de définir du contenu dans Wikidata, indépendamment de toute langue humaine, et qui est intégré dans diverses éditions locales de Wikipédia, afin d’accroître considérablement la quantité de connaissances que les locuteurs de langues actuellement mal servies pourront partager.

<span id="_Part_P1:_Wikifunctions">

Partie P1 : Wikifonctions

<span id="_Task_P1.1:_Project_initialization">

Tâche P1.1 : initialisation du projet

Nous configurerons des pages wiki sur Méta, des composants de suivi d’anomalies, des listes de discussion, un bureau consultatif et d’autres moyens appropriés de discussion avec la communauté la plus large. Nous commencerons à en discuter, déciderons des noms pour Wikifonctions et la Wikipédia abstraite et lancerons un concours pour les logos, organiserons la création d’un code de conduite et effectuerons les étapes nécessaires pour une saine communauté.

Il nous faudra démarrer le processus communautaire pour définir le choix de licence pour les différentes parties du projet : le contenu abstrait dans Wikidata, les fonctions et autres entités dans Wikifonctions, ainsi que le statut légal du texte généré à afficher dans Wikipédia. Ceci devra être terminé avant la tâche P1.9. Cette décision nécessitera l’avis d’un conseiller juridique.

<span id="_Task_P1.2:_Initial_development">

Tâche P1.2 : développement initial

La première étape de développement est de créer le wiki pour Wikifonctions avec un espaces de noms Fonction qui permettra le stockage et la modification des Objets Z (plus contraints que les objets JSON – en fait nous pourrions commencer avec les extensions JSON existantes et bâtir dessus). Le jalon initial vise à avoir :

  • Les types initiaux : chaîne Unicode, entier positif jusqu’à N, booléen, liste, couple, langue, texte monolingue, texte multilingue, type, fonction, mise en œuvre intégrée et erreur.
  • Un ensemble initial de constantes pour les types.
  • Un ensemble initial de fonctions : si, tête, queue, est_zéro, successeur, prédécesseur, abstraire, réifier, chaîne_égale, non-et, constructeurs, probablement quelques autres fonctions, chacune avec une mise en œuvre intégrée.

Ceci permettra de commencer à développer les composants d’interface utilisateur pour les appels de fonctions et de créer un premier ensemble d’outils et d’interfaces pour afficher les différents types d’Objets Z, mais aussi les Z Objets génériques. Ceci inclut également un premier évaluateur qui s’exécute sur les serveurs de Wikimédia.

Notez que les mises en œuvre initiales des vues, des interfaces de modification et des validateurs seront probablement jetées graduellement après P1.12 une fois que tous ceux-ci seront internalisés. Internaliser des éléments de code signifie les sortir du noyau pour les placer dans l’espace utilisateur, c’est-à-dire les mettre en œuvre à nouveau dans Wikifonctions et les appeler depuis ce dernier.

<span id="_Task_P1.3:_Set_up_testing_infrastructure">

Tâche P1.3 : mise en place de l’infrastructure de test

Wikifonctions nécessitera plusieurs systèmes de test. Un pour tester le noyau, un pour tester l’interface utilisateur sur le web, un pour tester le contenu de Wikifonctions lui-même. Ceci sera une tâche poursuivie qui devra être intégrée avec le système de contrôle de version.

<span id="_Task_P1.4:_Launch_public_test_system">

Tâche P1.4 : lancement du système public de test

Nous installerons un système de test visible publiquement et un système de test modifiable qui exécute les bords saillants du code (avec au moins un déploiement par journée de travail). Nous inviterons la communauté à y venir pour tenter de casser des fonctionnalités. Nous pourrions utiliser ce système pour des tests d’intégration continue.

<span id="_Task_P1.5:_Server-based_evaluator">

Tâche P1.5 : évaluateur hébergé sur le serveur

Alors que le développement initial a créé un évaluateur simple qui ne fonctionne qu’avec les mises en œuvre intégrées et qui a donc un comportement très prévisible, la tâche P1.6 qui arrive pour la composition de fonction nécessitera que nous repensions l’évaluateur. Le premier évaluateur s’exécutera sur l’infrastructure de Wikimédia et nécessitera les capacités de suivi et de régulation, ainsi que potentiellement la possibilité d’allouer aux utilisateurs différentes quantités de ressources de calcul selon qu’ils sont connectés et identifiés ou pas.

<span id="_Task_P1.6:_Function_composition">

Tâche P1.6 : composition de fonctions

Nous permettons la création de nouvelles interfaces de fonction et d’un nouveau type de mise en œuvre, qui sont composés d’appels de fonctions. Par ex. cela permet de mettre en œuvre

ajouter(x, y)

comme

si(est_zéro(y), x, ajouter(successeur(x), prédécesseur(y))

et le système pourra exécuter ceci. Cela permet aussi de multiples mises en œuvre.

<span id="_Task_P1.7:_Freeze_and_thaw_entities">

Tâche P1.7 : gel et dégel des entités

Un niveau de protection qui permet de modifier les métadonnées d’une entité (nom, description, etc.), mais pas la valeur réelle. Cette fonctionnalité pourrait être également utile pour Wikidata. Une proposition plus élaborée du versionnement est suggérée ici.

<span id="_Task_P1.8:_Launch_beta_Wikifunctions">

Tâche P1.8 : lancement de Wikifonctions en version bêta

Le système bêta exécute l’itération suivante du code qui continue sur Wikifonctions avec le cycle suivant de développement, afin d’effectuer des tests.

<span id="_Task_P1.9:_Launch_Wikifunctions">

Tâche P1.9 : lancement de Wikifonctions

Passer en revue la sécurité. Installer un nouveau wiki de projet Wikimédia. Déplacer certaines des pages wiki de Méta-Wiki à Wikifonctions.

<span id="_Task_P1.10:_Test_type">

Tâche P1.10 : type Test

Introduire un nouveau type pour l’écriture de tests des fonctions. Ceci est réalisé en spécifiant les valeurs d’entrée et une fonction qui vérifie la sortie. Au delà de l’introduction du type Test, les Fonctions et Mises en œuvre doivent aussi utiliser les Tests et les intégrer au développement d’une Mise en œuvre et aux vues d’Interface.

<span id="_Task_P1.11:_Special_page_to_write_function_calls">

Tâche P1.11 : page spéciale pour écrire des appels de fonction

Nous avons besoin d’une page Spéciale qui permet et prend en charge l’écriture des Appels de fonctions, avec une vérification syntaxique de base, la complétion automatique, la documentation, etc. Un sous-ensemble de cette fonctionnalité sera également intégré aux pages des Fonctions et Mises en œuvre individuelles afin de les exécuter avec des valeurs plus complexes. Cette page Spéciale dépend de l’API simple initiale pour évaluer des Appels de fonction.

<span id="_Task_P1.12:_JavaScript-based_implementations">

Tâche P1.12 : mises en œuvre basées sur JavaScript

Nous permettons un nouveau type de Mises en œuvre, qui sont celles écrites en JavaScript. Ceci nécessite de traduire les valeurs en JavaScript et à l’inverse en Objets-Z. Ceci nécessite également de penser à la sécurité, au moyen de l’analyse du code et d’un bac à sable, initialement enrichie par un passage en revue manuel et le gel (voir P1.7). Si le lambda-calcul (voir O1) n’a pas encore réussi ou a été sauté, nous pouvons également atteindre l’auto-hébergement pour Wikifonctions par cette tâche, qui permettrait d’internaliser la majeure partie du code.

<span id="_Task_P1.13:_Access_functions">

Tâche P1.13 : fonctions d’accès

Ajouter le mot magique Lambda (voir F7) aux projets Wikimédia afin de pouvoir encoder des appels de fonctions vers Wikifonctions et d’intégrer le résultat dans la sortie du projet Wikimédia donné. Ceci créera en fait un système centralisé de modèles puisque les personnes réaliserons qu’elles peuvent désormais remettre en œuvre les modèles dans Wikifonctions et alors les appeler depuis leurs wikis locaux. Ceci sera précédé par une analyse des solutions existantes, telles que les TemplateData et les appels Lua via l’extension Scribunto.

Ceci pourrait conduire à demander aux communautés d’activer le langage des modèles de MediaWiki et Lua (voir P1.15) en tant que langages de programmation au sein de Wikifonctions. Ceci conduira probablement à des demandes pour une solution améliorée pour la liste de suivi, de façon similaire à ce qu’a fait Wikidata, et à des mises en œuvre basées sur les modèles de Mediawiki, ainsi que d’autres demandes de la communauté. Afin de compléter ces tâches, une personne supplémentaire sera utile pour répondre aux demandes de la communauté. Sinon la partie P2 pourrait ne commencer qu’un trimestre plus tard. Cette personne sera listée dans l’équipe de développement ci-dessus.

<span id="_Task_P1.14:_Create_new_types">

Tâche P1.14 : création de nouveaux types

Nous permettons la création de nouveaux types. Cela signifie que nous devrions être en mesure d'éditer et de créer de nouvelles définitions de type, et d'internaliser tout le code pour gérer les valeurs d'un type au sein de Wikifunctions. C'est-à-dire que nous aurons besoin de code pour valider les valeurs, les construire, les visualiser dans plusieurs environnements, etc. Nous devrions également les internaliser pour tous les types existants.

<span id="_Task_P1.15:_Lua-based_implementations">

Tâche P1.15 : mises en œuvre basées sur Lua

Nous ajoutons Lua comme langage de programmation pris en charge pour les implémentations. L'importance de Lua est due à sa large utilisation dans les projets MediaWiki. De plus, si ce n'est pas déjà fait, la transformation des valeurs des wikifonctions en langage de programmation devrait être internalisée à ce stade (et également réalisée pour les implémentations JavaScript, qui utiliseront probablement des modules intégrés à ce stade).

<span id="_Task_P1.16:_Non-functional_interfaces">

Tâche P1.16 : interfaces non-fonctionnelles

Alors que Wikifunctions est construit sur des implémentations purement fonctionnelles, il existe certaines interfaces qui ne sont naïvement pas fonctionnelles, par exemple les nombres aléatoires, l'heure actuelle, les auto-incréments, ou de nombreux appels REST. Nous verrons comment les intégrer à Wikifonctions.

<span id="_Task_P1.17:_REST_calls">

Tâche P1.17 : appels d’interfaces REST

Nous fournirons des modules intégrés pour appeler des interfaces REST sur le Web et ingérer le résultat. Cela s'appuierait de préférence sur P1.16. Notez que l'appel à des interfaces REST arbitraires pose des problèmes de sécurité. Ceux-ci doivent être pris en compte dans une conception appropriée.

<span id="_Task_P1.18:_Accessing_Wikidata_and_other_WMF_projects">

Tâche P1.18 : accès à Wikidata et aux autres projets de la Fondation Wikimedia

Nous fournirons des fonctions permettant d'accéder aux articles et aux lexèmes de Wikidata, ainsi qu'à d'autres contenus des projets Wikimedia. Ceci s'appuiera de préférence sur P1.17, mais au cas où cela n'aurait pas encore réussi à ce stade, un intégré débloquera cette capacité.

<span id="_Task_P1.19:_Monolingual_generation">

Tâche P1.19 : génération monolingue

Le développement de ces fonctions se fait entièrement sur wiki. Cela inclut des tables et des enregistrements pour représenter les entités grammaticales telles que les noms, les verbes, phrases nominales, etc., ainsi que des fonctions pour travailler avec elles. Cela inclut l'implémentation du contexte afin que nous puissions générer des anaphores selon les besoins. Cela permet une génération concrète du langage naturel, c'est-à-dire pas encore abstrait.

<span id="_Part_P2:_Abstract_Wikipedia">

Partie P2 : Wikipédia abstraite

Les tâches de cette partie commenceront après un an de développement. Toutes les tâches de la partie P1 ne sont pas sensées être terminées avant le début de la partie P2 car, en fait, les parties P1 et P2 continueront à être développées en parallèle. Seules certaines des tâches de la partie P1 sont nécessaires au démarrage de la partie P2.

<span id="_Task_P2.1:_Constructors_and_Renderers">

Tâche P2.1 : constructeurs et moteurs de rendu

Ici nous introduisons les interfaces abstraites vers les générateurs concrets développés dans la tâche P1.19. Ceci nous conduit au développement initial des Constructeurs et de la fonction Rendu. Après cette tâche, la communauté devrait être en mesure de créer de nouveaux Constructeurs et d’étendre les Moteurs de rendu pour les prendre en charge.

  • Les Constructeurs sont utilisés pour la notation du contenu abstrait. Les Constructeurs sont indépendants de la langue et ne devraient contenir aucune logique conditionnelle.
  • Les Moteurs de rendu devraient détenir la logique conditionnelle effective (qui s’applique aux informations données aux constructeurs). Les rendus peuvent être définis selon la langue (mais peuvent également être partagés entre diverses langues).
  • La séparation entre les deux est analogue à la séparation dans d’autres systèmes de génération en langue naturelle, tel que Grammatical Framework.

<span id="_Task_P2.2:_Conditional_rendering">

Tâche P2.2 : rendu conditionnel

It will rarely be the case that a Renderer will be able to render the Content fully. We will need to support graceful degradation: if some Content fails to render, but other still renders, we should show that part that rendered. But sometimes it is narratively necessary to render certain Content only if other Content will definitely be rendered. In this task we will implement the support for such conditional rendering, that will allow smaller communities to grow their Wikipedias safely.

<span id="_Task_P2.3:_Abstract_Wikipedia">

Tâche P2.3 : Wikipédia abstraite

Create a new namespace in Wikidata and allow Content to be created and maintained there. Reuse UI elements and adapt them for Content creation. The UI work will be preceded by Design research work which can start prior to the launch of Part P2. Some important thoughts on this design are here. This task will also decide whether we need new magic words (F5, F6, and F7) or can avoid their introduction.

<span id="_Task_P2.4:_Mobile_UI">

Tâche P2.4 : interface utilisateur pour mobiles

The creation and editing of the Content will be the most frequent task in the creation of a multilingual Wikipedia. Therefore we want to ensure that this task has a pleasant and accessible user experience. We want to dedicate an explicit task to support the creation and maintenance of Content in a mobile interface. The assumption is that we can create an interface that allows for a better experience than editing wikitext.

<span id="_Task_P2.5:_Integrate_content_into_the_Wikipedias">

Tâche P2.5 : intégration de contenus vers les éditions locales de Wikipédia

Enable the Abstract Wikipedia magic word. Then allow for the explicit article creation, and finally the implicit article creation (F1, F2, F3, F4, F5, F6).

<span id="_Task_P2.6:_Regular_inflection">

Tâche P2.6 : inflexions régulières

Wikidata’s Lexemes contain the inflected Forms of a Lexeme. These Forms are often regular. We will create a solution that generates regular inflections through Wikifunctions and will discuss with the community how to integrate that with the existing Lexemes.

<span id="_Task_P2.7:_Basic_Renderer_for_English">

Tâche P2.7 : rendu basique en anglais

We assume that the initial creation of Renderers will be difficult. Given the status of English as a widely used language in the community, we will use English as a first language to demonstrate the creation of a Renderer, and document it well. We will integrate the help from the community. This also includes functionality to show references.

<span id="_Task_P2.8:_Basic_Renderer_for_a_second_language">

Tâche P2.8 : rendu basique dans une seconde langue

Based on the community feedback, interests, and expertise of the linguists working on the team, we will select a second large language for which we will create the basic Renderer together with the community. It would be interesting to choose a language where the community on the local Wikipedia has already confirmed their interest to integrate Abstract Wikipedia.

<span id="_Task_P2.9:_Renderer_for_a_language_from_another_family">

Tâche P2.9 : rendu basique dans une langue d’une autre famille

Since it is likely that the language in P2.8 will be an Indo-European language, we will also create a basic Renderer together with the community for a language from a different language family. The choice of this language will be done based on the expertise available to the team and the interests of the community. It would be interesting to choose a language where the community on the local Wikipedia has already confirmed their interest to integrate Abstract Wikipedia.

<span id="_Task_P2.10:_Renderer_for_an_underserved_language">

Tâche P2.10 : rendu dans une langue moins favorisée

Since it is likely that the languages in P2.8 and P2.9 will be languages which are already well-served with active and large Wikipedia communities, we will also select an underserved language, a language that currently has a large number of potential readers but only a small community and little content. The choice of this language will be done based on the expertise available to the team and the interests of the community. Here it is crucial to select a language where the community on the local Wikipedia has already committed their support to integrate Abstract Wikipedia.

<span id="_Task_P2.11:_Abstract_Wikidata_Descriptions">

Tâche P2.11 : descriptions Wikidata abstraites

Wikidata Descriptions seem particularly amenable to be created through Wikifunctions. They are often just short noun phrases. In this task we support the storage and maintenance of Abstract Descriptions in Wikidata, and their generation for Wikidata. We also should ensure that the result of this leads to unique combinations of labels and descriptions.

See Abstract Wikipedia/Updates/2021-07-29 for further details and discussion.

<span id="_Task_P2.12:_Abstract_Glosses">

Tâche P2.12 : gloses abstraites

Wikidata Lexemes have Senses. Senses are captured by Glosses. Glosses are available per language, which means that they are usually only available in a few languages. In order to support a truly multilingual dictionary, we are suggesting to create Abstract Glosses. Although this sounds like it should be much easier than creating full fledged Wikipedia articles, we think that this might be a much harder task due to the nature of Glosses.

<span id="_Task_P2.13:_Support_more_natural_languages">

Tâche P2.13 : prise en charge de plus de langues humaines

Support other language communities in the creation of Renderers, with a focus on underserved languages.

<span id="_Task_P2.14:_Template-generated_content">

Tâche P2.14 : contenu généré par modèle

Some Wikipedias currently contain a lot of template-generated content. Identify this content and discuss with the local Wikipedias whether they want to replace it with a solution based on Wikifunctions, where the template is in Wikifunctions and the content given in the local Wikipedia or in Abstract Wikipedia. This will lead to more sustainable and maintainable solutions that do not require to rely on a single contributor. Note that this does not have to be multilingual, and might be much simpler than going through full abstraction.

<span id="_Task_P2.15:_Casual_comments">

Tâche P2.15 : commentaires des cas d’utilisation

Allow casual contributors to make comments on the rendered text and create mechanisms to capture those comments and funnel them back to a triage mechanism that allows to direct them to either the content or the renderers. It is important to not lose comments by casual contributors. Ideally, we would allow them to explicitly overwrite a part of the rendered output and consider this a change request, and then we will have more involved contributors working on transforming the intent of the casual contributor to the corresponding changes in the system.

<span id="_Task_P2.16:_Quick_article_name_generation">

Tâche P2.16 : génération rapide de nom d’article

The general public comes to Wikipedia mostly by typing the names of the things they are looking for in their language into common search engines. This means that Wikidata items will need labels translated into a language in order to be able to use implicit article creation. This can probably be achieved by translating millions of Wikidata labels. Sometimes it can be done by bots or AI, but this is not totally reliable and scalable, so it has to involve humans.

The current tools for massive crowd-sourced translation of Wikidata labels are not up to the task. There are two main ways to do it: editing labels in Wikidata itself, which is fine for adding maybe a dozen of labels, but quickly gets tiring, and using Tabernacle, which appears to be more oriented at massive batch translations, but is too complicated to actually use for most people.

Cette tâche consiste à développer un outil de traduction d'étiquettes massif et intégré avec une interface simple et moderne, qui peut être utilisée par de nombreuses personnes.

<span id="_Non-core_tasks">

Tâches non essentielles

Voici une liste entière de tâches avancées facultatives. Idéalement, celles-ci pourraient être menées par des communautés externes et développées en code source ouvert hors de l’équipe initiale de développement, mais certaines d’entre elles pourraient avoir besoin d’être commencées ou même développées entièrement par l’équipe principale.

<span id="_Task_O1:_Lambda_calculus">

Tâche O1 : lambda-calcul

It is possible to entirely self-host Wikifunctions without relying on builtins or implementations in other programming languages, by implementing a Lambda calculus in Wikifunctions (this is where the name proposal comes from). This can be helpful to allow evaluation without any language support, and so easier start up the development of evaluators.

<span id="_Task_O2:_CLI_in_a_terminal">

Tâche O2 : interface en ligne de commande (CLI) dans un terminal

Many developers enjoy using a command line interface to access a system such as Wikifunctions. We should provide one, with the usual features such as autocompletion, history, shell integration, etc.

<span id="_Task_O3:_UIs_for_creating,_debugging_and_tracing_functions">

Tâche O3 : interfaces utilisateur (UIs) pour créer, déboguer et tracer les fonctions

Wikifunctions’s goal is to allow the quick understanding and development of the functions in Wikifunctions. Given the functional approach, it should be possible to create a user experience that allows for partial evaluation, unfolding, debugging, and tracing of a function call.

<span id="_Task_O4:_Improve_evaluator_efficiency">

Tâche O4 : amélioration de l’efficacité de l’évaluateur

There are many ways to improve the efficiency of evaluators, and thus reduce usage of resources, particularly caching, or the proper selection of an evaluation strategy. We should spend some time on doing so for evaluators in general and note down the results, so that different evaluators can use this knowledge, but also make sure that the evaluators maintained by the core team use most of the best practises.

<span id="_Task_O5:_Web_of_Trust_for_implementations">

Tâche O5 : réseau de confiance (Web of Trust) pour les mises en œuvre

In order to relax the conditions for implementations in programming languages, we could introduce a Web of Trust based solution, that allows contributors to review existing implementations and mark their approval explicitly, and also to mark other contributors as trustworthy. Then these approvals could be taken into account when choosing or preparing an evaluation strategy.

<span id="_Task_O6:_Python-based_implementations">

Tâche O6 : mises en œuvre basées sur Python

Python is a widely used programming language, particularly for learners and in some domains such as machine learning. Supporting Python can open a rich ecosystem to Wikifunctions.

<span id="_Task_O7:_Implementations_in_other_languages">

Tâche O7 : mises en œuvre dans d’autres langages

We will make an effort to call out to other programming language communities to integrate them into Wikifunctions, and support them. Candidates for implementations are Web Assembler, PHP, Rust, C/C++, R, Swift, Go, and others, but it depends on the interest of the core team and the external communities to create and support these interfaces.

<span id="_Task_O8:_Web-based_REPL">

Tâche O8 : environnement d’évaluation interactive (REPL) basé sur le web

A web-based REPL can bring the advantages of the O2 command line interface to the Web, without requiring to install a CLI in a local environment, which is sometimes not possible.

<span id="_Task_O9:_Extend_API_with_Parser_and_Linearizer">

Tâche O9 : extension de l’API avec un analyseur et linéarisateur

There might be different parsers and linearizers using Wikifunctions. The Wikifunctions API can be easier to use if the caller could explicitly select these, instead of wrapping them manually, which would allow the usage of Wikifunctions with different surface dialects.

<span id="_Task_O10:_Support_talk_pages">

Tâche O10 : prise en charge de pages de discussions

In order to support discussions on talk pages of Wikifunctions, develop and integrate a mechanism that allows for (initially) simple discussions, and slowly raising their complexity based on the need of the communities.

<span id="_Task_O11:_Legal_text_creation">

Tâche O11 : création de textes juridiques

An interesting application of Wikifunctions is for the creation of legal text in a modular manner and with different levels (legalese vs human-readable), similar to the different levels of description for the different Creative Commons licenses.

<span id="_Task_O12:_Health_related_text_creation">

Tâche O12 : création de textes relatifs à la santé

An interesting application of Wikifunctions is for the creation of health-related texts for different reading levels. This should be driven by WikiProject Medicine and their successful work, which could reach many more people through cooperation with Wikifunctions.

<span id="_Task_O13:_NPM_library">

Tâche O13 : bibliothèque NPM pour Javascript

We will create a Wikidata library for NPM that allows the simple usage of Functions from Wikifunctions in a JavaScript program. The same syntax should be used to allow JavaScript implementations in Wikifunctions to access other Wikifunctions functions. Note that this can be done by virtue of calling to a Wikifunctions evaluator, or by compiling the required functions into the given code base.

<span id="_Task_O14:_Python_library">

Tâche O14 : bibliothèque Python

We will create a Python library that allows the simple usage of Functions from Wikifunctions in a Python script. The same syntax should be used to allow Python implementations in Wikifunctions to access other Wikifunctions functions. Note that this can be done by virtue of calling to a Wikifunctions evaluator, or by compiling the required functions into the given code base.

<span id="_Task_O15:_Libraries_for_other_programming_languages">

Tâche O15 : bibliothèques pour d’autres langages de programmation

We will call out to the communities of several programming languages to help us with the creation of libraries that allow the simple call of Wikifunctions functions from programs in their language. Note that this can be done by virtue of calling to a Wikifunctions evaluator, or by compiling the required functions into the given code base.

<span id="_Task_O16:_Browser-based_evaluator">

Tâche O16 : évaluateur basé sur le navigateur

One of the advantages of Wikidata is that the actual evaluation of a function call can happen in different evaluators. The main evaluator for Abstract Wikipedia will be server-based and run by the Wikimedia Foundation, but in order to reduce the compute load, we should also provide evaluators running in the user’s client (probably in a Worker thread).

<span id="_Task_O17:_Jupyter-_and/or_PAWS-based_evaluator">

Tâche O17 : évaluateur basé sur Jupyter ou PAWS

One interesting evaluator is from a Jupyter or PAWS notebook, and thus allowing the usual advantages of such notebooks but integrating also the benefits from Wikifunctions.

<span id="_Task_O18:_App-based_evaluator">

Tâche O18 : évaluateur basé sur une application native

One evaluator should be running natively on Android or iOS devices, and thus allow the user to use the considerable computing power in their hand.

<span id="_Task_O19:_P2P-based_evaluator">

Tâche O19 : évaluateur distribué (en pair-à-pair)

Many of the evaluators could be linking together and allow each other to use dormant compute resources in their network. This may or may not require shields between the participating nodes that ensure the privacy of individual computes.

<span id="_Task_O20:_Cloud-based_evaluator">

Tâche O20 : évaluateur hébergé sur un serveur tiers (cloud)

One obvious place to get compute resources is by allowing to use a cloud provider. Whereas it would be possible to simply run the server-based evaluator on a cloud-based infrastructure, it is likely to be beneficial for the cloud providers to provide a thinner interface to a more custom-tailored evaluator.

<span id="_Task_O21:_Stream_type">

Tâche O21 : type de données pour flux diffusé (stream)

Add support for a type for streaming data, both as an input as well as an output. Stream types means for example the recent changes stream on a Wikimedia wiki.

<span id="_Task_O22:_Binary_type">

Tâche O22 : type de données binaires

Ajout de la prise en charge des fichiers binaires, tant en entrée qu'en sortie.

<span id="_Task_O23:_Integration_with_Commons_media_files">

Tâche O23 : intégration avec les fichiers média de Wikimedia Commons

Allow direct access to files on Commons. Enable workflows with Commons that require less deployment machinery than currently needed. Requires O22.

<span id="_Task_O24:_Integrate_with_Machine_Learning">

Tâche O24 : intégration avec l’apprentissage par la machine

Develop a few example integrations with Machine Learning solutions, e.g. for NLP tasks or for work on image or video e.g. using classifiers. This requires how and where to store models, possibly also how to train them, and how to access them.

<span id="_Task_O25:_Integrate_into_IDEs">

Tâche O25 : intégration dans les environnements interactifs de développement (IDEs)

Reach out to communities developing IDEs and support them in integrating with Wikifunctions, using type hints, documentation, completion, and many of the other convenient and crucial features of modern IDEs.

<span id="_Task_O26:_Create_simple_apps_or_Websites">

Tâche O26 : création d’applications ou de sites web simples

Develop a system to allow the easy creation and deployment of apps or Websites relying on Wikifunctions.

<span id="_Task_O27:_Display_open_tasks_for_contributors">

Tâche O27 : affichage des tâches ouvertes aux contributeurs

Abstract Wikipedia will require one Renderer for every Constructor for every language. It will be helpful if contributors could get some guidance to which Renderer to implement next, as this is often not trivially visible. Just counting how often a Constructor appears could be a first approximation, but if some Constructors are used more often in the lead, or in parts of the text that block other text from appearing, or in articles that are more read than others, this approximation might be off. In this task we create a form of dashboard that allows users to choose a language (and maybe a domain, such as sports, geography, history, etc., and maybe a filter for the complexity of the renderer that is expected) and then provide them with a list of unrendered Constructors ranked by the impact an implementation would have.

We could also allow contributors to sign up for a regular message telling them how much impact (in terms of views and created content) they had, based on the same framework needed for the dashboard.

This is comparable to seeing the status of translations of different projects on TranslateWiki.Net (for a selectable language), or the views on topics, organizations or authors in Scholia. For each project, it shows what % of the strings in it were translated and what % need update, and a volunteer translator can choose: get something from 98% to 100%, get something from 40% to 60%, get something from 0% to 10%, etc.

<span id="_Task_O28:_Active_view">

Tâche O28 : vue des activités

Whereas the default view of Rendered content would look much like static text, there should also be a more active view that invites contribution, based on existing Content that failed to render due to missing Renderers. In the simplest case this can be the creation of a Lexeme in Wikidata and connecting to the right Lexeme. In more complex cases that could be writing a Renderer, or offering example sentences as text, maybe using the Casual contribution path described in P2.15. This would provide an interesting funnel to turn more readers in contributors.

There are product and design decisions on how and where the active view should be used and whether it should be the default view, or whether it should be only switched on after an invitation, etc. There could also be mode where contributors can go from article to article and fill out missing pieces, similar to the more abstract way in O27.

It would probably be really useful that ensure that the active way and the contribution path it leads to work on mobile devices as well.

<span id="_Task_O29:_Implementation_compilation">

Tâche O29 : compilation des mises en œuvre

The function composition used for implementations should allow to create highly performant compilations of rather high-level functions in many different target programming languages, particularly Web Assembler and JavaScript. This should speed up evaluation by several orders of magnitude.

<span id="_Task_O30:_Integrate_with_Code_examples_on_Wikipedia,_Wikibooks,_etc.">

Tâche O30 : intégration avec des exemples de code sur Wikipédia, Wikibooks, etc.

Permettre à Wikipédia, à Wikilivres et aux autres projets d’intégrer leurs exemples de code directement dans le wiki des fonctions, afin que ceux-ci puissent s’exécuter en direct.


Phases de mise en œuvre

Le développement de la Wikipédia abstraite se déroulera en deux parties majeures, qui comprennent chacune un grand nombre de tâches. La première partie concerne le développement du wiki des fonctions, la seconde concerne le contenu abstrait et la génération en langue humaine. Sur cette page, nous redécoupons le début de la première partie en phases. Les phases sont reflétées dans Phabricator et liées depuis cette page, de même que les tâches et redécoupages des tâches.

Cette page pourrait rester inactive. L’emplacement canonique des informations concernant les tâches peut être trouvé dans Phabricator. Consultez l’état actuel dans Phabricator.

Nous nous attendons à environ dix phases avant le lancement du wiki des fonctions.

Toutes les tâches ci-dessous appartiennent à la tâche P1.2 : développement initial, sauf mention contraire.


Partie P1 : le wiki des fonctions

Article principal: Wikipédia abstraite/Tâches — § Partie P1 : Wikifonctions

Phase α (alpha) : stocker, afficher et modifier l’entête —   Terminé 2020-08-25

  1. Mise en place de l’environnement de développement réplicable. — tâche T258893
    •   Terminé Commencement de l’extension. — tâche T258893
    •   Terminé Travaux de configuration, téléversement du contenu de démarrage initial.
    •   Terminé Réutilisation du Gestionnaire de contenu JSON existant. — tâche T258893
    •   Terminé Permettre d’entrer des objets JSON par l’interface de modification brute. — tâche T258893
  2.   Terminé Extension et codage en dur des objets JSON pour vérifier qu’un Z-Objet est bien formé. Rien de ce qui n’est pas bien formé ne devrait être traité ou stocké. La forme correcte devrait probablement être vérifiée à la fois dans le code PHP et le code JavaScript (ce devrait de toute façon être facile à écrire).
    •   Terminé en PHP. — tâche T258894
    • Forme correcte : la syntaxe des clés, les clés autorisées, les valeurs sont des chaînes ou des proto-objets ou des listes de valeurs. — tâche T258894
  3.   Terminé Chaque Z-Objet de premier niveau stocké doit être un Z2/Objet persistant. — tâche T258897
  4.   Terminé Créer Z1/Objet, offrir une clé, Z1K1/type.
  5.   Terminé Étendre le validateur codé en dur pour vérifier Z1K1/type.
  6.   Terminé Créer Z2/Objet persistant. — tâche T258897
  7.   Terminé Z2/Objet persistant a les clés Z2K1/ID, Z2K2/valeur et Z2K3/proto-libellé, ce dernier étant contrefait, juste une simple chaîne sans information de langue. — tâche T258897
  8.   Terminé Étendre le validateur codé en dur pour Z2/Objet persistant jusqu’ici. — tâche T258897
  9.   Terminé Fournir l’affichage codé en dur pour Z2/Objet persistant (c’est-à-dire l’entête) (c’est une tâche assez large). — tâche T258898
  10.   Terminé Fournir une vue générique pour l’objet Z2K2/valeur. — tâche T258898
  11.   Terminé Transformer le Z2K3/proto-libellé en un Z2K3/libellé approprié pour du texte multilingue.
  12.   Terminé Étendre la vue pour Z2K3/libellé avec du texte multilingue.

Condition d’achèvement de la phase : en tant qu’utilisateur d’[un site avec l’extension MediaWiki installée], je peux créer et stocker une chaîne comme un nouveau Z-Objet, p.ex. « Bonjour au monde ! ».

Phase β (bêta) : création des types et des instances —   Terminé 2021-02-04

  1.   Terminé Validateurs codés en dur pour les Z4/proto-types et Z3/proto-clés. — tâche T258900
    • Un Z4 a un champ Z4K2/clés avec une Liste JSON de Z3.
    • Une proto-clé a un Z3K1/ID avec Z3K2/type et Z3K3/libellé (recopier le développement du libellé pour Z2K3 ?).
  2.   Terminé Créer Z4/Type et Z3/Clé (Task P1.14).
  3.   Terminé Recherche des Z-Objets par libellé. — tâche T260750
  4.   Terminé pour cette phase. Utiliser les données de type Z4 et les déclarations de clés pour valider les objets. — tâche T260861
  5.   Terminé Utiliser les données de type Z4 et les déclarations de clés pour une vue générique des objets. — tâche T258901
  6.   Terminé Utiliser les données de type Z4 et les déclarations de clés pour la modification ou la création des objets. — tâche T258903 & tâche T258904
  7.   Terminé Fournir un affichage codé en dur et une interface de modification pour le type Z4. — tâche T258900

Condition d’achèvement de la phase : en tant qu’utilisateur, je peux créer et stocker un objet qui met en œuvre tout type défini sur le wiki, p.ex. l’entier positif un.

Phase γ (gamma) : fonctions, mises en œuvre, erreurs —   Terminé 2021-04-02

  1.   Terminé Introduire un objet simple d’erreur. — tâche T261464
  2.   Terminé Introduire une fonction simple. — tâche T258957
  3.   Terminé Introduire une mise en œuvre simple, pour le moment seulement intégrée. — tâche T258958
  4.   Terminé Créer quelques fonctions et mise en œuvre intégrées. — tâche T261474
  5.   Terminé Introduire un appel de fonction simple. — tâche T261467
  6.   Terminé Type de test (Tâche P1.10). — tâche T261465

Condition d’achèvement de la phase : en tant qu’utilisateur, je peux stocker un appel de fonction, une fonction et un testeur (seulement les objets, pas encore leur évaluation réelle), p.ex. si(vrai, faux, vrai) (lire « si vrai alors faux sinon vrai », c.-à-d. la négation).

Phase δ (delta) : mises en œuvre intégrées —   Terminé 2021-05-11

  1.   Terminé Système d’évaluation pour les mises en œuvre intégrées. — tâche T260321
  2.   Terminé Permettre aux utilisateurs web d’appeler l’évaluation par un module d’API (Tâche P1.5). — tâche T261475
  3.   Terminé Page spéciale pour appeler l’évaluation (Tâche P1.11). — tâche T261471

Condition d’achèvement de la phase : en tant qu'utilisateur, je peux utiliser une page spéciale pour évaluer une fonction intégrée avec des entrées fournies, p.ex. pour vérifier si la liste vide est vide.

Phase ε (epsilon) : appels de fonction natifs —   Terminé 2021-06-30

  1.   Terminé Mises en œuvre en JavaScript (Tâche P1.12). — tâche T275944
  2.   Terminé Mises en œuvre en Python (Tâche O6). — tâche T273517
  3.   Terminé Permettre aux formulaires d’être inclus pour l’évaluation. — tâche T261472

Condition d’achèvement de la phase : en tant qu’utilisateur, je peux utiliser une page spéciale pour évaluer une fonction écrite par l’utilisateur dans l’un des langages pris en charge, p.ex. appeler une fonction écrite par l’utilisateur en Python pour additionner deux nombres.

Phase ζ (zêta) : composition —   Terminé 2021-08-27

  1.   Terminé Permettre les mises en œuvre par composition (Tâche P1.6). — tâche T261468

Condition d’achèvement de la phase :

  • en tant qu’utilisateur, je peux mettre en œuvre une fonction qui utilise la composition d’autres fonctions au lieu de l’écrire moi-même, p.ex. négation(Booléen → Booléen) ; —   Terminé
  • (condition étendue) en tant qu’utilisateur, je peux voir les résultats des testeurs sur la page appropriée de mise en œuvre d’une fonction. [Ceci pourrait nécessiter d’être remis à une phase ultérieure car tous les pré-requis pourraient ne pas encore être remplis à ce point. Cela devra être fait pour la phase ι (iota).] —   Terminé

Phase η (êta) : types génériques —   Terminé 2022-04-08

  1.   Terminé Permettre les types génériques, particulièrement pour Z10/Liste ou Z8/Fonction, et remplacer Z10/Liste et Z8/Fonction. ― tâche T275941
  2.   Terminé Les erreurs peuvent être traitées en tant que Z-Objets.
  3.   Terminé Les types définis par l’utilisateur fonctionnent avec les validateurs.

Condition d’achèvement de la phase :

  • être capable de mettre en œuvre la curryfication comme une composition sur the wiki, mais sans nécessiter une analyse statique stricte ; —   Terminé
  • rendre possible la création des trois types « définis par l’utilisateur » sur le wiki : entier positif, signe et entier ; —   Terminé
  • être capable de créer un type emballeur générique au moyen de la composition sur le wiki. —   Terminé

Voir également le bulletin d’actualité publié au sujet de cette phase.

Phase θ (thêta) : gel et dégel —   Terminé 2023-06-19

  1.   Terminé Gel et dégel de contenu (Tâche P1.7). ― tâche T275942
  2.   Terminé Tâche P1.9 : passage en revue de la sécurité. — tâche T274682, …
  3.   Terminé Lancement du système public de test (Tâche P1.4). — tâche T261469

Condition d’achèvement de la phase :

  • en tant qu’administrateur, je peux geler et dégeler tout objet écrit par l’utilisateur (apparenté à, ou peut-être la même chose que le système de protection de MediaWiki) ; tous les objets fournis par le système sont gelés de façon permanente ;
  • en tant qu’utilisateur modifiant une page gelée, je peux changer le libellé, mais pas la mise en œuvre, alors que sur une page non gelée, les deux sont possibles ;
  • les ZObjets sont stockés en utilisant la nouvelle forme canonique pour les listes typées et toutes les parties fonctionnent encore ;
  • la visualisation et la modification de fonction est mise en œuvre et testée avec succès ;
  • quand plusieurs mises en œuvre sont disponibles, la « meilleure » est choisie (la détermination de l’adéquation sera potentiellement modifiée ultérieurement) ;
  • nous mesurons l’utilisation du temps d’horloge et de la mémoire à chaque exécution de fonction et l’affichons sur les résultats d’exécution et dans le tableau des mises en œuvre et des tests ;
  • les modifications de ZObjets définis par le système sont restreintes aux seuls utilisateurs ayant les droits corrects ; des différences compréhensibles sont émises ; les résultats sont mis en cache ;
  • le texte avec repli, les références, les chaînes et les listes sont mis en œuvre et testés avec succès ;
  • une compréhension partagée avec la communauté sur la façon dont l’équipe contribuera à Wikifonctions, et pourquoi, est documentée ;
  • les conceptions pour la visualisation et la modification de la documentation multilingue sur les appareils mobiles et de bureau est approuvée ; l’expérience utilisateur est instrumentée et les données collectées.

Phase ι (iota) : documentation des objets

  1. Ceci est une affectation préliminaire, déplaçant les tâches de documentation ici.
  2. Fournir la modification pour l’entête (en plus de la modification du code brut complet) (ceci est une tâche assez large) – ceci ne se réfère qu’aux libellés, en fait.
  3. Étendre la modification pour Z2K3/libellé avec du texte multilingue.
  4. Étendre l’entête avec Z2K4/documentation. — tâche T260954 & tâche T260956
  5. Étendre la modification pour s’occuper de la Z2K4/documentation. — tâche T260955

Condition d’achèvement de la phase : en tant qu’utilisateur, je peux documenter un Z-Objet dans n’importe lequel des langages de programmation pris en charge, en utilisant du wikitexte.

Phase κ (kappa) : nettoyage

  1. Affinage et nettoyage des tâches, pour clôturer toutes les tâches de prélancement.

Condition d’achèvement de la phase : au sein de l’Équipe de la Wikipédia abstraite, nous nous sentons prêt au lancement, y compris avec l’approbation de tous les collègues concernés.

Phase λ (lambda) : lancement

  1. La phase λ (lambda) est destinée au lancement. S’il y a des tâches préalables au lancement qui empêche de le faire, il faudra que ce soit fait, évidemment.
  2. Mettre en place un nouveau projet Wikimédia.
  3. Déplacer certaines pages wiki de Méta-Wiki à Wikifunctions.

Condition d’achèvement de la phase : en tant que personne sur le Web, je peux visiter et utiliser Wikifunctions.org pour écrire et exécuter des fonctions directement sur le site.

Tâches hors phases

Les tâches préalables au lancement qui doivent arriver mais qui ne sont pas encore planifiées en phases :

Tâches postérieures au lancement de la première partie

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Abstract_Wikipedia/Plan/fr&oldid=21266374"