Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise
navigation-popups, Übersetzung und Restrukturierung
Frohes Neues, im Zuge von Spezial:Diff/195352561 müsste der nachstehende Aktionsplan umgesetzt werden, mit jeweils zwischenzeitlichem Funktionstest des Gadgets:
Ich höre erstmal bei Nr. 6 auf, damit alle schauen können, ob es auch funktioniert. Ich selbst benutze das Helferlein nicht. NNW17:16, 1. Jan. 2020 (CET)
Von meiner Seite sieht es korrekt umgesetzt aus, aber ich hab mit dem Dings auch nix zu tun.
Die bisherige Aktion benötigte zwei Runden Server-Abruf, das ist lahm und wegen race condition heikel, dass die deutsche Variante mal für ein merge zu spät käme. War aber offenbar langjährige Empfehlung aus enwiki.
Ich beabsichtige für die nächsten Tage eine zeitgenössische Doku-Seite mit diversen Verschiebungen, und dann auch eine Archiv-Übersicht mit den verschiedenen Diskussions-Orten.
Dabei sollen sämtliche Diskussionen zum WP-NR verschoben werden.
Es war sowieso eine Eselei, gleichzeitig zur WP/Doku und in derselben Angelegenheit im MW-NR zu diskutieren.
Bei Lua ist das anders gelöst: Alle Diskussionen leiten auf die eine zentrale Diskussionsseite weiter, und nur diese wäre bei Interesse zu beobachten.
Für die moderneren Gadgets werde ich das wohl auch mal konsequent einführen müssen.
Ach ja, die Erörterungen von vor fünf oder acht Jahren zu seinerzeitigen Gadget-Programmierungen sind alle kalter Kaffee, aber wegen Transparenz gäbe es einen Zwergenaufstand, wenn das missachtet und weggekippt würde.
Auf meta: habe ich nachgeguckt, du bist der Einzige, der uns als globales Skript aktiviert hat.
Ich werde nach Aufräum- und Modernisierungsarbeiten mal über alle de-Schwesterwikis und Commons streifen und nach weiteren Skripten suchen.
Grundsätzlich muss immer das Gadget als Ganzes aktiviert werden und nicht ein einzelnes Skript, weil zwar die Gadget-ID konstant über die Zeiten wäre, die dies implementierenden einzelnen Seiten das aber nicht sein müssen, wie gesehen. Außerdem solle eine Einbindung über load.php begleitendes CSS und Systemnachrichten sicherstellen.
Unsere eigene Programmierung werde ich gemäß jetzt gewonnener Erkenntnisse nochmals verschärfen und robuster gestalten; wird dann wieder auf BETA bereitgestellt.
Supi, danke :-) Für den Fall, dass das Gadget irgendwo völlig extern (außerhalb der Wikimedia-Wikis) eingebunden wird, könnte man ja für ein paar Wochen statt dem load-Statement eine Fehlermeldung in das zu löschende Script schreiben. --nenntmichruhigip (Diskussion) 14:37, 14. Jan. 2020 (CET)
Die Benutzer auf den Fremdprojekten wurden informiert.
Alarm-Meldungen bringen wenig; die könnten nur in die Konsole geschrieben werden, wo sie niemals jemand liest, oder aber es müsste mit einem heftigen Alarm die Wiki-Seite blockiert werden, worauf der Benutzer mit einem externen GreaseMonkey-Bookmarklet-sonstwas-Code überhaupt nicht kapiert, was die Alarm-Meldung meint und was nun wie zu machen wäre, und völlig überfordert ist.
Die alte Skript-Seite bleibt dann halt bis zum Umzug in den Gadget-Namensraum aus Kompatibilitätsgründen am Leben, wird nirgendwo noch Reklame dafür gemacht, ist dann halt ineffizient. Wer sie benutzt ist sebst schuld.
Die Gadget-Doku hat einen zeitgenössischen Rahmen erhalten.
Alle alten Diskussionen habe ich von vier verschiedenen Seiten zusammengekratzt und auf eine neue Diskussionsseite mit zentralem Archiv zusammengeschoben.
Es ist noch nicht aktiviert, wird aber wohl in den nächsten Wochen kommen: Angebot zum Verbleiben beim Vector von 2010/2014/2019.
In der Desktop-Sidebar links steht dann eine einzelne Verlinkung, die in deutscher Sprache über zwei Zeilen geht. Das ist irritierend, weil der Zeilenabstand für solch eine Verlinkung zu groß ist und eher nach zwei Verlinkungen aussieht. Die Schriftgröße ist herabgesetzt, der Zeilenabstand noch normalweit, was sinnvoll zur Abgrenzung unterschiedlicher Verlinkungen ist.
Gemäß WP:A/A#HS-definitiv erfolgt heute in der Nacht der (erste Versuch zum) Neustart unserer Hauptseite.
Gut wäre es, wenn ein BOA nach Mitternacht noch erreichbar wäre, sicherheitshalber.
Ansonsten nach Lagebericht auf WP:A/A am Sa morgens.
Nachstehend zwei Blöcke; der erste kann noch Fr im Lauf des Abends abgearbeitet werden; der zweite (MediaWiki:Common.css) nach Erfolg die Abschaltung möglicherweise konfligierender Regeln.
Für sehr unwahrscheinliche Konstellationen (Mobildarstellung auf HD-Breitbildschirm), die heute schon pervers aussieht, vorbeugend wegen Konflikt mit der Gesamtbreite
In MediaWiki:Common.css müsste nach erfolgreicher Umschaltung in den frühen Morgenstunden des Sa 11. Juni ziemlich zeitnah alles heraus, was mit +++++ 3. HAUPTSEITE zu tun hat. Meinem Eindruck nach gibt es entweder überhaupt keine Konflikte wegen völlig abweichender neuer Selektoren, oder sie hätten vorläufig verschmerzbare Wirkung. Es sollen dort nur noch verbleiben:
als BOA/A steh ich gerne zur Verfügung bis morgen früh 5:30 Uhr ca., zur Koordination/Messages würde ich aber gerne einen Abschnitt auf meiner Disk verwenden, um ein munteres Hin-und-Her-Switchen währenddessen zu vermeiden. Gehen wir so vor? – Doc Taxon • Disk. • 19:14, 10. Jul. 2020 (CEST)
Seit einiger Zeit erscheinen die Links unter "In anderen Sprachen" in wirrer Reihenfolge, siehe Diskussion hier. Das Problem ist bekannt und in Phabricator gemeldet, aber anscheinend dauert die Lösung noch länger. Die polnische und die schwedische Wikipedia setzen daher anscheinend einen "Hack" bzw. Workaround ein, der die Reihenfolge korrigiert. Ich bitte also darum, diesen auch hier einzubauen. Gestumblindi11:09, 20. Jul. 2020 (CEST)
localeCompare ist relativ kompatibel; Edge allerdings erst ab 12. Ich weiß nicht, ob das viel oder wenig ist, bin bei Microsoft nicht mehr so auf dem Laufenden. Ggf. crasht das dann halt.
classList ist DOM-Programmierung gemischt in jQuery-Programmierung ansonsten, was nicht sehr intuitiv verständlich wird.
Die .children() des $ul sind <li>.
.classList[ 1 ] ist in DOM die zweite Klasse einer Aufzählung von Klassenbezeichnern.
class="interlanguage-link interwiki-en" ist beispielsweise die einem en-Interlanguage-li zugeordnete Klassenliste.
Sortiert werden lauter Klassenbezeichner: interwiki-en interwiki-fr
Das entspricht unserer traditionellen Grundsortierung nach den Sprachcodes, wie sie sich auch aus den href= gewinnen ließen.
Den umständlichen und nicht mit Edge vollkompatiblen localeCompare-Ansatz habe ich nicht verstanden. Ich würde robuster und effizienter schreiben (ungetestet freihändig, mal Interessenten in BETA spielen gehen, wo aber wohl erstmal eine Testseite mit drei Interlanguages aufgemacht werden müsste; vielleicht besser auf testwiki: ein Benutzerskript):
localeCompare vergleicht Namen nach den Regeln der lokalen Sprache und Schrift, aber weil dies nur ASCII interwiki-en interwiki-fr ist, macht es die Aktion bestenfalls langsamer, wenn sie nicht bei irgendwem gleich ganz abstürzt.
Getestet: hier lokal, da irgendwie auf sämtlichen Betas und Testwikis ordentlich sortiert wurde: funktioniert und ist auch bei großer Interwikilinkliste recht performant, der Vergleichsoperator müsste noch gedreht werden für die gewohnte A–Z-Sortierung. Im Phabricator-Task wurde vorgeschlagen, MediaWiki:Group-user.js zu benutzen, da unangemeldet die verkürzte Interwikiliste gezeigt wird und die angeblich schon immer nach eigenem Gusto sortiert. Das halte ich für den gegebenen Fall im Sinne der Reduzierung von Zusatzlasten sinnvoll. -- hgzh15:50, 20. Jul. 2020 (CEST)
@MediaWiki:Group-user.js: Die wollte ich eigentlich nicht mehr einsauen und dokumentieren müssen.
Irgendwann steht sowieso der Umzug aller Skin-Ressourcen in den 2015 gebildeten Gadget-Namensraum an.
Das bekäme dann auch eine Doku-Seite, und auf der können wir die obigen und weitere Erkenntnisse festhalten.
Außerdem können wir das immer wieder aktivieren; ich habe es im Gefühl, dass sich der momentane Zustand wiederholen könnte, oder wir zukünftig anderweitige Modifikationen wünschen könnten, oder mobil oder was.
Die Syntax kennt zwar (noch) keine Benutzergruppen, aber minoreditsendemaileditmyuserjs sind Non-IP.
Damit können die Leute, die es nicht haben wollen, auch wieder opt-outen. Sei es wegen Performance, sei es weil es wohl noch Skripte gibt, die die Sprachnamen auf deutsch schreiben und dann vielleicht nach deutschen Sprachnamen alphabetisch oder was weiß denn ich, nach Kontinenten sortieren.
@Vergleichsoperator müsste noch gedreht werden:
Deshalb schrub ich „ungetestet freihändig“ und empfahl einen Test; war aus dem Handgelenk.
Bei diesen Sort-Vergleichsfunktionen muss ich jedes Mal 10 Minuten in die Doku gucken, wie war kleiner Null wenn dies oder sonst das bzw. true und false ist dann wann ergibt gleich was? Am Ende ist es immer genau andersrum als ich es zum Schluss dachte. Also teste ich lieber.
@performant: Bei Zeichenketten vergleichen <> plump die Unicodes.
localeCompare macht erstmal ein Fass auf, initialisiert eine Umgebung, und ist dann vorbereitet auf ß und ö und é und ñ – was bei ASCII-Sprachcodes etwas overkillernd ist.
Hallo, ich habe die Erfahrung gemacht, dass Chrome mit logischen Werten in der Sortierfunktion nicht klarkommt. Da würde eine Umwandlung in numerische Werte helfen: return ( a.classList[ 1 ] < b.classList[ 1 ] ? -1 : 1 );. --Wiegels„…“13:42, 25. Jul. 2020 (CEST)
Das wäre auch der konventionelle und nach ECMA erwartete Weg; für Array.prototype.sort(comparefn)
Die Geschichte mit boolean ist dann wohl eher Mozilla-basiert, und hatte mich beim Lesen der Doku ins Schleudern gebracht, siehe oben.
Ich brauchte aber sowieso einige Zeit, um auseinanderzupflücken, was der fremde Code warum macht, und halte das ohnehin für keinen sehr robusten Ansatz, aber für einen temporären Flicken wird es notfalls auch ein Jahr halten. Ich hätte unterstellt, dass ein <a> recht sicher ein Kind von <li> wäre, und dass dessen href mich die URL sortieren ließe; wie auch immer aufgebaut ist sie auch stets ASCII, hat den Interlanguage an der entscheidenden Stelle, und ich hätte die URL verglichen. Zurzeit wird darauf vertraut, dass bestimmte Klassen in bestimmter Reihenfolge stehen, was sich ohne Vorwarnung jederzeit ändern darf; auf sowas wäre ich im Traum nicht gekommen. Ist rein zufällig, wann welche Klasse in der Programmierung der Skin zugewiesen würde, und müssen auch nicht auf ewig grad solche an dieser Stelle sein.
Der traditionelle numerische Ansatz erlaubt es, dieselbe Funktion auch in .equals() zu verwenden, und ist der robustere. Das boolean findet sich als Alternative allerdings immer häufiger in Sortierfunktionen aller Sprachen.
Hallo, kürzlich wurde der mobilen Version der Seite ein Spenden-Link hinzugefügt (siehe T219793). Analog zur Desktop-Version (letzte entsprechende Bearbeitung von MediaWiki:Common.js) soll auf de.m.wikipedia.org der Link so umgebogen werden, dass er ebenfalls auf unsere Spendenseite zeigt und entsprechende Informationen zur Zuordnung enthält). en:User:Ammarpad hat in unserem Phabricator-Task (T257791) den Code-Schnipsel leicht angepasst und wir haben das auf unseren eigenen User-Script-Seiten getestet. Könnte jemand von euch den Code auf der Seite MediaWiki:Mobile.js hinterlegen? Die finale Version, in der auch die entsprechenden Parameter für unser Web-Analytics-Tool enthalten sind, findet ihr auf Benutzer:Kai_Nissen_(WMDE)/minerva.js.
Ich habe übrigens die ungenutzten Parameter language und country sowie die Abfrage auf die Spracheinstellung entfernt. Letzteres, weil der standardmäßig hinterlegte Zielseite donate.wikimedia.org auf GeoIP basierend immer auf unsere Spendenseite weiterleitet. Diese Änderung könnte auch in der Version auf MediaWiki:Common.js nachgezogen werden. Vielen Dank! Kai Nissen (WMDE) (Diskussion) 14:13, 17. Jul. 2020 (CEST)
Jo, kann man wohl so machen.
Ohne dass ich mich mit piwik_ und einer mobilen Sidebar auskennen würde.
In MediaWiki:Common.js solle der Abschnitt unter Ändere den Spenden-Link im Sidebar für Besucher aus Deutschland durch den identischen neuen Code ersetzt werden; jedoch hieße der Selektor dort n-sitesupport a für Desktop-Skins.
Zwei Anmerkungen zum Code:
typeof wird schon seit längerer Zeit als Operator notiert und nicht als Funktion; also ohne die Klammern.
Vielen Dank schonmal, deine beiden Anmerkungen kannst du gern auch einfließen lassen. Alles, was die Fehleranfälligkeit reduziert, ist natürlich sinnvoll. Die Bemerkung zum Nachziehen der Änderung auf MediaWiki:Common.js bezog sich lediglich auf die nicht benötigten Parameter und die Bedingung, nicht auf den gesamten Schnipsel. Kai Nissen (WMDE) (Diskussion) 15:29, 17. Jul. 2020 (CEST)
Vielen Dank für den Hinweis, ich halte es auch für besser, statt typeof( Geo ) === "object" lieber typeof Geo === "object" && Geo !== null zu verwenden (sowohl in Common.js als auch Mobile.js) Gabriel Birke (WMDE) (Diskussion) 15:50, 17. Jul. 2020 (CEST)
Die Bedingung wäre also: if ( typeof Geo === "object" && Geo !== null && Geo.country === 'DE' ) {, unabhängig von der Benutzersprache, wie derzeit noch in der Common.js? -- hgzh14:19, 18. Jul. 2020 (CEST)
Ja, schon besser.
Allerdings hatte ich oben mit window.Geo unter 2.) noch etwas anderes angedeutet: Geo wird hier als deklarierte Variable vorausgesetzt.
In dem Moment, in dem das site-JS gekapselt wird (wie es vorübergehend bis zu einem rollback schon mal kurzzeitig für Benutzer-JS eingeführt wurde), ist das nicht mehr bekannt, und im Falle des absehbaren strict führt die bloße Verwendung bereits zu einem protokollierten Laufzeitfehler.
In jedem Fall könnte die Bedingung in einer gekapselten Umgebung nie ausgewertet werden, weil Geo dann immer undefined ist und die Spendengelder werden niemals umgeleitet.
Ergo gehört das robust und zukunftssicher an das globale Objekt des Browsers angebunden.
Eine Abfrage nach explizit null ist nicht erforderlich, weil dies der einzige Zustand ist, in dem etwas nicht etwas wäre und trotzdem object sei.
Wobei es durchaus realistisch ist, dass vor dem Klick auf den Spendenbutton irgendein Skript von irgendwem zuschlug und aus Datenschutzgründen das indiskrete Geo neutralisiert hätte, egal wie.
Inhaltlich stellt sich mir die Frage, warum nur WMDE die Pinke umleitet und WMAT und WMCH nicht, aber mit der Finanzorganisation müssen sich die dortigen Schatzmeister auskennen.
Liebe Mitinteressierte, da wir jetzt erstmals einen Nichtadmin haben, der als BOA tätig sein möchte, habe ich das angekündigteMB in die Vorbereitung gestellt und bitte um Unterstützung. Gruss, --MBqDisk12:18, 6. Jul. 2020 (CEST)
Bin ich hier richtig? Der Link "Bildsuche" im Drop-Down-Menü über Artikeln funktioniert seit einiger Zeit nicht mehr. Es wird zwar die richtige Domain fist.toolforge.org aufgerufen, aber anscheinend wird die Abfrage nicht richtig gebildet, jedenfalls ist das Resultat ein 404. Kann das jemand korrigieren? Gestumblindi21:23, 23. Jul. 2020 (CEST)
Es gibt Tools, die eignen sich wegen der Art ihrer URL-Analyse und Parameterversorgung oder was immer momentan nicht zur Migration.
Dazu gehören meiner Erfahrung nach sämtliche Tools aus dem Hause Manske, aber auch andere.
Heißt: Es müssen alle migrierenden Tools einmal mit Parametersatz angefasst werden (parameterlose „Homepage“ geht zuweilen trotzdem) und geschaut, ob sie noch liefern.
Mit der letzten fist haute was nicht hin; die war am Ende doppelt gemoppelt und kann so nicht funktionieren.
Stecke da aber grad nicht so drin; andere ToDo-Liste, just4info.
Es ist jeweils nur eine einzige Seite, die das Problem hat. Es genügt auch, dass es ein einziges fehlerhaftes Argument gäbe. Es ist keine auslösende Bedingung, dass es mehrere formatnum-Argumente sein sollen.
Der translatewiki-Übersetzungsvorschlag wirkt erstmal auf alle deutschsprachigen Wikis. Damit können die nicht wissen, dass es bei uns Wikipedia: heißen würde, und die nennen sie erstmal irgendwie. Die Alternative wäre Englisch. Wir fangen die ansonsten vorher ab und setzen Systemnachricht und neue Wartungskat bevor das produktiv wird. VG --PerfektesChaos13:21, 25. Sep. 2020 (CEST)
Soweit ich das sehe, müsste auch contentSub2 auf der Hauptseite ausgeblendet werden, da sonst ein zu großer oberer Abstand erzeugt wird. Also bitte in MediaWiki:Common.css zusätzlich zu .action-view.page-Wikipedia_Hauptseite #contentSub noch .action-view.page-Wikipedia_Hauptseite #contentSub2 auf display:none setzen! Gruß–XanonymusX (Diskussion) 20:34, 2. Okt. 2020 (CEST)
Testfall, wenn jemand will: Ikarus (1975) Dort ist eine blödsinnige LCCN im VIAF-Cluster. Damit die irgendwann aus dem Cluster entfernt wird, ist sie bei Wikidata als "Missbilligter Rang" eingetragen. Das Orischinool-Script von Schnark schlägt diese vor, nach meiner Änderung wird die nicht mehr vorgeschlagen.
Es können nicht alle paar Wochen BOA in Schnarks Skripten herumprogrammieren.
Es kann ein Wurgl-Fork im eigenen BNR eröffnet werden, und die Handvoll Intensivtäter, die das nutzen, können den Namen im Pfad von Schnark auf Wurgl umstellen, bis Schnark wieder live ist.
Als Schnark vor einem Dutzend Jahre hier anfing, war er junger Student; dann wird er sich wohl gerade in einer anderen Lebensphase befinden und könnte dauerhaft stärker in Anspruch genommen werden.
Schnarks Skript müsste durch BOA auf den letzten Originalzustand von Dezember 2019 revertiert werden.
Maximal könnte anschließend, wenn sich das länger hinziehen sollte, das komplette Schnark-Skript ersetzt werden durch einen Kommentar plus mw.load auf den Wurgl-Fork. Dann ist immer klar ersichtlich, welche Programmierungen von Schnark vorgenommen wurden und von Schnark zu verantworten sind, und was von Wurgl auf dessen Verantwortung in dessen BNR programmiert wurde.
Erstmal ein dickes Danke für den Murks. Sowas hört man gerne, vor allem wenn es einfach so in den Raum geworfen wird.
Es geht rein um die Ränge der 4 Normdaten-Ids für VIAF, LCCN, GND und NDL und die sind bei Wikidata schlecht zu sehen, siehe Bild.
Es gibt drei Ränge: "bevorzugter Rang", "normaler Rang" und eben der "missbilligter Rang". Der visuelle Unterschied ist nur die Position des Knopfes.
Und wie schon kurz geschrieben: Missbilligte Ränge werden eingetragen wenn der VIAF-Cluster welches das Wikidata-Objekt enthält nicht passende Einträge enthält. Die werden nicht rausgelöscht, weil sonst irgendein schlauer Bot daherkommt und das wieder einträgt. Näheres dazu unter Sisyphos.
Der Wurgl-Fork ist kappes. Die ca. 380 Benutzer von Fliegelflagel können das nicht verwenden, weil Fliegelflagel schon selbst das Normdaten-Dingens einbindet und zwar von Schnarks Seite. Die knapp 100 Benutzer, welche das Normdaten-Dingens direkt eingebunden haben, könnten.
Und dann noch zur Verantwortung. Woraus besteht diese Verantwortung und welche Folgen wären denn für Schnark oder für mich zu erwarten, wenn diese Änderung Blödsinn machen würde? Wohl kaum mehr als Böser Blick und diese Verantwortung kann ich aushalten und wie man so munkelt, kann das Schnark auch aushalten.
Ob er junger Student oder alter Knacker ist bzw. war, ist vollkommen irrelevant. Ja, die Scripte sind in seinen Benutzer-Seiten, solange er aktiv war, verlangt der Resepkt, diese nicht zu ändern. Aber da er seinen letzte Edit am 9. März 2020 gemacht hat und am 3. August 2020 ein Danke abgesetzt hat, kann man davon ausgehen, das er inaktiv ist und wohl bleibt. Jedenfalls sind Scripte eines Users nach dessen aktiver Zeit nicht sakrosankt.
Und falls sich jemand diesen Murks ansehen will, hier ist der Diff. An vier Stellen (weil vier Properties) ist ein if-Statement hinzugekommen und ja, die geänderte Überschrift ist wieder zurückgeändert. Mehr ist da nicht. --Wurgl (Diskussion) 17:30, 17. Okt. 2020 (CEST)
Jeder BOA, der ohne eine andere Lösung in Betracht zu ziehen in den Skripten fremder Benutzer in irgendwann nicht mehr nachvollziehbarer Weise herumprogrammiert sollte seine Lizenz abgeben.
Für den Code ist Schnark verantwortlich, weil das Skript unter seinem Namen steht, und niemand sonst. Wenn da in undurchschaubarer Weise alle möglichen anderen Leute in seiner Programmierung herumpfuschen dann blickt niemand mehr durch; verantwortlich ist nach wie vor derjenige Account in dessen BNR die Ressource steht.
Schnark wird ein paar Monate beruflich oder familiär oder Corona oder sonstwie eingespannt sein. Es ist ziemlich dreist, ihn dann aus Bequemlichkeit gleich zu beerdigen, der kommt ja sowieso niemals wieder, also basteln wir jetzt in fremder Leute Software herum. Das nenne ich respektlos.
Wie das zu lösen geht, hatte ich oben bereits geschrieben:
Die letzte bereits unerlaubte Änderung der guten Ordnung halber erstmal wieder revertieren.
Als neueste Skript-Version eine komplett neue Programmierung einbauen, die aus genau zwei Elementen besteht:
Ein Kommentar, der die Situation und Gründe beschreibt.
Ein mw.load auf den Wurgl-Fork.
Dann funktioniert es auch bei irgendwelchen 380 Fliegelflagel-Anwendern.
Power-User können sich direkt den Wurgl-Fork einbinden und sparen sich den round-trip.
Maintainer und offenkundig Alleinverantwortlicher für die veränderte Programmierung ist dann Wurgl.
Wenn Schnark hoffentlich mal wieder Zeit und Gelegenheit hat, kann er die Wurgl-Ideen übernehmen oder verwerfen oder sonstwas nach seinem Belieben anstellen.
Es sollte Wurgl und jedem anderen möglich sein, einen Patch vorzuschlagen, ohne gleich für einen ganzen Fork verantwortlich sein zu müssen. Die Verantwortung für solche Patches ergeben sich aus der Versionsgeschichte und hier auch ZuQ, da Auftragsedit. Wenn Schnark zurückkommt und damit nicht zufrieden ist, kann er das natürlich zurücksetzen. ---MisterSynergy (Diskussion) 18:31, 17. Okt. 2020 (CEST)
„Patches“ gibt es nur für Community-gepflegte Ressourcen.
Das hier ist ein Benutzerskript in einem BNR, und dies verlässt sich auf den guten Namen von Schnark und niemand sonst. Niemand ist dazu befugt, in dem unter einem fremden Namen angebotenen Benutzerskript ohne Aufforderung in fremdem BNR herumzuprogrammieren.
Hier ist die Lösung ganz klar und einfach: Die letzte, bereits unerlaubte Veränderung revertieren, als oberste Version die Umleitung auf den Wurgl-Fork anlegen; und dann ist es ausschließliche und trivial nachvollziehbare Verantwortung von Wurgl was das JavaScript dann anstellt, und es braucht bei mutmaßlichen weiteren Veränderungen auch niemand gefragt zu werden.
Das Problem ist, dass Du hier einem Benutzer die Wartung eines Skriptes aufzwingen willst, im Tausch für eine durchaus sinnvolle kleine Verbesserung. Das ist aber nicht zuzumuten, denn Wurgl müsste damit erstmal das Skript und Verantwortung für mögliche Altlasten übernehmen und sich im Anschluss mit möglicherweise ihn überhaupt nicht interessierenden Anfragen zu ganz anderen Dingen rumplagen. Wenn im fremden Benutzernamensraum keine Skripte verändert werden sollen, was man ja durchaus fordern kann, dann gehört das von Schnark zurzeit nicht betreute, aber von der Community stark genutzte Skript halt umgehend in den Projektnamensraum zur Wartung durch die gesamte Community. Ich persönlich halte eine Modifikation an aktuellem Ort für angemessener, in der Hoffnung dass Schnark irgendwann mal wieder da ist und das dann wieder mit entsprechender Hoheit betreuen kann. ---MisterSynergy (Diskussion) 00:20, 18. Okt. 2020 (CEST)
Das Problem ist vielmehr, dass auch die Community keinerlei Kapazitäten zur Wartung und Pflege von JavaScript-Gadgets hat.
Alle unsere JS-Gadgets auf dem geistigen Stand von 2015 stammen von mir oder wurden von mir auf diesen Minimalstandard gebracht, falls ich da jetzt niemand übersehen hätte und jemandem Unrecht täte; oder sie sind WMF-gepflegte Codes und die Programmierung ist 1:1 von dort kopiert.
Wir haben noch ein halbes Dutzend Kadaver aus der Skriptbastelei-Ära, die auf dem behelfsmäßigen Stand von 2011 ihrer allgemeinen Unbrauchbarkeit entgegendämmern, oder irgendwer schreibt die fundamental neu.
De facto bedeutet das, dass die Verantwortung für die Wartung und Pflege auf ein unbestimmtes „Niemand“ von dir übertragen wird.
Ich jedenfalls lehne es strikt ab, für ein derart komplexes Community-Normdaten-Gadget irgendeine Mitverantwortung zu übernehmen und auch nur ein Byte daran inhaltlich zu betrachten.
Die JavaScript-Programmierungen bedürfen verantwortlicher Maintainer.
Für alles im BNR ist das immer der Account zwischen erstem Doppelpunkt und erstem Schrägstrich.
Für Community-Gadgets ist das ein unklares Alle-Jeder-Keiner.
Für die Altlasten Stand 2010 aus der Monobook-Skriptbastelei-Ära übernehme ich das, sofern es sich um zukunftsfähige Ansätze handelt, und habe das auch bereits auf den aktuellen Stand der Technik gebracht.
Es sind also noch nicht mal alle unsere Bestands-Skripte in einem befriedigenden Zustand, geschweige denn dass „wir“ uns noch neue Riesen-Pakete an den Hals hängen sollten. Die großen Unbekannten außer mir machen ja jetzt schon über Jahre keinen Finger krumm.
Community-Gadget heißt formal, dass ausnahmslos jeder Autor der deutschsprachigen Wikipedia für die Wartung und Pflege verantwortlich ist. Wohl bekomm’s.
Im Übrige ist das ein kein Feature, das Hunderte und Tausende von Bearbeitern alltäglich benötigen.
Es gibt sicher ein halbes Dutzend Power-User, die es häufig anwenden, und vielleicht noch ein halbes oder auch ganzes Dutzend Gelegenheitsnutzer, die es hin und wieder mal konsultieren.
Das Dutzend Leute, das es benutzt, soll sich dann auch intern mit ihren eigenen aktiven Accounts um ihren temporären oder permanenten Fork kümmern.
Sollte irgendein BOA sich bequatschen lassen, ein Schnark-Skript zum Community-Gadget zu machen, werde ich sämtliche Wartungs- und Pflege-Aufgaben an diesen persönlich adressieren.
Das gilt ggf. auch für alle weiteren beteiligten BOA und auch diejenigen, die das befördert hätten.
Unbekannten Anderen die Verantwortung und Lasten aufdrücken und sich selbst still und leise vom Acker schleichen ist eine Verhaltensweise, die von mir nullkommanull Unterstützung bekommt.
Es geht nicht darum, ob das das 100 oder mehr oder weniger User verwenden.
Es geht um die Qualität unserer Normdaten.
Wenn man es so lässt, wie es ist, dann kommen durch einfachen Klick bei nicht so geübten (oder schlampigen) Usern falsche Daten in die Vorlage.
Wenn man diese falschen Bei Wikidata nicht so markiert, sondern löscht, dann kommt ein Bot und malt die wieder lustig rein und wir sind wieder beim oberen Punkt.
Das ist der Grund für die Änderung bzw. Erweiterung.
Wenn du sorry Scheiß-Daten bei den Normdaten haben willst, dann stell dich weiterhin quer. Dann lassen wir das eben. Dann kommen halt Scheiß-Daten bei uns in die Normdaten. Ist doch egal, PC will sein Heiligtum verteidigen. </rant> --Wurgl (Diskussion) 13:37, 18. Okt. 2020 (CEST)
Ich habe dir oben einen gangbaren Weg aufgeschrieben.
Ob du oder ein anderer Normdaten-PowerUser ihn geht und eigenverantwortlicher Maintainer eines Forks wird, ist eure Sache.
Für die bekannten Intensivtäter bedarf es überhaupt keinerlei Eingriffe in fremder Leute BNR; dazu müsstet ihr nur die einbindende URL auf deinen Fork umstellen.
Dass Benutzeroberflächenadministratoren Änderungen in fremden Benutzerskripten vornehmen, ist die absolute Ausnahme und wird es auch bleiben. Wenn aber ein Skript viel von anderen Benutzern verwendet wird, der Maintainer inaktiv ist, die Änderung überschaubar und aus gut Gründen angezeigt ist, sie hier vorgestellt wird und es keine technischen Einwände zu ihr gibt, dann können Benutzeroberflächenadministratoren sie meiner Einschätzung nach auch umsetzen. Das sehe ich hier als gegeben, werde die Umsetzung deshalb vornehmen und Schnark auf seiner BD davon mit Hinweis auf diese Diskussion in Kenntnis setzen. Dann kann er sich die Änderung anschauen und ggfs. rückgängig machen, wenn er wieder aktiv wird. --Count Count (Diskussion) 15:10, 18. Okt. 2020 (CEST)
Unsere globalen Designer haben kürzlich entschieden, überall das Element <blockquote> mit einem links(LTR)seitigem grauen Streifen zu versehen.
Das ist offenbar erst vor wenigen Tagen wirksam geworden; mutmaßlich per WP:NEU gestern.
Hintergrund ist, dass in vielen Sprachen die Zitate den Lesern nicht durch Anführungszeichen verdeutlicht werden. Der graue Balken soll ab sofort von den Lesern aller Sprachen als Anführungszeichen verstanden werden.
Unsere Vorlage:Zitat verwendet jedoch umschließende Anführungszeichen.
Hingegen gibt es Hunderte von Autoren, die unter Missachtung der semantischen Bedeutung das Element <blockquote> missbrauchen, um typografisch eine Einrückung von Bildern, Tabellen, Galerien usw. zu erreichen.
Diese Masche ist in der enWP sehr beliebt, und unsere übersetzenden Abkopierer haben das von dort buchstäblich übernommen. Die enWP wird dann jetzt auch noch ihren Spaß haben.
Ich gehe deshalb von einem Rollback in den nächsten Wochen aus; abwarten und Anfang Dezember mal die Situation peilen.
Man hat jetzt allen Wikis eine Einrückung um 32px verordnet; unabhängig von der Schriftgröße – wir rücken die Blockzitate aber bereits Schrift-proportional um 2em ein.
Am Rande erwähnt sei, dass ich seit einem Jahr plane, eine vielsprachige Version der Vorlage:Zitat herauszubringen; mit einem ähnlichen Balken am rechten Rand, mobil-platzsparend ohne Einrückung, durch andere Symbolik Zitate auch kenntlich machend, wo das wegen Aufzählungsliste oder sonstiger besonderer Gestaltung nicht möglich ist (etwa auch Gedichte, Lieder; Schriftsysteme, die keine derartige Zitat-Kennzeichnung kennen).
Die verlinkten Beispiele, in denen diese Formatierung eher unvorteilhaft aussehen, überzeugen mich; ich würde die manuelle Überschreibung daher so umsetzen, wenngleich es im phab:T265947 bisher nicht danach aussieht, als würde das alsbald wieder verschwinden. Allerdings würde ich die Mobile.css nicht anpassen, da das anscheinend dort bereits zuvor so war. -- hgzh19:04, 12. Nov. 2020 (CET)
Aha. Demzufolge würde es reichen, Vector.css zu nullen.
Ich wusste vom Hintergrund der phab:T265947, aber diese am 19. Oktober 2020 losgetretene, von einer Einzelperson ohne Kontakt mit Communities umgesetzte Aktion war mir nicht bekannt. Hatte noch keine Zeit gehabt, die Task zu suchen.
Ich überlege noch, ob man denen schreiben soll, dass wir ihr Zeugs plattemacht haben.
Erste Proteste aus Communities laufen bereits auf.
Der Umstand, dass unsere Vorlagen-Zitate bereits durch Anführungszeichen gekennzeichnet sind, floss in die globale Weisheit nicht ein.
Wenn man schon in das Design von knapp 1000 Wikis eingreift, sollte man das schon vorher in diesen ulkigen Tech Newsletters vorher ankündigen; auch besser noch vor dem Handeln eine globale Stellungnahme/RFC abwarten.
Mobil ist mir vorläufig egal.
Mit einer Renovierung der Vorlage:Zitat wird dieser Balken links dann dort ebenso weggemacht.
Während Desktop links und rechts ein Stück einrückt (was rechts bei unserem Flattersatz selten wahrnehmbar ist), nutzt Mobil den Platz rechts voll aus und macht dafür zurzeit diesen Balken hin.
Also ich bin nicht wirklich froh über diesen Balken, das fördert anscheinend zudem die unerwünschte Verwendung der blockquote-Tags zwecks Formatierung. Spezial:Diff/205753715 das sollte unterdrückt werden. Sonst landet das vermutlich auch vermehrt im ANR. Es gibt schon jetzt tausende davon. Das ist echt kontraproduktiv. --Liebe Grüße, LómelindeDiskussion06:56, 21. Nov. 2020 (CET)
Seit letzter Woche erhalten unsere Tools eine neue Domain toolforge.org und sind dem Interwiki-Link-Format nicht mehr wirklich zugänglich. Um die lästigen zu vermeiden, sollte:
Seeeehr unwahrscheinlich, dass ein Fremdbetreiber unsere.toolforge.org/ in seine URL einbauen würde.
Sollte doch ein solcher externer Dienst auffallen, Massen an Google-Suchen nach uns, dann könnte diese spezielle Website notfalls wieder explizit extern geschaltet werden.
nach der derzeitigen Lösung werden Links a la https://pageviews.toolforge.org (ohne abschließenden Schrägstrich, kommt vor) noch mit dem Extern-Symbol versehen. Bei Entfernen des Schrägstrichs könnte dann auch onlinedrugs.toolforge.organisedcrime.com als intern markiert werden. Handhabbares Risiko oder eher nicht?
Wir schreiben aus genau diesem und ähnlichen Hintergründen projektweit und im ANR vorrangig und weitaus überwiegend die Domains immer mit Schrägstrich.
Wenn ein Bearbeiter dazu zu faul ist, gibt es halt ein External-Symbol. Auch kein Weltuntergang.
Es war bereits eingewendet worden, dass theoretisch (etwa bei einer Web-Archivierung oder in einem nicht-Google-Suchergebnis) unsere URL auch als Teil der URL jenseits der Domain aufttreten könne. Noch weiter aufweichen sollten wir deshalb nicht, sondern an Syntax nutzen was CSS hergibt.
@Gadgets:
Das soll ja angeblich seit Mitte Juni vollproduktiv in Betrieb sein; allzugroße Klagen über kaputte Zugriffe habe ich bislang bei fachgerechtem Umgang noch nicht gesehen.
Kann man also gern so allmählich bisherige Programmierungen nachziehen, um der neuen Lastverteilung möglichst viel Traffic auf den neuen Subdomains zuzuliefern.
Dann oute ich mich mal als mitunter faul ;) Große Dringlichkeit hat es nicht für mich, ist eben nur verschieden zu den anderen dieser Regeln. Die Gadgets nehme ich mir dann die Tage stückweise vor. Commons wird ebenfalls nicht als zugehörig markiert, Wiktionary etc. auch nicht, nur Wikidata. Ein bisschen inkonsistent, aber da habe ich im Moment keine Präferenz für oder gegen eine Extern-Kennzeichnung. -- hgzh18:33, 18. Jul. 2020 (CEST)
„verschieden zu den anderen dieser Regeln“ ist es, weil wir ansonsten die Subdomain genau kennen, und deshalb bei // beginnen können.
In der Toolforge hat jedoch jeder Account eine eigene Subdomain; das ist ja der Witz.
Und da es in CSS nur „fängt an mit“ oder „enthält“ zur Auswahl gibt, aber keine wildcards, muss halt auch mal bisschen inkonsistent sein.
Es geht darum, redundante div aus den CSS herauszunehmen, die zukünftig die Funktionalität blockieren werden, weil die Teile bald <nav> oder so heißen.
Diverse dürften inaktiv sein; Messerjokke79, Jogo.obb, Thoken fallen mir spontan als aktiv ein.
Wäre pragmatisch eine Lösung zu finden.
Im Übrigen bin ich der Meinung, dass die Angelegenheiten des Jahres 2019 auf dieser Seite verantwortlich zu archivieren wären.
1 ist umgesetzt. Verstehe ich das richtig, dass bspw. div#p-Mitmachen.portal unverändert bleibt? NNW19:51, 29. Mai 2020 (CEST)
Es ist hier unser lokales Gewächs, und deshalb global unbekannt und nicht erwähnt, aber da müsste es vorsorglich auch weg.
#p-Mitmachen.portal wirkt auf das (erste) Element der Seite, das die id="p-Mitmachen.portal" hat, und das ist momentan ein <div> – es wirkt auf kein anderes, weil es auch das einzige mit dieser id= ist oder sein sollte.
Die Geschichte mit div#p-Mitmachen.portal macht es nicht besser; es kommt im Moment das gleiche Element dabei heraus, aber wenn das Portal irgendwann mal vom unspezifischen <div> auf die speziellen semantischen strukturellen Elemente von HTML5 umgestellt wird, dann verhindert die explizite zusätzliche Forderung nach div, dass diese Elemente noch die Forderung erfüllen.
inhaltlicher falscher Seitenschutz-Hinweis in englischer Sprache
(Nicht ganz sicher, ob das hier richtig ist.)
Ich wollte gerade eine Seite mit *Halbschutz* *Dreiviertelschutz* bearbeiten und bekam folgenden Text in einer gelben Warnbox eingeblendet:
Warning: This page has been protected so that only users with administrator privileges can edit it. The latest log entry is provided below for reference: …
Meine Benutzeroberfläche wird in englischer Sprache angezeigt, deshalb ist die Wahl der Sprache zwar richtig, ihr Inhalt aber nicht da die Seite ja nicht vollgeschützt ist und ich sie tatsächlich auch bearbeiten konnte. Mit URL-Parameter "?uselang=de" bekomme ich in der Tat die inhaltlich korrekte deutschsprachige Nachricht:
Achtung: Diese Seite wurde geschützt, so dass sie nur durch Sichter bearbeitet werden kann. Gründe für den Seitenschutz finden sich im Seitenschutz-Logbuch, auf der Diskussionsseite oder in den Regeln für geschützte Seiten. Auszug aus dem Seitenschutz-Logbuch: …"
Jetzt finde ich gerade nicht, ob das onwiki irgendwo im Mediawiki-Namensraum zu verändern ist, oder ob das in die Software eincodiert ist oder über das Translatewiki geht. Kann da bitte mal jemand nachschauen?
Erstmal würden die einfachen WP:A/A hier reichen, wenn überhaupt, da es sich um eine textliche Nachricht auf dem Server handelt und nicht um eine Programmierung in einer Programmiersprache des Browsers.
Des weiteren könnte es um ein konzeptionelles Problem gehen; der englischsprachigen globalen Welt ist womöglich unser lokales Konzept des Dreiviertelschutz unbekannt – insbesondere sind „Sichter“ eine deutschsprachige Spezialität. Für fast jedes andere Wiki ist „mehr als Halbschutz“ identisch mit „Admin erforderlich“.
Deine eingangs erfolgte Situationsschilderung kann nicht zutreffen; es ginge nicht um „Halbschutz“ (IP oder Newbies ausgeschlossen), sondern um „Dreiviertelschutz“ (Nicht-Sichter ausgeschlossen).
Ich werde das weiter ermitteln und die weiteren Schritte veranlassen; hier erl.
Info: Es ist nicht MediaWiki:Protectedpagemovewarning, wie weiter oben geantwortet wurde, sondern eine komplexe lokale Programmierung innerhalb von MediaWiki:Protectedpagetext, die auf den Schutzlevel editeditorprotected reagiert (was „Sichter“ meint). Diese müsste komplett ins Englische übertragen werden.
Vorbemerkung: Die „Auswertung“ stammt nicht vom Ersteller der Umfrage und erfolgte unabgesprochen und ungefragt.
Grundsätzlich ist es jetzt Einschätzung möglicherweise umsetzender Admins, inwieweit die absolute Anzahl an Stimmen sowie das Verhältnis für eine Aktivität hinreichend erscheint.
Zu den Punkten im Einzelnen:
Zu „Datei hochladen“ wird offenbar eine Umlenkung des Linkziels gewünscht.
Das müssten die BOA dann in eigener Verantwortung realisieren.
Der Punkt „Änderungen an verlinkten Seiten“ wird offenbar von einigen Langzeit-Autoren weiterhin für sich persönlich gewünscht, kann aber offenkundig ohne Not für nicht angemeldete Leser wegfallen.
Das ließe sich über die Common.css realisieren, indem #t-recentchangeslinked zunächst ein display:none erhält, und danach .useronly #t-recentchangeslinked ein display:block
„Fragen von Neulingen“ wird offenbar von einigen Benutzern gewünscht; ggf. einfügen.
Die „Druckversion“ macht nichts anderes als die heutzutage möglichen Browser von selbst machen können.
MediaWiki wird dies über kurz oder lang von selbst im Zuge anderer Desktop-Änderungen entfernen.
Kann bis dahin per CSS ausgeblendet werden; ist uns nicht direkt zugänglich.
Grundsätzlich fällt umso mehr Aufmerksamkeit auf die verbleibenden Punkte, je weniger andere Funktionen es gibt – umso kürzer die Aufzählungen sind.
Generell läuft zurzeit auch global ein Experiment zur Modernisierung der seit 2010 unveränderten Desktop-Oberfläche.
Dabei haben sich um zehn Wikis gemeldet, die bereit sind, auf ihrem Wiki Änderungen zu erproben und auswerten zu lassen.
Die Erfahrungen dieser Wiki-Communities werden danach global für sämtliche Wikis einheitlich umgesetzt. Ansichten der deutschsprachigen Wikipedia sind dann irrelevant.
Insbesondere ist zu erwarten, dass für nicht angemeldete Leser die Oberfläche deutlich gestrafft und reduziert sowie voraussichtlich auch eingeklappt wird.
Was für angemeldete Benutzer passieren soll, bleibt abzuwarten; es werden aber wohl in jedem Fall die Funktionalitäten inhaltlich sauberer gegliedert umsortiert.
Generell gilt die Desktop-Oberfläche von 2010 auch in Koexistenz mit der Mobil-Oberfläche und der zeitgenössischen Gestaltung von den Lesern vertrauter anderer Webseiten als Sanierungsfall.
Was mir schon vor der Umfrage klar war: Für die Autoren von 2005 muss alles auf ewig so bleiben wie sie es 2005 mal gelernt hatten. Der Rest der Welt einschließlich aller Nur-Leser hat sich nach ihnen zu richten.
Ich rate von der Umleitung des Datei-hochladen-Ziels auf einen direkten Commons-Upload immer noch dringend ab! Des Weiteren war das eine Umfrage, kein MB. Eine Umfrage dient nur dazu, um abzuschätzen, wie die Stimmungslage ein. Konkrete Handlungen können daraus keine resultieren. -- Chaddy · D21:42, 1. Mär. 2020 (CET)
Eine direkte Commons-Verlinkung halte ich persönlich auch für schwierig. Eine Verlinkung auf eine Zwischenseite fände ich gut, die klarmacht, dass zwar das Gros nach Commons gehört, Dateien, die unter das Schutzlandprinzip fallen (u.Ä.), aber hier hochgeladen werden müssen. NNW10:17, 2. Mär. 2020 (CET)
MBs sind keine Pflicht – wenn Konsens besteht, kann selbstredend auch ohne die Oberfläche modifiziert werden. --MGChecker – (📞| 📝| ) 12:18, 2. Mär. 2020 (CET)
*quetsch* An Umfragen nehmen aber stets nur recht wenige Leute teil, eben weil sie durchaus zu Recht der Ansicht sind, dass es ja nur eine unverbindliche Umfrage sei. Daraus dann einen Konsens ableiten zu wollen ist zu kurz gegriffen. -- Chaddy · D15:41, 2. Mär. 2020 (CET)
Mein ursprünglicher Vorschlag in der Portalseite lief darauf hinaus, die Direktverlinkung auf die hiesige Spezialseite im Portal-Rahmen ersatzlos zu streichen und nur noch über Bildertutorial, Hilfeseiten oder andere Projektseiten zum Hochladen zu führen; ersatzweise über Spezial:Spezialseiten für Insider.
Dadurch sollen Hochlade-Interessenten sich vorher Gedanken über Rechte, unerwünschte Bilder und auch die Wahl des geeigneten Wikis machen.
Die „Zwischenseite“ wäre gerade die Anleitung, die sowas erklärt, und davon haben wir bereits diverse. Tendenz der Umfrage ist jedoch, dass sich für die Hardcore-Autoren von 2005 nichts ändern darf, was sie 2005 mal gelernt hatten, und es deshalb keinerlei zusätzlichen Klicks und zwischengeschalteten Menüs wie Spezial:Spezialseiten geben dürfe, sondern für sie alles mit nur einem Klick erreichbar bleiben solle.
Die Direktverlinkung im Portal stammt von 2003/2004 und damit aus einer Zeit, als es noch gar keine großen Anleitungen gegeben hatte, und auch Rechtsfragen in DACH unterschiedlich als auf dem gerade erst begründeten Commons steckten noch in den Kinderschuhen.
Weil alles auf ewig so bleiben muss, wie es 2005 mal gewesen war, auch wenn es inzwischen um die 200 Spezialseiten gibt und seinerzeit noch kein Dutzend, die man mal alle einzeln im Portal direkt zu verlinken gedachte, sieht der Rahmen halt noch so aus wie 2005/2010 stehengeblieben.
Auf WP:NEU #Version 1.35.0-wmf.21 steht inzwischen bereits die Ankündigung des Legacy-Vector, welches den Zustand von 2010 einfriert, während Vector sich davon abkoppeln wird und Schritt für Schritt zunächst für nicht angemeldete Besucher die Modernisierung vollziehen wird.
Kein Admin ist verpflichtet, ein Ergebnis der Umfrage umzusetzen, das als nicht zielführend eingeschätzt wird.
Ich habe eben den „wikEd“ unter den Helferlein in den Einstellungen ausprobiert. Dieser editor ist eine einzige Katastrophe. Ein Beispiel: Wenn ich auf der Disk signieren will, lande ich - ohne es zu zu beabsichtigen - in der Überschrift des Threads. Auch andere schwerwiegende Fehler traten auf. Die Programmierung ist sehr fehlerhaft. Kann der wikEd bitte sofort aus der Liste der empfohlenen Helferlein entfernt werden?!!! (Ich hoffe, ich bin auf der richtigen Seite für so ein Problem gelandet.) Gruß --Orik (Diskussion) 23:47, 4. Apr. 2020 (CEST)
Du bist auf einer durchaus zur Erörterung geeigneten Seite gelandet.
Der wikEd funktionierte wohl ein Jahrzehnt lang recht gut.
Dies unbeschadet durchaus kritikwürdiger und riskanter Programmierpraktiken; sowie der klaren Beschränkung auf eine spezielle Browser-Architektur. Ist aber bei einem Riesendingens wie diesem als ehrenamtliches Solo-Werk kaum zu vermeiden, zumal die Anfänge von wikEd in einem völlig anderen Zeitalter lagen und dies immer wieder deutlich modernisiert wurde.
Bekannt ist allerdings, dass der ein Jahrzehnt lang unermüdlich schuftende Entwickler in jüngerer Zeit wohl recht inaktiv war, insbesondere keine Anpassungen mehr vornahm.
Die dortigen Erörterungen in der englischsprachigen Wikipedia wären für unser weiteres Vorgehen maßgeblich; also Benutzer- bzw. Projektseiten.
Es ist jedem unserer Bearbeiter freigestellt, das Dings wieder wegzuhakeln, wenn es beim eigenen Browser nicht (mehr) korrekt funktioniert. Es ist keine Default-Option, die wir allen Benutzern aufzwingen würden.
Erst bei nachhaltiger unreparierter schädigender Funktion würden wir unser Gadget durch irgendeine Form von Fehlermeldungsbaustein ersetzen bzw. dahingehend ändern, da wir ohnehin nur nach einigen Vorbereitungen das englischsprachige Gadget laden.
Alle dort bisher verwendeten Benutzerkonfigurationen sollen verstanden werden.
Das Ergebnis soll bis auf Kleinigkeiten und Updates unverändert sein.
Konfiguration
Fundamentaler Unterschied: Die Spezifikation der Gruppenzugehörigkeit einzelner Benutzer soll nicht mehr in einem JavaScript-Code erfolgen, sondern per Wikitext im MediaWiki-Namensraum.
Damit kann wieder jeder Admin die Gruppenzugehörigkeit aktualisieren.
Wäre zur Konfiguratiion eine JSON-Seite nicht geeigneter? Das sollte deutlich einfacher zu parsen sein, kann (afaik) nicht korrput gespeichert werden, und kann perspektivisch per ResourceLoader in das Gadget geladen werden. --MGChecker – (📞| 📝| ) 20:11, 12. Jul. 2020 (CEST)
Das möchte ich aus mehreren Gründen bewusst nicht:
Eines Tages geht das harmlosere editsitejson auch noch flöten, und dann sind wir wieder bei den BOA, von denen ich grad weg will;
das Wikitable-Format ist für Non-Techies sehr viel intuitiver als JSON, und es ist auch robust gegen Syntaxfehler; dann hätte halt mal ein Eintrag keine Dekoration, aber der Rest funktioniert;
die Wikitable lässt sich sofort und auf low level darauf überprüfen, ob bei eingeschaltetem Gadget die Dekoration übereinstimmt mit den Angaben in der Spalte daneben;
die Wikitable erlaubt beliebige Kommentare, Standard-JSON null;
die Wikitable lässt sich unabhängig vom Gadget beliebig für Übersichten durch alle nutzen und rumsortieren;
statt einer MediaWiki:-Seite ließe sich, auch in anderen Projekten oder für andere Zwecke, genauso eine normale Projektseite verwenden. Könnte dann jetzt schon normale Projektseite unter Dreiviertel sein, aber die Administration der Administratoren organisieren die mal besser selbst unter sich. Im JSON-config steht übrigens noch kein Eintrag, wo die aktuelle Definition abgeholt werden kann.
Das Parsen einer solchen Wikitable ist in ein paar Zeilen gemacht und fällt gegenüber dem Gesamtaufwand nicht ins Gewicht. Wegen Performance passiert im Hintergrund sehr viel mehr (Caching einer “byte-compiled” aufbereiteten Version). Deshalb interessiert mich auch das Laden der Ressource nicht. Der Abruf vom Server ist der gleiche Aufwand, ob nun ein Seiteninhalt raw oder eine message.
Ich habe mir das auch mal angeschaut. Im Prinzip halte ich das für eine sinnvolle Idee. Die Definition per Wikitable ist erstmal ungewöhnlich, aber hat wie dargestellt auch Vorteile. Anwendbar wäre das 1:1 auch auf User:Anka Friedrich/markMentors.js, woraus sich meine Hauptfrage ergibt: bleibt eine benutzerspezifische Konfigurationsmöglichkeit erhalten? Ich nutze das Skript seit meiner Kontenmetamorphose nicht mehr, kann mich aber erinnern, dass einige gern auf die Exen-, Commons- oder Wikidata-Admin-Markierung verzichten wollten (genauso sind auch Mentoren nicht für jedermann von Belang) oder die Markierung lieber hochgestellt unfett etc pp. haben möchten. Das zweite könnte man per CSS und Klassenbezeichner regeln, das erste aber nicht. Und: bisher wurden die Markierungen immer innerhalb des Benutzerlinks eingefügt, also ohne Extraverweis zu Admins, BOAs, Stewards etc. Gruß, -- hgzh18:28, 13. Jul. 2020 (CEST)
TL;DR: Ja.
Man müsste sich nur mit einer race condition herumplagen, bzw. dürfte nicht gleichzeitig über Einstellungs-Häkchen das traditionelle markAdmins starten. Weil, wenn der dann startet, dann würde einmal geflöht, und wer zu spät kommt, den bestraft das Leben.
Es dürften jedoch beliebig oft Definitionen abgefeuert werden, die projekt-offizielle ist nur eine unter gleichberechtigten, und ein Objekt könnte auch statt einer wikitable oder JSON-Seite direkt gefeuert werden.
Wenn man sich sicher ist, dass alle gewünschten Definitionen in der Warteschlange stehen, dann müsste das markLinks zum Schluss geladen werden, und das futtert dann alle angesammelten Definitionen und arbeitet sie ab.
Die vorgesehene markAdmins-Nachfolge-Implementierung würde auch nichts anderes machen als Kompatibilitäts-Optionen zu generieren und abzufeuern, die amtlichen Definitionswünsche abzufeuern, und zum Schluss das ausführende Gadget zur Abarbeitung aufzufordern.
Sollte dann nur keine Konflikte um Buchstaben-Codes geben, oder Design oder sonstige Konfigurationen.
Ob eine Definition von einer Benutzer- oder Projektseite käme, aus MediaWiki: oder in JSON oder Wikitext oder implizit als Objekt mit abgefeuert wird ist völlig egal. Es käme jedoch ggf. auf die Reihenfolge an.
Das markMentors hatte ich vor Jahren mal gesehen und vielleicht implizit im Hinterkopf, aber jetzt dieser Tage nicht von dort vor Augen geholt. War jedoch grundsätzlich mitgemeint. Müsste dann wissen, ob es für diesen Anwender ein markMentors+Admins oder ein markMentors ohne Admins werden solle.
Zu Präsentationsfragen:
Das A ist in Simulation und JSON-Definition nicht mit einer Verlinkung unterlegt.
Bei Gebilden wie Omb, so mal angetroffen, halte ich eine erklärende Verlinkung nebst Tooltip jedoch für sehr sinnvoll. Was war jetzt nochmal dieses S wenn es nicht in SG drinsteht? Auch jemand, der mit den Sonderfunktionen nicht so vetraut wäre und nicht sowieso auswendig alle Admins alphabetisch aufsagen kann, kann ja das Gadget aktiviert haben, um zu wissen, wer ihm da gegenübertritt. Hier wird man seltenere unktionsträger nicht herunterbeten können.
Es ist auch alles konfigurierbar und muss auf jedes Wiki in jeder Schrift passen.
Grundsätzlich sehe ich mich nicht dazu verpflichtet, jedes Pixel auf ewig exakt auf dem Stand von 2008 zu konservieren und jede verbesserte Funktionalität konsequent abzublocken weil früher hatten wir das ja auch nicht gehabt.
Danke verbindlichst für diese Erläuterung an mich privat, aber das Gadget würde ja auch von weniger erfahrenen Benutzern eingebunden, die nicht alle diese Exoten und Codes sicher herunterleiern könnten. Auf der Simulation findest du das unmittelbar vor gell? mit Tooltip und verlinkt. VG --PerfektesChaos14:28, 14. Jul. 2020 (CEST)
Ich finde das sehr interessant. Schade, dass das hier anscheinend eingeschlafen ist. Wie sieht das in Sachen Serverbelastung aus (Cache)? Auch im Vergleich zum Skript und der – von mir zusätzlichen genutzten und anscheinend noch gar nicht erwähnten – Möglichkeit ggu? — Speravir– 00:22, 12. Feb. 2021 (CET)
ggu verwende ich selbst seit Jahren.
Was der Verweis auf den Server-Cache bedeuten soll, ist unklar. Er hat mit dem gesamten Themenkomplex absolut nichts zu tun.
ggu wertet die im System hinterlegten Informationen aus. Damit ist es per se ungeeignet für:
SG
Ex-
Mentoren
Nur theoretisch für Com-A, en-A, WD-A usw.
Dies bedingt dann jedoch, dass auch alle 1000 Admins der enWP in die CSS-Regel aufgenommen werden müssten, und alle Commons- und WD-Admins auch. Könnte man machen, wird aber etwas übersprudelnd.
Caching einer Wikiseite versus eines Skriptes versus eines extern abzurufenden Stylesheets. Caching verringert normalerweise die Serverbelastung, könnte ja sein, dass das auch eine Rolle für die Darstellungsgeschwindigkeit spielt (ggu brauch immer einen Moment). Durch das Caching kann es sein, dass jemand einen veralteten Stand angezeigt bekommt, worauf man kurz hinwiesen sollte (Hilfe:Cache gibt’s ja schon). Mir ging es um den Vergleich, wenn das egal ist, um so besser.
ggu habe ich nur als eine bereits existierende Teilalternative erwähnt, die mehr – nein, besser: – andere Markierungen erlaubt als markAdmins. Du hast aber Recht, dass sie für einiges, was dir an Sinnvollem vorschwebt, nicht geeignet ist. — Speravir– 22:40, 12. Feb. 2021 (CET)
„Caching einer Wikiseite“
Das hat aber völlig nullkommanullnullnullnull mit dieser gesamten Angelegenheit zu tun.
Im Cache des Wiki-Servers steht ein HTML-Schnipsel, nämlich der Inhaltsbereich, der aus dem Wikitext generiert wird. Bei Spezialseiten, wo auch sehr häufig Admins usw. zum Markieren auftauchen, gibt es überhaupt keinerlei Cache und der Inhaltsbereich wird spontan generiert. Dieser Inhaltsbereich wird im Moment der Anfrage in den je nach Benutzer und Namensraum unterschiedlichen Portalrahmen eingebettet.
Der Server liefert immer das gleiche HTML-Dokument aus und hat mit der Angelegenheit hier absolut nichts zu tun.
Alle Dekoration, sei es über JavaScript wie traditionell markAdmins oder hier neu vorgeschlagen markLinks oder aber per CSS mittels ggu passiert im Client; das ist der Browser des Lesers, und modelt nachträglich das vom Server ausgelieferte immer gleiche HTML-Dokument nur für diesen Leser um.
Die Ressourcen-Codes aller JavaScript oder CSS stehen sowieso im Browser-Cache des jeweiligen Lesers, werden ohnehin nicht jedes Mal neu übertragen, sondern die von der WMF stammenden Ressourcen werden nur kurz abgefragt ob die Version noch aktuell wäre; bei ggu passiert das einmal pro 24 Stunden.
„ggu brauch immer einen Moment“
Das liegt daran, dass bei Eintreffen von CSS-Regeln, sei es im Original-HTML-Dokument oder später wirksame Gadgets, jede Regel gegen alle Elemente im Dokument geprüft werden muss, und bei den zutreffenden dann die entsprechende Dekoration angewendet wird.
Mit je mehr CSS-Regeln man sich zukippt, desto länger dauert es bis alle Regeln für alle Elemente umgesetzt wurden.
Deshalb steht auch im allerersten Text-Abschnitt dieser Seite eine Epik, die darlegt, warum es Dummfug ist, über 20 Millionen Seiten Regeln auszukippen, die nur in 0,0001 % der Seiten wirksam sind und ansonsten ins Leere gehen.
„für einiges, was dir an Sinnvollem vorschwebt“
Das ist nicht das, was mir „an Sinnvollem vorschwebt“, sondern SG, Ex-, Com-A, en-A, WD-A usw. ist Kompatibilität zum bisherigen markAdmins, dessen Funktionalität vollumfänglich erhalten bleiben soll.
Na, wenn das Caching keine Rolle spielt, um so besser. Dass das Skript die Möglichkeit besitzt, war mir beim Schreiben auf die Schnelle nicht bewusst, obwohl SG ja sogar standardmäßig aktiv ist. Es bleibt aber: Schade, dass anscheinend niemand das hier mit Nachdruck weiterverfolgt hat (ich meine jetzt nicht dich) – wohl, weil es mit markAdmins vordergründig funktioniert und den Leuten die Einschränkungen hinter den Kulissen nicht so klar sind. Aber apropos: BOA kann markAdmins ja nicht markieren … — Speravir– 00:03, 15. Feb. 2021 (CET)
Vorschlag: Interne http:// - Links als externen Link behandeln
Mit der Commons.css wird verhindert, das interne Verlinkungen als externe Links gekennzeichnet werden. Meiner Meinung nach ergibt es Sinn die internen http:// Links, da diese "nicht sicherer" sind, auch zu kennzeichnen.
Die Zeilen "#mw-content-text a.external[href^="http://xxx.Wikiprojekt.org"]," sollten meiner Meinung entfernt werden. --𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫👤💬Rechte | Kenst du scho de boarische Wikipedia?13:32, 29. Aug. 2020 (CEST)
Nein, sehr viele Bearbeiter wissen nicht, wie sie Verlinkungen auf Seiten in Wiki-Projekten als Wikilink formatieren könnten, und geben sie als URL an, wenn es sich nicht um den einfachen Seitennamen der Clean URL handelt.
Damit das aber nicht andauernd als angebliche Nicht-Wiki-Verlinkung gekennzeichnet würde, stellen wir Ziele auf eine Wiki-Seite (bestimmter ausgewählter Projekte, insbesondere wir selbst) einheitlich als „intern“ dar.
Typische Beispiele:
URL-Difflink anstelle von Wikilink (ohnehin noch in unterschiedlichem Farbschema, jedoch ohne Icon).
@𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫: Richtig, wenn wir hier nicht schon seit Juli 2019 die MediaWiki-Erweiterung SecureLinkFixer hätten. Diese schreibt im Hintergrund jedes http auf https um, wenn die Webseite standardmäßig https verwendet. Und dies ist bei WMF-Seite auch schon länger der Fall. — RaymondDisk.19:40, 29. Aug. 2020 (CEST)
Ich denke nicht, denn die Änderung erfolgt nicht im Quellcode, sondern nur beim Rendern der Seite. ich muss aber zugeben, ich weiß nicht, on welcher Reihenfolge da im Hintergrund was passiert. Das könnte man sicherlich im Betawiki austesten. — RaymondDisk.10:01, 30. Aug. 2020 (CEST)
Beachte, dass ich http: geschrieben habe; die MediaWiki-Software erkennt wie korrekt von Raymond dargestellt ein eng befreundetes WMF-Projekt und schreibt das bereits im generierten und ausgelieferten HTML-Dokument auf https: um.
Die obere Verlinkung ist jedoch mit der class="external" gekennzeichnet, und diese bewirkt, dass ein der Verlinkung nachgestellt würde. Damit wären jedoch in unseren Artikeln auf für die Leser unbegreifliche Weise manche Links auf einen anderen unserer Artikel mit gekennzeichnet und die meisten nicht, und das würde nur verwirren. Deshalb unterdrücken wir dann mit dem von dir benannten CSS diesen Icon. Und deshalb ist das auch mitnichten überflüssig, nie gewesen, nie geworden und auch nicht zu entfernen.
Solltest du dich übrigens zur Verbesserung ohnehin bearbeiteter Artikel dafür interessieren, wo im ANR eine URL-Verlinkung statt Wikilink-Format benutzt wurde, könntest du in ähnlicher Weise derartige Verlinkungen für dich persönlich hervorheben, etwa durch einen bunten Rahmen um den Linktext.
Nebenbei bemerkt führt eine URL-Verlinkung nicht zu einer Aufnahme in die Spezial:Linkliste , wovon beim noping gelegentlich bewusst Gebrauch gemacht wird. Damit sind solche Artikel jedoch nicht mehr aktualisierbar, wenn bei Einrichtung von BKS oder sonstiger Aufteilung des Artikels alle bisherigen Verlinkungen gesucht werden. Aus diesem Grund sind URL-Links auf Artikel im ANR massiv unerwünscht.
Hallo, dank Wurgl gibt es eine Liste mit unbeschränkt gesperrten Benutzern, die eigene JS-Seiten (CSS wäre analog) in ihrem Benutzernamensraum haben. Da sie normalerweise keine Wirksamkeit mehr besitzen und auch nicht mehr von ihren Eigentümern gewartet werden können, schlage ich vor, solche Seiten zu löschen, sofern sie nirgendwo eingebunden sind und es sich nicht um Editcounter-Aktivierungsseiten a la EditCounterOptIn.js handelt. Die Vorteile lägen vor allem darin, möglicherweise veraltete Skripte, Skriptteile oder Funktionsverwendungen loszuwerden und deren Copy&Paste zu verhindern. Auf Phabricator laufen ja immer mal wieder Listen mit von Änderungen betroffenen Seiten auf, die so verkürzt werden könnten. Als zweiten Schritt könnte man diese Aktion noch auf seit langem inaktive Benutzer mit entsprechendem Hinweis auf Wiederherstellungsmöglichkeit ausweiten. Was denkt ihr? Gruß, -- hgzh12:07, 24. Nov. 2020 (CET)
Finde ich einen guten Vorschlag. Sollte in allen Fällen einen Standardlink auf eine Seite enthalten die beschreibt warum und wie man das wiederkriegen kann. Viele Grüße, Luke08151512:14, 24. Nov. 2020 (CET)
Ich würde die Seite einfach in der Löschbegründung verlinken. Das geht auf allen Seiten. z.B. "xy löscht Seite bla.js ([[Doku|Aufräumaktion Skripte gesperrter/inaktiver Benutzer]])" etc. Viele Grüße, Luke08151514:04, 24. Nov. 2020 (CET)
Grundsätzlich begrüße ich das in stufenweiser Umsetzung.
Zunächst mal dürfte sich innerhalb dewiki keine Einbindung durch andere, noch aktive Benutzer finden lassen. Was nicht ausschließt, dass es global irgendwo angefasst würde oder keine triviale auffindbare Zeichenkette verwendet wäre.
Begonnen werden sollte mit infinit gesperrten und verstorbenen (haben die nicht auch infinit?) Benutzern. Langjährig (5, 10 Jahre) inaktive könnten nach ersten Erfahrungen folgen.
Skripte aus der Zeit um 2010 sind heutzutage wegen zahlreicher Anpassungen an moderne Browsertechnologie und Konfliktvermeidung im globalen Namensraum der JS-Variablen nicht mehr lauffähig. Sie ziehen bei der mittlerweile möglichen globalen Protokollierung von Skriptfehlern (welche die Anwender selbst nicht mitbekommen, weil diese nur auf der Konsole und bei der WMF vermerkt werden) Wartungs- und Pflegebedarf nach sich.
CSS würde ich außen vor lassen, bis sich ein ernstzunehmendes Problem einstellt (globale Info der WMF, dass dieser und jene Selektor nicht mehr unterstützt würde).
Ich würde allerdings anders vorgehen:
Überschreiben der Seite mit einer neuesten Version, bestehend nur aus
window.alert("Du verwendest das Skript User:"+Bot-eingefügtAccount/subpage.js+"@dewiki. Dieses bedarf der Pflege."+" Bitte melde dich bei ...");// Eingefügt von Administrator ...... 2020-12-01// Wenn du dein Skript reaktivieren möchtest, brauchst du bloß ...
Wenn das irgendwo noch verwendet würde, müsste jemand aufschlagen.
Wenn keiner mault ist es erstmal egal.
Wenn ein User wiederaufersteht, hat er die Versionsgeschichte und kann schlicht revertieren.
Joa, diese Nachricht wäre dann möglich, wenn das Skript noch irgendwo eingebunden wird, ansonsten sieht es ja niemand. Gruß, -- hgzh19:47, 6. Dez. 2020 (CET)
Es wird inzwischen interessant, die BNR-Ressourcen von vor 2011 wie skizziert abzudecken.
MediaWiki-Entwickler gehen inzwischen dazu über, bei nachhaltig ungepflegtem JS wie diesem aus der Zeit vor 2011 global in allen Wikis die Ressourcen zwangsweise umzuschreiben. Irgendwie peinlich, dass dieses Wiki das nicht selbst auf die Kette bekommt.
Die Abschaffung der den globalen Namensraum verseuchenden Konfigurationsvariablen von vor 2011 steht offenbar unmittelbar bevor; nach zehn Jahren Migrationsperiode.
Ich habe jetzt mal einen Rutsch eindeutiger Fälle von unfreiwillig Gesperrten und Verstorbenen per Löschung bereinigt. Für alle weiteren müsste man nochmal überlegen – ein Hinweis wie oben würde ja bei jedem Laden der Seite erscheinen, da sehe ich schon Fackeln und Mistgabeln auf mich gerichtet. -- hgzh19:29, 13. Feb. 2021 (CET)
In diesem Fall stelle ich mich mit breiter Brust vor dich.
Eine Löschung ist ein heftigerer Eingriff, weil Wiederauferstandene ihn nicht beseitigen können.
Eine Seite nur mit Klartext-Kommentar und Bedienungsanleitung ist das mildere Mittel, erklärt nochmal was los ist, kann vom Account unbürokratisch revertiert und durch die VG gebraust werden, und wenn wer zurückkommt dann mag man auch auf FZW oder TWS sich erklären lassen was los ist.
Ich bin grad hundemüde, aber zu morgen kann ich dir ersatzweise zum window.alert() eine narrensichere console-nicht-console-warning-nicht-warning-dann-log aufschreiben, die für den Fall eines von weißdergeierwoher aufgerufenen Skriptes immerhin einen Hinweis in der Konsole hinterlässt. Die kein Normalbenutzer zur Kenntnis nimmt, aber wenn es kein alert() sein soll bliebe nur diese ulkige mw.notification, mit der ich aber auch noch nie gearbeitet habe und die ich morgen nachmittag erstmal auf BETA ausprobieren müsste.
Würde heißen: Dauerhafter Konsoleneintrag und 5 Sekunden Einblendung, falls es noch Anwender geben sollte.
Irgendetwas nicht so aufdringliches wäre mir schon lieber. Ich lasse gerade die Query mit aktuellem Stand durchlaufen und rasiere dann nochmal die eindeutigen Fälle runter, anschließend könnte man dann die Seiten der freiwillig Gesperrten entsprechend mit einem Hinweis ausstatten. Ich denke auch über eine Wartungskategorie für solche Seiten nach, etwa Kategorie:Benutzer:Skriptseite deaktiviert, zum Ausklammern bereits besuchter Seiten bei späteren Iterationen.
Diese Wikitext-Weiterleitungen wären gaga, das muss was mit mw.loader.load() sein (sie tauchen allerdings als verlinkte Seiten auf).
Bin am Wochenende durch zwei frische dicke Hunde auf meiner ToDo-Liste und in meinen geistig wachen Stunden gestört worden. Es werden jeden Tag mehr neue Initiativen gestartet als ich Rückstände abarbeiten kann. Inzwischen nachgeforscht:
//////////////////////////////////////////////////////// Dieses Skript wurde wegen Überalterung deaktiviert.// Eingefügt von Administrator ...... 2021-03-18// Wenn du dein Skript reaktivieren möchtest, brauchst du bloß ...//////////////////////////////////////////////////////(function(mw){"use strict";vars="################ Account/subpage.js ##############";s="Du verwendest das Skript User:"+s+"@dewiki.\n"+" Dieses bedarf der Pflege.\n"+" Bitte melde dich bei: w:de:WP:FZW";if(typeofwindow.console==="object"&&window.console){if(typeofwindow.console.warn==="function"){window.console.warn(s);}elseif(typeofwindow.console.log==="function"){window.console.log(s);}}if(typeofmw==="object"&&mw&&typeofmw.notify==="function"){mw.notify(s,{autoHide:false});}}(window.mediaWiki));// [[Kategorie:Benutzer:Ressourcenseite deaktiviert]]
Danke, ich werde das die Tage testen und dann mal beginnen. Das s kommt mir doppelt genutzt vor? Übrigens zum Thema ein kürzlicher Blogpost: Sailing Steady - How you can help keep Wikimedia sites Error-free, unter anderem mit der Empfehlung: User scripts should expire after a certain period and when users retire and no longer maintain them. If a user script hasn’t been edited in over 5 years for example, a bot should blank the page. Gruß, hgzh11:33, 17. Mär. 2021 (CET)
Die erste Zuweisung var s = "Account/subpage.js"; ist die einzig variable Stelle im ansonsten konstanten Text einer Serie und ist dafür gedacht, das vielleicht irgendwie halbautomatisch ausfüllen zu können.
Die zweite Zuweisung s = "Du verwendest das Skript User:"+ s +"@dewiki.\n" bettet die erste, variable Zuweisung in einen konstanten Rumpf ein. Der wird dann relativ narrensicher kommuniziert.
Die Verlinkung ist irgendwie putt. Da sind gemäß englischer Typografie hair space um den en-dash gelegt. Das heißt, wenn es denn ein en-dash wäre, ist aber ASCII U+002D.
Der Interwiki-Link löst aber gemäß Standard-Algorithmus hair space wie alle anderen Leerzeichen in _ auf.
Die Seite ist aber nur mit zwei U+200A erreichbar.
Die dümmlichste Idee, die mir in den letzten Wochen unterkam, war die Benennung eines Blogs als „Diff“.
Die zitierte Empfehlung ist nur halbgar.
Es gibt relativ schlichte Skripte, die funktionieren auch noch nach zehn und fünfzehn Jahren ohne Maintainer.
Kritisch war die Wende im globalen Namensraum um 2010, und die Einführung des mw-Objekts. Was älter ist, braucht Anpassung zur Migration der wikibits-Ära 2004–2010.
Je komplexer, je mehr Screengrabbing, desto wahrscheinlicher wird Wartungs- und Anpassungsbedarf.
a bot should blank the page – auf blank the page läuft das da oben hinaus, nur luxuriöser.
Ist aber sowieso nur als private Einzelmeinung zu werten.
Die Bug-Auswertungsmöglichkeiten muss ich mir mal genauer anschauen.
Als allgemeine Empfehlungen alles ganz okay, aber Anweisungen zum Eingriff in den BNR sind ein anderes Kaliber.
Bzgl. s hast du Recht, da hab ich schief geguckt. Den Link muss ich mir morgen nochmal ausgeschlafen anschauen. Gruß, -- hgzh21:23, 17. Mär. 2021 (CET)
Ich bin gegen die Löschung von js/css-Seiten freiwillig gesperrter Benutzer. Eine Sperrung hindert ja nicht daran, sich einzuloggen! Im Zweifel den Benutzer vorher auf seiner Disk ansprechen und hinreichend Zeit zur Reaktion geben. 84.137.67.24122:15, 18. Mär. 2021 (CET)
Die Seiten sollen auch nicht gelöscht, sondern überschrieben werden, sodass sie sich bei Bedarf leicht zurücksetzen lassen. hgzh12:58, 19. Mär. 2021 (CET)
zu vermeiden, sollte:
) 16:46, 9. Jul. 2020 (CEST)
21:42, 1. Mär. 2020 (CET)
Icon).