Wikipedia:Technik/Werkstatt

Automatische Archivierung

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

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

Dauerbaustellen; Spezifikationen für wünschenswerte Werkzeuge

• 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

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

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

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 HTTPS: https://toolserver.org/~kolossos/openlayers/kml-on-ol.php?lang=de&uselang=de&params=51.165_N_10.455277777778_E_dim:900000_region:DE_type:country&title=Deutschland
• Bei HTTP: http://toolserver.org/~kolossos/openlayers/kml-on-ol.php?lang=de&uselang=de&params=51.165_N_10.455277777778_E_dim:900000_region:DE_type:country&title=Deutschland

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

• http://toolserver.org/~master/osmjson/getGeoJSON.php und
• http://toolserver.org/~kolossos/geoworld/marks.php

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:

• http://creativecommons.org/licenses/by-sa/2.0/
• http://de.wikipedia.org/wiki/Wikipedia:WikiProjekt_Georeferenzierung/Wikipedia-World/en
• http://wiki.openstreetmap.org/wiki/WIWOSM
• http://de.wikipedia.org/wiki/Help:OpenStreetMap

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)

WP:FR#Kleines Dankeschön an IPs

Ich wäre für eine Stellungnahme zur Umsetzbarkeit dieser Script-/Gadget-Idee dankbar. --Leyo 14:04, 20. Okt. 2012 (CEST)

Umsetzbar ist so ziemlich alles. Zu erarbeiten wäre:

1. Begründung, warum das nicht mit WikiLove kompatibel sei; wenn es dort integrierbar ist, wird niemand Lust haben, es neu zu programmieren und in die Tonne zu treten, sobald WikiLove eines Tages in deWP eingeführt wird.
2. Operationale Anweisungen in Menschensprache an Programmierer:
   • Auf welchen Seiten soll ein Portlet-Link sichtbar sein?
   • Wenn ich auf welcher Seite das Portlet-Link anklicke, soll genau was passieren?
     • Nur für IPs; oder auch angemeldete, offenbar ohne Sichterrecht?
     • Eingabeformular für Freitext
     • Vorgegebene Standardtexte zum Anklicken
     • Feste Gesamt-Struktur des Textes, mit difflink der fraglichen Änderung/en.
     • Sicherheitshalber den letzten Bearbeiter anzeigen; falls nicht grad Aka zwischendurch noch gefixt hat und sich das Lob an Land zieht.
     • Wenn „Abschicken“, dann soll dies auf Benutzerdisku des letzten Bearbeiters der aktuellen und gesichteten Seite angefügt werden, obwohl / sofern / nicht / dies eine IP ist.
     • Es soll interaktiv die Benutzerdisku editiert werden, so dass last-minute-Anpassungen des Standardvorgangs möglich sind; oder alternativ per API gedonnert werden (Signatur-Umwandlung? Ausprobieren).

VG --PerfektesChaos 16:27, 20. Okt. 2012 (CEST)

„Individual wikis may request that WikiLove be deployed to them provided the following criteria are met:“

• Community consensus for the deployment has been reached
• The WikiLove extension has been localized to that wiki's language on TranslateWiki (you can help here) erledigtErledigt
• A configuration file exists on the local wiki (MediaWiki:WikiLove.js)

„Once these criteria are met, open a bug in bugzilla requesting the deployment.“

Gruß Matthias (Diskussion) 16:30, 20. Okt. 2012 (CEST)

Beim Vorschlag geht es um eine „Einklicklösung“. Es gibt ja etliche Skripte Huggle, etc., die beim Revert auch gleich einen Baustein wie {{Test}} auf der IP-Disk. absetzen. Ich stelle es mir in dieser Art vor, nur halt positiv statt negativ.

Dementsprechend könnten existierende Skripte angepasst und müssten nicht neu geschrieben werden. --Leyo 17:36, 20. Okt. 2012 (CEST)

Der Benutzer:Schnark/js/wikieditor hat seit kurzem einen Knopf für {{Willkommen}}. Ansonsten ist Benutzer:Schnark/js/autoantraege wohl das was du suchst. Auch dieses Skript kann Standardtexte auf der Benutzerdiskussionsseite hinterlassen. Gruß Matthias (Diskussion) 22:42, 20. Okt. 2012 (CEST)

Ich möchte es ja nicht nur für mich, sondern für eine breitere Anwendung, damit IPs nicht immer nur getadelt, sondern (mit geringtem Aufwand) gelobt werden. Beim obigen Kommentar hatte ich insbesondere an Benutzer:DerHexer/rollback.js, aber auch an Scripts wie Benutzer:Schnark/js/autoantraege gedacht. --Leyo 22:52, 20. Okt. 2012 (CEST)

Erstmal schönen Urlaub, oder was immer du geplant hast.

Die Geschichte ist noch nicht operational.

1. Inwieweit deckt das existierende aber in der deWP nicht aktivierte WikiLove den Wunsch bereits ab, oder könnte es das nicht?
2. Eine Spezifikation scheint vielleicht wie folgt zu lauten, soweit ich die nebelhaften Vorstellungen bislang durchschauen konnte:
   • Interaktive Auslösung, individuell konfigurierbar
     • Wenn auf einer Seite im ANR, dann Portlet-Link einfügen
     • oder zusätzlich: Wenn Sichtungs-Buttons auf der Seite sichtbar sind, dann füge einen weiteren Button hinzu
     • und außerdem stelle per API eine .fire()-Funktion für eigene GUI-Wünsche bereit; eine solche .fire()-Funktion wird ohnehin für Portlet-Link usw. benötigt und kann dann auch öffentlich gemacht werden.
   • Wenn ausgelöst wird, dann
     • Mache eine API-Abfrage, welcher Benutzer die RevID der aktuell angezeigten Seitenversion editiert hatte, oder lies das aus den Strukturen einer (Sichtungs-)Diffpage heraus.
     • Zeige inzwischen ein Formular zum Zusammenbau eines Textes an.
       • Vorgegebene Standard-Phrasen für alle Gadget-Nutzer, zum Anklicken.
       • Individuell konfigurierte Standard-Phrasen, zum Anklicken.
       • Feld für Freitext.
       • Buttons für Abschicken/API, Manueller Edit, Abbrechen.
     • Wenn Submit, dann bearbeite die Disku des inzwischen (per API?) ermittelten Benutzers (bzw. IP). Füge den zusammengestoppelten Text ein, zusammen mit Backlink auf die bearbeitete Seite und Signatur, Disku-Überschrift und ggf. Neuanlage einer nicht existierenden BD.
       • Ob es sich überhaupt lohnt, für diese letzte Phase ein externes Skript mit völlig anderer Methodik auch noch einzubinden (DerHexer/rollback.js, Schnark/js/autoantraege) oder ob das nicht größeren Aufwand und Probleme verursacht als das integriert selbst vorzuhalten steht dahin. Eigentlich sind das dann nur noch wenige Statements.
3. Der Überschrift dieses Thread entnehme ich, dass IPs gemeint wären. Der sonstigen Diskussion entnehme ich, dass seit kurzem angemeldete Benutzer gemeint wären, die noch kein Sichterrecht hätten. Wie denn nun?

LG --PerfektesChaos 13:29, 21. Okt. 2012 (CEST)

IMHO ist das WikiLob für IPs UND für Benutzer ohne Sichterrechte UND für alle anderen (nicht gesperrten) Benutzer gemeint. Der Entwicklungsaufwand und ein breiter Einsatz per default ist IMHO dann gerechtfertigt. Wenn das jemand benutzt, um ausschliesslich IPs postives Feedback zu schicken - wunderbar, kein Problem :-) ! Oder nur Neulingen, super! Alle können etwas mehr positives Feedback gebrauchen... Wichtig ist in jedem Fall: schnell benutzbar mit wenigen Klicks und nicht 3 Dialogboxen. Mal 2 konkrete Anwendungsbeispiele:

• Fall A): Ich will nur mal schnell eine IP für ihren Beitrag loben. In der Sichtungsbox (oder in meiner Beobachtungsliste oder in der Versionsgeschichte) klicke ich auf den "WikiDank"-Button , die Dialogbox öffnet sich (ohne das ich dabei ja die Seite verlasse). Ich klicke einfach nur auf "senden" (und ignoriere das optionale Texteingabefeld), damit wird folgendes automatisch auf die IP-Diskussionsseite geschrieben (voreingestelltes Bild und der Standardtext):

Einfach mal ein kleines Dankeschön für Deinen Beitrag in Liste der Universitäten in Ghana... von Atlasowa (Diskussion) 16:28, 29. Okt. 2012 (CET)

Alles wichtige ist damit gesagt, nämlich wer wem wofür konkret mal Dankeschön sagt. In vielen Fällen reicht diese "Basic" Variante völlig, beide wissen worum es geht, das ist auch nicht eigentlich "unpersönlich". Die IP wird per "Kackbalken" auf den WikiDank aufmerksam. Der gesendete WikiDank wird übrigens auch in meinen Benutzerbeiträgen aufgeführt.

• Fall B): Ich will mal schnell jemand für einen Edit Dankeschön sagen, aber auch einen persönlichen Kommentar dazu schreiben und ein passendes Bild auswählen. In der Sichtungsbox (oder in meiner Beobachtungsliste oder in der Versionsgeschichte) klicke ich auf den "WikiDank"-Button , die Dialogbox öffnet sich. Ich schreibe etwas in das Texteingabefeld und wähle (mit dem Link unter dem voreingestellten Bild) ein bestimmtes Bild von Commons aus (so ähnlich wie bei WikiLove). Wie bei WikiLove sehe ich dann eine Vorschau meiner WikiDank-Nachricht. Ich klicke auf "senden", damit wird folgendes automatisch auf die Benutzerdisk geschrieben:

Einfach mal ein kleines Dankeschön für Deinen Beitrag in Holsten Brauerei... Boah, gute Arbeit mit den Koordinaten, das kriege ich immer nicht richtig hin! Prost! --Atlasowa (Diskussion) 16:28, 29. Okt. 2012 (CET)

So ungefähr stelle ich mir das vor, voreingestelltes Bild und Optionen kann man natürlich noch diskutieren. Das ist aber so technisch machbar, oder? Das könnte man dann als gadget testen und danach als default einrichten, mit opt-out per Einstellungen (wie bei WikiLove). Grüsse --Atlasowa (Diskussion) 16:28, 29. Okt. 2012 (CET)

1. Technisch machbar ist das alles. Geistig keine Herausforderung, nur ein Haufen Routine-Programmierarbeit.
2. Noch nicht klar ist weiterhin, warum man dies nicht über das existierende WikiLove ansteuern kann; möglicherweise haben die eine API? Eine komplette Parallelprogrammierung wird kaum passieren.
3. Danke für die präzise Beschreibung der Vorstellungen; man nennt sowas auch Use Cases.
4. Die Geschichte mit dem Standard-Text und Einheits-Blumenstrauß wird so zur Farce. Wenn 100 Leute das Gadget benutzen und überwiegend denselben Text schicken und alle denselben Blumenstrauß, dann haben bald etliche Empfänger den identischen Block dreimal auf der Disku; und wenn sie auf die Disku anderer Leute gehen, dann finden sie dort noch zwei identische Blümchen und Texte wie bei sich selbst. Das wirkt mehr negativ und entwertet die Aktion. Wenn schon, dann müsste zufallsgesteuert der Blumenstrauß oder andere Motive aus einem Dutzend ausgewählt werden, kombiniert mit einer zufälligen Auswahl aus einigen vorgegebenen Standardphrasen, die um selbst geschriebene Textbrösel ergänzt werden.

LG --PerfektesChaos 23:25, 29. Okt. 2012 (CET)

Ich möchte ebenfalls einen Use Case nachliefern: Bei ungesichteten Änderungen erscheinen die zwei Sichtungsbuttons. Da könnte ein weiterer hinzugefügt werden.
Sichten Sichten + IP danken Änderungen verwerfen
Ein Klick auf den neuen Button würde folgendes bewirken:

• Diff wird gesichtet
• Difflink und Artikelname wird gespeichert
• Prüfung, ob Änderung durch IP User erfolgte → falls nein Abbruch
• IP-Disk. wird auf Existenz geprüft → falls nein Prüfung auf Vorhandensein von IP-Thanks-Bausteinen → falls ja Abbruch
• IP-Thanks-Baustein (mit Artikelname, Diff, Hinweis auf Sichtung und ggf. Zufallsbild) wird auf IP-Disk. gesetzt

Einige der Schritte sind (ähnlich) in Hexers Rollback-Script implementiert. Beispielsweise werden {{subst:Test}} oder {{subst:Benutzer:TheWolf/Quellen}} automatisch auf die IP-Disk. gesetzt. Falls diese erst kürzlich gearbeitet wurde, wird eine VM oder Sperre vorgeschlagen. --Leyo 22:52, 27. Nov. 2012 (CET)

mw:Extension:Thanks scheint diesem Wunsch hier ziemlich ähnlich zu sein. Könnte diese Extension hier übernommen und ggf. lokal angepasst werden? --Leyo 21:45, 26. Mär. 2013 (CET)

• Dies ist experimentell, und da bin ich persönlich erstmal zurückhaltend. Wir haben mit Lua und AFT und Wikidata und etlichem anderem einen ziemlichen Rückstau und viel zu wenig Techies, um uns in Kinderkrankheiten unausgereifter Produkte anderer Leut zu stürzen.
• Das System arbeitet mit Echo, welches ebenfalls noch nicht zu Ende entwickelt ist; noch weniger dass wir dieses ausgereift eingebaut hätten.
• Das System versendet seine Nachrichten rein privat, so dass sie niemand anders sehen kann. Womit man auch nicht wissen kann, ob es schon durch einen anderen Wikipedianer eine Benachrichtigung gegeben hätte.
• Das System scheint auf E-Mail zu setzen; der Thread hier heißt „Dankeschön an IP“. Wo und wie allerdings ein nicht angemeldeter Benutzer einen E-Mail- oder Echo-(=WP/SUL)-Account eingerichtet haben soll, erschließt sich mir grad nicht („no support for anonymous users“).
• Zum System „Thanks“ gibt es außer der standardmäßig zu jeder mw:Extension abgespulten mw-Installationsroutine keinerlei Doku-Seite verlinkt; außer einem Bildschirmfoto von einem Link „Hier draufklicken“ ist nichts über Funktionalität oder Abläufe erkennbar. Mit Softwareprodukten ohne Dokumentationsseite beschäftige ich persönlich mich grundsätzlich nicht.

VG --PerfektesChaos 22:07, 26. Mär. 2013 (CET)

Thanks ist mittlerweile aktiv. Wenn auch IPs berücksichtigt wären, so wäre mein Wunsch zumindest teilweise erfüllt. --Leyo 16:29, 21. Nov. 2013 (CET)

Erweiterung der Signatur-Zeitstempel auf Diskuseiten

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="/https/de.wikipedia.org/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?

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

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

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)

Position des Signatur-Buttons verändern

Gibt es eine einfache Möglichkeit, den Signatur-Button aus der Bearbeitenleiste (nur) auf Projekt- und Diskussionsseiten links neben den „Seite speichern“-Button zu legen?--CENNOXX 23:09, 11. Jul. 2013 (CEST)

• Das ist eine super-super-Idee!
  • Sie kommt leider um etliche Jahre zu spät. Es ist schon absehbar, wann unser klassisches Disku-Seiten-Signieren beendet sein wird.
• Verschieben von irgendwoher (es gibt mehrere solcher Bearbeitenleisten) ist nicht möglich; der bleibt schon da, wo er ist.
• Ein Button in gleicher Art wie der Speichern kann aber sehr leicht neu generiert werden.
• Dass es eine Seite ist, die entweder in einem Disku-Namensraum liegt oder aber (grübel) die Eigenschaft „Abschnitt hinzufügen“ hätte, ließe sich herausfinden. (Hm. PageProps newsectionlink per API? Bestimmte Namen wie „Werkstatt“, „Anfrage“, „Lösch“, „Umfrage“, „Meinungs“ wären fad. Das Magicword kann in einer /Intro stehen. Es kann ein neuer und leerer Abschnitt sein. – Jedenfalls nur WPNR.)
• Ein Kollege oder ich kann aber relativ bald ein Gadget schreiben, das sowas umsetzt.

Liebe Grüße --PerfektesChaos 00:33, 12. Jul. 2013 (CEST)

PS: Hat jemand eine Glaskugel und weiß, wann dewiki in Flow und Echo abhebt? Einen konkreten deployment plan für den Ersatz der Signaturen durch automatische Threads sehe ich grad nicht.

• enWP und dewiki listet noch kein derartiges Skript.
• Es ist möglich, auf Disku und im WPNR immer den Button gleichzeitig mit Seitenaufbau anzulegen.
  • Im WPNR wird er jedoch initial disabled und erst per API scharf geschaltet.
  • Würde man mit der Button-Anlage auf das API-Ergebnis warten, gäbe es da links einen heftigen Ruckler. Der kann sowieso beim Seitenaufbau kommen; aber da bewegt sich ja noch so manches.
  • Optional kann man ihm gelben Hintergrund geben, solange noch keine Tilden im Bearbeitungsfeld stehen, und das beim Verlassen des TEXTAREA aktualisieren.
• WikEd und Ace können auch aktiv sein.
• Optional das Einfügen mit zwei Bindestrichen, oder nur vier Tilden.
• Optional kann man bei Klick auf Speichern das TEXTAREA flöhen, ob Tilden bereits drin sind; und beim Fehlen einmalig warnen. Im Einzelfall (Archivierung, Typo, Linkfix rückwirkend, PS, BK) kann eine Bearbeitung ohne Tilden sinnvoll sein.

Baldiges Wochenende --PerfektesChaos 10:17, 12. Jul. 2013 (CEST)

Flow ist gerade am Anfang seiner Entwicklung (eventuell Ende 2013), Notifications (Echo) könnte diese Quartal kommen. Ansonsten schau mal auf mw:Editor Engagement/2013 strategy planning (Features) und mw:Roadmap bzw. dessen aktuellere Google-Exceltabelle (auf der Seite oben verlinkt)--se4598 / ? 10:40, 12. Jul. 2013 (CEST)

Ah, danke.

• Flow: „am Anfang seiner Entwicklung“ + „eventuell Ende 2013“ = Frühjahr oder Mitte 2014; könnte sich noch lohnen.
• Echo schätze ich so ein, dass es mit den in Rede stehenden Tilden nichts zu tun hat.

LG --PerfektesChaos 10:46, 12. Jul. 2013 (CEST)

Edit-Notice

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)

Neue Dateiversion angeblich ungesichtet

Ist der Fehler bekannt und gemeldet, dass das Hochladen einer neuen Dateiversion den Sichtungsstatus der Datei dermaßen zerstört, dass kein Nach- oder erneutes Sichten mehr etwas bewirkt? --TMg 15:31, 31. Jul. 2013 (CEST)

Könnte Bug 54165 sein. Der Umherirrende 19:36, 12. Okt. 2013 (CEST)

Verwendung bestimmter HTML-Elemente und Klassennamen analysieren

Hallo, zwecks Bereinigung der MediaWiki:Common.css würde mich aktuell interessieren, wo überall das HTML-Element <cite> verwendet wird. Lässt sich das irgendwie halbwegs einfach und zuverlässig auswerten?

Zum Hintergrund: Dieses Element ist laut HTML5-Spezifikation dazu gedacht, Titel von Werken auszuzeichnen und wird deshalb sinnvollerweise kursiv angezeigt. Leider wurde das Element in der Wikipedia falsch benutzt, um komplette Quellenangaben auszuzeichnen (z. B. in Vorlage:Zitat, Vorlage:Cite book usw.) und dadurch motiviert wurde die Kursivschrift in der Common.css aufgehoben. Ich würde jetzt eigentlich doch ganz gerne die Regel aus der Common.css entfernen, damit das Element in Zukunft korrekt benutzt wird, dazu müssten aber zuerst die aktuellen Verwendungen bereinigt werden.

Entsprechendes würde irgendwann in Zukunft auch für einige veraltete Klassennamen gelten. --Entlinkt (Diskussion) 12:37, 12. Sep. 2013 (CEST)

Ich habe aus dem aktuellen Dump eine Liste der betroffenen Seiten erstellt, du findest sie unter Benutzer:Entlinkt/cite. Nicht erschrecken, das meiste sind Seiten im WNR, hauptsächlich Unterschriften von Benutzer:Herr Th. und einigen anderen, die sogar semantisch korrekt sind. Es kann allerdings noch mehr geben, etwa wenn irgendwo {{FNZ|a|text|cite}} verwendet wird (frag mich nicht wieso, aber bei handgemachten Fußnoten wird <cite> anscheinend gerne missbraucht). Unter der Liste in einem Kommentar habe ich die ursprüngliche Ausgabe meines Skripts angehängt, damit du dir einen Überblick verschaffen kannst, ohne die Artikel einzeln aufrufen zu müssen. --Schnark 09:09, 13. Sep. 2013 (CEST)

Cool, vielen Dank! Ich werde mal schauen, ob das mit vertretbarem Aufwand zu bereinigen ist. Gruß --Entlinkt (Diskussion) 09:39, 13. Sep. 2013 (CEST)

Okay, die Bereinigung scheint geklappt zu haben (bis auf irgendwelche unerkannten Probleme, die bestimmt noch gefunden werden). Jetzt würde mich dasselbe für die folgenden Klassennamen interessieren (teils sind sie veraltet, teils soll die Verwendung geändert werden):

• hintergrundfarbe10 (außer in Jahresartikeln; zur Analyse; war nie definiert und soll ggf. neu definiert werden)
• imagemap-inline (kaputt, soll aus common.css entfernt werden)
• metadata (zur Analyse; Definition in common.css soll evtl. geändert werden)
• metadata-label (zur Analyse; soll ggf. nach MediaWiki:Gadget-Personendaten.css verschoben werden)
• NavEnd (kaputt, soll aus common.css entfernt werden)
• nogrid (kaputt, wurde bereits aus common.css entfernt, betroffene Seiten sollten aufgespürt werden)
• palaeobox (zur Analyse, soll evtl. mit Klasse taxobox zusammengeführt werden)

Gruß --Entlinkt (Diskussion) 15:58, 13. Sep. 2013 (CEST)

Ja, ja, der kleine Finger und die ganze Hand. ;-) Ich schau mal, ob ich die Listen übers Wochenende erstellen kann. --Schnark 10:22, 14. Sep. 2013 (CEST)

Die Liste steht unter Benutzer:Entlinkt/CSS-Klassen zur Verfügung. --Schnark 09:17, 16. Sep. 2013 (CEST)

Wieder danke! Die Regeln für metadata und palaeobox sind bereits aus der common.css entfernt, NavEnd wird ebenfalls noch eliminiert, die anderen sind etwas komplizierter. Gruß --Entlinkt (Diskussion) 01:17, 17. Sep. 2013 (CEST)

So, es sind jetzt noch zwei weitere Klassen weg. Ich fasse das zu Dokumentationszwecken nochmal zusammen:

• <cite>-Elemente sind jetzt wieder standardmäßig kursiv. Die ensprechende Regel, mit der das aufgehoben wurde, habe ich entfernt. Die kursive Schrift als Standardverhalten ist sinnvoll, weil <cite>-Elemente in HTML5 zur Auszeichnung von Werktiteln benutzt werden sollen und diese üblicherweise kursiv gesetzt werden. Dies fördert die semantisch korrekte Verwendung des Elements und verhindert insbesondere semantisch unkorrekte Verwendungen.
• Die Klasse imagemap-inline wurde vor vielen Jahren, als man Bilder noch nicht normal verlinken konnte, eingeführt, um sie wie in Vorlage:OstEuroPortal erst in eine Imagemap zu packen und diese dann inline darzustellen. Sie wurde jetzt entfernt, weil sie nicht mehr nötig ist. Stattdessen sollen Bilder normal verlinkt werden.
• Die Klasse metadata erzeugt nun bei Tabellen nicht mehr automatisch einen Rahmen. Dies dient der Konsistenz, weil sie das bei anderen Elementen auch nie getan hat. Vor vielen Jahren wurde diese Klasse für die Vorlage:Personendaten eingeführt, wird aber mittlerweile für etliche andere Dinge benutzt und sollte deshalb keine solchen Nebenwirkungen haben. Einen Rahmen kann man stattdessen mit class="rahmenfarbe1" erzeugen.
• Die Klasse NavEnd wurde in der Vorlage:Navigationsleiste benutzt, um gefloatete Bilder einzuschließen. Das passiert nun stattdessen in MediaWiki:Common.css mit dem Pseudoelement div.NavFrame:after. Die Klasse wird deshalb ersatzlos nicht mehr benötigt und wurde entfernt.
• Die Klasse nogrid wurde vor langer Zeit eingeführt, um zu verhindern, dass prettytables ihren Rahmen an Untertabellen vererben. Dass das überhaupt passierte, war ein Bug, der längst gefixt ist. Vereinzelt wurde die Klasse entgegen ihrem ursprünglichen Zweck verwendet, um bei den eigentlichen prettytables die inneren Rahmenlinien zu entfernen, was infolge des o. g. Bugfixes nicht mehr funktioniert. Es ist aber ohnehin gerade der Sinn der Klassen prettytable und wikitable, innere Rahmenlinien zu haben. Es gibt noch Verwendungen, die kontrolliert werden sollten (in den meisten Fällen scheint der Rahmen aber in Ordnung zu sein).
• Die Klasse palaeobox war bis auf die abweichende Hintergrundfarbe der Überschriften eine Kopie der Klasse taxobox und ist jetzt nur noch dafür zuständig, die abweichende Hintergrundfarbe zu setzen, d. h., es muss class="taxobox palaeobox" verwendet werden. Sie wird aber sowieso nur in der Vorlage:Taxobox benutzt.

Gruß --Entlinkt (Diskussion) 05:41, 22. Sep. 2013 (CEST)

Ist das mit dem {{FNZ|a|text|cite}} komplett erledigt, also eine derartige Nutzung durch die Hintertür jetzt auszuschließen? Ansonsten kann man die Vorlage temporär mit einem Wartungslink versehen. ÅñŧóñŜûŝî (Ð) 20:59, 22. Sep. 2013 (CEST)

{{FNZ|a|text|cite}} erzeugt kein <cite>-, sondern ein <span>-Element (und das war auch nie anders; der 3. Parameter wurde mit diesem Edit eingeführt und seitdem nicht verändert). --Entlinkt (Diskussion) 21:41, 22. Sep. 2013 (CEST)

Aha. "hintergrundfarbe10" kommt gem. Suche in 600 Jahresartikeln vor, immer in der Kombination  ::::colspan="2" class="hintergrundfarbe10" bgcolor=#ececec

Welchen Sinn es machen soll, sowohl eine Klasse, als auch ein bgcolor anzugeben, ist sowieso fraglich. Das sind aber längst nicht alle Seiten. ÅñŧóñŜûŝî (Ð) 11:26, 24. Sep. 2013 (CEST)

class="metadata" und <ref>

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)

https auf .beta.wmflabs.org

• 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

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)

Scrollbalken bewegt sich von alleine

Ich habe einen Fehler in der Wikipedia festgestellt. Wenn ich einen Text bearbeite, dann schiebt sich immer der Scrollbalken und somit auch der ganze Text ruckartig von alleine nach oben. Am Scrollrad meiner Maus liegt es nicht, denn in anderen Webseiten und Programmen passiert nichts. Ich kann gerne ein Video machen, wenn das jemand von der Wartung hilft. Die Probleme haben gestern Abend angefangen. Ich verwende "Windows XP" und den "Microsoft Internet Explorer 8" --Sassenburger (Diskussion) 22:31, 23. Feb. 2014 (CET)

Für die Mitleser: basierend auch auf der anderen Rückmeldung auf Special:Permalink/127875769#Wo Störungen in der Wikipedia melden? führt das ganze meiner Meinung nach über Benutzer Diskussion:Fomafix#IE8-Scroll-Bug zu gerrit:109660 als wahrscheinlicher Auslöser (siehe dort auch die Kommentare) --se4598 / ? 22:45, 23. Feb. 2014 (CET)

Ich habe das eben mal auf Original-XP mit echtem IE8 probert und konnte mit den angegebenen Tastaturaktionen nicht reproduzieren.

Gleichwohl besteht die Notwendigkeit für diesen Fix ganz offenkundig weiter; die Entfernung bitte revertieren. Ich weiß nicht, welche äußeren Umstände mitspielen müssen, aber es kommt ja zu unabhängigen Beobachtungen.

IE8 ist auch etwas, das zwar prozentual abnimmt, aber absolut noch auf Jahre hinaus nicht abgeklemmt werden kann.

VG --PerfektesChaos 23:39, 23. Feb. 2014 (CET)

Ich habe eben mal drei andere Browser ausprobiert. Der Bug betrifft tatsächlich nur den MIE8. --Sassenburger (Diskussion) 01:40, 24. Feb. 2014 (CET)

Möchte sich vielleicht mal jemand des Problems annehmen? Der Scroll-Bug existiert immer noch... UND NERVT! :-( --Sassenburger (Diskussion) 19:43, 3. Mai 2014 (CEST)

Ich kann (leider) nicht mehr unterstützen, da ich kein Zugriff mehr auf einen IE8 habe. Der Umherirrende 19:54, 12. Mai 2014 (CEST)

Man muss doch zu dem Stand VOR dem Bug zurückgehen können (Versionsgeschichte)? Oder war aus technischen Gründen Quellcode erforderlich, der nun diesen Bug auslöst? --Sassenburger (Diskussion) 23:30, 12. Mai 2014 (CEST)

Ich bin hier nicht involviert, und ich habe auch keine Ahnung, was die Leute von der weltweiten Wiki-Programmierung dazu getrieben hat, diesen IE8-Fix herauszunehmen.

Aber du kannst ja mal zur Selbsthilfe greifen:

1. Special:Mypage/common.css zum Bearbeiten öffnen.
2. Die folgenden Zeilen hineinkopieren:

#wpTextbox1 {
  height: 390px;
  width: 500px;
  min-width: 100%;
  max-width: 100%;		
}

Speichern; schaun, was passiert.

Viel Erfolg --PerfektesChaos 23:59, 12. Mai 2014 (CEST)

Super!!!! Der Bug ist weg! Die Firma sagt danke! :-D --Sassenburger (Diskussion) 00:07, 13. Mai 2014 (CEST)

Nö, der Bug ist noch da; aber den hat jetzt ein anderer … --PerfektesChaos 00:14, 13. Mai 2014 (CEST)

Darstellungsfehler QS-Baustein in Mobilversion

<ü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.

--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)

Revertkonflikt endlich beheben

Wann wird der Bug, der bewirkt, dass bei einem Revert kein BK angezeigt wird, endlich behoben? Es steht ja sogar auf WP:BK, dass kein BK angezeigt wird, wenn revertiert wird, während man selbst gerade bearbeitet/revertiert, dadurch habe ich heute bereits zweimal vermeintlich "vandaliert", weil jemand mir mti dem Zurücksetzen von Vandalismus zuvorkam und ich auf die vandalierte Version zurücksetzte... Mariofan13★^{Sprich mit mir!} 13:41, 9. Apr. 2014 (CEST)

Crossposting ohne Referenz ist böööse ;-) Kommt original von FzW. Hier ist aber meiner Meinung nach aber eine Fehlbedienung von Huggle oder ein Bug darin, wenn überhaupt dann eher API-Ding, aber nicht normale Oberfläche.--se4598 / ? 16:09, 9. Apr. 2014 (CEST)

Hover-Effekt bei Imagemaps

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)

Wikipedia:Hauptseite/Jahrestage/Bearbeitungshinweise

Unter Wikipedia:Hauptseite/Jahrestage/Bearbeitungshinweise und Wikipedia:Hauptseite/Jahrestage wird die Einbindung von Bilder folgendermaßen empfohlen:

• Bilder auf korrekte Lizenzierung überprüfen und wie folgt einbinden (vermeidet weiße Rahmen): <div style="float:right; padding-left:0.5em; display:table">[[Datei:Dateiname.jpg|85px|Text Bildbeschreibung]]</div>

Wozu ist hier das display:table notwendig? Kann das nicht entfallen? Weiße Rahmen um Bilder gibt es seit rev:79010, rev:79011 und rev:79086 nicht mehr. --Fomafix (Diskussion) 08:54, 30. Apr. 2014 (CEST)

Das display:table ist ein Workaround für einen Darstellungsfehler in sehr, sehr alten Opera-Versionen. Es schadet mit hoher Wahrscheinlichkeit nicht, sollte aber auch nicht mehr nötig sein. --Entlinkt (Diskussion) 17:44, 30. Apr. 2014 (CEST)

Bildverlinkungen in Galerien unterdrücken?

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)

Ruckeln der Seite beim Laden von Navigationsleisten vermeiden

Hallo,

Punkt 1: Das Ein- und Ausklappen der Navileisten geschieht momentan, indem der Code in MediaWiki:Common.js bei einigen Elementen die display-Eigenschaft zwischen block und none hin- und herschaltet. Allerdings setzt der Code die Eigenschaft bei standardmäßig ausgeklappten Leisten initial nicht (sondern erst beim ersten Zuklappen).

Punkt 2: Folgendes Problem: Beim Seitenaufbau sind die Leisten initial alle ausgeklappt und werden durch das Skript teilweise eingeklappt. Dies führt zu einem Ruckeln beim Seitenaufbau, das bei normalen Navileisten am Artikelende lästig, aber nicht besonders störend, bei kreativeren Verwendungen wie in der Vorlage:Infobox hochrangige Straße allerdings besonders störend ist (Beispiel: Artikel Bundesautobahn 2; bei mir ändert sich die Breite der Infobox wärend des Ladens der Seite).

Punkt 2 ließe sich m. E. relativ elegant mit einer CSS-Regel ähnlich der folgenden lösen:

.client-js div.NavPic,
.client-js div.NavContent {
	display: none;
}

Dadurch würden nicht mehr die standardmäßig eingeklappten, sondern die standardmäßig ausgeklappten Leisten ruckeln, was m. E. deutlich weniger stört.

Problem an dieser Stelle ist jetzt Punkt 1: Das Skript müsste so angepasst werden, dass die standardmäßig ausgeklappten Leisten initial (also auch vor dem ersten Zuklappen) display: block haben. Wäre das machbar und was wäre von dem gesamten Vorschlag zu halten?

Gruß --Entlinkt (Diskussion) 21:34, 12. Mai 2014 (CEST)

Ob das technisch machbar ist, kann ich nicht beurteilen; da mir dieser Klappeffekt aber gerade aufgefallen ist: in der Sache dafür! Gruß, IW 20:46, 21. Mai 2014 (CEST)

Technisch machbar ist das auf jeden Fall, ich bräuchte nur jemanden, der die oben beschriebene marginale Änderung in MediaWiki:Common.js vornimmt (der Navileistencode muss schon beim ersten Laden der Seite und nicht erst beim ersten „toggle“-Vorgang die display-Eigenschaft aller Navileisten setzen).

Die Änderung ist absolut trivial, ich kann sie aber nicht selbst vornehmen, weil ich die JavaScript-Programmierkonventionen, die sich in den letzten Jahren massiv geändert haben, nicht kenne. (Ich habe zwar schon in der Datei editiert, das waren aber immer nur Löschungen und keine Hinzufügungen.) --Entlinkt (Diskussion) 04:58, 22. Mai 2014 (CEST)

Ein CodeStyle oder andere Konventionen gibt es auf MediaWiki:Common.js nicht wirlich. Ich hatte nur mal einige Dinge in jQuery umgewandelt, damit man sich weniger Gedanken um Browserkompatibilität machen muss. Manches sieht auch einfacher aus und escaping kommt manchmal auch direkt mit. Also nur zu, jeder Admin kann meine Änderungen auf der Seite gerne overrulen. Es wird wohl noch lange dauern bis erfahrende JavaScript-Benutzer die notwendigen Rechte wohlen und/oder bekommen. Der Umherirrende 19:54, 23. Mai 2014 (CEST)

• Technisch möglich ist alles Mögliche.
  • Die Frage ist nur, was wir sinnvollerweise anbieten und unterstützen und warten und pflegen sollen.
• Eigentlich ist das ein (geduldeter) Missbrauch der Nav-Klappfunkion.
  • Ich hab ja Verständnis und Sympathie dafür, dass es bei A2, A7 oder Transamericana ziemlich lang wird; jeder Bach, der in die Donau fließt, landet wohl auch in deren Infobox.
  • Wir fördern die Nutzung der Klappmechanismen aber nicht, und bieten auch absichtlich keine ausgefeilte deutschsprachige Doku an.
  • Die fraglichen Infoboxen sollten dann besser class="mw-collapsible" verwenden.
• mw-collapsible
  • wird weltweit zentral gewartet, wir müssen uns nicht um die Pflege kümmern.
  • unterstützt ausdrücklich Vorgaben für initialen Zustand. Ohne JS wird immer ausgeklappt dargestellt, weil ohne JS der Leser sonst dumm sterben müsste.
  • 2012/13 gab es mal einen Bug mit irgendeiner dämlichen Animations-Spielerei. TMg hatte sich mähtig darüber aufgeregt. Ich weiß nicht, ob der heutzutage immer noch drin ist.
  • Siehe Wikipedia:Technik/Baustellen/collapsible Herausforderung zu Details.
• In Artikeln ist die Klapperei unerwünscht.
  • Entweder die Information ist enzyklopädisch relevant, dann soll sie sichtbar sein; oder sie ist unwichtig, dann soll man sie weglassen. Oder man legt gesonderte Listenartikel an und lagert endlose Tabellen dorthin aus.
  • Wenn man das noch propagiert und erleichtert, werden die Artikel zu Adventskalendern umgebaut, und erfahrungsgemäß wird von einer nennenswerten Minderheit jede bunte Spielerei eingebastelt, völlig egal ob sie in der Situation sinnvoll ist oder nicht.
• Unser Nav-Zeugs sollte perspektivisch aussterben.
  • Ich will da nicht weiter dran rumprogrammieren.
  • Dann bin ich auch noch schuld, wenn irgendeine Browser-Version rumspinnt.
  • Nebenwirkungen und Performance durchschaue ich grad nicht.
  • Vielmehr sollte das eines schönen Tages Bot-gestützt Zug um Zug durch mw-collapsible ersetzt werden.
  • Voraussetzung wäre, dass mw-collapsible robust läuft. Bin nicht aktuell, kenne keine Beschwerden.
  • Schon allein dass eine Funktionalität explizit das „Nav“ im Namen trägt, signalisiert, dass dies einen spezifischen Verwendungszweck hat und kein Maßstab für universelle Artikel-Dynamik sein kann; auch nur für diesen einen spezielle Anwendungsfall gewünscht ist.

Nebenbei: Bei einer seit neun Jahren existierenden ID (kein „Klassenname“) hätte ich mich ja gehütet, sie aus ästhetischen Gründen umzutaufen. Sehen kann die ID nur ein Profi; wenn sie überhaupt einen Sinn hätte und dies jemand in Benutzer- oder Browser-CSS oder JavaScript verwendet hatte, dann ist das jetzt broken; und wer es später neu mit „Ü“ versucht hatte und erfolglos blieb, guckt (vorher) in den Quelltext, ob überhaupt und wenn ja welche ID vereinbart ist.

Sonnigen Tag --PerfektesChaos 09:10, 22. Mai 2014 (CEST)

Das ist natürlich ein Klassenname (class=) und keine ID (id=), bisher gab es wegen übereinstimmender Formatierung der Überschriften in Monobook und Vector (und in den 9 Jahren davor auch in den anderen Skins) keinen Grund, ihn zu benutzen und deshalb wird er auch nicht benutzt, was natürlich vor der Umbenennung geprüft wurde. Durch die Nicht-mehr-Übereinstimmung seit dem Typografie-Update letztens gibt es den nun aber doch, inklusive einer Anfrage, die Formatierung in unsere CSS-Dateien zu verlagern. Also passt man den unbenutzten Namen besser an die wikipediaweit allgemein übliche Konvention an, bevor damit begonnen wird, ihn zu benutzen.

Zurück zum Thema: Danke für die Ausführungen zu Navileisten, wegen genau solcher Bedenken fragte ich in diesem Fall nach. Allerdings denke ich nicht, dass sich irgendwer in absehbarer Zeit (~ etliche Jahre) daran trauen wird, unseren alten Code durch mw-collapsible zu ersetzen, weil letzteres wegen der leidlich funktionierenden Animation von zahlreichen Benutzern abgelehnt wird. (Im Gegensatz zu dem vorgenannten Klassennamen sieht den Unterschied zwischen NavFrame und mw-collapsible wirklich jeder und deswegen ist damit zu rechnen, dass das nicht nur Leute stören wird, die nach etwas suchen.)

Die Ablehnung von mw-collapsible geht so weit, dass die Verwendung aktuell sogar per Missbrauchsfilter protokolliert wird. Die Zweckentfremdung der NavFrame-Klasse in der fleißig ruckelnden Vorlage:Bilderwunsch ist dagegen durch ein Meinungsbild abgesegnet und neulich las ich auf den Fragen zur Wikipedia die Ankündigung eines Meinungsbilds, das mw-collapsible abschaffen möchte. Gruß --Entlinkt (Diskussion) 04:30, 23. Mai 2014 (CEST)

• Ü1 nehme ich mit dem Ausdruck des Bedauerns zurück; hatte nicht genau hingeguckt und die Erwartungshaltung hinsichtlich aller anderen Vorlagen-ID in den mageren Teil des Diff projiziert.
  • Als Klassennamen hätte ich allerdings Überschrift1 erwartet: Weder das Präfix Vorlage_ noch der Hinweis auf eine Simulation sind für die Klassifizierung relevant; das soll ja gerade für die Zuweisung einer Eigenschaft genutzt werden, völlig egal wo und wie von der Klasse Gebrauch gemacht wird. Das ist dann allerdings schon vor neun Jahren vergeigt worden.
  • Aus diesem Grund hatte ich das class= auch nicht wahrgenommen.
  • Weiter in der Schwesterwerkstatt.
• Als 2011 der Bilderwunsch geschrieben wurde, gab es noch kein mw-collapsible.
• Es gibt drei Infoboxen für langgestreckte geografische Gebilde: Hochrangige Straßen, Flusssysteme und Bahnstrecken. Für diese drei und den Bilderwunsch ist eine initiale Einklappung sinnvoll; und hier sollte auf das vermutlich ruckelfreie mw-collapsible mw-collapsed umgestellt werden. Das bekäme noch nicht einmal der MBF mit.
• Man sollte bei MW anregen, einen JS-Parameter für das Abschalten der Animiererei einzuführen.
  • Dann könnte die deutschsprachige Wikipedia das komplett abschalten.
  • Anime-versessene Benutzer können das dann persönlich übersteuern und wieder aktivieren.
  • Bisher wird ohne duration-Parameter übergeben an
    • .fadeOut() / .fadeIn() – Tabellen-Zellen
    • .slideUp() / .slideDown() – sonst
  • Ein Konfigurationsparameter, der bei Nichtvorhandensein im Moment des Anklickens auf Standard=400ms zurückfällt und von uns auf Null gesetzt werden kann (oder von Langsamdenkern auch auf 2000ms) würde die Animation unterdrücken.
  • Preisfrage wäre, wohin und wie man diesen Konfiguartionsparameter benennen soll; es gibt kein Anwendungsobjekt und keine Struktur zum Andocken und damit nur einen globalen Namen, was weniger schön ist.
  • Benutzer:Umherirrender?
• Bis ein breiter Konsens über das Verhältnis von Klappspaten und Enzyklopädie ermittelt wurde, werde ich das Feature ansonsten nicht fördern und mich neutral verhalten.

LG --PerfektesChaos 10:07, 23. Mai 2014 (CEST)

Ich glaube nicht, das man eine Abschaltfunktion für die Built-In-Klapp-Funktion durch den Code-Review bekommt, du kannst deine Ideen/Wünsche aber über Bugzilla einbringen, vielleicht irre ich mich auch. Vielleicht gibt es auch Zustimmung von anderen. Der Umherirrende 19:54, 23. Mai 2014 (CEST)

@Umherirrender: Ein Missverständnis? Es geht nicht um das vollständige Abschalten der Funktion, sondern um das optionale Abschalten der Animation durch Reduzierung der duration von 400ms auf 0. LG --PerfektesChaos 21:08, 23. Mai 2014 (CEST)

Ich meine mal gelesen zu haben, das extra auf fade umgestellt wurde, damit es Benutzern möglich ist, das zu deaktivieren (jQuery.fx.off). Ob man die Standardwerte für slow, fast oder default auch so beeinflussen kann, weiß ich nicht. Der Umherirrende 21:33, 23. Mai 2014 (CEST)

jQuery.fx.off sagt mir jetzt nichts? Klingt aber so, als würde dadurch die Funktionalität ganz abgeschaltet. Klappen soll es ja noch, aber auf einen Schlag und ohne Spielkram. --PerfektesChaos 21:49, 23. Mai 2014 (CEST)

OK, ich hab es jetzt einfach mal umgesetzt (im „alten“ Stil, genau wie der bisherige Code). Die „kreativen“ Verwendungen in Infoboxen und Bilderwünschen sind übrigens nur ein Grund unter vielen; ich finde das selbst bei „genuinen“ Navileisten so herum sinnvoller, weil es immer besser aussieht, wenn während des Seitenaufbaus etwas dazukommt, als wenn etwas kurz da ist und dann wieder verschwindet. --Entlinkt (Diskussion) 20:19, 23. Mai 2014 (CEST)

@PerfektesChaos: Ist zwar wirklich off-topic an dieser Stelle, aber ich wollte das doch mal sagen: MediaWiki bildet seit jeher für jede Wikiseite einen charakteristischen Selektor am <body>-Element, bestehend aus page- gefolgt von dem Seitennamen, in dem lediglich Zeichen, die man in CSS escapen müsste, durch Unterstriche ersetzt sind. Für diese Seite lautet dieser Selektor beispielsweise page-Wikipedia_Technik_Werkstatt. Und in Vorlagen ist es wiederum seit langer Zeit üblich, diesen Selektor ohne den Präfix page- – aber mit Vorlage_ – zu übernehmen. Das wird in Hunderten von Vorlagen so gemacht und ich habe – wie dem Bearbeitungskommentar auch zu entnehmen ist – lediglich an diese Praxis angepasst, denn Umlaute braucht man in Klassennamen nicht zu escapen (dies tut MediaWiki auch nicht), im Übrigen entsprach der Selektor aber bereits der üblichen Form. Gruß --Entlinkt (Diskussion) 16:59, 24. Mai 2014 (CEST)

Ich fürchte, wir reden etwas aneinander vorbei.

Mir ging es im Zusammenhang mit der aktuellen Typografie-Debatte schwerpunktmäßig um die einheitliche Formatierung von Überschriften und Simulationen; also um eine von außen zugewiesen Formatierung der Überschrift.

Dass Vorlagen Selektoren zugewiesen bekommen, so dass die Einbindungen auch im HTML-Dokument noch identifizierbar wären (kurioserweise teilweise aber auch als id= – aber das bei Vorlagen, die es nur einmal geben sollte) ist eine andere Geschichte; ich hatte die falsche Erwartungshaltung beim Blick auf den Diff und schlicht nicht richtig hingeguckt; bzw. die selektive Wahrnehmung hatte zugeschlagen.

Kurios ist, dass ich nur extrem selten sehe, dass jemand hinterher in Benutzer-CSS oder anderweitig von diesen mühsam verteilten Selektoren Gebrauch macht, sieht man einmal vom Ausblenden bestimmter Hinweistexte ab. Eigentlich sehe ich nur Letzteres.

Unglücklich finde ich, dass dieses Projekt in dem zurückliegenden Dutzend Jahre nie dokumentiert hatte, was es mit den selbst vergebenen Selektoren anstellt, welche es gibt, wie sie aufgebaut sein sollen, wo sie hingehören – der erste Ansatz dazu kam von mir, und ich breche unter der Nachhollast der unterbliebenen Dokumentationen und Beschreibungen zusammen.

LG --PerfektesChaos 17:30, 24. Mai 2014 (CEST)

Typografie-Helferlein; Erweiterte Beobachtungsliste

Hallo. Seit einigen Tagen funktioniert bei mir das Typografie-Rückgängig-Helferlein nicht mehr (Überschriften werden mit Serifen angezeigt, Text scheint aber wie vorher zu sein). Auch werden die Pfeile zum Ausklappen mehrerer Änderungen an einer Seite in der Beobachtungsliste nicht mehr angezeigt. Ich nutze Konqueror 4.13.1. Leider muss ich zur Zeit auf den Firefox ausweichen. Weiß jemand, wo das Problem herkommt? Oder wie ich es beheben kann? – Giftpflanze 22:29, 27. Mai 2014 (CEST)

Bugmeldung MediaViewer: unvollständige Darstellung nach Vollbildanzeige

Moin, gemäß Hinweis auf Hilfe:Medienbetrachter#Wie kann ich ein technisches Problem melden? melde ich hiermit den folgenden Bug.

Umgebung: FireFox 29.0.1, Windows Vista SP2.

WP-Situation: eingeloggt, Vector.

Ergänzender Hinweis zur WP-Situation: Bug tritt ebenfalls auf, wenn ich nicht-eingeloggt – also als IP – die im Folgenden genannten Schritte ausführe. Das mag die Fehlersuche erleichtern.

Testseite: Artikel Ata Demirer.

Vorgehensweise zum Nachvollziehen des Bugs (in Schritten):

1. Seite Ata Demirer in neuem TAB (!) aufrufen (OK).
2. Bild anklicken (es gibt nur eines dort). Daraufhin wird das Bild großformatig angezeigt. (OK) Unterhalb des Bildes werden weitere Angaben dargestellt, konkret "Ata Demirer 01, Gemeinfrei, Lycentiex - Eigenes Werk, ..." (OK)
3. Im dargestellten Bild oben rechts Doppelpfeil "südwest/nordost" (unter "X") anklicken, daraufhin wird der Vollbildmodus eingeschaltet und das Bild vollformatig angezeigt und die Options-Buttons "erlauben" und "ablehnen" angezeigt. (OK)
4. Klicke auf "ablehnen". Daraufhin wird der MediaViewer verlassen und der Artikel Ata Demirer wieder angezeigt. (OK)
5. Klicke erneut auf das Bild (wie in Schritt #2). Daraufhin wird zwar das Bild großformatig angezeigt (OK), NICHT JEDOCH die "weiteren Angaben" aus Schritt #2, also "Ata Demirer 01, Gemeinfrei, Lycentiex - Eigenes Werk, etc." (BUG!).
6. Kehre zum Artikel zurück (klicke "X" rechts oben im Bild). Weiter dann mit Schritt #5 führt FOREVER weiterhin nicht zur Anzeige der "weiteren Angaben". (BUG!)

Einen diesbezüglichen "Reset" erreicht man, wenn man den Browser-Tab schließt und wieder mit Schritt #1 beginnt.

Gruß, --YAAA _NOOO? 21:35, 4. Jun. 2014 (CEST)

danke für die meldung. eingetragen unter bugzilla:66146 --se4598 / ? 01:10, 5. Jun. 2014 (CEST)

Lieben Dank für Deine Begutachtung und Unterstützung. --YAAA _NOOO? 01:55, 5. Jun. 2014 (CEST)

Problem mit Tabelle in der mobilen Version

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). → User: Perhelion 06:13, 1. Sep. 2014 (CEST)

Fehler bei dem Anchorjump nach dem Bearbeiten eines Abschnittes.

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?

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)

Probleme bei Datei-Löschungen

Seit heute bekomme ich zunehmend Fehlermeldungen beim Löschen von Dateien. Zu Beginn noch vereinzelt, inzwischen bei jeder Löschung taucht im ersten Versuch die Meldung Fehler bei Datei-Löschung: Im Speicher-Backend „local-swift-eqiad“ ist ein unbekannter Fehler aufgetreten. auf und die Datei wird nicht gelöscht. Der zweite Versuch der Löschung über Anklicken des Datei-Reiters und anschließend des Lösch-Reiters ist dann erfolgreich. Ich verwende Monobook. Bisher kann ich nur mit Sicherheit sagen, daß mein Arbeitsplatzrechner betroffen ist (Windows XP mit IE8). --Emergency doc (Disk) 20:29, 19. Aug. 2014 (CEST)

Einen ähnlichen Bug gibt es schon länger beim Upload, hat aber bislang niemand wirklich aktiv verfolgt. Standardfrage: Geht`s mit anderen Systemen? MfG Chewbacca2205 21:07, 19. Aug. 2014 (CEST)

Der Fehler kommt vom WMF-Server, müsste nach Hilfe:Bugzilla. Da es ähnliches auf hu.wp gibt, wird es wohl getrackt: Bug 69717. Der Umherirrende 21:12, 19. Aug. 2014 (CEST)

Die Bugzillameldung wegen dem Upload hatte ich gesehen. Hier hab ich das zuerst angesprochen, andere Benutzer hatten diese Probleme nicht. Wenn ich morgen zu hause bin kann ich es auf einem Xubuntu 14.04 mit Chromium testen. Hier hab ich nur meinen Arbeitsplatzrechner.--Emergency doc (Disk) 21:17, 19. Aug. 2014 (CEST)

Jetzt (auch) Bug 69760, könnte schon behoben sein. Der Umherirrende 19:28, 20. Aug. 2014 (CEST)

Tja, hat sich durch die zahlreichen Meldungen auch aus anderen Projekten zwar schon bestätigt, aber: Es ist nicht abhängig vom benutzten System. Sowohl auf meinem Xubuntu-Rechner als auch auf einem Android-Smartphone taucht das auf. Behoben ist das bis jetzt noch nicht. Gruß--Emergency doc (Disk) 22:04, 20. Aug. 2014 (CEST)

MediaWiki:Gadget-osm.js

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)

Leerzeilenbug

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: Perhelion 16: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)

„VM“, neues Signaturbild und kaputter Button in Werkzeugleiste

Hallo, gleich wieder was zur Werkzeugleiste (allerdings zur erweiterten, und ohne persönliche Veränderungen): Seit einiger Zeit gibt es nun den blauen Button für den (grundsätzlich praktischen) Vorlagenmeister, der allerdings nicht selbsterklärend ist, da die verwendete Abkürzung im Tooltip „VM“ lautet, was ich bislang nur als Vandalismusmeldung kannte. Sinnvollerweise sollte das Tooltip die vollständige Bezeichnung enthalten. Störender ist neuerdings allerdings der Button gleich rechts davon, „Signatur und Zeitstempel“: Wieso ist da jetzt plötzlich ein anderes Bild? Statt dem gewohnten blauen Stift sehe ich nur noch ein unscheinbares Gekritzel, das natürlich nicht mehr übereinstimmt mit den ganzen Signatur-Hinweisen in Bearbeitungshinweisen u. ä. Ich treffe den Button ja trotzdem, aber sowas muss doch nicht sein! Und noch was: Der Button für „Suchen und Ersetzen“ funktioniert nicht mehr, das Fenster wird nicht aufgerufen! Im Moment verwende ich Vector-Skin mit Internet Explorer 10.0.--XanonymusX (Diskussion) 22:27, 28. Sep. 2014 (CEST)

Hab mal verglichen, bei Iron/Chrome besteht kein Problem, beim IE weiterhin.--XanonymusX (Diskussion) 20:27, 3. Okt. 2014 (CEST)

PDF erstellen

Gemeldet in Bugzilla
Bug 71286

Moin Moin fleißige Techniker,

ich habe folgendes Problem:

Wenn ich eine PDF erstellen möchte macht Wiki diesen Murks:

Er erstellt eine Datein mit diesem Namen:

939975a094033b38618d9a2f16e2ee36ac8ab889

Die Datei ist 36,5KB groß und jedenfalls keine PDF. Das Problem trat in Chrome und Firefox auf. Etwa seit 4 Tagen funktioniert das PDF erstellen nicht mehr, ebenso die Buchfunktion arbeitet mit dem gleichen Fehler.

Bitte helft mir!

MFG Christoph (nicht signierter Beitrag von 89.246.56.36 (Diskussion) 12:39, 2. Okt. 2014 (CEST))

Die Generierung der PDFs wurde vor ein paar Tagen umgestellt und hat noch einen Bug, siehe WP:FzW#PDF-Funktion. Grüße sitic (Diskussion) 14:20, 2. Okt. 2014 (CEST)

Vielen Dank! (nicht signierter Beitrag von 89.246.17.86 (Diskussion) 17:32, 2. Okt. 2014 (CEST))

Moin Moin, ich finde die neue Software zu erstellung der PDF k...e. Die andere war klasse, bis auf die Bugs bei manchen Tabellen und Formeln. Das ist schade, dass ihr euch da eine neue angelacht habt! Ihr macht so gute Arbeit, aber die Entscheidung für dieses zweispaltige Grauen kann ich nicht verstehen. Achja und die neue Funktion hat auch noch nicht die Tabellen implementiert. Warum stellt ihr sowas um bevor es läuft? MFG (nicht signierter Beitrag von 89.246.26.249 (Diskussion) 12:58, 15. Okt. 2014 (CEST))

Alt-Texte im Screenreader

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:

• Bei den meisten Bildern sehe ich den Alt-Text mit Firefox, und bei Wikinger08 wird er vom Screenreader präsentiert. Beispiel: Elsa Brändström, Bild ganz oben.
• In (bisher) einem Fall sehe ich den Alt-Text mit Firefox, der Screenreader hingegen erkennt ihn nicht: Thomas Rhodes Armitage. Wikinger08 hat noch ein Beispiel gefunden: Benutzer_Diskussion:Wikinger08#Aral

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

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)

Falscher Pfad nach Link Extractor (LEA)

Statt //tools.wmflabs.org/tools.render/ ist seit einiger Zeit //tools.wmflabs.org/render/ richtig. Es reicht nun aber nicht, den Pfad zweimal im von tools.wmflabs.org/render/stools/articleMonitor nach Thoken/common.js kopierten Code zu korrigieren: Der Popup des Reiters "Article Monitor" der Navigation rechts oben in Artikeln enthält den falschen Link [10].
Was mache ich da falsch? Wo ist der Code, der funktioniert? --Thoken (Diskussion) 22:26, 23. Okt. 2014 (CEST)

1. Du vermutlich überhaupt nichts.
2. Es war ein Rückfall ins letzte Jahrhundert, auf toollabs:stools/articleMonitor so eine ewig lange so hochgradig detaillierte Code-Sequenz zum Kopieren für jeden Benutzer anzubieten.
   • Wie man das richtig macht, steht in den ersten Zeilen deiner common.js – das Innenleben kann zentral gewartet werden und belastet nicht die Anwender.
   • Die Code-Sequenz steckt voller Details, die schon veraltet sind, zur Zeit der Erstellung von dem Zeugs schon obsolet waren und noch Probleme machen werden. Sowas behält man für sich.
   • Das erinnert an unsere Monobook-Kopierer aus dem letzten Jahrzehnt, wo einer die monobook.js vom Kollegen kopiert hatte.
   • Für die professionellen Informatiker, die WMDE angestellt hatte, ist es eine Bankrotterklärung.
3. Ich vermute, die ungültigen Links stecken in etwas, das aktuell vom Server abgerufen wird.
4. Ein Gutes hat der Umstand, dass du die ganzen Zeilen lokal hast: Man kann simpler manipulieren (ginge aber sonst auch nachträglich).
   • Füge mal probehalber Diagnostik-Meldungen ein wie folgt:
     • Nach link = part[1]; die Zeile

       alert("link="+link);

     • Vor value = "<a href=' die Zeile

       alert("value[1]="+value[1]);

   • Danach erzähl mal, was da drinsteht.
5. Wenn das die beanstandeten Links sind, kannst du die alert-Zeilen ersetzen durch:
   • link = link.replace( /\/tools\.render\/toolkit/, "/render/toolkit" );
   • value[1]= value[1].replace( /\/tools\.render\/toolkit/, "/render/toolkit" );

Viel Erfolg --PerfektesChaos 00:09, 24. Okt. 2014 (CEST)

Danke, deine Vermutung (#3) trifft's: Es ist der getJSON-Aufruf (url abgekürzt), der den falschen Pfad zurückgibt, der dann in value[1] steht.
Dein Fix mit value[1].replace funktioniert. Der Pfad zum Server steht offenbar als Konstante im Server-Skript/-Datensatz und wird dem armen Anwender zur Benutzung überlassen. Dass der Server die Adresse wechselt, –  also mit SOWAS kann ja keiner rechnen. --Thoken (Diskussion) 17:23, 24. Okt. 2014 (CEST)

Server-Reply auf getJSON-Aufruf, Beispiel Soissons:

({"asqmResponse": {"statistics":{"title":"Statistiken","items":{"Seitentitel":"Soissons","Angelegt am":["multipart","16.02.2004 10:50"," (","von ",["J\u00f6rny","https:\/\/backend.710302.xyz:443\/https\/de.wikipedia.org\/wiki\/User:J%C3%B6rny"],")"],"Letzte \u00c4nderung":["multipart","24.10.2014 16:30"," (","von ",["Udo T.","https:\/\/backend.710302.xyz:443\/https\/de.wikipedia.org\/wiki\/User:Udo+T."],")"],"Autoren":"88 (+IP: 13)","Einzelnachweise":3,"Mediendateien":"9","Besucher gestern":28,"Besucher im letzten Monat":1292}},"analysis":{"title":"Analysen","items":{"Linkvergleich":["Verweise mit dem Link Extractor pr\u00fcfen","https:\/\/backend.710302.xyz:443\/http\/tools.wmflabs.org\/tools.render\/toolkit\/LEA\/index.php?submit=1&title=Soissons&lg=de&lang=de"],"Autorenverteilung":"WikiGini-Werte werden gerade berechnet"}},"assessment":{"title":"Bewertungen","items":{"Wikibu.ch":["Bewertung ansehen","https:\/\/backend.710302.xyz:443\/http\/wikibu.ch\/search.php?search=Soissons"]}}}}) @Abraham Taherivand (WMDE): ping --Thoken (Diskussion) 12:53, 27. Okt. 2014 (CET)

Hallo Thoken, das Problem hing mit einer Änderung der Benutzernamen auf Labs zusammen, die an uns vorbeigegangen ist. Wir haben das behoben, der Artikelmonitor läuft jetzt auch ohne den von PerfektesChaos vorgeschlagenen Workaround. Viele Grüße Kai Nissen (WMDE) (Diskussion) 11:23, 11. Nov. 2014 (CET)

@Kai Nissen (WMDE): Stimmt, PerfektesChaos' Workaround ist nicht mehr nötig, was der getJSON-Aufruf liefert, sieht ok aus.

Pfade im nach common.js kopierten aktuellen toollabs:render/stools/articleMonitor-Code müssen aber immer noch per /tools.render/ → /render/ korrigiert werden, s. common.js history. --Thoken (Diskussion) 20:35, 11. Dez. 2014 (CET)

HTML5-Quelltext der Artikel teilweise nicht standardkonform

Hallo,

wenn ich Artikel wie den über die Bibel als ziemlich ausführliche Artikel durch die Validierungsfunktion des W3C jage, kommt ein ganzer Haufen von Fehlermeldungen: Ergebnisse. Ich vermute, dass dieses Problem wikipediaweit besteht und nicht nur in der deutschen Version, da dasselbe auch in der englischen Ausgabe des Artikels passierte. Es wäre schön, wenn Wikipedia als Vorzeigeprojekt eines altruistischen Internets zu HTML5 komplett standardkonform wäre. Ich selbst verfüge leider nicht über den technischen Hintergrund, um die Fehler zu beheben. Danke für eure Aufmerksamkeit. (nicht signierter Beitrag von 87.149.68.13 (Diskussion) 2014-12-04T17:35:43)

• Die cellspacing- und cellpadding-Meldungen kommen aus {{Bausteindesign1}} (hier über {{Dieser Artikel}} und {{Belege fehlen}}).
• Die dl-Meldungen kommen aus dem Missbrauch von Definitionslisten für Unterüberschriften im Abschnitt Literatur. Bei allen Diskussionsseiten wird wegen des Missbrauchs für Einrückungen eine ähnliche Meldung ziemlich sicher bestehen bleiben.
• Die "Bad extlang subtag"-Meldungen (und ähnliche) kommen von den Interlanguagelinks. Da möge jemand anderes schauen, ob man das ändern kann bzw will und wenn ja wo man das ändern kann. Einige sind jedenfalls sicher nicht gültig (z.B. lang="simple").
• "Attribute action [and text] not allowed on element a at this point" kommt vom Wikidata-Interlanguagelinks-Bearbeiten-Link. Einen Nutzen der beiden Attribute sehe ich gerade nicht.

Ich hätte jedenfalls mehr Meldungen befürchtet. --nenntmichruhigip (Diskussion) 07:32, 5. Dez. 2014 (CET)

Es ist ziemlich wumpe, ob Stand heute die HTML-Dokumente absolut standardkonform sind; der HTML5-Standard gibt uns nur eine Marschrichtung für zukünftige Weiterentwicklungen.

• Die Browser unterstützen Formate bis zurück in die Mitte der 1990er Jahre; so schlecht sind die meisten unserer Seiten nun auch wieder nicht.
• Stümperhafte Versuche in der Vergangenheit, mit Gewalt absolute HTML5-Konformität zu erzwingen, hatten zu einer massiven Beschädigung von Artikeln sowohl hinsichtlich der Darstellung wie auch der scheinbaren Inhalte geführt.
• Richtig ist, dass wir tendenziell die Integrität unserer Wikitexte verbessern und modernisieren sollten.
• Für manche Syntaxkonstrukte wie etwa cellspacing gibt es keine triviale Entsprechung. Hier kann es nur um die Verwendung der modernen Klassen (wikitable) gehen.
• Das lang-Attribut simple mag von der zentralen Mediawiki-Steuerung im HTML-Dokument umformatiert werden auf en-Simple – simple ist aber unser privater Code, der Welt unbekannt, wie es auch en-Simple wäre. Letzteres verrät jedoch, dass es eine Variation von Englisch sein muss und Englisch geeignete Rückfallposition für Anwendungen wie Screenreader.
• Die Überschrift des threads „HTML5-Quelltext der Artikel“ verrät aber einen fundamentalen Denkfehler und ein grundlegendes Missverständnis: Der Quelltext der Artikel, also der Wikitext, hat überhaupt nichts mit HTML5 zu schaffen und muss auch keinerlei HTML-Standards erfüllen. Wenn das langfristig angestrebt wird, dann gilt das nur für das HTML-Dokument, das beim Browser ankommt. Zwischen dem Wikitext und dem Browser liegen zurzeit mindestens zwei Instanzen (zukünftig auch noch weitere): der Parser und HTML Tidy.

VG --PerfektesChaos 13:11, 5. Dez. 2014 (CET)

Nicht schlecht eure Analyse (Betr. ich habe mal ein Redirect zu unserer tatsächlichen Vorlage:Vorlage gemacht). :) Ansonsten hätte ich Weiteres auf (den neu eingeführten) Phabricator verwiesen und ergänzend im Zusammenhang auch auf WP:HTML5. ↔ User: Perhelion 13:25, 5. Dez. 2014 (CET)

Probleme aus den Navigationselementen sollten per individuellen Task auf Phabricator bekannt gemacht werden, vielleicht findet sich jemand, der die entsprechenden Ersetzungen machen kann. Nicht alles zusammen, da es teilweise auch Erweiterungen betrifft (Wikidata zum Beispiel). Der Umherirrende 17:12, 5. Dez. 2014 (CET)

Zu lang=simple scheint es eine Änderung gegeben zu haben, durch die nun das Wikimedia-Kürzel in einem Klassennamen steht. Jedenfalls meine ich, dass das davor nicht so war. Damit könnte man ohne Funktionalität zu entfernen (ich selbst habe bis eben das lang=simple ausgewertet :-) ) in lang und hreflang formal korrekte Sprachkürzel verwenden, und bräuchte auch keine Subsprachen erfinden. --nenntmichruhigip (Diskussion) 02:14, 8. Mai 2015 (CEST)

Benutzerbeiträge

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)

Überschriftensimulationen an Typografie-Update anpassen

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

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

Nächster Termin: Donnerstag, 28. November 2024

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

Achje.

   Nächster Termin: Mittwoch, 4. Dezember 2024

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 6. November 2024 noch nicht vorbei ist, so ist es dieser, ansonsten ist es 4. Dezember 2024. --Schnark 09:27, 30. Jan. 2015 (CET)

Das heißt, falls ich mich nicht verrechnet habe, ist das gesuchte Datum 4. Dezember 2024. 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! Vorlage:Smiley/Wartung/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: 3. April 2024. Wenn man das first weglässt (das ich nur von einem vorherigen Versuch drin hatte), müsste es gehen: 4. Dezember 2024 --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)

Windows Vista: Beim Verlassen des "Bearbeiten"-Modus IMMER Warnhinweis

In Windows Vista: Beim Verlassen des "Bearbeiten"-Modus kommt immer der Warnhinweis "Möchten Sie wirklich ...? Das Verlassen dieser Seite kann dazu führen ...", auch wenn darin absolut nichts angefasst wurde.
Problem tritt nicht auf: a) in Windows 7 (de:WP); b) unter Vista in der englischen, französischen, italienischen oder schwedischen WP. --Uli Elch (Diskussion) 11:02, 5. Feb. 2015 (CET)

(Schon lustig. ) Also eigentlich (sollte) ja die Meldung nur kommen wenn das Feld geändert wurde. Nun gibt es tatsächlich in den Einstellungen eine Option für den Check (also ein wikiinternes Script dahinter, welches ich nicht benennen kann). Was ich aber eher vermute ist ein Fremd-Script oder -Funktion die den Inhalt des Feldes in irgendeiner Weise verändert. ↔ User: Perhelion  11:11, 5. Feb. 2015 (CET)

Danke für die schnell erfolgte Antwort. Dann müßte sich Fremd-Script oder -Funktion blitzschnell und unsichtbar hinein schleichen, denn die Warnmeldung kommt ja nach "Bearbeiten" und sofort > "Abbruch" (oder Rückpfeil oben links). Vielleicht kennst Du ja noch irgendeinen Dinosaurier, der in der de:WP Vista benutzt; dann könnte man in der Tat sehen, ob es mein Privat-Problem oder ein allgemein deutsches ist. --Uli Elch (Diskussion) 11:32, 5. Feb. 2015 (CET)

Wichtiger als das Betriebssystem wäre der Browser. Hast du das Problem auch mit anderen Skins? Und ausgeloggt? --mfb (Diskussion) 16:12, 5. Feb. 2015 (CET)

+1

Der Browser (IE?) ist maßgeblich.

Die Wiki-Überwachung reagiert darauf, dass das Bearbeitungsfeld den Status „geändert“ erhält. Das kann durch eine Browser-Fehlfunktion erfolgen, würde aber in allen Sprachen gleich ablaufen.

Die Veränderung könnte durch unsichtbaren Whitespace ausgelöst worden sein, etwa ein Zeilenumbruch hinter dem Text, wenn noch keiner da war. Der Vergleich auf der Diffpage ignoriert das.

Interessant wäre, ob die Meldung auch mit einem anderen Browser kommt.

Fremd-Skripte sehe ich keine, weder hier noch global, höchstens Gadget/Common, aber dann müssten auch andere Benutzer berichten.

LG --PerfektesChaos 22:24, 5. Feb. 2015 (CET)

Der Quelltext liegt unter resources/src/mediawiki.action/mediawiki.action.edit.editWarning.js, falls sich das jemand anschauen möchte.

@Uli Elch: Die Info welcher Browser genutzt wird ist hier noch notwendig/wichtig. Eventuell mit einem anderen Browser auf dem Rechner versuchen ob das Problem auch existiert. Der Umherirrende 10:52, 7. Feb. 2015 (CET)

Hallo - ich mag zwar ein brauchbarer Schreiber sein, bin aber software-mäßig ein DAU! a) Immerhin habe ich jetzt herausgekriegt, dass ich offenbar einen "Internet Explorer 8" verwende; ich vermute, dass das der Browser ist. b) Was sind "andere Skins"? c) Problem Warnmeldung tritt wie beschrieben auch dann auf, wenn nicht als Benutzer in WP angemeldet. d) Was ist ein "anderer Browser", und wie kriege ich den zum Laufen - und dann wieder weg?

Jedenfalls Danke für die zahlreichen Hilfe-Versuche! Viele Grüße --Uli Elch (Diskussion) 17:04, 7. Feb. 2015 (CET)

• Dir kann ich zumindest umreißen, was eine „Skin“ ist: Hilfe:Skin.
• Rückfrage: In den anderen Sprachen und Wikis – hast du da auch überall das Häkchen gemacht auf der Seite Special:Preferences#mw-prefsection-editing beim überall dritten Kästchen, bei uns beschriftet: „Warnen, sofern eine zur Bearbeitung geöffnete Seite verlassen wird, die nicht gespeicherte Änderungen enthält“?
• Für Vista ist sicher auch das Download einer aktuelleren Version des IE möglich. Geht normalerweise recht einfach: Rechts außen in der Menüleiste ist ein „Über …“ oder „Hilfe“ – dort irgendwo gibt es „Browser aktualisieren“. Wäre wohl ratsam, weil auch sichereres Surfen.
• @Werkstattler:
  • IE, 8, soso. Ich könnte es geahnt haben.
  • Zur Funktionsweise: Der ursprüngliche Inhalt wird an ein data-Attribut gehängt; beim Versuch des Verlassens auf byteweise Identität geprüft.
    • IE8 könnte data nicht sauber unterstützen.
    • Ein Zeilenumbruch oder BOM könnte irgendwie hinzugekommen sein.
    • Müsste man aber eigentlich und weltweit mal von gehört haben.

Schönes Wochenende --PerfektesChaos 17:23, 7. Feb. 2015 (CET)

Schon mal schönen Dank, PerfektesChaos. a) Skin habe ich jetzt wohl so grob kapiert. b) In allen anderen erwähnten Sprachen und Wikis ist auch überall das erwähnte Häkchen gesetzt, genau wie in de:WP. c) Den Rest muss ich mir noch mal in Ruhe anschauen; IE neuer als IE8 soll irgendwelche Nachteile haben, muss noch mal einen befreundeten Experten fragen (auch, ob ich den neuen IE bei Bedarf wieder runter kriege!). Ulkig aber, dass es nur in der de:WP auftritt. --- Auch ein schönes Wochenende! --Uli Elch (Diskussion) 17:49, 7. Feb. 2015 (CET)

Misch-Namensraum Behelfs-Kategorie erstellen?

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__

• → pageprops → typeof .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)

Gemeldet in Phabricator
Task T47033

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)

Lokalisierte-Strings?

Gibt es evtl. ein (JS) Modul welches die selbe Funktion übernimmt wie {{int:…}}? Im Zuge der immer globaler werdender Scripte wäre das ein immenser Vorteil. Oder muss man sich die Schnipsel händisch von TranslateWiki holen (und komplett im Script hinterlegen)? ↔ User: Perhelion  11:43, 7. Feb. 2015 (CET)

Es kann mw.messages benutzt werden.

Damit kann innerhalb des Skriptes auf die Nachrichten zugegriffen werden.

Alle vorkommenden Systemnachrichten müssen aber vorher in der aktuellen Sprache definiert worden sein.

Bei Verwendung des RL werden diese in mw.loader.implement() usw. als Objekt mitgeliefert.

Hinterlegt werden müssen sie also in der Tat; wobei ein Wiki-Server, der das Objekt befüllt, direkten Zugriff auf die Übersetzungen hat.

LG --PerfektesChaos 15:03, 7. Feb. 2015 (CET)

Module:File

Verschiedene Funktionen geben Zugriff auf einige Dateieigenschaften; weiß jemand, wie ich zur Größe (in Bytes) kommen kann? Dazu muss es doch auch eine Variable geben, die ich aber nicht finden kann. sarang♥사랑 19:25, 10. Feb. 2015 (CET)

Dieses Modul macht zweierlei:

1. Die in Hilfe:Lua/Links #title.getFileInfo verfügbaren Informationen werden Vorlagen zugänglich gemacht.
2. Die in der Vorlage:Information auf der Dateibeschreibungsseite stehenden Infos werden ausgelesen.

Die Bytes gehören nicht zu den Angaben unter 1. – könnten aber eines Tages hinzukommen.

Hierzuwiki heißt das übrigens Wikipedia:Lua/Modul/FileMedia und kann perspektivisch und bei konkretem Bedarf die identischen Infos anbieten.

Nebenbei hätten wir für diese Anfrage die spezifische WP:Lua/Werkstatt – aber beim ersten Mal gibt es die Antwort auch hier.

LG --PerfektesChaos 20:26, 10. Feb. 2015 (CET)

Ah, du hast Glück:

• Expose file size and MIME to Lua voraussichtlich ab 25. Februar 2015.

Bräuchtest du das eigentlich auf Commons oder hierzuwiki?

LG --PerfektesChaos 09:34, 12. Feb. 2015 (CET)

Wie ich ihn kenne, ausschließlich auf Commons (wir hatten dbzgl. auch schon ein Gespräch und ich hatte auch die Lua-Werkstatt erwähnt). :-) ↔ User: Perhelion  11:54, 12. Feb. 2015 (CET)

Commons.js und Gadgets in den beiden sorbischen Wikipedien

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.
   • (siehe auch meine Edits hier)

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

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)

OSM

(Kopiert von Disku) --PerfektesChaos 22:17, 9. Mär. 2015 (CET)

Ich habe die Koordinaten in Liste der Stolpersteine im Kölner Stadtteil Mülheim eingetragen, die aber in der Übersichtskarte von OMS nicht angezeigt werden (vorher schon). Woran kanns liegen? -- Nicola - Ming Klaaf 20:20, 9. Mär. 2015 (CET)

mw-disambig – Hintergrundfarbe für BKL/BKS

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

Hallo,

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

• 11,93¹
• 11,94²
• 14,90³
• 7,20⁴
• 7,54⁵
• 9,86⁶

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:

• https://pl.wikipedia.org/wiki/Szablon:Sort
• https://pl.wikipedia.org/wiki/Wybory_samorz%C4%85dowe_w_Polsce_w_2014_roku#Wyniki_g.C5.82osowania

--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?

• Ich sehe auf pl:Wybory samorządowe w Polsce w 2014 roku #Wyniki głosowania nur für die erste Spalte eine Sortiermöglichkeit; alle anderen sind nicht sortierbar.

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

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

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)

If-Modified-Since

Seit einiger Zeit fällt mir auf, dass der Abruf von WP-Seiten ganz unverhältnismäßig viel Bandbreite beansprucht. Bei jeder Seite (egal was) wird ein knappes MB heruntergeladen. Wenn ich mir das mit Firebug ansehen, wird offenbar immer alles geladen. Zum Beispiel MediaWiki:Gadget-popups.js (ziemlich fett mit ca. 250kB), obwohl das längst im Cache ist. Die Header sind:

GET /w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript HTTP/1.1
Host: en.wikipedia.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:37.0) Gecko/20100101 Firefox/37.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: https://de.wikipedia.org/wiki/Langobarden
Cookie: ...
Connection: keep-alive
If-Modified-Since: Wed, 10 Dec 2014 23:42:14 GMT

HTTP/1.1 200 OK
Server: nginx/1.6.2
Date: Tue, 05 May 2015 07:24:12 GMT
Content-Type: text/javascript; charset=UTF-8
Content-Length: 252654
X-Content-Type-Options: nosniff
X-Powered-By: HHVM/3.3.1
Vary: Accept-Encoding
Last-Modified: Wed, 10 Dec 2014 23:42:14 GMT
X-Varnish: 3188909732, 2657218737, 1631950218
Via: 1.1 varnish, 1.1 varnish, 1.1 varnish
Accept-Ranges: bytes
Age: 0
X-Cache: cp1055 miss (0), cp3007 miss (0), cp3040 frontend miss (0)
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
x-analytics: https=1;WMF-Last-Access=05-May-2015
X-Firefox-Spdy: 3.1

Wenn ich das richtig verstehe, sollte der Server 304 statt 200 senden und nicht die 250kB noch einmal rüber schieben. Kann mir das jemand erklären? -- Wolfgang Rieger (Diskussion) 09:45, 5. Mai 2015 (CEST)

• Deine grundsätzliche Erwartung ist völlig berechtigt.
  • Es sind allerdings mehrere Aspekte an der bilateralen Kommunikation rätselhaft.
  • In dem oben dargestellten Beispiel hätte in der Tat auf ein If-Modified-Since ein 304 kommen müssen.
  • Allerdings haben wir nicht nur einen Server, sondern ein schizophrenes Sklavensystem. Master Boss hätte dir auch so geantwortet; dem Sklaven fehlte es an Einsicht.
  • Mir fällt beim spontanen Rumklicken auf, dass verschiedene andere Ressourcen (sofern sie nicht ohnehin mittels ResourceLoader im LocalStorage eingelagert wurden) hingegen mit 304 kommen, wie es deinen Erwartungen entspräche.
  • Mein flüchtiger Eindruck ist:
    1. Mein privater Browser-Cache ist mit 50 MB zu klein gewesen; ich kann mir das alles gar nicht merken.
    2. Die Regel für ein Expires durch MediaWiki ist recht konfus; mal fünf Minuten, mal nicht ganz exakt 30 Tage, mal 47 Sekunden.
• Ein Teil des Problems kann auch im Firefox und seinen Abfrage- und Verwaltungspraktiken liegen; er scheint mir grad sehr konservativ und misstrauisch vorzugehen.
• Genauso, wie ich anscheinend einen zu kleinen Cache habe, ist möglicherweise auf Seiten der Server irgendeine Tabelle zu klein für alle Seiten und Anfragen.
  • Dann gibt es nur miss statt wenigstens eines hit in X-Cache.
  • In diesem Fall weiß der (replizierende) Server nicht mehr so genau, wann die Seite im Originaltext zuletzt verändert wurde, und gibt sie sicherheitshalber komplett in der aktuellen Version zurück.
  • Die Hitliste wird aber von der Server-Administration kontinuierlich und engmaschig überwacht, und es wird versucht, eine optimale Balancierung zu finden. 200er Antworten bedeuten auch für die WMF-Seite erhöhten Netzwerktraffic, und man versucht wo immer möglich eine kurze 304er Antwort zu geben. Die Statistik wird täglich, minütlich, monatlich beobachtet und ausgewertet, und es wird versucht, Maßnahmen zu ergreifen.
• Ich habe jetzt bei einer Serie von Seitenaufrufen den Netzwerktraffic überwacht und in allen Fällen ein unter den gegebenen Umständen ordnungsgemäßes wenn auch teils unbefriedigendes Verhalten gefunden; wenn entweder Firefox es nicht weiß oder die expiry zu kurz ist und zur sofortigen Cache-Löschung im Browser führt oder der antwortende Server sich nicht mehr an die URL erinnern kann.

LG --PerfektesChaos 12:21, 5. Mai 2015 (CEST)

Hi, PG. Danke für Deine ausführliche Antwort. Dennoch: Das Verhalten ist bei mir jedenfalls reproduzierbar. Den Großteil des Traffics verursachen 3 Dateien, die jedesmal erneut geladen werden, nämlich Popup-Gadget, Vector-Skin und Hotcat-Gadget (insges. ca. 550 kB). Mit dem Browser-Cache kann es eigentlich nichts zu tun haben, denn der Browser wäre ja mit 304 zufrieden. Bei nur ganzen wenigen Dateien sendet der Server 304. Beispiel:

GET /w/static/1.26wmf3/resources/assets/poweredby_mediawiki_88x31.png HTTP/1.1
Host: de.wikipedia.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:37.0) Gecko/20100101 Firefox/37.0
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: https://de.wikipedia.org/wiki/MUED
Cookie: ...
Connection: keep-alive
If-Modified-Since: Wed, 22 Apr 2015 18:34:29 GMT
If-None-Match: "dc5-5145469d61740"

HTTP/1.1 304 Not Modified
Server: nginx/1.6.2
Date: Tue, 05 May 2015 11:27:31 GMT
Content-Type: image/png
X-Powered-By: HHVM/3.3.0-static
Last-Modified: Wed, 22 Apr 2015 18:34:29 GMT
Etag: "dc5-5145469d61740"
Expires: Sun, 31 May 2015 23:34:35 GMT
Access-Control-Allow-Origin: *
X-Varnish: 2343161719, 1629352778 1629349846, 1677625150 1104138953
Via: 1.1 varnish, 1.1 varnish, 1.1 varnish
Accept-Ranges: bytes
Age: 301975
X-Cache: cp1068 miss (0), cp3005 hit (5), cp3040 frontend hit (2867698)
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
x-analytics: https=1;WMF-Last-Access=05-May-2015
X-Firefox-Spdy: 3.1

Ich kann da nichts erkennen. Mein Browser-Cache ist bei weitem nicht voll, bei dem Expire-Datum sehe ich keinen Unterschied.

Dateien werdeb auch geladen, obwohl laut Response-Header X-Cache Hits da sind. Beipiel: Vector-Skin:

GET /w/load.php?debug=false&lang=de&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150504T195601Z HTTP/1.1
Host: de.wikipedia.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:37.0) Gecko/20100101 Firefox/37.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: https://de.wikipedia.org/wiki/Paul_Schultze-Naumburg
Cookie: ...
Connection: keep-alive
If-Modified-Since: Mon, 04 May 2015 19:56:01 GMT

HTTP/1.1 200 OK
Server: nginx/1.6.2
Date: Tue, 05 May 2015 12:01:11 GMT
Content-Type: text/javascript; charset=utf-8
Expires: Wed, 03 Jun 2015 19:57:02 GMT
X-Content-Type-Options: nosniff
X-Powered-By: HHVM/3.3.1
Vary: Accept-Encoding
Last-Modified: Mon, 04 May 2015 19:56:01 GMT
X-Varnish: 2441140267, 3059151757 3059151581, 1684806839 1575888861
Via: 1.1 varnish, 1.1 varnish, 1.1 varnish
Age: 57849
X-Cache: cp1065 miss (0), cp3003 hit (5), cp3040 frontend hit (1377979)
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
x-analytics: https=1;WMF-Last-Access=05-May-2015
X-Firefox-Spdy: 3.1

Was ist da los? Beste Grüße -- Wolfgang Rieger (Diskussion) 14:09, 5. Mai 2015 (CEST)

Keine Ahnung; die analytics sind solchen Effekten aber auf der Spur.

Bei einer Software, die pro Sekunde eine Million Antworten über mehrere Dutzend Server in die Welt schickt, mag es Mitte 2015 mal solche überflüssigen Antworten geben.

Solange sie inhaltlich richtig sind (und da sind MW und FF eher zu scharf und zu konservativ und antworten einmal zuviel mit einer frischen Vollversion), ist es erstmal okay.

Die Leute, die derartige Software geschrieben haben, sind keine Volldeppen. Und für die erfahrenen Serverleute ist es eine Herausforderung, die Cache-Quote möglichst über 99 % zu bekommen.

Dass sich dann in manchen Monaten noch einige vermeidbare dazwischenschmuggeln, würde ich kommentarlos hinnehmen; das verschwindet auf unerklärliche Art wieder, und dafür passiert woanders was Seltsames.

Du kannst an deine popups-URL mal dranhängen: &bcache=1&maxage=604800

LG --PerfektesChaos 14:31, 5. Mai 2015 (CEST)

Ich habe bei meinem Firefox auch festgestellt, dass sehr viele Anfragen mit 200 beantwortet werden statt mit 304. Nach dem Hinweis auf den Firefox-Cache habe ich bei mir den Haken „Automatisches Cache-Management ausschalten“ aktiviert und die Cache-Größe von 350 MB auf die Maximalgröße 1024 MB erhöht. Jetzt kommen wieder Antworten mit 304. Die WMF-Server haben anscheinend die Eigenschaft den Firefox-Cache so zu füllen, dass sinnvoll cachebare Anfragen nicht mehr gecacht werden. --Fomafix (Diskussion) 15:41, 5. Mai 2015 (CEST)

• Ich weiß nicht; meine preferences.js habe ich noch von Netscape.2 geerbt und die immer wieder auf neue Maschinen kopiert (inzwischen aber lokal raufgesetzt).
• Wenn FF das noch im Cache hatte, dann kennt er auch noch If-Modified-Since und kann es dem Server anbieten; wenn die Seite bei FF aus dem Cache geflogen war, ist das logischerweise unbekannt und muss komplett neu geholt werden.
• Lästig ist das must-revalidate usw. von MediaWiki; das ändert die Interpretation von Expires statt
  • Mindesthaltbarkeitsdatum (wie einer Tüte trockener Spaghetti) zu
  • Verfallsdatum (wie Hackepeter) – zur absoluten Unbrauchbarkeit.
• Es gibt auch Seiten, die hängen einfach falsch auf dem Server in der Cache-Datenbank fest; da müsste ein handelsübliches Purge helfen. Manchmal muss so ein Sklavenserver auch rebootet werden, oder seine Cache-Datenbank mal komplett geleert; durch die Maschinchen gehen Terabyte an Daten, und da kommt es schon mal zum memory leak oder zu einem geistigen Kratzer auf der Festplatte.

VG --PerfektesChaos 11:26, 7. Mai 2015 (CEST)

Also ich weiß nicht, ob ich mich da richtig ausgedrückt habe. Das ist kein Nebenproblem und das sind auch nicht irgendwelche Dateien. Das sind ein paar ziemlich große Dateien, die bei praktisch jedem Seitenaufruf (Ausnahme z.B. Spezialseiten) eingebunden werden. Wenn das Problem auch nur einen Bruchteil der Benutzer betrifft, dann hat das erheblichen Einfluss auf die serverseitige Bandbreite. Und bei Benutzern mit eingeschränkter Bandbreite (e.g. mobil mit 500MB/Tag) schränkt das die Verwendbarkeit von WP ein. Die Betreffenden werden auf einmal gedrosselt, ohne dass sie wissen, wie ihnen geschieht. Wenn die dann feststellen, dass WP der Bandbreitenfresser ist, werden sie einigermaßen sauer sein. Und mit Recht. IMHO sollte das nicht liegengelassen werden. Könnte jemand einen entsprechenden Bug-Eintrag machen? -- Wolfgang Rieger (Diskussion) 08:17, 8. Mai 2015 (CEST)

Nachträge: Ich habe mein Problem anscheinend gelöst, indem ich Firefox blank poliert habe. Die Header lauten jetzt im entsprechenden Fall (GET /w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript):

REQUEST:
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Cache-Control: max-age=0
Connection: keep-alive
Cookie: ...
DNT: 1
Host: en.wikipedia.org
If-Modified-Since: Wed, 10 Dec 2014 23:42:14 GMT
Referer: ...
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:37.0) Gecko/20100101 Firefox/37.0

RESPONSE:
Accept-Ranges: bytes
Age: 0
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Date: Fri, 08 May 2015 18:13:15 GMT
Server: nginx/1.6.2
Vary: Accept-Encoding
Via: 1.1 varnish, 1.1 varnish, 1.1 varnish
X-Analytics: https=1;WMF-Last-Access=08-May-2015
X-Cache: cp1055 miss (0), cp3007 miss (0), cp3005 frontend miss (0)
X-Firefox-Spdy: 3.1
X-Varnish: 3708524825, 2946262987, 3451454459 

Mit Chrome funktioniert es auch korrekt. Auch hier wird Response-Status 304 geliefert. Hier lauten die Header:

:host:en.wikipedia.org
:method:GET
:path:/w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript
:scheme:https
:version:HTTP/1.1

REQUEST:
accept:*/*
accept-encoding:gzip, deflate, sdch
accept-language:en-US,en;q=0.8,de-DE;q=0.6,de;q=0.4
cache-control:max-age=0
cookie: ...
dnt:1
if-modified-since:Wed, 10 Dec 2014 23:42:14 GMT
referer: ...
user-agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36

RESPONSE:
accept-ranges:bytes
age:0
cache-control:private, s-maxage=0, max-age=0, must-revalidate
content-encoding:gzip
content-type:text/javascript; charset=UTF-8
date:Fri, 08 May 2015 13:44:56 GMT
last-modified:Wed, 10 Dec 2014 23:42:14 GMT
server:nginx/1.6.2
status:304 Not Modified
vary:Accept-Encoding
version:HTTP/1.1
via:1.1 varnish, 1.1 varnish, 1.1 varnish
x-analytics:https=1;WMF-Last-Access=08-May-2015
x-cache:cp1055 miss (0), cp3007 miss (0), cp3041 frontend miss (0)
x-content-type-options:nosniff
x-powered-by:HHVM/3.3.1
x-varnish:3676403530, 2929413494, 1483623845

Der einzige nennenswerte Unterschied, den ich sehe, ist, dass zuvor Cache-Control: max-age=0 im Request-Header gefehlt hat. Anscheinend verstehe ich HTTP nicht, denn IMHO müsste der Server so oder so 304 senden, wenn if-modified-since passt. Kopfkratz … grübel … Vielleicht doch ein Bug? -- Wolfgang Rieger (Diskussion) 20:32, 8. Mai 2015 (CEST)

Wie oben beschrieben hatte ich am 5. Mai meinen Cache im Firefox von 350 MB auf 1024 MB vergrößert und danach wurden wieder Anfragen gecached und es kamen Antworten mit 304. Inzwischen ist auch dieser Cache vollgelaufen und alle Ressourcen werden wieder immer neu geladen mit 200. Ein Verringern und erneutes anschließendes Vergrößern des Caches hat wieder Platz im Cache geschaffen, so dass jetzt wieder Antworten mit 304 kommen. Die Frage ist nun, wird dieses seltsame Cache-Verhalten vom Firefox durch die Konfiguration der WMF-Server provoziert? --Fomafix (Diskussion) 10:12, 18. Mai 2015 (CEST)

Primär ein unglückliches Verhalten von Firefox.

• Mit Erreichen von rund 95 % der Plattenquota oder aber wenn nur 5 MB oder was über sind, sollte die garbage collection gestartet werden.
• Das klappte eigentlich zwei Jahrzehnte hindurch.
• Mozilla muss dann nach bestimmten Strategien (ältere und sehr große und selten angefasste und lange nicht benötigte zuerst) Einträge aus dem Cache entfernen, bis vielleicht nur noch 75 % oder so belegt sind.
• Deiner Schilderung nach ist das nicht passiert.
• MediaWiki hat damit erstmal nix am tun.
• Es wird auch nicht gleichzeitig 1 GB für die Darstellung einer Wiki-Seite benötigt.
• Muttu dich mal durch die Foren und den echten Bugzilla googlen.

MediaWiki ist aber auch ein fauler Trafficfresser.

• Es wird alles und jedes auf ein Höchstalter von Null Sekunden gesetzt.
• Das ist ja lieb, wenn es um Artikel-Inhalte und dergleichen geht.
• Aber ein 2004 nach Commons hochgeladenes Bildchen muss nicht alle 30 Sekunden bei jeder Preview erneut gefragt werden, ob’s zufällig grad eben eine neue Version hochgeladen hat.

LG --PerfektesChaos 10:41, 18. Mai 2015 (CEST)

Meine Frage ist immer noch: Ist es korrekt, dass der Server auf das fehlende Cache-Control: max-age=0 im Request-Header statt mit 304 mit 200 reagiert? Der Server kann natürlich 200 senden, wann immer er will. Nicht aber, wenn er weiß, was für ihn gut ist. Oder ist das eine vergurkte, serverseitige "Mozilla-Optimierung" ala wir drängeln uns jetzt mal wieder auf eine bessere Cache-Position? -- Wolfgang Rieger (Diskussion) 10:59, 18. Mai 2015 (CEST)

Das kostet die auch nur Netzwerk-Traffic, und MW hat nichts davon, und man ist bemüht, den Nicht-304-Traffic mit Inhalten zu minimieren.

Die Cache-Position ergibt sich auch mit 304 weiter oben, weil die Zahl der Anfragen auf diese URL im Browser-Cache um eins erhöht wird, der Zeitpunkt des letzten Bedarfs grad eben ist, und damit für die nächsten 24 Stunden oder was möglichst im Cache bleiben sollte. Ob 200 oder 304 ist dabei egal.

Die Serverfarm bemüht sich, bei Fragen auf eine statische URL /wiki/ usw. zu wissen, wann diese Seite zuletzt modifiziert wurde; wenn sie das weiß und damit die Aktualität bestätigt werden kann, kommt 304. Wenn der Sklave die Ressource nicht kennt und deshalb nicht einschätzen kann, ob sie noch aktuell ist, muss er sich beim Master eine frische holen und der sendet dann wohl auch gleich den Inhalt (was nicht ganz so optimal ist). Aber das ist eine komplexe Geschichte, die sich in Tausendstelsekunden in einem Hochgeschwindigkeitsbus abspielt, und die nicht trivial zu durchschauen ist. Die Hit- und Miss-Quoten werden aber beobachtet.

LG --PerfektesChaos 11:17, 18. Mai 2015 (CEST)

Ich habe in einer virtuellen Maschine mit einem Firefox ohne Addons und mit verringertem Cache etwas experimentiert. Sobald der Cache voll ist, werden bei dewiki über HTTPS Ressourcen aus index.php und load.php nicht mehr gecacht, sondern immer per 200 neu geholt. Bilder werden weiterhin gecacht und die Aktualität wird per 304 bestätigt. Bei einer lokalen MediaWiki-Installation per HTTP werden trotz vollem Firefox-Cache auch Ressourcen gecacht. Die Webserver-Einstellungen der WMF-Server scheinen also das Caching beim Firefox bei vollem Cache negativ zu beeinflussen. --Fomafix (Diskussion) 14:11, 18. Mai 2015 (CEST)

Dafür würde ich gleichwohl in erster Linie den FF verantwortlich machen.

• Die Situation „voller Cache“ darf überhaupt nicht auftreten.
  • Wenn der Cache eine Daumenbreit vor der quota angekommen ist, ist nach irgendeiner Heuristik für alle Dateien ein score zu bilden.
    • Was vor einer Stunde, einem Tag, einer Woche zuletzt angefasst wurde, bekommt entsprechend mehr Punkte.
    • Was häufiger verwendet wurde, bekommt mehr Punkte.
    • Was das MHD noch vor sich hat, bekommt mehr Punkte.
    • Was schon lange stabil war, bekommt Pluspunkte.
    • Kleine Dateien bekommen Extra-Punkte. Ein 2 MB großes Foto, das ich mir vor drei Wochen einmal angeschaut hatte, macht mehr realen Speicherplatz frei als 1000 kleine Icons und winzige Pixelgrafiken.
  • Der score ist dynamisch und kann nicht bei den Einträgen gespeichert werdne, weil die Information „innerhalb der letzten Stunde zuletzt benutzt“ vergänglich ist.
  • Danach werden von den Einträgen mit wenig Punken so lange welche gelöscht, bis wieder einige Dutzend MB frei geworden sind.
• Die Website hat überhaupt keine Möglichkeit, das zu beeinflussen. Sie liefert URL, Last-Modified und Expires.
  • Wie das in die Speicherbereinigung eingeht, ist allein Sache des Browsers.
  • Ein Browser muss eine Prognose machen, welche Dateien zukünftig wieder benötigt werden. Die, an denen ich grad sitze, die ich häufig anfasse, die könnte ich wieder brauchen; was ich nur selten und zuletzt vor langer Zeit benutzt habe, muss gelöscht werden.
• Damit ich den Cache wieder nutzen kann und Platz für Neues habe, muss Altes raus.

LG --PerfektesChaos 14:48, 18. Mai 2015 (CEST)

Sicherlich, die Entscheidung was aus dem Cache geworfen wird bzw. was in den Cache aufgenommen wird, ist Sache des Browsers. Ein voller Cache ist der Normalzustand, sofern der Browser eine Weile in Betrieb ist. Firefox hat anscheinend die Strategie, dass Ressourcen mit dem Header Cache-Control:"private, s-maxage=0, max-age=0, must-revalidate" grundsätzlich einen niedrigeren Score bekommen. Bei vollem Cache werden daher solche Ressourcen nicht mehr gecacht, weil im Cache noch Ressourcen mit anderem Cache-Control sind. Dieser Score kann daher vom Webserver beeinflusst werden. Die Konfiguration der WMF-Server ist daher schlecht. --Fomafix (Diskussion) 15:03, 18. Mai 2015 (CEST)

Der Server sieht nur den Request und sonst weiß er von nichts. Der einzige Unterschied im Request, der reproduzierbar zu 200- bzw. 304-Status geführt hat, war eben Cache-Control: max-age=0 im Request-Header. Laut dem entsprechenden Abschnitt in RFC 2616 (HTTP/1.1) sollte dieser Teil des Requests dazu führen, dass alles validiert wird, mehr nicht. Da aber keine neue Version da ist, kann die Validierung nichts Neues liefern, außer auf Serverseite wird das if-modified-since irgendwo in der Kette schlicht weggeschmissen (was IMHO ein Fehler wäre). Dass wie PC meint, ein Slave keine Kopie eben dieser Dateien hat, die bei jedem Seitenaufruf abgefragt werden und sich kaum je ändern, kann ich mir nicht vorstellen. Ich sehe wirklich nur die zwei Möglichkeiten: 1) ich verstehe HTTP nicht bzw. übersehe etwas Offensichtliches 2) das Verhalten der WP-Server ist fehlerhaft bzw. unökonomisch. -- Wolfgang Rieger (Diskussion) 15:35, 18. Mai 2015 (CEST)

@Wolfgang Rieger Mein beobachtetes Verhalten stimmt nicht mehr Deinem beschriebenen Verhalten überein. Anfragen mit If-Modified-Since werden bei mir auch immer mit 304 beantwortet – so weit ich sehe. Mir fällt nur auf, dass im Firefox bei vollem Cache Antworten mit Cache-Control: private, s-maxage=0, max-age=0, must-revalidate nicht in den Cache aufgenommen werden und daher die Folgeanfragen immer ohne If-Modified-Since angefragt werden und daher auch immer mit 200 beantwortet werden. --Fomafix (Diskussion) 16:45, 18. Mai 2015 (CEST)

Das scheint mir dann ein anderes, teilweise clientseitiges Problem zu sein. Der Punkt war ja gerade, dass If-Modified-Since da war und die Dateien auch im Browser-Cache vorhanden waren (das lässt sich ja überprüfen). Ich stimme PC hier zu, dass die von den WP-Servern gelieferten Response-Parameter übertrieben konservativ sind. -- Wolfgang Rieger (Diskussion) 17:13, 18. Mai 2015 (CEST)

@Wolfgang Rieger: Ich kann übrigens Dein Problem nicht reproduzieren:

$ socat - openssl:en.wikipedia.org:443,cafile=/etc/ssl/certs/ca-bundle.crt
GET /w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript HTTP/1.1
Host: en.wikipedia.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:37.0) Gecko/20100101 Firefox/37.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: https://de.wikipedia.org/wiki/Langobarden
Cookie: ...
Connection: keep-alive
If-Modified-Since: Wed, 10 Dec 2014 23:42:14 GMT


HTTP/1.1 304 Not Modified
Server: nginx/1.6.2
Date: Mon, 18 May 2015 15:31:11 GMT
Content-Type: text/javascript; charset=UTF-8
Connection: keep-alive
X-Powered-By: HHVM/3.6.1
X-Content-Type-Options: nosniff
Content-Encoding: gzip
Vary: Accept-Encoding
Last-Modified: Wed, 10 Dec 2014 23:42:14 GMT
X-Varnish: 961437819, 3786211680, 3037773168 3037713462
Via: 1.1 varnish, 1.1 varnish, 1.1 varnish
Accept-Ranges: bytes
Age: 29
X-Cache: cp1055 miss (0), cp3007 miss (0), cp3003 frontend hit (1)
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Set-Cookie: GeoIP=DE::51.0000:9.0000:v4; Path=/; Domain=.wikipedia.org
X-Analytics: https=1
Set-Cookie: WMF-Last-Access=18-May-2015;Path=/;HttpOnly;Expires=Fri, 19 Jun 2015 12:00:00 GMT

--Fomafix (Diskussion) 17:35, 18. Mai 2015 (CEST)

Mit gerrit:207661 wurde das Caching im ResourceLoader umgestellt. Mal schauen, wie es sich damit verhält. --Fomafix (Diskussion) 12:37, 21. Mai 2015 (CEST)

Hilfe mit TemplateData

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)

Zeilensprung nach Unterschrift

führt bei mir zum Rauswurf aus dem Wikikonto und zum Löschen des Geschriebenen. (S. auch Thread Fehlfunktion des Linksymbols oberhalb) Es ist gleichgültig, ob ich das mit der Vorlage oberhalb des Browserfensters mache oder mit den Hilfen unterhalb. --Orik (Diskussion) 09:26, 10. Mai 2015 (CEST)

API: Suche nach Einbindungen von Vorlage

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 [11]. --91.42.142.58 15:04, 15. Mai 2015 (CEST)

Vielen Dank. --Jobu0101 (Diskussion) 15:25, 15. Mai 2015 (CEST)

Community tech project ideas

Hello Wikipedia Germany, apologies for posting in English.

This is a note to the page on meta for community tech project ideas., please feel free to engage in the discussion or add a suggestion to project, etc. Thanks --Melamrawy (WMF) (talk) 11:59, 19 May 2015 (UTC)

patrol-Log unvollständig ausgeblendet

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. [12]. 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 – (📞| 📝| ) – 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 – (📞| 📝| ) – HDR 19:41, 25. Mai 2015 (CEST)

Suchfeld mobil nur noch grauer Balken in Android 2.3.6

Gemeldet in Phabricator
Task T98498 Resolved

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

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)

Fast fertiges Verschiebeskript für den Luke081515-Bot

Hallo, ich habe ein Skript für den Luke081515Bot programmiert (bzw. es versucht), das bei Klick auf einen Eintrag unter Verschieben zwei DIalogfenster öfnet, und dann per API den Edit speichert. Nun zu meinem Problem: Der Edit wird nicht gespeichert, obwohl sogar "Diese Bearbeitung wurde gespeichert" erscheint. Ich wäre sehr dankbar, wenn mir jemand sagen könnte, wo in meinem Skript der Fehler liegt, mutmaßlich in line 32-47.

Außerdem würde mich im Zuge der Weiternetwicklung des Skriptes imteressierten, ob es möglich ist, seitenspezifische Variablen wie wgCurRevisionId für andere Seiten auszugeben, als auf denen das JS läuft. (In diesem Beispiel konkret für die Variable "Ziellemma") --MGChecker – (📞| 📝| ) – HDR 20:36, 2. Jun. 2015 (CEST)

In der Konsole erhalte ich einen BadToken-Fehler. --MGChecker – (📞| 📝| ) – HDR 22:16, 2. Jun. 2015 (CEST)

@Umherirrender: Kanst du mir helfen? Du hast mich immerhin zu API gebracht. --MGChecker – (📞| 📝| ) – HDR 23:22, 2. Jun. 2015 (CEST)

Okay, das Hauptproblem habe ich jetzt gelöst, aber die Frage nach seitenspezifischen Variablen auf anderen Seiten konnte ich noch nicht für mich beantworten. --MGChecker – (📞| 📝| ) – HDR 18:29, 3. Jun. 2015 (CEST)

Wenn du die ID einer anderen Seite haben möchtest, müsstes du ein weiteren API-Request machen, beispielsweise action=query mit prop=info (api.php?action=query&prop=info&titles=Page%20A|Page%20). Die aktuelle Seite kennt nur seine seitenbezogenen Dinge. Der Umherirrende 20:00, 3. Jun. 2015 (CEST)

Falscher Abschnitt in Zusammenfassungszeile bei mobilen Bearbeitungen

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

Gemeldet in Phabricator
Task T101390

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 Taxon • Diskussion • Wiki-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 Taxon • Diskussion • Wiki-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 Taxon • Diskussion • Wiki-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 Taxon • Diskussion • Wiki-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)

Verwendung von Unicodesymbolen in einer Tabelle

Guten Tag,

ich bin dabei eine deutsche Version von PKP Intercity zu erstellen. Dabei habe ich allerdings ein kleines Problem. Bei der der polnischen Version (https://pl.wikipedia.org/wiki/PKP_Intercity#Elektryczne_zespo.C5.82y_trakcyjne) sind in der Tabelle zwei Unicodesymbole zu sehen(Rollstuhl, und eine Tasse). Der Rollstuhl entspricht der Unicodenummer U+268F und die Tasse U+2615. Wie kann ich diese Symbole bei folgender Tabelle (https://de.wikipedia.org/wiki/Benutzer:Kiepski1/PKP_Intercity#Elektrotriebwagen) in der sechsten und siebten Spalte integrieren. Vielen Dank im Voraus  --Kiepski1 (Diskussion) 14:02, 12. Jun. 2015 (CEST)

Generell sind in diesem Wiki derartige Zeichensymbole unerwünscht, da sie bei vielen Lesern nicht erkennbar sind.

Vielmehr würden wir lieber kleine Icon-Dateien Plik: sehen.

Frage doch mal auf PD:Bahn nach,wie das hier gehandhabt wird; vielleicht gibt es dafür eine kleine Szablon – bei den Autobahnen wird das so gemacht.

Wenn du hier Übersetzungen aus einem anderen Wiki anlegst, möchten wir übrigens gern deren Versionsgeschichte importieren; siehe WP:IMP.

Grüße --PerfektesChaos 14:59, 12. Jun. 2015 (CEST)

Hallo PerfektesChaos, danke für deine Antwort. Ich habe mal bei PD:Bahn nachgefragt. Die Versionsgeschichte werde ich bei Fertigstellung des Artikels importieren lassen. --Kiepski1 (Diskussion) 15:15, 12. Jun. 2015 (CEST)

Beides wird dort als Bild eingebunden: pl:Plik:Handicap_reverse_12px.svg, pl:Plik:Cup of coffee.svg. Den Rollstuhl sehe ich nicht, die Kaffeetasse als Unicode wäre ☕ aber siehe oben, Bilder sind besser. --mfb (Diskussion) 15:36, 12. Jun. 2015 (CEST)

Herzlichen Dank für die schnelle Problemlösung   --Kiepski1 (Diskussion) 15:52, 12. Jun. 2015 (CEST)

Das Rollstuhl-Symbol ist U+267F: ♿ --nenntmichruhigip (Diskussion) 09:39, 13. Jun. 2015 (CEST)

Benutzer:Schnark/js/personendaten.js/normdaten.js

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

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 ( und schmal ) 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)

Language-Links fehlen auf der Seite "Lautsprecher" wenn ich nicht eingeloggt bin

Auf der Seite "Lautsprecher" sehe ich in der linken Spalte unter "In anderen Sprachen" keine Links zu den entsprechenden Artikeln in anderen Sprachen, wenn ich nicht bei Wikipedia eingeloggt bin. Wenn ich eingeloggt bin, werden alle Links ordentlich angezeigt. Auf der Seite "Kopfhörer" werden die Language-Links immer korrekt angezeit. Ist das ein bekannter Bug? AxelBoldt (Diskussion) 15:52, 26. Jul. 2015 (CEST)

action=purge hat es behoben. Ich glaube der Fehler ist bereits bekannt. -- FriedhelmW (Diskussion) 16:06, 26. Jul. 2015 (CEST)

Task 47839. -- FriedhelmW (Diskussion) 16:47, 26. Jul. 2015 (CEST)

beta navigationsleiste

Hallo, Ich habe mir die beta Version auf meinem Samsung galaxy tab 4 angesehen (Android Version 4.4.2) angesehen. mir ist schnell ein Fehler aufgefallen, wenn man auf das Lupen-Symbol drückt soll wohl eine Navigationsleiste erscheinen. Ich sehe dort keinerlei Text, kann aber die Links anklicken und werde auch weitergeleitet. Nur leider weiß ich nicht wohin, da ich den Text nicht sehen kann.

Mit freundlichen Grüßen (nicht signierter Beitrag von 79.196.214.14 (Diskussion) 11:18, 8. Aug. 2015 (CEST))

Vielen Dank für deinen Hinweis.

Wir werden versuchen, deine Beobachtung an die Entwickler weiterzuleiten.

Nur bin ich im Moment ratlos, um welches der auf WP:Technik/Skin/Beta genannten Features es sich bei einer „beta navigationsleiste“ handeln würde.

Ich selbst bin nicht mobil unterwegs, eigentlich im Wiki-Urlaub und werde in wenigen Minuten verglüht sein.

LG --PerfektesChaos 13:13, 8. Aug. 2015 (CEST)

Hovercards in eowp spinnt

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

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)

c:MediaWiki talk:Edittools#Whitespaces in headlines with multilingual tags

Kann da jemand helfen? Es geht um Leerzeichen bei c:MediaWiki:Edittools (siehe Versionsgeschichte). --Leyo 00:22, 18. Aug. 2015 (CEST)

@Leyo Wozu, bzw. wer sagt das? Solange Wikimedia es anders propagiert wäre dies nur ein inkonsistenter Hack gegen Wikimedia. Ist dies nur deine Meinung oder wo ist die tatsächlich vorausgegangene Diskussion (vernehmlich auf Commons) zu deinem Wiki-Syntax-Bild? Wenn Diskussion/Umfrage vorhanden empfehle ich daher für Dein Anliegen allg. einen Phab-Task. ↔ User: Perhelion  23:47, 20. Aug. 2015 (CEST)

Ich verstehe deinen Einwand nicht. Es geht um (1) stimmt es, dass es mit (normalen) Leerzeichen tatsächlich nicht funktioniert und (2) könnte dies allenfalls umgangen werden? --Leyo 00:12, 21. Aug. 2015 (CEST)

Kategorien auslesen und für Commons übersetzen

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

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 ☕⌨☺   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 ☕⌨☺   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 ☕⌨☺   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)

Bearbeitungswerkzeugleiste?

Hallo! Seit einem Upgrade auf Windows 10 ist die Bearbeitungswerkzeugleiste verschwunden. Kann mir bitte jemand weiterhelfen?--Rainer P. (Diskussion) 22:12, 9. Sep. 2015 (CEST)

Bug mit passiven Sichterrechten?

Oder: Wieso hat Benutzer:Wählscheibentelefon noch keine passiven Sichterrechte? Diskussion bei den Adminanfragen. Die Kriterien sollten alle erfüllt sein. --mfb (Diskussion) 22:46, 12. Sep. 2015 (CEST)

VisualEditor und Wikitext

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

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:
   • Benutzer:Jobu0101/common.js
     • Da steht was von addOnloadHook.
     • Dazu siehe Obsolet.
     • Ersatz benenne ich dir unten.
   • Benutzer:Jobu0101/vector.js
     • Okaaay.
     • Mit welcher Skin arbeitest du eigentlich?
   • Benutzer:Jobu0101/monobook.js
     • Wirkungslos und obsolet: document.write sowie dontcountme=s
     • In Benutzer:Jobu0101/common.js machst du aber bereits das Gleiche in moderner; also kannst du es hier löschen.
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.

3. Ich arbeite schon seit langem mit Vector.
4. Diese Leiste hier: .
5. 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?

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

Gemeldet in Phabricator
Task T104524

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

Gemeldet in Phabricator
Task T56919

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

Gemeldet in Phabricator
Task T117309

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

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

Gemeldet in Phabricator
Task T117306

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

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)

Superprotect ist vorbei

Superprotect wurde von der Wikimedia Foundation (WMF) eingeführt um eine Meinungsverschiedenheit in der Produktentwicklung beizulegen. Die WMF hat seitdem kein weiteres Mal auf Superprotect zum Beilegen weiterer Auseinandersetzungen zurückgegriffen. Daher entfernen wir heute Superprotect von den Wikimedia-Servern.

Die Beseitigung von Superprotect entfernt einen symbolischen Konfliktherd. Allerdings besteht weiterhin das grundlegende Problem von Konflikten und daraus resultierenden Verzögerungen in der Phase der Zurverfügungstellung der Software auf den Wikimedia-Servern ("Deployment"). Wir müssen besser in der Softwareentwicklung zusammenzuarbeiten, um bessere Produkte und bessere Features schneller zur Verfügung stellen zu können. Die Zusammenarbeit von WMF und den Communities beruht auf gegenseitigem Vertrauen und konstruktiver Kritik. Daher müssen wir Wikimedia-Abläufe verbessern um Konsens zu schaffen, mehr Stimmen einzubeziehen und Meinungsverschiedenheiten beizulegen.

Es gibt einen ersten Entwurf eines aktualisierten Software-Produktentwicklungsprozesses, der die Richtlinie für die Arbeit der WMF Engineering and Product-Teams sein wird. Er betont dass das Feedback der Community, insbesondere in frühen Entwicklungsphasen, wichtig ist. Mehr und früheres Feedback erlauben es, von der Community angeregte Verbesserungen einfließen zu lassen und mögliche kontroverse Aspekte anzusprechen, solange die Pläne und die Software am flexibelsten angepasst werden können.

Wir begrüßen das Feedback von technischen und nicht-technischen Beitragenden. Mehr Details dazu können in den zugehörigen Fragen und Antworten (Q&A) gefunden werden.

Quim Gil, Engineering Community Manager @ Wikimedia Foundation -- 18:31, 5. Nov. 2015 (CET)

Sieh an, sieh an …--XanonymusX (Diskussion) 18:34, 5. Nov. 2015 (CET)

Das war überraschend. --MGChecker – (📞| 📝| ) 18:39, 5. Nov. 2015 (CET)

Das ist eine gute Nachricht. --Holder (Diskussion) 19:20, 5. Nov. 2015 (CET)

Ich bin gespannt, was sich sonst noch so tut. Oder ob die Kanone beim nächsten Disput wieder ausgerollt wird, anstatt sich dem eigenen Versagen zu stellen. —‏הגות‎⁴¹⁴ 19:29, 5. Nov. 2015 (CET)

Gespannt sein kann man. Ich fände es aber gut, wenn nach dieser Aktion auch die Wortwahl gegenüber WMF etwas freundlicher wird, um ein "Neuanfang" zu ermöglichen. Der Umherirrende 22:23, 5. Nov. 2015 (CET)

Sehr schön, damit habe ich nicht mehr gerechnet, ehrlich gesagt. Aber ich habe gleich mal die Signatur angepasst. :-) Ein gutes Zeichen jedenfalls, hoffentlich geht es auch so weiter, und zwar in beide Richtungen, nicht nur Feedback von hier für neue Entwicklungen der WMF, sondern auch mehr Vorschläge von hier und Bugmeldungen, die schneller umgesetzt werden. Das wäre wesentlich. --Winternacht in Wikimedias nicht mehr supergeschützten Wikis 21:44, 5. Nov. 2015 (CET)

Und wann wird das Meinungsbild umgesetzt und der neue Medienbetrachter nun abgeschaltet? Ich rege mich jedes Mal darüber auf, wenn ich unangemeldet unterwegs bin. Gerade auf mobilen Geräten ist der Betrachter klobig und verlangsamt das Browsing. --(Saint)-Louis (Diskussion) 22:15, 5. Nov. 2015 (CET)

Der Medienbetrachter hat sich weiterentwickelt. Auch unangemeldeten Benutzern ist es möglich ihn über ein Klick abzuschalten (wird als Cookie gespeichert).

Jetzt wieder damit anzufangen, dass auf den damaligen Weg auszuschalten, ist sehr kontraproduktiv, weil dann der Vertrauensvorschuss seitens WMF sicher nicht wieder aufholbar ist und es dann für immer bleibt. Der Umherirrende 22:23, 5. Nov. 2015 (CET)

Dass das Ding nun auch unangemeldet abschaltbar ist, ist auch erfreulich. Haben sie denn die URV-Probleme mit den mangelnden Autoren-Kennzeichnungen der Bilder eigentlich vollständig gelöst bekommen? Das war auch einer der Hauptgründe für die Kontrastimmen im MB. --Winternacht in Wikimedias nicht mehr supergeschützten Wikis 22:54, 5. Nov. 2015 (CET)

@Winternacht: Vollständig gelöst gibt es ja nie, aber es gab den meta:File metadata cleanup drive und laut https://tools.wmflabs.org/mrmetadata/ :

Global tally: 96% complete / Total number of files: 30,262,054 / Files with missing machine-readable metadata: 1,287,143

Commons: 99% complete / 395,997 files to go

dewp: 100% complete / Total number of files: 149,393 --Atlasowa (Diskussion) 00:44, 6. Nov. 2015 (CET)

@(Saint)-Louis: Meinst du mit "klobig" "auf mobilen Geräten" den Medienbetrachter von desktop-WP (https://de.wikipedia.org/wiki/Kanone#/media/File:Gribeauval_cannon_de_12_An_2_de_la_Republique.jpg) oder die Bilderanzeige von mobil-WP (https://de.m.wikipedia.org/wiki/Kanone#/media/Datei%3AGribeauval_cannon_de_12_An_2_de_la_Republique.jpg). Ist nicht das gleiche, auch wenn es ähnlich aussieht. --Atlasowa (Diskussion) 00:44, 6. Nov. 2015 (CET)

So ganz mag ich es nicht glauben, aber wenn es so bleibt ist das ein Fortschritt. -- Andreas Werle (Diskussion) 21:24, 6. Nov. 2015 (CET)

... someone said in Berlin.

Schön gesagt :D (and sorry, I can read German but not write it at the level required here). Glauben / trusting is important in our partnership, but you don't need to trust blindly. The WMF product development process draft is the important part of my post, because it is in the context of that process where our mutual trust as software partners will be exercised. I have added a Q&A about this. I invite you to contribute to the design of this process today. A big, diverse, well organized, and tech-savvy community like this one could get involved earlier in the development of new products, influence plans and their execution, and identify actionable blockers at the right times. This way of exercising community power can be really efficient and effective (and interesting and fun for a higher diversity of contributors, let me add).--Qgil-WMF (Diskussion) 01:10, 9. Nov. 2015 (CET)

Schriftgröße von Einzelnachweise

Kann mir da jemand sagen, wie ich in einem anderen Wiki die Schriftgröße der Einzelnachweise kleiner machen kann (nicht als User, sondern als Betreiber ;-) --danke K@rl 11:17, 8. Nov. 2015 (CET)

Auf den ersten Blick wäre das auf MediaWiki:Common.css einzufügen; müsste schon reichen:

.references { 
   font-size: 90%;
}

Allerdings ist es so, das Ältere und Smartphone-Benutzer mit dieser aus gedruckten Büchern bekannten Tradition Probleme haben; da ein Wiki kein Papier sparen muss, wird das eher nicht empfohlen.

LG --PerfektesChaos 11:29, 8. Nov. 2015 (CET)

Super danke - werd ich mir anschauen. --K@rl 11:55, 8. Nov. 2015 (CET)

Plattform-Uhrzeit um eine Stunde falsch

Hey (hoffe, dass ich hier mit meinem Anliegen richtig bin), am Fuß eines von mir bearbeiteten Artikels ist mir aufgefallen, dass (zumindest) in der Zeile "Diese Seite wurde zuletzt... geändert" die Uhrzeit falsch ist - sie liegt eine Stunde hinter der MEZ. Bezieht sich dieser Uhrzeitfehler auf das ganze System oder nur auf diese Fußzeile? Beides wäre natürlich nicht optimal ;) Grüßle, --Gambuso (Diskussion) 02:07, 10. Nov. 2015 (CET)

Ich kann keine falsche Uhrzeit feststellen. Dein zuletzt bearbeiteter Artikel Computerlinguistik wird bei mir sowohl in Deinen Benutzerbeiträgen, als auch in der Fußzeile des Artikels mit 01:40 Uhr angegeben. Was steht bei Dir? Was hast Du in Deinen Einstellungen für eine Zeitzone eingestellt? --Fomafix (Diskussion) 06:57, 10. Nov. 2015 (CET)

Danke, nach Behebung meiner Zeitzoneneinstellungen stimmt's. Unangemeldet scheint die Zeitangabe auch zu stimmen. Danke! :) --Gambuso (Diskussion) 15:17, 10. Nov. 2015 (CET)

Gruppierung auch in Bearbeitungsliste

Übertrag von Fragen zur Wikipedia auf Anraten von Lómelinde:

Ich meine vor einer Weile ein Skript o.ä. gesehen zu haben, das eine Gruppierung der Einträge analog zur Beobachtungsliste auch auf Spezial:Beiträge einbaut. Täuscht sich da mein Gedächtnis, oder weiß jemand wo das liegt? --Windharp (Diskussion) 09:43, 10. Nov. 2015 (CET)

Es könnte um Benutzer:PerfektesChaos/js/resultListSort gehen – der sortiert unter anderem die Spezial:Beiträge nach Namensraum und Seitentitel. LG --PerfektesChaos 10:52, 10. Nov. 2015 (CET)

Das ist doch schon mal ganz nett, ich glaube das hilft mir weiter. Danke schön. -- Windharp (Diskussion) 14:20, 10. Nov. 2015 (CET)

Dieser Abschnitt kann archiviert werden. --Windharp (Diskussion) 10:40, 17. Nov. 2015 (CET)

Fehler im Artikel Turkish Airlines?

Im Artikel Turkish Airlines, im Abschnitt Flotte kommt zwischen dem Satz und der Tabelle ein Bindestrich, aber keine Ahnung woher. Kann sich das bitte mal jemand anschauen..? Danke --MBurch (Diskussion) 18:51, 12. Nov. 2015 (CET)

erledigtErledigt, auch wenn ich (noch) nicht weiss, warum MW das daraus gemacht hat. --nenntmichruhigip (Diskussion) 19:08, 12. Nov. 2015 (CET)

Danke, so weit unten habe ich nich nach dem ollen Bindestrich gesucht Vorlage:Smiley/Wartung/pfeif  (doofe Frage, für was steht MW?).--MBurch (Diskussion) 19:24, 12. Nov. 2015 (CET)

Hab' ich auch nicht, war Zufall, dass es so schnell ging :-) Für MediaWiki, der Software dieses Wikis. --nenntmichruhigip (Diskussion) 19:28, 12. Nov. 2015 (CET)

Inhalte innerhalb des Tabellencodes, die nicht zur Tabellensyntax passen, werden gerne über der Tabelle ausgegeben. Siehe Quelltext hier. --mfb (Diskussion) 19:38, 12. Nov. 2015 (CET)

text

bla	bla
bla	bla

Wieder was gelernt. Danke Euch allen   --MBurch (Diskussion) 20:04, 12. Nov. 2015 (CET)

Aktualisierung Kategorie:Wikipedia:Seite_mit_Einzelnachweisfehlern

Ich schau in letzter Zeit öfter mal Kategorie:Wikipedia:Seite_mit_Einzelnachweisfehlern durch, und habe das über die letzten paar Tage nahezu leer und damit sehr übersichtlich gehalten. Dabei ist mir aufgefallen, dass immer wieder Seiten neu in der Liste auftauchen, die den Fehler schon "ewig" beinhalten. Ein Beispiel von heute ist Pfarrkirche Münzbach. In diesem Fall sieht es so aus, als wäre die Seite durch den Edit um 16. Nov. 2015‎ von der Software neu überprüft und die Wartungskategorie nachgetragen worden. Das fände ich zwar unschön, aber irgendwie plausibel.

Gestern hatte ich jedoch bei Einstrahliges Flugzeug einen neu in der Kategorie aufgetauchten Fall, wo der letzte Edit 22. Aug. 2015‎ stattgefunden hat. Irgendwie muss der Mechanismus hinter der Überprüfung also hier ein anderer sein. Weiß jemand was näheres über den Mechanismus? --Windharp (Diskussion) 10:39, 17. Nov. 2015 (CET)

PS: Würde es evtl. Sinn machen die Software dazu zu bringen mal alles abzugrasen? --Windharp (Diskussion) 10:42, 17. Nov. 2015 (CET)

Die Methodik, was als Fehler gilt, wurde vor wenigen Wochen erweitert; es werden inzwischen wesentlich mehr und/oder andere Fehler durch Mediawiki gefunden. Wir hatten intern aber auch schon kategorisiert, was wir jetzt wieder zurückbauen.

Die Neukategorisierung erfolgt immer dann, wenn ein Artikel bearbeitet wurde; ggf. auch aus anderen Gründen.

Es wird erfahrungsgemäß Wochen bis Monate dauern, bis die Altbestände durch den neuen Algorithmus gegangen sind, und in dieser Zeit werden immer mal wieder alte Neuzugänge hereintröpfeln.

VG --PerfektesChaos 12:16, 17. Nov. 2015 (CET)

Okay, also primär die Methode die ich vermutet habe. Danke PerfektesChaos. Ich vermute es gibt keinen Mechanismus der für Vollständigkeit der Prüfung sorgt? Naja irgendwas muss ja auch in Zukunft zu tun bleiben :-) --Windharp (Diskussion) 13:21, 17. Nov. 2015 (CET)

Irgendwo steht die Aussage, dass Artikel spätestens nach 30 Tagen neu durch den Parser geschickt werden - 30 Tage nach entsprechenden Softwareänderungen sollte also nichts neues mehr auftauchen, außer es werden neue Fehler eingebaut natürlich. Selbst dann kann der letzte Edit aber lange zurückliegen, wenn das Problem durch eine Vorlagenänderung entsteht. --mfb (Diskussion) 13:36, 17. Nov. 2015 (CET)