Wikipedia:Technik/Skin/MediaWiki/Änderungen

Änderungen im MediaWiki-Namensraum

Auf dieser Seite können lokale Änderungen an Codeseiten im MediaWiki-Namensraum, an Helferlein (Gadgets) sowie an Javascript- und CSS-Seiten anderer Benutzer vorgeschlagen werden. Diese können nur von Benutzeroberflächenadministratoren umgesetzt werden.

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 14 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Archiv

2024 2023 2022 2021 2020 2019 2018

Overflow für Musiknoten

Letzter Kommentar: vor 2 Jahren2 Kommentare1 Person ist an der Diskussion beteiligt

Nachdem die Score-Extension mittlerweile glücklicherweise wieder funktioniert, scheint es mir an der Zeit, ein .mw-ext-score { overflow:auto; } zu verordnen. Im Moment ragen längere Notenzeilen auf schmalen Bildschirmen (das können Mobilgeräte, aber auch einfach der neue Vector sein) rechts über den Rand; bei den Desktop-Skins wäre das wohl noch vertretbar (da es im Moment auch noch keine einheitliche Softwarelösung für überbreite Tabellen gibt), aber in Minerva/Mobile ist eine Scroll-Möglichkeit absolut notwendig, sonst verrutscht am Ende der ganze Inhalt. Der Einfachheit halber würde ich vorschlagen, die Anweisung für alle Skins und alle Bildschirmbreiten zu vergeben, schaden kann sie ja nicht. Oder gibt es andere Vorschläge? Ich setze mir das jetzt erst einmal in mein Benutzer-CSS. Gruß --XanonymusX (Diskussion) 15:31, 25. Dez. 2021 (CET)Beantworten

Wobei, für Desktop müsste man dann auch das display:inline-block deaktivieren, dessen Sinn habe ich noch nicht durchschaut. Eventuell muss die Lösung dann erst einmal auf Minerva/Mobile beschränkt bleiben. --XanonymusX (Diskussion) 15:37, 25. Dez. 2021 (CET)Beantworten

Warnbox in Common.css aufnehmen

Letzter Kommentar: vor 2 Jahren17 Kommentare3 Personen sind an der Diskussion beteiligt

Bitte die Definition des Standard-MediaWiki-Designs aus phab für Warnmeldungen in die MediaWiki:Common.css aufnehmen:

.mw-message-box-warning,
.warningbox {
	background-color: #fef6e7;
    	border-color: #fc3;

Hintergrund: Es werden hierzuwiki verschiedenste selbstgebastelte Warnboxen für den gleichen Zweck genutzt. Daher möchte ich dieses Standarddesign auch für lokale Systemnachrichten verwenden können. Gruß, --Wnme (Diskussion) 16:34, 21. Feb. 2022 (CET)Beantworten

Das geht doch schon längst und wird auch so verwendet.

Test

-- hgzh 16:54, 21. Feb. 2022 (CET)Beantworten

Naja, das ist so eine Sache.

Die Definitionen gibt es zwar, aber sie werden unzuverlässig in den Seiten bereitgestellt, und manche verschwinden auch wieder und manche gibt es nur wenn im statischen HTML-Text=wikitext bereits auftretend, nicht aber wenn erst durch JavaScript nachgeliefert.

CSS/Selektoren unter MediaWiki#Beispielformatierungen war mal nur rot und gelb und grün, aber .error gibt es nur wenn statisch im Wikitext und sonst nicht.

VG --PerfektesChaos 17:07, 21. Feb. 2022 (CET)Beantworten

Stimmt schon, mir ist aber noch kein Fall untergekommen, in der die warningbox in Systemnachrichten nicht funktioniert hat. -- hgzh 18:52, 21. Feb. 2022 (CET)Beantworten

Mein spezieller Freund ist seit Mitte letzten Jahres beauftragt, hauptamtlich den Dekorationsbereich zu ordnen, zu strukturieren und aufzuräumen.

Das löst er dadurch, dass serienmäßig CSS-Deklarationen gelöscht oder irgendwohin verbannt werden, damit er es einfacher hat.
Insbesondere soll es wohl nur noch die drei Farben weiß, schwarz und blau geben, so scheint es.

Anfragen, warum seit Jahrzehnten vorhandene Standardstile nicht mehr verfügbar sind, werden von den Vorgesetzten dahingehend beantwortet, dass den Projekten nur diejenigen Klassen zustehen, die auf offiziellen Seiten der WMF (MW) dokumentiert sind.

Das wäre dann die Seite mw:Manual:Interface/IDs and classes, während die dort noch verlinkte en:Wikipedia:Catalogue of CSS classes eine irrelevante Privat-Aktion ohne Verbindlichkeit sei.
Auf der WMF-Seite ist weder das Wort error noch warning auffindbar. Also, letzteres zwar schon, aber nicht in der Spalte mit Namen der Klasssen.
Bei allem, was nicht offiziell durch MediaWiki dokumentiert sei, behalte man sich vor, es jederzeit ohne vorherige Warnung zu eliminieren.
Wobei – .error gibt es offiziell seit Frühjahr 2006, weil wenn diese Klasse in " (und nicht in ' oder ohne) eingeschlossen sei, löst sie #iferror: aus, falls in deren Parameter vorkommend.
Die Deklaration von .error ist etwa Ende letzten Jahres dahingehend verschärft worden, dass sie nur noch innerhalb des Content-Bereichs .mw-body-content wirksam ist. Einfach mal das Wort „Mitmachen“ im Desktop-Portalrahmen in HTML-Bearbeitung mit dieser Klasse über Browser-Werkzeugkasten versehen. Wird nicht rot. Ich füge jetzt mal das Wort „Fehler“ in eine Blanko-Klasse ein: Fehler – über HTML-Manipulation lässt sich hier der Name der Klasse ändern, und im Content ist das (noch) wirksam. Wenn ein Gadget eine Fehlermeldung im Seitenkopf einfügt, ist Essig.

Ich schau mir das schon eine Weile interessiert an und überlege, ob wir ein inhaltsgleiches Paket mit den jahrzehntealten häufig sinnvollen Basis-Klassen bereitstelllen sollten, das wir innerhalb von Seiten per TemplateStyles und für Gadgets und Benutzerskripte per JS-load verfügbar machen, unter den alten Selektoren und im klassischen Design und ohne Mätzchen.

@Wnme: Weil du hier angefragt hast, so gab es ja offenbar eine Situation, in der das CSS nicht definiert war. Um genau welche Umstände handelte es sich denn?

VG --PerfektesChaos 21:43, 21. Feb. 2022 (CET)Beantworten

@PerfektesChaos: Ich komme mit den Details zur technischen Umsetzung zwar nicht ganz mit. Aber habe es mir noch mal angesehen. Hatte angefangen aufzuräumen, wo mir etwas über den Weg gelaufen ist und die Warnbox eingefügt. Teils wurden verschiedenste selbstgebastelte Designs verwendet. Teils gab es Warnhinweise ohne einen Style. Was ich mir wünschen würde wäre ein Design-Leitfaden, wo drauf verwiesen werden kann. Also z.B. „Kasten warn“ soll für use case x verwendet werden. Eine Struktur und ganzheitliche Lösung würde ich befürworten. Wie auch immer sie am Ende aussehen würde. Habe hier mal versucht den derzeitigen Stand der Einsatzzwecke der Styles zusammen zu fassen. Was mich am meisten beschäftigt sind die Styles für Filter und alles was newbies betrifft (zB. MediaWiki:revreview-editnotice, MediaWiki:Newarticletext-2). Die Überarbeitung der Texte der Filterwarnungen ist noch ein Projekt auf meiner Liste (Die Änderung bei MediaWiki:Abusefilter-!Box von abschreckenden rot auf rot zu grellen grün ist noch immer nicht unbedingt die optimale Lösung). Was das Thema Style howto betrifft können wir ja die Disk. an geeigneter Stelle fortführen. --Wnme (Diskussion) 10:02, 8. Mär. 2022 (CET)Beantworten

Wird wohl doch nochmal interessant: phab:T300314. Müssen wir schauen, ob sich das durch eine Vorlage lösen lässt oder wir tatsächlich die globale CSS einsauen müssen. -- hgzh 07:56, 2. Mär. 2022 (CET)Beantworten

Ja, ja, siehe auch Tech News 2022-09:

Wenn du Vorlagen entwickelst oder Benutzeroberflächenadministrator bist und absichtlich die Standard-CSS-Styles von Boxen zur Rückmeldung an Benutzer (die Klassen successbox, messagebox, errorbox, warningbox) überschreibst oder nutzt, beachte bitte, dass diese Klassen und das zugehörige CSS bald aus dem MediaWiki-Kern entfernt werden. Dies soll Probleme verhindern, falls die gleichen Klassennamen in einem Wiki verwendet werden. Bitte lass es uns wissen, wenn du glaubst, dass du betroffen sein könntest, indem du in phab:T300314 kommentierst.

Global einsauen möchte ich uns auch nicht; allenfalls selektiv.

Dazu muss vorher mal zusammengetragen werden, wer wo was überhaupt benötigt. Es gibt drei Gebiete:

Vorlagen; könnten TemplateStyles nutzen.
Systemnachrichten; können kein TemplateStyles aber inline-style über eine zentral gepflegte Vorlage einbinden.
Gadgets und Skripte bräuchten spezielles: Gadget-dewikiGadgetStyles.css

Vielleicht können wir grundsätzlich andere Lösungen finden.

Die historischen Klassenbezeichner sind damit verbrannt, wenn unser WMF-Löscher sie unter fadenscheiniger Begründung zukünftig nicht mehr global unterstützen will. Schon wegen Kollisionen mit C&P aus anderen Projekten sind solche Trivialnamen damit unbrauchbar.

Ich denke da an explizit lokale mit Präfix dewiki- und einem System, oder aber alternativ oder kombiniert an unser traditionelles Bausteindesign-Schema mit TYP und Klarnamen ohne Umlaute (und Kleinschreibung nach Bindestrich statt Großbuchstaben), auf die ggf. die bisherigen WMF-Designs abzubilden wären; bzw. wir auch neue definieren können, die WMF-Designs genauer wiedergeben. Irgendwas wie meldung-.
Sofern das nur seitenspezifisch angefordert wird, können wir die historischen Bezeichner aber migrierend unterstützen.
Misstrauisch hatte ich mir schon vor einigen Jahren die Deklarationen kopiert:

.error {
   color: #CC0000;
}
.warning {
   color: #705000;
}
.success {
   color: #009000;
}
.messagebox {
   background-color: #EAECF0;
   border-color: #A2A9B1;
}
.errorbox {
   background-color: #FEE7E6;
   border-color: #DD3333;
}
.warningbox {
   background-color: #FEF6E7;
   border-color: #FFCC33;
}
.successbox {
   background-color: #D5FDF4;
   border-color: #14866D;
}
.messagebox,
.errorbox,
.warningbox,
.successbox {
   border: 1px solid;
   color: #000000;
   padding: .5em 1em;
   margin-bottom: 1em;
}

resources/src/mediawiki.legacy/shared.css wurde mittlerweile gelöscht. Kein legacy, kein shared mehr.

Es gibt auch keine auf WMF-Seiten hinterlegte Zusage, dass wir dauerhaft mw-message-box-warning usw. verwenden und uns darauf verlassen dürfen. Insofern würde ich die WMF-Stile nunmehr sukzessive in die Tonne kloppen, auch um Kollisionen mit zukünftigen Design-Extravaganzen zu vermeiden, und nunmehr unser eigenes Ding drehen.

Das Problem mit dieser Super-Idee, Klassen statt inline-style zu verwenden, zieht in unserem globalen Namensraum mit Kollaboration zwischen anderen Wikis und der WMF und diversen Vorlagen und Artikeln nach sich, dass es einer kollisionsfreien globalen Registrierung der Namen bedarf. Und die fehlt seit immer. Und deshalb ist inline-style ohne Kollisionsgefahr und mit zentraler Vereinbarung in einer Vorlage diesem ganzen class-Rummel bis heute haushoch überlegen.

VG --PerfektesChaos 15:53, 2. Mär. 2022 (CET)Beantworten

Auch mw-message-box-warning wird nicht mehr immer verfügbar sein, so wie ich verstanden habe, wird die ganze messageBoxes.less nur noch vom Core geladen, wenn der Core sie auch braucht.

Ich hatte auch die Idee, das styling in Vorlage:Standardbaustein einzubauen. Ich weiß nur nicht, ob das dann auch in jeder Systemnachricht klappt. Gerade heute habe ich mich wieder darüber geärgert, dass die Systemnachrichten alles sein können, Konfigurationsvariable, Wikitext, HTML, Plaintext (und das noch abhängig vom Kontext) und raus findet man das praktisch nicht.

Naja, notfalls müssen eben Inline-Styles gebaut werden. -- hgzh 22:32, 3. Mär. 2022 (CET)Beantworten

Ich sinne bereits auf Abhilfe.

Dazu müsste aber erstmal geklärt werden, was wir wo brauchen; aus JavaScript oder in Vorlagen oder Systemnachrichten.

Mein momentaner Plan sähe dann so aus:

Es gibt ein Gadget-dewikiMsgStyle.css
Das kann einmalig pro Wiki-Seite eingelesen und in ein mw.loadData überführt werden, falls noch nicht bekannt.
Das wandelt alle Klassendefinitionen in inline-geeignete CSS um. Was allerdings bei Pseudo-Selektoren nicht ginge, aber die sind ja aktuell nicht betroffen.
Dadurch gibt es eine Lua-table mit Selektoren und zugeordnetem CSS-Code.
Nun kann ein Lua-Funktionsmodul (das ggf. vorher auch einmalig die Generierung pro Seite des mw.loadData umgesetzt hätte) die Generierung eines HTML-Elements übernehmen, typischerweise div oder span, mit Klassen und weiteren style und lang und dir usw. Und natürlich ein textueller Inhalt.
Die individuell übergebenen HTML-Spezifikationen und die Schlüssel werden zusammengeführt, und es kommt ein formatiertes Element heraus. Dem kann sogar eine Fehlerkat angeschlossen werden.

JavaScript kann das Gadget-dewikiMsgStyle wie üblich laden.

Vorlage:Standardbaustein aber ebenso (die ließe sich damit deutlich vereinfachen); auch die traditionell laaaaangweilige Vorlage:Kasten.

Damit gibt es nur eine zentrale Definition.

Theoretisch könnte noch per C&P ein textidentisches TemplateStyles parallel gehalten werden; weil das aber in Systemnachrichten nicht funktioniert und die gern außerhalb des Inhaltsbereiches irgendwelche Kästen darstellen ist das überflüssig und style geht immer und überall.

OT: Mein ganz spezieller Alles-Aufräum-Experte mit Tellerrand endend in der enWP hat’s mal wieder verbockt; was du ja auf FZW schon kommentiertest.

VG --PerfektesChaos 16:40, 4. Mär. 2022 (CET)Beantworten

@Hgzh: So, ich habe mal zur geistigen Entspannung Vorlage:Kasten@BETA gebaut.

Basiert auf MediaWiki:Gadget-dewikiMsgStyle.css die ich gern erstmal nur als existierende Seite hier hätte.
Vergleiche mit hiesiger Vorlage:Kasten sowie Vorlage:Standardbaustein.
- Vorlage:Standardbaustein ist inzwischen auf über 50.000 Einbindungen gekommen und damit Kandidat für Dreiviertel move=sysop geworden.
Gadget muss das einleitend genannte jetzt noch nicht sofort werden.
- Die Gadget-Schubserei machen wir vielleicht besser Mitte/Ende März; mir behagt momentan die Weltlage nicht und ich bin ziemlich down.

VG --PerfektesChaos 21:51, 7. Mär. 2022 (CET)Beantworten

Danke, ich schau es mir mal an. Gruß, -- hgzh 07:34, 8. Mär. 2022 (CET)Beantworten

So, nochmal ein bisschen drüber nachgedacht: wie sieht denn die Abgrenzung zwischen Vorlage:Kasten, Vorlage:Standardbaustein und Vorlage:Hinweisbaustein zukünftig aus? -- hgzh 20:03, 28. Mär. 2022 (CEST)Beantworten

Es nimmt die historisch gewachsenen und in den Köpfen eingewurzelten Traditionen auf.

Rein technisch ist Vorlage:Kasten (zukünftig) wenig anderes als ein Standardbaustein ohne Icon.

Könnte einen Unterschied in der beanspruchten Breite geben.
Hat deshalb aber weniger Parameter im Blickfeld.
Ob irgendwann Vorlage:Kasten intern Vorlage:Standardbaustein aufrufen mag oder nicht wäre ein späterer Schritt, nach Konsolidierung der ersten Phase.

Vorlage:Kasten ist dafür gedacht, direkt von Autoren im ANR, in Diskussionen und auf Projektseiten eingebaut zu werden.

Bisher gibt es einen einzigen Parameter und genau ein Design, was ja auch kompatibel bleibt.
Zukünftig sind mehr optische Lösungen im Angebot, die aber eher nicht völlig beliebig zusammengestellt werden sollten, sondern auf den traditionellen Satz an Standard-Designs kanalisiert würden. Momentan gibt es x private Direkt-Konstruktionen, auch mit Layout-Tabellen.
Es gibt auch weiterhin die HTML-Universal-Attribute wie bei allen derartigen Universal-Basis-Vorlagen, die aber ignoriert werden dürfen und nur Spezialfälle abdecken.
Es könnten unterstützte Parameter undokumentiert bleiben, fürs Volk: role dir

Vorlage:Standardbaustein ist wie auch Vorlage:Hinweisbaustein dafür gedacht, andere Bausteine zu konstruieren und den technischen Background auf einfache Weise unterstützt zu bekommen.

Also QS-Bausteine, Systemnachrichten usw.
Eine Direktverwendung für Autoren ist nicht vorgesehen, ließe sich aber nicht verhindern. Ergibt sich letztlich eher aus der Kategorisierung und Auffindbarkeit.
Vorlage:Hinweisbaustein ist ein Sonderfall für die Konstruktion von ANR-Bausteinen, insbesondere mit den beiden Varianten „ganz oben“ und „ganz unten“. Hat damit auch ein anderes Schutzbedürfnis und Häufigkeit.
Vorlage:Standardbaustein kann die neuen abstrahierten fehler warnung erfolg danach hinzulernen. Wäre ohnehin Migration einiger Design-Namen erforderlich (rotROT hellgrün), ist aber nur geringfügig verwendet worden.
Vorlage:Standardbaustein transportiert noch Infos zur Migration von Vorlage:Bausteindesign4 Vorlage:Bausteindesign5 ,,, Vorlage:Bausteindesign13 wohingegen Vorlage:Kasten nahe Null ohne Altbestand loslegen kann.

Parameternamen und Design soll innerhalb der Familie soweit möglich vereinheitlicht werden; ebenso die Klassenbezeichner. Familie ist aber sehr weitläufig.

VE-Unterstützung von vornherein mitgedacht. noprint zum Ankreuzeln.
Schriftfarbe nur über Hex könnte ich mir für Vorlage:Kasten noch vorstellen.
Systemnachrichten, Klassen und TemplateStyles beißen sich.
- Man könnte den Dingern noch die class= mitgeben, dann funktionieren die Systemnachrichten, und wer unbedingt sein privates Design veranstalten will kann das mit !important kontra-re-stechen.
Sind mehrere langjährige Migrationsphasen erforderlich, bis ein Optimalzustand erreicht wäre. Text@Kasten ist ein beliebiger Inhalt. Text@Zitat dann schon eher Text.

Nebenbei hatte ich auf BETA dein JS wohlwollend kommentiert.

VG --PerfektesChaos 15:23, 29. Mär. 2022 (CEST)Beantworten

Danke für die Klärung und auch für das Feedback zum JS-Versuch auf Beta.

Da es nun wohl ernst wird und mit dem kommenden Softwareupdate die Box-Klassen aus dem allgemeinen Stylesheet gekickt werden, habe ich MediaWiki:Gadget-dewikiMsgStyle.css von Beta hierher kopiert. Zweierlei erzeugt noch Fragen meinerseits:

wie wollen wir mit den hintergrundfarbe/rahmenfarbe-Klassen umgehen? Diese werden ja spezieller auch in Common.css und Mobile.css definiert, sollten also wenn möglich nicht konkurrierend bestehen. Die recht spezifische Definition der hintergrundfarbe-Klassen in der Common.css hatte seinerzeit einen Hintergrund: MediaWiki Diskussion:Common.css/Archiv/2#Hintergrundfarben nach Übernahme von wikitable in core-css.
dewikiMsgStyle passt mit hintergrundfarbe/rahmenfarbe nicht mehr so wirklich, da die ja auch überall anders verwendet werden, nicht nur in Benachrichtigungskästen.

Grund zur Hektik besteht m.E. aber nicht, lokal verwendet wird sie nur von ein paar Handvoll Systemnachrichten, die ein paar Tage auch ohne Rahmen auskommen dürften. Gruß, -- hgzh 18:11, 20. Apr. 2022 (CEST)Beantworten

@Hgzh: Bitte die MediaWiki:Gadget-dewikiMsgStyle.css noch in das Content Model sanitized setzen.

Nachdem gestern Ende von Sommer war und ich bei momentanen Temperaturen wieder anfangen kann zu denken, beginne ich nunmehr offene Baustellen abzuarbeiten.
Was die Frage nach Duplizität der hintergrundfarbe/rahmenfarbe-Klassen angeht, so werden sie wohl sehr sehr langfristig sowohl im Gadget wie auch in Common.css dupliziert verbleiben müssen.
- Sie sind dann aber auch auf Mobil wirksam; das wäre der nächste Teil einer Aktion; die parallele Deklaration aus MediaWiki:Mobile.css zu reduzieren. Wobei, da sind nicht alle Rahmenfarben identisch, aber das muss ich nicht verstehen
- Jedoch würde im Zuge der Einarbeitung mittels TemplateStyles in Vorlagen, dann ggf. in ANR oder per irgendwann möglicher Namensraum-spezifischer Gadget-Einbindung die Nutzung aus projektweiter CSS-Bereitstellung nach und nach zurückgebaut werden können. Dazu muss aber erstmal TemplateStyles einsatzfähig sein.
Name von dem Dingens, naja, „dewiki-und-Msg-Styles-Gadget“.

VG --PerfektesChaos 21:42, 18. Okt. 2022 (CEST)Beantworten

Die Content-Model-Änderung hatte ich kürzlich vorgenommen. Wieso wir die Farbklassen aus Mobile.css rausnehmen könnten, aus Common.css aber nicht, verstehe ich noch nicht. Zudem wäre noch zu klären, was die nur noch generelle Definition der hintergrundfarbe-Klassen für Auswirkungen auf Tabellen hat. Wenn ich mich recht entsinne, waren die Definitionen à la table > * > tr > th.hintergrundfarbe8 so, um in wikitables wirken zu können, die die Hintergrundfarben so spezifisch festlegen. Gruß, -- hgzh 12:01, 4. Nov. 2022 (CET)Beantworten

Neues Gadget: localUserOptions

Letzter Kommentar: vor 1 Jahr10 Kommentare2 Personen sind an der Diskussion beteiligt

Aufgabe: Für zahlreiche Anwendungen LocalStorage einfach verfügbar machen.
Betrieb: hidden default
Code: Benutzer:PerfektesChaos/js/localUserOptions.js
Anwendungen:
- watchlistMessage
- Nachfolger unserer Navileisten-Ausblendung mögen ein Gedächtnis bekommen.
- Zukünftig gäbe es von bestimmten Vorlagen ausgelöste JS-Gadgets, die dann interaktive Elemente einfügen könnten, namentlich Ausblendungs-Schaltzustände usw.
- Speicherung lokaler Cookie-Zustände, auch wenn alle Cookies bei Browser-Ende gelöscht würden, und Wiederherstellung falls mit leeren Cookies aufgewacht.
- Vorstellbar wäre auch eine Ausblendung der Rechtsbelehrung bei Quelltext-Bearbeitung für angemeldete auf 7 Tage. Da wäre das Benutzerkonto zu hinterlegen, und nach einer Woche muss die Ausblendung erneut bestätigt werden.
Besonderheiten:
- asynchrone Nutzung: Kontakt über mw.hook mit Callback-Funktionen
- Eingebautes Vergessen; alle Zuweisungen erhalten eine Lebensdauer von maximal etwa 10 Monaten. Das vermeidet Kumulation und Karteileichen bei nicht mehr genutzten Anwendungen.
Beispiele, in JS-Konsole ausprobierbar:

// Abfrage aktueller Stand, Meldung in Fehlerkonsole
mw.hook( "localUserOptions.fetch" )
  .fire( { sign: "Hello world",
           found: function (a){console.log(a)} } );
// Wertzuweisung; ohne Zeitlimit ergibt 24 Stunden
mw.hook( "localUserOptions.fill" )
  .fire( { _sign_: "Hello world",
           Name:   "Hugo" } );
// Wertzuweisung; mit Zeitlimit 5 Minuten
mw.hook( "localUserOptions.fill" )
  .fire( { _sign_:    "Hello world",
           _minutes_: 5,
           Name:      "Hugo" } );
// Nach zehn Minuten neue Seite aufbauen, Abfrage abschicken, ist dann vergessen.

Noch’n Feature:
- Mir fällt soeben auf, dass bei angemeldeten das Benutzerkonto noch an den Identifizierer angehängt werden müsste.
- Weil mehrere Benutzerkonten könnten sich ein Browserprofil teilen.
- Nicht angemeldete teilen sich einen Einstellungssatz.

VG --PerfektesChaos 15:29, 31. Jul. 2022 (CEST)Beantworten

Multi-Account-Code wurde geschrieben, aber noch nie getestet. to be continued VG --PerfektesChaos 17:08, 5. Aug. 2022 (CEST)Beantworten

Multi-Account-Code wurde kursorisch durchgetestet, scheint alles wie beabsichtigt zu funktionieren, Code a.a.O. einbindbar. VG --PerfektesChaos 17:03, 6. Aug. 2022 (CEST)Beantworten

Folgendes scheint mir hier relevant zu sein: gerrit:804591 und phab:T121646 - ohne jetzt genauer hingeschaut zu haben, würde das wohl einen selbstgebauten Ablaufmechanismus unnötig machen. -- hgzh 08:01, 17. Aug. 2022 (CEST)Beantworten

@PerfektesChaos: ich würde das gern mal auf Beta mit dismissableNotice (ex watchlistMessage) erproben. Kann ich mir das nach Beta kopieren? -- hgzh 23:47, 10. Feb. 2023 (CET)Beantworten

Ich kopiere dir voraussichtlich heute Nacht die aktuellste Version auf BETA:Gadget-.

Ist ein halbes Jahr her, ich habe alles vergessen.
Möglicherweise gibt es eine frischere und/oder robustere Version; muss ich mich erstmal einlesen und diffen. Hatte zwischenzeitlich irgendwann irgendwas geändert; weiß nicht mehr wo bereits eingeflossen.

Spoiler-Warnung: Es gibt eine Anwendung, die von sowas Gebrauch machen will. Beschreibung dann hier, wird aber komplex.

Ich habe die MW-Version verglichen und kommuniziert.

Meines unterscheidet Benutzerkonten + 1×anonym.
Meines ist robuster bei JSON- und Daten-Fehlern, etwa durch manuelles Eingreifen des Users in seinen Storage oder Fehlfunktion oder Fehlbedienung von Werkzeugen oder Browser-Absturz. Löscht dann möglichst selektiv beschädigte Bereiche.

VG --PerfektesChaos 12:09, 11. Feb. 2023 (CET)Beantworten

Gut, danke. Die Expiry-Funktion in mw.storage kommt sowieso nicht in Frage, weil die sich ja nur auf einen ganzen Key bezieht, ich ja aber unterschiedliche Ablaufdaten bräuchte. Also hier nicht weiter relevant. -- hgzh 12:40, 11. Feb. 2023 (CET)Beantworten

Hab grad einen BETA-Blocker von einer Minute auf die andere kassiert. Wird sich erfahrungsgemäß in den nächsten Stunden lösen.

Gadget kommt dann, gebe Nachricht.
Ich scheine keine signifikanten Änderungen gemacht zu haben; obiges ist somit aktuell.

„ich ja aber unterschiedliche Ablaufdaten bräuchte“

Das ist aber bei allen Verfahren das Gleiche.
Es gibt nur einen key pro automatisches expiry mit diesen Bibliotheksfunktionen.
Die Methodik wäre eine andere:
- Entweder komplette Selbstverwaltung in einem Objekt dismissableNotice und selbst erledigte nach Unix-Zeit rauslöschen.
- Oder jede Nachricht bekommt einen key: dismissableNotice.WiciCon.2023LastCall und der bekäme ein Ablaufdatum; in dem Fall von zwei Wochen und damit Verfall nach Ende der Veranstaltung.
- Wäre zu klären, was bei mehreren aktuellen Nachrichten passieren solle.
- Irgendwie war das schon mal im Zusammenhang mit dem modernisierten Gadget erörtert worden; käme ich drauf zurück.

VG --PerfektesChaos 14:35, 12. Feb. 2023 (CET)Beantworten

BETA ließ mich tagelang nicht rein, zwischenzeitlich schien ganz wmflabs down oder Tools über Stunden nicht erreichbar.

Dann kamst du aber zum Erproben auch nicht rein; also konnten wir die Angelegenheit auch um einige Tage verschieben.
Ich habe mir derweil mal ein paar Gedanken gemacht; ganz frisch und ohne nach meinen früher bereits mal ausgearbeiteten Vorstellungen zu gucken.
BETA live durch JS-Ersteller, noch ohne definition usw.

Anforderungen an unser Gadget:

Sowohl für watchlist wie für site mit derselben einen Ausführung wirksam.
Kein FOUC.
Auch ohne JS nutzbar, selbst wenn deren Apostel gegenüber unserer Kindergartenzeit heute minimal sein dürften.
Mehrere Banner gleichzeitig aktiv; drei Tage nach dem ersten mag eine dringliche zweite Meldung nötig werden. Wer die erste bereits weggedrückt hate, sieht nur die neue, die anderen dann eben zwei.
Das mit der unterschiedlichen anonymen SiteNotice hab ich grad nicht restlos durchschaut; müsste präziser definiert und dokumentiert werden. Ggf. von uns andere Methodik zur Definition einer SiteNoticeAngemeldetOnly.
Volle Mobil-Unterstützung.
Global (Angebot an andere Wikis).

SiteNotice

Wir nutzen deren Framework für die Platzierung in der Seite.
Mobil und Vector2022 sind tückisch.
Wir machen jedoch deren dynamische Elemente platt, falls unser localStorage wirksam.

MediaWiki:Watchlist-summary

Bisher nur eine Nachricht; zukünftig mehr.
Bisher nur mit JS; zukünftig auch nur CSS.
Bisher dem Namen nach nicht mobil.
MediaWiki:Common.js/watchlist.js entfällt dann.

Ablauf nach Seitenabruf:

Pseudo-Name jetzt mal dingens-notice als Arbeitstitel.
JS aktiv, Laden wird gestartet; wiederholter Code geblockt.
Herausfinden, ob NSN===8 und wenn ja Titel beginnend mit Gadget-**site** oder Gadget-**watch** (und wenn ja ob Content Model gleich wikitext – aber eigentlich egal). Wenn, dann Schalter Larry=true.
Bin ich Watchlist? Wenn, dann Schalter ListWatch=true.
DOM abwarten.
Nachdem DOM rettich:
- Wenn Larry dann nach dem MW-Selektor suchen und ein solches Element aus der Seite löschen, anschließend in jedem Fall Ausführung beenden.
- Gibt es ein Element mit hasClass unserer dingens-notice? Wenn nicht, dann jetzt Ausführung beenden.
Situation: Es gibt mindestens ein Element mit unserer Klasse in der Seite.
- Unser localStorage laden.
- Nachdem eingetroffen:
  - Welche ID sind bereits hinterlegt, falls überhaupt?
  - Ist localStorage schreibbar?
    - Das Limit für localStorage könnte überzogen sein, oder zum Privacy-Schutz blocken manche User und Browser das Hinterlegen verborgener Wiedererkennungs-Codes früherer Seitenbesuche.
  - Wenn es ein Objekt gibt, wird für alle unsere ID in der Seite geprüft, ob es einen Objekt-Eintrag mit booleschem Typ gibt.
    - Wenn es eine bereits bekannte ID gibt, wird dieses Element aus der Seite gelöscht.
  - Wenn es mindestens eine Löschung aus der Seite gab, wird die Ergebnismenge gefundener Elemente unserer Art aktualisiert.
- Wenn es kein Element mit dieser Objekt-ID in der Seite (watchlist?) gibt, dann diesen Eintrag aus dem Objekt löschen.
- Wenn es keines unserer Elemente gibt, wird ein MW-site-Block aus der Seite gelöscht.
- Wenn es hingegen einen MW-site-Block geben sollte, wird (ggf. nach einigen Millisekunden) das MW-Einklappen aus der Seite gelöscht, sofern unser localStorage schreiben kann (sonst alter MW-Cookie-Mechanismus mit ID=99999).
- In jeden einzelnen unserer Blöcke wird ein Button [Ausblenden] eingefügt und mit click() versehen.
- Der style für CSS-Ausblenden wird aus der Seite eliminiert.
- Wenn localStorage schreibbar, dann rechts daneben weiteren Button einfügen: [Erledigt] title="Dauerhaft entfernen"
- Wenn [Erledigt] angeklickt, dann:
  - Element aus der Seite löschen.
  - Neue ID dem Objekt hinzufügen.
  - Dabei Booleschen Wert je nach Art des Elements:
    - true – watchlist
    - false – site

localStorage-Ökonomie

Gemäß Algorithmus bleibt der allerletzte Eintrag im Objekt zurück, nachdem der Bannertext administrativ genullt wurde, weil nunmehr nicht mehr ein Element mit unserer Klasse in der Seite vorhanden ist und deshalb unser Gadget nicht mehr geladen wird.
Das sind mitsamt expiry vielleicht 100 Bytes oder sowas.
Wurscht. Es geht nur darum, dass die key in der localStorage nicht über mehrere Jahre kumulieren.
Der key als solches erhält aber ein expiry von 14 oder 30 oder wasweißich Tagen; 14400 Minuten sind zehn Tage.
Nach dem letzten Erledigt bleibt ein Eintrag noch für zwei Wochen tot stehen und wird dann komplett von der localStorage-Verwaltung entsorgt.
Nix in 2022.

FOUC

Früher gab es kein CSS-Fading, was mittlerweile immer erwartet werden darf.
Es ist heutzutage wohl extrem selten, dass jemand ohne JS arbeitet, aber das müssen einige ganz hartnäcktige sein.
Ich würde deshalb absolute überdeckende Positionierung statt reinschieben und rausruckeln vorsehen.
Die Überdeckung passiert 500–1000 ms nach Seitenaufbau, damit JS Zeit bekommt, um unerwünschtes erstes Aufblitzen vor abgeschlossener JS-Ausführung zu vermeiden.
- Ggf. mit Steigerungsverlauf in den zweiten 500 ms und 10 % verbleibender Transparenz.
Nach pro Nachricht konfigurierbarem Intervall von 15 bis 60 Sekunden faded sich der Inhalt wieder weg, falls kein JS aktiv ist. Pech. Block das Zeugs halt nicht.
Die CSS-Eigenschaft transition bietet hinreichende Möglichkeiten, um ein Non-JS ablaufen zu lassen.
Ggf. wäre ein Reinschieben ohne Überdeckung nach 1 Sekunde realisierbar, aber das kommt in der Community erfahrungsgemäß nicht gut an, weil der bereits zu Lesen begonnene Text vor den Augen abrutscht. Dann besser drüberklatschen, Kenntnisnahme, erledigt.

Objekt-Beispiel, oben Beo:

{ "WikiCon2024LastCall": true,
  "Serverwartung 2023-03-01 15:00": false
}

HTML-Block für Beo, sonst eine class weniger; ID HINTERGRUND RAHMEN INHALT ersetzen, kann man noch opacity-Animation von 0 bis 0.9 verwursten:

<div class="dingens dingens-watchlist"
     style="clear: both; position: absolute; visibility: hidden;"
     data-id="WikiCon2024LastCall">
<div style="background‑color: #HINTERGRUND; border: #RAHMEN 3px solid; border-radius: 4px; opacity: 0.9; transition: visibility 750ms; visibility: visible;">
<div class="dingens-fadeout"
     style="transition: visibility 30s; visibility: hidden;">
INHALT
</div>
</div>
</div>

Bedarf einer übersichtlichen /Editnotice sowie guter Gadget-Doku.
JS überschreibt in .dingens-fadeout die visibility mit visible oder löscht auch gleich noch die ganze transition .
HTML-Code freihändisch ungetestet nur Symbolbild.

VG --PerfektesChaos 12:53, 15. Feb. 2023 (CET)Beantworten

Ich hab das alles noch nicht so ganz restlos durchdacht und verstanden, aber ich nehme es auf. -- hgzh 18:28, 24. Feb. 2023 (CET)Beantworten

Deutsche Titel bei Spezialseiten

Letzter Kommentar: vor 2 Jahren11 Kommentare6 Personen sind an der Diskussion beteiligt

Hintergrund Spezial:PermaLink/226978873#Spezial:TopicSubscriptions, zu ändern wären (Liste von hgzh, hab mal mit paar Vorschlägen angefangen, gerne einfach ergänzen):

Was mir auch noch aufgefallen ist: Spezial:Verwaltung Benutzerkonten-Zusammenführung könnte man an den angezeigten Titel Spezial:Globale Benutzerkonteninformationen anpassen, für die SUL-Zusammenführung wird die Seite doch nicht mehr benötigt… VG, –IWL04 • 18:09, 12. Okt. 2022 (CEST)Beantworten

Das ist nichts was hier bewirkt werden kann.

Damit der Parser sowas versteht, muss PHP geändert werden, und dann ist die Frage ob nur für dewiki oder für alle de.

Also Phab-Ticket, gestützt auf einen Community Consensus.

Dazu muss für jede nachträgliche Übersetzung in projektoffener Diskussion erörtert werden, welches die beste Formulierung wäre.

Brauchen wir das? Bei allen? Gäbe es auch größere Probleme? Wem hülfe dies?

Spezial:DeletePage und Spezial:ProtectPage könnten nur Admins; nutzen die das jemals? Jedenfalls nicht massenwirksam. An jeder Seite NR≥0 ist ein Link um genau dies auszuführen.
Spezial:LintErrors – das gibt niemand direkt ein, verlinkt sich bei den Wartungsameisen. Die kennen die Seite.
GadgetUsage nutzen Programmierfexe.
Seiteninformationen – sicher wichtig, aber wer kommt per Spezialseite dorthin, und nicht über Verlinkung auf der fraglichen Seite?

VG --PerfektesChaos 19:10, 12. Okt. 2022 (CEST)Beantworten

@PerfektesChaos Das Thema kann durchaus hier behandelt werden. Wir müssen es nicht komplizierter machen als notwendig. Wenn es vernünftige, projektneutrale Übersetzungen sind, können wir sie auf Basis der hiesigen Sammlung als Patch einreichen. --Raymond ^Disk. 20:25, 12. Okt. 2022 (CEST)Beantworten

Ich würd mir erstmal die Frage stellen, wer wann wozu die Spezialseiten überhaupt benötigt?

Bearbeitungskommentare, Logbuchaktionen: Hier sind keine URL möglich, und Spezial:Diff/226930539/226982225 sowie Special:PermaLink/250456846 sind für die Funktionalität wichtig.
Spezial:Spezialseiten ermöglicht Navigation zu vielen Effekten. Dabei sieht aber niemand wie die heißen. Die Verlinkung wird angeklickt und gut ist.
Versionsgeschichte und Seiteninfo werden von den Verlinkungen der aktuellen Seite aus angesteuert. Ich kenne niemanden außer mir, der das im Wikitext zur Verlinkung per Spezialseite angibt, und glaube auch nicht dass irgendjemand solch eine Spezialseite in das Suchfeld eintippt. Die macht dann auch wieder action=info und action=history draus; niemand sieht die also in der URL und hat irgendeine Berührung damit.
Vieles wird nur von IT-Experten genutzt, und dann auch nur über Spezial:Spezialseiten oder von einer Hilfeseite aus navigiert: PasswordPolicies BotPasswords AutoblockList ChangeCredentials RemoveCredentials PagesWithBadges EntityUsage GadgetUsage ApiSandbox GraphSandbox – niemand weiß auswendig, auf welcher Spezialseite das stünde, und wie die genau hieße, und würde den Namen in das Suchfeld eintippen. Und zusätzlich zum englischen Namen sollen die Handvoll IT-ler sich noch deutsche Lokalisierungen merken?
Welcher Admin hat denn schon mal via Spezialseite eine Seite gelöscht?

Wer genau hat jetzt welches Problem womit?

VG --PerfektesChaos 20:45, 12. Okt. 2022 (CEST)Beantworten

Naja, mindestens bei TopicSubscriptions, FindComment (= Teilnehmer in Diskussionen), 2FA-Kram (= Admins, zukünftig mglw. mehr), Passwortkram (= alle Benutzer), PagesWithBadges, EntityUsage (= Wikidata-Pflege) und Contribute (= Mobilnutzer) sehe ich derzeit oder zukünftig schon einen etwas breiteren Anwenderkreis, sodass eine Lokalisierung zumindest dieser Seiten erstmal naheliegend ist. Die anderen könnte man in dem Aufwasch sicher mitmachen, auch wenn die weiterleitenden Spezialseiten nun nicht die Wichtigsten sind. Aber wir haben eben bspw. auch Special:Weiterleitung, Spezial:Neuer Abschnitt, Spezial:Permanentlink und die ganzen Zufallsseiten lokalisiert. Und die kanonische Form funktioniert ja weiterhin. Gruß, -- hgzh 22:09, 12. Okt. 2022 (CEST)Beantworten

Grundsätzlich wäre ich dafür, dass diese Spezialseiten genau den Namen haben, der eben auch schon als deutscher Titel angezeigt wird, sonst ist das inkonsequent. Wir müssten also in erster Linie die bestehenden Übersetzungen hier absegnen, dann die Seiten umbenennen lassen und alles ist gut. Gruß --XanonymusX (Diskussion) 22:11, 12. Okt. 2022 (CEST)Beantworten

Also, Contribute würde ich eher von Mobil ausgeblendet haben wollen, falls das jemals da auftaucht. Ich fürchte, es wird. Genau so ein Dings hatten wir schonmal vom Desktop verbannt. Es forderte unangemeldete Benutzer dazu auf mittels CX einen Artikel aus einer anderen Wikipedia automatisch zu übersetzen und dann hier anzulegen, oder alle noch nicht verlinkten Wörter in einem Artikel zu verlinken, und derlei Unfug.

Es ist nicht erforderlich, nur um des Übersetzens willen alles und jedes zu lokalisieren, wenn es niemand gibt, der die Spezialseite benötigt oder seltener als einmal pro Jahr anfasst und dann ohnehin aus einer Hilfeseite kommen muss. Viel wichtiger wäre es, auf einem Dingens egal wie es heißt verständliche auf der Seite sichtbare Handlungsanweisungen zu geben. Ohne Hilfeseite sind viele der aufgezählten Angelegenheiten ohnehin unbegreiflich, und auf der steht dann auch die Verlinkung zum Anklicken.

H:SS/L ist lang genug, und mir kann niemand erzählen dass Normalsterbliche all diese Seiten wirklich benötigen und sich deutschsprachig oder auch nur englischsprachig merken können.

VG --PerfektesChaos 22:45, 12. Okt. 2022 (CEST)Beantworten

Alles richtig. Aber sie sind eben schon übersetzt (soweit meine Stichproben gereicht haben), nur wurde das nicht konsequent auf den Seitennamen angewendet. Wie man all die Seiten finden und verstehen soll, ist ein anderes Thema (mir ist der Großteil auch unbekannt). Gruß --XanonymusX (Diskussion) 23:11, 12. Okt. 2022 (CEST)Beantworten

Ich habe jetzt mal alle Überschriften der Spezialseite oben eingetragen. Bitte ändert gerne auf ggfs. sinnvollere (kürzere?) Namen ab. Nur bei PageHistory müssten wir eine Alternative finden. Raymond ^Disk. 12:33, 13. Okt. 2022 (CEST)Beantworten

Durch MW übersetzt wurde wohl durchgängig die auffallend sichtbare Seitenüberschrift, nicht jedoch immer der in der Adresszeile von Desktop-Browsern sichtbare und bei Verlinkungen und für das Suchfeld benötigte (Alias-)Bezeichner.

Jeder technisch wirksame Alias, jede Weiterleitung einer Seite oder Alias eines Parameternamens ist eine Verkomplizierung des Systems.

Es zwingt alle Beteiligten dazu, sich zu merken, dass Y dieselbe Wirkung hat wie X und nichts Neues ist, und bei Suchvorgängen alle Aliasse durchzuprobieren.
Spezial:PageHistory ↔ Spezial:Versionsgeschichte lässt schon erahnen, welche Verwirrung und Konflikte diese Aktion zukünftig verursachen wird. „Benutzerbeiträge“ aka „Contribute“ ist das nächste Drama schon vor der Tür.
Spezial:PageInfo/WP:MW/Ä bewirkt in der Adresszeile wieder die URL mit action=info und die VG analog action=history, bleibt also englischsprachig. Diese Spezialseiten als WL auf URL wurden nur systematisch eingeführt, um gelegentlich Verlinkungen zu ermöglichen, wo URL nicht angebracht sind. Wobei Spezial:Weiterleitung/user/310926 zwingend die englischsprachigen Schlüsselwörter page und user erfordern – wird also bestenfalls Denglisch, bewahrt uns aber vor Gender-Aliassen.
Seiteninfo und VG werden über die an der betreffenden Seite angebrachten Verlinkungen angeklickt, und wenn jemand in FZW oder Artikeldisk eine derartige Darstellung zitieren möchte, dann wird die URL kopiert und verlinkt und gut ist. Niemand geht im Normalbetrieb zum Bearbeiten einer Seite erst auf eine Spezialseite und versucht dann diese Seite zu finden.
Spezial:PageInfo wird außerhalb der hier erörterten Lokalisierung und ihrer Hilfeseiten auf einer Benutzerseite und einer Portalseite genutzt. Das rechtfertigt keinen Alias.
In Systemnachrichten und Vorlagenprogrammierung ermöglichen die Spezialseiten-Aliasse gelegentlich einen eleganteren und übersichtlicheren Quelltext als die URL. Dann mögen sie genutzt werden, aber dort sind dann auch #switch und #ifeq im Spiel, und wer damit außerhalb des Sichtfeldes von Newbies zugange ist kommt auch mit PageInfo klar. Vor Benutzung muss ohnehin H:SS/P konsultiert werden.
Wir haben auch einen Alias Spezial:Kaputte Weiterleitungen verlangt, der sich (118 Treffer) mit „Defekte Weiterleitungen“ (288 Treffer) beißt, neben BrokenRedirects (31 Treffer). Hilfe:Weiterleitung kennt das Wort „kaputt“ nicht; projektüblich sind nur „Defekte“ wie auch in WP:DWL.

Wenn die aktive Verwendung im Publikum seltener als einmal jährlich oder nie zu erwarten ist, weder im Suchfeld noch bei Konstruktion von Verlinkungen, dann sind Lokalisierungen der Bezeichner eher schädlich als hilfreich.

Ein systematisches Vorgehen, um koste es was es wolle jeden momentan wirksamen Bezeichner einer Spezialseite unbedingt auch lokalisiert wie die momentan dargestellte Überschrift anzubieten, ist strikt abzulehnen.
Wer sich langweilt, möge sich lieber darum kümmern, dass in der dargestellten Seite selbst eine in dem Moment hilfreiche Anleitung gegeben wird, und auf eine zugehörige Meta-Seite verlinkt wird, und dass es überhaupt eine Beschreibung der Funktionalität auf unseren Seiten gibt. Da gibt es in obiger Liste wesentlich größere Defizite.

VG --PerfektesChaos 13:39, 13. Okt. 2022 (CEST)Beantworten

Zu PageHistory: Könnte da nicht Seiten- oder Versionsrückblick (oder auch -verlauf) passen? --Funkruf

^WP:CVU 16:58, 13. Okt. 2022 (CEST)Beantworten

Neues Gadget: CoordinatesPagePopup.js

Letzter Kommentar: vor 1 Jahr5 Kommentare2 Personen sind an der Diskussion beteiligt

Hintergrund: laufende Umstellung infolge von Wikipedia:WikiProjekt Georeferenzierung/Migration Seiten-Koordinate 2023 und diverse Anmerkungen und Überlegungen auf Vorlage Diskussion:Hinweis Seiten-Koordinaten.

Anwendungsfall: da die Darstellung der Seitenkoordinaten oben rechts für Desktopnutzer wegfällt und diese in einen entsprechenden Hinweiskasten verschoben werden, ist der Weg zu den Koordinaten etwas länger geworden, was insb. bei häufigem Zugriff auf Koordinaten umständlich ist. Mittels eines Popups soll eine Art Mittelweg zwischen der bisherigen und zukünftigen Darstellung gefunden werden.

Implementierungsdetails: Das Gadget prüft, ob ein entsprechender Indikator und der Hinweiskasten vorhanden sind. Ist beides der Fall, wird der Inhalt aus dem Hinweiskasten in einem Popup gespiegelt, das beim Überfahren des Indikators mit der Maus erscheint. Ein Klick auf den Indikator springt weiterhin zum Hinweiskasten.

Vorbedingungen: innerhalb der Vorlage:CoordinatesPage wäre ein Element hilfreich, dass die im Popup zu spiegelnden Texte enthält. Im gegenwärtigen Zustand funktioniert auch ein rudimentärer Selektor, aber sobald sich da etwa noch der WikiMiniAtlas oder das OSM-Gadget reinhängen, müsste eine saubere Unterscheidung getroffen werden können.

Geplante Aktivierung: default, aber individuell abschaltbar. Skins: alle, außer Minerva. Actions: view.

Code: https://de.wikipedia.beta.wmflabs.org/wiki/Benutzer:Hgzh/CoordinatesPagePopup.js

Gerne Feedback bzw. Review. Gruß, -- hgzh 22:57, 20. Jul. 2023 (CEST)Beantworten

Bedaure, aber ich möchte nicht, dass dies auf ewig ein von der BOA-Community zu pflegendes Gadget wird.

Gründe:

Der Personenkreis ist zu eng begrenzt. Es geht letztlich um wenige Hundert Veteranen, die ihr „ich will meine Welt auf immer so behalten wie sie immer schon gewesen ist“ konservieren möchten.
Die Screengrabbing-Programmierung ist viel zu komplex und damit änderungsanfällig und wartungsaufwändig, als dass das einfach mal so eben auf ewig gepflegt werden kann. Das ist dann eine ewige Hypothek für unsere Enkel.
Wenn so etwas erstmal als Community-Gadget angeboten wurde, dann fordern die Veteranen, dass die BOA das auf Gedeih und Verderb auf ewig immer irgendwie bereitstellen müssen. Auch wenn es nur noch drei Konten gibt, die das verwenden.
Für anonyme Konten ist das nichts. Die Trefferquoite (maximal Dreiviertelmillion unter 20 Millionen Seiten) ist viel zu schlecht, um jede Seite erstmal komplett durchsuchen zu müssen. Anonymes Publikum erwartet derartige Angebote dort auch überhaupt nicht.
Default deshalb auf gar keinen Fall, auch nicht für Angemeldete.
Das Desktop-Design und das Mobil-Design sollte möglichst analog sein, sofern nichts durch die Platzverhältnisse erzwungen wird. Wenn die MediaWiki-Superhelden endlich mal nach einem Jahrzehnt entscheiden, ob sie die Seitenindikatoren in die obere oder untere Icon-Leiste einfügen möchten, dann können auch die mobilen genau gleichartig die Funktionalität wie beim Desktop bekommen, also Icon-Klick. Die enzyklopädischen Inhalte in jeden Smartphone-Seitenkopf hineinzudreschen wird diesen wohl zersprengen. Enzyklopädische Inhalte gehören in den Inhaltsbereich, die Navigation durch Projekt, Seitenfunktionen und Benutzerkonto gehören in den Portalrahmen.
Wer nicht zu den Veteranen gehört, erwartet auf keiner Skin derartige weggebeamte Inhalte. Es ist letztlich ein rein psychologisches Problem: Wer erstmal auf diesen uralten Hack angefixt wurde, bekommt Entzugserscheinungen und jammert; wer das noch nie sah, kommt überhaupt nicht auf die Idee, völlig willkürlich sowas zu erwarten und vermisst auch nichts. Die kommenden Generationen brauchen sowas nicht.

Als persönliches Benutzerskript kannst du das ja gern dokumentieren und im Kurier annoncieren.

Bei einem Benutzerskript steht der Nick des Alleinverantwortlichen zwischen dem ersten Doppelpunkt und dem ersten Schrägstrich.

Inhaltlich schau ich mir den Code gern an, aber brauche unter den momentanen kühlen Nächten etwas, bis ich all das aufgearbeitet habe, was in den Glutwellen liegenblieb. Ich hab pro Tag immer nur wenige Viertelstunden zum Denken.

VG --PerfektesChaos 23:29, 20. Jul. 2023 (CEST)Beantworten

Ich sehe das anders.

Dass die Koordinaten oben rechts erscheinen, ist seit vielen Jahren und in zahlreichen anderen Sprachversionen so. Das ist ja an sich auch keine blöde Idee, sonst hätte man sich den Aufwand mit dem blöden Hack nicht gemacht, zumindest nicht aus Spaß an der Freude dort irgendwas mit absoluter Positionierung reingedengelt. Schnell nachschauen, wo das Artikelobjekt überhaupt liegt und dann die Einleitung weiterlesen ist nichts, was nur wenige hundert Veteranen machen, sondern ziemlich praktisch. Die Lebensdaten bei Personen stehen ja auch nicht nur in den Personendaten, sondern in der Einleitung dabei (um mal einen zugegeben etwas hinkenden Vergleich zu wählen).

Screengrabbing wird da problematisch, wo wir wenig Kontrolle haben, also bspw. in irgendwelchen MediaWiki-Softwarekomponenten, die sich unbemerkt ändern. Hier greifen wir nur auf eine lokale und ziemlich statische Vorlage zu, über die wir die volle Kontrolle haben. Sicher wird die Zeit kommen, in der mal eine Anpassung nötig werden wird, aber wie oft kam das bei der Koordinatenvorlage vor? Die ist ja immer noch die gleiche wie vor 15 Jahren, weshalb wir diesen Tanz hier ja überhaupt erst tanzen. Und komplex ist das Gadget nun wirklich nicht, immerhin hat es ein in JS relativ unbedarfter Benutzer:Hgzh geschrieben - Anpassungen bekommt man hin. Als Ausgleich könnte ich anbieten, MediaWiki:Gadget-contribsrange.js der Wartung zu entziehen, niemanden hat gestört, dass es bis vor kurzem kaputt war und mit IP-Masking wird es wohl sowieso nicht mehr funktionieren.

Dass ein Leser ein Angebot für Koordinaten oben rechts nicht erwarten würde, nachdem diese 20 Jahre lang dort zu finden waren, würde mich überraschen. Wie oben schon angedeutet, halte ich die Darstellung dort für nicht schlecht, eben nur bisher schlecht gemacht. Der Nutzen überwiegt die Last (900 Bytes minified) für mich. Wo kommen die 20 Millionen Seiten her? Special:Statistik nennt gerade mal 7,7 Mio. Als Default-Gadget läuft es ohnehin nicht Gefahr, nur noch von drei Leutchen genutzt zu werden, es sei denn, der KI übernimmt irgendwann die Ausspielung des wikiweiten Koordinatenwissens ;)

Der Unterschied zwischen Mobil und Desktop wird für mich hier über die Bedienung erzwungen, touch kennt nun mal kein hover; Zustimmung zum Platz - aber wieso nicht die Stärken des jeweiligen Bedienmittels nutzen? Um die Mobilversion geht es ja hier explizit nicht.

Gruß, -- hgzh 16:35, 21. Jul. 2023 (CEST)Beantworten

Über den Icon (zurzeit nur Desktop, irgendwann auch mobil, anders als dieser Vorschlag) ist die wirksame und kommentierte Verlinkung einen (in Worten: einen) Mausklick entfernt.

Es wird immer so getan, als ob das allerallererste, was irgendjemand machen wird, der auf eine Seite kommt, sich den Längengrad und den Breitengrad anzugucken und dann noch vor dem Lesen des Einleitungsabschnitts die Karte mit der Umgebung aufzurufen.

Das bezweifele ich allerdringendst.
Ich sehe auch keinerlei Nachweis, dass dies bei Millionen im Publikum und auch nicht in der Autorenschaft die eine allerwichtigste und dringlichste Aufgabe sei.
Ich gehe davon aus, dass bei einem von Tausend Artikelbesuchen mal jemand derartige Karten angucken möchte. Es sei denn, es wäre die eine Autorin, die serienmäßig chilenische Bergdörfer neu einbaut. Die hat aber noch gar keine Koordinaten im Artikel zu stehen. Und auch bei einer pflegenden Kontrolle reicht ein einziger Mausklick zusätzlich.
Der Vorschlag ist ein recht komplexes Gadget, das zwangsläufig bei jedem Besuch der 20 Millionen Wikitext-Seiten und jeglicher Kombination der unendlichen Spezialseiten-Auswertungen gestartet werden müsste. Das ist eine unverhältnismäßige Belastung bei einer Dreiviertelmillion Erfolge beim Finden und einem von 1000 nachfolgenden Kartenbesuchen, nur um einen Mausklick einzusparen.

Es ist eigentlich nur ein psychologisches Problem, das diejenigen haben, die ihr Monobook von 2005 in Ewigkeit genauso wie es immer schon war beibehalten möchten.

Das sind aber 100 oder 200 Menschen, und werden zwangsläufig weniger werden. Alle die das noch nie sahen oder die Karte ohnehin fast nie angucken wollen vermissen nichts.
Hätte man damals in allen Artikeln über Personen das Geburts- und Sterbedatum zwischen die Verlinkung von Diskussionsseite und Quelltextbearbeitung gequetscht, dann wäre auch das zum absolut unverzichtbaren Wesenskern aller Wikipedien geworden.
Nur weil 2004 mal jemand in der enWP eine unverzeihliche Pfuscherei in die Welt gesetzt hatte und alle Wikis das gedankenlos abkopiert hatten, ist es noch lange kein lebensnotwendiges Feature. Die Wikis waren in der ersten Hälfte der Nuller Jahre in der Krabbel- und Selbstfindungsphase; niemand wusste wo das alles enden würde, und jede Bastelei die jetzt erstmal irgendwie funzte wurde halt abkopiert. Gute Techies machen jedoch nicht alles was technisch möglich ist.

Die Hartgesottenen können sowas gern als Benutzerskript installieren.

Ein neuerliches Angebot durch die Community, das dann bis zum jüngsten Tag am Leben gehalten werden muss, lehne ich strikt ab.

Seit einem Dutzend Jahren haben wir aus sehr guten Gründen kein komplexeres hier entstandenes JavaScript mehr im Konsens und nach Absprache neu in die Community gebracht.

Alles wird nur noch auf WP:HX angeboten.
Wir haben noch mangelhaft gepflegtes Community-JavaScript und Schnarks vielgenutzte Bibliothek, die auch an sich ändernde Umstände angepasst werden müsste. Und Common.js usw. müssten ebenfalls saniert, ausgedünnt und modernisiert werden.
Wir haben noch nicht einmal qualifiziertes Personal, um den Bestand ordentlich zu pflegen. Die meisten BOA stehen nur auf der Liste und können Zeichenketten in markAdmins ersetzen.
Wir haben absolut keinerlei Kapazitäten, um neue komplexe Community-Funktionalitäten in die Welt zu setzen und dauerhaft zu pflegen.

Jedes Mal, wenn eine der Funktionalitäten von 2004 beendet werden soll, wird Mord und Totschlag angedroht und der sofortige Weltuntergang heraufbeschworen.

Wir haben überhaupt keine Möglichkeit, eine leichtfertig in die Welt gesetzte und überflüssige Community-Funktionalität wieder zu beenden.
Schon wenn aus unbenannten Vorlagenparametern benannte werden sollen, wird nach Meinungsbild gebrüllt und das Ende der Autorenarbeit angekündigt, eine weitere Projektmitarbeit wäre damit unmöglich.
Dabei sind es letztlich nur zwei Dutzend Leutchen, die aber lautstark auftreten, sechsstelligen Editcount haben und seit 2004/2005 dabei sind. Alle anderen Projektinteressen, wie das von 10.000 anderen Wikipedistas, oder gute Performance oder robuste und einfache, wartungsfähige Strukturen sind völlig wurscht.

Wenn die Community bei jeglicher minimalen Veränderung so ein Affentheater aufführt, dann dürfen keine neuen Community-Programmierungen mehr in die Welt gesetzt werden.

VG --PerfektesChaos 17:54, 21. Jul. 2023 (CEST)Beantworten

Einig werden wir uns diesbezüglich wohl hier nicht. TBC, hab aber gerade keine Zeit dafür. -- hgzh 18:30, 27. Jul. 2023 (CEST)Beantworten

Vereinheitlichung der DBL-Einträge

Letzter Kommentar: vor 10 Monaten22 Kommentare4 Personen sind an der Diskussion beteiligt

Gudn Tach!

Vorgeschichte: Wikipedia:Bots/Anträge_auf_Botflag#2023-10-24_–_CamelBot (und davor WP:AN#MediaWiki:Spam-blacklist_->_Spezial:BlockedExternalDomains).

Zusammenfassung:

Special:BlockedExternalDomains (kurz DBL für Domain-Blacklist) bietet ist ein neues Admin-Tool, mit dem die WP:SBL entlastet werden soll. Es bietet zwei Felder an: 1. zu blockierende Domain, 2. Bemerkung.
Am Ende werden die Einträge in MediaWiki:BlockedExternalDomains.json gespeichert, eine Datei die grundsätzlich auch direkt bearbeitet werden kann.
Es ist im Hinblick auf (automatisierte) Durchsuchbarkeit und Nachvollziehbarkeit sinnvoll, das Bemerkungsfeld mit mehreren Standardinfos (wann, welcher Admin, weshalb = Link auf Diskussion) und einheitlich zu befüllen.
Das UI ist sehr spartanisch und führt leicht zu uneinheitlichen und unvollständigen Einträgen, wie man bereits an anderen Sprachversionen sieht, z.B. en:Special:BlockedExternalDomains.

Denkbare Lösungen:

(Ein Bot könnte die Einträge automatisiert postprozessieren. Nachteile: 1. Es ist schwierig, einem Bot das Recht zu geben, die json-Datei zu bearbeiten; 2. Man ist abhängig von nicht in der Wikipedia gehostetem Code.)
Per JS könnte man das Bemerkungsfeld vorausfüllen lassen. Beispielhaftes Script: user:Lustiger_seth/admin_stuff.js. Nachteile: 1. Alle Admins, die mal die DBL bearbeiten wollen, müsste vorher das Script aktivieren oder jemand kümmert sich um die manuelle Nacharbeit des json-Files.
PerfektesChaos schlug ein Community-Gadget vor, das ans Recht editsitejson geknüpft wäre. Nachteil: Irgendwer müsste es erstellen oder zumindest ein Grundgerüst, in das dann der eigentliche Code eingefügt wird (wobei der o.g. Code wohl noch nicht die Qualitätsrichtlinien erfüllt).

Wegen des letzten Lösungsvorschlags bin ich hier. Verstehe ich es richtig, dass das Gadget dann automatisch bei allen Admins aktiv wäre? (Fänd ich sinnvoll.) -- seth (Diskussion) 20:04, 4. Nov. 2023 (CET)Beantworten

Also prinzipiell habe ich, wie schon gesagt, nichts dagegen.

Ein Gadget anzulegen ist nicht weiter schwierig, hier wäre es etwa MediaWiki:Gadget-domainBlacklist.js inkl. der erforderlichen Einbindung in MediaWiki:Gadgets-definition. Dort kann man festlegen, dass das Gadget nur für Nutzer mit editsitejson-Recht, nur auf Spezialseiten geladen, standardmäßig aktiv, deaktivierbar werden soll. -- hgzh 20:21, 7. Nov. 2023 (CET)Beantworten

Gudn Tach!

Ok, danke für die Hinweise. Zum Verständnis ein paar Fragen:

MediaWiki:Gadget-domainBlacklist.js kann ich erstellen, ohne dass das etwas am Verhalten der Software ändert, richtig?
Erst Änderungen an der MediaWiki:Gadgets-definition können das Script aktivieren bzw. schlimmstenfalls irgendwas kaputt machen, oder?
Soll ich schon mal den vorgeschlagenen Code in das JS-File packen, sodass man ihn anschließend überarbeiten kann?
Der Eintrag in der Definition wäre am Ende folgender?

domainBlacklist[ResourceLoader|default|hidden|namespaces=-1|rights=editsitejson|dependencies=mediawiki.config,mediawiki.user]|domainBlacklist.js

Kann man ein solches automatisch aktiviertes Script überhaupt irgendwie (z.B. per JS) deaktivieren bzw. persönlich für sich überschreiben? Oder geht das nur, wenn hidden nicht gesetzt ist (und dann einfach übers Web-Interface)?

-- seth (Diskussion) 23:39, 7. Nov. 2023 (CET)Beantworten

Das Gadget wird erst geladen, wenn es auf der Definitionsseite eingetragen ist, aber damit würde ich erst noch warten. Die JS-Seite kannst du von mir aus schon anlegen. In der Definition würde ich hidden weglassen, damit es über die Einstellungen deaktivierbar ist. Anzulegen wäre damit auch MediaWiki:Gadget-domainBlacklist, das die Kurzbeschreibung enthält und auch Wikipedia:Technik/Skin/Gadgets/domainBlacklist mit ausführlicherer Beschreibung, was das Gadget tut. Das kann aber nachgeordnet passieren. Dependency mediawiki.config dürfte nicht erforderlich sein.

Den Code schau ich mir später nochmal genauer an bzw. würde ihn dann direkt auf der Gadgetseite bearbeiten, ~~spontan springt mich const an, das als ES6-Element zwar in Userskripten, aber nicht in Gadgets funktionieren dürfte.~~ Geht mit requiresES6 in der Gadget-Definition. Gruß, -- hgzh 07:39, 8. Nov. 2023 (CET)Beantworten

Ich würde aus perspektivischen Planungsgründen eine längere ID verwenden, um für die Zukunft weitere Optionen offenzuhalten: Gadget-domainBlacklistSpecial
Ich empfehle, zuerst im BNR die Kinderkrankheiten zu beseitigen, und als allererste Version in MediaWiki: einen vorbildlichen Code der Nachwelt zu überliefern.
- const war mir auch schon aufgefallen, aus demselben Grund, und dient zur Verhinderung irrtümlichen Überschreibens in den weiteren Hunderten Programmzeilen. Bei momentan drei Statements eher nicht zu befürchten.
- Ich kann im Lauf des Tages eine Meckerliste zuliefern.

VG --PerfektesChaos 08:39, 8. Nov. 2023 (CET)Beantworten

zur namensgebung bitte überlegen ob nicht Block statt Black besser benutzt werden sollte:

es gibt bedenken bezüglich blacklist siehe T337431 und T254646

dann wäre es auch konsistent zum namen der neuen spezialseite (die ja perspektivisch an bedeutung gegenüber der alten lösung gewinnen wird)

--Wetterwolke (Diskussion) 14:13, 8. Nov. 2023 (CET)Beantworten

Wie angedroht:

Bezeichner:
- Dann SpecialDBL und dann ist wurscht was das „B“ bedeuten mag und der Bezeichner ist kürzer.
- Gadget zu einer Spezialseite halt, die mit dem DBL.
- „DBL“ ist dann das Nachfolgesystem zu SBL (WP:SBL), und während S=„Spam“ Litspam und Linkspam sein mag, geht es hier präziser um spammende URL-Domains.
- Das „Datenbanklink“ aus den schNuller-Jahren bekommt mal eine konkurrierende Interpretation des DBL. WP:DBL müsste leergeräumt werden, H:DBL bliebe. WP:DBL hätte 40 Bot-mäßig umbiegbare Einträge und mag dann neu belegt werden.
Leerzeichen
- In allen Welten unstrittig sind bestimmte Leerzeichen, um als Mensch gut zu erfassen.
- Definitiv nicht: $(function (){ (zwei Leerzeichen fehlen), if(mw.config.get ist bäh.
- mw:Manual:Coding conventions/JavaScript #Whitespace
  - Mit den Tabs bin ich nicht einverstanden; mal als acht Zeichen und die dritte oder vierte Schachtelung jenseits von Gut und Böse; mal generiert die Darstellung drei oder vier oder zwei Zeichen, und das wird uneinheitlich bei Fortsetzungszeilen.
  - Das Line breaking dort ist teils ungebräuchlich und riecht nach Privatgeschmack, wird von den MW-devs wohl auch flächendeckend ignoriert.
Validator
- MW verwendet https://eslint.org/
- Wir traditionell https://jshint.com/
- Egal wie; es muss ohne vermeidbare Meldungen herauskommen.
const war bereits thematisiert und beantwortet.
- var reicht hier.
- Ich würde allen Symbolen zu Beginn der Funktion entweder die Werte zuweisen oder zumindest ihre Namen mit Komma aufzählen.
getName() == 'Lustiger
- String-Vergleich mit ===
mw.user ist nicht notwendigerweise zu Beginn geladen; müsste korrekterweise zur Vermeidung einer race condition mit mw.loader.using() erst synchronisiert werden.
- Wobei das in der Praxis bei $() vermutlich schon passiert wäre; ist trotzdem sehr unsauber.
- wgUserName in mw.config.get() ist hingegen sofort (vorher) vorhanden.
Kapselung von allem gegen global und Schnittstelle für die Aliasse mw und $ über die längeren und weniger schnell abgeschossenen Symbole mediaWiki sowie jQuery; ggf. auch im globalen Objekt des Browsers verankert weil ohne Browser dieses JS nicht ausführbar ist.
Siehe zu allem vorstehend: en:user:PerfektesChaos/js
Vorkehrung, falls Skript durch anonym geladen; sogar im Kontext der Spezialseite (die alle angucken dürfen aber nichts ausfüllen können).
Komplexe Ausdrücke einmalig berechnen und speichernd hinterlegen.
- mw.user.getName()
  Doppelt ausgewertet.
  - sysop = mw.config.get( "wgUserName" );
- new Date()
  Doppelt ausgewertet.
  - now = new Date();
() * 60 * 1000).toISOString().slice(0, 16).replace(/T/, ' ')
- Das sieht ja arg kompliziert aus.
- Was genau soll die Multipliziererei bewirken?
- .toISOString() liefert 2011-10-05T14:48:00.000Z und da wäre
  stamp = now.toISOString();
  stamp = stamp.slice( 0, 10 ) + " " + stamp.slice( 11, 15 ) + ":00Z";
  wenn ich richtig verstehe was du vorhast.
document.getElementsByName
- C&P-Klau-Mischung von DOM vor 2010 und jQuery als $.
- Wir schreiben seit 2010 einheitlich in jQuery.
Nicks umschreiben:

switch ( sysop ) {
   case "Hgzh" :
      sysop = sysop.slice( 0, 0 ).toLowerCase()  +
              sysop.slice( 1 );
      break;
   case "Lustiger seth" :
      sysop = "lustiger_seth";
      break;
}   // switch sysop

Resultat mit Vorkehrung für Feldeinteilung: stamp + " @ " + sysop + " @ "
Alle vorstehenden Code-Beispiele freihändig ungetestet.

VG --PerfektesChaos 15:26, 8. Nov. 2023 (CET)Beantworten

Das kann man ja nicht mit ansehn: BETA

Übernahme bitte per XML-Import. Danke.

VG --PerfektesChaos 12:12, 9. Nov. 2023 (CET)Beantworten

Gudn Tach!

Oh, wow, vielen Dank für Zeit und Aufwand!

Die Multiplikation war nur drin, um Zeitzonen zu berücksichtigen, aber UTC finde ich eh besser (und hatte es ja im Original-Code auch schon vorbereitet), insofern: passt!
Den Eventhandler hast du absichtlich entfernt?
Wenn ich auf Special:Import keine XML-Auswahl sehe, liegt das vermutlich an fehlenden Import-Rechten, richtig? @user:Doc Taxon: Du bist Interface-Admin und hast Import-Rechte. Würdest du die von PerfektesChaos in Beta angelegte Seite hierher umziehen?

-- seth (Diskussion) 01:04, 10. Nov. 2023 (CET)Beantworten

„Den Eventhandler hast du absichtlich entfernt?“

????
Wenn du $(fill) meinst: Das ist das letzte ausführbare Statement.
Ich mag keine umfangreichen anonymen Funktionen, die als Parameter in irgendwas reingequetscht werden.
Weil ja jetzt gekapselt, bin ich auf die Anonymität nicht mehr angewiesen und könnte für die Kapsel ggf. auch Konfigurationsparameter wie den Feldbezeichner separat definieren.

VG --PerfektesChaos 09:30, 10. Nov. 2023 (CET)Beantworten

Gudn Tach!

Die Fragezeichen interpretiere ich als "Wovon redest du?". Ich meine die Zeilen 15 bis 18 in user:Lustiger_seth/admin_stuff.js, durch die auf einen Abschnitt in WP:SBL verwiesen wird (was natürlich manuell bearbeitet werden kann, aber idealerweise meistens einfach so zutrifft, siehe bisherige Einträge).
Problematisch ist unabhängig von einem Automatismus allerdings noch, dass die Diskussionsabschnitte ja irgendwann archiviert werden. Vielleicht also eher Permalinks? Die sind nur leider immer so hässlich und lang.
Denkbar wäre ansonsten, aber das sprengt vielleicht den Rahmen der hiesigen Diskussion, dass man für die Domains Unterseiten anlegt, also statt WP:SBL#example.org eher WP:SBL/example.org oder sogar (in Anlehnung an eine Idee von dir, die bald ihr 10-jähriges Jubiläum feiert): WD:Weblinks/Blockiert/example.org, dann wären wir auch von der Technik (SBL/DBL/FILT) und von Jahreszahlen unabhängig.

-- seth (Diskussion) 02:57, 11. Nov. 2023 (CET)Beantworten

Eventhandler

Der einzige Eventhandler hier beginnt jeweils mit: $(f
Er gehört zum Event „onDOMready“.
Die Funktion wird ausgeführt, nachdem die Elemente des HTML vollständig in das DOM überführt worden sind.
„Eventhandler“ ist ein Fachausdruck der HTML-Script-Technologie.

Zeilen 15 bis 18

Das meint wohl was mit: [[WP:SBL#
Das hatte ich weggelassen, weil funktionslos; zumindest so wie es da steht.
Das Gadget wird ausgeführt, sobald die Seite geladen worden ist (onDOMready).
Zu diesem Zeitpunkt sind die Formularfelder leer. Es sei denn, irgendwer tippt in 1/10000 Sekunde die Domain ein.
wpDomain ist deshalb immer leer.
Du hattest vermutlich bei bereits geladener Spezialseite und schon ausgefülltem Formularfeld das Script manuell gestartet.

Vorbelegung des Kommentars anhand der eingegebenen Domain

Dazu müsste man den Submit-Button kapern.
Geht am einfachsten, indem er aus dem HTML-Dokument gelöscht und durch einen eigenen Button ersetzt wird.
Der eigene Button wird mit einer Funktion verknüpft, die die beiden fertig ausgefüllten wpDomain und wpNotes analysiert und verwurstet.
Diese ändert ggf. den Feldinhalt wpNotes.
Kann natürlich noch einen Syntaxcheck für wpDomain machen.
Danach löst sie das HTML-Event „SubmitForm“ aus.

Vorbelegung des Kommentars zum Selbstausfüllen

Dazu wäre nach XML-Import mein Code an zwei Stellen zu ergänzen:
Im „Modul“-Kopf bei var Env eine Konfigurationsvariable: var Story = "[[WP:Weblinks/Block///]]";
Unten nach letzter stamp-Zuweisung:

if ( Story ) {
   stamp = stamp + " " + Story;
}

Man gliedert solche Text-Zuweisungen an den Kopf der Module aus, damit spätere Anpassungen und Wikilinkfixe durch Dritte ohne langes Rätselraten ermöglicht werden.
Genauso könnten die beiden Feldnamen hinterlegt werden; aber die dürften erstmal stabil sein, und wenn sich die Struktur und Logik der Spezialseite fundamental ändern, dann wird das nicht mit Anpassung von zwei ID getan sein.

Organisation zukünftiger Projektseiten

Das entgleitet dem Scope dieser Seite hier.
Grundsätzlich ist eine von Werkzeugen und Methoden unabhängige Dokumentation der problematischen Domains der momentanen Struktur vorzuziehen.
- Eine Anbindung als Unterseite von WP:Weblinks bietet maximale Auffindbarkeit; die „Defekten“ leben auch bereits dort.
- WP:Weblinks/Block ist deutsch-englisch und vemeidet „black“.
Die Unterseiten würde ich reverse-domain organisieren.
- Also gauner.example.com unter WP:Weblinks/Block/com/example/gauner in individuell beliebiger Schachtelungstiefe; je nachdem wieweit die zusammengehören.
- Siehe Anordnung in Wikipedia:Technik/Netzwerk/Domains.

VG --PerfektesChaos 10:30, 11. Nov. 2023 (CET)Beantworten

Gudn Tach!

Nee, ich hab nix manuell gestartet. Die Zeilen sorgen (zumindest unter Firefox, aber ich dachte, der Code sei weitgehend Browser-unabhängig) dafür, dass wenn man ins obere Feld irgendwas einträgt, dynamisch das zweite Feld befüllt wird und man idealerweise gar nix mehr dort zu ändern braucht (es aber kann!).
Das heißt: schreibe ich ins obere Feld example.org, dann steht unten bereits 2023-11-11 14:55 lustiger_seth: [[WP:SBL#example.org]].
Eine Submit-Button-Modifikation braucht's da nicht. Oder wir reden von unterschiedlichen Dingen.
Organisation: Ja, bereden wir besser unter MediaWiki_Diskussion:Spam-blacklist#Restrukturierung_2023.

-- seth (Diskussion) 15:01, 11. Nov. 2023 (CET)Beantworten

Ich hatte deine .js-Version vom 21. im Browser-Tab und die Version vom 28. nicht mitbekommen, mein Code basierte dann darauf.
XML-Import ist damit erstmal hinfällig.
Deine Version vom 28. ist aber trotzdem nicht bedienbar.
- Wenn jemand im Domain-Feld etwas nachbessert, vielleicht eine Subdomain einschränkend hinzugefügt oder eine voranstellt, dann wird das Notes-Feld gnadenlos überschrieben.
- Wenn man jedoch zwischenzeitlich an das Notes-Feld noch eine Bemerkung dranschrieb, dann ist die hiermit gelöscht.
- Davon kann ich aber nichts mitbekommen, weil der Text aus Zeitstempel und Nick so lang ist, dass ich das Ende mit meiner Bemerkung nicht mehr sehen kann, und auch nicht mit diesem Verhalten rechne.
Das wäre anders zu realisieren:
1. HTML-Submit-button verstecken.
2. Eigenen Button an gleicher Stelle hinzufügen; gleiche Beschriftung plus ein <sup>*</sup>.
3. Wenn angeklickt, dann folgenden Handler aufrufen:
  - Domain trimmen und lowercasen und normalisierten Wert in das Domain-Feld eintragen.
  - Notes trimmen, falls was drinstünde.
  - Domain syntaktisch prüfen:
    - Beginnt mit: ^[a-z]
    - Endet auf: \.[-a-z0-9]+$
    - Enthält nur: ^[-_%.a-z0-9]+$
    - Enthält keine: \.\.
  - Wenn Domain okay dann Zeitstempel und Nick und ggf. Wikilink und eingetragenen optionalen Notes-Inhalt in das Notes-Feld eintragen, und ein click auf den unsichtbaren HTML-Submit-button.
  - Wenn Domain nicht okay dann Domain-Feld rot unterlegen. Nix weiter.
4. Das Notes-Feld bleibt meist leer oder erhält einen optionalen Zusatz-Kommentar.
Weitere Aktivitäten lohnen sich erst, nachdem die Struktur der Projektseiten endgültig definiert ist.
- Ggf. erübrigt sich das Wikilink auch noch.
- Ggf. wäre eine URL-Verlinkung sinnvoller, weil die Spezialseite keine anklickbaren Verlinkungen auf die Projektseite generiert. Ob die URL-Links mitmacht glaub ich aber auch nicht, weil wegen Sicherheit.
- Wenn sich aber die Projektseite nachvollziehbar aus der Domain ergibt, dann langt ein Wikilink einmalig im Kopf der Spezialseite, mit Erläuterung, zur Selbstnavigation.

VG --PerfektesChaos 13:33, 13. Nov. 2023 (CET)Beantworten

Gudn Tach!

Die Beschreibung "nicht bedienbar" halte ich für deutlich übertrieben. Da ich es bedienen kann, ist es auf jeden Fall bedienbar. Dass es kleinere Mängel hat, will ich nicht bestreiten, nur bitte ich darum, Pauschalisierungen zu vermeiden.
Die Idee, das automatisiert erst beim Absenden einzufügen, hat zugegebenermaßen ihren Charme. Wenn ich es richtig verstehe, hätten die Eintragenden dann aber keine Möglichkeit, den Link vorm speichern zu modifizieren, oder?
Was meinst du mit "weil die Spezialseite keine anklickbaren Verlinkungen auf die Projektseite generiert"? Die SBL-Links auf special:BlockedExternalDomains sind anklickbar.

-- seth (Diskussion) 23:57, 17. Nov. 2023 (CET)Beantworten

Die Projektseiten sind exakt so zu organisieren, dass ich zu einer Domain auch eindeutig vorhersagbar das Wikilink bilden kann, unter dem ich die Diskussion dazu finden würde.

Wenn ich weiß, an welchem Tag eine LD begonnen wurde oder eine FZW-Erörterung, dann kann ich daraus exakt vorhersagbar ermitteln, wie die Archiv-Unterseite heißt.
Über WL können ggf. Dubletten auf eine zentrale Erörterung desselben Verantwortlichen umgelenkt werden; genauso auch mögliche separat nicht sinnvolle Subdomains auf die gemeinschaftliche Domain.
Wenn aus der Domain eindeutig folgt, wo und wie ich die Erörterung finden kann, dann sind sämtliche Extrawürstchen aller Art unzulässig, und dann ist es auch nicht erforderlich, im interaktiven Formular noch irgendwie am Wikilink herumzubasteln.
Neben der Eingabe im interaktiven Formular bleibt immer noch die Quellcode-Bearbeitung in JSON.

„Bedienbarkeit“ bedeutet, dass alle Menschen ohne besondere Vorkenntnisse das Formular intuitiv richtig und zuverlässig bedienen können (Principle of Least Surprise – Paradefall: „Generell sollte Software niemals Daten entfernen, die möglicherweise noch benötigt werden“; genau das macht aber die vorgelegte Programmierung, ohne dass dies erkennbar wäre).

Dass die Einzelperson, die sich das ausgehackt hatte, es selbst bedienen könnte und um die unvorhersehbaren und verborgenen Fallgruben und Fußangeln weiß, ist völlig unerheblich.

Von der Anklickbarkeit in der Spezialseite weiß ich einstweilen wenig. Welche Wikisyntax genau hier unterstützt würde, wäre erst noch zu erforschen; erfahrungsgemäß ist das nur eine begrenzte Teilmenge.

VG --PerfektesChaos 10:45, 18. Nov. 2023 (CET)Beantworten

Gudn Tach!

"zu einer Domain auch eindeutig vorhersagbar das Wikilink bilden" -> Ja, haste eigentlich recht. Ich hab auf WP:SBL#Restrukturierung_2023 bei dem Beispiel mit dem ukrainischen SEO-Spam beim Schreiben auch gedacht: "Hmm, eigentlich beschreibe ich hier nur die Praxis, finde diese Praxis aber selbst nicht so super, nun ja." Vermutlich würden wir das (mit einigen Weiterleitungen) hinbekommen. Das ist aber eher ein Thema, was wir dort weiterbesprechen sollten, oder?
Verstehe ich es richtig, dass dein Ansatz wäre, z.B. die erste Spalte von Special:BlockedExternalDomains per JS so zu modifizieren, dass sie gleich auf [[WD:Weblinks/block/example.org]] (oder was auch immer es dann sein wird) verlinkt, sodass man meine Sperenzchen mit dem dymanischen Ausfüllen gar nicht braucht, sondern nur (so wie ursprünglich gedacht) Timestamp + Name initial (oder eben beim Speichern) einträgt? Fänd ich, glaube ich, auch ok.

-- seth (Diskussion) 22:10, 18. Nov. 2023 (CET)Beantworten

Im Prozess der Abspeicherung (syntaktisch zulässige wpDomain vorausgesetzt) schriebe ich als Feldinhalt von wpNotes:

Timestamp @ Nick @ [[WP:Weblinks/Block/org/example]] <optional>Leerzeichen Feldinhalt von wpNotes</optional>

Wenn irgendeine „erste Spalte von Special:BlockedExternalDomains per JS so zu modifizieren“, dann würde das nur auf Personen wirken, die das Gadget aktiviert hätten; das wären per Definition jedoch nur Admins, und alle Normalmenschen, die die Spezialseite besuchen, sähen nur literally die JSON-Inhalte.

Dessen ungeachtet ließe sich jedoch mit Lua aus JSON eine sortierbare Wiki-Tabelle generieren, in der die Timestamp menschenlesbar eingekürzt und die Nicks verlinkt sind, und die Notes erst nach dem zweiten @ dargestellt werden.

VG --PerfektesChaos 08:19, 19. Nov. 2023 (CET)Beantworten

Gudn Tach!

Zur Struktur siehe WP:SBL#restrukturierung_2023. Da hab ich auch was zur Rückwärtsschreibweise geschrieben.
Erste Spalte: Das wäre dann ein anderes Script und dieses dann nicht nur für Admins aktiviert.
Falls da ressourcenschonend eine hübschere Ansicht mit Lua bewerkstelligt werden könnte: gerne (solange ich es nicht in Lua programmieren muss).

-- seth (Diskussion) 00:37, 20. Nov. 2023 (CET)Beantworten

@ „Das wäre dann ein anderes Script und dieses dann nicht nur für Admins aktiviert“

Ein derartiges Skript wird es nicht geben. Punkt.
Wenn (auch nicht angemeldete) erst ein „Skript“ installieren müssen, um eine Spezialseite lesen und übersichtlich verständlich darzustellen, dann ist diese Spezialseite für die Öffentlichkeit unbrauchbar.
In dem Moment, in dem all dieses Timestamp-Nick-Gedöns dransteht, ist die Spezialseite nur noch intern für pflegende Admins verwendbar.
Die verständliche Darstellung kann über Lua erfolgen.

VG --PerfektesChaos 09:57, 20. Nov. 2023 (CET)Beantworten

Gudn Tach!

Zum Punkt 2: Das sehe ich ganz genauso, weshalb ja mein Vorschlag auch ein für alle aktiviertes Script war, was aber wegen Punkt 1 wohl nicht geht.

Zum Punkt 4: Wenn du das (später) machst, gerne. :-)

Magst du dich bei Gelegenheit mal auf WP:SBL#Restrukturierung_2023 äußern? Ich würde ungern was umsetzen, mit dem du am Ende todunglücklich bist. -- seth (Diskussion) 09:47, 25. Nov. 2023 (CET)Beantworten

Gudn Tach!

Zur Info: user talk:lustiger_seth#Blocked_external_domains. So einfach kann's gehen. Bin mal gespannt, ob auch das Datum noch ergänzt wird. -- seth (Diskussion) 20:42, 15. Jan. 2024 (CET)Beantworten

Infobox unfloat lokal?

Letzter Kommentar: vor 1 Monat7 Kommentare2 Personen sind an der Diskussion beteiligt

Der momentan wirksame Stil für die infobox-Klasse auf Mobilgeräten spielt unnötigerweise auch an Rahmen, Padding, Textgröße und Textausrichtung herum und führt somit dazu, dass die Infoboxen sich mobil immer leicht abweichend verhalten oder gar Elemente, die pixelgenau arbeiten, zerschossen werden. Dies erschwert die Wartbarkeit und führt zu unerwünschtem Verhalten bzw. unpassender Darstellung (Überlauf, Scrollbalken etc.). Da wir inzwischen diese globalen Stile per MediaWiki:Wikimedia-styles-exclude deaktivieren können, wäre zu überlegen, ob es nicht eine lokale Kopie der Regeln geben sollte, die das Floating der Infobox aufheben und es gleichzeitig erlaubt, diese auch bei anderen Elementen, die keine Infoboxen sind, anzuwenden. Könnte dann in ein MediaWiki:Gadget-dewikiCommonResponsive.css o.Ä. ausgelagert werden. -- hgzh 12:58, 2. Mai 2024 (CEST)Beantworten

Das mag sein; aber bitte nicht Common im Bezeichner.

Das dewiki zeigt bereits an, dass es site ist.
„Common“ bedeutet, dass es gemeinschaftlich für alle Desktop-Skins sein soll; genau das ist ja nun überwunden.
Der umständliche Name passt dann auch nicht in die Linkbox.
Am liebsten die bisherigen auch einkürzen und verschieben; sind ja nur relativ wenige Seiten zu ändern.

VG --PerfektesChaos 16:13, 3. Mai 2024 (CEST)Beantworten

Ja, das war nur der erste Schuss. Meinetwegen auch einfach MediaWiki:Gadget-dewikiResponsive.css -- hgzh 21:44, 6. Mai 2024 (CEST)Beantworten

Work in Progress: BETA -- hgzh 22:52, 6. Mai 2024 (CEST)Beantworten

Update: Implementierung hier etwas verschoben, weil MediaWiki-seitig derzeit am zentralen Stylesheet geschraubt wird. -- hgzh 09:08, 28. Jun. 2024 (CEST)Beantworten

Wikipedia:Technik/Skin/Gadgets/dewikiResponsive fehlt dann aber immer noch, so nebenbei bemerkt. Wurde bereits verlinkt.

Kann ja blind und Standard-Gerippe sein; hier wird gesammelt aber noch ist nix da. Immerhin ein Zweck.

VG --PerfektesChaos 14:28, 7. Okt. 2024 (CEST)Beantworten

Ich weiß, ja, leider muss ich das nochmal komplett durchdenken. Mglw. fällt das auch erstmal ganz flach wegen unkontrollierbarer Nebenwirkungen. Aber ich versuche, das in den nächsten Wochen noch einmal anzugehen. -- hgzh 14:40, 7. Okt. 2024 (CEST)Beantworten

Dreimal Gadget

Letzter Kommentar: vor 19 Tagen20 Kommentare2 Personen sind an der Diskussion beteiligt

Zweimal Update:

BD:hgzh #Gadgets war Anlass
Codes, auf unseren konventionellen Stand von 2014 gebracht:
- MediaWiki:Gadget-easyNewSection.js aus easyNewSection@BETA
- MediaWiki:Gadget-Einleitung-bearbeiten.js aus Einleitung-bearbeiten@BETA
Außerdem Robustheits-Vorkehrungen eingebaut.

Einmal neu: annotationPair

VG --PerfektesChaos 14:25, 7. Okt. 2024 (CEST)Beantworten

easyNewSection habe ich aktualisiert, trivial.

Einleitung-bearbeiten hat die Namensraumabfrage verloren. Entweder ich baue sie per Gadgets-definition ein oder alle Namensräume bekommen eine Einleitungsbearbeitung; ob das sinnvoll ist, weiß ich nicht. Meine Tendenz ist eher dahingehend, die Einschränkung auf den ANR zu belassen, da nur dort garantiert ist, dass es überhaupt eine Einleitung gibt.

FN muss ich noch durchtesten. -- hgzh 08:39, 8. Okt. 2024 (CEST)Beantworten

Danke soweit.

@Einleitung-bearbeiten:

Da kam wohl in den Monaten auf meiner ToDo-Liste ein Detail abhanden.
Der Plan ist wohl, das Gadget nur im ANR zu starten.
Deshalb keine Abfrage innerhalb des JS mehr, was ja früher unumgänglich war.

VG --PerfektesChaos 13:30, 8. Okt. 2024 (CEST)Beantworten

Einleitung-bearbeiten ist nun auch aktualisiert. Beim Speichern habe ich dann gesehen, dass die Abfrage auf Artikel doch drin war, nur unten. Naja, doppelt hält besser. Gruß, -- hgzh 19:37, 16. Okt. 2024 (CEST)Beantworten

annotationPair: die Einzelnachweisvorschau funktioniert so mit der neuen Version nicht mehr.

FN braucht außen .reference und innen a, s. index.js, d.h. sup und a müssten andersherum verschachtelt werden
FNZ braucht reference-text innerhalb des Elements mit der id, s. createReferenceGateway.js, d.h. die id müsste vom a zum div-Parent
Encoding in der id des FNZ ist dabei auch problematisch. Im Beispiel wird ) zu %29 und dann klappt das Matching nicht mehr.

-- hgzh 20:15, 16. Okt. 2024 (CEST)Beantworten

@annotationPair:

Dass dieses EN-Zeugs auch bei FN funktioniert, war mir nicht bewusst, aber wäre dann ja wohl nur aus Sicht des -m und nicht des -a sinnvoll.
- Die Geschichten mit .reference und reference-text müssten soweit möglich auf Ebene der Vorlagen gelöst werden. Das JS soll davon möglichst nichts wissen; die Vorlagen sind hingegen ohne BOA veränderbar.
Ein Decoding kann ich veranlassen; bei der Zuweisung macht jQuery das minimal erforderliche dann schon, hoffentlich auch nicht mehr. Das von mir eingebaute Encoding ist jedoch sicherer, wenn die User-definierte Marke in das HTML eingebaut wird und <6> oder 5°17'14" werden soll.
Das Matching sollte durchaus funktionieren, weil beide (id= und href=#) identische Bezeichner sind; von einem anderen Matching wüsste ich nichts.
Ich kann über Nacht das JS updaten, sobald ich die Augen für geistig anspruchsvolle Tätigkeiten aufbekomme; bin momentan eher groggy. Diese Verschachtelung muss ich erstmal verinnerlichen.

@doppelt hält besser:

Nach zwei Monaten habe ich alles komplett vergessen.
Aber ich mache bewusst auch immer im JS das, was bereits Gadgets-definition leisten sollte. Also auch Ressourcen laden und Bedingungen abfragen und umsetzen.
Wenn über Gadgets-definition geladen, dann sind die Ressourcen bereits vorhanden, und ihr Vorhandensein wird nur noch abgehakt. Sonstige Voraussetzungen werden geprüft und ansonsten entsprechend reagiert.
Jedoch gibt es bei der Erst- und Weiterentwicklung noch kein geeignetes Gadgets-definition, und dann muss das JS nach manuellem Laden sich jederzeit autonom selbst helfen können.
Außerhalb des ANR wird nicht per Gadgets-definition geladen; wenn doch irgendwie, soll traditionell nix passieren. Wäre mir eigentlich egal, weil sogar auf einer Disk gibt es einen Einleitungsabschnitt, in dem die Archivierung konfiguriert werden könnte. Aber ich benutze das Dings ohnehin nicht.

@OT: Modul:TemplateData/config Zeile 3 find ich schleckig.

VG --PerfektesChaos 22:47, 16. Okt. 2024 (CEST)Beantworten

Nächtliches Treiben:

Einzelnachweisvorschau
- Innerhalb der Vorlagen habe ich die erwartete Struktur hergestellt.
- Ergibt sich die Frage, zu welchem Zeitpunkt das in den verlinkten Gerrits codierte JS ausgeführt wird. Wenn das basierend auf dem statischen HTML passiert, und danach wird das Gadget ausgeführt, dann konnte es das noch nicht sehen. Müsste also das Einzelnachweisvorschaudingens vom Gadget erneut gestartet werden, in der Hoffnung, dass dadurch keine Kollateralschäden aus der ersten Ausführung entstehen. Wohl bekomm’s.
- Der überkommene Zustand mit seinem invaliden HTML ist perspektivisch nicht mehr haltbar, war von Anfang an schon syntaktisch falsch gewesen. Die Verantwortung für die eindeutige Verwaltung der gruppe war den Autoren des Wikitextes auferlegt gewesen. Der Rücksprung erfolgt nicht an die 45. von 234 Tabellenzeilen, sondern immer und nur an die allererste. Wenn die Autoren überall die richtige gruppe hinterlegt haben.
- Das Einzelnachweisvorschau-Tool ist dafür gedacht, um auf dem vom Server ausgelieferten HTML ausgeliefert zu werden, und soll die von der cite-Extension generierten <ref> darstellen. Wenn man diese Funktionalität auch mit den FN haben möchte, muss die FN-Verwaltung einschließlich gruppe aka group= in die Server-Software integriert sein. Da gibt es sie aber schon seit zwei Jahrzehnten, macht eckige Klammern um die Marker, und als Marker ist ausschließlich eine fortlaufende Nummerierung in der gesamten Seite jeweils pro group erlaubt. Sternchen oder Buchstaben mit ohne Klammern und Gruppen-Namen sind nicht möglich.
- Ich benutze das Feature nicht, vermisse auch nichts und will auch kein Videospiel, bei dem mir permanent unter dem Mauszeiger irgendwelche Blasen aufpoppen und Performance-Last generiert wird.
Dekodierung
- Ich kann keine Nachteile erkennen; die Zeichenkette für Hin- und Rückbezeichner werden aus derselben JS-Variablen generiert und matchen perfekt.
- Hingegen gibt es Risiken, von nicht abgefangener HTML-/Wikisyntax bis hin zu Zeilenumbrüchen, was jedoch nach Encoding besser als bisher funktioniert. Vorlage:FN #Erlaubte Zeichen für Vorlage:FN und Vorlage:FNZ
- Es müssen nur id= und href=# matchen; was da sichtbar dargestellt wird ist irrelevant, und die Fragmentbezeichner enthalten ja auch zusätzlich willkürliche Präfixe.

VG --PerfektesChaos 07:40, 17. Okt. 2024 (CEST)Beantworten

Sorry für die Verzögerung, war die Tage anderweitig ausgelastet.

Punkt 1 meiner obigen Liste ist erledigt.
Punkt 2 fehlt noch, die ID müsste weg vom a zum Parent-div-Element, da das JS ja die ID einfügt, kann das auch nicht in den Vorlagen gelöst werden.
Punkt 3 (Encoding) ist knifflig, Problem ist wohl, dass das Sprungziel in href erst dekodiert wird, also %29 zur Klammer wird, und anschließend nach dieser ID gesucht und diese nicht gefunden wird, weil id weiterhin %29 enthält, s. [1]. Ich schätze es als eher schwierig ein, das zu ändern, d.h. bei FN-Bezeichnungen, die kodiert werden müssen, wird die Vorschau wohl nicht funktionieren. Ich kann höchstens mal beim Technische-Wünsche-Team anfragen, die sind da ja eh gerade dran. Würde ich aber erstmal nicht als blocker auffassen.

Da die Einzelnachweisvorschau eine Standardfunktion ist, finde ich es schon wichtig, dass diese möglichst funktioniert. Dem Leser ist's ja egal, was da für eine Technologie dahinter steht, und er wird den Unterschied zwischen ref und FN in 95% der Fälle auch nicht merken. gruppe sollte von allein funktionieren, da wird ja nur zusätzlicher Text in die Bezeichner eingefügt. -- hgzh 08:13, 29. Okt. 2024 (CET)Beantworten

Ich bin ja willig.

Punkt 2 (ID müsste weg vom a zum Parent-div-Element) müsste ich verstehen, wenn ich mal wach bin. Diesen Monat nicht mehr. Prinzipiell kann JS alles, soweit es global einheitlich zu handhaben ist.
Punkt 3 (Encoding) bringt mich zum Start eines Denkprozesses anchorencode::URLutil, Richtung Wochenende.
- "<> bleiben encoded, ein- oder mehrfacher Whitespace wird _.
- URL- und Entity-Encoding wird vorher dekodiert.
- Mir ist so, als ob ich sowas schon mal programmiert hatte, weiß aber nicht mehr wo, vielleicht ist es ja schon Bibliotheksfunktion, auf jeden Fall macht Lua das bereits.

VG --PerfektesChaos 16:11, 29. Okt. 2024 (CET)Beantworten

zu Punkt 2:

<div class="fussnoten-inhalt references">
  <a class="annotationpair-a" href="#" id="annotationpair-2-1%29-0">
    <sup class="fussnoten-marke mw-cite-backlink">1)</sup>
  </a>&nbsp;
  <div class="reference-text">German word for number <code>1</code>.</div>
</div>

soll werden:

<div class="fussnoten-inhalt references" id="annotationpair-2-1%29-0">
  <a class="annotationpair-a" href="#">
    <sup class="fussnoten-marke mw-cite-backlink">1)</sup>
  </a>&nbsp;
  <div class="reference-text">German word for number <code>1</code>.</div>
</div>

der Selektor in der Einzelnachweisvorschau lautet auf {id} .reference-text. Gruß, -- hgzh 21:50, 29. Okt. 2024 (CET)Beantworten

Ich hab dann mal auf BETA rumgeupdated. VG --PerfektesChaos 22:36, 31. Okt. 2024 (CET)Beantworten

Passt jetzt, danke. Den anchorencode in URLutil habe ich mitbekommen, planst du da noch was? -- hgzh 12:53, 7. Nov. 2024 (CET)Beantworten

Aktionsplan:

ich: WP-Doku Wikipedia:Technik/Skin/Gadgets/annotationPair (done)
ich: WP-Kat (done)
hgzh: MediaWiki:Gadget-annotationPair.js hierher, mit BK-Erwähnung des Erst-Erstellers
hgzh: MediaWiki:Gadget-annotationPair mit Verlinkung WP-Doku
ich: Vorlagen auf BETA mit anchorencode (heute nacht oder so, wenn ich mal gut drauf bin; die letzten zwei Tage waren arg)
hgzh: Gadgets-Definition scharf
ich: Vorlagen nach hier, Vorlagen-Disk

VG --PerfektesChaos 13:51, 7. Nov. 2024 (CET)Beantworten

3 + 4 Ok -- hgzh 14:08, 7. Nov. 2024 (CET)Beantworten

Vorlagen auf BETA angepasst, scheint zu stimmen.

Kannste nochmal alles durchchecken.

Gadgets-Definition können dann verschärft werden; mangels aktiver Kat bleibt das ja ohne Auswirkungen.

Sehe ich dann, übernehme bei Gelegenheit die Vorlagen nach hier, + Vorlagen-Disk.

VG --PerfektesChaos 21:30, 7. Nov. 2024 (CET)Beantworten

Also das Klammerproblem beim Encoding besteht nach wie vor, aber das ist wie gesagt erstmal vernachlässigbar. Gadget ist live. -- hgzh 22:28, 7. Nov. 2024 (CET)Beantworten

Klammerproblem schaue ich mir nochmal an, aber () sind nicht mehr kritisch. Muss ich in wacherer Phase mal nachforschen.

Für mich sieht alles passend aus, mit blau und fett und so.

Vorlagen transferiert. Doku in ein paar Tagen anzupassen.

MediaWiki:Gadgets-definition – Drehst du bitte noch edit,view in das prozessual und häufigkeitsmäßigere view,edit?

VG --PerfektesChaos 23:30, 7. Nov. 2024 (CET)Beantworten

edit,view ist (fast) überall so alphabetisch sortiert. -- hgzh 08:32, 8. Nov. 2024 (CET)Beantworten

Ansonsten sieht das gut aus, danke! -- hgzh 08:33, 8. Nov. 2024 (CET)Beantworten

Naja, die Doku beanstandet unterschiedliche Definitionen unklarer Ursache. VG --PerfektesChaos 17:57, 8. Nov. 2024 (CET)Beantworten

MediaWiki:Gadget-editMenusDef.css Darkmode Anpassung

Letzter Kommentar: vor 16 Tagen6 Kommentare3 Personen sind an der Diskussion beteiligt

Der Code muss an den Darkmode angepasst werden, damit die Leiste im Darkmode nicht weiterhin weiß ist. Hier der Änderungsvorschlag:

.editMenus-button {
   background:   var(--background-color-neutral-subtle, #D8D8D8);
   border-color: var(--background-color-neutral, #E0E0E0) var(--color-disabled, #707070) var(--color-disabled, #707070) var(--background-color-neutral, #E0E0E0)
   border-style: solid;
   border-width: 2px;
   display:      inline-block;
   min-width:    1.5em;
   text-align:   center;
}
.menuSwitcher {
   margin-bottom: 1em;
   margin-top:    1px;
   background-color: var(--background-color-base, #FFF) !important;
   color:         var(--color-base, #000) !important;
}
.editOptions {
   clear: both;
}

In dem div gibt es auch noch style parameter die nicht aus der Klasse kommen. Aus MediaWiki:Gadget-editMenusDef.js kommen die jedoch nicht, daher vorerst die Lösung über !important. --GPSLeo (Diskussion) 12:12, 27. Okt. 2024 (CET)Beantworten

--background-color-neutral-subtle ist recht hell, ich würde eher --background-color-neutral in Form von --dewiki-hintergrundfarbe5 nehmen, das kommt dem derzeitigen Aussehen näher.

Die Definitionen für den menuSwitcher kommen aus en:User:PerfektesChaos/js/menuSwitcher/d.js, da müsste PC die Zeilen 23 und 25 entsprechend anpassen. -- hgzh 07:46, 29. Okt. 2024 (CET)Beantworten

en:User:PerfektesChaos/js unterliegt einem Sicherheits- und Versionierungsprozedere, kann ich einpflegen, Testen eher am Wochenede. VG --PerfektesChaos 16:14, 29. Okt. 2024 (CET)Beantworten

en:Special:Diff/1254615359 live. VG --PerfektesChaos 22:34, 31. Okt. 2024 (CET)Beantworten

Noch scheint das hier nicht wirksam zu sein. Vermutlich der Cache. -- hgzh 08:14, 4. Nov. 2024 (CET)Beantworten

Offenbar scheint jQuerys .css()-Funktion die CSS-Variable in einen RGB-Wert zu expandieren. Da muss ich nochmal schauen, wieso das so ist und was man machen kann. -- hgzh 08:21, 11. Nov. 2024 (CET)Beantworten

Vorlagenbild mit Helferlein Navigation Popups

Letzter Kommentar: vor 21 Tagen3 Kommentare2 Personen sind an der Diskussion beteiligt

Hallo, wie ich gerade gesehen habe, wurde mein Problem bereits unter Wikipedia_Diskussion:Technik/Skin/Gadgets/navigation-popups#Falsches_Foto_wird_angezeigt angesprochen. Gibt es vielleicht doch eine Möglichkeit, das primäre Bild in den Navigation Popups anzuzeigen? Dann würde ich sehr gerne Infoboxen erstellen. (Vielleicht sehen andere es ähnlich ;-).) --Artessa (Diskussion) 11:31, 6. Nov. 2024 (CET)Beantworten

Wir können hier leider keine Änderungen erwirken, da das Gadget auf der englischen Wikipedia verwaltet und entwickelt wird: en:Wikipedia:Tools/Navigation popups. Gruß, -- hgzh 12:02, 6. Nov. 2024 (CET)Beantworten

Das hatte ich so im Vorfeld nicht verstanden. Bleibt noch zu hoffen, dass dort genügend User schreien. Sehr, sehr schade. Aber danke für die schnelle Info. --Artessa (Diskussion) 12:39, 6. Nov. 2024 (CET)Beantworten

Fahrer / Team für die Suche eingeben:

Fahrer / Team für die Suche eingeben:

Eisspeedway

Wikipedia:Technik/Skin/MediaWiki/Änderungen

Inhaltsverzeichnis

Overflow für Musiknoten

Warnbox in Common.css aufnehmen

Neues Gadget: localUserOptions

Deutsche Titel bei Spezialseiten

Neues Gadget: CoordinatesPagePopup.js

Vereinheitlichung der DBL-Einträge

Infobox unfloat lokal?

Dreimal Gadget

MediaWiki:Gadget-editMenusDef.css Darkmode Anpassung

Vorlagenbild mit Helferlein Navigation Popups