Wikipedia:Technik/Werkstatt

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
Abkürzung: WP:TWS
Logo Willkommen in der
Technik-Werkstatt

Hier können Wikipedia-Autoren Fragen zur Software rund um die Wikipedia stellen. Dazu gehören etwa:

  • Programmierung in JavaScript
  • Einsatz von CSS (Cascading Style Sheets)
  • Abfragen über die API
  • Vermutete Software-Fehler: Ist die deutschsprachige Wikipedia schuld, oder die weltweite Software? Ggf. Weiterleitung mittels Phabricator (ehemals: Bugzilla).
  • Fragen zu Tools (WP:LT) – soweit hier gängig
  • Probleme mit Netzwerk, Server, Browser.

Möglich ist alles, was zur Unterstützung der Mitarbeit an den Wiki-Projekten der WMF dient.

Sachdienliche Antworten können von allen gegeben werden; siehe ansonsten Wikipedia:Werkstätten zu den Gepflogenheiten.

Geeignete Fragen sind beispielsweise:
  • Mein CSS an dieser Stelle stellt nicht das dar, was ich möchte; warum nicht?
  • Ich will diese spezielle Aufgabe mit JavaScript automatisieren oder unterstützen. Auf Skin/Benutzerskripte habe ich nichts dazu gefunden. Gibt es dafür schon irgendwo etwas Fertiges?
  • Mein JavaScript geht nicht! Warum?
    Damit wir dir helfen können, benötigen wir von dir Angaben mit maximal möglicher Präzision:
    1. Welche Funktion und Wirkung erhoffst du dir?
    2. Welche Wirkung erfolgt im Moment?
    3. Welchen JS-Code hast du schon? Wikilinks angeben, ggf. darin bei längerem Code charakteristische Zeichenketten zum Suchen und Finden.
    4. Tritt das Problem nur in bestimmten Situationen auf? Nur bei bestimmten Artikeln: Wikilinks? Bei einem Browser geht es, mit dem anderen nicht – dann Versionsnummern!
    5. Gibt es Fehlermeldungen, insbesondere mit Zeilennummer? Copy&Paste + oldid/Uhrzeit dieses Skripts!
    6. Soll das Seitenlayout (Skin, Bedienungselemente) verändert werden? Dann diese Skin nennen.
    7. Abschließend als Lesetipp: Fehlerberichte – wie Sie Softwarefehler melden sollten.
  • Du hast einen mutmaßlichen Software-Fehler entdeckt, magst das aber nicht auf Phabricator melden? Wir prüfen gern, ob dies ein weltweiter Fehler ist oder ein in der deutschsprachigen Wikipedia hausgemachtes Problem (für das Phabricator nicht zuständig wäre) und leiten das Ergebnis geeignet weiter.
  • Ich möchte mit einem Skript Daten über die API abfragen, komme aber weder mit der Dokumentation noch mit der API-Spielwiese zurecht. Kann mir jemand sagen, welche Parameter ich senden muss, um diese Daten zu erhalten?
  • Es geht um „CSS in Vorlage“ – und du kannst dich nicht entscheiden, ob du hier oder in der Vorlagenwerkstatt richtig bist?
    Das ist völlig egal; in beiden Werkstätten werden dieselben Leute antworten. Weil aber unterschiedliche Kreise mitlesen und spezifisch archiviert wird, sollten reine Vorlagen-Angelegenheiten in der Vorlagenwerkstatt geklärt werden, also speziell zur Vorlagen-Systematik, Vorlagen-Parameter, Kategorien, Programmierung.

Technisch ist es nicht möglich, dass jemand anders deine .css- oder .js-Benutzerseiten verändert; auch wer besondere Rechte dazu hat, wird dies nicht tun.

Oder vielleicht doch vorher mal in die Anleitung gucken?
CSS JavaScript
Skin/CSS – CSS im Wikiprojekt Skin/JS – JS im Wikiprojekt
Browser-Cache schon geleert? Auch wirksam?

Nebenbei: Wenn dir so gut geholfen wurde, dass es ein paar Tage in diversen Situationen einwandfrei funktioniert, ist es gern gesehen, wenn du selbst einen Baustein {{Erledigt|1=~~~~}} setzt, damit die automatische Archivierung tätig wird.

Automatische Archivierung
Auf dieser Seite werden Abschnitte automatisch archiviert, die seit 10 Tagen mit dem Baustein {{Erledigt|1=~~~~}} versehen sind. Die Archivübersicht befindet sich unter Wikipedia:Technik/Archiv.

Inhaltsverzeichnis

Dauerbaustellen; Spezifikationen für wünschenswerte Werkzeuge[Quelltext bearbeiten]

  • Echo-Filter
  • Weiterleitungshinweis
  • Warnung wenn Zusammenfassung fehlt
  • Shortcut-Tooltip
  • Mehrfach-Sichtungen
  • prettytable und wikitable
  • Schriftgröße 100%
  • Beobachtung nach Karenzzeit beenden
  • Mit Maus verschiebbare große Grafik
  • Suchergebnis direkt anspringen
  • ISBN-Suchbeschleuniger
  • Speicher-Button-Aktionen
  • Wikilink statt URL in Zusammenfassungszeile
  • Hinweis auf Fehler im HTML-Text
  • Fehler im Bearbeitungsfeld hervorheben
  • Hervorhebung bestimmter Wikilinks
  • OSM weltweit
  • collapsible Herausforderung

MediaWiki:Common.js/watchlist.js[Quelltext bearbeiten]

Ich habe MediaWiki:Common.js/watchlist.js unter Benutzer:Fomafix/watchlist.js neu programmiert. Neben der Ersetzung veralteter Funktionen habe ich versucht das Ausblenden der Boxen während des Ladens per CSS zu erreichen, damit die Seite nach dem Laden nicht nochmal verrutscht. Allerdings weiß ich nicht, wie ich diese Funktion nun während des Ladens testen kann. Ich habe gerade gesehen, dass unter http://de.wikipedia.beta.wmflabs.org/wiki/MediaWiki:Common.js/watchlist.js bereits fast die gleiche Ersetzung der veralteten Funktionen vorgenommen hat. --Fomafix (Diskussion) 23:17, 9. Apr. 2012 (CEST)

Nur mal drübergeschaut: Mir fehlt da noch ein loader.using mit mediawiki.util und jquery.cookie. Mit Großbuchstaben beginnende Variablennamen sind mir persönlich nicht so lieb. Der dritte Parameter undefined wirkt überflüssig. Man könnte das CSS auch vereinfachen, wenn man die Rules kombiniert und dann nur noch ein display:none hat. Vielleicht komplett auf jQuery umsteigen? Du nutzt einmal setAttribute mit style und einmal obj.style. Auch wenn das letzter für nur ein Attribut einfacher ist, könnte man es einheitlich gestalten. Alles unverbindlich und nur wenn du es auch sinnvoll findest. Der Umherirrende 19:54, 11. Apr. 2012 (CEST)
Meine Überarbeitungen sind noch nicht abgeschlossen. Der Rahmen ist die Empfehlung von mw:Manual:Coding conventions/JavaScript#Closures, die restliche Programmierung ist noch nicht überarbeitet. Ich wollte zuerst Testen, ob CSS hier die gewünschte Verbesserung bringt. --Fomafix (Diskussion) 20:06, 11. Apr. 2012 (CEST)
Je nach Ergebnis von bugzilla:37187 würde ich statt dem Cookie lieber eine Benutzereinstellung sehen. --Schnark 10:21, 29. Mai 2012 (CEST)
Ja, wenn das inzwischen möglich ist, wäre das eine feine Sache. Vielleicht lässt sich das auch mit der neuen Funktion der Änderungen seit dem letzten Besuchen auch realisieren. Das wäre noch eleganter, denn das kommt ohne zusätzliche Speicherung von persistenten Daten aus und ist universeller. --Fomafix (Diskussion) 10:27, 29. Mai 2012 (CEST)
Kann über die API angefragt werden, was die letzte besuchte Revision einer Seite ist? Wenn ja wie? Den Besuchszähler kann man auf die aktuelle Revision setzten, indem man eine Seite besucht. Geht das auch über die API? --Fomafix (Diskussion) 09:51, 31. Mai 2012 (CEST)
Die Hilfe zu action=query&list=watchlist führt unter wlprop den Wert notificationtimestamp an: Adds timestamp of when the user was last notified about the edit, ein Update ist wohl über $.get('/w/index.php?title=...') möglich. Allerdings müsste man dazu alle Benutzer zwingen, eine bestimmte Seite zu beobachten; da man außerdem auf die Antwort der API warten müsste, würde es zudem zu sichtbaren Verzögerungen beim Ausblenden kommen. (Außer man blendet erst mal auf Verdacht aus, und dann je nach Antwort der API wieder ein.) --Schnark 10:08, 31. Mai 2012 (CEST)
Soviel habe ich inzwischen auch herausbekommen. wl_notificationtimestamp existiert nur, wenn die Seite in mw:Manual:Watchlist table ist. Zuerst müsste die Seite per API auf die Beobachtungsliste gesetzt werden, um das notificationtimestamp verwenden zu können. Das bringt mich auf eine andere Idee. Wäre es möglich das Einblenden und Ausblenden der Nachrichten über Einträge in der Beobachtungsliste zu steuern? Ich mache mir ein paar Gedanken. Auch das verzögerte Ein- oder Ausblenden ist ein wichtiges Thema. Derzeit geschieht Ausblenden auch etwas verzögert, weil JavaScript erst nach dem vollständigen Laden der Seite ausblendet. Ein zusätzlicher Request ist aber eine deutliche längere Verzögerung. --Fomafix (Diskussion) 16:05, 31. Mai 2012 (CEST)
Über notificationtimestamp wird das "Fette" auf der Beobachtungsliste oder die E-Mail-Benachrichtigung gesteuert. Dort steht der Timestamp der ersten Änderung, die man noch nicht gesehen hat. Per API kann man das aktuell nicht zurücksetzen (Bug 18758). Der Umherirrende 16:18, 31. Mai 2012 (CEST)
Bug 18758 ist umgesetzt worden. Was für Möglichkeiten gibt es nun? --Fomafix (Diskussion) 15:33, 2. Dez. 2012 (CET)

Egal, was wir tun, wir müssen es bald tun, denn in Kürze wird die Funktion getElementsByClassName entfernt, die in dem Skript noch verwendet wird. Ich bin dafür, Fomafix Variante zu übernehmen, ob wir von den Cookies auf etwas anderes umsteigen wollen oder können, kann ja immer noch diskutiert werden. Wobei ich inzwischen von meinem eigenen Vorschlag nicht mehr so ganz überzeugt bin, Cookies haben den Vorteil, dass sie automatisch entfernt werden und Benutzer, die eine Meldung versehentlich weggeklickt haben, eine (ihnen vermutlich bekannte) Möglichkeit besitzen, sie wieder hervorzuholen, nämlich einfach die Cookies zu löschen. --Schnark 09:41, 4. Nov. 2013 (CET)

Wenn es nur darum geht, das ist leicht rauszupatchen, indem man getElementsByClassName(docobj, 'div', 'watchlist-message') durch $('div.watchlist-message', docobj).get() ersetzt (getestet, funktioniert). --TMg 21:49, 5. Nov. 2013 (CET)
Ich hab mir die Version von Fomafix nochmal angesehen. So ganz funktioniert sie aktuell nicht. Zum einen ist .watchlist-message aktuell eine Klasse, keine ID. Vor allem sind die aktuell zwei Kästen in MediaWiki:Watchlist-summary per display:none standardmäßig ausgeblendet. Ich halte das für eine sehr gute Idee. Wer JavaScript abgeschaltet hat, hätte sonst überhaupt keine Möglichkeit, die Meldungen verschwinden zu lassen. Dass die Seite beim Einblenden der Kästen kurz hüpft, halte ich für kein Problem. Der Benutzer nimmt die Kästen auf diese Weise sogar besser wahr, liest sie kurz und klickt sie weg. Danach stört (dank des hart kodierten display:none) garantiert nie wieder ein Hüpfer den Seitenaufbau. --TMg 22:16, 5. Nov. 2013 (CET)
Ich habe auf beta einen kleinen Test gestartet: Das ready-Event tritt schon vor dem Laden des /watchlist.js-Skripts auf, sodass es für den Seitenaufbau keine Rolle spielt, ob die gelesenen Boxen gleich beim Laden per CSS (wie bei Fomafix) oder wie bisher per JavaScript nach dem Auftreten des ready-Events ausgeblendet werden. --Schnark 10:22, 6. Nov. 2013 (CET)

Völlig neuer Ansatz; auch „statt dem Cookie lieber eine Benutzereinstellung sehen“: Wikipedia:Technik/Baustellen/projectNotice. --PerfektesChaos 20:44, 23. Nov. 2013 (CET)

Fehler beim Zusammenspiel zwischen HotCat und bkl-check[Quelltext bearbeiten]

In dem Artikel Flugplatz Schwenningen werden fälschlicherweise ganz unten die Kategorien Kategorie:Verkehrslandeplatz und Kategorie:Flugplatz (Baden-Württemberg) als Link auf eine Begriffsklärungsseite markiert. Die Ursache liegt in dem Zusammenspiel zwischen von MediaWiki:Gadget-bkl-check.js mit MediaWiki:Gadget-HotCat.js. Zum Eingrenzen der Ursache habe ich den Artikel unangemeldet geöffnet und dann die beiden Gadgets mit folgenden Bookmarklet in dieser Reihenfolge geladen:

javascript:void( importScript( 'MediaWiki:Gadget-HotCat.js' ) )
javascript:void( importScript( 'MediaWiki:Gadget-bkl-check.js' ) )

Wo liegt hier der Fehler in den Gadgets? --Fomafix (Diskussion) 14:13, 30. Jun. 2012 (CEST)

Anscheinend schreibt HotCat den Sortierschlüssel der Kategorien in das title-Attribut. Für die Kategorien Kategorie:Verkehrslandeplatz und Kategorie:Flugplatz (Baden-Württemberg) ist das im obigen Beispiel Schwenningen. Bkl-Check erwartet im title-Attribut den Wikinamen des Ziels und überprüft, ob das eine Begriffsklärungsseite ist. Weil Schwenningen eine Begriffsklärungsseite ist, werden nun die Kategorien fälschlicherweise als Begriffsklärungsseite markiert. Beide Gadgets verlassen sich darauf, dass beim Start im title-Attribut der Wikiname ist und verändern anschließend das title-Attribut. Damit der Wikiname nicht verloren geht, sollte der ursprüngliche Wert des title-Attribut gesichert werden. Hier bietet sich einer Speicherung per .data() an. Wie kann man aber sinnvoll den neuen Wert des title-Attributs steuern, so dass mehrere Gadgets sich nicht stören? --Fomafix (Diskussion) 23:18, 30. Jun. 2012 (CEST)


  1. Glückwunsch zur Detektivarbeit.
  2. .data ist für die Zukunft zweifelsfrei der optimale Weg.
    • Nur ist mir nicht so ganz klar, was die Altbrauser da anstellen würden. Tun die das ins DOM? Kann das aus dem DOM wieder ausgelesen werden? Ich habe hier nur frische Brause in Reichweite stehen; ich weiß sowas immer nicht.
  3. Mittel der Wahl ist dann JSON/encode; das macht jQuery aber automatisch zusätzlich zum DOM.data.
    • Da müssten sich dann weltweit alle gadget-Programmierer absprechen.
    • In der Form .data(key,value):
      • key="bklCheck", value="BKS"
      • key="HotCat", value="sortkey"
    • In der Form .data(obj): Es wird ein { bklCheck: {...}, HotCat: {...} } oder so draus. (wenn bklCheck nur einen einzelnen String loswerden will, dann eben nur den; oder Array oder was immer)
    • Wer mit seinem Gadget ankäme, für den merkt jQuery, dass in .data schon was drinsteht, und packt seins dazu – sonst schreibt er sich in ein leeres {} hinein. Anschließend wird encoded+geschrieben – was jQuery für den Benutzer gleich miterledigt.
    • Ob man sich für eine der beiden Techniken entscheiden müsste, weiß ich nicht so genau. Mir scheint es so, als ob jQuery sowieso intern alle key=value zusammenschmeißt.
    • Das ist aber alles Zukunftsmusik; müsste jedoch schon Jahre im voraus in der MW-Welt propagiert werden.
  4. Für von jetzt auf gleich:
    1. bklCheck soll Kategorien in Frieden lassen, fertig.
      • Der wäre in deutscher Reichweite, solange er nicht disambigCheck heißt.
    2. HotCat mag dann in Kategorien schreiben, wozu sie Lust haben.
Gute Nacht --PerfektesChaos 01:30, 1. Jul. 2012 (CEST)
Bei meinem Gadget Benutzer:Fomafix/Gadget-redirecttitle.js habe ich das gleiche Problem. Dort habe ich es gelöst, indem ich vor dem überschreiben des title-Attributs den Inhalt gesichert habe per $( object ).data( 'title', object.title ). So kann mein Gadgets mehrfach ausgeführt werden und der korrekte Wikiname wird verwendet. Der ursprüngliche Wikiname ist eine gemeinsame Information und sollte von allen Gadgets gleich behandelt werden. Die von den Gadgets erzeugten Informationen könnten ebenfalls per .data() gespeichert werden. Aber wie kann die Erzeugung des neuen Titels bei vielen Gadgets sinnvoll gestaltet werden? --Fomafix (Diskussion) 14:31, 1. Jul. 2012 (CEST)


Ich war zum erste Mal mit der Frage von .data() unter Wiki-Bedingungen konfrontiert worden. Was ich dazu sagen wollte, wäre ausgeschlafen und zum zweiten Mal drüber nachgedacht:

  1. .data() wird dann wohl noch viele, viele Jahre warten müssen, weil offenbar die Altbrauser noch nicht mitspielen. Zumindest verbreitete Werkzeuge wie BKL-Check müssten noch eine Weile traditionelle Wege gehen.
  2. Wenn irgendwo .data eingesetzt wird, dann sollte weltweit eine MW-Konvention geschaffen werden:
    • In .data wird mit key=GadgetID und value=gadgetDataCollection geschrieben.
    • Grundsätzlich entspricht das dem Andocken an mw.libs, wobei die GadgetID pfiffig gewählt werden sollten.
    • value= kann ein einzelnes Datenelement sein, wenn das Gadget damit auskommt. Ansonsten ist es ein Objekt, das nach Belieben mit unterschiedlichen Komponenten gefüllt werden kann, spezifisch für das Gadget.
      Beispiel: key="HotCat", value="Schlussel"
    • Es darf nicht dazu kommen, dass die data verseucht werden mit unspezifischen key wie name oder count oder found oder so. Aus diesem Grund sähe ich auch title kritisch.
  3. Jedes Gadget muss für sich allein glücklich werden und unabhängig von anderen laufen. Wenn Benutzer sich widersprechende Aktivitäten lostreten, ist das deren Problem. Ein Gadget muss von seinem Start bis zum Ende mit seinen eigenen Daten arbeiten, und es sieht die allgemeinen Eigenschaften der Seite wie URL und mw.config – dementsprechend muss es sinnvoll arbeiten.
    • Ein Gadget darf nicht (oder nur auf allereigenste Gefahr) in die .data-key fremder Gadgets hineingucken, dort etwas auslesen oder gar ändern. Das gibt Ärger.
    • Ein Gadget kann sich den passenden title gern merken und sich in seinem eigenen .data-key ein fomafixRedir.titleSaved ablegen.
    • Wenn aber mehrere Gadgets gleichzeitig vom Benutzer aufgefordert werden, da durcheinander zu wirken, dann wird auch alles mit altem und neuem und mittlerem und endgültigem title durcheinander gehen.
  4. Inzwischen habe ich mich auch in die Quellcodes zu jQuery.data() näher eingelesen. Es gibt ein zentrales Objekt, das bei jedem DOM-Element abgelegt wird. Ob sie mit .data(obj) oder .data(key,value) gefüttet werden, ist offenbar völlig egal. jQuery macht auch ein JSON-Encoding, so dass wir uns um nichts mehr kümmern müssen.

Beste Grüße --PerfektesChaos 16:26, 1. Jul. 2012 (CEST)

Für das Speichern von privaten Daten eines Gadgets per $.data() passen Deine Erklärungen. Der Wikiname ist aber ein öffentlicher Wert, den mehrere Gadgets benötigen, und das title-Attribut ist eine öffentliche Ressource, die nur einmal vorhanden ist. Zentrale Funktion der Gadgets ist es das title-Attribut zu verändern. Mein Gadget und alle anderen Gadgets, die das title-Attribut verändern, beeinflussen damit die anderen Gadgets, die auf das title-Attribut angewiesen sind. Das Problem der gegenseitigen Beeinflussung kann behoben werden, indem der Wikiname nicht im title-Attribut, sondern an einer anderen festen Stelle gespeichert wird. Dann kann das title-Attribut verändert werden, ohne das andere Gadgets gestört werden. Sinnvoll wäre natürlich, dass der Wikiname von MediaWiki selbst direkt per HTML5 in ein entsprechendes data-Attribut geschrieben wird. Die Alternative ist es, dass das erste Gadget das title-Attribut in ein $.data() kopiert und alle weiteren Gadgets von dort den Wikinamen holen. Es muss aber einen festen Namen oder eine Funktion geben, aus dem alle Gadgets den Wikinamen auslesen können. Wenn aber mehrere Gadgets das title-Attribut verändern, dann hängt das Ergebnis von der zufälligen Ladereihenfolge der Gadgets ab. Hier suche ich noch nach einer Lösung. Bei http://api.jquery.com/data/ lese ich übrigens keine Einschränkungen auf bestimmte Browser. Zumindest beim Internet Explorer 8 scheint $.data() auch zu funktionieren. --Fomafix (Diskussion) 17:49, 1. Jul. 2012 (CEST)


Ich verstehe nicht, was du noch mit dem title-Attribut willst, sobald hinreichend viele Browser .data unterstützen?
  • Künftig wird dann das title-Attribut gar nicht mehr angefasst und jedes Gadget legt seine DOM-Element-bezogenen Privat-Infos ausschließlich im .data() ab.
  • Wobei man auch im Moment eigentlich kein title-Attribut bräuchte.
    • Nur wer mit document.links[] arbeiten würde und befürchten müsste, dass irgendwo zusätzliche Links in die HTML-Seite eingefügt oder aber solche gelöscht werden und die Seite sich massiv dynamisch verändert. Ansonsten kann man sich die Nummern interessanter Links merken und auf JS-Ebene abspeichern als
      meins = { "17": "dies", "39": "jenes" }
    • Bei dir analog:
      Du müsstest die Elemente, die du in redirects findest, erstmal in ein laufendes Array (gadget-global) pushen:
      collection.push( this ) (bzw. collection = [ this ])
      Anschließend willst du ja wohl blockweise je 50 eine query machen; dann holst du halt von 0...<50 alle collection[i].title (oder extrahiert aus collection[i].target – siehe unten) wieder aus dem Array und verkettest sie mit |.
      Array macht sich hier glücklicher als {}.
      Wenn die query eintrudelt, gehst du durch die collection[i] und stellst mit diesen DOM-Elementen an, was immer du magst.
      Wenn es mehr als 50 redirs sind, muss halt noch ein gadget-globales m von 0 über 1 die Elemente Nr. 50–99 abfragen, usw.
      Wenn du mehrfache Aufrufe des gadgets auf derselben Seite sicherstellen möchtest, kannst du eine Klasse dranhängen: fomafix-redir-hier-war-ich-schon
      Wenn du einzelne Links identifizieren und mit der collection verbinden willst, kannst du eine ID="fomafix."+i zuweisen.
      Ansonsten begreife ich wirklich nicht, was ihr immer mit dem title habt; das ist eine optische Präsentation für Benutzer, kann jederzeit geändert werden (as see) und hat keinen Anspruch auf Schutz und Unveränderbarkeit. Zurzeit bietet es im Ausgangsstadium eine etwas freundlichere Aufbereitung des Linkziels; da muss ggf. halt am Encoding des href ein wenig geguckt werden, wie es zur query passt, und dann hast du den Original-title.
      Die Variable redirects mit dem Suchergebnis scheinst du nicht zu benötigen; dann kannst du auch .each() direkt an .find() hängen.
  • Und BKLcheck wäre gut beraten, zumindest die im ANR oft zu erwartenden NR ^(Datei|Kategorie|Wikipedia): abzufangen und nicht in die query zu schieben oder title zu misshandeln; genau genommen aus den ganzen wgFormattedNamespaces!==["0"] dynamisch (oder lieber statisch) einen no-query-RegExp bauen.
    • Und wenn man schon grad dabei ist, möge BKLcheck doch bitte die href durch diesen regexp schieben, fragment wegschmeißen und sich im Erfolgsfall das Ergebnis notfalls API-geeignet umformatieren. Dann kann title in Frieden gelassen werden.
  • Also, das mit den Altbrausern durchschaue ich wie gesagt nicht; ich habe nur relativ aktuelle in Reichweite, und ich mag die spitzen Schreie von Benutzern nicht, die auf irgendwelchen Altlasten arbeiten und sich über Fehler beschweren, die ich nicht reproduzieren kann. Neben HTML5 geht es wohl um DOM3 (DOMUserData) und das ist seit 2004 auf dem Markt. Ab wann für IE6 und irgendwelche Safaris das berücksichtigt wurde, durchschaue ich nicht. Damit lassen sich bereits DOM-Funktionen aufrufen und DOM-Elemente mit Werten belegen, während die Repräsentation über HTML5 erst deutlich später erfolgte.
Liebe Grüße --PerfektesChaos 21:08, 1. Jul. 2012 (CEST)
Die Variable redirects brauche ich seit dem Umbau der Datenstruktur nicht mehr. Ich habe sie entfernt. Deine weiteren Hinweise zu der Datenstruktur in meinem Gadget verstehe ich nicht. Ich will nicht mehrfache Aufrufe meines Gadgets verhindern, sondern ich will erreichen, dass trotzt mehrfachen Ausführens das gleiche Ergebnis herauskommt und auch, dass andere Gadgets nicht beeinträchtigt werden.
Das Ziel meines Gadgets wie auch einiger anderer Gadgets ist es dem Anwender einen erweiterten Tooltip anzuzeigen. Daher wird das title-Attribut geändert. Dafür ist das title-Attribut auch schließlich da.
Die Gadgets benötigen den Wikinamen der Links als Basis. Mit Aufwand lässt sich der Wikiname auf dem href-Attribut extrahieren. Einfacher geht es aber, wenn man den Wikinamen aus dem title-Attribut nimmt. Beide Attribute könnten aber von anderen Gadgets verändert werden. Daher wäre es sinnvoll, wenn es eine globale Funktion gibt, die mir zu einem Link den ursprünglichen Wikinamen gibt. In meinem Gadget habe ich das ohne separate Funktion inline mit $.data() umgesetzt. Wenn das alle Gadgets so machen würden, dann gäbe es kein Problem mit einem überschriebenen Wikinamen.
Für meine eigentliche Frage, wie sich mehrere Gadgets kooperativ auf einen neuen Wert für das title-Attribut einigen können, bist Du leider nicht eingegangen. --Fomafix (Diskussion) 22:47, 1. Jul. 2012 (CEST)
Kurz vorab:
  • Einfacher geht es aber, wenn man den Wikinamen aus dem title-Attribut nimmt.“ – Ja, aber genau das ist das Problem. Der Tooltip kann von jedem nach Belieben verändert werden, und dann ist das überhaupt nicht mehr einfacher. Der Tooltip darf einfach nicht ausgewertet werden.
  • Mit Aufwand lässt sich der Wikiname auf dem href-Attribut extrahieren.
if ( ! href.indexOf( "/wiki/" ) {
   pagename = decodeURIComponent(href.substr(6).replace(/#.*$/,"")).replace(/_/g, " ");
   bigAction(pagename);
}
oder so ähnlich, und fertig ist die Laube.
Domain-relative URL vorausgesetzt, wie sie wohl im Moment in Mode sind; sonst halt das Projekt davorsetzen.
  • Ich sehe keinen Sinn darin, den title zu konservieren. Aber wer ihn unbedingt wiederhaben möchte, bekäme ihn wie vorstehend als pagename.
  • Jedes Gadget, das von einem Benutzer geliebt wird, mag sonstwas in den Tooltip reinschreiben. Einigen können die sich überhaupt nicht. Wenn Benutzer sich eine Kombination aus mehreren Gadgets zusammenbauen, landet da eben das, was er mag. Man könnte auch bei jedem ANR-Wikilink den Einleitungsabschnitt des verlinkten Artikels per API extrahieren, alle Syntaxelemente herausstrippen und das dann als plain text in den Tooltip schreiben. (In Java gibt es HTML-formatierbare Tooltips, und irgendwas neues geistert bei jQuery herum, tipsy oder so, das kann das auch.)
  • Das Format eines title kann sich auch mal ändern: bugzilla:542
Es ist mir schon klar, dass du das Gadget mehrmals hintereinander auf eine schon geladene HTML-Seite anwenden möchtest (es können sich eigentlich eher nur die Eigenschaften der Linkziele geändert haben, der aktuelle Seiteninhalt doch wohl weniger?). Ich schau mir auch gern demnächst deinen Quellcode genauer an; meine aber, dass es sich mit dem Verzicht auf das Auslesen von .title schon weitgehend erledigt hätte. Mir ist allerdings der praktische Arbeitsablauf und Zweck von mehrfachem Gadget-Start nicht so ganz einleuchtend; ich hätte in der Situation eher einen Inhibitor gesetzt.
Schönen Abend --PerfektesChaos 23:39, 1. Jul. 2012 (CEST)
Das mit dem mehrfachen Ausführen des Scripts war nur ein Test, ob andere Scripte, also auch das Script selbst, beeinflusst werden. Mein Script soll aber nicht notwendigerweise mehrfach ausgeführt werden. Solange mein Script den Wikinamen aus dem title-Attribut liest und danach in das title-Attribut schreibt, beeinflusst es immer andere Scripte, die auf das title-Attribut angewiesen sind. Für mein Skript konnte ich das umgehen, indem ich den ursprünglichen Wikinamen per $.data() sichere. Wenn das alle anderen Scripte auch so machen würden oder MediaWiki selbst so etwas machen würde, dann wäre der Zugriff auf den Wikinamen sichergestellt. So wie ich Dich aber verstanden habe, glaubst Du nicht daran, dass man sich auf eine gemeinsame $.data()-Struktur einigen kann und dass man sich auf den Wikinamen im title-Attribut nicht verlassen kann. Deiner Meinung nach sollte der Wikinamen aus dem href-Attribut extrahiert werden.
Ich habe es für mein Script so umgesetzt und habe das nun nicht mehr notwendige $.data() wieder entfernt. Deine oben angegebene Funktion habe ich mit wgArticlePath verallgemeinert und ist jetzt die Umkehrfunktion von mw.util.wikiGetlink(). Diese Funktion sollte in mw.util aufgenommen werden, denn das sollten dann alle Gadgets verwenden um den Wikinamen eines Links zu bekommen. --Fomafix (Diskussion) 14:23, 3. Jul. 2012 (CEST)
  • Richtig; wenn man bei .data etwas saven wollte, dann müsste es ein fullTitle sein: Die wgPageName sind mit Namensraum und Unterstreichungsstrich; die wgTitle ohne Namensraum und mit dekodierten Leerzeichen.
    • Dass im Moment der Startwert des Tooltip-title-Attributs eines Links zufällig grad dieses fullTitle ist, kann ja Arbeitserleichterung sein – aber woher weiß ich, dass da noch der Startwert drinsteht?
  • Du bist ja oft auf bugzilla unterwegs; ich hab da noch nicht mal einen Account: Mach doch mal höheren Ortes den Verbesserungsvorschlag samt Patch:
    • mw.util.wikiUrldecode(url)
      • Macht ein decode(), .replace(/_/,' ') und schlägt sich mit Doppelpunkten und Schrägstrichen herum; Resultat: wgTitle plus Namensraum.
      • Voraussetzung: url gehört zum gleichen Projekt
        • host-relativ, beginnt mit genau einem Schrägstrich
        • Protokoll-relativ, Domain der url ist die aktuelle Domain
        • http oder https angegeben, aber keine exakte Übereinstimmung erforderlich; aktuelle Domain
      • Zugabe zum wgArticlePath: /[?&]title=([^#&]+)([#&])?.*$/

Erfrischenden Tag --PerfektesChaos 15:32, 3. Jul. 2012 (CEST)

Ich habe mit Bug 38598 ein Vorschlag zum Befüllen der data-*-Attribute von MediaWiki gemacht. Vielleicht bekommen wir damit mal eine universelle Lösung. --Fomafix (Diskussion) 19:21, 23. Jul. 2012 (CEST)

Fein.
@bugzilla: Tja; vielleicht hätte auch gleich eine Begründung mitgeliefert werden sollen, als Motivation für Mitleser und die weltweite Gemeinde.
  • The objective for these three items is to provide an easy and undisturbed access to properties of the linked page.
  • Furthermore, the proposed naming scheme "data-mw-property" should be maintained by further items to avoid conflicts with attributes attached by user.
  • The reason for the suggested properties in particular is to get simplified access to characteristics of the linked page. Some might be derived already from URL by pattern matching and comparison with namespace name list within the same project, requiring slight efforts. Others, like final target of redirect, disambiguation page or namespace names used in a sister project are not available by URL evaluation. However, the server has better access to such information than the local site, impatiently waiting for some API retrieval. Any link to something within a wiki may be equipped with a set of properties if deviating from the current page context.
  • The "data-mw-title" property in particular is the page name of the target, while the title= attribute in HTML is a tooltip for visual display. Users might modify this by tipsy formatting or display the lead section of the article.
  • On the horizon, after availability of HTML5 by majority of user browsers, a successor for evaluation of class="mw-redirect" and other workarounds is shining up. Gadgets can use the additional information for meaningful user support.
@TMg: Der Hintergrund ist im vorstehenden Abschnitt zu finden.
Schönen Tag --PerfektesChaos 09:44, 24. Jul. 2012 (CEST)
@Steef Danke für bugzilla:38598#2
oder Fomafix:
Das war eigentlich so gedacht, dass jemand mit bugzilla-account diesen Text dort direkt posted, und Wikisyntax→bugzilla.plain.text.75chars wandelt. (siehe Quelltext-Kommentar hier drunter)
Heiß. Immer noch. --PerfektesChaos 23:31, 25. Jul. 2012 (CEST)

Ich nutze einfach mal ganz dreist diese Möglichkeit, ein wenig Werbung für importScript('Benutzer:Flominator/BklRedir.js'); Link zu machen :) --Flominator 18:52, 1. Jul. 2012 (CEST)

OpenStreetMap-Karte bei HTTPS[Quelltext bearbeiten]

Derzeit funktioniert die eingebaute OpenStreetMap-Karte nicht vollständig, wenn Wikipedia über HTTPS statt über HTTP aufgerufen wird. Beispiel: Beim Artikel Deutschland wird durch ein Klick auf den Knopf Karte folgende Seite eingebunden:

Bei HTTP funktioniert alles. Bei HTTPS fehlen das rote Overlay und die Stecknadeln für andere Artikel. Bisher hat das auch bei HTTPS funktioniert. Wo liegt der Fehler? --Fomafix (Diskussion) 14:29, 14. Sep. 2012 (CEST)

Es müsste bei HTTPS funktionieren, wenn in tools:~kolossos/openlayers/kml-on-ol.php statt
einfach protokollrelative Links verwendet werden:
  • //toolserver.org/~master/osmjson/getGeoJSON.php und
  • //toolserver.org/~kolossos/geoworld/marks.php
Kann das jemand beheben? --Fomafix (Diskussion) 14:49, 15. Sep. 2012 (CEST)
Irgendjemand hat es umgestellt. Es funktioniert nun wieder mit HTTP und HTTPS. Vielen Dank. --Fomafix (Diskussion) 11:32, 17. Sep. 2012 (CEST)

Es wäre noch schön, wenn die erzeugten Links auf die entsprechenden Wikipedia-Artikel auch protokollrelative URLs verwenden würden, damit man nicht von HTTPS auf HTTP umgelegt wird, wenn man einen neuen Artikel anklickt. Außerdem sollten die generierten URLs korrekt encoded werden. --Fomafix (Diskussion) 11:32, 17. Sep. 2012 (CEST)

Und auch sicherheitsgründen sollten die beiden eingebundenen JavaScript-Dateien ebenfalls über ein protokollrelativen Link geladen werden: Statt:

<script src="http://toolserver.org/~osm/libs/jquery/latest/jquery-min.js" type="text/javascript"></script>
<script src="http://toolserver.org/~osm/libs/openlayers/2.12/OpenLayers.js" type="text/javascript"></script>

besser:

<script src="//toolserver.org/~osm/libs/jquery/latest/jquery-min.js" type="text/javascript"></script>
<script src="//toolserver.org/~osm/libs/openlayers/2.12/OpenLayers.js" type="text/javascript"></script>

--Fomafix (Diskussion) 11:44, 17. Sep. 2012 (CEST)

Auch die folgenden Links sollten in protokollrelative Links gewandelt werden:

Dann werden nur noch die Bilder ohne protokollrelativen Links geladen. --Fomafix (Diskussion) 09:17, 19. Sep. 2012 (CEST)

Sieht so aus, als ob es (wieder) funktioniert, ansonsten mit User:Kolossos sprechen, der kann es entsprechend auf der Toolserver-Seite ändern. Der Umherirrende 09:34, 27. Okt. 2012 (CEST)

Die Links sind auch umgesetzt. --Kolossos (Diskussion) 17:28, 28. Okt. 2012 (CET)
Danke fürs umsetzen der Links auf protokollrelative Links. --Fomafix (Diskussion) 08:35, 30. Okt. 2012 (CET)

Eine Sorte von Links fehlt noch und zwar die Links auf die Artikel. Diese Links werden in tools:~kolossos/geoworld/marks.php erzeugt und sind derzeit HTTP-Links. Vermutlich müssten hier auch protokollrelative Links möglich sein. --Fomafix (Diskussion) 08:35, 30. Okt. 2012 (CET)

Außerdem fehlt bei diesen Links die Ersetzung von ' ' nach '_' und potentiell weiteren problematischen Zeichen. --Fomafix (Diskussion) 09:18, 25. Nov. 2013 (CET)
Die Ersetzung erfolgt bei Anchor-Elementen, Artikelnamen mit Javascript-Injection werden wohl bei der Eingangskontrolle auffallen. --Kolossos 20:49, 26. Nov. 2013 (CET)
Statt auf die Eingangkontrolle zu verlassen, sollte sinnvoller auf ein simples Encoding eingesetzt werden:
https://toolserver.org/~kolossos/geoworld/marks.php?LANG=de&thumbs=0&bbox=-4.2642046440962,45.463868737325,25.174760199654,56.338265659873 sollte statt
<a target="_blank" href="http://de.wikipedia.org/wiki/Münster (Westfalen)">
folgendes enthalten:
<a target="_blank" href="//de.wikipedia.org/wiki/M%C3%BCnster_%28Westfalen%29">
Meiner Meinung nach sollte auch das target="_blank" entfallen. --Fomafix (Diskussion) 21:26, 26. Nov. 2013 (CET)
Das Skript ist anfällig gegen JavaScript Injection. Ich lasse die Einbindung in MediaWiki:Common.js deaktivieren, bis der Encodingfehler behoben ist. --Fomafix (Diskussion) 21:54, 3. Dez. 2013 (CET)

Habs eingebaut, wenn es dich glücklich macht. Von weiterem persönlichen Kontakt bitte ich dich abzusehen... --Kolossos 21:59, 4. Dez. 2013 (CET)

Danke für das Beheben des Encodingfehlers, der JavaScript Injection ermöglichte.
Wie ich oben geschrieben habe, wäre es trotzdem weiterhin sinnvoll statt
<a target="_blank" href="http://de.wikipedia.org/wiki/M%C3%BCnster%20%28Westfalen%29">
protokollrelative Links zu verwenden:
<a href="//de.wikipedia.org/wiki/M%C3%BCnster_%28Westfalen%29">
damit HTTPS nicht verlassen wird, wenn ein Link angeklickt wird. --Fomafix (Diskussion) 22:12, 4. Dez. 2013 (CET)

Erledigt. --Kolossos 22:34, 4. Dez. 2013 (CET)

@Kolossos: Äh, was genau hast du behoben? Nach Fomafix Meldung habe ich selbst ein bisschen probiert und eine Möglichkeit gefunden beliebigen Code in den iframe einzuschleusen. Per Same-Origin-Policy ist das zwar kein großes Problem, aber zumindest Web-Bugs sind möglich. Und was immer du getan hast, mein Hack funktioniert noch immer. --Schnark 09:49, 5. Dez. 2013 (CET)
Was genau hast du gemacht? Rawurlencode bei den Links ist jetzt drin und auch das protokollneutrale verlinken auf Artikel. --Kolossos 12:50, 5. Dez. 2013 (CET)
Oh, ja, da sind noch viel mehr potentielle Lücken drin. JavaScript-Code sollte einfach nicht dynamisch erzeugt werden. --Fomafix (Diskussion) 13:31, 5. Dez. 2013 (CET)
Gibt es noch irgendwie konkretere Aussagen? In der marks.php wird garkein JavaScript erzeugt, sondern KML. --Kolossos 18:36, 6. Dez. 2013 (CET)
Ich hab dir eine E-Mail geschickt. --Schnark 11:04, 7. Dez. 2013 (CET)

@Fomafix, Kolossos, Schnark: Altes Thema, aber die Sicherheitslücken sollten geschlossen sein, bevor das archiviert wird. Funktioniert HTTPS jetzt oder kommt das mit dem Umzug nach Labs? Der Umherirrende 22:07, 20. Sep. 2014 (CEST)

Ich finde weiterhin Möglichkeiten von JavaScript-Injection. --Fomafix (Diskussion) 22:55, 20. Sep. 2014 (CEST)
Hast du einen Toollabs-Account? dann könnte ich dir Zugriff auf das Skript geben. Ansonsten, kann ich mit deine allgemeinen Aussage nicht viel anfangen. Du kannst mir aber gern eine Mail mit näheren Hinweisen schicken. --Kolossos 17:59, 21. Sep. 2014 (CEST)

Erweiterung der Signatur-Zeitstempel auf Diskuseiten[Quelltext bearbeiten]

Ich ärgere mich immer mal wieder, wenn auf Artikeldiskussionsseiten Mängel angemerkt worden sind, die nie kommentiert wurden. Es ist mitunter relativ mühsam, die Artikelversion zu suchen, die zum Zeitpunkt des Diskuseiten-Eintrags gültig war und diese mit der aktuellen Version zu vergleichen. Ich würde mir daher eine Erweiterung in der Form wünschen, dass auf Artikeldiskuseiten hinter jeder Signatur zwei Links auftauchen in der Form:

  • Anmerkung -- Signatur Zeitstempel ([Link zur zugehörigen Artikelversion|Version], [Difflink dieser Version zur aktullen Version|Diff])

Wäre so etwas prinzipiell denkbar? --Mabschaaf 11:01, 27. Feb. 2013 (CET)

  • Es ist nicht nur prinzipiell denkbar; es ist ganz konkret technisch lösbar.
  • Scheint mir ein sinnvolles und wünschenswertes Hilfsmittel zu sein.
  • Es geht nicht nur auf Artikel-Disku, sondern auf jeder seitenbezogenen Diskussionsseite.
  • Zwar sind Diskussionsseiten seit Jahren ein Auslaufmodell, LiquidThreads gerade beerdigt und mw:Flow noch in der Konzeptionsphase, aber auch da gibt es den Bezug zu einer spezifischen Version einer Seite im Namensraum.
  • Konkret würde das so aussehen:
    • Dass es in der Werkzeugbox einen Knopf gibt [Diese Disku mit Versions-Links ausstatten] – auf besonderen Wunsch immer schon so ausgerüstet, aber das bringt die Ladezeit in die Kniee und wäre nur opt-in.
    • Wenn ausgelöst, werden alle Verlinkungen auf href="/wiki/Benutzer(in)? gesucht; blinkende Signaturen mit Bildchen dabei ignoriert werden müssen; irgendwann würde aber ein Datumsformat 11:01, 27. Feb. 2013 (CET) oder CEST (Gadget-Zeitzonenkonverter beachten) folgen. (Vorlage:Unsigniert usw. auch noch bedenken)
    • Hinter dem Zeitstempel wäre ein Button einzufügen.
    • Dieser Zeitstempel, der leider von MediaWiki nicht speziell als ~~~~~/~~~~~~ klassifiziert wird, lässt sich semantisch auslesen und in formales Datum überführen.
    • Mittels der API kann man zum aus dem Seitennamen der Diskussionsseite leicht erratbaren Seitennamen der SUBJECTPAGE (Vorsicht: Verschiebung, curid nötig?) eine API-Abfrage generieren. Sie würde aber erst gestartet werden, wenn auf diesen Button draufgeklickt wird.
    • Beim ersten Klick würde per API die Revisionsliste abgerufen werden:
      • api.php?action=query&prop=revisions&titles=
      • Mit dem Parameter rvend= auf ein Zeitfenster eingegrenzt. rvstart= ist nicht sinnvoll; es findet sich beim Ende-Zeitpunkt schließlich die Version, die zur Zeit des Diskussionsbeitrags gültig war.
    • Dabei ist zu beachten, dass diese Zeitstamps in der lokalen Server-Zeit ablaufen, auch die Umstellung auf Sommerzeit mitmachen, mutmaßlich den gleichen angezeigten Nennwert haben und nicht in UTC oder Winterzeit vorliegen. Die Speicherung kann ein paar Sekunden abweichen. Das Intervall sollte ein paar Stunden weiter gefasst sein als akut benötigt; etwa begrenzt auf rund 50 Einträge rückwirkend.
    • Die API-Ergebnisse sollte man im JS-App-Objekt dieser Disk cachen als von/bis/RevID-Array; bei einem Klick auf einen anderen Disku-Beitrag wäre zu klären, ob nicht für das neuerlich gesuchte Zeitintervall bereits ein Eintrag bekannt ist. Bei mehrfachen Abrufen wird nach und nach die ganze Versionsgeschichte der SUBJECTPAGE hinterlegt.
    • In dem Moment, in dem festgestellt wird, dass der Zeitpunkt in einem Zeitintervall liegt, ist die RevID bekannt.
    • Nun kann diese RevID angezeigt werden in einem separaten Fenster/Tab; konfigurierbar
      • immer in demselben Zweitfenster
      • dasselbe Zweitfenster für jede Version dieser SUBJECTPAGE
      • jede RevID in einem Zweitfenster, dies aber möglichst wiederverwendbar. Das ist über die Hinterlegung des window.open() im von/bis/RevID-Array und seine momentane Eigenschaften (closed, URL) möglich.
    • Ist die RevID bekannt, kann auch das Difflink gebaut werden. Würde also (zur besseren Unterscheidbarkeit zwischen Signatur-Klickibunti und ursprünglichem Seiteninhalt) auf eine Ausstattung mit einem Anforderungs-Button nach jedem Beitrag hinauslaufen (sowas wäre unmöglich auf einer normalen Seite), der sich beim Anklicken nach Eintreffen des API-Ergebnisses/Cache in zwei Buttons oder eine Fehlermeldung wandelt. Der erste Button wird mit menschenlesbarer Zeitangabe der SUBJECTPAGE beschriftet, auf dem zweiten steht dann schlicht „Diff“.
    • Alle weiteren (zumindest unmittelbar vorangegangenen) Disku-Beiträge können dann mit etwas Glück von dem mitgelieferten Schwung an 50 Einträgen der Versionsgeschichte profitieren und würden sich sofort wandeln.
  • Nette Programmierübung. --PerfektesChaos 13:39, 27. Feb. 2013 (CET)
Beispiel für eine API-Anfrage zur Ermittlung der Artikelversion zu einem bestimmten Zeitpunkt. Trivial für einen einzelnen Diskussionsbeitrag, alles andere als trivial für eine komplette Diskussionsseite (siehe oben). --TMg 19:06, 7. Mär. 2013 (CET)

Benutzernamen aus Signaturlink anzeigen?[Quelltext bearbeiten]

Hallo Skin-Werker, unter Hilfe Diskussion:Signatur#Benutzernamen aus Verlinkung anzeigen? fragte ich nach einer Möglichkeit bei Signaturen, die nicht den Benutzernamen anzeigen, dies mittels CSS oder JS einzublenden. Ist jetzt nicht so, dass ich ohne das nicht leben könnte, aber manchmal rätsele ich zunächst, weil ich etwas nicht auf Anhieb nachvollziehen kann. Sei es, dass ich beim Nachvollziehen diskutierter Änderungen in einer Versionsgeschichte nach einem Phantom gesucht habe, weil der Signatur-Name nicht der Benutzername ist oder dass auf Benutzerbeiträge in einer Diskussion mit dem Benutzernamen Bezug genommen wird, dieser aber dort nicht auftaucht. Da es offensichtlich mehrere Benutzer gibt, die sich mit verdeckten Benutzernamen schwer tun, könnte das ein nützliches Gadget sein. Ob das Gadget den Benutzernamen nur ergänzt oder die Signaturveränderung in der Anzeige weitgehend unwirksam macht, wäre offen. Hat jemand von euch Interesse das umzusetzen? Grüße --Diwas (Diskussion) 23:28, 17. Apr. 2013 (CEST)

Nicht mehr ganz Stand der aktuellen Technik, funktioniert aber immer noch recht gut: Wikipedia:Skin/Baukasten#Wahren Benutzernamen anzeigen.
Einzubinden mit
importScript('Benutzer:Ce2/JavaScript/showusers.js'); //[[Benutzer:Ce2/JavaScript/showusers.js]]
in deiner common.js. --Schnark 09:17, 18. Apr. 2013 (CEST)
Ah, stimmt, danke, diesen Baukasten haben wir ja auch noch. Das ist so das Problem mit Schnipseln ohne Doku-Seite; zumal nur der nicht mehr aktive Ce2 Werbung für sich machen sollte.
Für eine Benutzerin: ist das allerdings blind. Dafür kann Ce2 nichts; 2006 gab es in der Wikipedia noch keine Benutzerin.
Eine Neukodierung nach sieben Jahren wäre trotzdem mal eine Überlegung wert; auch mit benutzerdefinierten Optionen, was genau mit maskierten Benutzernamen geschehen solle, und auf welchen Seiten. Im WP:K sind Autorenkürzel Standard. Im ANR (-QS) und auf Spezialseiten wäre der momentane Aufruf hingegen nur selten sinnvoll.
@Diwas: Wenn du das gelegentlich ausprobiert haben solltest, kannst du ja schildern, ob es dich bereits glücklich macht.
Sonnigen Tag --PerfektesChaos 09:56, 18. Apr. 2013 (CEST)
Danke, um den (einen oder anderen) sonnigen Tag nicht zu verpassen ... hab ich es erst jetzt ausprobiert. Tut eigentlich was ich meinte. Viele Benutzerinnen, noch dazu mit der Angabe und noch dazu abweichender Signatur, wird es wohl nicht geben. Da ich mir beispielsweise Administratoren kennzeichnen lasse, hab ich jetzt hinter dem (A) nochmal den Benutzernamen, auch wenn er schon davor offen steht, aber das macht ja nichts. Grüße --Diwas (Diskussion) 21:36, 27. Apr. 2013 (CEST)

Bei Benutzer:Steindy funktioniert es allerdings nicht. --Diwas (Diskussion) 14:52, 17. Jul. 2013 (CEST)

darstellung von thumbs[Quelltext bearbeiten]

ich glaub meine frage Wikipedia:Auskunft #darstellung von thumbs ist hier besser aufgehoben. seit einiger zeit überlagern sich bei mir manchmal ein thumb und text, meine anfrage in der auskunft war:

normalerweise werden bilder als thumbs am rechten rand voll dargesttellt und wenn zu wenig platz ist, rückt es nach unten und überlagert nicht text links. wenn ich mein browserfenster (firefox 20.0.1) schmaler ziehe überlagert sich in Landtagswahl in Hessen 2009 das thumb der wahlkreisergebinisse mit der tabelle, sodass die tabellenzahlen über dem bild dargestellt werden.
ist das normal, bzw. habt ihr das problem auch? gruß --Wetterwolke (Diskussion) 20:54, 5. Mai 2013 (CEST)

hängt das mit dem transpartenten hintergrund des bildeszusammen? gruß --Wetterwolke (Diskussion) 00:54, 6. Mai 2013 (CEST)

Faszinierend. Zur Info: Ich kann das in Opera 12.15 nachvollziehen. Auch IE 8/9 kommt mit dieser Kombination nicht klar. Dort überlagert sich immerhin nichts, aber die Tabelle springt je nach Fensterbreite mal unter und mal neben das Bild. Umpositionieren der Bildeinbindungen im Quelltext hilft nichts (das hilft nur bei IE 7, der ganz andere Bugs hat). --TMg 15:22, 12. Jun. 2013 (CEST)

update: inzwischen habe ich firefox 22 und das problem bleibt bestehen. nachdem das technikteam so super das pdf-problem weiter uneten gelöst hat, könnt ihr hier was machen? viele grüße --Wetterwolke (Diskussion) 22:35, 2. Jul. 2013 (CEST)

Anpassung in der erweiterten Bearbeiten-Werkzeugleiste[Quelltext bearbeiten]

Hallo, wenn man mit der erweiterten Bearbeiten-Werkzeugleiste einen Link mit einer Zielseite wie "Schauspieler" und einem anzuzeigenden Text wie "Schauspielerin" erstellen will, dann entsteht ein Link wie dieser: [[Schauspieler|Schauspielerin]]. Ist es möglich, diesen Link gleich kürzer als [[Schauspieler]]in einzufügen, oder ist das unerwünscht? Ich hab die zugehörige MediaWiki-Seite gesucht aber nicht gefunden, bearbeiten könnte sie aber ja eh nur ein Admin.--CENNOXX 19:20, 20. Jun. 2013 (CEST)

Ich habe mal bugzilla:49940 erstellt, mache mir aber nicht allzu viel Hoffnung. --Schnark 09:11, 21. Jun. 2013 (CEST)
Falls ich die Antwort des Gerrit Notification Bot richtig verstehe, wurde das implementiert. --Leyo 18:35, 18. Jul. 2013 (CEST)
Noch nicht ganz. Es existiert eine mögliche Lösung, diese durchläuft jetzt einem Codereview unter gerrit:69896 und erst wenn dieses positiv verläuft (es merged ist), ist es auch in MediaWiki bzw. der Erweiterung offiziell enthalten. Gerrit Bot postet normalerweise dann auch noch einen 2. Update-Kommentar in den Bugreport, wenn dies der Fall ist.--se4598 / ? 22:00, 18. Jul. 2013 (CEST)
Danke für die Erklärung. --Leyo 15:18, 19. Jul. 2013 (CEST)
Zur Info: Der Patch wurde verworfen, vermutlich weil die Lösung nicht so einfach zu machen ist, vorallem wenn man die verschiedenen Linkprefixe beachten muss. Der Umherirrende 22:02, 20. Sep. 2014 (CEST)

Edit-Notice[Quelltext bearbeiten]

Eine rein technische Frage: Würde es funktionieren, eine bestimmte Edit-Notice beim Bearbeitungsversuch für alle Artikel einzublenden, die entweder

  • auf einer Liste stehen (bzw. dort verlinkt sind) oder
  • in eine bestimmte (Wartungs-)Kat eingeordnet sind

Es geht hierbei tatsächlich um Artikel, d.h. den ANR. --Mabschaaf 19:35, 15. Jul. 2013 (CEST)

Hehe. Das geht bestimmt; und wenn Du mit LUA den Artikel oder die Liste durchparst. Schreiben darf das aber jemand anders. -- RE rillke fragen? 23:21, 15. Jul. 2013 (CEST)
Wie wäre es in Wikidata eine neue Eigenschaft editnotice anzulegen und deren Inhalt per {{#property:editnotice}} in MediaWiki:Editnotice-0 abzufragen? --Fomafix (Diskussion) 16:01, 16. Jul. 2013 (CEST)
@Lua: Stimmt.
Im Prinzip ja; aber das wäre arg ressourcenfressend. Eine Lösung ginge in der Tat über Lua; das kann eine Seite mit einer Liste von Seitentiteln (+curid) auslesen und mit dem aktuellen Titel/curid vergleichen; und in Abhängigkeit davon etwas anzeigen oder nicht. Das muss aber spontan bei jedem Edit geschehen. Und das für den gesamten ANR; da musst du schon etwas sehr Wichtiges vorhaben.
Was Wikidata dort helfen soll, wüsste ich nicht; es soll ja wohl eine zentrale Wartungsseite oder Wartungskat sein, die irgendwelche Seiten (Gender?) übersichtlich aktualisierbar mit irgendeiner Warnung versieht. Das ist ja keine Eigenschaft, die weltweit irgendwelchen Lemmata zuzuordnen ist.
Der klassische Weg ginge über /Editnotice-Unterseiten, die über Vorlage den identischen Standardtext einbinden und sich darin auch zusätzlich zur Vorlageneinbindung selbst kategorisieren können – zumindest wüsste ich nicht, warum das nicht gehen sollte.
Erfrischende Nachtkühle --PerfektesChaos 00:31, 17. Jul. 2013 (CEST)
Auf en.wp gab es mal editnotice für Begriffsklärungen. Dort wurde per JavaScript der Bearbeitenlink in der Navigation manipuliert, wenn eine bestimmte Vorlage/Kategorie vorhanden war. Bedarf aber JavaScript und ich weiß nicht, ob das immer noch aktiv ist. Der Umherirrende 15:50, 19. Jul. 2013 (CEST)

class="metadata" und <ref>[Quelltext bearbeiten]

Hallo habt ihr eine Idee, warum ein class="metadata" nicht dafür sorgt, dass die mit <ref> einfügten Fußnoten nur dann sichtbar sind, wenn auch die Metadaten sichtbar sind? Z.B. Liste der denkmalgeschützten Objekte in Nikitsch #3? Sollte ein class="metadata" nicht die Anzeige des ganzen Inhalts ausschalten / resp. wieder einschalten (je nach Benutzerkonfig)? lg --Herzi Pinki (Diskussion) 17:40, 21. Nov. 2013 (CET)

Das HTML-Attribut class="metadata" in den Zellen der rechten Spalte blendet die rechte Spalte aus, aber nichts, was im erzeugten HTML außerhalb dieser Zellen steht. Die mit <ref> erzeugten Fußnoten stehen zwar im Wikitext innerhalb der Tabelle, aber nicht im erzeugten HTML (dort stehen sie im unteren Abschnitt, wo man sie auch sieht).
Als Workaround könnte man <references group="bda"/> durch <div class="metadata"><references group="bda"/></div> ersetzen. Gruß --Entlinkt (Diskussion) 18:09, 21. Nov. 2013 (CET)
danke, soweit war ich eben auch schon. Du bist zwischen meine zwei Versuche hineingestolpert, eigentlich wollte ich dafür keine neue group="bda" einführen. lg --Herzi Pinki (Diskussion) 18:18, 21. Nov. 2013 (CET)
Okay, aber die Begründung, weshalb das ohne neue Gruppe nicht funktioniert, gilt trotzdem. Dieser Anwendungsfall ist in der Cite-Erweiterung anscheinend nicht vorgesehen. --Entlinkt (Diskussion) 13:37, 24. Nov. 2013 (CET)
Hinweis auf diesen Edit, der m. E. zurückgesetzt werden sollte.
An der Sache selbst hat sich aber nichts geändert: <element class="metadata">…<element> blendet nur aus, was innerhalb des Elements steht, und dazu gehören Fußnoten nun einmal nicht. Es wird sich auch niemals etwas daran ändern, da die Fußnoten ein Feature der MediaWiki-Software sind, während class="metadata" ein lokaler CSS-Hack ist, mit dem die MediaWiki-Software nicht rechnet. Es ist technisch unmöglich, diese Konstellation durch eine Erweiterung des lokalen CSS-Hacks zu erkennen, da CSS hierfür nicht ausdrucksstark genug ist.
PS: Ich sehe die Ausbreitung von class="metadata" mittlerweile als Fehlentwicklung an, die geordnet zurückgebaut werden sollte. --Entlinkt (Diskussion) 06:51, 24. Apr. 2016 (CEST)

https auf .beta.wmflabs.org[Quelltext bearbeiten]

  • Wir haben auch zu Weihnachten kein https für beta bekommen.
  • Jetzt hat jemand die gloriose Idee, nur die enWP auszustatten: bugzilla:48501 #c75.
  • Gleiches Recht für alle: bugzilla:48501#c70.
  • Die WMF schwimmt in Millionen. Ich glaube, es hackt.
  • Ein paar nichtenglischmuttersprachliche Bugzilla-Accounts mögen senfen.

VG --PerfektesChaos 11:16, 1. Feb. 2014 (CET)

Und der Kommentar 69 in dem Bug report sagt sogar warum ("Prices offered by SSL vendors felt out of scope"). Ich glaube auch es hackt wenn man Geld fuer ueberteuerte Zertifikate aus dem Fenster wirft, ich weiss aber leider nicht was "senfen" bedeutet, um hier noch glorioser und emotionaler argumentieren zu koennen. Eigentlich glaube ich sogar dass es immer hackt! --Malyacko (Diskussion) 16:50, 3. Feb. 2014 (CET)
Es gibt doch generische Zertifikate, oder? Es gibt ja nur ein Zertifikat für *.wikipedia.org oder für de.wikipedia.org? Dann müssten die ja für jede neue Sprache ein Zertifikat kaufen, das kann ich mir nicht vorstellen. Es müsste also für *.wmflabs.org und/oder *.beta.wmflabs.org ein Zertifikat geben. Das wäre nicht so viel Aufwand, aber ich kenne mich damit nicht wirklich aus, habe das Argument der Bezahlung aber schon häufiger im Zusammenhang mit https gehört. Der Umherirrende 19:19, 3. Feb. 2014 (CET)
Dazu hat sich Krinkle in dem oben genannten Bug schon wie folgt geäußert: We'd only need beta.wmflabs.org and *.beta.wmflabs.org to be in the certificate (at e.g. DigiCert, those wildcards are $1425 for 3 years includes root and *). $1425 sind eine ziemliche Summe... - Hoo man (Diskussion) 20:04, 3. Feb. 2014 (CET)

Die WMF hat regelmäßig einen Jahresumsatz von 50 Mio. USD; und da sollen sie 500 USD/Jahr für so ein Zertifikat umbringen? 1/100.000tel? Damit erst für hohe Personalkosten und Aufwand das Beta-Cluster aufgebaut wird, und es dann nicht richtig genutzt werden kann, weil irgendwer den Finanzkollaps vor Augen hat? Oh je --PerfektesChaos 22:02, 5. Feb. 2014 (CET)

Ich denke auch, dass die Diskussion der Angestellten darüber ob das Zertifikat angeschafft wird, schon mehr gekostet hat, als das Zertifikat letztendlich kosten wird. Der Umherirrende 17:47, 6. Feb. 2014 (CET)

Mehrere Wildcards auf verschiedene Subdomains sind wohl doch zu teuer, wenigstens gibts jetzt wieder Bewegung in bugzilla:48501. Falls die in comment 77 genannten genommen werden, müsste man wenigsten nur noch für dewiki, also die Seite die man bei uns eig. gerade besuchen möchte, manuell freigeben und alles andere wie CSS und JS würde normal geladen werden und nicht wie jetzt versteckt auch abgewiesen (ohne nötige zusätzliche komplizierte Freigabe von bits, login etc.). Wäre zumindest schonmal ein großer Benutzbarkeitsfortschritt… --se4598 / ? 00:22, 22. Feb. 2014 (CET)

Eigene Diskussionsbeiträge zusammenholen[Quelltext bearbeiten]

Wie es scheint, der Beginn einer Quest: Auf Hinweis von User PerfektesChaos (schöner Name übrigens!) hierher verschoben. Sein Hinweis "auch noch nie von einem solchen Wunsch gehört" ist nicht uninteressant, weil zu allerlei Interpretationen einladend. Aber das lassen wir jetzt mal. -- NACHTRAG: Perfekt wäre ein solches Tool, wenn man nicht nur eigene, sondern die Diskussionsbeiträge eines beliebigen Users X zusammenholen könnte. Ich könnte sowas für eine angestrebte linguistische Untersuchung zu 'Diskussionsstilen' brauchen. --Delabarquera (Diskussion) 10:42, 9. Feb. 2014 (CET)


Ich bin im WP-Café hierher empfohlen worden mit meiner Frage:

"... Ich würde gerne meine Diskussionbeiträge, die im Laufe der Jahre so angefallen sind, ohne großen Zeitaufwand in eine Text- oder HTM-Datei zusammenholen. Nun denn, es gibt Programme, die ganze Websites runterladen, aber ich habe da keinen Weg gefunden, auf dem z. B. die Beiträge, die über die erweiterte WP-Suchfunktion gefunden werden, zusammengeholt werden. Hat da jemand eine Idee oder sogar eine konkrete Wegbeschreibung? ..." (Ausführlicher und mit menschlichen Relativierungen versehen hier. ;-) --Delabarquera (Diskussion) 14:56, 7. Feb. 2014 (CET)

Man hat dir vielleicht empfohlen, dich an irgendwas mit Technik zu wenden; aber ausweislich des blauen Kastens ganz oben war WP:TW gemeint.
Eine erste Antwort gibt es trotzdem vorneweg:
  • Programmierer (ich zum Beispiel) könnten sich spontan etwas schreiben, das sowas mit den Quelltexten macht.
  • Als fertiges Werkzeug hätte ich keine Idee, und auch noch nie von einem solchen Wunsch gehört.
  • Bei Benutzer:Inkowik/Tools sehe ich nichts.
Du kannst aber den Abschnitt hier löschen und nochmal unter WP:TW meine Kollegen fragen; vielleicht fällt dort jemand etwas ein.
LG --PerfektesChaos 19:09, 8. Feb. 2014 (CET)

Darstellungsfehler QS-Baustein in Mobilversion[Quelltext bearbeiten]

<übertragen von Vorlage Diskussion:QS-Chemie --Mabschaaf 13:46, 16. Mär. 2014 (CET)>

In der mobilen Version wird das Bild des Hinweises nicht richtig dargestellt.

Darstellungsfehler.png

--Impériale (Diskussion) 13:04, 16. Mär. 2014 (CET)

<Ende Übertrag>

Kann das jemand nachvollziehen und betrifft das evtl. auch andere QS-Bausteine? Könnt ihr helfen? --Mabschaaf 13:46, 16. Mär. 2014 (CET)
Hallo, ähnlich verzerrte Bilder sind mir mit dem Chrome-Browser in Denkmallisten aufgefallen. Vielleicht ist es ein allgemeineres Browser-Problem/Feature. --Wiegels „…“ 14:06, 16. Mär. 2014 (CET)

Für die CSS/Chrome-Experten: Wenn ich in den Developer Tools von Chrome, wenn man das QS-Bild auswählt, die CSS-Regel .content img { max-width: 100% !important; } (von [1]) deaktiviert, sieht es wieder ganz normal aus. Und wenn man die Fensterbreite auf weniger als ungefähr 475px verkleinert, springt das sonst verzerrt mitschrumpfende Bild aus seiner Tabellenzelle raus und wird "normal" dargestellt in der Zelle daneben. --se4598 / ? 15:13, 16. Mär. 2014 (CET)

nochmal in Bugzilla gesucht: könnte bugzilla:62460 sein. Der vorgestellte Fix (an einem leicht anderen CSS-Selektor wegen Less?) dort löst laut meinem Test gerade das auf eine spezielle Weise: Das (QS-)Bild wird nicht verzerrt. Es wird einfach nur bis nur Nichterkennbarkeit kleiner. Jemand mehr Durchblick? --se4598 / ? 15:23, 16. Mär. 2014 (CET)

Hover-Effekt bei Imagemaps[Quelltext bearbeiten]

Ist es momentan irgendwie möglich bei einer Imagemap die Bereiche hervorzuheben, wenn man mit der Maus darüber fährt. (Hover-Effekt) Das finde ich, ist nämlich ein großes Manko von vielen Imagemaps, vorallem bei Karten wie dieser. Hier ist noch ein kleines Beispiel, dass ich gefunden habe um zu verdeutlichen, was ich meine. --Stiegenaufgang (Diskussion) 12:49, 25. Apr. 2014 (CEST)

Imagemaps wurden in der ersten Linie dazu entwickelt, hinter einem Bild verlinkungen von Teilbereichen zu verschiedenen Zielen zu ermöglichen. Die Hervorhebung wie von dir gewünscht, ist auch nett, könnte Bug 19549 sein. Der Umherirrende 20:27, 12. Mai 2014 (CEST)

Bildverlinkungen in Galerien unterdrücken?[Quelltext bearbeiten]

Gibt es eine Möglichkeit, Bildverlinkungen innerhalb von Gallery-Tags komplett zu unterdrücken?

Innerhalb einer Gallery kann man auf alternative Linkziele verweisen:

<gallery>
Datei:Beispiel.JPG|verweis=Hauptseite|Bildunterschrift
</gallery>

Ein leerer Verweis, der bei Bilder-Thumbnails sonst die Klickbarkeit unterdrückt, hat in der Gallery aber keine Auswirkungen:

<gallery>
Datei:Beispiel.JPG|verweis=|Bildunterschrift
</gallery>

Gibt es technisch eine andere Möglichkeit, die Bildverlinkung innerhalb der gallery-Tags zu unterdrücken? -- · peter schmelzle · disk · art · pics · lit · @ · 18:16, 6. Mai 2014 (CEST)

Siehe auch Wikipedia:Fragen zur Wikipedia/Archiv/2014/Woche 19#Galerien ohne verlinkte Bilder und meine Antwort von dort:
Es ist richtig, das ein leeres Verweisziel bei der gallery nicht den Link unterdrückt. Ich denke mal nicht, das es Absicht war, sondern das beim einbauen (vor ca. 2 Jahren, gerrit:4609) nicht an diesen Spezielfall gedacht wurde. Bester Weg ist über Hilfe:Bugzilla (Siehe auch bugzilla:47646#c3). Der Umherirrende 19:33, 12. Mai 2014 (CEST)

Problem mit Tabelle in der mobilen Version[Quelltext bearbeiten]

Hallo zusammen, ich musste gestern feststellen, dass die Tabelle "Liste der Fährschiffe der Autofähre Konstanz–Meersburg" in der mobilen Version wenig sinnvoll ist, weil kein hozizontales Scrollen möglich ist (es wird kein Scrollbalken angezeigt). Das Gerätchen, mit dem ich das probiert hatte, ist allerdings leicht angestaubt: Ein Motorola XT720 mit Android 2.1, verwendet wurde der in Android eingebaute Browser. Frage daher: Liegts an meinem Gerät - oder kann ich als Autor an der Tabelle was verbessern? Besten Dank für einen Tip, --Karsten Meyer-Konstanz (Diskussion) 10:29, 16. Jun. 2014 (CEST)

Man könnte probieren eine feste Höhe zu setzen (wie es bei gutem Webdesign üblich ist). Ansonsten glaube ich weniger, dass man da was machen kann. User: Perhelion   10:35, 16. Jun. 2014 (CEST)
Siehe auch bugzilla:64577 - Tabellen in mobilen Ansichten sind immer noch problematisch. --AKlapper (WMF) (Diskussion) 10:45, 16. Jun. 2014 (CEST)
Stelle eben fest, dass es mit neuerer Hardware und/oder Software funktioniert. Auf einem LG Optimus 9ii (D605) mit Android 4.4.2 gibt es keine Einschränkungen, und zwar sowohl mit "Internet" als auch mit dem Chrome-Browser und bei beiden sowohl in der normalen, als auch in der mobilen Ansicht. Das einzige, was nicht geht ist, in der mobilen Ansicht das Bild so klein zu ziehen, dass die gesamte Breite der Tabelle sichtbar ist. In der Normalansicht hingegen startet sie so klein. Ist aber keine wirkliche Einschränkung. @User: Perhelion Gutes Webdesign gibt keine festen Größen vor. --Karsten Meyer-Konstanz (D) 21:08, 6. Aug. 2014 (CEST)
@Meyer-Konstanz Sagt wer? Wenn Prozente die Lösung wären gäbe es mit Sicherheit kein Begriff wie Responsive Webdesign, davon abgesehen dass fixe Größen immer schneller und problemloser aufgebaut werden, darauf bezog ich mich und darum ging es doch hier? Pauschal kann man des eh nicht sagen, vlt. früher mehr, jedoch auch heute kann man das nicht eindeutig sagen, wenn man gewissen (Profi-)Tutorials folgt, z.B.:[2][3]and there might not be a right or wrong answer. PS: Ironischer Weise haben alle (unter Vereinsmeyer) auf deiner Benutzerseite als Webdesigner verlinkten Seiten ein Layout mit einer statischen Tabelle (sogar für jede einzelne Zelle).:-P User: Perhelion06:13, 1. Sep. 2014 (CEST)

Fehler bei dem Anchorjump nach dem Bearbeiten eines Abschnittes.[Quelltext bearbeiten]

Hi,

ich war drüben[4] und habe woanders[5] zur Sicherheit nochmal nachgefragt und bin deswegen hier gelandet xD

Fehlerwichtigkeit: Keine Auswirkung auf die Stabilität von Wikipedia, Schönheitskorrektur.
Rekonstruktion:
a) Navigiere auf [6].
b) Mache dich mit dem Inhaltsverzeichnis vertraut. Es beinhaltet zweimal die gleichen Unterkategorien bei Desktop als auch bei Mobil.
c) Navigiere nach 1.3 Core i3
d) Klicke hinter dem Schriftzug "Core i3" auf [Bearbeiten]
e) Beobachte, dass in "Zusammenfassung und Quellen:" "/* Core i3*/" steht.
f) Speichere die Seite durch klick auf "Seite speichern"
g) Nachdem die Seite gespeichert wurde, wirst du auf https://de.wikipedia.org/wiki/Liste_der_Intel-Core-i-Prozessoren#Core_i3 weitergeleitet. Dein gerade bearbeiteter
Abschnitt wird also direkt annavigiert. Dies geschieht über den Anchor #Core_i3.
h) Navigiere zum Inhaltsverzeichnis.
i) Navigiere nach 2.3 Core i3
j) Klicke hinter dem Schriftzug "Core i5" auf [Bearbeiten]
k) Beobachte, dass in "Zusammenfassung und Quellen:" "/* Core i3*/ steht.
l) Speichere die Seite durch klick auf "Seite speichern"
m) Nachdem die Seite gespeichert wurde, wirst du auf https://de.wikipedia.org/wiki/Liste_der_Intel-Core-i-Prozessoren#Core_i3 weitergeleitet. Dies ist nicht der gerade von dir bearbeitete Abschnitt. Der von dir bearbeitete Abschnitt wäre https://de.wikipedia.org/wiki/Liste_der_Intel-Core-i-Prozessoren#Core_i3_2.

=> Über die Zusammenfassungszeile ist eine Unterscheidung zwischen den einzelnen Abschnitten nicht möglich, wenn diese Unterabschnitte gleich heißen.
=> Die Weiterleitung soll wohl im zweiten Fall eher auf #Core_i3_2 laufen.

-- Enomine (Diskussion) 07:42, 26. Jul. 2014 (CEST)

Dieser Fehler ist bereits seit fast 10 Jahren gemeldet: Bug 111 --Fomafix (Diskussion) 15:17, 26. Jul. 2014 (CEST)

Nicht angezeigter Bearbeitungskonflikt bei Seitenneuanlagen?[Quelltext bearbeiten]

Bei der Neuanlage einer Benutzerdiskussionsseite gab es einen Bearbeitungskonflikt zwischen mir und Benutzer:Tol'biacMG, der mir nicht angezeigt wurde. Dadurch wurde meine "Seitenneuanlage" einfach als zweite version über Tol'biacMGs Version drübergeschrieben. Ist das ein bekannter Bug? Lässt sich der Bug reproduzieren? [7] Gruß--Emergency doc (Disk) 09:41, 7. Aug. 2014 (CEST)

@Emergency doc: Hast du diese Willkommen-Meldung per normalen Bearbeitungsfenster gemacht oder ein Tool oder ein Skript verwendet, wie beispielsweise Huggle oder ähnliches? Falls Bearbeitungen nicht per normalen Bearbeitungsfenster gemacht werden, muss das jeweilige Tool oder Skript das ganze mit bedenken und ein zusätzlichen Parameter setzen. Der Umherirrende 21:48, 20. Sep. 2014 (CEST)
Hallo, ich habe keine Hilfsmittel oder Tools eingesetzt sondern nur das normale Bearbeitungsfenster benutzt. Ich weiß aber nicht, ob Benutzer:Tol'biacMG ein Skript oder Programm benutzt.--Emergency doc (Disk) 01:17, 21. Sep. 2014 (CEST)
Falls es weiterhilft - ich nutze PDDs monobook-Skripte, sonst nichts. --Tolbiac|made|gotH 12:05, 21. Sep. 2014 (CEST)
Wichtig beim Bearbeitungskonflikt ist zu wissen, wie der Zweite die Bearbeitung getätigt hat, da die erste schon abgeschlossen ist und daher egal ist wie das passiert ist. Bei 13 Sekunden Unterschied ist es aber schon komisch, das die Erkennung nicht funktioniert hat. Möglicher Unterschied wäre noch mit section=new zu normaler Seitenerstellung. Ich werde die Tage mal testen, wobei sich seit dem 7. August auch schon wieder einiges an MediaWiki geändert haben kann, aber das bekommt man noch raus um das auszuschließen. Der Umherirrende 22:01, 21. Sep. 2014 (CEST)

MediaWiki:Gadget-osm.js[Quelltext bearbeiten]

Hallo,

ich hatte vor, diesen großen Codeblock wieder in ein (standardmäßig aktiviertes, aber deaktivierbares) Gadget auszulagern. Im Beta-Wiki kann man das Ganze auf der Seite Koordinatentest testen (dort muss das Gadget aber explizit aktiviert werden).

In meinen Tests funktioniert es; es kann bloß machmal passieren, dass die beiden Gadgets „WikiMiniAtlas“ und „OpenStreetMap“ in umgekehrter Reihenfolge ausgeführt werden und deshalb die Icons verdreht sind (finde ich aber nicht schlimm).

Ist das Ganze so in Ordnung? (Ist das mw.loader.using im Gadget überflüssig? Sollte man das noch entfernen?)

Gruß --Entlinkt (Diskussion) 23:41, 29. Aug. 2014 (CEST)

Das Problem mit der zufälligen Ausführungsreihenfolge besteht auch bisher, wenn der Code in MediaWiki:Common.js ist. Nicht schön, aber ich finde das auch nicht schlimm.
Das mw.loader.using im Gadget ist überflüssig, da es bereits in MediaWiki:Gadgets-definition definiert ist.
Der ganze Code kann noch deutlich gestrafft werden. Bei Gelegenheit kann ich das mal machen.
Die Umsetzung als Gadget ist auf jeden Fall sinnvoll. --Fomafix (Diskussion) 00:30, 30. Aug. 2014 (CEST)
Ich hab es jetzt einfach mal aktiviert. Verbesserungen sind ja auch so immer noch möglich. --Entlinkt (Diskussion) 01:17, 30. Aug. 2014 (CEST)
  • Die Prüfungen mittels using() sollten drinbleiben bzw. grundsätzlich vorhanden sein.
    • Sie sind mitnichten überflüssig:
      • Nicht angemeldete Benutzer könnten ein Gadget per Greasemonkey ausführen.
        • (Hier: zwangsläufig, solange als default markiert)
      • Angemeldete Benutzer könnten das Gadget nicht per Häkchen in den Einstellungen aktivieren, sondern unter bestimmten Bedingungen per Ladeanweisung starten (Etwa: Nur im ANR; oder: nie auf Disku; nicht auf bestimmten Geräten). Dazu gehört auch die Entwicklung.
      • Irrtümlich könnte jemand die Deklaration in MediaWiki:Gadgets-definition vergessen haben; auch in einem anderen Wiki.
        • Da der Quellcode derzeit auch keinen Kommentar im Kopf enthält, würde man bei der Pflege von MediaWiki:Gadgets-definition das auch nicht sehen. So sieht man das using() und weiß Bescheid.
    • Wenn über Gadgets-definition geladen wird und deshalb schon zuvor das Verlangen befriedigt wurde, hakt das innere using() nur noch ab: „Ja, kenne ich, kann weitergehen.“ So auch Wikipedia:Technik/Skin/Gadgets #dependencies.
  • Beim Seitennamen des .js sollte OpenStreetMap identisch notiert benutzt werden wie der Bezeichner der Benutzereinstellung; das wird zur besseren Übersichtlichkeit bei allen Gadgets so gehandhabt. OpenStreetMap ist aber okay, selbsterklärend und so.
  • Das Reihenfolge-Problem ließe sich lösen, indem beide Gadgets aufeinander Rücksicht nehmen und das Geschwisterchen erkennen; in diesem Fall unmittelbar danach bzw. davor einfügen.
  • rawurlencode von wgUserLanguage sieht mir nach Nonsens aus; das kann ohne bösen Hack nur ISO639-Stil enthalten.
  • A propos Hack: Die Erkennung einer geohack-URL darf etwas spezifischer als /geohack/ ausfallen.
    • Wenn das h.split('params=')[1]; eine leere Zeichenkette oder sonst nichts liefert, sollte auch nichts mehr passieren.
  • Allgemein ist der Deklarationsstil mit spät untergemischtem var nicht (mehr) Stand der Technik.
    • Ich kann es gern auf gleichwertige JSHint-reife Syntax bringen; müsste aber jemand anders durchtesten.
    • Dann kann es auch international und kolossos als Vorbild angeboten werden.
  • Grundsätzlich begrüße ich aber die Auslagerung.

Schönes Wochenende --PerfektesChaos 09:07, 30. Aug. 2014 (CEST) +kl.erg PerfektesChaos 09:17, 30. Aug. 2014 (CEST)

Wenn man das Gadget deaktiviert (oder wenn JavaScript im Browser deaktiviert ist, insofern bestand das Problem schon immer), liefert {{Karte}} nur den nutzlosen Text "Karte" in der rechten oberen Ecke. Da sollte ein display: none; in die Vorlage und ein $( '#coordinates' ).show(); in das Gadget. --Schnark 09:12, 30. Okt. 2014 (CET)
Für das Problem mit dem nutzlosen Text „Karte“ hätte ich die folgenden 3 Edits aus dem β-dewiki anzubieten:
Sind die Fixes richtig?
  • Es müssen beide Gadgets gefixt werden, da die Logik lauten muss: „Vorlagenkonstrukt genau dann sichtbar, wenn mindestens eines der beiden Gadgets aktiviert“
  • .show() ist IMHO nicht so günstig, da es das Vorlagenkonstrukt auch in den Skins sichtbar machen würde, in denen die Oben-Rechts-Positionierung nicht implementiert ist. Deshalb .css('display', ''), womit nur die Inline-Ausblendung entfernt wird.
  • Der Hook für WMA ist wohl recht neu und wird anscheinend von sonst niemandem auf der Welt verwendet, ist die Verwendung sinnvoll?
Gruß --Entlinkt (Diskussion) 04:39, 14. Mai 2016 (CEST)
Ich habe jetzt nichts getestet, aber die Änderungen sehen gut aus, bei show vs. css hast du vollkommen recht. Der Hook scheint wirklich noch nirgendwo verwendet zu werden (auch eine Suche direkt auf en:, nl:, pt:, mw:, m: und c: für den Fall, dass Google die Seiten nur nicht indexiert hat brachte nichts), aber das sollte kein Grund sein ihn nicht zu verwenden. Krinkle weiß ja im Allgemeinen, was er tut. --Schnark 10:11, 14. Mai 2016 (CEST)
Ich habe es (ein wenig) getestet und setze es jetzt um, aber ganz ehrlich: Ich mag {{Karte}} überhaupt nicht. Diese Vorlage hatte schon in dem Moment ein Problem, in dem sie erstellt wurde, und es steht sogar explizit auf der Diskussionsseite, dass sie ein Hack ist. Mit atemberaubenden 242 Einbindungen nebenbei auch einer mit relativ wenig Bedarf.
Irgendwann einmal sollten wir es wirklich schaffen, von den Hacks wegzukommen und Probleme entweder gleich richtig oder überhaupt nicht zu lösen. Ich mache das jetzt vor allem deshalb, weil das (sowieso bereits vorhanden gewesene) Problem durch meine Auslagerung leicht verschlimmert wurde, sehe mich aber weiterhin nicht als Maintainer des/der Gadgets. --Entlinkt (Diskussion) 16:10, 14. Mai 2016 (CEST)

Leerzeilenbug[Quelltext bearbeiten]

Hallo, ich bräuchte Hilfe beim Melden eines schon länger existierenden Bugs in Bugzilla, da ich selbst dort keinen Account habe und mein technisches Englisch in der Hinsicht wohl auch nicht ausreichen dürfte.
Als aktuelles Beispiel sei folgendes benannt (in meinen letzten Beiträgen finden sich aber noch mehr Korrekturedits á la "Leerzeilenbug entfernt"). Jedesmal, wenn man Abschnitte in Artikeln bearbeitet, in denen versteckte (optionale) Abschnittsüberschriften stecken, wird unbemerkt und ungewollt automatisch eine Leerzeile zwischen optionaler und verwendeter Überschrift ergänzt. Dieser Fehler existiert wie gesagt schon länger (mindestens 2-3 Jahre) und wurde meines Wissens auch schonmal durch Raymond gemeldet, allerdings weiß ich nicht, wie man den wiederfindet und kann daher auch nicht sagen, ob der je bearbeitet bzw. geschlossen wurde.
Auch wenn es vielleicht "nur" ein eher lästiger als schädlicher Fehler ist (mal abgesehen von der unästhetisch großen Textlücke wegen der Leerzeile), wäre eine Abhilfe doch sehr wünschenswert. Kann da jemand weiterhelfen? Mit Dank im voraus und viele Grüße -- Ra'ike Disk. LKU WPMin 14:53, 31. Aug. 2014 (CEST)

Anmerkung bezüglich obigem Fehler: Bitte im ANR kein Hinterher-Korrigieren nötig machen. --Leyo 00:11, 1. Sep. 2014 (CEST)
Die Tickets die Raymond im Bugzilla aufgemacht hat gibt es hier als Liste, ich kann aber spontan kein passendes finden bei der Suche nach "line" und "head". Bugzilla-Accounts gibt's aber umsonst und diese Seite sollte erklaeren wie man dort einen Eintrag macht. :) --AKlapper (WMF) (Diskussion) 12:52, 1. Sep. 2014 (CEST)
Diese Werkstatt ist aber ausdrücklich dazu da, um den weniger technisch versierten NormalbenutzerInnen zu helfen, die keine Lust haben, sich in Produktkategorien von MW einzuarbeiten und zu lernen, wie man diese ganzen Felder ausfüllen soll, und erstmal einen gesonderten Account anlegen und eine E-Mail-Adresse preisgeben zu müssen. Im Übrigen ist auch keine Voraussetzung für die Mitarbeit an einem Wiki, Technisches Englisch zu beherrschen.
Was mediawiki.org mal bräuchte, wäre ein Wiki. Ein niedrigschwelliges Angebot, wo alle und in ihrer Muttersprache Problembeschreibungen einbringen können (so wie diese Werkstatt hier). Das dann in einen Bug-Tracker einzupflegen ist dann Sache für die 100 Hauptamtlichen.
Da du ja jetzt von dem Problem weißt und es anscheinend keinen auffindbaren Bug in dieser Angelegenheit zu geben scheint, kannst du ihn ja jetzt anlegen, und kategorisieren und einstufen.
VG --PerfektesChaos 14:45, 1. Sep. 2014 (CEST)
+1 Dem kann man nur zustimmen, ganz abgesehen davon wie umständlich das alles (momentan) ist würde ich dann gerne wissen wieviele Bugs es dann tatsächlich geben würde. (Je mehr ich selbst dahinter steige desto mehr habe ich den Eindruck die Techniker sind in einer anderen Welt um nicht zu sagen Elfenbeinturm. Aber das Thema wird ja gerade intensiv woanders behandelt.) User: Perhelion16:00, 1. Sep. 2014 (CEST)
+1 und Dank an PerfektesChaos für die gute Idee mit der zentralen Bug-Sammelseite bräuchte, wo Fehler in der Muttersprache des hilfesuchenden Benutzers beschrieben und dann von Profis weiterbearbeitet werden können. Mir ist die Sache mit Bugzilla jedenfalls ebenfalls definitiv zu kompliziert und auf Anfrage bei Wikipediakollegen nach einer hilfreichen Seite wurde ich über Hilfe:Bugzilla bzw. Wikipedia:Technik/Bugzilla hierher gelotst, wo oben im gelben Feld Hilfe bei Problemen wie von mir beschrieben versprochen wird. Gruß -- Ra'ike Disk. LKU WPMin 20:05, 1. Sep. 2014 (CEST) P.S. @Perhelion: Der Vergleich mit dem Elfenbeinturm passt übrigens gut. Ich habe jedesmal das Gefühl, ich stehe vor einem, wenn ich mir diese Bugzilla-Seiten ansehe und versuche da durchzusteigen :-/
@PerfektesChaos: Schoen dass die Werkstatt ausdruecklich dazu da ist, das begruesse ich. Ich werde aber kein Ticket in der Fehlerdatenbank zu einem Problem anlegen wenn ich das Problem nicht selbst reproduziert habe, weil der Reporter eines Fehlerberichts ggf. Nachfragen erhalten wuerde, nur um dann wild Nachfragen von A nach B herumzukopieren. Aber wie bereits beschrieben, Phabricator sollte etwas einfacher werden als Bugzilla. --AKlapper (WMF) (Diskussion) 12:14, 5. Sep. 2014 (CEST)
  • Ich habe selbst die inhaltliche Seite der Angelegenheit nicht weiter analysiert, das geschah ja im weiteren Verlauf dieses Thread.
  • Was die technisch routinierten Beteiligten in dieser Werkstatt machen (siehe auch vierten Punkt im Einleitungsabschnitt sowie vierten Punkt im gelben Kasten), ist Folgendes:
    • Kann das Problem von einem Benutzerskript, einem Gadget oder einer lokalen Eigenschaft der dewiki abhängen?
    • Lässt es sich reproduzieren?
    • Ist es vom Browser oder bestimmten Konfigurationen (Skin?) abhängig?
    • Kann die Ursache in einer extension, dem core, einem bestimmten include nebst Zeilennummern identifiziert werden?
  • Anschließend eine möglichst detaillierte Bugzilla-Meldung mit den Ermittlungsergebnissen, oder sogar gleich ein Patch.
  • Durch diese Vorfilterung werden unnötige Bugzillas vermieden.
VG --PerfektesChaos 16:01, 6. Sep. 2014 (CEST)
Es steht ja demnächst ein Wechsel von bugzilla & gerrit zu Phabricator (demo) an. Damit entfällt wenigstens dank SUL (OAUTH) die Account-Anlegerei. Ob sich das Bug-Suchen und Anlegen signifikant vereinfachen wird bezweifle ich allerdings. Bugzilla werde ich jedenfalls nicht vermissen. --sitic (Diskussion) 21:29, 1. Sep. 2014 (CEST)
Seufz, die Demo-Weibseite spricht wieder kein HTTPS worauf man zwangsumgeleitet wird. Ist leider bei einigen WMF Projekten so (anderes Beispiel). --sitic (Diskussion) 21:32, 1. Sep. 2014 (CEST)
Habe das mal geändert, wobei ich es nicht begrüße, wenn neue Projekte kein Zertifikat bekommen, müsste man eigentlich per Bugzilla (oder Fab?) beantragen. Der Umherirrende 18:50, 2. Sep. 2014 (CEST)
Das Bug-Anlegen wird sich vereinfachen, zumindest wenn es um das Formular geht (weniger Felder). Warum das "Suchen" bisher (in Bugzilla) als nicht einfach empfunden wurde kann ich nicht nachvollziehen. --AKlapper (WMF) (Diskussion) 12:50, 2. Sep. 2014 (CEST)
Ra'ike: Ich weiß, dass wir über den Bug früher geredet haben, aber ich kann mich leider an keinen Bugeintrag erinnern :-( Spannende Frage: Tritt der Bug auch mit dem VE noch auf? — Raymond Disk. 17:55, 2. Sep. 2014 (CEST)
Das von dir beschrieben Verhalten kommt daher, das beim öffnen eines Bearbeitungsfensters immer eine leere Zeile angehängt wird, wenn man jetzt ein Abschnitt bearbeitet, wo der nächste Abschnitt nicht mit einer Leerzeile abgegrenzt ist, so wird einer hinzugefügt (bei zwei Zeilen wird einer entfernt). In deinem Beispiel werden die Kommentare als Text am Ende eines Abschnitts angesehen und somit eine Leerzeile am Ende des Bearbeitungsfensters ergänzt, beim erzeugen des HTML hingegen wird der Kommentar entfernt und es bleibt ein unschöner Absatz stehen. Stellt sich die Frage, ob man die leeren Überschriften im Quelltext haben möchte oder ob man sie anders anordnet oder die Leerzeile davor entfernt oder MediaWiki gar keine Leerzeichen am Bearbeitungsfenster anfügen soll. Ich weiß allerdings nicht ob dann mehr Leute aufschreihen (über alle WMF-Wikis), das dieses Feature fehlt als jetzt aufschreien. Der Umherirrende 18:50, 2. Sep. 2014 (CEST)
@Raymond: Mal abgesehen davon, dass der VisualEditor das grauseligste Bearbeitungstool ist, dass ich je gesehen habe, scheint zumindest der Leerzeilenbug dort nicht aufzutreten [8]. Allerdings kriegt man beim VE auskommentierte (optionale) Texte/Überschriften auch gar nicht erst zu sehen, d.h. man könnte sie im Bedarfsfall auch nicht aktivieren. Nebenbei kann man übrigens mit dem VE eingefügte Links wie z.B. den nach Santa Fe (Oruro) nicht hinter einem Alternativtext (ohne Klammerzusatz) verstecken (oder ich hab's nicht gefunden), verlinkte Teile in Einzelnachweisen (z.B. zur Überprüfung o. Ergänzung von Daten/Fakten) nicht aufrufen und vor allem Tabellen nach wie vor nicht bearbeiten, weshalb der VE für mich bisher auch völlig unbrauchbar ist und ich den nach dem Test auch schnell wieder abgeschaltet habe.
@Umherirrender: So wie Du das Problem beschreibst, erscheint die Funktion mit der Leerzeile (fehlende Abschnitts-Leerzeile wird automatisch ergänzt, überflüssige entfernt) sogar durchaus sinnvoll. Das einzige, was man dem Programm halt noch klar machen müsste ist, dass auskommentierter Text nicht als normaler Text betrachtet werden darf. Zur Not könnte man die optionalen Überschriften wohl auch noch in dieser Form verstecken, aber bequemer wäre es natürlich, wenn sie wie beschrieben nicht als normaler Text erkannt würden und entsprechend automatisch auch keine Leerzeile angehängt würde.
Falls sich jemand fragen sollte, wieso man unbedingt optionale Überschriften in den Artikel einbauen möchte: Sie dienen einerseits als Hilfestellung für ergänzungswillige Benutzer und andererseits der Wahrung einer gewissen Einheitlichkeit der Artikel in diesem Themenbereich. Den meisten Benutzern dürfte nämlich die entsprechende Formatvorlage nicht bekannt sein und außerdem hängt an vier der wichtigsten Überschriften ein Bot, der das Vorhandensein selbiger überprüft und fehlende meldet. Gruß -- Ra'ike Disk. LKU WPMin 19:37, 3. Sep. 2014 (CEST)

Alt-Texte im Screenreader[Quelltext bearbeiten]

Ich habe vor einiger Zeit begonnen, Bilder in Artikeln mit Alt-Texten auszustatten; diese werden von Screenreadern vorgelesen bzw. auf der Braillezeile angezeigt und erhöhen somit die Zugänglichkeit der Seite für blinde Benutzer. Mit Benutzer:Wikinger08 steht mir ein Benutzer mit Screenreader-Erfahrung zur Seite und reviewed meine Texte. Für meine eigene Kontrolle habe ich mir ein dieses Fireox-Plugin installiert, das die Alt-Texte beim Mouseover als Tooltip anzeigt. Nun ist Folgendes aufgefallen:

Ich finde im generierten HTML-Code jeweils das Alt-Attribut in gültiger Syntax ohne irgendwelche auffälligen Unterschiede. Wikinger08 weist darauf hin, dass bei den beiden nicht funktionierenden Beispielen die Bilder nicht von Commons, sondern aus der deutschen Wikipedia eingebunden werden.

Erbitte Hilfe! --Mosmas (Diskussion) 15:59, 2. Okt. 2014 (CEST)


Der HTML-Code der <img> sieht sauber aus und ist in allen drei Fällen strukturell identisch. Wird auch von derselben Software generiert.
  • Die Textlänge bei Elsa ist mit 338 Zeichen sogar länger als bei Thomas und erst recht bei Aral. An irgendeinem Limit von 255 oder 1024 Zeichen kann es nicht liegen.
  • Ich sehe auch keine ausgeflippten Bytes oder exotische Zeichenkodierungen. Gerade Aral ist sehr übersichtlich.
Der geäußerte Verdacht, Commons ./. deWP als eigentlicher Lagerort hätte etwas damit zu tun, käme mir sehr spanisch vor.
  • Die HTML-Seite weiß nichts davon, und die URL unterscheidet sich irgendwo im Pfad des Bildes. Die Domain upload.wikimedia.org ist identisch.
  • Es ist aber nicht auszuschließen, dass irgendwer oder was damit interagiert; ggf. weitere Software hinterher draufpatscht.
Rückfragen:
  • Was macht denn der MediaViewer so bei dieser Geschichte?
  • Unter Spezial:Einstellungen #mw-prefsection-gadgets gibt es etwas: „Überspringen der lokalen Dateibeschreibungsseite, um sofort nach Commons zu kommen“ – ist das aktiv und funkt womöglich dazwischen? MediaWiki:Gadget-Direct-link-to-Commons.js verändert an allen Commons-Bildern nachträglich die Umgebung des <img>-Elements, lässt aber die lokalen in Ruhe. Aber die lokalen beiden würden nicht funktionieren, sondern gerade die auf Commons?
  • Gibt es Sicherheitssoftware, die Manipulationen an HTML-Seiten beanstandet?
  • Passiert das Gleiche als angemeldeter und nicht angemeldeter Benutzer?
  • Es wäre sonst notwendig, etwas mehr über die Screenreader zu erfahren:
    • Wie lesen sie die Seite aus; in welcher Architektur sind sie gebaut? Ein eigenständiger Browser, oder ein Plugin in einem normalen Browser, das dann die abgerufenen HTML-Seiten interpretiert?
    • Könnte JavaScript im Spiel sein? Wird JavaScript vom Screenreader genutzt, ist es beim Browsen aktiviert?
Ansonsten:
  • Unbesorgt weitermachen; weitere Beispiele sammeln.
  • Die momentanen drei Bilder helfen noch nicht zur Identifikation eines Musters; fünf Ausfälle und zehn funktionierende sollten es schon sein.
Wird schon hinzubekommen sein --PerfektesChaos 17:25, 2. Okt. 2014 (CEST)
Antwort vom Firefox-Plugin-User (der jeden Alt-Text beim Mousover korrekt angezeigt bekommt):
  • Das Überspringen ist bei mir aktiv, keine Sicherheitssoftware, Verhalten an-/abgemeldet identisch (ok).
Bei Wikinger08 gibt's offenbar ein je nach Screenreader (JAWS bad, NVDA good) unterschiedliches Verhalten.
--Mosmas (Diskussion) 19:13, 2. Okt. 2014 (CEST)
  • Naja, dass du das lesen kannst, ahnte ich schon; es ginge um die Konstellation bei Wikinger08.
  • JAWS schreibt: „Works with Microsoft Office, Internet Explorer, Firefox, and much more“ – das bedeutet, es läuft ein üblicher Browser und dieses JAWS ist dort obendrauf gesetzt. Damit kann es schon mal zu Kollisionen mit irgendwas kommen, und dessen Programmausführung bricht ab.
  • Unsere HTML-Seite ist grundsätzlich in Ordnung; umso mehr, wenn der andere Screenreader es packt.
  • Vielleicht haben bestimmte unserer Seiten eine Eigenschaft, die JAWS an der Interpretation hindert; vielleicht muss man nicht zu eng auf das Bild gucken, sondern weiter drumrum in der Seitenstruktur.
    • Mit den bekannten drei Links ist da aber wenig zu sehen; zumal Thomas so übersichtlich ist, dass da eigentlich keine Extravaganzen auftreten.
  • Machen wir mal weiter, wenn mehr Informationen vorliegen --PerfektesChaos 20:03, 2. Okt. 2014 (CEST)
Hallo PerfektesChaos,
wenn ich mich abmelde, dann bekomme ich den Alternativtext bei Thomas vorgelesen und angezeigt; beim Aral-Logo hingegen wird er ignoriert. Ich habe wegen des Teilerfolgs mal alle Einstellungen auf Standard zurückgesetzt, doch da fehlen die Alt-Texte der o. g. Dateien wieder. Ob Commons oder dewiki, scheint doch keine Rolle zu spielen, denn im Artikel Weibernetz funktioniert die Interpretation des Alt-Textes.
Einstweilen vielen Dank fürs Überprüfen! --Wikinger08 (Diskussion) 10:10, 3. Okt. 2014 (CEST)
  • „wenn ich mich abmelde, dann bekomme ich den Alternativtext bei Thomas vorgelesen und angezeigt“ – das klingt sehr danach, als ob irgendeins unserer zahlreichen JavaScript-Einheiten mit JAWS kollidiert wäre. Das wäre etwas, was im angemeldeten Zustand aktiv und abgemeldet nicht aktiv oder anders justiert ist.
  • Mir fiel inzwischen noch MediaWiki:Gadget-Screenreader-Optimierung-TOC.js auf.
    • Der Code ist syntaktisch etwas veraltet. Warum TOC (Inhaltsverzeichnis) im Namen steht, ist nicht so recht ersichtlich – es beschäftigt sich mit allem Möglichen. Elsa und Weibernetz haben ein Inhaltsverzeichnis; Thomas standardmäßig nicht; auf Diskussionsseiten (→Aral) wirkt das Dingens nicht, sondern ausschließlich beim Angucken von Artikeln im ANR.
    • Der Diskussionsseite und den eingestreuten Kommentarzeilen kann ich in etwa entnehmen, was das Teil machen soll.
    • Es wäre zurzeit Kandidat Nummer 1 dafür, irgendetwas durcheinanderzubringen.
    • Das Dings orientiert sich an HTML-Seiten, wie wir sie 2007 produziert hatten. Zwar sehe ich keine Riesenauffälligkeiten, aber da könnte sich im Detail etwas geändert haben.
LG --PerfektesChaos 14:03, 3. Okt. 2014 (CEST)
Das Helferlein „Screenreader-Optimierung“ habe ich gar nicht aktiviert, weil ich keinerlei Vorteile erkennen kann. Es hat bei mir auch keine Auswirkung darauf, ob der Alt-Text funktioniert.
Ich mache jetzt erst mal eine Wikipause und melde mich hier zurück, wenn ich weitere Beispiele für nicht funktionierende Alt-Texte zusammengestellt habe. --Wikinger08 (Diskussion) 17:54, 4. Okt. 2014 (CEST)

BTW, kann man nach Bildern mit Alt-Text suchen? --Mosmas (Diskussion) 21:15, 5. Okt. 2014 (CEST)

Im Prinzip ja, macht aber keinen Spaß. Zumal du nicht nur Kurztexte wie „Logo“ lesen willst, sondern gezielt welche suchst, bei denen der Text 100 Zeichen und mehr hat; und da bekommt man derzeit nur selten eine Antwort. Man könnte aber den einige Wochen alten Dump durchsuchen lassen. LG --PerfektesChaos 22:39, 5. Okt. 2014 (CEST)
Wenn man nicht mit regulären Ausdrücken nach längeren Alt-Texten eingrenzen kann, würde ich eben selbst die längeren durch Sichtung herausfinden müssen. Wie würde man denn suchen? Viele Grüße --Mosmas (Diskussion) 09:20, 6. Okt. 2014 (CEST)
  • Das Problem ist ein anderes: Mit der neuen Cirrus-Suche, die du vorab über die Beta-Features aktivieren könntest, kannst du zwar einen Suchausdruck eingeben.
  • Es würde auch einen regulären Ausdruck geben, mit dem du Texte einer Mindestlänge von 77 Zeichen auffinden kannst:
    /\|\s*alt=[^]|]{77,}/
  • Nur musst du dir den Spezialserver für reguläre Ausdrücke offenbar mit allen Zeitzonen der Welt teilen, in denen Englisch gesprochen wird. Heißt: Die Abfrage ist sehr komplex, braucht sehr lange, und du kommst in der Warteschlange nie zum Zug, und falls doch, bricht der Server wegen Überschreitung des Zeitlimits ab. Vergiss es.
  • Wenn es unbedingt sein muss, wende dich besser an WP:B/A; den obigen RegExp kannst du mitbringen, da freuen die sich.
LG --PerfektesChaos 10:22, 6. Okt. 2014 (CEST)
vor regulären Ausdrücken habe ich keine Angst :) Danke, werde ich so machen! Liebe Grüße, --Mosmas (Diskussion) 17:47, 6. Okt. 2014 (CEST)

WP:QS nicht vorhanden und doch angezeigt[Quelltext bearbeiten]

Bei der Bearbeitung von BMW 500 Kompressor taucht unten die Zeile: Wikipedia:Qualitätssicherung Auto und Motorrad/falsche Bauart Motorrad auf, die es nicht gibt. Frage wurde im Portal [9] gestellt, doch braucht es dafür eines Kundigen um den Fehler zu beheben, ich kann nur tippen ;-) -- Beademung (Diskussion) 16:39, 21. Okt. 2014 (CEST)

Benutzerbeiträge[Quelltext bearbeiten]

Derzeit werden standardmäßig die letzten 50 Beiträge angezeigt, wenn man sich die Beitragsliste eines Benutzers anzeigen lassen will. Man kann dann wählen zwischen (20 | 50 | 100 | 250 | 500). Ich hätte gerne standardmäßig 250 Beiträge rückwärts angezeigt. Kann man das in erweitern? In den Helferlein? Am besten auch gleich auf 1000, also:

(neueste | älteste) Zeige (nächste 50 | vorherige 50) (20 | 50 | 100 | 250 | 500 | 1000)

MfG --Informationswiedergutmachung (Diskussion) 17:10, 26. Jan. 2015 (CET)

Spezial:Einstellungen#mw-prefsection-rc ist nicht das Gesuchte? --Leyo 17:25, 26. Jan. 2015 (CET)
Sieht so aus, danke. --Informationswiedergutmachung (Diskussion) 17:32, 26. Jan. 2015 (CET)
Erledigt-Vermerk nochmal raus: eigentlich wollte ich ja nur meine letzten 1000 Beiträge einsehen können. Mit der Änderung bekomme ich jetzt aber auf Spezial:Letzte_Änderungen bzw. Spezial:Neue_Seiten ebenfalls die letzten tausend Seiten. Mich stört es nicht weiter, wollte aber darauf aufmerksam machen, dass sich die Änderung auf alle Spezialseiten bezieht. Aus meiner Sicht: überlastet das nicht die Server? Ist das so gewollt? --Informationswiedergutmachung (Diskussion) 21:17, 26. Jan. 2015 (CET)
Bei mir steht drunter wofür das Limit genutzt wird: "Dies umfasst die Liste der letzten Änderungen, die Versionsgeschichte und die Logbücher.". Fehlt nur ein Hinweis auf die Benutzerbeiträge wo es anscheind auch funktioniert. Der Umherirrende 16:38, 29. Jan. 2015 (CET)

Dann müsste wohl MediaWiki:Prefs-help-recentchangescount angepasst werden, entweder lokal oder global. --Leyo 12:39, 28. Jan. 2016 (CET)

@Umherirrender, Informationswiedergutmachung: Was davon ist zu bevorzugen, auch in Anbetracht des Aufwands? --Leyo 02:07, 21. Feb. 2016 (CET)

Überschriftensimulationen an Typografie-Update anpassen[Quelltext bearbeiten]

Hallo, kann jemand bitte die Überschriftensimulationen ({{Überschriftensimulation 1}}, {{Überschriftensimulation 2}}, …) an die aktuell standardmäßige Formatierung der Überschriften anpassen? Das wurde nach dem Typography refresh anscheinend nicht gemacht.--CENNOXX 20:23, 26. Jan. 2015 (CET)

  • Das geht deshalb nicht trivial, weil Skin-abhängig.
  • Es müsste global von der jeweiligen Skin der Stil der Klasse zugewiesen werden, und dann diese dem H1 – dann könnten wir auch in dieser Vorlage davon Gebrauch machen.
    • Das wurde auch bereits irgendwo hier im Projekt diskutiert.
    • Vielleicht gibt es schon eine Phab-T.
  • Bislang war das Erscheinungsbild immer ähnlich gewesen; jetzt weicht Vector ab.
  • Eigentlich sieht es aber auch nicht schlecht aus, wo es eingesetzt wird.
  • Wir könnten mit schwer verhältnismäßigem Aufwand für sämtliche Seiten lokal ein workaraund definieren.
VG --PerfektesChaos 21:16, 26. Jan. 2015 (CET)

Datumsanzeige[Quelltext bearbeiten]

Hallo, wie kann man folgende Datumsanzeige von 'letzter Donnerstag im kommenden Monat' auf 'ersten Mittwoch im kommenden Monat' umbiegen?

Nächster Termin: Donnerstag, 29. September 2016

Vielen Dank im Voraus, Grüße --Ghilt (Diskussion) 20:48, 29. Jan. 2015 (CET)

Achje.
   Nächster Termin: Mittwoch, 5. Oktober 2016
Viel Erfolg, und das erste Jahr hindurch etwas kritisch beäugen. --PerfektesChaos 22:00, 29. Jan. 2015 (CET)
Ein herzliches Dankeschön! Grüße, --Ghilt (Diskussion) 22:19, 29. Jan. 2015 (CET)
@Ghilt: Zu früh gefreut: An den ersten drei Tagen des Februar wird das aber schon auf den März verweisen.
  • Richtung Wochenende gibt es Abhilfe, ich habe ja noch 49 Stunden.
  • Es soll sich so verhalten, dass es am Mittwoch selbst noch auf heute verweist und erst danach umspringt, richtig?
Bis dann --PerfektesChaos 22:46, 29. Jan. 2015 (CET)
Ja, genau, Grüße, --Ghilt (Diskussion) 22:52, 29. Jan. 2015 (CET)
Falls der 7. September 2016 noch nicht vorbei ist, so ist es dieser, ansonsten ist es 5. Oktober 2016. --Schnark 09:27, 30. Jan. 2015 (CET)
Das heißt, falls ich mich nicht verrechnet habe, ist das gesuchte Datum 5. Oktober 2016. Natürlich geht das vermutlich irgendwie auch schöner, aber PHP hat nun mal bereits die notwendige Logik für die Wochentage eingebaut, dann kann man sie auch nutzen, das erleichtert auch die Umstellung auf andere Wochentage. --Schnark 09:33, 30. Jan. 2015 (CET)
Auch Dir ein herzliches Dankeschön! Es wurde bereits umgesetzt. Grüße, --Ghilt (Diskussion) 09:49, 30. Jan. 2015 (CET)
@Schnark: Ah, danke; bei #ifexpr war ich gestern Abend auch schon gewesen, aber zu müde für eine zuverlässige Programmierung.
In PHP stecke ich nur oberflächlich, nicht in diesen Abgründen; hatte mich nur an unsere H:VP gehalten. Selbstverständlich ist first wednesday die sinnvollere Lösung als die bisher verwendeten Eigenbaukonstruktionen.
Dein Ausdruck scheint bei erstem Nachvollziehen richtig zu sein. Eleganter wird es auch kaum gehen.
LG --PerfektesChaos 10:07, 30. Jan. 2015 (CET)

Hallo Ihr, ich bin megaschwer beeindruckt, von der schnellen Erzeugung einer verständlichen (und funktionierenden!) Lösung! Ich finde sie enorm nützlich und werde sie sicher weiter empfehlen! Vielen Dank! blumen  -- FCT Berlin?! • 11:07, 30. Jan. 2015 (CET)

Nachdem ich nochmal darüber nachgedacht habe: Das schlägt fehl, wenn der Monatserste ein Mittwoch ist: 6. April 2016. Wenn man das first weglässt (das ich nur von einem vorherigen Versuch drin hatte), müsste es gehen: 5. Oktober 2016 --Schnark 11:50, 30. Jan. 2015 (CET)
Könntest du dann bitte auf H:VP dokumentieren, was genau wann first und präsumtiv last ist und wann genau der Fall friday eintritt? LG --PerfektesChaos 12:12, 30. Jan. 2015 (CET)
Die Dokumentation verlinkt doch das GNU tar Manual, wo man http://www.gnu.org/software/tar/manual/html_node/Day-of-week-items.html#SEC126 etc. findet (ansonsten hätte ich das ja auch nicht geschafft). Willst du wirklich, dass all dieses obskure Zeug von dort kopiert wird? --Schnark 12:31, 30. Jan. 2015 (CET)
Kopiert nicht, aber mindestens Hinweise darauf, dass es zu diesem, jenem und solchem Spezialfall weitere Möglichkeiten gäbe; Syntax und nähere Einzelheiten siehe GNU.
Wenn ich das Link anklicke, dann komme ich wieder bei Adam und Eva an, und hätte auch keine Veranlassung dazu, weil ich nicht ahne, dass es für mein aktuelles Problem etwas Neues gäbe.
LG --PerfektesChaos 13:01, 30. Jan. 2015 (CET)

Misch-Namensraum Behelfs-Kategorie erstellen?[Quelltext bearbeiten]

Mir ist die Idee gekommen eine Kategorie für einen speziellen Grund und für einen speziellen Namensraum zu schaffen (konkret in dem Bereich habe ich das noch nicht getan). Daher vorab hier die Frage, uzw. geht es um Wikipedia: und Seiten die eigentlich Diskussionsseiten sind (wie diese hier). Ich vermute davon könnten einige Scripte (oder Bots) profitieren (bestimmte Bedingungen nur dort, momentan löse ich das mit einer statischen Textliste direkt im Script, aber ich hatte auch schon mittels API nach divers Templates (AddNewSection oder __NEWSECTIONLINK__) oder Autoarchiv gescannt). Es sei denn es gibt schon eine bessere Lösung? Ich weiß nur dass PerfektesChaos hier auch irgendwie eine Prüfung mit seinem Script macht/braucht. Kann man das so in Angriff nehmen? :-) User: Perhelion 11:31, 6. Feb. 2015 (CET)

Also du meinst etwas wie Forumsseite, die es ja auch in einem Portal geben könnte.
Screengrabbing auf Desktop ist einfach: if( $("#ca-addsection").length ) {
Wenn das nur Skripte und Bots benötigen, sollte das nicht mit einer Kat geschehen, die auch irgendwer pflegen muss, sondern sie sollten sich das Zeugs on-the-fly aus der aktuellen Seite grabbeln.
Seiteneigenschaften__NEUER_ABSCHNITTSLINK__
  • pagepropstypeof .pageprops.newsectionlink !== "undefined"
LG --PerfektesChaos 11:54, 6. Feb. 2015 (CET)
Ähm* ja, da hätte ich tatsächlich auch alleine drauf kommen können. Das mit der API hatte ich schon mal etwas ähnlich (jedoch wesentlich umständlicher) TMg meinte aber das wäre zuviel des Guten… für so ein Script das im Dauer-/Massenbetrieb sein könnte. Vielen Dank, ich werde dies auch gleich einbauen. User: Perhelion 14:05, 6. Feb. 2015 (CET)
Jetzt gibt es doch noch einen entscheidenden Haken den ich tatsächlich vergessen hatte (und der Grund ist warum ich das bis jetzt noch nicht so gemacht habe). Im Editiermodus gibt es leider diese schöne Schaltfläche nicht mehr. :-/ Dann bleibt tatsächlich nur noch die API? Oder ich würde auch mit Cookies hantieren, allerdings müsste man dafür wohl alle Bearbeiten-Knöpfe überwachen um dann diese gesuchten Seiten vorher einzufangen (da die Seite wohl leider neu geladen wird)⁉ User: Perhelion 22:27, 7. Feb. 2015 (CET)
API ist sicher, funktioniert in allen Skins, mobil, und sonstwie.
Du müsstest ansonsten bei jeglicher normalen Seitenansicht in die sessionStorage vorsorglich reinschreiben, dass dies eine Forumsseite wäre. Cookie ist ganz schlecht, weil die den Traffic erhöhen und bei jeglicher Anfrage nach einem Bildchen usw. zum Server geschickt werden.
LG --PerfektesChaos 01:10, 8. Feb. 2015 (CET)
Dürfte phab:T22177 sein. Der Umherirrende 20:08, 8. Feb. 2015 (CET)
Oh tatsächlich, danke auch für die Task-Info (werde dort mal kommentieren).
@Cookie: Ok, danke auch für diese ernüchternde Einschätzung, dann mal ran an die API!
User: Perhelion 10:22, 9. Feb. 2015 (CET)
Ich habe den Code erfolgreich umgesetzt (wie gesagt hatte ich ihn sogar schon mal). Da nun, wie ich sehe diese Function auch von anderen Scripten (s. z.B. hier #Position des Signatur-Buttons verändern) verwendet werden kann (und auch bei meinem Smilie-Script evtl. Missbrauch vorgebeugt werden könnte), würde ich diese als Modul hier ablegen meta:User:Perhelion/forumPage.js, allerdings ist/wird die Abfrage dann etwas komplizierter, da auf die API-Antwort wohl gewartet werden muss. (PS: beim Suchen von Seiten habe ich gleich mal die nicht unbekannten Wikidata-Einträge für Forum und Hilfe:Tags in die richtige Richtung geschoben. :-P) User: Perhelion 22:11, 11. Feb. 2015 (CET)
@Perhelion:
  • Du sollst meine Verlinkungen nicht entstellen.
  • Du sollst WSTM nicht auf Forumsseiten einsetzen; dafür ist das nicht gedacht.
  • Du kannst dir auf Phab ja wünschen, dass du ein JS-Array aller props gleich mit der Seite mitgeliefert haben möchtest; so wie WP:JS/V#wgRestrictionMove oder zumindest in der Vorschau wgCategories. Dann sind sie sofort da; auch die normalen Tokens bekommt man heutzutage ohne erneuten API-Abruf.
LG --PerfektesChaos 00:38, 12. Feb. 2015 (CET)
Oh* sorry, ich war wieder gedanklich woanders (man verbringt einfach zuviel Zeit hier und man wird nicht jünger), werd ich mir hinter die Löffel schreiben.●°.°● Danke auch für den Hinweis (ich habe mir mal erlaubt auch deinen letzten Link zu fixen, nach ein klein wenig Suche⁉). Ja, das mit wgCategories wäre auch nicht schlecht. Dann werde ich mal dem Pfad deine Rates folgen (und meiner Wege gehen). :) User: Perhelion 12:12, 12. Feb. 2015 (CET)

Commons.js und Gadgets in den beiden sorbischen Wikipedien[Quelltext bearbeiten]

Kopiert aus MediaWiki Diskussion:Common.js --Tlustulimu (Diskussion) 17:30, 16. Feb. 2015 (CET)

Hallo. Vor einigen Tagen ist mir aufgefallen, daß bei mir, wenn ich mich in den sorbischen Wikpedien anmelde, einige Gadgets nicht laufen. In der Konsole vom Firefox erscheinen Meldungen, die mit folgenden Texten anfangen:

  • "Exception thrown by ext.gadget.Direct-link-to-Commons"
  • "Exception thrown by ext.echo.base"

Hinter beiden Meldungen erscheint denn jeweils noch ""TypeError: mw.config.get(...) is null" TypeError: mw.config.get(...) is null" mit einem gänzlich unübersichtlichen Link. Seltsam ist, daß manchmal sogar noch 2 weitere ähnliche Meldungen auftauchen. Das Problem liegt nicht am Browser, denn bei anderen Browsern laufen die problematischen Gadgets auch nicht. Welcher Code in hsb:MediaWiki:Common.js bzw. dsb:MediaWiki:Common.js muß vollständig ersetzt werden und wie? Ich habe mir schon hiesige Hilfsseiten dazu angesehen, verstehe aber nur Bahnhof. :-( Oder haben die Browser wegen der vielen Skripte schlicht ein Timingproblem?

Ich bin dort zurzeit der einige Admin, dem das Problem aufgefallen ist. Wahrscheinlich nutzen die anderen keine Gadgets oder nur solche, die laufen. Ist es möglich, daß irgendwelche Skripte "mw.config" ruinieren, sodaß sich nichts davon mehr auslesen läßt?

Unangemeldet funktioniert die Einklappfunktion bei den Vorlagen hsb:Předłoha:Infokašćik/LocMap wjacekróć beim Beispiel "Dwě mapje" und den folgenden sowie dsb:Pśedłoga:Infokašćik/LocMap wěcej raz beim Beispiel "Dwě kórśe" und danach problemlos. Aber angemeldet geht es in keinem Browser. Die zugehörige Funktion in Common.js heißt dort "GeoBox_Init". In der obersorbischen Wikipedia hatte ich diese Funktion gestern oder vorgestern nach der französischen Wikipedia aktualisiert. Es läuft nur unangemeldet. Warum?

Gestern hatte ich mal provisorisch meine vector.js geleert. Gebracht hat das aber gar nichts. Also muß der Fehler in Common.js oder einzelnen Gadgets liegen. Ich weiß ja, daß in Common.js dort alter Kram steht, weiß aber leider nicht, wie der aktualisiert werden muß. :-( --Tlustulimu (Diskussion) 10:10, 16. Feb. 2015 (CET)

Ich hatte gerade mal probiert, wie das Wiki reagiert, wenn ich alle Gadgets ausschalte und sie nacheinander wieder aktiviere. Bei hsb:MediaWiki:Gadget-HotCats.js traten die Fehler wieder auf. Aber ich habe das Gadget inzwischen nach der Version der Esperantowikipedia aktualisiert. Jetzt scheinen die Fehler verschwunden zu sein. :-)
Also muß ich wohl nur noch Common.js nach und nach ausmisten. Oder? Wenn ja, wie mache ich das am besten? --Tlustulimu (Diskussion) 11:11, 16. Feb. 2015 (CET)
  1. Ich würde empfehlen, diesen Abschnitt hier rückstandsfrei auszuschneiden und in Wikipedia:Technik/Werkstatt zu kopieren.
  2. Danach wäre es ratsam, sich Wikipedia:Technik/Skin/JS/Obsolet danebenzulegen und Stück für Stück abzuarbeiten. Das schließt vermeidbare Ursachen aus und hält auch die Fehlerkonsole übersichtlich.
  3. Danach mal vorsichtig in die WP:JS #Fehlermeldungen linsen.
  4. Was dann immer noch nicht mag, in der WP:TWS melden.
LG --PerfektesChaos 11:35, 16. Feb. 2015 (CET)

Hallo, PerfektesChaos. Ich habe es denn mal umkopiert. --Tlustulimu (Diskussion) 17:30, 16. Feb. 2015 (CET)

Merkwürdiges Verhalten beim Artikel Arbeitszeit[Quelltext bearbeiten]

Am 4.3. um 16:16 hat eine IP besagten Artikel bearbeitet, den ich als Sichter drei Minuten später revertiert hatte. Soweit ist noch alles in Ordnung. Aber am 5.3. um 10:23 wurde ein Fehler behoben, den ich nicht verursacht habe. In der Beschreibung wurde fälschlicherweise gesagt, dass meine Änderung rückgängig gemacht wurde. Dabei wurde ich noch über die Benachrichtigung informiert. Wieso hat der entsprechende Automatismus zugeschlagen? -- Raubsaurier (Diskussion) 21:02, 7. Mär. 2015 (CET)

Rückgängigmachen kann man nicht nur die letzte Bearbeitung, auch ältere, sofern sie nicht schon durch neuere Bearbeitungen verändert wurden. Diese Änderung vom 7. Februar ist von dir, und sie wurde am 5. März rückgängig gemacht. Gruß --Schniggendiller Diskussion 21:09, 7. Mär. 2015 (CET)
Wenn ich da mal weiter fragen darf: Wenn man eine länger zurückliegende Bearbeitung rückgängig macht, dann wird also nicht alles, was zwischen diesem Zeitpunkt und heute liegt, auch aufgehoben? Gilt das dann für einen Abschnitt oder wie darf man sich das vorstellen? --Karsten Meyer-Konstanz (D) 21:44, 7. Mär. 2015 (CET)
Sofern der betroffene Abschnitt nicht weiter bearbeitet wurde, schafft die Software das. Andernfalls bekommt man eine Meldung Die Änderung konnte nicht rückgängig gemacht werden, da der betroffene Abschnitt zwischenzeitlich verändert wurde. (Beispiel)
Ich vermute die Nachricht zum Zurücksetzen kommt von der URL (&undoafter=138629126&undo=138640011), nicht davon was genau man auf die Seite schreibt. --mfb (Diskussion) 21:47, 7. Mär. 2015 (CET)
Richtig. Echo nutzt die Versionskennung aus undo/undoafter zur Ermittlung des Benutzers. Die eigentliche Änderung ist auch in der Zusammenfassung erwähnt, nur nicht verlinkt, daher kommt man da nicht direkt drauf. Der Umherirrende 22:16, 7. Mär. 2015 (CET)
Ich danke euch. Bleibt die Frage, WIE man a) eine zurückliegend Änderung und b) alle zurückliegenden ab einem bestimmten Zeitpunkt revertiert. --Karsten Meyer-Konstanz (D) 23:00, 7. Mär. 2015 (CET)
Das Problem an a) habe ich jetzt nicht verstanden; aber b) geht so: In der Versionsgeschichte oder bei einer Diffpage auf die gewünschte Basisversion gehen, diese bearbeiten und ggf. nichts weiter machen außer speichern. LG --PerfektesChaos 23:05, 7. Mär. 2015 (CET)
Die Antwort auf a) dürfte sein: In der Versionsgeschichte oder auf einer Diff-Seite in den Stammdaten auf "rückgängig". --nenntmichruhigip (Diskussion) 23:25, 7. Mär. 2015 (CET)
Stimmt, danke euch beiden. Klar - in der Versionsgeschichte gibt es ja bei jeder einzelnen Änderung die Möglichkeit dazu. Und deine Lösung, PerfektesChaos, ist natürlich auch logisch - nur dass es nicht ersichtlich ist - außer, man schreibt's halt selbst in den Kommentar. --Karsten Meyer-Konstanz (D) 23:53, 7. Mär. 2015 (CET)

mw-disambig – Hintergrundfarbe für BKL/BKS[Quelltext bearbeiten]

Hallo zusammen, ich habe eben die Einstellung .mw-disambig gefunden und in meine globale CSS-Datei eingebunden, weil ich das standardmäßige Rot zu penetrant finde. Lade ich eine Seite mit einem BKL-Link, dann erscheint der Link während des Ladens in der von mir eingestellten Farbe, wenn die Seite jedoch fertig geladen ist, ändert sich die Hintergrundfarbe wieder auf den Standardwert. Was mache ich falsch? Viele Grüße – Filterkaffee (Diskussion) 13:41, 9. Apr. 2015 (CEST)

Eine kurze Erklärung möchte ich dann aber doch noch einfügen. Ich hatte den entsprechenden Quellcode in meine CSS-Datei kopiert, danach trat das Problem aber weiterhin auf. Die Lösung ist, die BKL-markierung nicht über Fliegelflagel zu aktivieren, sondern über die Einstellungen. Die Fliegelflagel-Erweiterung liest die CSS Datei nicht, deswegen konnte das nicht so funktionieren. Viele Grüße – Filterkaffee (Diskussion) 16:57, 9. Apr. 2015 (CEST)
Welche Problemdimensionen Fliegelflagel hier hinzufügt, weiss ich nicht, aber das ursprüngliche Problem ist, dass MediaWiki von sich aus (und zwar erst seit neuerer Zeit: meta:Tech/News/2014/38) BKL-Links die Klasse "mw-disambig" verpasst. Diese Klasse hast du gefunden und die Links per CSS entsprechend gestylt. Das Helferlein Begriffsklärungs-Check (das natürlich erst nachträglich geladen wird, deshalb der Effekt, dass es erst klappte) fügt um solche Links aber noch ein span mit der Klasse "bkl-link" hinzu, und dessen (standardmässiger) CSS-Style hat dann deine Angaben für .mw-disambig überschrieben. Das Helferlein einfach auszuschalten, hätte anstatt der erneuten CSS-Änderung auch geholfen, wobei dann auch der hochgestellte Text "BKL" verschwunden wäre. --YMS (Diskussion) 17:09, 9. Apr. 2015 (CEST)
Danke für den Hinweis auf die neue Klasse. Ich habe das für mich entsprechend geändert, weil ich eine nur-CSS-Lösung schöner finde. Der Text "BKL" ginge eigentlich mit :after auch in CSS, aber für die Hochstellung finde ich keine wirklich gute Lösung. Egal, brauche ich eh nicht. --nenntmichruhigip (Diskussion) 18:34, 9. Apr. 2015 (CEST)
Danke @YMS, dann gibt es dafür ja sogar noch eine zweite Möglichkeit. Viele Grüße – Filterkaffee (Diskussion) 18:38, 9. Apr. 2015 (CEST)
@Nenntmichruhigip: Unabhängig davon, ob du es brauchst oder nicht:
.mw-disambig::after {
 content: "BKL";
 font-size: 70%;
 vertical-align: super;
 line-height: 0;
}
@Filterkaffee, YMS: Ihr seid euch hoffentlich der Tatsache bewusst, dass durch die CSS-Lösung im Gegensatz zu den Javascript-Lösungen Weiterleitungen auf BKLs, also etwa Ap, nicht mehr markiert werden? --Schnark 09:49, 10. Apr. 2015 (CEST)
Wie löse ich das Ganze dann am elegantesten? Mit dem Javascript von Nenntmichruhigip und wo muss ich dann welches Skript deaktivieren? Das in Fliegelflagel oder das in den Einstellungen? Viele Grüße – Filterkaffee (Diskussion) 09:57, 10. Apr. 2015 (CEST)
Was genau meinst du? Von mir gibt's zu dem Thema jedenfalls kein JS :-) Du hast die Auswahl zwischen
  1. deine global.css so lassen wie sie momentan ist und das Helferlein Begriffsklärungs-Check aktivieren und
  2. das Helferlein nicht aktivieren und deine global.css so ändern, dass sie .mw-disambig{background-color: #cfefcf;} und das oben von Schnark geschriebene (für den Text "BKL") enthält.
Mit letzterem hättest du allerdings Weiterleitungen auf BKS nicht markiert. --nenntmichruhigip (Diskussion) 16:54, 10. Apr. 2015 (CEST)
Das sorgt leider auch für grösseren Zeilenabstand… --nenntmichruhigip (Diskussion) 16:54, 10. Apr. 2015 (CEST)
Es gibt noch mein Skript Benutzer:Schnark/js/bkl-check, das Filterkaffee über Benutzer:Schnark/js/fliegelflagel leicht aktivieren kann. Damit gibt es drei Möglichkeiten:
  • CSS: Vorteil: einfach, schnell, funktioniert in allen Projekten (also insbes. in global.css). Nachteil: Weiterleitungen auf BKLs werden nicht markiert, keine Unterscheidung möglich zwischen BKL, Falschschreibung und obsoleter Schreibung.
  • Gadget BKL-Check: Vorteil: einfach, für weitere Kategorien konfigurierbar, Nachteil: langsam, ungepflegt (insbes. funktioniert die Konfiguration höchstwahrscheinlich nicht mehr).
  • Mein Skript: Vorteil: konfigurierbar, theoretisch in allen Projekten einsetzbar, Nachteil: komplizierter zu aktivieren und konfigurieren als das Gadget (der erste Punkt fällt natürlich weg für Leute, die Fliegelflagel verwenden), „theoretisch in allen Projekten einsetzbar“ heißt in der Praxis nur: de.wikipedia und en.wikipedia (wobei weitere Projekte kein Problem sind, aber von mir von Hand konfiguriert werden müssen).
Mischbetriebe von verschiedenen dieser Varianten sind problematisch und sollten daher vermieden werden. --Schnark 09:22, 11. Apr. 2015 (CEST)

Frage zur Sortierung von Tabellen[Quelltext bearbeiten]

Hallo,

ich habe eine sortierbare Tabelle erstellt. Eine Spalte sieht dabei wie folgt aus:

  • 11,931
  • 11,942
  • 14,903
  • 7,204
  • 7,545
  • 9,866

Das Problem dabei ist, dass die Tabelle nach den Ziffern 1-6 sortiert wird und nicht wie gewünscht, die Basiszahl.

Hier der Link zu der Seite: https://de.wikipedia.org/wiki/Selbstverwaltungswahlen_in_Polen_2014#Ergebnisse_in_Prozent

Vielen Dank im Voraus:-)--Kiepski1 (Diskussion) 17:34, 29. Apr. 2015 (CEST)

Siehe Hilfe:Tabellen für Fortgeschrittene #Sortierbare_Tabellen. -- FriedhelmW (Diskussion) 17:56, 29. Apr. 2015 (CEST)
Hallo FriedhelmW, leider wird die Tabelle dadurch so verändert, dass sich die Farbbalken um eine Spalte nach rechts verschieben.--Kiepski1 (Diskussion) 18:33, 29. Apr. 2015 (CEST)
Ich habe da mal syntaktisch eingegriffen. Ausschlaggebend war data-sort-type="number", und bei rowspan="2" weiß keiner, was zu tun ist.
LG --PerfektesChaos 18:59, 29. Apr. 2015 (CEST)
@PerfektesChaos: Das Sortieren nach den Spalten "PiS" und "PO" scheint dem Zufallsprinzip zu folgen. -- FriedhelmW (Diskussion) 19:20, 29. Apr. 2015 (CEST)
Dies wäre mein zweites Problem, welches erst seit kurzem aufgetreten ist. So lassen sich die beiden Spalten im Bearbeitungsmodus und dann bei Vorschau zeigen, einwandfrei sortieren. Im normalen Modus tritt allerdings dieses Problem mit dem nach Zufall sortieren auf... --Kiepski1 (Diskussion) 19:28, 29. Apr. 2015 (CEST)
Lag an den Farben. Gleiches Gegenmittel, und ein defektes Weblink gefixt.
Nebenbei: Unsere Kollegen von der Nachbarwerkstatt WP:VWS sind hier eigentlich zuständiger, aber da gibt es einfach nur mehr Beobachter; wir hier können das auch, hier wie dort.
LG --PerfektesChaos 19:34, 29. Apr. 2015 (CEST)
Könnte man nicht eine Vorlage erstellen, welche dieses Problem beheben würde ohne das Aussehen der Tabelle zu verändern. Ich hätte da an folgendes gedacht:
"Vorlage:Sort"(siehe Berarbeitungsmodus)
Diese wird zu mindest in der polnischen Wikipedia verwendet. Siehe:
--Kiepski1 (Diskussion) 21:02, 29. Apr. 2015 (CEST)
  1. Wir haben sowas; heißt Vorlage:SortKey, und pl:Szablon:Sort weiß auch, dass wir sowas haben: d:Q6140381.
  2. Wir bauen die aber massiv zurück. Wenn es ein Problem gibt, dann wird einmalig data-sort-type="......" in der Kopfzeile eingegeben.
    • Dann erspart man es sich, jeden Wert einzeln einpacken zu müüssen.
    • Dadurch wird der Inhalt viel besser lesbar.
    • Normalerweise klappt es von alleine.
    • Das Ding und seine Gefährten fressen Ressourcen; manche Seiten wurden dadurch so groß und langsam, dass sie nicht mehr aufgebaut wurden.
LG --PerfektesChaos 21:13, 29. Apr. 2015 (CEST)
Sorry , wenn ich etwas dumm frage, bin halt Anfänger;-), aber warum funktioniert die Tabelle bei der polnischen Wikipedia
(sprich:Farbalken bleibt an seinen Platz beim Sortieren) und hier eben nicht?--Kiepski1 (Diskussion) 21:27, 29. Apr. 2015 (CEST)
Was bringt dich auf die Idee, dass da was funktioniert?
FriedhelmW, was siehst du dort?
LG --PerfektesChaos 21:40, 29. Apr. 2015 (CEST)
Wenn Du auf die jeweiligen Farben klickst, dann kann man auch für die restlichen Spalten die Zahlen sortieren lassen.--Kiepski1 (Diskussion) 21:54, 29. Apr. 2015 (CEST)

Abfrage zum Alter der ungesichteten Seiten[Quelltext bearbeiten]

Welche Möglichkeit gibt es das Alter in Tagen der ältesten noch ausstehenden Nachsichtungen auszugeben, sodass man dies in einer Vorlage verwenden kann? Gruß, --Wnme 00:24, 3. Mai 2015 (CEST)

Fehlfunktion des Linksymbols oben im Bearbeitungsfenster[Quelltext bearbeiten]

Wenn ich beim Artikelschreiben eingeloggt bin und einen Begriff mit Hilfe des Linksymbols oben im Bearbeitungsfenster verlinke, fliege ich beim weiteren Schreiben bei der nächsten Betätigung der Zeilensprungtaste aus meinem Wikipediakonto raus. Der eingegebene Text ist verschwunden und das Bearbeitungsfenster des Lemmas geschlossen. Wie kann das sein? Ich habe gestern beim Erstellen eines Textes 10 Versuche gebraucht, den Text fertigzustellen, wobei mir der Text jedesmal gelöscht wurde.--Orik (Diskussion) 00:00, 4. Mai 2015 (CEST)

Da empfehle ich Dir: Erstelle Deinen Beitrag in einem externen Editor, schreibe die links von Hand aus, und kopiere das fertige Projekt anschließend in das Bearbeitungsfenster. Da geht Dir der geschriebene Text nicht mehr verloren. J. K. H. Friedgé (Diskussion) 09:49, 4. Mai 2015 (CEST)

Wenn ich mit solch laienhaftem Vorgehen, das ich auch versucht habe, zufrieden waere, haette ich mich nicht an die technische Nothilfe gewendet. Waere es nicht passender, die Verlinkungssymbol ( eine Kette) aus dem oberen Rand des Bearbeitungsfensters zu nehmen, um nicht dieses jeden Tag zig-tausendfach auftretende Problem zu vermeiden? Oder man kann ja auch diesen Befehl, der oben am Bearbeitungsfenster sitzt, neu programmieren. Das schöne an dem Werkzeug im Bearbeitungsfenster ist doch, dass ich bereitstehende Symbole verwenden kann und nicht jeden Befehl voll ausschreiben muss. Man kann die Verlinkung auch mit dem Werkzeug am unteren Ende des Berabeitungsfensters machen, das ist nicht ganz so komfortabel, aber geht ohne Probleme. Das obere fehlerhafte Symbol ermöglicht gleichzeitiges Schreiben von Linkziel und einen abweichenden Linktext - - also eigentlich eine gute Einrichtung. --Orik (Diskussion) 10:43, 4. Mai 2015 (CEST)
Dass das Problem "jeden Tag zig-tausendfach" auftritt, darf wohl bezweifelt werden, dann gäb's längst jede Menge Beschwerden dazu. Bei mir scheint es jedenfalls nicht aufzutreten. Gerade hier im Abschnitt testweise gemacht: Text eingegeben, Link mit der Bearbeitungsfenster-Funktion gesetzt, Text weitergeschrieben,
Enter gedrückt, weitergeschrieben, Vorschau, alles gut, weitergeschrieben, Speichern, immer noch eingeloggt. Ist das bei dir hier heute noch reproduzierbar? Mit welchem Browser? --YMS (Diskussion) 11:22, 4. Mai 2015 (CEST)
Nun denn, du hast offensichtlich den Assistenten zum Einfügen von Links und Tabellen sowie die Funktion „Suchen und Ersetzen“ aktiviert (deaktivieren würde also das Problem ertsmal lösen). An sich steckt dahinter eine simple JavaScript-Function, daher ist die Frage nach Browser und System sehr berechtigt. User: Perhelion 14:13, 4. Mai 2015 (CEST)
Ich habe den Assistenten wieder demontiert, mal sehen ob es, Zeilensprung

klappt. Ja, ich bin nicht rausgeflogen. Es funkioniert. Danke für den Tip. Ich habe einen Mac, Syst 10.6.8 und den Safaribrowser 5.1.10 ( alles neuestmögliche Software). Gruss --Orik (Diskussion) 17:36, 4. Mai 2015 (CEST)

Kann nicht irgendjemand den Verlinkungsasistenten wieder in Gang bringen! Orik (Diskussion) 22:34, 5. Mai 2015 (CEST)
Da müsste man wohl einen Bugreport öffnen: WP:PHAB User: Perhelion 23:10, 5. Mai 2015 (CEST)
Meine Meldung war die eines absoluten Laien in der Technikwerkstatt. Konnte mal jemand den Bugreport vorschriftsmäßig machen? Das wäre schön. Orik (Diskussion) 04:57, 6. Mai 2015 (CEST)

Hilfe mit TemplateData[Quelltext bearbeiten]

Hallo! Da ich noch nie mehr mit TemplateData gemacht habe, wollte ich hier mal ein paar Meinungen einholen, wie sinnvoll die Funktionalität bei doch eher komplexen Vorlagen wie konkret {{Charttabelle}} (im Zusammenhang mit {{Charteintrag}}, {{Charteintrag2}} und {{Chartauswertung}}) ist (zur Kenntnisnahme: @Mfb, Darkking3:). Ich sehe hier zum einen das generelle Problem des vermutlich eigenwilligen Ausgabeformats durch TemplateData, zum anderen aber natürlich die Schwierigkeiten durch Kombination und Alternierung mehrerer Einzelvorlagen sowie die variabel gehaltenen (von eingegebenen Parametern abhängigen) Parameter und deren Abhängigkeit untereinander. Gibt es bereits Versuche mit ähnlich aufgebauten Vorlagen? Ich hab mal mit grundsätzlichen Definitionen unter Benutzer:XanonymusX/Charttabelle begonnen.--XanonymusX (Diskussion) 15:47, 6. Mai 2015 (CEST)

API: Suche nach Einbindungen von Vorlage[Quelltext bearbeiten]

Nach der Beschreibung müssten die hier gelisteten Ergebnisse eigentlich die Vorlage {{IMDb Name}} eingebunden haben. In den Artikeln (zum Beispiel 10. Panzerdivision oder 24 (Staffel 5)) finde ich eine solche Einbindung aber nicht. Wie ist das zu erklären? --Jobu0101 (Diskussion) 12:23, 15. Mai 2015 (CEST)

list=alltransclusions gibt dir einfach alle Seiten zurück, die eine beliebige andere Seite einbinden, unabhängig davon, was du als titles= angibst. Das richtige API-Modul ist Special:ApiHelp/query+embeddedin, die Abfrage demnach [10]. --91.42.142.58 15:04, 15. Mai 2015 (CEST)
Vielen Dank. --Jobu0101 (Diskussion) 15:25, 15. Mai 2015 (CEST)

patrol-Log unvollständig ausgeblendet[Quelltext bearbeiten]

Nicht schlimm, aber unschön: Auf Spezial:Log hatten wir bis vor ein paar Wochen einen Link zum Zeigen des patrol-Logs. Das hat Wnme mittels MediaWiki:Log-show-hide-patrol ausgeblendet, übrig ist aber noch die/das Pipe, die das patrol-Log vom Markierungs-Log trennt, vgl. [11]. Lässt sich das auch noch irgendwie beseitigen? Gruß --Schniggendiller Diskussion 18:18, 25. Mai 2015 (CEST)

Braucht man dazu Adminrechte? Falls es um diese Zeile geht, das ist alles was ich sehe:
Markierungs-Logbuch zeigen | Sichtungs-Logbuch zeigen | Dankeschön-Logbuch zeigen
--mfb (Diskussion) 18:22, 25. Mai 2015 (CEST)
Es gibt imme rnoch das Problem, dass nur Admins das Patrol-Log ausbelnden können, was man endlich beheben sollte, indem man * das patrolmarks-Recht zuweist. Habe ich irgendwo schon mal angesprochen. --MGChecker – (📞| 📝| User:MGChecker/Bewertung) – HDR 18:51, 25. Mai 2015 (CEST)
Die verlinkte Seite ist für Admins also tatsächlich sinnvoll nutzbar? ;) Und Admins haben die unsinnigen automatischen Sichtungen (>90% der Seite) sogar standardmäßig nicht in der Liste? Das wäre durchaus ein sinnvolles Feature für alle. --mfb (Diskussion) 19:05, 25. Mai 2015 (CEST)
Daß das patrol-Log für Nicht-Admins nicht sichtbar ist, hatte ich gar nicht mehr auf dem Schirm ;-)
Als Admin sehe ich folgendes: | Markierungs-Logbuch zeigen | Sichtungs-Logbuch zeigen | Dankeschön-Logbuch zeigen Die Pipe am Anfang stört, die hätte ich gern weg. Spezial:Log zeigt mir als Admin standardmäßig keine Markierungen, Sichtungen und Dankeschöns. Unangemeldet sehe ich Markierungs-Logbuch zeigen | Sichtungs-Logbuch zeigen | Dankeschön-Logbuch zeigen . Obwohl ich also Sichtungen nicht sehen sollte, sehe ich sie. Wtf?
Gruß --Schniggendiller Diskussion 19:27, 25. Mai 2015 (CEST)
@Schniggendiller: Das patrol-Log ist für Nciht-Admins sichtbar. Sie können es aber leider nicht abschaltzen. :( Dazu braucht man nämlich patrol oder patrolmarks. --MGChecker – (📞| 📝| User:MGChecker/Bewertung) – HDR 19:41, 25. Mai 2015 (CEST)

Suchfeld mobil nur noch grauer Balken in Android 2.3.6[Quelltext bearbeiten]

Vor kurzem habe ich bemerkt, dass in meinem Android-Browser (2.3.6 auf Samsung Galaxy S plus) das Suchfeld von http://de.m.wikipedia.org/wiki/Wikipedia:Hauptseite nur noch als verschwommener grauer Balken angezeigt wird, der sich nicht mehr für eine Eingabe anwählen lässt (es öffnet sich stattdessen ein Menü, bei zurück schließt der Browser). Identisches Verhalten im mobilen Firefox-Browser. Kann leider den Beginn dieses Effekts zeitlich nicht eingrenzen. BTW: Auch die Auf-/Zu-Zeichen bei den Menüpunkten werden nicht mehr angezeigt, womöglich werden hier nun Zeichen verwendet, die Android 2.3.6 nicht kennt. Fände es ärgerlich, wenn aufgrund von Änderungen (Gründe?) die mobile Wikipedia-Nutzung mit Android 2.3.6 nur noch eingeschränkt möglich wäre. (nicht signierter Beitrag von Clapham44 (Diskussion | Beiträge) 10:05, 26. Mai 2015 (CEST))

Ist bei mir auch schon seit ein paar Wochen (Monaten?) so. Aber da die Suche davor auch schon länger nicht mehr richtig funktionierte… Tipp: Ganz unten auf "klassische Anschicht" klicken, da funktioniert die Suche normal ;-) --nenntmichruhigip (Diskussion) 11:03, 26. Mai 2015 (CEST)
Siehe phab:T98498. --AKlapper (WMF) (Diskussion) 11:17, 1. Jun. 2015 (CEST)
Das Problem wurde übrigens behoben. Der Fix sollte auch bereits die Wikipedia erreicht haben :) Grüße --Florianschmidtwelzow (Diskussion) 07:35, 16. Jun. 2015 (CEST)
Mir war auch schon aufgefallen, dass da was anders aussieht. Hatte es aber bisher noch nicht ausprobiert, weil ich mir jetzt (seit der Link protokollrelativ gemacht wurde) angewöhnt habe auf "Klassische Ansicht" weiterzuklicken… Also: Bei mir ist das Suchfeld jetzt schmaler als es sein sollte (<50%) und die Suchvorschläge funktionieren nicht. Eingabe und Volltextsuche geht aber. Jedoch habe ich ein so sehr veraltetes Gerät dass ich selbst nur eingeschränkten Support dafür geben würde, also wenn's bei @Clapham44: funktioniert wär's ok für mich :-) --nenntmichruhigip (Diskussion) 10:35, 16. Jun. 2015 (CEST)

Karten in ortsbezogenen Artikeln[Quelltext bearbeiten]

In jedem ortsbezogenen Wikipedia-Artikel findet man oben rechts einen Link „Karte“. Ein Klick öffnet die OpenStreetMap-Karte und zeigt dort den Ort mit einem Marker hervorgehoben. Alle Wikipedia-Artikel „in der Nähe“ werden auf der Karte ebenfalls mit einem Marker bezeichnet.
So sollte es sein. Warum werden aber nicht die Wikipedia-Artikel der Stadtteile von Neustadt bei Coburg angezeigt (z.B Thann, Meilschnitz, Haarbrücken, usw. ), obwohl es diese alle seit ein paar Monaten gibt??? --Störfix (Diskussion) 18:14, 27. Mai 2015 (CEST)

Falscher Abschnitt in Zusammenfassungszeile bei mobilen Bearbeitungen[Quelltext bearbeiten]

Wieso erscheint in der Zusammenfassungszeile dieses Beitrags „(→‎Einzugsgebiet)“, obwohl Du dich zum Streaming-Portal geäußert hast? Gruß und weiterhin viel Spaß Peter 19:46, 3. Jun. 2015 (CEST)

Weil aus mir unerfindlichen Gründen ich bei der mobilen Anwendung ein paar Abschnitte höher bearbeiten muss, damit es am eigentlichen Ziel ankommt. Frag die Software-Entwickler, warum das so ist.--Gruß Kriddl Bitte schreib mir etwas. 09:03, 4. Jun. 2015 (CEST)

übertragen von Benutzer Diskussion:Kriddl#Zusammenfassungszeile und mit typographischen Anführungszeichen in meiner eigenen Frage ergänzt.

Das Phänomen habe ich nicht nur bei ihm bemerkt. Gruß und Dank Peter 09:08, 4. Jun. 2015 (CEST)

Es nervt noch immer: Spezial:Diff/145198668 -- Peter 17:58, 19. Aug. 2015 (CEST)

Referenzen in der TOC[Quelltext bearbeiten]

Hallo! Man hat mir eine Version mit einer Referenz in ref-Tags im Artikel-Abschnittstitel gezeigt, die in der TOC ausgepackt wird. Ich habe mir die Version mal auf meine Spielwiese geholt: user:TaxonBot/Schweizer Armee Zum Probieren dürft Ihr den Artikel dort gerne bearbeiten

Problem:

  • in einer Abschnittsüberschrift wurde eine Referenz in ref-Tags editiert. Sieht so aus:
    Panzer der Schweizer Armee [28]
    === Panzer der Schweizer Armee <ref>Urs Heller: ''Die Panzer der Schweizer Armee von 1920 bis 2008.''</ref> ===
    
  • in der TOC wird der Inhalt der Referenz ausgeschrieben. Sieht so aus:
    9.3 Panzer der Schweizer Armee <ref>Urs Heller: ''Die Panzer der Schweizer Armee von 1920 bis 2008.''</ref>

Ich meine mich zu erinnern, dass dies schon mal anders funktionierte. Die ref-Nr. wird zwar in der Abschnittsüberschrift, wie es auch sein soll, angezeigt. In der TOC wird aber weder die ref-Nr. noch die Referenz selbst und schon gar nicht die ref-Tags angezeigt. Oder irre ich mich jetzt da. Schönen Dank – Doc TaxonDiskussionWiki-MUC • 19:52, 7. Jun. 2015 (CEST)

Das passiert kurioserweise nicht in den Anm-ref mit group bei Liste der Herrscher Koreas.
Hingegen auch bei: Joseon-Dynastie, Olmütz, Beşiktaş Istanbul, Diakon.
Syntaxfehler zuvor, die das beeinflussen könnten, sind nicht auffindbar.
2.747 Treffer
Sieht nach Bastelei an der Extension aus; mal Phab flöhen. Funktionierte früher; war aber noch nie erwünscht gewesen.
LG --PerfektesChaos 21:07, 7. Jun. 2015 (CEST)
@PerfektesChaos: würdest Du das in den Phabricator kritzeln, mir ist das Ding zu unübersichtlich - keine Ahnung, wie das funktioniert – Doc TaxonDiskussionWiki-MUC • 23:02, 7. Jun. 2015 (CEST)
Ich hab auch ’ne andere Agenda; aber es betrifft nicht nur uns, sondern Hunderte Wikis weltweit. Wird schon jemand von der enWP gemeckert haben.
Die Extension ist bekannt dafür, dass sie bestimmte Syntax innerhalb des ref nicht mehr richtig parsed; ist ein zehn Jahre alter Bug. Diesmal hat sie entweder einen weiteren Kinken abbekommen, oder die Verarbeitung von Überschriften wurde verändert und Wikisyntax innerhalb von Überschriften arbeitet nicht mehr. Gegen letzteres spricht group bei Liste der Herrscher Koreas.
Die Extension ist sowieso buggy, verpennt und schweigsam wie nur was; wundert mich nix.
LG --PerfektesChaos 23:12, 7. Jun. 2015 (CEST)
na dann probier ich das mal irgendwie mit dem Phabricator – Doc TaxonDiskussionWiki-MUC • 23:56, 7. Jun. 2015 (CEST)
Ticket im Phabricator ist vorhanden (und Hilfe zu Phabricator gibt es auch). --AKlapper (WMF) (Diskussion) 00:29, 8. Jun. 2015 (CEST)
@AKlapper (WMF): Ja, mit der Hilfe hab ich es versucht. Eine Meldung damit anzulegen ist mir dennoch nicht geglückt. Ich habe den "Assigned To" nicht gewusst und auch "Projects" (de:wp ?) in der Liste nicht gefunden. – Doc TaxonDiskussionWiki-MUC • 02:49, 8. Jun. 2015 (CEST)
Assigned To darf gern freibleiben und Projects kann auch freibleiben wenn man keine Idee hat. Das ist wahrscheinlich besser auf mw:How to report a bug beschrieben. --AKlapper (WMF) (Diskussion) 10:30, 8. Jun. 2015 (CEST)
"Assigend To": Ein Task ist häufig jemand zugeordnet, wenn er gerade daran arbeitet oder ein Patch eingestellt hat und somit gearbeitet hat. Ein neuer Task wird im Normalfall nicht zugeordnet, dadurch landet er im großen Topf, aus dem sich jeder bedienen kann. Project wäre in diesem Fall "MediaWiki-extension-Cite", weil die Refs aus der mw:Extension:Cite stammen (Muss man nicht wissen, daher frei lassen). Der Umherirrende 17:46, 8. Jun. 2015 (CEST)

In der Hauptsache: Die Änderung wurde rollbacked, war schon vor diesem Thread in der enWP aufgefallen.

  • Welches project? WP:PHAB/T und nach <ref suchen.

LG --PerfektesChaos 16:38, 12. Jun. 2015 (CEST)

Benutzer:Schnark/js/personendaten.js/normdaten.js[Quelltext bearbeiten]

Ich benutze Schnarks kombiniertes PD&ND-Skript derzeit extrem oft. Seit gestern nachmittag kann ich aber plötzlich nur noch die ND bearbeiten, aber nicht mehr die PD. Ich habe zwar Schnark gestern abend auf seiner Seite gefragt, woran es liegen könnte, aber bisher keine Antwort bekommen (auch kein Wunder, so lange ist das ja noch nicht her). Trotzdem frage ich hier nach, weil es für meine derzeitige Arbeit sehr wichtig ist. Ich habe gehört, dass immer Donnerstags Wikipedia-Patchday sei, kann es damit zusammenhängen? MfG --Informationswiedergutmachung (Diskussion) 11:09, 26. Jun. 2015 (CEST)

Es wird möglicherweise an der Änderung von Modul jquery.mwExtension zu Modul mediawiki.RegExp liegen. Schnark verwendet zwar mw.loader.using('jquery.mwExtension'), aber vielleicht ist irgendwo etwas vergessen. Hast Du unter Spezial:Einstellungen#mw-prefsection-editing die Option „Erweiterte Bearbeiten-Werkzeugleiste aktivieren“ aktiviert. Der WikiEditor lädt derzeit noch jquery.mwExtension. Vielleicht hilft das übergangsweise. --Fomafix (Diskussion) 11:28, 26. Jun. 2015 (CEST)
Ich hatte gestern Abend für einige Stunden ein vergleichbares Problem, das sich heute morgen entmaterialisert hatte (phab:T103891).
  • Browser-Cache heftig löschen.
  • Wenn du kannst, mal vorübergehend mw.loader.store.clear(); vorn in deine common.js einbauen.
  • Wenn du kannst, WP:JS#Fehlerkonsole nutzen und uns mögliche Details benennen.
Schnark schaut erfahrungsgemäß morgen früh rein.
Um die Ausgangsfrage zu beantworten: Ja, kann es. Der Plan von Fomafix ist nachvollziehbar.
VG --PerfektesChaos 12:02, 26. Jun. 2015 (CEST)
"Erweiterte Bearbeiten-Werkzeugleiste aktivieren" war schon aktiviert, den Cache habe ich geleert, den mw.loader.store.clear(); eingebaut. Funktioklappt aber trotzdem nicht. Und mit WP:JS#Fehlerkonsole kenne ich mich so gut wie gar nicht aus. Nun ja, muss ich auf Schnark warten, danke für die Antworten. MfG --Informationswiedergutmachung (Diskussion) 12:20, 26. Jun. 2015 (CEST)
Es liegt daran, dass das Modul 'jquery.mwExtension' verwendet wird, bevor es geladen ist. Das Modul war vor der Änderung wohl standardmäßig bei jedem Artikel geladen, so dass die fehlende Abhängigkeit nicht aufgefallen ist. Jetzt wird das veraltete Modul nicht mehr geladen und dann gehen teilweise Skripte kaputt. Ich vermute aber, das alle diese Skripte auch schon vorher die Abhängigkeit nicht eindeutig deklariert hatten. (gerrit:219570, Abhängigkeit war sonst über 'mediawiki.util.js' immer gegeben, weil das Modul immer da ist). @Schnark: müsste migrieren oder die Abhängigkeit ergänzen (oder beides). Der Umherirrende 16:39, 26. Jun. 2015 (CEST)
so wie es jetzt ist, ist es jedenfalls unbrauchbar. Mit Hand PD nachtragen oder sie zu überprüfen führt zu einem viel zu hohen Arbeitsaufwand. Gestern habe ich Gustav Laddey erstellt, üblicherweise brauche ich für einen Artikel (ohne Schreibfehlerkorrektur) genau zwei Edits: einen, um ihn neu reinzustellen und einen, um ihn mit PD & ND zu ergänzen. Das dauert keine Minute, gestern habe ich dafür fünf Minuten gebraucht. Die Bitte geht daher an Schnark das nach Möglichkeit schnell zu ändern, u.a. weil ich diese Liste (4.587 Fehler, noch) schnellstmöglich abarbeiten will. Zwar funktioniert das ND-Tool, aber oft genug sind die PD auch ungenügend und zweimal alles abarbeiten wäre reine Zeitverschwendung. --Informationswiedergutmachung (Diskussion) 17:36, 26. Jun. 2015 (CEST)
@Umherirrender: Verwende ich es denn irgendwo ohne die Abhängigkeit korrekt zu deklarieren? Für mich sieht es so aus, als handle es sich nur um Fehler in anderen Skripten, die dann halt auch meine beeinträchtigen. (Was nicht heißt, dass ich die Funktion nicht dringend ersetzten sollte, mein Testskript, das mich über Deprecations unterrichtet, dreht gerade durch und spuckt 8825 Warnungen aus.) --Schnark 09:52, 27. Jun. 2015 (CEST)
@Schnark: Ich bin gestern auf eine Artikelseite einer Person gegangen und habe in der Konsole importScript( 'Benutzer:Schnark/js/personendaten.js' ); geschrieben, damit dein Skript geladen wird. Anschließend gab es "Das Objekt unterstützt die Eigenschaft oder Methode "escapeRE" nicht" in der Funktion wo staatenRe aufgebaut wird. Daraus habe ich geschlossen, dass die Funktion dann nicht zur Verfügung steht, wenn sie gebraucht wird. Du lädst die Funktion, aber anscheinend wird sie auch schon bei der Initialisierung benötigt und stand dann nicht zur Verfügung. IE11. Nach deiner Änderung funktioniert wieder alles ohne Fehler. Der Umherirrende 10:28, 27. Jun. 2015 (CEST)
Ups, du hast recht. Sollte jetzt korrigiert sein. --Schnark 10:36, 27. Jun. 2015 (CEST)
Guten Morgen, ich vestehe zwar euer Fachchinesisch nicht so ganz, aber: das PD-Tool funzt bei mir immer noch nicht wieder. MfG --Informationswiedergutmachung (Diskussion) 11:49, 27. Jun. 2015 (CEST)

Sortierpfeile[Quelltext bearbeiten]

Hallo! Eine kurze Nachfrage: unter Hilfe:Tabellen für Fortgeschrittene#Sortierbare Tabellen steht Eine sortierbare Tabelle erkennt man daran, dass sie in den Spaltenköpfen kleine Doppelpfeilsymbole zeigt. … Die Symbole sind auch als Icons (Sort both.svg und schmal Sort both small.svg) verfügbar. Heißt das, man kann irgendwie die Sortierfunktion mit schmalen Icons statt des Standards durchsetzen? Welche Einstellung ist dazu nötig? Gruß--XanonymusX (Diskussion) 11:49, 2. Jul. 2015 (CEST)

Mit folgender CSS-Definition kannst Du die Symbole schmaler machen:
table.jquery-tablesorter th.headerSort {
    background-position: right -4px center;
    padding-right: 12px;
}
--Fomafix (Diskussion) 13:33, 2. Jul. 2015 (CEST)
Okay, danke. Das bei einer einzelnen Tabelle (bzw. Vorlage) für alle umzustellen ist nicht möglich, oder?--XanonymusX (Diskussion) 18:35, 2. Jul. 2015 (CEST)
@Fomafix: Noch was: Kennst du dich besser mit sortable aus, dass du uns mit diesem Problem (Sortierbarkeit der vorbereiteten Vorlage ist falsch) weiterhelfen könntest?--XanonymusX (Diskussion) 02:15, 10. Jul. 2015 (CEST)

Hovercards in eowp spinnt[Quelltext bearbeiten]

Hallo. Bei mir ist die Betafunktion "Hovercards" in der Esperantowikipedia seit einigen Tagen total verkorkst. Statt der Tooltips erscheint der Text unformatiert unterhalb der Liste der aktuellen Änderungen. Da sind wohl die Formate verschwunden. Leider weiß ich nicht warum. :-( --Tlustulimu (Diskussion) 21:14, 10. Aug. 2015 (CEST)

Wie finde ich denn die "Liste der aktuellen Änderungen" in einem Artikel? Oder bezieht sich dies nicht auf einen Artikel? Genaue Schritte zum Reproduzieren des Problems sehr willkommen. :) --Malyacko (Diskussion) 13:12, 12. Aug. 2015 (CEST)
Es geht um diese Spezialseite, nicht um irgendeinen Artikel. --Tlustulimu (Diskussion) 19:54, 12. Aug. 2015 (CEST)
In meiner dortigen Beobachtungsliste tritt der Fehler auch auf. Wenn ich die Gadgets alle ausschalte, bleibt das Problem bestehen. Es kann also kaum an einem Gadget liegen. --Tlustulimu (Diskussion) 10:19, 14. Aug. 2015 (CEST)

Globales Benutzerkonto[Quelltext bearbeiten]

Leider funktioniert die globale Anmeldung immer noch nicht für "Commons"? Wer weiß etwas? Liegt's an mir, am Browser, an was auch immer? J. K. H. Friedgé (Diskussion) 11:36, 12. Aug. 2015 (CEST)

Was heisst den "funktioniert nicht" genau? Gibt es Fehlermeldungen? Funktioniert es mit einem anderen Browser, oder wenn man den "privaten Modus" vom Browser benutzt? --Malyacko (Diskussion) 13:17, 12. Aug. 2015 (CEST)
Laut Spezial:CentralAuth/J. K. H. Friedgé ist Commons Bestandteil deines Globalen Benutzerkontos. Kann es sein, das du Cookies so stark eingeschränkt hast, das sie für "*.wikimedia.org" nicht funktionieren? Was ist wenn du dich auf Commons zu erst anmeldest, bist du dann hier nicht angemeldet? Der Umherirrende 14:12, 12. Aug. 2015 (CEST)

Hallo @Umherirrender:, bin etwas spät, aber Deinen Vorschlag kann ich schlecht ausprobieren, weil ich dann meine ganze "Automatik" abschalten müsste. Was ist da in commons/wikimedia anders? Die Annahme von cookies ist bei mir insoweit reglementiert, als dass sie beim Verlassen der Seite gelöscht werden. Das erstaunlichste ist ja, dass ich meine Benutzerseite in commons aufrufen kann, indem ich auf der "Globale Benutzerkonten"-Seite auf den commons-link klicke? Beim nächsten Neustart werde ich versuchen die "Automatik" zu überlisten ;=) J. K. H. Friedgé (Diskussion) 11:14, 14. Okt. 2015 (CEST)

Kategorien auslesen und für Commons übersetzen[Quelltext bearbeiten]

Hallo, ich lege relativ häufig neue Personenkategorien auf Commons an, um die überfüllten People-by-occupation-Kategorien übersichtlicher zu machen und die Verknüpfung der Commons-Inhalte mit den Wikipedia-Personenartikeln zu erleichtern. Die Anlage der Kategorien ist eine recht öde Tätigkeit: Namen für DEFAULTSORT umdrehen, Tätigkeitskategorie und eventuelle Zusatzkategorien bestimmen, Geburtsjahr- und ggf. Todesjahrkategorie eintragen, "People by name"-Kategorie ergänzen. Öde deshalb, weil die ganzen Informationen im deutschen Wikipedia-Artikel eigentlich schon vorliegen und nur angepasst werden müssen. Ist im Einzelfall kein dramatischer Aufwand, wird mit steigender Menge aber doch langweilig. Enorm hilfreich wäre ein Tool, das

  • den Sortierschlüssel aus einem jeweils vorgegebenen DE-Artikel ausliest und in die Defaultsort-Vorlage umsetzt
  • dann die im DE-Artikel vorhandenen Kategorien anhand einer von mir angelegten (und ggf. einfach erweiterbaren) Konkordanzliste übersetzt
  • und das Ergebnis so ausspuckt, dass ich es einfach auf die Commons-Kategorienseite kopieren kann

Beispiel: Wikipedia hat den Artikel Othmar Baier mit dem Sortierschlüssel {{SORTIERUNG:Baier, Othmar}} und den Kategorien [[Kategorie:Hochschullehrer (Technische Universität München)]] sowie [[Kategorie:Geboren 1905]]. Das Tool soll daraus {{DEFAULTSORT:Baier, Othmar}} und (nach einem Abgleich mit meiner Übersetzungsliste) [[Category:Technische Universität München faculty‎]] sowie [[Category:1905 births]] machen. Ich habe keinerlei Ahnung von Software oder Programmierung und kann nicht einschätzen, ob sowas möglich ist bzw. wie aufwendig das wäre. Aber ich würde mich sehr darüber freuen, wenn jemand das angehen könnte... --Rudolph Buch (Diskussion) 19:07, 26. Aug. 2015 (CEST)

Ich habe keine Ahnung davon, aber irgendwie erinnert es mich an Lukes Ideen. Gruß an euch beide, Peter 19:34, 26. Aug. 2015 (CEST)
Klar, gehen tut das. @Rudolph Buch: verschieb dein anlegen mal nach Wikipedia:Bots/Anfragen. Per Bot geht das, den Defaultssort auslesen, und die Kats. Dann von den Kats über Wikidata prüfen, ob in Commons existent, und dann eine Liste anlegen. Wikidata ist nur nicht meine Sache, zumindest noch nicht, deswegen müsstest du dich wohl an einen anderen Botbetreiber wenden, also einfach dein anliegen dort schildern. Viele Grüße, Luke081515 19:40, 26. Aug. 2015 (CEST)
@Luke: Danke, ich hoffe, Du verzeihst mir, dass ich Dich da mit reingezogen habe. Gruß Peter 20:10, 26. Aug. 2015 (CEST)
Uhm, ich hab es falsch ausgedrückt: Ich will gar nicht, dass ein Bot den ganzen Vorgang für eine Vielzahl von Personen macht - sich jedes Bild und jede Person einzeln "menschlich" anzuschauen, ist schon sinnvoll, weil der Zusammenhang zwischen Bilddatei und Personenartikel nicht immer eindeutig ist. Aber mühsam im Sinne stupider Abtipperei ist dann, die Informationen aus dem konkreten WP-Artikel in Commons zu überführen: Ich habe bislang wohl an die 800 Commonskategorien angelegt, und da nervt es dann irgendwann allein schon, jedesmal die Namen wegen Defaultsort nochmal umgedreht eintippen zu müssen oder "1905 births" einzutippen, obwohl das im Grunde ja schon im WP-Artikel steht - nur halt auf Deutsch. Mein Traum wäre also ein Befehl "Liebes Script, bitte schau in den Artikel X und nimm die Kategorien, die da stehen. Vergleiche diese Kategorien dann mit einer Tabelle, die ich Dir gegeben habe. Und wenn Du in der ersten Spalte dieser Tabelle eine Kategorie aus dem Artikel findest, dann spuck die Category aus der zweiten Spalte der gleichen Zeile aus." Oder so ähnlich :-) --Rudolph Buch (Diskussion) 20:00, 26. Aug. 2015 (CEST)
Prinzipiell sollte mein Skript Benutzer:Schnark/js/stub bei geeigneter Konfiguration dazu in der Lage sein. --Schnark 09:15, 27. Aug. 2015 (CEST)
Per API auf den Artikelquelltext zugreifen, nach Defaultsort und direkt eingebundenen Kategorien suchen, mit einer Liste abgleichen. Ist mit JS wohl gut machbar. Alternativ die Kategorien auch über die API holen, dann hat man Infoboxen besser abgedeckt. --mfb (Diskussion) 09:48, 27. Aug. 2015 (CEST)
Defaultsort gibt es per prop=pageprops. Also So. Alternativ aus Wikidata die Sachen holen. Der Umherirrende 16:20, 28. Aug. 2015 (CEST)

Machbarkeitsabschätzung Vorlage für Dokumente in Cloude-Speicher mit Ausnahme für Editfilter[Quelltext bearbeiten]

Grundsätzlich halte ich Dokumente die in Cloude-Speicher (z.B. Google-Drive, Dropbox,...) für wenig Enzyklopädie-tauglich. Eine wesentliche Ausnahme sind Dokumente mit Backlinks von Seiten die den Kriterien von WP:Q oder WP:WEB voll entsprechen. Ein Beispiel dafür wäre der Backlink http://seedsoflifetimor.org/climatechange/resources/ der zu diesen Dokumenten führt: 238 Verlinkungen im ANR

Die Idee ist nun eine Vorlage zu bauen, die die URL des Backlink als Pflichtparameter, sowie die ID des Cloude-Speichers aufnimmt. Die Vorlage verlinkt auf das Cloude-Dokument, der Editfilter soll in diesem Fall nicht schlagend werden. Ev. könnte die Vorlage noch einen unsichtbaren zusätzlichen Wartungslink mit der ID produzieren.

Die Frage ist nun, ob es möglich ist, Edit-Filter zu bauen, die eine URL nicht filtern, wenn die entsprechende Vorlage verwendet wird. Frohes Schaffen — Boshomi ☕⌨☺ Defekte URLs - Hilfe gesucht  23:29, 7. Sep. 2015 (CEST)

Ist möglich, aber der Vorlagencode würde ein How-To, wie man den Editfilter umgehen kann. Ich denke das ist es nicht wert. --mfb (Diskussion) 00:06, 8. Sep. 2015 (CEST)
@Mfb: Angenommen der Cloude-URL lautet auf
https://drive.google.com/folderview?id=0B13RUdSV85KfN3Bxb3kyLW9VSjQ&usp=sharing&tid=0B13RUdSV85KfU0tDQ2ctV09Eb1U und die unsichtbare Check-URL
http://drive.google.test/folderview?id=0B13RUdSV85KfN3Bxb3kyLW9VSjQ&usp=sharing&tid=0B13RUdSV85KfU0tDQ2ctV09Eb1U und der Filter wäre in der Lage auf das Vorhandensein beider URLs zu reagieren, dann wären die Umgehungsmöglichkeiten des Filters schon extrem eingeschränkt, da das https://drive.google.com/ im Filter hard-vercodete wäre.
Derzeit gibt es den Filter 28 auf drive.google.com, der aber nur warnt. Wirklich scharf lässt sich der Filter wegen der vielen False-Positive nicht schalten. Eine manuelle Überprüfung in der Wartungsliste Wikipedia:WikiProjekt_Weblinkwartung/Toter_Link/Liste_google_user_content würde auch weiterhin erfolgen, sodass die technische Umgehbarkeit durch manuelle Kontrolle schnell aufgedeckt würde.  Frohes Schaffen — Boshomi ☕⌨☺ Defekte URLs - Hilfe gesucht  15:56, 8. Sep. 2015 (CEST)
Hmm warte, ich hatte bislang an die URL-Blacklist gedacht. Im Bearbeitungsfilter kann man wohl zwischen Vorlage und Quelltext unterscheiden. Außer einer besseren Nachvollziehbarkeit sehe ich aber keinen Vorteil - man könnte immer noch beliebige Google-Drive-Links einfügen, außer wir erstellen eine Whitelist irgendwo. In dem Fall könnte man aber auch die normale URL-Black/Whitelist nutzen.
Das Problem, was ich eingangs erwähnte: Die URL-Blacklist verhindert recht erfolgreich massenhaften URL-Spam. Wenn eine Vorlage zeigt, wie man die umgehen kann, kann ein Spammer das auch abseits der Vorlage ausnutzen. --mfb (Diskussion) 16:14, 8. Sep. 2015 (CEST)
Defakto geht es mir um einen Vorlagenzwang für Dokumente aus Cloude-Speichern. Wenn die Vorlage verwendet wird gibt der Bearbeitungsfilter ruhe, ansonsten kommt die Meldung, dass die Vorlage zu verwenden ist, ansonsten wird das Abspeichern verhindert. Der Vorteil der Vorlage wäre die deutlich einfachere Überprüfbarkeit. Ich denke da an Bearbeitungsfilter, nicht an die Spamm-Black-List. Die kann man zwar mit White-List-Einträgen überroulen, aber das ist den meisten Benutzern zu kompliziert, und würde bei der Menge an Dokumenten irgendwann an Grenzen stoßen.
Die Frage ist also ob Bearbeitungsfilter tatsächlich auf URLs reagieren können, die durch Vorlagen generiert werden, und auf der Oberfläche unsichtbar sind. Das Problem der Umgehungsmöglichkeit ist wegen der Einschränkung auf wenige Cloude-Domains und dem gleichzeitigen Aufbau manueller Wartungslisten extrem gering, und falls man den zweiten .test-Link in einer Untervorlage steckt sowieso nur von Vorlagenspezialisten auffindbar. Frohes Schaffen — Boshomi ☕⌨☺ Defekte URLs - Hilfe gesucht  18:02, 8. Sep. 2015 (CEST)
Man kann auf hinzugefügten Text "drive.google.com" prüfen, und die Vorlage soll dann nur id=0B13RUdSV85KfN3Bxb3kyLW9VSjQ&usp=sharing&tid=0B13RUdSV85KfU0tDQ2ctV09Eb1U oder Ähnliches als Parameter bekommen sodass die Domain nicht im hinzugefügten Quelltext erscheint. --mfb (Diskussion) 18:27, 8. Sep. 2015 (CEST)

VisualEditor und Wikitext[Quelltext bearbeiten]

So, noch eine VE-Frage: Folgender Code tut mal wieder fast das, was ich will:

function replaceWithWikitext (wikitext) {
	var formData = new FormData();
	formData.append('wikitext', wikitext);
	$.ajax({
		url: '/api/rest_v1/transform/wikitext/to/html/' + mw.config.get('wgPageName'),
		type: 'POST',
		data: formData,
		contentType: false,
		processData: false,
		dataType: 'html'
	}).done(function (html) {
		var newDoc = ve.dm.converter.getModelFromDom(ve.parseXhtml(html), {
			lang: mw.config.get('wgVisualEditor').pageLanguageCode,
			dir: mw.config.get('wgVisualEditor').pageLanguageDir
		}), surfaceModel = ve.init.target.getSurface().getModel(),
			documentModel = surfaceModel.getDocument(),
			range = documentModel.getDocumentNode().getOuterRange();
		surfaceModel.breakpoint();
		surfaceModel.change([
			ve.dm.Transaction.newFromRemoval(documentModel, range, true),
			ve.dm.Transaction.newFromDocumentInsertion(documentModel, 0, newDoc)
		]);
		surfaceModel.breakpoint();
	});
}
replaceWithWikitext('\'\'Beliebiger\'\' [[Wikitext]]');

Führt man ihn während einer Bearbeitung aus, dann wird der gesamte Inhalt durch den übergebenen Wikitext ersetzt, überführt in das Format des VE. Nur bei Vorlagen gibt es eine Sache, die mich stört: Lässt man sich etwa {{cite web|first=first name|last=last name|title=title|url=http://en.wikipedia.org}} einfügen, dann kommen im letztendlich erzeugten Wikitext Leerzeichen um die Gleichheitszeichen (sichtbar, wenn man sich die Änderungen vor dem Abspeichern zeigen lässt).

Daher meine Frage: Wo geht die Information über die genaue Formatierung verloren (wenn man einen Artikel mit Vorlagen bearbeiten, bleibt diese ja im Normalfall auch erhalten)? Oder noch besser: Was muss ich ändern, dass der beim Speichern erzeugte Wikitext exakt mit dem eingefügten übereinstimmt? --Schnark 11:50, 23. Sep. 2015 (CEST)

Editor lädt nicht immer richtig[Quelltext bearbeiten]

Hallo zusammen! Ich bin die Frage schon einmal bei Wikipedia:Fragen zur Wikipedia losgeworden, aber da konnte mir keiner weiterhelfen. Vielleicht ist hier der richtige Ort:

Ich habe seit einigen Wochen das Problem, dass beim Laden der Editierierseiten hier manchmal der Editor nicht richtig geladen wird. Also die Zeile über dem Text (mit Signierbutton und so weiter) fehlt. Ich drücke dann meist auf "Vorschau zeigen", dabei wird ja die komplette Seite neu geladen, dann ist der Editor meist auch richtig zu sehen.

Wie kommt es zu diesem Fehler und wie lässt er sich beheben? --Jobu0101 (Diskussion) 09:55, 24. Sep. 2015 (CEST)

  1. Du bist hier sowas von an der richtigen Adresse für solche Fragen.
  2. Es könnte Probleme in der MediaWiki-Software geben; andere Skripte, die du benutzt, könnten deinen Seitenaufbau zum Absturz bringen.
  3. Wir fangen aber mal bei dir selbst an:
  4. Was genau darf ich mir eigentlich unter „Zeile über dem Text (mit Signierbutton und so weiter)“ vorstellen – wir haben oben zwei verschiedene Technologien dazu, siehe Hilfe:Symbolleisten.
  5. Du hast zwei weitere wirkungslose Blöcke in Benutzer:Jobu0101/common.js, die ich an deiner Stelle löschen würde:
    • removeEditWarning – wird nicht gestartet, und würde man anders konfigurieren
    • if (wgAction=="edit") – tut nix, und irgendwann noch weniger.
Ersatz für Benutzer:Jobu0101/common.js
Statt
addOnloadHook(function() {
  if (wgAction == "edit") {
    window.setTimeout("selectswitch()", 100);
  }
});
besser
if ( mw.config.get( "wgAction" ) === "edit") {
   $( selectswitch );
}
(was immer das dann tun würde; ich habe die Absicht nicht so ganz verstanden).
LG --PerfektesChaos 10:24, 24. Sep. 2015 (CEST)
Vielen Dank PC für deine schnelle und kompetente Hilfe.
  1. Ich arbeite schon seit langem mit Vector.
  2. Diese Leiste hier: Erweiterte Bearbeiten-Werkzeugleiste (Vektor).png.
  3. Die Absicht war, dass in der Leiste, in der standardmäßig "Standard" ausgewählt ist, automatisch "WikiSyntax" ausgewählt wird. Nur leider sehe ich diese Leiste auch immer seltener.
Ich muss nun mal ein bisschen, ob das ursprüngliche Problem nun behoben ist. Bislang sieht es gut aus. Vielen Dank nochmals! --Jobu0101 (Diskussion) 11:35, 24. Sep. 2015 (CEST)
Ich habe nun das $(selectswitch); mal auskommentiert. Nun wird die Leiste unten wieder angezeigt, nur natürlich nicht auf WikiSyntax umgestellt. --Jobu0101 (Diskussion) 11:42, 24. Sep. 2015 (CEST)
  • Dein selectswitch hat einen massiven Fehler:
    • Die drei Variablen tools, summ, sel sind nicht mittels var als Funktions-intern deklariert. Damit würden sie andere Variablen gleichen Namens im globalen Namensraum überschreiben, sofern es dort solche gäbe; was aber auch unklug durch den Autor eines anderen Skriptes wäre.
  • Einen Schalter [Standard] ./. [WikiSyntax] gibt es; aber nicht in der abgebildeten Leiste oberhalb des Fensters, sondern unterhalb bei einem dritten Werkzeug.
    • Darf ich dir dazu meine editToolStrIns anempfehlen? Sie wirken erstmal genauso, aber erlauben dir auch die zusätzliche Konfiguration eines eigenen Sortiments, auch etwa zum Einfügen von Vorlagen.
    • Dein einfacher Wunsch nach Änderung der Reihenfolge würde dann realisiert werden, indem man vor dem Laden angibt:
if ( typeof mw.libs.editToolStrIns  !==  "object" ) {
   mw.libs.editToolStrIns = { };
}
mw.libs.editToolStrIns.user = { "custom": [ "WikiSyntax", true ] };

LG --PerfektesChaos 12:26, 24. Sep. 2015 (CEST)

Ja, mir ist bewusst, dass es sich bei der Leiste, die ich nun als zweites ansprach (das war nicht mein ursprüngliches Anliegen), um eine andere handelt, die unterhalb des Editierfeldes angezeigt wird. Ich habe nun versucht, deine editToolStrIns einzubinden. Jedoch wird standardmäßig immer noch nicht WikiSyntax ausgewählt. Das Skript, das das vorher machen sollte, stammte übrigens nicht aus meiner Feder, aber drübergucken hätte ich wohk trotzdem noch einmal sollen. Vielen Dank für deine Hilfe. --Jobu0101 (Diskussion) 15:27, 24. Sep. 2015 (CEST)
Oh, sorry, ich habe dir eine etwas falsche Auskunft gegeben: Die fragliche Zeile muss lauten
mw.libs.editToolStrIns.user = { "custom": [ "[[]]", true ] };
– dann klappt das auch.
  • Hintergrund ist, dass der interne eindeutige Bezeichner "[[]]" angegeben werden muss; „WikiSyntax“ ist nur ein beliebiger Text zur Anzeige ohne programmtechnische Bedeutung.
  • Geschrieben hatte ich das 2011, seitdem nur selten konfiguriert oder mit Anfragen zu tun gehabt; deshalb war es mir nicht mehr so präsent.
Wenn das erstmal funktioniert hat, magst du vielleicht noch etwas anderes ausprobieren; ersetze die fragliche Zeile mal durch
mw.libs.editToolStrIns.user =
   { "custom": [ "@Jobu0101", "Jobu",
                 "[[]]",      true ],
     "defs":
      { "@Jobu0101": [ [ [ "<jobu>", "</jobu>", "", "Meins!" ],
                         [ "{{Jobu0101|", "}}" ] ],
                       [ "’",
                         [ "„", "“" ],
                         [ "‚", "‘" ],
                         [ "»", "«" ],
                         [ "›", "‹" ],
                         [ "“", "”" ],
                         [ "‘", "’" ],
                         [ "«", "»" ],
                         [ "‹", "›" ],
                         [ "–", "", "", "Bisstrich/Gedankenstrich" ] ],
                       [ "+",
                         [ "−", "", "", "mathematisches Minus" ],
                         [ "·", "", "", "mathematisches Mal" ] ],
                       false,
                       [ 1, "×÷≈≠±≤≥²³½†#*‰§€¢£¥$¿¡∞‣•β" ],
                       [ "…", "→", "↔" ],
                       [ [ "&nbsp;", "", "", "Geschütztes Leerzeichen" ],
                         [ "[[", "]]", "", "Wikilink" ],
                         "|",
                         [ "{{", "}}", "", "Vorlageneinbindung" ],
                         [ "~~~~", "", "", "Signatur" ] ],
                       [ [ "°", "", "", "Grad" ],
                         [ "′", "", "", "Bogenminute, Fuß" ],
                         [ "″", "", "", "Bogensekunde, Zoll" ] ],
                     [ "<br />",
                       [ "<code>", "</code>" ],
                       [ "<code style=\"white-space: nowrap\">",
                         "</code>" ],
                       [ "<s>", "</s>" ],
                       [ "<small>", "</small>" ],
                       [ "<sub>", "</sub>" ],
                       [ "<sup>", "</sup>" ],
                       [ "<!-- ", " -->" ] ] ]
   } };
LG & viel Erfolg --PerfektesChaos 21:08, 24. Sep. 2015 (CEST)
Habe deinen Spezielvorschlag nun endlich mal ausprobiert. Ich bekomme meine eigene Abkürzungsleiste, doch beim Anklicken der neuen Tools passiert nichts, außer dass das Fenster nach oben scrollt. --Jobu0101 (Diskussion) 10:45, 23. Okt. 2015 (CEST)
Inzwischen klappt es. Ich habe jedoch, bevor ich das hier schrieb, das Editierfeld mehrfach neugeladen. War wohl dennoch zu wenig. Vielen Dank, PerfektesChaos, für diese nette Möglichkeit, mir meine eigene Leiste zu basteln. --Jobu0101 (Diskussion) 10:54, 23. Okt. 2015 (CEST)

Übrigens: Das urspüngliche Problem haben wir durch diese Sache hier doch nicht behoben: Es kommt nach wie vor oft vor, dass die obere Werkzeugsleiste einfach fehlt. --Jobu0101 (Diskussion) 10:54, 23. Okt. 2015 (CEST)

Dann stürzt irgendwas ab, zumindest manchmal, je nach Rechengeschwindigkeit, und reißt die Werkzeugsleiste mit sich. Ein paar Fehlerursachen hatte ich oben schon mal identifiziert.
Um aus der Ferne nachvollziehen zu können, was bei dir los ist, bedürfte es WP:JS #Fehlerkonsole und nur weniger Zeilen an Fehlermeldungen, die beim Aufbau einer kaputten Bearbeitungsseite auftreten und sonst nicht.
LG --PerfektesChaos 11:17, 23. Okt. 2015 (CEST)
Okay, vielen Dank. Dann werde ich mal ein Auge auf die Konsole werfen. --Jobu0101 (Diskussion) 15:06, 23. Okt. 2015 (CEST)

Stand der Technik bei Extraktion von Vorlagenparametern?[Quelltext bearbeiten]

Alle paar Monate gleiche ich TV-Episodenlisten und ähnliches mit meiner lokalen Datenbank ab, die ich andererseits wiederum mit IMDb und vergleichbaren Quellen abgleiche. Dazu kopiere ich normalerweise den Wiki-Quelltext und suche/ersetze ad hoc in meinem Editor die Aufrufe von beispielsweise en:Template:Episode list durch SQL-Tupel. Es juckt mir immer in den Fingern, das beispielsweise mit einem (Python-)MediaWiki-Parser zu automatisieren, auf der anderen Seite wäre eine direkte Lösung in JavaScript, die eine Textbox mit den extrahierten Daten zwecks Kopieren in die Zwischenablage anzeigt natürlich schöner.

Wie ist in Zeiten von Parsoid der Stand der Technik, mit Benutzer-JavaScript die Parameter von Vorlagen abzufragen? Hat jemand ein Beispiel-Script dafür? Ich möchte gerne:

===Series 1 (1999)===
[…]
{{Episode list
 |EpisodeNumber=1
 |Title=The Timber Frame Kit House
 |Aux1=Newhaven, East Sussex
 |OriginalAirDate=29 April 1999
 |ShortSummary=Tim Cox and Julia Brock want to build their home on a clifftop in Newhaven.
 |LineColor=ffc0b2
}}
[…]

in Tupel à la:

(1, 1, 'The Timber Frame Kit House', 'Newhaven, East Sussex'),

umwandeln. --Tim Landscheidt 03:53, 2. Okt. 2015 (CEST)

WSTM kann sowas fast perfekt in JavaScript.
Es ist aber eine harte Nuss: Pipes können bei den Parameterwerten in Wikilinks auftreten, in eingeschachtelten Vorlagen, als Vorgabewerte von Parametern, innerhalb eines Kommentars unwirksam, in Bildeinbindungen, deren Bildlegende wieder Vorlagen und Bilder und sogar Tabellen nebst nowiki-unwirksamen Pipes enthalten kann. Ansonsten tun es triviale RegExps.
Code bei WSTM_T unter WSTM.w.template.features()
BTW: Schaust du mal nach WD:LT/wikilint #Bug bei Klemp? …??
LG --PerfektesChaos 19:35, 3. Okt. 2015 (CEST)
Über Special:ExpandTemplates und dem API-Modul dazu, kann man sich den Parse-Tree holen und versuchen, diesen zu interpretieren. Dann braucht man es nicht selber parsen. Ansonsten gibt es wohl einige Freie MediaWiki-Parser. Bei Parsoid weiß ich nicht, ob man auch an den ParseTree kommt und ob der einfacher ist.
Für die Zukunft könntest du noch WikiData in deinen Abgleich mit einbeziehen (nur falls deinerseits interesse besteht). Der Umherirrende 10:26, 31. Okt. 2015 (CET)

Probleme beim Sichten nach Versionsimport[Quelltext bearbeiten]

Nach einem Versionsimport kommt es häufig vor, dass ein Artikel als "noch nie gesichtet" gilt (taucht auf Spezial:Ungesichtete Seiten auf), aber nicht direkt gesichtet werden kann. Man kann dieses Problem zwar beheben, indem man zunächst auf "Sichtung entfernen" und dann auf "Sichten" klickt, jedoch bitte ich um eine allgemeine Fehlerbehebung.

Aktuelles Beispiel ist Kris Sakti. Falls er noch gesichtet wird, hier ein Screenshot. --FeddaHeiko 02:56, 11. Okt. 2015 (CEST)

Klingt nach T104524 (auch wenn das sich stark auf WikiBase bezieht). Bei Dateiwiederherstellungen gibt es ähnliche Probleme (T52506). Der Umherirrende 10:23, 31. Okt. 2015 (CET)

Bugs beim Responsive Design[Quelltext bearbeiten]

Hallo zusammen,

immer wieder fällt mir auf, dass es bei nicht maximierten, beispielsweise an den linken Rand gepackten Fenstern Probleme bei der Anpassung des Seitenlayouts (insbesondere in der Kopfzeile) und somit beim Responsive Design gibt. Ich vermute, dass das ein technisches Problem ist, das sämtliche Wikipedias umfasst und mit der Kernsoftware zu tun hat - ist das richtig bzw. wo kann ich wen auf diesen Bug aufmerksam machen? Vielen Dank! :)

--Gambuso (Diskussion) 21:15, 13. Okt. 2015 (CEST)

Falls du damit meinst, dass bei recht schmalem Bildschirmfenster die Tab-Reiter wie hier „Projektseite“ | „Diskussion“ | „Lesen“ | „Bearbeiten“ nach unten über die Überschrift klappen – das Problem ist leider gut bekannt; Meldungen nicht erforderlich. LG --PerfektesChaos 21:37, 13. Okt. 2015 (CEST)
Fehlermeldung: phab:T56919 --AKlapper (WMF) (Diskussion) 10:58, 14. Okt. 2015 (CEST)

Safari und Danken-Funktion[Quelltext bearbeiten]

Auf den Admin-Anfragen wurde angemerkt, das sich die Danken-Funktion im Safari nicht richtig funktioniert bezüglich des ausblenden und einblendens der Rückfrage.

Eventuell kann jemand mit Safari einen entsprechenden Task aufmachen, wo das kompetent beschrieben ist. Vielen Dank. Der Umherirrende 11:05, 14. Okt. 2015 (CEST)

"Aktueller" IE 9 macht auch Probleme. --arilou (Diskussion) 16:30, 14. Okt. 2015 (CEST)
Ein Fehlerbericht im Phabricator (unter dem Projekt "Thanks") ist willkommen! --AKlapper (WMF) (Diskussion) 20:33, 14. Okt. 2015 (CEST)
Schade, das keiner mit Safari da ist, der einen Task mit besserer Beschreibung eröffnen könnte. Jetzt T117309. Der Umherirrende 10:20, 31. Okt. 2015 (CET)

Halbtote Links auf gestis[Quelltext bearbeiten]

Mag sich dieses Problem mal jemand anschauen und eine Lösung finden?--Mabschaaf 09:21, 23. Okt. 2015 (CEST)

Die Fragestellung ist für diese Werkstatt etwas unübersichtlich.
Offenbar ist gemeint, dass es ein unterschiedliches Verhalten gäbe von
  1. http://gestis.itrust.de/nxt/gateway.dll/gestis_de/520010.xml?f=templates$fn=print.htm#1100
  2. http://gestis.itrust.de/nxt/gateway.dll?f=id$t=default.htm$vid=gestisdeu:sdbdeu$id=500019
Es kommen haufenweise Ressourcen und Cookies mit. Es kann gut sein, dass die eine URL einen erforderlichen Cookie oder ein Script liefert, wodurch sie gut funktioniert, während die andere URL nicht alles mitbringt und deshalb erstmal nicht den Inhalt anzeigt, aber nach Besuch der anderen URL alles hätte, insbesondere einen Cookie-Wert.
Wenn die eine nicht richtig funktioniert, aber die andere, dann nehmt halt die andere.
LG --PerfektesChaos 11:09, 23. Okt. 2015 (CEST)

Verlassen der mobilen Ansicht bei Wechsel in andere Sprachen[Quelltext bearbeiten]

Wenn ich in der Mobilansicht unten auf den Button In einer anderen Sprache lesen tippe und mir eine Sprache auswähle, lädt der Artikel in der anderssprachigen Wikipedia nicht in der mobilen Ansicht sondern in der klassischen Ansicht. Der Link führt auch zu lang.wikipedia.org/wiki/$1 und nicht zu lang.m.wikipedia.org/wiki/$1. Besonders auf kleinen Bildschirm ist die Normalansicht oft schwerer zu lesen und jedes mal von Hand ein m. in die URL zu schreiben ist zwar zielführend, aber nicht besonders komfortabel. -- Freddy2001 DISK 20:33, 27. Okt. 2015 (CET)

Bisher war es afaik so, dass das in einem jeweils für z.B. wikipedia.org (also sprachunabhängig) gültigen Cookie gespeichert wurde. Statt die URL umzuschreiben kannst du auch ganz unten auf "Mobile Ansicht" klicken. Eine richtige Lösung (z.B. wie bisher) wäre natürlich dennoch wünschenswert. --nenntmichruhigip (Diskussion) 21:48, 27. Okt. 2015 (CET)
Ich habe mal T117306 erstellt, weil ich kein anderen Bug gefunden habe. Der Umherirrende 09:56, 31. Okt. 2015 (CET)

API: Import aus anderer Wikipedia feststellen[Quelltext bearbeiten]

Gibt es eine Möglichkeit per API festzustellen, wann ein entsprechender Artikel importiert wurde, bzw. welche die Version in der Versionsgeschichte ist, die den Import darstellt? --Jobu0101 (Diskussion) 09:38, 31. Okt. 2015 (CET)

Du kannst das Import-Logbuch per API auslesen (list=logevents&letype=import). Es gibt aber keine Möglichkeiten die importierten Versionen festzustellen und die Import-Version in der Versionsgeschichte. Einzige Annahme für die Import-Version, es ist die Version mit dem ähnlichen Zeitstempel (muss nicht Sekundengenau sein) wie der Log-Eintrag. Der Umherirrende 09:45, 31. Okt. 2015 (CET)
Wenn man bei der Importversion einen Vergleich mit der vorherigen anstellt über die Wikipediasoftware, dann sagt sie, dass beide Versionen identisch seien. Das geht doch ohne Import gar nicht bei aufeinanderfolgenden Versionen, weil die Software sonst das Abspeichern als neue Version verweigern würde, oder? Vielleicht könnte das helfen. --Jobu0101 (Diskussion) 10:02, 31. Okt. 2015 (CET)

Skript zum farbig unterlegen auf Links zu Artikeln, die ein bestimmter Benutzer erstellt hat[Quelltext bearbeiten]

Hallo,

der ein oder andere hat ja vielleicht schon mitbekommen, dass im Moment viele Boxerartikel erstellt werden, die so gerade den RKs und Qualitätsstandards genügen, aber dann idR vor sich hingammeln. Der Benutzer ist nicht bereit, auf Ansprachen zu reagieren und ich und auch andere Benutzer ärgern mich/sich jedes Mal, wenn sie auf einen solchen Artikel stoßen. Ist es vielleicht möglich, dass ein JS-affiner Mensch ein Skript schreibt, welches Links auf Artikel, welche Benutzer XYZ erstellt hat, farbig unterlegt werden, ähnlich wie bei BKL-Links? Grüße --Der Buckesfelder  Disk.  bewerten  E-Mail 08:20, 26. Nov. 2015 (CET)

Ähnlich wie bei BKL geht es sicher nicht - dort hilft die Mediawiki-Software und gibt den Links eine Kennzeichnung, die dann nur noch sichtbar gemacht werden muss. Ein solches Script müsste sich irgendwo extern eine Liste der erstellten Seiten holen und dann jeden Link mit dieser Liste abgleichen. Wenn es dir um die Artikel geht und nicht um Links darauf, wieso nicht einfach diese Liste der erstellten Seiten durchgehen? Links auf relevante Personen sind fast immer sinnvoll, selbst wenn es den Artikel gar nicht gibt. --mfb (Diskussion) 11:46, 26. Nov. 2015 (CET)
Hilft dir evtl. diese Suche weiter? [12]? Da werden nur die neu von ihm erstellen Seiten gelistet. --Wassertraeger Fish icon grey.svg 12:19, 26. Nov. 2015 (CET)
Es geht nicht darum, dass Personen relevant sind. Es geht darum, wie Artikel eines gewissen Benutzers aussehen und diese möchte ich einfach nicht mehr ansehen. --Der Buckesfelder  Disk.  bewerten  E-Mail 12:48, 26. Nov. 2015 (CET)
Ach so, also exakt das Gegenteil der Suche die ich vorgeschlagen habe. Eine ignore-Funktion quasi. Ja, die möchte ich auch bei einigen haben. Ärgern Dich die Boxer denn so sehr? --Wassertraeger Fish icon grey.svg 12:57, 26. Nov. 2015 (CET)
Du könntest etwas analog zu Benutzer:Mfb/monobook.css anlegen (ganz unten), braucht dann eine lange Liste aller (~700) Artikel, die manuell aktualisiert werden muss, und wird vermutlich das Laden von Seiten merklich verlangsamen. Testobjekte: Luis Alberto Pérez (Boxer), Robbie Regan, Lee Haskins. --mfb (Diskussion) 13:24, 26. Nov. 2015 (CET)

@Buckesfelder:

  • Technisch möglich ist sowas in automatisiert.
    • Für einen erfahrenen Programmierer wäre es noch nicht mal schwer, sondern Zusammenbasteln von Routine-Elementen.
    • Ich fürchte allerdings, es gibt niemanden, der Zeit dafür hätte.
    • Allgemeinverwertbar wäre ein Werkzeug schon, wenn man es von vornherein offen für viele Anwendungsfälle hielte.
  • Ich kann nur Realisierungstipps geben:
    • Immer, wenn man auf eine typische Seite käme, etwa die Beobachtungsliste, wird per API das Sortiment von vorgegebenen Regeln abgefragt.
    • Vorgegebene Regeln können sein:
      • Benutzer X hat Seite erstellt.
        • 500 Antworten pro Abfrage; ggf. Kette von 500er Schüben.
      • Seite ist in Kategorie Y (das wäre analog der BKL-Falschschreibung).
      • Ich beobachte diese Seite.
      • Seite wurde in den letzten drei Tagen geändert.
      • Seite wurde seit drei Jahren nicht mehr geändert.
    • Jede Regel besteht aus einem vorgenannten Kriterium, einem Kurzbezeichner und CSS für diese Verlinkung.
    • Wenn alle API-Antworten beisammen sind, wird localStorage aktualisiert.
      • Das ist ein permanenter Textspeicher im Browser.
      • Damit sind für den Artikel sofort Ergebnisse da; und müssen nicht bei jedem Seitenaufbau erst geholt werden, was zu größerem Ruckler beim Seitenaufbau führt und Netzwerkkosten verursacht. (Cache-Prinzip; Besuch bestimmter Seiten aktualisiert den Cache. Sooo schnell kommen da auch keine Seiten dazu.)
      • Jeder Treffer erhält eine Zeile mit dem enkodierten Seitennamen, einem Leerzeichen und dem Bezeichner der Regel. In die allererste Zeile schreibt man den Zeitstempel der Aktualisierung.
    • Wenn irgendeine Seite (in bestimmten Namensräumen) aufgerufen wird, dann werden aus dem Inhaltsbereich alle Wikilinks analysiert.
      • Dabei wird der enkodierte Namensteil des Linkziels in der localStorage-Komponente mit vorangehendem Zeilenumbruch und nachgestelltem Leerzeichen gesucht.
      • Man könnte auch jedes Mal erst komplizierte JSON-Objkte parsen und aufbauen und dann darin Komponenten suchen. Zeichenkettensuche ist hier ausreichend und deutlich schneller.
      • Wenn es einen Treffer gab, kennt man den nachstehenden Kurzbezeichner und kann das diesem Bezeichner zugeordnete CSS dem Wikilink verpassen.
      • Man könnte auch aus dem Speicher eine gigantische CSS-Regel über womöglich Tausende von Seiten konstruieren und diese dann der kompletten Seite verpassen; aber das wäre voraussichtlich ineffizienter.
      • Zusätzlich zur CSS-Dekoration könnte man einem Kurzbezeichner auch aktive Funktionen zuordnen; etwa generierte weitere Verlinkungen, oder entlinken oder sonstwas.
  • OT: Du hattest kürzlich Datumsbedingungen aus dem XML für Internetquelle entfernt; hatte das den Grund, dass im vorhandenen Artikelbestand lauter unerwünschte Datumsangaben diese Bedingung auslösten, oder stürzte das Skript ab?

LG --PerfektesChaos 13:40, 26. Nov. 2015 (CET)

@PerfektesChaos: Danke für die ausführlichen Informationen. Leider kann ich das (noch) nicht, ab der Ehrgeiz hat mich gepackt und irgendwann habe ich das dann auch (hoffentlich umgesetzt).
Zur {{Internetquelle}}: Das Problem waren nicht die Altlasten. Die wandle ich ich eigentlich, sofern ich den Link bearbeite, in YY-MM-DD um. Vielmehr hatte der Vorlagenmeister Probleme mit neueingegebenen Daten in dem oben genannten Format. Ich konnte leider noch nicht herausfinden woran das liegt, hatte das aber noch vor. Doch durch nervende Stubs und vielen Diskussionen auf WP:VM, WP:QS usw. hatte ich einfach keine Lust und Reiz mehr. Deshalb war ich so egoistisch und habe die entsprechenden Zeilen einfach gelöscht. Falls du eine Idee hast, woran das liegen könnte, nur her damit. Grüße --Der Buckesfelder  Disk.  bewerten  E-Mail 13:07, 27. Nov. 2015 (CET)
@Skript-Idee:
  • Alle aufgelisteten Regeln sollten nicht nur auf Wikilinks vom momentanen Artikel aus gelten, sondern auch für die momentane Seite selbst. Da müsste dann im Seitenkopf ein Kasten angezeigt werden.
  • Eine weitere Regel könnte sein: Benutzer X hat innerhalb der letzten 50/100/500 Bearbeitungen (maximal 30/90/1000 Tage zurück) die Seite bearbeitet.
  • Ein Teil der Regeln eignet sich dazu, lokal zur Beschleunigung gespeichert zu werden (Seitenersteller, werden keine 10.000 sein; was beobachte ich? – Seiten in Kategorie/Unterkat); andere wie diese eben müssten live abgerufen werden.
  • Nicht nur Benutzer-Nicks, sondern auch IPv4-Ranges.
  • Bei hinreichender Flexibilität in Sachen Regeln würde ein solches Werkzeug in interessierten Kreisen durchaus Anklang finden.
@Vorlagenmeister:
  • Ich hatte dieses Vorlagenmeister vor einem Jahr geschrieben, damals erfolgreich getestet und seitdem alles vergessen. Ich werde mich, wenn ich mal einen Block konzentrierte Zeit habe, auf BETA an eine Rekonstruktion des von dir geschilderten Problems machen. Wohl eher Jahreswechsel.
LG --PerfektesChaos 13:29, 27. Nov. 2015 (CET)

Mobil aufgerufene Änderungen als besucht markieren[Quelltext bearbeiten]

Es scheint so, als dass Änderungen, welche von der mobilen Beobachtungsliste aufgerufen werden, in der Desktop-Ansicht danach immer noch in Fettschrift als unbesucht angezeigt werden. -- Freddy2001 DISK 19:08, 26. Nov. 2015 (CET)

Probleme bei der PDF- bzw. Buchherstellung[Quelltext bearbeiten]

Nur durch Zufall bin ich darauf gestoßen, dass „\color{Red}“ in der math-Umgebung das Rendering bei der PDF- bzw. Buchherstellung abstürzen lässt. Es gibt aber noch andere Codes, die ähnliches Unheil bewirken, so lassen sich die Artikel Huffman-Code und Regulärer Ausdruck nicht als PDF-downloaden. Gibt es jemanden der sich das erklären bzw. das ändern kann? Ich hatte die Frage auch hier gestellt, aber die Seite wird wohl nicht allzuoft frequentiert. Dank und Gruß von --Konrad Stein (Diskussion) 19:58, 7. Dez. 2015 (CET)

Hi Konrad, ein Fehlerbericht in https://phabricator.wikimedia.org/maniphest/task/create/?projects=ocg-pdf-renderer ist willkommen. --AKlapper (WMF) (Diskussion) 11:51, 8. Dez. 2015 (CET)

Liste im IE, FF[Quelltext bearbeiten]

Hallo zusammen, ich bin unsicher, ob ich hier richtig bin. Bitte also um Nachsicht. Frage: In Bundeshaushaltsplan (Deutschland) gibt es eine Liste, die mit "0" beginnt und das auch soll. Das tut sie aber nur im Firefox, nimmt man den IE beginnt sie mit "1". Das muss als an dem <li value="0"> liegen. Hat jemand eine Idee, woran es liegt? --He3nry Disk. 16:07, 18. Dez. 2015 (CET)

Am IE. Quelltextmäßig ist alles richtig gelaufen. Aber der IE kann das nicht (wobei der Vergleich ziemlich veraltet wirkt). Vorschlag: 1. nochmal explizit als solches festlegen, dann wird im IE nur die erste Zeile falsch angezeigt. --mfb (Diskussion) 18:05, 18. Dez. 2015 (CET)
Soweit so gut, nur haben wir nun im IE eine doppelte "1". Ich mag ich glauben, dass es für dieses IE-Problem keinen Workaround gibt. --He3nry Disk. 09:10, 19. Dez. 2015 (CET)

"Meist gesehen" Rubrik[Quelltext bearbeiten]

Ich fände eine "Meist gesehen"-Auflistung, wie auf der enwiki (TOP 25 Report) auch für die deutsche wiki nicht schlecht. Jedoch fänd ich es passender, wenn man es monatlich macht, nicht wöchentlich wie auf der englischsprachigen Version. Falls es schonmal diskutiert wurde, sorry, aber ich find hier irgendwie keine Suchfunktion. Was haltet ihr davon?

Nützliche Links:

Gruß, Rayukk (Diskussion) 18:54, 20. Dez. 2015 (CET)

Ist das nicht eher etwas für WP:VV oder WP:B/A? --Leyo 01:59, 21. Feb. 2016 (CET)

Einfügung eines geschützten Leerzeichens in fremde Benutzerbeiträge[Quelltext bearbeiten]

Bei meinem letzten Edit [13] wurde - neben einer Tippo-Korrektur ("m" > "n"), die ich selbst durchführte, und der Einfügung meines Diskussionsbeitrags - an zwei Stellen ein geschütztes Leerzeichen eingefügt. Das habe ich nicht veranlasst und es ist mir unangenehm (es wirft zum Beispiel ein seltsames Licht auf meinen Beitrag, als wolle ich den Beitrag eines anderen Benutzers highlighten oder so). Weiß jemand, wie das zustandegekommen ist? Womöglich liegt es an meinem Browser? Ich wäre dankbar für eine technische Hilfe hierzu. --Carolin 11:57, 6. Jan. 2016 (CET)

Siehe WP:?#Unbeabsichtigte Fehlkorrektur. --Leyo 12:36, 6. Jan. 2016 (CET)
Ich danke für diesen Hinweis. --Carolin 12:51, 6. Jan. 2016 (CET)
Stellungnahme:
  • Es gibt Benutzerskripte, die derartige Veränderungen vornehmen.
    • Bei Carolin sehe ich allerdings keinerlei derartige Skripte aktiviert; auch nicht global.
    • Greasmonkey und Add-Ons kann ich naturgemäß nicht analysieren.
    • Gadget-Aktvierung kann ich ebenfalls nicht sehen.
      • Mir ist dunkel in Erinnerung, dass wikEd sowas auch macht. (BK: diese Vermutung inzwischen auch auf FZW aufgekommen)
  • WSTM
    • WSTM wehrt sich mit Händen und Füßen, auf Diskussionsseiten eingesetzt zu werden.
    • WSTM macht in Artikeln automatisch eine derartige Ersetzung; jedoch durch das inhaltlich gleichbedeutende &#160; – somit lassen sich menschlich eingefügte &nbsp; sicher unterscheiden.
  • Zeichenkodierung
    • Es liegt in der Hoheit der MediaWiki-Software, aus technischen Gründen den byteweisen Code einer Seite in eine gleichbedeutende Form zu ändern.
    • So werden beim Speichern einer Seite seit langen Jahren alle Leerzeilen und Leerzeichen am Seitende eliminiert; statt dessen seit einigen Jahren wohl immer ein abschließendes Zeilenumbruch-Zeichen spätestens bei der Wiedergabe eines Seiteninhalts produziert.
    • Von den Zeichencodes unter 32 werden nur 8 und 10 vom Server abgespeichert.
    • Es wird bereits seit einigen Jahren diskutiert, die unsichtbaren oder von Leerzeichen ununterscheidbaren Zeichen zur Transparenz gegenüber den nachfolgenden Autoren als sichtbare HTML-Entities zu kodieren, wenn die Seite in der Datenbank abgespeichert wird; das beträfe weiterhin in Unicode undefinierte Zeichenkodierungen oder auch durch den Sanitizer als unerlaubt klassifizierte HTML-Konstrukte. Letztere werden bislang jedes Mal erst detektiert, wenn ein Wikitext als HTML dargestellt wird, und dann trotzdem nicht umgesetzt.
    • Es gibt keinen Anspruch der Autoren, in ihren Wikitexten verborgene unsichtbare und nullbreite Botschaften mit abzuspeichern, obwohl man ansonsten ein ganzes Whitespace-Programm einschmuggeln könnte.
    • Eine inhaltliche „Verfälschung“ liegt nicht vor, wenn statt einer intern-technischen Zeichenkodierung eine andere intern-technische Zeichenkodierung gespeichert wird.
    • Der gesamte Text wird vom Server derzeit ohnehin nicht so gespeichert, wie es die Benutzer wollten, sondern in das effizientere UTF-8 konvertiert und beim Abruf wieder dekodiert.
  • Im vorliegenden Fall liegt in der Benutzersignatur offenbar eine verborgene und innerhalb des <small> unübliche abweichende Zeichenkodierung vor.
    • Das sollte, wenn es denn beabsichtigt ist, dann schon besser durch offene Kodierung dargestellt werden.
  • Welche Software diese Umkodierung bei den fraglichen Seiten vorgenommen hat, weiß ich nicht.
    • Es wäre ohne weiteres möglich und legitim, dass Browser so handeln. Alerdings wüssten diese nicht, dass ein HTML-Entity ein angemessenes Encoding im Textfeld wäre.
VG --PerfektesChaos 13:23, 6. Jan. 2016 (CET)
PS: Nochmals zur absoluten Klarstellung hinsichtlich der Abschnittsüberschrift – du hast kein „geschütztes Leerzeichen in fremde Benutzerbeiträge eingefügt“. Das hatte da schon längst gestanden, und vom Signatar selbst geschrieben, bloß mit anderer technischer Kodierung. VG --PerfektesChaos 13:45, 6. Jan. 2016 (CET)
Danke für die Details. Als pragmatisches Vorgehen habe ich inzwischen wikEd deaktiviert (siehe auch meinen Kommentar hier), da ich vermute, dass das Problem dorther kam und ich wikEd sowieso nicht wirklich benötige. --Carolin 16:13, 6. Jan. 2016 (CET)
Oh, daran bin ich wohl ein wenig mitschuld. Also an dem versteckten Leerzeichen. Ist es wirklich so bedenklich? Ich könnte es aus dem Script nehmen (s. meiner Sig). User: Perhelion 22:12, 6. Jan. 2016 (CET)
Nun ja, zumindest für Diskussionsseiten sollte es m.E. wirklich besser ganz aus dem Skript genommen werden. Denn sonst sieht es ja so aus, als hätte man die anderen Benutzerbeiträge für den Diff-View hervorheben wollen. Könnte es für Artikelseiten optional geschaltet werden (so dass man selbst in den Benutzereinstellungen aussucht, ob man automatische Korrekturen will oder nicht, und wenn ja, welche)? --Carolin 22:19, 6. Jan. 2016 (CET)
  • Das eigentliche wikEd ist ein weltweit eingesetztes Benutzerskript auf der enWP, und dessen Entwickler wird sich erfahrungsgemäß nicht um Befindlichkeiten der deWP hinsichtlich der Verhinderung einer expliziten und für alle Autoren durchschaubaren Zeichenkodierung geschützter Leerzeichen scheren.
    • Es ist weltweit unerwünscht und führt auch in der deWP immer wieder zu unnötigen Anfragen in den Werkstätten, auf FZW, und zu endlosen Diskussionen, wenn durch Zeichenkodierungen, die für die (zumindest anderen) Benutzer nicht wahrnehmbare Geheimbotschaften transportieren, Layout-Probleme und die unerklärliche Verhinderung der Suche nach Zeichenketten sowie Skript-Aktivitäten wie diese ausgelöst werden – namentlich wenn sowas dann unbemerkt durch C&P sonstwohin verschleppt wird.
  • Was du allerdings ankreuzt, ist nicht jenes selbst, sondern das unter Wikipedia:Technik/Skin/Gadgets/wikEd beschriebene Skript, das die Situation vorsortiert und das wir ändern können.
    • Vorstellbar ist es, die Nummer des Namensraums zu analysieren und in Diskussionsseiten oder aber auf allem, was nicht Artikel ist, auf speziellen Benutzerwunsch hin wikEd nicht zu starten. Eine Projektseite als Forum wie diese hier ist jedoch keine Diskussionsseite, und es gibt auch keine Möglichkeit, effizient Projektseiten zu identifizieren, auf denen signierte Beiträge vorkommen.
    • Wenn ich mal Langeweile habe, kann ich dort eine derartige Benutzeroption einbauen, deren Aktivierung du dann aber wie dann dort beschrieben selbst vornehmen musst; am über viele Jahre hindurch angebotenen Standardverhalten wird sich nichts ändern.

VG --PerfektesChaos 01:57, 8. Jan. 2016 (CET)

Weil wir grad unsichtbare Zeichen am Wickel hatten:
VG --PerfektesChaos 15:48, 10. Jan. 2016 (CET)

Neues Benutzerskript: WikiBar[Quelltext bearbeiten]

Hallo liebe Mitstreiter,

ich habe seit dem vergangenen Jahr ein Benutzerskript in Erprobung, welches ich nun der Gemeinschaft zur Verfügung stellen möchte. Unter Benutzer:FNDE/Script/WikiBar ist (hoffentlich) ausreichend dokumentiert was es kann, welche Optionen zur Personalisierung zur Verfügung stehen und wie es eingebunden werden kann. Auf den Kern heruntergebrochen habe ich ein Tool entwickelt, welches dem Benutzer erlaubt, schnell und komfortabel durch die Wikipedia zu navigieren und mit frei definierbaren Shortcuts verschiedene Aktionen (z.B. Sichten) auszulösen. Ich würde mich freuen, wenn jemand mal einen Blick darauf werfen könnte und vllt. besonders kritische Fehler anmerkt. Ich bin kein professioneller Programmierer und bitte deshalb um Nachsicht bei besonders dummen Fehlern :-)  Viele Grüße --FNDE (Diskussion) 19:01, 28. Jan. 2016 (CET)

Ja, die Doku ist fein, und nach WP:HX hast du ja schon hingefunden.
  • Auf deiner Doku-Seite hättte ich gern noch einen auffindbaren Abschnitt zu den Codes mit Links zu allen beteiligten JS(/CSS?).
Hinsichtlich deiner Parameter rege ich die Wahl eines vielleicht noch etwas spezifischeren Bezeichners an
LG --PerfektesChaos 19:28, 28. Jan. 2016 (CET)

Abrufstatistik[Quelltext bearbeiten]

Beim Artikel VZLU TOM-8 zeigt die Abrufstatistik keine Abrufe an. Da der Artikel von mehren Autoren bearbeitet wurde, muss er auch abgerufen worden sein. Bei der Anlage des Artikels habe ich nichts anders gemacht als bei Artikeln, bei denen die Abrufstatistik funktioniert.--Urfin7 (Diskussion) 15:30, 31. Jan. 2016 (CET)

Die letzten Tage scheinen generell zu fehlen, siehe z. B. hier - normalerweise 200 Aufrufe pro Tag, aber für die letzten Tage zeigt die Statistik 0 an. --mfb (Diskussion) 16:04, 31. Jan. 2016 (CET)
Und hier bricht sie mit dem 20.01. ab.--Urfin7 (Diskussion) 17:02, 31. Jan. 2016 (CET)
Es gibt genau eine Person, die diese Abrufstatistik reparieren kann, und das ist en:User:Henrik. Der liest hier aber bestimmt nicht mit. --Schnark 09:49, 1. Feb. 2016 (CET)
Macht aber nichts, weil der Fehler dort auch schon merfach gemeldet wurde.--Urfin7 (Diskussion) 21:43, 1. Feb. 2016 (CET)

Automatische Einkategorisierung[Quelltext bearbeiten]

Hallo zusammen, ich weiß nun nicht, ob ich hier richtig bin, versuche es aber trotzdem mal mit meinem Problemchen, da ich vermute, es hat hat mit irgend einem Formatierungs-Automatismus zu tun. Also: Ich habe für das Portal:Heidelberg, wie es sie für etliche andere Portale auch gibt, eine eigene Kategorie:Portal:Heidelberg angelegt, um die ganzen eingebundenen Unterseiten zu sammeln. Klappt ganz gut, nur: wenn ich die Seite Portal:Heidelberg/Fehlende Artikel einkategorisiere, dann taucht auf anderen Seiten die Portalkategorie Heidelberg als Kat auf, ohne daß ich dort eine Änderung vorgenommen hätte und ohne daß diesen Seiten einen direkten Bezug zum Portal hätten. Konkret sind dies die Seiten Portal:Städte/Artikelwünsche und Benutzer:SDB/Portal:Städte. Ähnliches Problem auch bei den Bilderwünschen. Hat jemand eine Idee, woran das liegt, und was dagegen zu tun wäre? Liebe Grüße aus der Kurpfalz von -- Kallewirsch (Ugh, Ugh!) (Iiek?) 02:59, 5. Feb. 2016 (CET)

Die Seite Portal:Heidelberg/Fehlende Artikel wird auf Portal:Städte/Artikelwünsche und Benutzer:SDB/Portal:Städte eingebunden, sodass die Kategorie übernommen wurde. Verhindert werden kann das mit einem <noinclude>, das ich jetzt ergänzt habe. --Schnark 09:37, 5. Feb. 2016 (CET)
Super. Herzlichen Dank und ein schönes Wochenende. -- Kallewirsch (Ugh, Ugh!) (Iiek?) 10:20, 5. Feb. 2016 (CET)

Abschnitte, API[Quelltext bearbeiten]

Hallo lieber Techniker! Wisst ihr da weiter? --Jobu0101 (Diskussion) 23:05, 14. Feb. 2016 (CET)

Hilfe bei Toolanpassung[Quelltext bearbeiten]

Das Datei-Werkzeug macht, wenn man als Admin im Automatikmodus eine Datei als commonsfähig markiert automatisch einen Eintrag in Wikipedia:Commons-Transfer per Bot/Anfragen. Da PerfektesChaos leider keine Zeit hat und meine JS-Kenntnisse sehr schlecht sind, bitte ich hier um Hilfe, wie diese Eintragungen deaktiviert werden könnte. Die Lösung muss nicht zwangsläufig total „sauber“ (unnötiger Code verbleibt im Script) sein, sondern einfach nebenwirkungsfrei.
Das Lemma der betroffenen Seite wird in diesen Zeilen definiert:

      FAdm.trans.bot.pageName      =  "Wikipedia:"
                                      + "Commons-Transfer per Bot"
                                      + "/Anfragen";

Folgende Workaround-Möglichkeiten sehe ich:

  1. Ganz löschen (potentielle Probleme: Hauptseite wird editiert; Fehler wegen undefinierter Variable)
  2. Alles nach dem = durch ""; ersetzen (potentielles Problem: Hauptseite wird editiert)
  3. Alles nach dem = durch "Spezial:Test"; ersetzen (unschön, aber sicher, da Spezialseiten nicht bearbeitet werden können)

Seht ihr eine Chance, dass eine der Möglichkeiten klappen könnte? --Leyo 03:10, 18. Feb. 2016 (CET)

Oder anders gefragt: Sind die Optionen 1 und 2 zu gefährlich? --Leyo 14:28, 8. Apr. 2016 (CEST)

Minervas Hintergrund[Quelltext bearbeiten]

Ich hab versucht über meine persönliche minerva.css mit body { color: #eee; background-color: #555;} den Hintergrund und die Schriftfarbe der mobilen Version zu ändern (ist für mich persönlich − vor allem Nachts − angenehmer):

Bei der Schriftfarbe hat das auch gleich geklappt, allerdings ist der Hintergrund zwar während dem Laden in der richtigen Farbe, wenn die Seite komplett geladen ist, ist sie jedoch trotzdem wieder weiß. Kann mir jemand sagen, warum das nicht funktioniert und wie man das ändern kann? Liebe Grüße, KPFC💬 22:23, 3. Mär. 2016 (CET)

Die Farbe wird von mehreren Elementen darunter wieder überschrieben. Im konkreten Fall könntest du analog zu "body" auch "pre" die Hintergrundfarbe geben, das sollte zumindest bei vielen Objekten helfen. --mfb (Diskussion) 00:21, 4. Mär. 2016 (CET)
Danke :) Funktioniert jetzt größtenteils. Nur Tabellen muss ich noch ändern. Liebe Grüße, KPFC💬 17:58, 6. Mär. 2016 (CET)

Benutzerskript zum SLA stellen[Quelltext bearbeiten]

Kann mir jemand ein Benutzerskript schreiben, welches ich zusätzlich zum normalen SLA-Skript nutzen kann, und mir {{Löschen|1= ''Abgearbeiteter Bot-Hinweis'' --~~~~}} als vorbelegten Feld-Code anzeigt. Das würde mir viel Tipparbeit bei den SLAs einsparen. Danke schonmal im Voraus. Viele Grüße --Der Buckesfelder  Disk.  bewerten  E-Mail 10:03, 8. Mär. 2016 (CET)

Mach einfach die Seite leer, speicher sie ab, und gut ist.
Wir haben mehrere 10.000 leere Artikeldisk, die zu 99 % auf Weblink-Bots zurückgehen.
  • Die alle händisch per Extra-SLA abzuarbeiten ist einfach nur gaga.
Lesetipp: BD:PerfektesChaos #Diskussionsseiten einzig mit Bothinweisen
Irgendwann mal kann jemand alle leeren Artikeldisk mit einem sinnvollen Automatismus löschen; vorgeschrieben ist allerdings per MB eine vorherige menschliche Sichtkontrolle, wenn an einen Bot oder Skript delegiert wird.
LG --PerfektesChaos 10:18, 8. Mär. 2016 (CET)
Dann mache ich das so und verweise im Zweifel einfach auf deine Disk. Danke! Grüße --Der Buckesfelder  Disk.  bewerten  E-Mail 10:32, 8. Mär. 2016 (CET)
Einspruch: Ich würde die 99 % mal eher auf 50 % runterkorrigieren, zumindest hat das meine Stichprobe ergeben. Daher ist ein SLA nach Abarbeitung der Bothinweise hilfreich. Yellowcard (D.) 18:36, 10. Mär. 2016 (CET)
@Der Buckesfelder: Also ich benutze für so etwas meta:User:Hoo man/Scripts/Tagger, das geht sehr fix, und ist praktisch. Sollte schneller gehen als Seite leeren (zwei klicks im Skript auf die Buttons). Viele Grüße, Luke081515 18:39, 10. Mär. 2016 (CET)
@Luke081515: Ich habe das Skript jetzt über meine global.js eingebunden, aber ich sehe weder unter Vector noch unter Monobook irgendwo einen Button oder ähnliches, wo ich drauf klicken kann. Grüße --Der Buckesfelder  Disk.  bewerten  E-Mail 11:14, 11. Mär. 2016 (CET)
Wenn du es richtig konfigurierst (ggf mal schauen, änderst du die Auswahlmöglichkeiten). Der Link zum aktivieren ist rechts oben unter dem Link für "Tag". (Nicht im Bearbeitenmodus, aber im normalen Lesemodus.) Viele Grüße, Luke081515 11:50, 11. Mär. 2016 (CET)
Ah da. :) War durch ein anderes Skript verdeckt. Danke für den Hinweis. Mal sehen, ob ich es mir irgendwie umschreiben kann, dass es an passender Stelle erscheint, also in irgendeinem Menü, egal ob links oder oben. --Der Buckesfelder  Disk.  bewerten  E-Mail 13:59, 11. Mär. 2016 (CET)
  • Der kürzeste technisch sinnvolle Text auf einer Artikeldisk wäre
    #redirect[[Talk:X]] und hätte 19 Zeichen.
    • Etwas mit weniger als 10 Bytes kann kaum ein inhaltlich voranbringender Text sein.
    • {{BLP}} mit 7 Bytes ist wohl die untere Grenze.
  • Es gibt momentan rund 14.300 Artikeldisks mit Null oder wenig mehr Bytes.
  • Es ist völlig wurscht, ob diese wegen erledigtem Bot-Hinweis oder Vandalismus Null Byte groß sind; alle etwa 14.000 sind zu löschen und wieder in den Status eines redlinks zu bringen.
  • Problematisch ist, dass im Einzelfall ein nicht-vandalierender Nicht-Tastaturtest, der auch nicht nach WP:DS wegen Bedeutungslosigkeit zu entfernen wäre, in der VG auftreten könnte und böswillig verborgen worden sein mag. Davon muss sich der löschende Admin aber ohnehin beim Abarbeiten jedes einzelnen individuellen SLA persönlich überzeugen.
  • Bereits 2014 gab es 9.000 absolut löschwürdige ANR-DS.
  • Seit Jahren sind die Admins völlig überfordert damit, die Unmengen inhaltsfreier Artikeldisks effizient und massenhaft zu löschen. 15.000 einzelne SLA zu stellen und damit die SLA-Kat zu fluten wäre auch keine Lösung; die gesamte erwin85/shortpages ist ein einziger SLA.

VG --PerfektesChaos 17:11, 11. Mär. 2016 (CET)

Was ist da mit alten Diskbeiträgen, wo die Seite geleert wurde? Kommt z.B. im Astronomiebereich oft vor. Viele Grüße, Luke081515 17:20, 11. Mär. 2016 (CET)
Wenn die Disk völlig oder bis auf einen nicht bedeutungstragenden Rest geleert wurde und in der VG nichts böswillig entferntes steht (das wäre per revert wieder offensichtlich zu machen) und in der VG nichts für kommende Generationen erhaltenswürdiges steht (also nur zurückgesetzter Vandalismus oder Vandalismus-nahes inhaltsfreies Gebrabbel oder trivale Hinweise [Da ist ein Schreibfehler, in Strn fehlt ein „e“] oder aber nur Bot-Hinweise), dann ist die Disk so oder so zu löschen und zum redlink zu machen. Andernfalls ist Sinnvolles sichtbar zu machen; und sei es ein Archiv-Verweis-Baustein. Wenn es erledigte erhaltenswürdige Diskussionen gibt, gehören sie ggf. auf eine Archiv-Unterseite – wie sollte man die sonst jemals auf einer leeren Seite vermuten?
VG --PerfektesChaos 18:27, 11. Mär. 2016 (CET)

Eine Einstellung für alle Acc (Global Settings)[Quelltext bearbeiten]

Hallo, hat zufällig jemand ein Code-Snippet für eine solche Funktion? Z.B. Die Sprach-Einstellung (oder Visual-Editor aus) für alle Benutzerkonten zu setzen und zu speichern? User: Perhelion 22:29, 17. Mär. 2016 (CET)

  • Ich hatte mal ein Konzept für ein solches Gadget, bin aber aus Zeitmangel nicht dazu gekommen.
  • Du kannst:
    1. Benutzer:PerfektesChaos/js/preferencesGadgetOptions #Installation laden.
    2. In die Callback-Funktion schreibst du rein, dass gemäß WP:JS/V #Benutzerkonfiguration mw.user.options.get("language") mit de verglichen werden solle, usw.
    3. Wenn das nicht den gewünschten Wert hat, kannst du preferencesGadgetOptions.string() zum Setzen benutzen.
    4. Was für Zeichenketten du bei logischen und numerischen Einstellungen verwenden müsstest, darfst du selbst herausfinden. Keine Ahnung; wenn du schlauer geworden bist, schreib es auf. "" neutralisiert vermutlich.
    5. Die ganze Installations-Aktion hüllst du in eine Abfrage auf wgNamespaceNumber (===2) und wgTitle (dein Nick), so dass es nicht auf jeder, sondern nur auf deiner Benutzerseite gestartet wird. Damit kannst du einmalig initialisieren und gelegentlich auch spätere Veränderungen propagieren.
    6. Für andere Benutzer kannst du eine Trennung in Programm und Daten vornehmen und ein konfigurierbares Objekt mit Eigenschaftsnamen und Sollwerten an ein neues Gadget übergeben, das dann die Analyse und Zuweisung für beliebige Eigenschaften ausführt.
Viel Spaß --PerfektesChaos 12:14, 18. Mär. 2016 (CET)
Wow* danke, da war ich wohl sehr naiv mit Snippet (deswegen habe ich jetzt auch nicht direkt nach einem Script gesucht).●^_^● Ich teste mal morgen (wenn ich's schaffe). PS: Spontan habe ich jetzt nur einen Typo im Installtions-Code bemerkt, ein ] zu viel (die jshint tatsächlich nicht muckiert). User: Perhelion 15:15, 18. Mär. 2016 (CET)
  • Eiwei; letzteres ist ja peinlich und noch von irgendwas übriggeblieben. Natürlich veröffentliche ich jshint-geprüft, verwende selbst den angegebenen Code aber niemals.
  • Du kannst auch in der enWP gucken, vielleicht hat da schon jemand was.
  • Vielleicht will oder muss man mal zu Testzwecken eine Einstellung ändern; da wäre es fies, wenn die beim Aufbau jeder beliebigen Seite sofort zurückgesetzt würde.
  • Ein MW-Projekt zu sowas scheiterte daran, dass es absolut nicht wünschenswert wäre, auf jedem SUL-Wiki identische Konfigurationen für alles zu haben; Heimatwikis sind anders konfiguriert als Meta oder MW oder testwiki oder irgendein zufällig mal besuchtes Wiktionary. Also kann das nur für bestimmte Eigenschaften gelten, und ggf. braucht man zu jeder Eigenschaft noch eine Ausnahmeliste mit DB-Namen, wo das ignoriert werden soll.
LG --PerfektesChaos 15:48, 18. Mär. 2016 (CET)
Ein Button "diese Einstellung global übernehmen" würde schon viel helfen. Wer Ausnahmen will, kann diese danach einstellen oder den Knopf nicht nutzen. Besser noch: "diese Einstellung global übernehmen, sofern eine Einstellung nicht vom lokalen Standardwert abweicht". Wäre sicher einfach einzubauen und würde so viel helfen... --mfb (Diskussion) 22:50, 18. Mär. 2016 (CET)
  • Das schreibst du so locker-flockig dahin; aber die Konsequenzen wären nicht trivial, und deshalb wurden diese Vorschläge bislang alle abgelehnt.
  • Nehmen wir mal an, es gäbe so eine globale Preferences-Seite. Alles, was dort als Vorgabe markiert ist, solle sich so auf die lokalen Wikis auswirken. Das kann auf eine von drei Arten geschehen:
    • Die globale Einstellung hat den unbedingt verpfichtenden Wert.
      • Die lokale Einstellung für diese Option ist dann grau, festgelegt. Kein lokales Wiki kann sie ändern.
      • Man will aber in seinem Heimatwiki und einigen häufig besuchten Arbeitswikis (deWP, Commons, Wikidata, deWikisource) abweichende Einstellungen haben; für Beo und Echo und alles. Fremde Wikis sollen Echo per Mail, das Heimatwiki soll niemals mailen. Manches hängt von Sprache oder Schrift ab.
      • Gadgets sind sowieso ein lokales individuelles Angebot.
      • Jedoch soll in nur selten und zufällig besuchten Wikis das globale Schema gelten.
      • Maximal für die Sprache der Benutzeroberfläche würde eine solche globale Vorgabe sinnvoll sein. Die kann man dann aber nirgendwo noch in die lokale Sprache ändern, um sich mit jemand auszutauschen, wie bestimmte Menüfelder heißen.
    • Die globale Einstellung kann lokal überschrieben werden.
      • Dann haben die Checkboxen keine zweiwertige Logik ja/nein mehr, sondern eine dreiwertige:
        1. Lokal definitiv JA
        2. Lokal definitiv NEIN
        3. Verwende den momentanen Wert von GLOBAL (Vorgabe).
      • Statt einer Checkbox mit Häkchen muss dann eine Optionsliste mit den drei möglichen Werten angeboten werden.
      • Bei Zeichenketten wie der Sprachauswahl wird es noch komplizierter.
        • Wenn ich lokal aus irgendeinem Grund de-CH eingestellt habe und eine Stunde später klicke ich global auf de für alle; soll dann auch mein de-CH umgeschaltet werden, oder soll meine lokale Auswahl bleiben?
        • Wenn ich nach der globalen Vorgabe später lokal setze, soll aber die lokale Auswahl bis auf Weiteres gelten.
    • Die globale Einstellung gibt nur für alle Wikis, auf denen ich schon mal war, den Momentanwert vor; setzt ihn jetzt einmalig unbedingt auf diesen Wert zurück.
      • Dann schrottet es meine vier Arbeitswikis.
      • Wenn ich noch nie auf diesem Wiki gewesen bin, dann soll statt der MW-Vorgabe meine globale Einstellung die Vorgabe sein. Okay, wäre nett.
  • Resultat der Beratungen war, dass es kaum Einstellungen gibt, von der Oberflächensprache abgesehen, für die man solche globalen Einstellungen problemlos auf alle lokalen Wikis übertragen kann, oder die Standardeinstellungen von MW treffen es sowieso und man braucht lokal kaum was zu verstellen.
    • Das resultierende Verhalten wäre kryptisch, konfus und unflexibel.
    • Kaum jemand würde ein solches Feature benutzen wollen, mit dem man sich die lokalen Konfigurationen unvorhersagbar wieder zerschießt, und breiten Bedarf gibt es auch nicht.
    • Lohnt den Aufwand nicht.
VG --PerfektesChaos 11:33, 24. Mär. 2016 (CET)
Was du da beschreibst, wäre alles viel komplizierter als die beiden von mir beschriebenen Optionen, die sehr viel helfen würden. Es ist keine globale Einstellung nötig, eine globale Seite die lokale Einstellungen ändern kann (wie oben beschrieben) wäre völlig ausreichend. --mfb (Diskussion) 20:48, 24. Mär. 2016 (CET)

interaktiver?[Quelltext bearbeiten]

Hallo, ein kurzer Hinweis dass das Reading-Team der Wikimedia Foundation sich momentan Rückmeldungen wünscht, um zu erkunden wie man Wikipedia interaktiver machen könnte. Bitte schaut Euch die Seite an um neue Ideen hinzuzufügen (gerne auch in deutscher Sprache) oder bestehende Ideen zu kommentieren. Danke! and thanks for Andre for translating this text for me.--Melamrawy (WMF) (Diskussion) 11:15, 23. Mär. 2016 (CET)

Nutzung der Vorlage:Bilderwunsch[Quelltext bearbeiten]

war: Abschnitt für Fragen aus dem "Publikum" :) Habe ich das richtig verstanden, dass ein Bilderwunsch auf einer Seite mit Koordinaten ausreicht (Text egal)? –Be..anyone (talk) 14:12, 8. Apr. 2016 (CEST)

@Be..anyone: Hier gibt's nur Flo :-)  und der versteht die Frage nicht --Flominator 14:18, 8. Apr. 2016 (CEST)
Flow ist das, was vielleicht mal Diskussionsseiten ::: Gefummel ablöst, nach dem beendetem Liquid Threads Versuch, kein persönlicher Angriff des WMF gegen Dich. :-) Vergessene Signaturen gibt's bei Flow jedenfalls nicht. –Be..anyone (talk) 14:52, 8. Apr. 2016 (CEST)
@Be..anyone: Meinst du so hier? {{Bilderwunsch|Koordinaten|Breitengrad=51/18/59/N|Längengrad=09/23/34/E|ISO-Region=DE-HE|Benutzer=~~~}} → diese Vorlage erstellt einen Bilderwunsch ohne Kommentar, mit Koordinaten. --FNDE (Diskussion) 14:31, 8. Apr. 2016 (CEST)
Nein, ich habe zufällig vor ein paar Stunden die {{Bilderwunsch}}-Doku gelesen, und dann angenommen, dass das einfach so geht. –Be..anyone (talk) 14:47, 8. Apr. 2016 (CEST)
@Be..anyone: Wenn das Bild an den Koordinaten von Akademischer Verein Motiv Berlin ( 52° 30′ 42″ N, 13° 18′ 54″ O) aufgenommen werden soll, kannst du einfach {{Bilderwunsch|hier|Leibnizstraße 14|Benutzer=~~~}} schreiben. --Flominator 14:57, 8. Apr. 2016 (CEST)
Aha, das hatte ich nicht spontan kapiert, egal oder hier ist hier nicht egal, Danke, korrigiert. –Be..anyone (talk) 15:11, 8. Apr. 2016 (CEST)
@Be..anyone: Genau. Hast du eine Idee, wie man unter Vorlage:Bilderwunsch/Doku besser beschreiben kann? --Flominator 15:32, 8. Apr. 2016 (CEST)
Vorschlag zur Besichtigung, vielleicht ist es jetzt offensichtlicher. –Be..anyone (talk) 16:08, 8. Apr. 2016 (CEST)

Benutzer:Matthiasb/monobook.js[Quelltext bearbeiten]

Mir ist nicht ganz klar, wie ich da addOnloadHook( function() ersetzen muß.

Ich denke, daß ich Lupins "Popups" ganz rauswerfen kann, weil ich das eh als Helferlein aktiviert habe? --Matthiasb – Blue ribbon.svg (CallMyCenter) 11:15, 2. Apr. 2016 (CEST)

  1. Die Zeichenkette addOnloadHook ist hier durch $ zu ersetzen.
  2. Die beiden Funktionen mit document.write sind seit längerer Zeit wirkungslos und können eliminiert werden.
  3. Die Zeichenkette addPortletLink ist zu ersetzen durch mw.util.addPortletLink.
    • Mehr Infos
    • Korrekterweise müsste auch noch mittels mw.loader.using sichergestelllt werden, dass diese Bibliothek bereits geladen wurde; siehe Code-Beispiel unter WP:GUI #addPortletLink().
VG --PerfektesChaos 11:41, 2. Apr. 2016 (CEST)
Gibt es eigentlich eine elegantere Möglichkeit, den Purge-Knopf zurück zu kriegen? Oder muß ich
// [[Benutzer:ParaDox/monobook/purge.js]]
document.write('<SCRIPT SRC="https://de.wikipedia.org/w/index.php?title='
+ 'Benutzer:ParaDox/monobook/purge.js&action=raw&ctype=text/javascript&dontcountme=s">'
+ '<\/SCRIPT>');

anpassen, ich nehme an etwa so:

mw.loader.load('//de.wikipedia.org/w/index.php?title=Benutzer:ParaDox/monobook/purge.js&action=raw&ctype=text/javascript&dontcountme=s');
Dann besteht ja noch das Problem, daß Paradox offenbar inaktiv ist und man wohl einen Admin überreden müßte, dessen Skript auf den neuesten Stand zu bringen. --Matthiasb – Blue ribbon.svg (CallMyCenter) 17:57, 3. Apr. 2016 (CEST)
ich hab den Benutzer:T§/PurgePortlet. --Wetterwolke (Diskussion) 18:19, 3. Apr. 2016 (CEST)
PS: In Bezug auf 3.), muß mw.loader.using vor die Zeile beginnend mit mw.util.addPortletLink oder vor die erste geschweifte öffnende Klammer? --Matthiasb – Blue ribbon.svg (CallMyCenter) 18:23, 3. Apr. 2016 (CEST)
Nach BK, die erste.
Was document.write angeht, so nimmst du in etwa richtig an; diese Funktion ist ansonsten wirkungslos gemacht worden (wobei in der URL auch noch ein obsoletes dontcountme=s vorkommt).
Was das Skript von 2008 angeht, so würde ich es als Totalschaden einstufen; mit rumdoktern ist es ob fundamentaler Rückstände in der Browser-Technologie nicht getan.
VG --PerfektesChaos 18:31, 3. Apr. 2016 (CEST)
Nach BK, die zweite, zum PS:
mw.loader.using( [ 'mediawiki.util' ],
                 function () {
	mw.util.addPortletLink('p-personal', "https://de.wikinews.org/wiki/Hauptseite",  'wikinews', 'pt-wikinews', 'wikinews', '', 'pt-userpage');
                 } );
Ist double-safe; erfahrungsgemäß ist zu diesem Zeitpunkt die Bibliothek util schon im Browser einsatzbereit; aber wäre vorstellbar, dass irgendwann mal nicht, und dann wird das halt abgewartet.
VG --PerfektesChaos 18:41, 3. Apr. 2016 (CEST)
Danke bis dahin. Jetzt habe ich aber das Problem, daß seit dieser Änderung das Auslösen der Eingabe im Suchfeld kein neues Browsertab mehr öffnet. --Matthiasb – Blue ribbon.svg (CallMyCenter) 19:20, 5. Apr. 2016 (CEST)
Bei deiner Änderung fehlte noch ein "});". Ich würde es so schreiben:
// systemweite Default-Optionen aus [[MediaWiki:Monobook.js]]
 mw.user.options.set( 'NavigationBarShowDefault', 10 );     // Navi-Leisten: alle einklappen == 0; alle ausklappen == 15 (z.B.)

$( function()
 {
  $("#searchform").attr("target", "_blank");
  $("div.suggestions").bind("DOMSubtreeModified", function(){$("a.mw-searchSuggest-link").click( function (e) { e.preventDefault(); });}); //search in  new page
  mw.loader.using( [ 'mediawiki.util'], function() {
   mw.util.addPortletLink('p-personal', "https://de.wikinews.org/wiki/Hauptseite", 'wikinews', 'pt-wikinews', 'wikinews', '', '#pt-userpage');
  });
 });

// IW-Entfernung
mw.loader.load('//www.wikidata.org/w/index.php?title=User:Yair_rand/checksitelinks.js&action=raw&ctype=text/javascript');
Der Umherirrende 22:39, 8. Apr. 2016 (CEST)

Nekrolog-Kopiervorlage[Quelltext bearbeiten]

Hallo zusammen, hier hatte APPER ein Toolserver-Tool entwickelt, das Kopiervorlagen für Nekrolog-Zeilen erzeugt. Inzwischen leitet die Toolserver-URL auf https://tools.wmflabs.org/persondata/misc/nekro.php?article=9057728 weiter, meldet aber dann 404. APPER reagierte nicht per E-Mal, daher die Frage an alle: Liegt das Skript vielleicht irgendwo anders? Fehlt noch etwas an der Migration? Gibt es eine Alternative? Danke und Gruß, --Flominator 13:00, 2. Apr. 2016 (CEST)

Alternativfrage: Fühlt sich jemand in der Lage, aus einer Artikel-ID PD auszulesen und daraus diese Zeile zu erzeugen?

| [[Todestag ohne Jahr]] || [[Lemma]] || Kurzbeschreibung || Alter 

Gruß, --Flominator 12:33, 31. Mai 2016 (CEST)

Verwandte Seiten[Quelltext bearbeiten]

Es gibt seit einiger Zeit die Funktion Verwandte Seiten bei der man in angemeldeten Zustand unter seinem neu angelegten Artikel Hinweise auf drei verwandte Artikel erhält. Gefällt mir an sich ganz gut, aber zuweilen wird wohl danebengegriffen. Etwa bei meinem Artikel Rosemarie Fiedler-Winter mit dem Foto eines jüdischen Schriftstellers, bei dem sich unterhalb des Artikels als verwandter Artikel der Antisemit Rudolf Heß befindet. Gibt es die Möglichkeit, sowas zu ändern - ohne die ganze Funktion zu entfernen? MoSchle (Diskussion) 20:19, 4. Apr. 2016 (CEST)

Werden die Vorschläge anhand der Kategorien gemacht? --FNDE (Diskussion) 23:06, 5. Apr. 2016 (CEST)
Siehe zum Hintergrund der Funktion dieses Meinungsbild in Vorbereitung: Wikipedia:Meinungsbilder/Mehr erfahren (Unterstützer gesucht!) - und die Links, die sich dort finden. Soviel ich weiss, ist die Funktion immer noch ein Beta-Feature und muss bewusst eingeschaltet werden, ist auch für angemeldete Benutzer noch nicht Standard. Man kann die Auswahl in einzelnen Artikeln anpassen, indem eine Zeile in diesem Stil eingefügt wird: {{#related:Neue Seite 1}}{{#related:Neue Seite 2}}{{#related:Neue Seite 3}} Gestumblindi 23:50, 5. Apr. 2016 (CEST)
Vielen Dank für die ausführliche Erklärung! Bei den Kategorien der beiden Artikel habe ich als Übereinstimmung Deutscher gefunden, im Artikel Zweiter Weltkrieg. Das dritte Bild hieß Landsberg/ Lech und kam bei Fiedler-Winter als Verlagsort eines Buches von ihr vor. MoSchle (Diskussion) 18:27, 6. Apr. 2016 (CEST)

[[User:[Niemand]|[Niemand]]] dankte dir ... (Benachrichtigung zum 'Danke'-Button)[Quelltext bearbeiten]

Hallo Technik-Team,

ich habe eine Anfrage zu einem anderen MediaWiki-Wiki, welches aber mit der WP in Beziehung steht - konkret ist es das '''Regiowiki AT''' (http://regiowiki.at/).

Es geht um die Funktionalität vom 'Danke'-Button in der Versionsgeschichte von Artikeln. Der Button funktioniert scheinbar korrekt, aber die Anzeige der Benachrichtigung beim Empfänger beginnt leider immer mit dem offensichtlich eigentlich als Benutzer-Link vorgesehenem Text [[User:[Niemand]|[Niemand]]] (direkt vor: 'dankte dir für deine Bearbeitung auf ...'). Diese eigenartige Form der Benachrichtigung tritt bei allen Benutzern im Regiowiki AT auf, sowohl unabhängig ob sie selbst Danken oder Bedankungen von Anderen erhalten, als auch scheinbar unabhängig vom die Bedankung betreffenden Artikel.

Zu diesem Thema gibt es bereits eine ältere, aber leider für mich praktisch nicht wirklich hilfreiche, kurze Anfrage vom Betreiber vom Regiowiki AT (Karl Gruber) selbst und bereits mit einer kurzen Antwort dazu unter 'Wikipedia:Fragen zur Wikipedia' (siehe Danke-Button von Juni 2015) - beides hier im Vollzitat (nur ohne Links):

Danke-Button

Eine Frage zu einem anderen Wiki: Woran kann das liegen, wenn ich als Danke ein [[User:[Niemand]|[Niemand]]] dankte dir für deine Bearbeitung statt dem Usernamen erhalte. Das Erwähnen funktioniert einwandfrei. (Egal von welchem Benutzer) --danke im Voraus K@rl 11:03, 15. Jun. 2015 (CEST)

Wenn dun auf einer Seite erwähnt wurdest, die später gelöscht wurde, sehen die Benachrichtigungen ähnlich aus. Eventuell etwas mit Renameuser oder Usermerge. --MGChecker – (📞| 📝| ) – HDR 17:06, 17. Jun. 2015 (CEST)

In dem diese eigenartigen 'Danke'-Benachrichtigungen betreffenden 'Regiowiki AT' wird die MW-Software noch in der Version 1.23.6 eingesetzt (Angabe der Versions-Spezialseite).

Ich bitte daher um ganz konkrete Angaben zu den möglichen Gründen der Entstehung dieses Fehlers in den Benachrichtigungen. Insbesondere um den Hinweis auf alle konkreten PHP-Dateien oder Konfigurationsdateien, die an der Erstellung dieser Benachrichtigung beteiligt sind oder sein könnten, inklusive den Ablaufdetails des gesamten Vorgangs dazu. Vielen Dank, schon im Voraus!

-- Gruß, Sonne7 Disk!  12:04, 9. Apr. 2016 (CEST)

Hört sich so ähnlich wie phab:T64435 an, nur das es hier den Benutzer betrifft. Der Umherirrende 12:23, 9. Apr. 2016 (CEST)
Hallo Umherirrender, Danke für die Info, aber mit dem Bug T64435 kann ich bezüglich dem konkreten Fehler leider nichts anfangen. Dieser Bug hat mMn eigentlich mit der MW-Erweiterung 'Danke' kaum etwas zu tun bzw. sehe ich den tatsächlichen Zusammenhang bisher noch nicht. Außerdem habe ich darin leider auch keine konkrete Angabe zur erforderlichen Behebung/Korrektur, die in diesem Fall im Regiowiki AT durchzuführen ist, gefunden. -- Gruß, Sonne7 Disk!  15:08, 9. Apr. 2016 (CEST)
Mit der Danke-Erweiterung hat er zu tuen. Neben dem Fall, das der Benutzer komisch aussieht, gibt es manchmal auch den Fall, dass die Seite nicht richtig dargestellt wird. Dieser Fall ist im Bug beschrieben.
Leider gibt es noch keine Behebung oder Korrektur, die angewendet werden kann (Bug ist noch "open"). Technisch ist der Fall so, dass der Auslöser des Dankes nicht mehr ermittelt werden kann. Dies passiert beispielsweise wenn ein Benutzer über eine andere Erweitung gelöscht oder zwei Benutzerkonten zusammengeführt werden. Der Umherirrende 16:09, 9. Apr. 2016 (CEST)
OK, in welcher Datei passiert das? Also welche Datei ist konkret dafür zuständig? Bitte um den Pfad und den Dateinamen. Ich werde sie mir einmal selbst ansehen, mal sehen ob ich darin etwas dazu finde :-) -- Gruß, Sonne7 Disk!  16:24, 9. Apr. 2016 (CEST)
Das ist ein Zusammenspiel von mediawiki/extensions/Echo/* und mediawiki/extensions/Thanks/*.
Wenn man sich aber bedankungen akutell hier in der Wikipedia anschaut, so ist der Benutzer nicht im Text verlinkt, daher kann es sein, das bereits mit einer neueren Version das Problem behoben ist. Der Umherirrende 17:28, 10. Apr. 2016 (CEST)
Vielen Dank für diese Info - allerdings betrifft es gar nicht die Wikipedia, sondern das damit verbundene Regiowiki AT (http://regiowiki.at/wiki/Hauptseite), welches lokale Themen bezüglich Österreich behandelt. -- Gruß, Sonne7 Disk!  20:48, 13. Apr. 2016 (CEST)

Dankeschön-Logbuch - Einträge um Artikelnamen ergänzen[Quelltext bearbeiten]

Kann man die Einträge im Dankeschön-Logbuch um den Artikelnamen ergänzen (also z.B. nach dem Zeitstempel, dem von-Benutzer, dem Text 'dankte' und dem an-Benutzer noch der Text 'bezüglich' und der Artikelname (als Link) wäre sehr hilfreich - kurzform: A dankte B bezüglich C ).

Diese Anfrage betrifft konkret das 'Regiowiki AT' (http://regiowiki.at/), bei dem über deren Betreiber K@rl, auch alle Systemadministrationsrechte verfügbar sind.

Bitte hierzu um einen konkreten Tipp der Realisierbarkeit davon - oder falls nicht einfach selbst konfigurierbar/programmierbar, dann bitte dieses als Verbesserungsvorschlag werten (vermutlich für MediaWiki) - vielen Dank, schon im Voraus!

-- Gruß, Sonne7 Disk!  12:14, 9. Apr. 2016 (CEST)

Die Grundidee hinter mw:Extension:Thanks war, dass die Info der betroffende Seite nicht öffentlich ist. Nur die generelle Benutzung ist öffentlich. Dies gilt dann aber für Drittnutzer wie das regiowiki. Man könnte dies über eine Konfiguration machen, der Verbesserungsvorschlag muss dann in Phabricator erfasst werden. Der Umherirrende 12:23, 9. Apr. 2016 (CEST)
Hallo Umherirrender, an den Regeln der Wikipedia möchte ich eigentlich hier gar nicht drehen (dazu wäre vermutlich viel zu viel Widerstand zu überwinden), obwohl es als VV mMn ungefährlich wäre, wenn es entweder nur für angemeldete Benutzer sichtbar sein würde (also gar nicht für IPs), oder sogar nur für die 'Danke' vom/zum eigenen Benutzer angezeigt werden würde (an diesen somit längeren Zeilen würden diese in der Liste sogar sehr viel besser zu erkennen sein, was ich als gewünschten Nebeneffekt betrachte). Jedenfalls für das im Vergleich zur WP nahezu familiäre Regiowiki AT (dort gibt es prinzipiell keine IPs und nur relativ wenige aktive Benutzer) möchte ich diese Erweiterung selbst (bzw. über K@rl) kurzfristig implementieren - dazu benötige ich aber den Namen der dafür dort (im RW) zu ändernden Datei (und eventuell zusätzlich noch einen Tipp zur erforderlichen Durchführung dieser Änderung). Deshalb bitte ich um diese Info(s) - Danke, schon im Voraus! -- Gruß, Sonne7 Disk!  16:11, 9. Apr. 2016 (CEST)
Versteckt sich alles in der Thanks-Erweiterung mediawiki/extensions/Thanks/*. Was genau zu ändern wäre, muss entsprechend geprüft werden. Man könnte den Seitennamen als Log-Parameter zusätzlich speichern und hat es dann bei der Anzeige wieder zur Verfügung. Lässt sich natürlich auch anders lösen. Der Umherirrende 17:24, 10. Apr. 2016 (CEST)
Vielen Dank für diese Info und den Tipp. Leider bin ich derzeit durch das RL sehr stark beschlagnahmt, weshalb ich erst später dazu kommen werde, diese Info und den Tipp praktisch zu nutzen. -- Gruß, Sonne7 Disk!  21:01, 13. Apr. 2016 (CEST)

background-image funzt nicht[Quelltext bearbeiten]

Hi, mag jemand mal schauen, warum ich hier den background-image nicht reinkrieg, siehe Quelltext user:Doc Taxon/WikiMUCDoc TaxonDiskussionWiki-MUCWikiliebe?!16:23, 10. Apr. 2016 (CEST)

background-image sind verboten, weil man über den url-Parameter auch Dateien von anderen Webseiten laden könnte. Der Umherirrende 16:27, 10. Apr. 2016 (CEST)
@Umherirrender: was wäre dann die Alternative für wiki/commons-Bilder? – Doc TaxonDiskussionWiki-MUCWikiliebe?!16:38, 10. Apr. 2016 (CEST)
@Doc Taxon: Du kannst folgendes machen: Bild normal einbinden, <div> als Container umschließen und mit position: absolute; hinter deine andere Ebene packen, notfalls mit z-index anpassen. Viele Grüße! --FNDE (Diskussion) 16:59, 10. Apr. 2016 (CEST)
Liegt daran, was man machen möchte. Wenn du Text über das Bild schreiben möchtest, dann wirst du um die genannten Spielerreihen nicht drumherum kommen. Die Positionskarten machen das beispielsweise. Der Umherirrende 17:26, 10. Apr. 2016 (CEST)
prima, hat super funktioniert. Vielen Dank, – Doc TaxonDiskussionWiki-MUCWikiliebe?!01:58, 11. Apr. 2016 (CEST)

Editnotice für ganze Gruppen von Artikeln einrichten?[Quelltext bearbeiten]

Hallo, ich habe auf Wikipedia:Administratoren/Anfragen#Editnotice Schweizbezogen eine Frage und Anregung zur Editnotice in Artikeln gestellt. Dort scheint nicht der richtige Ort für eine entsprechende Diskussion zu sein, vielleicht aber hier? Ich fände es sinnvoll, wenn es möglich wäre, in mehrere gleichartige Artikel eine bestimmte Editnotice (z. B. Vorlage:Editnotice Schweizbezogen) einzubauen. Dass man das – wie mir von den Administratoren mitgeteilt wurde, selbst habe ich davon keine Ahnung – für jeden Artikel nur einzeln machen kann, selbst wenn der Hinweis mehrere verwandte Artikel betrifft, ist doch unpraktisch und uneinheitlich. Was meint ihr? --Miss-Sophie (Diskussion) 16:00, 14. Apr. 2016 (CEST)

Die technische Auskunft stimmte, siehe Hilfe:Editnotice. Ob das, was Du willst, anders ginge, oder ob es wirklich sinnvoll wäre, kann ich nicht sagen. Auf enwiki unterdücke ich den editnotice-Spam mit en.wikipedia.org##DIV[class="editnotice-page"] im AdBlock. –Be..anyone 💩 16:40, 14. Apr. 2016 (CEST)
wie auf Wikipedia:Administratoren/Anfragen#Editnotice Schweizbezogen bemerkt, halte ich nicht nichts von massenhaften Verteilen von Editnotice-Seiten, da es für das gewünschte Ziel auch einfachere Methoden gibt, die nicht unnötigen Wartungsaufwand im Nachhinein verursachen (Etwa nach Seitenverschiebungen). Ich schätze, dass das derzeitige Editnotice-System irgendwann komplett geändert wird, und danach eigene Editnotice-Seiten gar nicht mehr notwendig sein werden. Die bestehenden werden dann wohl Löschkanditaten.  Frohes Schaffen — Boshomi Defekte URLs - Hilfe mit!  17:33, 17. Apr. 2016 (CEST)

Wikimails kaputt?[Quelltext bearbeiten]

Hallo, seit heute bekomme ich weder Wikimails von anderen Benutzern als auch solche von der Software. Senden geht wohl noch, aber die Kopie an mich geht auch nicht raus. Eingehende Mails werden nur als Ping angezeigt, jedoch nicht bei mir im Postfach. Andere E-Mails kommen problemlos bei mir an, also kann dies nicht an meinem Postfach liegen. Auch habe in letzter Zeit weder irgendetwas an meinen Einstellungen, noch an meinem Postfach geändert. Hat hier noch jemand anderes das Problem oder kann mir weiterhelfen? -- Freddy2001 DISK 20:08, 19. Apr. 2016 (CEST)

Ich habe ziemlich genau dieses Verhalten auch beobachtet. Als Vermutung naheliegend wäre ein Zusammenhang mit der heutigen wikitech:Switch Datacenter-Aktion. --Entlinkt (Diskussion) 20:14, 19. Apr. 2016 (CEST)
Die PDF-Funktion geht wohl auch nicht. Mal sehen, was jetzt sonst noch alles kommt… -- Freddy2001 DISK 20:56, 19. Apr. 2016 (CEST)
Die PDF-Funktion ist schon seit vielen Monaten nicht mehr brauchbar (Tabellen werden ignoiert), also ist ein aktueller Ausfall gar nicht schlimm. --Atamari (Diskussion) 21:01, 19. Apr. 2016 (CEST)
Das Problem mit der PDF-Funktion ist in Phabricator gemeldet und auch sehr zügig behoben worden (phab:T133136); für das E-Mail-Problem habe ich keinen Phabricator-Eintrag gefunden, dafür aber viele Meldungen quer durch die Wikipedia, siehe etwa dort oder dort oder dort. --Entlinkt (Diskussion) 07:22, 24. Apr. 2016 (CEST)

Shared tabular data storage for Commons![Quelltext bearbeiten]

CCing from commons, please participate there as this will be a cross-wiki shared feature. Please translate.

During the last hackathon I created a new on-wiki tabular storage described in T120452, similar to CSV and TSV formats. It allows any user to create a page, e.g. "Data:List of interesting facts.tabular" (demo), and keep it as a table, rather than wiki text. Tabular storage allows strings, numbers, Booleans (true/false), and "localized strings" – a string that has different value depending on the language. Additionally, tabular data stores metadata, such as description (localized) and license. More metadata can be added as needed.

Tabular storage greatly simplifies storing data for lists, tables, and graphs. Graphs may directly access tabular data, and on-wiki tables and lists can be created by using simple Lua scripts. This storage is fundamentally different from Wikidata, because it works with "blobs" (batches) of data, whereas Wikidata works with tiny "facts". Wikidata technology is simply not suited for large storage such as the list of the most expensive paintings, the shoe size comparisons table, or data to plot Moscow Metro expansion graph.

After a long discussion, it seems Commons is the best fit for such data. Commons community already has good experience with international multi-licensed content. The current proposal is to create the data namespace on Commons, and use it from all of the wikis.

Feel free to experiment with it at http://data.wmflabs.org/wiki/Data:Sample.tabular. Note that you can view it with different languages, e.g. http://data.wmflabs.org/wiki/Data:Sample.tabular?uselang=fr

Technical notes: When storing, the data is validated and stored as JSON, so there are no delimeter problems common to the traditional CSV/TSV files. At this point, the wiki editor shows tabular data as a JSON, but very soon I hope to have a CSV/TSV editor to simplify copy/pasting, and afterwards – a full scale spreadsheet table editor. Eventually, I would also like to implement Q number support, allowing direct links to Wikidata. --Yurik (Diskussion) 23:10, 19. Apr. 2016 (CEST)

Benachrichtungen defekt?[Quelltext bearbeiten]

Seit dem Datacenter-Switch werden bei mir keine Benachrichtigungen mehr in der obersten Seitenzeile addiert (also bei den Glocke- & Tabs-Feldern). Die letzte Nachricht ist am 19. April um 8:25 generiert worden. Wie ich jetzt entdeckt habe, gab es aber ein paar Edits für die es Nachrichten geben müsste (z.B. Erwähnung meines Benutzernamens). Hat jemand eine Idee, dazu? Emailus Interruptus gab es beim Switch offenbar auch? mit gruessen von VINCENZO1492 10:24, 22. Apr. 2016 (CEST)

Test-Danke unterwegs, versuch mal die üblichen Tricks (Purge, logout+login, …); bei mir geht's. –Be..anyone 💩 10:54, 22. Apr. 2016 (CEST)
Danke. Dein Danke wurde angezeigt. Anderes aber weiterhin nicht. Logout, purge, Einstellungen ein/aus, Erweiterte Benachrichtungen ein/aus, alles schon gemacht, trotzdem nix passiert. Die Benachrichtigungen der letzten Tage sind einfach nicht aufgetaucht. Es ist ja nicht nur die Anzeige, auf der Benachrichtigungsseite selbst ist auch nichts verzeichnet, obwohl es müsste. Die Edits die bisher ich gefunden habe, waren zwischen Switch & Re-Switch (19. & 21.04.). Falls Du noch mal antwortest, wäre es praktisch wenn Du darin ggf. meinen Benutzernamen erwähnen würdest, das sollte ja eine Nachricht auslösen. Evtl. ist ja jetzt auch bei mir wieder ein genaues Verzeichnis der Aktivitäten vorhanden. mit gruessen von VINCENZO1492 11:59, 22. Apr. 2016 (CEST)
@Vincenzo1492: angefordertes Ping. Dass irgendwas fehlt, was kurz vor der Umstellung war, wäre vielleicht Einzelschicksal, aber "geht gar nicht mehr" ist schlecht (bei Chrome gibt es chrome://settings/clearBrowserData beschränkt auf cached images and files, lösch nix anderes, wenn Du das probierst). –Be..anyone 💩 12:22, 22. Apr. 2016 (CEST)
Dein Ping ist jetzt korrekt angekommen. Aber mind. 3 Nachrichten zwischen den Switches, von denen ich inzwischen weiss, fehlen komplett... Seltsam. mit gruessen von VINCENZO1492 13:29, 22. Apr. 2016 (CEST)

Anzeigen, ob ein Bild auf Commons zum Löschen vorgeschlagen wurde[Quelltext bearbeiten]

Hierher verwiesen von FzW.
Gibt es die Möglichkeit, sich per CSS einen Link zu einem Bild z.B. rot zu hinterlegen, das auf Commons zum Löschen vorgeschlagen wurde? –Queryzo Red-WikiPill.png Blue-WikiPill.png 14:34, 27. Apr. 2016 (CEST)

Hallo Queryzo, wie dort schon erwähnt wird das mit CSS nicht ausreichen (zur Unterscheidung von Bildern aus Commons würde das reichen). Hier benötigt man JavaScript respektive API-requests. Nun ist noch die Frage, ob es nur Bilder von Commons sein sollen? User: Perhelion 14:43, 27. Apr. 2016 (CEST)
(nach BK) @Queryzo: Da sehe ich leider keine Chance. Dafür müsste der Link auf de:WP generell eine eigene Klasse haben. Man könnte es aber mit einem Script lösen, dass den jeweiligen Link prüft. Viele Grüße --FNDE (Diskussion) 14:44, 27. Apr. 2016 (CEST)
Mir ist es eigentlich egal, wie es funktioniert. Wenn es geht, würde ich mich riesig freuen, wenn mir jemand so etwas basteln könnte. Das würde die tägliche Arbeit mit der MerlBot-Liste ziemlich erleichtern. –Queryzo Red-WikiPill.png Blue-WikiPill.png 14:56, 27. Apr. 2016 (CEST)

@Magnus Manske: Ginge das vielleicht über „Category:DR“ + die Option „ist von dieser Seite verlinkt“ mit PetScan? --Flominator 15:29, 27. Apr. 2016 (CEST)

Man kann eine Liste von Seiten (Dateien) an PetScan übergeben, die dann ein Subset des „Category:Deletion requests“-Baums zurückgibt. Beispiel für „File:Max_V.jpg“. Das ginge per Script dann auch für die Dateien auf der Merlbot-Liste. Ich hoffe, das wird ein Link in der Werkeug-Leiste, kein automatisch-bei-jedem-Seiten-Laden, oder wir DDOSen PetScan… --Magnus Manske (Diskussion) 17:37, 27. Apr. 2016 (CEST)
Also ist im Prinzip die so geforderte Anfrage sinnvoll oder nicht?
@Magnus Manske: „kein automatisch-bei-jedem-Seiten-Laden“ also Benutzer:YMS meinte mehrere hundert API-Abfragen pro Aufruf wären kein Problem⁉
Ich habe nämlich schon mal die API-Anfrage (mit einem Bsp-Bild) fertig (Edit): jetzt im Script: User: Perhelion 01:05, 28. Apr. 2016 (CEST)
// [[File:User:Perhelion/riskImages.js]] (workaround for [[phab:T35355]])
importScript( 'Benutzer:Perhelion/problemImages.js' );
Fehlt nur noch die jQuery-Schleife welche eine Bilderliste der Seite generiert und eine CSS-Funktion die das Ergebnis umsetzt. User: Perhelion 18:16, 27. Apr. 2016 (CEST)
Meine Nachfrage auf FzW und die Antwort, dass da ein API-Aufruf reicht, habt ihr schon berücksichtigt? --° (Gradzeichen) 18:25, 27. Apr. 2016 (CEST)

Ich wollte mal etwas Ähnliches erreichen: Die Commons-Kategorien eines Bildes anzeigen zu lassen (ohne Test ob eine davon eine Löschen-Kategorie ist). Bisher war ich soweit gekommen:

image = document.getElementsByClassName("image")[0]; //Hier müsste eine For-Schleife hin, so wird nur das erste Bild genommen
urlcomp = image.href.split('/');
if (urlcomp[2] === "commons.wikimedia.org"){      //Nur für Commons-Bilder
  mw.loader.using( 'mediawiki.ForeignApi' ).done( function () {
    var api = new mw.ForeignApi( 'https://commons.wikimedia.org/w/api.php' );
    api.get( {
      action: 'query',
      prop: 'categories',
      format: 'json',
      formatversion: '2',
      titles: decodeURI(urlcomp[4])
    } ).done( function ( data ) {
      newdiv = document.createElement("div");
      image.insertBefore(newdiv, image.firstChild);
      newdiv.style.position = "absolute";
      newdiv.style.maxWidth = "200px";
      newdiv.className = "commonsCat";
      newdiv.style.textAlign= "left";
      obj1 = data.query.pages[0].categories;
      for (i = 0; i < obj1.length; i++){
        newdiv.appendChild(document.createTextNode(obj1[i].title.split(':')[1]));
        newdiv.appendChild(document.createElement("br"));
      }
    } );
  } );
}

Legt über das erste Bild der Seite eine Liste mit den Kategorien. Vielleicht hilft euch ja ein Teil davon. Mein Versuch alle Bilder in eine Abfrage zu packen begann so:

var images = document.getElementsByClassName("image");
filenames = "";
for (n = 0; n < images.length; n++){
  var urlcomp = images[n].href.split('/');
  if (urlcomp[2] === "commons.wikimedia.org"){
    filenames += decodeURI(urlcomp[4]);
    if (n != images.length - 1) { filenames += "|";}
  }
} //Generiert einen mit | geteilten String den die Commons-API versteht.

Ich bin bei Javascript aber nicht so talentiert, die Code-Qualität ist nicht sonderlich gut. Die API-Antwort für mehrere Bilder dabei habe ich aber nie ganz unter Kontrolle gekriegt, das continue bereitete mir Probleme. Ich habe an der Stelle dann aufgegeben. Vom JS-Amateur einen Gruß, --Nfreaker91 18:45, 27. Apr. 2016 (CEST)

Sorry, habe in der Zwischenzeit mein eigenes Script gebaut :-( Auf Deiner common.js-Seite nur
importScript( 'Benutzer:Magnus_Manske/rotbilder.js' );
hinzufügen, dann gibt’s ein neues „Rotbilder“-Werkzeug. Auf Wikipedia:Redaktion Film und Fernsehen/3F/Bilderwunsch z.B. markiert das dann alle von Löschung bedrohten Bilder. Habe es auf „normalen“ Seiten noch nicht ausprobiert, mangels Beispiel.
Oh, und die Commons-API könnt ihr gerne beharken wie ihr lustig seid. PetScan kann komplexere Anfragen bearbeiten, aber nicht ganz so zügig… --Magnus Manske (Diskussion) 19:07, 27. Apr. 2016 (CEST)
Wow, richtig was los hier! @Magnus Manske: Mit deinem Skript regt sich bei mir nix, hab gepurgt und alles, (die Merlbot-Liste) sieht aus wie vorher. –Queryzo Red-WikiPill.png Blue-WikiPill.png 23:33, 27. Apr. 2016 (CEST)
Ich habe mal Spaßes halber das Script, wie Anfangs gedacht (mit Hilfe von Teilen des Scriptes von Magnus) fertig gestellt:
importScript( 'Benutzer:Perhelion/problemImages.js' );
Bitte mal testen, z.B. ein Bild bei Benutzer:PerfektesChaos :-)
PS: Weiß jemand warum nicht alle Bilder die class image haben? Somit greift auch nicht immer das Gadget-Direct-link-to-Commons.js (dessen Erkennungsschleife ich genommen habe) User: Perhelion 00:31, 28. Apr. 2016 (CEST)
Ohne jetzt genau nachgeschaut zu haben: Wie behandelt dein Script Bilder die bei de.wiki gehostet werden statt commons? Ansonsten vielleicht wenn ein Bild kein Link ist (sehr selten wg. Lizenz), da das eine class des a-Elements ist. Gruß, --Nfreaker91 00:59, 28. Apr. 2016 (CEST)
@Nfreaker91: Gute Frage, es funzt momentan nur für Commonsbilder (wie eingangs gewünscht) und tatsächlich nur für Bilder die auch zum Bild verlinken. Die Wahrscheinlichkeit das unverlinkte Bilder gelöscht werden ist tasächlich sehr gering. PS: Ich habe auch noch Schnelllöschkandiaten drinnen und ich könnte noch offene Lizenz- und OTRS-Kandiaten in die „Gefahrengruppe“ aufnehmen. User: Perhelion 01:05, 28. Apr. 2016 (CEST)
@Magnus: Bei mir hat das Skript auch nichts markiert. User: Perhelion 01:05, 28. Apr. 2016 (CEST)
@Perhelion: Funktioniert auch nicht, getestet auf Firefox (44.0.2), Chrome (49.0.2623.112) und gepurgt. Der Parameter : -( wurde nicht erkannt! Queryzo Red-WikiPill.png Blue-WikiPill.png 08:34, 28. Apr. 2016 (CEST)
Na ja, „funktioniert nicht“ alleine ist nicht sehr hilfreich, bei mir geht’s. Wenn ihr auf „Rotbilder“ klickt, erscheint dann ein „Suchen“-Hinweis unter dem Link? Irgendwas in der JavaScript-Konsole? --Magnus Manske (Diskussion) 10:12, 28. Apr. 2016 (CEST)
@Magnus Manske: Wo steht denn „Rotbilder“? –Queryzo Red-WikiPill.png Blue-WikiPill.png 11:09, 28. Apr. 2016 (CEST)
Ich habe das Skript nicht aktiviert, aber so wie ich es gestern gelesen habe, müsste der Link in der Toolbox („Werkzeuge“ bei Vector links) stehen? --° (Gradzeichen) 11:49, 28. Apr. 2016 (CEST)
Gefunden! Super, danke!!‼ –Queryzo Red-WikiPill.png Blue-WikiPill.png 12:39, 28. Apr. 2016 (CEST)
Richtig, ihr könnt es auch testen in dem ihr einfach die Zeile in die JavaScript-Konsole (STRG + K oder J) des Browsers ausführt, dann müsste der Link immer ganz unten (links) bei den Werkzeugen sein (diese ist bei mir leider auch schön übergroß…).
Ich habe jetzt auch „lokale löschgefährdete Dateien“ hinzugefügt (kann mir hier kurz testen WP:GWS). @Nfreaker91: Kategorien anzeigen finde ich eigtl. praktisch, das füge ich auch noch hinzu bzw. gleich einen kleinen Symbolmarker, welche Datei auf Commons liegt⁉
Dabei fällt mir noch optional ein (was ich schon immer mal machen wollte und wenn wir schon dabei sind jede Datei zu scannen) gleich Dateien markieren die durch bessere ersetzt wurden, wie „Vector version available“ (oder Superseded PNG oder {{JetztSVG}})⁉ User: Perhelion 12:35, 28. Apr. 2016 (CEST)
@Perhelion: Mein ursprünglicher Plan war ein Popup für Bilder, so wie die Popups für Links. Dabei wollte ich den Commonsdateinamen, die -beschreibungen(de&en) und die -kategorien anzeigen lassen. Bisher habe ich Dateinamen und Kategorien, aber die Anzeige funktioniert nicht über Popup und nicht bei hover, sondern statisch. Wären auch andere an dieser Funktionalität interessiert? Dann würde ich weiterentwickeln. Gruß, --Nfreaker91 12:02, 29. Apr. 2016 (CEST)

@Magnus Manske: Nochmal vielen Dank für das Tool! Könntest du noch die Kategorien c:Category:Media without a license, c:Category:Media missing permission und c:Category:Candidates for speedy deletion ergänzen? LG –Queryzo Red-WikiPill.png Blue-WikiPill.png 13:00, 28. Apr. 2016 (CEST)

Funktioniert bei mir jetzt auch. @Queryzo, da war wohl ein kleines Verständnisproblem, ich hatte Anfangs das zu allg. verstanden. Meine Script-Variante arbeitet nun auf jeder Seite, jedoch nur bei Links mit Bild⁉ (auf so eine Liste muss man ja erst mal kommen, bzw. den Sinn dieser speziellen Liste verstehen) ^^ User: Perhelion 13:14, 28. Apr. 2016 (CEST)
also mit deinem Skript kriege ich bei der Merlbot-Liste „0 Dateien markiert“ … –Queryzo Red-WikiPill.png Blue-WikiPill.png 13:42, 28. Apr. 2016 (CEST)
@Queryzo: Deswegen sagte ich „Links mit Bild“ also Betonung auf mit Bild (deutlicher gemacht). Da ich eher dachte das Script im Artikelnamensraum auszuführen, da ist das Verhältnis zu andern Links wohl 0,000001 %. Wie gesagt ich dachte nicht an eine „einzelne“ Listenseite… User: Perhelion 14:01, 28. Apr. 2016 (CEST)
Auf Anregung von User:° habe ich nun auch eine globale Version erstellt und auf Meta abgelegt. User: Perhelion 14:37, 1. Mai 2016 (CEST)

Alternativvorschlag: Bot-Benachrichtigung[Quelltext bearbeiten]

Auch wenn Ihr hier schon fleißig an einer Implementierung für eine gegebene technische Lösung gearbeitet wird, lohnt es sich wahrscheinlich nochmal einen Schritt zurück zugehen und die Frage zu stellen, ob das überhaupt die beste Lösung für das dahinterliegende Problem ist⁈

Soweit ich das interpretiere, ist diese rote Markierung ja kein Selbstzweck, sondern soll den betroffenen Artikelautoren mitteilen: „Achtung dieses Bild ist von einer Löschung bedroht. Äußere Dich zum Löschantrag oder schau Dich nach Alternativen um.“ Diese Aufgabe kann die oben skizzierte Lösung aber nur dann erfüllen, wenn der jeweilig Autor zum Zeitpunkt des Löschantrags die betreffende Seite aufruft und bis zur Stelle des Bildes scrollt. Und dass das so gut wie nie der Fall sein dürfte, wird schnell klar, wenn man mal die Gesamtheit der beobachteten Seiten mit der Anzahl der Seiten vergleicht, die man in der letzten Woche tatsächlich besucht hat. Ich glaube daher nicht, dass diese geringe Erfolgswahrscheinlichkeit es rechtfertigt, Tag für Tag hunderte JS-API-Anfragen loszuschicken.

Wenn es also im Grunde darum geht, den Autoren der betroffenen Artikel mitzuteilen, dass ein dort verwendetes Bild gelöscht werden könnte, dann sollte man genau das tun: Genauso, wie heute schon ein Bot bei jedem Löschantrag, den Uploader des Bildes auf seiner Diskussionsseite informiert, könnte man das auch bei den Artikel tun. Und wenn bei einem Bild-Löschantrag automatisch auf der Diskussionsseite jeder Seite, die dieses Bild Wikimedia-weit einbindet eine Info gepostet würde, dann bekäme dass (im Gegensatz zur oben skizzierten Lösung) auch jeder Autor mit, der diese Seite auf seine Beobachtungsliste hat – und zwar ohne dafür täglich tausende sinnlose API-Anfragen zu schicken. // Martin K. (Diskussion) 19:13, 27. Apr. 2016 (CEST)

Das ist auf jeden Fall ein guter Gedankenansatz, der, wie ich befürchte, schon mal irgendwo gedacht wurde. Das sollte man mal irgendwo breiter vorschlagen, zwecks Sinnhaftigkeit. User: Perhelion 21:26, 27. Apr. 2016 (CEST)
Ich könnte mir vorstellen, das der MerlBot für Portale auf diesem Wiki diese Funktion anbieten kann (oder schon anbietet?). Der Umherirrende 22:00, 27. Apr. 2016 (CEST)

Auf Benutzer:Flominator/Breisgau-Hochschwarzwald/Baustellen habe ich etwas mit dem Subster-Bot gebastelt, das mir zumindest die Löschanträge in einer Kategorie und ihren Subkategorien anzeigt. Vielleicht hilft das ja weiter (wobei die Benachrichtigung auf der Diskussionsseite des einbindenden Artikels schon mehr Charme hätte) --Flominator 22:32, 27. Apr. 2016 (CEST)

JavaScript-Lösung für MediaWiki:Specialpage-helplink[Quelltext bearbeiten]

Hallo,

die obengenannte Systemnachricht wird benutzt, um auf einigen Spezialseiten (insbesondere Special:Logs) einen Hilfe-Link in der Ecke oben rechts anzuzeigen, wo kein MediaWiki-eigener Hilfe-Link vorhanden ist.

Ich habe auf der Seite MediaWiki Diskussion:Specialpage-helplink dargelegt, inwiefern die gegenwärtige Implementierung problematisch ist. In aller Kürze:

  1. Die Implementierung verlässt sich auf einen skinabhängigen CSS-Hack (nämlich auf denselben wie die Koordinaten), der ohnehin problematisch ist.
  2. Ein Ersatz durch das „offizielle“ Softwarefeature <indicator> ist nicht möglich, da dies nicht in allen betroffenen Systemnachrichten funktioniert.
  3. Ein Ersatz durch MediaWiki-eigene Hilfe-Links (wie man sie auf einigen Spezialseiten wie Spezial:Letzte Änderungen sieht) wäre optimal, ist aber durch uns nicht zu leisten.
  4. Die durch unsere Systemnachricht implementierten Hilfe-Links sehen anders aus als die MediaWiki-eigenen (kleiner, am oberen Rand klebend).
  5. Es ist zu erwarten, dass die gegenwärtige Lösung durch den Umschrieb aller Spezialseiten auf OOUI in absehbarer Zeit zumindest auf manchen Spezialseiten überhaupt nicht mehr funktionieren wird.

Ich habe daher eine JavaScript-Lösung entworfen und bitte um Beurteilungen, ob wir diesen Weg gehen sollten. Die Systemnachricht wäre durch den folgenden Inhalt zu ersetzen:

<div id="mw-indicator-mw-helplink" class="mw-indicator specialpage-helplink" style="display: none;">[[{{{link|Hilfe:Spezialseiten}}}|Hilfe]]</div>

Dazu käme (sinngemäß) das folgende JavaScript, das natürlich ggf. auch in ein Gadget verpackt werden kann:

/**
 * Unterstützung für [[MediaWiki:Specialpage-helplink]]
 * Simuliert das Aussehen und Verhalten derjenigen Hilfe-Links, die durch
 * OutputPage::addHelpLink() erzeugt werden
 */
if (mw.config.get( 'wgNamespaceNumber' ) === -1) {
	mw.loader.using( [ 'mediawiki.helplink' ], function () {
		mw.hook( 'wikipage.content' ).add( function ( $content ) {
			$content
			.find( '.specialpage-helplink' )
			.prependTo( '.mw-indicators' )
			.show()
			.children( 'a' )
			.addClass( 'mw-helplink' )
			.attr( 'target', '_blank' )
			.removeAttr( 'title' );
		} );
	} );
}

Der Code ist von dem ehemals in MediaWiki:Vector.js vorhandenen Code für „Top-Icons“ abgeleitet (Permalink). Ein offensichtlicher Nachteil dieser Lösung wäre, dass sie nur bei aktiviertem JavaScript funktioniert; dies halte ich aber für verschmerzbar, da die Implementierung bis vor kurzem noch an die „Top-Icons“ gekoppelt war, die im Vector-Skin ebenfalls nur bei aktiviertem JavaScript funktionierten.

Die „Design-Ziele“ meines Entwurfs sind folgende:

  1. Die Lösung soll möglichst einfach (und insbesondere nicht skinabhängig) sein.
  2. Das Resultat soll so exakt wie möglich das Aussehen und Verhalten der MediaWiki-eigenen Hilfe-Links simulieren (daher die vielleicht etwas merkwürdig anmutenden Manipulationen von Attributen).
  3. Die Lösung soll keine „kreativen“ Missbrauchsmöglichkeiten in der Seitengestaltung eröffnen (daher sollte das Skript nur auf Spezialseiten laufen).

Natürlich gibt es zu diesem Entwurf auch Alternativen, insbesondere die Möglichkeit, nichts zu tun. Viele Grüße --Entlinkt (Diskussion) 19:03, 11. Mai 2016 (CEST)

Statt prependTo fände ich appendTo logischer (auch wenn es in der Praxis keinen Unterschied machen sollte). Der Form halber wäre es zudem schön, wenn es zumindest ein Phabricator-Ticket gäbe, in dem darum gebeten wird, die indicator-Methode überall möglich zu machen, dieses beim Code erwähnt wird und dann natürlich auch die Seiten umgestellt werden, wo kein JS zur korrekten Anzeige mehr notwendig ist. Ansonsten volle Zustimmung von meiner Seite. --Schnark 09:32, 12. Mai 2016 (CEST)
Der Beweggrund für prependTo war folgender: Die <indicator>-Elemente sind ja rechtsbündig ausgerichtet und das Skript würde den Hilfe-Link dort hinzufügen. Wenn eine Spezialseite aus irgendeinem Grund ein „echtes“ <indicator>-Element enthält, würde ein appendTo des Hilfe-Links dazu führen, dass das „echte“ <indicator>-Element während des Ladevorgangs wahrnehmbar nach links rutscht. Mit prependTo wird dieser Effekt vermieden. In der Praxis tritt so eine Konstellation aber derzeit eh nirgends auf.
Ein Phabricator-Task wäre sicher gut, aber ich bin nicht sicher, was drin stehen sollte. Man könnte anregen, dass die <indicator>-Methode in den betroffenen Systemnachrichten verfügbar gemacht wird, aber man könnte auch anregen, dass jede betroffene Spezialseite einen MediaWiki-eigenen Hilfe-Link erhält (was gemäß phab:T45591 vermutlich prinzipiell erwünscht ist). Beides würde unsere Probleme lösen, aber ich fände es etwas dreist, gleich beides anzuregen.
Was mich noch interessieren würde, wäre die Sicherheit. Ist der konkret vorgeschlagene Code dahingehend problematisch? Es werden ja Elemente ungeprüft verschoben, was bei benutzergenerierten Inhalten grundsätzlich problematisch sein kann, allerdings kenne ich benutzergenerierte Inhalte auf Spezialseiten nur auf Special:ExpandTemplates.
Wenn man diese Lösung aktivieren würde, sollte das dann ein hidden-Gadget sein oder sollte der Code direkt in MediaWiki:Common.js stehen? Viele Grüße --Entlinkt (Diskussion) 13:01, 12. Mai 2016 (CEST)
Bei appendTo vs. prependTo war meine Überlegung, was passiert, wenn auf einer Spezialseite dynamisch Inhalt hinzugefügt wird, der .specialpage-helplink-Elemente enthält. Das sollte zwar auch nirgendwo vorkommen, aber in dem Fall wäre es logischer, die neuen Elemente anzuhängen.
DOM-Elemente zu verschieben sollte keine Sicherheitsprobleme erzeugen. Da sehe ich keine Probleme. Die ISBN-Suche kann übrigens auch von autoconfirmed-Benutzern bearbeitet werden.
Zu Gadget vs. Common.js: Der Code muss ohnehin auf allen Seiten geladen werden (die Abfrage, ob man sich auf einer Spezialseite befindet vom eigentlichen Code zu trennen, wäre wohl zu ineffizient), da der Code aber immer auf das mediawiki.helplink_Modul warten muss, gäbe es selbst mit einem im Seitenkopf geladenen Gadget keinen flackerfreieren Aufbau. Damit spielen die beiden Hauptgründe für eine der beiden Methoden keine Rolle. Wenn es ein Gadget wird, dann sollte in Common.js zumindest ein Kommentar, der darauf hinweist, damit Benutzer, die an der klassischen Stelle nach dem Code suchen ihn auch finden. --Schnark 10:37, 13. Mai 2016 (CEST)
OK, vielen Dank soweit. Aber noch eine Frage:
Eigentlich muss der Code gar nicht immer auf das Modul mediawiki.helplink warten, da dies nur CSS enthält, das nur gebraucht wird, wenn ein .specialpage-helplink-Element vorhanden ist. Ist es überhaupt korrekt, diese Beziehung durch eine Abhängigkeit auszudrücken? Man könnte auch (analog zu dem Nachladen von jquery.ui.button in MediaWiki:Common.js) zuerst die Seite analysieren und es nur laden, wenn mindestens ein .specialpage-helplink-Element da ist. Oder wäre dann ein FOUC zu befürchten?
@Umherirrender: Vielleicht kannst du auch noch etwas dazu sagen, da du die Systemnachricht erstellt hattest? Vor allem würde mich interessieren, warum <indicator> an manchen Stellen nicht geht, wie aufwendig es wäre, das zu ändern und ob es überhaupt sinnvoll ist, diesbezüglich eine Änderung anzuregen.
Sorry für die vielen Fragen, aber ich kenne mich da nicht so aus und möchte vermeiden, dass etwas falsches/suboptimales gemacht wird. Gruß --Entlinkt (Diskussion) 10:54, 13. Mai 2016 (CEST)
Mit einem Nachladen statt der Abhängigkeit hätte man (vermutlich, ausprobiert habe ich es nicht) einen en:FOUC, was vermutlich (auch das habe ich nicht probiert) wesentlich störender wäre, als ein leicht verzögertes Auftauchen. --Schnark 11:11, 13. Mai 2016 (CEST)
Angefangen hat es hier, als es mehr wurde habe ich eine Vorlage raus gemacht, damit es überall gleich aussieht.
Technische Hintergrund: Das indicator-tag gehört (wie auch ResourceLoader-Module) zu den Metadaten des Output-Objects in MediaWiki. Beim parsen von Systemnachrichten werden diese Metadaten nicht verwendet, sondern nur der Text. Das führt dazu, dass die indicator-Tags in Systemnachrichten nicht funktionieren. Beim TOC ist es ähnlich, da das JS-Modul für das ausblenden zu den Metadaten hinzugefügt wird, ist es auf Spezialseiten nicht vorhanden (T66969). Meine Lösung war mal gerrit:196626, es gibt aber zu viele Bedenken wegen Seiteneffekte.
Am besten wäre es, wenn der generische Systemnachricht-Name zum überschreiben der Helplinks auf allen Spezialseiten funktionieren würde und standardmäßig nur leer ist, dann braucht es kein JS. Dies werde ich mal ausprobieren. Der Umherirrende 15:30, 13. Mai 2016 (CEST)

Wie könnten interaktive Karten auf Wikipedia eingesetzt werden?[Quelltext bearbeiten]

Hallo!

Das Maps-Team bei der Wikimedia-Stiftung kommt der Einbindung von Interaktiven Karten immer näher. Wer schon einmal Dienste wie Google Maps oder Mapquest genutzt hat, wird mit interaktiven Karten vertraut sein. Wir würden gerne Editoren zum Austausch darüber einladen, wie diese Karten in Artikeln zu Einsatz kommen könnten. Dazu haben wir Informationen zusammengestellt, wie diese Karten und ihre Gestaltung aus technischer Sicht funktionieren — wo die Daten herkommen, wie Karten gestaltet werden sowie einige Beispielanwendungen.

Wir möchten uns besonders auf die Diskussion um drei Kernfragen konzentrieren (eine offene Diskussion außerhalb dieser Fragen ist auch willkommen).

  • Welche Arten von Artikeln würden interaktive Karten einsetzen?
  • Wie unterscheiden sich diese Artikel in ihren Anforderungen?
  • Gibt es Artikelklassen, deren Anforderungen an die Kartenstile grundlegend im Konflikt mit anderen Artikelklassen steht und daher mehrere Stile braucht?

Bitte besucht mw:Maps/Conversation about interactive map use, um mehr zu erfahren und mitzuhelfen. CKoerner (WMF) (Diskussion) 22:06, 20. Mai 2016 (CEST)

vector.js[Quelltext bearbeiten]

Hallo! Ich möchte gerne meine vector.js so erweitern, dass im Kasten links ein Punkt Coord erscheint. Wenn dieser angeklickt wird soll {{Coordinate|NS=|EW=|type=|region=}} im Artikel eingefügt werden. Kann mir da jemand helfen?-- Viele Grüße aus Druffel sendet der Druffeler! (Diskussion) 10:10, 29. Mai 2016 (CEST)

@Druffeler: Unter Commons:User:Flominator/flos functions.js habe ich vor Jahren ein ähnliches Feature erstellt. Als Beispiel kann dort insert_painting_template zusammen mit insert_into_textarea dienen. Gruß, --Flominator 09:47, 1. Jun. 2016 (CEST)
@Flominator: Da steige ich gar nicht durch! -- Viele Grüße aus Druffel sendet der Druffeler! (Diskussion) 12:51, 1. Jun. 2016 (CEST)

Wenn du das wirklich willst, kann ich dir zeigen, wie du meinen Uralt-Code in deine vector.js einbauen kannst. Es wäre aber vermutlich sinnvoller, den Code vorher von Benutzer:PerfektesChaos (oder jemand anderem auf dem Stand der Technik) auf "veraltetes Gedöhns" untersuchen zu lassen. Ich vermute, er kennt sowieso eine Lösung, die weiter verbreitet ist, als meine. Gruß, --Flominator 09:32, 6. Jun. 2016 (CEST)

@Druffeler: Meinst du mit Kasten links den Kasten von PDDs Monobook? In dem Fall könnte Benutzer Diskussion:PDD die bessere Anlaufstelle sein. Prinzipiell müsstest du in die Funktion „function qbEditTags()“ oder „function qbArticleTemps()“ einen weiteren Eintrag hinzufügen, die Syntax erklärt sich quasi von selbst. Gruß, --Nfreaker91 09:19, 12. Jun. 2016 (CEST)

Commons-Kategorien von Bildern einer Kategorie[Quelltext bearbeiten]

Nachdem das mit PetScan nicht geht: Wie kann ich (ohne größeren Entwicklungsaufwand) auf "einen Blick" sehen, welche Kategorien die einzelnen Bilder in Category:ETH-BIB Mittelholzer-Persia flight 1924-1925 haben bzw. welche noch nicht in Orts- bzw. Sachkategorien einsortiert wurden? Danke und Gruß, --Flominator 09:43, 1. Jun. 2016 (CEST)

@Flominator: Verweis auf ähnliche Diskussion: WP:TWS#Anzeigen, ob ein Bild auf Commons zum Löschen vorgeschlagen wurde. Die Frage war wie man auf einen Blick feststellen kann ob ein Commons-Bild in einer Löschkategorie ist. Benutzer:Magnus Manske schrieb ein Javascript dass per API alle Kategorien holte und überprüfte ob eine Löschkategorie dabei ist. Das löst zwar dein Problem nicht, könnte aber ein Ansatz sein. Mein Plan war für jedes Bild die jeweiligen Kategorien anzeigen zu lassen wenn man mit dem Mauszeiger draufzeigt, dieses Projekt habe ich aber noch nicht fertig. Gruß, --Nfreaker91 09:25, 12. Jun. 2016 (CEST)

Veraendertes nowiki - tag Verherhalten ??[Quelltext bearbeiten]

Hallo, ich habe das <nowiki> tag immer benutzt, um zB. beim Erstellen eines Artikel kategorie: etc verbose erscheinen zu lassen, seit einiger Zeit geht das nicht mehr und ich sehe nun das <nowiki> und Kategorien erscheinen. Bug oder Feature ? -- A1000 (Diskussion) 19:26, 1. Jun. 2016 (CEST)

Falls du dies meinst: Das Tag ist bei dir nicht geschlossen, d. h. du hast nur das Start-Tag (<nowiki>) angegeben, aber nicht das End-Tag (</nowiki>).
So ist es nicht richtig:
<nowiki>[[Kategorie:Wikipedia:Hauptseite]]
So ist es richtig:
<nowiki>[[Kategorie:Wikipedia:Hauptseite]]</nowiki>
Siehe auch Hilfe:Tags#Syntax.
Es mag sein, dass sich das Verhalten der Software bei unvollständigen Tags auch mal ändert und dass das fehlende End-Tag früher „toleriert“ wurde, das weiß ich aber nicht sicher. Viele Grüße --Entlinkt (Diskussion) 19:53, 1. Jun. 2016 (CEST)
Das nowiki-Tag selber hat sich nicht geändert, aber jedes MediaWiki-Tag wird seit einigen Wochen nur noch erkannt, wenn es auch geschlossen wird. Da es bei deinen Verwendungen nur ein offnes nowiki-tag gibt, wird es nicht mehr erkannt. Schreibe auch noch ein schließendes Tag ans Ende der Seite und du hast die Funktion wieder. Der Umherirrende 19:55, 1. Jun. 2016 (CEST)
Ist das auch bei div, span und font so? Da wird eine kaputte Verwendung ja (leider) auch von MediaWiki repariert. Würde (imho erfreulicherweise) ein paar Verwendungen auf BD-Seiten (und bei font auch anderswo…) beenden :-) --nenntmichruhigip (Diskussion) 12:42, 2. Jun. 2016 (CEST)
Meines Wissens nicht. Geplant sind aber zwei Dinge:
  • Laut phab:T134423 soll die Self-Closing-Syntax bei HTML-Tags (d. h. sowas wie <div style="clear:both;"/> bald nicht mehr unterstützt werden. Das betrifft bei uns einige produktiv genutzte Vorlagen, wo dies irrigerweise eingebaut wurde, und insbesondere eine ganze Reihe von Artikeln, wo {{Absatz}} substituiert wurde, als es genau dieses Konstrukt enthielt.
  • Laut mw:Parsing/Replacing Tidy soll HTML Tidy entfallen und dadurch ersetzt werden, dass man den Code durch einen HTML5-Parser schickt und wieder serialisiert. Der Effekt ist dann in HTML5-konformen Browsern derselbe wie keine Reparatur (und in nicht-HTML5-konformen Browsern derselbe wie in HTML5-konformen). Die üblichen Verwendungen auf BD-Seiten, die mir so einfallen, würden damit aber möglich bleiben (da ein HTML5-Parser diese genauso behandelt wie Tidy).
Beide Änderungen werden aber wohl noch eine Weile dauern. --Entlinkt (Diskussion) 12:45, 2. Jun. 2016 (CEST)
Praktisches Beispiel: Die Implementierung des Geo-Mikroformats in Vorlage:CoordinateMain verlässt sich derzeit darauf, dass Tidy leere <span>-Elemente entfernt und verzichtet deshalb an einer sehr performancekritischen Stelle auf einige #if-Abfragen. Dies wird kaputtgehen. --Entlinkt (Diskussion) 13:19, 2. Jun. 2016 (CEST)
mit </nowiki> gehts wieder, logisch Verständlich aber nervig -- A1000 (Diskussion) 15:03, 2. Jun. 2016 (CEST)
Aktuell gilt es nur für MediaWiki-Tags, nicht für html-Tags. Gilt also für <abschnitt>, <categorytree>, <ce>, <charinsert>, <gallery>, <graph>, <hiero>, <imagemap>, <indicator>, <inputbox>, <math>, <nowiki>, <poem>, <pre>, <ref>, <references>, <score>, <section>, <source>, <syntaxhighlight>, <templatedata> und <timeline> (Geklaut von Spezial:Version). Für noinclude, includeonly und onlyinclude weiß ich es nicht. Der Umherirrende 17:56, 2. Jun. 2016 (CEST)

Zwei Dinge[Quelltext bearbeiten]

Ich weiß nicht, ob das hier hingehört, aber ich versuche es mal. Es sind zwei Vorschläge mit der Nachfrage, ob das technisch möglich und sinnvoll ist.

Erstens: Es kommt häufig gerade auf mobilen Geräten vor, dass man statt "nächster Versionsunterschied" auf "kommentarlos zurücksetzen" kommt. Ist eine Einführung einer Nachfrage "Willst du wirklich..." hier möglich und sinnvoll?

Zweitens: Kann man im Helferlein etwas einbauen, dass einem Links, die auf Weiterleitungen führen, grün oder so angezeigt werden, wie Begriffsklärungsseiten einem auch rot angezeigt werden können? Das könnte zum Beispiel einerseits dazu dienen Falschschreibungen besser zu erkennen (mit Sonderzeichen, die manche Leute leider nicht eingeben wollen), andererseits beispielsweise, um Links, die auf Weiterleitungen führen, aber mittlerweile einen Artikel haben, besser erkennen und den Link korrigieren zu können. Ich meine so etwas (oder etwas ähnliches) bereits in der ungarischen WP einmal gesehen zu haben. Sinnvoll?

Vielleicht sind das ja gute Ideen. Mir würden sie helfen. Gruß Kenny McFly (Diskussion) 21:02, 5. Jun. 2016 (CEST)

Hallo Kenny McFly,
mal nur zum zweiten Punkt: Das Thema ist ein Dauerbrenner, es gab diverse Diskussionen hierzu unter Wikipedia Diskussion:Helferlein/Begriffsklärungs-Check/Archiv.
Um es kurz zu machen: Eine derartige Erweiterung des Helferleins wäre trivial realisierbar, wurde aber bisher immer abgelehnt, da Links auf Weiterleitungen im Gegensatz zu Begriffsklärungen in der Regel nicht umgebogen werden müssen und auch nicht umgebogen werden sollen. Die Erweiterung des Helferleins würde dazu führen, dass zu viele Benutzer zu prominent auf Weiterleitungen hingewiesen werden, was mit der Gefahr verbunden wäre, dass unerwünschte Umbiegungen stattfinden.
Daher sollte es wohl dabei bleiben, dass die Hervorhebung von Weiterleitungen nur durch individuelle CSS-Einträge erfolgt. Ich persönlich verwende folgendes in Special:Mypage/common.css:
/* Weiterleitungen mit einem vorangestellten Pfeil markieren */
.mw-redirect:before {
	content: "↪";
}
Eine Hintergrundfarbe wäre mir persönlich zu penetrant. Gruß --Entlinkt (Diskussion) 23:07, 5. Jun. 2016 (CEST)
An diesen Gegenpunkt habe ich auch gedacht. Er regt mich auf, aber lässt sich leider sowieso nicht verhindern. Aber vielen Dank für den Code (oder wie das heißt. Ist nicht mein Fachgebiet). Dankeschön und Gruß Kenny McFly (Diskussion) 23:11, 5. Jun. 2016 (CEST)

Bildnotizen ...[Quelltext bearbeiten]

... und "Notiz hinzufügen"-Knopf fehlen! „Not-Aus“ unter Helferlein ist aber nicht aktiviert! --Andreas Schwarzkopf (Diskussion) 07:40, 8. Jun. 2016 (CEST)

Also ich kenne so ein Gadget nicht, höchstens eins von Schnark. Ich habe aber auch gehört dass soetwas offiziell von Wikimedia in Planung ist. User: Perhelion 09:50, 8. Jun. 2016 (CEST)
Ach zufällig gesehen: c:Commons:Forum #Bildnotizen_... (manchmal ist die Glaskugel mir sehr gnädig) Den deutschen Namen dafür kannte ich nicht, wird auch erst weiter unten in der Beschreibung verwendet c:Help:Gadget-ImageAnnotator/de, dann wechselt der Begriff auch mal zu "Bildvermerk-Werkzeug". Sehr gute Idee einer Software mehrere Namen zu geben.
@Zur Frage: Ich empfehle dir erst mal den gelben Kasten prominent ganz oben durchzulesen, da du ja schon mindestens an 3 weiteren Stellen die Frage gestellt hast. User: Perhelion 10:29, 8. Jun. 2016 (CEST)
Da ich kein IT-Fachmann bin verstehe ich dieses Kauderwelsch nicht. :-( --Andreas Schwarzkopf (Diskussion) 11:04, 8. Jun. 2016 (CEST)

Kategorie ermitteln im Bearbeiten-Modus[Quelltext bearbeiten]

Hallo, (... der entspr. Seite) das scheint wohl nicht so einfach zu sein? Ich habe zwar schon ein Script geschrieben, dass dies per Ajax-API tut und auch eines im View-Modus per HTML-id auslesen kann, allerdings frage ich mich ob das die optimalste Lösung ist? Tatsächlich werden versteckte Kategorien am Ende der Seite angezeigt (somit auch per DOM-Selektor abrufbar), jedoch keine Normalen!? User: Perhelion 18:17, 24. Jun. 2016 (CEST)

Afaik werden alle Kategorien angezeigt, aber (wie z.B. die Abschnitte im Inhaltsverzeichnis) nur die, die im bearbeiteten Abschnit enthalten sind. --nenntmichruhigip (Diskussion) 21:02, 24. Jun. 2016 (CEST)
Hm, also ich sehe hier (Wikipedia:Technik/Werkstatt) nix, auch bei kompletter Seiten-Bearbeitung. tatsächlich bräuchte ich diese bei Abschnitts-Bearbeitung und tatsächlich ist es jetzt im konkreten Fall eine versteckte, also konnte ich diese per Selektor-Abfrage:
var exists = 0;
$('.hiddencats li').children('a').each(function () { // check cats
	if ( this.text && /Non-talk pages that are automatically signed$/.test( this.text ) )
		exists = 1;
});

(tatsächlich gibt es diese Katze nur auf EnWiki) PS: Gibt es nicht auch bei uns einen Bot-Betreiber der hier eine Kat pflegen könnte? (das würde meinem Signing-Script die extra Listen und ggf. eine API-Abfrage im Projekt-ns ersparen) User: Perhelion 21:14, 24. Jun. 2016 (CEST)

Fehlerbehebung in meinen Skripten erforderlich?[Quelltext bearbeiten]

Moinsen. Seit einiger Zeit habe ich, ohne meine Einstellungen verändert zu haben, folgendes Probelm beim Artikelbearbeiten: Bearbeite ich den Gesamtartikel, fehlen über dem BearbFenster sämtliche Formatierungsicons und unter dem Fenster die Sprachauswahl- und Sonderzeichen-Leisten. Bearbeite ich hingegen im selben Artikel nur ein einzelnes Kapitel, stehen diese Hilfsmittel komplett zur Verfügung, wie es seit vielen Jahren in jeder Bearbeitungsweise der Fall war. Woran liegt dieser Unterschied und – vor allem – wie bekomme ich die fehlenden Leisten auch beim Gesamtbearbeitungsfenster zurück? Danke, sagt --Wwwurm 12:07, 26. Jun. 2016 (CEST)
Wenn weitere Angaben zu meinen Konfigurationen u.ä. benötigt werden, bitte sprachlich berücksichtigen: hier spricht eine absolute Softwaretechniknull. :-) 

Hallo, ich hätte ein paar Rückfragen:
  1. Tritt das Verhalten auch auf wenn du abgemeldet bist?
  2. Tritt das Verhalten auf mehreren Geräten auf (anderer PC)?
  3. Tritt das Verhalten bei verschiedenen Skins auf (Monobook, Vector usw.)?
  4. Welchen Skin benutzt du normalerweise?
  5. Gibt es Javascript-Fehlermeldungen? Das fragte PerfektesChaos schon auf FZW.
  6. Wieso hast du den Inhalt in Benutzer:Wahrerwattwurm/common.js? Die zugehörige Hilfeseite empfiehlt eine andere Installation. Zumal deine Version von der „offiziellen“ (Benutzer:Kai Nissen (WMDE)/js/Artikelmonitor.js) leicht abweicht. Das hat aber wahrscheinlich nichts mit deinen Anzeigeproblemen zu tun.
Gruß, --Nfreaker91 12:48, 26. Jun. 2016 (CEST)
zu 1.) Ich bin permanent angemeldet, weiß das also nicht.
zu 2.) Ich nutze zum Schreiben ausschließlich einen PC; das ist allerdings seit ca. 2 Monaten ein neuer, und es könnte hinkommen, dass das auch der Zeitpunkt war, ab dem mein Problemchen aufgetreten ist.
zu 3.), 4.) und 6.) Das weiß ich nicht. Ich habe folgende Monobooks/Skripte laufen, die allesamt von anderen Nutzern bei mir installiert wurden, weil ich ehmt eine IT-0 bin: monobook.css, monobook.js, vector.css, vector.js, common.css, common.js – das müssten alle sein.
zu 5.) Soweit ich das mitbekommen habe, nicht.
--Wwwurm 13:14, 26. Jun. 2016 (CEST)
Nachklapp zu Fehlermeldungen (Deine Frage 5.): Folgendes fand ich unter Browser-Konsole:
Use of "wgNamespaceNumber" is deprecated. Use mw.config instead. (unbekannt)
Use of "wgCanonicalNamespace" is deprecated. Use mw.config instead. (unbekannt)
Use of "wgNamespaceNumber" is deprecated. Use mw.config instead. (unbekannt)
Use of "wgCanonicalNamespace" is deprecated. Use mw.config instead. (unbekannt)
Use of "wgTitle" is deprecated. Use mw.config instead. (unbekannt)
Use of "wgNamespaceNumber" is deprecated. Use mw.config instead. (unbekannt)
Use of "wgCanonicalNamespace" is deprecated. Use mw.config instead. (unbekannt)
Use of "wgNamespaceNumber" is deprecated. Use mw.config instead. (unbekannt)
Use of "wgCanonicalNamespace" is deprecated. Use mw.config instead. (unbekannt)
Use of "wgNamespaceNumber" is deprecated. Use mw.config instead. (unbekannt)
Use of "wgCanonicalNamespace" is deprecated. Use mw.config instead. (unbekannt)
mutating the Prototype of an object will cause your code to run very slowly; instead create the object with the correct initial Prototype value using Object.create browser-places.js:663:3
TelemetryStopwatch: requesting elapsed time for nonexisting stopwatch. Histogram: "FX_PAGE_LOAD_MS", key: "null"
TelemetryStopwatch.jsm:297:0
NS_ERROR_ILLEGAL_VALUE: Invalid arguments nsLivemarkService.js:299:0
  • Ich kann zwar dein Problem noch nicht lösen, aber jetzt einkreisen.
  • Der Bug-Report ist ausschlaggebend.
    • Was davor steht mit is deprecated. Use mw.config instead ist im Moment egal, aber wird dich irgendwann mal einholen. Nicht heute.
    • Ausschlaggebend ist offenbar: Invalid arguments nsLivemarkService.js:299:0
    • Warum das in genau dieser Situation wirksam wird, weiß ich nicht.
  • Du hast anscheinend en:Features of Firefox #Live bookmarks aktiviert.
    • Die stürzen offenbar ab.
    • Ich habe keine Ahnung, was das ist, und benutze es auch nicht.
    • Es scheint sich um eine Art RSS-Feed zu von dir beobachteten Seiten zu handeln.
    • Sieh zu, wie du das irgendwie ausgeschaltet bekommst.
    • Es solle sich um gelbe Pfeile in der Statusleiste handeln.
    • Könnte auch was mit Feed-icon.svg in deinem Firefox-Lesezeichen-Menü sein; „Diese Seite abonnieren“ oder so.
    • Vielleicht hast du auch ein Add-On namens FeedTicker oder Simple RSS Reader (SRR).
  • Der neue Rechner mit neuer Browser-Installation könnte passen; seitdem hast du irgendwie dieses Feature. Gibt es aber eigentlich schon mindestens seit 2004, aber du hattest es bisher wohl nicht aktiviert.
  • Die Wiki-Software hätte eigentlich eher nix damit zu tun. Deshalb bist du wohl auch der einzige Betrofffene.
Viel Spaß --PerfektesChaos 14:09, 26. Jun. 2016 (CEST)
Firefox' „dynamische Lesezeichen“ sind einfach ein ganz normaler RSS-Feedreader mit anderer Darstellung. Da gibt's eigentlich nichts zu aktivieren, kann man (wie normale Lesezeichen) nur nutzen oder seinlassen. Sollte (wie die anderen genannten Meldungen) auf die Darstellung von Websites eigentlich keinen Einfluss haben. --nenntmichruhigip (Diskussion) 16:38, 26. Jun. 2016 (CEST)
@Wahrerwattwurm: Könntest du mal versuchen, eine Seite im privaten Modus (Strg+Shift+P) zum Bearbeiten zu öffnen? War die Konsole beim Seitenaufruf schon offen? Falls nicht nochmal mit offener Konsole neuladen. Meldungen mit Kreuz vornedran sind interessant, solche mit "nur" einem Ausrufezeichen sind wahrscheinlich nicht auslösend, sollten aber auch nicht vorkommen. --nenntmichruhigip (Diskussion) 16:38, 26. Jun. 2016 (CEST)
@Nenntmichruhigip: Moin. Ich weiß zwar weder, was noch weshalb ich es gemacht habe – auch nicht, ob es überhaupt ich war, der etwas gemacht hat zwinker  –, aber jedenfalls funzt die Anzeige der fehlenden Leisten seit gestern, ca. 23 Uhr, wieder. Danke @all, die mir geholfen haben. --Wwwurm 11:20, 27. Jun. 2016 (CEST)

Wikihistory[Quelltext bearbeiten]

APPER hatte einmal verdankenswerterweise ein Tool entwickelt, mit dem die verschiedenen Beiträger zu einem Artikel ausgewiesen werden. Auf der dewiki läuft es seit längerer Zeit nicht mehr, und APPER reagiert nicht, wenn man ihn anspricht (siehe Benutzer Diskussion:APPER/WikiHistory/Programm#Tool läuft bei mir ...). Auf der alswiki läuft es hingegen nach wie vor tadellos. Weiss jemand, wie man das Tool auch auf der dewiki wieder zum Laufen bringen kann? Dank und Gruss, --Freigut (Diskussion) 15:27, 27. Jun. 2016 (CEST)

TeX-Darstellungsproblem.[Quelltext bearbeiten]

Sollte ich hier an der falschen Stelle sein, bitte ich um Entschuldigung und einen Tipp, wo diese Frage wirklich hingehört. :-)

Ich habe ein Problem mit der Darstellung von Text in Formeln. Man betrachte die Wikipedia-Seite Direkte Summe in der Version vom 6. Februar 2016, also hier (ich hoffe, dass dies ein Permalink ist). Die Definiion enthält einen Umlaut (das ü in "für alle..."). Dieser Umlaut wird komplett anders, nämlich zumindest um einiges größer gesetzt als sämtliche "normalen" Textzeichen. Der Befehl \text{} aus dem AMS-Paket wurde beim Experimentieren für die darauf folgende Version ohne Probleme vom Parser und Interpreter angenommen, allerdings war das Satzproblem damit nicht ansatzweise behoben - ü ragte immer noch unter den anderen Buchstaben hervor. \textrm{} sowie \textnormal{} wurden erst gar nicht erkannt. Die englischsprachige Hilfeseite zu TeX zeigt auch den charakteristischen Großdruck von Buchstaben mit Umlauten.

Daher meine Fragen:

1.) Wie kann ich Umlaute im Mathemodus auf Wikipedia unauffällig setzen, ohne kurzfristig mittels </math> in den Textmodus wechseln zu müssen? Dadurch wird nämlich beispielsweise die überaus elegante Anwendung der \left- und \right-Befehle bei den geschweiften Klammern in der Definition der direkten Summe verhindert. (Momentan wird die Größe manuell mittels \Big eingestellt - hässlich.) Ich weiss um die Variante mittels \left\{ ... \right. </math>...<math> \left. ... \right\}, allerdings erscheint mir auch diese Lösung unelegant.

2.) Gibt es irgendwo einen kompletten, sehr knapp gefassten Überblick, was texvcl alles erlaubt? Die Befehle des Paketes amsmath ja anscheinend schon. Kann man auch eigene Pakete einbinden?

3.) Wo liegt mein Fehler? Wenn ich im visuellen Bearbeitungsmodus eine Formel mittels "Bearbeiten" (nicht "Schnell Bearbeiten") bearbeite und den LaTeX-Quelltext verändere, so wird meine Änderung maskiert, in meinem Falle also ein Schrägstrich / durch das Ampersand-Äquivalent ersetzt, was aber an dieser Stelle syntaktisch keinerlei Sinn machte und vom Parser mit einem Syntax-Fehler beantwortet wurde. Oder liegt der Fehler im Quelltext der entsprechenden Funktion für den visuellen Bearbeitungsmodus verborgen?

Rückfragen sind immer willkommen. Vielen Dank im Voraus, --217.237.164.210 20:23, 27. Jun. 2016 (CEST)

Zu 1) Das Problem sollte in MediaWiki behoben werden, damit alle Artikel davon profitieren, da es wohl noch mehr mit Umlauten gibt, siehe dazu H:Phab
Zu 2) Nein, Hilfe:TeX ist auch nicht vollständig. Vielleicht aber auf mediawiki.org (mw:Texvc).
Zu 3) Zu Problemem im VisualEditor kann ich nichts sagen, vielleicht auf Wikipedia:Technik/Text/Edit/VisualEditor/Rückmeldungen anbringen.
Der Umherirrende 10:45, 30. Jun. 2016 (CEST)
Ich besitze momentan und mittelfristig kein Wikipedia-Konto, sodass das persönliche Melden eines Fehlers im Phabricator für mich flachfällt. Wenn Du oder ein anderer das übernehmen will, nur zu! Die englische MediaWiki-Seite zu Texvc ist sehr interessant. So hat man wenigstens Zugriff auf den Quelltext. Das Problem mit dem VisualEditor habe ich hier konstatiert, bis jetzt ist allerdings noch nichts passiert. Mal gucken, ob noch was draus wird. --80.156.181.148 00:08, 6. Jul. 2016 (CEST)

Erweiterung des BKL-Check[Quelltext bearbeiten]

Folgendes Problem: bisher sieht man, wenn man das Helferlein angestellt hat, wo im Artikel auf BKS verlinkt werden. Was man nicht sieht ist, wenn es eine BKL II gibt. Konkretes Beispiel: irgend jemand schreibt einen Artikel zu einem Komponisten. In dem Artikel wird dann der Kollege Karl Marx (Komponist) erwähnt. Der Autor verlinkt in seinem Artikel aber nur auf Karl Marx. Da hat man keine Chance diese Fehlverlinkung zu sehen, außer man klickt alle Verlinkungen durch (was der Artikelerstelle zwar selber machen sollte, aber oft genug eben nicht macht). Könnte man das Helferlein bitte so erweitern, dass das sichtbar wird? Also alle Artikel, die die Vorlage Dieser Artikel oder die Vorlage BKH werden in anderen Artikel - vielleicht grün? - farblich unterlegt? MfG --Informationswiedergutmachung (Diskussion) 19:35, 29. Jun. 2016 (CEST) .

Das müsste doch mit Benutzer:Schnark/js/bkl-check möglich sein. -- FriedhelmW (Diskussion) 22:07, 29. Jun. 2016 (CEST)
Nein, das benutze ich, das funktioniert nicht. --Informationswiedergutmachung (Diskussion) 22:24, 29. Jun. 2016 (CEST)
Das Script müsste manuell alle verlinkten Seiten überprüfen. Bei der normalen BKL-Anzeige liefert die Software die Info gleich im Quelltext mit, aber von unseren BKL II-Vorlagen hat die Software keine Ahnung. Sicher möglich, wäre aber mit erheblichem Traffic verbunden. --mfb (Diskussion) 23:53, 29. Jun. 2016 (CEST)
Was ist wichtiger? Traffic oder ordentlich verlinkte Seiten? Und das Skript muss nur alle Seiten überprüfen, die die genannten Voorlagen haben, nicht alle. --Informationswiedergutmachung (Diskussion) 23:57, 29. Jun. 2016 (CEST)
MEn geht es dabei eher um den Traffic und die Performance beim Benutzer. Wenn das Helferlein das machen würde, würde ich es nicht nutzen, weil mir das viel zu lange dauern würde. Ok, mach ich eh nicht, weil ich aus der Zeit, als das Gadget noch nicht ausschliesslich mit CSS funktionierte, identisches mit anderer Farbe in meiner global.css stehen habe. Deshalb gibt es Schnarks BKL-Check für diejenigen, die sich das antun wollen. --nenntmichruhigip (Diskussion) 09:16, 30. Jun. 2016 (CEST)
Jeder BKL-Checker der JavaScript verwendet und nach Kategorien der Links sucht, kann auch nach Vorlagen suchen, dafür müsste man es nur entsprechend erweitern. Da Links auf BKL II aber nicht falsch sein müssen und damit auch nicht umbedingt aus Artikeln verschwinden müssen, wird es wohl weniger Bestrebungen der aktuellen Autoren geben, dies einzubauen (Anders gesagt: Hinweise, die man nicht entfernen kann, werfen nur Fragen auf und lässt man daher). Man kann diese Version auch auf Templates ausdehen oder man nimmt Schnarks Variante. Es Bedarf aber eines Forks (den ich nicht anbieten möchte). Der Umherirrende 10:41, 30. Jun. 2016 (CEST)

Benutzer:Flominator/BklRedir.js kann auch BKLs hinter Weiterleitungen zeigen. --Flominator 09:45, 30. Jun. 2016 (CEST)

Weiterleitungen werden seit dem 11. Februar bereits als BKL markiert. Der Umherirrende 10:41, 30. Jun. 2016 (CEST)
@Flominator: Also müßte ich jetzt Karl Marx farblich unterlegt sehen, nachdem ich dein Skript in meine common.js importiert habe? Tut sich aber nix. Woran kann es liegen? MfG --Informationswiedergutmachung (Diskussion) 14:20, 30. Jun. 2016 (CEST)
@Informationswiedergutmachung: Nein, du müsstest auf der linken Seite ein Fenster haben, in dem drin steht, dass Marx eine WL auf Karl Marx ist (solange du einen Artikel bearbeitest(!), in dem Marx verlinkt ist und sich der Artikel im ANR befindet) --Flominator 14:33, 30. Jun. 2016 (CEST)
Da war ein Fenster, ab da stand nichts drin... --Informationswiedergutmachung (Diskussion) 14:38, 30. Jun. 2016 (CEST)

Anmelden mit mobiler Version auf der Hauptseite unmöglich[Quelltext bearbeiten]

Hallo, ich weiß nicht, ob das der richtige Ort für die Frage ist, aber wenn ich von einem Mobiltelefon (Mobile Version) aus versuche mich auf der Hauptseite anzumelden, kommt jedes mal eine Fehlermeldung. Wenn ich mich von einer anderen Seite aus anmelde (als Test: Kulturapfel), funktioniert es einwandfrei. Aber wenn ich in die Klassische Ansicht wechsle (wozu ich allerdings Cookies aktivieren muss, warum auch immer), kann ich mich auch von der Hauptseite aus anmelden.

Wenn's weiterhilft: das betroffene Gerät ist ein Windows Phone Lumia 535, Software Windows Phone 8.1 Update, Browser Internet Explorer unbekannter Version, WLAN. Könnte jemand nachsehen, ob's an der Software liegt? Ich hatte nicht die Möglichkeit, dies an einem gleichartigen Telefon auszuprobieren. LG, --Lesendes Okapi (Diskussion) 20:21, 4. Jul. 2016 (CEST)

@Lesendes Okapi: Was genau ist denn die Fehlermeldung? Verstehe ich es richtig, dass Cookies in der mobilen Ansicht im Browser deaktiviert sind? --AKlapper (WMF) (Diskussion) 23:05, 4. Jul. 2016 (CEST)

Danke, AKlapper (WMF), es lag tatsächlich an den Cookies. Wenn ich sie aktiviere, funktioniert auch die mobile Version. Muss ich jetzt für immer und ewig die Cookies aktivieren? :( --Lesendes Okapi (Diskussion) 14:29, 5. Jul. 2016 (CEST)

Wie sollen Suche die Fragezeichen behandeln?[Quelltext bearbeiten]

Das Wikimedia Foundation Sucheteam kürzlich entdeckt dass Suchanfragen, die mit einem Fragenzeichen (zum Beispiel “Wie alt int Tom Cruise?”), manchmal erfolglos erschien. Dieses ‘Null Resultat’ ist die Art und Weise dem Wikimedia Foundation Sucheteam wie die Menschen mit den Suchergebnissen zufrieden sein. Das Sucheteam schlägt das Verhalten der Wikimedia Suche ändern vor, aber es möchte Feedback von den Gemeinden zu helfen, eine intelligente Entscheidung machen. Wenn Sie wissen möchten, wie Suche funktioniert, oder sehen dieses als eine mögliche Unterbrechung für Ihre Arbeit, lernen mehr über diese Änderung bitte und lassen die Ingenieure Ihre Gedanken kennen. Vielen Dank. CKoerner (WMF) (Diskussion) 23:44, 5. Jul. 2016 (CEST)

Abschnitt "Sprachen" ganz nach oben vor Abschnitt "Mitmachen" ?[Quelltext bearbeiten]

Hallo, ich suche seit geraumer Zeit nach einer Möglichkeit den Abschnitt "Sprachen" ganz nach oben vor den Abschnitt "Mitmachen" im Menüband links im Skin Vector zu setzen. Ich muss sehr oft zu anderen Sprachversionen schalten. Ich habe jetzt unter Einstellungen die "Kompakten Sprachlinks" aktiviert, was eine große Hilfe darstellt. (Leider funktionieren die "Kompakten Sprachlinks" nur in der deutschen Version. Sobald ich eine fremdsprachige Version aufrufe, sind sie nicht mehr verfügbar, obwohl ich ein globales Benutzerkonto habe!?) Wenn ich jetzt die "Kompakten Sprachlinks" noch ganz nach oben links versetzen könnte, wäre mir sehr geholfen. Leider kenne ich mich mit CSS nicht aus. Ich weiß also nicht, was ich auf meine global.js- oder global.css-Seite schreiben müsste, um das Anzeigeverhalten entsprechend zu ändern. Kann mir jemand helfen? --Wolfgang1018 (Diskussion) 19:01, 7. Jul. 2016 (CEST)

Könnte mir vorstellen, dass das für manche hier überraschend ist, aber ja, das geht auch nur mit CSS: #mw-panel { display: flex; flex-direction: column; } #p-lang { order: -1; } :-) --nenntmichruhigip (Diskussion) 20:25, 7. Jul. 2016 (CEST)

Wikipedia.org portal update[Quelltext bearbeiten]

Hallo,

Hilf bitte mit, in deine Sprache zu übersetzen. Danke!

The Wikimedia Foundation Portal team has recently completed an A/B test on the Wikipedia.org portal. These tests were to see if a new design would be easier to navigate. This design added a dropdown that contained all the languages by article count.

The test results found that visitors were more likely to click through to a link. With the new design there was a lower amount of 'non-action' on the page. We also tested the page with many Wikipedia users. We received comments that the new page design was pleasing and less cluttered.

With this information, we would like to promote this into production on the Wikipedia.org portal. We would like to ask the community for feedback and suggestions.

Vielen Dank und prost aus dem Discovery-Portal Team! CKoerner (WMF) (Diskussion) 23:50, 12. Jul. 2016 (CEST)

Eine schnelle Uebersetzung: / A quick translation:
Das Portal-Team der Wikimedia Foundation hat vor kurzem auf dem Wikipedia.org-Portal einen A/B-Test durchgefuehrt. Dieser Test wurde gemacht um herauszufinden ob ein geaendertes Design einfacher zu navigieren waere. Das geaenderte Design bietet eine Auswahlliste, die alle Sprachen (sortiert nach Anzahl der Artikel) enthaelt.
Die Test-Ergebnisse (in Englisch) zeigen dass Besucher oefter auf diese Links klickten und dass es weniger 'Nicht-Aktionen' auf der Seite gab. Die Seite wurde mit vielen Wikipedia-Nutzern getestet, und wir haben Kommentare erhalten dass das neue Seiten-Design als angenehm empfunden wird.
Aufgrund dieser Erfahrungen moechten wir diese Designaenderung fuer alle Nutzer auf dem Wikipedia.org-Portal durchfuehren. Wir bitten die Nutzergemeinschaft um Rueckmeldungen und Vorschlaege.
--Malyacko (Diskussion) 12:38, 14. Jul. 2016 (CEST)

Portal:Luftfahrt/Überarbeiten[Quelltext bearbeiten]

Wäre es möglich, dass man dort den Button für die Signatur und Zeitstempel integriert..?--MBurch (Diskussion) 18:52, 15. Jul. 2016 (CEST)

vgl. Wikipedia:Umfragen/Unterschriften-Icon in Bearbeiten-Werkzeugleiste--Rik VII. my2cts Radsportler.svg  16:13, 8. Aug. 2016 (CEST)

Warum sind die Beiträge von Skibz777 verschwunden?[Quelltext bearbeiten]

Mir ist aufgefallen, dass Skibz777 keine Beiträge mehr gelistet hat (das war vorher anders). Man sieht aber seine Mitarbeit in der Versionsgeschichte von Birdemic: Shock and Terror. Könnte es etwas damit zu tun haben, dass die Bearbeitungen damals nicht in dewiki, sondern in enwiki gemacht wurden? Der Artikel wurde ja dann importiert. Aber selbst wenn dem so ist, dass importierte Beiträge nun nicht mehr in Skibz777 aufgeführt werden, dann muss sich das vor kurzem geändert haben. Am 24. Juli hatte er noch Beiträge. --Jobu0101 (Diskussion) 10:39, 29. Jul. 2016 (CEST)

Übrigens: Bei WikHead sieht man den Beitrag in Birdemic: Shock and Terror in dessen Benutzerbeiträgen, obwohl dieser genau so importiert wurde. Mit dem Import kann das also nicht zusammenhängen. --Jobu0101 (Diskussion) 10:42, 29. Jul. 2016 (CEST)
Beim Import gab es das Konto von WikHead bereits in der deutschsprachigen Wikipedia und die Beiträge haben eine User-Id zugeordnet bekommen. Das Konto des anderen Benutzers wurde erst später angelegt, daher hat es keine User-Id. Da die Suche über die User-Id schneller geht wurde dies irgendwann auf der Spezialseite mal geändert. Es handelt sich daher um phab:T36873. Warum dir die Spezialseite zum 24. Juli noch Beiträge angezeigt hat, kann ich nicht herausfinden. Änderungen dort habe ich nicht gefunden. Der Umherirrende 16:37, 21. Aug. 2016 (CEST)

Javascript-Problem Wikipedia-Aufruf mobil?[Quelltext bearbeiten]

Seit einigen Tagen bleiben in meinem Android-Browser (2.3.6 auf Samsung Galaxy S plus) mobile Wikipedia-Seiten (z.B. https://de.m.wikipedia.org/wiki/Wikipedia:Hauptseite) beim Laden irgendwann hängen: Text und Bilder laden zwar und lassen sich scrollen, der Ladevorgang wird aber nicht abgeschlossen, denn das Laden-Symbol dreht sich weiter. Es funktionieren dann weder Verweise/Links noch die Zurück-Taste noch das Suchfeld noch ein Stopp/aktualisieren/Aufruf von Favoriten. Dieses Problem tritt nur bei Wikipedia auf, andere Seiten funktionieren problemlos. Wenn ich Javascript deaktiviere, verschwindet das Problem. Deshalb vermute ich, dass eine Javascript-Bibliothek oder eine Javascript-Funktion aufgerufen wird, die einem (zugegeben veralteten) Mobilbrowser Probleme bereitet und diesen quasi blockiert. Leider fehlen mir die Analysemöglichkeiten, um die Sache näher einzugrenzen. Welche Javascript- oder z.B. jquery-Funktion(en) könnte(n) das sein, und sind sie für Wikipedia unbedingt erforderlich? Vielen Dank für Kommentare und Feedback. (nicht signierter Beitrag von Clapham44 (Diskussion | Beiträge) 11:47, 8. Aug. 2016 (CEST))

[Idea] Wikidata descriptions to help disambiguate article topic on mobile web[Quelltext bearbeiten]

Hello German Wikipedia, and apologies for posting in English. This is a little update to share with you a suggestion around Wikidata: The Reading team would like to help readers learn faster about the topics they are browsing on our mobile site, by displaying Wikidata descriptions underneath article title. This has been the case on apps for a while now, and the team would like to move with the same practice to mobile web, and help our mobile readers, by using content from a Wikipedia sister project. This change has already been enabled on Catalan and Polish Wikipedias. There is a page the describes the idea and the details here . Please check to learn more about the rationale and the details of the suggested change. Grüße vom --Melamrawy (WMF) (Diskussion) 18:14, 12. Aug. 2016 (CEST)

Login length being extended on Tuesday[Quelltext bearbeiten]

I have good news: A few years ago, the login length was reduced from 180 days (on most WMF projects) to just 30 days. From my POV, this means 12 opportunities to accidentally get logged out mid-edit per year.

The login length is being extended on Tuesday, 16 August at 15:00 UTC (8:00 a.m. PDT). After that, the next time you login, if you choose the option to stay logged in, you'll be logged in for a full year. This has been requested for more than two years and is finally ready to go.

There is some more information at mw:"Keep me logged in" extended to one year. There is information on that page about how to automatically display the length for users in the message on the login page. If you have other questions, please feel free to {{Ping}} me. Whatamidoing (WMF) (Diskussion) 21:52, 12. Aug. 2016 (CEST)

@Whatamidoing (WMF): What is this exactly about? I've not been logged out since the last force-logout a few months ago (when MediaWiki sometimes not actually logged out some users when they wanted to and everyone had to be logged out to make sure no one is unintentionally left logged in). But I remember there was a ~30 day timeout when I did not check "keep me logged in". So, is this about having "keep me logged in" checked, having it checked but beeing inactive, having it not checked, or something even different? --nenntmichruhigip (Diskussion) 14:28, 13. Aug. 2016 (CEST)
@Nenntmichruhigip: This is about having "keep me logged in" checked. I do not know what "having it checked but being inactive" means... --Malyacko (Diskussion) 14:41, 14. Aug. 2016 (CEST)
I have this checked, but am not beeing logged out after 30 days. So to me it seems the "good news" is under some wrong premise. But I'm usually doing something (i.e. looking at watchlist) before those 30 days are over. Now about the "having checked but inactive" thing: I suspect that the timeout meant above might be if the box is checked but the user doesn't do anything, i.e. is in some strange area without internet for 30 days. --nenntmichruhigip (Diskussion) 19:23, 14. Aug. 2016 (CEST)
What happens when you close/quit your web browser? Whatamidoing (WMF) (Diskussion) 22:53, 15. Aug. 2016 (CEST)
My Browser is set to keep session cookies when closed, so I can't close my web browser the way you mean ;-) --nenntmichruhigip (Diskussion) 12:04, 16. Aug. 2016 (CEST)

Bilder beschriften - Panoramabild[Quelltext bearbeiten]

Liebe Techniker, wir möchten gern ein Panoramabild einer Küste von See her gesehen beschriften. Es gibt Tausende Artikel, für die ein solches Panoramabild ein hoher Informationsgewinn wäre (und vermutlich noch viel mehr Fälle, wo Bildbeschriftungen ebenfalls bei der Verständlichkeit helfen).

Die Fotowerkstatt hat sich viele Gedanken dazu gemacht. Mit Vorlage:Annotation (User:Smith609) ist eine tolle Lösung entstanden. Leider ist die Erzeugung des Bildes viel zu komplex, und der Code im Artikeltext statt "irgendwie in der Bilddatei":


Café Sorgenfrei

Für eine sinnvolle Benutzung durch WP-Autoren bräuchte man:

  • ein Tool zur Unterstützung bei der Erzeugung solcher Beschriftungen
  • eine Lösung, wie man den Code "irgendwie in die Bilddatei" bekommt

Habt Ihr eine Idee? Gruss, --Markus (Diskussion) 04:34, 20. Aug. 2016 (CEST)

Das Panorama ist breiter als mein Browserfenster und die letzten Bildteile stehen untereinander. So geht das nicht. -- FriedhelmW (Diskussion) 18:40, 20. Aug. 2016 (CEST)
@Markus Bärlocher::
  • Wenn Du den Code unbedingt in der Bilddatei haben möchtest, dann müsstest Du ihn in diese Grafki-Datei reinschreiben. Verlinkungen sind dann natürlich leider nicht mehr möglich.
  • Alternativ könntest Du eine Vorlage basteln, in der dann die Annotation in WikiText drin steht und die Du dann einfach in beliebige Artikel einbinden kannst.
Die Wiki-Text-Umsetzung mit den mehrfachen Bildausschnitten ist jedoch wirklich etwas suboptimal und in diesem Fall auch die falsche Einsatzart von {{Annotiertes Bild}}. Das sollte wohl eher so aussehen:
Ich bin mal so frei, das im Artikel auszutauschen. // Martin K. (Diskussion) 13:40, 21. Aug. 2016 (CEST)
@FriedhelmW, Markus Bärlocher: MagentaGreen war damit offensichtlich nicht ganz einverstanden. Die Diskussion geht jetzt also im zugehörigen Artikel weiter. // Martin K. (Diskussion) 10:56, 22. Aug. 2016 (CEST)

Da sich die Diskussion im Artikel gerade etwas festgefressen hat, wäre es schön, wenn sich dort der ein oder andere mit technischem Hintergrundmal zu Wort melden könnte. // Martin K. (Diskussion) 12:18, 23. Aug. 2016 (CEST)

Liebe Techniker, danke für die interessanten Lösungsvorschläge. Nun geht es darum, ein für den WP-Autor simpel zu benutzendes Tool zu schaffen: Klick ins Bild setzt den Cursor, Text eingeben, ggf. Schriftgrösse/Farbe wählen, fertig.
Die dabei entstehenden Metadaten werden in eine Datei geschrieben, die mit dem Bild verlinkt wird. Jede Sprachversion erzeugt eine eigene Metadatei (vielleicht ein neuer Commons-NR?). Die Herausforderung wird sein, die Position und die Schriftgrösse relativ an unterschiedlich skalierte Bilder anzupassen...
Im Artikeltext soll dann nur das Bild und die passende Metadatei eingebunden werden.
Und wenn es ganz komfortabel werden soll: Text horizontal/vertikal bündig machen, Zeilenumbruch, zentriert/links/rechtsbündig.
Gruss, --Markus (Diskussion) 12:23, 26. Aug. 2016 (CEST)
@Markus Bärlocher: Natürlich wäre ein solche WYSIWYG-Editor hier (wie bei vielen anderen Vorlagen auch) hilfreich. Idealerweise würde man so etwas in den VisualEditor integrieren. Allerdings ist der Bau (und die Wartung eines solchen Tools) ziemlich aufwändig (und wäre zu mindest im Fall des VE bei der Foundation angesiedelt). So was wird sich bestenfalls langfristig realisieren lassen. Und wenn man sich ansieht, wie selten die Vorlage Annotiertes Bild bisher verwendet wird, gibt es sicherlich dringendere Baustellen.
oben links
unten zentriert
oben rechts
Ein annotiertes Bild
Es ist bereit s jetzt so, dass sich einfach Beschriftungen mit relativ wenig Code einbinden lassen. Und ich habe die Vorlage {{Annotation}} (die die Labels steuert) mittlerweile so erweitert, dass sich die Texte mit den parametern valign und halign vernünftig ausrichten lassen:
{{Annotiertes Bild
| image = Pacific Ocean - panoramio - ---=XEON=--- (2).jpg
| image-width = 400
| float = right
| annotations = 

{{Annotation|200|150|oben links|valign=-1|halign=-1|font-size=16 | font-weight=bold | color=#FFF}}

{{Annotation|200|150|unten zentriert|valign=1|halign=0|font-size=16 | font-weight=bold | color=#FFF}}

{{Annotation|200|150|oben rechts|valign=-1|halign=1|font-size=16 | font-weight=bold | color=#FFF}}

| caption =Ein annotiertes Bild
}}
// Martin K. (Diskussion) 14:03, 26. Aug. 2016 (CEST)

Für Imagemaps gab es vor Jahren mal ImageMapEdit von Benutzer:Dapete. Vielleicht hält sich der Aufwand einer Anpassung für Annotations ja in Grenzen. Daneben gibt es noch das Teil, mit dem man die Annotations auf Commons einfügt. Vielleicht könnte man das ja auch mit relativ geringem Aufwand anpassen. --Flominator 14:54, 27. Aug. 2016 (CEST)

Aktueller Stand[Quelltext bearbeiten]

Technische Ergebnisse habe ich in Hilfe:Bilder/beschriftete Panoramabilder zusammengefasst, damit man sie später mal wiederfinden (oder weiter daran arbeiten kann). Martin, bist Du noch dran? Gruss, --Markus (Diskussion) 16:49, 29. Aug. 2016 (CEST)

Grundsätzliche Fragen zu CSS und Wikitext[Quelltext bearbeiten]

Da ich (als jemand, der sich mit HTML/CSS/JS eigentlich ziemlich fit ist) mir gerade bei der Renovierung der diesjährigen WLM-Seite mal wieder ziemlich die Zähne an Wikitext ausbeiße, möcht ich mal ein paar grundsätzliche Fragen stellen:

  1. Gibt es eine Möglichkeit ganz normales CSS in eine Wikitext-Seite einzubinden? Damit meine ich nicht die Inline-Styles in einzelen HTML Elements (die besitzen ja weder Selektoren noch Media-Queries) und auch nicht die Eintragung in der eigenen common.css (die wären ja nur für mich sichtbar) bzw. der projektglobale MediaWiki:Common.css. Das in letztere tatsächlich das komplette CSS für die Hauptseite steht, lässt mich befürchten dass das es keine solche Möglichkeit gibt?!
    Falls das tatsächlich so ist, würde ich vorschlagen darauf hinzuwirken, das zu ändern und irgendeine Möglichkeit zu schaffen seitenindividuelle Style-Sheets einzubinden (und sei es nur solche, die einem speziell geschützten Namensraum stehen). Immerhin braucht man für jede Seite, die nicht 100% den Standardlook haben soll CSS. Und Inline-Style blähen einerseits den Code völlig unnötig auf und funktionieren andererseits spätestens dann nicht mehr, wenn es um Responsive Webdesign geht. Alles (wie das Haupseiten-CSS in die globale CSS-Datei zu pumpen ist sicher auch keine Lösung)
  2. Gibt es eine Möglichkeit Links oder WikiLinks auf Bilder zu legen? Ersten Tests zur Folge, werden Wikilinks ignoriert, sobald in ihnen irgendeine Grafik mit Wikitext eingebunden wurde. Gibt es da einen Workaround?
    • Nachtrag: HAbe gerade rausgefunden, das der Wikitext für Bilder einen Parameter "link" akzeptiert. Von daher ist diese Frage eigentlich beantwortet.
  3. Gibt es eine Möglichkeit Bilder ohne die WikiSyntax einzubinden?
  4. Gibt es eine Möglichkeit dieses Icon hinter externen Links loszuwerden? Ich brauche solche Links zum Ansteuern des Hochladeassistenten mit verschiedenen Parametern. Und das Icon sieht echt hässlich aus, wenn es hinter einem Button steht.
  5. Gibt es irgendwo eine Liste, welche HTML-Tags von Media-Wiki unter welchen Voraussetzungen druchschleift und weche nicht?

Wäre toll, wenn ihr mir da weiterhelfen könntet. // Martin K. (Diskussion) 14:06, 21. Aug. 2016 (CEST)

  1. „ganz normales CSS in eine Wikitext-Seite einzubinden“ (meint: style-Rules/sheet statt inline)
    • Im Moment definitiv nicht.
    • Ob vielleicht irgendwann mal – steht in den Sternen.
    • Wenn jemals, dann muss Wechselwirkung zwischen Teilen der Seite und eingebundenen Vorlagen ausgeschlossen werden.
    • Für jetzt: Vergiss es. Ist Absicht, dass das nicht geht.
  2. „WikiLinks auf Bilder“
    • Im Prinzip ja.
    • Urheberrechte der Bild-Ersteller sind zu beachten; sonst wird dir das wieder entfernt.
  3. „Bilder ohne die WikiSyntax einzubinden“
    • Wird mit voller Absicht verhindert.
    • Gründe: Schadsoftware, Zählpixel, Urheberrechte der Bild-Ersteller
  4. „Icon hinter externen Links loszuwerden“
    • Im Prinzip ja.
    • Fraglich ist, warum du überhaupt eines sehen kannst.
    • Wie genau lautet denn die Verlinkung?
  5. „welche HTML-Tags von Media-Wiki“
    • H:Tags
    • „weche nicht?“ – dort: Verbotenes HTML
VG --PerfektesChaos 14:32, 21. Aug. 2016 (CEST)
Danke für die schnelle Antwort, auch wenn sie leider meine Befürchtungen bestätigt.
Aktuell sieht der Link so aus. Ich musste leider diese umständliche From wählen, weil ich nur so URL-Parameter übergeben kommte. Oder gibt es da einen anderen Weg?!
[{{fullurl:c:Special:UploadWizard|campaign=wlm-de-bb}} <span class="mw-ui-button" style="width:20em;">Brandenburg&nbsp;»</span>]
// Martin K. (Diskussion) 14:41, 21. Aug. 2016 (CEST)
  • Soso, das geht ja nach Commons.
  • Und außerdem sind es keine Verlinkungen mittels <a>, sondern es sind href= von <area> in der imagemap.
  • Wir hätten da zwar gewisse Möglichkeiten, aber die greifen alle nicht auf <area>.
    • @Umherirrender: Hast du irgendeine Meinung dazu? Entlinkt kaum amüsiert.
VG --PerfektesChaos 15:02, 21. Aug. 2016 (CEST)
Oder mal anders gefragt:
  • Wenn du auf dieser Seite sowieso nur einen deutschsprachigen Hochladeassistenten für Commons-Bilder betreiben möchtest –
  • warum gliederst du nicht einfach diese Unterseite hier aus, verlinkst nur darauf,
  • und legst sie an geeignetem Ort auf Commons an?
  • Dann ist sie dort lokal, die Links auch, und einen Icon gibt es deswegen auch nicht.
VG --PerfektesChaos 15:41, 21. Aug. 2016 (CEST)
Die Links in der Imagemap haben kein Icon, die Kästen daneben sind normale Kästen außerhalb der area, da hilft ein plainlinks. Der Umherirrende 16:22, 21. Aug. 2016 (CEST)
Ja, es ging um die Buttons, nicht um die Image-Map. Danke für das einfügen der CSS-Klasse. // Martin K. (Diskussion) 16:51, 21. Aug. 2016 (CEST)
@PerfektesChaos: Es gibt auf Commons ja durchaus ein gespiegelte Seite. Aus Gründen der Nutzerführung, wollen wir nur so viel wie möglich lokal hier in der Wikipedia halten. Schließlich ist die Idee hinter WLM ja gerade, neue Mitarbeiter für unser Projekt zu gewinnen, und da sollte man sie nicht woanders abgertigen. Deshalb werden wir übrigens auch die externe Website abschalten und die URL wikilovesmonuments.de hierher ins Wiki routen. // Martin K. (Diskussion) 16:51, 21. Aug. 2016 (CEST)

Nochmal zu der Sache mit dem CSS. Wenn das wirklich aktuell nichts außer Inline-Styles möglich sind, sollten wir da wirklich mittelfristig auf eine Lösung hinarbeiten. MMn ist es nämlich ziemlicher Unsinn, dass z.B. die nur auf der Hauptseite verwendeten Styles bei jeder einzelnen Wiki-Seite mit ausgeliefert werden müssen.

Natürlich kann man das CSS nicht einfach für alle frei geben – ein Selectoren-Fehler und die ganze Seite ist verunstaltet. Aber es gäber ja da durchaus Wege, die den Sicherheitsbedenken Rechnung tragen und trotzdem den Einsatz ordentlicher Style-Sheets ermöglichen:

  1. Die Auslagerung solcher StyleSheets in einen eigenen Namensraum, der grundsätzlich nur von Admins bearbeitet werden darf. Die Einbindung würde dann mittels einer speziellen Vorlage erfolgen.
  2. Freie Einbindbarkeit eines StyleSheets mittels einer Vorlage, die jedem Selektor ein Selektor vorangestellt, der dafür sorgt, dass nur der Inhaltsblock der jeweiligen Seiten von diesen Style betroffen ist. Als Hauptselektor konnte man hier die jeweilige Seitenkennnummer als Id oder Klasse im Boda-Tag ausgeben.

Natürlich würden beide Wege einen Eingriff in MediaWiki erfordern. Aber angesichts der Möglichkeiten, die uns ordentliche StyleSheets bieten und angesichts des aktuellen Inline-Style-Gewurschtels wäre das echt sinnvoll. // Martin K. (Diskussion) 16:51, 21. Aug. 2016 (CEST)

Ich vermute, dass das von dir vorgeschlagene Verfahren den Seitenaufbau merklich verlangsamen würde. Schließlich müssen mehr Daten vom Server geholt werden. Die Common.css wird nur einmal benötigt und steht dann im Browsercache. -- FriedhelmW (Diskussion) 20:34, 21. Aug. 2016 (CEST)
Es ginge hier ja i.d.R. um maximal eine zusätzlich Anfrage. Und die halte ich für vertretbar, im Vergleich zur Holzhammer-Methode sämtliches CSS von x Unterseiten in die common.css zu stopfen. // Martin K. (Diskussion) 21:34, 21. Aug. 2016 (CEST)
Ideen gibt es schon: phab:T483 oder phab:T37704. Der Umherirrende 20:39, 21. Aug. 2016 (CEST)
Danke für den Hinweis. Ich werd' mir das mal anschauen. // Martin K. (Diskussion) 21:34, 21. Aug. 2016 (CEST)

Link auf Nutzerfunktionsseiten?[Quelltext bearbeiten]

Ich hätte noch eine Frage: Ist es möglich einen Link so zu setzen, dass er z.B. für jeden Nutzer auf die eigene Datei- oder Beitragsliste (auf Commons) führt? Eine Variable mit dem Nutzernamen scheint es ja nicht zu geben... // Martin K. (Diskussion) 22:34, 24. Aug. 2016 (CEST)

Ja, Special:MyUploads bzw. Special:MyContributions, ggf mit Interwikipräfix. --nenntmichruhigip (Diskussion) 14:19, 25. Aug. 2016 (CEST)
Super. Danke! // Martin K. (Diskussion) 17:24, 25. Aug. 2016 (CEST)

Unterscheidung Desktop-Version/Mobil-Version?[Quelltext bearbeiten]

Und noch eine Frage:

Ist es möglich mit Wikitext zu unterscheiden, ob ein Inhalt in der Desktopversion der Wikipedia, oder in der Mobilversion angezeigt wird? Hintergrund ist, dass die aktuelle WLM-Seite in der Mobilversion ziemlich zerstört aussieht, wenn das Browerfester zu eng ist. Und ohne Media Queries (s.o.) wüsste ich nicht, wie ich das mit Inline-Styles korrigieren sollte, ohne dass die Änderungen gleichzeitig auch in der Desktop-Version angezeigt werden. // Martin K. (Diskussion) 13:28, 3. Sep. 2016 (CEST)

@Martin Kraft:
  • Du kannst von Desktop-Darstellungen abspecken: Wikipedia:Technik/Mobil #Seitendarstellung.
  • Betont interaktive Oberflächen entwickelt man heutzutage so, dass sie auf Mobil klappen; dann funktionieren sie auf den breiteren Desktops allemal und könnten dort ggf. automatisch in die Breite gehen.
VG --PerfektesChaos 15:11, 3. Sep. 2016 (CEST)
@PerfektesChaos: Danke für den Link. Wie man heutzutage mobile-first Websites entwickelt ist mir geläufig – immerhin verdiene ich seit über 10 Jahren meine Brötchen damit und unterrichte es auch an einer Hochschule.
Nur dummerweise ist man in dieser Hinsicht ziemlich aufgeschmissen, wenn man weder Medie Queries noch vernünftiges CSS, sondern ausschließlichInline-styles verwenden kann. Das Ein- und Ausblenden mittels der Klasse nomobile ist zwar besser als nichts, hilft letztlich im Hinblick auf echte Responsiveness und fluide Layouts auch nicht wirklich weiter.
Um mal beim konkreten Beispiel zu bleiben: Die WLM-Seite sitzt ja in einem doppelten Container, der auf dem Desktop ja durchaus seine Berechtigung hat. Dieser besteht aus zwei divs jeweils mit einem padding. In der schmalen Smartphone-Ansicht führt das nun leider dazu, dass sich die beiden Paddings und ggf. noch Einrückungen und float-Element im Inhalt so blöd aufaddieren, dass keine vernünftige Breite mehr für den eigentlichen Inhalt übrige bleibt.
Hätte ich Media Queries, würde ich einfach einen Breakpoint setzen, ab dem die horizontalen Paddings einfach wegfallen bzw. so reduziert werden, dass die Kästen bis zum Rand gehen und genügen Platz für den Inhalt übrige bleibt (Mobile-First würde man das natürlich genau andersrum machen, aber die Desktop-Seite ist ja hier schon da). Dummerweise habe ich aber keine Media-Queries und nichtmal auf die Klassen-Unterschiede im Mobile-Rendering reagieren. Und class="nomobile" bringt mich im Bezug auf das Padding umgebender Container leider auch nicht weiter.
Ehrlich gesagt bin ich ziemlich ratlos. Die einzige funktionierende Möglichkeit, die mir aktuell einfallen würde, wäre ein entsprechende CSS global in die MediaWiki:Common.css schreiben zu lassen. Aber das kann es ja auch nicht sein, oder? Habt Ihr vielleicht irgendeine Idee? // Martin K. (Diskussion) 15:55, 3. Sep. 2016 (CEST)
Es wird sich wohl niemand darauf einlassen, für genau eine einzige von zehn Mllionen aktiven Seiten ein eigenes CSS in jede erdenkliche aufrufbare Seite zu injizieren.
Aaaalso: Erst ein steilisches neus Konzept basierend auf mobil in Testumgebung entwickeln, und das dann für alle Umgebungen produktiv stellen.
Padding ist sowieso Platzverschwendung. Aber wenn man vorher schon weiß, dass man mit einer simplen, bewusst reduzierten Wiki-Sprache arbeitet, dann kann man ja für den Desktop auch breite Padding-Streifen horizontal wie vertikal durch Tabellenstreifen dynamisch generieren, die width und class für nomobile kombinieren. Der Desktop funktioniert allerdings auch ohne petting.
Pfiffig eingesetztes float flutscht übrigens problemlos bei jeder Breite.
VG --PerfektesChaos 16:08, 3. Sep. 2016 (CEST)
Tabellen? Oje - das klingt nach HTML anno 1999 ;( // Martin K. (Diskussion) 16:44, 3. Sep. 2016 (CEST)
Das pfiffig "gesetzte float" der normalen Thumbnails sorgt übrigens dafür, dass der Text auf dem Smartphone in 2-Buchstaben-Zeilen zerfällt. Es ist echt ein Elend... // Martin K. (Diskussion) 17:54, 3. Sep. 2016 (CEST)
Ich hab das Padding jetzt mal in vw-Einheiten definiert. Das ist zwar nicht wirklich hübsch, verhindert auf dem Smartphone aber das Schlimmste.
Mittelfristig muss da aber wirklich eine Möglichkeit zur Einbindung von eigenem CSS herbei. So wie es jetzt ist, kann man im mobilen Zeitalter wirklich nicht mehr arbeiten. // Martin K. (Diskussion) 17:54, 3. Sep. 2016 (CEST)

Vorlagenparameter mit HTML-Tags wird ignoriert[Quelltext bearbeiten]

Beim annotierten Bild in diesem Artikel wird leider einer der Vorlagen-Parameter nicht interpretiert. Und zwar geht es um die Annotationen selbst, die i.d.R. Links sind und zudem mit HTML formatiert wurden:

{{Annotation|600|115|[[Burger Binnensee|<small style="color:#FFF">Einfahrt in den Burger See</small>]]}}

Bei allen Annotationen, die von einem Wikitext-Link umklammert sind funktioniert's. Fehlt dieser Link, wird nicht der Text, sondern das hier angezeigt: {{{3}}}. Ich vermute, dass in die HTML-Element im Text orientieren. Jedenfalls erscheint der Text sobald ich das <small> entferne.

  • Woran liegt das?
  • Gibt es eine Möglichkeit das zu verhindern (idealerweise in der Vorlage Annotation selbst)?

Wäre toll, wenn ihr mir da mal wieder weiterhelfen könntet. // Martin K. (Diskussion) 23:56, 21. Aug. 2016 (CEST)

  • Das Ding enthält ein Gleichheitszeichen.
  • Alles links vom ersten vorhandenen Gleichheitszeichen ist der Name des Parameters.
  • Also hat dein Parameter den Namen:
    [[Burger Binnensee|<small style
  • Somit ist es ratsam, vor die Zuweisung zu setzen:
    3=[[Burger Binnen
VG --PerfektesChaos 00:06, 22. Aug. 2016 (CEST)
Ah, ok das erklärt's. Gibt es in Wikitext eigentlich sowas wie eine Klammerung, die nichts weiter tut, als solche Effekte zu verhindern? // Martin K. (Diskussion) 00:09, 22. Aug. 2016 (CEST)
Nein, das kann man am besten umgehen in dem benannte Parameter verwendet werden. Hilfe:Vorlagen#Problem: Gleichheitszeichen in Parameterwerten. Der Umherirrende 17:11, 25. Aug. 2016 (CEST)
Und was ist mit dem | ? In der Vorlage:Dateiüberprüfung hab ich häufiger das Problem, dass er mir Links zerhackt, sobald ein | drin ist. // Martin K. (Diskussion) 17:24, 25. Aug. 2016 (CEST)
Hast du ein Beispiel? Komplette Wikilinks oder Vorlagensyntax werden nicht in der Mitte zerlegt, man kann sie in Vorlagen verwenden (Nicht nur im Parameter-Bereich). Ansonsten muss man es maskieren. Hilfe:Vorlagen#Senkrechter Strich. Der Umherirrende 20:44, 25. Aug. 2016 (CEST)

Infobox bei ungeeigneten Benutzernamen[Quelltext bearbeiten]

Wäre es nicht möglich bei jeder Verwendung der Vorlage {{ers:Benutzernamensverifizierung}} automatisch einen Hinweis auf WP:LBA einzublenden? Zum Beispiel analog wie wenn man einen neuen Löschkandidaten einträgt. Oder aber zumindest auf WP:BG ein Hinweis auf WP:LBA?--MBurch (Diskussion) 22:25, 23. Aug. 2016 (CEST)

Hey MBurch, soll das denn automatisch unter WP:LBA vermerkt werden? Das wäre ja ein Botauftrag. --FNDE (Diskussion) 00:04, 30. Aug. 2016 (CEST)

Automatisiert Links umbiegen per Javascript[Quelltext bearbeiten]

Hallo zusammen, D hat mir vor Jahren beim Erstellen von Benutzer:AnotherFlominator/monobook.js geholfen. Ziel war es damals ein einfaches Skript zu haben, das Links auf eine BKL umbiegt. Leider funktioniert es nicht mehr. Versteht jemand, warum das nicht geht oder hat eine einfache Alternative zur Hand? Danke und Gruß, --Flominator 19:27, 28. Aug. 2016 (CEST)

Hallo Flominator, probier es doch mal mit bkl-check von Schnark. Es ist auch in seiner sehr nützlichen Skriptsammlung Fliegelflagel enthalten. Gruß --vy 73 de Ptolusque AFu 23:58, 28. Aug. 2016 (CEST)
Danke für die Antwort. Jedoch ging es mir um etwas, das eine Liste von Lemmas bekommt, diese abklappert und darin Links ersetzt. --Flominator 08:41, 29. Aug. 2016 (CEST)
Verstehe, hatte „Skript zu haben, das Links auf eine BKL umbiegt“ nicht ganz verstanden. Viel Erfolg! Gruß --vy 73 de Ptolusque AFu 09:04, 29. Aug. 2016 (CEST)
  • Benutzer:AnotherFlominator/monobook.js kann nicht (mehr) funktionieren, weil darin FeedbackArea vorkommt.
    • FeedbackArea wird definiert in Benutzer:D/monobook/user.js – dieses muss erst vollständig geladen worden sein, bevor die BKL-Umbiegfunktion angefasst werden kann.
  • Beide Seiten sind interessant für Software-Archäologen und atmen den Geist des letzten Jahrhunderts.
    • Insbesondere als es nur ganz wenig Skripte gab und man nach Belieben irgendwie die Namen von Variablen nutzen konnte, ohne befürchten zu müssen, dass jemand anders einen Namen wie initialize oder Communication oder Special verwenden könnte, und man jemand anders das Skript zerschießen würde oder von einem anderen Skript die eigenen Variablen geplättet würden.
    • Hier ist katastrophal, dass davon ausgegangen wird, dass im Browser immer nur ein Skript nach dem anderen ausgeführt wird, und immer erstmal die letzte Ladeanweisung bis zum Ende, bevor in die zuvor noch laufende zurückgesprungen würde.
    • Moderne Browser führen aber viele Skripte gleichzeitig aus und versuchen möglichst viele schon mal herunterzuladen und den Code bereitzustellen. Früher hatte der Browser eine Pause mit dem Seitenaufbau eingelegt und abgewartet, bis das nächste angeforderte Skript bereitgestellt wurde und ausgeführt werden konnte. Heutzutage wird diese Wartezeit aber genutzt, um inzwischen andere schon ausführbare Aufgaben anzugehen. Bei den Hunderten von Skripten, die teilweise in eine Wiki-Seite fließen, würde der Aufbau jeder Seite sonst mehrere Minuten dauern.
  • Heißt: Kompletter Neubau; ohne die von D zusammenkopierte Skriptbibliothek.
  • Nebenbei gibt es bei Benutzer:AnotherFlominator/monobook.js einen Fehler beim Laden der CSS-Ressource; hier ist ein falscher MIME-Typ angegeben.

Bedauernd --PerfektesChaos 14:26, 29. Aug. 2016 (CEST)

Mit Benutzer:DerHexer/fixlinks.js müsste das gehen, denke ich. Gruß --Schniggendiller Diskussion 22:40, 29. Aug. 2016 (CEST)
Nicht ganz so, wie ich mir das vorgestellt habe, aber vielleicht sogar cooler. Das könnte auch Benutzer:Informationswiedergutmachung gefallen. Danke, --Flominator 09:46, 30. Aug. 2016 (CEST)
@Flominator: Wie könnte mir das helfen? Wenn ich ein Lemma Vorname Familienname auf ein Klammerlemma verschiebe, muss ich alle Links persönlich durchgucken, damit ich nicht fehlverlinke. Das könnte mir nur helfen, wenn ich einen Artikel von Vorname Familienname (Klammerlemma alt) auf Vorname Familienname (Klammerlemma neu) verschiebe. Geht das mit diesem Skript? Und wie funktioniert es? MfG --Informationswiedergutmachung (Diskussion) 18:36, 30. Aug. 2016 (CEST)
@Informationswiedergutmachung: Du gehst auf "Links auf diese Seite", dann findest du im Werkzeugkasten (wo normalerweise der Contexter ist) "Fix Links". Es geht ein Popup auf, das dich nach dem Ziel fragt, auf das umgebogen werden soll. Dann gehen x neue Tabs auf, die jeweils eine lokal beschränkte Vorschau der Änderung zeigen. Wenn sie dir gefällt, kannst du die Änderung speichern. Wenn nicht, kannst du einen anderes Ziel eingeben und trotzdem speichern. Wirkt durchdacht auf mich. Gruß, --Flominator 20:05, 30. Aug. 2016 (CEST)
Wieviele Tabs? Und das kommt vom Hexer? Ich bin erstaunt, ich dachte immer, der kann nur labern. Klingt aber interessant, muss ich mal ausprobieren. :) --Informationswiedergutmachung (Diskussion) 20:08, 30. Aug. 2016 (CEST)
@Flominator: Kannst du mir das mal in meine cs einbinden? Oder wohin das auch immger gehört? MfG --Informationswiedergutmachung (Diskussion) 20:15, 30. Aug. 2016 (CEST)
Hey, ich labere erst seit fünf Jahren! xD —DerHexer (Disk.Bew.) 21:24, 30. Aug. 2016 (CEST)

Hi Informationswiedergutmachung, du musst das hier: mw.loader.load('//de.wikipedia.org/wiki/Benutzer:DerHexer/fixlinks.js&action=raw&ctype=text/javascript'); in deine common.js einbinden :) Schönen Gruß --FNDE (Diskussion) 20:32, 30. Aug. 2016 (CEST)

@FNDE: Danke. Gruß. --Informationswiedergutmachung (Diskussion) 20:34, 30. Aug. 2016 (CEST)
So? --Informationswiedergutmachung (Diskussion) 20:41, 30. Aug. 2016 (CEST)

Auf jeden Fall ohne ' am Anfang und am Ende mit Klammer und Semikolon, dann klappts auch :-)  Einfach meine Zeile kopieren. --FNDE (Diskussion) 20:42, 30. Aug. 2016 (CEST)

Hmm. Funzt nicht. --Informationswiedergutmachung (Diskussion) 20:52, 30. Aug. 2016 (CEST)
Bei dir steht: 'mw.loader.load('//de.wikipedia.org/wiki/Benutzer:DerHexer/fixlinks.js&action=raw&ctype=text/javascript'.
Es müsste aber heißen:mw.loader.load('//de.wikipedia.org/wiki/Benutzer:DerHexer/fixlinks.js&action=raw&ctype=text/javascript');
--FNDE (Diskussion) 20:54, 30. Aug. 2016 (CEST)
Immer noch nicht - trotz mehrfachen Cache-Leerens. --Informationswiedergutmachung (Diskussion) 21:01, 30. Aug. 2016 (CEST)

Informationswiedergutmachung: Oh! Ich war zu schnell mit copy&paste – tut mir Leid! :) Hiermit geht es auf jeden Fall: mw.loader.load('//de.wikipedia.org/w/index.php?title=Benutzer:DerHexer/fixlinks.js&action=raw&ctype=text/javascript'); Schöne Grüße --FNDE (Diskussion) 22:04, 30. Aug. 2016 (CEST)

@FNDE: Jetzt funktioniert es. Danke. --Informationswiedergutmachung (Diskussion) 02:05, 31. Aug. 2016 (CEST)
@DerHexer: Ganz ordentlich. Aber verbesserungswürdig. Zeige ich dir auf der WikiCon, nicht vergessen, in Ordnung? Aber gleich zwei Bitten vorab. Erstens du hast die Obergrenze der sich zu öffnenden Tabs auf 10 gesetzt? Erhöhe doch mal bitte auf 20. Und zweitens: dein Skript sollte nur Seiten im ANR erfassen. Linkfixe in Archiven, auf Benutzer- und Portalseiten, generell auf Meta sind eh unüblich und unerwünscht. MfG --Informationswiedergutmachung (Diskussion) 02:05, 31. Aug. 2016 (CEST)
Hm, da ich eine Session aufmache und die bei mir auch bei 10 Tabs schon ab und an abläuft, sehe ich jetzt nicht das große Problem, hier zweimal heranzugehen. Vielleicht mach ich es auch einfach individuell. Zum Teil sind Linkfixe auch auf Metaseiten sinnvoll; hier kann man ja individuell abbrechen. Auf Diskussionsseiten wird nichts ersetzt, nur in den Namensräumen 0|4|6|10|12|14|100. Grüße, —DerHexer (Disk.Bew.) 02:11, 31. Aug. 2016 (CEST)
@DerHexer: Ich muß noch etwas üben. Für Verschiebungen von Klammerlemmata uf Klammerlemmata scheint es ordentlich zu sein, aber ansonsten habe ich noch Probleme. Mal schauen. Übrigens: Linkfixe auf Metaseiten sind nie sinnvoll. Glaub mir ausnahmsweise mal, ich habe mehr WikiPedia-Erfahrung als du. Liebe Grüße --Informationswiedergutmachung (Diskussion) 02:14, 31. Aug. 2016 (CEST)
Der war gut! —DerHexer (Disk.Bew.) 23:24, 1. Sep. 2016 (CEST)
@DerHexer: Also beim Verschub von Klammerlemma auf Klammerlemma funktioniert das Tool ordentlich, aber beim Verschub von klammerfreiem Lemma auf Klammerlemma gibt es noch Probleme: immer, wenn ich Artikel sehe, die nicht zum geklammerten Lemma passen, und ich auch nicht weiß, wer da nun gemeint ist, schließe ich die Fenster. Die werden aber beim nächsten Versuch Links zu fixen wieder geöffnet. Aber dem 11. Unbekannten geht nichts mehr. So eben beinahe geschehen nach dem Verschub von Richard Hunt auf Richard Hunt (Puppenspieler). Zum Glück gibt es da "nur" sechs Richard Hunts, die ich nicht zuordnen kann, siehe Spezial:Linkliste/Richard Hunt, auch nicht über die BKL. So muss ich diese Richard Hunts notgedrungen in den Artikeln als BKL stehen lassen. Zwar immer noch besser als komplett fehlverlinkt, aber nicht wirklich gut. MfG --Informationswiedergutmachung (Diskussion) 23:57, 3. Sep. 2016 (CEST)
Ja, das lässt sich aber ohne irgendeine Form von Speichersystem nicht wirklich lösen. Man könnte dann in den Fenstern, in denen du schließt, auf Person (Jahr/Tätigkeit/usw.) verlinken. Ich könnt aber wahrscheinlich ein starte ab Link x einbauen, würde dann aber ein zweites Bestätigungsfenster bedeuten, das man mit einer 0 standardmäßig ausfüllen könnte. Grüße, —DerHexer (Disk.Bew.) 00:03, 4. Sep. 2016 (CEST)
@DerHexer: Ich habe eben mal geguckt: Salem-Preis, mit einem Mathemathiker Richard Hunt. Über den Umweg Engwiki en:Salem Preis habe ich en:Richard Allen Hunt alös Preisträger gefunden. Jahr fällt da flach, und auch als Richard Hunt (Mathematiker) eher kontraproduktiv. Und das wird mir dann doch zuviel - das auf jeden einzelnen Namen abzuklopfen und am Ende eine Relevanz per Rotlink zu erzeugen, die am Ende bei uns nicht vorhanden ist. Bei dem habe ich das jetzt aber mal gemacht, der hat damit jetzt sogar drei Rotlinks, siehe Spezial:Linkliste/Richard Allen Hunt. Das Tool ist gut, aber das ist für den gehobenen Umlinkanspruch. :) MfG --Informationswiedergutmachung (Diskussion) 00:12, 4. Sep. 2016 (CEST)

@Informationswiedergutmachung: Zum Thema "gehobener Anspruch" habe ich gerade den Contexter etwas optimiert. Vielleicht gefällt es dir ja. Und vielleicht gefällt es Hexi ja, dass ich sein Script dafür missbrauche. Dabei gleich noch zwei Verbesserungsvorschläge dafür:

  1. [[Produzent]] mit Produzent => Musikproduzent sollte m.E. zu [[Musikproduzent|Produzent]] werden (bisher wird daraus einfach [[Musikproduzent]]). Ich kann zwar für das Ersetzungsziel auch Musikproduzent|Produzent angeben, aber dann liege ich bei [[Produzent|Producer]] oder [[Produzent|Produzentin]] auf der Nase. Schön wäre ein optionaler Parameter zum Maskieren der Links.
  2. [[Münster (Westfalen)]] mit Münster => Münster (Westfalen) sollte m.E. nicht zu [[Münster (Westfalen) (Westfalen)]] werden. --Flominator 22:13, 6. Sep. 2016 (CEST)
Schau mer mal, muss ich ein paar Mal ausprobieren. MfG --Informationswiedergutmachung (Diskussion) 22:16, 6. Sep. 2016 (CEST)
Bug Nummer 1 ist mir bekannt, da hatte ich aber noch keine Zeit, das zu fixen. Bug Nummer 2 ist spannend, sollte eigentlich nicht passieren. Da sollt ich mich mal drängender dran machen. Danke für das wachsame Auge! Grüße, —DerHexer (Disk.Bew.) 23:15, 6. Sep. 2016 (CEST)
@DerHexer: Vielleicht willst du ja in der Summary zudem auf das Skript verlinken? --Flominator 13:32, 7. Sep. 2016 (CEST)
Doch, klar, würde natürlich passieren. Für den Umgang mit der Pipe müsste ich sämtliche reguläre Ausdrücke noch mal durchgehen, das dürfte etwas dauern. @Flominator, Informationswiedergutmachung: Ich hab aber den Link auf das Tool sowie eine Möglichkeit ergänzt, die ersten x Links zu überspringen. Grüße, —DerHexer (Disk.Bew.) 21:01, 8. Sep. 2016 (CEST)

Fehlerhafte Darstellung bei Transklusion von Seiten mit Spezial:Änderungen an verlinkten Seiten[Quelltext bearbeiten]

Die Einbindung der Seiten Wikipedia:WikiProjekt Amateurfunkdienst/Ungesichtete_Änderungen und Wikipedia:WikiProjekt Amateurfunkdienst/Letzte Änderungen führt zu einer fehlerhaften Darstellung von Spezial:Änderungen an verlinkten Seiten auf der Seite Wikipedia:WikiProjekt Amateurfunkdienst/Inhalt, in welcher Erstere eingebunden sind. Alle Einbindungen von Seiten mit Spezial:Änderungen an verlinkten Seiten werden auf Wikipedia:WikiProjekt Amateurfunkdienst/Inhalt angezeigt wie die Einbindung von Wikipedia:WikiProjekt Amateurfunkdienst/Letzte Diskussionen, welche dort ebenfalls eingebunden ist. Auf den beiden erstgenannten Seiten selbst funktioniert Spezial:Änderungen an verlinkten Seiten jedoch einwandfrei. Getestet mit verschiedenen Browsern und Cache leeren. Habe ich irgendetwas übersehen bzw. kennt jemand die Ursache für dieses Problem? Danke. --vy 73 de Ptolusque AFu 23:30, 28. Aug. 2016 (CEST)

Ist wohl ein Softwarebug. Hat nichts mit Vorlagen zu tun, die gleiche Spezialseite doppelt mit verschiedenen Parametern direkt einzubinden ergibt das gleiche merkwürdige Verhalten. Die ungesichteten Seiten können je nach Reihenfolge einzeln erscheinen, aber die anderen beiden sind immer gleich, egal in welcher Reihenfolge. --mfb (Diskussion) 19:20, 30. Aug. 2016 (CEST)
{{Spezial:Änderungen_an_verlinkten_Seiten|days=90|target=Portal:Amateurfunkdienst/Artikelliste|limit=6}}

{{Spezial:Änderungen_an_verlinkten_Seiten|days=90|target=Portal:Amateurfunkdienst/Artikeldiskussionsliste|limit=4}}

{{Spezial:Änderungen an verlinkten Seiten|days=90|namespace=0|target=Portal:Amateurfunkdienst/Artikelliste|hideReviewed=1|limit=6}}
Ich habe mal mit gerrit:308144 einen Software-Änderungs-Vorschlag gemacht. Mal schauen, ob das so angenommen wird. Der Umherirrende 12:00, 2. Sep. 2016 (CEST)
@Umherirrender: Danke! Scheint ein globaler MediaWiki Bug zu sein. Nach gerrit:281174 ist der Bug auch bei anderen specialpages, die multipel inkludiert sind zutreffend. Gruß --vy 73 de Ptolusque AFu 18:18, 2. Sep. 2016 (CEST)

i Info:: phab:T132545 Multiple special page transclusions all display the same as the first transclusion present --vy 73 de Ptolusque AFu 19:19, 26. Sep. 2016 (CEST)

Warnmeldung bei IP-Sperre[Quelltext bearbeiten]

Wie ich kürzlich mitbekommen und selbst nachvollzogen habe, bekommt jemand, dessen IP-Adresse global gesperrt ist, einen solchen Warnhinweis (Ausschnitt):

„Du kannst NN kontaktieren, um die Sperre zu diskutieren. Du kannst nicht die Funktion „E-Mail an diesen Benutzer“ benutzen, bis du eine gültige E-Mail-Adresse in deinen Benutzerkonteneinstellungen angegeben hast und du nicht daran gehindert wirst, diese Funktion zu verwenden.“

Das ist in den meisten Fällen wenig bis gar nicht hilfreich, vor allem wenn der Betroffene auch noch am Anlegen eines Benutzerkontos gehindert wird. Gäbe es die Möglichkeit, in den Warntext eine sinnvollere Kontaktmöglichkeit einzubauen, beispielsweise info-de@wikipedia.org o.ä.? Grüße TRN 3.svg hugarheimur 19:02, 3. Sep. 2016 (CEST)

Ich denke stewards[at]wikimedia[dot]org ist da die richtige Adresse, wenn es um Aktionen von Stewards geht. Wenn jemand nen Konto angelegt bekommt, und es nicht nutzen kann, weil er dennoch gesperrt ist, ist das auch blöd. Viele Grüße, Luke081515 20:11, 3. Sep. 2016 (CEST)

Wiki-Mail[Quelltext bearbeiten]

Wiki-Mail funktiioniert nur suboptimal. Mails, über die man per Benachrichtigung in Kenntnis gesetzt wurde, kommen nicht immer an, das ist mir mehrmals als Adressat und heute auch als Absender passiert; dass die abgesandte Mail gleichzeitug auch den eigenen Mail-Account geht, hat bei mir noch nie geklappt - und ja, ich habe jdes Mal das entsprechende Häkchen gesetzt. Was ist da los?

Ich hatte diese Frage schon auf WP:? gepostet, aber keine gescheite Antwort erhalten. kann mir hier jemand weiterhelfen? --Φ (Diskussion) 21:45, 12. Sep. 2016 (CEST)


i Info: Auf WP:? ist das aktuell WP:?#Wiki-Mail, nach Archivierung wäre es WP:Fragen zur Wikipedia/Archiv/2016/Woche 37#Wiki-Mail. --Schniggendiller Diskussion 00:26, 18. Sep. 2016 (CEST)

Fuer technisch Interessierte: Ich nehme an dass es sich um ein DMARC-Problem handelt (vorallem falls Yahoo fuer E-Mails genutzt wird): Die technischen Details des Problems werden in https://phabricator.wikimedia.org/T134886#2291395 auf Englisch beschrieben. Moegliche Ansaetze sind phab:T137603 und phab:T137614. --AKlapper (WMF) (Diskussion) 17:09, 19. Sep. 2016 (CEST)

Weiterleitungumwandlung und Neue Seiten[Quelltext bearbeiten]

Hinweis und Frage zur fehlender korrekten Erfassung eines neu angelegten Lemmas. Vorgang: Lemma Moers-Mitte wurde am 17.09.16 über die Bearbeitungsseite „Weiterleitung Moers-Mitte“ neu angelegt (die Weiterleitung wurde dabei vor Anlegung des Textes gelöscht). Dies scheint nach der derzeitigen WP-Technik nicht zulässig zu sein, da das neue Lemma weder unter der Rubrik „Neue Artikel 17. Sept.“ noch unter „Beiträge-Urdenbacher/Neue Artikel“ erfasst und angezeigt wird. Frage: Muss die Weiterleitung (Redirekt) vor Anlegung eines derartigen Lemmas von einem Admin gelöscht werden, da in Kürze ein weiteres neues Lemma statt einer derzeitige „Weiterleitung“ erstellt wird? --Urdenbacher (Diskussion) 11:45, 18. Sep. 2016 (CEST)

Bist du dir sicher, dass du die Frage hier stellen wolltest? Technisch ist das Ändern einer Weiterleitung in einen normalen Artikel keine Artikelanlage. Das ist auch so gewünscht, nichts zu ändern. --mfb (Diskussion) 15:16, 18. Sep. 2016 (CEST)
Sicher bin ich nicht, dass hier Hinweis und Frage hingehören. Aber eine zutreffendere Rubrik wurde trotz Suche unter WP-Technik nicht gefunden. --Urdenbacher (Diskussion) 17:09, 18. Sep. 2016 (CEST)
Die Erkennung von neuen Artikeln geht auf Basis neu erstellter Seiten, daher wird die Umwandlung einer Weiterleitung in einen Artikel nicht als solcher auf Spezial:Neue Seiten gelistet. Des Weiteren führt dies auch nicht zu Zuordnung dieser Seiten als "Neu" in diversen Tools die Benutzerinfos aufbereiten. Dies ist aber technisch aktuell nicht anders möglich. Bei Tools zur Ermittelung des Hauptautors wie Benutzer:APPER/WikiHistory würde diese Umwandlung aber entsprechend berücksichtigt werden. Aber nur wegen der eigenen Benutzerinfos die Admins mit der Löschung zu belästigen halte ich persönlich nicht für gerechtfertigt. Aber ich denke, da gehen die Meinung auseinander. Der Umherirrende 18:49, 20. Sep. 2016 (CEST)
Ich war mal so frei und habe die Weiterleitung gerade gelöscht, da ich es teilweise auch als nervend empfinde, Link-Benachrichtigungen zu Weiterleitungen zu bekommen, die ich mal angelegt habe und die irgendjemand zu einem Artikel ausgebaut. Ich würde Benutzer:Urdenbacher empfehlen, in Zukunft einen SLA vor der Neuanlage des Artikels zu stellen. Das macht weniger Arbeit. Gruß aus dem nassen Schwarzwald, --Flominator 19:30, 20. Sep. 2016 (CEST)
@Urdenbacher: Die Seite ist schon richtig, aber dein Beitrag war im Abschnitt #Benutzerbeitr.C3.A4ge weiter oben der mit dem Thema nichts zu tun hat. --mfb (Diskussion) 20:57, 20. Sep. 2016 (CEST)
Danke für die Hinweise und Info. Falls nochmals "Hilfe/Info" für einen technischen Vorgang benötigt wird, erfolgt dies über einen neuen Abschnitt. Für normale Bearbeitungen ist die Inanspruchnahme "dieser Seite" aber kaum erforderlich und der Vorgang "Weiterleitung/Ersatz durch neues Lemma/Löschung der Weiterleitung" dürfte sich - für mich - erledigt haben. Gruß, --Urdenbacher (Diskussion) 18:07, 21. Sep. 2016 (CEST)
Dieser Abschnitt kann archiviert werden. Urdenbacher (Diskussion) 10:57, 25. Sep. 2016 (CEST)

Box verkleinern[Quelltext bearbeiten]

Guten Tag! Im Artikel Hementerin im Abschnitt "Aminosäuresequenz" geht die graue Box bis zur Infobox, was unschön aussieht. Gibt es eine Möglichkeit, die graue Box dem Text anzupassen? --ChemPro (Diskussion) 12:04, 25. Sep. 2016 (CEST)

Geht mit Div-tags
        10         20         30
XTLSEPEPTC SIEYFRYQAI EDCEYSISVK
so? --Liebe Grüße, Lómelinde Diskussion 13:04, 25. Sep. 2016 (CEST)
Vielen vielen Dank! --ChemPro (Diskussion) 13:22, 25. Sep. 2016 (CEST)
Dieser Abschnitt kann archiviert werden. --ChemPro (Diskussion) 13:22, 25. Sep. 2016 (CEST)

Babeleinbindung scheitert an CSS?[Quelltext bearbeiten]

Hi all,

kann mal jemand, der mehr Ahnung davon hat als ich, hier schauen, woran die fehlerhafte Einbindung des Babelbausteins liegt? Ich tippe entweder auf CSS und die Einbindung der Vorlage in meine (vor Urzeiten gestrickte) Babelleiste oder aber auf eine fehlerhafte Vorlage, die sich, so wie beschrieben, dann in dem Kontext nicht nutzen lässt. Viele Grüße Martin Bahmann (Diskussion) 17:01, 26. Sep. 2016 (CEST) P.S.: Natürlich darf jeder dafür gerne Hand an meine Seite legen :-)

Du könntest es machen wie Benutzer:Schwenn. --Leyo 17:07, 26. Sep. 2016 (CEST)
Ich habe mal versuchsweise einen Baustein eingefügt. --Liebe Grüße, Lómelinde Diskussion 18:26, 26. Sep. 2016 (CEST)
Lómelinde hat das Problem gelöst. Vielen lieben Dank dafür! Viele Grüße Martin Bahmann (Diskussion) 09:43, 27. Sep. 2016 (CEST)
Dieser Abschnitt kann archiviert werden. Martin Bahmann (Diskussion) 09:43, 27. Sep. 2016 (CEST)