Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise
Der Kaskadenschutz liegt auf WP:Hauptseite/Heute, wo die Gestorben-Vorlage nicht eingebunden ist, daher kann sie bearbeitet werden. Hat aber den Nachteil, das sich die zeitabhängigen Vorlagen nicht so schnell aktualisieren.
Du könntest ein Link auf Spezial:Geschützte Seiten mit ausgefülltem "Nur Seiten mit Kaskadenschutz" anbieten.
Der Schutz vor Neuanlage für einen bestimmten Namen ist MediaWiki-Standard und taucht ja auch in den Logbüchern und auf der genannten Spezialseite auf. Titleblacklist bietet zusätzlich die Möglichkeit generisch Seitennamen (und mehr) zu verbieten. Die Treffer hier werden aber nicht geloggt, somit beeinflussen sie nicht die Liste, sondern erweitern sie höchstens. Wird aber lokal nur für wenige Seitennamen genutzt.
Der Logbuch-Abschnitt enthält Text wie er früher mal in der Versionsgeschichte auftauchte. Im Logbuch selber sind die Texte (leider) noch nicht übersetzt. Der Umherirrende21:00, 7. Jul. 2014 (CEST)
Ah ja.
Na, dann war das höchste Zeit, dass das alles mal überarbeitet wurde.
Du hast mir sehr geholfen; kannst ja morgen noch mal draufgucken, ob ich das alles richtig gemacht habe.
Sieht gut aus. Habe noch ein Satz bei den Kaskadensperren ergänzt.
Der Hinweis, dass es zu einer Zeit immer nur eine Sperre geben kann, ist vermutlich nur für Admins sinnvoll. Es wäre ja schön, wenn man eine unbegrenzt halbgesperrte Seite auch mal eine Woche vollsperren könnte und sie nach der einen Woche wieder auf halbsperre zurückfällt. Im Moment ist sie dann ungeschützt (Bug 39038).
Man könnte auch noch ein Hinweis aufnehmen, das in der Versionsgeschichte eine Nullbearbeitung mit dem entsprechenden Kommentar erzeugt wird, aber das scheint beim Verschieben auch noch nicht erwähnt zu werden … Der Umherirrende20:48, 8. Jul. 2014 (CEST)
Ich denk, das ginge über eine Anleitung für Benutzer hinaus. Wäre dann das High-Tech-Manual für Programmierer oder schon ein Admin-Handbuch. Wo es ja eine detailierte Anleitung gibt; die ärgerliche Geschichte, dass sich die befristete Sperre nach Zeitablauf nicht mehr an den vorigen Zustand erinnert, betrifft keinen Normalbenutzer sondern nur Admins.
Siehe WP:NEU#10. Juli. Ja, die Server brauchen etwas um die 1,2 Mio. backlinks zu verarbeiten. Bin noch nicht über alle Seiten gekommen, vorallem stellt sich mir die Frage, in welchem Abschnitt man das einbaut. Der Umherirrende20:08, 11. Jul. 2014 (CEST)
Diese Variable ist neuartig. Ergo braucht es m.E. eigentlich einen eigenen Abschnitt, spätestens wenn da noch mehr kommt. Ich habe es jetzt mal unter "Generelle, konstante Variablen" eingebaut. ÅñŧóñŜûŝî(Ð)20:46, 11. Jul. 2014 (CEST)
Da passt es im Moment am besten. Ich glaube aber nicht, das noch mehr kommen, da man alle anderen Hilfsvorlagen für Tabellen eigentlich nicht braucht, sondern das nur Kurzschreibungen sind. Der Umherirrende20:51, 11. Jul. 2014 (CEST)
Wenn in den Hilfsvorlagen jetzt die Variable anstatt des plain | eingebunden wird, entsteht nur eine weitere Verschachtelungstiefe, die die Server und einige Limits mehr belasten dürfte als es Plaintext überhaupt kann.
Eine Ersetzung der anderen Hilfsvorlagen kann man gerne machen, wenn man eh eine Vorlage bearbeitet, da eine Bearbeitung alleine und der damit verbundene Reparse aller Seiten die die Vorlage verwenden die Server weitaus mehr belasten wird, als es eine Vorlageneinbindung einsparen kann. Der Umherirrende21:08, 11. Jul. 2014 (CEST)
@Antonsusi: Ich hatte das schon Ernst gemeint mit den sinnlosen Bearbeitungen, also lasse es bitte. Es läuft nichts weg. Ob sie da sind oder nicht ist doch völlig egal. Der Umherirrende22:20, 11. Jul. 2014 (CEST)
Ok, ok. Ich war neugierig, ob das auch überall problemlos funktioniert... Noch was:
Wie ist eigentlich die Priorität gesetzt? Geht der Parser bei sowas wie {{{{{!}}}}}oder {{{!}} immer hin, und ersetzt zuerst den String {{!}} durch "|", bevor er nach Vorlageneinbindungen oder Tabellensyntax sucht?
Der Parser macht nicht einfache Textersetzungen. Bei einem Pärchen von zwei geschweiften Klammern geht er in die Verarbeitung (braceSubstitution). Ein Teil davon ist die Erkennung von Variablen und Parserfunktionen, der zweite ist die Vorlage im Wiki zu suchen. Da auch andere Vorlageneinbindungen mit drei Klammern anfangen können und diese richtig erkannt werden, passiert es auch hier. Die Tabellensytnax wird erst verarbeitet, wenn alle Vorlagen expandiert sind, sonst würde der Hack (der jetzt keiner mehr ist, da es die Software selber unterstützt) nicht funktionieren.
Die Server hier sind durch, ich würde aber gerne noch ein paar Tage warten, bis auch sicher ist, das es bei der Variable bleibt und dann kann man die Vorlage mit einem Informativen Kommentar löschen, so dass in Zukunft die Verweise darauf auch verstanden werden. Man sollte die anderen Hilfsvorlagen erwähnen, aber vielleicht nicht ihre Nutzung propagrieren. Es soll ja auch vorkommen, das Neulinge sich mit Vorlagen beschäftigen und dann über diese Vorlagen stolpern. Der Umherirrende11:33, 12. Jul. 2014 (CEST)
Ist jetzt weg. Man könnte nur noch in der Dokumentation erwähnen, das es früher mal eine Vorlage war, falls jemand ein Wikilink auf die Vorlage findet und sich dann wundert. Der Umherirrende09:46, 16. Jul. 2014 (CEST)
⇐⇐Ich habe bedenken, ob es gut ist, wenn die Vorlage ersatzlos weg ist. Bringt das gegenüber einem Hinweis wie z. B.
<noinclude>Diese Vorlage wurde gelöscht. Näheres dazu unter [[Special:Redirect/page/243848|Hilfe:Variablen]].</noinclude>
Da die Linkliste jetzt für 24 Stunden leer war, gibt es keine Einbindungen mehr, neue Einbindungen sollte der Verwender schneller erkennnen, dass irgendetwas nicht passt. Aus meiner Sicht reicht der Hinweis im Löschlogbuch. Der Umherirrende12:30, 16. Jul. 2014 (CEST)
Hallo, ich wünsche mir eine Vorlage. Und zwar wünsche ich mir eine Vorlage nach diesem Vorbild: https://en.wikipedia.org/wiki/Template:Collapse . Ich würde das auch selbst machen. Aber ich habe bisher keine Erfahrung mit Vorlagen. Und eigentlich interessieren mich Vorlagen auch nur aus der Benutzersicht - und nicht aus der Entwicklersicht... Wie muss ich es anstellen, so dass ich so eine Vorlage bekomme? Was muss ich tun? :-) --Kassbohm (Diskussion) 22:09, 18. Jul. 2014 (CEST)
Hallo nochmal. Ich konnte das Problem inzwischen Lösen durch die Verwendung von wikitable mw-collapsible mw-collapsed - und brauche daher keine Vorlage mehr. Entschuldigung für die Störung. --Kassbohm (Diskussion) 06:59, 20. Jul. 2014 (CEST)
Kuriosität: Gespenstischer Benutzer
Hi,
Sensation (Dance-Event) wurde am 13. Januar 2005 von einem Geist erstellt. Offenbar sind wir seitdem robuster geworden; obwohl 2005 schon fortgeschritten war.
Ja, sieht auch per API kaputt aus, aber bei einer so alten Software, wo die Daten das ein oder andere mal migriert wurden, wird sich so etwas wohl immer finden, aber da wird wohl kein Sysadmin das reparieren können/wollen. Ein paar Leichen hat jeder im Keller, vorallem aus 2004 und 2005 gibt es da sicher viele ;-) Der Umherirrende21:59, 9. Aug. 2014 (CEST)
Kann man diese Versionseinträge irgendwie komplett (also von allen heute existierenden Artikeln) herausfiltern und auflisten? ÅñŧóñŜûŝî(Ð)08:49, 10. Aug. 2014 (CEST)
Das sind mit ziemlicher Sicherheit alle neu angelegten Seiten. Ob die Macke auch Bearbeitungen existierender Seiten betraf, müsste man durch Analyse des Tages (etwa LD) herausfinden; an dem Tag zu der Stunde war die Software oder das Server-Netzwerk offenbar nicht ganz stabiil gewesen. VG --PerfektesChaos10:42, 10. Aug. 2014 (CEST)
Eine solche Auflistung sehe ich ohne Mehrwert. Es gibt ein metadata-Dump mit allen Versionen aber ohne die Texte, diesen könnte man bei Bedarf auswerten. Alternativ ein Query auf ToolLabs, aber keine Ahnung, wie lange der läuft. Der Umherirrende18:00, 10. Aug. 2014 (CEST)
markAdmins
Moin! Benutzer:Filzstift ist als Administrator zurückgetreten, hat die Knöpfe als CU aber behalten, siehe hier. Nun muss Benutzer:PDD/markAdmins.js so angepasst werden, dass er nicht mehr A/CU, sondern CU-A ist, also analog von A/SG und SG-A. Ich kann das nicht, du vielleicht? Viele Grüße, NNW20:23, 12. Aug. 2014 (CEST)
ich hätte zwei Fragen bezüglich Statistiken, auf die du vielleicht eine Antwort hast, da du ja bereits früher ähnliche Statistiken erstellt hast (stimmberechtigte Konten):
Wäre es möglich, eine Liste aller Administratoren mit der Anzahl ihrer Adminaktionen zu erstellen, einmal insgesamt und dann für die letzten 30 Tage. Mich würde mal interessieren, welchen Anteil beispielsweise die ersten 50 Admins haben oder wie groß der Anteil von Aka oder Itti alleine ist.
Wäre es möglich, festzustellen wie viele der insgesamt registrierten Konten (die 1.932.032+) überhaupt mal aktiv waren, also: Nie aktiv, < 10 Bearbeitungen, < 100 Bearbeitungen, > 1000 Bearbeitungen. Sowas halt. Zumindest die nie aktiven wären eine interessante Zahl, die anderen natürlich auch.
Wie gesagt, vielleicht kannst du was dazu sagen, ob eine solche Statistik leicht zu erstellen wäre, oder ob das (ähnlich wie bei den stimmberechtigten Konten) zu arbeitsintensiv ist. Sofern letzteres, würde mir diese Antwort völlig genügen, aber wie gesagt, interessant wäre es allemal. Gruß, BHC (Disk.) 12:09, 18. Aug. 2014 (CEST)
Allerdings solltest du dich nicht ganz auf diese Zahlen verlassen. Es gibt Admins in Spezialbereichen, die in dieser Liste kaum aufscheinen, und dennoch als recht aktiv gelten. (z.B. durch wichtige Wartungsarbeiten auf gesperrten Seiten.) Frohes Schaffen — Boshomi☕⌨☺14:13, 18. Aug. 2014 (CEST)
Auch danke dir Filzstift und Boshomi, keine Sorge, ich habe nicht vor reihenweise Wiederwahlstimmen zu verteilen, die bekommen nur die ganz Inaktiven ohne Stimmberechtigung. Aber das ganze ist schon interessant, so sind die ersten 100 Admins für 98,4 % aller (aufgeführten) Adminaktionen verantwortlich. 85 Admins (ohne SG-A) haben dagegen gar keine Aktion... --BHC (Disk.) 16:18, 18. Aug. 2014 (CEST)
Auch hierzu taugt die Statistik wenig. Es ist relativ einfach 1000 Diskussionsseiten dynamischer IP-s zu löschen, aber ein Riesenaufwand einen Filter zu schreiben, der einen einzigen Troll aus dem Schurken-Universum vom Belästigen anderer User abhält. Spezialwissen kann da mehr wert sein als Stimmberechtigungen. Frohes Schaffen — Boshomi☕⌨☺17:05, 18. Aug. 2014 (CEST)
Ich bezweifle ganz stark, dass diejenigen, von denen ich hier rede, Filter programmieren, oder siehst du einen Grund warum der oder der Adminrechte benötigt? --BHC (Disk.) 18:31, 18. Aug. 2014 (CEST)
Es gab auch mal eine Initiative auf einer Benutzerseite worauf hin viele Admins ohne Stimmberechtigung viele Wiederwahlstimmen gesammelt hatten, aber keine Ahnung, wo das war. Der Umherirrende20:15, 19. Aug. 2014 (CEST)
Ich werde mal eine Auswertung der Bearbeitungen machen, dafür werde ich aber das am Benutzer gespeicherte Feld über die Bearbeitungen nehmen (Das was man auf den Einstellungen sieht). Das beinhaltet dann keine importe oder Verschiebungen, dürfte aber ähnlich aussagekräftig sein, da Benutzer mit nur solchen Sachen in der Masse untergehen. Der Umherirrende20:15, 19. Aug. 2014 (CEST)
Ich danke dir vielmals, das ist wirklich interessant. Etwa 60 % aller registrierten Konten wurde nie benutzt, weniger als 0,5 % haben mehr als 1000 Bearbeitungen. Nochmals danke, Umherirrender. --BHC (Disk.) 21:58, 19. Aug. 2014 (CEST)
Fehlende <references>-Tag-Kategorie
Moin, es wurde ja vor einiger Zeit eine Sache in der Cite-Extension geändert, wodurch die Möglichkeit embedded in eine Message eine Artikel-Kat zu setzen verschwand. Als Ersatz kam gerrit:145474. Das wurde aber mit gerrit:149091 mit Verweis auf angebliche Parserprobleme rückgängig gemacht und liegt seitdem brach. Wäre nett wenn du da ein Blick drauf werfen könntest, warum das so sein könnte und ob du da ne Lösung findest. Viele Grüße --se4598 / ?01:05, 17. Aug. 2014 (CEST)
Ah, das fiel mir auch neulich auf, als ich am 10. August Special:diff/132946864 per Abschnittsbearbeitung ein ref einfügte, nach Speichern zum references-Tag schaute und weder Wartungskat noch Fehlermeldung in der Seite fand; die Wartungskat leer war.
Gerrit ist vom 11. August, das war aber am 10. August schon ohne Wartungskat gewesen.
Ich hatte in den vergangenen Wochen immer mal in die Wartungskat geschaut, um den Arbeitsanfall einzuschätzen. Die Wartungskat war immer leer. Mein Eindruck: Die hatte noch nie funktioniert. Ggf. Umfrage auf Kategorie:Wikipedia:Seite mit Einzelnachweisfehlern, ob das dortige Wartungspersonal da schon jemals eine Seite gesehen und repariert hat.
Über den weiteren Trubel um Gruppenrechte hatte ich die Angelegenheit auf meiner ToDo-List nach unten geschoben.
Ich klick mich immer durch das Code-Review und freue mich, wenn ich mir dort was verständliches rausfiltern kann. hier wurde was am 24. Juli gemergt, passt auch hierzu. Am 10. August war schon das aktuelle Verhalten implementiert, wenn ich mich jetzt nicht täusche. IW13:42, 17. Aug. 2014 (CEST)
Du hast recht, ich hab mich vom Datum des letzten Diskussionsbeitrags irritieren lassen.
Demnach wäre es spätestens mit Do 31. Juli 1.24wmf15 (oder früher?) deaktiviert; Kat-Einträge kann es nur eine Woche lang gegeben haben (die ich vielleicht nicht mitbekam) und seit 1. August gibt es permanent Null. Danke --PerfektesChaos14:27, 17. Aug. 2014 (CEST)
Ohne dass es noch von Bedeutung wäre; aber war das revert vom 24. Juli mit sofortiger Wirkung oder 1.24wmf15? Ich werde das nie durchschauen. --PerfektesChaos14:56, 17. Aug. 2014 (CEST)
gerrit:149096 ist ja im Branch "wmf/1.24wmf14" (gerrit:149093 ist für 1.24wmf15 und gerrit:149091 für master - was dann 1.24wmf16 ff. geworden ist). Also ja, mit sofortiger Wirkung, wenn auch für das deployment gerrit:149098 benötigt wurde (Weil die Extension Sub-Module in git sind, die aktualisiert werden müssen, soweit ich das verstanden habe). Der Umherirrende15:02, 17. Aug. 2014 (CEST)
Ufff. Heute habe ich den kapiert, aber ob ich mir das auch merken kann? – Somit stimmte meine Beobachtung; da war nach Ankündigung nie ein Artikel in der Wartungskat gewesen. Danke --PerfektesChaos15:19, 17. Aug. 2014 (CEST)
Ich habe mir das mal angeschaut, aber Cite ist keine einfache Extension, weil da auch mit verschiedenen Parser-Instanzen hantiert wird oder so. Keine Ahnung, warum das hinzufügen einer Tracking-Kategorie zu StripMarkers (QINU) geführt haben könnte. Aber der Parser ist keine einfache Sache. Der Umherirrende14:51, 17. Aug. 2014 (CEST)
Noch eine Woche Aufschub für den ArchivBot, aber sieht erstmal schwierig aus, da ich noch nicht ganz verstanden habe, was am damaligen Patch das Problem war. Der Umherirrende09:58, 24. Aug. 2014 (CEST)
Magst du in Special:Diff hineinpatschen?
Gibt man zwei Versionsnummern an, so wird links die erste und rechts die zweite Versionsnummer dargestellt, auch wenn die erste größer als die zweite ist.
Es ist eigentlich auch egal, ob beide revid zur selben oder zu unterschiedlichen Seiten gehören; aber man könnte ein Stückchen Rest-Sinn darin belassen, indem man die beiden Zahlen nur tauscht, wenn die erste größer als die zweite ist und beide zur selben pageid gehören. Aber auch bei unterschiedlichen Seiten wäre die kleinere Nummer zeitlich früher passiert.
Da Special:Diff die Parameter einfach nur an index.php weitergibt, würde der Tausch ja auch für klassische Difflinks sein und auch dort sind gedrehte Diffs möglich, so dass eine Einfügung als Löschung dargestellt wird, weil die linke Version zeitlich später als die rechte Version entstanden ist. Ich weiß aber nicht, ob man damit nicht auch Difflinks kaputt macht, daher würde ich das nicht automatisch tauschen. Der Umherirrende16:41, 6. Sep. 2014 (CEST)
Kaputt macht man wohl kaum etwas; es hat nur Einfluss auf die optische Darstellung.
Bei den klassischen Difflinks hat man einfach nur mit C&P eine URL genommen, die letztlich aus der Beo oder der Versionsgeschichte stammte. Da war die Reihenfolge immer richtig und die Parameter sowieso per Namen zugeordnet, und es gab kaum ein Problem.
Wenn man hingegen manuell das [[Special:Diff/]] ausfüllt, kann es hingegen leicht passieren, dass man unbemerkt bei den sehr langen Zahlen eine Dreher hineinbaut.
Die Korrektur müsste in dem Moment in includes/specials/SpecialDiff.php passieren, in dem er sieht, dass $parts[0]; numerisch größer als $parts[1]; ist. Womöglich dann unter Einschränkung auf dieselbe Seite.
index.php bekommt davon nichts mit, bestehende Aktionen werden nicht verändert. Und bei Spezialseiten-Links ist das eben das gewünschte Verhalten.
Gerade dass irrtümlich suggeriert wird, eine Einfügung wäre eine Löschung, wenn man nicht ganz genau auf Datum und Uhrzeit schaut, ist Anlass für meine Überlegungen.
Die Spezialseite ist in der jetztigen Implementierung nur ein Durchlauferhitzer für die Erstellung des index.php-Links und sollte auch "leichtgewichtig" bleiben.
Um die Bedingung mit den gleichen Seitennamen zu erfüllen, müsste man an dieser Stelle ein Datenbankzugriff einbauen, was die Seite wohl "schwergewichtig" macht.
Die Gefahr von gedrehten Diffs sehe ich nicht so hoch an, auch wenn sie durch die Spezialweiterleitungsseite eher entstehen können, jeder sollte aber vorher noch mal prüfen, ob auch das angezeigt wird, was man wollte.
Ich kann die nächsten Tage mal schauen, ob sich das einrichtigen lässt. Ich meine, das ich automatisch Dateien ausschließe, die mit {{NoCommons}} markiert sind, damit erst garnichts fälschlicherweise übertragen wird und dann hier gelöscht und anschließend doch auf Commons gelöscht wird. Wenn da Konsens ist, das solche Dateien immer übertragbar ist, sollte man das vielleicht dokumentieren. Der Umherirrende21:20, 15. Sep. 2014 (CEST)
Der Ausschluss ist im Prinzip schon richtig, nur bei denen mit PD-Schöpfungshöhe gibt es schon welche, die übertragen werden könnten. Daher wäre zu wissen welche dies sind schon interessant. Grüße --Nachcommonsverschieber (Diskussion) 23:05, 15. Sep. 2014 (CEST)
Ich habe die 276 Sprachversionen der Wikipedia gecheckt. Es wurden rund 360 Dateien gefunden, die mit den hier auf de.wp identisch sind. Sie werden in der nächsten Zeit entsprechend mit der Vorlage versehen. Ich hoffe, dein Vorlagenwunsch habe ich richtig mit berücksichtigt, habe das noch nicht geprüft. Der Umherirrende17:58, 18. Sep. 2014 (CEST)
Danke für die Info. Für den Laien ist es immer etwas verwirrend, wenn Probleme fortbestehen, aber der zugehörige Bug schon "resolved fixed" ist. Gruß --тнояsтеn⇔21:18, 7. Okt. 2014 (CEST)
Ja, zu erkennen, wann welche Version hier auf WMF-Wikis behoben ist oder generell in welchem Release sie sind, ist etwas schwierig. In Bugzilla werden die Bugs als "resolved fixed" markiert, wenn sie in der Entwicklungsumgebung behoben sind, da ab hier kein anderer Entwickler sich diesen Bug anschauen muss. Die Fixes werden dann einmal in der Woche "abgezogen" (meistens Donnerstagsabend) und durchlaufen ab dann die Teststufen von testwiki über mw.org, meta und den anderen Schwesterprojekten und sind nach einer Woche auf Wikipedia verfügbar (nächsten Donnerstagabend). Da die Änderung am 2. Oktober erst nach dem Abzug akzeptiert wurde, wird der Abzug erst am 9. Oktober erfolgen und eine Woche später (also der von Raymond genannte 16. Oktober) ist die Änderung hier. Bei schwerwiegenden Problemen gibt es auch den "cherry-pick", da wird dann vom WMF-Personal die Änderung in die aktuellen Versionen übernommen und ist natürlich sofort behoben, aber ist auch aufwändig und für die Sortierung reicht es nicht als Grund ;-) Der Umherirrende17:19, 8. Okt. 2014 (CEST)
Hiermit verleihen wir Umherirrender/Archiv die Auszeichnung TechnikEule als Anerkennung
für herausragende Arbeit im Dienste der Verbesserung unserer Enzyklopädie. gez. WikiEulenAcademy 10/2014
Na Umherirrender,
du hast doch wohl nicht gedacht, wir hätten dich vergessen?[1] Wir sind nur auch nicht mehr die Jüngsten und auch Eulen brauchen ihren Schlaf... Vorlage:Smiley/Wartung/;)
Die WikiEulenAcademy schließt sich jedenfalls den obigen Glückwünschen an und gratuliert dir recht herzlich zur WikiEule 2014. Vorlage:Smiley/Wartung/blumen
Es ist uns eine Ehre dir neben der Eule für den Schreibtisch eine WikiEule für deine Benutzerseite zu überreichen.
Sollte dir diese einmal zu groß sein, haben wir einen entsprechenden Babel vorbereitet:
Selbstverständlich darfst du diese Auszeichnung auch in andere „Wikis“ tragen. Für WikimediaCommons und Wikidata sind diese schon vorbereitet. Nach Meta und uns MediaWiki haben wir uns noch nicht getraut.
Wir wünschen dir noch viel Freude und hoffen auf weitere großartige Beiträge.
Vielleicht sieht man sich auch bei anderen Treffen oder der nächsten WikiCon wieder?
Ja, die Sache mit dem Schlaf ;-) Ich war vielleicht etwas ungeduldig mit dem Übertrag, aber war nicht davon ausgegangen, das ich vergessen wurde, sondern das es seine Zeit braucht.
wärst du so nett, künftig als Testfälle Artikel über Gänseblümchen oder Gebirgsbäche als Testfälle auf BETA zu kopieren, nicht aber über Personen?
Grund: In den Testseiten gibt es auch Tastaturtests und wüsten Vandalismus und Gemansche.
Wenn jemand ein Gänseblümchen ausrupft oder einen Baum umsägt, ist das nicht weiter schlimm.
Aber wenn in einem Artikel über Menschen eine dicke Nase gemalt oder Nonsens geschrieben wird, ist das genauso im Netz veröffentlicht wie in echt, und fällt auf uns zurück.
Ich hatte kürzlich den gesamten Bestand an personenbezogenen Inhalten aus BETA gelöscht. Pikanterweise hatte man mal als Grundausstattung genau ein Dutzend Biografie-Artikel gezielt ausgewählt.
Schiffe versenken ist völlig in Ordnung. Zumal man hier noch nicht mal ein bestimmtes torpedieren könnte.
Bloß Artikel über Personen, Religionen, Politik oder sonstwie brisante Themen sollten auf BETA nicht als Buchstabenquelle dienen und womöglich von Suchmaschinen gefunden werden und mitsamt Tastaturtest weitergemeldet.
Klingt gut, da man in Benutzerseiten ja nicht eingreifen soll, um mögliche Fehler zu behebn. Habe es mal eingebaut und die entsprechenden Seiten mit einem linkupdate versehen. Der Umherirrende18:46, 11. Nov. 2014 (CET)
Danke schön; in Benutzerseiten nicht und sowieso nicht in die wilden Lua-Experimente. Die können die hübsch alleine austüfteln. Schönen Abend --PerfektesChaos19:03, 11. Nov. 2014 (CET)
Suche in Namensräumen
Ich beschäftige mich aus aktuellem Anlass damit, die Suche intuitiver zu machen.
Auf Spezial:Suche stehen vier Modi zur Spezifikation von Namensräumen zur Auswahl.
Ich fände es schick, wenn das jeweilige Selbstlink einen blauen oder grünen Rahmen bekäme; als Zeichen, das man jetzt in diesem Bereich sucht.
Ausgewählt ist LI.current (die nicht aktiven haben LI.normal).
Im Moment gehört Know-How dazu, um aus dem Umstand, dass ein Begriff schwarz ist, die anderen drei aber blau, den Rückschluss zu ziehen, dass das schwarz erscheinende Link die Auswahl ist.
Im Prinzip würde das unsere Common.css belasten; aber diese ulkige Linkeinfärbung muss ja auch irgendwo weltweit definiert sein; vielleicht gleich dort das LI.current mit einem gestrichelten Rahmen in dunkelgrau oder mittelblau versehen? Trifft das nur diese Spezialseite, oder kommt .current noch woanders vor? Womöglich genauso zu verdeutlichen.
Damit wird aber nur der Link sichtbar "unklickbar", obwohl er weiterhin klickbar ist (sofern ich das verstanden habe). Was hattest du dir da vorgestellt (in CSS)? Ich vermute aber, das wird eine Diskussion mit dem Design Team nach sich ziehen. Vielleicht solltest du das ab dem 21. November dann selber starten ;-) Der Umherirrende20:13, 16. Nov. 2014 (CET)
Das ist ja fein; CSS bei der Spezialseite selbst. Danke für das Suchen.
Ich hatte vergeblich nach einer globalen Definition für .current gefahndet.
Ich stelle mir vor, den oberen (oder das Elternteil) zusätzlich mit etwas zu beglücken wie
border: #8080FF 1px dashed;
padding: 3px;
Damit wird optisch verdeutlicht, in welchem NR-Modus die Spezialseite gerade ist.
Richtig ist, dass ich Ende November auf Streifzug in das Phabland gehen werde; mal sehen.
Dank des ResourceLoaders ist es ja möglich Module für alles mögliche zu schreiben, so auch für Spezialseiten im allgemeinen und bei der Suche gibt es noch ein Untermodul. Die dashes machen es besser, wäre aber etwas neues. Ich habe so etwas noch nicht im Kontext von MediaWiki gesehen, mir fällt aber auch keine bessere Möglichkeit ein, um hier etwas hervorzuheben. Der Umherirrende21:36, 16. Nov. 2014 (CET)
Die dashes wären die schlichteste Variante. Heftiger wäre etwas mit Hintergrundfarben und Rahmen oder so.
Die dashes sind keineswegs neu. Bei der Auswahl zu vergleichender Versionen in der VG gibt es sie auch.
Übrigens brächte ich es in den nächsten Monaten allenfalls zu einem neuen Phab-T oder wie immer die Bugs dann heißen mögen. Akzeptable Pätsche zuliefern kann nur ein promovierter Developer.
Man übersieht diese Meldung häufig und dann kommt es zu Komplikationen. Ich wollte es leicht ändern, s. hier, doch dass unterliegt alles jetzt einem aus meiner Sicht übertriebenen Zentralismus. In Translatewiki werde ich derzeit nicht eingeloggt und habe auch keinen Bock, nützliche Änderungen immer umständlicher machen zu müssen. -jkb-16:34, 18. Nov. 2014 (CET)
@-jkb-: Dein rot finde ich etwas deplatziert. Außerdem werden immer nur zwei Versionen in einem Versionsunterschied angezeigt, da ist logisch, das alles dazwischen nicht angezeigt wird. Ich finde die Nachricht daher aussagekräftig.
"dass unterliegt alles jetzt einem aus meiner Sicht übertriebenen Zentralismus": Den Zusammenhang zu der Änderung einer Systemnachricht verstehe ich nicht.
"In Translatewiki werde ich derzeit nicht eingeloggt": translatewiki.net gehört nicht zu WMF und fällt damit nicht unter WP:SUL.
Danke, so passt es. Bezieht sich auf „Versionen“, ja. Wenn es mehrere Benutzer sind, sind es automatisch mehrere Versionen. Das Rot finde ich gar nicht mal so schlecht, nur wäre es bei dem Diff zu anderen Benutzern noch besser aufgehoben als bei dem zum selben Benutzer. Dann müsste man es also eher bei MediaWiki:Diff-multi-otherusers platzieren, damit es beim Aufrufen der Änderungen der eigenen Disk. besser auffällt, dass dort mehrere Benutzer etwas geschrieben haben. Könnte man also so lokal abändern und mal ausprobieren:
({{PLURAL:$1|Eine dazwischenliegende Version|$1 dazwischenliegende Versionen}} von {{PLURAL:$2|einem anderen Benutzer|$2 Benutzern}} {{PLURAL:$1|wird|werden}} <strong style="color:red">nicht angezeigt</strong>)
($1 dazwischenliegende Versionen von $2 Benutzern werden nicht angezeigt)
Oder nur rot, aber nicht auch noch fett, denn mit Signalfarbe sollte es doch genügend ins Auge fallen, oder? Beim selben Benutzer allerdings ist das wohl unnötig bzw. eher unwichtig zu betonen. Und wenn man es nur beim anderen Benutzer, aber nicht beim selben Benutzer betont, fällt es in diesem Fall auch mehr ins Auge, als wenn es bei beiden Varianten standardmäßig steht. Also am besten aus der einen lokalen MW-Seite wieder raus und stattdessen in die andere rein. --Winternacht in Wikimediassupergeschützten Wikis17:35, 18. Nov. 2014 (CET)
Bei mir steht schon in der Echo-Meldung, das mehrere Benutzer etwas geschrieben haben. Da der Text aber bei allen möglichen Versionsunterschieden angezeigt wird, finde ich das etwas unpassend. Aber wenn es der Mehrheit gefällt, lassen wir es. Der Umherirrende18:19, 18. Nov. 2014 (CET)
Ich weiß nicht warum, aber im obigen Diff steht immer noch „werden“ statt „wird“. Wird das lokal gar nicht mehr zeitnah aktualisiert? Dann sollte man die lokale Nachricht entsprechend anpassen, bis es irgendwann übertragen wurde. Außerdem ist dasselbe auch hier, da und dort falsch. --Winternacht in Wikimediassupergeschützten Wikis19:06, 19. Nov. 2014 (CET)
Nein, das ERROR steht für etwas anderes. Die Sprachvarianten müssen nicht angepasst werden, weil MediaWiki für diese Sprachen ein Rückfallsprache kennt, die Deutsch ist. Diese Rückfallsprache wird genutzt, wenn für die Systemnachricht keine eigene Nachricht in der Sprache existiert. Du findest sie auch nicht auf translatewiki.net um sie anzupassen. Da es aber anscheind so wichtig ist, habe ich die Änderung lokal vorgeholt (und natürlich auch die Sprachvarianten). Der Umherirrende19:43, 19. Nov. 2014 (CET)
bitte auch MediaWiki:Diff-multi-otherusers in rot umändern. grade wenn die änderungen von verschiedenen benutzern sind ist ein hinweis wichtig, viel mehr, als bei einem einzelnen benutzer. --Wetterwolke (Diskussion) 19:17, 18. Nov. 2014 (CET)
Eigentlich nur da und nicht bei der anderen Seite. Denn dann fällt es besser auf, wenn es verschiedene Benutzer sind, und man sieht dann am Rot auch sofort, dass mehrere Benutzer gepostet haben und im Diff enthalten sind. Also bei einem Benutzer raus und stattdessen bei mehreren Benutzern rein. @-jkb-: Machst du das? Oder Umherirrender? --Winternacht in Wikimediassupergeschützten Wikis21:48, 18. Nov. 2014 (CET)
Für mich sieht das mit der Signalfarbe wie eine Warnung aus, dass irgendwelche Änderungen nicht angezeigt werden. Es ist doch in aller Regel so, dass man einen Bereich in der Versionsgeschichte wählt, klickt auf "Gewählte Versionen vergleichen", dann wird genau das anzeigt was man ausgewählt hat – aber in einer Form, sie suggeriert dass etwas schiefgegangen ist. --PM315:05, 19. Nov. 2014 (CET)
Nein, dringend behalten, passiert häufig, wie ich gelewsen habe, zuletzt sogar mir (s. hier), wenn man auf die Links der Notifikation klickt. Da steht häufig "1 Nachricht", es sind aber mehr und man übersieht die restlichen. Wenn's nicht rot unterlegt ist, so merhkt mans gar nicht. -jkb-15:17, 19. Nov. 2014 (CET)
D.h. es ist ein Workaround für ein Notify-Problem, welches auch nicht leicht zu beheben ist. Mist. Man bräuchte unterschiedliche Meldungen, je nachdem von wo die Diff aufgerufen wurde. --PM315:27, 19. Nov. 2014 (CET)
Wie oben schon geschrieben, steht auch schon in Echo: "YXZ und weitere Benutzer hinterließen eine Nachricht auf deiner Benutzerdiskussionsseite.". Aus diesem Grund sollte das im Versionsunterschied weg, weil man es in Echo bereits lesen kann und damit ist sichergestellt, das es nur kurz vor dem Öffnen der Benutzerdiskussionsseite zu lesen ist. Wenn in 4 Minuten zwei Abschnitte kommen, dann sollte entweder der Name des ersten Abschnitts in Echo stehen, daran kann man es auch erkennen. Der Umherirrende18:04, 19. Nov. 2014 (CET)
Aber wenn erst der erste, dann der zweite und dann wieder der erste Benutzer hintereinander posten, steht in der Benachrichtigung derselbe Benutzer wie im Diff ganz oben. Dann merkt man es also nicht daran. In jedem Fall aber ist es so wie jetzt Kappes, wie ich oben schon zweimal schrieb. Denn zurzeit werden ja nur die Diffs rot dargestellt, wo eben gerade nicht zwei oder mehrere Benutzer gepostet haben, sondern wo vom selben Benutzer mehrere Versionen hintereinander kamen so wie hier. Kann mir bitte jemand den Sinn erklären, wenn das gerade nicht beabsichtigt war? Dann sollte man es doch abändern, so dass das herauskommt, was gewollt war, nämlich dasselbe in den anderen Diff einfügen. Das hätte auch noch den weiteren Vorteil, dass endlich nicht mehr da stünde „werden“ statt „wird“. So wie es jetzt ist, ist es jedenfalls Quatsch. Bitte ändern, damit das Ganze zumindest einen Sinn ergibt. Dann kann man weiter diskutieren. Aber das jetzt einfach so falsch stehen zu lassen, halte ich für falsch. Grüße --Winternacht in Wikimediassupergeschützten Wikis19:20, 19. Nov. 2014 (CET)
Nein, dann noch einmal: Wenn eine Notification zuschlägt, dann sehe ich ganz deutlich und alles überragend 1 . Dass darunter noch manchmal richtig (nocht immer) ein Blala ... und noch jemand ... beachtet man doch gar nicht, ich will eine (1!) Nachricht sehen, also klicke ich auf den Difflink und lese etwas. Das da ebenfalls noch etwas undeutlich steht, merkt man nicht, wenn man täglich mit zig Vandalismen usw. zu tun hat. Dann passiert das wie bei mir, dass ich einen User zu Unrecht anmache. Wenn da eber zumindest ein Teil der Nachricht farbig schreit, dann lese ich doch, und erst da erfahre ich, dass so und so viele zwischenliegende Edits da sind. Es hat einen Sinn, solange die Ziffern in der Notifikation nicht den Tatsachen entsprechen. Gruß -jkb-19:34, 19. Nov. 2014 (CET)
Die 1 bedeutet, das dort ein "Event" ist, das Event kann seinerseits aus mehreren Versionen bestehen. Ich finde es auch nicht schön, das mehrere Nachrichten zusammengefasst werden, aber es steht dort und man muss es auch lesen, weil ein Klick auf die rote 1 öffent nur das Menü, wo der Versionsunterschied ist. Das rot ist aber auch irreführend, da die Echo-Nachricht die korrekten Informationen wieder gibt, habe ich das rot wieder entfernt. Hier sind die Erwartungen und die tatsächliche Umsetzung nicht deckungsgleich, wäre als etwas für Hilfe Diskussion:Echo, aber eine solche Umgehungslösung die bei allen Versionsunterschieden auftaucht ist da nicht hilfreich. Der Umherirrende19:43, 19. Nov. 2014 (CET)
Cite futsch?
Hi, gerade über Hilfe:Spezialseiten/Liste guckend, ist MediaWiki:Cite in „⧼Cite⧽“ plötzlich redlink aber Special:Cite noch da. Dafür schaltet es kursiv; zwei Apostrophe als Begrenzer einer leeren Zeichenkette wohl.
Die Spezialseite wurde mit gerrit:149593 und gerrit:149592 in ein eigenes Repo geschoben (und umbenannt) und deshalb findet sich die Nachricht unter MediaWiki:citethispage, was aber auch bedeutet, das sich der kanonische Name geändert hat, was nicht so schön ist. Das mit dem Kursiv ist aber schon komisch und werde ich mir näher anschauen. Der Umherirrende16:42, 21. Nov. 2014 (CET)
Bei nicht existierenden Nachrichten wird der Name in spitze Klammern gepackt, du kannst dir ja denken, was dann für ein Tag raus kommt und vom WikiParser als HTML bis zur Ausgabe durchgeschleust wird ;-). Solltest ein Phab (oder wie die Dinge heißen werden) in ein paar Tagen aufmachen ;-) Der Umherirrende16:56, 21. Nov. 2014 (CET)
Aaaaah.
Ich ging natürlich davon aus, dass kanonische Namen nie nie nie verändert würden, und hatte deshalb nicht in Betracht gezogen, dass Special:Cite heute ein Alias sein könnte. Ich seh hinterher sowieso nur „Zitierhilfe“.
Gewonnen hat der Stratege damit wenig; weil Special:Cite weiterhin Alias bleibt und bleiben muss, ist kein Name für eine andere Verwendung frei geworden, und die alten Verlinkungen wird er ja wohl nicht auch noch brechen wollen.
Es träfe also nur eine Handvoll Programmierer. Ob jemand in einem user script den kanonischen Namen abfragt, weiß ich nicht; exotisches Thema. Im Zweifelsfall haut irgendwo in MW selbst mal was nicht hin; deren Problem.
Ich werde mir merken müssen, dass dieses MW-Management auch vor Änderungen an kanonischen Namen nicht zurückschreckt.
Für nächstes Wochenende habe ich meine erste Phab-Bugmeldung eingeplant, und werde anhand dieser Erfahrungen auch die künftige Doku-Seite komplettieren. Erstmal muss das aber stabil werden, also kein rollback am Dienstag oder Donnerstag; abwarten.
Ja, da werden immer mal Dinge nicht kompatibel geändert. Eine Übersicht über alle Spezialseiten findest du über die API: meta=siteinfo&siprop=specialpagealiases, dort sind aber auch Spezialseiten aufgelistet, die nur für die interne Verwendung sind oder sonst keine Notwendigkeit hier haben. Bin mir nicht sicher, ob der "realname" der kanonische Name ist, weil es auch Seiten gibt, wo der realname nicht als alias auftaucht. Der Umherirrende12:21, 22. Nov. 2014 (CET)
Hi, ich brauch mal wieder Hilfe von einem Durchblicker.
Ich fand zufällig ein Konstrukt {{msg: bei der Vorlageneinbindung.
Es ist nirgendwo dokumentiert.
Es gibt nur das {{msgnw: für die Experten.
Es scheint heute eine Art NOOP zu sein; vielleicht hatte es vor zehn Jahren mal eine Bedeutung.
Im ANR kommt es auf 27 Seiten vor. Ich würde empfehlen, es dort zur Vermeidung von Verwirrung zu entfernen; außerdem aus jeder Vorlagenprogrammierung und aktiven WP-Seiten.
Ich habe ums Verrecken Cirrus nicht dazu bekommen und escaped gekriegt, mir alle Vorkommen von ).live( im BNR und WPNR aufzulisten.
Schaust du mal in einen Dump, der ruhig ein paar Monate alt sein kann, wo sich die rumtreiben und wo ein Fix sinnvoll wäre? Sicherheitshalber .live( ohne die Klammer am Anfang.
Du musst ja nicht in den Skripten vorübergehend inaktiver Benutzer herumkorrigieren.
msg: ist als obsolete gekennzeichent. msgnw: dürfte aus der Zeit stammen, wo es noch kein Vorlagennamensraum gab, mehr Infos unter mw:Help:Magic words#Template modifiers. Eine Aktive Verwendung kann ich mir nicht sinnvoll vorstellen.
Magst du auf fachliche Richtigkeit prüfen und um weitere Manual-Seiten mit wichtigen DB-Tabellen ergänzen?
Und dann kannst du mir mal verraten, wo zum Henker definiert ist, dass die Special:PermanentLink einen Alias PermaLink habe, und ob das für alle Wikis weltweit gilt? Ich hab schon alle möglichen configs und includes geflöht, aber irgendwie verstecken sich solche Sachen vor mir.
Quarry wird dir beim suchen in Quelltexten vermutlich nicht helfen, weil die Texte normalerweise nicht repliziert werden (war zumindestens auf dem Toolserver so, keine Ahnung, ob sich das mit Labs geändert hat). Ich werde aber mal über die Seite schauen. Die Beschreibung der Tabellen ist auf mw.org auch nicht schön und aktuell, aber ich kann ja mal eine Übersicht basteln. Der Umherirrende18:27, 20. Dez. 2014 (CET)
Grund: Es betrifft ja auch die Produktivversion eines Wiki, dokumentiert einen Aspekt der allgemeinen Wiki-Software und nicht nur Labs.
Deshalb ist es dann auch richtig, dass text mit aufgezählt wird; mit dem ausdrücklichen Hinweis, dass das halt bei den Replikaten und unter Quarry nicht mit bei ist.
Ansonsten muss es auch nicht vollständig sein; der Reiz ist ja gerade die übersichtliche Beschränkung auf das, was von Anwendern wirklich benötigt wird. Mehr muss es wirklich nicht werden; ist ja schon Fleißarbeit genug.
Es sind dann auch nur die öffentlich sichtbaren Infos verfügbar, nicht aber gelöschte, v-gelöschte oder OS. Da das normale Anwender sowieso nicht sehen können, braucht es dafür auch keine Doku. Und Admin/OS-Rechte gibt es für SQL sowieso nicht.
Im Übrigen hätte ich mit ja denken können, dass bei Quarry noch irgendein Haken ist und ich im Zweifelsfall Dump-Durchsucher brauche; Cirrus ist zwar ganz nett und es wurde anscheinend für die weltweiten RegExp-Anfragen auch mindestens ein neuer Server gekauft, aber bei den Sonderzeichen versagt das oft. Zumal es keine saubere Doku für deren RegExp-Syntax gibt; ich taste mich anhand der Fehlermeldungen so allmählich ran. Ist mutmaßlich ein stark PHP-betonter Dialekt, aber immer wieder überraschend.
Danke für die Geschenke. uselang tippe ich meistens noch ein, weil so häufig es auch nicht vorkommt. Für forcelinkupdate habe ich schon etwas, das recursive braucht man ja nicht häufig. Schöne Feiertage gehabt zu haben. Der Umherirrende10:28, 27. Dez. 2014 (CET)
War ja nur ein Angebot; dass du dir irgendwie zu helfen wusstest, ist mir klar. Neben einfachem purge für alle Anwender und forcerecursivelinkupdate noch eine dritte Stufe anklickbar zu machen war mir aber zu konfus; wenn schon mal linkupdate, dann halt gleich mit Vollgas. LG --PerfektesChaos16:23, 27. Dez. 2014 (CET)
Die WikiEulenAcademy schließt sich jedenfalls den obigen Glückwünschen an und gratuliert dir recht herzlich zur WikiEule 2014. 
Funkruf WP:CVU 10:51, 11. Okt. 2014 (CEST)