Perrypedia Diskussion:Automatisierte Änderungen

Benannte Parameter ohne Wert

Durch Zufall bei GESHOD-Spross gesehen:
{{ImageLink EA|Nummer=2908|Überschrift=|Text=''Der '''Spross''' YETO''}} {{ImageLink EA|Nummer=2924|Überschrift=|Text=''Im [[Librationsgewölbe]]''}}
Neugierdehalber mit ReplaceText gesucht nach "=|"
82 Stellen gefunden (überwiegend link=|).
Auch wenn es nicht schadet benannte Parameter ohne Wert hinzuschreiben, ist eigentlich überflüssig oder?
Einwände dagegen, dass ich das gerade ziehe? --NAN (Diskussion|Beiträge) 19:20, 25. Dez. 2018 (CET)

Nö, keine Einwände. Beachte aber, dass die Jobwarteschlange aktuell recht voll ist. --Klenzy (Diskussion) 19:57, 25. Dez. 2018 (CET)

Alles klar.

Ich lass mir ein paar Tage Zeit, ist ja nicht dringend. :-) --NAN (Diskussion|Beiträge) 20:26, 25. Dez. 2018 (CET)

Ich bin spätestenz morgen Mittag fertig. --JoKaene 20:32, 25. Dez. 2018 (CET)

Ah, und da wollte ich mal wieder den "bot" laufen lassen. ;-)

In Ernst: Hab auch schon gedacht, die 82 könnte ich auch manuell angehen. Cool, wenn Du das schon jetzt machen kannst. Vielleicht übernehme ich zwischendrin auch ein, zwei. :-) --NAN (Diskussion|Beiträge) 06:30, 26. Dez. 2018 (CET)

Ich bin jetzt mit meinem Kram durch. --JoKaene 12:08, 26. Dez. 2018 (CET)

NOTOC entfernen

Wie zuletzt unter Perrypedia:Diskussion#NOTOC diskutiert, können alle NOTOC gelöscht werden, da inzwischen ein Automatismus bezüglich Ausblenden von Inhaltsverzeichnissen greift.
Beginne mal vorsichtig damit (erstmal nur alle Artikel, die mit Aa beginnen).
Wer will, ist gerne eingeladen, mit einen Blick über die Änderungen zu werfen, um sicher zu stellen, dass keine Fehler reinrutschen. Bitte gebt dabei nicht nur negatives, sondern auch positives feedback, damit ich ein besseres Gefühl dafür bekomme, wie viele Leute mitgeschaut haben.
Wenn die Sache gut läuft, dann ändere ich immer größere Blöcke und hoffe, die Sache so noch heute durch zu bringen. --NAN s BOT (Diskussion) 10:47, 29. Jun. 2013 (CEST)

PS: Ich habe noch nicht mit den Wartungsarbeiten begonnen, das Wiki verhält sich aber auch bei "normalen" Aktionen, wie zum Beispiel dem Speichern dieses Textes, ziemlich träge, ist also wohl durch irgendetwas ziemlich ausgelastet. Wenn sich zeigt, dass der Bot seine Änderungen nur sehr langsam machen kann, stelle ich die Änderungen eventuell doch noch zurück. Mal schauen. --NAN s BOT (Diskussion) 10:49, 29. Jun. 2013 (CEST)

Alles gut. --Klenzy (Diskussion) 16:26, 29. Jun. 2013 (CEST)

Ab und an stößt man beim Kontrollieren auf Artikel, bei denen längst ein TOC links gesetzt werden hätte sollen.

Dass ist aber keine Verschlechterung durch die Änderung. Von daher auch von meiner Seite: bisher alles in Ordnung.

Gehe dann mal etwas "mutiger" vor, damit das heute noch fertig wird. :-) --NAN (Diskussion|Beiträge) 16:47, 29. Jun. 2013 (CEST)

Kann es am Bot liegen, dass die PP derzeit eine gefühlte Ewigkeit (manchmal mehrere Minuten) braucht, um eine Seite zu laden? An meiner Internetverbindung liegt's jedenfalls nicht, hab nachher getestet, Youtube geht im Vollbildmodus ruckelfrei. ;) --Andi47 (Diskussion) 17:13, 29. Jun. 2013 (CEST)

Wie gleich ganz am Anfang geschrieben (siehe oben), war das Phänomen schon vorhanden, bevor ich den bot gestartet hatte.

Und auch jetzt, wo der bot mit seiner letzten Teilaufgabe schon eine Weile durch ist, nicht mehr läuft, verhält sich das wiki immer noch träge...

Aber offen gesagt, aus früherer Erfahrung hatte ich mir da schon heute morgen gedacht "bestimmt heißt es dann trotzdem, der bot sei schuld".

Also, ich breche die Änderungen mal ab. Auf eine "andere überzeugen, dass der bot nicht Schuld ist"-Diskussion habe ich nämlich keine Lust. Setze das ganze fort, wenn das wiki mal wieder rund läuft. --NAN s BOT (Diskussion) 18:03, 29. Jun. 2013 (CEST)

ooops, sorry, hab ich übersehen, dass die Antwort auf meine Frage schon ein paar Zeilen weiter oben steht. Ich wollte aber auch nicht eine Behauptung in die Welt setzen, sondern einfach mal fragen, ob es daran liegen kann. Da der Bot zum fraglichen Zeitpunkt anscheinend noch nicht aktiv war, und es trotzdem 3-5 Minuten gedauert hat, um irgend eine Seite geladen zu bekommen: Weiß jemand, was die PP so ausgebremst hat? --Andi47 (Diskussion) 21:41, 29. Jun. 2013 (CEST)

Der einzige, der Dir so eine Frage eventuell (lässt sich ja nicht immer sooo klar sagen) beantworten könnte wäre Poldi. Versuch doch mal, ihn direkt auf seiner Benutzerseite anzusprechen. --NAN (Diskussion|Beiträge) 06:25, 30. Jun. 2013 (CEST)

"Letzte Änderungen" erscheinen inzwischen wieder fast sofort. Was auch immer das wiki belastet hatte, ist aktuell nicht mehr vorhanden. Ich setze die Änderungen fort. --NAN (Diskussion|Beiträge) 06:25, 30. Jun. 2013 (CEST)

PS: Diesen Beitrag zu speichern hatte trotzdem gerade mehr als 10 Sekunden gedauert (bot läuft noch nicht). Nehme aber mal die "Letzten Änderungen" und das "Artikel öffnen" als Maßstab und starte dann den bot erneut. --NAN (Diskussion|Beiträge) 06:28, 30. Jun. 2013 (CEST)

ca. 10 Sekunden kann ich bestätigen, z.T. ein bisschen schneller, d.h. die Verzögerungen sind nicht schlimmer geworden. Ich gehe mal davon aus, dass Dein Bot bereits läuft, somit kann man IMHO entgegen meiner gestrigen Befürchtung annehmen, dass der Bot im Hinblick auf die Belastung der Datenbank harmlos (und somit unschuldig :-) ) ist. Ich hab Poldi trotzdem mal angeschrieben, vielleicht kann er herausfinden, was gestern die PP in die Knie gezwungen hat. --Andi47 (Diskussion) 07:05, 30. Jun. 2013 (CEST)

Die Änderungen sind durch. --NAN (Diskussion|Beiträge) 10:53, 30. Jun. 2013 (CEST)

Danke, NAN. Gute Arbeit. --GolfSierra (Diskussion) 13:21, 30. Jun. 2013 (CEST)

Ich sag ebenfalls danke! --Andi47 (Diskussion) 14:15, 30. Jun. 2013 (CEST)

Dank an Klenzy, für die Unterstützung. :-) --NAN (Diskussion|Beiträge) 07:04, 1. Jul. 2013 (CEST)

Auflösung Pipelinks

Als nächstes möchte ich die unnötigen Pipelinks bearbeiten, also wenn vor und nach dem Pipe dasselbe steht. Hiervon insbesondere diejenigen, die aus zweigeteilten Begriffen bestehen und vor dem Pipe ein Leerzeichen, nach dem Pipe aber ein   enthalten. Das sieht dann so aus:

\[\[([^\]]+) ([^\]]+)\|\1( | )\2\]\]

durch

[[$1$3$2]]

Das würde dann etwa Ende nächster Woche steigen. --Klenzy (Diskussion) 14:22, 18. Apr. 2013 (CEST)

Erledigt. --Klenzy-Bot (Diskussion) 15:27, 13. Mai 2013 (CEST)

Lessons learned

Obacht bei Verwendung von \b = Word boundary. Deutsche Umlaute werden als Word boundary eingestuft. Siehe http://www.perrypedia.proc.org/mediawiki/index.php?title=Perry_Rhodan-Quartett&diff=901967&oldid=858715. --Klenzy (Diskussion) 12:33, 7. Apr. 2013 (CEST)

Zeilenumbruch bei Raumschiffsnamen vermeiden

Die folgende Textersetzung soll die bisher einzeln und ohne Regex durchgeführten Änderungen von JoBot pauschal für alle Raumschiffsnamen mit lateinischen Ordinalzahlen durchführen:

\b([-A-Z]+)( | )([IVXLCM]+)\b

durch

$1 $3

Einwände? Falls nein, plane ich den Lauf nächstes Wochenende ein. --Klenzy-Bot (Diskussion) 18:53, 30. Mär 2013 (CET)

Zeilenumbruch bei Galaxien vermeiden

Die folgende Textersetzung soll die bisher einzeln und ohne Regex durchgeführten Änderungen von JoBot pauschal für alle Galaxien durchführen:

(?<!:)\b(M|NGC|IC|HCG|UGC|PGC) ([0-9]+\b)(?![^\]]*\|)

durch

$1 $2

Einwände? Falls nein, plane ich den Lauf am Osterwochenende ein. --Klenzy-Bot (Diskussion) 14:26, 22. Mär 2013 (CET)

Erledigt. --Klenzy-Bot (Diskussion) 18:49, 30. Mär 2013 (CET)

Textersetzung PR Neo-Links

Klenzy hat unter Benutzer Diskussion:JoKaene#Textersetzung PR Neo-Links eine Textersetzung der vorhandenen pipe links für Neo-Artikel vorgeschlagen:
Suchmuster: \[\[(.*)\(PR Neo\)\|(.*)\]\]
Zielmuster: {{PRNA|$1|$2}
Das wurde von JoKaene etwas verfeinert, um überflüssige Leerzeichen zu vermeiden: Suchmuster: \[\[(.*) \(PR Neo\)\|(.*)\]\] Zielmuster: {{PRNA|$1|$2}
Erkanntest Problem: [[Sid González (PR Neo)|Sid González]] --> {{PRNA|Sid González|Sid González}}
Sollte eigentlich sein: [[Sid González (PR Neo)|Sid González]] --> {{PRNA|Sid González}}
Die originale ReplaceText-Extension bietet eine zu eingeschränkte Form der RegEx, um das Problem wirklich zu behandeln.
Daher hat Poldi im Testwiki eine Erweiterung für MySQL installiert und die Extension angepasst. --NAN (Diskussion|Beiträge) 07:22, 1. Mär 2013 (CET)

Weiteres Problem: [[Sid González (PR Neo)|Sid González]]es (schlechtes Beispiel, nur vom Prinzip her: Der Link kann auch nach den eckigen Klammern weitergehen.

Eine mögliche Lösung: Zwei Schritte, erst alle Links, die mit ]] zu Ende sind, dann die anderen. --NAN (Diskussion|Beiträge) 07:29, 1. Mär 2013 (CET)

PS: Ist doch kein Problem, da auch z.B. {{PRNA|Wega}}s (Wegas) funktioniert. Ist nur die Frage, ob wir das eventuell einheitlich als {{PRNA|Wega|Wegas}} (Wegas) geschrieben haben möchten, oder einheitlich wenn möglich in der ersten Form, oder ob uns in diesem Fall Einheitlichkeit egal ist.--NAN s BOT (Diskussion) 08:06, 1. Mär 2013 (CET)

Backreference funktioniert dank der Erweiterung von Poldi (Suche und ersetzen):

siehe hier. --NAN (Diskussion|Beiträge) 07:35, 1. Mär 2013 (CET)

Das Ergebnis ist erst mal klasse. Wie von dir vorgeschlagen, habe ich nur die Funktion regexCond angepasst.

        private function regexCond( $dbr, $column, $regex ) {
                if ( $dbr instanceof DatabasePostgres ) {
                        $op = '~';
                } else {
                //Neuen Operator verwenden. Nun nicht mehr mysql REGEXP.
                        $op = 'PREG_RLIKE'; 
                }
                //Die Regex muss im Perl-Syntax vorliegen. Daher mit / einschließen.
                $regex = "/" . $regex . "/"; 
                //PREG_LIKE braucht eine andere Reihenfolge der Parameter
                return " $op ( " .  $dbr->addQuotes( $regex ) . "," . $column . ")"; 
                //return "$column $op " . $dbr->addQuotes( $regex );
        }

Um das Ersetzten hatte ich mich noch gar nicht gekümmert. Wollte ich erst heute machen. Aber wenn es ja jetzt auch schon funktioniert, dann wird die Anpassung auf PRE deutlich einfacher als gedacht (und gehofft). --Poldi (Diskussion) 08:15, 1. Mär 2013 (CET)

Bei sehr komplexen Abfragen könnte jetzt theoretisch zum Tragen kommen, dass Suche und Ersetzen (schon immer und auch vor Deiner Erweiterung) in der Extension auf unterschiedliche Mechanismen zurückgreifen. Früher war das lediglich deswegen keine Möglichkeit, da wegen der Einschränkungen beim Suchen schlicht keine komplexen Abfragen möglich waren.

Von daher würde ich auch mit den neuen Möglichkeiten tendenziell eher mit mehreren Änderungsschritten als mit hochkomplexen Suchmustern arbeiten. Aber selbst dann bringt uns die Möglichkeit Backreferences zu nutzen (was an und für sich ja noch nicht hochkomplex ist ;-) ) sehr viel.

Danke, Poldi. :-)

Denke, Klenzy wird wahrscheinlich im Testwiki eine ganze Reihe von Tests bezüglich dem Ersetzen machen? Das dürfte im Testwiki genügend Sicherheit geben, dass wir die Erweiterungen auch im Hauptwiki einführen? --NAN (Diskussion|Beiträge) 08:32, 1. Mär 2013 (CET)

Zusätzliche Tests sollten wir auf jeden Fall machen. Im Testwiki ist auch noch die Ausgabe für SQL-Fehler aktiv. Wenn ihr auf einen Fehler stoßt, dann notiert euch bitte das SQL-Statement. Dann können wir besser prüfen, ob noch ein Programmfehler vorliegt oder ob die Syntax der Regex falsch ist. Ich hoffe aber, dass ihr keine Fehler findet. Denn bei einer größeren Fehlersuche und Programmierung muss ich passen. Ich kann eigentlich kein PHP. Also hoffen wir das Beste ;-) --Poldi (Diskussion) 09:50, 1. Mär 2013 (CET)

Vorlage:PRNA wurde von mir zwischenzeitlich so erweitert, dass das zweite »|« nur noch gesetzt werden muss, wenn wirklich auch ein zweiter Parameter vorhanden ist (also nicht mehr z.B. {{PRNA|Wega|}} sondern nur noch {{PRNA|Wega}}; für Anwendungsbeispiele siehe Vorlage:PRNA)
Bestehende Links wurden von mir per ReplaceText angepasst. --NAN (Diskussion|Beiträge) 08:47, 1. Mär 2013 (CET)

Huh? Ihr habt jetzt eben mal die ReplaceText-Extension umprogrammiert...? *Ehrfürchtiges Erstarren* und mächtigen Dank für euren Einsatz!

Ich mache gern weitere Tests, benötige dafür bitte den Bot-Status im Testwiki.

Wg. {{PRNA|Wega}}s: Diese Möglichkeit sollten wir schon nutzen, analog [[Wega]]s. Es muss ja nicht gleich eine eigene Regel zwecks Einheitlichkeit geben, bei den »normalen« Links funktioniert es auch auf freiwilliger Basis. Wenn es denn Fälle wie {{PRNA|Wega|Wegas}} gibt, tun die niemandem weh. --Klenzy (Diskussion) 10:09, 1. Mär 2013 (CET)

Erledigt. --Poldi (Diskussion) 10:18, 1. Mär 2013 (CET)

Wo wir schon dabei sind, könnt ihr vielleicht kurz auch mal Windows umprogrammieren? Ist total ärgerlich, dass in jedem Edit-Fenster die Texte logischerweise linksbündig stehen, aber die Scrollbars immer ganz rechts sind. Ich hätte die Scrollbars gern links... :-D --Klenzy (Diskussion) 10:24, 1. Mär 2013 (CET)

Du stellst dir das viel zu kompliziert vor :-) Es war wirklich keine Kunst, da nur an einer Stelle eine Kleinigkeit geändert werden musste. Aber bezüglich Windows muss ich dich enttäuschen. Da kann nur ein Wunder helfen ;-))

Wenn Du weitere Tests durchführst, dann beachte bitte, dass die Regulären Ausdrücke nun dem Syntax von Perl entsprechen müssen. --Poldi (Diskussion) 10:51, 1. Mär 2013 (CET)

Hölle, ist das Zeug gefährlich. Da schießt man schnell einen Bock. ».*« ist gnadenlos jedes Zeichen und so liefert \[\[(.*) \(PR Neo\)\|(.*)\]\] --> {{PRNA|$1|$2}} ein unvermutetes Ergebnis: [1]. Ich lerne daraus: 1. testen, testen, testen. 2. bei .* immer misstrauisch sein.

Mit [^\]]* ist es wesentlich ungefährlicher.

Ich wär' dann so weit: Tests im Testwiki ok! --Klenzy (Diskussion) 13:44, 1. Mär 2013 (CET)

Der Plan sieht also wie folgt aus:

1. \[\[([^\]]*)( |& nbsp;)\(PR Neo\)\|\1\]\] --> {{PRNA|$1}} (alle die vor und nach dem Pipe denselben String haben)
2. \[\[([^\]]*) \(PR Neo\)\|([^\]]*)\]\] --> {{PRNA|$1|$2}} (alle übrigen)

beides mit Einschränkung auf Kategorie:Perry Rhodan Neo.
Ok? --Klenzy-Bot (Diskussion) 16:01, 1. Mär 2013 (CET)

Die Erweiterung ReplaceText versteht nun die Syntax von PCRE. --Poldi (Diskussion) 21:41, 19. Mär 2013 (CET)

Besten Dank! --Klenzy-Bot (Diskussion) 13:29, 22. Mär 2013 (CET)

Und erledigt. --Klenzy-Bot (Diskussion) 13:52, 22. Mär 2013 (CET)

Form des Erscheinungsdatums

Ausgehend von dieser Diskussion scheint der Wunsch zu bestehen, dass bei den Heftzusammenfassungen das Erscheinungsdatum in der Form Freitag, 15. Februar 2013 dargestellt wird.
Dies lässt sich ohne großen Aufwand automatisiert umsetzen und wie angekündigt, möchte ich es heute erledigen. Ohne ein »Letzte-Minute-Veto« werde ich im Laufe des Nachmittags damit beginnen. --JoKaene (Diskussion) 11:21, 16. Feb. 2013 (CET)

Du gehst wahrscheinlich Tag für Tag durch und machst eine Ersetzung ohne regex in den Kategorien "Atlan-Heftroman", "Perry Rhodan-Heftroman", ... (siehe Kategorie:Handlungszusammenfassung)?

Werde auch ab und an reinschauen und die Rolle des zweiten Paars Augen übernehmen. --NAN (Diskussion|Beiträge) 11:49, 16. Feb. 2013 (CET)

Genau, so habe ich es vor. Werde vorher im Testwiki noch »üben«. --JoKaene (Diskussion) 11:56, 16. Feb. 2013 (CET)

Um 15:00 Uhr fange ich an. --JoKaene (Diskussion) 14:29, 16. Feb. 2013 (CET)

Bin online. --NAN (Diskussion|Beiträge) 15:06, 16. Feb. 2013 (CET)

Alle Stichproben bis jetzt schauen - wie nicht anders zu erwarten, aber um es gesagt zu haben ;-) - gut aus. :-) --NAN (Diskussion|Beiträge) 16:06, 16. Feb. 2013 (CET)

So, ich bin durch. Habe dabei festgestellt, dass es auch Datumsangaben ohne genannten Wochentag gibt. Die sind natürlich nicht bearbeitet worden. Insgesamt wurden gut 2700 Änderungen vorgenommen. --JoKaene (Diskussion) 16:24, 16. Feb. 2013 (CET)

PS: Danke NAN für Deine Kontrolle. Ich habe ebenfalls keinen Fehler entdeckt. --JoKaene (Diskussion) 16:28, 16. Feb. 2013 (CET)

Danke für die Änderungen. :-) --NAN (Diskussion|Beiträge) 16:34, 16. Feb. 2013 (CET)

Gern gemacht. :-)

Jetzt nochmal genau geprüft: Bei 3156 von 4488 Handlungszusammenfassungen entspricht die Datumsangabe nun dem gewünschten Format. --JoKaene (Diskussion) 16:48, 16. Feb. 2013 (CET)

Mögliche Automatisierung bei der Einführung von SMW

Welche Möglichkeiten gibt es eigentlich, für die eventuelle Einführung von Semantic MediaWiki (SMW) unser Textersetzungstool einzusetzen? Folgende Punkte fallen mir im Moment ein:

• Es ließe sich eine an eine spezielle Kategorie angepasste Factbox-Maske an das Ende aller Artikel/Redirects dieser Kategorie anhängen.
• Diese Factbox sollte zunächst auskommentiert (<!--FACTBOX-->) sein, damit sie, solange sie nicht mit Daten gefüllt ist, das Erscheinungsbild des Artikels nicht beinträchtigt.
• Damit sich die Auskommentierung problemlos auch automatisiert wieder entfernen lässt, kann man ihr eine spezifische Zeichenkette hinzufügen. Beispielsweise: <!--factboxanfang-FACTBOX-factboxende--> (Nur notwendig, wenn sich Attribute-Daten automatisiert eintragen lassen).
• Zusätzlich zur Factbox könnte man eine noch zu erstellende Kategorie (z.B. [[Kategorie:Leere Factbox]]) anhängen. Sobald Daten eingetragen sind, wird die Kategorie wieder gelöscht und ermöglicht über die Kategorieseite einen Überblick, wo entsprechende Einträge noch fehlen.
• Frage: »Lassen sich Daten zu den Attributen automatisiert eintragen?« Zum Beispiel ein Übertrag aus bereits bestehenden Listeneinträgen?
• Wenn ja, muss auch die automatisierte Entfernung der Auskommentierung und der [[Kategorie:Leere Factbox]] nur bei den bearbeiteten Artikeln sichergestellt werden.

Sicher habe ich irgendwas außer Acht gelassen, aber falls SMW eingeführt wird, sollten wir mal die Vorgehensweise definieren und die Möglichkeiten einer zumindest eingeschränkten Automatisierung ausloten und dokumentieren. --JoKaene 12:24, 24. Sep. 2012 (UTC)

ImageLink-Anpassungen nach Änderung der Lage der Titelbilder

Ausgangslage:

Nach der Neugestaltung der PR-Website liegen die Titelbilder nicht mehr dort, wo sie früher lagen.

Als erster Schritt wurden die Vorlagen für die Heft-Romane angepasst/erweitert, damit zumindest dort die Titelbilder wieder angezeigt werden.

Im Zuge dessen entstand auch die Vorlage:ImageLink EA als weitere Kapselung für den Zugriff auf die Titelbilder.

Es exitieren nun viele Artikel, in denen ImageLinks auf EA-Titelbilder angelegt wurden.

Alle diese ImageLinks funktionieren aktuell nicht mehr, da die dort angegebene URL nicht mehr stimmt.

Diese Links müssen angepasst werden.

Optionen:

1. Am einfachsten wäre, die URL anzupassen und wieder die Bilder von der PR-Website anzeigen zu lassen. Allerdings würden die dann deutlich zu groß angezeigt werden. Aufwand (hoffentlich ;-) ) minimal.
2. Die Links innerhalb der ImageLinks könnten auf Zugriff auf lokal in der PP gespeicherte Bilder umgestellt werden (siehe Perrypedia:Diskussion#Genehmigung zur Coverübernahme ist erteilt!, Poldi hat sich die Arbeit gemacht, die Bilder hochzuladen). Es würde weiter die Vorlage:ImageLink-alt genutzt. Die Größe des "kleinen" Bildes müsste in jedem Link festgelegt werden (wir müssten uns im Vorfeld darauf einigen, würde 240px vorschlagen, da das gerade bei den Handlungszusammenfassungen der EA üblich ist). Aufwand: Ähnlich wie bei Option 1.
3. Die ImageLinks könnten auf Vorlage:ImageLink EA umgestellt werden. Persönlich halte ich das für besser (siehe Diskussion:Die geträumte Welt für Argumente/Gegenargumente). Aufwand/Komplexität der regex: definitiv höher als bei den anderen beiden Varianten.

Meine Meinung: Da ich nun mal von Option 3 überzeugt bin, denke ich, das wäre den aufwand wert und würde mich da auch reinknien.
Als Kompromiss könnte ich mir aber vorstellen (da Option 3 einfach auch Zeit kostet) erstmal "schnell" Option 2 umzusetzen und dann erst in aller Ruhe auf die in meinen Augen langfristig bessere Option 3 zu ändern. Denke wäre für unsere Leser die beste Lösung. --NAN (Diskussion|Beiträge) 07:00, 11. Jul. 2012 (UTC)

Ich denke, Option Nr. 1 sollten wir ausschließen.

Wenn sich mit Option 2 relativ schnell erreichen lässt, dass die Cover (Innenillus sind dabei ja noch nicht miteingeschlossen) wieder angezeigt werden, sollten wir das auch zunächst umsetzen. Letztendlich sehe auch ich die Umstellung auf Vorlage:ImageLink EA (Option 3) als die beste und sinnvollste Möglichkeit an. Einer Imagegröße vo 240px stimme ich zu. --JoKaene 07:29, 11. Jul. 2012 (UTC)

Fange mal mit der technischen Ausarbeitung von Option 2 an. --NAN s BOT 10:08, 11. Jul. 2012 (UTC)

Technische Ausarbeitung

Für Titelbilder der EA gab es früher zwei prinzipielle Links:

[http://perry-rhodan.net/pics/tibis/0675tibi.jpg http://perry-rhodan.net/pics/tibis/178/0675tibi.jpg]

[http://perry-rhodan.net/pics/tibis/2198tibi.jpg http://perry-rhodan.net/pics/2/2198tibi.jpg]

Um auf wie oben unter Option 2 beschrieben die intern gespeicherten Bilder umzustellen, müssen die Links gefunden werden und durch einen Link der Form

[[Datei:PR0675.jpg|240px]]

ersetzt werden. Ob die Links tatsächlich innerhalb eines ImageLinks sind oder nicht, sollte gleichgültig sein.

--NAN s BOT 10:08, 11. Jul. 2012 (UTC)

Muster für Originaltext (Form 1)

\[http:..perry-rhodan.net.pics.tibis.([0-9][0-9][0-9][0-9])tibi.jpg http:..perry-rhodan.net.pics.tibis.178.([0-9][0-9][0-9][0-9])tibi.jpg\]

Die »/« hätten jeweils mit einem »\« maskiert werden müssen, war mir zu viel aufwand, habe ».« daraus gemacht. Das ist zwar genau genommen nicht richtig, da ».« für ein beliebiges Zeichen steht, aber ist doch recht unwahrscheinlich, das zwischen den gegeben Zeichen irgendwas anderes als »/« steht. Muss man also nicht sooo genau nehmen. Aus dem gleichen Grund habe ich den Punkt für »jpg« nicht maskiert.

Über die ([0-9][0-9][0-9][0-9]) kommen wir an die Zahl, die glücklicherweise bereits eine führende 0 hat und so ergibt sich als Muster für die Ersetzung:

[[Datei:PR$1.jpg|220px]]

Getestet bei Monument der Macht, History (habe geschaut, das Bild war auch vor der Änderung so ungünstig angeordnet) und Hisso Rillos.

Bitte schaut Euch auch die Größe an, vielleicht ist kleiner doch besser?--NAN s BOT 10:31, 11. Jul. 2012 (UTC)

Vielleicht etwas zu groß. 200px erschien mir schon fast zu klein. 220px würde mir gefallen. --JoKaene 10:41, 11. Jul. 2012 (UTC)

Habe mal in allen betroffenen Artikeln auf 220px geändert (und auch die bisher genannten Muster für die Ersetzung hier angepasst). Finde auch, dass das besser aussieht. --NAN s BOT 10:51, 11. Jul. 2012 (UTC)

Muster für Originaltext (Form 2)

\[http:..perry-rhodan.net.pics.tibis.([0-9][0-9][0-9][0-9])tibi.jpg http:..perry-rhodan.net.pics.2.([0-9][0-9][0-9][0-9])tibi.jpg\]

Muster für die Ersetzung:

[[Datei:PR$1.jpg|220px]]

Getestet bei Hismoom. Link auf Innenillustration wie zu erwarten weiter nicht funktionsfähig, Titelbild wird nun aber angezeigt.

Man könnte die beiden Suchmuster natürlich vereinfachen und einigermaßen elegant beide Fälle in einem behandeln.

Bin mir aber nicht sicher, ob das die Gefahr von false positive erhöhen würde. Vielleicht ist dem nicht so, aber einfach um die Zeit zu sparen, die es kostet, diese Möglichkeit zu untersuchen, würde ich vorschlagen, ReplaceText einfach zweimal laufen zu lassen, einmal mit dem ersten Muster und dann mit dem zweiten Muster. --NAN s BOT 10:46, 11. Jul. 2012 (UTC)

False positive kann ich nicht abschätzen. Macht ein Testlauf in der 2.PP Sinn? Ansonsten stimme ich Deinem Vorschlag (zwei Durchgänge) zu. --JoKaene 10:55, 11. Jul. 2012 (UTC)

Kostet halt Zeit, nur um sich dann wieder nicht gaaanz sicher zu sein.

Denke nachdem die ersten paar Tests sehr gut liefen, können wir einfach in der 1.PP (;-)) loslegen. Wie bei anderen Aktionen auch am Besten Buchstabe für Buchstabe. Die ersten ein, zwei Läufe/Buchstaben können wir jeweils komplett prüfen, danach Stichproben nehmen. --NAN s BOT 11:10, 11. Jul. 2012 (UTC)

Bin Einverstanden. Aleerdings bin ich jetzt für etwa zwei Stunden offline. Falls Du gleich beginnen möchtest, kann ich erstmal nicht mitkontrollieren. --JoKaene 11:16, 11. Jul. 2012 (UTC)

Melde Dich einfach, wenn Du Zeit hast. :-) --NAN s BOT 12:00, 11. Jul. 2012 (UTC)

Bin wieder da - und bereit. --JoKaene 12:40, 11. Jul. 2012 (UTC)

Cool. :-)

Beginne mit Form 1.

Habe einen weiteren Test mit allen Artikeln gemacht, die mit "Ab" beginnen (waren drei). Sah gut aus.

Habe nun die Änderung für alle Artikel, die mit "A" beginnen angestoßen. --NAN s BOT 13:43, 11. Jul. 2012 (UTC)

Wirf mal einen Blick auf Asteroidenstadt. --JoKaene 13:52, 11. Jul. 2012 (UTC)

Sorry. Textersetzung war korrekt, der Fehler war vorher. --JoKaene 13:55, 11. Jul. 2012 (UTC)

Speicherkonflinkt, bringe mal trotzdem den Text:

Deine Änderung ist mir gerade aufgefallen.

Bin noch irgendwo mitte drin beim überprüfen der 53 Änderungen. Sieht so weit so gut aus.

Lediglich bei den Sonderfällen, in denen mehrere Bilder mit einem ImageLink nebeneinander angeordnet wurden (wofür ImageLink eigentlich ohnehin nicht geeignet ist, aber man kann tricksen ;-) ), sieht der Text darunter aufgrund der neuen Größe etwas ungünstig aus.

In einem Fall waren zwei ImageLinks nebeneinander, der eine bereits zuvor auf intern und 178px, der andere durch die Umstellung auf 220px, habe beide auf 220px geändert.

Sind denke ich aber Fälle, die nicht so wild sind. Hauptsache wir zeigen die Bilder wieder an und das Ganze wird später ohnehin besser wenn wir auf eine zentrale Vorlage umstellen. --NAN s BOT 14:05, 11. Jul. 2012 (UTC)

Alles kontrolliert, keine Fehler gefunden. Bestätige hiermit auch noch mal, das die gewählte Bildgröße ganz gut passt. --JoKaene 14:02, 11. Jul. 2012 (UTC)

Stimme Dir bezüglich der Bildgröße zu. Sieht man wenigstens, was auf dem Bild ist.

Dürfen aber nicht vergessen, dann später mal auch alle Atlan-Titelbilder entsprechend anzupassen. Die sind aktuell ja bereits intern verlinkt und z.B. im Artikel Atlan da Gonozal auf 180px.

Aber denke das kann warten, bis wir auf eine entsprechende Vorlage umstellen. --NAN s BOT 14:09, 11. Jul. 2012 (UTC)

Diesmal hatte ich den Speicherkonflikt. ;-)

Ich denke auch, dass wir uns um die Sonderfälle (Darstellung nebeneinander) später kümmern können, die Wiederherstellung erscheint mir zunächst wichtiger. Wo mehr als ein Bild korrigiert wird ist an der höheren Byte-Zahl erkennbar und so leicht zu finden. Dem kann man dann größere Aufmerksamkeit widmen.

Einheitlichkeit mit den Atlan-Bildern kriewgen wir schon hin. Sollte kein Problem sein. --JoKaene 14:15, 11. Jul. 2012 (UTC)

Bei Archäonten ein ähnlicher Fehler wie bei Asteroidenstadt.

Der Fehler war zwar schon vorher drin, aber vielleicht sollte ich bei den weiteren Ersetzungen lieber auf $2 gehen, das wäre der Link, der im Artikel angezeigt wird. $1 ist das große Bild, das nach dem Klick angezeigt wird und da sind die Fehler wohl wahrscheinlicher, da nicht sofort zu sehen. --NAN s BOT 14:19, 11. Jul. 2012 (UTC)

Zustimmung! Ein falsches (angezeigtes) Bild wäre wohl schon vorher aufgefallen; ein falscher Link eher selten. --JoKaene 14:23, 11. Jul. 2012 (UTC)

O.k., das zweite Paar Augen ist mit dem nochmal drüber schauen ebenfalls durch.

Passe das Muster für die Ersetzung wie folgt an und setze die Änderungen beim Buchstaben B fort:

[[Datei:PR$2.jpg|220px]]

--NAN s BOT 14:29, 11. Jul. 2012 (UTC)

Bin mit dem Kontrollieren durch der letzten Änderungen durch. Keine Fehler durch die Änderungen entdeckt (dafür aber einige schon zuvor existierende fehlerhafte/unvollständige Anwendungen der Imagelink-Vorlage).

Bin jetzt 'ne Weile offline, aber Du kannst gerne weitermachen JoKaene. Ich kann dann später den QS-Part übernehmen und mir Stichproben Deiner Änderungen anschauen. --NAN s BOT 14:54, 11. Jul. 2012 (UTC)

OK! BTW, bei umlaufenden Covern erhöhe ich die Breite auf 360px. Dieses Maß hast Du glaube ich auch schon genommen.

Betreff weitermachen. Hast Du außer Präfix weitere Einschränkungen geschaltet? --JoKaene 14:58, 11. Jul. 2012 (UTC)

Sorry, aber ich habe im Moment extreme Schwierigkeiten mit meinem Netzzugang und kann kaum einen Edit ausführen. (bin sehr genervt!!!) Übrigens scheinen jetzt die TiBis wieder unter ihrer alten Adresse zur Verfügung zu stehen. :-( --JoBot 17:07, 11. Jul. 2012 (UTC)

Dank der zumindest temporär wieder vorhandenen Bilder am alten Platz ist die Sache hier ja auch nicht mehr soooo dringend.

Habe mir Stichproben Deiner Änderungen angeschaut. Sahen alle gut aus. Besonders beeindruckend die Umstellung der Galerien (hier aber dann auch das Problem bezüglich "neue Größe gemischt mit alter" relativ augenfällig).

Ziehe mich dann für heute zurück.

Wünsch Dir noch 'nen schönen Abend. --NAN s BOT 17:18, 11. Jul. 2012 (UTC)

So, mit Form 1 bin ich durch. Habe sehr viele, aber nicht alle Artikel überprüft. Sah jedoch alles gut aus. Ich habe vor allem auch die Artikel mit mehr als einem Cover überprüft um gegebenenfalls die Untertitelung an die neue Größe anzupassen. Mache jetzt etwas Pause und gehe dann mal Form 2 an. --JoKaene 13:00, 12. Jul. 2012 (UTC)

Form 2 habe ich jetzt für »A« ausgeführt. Lief soweit auch ordentlich durch. Lediglich bei Anzug der Vernichtung ist ein Link nicht bearbeitet worden. Übersehe ich hier etwas oder haben wir noch eine »Form 3«? Um den Überblick zu behalten stelle ich die Textersetzung jetzt zunächst wieder ein. --JoKaene 15:13, 12. Jul. 2012 (UTC)

Ja. ;-)

Muster für Originaltext (Form 3)

\[http:..perry-rhodan.net.pics.tibis.([0-9][0-9][0-9][0-9])tibi.jpg http:..perry-rhodan.net.pics.tibi1.([0-9][0-9][0-9][0-9])tibi.jpg\]

Muster für die Ersetzung:

[[Datei:PR$2.jpg|220px]]

Getestet mit Adentoco Porvistar, Amethyst-Stadt, Anais Berkoff, Anthurianer, Anzug der Universen, Anzug der Vernichtung. Sieht gut aus. --NAN s BOT 19:12, 12. Jul. 2012 (UTC)

Änderung für sämtliche 91 so gefundene Artikel angestoßen. --NAN s BOT 19:13, 12. Jul. 2012 (UTC)

Habe grob drübergeschaut und sah gut aus. Machst Du weiter oder soll ich den Rest von Form 2 übernehmen? --JoKaene 19:24, 12. Jul. 2012 (UTC)

Form 3 ist inzwischen komplett durch. Da doch etwas Risiko dabei war, habe ich jede Änderung einzeln geprüft. Habe ebenfalls keine Fehler gefunden.

Mach ruhig mit Form 2 weiter. "Eigentlich" habe ich eh keine Zeit und bin auch gleich wieder offline. (Samstag kann ich mich wieder stärker einbringen und mache dann gerne die 2. Prüfung per Stichproben der von Dir gemachten Änderungen). --NAN s BOT 19:37, 12. Jul. 2012 (UTC)

Alles klar. Bis dann. --JoKaene 19:40, 12. Jul. 2012 (UTC)

Form 2 beendet und vollständig kontrolliert. Dabei Form 4 entdeckt.

[http://perry-rhodan.net/produkte/hefte/1/tibi1804.html http://perry-rhodan.net/pics/1/1804tibi.jpg]

Regex

\[http:..perry-rhodan.net.produkte.hefte.1.tibi([0-9][0-9][0-9][0-9]).html http:..perry-rhodan.net.pics.1.([0-9][0-9][0-9][0-9])tibi.jpg\] mit

[[Datei:PR$2.jpg|220px]] ersetzt. --JoBot 09:59, 13. Jul. 2012 (UTC)

Form 5

[http://perry-rhodan.net/pics/tibis/1818tibi.jpg http://perry-rhodan.net/pics/1/1818tibi.jpg]

\[http:..perry-rhodan.net.pics.tibis.([0-9][0-9][0-9][0-9])tibi.jpg http:..perry-rhodan.net.pics.1.([0-9][0-9][0-9][0-9])tibi.jpg\] mit

[[Datei:PR$2.jpg|220px]] ersetzt. --JoBot 10:45, 13. Jul. 2012 (UTC)

Form 6 (*seufz*)

[http://perry-rhodan.net/produkte/hefte/1/tibi2174.html http://perry-rhodan.net/pics//2/2174tibi.jpg]

\[http:..perry-rhodan.net.produkte.hefte.1.tibi([0-9][0-9][0-9][0-9]).html http:..perry-rhodan.net.pics..2.([0-9][0-9][0-9][0-9])tibi.jpg\] mit

[[Datei:PR$2.jpg|220px]] ersetzt. --JoBot 10:59, 13. Jul. 2012 (UTC)

Interessant, hätte jetzt nicht gedacht, dass wir da auf so viele unterschiedliche Pfade stoßen würden...

Vielen Dank für Deine wie immer gründliche Arbeit. :-)

Bin mit der 2. Prüfung übrigens ebenfalls durch, alle Stichproben sahen gut aus. :-) --NAN (Diskussion|Beiträge) 16:47, 13. Jul. 2012 (UTC)

Ja hätte ich auch nicht vermutet; dachte bislang ebenfalls, dass es nur zwei Adressen gab. Besonders interessant war Form 6: Kam nur einmal (!) vor.

Im Übrigen habe ich diesmal alle Änderungen überprüft; war mir doch lieber, nachdem ich erst einmal eine weitere Adressform gefunden hatte.

Diese Umstellung könnte damit also erledigt sein. --JoKaene 17:14, 13. Jul. 2012 (UTC)

220 px

Bin leider etwas spät dran für obige Diskussion. Doch mir ist aufgefallen, dass die Größe der TiBis, die auf 220 px skaliert sind, den Bildschirmrahmen der 4:3 Monitore sprengt. Es passen nicht mehr alle Tibis in den Galerien der Breite nach auf die Oberfläche. Ebenso wird der Überblick-Kasten zu breit, sodass der Text der Handlung zum Teil in diesen hineinragt. Optisch unschön. Wollte nur drauf hinweisen und fragen, ob das auch anders machbar ist. --Zapp 14:01, 14. Jul. 2012 (UTC)

Habe auf Auflösung 1280x960 eingestellt, also 4:3, kann Deine Beobachtung bei 100% Zoom nicht nachvollziehen.

Kannst Du bitte ein paar Beispiele verlinken und Deine technischen Daten (Browser, Bildschirmauflösung, Zoomfaktor im Browser) nennen? Danke. --NAN (Diskussion|Beiträge) 14:04, 14. Jul. 2012 (UTC)

PS: Das Ändern von 220px auf einen anderen Wert wäre davon abgesehen kein Problem. Die gemachte Änderung zielte halt zunächst mal darauf, die Bilder überhaupt wieder anzuzeigen. Solche Feinheiten wie die Größe kann man immer noch klären. Selbst bin ich allerdings noch nicht wirklich überzeugt, dass kleiner besser wäre. --NAN (Diskussion|Beiträge) 14:09, 14. Jul. 2012 (UTC)

PPS: Überblickskasten bezieht sich wahrscheinlich auf die Handlungszusammenfassungen? (Bin nicht gleich drauf gekommen, da die von den oben beschriebenen Änderungen nicht betroffen waren.)

Dort wird aktuell mit 240 px gearbeitet. Das ist bei dieser Auflösung definitiv zu viel. Ich ändere mal die entsprechende Vorlage runter auf 220 px, dann haben wir eine gemeinsame Ausgangsbasis für die weitere Diskussion. --NAN (Diskussion|Beiträge) 14:24, 14. Jul. 2012 (UTC)

Ich persönlich wäre mit der aktuellen Größe von 220px sehr zufrieden. Obwohl mein Bildschirm auch nicht sooo groß ist, wäre da sogar noch »Luft nach oben«. Nun will ich das aber auch nicht verallgemeinern und wünsche mir deshalb, dass noch weitere Meinungsäußerungen hinzukommen. Richtig eilig kann eine eventuelle Änderung aber auch nicht sein. Man sollte auf der Hauptseite im Disskussionskasten auf diese Diskussion aufmerksam machen, vielleicht eine Woche lang Reaktionen abwarten und dann sehen, ob Handlungsbedarf besteht. --JoKaene 14:52, 14. Jul. 2012 (UTC)

Zustimm.

Eventuell kann man die Änderung dann auch mit der Umstellung auf eine, oder mehrere zentrale Vorlagen verknüpfen. In einer Woche könnten wir mit den Vorlagen weit genug sein.

Einfach mal auf die Beispiel-Links von Zapp warten und dann anhand der Beispiele die Mehrheit entscheiden lassen. --NAN (Diskussion|Beiträge) 14:56, 14. Jul. 2012 (UTC)

Dann warte ich noch eine Reaktion von Zapp ab und verweise dann auf der Haupseite auf diese Diskussion. --JoKaene 15:12, 14. Jul. 2012 (UTC)

War mal kurz im Altersheim. ;-) Meine Bildschirmauflösung steht auf höchster Stufe: 1024x768, der Zoom-Faktor auf "Strg+0". Browser: Mozilla Firefox. Da bei Euch offensichtlich alles gut aussieht, wollte ich Euch einen Screenshot schicken. Da NAN inzwischen in den Heftzusammenfassungen die Bildgröße von 240px auf 220px reduziert hat, passt es in meiner Darstellung wieder. Aber vereinzelte Seiten sehen immer noch so ähnlich aus, z.B. PR2651. Bei der Galerie zitierter Lokalitäten z.B. ist das rechte TiBi nur ca. zu einem Drittel noch sichtbar. Natürlich könnte ich den Zoomfaktor erniedrigen, dann wird aber die Schrift so klein, dass sie schwer lesbar wird. (Zumindest im Altersheim.) --Zapp 16:45, 14. Jul. 2012 (UTC)

Ich benutze recht viel recht viel mein iPad um zu surfen. Hinundwieder hatte ich vor der Umstellung ähnliche Darstellungen wie sie Zapp beobachtet. Seit der Umstellung sieht bei mir jede HZF so aus. Das iPad hat 4:3 Format. --Poldi 16:56, 14. Jul. 2012 (UTC)

Ist das aktuell immer noch so? Bisher war das Bild in den HZF auf 240px, habe das heute auf 220px verkleiner. --NAN (Diskussion|Beiträge) 17:07, 14. Jul. 2012 (UTC)

Mit Auflösung 1024x768 kann ich das Problem nun ebenfalls nachvollziehen.

Habe mal kurz unter [2] einen Test mit 200px gemacht.

Passt bei Zoom-Faktor "Strg+0" ebenfalls nicht ganz, aber immerhin schon besser.

Denke die Frage ist damit aber einfach: Wollen wir als kleinste Auflösung 1024x768 unterstützen?

Falls ja, dann halte ich sogar tatsächlich das bisher verwendete 180px für angebracht. (200px wäre irgendwie 'ne halbe Sache.)

Oder gehen wir davon aus, dass eine solche Auflösung recht selten ist und für die allergrößte Mehrheit der Leser das größere 220px wesentlich besser.

Ehrlich: Da muss ich erstmal drüber nachdenken, wie meine Meinung ist. ;-)

Wir sollten uns aber auf etwas durchgehendes einigen, da bei jeder Seite immer zu prüfen, ob vielleicht ausnahmsweise doch auch 220px oder ähnliches auch bei 1024x768 funktioniert wäre von der Wartung her nicht so wirklich toll.

@Poldi, ich denke, das hat nicht wirklich bzw. nur indirekt was mit 4:3 zu tun. Größere Auflösungen gibt es ja auch in dem Format und dann sieht das gut aus. (Also mal auf das nächste iPad warten. ;-))

Diesbezüglich eine Frage: Die Wikipedia hat eine recht gute mobile-Ansicht. Könnten wir die relativ einfach in unserem wiki aktivieren, oder ist das eine kompliziertere Sache? --NAN (Diskussion|Beiträge) 17:02, 14. Jul. 2012 (UTC)

Ich kann das Problem mit dem iPad 1 und 3 nachvollziehen. Zumindest das 3 hat eine höhere Auflösung aber ebenfalls 4:3. Bzgl. der mobilen Version kann ich gar nichts sagen. Damit hab ich mich noch nicht beschäftigt. --Poldi 17:12, 14. Jul. 2012 (UTC)

Falls eine höhere Auflösung als "Standard" angesehen werden sollte, dann wäre ein gut sichtbarer Hinweis etwa in dieser Form: "Optimale Auflösung bei B x H px" hilfreich. --Zapp 17:17, 14. Jul. 2012 (UTC)

@Poldi: Ist interessant. Am PC ist das ganze bei z.B. 1280x960 (auch 4:3) lesbar. Aber wahrscheinlich hast Du am iPad trotz gigantischer Auflösung auch einen entsprechendne Zoom-Faktor, um auf dem relativ kleinen Bildschirm Lesen zu können?

Die Unterstützung von Tablets, die denke ich eher selten eine mobile-Version anzeigen (?), wäre wohl auch langfristig ein Grund, die Bilder kleiner zu machen.

@Zapp: Denke, falls es so einen Hinweis braucht, dann ist das ein Zeichen, dass genügend Leute eine Auflösung/Zoom-Faktor-Kombination nutzen, um auf 180px zu gehen. Na ja, und dann braucht es den Hinweis (der irgendwie ja auch störend wäre) nicht. ;-)

Also ich tendiere nun ebenfalls zu 180px und 1024x768/Zoom 100%/am PC als Referenzpunkt. --NAN (Diskussion|Beiträge) 17:31, 14. Jul. 2012 (UTC)

Ich habe jetzt mal einen Hinweis auf diese Diskussion auf der Hauptseite hinterlegt.

So lieb mir eine größere Darstellung (220px) auch wäre, bin da doch nicht festgelegt. Bislang kam ich ja auch mit 180px klar. Wenn also eine kleinere Auflösung gewünscht wird (selbst wenn das keine Mehrheit will), stimme ich dem auch zu. --JoKaene 17:43, 14. Jul. 2012 (UTC)

Das Problem habe ich nicht auf dem iPhone. Auch nicht 4:3. Früher hatten wir die 180px und es gab keine großen Beschwerden. Auch wenn 180px mittlerweile für viele Auflösungen zu klein wirkt, scheint es aber der kleinste (eh ist ja ein Wortspiel :-) gemeinsame Nenner zu sein. --Poldi 17:45, 14. Jul. 2012 (UTC)

Ah, diese Form der Beweisführung fordert doch den Mathematiker in mir heraus. ;-)

Ich habe das Problem am Samsung Galaxy SII. Auch nicht 4:3. ;-)

Denke es ist wichtig zu sehen, dass das Fehlerbild nicht unbedingt am Verhältnis Breite/Höhe des Bildschirms hängt (sonst könnte man ja auf den Gedanken kommen, dass es ohnehin bald keine 4:3-Geräte mehr gibt und gut ist ;-) ). Es spielen mehrere Faktoren (Auflösung, Zoom, ?) zusammen, die 4:3 - Sache ergibt sich nur indirekt. Mal passt die Anzeige bei 4:3, mal nicht. Mal passt die Anzeige bei anderen Verhältnissen, mal nicht.

Denke gerade der mobile Bereich ist dabei eine Sache, die wir nicht aus den Augen verlieren und uns irgendwann in aller Ruhe anschauen sollten. --NAN (Diskussion|Beiträge) 18:22, 14. Jul. 2012 (UTC)

Hallo zusammen! Vielleicht schrecken die technischen Details und/oder der Umfang der Diskussion potentiele Diskussionsteilnehmer ja ab (z. B. mich), daher so wenig Feedback? Ich würde die verschiedenen Größenvarianten gern selbst ausprobieren, aber dazu wäre es hilfreich, zur besseren Vergleichbarkeit ein- und dieselbe Beispielseite mit den unterschiedlichen Covergrößen anzubieten. Geht das? VG --Klenzy 12:13, 17. Jul. 2012 (UTC)

Das macht vermutlich nicht viel Sinn, weil es darum geht, ob mit der neuen Größe auch bei geringer Bilschirmauflösung noch der gesamte Artikel in seiner Breite auf den Bildschirm passt. Da aber bislang nur die PR-Cover größer dargestellt werden, können als Vergleich Artikel mit Atlan-Covern herangezogen werden. Die haben noch die alte, kleinere Größe. --JoKaene 12:41, 17. Jul. 2012 (UTC)

Hm, Klenzy, Beispiele sind sicher machbar (und ich mache Sie Dir einfach mal heute abend oder spätestens morgen früh, sowohl für Handlungszusammenfassung, als auch "normalen" Artikel).

Aber wichtig: Wie von JoKaene angesprochen, geht es um den Fall der geringen Bildschirmauflösung z.B. auf Tablets.

Uns wäre nicht geholfen, würde sich hier eine "lokale" Mehrheit finden, weil auf den Bildschirmen der meisten aktiven user das passt.

Leser haben wir ja (hoffentlich ;-) ) sehr viel mehr. Denke zukünftig auch verstärkt mit Tablets als Anzeigegerät. Eben deswegen habe z.B. ich meine Meinung in Richtung 180px geändert. --NAN (Diskussion|Beiträge) 14:52, 17. Jul. 2012 (UTC)

Ooops, sorry, ich habe die Diskussion hier erst jetzt gesehen. Meiner Meinung sind 180px (also wie bisher) - auch aus Rücksichtnahme auf mobile Geräte (TabletPC, Smartphones, aber auch kleinere Notebooks) und ältere Bildschirme - OK, vor Allem wenn es für den Leser die Möglichkeit gibt, das Bild durch Anklicken größer anzuzeigen. Noch etwas ist mir aufgefallen, aber vielleicht ist/war das nur ein vorübergehendes Phänomen während der Umstellung: Die Größe von Tibi und Innenillu sollte einheitlich sein. --Andi47 16:18, 17. Jul. 2012 (UTC)

Bei 180px der PR-Cover hätten wir bei den gegebenen Umständen wieder eine einheitliche Größe. Die Illus werden allerdings auch noch auf unseren Server geladen und könnten dann natürlich auch größer dargestellt werden. Aber so, wie es im Moment aussieht, läuft wohl alles auf die ursprüngliche Größe (180px) hinaus, denn bislang hat sich noch niemand »vehement« für 220px ausgesprochen. --JoKaene 16:34, 17. Jul. 2012 (UTC)

Beispiel 1: Artikel mit 180px, Artikel mit 220px

Beispiel 2: Artikel mit 180px, Artikel mit 220px

Beispiel 3: Handlungszusammenfassung mit 180px: Quelle:A4; Handlungszusammenfassung mit 220px: Quelle:A3;

Bezüglich fehlerhafter Darstellung, wenn zu groß/Auflösung zu klein/Zoom zu groß: Kann z.B. bei Quelle:PR2651 beobachtet werden. --NAN (Diskussion|Beiträge) 04:20, 18. Jul. 2012 (UTC)

Herzlichen Dank, so ist es für mich einfach leichter, mit ein paar unterschiedlichen Auflösungen zu spielen und das Ergebnis zu vergleichen.

Zugegeben, zu Tablets oder Smartphones als PP-Endgeräten kann ich nichts beisteuern. Insofern ist mein Eindruck nur begrenzt zu berücksichtigen.

Aus meinen Spielereien habe ich folgenden zusammenfassenden Eindruck gewonnen. In allen Beispielen gibt es keinen signifikanten Informationsgewinn (z. B. Name des Autors, Untertitel), egal ob das Bild in 180px oder 220px dargestellt wird, oder anders ausgedrückt geht bei 180px nichts verloren, und das gilt für 1024x768 ebenso wie für 1600x900. Bei 1024x768 ist die Darstellung in jedem Fall unschön, egal ob 180px oder 220px nimmt das Cover einfach zuviel Platz weg im Verhältnis zum Text. Ab 1280x720 passt die HZF mit 180px. Aber 1024x768 sieht mittlerweile bei den meisten Programmen nicht mehr besonders gut aus und wird über kurz oder lang sowieso aussterben.

Ich finde, selbst als herkömmlicher PC-Nutzer kann ich mich deutlich »pro« 180px aussprechen bzw. gibt es keine echte Notwendigkeit für 220px. --Klenzy 17:53, 19. Jul. 2012 (UTC)

Nur als Ergänzung: Bei Beispiel 1 (Amethyst-Stadt, Artikel mit 180px, Artikel mit 220px) wäre der erhoffte Informationsgewin z.B. ein besseres Erkennen der Stadt, also des Gegenstands des illustrierten Artikels. --NAN (Diskussion|Beiträge) 19:42, 19. Jul. 2012 (UTC)

Gilt auch für die Stadt: auch bei 180px einwandfrei zu erkennen. --Klenzy 23:02, 19. Jul. 2012 (UTC)

Die 180px scheinen eine sehr eindeutige Mehrheit zu haben?

Würde vorschlagen, die 220px per ReplaceText nach 180px abzuändern. Bis die Vorlagen so weit sind kann es noch etwas dauern. --NAN (Diskussion|Beiträge) 19:44, 19. Jul. 2012 (UTC)

Ja, eine Mehrheit für 220px wird sich nicht mehr bilden und die Argumente für 180px sind stark genug. Ich würde die Arbeit im Laufe des heutigen Tages auch übernehmen. Zur Kontrolle stelle ich den RegEx ein:

Originaltext = \[\[Datei:PR([0-9][0-9][0-9][0-9]).jpg|220px\]\]

Ersetzt durch = [[Datei:PR$1.jpg|180px]]

Habe ich zwar schon positiv getestet, aber dennoch hätte ich gerne eine Rückmeldung, ob das richtig ist. --JoKaene 04:44, 20. Jul. 2012 (UTC)

Spricht noch irgendetwas gegen die Rückwandlung nach 180px oder kann ich es durchführen? --JoKaene 11:41, 21. Jul. 2012 (UTC)

Würde gerne die Muster noch mal testen (eigentlich sollte das "|" im Suchmuster stören?). Melde mich gleich noch mal. --NAN (Diskussion|Beiträge) 11:57, 21. Jul. 2012 (UTC)

Test für Abanathan Seg Dathuel bewirkt keine Änderung. Entweder der Job ist noch in der Warteschlange, oder das Muster funktioniert nicht (kann keine klare Aussage darüber machen).

Nachtrag: Hat nur etwas gedauert. Test zeigt, dass Suchmuster nicht funktioniert. --NAN s BOT 12:03, 21. Jul. 2012 (UTC)

Teste mal ein alternatives Muster. Melde mich gleich wieder. --NAN s BOT 12:02, 21. Jul. 2012 (UTC)

Ja, hab's gemerkt. Muster ist fehlerhaft. Weiß nur nicht warum. Hoffe auf Deine Korrektur. --JoBot 12:11, 21. Jul. 2012 (UTC)

O.k., mein Vorschlag für das Suchmuster wäre:

\[\[ *Datei:PR([0-9][0-9][0-9][0-9]).jpg *\| *220px *\]\]

Das "|" hat die Bedeutung von "oder", sollte von daher maskiert werden.

Die ganzen optionalen Leerzeichen sind zwar wahrscheinlich nicht nötig, aber sicher ist sicher.

Getestet mit Augustus.

Aber: Habe natürlich einen weiteren Test mit dem ursprünglichen Muster gemacht und auch das würde anscheinend funktionieren. Aus irgendwelchen Gründen wirkt sich das unmaskierte "|" nur dann negativ aus, wenn man so wie ich versehentlich beim Kopieren ein Leerzeichen vor dem Suchmuster mitnimmt (also: vor dem \[; klarer Fehler beim Tester ;-) ).

Trotzdem: Würde eher zum von mir vorgeschlagenen Muster tendieren, einfach, weil ich da verstehe, warum es funktioniert und beim ursprünglichen eigentlich nicht so wirklich. --NAN s BOT 12:21, 21. Jul. 2012 (UTC)

Dann werde ich es mal vorsichtig angehen. Noch ein paar Tests und dann mal Buchstabenweise. --JoBot 12:24, 21. Jul. 2012 (UTC)

Stichproben angeschaut. Sieht gut aus. --NAN (Diskussion|Beiträge) 13:39, 21. Jul. 2012 (UTC)

Die Vorlagen für die Handlungszusammenfassungen habe ich zwischenzeitlich ebenfalls mal angepasst.

Ansonsten: Weitere Stichproben genommen. Sahen alle gut aus.

JoKaene, Danke, dass Du die Arbeit gemacht hast. :-) --NAN (Diskussion|Beiträge) 14:22, 21. Jul. 2012 (UTC)

Kein Problem. Meine Kontrollen haben auch keine Unregelmäßigkeiten aufgedeckt. Einige spezielle Seiten (zwei Cover nebeneinander) bedürfen noch etwas Nacharbeit in Bezug auf Untertitelung (mache ich jetzt), aber der alte Stand dürfte damit wiederhergestellt sein. --JoKaene 14:30, 21. Jul. 2012 (UTC)

Textersetzung

Ich habe vor, in der nächsten Zeit mithilfe von ReplaceText unnötige Pipe-Links aufzulösen und bei entsprechenden Begriffen durch einfügen von & nbsp; ungünstige Zeilenumbrüche im Fließtext zu vermeiden. Ein Beispiel zu den Pipe-Links wäre beispielsweise [[M 13|M& nbsp;13]] (ändern zu [[M& nbsp;13]]
Ungünstige Zeilenumbrüche sehe ich z.B. bei Begriffen, die alleinstehende einzelne Buchstaben beinhalten, etwa der Name Argan U. Aber auch bei durch einen Punkt markierten Abkürzungen wie bei Homer G. Adams. Ein Punkt am Ende einer Zeile, der keinen Satz abschließt, kann schon mal verwirren.
Da dies alles eine reine Textersetzung ist, besteht eigentlich keine Gefahr, da eventuelle Falscheingaben mit dem Tool auch wieder rückgängig gemacht werden können. Dennoch möchte ich mir hier natürlich ein »OK« abholen, da ich die Änderungen als Bot durchführen würde und sie deshalb nahezu unsichtbar geschehen.
Um es nachvollziehbar zu halten werde ich jede mit dem Tool durchgeführte Änderung dokumentieren. Um aufzuzeigen wie das aussieht, habe ich die beiden ersten oben genannten Beispiele bereits umgesetzt und in diese Liste eingetragen. --JoKaene 20:12, 5. Mai 2012 (CEST)

Wie bekannt wäre mein persönlicher "Traum" ;-) ja, so etwas zentral zu machen, anstatt auf individuelle Seiten individueller Bots verteilt. Das Verteilte gab es früher schon (falls Du Dir Anregungen für weitere Sachen holen willst, schau mal auf die Seite von WoBot), gibt es jetzt mit Deiner Seite, JoKaene, eine mehr. Diskussionen werden sich wohl automatisch zu Deiner Diskussionsseite dort verlagern. Und sollte JoBot irgendwann mal nicht mehr laufen, dann gerät die Seite wahrscheinlich auch rasch in Vergessenheit. Hoffe siehst mir nach, wenn mich das jetzt einfach mal nicht so direkt wirklich begeistert. ;-)

Aber nun, mit meiner Meinung stehe ich alleine, insofern: Schön gemacht, die Seite.

Wenn Du nichts dagegen hast, werde ich Formatierungen für die Seite hier und meine eigenen Seiten übernehmen.

Beim Durchsehen der redirects ist mir kürzlich aufgefallen, dass da teilweise unnötige Zeichen enthalten waren (die aber zumindest zum größten Teil nicht geschadet haben).

Sehe ich als einzigen Nachteil bei der von Dir geplanten automatisierten Ersetzung: Du wirst wahrscheinlich redirects nicht ausnehmen können (z.B.[3]), dann enthalten auch die Weiterleitungslinks das »&nbsp;«.

Scheint nicht zu stören, denke wäre aber gut, das nochmal zu prüfen, bei Poldi nachzufragen. --NAN (Diskussion|Beiträge) 16:02, 11. Mai 2012 (CEST)

Ja, durch Deine Änderungen bei den Redirects ist mir der Fehler auch aufgefallen. Hatte das tatsächlich vorher nicht bedacht. Inzwischen überprüfe ich allerdings möglicherweise betroffene Redirects im Nachhinein.

Die Änderungen auch auf dieser Projektseite zu notieren finde ich ebenfalls sinnvoll. Ich hatte es bislang lediglich auf der JoBot-Seite notiert, um es für mich festzuhalten und auch um aufzuzeigen, dass die Änderungen festgehalten werden sollten, damit ein Überblick gewährleistet ist. Ob für die Projektseite »meine« Formatierung übernommen wird (oder ob Du sie übernimmst), spielt für mich keine Rolle.

Kurz, an der Verwirklichung Deines Traums beteilige ich mich gern. ;-)

PS: WoBot habe ich mir schon angeschaut und letztlich stammt die Idee meiner aktuellen Textersetzung zumindest zum Teil von dort. --JoKaene 16:35, 11. Mai 2012 (CEST)

Nun, Du hast Talent wenn es darum geht, Informationen übersichtlich darzustellen.

Das ist natürliche auch für die Projektseite gewünscht. Kannst Du gerne auch Änderungen einpflegen. :-) --NAN (Diskussion|Beiträge) 17:07, 11. Mai 2012 (CEST)

Die Änderung der redirects ist ja nicht unbedingt ein Fehler. Wir sollten uns nur einfach sicher sein. --NAN (Diskussion|Beiträge) 17:09, 11. Mai 2012 (CEST)

OK, ich pflege die Informationen ein.

Die Geschichte mit den Redirects mag kein Fehler mit Auswirkungen sein, aber es war weder geplant noch gewünscht. Insofern war es ein Fehler in meiner Herangehensweise. Und das sehe ich dann doch als Fehler an, der mir obendrein nur durch Deine »Säuberung« der Redirects, also eher zufällig offenbar wurde. Das war mir schon etwas peinlich. Aber natürlich bin ich dadurch jetzt auch noch vorsichtiger geworden. ;-) --JoKaene 17:28, 11. Mai 2012 (CEST)

Dann lasse ich die nächste Zeit erstmal die Finger von der Seite, um Dir nicht in die Quere zu kommen. ;-)

Könntest Du bitte insbesondere auch einen Blick auf Perrypedia:Automatisierte_Änderungen#Änderungen per »Extension:Replace Text« werfen? Ich bin bezüglich Informationsgehalt zufrieden mit dem, was ich dort gemacht habe. Aber bezüglich Darstellung kann man da sicher mehr machen und selbst komme ich gerade auf keine neuen, frischen Ideen. ;-) --NAN (Diskussion|Beiträge) 17:36, 11. Mai 2012 (CEST)

Ich schau's mir an. Spätestens morgen mittag ist alles erledigt. Habe schon eine Idee, aber heute kaum noch Zeit. --JoKaene 17:42, 11. Mai 2012 (CEST)

Hab's optisch und teilweise im Wortlaut überarbeitet überarbeitet. --JoKaene 09:24, 12. Mai 2012 (CEST)

...und den Absatz »Textersetzung ohne regex« angehängt. Ist dies alles eine Verbesserung oder gibt es weitere Anregungen? --JoKaene 09:55, 12. Mai 2012 (CEST)

Vielleicht wäre es optisch noch einen Tick besser, den Einklapp-Bereich links zu setzen und ausgeklappt (da ausgeklappt nicht funktioniert: Als Tabelle, aber optisch so wie der Einklapp-Bereich)? --NAN (Diskussion|Beiträge) 11:22, 12. Mai 2012 (CEST)

Ich persönlich würde die jeweiligen regex lieber auf der rechten Seite belassen, weil so der erläuternde Text quasi vorangestellt bleibt; was ich als »richtiger« empfinde. Wie man die regex sinnvoll als offene Tabelle darstellen kann, muss ich erst noch erarbeiten, wäre aber wohl kein Problem. --JoKaene 11:41, 12. Mai 2012 (CEST)

Ja, stimme Dir da zu. Was mich aktuell beim Draufschauen aber etwas irritiert ist, denke ich einfach die weiße Fläche links und der farbig hinterlegte Balken rechts. Empfinde das so, dass der »Schwerpunkt« rechts liegt. Gleichzeitig ist mir klar, dass der »Schwerpunkt« eigentlich links liegt, dass dort das steht, was es zu lesen gilt. Hm, irgendwie schwer auszudrücken. Vielleicht, wenn der linke Text in einem ähnlich farbig hinterlegten Kasten steht wie der rechte auch ohne Vertauschen der Spalten besser? --NAN (Diskussion|Beiträge) 11:47, 12. Mai 2012 (CEST)

Ich denke, ich verstehe was Du meinst und gehe die Sache noch mal an. --JoKaene 11:51, 12. Mai 2012 (CEST)

So, diesmal habe ich etwas völlig anderes gemacht. Der Quelltext ist zwar etwas unübersichtlich, aber die allgemeine Optik gefällt mir. Ob ich dabei die »richtigen« Farben gewählt habe ist natürlich Geschmacksache. --JoKaene 15:07, 12. Mai 2012 (CEST)

Die allgemeine Optik gefällt mir auch. Farbzusammenstellung sagt mir zu. Finde insbesondere die graue Grundfläche cool. :-) --NAN (Diskussion|Beiträge) 15:28, 12. Mai 2012 (CEST)

:-)

...und dabei war die Grundfläche nur eine Notlösung, um den langen Block bei »Sortierung über PPDefaultsort« zusammenzuhalten. --JoKaene 15:37, 12. Mai 2012 (CEST)

Vorlagenaustausch

Ich denke, dass am Ende der Sortkey-Zuordnungsaktion für jedes Lemma jeweils die Vorlage verwendet wird, die auch in der Hilfe empfohlen wird. In vielen Fällen wurde, bevor PPDefaultsort fertig war, DEFAULTSORT: verwendet. Wo es richtig ist, würde ich deshalb gerne DEFAULTSORT gegen PPDefaultsort austauschen. Mit dem regex

(\{\{DEFAULTSORT:([^]]*)\}\}) ersetzen durch {{PPDefaultsort}}

habe ich in der Zweit-PP bereits erfolgreiche Tests durchgeführt. Da ich den regex jedoch lediglich aus einem anderen abgeleitet habe, bedarf er einer Überprüfung. --JoKaene 13:02, 25. Apr. 2012 (CEST)

Hoffe nimmst es mir nicht übel, wenn ich nicht einfach das Ergebnis schreibe, sondern auch die Herleitung? Denke nützt Dir vielleicht bei weiteren Mustern. Mir ist aber natürlich auch klar, dass das von meiner Seite mal wieder oberlehrerhaft rüberkommt. ;-)

In der Praxis würde Dein Muster funktionieren, da wir DEFAULTSORT immer ganz an das Ende eines Artikels gestellt haben.

Besser/Korrekter wäre:

(\{\{DEFAULTSORT:([^}]*)\}\})

In »[]« stellen heißt: Eines der Zeichen in eckigen Klammern.

In »[^]« stellen heißt: Alle Zeichen, außer den in den eckigen Klammern (das ^ bewirkt an dieser Stelle eine Verneinung, außerhalb der eckigen Klammern hat es eine andere Bedeutung)

Das »[^]]« bedeutet also: Jedes Zeichen außer »]«, was für die Kategorien cool war. Hier schließt der Suchbegriff aber mit »}« ab, deswegen [^}].

* bedeutet »0 bis beliebig viele Wiederholungen«, + bedeutet »1 bis beliebig viele Wiederholungen«.

Also noch besser:

(\{\{DEFAULTSORT:([^}]+)\}\})

Eine der Alternativen, nämlich .+, bedeutet »1 bis beliebig viele beliebige Zeichen«, würde ich nicht verwenden, da von der Regex immer (o.k., müsste man prüfen, ob unsere das genauso macht, schadet aber nicht, das anzunehmen) nach möglichst viel gesucht wird. Würde z.B. irgendwo stehen:

Test {{DEFAULTSORT:Test}} weiterer Text {{andere Vorlage}}

würde gefunden und ersetzt

{{DEFAULTSORT:Test}} weiterer Text {{andere Vorlage}}

also zu viel.

Gerade getestet: Unsere Extension macht tatsächlich bereits bei den ersten beiden »}« halt, persönlich ziehe ich die Schreibweise mit der Verneinung zwar vor, aber in diesem Fall würde - wenn man nicht weiter einschränken will, siehe unten - .+ doch auch funktionieren. --NAN s BOT 17:54, 25. Apr. 2012 (CEST)

Die Runden Klammern sind in diesem Fall überflüssig. Sie schaden zwar nicht, aber man kann auch schreiben:

\{\{DEFAULTSORT:[^}]+\}\}

Wahrscheinlich möchtest Du aber noch weiter einschränken? Jedes DEFAULTSORT mit einer Zahl im Sortkey ist ja richtig?

Das Suchmuster wäre dann:

\{\{DEFAULTSORT:[^}0-9]+\}\}

Muss man nur noch testen, ob die Theorie stimmt. ;-) --NAN 17:42, 25. Apr. 2012 (CEST)

Test auf Testseite sieht gut aus. --NAN s BOT 17:54, 25. Apr. 2012 (CEST)

Aaaah ha! ;-)

Grob überflogen verstehe ich es - ansatzweise. (Wenigstens weiß ich, worum es geht.) Über die Bedeutung der einzelnen Zeichen habe ich mich schon grob informiert, ihre Anwendung ist aber für einen Laien kein einfaches Thema. Und ich gebe es zu, solange mir Dein Wissen zur Verfügung steht, möchte ich auch gar nicht beginnen, regex selber zu formulieren; die Fehlerquote wäre sicher zu hoch. Mir war in diesem Fall auch klar, dass es wohl ein eleganteres Suchmuster gibt, als das von mir getestete. Der Ausschluss von Zahlen beispielsweise. Deshalb wollte ich es ja auch kontrolliert wissen. Aber, lange Rede, kurzer Sinn: Ich werde Dein Suchmuster ebenfalls noch testen und dann, wenn es funktioniert und es keinen Widerspruch gibt, anwenden. --JoKaene 18:10, 25. Apr. 2012 (CEST)

Extension »Replace Text«: Lessons Learned

Fange mal diesen Abschnitt hier an, um eine Gelegenheit zu bieten, gewonnene Erkenntnisse im Umgang mit der Extension zu teilen.
Vorweg eine kurze Beschreibung, der Extensions:
Zum Zeitpunkt des Schreibens dieser Zeilen findet sich die Beschreibung der Extension unter http://www.mediawiki.org/wiki/Extension:Replace_Text. Dort kann man unter anderem auch Bilder der ersten beiden Seite der Extension (insgesamt gibt es derer drei) sehen.
Auf der ersten Seite kann man folgendes eingeben:

• Suchmuster
• Muster für das Ersetzen
• Häkchen: Handelt es sich bei den Mustern um eine regex (man könnte auch nach »normalen« Texten wie z.B. »Test« suchen)
• Einschränkung auf einen bestimmten Namensraum (Vorbelegt sind die normalen Seiten, möglich wäre z.B. auch »Diskussionen«, »Benutzer« oder ähnliches)
• Einschränkung auf eine bestimmte Kategorie (Textfeld, Kategorie kann einfach eingegeben werden)
• Einschränkung auf Artikel, die mit einer bestimmten Zeichenkette beginnen (Textfeld, gibt man z.B. »L« ein, werden nur Artikel angeschaut, deren Namen mit »L« beginnen, gibt man »Landschaften« ein, dann nur Artikel, deren Namen mit »Landschaften« beginnen).
• Häkchen: Sollen Seiteninhalte angeschaut/geändert werden.
• Häkchen: Sollen Seitentitel angeschaut/geändert werden.

Ist alles ausgefüllt geht es mit der Schaltfläche »Fortfahren« weiter.
Klickt man auf die Schaltfläche werden alle Seiten nach dem Suchmuster durchsucht (die gemachten Einschränkungen werden dabei beachtet).
Es wird eine Liste aller Artikel erzeugt, in denen das Suchmuster gefunden wurde, vor jedem Artikel ist ein Kästchen, über das man den Artikel ab-/auswählen kann. Hinter dem als Link aufgeführten Artikelnamen wird ein Auszug des Textes angezeigt, in dem sich das gefundene Suchmuster befindet.
Ganz am Ende der Liste sind zwei Schaltflächen: »Ersetzen« und »Auswahl umkehren«.
Erste Schaltfläche löst die nicht mehr zu stoppende Änderung aus (eventuell kann ein Admin noch was machen, wenn er den Botuser sperrt, wurde noch nicht ausprobiert).
Zweite Schaltfläche kehrt die Auswahl in der Vorschlagsliste um (alle nicht-ausgewählten Artikel werden ausgewählt, alle ausgewählten Artikel werden abgewählt)
Die beiden Schaltflächen liegen direkt nebeneinander.
Wenn man auf Ersetzen geklickt hat erscheint eine Seite, auf der einem die Zahl der Artikel mitgeteilt wird, die nun geändert werden.
Denke, das reicht als Beschreibung? Als nächstes füge ich dann ein paar Punkte an, die beim praktischen Einsatz der Extension aufgefallen sind. --NAN 18:12, 14. Apr. 2012 (UTC)

Ersetze nur in Seiten mit bestimmtem Präfix

Denke nach ein paar Tagen Arbeit mit der Extension, diese Textbox ist die wichtigste überhaupt, wenn es darum geht, ungewollte Änderungen zu verhindern.
Theoretisch wäre das ein Job für die auf der nächsten Seite am Ende der Vorschlagsliste zu findende Schaltfläche »Auswahl umkehren«. Mit der kann man nämlich alle vorgeschlagenen Artikel abwählen.
Praktisch ist man an diesem Punkt nur noch einen kleinen Fehlklick vom Auslösen der Änderung entfernt, da die Schaltfläche »Ersetzen« unmittelbar neben »Auswahl umkehren« liegt.
Wenn ich auf der zweiten Seite eine große Anzahl Artikel sehe (ich müsste mehrere Bildschirmseiten nach unten blättern, um überhaupt zu den Schaltflächen zu kommen), halte ich erst mal inne und gehe über die Navigation des Webbrowser auf die erste Seite zurück. Keine Chance für einen Fehlklick.
Hier schränke ich dann über die Textbox »Ersetze nur in Seiten mit dem Präfix« z.B. auf Seiten ein, die mit einem bestimmten Buchstaben beginnen. Schon ist die Vorschlagsliste auf der nächsten Seite sehr viel kleiner. Selbst falls etwas schief gehen sollte: Es sind nur relativ wenige Seiten betroffen, die Sache kann relativ leicht wieder rückgängig gemacht werden.
Ohne Präfix arbeite ich für meinen Teil nur noch, wenn bereits mehrere Tests und ein paar Praxiseinsätze gezeigt haben, dass Suchmuster und Muster für die Ersetzung passen. --NAN 18:24, 14. Apr. 2012 (UTC)

Mit Testseite testen ist einfach

Für Benutzer:NAN s BOT habe ich mir zwei Unterseiten (Benutzer:NAN_s_BOT/nansbot_Test1 und Benutzer:NAN_s_BOT/nansbot_Test2) angelegt.) Hier kann ich z.B zig Variationen von »Zahl mit Einheit« (10 m, 10 mal, 10 möglich, 10 m(?), ...) reinschreiben, muss nicht erst Artikel suchen, die diese Texte enthalten.
Auf der ersten Seite der Extension muss ich nun lediglich als Präfix »Benutzer:NAN_s_BOT« angeben und als Namensraum »Benutzer« und schon enthält die Vorschlagsliste nur meine eigenen Testseiten und ich kann testen, was durch ein Suchmuster ersetzt wird und was nicht.
Wichtig: Fremde Benutzerseiten zu ändern ist verboten. Da man aber auf der Vorschlagsliste sofort sieht, ob man vergessen hat, den Präfix anzugeben, kein Problem: Einfach über die Navigation des Webbrowsers zurückgehen, Präfix angeben und alles ist gut. --NAN 18:35, 14. Apr. 2012 (UTC)

Zurück über Schaltfläche des Webbrowsers

Über die »Zurück«-Schaltfläche des Webbrowser kann man wie oben bereits erwähnt einfach, ohne Risiko eines Fehlklicks (die Schaltfläche ist ganz wo anders, als die »Ersetzen«-Schaltfläche) von der Vorschlagsliste auf die erste Seite zurück wechseln, um die Vorschlagsliste einzuschränken.
Sie ist aber auch sehr hilfreich, wenn man z.B. ein Suchmuster Buchstabenweise anwendet:
Normalerweise müsste man das Suchmuster immer wieder neu eintippen (oder besser: rein kopieren). So etwas ist fehleranfällig.
Es ist aber auch möglich, von der dritten Seite mit zwei Klicks auf die Schaltfläche des Webbrowsers auf die erste Seite der Extension zurück zu navigieren. Dann steht dort noch alles so, wie es einmal eingegeben wurde (und z.B. für einen bestimmten Buchstaben gerade eben überprüft wurde). Präfix anpassen (z.B. auf nächsten Buchstaben im Alphabet ändern), ganz normal die Änderung anstoßen und das ganze so lange wiederholen, wie es halt nötig ist. Wieder eine Fehlerquelle ausgeschlossen. --NAN 18:45, 14. Apr. 2012 (UTC)

PS: In dem Fall lohnt es sich, mit mindestens zwei offenen Registerkarten zu arbeiten: Eine für die Extension und eine, in der man sich die letzten Änderungen ansieht, von der aus man die gerade gemachten Änderungen überprüft. --NAN 18:50, 14. Apr. 2012 (UTC)

Anmerkungen »Lessons Learned«

An dieser Stelle eröffne ich lieber einen neuen Absatz, um das obige besser zusammenzuhalten.
Durch die Beschreibung wird mir nun wenigsten klar, wie es zu Poldis »Unfall« kam. Obwol er ja schon beschrieben hatte, dass es durch einen Klick auf den wohl sehr ungünstig liegenden Ausführen-Button geschah. Viel mehr kann ich allerdings nicht dazu sagen. Die Ausführungen machen ja mehr den Eindruck einer Bedienungsanleitung und ein »normaler« PPnaut hat eh keinen Zugriff auf die Extension. Das ganze scheint mir unter diesem Aspekt aber gut genug gelungen, dass es auch auf der Projektseite selbst gut aufgehoben wäre. Für Interessierte könnte man dort übrigens auch einen Link zu der wie ich glaube recht informativen Wikipediaseite zu regex platzieren. --JoKaene 19:37, 14. Apr. 2012 (UTC)

Erkenntnisse gewinnt man doch ständig neu. Momentan, jetzt am Anfang, mag sich das wie eine Anleitung lesen. Falls Poldi abweichende Erkenntnisse dem geschriebenen entgegenstellen sollte, sieht das anders aus. Falls ich selbst mit mehr Erfahrung relativiere, sieht die Sache anders aus. Falls mal mehr oder einfach andere Leute aktiv sind, die an der Stelle mitmachen und eigene »Lessons learned« einbringen/entgegenstellen, sieht die Sache anders aus. In all den Fällen lässt die Diskussions-Form nachvollziehbar, dass und warum man sich zunächst denken mag: »Ja, so geht das.«, nur um später dann doch zu erkennen: »Ne, das war zumindest genau so doch nichts.«, um vielleicht noch später zu erkennen: »War doch was dran, an den ursprünglichen Gedanken«.

Also ich finde die Stelle hier, die hoffentlich auch unmittelbarer zur Kommunikation einlädt als ein Eintrag auf der Projektseite, gut. --NAN 04:45, 15. Apr. 2012 (UTC)

Der Zusammenfassung kann ich nichts mehr hinzufügen. Für große Test habe ich wieder eine Test-PP aufgesetzt. Unter http://www.perrypedia.proc.org:8088 gibt es nun eine ganz große Spielwiese. Im Moment läuft noch der XML-Import. Bei der momentanen Geschwindigkeitr kann vermutlich noch bis übermorgen dauern. --Poldi 08:30, 15. Apr. 2012 (UTC)

NGZ-Angaben [[xxx NGZ|xxx NGZ]] umwandeln

Die ursprüngliche von I-Robot genutzte Form des Suchmusters:

• \[\[([0-9]+) NGZ\|([0-9])+&nbsp;NGZ\]\]

findet zwar die richtigen Stellen, Die Ersetzung durch das Muster:

• [[$2&nbsp;NGZ]]

funktioniert aber nicht richtig.
Das »+« nach der zweiten Klammer muss verschoben werden:

• \[\[([0-9]+) NGZ\|([0-9]+)&nbsp;NGZ\]\]

dann funktioniert auch die Ersetzung mit

• [[$2&nbsp;NGZ]]

Getestet wurde das neue Muster hier.
Sieht jemand noch weitere mögliche Fehlerquellen? --NAN s BOT 05:51, 13. Apr. 2012 (UTC)

PS: Habe den Eintrag hier bereits angepasst, damit zumindest der bereits bekannte Fehler nicht mehr dort steht.

Habe die Form angepasst.

Eine Unterschrift ist dort denke ich auch nur für "Zuletzt ausgeführt von: " notwendig.--NAN 06:02, 13. Apr. 2012 (UTC)

Habe inzwischen einen Test auf zwei »echte« Artikel ausgeführt: Zyklen (Änderung siehe [4]) und Zitonie Kalishan (Änderung siehe [5]).

Hat geklappt. --NAN s BOT 15:36, 13. Apr. 2012 (UTC)

Denke, an Tests ist ja jetzt alles glaufen, was laufen konnte (und das Tagelang auf Einspruch warten, wird ja anscheinend von niemanden erwartet, siehe unten), setze die Änderungen mit allen betroffen Seiten mit Anfangsbuchstaben Z fort. --NAN 16:15, 13. Apr. 2012 (UTC)

Änderungen sind durch, habe jede einzeln kontrolliert, konnte keinen Fehler finden.

Denke inzwischen können wir uns der Sache so sicher sein, dass wir das Suchmuster und das Muster zum Ersetzen, wie es hier nachzulesen/rauszukopieren ist, auf alle restlichen Artikel im Hauptnamensraum anwenden?

Da es seeehr viele sind: Vielleicht sollten wir uns aber wirklich auch Buchstabenweise durcharbeiten? Sind dann jeweils kleinere Gruppen von Änderungen, bei denen man jeweils bei Stichproben nachschauen könnte, ob nicht doch noch irgendwas schief läuft.

Mache selbst auf jeden Fall mal heute nichts mehr in diese Richtung, falls jemand die Änderungen an den Artikeln, die mit Z beginnen ebenfalls prüfen will: Schaut mal hier (eventuell in der Zwischenzeit recht weit unten, oder erst auf der zweiten Seite). --NAN 16:43, 13. Apr. 2012 (UTC)

Bei vielen genommenen Stichproben habe ich keinen Fehler gefunden. --JoKaene 18:48, 13. Apr. 2012 (UTC)

Danke für die Unterstützung.

Setze die Änderungen dann heute fort. Arbeite mich die Buchstaben einzeln durch (bedeutet nur geringen Mehraufwand). Dann kann man immer recht rasch die Bremse ziehen. Aktuell sehen aber immer noch alle Stichproben gut aus. --NAN 06:49, 14. Apr. 2012 (UTC)

Auch von meiner Seite: Stichproben bei »A« und »B« sehen noch immer gut aus. --JoKaene 07:42, 14. Apr. 2012 (UTC)

Danke für die Rückmeldung.

Denke fast, wir könnten das jetzt eigentlich wieder insgesammt laufen lassen, aber nun, ist ja keine Eile und damit auch kein Grund für Risiko. Schau, dass ich die Sache bis heute Nachmittag Buchstabe für Buchstabe durchgehe. --NAN 08:30, 14. Apr. 2012 (UTC)

Ich glaube auch, dass das Suchmuster tadellos funktioniert (auch »C« sieht gut aus). Wenn Du eh Buchstabe für Buchstabe vorgehst, kann man ja auch nach jedem Durchgang noch Stichproben nehmen um sicher zu sein. So kann das Thema heute abgeschlossen werden. --JoKaene 08:43, 14. Apr. 2012 (UTC)

Ich kontrollier bei jedem Buchstaben immer ein, zwei Handvoll Änderungen. Wenn Du auch noch ab und an Zufalls-Stichproben nimmst, passt das sicher. Nochmal danke für die Unterstützung. --NAN 09:00, 14. Apr. 2012 (UTC)

Bin nach wie vor dran. --JoKaene 09:04, 14. Apr. 2012 (UTC)

Done. Es werden keine weiteren Seiten zum Ändern gefunden.

Dank an Poldi für das Ausarbeiten des ursprünglichen Suchmusters und an JoKaene für die QS.

Denke man kann aus diesem ersten größeren Einsatz der Extension »Replace Text« ein paar »Lessons learned« ableiten. Schreibe die die nächsten Tage mal zusammen, zwecks »Knowledge sharing« und so. ;-) --NAN 14:26, 14. Apr. 2012 (UTC)

So, auch ich habe die letzten Änderungen überprüft und weiterhin keine Fehler gefunden. Obwohl man sich relativ schnell sicher sein konnte, dass es funktioniert, fand ich es dennoch gut Blockweise vorzugehen. (Man weiß ja nie!).

... und ein weiterer Dank geht natürlich an NAN für die Umsetzung. :-) --JoKaene 14:40, 14. Apr. 2012 (UTC)

Keine Zusammenarbeit

Weiter unten hatte ich vorgeschlagen, dass niemand ohne vorherige Diskussion hier irgendeine Abfrage ausführen solle (Wiederholungen, nachdem ein Lauf bewiesen hat, dass alles funktioniert, sind natürlich was anderes, geht um die erste Ausführung). Als Mindestlaufzeit für die Diskussion hatte ich volle sieben Tage vorgeschlagen. Falls in der Zeit keine Einwände kämen, sei die Sache meiner Meinung nach cool.
Könnten dadurch Fehler mit 100% Sicherheit vermieden werden: Nein.
Kann die Fehlerwahrscheinlichkeit stark minimiert werden: Ja.
Findet irgendjemand außer mir den Vorschlag gut:
Wie die letzten Änderungen von »I-Robot« zeigen, nein.
Kann ich auch mit leben. Selbst werde ich weiter hier auf der Diskussionsseite Infos liefern und auf gegenseitigen konstruktiven Input hoffen. Ob ich mich selbst an die von mir vorgeschlagene 7-Tage-Frist halten werden: Keine Ahnung. Da das sonst niemand gut findet und sich von daher auch niemand dran gebunden fühlt, fühle aber auch ich mich da nicht so wirklich dran gebunden. --NAN 05:24, 13. Apr. 2012 (UTC)
PS: Man kann Änderungen auch jeweils auf Testseiten, die man als Unterseiten der eigenen Benutzerseite anlegt, testen. Man muss nicht immer gleich auf Artikel im Hauptnamensraum gehen. --NAN 05:24, 13. Apr. 2012 (UTC)

Ehrlich gesagt, hatte ich Deinen Vorschlag schlicht vergessen. :-(

Grundsätzlich fände ich eine entsprechende Umsetzung aber ebenfalls gut, schon, damit jeder Interessierte User nachvollziehen kann, was passiert (Änderungen durch Bots sind ja durch Voreinstellung in der Regel nicht sichtbar).

In dem speziellen Fall, auf den Du hier anspielst, war es meiner Meinung nach aber nicht schlimm, dass dazu nicht groß nachgefragt wurde. Auch wenn es nur eine Vermutung ist, gehe ich doch davon aus, dass dazu Zustimmung geherrscht hätte. Calloberian, der seit einiger Zeit die gleiche Änderung von Hand durchführt, hat auch nicht nachgefragt, ob er es darf und hat damit auch keinen Widerspruch erzeugt. Es handelt sich halt um eine Grundsätzlichkeit, die früher nicht möglich war und sowohl die Darstellung wie auch die Erstellung entsprechender Links vereinfacht. Der Unfall mit I-Robot hätte natürlich auch passieren können, wenn Poldi angefragt und sieben Tage gewartet hätte. --JoKaene 06:46, 13. Apr. 2012 (UTC)

Ich Moment verstehe ich diese Diskussion nicht. Ich hab doch mein Vorhaben hier eingestellt und habe getestet. Leider ist der Test schief gegangen. --Poldi 07:01, 13. Apr. 2012 (UTC)

@JoKaene: Das Problem war ein technisches, wie ich heute Morgen noch kurz rausfinden konnte (siehe hier):

Kurz zusammengefasst: Ein »+« gehört im Suchmuster eine Stelle nach links verschoben.

Kleines Versehen, große Wirkung.

Wie diese Diskussion zeigt etwas, was durchaus auch schon vorm Ausführen, wenn das Suchmuster den zur Diskussion gestellt wird, auffallen kann. Thinman hatte da z.B. relativ schnell gesehen, dass ».« und »,« fehlen. (War zwar dann dort doch kein Fehler, hätte aber sein können.)

Dazu muss das Suchmuster und das Muster für die Ersetzung aber natürlich vor der Ausführung der Änderung zur Diskussion gestellt werten.

@Poldi: Ich konnte bisher nur sehen, dass Du das Muster gestern um 17:37 Uhr ohne vorherige Diskussion unter Perrypedia:Automatisierte_Änderungen eingestellt hast.

Bereits ab 17:32 liefen die Änderungen des Bots.

Wie bitte sollte da irgendjemand Gelegenheit haben, dich auf das kleine Versehen mit dem »+«-Zeichen aufmerksam zu machen? (Welche Diskussion übersehe ich?)

Wenn ich die Beiträge des Bots durchblättere, dann waren das mehr als 4.000 Änderungen? (Kann das wirklich sein?)

Und das nennst Du einen Test?

Was passiert ist, ist passiert und kann auch jedem anderen egal, wie gründlich man sich vorbereitet, ebenfalls passieren.

Aber wie geschrieben: Es wäre absolut einfach die Fehlerwahrscheinlichkeit zumindest zu minimieren.

An Tests (nicht bereits die Änderungen an allen Artikeln) wäre z.B. vorstellbar (und natürlich muss das niemand machen, nur meine aktuellen Gedanken zum Thema):

• Test des Suchmuster mit einem Regex Prüfer (habe Dir ja vor ein paar Tagen einen Link diesbezüglich zugeschickt, gibt es aber mehr)
• Da die Prüfer manchmal mehr können, als unsere Extension: Zusätzlich ein Test mit der Extension, aber auf eine Unterseite der eigenen Benutzerseite. Oder, wenn man unbedingt auf echte Seiten gehen will: Bei der erzeugten Vorschlagliste ganz unten auf die Schaltfläche »Auswahl umkehren« klicken (entfernt alle gesetzten Häkchen), zwei, drei Seiten wieder auswählen und dann testen.

Aber ich rede mir jetzt seit Tagen den Mund fusselig, wie spitze es wäre, wenn wir zusammenarbeiten und voneinander profitieren würden. Wenn es als cool angesehen wird, zum »Test« gleich mal mehrere tausend Seiten zu ändern: Was soll's --NAN 15:30, 13. Apr. 2012 (UTC)

Inzwischen habe ich unter Benutzer Diskussion:I-Robot gelesen, dass Dein Test, Poldi, tatsächlich wie oben von mir vorgeschlagen, mit »Auswahl umkehren« laufen sollte, ging halt schief (versehentlich falsch geklickt).

Ein Grund, warum ich es vorziehe, mit Unterseiten meiner Benutzerseite zu arbeiten (in der Extension auf Namensraum »Benutzer« einschränken und als Präfix z.B. »Benutzer:I-Robot« angeben, schon kommen seeehr viel weniger Seiten in Betracht und alle kannst Du ohne Probleme bearbeiten). Es ist so sehr viel weniger Wahrscheinlich, so einen Fehler zu machen.

Das relativiert Deine Antwort bezüglich »Test« und wenn ich die Info gehabt hätte, bevor ich das oben geschrieben hatte (leider hast Du die Info ja nur auf der anderen Diskussionseite gegeben), wäre mein Tonfall weniger scharf ausgefallen. So war Deine Antwort nach zig fehlerhaften Änderungen halt schon etwas, sagen wir mal, interessant. Für meinen Tonfall entschuldige ich mich nichtsdestotrotz.

Inhaltlich bleiben aber alle von mir aufgeführten Punkte denke ich mal bestehen: Es wäre besser, erst zu diskutieren und für die Diskussion auch ein paar Tage Zeit einzuräumen. Es wäre besser, die Tests nicht gleich im Hauptnamensraum zu machen. --NAN 16:07, 13. Apr. 2012 (UTC)

Es ist gut, dass es eben bei mir zu einem Bearbeitungskonflikt kam. Sonst hättest Du meine Antwort auf deinen Post lesen können ;-) Bei allen Codeanalysen, Testdaten erstellen, Enwickler- und Fachtests usw, habe ich in der Praxis die Erfahrung gemacht, dass erst der Einsatz in der Produktion die wirklichen Fehler zu Tage bringt. Ich hab aber auch gelernt, dass ein Test in der Produktion nur im äußersten Notfall zu machen ist. Daher baue ich am Wochenende für uns eine zweite PP auf, die wir dann auch mal verdaddeln können. --Poldi 16:27, 13. Apr. 2012 (UTC)

Tja, dann ist ja gut, dass ich zufällig deine Antwort auf der Diskussionsseite von I-Robot doch noch gesehen hatte. ;-)

Fasse Deine Antwort mal so auf, dass alle Argumente, die ich gebracht habe, alle Möglichkeiten, die auch ohne eine extra Zweit-PP existieren würden, weiter nicht wahrgenommen werden? Jeder macht halt alleine für sich etwas im Zweit-Wiki und sobald da keine Fehler mehr feststellbar sind, wird im Hauptwiki geändert? Sowas wie gemeinsam was ausarbeiten braucht es dann ja nicht mehr. Finde ich irgendwie schade, aber was soll's.

Davon abgesehen bietet so ein Zweit-Wiki noch mal ein extra Sicherheitsnetz. Sicher notwendig, wenn die von mir oben aufgeführten Möglichkeiten halt mal nicht möglich sind. ;-) --NAN 17:00, 13. Apr. 2012 (UTC)

Zunächst einmal, ich nehme Deine, NANs, Argumente durchaus ernst und unterstütze sie.

Wichtig erscheinen mir zwei Punkte von unterschiedlicher Bedeutung:

1. Eine durch Massenverarbeitung gewünschte Veränderung soll angekündigt werden und Zustimmung oder Ablehnung abgewartet werden. Für welche Dauer wird sich, so denke ich, aus geäußerten Meinungen ergeben. Eine Woche als Richtlinie finde ich aber gut. Sollte sich etwas wie eine Grundsatzdiskussion ergeben, wird das nicht ausreichen, aber eine Verlängerung auch von allein ergeben. An diesem Punkt können sich alle PPnauten beteiligen. Wie viele das aber jeweils sein werden, liegt wohl an der Bedeutung der Änderung.
2. Das Suchmuster sollte, nachdem es auf ungefährliche Weise vom Ersteller getestet und für richtig befunden wurde, hier zunächst öffentlich gemacht werden. (Zeitgleich mit der Änderungsanfrage) Dies gibt qualifizierten Usern die Möglichkeit, es zu überprüfen, eventuell selbst zu testen und letztlich abzusegnen oder Korrekturvorschläge einzubringen. Dazu sind von den aktuell aktiven Benutzern aber offensichtlich nur sehr wenige, vielleicht sogar nur zwei in der Lage. Umso wichtiger erscheint mir dieser Punkt.

Ich könnte mir übrigens gut vorstellen, dass die resultierenden Diskussionen auf unterschiedlichen Seiten stattfinden, da die Darstellung des Suchmusters an sich schon auf viele PPnauten abschreckend wirken könnte. --JoKaene 18:46, 13. Apr. 2012 (UTC)

Stimme Dir zu.

Du greifst auch einen Punkt auf, der zwar bereits auf der Projektseite steht, aber irgendwie wohl untergegangen ist: Die Diskussionen sollten sich auch um den Sinn einer Automatisierung drehen. Das bedeuted einerseits natürlich "ist es fachlich richtig, das so zu machen". Andererseits aber auch "Wie dringend ist es, die Sache in kurzer Zeit durchzuziehen" und "gibt es jemanden, der die Sache lieber manuell macht?". Letztere könnten sich zu Wort melden, falls vor der Ausführung der Änderungen eine Diskussion erfolgt. Eventuell kann man manuelle und automatisierte Änderung auch einfach besser koordinieren.

Na ja, mal abwarten, wie das weiter läuft. --NAN 04:31, 17. Apr. 2012 (UTC)

Ich kenn mich mit den technischen Details nicht so gut aus, darum hab ich mich bis jetzt aus der Diskussion rausgehalten. Trotzdem jetzt ein kleiner Kommentar meinerseits: Wenn ich die Sache richtig mitbekommen habe, war das mit den NGZ-Ersetzungen ein Test-Unfall (beim Testen versehentlich auf den falschen Knopf gedrückt, dadurch ist der Schuss zu früh losgegangen). Andererseits wird wohl kaum jemand freiwillig 4000 oder mehr Artikel manuell ändern, wenn ein Bot bereitsteht, der das ganze mit weniger Arbeitsaufwand machen kann. Insofern halte ich das Zweit-Wiki als Testgelände für eine gute Idee, da dort gefahrlos getestet werden kann (es schadet dort nicht, wenn man sich verklickt, oder das Suchmuster trotz Test auf einer Seite Fehler produziert). Andererseits sind - wie JoKaene sagt - nach den ersten Tests zumindest ein paar Tage Zeit zur Diskussion eine gute Idee, damit die Bot-technisch versierten User Zeit haben, einerseits im Zweit-Wiki die Änderungen stichprobenartig zu prüfen, und ggf. zu debuggen. --Andi47 06:32, 19. Apr. 2012 (UTC)

Default sort am Ende von Artikeln

Wie geht's weiter?

Wie geht es mit dem Thema nun weiter. Ich würde gerne nach Kategorien vorgehen. Ähnlich wie bei den Handlungszummenfassungen können wir die umzustellenden Kategorien auflisten und entsprechend abhaken. --Poldi 08:25, 15. Apr. 2012 (UTC)

Wir haben aktuel auf jeden Fall noch zwei große Vorhaben:

Durch den Vorschlag, Raumschiffe und Raumschiffsklassen nicht mehr als Sonderfall zu betrachten, könnte dort jeweils »PPDefaultsort« angehängt werden. Das macht aber nur Sinn, wenn bei den weiteren dem Artikel zugehörigen Kategorien der bestehende Sortkey entfernt wird. Ist das in einem Durchgang zu machen?

Ähnliches gilt für die Kategorien Personen und Parabegabte. --JoKaene 08:44, 15. Apr. 2012 (UTC)

Was relativ einfach ist, ist das Entfernen des Sortkeys für ausgesuchte Kategorien. Wenn die Artikel dann »geputzt« sind, kann der neue Sortkeys, entweder über DEFAULTSORT oder PPDefault hinzugefügt werden. Als Abwandlung von dieser Vorgehensweise kann für Artikel, die definitv einen DEFAULTSORT benötigen dieser erst aus dem Kategorie-Sortkey gerettet werden und dann als DEFAULTSORT hinzugefügt werden. Dann können alle anderen Kategorie-Sortkey gelöscht werden. Für alle anderen können die Kategorie-Sortkey direkt gelöscht werden und PPDefault hinzugefügt werden. Natürlich können die Kategorien Personen und Parabegabe ausgelassen werden. --Poldi 09:03, 15. Apr. 2012 (UTC)

Unter Perrypedia_Diskussion:Automatisierte_Änderungen#Technisch findet ihr ein allgemeines, nicht auf bestimmte Kategorien festgelegtes Suchmuster zum Löschen der Sortkeys.

Bei Einschränkung auf Kategorie Raumschiffe wäre prinzipiell folgendes Vorgehen vorstellbar:

1. Falls vorhanden bereits gesetzte PPDefaultsort entfernen.
2. Alle Sortkeys entfernen.
3. Bei allen Artikeln PPDefaultsort an das Ende des Artikels setzen (Muster siehe ebenfalls Perrypedia_Diskussion:Automatisierte_Änderungen#Technisch)

Bei Raumschiffsklassen entsprechend.

Kann man wahrscheinlich auch zusammenfassen, macht die Sache nur komplexer, als das Vorgehen in Einzelschritten.

Problem sind die Zahlen, könnte man das Suchmuster für das Löschen der Sortkeys wahrscheinlich noch für anpassen. PPDefaultsort dürfte aber nur gesetzt werden, wenn nicht bereits DEFAULTSORT dortsteht? Eventuell über einen weiteren Schritt lösbar (Wenn DEFAULTSORT und PPDefaultsort, das PPDefaultsort wieder löschen). --NAN 09:31, 15. Apr. 2012 (UTC)

Muster für Sonderfall Zahlen erweitert, siehe hier. --NAN 09:42, 15. Apr. 2012 (UTC)

Mir geht es jetzt nicht so sehr um Technik, sondern mehr um Organisation. Wie wollen wir die Arbeit angehen und aufteilen?--Poldi 10:04, 15. Apr. 2012 (UTC)

Im Grunde kann man die Kategorien in der Reihenfolge abarbeiten, wie sie der Kategorienbaum vorgibt. Da aber bereits sehr viele Sortkeys (Betreff: Umlaute, Sonderzeichen etc.) von Hand in den einzelnen Kategorien vergeben wurden, muss natürlich zuvor die Vorgehensweise geklärt und abgesprochen werden. --JoKaene 10:16, 15. Apr. 2012 (UTC)

@Polid: Je nach Stand der Technik existieren unterschiedliche Möglichkeiten. Das Vorhandensein oder Fehlen von Möglichkeiten ist sicher ein Punkt der wichtig ist?

@JoKaene: Mit dem von mir erwähnten Suchmuster zum Löschen von Sortkeys könnte man beinahe schon einfach ohne Einschränkung auf bestimmte Kategorien arbeiten. Einzig Personen und Parabegabte sind da noch ein Problem (fällt mir gerade ein, könnte man umgehen, indem man Sortkeys mit Komma nicht löscht, muss ich gleich ausprobieren :-) ). Aber verstehe, dass Ihr da endlich weitermachen wollt, dann ist die Idee, auf Kategorien einzuschränken sicher eine gute.

Bezüglich Aufteilen: Den Vorschlag von JoKaene als nächstes Raumschiffe und Raumschiffsklassen anzugehen finde ich gut. Selbst werde ich nach dem Tag gestern aber erstmal etwas kürzer treten. Vom Ausarbeiten von Suchmustern mal abgesehen, das macht ja irgendwie Spaß, :-) hat aber ja nur indirekten (neue Möglichkeiten ergeben sich) Einfluss auf Eure Arbeit. --NAN 10:24, 15. Apr. 2012 (UTC)

Wäre eine Möglichkeit, bei allen Kategorien unterhalb »Perryversum« (außer Personen/Parabegabte) zunächst alle bestehenden Sortkeys zu entfernen? Danach könnte man dann bei allen (inklusive Personen/Parabegabte) PPDefaultsort setzen, sofern nicht bereits DEFAULTSORT oder PPDefaultsort besteht. Dann hätten wir's doch. --JoKaene 10:40, 15. Apr. 2012 (UTC)

Das ist kein Problem. Ich möchte aber noch erklären warum mir mehr die Organisation als die Technik wichtig ist. Wenn wir die Arbeit aufteilen und nur das Ergebnis festlegen, dann können sich auch die PPnauten beteiligen, die keinen Bot haben. Die können die Änderungen auch gerne händisch durchführen. So als Art Zen-Meditation. ;-) NAN oder ich wir können auch gerne eine Liste der Artikel erstellen, die noch kein PPDefault oder DEFAULTSORT enthalten. Die können wir dan auch gerne alphabetisch abarbeiten. Und zwar so, wie es jeder mag oder kann. --Poldi 11:04, 15. Apr. 2012 (UTC)

@JoKaene: Da Beispiele mehr sagen als tausend Worte: ;-)

Eine Möglichkeit:

• AACHTHOM (Sporenschiff) (Schritt1, Schritt2)
• Aa-ki (Schritt1, Schritt2)
• Aachthom (Schritt1, Schritt2)
• Galbraith Deighton (Schritt1, Schrit2)

Sieht soweit gut aus.

Noch nicht geklärte Punkte:

• Kategorien (z.B. Zyklus-Kategorien), bei denen - fehlerhaft - Sortkey mit umgestellten Namensbestandteilen gesetzt wurde (könnte man z.B. manuell nachbearbeiten?)
• Die ganze »doppelt default sort setzen«-Sache. Könnte man wahrscheinlich in einem weiteren Schritt automatisiert, oder halt ebenfalls manuell korrigieren. Hm, kommt mir gerade noch eine Idee, melde mich gleich wieder. --NAN 11:54, 15. Apr. 2012 (UTC)

O.k., habe im Technik-Abschnitt noch Muster ergänzt, um mit versehentlich doppelt gesetzten default sort zurecht zu kommen.

Damit sind die einzige Einschränkung bei den von mir ausgearbeiten Möglichkeiten (falls sich nicht doch noch Probleme zeigen, soo viele Tests habe ich da jetzt auch noch nicht gemacht) »Personen«-Sortkeys bei Kategorien, bei denen sie eigentlich gar nicht gesetzt gehören. Könnte ich eine Liste erstellen, zwecks manuell nachbearbeiten.

Die Organisation bestünde einfach darin, alle Artikel Buchstabe für Buchstabe durchzugehen. Selbst dann ist die Menge bereits sehr groß, man könnte eventuell bis ein gewisses Vertrauen in die Funktionsfähigkeit der Muster aufgebaut ist, auch auf die ersten beiden Buchstaben einschränken (»Aa«, »Ab«, ...)

Denke, Poldi, Du verfolgst einen leicht anderen Ansatz? --NAN

Für mich sieht das Ganze im Moment recht gut aus, auch für weitere Kategorien. Nacharbeiten scheinen mir allerdings gewiss, da es sicher noch Lemmata gibt, die eigentlich DEFAULTSORT brauchen (Raumschiffe mit römischen Zahlen z.B.) Aber es wäre schon ein großer Schritt. --JoKaene 13:02, 15. Apr. 2012 (UTC)

Einen bestimmten Ansatz verfolgte ich bisher nicht. Bei den bisherigen Umstellungen habe die Erfahrung gemacht, dass es besser (sein könnte) ist, in einem Artikel alle Sortkeys zu überarbeiten. Damit kommen doppelte DEFAULTSORT oder PPDefaultsort gar nicht erst vor. Der Nachteil ist aber, dass man bis zu Ende der Aktion ein Mix in den Kategorien hat. Auch das Abarbeiten über die Kategorien, so wie wir es bisher gemacht haben, ist dann nicht optimal. Bei der Variante Buchstabe nach Buchstabe muss man ein bisschen mehr organisieren. Und wie gesagt, ich möchte, dass sich auch andere PPnauten an der Aktion beteiligen können. --Poldi 13:20, 15. Apr. 2012 (UTC)

Habe noch eine (zumindest weitgehend) automatisierte Lösung für die Sache mit den »Personen«-Sortkeys ausgearbeitet.

Ein mögliches Vorgehen sähe vom Prinzip dann so aus:

1. Explizit gesetzte Sortkeys ohne Einschränkung auf bestimmte Kategorien löschen (was stehen bleiben soll, bleibt stehen, plus unerwünschter »Personen«-Sortkeys)
2. Bei allen Artikel am Ende PPDefaultsort setzen (Einschränkung siehe oben).
3. Nacharbeit eingeschränkt auf Kategorie Personen, um bei den falschen Kategorien gesetzte »Personen«-Sortkeys auch noch zu löschen.

(Details siehe Technik-Abschnitt)

Kommt dem Vorschlag von JoKaene schon recht nahe.

Denke, falls man sich zu diesem Vorgehen entschließt, sollte man das ganze einmal komplett im Zweit-Wiki durchspielen. Dort könnte man dann auch schon sehen, ob durch bei allen Artikeln gesetzten PPDefaultsort nicht doch noch Performance-Probleme auftreten.

Andere, die unabhängig von der automatisierten Lösung was machen wollen, obwohl es nicht notwendig ist, können das natürlich machen. Wenn jemand z.B. einen Buchstaben übernehmen will, oder schon mal die falsch gesetzten »Personen«-Sortkeys bereinigen will: Klar.

Denke die Organisation bestünde dann einfach darin, dass sich Leute hier melden und wir das dann beim automatisierten Ausführen berücksichtigen (Sachen halt einfach nicht machen, an denen bereits jemand anders arbeitet).

Nur, an der automatisierten Lösung, Poldi, können sich bezüglich Ausführung nur zwei beteiligen, nämlich wir beide.

Unterstützen kann dann jeder wieder bei der QS und bei eventuell aktuell noch nicht erkannten Nacharbeiten. (Und natürlich bereits hier, beim Diskutieren, Lösung erarbeiten :-) )--NAN 13:31, 15. Apr. 2012 (UTC)

@NAN. Nachdem Deine weiteren Tests zur »Entfernung der Namen in falschen Kategorien« erfolgreich waren, kann man diese schrittweise Vorgehensweise ernsthaft ins Auge fassen. Allerdings bin ich mit Dir der Meinung, dass dies erst in der »Spielwiesen-PP« in größerem Rahmen getestet werden sollte - aber die ist ja noch nicht soweit. Daneben werde ich mir noch mal die Kategorien anschauen und auflisten, welche noch abgearbeitet werden müssen.

Eine Frage noch: Macht es Sinn, wo es notwendig ist, bereits vor einer Massenänderung DEFAULTSORT zu vergeben (z.B. Raumschiffe mit römischen Zahlen) oder ist das kontraproduktiv? --JoKaene 17:21, 15. Apr. 2012 (UTC)

Sollte zwar funktionieren, bzw. auf das ganze automatisch Ändern keinen Einfluss haben, mein Bauchgefühl sagt mir aber: Besser, das mit dem DEFAULTSORT noch zu schieben. Na ja, manchmal ist mein Bauchgefühlt auch übervorsichtig, leg ruhig los. (Aber setze das DEFAULTSORT bitte ganz ans Ende der Artikel).

Poldi denkt, das Spielwiesen-Wiki ist spätestens Übermorgen einsatzbereit.

Anders als im Produktiv-System müssen wir dort - außer Poldi hat Einwände - keine gesteigerte Vorsicht walten lassen, sprich: Wir können mit einer Abfrage auf einen Artikel sicherstellen, das Suchmuster richtig kopiert zu haben und dann mit einer einzigen weiteren Abfrage, das Entfernen aller Sortkeys über alle Artikel ausführen. Ähnlich kann das Hinzufüge der PPDefaultsort-Vorlage bei allen Artikeln angestoßen werden. Wahrscheinlich besser, wenn wir warten, bis das erste durch ist, aber trotzdem: Sicher selbst an einem Arbeitstag binnen 24 Stunden, eher sehr viel weniger, abschließbar.

Mal angenommen, es tauchen keine größeren Probleme auf: Wir wären dann spätestens Mittwoch so weit, dass wir auch im Produktiv-System richtig loslegen könnten.

PS: Eine Einschränkung auf Kategorien schadet natürlich nicht, ist aber mal von der Sache mit der Personen-Kategorie bei dieser Vorgehensweise nicht notwendig.

PPS: Denke für Dich wäre der Einsatz der Extension ebenfalls eine Option. Falls Du mit regex nicht ganz so bewandert sein solltest: Die können auch andere liefern. Die Ausführung wäre aber sicher auch was für Dich. Vielleicht willst Du ja im Zweit-Wiki etwas damit spielen. Bin sicher, Du wirst sehen, dass gerade mit der Einschränkung auf einen bestimmten Präfix die Sache relativ ungefährlich ist. --NAN 18:23, 15. Apr. 2012 (UTC)

Ja, ich leg dann mal los (morgen ;-)). Zur Extension: Solange ich es nicht geschafft habe, mit dem AWB wenigstens einen Edit auszuführen, sollte ich es uns allen nicht antun, mit ihr arbeiten zu wollen. --JoKaene 18:41, 15. Apr. 2012 (UTC)

Wenn Du auch nur einen Edit mit AWB schaffst, dann bekommst Du von mir sofort alle Rechte die so ein Wiki her gibt verliehen! Um mit AWB arbeiten zu können, brauchst Du einen User mit Bot-Rechten :-)) Und solange Du den nicht hast, wird es auch mit dem edit nichts. --Poldi 18:45, 15. Apr. 2012 (UTC)

Verdammt!! Ich hatte es mir schon gedacht, als ich es nicht einmal geschafft habe, mich einzuloggen. Ist mit einem Dump zu arbeiten die richtige Vorgehensweise zum Üben? --JoKaene 18:51, 15. Apr. 2012 (UTC)

Nachdem ich jetzt auf der Zweit-PP dank des ohne Nachfrage erhaltenen Bot-Status doch mal etwas mit der Extension »gespielt« habe, musste ich erkennen, dass es doch nicht sooo schwer ist - solange ich auf regex verzichte. Ich habe also »JoBot« angemeldet. Für einfache Textersetzungen ist es ein Werkzeug, das mir keine Schwierigkeiten bereitet. Was sich daraus ergibt, werden wir sehen. --JoBot 17:59, 17. Apr. 2012 (UTC) Falsche Unterschrift! Hier die richtige. --JoKaene 18:00, 17. Apr. 2012 (UTC)

DEFAULTSORT bei Heftzusammenfassungen

• Silberband sind erledigt --Poldi 18:13, 10. Apr. 2012 (UTC)
• Perry Rhodan-Heftrome sind erledigt --Poldi 18:13, 10. Apr. 2012 (UTC)
• Planetenromane --Poldi 18:55, 13. Apr. 2012 (UTC)
• Perry Rhodan-Taschenbuch --Poldi 18:56, 13. Apr. 2012 (UTC)
• Atlan-Heftroman --Poldi 19:04, 13. Apr. 2012 (UTC)
• Blauband --Poldi 19:04, 13. Apr. 2012 (UTC)
• Atlan-Taschenbuch --Poldi 19:04, 13. Apr. 2012 (UTC)
• Hörspiel (Handlung) Scheint nicht so einfach zu sein. Die Extension kann die Kategorie nicht selektieren. --Poldi 19:14, 13. Apr. 2012 (UTC) )
• Kurzgeschichte --Poldi 19:54, 13. Apr. 2012 (UTC)

Um besser unterscheiden zu können ob ein Artikel bereits korrekt bearbeitet wurde, setze ich immer entweder PPDefaultsort oder DEFAULTSORT an das Ende des Artikel. In einigen Fällen ist das zwar nicht unbedingt nötig, es schadet aber auch nicht. Für die Fälle, wo bereits in der Kategorie der Sortkey angegeben ist, wird dieser kopiert. Die Regex für die Extension Text ersetzen ist Kategorie:Perry Rhodan-Heftroman\|(.+)\]\] und wird ersetzt durch Kategorie:Perry Rhodan-Heftroman]] Für den Fall, dass der ursprüngliche Sortkey noch nicht den neuen Regeln entspricht muss dieser leider manuell angepasst werden. --Poldi 18:13, 10. Apr. 2012 (UTC)

Ich wollte mich noch für die schöne Übersicht bedanken. Wenn man Dir so zuschaut - kann ja ganz schön flott gehen! --JoKaene 18:54, 11. Apr. 2012 (UTC)

Bei Zusammenfassungen können noch die Kategorien Handlungszusammenfassungs-Stubs und Fehlende Daten vorkommen. Wenn PPDefaultsort oder DEFAULSORT gesetzt ist, können die Sortkey pro Kategorie gelöscht werden. --Poldi 19:54, 13. Apr. 2012 (UTC)

Ich kümmer mich drum, auch um Kategorie:Hörspiel (Handlung).

Ist mir gerade aufgefallen, es gibt auch noch die Kategorie:Hörspiele. --JoKaene 20:07, 13. Apr. 2012 (UTC)

Kategorie »Hörspiel (Handlung)« wurde jetzt erledigt. --JoKaene 15:49, 14. Apr. 2012 (UTC)

Extension Replace Text nutzen, um Fehler zu finden

Beim oben beschriebenen Vorgehen rutschen ab und an noch Fehler rein. Relativ leicht finden lassen sich diese, indem die »Listen erstellen«-Funktion z.B. der Extension Replace Text genutzt wird: Als Suchmuster '''(\{\{PPDefaultsort\}\})''' eingeben, im Eingabefeld »Neuer Text« folgendes eingeben: $1, Vorschau anzeigen lassen (nicht ausführen):
Die Vorschauliste enthält dann z.B. auch Einträge wie:
Balladen des Todes (Blauband) - …t unterer Teil [[Kategorie:Blauband]] '''{{PPDefaultsort}}''' [[Kategorie:Handlungszusammenfassungs-Stubs|B…
Das fällt in der Liste, in der ansonsten fast immer '''{{PPDefaultsort}}''' am Ende steht auf, man kann kurz auf die Seite springen und die notwendige Korrektur ([6]) machen.
PS: Die Klammern um das Suchmuster und das $1 sind nur Sicherheitsmaßnahmen: Sollte man doch mal versehentlich auf »Ersetzen« Klicken, so passiert dadurch im Endeffekt nichts, da einfach '''{{PPDefaultsort}}''' durch '''{{PPDefaultsort}}''' ersetzt würde. --NAN 04:50, 12. Apr. 2012 (UTC)

Fachlich

Über Vorlage:PPDefaultsort wurde eine Möglichkeit zur Verfügung gestellt, die Standardsortierung zu verwirklichen (mit einigen definierten Ausnahmen, siehe Vorlage Diskussion:SortKey#Version 1.0).
Prinzipiell könnte die Vorlage einfach bei allen Artikeln gesetzt werden, die Ausnahmen müssen so oder so extra realisiert werden, indem bei den Kategorien noch mal extra Sortierschlüssel gesetzt werden. Die Vorlage stört die Sortierung aber nie. Sie ist nur ab und an überflüssig.
Unklar ist allerdings bisher auch, inwiefern die Vorlage den Server belastet. Aus entsprechenden Messungen könnte sich ergeben, dass sie wirklich nur dann gesetzt werden soll, wenn sie auch benötigt wird. Was die Sache aber etwas komplizierter machen würde.
Des weiteren existieren mehrere tausend Artikel, bei denen noch vor der Schaffung der Vorlage bereits extra Sortierschlüssel bei den einzelnen Kategorien gesetzt wurden, die wiederum durch das Setzen der Vorlage überflüssig würden. Wiederum: Die beiden Sachen stören sich nicht, ist aber unschön, überflüssige Sortierschlüssel bei den einzelnen Kategorien sollten gelöscht werden.
Ein weiterer Punkt sind Artikel, bei denen bereits die Vorlage DEFAULTSORT gesetzt wurde. Diese dürfte in Kombination mit PPDefaultsort tatsächlich zu Fehlern führen (im Endeffekt würden zwei Standardsortierschlüssel gesetzt, selbst wenn diese gleich sind »mag« das die Wiki-Software nicht).
Vorstellbar sind mehrere Vorgehensweisen, eine nachträgliche »unabhängige« Prüfung z.B. durch Auswerten des XML-Dumps wäre aber wohl auf jeden Fall angebracht. Eine mögliche Vorgehensweise wäre denke ich:

1. Alle DEFAULTSORT entfernen.
2. In allen Artikeln am Ende das PPDefaultsort setzen.
3. Alle mehrfachen PPDefaultsort entfernen (nach Schritt zwei, falls da aufgrund technischer Schwierigkeiten Dubletten reingerutscht sein sollten).
4. Bei allen Kategorie-Tags, für die PPDefaultsort funktioniert, eventuell vorhandene explizite Sortierschlüssel entfernen, außer sie beginnen mit einem Leerzeichen, dann sollten sie durch Leerzeichen{{SortKey}} ersetzt werden.

Habe ich die Sache einigermaßen korrekt zusammengefasst? --NAN 08:11, 6. Apr. 2012 (UTC)

Die Zusammenfassung erscheint mir richtig!

Aktuell sind knapp 1300 Artikel mit {{PPDefaultsort}} versehen. Laut Poldi gibt es noch keine Beeinträchtigung der Performance. (Ergibt sich eigentlich eine permanente Belastung oder entsteht sie nur beim Aufruf von Kategorieseiten?)

{{DEFAULTSORT:}} ist weniger als 200 mal verwendet worden und kann vollständig durch {{PPDefaultsort}} ersetzt werden. (Dann wären wir das schon mal wieder los)

Da es doch sehr viele Artikel gibt, deren Sortierung mit {{PPDefaultsort}} nicht funktioniert (einleitende Artikel »der, die, das« sowie die hier aufgeführten Ausnahmen) sollte die Vorlage aber nicht grundsätzlich überall eingefügt werden. Da muss man wohl selektiver vorgehen. --JoKaene 08:55, 6. Apr. 2012 (UTC)

Zur Ergänzung: Die Ausnahmen sind auf Artikel bezogen natürlich recht relativ. So dürfte bei den meisten Personen-Artikeln, Raumschiff-Artikeln, ... z.B. eine Kombination aus PPDefaultsort (z.B. für die Zyklus-Kategorien) und eben den Ausnahmen angebracht sein...

Ich schau mal, ob ich da Zahlen ermitteln kann. --NAN 09:49, 6. Apr. 2012 (UTC)

Die Zahlen lassen noch etwas auf sich warten. Zwischenzeitlich ist mir aber eingefallen, dass der erste Schritt prinzipiell falsch wäre, da das DEFAULTSORT durchaus seinen Zweck hat, z.B. bei Artikeln mit einer Zahl im Namen: So kann einfach in allen Kategorien die richtige Form gesetzt werden. Das ganze müsste also eher so aussehen?

1. In allen betroffenen Artikeln am Ende das PPDefaultsort setzen.
2. Alle mehrfachen PPDefaultsort entfernen (nach Schritt zwei, falls da aufgrund technischer Schwierigkeiten Dubletten reingerutscht sein sollten).
3. Alle überflüssigen DEFAULTSORT entfernen.
4. Bei allen Kategorie-Tags, für die PPDefaultsort funktioniert, eventuell vorhandene explizite Sortierschlüssel entfernen, außer sie beginnen mit einem Leerzeichen, dann sollten sie durch Leerzeichen{{SortKey}} ersetzt werden.

--NAN 04:42, 7. Apr. 2012 (UTC)

Ich habe gerade noch mal überprüft, wo {{DEFAULTSORT:}} eingesetzt wurde, und es sind ausschließlich normale Lemmata. Es bleibt also dabei, dass die Einträge komplett durch {{PPDefaultsort}} ersetzt werden können. --JoKaene 07:03, 7. Apr. 2012 (UTC)

Na ja, das ist aktuell so. Eventuell können wir die Abfrage aber auch so gestalten, dass sie ab und an wiederholt werden kann. Und dann wäre das doch ein wichtiger Punkt, den warum sollte man bei z.B. Titeln mit Zahlen bei jeder Zyklus-Kategorie einen Text hinzufügen, wenn ein DEFAULTSORT auch genügen würde? --NAN 07:22, 7. Apr. 2012 (UTC)

Ich gehe dabei nur von der aktuellen Situation aus und da würde ich schon ersetzen. Hätte die Vorlage früher zur Verfügung gestanden, hätte ich sie ja in den betreffenden Fällen auch angewendet. Dass {{DEFAULTSORT:}} dennoch sinnvoll ist, ist natürlich klar. --JoKaene 07:45, 7. Apr. 2012 (UTC)

Bisher gingen wir davon aus, dass wir nicht automatisiert unterscheiden können, ob ein PPDefaultsort wirklich notwendig ist (zwecks Sonderzeichen oder ähnlichem), oder nicht. Das bisher diskutierte Vorgehen setzt die Vorlage einfach in jedem Artikel, schadet ja in keinem Fall.
Beim Testen der Muster für das Ersetzen explizit gesetzter SortKeys ist mir aufgefallen: Dank der erfolgten Vorarbeit von JoKaene und Klenzy können wir das doch unterscheiden!
Alle explizit gesetzten SortKeys (mit Ausnahme jener, die sich in der Kategorie Personen befinden), sind korrekt gesetzte SortKeys. Bei allen Artikeln, bei denen SortKeys gesetzt gehören, wurden diese auch gesetzt. Wir sind in der Lage, diese Artikel für das Löschen der SortKeys zu erkennen. Also sind wir, solange wir das Löschen noch nicht gemacht haben, auch in der Lage zu erkennen, wo ein PPDefaultsort gesetzt gehört.
Das Vorgehen bestünde zunächst immer noch in zwei Schritten ohne Einschränkung auf Kategorien:

1. PPDefaultsort in allen Artikeln setzen, bei denen zu löschende SortKeys enthalten sind.
2. Alle zu löschenden SortKeys löschen.

Die Kategorie Personen müsste dann nachbearbeitet werden:

1. Alle falsch gesetzten »Personen«-SortKeys löschen
2. Bei allen Artikeln in der Kategorie Personen am Ende das PPDefaultsort setzen, falls es nicht bereits dort steht.

Zum einen, würden so unnötig gesetzte PPDefaultsort vermieden werden.
Zum anderen hätte die enorme Arbeit, die JoKaene und Klenzy bereits geleistet haben, einen Sinn, würde genutzt und nicht einfach platt gemacht.
Was denkt Ihr? --NAN 05:26, 16. Apr. 2012 (UTC)

Das bedeutet also, dass am Ende auch nur dort PPDefaultsort gesetzt wird, wo es auch benötigt wird? (Aufgrund der Vorarbeit, die ja ebenfalls nur entsprechende Lemmata berücksichtigte.) Bleiben die Begriffe, die eigentlich DEFAULTSORT benötigen. Allerdings fallen mir dazu im Moment nur Planeten und Raumschiffe mit (römischen) Zahlen ein, die ja auch manuell recht einfach zu finden wären. So macht Dein Vorschlag zur Vorgehensweise auf mich einen guten Eindruck. Umfangreicherere Tests auf der Zweit-PP sollten sein, aber dass siehst Du ja eh genauso. --JoKaene 06:09, 16. Apr. 2012 (UTC)

Dann wäre es wohl von Vorteil, wo es benötigt wird, DEFAULTSORT doch zunerst zu setzen!? --JoKaene 06:30, 16. Apr. 2012 (UTC)

Diese Sache ist unabhängig von der automatisierten Änderung. Mach es einfach, wenn es Dir Spaß macht. :-) --NAN 07:12, 16. Apr. 2012 (UTC)

Spaß ist in dieser Hinsicht zwar ein relativer Begriff geworden, aber ich bin tapfer. ;-) Ich geh's mal an. --JoKaene 07:24, 16. Apr. 2012 (UTC)

Ich beginne dann mal mit dem ersten Test im Zweit-Wiki. --NAN 19:03, 16. Apr. 2012 (UTC)

Für Buchstabe A wurden die ersten beiden Schritte ausgeführt, können auf Fehler geprüft werden. --NAN 04:44, 17. Apr. 2012 (UTC)

Sehe gerade: Geht langsamer als im Hauptwiki, insgesamt waren es bei Schritt 2 um die 1200 Änderungen, aktuell werden 3 pro Minute ausgeführt, dauert also doch noch 'ne Weile. Die Artikel, die heute von NAN2 geändert wurden, könnten aber bereits auf Fehler geprüft werden. --NAN 04:52, 17. Apr. 2012 (UTC)

Technisch

Habe die Diskussion zum Technischen Aspekt mal extra gesetzt. Denke wir sollten uns erst mal klar werden, was wir eigentlich fachlich wollen (siehe oben) --NAN 08:11, 6. Apr. 2012 (UTC)

Denke, die fachliche Seite ist inzwischen so klar, dass man daran gehen kann, die technische Umsetzung auszuarbeiten. Wenn sich weitere fachliche Sachen ergeben, kann man die ja trotzdem noch nennen, und die technische Umsetzung hier entsprechend anpassen.

Falls die Sache gut läuft, könnten wir aber denke ich mal bereits nächstes Wochenende die automatisierten Änderungen ausführen.

Fange mal mit einem einfachem, noch nicht vollständigem Muster an:

• Suchmuster: $ (Das Muster findet das Ende des Textes, Zeilenumbrüche werden in der von MySQL genutzten Form ignoriert)
• Wird ersetzt durch: {{PPDefaultsort}}

Jetzt müssen nur noch verschiedene Sonderfälle und Erweiterungen mit rein. Eventuell sollten wir die regex aber auch relativ einfach halten und das gewünschte Endergebnis durch ausführen von zwei, drei verschiedenen Änderungen nacheinander erreichen. --NAN 10:09, 9. Apr. 2012 (UTC)

Gerade oben nachgelesen, wurde zwar angedeutet, aber noch nicht so wirklich deutlich erwähnt:

Mit der Extension »Replace Text« ist bezüglich Suchmuster kein Zugriff auf den Artikelnamen möglich. Es ist von daher nicht möglich, zu erkennen, wenn der Name nur aus einem Wort besteht und auch sonst kein Grund vorhanden ist, eine der Vorlagen zu setzen.

Kann man z.B. umgehen, indem der Verwender der Extension aus einer von der Extension gelieferten Vorschlagsliste von zu ändernden Artikeln manuell alle Artikel rausnimmt, bei denen auf die Vorlage PPDefaultsort verzichtet werden kann.

Man kann aktuell auch darauf bauen, dass die Sortkeys bei fast allen Artikeln bereits korrekt gesetzt werden, und darüber die Info bezüglich Artikelname beziehen.

Man könnte sich ein Konstrukt überlegen, dass auf den ersten zwischen »'''« stehenden Text - eben den Artikelnamen - zugreift.

Oder, man könnte einfach überall PPDefaultsort setzen, weil die Vorlage auch nie stört.

Das Problem ist also mit der Extension soweit absehbar durchaus lösbar, zeigt aber, dass das eventuell eine jener automatisierten Änderungen ist, die leichter mit einem »echten« Bot erledigt werden könnten. --NAN 04:33, 10. Apr. 2012 (UTC)

Habe zwischenzeitlich zusätzlich ein Muster ausgearbeitet, dass Sortkeys löscht, außer, wenn davor ein Leerzeichen steht. ([7]).

• Suchmuster: \[\[ *Kategorie:([^]]*)\|[^ ][^]]*\]\]
• Muster zum Ersetzen: [[Kategorie:$1]]

Scheint wie der Test zeigt zu funktionieren, vor einem größeren produktiven Einsatz sollte es aber erst an weiteren Seiten getestet werden.

Lookahead scheint übrigens nicht im Rahmen der Möglichkeiten unserer Extension zu liegen. Schade, wäre eine elegante Lösung für das zusätzliche Ausklammern der Personen-Kategorie gewesen, geht aber denke ich auch ohne. Arbeite dran. --NAN 09:03, 15. Apr. 2012 (UTC)

Habe das Muster weiter verfeinert, ebenfalls nicht gelöscht werden dürfen explizite Sortkeys, in denen Zahlen vorkommen (wurden dann wohl wegen der Sonderregel für Sortierung von Zahlen gesetzt).

• Suchmuster: \[\[ *Kategorie:([^]]*)\|[^ ][^]0-9]*\]\]
• Muster zum Ersetzen: [[Kategorie:$1]]

Getestet hier. Mehr Tests würden sicher nicht schaden. --NAN 09:39, 15. Apr. 2012 (UTC)

PS: Ein Teil der Diskussion läuft inzwischen weder unter fachlich, noch unter technisch sondern hier. --NAN 09:41, 15. Apr. 2012 (UTC)

Habe das Muster weiter verfeinert, ebenfalls nicht gelöscht werden nun explizite Sortkeys, in denen Komma vorkommen. Das entspricht zwar nicht ganz der eigentlich angestrebten Lösung für Kategorie Personen und Parabegabte, aber kommt beim aktuellen Stand unserer Artikel wohl doch recht nahe an die eigentliche Lösung ran:

• Suchmuster: \[\[ *Kategorie:([^]]*)\|[^ ][^]0-9,]*\]\]

Ungetestet, müsste aber eigentlich besser sein (erstes Zeichen kann schließlich bereits eine Zahl sein):

\[\[ *Kategorie:([^]]*)\|[^ 0-9][^]0-9,]*\]\] --NAN 12:53, 15. Apr. 2012 (UTC)

Getestet, sieht gut aus. --NAN 05:27, 16. Apr. 2012 (UTC)

• Muster zum Ersetzen: [[Kategorie:$1]]

Getestet hier. Mehr Tests würden sicher nicht schaden. --NAN 09:39, 15. Apr. 2012 (UTC)

Der nächste Schritt ist dann wohl mal ein Test auf eine stark eingeschränkte Menge echter Artikel.

Mache das mal. --NAN 11:23, 15. Apr. 2012 (UTC)

Test durchgeführt:

• AACHTHOM (Sporenschiff) (Schritt1, Schritt2)
• Aa-ki (Schritt1, Schritt2)
• Aachthom (Schritt1, Schritt2)
• Galbraith Deighton (Schritt1, Schritt2)

Sieht soweit gut aus.

Noch nicht geklärte Punkte:

Kategorien (z.B. Zyklus-Kategorien), bei denen - fehlerhaft - Sortkey mit umgestellten Namensbestandteilen gesetzt wurde (könnte man z.B. manuell nachbearbeiten?)

Die ganze »doppelt default sort setzen«-Sache. Könnte man wahrscheinlich in einem weiteren Schritt automatisiert, oder halt ebenfalls manuell korrigieren. --NAN 11:49, 15. Apr. 2012 (UTC)

Es erscheint mir schwierig, ohne die Möglichkeit von Lookahead bzw. Lookbehind Matches auszuschließen, bei denen der default sort bereits gesetzt wurde. Arbeitet man z.B. mit einzelnen verneinten character classes, kann es leicht passieren, dass zu viel ausgeschlossen wird.

Folgende Kombination von Suchmuster und Muster zum Ersetzen bei Schritt 2 scheint die Sache aber zu erledigen

Suchmuster:

([^}][^}])$

Muster zum Ersetzen.

$1

{{PPDefaultsort}}

Geht davon aus, dass die »default sort«-Sachen am Ende des Artikels stehen und dass prinzipiell falls am Ende des Artikels eine Vorlage steht, kein default sort gesetzt werden muss.

Hm, falls man doch lieber einen weiteren Schritt zum Löschen von doppelten Vorlagen nutzen möchte:

Suchmuster:

{{PPDefaultsort}}([^{]*){{PPDefaultsort}}

Muster zum Ersetzen.

$1{{PPDefaultsort}}

zu ersetzen ([8]). --NAN 12:33, 15. Apr. 2012 (UTC)

Ein Problem des oben angeführten Musters zum Löschen explizit bei den Kategorien gesetzter Sortkeys ist, dass »Personen«-Sortkeys in Kategorien, bei denen eigentlich keine gesetzt werden sollten, nicht mit erfasst werden.

Dachte zunächst, da müsse man bei diesem Ansatz manuell nacharbeiten.

Wenn man einen weiteren Schritt ausführt, indem man auf die Kategorie Personen einschränkt, dann kann man aber auch folgendes machen:

Suchmuster:

\[\[ *Kategorie:([^]P]+)\|[^ 0-9][^]0-9,]*,[^]0-9,]*\]\]

Muster zum Ersetzen.

[[Kategorie:$1]]

Tests:

• [9], [10], [11], [12], [13]

• Nachtrag: Alle 210 Artikel der Kategorie Personen, deren Name mit A beginnt und die das Suchmuster enthielten. Jede Änderung einzeln kontrolliert. Keine Fehler gefunden. --NAN 16:26, 15. Apr. 2012 (UTC)

Ist nicht perfekt, Zyklus-Kategorien, die mit »P« beginnen, bleiben z.B. außen vor, aber das könnte man dann bei einem weiteren Durchlauf noch beachten.

Von daher könnte man mit dem bisher ausgearbeiteten Mustern wie folgt vorgehen:

1. Explizit gesetzte Sortkeys ohne Einschränkung auf bestimmte Kategorien löschen (was stehen bleiben soll, bleibt stehen)
2. Bei allen Artikel am Ende PPDefaultsort setzen (Einschränkung siehe oben).
3. Nacharbeit eingeschränkt auf Kategorie Personen, um bei den falschen Kategorien gesetzte »Personen«-Sortkeys zu löschen.

Denke, falls man sich zu diesem Vorgehen entschließt, sollte man das ganze einmal komplett im Zweit-Wiki durchspielen. Dort könnte man dann auch schon sehen, ob durch bei allen Artikeln gesetzten PPDefaultsort nicht doch noch Performance-Probleme auftreten. --NAN

Muster, um bei allen Artikeln PPDefaultsort zu setzen, bei denen explizite Sortkeys vorhanden sind, die aber nicht Sonderfall Personen oder Sonderfall Oberbegriff oder Sonderfall Zahlen entsprechen:

Suchmuster:

((\[\[ *Kategorie:[^]]*\|[^ 0-9][^]0-9,]*\]\][^}]*[^}])+)$

Muster zum Ersetzen.

$1

{{PPDefaultsort}}

Test: [14]

Weitere Tests scheinen angebracht. --NAN 05:33, 16. Apr. 2012 (UTC)

Änderungen laufen

Da leider auch unnötige explizite sortkeys gesetzt wurden, wird das PPDefaultsort auch bei einigen Artikeln gesetzt, bei denen man auch darauf verzichten könnte. Aber nun, besser, als bei wirklich jedem Artikel PPDefaultsort zu setzen, ist das trotzdem noch. Bei Kategorie Personen wird dann auch immer das PPDefaultsort gesetzt. Die allermeiste Zeit sollte das dort auch notwendig sein, bei Namen, die nur aus einem Wort bestehen und keine Sonderzeichen enthalten, wird das PPDefaultsort aber ebenfalls nicht benötigt, schadet aber auch nicht. --NAN s BOT 18:59, 17. Apr. 2012 (UTC)

ADVENTUROUS zeigt ein Problem der Abfrage: Schritt 1 erkennt nicht, dass PPDefaultsort gesetzt werden muss. Liegt daran, dass sich die Kategorie mit dem zu löschenden Sortkey ganz am Ende befindet. Untersuche das und führe bis zur Lösung keine weiteren Änderungen aus. --NAN s BOT 19:12, 17. Apr. 2012 (UTC)

Lösung für ADVENTUROUS gefunden.

Tests mit einzelnen Artikeln, ob dadurch was anderes nicht mehr funktioniert, folgen. --NAN s BOT 19:34, 17. Apr. 2012 (UTC)

Test mit allen 8 mit Präfix »Ae« gefundenen Artikeln: O.k.

Gegenprüfung mit altem Suchmuster: Findet keine zustäzlichen Artikel => Durch neues Muster fallen - zumindest mal im geprüften Bereich - keine Artikel unter den Tisch, die mit dem alten beachtet wurden.

Suchmuster auf Projektseite korrigiert. --NAN s BOT 19:46, 17. Apr. 2012 (UTC)

Test mit allen 11 mit Präfix »Af« gefundenen Artikeln: O.k.

Melde mich dann mal für heute ab. Wenn wir uns bezüglich Funktionsfähigkeit der Muster noch etwas sicherer sind, können wir dann ja auch mehr auf einmal und damit schneller weitermachen. --NAN 19:56, 17. Apr. 2012 (UTC)

OK. Dann »Gute Nacht«! Sag Bescheid, wenns weitergeht, damit ich pünktlich die Bot-Änderungen zuschalte. --JoKaene 20:00, 17. Apr. 2012 (UTC)

Danke für deine Mithilfe, JoKaene.

Ich mache dann mal mit dem Buchstaben A weiter (der aus irgendwelchen technischen Gründen auch mit Ü beginnende Artikel mit einschließt).

Denke, wir können uns inzwischen ziemlich sicher sein, dass bei unserem Vorgehen keine echten Fehler reinkommen. Lasse daher alle Artikel auf einmal ändern. Auch, weil ich heute den ganzen Tag über keine Zeit habe und wir von daher sonst nicht so wirklich weiterkommen.

Sollten doch Fehler reinkommen, kümmere ich mich natürlich Abends darum.

@JoKaene, da Du ja inzwischen ebenfalls ein Bot bist (noch kurz: Gratulation! ;-) ): Vielleicht willst Du ja im Zweit-Wiki mal testen, wie Du unter Nutzung der oben erklärten Vorgehensweisen mit Präfix, mehreren offenen Registerkarten und Zurück-Schaltfläche mit dem Anwenden des hier beschriebenen (für jeden Präfix erst Schritt 1, dann Schritt 2, dann Wiederholen, Schritt 3 und 4 zunächst noch ignorieren) zurechtkommst. --NAN 04:41, 18. Apr. 2012 (UTC)

Habe diesen Eintrag erst jetzt gesehen. Ja, warum nicht! Ich schau's mir morgen mal an. --JoKaene 18:47, 18. Apr. 2012 (UTC)

Für alle Seiten mit Anfangsbuchstaben A Schritt 1 ausgeführt, 1136 Artikel betroffen, warte mit Ausführung von Schritt 2, bis der erste durch ist. --NAN s BOT 04:49, 18. Apr. 2012 (UTC)

Für alle Seiten mit Anfangsbuchstaben A Schritt 1 beendet, Schritt 2 gestartet, 1136 Artikel betroffen. Wird 'ne Weile laufen, kann dann vor der Arbeit nichts weiter machen.

Stichproben von Schritt 1 sahen übrigens alle gut aus. --NAN s BOT 05:39, 18. Apr. 2012 (UTC)

Kleiner Hinweis: Auch wenn ich mich nicht ständig dazu äußere, verfolge ich die Änderungen aufmerksam und kontrolliere sie. --JoKaene 07:22, 18. Apr. 2012 (UTC)

Danke. :-)

Mache dann mal mit B weiter.

Übrigens: Die Listen (wie z.B. Personen M) muss man sich im Nachgang nochmal anschauen (außer, die werden auf »normale« Oberbegriff-Logik mit dem führenden Leerzeichen umgestellt). Mache ich, das Anschauen/Korrigieren, möchte das ansonsten funktionierende Suchmuster nur deshalb aber nicht noch weiter umschreiben. --NAN 18:02, 18. Apr. 2012 (UTC)

Für alle Seiten mit Anfangsbuchstaben B Schritt 1 ausgeführt, Schritt 2 gestartet 639 Artikel betroffen.--NAN s BOT 18:23, 18. Apr. 2012 (UTC)

Eine Sache fiel mir gerade auf: Der Redirect Benjameen von Jacinta wurde korrekt abgearbeitet, der Hauptartikel Benjameen da Jacinta jedoch wurde nicht berücksichtigt. Dort wäre zwar nichts zu löschen, aber PPDefaultsort wurde nicht eingetragen. Oder habe ich gerade vergessen, dass es noch einen dritten Schritt für derartige Fälle gibt? (Ich will lieber kontrollieren als suchen.) --JoKaene 18:37, 18. Apr. 2012 (UTC)

Für alle Seiten mit Anfangsbuchstaben C Schritt 1 gestartet, 542 Artikel betroffen, warte mit Ausführung von Schritt 2, bis der erste durch ist.

@JoKaene: Schau' ich mir an.--NAN s BOT 18:45, 18. Apr. 2012 (UTC)

Ist ein Fall für Schritt 3 und 4: Die Nachbearbeitung von Personen-Artikeln. Würde ich gerne erst nach komplettem Durchführen der Schritte 1 und 2 machen. --NAN s BOT 18:49, 18. Apr. 2012 (UTC)

Habe die Projektseite etwas (hoffentlich ;-) ) klarer formuliert: Perrypedia:Automatisierte_Änderungen#Sortierung Über PPDefaultsort --NAN 04:47, 19. Apr. 2012 (UTC)

Für alle Seiten mit Anfangsbuchstaben C Schritt 1 beendet, Schritt 2 gestartet 542 Artikel betroffen.--NAN s BOT 04:52, 19. Apr. 2012 (UTC)

Für alle Seiten mit Anfangsbuchstaben D Schritt 1 gestartet, wieder 542 Artikel betroffen, warte mit Ausführung von Schritt 2, bis der erste durch ist. --NAN s BOT 05:09, 19. Apr. 2012 (UTC)

Für alle Seiten mit Anfangsbuchstaben D Schritt 1 beendet, Schritt 2 gestartet, 542 Artikel betroffen --NAN s BOT 05:21, 19. Apr. 2012 (UTC)

Für alle Seiten mit Anfangsbuchstaben E Schritt 1 gestartet, 496 Artikel betroffen, warte mit Ausführung von Schritt 2, bis der erste durch ist. --NAN s BOT 05:42, 19. Apr. 2012 (UTC)

Denke, inzwischen können wir uns seeehr sicher sein, dass Schritt 1 wirklich nur was hinzufügt, nichts zerstört.

Würde von daher den Schritt gerne ohne weitere Einschränkung auf bestimmte Buchstaben über alle Artikel laufen lassen.

Bin zwar geneigt, das gleich zu machen, aber falls bis 8:00 Uhr keine Bestätigung kommt, warte ich noch bis heute Abend, gebe mehr Zeit für Einspruch und dann können die Änderungen eventuell über Nacht laufen. --NAN 05:39, 19. Apr. 2012 (UTC)

Nach vielen genommenen Stichproben bestätige ich Deine Einschätzung, zumal bei den nicht geprüften Seiten als Änderung immer »plus 19 Bytes« angezeigt wird. --JoKaene 05:48, 19. Apr. 2012 (UTC)

O.k., dann lasse ich Schritt 1 über alle Artikel laufen.

Schritt 2, als einen Schritt, der löscht, würde ich aber dann anschließend trotzdem gerne wieder nur Buchstabenweise ausführen. Dauert dann zwar etwas länger, aber das sollte uns die zusätzliche Sicherheit denke ich Wert sein. --NAN s BOT 05:52, 19. Apr. 2012 (UTC)

Für alle verbleibenden Seiten Schritt 1 gestartet, 9.457 Artikel betroffen.--NAN s BOT 06:06, 19. Apr. 2012 (UTC)

Muss es Sorge bereiten, dass in der abzuarbeitenden Folge auch Begriffe mit einem anderen Anfangsbuchstaben auftauchen? Aktuell bei »G« wurden auch Ti-Jah'wk‎, Komplex Astrovent‎ und Sahin-Wüste‎ (korrekt) bearbeitet. --JoKaene 07:02, 19. Apr. 2012 (UTC)

Wenn die Änderung passt, wahrscheinlich nicht. Schau mir das aber mal an... --NAN 16:56, 19. Apr. 2012 (UTC)

Das ist noch vielfach passiert, aber ich glaube, es waren stets Begriffe mit einem Sonderzeichen oder Umlaut. Bin mir da aber nicht ganz sicher, weil der Job »hier« ein recht hohes Tempo hatte. --JoKaene 17:03, 19. Apr. 2012 (UTC)

Waren auch andere Wörter dabei. Denke aber mal, da müssen wir uns keine Sorgen machen. Es war ja keine Einschränkung auf bestimmte Anfangsbuchstaben vorgegeben. Die Sortierung der Extension ist halt dann einfach nicht einwandfrei. Das Wichtige ist ja die Bearbeitung. --NAN s BOT 17:52, 19. Apr. 2012 (UTC)

Ja, die fehlende Einschränkung wird der Grund sein. Auch mit Einschränkung auf einen Buchstaben waren Sortierfehler dabei, aber der Anfangsbuchstabe passte immer! --JoKaene 18:08, 19. Apr. 2012 (UTC)

Hast Du den Buchstaben G schon durch? der Redirect-Artikel Ganymed (Mond) hat sowohl explizite Sortkeys, als auch PPDefaultsort, ist das beabsichtigt? --Andi47 08:27, 19. Apr. 2012 (UTC)

Die Änderung muss in zwei Schritten erfolgen. Zunächst wird PPDefaultsort gesetzt und dann, in einem zweiten Durchgang, werden die bereits gesetzten Sortkeys gelöscht. Da der erste Durchgang noch läuft, hat das seine Richtigkeit. --JoKaene 08:39, 19. Apr. 2012 (UTC)

Achso. Sorry für die Nachfrage, ich wollte nur sichergehen, dass sich da keine Fehler eingeschlichen haben. --Andi47 09:35, 19. Apr. 2012 (UTC)

Schritt 1 offensichtlich fehlerfrei beendet. --JoKaene 11:13, 19. Apr. 2012 (UTC)

Danke für die Info und Unterstützung.

Setze dann die Arbeit mit Schritt 2 Buchstabe für Buchstabe fort.

Die Listen wie z.B. Personen M werden dadurch vorübergehend falsch sortiert, da die besondere "Ein-Buchstaben-Sortierung" nicht berücksichtigt wird. Passe das dann im Anschluss an. Vielleicht ist bis dahin ja auch die Diskussion durch, wie genau das zukünftig aussehen soll.--NAN 17:06, 19. Apr. 2012 (UTC)

Inzwischen sind wir mit Schritt 2 bei »N« angekommen.

Ab und an wird ein Sortkey nicht gelöscht, da das Wort »kategorie« klein geschrieben wird.

Wäre einfach genug in der regex anzupassen, aus Sicherheitsüberlegungen bleibe ich aber lieber mal beim bewährten Muster. Arbeite die wie es aussieht sehr seltenen Fälle nach. --NAN s BOT 04:26, 20. Apr. 2012 (UTC)

Kleine Zwischenfrage: Verstehe ich die Angaben auf der Projektseite richtig und mit Schritt 3 werden auch die an falscher Stelle gesetzten Sortkeys zu Personennamen gelöscht? (Ich beziehe mich da z.B. auf die nach Nachname/Vorname gesetzten Sortkeys in Kategorie:Atlan-Serie.) --JoKaene 06:30, 21. Apr. 2012 (UTC)

Ja. --NAN s BOT 06:31, 21. Apr. 2012 (UTC)

Würde Schritt 4 gerne zumindest für den ersten Lauf weiter einschränken und nur bei jenen Artikeln aus der Kategorie Personen ein PPDefaultsort setzen, bei denen in der Kategorie ein Sortkey mit Komma steht. Passe parallel dazu mein Auswertungs-Tool an. Kann dann ermitteln, ob damit plus den vorherigen Schritten alle relevante Personen-Artikel mit PPDefaultsort versehen wurden.

Falls ja, ist cool und die Anzahl der unnötig mit PPDefaultsort versehenen Artikel bleibt gering.

Falls nein, ist auch cool ;-), dann führe ich einfach Replace Text wie ursprünglich geplant nochmal so aus, dass an allen verbleibenden Artikeln der Kategorie ein PPDefaultsort gesetzt wird. --NAN 07:18, 21. Apr. 2012 (UTC)

Schritt 2 ist durch.

Korrektur bezüglich aufgrund Groß-/Kleinschreibung »übersehener« Kategorien wurde gemacht (prüfe aber nochmal, ob ich was übersehen haben).

Korrektur der Listen führe ich aus. Nehme den aktuellen Stand der Diskussion (Sortierung an den Anfang der Kategorielisten).

Alle Listen, die vor Schritt 2 eine "Ein-Buchstaben-Sortierung" hatten, korrigiert. --NAN 11:56, 21. Apr. 2012 (UTC)

Schritt 3 wurde gestartet. --NAN 10:26, 21. Apr. 2012 (UTC)

Die bisherigen Änderungen von Schritt 3 sehen zwar gut aus, aber ich behalte sie zunächst »verschärft« im Auge. --JoKaene 10:29, 21. Apr. 2012 (UTC)

Cool. :-)

Sind bei Schritt 3 inzwischen bei »N« --NAN 11:56, 21. Apr. 2012 (UTC)

Schritt 3 ist durch.

Beginne damit, das Muster von Schritt 4 so zu ändern, dass nur Personen-Artikel betroffen sind, die bei der Kategorie Personen einen Sortkey gesetzt haben, der ein Komma enthält.

Teste das Muster (das sehr ähnlich sein wird wie bereits verwendete), indem ich zunächst nur wenige Artikel ändere und jeden einzeln prüfe. --NAN 14:23, 21. Apr. 2012 (UTC)

Alle Artikel der Kategorie Personen betrachtet, die mit Aa und Ab beginnen.

15 Artikel erhielten durch die Einschränkung kein PPDefaultsort, da kein expliziter Sortkey mit Komma gesetzt war.

Bei 6 musste ich manuell das PPDefaultsort und teilweise einen Eintrag bei der Kategorie Personen nachtragen. Waren einfach vor den ganzen aktuellen Änderungen bereits ohne Sortkey und konnten von daher nicht automatisiert erkannt werden.

Die Menge der untersuchten Artikel ist natürlich zu gering, um eine wirklich Aussage trefen zu können.

Aber denke mal: Da wir bereits der Meinung waren, dass ab und an ein PPDefaultsort zu oft zu setzen nicht schadet, ist es wohl besser, doch beim ursprünglichen Plan zu bleiben und einfach bei allen Personen-Artikeln das PPDefaultsort zu setzen.

Nacharbeiten werden dann nur insofern notwendig, als dass bei der Kategorie Personen teilweise keine Sortkeys standen, bzw. Sortkeys ohne Komma standen, obwohl dort welche mit Komma hätten stehen müssen.

Also starte dann mal - langsam - damit, bei allen Artikeln der Kategorie Personen wie ursprünglich abgesprochen PPDefaultsort zu setzen. --NAN 14:57, 21. Apr. 2012 (UTC)

Stimme zu! Die Kategorie:Personen bedarf wohl eh einer Nachbetrachtung. --JoKaene 15:00, 21. Apr. 2012 (UTC)

Sieht bisher ja mal gut aus. Wie schon bei Schritt 1 würde ich das ganze gerne demnächst über alle Personen-Artikel ohne Einschränkung auf Buchstaben laufen lassen. Dann wäre die Sache morgen früh wohl fertig, das Ergebnis bereits im XML-Dump, der immer morgens erzeugt wird und ich könnte bereits morgen Listen bezüglich Nacharbeiten liefern. --NAN 16:10, 21. Apr. 2012 (UTC)

Ich denke auch, dass dem nichts entgegensteht. Das läuft alles so gut... --JoKaene 16:15, 21. Apr. 2012 (UTC)

Wenn die Änderungen für E durch sind, starte ich den Job für die gesamten restlichen Artikel der Kategorie Personen. --NAN 18:13, 21. Apr. 2012 (UTC)

Die Änderung ist wohl korrekt abgearbeitet worden, allerdings hängen noch 20 Jobs in der Warteschlange!? --JoKaene 08:24, 22. Apr. 2012 (CEST)

Habe zwischenzeitlich immer wieder mal beobachtet, dass eine Textersetzung durch war, aber noch Jobs rumstanden.

Da nicht nur Replace Text Jobs startet, wahrscheinlich kein Problem.

Aber vielleicht kann Poldi ja mal in die entsprechende Tabelle schauen, was das für Jobs sind? --NAN s BOT 08:34, 22. Apr. 2012 (CEST)

Schritt 4 ist durch. Mache noch ein paar Nacharbeiten und schau dann als nächstes, dass ich über eine Auswertung des XML-Dumps rausfinde, was alles noch genau zu tun ist. Melde mich wieder, sobald ich da ein Ergebnis habe. --NAN s BOT 08:34, 22. Apr. 2012 (CEST)

Im Zuge der Nacharbeiten habe ich gerade vier neue Änderungen gestartet und nun, nachdem die durch sind, ist der Zähler bei den Jobs auf 0.

Schätze mal, so gaaanz genau funktioniert der nicht, bzw. da ist eventuell ab und an noch was im Hintergrund, was Auswirkung auf den Zähler hat, von uns aber nicht gesehen werden kann. --NAN s BOT 08:48, 22. Apr. 2012 (CEST)

Folgende Beobachtung: Die Redirects »Faktor I«, »Faktor II« etc. hatten keinen Sortkey (»Faktor 01«). Mit Schritt 1 hätte deshalb doch eigentlich PPDefaultsort vergeben werden müssen. Dies ist jedoch nicht passiert. --JoKaene 11:00, 22. Apr. 2012 (CEST)

Schritt 1 hat PPDefaultsort bei Artikeln gesetzt, bei denen bereits ein explizit gesetzter Sortkey vorhanden war.

Wie weiter oben diskutiert sollte so der Umstand genutzt werden, dass bei allen Seiten, mit Ausnahme Personen-Artikel und Artikeln mit Zahlen, die SortKeys bereits richtig gesetzt waren.

Insofern hat sich Schritt 1 genauso verhalten wie definiert: Keine explizit gesetzten SortKeys vorhanden, kann nicht erkennen, ob da ein PPDefaultsort notwendig/richtig ist, kein PPDefaultsort gesetzt.

Die Artikel mit Zahlen müssen wir halt leider alle prüfen. Die automatisierten Änderungen waren aber ja auch nicht dazu da, uns diesbezüglich sämtliche Arbeit abzunehmen, sondern »nur« dazu da, uns gut 15.000 Änderungen abzunehmen. --NAN 11:09, 22. Apr. 2012 (CEST)

Ah, sorry. Da hatte ich Schritt 1 falsch in Erinnerung. --JoKaene 11:12, 22. Apr. 2012 (CEST)

Gesperrtes Leerzeichen vor Einheiten

Wenn ich es richtig sehe, dann soll der Zeilenumbruch nicht nur vor cm, sondern vor allen Einheiten verhindert werden?
Falls dem fachlich so ist, könnte man dann technisch gesehen folgendes Suchmuster einsetzen?

• ([0-9]*) (cm|m|kg)\b
  

Und folgendes Muster für die Ersetzung:

• $1&nbsp;$2

Neben cm, m und kg natürlich um beliebige weitere Einheiten ergänzt. Das \b sollte unerwünschte Nebeneffekte verhindern? --NAN 18:17, 5. Apr. 2012 (UTC)

Also mir fehlt da in der ersten Klammer noch ein "," und ein "." . --Thinman 19:40, 6. Apr. 2012 (UTC)

Warum? Es reicht doch aus, wenn eine beliebige Ziffer, ein Leerzeichen und dann die Maßeinheit kommt. Bespielsweise 1,5 cm oder 5 cm. Beide werden erkannt und ersetzt. Was aber noch ergänzt werden sollte, ist, dass sich bei den regex um mysql handelt und nicht um PHP. Ist zumindest meine Erfahrung. --Poldi 19:50, 6. Apr. 2012 (UTC)

@Thinman: War auch am überlegen, ob der Ausdruck nicht noch genauer gefasst werden sollte/müsste, um ganz sicher zu gehen, dass nicht versehentlich was falsches mit verändert wird. Dann wiederum dachte ich mir »je kürzer/einfacher der Ausdruck, desto weniger Serverlast und selbst falls an ein, zwei Stellen ein &nbsp; ein Leerzeichen ersetzen sollte, das nicht ersetzt werden müsste, schadet nicht, ist schnell nachträglich korrigiert«. Gleich Poldi kann ich aber keine Situation sehen, in der ein &nbsp; unbegründet gesetzt würde, weil die Zahl nicht vollständig definiert ist?

@Poldi: Wie sieht den der Ausdruck in MySql-Form aus? So?

• ([0-9]*) (cm|m|kg)\\b

Wobei mir gerade noch ein Fehler aufgefallen ist

• ([0-9]+) (cm|m|kg)\\b

Sonst würde auch z.B. »Einheit cm« einen Match (» cm«) liefern. --NAN 04:55, 7. Apr. 2012 (UTC)

Habe das Suchmuster (um g ergänzt) mal auf den XML-Dump angewendet ([15], Artikelname plus matches). Sind einige false positive dabei, wird besser, wenn Groß-/Kleinschreibung beachtet wird:

• (?-i)([0-9]+) (cm|m|kg|g)\b ([16] [17])

Betroffen sind dann 318 Seiten. --NAN 16:58, 7. Apr. 2012 (UTC)

Habe mal etwas in der Doku im Netz gestöbert:

MySql nutzt demnach POSIX Extended Regular Expression, was im Vergleich zu anderen regex-Formen eher eingeschränkt ist.

Das (?-i) z.B. funktioniert in der Extension daher nicht (zur Erklärung: Meine Abfrage oben habe ich mit .Net ausgeführt, dort existiert die Möglichkeit). Ob Groß-/Kleinschreibung beachtet wird, oder nicht hängt davon ab, wie die Tabellen konfiguriert sind.

Ein Test zeigt, dass bei uns Groß-/Kleinschreibung aktuell beachtet wird. (?-i) kann also wegfallen, ohne dass sich was am Ergebnis ändert.

Das »\b« wird ebenfalls nicht unterstützt, sollten wir uns noch genauer anschauen.

Aktuell würde die regex für das Suchmuster also so aussehen:

• ([0-9]+) (cm|m|kg|g)

--NAN s BOT 09:40, 9. Apr. 2012 (UTC)

Eine Woche lang keine weitere Antwort, keine Einwände, gehe die Sache dann mal an. --NAN 17:04, 13. Apr. 2012 (UTC)

Gerade noch gesehen, der Wegfall des »\b« (da nicht von POSIX Extended Regular Expression unterstützt) führt auch zu Ergebnissen wie z.B. »7 mal«.

Keine Ahnung, ob das fachlich gewünscht ist, war auf jeden Fall mal nicht Gegenstand der Diskussion hier, umgehe diese Fälle daher, indem ich die regex wie folgt erweitere:

([0-9]+) (cm|m|kg|g)[^a-z^A-Z^0-9^ä^Ä^ö^Ö^ü^Ü]--NAN 17:21, 13. Apr. 2012 (UTC)

Und sehe meine Meinung, dass man so Erweiterungen/Änderungen einer regex nicht einfach so mal schnell machen sollte bestätigt:

Bei unverändertem Muster für die Ersetzung führt das natürlich dazu, dass das Zeichen nach z.B. m (meist ein Leerzeichen) gelöscht wird.

Hatte die Änderung allerdings auf Artikel, die mit A beginnen eingeschränkt, 18 Stück, behebe die Sache gleich wieder. --NAN 17:24, 13. Apr. 2012 (UTC)

Auf ein Neues:

• Suchmuster: ([0-9]+) (cm|m|kg|g)([^a-z^A-Z^0-9^ä^Ä^ö^Ö^ü^Ü])
• Muster zum Ersetzen: $1&nbsp;$2$3

Mit Artikeln, die mit B beginnen getestet, funktioniert. Ist aber auch irgenwie unschön. Vielleicht findet ja jemand noch eine elegantere Lösung? --NAN 18:17, 13. Apr. 2012 (UTC)

Sollte nicht ([0-9]+) (cm|m|kg|g)( +) reichen. Ein oder mehrere Leerzeichen – wobei das auch schon wieder ein Fehler wäre – grenzt die Maßeinheit von dem nachfolgendem Text ab. --Poldi 18:50, 13. Apr. 2012 (UTC)

Würde Fälle nicht erfassen, bei denen nach der Einheit ein Zeilenumbruch kommt. Manchmal folgt nach der Einheit auch ein . oder , oder ein ) (und vielleicht noch ein paar weitere Zeichen, müsste man sich nochmal anschauen). Durch die Verneinung auf Buchstaben und Zahlen wird das \b denke ich relativ gut nachgebildet. Aber zugegeben, habe ich jetzt recht kurzfristig und nach einer langen Arbeitswoche aus dem Ärmel geschüttelt. Eventuell ist eine mit | getrennte Liste jener Zeichen, die wir erwarten können, eleganter. Wobei ich mir ja denke, irgendwie muss dass eigentlich auch mit diesem POSIX regex noch schöner gehen. ;-)

Änderung ist übrigens durch.

Habe mal jede einzelne Änderung kontrolliert (Versionsvergleich): Schaut gut aus.

Die Extension hat in der Vorschlagsliste ein paar Artikel angezeigt, in denen das Suchmuster anscheinend nicht enthalten war. Diese habe ich mal außen vor gelassen. (Anscheinend würde da dann auch nichts gemacht. Klar, gibt ja nichts zu machen. Schaue ich mir aber morgen nochmal an.)

Übernehme dann mal das Suchmuster und das Muster zum Ersetzen in die Projektseite. Haben sich ja beide bewährt. --NAN 19:08, 13. Apr. 2012 (UTC)

Dachte mir gestern schon "etwas viele ^-Zeichen in der regex". Da das Muster überprüfterweise funktionierte, hatte ich nicht weiter nachgeforscht. War aber eine von den nicht wirklich elegant aussehenden Sachen im Muster, was ja immer ein guter Hinweis auf einen möglichen Fehler, eine mögliche Unschärfe ist, auch wenn die Sache beim aktuellen Stand der Dinge funktioniert. Habe das deswegen jetzt noch geprüft.

Zum Verneinen einer character class genügt ein ^-Zeichen am Anfang. Nur um sicher zu gehen, dass das auch bei der von der Extension genutzten Regex-Form so ist, habe ich das zunächst auf einer der Testseiten meines Bots getestet und danach auch noch beim Artikel Landschaften. Dadurch, dass nur ein ^-Zeichen am Anfang gesetzt wird, ändert sich auch die Vorschlagsliste der Extension nicht. Damit hat sich die Theorie in der Praxis bestätigt:

• Suchmuster: ([0-9]+) (cm|m|kg|g)([^a-zA-Z0-9äÄöÖüÜ])
• Muster zum Ersetzen: $1&nbsp;$2$3

Die Projektseite wurde von mir angepasst. --NAN 05:27, 14. Apr. 2012 (UTC)

Wer soll die Extension nutzen können

Bisher kann die Extension nur von einem Bürokraten verwendet werden. Die Praxis hat aber gezeigt, dass dann die erfolgten Änderungen die »Letzte Änderungen« flutet und diese nicht über »Bots ausblenden« ausgeblendet werden können. Es ist daher sinnvoll, wenn die Änderungen von einem User gemacht werden, der Bot-Status hat. Wenn jemand sich berufen fühlt die Extension zu verwenden, kann er sich einen Bot-User anlegen lassen und mit diesen dann die Änderungen durchführen. Die Vorschläge was geändert werden soll, können gerne auf dieser Projektseite hinterlegt werden. Der User der sie umsetzten möchte kann die Aufgabe mit seiner Unterschrift markieren und umsetzten. Diese Vorgehensweise deckt sich weitestgehend der Regelung für Bots. --Poldi 17:28, 5. Apr. 2012 (UTC)

Denke wichtig ist das technische Wissen, um sich der möglichen Konsequenzen wirklich bewusst zu sein und im Fall der Fälle konsequent richtig zu handeln (Poldi, Du hast bei Deinen Tests ja z.B. festgestellt, dass die Extension ein echter Ressourcenfresser ist und verschiedene Standardeinstellungen der Mediawiki deutlich erhöht. Die Fähigkeit das zu erkennen und entsprechend zu handeln hat eigentlich nur ein Bürokrat? Leute, die tatsächlich schon bots geschrieben haben, sind sich zumindest der möglichen Konsequenzen wirklich bewusst?).

Würde von daher mal sagen, jeder, der einen bot schreiben kann oder Bürokrat ist. Alle anderen sollten meiner Meinung nach nicht die Möglichkeit erhalten, die Extension zu nutzen.

Jeder sollte aber in der Lage sein, einfach Wünsche für eine Abfrage einbringen zu können.

Jeder sollte sich gerade bei komplizierteren Abfragen auch bezüglich der Ausarbeitung der regex einbringen können.

Niemand sollte nachdem der anfängliche Testzeitraum vorbei ist ohne vorherige Diskussion hier (vor der ersten Ausführung) irgendeine Abfrage ausführen. Als Mindestlaufzeit für die Diskussion würde ich volle sieben Tage ansetzen. Falls in der Zeit keine Einwände kommen, ist die Sache cool. --NAN 18:03, 5. Apr. 2012 (UTC)

Wie, NAN, schätzt Du dich in dieser Beziehung eigentlich selbst ein? --JoKaene 18:10, 5. Apr. 2012 (UTC)

Ist ja ziemlich einfach: Da ich weder einen Bot geschrieben habe, noch Bürokrat bin, sollte ich auch keine Rechte zur Ausführung erhalten.

Hätte ich rein vom Wissen und praktischer Erfahrung her das Zeug dazu, einen bot zu schreiben, die Aufgaben eines Bürokraten wahrzunehmen, bin ich mir der möglichen Konsequenzen wirklich ;-) bewusst und würde es mir in den Fingern jucken, da mal ordentlich ohne irgendwelche Sieben-Tage-Wartezeiten loszulegen? Spielt einfach keine Rolle. Man sollte Systeme, die zur Sicherheit eingeführt werden, nicht durch Ausnahmen aushebeln.

Aber nun, noch ist das System nicht etabliert, Poldi scheint das Ganze ja etwas lockerer zu sehen und von daher sind das erstmal nur "Was wäre wenn"-Aussagen. --NAN 18:26, 5. Apr. 2012 (UTC)

Hm! Das hieße natürlich, dass dann nur Poldi infrage käme (Alex lasse ich mal außen vor)! ...wenn er Bots schreiben kann. ;-) --JoKaene 18:36, 5. Apr. 2012 (UTC)

Ist ja ein oder. Also Wolfram könnte auch noch und Syntron und Bully1966.

Dass praktisch aktuell wohl nur Poldi die Möglichkeit tatsächlich auch nutzen würde, sehe ich nicht als Problem: Das Wissen wird hier gesammelt und wir werden immer irgendeinen Bürokraten haben (schlicht, weil wir sonst auf Dauer nicht lauffähig sind), der dann auch die Extension ohne groß sich alles selbst neu überlegen zu müssen nutzen kann.

Also, solange Poldi nicht sagt, dass er da nicht mal ab und an Zeit für hat, passt das.

Die Extension, von der wir ja schon wissen, dass sie viele Ressourcen verbraucht, sollte ja auch nicht unbedingt täglich laufen.

Und klar, falls Poldi doch überhaupt keine Zeit für sowas hat, dann müsste man den Kreis um ein, zwei Leute erweitern... --NAN 18:56, 5. Apr. 2012 (UTC)

Ich habe die Berechtigung auch für Bots eingerichtet und mit meinem Bot-User I-Robot einen Test gemacht. --Poldi 21:04, 5. Apr. 2012 (UTC)

Nur, damit ich mal den Arbeitsaufwand abschätzen kann:

Kann die Extension selbstständig eine vorgefertigte Liste abarbeiten und

muss jede von der Extension durchgeführte Änderung manuel durch anklicken des Speichern-Buttons bestätigt werden? --JoKaene 09:10, 9. Apr. 2012 (UTC)

Nein, vorgefertigte Listen können nicht abgearbeitet werden. Die Liste wird durch die Angabe eines Suchbegriffes über die Artikel von der Extension selbst erstellt. Die Änderungen erfolgen automatisch. Was aber auch ein Nachteil sein kann, da der Vorgang nicht mehr unterbrochen werden kann. Ist mir leider schon passiert :-( --Poldi 09:18, 9. Apr. 2012 (UTC)

Ob die Liste vorgefertigt ist oder mit den gleichen Suchbegriffen durch die Extension selbst erstellt wird, macht ja keinen Unterschied, außer, dass noch weniger Arbeit aufzuwenden wäre. Mit entsprechender Vorsicht lassen sich also auch sehr umfangreiche Änderungen innerhalb kurzer Zeit automatisch abarbeiten. (Ich habe da immer noch die Artikel zu Personen im Kopf, auch wenn ich das erst mal hinten anstelle und gut durchdenken muss.) --JoKaene 09:29, 9. Apr. 2012 (UTC)

Man kann alle Seiten des Wikis, oder nur alle Seiten eines Namensraums, oder nur alle Seiten, die mit einer bestimmten Zeichenfolge beginnen oder aber halt auch nur alle Seiten einer Kategorie (wie z.B. Personen) ändern, indem man entsprechend Häkchen setzt bzw. Texteingabefelder ausfüllt.

Wie von Poldi schon angedeutet: Eine Änderung einer so großen Anzahl von Seiten muss aber gut durchdacht sein, da sonst leicht möglich ist, dass in mehreren tausend Seiten in kürzester Zeit Fehler eingebaut werden.

Tests des gefundenen Suchmusters anhand weniger Seiten im Vorfeld und zumindest stichprobenmäßiges Kontrollieren nach dem Ändern einer größeren Gruppe von Seiten ist von daher leider nicht zu umgehen. Wäre aber bei einem bot nicht anders und gerade bei großen Mengen von Seiten dürfte das trotzdem schneller/leichter sein, als manuelle Änderungen. --NAN s BOT 09:58, 9. Apr. 2012 (UTC)

PS: Nach weiterer Diskussionen an anderer Stelle bin ich inzwischen doch Bot. --NAN s BOT 10:01, 9. Apr. 2012 (UTC)

Extension:Replace Text

Die Extension wurde in dieser Diskussion als mögliche Alternative zu einem bot diskutiert.
Hier wurde die prinzipielle Einsetzbarkeit bestätig. --NAN 15:56, 5. Apr. 2012 (UTC)

Neu

Habe die Seite gerade neu angelegt, bitte gönnt mir ein, zwei Tage, um sie auszuarbeiten. --NAN 15:30, 5. Apr. 2012 (UTC)

Die erste Version ist fertig.

Den Überblick habe ich geschrieben, da jeder schnell und ohne groß nachzufragen erkennen können soll, worum es geht.

Die Aufteilung zwischen Extension und Bots habe ich gemacht, da manche Sachen von der Extension wahrscheinlich nicht machbar sein werden (muss man schauen, was das ist). Es ist von daher durchaus weiterhin sinnvoll zusätzlich für kompliziertere Sachen mit Bots zu arbeiten und falls z.B. ich mal die Zeit abzweigen kann, so ein Programm zu schreiben, dann haben wir auch wieder einen.

Obwohl ein Bot natürlich seine eigene Benutzer-Seite hat, sollte meiner Meinung nach zwecks Überblick die jeweilige von ihm übernommene Änderung allgemeinverständlich Beschrieben auch hier vermerkt werden. Insbesondere hat man dann immer einen schönen, zentralen Überblick, was prinzipiell schon gemacht werden kann. Falls neue Botschreiber hinzukommen, sehen sie sofort, was schon geht, können sich eventuell auf andere Sachen konzentrieren. Sehen, wen sie wegen der Lösung ähnlicher Probleme um Rat fragen könnten.

Für »Replace Text« war mir wieder wichtig, dass zuerst eine Beschreibung erfolgt, die auch von Nicht-EDV-Experten verstanden werden kann. Zwecks Transparenz sollte meiner Meinung nach dann immer das Datum der letzten Ausführung einer Änderung und der Nutzer eingetragen werden. So sieht man einerseits, ob es mal wieder Zeit ist, die Änderung zu wiederholen. Andererseits kann man auch konkret Nachfragen, falls es Grund zur Nachfrage geben sollte. Mehr als die letzte Änderung würde ich auf der Seite nicht vermerken, da ja alle früheren auch über die Versionsgeschichte der Seite nachgeschlagen werden können.

Die technischen Details habe ich eingeklappt: Nehmen doch etwas Platz weg und irritieren vielleicht die Nicht-EDV-Experten. Bezüglich Inhalt habe ich mich an den unter http://www.mediawiki.org/wiki/Extension:Replace_Text beschriebenen Möglichkeiten orientiert. Als Beispiel habe ich eine der Sachen genommen, mit denen Poldi bereits getestet hatte und was von daher funktionieren dürfte. Habe den Punkt aber natürlich weiter oben auch noch zur Diskussion gestellt. --NAN 05:17, 6. Apr. 2012 (UTC)