Wikipedia Diskussion:Dateiwartung/Werkzeug/Programmierung

Hier tauschen sich Entwickler und Anwender im technischen Detail über das Werkzeug aus. Es ist jede Frage erlaubt, jeder Wunsch, jede Utopie; es mag von völliger Ahnungslosigkeit zeugen und grauenhafter Unsinn sein.

Abgearbeitete, erledigte und restlos geklärte Fragen sind auf /Archiv abgelegt, um den Überblick zu behalten.

Vorgeburtliches

Browser-Tabs und Fenster

Das Skript arbeitet mit drei Fenstern/Browser-Tabs, von denen es sich das zweite und dritte selbst aufmacht.

Begonnen wird auf der Seite Kategorie:Datei:Beschreibung.

Browser-Tabs

	(Start)	fileSingle	fileTools
Beobachtungsliste	Kategorie:Datei:Paris {{Dateikategorie}} Datei:Eiffelturm.svg Datei:MonaLisa.jpg Datei:NotreDame.png	Datei:MonaLisa.jpg	toolserver.org/~ Datei:MonaLisa.jpg Datei:NotreDame.png	Skin/Werkstatt

• Die erste Seite (Dateikategorie) erhält die 4 Links auf das Tool, die bisher auf dem weißen Dingsda rechts oben stehen.
• Die 4 Tool-Links stehen bei den Portal-Buttons (Vector: ▼) sonst links bei Werkzeuge vor „Links auf diese Seite“.
• Ein 5. Link kommt hinzu: Ein/Ausschalten des „Prüfer-Modus“.
• Wenn auf der ersten Seite (Dateikategorie) eine Einzeldatei angeklickt wird, wird diese im folgenden Browser-Tab bzw. neuem Fenster geöffnet.
  • Welches von beiden, Tab oder Fenster: ist persönliche Browser-Einstellung, nicht beeinflussbar.
• Jeder weitere Klick in der Dateikategorie-Seite auf eine Einzeldatei benutzt immer wieder dasselbe Einzeldatei-Tab/Fenster.
• Wenn auf der ersten Seite (Dateikategorie) ein Tool-Link angeklickt wird, wird das im nächstfolgenden Browser-Tab bzw. neuem Fenster geöffnet und dort das Tool-Ergebnis dargestellt.
• Jeder weitere Klick in der Dateikategorie-Seite auf ein Tool-Link benutzt immer wieder dasselbe Tool-Ergebnis-Tab/Fenster.
• Wenn auf der Seite mit dem Tool-Ergebnis auf eine Einzeldatei geklickt wird, wird die Einzeldatei in wieder demselben Einzeldatei-Tab/Fenster geöffnet, wie es auch schon von der Dateikategorie aus benutzt wurde. (bedarf jeweils vorher eines kleinen Extra-Kunstgriffs).

Einwände? --PerfektesChaos 21:17, 22. Jul. 2011 (CEST)

Puh, ich mir deinen Vorschlag zwar so halb vorstellen, bin aber nicht sicher, ob es der gesuchte Aufbau/Ablauf ist. Ich schildere mal, wie der Ablauf bisher bei vielen Benutzern ist:

• Eine Dateiliste wird angeschaut. Beispiele sind Wikipedia:WikiProjekt Dateikategorisierung/Kategorie:!Hauptkategorie, Wikipedia:Redaktion Biologie/Wartungsseite lokale Bilder oder Spezial:Neue Dateien.
• Falls bei einer Datei nicht alles OK ist → {{DÜP}}
• Falls alles OK ist und die Datei nicht commonsfähig ist → {{Geprüfte Datei}} + Dateikategorie(n) (Nicht-„Dateiprüfer“ führen nur die Dateikategorisierung durch)
• Falls alles OK ist und die Datei commonsfähig ist → Datei nach Commons transferieren (WP:CTB ist nur eine Variante)

Je nachdem müssen für die Kategorisierung von nicht commonsfähigen Dateien Dateikategorien neu angelegt werden. --Leyo 23:14, 22. Jul. 2011 (CEST)

Merkzettel

Browser-Tab: Datei:Einzeldatei.jpg

• Kommt zu einem späteren Zeitpunkt im Detail.
• Auswahlmenü für das Einfügen von Lizenzvorlagen usw. für Bildrechte

Vorlagen anpassen

{{Dateikategorie}}

+ <div id="Dateikategorie">

--PerfektesChaos 18:47, 13. Aug. 2011 (CEST)

Und zugleich dies rückgängig machen, oder? --Leyo 00:18, 17. Aug. 2011 (CEST)

Zugleich nicht, aber perspektivisch kann das zunächst unsichtbar belassen und nach allgemeiner Einführung des Universalwerkzeugs auch aus der Vorlage entfernt werden. Deshalb auch der davon unabhängige Identifizierer. --PerfektesChaos 11:07, 17. Aug. 2011 (CEST)

Vierter Prototyp

Was gibt es Neues?

• Die Kinderkrankheiten mit doppelten Klammern usw. sind jetzt hoffentlich ausgestanden. Ich finde keine Macken mehr; du möglichst auch nicht.
• Es reagiert jetzt auf die Original-Vorlage {{Geprüfte Datei}} und mag von dir probeweise produktiv eingesetzt werden.
• Der seltsam erscheinende BK „kosmetische Änderungen“ ist jetzt unempfindlich für Whitespace am Ende der Seite.
• Betreffend der Frage, ob Einzeldateien von einer Steuer-Seite aus in einem neuen oder demselben Fenster dargestellt werden sollen: Es gibt jetzt ein Umschalt-Link dazu, mit dem sich jeder spontan den Lieblings-Modus jederzeit einstellen kann. Die Einstellung gilt für die gesamte Sitzung (vielleicht irgendwann für die kommende Woche) für jede weitere Steuer-Seite.
• Wenn du eine Vorlage:Dateiwartungsseite kreierst, gilt das Konzept der Steuer-Seite auch für andere als Kategorien.
• Stellt sich die Frage, was als Nächstes angegangen werden soll, DÜB oder CTB?
  1. Ist TUSC noch aktuell bei Euch? Oder machen das alles Bots? Ich könnte mir vorstellen, ein Werkzeug-Link zu generieren, das genau dann erscheint, wenn nichts gegen CTB spricht (keine DÜP, geeignete Lizenz) und Username sowie TUSC-Passwort enthält. Letztere würde ich ziemlich dauerhaft in einem Cookie speichern.
  2. Was als Commonsfähig gilt, erhält Link für Vorlagen-Einfügung zum Commons-Transfer per Bot durch Admin oder spezifische Benutzer, auch unter anderem Namen?
  3. DÜP mit mehreren Parametern einfügen?

Blut geleckt --PerfektesChaos 21:25, 21. Aug. 2011 (CEST)

• Aw Vorlage:Dateiwartungsseite: War im 4. Prototyp irrtümlich noch nicht freigeschaltet; aber keine Sorge, in meiner Entwicklerversion ist das bereits aktiv, im nächsten Prototyp dann auch.
• fileAdmin_miniatur = true; in meine common.js eingefügt, aber die Wirkung blieb aus. – Der vorangegangenen Disk entnehme ich, dass du false begehrst. Die Doku ist ja noch nicht geschrieben; die Aktivität heißt mit vollständigem Namen: „Blende Miniaturbilder aus“ und ist damit (dich möglicherweise irritierend) das Gegenteil der Sichtbarkeit. false heißt jedoch immer: Mache garnix.
• Auskommentierte Frage weiter offen: blau unterlegt mit blauem Rahmen = Commons-Transfer aktiv; heißt das Vorlage:Nach Commons verschieben (bestätigt) oder auch Vorlage:Nach Commons verschieben (Bestätigung nötig)? Mittlerweile tendiere ich zu blauer Unterlegung für „(bestätigt)“ und gelb bei „(Bestätigung nötig)“.
• Aktuell offen ist die Frage: Was ist mit diesen TUSC? Benutzt die jemand; hilft die Versorgung mit Name@Commons und einer lokalen Speicherung des Passworts?

Beste Grüße --PerfektesChaos 09:52, 25. Aug. 2011 (CEST)

• Ich habe true durch false ersetzt. Jetzt passt's.
• Eine Unterscheidung ist sinnvoll, gibt aber eine weitere Kombination, die man sich merken sollte. :-)
• Ich benutze eigentlich praktisch nur den Bot oder das Bookmarklet. Für mich ist es daher nicht notwendig.
• Fürs DÜP-Setzen funktioniert Benutzer:Ireas/düp-setzen-monobook.js eigentlich gut. Aber falls du Verbesserungspotential siehst…
• Diese Idee könnte ggf. umgesetzt werden, aber hat keine hohe Priorität.

--Leyo 15:41, 25. Aug. 2011 (CEST)

• TUSC bleibt zurückgestellt; ist aber in die Architektur eingepreist. Wenn sich Bedarf zeigt, kann dies ausgebaut werden.
• Alle Uploads eines Benutzers transferieren – klingt machbar, falls ich es zu Ende verstanden habe. Es soll eine weitere Spalte oder ähnlich in Spezial:Dateien/Yesuitus2001 angefügt werden, die ein Häkchen bekommt: „Mache CTB damit“. Und die Links auf die Dateien sollen bunt bemalt werden, damit man sieht, wie ihr Status ist? Und die Möglichkeit zum Häkchen-Setzen haben nur die Commons-fähigen? Und zum Schluss ein Knopf „Alle Dateien mit Häkchen auf einen Schlag mit CTB-Vorlage versehen“? – Allgemein muss ich mich erstmal mit dem Spezial-Namensraum und den Spezial:Dateien auseinandersetzen; da war ich noch nie zugange. Klingt aufregend.
• Das DÜP-Skript sieht schon recht manierlich aus; nur mag ich keine Dingsdas, die über der Seite schweben und irgendwas verdecken. Und vielleicht fällt mir noch eine Verfeinerung ein; Kleinigkeiten wüsste ich schon. Die Grundstruktur ist identisch mit Review und CTB und bekommt nur andere Texte.

Beim Tüfteln --PerfektesChaos 17:24, 25. Aug. 2011 (CEST)

Betreffend des 2. Punkts: Ja, so habe ich mir's gedacht. Die Anzahl der Versionen wäre hilfreich, um auf einen Blick zu sehen, ob die Datei(beschreibungsseite) nach dem Upload noch geändert wurde. Das Einfügen oder Ändern von Lizenzbausteinen durch Dritte beispielsweise würde so mehr auffallen. --Leyo 17:45, 25. Aug. 2011 (CEST)

Sechster Prototyp

Eigentlich wollte ich erst nach Umstellung auf MW 1.18 am 5. Oktober hier weiter programmieren, aber nun habe ich doch schon an DÜP etwas weiter geschraubt.

• DÜP
  • Wenn schon eine DÜP in der Beschreibungsseite vorhanden ist, wird sie ausgelesen und ihre Parameter in Formular-Häkchen umgesetzt. Durch Hinzufügen oder Entfernen von Häkchen können Parameter noch umgewurstelt werden.
  • Falls der Uploader bereits benachrichtigt wurde, steht ja nicht mehr die DÜP-Vorlage in der Beschreibungsseite. Das Skript ist bereits darauf vorbereitet, bei diesen Kategorien (Dateiüberprüfung/Informationsmängel) die Formular-Häkchen zu setzen und diese Felder zu deaktivieren (auszugrauen). Das ist aber noch nicht umgesetzt.
  • Der Edit-Vorgang ohne DÜP-Anforderung berücksichtigt möglicherweise noch nicht bei jedem Schritt den aktuellen Zustand der DÜP-Vorlage; hier habe ich noch nicht getestet.
• CTB mit Eintragung auf /Anfragen soll es weiterhin erst mit dem neuen Edittoken unter MW 1.18 geben; dies werde ich an diesem Beispiel erproben.
• Steuer-Seite: Bot-generierte Eintragungen haben noch nicht das geeignete WMF-Format und müssten noch angepasst werden.

--PerfektesChaos 18:56, 29. Sep. 2011 (CEST)

• Mit Übernahme dieser Änderungen sollte das Feature "deaktivierte Formular-Häkchen nach Benachrichtigung" wirksam werden. --PerfektesChaos 20:39, 29. Sep. 2011 (CEST)

Übernommen.

Die DÜP-Setzung sollte eigentlich immer zur Verfügung stehen. Es ist nicht möglich, automatisch anhand der Dateibeschreibungsseite zu erkennen, es alles OK ist oder nicht. Ausnahme ist eigentlich nur der Fall, wo die DÜP-Vorlage bereits eingetragen wurde (egal ob von BLUbot schon geändert oder nicht). Allerdings wäre es bei {{Dateiüberprüfung}} ohne Parameter praktisch, wenn diese einfach nachgetragen werden könnten.

--Leyo 14:51, 1. Okt. 2011 (CEST)

Vielleicht ein Missverständnis? Browser-Cache gelöscht? Skript von Ireas am Wickel? – Da ich sowieso eine Bedienungsanleitung für die DÜP-Funktionen schreiben müsste, werde ich das hier irgendwo als Vorabversion tun. Das neue Skript müsste sich ganz anders verhalten. --PerfektesChaos 21:03, 1. Okt. 2011 (CEST)

Bot-Ausgabeformat und Steuer-Seite

Das Ausgabeformat der Bots müsste an die Steuerseite angepasst werden.

• Bisher bestand dazu keinerlei Notwendigkeit. Ein Bot konnte in irgendeinem Format schreiben. Niemand ist irgendein Vorwurf zu machen.
• Es können vom Werkzeug nicht unbegrenzt viele Formatvarianten unterstützt werden; nur die Formate werden beachtet, die auch von WMF benutzt werden.

Musterformat

Zwei Eigenschaften der Bilddateien erwartet das Werkzeug auf einer Steuer-Seite:

1. Der Name der Datei ist verlinkt.
2. Ein Bild ist als <img> eingebunden und hat thumb als Klasse.

Außerdem ist es möglich, auch das <img> in eine zusätzliche Verlinkung einzubeziehen. Dies muss jedoch vor dem verlinkten Dateinamen erfolgen.

Das Skript geht wie folgt vor:

1. Zum Ein- und Ausblenden der Miniaturbilder werden die IMG.thumb mit einem entsprechenden style versehen bzw. dieser wieder entfernt.
2. Zur Anzeige des Datei-Status werden alle document.links durchgegangen. Dabei werden URL mit wiki/Datei: ausgefiltert. Folgen zwei derartige Links auf dieselbe Datei unmittelbar aufeinander, wird unterstellt, dass das erste Link zum Bild gehört, das zweite zum Namen. Das Link mit dem Dateinamen wird mit dem style des Datei-Status versehen.

Alle Angaben zum Layout werden völlig ignoriert. Es mag <li> oder <td> oder was immer benutzt werden.

Damit ergibt sich folgende Grundstruktur als Musterlösung:

<a href=wiki/Datei:Muster.jpg><img src=wiki/Datei:Muster.jpg /></a><br />
<a href=wiki/Datei:Muster.jpg>Muster.jpg</a>

Etwa: Kategorie:Datei:Chemie

Im September 2011 gibt es beispielsweise auf folgenden Seiten ein Formatproblem:

• Wikipedia:Redaktion Biologie/Wartungsseite lokale Bilder
  • Hier mache ich zwar die Farbmarkierung, aber es ist nur das Bild verlinkt und nicht der Dateiname.
  • Kein class="thumb"
• Wikipedia:WikiProjekt Dateikategorisierung/Kategorie:!Hauptkategorie
  • IMG hat src=//upload.wikimedia.org/
    • kein wiki/Datei:
    • kein class="thumb"
  • Dateiname ist nicht vorhanden, schon gar nicht verlinkt.

--PerfektesChaos 23:20, 29. Sep. 2011 (CEST)

gallery

Könnte nicht gallery zusätzlich unterstützt werden? --Leyo 14:53, 1. Okt. 2011 (CEST)

gallery wird bereits jetzt unterstützt – mindestens was die Steuer-Seite angeht; da gallery auch thumb kennt, müsste auch das Ausblenden der Minibilder bereits jetzt funktionieren.

Zurzeit scheinen die Bots HTML direkt als Quelltext in die Seite einzufügen. Es würde auch gehen:

     <gallery>
     Muster.jpg | [[:Datei:Muster.jpg]]
     </gallery>

In der Bildunterschrift darf daneben auch beliebig viel anderes herumstehen. Das Skript bekommt überhaupt nicht mit, ob die Links und Bildchen durch gallery oder sonstwie generiert wurden; es sieht nur die fertige HTML-Seite. --PerfektesChaos 21:03, 1. Okt. 2011 (CEST)

Anregungen

• Wikipedia:WikiProjekt Dateikategorisierung/Werkzeug/Optionen will bei mir nicht richtig funktionieren. Ich möchte die Miniaturbilder standardmässig angezeigt bekommen und die Dateibeschreibungsseiten im selben Tab öffnen. Die bei den Optionen gewählten Standards werden nicht zuverlässig übernommen (Beispiel: Kategorie:Datei:JetztSVG).
• Beim Kategorisieren und Prüfen von Dateien verwende ich normalerweise HotCat zuerst und füge dann die Prüf-Vorlage ein. Aktuell ist das mit dem Werkzeug nicht möglich, da die Kategorien wieder rausfliegen.
• Betreffend automatisches Einfügen der Vorlage:Information: Um das Rad nicht neu zu erfinden, könnte Benutzer:Akkakk/autoInformation.js verwendet werden.

--Leyo 15:04, 1. Okt. 2011 (CEST)

1. Optionen
   Hm, bei mir irgendwie schon?
   Prüfe ich nochmal; genieße dein Wochenende und sei ein paar Tage sporadisch online, danach schauen wir weiter.
2. HotCat war bislang nicht im Gespräch. Ich selbst arbeite nicht damit, habe keinerlei Erfahrung. Ich kann mir aber gut vorstellen, dass HotCat gern am aus der DB entnommenen Text Kategorien löscht oder einfügt und das dann in das Textfeld schreibt. Da ich das Gleiche mache, bekomme ich HotCat wohl nicht mit; sobald ich herausgefunden habe, wann und wie HotCat seine Veränderung macht, kann ich ihm entweder den Vortritt lassen oder seinen Edit einfangen und bei mir einbauen.
   • Möglicherweise reicht es aber schon, wenn für den Fall ns===6 (Datei) eingefügt wird:

     hotcat_no_autocommit = 1;

     Das könnte der anwendende Benutzer machen, ich aber auch.

   • Aus der Bedienungsanleitung habe ich das aber noch nicht restlos verstanden; wenn beim Betrachten einer Seite „okay“ gedrückt und dies dann gespeichert wird, bekäme das fileAdmin-Skript schon den geänderten Seiteninhalt.
3. Ich lese deine Beo mit und beziehe daher Anregungen … das genannte Skript kann man mit Sicherheit nicht in die Infrastruktur integrieren, sehr wohl aber diejenigen Aktivitäten, die man benötigt. Ich habe verstanden:
   • Wenn fremdsprachliche Schlüsselwörter für aus anderen Projekten kopierte Dateibeschreibungsseiten zu ersetzen sind, kann ich das tun. Allerdings läuft das bei mir etwas anders.
   • Wenn Vorlage Info noch nicht vorhanden, soll sie leer eingefügt werden. – Kleinigkeit.
   • Leere Felder einer Vorlage Information kann ich immer aus dem Gesamttext der Dateibeschreibungsseite füllen, indem ich die Expertise von Akkakk aus doAutoInformation() in eine entsprechende Funktion übernehme; ich gehe davon aus, dass er der einzige Autor von „var i_b“ bis „Roland Nonnenmacher“ ist.
   • „AutoInformation“ heißt dann allerdings auch Auto-Information – solange leere Felder in Vorlage Information vorhanden sind und unformatiertes Geplapper auf der Dateibeschreibungsseite zu finden ist, wird das auch zum Ausfüllen der Vorlage benutzt. Löschen werde ich nichts; die Entscheidung, was wegkann und was nicht, ist individuell vom Menschen zu treffen.
   • Weiter denke ich über ein zusätzliches Feature nach Art eines Plug-In nach; einiges an diesem Skript („Klaus Graf“, „Roland Nonnenmacher“, „Roland Wellenhöfer“) kommt mir sehr speziell vor.

--PerfektesChaos 22:05, 1. Okt. 2011 (CEST)

fileAdm und HotCat

Ich kann nicht erkennen, dass das Skript fileAdm irgendwas am Zusammenwirken mit HotCat verändert; das Problem träte so oder so auf.

• Nachdem bei HotCat Verändern [Okay] ausgelöst wurde, läuft über einige Sekunden die Seitenveränderung per API.
• Wenn innerhalb dieser Laufzeit das normale [Bearbeiten] oder ein Knopf des Skriptes ausgelöst wird, greift das auf die alte, unveränderte Version zu; später müsste es einen Bearbeitungskonflikt geben.
• Das hat aber nichts mit fileAdm zu tun.

Abhilfe

• Je nach regionalem Grundrhythmus bis zehn oder bis fünf zählen, danach den jeweiligen Knopf drücken.
  Dann basiert der Edit auf der aktuellen Version auf dem Server.

Keine Hilfe ist:

• if (ns===6) hotcat_no_autocommit = 1;
  Dies würde bewirken, dass nach dem Edit die normale Edit-Funktion aufgerufen wird; allerdings nicht ein modifizierter Aufruf "Editiere und füge dabei diese und jene Vorlage ein".

Veränderung international

• commons:MediaWiki:Gadget-HotCat.js verwendet window.setTimeout – davon wird im Sommer 2011 berichtet, dass dies bei Abspaltung von Kindprozessen (wie bei Firefox 4, 5, 3.20 erfolgend) zu Problemen führt.
• Nachdem HotCat per API die Seite geändert hat, sollte ein Event geworfen werden oder eine benutzerdefinierbare Callback-Funktion vorgesehen werden, die anzeigt, dass das Ändern der Seite abgeschlossen wurde. Dann könnte das fileAdm darauf angemessen reagieren und die Seite ggf. neu laden. fileAdm kann bereits heute sehen, dass HotCat aktiv ist; wohl auch, dass eine Veränderung durch HotCat gestartet wurde; nur HotCat kann aber signalisieren, dass diese Veränderung erfolgreich abgeschlossen wurde.

--PerfektesChaos 10:32, 2. Okt. 2011 (CEST)

DÜP – Vorgriff auf die Bedienungsanleitung

Das Nachstehende soll später in die Bedienungsanleitung einfließen. Es beschreibt die Funktion September 2011; benachrichtigte sind bislang nur teilweise umgesetzt, folgen Mitte Oktober.

• Auf allen aktuellen Versionen der Dateibeschreibungsseiten steht in den Werkzeug-Links ein [DÜP] zur Verfügung, mit Ausnahme dreier Fälle:
  1. Es ist schon Vorlage DÜP (Mitte Oktober: oder DÜP/benachrichtigt) eingebunden.
  2. Es liegt NowCommons vor – dann ist es sinnfrei, im lokalen Projekt noch DÜP zu diskutieren.
  3. Die Dateibeschreibung wird von Commons eingebunden; dann müsste dort diskutiert werden.
• Was auf Commons (Fall 2 und 3) geschehen soll, wäre noch zu spezifizieren.
• Wenn Vorlage DÜP (oder DÜP/benachrichtigt) bereits eingebunden ist, wird das Fomular immer schon angezeigt; sonst wird das Fomular durch [DÜP]-Klick eingefügt.
• Das Hinzufügen von DÜP geht allen anderen Formularen vor. DÜP unterbricht einen laufenden CTB-Prozess.
• Die Parameter einer bereits vorhandenen Vorlage DÜP werden ausgelesen und als Vorgabe-Häkchen in das Formular eingetragen.
• Die Häkchen im Formular können entfernt oder hinzugefügt werden. Wird dann Bearbeiten oder Übernehmen ausgeführt, werden genau diese Parameter in die Vorlage geschrieben. (Stand schon „Urheber“ in der Vorlage, wurde aber das Urheber-Häkchen entfernt, dann wird aus der Vorlageneinbindung der Parameter „Urheber“ entfernt.)
• Die Parameter einer vorhandenen Vorlage DÜP/benachrichtigt werden ausgelesen und als deaktivierte Häkchen in das Formular eingetragen, also meist grau unterlegt und unveränderlich. In die einfache Vorlage DÜP kann dieser Parameter nicht mehr eingetragen werden, weil der Uploader bereits benachrichtigt wurde.

So in etwa sollte es zumindest funktionieren; machte es bei mir. --PerfektesChaos 10:56, 2. Okt. 2011 (CEST)

Die Ausnahme 2 würde ich weglassen: Es gibt immer wieder Fälle, wo ein Bild, bei dem (noch) nicht alles in Ordnung ist, nach Commons transferiert wurde. Es kommt auch vor, dass ein Benutzer eine Datei an beiden Orten hochlädt. Beim Entdecken wird da der DÜP-Baustein eingefügt. Bei Commons wird je nach Situation gleichzeitig ein Deletion Request gestartet. --Leyo 00:24, 3. Okt. 2011 (CEST)

• Du musst dich nicht jedes Mal entschuldigen, wenn du gerade nur kurz antworten kannst oder es ein paar Tage gedauert hat. Wir hangeln uns in aller Ruhe durch den Dschungel, und ich hänge auch nicht Tag und Nacht auf der Beo, um zu sehen, wann ich endlich wieder fileAdm weiter programmieren könnte. In diesen Tagen ist mit https und MW1.18 allerlei Umstellungsaufwand zu erwarten, und vermutlich wird deshalb ein großer Schritt vorwärts bei fileAdm erst am kommenden Wochenede erfolgen.
• Die Ausnahmebedingung "2" habe ich soeben aus dem Quellcode gestrichen; je weniger Ausnahmen, desto einfacher. NowCommons hatte ich bisher als eine Art SLA aufgefasst, aber wenn dem nicht so ist – ich habe eh’ keine Ahnung von den Abläufen.
• Bei der Formular-Sichtbarkeit hatte ich bisher einen kleinen Denkfehler, der mir beim Testen entgangen war: Wenn die DÜP-Vorlage bisher nicht in der Dateibeschreibungsseite stand, sondern soeben erst eingefügt werden soll, dann war sie in dem Moment noch nicht zu finden, als über die Anzeige des DÜP-Formulars entschieden wurde. Dies habe ich inzwischen grundsätzlich anders gelöst.
• Gestern Abend hatte ich auch die /benachrichtigt eingearbeitet und dazu die Logik deutlich umgestellt; bisher wurden nur unbenachrichtigte DÜP-Vorlagen wahrgenommen. Das muss ich jetzt aber selbst mal durchspielen; eine Zwischenversion vielleicht heute Mittag oder abends als 0.62.
• Frühestens am Wochenende 0.7 als Siebenter Prototyp, mit CTB/Anfragen unter MW 1.18 und neuem Zugriff auf edittoken.

Einen sonnigen Tag, gern auch ohne Wikis --PerfektesChaos 09:57, 3. Okt. 2011 (CEST)

Siebter Prototyp

0.7 live.

• Alles, was mir einfiel, habe ich mit meinen Testdaten ausprobiert. Dir fällt aber sicher wieder eine andere Konfiguration und Aktionsfolge ein, bei der irgendwas muckt. Hinzu kommt, dass ich mit allerlei Testseiten und Vorlagen das RealLife nur simuliere und die richtigen Aktionen nie gesehen hatte. Kleine Böckchen sind also wie immer nicht auszuschließen; bitte möglichst genau die Aktivitäten beschreiben, die einen Fehler ausgelöst hätten: Manuell editiert oder API? difflinks!
• „Ich möchte die Miniaturbilder standardmässig angezeigt bekommen“ – wessen Zitat, sieht man am „ss“. Das wäre „Nicht Ausblenden“ und in deiner common.js ist fileAdmin_miniatur = false; der richtige Startwert für die Sitzung. Allerdings merkt sich das Teufelszeug die zuletzt in dieser Sitzung vorgenommene Einstellung. Auf der Optionsseite wäre das zu ändern in „Jede Seite neu“.
• Als nächstes werde ich mit dem Schreiben der Bedienungsanleitung beginnen; dort stünde dann, wie es funktionieren müsste.

Viel Spaß --PerfektesChaos 20:49, 14. Okt. 2011 (CEST)

• Bei mir sind seit dem Update die Beschriftungen teilweise auf Englisch. Ich vermute, dass du's konfiguriert hast, dass man bei UI-Sprache ≠ de die engl. Version kriegt. Bei de-at und de-ch wäre auch Deutsch sinnvoller. de-formal, nds oder als haben wohl nur ganz wenige Benutzer ausgewählt.
• Gibt es auch eine Standardeinstellung, um die Dateibeschreibungsseiten im selben Tab zu öffnen? Dass man umschalten kann, finde ich aber für einige Situationen nützlich, auch bei den Miniaturbildern.
• „Markiere für CTB“ funktioniert, aber teilweise wird der Eintrag bei Wikipedia:Commons-Transfer per Bot/Anfragen nicht gemacht (Beispiel, wo nur die Dateibeschreibungsseite bearbeitet wurde). Auch „Erneuter Transfer“ bewirkte dann nichts. Als ich es ein paar Stunden später nochmals versuchte, klappte es dann (entsprechendes Beispiel). Komischerweise erscheint nach dem Klicken jeweils trotzdem zuerst kurz die Meldung „Nichts zu tun“. Das Feature „Erneuter Transfer“ gefällt mir ansonsten gut und ist praktisch.
• Ein momentan noch fehlendes Feature ist, für Commons einen anderen Namen festzulegen. Beim Script von Ireas steht dazu: Hinweis: Bitte beachte, dass nur dann ein abweichender Dateiname gewählt werden sollte, wenn es dafür einen triftigen Grund gibt.
• Ein weiterer Feature-Request: Beim Markieren einer Datei mit CTB oder DÜP wird diese automatisch beobachtet, so dass bei erfolgtem Transfer die Dateibeschreibungsseite auf Commons bearbeitet werden kann bzw. Änderungen durch die Uploader bemerkt werden. Beim CTB-Script von Ireas ist dies so eingestellt.
• „Bearbeiten mit CTB-Markierung“ funktioniert bei mir nicht. Das Einzige, was sich vom normalen Bearbeiten unterscheidet, ist der zusätzliche URL-Parameter. Gleiches gilt auch für „Bearbeiten mit DÜP-Markierung“ und „Bearbeiten mit Prüfmarkierung“.
• Bei mit DÜP markierten und vom BLUbot schon besuchten Dateien sind bei mir die Häkchen nicht grau und ergänzt oder entfernt werden. Beim Speichern passierte dies.
• Bei der Dateiprüfung gibt es diesen Fehler.
• Noch habe ich keine Möglichkeit gefunden, zur gleichzeitigen Dateikategorisierung und -prüfung, zuerst mit HotCat die Kategorien einzutragen und dann mit einem Tool den Prüfbaustein.

Ich wünsche dir ein schönes Wochenende. --Leyo 01:05, 22. Okt. 2011 (CEST)

Spontane Antworten, ohne zunächst selbst das Skript gestartet zu haben:

1. Sprache:
   • Die nächste Version wird de-CH kennen.
   • Richtig beobachtet: Das Skript unterscheidet
     1. wgDBname – Projekt-DB ("dewiki"); danach richten sich Vorlagen- und Seiten-Namen.
     2. wgContentLanguage – Sprache des Projektes; danach richten sich Bearbeitungskommentare.
     3. wgUserLanguage – Sprache des Benutzers; danach werden Bedienungselemente gestaltet, die ausschließlich der momentane Benutzer sieht. Ist diese Sprache unbekannt, wird immer auf Englisch zurückgefallen.
2. Dateibeschreibungsseiten im selben Tab
   • Eigentlich auf der Optionsseite und im common.js konfigurierbar.
   • Funktioniert es bei dir nicht?
   • Ich prüfe die Funktion nochmal.
3. Eintrag bei CTB/Anfragen erfolgt nicht.
   • Bitte nähere Umstände beobachten; "Nichts zu tun" sagt, dass Eintrag unter diesen Namen schon in der Auftragsliste gefunden wurde.
   • Fehlersuche ist für mich schwierig, weil das immer vom momentanen Gesamtzustand abhängt und über diffpage kaum nachvollziehbar.
4. Bearbeiten mit XXXX funktioniert nicht
   • Werde ich im Lauf des Wochenendes prüfen; neulich ging's noch. Alle drei verwenden die identischen Funktionen und sollten die Vorlage einfügen oder aktualisieren. Der URL-Parameter sollte das auslösen. Beim Bereitstellen des Prototyps klappte das doch eigentlich? Grrrr.
5. Commons einen anderen Namen
   • Wenn die Vorlage "(Bestätigung nötig)" einen NameAufCommons enthält, wird dieser immer übernommen, sobald die Umwandlung "(Bestätigung nötig)" → "(bestätigt)" erfolgt.
   • Wenn mit Button (über API) abgeschickt, ist die Definition eines abweichenden Namens in diesem Moment weder erwünscht noch möglich.
   • Abweichenden Namen erhält man sonst ausschließlich über Edit; hier hat man ja die Vorlage "(bestätigt)" eingefügt bekommen und muss selbst wissen, dass als Parameter der NameAufCommons möglich ist. Der wird dann auch berücksichtigt.
   • Bedienungsanleitung und Hinweise mag ich im Skript nicht liefern. Die Handvoll besonders Befugter und die regelmäßig CTB verübenden Admins sollten das auch so wissen; wenn ein Selten-Transferierer unter den 300 Admins das mit dem triftigen Grund nicht weiß, kennt er auch den Parameter von "(bestätigt)" nicht.
6. DÜP: Häkchen nicht grau
   • Werde ich untersuchen. Bei mir ging's.
7. Geklaute Kategorie bei Dateiprüfung
   • Zweifelsfrei ein Bug; wird sich finden lassen.
   • Das Skript trennt zuächst die Sort/Kat/IW ab, fügt "Geprüfte Datei" (ggf. aktualisiert) an den Rumpf und soll den abgetrennten Block wieder dranschreiben; vor einigen Monaten ging das auch mal. Irgendwo verbummelt.

Ich werde im Laufe des Wochenendes eine leicht nachgebesserte Version bereitstellen (0.72), bei der ohne größeren Aufwand zu beseitigende Macken gefixt sind.

Bis dann --PerfektesChaos 09:18, 22. Okt. 2011 (CEST)

0.71 geschrieben, wenn ausgetestet 0.72

Ich habe bislang:

• Geklaute Kategorie bei Dateiprüfung – Schreibfehler, fixed.
• Bearbeiten mit XXXX funktioniert nicht – DÜP hatte einen Logik-Bug, die anderen beiden wohl nicht und scheinen zu funktionieren. Fixed.
• Sprache de-CH etc. jetzt bekannt.
• Dateibeschreibungsseiten im selben Tab – scheint bei mir auf Anhieb zu funktionieren?

Noch im Laufe des Abends/frühmorgens beabsichtigt:

• DÜP: Häkchen nicht grau; Konflikt mit Benachrichtigung? Noch zu analysieren.
• BEO wenn über API DÜP/CTB eingefügt: Kinderkram, eine Zeile.

--PerfektesChaos 23:21, 23. Okt. 2011 (CEST)

1. DÜP: Häkchen nicht grau – Ich habe mir mal den ersten von der Liste gegriffen: Datei:Bawerk.gif – hat benachrichtigt=Lizenz. Wenn ich mir die Dateibeschreibung ansehe, sehe ich ein graues Häkchen in der roten DÜP-Box bei „Lizenz“. Wenn ich nun normales [Bearbeiten] anklicke, passiert nichts ungewöhnliches. Klicke ich [Bearbeiten mit DÜP] an, bekomme ich eine leere {{Dateiüberprüfung}} eingefügt; so soll es sein. Klicke ich während des Bearbeitens in der roten Box etwas an, wird auf [Markiere als DÜP] hin die Vorlage eingefügt und die Parameter werden aktualisiert. Durch Setzen und Umdefinieren der Häkchen lassen sich die jeweiligen Parameter in der Vorlageneinbindung verändern (auch wieder löschen), sobald [Markiere als DÜP] die Aktion startet. Was nicht geht, ist den Parameter „Lizenz“ hineinzubringen. Wo genau ist nun das Problem?
2. BEO – nun zunächst wie folgt: Wenn über API die DÜP oder CTB eingefügt werden, wird das Häkchen immer gesetzt. Bisher galt hier: „Benutzereinstellung beachten“ (Markiere die von mir geänderten Artikel). Prinzipiell lässt sich das auch ausdehnen auf die Fälle, in denen interaktiv bearbeitet wird; ich ahne jedoch, dass hier einige Leute das mal so, mal anders haben möchten. Deshalb werde ich das nächste Woche in zwei konfigurierbare Benutzer-Optionen überführen.

In einigen Minuten Version 0.72 live.

Gute Nacht --PerfektesChaos 00:51, 24. Okt. 2011 (CEST)

de-ch funktioniert, danke.

Seltsam. Bei Datei:Bawerk.gif ist bei mir das Häkchen schwarz und kann entfernt werden. In den übrigen Feldern können Häkchen eingefügt werden. Bei Bearbeiten oder Bearbeiten mit DÜP-Markierung ändert sich nichts an der Seite.

Bei Datei:Chemisches Labor1898.jpg und anderen wird in roter Schrift Noch keine Kategorie. angezeigt, obwohl Kategorien vorhanden sind. --Leyo 22:34, 27. Okt. 2011 (CEST)

1. Noch keine Kategorie. – Stimmt, Falschanzeige. Muss ich mal herausfinden, warum er die Kategorien nicht findet; irgendein Schreibfehler vermutlich.
2. Graues Häkchen – Das ist allerdings seltsam. Ich gucke mit FF3.6 auf ein graues Häkchen bei „Lizenz“, das sich nicht entfernen lässt. Da werde ich Detektiv spielen müssen. – Wenn du mit dem Häkchen nur bei Lizenz Bearbeiten mit DÜP-Markierung anklickst, kann sich auch nichts ändern. Aber wenn du „Freigabe“ anhäkelst und danach Bearbeiten mit DÜP-Markierung anklickst (geht auch während des Bearbeitens), wird bei mir die Vorlage frisch eingefügt und der Parameter „Freigabe“ gesetzt.

Trotzdem schönen Urlaub --PerfektesChaos 23:41, 27. Okt. 2011 (CEST)

Noch keine Kategorie. – War ein vertrödeltes Minuszeichen; sollte jetzt passen. In 0.74 bereits live. --PerfektesChaos 00:26, 28. Okt. 2011 (CEST)

0.73 mit BEO

• Soeben 0.73 live; clear cache.
• Beo: In Abhängigkeit von den Optionen wird eingefügte DÜP/CTB automatisch beobachtet (Vorgabe: automatisch immer); sowohl edit wie API.
  • Ist in den blauen Dunst geschrieben, nicht getestet und für mich auch nur mühsam zu testen. Bitte Verhalten an realen Seiten überwachen.
• A propos Optionen: Dort gibt es auch die individuelle Einstellung „Zielfenster“, die die Anzeige der „Dateibeschreibungsseiten im selben Tab“ festlegt.

Amüsier dich --PerfektesChaos 10:10, 25. Okt. 2011 (CEST)

Bugmeldung

Ich hatte eine Datei die mit {{Commonsfähig}} war, mit dem Tool oben via CTB zum Commonstransfer angemeldet. Folge: Datei wurde zwar eingetragen, jedoch wurde die Dateibeschreibung vollständig gelöscht. Siehe Diff-Link. --Quedel 17:29, 1. Nov. 2011 (CET)

Da die lokale Dateibeschreibungsseite inzwischen gelöscht ist: Der Seiteninhalt wurde ersetzt durch

{{Nach Commons verschieben (bestätigt)}}

false

--Leyo 01:28, 22. Nov. 2011 (CET)

Uuuups, sorry, Quedel, deine Meldung ist mir völlig in den Fluten meiner BEO versunken. Ich hatte diese Seite hier auch nach Leyos Urlaubsantritt nicht mehr angefasst.

Näheres siehe unten.

Bis demnächst --PerfektesChaos 09:56, 22. Nov. 2011 (CET)

WP:Dateiverwaltung

Ich empfehle die Anlage einer Seite WP:Dateiverwaltung.

• Zweck: Information Welche Arbeitsgruppen sind in der de.WP alles rund um Dateien tätig?
• Liste mit Kurzbeschreibung des Tätigkeitsfeldes:
  1. Dateiüberprüfung, aber kein Projekt
  2. WikiProjekt Dateikategorisierung
  3. WikiProjekt Commons-Transfer
  4. Dateiprüfung (kein Projekt, aber Mitarbeiter)

Als fünfte Aufgabe (und aktueller Anlass) der Seite wäre das Hosting für das Universalwerkzeug zu nennen.

Dann gibt es (nicht unmittelbar zur Verwaltung) zu nennen:

• Grafikwerkstatt
• Irgendwer macht koordiniert was mit der Umwandlung in SVG.
• Vor Jahren gab es mal eine eigene Truppe Bild-URV? Jetzt irgendwie bei Wikipedia:Urheberrechtsfragen.
• Schließlich: Betreuung der Hilfeseiten zu Bildern und des Tutorials.

Sind insgesamt 9 Themenkomplexe, zu denen es irgendwo Anlaufstellen und Mitarbeiter gibt.

Hintergrund: Als ich mich im Sommer an das Thema machte, hatte ich große Schwierigkeiten damit, die „Zuständigkeiten“ zu durchschauen. --PerfektesChaos 10:14, 15. Okt. 2011 (CEST)

Hm, was man machen könnte ist, die Linkbox Vorlage:Dateiüberprüfung (Index) nach dem Vorbild Wikipedia:Redaktion Bilder/Linkbox zu erweitern und in die relevanten Seiten einzubinden. Was meinst du? --Leyo 01:09, 22. Okt. 2011 (CEST)

Ich fürchte, den eigentlichen Witz hast du noch nicht geblickt: Es ist Punkt Fünf.

Ich ziele ab auf Umzug nach: WP:Dateiverwaltung/Werkzeug.js

WPDK deckt nämlich nicht CTB ab.

Und die Oberseite zum Werkzeug listet elegant die beschriebenen fast zehn Arbeitskreise auf.

--PerfektesChaos 09:28, 22. Okt. 2011 (CEST)

HotCat

Es gibt einen deutschsprachigen Benutzer:Lupo als offenkundigen Hauptentwickler.

• Ich selbst benutze HotCat nicht und mag mich auch nicht einarbeiten.
• Das Problem müsste auch genauso ohne das neue Skript bestehen, wenn während der Laufzeit der API-Änderung das normale [Bearbeiten] angeklickt wird. Auch dann wird die Version vor HotCat zum Bearbeiten übernommen; danach wird in der Server-Version die HotCat-Änderung eingearbeitet, und beim Abspeichern des manuellen Edits sollte es einen Bearbeitungskonflikt geben.
• Lösungsansätze:
  • HotCat.js müsste definieren (wahlweise):

      mw.libs.hotCat.inProcess = true;
      var HotCat_inProcess = true;   // old fashion: Polluting global namespace

• Nachdem HotCat aktivitätslos abgebrochen wurde oder eine API-Änderung erfolgreich vollzogen wurde, setze man dies auf false.

• Um schlafende Aktivitäten aufzuwecken, sollte zusätzlich ausgelöst werden:

      jQuery(document).trigger("autoEdit", ["Gadget/HotCat"]);

• Ich kann die Existenz dieser Variable prüfen und meine Aktivitäten so lange blockieren, bis inProcess nicht mehr true ist; also auch, wenn das HotCat-Fenster offen ist. Damit kann ich die Blockade aufheben; wenn ein Event aufgefangen wird, lassen sich auch schlafende Klicks automatisch nachholen.

• Das kann auch für diverse andere Skripte und Abläufe von Interesse sein.

--PerfektesChaos 10:55, 23. Okt. 2011 (CEST)

Ich schreibe einfach mal, wie ich es mir gedacht hatte: Nachdem man die Kategorien mit HotCat gesucht und ausgewählt hat, klickt man auf Speichern. Anders als der Name erwarten lassen würde, wird nicht gespeichert, sondern der Bearbeitungsmodus aufgerufen. Dort sind die ergänzten oder geänderten Kategorien enthalten. Das Script müsste nun Vorlage:Geprüfte Datei in die im Editmodus angezeigte Version einsetzen. Benutzer:Ireas/bilderpruefen.js macht dies so. --Leyo 22:24, 27. Okt. 2011 (CEST)

Wenn du auf halbwegs zulässige Weise von HotCat aus in die Bearbeitungsseite kommst, müsstest du eigentlich die grüne Box für Dateiprüfung angezeigt bekommen, und auf der sollten die Links für das Einfügen der Vorlage auch im Bearbeitungsmodus stehen. Ich werde das mal näher analysieren und nächste Woche HotCat zum Spielen aktivieren. --PerfektesChaos 23:31, 27. Okt. 2011 (CEST)

Testbilder

Ich hätte gern 3 neue, durch einen prominenten Bild-Admin angelegt; die Grafik kann unverändert die aus dem August sein; jedoch:

1. Testbild-Dateiverwaltung-einfach.png
   • wie bisher
2. Testbild-Dateiverwaltung-CTB-Wunsch.png
   • Grundausstattung mit „(Bestätigung nötig)“ und dazu geeigneter Lizenz.
3. Testbild-Dateiverwaltung-kategorisiert.png
   • Lizenz für Dateiprüfung + Kategorie:Vorlage:nur Test

Das alte Bild mit zermanschter VG kann hingegen geSLAt werden.

• Was die Kategorie-Systematiker angeht: Außer für Vorlagen haben wir bisher keine Kategorie:WP:nur Testdaten, dazu Kategorie:Datei:nur Testbild ... letztere würde ich eigentlich brauchen.

LG --PerfektesChaos 00:57, 24. Okt. 2011 (CEST)

Die Kategorie und die beiden ersten Bildwünsche habe ich angelegt/erfüllt, hoffentlich richtig. Den dritten Wunsch verstehe ich nicht ganz, sorry.

Nun verabschiede ich mich erstmal in die Ferien und wünsche dir eine gute Zeit! --Leyo 22:59, 27. Okt. 2011 (CEST)

Vielleicht schaffst du das dritte Bild aus dem Koffer heraus – es müsste eine Lizenz haben, aus derNoCommons folgt, und damit prüffähig sein. Der Kategorie:Datei:nur Testbild darf man nicht verraten, dass sie eigentlich eine Wartungskat ist, dann muss ich nicht heimlich die Datei:Chemie missbrauchen und hoffen, dass es in den Minuten keiner merkt. Wenn ich meinen Vandalismus kommentarlos zurücksetze, möchte ich wieder auf einen definierten Anfangszustand zurückfallen; dazu darf ich nicht selbst der Hochlader sein.

Schönen Urlaub, falls du schon offline bist --PerfektesChaos 23:27, 27. Okt. 2011 (CEST)

Im November

Zum achten Prototyp habe ich folgende Punkte auf der Agenda, die ich diese/kommende Woche abzuarbeiten gedenke:

1. Von Quedel 1. Nov. gemeldet:
   • Wenn {{Commonsfähig}} bei CTB dann Seiteninhalt gegen false.
   • Sicher nur ein Tippfehler irgendwo im Skript; nach Ortung kinderleicht zu beseitigen.
   • Rückfrage: Tritt das ausschließlich bei {{Commonsfähig}} auf oder wurde das auch in anderen Fällen beobachtet? – Da Quedel das Werkzeug nach dem 1. November öfters benutzt hatte, gehe ich mal davon aus, dass es ein Schreibfehler im Zusammenhang mit dem Wort „Commonsfähig“ und Folgen daraus sein dürfte.
2. Dateiprüfung + HotCat: Es ging darum, dass die grüne Einfügen-Box beim Bearbeiten einer (jetzt erst?) Dateiprüfungs-fähigen Seite nicht erscheint.
   • Muss ich mir noch genauer anschauen. Eigentlich sollte diese grüne Box bei jedem Bearbeiten einer Dateiprüfungs-fähigen Seite vorhanden sein. Möglicherweise wurde eine notwendige Voraussetzung für Dateiprüfung erst mit HotCat eingefügt/entfernt und war deshalb für das Skript nicht rechtzeitig sichtbar?
3. Leyo berichtete von Schwierigkeiten mit den Optionen und der Vorgabe Miniaturbilder/Fenster
   • Bisher nicht reproduzierbar, noch zu analysieren.
4. DÜP: Häkchen nicht grau wenn bereits benachrichtigt
   • Seltsam. Weiter untersuchen; bei mir geht's.

Ich habe das Skript seit über drei Wochen nicht mehr angefasst und muss mich in mein eigenes Geschreibsel erstmal wieder einlesen.

In den nächsten Tagen bin ich noch auf einer anderen Wiki-Baustelle aktiv, von der auch Commons etwas hat.

Liebe Grüße --PerfektesChaos 10:05, 22. Nov. 2011 (CET)

1. Soweit ich mich erinnern kann, ist das Problem sonst nirgends aufgetreten.
2. Die Voraussetzung für eine lokale Dateikategorisierung ist NoCommons. Mit HotCat werden nur Kategorien bearbeitet. Daran sollte es eigentlich nicht liegen.
3. Vielleicht liegt's auch an meinen Einstellungen: Ich habe fileAdmin_miniatur = false; in meiner common.js.
4. Da hat sich nichts geändert.

--Leyo 01:03, 13. Dez. 2011 (CET)

Achter Prototyp

Version 0.8 nach Cache-Leerung live.

• Den Tippfehler bei Commonsfähig habe ich beseitigt.
• Eine Dateiprüfung ist nun auch noch möglich, wenn die Seite bereits anderweitig zum Bearbeiten geöffnet wurde. Damit sollte sich das HotCat-Problem erledigt haben?
• Intern habe ich einige Restrukturierungen und Vereinfachungen (erstmal für mich) vorgenommen, von denen man hoffentlich nach außen nichts merkt. Dabei könnten sich aber in irgendeiner Nische Fehler eingeschlichen haben.
• Ich habe alles durchgespielt, was mir einfiel. Bitte trotzdem erstmal in den ersten Tagen mit Misstrauen begucken.
• Die Umbenennung "Versteckte Kategorie" → Kategorie:Versteckt habe ich dann auch mitbekommen. Gab es noch mehr davon?

Schöne Adventszeit --PerfektesChaos 15:31, 4. Dez. 2011 (CET)

Betreffend Dateiprüfung: Ich merke keinen Unterschied:

• Wenn man mittels HotCat Kategorien ändert bzw. hinzufügt und dann mittels Speichern die geänderte Dateibeschreibungsseite im Editmodus öffnet, fehlt ein Prüfen-Knopf.
• Bearbeiten mit Prüfmarkierung (&action=edit&fileAdm=approve) bewirkt dasselbe wie &action=edit.

Durch die internen Umstrukturierungen sind bei mir keine neuen Probleme ausgetaucht.

Relevante Umbenennungen? Hm, da kommt mir nur etwas entfernt Verwandtes in den Sinn: Bei den beiden Unterkategorien von Kategorie:Datei:NowCommons sollte Fehlende Vorlage: Dateikategorie nicht eingeblendet werden.

Ich wünsche eine schöne Rest-Adventszeit. --Leyo 00:55, 13. Dez. 2011 (CET)

• Ich werde sie mir mit JS-Verfeinerungen zu versüßen wissen.
• Für die beiden NowCommons() wäre wohl irgendeine Markierung als Wartungskategorie oder Versteckt hinreichend; nach meinem Verständnis erfüllen sie diese Vorausssetzung. Siehe Kategorie:Datei:Datei-Wartung.
• WP:WVW #Auf mehrere Dateiversionen prüfen ist in die laufende Testversion eingebaut und benötigt
  • von einem bekannten Uploader ein neues Testbild mit sprechendem Namen und zwei Upload-Versionen und {{NowCommons}}.
  • Einfügung eines stylishen Hinweises in Vorlage:NowCommons (nicht mehr id=, sondern jetzt class="multiVersion") zum weiteren Testen.
• fileAdmin_miniatur=false; für „Miniaturbilder einblenden“ ist die Vorgabe und auch die richtige Option. Bei mir funktioniert das wie vorgesehen. Seltsam; inzwischen habe ich hier aber einen Anhaltspunkt gefunden und werde diesem Verdacht nachgehen.
• Wenn ich Datei:Testbild-Dateiverwaltung-einfach.png mit dem Alle-Welt-Bearbeiten editiere, sehe ich im Bearbeiten-Modus das grüne Kästchen zum „Markiere als geprüft“. Das lässt sich auch anklicken, fügt die Vorlage ein und entfernt das grüne Kästchen während des weiteren Bearbeitens.
  1. Ist das bei dir genauso?
  2. Was ist bei „HotCat-Dateiprüfung“ anders?
• Auch die weitere offene Knacknuss „benachrichtigtes DÜP-Häkchen nicht grau“ ist weiterhin auf dem Schirm. Möglicherweise jeweils Browser-Abhängigkeit, Einfluss individueller Konfiguration; sobald Ursache erkannt ist, wird sie sich auch beseitigen lassen.

LG --PerfektesChaos 13:28, 13. Dez. 2011 (CET)

Bug bei CTB

Heute hat in allen vier Versuchen der Eintrag in Wikipedia:Commons-Transfer per Bot/Anfragen nicht geklappt. Auch das Klicken auf „Erneuter Transfer“ bewirkt nichts. --Leyo 14:52, 20. Dez. 2011 (CET)

Mein erster Verdacht wäre, dass es daran liegt, dass die Anfragen absolut leer sind. (Eigentlich hatte ich diesen Fall mal getestet, aber vielleicht haben sich Umstände geändert.)

• Das Skript könnte bei einer leeren Zeichenkette einen Fehler machen, wenn die Suche nach dem bereits vorhandenen Eintrag zur gleichen lokalen Datei fehlschlägt. Dies war aber getestet und es gibt dazu keinen Anlass.
• Die API gibt bei einer völlig leeren Seite vielleicht jetzt keine leere Zeichenkette mehr zurück, sondern meldet dies (jetzt?) auf andere Weise.

Wenn ihr es zur Hand habt, probiert doch mal mit einem anderen Skript einen Eintrag zu generieren, oder schreibt ein paar Leerzeichen/zeilen hinein. Wenn es danach geht, ist der Auslöser identifiziert und kann beseitigt werden.

• Später am Abend werde ich auf den Spiel-Anfragen nach der Ursache suchen.

In jedem Fall wäre der 9. Prototyp fällig; dazu wäre ein Mehrversions-Testbild und eine aufgehübschte Vorlage:NowCommons mit class="multiVersion" (nicht mehr id) zum Testen des bereits programmierten Auf mehrere Dateiversionen prüfen sinnvoll.

Bis demnächst --PerfektesChaos 17:31, 20. Dez. 2011 (CET)

Deine Vermutung scheint zuzutreffen: Bei nicht-leerer Antragsseite geht's wieder. Beim Klick auf „Erneuter Transfer“ erscheint „Nichts zu tun“ jeweils trotzdem kurz. Dieses Problem existiert in deinem Script nicht, oder?

Die benötigte Datei lade ich demnächst hoch. Bezüglich Vorlage:NowCommons bin ich mir nicht sicher, ob id="Vorlage_NowCommons" durch class="multiVersion" ersetzt werden soll. Hätte das nicht irgendwelche unerwünschten Auswirkungen? --Leyo 17:43, 20. Dez. 2011 (CET)

@Vorlage:NowCommons: Es müssen beide vorhanden sein, und sie haben überhaupt nichts miteinander zu tun. Wie in der Vorlagen-Werkstatt angegeben, ist das ein separater Block, der normalerweise unsichtbar ist. Bei mehreren Dateiversionen werden alle (weil class) Blöcke mit multiVersion, die auf der Seite unsichtbar vorhanden waren, dadurch sichtbar, dass ich ihren style wegschmeiße.

@Kodierung und älteres Problem: Ich kannte die Disku und hatte sie berücksichtigt; an Einzelheiten kann ich mich nicht erinnern.

@Leere Anfragenseite: Es ist dann vermutlich so, dass das Skript bisher nicht weitermacht, wenn die API keine leere Zeichenkette zurückgibt; vielleicht hatte beim Testen bisher immer noch ein Zeilenumbruch dringestanden. Wenn das aber so ist, wird sich die Situation erkennen lassen und ich kann selbst eine leere Zeichenkette vorgeben, an die der neue Eintrag angehängt wird. Es wird immer nur eine schon vorhandene Liste von Anfragen erweitert.

Bis bald --PerfektesChaos 18:03, 20. Dez. 2011 (CET)

Gerade weiter oben auf dieser Seite gecheckt: In fileAdm.trans.bot.feed schreibe ich seit Monaten " statt ". --PerfektesChaos 19:25, 20. Dez. 2011 (CET)

Ups, ich hatte das nicht mehr auf dem Radar.

Die Änderung von Vorlage:NowCommons habe ich nun vorgenommen, die gewünschte Mehrversionen-Datei hochgeladen. --Leyo 11:45, 21. Dez. 2011 (CET)

Die Änderung von Vorlage:NowCommons befriedigt leider weder ästhetisch noch technisch. Zur Erinnerung nochmals ein Auszug aus der Vorlagen-Werkstatt:

Die Vorlage müsste einen standardmäßig ausgeblendeten Block enthalten:

<div idclass="multiVersion" style="display:none">
 {| rahmen
 Achtung; diese ...
 * [[#filehistory|Dateiversionen]]
 * [[tools:~magog/oldver.php]]& file={{urlencode:{{...}}|PATH}}
 |}
</div>

Es handelt sich um einen eigenständigen Block, bei dem du zur Erprobung das none hinter display: weglassen kannst. Diesen Block kannst du fachlich-inhaltlich geeignet ausgestalten. Anschließend das none reinsetzen, dafür deine vorangegangenen Änderung besser reverten. Wenn fileAdm eine NowCommons findet, fragt es in der API nach mehr als einer Version; falls ja, nimmt es bei allem, was eine class=multiVersion hat, ein eventuelles style weg.

Gute Nacht --PerfektesChaos 23:31, 22. Dez. 2011 (CET)

Da habe ich dich falsch verstanden. Es wäre wohl einfacher, wenn du die Änderung in der Vorlage:NowCommons selbst vornehmen würdest. Der Aufruf des Old version filemover sollte eigentlich mit

[//toolserver.org/~magog/oldver.php?project=de.wikipedia&src={{urlencode:{{PAGENAMEE}}}}{{#if: {{{1|}}}|&trg={{urlencode:{{{1}}}}}}} Fehlende Versionen bei Commons hochladen]

oder ähnlich klappen, aber irgendwie mag das Tool „get“ nicht. --Leyo 13:35, 24. Dez. 2011 (CET)

• Die Vorlage habe ich geändert.
• Ich sehe keinerlei Doku zu dem tool, und keinen Hinweis darauf, dass diese Parameter project= src= trg= in der get-URL ausgewertet würden. Das sind die Parameter, mit denen er seine eigentliche Aktion startet; richtig bemerkt, nur mit POST möglich, und dann passiert sofort irgendwas Wirksames (keine Ahnung was).
• Unter Commons-Experten könntet ihr euch ja austauschen, dass bei URL-GET die Formularfelder vorbelegt werden sollen (etwa das doofe project schon mal gewählt wird), und von da aus die wirkliche Aktivität über POST gestartet wird.

Guten Rutsch einstweilen --PerfektesChaos 23:08, 29. Dez. 2011 (CET)

Magog hat POST auf GET umgestellt. --Leyo 01:44, 4. Jan. 2012 (CET)

Neunter Prototyp; zum Kopieren bereit

Updates:

• Bugfix: Leere CTB-Warteschlange

  War ein Fehler bei mir. Eine leere Zeichenkette verhält sich in JS meist wie ein garnix. Dies hatte bei einer Abfrage zu unverzeihlicher Faulheit geführt. Beim Testen hatte ich vermutlich noch einen Zeilenumbruch oder ein Leerzeichen auf meiner Spielwiese, so dass sie leer aussah, aber noch ein Byte enthielt.

• Seltsamkeit bei Voreinstellung von Miniaturbildern

  Nach längerem Suchen eine Unstimmigkeit gefunden, die im Zusammenspiel von Voreinstellung, automatisch generiertem Cookie und Optionsseite in manchen Situationen vermutlich irrtümliches Ausblenden bewirkte.

• Neues Feature: Mehrere Bildversionen im NowCommons

  Anzeige von Hinweisen wird ausgelöst.

Der 9. Prototyp liegt für Admin zum Kopieren unter Benutzer:PerfektesChaos/js/fileAdm.js bereit (Vollschutz).

Offene Angelegenheiten:

• Globale Verwendung einer Datei (Commons, Lokal?) kennzeichnen: verwendet oder nicht verwendet?
  • Lokale Verwendung einer Datei: Lokal verwendet oder nicht verwendet?
• HotCat-Arbeitsablauf bei Dateiprüfung??

Für 2012 sollte ein neuer Seitenname in den Pfad dieses Werkzeugs gesetzt werden (über Dateikategorie ist es schon längst hinaus) und mit der Version 1.0 das Teststadium verlassen und in den allgemeinen Betrieb gehen.

@Leyo:

• Datei:Ajax-loader.gif hätte ich gern wie Datei:Temps réel.gif auf Commons unter „Sanduhr“ auffindbar kategorisiert gesehen, traue mich aber nicht. Oder diese Category verweist auf commons:Category:Throbbers – Throbber ist hier das Ajax-Pendant der Windows/Mac-Eieruhr. Ich hatte es vergeblich bei den clocks gesucht und nur zufällig mal unsere URL in die Hände bekommen.

Damit wäre das Jahr 2011 auch in dieser Beziehung zu einem definierten Abschluss gekommen; Guten Rutsch --PerfektesChaos 15:16, 31. Dez. 2011 (CET)

Bug: 0.9→0.91

Ich wünsche dir nachträglich ebenfalls einen guten Rutsch!

Ich hoffe, du bist mit der Ergänzung in commons:Category:Hourglass icons zufrieden.

Die neue Version habe ich übernommen. Dabei sind mir Verbesserungen und Verschlechterungen aufgefallen:

• Der Kasten oben für Dateiprüfung und CTB ist verschwunden.
• Standardmässig werden bei mir jetzt die Thumbnails wie gewünscht angezeigt. Nur mit dem Standard Zielfenster gleich will es nicht klappen. Auch das half nichts.
• Bearbeiten mit DÜP-Markierung funktioniert nun.

Soviel für den Moment. --Leyo 00:50, 4. Jan. 2012 (CET)

• Keine Kästen
  • Äh, – du bist sicher, dass du noch Admin bist?
  • Klingt so, als ob deine Berechtigung aus Dateiprüfer nicht rechtzeitig eintrifft, oder irgendwie abhanden kommt. Sofort wird aber bestimmt, ob du sysop bist; CTB-Berechtigte wird dann gar nicht mehr abgefragt.
  • Es hat sich von 0.8 auf 0.9 eigentlich absolut nichts geändert, was darauf Einfluss hätte.
  • Verstehe ich richtig: Unter 0.8 ging es, und beim Umstieg auf 0.9 sind immer alle Kästen weg, für die besondere Rechte erforderlich sind?
  • Ich selbst sehe immer alle Kästen, aber ich habe auch einen harten Keks.
  • Oder wo genau in welcher Situation sind seit wann welche Kästen weg?
• Option „Zielfenster“
  • schaue ich mir an; deine common.js müsste allen inneren Prozeduren vorgehen. Da war ich schon seit Monaten nicht mehr dran; vielleicht ging aber bei einer inneren Restrukturierung vom siebten auf den achten Prototyp etwas verloren.
• Bearbeiten mit DÜP-Markierung funktioniert nun.
  • Das deute ich so, dass damit die HotCat-Angelegenheit erledigt ist?

Nach erfolgreicher Diagnostik wird sich kurzfristig ein 0.91 schaffen lassen, das die im Code winzigen Korrekturen enthält.

Bis bald --PerfektesChaos 10:28, 4. Jan. 2012 (CET)

Betreffend Kästen: Sie sind seit dem Update von 0.8 auf 0.9 weg. Einzig DÜP wird angezeigt, wenn Quelle oder Urheber fehlt bzw. wenn die Datei bereits getaggt worden ist.

Betreffend HotCat: Das hat damit nichts zu tun. Hier wird nach dem Taggen per fileAdm nicht gespeichert, so dass eine weitere Bearbeitung im gleichen Edit möglich ist. Bei HotCat hingegen müsste fileAdm nach dessen Einsatz aktiv werden, also im Editmodus.

Zudem ist bei mir Wikipedia (ungefähr?) seit der Umstellung sehr langsam. Navigation-Popups ist nicht mehr zu gebrauchen, bei Diffansichten dauert das Laden ewig (nachdem eigentlich schon alles da zu sein scheint). --Leyo 14:55, 5. Jan. 2012 (CET)

Na, das klingt ja bedrohlich.

• Das Skript und seine Veränderungen habe ich nochmals durchgesehen, aber bisher keinen Hinweis finden können. Sonst hätte ich den Prototyp auch nicht bereitgestellt. Bei mir geht alles.
• Du bist offenkundig als Normalbenutzer ohne Zusatz-Berechtigungen tätig.
  • Falls du sowas noch nicht hast, wäre ein FireFox-AddOn sinnvoll, das dir die Inhalte von Cookies anzeigt, sie löschen und manipulieren lässt. Das ist auch für den privaten Datenschutz interessant, um zu überblicken, welche Infos irgendwelche Websites über dich sammeln. Eins von mehreren AddOns wäre cookie-manager.
  • Dann würde mich nämlich der Inhalt der beiden Cookies interessieren, die von fileAdm für Zusatz-Berechtigungen angelegt werden, damit sie schnell ausgewertet werden können.
• "Seit der Umstellung" meint welche Umstellung? fileAdm 0.9, MW 1.18, FF8→FF9? Falls fileAdm im Verdacht und bislang noch nicht probiert, fileAdm-Einbindung mal auskommentieren und schaun was passiert. Wenn offenbar ich schuld bin, erstmal so lassen.
  • Ich hatte sowas in den letzten Tagen auch öfter und konnte identifizieren, dass der Spendenbanner eine ausgiebige und für mich nicht nachvollziehbare Kommunikation mit seinem Heimatplaneten zu führen versuchte. Unter anderem versuchte er auch meine "GeoIP" zu lokalisieren und weiterzuleiten, was aber immer fehlschlägt, weil von mir geAdBlockt.
• Ich überlege derzeit eine Diagnostik-Version von fileAdm, die an entscheidenden Stellen Boxen aufpoppen lässt, um deine Situation analysieren zu können.
• Zur Kompatibilitätsanalyse bleibe ich noch in der FF3.6-Serie und hoffe, dass in neueren FF nichts passiert, das ich wissen müsste. Einen Bug in FF hat Steef389 neulich gefunden.

Das wird schon wieder --PerfektesChaos 10:24, 6. Jan. 2012 (CET)

Ich habe nun die Web-Konsole laufen lassen. Die Fehlermeldung, die ich beim Laden von Dateibeschreibungsseiten kriege, wo die Balken oben erscheinen sollten ist:

fileAdm is not defined @ http://de.wikipedia.org/w/index.php?title=Wikipedia:WikiProjekt_Dateikategorisierung/Werkzeug/x.js&action=raw&ctype=text/javascript:5714

Du scheinst also recht zu haben. Mit Umstellung meinte ich auf die neue Version des Scripts (0.8→0.9). Auf diesem PC läuft FF 8.0.1, auf dem andern wahrscheinlich 9.0.x.

Den Advanced Cookie Manager habe ich installiert, aber ich muss mir das mal in Ruhe anschauen. --Leyo 04:47, 7. Jan. 2012 (CET)

Das mit der Fehlerkonsole war eine Spitzen-Idee; warum bin ich nicht draufgekommen?

• javascript:5714 war die Schlüssel-Information (fileAdm is not defined)
• Ein klassischer, simpler, öder Bug (ab Zeile 5711+3).
• Aus unerklärlichen Gründen bei einer globalen Ersetzung aufgetreten, bei der alle Objektkomponenten an das globale MediaWiki-Extension-Objekt angedockt wurden. Alle Zeilen hatten das mitbekommen, nur diese eine nicht. Warum nur, waruuuum?? Klassischer Edit-Unfall.
• Dies aufgetreten in dem Pfad, der bei Fehlen der Cookie-Information die individuellen Benutzerermächtigungen nachprüft und das Ergebnis in einem Cookie speichert. Weil ich aber als Tester eine Dauerkarte bis 2015 habe, komme ich nie durch diese kleine hohle Gasse.
• Es bedarf also nur des Kopierens in den WP-NR über den Vollschutz.
• Advanced Cookie Manager ist für diese Aktion nicht mehr erforderlich, aber für dich privat kannst du mal gucken, welche Websites alles Informationen über dein Surfverhalten speichern, diese ggf. gezielt löschen oder blockieren.
  • Du könntest dir allerdings fileAdm eine Winzigkeit beschleunigen, indem du aus den beiden Berechtigungen R=Review und T=CTB ebenfalls Dauerkekse machst. Aber dann wärst du in der gleichen Konfiguration wie ich und würdest nicht mehr in potenzielle künftige Bugs laufen; also in der Testphase besser so lassen. Es sind standardmäßig Sitzungs-Cookies, das heißt dass der Cookie am Ende der Browser-Sitzung vernichtet wird, damit einmalig am Beginn der neuen Browser-Sitzung wieder die Informationen abgefragt werden. Das Ergebnis dieser Abfrage wird von eben dieser Funktion mw.libs.fileAdm.users.familiar als Cookie abgelegt, die hier abgeschmiert war. Damit ging dann garnix mehr.
• Im Übrigen beobachte ich sporadisch mit dem AddOn HttpFox den Datenverkehr, wenn die Wiki-Seiten mal wieder unerträglich lahm sind. Ursache ist regelmäßig centralnotice=Spendenbanner, der auf Antwort wartet, keine bekommt und damit den Betrieb aufhält, weil die Seite nicht weiter aufgebaut wird. Auch BKL-Check und Rechtschreibprüfung produzieren gelegentlich eine Zeitüberschreitung oder anderen Zugriffsfehler; im Gegensatz zum Spendenbanner hat das aber keine dramatischen Folgen, weil einfach nur das Prüfungsergebnis nicht eintrifft und auf der fertigen Seite die Markierung der Fehlerstellen dann nicht erfolgt.

Sorry for confusion --PerfektesChaos 10:16, 7. Jan. 2012 (CET)

Vielen Dank für die schneller Korrektur! Nun sind die Balken wieder da.

Nun ist mir ein anderes kleines Problem aufgefallen: Bei der Zweitprüfung mittels „Bearbeiten mit Prüfmarkierung“ passierte das. Der „Balken“ erkennt die Erstprüfung, nicht aber der „Editor“. Dasselbe passiert auch bei der automatisch gespeicherten Variante („Markiere als geprüft“).

So, nun muss ich weg. Schönes Wochenende! --Leyo 15:16, 7. Jan. 2012 (CET)

Ähm, ja, 0.91 hast du wie hier dargelegt und in der diff erscheinend kopiert; nur hatte ich dann anschließend noch diesen von mir mangels Eintrag in den betreffenden Original-Listen sehr selten benutzten Pfad selbst begangen und eine Viertelstunde nach der vorstehenden Nachricht eine 0.92 hochgeladen; noch ein weiteres Problemkind der Objektkomponenten. Dann müssten es dort aber hoffentlich alle sein.

Dies ist möglicherweise die Ursache für das 15:16 geschilderte Problem

Also leider erstmal die neueste 0.92, wenn du wieder WP-Online bist, bittschön.

Die Mitteilung von 15:16 werde ich weiter analysieren; vielleicht kommt dann noch eine 0.93.

Das Kopieren rennt nicht weg; mach erstmal RL, dann habe ich etwas Zeit, um mir das genauer anzuschauen.

Liebe Grüße --PerfektesChaos 15:23, 7. Jan. 2012 (CET)

Erstanalyse: Die zweifache Einbindung der geprüfte Datei ist eine andere Tücke; bei der großen Aufräumaktion vor inzwischen Monaten ist die Verwaltung der Regulären Ausdrücke vereinfacht worden – offenbar irgendwas irgendwo unter die Räder gekommen, möglicherweise wird die Kleinschreibung nicht mehr erkannt.

Es gibt in jedem Fall kurzfristig noch eine 0.93.

Bis dennele --PerfektesChaos 15:35, 7. Jan. 2012 (CET)

Betreffend oben erwähnter Langsamkeit: Log zur Analyse unter WP:?#Wikipedia im FF 9.0.1 sehr langsam --Leyo 19:08, 12. Jan. 2012 (CET)

0.93

Was war passiert?

• Schon vor einem halben Jahr waren Vorlagen hinter Kategorien aufgefischt und vor die Kategorien verschoben worden.
• Bei einer Restrukturierung und Vereinfachung des Skriptes ist da wohl schon vor Monaten ein Schnörkel abgebrochen.
• Ich filtere aus der (Dateibeschreibungs-)seite einen BODY und einen TAIL. Der TAIL enthält eine mögliche SORTIERUNG und mögliche Liste von Kategorien.
• Nun hatte sich irgendwie die bereits vorhandene Vorlageneinbindung hinter der letzten Kategorie versteckt und geriet in den TAIL. Die weitere Analyse arbeitet ausschließlich mit dem BODY, in dem dies nun nicht mehr sichtbar war.
• Meine Testfälle der letzten Monate waren alle selbst erzeugt worden, hatten also immer die Prüf-Einbindung der Erstprüfung vor der Kat.
• Die beiden gemeldeten Seiten hatten nach alter Art die Prüf-Einbindung hinter Kat.

Nach Abkopieren der 0.93 und Browser-Cache-Löschung müsste auch dies gehen.

Schönen Sonntag --PerfektesChaos 22:56, 7. Jan. 2012 (CET)

Der Bug scheint behoben zu sein: automatische Speicherung, nicht-automatische Speicherung. Hier allerdings wurde die Geprüft-Vorlage entfernt und zudem als Transferwunsch gelistet (Zweitfall).

Einen unerwünschten Eintrag bewirkte auch dieser Edit. Falls relevant: Zu diesem Zeitpunkt war noch Version 0.92 aktiv, die Transferwunsch-Vorlage entfernte ich manuell.

Happy Bug Tracking! ;-) --Leyo 14:04, 8. Jan. 2012 (CET)

Ich war inhaltlich seit einem Vierteljahr nicht mehr dran, hatte nur bei der Systematisierung versucht ohne Kollateralschäden die Programmierung zu vereinfachen und in meinen Testfällen nichts Auffälliges gesehen. Wird sich herausfinden lassen; Happy werde ich haben.

Nach der Options-Vorgabe „Zweitfenster“ werde ich bei dieser Gelegenheit schauen.

Nachdem ein robuster Zustand eingetreten ist, plane ich auf Steuerseiten ein zusätzliches Menüfeld „Dateiverwendung“ wie die Statusanzeige, die mit dieser auch kombiniert dargestellt werden kann. Sie wäre sowohl im lokalen Projekt wie auch auf Commons einsetzbar, wobei ein lokales Projekt aber nach meinem bisherigen Kenntnisstand keine Steuerseiten auf Commons anzeigt. Kodierung: Fette Unterstreichung des Dateinamens; blau globale Nutzung auf Commons, grün lokale Einbindung in einem lokalen Projekt, grau keinerlei Einbindung ermittelt, keine Unterstreichung = nicht ermittelbar. Dies von vornherein so geschrieben, dass das Skript auch auf Commons eingebunden werden kann; nur die entsprechend sinnvollen Funktionen würden dort wirksam.

Davor oder danach sollte eine stabile Version 1.0 nach inzwischen einem halben Jahr Entwicklungszeit einem breiteren Publikum und an einem zentraleren Ort präsentiert werden.

Schönen Sonntag noch --PerfektesChaos 14:35, 8. Jan. 2012 (CET)

Analyse fertig; Lösung erscheint trivial.

• Dass jetzt übereifrig jede Dateiprüfung als CTB gemeldet wird, beruht auf einem logischen Fehler. Es sieht so aus, als ob ich einfach nur eine Zeile jetzt erstmal auskommentieren muss, und fertig. Welche Folgen und Nebenwirkungen dies sonst noch hätte, möchte ich aber lieber erstmal überschlafen. Noch nicht verstanden habe ich, warum ich vor Monaten in der fraglichen Situation die Einreihung ausgelöst hatte.
• Dass mir dies beim Testen nicht auffiel, hing mit dem vor wenigen Tagen behobenen Bug bei leerer Warteschlange zusammen: Ich habe in meiner Spiel-Auftragsliste nur null oder eine Datei zu stehen; beim Prüfen und leerer Spiel-Warteschlange passierte einfach nix Auffälliges.

Heute kein Bugfix zum Kopieren mehr, vielleicht morgen --PerfektesChaos 23:08, 8. Jan. 2012 (CET)

0.94

• Uuups – dass ich fleißig war, hast du ja unbeabsichtigt mitgekommen; sorry für die Belästigung; mal wieder vergessen, vor 18:00 die DÜP wieder rauszunehmen.
• Ich habe alles angerichtet, was mir in meiner bescheidenen Testwelt irgend möglich war. Dann jetzt eben mal in Trippelschritten.
• 0.94 zum Kopieren in den Vollschutz bereit.
• Nach mehreren Monaten Pause haben sich bei mir die Bildchen-Abläufe auch inzwischen verfestigt, und ich kann nun in Kenntnis des Gesamtumfangs rückwärts sauberer und übersichtlicher schreiben; hoffentlich keine neuen Bugs durch die Straffung.
• Erstmal wurde nur das akute Problem beseitigt.
• Die weiteren, wenig dramatischen Kinderkrankheiten möchte ich gern auf einen stabilen Zustand aufbauen.

Bis zum nächsten Bock --PerfektesChaos 21:43, 9. Jan. 2012 (CET)

Vielen Dank! Die unerwünschten Botaufträge bleiben nun aus.

Drei kleine Fehler sind mir aufgefallen:

• Wenn die Datei in mehrere Kategorien eingeordnet ist, ergibt sich beim Umsortieren dieses unschöne Bild (egal ob mittels „Bearbeiten mit Prüfmarkierung“ oder normalem Bearbeiten und dann „Markiere als geprüft“). Nach dem oder beim Aufräumversuch hüpfte eine andere Kategorie hoch und erhielt zudem Gesellschaft.
• Wenn man bei einer zweimal geprüften Datei die noch ungespeicherten Änderungen in der Diffansicht betrachtet, steht oben im Kasten „Bisher noch nie geprüft“.
• Bei einer einmal geprüften Datei steht im Editmodus trotzdem „Bisher noch nie geprüft“.

--Leyo 00:47, 10. Jan. 2012 (CET)

1. Mehrere Kat
   • Äh, ja, ein Flag im RegExp war hier zu entfernen; obwohl ich in RegExp denke, hatte ich diesen Fall nicht betrachtet. Dürfte gelöst sein.
   • „Meine“ Testbildchen haben nur eine einzige Kat und können/dürfen auch nicht mehr haben; deshalb fiel das beim Experimentieren nicht auf.
   • Bei den geprüften habe ich Angst vorm Missbrauchsfilter und fasse echte Bilder nur ungern an. Ausführen kann ich ohnehin nichts.
2. „Bisher noch nie geprüft“
   • steht nur oben im Kasten während des Bearbeitens, richtig? – Ich schau mal. Wenn es mit dem richtigen BK gespeichert wird, hat es ja keine Eile.
   • Zu dieser Logik gab es Straffungen bei der Reorganisation; irgendein Schalterchen verschläft wohl die Existenz der Vorlage beim Bearbeiten.

Wenn es aus anderen Gründen ein 0.95 gibt, wird das geklärt sein. Ich sammel erstmal --PerfektesChaos 09:47, 10. Jan. 2012 (CET)

„Bisher noch nie geprüft“

• Analysiert; nicht direkt ein Fehler.
• Im August hatte ich die Information über bereits erfolgte Prüfungen auch beim Bearbeiten der Seitenvorschau entnommen, wie sonst der view-Ansicht.
• Wenn beim Öffnen zur Bearbeitung nicht gleich auch eine Seitenvorschau angezeigt wird, stehen auch keine Prüfer im Kasten. – Es gibt dazu eine allgemeine Benutzer-Option; ich weiß nicht so genau, ob ich im Lauf des letzten halben Jahres da selbst etwas weggeklickt hätte, meine aber, dass ich seit Jahren ein Häkchen bei „Beim ersten Bearbeiten immer die Vorschau anzeigen“ gehabt hätte.
• Inzwischen habe ich in Bezug auf dieses Skript viel dazugelernt und kann auf allerhand fertige Infrastruktur zurückgreifen. Dementsprechend werde ich das Skript erweitern und die Kategorien analysieren; enthalten sie einen Hinweis auf Datei:Geprüfte Datei, dann lohnt es sich beim Bearbeiten, im Text nach der Vorlageneinbindung zu suchen. Die Werkzeuge dazu sind bereits vorhanden.
• Übrigens kann ich als Tester die Vorlagen in den Dateibeschreibungsseiten realer Bilder nicht sehen. Bei mir heißt diese Vorlage Wikipedia:WikiProjekt Dateikategorisierung/Werkzeug/Vorlage:Geprüfte Datei.

Rettung naht --PerfektesChaos 17:49, 10. Jan. 2012 (CET)

0.95

• Betreffend Kasten „Art und Anzahl der Dateiprüfungen“
  • Funktioniert jetzt sogar auf der diffpage.
  • Kleiner Seitenhieb: Dieses weiße Dingsda versagt genauso, wenn keine Seitenvorschau an ist. Bääh! Aber ich kann es (jetzt). Ätsch!
• GROSSEN GURU ist angekommen. Die Großbuchstaben entheben elegant der Frage, ob ß oder ss. Ich möchte ja deine Augen nicht beleidigen. Nebenbei hatte dein Edit den Fingerprint 14CEF3BF invalidiert; aber das macht nichts.
• Würdest du bitte mit deiner administrativen Kompetenz dies revertieren und eine Version nebst signierter deutlicher Bemerkung herstellen?
• Einfach weiter benutzen; ich möchte mich jetzt Schrittchen für Schrittchen einer stabilen Version 1.0 nähern und nach einem halben Jahr mal einen Meilenstein erreichen.

Viel Spaß --PerfektesChaos 09:44, 12. Jan. 2012 (CET)

Beim Vorschau-Diff funktioniert dein Script, beim normalen Diff das andere. ;-) Bei letzteren ist es auch nicht wichtig. Wichtig ist vor allem, dass keine falsche Information angezeigt wird. Danke für die Umsetzung!

Ich muss gestehen, dass ich allgemein kein Fan von Änderungen der Seite nach dem Absenden bin. Ich gestalte den Quelltext jeweils genau so wie ich ihn als sinnvoll erachte. Nun ja, solche kosmetischen Änderungen sollten ausbleiben.

Betreffend Zusammenspiel mit HotCat: Wenn ich per HotCat Dateikategorien ergänze oder ändere und dann auf „Speichern“ klicke, so ich die Dateibeschreibungsseite im Editmodus kriege, erscheint dort ein Kasten mit „Markiere als geprüft“. Soweit so gut. Wenn ich darauf klicke, wird die Dateibeschreibungsseite jedoch neu geladen und alle Kategorie- oder sonstwelche Änderungen gehen verloren.

Ich fände es logischer, wenn „Speichern++“ nur in denjenigen Fällen angezeigt würde, in denen beim Klicken zusätzlich eine andere Seite bearbeitet wird. Das ist aktuell nur bei CTB der Fall.

Betreffend Revert: Könnte man die Vorlage vielleicht jeweils zum Testen reinsetzen und dann wieder rausnehmen? Alternativ könnte wohl erreicht werden, dass die Datei in Kategorie:Datei:NowCommons (Gleicher Name) immer ganz am Ende einsortiert wird.

Danke auch nochmals für deine Hilfe bei meinen FF-9.0.1-Problemen! --Leyo 02:13, 15. Jan. 2012 (CET)

• Das „normale Diff“ weckt meinen Ehrgeiz; ich muss erstmal auf die Suche nach einem solchen „normalen Diff“ gehen.
• „solche kosmetischen Änderungen“ sind keine; dies wäre ein noch zu behebender Bug. Kümmere ich mich drum. Muss erstmal herausbekommen, wie du dahin gekommen bist.
  • Mit „kosmetischen Änderungen“ sind in erster Linie gemeint: Redundante Leerzeichen; drei Leerzeilen werden zu zwei; etc. Sie sollen keine sichtbare, geschweige denn funktional wirksame Änderung sein. Allerdings gehört das Sortieren direkt angegebener Kategorien hinter den normalen Wikitext zur Kosmetik und war einmal ausdrücklich gewünscht worden.
• Ob und wann das „Speichern++“ erforderlich ist, kann das Skript erst dann herausfinden, wenn es über das „Speichern++“ tätig wurde: So könnte durch das Entfernen eines DÜP ein bislang blockiertes CTB wieder wirksam werden, oder der Admin könnte manuell eine CTB-Vorlage eingefügt haben. Wurde DÜP eingefügt, wird die Datei ggf. aus der Warteschlange wieder herausgenommen. Genau diesen Status herauszufinden macht das „Speichern++“. Das kann es aber erst hinterher im Moment des Speicherns, weil erst dann bekannt ist, was denn zum Schluss nun im Bearbeitungsfeld gestanden hat.
• HotCat, Editmodus schon geöffnet: Das soll so nicht sein; wenn es schon ein Bearbeitungsfeld gibt, soll er die Seite nicht neu laden, sondern nur in das aktuelle Bearbeitungsfeld hineinschreiben. Gucke ich mir an. HotCat taucht aber in meiner Erprobung nicht auf. – Rückfrage: Wie lautet eigentlich der action=, nachdem HotCat geöffnet hatte? edit oder submit?
• „Betreffend Revert: Könnte man die Vorlage vielleicht jeweils zum Testen reinsetzen und dann wieder rausnehmen?“ – das habe ich nicht verstanden. Welche Vorlage? Was für ein Revert?
• Kategorie:Datei:NowCommons (Gleicher Name) – Katsort ist im Prinzip möglich. Kat:NowCommons kommt aber indirekt über die Vorlage. Die Vorlage:NowCommons müsste also zum Schluss stehen. Kommen aber dahinter noch direkt angegebene Kat, dann sollen diese gemäß allgemeinen Prinzipien des Wikitextes hinter den Vorlagen stehen. Insofern wären das zwei widersprüchliche Forderungen an die Reihenfolge. Weil das aber nur Wartungskat sind und die ganze Dateibeschreibungsseite schon dem Untergang geweiht ist, geht es vielleicht auch in dieser Reihenfolge?
• Einmal mehr wiederholt: Im August/September gab es mal die erste und ausgetestete Programmierung. Nachdem wir inzwischen über 200 kB sind, war im Herbst eine interne Reorganisation fällig, bei der duplizierte Prozeduren vereinheitlicht wurden und die Abläufe damit einfacher und übersichtlicher und für gleichartige künftige Aufgaben wiederverwendbar wurden, und ein Gegeneinander von Prozeduren vermieden wird. Dabei sind allerdings möglicherweise früher schon einmal erreichte Einzelfunktionen angedätscht worden; ich kann immer nur mit den Testbildern kleine einzelne Spiele machen und arbeite ja nicht im eigentlichen Sinn mit realen Bildern und Aufgaben.
• FF 9.0.1: Gern geschehen; war mir ein Vergnügen. Genau deshalb arbeite ich weiterhin mit FF 3.6.25 …

Schönen Abend --PerfektesChaos 18:12, 15. Jan. 2012 (CET)

Zum oben genannten Bug gibt es drei neue Fälle. Ich weiss nicht, ob diese beim Bug Tracking helfen.

Mir ist aufgefallen, dass beim (erfolgreichen) Taggen mit CTB oft erst die Bestätigung und dann „Invalid request“ angezeigt wird.

Bei HotCat steht nach Klick auf „Speichern“ in der URL &action=edit.

Danke für die Erklärung von „Speichern++“. Momentan bin ich einfach wegen des oben genannten Bugs immer etwas skeptisch, ob das Script dann nicht etwas Ungewolltes anstellt. :-) Ein mögliches Feature wäre übrigens, dass man CTB im einfach einfügen kann, auch wenn die Datei vor dem Bearbeiten nicht commonsfähig scheint. Ein Beispiel wäre, wenn die DÜP erfolgreich war und die entsprechenden Vorlagen entfernt werden können. In vielen Fällen kann die Datei danach für CTB getaggt werden. Falls es zu viel Aufwand oder zu heikel ist, bastle ich mir einen Button.

Das mit dem Revert betrifft deinen zweitletzten Punkt oben.

Weshalb funktioniert eigentlich Datei-Status zeigen auf Wikipedia:WikiProjekt Commons-Transfer/Flickr nicht?

--Leyo 14:50, 31. Jan. 2012 (CET), ergänzt 10:48, 10. Feb. 2012 (CET)

• Sodele, seit sechs Wochen nicht intensiv an fileAdm dran gewesen, aber dieses Wochenende ist nass und kalt und schneefrei.
• Den Formatierungs-Bug hatte ich in den letzten Wochen immer mal wieder angegangen, kann ihn jedoch nicht reproduzieren.
  • Das mag daran liegen, dass ich aus Missbrauchsgründen nicht mit der Original-Vorlage „Geprüfte“ arbeiten kann. Mit meinem Dummy habe ich mich ziemlich verrenkt, konnte es aber beim besten Willen nicht vor die Wand fahren. Allmählich interessiert es mich.
• In der letzten Zeit hatte ich einen Schwerpunkt auf einer radikalen Umstellung von über 100 Funktionen meines WSTM, die fast unbemerkt über die Bühne ging; einen weiteren in Vorbereitung der projektweiten MediaWiki:Common.js usw. auf MW 1.19, wie du gemerkt haben wirst. Kleinkram und Disku zwischendurch geht, aber Zeitfenster, in denen ich stundenlang intensiv und ungestört tüfteln kann, sind rar.
• Wikipedia:WikiProjekt Commons-Transfer/Flickr – das ist einfach; hatten wir weiter oben schon einmal unter #Bot-Ausgabeformat und Steuer-Seite.
  • Es ist keinerlei Link auf einen Dateinamen vorhanden, das mit dem Datei-Status dekoriert werden könnte. Benötigt wird ein verlinktes Textelement, siehe Kategorie:Datei:Chemie
  • Die {{IsLocal}} müsste deshalb wie folgt verbessert werden:
    1. Statt
       Datei:{{{1}}}{{!}}{{{1}}}
       muss ein verlinkter Dateiname stehen:
       Datei:{{{1}}}{{!}}[[:Datei:{{{1}}}]]
    2. Wenn ich schon grad dabei bin: Wenn ein Bild durch Wartungsarbeiten nicht mehr existiert, platzt die Gallery-Zeile – sie muss nach Whitespace immer mit Datei: File: Image: Bild: beginnen.
       Statt dessen steht dort momentan
       ungültiger Name{{!}}{{{1}}}
       Es müsste ein Pseudo-Bild (großes rotes X oder sowas) angezeigt werden; dahinter erst der Text, etwa
       Datei:Red x.svg{{!}}''ungültiger Name:''{{{1}}}
       oder gleich mit redlink zum Löschvorgang
       Datei:Red x.svg{{!}}''ungültiger Name:''<br />[[:Datei:{{{1}}}]]
    3. Das Merl-Leyo-Gemeinschaftswerk fasse ich aber nicht an.
• CTB nach DÜP-Entfernung: Nachdem eine Vorschau durchgeführt wurde, hat das Skript völlig vergessen, dass jemals DÜP eingebunden gewesen war, und müsste die Markierung zum CTB anbieten, wenn sonst nichts dagegen spricht. Ohne Vorschau weiß es aber nicht, was sich im Textfenster geändert hat, weil es nicht jeden Tastendruck und Mausklick verfolgt.

Schönes Wochenende --PerfektesChaos 22:29, 24. Feb. 2012 (CET)

• Ich habe nochmals etwas getestet: Diese Probleme scheinen von {{subst:REVISIONUSER}} ausgelöst zu werden, ev. weil das Script dieses als Vorlage behandelt und daher verschiebt. Wenn ich es durch meinen Benutzernamen ersetze, ergibt sich kein Fehler.
• Ich habe deine Vorschläge zu {{IsLocal}} fast vollständig umgesetzt. Bei Wikipedia:WikiProjekt Commons-Transfer/Flickr funktioniert Datei-Status anzeigen „ein bisschen“: Nur die dritte Datei kriegt einen farbigen Rahmen um den Link.
• CTB nach DÜP-Entfernung: In der Vorschau ist oben ein Kasten mit Dateiprüfung // Ohne NoCommons // Noch keine Kategorie. zu sehen, aber nichts zum Markieren mit CTB.

--Leyo 19:02, 21. Mär. 2012 (CET)

• {{subst:REVISIONUSER}} – das würde erklären, warum ich das nie reproduzieren konnte. Ich füge das schlicht nicht ein.
  • Mir ist im Moment auch nicht so ganz klar, wer diese Zeichenkette wann wie einfügt. Mit welchen Arbeitsschritten bist du überhaupt dorthin gekommen; es ist eine automatische Prozedur?
  • Ohne jetzt im Detail nachgeguckt zu haben: Das Skript analysiert syntaktisch den Vorlagenparameter, und sucht wahlweise nach benutzer: oder user: und dem Benutzernamen, und gleicht den mit dem momentanen Benutzer ab. Ein {{subst:REVISIONUSER}} schmeißt diese Analyse natürlich völlig aus der Bahn.
  • Mit der Geprüfte Datei habe ich sowieso reichlich Kummer; zum Austesten nutze ich eine komplizierte Ersatzvorlage; life Testen mit den Testbildern kann ich wegen Missbrauchsfilter und Logbuch nicht.
• Nur die dritte Datei kriegt einen farbigen Rahmen um den Link. – Das liegt nicht an mir, sondern an der Antwort, die die API erhält. Wenn ich das richtig deute, handelt es sich teilweise um Dateien, die sehr frisch angekommen sind. Meiner Beobachtung nach gibt es etwas wie einen Sichtungsvorgang oder flagged rev oder sowas, der offenbar in den ersten Stunden/Tagen nach dem Hochladen ein Häkchen setzt. Irgendein Mensch oder eine Maschine macht aus dem Bild etwas Ähnliches wie eine „Gesichtete Version“, und erst dann verrät die API die Infos. Vielleicht gibt es aber auch irgendeinen Cache, der erst nach ein paar Stunden eine neue Datei kennt? Jedenfalls müsstest du dich damit besser auskennen als ich.
  • Im Übrigen habe ich mir soeben den Datei-Status anzeigen lassen und bekomme auf anscheinend allen existierenden gültigen Dateien die Farbmarkierung.
• Wenn oben ein Kasten mit „Dateiprüfung // Ohne NoCommons // Noch keine Kategorie“ zu sehen ist, dann ist der Algorithmus zu der Einschätzung gekommen, dass diese Datei lokal gehalten werden soll und nicht nach Commons transferiert werden soll (deshalb die Frage nach einer Kategorie). Um welche Datei handelt es sich denn?

Liebe Grüsse --PerfektesChaos 21:46, 22. Mär. 2012 (CET)

• {{subst:REVISIONUSER}} ist Bestandteil einer Ergänzung per Script. Nur weil HotCat→Prüfen mit fileAdm nicht klappt (siehe weiter oben), weiche ich darauf aus. ~~~~ kann nicht genutzt werden, weil die frühere Standardsignatur verwendet werden soll, also ohne Disk'seitenlink, Farben oder Bildchen…
  Bezüglich Live-Testen: Soll ich dich in die Ausnahmenliste des Filters aufnehmen?
• Das Problem mit den Dateistatus besteht weiterhin. Ich hab mir's jetzt mal in der Konsole angeschaut. Da kriege ich folgenden Fehler: getAttribute is not defined @ http://de.wikipedia.org/w/index.php?title=Wikipedia:WikiProjekt_Dateikategorisierung/Werkzeug/x.js&action=raw&ctype=text/javascript:2756
• Beispiele sind etwa Dateien in Kategorie:Wikipedia:Dateiüberprüfung/Gültige Problemangabe nachdem man den DÜP-Baustein entfernt hat und eine commonstaugliche Lizenzvorlage vorhanden ist. Weiteres Beispiel: Dateien in Kategorie:Datei:Public Domain (alt), nachdem man {{Bild-PD-alt}} in {{Bild-PD-alt|Commons=Ja}} geändert hat.

Guten Nach-Ostertage-Start! --Leyo 23:26, 9. Apr. 2012 (CEST)

0.959

• Der offenkundige Bug in Zeile 2756 war schon am 22. Februar in meiner Quelle gefixt gewesen, aber irgendwie war die Upload-Information untergegangen. Du hast gut aufgepasst; dieses Problem war unnötig, sorry.
  • Diese neueste Version habe ich jetzt unter Nummer 0.959 auf test.wikipedia.org bereitgestellt.
• Zu den Signatur-Formaten:
  1. Es gibt bereits im .review.format() irgendwas, das "~~~~" erkennt und in ein Basis-Benutzerlink ohne Signatur-Kinkerlitzchen umwandelt. Meiner Erinnerung nach müsste es also beispielsweise gehen, wenn an dieser Stelle händisch ~~~~ eingefügt werden und diese würden dann schon einfachstmöglich standardisiert, bevor die Seite abgespeichert wird und die normale Signatur-Umsetzung auf dem Server passieren würde. Allerdings habe ich das zuletzt am 7. Januar gesehen und muss mich da erstmal wieder einlesen.
  2. Genauso kann ich zukünftig immer die mir bisher nicht bekannte Variante mit {{((safe)?subst|ers):REVISIONUSER}} erkennen und jeweils durch das Basis-Benutzerlink des momentanen Bearbeiters ersetzen. Die beiden }} hinter REVISIONUSER waren wohl auch ursächlich für das von dir beobachtete Verhalten; sie waren vom Skript als das Ende der Vorlageneinbindung {{Geprüfte Datei}} interpretiert worden und haben dann natürlich perfektes Chaos angerichtet.
• Für eine angekündigte Testphase von…bis wäre eine befristete Aufnahme in den Missbrauchsfilter hilfreich, um die Test-Bilder einmal unter Originalbedingungen und nicht mit Wikipedia:WikiProjekt Dateikategorisierung/Werkzeug/Vorlage:Geprüfte Datei prüfen zu können. In diesem Zeitraum lässt sich auch schnell feststellen, ob in meinen Benutzerbeiträgen im Dateinamensraum andere Edits an Dateien stattgefunden hätten; danach würde ich aus der Prüferliste im Missbrauchsfilter wieder heraus wollen.
• In dieser Woche habe ich eine Art Osterferien oder Brückentage und mir schwerpunktmäßig mein größtes Baby mit zurzeit vermutlich über 600 kB vorgenommen. Das sollte bis zum Wochenende einen geplanten Meilenstein erreicht haben; ab der nächsten Woche werde ich mich wieder einmal in die 200 kB von fileAdm hineindenken (habe alles vergessen). Dann werde ich die Geschichte mit dem REVISIONUSER einbauen und dich über das mögliche upload der Version 0.96 informieren.

Ich habe dich (vorübergehend) in Filter 40 aufgenommen.

Die neue Version habe ich übernommen. Damit ist auch das Problem behoben. Nur hier verweigert das Script seine Dienste. Oder ist der BNR davon ausgenommen?

--Leyo 10:33, 10. Apr. 2012 (CEST)

BNR? Was ist das?

Wenn du in die letzte Bildschirmseite des Quellprogramms guckst, kannst du in fileAdm.all.fire() erahnen, dass es nur die folgenden kennt:

• case ns.nSpecial
• case ns.nProject
• case ns.nOthers1
• case ns.nFile
• case ns.nCat

In jedem anderen Namensraum steigt das Skript sofort wieder aus und macht gar nix. Oder soll der BNR dem nOthers1=100=Portal gleichgestellt werden?

Fein, dass es jetzt läuft; wenn dir weitere Unstimmigkeiten auffallen, gib Bescheid. --PerfektesChaos 10:52, 10. Apr. 2012 (CEST)

Naja, das Script würde ja nur auf Benutzer(unter)seiten mit {{Dateiwartungsseite}} aktiv. Unter Kategorie:Wikipedia:MerlBot-Listen Typ (WORKLIST) gibt es jedenfalls einige potentielle Kandidaten. Falls es Gründe gibt, die dagegen sprechen, kann ich natürlich auf diese Änderung verzichten. --Leyo 14:46, 10. Apr. 2012 (CEST)

Mir ist das relativ egal. Es ist letztlich eine Performance-Angelegenheit für die eigentlichen Anwender.

• Ich brauche nur zwei Zeilen einzufügen:
  1. eine in .all.fire()
  2. eine in .guide.action()

  ns.nUser ist aus anderen Gründen sogar schon bekannt.

• Für die Anwender soll es möglichst schnell gehen; das Skript guckt also möglichst vor der Initialisierung erstmal nach, ob in diesem NR etwas zu erwarten wäre. Wenn nicht, steigt es schnellstens wieder aus.
  • Die Folge wäre lediglich, dass auch im BNR jede besuchte Seite erst analysiert wird, ob .guide.selTemplate→#fileAdmin_Guide-collection aus Vorlage:Dateiwartungsseite oder dergleichen vorhanden ist; falls nicht, steigt das Skript ebenfalls gleich wieder aus. Das dauert Millisekunden, und dann wäre es erledigt.
  • Übrigens könnten geschwindigkeitsbewusste Anwender bereits vor dem .loader.load() eine Abfrage auf den NR machen und bei aussichtslosem NR auf das Laden der 200 kB verzichten.
• Bisher stand der BNR halt nie in Rede.

It’s up to you --PerfektesChaos 20:11, 10. Apr. 2012 (CEST)

Ich denke, es ist wohl besser, vorerst auf eine Erweiterung auf den BNR zu verzichten. Dass jede BNR-Seite durchsucht werden müsste, hatte ich nicht bedacht. --Leyo 23:34, 10. Apr. 2012 (CEST)

Ich mache mir mal Gedanken über eine schnelle Konfigurationsvariable, etwa in der Art fileAdm.opt.userpages=[]; – wenn diese nicht vorhanden ist, wird der BNR nicht beachtet, ansonsten exakt die hier angegebenen Seitentitel durchsucht. Die Seiten sollen bei Benutzern, die sie sich eingerichtet haben, dann auch analysiert werden können. VG --PerfektesChaos 23:52, 12. Apr. 2012 (CEST)

Post 1.0

Für die Zeit nach einer robusten Basisversion habe ich folgende Features vorgesehen:

• Weiteres Link auf Steuerseiten: „Dateiverwendung“
  • Globale bzw. lokale Verwendung jeder Datei wird abgefragt und wie der "Datei-Status" (auch mit diesem kombinierbar) angezeigt (verwendet: ja/nein).
• JPG-Eigenschaften
  • Über EXIF und Metadaten hinausgehende technische Informationen über eine JPEG werden auf Anforderung für ein Einzelbild ermittelt und angezeigt.
• Mehrere Dateien (eines Benutzers) gleichzeitig verarbeiten
  • Bereits teilweise implementiert (Datei-Status eröffnet zusätzliche Spalte).
  • Konkrete Ziele fehlen.

--PerfektesChaos 18:12, 15. Jan. 2012 (CET)

Reihenfolge von Kategorien und Interwikis

Könntest du die Korrektur der Reihenfolge von Kategorien und Interwikis korrigieren (Beispiel für ungewollte kosmetische Änderungen)? --Leyo 21:21, 6. Jun. 2012 (CEST)

Ojeoje, ich habe alles vergessen und stecke in der Endprogrammierung von WSTM.5 – aber ich schau mal.

Was Interwiki angeht: Ich kann mich nicht daran erinnern, da jemals was dazu programmiert zu haben; es gibt allerdings die Funktion fileAdm.edit.formatPageTail(), die darauf vorbereitet wäre, sowas zu machen.

Soll heißen: Das fileAdm kennt momentan ausschließlich Kategorien und schreibt die nach hinten; davor käme die Sortierung, und davor die GeprüfteDatei.

Interwiki wären also fileAdm bisher völlig unbekannt. Sie werden also für ganz normalen Text gehalten und folgerichtig oberhalb von GeprüfteDatei einsortiert.

Kann es denn häufiger vorkommen, dass Interwiki auftreten? Könnten die einstweilen manuell geradegeschoben werden, bis ich mich wieder tiefer in fileAdm hineindenke (oder poppen die beim Speichern immer wieder nach oben? – wäre mir zuzutrauen).

Bis demnächst --PerfektesChaos 21:57, 6. Jun. 2012 (CEST)

Danke für deine ausführliche Antwort!

Interwikis bei nicht commonsfähigen Dateien sind nicht selten. Ich würde den Anteil auf 1–5 % schätzen.

Zweiteres trifft zu: ich hatte den Interwiki manuell wieder nach unten verschoben, aber die kosmetischen Änderungen scherten sich nicht darum. Ich bin ehrlich gesagt kein Fan der kosmetischen Änderungen nach dem Speichern – oder zumindest von einigen wie der oben diskutierten. Die kosmetischen Änderungen beim Laden des Bearbeitungsmodus finde ich sinnvoller.

--Leyo 23:31, 6. Jun. 2012 (CEST)

Ich kann das Interwiki-Sortieren demnächst einbeziehen.

Leider sind die Dinger nicht trivial:

• [[wp:Artikel illustrieren]] – ist kein Interwiki
• [[en:Main Page]] – ist Interwiki
• [[CSI: Miami]] – ist kein Interwiki
• [[ALS: Houptsyte]] – ist Interwiki
• [[DOI: 10.1000/182]] – ist Pseudo-Interwiki
• [[roa-rup: Prota frãndzã]] – ist Interwiki

In WSTM analysiere ich das und kann es entsprechend in fileAdm übernehmen; das Schreiben und vor allem Testen bedarf aber ein wenig Zeit.

Grundsätzlich sind diese automatisierten Aufräumereien, wenn sie denn wissen womit zu rechnen ist, zuverlässiger als wir doofe Menschen und helfen später anderen Werkzeugen und Skripten, wenn Texte schon in standardisierter Form vorliegen.

Bis demnächst --PerfektesChaos 13:39, 7. Jun. 2012 (CEST)

Bug: Doppeledits

Kannst du dir diese Doppeledits erklären? Irgendetwas Kleines wird geändert, sonst wären es ja Nulledits. --Leyo 10:12, 5. Jul. 2012 (CEST)

Auch Schnarks diff findet kein einziges geändertes Leerzeichen oder dergleichen.

Es könnte sich um eine serverseitige Macke handeln, dies als neue Version abzuspeichern; ich meine, da im Lauf der letzten Monate mal von sowas gehört zu haben.

Sollte das ein dauerhaftes Problem sein, könnte ich per API die beiden Original-Bytefolgen herunterladen und byteweise vergleichen; aber das macht Schnark auch schon online.

Es wird zumindest in der Summe nichts hinzugefügt und nichts weggenommen; damit müsste also etwa ein Leerzeichen oder Zeilenumbruch seine Eigenschaften ändern.

Liebe Grüße --PerfektesChaos 10:35, 5. Jul. 2012 (CEST)

Danke für die Antwort! Schlimm ist's nicht, ich fand's bloss komisch. --Leyo 16:51, 5. Jul. 2012 (CEST)

Es ist mit großer Sicherheit ein aktuelles Serverproblem. Ich habe heute mehrfach dewiki-Seiten wegen schweren Datenbankproblems nicht zu sehen bekommen, auf der enWP/testwiki Speicherprobleme und eine der von mir beobachteten Seiten hat die verdächtige graue 0 und zwei Abspeicherungsversuche mit gleichem BK in einer Minute, ohne Veränderung. Wenn es dem Server nicht zu heiß ist, hätte er hier einen Nulledit feststellen müssen und kein zweites Mal abspeichern dürfen. LG --PerfektesChaos 19:11, 5. Jul. 2012 (CEST)

Vermutlich Bug 37225. Wurde schon entschärft, so dass er nicht mehr zu doppelten Einträgen führen sollte, wobei das Grundlegende Problem wohl noch nicht gelöst ist. Der Umherirrende 22:05, 13. Jul. 2012 (CEST)

Danke für die Info.

Zwei Anmerkungen, soweit ich dem Drüberschauen entnehmen konnte:

1. Es scheint jahrelang folgenlos gebliebene Missachtung von grundlegenden Sowas tut man nicht! zu geben; irgendwann rächt es sich.
   • Man greift zur Konfliktvermeidung den Satzschlüssel immer nur aus dem Master ab und nicht aus irgendwelchen Slaves.
   • Man speichert eine Satzänderung in genau einer einzigen DB-Transaktion ab.
2. In BD:Schnark/Archiv2 #Simuliertes Edit-Formular hatte ich schon einmal angemerkt, dass heutzutage eindeutig unterscheidbares lastrevid statt wpEdittime zu verwenden sei. Sekundentakt reicht nicht; dass es in der Kindergartenzeit der Wikis noch keine fortlaufende ID gab, ist keine Ausrede für die Ewigkeit.

Schönes Wochenende --PerfektesChaos 10:10, 14. Jul. 2012 (CEST)

Bug durch „Bubbles“

Wie du unter WD:DÜP#Skript zickt rum nachlesen kannst, ist auch fileAdm von der Umstellung aufs Bubble-Design betroffen, indem der Kasten oben nach einigen Sekunden ausgeblendet wird. --Leyo 00:27, 30. Aug. 2012 (CEST)

• Ich habe auf testwiki eine Version 0.965 auf dem Weg zwischen 0.96 und 0.97 zun Admin-Kopieren bereitgestellt; sie ist aber nur kursorisch und formal-technisch getestet, nicht inhaltlich. Die spontane Aktion heute hatte ich nicht im Fahrplan; parallel dazu mache ich nach und nach eine Anpassung des Quellcodes an neuere Gegebenheiten. Deshalb ist relativ viel gegenüber der letzten Version aus dem Juni verändert, ohne dass ich Gelegenheit zum Testen habe.
• Inzwischen gibt es auch eine Anfrage nach breiterem Einsatz.
• Die offizielle Version wäre dann Werkzeug.js ohne x mit der Nummer 1.0 – die x-Versionen sind zur Erprobung gedacht und können sich für die Entwicklung neuer Features häufiger ändern, während „ohne x“ stabil mit einer ausgetesten Funktionalität sein sollte; außerdem von r.js mit komprimiertem Code arbeiten.
• Die Bedienungsanleitung und Funktionsbeschreibung müsste zur Version 1.0 vervollständigt und aktualisiert werden.
• Ich weiß nichts mehr. Das ist alles ein halbes Jahr und länger her; ich kann mich an nichts mehr erinnern. Das ging irgendwie um Bilder, oder?
• Noch nicht ganz klar ist mir die Breite und Positionierung dieser Teile. Sie wurde unkonfigurierbar weltweit einheitlich festgelegt auf eine Breite von 20 Anschlägen (width:20em). Hier habe ich schon mal etwas eingegriffen. Auch die unkonfigurierbar fest programmierte Zeit von 5 Sekunden bis zum Verschwinden aller Bubbles ist eine Frechheit.

Schönen Abend --PerfektesChaos 20:36, 30. Aug. 2012 (CEST)

Vielen Dank für die schnelle Reaktion! Ich werde die neue Version des Scripts in den nächsten Tagen/Wochen testen.

Ich habe übrigens gerade Wikipedia:Dateiwartung als Übersichtsseite über den Wartungsseiten im Dateibereich erstellt. Das Script könnte man da auf einer Unterseite parkieren. Wenn ich mich richtig erinnere, hattest du mal sowas vorgeschlagen. --Leyo 21:18, 30. Aug. 2012 (CEST)

Ja, genau. Das wäre dann der Punkt für die Version 1.0, also:

WP:Dateiwartung/Werkzeug.js

Unser momentaner Gastgeber „Dateikategorisierung“ deckt die Vielfalt der Tool-Funktionen schon längst nicht mehr ab. Sobald du möchtest, kannst du mit diesem ganzen Seitenkram hier diskussionslos umziehen nach WP:Dateiwartung/Werkzeug als endgültige Adresse. Ich kann das nicht, weil die x.js mir nicht zusteht, und es sieht auch besser aus, wenn Leyo bei Dateiwartung etwas macht. C&P würde reichen; die Versionsgeschichten der Entwicklungsphase können in die Tonne. Die Beiträge sind ja signiert.

Viel Spaß --PerfektesChaos 21:26, 30. Aug. 2012 (CEST)

• (BK) Bei meinem „Schnelltest“ sehen Boxen des Scripts wieder wie vor den „Bubbles“ aus.
• Eine Bitte hätte ich noch: Sobald die Vorlage:Dateiüberprüfung vom Bot durch Vorlage:Dateiüberprüfung/benachrichtigt (Vermerk), Vorlage:Dateiüberprüfung/benachrichtigt (Text) und Vorlage:Dateiüberprüfung/benachrichtigt (Kategorie) ersetzt wurde, sollte der große Kasten mit den Checkboxen durch einen kleineren ersetzt werden: Darin könnte etwa folgendes stehen: „In der Dateiüberprüfung seit 1. August 2012.“ Das Datum ist in Vorlage:Dateiüberprüfung/benachrichtigt (Kategorie) enthalten, aber sonst auch nicht so wichtig.

--Leyo 21:33, 30. Aug. 2012 (CEST)

Naja, die grosse Kiste mit den Checkboxen steht nach der ersten /benachrichtigt dort nicht aus Langeweile: Wenn das /benachrichtigt geschehen ist, müssten die Häkchen in den betreffenden grauen, deaktivierten Feldern vorgegeben stehen (meine ich mich dunkel zu erinnern). Alle anderen Checkboxen bleiben aber operational. Fällt nun bei der zweiten Durchsicht ein anderes Problem auf, dann können die leeren Checkbox-Felder angeklickt werden und die nächste Bot-Aktion wird losgetreten. Also würde ich es lieber so belassen. LG --PerfektesChaos 21:53, 30. Aug. 2012 (CEST)

IMO ist ein Lostreter einer erneuten Botaktion nicht notwendig bzw. vorgesehen. Dass man die Checkboxen ändern kann bevor der Bot durch ist, und das Script das entsprechend anpasst, ist hingegen eine echt nützliche Funktion. --Leyo 22:10, 30. Aug. 2012 (CEST)

Wenn der DÜP-Kasten manuell (also durch Klicken auf DÜP in der Toolbox) aktiviert wird, verschwindet er nach einigen Sekunden wieder. --Leyo 00:05, 7. Sep. 2012 (CEST)

1. Ich kann dies mit keiner Skin nachvollziehen. Insbesondere werden in fileAdm sämtliche Message-Aufrufe über ein und dieselbe Funktion geleitet, so dass sich alle Boxen identisch verhalten müssen.
2. Bist du sicher, dass du das Menüfeld DÜP@fileAdm am Wickel hast und nicht DÜP@Ireas? Siehe hier.
3. Mit Dateiwartung/Werkzeug 1.0 sollten wir warten, bis HTML5 demnächst herumgeistert. Ich erwarte zwar keinerlei Auswirkungen auf JavaScript, aber das kann man nie so genau wissen und es wäre unhübsch, erst Reklame für ein neues Werkzeug zu machen und drei Tage später mit HTML5 klappt irgendwas nicht.
4. Weil ich heute sowieso auf dem testwiki bin, habe ich eine intern weiter restrukturierte Version von fileAdm bereitgestellt, die auf x.js gespielt werden sollte. An der Funktionalität ändert sich nichts; es geht nur um eine syntaktische Anpassung an aktuelle Rahmenbedingungen. Fehler sind mir dabei nicht aufgefallen, aber durch Tippfehler kann sich immer mal irgendwo eine Macke einschleichen.

Liebe Grüße --PerfektesChaos 10:14, 7. Sep. 2012 (CEST)

Ja, ich bin mir da schon sicher, dass es sich um den fileAdm-Kasten gehandelt hat. Die andern sehen ganz anders aus. Durch das Update auf die neue fileAdm-Version wurde der Fehler jedoch behoben.

Etwas anderes ist mir jedoch aufgefallen: Der Dateiprüfungskasten ist jetzt oben rechts und überdeckt so einen Teil der Seite. Wenn ich mich richtig erinnere, nahm der früher auch die gesamte Breite ein. --Leyo 11:27, 7. Sep. 2012 (CEST)

• Dann hattest du möglicherweise noch den Status quo ante im Cache. An der message-Programmierung hatte ich seit dem ersten Fix nichts geändert. Ich selbst benutze keinen Server mehr und keinen Cache, sondern lade alles direkt von der Festplatte, mit der identischen Datei, die ich auch editiere.
• Ja, die sehen anders aus; heute hatte ich zum ersten Mal eine Ireas-Box gesehen.
• Ich habe die Breite bei Dateiprüfung erstmal von 20em auf 30em gesetzt. Ansonsten ist die grüne Dateiprüfungsbox eine neumodische Bubble (das heißt, sie verschwindet beim Draufklicken und liegt ohne Ruckeln oben drüber); nur etwas breiter und mit ohne autohide nach 5 Sekunden. Das wollte ich erstmal so lassen.
• Wenn das angekündigte mw.notification stabil eingetroffen ist, werde ich mal gucken, was das taugt. Weil alle Messageboxen jetzt über die zentrale Funktion fileAdm.misc.message() geleitet werden, kann ich diese mit Leichtigkeit ummodeln. Eine Tücke bei den momentanen mw.util.jsMessage() ist wie seit Jahren, dass sie von der nächsten eintreffenden Nachricht von sonstwoher überschrieben wird.

Viel Spaß --PerfektesChaos 12:16, 7. Sep. 2012 (CEST)

Seit ca. gestern kommen wieder alle fileAdm-Boxen als Bubbles daher, sind also oben rechts und verschwinden nach ein paar Sekunden. Dies tritt an beiden von mir benutzten PCs gleichermassen auf.

Zuvor bestand übrigens das Problem, dass im Editmodus der Dateiprüfungskasten einen Teil des Eingabefeldes überdeckte. Seit gestern verschwindet nun auch dieser Kasten, was wohl einen günstigen Nebeneffekt darstellt. ;-) --Leyo 22:23, 14. Sep. 2012 (CEST)

Seit ca. gestern (vorgestern) haben wir MW 1.20wmf11, und offenkundig haben diese Scherzkekse an der bestehenden weltweiten mw-Programmbibliothek Funktionalitäten verändert; siehe WSTM. Ich werde am Wochenende detektieren gehen. Grrrrr --PerfektesChaos 22:36, 14. Sep. 2012 (CEST)

Schöne Bescherung… :-( --Leyo 22:44, 14. Sep. 2012 (CEST)

Auf testwiki jetzt eine Version, bei der ich die mit MW 1.19 zum 1. März 2012 erst neu eingeführte Message-Funktion, die in den letzten zwei Wochen zweimal die Wirkung geändert hatte, nun komplett rausgeworfen habe. Außerdem gibt es, wie am Byte-Zuwachs von 7kB erkennbar, syntaktische Erneuerung, bei der immer mal ein Tippfehler unterkommen mag. Enjoy --PerfektesChaos 21:11, 16. Sep. 2012 (CEST)

Danke. Ich habe die neue Version übernommen, aber noch nicht eingehend getestet. Ein Bug ist mir aber aufgefallen: Wenn ich bei einer Datei aus Kategorie:Datei:Nach Commons verschieben (bestätigt) auf Erneuter Transfer klicke, erhalte ich TypeError: this.bot is undefined @ 5823. --Leyo 01:03, 17. Sep. 2012 (CEST)

Durch die von dir angegebene Zeilennummer war das Malheur sofort klar; Update nach Fehler bei Syntaxumstellung (kleines Problem mit dem Bezug eines Relativpronomens). Schönen Tag --PerfektesChaos 09:16, 17. Sep. 2012 (CEST)

Das klappt nun wieder, dafür gibt's beim DÜPen noch einen Bug: [19:58:42.372] TypeError: this is undefined @ 4676 --Leyo 20:00, 17. Sep. 2012 (CEST)

Ich habe mich davon überzeugen können, dass es beim Ajax-Button nicht geht. Mir ist allerdings philosophisch völlig schleierhaft, warum er dieses this nicht mehr kennt. Ich weiß, dass eine Event-Funktion dem this eine andere Bedeutung gibt. Aber dies hier ist in der zweiten Generation, und bislang dachte ich, dass er sich hier wieder eingekriegt hätte. Es kann gut sein, dass bei anderen Ajax-Aktivitäten noch analoge Fehler auftreten. Mir sind allerdings die Testkandidaten ausgegangen. Fix ist erstmal am üblichen Platz. LG --PerfektesChaos 21:36, 17. Sep. 2012 (CEST)

Leyos Wunschliste

Ich sammle hier, welche Änderungen oder Ergänzungen ich langfristig sinnvoll/praktisch fände. --Leyo 00:56, 3. Okt. 2012 (CEST)

1. Invalid request erscheint bei CTB nicht mehr (weder am Ende noch zwischenzeitlich), obwohl es funktioniert hat.
2. Änderung vorgenommen – Aktuelle Version anzeigen verschwindet analog wie die Bubble Messages nach einigen Sekunden und es wird die aktuelle Version angezeigt. (Ich habe bei ungesichteten Dateibeschreibungsseiten schon mehrfach fälschlicherweise die zweitletzte Version gesichet.)
3. Wenn {{NC}} schon automatisch zu {{NowCommons}} geändert wird (was OK ist, aber nicht notwendig wäre), dann soll dies keine Ergänzung von „, kosmetische Änderungen“ im Bearbeitungskommentar bewirken.
4. Zusammenspiel von HotCat und Dateiprüfung verbessern: Nach dem Ergänzen von Kategorien per HotCat gelangt man in den Bearbeitungsmodus, wo die ergänzten oder geänderten Dateikategorien vorhanden sind. Beim Klick auf Markiere als geprüft sollen diese nicht verloren gehen. Auch soll der durch HotCat generierte Bearbeitungskommentar nicht durch Erste Dateiprüfung ersetzt werden, sondern darum ergänzt.
5. Der Kasten mit den verschiedenen Optionen soll bei durch den Bot substituierter Vorlage:Dateiüberprüfung (also Vorlage:Dateiüberprüfung/benachrichtigt (Text) usw.) nicht mehr gezeigt werden.
6. Weil {{Bild-PD-Schöpfungshöhe}}, {{Bild-LogoSH}}, {{Bild-PD-alt}} und {{Bild-PD-alt-100}} standardmäßig {{NoCommons}} einbinden, können sie nicht direkt mittels CTB nach Commons transferiert werden. Sie kann durch |Commons=ja umgangen werden. Analog zu DÜP, das bei nicht offensichtlich mangelhaften Dateibeschreibungsseiten in der Toolbox zur Verfügung steht, könnte dies auch bei CTB und NoCommons-Dateien gemacht werden. Bei CTB müsste zusätzlich |Commons=ja eingefügt werden. Falls eine Implementierung zu viel Aufwand mit sich bringen sollte, bitte sein lassen.

1. MessageBox-Angelegenheit? Siehe 2.)
2. Bei mir gibt es nichts dergleichen; keine 5 Sekunden mehr, keine Bubble und eigentlich kein Verschwinden. Ich habe fluchend das Message-Wesen völlig von mw getrennt und mache es unabhängig davon komplett selbst mit jQuery.
   • Aus dem gleichen Grund werde ich auch nicht mehr auf das neue mw.Api migrieren, weil die da auch schon wieder nachträglich herummachen und das Debugging bei API-Dialogen ziemlich mühsam ist.
   • Bevor ich mit dem Suchen anfange:
     • Gibt es einen zeitlichen Zusammenhang mit 1.20wmf12 vom 26. September?
     • Du bist schon sicher, dass das dieses Werkzeug hier war?
3. Schwierig. Ich sehe mich grundsätzlich verpflichtet, sowas nicht ohne Vermerk im BK zu machen, und stehe da auch in Tradition der bots.
4. HotCat ist wie LocalUsage/GlobalUsage eine größere Aktion, die ich jetzt erstmal nicht anfassen mag. Dazu müsste ich überhaupt mal HotCat aktivieren, in die Doku gucken, eine Spielwiese zum Entfernen und Hinzufügen von Kats finden, und dann im Detail die Prozesse verfolgen.
   • BK wird bereits in der Regel nur ergänzt, wenn damit gerechnet wird; das mag bei der Dateiprüfung bislang nicht der Fall sein. Vorab machbar.
5. DÜP-Kasten würde Benutzeroption für die common.js. Vorab machbar.
6. Das habe ich nicht restlos verstanden.
   • Die fraglichen Vorlagen analysiere ich nicht selbst, sondern bemerke nur die resultierende Kategorie (NoCommons).
   • Du möchtest einen Knopf haben, der sichtbar wird, wenn etwas in NoCommons einsortiert ist; wenn sich dann ergibt, dass eine der aufgezählten Vorlagen eingebunden ist, dann soll in diese |Commons=ja auf dem üblichen Dienstweg eingefügt werden?

Schönen Tag --PerfektesChaos 11:10, 3. Okt. 2012 (CEST)

Puh, meine Antwort ist ganz schön spät, auch wenn ich länger abwesend war…

1. Das hatte ich ev. etwas missverständlich formuliert: Invalid request erscheint bei CTB oft, obwohl es das nicht sollte (weil's ja geklappt hat). Ich kann dir ggf. einen Screenshot mailen.
2. Das Bubble-Messages-Problem existiert nicht mehr. Dennoch fände ich es gut, wenn nach erfolgreicher Ausführung und Bestätigung die Dateibeschreibungsseite neu geladen würde. Damit wären die Änderungen direkt (ohne manuelles Neuladen) sichtbar.
3. Im beschriebenen Fall trifft der Bearbeitungskommentar nicht zu: Bei der Bearbeitung wurde ein NC-/NowCommons-Baustein eingefügt, nichts weiter. Ob da jetzt {{NC}} oder {{NowCommons}} drinsteht, ist irrelevant. Allgemein sollten – im Gegensatz zum Zeitpunkt des Ladens des Quelltextes – beim Speichern die kosmetischen Änderungen auf ein Minimum (z. B. CTB-Baustein nach oben) beschränkt werden. Ich fühle mich dadurch vom Script bevormundet, da eine Kontrollmöglichkeit fehlt.
4. Eigentlich ist der Änderungswunsch von HotCat unabhängig: Wenn ich eine Dateibeschreibungsseite in Kategorie:Datei:NoCommons bearbeite, so erscheint oben der Kasten mit Markiere als geprüft. Nehme ich zuerst Änderungen am Seitenquelltext vor und klicke dann auf Markiere als geprüft, so gehen alle Änderungen verloren. Das Script nimmt die letzte gespeicherte Version statt den Inhalt des Bearbeitungsfensters.
5. Gut.
6. Ich denke, da kann auch darauf verzichtet werden, zumindest vorläufig.

Ich wünsche dir frohe Festtage! --Leyo 01:48, 22. Dez. 2012 (CET)

Bug bei mehreren Kategorien

Wenn ich eine Dateibeschreibungsseite, welche Vorlage:Geprüfte Datei sowie mehrere Kategorien enthält, öffne, so platziert mir fileAdm die Vorlage um, und zwar zwischen die Kategorien. Use Case: Datei:GameStar Logo.svg. --Leyo 00:41, 5. Jan. 2013 (CET)

Also, ich sehe da nur eine Kategorie-Einbindung.

Was ich nicht sehe, ist nach der runden Deutschland-Klammer die andere eckige; deshalb steht es auf der Seitenansicht unter der ganzen bunten Reklame. Damit ist es normaler Text, an dessen Ende eingefügt wird.

Ansonsten ist die Erkennung der ersten korrekten Kat-Einbindung unproblematisch; es ist egal, wie viele dann dahinter folgen. Auch beim Verschieben der Einbindung wird eigentlich keine Klammer gemopst.

Mein Eindruck ist eher, dass dir beim Editieren die irgendwie weggerutscht war. Die Reihenfolge der beiden Kat hat sich ja geändert.

Wenn dann nichts mehr kommt, kann ja langsam die öffentliche Freigabe des Werkzeugs erfolgen.

Die Benutzer-Doku habe ich mit einem Grundgerüst an wesentlichen technischen Informationen versehen. Gut wäre es, wenn du so nach und nach aus Sicht eines Anwenders die Benutzung näher beschreiben würdest.

Grüsse --PerfektesChaos 20:22, 5. Jan. 2013 (CET)

Nun habe ich die fehlende Klammer auch gesehen. Passiert muss das sein, da ich die durch ein anderes Script^* um [[Benutzer:{{subst:REVISIONUSER}}|]] ~~~~~ ergänzt hatte, was dann von fileAdm „zerrissen“ wurde, und ich beim Hinterherkorrigieren nicht alles erwischt hatte. Sorry für die Falschmeldung!

^*: Da ich bereits einige Bearbeitungen vorgenommen hatte und ich mich erst dann fürs Prüfen entschied, konnte ich nicht fileAdm verwenden ohne diese zu verlieren. Siehe dazu Punkt 4 oben. --Leyo 22:01, 6. Jan. 2013 (CET)

Bug #1 und #4

• Invalid request erscheint bei CTB oft, obwohl es das nicht sollte (weil's ja geklappt hat).
  • Das weist auf eine fehlende Paranoia-Bestätigung bei der API-Übertragung hin.
  • Im Sommer 2011 hatte ich zusätzlich zu 200 OK auch den newtimestamp abgefragt. Das ist die ultimative Bestätigung, dass die editierte Version sich nicht mit einem anderen Benutzer gekreuzt hatte. Es könnte in derselben Millisekunde jemand ebenfalls die Warteschlange bearbeitet haben.
  • Wenn du meinst, dass das trotzdem funktioniert, dann habe ich diesen Check jetzt deaktiviert.
  • Es wird in der Server-Antwort gefragt, ob die Zuweisung newtimestamp= vorkommt. Im Sommer 2011 war das immer der Fall. Vielleicht hat sich an der Programmierung der API etwas geändert. Vielleicht haben sich die Zeitabläufe geändert; der Browser zu schnell, der Server zu langsam oder zu schnell; keine Ahnung. Heutzutage scheint die Abfrage nicht mehr üblich zu sein; es wird ohnehin mit dem Zeitstempel abgeglichen, auf dem die Bearbeitung beruhte, und ein BK dürfte nicht 200 OK werfen..
  • Die Programmierung von Sommer 2011 würde ich heute nicht mehr so machen; inzwischen wurde mw.Api eingeführt. Irgendwann, wenn Version 1.0 robust läuft, würde ich zur Vereinfachung und Standardisierung darauf umstellen.
• Diese Beschreibung war dann präzise und hilfreich:

  Wenn ich eine Dateibeschreibungsseite in Kategorie:Datei:NoCommons bearbeite, so erscheint oben der Kasten mit Markiere als geprüft. Nehme ich zuerst Änderungen am Seitenquelltext vor und klicke dann auf Markiere als geprüft, so gehen alle Änderungen verloren. Das Script nimmt die letzte gespeicherte Version statt den Inhalt des Bearbeitungsfensters.

  • Dies bedurfte eines trivialen Linkfixes.
  • Das blaue Link auf „Einfügen“ im Edit-Modus war das gleiche wie wenn die Seite nur angeguckt wird; das darf nicht sein. Es gibt ein Link für den view und ein anderes für edit/submit. Weil es auch das für view war, wurde die letzte gespeicherte Version statt dem Inhalt des Bearbeitungsfensters als Grundlage verwendet.
  • Die Funktion, die das Link hinschreibt, ist am 6. Oktober 2011 zuletzt geändert worden. Irgendwann im Sommer 2011 hatte das sicher mal korrekt funktioniert; irgendwann im Frühherbst 2011 muss das Link beim Aufräumen und Vereinfachen mal die falsche Funktion zugeordnet bekommen haben.
• Bedenke, dass ich solche Admin-Skripte nicht selbst zur alltäglichen Arbeit einsetze; ich klicke wild oder gezielt mal überall drauf rum und schreibe vielleicht einen Tastaturtest in die Beschreibung. Hier hatte ich schlicht nie den Text der Beschreibungsseite geändert (wozu auch?) und deshalb immer nur den unveränderten Text benutzt; konnte deshalb den Unterschied nicht bemerken.
  • Ich bin deshalb besonders auf präzise Schilderungen angewiesen, welche Knöpfe in welcher Reihenfolge in genau welcher Situation gedrückt wurden und was genau daraufhin passiert.
  • Die Beschreibung oben nicht unter der Überschrift „Leyos Wunschliste“, sondern einzeln als „Bug“ oder „Fehlfunktion“ in einem Abschnitt hätte im Herbst 2011 gereicht.
• Neue Version wie üblich auf testwiki:User:PerfektesChaos/js/fileAdm/d.js als Ersatz; Cache-Löschung nicht vergessen.

Schönen Abend --PerfektesChaos 22:49, 7. Jan. 2013 (CET)

Das ging ja jetzt fix. Vielen Dank! Und sorry dass die Überschrift verwirrlich war…

Bei Bug #1 muss ich noch etwas mehr testen. Schon mal ein Kürzesttestbericht: Da und da wurde die Bestätigung angezeigt, da hingegen verschwand die file-AdmBox ersatzlos. Wie an Diff und Bearbeitungskommentar erkannt werden kann, musste ich bei letzterem zuerst |Commons=Ja ergänzen.

Bug #4 scheint erfolgreich behoben zu sein: Da wurden meine Änderungen mittels HotCat sowie von Hand beim Klick auf Markiere als geprüft übernommen.

Was sich hingegen zum Negativen geändert hat: var fileAdmin_multiWin = false; in meiner common.js scheint seine Wirkung verloren zu haben. So öffnet sich nun beim Klick auf ein Bild beispielsweise in Wikipedia:Redaktion Biologie/Wartungsseite lokale Bilder ein neues Fenster.

--Leyo 23:51, 7. Jan. 2013 (CET)

• CTB
  • Da geht es offenbar um Kategorien. Mit denen habe ich mich seit über einem Jahr nicht mehr beschäftigt und weiß nicht mehr, was wann warum Bild-PD-alt auslöst oder nicht. Irgendeine Logik steckt schließlich dahinter. Boxen benötigen eine Situation vorhandener oder nicht vorhandener Kategorien, um angezeigt zu werden; analog im Edit-Modus auch das Vorhandensein oder Nicht-Vorhandensein bestimmter Vorlagen.
  • Aus dem Difflink werde ich nicht schlau. Was soll es mir sagen? Nach Commons verschieben (bestätigt) ist ebenfalls ein Auslöser für die blaue Box Erneuter Transfer. Mir scheint Bild-PD-alt so definiert zu sein, dass ein Transfer nach Commons prinzipiell unerwünscht wäre. Das beruht auf deinen Angaben.
  • Es gibt irgendwo ein Fitzelchen Feature-Wunsch, zu irgend etwas |Commons=Ja hinzuzufügen. Gern, aber erst in Version 1.1 oder später.
  • #1 (Invalid request) beschäftigte sich mit einem Paranoia-Modus bei der Antwort des API-Servers und hat nichts mit Kategorien zu tun; bitte trennscharf bleiben.
• Optionen:
  • Was sagen denn deine Cookies und die Optionsseite?
  • Die Methodik, mit globalen Variablen zu arbeiten, ist zwar Wikipedia-Monobook-traditionell, aber überholt, war schon im Sommer 2011 Auslaufmodell gewesen. Dadurch werden -zig globale Variable erzeugt. Innerhalb des fileAdm-Skriptes bedarf es einer unglücklichen Konstruktion, um bei einer größeren Zahl solcher globaler Variabler diese dynamisch zu bilden.
  • Ich erwäge deshalb, auch hier noch vor der Einführung der 1.0 umzustellen auf die Zuordnung über Anwendungsobjekt für individuelle feste Vorgaben.
  • Damit lassen sich irgendwelche lose herumgeisternden Variablen direkt der Anwendung zuordnen.
  • Dementsprechend würde ich das Debugging in dieser Frage verschieben auf diese Umstellung. Vorbeugend kannst du bereits heute in deine common.js zusätzlich einfügen:

if (! mw.libs.fileAdm) {
   mw.libs.fileAdm  =  { };
}
mw.libs.fileAdm.options  =  { "miniatur": false,
                              "multiWin": false };

Schönen Tag --PerfektesChaos 10:19, 8. Jan. 2013 (CET)

Der wesentliche Unterschied ist, dass ich bei den ersten beiden Dateien auf Markiere für CTB geklickt habe („Automatik“), während da zuerst ein Bearbeiten der Dateibeschreibungsseite notwendig war. Ausgelöst wurde der Transfer dementsprechend durch den Klick auf Speichern++ und das Vorhandensein von {{Nach Commons verschieben (bestätigt)}}. Da und bei einem analogen Fall habe ich's nochmals ausprobiert. Die Bestätigung erschien für knapp eine Sekunde. Danach wurde sie durch den Kasten mit Erneuter Transfer ersetzt. Dies passiert bei der „Automatik“ nicht. Der Unterschied ist aber auch nicht weiter schlimm.

Unter Wikipedia:Dateiwartung/Werkzeug/Optionen fehlen mir bei Zielfenster die beiden Radiobuttons. Sonst sind sie überall vorhanden. Deinen Vorschlag bezüglich meiner common.js setze ich später gerne, aber ev. hast du ja noch eine Rückfrage zum aktuellen Verhalten…

Gute Nacht. --Leyo 01:09, 9. Jan. 2013 (CET)

• Die Sache mit den Boxen bei CTB hat ihre Richtigkeit und ist nur schwer zu vermeiden.
  • Wenn du die Seite anguckst (view) und dann auf den API-Knopf drückst, bleibst du auf derselben Seite und der Inhalt der Box wird je nach Ergebnis der API ausgetauscht.
  • Wenn du im Bearbeiten-Modus bist, und Speichern++ drückst, läuft die API los und meldet das auch in der zuständigen Box. Gleichzeitig schickst du aber die Seite zum Speichern auf den Server. Der Server antwortet mit einer komplett neuen Seite im view-Modus. Diese weiss nichts davon, was in der Geschichte irgendwann vorher mal in diesem Fenster passiert war, und baut aus den ihr vorliegenden Informationen den zugehörigen Kasten Erneuter Transfer auf
  • Die Trennung zwischen den beiden Seiten im Fenster hat Sicherheitsgründe im Browser und gilt allgemein. Die alte Seite (edit/submit) im Fenster ist der Adressat der API-Antwort, dass es geklappt habe oder nicht; diese Adresse existiert nicht mehr und die Rückmeldung geht ins Leere. Die neue Seite (view) darf keine Botschaften für fremde Seiten lesen.
• Radiobuttons: Sehe ich jetzt auch; habe alles vergessen und muss das nachvollziehen und debuggen. Sieht so aus, als ob für die Zielfenster-Option irgendwo ein Schlüsselwort beschädigt wäre; Tippfehler, Edit-Unfall usw.
• Die neuen Zeilen kannst du jederzeit einfügen, ohne dass dies momentan irgendeine Wirkung hätte. Die momentan von dir hinterlegte und geladene Skriptversion weiss nichts von einer solchen Komponente, kann sie nicht anfassen und auch nicht beeinflusst werden.

Beste Grüsse --PerfektesChaos 10:23, 9. Jan. 2013 (CET)

Danke für die Erklärung! Dieser prinzipielle Unterschied war mir nicht bewusst. Wäre es denn möglich, die auch im View-Modus die Bestätigungsmeldung nach wenigen Sekunden durch den Kasten Erneuter Transfer ersetzt wird? Faktisch würde dies wohl heissen, dass ein Neuladen der Seite erzwungen wird. Wenn etwas gegegen spricht, so kann man's gerne auch so lassen…

Bezüglich Radiobuttons, siehe unten. --Leyo 00:47, 10. Jan. 2013 (CET)

Bug bei DÜP

Ich ich im DÜP-Kasten einen Text eingebe und anschliessend auf Bearbeiten mit DÜP-Markierung klicke, so ist im Bearbeiten-Modus, weder der DÜP-Baustein noch der Text eingefügt worden. Als URL habe ich erhalten: http://de.wikipedia.org/w/index.php?title=Datei:Six_Pence.jpg&action=edit&fileAdm=questionable/4//*Angabe%20zum%20Alter%20der%20M%FCnze%20fehlt.*/ Wenn ich mich nicht komplett irre, hat sowas in früheren Versionen geklappt. --Leyo 18:47, 11. Jan. 2013 (CET)

Nachtrag: Es scheint am Umlaut im Text zu liegen. Mit ue statt ü klappt's. --Leyo 18:50, 11. Jan. 2013 (CET)

Gut aufgepasst, das ü ist der Verursacher.

In der URL war das ü dargestellt als %FC. Das ist zulässig (ISO8859-1), aber nicht mehr modern; unter URL-Encoding #Nicht-ASCII-Zeichen ist das beschrieben.

Ich habe umgestellt auf eine Methode, die UTF-8 bringen müsste, was für ü den Code %C3%BC liefert. Das ist das universellere Verfahren.

Die Funktionen für das Kodieren und Dekodieren sind im Browser eingebaut. Ich habe keinen direkten Einfluss darauf. Die Dekodier-Funktionen können unterschiedlich intelligent ausfallen. In den meisten Fällen ist es von der Logik her unterscheidbar. Hat das erste Zeichen einen Wert von 160 bis 191, muss es nach ISO8859-1 kodiert sein. Liegt es zwischen 192 und 255, dann wäre es UTF-8, wenn das folgende Zeichen auch Prozent-kodiert ist, und ISO8859-1, wenn das nicht der Fall ist. %FC liefert 252 für das erste Zeichen, darauf folgt ein normales n und damit ist es ISO8859-1.

Die momentane Funktion im Firefox stürzt allerdings dann komplett ab und reißt das gesamte Skript mit sich.

Fix ist abzuholen --PerfektesChaos 18:46, 12. Jan. 2013 (CET)

Vielen Dank für den Fix und die Erklärung! & im Text mag fileAdm noch nicht. Dass man sowas verwenden möchte, kann durchaus vorkommen. Gerade kürzlich habe ich eine Datei mit „Unten links steht Photo Campbell & Gray“ beDÜPt, allerdings per Vollautomatik. --Leyo 22:11, 12. Jan. 2013 (CET)

Auch das & habe ich jetzt versteckt; allerdings erstmal auf der Festplatte. Upload erst mit einem gravierenderen Bug, oder mit Version 1.0. Schönen Abend --PerfektesChaos 22:46, 12. Jan. 2013 (CET)

Danke, das klappt jetzt. Ev. könntest du dasselbe noch mit % machen. So ergibt etwa abc%20def abc def. Das könnte beim Einfügen von URLs vorkommen. --Leyo 14:43, 13. Jan. 2013 (CET)

Im Gegenteil; ich habe gerade eine Anweisung zur Dekodierung herausgenommen.

Grund: Die MW-Funktion dekodiert von sich aus. Was ich bis zu deinem Hinweis nicht wusste.

Die MW-Leute schreiben davon natürlich nix in der Doku.

Gewohnheitsmäßig hatte ich den Parameterwert von meiner Seite aus dekodiert, also zum zweiten Mal.

Wieder was gelernt. --PerfektesChaos 21:11, 13. Jan. 2013 (CET)

Ich schreib's mal hier dazu, da es ja um DÜP geht: Hier hatte ich Quelle und Urheber ausgewählt, hier Lizenz. Beides hat fileAdm nicht übernommen. --Leyo 15:40, 14. Jan. 2013 (CET)

Passte hier schon ganz gut.

An einer Stelle eine 0 durch eine 1 ersetzt, dann sollte auch dies gehen.

Fix ist abholbereit.

Enjoy. --PerfektesChaos 10:08, 16. Jan. 2013 (CET)

Nun klappt's, vielen Dank!

Etwas anderes ist aber verlorengegangen (wann kann ich nicht sagen): Bei Dateien in Kategorie:Wikipedia:Dateiüberprüfung/Gültige Problemangabe, wo also Optionen gewählt wurden, die Vorlage aber noch nicht vom Bot substituiert worden ist, werden die Häkchen nicht mehr angezeigt. Sobald Vorlage:Dateiüberprüfung durch den Bot substituiert worden ist (dadurch sind solche Vorlagen eingebunden), sollte anstelle des Kastens mit den Optionen am besten sowas wie bei NowCommons-Dateien („Transfer to Commons by Bot – NowCommons“) angezeigt werden.

--Leyo 22:10, 21. Jan. 2013 (CET)

• Häkchen: Sollten hiermit wieder aktiv werden. Die fileAdmin (2011) müssen einheitlich fileAdm (2012/13) werden, da finde ich mich sonst nicht mehr durch.
• Mit Bot und Substitution beschäftige ich mich heute abend anlässlich des Hinweis-Textes.

Angenehmen Tag --PerfektesChaos 13:10, 22. Jan. 2013 (CET)

Ja, die Häkchen sind wieder da und Taggen mit Hinweis funktioniert auch.

Der spezielle Hinweis bei Dateien, die schon „Vorlage:Dateiüberprüfung/benachrichtigt …“ enthalten, fehlt noch. --Leyo 00:02, 1. Feb. 2013 (CET)

Der hängt genauso wie die zugehörige Vorlage in der Warteschleife der WP:WVW #Erweiterung der Vorlagen der Dateiüberprüfung um einen optionalen Parameter und wartet seit 22. Jan. auf das Feedback und das endgültige Design der ersten Stufe. --PerfektesChaos 00:18, 1. Feb. 2013 (CET)

.options.multiWin

Mutmasslich gefixt.

Beim Aufräumen hatte ich alphabetisch sortiert, und dabei ohne die Folge zu bemerken die Vorgabe für .wins hinter .opt sortiert, so dass es bei Definition der lertzteren undefiniert war und dieser Zweig ignoriert wurde.

• Nicht ohne Grund heißt es auf meiner Benutzerseite: „Angemessene Lieblingskunst: Aufräumfotos von Ursus Wehrli“.

Aktualisierte Version am bekannten Ort. LG --PerfektesChaos 13:20, 9. Jan. 2013 (CET)

Danke. Ich habe die neue Version übernommen. Die Radiobuttons sind jetzt da. Auswählen und übernehmen hat jedoch keine Auswirkung (es scheint nichts gespeichert zu werden) – genausowenig wie der in meine common.js eingefügte Code. --Leyo 00:40, 10. Jan. 2013 (CET)

Okay; am 12. Oktober 2011 war die Programmierung irgendwie halbfertig abgebrochen.

Die mühsame Aktion mit einem Stapel einzelner globaler Variablen war wohl nicht mehr so ganz sauber; jetzt alles einfacher und robuster im Objekt gelöst. Scheint zu wirken.

Fix ist abzuholen am üblichen Ort.

Nach Installation und Cache-Leerung mal die Optionsseite aufsuchen.

Schönen Abend --PerfektesChaos 18:50, 12. Jan. 2013 (CET)

Kurzer Testbericht: Die Cookies werden wie gewünscht gespeichert (mittels Cookie Manager überwacht), nur scheinen diese nicht zu wirken: Trotz fileAdm_multiWin = true, fileAdm_miniatur = true und fileAdm_watchQ = nochange öffnen sich die Dateien nicht in einem neuen Fenster (was ich ja prinzipiell so möchte, aber es waren ja Testeinstellungen), werden die Miniaturbilder nicht ausgeblendet und verbleibt der Beobachtungsstatus beim DÜPen nicht unverändert. Zudem fehlen in der Toolbox die fileAdm-spezifischen Links. JS-Fehler kriege ich übrigens keine. --Leyo 22:46, 12. Jan. 2013 (CET)

Das letztere dürfte hiermit gefixt worden sein. Ursprünglich hiess es fileAdmin, inzwischen ist es einheitlich nur noch fileAdm – bei einer globalen Zeichenkettenersetzung gestern war der Ausreisser unbemerkt untergepflügt worden.

Die Beobachtung mit den Optionen kann ich nicht so recht verfolgen. Weil ich hier aber in den letzten Tagen massiv eingegriffen hatte, muss ich da heute nochmal genauer rumspielen.

Schönen Sonntag --PerfektesChaos 10:00, 13. Jan. 2013 (CET)

Einen Lapsus bei der Behandlung der Zeichenketten in der Optionsseite habe ich grad noch beseitigt.

Neuer Code a.a.O.

Bei mir läuft das mit dem Ausblenden und Einblenden und den neuen Fenstern. Ich habe jetzt alle Varianten durch. Mit watch und so kann ich mangels Ausführung echter Aktionen zurzeit wenig testen.

Viel Erfolg --PerfektesChaos 13:28, 13. Jan. 2013 (CET)

Kurzer Testbericht:

• Ja, daran daran lag's.
• Das Ein- und Ausblenden der Miniaturen klappt jetzt. Anmerkung: fileAdm_miniatur = false für Miniaturbilder anzeigen und fileAdm_miniatur = true für Miniaturbilder ausblenden ist für mich irgendwie kontraintuitiv.
• Die Steuerung des Zielfensters via Optionsseite klappt bei mir noch nicht. Es wird immer ein neues Fenster geöffnet. Die Cookies scheinen korrekt gesetzt zu werden. Die Steuerung via Link in der Toolbox funktioniert hingegen.
• Die Dateien werden der Beobachtungsliste weiterhin hinzugefügt, wenn für DÜP und CTB die Option „nochange“ gewählt wird.

Schönen Sonntag noch. --Leyo 14:55, 13. Jan. 2013 (CET)

• Ich habe ein Brückenglied woanders eingefügt, das offenbar bei der Neuorganisation der Optionen in der Technik von 2012/13 nicht oder zu früh angelaufen wurde.
• Code ist abholbereit.
• Die Logik ist für mich und das Skript relativ klar:
  • false – normale Funktion von Wiki-Portal und Browser; nicht eingreifen
  • true – aktiver Eingriff, zusätzliche oder veränderte Funktionalität
  • Durchdekliniert:
    • Miniaturbilder anzeigen → normale Wiki-Seite; keine Veränderung → miniatur=false
    • Miniaturbilder ausblenden → Wiki-Seite verändern und aktiv Ausblende-Syntax einfügen → miniatur=true
    • Link in demselben Browser-Fenster anzeigen → normales Verhalten; keine Veränderung → multiWin=false
    • Link in anderem Browser-Fenster anzeigen → Wiki-Seite verändern und aktiv Umlenk-Syntax einfügen → multiWin=true

Hoffentlich damit wieder einen Schritt weiter --PerfektesChaos 12:59, 14. Jan. 2013 (CET)

Die Logik ist mir klar und ja auch konsistent. Nur wäre es intuitiver, wenn das Schlüsselwort nominiatur, miniaturausgeblendet oder ähnlich statt miniatur wäre. --Leyo 13:33, 14. Jan. 2013 (CET)

Okay, breitgeklopft. Mit dem obigen Fix heisst das Ding lessmini, ich hoffe alle erwischt zu haben und habe auch die Optionsseite aktualisiert.

Schönen Tag --PerfektesChaos 10:10, 16. Jan. 2013 (CET)

Danke für die Änderung. Leider wird nach wie vor ein neues Tab geöffnet, was auch immer ich in Wikipedia:Dateiwartung/Werkzeug/Optionen auswähle. Auch werden mit DÜP oder CTB markierte Dateien trotz nochange beobachtet. Letzteres habe ich nur zu Testzwecken so ausgewählt, denn ich finde es sinnvoll, diese Dateien zu beobachten. --Leyo 22:22, 21. Jan. 2013 (CET)

• Möglicherweise hatte ich übersehen, den [Übernehmen]-Button aus der Wirkung von 2011 in die abgeänderte Methodik von 2013 zu [Übernehmen], damit auch die Werte der Optionsseite in die Anwendungswelt übernommen werden.
• Der neue Hinweis= wird bei DÜP wie in der Vorlagenwerkstatt gewünscht gesetzt. Rückmeldungen zur Funktion kamen dort keine; also klappt das wohl.

Geänderte Version a.a.O. abholbereit.

Schönen Abend --PerfektesChaos 23:25, 28. Jan. 2013 (CET)

Danke! Übernommen ist's, testen werde ich's demnächst einmal. --Leyo 23:41, 28. Jan. 2013 (CET) PS. Langsam wird's schwierig die „9“ zu zählen… :-)

Das damals sehr stressige RL und mein Gedächtnis hatten mir offensichtlich einen Streich gespielt. Ich dachte, ich hätte geschrieben, dass die Default-Auswahl bezüglich Fenster unverändert zu sein scheint und dass es mit dem neuen Hinweis-Parameter wunderbar klappt (herzlichen Dank nochmals). Ev. hatte ich nur auf „Vorschau“ statt auf „Speichern“ geklickt (passiert mir alle paar Monate einmal) …?

An "multiWin": false in meiner common.js wird es wohl nicht liegen, oder? Sonst hätte ja Yellowcard, der diese Option dort nicht gesetzt hat, dieses Problem nicht auch. --Leyo 23:33, 28. Apr. 2014 (CEST)

Abschluss der Experimentalphase

Nachdem mehr als ein halbes Jahr keinerlei Probleme mehr berichtet wurden, wurde am 25. August 2013 die experimentelle Entwicklungslinie basierend auf der ersten Struktur von 2011 endgültig und definitiv eingestellt.

Die ursprüngliche Implementierung musste vielerlei Basisfunktionen realisieren, die inzwischen als Standardbibliotheken verfügbar sind. Deren parallele Pflege und Weiterentwicklung ist nicht mehr sinnvoll. Bei der ersten Konzeption des Prototyps 2010/11 war auch der spätere Umfang nicht absehbar gewesen und diese nicht dafür ausgelegt gewesen.

Insbesondere die folgenden Bereiche werden grundlegend durch externe Funktionalitäten ersetzt:

• API-Kommunikation
• Verwaltung von Benutzer-Einstellungen
• Sprachversionen
• Cookies → SessionStorage

Bis Frühjahr 2014 war die Experimentalversion durch fehlenden Abschluss der 2012 bereits beendeten Version blockiert gewesen, so dass erst ab Mitte 2014 eine Experimentalversion auf Basis der geänderten Infrastruktur begonnen werden kann.

--PerfektesChaos 23:54, 25. Mai 2014 (CEST)

Statt CTB nun einfach Commonsfähig

Könnte man das Script nach dem Wegfall von WP:CTB dahingehend ändern, dass statt {{Nach Commons verschieben (Bestätigung nötig)}} bzw. {{Nach Commons verschieben (bestätigt)}} jeweils {{Commonsfähig}} eingesetzt wird? Im Script taucht „bestätig“ fünfmal auf, wovon wohl an vier Stellen die Vorlagen betroffen sind. Ich wäre froh, wenn die Änderung von jemandem gemacht werden könnte, der bessere JS-Kenntnisse hat als ich. --Leyo 23:46, 27. Nov. 2014 (CET)

@Wdwd, Yellowcard, Ireas: Euch würde ich dies zutrauen. ;-) --Leyo 14:19, 7. Dez. 2014 (CET)

Hi Leyo, danke für die Zutrauung. :) Javascript ist nur nicht so ganz meine Spielwiese.--wdwd (Diskussion) 20:11, 8. Dez. 2014 (CET)

So scheint's geklappt zu haben. Nun müssten noch die Einträge unter Wikipedia:Commons-Transfer per Bot/Anfragen vermieden werden. --Leyo 22:12, 3. Jan. 2015 (CET)