Benutzer Diskussion:Schnark

Automatische Archivierung

Auf dieser Seite werden Abschnitte sonntags automatisch archiviert, deren jüngster Beitrag mehr als 30 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Die Archivübersicht befindet sich unter Archiv. Das momentan verwendete Archiv ist Archiv 1.

mea culpa, mea ∞ culpa

Betrifft: Deine Recherchen nach Leerzeichen als Sortierschlüssel: Ich war’s.

• Du hattest Arbeit und Mühe gehabt, detektivisch dem Kategorie-Bug nachzugehen, und Benutzer andiskutiert. Sorry und danke.
• Leider war das flag iwcat, das den Sortierschlüssel schützen soll, in den fraglichen Fällen zu spät/garnicht gesetzt worden, so dass der Klammerinhalt im weiteren Verlauf als normales Wikilink einer Rasur schließender Leerzeichen zum Opfer fiel, weil ja whitespace folgt. Es sind deshalb nur die Fälle betroffen, in denen der Sortierschlüssel ein einzelnes Leerzeichen ist. Weil damit die Situation [[xyz:abc|]] entstand, die durch göttliche Interpretation unseres Parsers eine Abkürzung für [[xyz:abc|abc]] ist und ich dies zur besseren Verständlichkeit danach expandiere, steht dort jetzt jeweils [[Kategorie:Kkkk|Kkkk]].
• Du warst ja vor einem knappen Jahr mal auf der Suche nach einer Kategorie:Mann|Mann – darf ich davon ausgehen, dass du einen Dump zur Hand hast, in dem du die fraglichen Artikel identifizieren kannst? Da du ja auch die Benutzer identifizieren konntest? Wenn du mir eine Liste verdächtiger Artikel aufschreiben könntest, analysiere und berichtige ich die fraglichen Artikel natürlich selbst.
• 1.4 uploaded (Cache) … nach kurzem Anlauftest werde ich auf die Suche nach den Benutzern gehen und informieren.

sorry for trouble and inconvenience --PerfektesChaos 16:44, 12. Sep. 2010 (CEST)

Du bist überhaupt nicht an allem Schuld. Vielleicht an den zwei Fehlern, die Jodo passiert sind, aber der Rest waren Altlasten von WikEd, ein Modul aus PDDs Monobook oder Unkonzentriertheit menschlicher Bearbeiter. Bei mir trat dieser Fehler übrigens noch nie auf (das hatte ich auch mal explizit getestet) und auch jetzt ohne den Cache zu leeren, tut dein Skript bei mir genau das, was es soll. Meine Liste, nach der ich vorgehe, entstand natürlich mit zgrep und dem XML-Dump, ist aber inzwischen fast leer, sofern dir nicht die Nebenflusstiefe von Arroyo San Martín bekannt ist, gibt es nicht viel, wo du noch helfen könntest. Wenn es dir nur ums Analysieren geht, kannst du einfach meine Bearbeitungen vom Samstag durchgehen. Viele Grüße --Schnark 09:24, 13. Sep. 2010 (CEST)

Du darfst natürlich trotzdem die verbliebenen Seiten anschauen: Lucca ([[Kategorie: Lucca| Lucca]]), Dili (Distrikt) ([[Kategorie:Dili|Dili]]), Charles de Gaulle (R 91) ([[Kategorie:Charles de Gaulle|Charles de Gaulle]]), Kategorie:Bremer Organisation ([[Kategorie:Organisation (Freie Hansestadt Bremen)|Organisation]]), Star Wars (Arcade-Spiel) ([[Kategorie:Star Wars|Star Wars]]), Wikipedia:WikiProjekt Himmelskörper ([[Kategorie:WikiProjekt Himmelskörper|WikiProjekt Himmelskörper]]), Vorlage:Navigationsleiste Eparchien der Bulgarisch-orthodoxen Kirche ([[Kategorie:Bulgarisch-Orthodoxe Kirche|Bulgarisch-Orthodoxe Kirche]]), Arroyo San Martín ([[Kategorie:Flusssystem Río Uruguay|Flusssystem Río Uruguay]]), Kategorie:Person nach Person ([[Kategorie:Person|Person]]) Es sind aber auch einige dabei, bei denen das alles so passt. --Schnark 10:50, 13. Sep. 2010 (CEST)

• Na, da bin ich ja beruhigt und erleichtert.
• Zu der kuriosen Geschichte:
  • Mittlerweile habe ich herausgefunden, dass in bestimmten Situationen mein schützendes iwcat-Flag fehlerhaft die Kategorie nicht semantisch als solche markierte, dies aber keinerlei Folgen für den Wikitext hatte, weil diese Situation gerade nur die ohne Angabe eines Sortierschlüssels oder eines leeren Sortierschlüssels war. Mit einem Leerzeichen als Sortierschlüssel aber passierte von meiner Seite aus nix.
  • Deshalb bekommen wir zwei beiden von der Geschichte auch garnichts mit.
  • A: Jodo hat eine Kopie der PDD:monobook, in der steht importJavascriptL('BLueFiSH.as/JS/markup' und führt die vor mir aus – kam also ohne Leerzeichen bei mir an.
  • Weil ich das semantisch nicht richtig klassifiziert hatte, behandelte ich es als normales Wikilink und expandierte auch [[foo:bar|]] zwecks Verdeutlichung zu [[foo:bar|bar]] statt meiner Gewohnheit nach auch noch das überflüssige Pipe-Symbol eines leeren Sortierschlüssels einzukassieren.
  • B: Es ist aber Gewohnheit des Servers (nicht von WikEd, Test als IP auf der Spielwiese), zur Verständlichkeit (intern bereits in der Diffpage sichtbar) Wikitext mit [[foo:bar|]] als [[foo:bar|bar]] abzuspeichern (habe ich zumindest nicht gewusst, war wohl Anfang des Jahres auch noch nicht so).
  • Ich hätte es also doch nicht verhindern können, weil nicht das schon fehlende Leerzeichen wiederbringen können – trotzdem eine Fehlfunktion.
    Auswirkung wäre aber zurzeit nur gewesen:
    • Jede Kategorie beginnt auf neuer Zeile wäre nicht repariert worden.
    • Zukünftig wäre nicht repariert worden: Kategorie doppelt
    • und in ganz ferner Zukunft die Anordnung in Blöcken

      {{SORTIERUNG}}

      [[Kategorie:

      {{PD}}

      {{Link}}

      [[interwiki:

      identifizieren und ggf. umsortieren

  • C: Ursache für meinen bug war ein mir zwar irgendwie im Hinterkopf waberndes JavaScript-Phänomen: Eine leere Zeichenkette s=""; gilt in C, C++, C#, Java als "allokiert und Speicherplatz beanspruchend", damit liefert die Abfrage if (s) in den mir noch länger vertrauten Sprachen "wahr", in JavaScript unter dem gegenwärtigen Firefox "falsch". Die Standards zu JavaScript/ECMA erwähnen dieses Phänomen nicht. s selbst ist damit aber nicht null oder '\0', denn s.length gibt es noch und s.concat("a") ergibt s="a" – s ist allokiertes Objekt, aber halt vom internen JavaScript-Spezialtyp String. Anfang des Jahres hatte ich diesen Mist schon mal. s2=new String(); ist dagegen auch nichts anderes als "", aber if (s2) ist in meinem Firefox "wahr". Das verstehe wer will.
  • D: Deine Wochenend-Edits und Benutzer-Anfragen hatte ich bereits Sonntag abend analysiert gehabt und ziemlich gerätselt – die Bearbeiter hatten mein Skript nicht eingebunden und (falls nicht gelöscht) noch nie ein js-Benutzerskript. Außerdem hatte ich im Juli eigentlich mit über 1000 Artikeln getestet, in der vorangegangenen Entwicklung war der leere Sortierschlüssel (wie auch das einzelne Leerzeichen) ein expliziter Testfall und führte damals planmäßig zur Entfernung des Pipe-Symbols; der bug stammt wohl aus dem August.
  • Als ich Sonntag nachmittag hurtig auf Fehlersuche war und den iwcat-Fehler fand, hatte ich das Problem erstmal bei mir selbst gesehen; beim Austesten mit Jodos wallonischem Schlagzeug kam ich wohl mit den diversen Versionen und vorher/nachher durcheinander.
• Wieviele Leichen haben wir denn noch im Keller?
  • E: Es wäre dienlich, wenn du vorbeugend deinen Dump durchgrabbelst nach: \[\[Kategorie:.+\|\]\]
  • Das wären dann die ehemals einzelnen Leerzeichen, die schon irgendwie abhanden kamen und mit der nächsten Abspeicherung expandiert würden (falls es ein halbes Jahr unbearbeitete Artikel gäbe).
• F: WikEd
  • Hier würde ich Dich um Aufklärung bitten – gibt es irgendwelche verborgen ablaufende automatisierte Syntaxkorrektur? Das wäre für mich als Entwickler fatal, wenn klammheimlich parallel ein anderer Algorithmus den wikitext zwirbelt; das [[foo:bar|]] ist schon confusing genug.
  • Die WikEdFix*** habe ich mit kollegialem Interesse gelesen. Das sind ja offenbar die Buttons zwischen Suchen/Ersetzen und Textarea, und wenn die manuell lokal unter optischer Kontrolle ausgeführt werden, sind sie sicher sinnvoll – Select-All und dann global anwenden wäre jedoch unweise, wovon ich ein 230kB langes Lied singen kann. Ich halte dieses und die anderen Button-Blöcke mit Ausnahme der Basisformatierung und Suchen/Ersetzen allerdings ausgeblendet, um mehr Platz zu haben.
  • Den anscheinend inzwischen beseitigten Fehler in WikEd habe ich nicht mehr auffinden können.
• G: Zu Charles de Gaulle (R 91) fällt mir auch nichts mehr ein, da Flugzeugtrager oder Schiff hinzuschreiben, reißt es ja wohl auch nicht 'raus. Da du nunmehr in der Materie eingearbeitet bist, wäre es wohl besser, wenn du noch zu Erledigendes selbst perfektionierst.
• H: Wenn du dir freundlicherweise in vier bis sechs Wochen mal den dann frischen Dump zur Nachsorge vornimmst?

Jetzt wieder mit gutem Appetit, dir gleichfalls --PerfektesChaos 12:59, 14. Sep. 2010 (CEST)

Ich habe mal Buchstaben in deine Bemerkungen eingefügt, um mich besser darauf beziehen zu können:

A: Grrr, wie kann man nur zwei Skripte verwenden, die das gleiche Problem behandeln?

B: Nein, nein, das war schon immer so. includes/parser/Parser.php Stichwort "Context links".

C: In Anbetracht der Tatsache, dass mein Toolbar-Skript auch im IE funktioniert, behandelt auch dieser Leerstrings als false. Ich bin zu sehr Perl-belastet um irgendein Verhalten dabei merkwürdig zu finden ...

D: Da die meisten Fehler wohl wirklich noch von WikEd stammen (Fehlerbehebung war am 21. Juli), kann man als Ausenstehender keine Skripte finden.

E: Siehe B, würde der Ausdruck irgendetwas finden, dann wäre irgendwo ein dicker Fehler in Mediawiki. Ich habe mit \[\[Kategorie:(.*)(,.*)?( \([^\)]*\))?\|\1\]\] gesucht, alles was dabei durch die Lappen gehen kann, sind Kategorien mit （）als Klammern, wovon ich hoffe, dass es sie nicht gibt. Und natürlich Kategorien, die von einem Bot umbenannt wurden, bevor der Fehler bemerkt werden konnte, aber die kann man nicht per RegExp finden.

F: Automatisch tut WikEd soweit ich weiß nichts. Allerdings läuft die Whitespace-Korrektur, in der der Fehler wohl saß, bei jeder manuell eingeleiteten Autokorrektur (die lila Knöpfe) ab. Der Programmierer hat den Bug aber nun endlich so ca. ein Jahr, nachdem er darauf aufmerksam gemacht wurde, behoben.

G: Der Artikel tauchte schon länger in der Liste auf, sowohl Benutzer:Asdert als auch ich tun nichts damit, also bleibt es wohl so, wie es ist.

H: Ob ich Lust habe, das ganze schon wieder in ein, zwei Monaten zu wiederholen, weiß ich nicht, aber irgendwann werde ich die Liste sicher wieder aktualisieren. So dringend ist es ja nun auch wieder nicht.

Viele Grüße --Schnark 09:43, 15. Sep. 2010 (CEST)

ad B) – Dass es immer schon so dargestellt wurde, glaube ich ohne Weiteres; diese Syntax-Eskapade fügt sich wunderbar in die spontane Entwicklungsphase Anfang des Jahrtausends ein. Nur meine ich, während der Skript-Entwicklung im Frühjahr dieses Jahres im Quelltext ein |]] vorgefunden zu haben, seine Darstellung bestaunt hätte und erst daraufhin in der Hilfe nachgesehen zu haben, was das bedeutet. Erst dann hatte ich das Konstrukt auf meine ToDo-List gesetzt, um es subito zu expandieren. Möglicherweise hat aber zwischenzeitlich jemand eingesehen, dass dieses Strichlein von Menschen und dem nachfolgenden Autor zu leicht übersehen wird und es bei einer Wartung in der gesamten Datenbank expandiert. Egal. – Übrigens ist es immer anregend, mit dir zu kommunizieren; in der Parser.php ist ein [[|name]] erwähnt, über das ich erstmal tiefer nachdenken muss. Habe ich noch nie in einem Quelltext gesehen. Wenn es aber in keiner Hilfe steht und (jetzt?) bei Abspeicherung schon expandiert wird, kann ich es weitgehend ignorieren; ich analysiere ein [[]] ebenfalls nicht weiter, und das ist die gleiche Situation.

ad C) – Na, nur zur Warnung, dass diese Syntax nicht eindeutig definiert ist und das Verhalten sich in Opera Safari FF-4 IE-10 spontan ändern kann, was dann extrem mühsam zu debuggen ist.

s1=""; s1 ist leere Zeichenkette, if (s1) → falsch

s2=new String(); s2 ist leere Zeichenkette, if (s2) → wahr

s3="ABC".substr(10); s3 ist leere Zeichenkette, if (s3) → … ?? … zurzeit falsch (FF3.6.9)

Das muss früher oder später schief gehen.

ad X) – Version 1.5 in Vorbereitung, die die Erfahrungen und Erkenntnisse des Wochenendes aufarbeiten wird, aber nach restloser Aufklärung zuvor noch ein paar Tage zu testen wäre.

Mahlzeit --PerfektesChaos 12:38, 15. Sep. 2010 (CEST)

B: Nicht umsonst steht im Quelltextkommentar ein "Pre-save transform helper function" darüber, und das schon jahrelang und noch länger. Es kann eigentlich nirgendwo im Quelltext ein [[foo|]] vorkommen.

C: Ursprünglich konnte an der einen Stelle, wo ich es verwende, sowohl ein Leerstring als auch ein undefined übergeben werden. Da das undefined inzwischen nicht mehr möglich sein sollte, hast du recht, dass es besser wäre, wenn ich es mal umstellen würde.

Y: Hast du dir eigentlich davon schon den Appetit verderben lassen? --Schnark 09:20, 16. Sep. 2010 (CEST)

• Danke für die Info.
• 0) Ich war's doch. Aber wir zwei Profis konnten gar nicht geleimt werden, wir beide waren gefeit ... unser Modif_Text blockierte das als Nebenwirkung. r=1.6 launched, please clear cache. Ich werde systematisch im Schlicht-Modus austesten müssen; bisher war bei mir fast immer Modif_* aktiv.
• B) Ja, dann mag das so sein; ich habe nur nebelhafte Erinnerungen, wie ich mal auf das Konstrukt gestoßen war.
• P) (neu): PDfix wie gewünscht verfügbar. g-Flag allerdings nur sinngemäß, tatsächlich plumpe Wiederholung: Weil der RegExp nach |name=val sucht, kann das nur genau einmal gefunden werden und kommt im Rest der Vorlageneinbindung nicht mehr vor. g-Flag ist erst möglich, wenn ich mal die Implementierung von allgemeines verschachtelbares Syntax-Objekt fertig habe; dann kann in der Liste der Tupel name=val der Inhalt von val separat analysiert werden; dann können die val Vorlagen (und Links neben nowiki und Kommentar) enthalten. Dieses Objekt wäre neben konkret benannter Vorlagen auch für gallery und Datei:-Einbindungen verwendbar. Also vorläufig nur 3 Pseudonyme und nur je 2 vollständige/wirkliche Namen.
• R) (neu): Re-Engineering steht aber vorrangig auf der Agenda. Die Funktion, die das Wikilink-Format analysiert, hat 660 Zeilen und ist definitiv zu lang; nicht mehr robust zu warten und zu entwickeln. Hier wird es einen objektorientierten Ersatz geben müssen. Macht aber Spaß.
• Y)
  1. Ich schaue mal, wie sich das dann auf mich auswirken würde und ob überhaupt; dazu muss ich aber die konkret generierte HTML-Seite lesen. Von den Deprecations sehe ich nur eine banale Ersetzung mediaWiki.loader.load() statt importScript() -- wobei das wohl in PHP steht, also noch ein paar Zeilen abzukopieren wären. Aber da wird wohl jemand eine Kopiervorlage liefern, oder es bleibt eine initiale Wrapperfunktion für triviale Fälle erhalten.
  2. Ich habe die Projektneuheiten auf meine Beobachtungsliste gesetzt, du warst mal wieder hilfreich.
  3. Den Appetit hat es mir nicht verdorben; im Gegenteil erfreulich wird werden das von mir schon still ersehnte feature Vom Benutzer angelegte JavaScripte werden beim Aufruf im script-tag der HTML-Seite um die Revision-ID ergänzt: User:Foo/common.js&action=raw&2138018 – dadurch wird der Browser-Cache angewiesen, das aktuellste JavaScript vom Server zu laden und abzuarbeiten; damit entfiele das Cache-Rumgedödel.

--PerfektesChaos 20:52, 25. Sep. 2010 (CEST)

P) Danke für den schnellen Einbau. Zwei Mal wirklicher Name sollte eigentlich reichen, und wenn einer vier abgekürzte Pseudonyme hat, muss ich eben eines von Hand ändern oder einmal auf Syntaxkorrekutur-manuell-durchführen-Knopf klicken.

Y) Ich habe mir das Ding mal näher angeschaut und kam zu folgenden Schlüssen:

1. Die meisten Änderungen (insbesondere die meisten Verbesserungen) betreffen nur Mediawiki-Programmierer, vom automatischen durch JS-Minify Jagen über das automatisch Abhängigkeiten auflösen bis hin zum Browser-Cache gezielt aushebeln profitieren wir nur bei unseren vector.js/monobook.js & common.js, Unterseiten sind davon nicht betroffen, wer modular programmiert, hat in diesem Fall einfach Pech. Einen guten Überblick, was sich eigentlich verbessert, bietet [1]. Der Code, insbesondere der clientseitige, ist trotzdem lesenswert und hat mich zu einem eigenen kleinen Experiment angeregt.
2. Wie das Ganze aussehen wird, kannst du dir schon auf Translatewiki ansehen, wo die persönliche vector.js/... geladen wird, weiß ich nicht, vermutlich irgendwo in der Gegend, wo das mediaWiki.user.options.set steht. Evt. anmelden und ausprobieren.
3. Einzige Verbesserung für den gewöhnlichen Skriptbastler ist in meinen Augen, das Vorhandensein von jQuery (das ist jetzt schon der Fall) und bei Bedarf alle möglichen UI- und sonstigen Plugins (Liste: [2], Demos: [3]) Wobei das von optischem Schnickschnack abgesehen nur dem Vorteile bringt, der für DOM-Manipulationen von Hand zu faul ist. (Mir zum Beispiel.)
4. Eine weitere Änderung ist die Tatsache, dass die Skripte nun erst am Schluss aufgerufen werden, dort wo bisher das runOnloadHook(); steht, das bei der Gelegenheit wegfallen wird. Das kann bedeuten, dass ein addOnloadHook oder was auch immer man als Ersatz nehmen will die Funktion nicht auf die Wartebank setzt, sondern sie eventuell direkt ausführt, weil das Load-Event bereits abgefeuert wurde. Dann käme jegliche benutzerdefinierte Konfiguration, die danach kommt, zu spät. Ob das tatsächlich passieren kann, weiß ich nicht, verlassen würde ich mich aber auf nichts mehr.
5. Zu den Deprecations gehört nicht nur die komplette Wikibits.js, sondern auch alle globalen Variablen wgWasWeissIch, die man in Zukunft über mediaWiki.config.get('wgWasWeissIch'); aufrufen sollte. Sollten die Programmierer jemals auf die Idee kommen importScript zu entfernen, wird es einen ganz großen Aufschrei geben, den ich mir lieber nicht vorstellen will, aber zutrauen tu ich es ihnen schon.

Viel Spaß beim Programmieren aller notwendigen und freiwilligen Änderungen, --Schnark 09:41, 27. Sep. 2010 (CEST)

Z) Nachtrag, da ich gerade Benutzer:PerfektesChaos/css#Seiten-interne Verlinkungen gelesen habe. Je nach Wert von wgIsArticle hat das Body-Tag die Klasse ns-subject oder ns-talk. Damit ist im Prinzip eine reine CSS-Lösung möglich. --Schnark 11:35, 27. Sep. 2010 (CEST)

toolbar.js

Für alle, die mein toolbar.js-Skript eingebunden haben und zufälligerweise hier noch mitlesen, oder gerade hierher gekommen sind, um sich darüber zu beschweren: Ich habe gerade eine etwas größere Umstellung vorgenommen, die aber eigentlich keine negativen Auswirkungen haben sollte. Falls irgendetwas wider Erwarten nicht funktionieren sollte, bitte zunächst einmal den Browser-Cache leeren, wenn das noch nicht hilft, evt. den Browser neustarten (war bei mir einmal aus irgendeinem Grund hilfreich) und wenn das auch nichts hilft hier beschweren. --Schnark 10:25, 16. Sep. 2010 (CEST)

Nochmal ein Nachtrag: Es sollte sich eigentlich gar nichts geändert haben durch meine Aktion gerade eben, falls doch, bitte sofort melden. --Schnark 10:09, 14. Okt. 2010 (CEST)

Alle ausgewählten Gadgets temporär deaktivieren

Hallo Schnark. Ich habe gerade deine JS-Scripte bemerkt. Unter MediaWiki Diskussion:Gadgets-definition#alle ausgewählten Gadgets temporär deaktivieren wird etwas ähnliches gefragt wie du mit modulverwaltung.js anbietest. Vielleicht kannst du da (oder ggf. auch bei meinem Change-Tab-Wunsch) ja helfen. --Leyo 11:40, 11. Okt. 2010 (CEST)

Bei den Gadgets kann mein Skript nicht wirklich weiterhelfen, da die Einbindung der js-Dateien auf dem Server geschieht und ich darauf per Javascript keinen Einfluss habe. Außerdem kann man bei mir Skripte auch nur einzeln aktivieren und deaktivieren. Für dein Problem könntest du deine vector.js ersetzen durch etwas wie

importScript('Benutzer:Schnark/js/jsmodules.js'); //[[Benutzer:Schnark/js/jsmodules.js]]
function jsmodules_init() {
  jsmodules.register('[[Benutzer:Jonathan_Haas/vector.js]]');
  jsmodules.register('[[Benutzer:Leyo/monobook.js]]');
  jsmodules.load('[[Benutzer:Schnark/js/modulverwaltung.js]]');
};

Dadurch würde zunächst einmal kein Skript aktiv sein, auf [4] könntest du dann aber beide nach Belieben aktivieren. (Unter der Annahme, dass alles was in deiner monobook.js steht auch unter Vector funktioniert.) Das wären dann beim Wechsel natürlich immer zwei Klicks und ließe sich nur auf dieser Seite oder einer deiner Unterseiten durchführen, aber immerhin. --Schnark 12:00, 11. Okt. 2010 (CEST)

Vielen Dank für deine ausführliche Antwort! Ich werde das demnächst ausprobieren. --Leyo 12:02, 11. Okt. 2010 (CEST)

Mir ist – etwas spät – aufgefallen, dass dein Script ja nur den Vector-Skin unterstützt. Momentan möchte ich aber beim Monobook-Skin bleiben. --Leyo 15:57, 17. Okt. 2010 (CEST)

Prinzipiell ließe sich das Skript vermutlich auch unter Monobook zum Laufen bekommen, allerdings habe ich das noch nicht versucht. Warten wir am besten auf MediaWiki 1.17, da ist es für mich dann kein Problem mehr, das Ganze unter allen Skins zum Laufen zu bringen. --Schnark 09:05, 18. Okt. 2010 (CEST)

Und wann kommt das voraussichtlich? Funktioniert Benutzer:Schnark/js/extratabs mit Google-Übersetzung in anderssprachigen WPs? --Leyo 11:05, 19. Okt. 2010 (CEST)

Auf Glaskugeleien zu MediaWiki-Versionen will ich mich irgendwie nicht einlassen, ich meine mich daran zu erinnern, dass irgendein Optimist mal den November erwähnte (also vielleicht im März nächsten Jahres?). Die Extratabs funktionieren – wenn man sie mit importScriptURI einbindet (Bsp.: [5], [6] – auch in fremdsprachlichen Projekten, man hat allerdings dann gleich alle Extratabs und ich habe gerade festgestellt, dass diese in anderen Projekten nicht einmal alle funktionieren. Im Vector-Skin ist es natürlich einfach, diese anderen Tabs zu ignorieren, ich kann aber auch eine Option einbauen, dass man bei Bedarf alle Tabs außer der Google-Übersetzung ausschalten kann. --Schnark 11:19, 19. Okt. 2010 (CEST)

Ich hab's mal in der fr-WP ausprobiert. Bei mehreren Extratabs bewirkt „wikipédia“ das Problem. --Leyo 11:31, 19. Okt. 2010 (CEST)

Bitte einmal den Browsercache leeren. WikiLint als spezielles de.wikipedia-Tool funktioniert natürlich noch immer nicht, aber die anderen Dinge laufen jetzt auch in fr. --Schnark 11:50, 19. Okt. 2010 (CEST)

Uppss...

...sorry, hatte mich eben verklickt und dabei eine PDD-Einfügung durch Dich rückgängig gemacht. Habe das natürlich sofort korrigiert. Möchte Dich nur informieren, dass es keinen Grund dafür gab. Ich muss mal meine Bildschirmauflösung neu anpassen; derzeit stehen sehr häufig die Links "Versionen" und "Zurücksetzen" exakt übereinander; wenn ich dann auf dem Mauspad verrutsche... Nix für ungut. Gruß, --CC 10:51, 16. Okt. 2010 (CEST)

Gibt es hier irgendjemand, dem das noch nicht passiert ist? Ich habe, nachdem es mir das erste Mal passiert ist, ein

.mw-rollback-link { display:none; }       /*Zurücksetzen weg, zu gefährlich*/
.diff-ntitle .mw-rollback-link { display:inline; background-color:#FFC0C0;}
                                             /*nur bei Diffs, rot unterlegt*/

in meiner vector.css, was die Zurücksetzen-Links an den meisten Stellen ausblendet und sonst rot hinterlegt. Falls du es übernehmen willst, muss der Code in Spezial:Meine Benutzerseite/vector.css (oder Spezial:Meine Benutzerseite/monobook.css, falls du beim alten Skin geblieben bist). Ansonsten kann ich noch safe-rollback.js von Revolus empfehlen. Viele Grüße --Schnark 11:00, 16. Okt. 2010 (CEST)

Herzlichen Dank, freundliches Angebot. Ich schätze meinen Skin aber tatsächlich "nackt", s.h. ohne Erweiterungen, wesentlich mehr. Freundlicher Gruß, --CC 11:30, 16. Okt. 2010 (CEST)