Wikifunctions:Status-Updates/2024-07-18

◀

Wikifunctions Status-Updates

▶

Forschungsbericht zur Integration von Wikifunctions in Wikipedia

In den letzten Monaten haben wir mit einem Designforscher zusammengearbeitet, um Antworten auf die folgenden zwei Fragen zu finden:

1. Welche Möglichkeiten gibt es, die Arbeitsabläufe und die Effektivität von Wikipedia-Mitarbeitern durch Wikifunctions zu verbessern?
2. Welche Hindernisse könnten einer erfolgreichen Wikifunctions-Integration im Wege stehen?

Wir haben nun den Bericht auf Wikimedia Commons veröffentlicht.

Unsere Forscher fanden heraus, dass die typischen Beitragsabläufe, die von Autoren kleiner Wikipedia-Sprachversionen beschrieben werden, hauptsächlich das Übersetzen von Artikeln aus größeren Wikipedias (normalerweise Englisch) in ihre eigene Sprache mithilfe von Werkzeugen wie dem Werkzeug zur Inhaltsübersetzung umfassen. Sie sind auch damit beschäftigt, Artikel zu erweitern, Fehler zu korrigieren und technische Probleme (z. B. an Vorlagen) zu beheben. Das größte technische Problem, das von den Teilnehmern hervorgehoben wurde, ist das Fehlen entsprechender Vorlagen beim Übersetzen von Artikeln, insbesondere aus dem Englischen. Dies führt häufig zu inhaltlichen Auslassungen, Fehlern oder fehlenden Einzelnachweisen, wenn Artikel auf diese Weise erstellt werden.

In vielen Wikimedia-Communitys herrscht ein bemerkenswerter Mangel an technischem Wissen, und oft übernehmen einige wenige erfahrene Autoren die meisten technischen Aufgaben. Eine gute Beschreibung einer solchen Situation findet sich in einem aktuellen Signpost-Artikel über die Community der russischen Wikipedia.

Mit dem Wachstum der Communitys und ihrer Inhalte werden die Vorlagensätze in den verschiedenen Wikipedia-Sprachen tendenziell komplexer und unterscheiden sich stärker von anderen Wikis. Kleinere Wikipedias beginnen oft mit Vorlagen, die sie aus der englischen Wikipedia kopieren, entwickeln diese dann aber entsprechend ihren eigenen Bedürfnissen und Richtlinien weiter. Die Untersuchung ergab keine spezifischen Details zu den regulären Prozessen, die von Communitys befolgt werden, um Vorlagencode und Lua-Module zu pflegen.

Die Untersuchung ergab, dass das Aktualisieren von Fakten in Artikeln kein üblicher Arbeitsablauf unter den Teilnehmern ist. Ihr Fokus liegt im Allgemeinen auf dem Erstellen neuer Artikel, anstatt bestehende auf dem neuesten Stand zu halten. Einige Beitragende verwenden jedoch automatisierte Werkzeuge (z. B. "Datenboxen"), um Inhalte aus Quellen wie Volkszählungsdaten über Wikidata zu optimieren.

Die meisten Teilnehmer hatten von Wikidata und Wikifunctions gehört und standen diesen Projekten im Allgemeinen positiv gegenüber. Die Vertrautheit mit der Abstrakten Wikipedia war geringer, aber Teilnehmer, die Wikifunctions kannten, sahen es positiv und erkannten sein zukünftiges Potenzial, ihre Arbeit zu unterstützen. Die Teilnehmer reagierten im Allgemeinen positiv auf ein in einem Video demonstriertes Integrationsmodell von Wikifunctions. Sie erkannten schnell den Wert von Wikifunctions.

Einige Teilnehmer glaubten fälschlicherweise, dass jeder von Wikifunctions oder der Abstrakten Wikipedia erstellte Text maschinell aus dem Englischen übersetzt würde, und es herrschte Verwirrung über den Unterschied zwischen maschineller Übersetzung und strukturierter Textgenerierung anhand strukturierter Daten. Es musste auch klargestellt werden, dass Funktionen nicht in ihrer eigenen Wikipedia-Sprachversion bereitgestellt und gepflegt würden, sondern sprachübergreifend verwendet werden könnten.

Der Forschungsbericht gibt folgende Empfehlungen:

1. Integration von Wikifunctions in gängige Aktivitäten, die Autoren gerne durchführen und mit denen sie bereits vertraut sind.
2. Anpassung von Wikifunctions, um bestehende technische Herausforderungen zu lösen und so den technischen Gesamtaufwand für Autoren deutlich zu reduzieren.

Dazu gehört das Erstellen von Funktionen, die die Funktionalität häufig verwendeter, vorhandener Vorlagen oder Module der englischen Wikipedia replizieren, und das Bereitstellen von Funktionen, die Beitragende mit wenig oder keinem Aufwand in anderen Wikis verwenden können. Wir sollten auch sicherstellen, dass die Wikifunctions-Integration verschiedene, wikispezifische redaktionelle Richtlinien unterstützt.

Der Bericht konzentrierte sich auf Bearbeitungsmuster für Wikipedias, aber wir hoffen, dass die Erkenntnisse auf alle unsere Projekte übertragbar sind. Wir danken Andrew für die Erstellung des Berichts, Amin für seine Unterstützung und die Formulierung eines Großteils der obigen Zusammenfassung, Amy und Bethany für die Betreuung des Berichts und den vielen Community-Mitgliedern, die interviewt wurden und deren Erkenntnisse zum Bericht beigetragen haben.

Du kannst den vollständigen Bericht auf Wikimedia Commons lesen.

Letzte Änderungen an der Software

Diese Woche haben wir einen großen Teil unserer Energie in die für das Quartal geplanten Arbeiten gesteckt, insbesondere in Bezug auf die Protokollierung bei den Back-End-Diensten (T368000), die wir diese Woche bereitgestellt haben.

Wir haben den Algorithmus geändert, der die schnellste Implementierung auswählt (und die Liste im Wiki neu sortiert), um Verwirrungen zu vermeiden. Zuvor wurde die gesamte CPU-Zeit des Servers verwendet, jetzt jedoch die serverseitige Dauer ('Wall Time'). Dadurch wird möglicherweise Code ausgewählt, der auf unseren Servern langsamer läuft, in der Praxis jedoch für Benutzer schneller läuft (T369587).

Wir haben die Logik im Front-End beim Bearbeiten des Typs typisierter Listen verbessert; anstatt alle Elemente zu entfernen, wenn du ihren Typ änderst, entfernen wir jetzt nur nicht übereinstimmende Elemente (T352258). Das bedeutet, dass, wenn du eine typisierte Liste allgemeiner Objekte (Z1) hättest, von denen die Hälfte Zeichenketten (Z6) und die andere Hälfte boolesche Werte (Z40) wären, und du diese in eine typisierte Liste von Zeichenketten ändern würdest, die booleschen Werte gelöscht würden, die Zeichenketten jedoch erhalten blieben.

Wir haben auch ein paar Verbesserungen der Benutzerfreundlichkeit im Front-End-Erlebnis vorgenommen. Zunächst haben wir den <title> einfacher gestaltet: statt "{Label} {ZID} {Type} - Wikifunctions" (z. B. "Echo - Wikifunctions") nur "{Label} - Wikifunctions" (also "Echo - Wikifunctions"). So verhält sich Wikidata, und wir hoffen, dass es Reiter schneller und einfacher lesbar macht (T360169). Zweitens haben wir das alte Design der h1-Überschrift auf Objektseiten geändert, das zuvor dem Design von Wikidata entsprach. Wir haben die ZID von Klammern auf eine Schriftart mit einzelnem Leerzeichen umgestellt und sie per Klick kopierbar gemacht, um mit dem Widget "Funktions-Explorer" konsistent zu sein (T360001). Dies ist ein Verhalten, das Wikidata vielleicht von uns kopieren möchte! 😉

Wir haben einen Fehler behoben, der dazu führte, dass beim Klicken auf den Link "Zum Inhalt springen", den MediaWiki in die Seite einfügt, Bezeichnungen gelöscht wurden, wenn in Chrome neue Funktionen oder Objekte erstellt wurden (T348094).

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

Neuer Typ: Ära des Gregorianischen Kalenders

Wir haben eine Aufzählung für die Ära des Gregorianischen Kalenders erstellt, da die Community im Typenvorschlag Unterstützung dafür geäußert hat. Sie hat zwei Werte: einen für die Ära, in der wir uns befinden und einen für die davor. Sie heißen derzeit im (internationalen) Englisch AD und BC und im amerikanischen Englisch CE und BCE – aber wir sind uns bei der Benennung nicht ganz sicher und überlassen es wie immer der Community, die Namen auszuwählen, die sie für am passendsten hält.

Die verwandten Vorschläge für Tag des Römischen Jahres, Gregorianisches Jahr und Datum des Gregorianischen Kalenders haben noch nicht viel Interaktion erfahren, und es wäre toll, Rückmeldungen oder alternative Vorschläge zu sehen. Vielleicht erschwerte die Aufteilung der Vorschläge auf einzelne Seiten die Navigation und Prüfung?

Basierend auf dieser Erfahrung haben wir die Typen mit Bezug zu Lexem auf Wikidata auf einer einzigen Seite zusammengefasst, wie letzte Woche besprochen. Das hat ziemlich viel Interaktion hervorgerufen, und wir haben mit der Einrichtung von Prototypen der Struktur der Typen im Wiki begonnen. Wir haben auch den Typ Lexem-Sinn hinzugefügt, aber dieser muss noch weiter ausgearbeitet werden. Wir bitten darum, diese Typen noch nicht zu verwenden (wahrscheinlich für eine Weile), während wir herausfinden, wie sie mit Wikidata verbunden werden können. Wir halten dich auf dem Laufenden.

Denny für ein paar Wochen abwesend

Denny zieht in den nächsten Wochen von den USA nach Deutschland und ist somit weniger erreichbar. Den wöchentlichen Newsletter übernimmt wie schon beim letzten Mal Sharvani.

Eine frei bearbeitbare Präsentation über Wikifunctions & Abstrakte Wikipedia ist verfügbar

Im letzten Quartal (April bis Juni 2024) haben wir an einer grundlegenden Präsentation über Wikifunctions und die Abstrakte Wikipedia gearbeitet, die von Benutzern frei wiederverwendet und bearbeitet werden kann, falls du eine Präsentation über unser(e) Projekt(e) halten möchtest, dabei aber etwas Hilfe benötigst.

Wir freuen uns, dir mitteilen zu können, dass Version 1.0 der Folien jetzt frei verfügbar und herunterladbar ist. Du kannst sie gerne in dem von dir gewünschten Format herunterladen und übersetzen oder nach deinen Wünschen ändern. Du kannst auch Folien kommentieren, wenn du uns Rückmeldung geben möchtest oder Erläuterungen benötigst. Du kannst hierfür auch den Abschnitt in der Projektdiskussion verwenden, wenn du möchtest. Wir würden gerne sehen, welche Änderungen du vornimmst, und alle endgültigen Präsentationen (in jeder beliebigen Sprache), falls du sie verwendest.

Beachte auch, dass die meisten Folien Notizen für Vortragende enthalten: Wir haben dies getan, damit die Leute die Idee hinter der Einführung und den meisten Folien, die nur aus Bildern bestehen, besser verstehen. Notizen können natürlich auch frei wiederverwendet, geändert und übersetzt werden.

Da Commons uns leider nicht erlaubt, .odp- oder .ppt-Dateien hochzuladen, können wir sie vorerst nur auf Google Docs bereitstellen. Wir wissen, dass dies für einige ein Problem sein könnte. Wenn du also eine Kopie der Folien in einem offenen Format benötigst, sende bitte eine E-Mail an User:Sannita (WMF), und er wird sie dir zusenden. Vielen Dank für deine Geduld!

Funktion der Woche: Teiler

Letzte Woche haben wir angekündigt, dass typisierte Listen jetzt auch für die Arbeit mit im Wiki definierten Typen verfügbar sind. Wir haben jetzt eine ganze Reihe von Funktionen, die mit typisierten Listen arbeiten. Daher haben wir eine Funktion ausgewählt, die mit einer solchen typisierten Liste arbeitet: Teiler (Z13726).

Ein Teiler ist eine Zahl, die eine gegebene Zahl ohne Rest teilt. Wir haben eine Funktion, ist teilbar (Z13740), die prüft, ob eine Zahl durch die andere teilbar ist. Beispielsweise ist 6 durch 3 teilbar und 24 ist durch 8 teilbar, aber keine der beiden Zahlen wäre durch 7 teilbar.

Die Funktion Teiler (Z13726) nimmt eine natürliche Zahl und gibt alle Zahlen, durch die die gegebene Zahl teilbar ist, als typisierte Liste natürlicher Zahlen zurück. Für die Eingabe 6 wären das 1, 2, 3 und 6. Für 24 wäre das die Liste 1, 2, 3, 4, 6, 8, 12 und 24. Für 7 sind das nur 1 und 7, was bedeutet, dass 7 eine Primzahl ist, da sie nur durch 1 und sich selbst teilbar ist.

Die Funktion hat derzeit drei Implementierungen:

1. eine in Python, die die Werte bis zur Quadratwurzel des Arguments prüft
2. ein weitere in Python, die alle Werte bis zum Argument prüft
3. und eine in JavaScript, die ebenfalls alle Werte bis zum Argument prüft

Die Funktion hat sieben Tests, die die Teiler von null, sechs, neun, zehn, sechzehn, siebzehn und der Belphegors Primzahl prüfen. Das ist eine ganz schöne Streuung: Null als Test für einen Randfall (der andere Randfall, eins, fehlt), siebzehn für eine Primzahl, neun und sechzehn als kubische und quartische Zahlen prüfen auf Wiederholungen der Faktoren, was bei einigen Implementierungen passieren könnte. Sechs und zehn sind schöne, übliche Werte. Und Belphegors Primzahl dient als Stresstest der Implementierungen, da es sich um eine sehr große Primzahl handelt, und wie erwartet schlagen die Implementierungen fehl (und dementsprechend ist dieser Test nicht verbunden).

Beachte, dass wir derzeit keine Code-Implementierungen für Funktionen mit untypisierten Listen unterstützen (T370028).