Wikifunctions:Status-Updates/2024-09-20
| ◀ |  Wikifunctions Status-Updates  |
▶ |
|
Einführung von Fokus-Themenbereichen
Da wir der Möglichkeit immer näher kommen, Texte in natürlichen Sprachen zu generieren, denken wir darüber nach, thematische Fokusbereiche einzuführen. Wir haben bereits Fokussprachen, aber wir denken auch darüber nach, thematische Fokusbereiche einzuführen.
Wie wir bereits zuvor besprochen haben, erwarten wir von den Communities, dass sie mit der Abstrakten Wikipedia (mindestens) zwei verschiedene Arten von Artikeln erstellen: Einerseits werden wir hochstandardisierte Artikel haben, die größtenteils auf Wikidata basieren und als Modellartikel bezeichnet werden. Andererseits werden wir angepasste, von Hand erstellte Artikel haben, die Satz für Satz zusammengestellt werden.
Wir schlagen vor, (mindestens) zwei verschiedene thematische Fokusbereiche einzuführen: einen Fokusbereich für die Modellartikel und einen anderen Fokusbereich für die manuell geschriebenen Artikel. Die beiden verschiedenen Artikeltypen profitieren von unterschiedlichen Themenbereichen: Modellartikel eignen sich besser für Bereiche mit vielen einzelnen Objekten, die in Wikidata einheitlich beschreibbar sind, während manuell geschriebene Artikel besser für Themenbereiche geeignet sind, in denen sich jeder Artikel im Themenbereich stark von den anderen unterscheidet und die Objekte in Wikidata häufig eher leer sind.
Wir würden es vorziehen, Themenbereiche auszuwählen, die weder innerhalb einer Sprache noch über Sprachbarrieren hinweg besonders umstritten sind. Dies gilt insbesondere für den Ansatz mit Modellartikeln: Sowohl subtile als auch offensichtliche Unterschiede werden oft nicht sorgfältig genug geprüft, insbesondere wenn wir Tausende oder Millionen von Artikeln erstellen!
Wir würden einen Themenbereich bevorzugen, der Beiträge aus der ganzen Welt einlädt. Artikel über das Kabuki-Theater würden beispielsweise einen großen Beitrag zum Wissen der Welt leisten, aber wir erwarten, dass die meisten Beitragenden aus einem einzigen Land kommen und hauptsächlich eine Sprache sprechen würden.
Wir würden einen Themenbereich bevorzugen, der für die breite Öffentlichkeit von Interesse ist. Während Wikidata für seine Abdeckung von wissenschaftlichen Arbeiten oder astronomischen Objekten bekannt ist, scheinen beide Themenbereiche eine begrenzte Leserschaft zu haben, was auch den Wert des jeweiligen Themenbereichs begrenzt.
Vor diesem Hintergrund schlagen wir als Themenbereich für händisch erstellte Artikel Essen vor. Wir werden ein detaillierteres Status-Update darüber schreiben, warum Essen ein so großartiges Themengebiet ist, und falls es keine Vetos oder besseren Vorschläge gibt, werden wir dies als einen unserer beiden Fokusbereiche aufgreifen.
Für Modellartikel wünschen wir uns eine Diskussion, um zu sehen, was wir auswählen sollten: Die beiden offensichtlichsten Themenbereiche wären Siedlungen und Menschen, aber beide haben ein großes Streitpotenzial. Biologische Arten sind ein weiterer interessanter Themenbereich, aber oft viel komplizierter als erwartet. Es gibt viele andere interessante Themenbereiche, und wir würden uns freuen, deine Vorschläge, Gedanken und Überlegungen zu hören und eine Diskussion zu sehen.
Beachte, dass wir auf keinen Fall jemanden davon abhalten werden, Inhalte zu erstellen, die ihn interessieren. Du kannst Artikel zu den Themenbereichen erstellen, die dich interessieren, und es können Modellartikel oder manuell geschriebene Artikel sein. Der Fokusbereich dient lediglich dazu, dem Entwicklungsteam zu helfen, sich auf etwas zu konzentrieren und Erwartungen zu setzen, wenn wir als mit dir euch als Community zusammenarbeiten. Wenn du einen abstrakten Artikel über einen bestimmten Modetrend der 1980er-Jahre schreiben oder Modellartikel für Häkelmuster erstellen möchtest, kannst du dies gerne tun. Wir möchten dir nur helfen, unsere Priorisierung zu verstehen.
Bitte sag uns, welche Themengebiete aus deiner Sicht besonders sinnvoll wären, damit wir in den nächsten Wochen eine Vorentscheidung treffen können. Vielen Dank!
Neuigkeiten zur Instabilität der Seite
Wir hatten einen anhaltenden Vorfall, über den wir bereits im Update der letzten Woche berichtet haben. Gemeinsam mit unseren Kollegen im SRE haben wir eine ganze Weile versucht, herauszufinden, was los war, und konnten es nicht. Am frustrierendsten war, dass wir die Probleme aus der Produktion in keiner anderen Umgebung reproduzieren konnten, was die Fehlerbehebung wirklich schwierig machte.
Das Problem trat auf, als bei etwa 10–20 % der Funktionsseiten eine Zeitüberschreitung auftrat, außerdem zahlreiche Test- und Implementierungsseiten fehlschlugen und andere Probleme auftraten. Alle Tests schlugen durchgängig fehl. SRE wurde so oft benachrichtigt, dass sie die Überwachung von Wikifunctions abschalten mussten.
Wir haben unser Verfahren für Vorfälle gestartet und die dem Problem gewidmeten Ressourcen kontinuierlich aufgestockt. Wir haben mehrere mögliche Ursachen gefunden, aber da wir das Problem nicht lokal reproduzieren konnten, war der Versuch, es zu beheben, oft ein frustrierender Zyklus aus Einführungen in der Produktion und der Überprüfung, ob dies geholfen hat. Ab sofort hoffen wir, dass sich die Seite erholt hat. Während wir unser Netz weiter auswarfen, konnten wir eine Änderung an Wikifunctions finden, die bei bestimmten Prüfungen eine Endlosschleife verursacht zu haben schien. Wir konnten diese Änderung rückgängig machen.
Wir untersuchen noch immer, wie diese Änderung zu solch großen Auswirkungen führen konnte, warum wir dieses Problem nicht früher erkannt haben und was wir tun können, um sicherzustellen, dass wir nicht wieder in eine ähnliche Situation geraten. Wenn du weiterhin Zeitüberschreitungen auf der Seite bemerkst, lass es uns bitte wissen.
Vielen Dank an alle für eure Geduld. Wir entschuldigen uns dafür, dass wir noch etwas vage sind, aber wir möchten zunächst die Grundursache des Problems besser verstehen, bevor wir einfach zugänglich machen, wie man die Seite erneut beschädigen kann. Wir verstehen, dass einige von euch jetzt problemlos auf der Seite nachsehen könnten, um Einzelheiten herauszufinden, aber wir möchten dich bitten, dieses Wissen noch nicht zu weit zu verbreiten. Wir planen, in den kommenden Wochen etwas mehr dazu zu sagen, sobald wir etwas mehr Zeit hatten, die Grundursache zu verstehen. Vielen Dank für deine Geduld!
Funktion der Woche: Caesar-Verschlüsselung in Bengali
Über die Caesar-Verschlüsselung hatten wir bereits in der Funktion der Woche gesprochen. Es handelt sich dabei um eine alte Form der Kryptographie, bei der jeder Buchstabe um eine bestimmte Anzahl von Positionen verschoben wird. Traditionell wird sie auf Texte angewendet, die im lateinischen Alphabet geschrieben sind.
Ein großer Vorteil von Wikifunctions ist, dass wir problemlos neue Funktionen erstellen und bereitstellen können, sogar Funktionen, die noch nicht implementiert wurden, und sie jedem auf der Welt (oder zumindest jedem mit Internetzugang) zur Verfügung stellen können. Auf diese Weise können unsere Beitragenden Funktionen erstellen, über die wahrscheinlich nachgedacht wurde, die aber noch keine weit verbreitete Implementierung erfahren haben: So könnte man beispielsweise die Idee der Caesar-Verschlüsselung auf andere Alphabete anwenden.
Und genau das haben wir in unserer aktuellen Funktion der Woche: Sie wendet die Idee der Caesar-Verschlüsselung - das Verschieben von Buchstaben entlang eines gegebenen Alphabets - auf das bengalische Alphabet an. Das bengalische Alphabet ist eine Schrift des indischen Subkontinents, die seit gut tausend Jahren und in zahlreichen Sprachen verwendet wird, darunter klassische Sprachen wie Sanskrit und lebende Sprachen wie Bengalisch mit mehr als einer Viertelmilliarde Sprechern.
Die Funktion Z17530 verwendet zwei Argumente: die zu kodierende bengalische Zeichenkette und den Verschiebungswert, eine Zahl, die angibt, um wie viele Buchstaben die Verschiebung erfolgen soll. Die Ausgabe ist eine Zeichenkette, die die kodierte bengalische Eingabe darstellt.
Derzeit gibt es eine Implementierung in Python, die auf einem Array mit dem bengalischen Alphabet basiert und dann die eingegebene Zeichenkette durchgeht, um jeden Buchstaben durch den verschobenen Buchstaben zu ersetzen.
Die Funktion hat sechs Tests:
- Verschieben von অআকখ um 2 ergibt ইঈগঘ
- Verschieben von ক um 38 ergibt অ
- Verschieben von হ um 1 ergibt ড়
- Verschieben von অ um 49 ergibt অ (d. h. dass wieder der ursprüngliche Wert erreicht wird)
- Verschieben von য় um 1 ergibt ৎ
- Verschieben von অ um 11 ergibt ক (was die Umkehrung des zweiten Tests ist)
Die vorhandene Implementierung besteht alle sechs Tests.
Die Tests sehen toll aus und decken einige interessante Fälle ab (wie die Verschiebung auf den ursprünglichen Wert oder eine Umkehrung). Ich würde Tests für eine Verschiebung um null hinzufügen, für eine Verschiebung über 49 hinaus (z. B. für 98 oder für 100) und mehr Wörter statt einzelner Buchstaben verschieben, einschließlich Buchstaben und Zeichen, die nicht im bengalischen Alphabet vorkommen. Es wäre auch gut, mehr als nur eine Implementierung zu haben.
Aber das wirklich Interessante ist, dass dies eine weithin verfügbare Implementierung der Caesar-Verschlüsselung für ein Alphabet bietet, für das dies zuvor nicht weithin verfügbar war. Ich freue mich darauf zu sehen, welche anderen Funktionen wir in neuen Kontexten verfügbar machen können und ob sie Anklang finden.