Wikifunctions:Status-Updates/2024-02-07

Wikifunctions Status-Updates

Vierteljährliche Planung

Vor zwei Wochen haben wir ein internes Planungstreffen abgehalten, um zu skizzieren, woran wir im laufenden Quartal arbeiten wollen. Letzte Woche haben wir die Ergebnisse gesammelt und aufgeschrieben, und wir möchten diese Ergebnisse mit euch teilen.

Das übergeordnete Ziel unseres Teams besteht darin, darauf hinzuarbeiten, die für die Abstrakte Wikipedia benötigten Teile zu unterstützen.

Typunterstützung für einen Wikidata-Prototyp. Wir möchten Wikifunctions weitere Typen hinzufügen, insbesondere mit Blick auf die Typen, die benötigt werden, um Formen aus lexikografischen Daten in Wikidata integrieren zu können. Dazu wollen wir an Serialisierern und Deserialisierern, Renderern und Parsern sowie Validatoren arbeiten. Die Typen, die wir voraussichtlich aktivieren werden, sind neben den kürzlich aktivierten Listen Zahlen, Aufzählungen (z. B. für grammatikalische Funktionen) und Lexeme. Wir werden mit der Community an der genauen Liste der zu unterstützenden Typen arbeiten, hoffen aber, dass am Ende alle Typen vorhanden sind, damit wir im nächsten Quartal auf den Zugriff auf Lexeme aus Wikidata hinarbeiten können.
Öffentliche API für Wikifunctions. Wir möchten die Erstellung von Drittanbieter-Apps mit Funktionen aus Wikifunctions fördern, beispielsweise die Integration mit Lucas Werkmeisters Wikidata Lexeme Forms, das derzeit eine interne API verwendet. Der erste Schritt besteht darin, die API zu entwerfen und über unseren Ansatz zu entscheiden.
Vereinfachen unserer Ende-zu-Ende-Tests und verbessern der Zuverlässigkeit. Unser Stack ist im Vergleich zu anderen Systemen bei Wikimedia etwas kompliziert, da er im Backend einen Auswerter und Orchestrierer-Dienste sowie das Wiki selbst mit der Wikilambda-Erweiterung ausführt und sich auf bestimmte Inhalte im Wiki verlässt. Aus diesem Grund sind Teile unserer Testplattform mit kontinuierlicher Integration derzeit nicht in einem guten Zustand. Bei dieser Aufgabe geht es darum, diese Situation zu verbessern und unser Vertrauen in unsere Tests zu stärken.
Recherche zum Aufruf von Wikifunctions innerhalb von Wikipedia-Inhalten. Ein Hauptziel unseres Projekts ist es, der Wikipedia und anderen Wikimedia-Communities zu ermöglichen, Funktionen von Wikifunctions innerhalb von Wiki-Seiten aufzurufen, wie sie es mit Commons-Mediendateien oder lokalen Vorlagen und Lua-Skripten tun. Um uns darauf vorzubereiten, werden wir mit der Nutzerforschung beginnen, um ein besseres Verständnis der Nutzerbedürfnisse und -erwartungen zu erlangen.
Entwickeln eines grundlegendes Verständnisses unserer Benutzer und ihrer Motivationen. Um sicherzustellen, dass wir Wikifunctions benutzerorientiert entwickeln, möchten wir anhand der uns bisher vorliegenden Kennzahlen besser analysieren, wer unsere aktuellen Benutzer sind und warum sie hier sind.
Etablieren eines regelmäßigen Rhythmus der externen Kommunikation. Unser wöchentlicher Newsletter eignet sich gut für die Kommunikation mit unserer unmittelbaren Community, wir möchten aber auch ein breiteres Publikum erreichen. Dazu gehören regelmäßige Beiträge auf Diff.
Entwickeln eines Frameworks, um den narrativen Unterschied zwischen zwei Wikipedia-Artikeln in verschiedenen Sprachen zu messen. Dies ist eine Forschungsaufgabe, die uns auf den Weg bringen wird, zu verstehen, wie sich zwei Artikel in zwei verschiedenen Sprachen zum gleichen Thema unterscheiden. Ein solches Werkzeug würde uns dabei helfen, Leitlinien für das Wachstum der Abstrakten Wikipedia bereitzustellen, und könnte uns gleichzeitig möglicherweise ein Frühwarnsystem bieten, das auf einen Verlust an Vielfalt hinweisen könnte.

Da dies unsere erste Planung für einen solchen Rhythmus war, gehört dazu auch das Erlernen des richtigen Arbeitsumfangs. Am Ende des Quartals werden wir auf das tatsächlich Erreichte zurückblicken und daraus für das nächste Quartal lernen.

Danke, Quiddity!

Letzte Woche war Nick Wilsons letzter Tag im Team der Abstrakten Wikipedia, bevor er in eine wohlverdiente Pause geht. Einigen von euch dürfte Nick besser unter seinem Wikinym “Quiddity” bekannt sein. Nick war von Anfang an Teil des Projekts Abstrakte Wikipedia, hat den Namenswettbewerb für Wikifunctions ins Leben gerufen und organisiert und die meisten unserer Kommunikationsstrukturen aufgebaut.

Hier sind ein paar Worte von Nick als Abschiedsnachricht:

Danke euch allen!
Es war faszinierend, beeindruckend, motivierend und zutiefst inspirierend, Teil dieser komplexen Projekte zu sein. Ich habe es sehr geschätzt, so viele Aspekte unserer Bewegung und unserer Mission kennenzulernen (oder tiefer mit ihnen vertraut zu werden) und mehr von den Menschen kennenzulernen, die stetig dazu beitragen, dass alles vorankommt.

Wie immer wünschte ich, ich könnte mich selbst klonen, um mich neben der Arbeit in neuen Bereichen für immer auf dieses Projekt konzentrieren zu können. Ich freue mich sehr auf eine funktionsorientierte Zukunft und hoffe, dass ich nach einer kurzen Wiki-Pause weiterhin ehrenamtlich helfen kann.

Luca, der Anfang 2022 zu uns kam, wird weiterhin die Rolle des Community Relations Specialist für das Projekt ausüben und Nicks Aufgaben übernehmen. Bitte dankt gemeinsam mit mir Nick für seine Arbeit!

Letzte Änderungen an der Software

Wie oben besprochen, ist ein Teil unserer größeren Arbeit in diesem Quartal die Typunterstützung, die zur Wikidata-Unterstützung führt. Als Teil davon haben wir die Validierung für Typen repariert (T352295) und jetzt wieder aktiviert, was noch keine sichtbaren Auswirkungen haben sollte, aber die Möglichkeit freischaltet, dem Benutzer mitzuteilen, dass seine Eingabe falsch ist, wenn er versucht, einen Typ zu verwenden (beispielsweise kann man sagen, dass eine natürliche Zahl keine Nicht-Ziffern enthalten darf oder dass ein Datum im Februar nicht auf dem 30. Tag liegen darf).

Wir haben jetzt eine kleine Änderung an der Anzeige der von Funktionen zurückgegebenen Zeichenketten vorgenommen und sie in doppelte Anführungszeichen gesetzt, wodurch es möglich wird, "" und " " als unterschiedliche Antworten zu unterscheiden. Dadurch werden nicht alle Probleme mit Leerzeichen in Eingaben behoben, da es aufgrund der Natur von HTML schwierig ist, mit einigen möglichen Rückgabewerten auf eine skalierbare Weise umzugehen, die andere Anwendungsfälle nicht beeinträchtigt. Wir planen, mit weiteren Verbesserungen auf diesen Bereich zurückzukommen und würden uns über deine Meinung zu den Verbesserungen freuen, die du gerne sehen würdest.

Wir haben auch das Problem behoben, dass die Benutzeroberfläche bei Verwendung einer Sprache, die MediaWiki nicht unterstützt, wie z. B. https://www.wikifunctions.org/view/elx/Z10000, nicht mehr funktioniert – früher kam es zu einem fehlerhaften Zustand, aber jetzt funktioniert alles wie vorgesehen (T356428). Das bedeutet auch, dass, wenn du versuchst, eine Sprache zu verwenden, die Wikifunctions nicht kennt, wie etwa https://www.wikifunctions.org/view/hellothisisnotalanguage/Z10000, das System auf Englisch zurückgreift (wie der Rest von MediaWiki), anstatt auf mysteriöse Weise eine Mischung aus Englisch und größtenteils Fehlern bereitzustellen.

Zu den kleineren Änderungen gehört eine Fortsetzung der Änderung von letzter Woche, um die Noindex-Direktive von unseren Seiten zu entfernen, damit Google und andere Suchmaschinen sie sehen (phab:T355441). Neben den Hauptlinks wie https://wikifunctions.org/view/ar/Z801 haben wir noch einige URLs, die aufgrund der Art und Weise, wie MediaWiki Seiten verwaltet, ebenfalls funktionieren, beispielsweise …/wiki/Z801?uselang=ar oder …/wiki/Special:ViewObject/ar/Z801; diese erheben nun nicht mehr den Anspruch, "kanonisch" zu sein (T355546). Außerdem haben wir alle verlinkten Software-Hilfeseiten auf MediaWiki.org an die gleiche Stelle verschoben, in der Hierarchie "Hilfe:Wikifunctions". Wir haben auch eine Optimierung an der Benutzeroberfläche der Sprachauswahl auf einer Seite vorgenommen, wenn diese bereits über mehrere Übersetzungen verfügt – der Abstand passt jetzt zum Rest des Formulars und ist nicht viel breiter (T355946).

Wir haben außerdem zwei neue Sprachen hinzugefügt, die von MediaWiki unterstützt werden: Ebira (Z1920) und Petjo (Z1921). Diese werden manuell hinzugefügt.

Auf der Codeseite haben wir einige kleinere Verbesserungen an der Abdeckung der kritischen ZObjekt-Klassen durch unseren PHP-Code vorgenommen und nähern uns nun 100 % (T302599). Wir haben im Anschluss an frühere Arbeiten eine Reihe von Bereinigungen an unserem Front-End-Code vorgenommen, ungenutzte Komponenten entfernt (T301868) und allgemein unseren Datenspeichercode verbessert (T329107). Diese Woche ist eine Reparatur-Woche für das Team, daher werden wir weitere Verbesserungen dieser Art vornehmen, die nächste Woche mitgeteilt werden.

Funktion der Woche: ist Permutation

Für die aktuelle Funktion der Woche habe ich Nick nach einer Lieblingsfunktion gefragt und er hat sofort geantwortet, dass er Listen und das Ungewöhnliche liebt und deshalb gerne eine ungewöhnliche Funktion auswählen würde, die sich mit Listen befasst. Wenn wir uns den Katalog der Listenfunktionen ansehen, entsprachen die meisten davon dem, was man von Listenoperationen erwarten würde, aber eine davon kam uns in dem Sinne ungewöhnlich vor, dass die meisten Programmiersprachen diese Funktionalität standardmäßig nicht unterstützen würden: ist Permutation (korrigiere uns gerne, wenn wir falsch liegen).

Eine Permutation einer Liste ist eine zweite Liste, die genau dieselben Elemente enthält, jedoch möglicherweise in einer anderen Reihenfolge. Die Funktion ist Permutation nimmt zwei Listen und prüft, ob es sich dabei um Permutationen voneinander handelt. Die Funktion gibt einen booleschen Wert zurück: wahr, wenn die beiden Listen Permutationen voneinander sind und falsch, wenn dies nicht der Fall ist.

Im Allgemeinen habe ich ein kleines Problem mit einer Funktion wie dieser: Die Funktion wird für Listen von Objekten definiert und nicht für Listen eines bestimmten Typs, wie eine Liste von Zeichenketten oder eine Liste von booleschen Werten. Aber nicht alle Typen verfügen unbedingt über eine Funktion zur Prüfung auf Gleichheit, die eine notwendige Voraussetzung dafür ist, dass diese Funktion funktioniert. Dies könnte also später zu Problemen führen. Ich bin mir nicht sicher, wie man damit am besten umgehen soll.

Die Funktion verfügt derzeit über fünf Tests: drei Paare, die keine Permutationen sind – (a, a, a) / (a, b, c), (b,c) / (a,b,c) und (b,b,a) / (a,a,b) – und zwei Paare, die Permutationen sind, (b,c,a) / (a,b,c) und (a,b,a) / (a,a,b). Es ist großartig, fünf Tests zu sehen! Ich würde mich auch für einige Randfälle entscheiden (was ist mit leeren Listen?) und, sofern die Funktion für Listen beliebigen Typs definiert ist, auch für Listen, die mehr als einstellige Zeichenketten als Elemente haben. Aber nochmal: Juhu für fünf Tests! Mit fünf Tests liegt die Funktion in den oberen 10 % der Funktionen nach Anzahl der Tests.

Die Funktion verfügt derzeit über drei Implementierungen, eine in Python und zwei Kompositionen. Die Python-Implementierung besteht aus zwei Schritten: Sie führt zunächst eine Kürzung durch und prüft, ob die beiden Listen unterschiedliche Längen haben. Wenn dies der Fall ist, stoppt die Implementierung und gibt falsch zurück: Zwei Listen unterschiedlicher Länge können niemals Permutationen voneinander sein. Sobald wir wissen, dass sie die gleiche Länge haben, vergleichen wir, ob die beiden sortierten Listen gleich sind. Wenn dies der Fall ist, sind die beiden Listen Permutationen voneinander, wenn nicht, sind sie es nicht. Durch die Sortierung wird jede der Eingabelisten hinsichtlich ihrer Elemente in eine kanonische Version umgewandelt, die unabhängig von der Reihenfolge ist, weshalb diese Implementierung funktioniert. Theoretisch könnten wir den ersten Schritt dieser Implementierung auch weglassen, aber die Prüfung ermöglicht wahrscheinlich eine gewisse Beschleunigung.

Eine der Kompositionen verwendet Obermengen: Wir haben eine Funktion, ist Obermenge, die prüft, ob eine Liste eine Obermenge der anderen ist. Die Komposition verwendet hier eine Obermenge, um zu prüfen, ob die erste Liste eine Obermenge der zweiten und die zweite eine Obermenge der ersten ist. Wenn beide Bedingungen erfüllt sind (wir überprüfen dies mit and), wissen wir, dass beide Listen alle Elemente der anderen Liste und daher dieselben Elemente enthalten und daher Permutationen voneinander sein müssen. Bei zwei Tests kam es zu Zeitüberschreitungen, leider jedoch mit einer unbrauchbaren Fehlermeldung. Ein Fehler wurde gemeldet (T356556).

Die andere Komposition ist aufwändiger:

Zuerst prüft sie, ob die beiden Listen die gleiche Länge haben. Wenn nicht, wird falsch zurückgegeben.
Wenn dies der Fall ist, prüft sie, ob die erste Liste leer ist. Wenn ja, wird wahr zurückgegeben (da wir wissen, dass die zweite Liste aufgrund der vorherigen Prüfung ebenfalls leer sein muss und leere Listen Permutationen voneinander sind).
Als nächstes rufen wir die Permutation rekursiv selbst auf. Für den Rekursionsschritt finden und entfernen wir das erste Element der zweiten Liste aus der ersten Liste und vergleichen es mit der zweiten Liste ohne das erste Element.

In diesem letzten Schritt entfernen wir dasselbe Element aus beiden Listen und haben somit zwei kürzere Listen übrig. Wenn es sich dabei um Permutationen voneinander handelt, wären die beiden Listen mit den entfernten Elementen auch Permutationen voneinander, unabhängig davon, wo diese beiden Elemente in diesen Listen hinzugefügt werden.

Wenn das erste Element der zweiten Liste nicht in der ersten Liste vorhanden ist, bleibt die erste Liste unverändert, eine Bedingung, die von diesem Test in der Funktion erstes passendes Element entfernen überprüft wird.

Die beiden Kompositionen veranschaulichen, wie unterschiedlich zwei Kompositionen hinsichtlich der Komplexität sein können: Die Komposition mit Obermenge ist eine sehr einfache Komposition, fast wie eine Definition, die nur zwei vorhandene Funktionen kombiniert. Die andere Komposition ist viel ausgefeilter und kombiniert eine ganze Reihe verschiedener Funktionen, verwendet verschachtelte Wenn-Bedingungen und einen rekursiven Aufruf. Die letztgenannte Komposition liegt wahrscheinlich etwa in der Mitte der Komplexitätsstufe, von der ich erwarten würde, dass wir sie für Funktionskompositionen unterstützen: Viel komplexere Kompositionen als diese würde ich in Wikifunctions überhaupt nicht erwarten. Letztendlich sind beide Kompositionen jedoch großartige Beispiele dafür, wie Komposition zum Erstellen übergeordneter Funktionen verwendet werden kann.