Wikiup Diskussion:Projektneuheiten/Archiv/2012

aus Wikipedia, der freien Enzyklopädie
< Wikiup Diskussion:Projektneuheiten‎ | Archiv
Dies ist die aktuelle Version dieser Seite, zuletzt bearbeitet am 31. Mai 2022 um 20:34 Uhr durch imported>PerfektesChaos(310926) (lf).
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

1.19 – Laden im HEAD

Anmerkung zu Eine Konfigurationsvariable ermöglicht das Laden von JavaScript-Module im head-Bereich anstatt am Ende des body-Bereiches. Dadurch werden die Module früher geladen und die Seite schneller geladen

Ich dividiere die Aussage mal auseinander: Dadurch werden die Module

  • früher geladen – ja
  • und die Seite schneller geladen – kommt drauf an. Das hängt davon ab, was die Skripte so treiben, und von der Sachkunde der Entwickler.

Wenn das Skript im HEAD-Bereich wenig zeitaufwendige grundlegende Weichenstellungen vornimmt, wird es schneller. Beispiele:

  • Einfügen von zusätzlichem CSS-Code (der vielleicht Teile der Seite unsichtbar macht und damit auch ein nachträgliches Ruckeln vermeidet) ist immer sinnvoll, damit es bereits auf das Rendern einwirken kann.
  • Abfeuern einer API-Abfrage, die parallel wirken kann, und bereits mit dem Ende der Seitendarstellung zum Einarbeiten verfügbar ist.

Wenn ein solches Skript aber umfangreiche Denkprozesse startet, deren Ergebnis für den Leser zunächst unsichtbar bleibt, dauert es länger, bis die Seite für den Leser (vollständig) sichtbar ist, oder es wird sogar mit der Darstellung abgewartet, bis das Skript fertig ist. Verborgene Hintergrundaktivitäten sollten erst durch das document.ready ausgelöst werden.

Das fragliche $wgResourceLoaderExperimentalAsyncLoading ist aber ohnehin als experimentell benannt, und für die de.WP wohl eher nicht als Standard zu empfehlen?

VG --PerfektesChaos 22:46, 6. Jan. 2012 (CET)

Nur zur Info für Mitlesende: Im Kommentar der Revision 108184 und im Bug gibt es noch viel mehr zum Thema, sowie in den Kommentaren zur Revision. Scheint es schwieriges Thema zu sein. Ich denke aber auch nicht, das in absehbarer Zeit das aktiviert wird. Da deutet schon das Experimental drauf hin. Der Umherirrende 20:48, 10. Jan. 2012 (CET)

WP:?#Erweiterte Suche

Vielleicht weiss jemand der hiesigen Watchers weiter… Mich stört das jedenfalls ziemlich und werde dabei wohl nicht der einzige sein. --Leyo 13:52, 7. Jan. 2012 (CET)

Ich hatte unterhalb von rev:106780 bereits einen Kommentar hinterlassen, aber es gibt jetzt auch Bug 33583. Der Umherirrende 18:37, 7. Jan. 2012 (CET)
Danke! Dann hoffen wir, dass der Bug bald behoben wird. --Leyo 20:37, 7. Jan. 2012 (CET)
Gefixt. Danke an alle, die dazu beigetragen haben! --Leyo 00:35, 14. Jan. 2012 (CET)

JavaScript: Programmierende Admins benötigt

Die zwangsweise bei jedem Benutzer ausgeführten JS sollten auf den aktuellen Stand von MW 1.18 gebracht werden, solange die Situation noch übersichtlich ist. Wenn dann MW 1.19 kommt, könnten alte und neue Probleme sonst ununterscheidbar werden. Mit den neuartigen Browsern (asynchrones Laden) wird eine stetige Anpassung unumgänglich und muss sowieso früher oder später umgesetzt werden. Erst letzte Woche hatte wieder jemand Probleme mit addOnloadHook.

Schönes Wochenende --PerfektesChaos 11:34, 22. Jan. 2012 (CET)

Wer möchte, kann auch gerne auf dem Testwiki Site-JavaScript und Gadgets testen. Wer dafür Adminrechte braucht, der sollte sich hier mit dem Benutzernamen von dort melden, die Adminrechte lassen sich dann einrichten. Der Umherirrende 20:38, 23. Jan. 2012 (CET)
Ein Gadget, das wohl den Test dort sehr nötig hat, ist (mal wieder) MediaWiki:Gadget-Extra-Editbuttons.js. Das Gadget ist eine Art russisches Roulette, es vertraut darauf, dass der Code vom Gadget, der von mediawiki.action.edit.js, im Falle von Benutzerkonfigurationen auch noch der Code der einzelnen Benutzerskripte jeweils zum genau richtigen Zeitpunkt stattfindet. Es würde mich nicht wundern, wenn das furchtbar schiefgeht. --Schnark 10:58, 24. Jan. 2012 (CET)
Hm, scheint doch zu funktionieren. Da ich aber vorhin noch einen Bug gegen mediawiki.action.edit.js bezüglich dem Ausführungszeitpunkt gemeldet habe, kann sich das aber auch noch ändern. --Schnark 12:04, 24. Jan. 2012 (CET)
Die anderen Gadgets funktionieren auch, nur Popups ist der Ansicht, das alle Seiten leer sind. --Schnark 12:13, 24. Jan. 2012 (CET)

REVISIONUSER in der Vorschau

Besteht die Chance, dass {{REVISIONUSER}} in der Vorschau wieder aktiviert wird? Ansonsten müssten einige Editnotices und Ähnliches angepasst werden. --Leyo 14:44, 6. Jan. 2012 (CET)

REVISIONUSER zeigt in der Vorschau deinen Benutzernamen an, aber die Editnotice wird nicht mehr als Vorschau behandelt. Nur REVISIONTIMESTAMP ist in der Vorschau ein leerer String. Das hat sich bis jetzt (noch) nicht geändert. Ob sich das aber noch ändert, kann ich nicht sagen. Der Umherirrende 22:54, 6. Jan. 2012 (CET)
Sind die Editnotices in allen NR betroffen? Falls Ja, wäre es wohl sinnvoll die betroffenen Seiten (≠ BNR) durchzugehen und ggf. anzupassen. --Leyo 14:01, 11. Jan. 2012 (CET)
Ich meine, dass ich genau das schon längst getan habe: [1] --Schnark 10:36, 12. Jan. 2012 (CET)
Waren wirklich nur so wenige Seiten betroffen? --Leyo 10:57, 12. Jan. 2012 (CET)
Wenn ich beim Durchsuchen des Dumps keine Fehler gemacht habe: Ja. --Schnark 11:07, 12. Jan. 2012 (CET)
Mindestens eine hatte ich wohl aus irgendeinem Grund übersehen oder mit (… Diskussion zusammengeworfen): Vorlage:MediaWiki Newarticletext NS Benutzer. --Schnark 12:30, 12. Jan. 2012 (CET)
Um genau zu sein: Bei mindestens den folgenden Vorlagen existiert ein nutzloser if-Zweig:
--Schnark 09:50, 13. Jan. 2012 (CET)
Danke! Könnte vielleicht ein Admin, der sich mit diesen Vorlagen auskennt, {{REVISIONUSER}} entfernen? --Leyo 11:30, 17. Jan. 2012 (CET)
Ersetze {{#ifeq: X | {{REVISIONUSER}} | A | B }} durch B (etwas anderes passiert ohnehin nicht, und formuliere danach das ganze so um, dass es sich sowohl für den Besitzer der Seite als auch für fremde sinnvoll anhört. --Schnark 11:47, 17. Jan. 2012 (CET)
OK, ich hoffe es korrekt umgesetzt zu haben. --Leyo 12:13, 24. Jan. 2012 (CET)
Den ersten Teil meiner Anweisung hast du korrekt umgesetzt, nur sind Formulierungen wie „Wenn du Benutzer Benutzername bist, dann melde dich bitte an, um diese Seite zu erstellen.“ nicht sehr sinnvoll, wenn man gerade als Benutzer Benutzername angemeldet ist. Ein Benutzer sieht auf der noch fehlenden Benutzer(-diskussions-)seite bzw. beim Erstellen über dem Editfenster genau die 4 Texte, sodass sie alle so formuliert sein sollten, dass sie für alle Benutzer sinnvoll klingen. --Schnark 12:51, 24. Jan. 2012 (CET)
Naja, deshalb hatte ich ja darum gebeten, dass sich ein Admin, der sich mit diesem Vorlagen auskennt, die notwendigen Änderungen vornimmt. Ich warte nun mal etwas ab… --Leyo 13:56, 24. Jan. 2012 (CET)
Wäre ich Formulierungskünstler, hätte ich ja auch konkrete Vorschläge gemacht. Immerhin kann man jetzt im Quelltext erkennen, was die Vorlagen wirklich ausgeben. --Schnark 09:10, 25. Jan. 2012 (CET)

akeytt() in JavaScript ab 1.19

  • Die Funktion akeytt() wird ab MW 1.19 undefined sein.
  • Zurzeit sind es noch 25 Treffer in unseren Benutzer-.js sichtbar – unklar, welche davon noch aktiv benutzt werden.
  • Ein Skriptbenutzer muss nicht der Autor sein.
  • Zukünftig wird das gesamte umgebende Skript abstürzen; kommentarlos für einfache Benutzer. Bisher war die Funktion zwar offenbar wirkungslos, störte aber wohl auch nicht.
  • Ich schlage die Aufnahme folgender Funktion in die Mediawiki:Common.js vor (ggf. anonym und/oder parametrisiert mehrfach nutzbar):
 function akeytt() {
    alert("Ein Skript benutzt die veraltete Funktion akeytt()." +
          "\nWenn du der Autor des Skripts bist, solltest du sie entfernen." +
          "\nWenn du nichts darüber weißt, kannst du auf [[WP:TSW]] nachfragen." +
          "\n-- de.WP");
 }
  • MW 1.19 braucht nicht abgewartet werden; das kann auch sofort erfolgen. Ein Kommentar kann die Entfernung für 2013 vorsehen.

VG --PerfektesChaos 13:50, 10. Jan. 2012 (CET)

Da ich nicht denke, das neue Verwendungen hinzukommen, würde es aus meiner Sicht reichen, wenn man die betroffenden persönlich anschreibt und auch Hilfe direkt mit anbietet oder per Bot und auf WP:TSW verweist. Meine Vermutung liegt aber nah, das es sich um JavaScript von inaktiven Benutzern handelt. Sonst würde es vermutlich irgendwie schon aufgefallen sein. Der Umherirrende 20:42, 10. Jan. 2012 (CET)
Ein paar der Namen sind prominent und aktiv.
Das aufrufende Skript kann durchaus noch benutzt werden, weil akeytt() zurzeit wohl einfach nichts tut.
Auch wenn der Autor des Skripts seit Jahren inaktiv ist, kann das Skript noch täglich von anderen Benutzern aufgerufen werden. Wer auf welchen verschlungenen Wegen was importiert, möchte ich nicht eruieren müssen.
Aber wenn du magst, kannst du gern parallel ein paar alte Bekannte kontaktieren und um Löschung aus dem Suchergebnis bitten.
Viel Spaß --PerfektesChaos 20:50, 10. Jan. 2012 (CET)
Ich hatte bei der Verteilung der Benutzeranschreiben nicht direkt an mich gedacht … ;-) Der Umherirrende 22:00, 10. Jan. 2012 (CET)
So ganz inaktiv sind nicht alle Benutzer: Benutzer:DerHexer/addotrs.js. Die Suche listet aber nicht alle (nachdem es jetzt verlinkt ist, vielleicht schon), sodass jemand mit einem Komplett-Dump eine Liste erstellen sollte. --Schnark 09:24, 11. Jan. 2012 (CET)

Wenn die Funktion sowieso seit mehreren Jahren (!) vollständig funktionslos war, dann verstehe ich ehrlich gesagt nicht, wieso nicht einfach ein Administrator durch die Skripte der inaktiven Benutzer gehen kann (die aktiven sollten selbstverständlich angesprochen werden) und die Zeile auskommentiert und mit einem Hinweis versieht. Jetzt ein Skript zu vermüllen, weil ein anderes entmüllt wird, erscheint mir irgendwie widersinnig, vor allem da es scheinbar nur um ein paar wenige Duzend Fälle geht. --TMg 09:37, 11. Jan. 2012 (CET)

Das war auch mein Gedankengang. Warum sollen alle Nutzer Code erhalten, der nur für eine kleine Zahl von ihnen gedacht ist und dort wiederum nur dafür sorgt, dass nichts passiert? --32X 10:25, 11. Jan. 2012 (CET)
  • Alle Benutzer werden schon seit Jahren mit wirkungslosem und längerem Code zu akeytt() belästigt; auch jetzt gerade.
  • Dies vorübergehend und ab sofort durch eine auf eine Zeile eindampfbare shutdown msg als Abschluss der Angelegenheit zu ersetzen, bedeutet eine Reduzierung der Inanspruchnahme von Ressourcen. Per Kommentar wäre ein geeignetes Verfallsdatum mitzugeben.
  • Dass Benutzerskripte von Anderen verändert würden, scheint mir ein Novum. Dies wäre bei Missbrauch oder anders nicht zu beseitigendem Schadverhalten zu rechtfertigen; hier wären aber vermutlich die allermeisten Skripte tatsächlich inaktiv – das heißt, nicht nur der Autor wäre nicht mehr in der WP tätig, sondern das Skript wird auch von niemandem mehr benutzt.
  • Niemand kann sagen, welche der fraglichen Skripte in 2012 überhaupt noch aufgerufen werden und von wem.
  • Die Reduzierung der momentanen Blindfunktion auf die vorgeschlagene Warnmeldung bedeutet den geringsten Aufwand. Eine mehrwöchige Kommunikationsphase mit inaktiven Skriptautoren wäre wenig effizient; der administrative Eingriff in die Programmierung fremder Benutzerskripte existiert in meinem Weltbild nicht.
  • Weil die weitere Reduktion der wikibits abzusehen ist, kann man sich aber gern mal grundlegend mit der Problematik auseinandersetzen. Wir simulieren zurzeit auf :de:MediaWiki:Common.js auch ein veraltetes includePage() durch ein ebenfalls veraltetes importScript() – angesichts der aktuellen Browser mit asynchronem Laden wäre mir mw.loader.load() lieber. Ein halbes Dutzend weiterer Kandidaten wüsste ich hier. mwEditButtons/mwCustomEditButtons sind wohl die nächsten Fälle für eine Betreuung durch das lokale Projekt, oder das Konzept der AccessKeys@wikibits.

VG --PerfektesChaos 13:35, 11. Jan. 2012 (CET)

der administrative Eingriff in die Programmierung fremder Benutzerskripte existiert in meinem Weltbild nicht. – Lerne damit zu leben, denn der administrative Eingriff in die common.js ist nichts anderes, jedoch mit dem Unterschied, dass er bei sämtlichen Benutzern (mit aktiviertem JS) erfolgt. --32X 15:14, 11. Jan. 2012 (CET)
Das meinte ich, danke. Wenn 100-prozentig sichergestellt werden kann, dass eine Ersetzung nichts verändert, dann sehe ich da wirklich kein Problem. Da es sich meist um das immer selbe kopierte Benutzerskript handelt, kann das in all diesen Fällen auch komplett durch ein einzeiliges mw.loader.load("//de.wikipedia.org/w/index.php?title=Benutzer:Olliminatore/unsigned.js&action=raw&ctype=text/javascript"); ersetzt werden. Wichtig ist wie immer nur, dass in der Zusammenfassungszeile auf eine nachvollziehbare Begründung verwiesen wird. Und noch ein Argument gegen die Alert-Box: Angenommen, wir machen das und verändern eine Funktion, die aktuell nichts tut so, dass sie die Benutzer mit Popupfenstern zu Tode nervt, dann werden wir in einem Jahr trotzdem exakt die selbe Diskussion führen wie gerade eben, außer dass es dann um zwei oder drei Einbindungen weniger geht. --TMg 22:23, 12. Jan. 2012 (CET)
Nach einigen Wochen wären alle Benutzer, die auf irgendeine Weise noch eines dieser Skripte tatsächlich nutzen, auf TSW fluchend über den zusätzlichen Klick aufgelaufen, und dann kann gezielt getrackt werden, um wen es überhaupt noch ginge. Dagegen kann man dann in geeigneter Weise etwas machen; der Rest kann bis in alle Ewigkeit schlafen. Wenn sich innerhalb eines Jahres niemand meldet, werden die Skripte offenkundig auch nicht mehr genutzt. --PerfektesChaos 22:57, 12. Jan. 2012 (CET)
Übrigens ist dann in jedem der betroffenen Skripte auch gleichzeitig jedes Vorkommen des Arrays ta[] auszukommentieren bzw. umzuprogrammieren: rev:107329. Der Aufruf von akeytt() soll die Elemente dieses Array ta[] in Kraft setzen, und ta wird künftig auch nicht mehr vorhanden sein und einen Laufzeitfehler verursachen. Vorstehend hatte ich akeytt benannt, weil es eine charakteristischer zu identifizierende Zeichenkette ist.
Da hat 32X sich ja eine Menge vorgenommen, aber TMg hilft sicher bei der Umprogrammierung dieser 30 Skripte.
VG --PerfektesChaos 14:21, 14. Jan. 2012 (CET)
Ich hab mal damit angefangen, die Benutzer anzuschreiben, die lediglich das unsigned-Skript kopiert hatten. Es waren leider weniger, als ich zuerst dachte (nur 5, wovon 1 schon gelöscht ist). --TMg 22:44, 26. Jan. 2012 (CET)

FeaturedFeeds

Ich habe das neue System mal angetestet. Grundsätzlich funktioniert es: https://de.wikipedia.org/w/api.php?action=featuredfeed&feed=featured&feedformat=atom Der Feed wird im Browser nur auf der Hauptseite angeboten.

Folgende Seiten haben ich eingerichtet:

MediaWiki:Ffeed-featured-page
Inhalt: Wikipedia:Hauptseite/Artikel des Tages/{{LOCALDAYNAME}}/Feed
Wikipedia:Hauptseite/Artikel des Tages/Montag/Feed bis Wikipedia:Hauptseite/Artikel des Tages/Sonntag/Feed
Inhalt: Jeweils Wikipedia:Hauptseite/Artikel des Tages/Montag bis Wikipedia:Hauptseite/Artikel des Tages/Sonntag. Dies war nötig, damit im Feed nur der jeweilige Anriss ohne Dokutexte erscheint.

Angepasst können noch werden:

Aktuelle Probleme:

  • Der Feed geht immer über 10 Tage, die Woche hat aber nur 7 Tage. Lösungsmöglichkeiten:
    • $wgFeaturedFeedsDefaults durch Serveradmins auf 7 Tage anpassen lassen
    • Unterseiten mit Tagesdatum statt Wochentag anlegen

Achtung: Änderungen an den Systemtexten werden durch den Servercache erst nach 1 Stunde wirksam. — Raymond Disk. 20:41, 26. Jan. 2012 (CET)

Er rotiert also die Tage durch, daher hat der 19. Januar das gleiche wie heute (26. Januar). Das ist natürlich schlecht, aber lässt sich auch nicht umgehen. Auch wenn wir 10. Seiten anlegen würden, hätten wir nur die 7 Quellseiten. Es müsste also ein Bot die 10 Tage rotierend mit dem Teaser versorgen (jeden Tag einen alten Teaser überschreiben), damit das funktioniert. Da wäre das umstellen der Tage auf 7 wohl die einfachere und aus meiner Sicht auch die beste Möglichkeit, da es unseren Gegebenheiten besser entspricht (Schon gewusst ist auch so, nur nicht Was geschah am?, aber da sollte eine Woche auch reichen). Der Umherirrende 21:03, 26. Jan. 2012 (CET)
Wobei: Wenn die Artikel des Tages für beispielsweise 2 Tage im Vorraus eingetragen werden, dann wäre es ja auch falsch, weil die beiden Wochentage dann im Feed bereits die neuen und nicht die alten Teaser zeigen würde. Entweder müssen die Wochentage-Seiten eine kleine Historie pflegen, die dann mit Vorlagenprogrammierung zu Tage kommt, wenn die Seite mit altem Datum gerendert wird oder es wird doch ein Bot benötigt (oder Handarbeit), oder man macht es wie in en.wp, wo jeder Tag eine eigene Seite ist (und vermutlich die Diskussion auf der Diskussionsseite stattfindet). Der Umherirrende 21:10, 26. Jan. 2012 (CET)

So wie ich die Doku gelesen habe wird jeden Tag einmal die Systemnachricht zu einem Seitennamen expandiert. Ist der gültig, wird die angegebene Seite unter Special:FeedItem/featured (buggy) gepermacached: „The extension creates a permanent link for each feed entry even if the feed is loaded from a single template.“. Demnach werden wir also kaum Probleme bekommen, und der Feed den du verlinkt hast besteht ja auch schon aus über 7 verschiedenen Items. -- ✓ Bergi 21:55, 26. Jan. 2012 (CET)

Ja, die falschen könnten auch da sein, weil das alles noch frisch ist, dann müsste man nochmal in ein paar Tagen schauen. Der Umherirrende 22:03, 26. Jan. 2012 (CET)

Section Edit Link im Diff

Sagt mal, was ist eigentlich da los, dass der Section-Edit-Link in Diffs immernoch nicht wieder da ist? Kümmert sich eigentlich jemand darum? Oder wen muss man wie ansprechen? Grüße --h-stt !? 13:32, 27. Jan. 2012 (CET)

Man stochert im Trüben: Bug 33671. --Steef 389 18:19, 27. Jan. 2012 (CET)
Mist, Mist, Mist. Das ist super lästig, da ich meine Beobachtungsliste immer per Diffs durchgehe. Und wen ich dann etwas entdecke, was ich bearbeiten will, brauche ich jetzt immer mindestens zwei Klicks an völlig entgegengesetzten Enden des Bildschirms mehr. --h-stt !? 19:27, 27. Jan. 2012 (CET)
Scheint im Testwiki für das nächste Software-Update aber (wieder) zu funktionieren. Der Umherirrende 20:40, 27. Jan. 2012 (CET)

Änderung bei der Babel-Erweiterung von MediaWiki

Hallo Leute! Die Babel-Erweiterung von MediaWiki benutzte ja – falls vorhanden – die Babel-Sprachvorlagen unseres alten Systems. Das war auch sinnvoll, weil unsere Vorlagen vieles besser machen als die der MediaWiki-Erweiterung, z.B. die Kategorisierung. Neuerdings benutzt die Erweiterung jedoch ihre eigenen Bausteine und ignoriert unsere Sprachvorlagen. Warum tut sie das? Und kann man das wieder ändern? MfG Stefan Knauf 23:08, 10. Feb. 2012 (CET)

Hallo Leute! Wer sind eigentlich die Leute, die die Einstellungen der MediaWiki-Babel-Erweiterung für die deutsche Wikipedia ändern können? MfG Stefan Knauf 23:16, 18. Feb. 2012 (CET)

Das wurde aufgrund von Bug 31330 geändert. Die Einstellungen können nur Systemadmins ändern, sie brauchen dafür ein Bug und vermutlich auch eine kleine Abstimmung der Community. Geht es dir um die doppelte Kategorisierung? Der Umherirrende 23:21, 18. Feb. 2012 (CET)
Hallo Umherirrender! Ja, die doppelte Kategorisierung ist das, was mich am meisten stört. Aber auch das Vorhandensein unterschiedlicher Designs finde ich nicht optimal. Ich bin mir noch nicht sicher, ob ich unser altes Design nur aus Gewohnheit schöner finde oder ob es einfach netter aussieht. MfG Stefan Knauf 00:27, 19. Feb. 2012 (CET)
Da lässt sich wohl nicht viel machen. Entweder hat man ein einheitliches Design auf diesem Wiki oder ein einheitliches Design über alle Wikis, wenn man überall #babel verwendet hat. Ist erstmal unschön, aber da es auf zwei Wege produziert wird, vielleicht auch vertretbar. Der Umherirrende 20:29, 20. Feb. 2012 (CET)
Hallo Umherirrender! Ich sehe gerade, dass die Niederländer es geschafft haben, dass in ihrer Wikipedia auch die MediaWiki-Babel-Erweiterung auf die Doppelkategorisierung der Benutzerseiten verzichtet. Können wir das bei uns nachmachen und wenn ja, wie? MfG Stefan Knauf 01:22, 21. Feb. 2012 (CET)
Die Niederländer haben in ihrer Common.css einiges CSS stehen, womit die Boxen wohl auf die gleichen Farben gehoben werden. Außerdem wurde für die Niederländer die Variable wgBabelMainCategory nicht gesetzt, was dazu führt, das sie nicht doppelt kategorisiert werden (war wohl Bug 33042). Ich habe mal Bug 34570 eröffnet, vielleicht geht es auch umkompliziert für uns. Der Umherirrende 19:06, 21. Feb. 2012 (CET)
Ist nun umgesetzt. Bis die Kategorien sich aber "erholt"/aktualisiert haben, kann es etwas dauern. Ansonsten Nulledit auf die betroffende Seite machen, dann sollte der Kategorieeintrag auch verschwinden. Der Umherirrende 15:08, 24. Feb. 2012 (CET)
Hallo Umherirrender! Boar, Danke! Das scheint ja wirklich zu funktionieren! Aber die Sprachangabe de-0 scheint im MediaWiki-Babel-System nun keine Kategorisierung mehr zu bewirken (Beispiel).
Und das MediaWiki-Babel-System kategorisiert ja auch Diskussionsseiten. Besteht da Aussicht, dass sich das auch beheben lässt, oder sollte man da einfach den Leuten, die den Babelturm sowohl auf ihrer Benutzer- als auch auf ihrer Benutzerdiskussionsseite stehen haben, den MediaWiki-Babelturm durch den alten Babelturm ersetzen? MfG Stefan Knauf
Da scheinen wir aktuell keinen Einfluss drauf zu haben. Gleiches gilt ja auch für Unterseiten und ähnliches. Da de-0 vermutlich in die übergeordnete Kategorie kam, was ja falsch war, ist es jetzt ja "besser", wenn auch nicht ganz richtig. Leider ist mir keine Möglichkeit bekannt, hier vom Wiki aus Einfluss zu nehmen. Der Umherirrende 22:00, 24. Feb. 2012 (CET)

Extra-Editbuttons

Das Gadget Extra-Editbuttons wird mit 1.19 voraussichtlich (mal wieder) kaputt gehen, wie man auf http://de.wikipedia.beta.wmflabs.org testen kann: Dank rev:111983 und der etwas eigenwilligen Programmierung des Gadgets werden beim Aktivieren alle Schaltflächen entfernt, aber keine mehr hinzugefügt. rev:112451 ist in diesem Zusammenhang auch noch interessant, beide Änderungen sind für den Backport nach 1.19 vorgesehen. Falls sich jemand dazu berufen fühlt, das Gadget zu reparieren, dann solle er diesem Ruf möglichst bald folgen. --Schnark 10:55, 27. Feb. 2012 (CET)

Bei mir ist die gesamte alte Buttonleiste hinüber, egal ob mit oder ohne Gadget. Irgendwer musst init auf onReady ändern, hat aber das inline-Script vergessen. Sollte es mal kommen, werd ichs schon reparieren.
Derzeit funktioniert die Toolbar nur mit dem Gadget :-) [2][3] -- ✓ Bergi 17:36, 27. Feb. 2012 (CET)
Ich denke mal tstarling hat die Namensänderung ohne internen Aufruf aus guten Grund gemacht, oder nicht? Daher ist es vermutlich eine schlechte Idee, das bei uns einfach umzubiegen. Der Umherirrende 20:44, 27. Feb. 2012 (CET)
Keine Ahnung, beim Versuch das zu fixen hat jedenfalls jemand großen Mist gebaut. Bis das "bei uns" kommt ist ihnen das hoffentlich selbst aufgefallen (Bug 34662). Hab jetzt keine Lust mich durch den revisons-Dschungel zu kämpfen um den Bösewicht zu identifizieren. -- ✓ Bergi 21:30, 27. Feb. 2012 (CET)
Die Umbenennung fand mit rev:111983 statt, die hat Schnark ja verlinkt. Was da sonst noch schiefgelaufen ist, kann ich nicht sagen, dafür habe ich da nicht tief genug reingeschaut. Der Umherirrende 21:37, 27. Feb. 2012 (CET)
Bei mir (FF3.6) funktioniert jetzt die alte Editleiste sowohl mit als auch ohne Gadget, allerdings wird die benutzerdefinierte Konfiguration ignoriert. --Schnark 09:25, 28. Feb. 2012 (CET)
Ach, und übrigens: Move onReady and isReady to the local scope (introduced recently in r111983, not used or meant to be used publicly) --Schnark 09:38, 28. Feb. 2012 (CET)
Dann war mein Gedanke ja richtig, das niemand dies extra ausführen soll. Der Umherirrende 20:17, 28. Feb. 2012 (CET)
Na dann wird man die reload-Funktion wohl direkt ins Gadget kopieren müssen. Bis dahin: auf beta.wmflabs läuft 1.20alpha, auf dem offiziellen Referenzwiki test.wikipedia 1.19wmf – mit dem kaputten Zwischenstand. Ich werd die Lösung des Problems erst dann formulieren, wenn klar ist was wir hier bekommen. -- ✓ Bergi 20:55, 28. Feb. 2012 (CET)

Verschieben einer Seite

Seiten werden beim Verschieben innerhalb eines Namensraumes nicht mehr automatisch gesichtet, sofern der Verschieber kein Sicherrecht hat. Heißt das, wenn ein Sichter eine ungesichtete Seite innerhalb des ANR verschiebt, wird diese gesichtet, ohne dass der Verschieber das beabsichtigt hat? Ich hoffe, dass ich das falsch verstanden hab. --Morten Haan · Wikipedia ist für Leser da 01:07, 4. Mär. 2012 (CET)

Nein das hast du richtig verstanden. Siehe hier: [4] (XenonX3 verschob Seite Paragraf 78 nach Paragraph 78 – Das Spiel des Todes: WP:NK#Filme) (rückgängig) [automatisch gesichtet]. Aber der Fehler wurde ja schon behoben :) --chatter ಠ_ಠ 02:20, 4. Mär. 2012 (CET)

Merkwürdiger Escapefehler im RSS

Datei:Rss-escapefehler.png
Screenshot

Im RSS/Atom-Feed der Beobachtungsliste (Links bei Werkzeuge) werden die HTML-Tags der Zusammenfassungszeile geparst (dieser Diff), obwohl die Tags eigentlich korrekt escapt sind. Sowohl angemeldet als auch unangemeldet im Firefox. Weiß jemand was da kaputt sein könnte? -- chatter ಠ_ಠ 13:05, 8. Mär. 2012 (CET)

Sieht in meinem Firefox mit dem Addon "Feed Sidebar" normal aus. Hilft dir nicht weiter, weiß ich...— Raymond Disk. 14:23, 8. Mär. 2012 (CET)
Schalt das Addon mal aus und nutz den Firefox internen Reader. Opera zeigt ähnliches verhalten. Die Tags werden dort zwar nicht geparst, aber auch nicht angezeigt. Der Content-Header ist auch nicht ganz korrekt. Content-Type ist "application/xml" statt "application/rss+xml" bzw. "application/atom+xml". --chatter ಠ_ಠ 18:08, 8. Mär. 2012 (CET)
Als Quelltext bekomme ich vom Server für die entsprechende Stelle:

<entry> <id>//de.wikipedia.org/wiki/Wikipedia:Projektneuheiten</id> <title>Wikipedia:Projektneuheiten</title> <link rel="alternate" type="text/html" href="https://de.wikipedia.org/wiki/Wikipedia:Projektneuheiten"/> <updated>2012-03-08T10:03:43Z</updated> <summary type="html">/* Vorschau auf Version 1.20 */ Die E-Mail-Felder in den Benutzereinstellungen haben CSS-Klassen erhalten // Programmcode, der mittels &lt;source lang=&quot;...&quot;&gt;&lt;/source&gt; dargestellt wird, wird mit &lt;code&gt; und &lt;pre&gt; statt &lt;span&gt; und &lt;div&gt; formatiert. (Raymond)</summary> <author><name>Raymond</name></author> </entry>

Das Problem liegt also auf deiner Seite. --Steef 389 19:16, 8. Mär. 2012 (CET)
Das wundert mich ja. Bei mir ist es genau der gleiche Quelltext und trotzdem wird es vom Browser geparst. Inzwischen mit 4 Firefox getestet (1x auf Windows, 1x Neuinstallation und gerade eben auch noch mit deaktivierten Addons) und Opera (ohne Änderungen) zeigt die Tags ja gar nicht an. -- chatter ಠ_ಠ 20:30, 8. Mär. 2012 (CET)

Einrückung

Hallo,

seit wann rücken denn der Stern (*) und der Doppelpunkt (:) den Text gleichweit ein? Das ganze macht dann ja Konstruktionen wie hier überflüssig. Viele Grüße --Christian1985 (Diskussion) 15:49, 8. Mär. 2012 (CET)

Das ist offensichtlich neu. -- Chaddy · D – DÜP – 19:59, 8. Mär. 2012 (CET)
Ist ein Bugfix: Bug 12262. Der Umherirrende 17:34, 11. Mär. 2012 (CET)
In den Release Notes wurde es heute auch erst nachgetragen: rev:13572. Und ich habe die Bedeutung von rev:102026 leider auch nicht erkannt, so dass ich es nicht auf die Vorderseite eingetragen habe. — Raymond Disk. 18:13, 11. Mär. 2012 (CET)
Ist echt praktisch, dass dies nun umgesetzt wurde. Vielen Dank für die Antworten. --Christian1985 (Diskussion) 20:20, 11. Mär. 2012 (CET)

Fallback

Seit Kurzem funktioniert der Fallback von de-at, de-ch und de-formal auf de nicht mehr. Siehe dazu WP:?#Sprachprobleme oder die Editnotice auf meiner Diskussionsseite. Weiss jemand, woran das liegt? --Leyo 14:17, 20. Mär. 2012 (CET)

habe mal in „proof of pudding is in the eating“-manier die dort genannte „problemseite“ kurzzeitig gelöscht, danach war deine editnotice auch bei de-at-spracheinstellung wieder deutsch. siehe verlinkter abschnitt. gruß, —Pill (Kontakt) 14:35, 20. Mär. 2012 (CET)
Dort beantwortet. --Filzstift ✎ 15:14, 20. Mär. 2012 (CET)

Benutzerdefinierte Nachricht für Spezial:E-Mail ähnlich einer Editnotice nun möglich

Falls sich jemand dafür interessiert und/oder es auch tun möchte: Da ich für Mails an mich auf Spezial:E-Mail/Filzstift (s. ebenda) einen benutzerdefinierten Hinweis reinplatzieren wollte, habe ich kurzerhand die entsprechende MediaWiki-Nachricht angepasst (MediaWiki:Emailpagetext). Konkret: man kann ähnlich wie bei einer Editnotice auf Benutzer:xyz/E-Mail-Hinweis eine benutzerdefinierten E-Mail-Hinweis eingeben (bei mir ist es also Benutzer:Filzstift/E-Mail-Hinweis). --Filzstift ✎ 23:10, 20. Mär. 2012 (CET)

Endlich! Danke für diese längst fällige Umsetzung eines lang gewünschten Features. Ich habe mal auf FZW und A/N auf diesen Hinweis verwiesen, damit es bekannter wird. XenonX3 - (☎:✉) 00:38, 21. Mär. 2012 (CET)
Jawoll! Die größte Errungenschaft seit Erfindung der rauchlosen Bratkartoffel! --79.253.5.254 07:25, 21. Mär. 2012 (CET)

Siehe dazu auch MediaWiki Diskussion:Emailpagetext. --Leyo 10:19, 23. Mär. 2012 (CET)

Sollte es bei jmd. nicht gehen, bitte "srv" aus HTML quelltext auf Disk melden

Was bedeutet srv? Auf jeden Fall funktioniert bei mir der Link nicht. --Metalhead ✉ 14:29, 23. Mär. 2012 (CET)

das auf der seite soll jedenfalls auch keiner sein, daher die <nowiki>-kommentare drumherum: das gerrit:3322 soll einer sein. geht der auch nicht? grüße, —Pill (Kontakt) 14:31, 23. Mär. 2012 (CET)
das nowiki habe ich soeben rausgemacht --Metalhead ✉ 14:34, 23. Mär. 2012 (CET)
ich hätte jetzt getippt, dass das da absichtlich stand, damit man sieht, wie man den link setzt. —Pill (Kontakt) 15:04, 23. Mär. 2012 (CET)
Wenn du in deinem Browser per Rechtsklick "Quelltext betrachten" (oder ähnlich) sagst, bekommst du den HTML-Quelltext der Seite (Nicht Wikitext). Dort steht ganz am Ende ein Satz Served by srv190 in 0.137 secs., wo man sehen kann, von welchem Server das kommt. Da es verschiedene Server gibt, kann es sein, das die Verteilung der Änderung nicht alle erreicht, dann kann man den Serveradmins den Server sagen und die müssen gucken, was da nicht läuft. Der Umherirrende 16:19, 23. Mär. 2012 (CET)
Das nowiki war Blödsinn von mir, da war ich im falschen (Wiki)Film. Mir schwirrt gerade von Umstellung auf Git der Kopf. Sorry, falls es Verwirrung gestiftet hat.

Ich hab es mal verdeutlicht. So war es wohl gemeint gewesen. Gut’s Nächtle --PerfektesChaos 00:00, 24. Mär. 2012 (CET)

(Serverkonfiguration) Der Dateiupload ist nur noch mit gültigem Edittoken möglich.

Dadurch funktionieren der CommonsHelper und ähnliche Tools nicht mehr. Hätte man diese Konfigurationsänderung nicht vorankündigen können, so dass die Tool-Entwickler Zeit zur Anpassung gehabt hätten? --Leyo 10:17, 23. Mär. 2012 (CET)

Es war leider eine Sicherheitslücke, die geschlossen werden musste, siehe rev:114429. — Raymond Disk. 11:44, 23. Mär. 2012 (CET)
Ich war vorher sogar davon ausgegangen, dass man ohne edittoken sowieso nicht hätte hochladen können. Insofern hat es mich eigentlich verwundert, das dies bisher möglich war. Alle Dokumentationen seit MW 1.17 sagen eigentlich aus, dass man den Token braucht. Also haben die Tool-Entwickler die Doku nicht gelesen. Merlissimo 12:08, 23. Mär. 2012 (CET)
Das doofe dabei ist, dass der CommonsHelper vermeintlich "funktioniert", nur kein Ergebnis rauskommt, also: es gibt keine Fehlermeldung o.ä. Ist es möglich, sowas einzubauen bzw. auf die Variante mit dem Selbst-Upload hinzuweisen? --emha d|b 16:03, 23. Mär. 2012 (CET)
Wer ließt schon Doku? ;-) Ich denke mal der Toolentwickler hat es ausprobiert und da es funktionierte hat er sich nicht weiter darum gekümmert. Bei Benutzung der API (wie für Tools immer sinnvoll) wäre es nicht passiert, da diese schon immer ein Token verlangte. Der Umherirrende 16:50, 23. Mär. 2012 (CET)

Auch Flickr2Commons funktioniert nicht mehr, womöglich auch aufgrund dieses "Features". --AndreasPraefcke (Diskussion) 17:41, 23. Mär. 2012 (CET)

Commonshelper und Flickr2Commons sollten lt. Magnus Manske wieder funktionieren (ich habe es noch nicht ausprobiert). -- Rosenzweig δ 13:53, 25. Mär. 2012 (CEST)
Ich habe es ausprobiert und kann es leider nicht bestätigen. Weder CommonsHelper noch CH2 funktionieren bei mir. --emha d|b 11:30, 26. Mär. 2012 (CEST)
Commonshelper klappt (auch bei mir) wieder. Mit Token. --emha d|b 16:13, 30. Mär. 2012 (CEST)

Umstellung von SVN auf Git

Ich habe in Firefox drei Bookmarks:

  1. http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions
  2. http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/languages/messages/MessagesDe.php
  3. http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/languages/messages/MessagesEn.php

Da ich annehme, dass die Inhalte im SVN nicht mehr aktualisiert werden, stellt sich nun die Frage, ob es äquivalente URLs der o. a. Dateien/Verzeichnisse im Git gibt, ohne immer nur eine Revision zu verlinken. --\m/etalhead ✉ 14:39, 24. Mär. 2012 (CET)

Für 1. biete ich https://gerrit.wikimedia.org/r/#q,mediawiki/extensions+status:merged,n,z an. — Raymond Disk. 21:42, 24. Mär. 2012 (CET)
Wie soll eigentlich Otto Normalbenutzer zukünftig Extensions downloaden können? --\m/etalhead ✉ 13:17, 25. Mär. 2012 (CEST)
Kann jemand ein java-git-Framework empfehlen? Ich bin gerade mit unterschiedlichen Varianten erschlagen worden. Ich brauche es nur um die jeweils letzte Version der Sprachdateien herunterzuladen (um aus dem Quelltext die Fallback-Spracheliste zu ermitteln). Merlissimo 14:15, 25. Mär. 2012 (CEST)
meta=siteinfo enthält die Fallback-Sprachen (seit 1.19?) mit siprop=general. Der Umherirrende 16:08, 25. Mär. 2012 (CEST)
Ja seit MW 1.19 für ein Wiki. Darauf wollte ich für die Wikipedias auch umstellen. Nur hilft mir das beim den Testwikis im incubatorwiki nicht weiter, weshalb ich auch noch die andere Methode brauche. Merlissimo 16:28, 25. Mär. 2012 (CEST)
Stimmt, mit Incubator wird es schwierig, weil da mehrere Sprachen aufeinander hocken, wo vermutlich alle ein Fallback haben, weil sie klein sind und nicht so viele die Übersetzungen machen. Da fällt mir keine API-Lösung zu sein. Ein Framework zum Zugriff habe ich auch (noch) nicht. Der Umherirrende 19:39, 25. Mär. 2012 (CEST)
Prinzipiell ist der Fallbackpath sprachen- und nicht wikiabhängig. Insofern könnte von Datenbestand her jedes Wiki den Fallbackpath zu jeder Sprache liefern. Aber ich habe eben schon Robin schon belabert, den Fallbackpath über die Incubator-Extension zu bekommen (das ginge schneller als ein Featurewunsch für MW 20+). Nur hat selbst er Probleme git ordentlich an laufen zu bringen und meinte, dass deswegen in nächster Zeit nicht viele commits von ihm zu erwarten seien. Merlissimo 20:20, 25. Mär. 2012 (CEST)
Alles noch im Fluss... Es sind viele Tools noch nicht angepasst. Ich selber kämpfe noch mit einer Windows-Installation für Git und git-review, die sich vernünftig per GUI bedienen lässt.  :-( Per Shell kann ich schon committen, Freude bereitet mir das aber noch nicht. — Raymond Disk. 14:20, 25. Mär. 2012 (CEST)
It works! Ich nutze egit (Das ist auf eclipse-Basis). Der Umherirrende 20:33, 30. Mär. 2012 (CEST)
Soweit ich gehört habe wird SVN jetzt von Git aus befüttert statt andersrum, bleibt aber weiterhin aktuell. Zumindest der wmf1.19-Zweig muss aktualisiert werden, da die WMF-Hamster immer noch SVN fressen und das Translatewiki ebenfalls noch an SVN schickt.
Sowas wie viewSVN hab ich noch nicht gesehen. Was es zu geben scheint sind (herunterladbare) Snapshots von irgendwelche Commit-Bäumen oder so ähnlich. -- ✓ Bergi 20:43, 27. Mär. 2012 (CEST)
PS: Als Ersatz, nein so darf man das nicht bezeichnen, wie auch immer – versuch es mal mit
-- ✓ Bergi 00:36, 28. Mär. 2012 (CEST)

Benutzerrechteverwaltung: Link auf Meta-Logbuch

Mich hat schon länger gestört, dass unter Spezial:Benutzerrechte allfällige Entfernungen von Adminrechten nicht angezeigt werden. Daher habe ich in MediaWiki:Userrights-groups-help einen Link auf das Logbuch bei Meta hinzugefügt. Falls jemand eine bessere Idee hat (optimal wäre ein Hinweis unten beim Log), bin ich gerne bereit, meine Änderung zurückzunehmen. --Leyo 10:22, 4. Apr. 2012 (CEST)

Fehlt eigentlich nur bei mir der Zeilenumbruch vor „Sie können die Gruppenzugehörigkeit dieses Benutzers ändern:“? --Leyo 17:19, 10. Apr. 2012 (CEST)
Nein, aber keine Ahnung, warum das bei lokaler Überschreibung passiert. Der Umherirrende 20:31, 10. Apr. 2012 (CEST)

Quelltext benutzerfreundlicher machen

Ich hätte es gern, wenn der Quelltext anwenderfreundlicher gestaltet würde. Ein Text, der großzügig mit <ref>-Nachweisen versehen ist, ist gegenwärtig mühselig zu bearbeiten. Es würde mich freuen, wenn im Bearbeitungsfenster die per ref-tag eingefaßten Textsequenzen automatisch farblich abgesetzt erschienen - mein Vorschlag dunkelbraun. Ich hoffe, daß mein Gedanke, den Quelltext zu "funktionalisieren", auf Sympathie stößt. Die Umsetzung ist Sache der Systementwickler. An wen wende ich mich? Hm20 (Diskussion) 19:35, 9. Apr. 2012 (CEST)

Schon mal WikEd probiert? --Steef 389 19:45, 9. Apr. 2012 (CEST)
Danke für den Hinweis. Genau sowas hatte ich gesucht. Eine kluge Erfindung, die ich leider vorläufig nicht nutzen kann. Hm20 (Diskussion) 15:00, 10. Apr. 2012 (CEST)
Ich verweise hier mal auf die Möglichkeit, die Einzelnachweise am Ende des Artikels einzufügen. Dies macht den Quelltext um einiges lesbarer. --ucc 15:36, 10. Apr. 2012 (CEST)

Verschiebeaktion Format-Änderung in recentchanges Tabelle

Ich habe da ein größeres Problem, weil mein Bot seit ein paar Tagen einige Seitenverschiebungen aus dem BNR nicht mehr mitbekommt um diese dann bei den neuen Artikel aufzuführen.

Früher (bei 1.18) ergabt die Abfrage select REPLACE(SUBSTRING_INDEX(rc_params,"\n",1),' ','_') AS title, rc_timestamp AS mintime from dewiki_p.recentchanges where rc_log_type IN ('move') and rc_namespace=2 and rc_params NOT like '%:%' alle Seitentitel mit Verschiebungen aus dem BNR in den ANR, die keinen Doppelpunkt im Titel haben. Dies funktioniert so nun nicht mehr.

Nun steht dort was ganz anderes. Zum einen enthält rc_cur_id nicht die page_id der verschobenen Seite, sondern irgend eine andere Zahl. Zum anderen ist rc_param irgendwas im JSON-Format, was mir große Sorgen macht. Ich verstehe im Moment weder die Logik von rc_cur_id (habe ich noch nie), noch wie man das json-format mit sql verarbeiten könnte.

Was ich in meiner Tabelle brauche, ist eine Liste aller Seiten, die neu in den ANR verschoben wurden mit Verschiebedatum. Mein bisheriges Script sieht so aus (mit einer Laufzeit von 3-5 Sekunden auf dem TS): 

CREATE TEMPORARY TABLE IA_NeueArtikelActions (pid INT, pt VARCHAR(255), pns INT, predir INT, mintime DATETIME, type varchar(10), INDEX(pid), INDEX(mintime)) ENGINE=MEMORY;
#pre detect non-talk/anr to anr page moves
#all pages moved from non-anr
CREATE TEMPORARY TABLE a (title VARCHAR(255), mintime DATETIME, INDEX(title), INDEX(mintime))
 SELECT REPLACE(SUBSTRING_INDEX(rc_params,"\n",1),' ','_') AS title, rc_timestamp AS mintime
  FROM dewiki_p.recentchanges
  WHERE rc_type=3 AND rc_log_type='move' AND rc_namespace!=0 AND rc_namespace!=1;
#delete non anr target
DELETE FROM a
 WHERE SUBSTRING_INDEX(title,':',1) IN
  (SELECT REPLACE(ns_name,' ','_') FROM toolserver.namespacename WHERE dbname='dewiki_p');
#detect non-anr to anr page moves and make move date as create date
INSERT INTO IA_NeueArtikelActions (pid, mintime, type)
 SELECT page_id, mintime, 'moveto'
  FROM a INNER JOIN dewiki_p.page ON title=page_title
  WHERE page_namespace=0;

Kann mir jemand helfen? Ich benutze reine sql-Script, die ich direkt dem mysql command client übergebe.Merlissimo 13:41, 4. Mär. 2012 (CET)

Es gab ein Logbuch-Rewrite, unteranderem auch für Verschiebungsaktionen. Die Log-Params von neuen Aktionen sind jetzt ein serializiertes PHP-Array. Daher gab es ja auch die Probleme mit dem IRC-Feed, weil sich da etwas geändert hat. Der Umherirrende 13:47, 4. Mär. 2012 (CET)
Unter rc_cur_id befindet sich die Pageid der neu erstellten Weiterleitung. Das scheint mir auch richtig, weil der RC-Eintrag weiterhin unter dem alten Lemma läuft, aber durch die Verschiebung ist die vorherige Seite mit der pageid dort nicht mehr. Bei suppressredirect ist das Feld 0, weil der Eintrag unter dem alten Seitennamen läuft, aber dort keine Seite ist. Das war aber vorher auch schon so. Der Umherirrende 14:29, 4. Mär. 2012 (CET)
Auf dem TS hat das Feld rc_params leider keinen index. Regex wird deshalb schwierig, aber ich habe es selber noch nicht ausprobiert. Die logging-Table ist viel zu groß und hat ebenfalls schlechte Indexes, so dass ich diese bisher auch nicht genutzt habe.
Ich brauche einfach eine sql-Abfrage, die mir die in den ANR verschobenen Seiten in meine IA_NeueArtikelActions Tabelle einfügt und auf den TS täglich machbar ist. Seiten die später nochmal weiter verschoben werden, waren bisher schon nicht enthalten, da ich dafür keine performante Lösung gefunden hatte.
Die Leute beschweren sich derzeit auf FZW und meiner Disk wegen der fehlenden Einträge. Catscan hat diese Art der neuen Artikel immer schon ignoriert, weil es immer nur das rc_new flag ausgewertet hat. Merlissimo 17:14, 4. Mär. 2012 (CET)
Mit der logging-Tabelle hättest du ja das gleiche Probem. Die Logaktion wird unter dem alten Namen geloggt und der neue steht in den params, die auch hier ein serializiertes PHP-Array sind. Ich habe keine Ahnung, wie man das effizient machen könnte. Wenn kein Regex wird es mit wildem Substrings wohl auch nicht einfacher und geht vielleicht auch irgendwann kaputt. Der Umherirrende 19:18, 4. Mär. 2012 (CET)
...und für den fleißigen Autor heißt das auf hochdeutsch, er darf keine Artikel mehr auf einer Nutzerunterseite erstellen, jedenfalls dann nicht, wenn er möchte, dass dieser nach Verschiebung in den ANR auch in den passenden Portalen gelistet wird?
Der Nervkram ist ja momentan zudem, dass MerlBot den sogar wieder aus Portal:XY/Neue Artikel rauswirft, wenn man ihn dort manuell einträgt. Kann man, bis das technische Problem behoben ist, diese Wegputz-Botfunktion nicht vorübergehend abschalten, Merlissimo? --Wwwurm Mien Klönschnack 09:55, 5. Mär. 2012 (CET)
Nein, weil das ein ganz anderes Botscript benötigen würde. Im Moment erstelle ich die Liste und ersetzte einfach alles, was zwischen den Markern steht.
Bei deiner Version müsste ich überhaupt erst mal analysieren, was dort vorher war. Dazu müsste ich den Text, der dort vorher steht, lesen und auswerten und danach eine Entscheidungsmethode finden, welche Einträge bleiben müssten. Was ist mit umkategorisierten Seiten, wie erkenne ich diese, bleiben die? Was mit Weiterleitungen, mit gelöschten Seiten? Wie Fehlertolerant müsste der Bot gegenüber anderen manuell benutzen Formaten sein? Und das ganze dann für 400 Portale pro Tag.
Es hat lange gedauert bis ich den Bot auf diese Leitung bringen konnte. Ich sehe nicht, wie so was praktikabel umsetzbar wäre.
Die Liste wird jeden Tag komplett neu erstellt. Dass es dann im Diff so aussieht, als hätte er nur ein paar wenige Einträge ergänzt/geändert liegt dann an MediaWiki.Merlissimo 16:52, 5. Mär. 2012 (CET)
Die mit einfachsten Mitteln herstellbare Problemlösung ist mir natürlich recht. Ich hab' allerdings vermutlich immer noch den ca. 15 Jahre alten Slogan im Ohr, dass die IT uns allen das Leben wunderbarst erleichtern werde – sowas wie „Schalter ein, Schalter aus“ ... ;-) Gruß von --Wwwurm Mien Klönschnack 17:31, 5. Mär. 2012 (CET)
Es mir eigentlich relativ egal, wie schwer oder leicht das hinzubekommen ist. Aber solange der Bot neu in den Artikelnamensraum verschobene Artikel nicht als neue Artikel erkennt, sollte er in den Portalen nur hinzufügen und nicht löschen und wenn er das nicht kann halt solange abgeschaltet werden, bis er das kann. Der Bot soll uns helfen und nicht ärgern. --Mogelzahn (Diskussion) 17:40, 5. Mär. 2012 (CET)
Ich bin eigentlich auch immer der Meinung, der die IT uns helfen soll. Im Moment ist eher die Frage, was das kleinere Übel ist: Den Bot ganz abschalten, oder ein paar Artikel nicht nicht auflisten.
Was im Moment noch funktioniert ist die Erkennung von die ausgebauten Ex-Weiterleitungen und importierten Artikeln. Catscan erkennt nur die Artikel mit Neu-Flag, die vorher nur gut 60% aller vom Bot gemeldeten neuen Artikel ausgemacht haben.
Im Moment denke ich, dass es besser ist den Bot laufen zu lassen, denn jedes Portal kann selbst entscheiden, ob es den Bot deaktivieren möchte. Bei einer reinen manuellen Aktualisierung würden trotz Catscan-Benutzung deutlich mehr Artikel gar nicht erfasst werden, als die relativ wenigen BNR/ANR->ANR-Verschiebungen.
Am 29. Februar gab es durch die beiden Verschiebeerkennung 1207 bei mir intern als Neue-Artikel-Aktionen bezeichnete Treffer. Insgesamt gab es über 48000 Neue-Artikel-Aktionen, wodurch dann 17043 neue Artikel für die letzten 30 Tage erfasst wurden. Ein Artikel kann über mehrere Aktionen (Seitenerstellung, BNR->ANR Verschiebungen, Import, starke Seitenvergrößerung(=Ex-WL/Stub)) erfasst werden, wobei dann das Datum der jüngsten Aktion als Erstellungdatum genommen wird.
Ich habe mal versucht letzte Nacht eine Regex laufen zu lassen. Mit einer Laufzeit von über 7 Stunden bei relativ geringer DB-Auslastung nicht machbar. Da ist die Liste schon veraltet bevor sie erstellt wird - selbst wenn daphne schneller als cassia sein sollte. Wobei die Ergenisse noch nicht mal wirklich zu gebrauchen sind, weil ich escapte " noch nicht beachtet habe. Merlissimo 20:14, 5. Mär. 2012 (CET)
Da gibt es die Funktion erst seit kurzem und auch nur beim Bot und dann ist man schon so verwöhnt, das wenn er es aufgrund eines Software-Updates nicht mehr kann, sofort verzweifelt ist? Keiner zwinkt dich, den Bot oder das Ergebnis des Bots zu nutzen. Denke nur mal an die Zeit vor dem Bot, dort sind die Artikel garnicht aufgefallen, war es da tragisch? Der Umherirrende 20:35, 5. Mär. 2012 (CET)
Ganz ehrlich: Mir war die Vorbot-Zeit lieber. Und: Natürlich zwingt mich jemand, die Bot-Ergebnisse zu nutzen, weil die Mehrheit in den jeweiligen von mir genutzten Portalen den Bot will. --Mogelzahn (Diskussion) 15:13, 6. Mär. 2012 (CET)
Wenn eine doppelte Liste nicht in Frage kommt, ist es natürlich schwieriger, da stimme ich dir zu, aber der Bot macht jetzt immer noch mehr, als in der Vorzeit (also was mit Catscan möglich war), außer die Vorzeit bestand aus einer selbstgepflegten Liste, wo jeder nach Artikelerstellung/-verschiebung diesen eingetragen hat, das lässt sich nicht abbilden. Der Umherirrende 19:08, 6. Mär. 2012 (CET)
@Merlissimo: Die Zeichenkette am Anfang ist doch immer gleich? a:2:{s:9:"4::target"; (oder so). Diesen Teil könnte man dann schonmal wegschnippeln. Danach folgt die Länge des Wortes und das Wort, wobei Quotes nicht escaped werden im serialisierten PHP-Array. Soll heißen, das bei der Angabe s:9:"text"text" der Text ab dem ersten Quote 9 Zeichen lang ist (also text"text, danach sollte dann das abschließende Quote kommen, wird aber wohl nicht geprüft. Ist auch gemurkste, aber für den Moment hilft das vielleicht. Der Umherirrende 20:35, 5. Mär. 2012 (CET)
Ich hatte per Regex einfach versucht den String zwischen dem zweiten und dritten Anführungszeichen zu machen. Zeichen zählen geht auch nicht, weil die TS-Datenbank in latin1 ist, aber darin UTF-8-Zeichen gespeichert werden, so dass die Bytezahl nicht passt. Also muss ich irgendwie feste Begrenzer nutzen. Da muss ich halt ein wenig mit verschatelten substr/indeoxof Funktionen was basteln. Werde ich schon irgendwie hinbekommen - dauert halt. Leider habe ich keine wirkliche Definition gefunden, noch sind nach vier Tagen genug Fälle in der DB, so dass ich sicher sein kann alle Ausnahmen erfasst zu haben. Es gibt gerade mal 1000 Verschiebungen mit dem neuen Format in allen Namensräumen. Derzeit beginnen alle Eintrage mit "a:2:{s:9:\"4::target\";s:" und enden bisher aber auch mit "\";s:10:\"5::noredir\";s:1:\"1\";}" oder "\";s:10:\"5::noredir\";s:1:\"0\";}" (nur die letzte Zahl 0/1 ist unterschiedlich. Das wäre super, aber kann man sich wirklich darauf verlassen, dass es immer genau zwei Einträge gibt, target als erstes dort steht und als zweites noredir, das einen binary value hat? Merlissimo 22:56, 5. Mär. 2012 (CET)
5::noredir entspricht dem Wert, der vorher in der zweiten Zeile der Logparams stand (also nach dem \n) und sagt, ob es suppressedredirect war oder nicht. Für Verschiebungen kann man dies annehmen, würde ich sagen. Das ihr die Zeichensätze nicht richtig habt, erklärt aber einige "kaputt" wirkende Auswertungen, die ich mal gesehen habe. Der Umherirrende 19:08, 6. Mär. 2012 (CET)

Diese Diskussion ist mittlerweile eine Woche her. Hat sich inzwischen etwas zur Lösung dieses Problems getan?
Es besteht ja, wie ich bei einem gestern von mir neu angelegte Artikel sehe, nach wie vor. --Global Fish (Diskussion) 13:20, 13. Mär. 2012 (CET)

Nachtrag: wenn ich die von mir am stärksten frequentierten Portale (Bahn und Mecklenburg-Vorpommern) mir ansehe, so betrifft das nicht nur Verschiebungen aus dem BNR, sondern auch Artikel, die "einfach nur so" innerhalb des ANR verschoben wurden. Eine Systematik sehe ich dabei nicht; andere Artikel bleiben auch nach Verschiebung gelistet. Anscheinend sind die vom Bot nicht mehr erkannten verschobenen Artikel allesamt zweimal verschoben worden; in zwei Fällen hin- und her (die Zwischenversionen des Namens verblieben als Weiterleitung), einmal zweimal verschieden (die alten Artikelnamen existieren nicht dort mehr).

Abgesehen von "meinem" Artikel (Bahnhof Berlin-Blankenburg, aus BNR) kann ich unten nur die aufzählen, die einmal vom Bot gelistet wurden, aber später nicht mehr. Abgesehen von den gelöschten, URV, falsch kategorisierten Fällen etc. macht das etwa 10% der neuen Artikel aus. Plus Dunkelziffer, also im BNR erstellte Artikel, deren Fehlen auf den Neue-Artikel-Seiten den Autoren nicht auffiel. Deren Zahl kenne ich natürlich nicht. Das sind m.E. keine Peanuts mehr, da sehe ich dringenden Handlungsbedarf.

Hier die Fälle vom März aus Bahn:

Aus Mecklenburg-Vorpommern betrifft das

Zumindest sollte als nullter Schritt bitte der Warnhinweis in der Bot-Meldung dick und fett angezeigt werden, dass er jedem auffällt. Ansonsten bitte möglichst zeitnah, wie schon einige andere hier sagten, - auch wenn das eigentliche Problem auf die Schnelle nicht zu lösen ist, den Bot wenigstens so programmieren, dass er nichts aus den Listen löscht. --Global Fish (Diskussion) 14:30, 13. Mär. 2012 (CET)

Bitte lese meine Beiträge in diesem Abschnitt. Deine ganzen Anmerkungen findest du dort beantwortet: Es betrifft auch ANR/ANR-Verschiebungen betrifft. Mehrfache ANR-Verschiebungen sind waren immer schon rausgeflogen. Zudem kannst du nachlesen, dass mein Bot nicht einzelne aktiv löscht, sondern einfach nur alles Überschreibt.
Ich habe oben die Gesamtstatistiken bereits präsentiert. Daraus geht hervor, das es im Februar deutlich weniger als 10% waren. Je nach Portalgepflogenheit können einzelne Portale natürlich stärker betroffen sein.
Ab Donnerstagabend bin ich für eine Woche auf Geschäftsreise im Ausland. Es wird also noch etwas dauern, bis ich Zeit finde. Oben gab es bereits von Mogelzahn den Wunsch, den Bot solange abzustellen. Meine Antwort ist dort nachzulesen. Wenn sich die Stimmen dafür aber mehren, kann ich das natürlich machen. Für's Weiterlaufen hat sich bisher nur der Umherirrende ausgesprochen. Da er aber kein Portalmitarbeiter ist fehlt ihm die subjektive Sichtweise ;-).
@Global Fish: Wenn du schon Statistiken aufstellst, schau doch mal, wie der Vergleich mit Catscan aussieht. Das würde mich auch persönlich interessieren, da ich dies zuletzt vor zwei Jahren gemacht habe. Merlissimo 02:48, 14. Mär. 2012 (CET)
Nun, mein Hinweis, dass die Anzeige auf Fehlfunktionen im Bot auch so fett dargestellt werden könnte, dass es jedem, der die Seite aufruft, sofort auffällt, war neu. Das halte ich auch für wichtig.
Es sind ansonsten funktional für den Nutzer (für die andere Seite kann ich nicht sprechen) zwei verschiedene Sachen. Die eine ist, dass nicht alle Seiten gelistet werden. Da wurde in der Diskussion angeführt, dass der Bot selbst jetzt noch besser funktioniert (im Sinne, dass er mehr Artikel erkennt), als alle anderen früheren Lösungen. Das ist sicherlich richtig. Auf der anderen Seite steht aber, dass in der Zeiten vor dem Bot jeder immer die Möglichkeit hatte, Artikel händisch nachzutragen. Und genau das geht jetzt nicht mehr, bzw. man muss das jeden Tag von neuem tun, was wohl kaum eine praktikable Lösung ist.
Das wiederholte Löschen von Inhalten von den Wikipedia-Seiten, auf die sie gehören, ist ganz klar Vandalismus. Und das ist niemals zu akzeptieren, auch wenn bei der fraglichen Aktion auch anderen Inhalte wieder eingefügt werden.
Das geht natürlich nicht gegen Dich; Du kannst hier überhaupt nichts dafür, wenn die Hintergrundsoftware sich ändert. Du engagierst Dich hier, musst diversen Nutzern Rede und Antwort stehen, und wie ich lese, ist gerade jetzt Deine Zeit besonders knapp.
Möglicherweise wäre es dann auch in Deinem Interesse, wenn ich auf WP:VM ginge, weil von dort vielleicht mehr Manpower zu erwarten ist, als Du sie im Moment aufbringen kannst?
Du schreibst, dass Du den Bot nicht dahingehend ändern kannst, dass er nicht alles überschreibt. Stimmt, das stand schon oben. Ok, dann mögen manche Dinge nicht so einfach funktionieren, wie man als Außenstehender es sich auf die Schnelle denkt. Dennoch muss eine akzeptabele Lösung gefunden werden. Den Bot, so wie er jetzt ist, einfach weiterlaufen zu lassen, halte ich ausdrücklich nicht für eine solche.
Ginge es vielleicht, dass man die nicht gelisteten Seiten + Erstellungsdatum auf einer separaten Seite einträgt (wenn es einen deutlichen Hinweis darauf auf den "Neue Artikel"-Seiten gäbe, könnten das die Nutzer selbst) und nach dem merlbot einen zweiten Bot laufen lässt, der diese Seite auswertet und auf den Neue-Artikel-Seiten ergänzt? --Global Fish (Diskussion) 09:44, 14. Mär. 2012 (CET)
Hab mal Catscan (die alte Version) über die Kategorie:Schienenverkehr über die letzten 336 Stunden laufen lassen.
Der Toolserver hat dabei den Scan bei einer Suchtiefe von 4 abgebrochen (ich hatte 7 eingestellt), d.h., dass alle Artikel etwa zu Bahnstrecken in Deutschland nicht gefunden werden.
Generell: alle Artikel, die bei Catscan gefunden werden, wurden auch von Merlbot gefunden. Ausgenommen sind natürlich Kategorien und Weiterleitungen. Umgekehrt findet Catscan im wesentlichen auch das, was Merlbot findet.
Eine einzige ernstere Auffälligkeit: Catscan findet die Weiterleitung von SŽD-Baureihe_Б. Diese WL zeigt auf Russische Baureihe Б und wurde am 4. März angelegt und der Artikel dabei deutlich erweitert. Russische Baureihe Б wiederum wurde am 28. Februar angelegt und nur einmal verschoben, wird aber von Merlbot nicht gefunden.
Kleinkram andersherum: Merlbot findet U-Bahnlinie 53 (Amsterdam) und U-Bahnlinie 54 (Amsterdam), Catscan von Kategorie:Schienenverkehr nicht, was wohl daran liegt, dass sie (im Gegensatz zur Linie 52) nur unter Spurweite 1435 mm, nicht aber als U-Bahn-Strecke kategorisiert waren.
Bahnhöfe und Bahnstrecken habe ich mit Catscan nochmal separat durchsucht. Kein Unterschied zwischen Merlbot und Catscan (bis auf WL und Kats); die beiden im BNR erstellten und händisch in die Neue-Artikel-Liste eingetragenen Artikel Bahnhof Alexisbad und Bahnhof Berlin-Blankenburg findet auch Catscan nicht. --Global Fish (Diskussion) 12:33, 14. Mär. 2012 (CET)
Eine TS-Seite, auf der man Artikel eintragen kann, wäre eine Möglichkeit. Muss ich aber auch erstmal schreiben. Bei der Machbarkeit von Erweiterungen beim Bot muss man eins bedenken: Es sind etwa 550 Seiten, auf deinen mein Bot jeden Tag die neuen Artikel aktualisieren muss (wobei der Nutzen oft fraglich ist, wenn die Pageviews für einen ganzen Monat im einstelligen Bereich liegen). Merlissimo 14:41, 14. Mär. 2012 (CET)

NeueArtikel-Bot auf Wunsch nun inaktiv

Inzwischen gibt es in der obigen Diskussion schon zwei Stimmen, die für die Abschaltung des Bots sind. Da sich noch kein Portalmitarbeiter für den Weiterbetrieb ausgesprochen hat, werde ich als Botbetreiber dem damit nun eindeutigen Wunsch folge leisten. Der Bug, der durch die neue MediaWiki Version 1.19 entstanden ist betrifft die Erkennung von Verschiebungen vom BNR oder innerhalb des ANR. Ich hoffe, dass ich dies bis Ende des Monat wieder behoben habe. Im Februar 2012 wurden über diese Methode maximal 1207 der 17043 neuen Artikel erkannt. Weitere Erklärungen oben. Falls ihr hier kommentiert, gebt bitte ein Votum ab, wie ihr das seht, damit ich mir leicht einen Überblick machen kann. Merlissimo 14:41, 14. Mär. 2012 (CET)

Möglicherweise hat noch kein Portalbetreiber überhaupt von dem Problem gehört. Ich zumindest kann für die Portale Portal:Heilbronn, Portal:Odenwald und Portal:Postgeschichte (bei den beiden erstgenannten war der Bot aktiv, bei letzterem war der Bot in Planung) sprechen, und auf allen diesen Portalen spielt der MerlBot eine wichtige Rolle. Ich habe vorher die neuen Artikel des Portal:HN von Hand gesucht und eingetragen, und das war mühsam und unvollständig. Der Bot-Lösung war in dieser Hinsicht eine Erlösung. Ich selbst würde keine neuen Artikel mehr manuell suchen wollen, vermutlich haben auch die restlichen engagierten Autoren besseres zu tun. Ohne die Anzeige der neuen Artikel verlieren die von mir hier genannten Portale viel von ihrem Reiz als Anlaufstelle und Arbeitswerkzeug für Autoren. Gibt es wirklich keinen Weg zum Weiterbetrieb des Bots für neue Artikel aus Kategoriescan? Der Bot ist wirklich wichtig! (Zugriffszahlen lt. stats.grok.se für Portal Heilbronn: ca. 700 Views per Monat, Portal Odenwald ca. 500, Portal Postgeschichte ebenfalls ca. 500, also weit entfernt vom oben befürchteten einstelligen Bereich.) GRüße -- · peter schmelzle · User de schmelzle.jpg · d · @ · 15:06, 14. Mär. 2012 (CET)
Für Abschaltung:
  • Global Fish
  • Mogelzahn
JFTR, ich habe nicht gegen den Bot, ich schätze ihn sehr und finde ihn sehr wichtig. Aber wenn er Artikel selektiert (betrifft ja tendenziell gerade die aufwändigeren Artikel, die man eher im BNR bastelt, als Stubs) ohne dass es eine ernstzunehmende Chance auf manuelle Korrektur gibt (jeden Tag Edit-Wars mit dem Bot zu führen wäre ja wohl nicht der Sinn der Sache) geht m.E. gar nicht. --Global Fish (Diskussion) 16:43, 14. Mär. 2012 (CET)
Ich habe auch nichts gegen den Bot, aber er sollte halt nur zusätzlich Artikel in die Liste einpflegen, ohne die per Hand eingepflegten wieder zu löschen. --Mogelzahn (Diskussion) 22:11, 14. Mär. 2012 (CET)
Gegen Abschaltung:
Nein, man kann die Artikel eben nicht in die echte Liste kopieren (bzw. das ist sinnlos), weil sie beim nächsten Botlauf wieder rausfliegen. Genau das ist ja das Problem. --Global Fish (Diskussion) 16:11, 14. Mär. 2012 (CET)
Lies und versteh „separate Botliste“ und denke dir eine manuell gepflegte „echte Liste“, in die die Bot-Funde manuell eingetragen werden, dann passts schon. -- · peter schmelzle · User de schmelzle.jpg · d · @ · 16:14, 14. Mär. 2012 (CET)
Stimmt, so herum wäre es auch eine Variante. Möglicherweise sogar die einfachste. --Global Fish (Diskussion) 16:39, 14. Mär. 2012 (CET)
Aber das würde ja auch tägliche manuelle Arbeit bedeuten, und das auch, wenn das Portal gar nicht direkt betroffen ist. Da scheint mir meine obige Idee mit einer manuell ergänzten Liste der nicht gelisteten Artikel und Ergänzung der Neuen Artikel-Seite per separatem Bot einfacher zu sein. --Global Fish (Diskussion) 16:51, 14. Mär. 2012 (CET)
  • NeverDoING (Diskussion) 15:34, 14. Mär. 2012 (CET) lieber weniger neue Artikel in der Liste als gar keine Liste--NeverDoING (Diskussion) 15:34, 14. Mär. 2012 (CET)
  • Stört auch das Vorlagenprojekt, nicht wahr? Ansonsten Portal:Bahn -- ✓ Bergi 15:39, 14. Mär. 2012 (CET)
  • -- Rosenzweig δ 15:50, 14. Mär. 2012 (CET) (P:HN)
  • --Silvicola Diskussion Silvicola 15:56, 14. Mär. 2012 (CET)
  • Im Badminton funktioniert er weiterhin einwandfrei. Florentyna (Diskussion) 16:04, 14. Mär. 2012 (CET)
  • --Daniel749 •Diskussion•ST•WPST 16:06, 14. Mär. 2012 (CET) (Portal:Straßen)
  • --emha d|b 16:40, 14. Mär. 2012 (CET)
  • liesel Schreibsklave® 16:44, 14. Mär. 2012 (CET)
  • weiter machen, auch wenn es fehler hat - die Listen sind enorm wichtig und weine sehr große Hilfe, ich arbeite täglich damit, -jkb- (Diskussion) 16:55, 14. Mär. 2012 (CET)
  • --Reinhardhauke (Diskussion) 17:02, 14. Mär. 2012 (CET)
  • --Jo (Diskussion) 17:11, 14. Mär. 2012 (CET). Lieber weniger als gar keine
  • --GDK Δ 17:16, 14. Mär. 2012 (CET) Die Liste ist extrem wichtig, selbst wenn sie nicht vollständig ist
  • --Anka ☺☻Wau! 18:12, 14. Mär. 2012 (CET) Was soll das überhaupt? Der Bot kommt doch nur "auf Bestellung". Wer ihn nicht will, soll ihn nicht bestellen. Fertig.
  • --Hic et nunc disk WP:RM 18:28, 14. Mär. 2012 (CET) Bitte nicht abklemmen!
  • BITTE nicht abklemmen, ich habe nicht die Zeit, wie früher für das Portal:Odenwald wieder händisch neue Artikel zu suchen, was war, nee IST das für eine Erleichterung. Danke fürs Laufenlassen. MfG --commander-pirx (Diskussion) 18:31, 14. Mär. 2012 (CET)
  • --Orci Disk 19:37, 14. Mär. 2012 (CET) Wer die Automatik nicht möchte, kann die Variante von Portal:Chemie/Neue Artikel nehmen: per Hand gepflegte Liste, darunter die automatische aus der man per Hand die relevanten Artikel überträgt. Wenn der Bot zu viele unsinnige Artikel einträgt, sollte man besser mal das jeweilige Kategoriesystem überprüfen, als den Bot abschaffen zu wollen.
  • --Cvf-psDisk+/− 20:22, 14. Mär. 2012 (CET) es gibt keinen echten Grund für die Abschaltung, wer den Bot nicht will, darf gerne weiter von Hand eintragen.
  • --Quarz (Diskussion) 20:53, 14. Mär. 2012 (CET) Für das Portal:Bremen: Bitte weiter laufen lassen!
  • --Voyager (Diskussion) 21:07, 14. Mär. 2012 (CET) Unverzichtbares Hilfsmittel für die Portale Kanada, Schweiz, Wintersport und Rugby.
  • -- Niteshift (Diskussion) 23:25, 14. Mär. 2012 (CET). Bitte weitermachen. Zur Not können in den Portalen bis zu einer Problemlösung ja parallel manuelle Listen geführt bzw. die InAction-Vorlage deaktiviert werden.
  • Uwe G. ¿⇔? RM 07:19, 15. Mär. 2012 (CET) Hat der Redaktion Medizin einen Haufen Arbeit erpsart, wer ihn nicht will, kann ihn im Portal abschalten.
  • --Gunnar1m (Diskussion) 11:41, 15. Mär. 2012 (CET) Ich möchte die Arbeit des Bots nicht missen, allerdings nervt das schon, wenn eigenhändig nachgetragene Artikel wieder herausgelöscht werden. Hier ist eine Lösung zu finden – bis er wieder richtig funktioniert!
Siehe unten: Manuelle Ergänzungen außerhalb des mit <!--MB-NeueArtikel--> beginnenden und beendeten Bereichs einfügen. Alles, was dazwischen steht, ist dem Bot seins. VG --PerfektesChaos 13:39, 15. Mär. 2012 (CET)
Nein, es sollte schon eine Möglichkeit geben, die neuen Artikel händisch an die datumsmäßig richtige Stelle dauerhaft einzusetzen. Außerhalb der Liste ist es unsinnig. Der Bot. sollte eben nicht einfach täglich eine neue Liste generieren, sondern nur die neu erstellten Artikel unter dem jeweiligen Datum anfügen, ohne die anderen herauszulöschen. --Mogelzahn (Diskussion) 19:11, 15. Mär. 2012 (CET)
Woher soll der Bot wissen, ob das was du dort händisch eingepflegt hast, wirklich der Link zu einem neuen Artikel ist? Und was ist mit Artikel die fälschlicherweise in der Liste sind und nicht händisch entfernt werden? Was du verlangst steht in keinem Verhältnis von Aufwand und Nutzen. Ich empfehle dir deshalb den Bot abzuschalten und nur noch auf irgendeiner temporären Seite zu betreiben und die neuen Artikel händisch zu übertragen. liesel Schreibsklave® 19:26, 15. Mär. 2012 (CET)
So machen wir das im Hamburg-Portal ja auch. Aber ich verstehe nicht, warum der Bot jedesmal eine neue Liste erstellen muss, anstatt nur die neu erkannten Artikel der Liste hinzuzufügen. --Mogelzahn (Diskussion) 16:30, 16. Mär. 2012 (CET)
Weil es technisch wesentlich einfacher ist, alle Kandidaten, die eingefügt werden können zu ermitteln und den kompletten Bereich damit zu ersten. Damit muss man nicht jeden einzelnen einzufügenden Eintrag prüfen, ob er nun auch wirklich eingefügt werden soll. --Flominator 18:26, 16. Mär. 2012 (CET)

Ich habe hier zwar keine Aktien, aber es lassen sich vermutlich fortgesetzte Bot-Aktion und die von GlobalFish gewünschten manuellen Ergänzungen miteinander verbinden.

GlobalFish geht es wohl um Portal:Berlin/neue Artikel. Diese und mutmaßlich die anderen Seiten sind wie folgt aufgebaut:

  1. <noinclude>Manuelle Information</noinclude>
  2. <includeonly>MerlBot-Eintrag</includeonly>
  3. <includeonly>MerlBot-Eintrag</includeonly>
  4. <includeonly>MerlBot-Eintrag</includeonly>

Vermutlich ließe sich folgende Struktur realisieren:

  1. <noinclude>Manuelle Information></noinclude>
  2. <includeonly>MerlBot-Eintrag</includeonly>
  3. <includeonly bot="none">Manuelle Ergänzung</includeonly nobot>
  4. <includeonly>MerlBot-Eintrag</includeonly>

Mit etwas Glück lässt der Bot den maskierten Eintrag stehen, wobei ich die Reihenfolge des Datums nicht garantieren kann.

  • Ansonsten müsste es gehen, den Eintrag <includeonly bot="none"> noch vor <noinclude> zu stellen; spätestens da wird es vor dem Bot sicher sein.
  • Auf jeden Fall lassen sich manuelle Ergänzungen im <noinclude>...</noinclude> unterbringen, werden dann allerdings nicht in die Portalseite eingebunden.

Die Einbindung in die Portalseite wird von den syntaktisch ungewöhnlichen <includeonly> nicht gestört, aber der Bot sollte sie nicht finden. --PerfektesChaos 17:46, 14. Mär. 2012 (CET)

@PerfektesChaos Der Bot ersetzt einfach alles zwischen den beiden Marker-Kommentaren. Dein Bot=none habe ich gerade nicht verstanden.
Ein Beispiel für eine manuelle Liste, die mit Hinweisen von der Botliste erstellt wird findest sich unter Portal:Chemie/Neue_Artikel.
Das Votum oben hat sich nun wieder in Gegenteil gedreht. Solange es eine Mehrheit gegen die Abschaltung gibt, lasse ich den Bot nun also trotz Mangel weiterlaufen. Das Bahnportal kann den Botbaustein temporär entfernen. Merlissimo 18:24, 14. Mär. 2012 (CET)
@PerfektesChaos, Portal:Berlin/neue Artikel ist doch der wenigen, die händisch erstellt werden (ich würd mir diese Arbeit nie machen wollen, insofern schätze ich den Bot durchaus sehr).
Ich habe auch nicht gefordert, den Bot einzustellen. Wir möchten ja alle, dass auch die aus dem BNR verschobene Artikel direkt vom Bot erfasst werden. Aber wenn dieses Problem nicht so bald gelöst werden kann, wäre es schön, zeitnah (was nicht heute oder morgen bedeuten muss, aber auch nicht erst in ein paar Wochen) eine andere Möglichkeit zu haben, dass diese Artikel trotzdem auf den "Neue Artikel"-Seiten erscheinen, ohne, dass sie von Tag zu Tag neu eingetippt werden müssen. Eine einmalige manuelle Aktion pro Artikel fände ich vertretbar, aber nicht täglich. --Global Fish (Diskussion) 18:43, 14. Mär. 2012 (CET)
Aha, also zwischen <!-- Icons: und <!--<small>15.3.</small>-->
Dann ginge das ja noch einfacher: Manuelle Ergänzungen außerhalb dieses Bereichs einfügen. Das löst das Problem von GlobalFish. Notfalls nach zwei Tagen wiederkommen und noch hübscher in das richtige Datum einpflegen; ansonsten den manuellen neuen Artikel zwei Tage rückdatieren.
Mir war nicht so ganz klar, wer welche includeonly noch löscht (insbesondere die veralteten), ob dein Bot ggf. alle includeonly von der Seite holt und sie dann alle neu geschrieben werden. So hörte sich das ganz weit oben an.
Schönen Abend --PerfektesChaos 18:45, 14. Mär. 2012 (CET)
Mit noinclude/includeonly/onlyinclude hat der Bot nichts zu tun. Das ist Sache des Seitengestalters, die die Botvorlage sinnvollerweise oft in noinclude und die Ausgabe in einen inlcude-teil setzen. Den Bot (gilt analog für alle InAction-Scripte) interessiert sich wirklich nur für den Bereich zwischen den Kommentarmarkierungen. Für Profis: Regex \Q<!--MB-NeueArtikel-->\E(.*?)\Q<!--MB-NeueArtikel-->\E global, dotall (und non greedy). Merlissimo 21:28, 14. Mär. 2012 (CET)
Ich hatte von GlobalFish zunächst die Berlin-Seite statt Portal:Bahn/Mitmachen/Neue Artikel in die Finger bekommen; deshalb meine Verwirrung betreffend des Formats.
Genau das hatte ich gemeint. Jetzt noch eine Kommentarzeile spendiert, dann passiert das auch nicht mehr.
Besser ist es einstweilen nicht zu machen; schönen Abend --PerfektesChaos 22:53, 14. Mär. 2012 (CET)

Hier die Bitte an alle, die ihre Artikel lieber händisch pflegen: Löscht von der Seite, auf der die neuen Artikel gesammelt werden, den Eintrag {{Benutzer:MerlBot/InAction|NeueArtikel|…}}, dann habt Ihr Ruhe vor dem Bot, der – wie Ihr es zu sehen scheint – Eure Arbeit zunichte macht. Er lässt Euch dann völlig in Ruhe und schreibt gar nichts mehr.

Und nochmals die Bitte an Merlissimo: Bitte lass Deinen Bot wieder laufen. Es kann nicht sein, dass zwei Nutzer, die den Bot nicht wollen, dafür sorgen, dass ein ganzes Projekt seine Vorteile nicht mehr nutzen kann. Man kann den abschalten, er arbeitet niemals gegen den Willen der Benutzer. Das Ganze erinnert an moderne Maschinenstürmerei. Anka ☺☻Wau! 09:58, 18. Mär. 2012 (CET)

+1 zu Anka. --SteKrueBe Office 11:59, 18. Mär. 2012 (CET)
+1 er fehlt mir! --Kpisimon (Diskussion) 14:14, 18. Mär. 2012 (CET)
+1 -- Biberbaer (Diskussion) 14:59, 18. Mär. 2012 (CET)
+1 Schade, wenn Merlbot nicht alle neuen Artikel findet, aber schlimm, wen er inaktiv ist. Auf de Portal:Radsport wir er schmerzhaft vermisst. Wie soll man denn neue Artikel verbessern, wenn man nicht weiß, dass es sie gibt. Besser Merlbot zeigt mir, was er findet als garnix.--RikVII Scio me nihil scire 15:40, 18. Mär. 2012 (CET)
+1--wdwd (Diskussion) 19:02, 18. Mär. 2012 (CET)
+1 --olei (Diskussion) 00:16, 24. Mär. 2012 (CET)
<quetsch> Ich trags jetzt halt vorläufig wieder händisch ein, der Bot wirds schon weglöschen wenn alles wieder funktioniert. Übrigens, CatScan verwendet Klartext und kann nicht nur von Bots ausgelesen werden! Wenn nun also aus vorrübergehender Nützlichkeit, Bequemlichkeit oder wwasauchimmer, sich bei einer Pannensituation Hilflosigkeit und totale Botabhängigkeit herauskristallisiert, wäre das mal ein Anlass über die eigene Technikgläubigkeit, Medienkompetenz usw. nachzudenken und/oder sich um den passenden Link für die Handarbeit zu kümmern. Dem Radsportportal sei der DIY-Link spendiert [5], bei weiterem Bedarf einfach an die eigenen Bedürfnisse anpassen. --Vux (Diskussion) 01:16, 19. Mär. 2012 (CET)
Nachdem sich die meisten hier schnell für ein Weiterlaufen ausgesprochen hatten, war der Bot nie wirklich inaktiv. Aktuell laufen vieler meiner Botscripte nur nicht, weil die S5-Datenbank auf dem Toolserver im readonly-Modus läuft. Darauf habe ich keinen Einfluss. Ich bin aktuell auch nicht drüber informiert, warum dies so ist. Merlissimo 20:18, 18. Mär. 2012 (CET)
  • Hoffentlich geht er bald wieder! (Bitte Bot wieder aktivieren) --Coffins (Diskussion) 11:20, 19. Mär. 2012 (CET)
Mal ein kleiner Status-Update: Es ist leider recht schwierig das performant gelöst zu bekommen. Ich bin aber auf einem gutem Wege. Mit Terminzusage bin ich aber lieber etwas vorsichtig. Aber ich kann die Statistik mal genauer fassen, wieviel nicht erfasst wurde:
Im Marz 2012 hat mein Bot 14133 neue Artikel gemeldet. Die neue Algorithmus zur Erkennung der ANR/BNR->ANR Verschiebungen erfasst 905 Artikel, jedoch sind nur 622 Artikel nicht durch andere Methoden erfasst (d.h. 283 Fälle haben möglicherweise ein falsches Datum, werden aber aufgeführt).
Also insgesamt 14755 neue Artikel, von denen 622 (=4,2%) nicht gemeldet wurden. Wie oben schon gesagt, sind darunter vor allem Fälle der erfahreneren Autoren. Merlissimo 03:50, 2. Apr. 2012 (CEST)
Seit einer Woche ist das neue Script aktiv. Damit werden die vor dem MW erkannten Fälle nun wieder alle gelistet. Damit das machbar war gibt es nun einen neuen internen Cache. Zusätzlich neu ist die Erkennung unter bestimmten Bedingungen wieder hergestellte (undelete) Seiten. Damit nun hier erledigt. Merlissimo 10:55, 13. Apr. 2012 (CEST)
Dieser Abschnitt kann archiviert werden. Merlissimo (Merlissimo 10:55, 13. Apr. 2012 (CEST))

Nachbesserung statt Deaktivierung

Dort, wo er relativ unbetreute Portale aktualisiert, ist der Bot eine gute Hilfe. Allerdings sollte er dringend überarbeitet werden, da er ziemlich undifferenziert vorgeht! Warum wird zum Beispiel ein literarisches Werk wie Maigret und der Treidler der „Providence“ im Portal:Geschichte des 20. Jahrhunderts/Neue Artikel geführt? Und das ist nur ein Beispiel von vielen. Sämtliche Autoren werden unterschiedslos dort ebenfalls geführt. Mit welchem Zweck? Gruß --Laibwächter (Diskussion) 17:32, 4. Apr. 2012 (CEST)

Dafür ist nicht der Bot, sondern das Kategoriesystem verantwortlich: Der Artikel Maigret und der Treidler der „Providence“ ist in der Kategorie:Literatur (20. Jahrhundert) eingeordnet, die eine Unterkategorie von Kategorie:Kultur (20. Jahrhundert) ist, welche wiederum eine Unterkat. von Kategorie:20. Jahrhundert ist. Da muss der Parameter IGNORECAT erweitert werden, sonst wird der Artikel weiterhin auf der Seite aufgeführt. Gruß --Daniel749 •Diskussion•ST•WPST 17:44, 4. Apr. 2012 (CEST)

MediaWiki 1.19 Erscheinungstermin

Wann wird MW 1.19 voraussichtlich offiziell herauskommen? Gibt es schon etwas Neues? --109.75.18.242 08:30, 13. Apr. 2012 (CEST)

hopefully […] in April 2012 – mw:MediaWiki 1.19, beachte aber auch diese Änderung --Schnark 09:28, 13. Apr. 2012 (CEST)
Schaun mer mal. --109.75.18.242 12:34, 13. Apr. 2012 (CEST)

Haltbarkeit von Cookies

Hat es irgendeinen Sinn, dass es schon nach wenigen Tage nach der letzten Anmeldung heißt: „Du bist nicht angemeldet“? --\m/etalhead ✉ 10:05, 15. Apr. 2012 (CEST)

Könntest du deine Beobachtung konkretisieren?
  1. http oder https?
  2. Geht es um das Kreuzchen „auf diesem Browser für 30 Tage angemeldet bleiben“ beim Login?
  3. Könnte sich zwischenzeitlich deine IP-Adresse geändert haben?
  4. Fand in den „mehreren Tagen“ irgendeine Aktivität statt, und sei es einfach nur das Angucken einer Seite?
Die „Haltbarkeit der Cookies“ wäre vermutlich weniger betroffen; ihre Verfallsdaten werden eigentlich korrekt gesetzt. Höchstens könnten sie von irgendeiner Browser-Sicherheitsanwendung komplett gelöscht werden. Vielmehr dürfte es sich bei deiner Beobachtung um einen Sicherheitsmechanismus unseres Anmeldeservers handeln, bei dem Zweifel an deiner Identitätszuordnung aufgekommen sind.
LG --PerfektesChaos 12:27, 15. Apr. 2012 (CEST)
Zu 1.: HTTP
Zu 2.: Selbstverständlich
Zu 3.: Ändert sich doch regelmäßig
Zu 4.: Ja --\m/etalhead ✉ 13:24, 15. Apr. 2012 (CEST)

Mir passiert das auch zuweilen, nach gefühlt kürzerer Zeit als es sollte (habe aber nicht mitgeschrieben). Also: Häkchen gesetzt, fast jeden Tag WP aufgerufen (über Hauptseite). --eryakaas (Diskussion) 13:42, 15. Apr. 2012 (CEST)

Danke; Rückfragen an euch beide zum weiteren Einkreisen:
  1. Geschieht das innerhalb derselben Browser-Sitzung, oder wird der Browser zwischenzeitlich geschlossen?
  2. Es ist sichergestellt, dass kein Add-On des Browsers die Keksdose leermachen soll?
  3. Das Problem gibt es erst neuerdings; das heißt: Bis vor kurzer Zeit hat es über viele Monate funktioniert, und jetzt auf einmal (seit wann?) wird gemuckt?
  4. Habt ihr die Möglichkeit, etwa über Browser-Addons Cookies und IP-Adresse zu inspizieren?
Normalerweise wird eine Sitzung bei https nach 60 Minuten, bei http wohl nach 24 Stunden oder so beendet, wenn keine Seite aufgerufen wurde und keine Aktivität erfolgte. Die fragliche Option setzt dieses Zeitlimit außer Kraft; das heißt aber nicht, dass alle Sicherheitsregeln über Bord geworfen werden müssen. So kann man zusätzlich Browser-Version oder IP-Adresse prüfen, um ein Kapern des Benutzerkontos zu vermeiden. – Man kann über Jahre die gleiche IP-Adresse einer Firma oder Uni haben, oder auf einem Mobilgerät kann sie sich alle paar Stunden ändern.
  • Auf dem Wiki-Anmelde-Server könnte im Rahmen von Software-Umstellungen oder durch technisches Problem der Bestand an laufenden Sitzungsdaten gelöscht worden sein.
  • Programmierer könnten Sicherheitsabfragen des Anmelde-Servers kürzlich verschärft haben. Solche Einzelheiten hängt man nicht gern an die große Glocke. Die Option eröffnet schließlich ein massives Sicherheitsproblem.
  • Wenn eine bleibende Ursache identifiziert wird, lässt sich Hilfe:Anmelden konkret ergänzen und vielleicht ein Hinweis zur Vermeidung geben.
Liebe Grüße --PerfektesChaos 22:13, 15. Apr. 2012 (CEST)

Oh je, so genau kann ich da nicht weiterhelfen. Nur soweit:

  1. Es geht um verschiedene Browsersitzungen, ich mache den Rechner (fast) jeden Tag aus ;-)
  2. Keine Add-Ons, auf anderen Seiten, wo ich unterwegs bin, fliege ich nicht raus.
  3. Nein, eher umgekehrt, es ist mir jetzt schon länger nicht mehr aufgefallen, es muss im vorigen Jahr ein paar Mal passiert sein, teilweise kann es auch noch länger her sein. Meiner Erinnerung nach war das neue Einloggen nach ein paar Tagen nötig.
  4. Inspizieren? Soll ich gucken, welche Cookies gesetzt sind und welche IP ich habe, oder was ist gemeint?

eryakaas (Diskussion) 02:40, 16. Apr. 2012 (CEST)

bdi

Seit heute ist MediaWiki 1.20wmf1 aktiv und damit ist das HTML-Element bdi für den Einsatz in normalen Wikiseiten zugelassen (Bug 31817, gerrit:3844). Wo kann das sinnvoll eingesetzt werden? Beispielsweise bei der Vorlage:Arabische Schrift? --Fomafix (Diskussion) 20:31, 25. Apr. 2012 (CEST)

Nach https://developer.mozilla.org/en/HTML/Element/bdi wird das Element erst seit Firefox 10.0 und Chrome 16 und von den anderen Browsern noch überhaupt nicht unterstützt. Vermutlich wäre es daher sinnvoller derzeit noch auf das Element zu verzichten. Was zeigen den die Browser an?
  • (<bdi>مكة المكرّمة</bdi>) ergibt (مكة المكرّمة)
  • (<bdi dir="rtl">مكة المكرّمة</bdi>) ergibt (مكة المكرّمة)
  • (<span dir="rtl">مكة المكرّمة</span>) ergibt (مكة المكرّمة)
--Fomafix (Diskussion) 21:02, 25. Apr. 2012 (CEST)

Interwikis ausschließen

Worin sollte der Sinn bestehen, die Interwiki-Einbindung aus Wikidata zu unterbinden? Fehlerhafte Verlinkung wohl kaum, das könnte man ja in Wikidata korrigieren. 79.217.181.12 11:35, 15. Apr. 2012 (CEST)

Ich halte das aufgrund der Autorenfreiheit auf deWP für sinnvoll, dass grundsätzlich die technische Möglichkeit besteht, unabhängig von Wikidata zu arbeiten. Kann ja sein, dass diese Option genutzt wird, wenn es sich nicht um falsche Interwikilinks, sondern um umstrittene Verlinkungen handelt, bei denen hiesige Autoren anderer Ansicht sind als die Bearbeiter auf Wikidata. --Septembermorgen (Diskussion) 11:48, 15. Apr. 2012 (CEST)
Ich denke, dass es erstmal eher um die semantische Struktur geht. Es ist grundsätzlich sinnvoll, bei Einführung eines Mechanismus gleichzeitig auch die Gegen-Option einzuführen, die in bestimmten Einzelfällen auch die Nichtverwendung eines Automatismus ermöglicht.
Es muss bei weltweiten Wiki-Projekten über etliche Sprachen und Kulturen hinweg nicht immer so sein, dass jedes Lemma absolut deckungsgleich interwiki-verlinkbar wäre. Bei einem Lemma über ein menschliches Individuum ist der Artikelgegenstand zweifelsfrei identisch. Bei abgrenzbaren Begriffen sind jedoch teilweise Kongruenzen vorstellbar, so dass bestimmte Gruppen von Artikeln untereinander interwiki-mäßig zusammenpassen, andere Gruppen ebenfalls untereinander – aber nicht wie die andere Gruppe, und dazwischen Autoren und Projekte ein Lemma so abgegrenzt haben, dass es zu beiden Gruppen passt.
Schönen Sonntag --PerfektesChaos 12:39, 15. Apr. 2012 (CEST)
Hallo. Wann werden den die zentralen Interwikis überhaupt aktiviert? Gibt es dazu schon eine Hilfeseite? Gruß --Tlustulimu (Diskussion) 17:00, 22. Apr. 2012 (CEST)
Da WP:Wikidata noch in der Entstehung ist, kann es etwas dauern, wohl bis März 2013. Hat aber auch den Vorteil, das man schon früh Einfluss nehmen kann. Da die Erwartungen aber auch hoch sind, kann das ganze sich auch sehr in die Länge ziehen. Der Umherirrende 20:24, 22. Apr. 2012 (CEST)

Kann man das dann eigentlich auch projektweit einstellen? (Beispiel: es gäbe z. B. eine klingonische Wikipedia, die aber von der de.community grundästzlich nicht als verlinkungsfähig akzeptiert wird, oder auch bei Schwesterprojektverlinkungen Projekte wie das umstrittene Wikispecies, oder wenn etwas Wikisource grundsätzlich nicht auf Wikinews verlinken will). --AndreasPraefcke (Diskussion) 21:17, 29. Apr. 2012 (CEST)

Mit der Methodik nicht, da müsste man sich vermutlich etwas anders überlegen (Etwas, was höchstens für Admins änderbar wäre). Frag mal auf WP:Wikidata, ob soetwas angedacht ist. Der Umherirrende 10:05, 30. Apr. 2012 (CEST)

Bei Änderungen an beobachteten Seiten E-Mails senden

Ist diese Option auf Projekten wie enwiki und dewiki überhaupt sinnvoll? Abgesehen davon, dass mein Postfach regelrecht geflutet würde, wenn ich das aktiviere, frage ich mich, ob man damit nicht auch den Server völlig überlasten würde. --PaterMcFly Diskussion Beiträge 08:10, 2. Mai 2012 (CEST)

Die Option ist für uns Power-Wikipedianer sicherlich nicht sinnvoll. Für Wenig-Nutzer, die über nur wenige Artikel informiert werden möchten, ist die Option sehr sinnvoll. Im Rahmen von Wikipedia-Workshops an VHSsen usw. wird immer wieder nach dieser Möglichkeit gefragt. Serverlast: Schau'n mer mal. — Raymond Disk. 08:47, 2. Mai 2012 (CEST)
Ich sehe das mit mäßigem Argwohn.
Welche (möglicherweise konfigurierbaren) Begrenzungsmöglichkeiten gäbe es?
  • Delay – wie viele Stunden (vielleicht 24 oder 72) zwischen der Beo-Änderung und dem Versenden der E-Mail?
  • Reset – mit dem Einloggen (oder Aufruf der Beo) wird der Benachrichtigungsmechanismus zurückgesetzt.
  • Wie oft? – Mail gibt es nur eine einzige auf die erste Änderung hin; danach ist Einloggen erforderlich.
  • Beo-Länge? – Ab 100 oder 1000 beobachteten Seiten keine Mail mehr.
Unter Einhaltung derartiger Limits habe ich nichts gegen die weltweite Nutzung. Ein polnischsprachiger Benutzer mit Stammsitz in der polnischsprachigen Wikipedia mag besonderes Interesse an drei Artikeln in der deWP haben; ansonsten würde die deWP nur selten benutzt. Da ist die Benachrichtigung okay. Auch der Ortschronist mit nur einem selbst geschriebenen Artikel und Beobachtung des Landkreis-Artikels soll seine Heimatkunde pflegen dürfen, oder man beobachtet nur die persönliche Benutzer-Seite→Disku.
Beste Grüße --PerfektesChaos 09:32, 2. Mai 2012 (CEST)
„Argwohn“? Die Serveradministration wird ja wohl selbst sehen, ob die Infrastruktur das verkraftet, insofern ist mir nicht so klar, wieso wir uns hier mit solchen Überlegungen herumschlagen sollen. —Pill (Kontakt) 09:36, 2. Mai 2012 (CEST)
Perfektes Chaos bringt aber einige mE wesentlichen Punkte auf den Tisch: Erstens ist (ausser ich übersehe was) nicht wirklich dokumentiert, wann genau ein Mail verschickt wird und wie oft. Und zweitens müsste man das wohl mindestens nach Namensraum filtern können. Änderungen an Artikeln z.B. könnten mich vielleicht auch interessieren, aber ich will bitte dann kein E-Mail bei jeder VM-Meldung. --PaterMcFly Diskussion Beiträge 18:11, 2. Mai 2012 (CEST)
Ich glaube nicht, das wir uns lokal Sorgen machen müssen über die Serverlast. Die Funktion ist für jeden Benutzer standardmäßig aus, so dass kein Poweruser plötzlich mit E-Mail überflutet wird. Hätten wir auch schon von gehört. Wer die Funktion aktiviert: Gesendet wird sofort nach einer Änderung einer beobachteten Seite durch Dritte. Ob dann 1 oder 100 Bearbeitungen erfolgen, spielt keine Rolle, der Benutzer erhält nur eine E-Mail. Er muss die Seite aktiv besuchen, um einen Reset für eine weitere E-Mail auszulösen. Filter auf bestimmte Namensräume gibt es nicht. Müssten erst programmiert werden. Du hast die Wahl: Nutze die Funktion oder lass es. Ggfs. kannst du ja auf Mailclient-Seite Filter einrichten. — Raymond Disk. 21:44, 2. Mai 2012 (CEST)

Vernünftig angewandt senkt die Funktionalität IMHO die Server-Last. Bei de.wikipedia verwende ich es natürlich nicht, aber bei en.wikipedia und commons kann ich mir jetzt ersparen, täglich auf Beobachtungsliste zu klicken und bekomme ich stattdessen ein oder zweimal pro Woche eine Mail. Und bei anderen Wikis, wo ich noch seltener Beobachtungslisteneingänge bekomme, dass ich sie gar nicht mehr regelmäßig aufrufe, habe ich jetzt überhaupt erst die Chance, mit vernünftigem Aufwand eventuelles Feedback auf meine Beiträge mitzubekommen. Und natürlich mag es vielen Benutzern mit anderem Stammwiki in Bezug auf de.wikipedia entsprechend gehen, also ist es gar keine Frage von „enwiki und dewiki“, ob es für einen Wiki überhaupt sinnvoll ist. Eine Begrenzung auf „100 beobachtete Seiten“ scheint mir auch nicht sinnvoll – ich habe etliche Seiten auf meiner Beo, die nur alle paar Jahre mal geändert werden, das macht in der Summe auch nur alle paar Tage mal eine Änderung. Wenn Limit, dann dynamisch bei z. B. der 10. Mail in 24 h den Versand unterdrücken. Ich empfehle aber, einfach erstmal darauf zu vertrauen, dass die Benutzer auch ein Interesse an der vernünftigen Nutzung der Funktionalität haben und 99,9 % sie nur dann nutzen werden, wenn sie nicht mit Mails geflutet werden. Von mir ein Dankeschön für die Funktion! --dealerofsalvation 05:28, 3. Mai 2012 (CEST)

Neue Wartungskategorien

Damit später keine Umbenennungsanträge für die beiden neuen Wartungskategorien gibt, schlage ich vor, die entsprechenden Systemnachrichten schon vorher mit dem gewünschten Namen anzulegen. Es ergibt sich dann:

Falls jemand bessere Vorschläge hat, nur zu, einfach abändern. Vielen Dank. Ich (oder auch jemand anders) werden sie dann bei Zeiten entsprechend anlegen. Der Umherirrende 20:37, 29. Apr. 2012 (CEST)

Öh, mit Knotenpunkten kann ich gar nichts anfangen (erster Gedanke: hat das was mit WP:GEO zu tun). Den Begriff „Node“ verbinde ich dagegen sofort mit einem DOM-Knoten. Imho besser unübersetzt lassen. Oder eine Entsprechung, mit der Laien auch was anfangen können, finden, etwa „Verschachtelungtiefe“. Was genau wird da nochmal gezählt, PPFrame-Nodes? -- ✓ Bergi 02:28, 30. Apr. 2012 (CEST)
Um die Übersetzung habe ich mich diesmal nicht gekümmert. Ich habe aber mal "Knotenpunkt" in "Knoten" verkürzt, da die Übersetzung ja allen zugute kommen sollte.
Es ist eher eine Stacktiefe, siehe mw:Manual:$wgMaxPPExpandDepth. Das ganze dient nur dazu, den Speicherbedarf einer Wikiseite beim parsen zu begrenzen und als weitere Absicherung gegenüber Rekursionen, die in Endlosschleifen enden können. Der Umherirrende 08:33, 30. Apr. 2012 (CEST)
  • Anderer Vorschlag für „Knoten“ vielleicht: „Element-Anzahl“ – das ist fachlich wohl nicht falsch, vermeidet aber Assoziationen zu Schnürsenkeln.
  • In beiden Kategorie-Titeln sollte die Vokabel „Vorlage“ auftauchen, also etwa „Vorlagen-Expansionstiefe“ und entsprechend „Vorlagen-Elementanzahl“.
  • „Verschachtelungstiefe“ ist ein Node Count wohl eher nicht; auch bei Verschachtelungstiefe=1 wäre eine Million Knoten nebeneinander wohl zuviel.
Es ist in der Tat pfiffig, sich vor der Neuanlage zu mehreren Gedanken über einen möglichst allgemein zu kapierenden Namen zu machen.
Sonne für alle --PerfektesChaos 09:52, 30. Apr. 2012 (CEST)
Unter der BKS Knoten gibt es den Link Knoten (Programmierung), somit ist natürlich der Schnürsenkelknoten möglich, aber bei einer String gibt es ja ähnliche Probleme mit der Assoziation. Die Verschachtelungstiefe bezieht sich auch auf "Expansion depth", 1 Mio. ist die aktuelle Grenze für den "Node count" ;-). Wenn man das Hickhack und die Benamung von den anderen (technischen) Wartungskategorien gelesen hat, dann versucht man das zu vermeiden und sauber zu starten. Der Umherirrende 10:02, 30. Apr. 2012 (CEST)

Bitte in Kategorie:Wikipedia:Knotenanzahl überschritten und Kategorie:Wikipedia:Expansionstiefe überschritten umbenennen. Es heißt auch Kategorie:Wikipedia:Belege fehlen und nicht Kategorie:Wikipedia:Seite, in der Belege fehlen usw. 89.247.154.42 08:50, 2. Mai 2012 (CEST)

Dann wäre ich mal für
Wir schaffen das schon. --PerfektesChaos 09:25, 2. Mai 2012 (CEST)
Oder „Kategorie:Wikipedia:Maximale … überschritten“. --Leyo 09:31, 2. Mai 2012 (CEST)
Ich hatte mich da eher an Kategorie:Wikipedia:Seite, die aufwändige Parserfunktionen zu oft aufruft orientiert, da es aber schon Kategorie:Wikipedia:Maximale Seitengröße durch Vorlageneinbindungen überschritten und Kategorie:Wikipedia:Maximale Gesamtgröße der Vorlagenparameter überschritten gibt, wäre das Schema von Leyo nicht schlecht, also Kategorie:Wikipedia:Maximale Knotenanzahl überschritten und Kategorie:Wikipedia:Maximale Expansionstiefe überschritten. Ist auch nah am Vorschlag der IP. Der Umherirrende 18:13, 3. Mai 2012 (CEST)
Leyos Variante hielte ich auch für am sinnvollsten. -- Inkowik 19:29, 3. Mai 2012 (CEST)
Erledigt. Systemnachrichten angepasst und Kategorien angelegt, auch wenn sie erst ab 9. Mai füllen könnten. Der Umherirrende 18:14, 4. Mai 2012 (CEST)

Auf deiner Beobachtungsliste kannst du alle Benachrichtigungsmarkierungen zusammen zurücksetzen.

Auch auf die Gefahr hin, das es nicht die richtigen Leute anspricht, ansonsten einfach ignorieren. Der oben genannte Satz steht in jeder E-Mail, die man für eine Änderung auf der Beobachtungsliste bekommt, nur dumm, das die Funktion bei uns (wie vorne zu lesen ist) aus Performancegründen garnicht aktiv ist. Wird Neulinge wohl sicher verwirren. Technisch könnte man diese Schaltfläche mit JavaScript aber nachbauen, weil MediaWiki Requests mit dem reset Parameter (als POST) akzeptiert und dann die entsprechenen Zeitstempel zurücksetzt und somit alle Seiten als besucht markiert sind. Da ich das System noch nicht ganz verstanden habe, schreibe ich es hier hin, vielleicht findet sich jemand, der das verwerten kann. Da die E-Mail-Benachrichtigung und die aus Performancegründen abgeschalte Funktion die gleiche Datenbankspalte nutzen, scheint das Problem nicht so groß zu sein. Ich denke aber, das die Techniker da besseren Einbick haben und somit die (für die Server) richtige Entscheidung gewählt haben. Der Umherirrende 19:26, 9. Mai 2012 (CEST)

Vielleicht lässt sich auf der BEO-summary (zumindest für einige Wochen) ein <small>Hinweiskasten</small> anbringen, die darüber aufklärt, mit Link auf Hilfeseiten-Abschnitt. --PerfektesChaos 20:37, 9. Mai 2012 (CEST)
Ich habe den Satz erstmal aus MediaWiki:Enotif body entfernt. Ob man da noch weiter Informieren muss, überlasse ich anderen. Der Umherirrende 20:42, 9. Mai 2012 (CEST)
Da die Funktion jetzt auch hier aktiviert ist, habe ich die Anpassungen wieder entfernt und das hier hat sich erledigt. Der Umherirrende 19:10, 10. Mai 2012 (CEST)

lässt sich dat ganze markierungszeug auch wieder abstellen? --Muscari (Diskussion) 22:57, 10. Mai 2012 (CEST)

Schau mal unter WP:FzW#Fettschrift in der Beobachtungsliste?. Der Umherirrende 15:07, 11. Mai 2012 (CEST)
Ev. könnte man sicherstellen, dass man die Infos nach der dortigen Archivierung noch findet. --Leyo 15:33, 11. Mai 2012 (CEST)
Ja, da wäre Hilfe:Beobachtungsliste wohl gut geeignet. Unterhalb von WP:Skin wird es wohl untergehen. Siehe auch die Diskussionsseite. Der Umherirrende 15:35, 11. Mai 2012 (CEST)
Ich hatte es mir schon vorgemerkt; WP:CSS#watchlist wird es nachher zentral aufnehmen, und Hilfe:Beobachtungsliste darauf hinweisen. Noch scheint aber die Sonne; wenn es nachher regnet, geht’s weiter. LG --PerfektesChaos 16:24, 11. Mai 2012 (CEST)

Update on IPv6

Kopie von WP:FzW#Update on IPv6, aber hier dürfte es auch noch ein paar Leute erreichen, eine Übersetzung ist akutell noch nicht angefangen.

Datei:Wikimedia Foundation RGB logo with text.svg

(Apologies if this message isn't in your language. Please consider translating it, as well as the full version of this announcement on Meta)

The Wikimedia Foundation is planning to do limited testing of IPv6 on June 2-3. If there are not too many problems, we may fully enable IPv6 on World IPv6 day (June 6), and keep it enabled.

What this means for your project:

  • At least on June 2-3, 2012, you may see a small number of edits from IPv6 addresses, which are in the form "2001:0db8:85a3:0000:0000:8a2e:0370:7334". See e.g. w:en:IPv6 address. These addresses should behave like any other IP address: You can leave messages on their talk pages; you can track their contributions; you can block them. (See the full version of this announcement for notes on range blocks.)
  • In the mid term, some user scripts and tools will need to be adapted for IPv6.
  • We suspect that IPv6 usage is going to be very low initially, meaning that abuse should be manageable, and we will assist in the monitoring of the situation.

Read the full version of this announcement on how to test the behavior of IPv6 with various tools and how to leave bug reports, and to find a fuller analysis of the implications of the IPv6 migration.

--Erik Möller, VP of Engineering and Product Development, Wikimedia Foundation 02:51, 2. Jun. 2012 (CEST)

https / http

Am 13. April steht Folgendes:

(Lokales JavaScript) Ein lokales JavaScript wurde aktiviert, welches Weblinks auf Wikimedia-Projekte in protokoll-relative Weblinks ändert. Ein ähnliches Skript gab es schon lange für secure.wikimedia.org. Durch das Skript soll ein möglicher Wechsel zwischen http und https bei Klick auf Weblinks vermieden werden. Falls Weblinks auffallen, die jetzt nicht mehr funktionieren, einfach auf der Diskussionsseite hier melden.

Kann es sein, dass diese Änderung dazu führt, dass man z. B. nicht mehr innerhalb der Wikimedia-Projekte auf die entsprechenden https-Login-Seiten verlinken kann?

Beispiel:

Dies ist ein Link auf eine https-Seite (siehe Quelltext). Sie wird aber zu einem http-Link umgewandelt. Externe Links (z. B. Google) funktionieren aber noch mit https. DestinyFound (Diskussion) 06:42, 5. Jun. 2012 (CEST)

Einige erste Antworten:
  • Umwandlungen https ↔ http betreffen ausschließlich URL aus dem Wiki-Bereich, nicht Google.
  • Sinn der Sache ist, dass man nicht aus seiner Wiki-Anmeldung in dem einen System (insbesondere der geschützten https-Übertragung) herausfliegen soll, wenn irgendwo im Wikitext eine URL auf eine Wikiseite (etwa Versionsunterschied) mit dem Protokoll angegeben ist, so wie man das normalerweise durch copy&paste aus der Adresszeile des Browsers überträgt.
  • Deine Anfrage kommt ja von der WP:FZW #https-Link funktioniert nicht.
  • Der dort geschilderte Fall ist eine korrekte Ausnahme: Hier will man bewusst von einer momentan mit http aufgebauten Seite wechseln zu einer Seite unter https.
  • Es dürfte sich so verhalten, wie du das schon vermutest: Das geschilderte Skript wandelt auch hier die URL so um, dass man innerhalb seines Protokolls bleibt.
  • Mein Problem: Ich kann dieses elende Link nicht finden. Auch wenn ich auf http und natürlich unangemeldet ankomme, finde ich weder unter dem beschriebenen Spezial:Benutzerkonto anlegen etwas wie „Benutzerkonto anlegen (sichere Verbindung)“ noch auf anderen Wegen.
    • Die Zeichenkette „(sichere Verbindung)“ wäre in
      • MediaWiki:Loginend
      • MediaWiki:Signupend – da findet sie noch die Suche, aber ich sehe nix im Text (auch nicht Quelltext), und er wurde auch seit Wochen nicht verändert.
        • Nebenbei ist hier der Text verdreht: Der Klammerzusatz „(Checkuser-Funktion)“ gehört hinter „ausgewählte Personen“ und nicht an die momentane Stelle.
  • Sobald identifiziert wurde, für welche Seiten Ausnahmen gemacht werden müssen, kann das Skript erstmal kostengünstig den Namensraum ===-1 abfragen und dann gucken, ob es sich um so eine Anmeldungs-/Registrierungs-Seite handelt, und die Umwandlung auf bestimmten Seiten unterdrücken.
Liebe Grüße --PerfektesChaos 09:13, 5. Jun. 2012 (CEST)
Ja, die gemeinte Seite musste ich auch erst suchen. ;) Gemeint ist Hilfe:Benutzerkonto anlegen. Da wird oben eben mit einer sicheren Verbindung geworben, die dann aber halt so gar nicht funktioniert. DestinyFound (Diskussion) 10:44, 5. Jun. 2012 (CEST)
Ich glaub en hat dafür extra n Template erstellt.. siehe en:Template:Sec link. DestinyFound (Diskussion) 10:57, 5. Jun. 2012 (CEST)


Danke für deine Informationen.

Ich sehe drei Möglichkeiten:

  • Das Skript, das seine eigentliche Arbeit hier tut und von MediaWiki:Common.js aufgerufen wird, müsste speziell im Hilfe-NR diesen einen Seitennamen ausnehmen.
    • Das Skript wird auf dem fertig ausgelieferten HTML-Dokument tätig; was immer man mit Vorlagen und dergleichen auf der Wiki-Seite anstellen würde, ist dann schon zu endgültigem HTML verarbeitet. (Auf Spezial-Seiten wird es übrigens nicht tätig; deshalb funktioniert das https-Link auf Spezial:Anmelden.)
    • Die Nummer des NR wird ohnehin bereits festgestellt und ausgewertet. Der effizienteste Weg wäre hier:
switch ( mw.config.get( 'wgNamespaceNumber' ) ) {
   case -2 :   // Media:
   case -1 :   // Spezial:
   case  0 :   // ANR
   case  8 :   // MediaWiki:
      break;
   case 12 :   // Hilfe:
      if ( mw.config.get( 'wgTitle' ) === 'Benutzerkonto anlegen' ) {
         break;
      }
      // fall through
   default:
      mw.loader.using( [ 'user', 'mediawiki.user', 'user.options' ],
      ...
      });
}   // switch wgNamespaceNumber
  • Ein böser Hacker-Trick wäre es allerdings, auf der Hilfe-Seite statt https HTTPS zu schreiben; das müsste auf jedem Browser funktionieren, entspricht aber nicht meinen eigenen Qualitätsstandards. Risiko wäre, dass irgendein pfiffiger Server-Algorithmus zwischendurch aus HTTPS wieder https gemacht hätte, oder die Hilfeseite routinemäßiger Syntaxkorrektur überzogen wird.
  • Auf der Hilfeseite könnte statt des angebotenen Links der Benutzer dazu aufgefordert werden, selbst ein 's' in die URL seiner Browser-Adresszeile einzufügen. Doof.

Soviel dazu --PerfektesChaos 12:37, 5. Jun. 2012 (CEST)

Wärs vielleicht nicht irgendwie möglich und einfacher via index.php die Seite anzusteuern und dann mittels Parameter den https-Wechsel zu erzwingen? Also sowas wie: http://de.wikipedia.org/w/index.php?title=Spezial:Anmelden/signup&secure=true oder so. DestinyFound (Diskussion) 13:27, 5. Jun. 2012 (CEST)
Theoretisch schon.
  • Hilfe:URL-Parameter kennt zwar noch keinen secure-Parameter, aber da könnten wir uns ja selbst helfen.
  • Die Seite Spezial:Anmelden müsste also immer ein JavaScript ausführen, das bei Vorhandensein des secure-Parameters die Location dieser Seite auf https umschaltet. Weil der Namensraum ausgenommen ist, bliebe das auch unverändert.
  • Nun könnte man einwenden, dass bei Benutzern ohne aktiviertes JavaScript dies nicht ausgeführt werden würde. Das stimmt. Allerdings kann man von vornherein auf der Hilfeseite auf https://de.wikipedia.org/w/index.php?title=Spezial:Anmelden/signup&secure=true verlinken; ohne aktiviertes JavaScript würde dies auch nicht in (protokollrelatives) http:// glattgezogen.
Mein obiger Vorschlag ermöglicht allerdings auch, gelegentlich andere Seiten von der Protokollrelativierung auszunehmen, falls sich das ergibt.
Schönen Tag --PerfektesChaos 13:43, 5. Jun. 2012 (CEST)
Auf Seiten mit Passwortfeldern wird MediaWiki:Common.js nicht ausgeführt (oder sollte zumindestens nicht), daher würde das mit einen URL-Parameter nicht funktionieren. En.wp hat vielleicht eine Vorlage, aber dort besteht das Problem auch nicht, weil kein JavaScript die URLs ändert. Ausnahmen für ganze Seiten fände ich schlecht, per Zielseite (also title= oder so) würde auch aufwendiger sein. Der Umherirrende 17:56, 5. Jun. 2012 (CEST)
(BK) Wollte ich auch grad anmerken, dass auf Spezial:Anmelden kein (anpassbares) JS ausgeführt wird.
Der URL-Parameter scheint mit aber der einzig passable Ausweg zu sein. Man kann das Skript relativ einfach anpassen, indem man die Bedingung erweitert:
        if (href.search(reg) === 0) {
            if (href.search(/\?([^&]*&)*protocol=absolute(&|#|$)/) == -1)
                link.setAttribute('href', href.substr(href.substr(4,1) === "s" ? 6 : 5 ));
            return;
        }
meint -- ✓ Bergi 18:12, 5. Jun. 2012 (CEST)
Ganz wie ihr meint; sehe die Lösungsvarianten leidenschaftslos.
  • Mein obiges switch hätte den Vorteil, dass noch mehr komplette NR ausgenommen werden können; mir fiele noch die Vorlage: ein. Der Title wird nur im Fall des Hilfe-NR abgeglichen; allerdings die komplette Seite ausgenommen. Auch bisher schon wird NR<=0 getestet. Im Gegenzug spart man sich die Analyse jedes einzelnen Links in allen NR gemäß Bergi.
  • Bergis RE ist aber auch okay. Wobei ein indexOf() statt aufwändigerer RE-Suche es auch tun würde; ein &protocol=absolute oder &protocol=keep ist charakteristisch genug, um diese URL zu überspringen; es kann nie Teil des Seitentitels sein. Das ? stünde bereits bei ?title= und mehr als dieses eine Link auf der genannten Hilfeseite oder vielleicht mal irgendwo ein zweites oder drittes kommt ohnehin nicht vor.
  • Dass es auf Spezial:Anmelden kein JS gibt, wusste ich nicht; klingt aber ob der Passwörter recht logisch.
Grüße --PerfektesChaos 18:50, 5. Jun. 2012 (CEST)
Vielen Dank, dass ihr euch Gedanken macht, und sorry für die Verwirrung – natürlich war die Hilfeseite gemeint. Gruß, --Nirakka Disk. Bew. 23:21, 5. Jun. 2012 (CEST)

Zwar sehe ich grundsätzlich keine Notwendigkeit https Links in Protokoll relative zu ändern (wenn man über http angemeldet ist, ist die Sitzung auch unter https nutzbar, aber nicht andersrum)... aber wenn ihr das trotzdem so machen wollt, dann nutzt bitte mw.util.getParamValue zum auslesen des Parameters und auch das möglichst nur einmal (bin mir nicht sicher, ob die Funktion cached, aber bei jedem Link fund zu suchen ist wirklich nicht notwendig) - Hoo man (Diskussion) 12:02, 6. Jun. 2012 (CEST)

Doch, hier geht es eben genau darum jeden Link zu durchsuchen. Der Sinn der Relativierung: http-Nutzer sollen auf http bleiben und https-Nutzer sollen auf https bleiben. getParamValue() zu benutzen ist hier übrigens absolut unperformant, da nicht gerade für diese Aufgabe vorgesehen. -- ✓ Bergi 12:22, 6. Jun. 2012 (CEST)
Ich würde nur dann von der Benutzung von mw.util.getParamValue abraten, wenn dafür extra mw.util geladen werden muss, sonst würde ich den schöneren und besser wartbaren Code bevorzugen. Wichtiger ist es eh, dafür zu sorgen, dass nur einmal getestet wird. Mir erschließt sich aber immer noch nicht der Sinn, dedizierte https Links in Protokoll relative umzwandeln, wenn jemand https Linkt, dann sollte da auch ein https Link rauskommen - Hoo man (Diskussion) 12:34, 6. Jun. 2012 (CEST)
  1. Wenn jemand dezidiert mit https auf die DNB oder bugzilla oder gerrit oder ticket verlinkt, dann wird daran auch nichts verändert.
  2. Die weitaus überwiegende Zahl der Verlinkungen im WMF-Bereich entsteht lediglich dadurch, dass jemand die komplette URL aus der Adresszeile seines Browsers kopiert, so wie sie zufällig grad dasteht, und in die Seite hineinklatscht. Hier ist weder von Absicht noch von besonderer Kenntnis die Rede. Für den nächsten, der dem Link folgt, ist das aber unangenehm; insbesondere wenn aus guten Gründen unter https tätig ist und nun unmerklich in der deWP durch eine Versionsunterschieds-Seite auf http runtergestuft wird, und das nunmehr auch bei jedem Link, dem von dieser http-Seite aus gefolgt wird. Für den Benutzer, der bewusst unter http arbeiten möchte, ist es eine Behinderung, wenn er durch URL innerhalb der WMF unbemerkt auf https geschoben wird und von nun an verschlüsselt arbeiten muss; in Einzelfällen hatte das auch bereits Interaktionsprobleme mit der gleichzeitigen Anmeldung noch unter http zur Folge.
  3. Ich kenne nur genau drei Seiten, bei denen man innerhalb der deWP von einem beabsichtigten Protokollwechsel durch WMF-Links sprechen kann: Hilfe:Benutzerkonto anlegen, Hilfe:Anmelden und Hilfe:Secure Server kommen grundsätzlich in Frage.
  4. Betreffend der Performance gebe ich Bergi völlig recht: Diese Sequenz wird zwangsweise bei praktisch jedem angemeldeten und unangemeldeten Benutzer ausgeführt, und zwar würde jedes Link analysiert, das auf der HTML-Seite vorkommt. Hier ist die 15 Jahre alte Basismethodik angebracht. Hinsichtlich des Gesamtablaufs würde ich kurzerhand die vorgenannten drei Hilfeseiten und die komplett ignorierten Namensräume ausnehmen und ansonsten Links innerhalb des normalen WMF-Bereichs nicht näher analysieren.
VG --PerfektesChaos 13:56, 6. Jun. 2012 (CEST) + erg --PerfektesChaos 14:15, 6. Jun. 2012 (CEST)
Nein, von der Performance ist das kein so großes Problem. Es werden nur auf nicht-ANR-Seiten Links aus dem Content-Bereich, die mit absolutem Protokoll beginnen, überhaupt analysiert. Das trifft i.d.R alle externen Links - nicht im ANR, wohlgemerkt! Die wenigen, die da noch übrigbleiben, müssen dann erstmal den riesengroßen Regex durchlaufen ob sie auf ein WMF-Projekt zeigen. Und erst dann käme ein protocol=keep-Parameter ins Spiel - performancmäßig wirklich zu vernachlässigen. mw.util wäre zwar sogar schon geladen, aber getParamValue dient nunmal dazu eine Parameterwert auszulesen und zu decodieren - hier muss aber nur überprüft werden ob eine feste Zeichensequenz vorkommt. Ob der Code schön aussieht ist mir dabei herzlich egal. -- ✓ Bergi 17:11, 6. Jun. 2012 (CEST)
Ich habe das Skript mal so gestaltet, das ein relative=no am Ende der URL den Link nicht ändert und dann entfernt wird. Der Umherirrende 22:04, 6. Jun. 2012 (CEST)
OK, keyword nur am Ende ist stark vereinfacht aber elegant; Danke. -- ✓ Bergi 22:37, 6. Jun. 2012 (CEST)
Ich hatte mir gedacht, das es das Problem löst und man mit dieser Einschränkung wohl leben kann, wenn man das http/https-Umwandlung nicht haben möchte. Soll ja auch nicht überall gebraucht werden. Der Umherirrende 22:40, 6. Jun. 2012 (CEST)
Dieser Abschnitt kann archiviert werden. -- ✓ Bergi 22:37, 6. Jun. 2012 (CEST)

Getrennte Links für Anmelden/Benutzerkonto anlegen

Ich finde die getrennten Links auch nicht schlecht, aber hätte mir die Links andersherum vorgestellt, weil dadurch ein Klick auf die gleiche Stelle wie vorher auch zur Anmeldeseite führen würde. Aber wenn man das vermutlich (nachträglich) umdreht, verwirrt es andere. Nur als Anregung, vielleicht sehen andere das ja anders. Der Umherirrende 18:51, 3. Jun. 2012 (CEST)

Der Link "Benutzerkonto anlegen" hat garkein Tooltip, ist mir gerade aufgefallen. Bei gerrit: sind die Links auch andersherum (Erst registrieren, dann anmelden; hier ist aktuell anmelden, dann registrieren). Die Reihenfolge dort finde ich nicht schlecht. Der Umherirrende 20:26, 3. Jun. 2012 (CEST)
Sehe ich genauso wie Der Umherirrende.
Man meldet sich sehr viel öfter an, als man ein Benutzerkonto anlegt. Also ist hierfür der mnemotechnisch und maushaptisch einfachere Platz ganz in der Ecke besser als eine Stelle „irgendwie ein bisschen davor“. --Silvicola ⇨⇦ 13:11, 4. Jun. 2012 (CEST)
Dem möchte ich mich anschließen. Auf meinem Smartphone drücke ich immer oben rechts in der Ecke und lande nun auf einmal auf der falschen Seite. Mein Hirn möchte sich ungerne umstellen... ;) XenonX3 - (☎:✉) 13:13, 4. Jun. 2012 (CEST)
Habe ich in der Zwischenzeit mit Gerrit:10460 gemacht und wurde auch schon in den normalen Softwarezweig übernommen. Mal schauen, ob sich das hält. Hier dürfte es am übernächsten Mittwoch, 20. Juni, live gehen. Der Umherirrende 19:12, 11. Jun. 2012 (CEST)

Commons-Bildbeschreibungs-Helferlein

(Helferlein) Es steht das neue Helferlein „Überspringen der lokalen Dateibeschreibungsseite, um sofort nach Commons zu kommen“ für angemeldete Benutzer zur Verfügung.

Hmm, hier weiß ich nicht, ob ich mich freuen oder ärgern soll. Die Verwirrung mit der zwischengeschalteten virtuellen Dateibeschreibungsseite dürfte ja eher die unbedarften Leser denn die angemeldeten Benutzer treffen. Wer in der Lage ist, dieses Helferlein zu finden und zu aktivieren, hat den Hintergrund sicher längst realisiert. Da wünsche ich mir klar eine sofortige Weiterleitung für alle Leser. --Stepro (Diskussion) 23:09, 21. Jun. 2012 (CEST)

Das ist der erste Schritt, siehe auch MediaWiki Diskussion:Common.js#Überspringen der deutschen Dateiseite. Der Umherirrende 15:41, 22. Jun. 2012 (CEST)

Überlange Zeilen in pre

Das hatten wir doch schon mal: Common.css, WP:VV. Ich sehe die damaligen Probleme immer noch. Ist zwar im Moment wieder raus, aber wenn es doch kommt, sollten wir uns überlegen, ob wir es hier lokal überschreiben wollen oder nicht. --Steef 389 15:56, 23. Jun. 2012 (CEST)

Ja, zwar nicht das IE6-Problem aber white-space: pre-wrap; erscheint noch immer deutlich sinnvoller. -- ✓ Bergi 23:50, 23. Jun. 2012 (CEST)
Wurde wieder entfernt. Vielleicht könnt ihr eure Bedenken bei dem Bug noch einbringen, so dass der nächste Versuch besser ist (falls das nicht schon von anderer Seite gemacht wurde). Der Umherirrende 21:03, 26. Jun. 2012 (CEST)

Änderungen heute?

Hallo, gab es heute irgendwelche Softwareänderungen? Seit kurzem wird mein vector.js auf de-WP nicht mehr ausgeführt, auf de-WQ funktioniert das identische Script nach wie vor. Bin ratlos. --Stepro (Diskussion) 13:54, 26. Jun. 2012 (CEST)

Bei mir werden die Thumbnails nicht geladen. Die Hamster sind wohl überlastet… --Leyo 13:57, 26. Jun. 2012 (CEST)
Hmm, also bei mir hält der merkwürdige Zustand an. --Stepro (Diskussion) 15:32, 27. Jun. 2012 (CEST)
@Stepro: Wir haben ein komplexes System, und Probleme können auf allen Ebenen entstehen: Browser-Version, Netzwerk, Skripte, Proxy-Server, Wiki-Software, Wiki-Server, …
Gleichwohl sollte man vermeidbare Fehlerquellen eliminieren, die in unvorhersehbarer Weise mit allem Möglichen interagieren können: WP:JS #document.write()
Wenigstens als
         importScript("Benutzer:Stefan/Sperrstatus.js");
         importScript("User:lustiger_seth/unsigned.js");
Grüße --PerfektesChaos 18:37, 27. Jun. 2012 (CEST)
Ach, ich seh grad – da ist ja noch viel mehr. Na dann WP:JS #Veraltet (Vollprogramm). Viel Spaß --PerfektesChaos 18:40, 27. Jun. 2012 (CEST)
Ah, die Seite kannte ich noch gar nicht. Vielen Dank! --Stepro (Diskussion) 20:29, 27. Jun. 2012 (CEST)
Bitte, gern geschehen. Übrigens lese ich grad den Anfang des Thread genauer; wenn de-WQ wikiquote heißen soll, dann wäre mw.loader.load(URL) statt importScript() zu benutzen – importScript geht davon aus, dass du innerhalb des Projekts (WP) bleiben würdest. Beste Grüße --PerfektesChaos 20:52, 27. Jun. 2012 (CEST)
Ja, Wikiquote. Ich habe es dort auch geändert. Witzigerweise hat aber die Einbindung dort aus dem "Fremdprojekt" WP mittels importScriptURI noch funktioniert, hier innerhalb WP nicht mehr. ;-) Stepro (Diskussion) 20:59, 27. Jun. 2012 (CEST)

Das Konstrukt document.addEventListener ist zwar nicht auf dieser Schwarzen Liste aufgeführt; gehört aber inhaltlich ebenfalls drauf.

  • Die drei Aufrufe von insert_link_before() kannst du in changeBeschriftungen() integrieren. Die Wirkung ist die gleiche: Du möchtest, dass diese Menüpunkte erst aufgenommen werden, nachdem die Basis-Seite aufgebaut wurde. Dann document.addEventListener wegschmeißen.
  • Wobei das Konstrukt insert_link_before() sich durch eine modernere Standardfunktion WP:GUI #addPortletLink ersetzen ließe.

Das meinte ich mit Vollprogramm; all diese veralteten Geschichten können bei modernen Browsern dazu führen, dass irgendwas nicht funktioniert. Mühsam, den Überblick zu behalten, was mit wem sich wo beißt --PerfektesChaos 21:23, 27. Jun. 2012 (CEST)

Fehler in MathJax

Wahrscheinlich bei der Umstellung auf die Version 1.20wmf6 wurden auch elementare Fehler in der Darstellung von <, >, & im Math-Mode bei der Anzeigemethode MathJax entfernt. Dies konnte ich auf der Projektseite nicht entdecken. Viele Grüße --Christian1985 (Diskussion) 17:04, 4. Jul. 2012 (CEST)

Link zu den Commons-Dateien

Ich kopiere mal von meiner Nutzerdisk, Steak hat mich da auf etwas interessantes aufmerksam gemacht:

Gib mal hier Steak oder einen anderen Name ein. Wo ist da ein Commons-Link? Steak 22:19, 20. Aug. 2012 (CEST)

Du findest ihn hier: Spezial:Dateien/Steak, ich habe ihn Dir mal rot eingekreist: klick --Stepro (Diskussion) 22:31, 20. Aug. 2012 (CEST)
Wenn ich auf deinen Link klicke seh ich ihn auch. Siehst du ihn aber hier? Ich nämlich nicht. Steak 22:34, 20. Aug. 2012 (CEST)
Da ist er nicht da, sollte man vielleicht mal als Bug melden. Wie kommt man auf diese Seite (außer durch Eingabe der URL per Hand)? Ich habe einfach links auf Benutzerbeiträge und dann oben auf Hochgeladene Dateien geklickt. --Stepro (Diskussion) 22:38, 20. Aug. 2012 (CEST)
Wie man auf die Seite kommt? Einfach Spezial:Dateien aufrufen und den Benutzername eingeben! Steak 22:41, 20. Aug. 2012 (CEST)
Das ist interessant. Gerade in Wikiquote und Wiktionary nachgesehen, dort kommt man auf die Seite mit dem ausgefüllten Formularfeld. Das mit dem Commons-Link funktioniert also nur hier bei WP und auch nur, wenn man über den Link auf der Seite der eigenen Beiträge geht. Das ist noch etwas suboptimal. Ich kopiere das hier mal nach Wikipedia Diskussion:Projektneuheiten. --Stepro (Diskussion) 22:45, 20. Aug. 2012 (CEST)
Siehe MediaWiki:Listfiles-summary. Da passt was mit dem #ifeq nicht. --Steef 389 22:53, 20. Aug. 2012 (CEST)
Das ist bekannt, siehe Statement von Umherirrender. --Leyo 00:02, 21. Aug. 2012 (CEST)

Title-Tag beim Bearbeiten

Wer hat eigentlich wann und aus welchem Grund den Seitentitel beim Bearbeiten von "Bearbeiten von PAGENAME" nach "PAGENAME - Bearbeiten" geändert? Bei mehreren Tabs erkennt man nun nicht mehr, bei welchem man auf bearbeiten geklickt hat. Ich habe mir zwar nun einen Hack dafür in die Monobook eingebaut, aber das Motiv wüsste ich trotzdem gerne. --Flominator 19:30, 17. Aug. 2012 (CEST)

Hallo Flominator, verglichen mit dem Ansichtsmodus ist das Lemma im Bearbeitungsmodus mit Anführungszeichen umfasst. So gesehen finde ich diese Änderung sogar ziemlich praktisch, wenn man mehrere Tab zum Bearbeiten offen hat. --Wiegels „…“ 19:49, 17. Aug. 2012 (CEST)
Darf ich zunächst mal dieses Gadget anempfehlen? Du wirst dann wohl keinen Grund zur Klage mehr haben.
Wer wann warum wüsste ich auch, aber heute ist so ein schöner und angenehmer Abend … genießt! --PerfektesChaos 20:03, 17. Aug. 2012 (CEST)
Die Anführungszeichen kommen auch bei der Betrachtung der Versionsgeschichte (da stand doch früher auch "Versionsgeschichte von..." oder so ähnlich im Titel, wenn ich mich nicht täusche?) oder eines diffs. Bitte rückgängig machen, diese Neuerung ist äußerst supotimal. -- Chaddy · D – DÜP – 21:13, 17. Aug. 2012 (CEST)
Ich glaube, das jetzige war ein Kompromis zwischen den Leuten, die die Tabs unterscheiden möchten und den jenigen, die auf ihrem Tab den Seitennamen lesen möchte. Im Archiv von WP:FzW findet sich einiges dazu (Beispiel, da waren aber noch mehr Abschnitte). Der Umherirrende 09:04, 18. Aug. 2012 (CEST)
Inkowik im Mai und Juni. --32X → Autorenngilde № 1 21:23, 17. Aug. 2012 (CEST)

@Chaddy @Flominator:

  1. Bitte probiert einfach mal dieses Gadget aus; ich habe es extra für euch geschrieben. Ganz schlicht die Basisversion mit loader.load einbinden.
  2. Der Sinn der Änderung war gewesen, dass man die unterschiedlichen Seiten im Tab unterscheiden können soll. Ansonsten liest man auf jedem Tab nur „Versionsgeschich…“ – „Versionsgeschich…“ – „Bearbeiten von Lis…“ – „Bearbeiten von Lis…“ – „Bearbeiten von Lis…“.

Sonniges Wochenende --PerfektesChaos 09:54, 18. Aug. 2012 (CEST)

Danke für das Gadget, sieht ganz brauchbar aus. Das bringt allerdings nur angemeldeten Benutzern was... -- Chaddy · D – DÜP – 21:35, 18. Aug. 2012 (CEST)
  • Freut mich, wenn es dir gefällt.
  • Die Angelegenheit schlummerte die letzten sechs Wochen bis gestern.
  • Die dort vorgeschlagenen ANSI-Zeichen könnten in den vier Fällen serienmäßig bei allen Tabs vorangestellt werden; das bekämen auch IP und nicht-JS zu sehen. Das gibt dann aber den nächsten Aufschrei eines Dutzend Widerspenstiger „Was sollen denn plötzlich diese komischen Zeichen? Ich verstehe dieses Sternchen nicht, bloß wieder weg damit!“ – ich habe es längst aufgegeben, es allen genehm machen zu wollen, weil immer drei Leute auf irgendeine Veränderung mit Gebrüll und VM und Beschimpfungen reagieren, während Hunderte einen Vorteil haben.
Schönen Sonntag --PerfektesChaos 09:55, 19. Aug. 2012 (CEST)

Das wurde doch vor ein paar Wochen, als das plötzlich automatisch geändert wurde, ziemlich konstruktiv diskutiert:

Inkowik hatte dankenswerterweise die Mehrheitsmeinung umgesetzt. Wenn es eine noch bessere Lösung gibt, die allen hilft, dann stellt das doch mal vor... Nur keine Angst ;-) --Atlasowa (Diskussion) 14:51, 20. Aug. 2012 (CEST)

Das Problem bei der alten Version war, dass „Unterschied zwischen den Versionen von XYZ“ zu lang für einen Tab ist und man deshalb nicht mehr sehen konnte, um welchen Versionsunterschied es sich handelte. Ich stieß daraufhin die Diskussion auf FZW an, als deren Ergebnis dann die Umstellung durch Xenon erfolgte. Nach einer Anfrage von Orci stellte ich dann auch die restlichen Seitentitel auf diese Benennung um, damit etwas Einheitlichkeit herrscht. Dass die jetzige Version auch ihre Nachteile hat, steht außer Frage, mir fällt allerdings auch keine bessere ein. --Inkowik 14:17, 25. Aug. 2012 (CEST)

mw.util.jsMessage() von gestern

Die seit gestern wirksame Veränderung im Verhalten der „Bubble“-Message-Funktion ist ein Paradebeispiel dafür, wie man es nicht machen sollte.

Erste Hilfe für Skript-Programmierer:

  • Automatisches Verschwinden nach 5 Sekunden deaktivieren:
$( '#mw-js-message' ).trigger( 'mouseenter' );
Unmittelbar nach dem Aufruf von mw.util.jsMessage() in das Skript einfügen.
Simuliert das „Betreten“ der Bubble durch die Maus. Dadurch wird die 5-Sekunden-Eieruhr zurückgesetzt, die man auch manuell mit Mausbewegungen anhalten könnte; dass dies möglich wäre, habe ich allerdings erst dem Quellcode bei gerrit entnehmen können.
Die vorgesehene Funktionalität bleibt ansonsten erhalten. Mangels anderer Bedienungsanleitungen:
  • Mauszeiger in Bubble hält 5-Sekunden-Uhr an.
  • Mauszeiger dann aus Bubble heraus startet 5-Sekunden-Uhr wieder.
  • Klick auf Bubble lässt sie verschwinden.
  • Funktionalität für anklickbare Formulare wiederherstellen (die Programmierer hatten zwar daran gedacht, dass <A>-Links vorhanden sein könnten, aber <FORM> vergessen):
$( '#mw-js-message' ).off();
Ende mit allem Spuk. Vorherige Funktionalität erreicht. Das vorstehende .trigger( 'mouseenter' ) ist trotzdem erforderlich, um die bereits laufende Uhr aktiv anzuhalten.


Die Funktion war in der mw.util als Hilfe für alle Programmierer weltweit angeboten worden, und zwar ohne irgendwelche Einschränkungen.

  • Wenn man wie hier eine neue Funktionalität einführt, dann führt man einen neuen, dritten Parameter ein; eine Zeichenkette mit sinnigen Schlüsselwörtern oder ein Objekt mit key=val. Wer noch die alte Verwendung hat, übergibt somit ein undefined; wer explizit die Anwendung klarstellen will, schickt null. Alle für den neuen Modus geeigneten Anwendungen können ihn dann explizit anfordern, für alle anderen ändert sich nichts.
  • Die neue Programmierung phantasiert Unterstellungen zusammen:
    • Jeder Anwender würde innerhalb von 5 Sekunden die gesamte Nachricht verstehen. – Neben einer Standardinfo kann dies aber eine differenzierte Meldung sein, etwa eine komplexe Fehlersituation und Abhilfe beschreiben.
    • Die Meldung wäre immer so klein, dass sie lediglich den Überschriftenbereich abdecken würde; es gäbe ausschließlich one-liner.
    • Während der Bubble-Lektüre sei die Benutzung anderer Menüfelder wie der Vector-Rollout nicht erforderlich.
    • Formulare würden nie in dieser Box untergebracht.
    • Anwender würden schon wissen, mit welchem Maus-Verhalten sie das Verschwinden der Bubble verhindern können.
  • Eine vorherige deutliche Kommunikation über die fundamentale Änderung im konkreten Verhalten erfogte offenbar nicht; bei mir kam zumindest nichts an.

Für demnächst ist ein „mw.notifaction“ angekündigt/angedroht, das jquery.messageBox ersetzen solle.

Aktueller Bezug: WD:DÜP #Skript zickt rum u.a.


Liebe Grüße --PerfektesChaos 10:47, 30. Aug. 2012 (CEST)

Sinnvoller als irgendwelche komischen Hacks zu verwenden, wäre es, jsMessage nur in den Fällen zu verwenden, für die es gedacht ist, nämlich eine kurze Meldung auszugeben. Wenn man etwas am oberen Rand einfügen möchte, dann sollte man eben auch eine Funktion verwenden, die dafür gedacht ist, etwas am oberen Rand einzufügen, etwa mw.util.$content.prepend(). Siehe auch bugzilla:39699. --Schnark 11:14, 30. Aug. 2012 (CEST)


  • Es war noch nie irgendwo dokumentiert gewesen, dass mw.util.jsMessage() ausschließlich für kurze temporäre Benachrichtigungen vorgesehen sein soll. Vielmehr ist es auch legacy von wikibits::jsMsg() und als solches seit Jahren weltweit im Gebrauch, bei bekannter Funktionalität.
  • Es ist durchaus sinnvoll, alle im Seitenkopf erscheinenden Botschaften und Boxen über eine zentrale Bibliotheksfunktion zu leiten, zu koordinieren und priorisieren und etwa Unwichtiges beim Erscheinen wichtiger Nachrichten auszublenden. Dazu ist auch die zentrale Handhabung von Klassen und Identifizierern notwendig. Im Moment klatscht jeder irgendwas irgendwie irgendwohin: Fehlermeldungen, beiläufige Benachrichtigungen, Formulare, Site-notice, Central-notice, fundraising; von Gadget, Benutzern, lokalem Projekt, weltweit. – mw.util.$content.prepend() kann ich auch; das steht im Quellcode von mw.util.jsMessage(). Dem fehlt allerdings die Möglichkeit der programmatischen Löschung durch Aufruf von mw.util.jsMessage() ohne Parameter; die Verwendung von mw.util.jsMessage() für eine Folgenachricht sorgt auch dafür, dass eine vorangegangene Meldung ausgeblendet wird, was durchaus beabsichtigt sein kann.
  • Zurzeit gibt es offenbar völlige Konzeptions- und Planlosigkeit und nebeneinander her die veralteten wikibits::jsMsg() und jquery.messageBox(), ein angekündigtes mw.notifaction unbekannter Konzeption und Funktionalität und ein mw.util.jsMessage() mit bekanntermaßen “significantly changed” behaviour. Ein Gesamtkonzept und ein Umstellungshinweis, welcher Aufruf mit welchem Parameter in welcher Situation einzusetzen sei, fehlt ganz offensichtlich. Zurzeit ist die einzige verfügbare und nicht veraltete Funktion mw.util.jsMessage().
  • Zu programmieren ist eine Sache; aber dazu gehören dann auch präzise Dokumentation, verständliche Anleitungen, Hinweise auf vorgesehene zukünftige Entwicklungen, Leitfäden zur Umstellung von veraltetem Code und die Entwicklung weitsichtiger Gesamtkonzeptionen – kurz: Informationspolitik.
  • Eine als „Erste Hilfe“ gekennzeichnete Sofortmaßnahme innert einer guten Stunde hat nicht den Anspruch, eine konzeptionelle Lösung für die nächsten Jahre zu sein.
Beste Grüße --PerfektesChaos 13:14, 30. Aug. 2012 (CEST)
Dokumentiert ist das schon, wenn auch etwas dürftig: mw:RL/DM#jsMessage verweist auf die legacy-Funktion, diese ist im Quelltext dokumentiert: Add a cute little box at the top of the screen to inform the user of something, replacing any preexisting message. Die Wendung cute little sollte eigentlich jedem, der mehr als zwei kurze Sätze damit anzeigen will, zu denken geben, die Warnung, dass die Meldung einfach so verschwinden kann (ursprünglich nur, wenn eine neue Meldung kam, jetzt eben auch nach 5 Sekunden ohne ein durch den Mauszeiger bekundetes Interesse) gab es auch schon immer. --Schnark 09:28, 31. Aug. 2012 (CEST)


  • Unter der Dokumentation einer öffentlich sichtbaren und zur allgemeinen Benutzung angebotenen Bibliotheksfunktion verstehe ich mw:ResourceLoader/Default modules #jsMessage. Dort heißt es: “keeping it fully backwards compatible” (was definitiv falsch ist) und über autohide, bubble oder schmale Breite wird dort bis heute keine Silbe verloren. Selbst wenn man in den Quelltext guckt, heißt es als Kommentar nur “Add a little box at the top of the screen to inform the user of something”. Dass diese Meldung eine vorangegangene überschreibt und damit durchaus beabsichtigt eine Fehlermeldung eine relativ unwichtige Nachricht entfernt, war immer bekannt (mw: "replace/add the message on top") und ist völlig okay; war auch in wikibits der Fall. Nicht okay ist, dass auch wichtige Meldungen nach 5 Sekunden wieder verschwinden, weil jetzt per se weltweit alle Nachrichten als eigentlich bedeutungslos eingestuft wurden. Nicht okay ist weiterhin, little und cute hin oder her, dass als Breite 20 Anschläge (width:20em) unkonfigurierbar fest vorgegeben wurden. Obendrein vergaß man RTL, da direction sich nicht auf right auswirkt.
  • Es kann ja nicht ernst gemeint sein, dass man den Quelltext des veralteten wikibits.js heranziehen muss, um zum Wort cute zu gelangen, und aus dieser Niedlichkeit herauszuinterpretieren, dass zukünftig beabsichtigt wäre, die einzige Bibliotheksfunktion sei nur für prinzipiell unwichtige, kurz aufscheinende Miniaturmeldungen einsetzbar.
  • Es wäre alles fein, wenn die Funktionsänderung von einem Optionsparameter begleitet wäre, mit der diejenigen Anwendungen die neue Funktionalität explizit anfordern, die dafür auch geeignet sind.
  • Wo hatte man eigentlich das neue Verhalten für die Anwender (und die Notwendigkeit für Benutzer, mit dem Mauszeiger auf dem Sprung zu sein) im Vorfeld kommuniziert und dokumentiert?

My anticipation of a universal library function, also regarding the announced mw.notification:

Library function
parameter value meaning
priority high,
none,
low,
temp,
... 		occurrence issued by content
none all pages, over days site Advertising (poll, questionary, donate)
centralnotice sitenotice fundraising
Do not show if any other message activated.
May be assigned to a class="mw-message-neglectable" which will be none-displayed by any other call.
high all pages, breaking shutdown
show always
high all pages usermessage (unvisited change on talk page)
show always
high particular situation editnotice etc.
show always
May be undisplayed individually by CSS
temp particular situation Please wait: throbber, hour glass
To be discarded when finished.
low particular situation Requested action done.
high particular situation gadget Error in page; user dialog, form
vertical Default: auto space above content
  • non-important (informative) messages must not be placed on top of important messages
  • no message is permitted to be placed above drop-down menus like vector content actions.
true layer on top
hideauto Default: keep  
true standard timeout (5 seconds)
Number of seconds
width Default: auto entire
true standard bubble size ("20em")
String CSS length
aside Default: auto no alignment
true close to opposite border ("1em") LTR: right:aside; – RTL: left:aside;
String CSS margin-width
identifier String optional ID for later referencing

Coordination of multiple boxes expected. “Bubble” would be covered by: 

{ priority: 'low',
  vertical: true,
  hideauto: true,
  width:    true,
  aside:    true
}

Greetings --PerfektesChaos 21:35, 2. Sep. 2012 (CEST)

 Info: Werft mal einen Blick auf Gerrit:19199. Wird vermutlich mit MediaWiki 1.12wmf11 kommen. — Raymond Disk. 22:14, 2. Sep. 2012 (CEST)

Ich finde die visuellen Änderungen der neuen Anzeige gut und für die typische Verwendung beim Hinzufügen zur Beobachtungsliste passend. Einen Fehler mit RTL/LTR kann ich nicht nachvollziehen. --Fomafix (Diskussion) 22:29, 2. Sep. 2012 (CEST)
  • I am really looking forward to see the new mw.notification on stage and working. Moreover, I’m curious about the documentation page.
  • Ich habe nichts gegen die Bubble, und sie mag etwa für die Beo sinnvoll sein und man möge sie verwenden. Ich habe etwas dagegen, dass man die Wirkung einer seit Jahren weltweit und in unübersehbarer Vielfalt eingesetzten Funktion plötzlich und ohne irgendeine Vorwarnung verändert. Wenn man eine significantly geänderte Funktionalität einführt, setzt man einen Steuerparameter. Diejenigen Anwendungen, die wie watchlist für die Änderung geeignet sind, ergänzen explizit den Steuerparameter; für den Bestand hat es keine Auswirkungen. Mit einer Umstellung auf Aufrufe von mw.notification wäre exakt dieser Effekt erreicht worden; da man ja schon wusste, dass dies unmittelbar bevorsteht, war die Veränderung in 1.20wmf10 übereilt gegen Migration mittels 1.20wmf11.
  • RTL: Es gibt irgendwo einen schlauen Mechanismus, der die Skin-Seiten RTL-spiegelt. Dieser greift offenkundig nicht für die dynamische mw.util.jsMessage. CSS-Angaben wirken nur auf die Schreibrichtung von Zeichenfolgen, nicht aber auf absolute position. Ein Leser und Autor der hebräischsprachigen WP, der gleichzeitig auch Leser und Autor der enWP ist, sieht die Bubble offenbar über dem Globus und am Zeilenanfang im Mittelpunkt des Interesses, während sie in der LTR-Welt am Zeilenende steht und jetzt ja alle Nachrichten automatisch als wenig wichtig eingestuft wurden.
VG --PerfektesChaos 10:18, 3. Sep. 2012 (CEST)
Ich gebe Dir recht, dass die Einführung etwas unglücklich war.
Bezüglich RTL/LTR kann ich keinen Fehler finden:
Das ist meiner Meinung nach auch das richtige Verhalten. --Fomafix (Diskussion) 10:27, 3. Sep. 2012 (CEST)
@RTL: Okay, in dem Punkt hatte ich mich getäuscht.
  • bits/he/shared.css nennt unter div#mw-js-message die position:absolute;right:1em; – man hatte mir mal eingebleut, dass auch bei RTL dieses right echt rechts bliebe. So eigentlich auch CSS@W3C. Wie ich mich überzeugen konnte, erscheint es trotzdem links; durch welchen übergeordneten dir-Zaubertrank auch immer. Ich weiß schon, warum ich einen Bogen um RTL pop-bidi mache.
Unter Aufrechterhaltung meiner Kritik im Übrigen LG --PerfektesChaos 13:48, 3. Sep. 2012 (CEST)
Wenn Du die Sprache auch den richtigen Wert hat, dann flippt der Ressource Loader auch: bits/he/shared.css. --Fomafix (Diskussion) 14:04, 3. Sep. 2012 (CEST)
Uff! Das ist dieser Zauber-Mechanismus, den ich irgendwann im PHP mal gesehen hatte; soso, im RL war das. Wieder was gelernt, und mit position:absolute muss ich auch nicht umlernen. Schönen Tag --PerfektesChaos 14:28, 3. Sep. 2012 (CEST)
Das Flippen wird mit CSSJanus gemacht und kann mit @noflip unterbunden werden, wie es für einige Anweisungen in MediaWiki:Common.css gemacht wird. Der Umherirrende 17:57, 3. Sep. 2012 (CEST)

Vielleicht interessiert und motiviert das ja: Lob für Bubbles. Gruß, eryakaas | D 15:04, 6. Sep. 2012 (CEST)

  • Es geht nicht darum, ob mir die Bubble gefällt; ich finde sie für die Beo ja auch ganz nett.
  • Es geht darum, dass die einzige stabile Bibliotheksfunktion zu diesem Thema ihr Verhalten radikal verändert hat und bei sämtlichen Anwendungen alle Nachrichten nach 5 Sekunden wieder verschwinden lässt. Das ruft bis heute nicht behobene Unbrauchbarkeit von Skripten hervor, so beispielsweise hier.
  • Korrekt wäre es gewesen, wenn die Beo-Funktion eine neue Funktion wie irgendein mw.notification verwendet oder explizit anfordert „Als bubble darstellen“. Für diejenigen Anwendungen, die eine nebensächliche Nachricht haben, ist das dann völlig okay. So sind aber pauschal alle existierenden Benachrichtigungen in jedem Zusammenhang als unwichtig erklärt worden.
VG --PerfektesChaos 20:17, 6. Sep. 2012 (CEST)
Meine Info war nicht als Beschwichtigung für eure Probleme gedacht, sondern ich wollte einfach auf das auf der HS-Disk ausgesprochene Lob hinweisen und es an die weitergeben, die es wirklich angeht. eryakaas | D 00:07, 7. Sep. 2012 (CEST)

Fußnotenblase

In der englischsprachigen Wikipädie sah ich gerade, als ich über eine Fußnote fuhr, eine Blase aufpoppen, die mir den Inhalt der Fußnote anzeigte. Kann ich das hier bitte auch haben? --32X → Autorenngilde № 1 15:27, 6. Sep. 2012 (CEST)

Wird gerade getestet: Du kannst es aktivieren unter Einstellungen, Helferlein, Lesehilfen, letzter Punkt. Diskussion ist unter WP:VV#MouseOver bei Einzelnachweisen. --χario 15:30, 6. Sep. 2012 (CEST)
bitte nicht noch mehr zwangseinstellungen; abschaltmöglichkeit über die einstellungen wäre wünschenswert.--Pm (Diskussion) 17:05, 6. Sep. 2012 (CEST)

Preprocessor generated node count

Es wurde ein neues Limit für Seiten eingefügt, um den Speicherbedarf im Hauptspeicher beim Parsen zu reduzieren. Infos auf der Mailingliste Wikitech-l. Hat das jemand verstanden, um das vorne als kurze Info hinzuschreiben? Ich bin mir nicht sicher, ob wir eine solche Seite haben und wie die sich dann verhält. Der Umherirrende 20:14, 21. Sep. 2012 (CEST)

Verstanden hätte ich es schon; „ein Limit von etwa einer Viertelmillion Fallunterscheidungen mit #switch wurde eingeführt“ könnte man vorn schreiben.
Eine solche Vorlage haben wir wohl eher nicht, aber Geo habe ich als arbeitsintensiv in Erinnerung.
Die Kollegen werden in ihrem Bistro französisch parliert haben; aber es wäre interessant die Programmierpraktik zu verstehen, um sie selbst vermeiden zu können. Die gesammelte Vorlage habe 37000 switch-Fälle unterschieden und sei in einen Artikel 15-mal eingebunden gewesen.
LG --PerfektesChaos 20:45, 21. Sep. 2012 (CEST)
Die „Programmierpraktik“ ist genau die, die sich hier bei uns „Metadatenvorlagen“ nennt. Ich finde das gerade reichlich amüsant, dass genau diese Bedenken, die immer schon geäußert und meist für unbegründet erklärt wurden, jetzt sogar zur Einführung eines neuen Limits geführt haben. Natürlich ist auch das kein Grund, Metadatenvorlagen zu verteufeln, denn es kommt sehr auf die Art und Weise an, wie (tief) solche Switch-Konstrukte letztendlich eingebunden sind. Mit unseren Koordinaten-Vorlagen haben wir dieses Problem jedenfalls nicht. Dafür kratzen sehr viele unserer Artikel an der Highest expansion depth, die nur bis 40 geht. --TMg 20:59, 21. Sep. 2012 (CEST)

x neue Nachrichten von y Benutzern

WP:NEU#29. August: Der Benachrichtungsbalken zeigt nun an, von wievielen verschiedenen Benutzern Nachrichten vorliegen.

Sehe ich das richtig, daß das nicht funktioniert? Wurde das zurückgezogen? bugzilla:12701#c37 erwähnt einen Revert, der aber vom 11. August ist? Gruß --Schniggendiller Diskussion 00:05, 21. Sep. 2012 (CEST)

Diser Revert wurde wieder verworfen, sodass die Anzeige eigentlich weiterhin funktionieren sollte. Wenn sie es nicht tut, dann liefere ein Beispiel dafür, was fälschlicherweise angezeigt wird, inklusive der verwendeten Nachricht (?uselang=qqx an die URL anhängen). --Schnark 09:15, 21. Sep. 2012 (CEST)
Ich hatte auch schon das Gefühl, das es nicht funktioniert, weil die URL auch keine id enthält, sondern mit diff=cur arbeitet, was eigentlich sich ändern sollte. Ich habe aber auch unter wikitech:Schema changes gelesen, das da etwas von "Fix schema inconsistency" für user_newtalk table steht. Man könnte per Bug nachfragen oder im IRC, was aus dem ticket geworden ist. Der Umherirrende 15:13, 21. Sep. 2012 (CEST)
Bei mir ergab das youhavenewmessages = „Du hast eine neue Nachricht auf deiner Diskussionsseite.“ --Leyo 16:09, 21. Sep. 2012 (CEST)
Kann ich bestätigen: URL mit diff=cur, die verwendete Nachricht ist MediaWiki:Youhavenewmessages mit dem Text „Du hast eine neue Nachricht auf deiner Diskussionsseite.“ (obwohl ich heute weit mehr als nur eine Nachricht von einem Benutzer hatte). Daß die neuen Nachrichten in verschiedenen Abschnitten stehen, macht keinen Unterschied. Getestet mit Vector und Monobook. Gruß --Schniggendiller Diskussion 18:58, 23. Sep. 2012 (CEST)
 Info: Nummer 40512 für die Nachfrage gezogen. Der Umherirrende 20:59, 25. Sep. 2012 (CEST)

Nur zur Info: Wikipedia jetzt auf Schweizer Hochdeutsch

Die deutschsprachige Wikipedia besitzt nun nach einigen Vorbereitungen eine auf das Schweizer Hochdeutsch angepasste Benutzeroberfläche.

Was diese beinhaltet und wie diese Oberfläche aktiviert wird, ist auf Wikipedia:WikiProjekt Schweiz/Benutzeroberfläche beschrieben. Feedback ist auf der Diskussionsseite gerne willkommen.

Dazu beigetragen haben direkt oder indirekt, bewusst oder unbewusst, Benutzer:Geitost, Benutzer:Umherirrender, Benutzer:Leyo und andere; Raymond hat jetzt das noch letzte Mosaiksteinchen dazu geliefert. Allen herzlichen Dank! --Filzstift ✎ 10:42, 4. Okt. 2012 (CEST)

Wenn HTML5 bedeutet

... dass jetzt u.a. alle align-Attribute aus Tabellen gekillt werden, dann nein Danke. Nein, die CSS-Angabe text-align ist kein gleichbedeutender Ersatz für das align-Attribut. Kann man dieses Umschreiben von align nach text-align, das jetzt scheinbar zwangsweise passiert, bitte wieder abschalten? --TMg 03:19, 18. Sep. 2012 (CEST)

Hier die konkreten Fälle, die bisher funktionierten (auch in sehr alten Webbrowsern) und jetzt entweder gar nicht oder inkonsistent und alles in allem halbgar umgesetzt werden.

Ein für die ganze Tabellenzeile gesetztes align="center" wird gelöscht. Das war und ist ein üblicher Anwendungsfall sowohl in Vorlagen als auch Artikeln.
Beispiel
Ein für die einzelne Tabellenzelle gesetztes align="center" wird ungefragt in text-align: center geändert, obwohl das nicht gleichbedeutend ist.
Beispiel
Witzigerweise bleibt <center> unangetastet. Dann verstehe ich wirklich nicht, warum an align herum gefummelt wird, statt es genauso 1:1 an die Webbrowser weiter zu reichen.

Jeder Webbrowser muss und wird noch viele, viele Jahre in der Lage sein, align zu interpretieren. Warum muss das Attribut jetzt ausgelöscht werden, und dann auch noch so inkonsistent und fehleranfällig? --TMg 04:17, 18. Sep. 2012 (CEST)

Mir scheint das Parsing von align=center etwas seltsam. In einer Tabellenzelle wird es weiterhin akzeptiert (HTML-Tag <td> bzw. die Pipe | bei MediaWiki), in einer ganzen Zeile hingegen nicht mehr (<tr>, |-). Vermutlich wird der Fehler beim Parser liegen, der schon immer HTML-Tags zerflückte und neu zusammensetzte (damit auch <br> </br> <br /> … alle die gleiche fehlerfreie Ausgabe liefern). --32X → Autorenngilde № 1 09:41, 18. Sep. 2012 (CEST)
Als Bug #40329 gemeldet. --TMg 16:17, 18. Sep. 2012 (CEST)
Vorlage:Infobox Partei Schweiz (Beispieleinbindung: Alternative Linke) - Das sieht z.B. auch hier kotzhässlich aus, weiss nicht was diese MediaWiki-Programmierer eigentlich studieren. Bin zwar auch ein Befürworter von klaren Standarts, aber sicher nicht so! fundriver Was guckst du?! Winterthur! 12:03, 29. Sep. 2012 (CEST)
Ich habe mal ein paar kleine Änderungen an der Vorlage vorgenommen, das Logo ist jetzt wieder zentriert, wenn man weiß, was ich gemacht habe, kann man minimale Änderungen im Aussehen feststellen, aber ich vermute und hoffe, dass sich daran niemand stört. --Schnark 11:51, 1. Okt. 2012 (CEST)
In diesem Fall ist das simple Ersetzen durch text-align: center; sogar korrekt, da das Logo in dieser Infobox (hoffentlich) überall so eingebunden ist, dass nur HTML-Elementen entstehen, die der Eigenschaft text-align zugänglich sind (konkret entsteht <td style="text-align: center;><p><a><img /></a></p></td>). Wie gesagt: Hoffentlich. Diese Infobox ist ein Beispiel für einen Fall, der in einem Bildparameter jegliche Syntax erlaubt, beispielsweise auch die Vorlage:Doppeltes Bild. Das muss jetzt zwangsläufig fehlschlagen. Die Bildvorlage umzubauen, behebt das Problem nicht, da jeder Benutzer jederzeit unendlich viele neue Fälle konstruieren kann, die dann wieder nicht zentriert werden. Ein simples align="center" wäre deshalb deutlich robuster als das jetzt eingesetzte ach so „standardkonforme“ style="text-align: center;" und damit in gewisser Weise sogar zukunftssicherer. Aber nein, es ist ja wichtiger, in obskuren HTML5-Validatoren zu punkten. Ähnlich liegt der Fall beim cellpadding, das ich wieder in die Vorlage eingefügt habe, weil es keine sinnvolle Alternative dafür gibt, außer jede einzelne Tabellenzelle dutzendfach redundant mit einem style="padding: 2px;" zu schmücken. Abschließend lieferst du (nichts für ungut) ein weiteres Argument für die Beibehaltung des schlichten align="center". Wenn nämlich selbst Benutzer wie du die Empfehlung, das missbilligte align="center" durch margin: auto; zu ersetzen, so missverstehen, dass margin in die Tabellenzelle eingesetzt wird, wo es gar keine Wirkung haben kann, wie soll das dann der durchschnittliche MediaWiki-Benutzer begreifen? Das margin müsste auf das Bild angewandt werden. Im Fall dieser Vorlage, die Bilder nicht per Dateiname sondern in vollständiger Syntax erwartet, würde das bedeuten, das margin in die Artikel einfügen zu müssen. Mit anderen Worten: Das faktische Verbot, die align-Eigenschaft weiterhin zu verwenden, zieht in letzter Konsequenz auch ein Verbot von Konstruktionen wie bei der Vorlage:Infobox Partei Schweiz nach sich. Ob das gut oder schlecht ist, will ich gar nicht festlegen. Von mir aus können HTML-Altlasten wie das unsägliche <center>, bei dessen Anblick ernsthaften Webentwicklern schon vor 10 Jahren die Nackenhaare zu Berge standen, liebend gern getilgt werden. Aber dann bitte konsistent und mit einem Plan, der mit der Community abgesprochen ist und der nach einer überschaubaren Zeit zum endgültigen Verschwinden dieses Mülls führt, und nicht so ein vollständig sinnfreies Gemurkse mit magical transformations wie jetzt. --TMg 17:22, 1. Okt. 2012 (CEST)
Wikipedia:Fragen_zur_Wikipedia#Darstellungsfehler_Infobox_Element --Wickie37 15:58, 4. Okt. 2012 (CEST)

PostEdit * Syntaxfehler

Wrt extensions/PostEdit/resources/ext.postEdit.js

Here: static-1.21wmf1

Would the developers please be so kind and remove the space between ! and == ASAP? And refresh immediately bits.wikimedia.org? You are crashing my scripts. Thx. 

function isPostEdit() {
   return (( document.referrer.indexOf( 'action=edit' ) !== -1 ||
             document.referrer.indexOf( 'action=submit' ) ! == -1 ) &&
             mw.config.get( 'wgPostEdit' )
           );

Btw, on top of the extension there is a helpful … 

/*jslint browser:true, white:true */
/*globals mediaWiki:true */

… Expected an operator and instead saw '!'.

deWP-Kollegen: Bugzilla is welcome. Greetings --PerfektesChaos 14:19, 23. Okt. 2012 (CEST)

gefixt/geändert ist es schon seit Freitag(siehe [6]), weiß aber nicht, ob es vor php-1.21wmf2 deployed wird.
October 22 21:17 logmsgbot_: olivneh synchronized php-1.21wmf2/extensions/PostEdit

--se4598 / ? 15:36, 23. Okt. 2012 (CEST) 

14:32 logmsgbot_: reedy synchronized php-1.21wmf1/extensions/PostEdit 'Update PostEdit to master'

siehe static-1.21wmf1. Die entsprechende Funktion existiert somit nicht mehr... (Versionsgeschichte der Extension) --se4598 / ? 16:59, 23. Okt. 2012 (CEST)

@PerfektesChaos: I'll forward this on to the maintainers of the extension for review. In the meantime, when you have immediate changes you want to see that you think are necessary, you're always welcome to submit a patch in Gerrit. (Here's where to request access, if you don't have it.) Steven (WMF) (Diskussion) 18:27, 23. Okt. 2012 (CEST)

Thank you, I am able to continue my development now. I have been looking for a bug within my own stuff for some days now, when I grasped that message today. I learnt that regular deployment of 1.21wmf2 is scheduled for tomorrow anyway. Greetings --PerfektesChaos 22:01, 23. Okt. 2012 (CEST)

„Deine Bearbeitung wurde gespeichert“ blockiert Mausklicks

Würde bitte jeder, der heute das Gefühl hatte, dass Mausklicks auf irgend einen der Tabs („Versionsgeschichte“ usw.) und Links oben rechts in der Fensterecke („Eigene Diskussion“ usw.) verschluckt wurden, einen Kommentar auf bugzilla:41231 hinterlassen? Die glauben mir das nicht. --TMg 01:04, 24. Okt. 2012 (CEST)

Ist mir noch nicht passiert (ich nutze aber auch nicht den Vector-Skin). --Mogelzahn (Diskussion) 15:13, 24. Okt. 2012 (CEST)
Ich kanns mit den perm-Links nachvollziehen mit FF16 und Monobook. Daneben auch für Chrome 22.0.1229.94 und Opera 12.02 mit Vector. --darkking3 Թ 08:08, 25. Okt. 2012 (CEST)
Ich bekam/bekomme gerade mehrfach beim puren Seitenwechsel (bzw. beim Bearbeitungsklick hier zur Meldung des Bugs) die Hinweisblase, dass meine Bearbeitung gespeichert wurde. Mein Browser (Firefox 16.0.1) frisst zwar gerade gut Ressourcen, dennoch sollte der JS-Codeschnipsel nicht einfach ausgeführt werden und mir eine falsche Bestätigung anzeigen. So kehrt sich die Einführungsbegründung „das erwartet man von Web2.0-Seiten“ ins Gegenteil. --René Mettke 16:07, 26. Okt. 2012 (CEST)
Das höre ich zum ersten Mal. Das Ding ist von einem Cookie abhängig. Kannst du mal schauen, ob das Cookie bei dir vielleicht permanent gesetzt ist und nicht gelöscht werden kann? Das wäre eine mögliche Erklärung. --TMg 23:40, 29. Okt. 2012 (CET)

Wikipedia:Projektneuheiten/Tech blog

Zur Info: Ich habe mal eine Seite mit den letzten 5 Einträgen des Tech blogs angelegt. Diese Seite wird durch einen Bot aktualisiert. So kann man über neue Einträge dort auf der Beobachtungsliste informiert werden. Die Aktualisierungen scheinen aber als Bot markiert zu werden, so dass es für Personen, die so etwas standardmäßig filtern, wohl nicht praktikabel ist. Aber vielleicht gefällt es anderen. Der Umherirrende 21:21, 29. Okt. 2012 (CET)

y: für Wikivoyage

Tja;

unter curid=1072345 haben wir Y: The Last Man.

D: sehe ich grad nicht.

Enjoy. --PerfektesChaos 20:16, 10. Nov. 2012 (CET)

Ist verschoben nach Y - The Last Man.
Der Umherirrende 20:42, 10. Nov. 2012 (CET)
Wobei es jetzt voy für wikivoyage geworden ist. Es kann gerne wieder zurückgeschoben werden, wenn das der besser Name ist. Der Umherirrende 21:37, 10. Nov. 2012 (CET)
Verblüffend. Vor einer halben Stunde landete Y: The Last Man noch auswärts. So schnell kann ich meine Skripte ja gar nicht anpassen, wie das weltweit im Zickzack geht. Irgendwie habe ich mehr und mehr das Gefühl, dass mit den Updates im Wochentakt das nicht zu Ende gedachte Gehudel allmählich zunimmt. --PerfektesChaos 22:04, 10. Nov. 2012 (CET)
Das glaube ich dir. gerrit:32751 wars. Hier könnte dir höchstens die API helfen, weil das Ergebnis sollte wohl up to date sein. Ich habe übrigens zurück verschoben, falls es interessiert. Der Umherirrende 22:07, 10. Nov. 2012 (CET)

Patrol-Link plötzlich wieder da?!

Moin, als ich gerade Wikipedia Diskussion:Mentorenprogramm/Abstimmungen/Leoll aufrief, stand am Seitenende plötzlich der Link [Seite als kontrolliert markieren], den ich auch sogleich genutzt habe. Der wird doch eigentlich in Wikimedia-Projekten ausgeblendet (weil die Funktion durch die gesichteten Versionen praktisch ersetzt wurde). Hat sich daran was geändert? XenonX3 - (☎) 21:43, 15. Nov. 2012 (CET)

Die Stylesheets werden anscheind im Moment nicht richtig ausgeliefert, siehe auch WP:FZW#Fehlerhaftes Facelift? Wikipedia-Ansicht ist zusammengebrochen!. Der Umherirrende 21:50, 15. Nov. 2012 (CET)

Feedback-Tool

Bin ich blind oder wurde vergessen, die Aktivierung des AFT umseitig zu vermelden? XenonX3 - (☎) 23:09, 17. Dez. 2012 (CET)

Der eigentliche Start ist nicht eingetragen afais, aber die Aktivierung auch für IPs ist drin. – Giftpflanze 18:50, 18. Dez. 2012 (CET)
Abgerufen von „https://de.wikiup.org/index.php?title=Wikiup_Diskussion:Projektneuheiten/Archiv/2012&oldid=223330318“