Dans cette édition du bulletin hebdomadaire, je veux discuter des différents endroits où nous utiliserons du texte déstructuré dans les objets du wiki des fonctions.
Ce qui suit est un plan et un appel à commentaires. Au delà des libellés, rien n’est encore en œuvre, aussi nous apprécierions réellement vos avis.
Libellés.
Chaque objet dans le wiki des fonctions sera identifié par un Z-ID, similaire aux Q-ID qui identifient les éléments dans Wikidata. Mais comme les Q-ID, nous ne nous attendons pas à rendre les Z-ID largement visibles et utilisés. À la place, chaque objet aura des libellés, un par langue.
Mais au contraire des éléments de Wikidata, chaque objet sera une instance d’un type spécifique. Par exemple, il pourrait exister un objet qui représente la somme de deux nombres entiers. Donc le libellé pour cet objet serait “add” en anglais, ou « ajouter » en français. D’autres bon libellés pour cet objet pourraient être « addition », « somme » ou « plus ». Un nom inapproprié pour la fonction serait « multiplication », ce qui serait une terrible source de confusion.
Unicité.
Il y aura probablement d’autres objets pour représenter des fonctions qui effectuent des additions, par exemple l’addition de deux nombres réels non entiers, de deux nombres complexes ou de deux matrices.
Dans le wiki des fonctions, les libellés n’auront pas besoin d’être unique en général ― mais ils devront être uniques pour chaque type. Ainsi il ne pourra y avoir qu’une seule fonction avec le libellé « ajouter » qui prend deux entiers et retourne un entier. Ou qu’un seul type avec le libellé « entier ». Pour chaque type, chaque libellé doit être unique.
Maintenant, est-ce que tout objet nécessite un libellé ? Non. Il y aura de nombreux objets où un libellé ne sera pas strictement nécessaire.
Chacun des tests pour une fonction n’aura pas besoin d’un libellé, ni chacune des mises en œuvre d’une fonction. Ils pourront avoir des libellés, mais il ne seront pas nécessaires ― c’est une autre différence avec Wikidata, où les éléments sans libellés sont presque toujours problématiques.
Une note supplémentaire concernant les libellés ― les libellés n’ont pas à être des traductions directes entre les langues.
Ainsi si dans une langue, deux fonctions pourraient avoir le même libellé si elles sont de types différents, mais dans une autre les deux fonctions pourraient également avoir des libellés différents.
Par exemple, en anglais “length” pourrait être un libellé approprié pour une fonction qui retourne le nombre d’éléments dans une liste, mais aussi pour une fonction qui retourne la longueur d’un cours d’eau, ou encore une fonction qui retourne la durée d’un film.
En croate cependant, les trois fonctions pourraient avoir des noms différents (“broj elemenata”, “duljina”, “trajanje”).
Chaque langue peut décider quel motif leur convient le mieux. Que ce soit des verbes en forme impérative (« ajoute ») ou infinitive (« ajouter »), une description du résultat (« somme ») ou le nom de l’opération (« addition ») qui fonctionne le mieux peut être décidé d’une langue à l’autre et des guides de style indépendants pour chaque langue peuvent évoluer.
Synonymes (alias).
À côté des libellés, chaque objet peut avoir des synonymes ou alias pour chaque langue. Les synonymes ou alias sont utiles pour rechercher un objet.
La fonction ci-dessous, libellée “add” en anglais ou « ajoute » en français, pourrait avoir tous les autres noms alternatifs donnés ci-dessus ― « ajouter », « somme », « plus », « addition » ― définis comme synonymes ou alias, afin que quelqu’un recherchant une fonction par un nom différents puisse trouver la fonction correcte dans un des résultats.
Documentation.
Chaque objet peut également avoir une documentation dans chaque langue. La documentation est un wikitexte qui décrit plus complètement l’objet donné. Nombre d’objets n’auront pas de documentation du tout, mais de nombreux autres en auront un peu.
Si vous avez déjà eu l’opportunité de lire en anglais The Art of Computer Programming (L’Art de la programmation), vous savez qu’il y a souvent beaucoup à dire concernant une fonction !
Mais au delà de ce genre d’histoire de fond, nous pouvons avoir quelque documentation qui décrit une mise en œuvre donnée, ou quelques explications sur les raisons de l’utilité d’un test donné.
Cela pourrait aussi être un lien vers une tâche de Phabricator qui décrit une erreur qui s’y est produite auparavant et que ce test va vérifier afin de la détecter avant qu’elle survienne à nouveau, ou bien un lien vers d’autres ressources comme un manuel sur les algorithmes.
Clés et arguments.
Au moins les types et les fonctions auront des libellés pour chaque clé de type et chaque argument de la fonction. Cela sera utilisé pour créer l’interface utilisateur permettant d’afficher et modifier les valeurs et appels de fonctions.
Courtes descriptions.
Une question spécifique que nous avons ― devrons nous avoir une courte description pour chaque objet ?
De nombreux ateliers logiciels et parfois même le langage de programmation (pensez aux docstrings de Python) prennent en charge de courtes lignes qui donnent un peu d’informations supplémentaires pour une fonction, au delà de simplement le nom de la fonction ou des arguments et de leurs types.
Nous allons avoir un système de typage fort et disposerons de plein d’espace pour la documentation.
Ainsi avons nous réellement besoin d’un lieu pour les descriptions courtes ? Quel serait leur cas d’utilisation ? Comment seraient-elles utilisées dans l’interface utilisateur ?
Sur le site web, quelque chose de similaire aux panneaux surgissant de prévisualisation sur Wikipédia semble être plus utile qu’un texte court, pour prévisualiser la documentation entière.
À l’origine j’ai supposé par défaut que nous aurons des descriptions courtes, étant donné leur importance et utilité dans Wikidata, c’est pourquoi elles figurent dans les fonctionnalités du prototype TexteAbstrait. Mais elles n’était jamais utiles à cet endroit.
De plus, le typage a pris le rôle de désambiguïseur, comme décrit ci-dessus, aussi il n’y avait pas de réel besoin technique pour une description courte.
Le penche actuellement pour ne pas les avoir, mais j’aimerais entendre plus d’avis à ce sujet
La bonne chose est qu’aucune décision ne sera gravé dans la pierre. Le modèle du wiki des fonctions sera bien plus flexible que le modèle des données de Wikidata, et si nous réalisons que nous avons réellement besoin des descriptions courtes, nous pouvons les introduire plus tard.
Il est en revanche plus dur de retirer des choses, car presque tout ce qui est présent sera utilisé d’une façon ou d’une autre, aussi je suis plus prudent avant d’introduire des fonctionnalités sans une bonne raison.
Utilisation par nous-même.
Une question évidente est : hé, vous développez cette architecture pour créer un contenu multilingue, pourquoi alors avoir toute cette documentation et ces libellés dans des langues réelles, pourquoi ne pas utiliser nos propres fonctions pour construire tout ça ?
Et oui, nous sommes d’accord, ce serait le mieux. C’est juste que nous n’en sommes pas encore là et, en attendant mieux, nous aurons encore besoin des libellés, des synonymes ou alias et de la documentation.
Aussi éventuellement, je suivrais bien le moyen d’utiliser le contenu abstrait afin de décrire les objets eux-mêmes du wiki des fonctions.
Il sera également intéressant de voir si nous pouvons annuler une partie du contenu local, et comment nous serons ouverts à agir ainsi ― comme cela nous donnera une vue très intéressante sur la façon d’approcher des objectifs similaires dans les autres projets Wikimedia, depuis des descriptions (et peut-être même les libellés ? ou même les glosses sémantiques ?) pour ébaucher des articles de Wikipédia.
Il y aura un gros potentiel pour rendre notre contenu au travers des projets plus facile à maintenir et pour fournir une couverture de base plus uniforme entre les différentes langues.
Nouvelle vidéo de présentation de la Wikipédia abstraite.
Le second tour de vote pour le nom du nouveau wiki des fonctions est initialement prévu pour la semaine prochaine, le mardi 27 octobre.
Les propositions sont actuellement examinées au plan juridique et nous devrions savoir bientôt quels noms figureront dans le dernier tour.
Alors que des révisions plus avancées des candidats sélectionnés sont nécessaires, de même que quelques tests supplémentaires pour déployer un nouveau gadget interactif de vote, le scrutin ouvrira finalement le mardi 2 novembre pendant deux semaines.
Actualités de la Wikipédia abstraite 
