MediaWiki Diskussion:Gadgets-definition/Archiv 2011

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[MediaWiki Diskussion:Gadgets-definition/Archiv 2011#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wiki.x.io/wiki/MediaWiki_Diskussion:Gadgets-definition/Archiv_2011#Thema_1

Bitte mal schauen

Bitte mal hier schauen: [1] Ein mE nützliches Gadget (nicht signierter Beitrag von 92.205.29.231 (Diskussion) )

Der Abschnitt wurde archiviert und ich mag jetzt nicht suchen… --Leyo 19:39, 27. Jan. 2011 (CET)

Ist das gleiche wie "mein" Vorschlag hier untendrunter. Im Archiv. Viele Grüße --Saibo (Δ) 19:47, 27. Jan. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Saibo (Δ) 19:49, 27. Jan. 2011 (CET)

Commons:MediaWiki:Gadget-rightsfilter.js

Ich finde die Möglichkeit, Logs, Beitrags- und Beobachtungslisten zu filtern, ganz praktisch. Wie wär's dieses Gadget auch hier einzuführen? --Leyo 16:51, 30. Mär. 2011 (CEST)

Mach. Ich würde es, wie bei wikEd, aus dem Fremdwiki laden. (Andernfalls endet man wie in WikiSource irgendwann bei einer Uraltversion.) Probleme gibt es ggf., wenn man sich per HTTPS anmeldet. --32X 11:12, 31. Mär. 2011 (CEST)

Also so?

document.write('<script type="text/javascript" src="'

+ 'http://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-rightsfilter.js'

+ '&action=raw&ctype=text/javascript"></' + 'script>');

--Leyo 14:49, 31. Mär. 2011 (CEST)

Bitte keine document.writes! Von mw:ResourceLoader/Migration guide (users)#Gadgets kopierter und angepasster Code:

/*
 Importiert die aktuelle Version des Gadgets Rightsfilter von Commons.
 Ermöglicht eine Filterung von Spezial:Log mit regulären Ausdrücken.
*/
var commonsBase = 'http://commons.wikimedia.org';
if ( mw.config.get( 'wgServer' ).indexOf('https://') === 0 ) {
	commonsBase = 'https://secure.wikimedia.org/wikipedia/commons';
}
mw.loader.load( commonsBase + '/w/index.php?title=MediaWiki:Gadget-rightsfilter.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400' );

--Schnark 09:18, 1. Apr. 2011 (CEST)

Danke! Ich habe das Gadget so unter MediaWiki:Gadget-rightsfilter.js angelegt. Es scheint zu funktionieren.

Nach deinen obigen Ausführungen müsste MediaWiki:Gadget-wikEd.js angepasst werden, oder? --Leyo 09:48, 1. Apr. 2011 (CEST)

Ersetze „müsste“ durch „sollte“ und jeden Verweis auf Commons durch en (letzteres am einfachsten durch C&P des Navigation Popups-Beispiels auf der verlinkten mw-Seite). Falls du ohnehin dabei bist, MediaWiki:Gadget-WikiMiniAtlas.js und MediaWiki:Gadget-wikEd.js verwenden auch noch document.writes. --Schnark 10:34, 1. Apr. 2011 (CEST)

Ist das so und so korrekt? --Leyo 10:49, 1. Apr. 2011 (CEST)

Sieht gut aus, WikiMiniAtlas über http habe ich auch gerade erfolgreich getestet. WikEd erzeugt bei mir Fehler, aber das liegt an meinen Browser-Einstellungen. Da bei allen Benutzern, die das Gadget aktiviert haben, automatisch der Cache umgangen und der aktuelle Code geladen wird, werden Beschwerden schon schnell genug auf WP:FzW aufschlagen, falls es doch irgendwelche Probleme geben sollte. --Schnark 11:09, 1. Apr. 2011 (CEST)

Das Gadget Rightsfilter funktioniert hier noch nicht (außer man verwendet gleichzeitig das Popups-Gadget o. Ä.). Soweit ich sehen kann, kann man dies ohne Nebenwirkungen lösen, indem in MediaWiki:Gadget-rightsfilter.js noch die Zeile

window.getParamValue = mw.util.getParamValue;

am Anfang eingefügt wird. Alternativ bringt man einen Commons-Admin (im Zweifelsfall commons:User:Krinkle) dazu, in commons:MediaWiki:Gadget-rightsfilter.js alle getParamValue durch mw.util.getParamValue zu ersetzen. --Schnark 10:02, 5. Apr. 2011 (CEST)

Bei mir hat's aus diesem Grund funktioniert. Ich habe wie vorgeschlagen und im Vertrauen auf deine Kenntnisse die Commons-Version angepasst. --Leyo 15:45, 5. Apr. 2011 (CEST)

Funktioniert nun wunderbar. --Schnark 09:10, 6. Apr. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 00:18, 24. Apr. 2012 (CEST)

en:User:Cacycle/wikEdDiff

Ich nutze Wikipedia:WikEd seit Einführung des Vector-Skins nicht mehr, aber der farbige diff ist weiterhin sehr praktisch zum Hilfe:Sichten. Gruß Matthias 09:03, 27. Apr. 2011 (CEST)

Kennst du Benutzer:Schnark/js/diff (oder auch Benutzer:Schnark/js/jsmodules)? --Leyo 10:35, 27. Apr. 2011 (CEST)

Nein, kannte ich bis jetzt noch nicht. Danke für den Tipp auch wenn ich zwischen Benutzer:Schnark/js/modulverwaltung und MediaWiki:Gadgets-definition ein Not-Invented-Here-Syndrom bzw. eine gewisse Redundanz sehe. Gruß Matthias 10:59, 27. Apr. 2011 (CEST)

Zur Ehrenrettung von Schnark: Schnark hat ein Workaround geschrieben, das eine fehlerhafte Funktion umgeht: en:User talk:Cacycle/wikEd#Bug in diff.js. Erfahrungsgemäß dauert es über 12 Monate, bis User:Cacycle einen bug beseitigt. – Eine Schnittmenge zwischen der Registrierung und Cookie-Steuerung in modulverwaltung und Gadgets-definition kann ich nicht erkennen. VG --PerfektesChaos 15:54, 12. Jun. 2011 (CEST)

Ich sehe gerade, dass Benutzer:Schnark/js/diff ist en:User:Cacycle/wikEdDiff deutlich überlegen ist. Wenn er es nur über die Benutzer:Schnark/js/modulverwaltung verbreiten möchte, die einen ähnlichen Komfort bietet, dann brauchen wir hier kein Gadget dafür. Gruß Matthias (Diskussion) 14:32, 5. Okt. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Matthias (Diskussion) 14:32, 5. Okt. 2012 (CEST)

bytechange in den Versionsgeschichten

... so wie es auch in der Beo aussieht. Aktuell hier: Benutzer:Steef389/bytechange.js.

Besitzt den Parameter replace_size = true; um die Größenangabe zu ersetzen. Den Parameter habe ich persönlich nicht aktiv - ich sehe gern beide Zahlen. Viele Grüße --Saibo (Δ) 19:25, 27. Jan. 2011 (CET)

Hier die Ausgangsdiskussion dazu (im Archiv) --Saibo (Δ) 19:49, 27. Jan. 2011 (CET)

Mach ’ne „saubere“ und leicht dokumentierte Version davon und erstelle noch eine Dokumentationsseite, dann verschiebe ich beide an die entsprechenden Positionen. --32X 10:45, 28. Jan. 2011 (CET)

Das verschieben bekäme ich schon selbst hin - eher wusste ich nicht in welchem Format die Gadgets sein müssen. Nun habe ich aber oben gesehen, dass da wohl die Gadget-Definitionen verlinkt sind - dann schaue ich mir das mal an. Viele Grüße --Saibo (Δ) 15:31, 28. Jan. 2011 (CET)

Habe den Code jetzt auskommentiert und noch ein bisschen umgebaut. Eine Dokuseite könnte ich morgen noch erstellen, komme ich jetzt nicht mehr dazu. Wenn am Code noch etwas geändert werden soll, gebt mir bescheid (oder ändert es selbst; it's a wiki). --Steef ³⁸⁹ 20:50, 28. Jan. 2011 (CET)

Super, ich danke dir. Wenn eine Seite komplett geleert wurde, dann wird NaN statt der korrekten Differenz angezeigt - das könntest du vielleicht noch ändern, wenn du lustig bist. Beispiel: "(leer) (NaN)" in Benutzer:Saibo/eigene Spielwiese

Eine Doku habe ich mal hier vorbereitet - ich nehme an, dass das gemeint war: Benutzer Diskussion:Steef389/bytechange.js

Viele Grüße --Saibo (Δ) 21:37, 28. Jan. 2011 (CET)

NaN-Problem behoben. --Steef ³⁸⁹ 23:57, 28. Jan. 2011 (CET)

Danke, funktioniert. Viele Grüße --Saibo (Δ) 00:53, 29. Jan. 2011 (CET)

MediaWiki zeigt seit der Version 1.19 von sich aus beide Werte an, daher nicht mehr notwendig. Der Umherirrende 20:06, 9. Okt. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:06, 9. Okt. 2012 (CEST)

eo:MediaWiki:Gadget-Popups.js, eo:MediaWiki:Gadget-markblocked.js

Hallo. Die Seiten eo:MediaWiki:Gadget-Popups.js, eo:MediaWiki:Gadget-markblocked.js verwenden noch document.write. Wie müßte ich sie anpassen? Gruß --Tlustulimu 17:14, 12. Jun. 2011 (CEST)

Beide Gadgets wurden bereits angepasst. Der Umherirrende 20:04, 9. Okt. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:04, 9. Okt. 2012 (CEST)

secure.wikimedia.org

Wäre einer der Admins so lieb, secure.wikimedia.org in protokoll-relative URL zu vereinfachen?

• MediaWiki:Common.js 2012: siehe unten
• MediaWiki:Gadget-revisionjumper.js
• MediaWiki:Gadget-rightsfilter.js erl.
• MediaWiki:Gadget-wikEd.js nach Benutzerbeschwerde
• MediaWiki:Gadget-WikiMiniAtlas.js erl.

Danke --PerfektesChaos 20:16, 15. Nov. 2011 (CET)

Dass MediaWiki:Gadget-revisionjumper.js sowohl für http:, als auch https: und secure funktioniert, hast du gesehen? ;o) Hatte ich natürlich gleich angepasst … Grüße, —DerHexer (Disk., Bew.) 22:13, 15. Nov. 2011 (CET)

Wäre es denn problematisch, wenn man secure rausstreicht? Also dass von secure.wikimedia.org Dateien von //*.wiki.x.io (ebenfalls per https) angefordert werden, oder würden da Cross-Domain-Probleme entstehen? -- ✓ ^Bergi 22:49, 15. Nov. 2011 (CET)

In diesem Skript könnte man secure entfernen, wenn man davon ausgeht, dass niemand mehr dieses Skript unter secure verwendet (das bezweifle ich mal teilweise). Bei anderen Skripten meinerseits besteht aber dieses Cross-Domain-Problem. Grüße, —DerHexer (Disk., Bew.) 23:32, 15. Nov. 2011 (CET)

• Mir geht es nur darum, den Code (hier: Helferlein, von Vielen genutzt) möglichst lesbar und nachvollziehbar zu gestalten und grundlose Ausnahmen zu vermeiden.
• Die anderen Skripte bestünden dann nur aus einer Zeile wie

      mw.loader.load("//en.wiki.x.io/..............

• Bei revisionjumper.js verhält es sich insofern etwas anders, als hier das eigentliche Arbeitsskript hinterlegt ist.
  • Gleichwohl würde das nämliche Vorgehen zum Erfolg führen:

      mw.loader.load(wgServer+wgScript+
      // vielleicht besser als
      mw.loader.load("//de.wiki.x.io/w/index.php?title=

• Ich habe meine Bookmarks auf secure.wikimedia.org behalten und melde mich zu Testzwecken regelmäßig auch darüber an. Cross-Domain-Probleme kann ich mir vorstellen, wenn die API involviert ist, wie das bei revisionjumper der Fall ist, weil dann XMLHttpRequest auf die Domain Wert legt. Das hängt aber nicht von der URL ab, unter der das umgebende Skript geladen wurde, sondern von der Gestaltung jedes einzelnen API-Aufrufs.

Liebe Grüße --PerfektesChaos 09:45, 16. Nov. 2011 (CET)

Da eh schon Sachen von bits geladen werden, scheint es beim laden des Skripts nicht zu stören. Viel wichtiger ist es, dann angebotende Links auch auf secure.wikimedia.org bleiben, damit der Benutzer angemeldet bleibt. Bei einem Skript, was nur interne Links erzeugt ist das einfach. Bei links auf Commons müsste man es so machen, wie in der Common.js derzeit ist. Der Umherirrende 11:53, 16. Nov. 2011 (CET)

1. Das ausgeführte Skript hat keinerlei Kenntnis davon, von welcher URL sein Quellcode stammt (debugging-Funktionen mal ausgenommen).
2. Richtig ist, dass generierte Verlinkungen die Umgebung des Benutzers beachten sollen, der es ausführt; API-requests müssen in dieser Domain bleiben.
3. Wer unter https angemeldet ist, sollte nur Ressourcen einbinden müssen, die über zertifiziertes https geladen werden.

LG --PerfektesChaos 17:22, 16. Nov. 2011 (CET)

Status 2012: Common.js an zwei Stellen

1. Bilddiskussionsseitenlink kann bei secure.wikimedia.org weiterverlinken auf https://commons.wikimedia.org/wiki/ und ansonsten Protokoll-relativ.
2. Import von /secure.js wird nicht wirksam bei https://de.wiki.x.io – müsste aber allgemein bei window.location.protocol==="https" ausgeführt werden, um die expliziten http in der Seite umzusetzen.

VG --PerfektesChaos 00:04, 7. Jan. 2012 (CET)

Die Commons-Link sind in Ordnung, weil man dann seine Domain nicht verlässt. Import von secure.js ist für protokoll-relative WP nicht sinnvoll, weil es secure.wikimedia.org-Links generiert. Ich hatte daher unter MediaWiki Diskussion:Common.js#MediaWiki:Common.js/relative.js ein ähnliches Skript für protokoll-relative WP vorgeschlagen. Das Beispiel dort funktioniert, aber es hat sich bis jetzt noch niemand gefunden, das entsprechend umzusetzen. Der Umherirrende 22:59, 7. Jan. 2012 (CET)

• Commons-Domain nicht verlassen bei secure – ja, okay, ist ein Gesichtspunkt; vielleicht denkt sich jemand was dabei.
• Wenn ein secure.js eingebunden wird, dann soll dieses natürlich künftig auf protokollrelativ statt auf http verlinken, fertig. Geht viel einfacher als die bisherige Praxis und wäre für beide https-Wege nutzbar.

Schönen Sonntag --PerfektesChaos 23:28, 7. Jan. 2012 (CET)

relative.js ist aktiv, der Rest angepasst, sollte somit erstmal alles passen. Der Umherirrende 20:02, 9. Okt. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:02, 9. Okt. 2012 (CEST)

MediaWiki:Gadget-searchbox.js

Dieses Gadget ist sehr hilfreich. JackPotte 12:31, 11. Feb. 2011 (CET)

Geo-Referenzierungs-Dings-Bums

Moin! IMHO koennte/sollte ein Geo-Ref Tool wie z.B. GetCoordinate von Mcaviglia eingebaut werden. Ich mag nicht meine monobook immer wieder aendern und manchmal stolpert man ja auch einfach ueber eine fehlende Koordinate. Wer kann sowas basteln? :) --Hedwig in Washington (Post?)•B 02:37, 20. Jun. 2011 (CEST)

Kompakte Einverständniserklärung

Beim Bearbeiten werden zwei Boxen mit Hinweisen zu Lizensierung angezeigt:

Das Kopieren urheberrechtlich geschützter Werke ist verboten! Mit dem Speichern dieser Seite versichere ich…

und

Wenn du nicht möchtest, dass dein Text weiterbearbeitet und weiterverbreitet wird…

Ich sehe ein, dass diese Hinweise für Erstbenutzer besonders plakativ und eindringlich sein müssen und ich sehe auch ein, das jede Bearbeitung beim Speichern korrekt lizensiert werden muss. Ich schlage vor, diese Meldungen für angemeldete Benutzer per Option auf ein Mindestmaß (mit weiterführenden Links) zu verkürzen - sinngemäß so wie auf jeder Internet-Bestellseite steht

Ich habe die Allgemeinen Geschäftsbedingungen CC 3.0 und GFDL einschließlich der Nutzungsbedingungen gelesen und erkenne diese an.

Ich erhoffe mir davon, mehr vom dem wertvollem Bildschirmplatz für den Editor oder die Vorschau verwenden zu können.--Spischot 22:56, 9. Jul. 2011 (CEST)

Ich habe sie bei mir per Adblock komplett ausgeblendet - sehe ich genauso wie du. Man könnte natürlich sich auch in die skin.css etwas schreiben. Per Gadget müsste es auch gehen, ja. Allerdings sollte die Ausblendentscheidung schon wirklich wissenlich und bewusst getroffen werden, da ja dort die Zustimmung zur Lizenzierung drinsteht. Nicht das jemand das versehentlich macht und dann meint für ihn gelte die Lizenz nicht... Das scheint mir per Gadget-Checkbox etwas schwierig. Vielleicht fällt ja jemandem was ein. Viele Grüße --Saibo (Δ) 02:44, 10. Jul. 2011 (CEST)

Die Erklärung soll ja nicht weg sondern nur platzsparend dargestellt werden – justitisch ist das äquivalent. Ich sehe da kein Problem, insbesondere, nachdem das erst auf expliziten Benutzerwunsch reduziert wurde. CSS und Adblock sind keine Alternative für Gadgets. (Aber trotzdem mal neugierig gefragt: Wie lautete die entsprechende Filterregel für Adblock denn?) --Spischot 08:25, 10. Jul. 2011 (CEST)

Ich habe jetzt mal selbst herumprobiert und folgende Filterregeln erstellt:

!Hinweise für Nutzungsbedindungen beim Editieren von Wikiperdia unterdrücken (Die Nutzungsbedingungen gelten dennoch)
##div#editpage-copywarn
##div.mw-tos-summary

Ich habe dann noch versucht, diese Regel auf die Wikipedia-URLs zu beschränken:

|http://*.wiki.x.io##div#editpage-copywrn
|http://*.wiki.x.io##div.mw-tos-summary

Das funktioniert leider nicht – irgendwas mache ich wohl noch falsch. --Spischot 10:09, 10. Jul. 2011 (CEST)

Achso - ja - stimmt, wenn sie nur komprimiert dargestellt werden, dann ist das per Gadgethäkchen schon okay. Ich nehme an, dass per Gadget nur Javascript und nicht CSS aktiviert werden kann. Daher müsste dann wohl per Javascript eine entsprechende CSS-Regel injiziert (oder das Element gelöscht) werden.

wikimedia.org##DIV#editpage-copywarn
wikimedia.org##DIV.mw-tos-summary

Habe ich (für secure-Server) - für de.wiki.x.io dann natürlich das m durch ein p tauschen. Wenn wir schon dabei sind: "wikimedia.org##DIV#footer:last-child" finde ich auch noch praktisch. Viele Grüße --Saibo (Δ) 15:46, 10. Jul. 2011 (CEST)

Es geht auch CSS per Gadget. Vielleicht reicht aber hierfür auch ein Abschnitt auf WP:Skin oder so, da es schon sehr einfach ist, aber das sind andere Gadgets auch, also zwiespältig, ob es dafür lohnt. Der Umherirrende 16:28, 10. Jul. 2011 (CEST)

Skinbasteleien sind halt für den Ottonormaluser doch um einiges schwieriger, als ein Häkchen zu setzen. ;-) Per CSS könnte man sie aber nur ganz ausblenden und nicht den Text austauschen, richtig? Viele Grüße --Saibo (Δ) 18:46, 10. Jul. 2011 (CEST)

Text ändern geht nicht, aber kleiner kann man es machen. Der Umherirrende 18:49, 10. Jul. 2011 (CEST)

Schade, dass das mit den Ändern nicht geht, denn selbst verkleinern bringt nur wenig Platzgewinn. Die untere Box kann wohl ohne rechtliche Probleme ganz weg, da sie nur Hinweise und keine rechtlichen Erklärungen des Autors enthält. In der oberne Box sind ebenfalls drei Hinweise-Sätze („Das Kopieren …“, „Bitte gib …“ und „Wikipedia-Artikel …“, gleicher Art die eher weg sollten, was aber eine Änderung bräuchte. Und selbst der einzig juristisch bedeutende Satz „Mit dem Speichern …“ hat deutliches Kürzungspotential („Mit dem Speichern dieser Seite erkenne ich die Nutzungsbedingungen an“). Das Kleingedruckte als extrem klein gedrucktes bringt es irgendwie nicht. --Spischot 19:07, 10. Jul. 2011 (CEST)

M.E. sollte nach Erstellung des Benutzerkontos – oder sobald man automatischer Sichter ist – eine Art EULA (Hinweis, dass alle Bearbeitungen, die an der Wikipedia getätigt werden …) angezeigt werden und drunter die Optionen, ob ich noch konkrete Erinnerungen in Form dieser Boxen möchte oder ob ich es verstanden habe und diese verstecken möchte. -- RE rillke fragen? 14:23, 31. Okt. 2012 (CET)

1. Ein Ausblenden der juristischen Hinweise durch simplen Klick auf der Einstellungs-Seite ist juristisch extrem heikel.
   • Das kann auch durch irrtümlichen Klick und Herumprobieren auf den Einstellungen und Helferlein passiert sein.
2. Mittel der Wahl unter den gegenwärtigen Bedingungen ist das individuelle Ausblenden per Benutzer-CSS.
   • Das hinterlässt auf Jahre hinaus Spuren in der Versionsgeschichte und ist zweifelsfrei rekonstruierbar.
   • Es kann auch nachvollzogen werden, dass zwischen dem Zeitpunkt des Ausblendens und dem ersten Edit mehrere Hundert Bearbeitungen gelegen haben, bis man herausgefunden hatte, wie das mit dem CSS geht. Damit ist aber nachweisbar, dass mehrere Hundert Mal die Kisten wahrgenommen werden mussten.
   • Das Gadget-Häkchen hinterlässt allenfalls kurzfristig eine Spur auf dem Server, eigentlich nur seinen momentanen Zustand, und keine History über mehrere Tage oder gar Jahre.
   • Das Bearbeiten von Benutzer-CSS ist eine komplexe aktive Handlung und kann nicht mal eben aus Versehen durch einen Mausklick an der falschen Stelle geschehen sein.
3. Wie das mit CSS geht, steht unter WP:CSS #edithelps und auch mehr unter WP:CSS #hints.
   • Offenkundig dauert es ein Weilchen, bis man dorthin findet. Das ist auch gut so.
4. Das Aufteilen in unterschiedliche Boxen (wie auch schon auf enWP) kann man in Absprache mit verantwortlichen Obermacs (Admin-Konsens, B, Stewards?, WMF) durchaus machen, etwa aufgeteilt in Bedienungshinweise und juristische Fragen. Über letztere muss man jedoch aktiv hinwegscrollen, um an den Speichern-Knopf zu gelangen; in der Fußzeile ist es wertlos, und sie müssen zusammen mit dem Speichern-Knopf sichtbar sein.
5. Eine Lösung mittels Häkchen in einer Zustimmungs-Box müsste dauerhaft (etwa im Benutzer-Logbuch) dokumentiert werden; und dies bedürfte einer weltweit wirksamen Software-Änderung.

VG --PerfektesChaos 20:14, 31. Okt. 2012 (CET)

1. Dann muss eben sichergestellt werden, dass man nicht "aus Versehen" diesen Haken drückt (z.B. durch die Bitte 2 zufällig generierte Zahlen zu addieren).
2. Endbenutzerlizenzverträge sind schließlich auch rechtswirksam.
3. Ich schlage vor:

• MediaWiki:wikimedia-copyrightwarning erhält 2 Texte: Den kurzen Standardtext (oder noch knapper formuliert) und den längeren aktuellen Text.
• Per CSS (im HTML style-attribut) wird der kürzere Standardtext ausgeblendet.
• Beide Texte werden in einen Elternknoten mit individueller Klasse gepackt.
• Das Gadget würde den langen Text ausblenden und den kürzeren, dennoch rechtlich unbedenklichen Text einblenden.

-- RE rillke fragen? 00:31, 2. Nov. 2012 (CET)

Benutzer:Flominator/Weiterleitungshinweis.js

Blendet den Vorlage:Weiterleitungshinweis aus, wenn man nicht weitergeleitet wurde. Was haltet ihr davon? Was müsste man noch umstellen, bevor es freigeschalten werden könnte? --Flominator 07:44, 23. Okt. 2011 (CEST)

Funktioniert nicht mit anderen Sprachen und Skins (bei cologneblue und standard hat das Element nur die Klasse subtitle). Wo überall etwas zum Subtitle hinzugefügt wird, erfährst du hier, vielleicht hilft das weiter (Spezialfallbeispiel).

Ansonsten nutze jQuery.ready statt addOnLoadHook und die Überprüfung auf document.getElementById sollte man sich mitterweile auch sparen können.

Ob eine derartig triviale Funktionalität eines Gadgets würdig ist, weiß ich nicht. -- ✓ ^Bergi 21:33, 30. Okt. 2011 (CET)

Danke für das Feedback. Mit "eines Gadgets würdig" meinst du "lass den Quatsch" oder "pack es gleich in die Common.js"? Gruß, --Flominator 11:28, 13. Nov. 2011 (CET)

Letzteres, die Funktionalität ist ja sinnvoll. Nur "lohnt" sich für einen solchen Dreizeiler (etwas verkürzt geschrieben wirds einer) kaum eine eigene Skriptdatei zum Laden (gut, RessourceLoader hilft). Jetzt ist halt abzuwägen, ob die Community das in den Einstellungen aktivierbar haben möchte, defaultmäßig angeschaltet (MediaWiki:Common.js) haben möchte oder es als zu unbedeutend ansieht und man sich die Zeilen in die eigene common.js kopieren soll („…wenn mans unbedingt braucht“). -- ✓ ^Bergi 19:04, 13. Nov. 2011 (CET)

Wo sollte man das diskutieren? --Flominator 18:09, 4. Dez. 2011 (CET)

Hier ist eigentlich der richtige Ort dafür, nur leider zu wenig Publikum. Starte eine kleine Inline-Umfrage und verweise von FzW darauf? Eine Option hab ich übrigens vergessen: defaultmäßig angeschaltet als Gadget, d.h. nicht per Userscriptdatei sondern in den Einstellungen abschaltbar. -- ✓ ^Bergi 14:44, 27. Dez. 2011 (CET)

Ich würde, wenn dann Gadget mit RL bevorzugen - sollte so nicht wirklich länger dauern als per common.js, oder? Ein gesteigertes Bedürfnis für das Gadget habe ich allerdings nicht. ;-) Wahrscheinlich führt es z.B. dazu dass auf meinem lahmen Computer/Firefox der ganze Artikeltext herumhüpft, wenn das Script (auf einer der extrem wenigen 478 Seiten mit einem solchen Hinweis) geladen ist. Viele Grüße --Saibo (Δ) 19:30, 27. Dez. 2011 (CET)

Wenn Bug 32230 live ist, sollte das Script unbedingt auf wgRedirectedFrom umgestellt werden. Vielleicht kann damit auch die Ladereihenfolge so geändert werden, dass eine CSS-Definition aktiviert wird, bevor die Seite geladen ist, damit die Position nicht mehr herumhüpft. --Fomafix 21:41, 27. Dez. 2011 (CET)

Na, wenn ich das so verstehe, dass mit MW 1.19 dieses wgRedirectedFrom sowieso kommt, dann machen wir daraus doch gleich eine richtige Funktionalität für die MediaWiki:Common.js (Klassennamen als Arbeitstitel):

if (mw.config.get("wgRedirectedFrom")) {
   mw.util.addCSS("                              \
      .Seite-wurde-weitergeleitet-ausblenden {   \
         display: none;                          \
      }                                          \
      .Seite-wurde-weitergeleitet-einblenden {   \
         display: block ! important;             \
      }                                          \
                  ");
}

Wirkung: Wenn wgRedirectedFrom, dann ist das bereits in der HEAD-Ladephase oder jedenfalls so früh wie irgend möglich vor ContentLoad bekannt, und die beiden CSS-Definitionen werden wirksam.

Nun kann in jede einschlägige Vorlage die geeignete Klasse hineingeschrieben werden, also ein class="Seite-wurde-weitergeleitet-einblenden" style="display:none" in die Vorlage:Weiterleitungshinweis. Normalerweise ist wgRedirectedFrom immer unbekannt, damit in der Vorlage:Weiterleitungshinweis also unwirksam. Ist es jetzt tatsächlich eine WL, greift die Zuordnung und das display:none wird übertrumpft.

Wenn dann der BODY der Seite aufgebaut wird, sind die Stile von vornherein bekannt und die Vorlage wird gar nicht erst angezeigt, die Flickerei beim Seitenaufbau also vermieden.

Auf Wunsch noch mit negiertem Pfad und Klasse, noch hüpfsicherer:

} else {
   mw.util.addCSS("                                    \
      .Seite-wurde-nicht-weitergeleitet-ausblenden {   \
         display: none;                                \
      }                                                \
      .Seite-wurde-nicht-weitergeleitet-einblenden {   \
         display: block ! important;                   \
      }                                                \
                  ");

Falls man es also auf diesem Weg löst, kann man sich die Reklame für Gadgets und die Diskussion und Rückfragen und Doku mit Helferlein sparen und es kommt unbemerkt für alle einschließlich IP – ohne dass jemand die Wirkung mitbekommt.

Schönes Rest-2011 --PerfektesChaos 11:12, 28. Dez. 2011 (CET)

Na, und ich sehe gerade:

Abwarten auf MW 1.19 ist nicht erforderlich; es geht auch heute schon (und ging schon seit Jahren):

/* MW 1.19 -- bis dahin workaround
if (mw.config.get("wgRedirectedFrom")) {
*/
if (document.location.pathname !==
    mw.util.wikiGetlink(mw.config.get(wgPageName)) ) {

Mit MW 1.19 sollte der Ausdruck allerdings hübscher gestaltet werden.

URL-Encoding mag noch differieren; sollte aber auch den Umlaut von Bund für Umwelt und Naturschutz Deutschland richtig identifizieren, zumal nur im ANR und wohl ausschließlich im Zusammenhang mit Abkürzungen eingesetzt.

Kann sofort in MediaWiki:Common.js eingebaut werden, Gadget ist nicht erforderlich.

Wenn die else-Clause wahrgenommen wird, wäre in Vorlage:Weiterleitungshinweis einzufügen: class="Seite-wurde-nicht-weitergeleitet-ausblenden"

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

…&& mw.util.getParamValue("title") != encodeURIComponent(wgPageName) (oder so ähnlich)?

@Klassen: Bitte nicht doppelt moppeln, einmal redirected-hide und einmal notredirected-hide sollten genügen. Und bitte keine ganzen Sätze im class-Attribut :-) -- ✓ ^Bergi 13:27, 28. Dez. 2011 (CET)

• Das mit den title= war mir auch aufgefallen, würde ich aber im vorläufigen workaround nicht verkomplizieren. Bei diffpages, preview und Permlink zeigt der workaround eben „fälschlich“ und wie auch schon seit Jahren die Kiste – das kann dann später mit dem sichereren MW 1.19 auch noch wegfallen. Der Umlaut wird ja wohl bereits richtig erfasst. In erster Linie geht es um einfache Leser, auch als IP, die im Suchfeld über GPL gekommen sind, oder aber über interne Verlinkung auf GNU General Public License. Wobei man dann künftig als Linkziel die ausgeschriebene Form GPL wählen sollte, mit der Abkürzung als Linktitel – was auch bisher schon zu einem selbsterklärenden Tooltip führt und ggf. einen Klick auf den Artikel spart.
• Die „ganzen Sätze“ in der class (einleitend als „Arbeitstitel“ bezeichnet) oder auch die vom Minifier nicht erfassten Leerzeichen im addCSS() dienen dem leichteren Verständnis der Diskutanten.

In diesem Sinne --PerfektesChaos 14:01, 28. Dez. 2011 (CET)

Ungefähr so wollte ich es auch umsetzen. Ganz zufrieden bin ich aber noch nicht. Der Artikel GNU General Public License hat neben der Weiterleitung GPL auch noch die Weiterleitung GNU GPL. Bei einem Aufruf von GNU GPL ist ein Weiterleitungshinweis auf GPL (Begriffsklärung) ebenso nicht sinnvoll. Der Weiterleitungshinweis sollte daher nur dann angezeigt werden, wenn wgRedirectedFrom gleich {{{1}}} der Vorlage:Weiterleitungshinweis. Für Hinweise auf mehrere Weiterleitungen muss die Vorlage und deren Einbindungen aber noch umgebaut werden. Die zwei Monate bis MediaWiki 1.19 und damit wgRedirectedFrom bei uns kommt, können wir auch noch warten. --Fomafix 15:45, 28. Dez. 2011 (CET)

• Ich bewundere deinen Optimismus. Ich halte es eher mit der alten Bauernregel: Software-Projekte dauern immer doppelt so lange wie angekündigt, und erwarte MW 1.19 eher zu Ostern.
• Es schadet nichts, die überwiegende Zahl der vermeidbaren Boxen-Anzeige bereits in diesem Jahr standardmäßig per workaround zu entfernen. Die Feinarbeit kann dann irgendwann in 2012 kommen.
• Da es offenbar ausschließlich nur um den ANR geht, lässt sich unnötiger DOM-style-Aufwand vermeiden mit einem umschließenden ! wgNamespaceNumber und anschließend innen auch wgAction==="view" – auf einer diffpage kann es praktisch nie eine WL der beschriebenen Art geben, zumindest in keinem üblichen Arbeitsablauf.
• Nun zu der von dir benannten Tücke, dass mehrere unterschiedliche WL auf die Seite verweisen, aber nur bei der Standard-Abkürzung die Box gezeigt werden soll.
  • Wurde direkt auf den vollständigen Seitennamen verlinkt, dann kann bereits in der HEAD-Phase flickerfrei die Box in einem äußeren div unterdrückt werden mit:
    • class="redirected-no-hide"
    • Das kann jetzt schon per document-workaround für den Standardfall geregelt werden.
  • Handelt es sich um eine Weiterleitung von irgendwas, dann muss {{{1}}}} abgeglichen werden. Das ist aber erst während des BODY und DOM-Aufbau analysierbar. Je nachdem, wie schnell und in welcher Reihenfolge DOM-Analyse, Rendering, Skriptausführung, DOM-Veränderung, Auswirkung des eingefügten Styles greifen, ist in diesen Fällen Flackern und Hüpfen nicht völlig auszuschließen, wenn eine Irgendwie-Weiterleitung auch eine Abk-WL ist.
  • Unterdrückt werden kann die Anzeige mit der Definition von (syntaxhighlight-Problem mit " im RE-Literal)

if (mw.config.get("wgRedirectedFrom")) {
   if (mw.config.get("wgAction" === "view")) {
      mw.util.addCSS("                   \
         .redirected-from-"
               + / +:*=%&?()\/'"{},/.replace(mw.config.get(wgRedirectedFrom), "")
               + "           {           \
            display: block ! important;  \
         }                               \
                     ");
   }
} else {
   mw.util.addCSS("           \
      .redirected-no-hide {   \
         display: none;       \
      }                       \
                  ");
}

und in der Vorlage in einem zweiten, inneren

<div class="redirected-from-{{{1|}}}}" style="display:none">

• Für die auftretenden Fälle von Abk-WL müsste man mal die Seitentitel analysieren.
  • Soweit ich das erstmal sehen kann, sind die Abkürzungen alle aus den 26 A–Z (Großbuchstaben ohne Umlaute). Sollte sich erweisen, dass bei irgendwas Kleinbuchstaben oder URL-encoded Zeichen oder Leerzeichen für die Bildung des BKL-Lemmas auftauchen, müsste dafür ein 2. Vorlagenparameter eingeführt werden mit

    <div class="redirected-from-{{{2|{{{1|}}}}}}}}" style="display:none"

• Wirkung: Bei einer Weiterleitung ist die äußere Klasse redirected-no-hide nicht wirksam, das äußere div wird angezeigt. Das innere div schaltet grundsätzlich auf unsichtbar (display:none); dieses wird genau dann aufgehoben, wenn der Name des Referrers zum redirected-from- der Abk passt. In diesem Moment könnte es zum Flackern kommen, oder aber manche ungebräuchliche Browser könnten das important verschlafen und den Hinweis nicht anzeigen. Diese Benutzer hätten dann halt Pech gehabt, aber Browser dieser Schlafmützigkeit wären mir nicht mehr bekannt.
  • Über ein encodeURL(wgRedirectedFrom) statt .replace() wäre gesondert nachzudenken. Gemäß CSS1/HTML4-Definitionen ist nicht vorgeschrieben, dass die Zeichen im Klassenbezeichner ASCII sein müssen. Ein schlichtes Ä würde keinen Ärger machen, das Prozentzeichen in einem encoded könnte das aber durchaus. Eventuell kann man an ein .toUpperCase() denken, ggf. in Kooperation mit einem {{uc:}}.
  • Das redirected-from- gibt für den Fall der Nicht-Buchstabe/Ziffer den ursprünglich aufgerufenen Seitennamen nicht exakt wieder; es ist aber egal und nur der Fall der vollen Übereinstimmung mit Abk ist relevant.
  • Es sind Browser im Gebrauch, die bei einer class nur den ersten Bezeichner für CSS-Darstellungen auswerten; deshalb zwei geschachtelte div, bei denen die CSS-relevante class jeweils einen eigenen Bezeichner hat.
• Auf einer diffpage, preview usw. sollte Vorlage:Weiterleitungshinweis grundsätzlich nie angezeigt werden; wäre immer sinnfrei. Über {{REVISIONID}} im {{ns:0}} kann die Vorlage das bereits selbst unterdrücken; JS würde dies wo immer möglich weiter fördern.
• Diese ausführlichen Darlegungen sind dafür vorgesehen, in Teilen in die Doku der Vorlage(n) aufgenommen zu werden.

Viel Spaß --PerfektesChaos 14:53, 29. Dez. 2011 (CET)

---

MediaWiki 1.19 ist aktiv und es gibt die globale Variable wgRedirectedFrom. --Fomafix (Diskussion) 22:16, 1. Mär. 2012 (CET)

Na dann! Für MediaWiki:Common.js:

mw.loader.using( "mediawiki.util", function() {
    var css = [];
    css.push(".noscript { display:none; }"); // <noscript>-Emulation via <div class="noscript">

    var red = false;
    if (mw.config.exists('wgRedirectedFrom') && (red = ""+mw.config.get('wgRedirectedFrom')) && red.length) // only set for redirects? maybe an array? will surely change in future
        css.push(".show-redirected { display:none; }"); // == hide if not redirected
    else {
        css.push(".hide-redirected { display:none; }"); // == show if not redirected
        red = red.replace(/[\u0000-\u00A0]/g, function(x) {
            return x.match(/[-_0-9a-zA-Z]/) ? x : x==" "?"_":"\\"+x;
        });
        css.push(".hide-redirected-from-"+red+" { display:none; }");
        css.push(".show-redirected-from-"+red+" { display:block; }");
        css.push("span.show-redirected-from-"+red+" { display:inline; }");
    }
    
    mw.util.addCSS(css.join("\n"));
});

Das sollte eigentlich alle möglichen Fälle abdecken. die Vorlage:Weiterleitungshinweis wird standardmäßig mit class="show-redirected" versehen, wenn man einzelne WL berücksichitgen will kann man das mit class="hide-redirected-from-Gefahrenpiktogramm" oder class="hide-redirected show-redirected-from-\!" tun.

• Damit braucht man auch kein style-attribut, welches mit !important overruled werden muss. Springen sollte nicht passieren, das common.js wird eh recht früh geladen – optimieren geht nicht.
• eine valide CSS-Klasse ist schwierig. Unter U+00A1 sind nur die üblichen Verdächtigen erlaubt. Ausgeschlossen werden müssen also \u0001\u0002\u0003\u0004\u0005\u0006\u0007\b\t\n\v\f\r\u000e\u000f\u0010\u0011\u0012\u0013\u0014\u0015\u0016\u0017\u0018\u0019\u001a\u001b\u001c\u001d\u001e\u001f !\"#$%&\'()*+,./:;<=>?@[\\]^`{|}~\u007f\u0080\u0081\u0082\u0083\u0084\u0085\u0086\u0087\u0088\u0089\u008a\u008b\u008c\u008d\u008e\u008f u0090\u0091\u0092\u0093\u0094\u0095\u0096\u0097\u0098\u0099\u009a\u009b\u009c\u009d\u009e\u009f\u00a0, wobei die meisten Steuerzeichen und [] eh nicht als Seitentitel erlaubt sind.
• Browser, die nur eine CSS-Klasse berücksichtigen, gehören in den Schrott und können nicht in DOM-Strukturen berücksichtigt werden.
• wgAction sollte keine Rolle spielen. Die Vorlagen müssen authentisch reagieren, und in diff/preview/sonstwas gibts auch so kein wgRedirectedFrom
• Das Ganze wurde mit noscript zusammengelegt, um stylesheets zu sparen (was von addCSS eigentlich selbst erledigt werden sollte)

meint -- ✓ ^Bergi 03:35, 2. Mär. 2012 (CET)

Guten Morgen; wieder fit?

• Bug report:
  • mw.config.isset meint wohl mw.config.exists
  • red.length meint wohl css.length
  • css.join("\n") – der Mehrwert von \n vor dem </style> hat sich mir nicht erschlossen.
  • css = []; css.push() – Argument von addCSS ist ein String.
• Eine versteckte Wertzuweisung knockt jeden späteren Bearbeiter aus:

       (red = ""+mw.config.get('wgRedirectedFrom') && red.length)

Im Übrigen ist sie völlig überflüssig; wgRedirectedFrom wird offenkundig dann und nur dann gesetzt, wenn es nicht leer ist. Wer trotzdem einen leeren String in wgRedirectedFrom befürchtet, mag setzen:

     var red = mw.config.get("wgRedirectedFrom");
     if (red) {
        // ...
     } else {
        // "" oder null (=undefiniert)
     }

• Das Ganze in eine Abfrage einzuschließen (etwa wgIsArticle) spart dem Gadget-Benutzer Ladezeit und DOM-Manipulation und Neuaufbau des CSS-Modells, um Seiten oder Zustände auszuklammern, bei denen die Vorlage nicht existieren kann (Spezialseite; edit immer unter wirklichem Titel – Anzeige schlimm?). Wenn es denn wirklich kein Gadget mehr sein soll, sondern zwangsweise jedem Leser per MediaWiki:Common.js aufgedrückt werden soll, muss es sorgsam mit dessen Ressourcen haushalten.
• Im Übrigen bin ich aber der Meinung, dass die Vorlage dann (MediaWiki:Common.js) so zu schreiben ist, dass CSS-Direktiven nur benötigt werden, wenn tatsächlich der Fall wgRedirectedFrom eingetreten ist; die Vorlage also standardmäßig ausgeblendet ist und nur in der Situation wgRedirectedFrom CSS-Direktiven eingefügt werden, die ein allgemeines oder selektives Einblenden (Abk.) ermöglichen.
• Mir schmeckt es überhaupt nicht, dass zwangsweise bei jedem Leser eine mühselige nachträgliche DOM-Manipulationim HEAD und CSS-Modell eingeführt wird, die nur in einem winzigen Bruchteil von Seitendarstellungen tatsächlich erforderlich ist.
• Wenn in der Vorlage auf eine Klasse verwiesen würde, die statisch in MediaWiki:Common.css als { display:none; } definiert ist (ein allgemeines .hide), und anschließend eine ID div#redirect-warning auf { display:block; } das ganze Teil sichtbar macht, müsste man die aktive CSS-Manipulation auf Fälle einer echten Weiterleitung beschränken können, sofern .hide und #redirect-warning dasselbe div identifizieren.
• mw.loader.using("site", function () { wird erst nach dem Laden der MediaWiki:Common.css ausgeführt.

VG --PerfektesChaos (D) 10:11, 2. Mär. 2012 (CET)

Nein, das ist explizit für die Common.js gedacht. Da frisst es keine Ressourcen, wird rechtzeitig (im Head) geladen und ist für alle Benutzer drin. Am (body-)DOM wird nichts manipuliert, das style-tag sowieso erzeugt (.noscript). 1 Zeile mehr CSS (bzw. 3 im Falle einer WL, selten) zu parsen wird man nicht mal messen können.

das mit dem überflüssigen Überprüfen wäre ich mir nicht so sicher. Wo du schreibst "offenkundig", bin ich da lieber vorsichtig. Im Bug steht auch was von Array (gut, bei genauem Lesen wieder revidiert). Möglicherweise vereinfachungswürdig, ja.

von deinem Bugreport stimmt nur der exists()-Fall (isset muss irgendwie von der PHP-Schiene gekommen sein). Und eine vergessene Klammer hab ich noch gefixt. Ansonsten gibt der join eines Arrays einen String zurück (ohne joiner am Ende), und eine versteckte Wertzuweisung sehe ich auch nicht - die ist extra.

Auf allgemeines Ausblenden würde ich gerne verzichten:

• User ohne js sehen dann nämlich gar nichts mehr von dem Hinweis
• display:none ist schwer zu überschreiben. block? inline? table? sonstwas? Eine Ausblendung ist deutlich einfacher
• common.css könnte man erwägen. Trifft dann aber wieder die noscript-user, und kann auch nicht weniger Flackern verhindern.

denkt -- ✓ ^Bergi 11:12, 2. Mär. 2012 (CET)

Habt ihr den mehrzahl-Parameter gesehen? Damit wird es dann unmöglich. Ich würde das erst ausblenden, dann auf ready warten und den Text vergleichen, wenn er gleich ist, das ganze wieder einblenden.

if( mw.config.exists( 'wgRedirectedFrom' ) ) {
 mw.loader.using( [ 'mediawiki.util' ], function() {
  mw.util.addCSS( '#Vorlage_Weiterleitungshinweis { display: none; }' );
  $( function() {
   if( mw.config.get( 'wgRedirectedFrom' ).replace( /_/g, ' ' ) === $( '#Vorlage_Weiterleitungshinweis_text' ).text() ) {
    mw.util.addCSS( '#Vorlage_Weiterleitungshinweis { display: block; }' );
   }
  });
 });
}

Dafür müsste mal allerdings in der Vorlage Parameter 1 in ein span mit id packen. Vorsichtshalber sollte man den Parameter vorher durch FULLPAGENAME schicken, damit er auch entsprechend ist. Der Umherirrende 20:21, 2. Mär. 2012 (CET)

Bei deiner Lösung wird derzeit die Vorlage standardmäßig eingeblendet :-)

Aufs DOM warten lassen wir lieber mal, und schon gleich Abgleiche mit Vorlagenparametern. Ersteres führt 100%ig zu Flackern, und zweiteres wird von viel zu vielen Unsicherheiten beeinflusst.

Meine Lösung ist ganz einfach ausgelegt, wie am Anfang von Fomafix vorgesehen: Die Tabelle bekommt neben der Id noch die Klasse show-redirected und wird damit nur eingeblendet, wenn man weitergeleitet worden ist. Fertig. bzw ist sie eingeblendet, wenn keine Skripte verfügbar sind

Der Rest ist nur für Spielkinder (und sollte wahrscheinlich gar nicht in die Vorlage). So könnte man die Box in American Standard Code for Information Interchange etwa mit den Klassen hide-notredirectedshow-redirected hide-redirected show-redirected-from-ascii show-redirected-from-ASCII versehen, damit sie wirklich nur bei diesen beiden WL angezeigt wird. Oder eben im Text sowas wie du wurdest von <span class="hide-redirected-from-ASCII">ascii</span><span class="hide-redirected-from-ascii">ASCII</span> hierher geleitet schreiben (mit den verschiedenen Kombinationen ist alles möglich). Das ist aber viel zu kompliziert für den Standardgebrauch.

Da wäre es fast einfacher, man böte in einem fest versteckten div (style="display:none;") verschiedene DOM-Bausteine an. Sobald eine Weiterleitung erkannt wurde, kann ein Script onDomReady den passenden Auswählen und mit großem Traraa in einen roten Kasten an den Anfang des Artikels animieren (einfaches Auftauchen lassen würde Flackern bedeuten). Der noscript-Nutzer wird sich sicher darüber freuen, dass er gar keine Information mehr bekommt.

meint -- ✓ ^Bergi 02:24, 3. Mär. 2012 (CET)

Stimmt, den Fall, das man die Seite ohne Weiterleitung besucht, hatte ich irgendwie nicht auf dem Schirm gehabt … Der Umherirrende 16:43, 3. Mär. 2012 (CET)

MW 1.19 ist da. Wie geht es nun weiter? --Flominator 16:33, 4. Mär. 2012 (CET)

Ich blicke hier nimmer durch. Wie geht es denn nun weiter? Was muss getan werden? --Flominator 13:15, 21. Apr. 2012 (CEST)