Wikifunctions:Status-Updates/2025-11-13
| ◀ | ▶ |
Vorbereitung für die zweite Abstimmungsrunde über den Namen des Wikis mit abstraktem Inhalt
Nächste Woche startet die zweite und letzte Abstimmungsrunde über den Namen des Wikis mit abstraktem Inhalt. Es wird ein neues Wiki sein, aber im Grunde ein Hintergrundprojekt für Wikipedia-Leser.
Die sechs Vorschläge, die voraussichtlich in die zweite Runde gehen, sind Abstract Wikipedia, Wikicore, Multilingual Wikipedia, Wikiabstracts, Wikigenerator und Proto-Wiki. Ab nächster Woche kannst du für diese Vorschläge abstimmen, indem du sie nach Priorität ordnest. Anschließend werten wir die Stimmen aus und ermitteln so die Präferenz der Community.
Aktuell laufen Diskussionen über die Vorschläge mit dem Ziel, diese in einer Tabelle zusammenzufassen, die den Wählern als Orientierung dienen soll. Du bist herzlich eingeladen, dich an der Diskussion und an der Erstellung der Zusammenfassung zu beteiligen.
Darüber hinaus haben wir die Marken- und Rechtsabteilung der Wikimedia Foundation um eine Stellungnahme zu den Vorschlägen gebeten und gehen davon aus, diese ebenfalls vor Beginn der Abstimmung in die Tabelle aufzunehmen.
Nochmals vielen Dank an alle, die bisher an diesem Prozess teilgenommen haben, und wir freuen uns darauf, einen tollen Namen für das neue Projekt zu finden!
Neuschreiben des Back-Ends: Warum Rust?
Das Team der Abstrakten Wikipedia verwendet WebAssembly (WASM) für die Sandbox-Umgebung von Benutzercode. Dies hat zu Problemen mit unseren in Node.js geschriebenen Diensten geführt. Es gibt keine Integrationen des WebAssembly System Interface (WASI) für Node.js, die die notwendigen Funktionen zum Ausführen von WASM-basierten Interpretern für Python und JavaScript bieten. Auch die bestehenden Integrationen erlauben keine Kontrolle über die WASM-Sandbox-Umgebung. Daher hat das Team WASI-Laufzeitumgebungen in Unterprozessen über eine Kommandozeilenschnittstelle (CLI) ausgeführt. Dies hat zu einer komplexen und fehleranfälligen Logik bei der Verwaltung verschachtelter Unterprozesse geführt. Es kann leicht passieren, dass der übergeordnete Prozess eines Prozesses beendet wird und der Prozess dann von PID 1 übernommen wird.
Eine Anmerkung zur Mythologie und Terminologie: Auf Unix-Systemen können Prozesse Eltern- und Kindprozesse haben. Ein Kindprozess, dessen Elternprozess stirbt, wird er zu einem "verwaisten Prozess". Dieser verwaiste Prozess kann dann von einem anderen Prozess übernommen werden. Wird der verwaiste Prozess jedoch von PID 1 übernommen und kann nicht mehr beendet werden, spricht man von einem "Zombie-Prozess". Dies ist, gelinde gesagt, eine ungewöhnliche Erklärung für Zombie-Prozesse.
Es gibt zwar Möglichkeiten, das Problem der Zombie-Prozesse abzuschwächen, diese lassen sich jedoch nur schwer in die Infrastruktur des Wikifunctions-Dienstes integrieren. Noch besser wäre es, das Auftreten von Zombie-Prozessen von vornherein zu verhindern, was eine Reduzierung unserer Abhängigkeit von Unterprozessen erfordert.
Aus diesem Grund hat das AW-Team beschlossen, den Funktionsauswerter in Rust neu zu implementieren. Rust bietet zahlreiche funktionsreiche Bibliotheken für die Interaktion mit WASI, darunter vollständige WASI-Laufzeitumgebungen, die direkt in Rust ausgeführt werden. Dadurch können wir auf Unterprozesse verzichten und stattdessen Threads (oder, technischer gesagt, asynchrone Aufgaben) in Rust verwenden. Threads/Aufgaben sind deutlich einfacher zu verwalten. Entscheidend ist, dass unser Rust-Code sicherstellt, dass Aufgaben nach einer gewissen Zeit sicher beendet werden und alle von der Aufgabe verwendeten Ressourcen beim Beenden freigegeben werden.
Mit Blick auf die Zukunft bietet Rust weitere Vorteile für das Wikifunctions-Back-End. Die WASI-Bibliotheken von Rust ermöglichen eine präzise Steuerung und eröffnen sogar neue Möglichkeiten für die native Codeausführung. Das Team prüft derzeit, ob der Funktions-Orchestratrierer ebenfalls auf Rust basieren soll. Ein auf Rust basierender Funktions-Orchestratrierer würde deutlich weniger Speicher und CPU-Leistung benötigen und zudem stärkere Garantien für das Verhalten der Wikifunctions-Kompositionssprache bieten.
Letzte Änderungen an der Software
Diese Woche gibt es nur eine für Benutzer sichtbare Änderung. Wir haben einen neuen vordefinierten Fehler, Z576, eingeführt, der ausgegeben wird, wenn der Backend-Auswertungsdienst nicht geladen werden kann (T408824). Dieser Fehler wird nun deutlich schneller zurückgegeben, anstatt auf die Zeitüberschreitung zu warten (T408826). Diese Änderungen sind Teil der Nacharbeiten nach dem Python-Ausfall (T406848).
Wir haben im Orchestrierer ein lokales Caching für Suchergebnisse von Wikidata implementiert (T408013). Dies beschleunigt Aufrufe von Funktionen, die auf finde Lexeme für Wikidata-Datenobjekt und/oder finde Lexeme für Wikidata-Lexemsinn aufbauen. Deklinationstabelle für deutsche Substantive ist ein Beispiel für eine solche Funktion.
Bevorstehendes NLG/SIG-Treffen am 18. November: Untersuchung von Designentscheidungen der Uniform Meaning Representation im Vergleich zu Ninai/Udiron
Das nächste Treffen der NLG SIG findet am Dienstag, den 18. November 2025 von 17:00 bis 18:00 Uhr MEZ auf Google Meet statt. Das Treffen wird aufgezeichnet.
Mahir256 präsentiert Untersuchungen von Designentscheidungen der Uniform Meaning Representation im Vergleich zu Ninai/Udiron.
Bitte um Hilfe auf Wikifunctions: Ersetzen von Z28154
Wir ersetzen Z28154 durch die integrierte Funktion Z851. Eine Liste von Implementierungen, die von einer Aktualisierung profitieren würden, findet sich hier, um die doppelte Funktion zu entfernen. Wir würden uns über Unterstützung bei dieser Aufgabe freuen.
Aufzeichnung von Präsentationen bei der WikidataCon
Auf der WikidataCon gab es dieses Jahr zwei Vorträge mit Bezug zur Abstrakten Wikipedia. Die Vorträge können als YouTube-Streams angesehen werden: Mad Libs mit Wikidata-Lexemen und Abstrakten Inhalten von Mahir und Wikidata und Abstrakte Wikipedia: die Gegenwart und die Zukunft von Geno. Viel Spaß beim Ansehen!
Wöchentliche neue Funktionen: 33 neue Funktionen
Diese Woche hatten wir 33 neue Funktionen. Hier ist eine unvollständige Liste von Funktionen mit Implementierungen und bestandenen Tests, um einen Eindruck davon zu bekommen, welche Funktionen erstellt wurden. Vielen Dank an alle für ihre Beiträge!
- is SignWriting? (Z29248)
- Brazilian Sign Language: article-less defining (Z29256)
- quoted reference (Z29267)
- punctuation mark in SignWriting (Z29270)
- extract SignWriting symbol (Z29283)
- table from function of row and column elements (Z29286)
- flatten a list completely (Z29290)
- object equivalence (Z29294)
- list to singleton-list (Z29301)
- outer product, u⊗v (rational vectors) (Z29308)
- form for table header (Z29315)
- form for table header, default (Z29316)
- table from function of set arg and list of row,col (Z29324)
- conjugate Italian adjective (feature list) (Z29334)
- Wikidata item reference from object (Z29335)
- QID is valid value of Enum Type (Z29341)
- Italian positive adjective conjugation table (Z29346)
- Function identity (Z29350)
- Low German article-ful instantiating sentence (Z29356)
- Low German article-ful instantiating sentence (Z29356)
- Unbeschriftet (Z29365)
- table from function of arg, row [arg], col [arg] (Z29368)
- apply3 to a common 1st and 2nd arg and list of 3rd (Z29370)
- classify nouns in German (Z29384)
- apply the needed arguments (Z29390)
- indexes of required arguments (Z29396)
- filter list through list of indexes (Z29400)
- most common element on list (Z29409)
- count occurrences of element on list (Z29413)
Eine vollständige Liste aller Funktionen, sortiert nach Erstellungsdatum, ist verfügbar.