Auf den Adminanfragen kannst du Wikipedia-Administratoren um Hilfe bitten, wenn dein Anliegen zu keiner anderen Seite passt. Diese Seite ist nicht der richtige Ort, um auf aktuelle Konflikte zwischen Benutzern (dazu gibt es die Vandalismusmeldung) oder möglichen Missbrauch von Administratorrechten (siehe Wikipedia:Administratoren/Probleme) aufmerksam zu machen.
Jeder Benutzer kann durch sachbezogene Kommentare beitragen. Allgemeine Betrachtungen, Nachtreten (gegenüber dem Antragsteller oder anderen Benutzern) usw. gehören nicht auf diese Projektseite und werden entfernt.
Warum Benutzerkonten nicht gelöscht werden können, erfährst du in den FAQ, und wie du ein Konto stilllegen kannst, unter Hilfe:Benutzerkonto stilllegen.
Ist das die richtige Seite für mich?
Für viele Aufgaben gibt es separate Anlaufstellen, siehe hierzu die Infobox „Hilfreiche Links“ rechts.
Auf dieser Seite bist du richtig, wenn du zum Beispiel
eine Artikelversion aus einem anderen Grund als Urheberrechtsverletzung zur Löschung vorschlagen willst,
Text, Bearbeiter oder Bearbeitungskommentar einer versteckten Version wieder sichtbar machen lassen möchtest,
sonst irgendetwas machen möchtest, von dem du glaubst, dass man dafür Adminrechte braucht, und das nicht in der Box „Hilfreiche Links“ rechts steht.
Wie lege ich einen neuen Abschnitt an?
Über den Link unten öffnet sich ein Bearbeitungsfenster, in das du deine Anfrage eintragen kannst. Verwende bitte eine sinnvolle Überschrift im Betreffsfeld und beschreibe die Situation möglichst sorgfältig. Insbesondere sind Links auf Bearbeitungen (Diff-Links) und Logbücher erwünscht. Sofern es notwendig und dir möglich ist, versuche Vorschläge zu machen, wie die Situation gelöst werden könnte.
Mit dem {{Erledigt|1=--~~~~}}-Baustein markierte Abschnitte werden zwei Mal täglich archiviert, nicht erledigte Abschnitte werden dagegen sieben Tage nach dem neuesten Beitrag automatisch ins Archiv verschoben (aktuelles Archiv).
Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 7Tage zurückliegt und die mindestens einen signierten Beitrag enthalten.
@Johannnes89: Da du an der Implementierung mitgewirkt hast, wirst du es auch am ehesten für uns konfigurieren können.
Wir hatten das ja kürzlich bereits angerissen.
Den dussligen : hätte ich gern sofort ersetzt bekommen durch ref- für: <refname="ref-1">
Ob es ganzer eigener Module bedarf, weiß ich nicht.
|Datum= und |datum= liegen uns zwar weitgehend in ISO vor, was von {{#time:Y|datum}} verstanden wird, nebst ausgeschriebenem echtem lokalem Datum, die Vorlagen akzeptieren jedoch klaglos eine Vielzahl anderer Formate.
Vorlage:Datum verstünde bei allen gültigen: {{Datum|datum|Y}}
Den ersten Familiennamen aus einer Komma-getrennten, notfalls Semikolon-getrennten Aufzählung von 14 Beteiligten einer akademischen Publikation herauszufischen, deren 8.Nobelpreisträgerin ist, würde ich mit einer neuen Funktion in Modul:Text bewerkstelligen wollen, denke heute über Nacht nochmal genauer.
Danke im Voraus --PerfektesChaos 14:13, 14. Okt. 2026 (CEST)
Eine Nacht drüber schlafen, und erstmal denken und verdauen und träumen, hat sich als Strategie bewährt.
Bei Internetquelle ist url Pflichtparameter.
Bei Literatur ist Titel Pflichtparameter; Autor und Datum sind optional.
Ergebnis: Kommt drauf an. Erster Familienname, falls Autor; mit Jahreszahl, falls Datum – ohne Autor längstes Wort im Titel (insbesondere wenn mit Großbuchstaben beginnend).
Vermutung: An den sprechenden Bezeichner wird ohnehin eine noch nicht verwendete -1-2-3 drangehängt, weil es das ja mit unterschiedlichen Bandnummern, Seitenzahlen oder mehrere im Jahr geben könnte.
Danke für Ping, genau in die Richtung hatte ich auch gedacht und im testwiki auch schon ein wenig mit nem Modul rumgespielt, auf den ersten Blick passt dein Vorschlag für mich. Frwiki hat in sehr ähnliche Richtung gedacht mit fr:Module:NomRefAuto, vielleicht können wir uns davon auch inspirieren lassen? --Johannnes89 (Diskussion) 19:28, 14. Okt. 2026 (CEST)
Ok ich hab im betawiki weiter getestet, mir auch die Implementation in frwiki & ruwiki angeschaut und bin nun über den Vorschlag hinaus gegangen, aus verschiedenen Gründen:
Nicht alle EN nutzen Literatur/Internetquelle, wir sollten auch für den (vergleichsweise seltenen, aber möglichen) Fall vorbeugen, dass jemand Vorlagen wie Cite web, Cite book, Webarchiv usw. nutzt.
Ich hab zudem noch mehr Fallbackoptionen bei den Vorlagenparametern eingebaut, um das Risiko von vergleichsweise schlechten Namen zu reduzieren. Im Idealfall ist der Name stets "Nachname-Jahr" oder (falls kein Datum/Jahr verfügbar) nur "Nachname", außer bei Internetquelle, wo zuerst versucht wird, die URL zu extrahieren, bevor "Nachname-Jahr" der Fallback wird.
Wenn auch die weiteren fallback-Optionen nichts produzieren, wird halt kein inhaltsbasierter EN-Name erstellt, sondern ein simpler Fallbackname (dazu unten).
Das findet sich nun in Modul:VisualEditorRef abgebildet, aus dem sich {{Autoname}}, {{AutonameInternetquelle}} und {{AutonameLiteratur}} bedienen. Diese Seiten hab ich erstmal auf Sichterlevel geschützt, wahrscheinlich werden wir am Anfang ja vielleicht noch manches anpassen, danach sollte es am besten auf Adminlevel geschützt werden, um versehentliche Änderungen der VE ref name pattern zu vermeiden.
In Benutzer:Johannnes89/Autorefnames hab ich zahlreiche Beispiele erstellt, welche EN-Namen so entstehen würden (die Zahl wird dann bei echten Einzelnachweisnamen automatisch angehängt – in der Tat um Fälle von ungewollt doppelten EN-Namen zu vermeiden und die automatischen Namen leichter identifizierbar zu machen, falls es ein Problem gibt).
Dann habe ich MediaWiki:Cite-autoname-template-map.json erstellt, die zuordnet, dass für Literatur/Internetquelle die jeweils speziell definierten Vorlagen genutzt werden sollen und für sonstige Vorlagen in Einzelnachweisen {{Autoname}}. Sollten sich mehrere Vorlagen in EN befinden, wird künftig übrigens stets die erste Vorlage dahingehend ausgewertet, ob sie Parameter enthält, die für inhaltsbasierte EN-Namen nutzbar sind.
Bei den simplen Fallbacknamen (nötig für EN ohne Vorlage oder Vorlagen, bei denen keine Inhalte für den Namen genutzt werden konnten) bin ich von <refname="ref-1">, <refname="ref-2"> usw. immer noch nicht ganz überzeugt. Ist zwar schön kurz, aber lässt sich das gut erfassen? <refname="Einzelnachweis-1">, <refname="Einzelnachweis-2"> usw. ist in meinen Augen besser lesbar und vermeidet so Fehler. Entsprechend habe ich MediaWiki:Visualeditor-cite-tool-name-book-autoname und MediaWiki:Visualeditor-cite-tool-name-web-autoname erstellt, damit ist der simple Fallback einheitlich bei EN mit und ohne Vorlage (andernfalls gäb es auch noch simple Fallbacks wie "Buch-1" und "Website-1", das ist nun nicht mehr der Fall). Lässt sich natürlich auch alles noch ändern, falls alle anderen doch <ref name="ref-1"> besser finden.
Und nachdem ich all das geschrieben hatte und überlegt hatte, erst noch weiter zu testen, kam ich zum Entschluss, dass PC recht hat und wir so schnell wie möglich die alten <refname=":1"> loswerden sollten. Deshalb hab ich nun per Spezial:CommunityConfiguration/Cite-VisualEditor-Autonames / MediaWiki:Cite-VisualEditor-Autonames.json das neue Namensschema aktiviert. Idealerweise ist es inhaltsbasiert (z.B. <refname="Obama2026-1">), bei EN ohne Vorlagen (oder EN deren Vorlagen keinen unterstützten Parameter nutzen) wird der Name dann <refname="Einzelnachweis-1">. Ändern können wir das ja weiterhin noch (oder auch wieder deaktivieren und erstmal die alten Namen nutzen, sollte ich nen groben Fehler übersehen haben – aber das denke ich eigentlich nicht mit Blick auf die Tests in Benutzer:Johannnes89/Autorefnames).
Um möglichen Fragen vorzugreifen: Bestehende EN-Namen werden von der Änderung nicht erfasst. Und sobald einmal gespeichert ändert sich der durch VE generierte Name auch nicht mehr, nur weil man (egal ob im Wikitext oder VE) was am EN-Inhalt ändert (und wie immer kann man natürlich auch die EN-Namen im Wikitext weiter anpassen, wenn das VE-Ergebnis mal suboptimal war, z.B. nur der simple Fallbackname herauskam. Ebenfalls nicht erfasst werden Edits, wo jemand schon auf "Bearbeiten" gedrückt hat, bevor die Änderung wirksam wurde, deshalb können zunächst noch ein paar alte Namen noch auftauchen. --Johannnes89 (Diskussion) 18:09, 15. Okt. 2026 (CEST)
Da haben wir uns ggf. wunderhübsch überkreuzt.
Ich habe letzte Nacht bereits eine Implementierung auf die Festplatte geschrieben.
Ich weiß jetzt nicht so genau, ob dein Modul administrativ definitiv produktiv sein soll, oder „im testwiki auch schon ein wenig mit nem Modul rumgespielt“ mehr als Fingerübung gedacht war.
Nun arbeite ich ungern für die Tonne.
Diese Kollision müsste jetzt erstmal geklärt werden.
Unnötig zu erklären, dass ich meine Programmierung als vielfach besser, robuster, performanter bei noch mehr Funktionalität einschätze.
Es ist global konzipiert, abstrahiert also von den Verhältnissen der deWP, kann auch in allen anderen Wikis genutzt werden.
Dadurch wird es letztlich auch einfacher und robuster und viel kürzer und gibt sich nicht mit so vielen Spezialitäten ab.
Bei dir sehe ich etliches, was ich meine per Kunstgriff vermeiden zu können.
Zum generellen Verständnis, das aus mw:Help: nicht so restlos hervorgeht, und ich mir bislang zusammengereint habe:
Der ref-Inhalt wird nach dem im JSON angegebenen Namen der Zitationsvorlage durchsucht, und falls gefunden dann mit dem allerersten Treffer die zuordnende autoname-Vorlage mit allen deren Parameterwerten aufgerufen?
Richtig?
Ich habe keine fr- oder ru-Module durchgelesen.
getHost@URLutil hatte ich schon vor einem Dutzend Jahren ohne Vorbilder geschrieben.
Ich komme auch mit einer einzigen Vorlage und notfalls einer Unter-Vorlage aus; je weniger involviert sind und einzeln dokumentiert werden, desto simpler.
Es gibt keine sinnvollen Belege mit eins von diesen dreien, wo url fehlen würde, und deshalb nur extremst selten mal ein Fallback. Hingegen ist host/ dann der anzustrebende und bei sehr vielen Fällen hinreichend gute Bezeichner. Die laufende Nummer kann dann nur im Kontext des gesamten Artikels und aller anderen geplanten oder vorhendenen Belege dieses host und des hier charakteristischen Schlagworts für genau diesen Beleg händisch ausgetauscht werden.
Bei allen anderen wäre Familienname/Jahreszahl/ der anzustrebende Bezeichner, und wenn keiner gefunden wird, dann das längste und möglichst mit Großbuchstaben beginnende Wort im Titel der Publikation. Der ist wieder Pflichtparameter, und nur wenn ausnahmsweise auch kein Wort gefunden wird, käme Fallback zum Zuge.
Das passt auf alle lateinisch, kyrillisch und griechisch geschriebenen Sprachen; mutmaßlich auch arabisch und hebräisch und diverse mehr.
Das „Sammelwerk“ ist dann nicht mehr erforderlich, weil der „Titel“ des offenbar anonym verfassten Aufsatzes schon hinreichend unterscheidend wirkt. Wobei ein Artikel zum Thema „Giggelblonk“ auch mehrere anonyme Aufsätze zitieren mag, die „Giggelblonk“ im Titel enthalten. Die „Herausgeber“ usw. sind überflüssig und retten einen kaputten Beleg dann auch nicht mehr; es sind häufig Institutionen mit ellenlangem Namen und hier ungeeignet: „Verein für Brauchtumspflege und Ortsverschönerung Oberbachem e.V.“
Der Bezeichner soll intuitiv selbsterklärend sein, aus welcher Richtung dieser Beleg kommt; er soll aber auch möglichst kurz und übersichtlich sein. Besser als :1 wird das schon; aber darf den Quellcode auch nicht inakzeptabel aufblähen.
Der Begriff „Einzelnachweis“ darf nicht im automatisch generierten Bezeichner auftreten; sonst gibt es sofort ein projektweites Drama, dass es „Quelle“ oder „Beleg“ oder „Einzelbeleg“ heißen müssen; das Wort ist auch viel zu sperrig, siehe eins vor.
Hab ohne deine Version zu kennen keinen Zweifel, dass sie insbes. bei der Domain-Extrahierung besser sein dürfte und bestimmt auch sonst robuster usw. Prinzipiell also gerne deine Variante.
Deine Beschränkung auf url, autor+jahr und titel halte ich aber für zu kurz gegriffen. Bereits jetzt hab ich ein Beispiel gefunden, wo weitere Fallback-Parameter sinnvoll wären, um tatsächlich nen inhaltsbasierten Namen zu erhalten (|Eintrag= als Fallback für |Titel=), weil manche EN nunmal auch andere Vorlagen nutzen. Und auch bei der Literatur-Vorlage sieht man, dass manche User wirklich nur sehr wenige Felder ausfüllen – sonderlich gut finde ich die Nutzung des längsten großgeschriebenen Wortes aus dem Titel da nicht.
Genau aus dem Grund will ich also mehr als nur ein paar wenige Parameter der beiden Standard-Einzelnachweisvorlagen covern – über die verschiedenen Varianten zum Autorenfeld und Datum/Jahr, die verschiedenen Varianten zu Werk und Hrsg sowie verschiedene Varianten zu URL und Titel sind auch cite book, cite new, cite journal und viele weitere Vorlagen sicher erfasst.
Titel ist in meinen Augen eher nachrangig einzuordnen – wenn |Autor= nicht verfügbar ist, nehm ich doch viel lieber |Hrsg= + |Datum= anstatt direkt nen potentiell schlechten Namen aus dem Titel zu pflücken? Was passiert z.B., wenn jemand die URL auch in den Titel packt?
An Sammelwerk häng ich nicht besonders. Ich hab halt geschaut, aus welchen Parametern sich potentiell sinnvolle Namen generieren lassen und wollte beim Fallbackchain nicht sparsam sein, weil es ja immer sein kann, dass irgendeine mir gerade unbekannte Vorlage einen so benannten Parameter nutzt und somit zufällig von der Autoname-Implementierung erfasst wäre. Das halte ich für besser, als weiterhin einige Namen, die nichts zum Inhalt sagen.
Was den simplen Fallbackbegriff betrifft: Wir könnten ja auch erstmal abwarten, ob sich jemand beschwert und notfalls dann ändern;) Klare Lesbarkeit hätte da für mich Prio. Falls unbedingt "ref1", dann lieber "Ref1", um es optisch von der eigentlichen ref-syntax abzuheben. Aber in meinen Augen signalisiert ein ganzes Wort wie "Einzelnachweis-1" auch deutlich mehr, dass man den Namen ersetzen kann, das dürften unerfahrene Wikitextuser bei <ref name="ref1"> weniger schnell realisieren.
Diejenigen, womöglich als Newbies nur das VE-Formular sehen.
Alle Quelltext-Bearbeitenden, die sich permanent darüber ärgern, dass es ein unnötig langes Wort, und obendrein eine missliebige Vokabel, überall in den Quelltext eingestreut bekommt, und niemand die Möglichkeit hat, das überall abzuändern, ohne Gefahr zu laufen, dass es dann zu einem Zuordnungsfehler kommt. Und auch niemand diese administrativ aufgezwungene Extra-Editier-Nacharbeit haben will.
Und die zweiten sind die lauteren.
Man könnte ja auch mal aus den letzten Jahrzehnten was lernen, wie Angelegenheiten geschmeidig laufen, statt vorsätzlich einen Protest auszulösen (hiermit amtlich zu Protokoll gegeben) und erst einem Volksaufstand weichen zu wollen.
Und für die ersteren wird sich ref-3 im Eingabeformular mit der Zeit lernen lassen.
Während die zweiten <ref name="ref-3"> im Quelltext sehen, und ein und dasselbe Schlüsselwort ref klarmacht, wie es gemeint ist, und niemand nochmal eine willkürliche zweite Notation dafür zusätzlich erlernen muss.
»manche User wirklich nur sehr wenige Felder ausfüllen«
Mag ja sein; aber Titel ist Pflichtparameter, und es gibt im Bestand nur extrem wenige Einbindungen ohne, weil sofort die Vorlagenwartung aufschlägt, und versucht irgendwie zu erraten, was da gemeint wurde, vielleicht in den falschen Parameter geschrieben, oder anhand von ISBN DOI URL usw. zu rekonstruieren.
Du kannst also davon ausgehen, dass praktisch immer, wenn die Wiederverwendungs-Situation eintritt, der Titel definiert ist.
»um tatsächlich nen inhaltsbasierten Namen zu erhalten«
Du hast da aber keine KI am Start.
Was in welchem Einzelfall das intelligenteste charakteristische Schlagwort wäre, kann nur händisch-menschlich beurteilt werden; automatisch mit schlichtem Algorithmus ist das nicht feststellbar.
In aller Regel ist der Titel des Aufsatzes, des Buches, dieser anonymen Publikation auch der charakteristische Bezeichner für genau diese einzelne Publikation. Oder ein Familienname, auch okay.
Das soll aber auch möglichst kurz sein; ein ellenlanger Werktitel, womöglich einer wissenschaftlichen Arbeit, wäre weder im VE-Formular noch im Quelltext akzeptabel.
Die ganzen kurzen Wörter, es am zu ein der die das von auf, sollen da rausgeschmissen werden.
Ein möglichst langes Wort im Titel ist auch besonders charakteristisch und auffällig für diesen anonymen Aufsatz; im Deutschen bei Großschreibung vermutlich ein wichtiges Substantiv.
»die verschiedenen Varianten zu Werk und Hrsg […]«
Wenn es bei Internetquelle, Webarchiv, cite web eine gültige url als Pflichtparameter gibt (deren Fehlen oder Ungültigkeit eine Wartungskat auslöst und den Putzdienst herbeiruft), dann ergibt sich daraus die wesentliche Domain, damit ist der Bezeichner bereits endgültig festgelegt, und alle weiteren Überlegungen zu irgendwelchen anderen Parametern laufen komplett ins Leere.
Der Werktitel ist Pflichtparameter bei allen Literatur, cite book, cite new, cite journal, und wenn aus dem erstmal das wichtigste Wort, das genau diesen einen anonymen Aufsatz kennzeichnet, glücklich herausfiltriert wurde, dann ist die Suche nach dem Bezeichner abgeschlossen.
Im Artikel können am Dutzend lauter verschiedene Aufsätze desselben Periodikums zitiert werden. Die haben alle verschiedene Werktitel. Würde man sowas als Bezeichner wählen, dann haben alle Aufsätze den gleichen Basis-Bezeichner. Im Übrigen sind die Namen von Zeitschriften oft extrem lang (Mitteilungen des historisch-geografischen Instituts der Fritze-Willi-Universität zu Berlin), weshalb ein Sammelwerk oder journal wegen übermäßiger Länge weder für das VE-Formular noch für den Quelltext geeignet ist. Und ein Hrsg mit Christian-Albrechts-Universität zu Kiel bringt auch keine Verbesserung mehr.
Es kann natürlich die Situation auftreten, dass ein wichtiges langes Wort mit Bezug zur Artikelthematik in mehreren Aufsätzen das längste ist; Pech. Es geht um einen simplen Algorithmus, und keine KI.
Weil du oben den hier verlinkt hast und dich zu»|Eintrag= als Fallback für |Titel=«ausgelassen hast:
Wir haben um die 15.000 Vorlagen, die als Zitationsvorlage in Frage kommen, darunter 4000 BibISBN.
Die haben auch extrem verschiedene Parameterkonzepte; alle die eine neue Vorlage bauen dürfen hier machen was immer sie wollen, die VWS hat keinerlei Weisungsbefugnis.
Auch über * lassen sich nicht sämtliche Parametermodelle abbilden.
Für eine Handvoll Universal-Zitationsvorlagen wie Internetquelle, Literatur und womöglich noch eine Handvoll cite lässt sich sowas aufbauen und pflegen. Das sind solche mit Zigtausenden von Artikeln, in denen sie verwendet werden. Alle Vorstellungen darüber hinaus werden am Baum landen. Das von dir zitierte righteous.yadvashem.org ist in 65 Artikel eingebunden.
Es muss für die große Masse an Belegen ein möglichst kurzer Bezeichner mit simplem Lua aufgefischt werden, der sich von möglichst vielen anderen Bezeichnern unterscheidet, und assoziieren lässt, um welche der Publikationen es geht.
Natürlich kann es sein, dass ebendiese Internet-Domain häufig in diesem Artikel refenziert wird. Kann auch sein, dass diese Domain nur einmal im ganzen Artikel vorkommt. Schicksal. Wir sehen nur den einen einzelnen ref vor uns, und müssen mit einer wartungsfähigen Implementierung und einem von den Enkeln begreifbaren Algorithmus einen sehr kurzen Bezeichner finden, der hoffentlich eindeutig nur diese eine Publikation erratbar kennzeichnet.
Ich seh deinen Punkt bei Werk/Herausgeber, aber man könnte ja auch wie beim Titel ebenfalls versuchen, da das längste Wort oder was anderes sinnvolles rauszufiltern. Mein Modul schaut z.B. bereits jetzt bei |werk= ob sich eine Domain extrahieren lässt und nimmt sonst (wie beim Titel) das längste Wort. Damit bekommt man auch da schöne Ergebnisse (Beispiel )
Natürlich sind wir keine KI und können nicht für alle 15.000 Vorlagen mitdenken. Aber zum Glück nutzen viele Vorlagen ja identisch (oder fast identisch) benannte Parameter. Wenn also das Modul typische Parameter wie Autor (+Datum/Jahr), Titel, Werk, Herausgeber... in verschiedenen denkbaren Schreibweisen (und auch auf Englisch) abdeckt, erreicht man schon recht viele dieser Vorlagen (nebenbei bemerkt hätte ich persönlich auch nichts dagegen, später stückweise weitere Parameter zu ergänzen, wenn nicht-abgedeckte edge cases auffallen).
Und dann müssen wir die Namen all dieser Vorlagen weder kennen, noch uns sonst darum groß Gedanken machen. Im JSON kann man (wie es jetzt auch konfiguriert ist) ja festlegen, dass eine Autoname-Vorlagen auf sämtliche Vorlagen angewendet werden soll, die sich in Einzelnachweisen finden lassen, sofern nicht ebenfalls im JSON definiert ist, dass für spezielle Vorlagen spezielle Autoname-Vorlagen genutzt werden sollen. So kann man mit wenig Aufwand zumindest den Versuch betreiben, auch bei weniger typischen EN-Vorlagen (an die man womöglich gar nicht gedacht hat) nen sinnvollen Namen zu erstellen.
Ich muss somit righteous.yadvashem.org gar nicht im JSON aufzählen, sondern nur (zufällig oder absichtlich) in der Autoname-Vorlage (bzw. dem Modul) nen Parameter definiert haben, der in dieser Vorlage genutzt wurde.
Ebenso muss ich auch künftige Vorlagen nicht mitdenken – entweder nutzen die einen der Parameter in einer der Schreibweisen, die man als Fallbackchain definiert hat, oder man hat halt Pech. Aber durch etwas mehr definierte Fallbackoptionen bei den Parametern kann man ja zumindest die Wahrscheinlichkeit erhöhen, dass es klappt...
Auch bei Wartbarkeit sehe ich keine Probleme – das ist ein Grund, weshalb ich in meinem Implementierungsvorschlag Internetquelle & Literatur separat definiert hab: Bei den beiden Vorlagen wollen wir ganz genau wissen (und das auch zuverlässig warten und testen), wann welcher Autoname erstellt wird. Bei quasi allen anderen Vorlagen ist es ideal, wenn es klappt, aber natürlich verkraften wir es auch, wenn doch zum Fallbacknamen gegriffen werden muss.
Praktischerweise haben wir eine Auswertung, welche Vorlagen am häufigsten in EN eingebunden sind – mir geht es insbesondere darum, sich zumindest Gedanken zu machen, die Top20 zu erwischen (tut mein Modul auch nicht vollständig, weil manche Vorlagen sich nicht für ref name eignen, aber angesichts der vielen Möglichkeiten direkt einfach nur auf Literatur, Internetquelle und Cite XY abzustellen, halte ich für falsch.
Ich vergaß, deine generelle Frage zu beantworten: VisualEditor schaut, ob im EN eine Vorlage ist.
Falls nein -> simpler fallback name.
Falls ja, wird die erste gefundene Vorlage evaluiert (um nicht zu viele API-Calls zu senden, zumal die erste Vorlage idR die Belegvorlage sein dürfte bei EN, die mehrere Vorlagen enthalten).
Dabei wird geschaut, ob in MediaWiki:Cite-autoname-template-map.json eine Autoname-Vorlage für die jeweilige (Beleg-)vorlage hinterlegt ist (* = default für alle Vorlagen, außer für solche, die extra definiert sind). Falls nein, greift der simple fallback name.
Wenn es eine passende Autoname-Vorlage gibt, wird geschaut, ob diese Autoname-Vorlage einen oder mehrere Parameter definiert, die in der im EN gefundenen Vorlage genutzt werden. Wenn ja, wird gemäß "Anweisung" der Autoname-Vorlage (oder des zugehörigen Moduls) der inhaltsbasierte ref name erstellt. Falls nein, greift erneut der simple fallback name.
„wird geschaut, ob diese Autoname-Vorlage einen oder mehrere Parameter definiert“
ist mir das immer noch nicht präzise und verständlich genug.
ist es überflüssig. Es wurde in JSON definiert, dass bei Zitationsvorlage X die autoname-Vorlage Y angewendet werden soll.
Dann kann die autoname-Vorlage Y mit allen Parametern aufgerufen werden, die in Zitationsvorlage X einen Wert (notfalls sogar leer) zuweisen.
Es wurde in JSON definiert, dass für X die Y benutzt werden soll; dann darf ungeprüft unterstellt werden, dass Y mit einigen dieser Parameter was anfangen kann. Wenn nicht, dann ist es denen ihr Problem. „geschaut, ob“ braucht es nicht.
Nee eben nicht: Im JSON kann sinnvollerweise definiert werden, eine Autoname-Vorlage bei sämtlichen EN-Vorlagen anzuwenden, sofern nicht definiert ist, für bestimmte EN-Vorlagen eine eigene Autoname-Vorlage zu nutzen. So kann man zumindest den Versuch unternehmen, unsere tausenden Vorlagen abzudecken. Gleichzeitig kann dann halt nicht "ungeprüft unterstellt werden", dass die Autoname-Vorlage was mit irgendeinem Parameter anfangen kann, das wird bei weniger häufig genutzten EN-Vorlagen einfach (willkommener) Zufall sein.
Noch was anderes zur technischen Implementierung, was ich vergaß zu erwähnen: Nur die Zahl wird automatisch vergeben, weil verschiedene Wikis verschiedene Präferenzen haben könnten, ob sie "Obama2026-1", "Obama2026_1" o.Ä. haben wollen (vielleicht auch "Obama2026-1", aber ohne Jahr dann "Obama1"). Das muss also auch über die Vorlage bzw. das Modul definiert werden. Beim Testen im Betawiki hatte ich zunächst dran gedacht, den Bindestrich wirklich nur bei Jahreszahlen zu nutzen, aber "tagesschau.de1" sieht in meinen Augen schlechter aus als "tageschau.de-1", deshalb sorgt Modul:VisualEditorRef nun einfach überall für nen Bindestrich, wie man auch bei den Beispielen in Benutzer:Johannnes89/Autorefnames sieht. --Johannnes89 (Diskussion) 08:03, 16. Okt. 2026 (CEST)
Und warum wird das, was du jetzt darlegst, nicht für die Umsetzenden und Pflegenden in all den Wikis präzise und konkret auf mw:Help: dargestellt?
Bislang steht da einfach nur, man könne einige autoname-Vorlagen spezifizieren, und die würden dann aufgerufen.
Mit welchen Parametern, wird nicht ausgesagt.
»um nicht zu viele API-Calls zu senden« 23:37, 15. Okt.; »wird geschaut, ob diese Autoname-Vorlage einen oder mehrere Parameter definiert, die in der im EN gefundenen Vorlage genutzt werden«
Wozu soll das denn nötig sein??
Im ref ist {{HMBL |a=Ding |b=Dong}} eingebunden.
Der HMBL ist autoname via JSON zugeordnet.
Also wird ausgewertet: {{autoname |a=Ding |b=Dong}} und dessen Ergebnis ist der Basis-Bezeichner.
Ob da irgendwas „definiert“ sei, egal ob in Vorlage:autoname oder Vorlage:HMBL und deren TemplateData, ist völlig egal.
autoname wird mit a und b aufgerufen, und damit fertig.
Wenn autoname das kennt und irgendwas damit anstellt, passiert was. Wenn sie unbekannt sind, dann passiert halt nix. Warum muss da zuerst „geschaut“ und „definiert“ und „API-Calls“ werden???
Mal abgesehen davon könnten auch mit getParent().args die Aufrufparameter von autoname ausgewertet werden, ohne dass sie im Programmierungs-Quelltext von autoname „definiert“ würden.
Ich kann sehr wohl »dann halt nicht "ungeprüft unterstellt werden"«– doch, sie wird mit sämtlichen Parametern aufgerufen, und die mit denen sie was anfangen kann, werden ausgewertet, und alle unbekannten bleiben halt wirkungslos. Ist seit zwei Jahrzehnten immer schon so und teils bewusst zur Hinterlegung praktiziert. Wo soll das Problem sein? Wer muss zu welchem Zweck da irgendwas „geprüft“ haben?
„Tötet sie alle, Gott wird die Seinen erkennen“ – rief man wohl schon vor einem Jahrtausend.
»Bindestrich«
Ein Trennzeichen zwischen Schlagwort und laufender Nummer ist in jedem Fall angebracht.
Bindestrich muss es nicht zwangsläufig sein.
ref- hatte ich mir bereits 14:13, 14. Okt. gewünscht.
Bei einer Domain wäre aber example.com/1 angebrachter, woraus ich später eine Pseudo-URL example.com/Dingens machen kann.
„Meier-Burghard-1“ ist auch ein seltsamer Familienname; „Meier-Burghard/1“ liest sich strukturierter.
Ich freu mich immer über Feedback, wenn etwas unklar oder unpräzise ist, kann natürlich sein, dass ich da etwas betriebsblind war oder es in verschiedenen Wikis verschiedene Informationsbedürfnisse gibt, dann update ich die Hilfeseite gerne, um sie für alle verständlich zu machen.
"Mit welchen Parametern..." – das ist doch der Punkt: Die Autoname-Vorlage gibt an, welche EN-Vorlagenparameter sie "kennt" und wie daraus ein Name entstehen könnte. Das ermöglicht vollkommene Flexibilität, die Autonamevorlage immer wirken zu lassen, wenn in der EN-Vorlage einen Parameter genutzt wird, mit dem die Autoname-Vorlage etwas anfangen kann.
"Wozu soll das nötig sein"? Man stelle sich einen Einzelnachweis wie <ref>{{righteous.yadvashem.org |...}} {{Webarchiv ...}}</ref> vor – in dem Fall würde VisualEditor nur bei der ersten Vorlage versuchen, einen EN-Namen zu erstellen (und zum simplen Fallback greifen, wenn die erste Vorlage keinen Parameter liefert, mit dem eine Autonamevorlage etwas anfangen kann).
Ich bekomme das Gefühl, du möchtest mich missverstehen, wenn ich hier versuche in einfacher Sprache den Prozess zu erklären. Was ich will ist einfach: Eine Autonamevorlage, die diverse Parameter abdeckt, die möglichst viele der 15.000 Vorlagen potentiell erfasst, ohne dass ich überprüfen muss, ob das tatsächlich so ist (außer bei den zentralen Vorlagen wie Internetquelle/Literatur, für die ich diverse Tests gemacht hab). Und das geht nunmal am einfachsten, wenn ich verschiedene mögliche Varianten von Autor, Titel, Werk usw. in die Autoname-Vorlage schreibe – entweder trifft dann eine davon auf die EN-Vorlage zu, oder wenn ich Pech hab halt nicht.
Bindestrich: Ich hab noch nie gesehen, dass ein Autor im Quelltext einen EN "tagesschau.de/1" genannt hätte, aber sowas wie "tageschau-1" oder "tagesschau.de-1" ist mir schon häufiger begegnet, wenn es mehrere EN der gleichen Website gab.
»Ich freu mich immer über Feedback, wenn etwas unklar oder unpräzise ist«
mw:Help: müsste eine Vorlagendokumentation liefern zu der abstrakten Autoname-Vorlage, die dann in den Wikis implementiert würde.
Eine Vorlagendokumentation muss drei Angaben machen:
Den Bezeichner der Vorlage; hier definiert per JSON
Die Parameter, mit denen diese Vorlage aufgerufen werden kann, muss, darf; und was diese bewirken würden.
Die sind hier konkret unspezifiziert; aber müssten umschrieben werden dahingehend was die Software als Parametersatz generiert.
Das Resultat (Zeichenkette), das die Vorlage liefern wird.
Müsste hier das schließende Trennzeichen thematisieren, und erwähnen, dass dahinter fortlaufende Ziffern angehängt werden.
mw:Help: enthält zurzeit jedoch nur wolkige example, keine Vorlagendokumentation.
Weil da in einem Code-Beispiel das Resultat auf ein Trennzeichen endet, müssen also alle auf der Welt raten, dass sie dieses Trennzeichen liefern können/sollen.
Eine Dokumentation ist Design by Contract; die eine Seite (VE) liefert die Vertragsbedingungen, die im Wiki durch die Entwicklung erfüllt werden müssen, und wenn sich an die Vertragsbedingungen gehalten wird, produziert VE immer das vereinbarte Ergebnis. Ohne Vertrag und Dokumentation ein schlechtes Geschäft.
»in einfacher Sprache« – Adressaten sind Leutchen aus der Programmierung, und die benötigen formale eindeutige Statements. Und kommen auch damit klar.
»Die Autoname-Vorlage gibt an«
Sie gibt üerhaupt nichts an, und mit getParent().args kennt sie jede Zeichenkette des Planeten.
»Man stelle sich […] vor – in dem Fall würde VisualEditor nur bei der ersten Vorlage versuchen«
Ich kenne ein wenig die enWP, und ich formatiere seit über einem Dutzend Jahren Belege in der deWP und habe Millionen davon gesehen.
Mir ist kein Fall erinnerlich, wo nicht die allererste eingebundene Vorlage die wesentlichen Informationen zur Publikation angeben würde.
Es gäbe höchstens Experimente, dass es kein echter Beleg wäre, sondern ein Anmerkungstext, in dem mit Vorlage:" eine nebenläufige Abhandlung begonnen wird. Dann ist aber unvorhersagbar, welche der nachfolgenden Vorlageneinbindungen nun eine Publikation sinnhaft beschreiben würden.
In solchen Fällen ist die Wiedervertbarkeit eines ref mit Zitat und Anmerkungs-Story jedoch äußerst zweifelhaft. Problem stellt sich nicht.
Heißt: Die zuallererst angetroffene Einbindung ist mit sehr großer Sicherheit diejenige, welche die Beleg-Publikation liefert. Ergibt deren Auswertung keinen Hinweis, dann muss eben auf Fallback zurückgegangen werden, wie schon seit einem Dutzend Jahren mittels:.
Falls irgendwelche anderen Einbindungen hinterherklappern, was in der enWP schon mal vorkommt, dann generieren die nichtssagende Hinweise zu Lizenzen oder OpenAccess oder sonstwas. Die Unterstellung, die Einbindung mit der wesentlichen Angabe der Publikation würde von weiteren hilfreichen sinnhaften Einbindungen gefolgt, bedürfte eines empirischen Nachweises. Und es ist auch wenig plausibel, dass eine später folgende Vorlage dann das entscheidende unterscheidende Schlagwort liefern würde.
Schrägstrich:
tagesschau.de/irgendwas ist ein vertrautes URL-Schema; wir versuchen immer, an bekannte und vertraute Muster anzuknüpfen. Hier ist es eine selbstgemachte Pseudo-URL.
Ansonsten hilft kurzes insource: – gibt Tausende von Anwendungen, und die Suche bricht schnell ab:
Insgesamt haben zigtausende von Menschen mal strategisch, mal aus purer Not die gerade in den Sinn kommenden selbsterklärenden Unterschedungs-Zeichenketten vergeben. Ein Schema, eine wahrgenommene Anleitung, eine Richtlinie dazu gibt es nicht. Also müssen wir jetzt weitsichtig für die Comminity in den nächsten Jahren planen.
name="Fischer-Dieskau/374-378" wird gern verwendet für: „Fischer-Dieskau, S. 374–378“, was problematisch wird mit: Fischer-Dieskau-1987-374-378
"Vorlagendokumentation liefern zu der abstrakten Autoname-Vorlage" – sowas gibt es aber gar nicht. In der Hilfeseite steht explizit: Wikis können eine oder mehrere Autoname-Vorlagen erstellen und darin definieren, welche EN-Vorlagenparameter auf welche Art und Weise zur Erstellung von Einzelnachweisnamen genutzt werden sollen. Als simples Beispiel ist dafür eine Vorlage gezeigt, die für den Namen schlichtweg den vollständigen Inhalt aus bestimmten Belegvorlagenparametern nimmt (z.B. Autor + Jahr). Es ist aber den Wikis selbst überlassen, welche / wie viele Belegvorlagenparameter sie in die Autoname-Vorlage packen wollen, wie sie die kombinieren wollen (oder welche Fallbackketten sie erstellen) und ob sie mehrere Autoname-Vorlagen für mehrere Belegvorlagen(arten) erstellen wollen. Ebenfalls beschrieben ist auch, dass (und wie) man im JSON eine default Autonamevorlage festlegen kann. Und wenn man jetzt noch Lua nutzt, haben Wikis quasi unendliche Freiheiten. VisualEditor nimmt im Prinzip einfach an, was auch immer ihm die Autoname-Vorlage (mit oder ohne Modul) ausspuckt und hängt dann noch ne Zahl dran. Das kann 1:1 der Inhalt eines beliebigen, von der Community gewählten Vorlagenparameters sein oder per Modul extrahiert auch nur ein Teil des Vorlagenparameterinhalts, ggf. kombiniert mit anderen Inhalten.
Die Anweisung muss für ~1000 WMF Wikis (und zahlreiche third party wikis) funktionieren, die alle unterschiedliche Einzelnachweisvorlagen nutzen und überwiegend eben keine "Leutchen aus der Programmierung" sind, sondern Menschen, die es so eben und eben schaffen, eine einfache Beispielvorlage aus ner Hilfeseite zu kopieren oder sich was von nem anderen Wiki abzukupfern, vorausgesetzt es passt zu den im eigenen Wiki verwendeten Vorlagen. Auch hier auf WP:AA führen wir ja keine Privatunterhaltung, ich versuche meine Beschreibungen so zu verfassen, dass auch andere Menschen mitlesen und ihre Meinung äußern können. Entsprechend sehen wir bereits ein paar größere, technisch affinere Projekte, die mit eigenen Autoname-Modulen experimentieren, während andere Wikis einfach das simple Beispiel nutzen (oder auf inhaltsbasierte Namen komplett verzichten und einfach nur von <ref name=":1"> auf sowas wie <ref name="Einzelnachweis-1"> in deren Sprache wechseln).
Ich hab in der Hilfeseite noch nen Hinweis bzgl. des Trennzeichens eingebaut, das war in der Tat nicht klar, sondern bisher nur bei den simplen Fallbacknamen erwähnt oder aus dem Beispiel ableitbar, danke für das Feedback. Die fortlaufenden Ziffern standen da bereits, aber ich lass mir nochmal durch den Kopf gehen, ob das noch klarer sein kann. --Johannnes89 (Diskussion) 15:17, 16. Okt. 2026 (CEST)
Gerade etwas wie tagesschau.de/1 fände ich da aber eher unnötig irritierend. Eben weil man das URL-Schema kennt, rechnet man auch mit einer URL und nicht damit, dass es sich um eine Pseudo-URL handelt. --Ameisenigel (Diskussion) 15:44, 16. Okt. 2026 (CEST)
Ich habe noch nie eine Internet-TL-Domain .de-1 gesehen.
Da ich täglich hier neue Herausforderungen von redacted bis Hauptseite usw. abbekomme, bin ich bisher noch nicht zum Aufsetzen und Erproben meines vorbereiteten Moduls gekommen. Mal sehn, wie lang die Nächte am Wochenende werden.
Richtig, und deshalb erkennt man bei "tagesschau.de-1" sofort, dass der Name "tagesschau.de" ist und dann eine Nummer erhalten hat, während /1 eben wie ein Teil einer URL aussieht und damit ein ungeeigneter ref name ist. Mit einer insource-Suche kannst du feststellen, dass es auch vor meiner Änderung schon zahlreiche Namen gab, die genau wie "tagesschau.de-1" aussahen. Deine Beispiele oben hingegen belegen zwar, dass es auch Namen mit / gab, aber sowas wie "tagesschau.de/1" ist mir bei meiner eigenen Suche jedenfalls nicht begegnet (dir anscheinend auch nicht, sonst hättest du bessere Beispiele geliefert).
Zu deiner letzten Anmerkung: Dass an verschiedenen Stellen in der Wikipedia verschiedene technische Themen diskutiert werden, bedeutet übrigens nicht, dass du "Herausforderungen" abbekommst, in diesem Gemeinschaftsprojekt können durchaus auch andere sich mit solchen Fragen beschäftigen. --Johannnes89 (Diskussion) 14:27, 22. Okt. 2026 (CEST)
Beim letzten Mal hat die IP-Sperre allerdings auch nicht so viel gebracht (und ist ja auch so oder sehr sehr einfach zu umgehen). Wäre vielleicht ein Bearbeitungsfilter denkbar (mit denen kenne ich mich allerdings nur wenig aus und kann dementsprechend auch nur bedingt Vorschläge machen, wie der aussehen könnte)? -- Chaddy · D 13:39, 19. Okt. 2026 (CEST)
Warum, was gefällt Dir nicht an der jetzigen Situation? Ist doch alles eindeutig. Wer Sea Shepherd sucht wird ohne Umweg auf die drei Organisationen geleitet, die ohnehin redundant sind. -- Biberbaer (Diskussion) 08:59, 21. Okt. 2026 (CEST)
Ich halte diese Anfrage für abgeschlossen. Verschiebungen, zudem möglicherweise ohne eindeutigen Konsens, sind inhaltliche, nicht administrative EEntscheidung. -- Toni 09:51, 25. Okt. 2026 (CET)
Text etwas wie: „Wegen PHP2Shell sind viele Hilfsmittel aus der Wiki-Cloud vorsorglich abgeschaltet worden. Bis das letzte Werkzeug wieder funktionieren wird, kann es Ende Oktober werden; ein größerer Teil sollte aber in der kommenden Woche reaktiviert sein.“
Updates dann mit anderen Farben, wenn was wieder freigeschaltet wurde.
@PerfektesChaos, @Johannnes89: Woher kommt „ein größerer Teil sollte aber in der kommenden Woche reaktiviert sein“? Ist das offiziell? --Count Count (Diskussion) 15:13, 22. Okt. 2026 (CEST)
Das ist Autofahren mit Kindern: „Wann sind wir endlich da?“ „Ich muss mal! Dringend!“ „Wie lange dauert das denn noch?“ „Wann sind wir endlich da?“
Die Message ist: Dieses Wochenende, und die nächste Woche durch brauchst du nicht zu drängeln; aber irgendwann wird die Sonne aufgehen, und nach und nach wird alles wieder gut.
Der momentane Text hält bis Sonntag abend, weil heute Werktag ist; bis dann braucht es ohnehin ein Update.
3 ½ Tage sind in der IT eine lange Zeit; ich gehe davon aus, dass bis dahin irgendwas wieder laufen wird; zunächst die Toolforge.
Wir gucken alle paar Stunden, wie das so abgeht, und spätestens am Wochenende gibt es entweder Erfreuliches oder zumindest genauere Einschätzungen.
Ich mach das ja auch schon ein paar Jahrzehnte und jongliere mit Glaskugeln.
Ist in der Tat nicht wirklich sicher, aber die WMF hat ja bereits darum gebeten, Tool auf wikitech:Talk:Incidents/2026-10-21 PHP security update/Community zu nennen, die kein PHP nutzen, das klingt nach ner guten Chance, dass viele Tools irgendwann kommende Woche wieder laufen können – und wenn nicht, kann man den Text ja noch updaten. --Johannnes89 (Diskussion) 15:42, 22. Okt. 2026 (CEST)
We're working on making the Toolforge build service smart enough to block launching of PHP tools so that we can start launching non-php things safely. Next, we'll figure out what to do about tools that rely on unfixed/unfixable PHP versions. We hope to have partial (php-free) Toolforge functionality restored sometime in the next 24 hours.
Cloud-VPS:
We're currently focusing on projects maintained by WMF staff and/or NDA users, since we have more flexibility to adjust those projects to our current safety standards. Our team is auditing projects one by one with the goal of starting up those projects that don't use PHP at all ASAP. After that we'll look at patching projects that use PHP in some form - we'll do so to the best of our ability and understanding of each project, with a focus on security rather than fully enabled functionality at first - and after that we will face up to the projects that rely on unfixed PHP versions. This whole process will likely take a few days for most projects which have a simpler path to safety, and a few weeks for the most complex ones. We might start contacting some maintainers for support as we start working on their projects." --Johannnes89 (Diskussion) 18:07, 22. Okt. 2026 (CEST)
Da die Lage (erwartungsgemäß) sehr im Fluss ist und Update-watchlistMessage kurzfristig absehbar, hier erstmal noch nicht erlen. Ich bebachte grad bei Probeklicks einen Fortschritt auf Toolforge, wenngleich noch keine Funktionalität.
wmfcloud.org (beispielsweise xtools) und wmflabs.org haben lauter logische Server, die eigentlich von deren Maintainern einzeln gepatcht werden müssten, wo es häufig Freiwillige usw. sind. Das kann dauern.
Toolforge stelle ich mir so vor, dass es eine Handvoll physischer Server sind, die eher mit einem Patch pro Server auskommen sollten. Womit einzelne Werkzeuge unverträglich sein könnten? Bis alle Bots und cronjobs wieder vollautomatisch laufen, mag es sich ziehen.
Wenn Nicht-PHP-Anwendungen identifizierbar sind, können diese bevorzugt freigeschaltet werden. Ist aber eine Heidenarbeit, alles das sicher zu konfigurieren.
Einbrecher, die bei uns persönliche Daten klauen könnten oder was manipuliert hätten, sehe ich eher nur selten; etwa die Veranstaltungen, die auf wmflabs.org angesteuert werden und dann wohl auf anderen Wiki-Servern hinterlegt sind, hätten was echtes. Die Server-Logs wären noch interessant, sind aber wenig aussagekräftig. Eine IP hat mit einem Browser ein Werkzeug benutzt – so what? Hash-Datenbanken für das Login kann man im Prinzip sogar veröffentlichen; ohne Quantencomputer kann da keiner was mit anfangen.
Gerade eben lieferte ics, dessen Ausfall ich am späten Abend des 20. beobachtete.
Vermutlich gehen jetzt, wie skizziert, erste der Toolforge-Dingse wieder live.
Nach einiger Beobachtung betreffend Robustheit sollte in hellgrüner Hoffnungsfarbe die watchlistMessage betreffend „kommenden Woche“ umformuliert werden (dieser Halbsatz gestrichen); hingegen angefügt: „einige konnten bereits reaktiviert werden, und nach und nach werden weitere folgen“
Sodele; sieht ganz gut aus; Update in hellgrüner Hoffnungsfarbe sollte dann jetzt raus.
persondata geht auch wieder; wirkt stabil.
Update on the ongoing Toolforge and Cloud VPS downtime meint ja, die “webservices” würden laufen. Das ist wohl das, was wir „Tools“ nennen. “php jobs” würden noch dauern, wegen “build images”; vielleicht sind das Bots und cronjobs.
Instanzen der wmcloud.org dauern wohl noch einige Zeit, etwa petscan und pageviews, weil da wohl die Maintainer dieser virtuellen Server jeder eigenverantwortlich konfigurieren müssen.
War gerade dabei, die watchlist messsage wie von dir vorgeschlagen zu updaten, aber da immer mehr Tools nun bereits zurückkommen (vgl. wikitech:Incidents/2026-10-21 PHP security update/Community, die dort verlinkten Mails/Tickets und die vielen schon abgehakten Tools in wikitech:Talk:Incidents/2026-10-21 PHP security update/Community) frag ich mich gerade, ob die Message überhaupt noch nötig ist? Zumal es inzwischen doch ein WMF CentralNotice-Banner gibt. Viele Tools, die den Durchschnittsusern besonders auffallen dürften, sind bereits wieder online (z.B. xtools und pageviews). --Johannnes89 (Diskussion) 07:33, 24. Okt. 2026 (CEST)
Tools und Bots, die PHP verwenden, sind solange offline, bis sich die Maintainer darum kümmern. Da PHP 7 nicht mehr unterstützt wird und somit eine Migration auf PHP 8 nötig ist, ist das je nach Codebasis mehr oder weniger aufwendig. Meine Tools laufen wieder, da sie kein PHP verwenden bis auf toolforge:stimmberechtigung, für das ich inzwischen auch die Pflege übernommen habe. Da bin ich dran, es sollte also bis heute Abend wieder laufen. --Count Count (Diskussion) 09:11, 24. Okt. 2026 (CEST)
Vielleicht ist es an diesem Punkt sinnvoller, auf WP:TW zu sammeln, welche für unsere Community wichtigen Tools noch offline sind und die jeweiligen Maintainer individuell anzusprechen. --Johannnes89 (Diskussion) 09:41, 24. Okt. 2026 (CEST)
+1. Ich bin auch gerne bereit, mich bei wichtigen Tools von inaktiven Maintainern um die Migration zu kümmern, soweit möglich. --Count Count (Diskussion) 11:12, 24. Okt. 2026 (CEST)
Zurzeit bekommen alle, die erstmals dieses Wochenende die Beo besuchen, die hellblaue Message, dass garnix geht.
Alle, die es in den letzten Tagen gesehen haben, müssen davon ausgehen, dass Toolforge weiterhin unbenutzbar wäre, und versuchen es überhaupt nicht.
Insofern Teilentwarnung für den überwiegenden Bereich der Toolforge und die für uns wichtigsten Werkzeuge dort; Autoren können aber nicht zwischen VPS und Toolforge unterscheiden, und brauchen sich ansonsten auch nicht drum zu kümmern.
VPS = wmfcloud.org und wmflabs.org brauchen offenbar alle Maintainer-Eingriffe; in manchen Fällen wegen PHP-Inkompatibilität womöglich Umprogrammierungen. Das kann sich auch bis in den November und 2027 ziehen; aber viele mit agilen Maintainern wie die xtools-Bande sind schon durch.
Bots sind nochmal ein anderes Spiel; ob deWP-Bots betroffen wären, und wie aktiv deren Maintainer wären, weiß ich nicht.
Am Rande: wmcloud-Funktionen kommen auch bereits zurück (z.B. xtools). Es geht alles doch schneller, als ich zu hoffen gewagt hatte. --Mpns(Martin / Disk) 12:58, 24. Okt. 2026 (CEST)
Dafür sind diese Woche ja noch weitere Sicherheitslücken aufgetaucht (die nichts mit PHP zu tun haben, z.B. Node2Shell), die zur Deaktivierung weiterer Tools geführt haben (z.B. Etherpad) – vielleicht könnte man die Nachricht auch einfach verallgemeinern, dass wegen Sicherheitslücken gerade einige Tools offline sind, ohne viel zu spezifizieren. --Johannnes89 (Diskussion) 17:29, 24. Okt. 2026 (CEST)
@ „Nachricht auch einfach verallgemeinern“
„Viele Werkzeuge arbeiten inzwischen wieder, bei einigen wird das erst später möglich sein, sogar bis in den November.“
Der letzte Stand der Beobachtenden war, dass überhaupt nichts ginge. Wer heute erst aufschlägt, sieht in hellblau, dass alles hi ist.
Müssen halt alle bei ihren Lieblings-Tools selbst hin und wieder testen, was ginge und was nicht.
Ob wir einen Brotli-Decoder verwenden, und wie lange ein Update dauert, wird abzuwarten sein.
node.js ist allerdings ein ziemlich zentrales Fundament der Wiki-Architektur.
Für den Rest des Jahres können wir uns darauf einstellen, dass die KI global an diversen Stellen Leaks aufspüren wird, auf die ein Jahrzehnt keiner gekommen war. Danach ist die Welt wieder ein Stück besser, und zukünftige Distributionen werden von vornherein mit neuartigen KI-Methoden gecheckt.
