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)

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="/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)

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)

Hinweis auf diesen Edit, der m. E. zurückgesetzt werden sollte.

An der Sache selbst hat sich aber nichts geändert: <element class="metadata">…<element> blendet nur aus, was innerhalb des Elements steht, und dazu gehören Fußnoten nun einmal nicht. Es wird sich auch niemals etwas daran ändern, da die Fußnoten ein Feature der MediaWiki-Software sind, während class="metadata" ein lokaler CSS-Hack ist, mit dem die MediaWiki-Software nicht rechnet. Es ist technisch unmöglich, diese Konstellation durch eine Erweiterung des lokalen CSS-Hacks zu erkennen, da CSS hierfür nicht ausdrucksstark genug ist.

PS: Ich sehe die Ausbreitung von class="metadata" mittlerweile als Fehlentwicklung an, die geordnet zurückgebaut werden sollte. --Entlinkt (Diskussion) 06:51, 24. Apr. 2016 (CEST)

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)

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)

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)

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)

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)

Für das Problem mit dem nutzlosen Text „Karte“ hätte ich die folgenden 3 Edits aus dem β-dewiki anzubieten:

• Vorlagenfix
• Gadget-Fix 1 (OpenStreetMap)
• Gadget-Fix 2 (WikiMiniAtlas)

Sind die Fixes richtig?

• Es müssen beide Gadgets gefixt werden, da die Logik lauten muss: „Vorlagenkonstrukt genau dann sichtbar, wenn mindestens eines der beiden Gadgets aktiviert“
• .show() ist IMHO nicht so günstig, da es das Vorlagenkonstrukt auch in den Skins sichtbar machen würde, in denen die Oben-Rechts-Positionierung nicht implementiert ist. Deshalb .css('display', ''), womit nur die Inline-Ausblendung entfernt wird.
• Der Hook für WMA ist wohl recht neu und wird anscheinend von sonst niemandem auf der Welt verwendet, ist die Verwendung sinnvoll?

Gruß --Entlinkt (Diskussion) 04:39, 14. Mai 2016 (CEST)

Ich habe jetzt nichts getestet, aber die Änderungen sehen gut aus, bei show vs. css hast du vollkommen recht. Der Hook scheint wirklich noch nirgendwo verwendet zu werden (auch eine Suche direkt auf en:, nl:, pt:, mw:, m: und c: für den Fall, dass Google die Seiten nur nicht indexiert hat brachte nichts), aber das sollte kein Grund sein ihn nicht zu verwenden. Krinkle weiß ja im Allgemeinen, was er tut. --Schnark 10:11, 14. Mai 2016 (CEST)

Ich habe es (ein wenig) getestet und setze es jetzt um, aber ganz ehrlich: Ich mag {{Karte}} überhaupt nicht. Diese Vorlage hatte schon in dem Moment ein Problem, in dem sie erstellt wurde, und es steht sogar explizit auf der Diskussionsseite, dass sie ein Hack ist. Mit atemberaubenden 242 Einbindungen nebenbei auch einer mit relativ wenig Bedarf.

Irgendwann einmal sollten wir es wirklich schaffen, von den Hacks wegzukommen und Probleme entweder gleich richtig oder überhaupt nicht zu lösen. Ich mache das jetzt vor allem deshalb, weil das (sowieso bereits vorhanden gewesene) Problem durch meine Auslagerung leicht verschlimmert wurde, sehe mich aber weiterhin nicht als Maintainer des/der Gadgets. --Entlinkt (Diskussion) 16:10, 14. Mai 2016 (CEST)

Leerzeilenbug

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)

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)

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)

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

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

Überschriftensimulationen an Typografie-Update anpassen

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, 30. Mai 2024

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

Achje.

   Nächster Termin: Mittwoch, 5. Juni 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 8. Mai 2024 noch nicht vorbei ist, so ist es dieser, ansonsten ist es 5. Juni 2024. --Schnark 09:27, 30. Jan. 2015 (CET)

Das heißt, falls ich mich nicht verrechnet habe, ist das gesuchte Datum 5. Juni 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: 5. Juni 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)

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)

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)

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)

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)

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. [9]. 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)

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)

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)

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)

Skript zum farbig unterlegen auf Links zu Artikeln, die ein bestimmter Benutzer erstellt hat

Hallo,

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

Ähnlich wie bei BKL geht es sicher nicht - dort hilft die Mediawiki-Software und gibt den Links eine Kennzeichnung, die dann nur noch sichtbar gemacht werden muss. Ein solches Script müsste sich irgendwo extern eine Liste der erstellten Seiten holen und dann jeden Link mit dieser Liste abgleichen. Wenn es dir um die Artikel geht und nicht um Links darauf, wieso nicht einfach diese Liste der erstellten Seiten durchgehen? Links auf relevante Personen sind fast immer sinnvoll, selbst wenn es den Artikel gar nicht gibt. --mfb (Diskussion) 11:46, 26. Nov. 2015 (CET)

Hilft dir evtl. diese Suche weiter? [10]? Da werden nur die neu von ihm erstellen Seiten gelistet. --Wassertraeger  12:19, 26. Nov. 2015 (CET)

Es geht nicht darum, dass Personen relevant sind. Es geht darum, wie Artikel eines gewissen Benutzers aussehen und diese möchte ich einfach nicht mehr ansehen. --Der Buckesfelder  ^Disk.  _bewerten  ^E-Mail 12:48, 26. Nov. 2015 (CET)

Ach so, also exakt das Gegenteil der Suche die ich vorgeschlagen habe. Eine ignore-Funktion quasi. Ja, die möchte ich auch bei einigen haben. Ärgern Dich die Boxer denn so sehr? --Wassertraeger  12:57, 26. Nov. 2015 (CET)

Du könntest etwas analog zu Benutzer:Mfb/monobook.css anlegen (ganz unten), braucht dann eine lange Liste aller (~700) Artikel, die manuell aktualisiert werden muss, und wird vermutlich das Laden von Seiten merklich verlangsamen. Testobjekte: Luis Alberto Pérez (Boxer), Robbie Regan, Lee Haskins. --mfb (Diskussion) 13:24, 26. Nov. 2015 (CET)

@Buckesfelder:

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

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

@PerfektesChaos: Danke für die ausführlichen Informationen. Leider kann ich das (noch) nicht, ab der Ehrgeiz hat mich gepackt und irgendwann habe ich das dann auch (hoffentlich umgesetzt).

Zur {{Internetquelle}}: Das Problem waren nicht die Altlasten. Die wandle ich ich eigentlich, sofern ich den Link bearbeite, in YY-MM-DD um. Vielmehr hatte der Vorlagenmeister Probleme mit neueingegebenen Daten in dem oben genannten Format. Ich konnte leider noch nicht herausfinden woran das liegt, hatte das aber noch vor. Doch durch nervende Stubs und vielen Diskussionen auf WP:VM, WP:QS usw. hatte ich einfach keine Lust und Reiz mehr. Deshalb war ich so egoistisch und habe die entsprechenden Zeilen einfach gelöscht. Falls du eine Idee hast, woran das liegen könnte, nur her damit. Grüße --Der Buckesfelder  ^Disk.  _bewerten  ^E-Mail 13:07, 27. Nov. 2015 (CET)

@Skript-Idee:

• Alle aufgelisteten Regeln sollten nicht nur auf Wikilinks vom momentanen Artikel aus gelten, sondern auch für die momentane Seite selbst. Da müsste dann im Seitenkopf ein Kasten angezeigt werden.
• Eine weitere Regel könnte sein: Benutzer X hat innerhalb der letzten 50/100/500 Bearbeitungen (maximal 30/90/1000 Tage zurück) die Seite bearbeitet.
• Ein Teil der Regeln eignet sich dazu, lokal zur Beschleunigung gespeichert zu werden (Seitenersteller, werden keine 10.000 sein; was beobachte ich? – Seiten in Kategorie/Unterkat); andere wie diese eben müssten live abgerufen werden.
• Nicht nur Benutzer-Nicks, sondern auch IPv4-Ranges.
• Bei hinreichender Flexibilität in Sachen Regeln würde ein solches Werkzeug in interessierten Kreisen durchaus Anklang finden.

@Vorlagenmeister:

• Ich hatte dieses Vorlagenmeister vor einem Jahr geschrieben, damals erfolgreich getestet und seitdem alles vergessen. Ich werde mich, wenn ich mal einen Block konzentrierte Zeit habe, auf BETA an eine Rekonstruktion des von dir geschilderten Problems machen. Wohl eher Jahreswechsel.

LG --PerfektesChaos 13:29, 27. Nov. 2015 (CET)

Probleme bei der PDF- bzw. Buchherstellung

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

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

Liste im IE, FF

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

Am IE. Quelltextmäßig ist alles richtig gelaufen. Aber der IE kann das nicht (wobei der Vergleich ziemlich veraltet wirkt). Vorschlag: 1. nochmal explizit als solches festlegen, dann wird im IE nur die erste Zeile falsch angezeigt. --mfb (Diskussion) 18:05, 18. Dez. 2015 (CET)

Soweit so gut, nur haben wir nun im IE eine doppelte "1". Ich mag ich glauben, dass es für dieses IE-Problem keinen Workaround gibt. --He3nry Disk. 09:10, 19. Dez. 2015 (CET)

Neues Benutzerskript: WikiBar

Hallo liebe Mitstreiter,

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

Ja, die Doku ist fein, und nach WP:HX hast du ja schon hingefunden.

• Auf deiner Doku-Seite hättte ich gern noch einen auffindbaren Abschnitt zu den Codes mit Links zu allen beteiligten JS(/CSS?).

Hinsichtlich deiner Parameter rege ich die Wahl eines vielleicht noch etwas spezifischeren Bezeichners an

• und dann Registrierung auf WP:JS/LIBS
• und dann Optionsparameter in einem mw.libs-Objekt, statt einzelner globaler Variablen.
  • Siehe etwa Benutzer:Flominator/WaWeWeWi.js
  • und weiter Wikipedia:Technik/Skin/JS/Datenelemente #config.opt –
  • vor zehn Jahren hatte man mal lose Parameter verteilt.
• Du kannst dich nicht darauf verlassen, dass eine solche lokal definierte Funktion des Anwenders langfristig nutzbar wäre; es ist kein zukunftsweisendes Konzept.

LG --PerfektesChaos 19:28, 28. Jan. 2016 (CET)

Eine Einstellung für alle Acc (Global Settings)

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

• Ich hatte mal ein Konzept für ein solches Gadget, bin aber aus Zeitmangel nicht dazu gekommen.
• Du kannst:
  1. Benutzer:PerfektesChaos/js/preferencesGadgetOptions #Installation laden.
  2. In die Callback-Funktion schreibst du rein, dass gemäß WP:JS/V #Benutzerkonfiguration mw.user.options.get("language") mit de verglichen werden solle, usw.
  3. Wenn das nicht den gewünschten Wert hat, kannst du preferencesGadgetOptions.string() zum Setzen benutzen.
  4. Was für Zeichenketten du bei logischen und numerischen Einstellungen verwenden müsstest, darfst du selbst herausfinden. Keine Ahnung; wenn du schlauer geworden bist, schreib es auf. "" neutralisiert vermutlich.
  5. Die ganze Installations-Aktion hüllst du in eine Abfrage auf wgNamespaceNumber (===2) und wgTitle (dein Nick), so dass es nicht auf jeder, sondern nur auf deiner Benutzerseite gestartet wird. Damit kannst du einmalig initialisieren und gelegentlich auch spätere Veränderungen propagieren.
  6. Für andere Benutzer kannst du eine Trennung in Programm und Daten vornehmen und ein konfigurierbares Objekt mit Eigenschaftsnamen und Sollwerten an ein neues Gadget übergeben, das dann die Analyse und Zuweisung für beliebige Eigenschaften ausführt.

Viel Spaß --PerfektesChaos 12:14, 18. Mär. 2016 (CET)

Wow* danke, da war ich wohl sehr naiv mit Snippet (deswegen habe ich jetzt auch nicht direkt nach einem Script gesucht). Ich teste mal morgen (wenn ich's schaffe). PS: Spontan habe ich jetzt nur einen Typo im Installtions-Code bemerkt, ein ] zu viel (die jshint tatsächlich nicht muckiert). ↔ User: Perhelion 15:15, 18. Mär. 2016 (CET)

• Eiwei; letzteres ist ja peinlich und noch von irgendwas übriggeblieben. Natürlich veröffentliche ich jshint-geprüft, verwende selbst den angegebenen Code aber niemals.
• Du kannst auch in der enWP gucken, vielleicht hat da schon jemand was.
• Vielleicht will oder muss man mal zu Testzwecken eine Einstellung ändern; da wäre es fies, wenn die beim Aufbau jeder beliebigen Seite sofort zurückgesetzt würde.
• Ein MW-Projekt zu sowas scheiterte daran, dass es absolut nicht wünschenswert wäre, auf jedem SUL-Wiki identische Konfigurationen für alles zu haben; Heimatwikis sind anders konfiguriert als Meta oder MW oder testwiki oder irgendein zufällig mal besuchtes Wiktionary. Also kann das nur für bestimmte Eigenschaften gelten, und ggf. braucht man zu jeder Eigenschaft noch eine Ausnahmeliste mit DB-Namen, wo das ignoriert werden soll.

LG --PerfektesChaos 15:48, 18. Mär. 2016 (CET)

Ein Button "diese Einstellung global übernehmen" würde schon viel helfen. Wer Ausnahmen will, kann diese danach einstellen oder den Knopf nicht nutzen. Besser noch: "diese Einstellung global übernehmen, sofern eine Einstellung nicht vom lokalen Standardwert abweicht". Wäre sicher einfach einzubauen und würde so viel helfen... --mfb (Diskussion) 22:50, 18. Mär. 2016 (CET)

• Das schreibst du so locker-flockig dahin; aber die Konsequenzen wären nicht trivial, und deshalb wurden diese Vorschläge bislang alle abgelehnt.
• Nehmen wir mal an, es gäbe so eine globale Preferences-Seite. Alles, was dort als Vorgabe markiert ist, solle sich so auf die lokalen Wikis auswirken. Das kann auf eine von drei Arten geschehen:
  • Die globale Einstellung hat den unbedingt verpfichtenden Wert.
    • Die lokale Einstellung für diese Option ist dann grau, festgelegt. Kein lokales Wiki kann sie ändern.
    • Man will aber in seinem Heimatwiki und einigen häufig besuchten Arbeitswikis (deWP, Commons, Wikidata, deWikisource) abweichende Einstellungen haben; für Beo und Echo und alles. Fremde Wikis sollen Echo per Mail, das Heimatwiki soll niemals mailen. Manches hängt von Sprache oder Schrift ab.
    • Gadgets sind sowieso ein lokales individuelles Angebot.
    • Jedoch soll in nur selten und zufällig besuchten Wikis das globale Schema gelten.
    • Maximal für die Sprache der Benutzeroberfläche würde eine solche globale Vorgabe sinnvoll sein. Die kann man dann aber nirgendwo noch in die lokale Sprache ändern, um sich mit jemand auszutauschen, wie bestimmte Menüfelder heißen.
  • Die globale Einstellung kann lokal überschrieben werden.
    • Dann haben die Checkboxen keine zweiwertige Logik ja/nein mehr, sondern eine dreiwertige:
      1. Lokal definitiv JA
      2. Lokal definitiv NEIN
      3. Verwende den momentanen Wert von GLOBAL (Vorgabe).
    • Statt einer Checkbox mit Häkchen muss dann eine Optionsliste mit den drei möglichen Werten angeboten werden.
    • Bei Zeichenketten wie der Sprachauswahl wird es noch komplizierter.
      • Wenn ich lokal aus irgendeinem Grund de-CH eingestellt habe und eine Stunde später klicke ich global auf de für alle; soll dann auch mein de-CH umgeschaltet werden, oder soll meine lokale Auswahl bleiben?
      • Wenn ich nach der globalen Vorgabe später lokal setze, soll aber die lokale Auswahl bis auf Weiteres gelten.
  • Die globale Einstellung gibt nur für alle Wikis, auf denen ich schon mal war, den Momentanwert vor; setzt ihn jetzt einmalig unbedingt auf diesen Wert zurück.
    • Dann schrottet es meine vier Arbeitswikis.
    • Wenn ich noch nie auf diesem Wiki gewesen bin, dann soll statt der MW-Vorgabe meine globale Einstellung die Vorgabe sein. Okay, wäre nett.
• Resultat der Beratungen war, dass es kaum Einstellungen gibt, von der Oberflächensprache abgesehen, für die man solche globalen Einstellungen problemlos auf alle lokalen Wikis übertragen kann, oder die Standardeinstellungen von MW treffen es sowieso und man braucht lokal kaum was zu verstellen.
  • Das resultierende Verhalten wäre kryptisch, konfus und unflexibel.
  • Kaum jemand würde ein solches Feature benutzen wollen, mit dem man sich die lokalen Konfigurationen unvorhersagbar wieder zerschießt, und breiten Bedarf gibt es auch nicht.
  • Lohnt den Aufwand nicht.

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

Was du da beschreibst, wäre alles viel komplizierter als die beiden von mir beschriebenen Optionen, die sehr viel helfen würden. Es ist keine globale Einstellung nötig, eine globale Seite die lokale Einstellungen ändern kann (wie oben beschrieben) wäre völlig ausreichend. --mfb (Diskussion) 20:48, 24. Mär. 2016 (CET)

Nekrolog-Kopiervorlage

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

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

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

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

Hat vor kurzem wieder funktioniert, jetzt wieder nimmer Vorlage:Smiley/Wartung/:(  http://tools.wmflabs.org/persondata/service/nekrolog/onearticle.php?article=5505379 --Flominator 18:14, 9. Dez. 2016 (CET)

Jetzt wieder. --Flominator 09:13, 18. Mär. 2017 (CET)

Verwandte Seiten

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

Werden die Vorschläge anhand der Kategorien gemacht? --FNDE (Diskussion) 23:06, 5. Apr. 2016 (CEST)

Siehe zum Hintergrund der Funktion dieses Meinungsbild in Vorbereitung: Wikipedia:Meinungsbilder/Mehr erfahren (Unterstützer gesucht!) - und die Links, die sich dort finden. Soviel ich weiss, ist die Funktion immer noch ein Beta-Feature und muss bewusst eingeschaltet werden, ist auch für angemeldete Benutzer noch nicht Standard. Man kann die Auswahl in einzelnen Artikeln anpassen, indem eine Zeile in diesem Stil eingefügt wird: {{#related:Neue Seite 1}}{{#related:Neue Seite 2}}{{#related:Neue Seite 3}} Gestumblindi 23:50, 5. Apr. 2016 (CEST)

Vielen Dank für die ausführliche Erklärung! Bei den Kategorien der beiden Artikel habe ich als Übereinstimmung Deutscher gefunden, im Artikel Zweiter Weltkrieg. Das dritte Bild hieß Landsberg/ Lech und kam bei Fiedler-Winter als Verlagsort eines Buches von ihr vor. MoSchle (Diskussion) 18:27, 6. Apr. 2016 (CEST)

Editnotice für ganze Gruppen von Artikeln einrichten?

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

Die technische Auskunft stimmte, siehe Hilfe:Editnotice. Ob das, was Du willst, anders ginge, oder ob es wirklich sinnvoll wäre, kann ich nicht sagen. Auf enwiki unterdücke ich den editnotice-Spam mit en.wikipedia.org##DIV[class="editnotice-page"] im AdBlock. –Be..anyone 💩 16:40, 14. Apr. 2016 (CEST)

wie auf Wikipedia:Administratoren/Anfragen#Editnotice Schweizbezogen bemerkt, halte ich nicht nichts von massenhaften Verteilen von Editnotice-Seiten, da es für das gewünschte Ziel auch einfachere Methoden gibt, die nicht unnötigen Wartungsaufwand im Nachhinein verursachen (Etwa nach Seitenverschiebungen). Ich schätze, dass das derzeitige Editnotice-System irgendwann komplett geändert wird, und danach eigene Editnotice-Seiten gar nicht mehr notwendig sein werden. Die bestehenden werden dann wohl Löschkanditaten.  Frohes Schaffen — Boshomi ⌨   17:33, 17. Apr. 2016 (CEST)

Shared tabular data storage for Commons!

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

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

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

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

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

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

JavaScript-Lösung für MediaWiki:Specialpage-helplink

Hallo,

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

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

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

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

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

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

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

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

Die „Design-Ziele“ meines Entwurfs sind folgende:

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

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

Statt prependTo fände ich appendTo logischer (auch wenn es in der Praxis keinen Unterschied machen sollte). Der Form halber wäre es zudem schön, wenn es zumindest ein Phabricator-Ticket gäbe, in dem darum gebeten wird, die indicator-Methode überall möglich zu machen, dieses beim Code erwähnt wird und dann natürlich auch die Seiten umgestellt werden, wo kein JS zur korrekten Anzeige mehr notwendig ist. Ansonsten volle Zustimmung von meiner Seite. --Schnark 09:32, 12. Mai 2016 (CEST)

Der Beweggrund für prependTo war folgender: Die <indicator>-Elemente sind ja rechtsbündig ausgerichtet und das Skript würde den Hilfe-Link dort hinzufügen. Wenn eine Spezialseite aus irgendeinem Grund ein „echtes“ <indicator>-Element enthält, würde ein appendTo des Hilfe-Links dazu führen, dass das „echte“ <indicator>-Element während des Ladevorgangs wahrnehmbar nach links rutscht. Mit prependTo wird dieser Effekt vermieden. In der Praxis tritt so eine Konstellation aber derzeit eh nirgends auf.

Ein Phabricator-Task wäre sicher gut, aber ich bin nicht sicher, was drin stehen sollte. Man könnte anregen, dass die <indicator>-Methode in den betroffenen Systemnachrichten verfügbar gemacht wird, aber man könnte auch anregen, dass jede betroffene Spezialseite einen MediaWiki-eigenen Hilfe-Link erhält (was gemäß phab:T45591 vermutlich prinzipiell erwünscht ist). Beides würde unsere Probleme lösen, aber ich fände es etwas dreist, gleich beides anzuregen.

Was mich noch interessieren würde, wäre die Sicherheit. Ist der konkret vorgeschlagene Code dahingehend problematisch? Es werden ja Elemente ungeprüft verschoben, was bei benutzergenerierten Inhalten grundsätzlich problematisch sein kann, allerdings kenne ich benutzergenerierte Inhalte auf Spezialseiten nur auf Special:ExpandTemplates.

Wenn man diese Lösung aktivieren würde, sollte das dann ein hidden-Gadget sein oder sollte der Code direkt in MediaWiki:Common.js stehen? Viele Grüße --Entlinkt (Diskussion) 13:01, 12. Mai 2016 (CEST)

Bei appendTo vs. prependTo war meine Überlegung, was passiert, wenn auf einer Spezialseite dynamisch Inhalt hinzugefügt wird, der .specialpage-helplink-Elemente enthält. Das sollte zwar auch nirgendwo vorkommen, aber in dem Fall wäre es logischer, die neuen Elemente anzuhängen.

DOM-Elemente zu verschieben sollte keine Sicherheitsprobleme erzeugen. Da sehe ich keine Probleme. Die ISBN-Suche kann übrigens auch von autoconfirmed-Benutzern bearbeitet werden.

Zu Gadget vs. Common.js: Der Code muss ohnehin auf allen Seiten geladen werden (die Abfrage, ob man sich auf einer Spezialseite befindet vom eigentlichen Code zu trennen, wäre wohl zu ineffizient), da der Code aber immer auf das mediawiki.helplink_Modul warten muss, gäbe es selbst mit einem im Seitenkopf geladenen Gadget keinen flackerfreieren Aufbau. Damit spielen die beiden Hauptgründe für eine der beiden Methoden keine Rolle. Wenn es ein Gadget wird, dann sollte in Common.js zumindest ein Kommentar, der darauf hinweist, damit Benutzer, die an der klassischen Stelle nach dem Code suchen ihn auch finden. --Schnark 10:37, 13. Mai 2016 (CEST)

OK, vielen Dank soweit. Aber noch eine Frage:

Eigentlich muss der Code gar nicht immer auf das Modul mediawiki.helplink warten, da dies nur CSS enthält, das nur gebraucht wird, wenn ein .specialpage-helplink-Element vorhanden ist. Ist es überhaupt korrekt, diese Beziehung durch eine Abhängigkeit auszudrücken? Man könnte auch (analog zu dem Nachladen von jquery.ui.button in MediaWiki:Common.js) zuerst die Seite analysieren und es nur laden, wenn mindestens ein .specialpage-helplink-Element da ist. Oder wäre dann ein FOUC zu befürchten?

@Umherirrender: Vielleicht kannst du auch noch etwas dazu sagen, da du die Systemnachricht erstellt hattest? Vor allem würde mich interessieren, warum <indicator> an manchen Stellen nicht geht, wie aufwendig es wäre, das zu ändern und ob es überhaupt sinnvoll ist, diesbezüglich eine Änderung anzuregen.

Sorry für die vielen Fragen, aber ich kenne mich da nicht so aus und möchte vermeiden, dass etwas falsches/suboptimales gemacht wird. Gruß --Entlinkt (Diskussion) 10:54, 13. Mai 2016 (CEST)

Mit einem Nachladen statt der Abhängigkeit hätte man (vermutlich, ausprobiert habe ich es nicht) einen en:FOUC, was vermutlich (auch das habe ich nicht probiert) wesentlich störender wäre, als ein leicht verzögertes Auftauchen. --Schnark 11:11, 13. Mai 2016 (CEST)

Angefangen hat es hier, als es mehr wurde habe ich eine Vorlage raus gemacht, damit es überall gleich aussieht.

Technische Hintergrund: Das indicator-tag gehört (wie auch ResourceLoader-Module) zu den Metadaten des Output-Objects in MediaWiki. Beim parsen von Systemnachrichten werden diese Metadaten nicht verwendet, sondern nur der Text. Das führt dazu, dass die indicator-Tags in Systemnachrichten nicht funktionieren. Beim TOC ist es ähnlich, da das JS-Modul für das ausblenden zu den Metadaten hinzugefügt wird, ist es auf Spezialseiten nicht vorhanden (T66969). Meine Lösung war mal gerrit:196626, es gibt aber zu viele Bedenken wegen Seiteneffekte.

Am besten wäre es, wenn der generische Systemnachricht-Name zum überschreiben der Helplinks auf allen Spezialseiten funktionieren würde und standardmäßig nur leer ist, dann braucht es kein JS. Dies werde ich mal ausprobieren. Der Umherirrende 15:30, 13. Mai 2016 (CEST)

Veraendertes nowiki - tag Verherhalten ??

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

Falls du dies meinst: Das Tag ist bei dir nicht geschlossen, d. h. du hast nur das Start-Tag (<nowiki>) angegeben, aber nicht das End-Tag (</nowiki>).

So ist es nicht richtig:

<nowiki>[[Kategorie:Wikipedia:Hauptseite]]

So ist es richtig:

<nowiki>[[Kategorie:Wikipedia:Hauptseite]]</nowiki>

Siehe auch Hilfe:Tags#Syntax.

Es mag sein, dass sich das Verhalten der Software bei unvollständigen Tags auch mal ändert und dass das fehlende End-Tag früher „toleriert“ wurde, das weiß ich aber nicht sicher. Viele Grüße --Entlinkt (Diskussion) 19:53, 1. Jun. 2016 (CEST)

Das nowiki-Tag selber hat sich nicht geändert, aber jedes MediaWiki-Tag wird seit einigen Wochen nur noch erkannt, wenn es auch geschlossen wird. Da es bei deinen Verwendungen nur ein offnes nowiki-tag gibt, wird es nicht mehr erkannt. Schreibe auch noch ein schließendes Tag ans Ende der Seite und du hast die Funktion wieder. Der Umherirrende 19:55, 1. Jun. 2016 (CEST)

Ist das auch bei div, span und font so? Da wird eine kaputte Verwendung ja (leider) auch von MediaWiki repariert. Würde (imho erfreulicherweise) ein paar Verwendungen auf BD-Seiten (und bei font auch anderswo…) beenden :-) --nenntmichruhigip (Diskussion) 12:42, 2. Jun. 2016 (CEST)

Meines Wissens nicht. Geplant sind aber zwei Dinge:

• Laut phab:T134423 soll die Self-Closing-Syntax bei HTML-Tags (d. h. sowas wie <div style="clear:both;"/> bald nicht mehr unterstützt werden. Das betrifft bei uns einige produktiv genutzte Vorlagen, wo dies irrigerweise eingebaut wurde, und insbesondere eine ganze Reihe von Artikeln, wo {{Absatz}} substituiert wurde, als es genau dieses Konstrukt enthielt.
• Laut mw:Parsing/Replacing Tidy soll HTML Tidy entfallen und dadurch ersetzt werden, dass man den Code durch einen HTML5-Parser schickt und wieder serialisiert. Der Effekt ist dann in HTML5-konformen Browsern derselbe wie keine Reparatur (und in nicht-HTML5-konformen Browsern derselbe wie in HTML5-konformen). Die üblichen Verwendungen auf BD-Seiten, die mir so einfallen, würden damit aber möglich bleiben (da ein HTML5-Parser diese genauso behandelt wie Tidy).

Beide Änderungen werden aber wohl noch eine Weile dauern. --Entlinkt (Diskussion) 12:45, 2. Jun. 2016 (CEST)

Praktisches Beispiel: Die Implementierung des Geo-Mikroformats in Vorlage:CoordinateMain verlässt sich derzeit darauf, dass Tidy leere <span>-Elemente entfernt und verzichtet deshalb an einer sehr performancekritischen Stelle auf einige #if-Abfragen. Dies wird kaputtgehen. --Entlinkt (Diskussion) 13:19, 2. Jun. 2016 (CEST)

mit </nowiki> gehts wieder, logisch Verständlich aber nervig -- A1000 (Diskussion) 15:03, 2. Jun. 2016 (CEST)

Aktuell gilt es nur für MediaWiki-Tags, nicht für html-Tags. Gilt also für <abschnitt>, <categorytree>, <ce>, <charinsert>, <gallery>, <graph>, <hiero>, <imagemap>, <indicator>, <inputbox>, <math>, <nowiki>, <poem>, <pre>, <ref>, <references>, <score>, <section>, <source>, <syntaxhighlight>, <templatedata> und <timeline> (Geklaut von Spezial:Version). Für noinclude, includeonly und onlyinclude weiß ich es nicht. Der Umherirrende 17:56, 2. Jun. 2016 (CEST)

Zwei Dinge

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

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

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

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

Hallo Kenny McFly,

mal nur zum zweiten Punkt: Das Thema ist ein Dauerbrenner, es gab diverse Diskussionen hierzu unter Wikipedia Diskussion:Helferlein/Begriffsklärungs-Check/Archiv.

Um es kurz zu machen: Eine derartige Erweiterung des Helferleins wäre trivial realisierbar, wurde aber bisher immer abgelehnt, da Links auf Weiterleitungen im Gegensatz zu Begriffsklärungen in der Regel nicht umgebogen werden müssen und auch nicht umgebogen werden sollen. Die Erweiterung des Helferleins würde dazu führen, dass zu viele Benutzer zu prominent auf Weiterleitungen hingewiesen werden, was mit der Gefahr verbunden wäre, dass unerwünschte Umbiegungen stattfinden.

Daher sollte es wohl dabei bleiben, dass die Hervorhebung von Weiterleitungen nur durch individuelle CSS-Einträge erfolgt. Ich persönlich verwende folgendes in Special:Mypage/common.css:

/* Weiterleitungen mit einem vorangestellten Pfeil markieren */
.mw-redirect:before {
	content: "↪";
}

Eine Hintergrundfarbe wäre mir persönlich zu penetrant. Gruß --Entlinkt (Diskussion) 23:07, 5. Jun. 2016 (CEST)

An diesen Gegenpunkt habe ich auch gedacht. Er regt mich auf, aber lässt sich leider sowieso nicht verhindern. Aber vielen Dank für den Code (oder wie das heißt. Ist nicht mein Fachgebiet). Dankeschön und Gruß Kenny McFly (Diskussion) 23:11, 5. Jun. 2016 (CEST)

Bildnotizen ...

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

Also ich kenne so ein Gadget nicht, höchstens eins von Schnark. Ich habe aber auch gehört dass soetwas offiziell von Wikimedia in Planung ist. ↔ User: Perhelion 09:50, 8. Jun. 2016 (CEST)

Ach zufällig gesehen: c:Commons:Forum #Bildnotizen_... (manchmal ist die Glaskugel mir sehr gnädig) Den deutschen Namen dafür kannte ich nicht, wird auch erst weiter unten in der Beschreibung verwendet c:Help:Gadget-ImageAnnotator/de, dann wechselt der Begriff auch mal zu "Bildvermerk-Werkzeug". Sehr gute Idee einer Software mehrere Namen zu geben.

@Zur Frage: Ich empfehle dir erst mal den gelben Kasten prominent ganz oben durchzulesen, da du ja schon mindestens an 3 weiteren Stellen die Frage gestellt hast. ↔ User: Perhelion 10:29, 8. Jun. 2016 (CEST)

Da ich kein IT-Fachmann bin verstehe ich dieses Kauderwelsch nicht. :-( --Andreas Schwarzkopf (Diskussion) 11:04, 8. Jun. 2016 (CEST)

Kategorie ermitteln im Bearbeiten-Modus

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

Afaik werden alle Kategorien angezeigt, aber (wie z.B. die Abschnitte im Inhaltsverzeichnis) nur die, die im bearbeiteten Abschnit enthalten sind. --nenntmichruhigip (Diskussion) 21:02, 24. Jun. 2016 (CEST)

Hm, also ich sehe hier (Wikipedia:Technik/Werkstatt) nix, auch bei kompletter Seiten-Bearbeitung. tatsächlich bräuchte ich diese bei Abschnitts-Bearbeitung und tatsächlich ist es jetzt im konkreten Fall eine versteckte, also konnte ich diese per Selektor-Abfrage:

var exists = 0;
$('.hiddencats li').children('a').each(function () { // check cats
	if ( this.text && /Non-talk pages that are automatically signed$/.test( this.text ) )
		exists = 1;
});

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

Wikihistory

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

Erweiterung des BKL-Check

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

Das müsste doch mit Benutzer:Schnark/js/bkl-check möglich sein. -- FriedhelmW (Diskussion) 22:07, 29. Jun. 2016 (CEST)

Nein, das benutze ich, das funktioniert nicht. --Informationswiedergutmachung (Diskussion) 22:24, 29. Jun. 2016 (CEST)

Das Script müsste manuell alle verlinkten Seiten überprüfen. Bei der normalen BKL-Anzeige liefert die Software die Info gleich im Quelltext mit, aber von unseren BKL II-Vorlagen hat die Software keine Ahnung. Sicher möglich, wäre aber mit erheblichem Traffic verbunden. --mfb (Diskussion) 23:53, 29. Jun. 2016 (CEST)

Was ist wichtiger? Traffic oder ordentlich verlinkte Seiten? Und das Skript muss nur alle Seiten überprüfen, die die genannten Voorlagen haben, nicht alle. --Informationswiedergutmachung (Diskussion) 23:57, 29. Jun. 2016 (CEST)

MEn geht es dabei eher um den Traffic und die Performance beim Benutzer. Wenn das Helferlein das machen würde, würde ich es nicht nutzen, weil mir das viel zu lange dauern würde. Ok, mach ich eh nicht, weil ich aus der Zeit, als das Gadget noch nicht ausschliesslich mit CSS funktionierte, identisches mit anderer Farbe in meiner global.css stehen habe. Deshalb gibt es Schnarks BKL-Check für diejenigen, die sich das antun wollen. --nenntmichruhigip (Diskussion) 09:16, 30. Jun. 2016 (CEST)

Jeder BKL-Checker der JavaScript verwendet und nach Kategorien der Links sucht, kann auch nach Vorlagen suchen, dafür müsste man es nur entsprechend erweitern. Da Links auf BKL II aber nicht falsch sein müssen und damit auch nicht umbedingt aus Artikeln verschwinden müssen, wird es wohl weniger Bestrebungen der aktuellen Autoren geben, dies einzubauen (Anders gesagt: Hinweise, die man nicht entfernen kann, werfen nur Fragen auf und lässt man daher). Man kann diese Version auch auf Templates ausdehen oder man nimmt Schnarks Variante. Es Bedarf aber eines Forks (den ich nicht anbieten möchte). Der Umherirrende 10:41, 30. Jun. 2016 (CEST)

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

Weiterleitungen werden seit dem 11. Februar bereits als BKL markiert. Der Umherirrende 10:41, 30. Jun. 2016 (CEST)

@Flominator: Also müßte ich jetzt Karl Marx farblich unterlegt sehen, nachdem ich dein Skript in meine common.js importiert habe? Tut sich aber nix. Woran kann es liegen? MfG --Informationswiedergutmachung (Diskussion) 14:20, 30. Jun. 2016 (CEST)

@Informationswiedergutmachung: Nein, du müsstest auf der linken Seite ein Fenster haben, in dem drin steht, dass Marx eine WL auf Karl Marx ist (solange du einen Artikel bearbeitest(!), in dem Marx verlinkt ist und sich der Artikel im ANR befindet) --Flominator 14:33, 30. Jun. 2016 (CEST)

Da war ein Fenster, ab da stand nichts drin... --Informationswiedergutmachung (Diskussion) 14:38, 30. Jun. 2016 (CEST)

Javascript-Problem Wikipedia-Aufruf mobil?

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

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

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

• First mobile screen with and without description
• 
  You can't tell who Maria Callas is from the first screen
• 
  The current beta view where the descriptions show under the title makes it easy to learn about the topic from the first glance

Bilder beschriften - Panoramabild

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

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

Großenbrode Fehmarnsundbrücke Wulfen Fahrwassertonne Burg Einfahrt i. d. Burger See ↑ Café Sorgenfrei Burgstaaken Windpark Burg auf Fehmarn

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

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

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

Das Panorama ist breiter als mein Browserfenster und die letzten Bildteile stehen untereinander. So geht das nicht. -- FriedhelmW (Diskussion) 18:40, 20. Aug. 2016 (CEST)

@Markus Bärlocher::

• Wenn Du den Code unbedingt in der Bilddatei haben möchtest, dann müsstest Du ihn in diese Grafki-Datei reinschreiben. Verlinkungen sind dann natürlich leider nicht mehr möglich.
• Alternativ könntest Du eine Vorlage basteln, in der dann die Annotation in WikiText drin steht und die Du dann einfach in beliebige Artikel einbinden kannst.

Die Wiki-Text-Umsetzung mit den mehrfachen Bildausschnitten ist jedoch wirklich etwas suboptimal und in diesem Fall auch die falsche Einsatzart von {{Annotiertes Bild}}. Das sollte wohl eher so aussehen:

Vorlage:Annotation/Wartung

Vorlage:Annotation/Wartung

Vorlage:Annotation/Wartung

Vorlage:Annotation/Wartung

Vorlage:Annotation/Wartung

Vorlage:Annotation/Wartung

Vorlage:Annotation/Wartung

Vorlage:Annotation/Wartung

Hafeneinfahrt Burgstaaken-Burgtiefe

Ich bin mal so frei, das im Artikel auszutauschen. // Martin K. (Diskussion) 13:40, 21. Aug. 2016 (CEST)

@FriedhelmW, Markus Bärlocher: MagentaGreen war damit offensichtlich nicht ganz einverstanden. Die Diskussion geht jetzt also im zugehörigen Artikel weiter. // Martin K. (Diskussion) 10:56, 22. Aug. 2016 (CEST)

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

Liebe Techniker, danke für die interessanten Lösungsvorschläge. Nun geht es darum, ein für den WP-Autor simpel zu benutzendes Tool zu schaffen: Klick ins Bild setzt den Cursor, Text eingeben, ggf. Schriftgrösse/Farbe wählen, fertig.

Die dabei entstehenden Metadaten werden in eine Datei geschrieben, die mit dem Bild verlinkt wird. Jede Sprachversion erzeugt eine eigene Metadatei (vielleicht ein neuer Commons-NR?). Die Herausforderung wird sein, die Position und die Schriftgrösse relativ an unterschiedlich skalierte Bilder anzupassen...

Im Artikeltext soll dann nur das Bild und die passende Metadatei eingebunden werden.

Und wenn es ganz komfortabel werden soll: Text horizontal/vertikal bündig machen, Zeilenumbruch, zentriert/links/rechtsbündig.

Gruss, --Markus (Diskussion) 12:23, 26. Aug. 2016 (CEST)

@Markus Bärlocher: Natürlich wäre ein solche WYSIWYG-Editor hier (wie bei vielen anderen Vorlagen auch) hilfreich. Idealerweise würde man so etwas in den VisualEditor integrieren. Allerdings ist der Bau (und die Wartung eines solchen Tools) ziemlich aufwändig (und wäre zu mindest im Fall des VE bei der Foundation angesiedelt). So was wird sich bestenfalls langfristig realisieren lassen. Und wenn man sich ansieht, wie selten die Vorlage Annotiertes Bild bisher verwendet wird, gibt es sicherlich dringendere Baustellen.

Vorlage:Annotation/Wartung

Vorlage:Annotation/Wartung

Vorlage:Annotation/Wartung

Ein annotiertes Bild

Es ist bereit s jetzt so, dass sich einfach Beschriftungen mit relativ wenig Code einbinden lassen. Und ich habe die Vorlage {{Annotation}} (die die Labels steuert) mittlerweile so erweitert, dass sich die Texte mit den parametern valign und halign vernünftig ausrichten lassen:

{{Annotiertes Bild
| image = Pacific Ocean - panoramio - ---=XEON=--- (2).jpg
| image-width = 400
| float = right
| annotations = 

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

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

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

| caption =Ein annotiertes Bild
}}

// Martin K. (Diskussion) 14:03, 26. Aug. 2016 (CEST)

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

Aktueller Stand

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

Grundsätzliche Fragen zu CSS und Wikitext

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

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

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

1. „ganz normales CSS in eine Wikitext-Seite einzubinden“ (meint: style-Rules/sheet statt inline)
   • Im Moment definitiv nicht.
   • Ob vielleicht irgendwann mal – steht in den Sternen.
   • Wenn jemals, dann muss Wechselwirkung zwischen Teilen der Seite und eingebundenen Vorlagen ausgeschlossen werden.
   • Für jetzt: Vergiss es. Ist Absicht, dass das nicht geht.
2. „WikiLinks auf Bilder“
   • Im Prinzip ja.
   • Urheberrechte der Bild-Ersteller sind zu beachten; sonst wird dir das wieder entfernt.
3. „Bilder ohne die WikiSyntax einzubinden“
   • Wird mit voller Absicht verhindert.
   • Gründe: Schadsoftware, Zählpixel, Urheberrechte der Bild-Ersteller
4. „Icon hinter externen Links loszuwerden“
   • Im Prinzip ja.
   • Fraglich ist, warum du überhaupt eines sehen kannst.
   • Wie genau lautet denn die Verlinkung?
5. „welche HTML-Tags von Media-Wiki“
   • H:Tags
   • „weche nicht?“ – dort: Verbotenes HTML

VG --PerfektesChaos 14:32, 21. Aug. 2016 (CEST)

Danke für die schnelle Antwort, auch wenn sie leider meine Befürchtungen bestätigt.

Aktuell sieht der Link so aus. Ich musste leider diese umständliche From wählen, weil ich nur so URL-Parameter übergeben kommte. Oder gibt es da einen anderen Weg?!

[{{fullurl:c:Special:UploadWizard|campaign=wlm-de-bb}} <span class="mw-ui-button" style="width:20em;">Brandenburg&nbsp;»</span>]

// Martin K. (Diskussion) 14:41, 21. Aug. 2016 (CEST)

• Soso, das geht ja nach Commons.
• Und außerdem sind es keine Verlinkungen mittels <a>, sondern es sind href= von <area> in der imagemap.
• Wir hätten da zwar gewisse Möglichkeiten, aber die greifen alle nicht auf <area>.
  • @Umherirrender: Hast du irgendeine Meinung dazu? Entlinkt kaum amüsiert.

VG --PerfektesChaos 15:02, 21. Aug. 2016 (CEST)

Oder mal anders gefragt:

• Wenn du auf dieser Seite sowieso nur einen deutschsprachigen Hochladeassistenten für Commons-Bilder betreiben möchtest –
• warum gliederst du nicht einfach diese Unterseite hier aus, verlinkst nur darauf,
• und legst sie an geeignetem Ort auf Commons an?
• Dann ist sie dort lokal, die Links auch, und einen Icon gibt es deswegen auch nicht.

VG --PerfektesChaos 15:41, 21. Aug. 2016 (CEST)

Die Links in der Imagemap haben kein Icon, die Kästen daneben sind normale Kästen außerhalb der area, da hilft ein plainlinks. Der Umherirrende 16:22, 21. Aug. 2016 (CEST)

Ja, es ging um die Buttons, nicht um die Image-Map. Danke für das einfügen der CSS-Klasse. // Martin K. (Diskussion) 16:51, 21. Aug. 2016 (CEST)

@PerfektesChaos: Es gibt auf Commons ja durchaus ein gespiegelte Seite. Aus Gründen der Nutzerführung, wollen wir nur so viel wie möglich lokal hier in der Wikipedia halten. Schließlich ist die Idee hinter WLM ja gerade, neue Mitarbeiter für unser Projekt zu gewinnen, und da sollte man sie nicht woanders abgertigen. Deshalb werden wir übrigens auch die externe Website abschalten und die URL wikilovesmonuments.de hierher ins Wiki routen. // Martin K. (Diskussion) 16:51, 21. Aug. 2016 (CEST)

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

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

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

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

Ich vermute, dass das von dir vorgeschlagene Verfahren den Seitenaufbau merklich verlangsamen würde. Schließlich müssen mehr Daten vom Server geholt werden. Die Common.css wird nur einmal benötigt und steht dann im Browsercache. -- FriedhelmW (Diskussion) 20:34, 21. Aug. 2016 (CEST)

Es ginge hier ja i.d.R. um maximal eine zusätzlich Anfrage. Und die halte ich für vertretbar, im Vergleich zur Holzhammer-Methode sämtliches CSS von x Unterseiten in die common.css zu stopfen. // Martin K. (Diskussion) 21:34, 21. Aug. 2016 (CEST)

Ideen gibt es schon: phab:T483 oder phab:T37704. Der Umherirrende 20:39, 21. Aug. 2016 (CEST)

Danke für den Hinweis. Ich werd' mir das mal anschauen. // Martin K. (Diskussion) 21:34, 21. Aug. 2016 (CEST)

Link auf Nutzerfunktionsseiten?

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

Ja, Special:MyUploads bzw. Special:MyContributions, ggf mit Interwikipräfix. --nenntmichruhigip (Diskussion) 14:19, 25. Aug. 2016 (CEST)

Super. Danke! // Martin K. (Diskussion) 17:24, 25. Aug. 2016 (CEST)

Unterscheidung Desktop-Version/Mobil-Version?

Und noch eine Frage:

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

@Martin Kraft:

• Du kannst von Desktop-Darstellungen abspecken: Wikipedia:Technik/Mobil #Seitendarstellung.
• Betont interaktive Oberflächen entwickelt man heutzutage so, dass sie auf Mobil klappen; dann funktionieren sie auf den breiteren Desktops allemal und könnten dort ggf. automatisch in die Breite gehen.

VG --PerfektesChaos 15:11, 3. Sep. 2016 (CEST)

@PerfektesChaos: Danke für den Link. Wie man heutzutage mobile-first Websites entwickelt ist mir geläufig – immerhin verdiene ich seit über 10 Jahren meine Brötchen damit und unterrichte es auch an einer Hochschule.

Nur dummerweise ist man in dieser Hinsicht ziemlich aufgeschmissen, wenn man weder Medie Queries noch vernünftiges CSS, sondern ausschließlichInline-styles verwenden kann. Das Ein- und Ausblenden mittels der Klasse nomobile ist zwar besser als nichts, hilft letztlich im Hinblick auf echte Responsiveness und fluide Layouts auch nicht wirklich weiter.

Um mal beim konkreten Beispiel zu bleiben: Die WLM-Seite sitzt ja in einem doppelten Container, der auf dem Desktop ja durchaus seine Berechtigung hat. Dieser besteht aus zwei divs jeweils mit einem padding. In der schmalen Smartphone-Ansicht führt das nun leider dazu, dass sich die beiden Paddings und ggf. noch Einrückungen und float-Element im Inhalt so blöd aufaddieren, dass keine vernünftige Breite mehr für den eigentlichen Inhalt übrige bleibt.

Hätte ich Media Queries, würde ich einfach einen Breakpoint setzen, ab dem die horizontalen Paddings einfach wegfallen bzw. so reduziert werden, dass die Kästen bis zum Rand gehen und genügen Platz für den Inhalt übrige bleibt (Mobile-First würde man das natürlich genau andersrum machen, aber die Desktop-Seite ist ja hier schon da). Dummerweise habe ich aber keine Media-Queries und nichtmal auf die Klassen-Unterschiede im Mobile-Rendering reagieren. Und class="nomobile" bringt mich im Bezug auf das Padding umgebender Container leider auch nicht weiter.

Ehrlich gesagt bin ich ziemlich ratlos. Die einzige funktionierende Möglichkeit, die mir aktuell einfallen würde, wäre ein entsprechende CSS global in die MediaWiki:Common.css schreiben zu lassen. Aber das kann es ja auch nicht sein, oder? Habt Ihr vielleicht irgendeine Idee? // Martin K. (Diskussion) 15:55, 3. Sep. 2016 (CEST)

Es wird sich wohl niemand darauf einlassen, für genau eine einzige von zehn Mllionen aktiven Seiten ein eigenes CSS in jede erdenkliche aufrufbare Seite zu injizieren.

Aaaalso: Erst ein steilisches neus Konzept basierend auf mobil in Testumgebung entwickeln, und das dann für alle Umgebungen produktiv stellen.

Padding ist sowieso Platzverschwendung. Aber wenn man vorher schon weiß, dass man mit einer simplen, bewusst reduzierten Wiki-Sprache arbeitet, dann kann man ja für den Desktop auch breite Padding-Streifen horizontal wie vertikal durch Tabellenstreifen dynamisch generieren, die width und class für nomobile kombinieren. Der Desktop funktioniert allerdings auch ohne petting.

Pfiffig eingesetztes float flutscht übrigens problemlos bei jeder Breite.

VG --PerfektesChaos 16:08, 3. Sep. 2016 (CEST)

Tabellen? Oje - das klingt nach HTML anno 1999 ;( // Martin K. (Diskussion) 16:44, 3. Sep. 2016 (CEST)

Das pfiffig "gesetzte float" der normalen Thumbnails sorgt übrigens dafür, dass der Text auf dem Smartphone in 2-Buchstaben-Zeilen zerfällt. Es ist echt ein Elend... // Martin K. (Diskussion) 17:54, 3. Sep. 2016 (CEST)

Ich hab das Padding jetzt mal in vw-Einheiten definiert. Das ist zwar nicht wirklich hübsch, verhindert auf dem Smartphone aber das Schlimmste.
Mittelfristig muss da aber wirklich eine Möglichkeit zur Einbindung von eigenem CSS herbei. So wie es jetzt ist, kann man im mobilen Zeitalter wirklich nicht mehr arbeiten. // Martin K. (Diskussion) 17:54, 3. Sep. 2016 (CEST)

Vorlagenparameter mit HTML-Tags wird ignoriert

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

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

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

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

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

• Das Ding enthält ein Gleichheitszeichen.
• Alles links vom ersten vorhandenen Gleichheitszeichen ist der Name des Parameters.
• Also hat dein Parameter den Namen:
  [[Burger Binnensee|<small style
• Somit ist es ratsam, vor die Zuweisung zu setzen:
  3=[[Burger Binnen

VG --PerfektesChaos 00:06, 22. Aug. 2016 (CEST)

Ah, ok das erklärt's. Gibt es in Wikitext eigentlich sowas wie eine Klammerung, die nichts weiter tut, als solche Effekte zu verhindern? // Martin K. (Diskussion) 00:09, 22. Aug. 2016 (CEST)

Nein, das kann man am besten umgehen in dem benannte Parameter verwendet werden. Hilfe:Vorlagen#Problem: Gleichheitszeichen in Parameterwerten. Der Umherirrende 17:11, 25. Aug. 2016 (CEST)

Und was ist mit dem | ? In der Vorlage:Dateiüberprüfung hab ich häufiger das Problem, dass er mir Links zerhackt, sobald ein | drin ist. // Martin K. (Diskussion) 17:24, 25. Aug. 2016 (CEST)

Hast du ein Beispiel? Komplette Wikilinks oder Vorlagensyntax werden nicht in der Mitte zerlegt, man kann sie in Vorlagen verwenden (Nicht nur im Parameter-Bereich). Ansonsten muss man es maskieren. Hilfe:Vorlagen#Senkrechter Strich. Der Umherirrende 20:44, 25. Aug. 2016 (CEST)

Automatisiert Links umbiegen per Javascript

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

Hallo Flominator, probier es doch mal mit bkl-check von Schnark. Es ist auch in seiner sehr nützlichen Skriptsammlung Fliegelflagel enthalten. Gruß --vy 73 de Ptolusque AFu • ☑ 23:58, 28. Aug. 2016 (CEST)

Danke für die Antwort. Jedoch ging es mir um etwas, das eine Liste von Lemmas bekommt, diese abklappert und darin Links ersetzt. --Flominator 08:41, 29. Aug. 2016 (CEST)

Verstehe, hatte „Skript zu haben, das Links auf eine BKL umbiegt“ nicht ganz verstanden. Viel Erfolg! Gruß --vy 73 de Ptolusque AFu • ☑ 09:04, 29. Aug. 2016 (CEST)

• Benutzer:AnotherFlominator/monobook.js kann nicht (mehr) funktionieren, weil darin FeedbackArea vorkommt.
  • FeedbackArea wird definiert in Benutzer:D/monobook/user.js – dieses muss erst vollständig geladen worden sein, bevor die BKL-Umbiegfunktion angefasst werden kann.
• Beide Seiten sind interessant für Software-Archäologen und atmen den Geist des letzten Jahrhunderts.
  • Insbesondere als es nur ganz wenig Skripte gab und man nach Belieben irgendwie die Namen von Variablen nutzen konnte, ohne befürchten zu müssen, dass jemand anders einen Namen wie initialize oder Communication oder Special verwenden könnte, und man jemand anders das Skript zerschießen würde oder von einem anderen Skript die eigenen Variablen geplättet würden.
  • Hier ist katastrophal, dass davon ausgegangen wird, dass im Browser immer nur ein Skript nach dem anderen ausgeführt wird, und immer erstmal die letzte Ladeanweisung bis zum Ende, bevor in die zuvor noch laufende zurückgesprungen würde.
  • Moderne Browser führen aber viele Skripte gleichzeitig aus und versuchen möglichst viele schon mal herunterzuladen und den Code bereitzustellen. Früher hatte der Browser eine Pause mit dem Seitenaufbau eingelegt und abgewartet, bis das nächste angeforderte Skript bereitgestellt wurde und ausgeführt werden konnte. Heutzutage wird diese Wartezeit aber genutzt, um inzwischen andere schon ausführbare Aufgaben anzugehen. Bei den Hunderten von Skripten, die teilweise in eine Wiki-Seite fließen, würde der Aufbau jeder Seite sonst mehrere Minuten dauern.
• Heißt: Kompletter Neubau; ohne die von D zusammenkopierte Skriptbibliothek.
• Nebenbei gibt es bei Benutzer:AnotherFlominator/monobook.js einen Fehler beim Laden der CSS-Ressource; hier ist ein falscher MIME-Typ angegeben.

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

Mit Benutzer:DerHexer/fixlinks.js müsste das gehen, denke ich. Gruß --Schniggendiller Diskussion 22:40, 29. Aug. 2016 (CEST)

Nicht ganz so, wie ich mir das vorgestellt habe, aber vielleicht sogar cooler. Das könnte auch Benutzer:Informationswiedergutmachung gefallen. Danke, --Flominator 09:46, 30. Aug. 2016 (CEST)

@Flominator: Wie könnte mir das helfen? Wenn ich ein Lemma Vorname Familienname auf ein Klammerlemma verschiebe, muss ich alle Links persönlich durchgucken, damit ich nicht fehlverlinke. Das könnte mir nur helfen, wenn ich einen Artikel von Vorname Familienname (Klammerlemma alt) auf Vorname Familienname (Klammerlemma neu) verschiebe. Geht das mit diesem Skript? Und wie funktioniert es? MfG --Informationswiedergutmachung (Diskussion) 18:36, 30. Aug. 2016 (CEST)

@Informationswiedergutmachung: Du gehst auf "Links auf diese Seite", dann findest du im Werkzeugkasten (wo normalerweise der Contexter ist) "Fix Links". Es geht ein Popup auf, das dich nach dem Ziel fragt, auf das umgebogen werden soll. Dann gehen x neue Tabs auf, die jeweils eine lokal beschränkte Vorschau der Änderung zeigen. Wenn sie dir gefällt, kannst du die Änderung speichern. Wenn nicht, kannst du einen anderes Ziel eingeben und trotzdem speichern. Wirkt durchdacht auf mich. Gruß, --Flominator 20:05, 30. Aug. 2016 (CEST)

Wieviele Tabs? Und das kommt vom Hexer? Ich bin erstaunt, ich dachte immer, der kann nur labern. Klingt aber interessant, muss ich mal ausprobieren. :) --Informationswiedergutmachung (Diskussion) 20:08, 30. Aug. 2016 (CEST)

@Flominator: Kannst du mir das mal in meine cs einbinden? Oder wohin das auch immger gehört? MfG --Informationswiedergutmachung (Diskussion) 20:15, 30. Aug. 2016 (CEST)

Hey, ich labere erst seit fünf Jahren! xD —DerHexer (Disk., Bew.) 21:24, 30. Aug. 2016 (CEST)

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

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

So? --Informationswiedergutmachung (Diskussion) 20:41, 30. Aug. 2016 (CEST)

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

Hmm. Funzt nicht. --Informationswiedergutmachung (Diskussion) 20:52, 30. Aug. 2016 (CEST)

Bei dir steht: 'mw.loader.load('//de.wikipedia.org/wiki/Benutzer:DerHexer/fixlinks.js&action=raw&ctype=text/javascript'.

Es müsste aber heißen:mw.loader.load('//de.wikipedia.org/wiki/Benutzer:DerHexer/fixlinks.js&action=raw&ctype=text/javascript');

--FNDE (Diskussion) 20:54, 30. Aug. 2016 (CEST)

Immer noch nicht - trotz mehrfachen Cache-Leerens. --Informationswiedergutmachung (Diskussion) 21:01, 30. Aug. 2016 (CEST)

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

@FNDE: Jetzt funktioniert es. Danke. --Informationswiedergutmachung (Diskussion) 02:05, 31. Aug. 2016 (CEST)

@DerHexer: Ganz ordentlich. Aber verbesserungswürdig. Zeige ich dir auf der WikiCon, nicht vergessen, in Ordnung? Aber gleich zwei Bitten vorab. Erstens du hast die Obergrenze der sich zu öffnenden Tabs auf 10 gesetzt? Erhöhe doch mal bitte auf 20. Und zweitens: dein Skript sollte nur Seiten im ANR erfassen. Linkfixe in Archiven, auf Benutzer- und Portalseiten, generell auf Meta sind eh unüblich und unerwünscht. MfG --Informationswiedergutmachung (Diskussion) 02:05, 31. Aug. 2016 (CEST)

Hm, da ich eine Session aufmache und die bei mir auch bei 10 Tabs schon ab und an abläuft, sehe ich jetzt nicht das große Problem, hier zweimal heranzugehen. Vielleicht mach ich es auch einfach individuell. Zum Teil sind Linkfixe auch auf Metaseiten sinnvoll; hier kann man ja individuell abbrechen. Auf Diskussionsseiten wird nichts ersetzt, nur in den Namensräumen 0|4|6|10|12|14|100. Grüße, —DerHexer (Disk., Bew.) 02:11, 31. Aug. 2016 (CEST)

@DerHexer: Ich muß noch etwas üben. Für Verschiebungen von Klammerlemmata uf Klammerlemmata scheint es ordentlich zu sein, aber ansonsten habe ich noch Probleme. Mal schauen. Übrigens: Linkfixe auf Metaseiten sind nie sinnvoll. Glaub mir ausnahmsweise mal, ich habe mehr WikiPedia-Erfahrung als du. Liebe Grüße --Informationswiedergutmachung (Diskussion) 02:14, 31. Aug. 2016 (CEST)

Der war gut! —DerHexer (Disk., Bew.) 23:24, 1. Sep. 2016 (CEST)

@DerHexer: Also beim Verschub von Klammerlemma auf Klammerlemma funktioniert das Tool ordentlich, aber beim Verschub von klammerfreiem Lemma auf Klammerlemma gibt es noch Probleme: immer, wenn ich Artikel sehe, die nicht zum geklammerten Lemma passen, und ich auch nicht weiß, wer da nun gemeint ist, schließe ich die Fenster. Die werden aber beim nächsten Versuch Links zu fixen wieder geöffnet. Aber dem 11. Unbekannten geht nichts mehr. So eben beinahe geschehen nach dem Verschub von Richard Hunt auf Richard Hunt (Puppenspieler). Zum Glück gibt es da "nur" sechs Richard Hunts, die ich nicht zuordnen kann, siehe Spezial:Linkliste/Richard Hunt, auch nicht über die BKL. So muss ich diese Richard Hunts notgedrungen in den Artikeln als BKL stehen lassen. Zwar immer noch besser als komplett fehlverlinkt, aber nicht wirklich gut. MfG --Informationswiedergutmachung (Diskussion) 23:57, 3. Sep. 2016 (CEST)

Ja, das lässt sich aber ohne irgendeine Form von Speichersystem nicht wirklich lösen. Man könnte dann in den Fenstern, in denen du schließt, auf Person (Jahr/Tätigkeit/usw.) verlinken. Ich könnt aber wahrscheinlich ein starte ab Link x einbauen, würde dann aber ein zweites Bestätigungsfenster bedeuten, das man mit einer 0 standardmäßig ausfüllen könnte. Grüße, —DerHexer (Disk., Bew.) 00:03, 4. Sep. 2016 (CEST)

@DerHexer: Ich habe eben mal geguckt: Salem-Preis, mit einem Mathemathiker Richard Hunt. Über den Umweg Engwiki en:Salem Preis habe ich en:Richard Allen Hunt alös Preisträger gefunden. Jahr fällt da flach, und auch als Richard Hunt (Mathematiker) eher kontraproduktiv. Und das wird mir dann doch zuviel - das auf jeden einzelnen Namen abzuklopfen und am Ende eine Relevanz per Rotlink zu erzeugen, die am Ende bei uns nicht vorhanden ist. Bei dem habe ich das jetzt aber mal gemacht, der hat damit jetzt sogar drei Rotlinks, siehe Spezial:Linkliste/Richard Allen Hunt. Das Tool ist gut, aber das ist für den gehobenen Umlinkanspruch. :) MfG --Informationswiedergutmachung (Diskussion) 00:12, 4. Sep. 2016 (CEST)

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

1. [[Produzent]] mit Produzent => Musikproduzent sollte m.E. zu [[Musikproduzent|Produzent]] werden (bisher wird daraus einfach [[Musikproduzent]]). Ich kann zwar für das Ersetzungsziel auch Musikproduzent|Produzent angeben, aber dann liege ich bei [[Produzent|Producer]] oder [[Produzent|Produzentin]] auf der Nase. Schön wäre ein optionaler Parameter zum Maskieren der Links.
2. [[Münster (Westfalen)]] mit Münster => Münster (Westfalen) sollte m.E. nicht zu [[Münster (Westfalen) (Westfalen)]] werden. --Flominator 22:13, 6. Sep. 2016 (CEST)

Schau mer mal, muss ich ein paar Mal ausprobieren. MfG --Informationswiedergutmachung (Diskussion) 22:16, 6. Sep. 2016 (CEST)

Bug Nummer 1 ist mir bekannt, da hatte ich aber noch keine Zeit, das zu fixen. Bug Nummer 2 ist spannend, sollte eigentlich nicht passieren. Da sollt ich mich mal drängender dran machen. Danke für das wachsame Auge! Grüße, —DerHexer (Disk., Bew.) 23:15, 6. Sep. 2016 (CEST)

@DerHexer: Vielleicht willst du ja in der Summary zudem auf das Skript verlinken? --Flominator 13:32, 7. Sep. 2016 (CEST)

Doch, klar, würde natürlich passieren. Für den Umgang mit der Pipe müsste ich sämtliche reguläre Ausdrücke noch mal durchgehen, das dürfte etwas dauern. @Flominator, Informationswiedergutmachung: Ich hab aber den Link auf das Tool sowie eine Möglichkeit ergänzt, die ersten x Links zu überspringen. Grüße, —DerHexer (Disk., Bew.) 21:01, 8. Sep. 2016 (CEST)

Fehlerhafte Darstellung bei Transklusion von Seiten mit Spezial:Änderungen an verlinkten Seiten

Siehe auch: WP:VWS#Fehlerhafte Darstellung bei Transklusion von Seiten mit Spezial:Änderungen an verlinkten Seiten

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

Ist wohl ein Softwarebug. Hat nichts mit Vorlagen zu tun, die gleiche Spezialseite doppelt mit verschiedenen Parametern direkt einzubinden ergibt das gleiche merkwürdige Verhalten. Die ungesichteten Seiten können je nach Reihenfolge einzeln erscheinen, aber die anderen beiden sind immer gleich, egal in welcher Reihenfolge. --mfb (Diskussion) 19:20, 30. Aug. 2016 (CEST)

{{Spezial:Änderungen_an_verlinkten_Seiten|days=90|target=Portal:Amateurfunkdienst/Artikelliste|limit=6}}

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

{{Spezial:Änderungen an verlinkten Seiten|days=90|namespace=0|target=Portal:Amateurfunkdienst/Artikelliste|hideReviewed=1|limit=6}}

Ich habe mal mit gerrit:308144 einen Software-Änderungs-Vorschlag gemacht. Mal schauen, ob das so angenommen wird. Der Umherirrende 12:00, 2. Sep. 2016 (CEST)

@Umherirrender: Danke! Scheint ein globaler MediaWiki Bug zu sein. Nach gerrit:281174 ist der Bug auch bei anderen specialpages, die multipel inkludiert sind zutreffend. Gruß --vy 73 de Ptolusque AFu • ☑ 18:18, 2. Sep. 2016 (CEST)

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

Warnmeldung bei IP-Sperre

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

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

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

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

Hochkant

Hi, ich hätte einen Vorschlag: Könnte man nicht unter Eingebettete Datei und hier unter Format noch die Option hochkant einfügen?--Hubon (Diskussion) 21:46, 1. Okt. 2016 (CEST)

@Hubon: Was sind denn die notwendigen Schritte, damit man Eingebettete Datei angezeigt bekommt? --Malyacko (Diskussion) 13:31, 5. Okt. 2016 (CEST)

Danke. Ich meine einfach im Editor das 5. Ikon von links, um Bilder einzufügen. Dieses Ikon trägt eben die Bezeichnung Eingebettete Datei.--Hubon (Diskussion) 13:35, 5. Okt. 2016 (CEST)

Es geht um die erweiterte Bearbeitungsleiste in Kombination mit dem Assistenten zum Einfügen von Links.

Man könnte die Option dort aufnehmen. Es würde aber nicht unter "Ausrichtung" oder "Format" passen, sondern es braucht wohl eine neue Rubrik. Außerdem bietet hochkant die Möglichkeit eine Zahl anzugeben, das in so ein Formular zu bringen, braucht einen guten Einfall zur Platzierung/Gestaltung. Der Umherirrende 16:20, 6. Okt. 2016 (CEST)

Danke dir! Warum meinst du, Format passt nicht?--Hubon (Diskussion) 16:21, 6. Okt. 2016 (CEST)

Nach Hilfe:Bilder#Automatische Skalierung kann man hochkant nur mit miniatur und rahmenlos zusammen verwenden, nicht mit gerahmt. Man müsste dort also zwei Sachen auswählen können. Der Umherirrende 16:25, 6. Okt. 2016 (CEST)

Verstehe. Vielleicht hat ja dennoch jemand eine pfiffige Idee...?--Hubon (Diskussion) 15:17, 8. Okt. 2016 (CEST)

Eingabefeld

Wäre es aus eurer Sicht nicht sinnvoll und möglich, dass beim Drücken der Tastatur im Lesemodus automatisch die Eingabe im Suchfeld erfolgt?--Hubon (Diskussion) 14:13, 6. Okt. 2016 (CEST)

Es gibt ein Helferlein dazu: Einstellungen -> Helferlein -> Cursor-Platzierung auf der Hauptseite immer in der Suchbox. Die Tastatur ist für eine alternative Eingabemöglichkeit für die Maus. Wenn jetzt jeder Tastatur-Klick zur Suche geht, ist diese Eingabemöglichkeit nicht mehr gegeben. Daher gibt es die Funktion nicht standardmäßig. Der Umherirrende 16:06, 6. Okt. 2016 (CEST)

Ich habe das Helferlein aktiviert, aber der Cursor ist trotzdem nicht automatisch in der Suchbox (sobald ich die Tastatur bediene). Außerdem scheint sich das ja dem Namen nach nur auf die Hauptseite zu beziehen; ich hätte das aber gerne auf jeder Seite.--Hubon (Diskussion) 16:27, 6. Okt. 2016 (CEST)

Dann musst du selber aktiv werden, der JavaScript-Quelltext liegt unter MediaWiki:Gadget-Suchfokus-Hauptseite.js. Den Quelltext kopieren nach Special:MyPage/common.css und das if sowie die letzte } entfernen. Mehr Infos unter WP:JS. Wenn dir das zu kompliziert ist, vielleicht gibt es auch Browser-Add-Ons, die man installieren kann. Der Umherirrende 18:55, 17. Okt. 2016 (CEST)

Habe ich gemacht, aber es wurden Fehler angezeigt... Ich habe es trotzdem so gespeichert, aber offenbar funktioniert das nicht. Habe ich etwas falsch gemacht? Unabhängig davon: Das Problem scheint wohl generell eine Browser-Sache zu sein, richtig? Könnte man das hier nicht dennoch Browser-übergreifend möglichst einfach bzw. elegant lösen?--Hubon (Diskussion) 23:20, 19. Okt. 2016 (CEST)

@Hubon: Der Umherirrende hatte wohl einen kleinen Tippfehler, er meinte die Seite Special:MyPage/common.js. Für einen Laien können (derart kurze) Code-Änderungs-Beschreibungen wohl etwas uneindeutig sein. Falls es immer noch nicht funzt würde ich ( mw.config.get( 'skin' ) === 'cologneblue' ) in Klammern setzen (wohl für ältere Browser). ↔ User: Perhelion 02:10, 20. Okt. 2016 (CEST)

@Perhelion: Danke, aber wenn ich das entsprechend der Anweisung (das if sowie die letzte } entfernen) von Der Umherirrende auf die von dir besagte Unterseite kopiere, werden immer noch als Fehler gemeldet: „Missing ";" before statement“ sowie „Unmatched '{'“. ???--Hubon (Diskussion) 23:02, 23. Okt. 2016 (CEST)

@Hubon: Aja, wenn du nicht gerade Cologneblue als Skin verwendest sollte $("#searchInput").focus(); auch völlig ausreichen. MfG ↔ User: Perhelion 01:53, 24. Okt. 2016 (CEST)

@Perhelion: Super Tipp, vielen Dank – jetzt funzt es endlich! Aber könnte man das denn wirklich nicht – für alle – leichter haben (ohne Programmierkenntnisse)?--Hubon (Diskussion) 03:05, 24. Okt. 2016 (CEST)

PS: Ich sah gerade, dass nach Verwendung der Suchfunktion (Strg + F) und Schließen derselben der Cursor leider doch nicht wieder automatisch im Wiki-Suchfenster landet, wenn ich die Tastatur betätige – also wohl zu früh gefreut...--Hubon (Diskussion) 03:09, 24. Okt. 2016 (CEST)

@Hubon: Das wird aber anders (vermutlich) nicht gehen, da die Browser-eigene Suchfunktion den Fokus natürlich löscht. Eine JS-Event für das Schließen dieses Fensterchen ist mir nicht bekannt. Du kannst auch einfach Shift + Alt + F für die Wiki-eigene Suche benutzen. Übrigens kann man den focus auch default (also Wikimedia native) per HTML setzen.

Der offene Wikimedia Phabtask dafür ist: phab:T3864 (ich kommentiere mal dort auf English). MfG ↔ User: Perhelion 19:45, 24. Okt. 2016 (CEST)

Sorry, aber da komme ich leider nicht mehr mit...--Hubon (Diskussion) 20:55, 24. Okt. 2016 (CEST)

Theoretisch könnte man über window.innerHeight erraten, wann das Browsersuchfeld offen ist, und ansonsten den Fokus immer wieder auf das Wikisuchfeld setzen. Da müsste aber @Hubon die für seine Browser- und GUI-Konfiguration passenden Werte selbst ermitteln, was ich ihm gerade nicht wirklich zutraue. Oder vielleicht das OP wörtlich nehmen, und den Focus mit einem Eventhandler "Keypress überall" setzen? Viel Spass mit den möglichen Nebeneffekten in beiden Fällen :-) Oh, und um die Frage aus dem OP zu beantworten: Nein, aus meiner Sicht ganz deutlich nicht sinnvoll. --nenntmichruhigip (Diskussion) 09:09, 25. Okt. 2016 (CEST)

@nenntmichruhigip: Danke, aber warum nicht? Eine Begründung wäre schön...--Hubon (Diskussion) 22:41, 28. Okt. 2016 (CEST)

Wurde hier ja eigentlich schon von mehreren geschrieben: Weil man dann nicht wirklich was anderes mit der Tastatur machen könnte. Aber wenn du meinst, dass das für dich in Ordnung sei: Nur zu. Ich vermute aber, dass du damit irgendwann (ich hab's eben ausprobiert und war schon nach weniger als zehn Sekunden soweit, es wieder entfernen zu müssen) auf Probleme stossen wirst, mit denen du das lieber nicht mehr haben willst. Und hier wird eher niemand die Zeit haben, dein Script immer wieder anzupassen, wenn du doch mal irgendwo anders die Tastatur nutzen willst. Falls es anders wäre hätte sich wohl schon jemand die fünf Minuten genommen, um dir die Lösung für deine ursprüngliche Anfrage als kopierfertigen Code zu nennen. Nachträglich anpingen funktioniert übrigens nicht, es braucht einen neuen Beitrag samt passender Signatur. --nenntmichruhigip (Diskussion) 17:30, 7. Nov. 2016 (CET)

Autovervollständigung von Links

Zur Funktion Link einfügen: Wäre es aus eurer Sicht nicht sinnvoll und möglich, dass bei der automatischen Vervollständigung auch Abschnittslinks angezeigt werden? Dies könnte uns allen eine Menge Arbeit ersparen... Kollegiale Grüße--Hubon (Diskussion) 14:16, 6. Okt. 2016 (CEST)

Ob es sinnvoll ist, kann ich nicht sagen, aber aktuell sind diese Infos über eine Seite nicht zum auswerten verfügbar, daher wäre dies nicht so einfach umzusetzen (was aber kein Ausschluss ist). Verlinkungen auf Abschnitte (im Artikelnamensraum) sind vermutlich nur in wenigen Fällen hilfreich, was den Aufwand vielleicht nicht rechtfertigt. Der Umherirrende 16:08, 6. Okt. 2016 (CEST)

Vielen Dank. Gibt es weitere Meinungen?--Hubon (Diskussion) 23:03, 23. Okt. 2016 (CEST)

Zeitstempel und Vorschaufunktion

Ich weiß nicht, ob das Problem hier schon mal diskutiert wurde bzw. ob es sich um ein Problem bei mir handelt, ich schilder es hier einfach mal: Wenn ich mit --~~~~ signiere und auf „Änderungen speichern“ klicke, wird immer die aktuelle Zeit in der Signatur angezeigt. So weit nichts Neues. Wenn ich aber --~~~~ in das Feld eingebe, zuerst die Vorschaufunktion benutze und dann erst abspeichere, erscheint in der Signatur schließlich die selbe Zeitangabe, die mir auch in der Vorschaufunktion angezeigt wurde, nicht die Zeit zum Zeitpunkt des Abspeicherns. Ich meine, früher wäre das nicht so gewesen. Gibt es da ein Problem mit meinem Cache oder ist das ein wikipediaseitiges Problem? --Singsangsung ^{Los, frag mich!} 14:42, 8. Okt. 2016 (CEST)

Das hat mit dem Cache nichts zu tun. Gruß -- FriedhelmW (Diskussion) 14:49, 8. Okt. 2016 (CEST)

Die Beobachtung könnte, was die Sekunden angeht, durchaus stimmen.

Seit einigen Monaten betreiben wir ein “preemptive save”. Ich versuche mal, das grobe Prinzip zu erklären:

• Mit der Vorschau schickst du den Quelltext an den Server; der kennt den also.
• Wenn du nun nichts mehr veränderst, und auf [Speichern] klickst, dann wird nicht dein 100 kB großer Quelltext erneut an den Server geschickt, wie das immer schon gewesen war, sondern der schon auf dem Server vorhandene Quelltext wird gespeichert, und die Nachricht ist nur mini ErHatSpeichernGeklickt.

Es mag nun sein, dass dabei der Zeitstempel der Vorschau für ~~~~ verwendet wird, statt der von ErHatSpeichernGeklickt.

• Das würde ich für einen Bug halten; sogar meldepflichtig.

Müsste mal wer genauer erforschen; Vorschau, Kaffee trinken, dann Speichern.

LG --PerfektesChaos 15:12, 8. Okt. 2016 (CEST)

Sowas wie in deinem letzten Satz mache ich gelegentlich, deshalb habe ich mal durch meine Diskussionsbeiträge der letzten Tage geschaut: Fast alles unterhalb von 20 Sekunden (davon ausgehend, dass ich laut Signatur bei 59 Sekunden gespeichert hätte, was bei mir dann aber erstaunlich oft vorkommen würde), bis auf einmal 39 Sekunden und einmal 82(!) Sekunden. Wenn's mehr wäre würde ich das ausserdem als Datenschutzproblem einstufen, die 82 Sekunden finde ich schon grenzwertig. --nenntmichruhigip (Diskussion) 15:31, 8. Okt. 2016 (CEST)

Es gab immer schon Zeitdifferenzen zwischen dem Moment, in dem hier auf Abspeichern gedrückt wurde, und dem Moment, wo der gesamte neue Text fertig durchs Netz übertragen wurde, und der Server seine Warteschlange abgearbeitet und die Änderung in die Datenbank geschrieben und in dem Moment das ~~~~ aufgelöst hatte.

Sekundengenau registriert wurde der Klick auf Speicher somit noch nie, und wenn die eine Grenze von einer Minute eingebaut hätten, oder zwei, wäre das okay. Fünf Minuten wären schon seltsam.

VG --PerfektesChaos 15:39, 8. Okt. 2016 (CEST)

Zur Illustration, wo es mir zum ersten Mal richtig aufgefallen ist: klick. Da handelt es sich um eine Zeitdifferenz von gut 5 Minuten. --Singsangsung ^{Los, frag mich!} 15:48, 8. Okt. 2016 (CEST)

Test. --Singsangsung ^{Los, frag mich!} 16:15, 8. Okt. 2016 (CEST) (Hier stand im Vorschaufenster 15:59, es gibt also eine Grenze. --Singsangsung ^{Los, frag mich!} 16:17, 8. Okt. 2016 (CEST) )
Test. --Singsangsung ^{Los, frag mich!} 16:25, 8. Okt. 2016 (CEST) (Hier stand 16:17 im Vorschaufenster. Also wohl doch eher eine 5-Minuten-Grenze. --Singsangsung ^{Los, frag mich!} 16:25, 8. Okt. 2016 (CEST) )

Die Grenze liegt (aktuell) bei 5 Minuten (300 Sekunden). Ich meine es gibt auch ein phab das Signaturen/Diskussionen ausgenommen werden sollen, finde den nur nicht. Der Umherirrende 18:52, 17. Okt. 2016 (CEST)

The Wikimedia Developer Summit wants you

The Wikimedia Developer Summit is the annual meeting to push the evolution of MediaWiki and other technologies supporting the Wikimedia movement. The next edition will be held in San Francisco on January 9–11, 2017.

We welcome all Wikimedia technical contributors, third party developers, and users of MediaWiki and the Wikimedia APIs. We specifically want to increase the participation of volunteer developers and other contributors dealing with extensions, apps, tools, bots, gadgets, and templates.

Important deadlines:

• Monday, October 24: last day to request travel sponsorship. Applying takes less than five minutes.
• Monday, October 31: last day to propose an activity. Bring the topics you care about!

More information: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit

Subscribe to weekly updates: https://www.mediawiki.org/wiki/Topic:Td5wfd70vptn8eu4

MKramer (WMF) (talk) 21:07, 14. Okt. 2016 (CEST)

insource:/\)\|\]\]/

Gemeldet in Phabricator
Task T4700

Als Beispiel: [[Donald Mackay]] wird mit [[Donald Mackay (Chemiker)|]] ersetzt. Das [[Donald Mackay (Chemiker)|]] wird beim Speichern normalerweise zu [[Donald Mackay (Chemiker)|Donald Mackay]]. Funktioniert aber nicht in Referenzen, siehe Spezial:Diff/157864615. Kann man diesen Bug mal fixen? --Informationswiedergutmachung (Diskussion) 15:08, 17. Okt. 2016 (CEST)

Bereits lange bekannter Bug, siehe phab:T4700 und gerrit:272916. -- hgzh 15:13, 17. Okt. 2016 (CEST)

(BK)

Das ist schon seit einem Dutzend Jahren so; oder seit es die jeweiligen Extensions gibt.

Siehe H:L#Pipe-Trick

Grund: In einer Extension erfolgt kein Reparsing des Wikitextes mehr, und der Pipe-Trick war schon vorher dran gewesen.

Abhilfe: Vorschau benutzen, oder wenigstens nach dem Speichern noch mal drübergucken; so auch Spezial:Diff/155228444 Spezial:Diff/155727135 Spezial:Diff/157814009 Spezial:Diff/158200970 Spezial:Diff/158493844.

@Flominator: FYI qed

VG --PerfektesChaos 15:18, 17. Okt. 2016 (CEST)

Das weiß ich mittlerweile selber. Aber diese Arbeitserleichterung war vor einiger Zeit sogar mal Tipp des Tages. Man sollte den Bug mal langsam abstellen - es wird mehr werden und die wenigstens der Fehler sind von mir. Übrigens: nettes Nerd-Kauderwelsch: In einer Extension erfolgt kein Reparsing des Wikitextes mehr, und der Pipe-Trick war schon vorher dran gewesen. :) --Informationswiedergutmachung (Diskussion) 15:30, 17. Okt. 2016 (CEST)

Ach ja: 64 Subscribers seit 2005 und nüschts geht? Wem muss man das Hinterteil denn nun abknutschen, dass dieser Uraltbug mal bearbeitet wird? --Informationswiedergutmachung (Diskussion) 15:32, 17. Okt. 2016 (CEST)

1. Ich kann nichts dafür, dass jemand solch brisantes Zeugs auch noch zum Tdt macht.
2. Mir wäre es lieber, dass auch auf der Hilfeseite nicht für sowas Reklame gemacht werden würde.
3. Bei den Extensions wird der Inhalt zwischen den H:Tags herausgeschnitten, von dieser intern verarbeitet und das Resultat hinterher in die ansonsten fertige Wiki-Seite einkopiert. Alles, was ansonsten noch auf der Seite passiert, bekommt eine Extension grundsätzlich nicht mit, so auch nicht diesen gefährlichen Trick. Aussicht darauf, dass sich hieran etwas ändert, gibt es wenig, weil der Pipe-Trick zum Kern gehört und die Extension eben gerade außerhalb des Kerns liegt und ihr eigenes Ding macht. Die Architektur der Seitenaufbereitung wird zwar in diesen Jahren grundlegend umprogrammiert, aber das betrifft nur den Kern.

VG --PerfektesChaos 15:39, 17. Okt. 2016 (CEST)

Muß man als Technik-Nerd, der ich bin, irgendwie nicht verstehen. Ich verstehe es auch nicht wirklich, aber das man sowas 11 (!) Jahre nicht in den Griff bekommt... Nun ja. Kein echtes Ruhmesblatt für die Wikipedia... --Informationswiedergutmachung (Diskussion) 15:46, 17. Okt. 2016 (CEST)

Eher für MediaWiki. Auch wenn man es schaffen würde diesen Bug zu fixen, würde das viele Seiteneffekte haben, die dann wieder als Bug aufgenommen werden sollen, obwohl es Features sind. Alle Tags (also alles mit spitzen Klammern was nicht HTML ist) wird identisch verarbeitet, aber bei pre oder nowiki will man vielleicht kein Pipe-Trick, da sie die Texte so darstellen sollen wie man sie übergeben hat. Man muss also Sachen die identisch behandelt werden, so trennen das es weiterhin das gewünschte Ergebnis liefert. Diesen Fix muss man dann noch ganz tief ins Herzstück der Wikitext-Verarbeitung platzieren. Da traut sich keiner der Freiwilligen dran und den bezahlten ist es vielleicht auch zu heikel. Der Umherirrende 18:49, 17. Okt. 2016 (CEST)

@Leyo: Zur Kenntnisnahme. MfG --Informationswiedergutmachung (Diskussion) 18:55, 17. Okt. 2016 (CEST)

Von den ursprünglich 70 Treffern sind nun bis auf 19 (zumeist in Kommentaren) alle gefixt. --Leyo 22:25, 17. Okt. 2016 (CEST)

Ich versuche mal noobverständlich zu formulieren, was das Problem ist, weil ich's bis eben auch noch nicht verstanden hatte und einen ganz offensichtlichen Vorschlag machen wollte: Wenn der Benutzer auf "Änderungen speichern" drückt wird der Artikelquelltext an den Server gesendet. Dort wird dann der Pipe-Trick (genauso wie {{subst:) schon aufgelöst, und erst danach die Seite gespeichert. Wenn die Seite danach aufgerufen wird, liest der Server die gespeicherte Seite und verarbeitet die ganze restliche Wikisyntax, also u.A. Vorlagen, solche Tags wie <ref>, <gallery> oder <math>, und die Links selbst. --nenntmichruhigip (Diskussion) 21:21, 17. Okt. 2016 (CEST)

Du hast schon ein Beispiel geliefert warum man nicht einfach subst und pipe-Trick vor dem Speichern auflösen kann. Nowiki würde nicht mehr funktionieren. Aus diesem Grund wird bereits vor dem Speichern (bzw. vor dem pst - pre-save-transform - "Vor-Speichern-Umwandlung") die Tags interpretiert und das führt zu diesem Ergebnis. Der Umherirrende 22:08, 17. Okt. 2016 (CEST)

Oh, stimmt, ich habe beim Schreiben ein paar Sätze vergessen :-) Ich versuche mal sie noch zu retten, wird jetzt evtl leider nicht ganz so noobfreundlich. --nenntmichruhigip (Diskussion) 22:22, 17. Okt. 2016 (CEST)

Die Inhalte der Mediawiki-Tags müssen bei der Transformation vor dem Speichern ignoriert werden, weil es bei deren Inhalt sehr wahrscheinlich ist, dass er anders interpretiert werden muss (z.B. <nowiki>, <math>). Wenn dann beim verarbeiten der restlichen Wikisyntax die Mediawiki-Erweiterung, die für die Verarbeitung dieser Tags zuständig ist, sagt "übersetze mir diesen Quellcode" wird er genauso verarbeitet wie der sonstige Quellcode nach dem Speichern. --nenntmichruhigip (Diskussion) 22:22, 17. Okt. 2016 (CEST)

Könnte man das Auflösen der |]] nicht vor dem Speichern clientseitig über Javascript lösen? --Flominator 13:18, 18. Okt. 2016 (CEST)

• Klar, einfach WSTM anklicken.
• Die Analyse ist allerdings hochkomplex, muss nowiki, syntaxhighlight und HTML-Kommentare sowie Vorlagensyntax berückschtigen. Mal so eben regexpen wird nix.

LG --PerfektesChaos 13:46, 18. Okt. 2016 (CEST)

Karte mit Lage des Ortes wird nicht richtig angezeigt

Hallo

Auf vielen Seiten wird die Karte mit der Lage des Ortes nicht korrekt angezeigt. Es erscheint nur ein roter Punkt. Klickt man die Karte an, erscheint die blanke Karte, der rote Punkt fehlt.

Beispiel: https://de.wikipedia.org/wiki/Lampenricht

Kann jemand den Fehler beheben?

Danke für die Hilfe.

Schöne Grüße! --A. Köppl (Diskussion) 10:56, 23. Okt. 2016 (CEST)

Mit welchen Browsern tritt der Fehler auf? Grüße -- FriedhelmW (Diskussion) 17:29, 23. Okt. 2016 (CEST)

Ich verwende Mozilla Firefox!

Schöne Grüße! --A. Köppl (Diskussion) 06:28, 24. Okt. 2016 (CEST)

Welche Version? Irgendwelche Addons oder relevante Änderungen an den Einstellungen? --nenntmichruhigip (Diskussion) 09:19, 24. Okt. 2016 (CEST)

Sehe gerade, dass das gestern abend in WP:FzW#Italien-Artikel von mehreren Benutzern gemeldet wurde. Damit haben sich meine obigen Fragen wahrscheinlich erübrigt. Interessierte sollten vielleicht eher dort weiterlesen. --nenntmichruhigip (Diskussion) 09:46, 24. Okt. 2016 (CEST)

Ich verwende Firefox, Verion 49.0.2, Schöne Grüße! --A. Köppl (Diskussion) 14:19, 24. Okt. 2016 (CEST)

@A. Köppl: Das ist by design. Die Positionskartenimplementierung arbeitet mit geobewussten Hintergrundkarten (kennen ihre Ränder im Koordinatensystem), der Punkt auf der Karte ist auch ein Bild und ein Overlay an der richtigen Position. Der Punkt selbst ist zum geohack und damit zu den Kartendiensten verlinkt, dort kannst du alle Karten ansehen (bis auf die ursprünglich unterlegte Positionskarte Vorlage:Smiley/Wartung/traurig ). Bei einem Klick auf die Karte (das Bild) bekommst du hingegen wie bei allen Bildern die Bildbeschreibungsseite der Karte (ohne Punkt). Ich denke da ist nicht viel zu machen. Das Verhalten ist browserunabhängig. lg --Herzi Pinki (Diskussion) 20:50, 7. Nov. 2016 (CET)

Danke für deine Mitteilung. Aber es funktioniert wieder alles! --A. Köppl (Diskussion) 21:18, 7. Nov. 2016 (CET)

Oh sorry, schlecht gelesen. Es hat vor ein paar Wochen (2-3, könnte also hinkommen) ein Problem mit dem Laden von Bildern gegeben, das sich wieder gegeben hat. Bildersuchergebnisse waren damals meist unvollständig, wechselnde leere Bilder. War gleichzeitig mit der großen DDoS-Attacke gegen einen DNS Provider in Amerika (21.10.). lg --Herzi Pinki (Diskussion) 21:28, 7. Nov. 2016 (CET)

Schriftgröße?

Wie kommt es, dass ich in unterschiedlichen Sprachversionen und WIKIs verschiedene Schriftformen und Größen angezeigt bekomme? Kann mir vielleicht jemand die optimalen Einstellungen für den FF (V 49.0.2) verraten, so dass ich eine Anzeige von ca. 12 pt hinbekomme? Ich habe eine Mindestgröße von 16 eingestellt, die Anzeige hat aber höchstens 10 pt? Nur in meiner (google)Mail bekomme ich 16 pt, die natürlich über die festgelegte Umgrenzungslinie hinausgehen und daher nicht angezeigt werden. In Opera ist die Darstellung noch besch . .eidener. Da sieht das Schriftbild in deWiki aus, als sei es in die Hosen gerutscht. D. h. die Buchstaben sind unten "dicker" als oben - ist sehr schlecht lesbar. In der noWiki ist die Darstellung aber wieder "normal", wenn auch zu klein. Ich mach mir die Augen kaputt ;=( J. K. H. Friedgé (Diskussion) 17:25, 23. Okt. 2016 (CEST)

Der Zoomfaktor beeinflusst die Schriftgröße. Mit Strg-Null stellst du 100% ein, mit Strg-Plus vergrößerst du Schrift und Bilder. Grüße -- FriedhelmW (Diskussion) 17:42, 23. Okt. 2016 (CEST)

Naja, das müsste ja dauernd und in jedem Tab neu abgefordert werden.

Wir verwenden die Original-Schrifteigenschaften von MediaWiki; es kann sein, dass andere Wikis daran gedreht haben.

Schau mal unter Hilfe:Skin; wenn du nicht „Vector“ eingestellt hast, wird es kleiner.

Wenn du Probleme mit den Augen hast, dann guck mal vorsichtig nach WP:CSS und kopiere danach in common.css die folgenden Zeilen, ggf. mit anderen Prozentzahlen:

body {
   font-size: 120%;
}

(OT: FriedhelmW: Guck doch mal nach WD:HW/VM)

LG --PerfektesChaos 17:56, 23. Okt. 2016 (CEST)

Zumindest Firefox merkt sich die Zoomeinstellung (die man mit Strg+Mausrad auch versehentlich mal verstellen kann) pro Domain, und man kann (mit browser.zoom.siteSpecific) einstellen, dass stattdessen die Einstellung überall gleich ist. Also @J. K. H. Friedgé: Versuch mal hier Strg+0 zu drücken, um die Zoomeinstellung zurückzusetzen, und versuche das in einem Wiki, wo dir die Schrift anders gross vorkommt.

Man kann in Firefox aber auch einstellen, dass kein Text kleiner als eine bestimmte Schriftgrösse dargestellt werden soll. Das lässt sich zwar theoretisch umgehen, aber ich behaupte einfach mal, dass das in keinem WMF-Wiki gemacht wird. Es wäre aber denkbar, dass eine Schriftart grösser wirkt als eine andere. Andererseits nutzen ja (fast?) alle WMF-Wikis dieselben Schriftarten. Da müsste @J. K. H. Friedgé mal ein paar Wikis nennen, bei denen ihm das unterschiedlich vorkommt, falls es nicht durch das oben beschriebene Zoomzurücksetzen behoben ist. --nenntmichruhigip (Diskussion) 09:18, 24. Okt. 2016 (CEST)

@PerfektesChaos@Nenntmichruhigip Auf die CSS bin ich auch schon gekommen. Diese jedoch verstellt nur das Verhältnis und hat auch keinen Einfluss auf die Schriftart? Übrigens wird es noch schlimmer, wenn ich in den FF-Einstellungen die Schriftgrößenübernahme aus anderen Programmen anhake. Ich würde Euch gerne Muster zeigen, aber diese nicht auf COMMONS laden. Was @FriedhelmW vorschlägt, ist wirklich zu umstandlich. Da müssen dann wohl doch die HTML-Spezialisten ran. Wenn man im Browser eine Schriftgröße festlegt, sollte das wenigstens als Mindestgröße übernommen werden. LG J. K. H. Friedgé (Diskussion) 22:40, 24. Okt. 2016 (CEST)

Das mit der Mindestgrösse passiert browserseitig, da kann wikipediaseitig nichts dafür oder dagegen gemacht werden. Frag mal auf WP:Auskunft (absichtlich nicht WP:FzW) mit einem Verweis auf diesen Abschnitt nach, ob die dir verständlicher erklären können, was hier geschrieben wurde. --nenntmichruhigip (Diskussion) 09:13, 25. Okt. 2016 (CEST)

Ich denke wir können abschließen. Der Effekt ist nicht zu erklären. J. K. H. Friedgé (Diskussion) 10:14, 26. Okt. 2016 (CEST) (erl.)

@J. K. H. Friedgé: Lass mich nochmal eine Verständnisfrage stellen:

• Geht es darum, dass Dein Browser Websites in anderen Schriften und Größen anzeigt, als das in anderen Browsern der Fall ist? Geht es also um einen Fehler, der gefunden werden müsste?
• Oder geht es darum, dass Du alle Websites unabhängig von den Vorgaben des jeweiligen Anbieters auf eine Mindestschriftgröße zwingen möchtest? Also um ein Feature? Und falls ja: warum?

Wenn Dir generell alles etwas zu klein ist, solltest Du die Größenanpassung Deines Betriebsystems konsultieren und ggf. etwas nach oben korrigieren-

Zum lokalen anpassen des Browser-CSS würde ich das Firefox-Addon Stylish empfehlen. Dort kannst Du einen neuen Style erstellen und so z.B. die Basis-Schrift auf die gewünschte Schriftart und Pixelgröße setzen. Da die rem-Einheiten vom html-Element ausgehen, sollte man dieses stylen und nicht nur den Body

html, body{
   font-size: 12px; /* Oder irgendeine andere Größe */
   font-family: Arial, sans-serif;
}

Das ist die harmlose Methode, die nur die Basis-Schriftgröße verändert und wieder vom Page-Style der jeweiligen Seite überschrieben werden kann. Wenn Du es gerne etwas brutaler hättest, kannst Du auch die Stile aller relevanten Elemente auf eine Größe zwingen. Das sähe dann so aus:

html, body, div, p, main, section, article{
   font-size: 12px!important;
   font-family: Arial, sans-serif!important;
}

// Martin K. (Diskussion) 10:55, 26. Okt. 2016 (CEST)

@Martin Kraft Hallo Martin, in meiner Frage ganz oben steht, dass unterschiedliche Projekte/Sprachversionen unterschiedlich dargestellt werden. Die Mindestgrößeneinstellung des Browsers wirkt nicht (überall), und die vorgegebene Schriftgröße wirkt in Wiki auf andere Elemente als in anderen (z.B. Google) Fenstern.

Da Du ja Fachmann bist (ich bin keiner, jedenfalls in HTML): ich denke, dass die HTML-Seitenbeschreibung unterschiedliche "Quellen" für die Schriftgröße nutzt. Es ist wohl übertrieben, für die Umschaltung in ein anderes Fenster die Größe zu ändern. Wenn es Dich nicht belästigt, schicke ich Dir ein paar Screenshots, um zu verdeutlichen was ich meine. L.G. J. K. H. Friedgé (Diskussion) 13:07, 27. Okt. 2016 (CEST)

@J. K. H. Friedgé: Da ich aus dem, was Du da schreibst nicht ganz schlau werde, wäre es wohl tatsächlich am besten, wenn Du mir mal ein paar ScreenShots zu kommen lässt. // Martin K. (Diskussion) 14:55, 27. Okt. 2016 (CEST)

Sonderzeichen

Hat jemand für dieses Problem "gefallen" eine Lösung?--Ekkehart Baals (Diskussion) 18:51, 23. Okt. 2016 (CEST)

Werkzeug zur Abfrage der prozentualen Bearbeitungen eines Artikels

Bisher habe ich dieses Werkzeug benutzt: wikihistory v. apper Aufruf- und Bearbeitungsstatistik. Funktioniert das noch oder gibt es eine Alternative? Dank im voraus. --Anima (Diskussion) 10:45, 27. Okt. 2016 (CEST)

• Funktioniert wohl zumindest bei mir →Der Hobbit
• Alternativ gibt es noch ein Skript Benutzer:Schnark/js/artikel-statistik, welches die Textstellen im Artikel farblich zum jeweiligen Autor markiert.

Hilft dir das weiter? --Liebe Grüße, Lómelinde Diskussion 11:29, 27. Okt. 2016 (CEST)

Hallo Lómelinde, ja, sehr. Bei mir lässt sich nur ein einziger Artikel nicht nach apper auswerten. Und jetzt lerne ich ein weiteres Werkzeug kennen. Liebe Grüße von --Anima (Diskussion) 16:13, 27. Okt. 2016 (CEST)

Das freut mich, ich benutze nur das von Schnark, es dauert zwar manchmal etwas sehr lange, bis alle Versionen ausgewertet wurden, aber so kann man sehr gut sehen wer wann eine Änderung durchgeführt hat. --Liebe Grüße, Lómelinde Diskussion 16:19, 27. Okt. 2016 (CEST)

Bitte um Kommentare: Technical Collaboration Guideline

Hallo,

wir bitten um Rückmeldungen und Kommentare zu den Richtlinien für die Zusammenarbeit in technischen Bereichen ("Technical Collaboration Guideline", TCG).

Die TCG sind Empfehlungen zu bewährten Vorgehensweisen bei der Planung von Softwareprojekten und der Kommunikation mit den Wikimedia-Gemeinschaften (Communities). Das Ziel ist es eine bessere Zusammenarbeit zu ermöglichen. Bei der TCG handelt es sich um eine Anleitung deren Inhalt erlauben soll, dass Softwareprojektteams der Wikimedia Foundation (WMF) und die Wikimedia-Gemeinschaften gemeinschaftlich und systematisch zusammenarbeiten in der Phase der Produktentwicklung und der Phase des Bereitstellens von Software auf den Servern. Wir hoffen dass die TCG nützlich genug sein wird um beim Planen und Kommunizieren genutzt zu werden - für jedes Softwareprojekt, von jedem. Die TCG ist flexibel angelegt und bewusst nicht allumfassend, da sich Pläne und Produkte während der Entwicklung ändern können.

Der erste Entwurf der TCG wurde nach Diskussionen mit kleinen Gruppen von Mitgliedern der "Community Liaisons"- und Produkt-Management-Teams geschrieben, um sowohl Fehler als auch erfolgreiche Vorgehensweisen in der Kommunikation zu identifizieren, und was getan werden kann um die Zusammenarbeit zwischen Softwareentwicklungsteams und den Wikimedia-Gemeinschaften anzuregen und zu fördern. Während des nächsten Monats bitten wir Mitglieder der Wikimedia-Gemeinschaften um Rückmeldungen und Kommentare. Alle Kommentare werden gelesen. Die Kommentare werden berücksichtigt wenn am nächsten Entwurf der TCG gearbeitet wird. Die TCG und die Diskussionen zur TCG sind in englischer Sprache, aber Kommentaren in anderen Sprachen sind willkommen auf der Seite mw:Talk:Technical Collaboration Guideline.

In den nächsten Wochen wird zudem ein Review des Design-Team der WMF angekündigt werden. Das Team hat die letzten Monate daran gearbeitet den Zweck und Ziele von Design-bezogener Arbeit in der WMF zu beschreiben, und das Team freut sich darauf dies mit der Wikimedia-Bewegung zu teilen um Kommentare und Rückmeldungen zu erhalten. --AKlapper (WMF) (Diskussion) 13:01, 27. Okt. 2016 (CEST)

Teilbeobachtung

Lässt sich iwie einrichten, dass man beispielsweise in Diskussionen nur einen Abschnitt beobachten kann oder beispielsweise nur die Diskussionsseite eines Artikels? Theoretisch kann man das ja bei "Beobachtungsliste als Liste bearbeiten" im Quelltext schreiben, aber der Abschnitt oder das "Diskussion:" werden einfach missachtet. Es ist manchmal sehr nervig, wenn man auf einer vielbearbeiteten Diskussion eine Antwort erwartet, aber auf der Beo alle anderen Abschnitte landen. Beispiel: VM oder LKH. --Kenny McFly (Diskussion) 11:40, 30. Okt. 2016 (CET)

Für ersteres ist ein Tool in der Entwicklung, siehe Benutzer:FNDE/secWatch (mehr Lesestoff unter WP:Fragen zur Wikipedia/Archiv/2016/Woche 39#Edit-Limits für Bots.

Für letzteres gibt es Benutzer:Schnark/js/watchlist++.

Gruß --Schniggendiller Diskussion 11:51, 30. Okt. 2016 (CET)

Für selektives Ein- und Ausblenden, insbesondere nur der Vorderseite oder nur der Diskussionsseite, oder der Beiträge bestimmter Benutzer, oder alle außer bestimmter Benutzer, gibt es auch listPageOptions.

Allgemein: WP:HX #Beo

LG --PerfektesChaos 11:58, 30. Okt. 2016 (CET)

@DrTrigon: Warum tut eigentlich Benutzer:DrTrigonBot/Doku#Diskussions-Zusammenfassung nimmer? Damit konnte man wunderbar Abschnitte beobachten. --Flominator 20:14, 7. Nov. 2016 (CET)

@Kenny McFly: Um nur Diskussionsseiten zu beobachten, kannst du dir sowas anlegen und dann auf Änderungen an verlinkten Seiten klicken. --Flominator 20:14, 7. Nov. 2016 (CET)

Darstellung von Überschriften

Ich möchte einfach mal loswerden, dass ich die derzeitige Darstellung von Überschriften nicht optimal finde. Ab er zweiten Hierarchieebene (Ebene 3) wird fette Schrift verwendet, weshalb diese Überschriften im Schriftbild stärker hervortreten als die der ersten Ordnung (hier Ebene 2 genannt) - die werden zwar deutlich größer, aber in normal ausgezeichneter Schrift dargestellt. Auf Chrome unter Android ist es etwas besser - dort wird unter der "Ebene 2" mehr Platz gelassen - als zum Beispiel im aktuellen Firefox unter Windows 10. Bin ich der einzige, der so so sieht? Welches Gremium hier hat denn das eigentlich festgelegt? --Karsten Meyer-Konstanz (D) 15:38, 19. Nov. 2016 (CET)

1. Es ist so oder so ein internationales Design; festgelegt von der WMF.
2. Für dich persönlich kannst du es mittels WP:CSS nach Belieben umgestalten.
3. Aus deinen Darlegungen geht nicht hervor, ob mobil oder Desktop; und welche Skin. Die Gestaltung ist überall anders konfiguriert.
4. Ich glaube nicht, dass diese Werkstatt viel mehr für dich tun kann.

VG --PerfektesChaos 15:47, 19. Nov. 2016 (CET)

Danke für die schnelle Antwort PerfektesChaos.

1. Die WMF ist groß.  ;-)
2. Es geht mir darum, dass die, für die ich hier schreibe, das optimal sehen.
3. Mit "Chrome unter Android" meinte ich die mobile Ansicht, die klassische sieht weitgehend gleich aus wie beim Firefox unter Windows.
4. Das war zu befürchten.

Trotzdem Danke und ein schönes Wochenende --Karsten Meyer-Konstanz (D) 16:59, 19. Nov. 2016 (CET)

Anzeige von Änderungen

Es wäre schön, bei der Ansicht von Änderungen direkt aus einem Änderungsblock heraus an die entspr. Stelle des erzeugten Texts springen zu können - vor allem dann, wenn der Quelltext z.B. mir Referenzen durchsetzt und deshalb schwer zu erfassen ist. Klar - noch toller wär's, wenn man auch eine Referenz direkt anspringen könnte. Momentan nutze ich die Suchfunktion des Browsers dafür, aber das könnte wirklich bequemer gehen. Danke für Hinweise! --Karsten Meyer-Konstanz (D) 11:27, 20. Nov. 2016 (CET)

Einzelnachweise im Bild

Hallo zusammen, im IE 11 bei 1920x1200 Pixeln laufen in Stallegger Tanne die Nummern der Einzelnachweise ins Bild hinein, auch nach Abmeldung. Ist das Verhalten schon bekannt? Gruß, --Flominator 13:42, 25. Nov. 2016 (CET)

Geschütztes Leerzeichen

Auf Wikipedia:Typografie#Leerzeichen steht, man solle   verwenden, wenn man etwa „z. B.“ trennen möchte. Trifft dies noch auf die aktuelle "Wiki-Version" zu? Oder reicht da inzwischen ein "normales" Leerzeichen?   stört so manchen Quelltext-Autor ... Grüße --Brackenheim 18:38, 30. Nov. 2016 (CET)

Ein „normales“ Leerzeichen ist kein geschütztes Leerzeichen. Wenn die Wikitext-Editoren technisch in der Lage sind das geschützte Leerzeichen direkt als Unicodezeichen U+00A0 zu verarbeiten, dann wäre das die lesbarere Form für den Quelltext. --Fomafix (Diskussion) 19:29, 30. Nov. 2016 (CET)

Die Frage von Brackenheim ist nicht unberechtigt, denn mit dem Leerzeichen beim %-Zeichen wurde das ja bereits gemacht. Man müsste (einfach?) mal eine konkrete Anfrage bei Wikimedia machen. PS: Evtl. hat Fomafix sich etwas undeutlich ausgedrückt, denn die die "Wikitext-Editoren" können Unicode-Zeichen verarbeiten. ↔ User: Perhelion 19:50, 30. Nov. 2016 (CET)

1. In den letzten anderthalb Jahrzehten gab es auf diesem Feld keinerlei Bewegung.
   • Der angesprochene Text ist somit unverändert aktuell.
2. Die Angelegenheit Wikipedia:Typografie/Automatische Leerzeichen stagniert, und ich habe auch nicht den Eindruck, dass sich irgendjemand darum kümmern würde.
3. Alle in der Textdarstellung unsichtbar/unauffällig erscheinenden Zeichen müssen für die Bearbeiter im Quelltext und im VE sichtbar und unterscheidbar sein.
   • Die Bearbeiter müssen erkennen können, an welchen Stellen welche Zeichen vorhanden sind, und welche Auswirkung sie hätten.
   • Aus diesem Grund scheiden auch U+00A0 aus; bzw. es wäre völlig egal, ob als UCS oder wie derzeit HTML-Entity – wenn es an irgendeiner Stelle ein Zeichen gibt, das kein normales ASCII-Leerzeichen oder ein nullbreites Zeichen ist, dann müssen alle Bearbeiter mit jeder Software-Umgebung und jedem Browser sehen können, welches Zeichen an welchen Stellen vorhanden ist, und ein U+00A0 müsste für alle Bearbeiter in jedem Browser in gleicher Weise erkennbar gemacht werden.
   • Die Zeichen mit verborgener Nebenwirkung werden ansonsten kreuz und quer durch den gesamten Text kopiert und lösen unvermutet rätselhafte, unbeabsichtigte und unerwünschte Nebenwirkungen aus. Und jeder Bearbeiter würde ansonsten bei jeder Bearbeitung erneut ein geschütztes Leerzeichen zwischen z. und B. setzen müssen, weil man ansonsten nicht sehen könnte, dass dort ja bereits vorher ein geschütztes Leerzeichen vorhanden war.
4. Solange also im Quelltext Zeichen mit besonderer Kodierung eingestreut werden, muss das also auch weiterhin mittels HTML-Entity sichtbar gemacht werden.
   • Nur wenn ohne zusätzliche Zeichen im Quelltext nachträglich in das generierte Dokument formatierungswirksame Elemente eingebracht werden, können die HTML-Entities entfallen.

VG --PerfektesChaos 20:24, 30. Nov. 2016 (CET)

Danke Euch für die schnellen Antworten! Verstehe ich es also richtig, dass man z. B. bei solchen Änderungen das geschütze Leerzeichen doch nicht braucht und ein "normales" ausreicht? Grüße Brackenheim 11:12, 1. Dez. 2016 (CET)

Noch ist es nötig ein geschütztes zu verwenden. Käme man mit dem Automatismus weiter, wäre es unnötig, so wie schon jetzt vor dem % --Diwas (Diskussion) 11:52, 1. Dez. 2016 (CET)

Danke ;-) Der Automatismus wird wohl noch einige Zeit dauern ... Gruß, --Brackenheim 12:24, 1. Dez. 2016 (CET)

Wer Interesse hat: Auf Wikipedia_Diskussion:Typografie#Anwendung_gesch.C3.BCtzter_Leerzeichen findet eine Diskussion statt, inwiefern es sich durchsetzen lässt, dass man auf de.wiki Leerzeichen einfügt bzw. einfügen darf. --Brackenheim 17:02, 2. Dez. 2016 (CET)

markAdmins.js

Moin! Da hier wohl das versammelte Wissen zu .js-Seiten zu finden ist, möchte ich meine Frage hier zur notwendigen Erweiterung des PDD-Skripts hinweisen (geht vielleicht schneller als auf WP:FZW). Viele Grüße, NNW 11:16, 1. Dez. 2016 (CET)

Hallo NNW, hier ist die neue Version. Wie wäre es wenn wir das effektivere System von hier übernehmen? РDD3 (Diskussion) 02:50, 2. Dez. 2016 (CET)

Grundsätzlich spricht von meiner Seite nichts dagegen. Es ist wohl eher eine Frage, wie das für dich wird. Als reines Gadget verlierst du die Kontrolle über deine Unterseite, was vermutlich hauptsächlich die hin und wieder anklingende Frage betrifft, ob man weiterhin die Ex-Leute angibt oder nicht (und auch welche, z.B. Ex-CU und Ex-OS). Da ich froh bin, die Ex-Angaben nicht zu lesen, sollte es zumindest abschaltbar sein, falls diese Angaben im Gadget erhalten bleiben sollen. Schick wäre dann auch hier ein Bot, der die Liste aktuell hält, es ginge aber auch ohne. NNW 11:08, 2. Dez. 2016 (CET)

@NordNordWest, РDD3. NNW – „ein Bot wäre schick“ – ich wollte die Frage sowieso schon in Commons stellen, aber vielleicht kann PDD mit seinen Skriptkenntnissen da helfen, denn der aktive Bot in Commons hängt da etwas zurück. Siehe jetzt c:Commons:Administrators' noticeboard#Mark new admins, unmark de-adminships. — Speravir (Disk.) – 18:21, 2. Dez. 2016 (CET)

@NordNordWest, Speravir: gut, ich würde das Primärziel auf Performance setzen, ein reines Gadget scheint, nachdem was ich gesehen habe, jedoch nicht zwingend. Hat jemand zufällig eine große Seite mit betreffenden Benutzer-Links als Test-Referenz? @Speravir: bzgl. deines Anliegens, im dortigen Commons-Skript sind die Stewards zwar konfiguriert aber nicht standardmäßig per enabled: true eingeschaltet. Gruß РDD3 (Diskussion) 01:18, 4. Dez. 2016 (CET)

Danke, РDD3. Ach, so simpel! Das hätte ich aber auch ohne große JS-Kenntnisse selbst erkennen sollen. — Speravir (Disk.) – 01:42, 4. Dez. 2016 (CET)

@NordNordWest: Nachdem ich ein paar Stunden Einarbeitung benötigt habe, habe ich das System von Rillke weitestgehend übernommen, tatsächlich sollte es jetzt doppelt so schnell sein (nachdem was ich gemessen habe, der Fehler lag darin die meisten Abfragen in der Hauptschleife zu machen anstatt einmalig davor, etc.). Alle User sind nun ebenfalls in einer separaten Datei. Ob man jetzt bei der Gelegenheit dies in den Gadget-Raum verschiebt ist mir egal. Die Mini-Gruppen habe ich allerdings entfernen müssen, es machte performance-technisch keinen Sinn, wenn jetzt nur 1-2 User statt mit einen Slash mit einem Bindestrich gekennzeichnet werden sollen, und dabei diese Abfrage bei jedem Link erfolgen soll, ist dies leider ein klarer Overkill (konkret sind es die Mini-Untergruppen SG-A und Omb-A, wobei dortige User-Konfiguration auch gar nicht mehr stimmte, s. Man77. Bzw. die "neue Rechtekombination" von Gnom, das zu programmieren ging leider schon in die Richtung Spaghetticode, noch eine Variable noch eine Ausnahme und nochmal bei allen anderen und hinterher sieht man nicht mehr durch). Die Reihenfolge der Gruppenzeichen kann mittels der markAdmins-data.js erfolgen. Wobei nun neben der Alten möglichen Konfiguration zwei neue Möglichkeiten bestehen das Script zu konfigurieren, und eine Vierte mittels mw.user.options.get('markAdminCfg') welche ich nicht ganz verstanden habe (daher erst mal auskommentiert), da Rillke auch leider nichts zur Anwendung dokumentiert hat (vermutlich etwas für die Zukunft mittels GUI-Konfiguration). VG РDD3 (Diskussion) 15:33, 7. Dez. 2016 (CET)

Ich bin offensichtlich zu blöd, auf das Skript zuzugreifen, und kann daher nichts dazu sagen. NNW 16:39, 7. Dez. 2016 (CET)

@NordNordWest: Meinst Du Benutzer:РDD3/markAdmins.js oder Benutzer:РDD3/markAdmins-data.js (beide oben versteckt verlinkt)? Warum eigentlich funktioniert Spezial:Präfixindex/Benutzer:PDD3 nicht? — Speravir (Disk.) – 20:32, 7. Dez. 2016 (CET)

@Speravir: Das ist tricky. Du hast es wohl manuell eingegeben. Spezial:Präfixindex/Benutzer:PDD3/ nichts, Spezial:Präfixindex/Benutzer:РDD3/ gibt's. Sieht bei mir überall identisch aus außer im Quelltext, wo das P größer ist als das D. Was sind das für Zeichen? Benutzer:PDD3 = "Das Benutzerkonto „PDD3“ ist nicht vorhanden." Sollte man besser anlegen als Weiterleitung, wenn das technisch überhaupt geht (wegen der Ähnlichkeit). --Bjarlin 13:35, 9. Dez. 2016 (CET) PS: Es ist ein kyrillisches Р.

@Bjarlin: Sieh mal ein wenig weiter unten, Suchwort „Schelm“. ;-) RРDD3 hatte einen versteckten Hinweis gegeben. — Speravir (Disk.) – 18:38, 9. Dez. 2016 (CET)

markAdmins.js. Ich ging davon aus, dass das Skript die data-Seite selbstständig abruft. Vielleicht ist das auch alles falsch gedacht, jedenfalls bekomme ich es nicht zum Laufen. NNW 10:16, 8. Dez. 2016 (CET)

@PDD: Kann sein, dass ich dich missverstehe, aber hast Du die letzten Änderungen am Commons-Skript bemerkt? Vgl. c:Special:Diff/141906851/225110806. — Speravir (Disk.) – 20:32, 7. Dez. 2016 (CET)

Hm, das ist natürlich schade. Ja, das habe ich schon bemerkt, ich habe dieses mal eingefügt, obwohl dies eigentlich wie gehabt auf der Diskussionsseite hinterlegt werden kann. Evtl. unterliegt ihr beide der selben Stolperfalle, dann könnte ich euch hiermit auf die Sprünge helfen. Gruß, РDD3 (Diskussion) 01:02, 8. Dez. 2016 (CET)

(Aha, dieses Mal wieder als РDD3.) Jetzt hast Du mich verloren. Ich hätte das auf Deiner Disk.-Seite melden sollen, obwohl es hier die ganze Zeit um das Skript geht? Welche Stolperfalle, wo sollte bei dir etwas UTF8-kodiert sein? So,so, du Schelm; dann eben Spezial:Präfixindex/Benutzer:РDD3. Bei mir funktioniert übrigens diese individuelle Konfiguration in Commons. (Da ich inhaltlich wohl nichts mehr beitragen kann, sollte ich mich vermutlich aber sowieso ausklinken.) — Speravir (Disk.) – 17:34, 8. Dez. 2016 (CET)

@РDD3: Doch noch was: Perhelion hat auf der Diskussionsseite des Skriptes in Commons etwas ergänzt, wo ich vor allem die Möglichkeit, das Label zu ändern, hilfreich finde (obwohl das in DE-Wiki meiner Meinung nach nicht notwendig ist), vgl. c:Special:Diff/225553172/225572361. — Speravir (Disk.) – 18:38, 9. Dez. 2016 (CET)

@NNW, Umherirrender, ich sehe keinen Grund warum es nicht funktionieren sollte. Könntest du bitte etwas genauer werden bzw. noch mal testen? Grüße PDD3 23:39, 8. Dez. 2016 (CET)

Ich habe markAdmins in der monobook.js deaktiviert und wollte per mw.loader.load die neue Seite aufrufen (wie andere Benutzerskripte auch). Ich fürchte, ich brauche eine Anleitung, was ich zu ändern habe, das sind für mich alles böhmische Dörfer. NNW 10:05, 9. Dez. 2016 (CET)

Ich sehe mich nicht in der Lage, das zu reviewen. Der Umherirrende 12:44, 9. Dez. 2016 (CET)

@NordNordWest, Umherirrender: Mit der weiter oben zu findenden Methode, das Skript als Bookmarklet zu starten, also mit javascript:void(importScript('Benutzer:%D0%A0DD3/markAdmins.js')); (nicht vergessen, das Gadget zu deaktivieren), funktioniert das Skript bestens auf Seiten wie dieser hier oder Wikipedia:Liste der Administratoren, nicht auf Benutzerseiten und deren Diskussionen. @РDD3: Kann es sein, dass folgende Zeile mit den deutschsprachigen Pendants ergänzt werden muss? (Übrigens zweiter Ping, hoffentlich übersiehst du den anderen oben nicht.)

runOn: ['Special', 'User', 'User_talk', 'Project', 'File', 'Help'],

Und vielleicht wäre eine Weiterleitung, wie von Bjarlin oben angeregt, wirklich sinnvoll. — Speravir (Disk.) – 18:38, 9. Dez. 2016 (CET)

Gut dann will ich "euch" mal nicht "blöd" sterben lassen, eigtl. gibt es gar keinen Grund für eine größere Diskussion hier. Ich verabschiede mich dann erstmal wieder, vielleicht packt ja einer das Geschenk nach Weihnachten noch aus.

@NNW wie ich gesehen habe hast du mehrere Anläufe unternommen, allerdings tatsächlich wohl sehr unglückliche, da bei jedem Versuch etwas anderes falsch (bzw. dann wieder richtig) war. Ich möchte aber nur auf den einen, den ersten eingehen (dein "deaktiviert" war leicht untertrieben, die Kommentare von Speravir haben dann wohl leider gut gemeint noch zur vollsten Verwirrung gesorgt). In der Tat komme ich ursprünglich aus der Nähe von Böhmen. Also (wie eigtl. bei jeder Programmiersprache müssen Variablen vorher deklariert werden, hier bei JS mit var) du hast leider im Glauben des Nichtsnutzen oder besser gesagt für optional gehaltene (nur die die mit mark beginnen) var's "entfernt" (warum auch immer, denn das neue Script interpretiert diese auch, bzw. gehörten zur Monobook), folglich kam es zu einem Fehler und Abbruch (im FF, z.B. Chrome ist hier fehlertolleranter), ab der Abfrage dieser var's, was glücklich jedoch verschleiernd erst am Ende deiner Monobook geschah (also genau da wo du das Script eingebunden hattest). Als weitere Hilfe kann ich dir das Stichwort Web-/Browser-Konsole nennen, dort tauchte der Fehler auch als: ReferenceError: mawatchlist is not defined

Wie gesagt sind das alles sehr rudimentäre Sachen (für JS) daher habe ich nicht mit solchen Schwierigkeiten gerechnet, bzw. nicht deinen Kenntnisstand geahnt. :-P Dann einen schönen Advent noch. Gruß PDD3 16:25, 10. Dez. 2016 (CET)

@Speravir, ist mir nicht entgangen. runOn: das sind die globalen Standardnamen, sog. canonical names. Eine Weiterleitung halte ich für unnötig bzw. noch mehr für Verwirrung stiftend (@Böhmische Dörfer: wie Jan Böhmermann auch gerne mal mit offensichtlich anderer Identität unterwegs, Hinweise gibt es ja noch mehr... die dir offenbar entgangen sind). PDD3 16:51, 10. Dez. 2016 (CET)

Mein Status in solchen Dingen ist DAU, man muss mir alles erklären. Ich versuche es später nochmal, vielleicht klappt es diesmal. NNW 19:02, 10. Dez. 2016 (CET)

NNW, dann nochmal ausführlicher, wie ich es gemacht habe: Ein neues Lesezeichen anlegen mit einem markanten Namen und dort, wo der Link eingetragen werden soll, stattdessen javascript:void(importScript('Benutzer:%D0%A0DD3/markAdmins.js')); einfügen; sowas wird dann Bookmarklet genannt (funktioniert wenigstens im Firefox). Das Gadget in den Helferlein vorübergehend deaktivieren. Eine Seite aufrufen oder neu laden, wo auf jeden Fall Admins und weitere Funktionen aufgeführt sind, wie eben Wikipedia:Liste der Administratoren und dann auf das Bookmarklet klicken. Letzteres muss auf jeder Seite wiederholt werden. — Speravir (Disk.) – 20:47, 10. Dez. 2016 (CET)

@РDD3: „Hinweise gibt es ja noch mehr... die dir offenbar entgangen sind“ Was auch immer du meinst, oder … Anscheinend ja. Aber ich bin ja hier wohl derjenige, der noch die wenigsten Probleme mit dem Skript hat. Dieses funktioniert übrigens nach deiner/n letzten Änderung/en einwandfrei! Von mir aus könnte das dann standardmäßig verwendet werden (ich würde Deine Ergänzung der Commons- und WD-Admins sogar gern nutzen). — Speravir (Disk.) – 20:47, 10. Dez. 2016 (CET)

Danke und sorry wegen der vermeintlichen Verkomplizierung. Ich wollte euch nur vor etwaigen Enttäuschungen warnen, allerdings ist das jetzt wohl auch egal. (Das mit dem Namen kann natürlich selbst für versierte User eine Stolperfalle sein.) Ein Bookmarklet funzt zwar ist jedoch nicht das Wahre zum Testen, Stichwort Web-Konsole (im FF Strg+Shift+K) einfach importJavascriptL('РDD3/markAdmins','de'); eingeben (die URI-Kodierung wie beim Bookmarklet funzt hier nicht, JS-Unicode-kodiert wäre importScript('Benutzer:\u0420DD3/markAdmins.js'), genauso wie Bookmarklets kein richtiges, sprich reines JS sind und daher auch nicht in der Konsole oder als automatischer Import im Benutzerscript funzen). Genauso gut kann man gleich den kompletten Code in die Konsole einfügen (ohne einen Script- oder Seitennamen). @Helferlein: da NNW es über die ursprüngliche Monobook eingebunden hat wird er hier wohl eh nichts aktiviert haben. @NNW: um es in deiner Mono zu testen am einfachsten den zuletzt genannten Code kopieren und den dann wie hier ersetzen (Stichwort UTF8 Stolperfalle). PDD3 00:09, 11. Dez. 2016 (CET)

Danke, jetzt hat's gefunzt. NNW 20:58, 12. Dez. 2016 (CET)

Nachtrag: Com-A und WD-A werden bei mir nicht angezeigt. NNW 10:39, 15. Dez. 2016 (CET)

Die Vorlage Revisionuser …

… zickt offenbar herum und ist extrem „launisch“. Das bedeutet, dass auf manchen Seiten, z.B. auf meiner Nutzerdisku, einige Besucher den Namen des letzten dortigen Autors sehen können, gleichzeitig andere Besucher hingegen nicht. Und es kommt sogar vor, dass derselbe Betrachter den Namen des letzten Autors innerhalb kurzer Zeit einmal sehen kann und danach wieder nicht (siehe etwas anschaulicher diese Diskussion). Mich erinnert das Ganze an einen elektrischen Wackelkontakt … Ich hoffe, ich bin mit dem Problem(chen) hier an der richtigen Stelle. Gruß von --Wwwurm 14:11, 6. Dez. 2016 (CET)

• An einer grundsätzlich richtigen Adresse bist du schon.
• {{REVISIONUSER}} ist keine Vorlage, sondern eine Parserfunktion gemäß Hilfe:Variablen #REVISIONUSER.
• Eigentlich zickt die nicht; es kommt halt drauf an, wer die wann wozu benutzt. Auf einer bereits existierenden Seite zeigt sie an, wer die zuletzt abgespeicherte Version zu verantworten hat, und das auch während der Bearbeiten-Vorschau (dann den momentanen Bearbeiter).
• toolserver.org/~daniel/WikiSense gibt es nicht mehr.
• <center> ist zwar veraltet, funktioniert aber und kann kein Hindernis sein.

Da wird allerlei HTML und blockweise und float und TOC ineinandergeschachtelt. Ich gehe eher davon aus, dass das je nach Browserfensterbreite, Layout und Browserversion sich irgendwie überdeckt und unter die Räder kommt. Ich habe jedenfalls die Layout-Struktur nicht verstanden.

VG --PerfektesChaos 14:26, 6. Dez. 2016 (CET)

Das tritt auch bei ganz simplen Testfällen auf, und lässt sich (zumindest in 1 von 1 Fällen) per Purge lösen. Hier mal zum Beobachten: Entlinkt. Bei Nichtfunktion ist die Variable leer. --nenntmichruhigip (Diskussion) 15:30, 6. Dez. 2016 (CET)

Umlaute in Formeln fehlerhaft

Kopiert aus der WP:RPQS#Umlaute in Formeln

SNIP

Es gibt Hinweise darauf, dass es Probleme mit Umlauten in der Darstellung von Formeln gibt.

${\text{für}}\,$

Bei mir funktioniert das. Kann jemand hier ein Problem bei der Darstellung feststellen? --Boehm (Diskussion) 14:12, 30. Nov. 2016 (CET)

Ja, das ü ist viel zu groß, geschätzt zu 50%. Kein Einstein (Diskussion) 18:14, 30. Nov. 2016 (CET)

Und zu einem anderen Zeichensatz gehört es nach meinem Eindruck auch. --der Saure 18:24, 30. Nov. 2016 (CET)

Definitiv ein anderer Zeichensatz, der da gerendert wird. Gerade vs. geschwungene Linien, eckige statt abgerundeter Serifen, andere Proportionen (Strich zu Zeichengröße, Seitenverhältnis).--Alturand (Diskussion) 18:35, 30. Nov. 2016 (CET)

OH! Jetzt sehe ich es auch: Ich musste mich dazu erst einmal abmelden. Was ist denn hier passiert? Bei 'mbox' tritt das gleiche Problem auf. --Boehm (Diskussion) 19:41, 30. Nov. 2016 (CET)

Stimmt, wobei es bei mir ehr geschätzte 30% sind. Ich glaube, ich habe das schon mal gelesen, habe aber nur phab:T2798 und phab:T130967 gefunden @Physikerwelt:--Debenben (Diskussion) 20:57, 4. Dez. 2016 (CET)

Also ich sehe da ein Bild (https://wikimedia.org/api/rest_v1/media/math/render/svg/2d52c948c4d163661f7ebf6ebda1812f4bcb0c82) vom Typ "SVG+XML":

 <?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns:xlink="http://www.w3.org/1999/xlink" width="3.448ex" height="3.343ex" style="vertical-align: -1.171ex;" viewBox="0 -934.9 1484.6 1439.2"  xmlns="http://www.w3.org/2000/svg">
<defs>
<path stroke-width="10" id="E1-MJMAIN-66" d="M273 0Q255 3 146 3Q43 3 34 0H26V46H42Q70 46 91 49Q99 52 103 60Q104 62 104 224V385H33V431H104V497L105 564L107 574Q126 639 171 668T266 704Q267 704 275 704T289 705Q330 702 351 679T372 627Q372 604 358 590T321 576T284 590T270 627Q270 647 288 667H284Q280 668 273 668Q245 668 223 647T189 592Q183 572 182 497V431H293V385H185V225Q185 63 186 61T189 57T194 54T199 51T206 49T213 48T222 47T231 47T241 46T251 46H282V0H273Z"></path>
<path stroke-width="10" id="E1-MJMAIN-72" d="M36 46H50Q89 46 97 60V68Q97 77 97 91T98 122T98 161T98 203Q98 234 98 269T98 328L97 351Q94 370 83 376T38 385H20V408Q20 431 22 431L32 432Q42 433 60 434T96 436Q112 437 131 438T160 441T171 442H174V373Q213 441 271 441H277Q322 441 343 419T364 373Q364 352 351 337T313 322Q288 322 276 338T263 372Q263 381 265 388T270 400T273 405Q271 407 250 401Q234 393 226 386Q179 341 179 207V154Q179 141 179 127T179 101T180 81T180 66V61Q181 59 183 57T188 54T193 51T200 49T207 48T216 47T225 47T235 46T245 46H276V0H267Q249 3 140 3Q37 3 28 0H20V46H36Z"></path>
</defs>
<g stroke="currentColor" fill="currentColor" stroke-width="0" transform="matrix(1 0 0 -1 0 0)">
<use xlink:href="#E1-MJMAIN-66"></use>
<g transform="translate(311,0)">
<text font-family="STIXGeneral,'Arial Unicode MS',serif" font-style="" font-weight="" stroke="none" style="font-family: monospace" transform="scale(71.759) matrix(1 0 0 -1 0 0)">ü</text>
</g>
<use xlink:href="#E1-MJMAIN-72" x="920" y="0"></use>
</g>
</svg>

Da scheint der Umlaut erst im Browser generiert zu werden mit Hinweis auf eine font-family, während die anderen Zeichen schon vom renderer in Kurven aufgelöst werden.--Alturand (Diskussion) 07:52, 5. Dez. 2016 (CET)

Ist das ein Punkt für die community wishlist 2017 (hoffentlicher Nachfolger von Meta: 2016 Community Wishlist Survey Meta) oder gar ein bug? Zumindest scheint mir das softwaretechnisch nicht optimal gelöst zu sein. --Blauer elephant (Diskussion) 11:05, 5. Dez. 2016 (CET)

Es ist mit Sicherheit ein Bug. <math>\text{für}</math> sollte so

https://upload.wikimedia.org/math/1/c/d/1cd86f5f9ca8d116a34a85a07023ca39.png

aussehen. Es sieht aber bei einigen so

https://wikimedia.org/api/rest_v1/media/math/render/svg/2d52c948c4d163661f7ebf6ebda1812f4bcb0c82

aus. Das kann nicht gewollt sein.

Alturand ist wohl auf der richtigen Färte. Es stimmt was mit den Fonts nicht.

Meine persönliche Behelfslösung ist, was ich schon seit langem aus verschiedenen anderen Gründen gemacht habe, png-only in den Voreinstellungen zu aktivieren.

--Boehm (Diskussion) 14:35, 5. Dez. 2016 (CET)

Hmm...da versteh ich den Präsentationslayer der Wikisoftware nicht gut genug, insbesondere welche Komponente oder welches Skript (server oder clientseitig) jetzt eigentlich entscheidet, ob der Link zum PNG oder zum SVG eingesetzt wird -spricht eigentlich überhautp irgendwas für das SVG?. Dass im SVG der Text bereits in Kurven aufgelöst wird, erscheint mir jedenfalls sinnvoll - dass da drin einzelne Zeichen erst vom SVG-Browser durch eine auf dem Client installierte Font gezeichnet werden, ist mindestens inkonsistent.--Alturand (Diskussion) 23:16, 5. Dez. 2016 (CET)

oops, noch ein Nachtrag: "(empfohlen für moderne Browser und Barrierefreiheitswerkzeuge)" kommt mir aber auch wieder komisch vor, wenn im SVG dann der Text als Kurven vorliegt. Liest mir dann der Browser: "..Emm dreiundsechzig sechsundvierzig haa fünfzig Kuh neunundachtzig.." statt "eff ühh err" vor? "Für" wäre irgendwie barrierefreier!--Alturand (Diskussion) 23:20, 5. Dez. 2016 (CET)

Das wären also 3 Probleme:

1. das SVG mischt im gleichen Wort/Text Elemente die serverseitig gerendert wurden mit solchen die clientseitig gerendert werden, was nur dann gut funktioniert, wenn der Client dieselben Fonts verwendet wie der Server. Die PNGs sind ok.
2. die MathML Einstellung liefert manchmal das SVG und manchmal das PNG aus
3. MathML ist für Barrierefreiheit empfohlen, produziert aber nichts barrierefreies.--Alturand (Diskussion) 22:33, 6. Dez. 2016 (CET)

Anmerkung zu 2: Ich habe bei mir png-Darstellung bevorzugt eingestellt. Daher bekomme ich ein png-Bild der Formel dargestellt. Es ist also kein Zufall wann was dargestellt wird, sondern hängt von den Voreinstellungen ab. Unglücklicherweise bekommen unangemeldete Benutzer die kaputten Formeln zu sehen.

--Boehm (Diskussion) 11:28, 7. Dez. 2016 (CET)

Zumindest bei Dir ist es kein Zufall - ich wähle "MathML mit SVG oder PNG" aus - und bekomme SVG.--Alturand (Diskussion) 11:32, 7. Dez. 2016 (CET)

Der vorgeschlagene Workaround, PNG zu verwenden, sah lange Zeit vielversprechend aus, hat allerdings das Problem, dass einige (neuere) Ausdrücke in LaTex wie z. B. \ooint vom PNG Renderer nicht verarbeitet werden (s. Diskussion:Elektrische Ladung, Spezial:Diff/161310127/161310651) --Alturand (Diskussion) 12:18, 7. Jan. 2017 (CET)

Danke Alturand für den Hinweis. Im Endeffekt zeigt sich, dass das Rendern von mathematischen Formeln noch immer nicht ausgereift ist und es letztendlich viele Baustellen gibt. Schade, dass dem Ausbau einer konsistenten Latex- bzw. Render-Umgebung so wenig Priorität zugestanden wird. --Boehm (Diskussion) 18:07, 20. Jan. 2017 (CET)

Fehler in der "Übersichtszeile"

Hallo liebe Leute, ich habe einen Fehler bei der "Übersichtszeile" gefunden. Und zwar ist es ja jetzt neu, dass bei der mobilen Version der Wikipedia hier nun eine Kurzbeschreibung aus Wikidata angezeigt wird, z. B. "Deutsche Politikerin, Bundeskanzerin". Bei Weiterleitungen in fremdsprachige Wikis führt dies zu Fehlern. So ist Allwissende Müllhalde mit en:List of Fraggle Rock characters#Marjory the Trash Heap verknüpft. Dies führt dazu, dass zur Ermittlung der Übersichtszeile das Wikidata-Objekt wikidata:Q2649509 gelesen wird. Das hingegen führt dazu, dass Allwissende Müllhalde als "Wikimedia-Liste" bezeichnet wird, statt korrekt als "Fiktionaler Charakter". Könnt ihr das mal überprüfen? Danke sehr. --Stoffdelphin (Diskussion) 23:14, 6. Dez. 2016 (CET)

Habe die Verbindung getrennt. Grüße -- FriedhelmW (Diskussion) 17:14, 7. Dez. 2016 (CET)

Danke sehr. Ich hoffe mal, dass das ein Einzelfall ist. Ich will nämlich keine Symptome bekämpfen, sondern das Problem an der Wurzel lösen. Auffällig finde ich auch, dass in der Type-Ahead-Suche bei Wikidata bei der Eingabe von "List of" direkt mehrere komische Ergebnisse anzeigt. "List of neighborhoods of Curitiba" zeigt auf wikidata:Q4361 (Curitiba), "List of settlements in Svalbard" auf wikidata:Q25231 (Spitzbergen) usw. usf. Da scheint sich ein riesiger Schiefstand an unbeabsichtigter Synekdochen aufzubauen. --Stoffdelphin (Diskussion) 23:30, 7. Dez. 2016 (CET)

Interaktive Karten auf Wikipedia

Screenshot einer eingebettet interaktiven Karte.

Hallo,

Das „interaktive“ Team der Wikimedia Foundation möchte die <mapframe> Funktion für interaktive Karten zu diesem Projekt aktivieren.

Diese neue Funktion ermöglicht es den Editoren, interaktive Karten in jede Wiki-Seite einzubetten. Diese Funktion ähnelt der <maplink> Funktion; aber anstelle eines Links zu einer Karte, die in einem Fenster geöffnet wird, sehen Sie ein schön formatiertes Bild der Kartendarstellung. Dieses Bild kann durch Klicken mit ihm interagiert werden.

Videos, die diese Funktionen demonstrieren, können auf Commons gefunden werden. [11] [12]

Die <mapframe> in Vorlagen und andere mehr technische Implementierungen. Die <mapframe> Funktion kann mit anderen Projekten (wie der Sandkasten auf Mediawiki.org) experimentiert werden, um die Funktion zu erleben und Reaktionen zu geben.

Wir möchten diese Funktion von Anfang bis Mitte Januar aktivieren, wenn wir die Unterstützung der Community hier haben. Bitte informieren Sie uns über irgendwelche Gedanken oder Interessen.

Vielen Dank für deine Zeit. CKoerner (WMF) (Diskussion) 23:40, 12. Dez. 2016 (CET)

Topografie --kogo (Diskussion) 23:18, 13. Dez. 2016 (CET)

erstmal ist es gut, wenn das Feature aktiviert wird. Ob es dann genutzt wird, ist ja nochmals eine andere Frage. Meine Punkte

• In Polnähe bietet Kartographer keinen Ersatz für die bisher verwendeten Postionskarten, vergleiche [[13]] (dort den Link folgen) und Südpol / Lage der verschiedenen Südpole. An einigen Stellen (z.B. Infoboxen) wird nicht nach Breitengradregionen unterschieden, d.h es würde die Einsetzbarkeit von Kartographer erst ermöglichen, wenn in den Polregionen die entsprechenden Projektionen verwendet würde und nicht die dort unsinnige (vermutlich) Zylinderprojektion.
• Kartographer unterstützt keine beliebigen labels, nur einfache ASCII-Zeichen.
• In WP:de werden je nach Anwendungsfall politische oder topographische Karten (relief) eingesetzt. Um das abzubilden bräuchte Kartographer eine Möglichkeit das zu steuern und je nach Kontext andere Basis-Kartentypen einzublenden bzw. einen einfache Umschaltmöglichkeit in der Karte selbst.
• generell die Diskussion Hilfe Diskussion:Kartographer beachten.
• Ich denke, dass ob er Komplexität der Schnittstelle eine direkte Einbindung in Artikel in WP:de eher nicht gewünscht ist.
• @CKoerner (WMF): I hope you understand the German here.

lg --Herzi Pinki (Diskussion) 01:03, 16. Dez. 2016 (CET)

Ja, mein Deutsch ist nicht so gut, aber ich verstehe. Ich warden lasse die Gruppe Ihre Bedenken wissen. Vielen Dank! CKoerner (WMF) (Diskussion) 16:09, 16. Dez. 2016 (CET)

Gibt es einen neuen Zeitplan? Mit 27. 1. ist <mapframe> nicht aktiviert. lg --Herzi Pinki (Diskussion) 02:25, 27. Jan. 2017 (CET)

IIUC beißt sich <mapframe> mit Flagged Revisions; vgl. phab:T153158. --Tim Landscheidt 08:12, 3. Feb. 2017 (CET)

Formeldarstellungsfehler (LaTeX) mit Android

Hi Wiki-Team, hoffe bin hier mit meinem Anliegen richtig, sowie hoffe ich, dass die Anmerkung nicht schon aufkam, hab aber über die Suchfunktion nichts gefunden.

Ich habe folgendes Problem (und dachte ich sei damit alleine) und musste letztens feststellen, dass das wohl kein ungewöhnliches Problem ist.

Wenn man sich Artikel auf Android anschaut, so werden mehrheitlich die LaTeX-Formeln nur in minimaler Größe dargestellt und es ist notwendig diese erst heranzuzoomen, um sie lesbar zu gestalten. Mal einen Beispielartikel aus der englischen Wikipedia, da dort amüsanter Weise beides auftritt: Lesbarkeit und gleichzeitig Unlesbarkeit. https://en.m.wikipedia.org/wiki/Mean_value_theorem Kann leider keine Bilddatei hochladen um das Problem zu Visualisieren und hoffe es ist reproduzierbar. (Was man sehen sollte: Einleitungsformel ist Normalgröße. Formeln in "Formel statement" sind nicht lesbar, da zu klein)

Ich selbst nutze ein Samsung S5 mit der aktuellsten Android Software und das "normale Interneticon" von Samsung "Internet Version 4.0.20-17".

Auf Wunsch kann ich noch einen Link beisteuern, in dem das Problem in einem anderen Forum (wiki-unabhängig) schon angemerkt wurde, sowie ein Beispielbild dort zur Verfügung stellen, weiß aber nicht inwiefern das hier gern gesehen ist, fremde Links zu setzen.

Danke bereits für eure Hilfe und Beste Grüße, Equester (nicht signierter Beitrag von 1.124.48.156 (Diskussion) 08:38, 28. Jan. 2017 (CET))

Bei mir auf dem Desktop-Firefox sind die Formeln in der Einleitung ganz normal, und die dartuner (die bei dir zu klein sind) werden erst sehr viel später, also wohl per Javascript, nachgeladen. Möglicherweise besteht da irgendein Zusammenhang. Wegen Links auf externe Bilder oder Foren: Bei solchen Einträgen zur Problembehebung ist das idR in Ordnung :-) --nenntmichruhigip (Diskussion) 12:19, 28. Jan. 2017 (CET)

Danke für die Hinweise. Dann füge ich auch gerade mal die Links bei, mit Bild :).

- http://www.matheboard.de/thread.php?threadid=572681

- http://www.matheboard.de/thread.php?postid=2080897#post2080897

Hoffe das hilft weiter. --Equester 14:36, 28. Jan. 2017 (CET) (ohne Benutzername signierter Beitrag von 1.124.48.156 (Diskussion))

Unten gab es eine weitere Meldung dazu, bei der auch ein paar Phab-Tickets verlinkt wurden. --nenntmichruhigip (Diskussion) 20:49, 8. Feb. 2017 (CET)

Developer Wishlist Survey: Vote for Proposals

Almost two weeks ago, the Technical Collaboration team invited proposals for the first edition of the Developer Wishlist survey!

We collected around 77 proposals that were marked as suitable for the developer wishlist and met the defined scope and criteria. These proposals fall into the following nine categories: Frontend, Backend, Code Contribution (Process, Guidelines), Extensions, Technical Debt, Developer Environment, Documentation, Tools (Phabricator, Gerrit) and Community Engagement.

Voting phase starts now and will run until February 14th, 23:59 UTC. Click here on a category and show support for the proposals you care for most. Use the 'Vote' and 'Endorse' buttons next to a proposal to do so.

What happens next?
Proposals that will gather most votes will be included in the final results which will be published on Wednesday, February 15th. These proposals will also be considered in the Wikimedia Foundation’s annual plan FY 2017-18 - SSethi_(WMF) (talk) 04:41, 6 February 2017 (UTC)

Offizielle Wikipedia-App für Android und <math>

Die offizielle Wikipedia-App für Android hat Probleme mit <math>-Elementen. Diese werden viel zu klein dargestellt. Kann ich die vergrößern ohne mich anzumelden? --FriedhelmW (Diskussion) 20:48, 6. Feb. 2017 (CET)

Meinst du die App oder die Mobile-Version? Es gibt da phab:T150052, phab:T107775 und phab:T73787. Der Umherirrende 21:10, 6. Feb. 2017 (CET)

Danke für die Links. Die App heißt "Wikipedia 2.4.160-r-2016-10-14". --FriedhelmW (Diskussion) 21:48, 6. Feb. 2017 (CET)

Dieser Abschnitt kann archiviert werden. FriedhelmW (Diskussion) 21:05, 28. Apr. 2017 (CEST)

JavaScript für Anzahl an Verlinkungen auf roten Artikel

Hallo. Ich hätte gerne über ein Benutzerscript die Anzahl der Verlinkungen auf einen nicht existierenden Artikel hinter jedem Rotlink. Dazu habe ich serverseitig auf Tool Labs schon ein Script vorbereitet, welches die Anzahl ermittelt. Dies müsste jetzt nur noch hinter die passenden Rotlinks projeziert werden. Dazu müsste das Linkziel ermittelt werden und im Parameter title= an das Script auf Tools weitergereicht werden. Die Syntax dafür lautet: https://tools.wmflabs.org/freddy2001/linknumbers.php?title=Beispiel Viele Grüße -- Freddy2001 ^DISK 11:55, 15. Feb. 2017 (CET)

Hallo Freddy, das bekommen wir hin, ich mache mich mal am We daran. LG -- User: Perhelion 00:52, 25. Feb. 2017 (CET)

@Freddy2001: Funzt nicht, denn es fehlt wohl ein "'Access-Control-Allow-Origin' header" bei deinem php (CORS)!? Ansonsten, was spräche den gegen einen Wiki-eigenen API-Aufruf? Wohl nur die Belastung des Wiki-Servers!? -- User: Perhelion 16:36, 26. Feb. 2017 (CET)

Evtl. haperts auch nur daran, dass einfacher Text übergeben wird!? :-/ (JSONP scheint auch nicht die richtige Wahl, JSON wäre z.B. {count:12}). Hier ist mein Stand der Dinge:

var redlinks = {};
function getLinksCount(e) {
	var url = 'https://tools.wmflabs.org/freddy2001/linknumbers.php';
	var $target = $(this);
	var title = encodeURIComponent('Beispiel' ||
			$target.prop('title').replace(' (Seite nicht vorhanden)', '')  // FIXME: get string dynamically
	);
	var r = "666"; // FAIL
	if (redlinks.hasOwnProperty(title)) return; // run only once
	$.ajax({
		url: url + "?callback=?",
		type: "GET",
		crossDomain: true,
		beforeSend: function (xhr) { xhr.overrideMimeType("text/plain"); },
		contentType: 'text/plain',
		processData: true,
		dataType: 'json', // or 'text'!?
		cache: true,
		timeout: 2000, // Give up if Tool Labs is being slow today
		data: "title=" + title,
		xhrFields: { withCredentials: true },
		success: function (r) {
			redlinks[title] = r;
			$target.prop('title', $('#t-whatlinkshere a').text() + " " + r);
			alert(r);
		},
		error: function (err) {
			alert("no good " + JSON.stringify(err));
		}
	})
}
$('.new').on('mouseover', getLinksCount);

PHP und Toolserver hatte ich bis jetzt weniger am Hut. MfG -- User: Perhelion 14:05, 27. Feb. 2017 (CET)

Ich habe mal ein Script ohne Toolserver erstellt, Freddy. -- User: Perhelion 03:37, 6. Mär. 2017 (CET)

Hallo Perhelion, das zweite Script auf meta funktioniert ausgezeichnet, genau so möchte ich es haben. Leider ist es jedoch ziemlich langsam (Mobil benötigt es fast eine halbe Minute, bis die Seite geladen ist).

Bei dem Script mit dem Toolserver bekomme ich immer nur linknumbers.php?callback=jQuery111309299507719567893_1488796530972&title=Beispiel und nicht den richtigen Titel des Links übergeben. Falls es helfen würde, könnte ich dort auch mit JSON die Ausgabe zurückgeben.

Zudem wäre es für mobile Verbindungen vermutlich auch besser, wenn nicht jede Anfrage einzeln, sondern mehrere auf einmal angefragt werden (wie bei der API), was auch Traffic sparen würde. -- Freddy2001 ^DISK 11:44, 6. Mär. 2017 (CET)

@Freddy2001: Wäre ein Versuch wert (ich befürchte allerdings dass beim Toolserver CORS deklariert werden muss). Evtl. kann sich ja jemand Drittes hierzu äußern. An die Funktion alle Redlinks in einem Rutsch abzuarbeiten habe ich auch schon gedacht, allerdings nur per konkret manueller Aktivierung (also als Link im Tool-Menue). Wobei man auch eine Art Badge mit Zahl direkt am Link erzeugen könnte ohne Mouseover!? Das Script sollte dann auch nur im Artikelnamensraum geladen werden? Tatsächlich werden momentan 2 Module vorgeladen, die generell ein Laden verzögern könnten (das könnte man auch nach hinten stellen, entweder bei Linkausführung oder erstem Mouseover). Ich könnte die Module auch rausschmeißen und durch nativerem (nur wenig längerem) Code ersetzen. -- User: Perhelion 22:57, 6. Mär. 2017 (CET)

@Perhelion:Ich kann auf dem Server gerne die CORS-Informationen mitsenden. So viel, wie ich bisher dazu herausgefunden habe, müsste das doch nur das Header-Feld Access-Control-Allow-Origin: * sein, was ich noch mitsenden müsste. Ideal wäre es, wenn es sich im ANR direkt automatisch aktiviert, jedoch ist es egal ob die Anzahl nur per Mouse-over oder als Zahl in Klammern dahinter steht. Soweit ich deinen Code und meinen Browserlog verstanden habe, liegt die Schwachstelle derzeit dadrin, dass jeder einzelner Link bei der API angefragt wird und diese natürlich weitaus mehr Informationen zurückliefert als benötigt, wie z.B. die Linktitel, die für dieses Script irrelevant sind, was natürlich auch wieder Datenverkehr verursacht. -- Freddy2001 ^DISK 16:30, 10. Mär. 2017 (CET)

@Freddy2001: Ja mache das mal, für einen automatischen Lauf wäre dein Tool sicher besser. Obwohl "mein" Script jetzt auch nur minimale API-Daten bekommt, kann es nun alle Red-Links auf einmal abfragen (wobei ich hier ein Limit von 100 einbauen musste da hier wohl die API-Grenze zu liegen scheint, allerdings funzt Mouseover so oder so dann trotzdem noch). -- User: Perhelion 16:29, 25. Mär. 2017 (CET)

Im Antwortheader sind nun folgende Informationen enthalten: Content-Encoding: gzip Content-Type: text/html Date: Mon, 27 Mar 2017 09:06:55 GMT Server: nginx/1.11.3 X-Clacks-Overhead: GNU Terry Pratchett X-Powered-By: PHP/5.5.9-1ubuntu4.21 access-control-allow-credentials: true Reicht dir das so, oder müsste ich noch weitere Werte einbauen? Als Bot kann ich über die API 5000 statt nur 500 Ergebnisse holen und über die Datenbank könnte ich unbegrenzt viele Links bestimmen. -- Freddy2001 ^DISK 11:13, 27. Mär. 2017 (CEST)

Bug in math-Funktion

Könnte bitte jemand für das auf Wikipedia:Redaktion_Chemie/Knacknüsse#Layoutproblem_Perchlorate beschriebene Problem ein Phab-Task aufmachen? Der letzte Beitrag fasst das Problem gut zusammen. Ich halte das klar für einen Bug, jedoch ist niemand aus der RC auf Phab aktiv.--Mabschaaf 23:02, 18. Feb. 2017 (CET)

@Mabschaaf:

Warum schreibt ihr das nicht einfach in <ce>? Dort besteht das Problem nicht.

<ce>	${\ce {3Cl_{2}\ +6OH^{-}\rightarrow 5Cl^{-}\ +ClO_{3}^{-}\ +3H_{2}O}}$
<math>	$\mathrm {3\ Cl_{2}+6\ OH^{-}\rightarrow 5\ Cl^{-}+ClO_{3}^{-}+3\ H_{2}O}$

Es ist kein Bug, sondern einfach uneindeutig, woran der horizontale Strich gehören soll. math setzt ihn an das, wo er dransteht, nämlich an die 3, und das ist sinnvoll.

<ce> weiß hingegen, was ein Anion ist.

VG --PerfektesChaos 23:37, 18. Feb. 2017 (CET)

Am 8. Feb. 2017 hatte hier jemand ein offenes nicht escapetes math-Tag reingeschrieben, deshalb schmierte die Seite vorübergehend ab. VG --PerfektesChaos 23:49, 18. Feb. 2017 (CET)

Zu <ce>: Solange sogar der Entwickler von der Verwendung abrät (siehe Wikipedia:Redaktion_Chemie/Knacknüsse#Implementierungsstand) ist das keine Alternative. Zudem hieße das Hunderte von Artikeln umbauen, weil <math> igendwann sein Darstellungsverhalten geändert hat.--Mabschaaf 23:56, 18. Feb. 2017 (CET)

@Mabschaaf: Du kannst auch gern selbst auf Phab aktiv werden. Kurz Konto erstellen, dann Fehler berichten. --Malyacko (Diskussion) 09:41, 20. Feb. 2017 (CET)

Im Prinzip weiß ich das, habe aber keine Lust, mich auf einem weiteren Projekt in irgendwelche Details einzuarbeiten. Daher bin ich nach Intro #4 mit meinem Wunsch hierher gekommen. --Mabschaaf 13:08, 20. Feb. 2017 (CET)

Dynamische Altersangaben nur für angemeldete Benutzer korrekt?

Hallo zusammen,
dieser Tage habe ich festgestellt, dass dynamische Altersangaben zumindest in bestimmten Fällen nicht angemeldeten Lesern nicht korrekt angezeigt werden.
Ich habe das jetzt mal an einem Beispiel überprüft:
Die derzeit älteste lebende Person, Emma Morano-Martinuzzi, ist heute 117 Jahre und 85 Tage alt.

• Dies wird mir in den Artikeln Liste der ältesten Menschen, Liste der ältesten Frauen und Ältester Mensch#Die ältesten Menschen auch richtig angezeigt – wenn ich eingeloggt bin!
• Ausgeloggt (also vermutlich wie die meisten unserer Leser) sehe ich auf der erstgenannten Seite das korrekte Alter, auf der zweiten „117 Jahre und 84 Tage“ und auf der letzten gar „117 Jahre und 76 Tage“.
• Der erste Artikel wurde heute (CET) bearbeitet, der zweite zuletzt vorgestern und der dritte am 8. Februar. Die Abweichung erklärt sich also nicht allein aus dem Zeitpunkt des letzten Abspeicherns.
• Nulledit (eingeloggt) ändert nichts.
• Lasse ich mir (nicht eingeloggt) den jeweiligen Diff anzeigen, ist jedoch alles korrekt.

Nachdem ich seit Jahren regelmäßig bei der pünktlichen Pflege der Ältestenlisten mithelfe, bin ich doch einigermaßen verwundert, dass diese Arbeit so nicht bei unseren Lesern anzukommen scheint. Es kann nicht sein, dass nicht Eingeloggten in der normalen Leseansicht eine durch falsche Altersangaben nahezu unbrauchbare Liste präsentiert wird.
Vielen Dank im Voraus für Eure Antworten – ich hoffe, ich bin mit dem Problem richtig hier. Grüße --Monow (Diskussion) 22:00, 22. Feb. 2017 (CET)

Der Cache wird vorallem für unangemeldete Benutzer genutzt, aber auch für angemeldete mit Standardeinstellungen. Es ist daher nicht möglich, korrekte Zeitangaben zu machen. Siehe auch Vorlage:Tagesdifferenz#Parameter. Der Umherirrende 17:32, 23. Feb. 2017 (CET)

Wäre es möglich im Tabellenkopf das Bezugsdatum (Cache) anzugeben? Sonst sollten die Tage ausgeblendet werden oder wenigstens mindestens ... Tage eingesetzt werden. --Diwas (Diskussion) 23:08, 23. Feb. 2017 (CET)

Die Vorschläge im letzten Satz schießen meiner Meinung nach beide deutlich übers Ziel hinaus – da wäre die Arbeit wirklich umsonst gewesen. Sinnvoller wäre es, über {{Purge}} mit einem entsprechenden Hinweis nachzudenken. Wie ich heute festgestellt habe, funktioniert (anders als beim Nulledit) auf diese Weise die Anzeige der Zahlen nämlich korrekt. Mit Rücksicht auf die Serverbelastung genügt es aber wohl, wenn ich das bei der (nach Möglichkeit) täglichen Aktualisierung gleich miterledige und nicht jeder zweite Leser da draufklickt :-) Grüße --Monow (Diskussion) 23:32, 23. Feb. 2017 (CET)

Für die von dir gepflegten Seiten, wäre das natürlich die leserfreundliche Lösung. Falls solche Vorlagen auch in anderen Artikeln verwendet werden: Gibt es eine Möglichkeit, die Server zu veranlassen, Seiten mit bestimmten Vorlagen automatisch täglich zu purgen? --Diwas (Diskussion) 14:33, 24. Feb. 2017 (CET)

Problem beim Übertragen der Benutzerdaten

Seit etwa einem Tag kann ich keine Seiten mehr bearbeiten. Beim Versuch, eine Seite zu sichten ergibt sich folgende Fehlermeldung: "Es gab ein Problem bei der Übertragung deiner Benutzerdaten. Diese Aktion wurde daher sicherheitshalber abgebrochen, um eine falsche Zuordnung deiner Änderungen zu einem anderen Benutzer zu verhindern. Bitte gehe zurück zur vorherigen Seite, lade sie erneut und versuche, den Vorgang erneut auszuführen"

Beim Versuch, eine Bearbeitung zu speichern kommt folgender Fehler: "Entschuldigung! Wir konnten deine Bearbeitung nicht verarbeiten, da Sitzungsdaten verloren gegangen sind.

Du wurdest eventuell abgemeldet. Bitte verifiziere, dass du noch angemeldet bist und versuche es erneut. Falls dies nicht funktioniert, versuche dich abzumelden und anschließend wieder anzumelden und überprüfe, ob dein Browser Cookies von dieser Website akzeptiert."

Der Fehler ergibt sich auch in anderssprachigen Versionen, manchmal klappt es beim xten Versuch, manchmal nicht. Aus- und wieder Einloggen hilft nicht. Browser ist Firefox. Liegt das Problem an mir? Wie kann ich Abhilfe schaffen? Vielen Dank, --79.199.134.118 18:49, 23. Feb. 2017 (CET)

Andere Firefox-Benutzer haben das Problem auch. Siehe Wikipedia:Fragen zur Wikipedia/Archiv/2017/Woche 03#Fehlercode: badtoken --Fomafix (Diskussion) 19:18, 23. Feb. 2017 (CET)

Danke!! Und die dortige Anleitung scheint zu helfen :) --Grullab (Diskussion) 19:32, 23. Feb. 2017 (CET)

Element neben Überschrift?

Hallo Profis! Ist es möglich, neben einer Überschrift noch ein Element zu platzieren? Im Beispiel soll der eingeklappte Kasten auf gleicher Ebene rechts am Rand (wie ein Bild) stehen und nicht untereinander wie hier:

Testüberschrift

„Daten 1“
Parameter	Werte	Vergleich
Energieeinsatz:	ca. 0,5 MJ/ha/Jahr	1/10.000stel so hoch
Energieeffizienz:	6-fach	weniger als halb so effizient
Angaben nach Lauk; aus Fallbeispielen zusammengefasst und großzügig gerundet

Würde mich freuen, wenn das ginge, weil´s optisch deutlich schöner wäre! Viele Grüße --Fährtenleser (Diskussion) --Fährtenleser (Diskussion) 16:09, 28. Feb. 2017 (CET)15:41, 28. Feb. 2017 (CET)

Es gibt keine robuste und saubere Realiierung, die dann auch für alle Leser sinnvoll wäre und nicht die Gefahr schwerer Nebenwirkungen hätten.

• Die Leutchen hier in dieser Werkstatt können zwar zaubern, aber das hat Grenzen.

Bedenke:

• Es gibt auch Mobilgeräte, die von rund der Hälfte unserer Leser eingesetzt wetden.
• Neben der Überschrift steht in der Regel auch eine Verlinkung zur Abschnittsbearbeitung.

Grundsätzlich können knapp oberhalb der Überschrift am rechten Fensterrand ausgerichtete Elemente beginnen; so auch Bilder usw.

• Überlege dir jedoch, wie eine etwas breitere Tabelle wie im Beispiel beim Ausklappen auf einem schmaleren Bildschirm die Überschrift und das [Bearbeiten] zerquetscht.
• Auf Mobilgeräten ist das Layout obendrein völlig anders.

Zauberkunststückchen können leicht dazu führen, dass sich Textzeilen und das Element überlappen.

VG --PerfektesChaos 19:26, 28. Feb. 2017 (CET)

Ein Beispiel für „schwere Nebenwirkungen“: auf den ersten Blick denkt man, je größer der klappbare Inhalt desto mehr macht es Sinn ihn auf und zu zu klappen. Fehlanzeige: ist ein klappbarer Inhalt ausgeklappt und man befindet sich mitten im klappbaren Inhalt, dann läuft der Button zum Auf-/Zuklappen aus dem Bild. Man kann den Inhalt also nicht verschwinden lassen. Je kleiner der Bildschirm, desto großer das Problem. Hingeben ist die Software von Geräten mit kl. Bildschirm von Haus aus so ausgelegt, dass einfaches Scrollen gut funktioniert. Darauf sollte man aufbauen (und Überschriften vernünftig wählen soll auch helfen). -- Summer • Streicheln • Note 15:14, 4. Mär. 2017 (CET)

OK, dankeschön! Ich werde es anders lösen. Viele Grüße aus Wuppertal --Fährtenleser (Diskussion) 11:58, 8. Mär. 2017 (CET)

Standardtext beim Verwerfen von ungesichteten Änderungen bei IPv6 ist zu lange

Gemeldet in Phabricator
Task T39356

Wenn man eine ungesichtete Änderung verwerfen und wieder auf die bisherige Version eines Artikeltexts zurücksetzen will, so erscheint ein Standardtext, der den Benutzernamen übernimmt:

(Die letzte Textänderung von ÄÄÄÄÄÄÄÄ wurde verworfen und die Version 000000000 von ZZZZZZZZ wiederhergestellt.)

Ist einer (oder gar beide) dieser Benutzernamen aber eine IPv6-Adresse, so wird der gesamte Text zu lange und man muss manuell kürzen, damit der Text nicht länger als 200 Zeichen wird. Bitte den Standardtext kürzen (z.B. Artikel entfernen gem. Beispiel):

(Änderung von ÄÄÄÄÄÄÄÄ verworfen und Version 000000000 von ZZZZZZZZ wiederhergestellt.)

Für's erste sollte das ein Stück weit reichen, ohne das Textfeld länger zu machen (was wohl weiterreichende Folgen hätte). Danke --ProloSozz (Diskussion) 13:32, 5. Mär. 2017 (CET)

Siehe auch phab:T39356 --nenntmichruhigip (Diskussion) 13:40, 5. Mär. 2017 (CET)

Die Systemnachrichten sind diese. -- MBq ^Disk 13:52, 5. Mär. 2017 (CET)

Danke; was muss man tun, um diese Systemnachrichten anpassen zu können/dürfen? --ProloSozz (Diskussion) 15:49, 5. Mär. 2017 (CET)

1. Ich habe noch nie was mit Modulen in solchen Systemnachrichten zu tun gehabt, aber wenn Parserfunktionen gehen, dann gehen Lua-Aufrufe vielleicht auch. Falls nicht, käme eine JavaScript-Nachbereitung des BK-Vorschlags in Frage; die geht mit Sicherheit.
2. Lua wäre Wikipedia:Lua/Modul/URLutil #isIPv6
   • {{#if: {{#invoke:URLutil|isIPv6|1=$2}} | Dies | Das }}
3. Für JavaScript würde in der URL wohl irgendwas mit &undo= stehen; das ließe sich abfangen und in dieser Situation der Inhalt des BK nach einem gewissen Schema transformieren.
   • Ein Opt-Out-Gadget, und wenn eines Tages das Limit für BK-Länge erhöht wird, dann kann das auch wieder aus dem Angebot genomen werden.
4. Die IP-Verlinkung sollte schon funktionstüchtig bleiben und nicht gekürzt werden.
5. Konkrete Textvorschläge für den IPv6-Text?
6. @ProloSozz: Es braucht einen Techie aus dieser Werkstatt, einen Admin zum Live-machen, und WP:BETA zum Erproben.

LG --PerfektesChaos 16:55, 5. Mär. 2017 (CET)

Naja, wenn JavaScript eh abgeschaltet bleibt, dann bringt eine "Lösung" mit JS eh nix. Nun: ich würde momentan nicht mehr machen als wie im Beisipel oben ausgeführt. D.h.: "Die letzte Text..." entfernen und auf "Änderung" verkürzen (ob das erste oder letzte war, kann doch eh an der Nummer ersehen werden), "wurde" entfernen, "die" entfernen"; damit hat sich's vorläufig. Das wird sich dann weisen, ob das ausreicht oder immer noch zu lang ist. --ProloSozz (Diskussion) 17:03, 5. Mär. 2017 (CET)

Also, „das wird sich dann weisen“ ist dieser Werkstatt nicht der Brauch. Das kann man sich ja vorher ausrechnen, wie viele Bytes dabei herausspringen werden, und es soll ja auch noch was übrigbleiben, um noch eine kleine Anmerkung dranzuhängen.

Und wenn ich mir Spezial:Diff/163237508 mal genauer anschaue, dann scheinen sich mir folgende Kürzungsmöglichkeiten auf Kosten der Schönheit zu ergeben:

• Änderungen von [[Spezial:Beiträge/2003:75:8F17:B801:789F:728F:5D2C:79F7|2003:75:8F17:B801:789F:728F:5D2C:79F7]] ([[Benutzer Diskussion:2003:75:8F17:B801:789F:728F:5D2C:79F7|Diskussion]]) auf die letzte Version von [[Benutzer:Regi51|Regi51]] zurückgesetzt
  • Die Diskussionsseite einer IPv6 scheint mir kein unmittelbar dringendes Ziel zu sein.
  • Die Maskierung der Beitragsliste mag entfallen.
  • So auch die vornehm gekürzte Linkbeschriftungeiner Versionsnummer.

Warum „wenn JavaScript eh abgeschaltet bleibt“ der Fall sein solle, habe ich jetzt nicht verstanden.

LG --PerfektesChaos 17:16, 5. Mär. 2017 (CET)

a) "Wird sich weisen ..." Die Textlänge ist auch von der Namenslänge des Vorschreibers abhängig. Und da i.d.R. auf eine Version eines namentlich angemeldeten Benutzers revertiert wird, dessen Name nicht so überlang ist wie eine IPv6-Adresse, ist vorerst mal eine Länge einzuhalten, die für eine (einzige) IPv6-Adresse erträglich ist; und das dürfte mit der bestehenden Feldlänge noch zutreffend sein. Klar wäre es sicher nicht zu verachten, wenn genügend Platz da wäre, um zwei IPv6-Adressen unterbringen zu können. Aber das würde dann wohl nicht ohne Feldlängenvergrösserung gehen; und die könnte jetzt noch zurückgestellt werden. Sollte sich aber trotz Systemtextkurzform das Problem weiterhin zeigen, dann müsste die Feldlänge dann doch erhöht werden. Und genau _das_ wird sich weisen, ob das dann doch nötig würde.

b) Ich hab' JS eigentlich immer abgeschaltet und schalte das nur dann ein, wenn es nicht anders geht. Auf die kleinen Zusatzdetails (wysiwyg etc.) kann ich gerne verzichten, wenn ich es nicht ausdrücklich mal einsetzen will (und dann wird kurzzeitig JS eingeschaltet und nach der Aktion wieder aus). Und das werden hier viele auch so handhaben. Deshalb sollte es eine Lösung sein, die ohne JS auskommt.

c) Als Text würde "Änderung(en) von ÄÄÄÄÄÄÄÄ auf letzte/erste Version(en) 000000000 von ZZZZZZZZ zurückgesetzt." ausreichen; da wäre dann sogar das "erste"/"letzte" noch mit dabei (das "die" kann auch entfallen). --ProloSozz (Diskussion) 19:17, 5. Mär. 2017 (CET)

• @ProloSozz
  • Ich schrieb oben: möglichst Lua; notfalls JavaScript („gehen Lua-Aufrufe vielleicht auch. Falls nicht“).
  • Wenn Lua nunmal nicht geht, dann bleibt eben nur JavaScript – wenigstens für die weitaus überwiegende Mehrheit der Benutzer.
  • Erfreulicherweise konnte ich jedoch erproben, dass Lua hier einsetzbar ist.
• Eine IPv6 nimmt 63 Bytes in Anspruch.
  • In MediaWiki:Revertpage tritt die Benutzerkennung fünfmal auf.
  • Wenn also eine IPv6 eine andere IPv6 revertiert, kommen 315 Bytes für die IDs sowie 131 Bytes zusammen; 446 Bytes würden benötigt.
  • Ein Nick darf für die WMF wohl 32 Zeichen lang sein (mw:Manual:user table meint 255 varchar?) und wenn dafür nur altchinesische Schriftzeichen benutzt werden, dann braucht das nach meiner Kenntnis von UTF 128 Bytes je Nennung. Unser Standard-BK würde 771 Bytes lang.
• Die Summary ist wohl weiterhin auf 255 Bytes begrenzt.
  • Ideen, das auszudehnen, gehen auf 2006 zurück.
  • Auch in jüngerer Zeit stand man seitens MW einer WMF-weiten Ausdehnung der zulässigen Länge sehr skeptisch entgegen.
  • Ich selbst halte überhaupt nichts von einer Aufblähung des BK. Ich will auf Beo und in der VG keine mehrzeiligen Gedichte zu lesen bekommen, sondern in knappen Schlagworten und ggf. mit Links das Ziel der Aktion zusammengefasst bekommen. Detailfragen sind erst im Diff zu erschließen.
  • Die Vorstellung aus Kindertagen der WP, man könnte im BK die vollständigen Literaturangaben für den Edit unterbringen (weshalb das noch Hilfe:Zusammenfassung und Quellen genannt wird), ist Quatsch. Allenfalls kann da mal eine IP den ungesichteten Edit untermauern. Aber über anderthalb Jahrzehnte alle URL in der Versionsgeschichte durchzuprobieren, damit jedes Mal jeder Leser herausfinden könne, welcher der Beleg für eine bestimmte Aussage sein soll, ist Unfug; dazu haben wir leserfreundliche Einzelnachweise mit direktem Bezug.
  • Eine Lösung über längere BK ist nicht zu erwarten (wir konnten leider ihre Bremsen nicht reparieren – deshalb haben wir ihnen eine lautere Hupe eingebaut).
• Ich habe mal zur Erprobung Modul:MsgRevert gestartet.
  • Die gute Nachricht: Das Modul wird anstandslos ausgeführt.
  • Zu Testzwecken habe ich das Limit mal auf je 20 Bytes gesetzt.
  • Als PerfektesChaos kam die normale Nachricht (s1s2).
  • Als Pēřƒēķťēš Čĥāōš mit Multi-Byte-Zeichen kam die Nachricht mit offenem Link für $2 (s1x2).

@Umherirrender, Raymond:

• Ich bitte um Stellungnahme hinsichtlich Einführung in der echten WP.
• Zur Erprobung kann ja ein Ümhéřïřřéñðéř angelegt werden.
• Zurzeit wird [kommentarlos zurücksetzen] unterstützt.
  • MediaWiki:Revertpage
  • Welche von den rollback-undo-Dingenskirchen werden denn noch produktiv eingesetzt? Die Tabelle oben ist nix.
  • Statt „Contributions“ dann natürlich offen „Spezial:Beiträge“.
  • Müsste man sich mal die genauen Limits für $1 und $2 ausrechnen; 2×$1 + 3×$2 < 120 oder so irgendwie.
  • Nix mit „es wird sich weisen“; vorher denken.
• Benutzerskripte für rollback, die eine summary generieren, müssten analoge Überlegungen anstellen.
• Übrigens gibt es auch doofe Logbucheinträge, in denen nicht anklickbare URL stehen; wobei oft anklickbare Wikilink-Syntax möglich wäre. Ließen sich vermutlich ebenfalls in geeigneten Systemnachrichten auffischen und verlustfrei umwandeln.

VG --PerfektesChaos 10:44, 7. Mär. 2017 (CET)

MediaWiki:Undo-summary kommt beim Klick auf (rückgängig), MediaWiki:Revreview-reject-summary-cur und MediaWiki:Revreview-reject-summary-cur-short werden beim Verwerfen einer ungesichteten Änderung benutzt. -- hgzh 11:13, 7. Mär. 2017 (CET)

Wenn es mit Lua funktioniert, und so sieht es ja aus, warum nicht? Aber beim Review von Lua-Code bin ich aus dem Spiel :-( — Raymond ^Disk. 12:15, 8. Mär. 2017 (CET)

Ich würde es begrüßen, das in php für alle Wikis zu haben, nicht nur hier. Für FlaggedRevs gibt es bereits Ansätze dazu, daher gibt es "revreview-reject-summary-cur" und "revreview-reject-summary-cur-short". Der Umherirrende 20:10, 10. Mär. 2017 (CET)

Anzeigen nur der letzten Erwähnung eines "Artikels" bei den eigenen Beiträgen

In der Anzeige der eigenen Beiträge können bekanntlich mehrere Filter gesetzte werden:

• Nur aktuelle Versionen zeigen
• Nur Seitenerstellungen anzeigen
• Kleine Bearbeitungen ausblenden

Wo ist aber die Option "nur jeweils letzten Eintrag eines 'Artikels' zeigen"? Hintergrund ist: ich will erkennen können, welche meiner Beiträge noch aktuell sind und welche nicht. Und wenn ein Beitrag 50x aufgelistet wird (und natürlich immer "nicht merh aktuell" ist, muß aus diesem Datenwust dann herausgesucht werden, ob der letzte aktuell ist oder nicht; das ist natürlich ziemlich durchmischt. Wen von jedem bearbeiteten "Artikel" (wobei da auch Beiträge bei Diskussionen, Vorlagen, etc. mit gemeint sind) nur jeweils der letzte aufgelistet würde, könnte viel besser erkannt werden, welche noch aktuell sind und bei welchen schon wieder etwas geändert wurde. Wie ist so ein Filter einzurichten? --ProloSozz (Diskussion) 13:45, 6. Mär. 2017 (CET)

@ProloSozz: Ich habe neulich für Benutzer:Flominator/WhereWasI.js etwas in dieser Richtung eingebaut: Es gibt einen Link mit denen man alle Einträge ausblenden kann, außer denen die nach einem selbst geändert wurden. Hilft dir das weiter? --Flominator 13:53, 6. Mär. 2017 (CET)

Hmm, muß mir das mal anschauen ... Wie wäre das einzubinden/zu aktivieren? NB: meine Idee ist: wenn ich auf "Beiträge" oben rechts gehe, sollte ich (neben der Anzeige sämtlicher meiner Beiträge) auch so filtern können, dass jeweils nur die allereltzte Bearbeitung eines "Artikels" erscheint und alle früheren Bearbeitungen ausgeblendet werden; d.h. es erscheint dann jeder "Artikel", an dem ich etwas geändert hatte, nur genau ein einziges mal (und zwar meine letzte Änderung; meine vorhergehenden Änderungen würden ausgeblendet und wären nicht sichtbar). Wenn dann ein "(aktuell) steht, war ich es, der zuletzt geändert hatte; wenn nicht, wurde von sonstwem schon wieder etwas daran geändert. Ich will ja wissen, ob mein Stand noch vorliegt oder nicht. --ProloSozz (Diskussion) 14:38, 6. Mär. 2017 (CET)

Hi ProloSozz, das ist mit einem Benutzerscript nicht so leicht umzusetzen, man könnte dafür aber ein kleines Tool schreiben was eine Datenbankabfrage durchführt und einfach die zuletzt bearbeiteten Artikel auflistet. --FNDE 16:33, 6. Mär. 2017 (CET)

@FNDE: Einspruch, siehe HideMyLatestRevisions() --Flominator 17:07, 6. Mär. 2017 (CET)

@ProloSozz: Indem du importScript('Benutzer:Flominator/BklRedir.js'); in deine Common.js/Monobook.js/Vector.js einfügst und danach auf "Eigene Beiträge" den Link " Aktuelle Versionen ausblenden" anklickst (im kleingeschriebenen Text unter der Überschrift "Benutzerbeiträge") --Flominator 21:10, 7. Mär. 2017 (CET)

Wikipedia:Technik/Labs/Tools/vcat/render

Das Tool scheint nicht mehr zu laufen. Kann jemand helfen? Gruß --Zulu55 (Diskussion) _Unwissen 21:56, 6. Mär. 2017 (CET)

Der Fehler betrifft nur die SVG-Darstellung; wenn man in der URL SVG durch PNG ändert, bekommt man eine gültige Grafik. Kann man als Workaround die Verlinkung auf die PMG-Version ändern? --Matthiasb – ^{(CallMyCenter)} 15:46, 10. Mär. 2017 (CET)

format=png soll angeblich die Voreinstellung sein.

Wenn man den Parameter format= weglässt, soll PNG also nach letztem bekanntgewordenem Stand das Normalverhalten sein.

format=svg funktioniert nicht bei jedem Browser, sondern nur bei solchen, die auch ein PlugIn für SVG-Darstellung serienmäßig eingebaut oder vom Benutzer nachgerüstet erhalten haben.

VG --PerfektesChaos 16:01, 10. Mär. 2017 (CET)

A/B test zur Multi-Wiki Suchfunktion

Hallo,

Das Discovery Suchmaschinen Team würde gerne einige A/B Experimente zur Suchqualität in diesem Wiki durchführen. Jedes dieser Experimente wird ungefähr eine Woche dauern, und wird einer kleinen Gruppe von Benutzern neue Suchergebnisse präsentieren. Als Resultat werden wir besser verstehen, ob zusätzliche Suchergebnisse aus anderen gleichsprachigen Wikis nützlich, relevant und für Benutzer interessant sind. (demo)

Bitte lasst uns wissen falls es Bedenken oder Fragen hierzu gibt. Falls keine signifikanten Probleme identifiziert werden, planen wir die Tests gegen Ende März zu starten.

Mehr Hintergrundinformationen sind unter Cross-wiki Search Result Improvements verfügbar. Die vorläufig geplanten Tests sind unter Cross-wiki Search Result Improvements/Testing beschrieben.

Vielen Dank, CKoerner (WMF) (Diskussion) 15:33, 10. Mär. 2017 (CET)

Kategorien über Vorlagen / Cache-Handling

Moin zusammen, vor einigen Monaten habe ich in die Vorlage:Infobox Freizeitpark einen automatischen Bilderwunsch eingebaut, so kein Bild gesetzt wurde. Nun tauchen immer mal wieder ein paar solcher Artikel auf Botlisten und in der WP:bwAPI auf, obwohl sie schon seit Ewigkeiten kein Bild haben. Ich vermute einfach mal, dass liegt am Caching, sodass die Seite bearbeitet werden muss (und sei es nur ein Dummy-Edit), damit die Kategorienzuordnung wirksam wird. Ist dem so? Passiert das irgendwann auch von selbst oder muss man hier einen Dummy-Edit provozieren? Danke und Gruß, --Flominator 10:08, 11. Mär. 2017 (CET)

„obwohl sie schon seit Ewigkeiten kein Bild haben“

• Dies habe ich nicht verstanden.
• Gemeint ist: Obwohl der Bildparameter inzwischen gesetzt wurde?
• Obwohl ein Bild mittlerweile irgendwo im Artikel vorkommt?

Wenn jemand den Artikel bearbeitet, dabei die Vorlageneinbindung dahingehend ändert, dass BILD=hier.jpg eingetragen wurde, dann fällt der Artikel beim Speichern automatisch aus der Kategorie heraus, ohne dass du etwas machen müsstest.

Du hast die Vorlage Anfang Oktober 2016 verändert; das sollte im Prinzip reichen, dass die einbindenden Artikel das nach einigen Wochen mitbekommen, weil gelegentlich alles im Cache neu aufgebaut wird. Kann sich aber mit unbekannter Verzögerung hinziehen.

Du bräuchest in solchen und anderen Fällen wohl etwas wie: Benutzer:PerfektesChaos/js/pageLinkHelper #forcerecursivelinkupdate

• Bei Kategorien und Links auf diese Seite erhältst du dann ein zusätzliches Link im Werkzeugmenü angeboten, das im Hintergrund einen API-Prozess lostrittt, und (so lange die Seite offen bleibt) in beliebiger Menge alle Seiten in der Kategorie bew. alle Verlinkungen darauf dahingehend aktualisiert, dass anschließend die Kategorisierung stimmt.
• Nach Änderungen wie im letzten Oktober kannst du somit die indirekten Kategorisierungen usw. mit sofortiger Wirkung aktualisieren, während ansonsten die veränderte Vorlagenprogrammierung noch keine Auswirkung auf die einbindenden Artikel hätte, zumindest nicht hinsichtlich ihrer Kategorisierung und eigenen Linklisten.

LG --PerfektesChaos 20:28, 11. Mär. 2017 (CET)

Danke. Was ist der Unterschied zwischen PURGE/linkupdate und PURGE/rekursiv? Gruß, --Flominator 09:22, 18. Mär. 2017 (CET)

Unterschiede:

• purge aktualisiert die optische Darstellung der momentanen Seite.
• linkupdate aktualisiert (außerdem) die Wirkung der momentanen Seite nach außen; namentlich Kategorisierung, ggf. auch behauptete Einbindungen/Verlinkungen.
  • Das müsste sich nach dem Abspeichern einer neuen Version eigentlich auch von selbst regeln, zumindest wenn durch den Quelltext selbst ausgelöst; kann aber bei Vorlagen und Softwarefehler-Detektierung schon mal hakeln.
• rekursiv macht auch ein linkupdate, aber zusätzlich bei allen Seiten, die die momentane Seite einbinden.
  • Wenn sich durch Änderung in einer Vorlage die Kategorisierung ändert, dann bekommen das die einbindenden Seiten oft nicht so restlos mit; sie zeigen zwar optisch für sich die richtige Kat an, stehen aber womöglich noch in der falschen.
• Mein Werkzeug kennt noch „bezogene Seiten“.
  • Das greift bei Kats und Spezialseite „Was linkt hierher“.
  • Dann bekommen alle Mitglieder der Kat usw. nach und nach ein linkupdate.
  • Ansonsten würde rekursiv nur auf die Seiten wirken, die die Kategoriebeschreibungsseite einbinden.

Wenn du in einer Werkstatt fragst, bekommst du der Reihe nach von irgendjemandem, der grad Zeit hat, gelegentlich eine Antwort, wenn es sich halt ergibt. Wenn du jemanden anpingst, dann leuchtet es rot auf, die Arbeit wird unterbrochen, man muss die auslösende Seite aufrufen, um zu gucken, was es gibt, und sich schon mal einlesen. Dadurch drängelst du dich an der normalen Abarbeitung vorbei nach ganz vorne. Wenn es eine Frage für ein allgemeines Forum ist, mit dem die Angepingten selbst gar nichts zu tun haben, ist das nicht so prickelnd. Jetzt ist Sonntag nachmittag, und ich gehe grad die Werkstätten durch, wo was offen ist.

LG --PerfektesChaos 15:16, 19. Mär. 2017 (CET)

Danke für die Erklärung. Wäre das vielleicht ein Tooltip für die Links wert. Dass Ping deine Arbeit unterbricht, war mir nicht bewusst. Für mich landen die Pings i.d.R. auch nur in der Inbox und werden bei Gelegenheit durchgearbeitet. Ich werde versuchen, zukünftig auf Pings an dich zu verzichten. Gruß, --Flominator 15:39, 19. Mär. 2017 (CET)

Mehrere API-Abfragenergebnisse in JavaScript zusammenfassen?

Ich habe ein kleines Script, das mehrere API-Abfragen abschickt und die Resultate auf der Konsole anzeigt:

mw.loader.using( [ 'mediawiki.api', 'mediawiki.ForeignApi' ] ).done( function () {
    var api = new mw.Api();
    api.get( {
        action: 'query',
        meta: 'globaluserinfo',
        guiprop: 'merged'
    } ).done( function ( data ) {
        data.query.globaluserinfo.merged.forEach( function( element, index, array ) {
            let url = element.url;
            var remoteapi = new mw.ForeignApi( url + '/w/api.php' );
            [mw.config.get('wgNamespaceIds').user, mw.config.get('wgNamespaceIds').user_talk].forEach( function( element, index, array ) {
                remoteapi.get( {
                    action: 'query',
                    list: 'allpages',
                    apprefix: data.query.globaluserinfo.name,
                    apnamespace: element
                } ).done( function (data2) {
                    for( var j = 0; j < data2.query.allpages.length; j++ )
                        console.log( url + '/wiki/' + data2.query.allpages[j].title );
                });
            } );
        } );
    } );
} );

Ich möchte dieses derart verändern, dass statt der Konsolenausgaben nach dem Erfolg aller API-Abfragen ein Dialogfenster à la mw.loader.using( 'oojs-ui-windows' ).done( function () { OO.ui.alert( 'Alle Daten: ' + results ); } ); erscheint. Wie löst man so etwas normalerweise? --Tim Landscheidt (Diskussion) 00:05, 12. Mär. 2017 (CET)

Deine Fragestellung verblüfft.

• Was da oben steht, ist so hochprofessionell, dass du sie dir eigentlich selbst beantworten können müsstest.
• Allerdings erkenne ich C&P-Quellen aus mw: wieder.

Zur Beantwortung:

• oojs-ui-windows gehört oben in das mw.loader.using() mit hinein.
• Ich würde mir überlegen, wie viel Text bei der automatischen Selbstanalyse herauskommen kann, und wie groß ein Alert-Window sein kann, wie groß ein Browser-Fenster und Bildschirm wären.
  • Es sollte besser etwas sein, das eingepackt ist in ein <div style="overflow:auto">
  • Die einzeln lesbaren Zeilen/Einträge müssen geeignet voneinander getrennt werden.
  • Die oojs-ui akzeptieren ein jquery-Element $content zur Darstellung, ergo muss das strukturiert aufgebaut werden, damit dieses div herauskommt. text mag eine kurze, kleine Überschrift sein.
  • Seitennamen können Aufzählungslisten <li> sein, falls mehr als einer; ggf. gekürzt um die immergleichen Benutzernamen und womöglich fremdsprachliche Namensraumbezeichnungen.
• Du brauchst eine Variable, vorab wahlweise als leerer String oder als Array deklariert, in der du jedes eintrudelnde Ergebnis erstmal ablegst.
  • Auf der console zu protokollieren kannst du außerdem beibehalten.
  • Zum Schluss wertest du das Sammel-Array aus und baust den $content daraus, und stellst das dar.
• Ich würde die merged-Details mit in das Element des jeweiligen Resultat-Arrays aufnehmen; bzw. über die Wiki-IDs (oder Domain-URL) alle Elemente von merged in einem Objekt zugreifbar machen, und die Resultate der Abfrage auf dem Fremdwiki in diesem Objekt unter der jeweiligen Wiki-ID hinterlegen.
• Du musst irgendwie feststellen, wann du alle Ergebnisse der fremden Wikis erhalten hast, oder wann es sich nicht mehr lohnt, auf Ergebnisse zu warten.
  • Ein trivialer Ansatz ist es, die initiale (doppelte) Länge des merged-Arrays herunterzuzählen; bei 0 hast du alles.
  • Noch deppischer wäre es, die Länge der Arrays von merged und der gesammelten Resultate miteinander zu vergleichen.
  • Schlauer wäre es, eine gewisse Anzahl von Sekunden abzuwarten, und den Ergebnisdarstellungsprozess alternativ beim Eingang des letzten Resultats aus dem letzten Wiki oder aber nach Zeitablauf darzustellen. Wenn ein Wiki nicht antworten mag, kannst du vor dem Bildschirm vermodern.
  • Falls du ein adressierbares Objekt verwendest, könntest du zur Darstellung sogar eine sortierbare Tabelle der Wikis mit Anzahl und Art verlinkter Benutzerseiten anzeigen; mit Markierungen, wo ein Wiki nicht innerhalb der Zeit geantwortet hatte. Allpages können mehrere oder viele werden (aplimit!).
• wgNamespaceIds brauchst du nicht, user und user_talk gehen eigentlich immer, bzw. sind immer 2 und 3 bei der WMF. Abgesehen davon fragst du sowieso immer nur die Werte der deutschsprachigen Wikipedia ab, oder wo immer gestartet.
  • Man würde schreiben
    for ( nsn = 2; nsn <= 3; nsn++ ) { /* ... */ }
  • var-Deklarationen gehören übrigens an den Anfang eines Funktions-Levels und nicht mitten in eine Schleife.
• ForeignApi brauchst du eher nicht, da du auf den fremden Wikis nicht mit Token arbeitest, sondern eine simple query machst – um dich mit Token wie ein lokal eingeloggter Benutzer zu verhalten, dessen Anmelde-Cookie zu nutzen, würdest du mit ForeignApi arbeiten müssen.
• Alternativ zu einem winzigen volatilen alert-Fensterchen stünde der Aufbau einer Unterseite von Special:Blankpage in einem neuen Browser-Tab.

VG --PerfektesChaos 10:19, 12. Mär. 2017 (CET)

Danke für die Ideen zu der Darstellung; ich werde sie bei Gelegenheit einmal durchexerzieren. Es ist vornehmlich copy & paste, daher meine Frage :-).

(Drei kleine Erklärungen: 1. Mein Gedanke bei dem separaten Aufruf von mw.loader.using() für oojs-ui-windows war (und ist), so wenig Code wie möglich zu laden; das heißt, wenn keine Dialogbox ausgegeben werden muss, brauche ich den Speicher nicht mit der Bibliothek zu belegen. 2. Die Idee hinter wgNamespaceIds ist, den Code auch in einem Jahr noch lesen zu können; ich muss die Zahlen immer nachschlagen, und wenn ich zwischen dem Kommentar „2 = Benutzer:“ oder selbsterklärendem JavaScript wählen kann, nehme ich letzteres. 3. Ohne mediawiki.ForeignApi erzeugt a = new mw.Api({ ajax: { url: 'https://en.wikipedia.org/w/api.php' } }); a.get( { action: 'query', list: 'allpages', apprefix: 'Tim.landscheidt', apnamespace: 3 }).done( function( data ) { console.log( JSON.stringify( data ) ); } ).fail( function () { console.log( JSON.stringify( arguments ) ) } ); einen Fehler: "Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf https://en.wikipedia.org/w/api.php?action=query&format=json&list=allpages&apprefix=Tim%2Elandscheidt&apnamespace=3. (Grund: CORS-Kopfzeile 'Access-Control-Allow-Origin' fehlt)." Ehe ich diese auch noch händisch einfüge, kann ich auch direkt die dafür gedachte Funktion nehmen.)

Mein Kernproblem war die Frage, wie man das „Ende“ feststellt (Herunterzählen & Co.); ich bin jetzt bei:

    mw.loader.using( [ 'mediawiki.api', 'mediawiki.ForeignApi' ] ).done( function () {
        var api = new mw.Api();
        api.get( {
            action: 'query',
            meta: 'globaluserinfo',
            guiprop: 'merged'
        } ).done( function ( data ) {
            var p = [];
            var r = [];
            data.query.globaluserinfo.merged.forEach( function( element, index, array ) {
                let url = element.url;
                if (url === 'https:' + mw.config.get('wgServer'))
                    var remoteapi = new mw.Api();
                else
                    var remoteapi = new mw.ForeignApi( url + '/w/api.php' );
                [mw.config.get('wgNamespaceIds').user, mw.config.get('wgNamespaceIds').user_talk].forEach( function( element, index, array ) {
                    p.push( remoteapi.get( {
                        action: 'query',
                        list: 'allpages',
                        apprefix: data.query.globaluserinfo.name + '/',
                        apnamespace: element
                    } ).done( function (data2) {
                        for( var j = 0; j < data2.query.allpages.length; j++ )
                            r.push( url + '/wiki/' + data2.query.allpages[j].title );
                    } ).fail( function () {
                        console.log( 'FAIL = ' + JSON.stringify( arguments ) );
                    } ) );
                } );
            } );
            $.when.apply($, p).done( function () {
                mw.loader.using( 'oojs-ui-windows' ).done( function () {
                    OO.ui.alert( 'All results: ' + r );
                } );
            } ).fail( function () {
                mw.loader.using( 'oojs-ui-windows' ).done( function () {
                    OO.ui.alert( 'FAIL!' );
                } );
            } );
        } );
    } );

gelandet. Damit werden alle Promises, die von den mediawiki.api.get()-Aufrufen kommen, in ein Array gesteckt und dann mit $.when() auf deren gemeinsame Erfüllung (oder den Fehler einer einzelnen) gewartet. Wenn jemand Ideen hat, wie man die Abfragen sequentiell hintereinander ausführen kann, immer her damit. --Tim Landscheidt (Diskussion) 14:21, 13. Mär. 2017 (CET)

• Das .fail() unterstellt, dass noch eine Antwort kommt, wobei eigentlich nach 30 Sekunden ohne Antwort sowas ausgelöst werden müsste.
  • Gleichwohl ist das kein sehr sicheres Verfahren, und da du um die Hundert API-Abfragen gleichzeitig losschießt, kann ein lahmes Netzwerk, ein überforderter Browser oder sonstwas die ausdrückliche Rückantwort verweigern.
• Als Kommentar für 2, 3 würde // BNR+BD ausreichen; mit deinem Konstrukt, das im Inneren einer Schleife jedes Mal sehr umständlich die deutschsprachige WP fragt, welche Nummern die Namensräume für user und user_talk hätten, hast du mich dafür für zehn Minuten ins Grübeln geschickt.
• Den alert() per OO.ui musst du bei der beabsichtigten Ergebnisanzeige deinem Benutzer in jedem Fall zeigen; entweder du präsentierst Ergebnisse, oder eine Fehlermeldung. Auf das übersichtliche vorherige Anfordern aller Ressourcen zu verzichten (ich mache auch öfters lazy loading) hat hier deshalb keinen Sinn. Es würde sonst die Situation eingeplant sein, dass du den Anwender benachrichtigungslos auf das nicht endende Skript starren lässt.
• Deine Konstruktion spielt Alles-oder-Nichts; wenn von 50 Wikis eines grad nicht rechtzeitig antworten mag, ist nur begründungsloser Totalschaden.
• Wenn du Netzwerkblockaden (keine Wiki-Limits, du fragst ja unterschiedliche Wikis nur zweimal) vermeiden möchtest, brauchst du nur nach Eintreffen beider Resultate des aktuell analysierten Wikis zwei Anfragen an das nächste Wiki zu richten; wobei die Kette abbräche, wenn eines verweigert. Dagegen würde ein wiederum komplexeres TimeOut helfen, das mit dem nächsten Wiki beginnt, wenn beide Ergebnisse eingetroffen sind (oder gefehlt hätten, was auch eine Antwort wäre) oder 3000 Millisekunden verstrichen wären.

VG --PerfektesChaos 14:53, 13. Mär. 2017 (CET)

Lupenfunktion für große Bilder (vor allem Landkarten)

Liebe Wiki-Techniker,

ich habe eine Idee, wie man ggf. den Wunsch „Mit Maus verschiebbare große Grafik“ (→ „Dauerbaustellen“) elegant anders lösen könnte:

In etlichen Webshops wird für Abbildungen eine Lupe zum Vergrößern der Ansicht angeboten. Wenn man sie auswählt und damit über das Bild in Kleinformat fährt, bekommt man in einem PopUp-Fenster einen Ausschnitt des Bildes in Originalgröße angezeigt. Das wäre doch eine hervorragende Lösung für große Karten, um nicht zu Commons (oder zu meiner „Hilfslösung“ wie etwa bei Vegetationszone) wechseln zu müssen und gleichzeitig bei der Ansicht die Legende immer im Blick behalten kann. Hier ein Beispiel aus einem Webshop, dass meinen Vorschlag sicherlich sofort verständlich macht: Lupenfunktion auf Bild.

Ich bin sehr gespannt auf eure Meinungen und Kommentare! Gruß --Fährtenleser (Diskussion) 12:33, 16. Mär. 2017 (CET)

Wie ich die hiesigen Pappenheimer kenne, ist die Idee bestimmt nicht neu, es hatte halt noch keiner Lust sie zu programmieren. Aber ich lasse mich gerne überaschen.... 129.13.72.198 12:36, 16. Mär. 2017 (CET)

Hat noch niemand sonst diesen Beitrag gesehen? Ich würde mich über eine Rückmeldung freuen! --Fährtenleser (Diskussion) 19:32, 22. Mär. 2017 (CET)

Ich lade das Bild (bei Bedarf) herunter und öffne es mit der Windows-Vorschau; damit kann ich nach Belieben zoomen. Bei Landkarten Screenshot machen und in der Vorschau zoomen ... :D --ProloSozz (Diskussion) 16:42, 25. Mär. 2017 (CET)

Das ist zwar nett, aber doch keine Wiki-Lösung! Dabei kannst du die Legende nicht sehen und musst etliche Schritte vollführen, die viele User überhaupt nicht können/kennen. Meine Frage bleibt offen: Wie wäre es mit einer Lupenfunktion? --Fährtenleser (Diskussion) 07:19, 27. Mär. 2017 (CEST)

Hat noch niemand außer ProloSozz diesen Vorschlag gesehen? Er würde den Informationswert von großen Landkarten beträchtlich erhöhen! Wo sind die Profis? --Fährtenleser (Diskussion) 12:27, 4. Apr. 2017 (CEST)

Katastrophale Basteleien beim "internen Benutzermenü"

Seit ein paar Tagen erscheint beim "Benutzermenü" (MonoBook-Darstellung, allerorberste Zeile rechtsbündig) nach dem eigenen Benutzernamen ein mehrfach verschachtelt übereinandergelegter Buchstabensalat. Zu lesen ist noch: "0 MeldXXXXXXXXXXXXXXXXXXXXXXion" (die XXX sind übereinandergelegte Buchstaben); sprich: "0 Meldungen", "Mitteilungen (0)" und "Diskussion" liegen derart übereinander, dass nur gerade "0 Meld..." und "...ion" gelesen werden kann (danach kommen noch Einstellungen, Beta, Beobachtungslisten, Beiträge und Abmelden). Bitte wieder les- und klickbar herrichten; danke. --ProloSozz (Diskussion) 16:33, 24. Mär. 2017 (CET)

Dies ist erst die zweite Meldung eines Benutzers, aber unter WD:NEU#Icons fehlen? ist bereits ein Abschnitt, wo das Problem besprochen wird. Der Umherirrende 16:46, 24. Mär. 2017 (CET)

Ist ein anderes Thema (möglicherweise desselben Themas). Offen gesagt: mir sind Icons eigentlich völlig egal; aber was nicht brauchbar ist, sind übereinandergelegte Darstellungen. Insofern ist das hier wie dort nicht ganz dasselbe --ProloSozz (Diskussion) 02:02, 25. Mär. 2017 (CET)

Das Problem ist, das anstelle der Icons die Texte angezeigt werden. Das bei der Anzeige der Texte diese überlappen ist sicher nicht gewünscht, aber bei den meisten Benutzern fällt dieses nicht auf, da die Icons dargestellt werden. Was aber bei allen auffällt, ist das man "Diskussion" nicht überall anklicken kann, da die Texte überlappen aber unsichtbar sind. Der Umherirrende 08:57, 25. Mär. 2017 (CET)

OK; aber liesse es sich nicht einrichten, dass einfach die Textworte aneinandergereiht werden (rechtsbündig), wenn der Text und nicht die Icons angezeigt werden? Die ganze Zeile sollte doch auf einem 800 Pixel breiten Bildschirm noch platz haben (möglicherweise sogar innerhalb 640 Pixel; in 1024 hat das auf jeden Fall platz). --ProloSozz (Diskussion) 12:18, 25. Mär. 2017 (CET)

Momentan sind zwei unsichtbare Links vorhanden (anstatt des übereinandergelegten Texts) ... --ProloSozz (Diskussion) 17:22, 31. Mär. 2017 (CEST)

Bearbeitungsproblem

Hallo, habe seit heute das Problem, dass bei Bearbeitungen nicht der "Signier Link" oberhalb des Bearbeitungsfeldes angezeigt wird. (Hier wird er aber angezeigt) Hinweise zu diesem Problem:

• bei der Bearbeitung der Kondolenzliste für Dr. Küppers wurde heute erstmals das Problem bemerkt.
• dort wurde die erste Bearbeitung abgebrochen und dann eine kleine Bearbeitung zur Überprüfung bei dem Lemma Graf-Adolf-Straße durchgeführt. Der Signier Link fehlte dort auch, aber nach "Bearbeitung Speichern" wurde diese mit meiner Signatur richtig verarbeitet und angezeigt.
• Danach wurde versucht die Kondolenzliste zu bearbeten, dies ging aber schief und wurde von 2 Wikipedianer zum Glück sofort korregiert.
• Dann wurde über die Diskussionsseite von "Ittig" der Fehler diskutiert. Hier war der Signier Link vorhanden
• Dann wurde im Lemma Graf-Adolf-Straße überprüft, ob bei der Bearbeitung mir der Signier Link wieder angezeigt wird. Dies ist immer noch nicht der Fall.

Was läuft da bei mir falsch, dass der Signier Link bei meinen Bearbeitungen zur Zeit nicht angezeigt wird? Danke vorab für evt. Hilfe für das Problem. --Urdenbacher (Diskussion) 18:47, 24. Mär. 2017 (CET)

Seit 13. August 2015 wird der Signatur-Button nur noch auf Diskussionsseiten angezeigt. Es liegt also kein Problem bei deinem Bearbeitungsfeld vor. Auf Hilfe:Signatur#Unterschreiben findet du ein Weg, wie doch eine Signatur gesetzt werden kann. Der Umherirrende 19:33, 24. Mär. 2017 (CET)

Danke für die schnelle Antwort. Mein obiger Hinweis zur Bearbeitung eines Lemmas war zwar überflüssig, da die ja grundsätzlich nicht manuell signiert werden, allerdings ist damit Problem bei der Kondolenzliste, die nicht signiert werden konnte, damit weiterhin unklar. --Urdenbacher (Diskussion) 19:42, 24. Mär. 2017 (CET)

Die Kondolenzliste liegt auf einer Benutzerunterseite, also nicht im Diskussionsnamensraum und dadurch gibt es kein Signierbutton. Warum bei der Ergänzung eines Eintrags alles entfernt wurde, kann ich nicht beantworten. Auch nicht was auf Itti's Diskussionsseite passiert ist. Der Umherirrende 19:50, 24. Mär. 2017 (CET)

Nochmals Danke für die Infos. Der Fehler bei der Bearbeitung der Kondolenzliste war, dass die Verwendung der Benutzerseite des Betroffenen übersehen wurde und deshalb die Signierung nicht manuell vorgenommen wurde. Der Fehler auf Itti's Diskussionsseite wurde ebenfalls durch eine falsche Bearbeitung von mir verursacht. --Urdenbacher (Diskussion) 10:14, 25. Mär. 2017 (CET)

Unkategorisierte Commons-Bilder mit Verwendung in Wikipedia-Kategorien

Hallo zusammen, haben wir irgendwo ein Tool, mit dem ich Bilder finden kann, die auf Commons nicht kategorisiert sind, aber in hiesigen Artikeln verwendet werden, die sich innerhalb einer hiesigen Kategorie oder einer ihrer Unterkategorien befinden? Falls nicht: Hätte jemand Lust, etwas in dieser Richtung zu basteln? Danke und Gruß, --Flominator 22:23, 29. Mär. 2017 (CEST)

Generell ein Petscan-Job.

Nur: Bilder, die auf Commons nicht kategorisiert sind, lassen sich damit nicht finden.

Jedoch die Commons-Hausmeisterei hat sicher irgendeinen Bot, die alle Vorlagen, die noch nicht inhaltlich kategorisiert wären, täglich in eine Wartungskat einsortiert.

Und Petscan & Co. können dann mit etwas Glück vermutlich solche Bildeinbindungen mit dieser Commons-Wartungskat finden.

LG --PerfektesChaos 22:45, 29. Mär. 2017 (CEST)

Dafür sollte sich die folgende Commons-Kategorie zum Verschneiden eignen: Category:Media needing categories. Yellowcard (D.) 00:10, 30. Mär. 2017 (CEST)

Ich habe das mal in mein Artikel bezogenes Script aufgenommen (welches ich hier auf eine andere Anfrage erstellt hatte, betroffene Bilder bekommen im Artikel einen farbigen Rahmen, je nach Problem eine andere :-)). -- User: Perhelion 00:40, 30. Mär. 2017 (CEST)

@PerfektesChaos: Kann PetScan Wikipedia und Commons verschneiden? Wäre mir zumindest neu. --Flominator 08:26, 30. Mär. 2017 (CEST)

• Ich schrieb ja auch „& Co.“.
• Kat-Einträge gehen wohl in den Millionenbereich.
• Etwas Ähnliches machen:
  • toollabs:glamtools/glamorous
  • toollabs:glamtools/glamorous.php
• Ein fertiges Tool habe ich auf Wikipedia:Technik/Labs/Tools nicht gefunden, kenne mich aber nicht so aus.
• Wäre eine sinnvolle und vermutlich eigenständige Anwendung, um Commons beim Aufarbeiten unkategorisierter Bestände zu helfen.
• PetScan schneidet zurzeit nicht cross-wiki; wäre ein Lösungsansatz für zukünftigen Ausbau.
  • Wobei unsere Bildeinbindung selbst ja nicht kategorisiert wäre.
• Oder separates Tool, das die intern hinterlegte Commons-Wartungskat (nebst dessen Unterkat) mit einer Projekt-ID und deren lokaler Themenkat (nebst deren Unterkat) verschneidet.
  • Berechnung könnte eine Weile dauern.
    • Für alle Einträge in Wartungskat + Unterkat
    • das GlobalUsage des angefragten Projekts filtern
    • und alle dortigen Trefferseiten filtern, ob sie in angefrager lokaler Themenkat +Unterkat auftreten.
  • Es ist eine realistische Mutmaßung, dass Bilder, die in unsere Artikel im Katbaum zu „Zürich“ eingebunden sind, auch etwas mit „Zürich“ zu tun hätten, und ein hiesiger Zürich-Fan dann auf Commons hausmeistert und die dortige Themenkatstruktur um Zürich herum kennen würde und per crowdsourcing nachkategorisiert.
    • Vielleicht findet der Heimatliebhaber auf diese Weise noch ein paar Bildchen, die schon lange in den eigenen Artikeln fehlten.
• Wäre eher was für ein Commons-Forum als uns hier.
• Fa. Manske baut sowas in Serie und hat alle Komponenten am Lager.

LG --PerfektesChaos 10:08, 30. Mär. 2017 (CEST)

@Magnus Manske: Lässt sich das vielleicht irgendwie über "Other sources" in Petscan bewerkstelligen? Danke und Gruß, --Flominator 10:45, 30. Mär. 2017 (CEST)

Angemeldet bearbeiten

Hallo, habe seit heute morgen das Problem, dass ich, so bald ich angemeldet bin, nichts mehr bearbeiten kann. Die Ikons für die Mitteilungen und Meldungen sind weit nach unten gerutscht und erst darunter kann ich Links öffnen. Sehr ärgerlich - hatte heute nämlich Zeit für eine Artikelanlage. Es funktionierte sowohl beim Rechner auf Arbeit als auch zu Hause nicht ... Hat jemand eine Idee?? -- 78.55.103.80 18:02, 31. Mär. 2017 (CEST)

Vermutlich der gleiche Fehler wie dort. --Diwas (Diskussion) 18:34, 31. Mär. 2017 (CEST)

Besten Dank! Genau das Prob. war es. Konnte mit den Tipps von dort das monobook ändern. Leider herrscht in der Zeile Meldungen / Mitteilungen immer noch Chaos - dafür funktionieren alle Links wieder. Sehr sehr ärgerlich das man vor der Änderung nicht einen Testlauf mit div. Browsern durchgeführt hat ... Grüße -- Proxy (Diskussion) 19:08, 31. Mär. 2017 (CEST)

Dieser Abschnitt kann archiviert werden. FriedhelmW (Diskussion) 21:10, 28. Apr. 2017 (CEST)

Wappen aus Wikidata einbinden

Die {{Infobox Gemeinde in Deutschland}} hat eigentlich schon seit einigen Jahren für das Wappen einen Wikidata-Fallback, nur war der bislang so implementiert, dass er im Regelfall auch ohne Wappen nicht funktioniert hat. Ich habe das jetzt mal repariert und dreimal schlägt es tatsächlich an, siehe Kategorie:Wikipedia:Seite verwendet P94. Bloß funktionieren die Wappeneinbindungen, obwohl syntaktisch IMO korrekt, nicht, sondern werden als Text dargestellt (Beispiel: Appel). Sieht so aus, als ob der Parser den Wikitext nicht mehr als solchen interpretiert. Kann man da was machen oder ist das einfach softwarebedingt? Danke, Yellowcard (D.) 19:00, 5. Apr. 2017 (CEST)

Jetzt passt es. --FriedhelmW (Diskussion) 20:09, 5. Apr. 2017 (CEST)

Jaja, das war die Ursache, denn die Kat war der Vorlage:Infobox Verwaltungseinheit in Deutschland übergeben worden; als Bezeichner einer Mediendatei.

• Dort war sie zwar unsichtbar, sprengte aber die Syntax der Medieneinbindung.

Die Kategorisierung muss aber wieder rein.

• Und die entsprechende Logik sollte tunlichst außerhalb der Einbindung von Vorlage:Infobox Verwaltungseinheit in Deutschland passieren.

Nebenbei bemerkt ist für solche Fragen eher die Partnerwerkstatt VWS zuständig, aber wir hier kämen notfalls auch damit klar.

LG --PerfektesChaos 20:17, 5. Apr. 2017 (CEST)

Habe die Kategorie wieder eingebaut. --FriedhelmW (Diskussion) 20:28, 5. Apr. 2017 (CEST)

Klasse, ich danke euch! Hatte das Problem größer und beim Parser vermutet, daher hier. Yellowcard (D.) 23:00, 5. Apr. 2017 (CEST)

Das habe ich ja damals (relativ unbedarft) eingebaut, allerdings hatte ich gedacht, dass sich das wesentlich schneller durchsetzt. Ich habe wohl noch andere Vorlagen damit bestückt (wo es funzt). Ich nehme mal an die sollen auch diese Kat bekommen. -- User: Perhelion 23:11, 5. Apr. 2017 (CEST)

@Perhelion: Ja, ich denke, diese Kategorien sollten überall gesetzt werden. Es gibt dieses Meinungbild zum Thema, das aber nur verlangt, dass die Vorlage selbst in Kategorie:Vorlage:verwendet Daten aus Wikidata einsortiert sowie dass die Daten aus Wikidata in eine entsprechende CSS-Klasse gepackt werden (Letzteres macht bei einem Wappen allerdings wenig Sinn). Diese Kategorie, um die es hier ging, kategorisiert den Artikel selbst; das war nicht gefordert, aus Beobachtungs-Zwecken (wie entwickelt sich die Datenübernahme aus Wikidata?) aber sehr sinnvoll. Das ist aber bisher eher bei einer Minderheit der Vorlagen umgesetzt. Wenn Du die anderen Orte noch findest, wo Du das eingefügt hattest, wäre es sicher nicht verkehrt, sich das dort auch nochmal anzuschauen. Yellowcard (D.) 11:46, 6. Apr. 2017 (CEST)

Die sind dann wohl unter der von dir genannten Kat schon gelistet und konkret auch hier: Benutzer:Mabschaaf/WD-Nutzung in deWP (Stand 2005). -- User: Perhelion 15:01, 6. Apr. 2017 (CEST)

Suchergebnisse von Schwesterprojekten

Hallo,

Im September 2016 schrieb das Discovery Search Team der Wikimedia Foundation hier bereits, um die Anfangsarbeit am Anzeigen anderer Wikimedia-Projekte in den Suchergebnissen zu diskutieren. Das Team wird bald die letzten Code-Aktualisierungen basierend auf dem jüngsten A/B-Test einfließen lassen und dann diese Änderung auf den Servern für alle verfügbar machen. Diese Aktualisierung zeigt einzig und allein eine Vorschau von Resultaten von den Wikimedia-Schwesterprojekten in der Seitenleiste der Suchergebnisseite an. Es ist geplant diese Änderung Ende April 2017 auf allen Wikipedias freizuschalten.

Weiteres Testen wird beschrieben (in englischer Sprache) auf der Seite Cross-wiki Search Result Improvements/Testing. Falls Du diese zusätzlichen Suchergebnisse vorher selbst testen möchtest so ist dies möglich. Weitere Informationen zu diesem Projekt sind verfügbar. Wir freuen uns auf diesen nächsten Schritt in der Wikipedia-Suche und begrüßen Rückmeldungen und Kommentare.

Danke, CKoerner (WMF) (Diskussion) 23:56, 6. Apr. 2017 (CEST)

PerfektesChaos, Guten tag. Sie sind hier aktiv. Ist das der richtige Ort für diese Nachricht? Sollte es verschoben in Wikipedia:Projektdiskussion werden? Ich möchte dafür sorgen, dass die Menschen sich dieser Veränderungen bewusst sind. Danke. CKoerner (WMF) (Diskussion) 18:51, 21. Apr. 2017 (CEST)

@CKoerner (WMF): Basically, this workshop (technical village pump) is a good starting point for announcements.

However, I assume low attention by German community.

Apparently this does no harm, would just populate the search result page a bit. Therefore I am not sure how much authors feel a need to get involved in advance.

I do not see a German translation of the linked project page. If any available, a short notice might link from the German Signpost (‘right column’), called “Wikipedia:Kurier”. Most German speakers can read English, at least get a flavour of the contents if an important matter touched, but only a limited number would be able and willing to comment.

Greetings --PerfektesChaos 19:25, 21. Apr. 2017 (CEST)

Regulärer Ausdruck zur Vorlagenauswertung

Hallo! Gibt es einen regulären Ausdruck zur sicheren Ermittlung von Vorlagenparametern aus dem Wikitext? Mit diesem Ausdruck möchte ich aus dem Wikiquelltext genau den Parameterinhalt von Beispielparameter aus der eingebundenen Vorlage Beispielvorlage ermitteln – auch, wenn dieser Parameter wiederum eine Vorlage enthält. Hat da jemand was zur Hand? Yellowcard (D.) 23:51, 8. Apr. 2017 (CEST)

Ich glaube nicht dass das möglich ist. --FriedhelmW (Diskussion) 00:02, 9. Apr. 2017 (CEST)

Das einzige Problem wäre wohl, bei zwei geschlossenen geschweiften Klammern zu erkennen, ob es das Ende der Vorlage (und damit des Parameters) ist oder ob es bloß das Ende einer Vorlage innerhalb des Parameters (wonach der Parameter ja weitergehen könnte) ist, oder? Zumindest, wenn man die Anzahl der geöffneten und geschlossenen geschweiften Klammern zählt, müsste man das doch hinbekommen können. Yellowcard (D.) 02:43, 9. Apr. 2017 (CEST)

1. Du wirst hier kein Paar geschweifter Klammern zu sehen bekommen, weil diese Ausdrücke bereits ausgewertet worden sind, wenn der Parameterwert an die aufgerufene Ebene übergeben wird.
   • Zumindest für den allgemeinen Fall hast du keine Möglichkeit festzustellen, auf welche Art und Weise ein Parameterwert zustandekam.
2. Nebenbei bist du mal wieder in der falschen Werkstatt.

LG --PerfektesChaos 13:28, 9. Apr. 2017 (CEST)

Mir geht es um den reinen Wikitext, auf den ich einen regulären Ausdruck anwenden möchte. Da wurde noch nichts ausgewertet. Was die Werkstatt angeht: Entschuldige bitte, wo muss ich denn hin? Yellowcard (D.) 15:15, 9. Apr. 2017 (CEST)

Auskunft? Prinzipiell ist das möglich mit regulären Ausdrücken, die Rekursion erlauben, aber (a) ist das ziemlich exotisches Zeug und (b) ist das oft extrem ineffizient. Es gibt in diversen Programmiersprachen Parser, die den Quelltext auswerten können. --mfb (Diskussion) 15:17, 9. Apr. 2017 (CEST)

• Hmm, dann müsstest du deine Fragen schon präziser formulieren.
• Es gibt keinen regulären Ausdruck, sondern nur rekursives Parsen über Funktionen.
• Die Geschichte ist hochkomplex, muss außerdem drei Klammern hintereinander für potenzielle Vorlagenparameter sowie nowiki und Kommentare berücksichtigen. Ich hatte rund ein Vierteljahr gebraucht, bis es halbwegs störungsfrei lief.
• WSTM.w.template.fold() in Zeile 818; ruft sich rekursiv selbst auf.

LG --PerfektesChaos 15:44, 9. Apr. 2017 (CEST)

Dankeschön! Yellowcard (D.) 15:49, 9. Apr. 2017 (CEST)

@Yellowcard: (war ein BK mit PC, meine Antwort geht in eine völlig andere Richtung - aber vielleicht habe ich auch die Frage falsch verstanden. Da ich es aber eh schon getippt habe, kann ich auch speichern, bitte ggf. einfach ignorieren.) Suchst Du das einmalig oder für häufigere Auswertungen? Einmalig kann Dir sicher Benutzer:Cactus26 weiterhelfen, der Dir von einer konkreten Vorlage alle Einbindungen mit allen Parameterwerten als Excel-Tabelle (bzw. .csv) liefern kann. Giftpflanze hatte dafür auch mal ein Tool geschrieben, das sich mit https://tools.wmflabs.org/giftbot/parsetemplates-getcsv.fcgi?template=xxx (Ersetze xxx durch den Vorlagennamen) aufrufen lässt, aber dahingehend etwas buggy ist, dass es offenbar manchmal nicht alle Einbindungen auflistet oder sogar abstürzt - vor allem, wenn die Vorlage häufig verwendet wird. Ein Versuch ist es aber vielleicht wert. In Excel kannst Du dann natürlich mit den dort verfügbaren Funktionen suchen.--Mabschaaf 15:52, 9. Apr. 2017 (CEST)

Na, wenn es nur darum ginge, dann kann ja mal jemand darauf hinwirken, dass in toollabs:templatetiger die dewiki nicht mehr die praktisch einzige mit Stand 2015 ist, während fast alle anderen Februar 2017 haben. LG --PerfektesChaos 15:59, 9. Apr. 2017 (CEST)

Wäre definitiv kein Fehler!

Für mein Verständnis sollten die Entwickler Cirrus dahingehend erweitern, dass man Suchausdrücke auf konkrete Vorlagen&Parameter anwenden kann. Aber das wird sicher noch ein Weilchen dauern...--Mabschaaf 16:05, 9. Apr. 2017 (CEST)

Vielleicht kann Kolossos was dazu sagen? Yellowcard (D.) 16:27, 9. Apr. 2017 (CEST)

Der Templatetiger kann reguläre Ausdrücke: Wikipedia:WikiProjekt_Vorlagenauswertung#Reguläre_Ausdrücke. Bezüglich der Aktualisierung von dewiki werde ich nochmal hinterher telefonieren. Ansonsten gäbe es ja auch noch den MediaWiki Parser from Hell. --Kolossos 22:07, 10. Apr. 2017 (CEST)

MediaWiki Parser from Hell habe ich schon benutzt, funktioniert prima. --mfb (Diskussion) 00:31, 11. Apr. 2017 (CEST)

@Yellowcard: Weil Mabschaaf mich oben angepingt hat: Wenn Du eine konkreten Wunsch hast für Vorlagenverwendungen in Form einer Datei (Trennzeichen Tab) hast (die sich in Excel o.ä. weiterverarbeiten lässt, brauchst Du Dich nur bei mir melden. Zu Deiner Ursprungsfrage: Ob so etwas möglich mit regulären Ausdrücken, hängt konkret von der Regex-Implementierung ab. Mein "Parser" ist nämlich keiner, denn er verwendet Regex und nutzt sogenannte Balanced Constructs um Schachtelungen abzuhandeln, siehe [14]. (Damit lässt sich auch der mir bekannte "Nested-Worstcase", die Vorlage {{Klade}}, beherrschen. Andere Regex-Implementierungen bieten mW ähnliche Konstrukte an, um Schachtelungen abhandeln zu können. --Cactus26 (Diskussion) 14:18, 11. Apr. 2017 (CEST)

@Kolossos, Mfb, Cactus26: Vielen Dank für euren Input. Es ging mir bei der Ursprungsfrage nicht um einen konkreten Anwendungsfall, sondern eher um ein allgemeines Gedankenkonstrukt, bei den Artikeln innerhalb einer Kategorie live einzelne konkrete Vorlagenparameter auszulesen. Solange die Menge an zu durchsuchenden Artikeln klein genug ist, sollte das in der Theorie möglich sein. Ob das mit Hilfe eines Parsers oder eines regulären Ausdrucks geschieht, ist mir am Ende dabei fast egal. Der MediaWiki Parser from Hell ist sehr interessant und kommt dem, was ich suche, sehr nahe. Weiß jemand, ob es das auch für PHP gibt? Letztendlich macht der MediaWiki Core ja auch nichts anderes, benutzt aber eben PHP. @Cactus: Welche Sprache nutzt du für deine Regex? Und, was Dein Angebot bzgl. der Datei angeht, schicke ich Dir eine Wikimail. Danke nochmal in die Runde, Yellowcard (D.) 14:31, 11. Apr. 2017 (CEST)

Die MediaWiki-Software is Open Source, im Prinzip kannst du den Parser dort nutzen. Ob das mit vertretbarem Aufwand geht, ist eine andere Frage. Falls du eine verwendbare PHP-Umsetzung findest, wäre ich an der auch interessiert. --mfb (Diskussion) 15:18, 11. Apr. 2017 (CEST)

@Yellowcard: Ich nutzte .NET und C#.--Cactus26 (Diskussion) 06:41, 12. Apr. 2017 (CEST)

Exzellent-Auszeichnung

Hallo zusammen, aktuell scheint in allen exzellenten Artikeln das grüne Sternchen rechts oben nicht angezeigt zu werden, stattdessen nur der Text: "Dies ist ein als exzellent ausgezeichneter Artikel." Wurde da geschraubt oder ist das Hamster(heu)schnufen?--Mabschaaf 20:03, 11. Apr. 2017 (CEST)

• Linkservice: Vorlage:Exzellent, genehmes Beispiel: Argon.
• Vorlage zuletzt vor bald einem halben Jahr (durch mich) bearbeitet.
• Für mich sieht das auf Vector völlig normal aus.
• Falls die Icon-Grafik commons:File:Qsicon Exzellent.svg vom Server nicht rausgerückt wurde, was bei dir persönlich ja der Fall gewesen sein mag, erscheint dieser Text in deinem Browser.
  • 2014-02-22T21:58:16 Optimized, auch schon ein paar Wochen her.
  • SVG-Inkompatibilität, persönliche SVG-Konfiguration, SVG im Browser darstellen statt PNG?

LG --PerfektesChaos 20:29, 11. Apr. 2017 (CEST)

• Ich habe an meinen Einstellungen nichts geändert, gestern war das Sternchen noch da (weiß ich zufällig genau)
• Ich bin nicht alleine.
• Auch da gibt es noch ein Problem, wobei ich nicht abschätzen kann, ob das die gleiche Ursache hat oder mit dem dort genannten Phab-Task zusammenhängt, denn das konnte ich nicht reproduzieren.
• Falls es interessiert: FF 52.0.2, Monobook.--Mabschaaf 21:23, 11. Apr. 2017 (CEST)

• Soweit ich Phab überflogen habe, gibt es Probleme mit den unterschiedlichen Servern, die PNG-Zubereitungen bereitstellen.
  • Das kann erklären, warum das bei unterschiedlichen Leuten unterschiedlich aussieht; wir werden von verschiedenen Servern bedient, je nach IP oder so.
  • Du hast dann wohl eine beschädigte oder genullte Dateiversion in deinem Browser-Cache.
• Ein Klick hierdrauf bringt dir eine Seite mit dem Exzellent-PNG.
  • Dieses dann reloaden (Ctrl+F5) sollte dir nur diese URL neu machen, statt deinen gesamten Browser-Cache zu leeren; wer weiß, was dann alles nicht geht.
  • Falls du dann immer noch Neumond siehst, ist halt Pech.
• Ansonsten was für Server-Experten.
• Gibt sich im Lauf der Tage.

LG --PerfektesChaos 22:09, 11. Apr. 2017 (CEST)

Klick+Reload hat geholfen, vielen Dank. Leider bin ich nicht der Nabel der Welt - ich könnte auch ohne Sternchen leben. Ich denke da mehr an unsere Leser. Und für die ist es schon ärgerlich, wenn verschiedentlich Bilder nicht ausgeliefert werden.--Mabschaaf 23:05, 11. Apr. 2017 (CEST)

Tabelle

Ich möchte in der Tabelle (Erfolge) von Marie Lang (Kickboxerin) einen neuen Erfolg von 2017 eintragen. Wenn ich jedoch die selben Zeichen eingebe, wie auch 2016 verschiebt sich die gesamte Tabelle. Was mache ich falsch. bzw. kann mir jemanden das Jahr 2017 in der Tabelle eingeben.Danke --CM (Diskussion) 15:01, 14. Apr. 2017 (CEST)

CM, schau jetzt mal. Grüße --Diwas (Diskussion) 16:19, 14. Apr. 2017 (CEST)

Bei 2016 stand ein rowspan=5 also fünf Zeilen wurden verbunden (Hilfe:Tabellen#Verbundene Tabellenzellen). Da es 2016 aber nur drei Einträge gab, war zwei Zeilen für 2017 mit 2016 verbunden. --Diwas (Diskussion) 16:30, 14. Apr. 2017 (CEST)

@Diwas: Klasse da wäre ich nie darauf gekommen! Vielen Dank --CM (Diskussion)

Sätze ohne Einzelnachweise finden

Citation Hunt English screenshot

Gibt es ein Tool, das Satzteile hervorheben kann, die nicht von einem Einzelnachweis erfasst werden? Unter der Annahme, dass EN hinter/vor einer bestimmten Zeichenkombination immer bis zu einer dazu festgelegten anderen Zeichenkombination gelten. Die Unsitte von EN für ganze Abschnitte oder gar irgendwelche auffainanderfolgenden Sätze muss selbstverständlich nicht unterstützt werden. False-positives wären dabei auch nicht schlimm, da es ja nur für menschliche Betrachter wäre. --nenntmichruhigip (Diskussion) 12:13, 20. Apr. 2017 (CEST)

Ja, User:Nenntmichruhigip, und das Tool ist richtig super: citationhunt! (Die deutsche Übersetzung könnte man vielleicht noch etwas polieren, die englische Version ist cooler) --Atlasowa (Diskussion) 11:11, 26. Apr. 2017 (CEST)

Ich meinte etwas anderes: Ich habe einen bestimmten Artikel, bei dem viele Sätze nicht oder unklar belegt sind, dazwischen aber auch viele belegte Sätze stehen. Da lässt sich über den ganzen Artikel schlecht überblicken, was belegt ist und was nicht. Also will ich in diesem einen, kompletten Artikel belegte Sätze z.B. durch einen grauen Hintergrund markieren oder andersrum unbelegte z.B. durch einen gelben.

Für einen Artikel könnte man das notfalls auch mittels Bildbearbeitung oder ähnlichem machen (für die älteren: wie mit einem Textmarker), aber ich würde das eigentlich gerne auch den Hauptautor des Artikels (der evtl leichter seine Quellen wiederfindet als jemand anderes) sehen lassen, und vermute, dass soetwas auch bei weiteren Artikeln gelegentlich nützlich wäre. --nenntmichruhigip (Diskussion) 16:41, 27. Apr. 2017 (CEST)

Google Pie Chart

Gibt es die Möglichkeit, Google Pie Chart zumindest auf Benutzerseiten zu verwenden? --Jobu0101 (Diskussion) 13:44, 20. Apr. 2017 (CEST)

Wenn sie niemand außer dir selbst sehen soll, ja. LG --PerfektesChaos 13:49, 20. Apr. 2017 (CEST)

Nee, sollen schon alle sehen. Du spielst auf die common.js an? --Jobu0101 (Diskussion) 17:26, 20. Apr. 2017 (CEST)

• Wenn wir Google-Software aus unseren Seiten heraus einbinden würden, dann wüsste Google, wer welche Wiki-Seite liest, mit welcher IP und welchem nahezu eindeutigem Browser-Profil.
  • Das würden wir mit Scherheit nicht machen.
  • Allerdings gibt es hier Wege, das zu vermeiden.
• Wenn ein beliebiger Besucher deiner Seite eine externe Software verwenden müsste, gleich welche, auch standardmäßig nicht geladene von MediaWiki selbst, dann müssten wir jede der über zehn Millionen deWP-Seiten während der Darstellung durchsuchen, ob sich darin etwas aus einer Liste fände, das noch nachgeladen werden müsste.
  • Das werden wir auch nicht machen.

LG --PerfektesChaos 15:21, 22. Apr. 2017 (CEST)

Statistische Auswertung der Position von Einzelnachweisen

Hallo zusammen, hat jemand eine Idee für eine Methode, mit der man "einmalig" zählen könnte, wie viele Artikel <references vor == Literatur == oder == Weblinks == stehen haben und wie viele dahinter? Damit ließe sich die hier genannten "gefühlten 95% der Artikel" verifizieren. Danke und Gruß, --Flominator 11:38, 24. Apr. 2017 (CEST)

Dumps durchsuchen. Vermutlich nur ein paar Zeilen in Python. --mfb (Diskussion) 17:02, 25. Apr. 2017 (CEST)

Untergrenzen (!):

• "insource:/references.*= ?Weblinks ?=/" findet 11.557 Artikel mit references vor Weblinks,
• "insource:/references.*= ?Literatur ?=/" findet 2.205 Artikel.
• "insource:/= ?Literatur ?=.*references/" findet 197.522 Literatur vor references,
• "insource:/= ?Weblinks ?=.*references/" findet 333.521 Artikel mit Weblinks vor references. :--mfb (Diskussion) 17:09, 25. Apr. 2017 (CEST)

@Mfb: Vielen Dank für die Auswertung. Was genau meinst du mit "Untergrenzen"? Gruß, --Flominator 22:11, 25. Apr. 2017 (CEST)

Es meint, dass die Cirrus-Suche nicht alles findet, sondern bei einer Drittelmillion abschaltet wegen Zeitüberschreitung (nur RegExp).

Die großen Zahlen >100.000 sind zu niedrig, die kleinen fünfstelligen glaubwürdig.

• Es gibt knapp 1,1 Millionen references und knapp 1 Million „Einzelnachweise“.
• Nach obigem gibt es 700.000 mit references ohne „Weblinks“ und 800.000 mit references ohne „Literatur“ – das glaub ich nicht.

LG --PerfektesChaos 22:20, 25. Apr. 2017 (CEST)

insource:Weblinks insource:references liefert 817.140 Treffer, das ist realistisch.

„Weblinks“ ist im Unterschied zu „Literatur“ ein WP-typischer Begriff, der im ANR eigentlich nur im Kontext von Abschnitttsüberschriften auftritt.

Daraus folgt:

• references → Weblinks: 11.557
• Weblinks → references: 800.000

VG --PerfektesChaos 10:10, 26. Apr. 2017 (CEST)

Echo-Funktion problematisch

Weiß einer hier, warum es so oft Fehler bei der Anwendung der ping-Vorlage bzw. bei der Anwendung des Benutzernamens als Link zur Benachrichtigung. Es geht wohl um die Echo-Funktion.

1. Spezial:Diff/164908753/next

   hier wurde kein Ping ausgelöst

2. Spezial:Diff/164924444/next

   hier aber dann doch

Meiner Meinung nach habe ich in beiden Fällen keinen Fehler gemacht. Warum hat Echo beim ersten Fall nicht funktioniert. Und da ich relativ oft die Ping-Vorlage nutze, fällt mir so was natürlich auf, und es kommt täglich vor. Ich denke, hier liegt ein Bug in der Echo-Funktion vor, oder seht Ihr das anders? Für Eure Antworten schon mal jetzt danke, – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 10:02, 26. Apr. 2017 (CEST)

Du musst einen neuen Absatz starten. Der erste Edit hat einen vorhandenen Absatz erweitert. --mfb (Diskussion) 15:14, 26. Apr. 2017 (CEST)

@Mfb: auch das kann nicht die Lösung sein. Spezial:Diff/164925586/next war auch kein neu gestarteter Absatz, und hat prima funktioniert. Und sowas hab ich auch schon x-mal gemacht, fast immer funktioniert das Echo. Andersrum funktioniert das Echo ab und zu auch nicht, wenn ich unten dran einen neuen Absatz starte. Hier ist also was anderes im Busch. – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 21:53, 26. Apr. 2017 (CEST)

Wie sicher bist du dir, dass im neuen Beispiel Echo ausgelöst wurde? Ich sehe zwischen den beiden Beispielen jedenfalls kein Unterschied. --mfb (Diskussion) 00:21, 27. Apr. 2017 (CEST)

@Mfb: In den Einstellungen > Benachrichtigungen habe ich "erfolgreiche Erwähnung" angekreuzt. Dass die Erwähnung erfolgreich war, wird mir dann in den Meldungen angezeigt, und ich weiß dann sofort bescheid. – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 01:00, 27. Apr. 2017 (CEST)

Fehlende Version in Datenbank

Hallo zusammen, ich lasse von meinem Bot zur Sicherheit die Versionen der Seite Benutzer:FNBot/Danke/OptIn überprüfen, ob sich der Benutzer tatsächlich selbst dort eingetragen hat. Heute ist da allerdings eine sehr merkwürdige Unregelmäßigkeit aufgetreten. Wenn ich auf Labs in der Tabelle dewiki_p.revision die folgende Abfrage tätige, wird die letzte Bearbeitung von Benutzer Aatwork einfach nicht angezeigt:

select rev_id,rev_user_text,rev_comment from revision where rev_page=9557870 order by rev_id desc limit 10

Ich habe absolut keine Ahnung woran das liegt. Habt ihr eine Idee? Viele Grüße --FNDE 16:31, 26. Apr. 2017 (CEST)

Am Repro-Lag? Yellowcard (D.) 17:08, 26. Apr. 2017 (CEST)

Das laggt doch nicht über Stunden, oder? --FNDE 17:29, 26. Apr. 2017 (CEST)

Die höchste rev_id auf Labs ist derzeit 164931358, siehe Special:Diff/164931358, von kurz nach um eins. -- hgzh 18:29, 26. Apr. 2017 (CEST)

Oh, krass? Was ist da denn los? --FNDE 22:39, 26. Apr. 2017 (CEST)

Keine Ahnung was da los war, jetzt sind wir jedenfalls wieder einigermaßen aktuell. -- hgzh 23:39, 26. Apr. 2017 (CEST)

Danke dir. Hätte nicht gedacht, dass es ein "globales" Problem war. Beste Grüße --FNDE 00:15, 27. Apr. 2017 (CEST)

Hab einen Befehl gefunden, mit dem man Lags in Sekunden anzeigen kann:

SELECT lag FROM heartbeat_p.heartbeat where shard="s5" (für dewiki)

Momentan hängen wir noch 7 Stunden hinterher. --FNDE 14:19, 27. Apr. 2017 (CEST)

@FNDE: aus dem channel #mediawiki-databases:

17:33 < doctaxon> what's going on here, 7 hours
                  lag for a long time now:
17:33 < doctaxon> MariaDB [dewiki_p]> select lag
                  from heartbeat_p.heartbeat
                  where shard='s5';
17:33 < doctaxon> +-------+
17:33 < doctaxon> | lag   |
17:33 < doctaxon> +-------+
17:33 < doctaxon> | 24727 |
17:33 < doctaxon> +-------+
17:33 < doctaxon> 1 row in set (0.02 sec)
17:33 < marostegui> doctaxon: we are fixing it
17:33 < jynus> doctaxon, there is maintenance
               ongoing
17:33 < jynus> it was announced

– Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 19:37, 27. Apr. 2017 (CEST)

seit 19:53 soll die Replikation wieder laufen. Kann aber noch einige Stunden dauern, bis der Lag aufgeholt ist. Hintergrund: es wurde der Datenbank die neue wb_terms table term_full_entity_id hinzugefügt. – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 20:10, 27. Apr. 2017 (CEST)

hm, nee, die haben doch noch Probleme ... – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 21:19, 27. Apr. 2017 (CEST)

Danke Doc! Meinen Aufzeichnungen nach geht es seit Punkt 18:00 Uhr wieder runter mit den Lags, dürfte bis Mitternacht erledigt sein, die Hälfte wurde schon wieder abgebaut. --FNDE 21:28, 27. Apr. 2017 (CEST)

Was mich trotzdem interessieren würde: wo haben die das denn angekündigt? --FNDE 21:30, 27. Apr. 2017 (CEST)

Vllt [Labs-announce], oder wikitech-I oder sowas? Hab jetzt keine Mail finden können.Btw, das Replag gibts auch online, hier: https://tools.wmflabs.org/replag/. Viele Grüße, Luke081515 23:05, 27. Apr. 2017 (CEST)

Danke Luke! Ich versuch dich ja gefühlt seit Monaten im IRC wieder zu treffen ;-) Das replag-Tool hatte ich auch gefunden, zeigt für dewiki aber falsche Werte an. Momentan haben wir nämlich keins mehr, man muss da schon konkret nach s5.labsdb schauen. Die Mail-Listen hatte ich rudimentär mal durchgeschaut aber keine Anhaltspunkte gefunden, auf wikitech gabs so eine mysteriöse Unterseite, wo db-maintenance angedeutet war. Wenn ihr eine Idee habt würde ich es cool finden, wenn wir sowas das nächste mal in den Tech-newsletter drücken, so kam das jetzt doch etwas überraschend :)) Beste Grüße --FNDE 23:21, 27. Apr. 2017 (CEST)

@FNDE: Das Lag ist aktuell abgebaut, die haben aber geschrieben, dass es durchaus die nächsten Tage zu weiteren Lags kommen kann. Möglicherweise kam das Announcement über eine Mailing List, ich habe zwar die labs-l Mailinglist, anscheinend ist diese aber die falsche dafür, denn da kam darüber nichts. Liebe Grüße, – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 07:10, 28. Apr. 2017 (CEST)

Danke Doc, heute gabs für 45 Minuten offenbar wieder Probleme, aber hat sich deutlich schneller abgebaut als gestern. --FNDE 22:13, 28. Apr. 2017 (CEST)

Fenster rechts

Ich bräuchte für ein JS die Funktionalität, die mir erlaubt, rechts dieses abgerundete Kästchen erscheinen zu lassen, was diverse Skripte und Komponenten verwenden, um den BenutzerInformationen zukommen zu lassen, konnte sie aber gerade nicht finden. Wenn mir jemand einfach sagen könnte, wo ich Informationen dazu finde, wäre ich demjenigen sehr dankbar. --MGChecker – (📞| 📝| ) 16:26, 1. Mai 2017 (CEST)

Dürfte mw.notify sein, siehe mw:ResourceLoader/Core modules#mediawiki.notify. Gruß, -- hgzh 17:52, 1. Mai 2017 (CEST)

Vielen Dank, das war mir eine große Hilfe! Vielleicht verbessere ich irgendwann auch nochmal die Dokumentation dafür ^^ --MGChecker – (📞| 📝| ) 11:17, 2. Mai 2017 (CEST)

liebe werkstatt

... Benutzer:Entlinkt machte mich darauf aufmerksam, dass ich mich an euch wenden soll.

es geht um meine monobook.js (Benutzer:Najadenn/monobook.js):

ich habe auch noch die arbeitssocke Benutzer:NBarchiv, und bei der funzt alles wieder genauso wie vor dem 29.04.

leider iss 'Benutzer Najadenn/:monobook.js' abhängig davon und müsste auch korrigiert werden, damit ich als Najadenn dieselben ergebnisse sehen kann (Mentoren, Ex-mentoren usw.)

könntet ihr bitte die Benutzer:Najadenn/monobook.js genauso fixen wie Entlinkt die Benutzer:NBarchiv/monobook.js gefixt hat? (ich musste ihm versprochen, nie wieder einen admin um sowas zu bitten!)

vielen dank im voraus. lg, ulli p. (--NBarchiv (Diskussion) 02:27, 3. Mai 2017 (CEST))

Du kannst nach Belieben Admins um Korrekturen in deinen *.js-Seiten bitten, es ist nur so, dass solche Eingriffe von einigen anderen Benutzern (ich meine Nicht-Admins) nicht besonders gerne gesehen werden.

Zur Sache: Hast du denn schon mal ausprobiert, ob mit dem Account Najadenn überhaupt noch Fehler auftreten? Meiner Meinung nach sollte bereits alles funktionieren, weil Najadenn die bereits korrigierten Seiten von NBarchiv einbindet.

Falls noch Fehler auftreten, wären die genauen Fehlermeldungen aus der JavaScript-Konsole (erreichbar meistens über die Taste F12) hilfreich. --Entlinkt (Diskussion) 02:45, 3. Mai 2017 (CEST)

...auweia! du hast natürlich vollkommen recht - reloaden iss angesagt...

iss mir alles super-peinlich. zeigt eigntlich nur, dass man ab einem gewissen alter die finger davon lassen sollte - man kann sich nur blamieren!

dir jedenfalls danke ich nochmals für deine geduld: die allein iss schon bewundernswert...

alles wieder paletti - dank Entlinkt!!

lg, ulli p. (--Najadenn (Diskussion) 03:30, 3. Mai 2017 (CEST))

(und jezz hab ich doch tatsächlich zum ersten mal nach fast zwei jahren einen "nicht-ANR"-edit unter meinem benutzeraccount gemacht - strafe muss sein! ;-) )

Meine Skripte

Ich muss seit geraumer Zeit viele Seiten mehrfach neu laden, bis JavaScript geladen wird. Betrifft sowohl Wikipedia als auch Commons. Vermutlich hängt es mit Wikipedia:Technik/Skin/JS/Obsolet#April 2017 zusammen?! Kann bitte mal jemand in meta:User:Thgoiter/global.js und c:User:Thgoiter/common.js schauen, ob da was problematisch ist? Alles nur mit Copy & Paste zusammengebastelt ohne tieferes Hintergrundwissen. Danke --тнояsтеn ⇔ 10:27, 3. Mai 2017 (CEST)

Ich guck mal rein, sobald ich dazu komme. Mehr auf deiner BD. LG --PerfektesChaos 11:08, 3. Mai 2017 (CEST)

„Wenn irgendwo etwas steht, das mit mw.util anfängt, dann muss auch irgendwo etwas von mw.loader.using('mediawiki.util') stehen.“

– Benutzer:Schnark: in WP:FZW#Skripte

Das ist bei deinen Skripten nicht so. Ohne nennenswerten Sachverstand grüßt --Nfreaker91 23:27, 3. Mai 2017 (CEST)

Mit minimalem Sachverstand: Wenn es manchmal funktioniert und manchmal nicht, dann deutet das auf eine Race Condition hin, was bedeutet: Es wird ein Modul verwendet, ohne sicherzustellen, dass das Modul vorher auch geladen wurde. (Manchmal ist das Modul zufälligerweise geladen, manchmal aber eben auch nicht.) In meta:User:Thgoiter/global.js sehe ich einen Abschnitt, der dafür verantwortlich sein könnte. Versuche doch mal, ob es hilft, den Teil

// Purge-Button
$( function() {
    if ( !$( '#ca-purge' ).length && mw.config.get( 'wgIsArticle' ) ) {
        mw.util.addPortletLink(
            'p-cactions',
            mw.util.getUrl( mw.config.get( 'wgPageName' ) ) + '?action=purge',
            mw.config.get( 'skin' ) == 'vector' ? 'Purge' : '*',
            'ca-purge',
            'Purge the server cache of this page',
            '*'
        );
    }
});

durch

// Purge-Button
mw.loader.using('mediawiki.util', function () { $(function () {
    if ( !$( '#ca-purge' ).length && mw.config.get( 'wgIsArticle' ) ) {
        mw.util.addPortletLink(
            'p-cactions',
            mw.util.getUrl( mw.config.get( 'wgPageName' ) ) + '?action=purge',
            mw.config.get( 'skin' ) == 'vector' ? 'Purge' : '*',
            'ca-purge',
            'Purge the server cache of this page',
            '*'
        );
    }
}); });

zu ersetzen. (Zwei Zeilen sind zu ändern.) Gruß --Entlinkt (Diskussion) 02:12, 4. Mai 2017 (CEST)

Inzwischen könnte man auch

$.when(mw.loader.using('mediawiki.util'), $.ready).done(function () {
//...
});

schreiben, was aber keinerlei Vorteil über ein (nach meinem Geschmack) etwas hübscherem Code hat. –Schnark 10:45, 5. Mai 2017 (CEST)

Die Änderung [15] scheint gut gewesen zu sein. Ich werde noch ein paar Tage testen, da auch zuvor nur sporadisch Probleme auftraten. --тнояsтеn ⇔ 22:15, 7. Mai 2017 (CEST)

TeX-Problem

Hallo, nach eingehender Besprechung weise ich hier mal entsprechend darauf hin, dass TeX bei der Verwendung von Umlauten ein wenig „spinnt“, wie man an der Formel in diesem Artikel sogar gleich zweimal sehen kann... Kann man denn da was machen? Wenn ja, müsste das dann wahrscheinlich global geschehen (→ Phabricator), oder?--Hubon (Diskussion) 05:39, 4. Mai 2017 (CEST)

Fehlermeldung bei Commons

Seit Kurzem erhalte ich bei Commons folgende JS-Fehlermeldung:

ReferenceError: addPortletLink is not defined [Weitere Informationen] index.php:5:10

Wenn ich rechts auf den Link klicke, wird die Zeile

addPortletLink('p-tb', 'javascript:AjaxQuickDelete.nominateForDeletionChem();', "Nom for del (chem)", 't-ajaxquickdeletechem', null);

in c:User:Leyo/del-chem.js markiert.
Kann da jemand helfen? Da das Script auch von anderen eingebunden wird, möchte ich mich nicht selbst daran „herumspielen“. --Leyo 22:35, 5. Mai 2017 (CEST)

Hallo Leyo, das ist einfach, da wohl eine lang angekündigte globale deprecated function entfernt wurde. Du solltest einfach mw.util davorsetzen, wie in deiner common.js. Sicherheitshalber auch das Modul dazu laden (evtl. Race Condition):

-mediaWiki.loader.using('ext.gadget.AjaxQuickDelete', function() {
+mediaWiki.loader.using(['ext.gadget.AjaxQuickDelete', 'mediawiki.util'], function() {

MfG -- User: Perhelion 23:38, 5. Mai 2017 (CEST) -- User: Perhelion 23:44, 5. Mai 2017 (CEST)

PS: Das Modul brauchst du wohl nicht extra laden da bereits durch Abhängigkeit der anderen geladenen Module bereit (AjaxQuickDelete). -- User: Perhelion 23:49, 5. Mai 2017 (CEST)

Danke, die Fehlermeldung ist verschwunden und die Links in der Toolbox wieder da. --Leyo 23:52, 5. Mai 2017 (CEST)

Dieser Abschnitt kann archiviert werden. Leyo 23:52, 5. Mai 2017 (CEST)

Edittools weg

unter Hilfe Diskussion:Symbolleisten wurde grade von jemand anderem auf ein JS-problem hingewiesen. die customToolbar.js (button-ergänzungen) ist die letzte zeit instabil gelaufen, funktioniert jetzt aber wieder, dafür tritt jetzt dieses problem seit 2 tagen auch auf. ich hab folgendes laufen (meine vector.js):

//========================= moveEditTools ===================================

// Benutzer:W!B:
// Ziel:    verschiebt die Edittools zur Toolbar
// 
function moveEditTools() {
     var editTools = document.getElementById('mw-editTools');
     editTools.parentNode.removeChild(editTools);
	if (!editTools) return;
     var toolbar = document.getElementById('toolbar');
       if (toolbar) {
         toolbar.appendChild(editTools)
       }
}
addOnloadHook(moveEditTools);

im quelltext steht nurmehr <div class="mw-editTools"><div id="mw-editTools"></div> und zwar weiterhin unterhalb editButtons (wpSave,wpPreview,wpDiff), unterhalb des bearbeiten-fensters, nicht bei meiner Toolbar oberhalb. hat die eine inkompatibilität? ist die ElementId('toolbar') abgeschafft worden? --W!B: (Diskussion) 13:27, 8. Mai 2017 (CEST)

hoppsla, jetzt grad ist sie wieder da, aber weiterhin unten. wird grad am server umgebaut? oder liegt es vielleicht an meinem firefox (zb noscript oder adblock) --W!B: (Diskussion) 13:31, 8. Mai 2017 (CEST)

Kann es sein, dass du die Option „Erweiterte Bearbeiten-Werkzeugleiste aktivieren“ ursprünglich nicht aktiviert hattest und sie kürzlich aktiviert hast? Das zur „erweiterten Bearbeiten-Werkzeugleiste“ gehörende Skript phab:diffusion/EWED/browse/master/modules/ext.wikiEditor.toolbar.js entfernt das Element mit der ID toolbar:

$( '#toolbar' ).remove();

Je nachdem, in welcher Reihenfolge die Skripte ausgeführt werden, kann das lustige Effekte ergeben.

Falls du die „erweiterte Bearbeiten-Werkzeugleiste“ nutzen möchtest, muss dein Skript so umgeschrieben werden, dass es den Selektor toolbar nicht mehr verwendet. Andernfalls würde es wohl ausreichen, die „erweiterte Bearbeiten-Werkzeugleiste“ wieder abzuschalten. Gruß --Entlinkt (Diskussion) 16:52, 8. Mai 2017 (CEST)