Wikifunctions:Status-Updates/2025-07-04

Wikifunctions Status-Updates

Abdeckung von 1298

In vielen Sprachversionen der Wikipedia gibt es Artikel zu einzelnen Jahren – meist einige Tausend, die den Zeitraum von 500 v. Chr. bis etwa 2030 n. Chr. abdecken. Viele Wikipedias beginnen früher und einige Wikipedias gehen weiter in die Zukunft.

Wir haben das Jahr 1298 n. Chr. als zufälliges Jahr betrachtet und untersucht, wie gut dieses Jahr in verschiedenen Sprachversionen der Wikipedia abgedeckt ist. Dabei geht es nicht nur darum, die Anzahl der Artikel in einer Sprachversion zu bewerten, sondern darüber hinaus auch zu prüfen, wie viel Wissen der jeweilige Artikel enthält.

Als ich in der kroatischen Wikipedia arbeitete, war eine der ersten Sachen, die ich tat, die Entwicklung eines Python-Bots, der die Jahresartikel für die kroatische Wikipedia erstellte. Dadurch wurde die Anzahl der Rotlinks (d. h. Links, die zu noch nicht existierenden Artikeln führen) erheblich reduziert und es wurde einfacher, Wissen in diesen Artikeln zu sammeln und die Linkstruktur für den Aufbau und die Pflege der Enzyklopädie zu nutzen. Es würde mich nicht überraschen, wenn in vielen Sprachen die Jahresartikel ebenfalls von einem einzigen Autor begonnen wurden, der mit einem Bot über 2500 Artikel erstellte.

Jeder Bot, der dies tut, könnte einige strukturelle Informationen über das Jahr liefern – War es ein Schaltjahr? In welchem Jahrhundert war es? – aber normalerweise nicht mehr. Damals hätte ich weder die Idee noch die Mittel gehabt, einen Bot zu verwenden, um weitere Informationen über das Jahr aufzuschreiben, wie Geburten, Todesfälle, Ereignisse, etc. Heute, dank Wikidata, wäre das viel besser denkbar: Heute können wir ganz einfach eine Liste aller Personen in Wikidata, die im Jahr 1298 gestorben sind, sortiert nach der Anzahl ihrer Seitenlinks, erhalten und diese verwenden, um Teile des Artikels zu erstellen.

Diese von Bots erstellten Artikel blieben danach oft lange Zeit unberührt.

Die Analyse erfolgte manuell. Ich war bestrebt, die Möglichkeiten der Abstrakten Wikipedia streng zu bewerten und die Komplexität der Sprachversionen großzügig zu berücksichtigen. Eine vollständige Liste meiner Bewertungen findet sich hier. Die Analyse wurde am 8. April 2025 durchgeführt.

Zu diesem Zeitpunkt gab es 341 Sprachversionen der Wikipedia. Ein Artikel für das Jahr 1298 war in 131 Sprachen verfügbar und fehlte in 208 Sprachen völlig. Zwei Sprachversionen hatten Weiterleitungen zum entsprechenden Jahrhundert anstelle eines Artikels für das angegebene Jahr. Das bedeutet, dass diese Communitys potenziell Lücken schließen können, indem sie die Abstrakte Wikipedia in 61 % der Sprachen verwenden und die Anzahl der Sprachen, in denen der Artikel für das Jahr 1298 verfügbar ist, durch die einfache Erstellung einer einzigen Funktion (der Funktion für die Einleitung eines Jahres für die jeweilige Sprache, wie in einem vorherigen Newsletter erläutert) mehr als verdoppeln können.

In 65 Sprachen bestand der Artikel nur aus einem einfachen Jahresgerüst ohne weitere Informationen, wahrscheinlich von einem Bot erstellt und seitdem nicht mehr von Menschenhand bearbeitet. Viele dieser Jahresgerüstartikel waren sogar noch schlichter als die grundlegende Funktion für die Einleitung eines Jahres. Sobald die Abstrakte Wikipedia in diesen Sprachen verfügbar ist, könnten diese Artikel gelöscht werden, da die Abstrakte Wikipedia sie im Vergleich zur aktuellen Situation wahrscheinlich sehr schnell verbessern wird.

Jetzt wird es interessant: In 28 Sprachen haben wir nicht nur das Grundgerüst, sondern auch eine Liste einiger Geburten, Todesfälle und sehr einfacher Ereignisse (soweit ich das beurteilen konnte). Diese schienen alle sehr gut in der Abstrakten Wikipedia abgedeckt werden zu können, und die meisten davon würden auch von einer Quellenangabe aus der Abstrakten Wikipedia profitieren. Das bedeutet, dass wir davon ausgehen, dass 89 % der Wikipedias unmittelbar von der Abstrakten Wikipedia profitieren würden.

Interessant war übrigens, dass die thailändische Wikipedia das westliche Jahr 1298 mit dem weitgehend überlappenden Jahr 1841 BE im thailändischen Sonnenkalender abdeckt – ein hervorragendes Beispiel dafür, wie kulturelle Unterschiede die Struktur einer mehrsprachigen Enzyklopädie beeinflussen. In der Abstrakten Wikipedia setzen wir alles daran, dies auch in Zukunft zu ermöglichen.

Zeichnung aus einer japanischen Schriftrolle, erstellt 1298

Damit bleiben uns 38 Sprachen, deren Artikel komplexe Ereignisse beschreiben oder vielleicht sogar einen wertvollen Beitrag zu den Trends und Veränderungen des jeweiligen Jahres bieten. Die Inhalte dieser Artikel erfordern deutlich mehr Arbeit als die oben genannten, um sie wirklich in der Abstrakten Wikipedia zu erfassen. Besonders hervorzuheben sind die Artikel auf Slowenisch und Ukrainisch für ihren narrativen Inhalt. Dennoch ist es wahrscheinlich, dass einige dieser Artikel von einem Ersatz oder einer Erweiterung durch die Version der Abstrakten Wikipedia profitieren werden.

Hier liegt ein großer Vorteil des Modells der Abstrakten Wikipedia gegenüber der aktuellen Situation, basierend auf meinen Erfahrungen mit der kroatischen Wikipedia: Wenn die Artikel einzeln von Bots, die von einem Beitragenden geschrieben und auf dessen Rechner ausgeführt werden, erstellt werden, wird es für die Community, insbesondere später, recht schwierig, die Verantwortung für das Ergebnis zu verwalten. In kleinen Communitys ist das Fachwissen zum Schreiben, Anpassen und Ausführen solcher Bots möglicherweise nicht ohne Weiteres vorhanden. Wer also einen Bot für Tausende von Artikeln betreibt, übernimmt eine überproportionale Verantwortung für große Teile des Inhalts der jeweiligen Wikipedia.

Mit der Abstrakten Wikipedia wird sich das ändern, da die Mechanismen zur Inhaltserstellung in den Wikis selbst liegen, diese gemeinsam gepflegt werden können und Verbesserungen in die jeweiligen Wikipedias einfließen – und von der Community gemeinsam getragen werden. Außerdem werden einige einfache Fehler hoffentlich seltener, wie etwa Kopier- und Einfügefehler, die zu falschen römischen Ziffern führen, die falsche Instanziierung einer Vorlage oder Fehler in der Vorlage.

Letzte Änderungen an der Software

Wir haben den letzten erwarteten Teil der Proof-of-Concept-Arbeit zur Unterstützung der Rich-Text-Ausgabe (HTML) aus eingebetteten Funktionsaufrufen abgeschlossen. Die Ausgabe wird durch den HTML-Bereinigungscode von MediaWiki geleitet, um sicherzustellen, dass sie sicher in die Inhaltsseite eingefügt werden kann (T391983 und T391984). Wir werden die Funktionsweise in Kürze demonstrieren.

Wir haben unseren Code angepasst, der ausgeführt wird, wenn ein Objekt gelöscht wird, wodurch sichergestellt wird, dass das Objekt aus allen Caches gelöscht wird, und um das gelöschte Objekt auch im Wiki von allen anderen Objekten zu trennen, wenn es sich um eine verbundene Implementierung oder einen Testfall handelte (T392160 und T383502).

Wir haben die Funktionsauswertungskomponente so korrigiert, dass sie ihren Status beim Wechsel der verwendeten Funktion korrekt neu initialisiert (T395119). Außerdem haben wir einen kürzlich aufgetretenen Fehler in dieser Komponente behoben, der dazu führte, dass bei Funktionen mit einer typisierten Liste als Eingabeparameter die UX abstürzte (T397682). Wir haben den Code, der ein Objekt als einfache Zeichenfolge anzeigt, so korrigiert, dass unter bestimmten Umständen 'undefiniert' nicht mehr als Tooltip angezeigt wird.

Um die Funktionsfähigkeit und Leistung des Systems besser überwachen zu können, haben wir den Middleware-Code so umgestellt, dass er Nicht-HTTP-200-Antworten der Back-End-Dienste weiterleitet, anstatt sofort einen Fehler zu melden. Dadurch können wir HTTP-400-Fehler bei fehlerhaften Benutzereingaben und, was noch wichtiger ist, HTTP-500-Fehler bei Dienstausfällen korrekter zurückgeben, sodass wir diese schneller erkennen und beheben können (T393522). Außerdem haben wir die Protokollierung auf eine niedrigere Warnstufe eingestellt, wenn wir einen HTTP-400-Fehler vom Back-End erhalten.

Wir haben unser Wartungsskript LoadJsonDump erweitert, um den Import einer Reihe von Objekten anstelle der gesamten Datenbank zu ermöglichen und so ein schnelleres lokales Debugging basierend auf Produktionsdaten zu ermöglichen. Da der gesamte MediaWiki-Code nun PHP 8.1 oder höher erfordert, haben wir begonnen, unseren Code schrittweise so umzustellen, dass keine Catch-Variablennamen deklariert werden, die wir nicht verwenden. Außerdem haben wir bei Problemen auf Benutzerantwortebene, wo dies nicht angebracht ist, das Abfangen von Throwable- statt Exception-Fehlern eingestellt.

Wir und der gesamte von Wikimedia bereitgestellte Code verwenden seit dieser Woche die neueste Version der Codex UX-Bibliothek, Version 2.2.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.

Freiwilligentreffen am Montag

Am Montag, 7. Juli 2025, um 19:30 Uhr MESZ, findet unser monatliches Freiwilligentreffen statt. Sofern es nicht viele Fragen gibt, folgen wir unserem üblichen Programm: Wir informieren über die bevorstehenden Pläne und aktuelle Aktivitäten, bieten ausreichend Zeit und Raum für Fragen und erstellen gemeinsam eine Funktion. Wir freuen uns darauf, dich am Montag online zu sehen!

Wöchentliche neue Funktionen: 47 neue Funktionen

Diese Woche hatten wir 47 neue Funktionen. 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.