Wikifunctions:Status-Updates/2025-06-21

Wikifunctions Status-Updates

Quartalsplanung für Juli-September 2025

Um unsere Arbeit transparenter zu gestalten, veröffentlichen wir hier jedes Quartal unseren Plan für die kommenden drei Monate. Zu Beginn haben wir bereits unseren Plan für das vierte Quartal (April-Juni 2025) vorgestellt und werden in Kürze über dessen Umsetzung berichten.

Der Jahreszyklus der Foundation läuft von Juli bis Juni des darauffolgenden Kalenderjahres. Der diesjährige Jahresplan beinhaltet das zentrale "Ziel", um das sich die Arbeit unseres Teams dreht, Wiki-Erfahrungen (WE) 2, "Zentrales Wissen":

Mehr zentrales Wissen sprach- und themenübergreifend verfügbar machen und gut darstellen.

Das Team Abstrakte Wikipedia verfolgt im Allgemeinen drei strategische Ziele für seine Roadmap — Technische Grundlagen, Community-Aufbau und Vorbereitung auf Skalierung. In diesem Jahr konzentrieren wir uns hauptsächlich auf die technischen Grundlagen und den Ausbau der Funktionalitäten von Wikifunctions, um die Vision der Abstrakten Wikipedia zu veranschaulichen, sprachunabhängige Artikel in jeder Sprache basierend auf Wikidata-Inhalten zu generieren. Dies haben wir im Jahresplan als Schlüsselergebnis WE2.2 formuliert als "Aufbau der erforderlichen Plattformfunktionen, um zu bestätigen, dass wir die Vision der Abstrakten Wikipedia in großem Maßstab unterstützen können."

Wir haben mehrere Arbeitsbereiche, die wir im Folgenden in unsere drei unten aufgeführten Bereiche einteilen.

Technische Grundlagen

Damit die Vision einer Abstrakten Wikipedia spannend, interessant und bedeutsam wird, müssen wir durch echte, funktionierende Systeme die Fähigkeiten demonstrieren, mit denen die On-Wiki-Communitys glaubwürdiges, wertvolles und zentrales Wissen in mehreren Sprachen erstellen können.

In diesem Quartal haben wir eine Reihe von Funktionalitäts- und technischen Arbeiten, von denen wir glauben, dass sie unseren On-Wiki-Communitys beim Aufbau glaubwürdiger Funktionen helfen werden:

Rich Text/HTML: Wenn wir auf Wikifunctions ermöglichen, HTML-Tabellen, Stile und Links auszugeben, demonstrieren wir durch eine Funktion, die eine Konjugationstabelle anzeigt, seine Fähigkeit, über einfache Umwandlungen hinaus neues Wissen in Wiktionarys zu generieren.
Usability-Korrekturen basierend auf Tests der Dagbani-Community. Wenn wir die Usability-Ergebnisse der Dagbani-Community berücksichtigen, werden Autoren bei Tests weniger oder gar keine kritischen Usability-Probleme feststellen und wir werden eine verstärkte Nutzung eingebetteter Wikifunctions in Wikis feststellen.
Bereitstellung einer Wikidata-Lexem-Sinn-Komponente. Wenn wir eine Wikidata-Lexem-Sinn-Komponente in die Wikifunctions-Benutzeroberfläche integrieren, können Beitragende relevante Lexeme identifizieren und auswählen, ohne die Plattform/Wikifunctions verlassen zu müssen. Dies reduziert den Kontextwechsel und ermöglicht eine schnellere und erfolgreichere Erstellung sprachbezogener Funktionen.
Wikidata in eingebetteten Funktionsaufrufen: Wenn wir Unterstützung für Wikidata-Entitäten in eingebetteten Funktionsaufrufen hinzufügen, aktivieren wir über 200 neue Funktionen, die mithilfe von Wikidata-Entitäten umfassende Sätze generieren können, wodurch Funktionen in Wikimedia-Projekten einfacher verwendet werden können.
Umfassenderer Zugriff auf Wikidata-Inhalte: Wenn wir den Import von Wikidata-Aussagen mit Qualifikatoren ermöglichen, können vielschichtige Fakten generiert werden (Fakten, die mehr als nur Subjekt/Prädikat/Wert zum Ausdruck bringen müssen), was schätzungsweise 50 % der enzyklopädischen Inhalte in Wikidata umfasst.
Leistungsstärkerer Zugriff auf Wikidata-Inhalte: Wenn wir die Zwischenspeicherung abgerufener Wikidata-Entitäten ermöglichen, reduzieren wir die durchschnittliche Laufzeit inhaltsbasierter Funktionen von Wikidata um mindestens 50 % und verringern so Zeitüberschreitungen und Benutzerfrustration.
Erhöhung der Stabilität beim Ausführen von Funktionsaufrufen: Wenn wir unser Back-End-internes Anforderungsformat ausdrucksstärker und prägnanter gestalten, können wir die Stabilität des Systems erhöhen und so eine breitere Einführung unterstützen.
[Produktspitze] Erkundung der Unterstützung für Zitate: Wenn wir die Produktanforderungen für Einzelnachweise, die für Abstrakte Inhalte erforderlich sind, definieren und zwischen den Produkt- und Technologieteams abstimmen, können wir die wikimediaübergreifende Arbeit vorantreiben, um mit Abstrakten Inhalten verknüpfte Herkunftsinformationen bereitzustellen, die für eine erfolgreiche Übernahme in allen Wikis von entscheidender Bedeutung sind.

Community-Aufbau

Damit die Vision der Abstrakten Wikipedia ein Erfolg wird, müssen wir planen, wie die Communitys die Abstrakten Inhalte nutzen, kontrollieren und im Hinblick darauf zusammenarbeiten, sodass sämtliches wichtige Wissen, das sie schaffen kann, tatsächlich in mehreren Sprachen sinnvoll verfügbar ist.

In diesem Quartal möchten wir die Diskussion über die Funktionsweise Abstrakter Inhalte fortsetzen und Inhalte demonstrieren, die zeigen, wie es funktioniert, damit wir Antworten darauf haben, wie sie von On-Wiki-Communitys genutzt werden:

[Produktspitze] Umfang der Arbeit am Ort der abstrakten Inhalte: Wenn wir einen Architekturplan dafür entwickeln, wo Abstrakte Inhalte gespeichert werden und wie sie mit Wikipedia interagieren, sind wir besser darauf vorbereitet, die Plattform für die Abstrakte Wikipedia zu implementieren, um die Bereitstellung hochwertiger enzyklopädischer Inhalte zu erhöhen.
Demonstrierter Abstrakter NLG-Inhalt: Wenn wir Prototypfragmente mithilfe von Wikidata- und Wikifunctions-Aufrufen bereitstellen, um Ausschnitte in natürlicher Sprache zu generieren, zeigen wir die Bereitschaft für das Projekt und sind bereit, es zum Trainieren von KI zu verwenden, sodass Menschen nicht zu viel über Funktionen nachdenken müssen.

Vorbereitung auf Skalierung

Damit die Vision der Abstrakten Wikipedia nutzbar und skalierbar ist und viele Themen in vielen Sprachen abdeckt, müssen wir dafür sorgen, dass sie für die Benutzer schnell zu lesen und zu bearbeiten ist, sich schnell aktualisieren lässt, wenn sich die zugrunde liegenden Datenquellen ändern, und dass die Server kostengünstig sind, damit sie skalierbar ist.

In diesem Quartal planen wir, die Einführung der vorhandenen eingebetteten Funktion in neuen On-Wiki-Communitys fortzusetzen, damit wir von ihnen lernen können, wie gut die Werkzeuge funktionieren, welche neuen Probleme in verschiedenen Sprachen und Communitys auftreten und wo wir Funktionen hinzufügen oder erweitern können, um sie besser an unterschiedliche Wissens- und Community-Formen anzupassen:

Einführung: Wenn wir der Einführung von Parsoid folgen und Wikifunctions in die meisten Wiktionarys und einige Wikipedias mit geringem Datenverkehr integrieren, erhalten wir die Tests, die wir benötigen, um die Einführung sicher in größeren Wikis durchzuführen.

Neben den oben genannten Punkten planen wir auch einige wichtige Arbeiten, erstens um eine bessere Kapazitätsplanung für die Back-End-Dienste durchzuführen und zweitens um unsere Rust-Neuplattformierung des sicherheitssensiblen Auswertungsdienstes für die Ausführung des Back-End-Codes fortzusetzen.

Letzte Änderungen an der Software

Diese Woche ist es ruhiger, da wir einige der neuesten Funktionen und Fähigkeiten bereinigen.

Zusätzlich zu dem Back-End-Service-Caching-System, das wir letzte Woche eingeführt haben (T390549), aktivieren wir diese Woche einen neuen Stapel-Algorithmus, der uns weniger und konsolidiertere Anfragen für Objekte ermöglicht, wenn wir diese aus dem Wiki abrufen müssen (T390550). Außerdem haben wir eines unserer Wartungsskripte erweitert, um alle Objekte eines Typs an diesen Cache senden zu können. Dadurch können wir eine hohe Cache-Leistung gewährleisten, selbst wenn der Cache neu erstellt werden muss.

Wir haben auch einen Machbarkeitsnachweis für eingebettete Wikifunctions-Aufrufe erbracht, der Rich Text anstelle von reinem Text zurückgibt, und die Front-End-Komponente für die Anzeige und Bearbeitung dieser Inhalte fertiggestellt (T391985). Weitere Informationen folgen in Kürze!

Wir haben die benutzerdefinierten 'Chip'-Komponenten, die wir für Aliasse verwendet haben, durch die jetzt verfügbare offizielle Codex-Version ersetzt (T392702). Wir haben einen Teil unseres Codes für die Kommunikation zwischen der Wikifunctions.org-Wikisoftware und den Back-End-Diensten vereinfacht. Wir haben das Format modernisiert, das von den API-Aufrufen unseres Front-End-Vue-Codes für die Kommunikation mit dem Wiki zurückgegeben wird, um Konsistenz zu gewährleisten und Verwirrung bei den Entwicklern zu vermeiden.

Wir und der gesamte von Wikimedia bereitgestellte Code verwenden seit dieser Woche die neueste Version der Codex UX-Bibliothek, Version 2.1.0. Wir sind der Meinung, dass es keine für den Benutzer sichtbaren Änderungen an Wikifunctions geben sollte. Kommentiere daher bitte in der Projektdiskussion oder erstelle einen Task im Phabricator, wenn du ein Problem bemerkst.

Neuigkeiten zu Typen

Einige neue integrierte Typen

Um Wikidata-Daten besser zu unterstützen, haben wir einige integrierte Typen eingeführt: Wikidata-Zeit, Wikidata-Menge und Wikidata-Geokoordinaten. Diese Woche haben wir Code bereitgestellt, der diese neuen Typen instanziiert. Werte dieser drei Typen erscheinen in Aussagen innerhalb größerer ZObjekte mit Wikidata-Inhalten, wie Wikidata-Datenobjekt und Wikidata-Lexem. Diese Werte werden instanziiert, wenn eine der Wikidata-Abruffunktionen aufgerufen wird, wie erhalte Wikidata-Datenobjekt und erhalte Wikidata-Lexem.

Allerdings gibt es hinsichtlich dieser drei neuen Typen noch einige offene Punkte:

Jeder von ihnen basiert auf bestehenden Typen wie Natürliche Zahl, Rationale Zahl und Tag des Römischen Kalenders. Wir stellen fest, dass die Benutzeroberfläche gelegentlich Fehlermeldungen der Anzeigefunktionen für diese Typen anzeigt. Wir vermuten, dass dies mit der aktuellen Langsamkeit bei der Anzeige großer Wikidata-Entitäten zusammenhängt. Derzeit wird an einer deutlichen Verbesserung gearbeitet. Bis dahin ist es möglich, eine Fehlermeldung zu umgehen und die Werte anzuzeigen, indem man auf den entsprechenden Chevron (>) klickt, um die Detailansicht zu öffnen.
Wie in der Projektdiskussion erwähnt, müssen Funktionen im Zusammenhang mit dem Tag des Römischen Kalenders möglicherweise noch aktualisiert werden, um einige neue Konventionen zu berücksichtigen, die wir für unbekannte Monate und unbekannte Jahre übernommen haben.

Bitte beachte diese offenen Punkte beim Schreiben von Implementierungen für die neuen Typen. Wie du im nächsten Abschnitt siehst, wurden bereits viele Funktionen dafür geschrieben. Einige Diskussionen über Umwandler haben bereits begonnen. Vielen Dank an alle!

Leichtgewichtige Aufzählungstypen

Die neue Möglichkeit "leichtgewichtiger Aufzählungstypen", die zuvor auf der Statusseite erwähnt wurde, ist jetzt verfügbar.

Ein leichtgewichtiger Aufzählungstyp ist eine Sammlung von Wikidata-Entitätsreferenzen, die die möglichen Werte des Typs darstellen. Jede Instanz des Typs ist ein kleiner Wrapper um einen der möglichen Werte. Es gibt derzeit fünf erste Beispiele für leichtgewichtige Aufzählungstypen:

Grammatikalisches Geschlecht (M/F), für maskuline und feminine Geschlechter
Grammatikalisches Geschlecht (M/F/N), für maskuline / feminine / neutrale Geschlechter
Grammatikalisches Geschlecht (U/N), für die Geschlechter Utrum und Neutrum
Wikidata-Kalendermodell, derzeit mit Verweis auf den Gregorianischen und den Julianischen Kalender
Wikidata-Zeitpräzision, mit einer Auflistung der 15 in Wikidata verwendeten Stufen der zeitlichen Präzision

Die ersten drei davon können bei der Generierung von Inhalten in Sprachen nützlich sein, die diese Gruppierungen von Geschlechtskonzepten verwenden, wie sie in diesem Wikipedia-Listenartikel kategorisiert sind. Die anderen beiden werden im Zusammenhang mit dem oben erwähnten Typ Wikidata-Zeit verwendet.

Es gibt eine Gleichheitsfunktion, die mit Instanzen jedes beliebigen leichtgewichtigen Aufzählungstyps verwendet werden kann. Mindestens zwei weitere integrierte Hilfsfunktionen sind geplant, um den Nutzen leichtgewichtiger Aufzählungstypen zu erhöhen. Sie sollten in den nächsten ein bis zwei Wochen verfügbar sein:

eine Funktion, die die Wikidata-Referenz aus einer Instanz eines leichtgewichtigen Aufzählungstyps extrahiert (T397490)
eine Funktion, die die möglichen Werte eines leichtgewichtigen Aufzählungstyps meldet (T397494).

Beachte, dass sich leichtgewichtige Aufzählungstypen von normalen Aufzählungstypen unterscheiden, die im Status-Update 2024-05-10 eingeführt wurden. Bei einem normalen Aufzählungstyp ist jeder mögliche Wert ein persistentes ZObjekt mit eigener ZID, während die möglichen Werte leichtgewichtiger Aufzählungstypen Referenzen auf Wikidata-Entitäten sind (die keine lokale Instanziierung auf Wikifunctions haben).

Wöchentliche neue Funktionen: 72 neue Funktionen

Diese Woche hatten wir 72 neue Funktionen. Juhu! Hier ist eine 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!

Eine vollständige Liste aller Funktionen, sortiert nach Erstellungsdatum, ist verfügbar.