Wikifunctions:Status-Updates/2024-12-19

◀

Wikifunctions Status-Updates

▶

Funktion der Woche: Alter

Letzte Woche haben wir den Typ Gregorianisches Datum eingeführt und während ich dies hier schreibe haben wir 23 Funktionen, die den neuen Typ verwenden. Vielen Dank an alle für eure Beiträge!

Eine Torte zum zehnten Geburtstag der Wikipedia

Eine der wichtigsten Funktionen für Wikifunctions, die wir bereits in Präsentationen und Aufsätzen erwähnt haben, ist die Altersfunktion. Diese Funktion verwendet zwei Datumsangaben als Argumente und berechnet die Differenz zwischen ihnen. Das erste Argument könnte beispielsweise das Geburtsdatum einer Person oder das Gründungsdatum einer Organisation sein. Die Funktion berechnet dann das Alter der Person oder Organisation in vollen Jahren zum im zweiten Argument angegebenen Datum.

Wikipedia wurde beispielsweise am 15. Januar 2001 gegründet. Am Tag der Veröffentlichung dieses Newsletters war die Wikipedia 23 Jahre alt. Die Altersfunktion würde dir diese natürliche Zahl als Antwort liefern.

Warum haben wir sie als Flaggschiff-Funktion ausgewählt? Weil mehr als 160 Wikimedia-Projekte eine Vorlage für diese Funktionalität haben und mehr als 100 Projekte ein Modul für diese Funktionalität haben. Aber in vielen Fällen werden diese Vorlagen und Module aus einem anderen Projekt kopiert und eingefügt, sind unzureichend dokumentiert, nicht gut getestet und werden fast nie aktualisiert, wenn das Original verbessert wurde. Und so oft diese Vorlagen und Module auch kopiert wurden, gibt es immer noch mehr als 500 Wikimedia-Projekte, die keinen Zugriff auf diese Funktionalität haben.

Ein Ziel von Wikifunctions ist es, solche Funktionen aus einem zentralen Repositorium bereitzustellen: Alle Projekte sollten automatisch auf diese Funktionalität zugreifen können, und zwar in ihrer aktuellsten Form, die sowohl durch explizite Funktionstests als auch durch die Verwendung in vielen Projekten gut getestet wurde. Kein Kopieren und Einfügen aus anderen Wikis mehr, keine Inhalte mehr, die die lokale Community kaum versteht und nur schwer pflegen kann.

Und jetzt haben wir auf Wikifunctions die Funktion Alter (Z20756). Sie hat derzeit vier Implementierungen und fünf Tests. Da wir noch keinen Parser für Datumsangaben konfiguriert haben, ist die Eingabe der Argumente etwas umständlich. Trotzdem habe ich diese Funktion als letzte Funktion der Woche für dieses Jahr ausgewählt, um die Gelegenheit zu nutzen, einen Teil dessen hervorzuheben, was Wikifunctions in Zukunft für Wikipedia bedeuten könnte.

Die fünf Tests sind:

• Jemand, der letztes Jahr an Weihnachten geboren wurde, wird dieses Jahr an Weihnachten 1 Jahr alt sein
• Jemand, der an Weihnachten im Jahr 4 n. Chr. geboren wurde, wird dieses Jahr an Weihnachten 2020 Jahre alt sein
• Jemand, der letztes Jahr an Weihnachten geboren wurde, wird dieses Jahr an Heiligabend immer noch 0 Jahre alt sein
• Jemand, der am 23. Januar 12 v. Chr. geboren wurde, war am 1. März 2 v. Chr. 10 Jahre alt
• Jemand, der am 1. Januar 5 v. Chr. geboren wurde, war am 3. April 33 n. Chr. 37 Jahre alt

Die Tests decken einen guten Bereich ab. Insbesondere die Tests über den Wechsel der Ära hinweg sind wichtig. Es wäre interessant, Vereinbarungen und Tests dafür zu haben, was passiert, wenn das erste Datum hinter dem zweiten liegt, und Tests für Datumsangaben außerhalb des Datumsbereichs von JavaScript (die ferne Zukunft oder Vergangenheit, mehr als 300.000 Jahre entfernt), aber ansonsten scheint die Testabdeckung gut zu sein.

Die vier aktuellen Implementierungen sind:

• Eine Komposition, die die Tage zwischen den beiden Datumsangaben zählt und sie durch 365 dividiert (wobei Schaltjahre nicht berücksichtigt werden)
• Eine weitere Komposition, die das erste Jahr vom zweiten subtrahiert und eine weitere Zahl subtrahiert, falls das zweite Datum früher im Jahr liegt als das erste. Dies geschieht durch geschickte Verwendung einer Umwandlung der Bedingung in eine Zahl. Diese Komposition schlägt jedoch zum Zeitpunkt, an dem ich dies hier schreibe, fehl.
• Eine dritte Komposition, die dasselbe tut, aber Ganzzahlen statt natürlicher Zahlen verwendet. Diese funktioniert, könnte aber von der Verwendung einiger weiterer Funktionen auf höherer Ebene profitieren.
• Eine Implementierung in JavaScript, die im Grunde dasselbe macht: Sie subtrahiert die Jahre und wenn das Datum später im Jahr liegt, wird noch eins abgezogen.

(Hinweis: Die ersten beiden Kompositionen wurden seit dem Verfassen dieses Textes gelöscht.)

Die Implementierungen sind interessant (auch wegen der ersten, die fehlschlagen soll, um die Relevanz einiger Testfälle hervorzuheben).

Aufruf für Funktionen: Intros für Artikel über Jahre

Das Hauptziel von Wikifunctions ist die Unterstützung der Abstrakten Wikipedia – aussagekräftige Absätze und Artikel im Wikipedia-Stil, die aus Daten und abstrakten Inhalten generiert werden. Dafür müssen wir in der Lage sein, qualitativ hochwertige textliche Inhalte für Artikel in vielen Sprachen zu erstellen.

Viele Wikipedias haben eine Reihe von Artikeln zu einzelnen Jahren — hier ist beispielsweise der Artikel für das Jahr 2023 in der Englischen Wikipedia. In den meisten Sprachen beginnt der Artikel mit ein paar Sätzen mit sehr ähnlichem Inhalt wie der englische Wikipedia-Artikel:

“2023 (MMXXIII) was a common year starting on Sunday of the Gregorian calendar, the 2023rd year of the Common Era (CE) and Anno Domini (AD) designations, the 23rd year of the 3rd millennium and the 21st century, and the 4th year of the 2020s decade.”

Es gibt nun eine Funktion, die einen Text erstellen kann, der diesem hier sehr ähnlich ist, allerdings ohne die Links und die Formatierung: Intro für Jahr auf Englisch, die den folgenden Text erzeugt:

“2023 (MMXXIII) was a common year starting on Sunday of the Gregorian calendar, the 2023rd year of the Common Era (CE) and Anno Domini (AD) designations, the 23rd year of the 3rd millennium, the 23rd year of the 21st century, and the 4th year of the 2020s decade.”

Diese ist derzeit nur auf Englisch verfügbar und verfügt über weniger Funktionen als die englische Wikipedia (sie wechselt beispielsweise nicht zum Julianischen Kalender, vereinheitlicht nicht die Zählung der Jahre in einem Jahrhundert und einem Jahrtausend, wenn es gleich ist, etc.). Es wäre interessant, ähnliche Funktionen auch für andere Sprachen zu erstellen. Daher rufen wir dazu auf, über die Feiertage Funktionen zu schreiben, und werden zu Beginn des Gregorianischen Kalenderjahres 2025 eine Bestandsaufnahme machen.

Eine weitere interessante Aufgabe – und die wäre mittelfristig – wäre die Arbeit an einer Funktion, die abstrakt ist, d. h. die die richtigen Wörter für die gegebenen Sprachen erzeugt, anstatt dass die Community auf Wikifunctions diese in jeder Sprache fest codieren muss. Das wäre derzeit noch schwierig, aber bis zum Ende des nächsten Quartals sollten wir in der Lage sein, “Jahrzehnt” oder “Jahrhundert” aus Wikidata in vielen verschiedenen Sprachen zu erhalten, was uns dabei helfen würde, dieses Ziel zu erreichen.

Es gibt außerdem drei wichtige Vorbehalte gegenüber der aktuellen Arbeit:

1. Bei größeren Kompositionen kommt es beim Wikifunctions-System zu Zeitüberschreitungen. Obwohl wir die Leistung unseres Systems verbessert haben, kommt es bei größeren Kompositionen immer noch zu Zeitüberschreitungen.
2. Es fehlt eine Funktion, die es uns ermöglicht, die Bezeichnung eines Objekts zu erhalten.
3. Zugegebenermaßen würde es in vielen Sprachen nicht ausreichen, selbst wenn wir die Bezeichnung hätten, da wir vielmehr das Lexem benötigen würden, um die entsprechende Beugung zu erhalten.

Wir sehen also, dass wir kurz davor sind, Funktionen zu bauen, die über Jahre hinweg Texte generieren können, aber es gibt noch ein paar Hindernisse auf unserem Weg. Diese Hindernisse werden wir in den nächsten Monaten nutzen, um Fortschritte sichtbar zu machen und unsere Entwicklung zu fokussieren, damit dies funktioniert – und zwar nicht nur auf Wikifunctions, sondern auch in der Wikipedia.

Ich hoffe, dass diese Gedanken uns sowohl als Reflexion darüber dienen, was wir in diesem Jahr erreicht haben, als auch darüber, wohin wir im nächsten Jahr gehen wollen.

Letzte Änderungen an der Software

Diese Woche ist die letzte Veröffentlichung in der Produktion vor Ende 2024, da Wikimedia eine Veröffentlichungssperre zum Jahresende hat, damit wir keinen Code bereitstellen, wenn viele Leute abwesend und nicht verfügbar sind. Die nächste Veröffentlichung in der Produktion danach wird um den 15. Januar 2025 herum erscheinen.

Wir haben den Datenbankcode hinter einigen unserer Spezialseiten so korrigiert, dass Objekte mit Diskussionsseiten nicht doppelt aufgelistet werden – danke Feeglgeef für die Meldung (T381003). Wir haben einige vorbereitende Datenbankarbeiten abgeschlossen, die es uns in Zukunft ermöglichen werden, Funktionen aufzulisten, die bestimmte Typen verwenden, sodass du Beispiele dafür finden kannst, wie andere sie verwendet haben; dies wird voraussichtlich irgendwann im nächsten Kalenderjahr der Fall sein (T301712).

Wir haben die Logik beim Laden von Inhalten aus der Datenbank angepasst, sodass ein klarerer, MediaWiki-üblicherer Fehler ausgegeben wird, wenn aus irgendeinem Grund etwas Ungültiges im Wiki gespeichert wurde (T381115). Wir haben außerdem bessere Tests für ungültige Z2K1-Werte hinzugefügt, die API daran gehindert, solche ungültigen Elemente zu verbergen, und einige Probleme behoben, die dazu führten, dass diese Art von fehlerhaften Inhalten schwer zu beheben war (T381972). In einem anderen Bereich haben wir uns gegen seltsame Fehler gewappnet, die durch ungültige Inhalte ausgelöst werden, wenn Seiten neu gerendert werden, um zu vermeiden, dass Produktionsprotokolle mit verwirrenden Warnungen gefüllt werden, die an die falschen Personen gehen (T380446).

Wir haben eine wiederverwendete i18n-Nachricht aufgeteilt, damit sie richtig übersetzt werden kann (T373745), und zwei alte, jetzt nicht mehr verwendete Nachrichten gelöscht, um unnötigen Übersetzungsaufwand zu vermeiden – Entschuldigung dafür!

Auf der Entwicklerseite haben wir die Version von JSDoc aktualisiert, die zum Generieren unserer (ziemlich begrenzten) Frontend-JS-Dokumentation verwendet wird, sowie den Phan-Static-Analysator unseres PHP und alle Wikimedia-Repos sind auf die neueren Versionen umgestiegen. Wir haben außerdem einen Fehler eines unserer Test-Werkzeuge deutlicher gemacht, als Teil der Vorbereitungen für die Aktualisierung unserer Tests, um eine modernere Version unseres Frontend-Frameworks abzudecken.

Wir haben Unterstützung für die Sprache Z1956/fvr zu Wikifunctions hinzugefügt, da sie zu MediaWiki hinzugefügt wurde (T381894).

Bitte benachrichtige uns wie immer, wenn du auf Probleme stößt.

Neuigkeiten bei Typen: Gleitkommazahlen mit doppelter Genauigkeit

Diese Woche führen wir den Typ Gleitkommazahl mit doppelter Genauigkeit ein, der unter Freunden auch als "Float64" oder einfach als "Float" bekannt ist. Im Gegensatz zu den anderen Zahlentypen, die wir bereits kennen – natürliche Zahlen, ganze Zahlen und rationale Zahlen – sind Gleitkommazahlen nicht unbedingt präzise. Stattdessen sind sie ein Kompromiss zwischen Präzision, Machbarkeit und Effizienz, der vor fast vierzig Jahren in einem Standard kodifiziert wurde.

Die 64 in Float64 gibt an, dass eine Gleitkommazahl in den meisten Programmiersprachen 64 Bits benötigt. Dies wird als Gleitkommazahl mit doppelter Genauigkeit bezeichnet: Einfache Genauigkeit benötigt 32 Bits und halbe Genauigkeit 16 Bits. Ich bin versucht, noch viel mehr über Gleitkommazahlen und all die coolen Funktionen zu erzählen, die sie haben, aber stattdessen verweise ich einfach auf den deutschsprachigen Wikipedia-Artikel als Ausgangspunkt.

Wozu sind Gleitkommazahlen auf Wikifunctions gut? Wir müssen sehen, wie sich die verschiedenen Zahlentypen bewähren. Ich gehe davon aus, dass wir für viele Berechnungen die Genauigkeit rationaler Zahlen bevorzugen. Der pragmatischste Ansatz zum Umgang mit irrationalen Zahlen ist jedoch die Verwendung der Näherung, die Gleitkommazahlen bieten. Ob wir es mit Wurzeln, Kreisen, Sinuswellen oder Logarithmen zu tun haben, sie sind mit den Zahlen, die wir bereits haben, oft schwierig oder unmöglich zu berechnen. Um dieses Problem zu lösen, ist jetzt ein neuer Typ verfügbar, der Näherung und Genauigkeit in Einklang bringt.

Ein großer Vorteil von Gleitkommazahlen besteht darin, dass sie standardisiert sind und der Standard weithin in Hardware implementiert und in vielen Programmiersprachen verfügbar ist.

Gleitkommazahlen werden uns möglicherweise dazu anregen, neue Muster beim Schreiben von Tests zu finden. Oft ist exakte Genauigkeit kontraproduktiv (ein klassisches Beispiel ist, dass in der Gleitkommaarithmetik 0,1+0,2 nicht gleich 0,3 ist), und für einige Funktionen möchten wir vielleicht Tests schreiben, die nicht auf exakter Gleichheit beruhen, sondern vielmehr darauf, zu prüfen, ob das Ergebnis nahe genug am erwarteten Wert liegt. Und das wird ein Muster sein, das für die komplexeren und interessanteren Typen, die uns in Zukunft erwarten, nützlich sein wird.

Der Newsletter macht eine Pause

Die nächsten Tage macht der Großteil des Teams wegen der Urlaubszeit zum Jahresende frei. Erwarte das nächste Update in der Woche vom 15. Januar 2025. Das erste Freiwilligentreffen des nächsten Jahres findet am 13. Januar 2025 statt. Wir wünschen allen friedliche Tage und sehen uns im neuen Gregorianischen Kalenderjahr!