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)

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)

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)

Fehler bei dem Anchorjump nach dem Bearbeiten eines Abschnittes.

Hi,

ich war drüben[2] und habe woanders[3] 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 [4].
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)

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 [5]. 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 (1, 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)

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

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)

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)

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)

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)

Sonderzeichen

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

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)

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

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 [[10]] (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)

User:CKoerner (WMF): Any news on this? --тнояsтеn ⇔ 09:30, 11. Dez. 2017 (CET)

тнояsтеn I wish I had more to tell you. Leadership at the foundation is investigating what it would take to better support Maps. I hope to have more information early in the new year. CKoerner (WMF) (Diskussion) 22:58, 15. Dez. 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)

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)

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)

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)

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)

Herunterladen einer zweispaltigen pdf-Datei bei Artikel "Bankhaus Friedrich Schmid & Co." nicht möglich

Hallo, ausschließlich bei dem Artikel "Bankhaus Friedrich Schmid & Co." ist das Herunterladen einer zweispaltigen pdf-Datei nicht möglich. Ich habe es mit verschiedenen PCs und Einstellungen probiert. Es erscheint immer die Fehlermeldung: "Rendering fehlgeschlagen / Die Erstellung der Dokumentendatei ist fehlgeschlagen. / Status: Bundling process died with non zero code: 1" Wer kann Abhoilfe schaffen? Vielen Dank im Voraus und Grüße --Salisburgensis (Diskussion) 08:14, 30. Mai 2017 (CEST)

Wahrscheinlich niemand. OCG hat viele sehr aehnliche Fehlerberichte und wird soweit ich weiss von niemandem gewartet. Eine andere Software zum Erstellen von PDF-Dateien (namens Electron) ist in Arbeit. --Malyacko (Diskussion) 09:42, 30. Mai 2017 (CEST)

Danke! --Salisburgensis (Diskussion) 09:52, 30. Mai 2017 (CEST)

Wikipedia loggt Benutzer bei Seitenwechsel aus

Wenn ich mich bei Wikipedia einlogge, erscheint wie gewohnt mein Benutzername oben in der Statuszeile. Klicke ich anschließend auf irgendeinen Link und eine andere Wikipediaseite wird geöffnet, erscheint in der Statuszeile "nicht angemeldet". Ich kann mich dann zwar erneut anmelden, aber beim nächsten Wechsel auf eine andere Seite "vergisst" das System, dass ich bereits eingeloggt bin. Auch wenn ich beim Einloggen "Angemeldet bleiben" anklicke. Auch diesen Beitrag kann ich nicht eingeloggt abspeichern, weil das System mich beim Speichern ausloggt. Meine Browser (Firefox, Google Chrome) akzeptieren Cookies. Wo könnte der Fehler liegen? --gruhland

Du hast vermutlich einen sog. "privaten Tab" offen oder hast Cookies deaktiviert. Schau mal in den Einstellungen. --FNDE 14:38, 13. Jul. 2017 (CEST)

Siehe Wikipedia:Fragen_zur_Wikipedia#Anmeldung. Gruß --FriedhelmW (Diskussion) 14:56, 13. Jul. 2017 (CEST)

Umgang der Suchfunktion mit Umlauten

Hallo allerseits,

es gibt ein Problem mit der Suchfunktion, das kürzlich (wieder) unter WP:FzW#Wasserfälle aufkam:

Seit Cirrus ignoriert die Artikelsuche diakritische Zeichen - wozu auch die Punkte über Umlauten zählen. So führt zum Beispiel die Eingabe von Bälle auf die Seite Balle, direkt, ohne Umweg über die Volltextsuche. Dieses Verhalten ist auf deWP leider in praktisch allen Fällen sinnlos und in vielen Fällen störend, wie die Anfrage auf FzW zeigt. Dort wurde das Problem mit einer (regelwidrigen) Weiterleitung als Workaround gelöst, was aber nicht als flächendeckende Lösung taugt.

Hätte ein Bugreport Aussicht auf Erfolg, bzw. gibt es schon einen? Falls nein, gibt es eine Möglichkeit, dieses Verhalten auf deWP lokal abzuschalten? --Katimpe (Diskussion) 18:41, 17. Jul. 2017 (CEST)

Bessere Suchergebnisse erzielt man mit Google, z.B. mit der Eingabe Bälle site:de.wikipedia.org. Gruß --FriedhelmW (Diskussion) 19:58, 17. Jul. 2017 (CEST)

Das ist schon klar, es geht aber um die WP-eigene Suche. Die soll ja gelegentlich auch verwendet werden. --Katimpe (Diskussion) 20:55, 17. Jul. 2017 (CEST)

Hmmm. Das ist IMO kein einfach zu loesendes Problem. Wie man an meinen Beitraegen unschwer erkennen kann, benutze ich eine Tastatur ohne deutsche Umlaute. Da finde ich es richtig gut, dass die aktuelle Suchfunktion mir einzelne Buchstaben ersetzt. Und das gilt auch fuer anderssprachige Sonderzeichen, z.B. Jørgensen (findet die Suche per "Jorgensen"; koenntest Du, Katimpe, problemlos ein "ø" produzieren? - und, falls "ja", koennte das die Mehrheit der Benutzer?). Dass in Einzelfaellen sic! dabei auch "falsche" Ergebnisse erhalten werden stellt mMn kein echtes Ausschlusskriterium dar. Just $0.02 von -- Iwesb (Diskussion) 03:58, 18. Jul. 2017 (CEST) PS: Waere ein entsprechender Schalter unter "Einstellungen" moeglicherweise eine Loesung?

In meinen o.g. Beispielen gilt ja gerade das Umgekehrte: ä wird zu a, ø wird zu o und so weiter. Das braucht ganz sicher niemand. Und ansonsten:

• Jørgensen hast du nur über die Autovervollständigung gefunden, sonst wärst du auf Jorgensen gelandet. Das Problem besteht ja vor allem darin, dass man direkt auf den falschen Artikel geführt wird, wenn der richtige nicht existiert.
• Das Problem betrifft natürlich im Wesentlichen die Umlaute, mit denen der Durchschnittsbenutzer eben kein Problem hat. Aber auch für Zeichen wie ø haben wir bereits ein Instrument, es nennt sich Weiterleitung. Gäbe es Jorgensen nicht, würde man dort eine Weiterleitung auf Jørgensen einrichten. (btw, wieso muss ich dir das erklären?)
• Wie ich sehe, ersetzt du das ä nicht durch a, sondern durch ae, was ja auch allgemein üblich ist. Diese Funktion bietet die Software gerade nicht! Könnte man natürlich einrichten - bloß, die Community hat sich meines Wissens vor langer Zeit gegen solche Weiterleitungen entschieden. Aber darum geht es hier nicht.

Was auch immer das Verhalten der Suchfunktion für Vorteile haben mag, sie lassen sich durch Weiterleitungen genauso herstellen, wenn man das denn will. Was man in den Einstellungen einrichten kann, weiß ich nicht, es geht um das Standardverhalten. Und das mag für einen Anglophonen in dieser Form Sinn ergeben, in der deutschen Wikipedia ist es einfach nur fehl am Platz. --Katimpe (Diskussion) 05:08, 18. Jul. 2017 (CEST)

Hi everyone,

Sorry for replying in English, and for the very long message. I can get translation help if needed, but it will take a lot of time. I've been following the conversation with the help of Google Translate. Please forgive any misunderstandings.

There are multiple search-related issues here. I will try to identify them and explain them. Then maybe we can find the best course of action for each problem.

First, it is good to know that (1) searching from the input box in the upper right of the window (sometimes called the "Go" feature) and (2) full-text searching use different search methods with different language processing.

(1) The "Go" feature tries to match titles and does not break up words. If it cannot find an exact match, it will remove diacritics and try again. It actually does more than remove diacritics; it will also "fold" many Unicode characters into "simpler" or "more standard" characters. This includes removing diacritics, but also converting "ß" to "ss", Greek final sigma "ς" to regular sigma "σ", fullwidth numbers and letters "０１２ＡＢＣ" to "normal" halfwidth "012ABC", halfwidth CJK characters "ﾒ" to fullwidth "メ", and much more.

As a result, you can search in the "Go" (upper right) input box for ℬªɬĹɇ and you will land on the page Balle, because there is not page called "ℬªɬĹɇ". This is a more extreme case than Bälle taking you to the page Balle, but it is the same idea.

I believe that text processing for the "Go" feature is currently configured exactly the same on all wiki projects. It does not currently allow for customization.

(2) Full-text searching does language-specific processing of the text. This language-specific processing is provided by Elasticsearch and Lucene. These are the open-source technologies that CirrusSearch is built on. For many languages—like German, English, and French—we initially used with the language-specific processing provided by Elasticsearch without making any changes. We have customized English, French, and others, but German is using the original default configuration. The configuration for German full-text search could be changed. I would like to change it to include general character folding (except possibly ß, ä, ö, and ü), which the default language processing does not do. The extra folding in full-text search has been helpful on English and French wiki projects.

For whatever reason, the German language processing includes a step called "German Normalization" that does the following:* 'ß' is replaced by 'ss'

• 'ä', 'ö', 'ü' are replaced by 'a', 'o', 'u', respectively.
• 'ae' and 'oe' are replaced by 'a', and 'o', respectively.
• 'ue' is replaced by 'u', when not following a vowel or q.

This could be disabled, or possibly replaced with something different.

I often work on language-specific configuration changes. I have a general guideline that I use for configuring character folding for a given language: my first suggestion is that everything should be folded, except for characters used by the language of the project. So, in English projects, I would fold everything. In German projects, I would not fold ß, ä, ö, or ü, but I would fold å, é, î, ø, ÿ, all the letters in "ℬªɬĹɇ" and all the others. I would of course modify the list of exceptions based on feedback from German speakers!

There also seems to be some problem with the way that ß is treated by Elasticsearch that may make it difficult to treat it correctly in the near future. See phabricator ticket T87136 for more information.

I agree with Iwesb that in general character folding is a good thing, especially for characters that are hard to type. I support maximum character folding for titles, too. Redirects can solve a lot of problems, but they can't cover everything. Many pages don't have redirects without diacritics, and finding them would be a lot of effort that could be spent doing more productive things. It is also impossible to include every potentially useful redirect.

For example, there is an Icelandic band called Sigur Rós. I found a playlist of their music online, which spells the band name Sigür Ròs. Without character folding in the "Go" feature, this would not be a match.

The side effect of this is the situation with Balle/Bälle, and Wasserfälle/Wasserfall/Wasserfalle. I noticed that the Wasserfälle problem has been solved with a redirect. That makes perfect sense, because there isn't any other way to handle it.

Regardless of my preferences, if there is consensus that some set of letters (probably ß, ä, ö, and ü) should not be folded in either the "Go" feature search or in full-text search, I would be happy to try to implement those changes and see what the effect is.

Unfortunately, changing the "Go" feature would be more work and would take longer, because it would require adding the capability to configure how the "Go" feature does character folding. We already have the ability to do that for full-text search.

Because the changes would affect a lot of users, especially inexperienced users who don't have any knowledge of searching, or the Help Desk, etc., I would suggest reaching a consensus among a larger group of users. I don't see the German Wikipedia equivalent of an RfC, but there must be something similar.

I will check back and try to answer any questions or comments. TJones (WMF) (Diskussion) 19:19, 20. Jul. 2017 (CEST)

Benutzer:PDD/hideduplicatecontribs.js

… scheint nicht mehr zu gehen. Liegt es an mir (eingebunden über meta:User:Thgoiter/global.js) oder dem Skript von Benutzer:PDD? --тнояsтеn ⇔ 13:34, 31. Aug. 2017 (CEST)

Gadget search-new-tab funktioniert manchmal nicht

Das Gadget search-new-tab (gibt es das hierzuwiki echt nicht als in den Einstellungen aktivierbares Gadget?) fällt bei mir auf der Beobachtungslistenseite alle paar Tage mal spontan bis zum Neuladen aus. In der Fehlerkonsole, die ich jetzt extra offengelassen hatte damit wirklich nichts verloren geht, gibt es keinen Eintrag (oder höchstens mal „Diese Website verwendet anscheinend einen scroll-verknüpften Positionierungseffekt“, was damit aber nichts zu tun hat). Hat jemand eine Idee, wie man sonst noch herausfinden könnte, woran das liegt? --nenntmichruhigip (Diskussion) 14:25, 14. Sep. 2017 (CEST)

Im Quellcode steht folgender Kommentar:

According to Krinkle, gadgets don't have to wait using $(function() {... (only core stuff)

Diese Behauptung halte ich für falsch. Ich vermute dass das Gadget manchmal nicht funktioniert, weil es eben vor Document-Ready ausgeführt wird. Das $(function() {... würde genau das beheben. --Fomafix (Diskussion) 14:43, 14. Sep. 2017 (CEST)

Ich habe jetzt mal auf der Gadget-Disk nachgefragt und dabei Krinkle angepingt. --nenntmichruhigip (Diskussion) 20:19, 14. Nov. 2017 (CET)

Feld "Grund" in Special:Import hat ein Problem mit kaufmännischem Und-Zeichen

Hallo zusammen, keine Ahnung, ob es dazu schon etwas im Phabricator gibt, gefunden habe ich gerade nichts. Wenn ich einen Grund eingebe, der ein Und-Zeichen enthält, und dann auf "Datei hochladen" klicke, funktioniert der Import nicht, sondern ich lande wieder auf einer unausgefüllten Import-Seite. Gruß, --Flominator 18:16, 23. Sep. 2017 (CEST)

Klappt es mit &amp;? --mfb (Diskussion) 19:10, 23. Sep. 2017 (CEST)

weghüpfende Links auf die Wikidata-Interwikiübersicht

Unter der Liste mit Links zu einem gerade betrachteten Artikel „In anderen Sprachen“ gibt es einen weiteren Link in Grau, „Links bearbeiten“, der auf etwas in der Art https://www.wikidata.org/wiki/Q3573893#sitelinks-wikipedia führt. Das wäre manchmal ein sehr nützlicher Link, mit dem man einer unbekannten vielsprachigen Leserschaft ebendiese Liste von Wikipediaartikeln zu einem bestimmten Thema in allen verfügbaren Sprachen zukommen lassen könnte, wenn nicht am Ziel irgendetwas passieren würde (vermutlich per Javascript, ohne Javascript tritt das Problem nicht auf), was die Liste nach einem Moment aus dem Blickfeld springen lässt. Der Link wirkt dadurch nur verwirrend. Gibt es ein Gegenmittel?--Hanekomi (Diskussion) 18:48, 1. Okt. 2017 (CEST)

Da hilft höchstens ein Wechsel des Browsers. --FriedhelmW (Diskussion) 19:25, 1. Okt. 2017 (CEST)

Auch das wird nicht helfen: Das ist das bekannte Problem, wenn nachträglich die Seitenlänge geändert wird. Hierzuwiki eher von einklappenden Tabellen bekannt, sind es bei Wikidata die weiteren Sprachen der Itembeschreibung und die Bearbeiten-Links. --nenntmichruhigip (Diskussion) 15:23, 9. Okt. 2017 (CEST)

Menüleisten / Minerva

Hallo Technik-Werkstatt, ich bin recht neu bei Wikipedia und hatte das Problem, dass mir keine Menüleisten (oben, links) etc. angezeigt wurden (ihr könnt den Verlauf der Problemlösungsversuche etc. auf meiner Diskussionseite sehen). Der Laptop musste zur Reperatur und wir habe festgestellt, dass außer Minerva in allen anderen Ansichten, das Menü einwandfrei angzeigt wird. Vielleicht kennt Ihr das Problem? Die ITler haben ansonsten einen Scriptfehler vermutet. (nicht signierter Beitrag von Trudi64 (Diskussion | Beiträge) )

Was ist denn Minerva? -- Qt (Disk|Bilder|Autor) 13:08, 29. Okt. 2017 (CET)

Minerva ist der Skin der mobilen Ansicht. -- hgzh 15:44, 29. Okt. 2017 (CET)

Slideshow

Für den Artikel zum Atari 800 brauche ich eine Diashow, um den Aufbau des Computers zu verdeutlichenn. Das funktioniert mit dem Gallery-Tag auch, sieht aber ziemlich komisch aus:

1) Die Abstände zum Text oben und unten scheinen mir etwas zu groß.

2) Kann man die Position der Weiter-Pfeile < und > nicht an die Bildgröße darunter anpassen, so dass sie am rechten bzw. linken Bildrand liegen?

Gibt es vllt. sogar eine andere, etwas professioneller aussehende Alternative? Viele Grüße, Schnurrikowski (Diskussion) 12:35, 10. Nov. 2017 (CET)

MathJax Benutzerscript

Ich versuche gerade MathJax per Wikipedia-Benutzerscript Benutzer:Debenben/MathJax.js einzurichten (vgl. Hilfe_Diskussion:TeX#MathJax). Weiß jemand, wie ich es hinbekomme, dass Formeln mit Doppelpunkt-Einrückung :<math> automatisch als Blockformeln erkannt werden. Im Moment werden sie durch die Dollarzeichen als inline erkannt: inlineMath: [['$ ',' $']].--Debenben (Diskussion) 21:57, 11. Nov. 2017 (CET)

Quelltextbearbeitung teilweise in englischer Sprache

Bei der Quelltextbearbeitung steht unten teilweise (d.h. nicht immer) statt "Vorschau" "Preview" und statt "Änderungen" "Changes". Stört zwar nicht sehr, sollte aber bei Gelegenheit doch korrigiert werden. Mein Browser: Google Chrome, Version 62.0.3202.94 --Rita2008 (Diskussion) 11:53, 19. Nov. 2017 (CET)

Hast du das Wiki oder deinen Browser auf Englisch eingestellt? -- Freddy2001 ^DISK 20:46, 19. Nov. 2017 (CET)

Nein. Alles andere, auch links das "Änderungen veröffentlichen" erscheint ja in Deutsch und es passiert auch nicht immer. Übrigens habe ich inzwischen festgestellt, dass es nicht nur beim Google Chrome auftritt. --Rita2008 (Diskussion) 18:01, 22. Nov. 2017 (CET)

Become a Tech Ambassador today

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

Do you have a passion for technology? Do you enjoy supporting this community in things like figuring out software changes and communicating with the developers, or maybe you would consider doing it, but you don't know where to start?

The Community Liaisons team at the Wikimedia Foundation is looking for active tech ambassadors in this community. We would like to help make this volunteer role an attractive and low-barrier contribution path in our movement. You can add your name to the table on Meta, or you can let me know about someone else who should really, really be in that list.

Please, do not assume that you are not "fit", that you lack the skills, or the experience etc. If you have doubts, questions, etc., let's chat. Thank you for your attention! --Elitre (WMF) (Diskussion) 18:09, 29. Nov. 2017 (CET)

Absätze...

Hallo zusammen! Wie kommt es, dass in dieser Version der Abstand vor „In Zitaten wird sic in eckige Klammern gesetzt…“ kleiner ist als vor dem darauffolgenden Absatz beginnend mit „Die so gekennzeichnete Besonderheit“?--134.61.103.163 20:18, 4. Dez. 2017 (CET)

Entfernung von jQuery UI

Gemeldet in Phabricator
Task T49145

Dieses Modul soll (deprecated mit Priorität "Hoch"!) aus dem Core zugunsten von OOUI von Wikimedia verschwinden, wie seht ihr das? Nunja der Task ist schon 4 Jahre alt allerdings bekommt man erst jüngst die Depraction-Warnings (also vorher habe ich nichts von diesen Plänen mitbekommen). Ich persönlich empfinde das als Klaps ins Gesicht von Volunteer-Programmierern und das nicht weil alle User-Scripte dbzgl. aktuallisiert werden müssen. -- User: Perhelion 20:49, 14. Dez. 2017 (CET)

PS: Wikipedia has been taken over by marketing OOUI -- User: Perhelion 22:09, 18. Dez. 2017 (CET)

Positionskarte zeigt im mobilen Skin falsche Positionen, wenn die Bildunterschrift zu lang ist

Siehe Vorlage Diskussion:Positionskarte+#Kompatibilität mit Timeless Skin II, dort ist schon ein Korrekturvorschlag/Workaround von Benutzer:Slomox, bitte einen prüfenden Blick. Antwort gerne auch bei der Adminanfrage -- MBq ^Disk 11:20, 28. Dez. 2017 (CET)

Ausblenden des Sichtungshinweises auf der BEO

Hallo zusammen.

Bezug nehmend auf MediaWiki Diskussion:Flaggedrevs-watched-pending: Lässt sich über das eigene common.css der Kasten oben auf der BEO komplett abschalten? Der der da sagt: Es gibt momentan ungesichtete Bearbeitungen, die sich auf deiner Beobachtungsliste befinden. Es geht nur um die eigenen Einstellungen des jeweiligen Benutzers. Viele der anderen Kästen, Hilfehinweise usw. lassen sich ja auch ausblenden. Mit der Bitte um eine laientaugliche Antwort, ich habe von css wenig bis keine Ahnung. Danke und Gruß, --Druschba 4 (Diskussion) 02:45, 29. Dez. 2017 (CET)

In deine common.css die nachstehend bunt markierten Zeilen kopieren:

.fr-watchlist-pending-notice {
   display: none;
}

WP:CSS #Beobachtungsliste enthält mehr Infos.

дружба --PerfektesChaos 03:24, 29. Dez. 2017 (CET)

Большое спасибо, работает очень хорошо. Vorlage:Smiley/Wartung/:-)  Спокойной ночи, --Druschba 4 (Diskussion) 03:44, 29. Dez. 2017 (CET)

Wie bei den CentralNotices einen einfachen Schließbutton für Systemnachrichten und Vorlagen zu haben wäre schön. Ließe sich soetwas vielleicht entwickeln oder ist da überhaupt schon mal jemand drauf gekommen? Vorlage:Smiley/Wartung/;)  Ansonsten werden unsere zunehmenden Hinweise wohl vermehrt übersehen und es fällt am Ende nicht mehr auf, wenn auf etwas wichtiges hingewiesen wird. Gruß, --Wnme 19:23, 29. Dez. 2017 (CET)

Also ich frage mich echt was man dann überhaupt von der BEO will, wenn man so etwas ausblenden muss. Ich finde das Sichten das Mindeste was man hier tun kann/sollte, zudem frage ich mich wo diese Mini-Markierung stören soll. Missverständnis, bezog mich auf die einzelnen Edits. -- User: Perhelion 20:57, 29. Dez. 2017 (CET)

Wenn der Hinweis wenigstens klein wäre, aber so ein Monsterfeld mit ein bissl Text ist unnötig. -- Quotengrote (D|B|A) 12:08, 31. Dez. 2017 (CET)

Aja, das ist schon lustig und dem könnte man zustimmen, denn zum einen wird das "padding" dieser Box in unserer allg. MediaWiki:Common.css auf 0 gesetzt (by Entlinkt und vormals Raymond von default 3px) um dann von MediaWiki:Flaggedrevs-watched-pending (by Wnme, also lokaler Einstellung) ein extra DIV mit u.a. padding:10px; verpasst zu bekommen (das enthaltene P-Element hat auch noch mal padding). Ich glaube auch der Umherirrende könnte da etwas zu sagen bzw. helfen. Einen guten Rutsch allen. VG class="Vorlage_Kasten hintergrundfarbe2 rahmenfarbe1" style="border-style:solid; clear:both; padding:10px;"

PS: Nach diesem Gespräch, hatte die Box sogar mal zwei [Ausblenden/Verbergen] Button. Die dann wohl jetzt tatsächlich völlig fehlen. -- User: Perhelion 13:22, 31. Dez. 2017 (CET)

Das Padding beim Ausblenden (hier Transparent gemacht) muss auch auf 0 gesetzt werden, da sonst ein magischer Freier Bereich mit dem Padding entstehen könnte (so meine Vermutung). Ich kann mich nicht erinnern, ob es ein Ausblenden von der Software gab, habe aber Mangels Artikel auf der Beobachtungsliste den Kasten auch ausgeblendet. Der Umherirrende 21:00, 1. Jan. 2018 (CET)

Aja (mein vorherigen Statement habe ich gestrichen wegen kleinem Missverständnis), nur gibt es ja momentan keinen. Allerdings müsste dies wohl etwas Cookie-festes sein, wie der erwähnte Knopf beim Banner. Also ohne einer weiteren Extension oder Erweiterung der mw:Extension:FlaggedRevs wird es wohl nichts. -- User: Perhelion 11:56, 2. Jan. 2018 (CET)

Rendern zu PediaPress

Hallo Ich versuche seit einiger Zeit alle Seiten der BLS Triebfahrzeuge als Buch bei PediaPress drucken zu lassen. Aber das Rendern dieser Seiten will einfach nicht gelingen. Ich bekomme immer die Meldung es bestehe ein Fehler mit diesen Seiten. Andere Bücher funktionieren richtig, wie es sein soll. Was kann das sein, und wie kann man dieses Problem Lösen? Ist vielleicht eine Artikel-Seite defekt? Ich hoffe auf eine anwendbare Lösung. Mit freundlichen Grüssen, Herbert Häuselmann / Traktor-Katze (nicht signierter Beitrag von Traktor-Katze (Diskussion | Beiträge) 16:09, 8. Jan. 2018 (CET))

Service für nicht-Eisenbahner: Vermutlich sind Artikel aus Kategorie:Triebfahrzeug (BLS) gemeint. --nenntmichruhigip (Diskussion) 09:13, 11. Jan. 2018 (CET)

Wenn ich mich recht entsinne wurde PediaPress doch eingestellt? -- Quotengrote (D|B|A) 10:12, 11. Jan. 2018 (CET)

Auf Benutzer:Traktor-Katze/Bücher/BLS Tribfahrzeuge und Benutzer:Traktor-Katze/Bücher/BLS die Drite gibt es oben die Links "PDF" und "Gedrucktes Buch bestellen". Beides geht nicht und das ist wohl das Problem des Fragestellers. --тнояsтеn ⇔ 10:26, 11. Jan. 2018 (CET)

Ja genau, diese 2 Links gehen nicht. Und ausserdem geht es mit anderen Büchern, somit ist klar, PediaPress druckt diese Bücher auch noch! Ich stehe sogar in kontakt mit PediaPress und habe den Link per E-Mail zu ihnen geschickt. Mal sehen was da raus kommt. (nicht signierter Beitrag von Traktor-Katze (Diskussion | Beiträge) 18:23, 11. Jan. 2018 (CET))

sum_cat_disc.py hat ein Login-Problem

Wie bereits beim Betreiber DrTrigon angefragt, wirft sein Skript mit einem beliebigen Link momentan folgenden Fehler:

OperationalError: (1044, "Access denied for user 's51312'@'%' to database 's51312__u_s51312'")

DocTrigon scheint relativ inaktiv zu sein. Eine der Ideen hinter toollabs war es m.E., dass andere Benutzer als der Hauptentwickler Tools warten könnten. Geht das in diesem Fall? Wer kann das? Wo muss ich das einpipen? Danke und Gruß, --Flominator 19:30, 11. Jan. 2018 (CET)

Einige andere Tools von DrTrigon werden von Benutzer:AsuraBot aka Benutzer:sitic betrieben, aber letzterer ist auch seit über zwei Jahren inaktiv. Da muss man sich eigentlich wundern, dass der Bot nach so langer Abwesenheit noch funktioniert .... --Flominator 19:35, 11. Jan. 2018 (CET)

Nachdem ich gerade über https://tools.wmflabs.org/admin/tools gestolpert bin, setze ich mal einen verzweifelten Ping an Benutzer:FNDE und Benutzerin:Giftpflanze ab. Könnt ihr bitte mal schauen? Danke und Gruß, --Flominator 13:09, 25. Jan. 2018 (CET)

Timeless und Formatvorlage Bahnstrecke

Im Skin Timeless werden die Streckenbänder bei Bahnstreckenartikeln nach WP:FVBS unterbrochen dargestellt. Das liegt daran, dass dort Inline-Bilder nicht vertical-align: middle; erhalten. Was ist der richtig Ort, das zu beheben? Die Ergänzung von .bs-icon a img{vertical-align: middle;} in MediaWiki:Timeless.css? --nenntmichruhigip (Diskussion) 10:01, 18. Jan. 2018 (CET)

Meiner Ansicht nach ist phab:T183827 der richtige Ort dafür. –Schnark 10:05, 18. Jan. 2018 (CET)

+1

Muss ja nicht nur .bs-icon betreffen, sondern andere Themen genauso.

Wir könnten bis zur Lösung von T183827 eine temporäre CSS-Regel durch Admin bereitstellen, falls jemand den richtigen kollateralschadenfreien Selektor für img ausguckt.

LG --PerfektesChaos 10:41, 18. Jan. 2018 (CET)

Wo in MediaWiki talk:Common.css gerade Minerva erwähnt wurde hänge ich hier mal einen weiteren Darstellungsfehler in der FVBS mit der selben Frage („Wo beheben?“) dran: Mit dem Skin Minerva sind die div.bs-icon 0.6 px zu hoch. Mit kleineren Werten für font-size lässt sich das behoben, aber ohne Anpassung ist es genauso wie in Vector 100%; scheint also noch einen anderen Lösungsweg zu geben. --nenntmichruhigip (Diskussion) 11:03, 19. Jan. 2018 (CET)

Zeilenumbruch nach «schweizbezogen» vor einer Vorlage für Mouse-over notwendig

Kopie von Wikipedia Diskussion:Schweizbezogen#Zeilenumbruch nach «schweizbezogen»
Hallo, nach dem Hinweis «schweizbezogen» muss wohl ein Zeilenumbruch vor einer Vorlage erfolgen; sonst wird in der Mouse-over-Vorschau mit meinem Helferlein (vmtl. nicht dieses) nicht der Artikelanfang, sondern nur der Quellcode }} (= Ende der Vorlage?) angezeigt. Habe mit dieser einschlägigen Änderung eine funktionierende Vorschau auf die erste der hier aufgeführten Personen erreicht.
Ob das auf weitere Vorlagen oder auf Vorlagen insgesamt zutrifft, kann ich nicht sagen. Falls das so ist, wäre umseitig ggf. ein Hinweis auf eine notwendige Zeilenschaltung angebracht. Gruß, --Wi-luc-ky (Diskussion) 18:09, 23. Jan. 2018 (CET)

Deine Entdeckung trifft unabhängig der Infobox zu, jedoch seltsamerweise nicht bei allen Artikeln:

• hastemplate:Infobox_Alpiner_Skirennläufer insource:/schweizbezogen-->\{\{/
• hastemplate:Infobox_See insource:/schweizbezogen-->\{\{/
• hastemplate:Infobox_Stausee insource:/schweizbezogen-->\{\{/
• hastemplate:Infobox_Berg insource:/schweizbezogen-->\{\{/

Vielleicht ist das etwas für die TWS. --Leyo 18:39, 23. Jan. 2018 (CET)

Ende Kopie

Kann sich das Phänomen bitte mal noch jemand ansehen? Danke, --Wi-luc-ky (Diskussion) 19:04, 23. Jan. 2018 (CET)

• Zunächst müsstet ihr herausfinden, um welches Tool es eigentlich geht.
• Wenn „Navigation-Popups“, dann müsstet ihr euch direkt an die enWP wenden, per en:MediaWiki:Gadget-popups.js.
• Wenn die sogenannten „Hovercards“, dann kann die TWS maximal einen Phab-Bericht schreiben und in den richtigen Briefschlitz stecken.
• In jedem Fall braucht ihr eine tabellarische Analyse, in genau welchen Situationen immer genau was passiert und in genau welchen was nicht; und dazu möglichst zwischendurch nicht mehr umgestrickte Seiten, an denen einige Zeit später ein Entwickler das auch mit der aktuellen Seitenversion nachvollziehen kann.
• Grundsäzlich sollte ob Quelltextverständlichkeit der Kommentar auf einer eigenen, allerersten Zeile stehen.

VG --PerfektesChaos 19:18, 23. Jan. 2018 (CET)

Danke, Perfektes Chaos, es ist wohl die Hover-Card-Funktion. [Korrektur: das Navigation-Popups-Helferlein. --Wi-luc-ky.] (Vllt. kannst Du mal in meinem „Uhrwerk“ nachsehen. Kann bitte auch Leyo schreiben, mit welchem Tool er diese Fehler reproduzieren konnte.)

Vorläufige Zusammenfassung: Es gibt neben der „Normalvorschau“ drei Arten fehlerhaften Vorschauen, seltsamerweise bei anscheinend immer gleichem oder vergleichbarem Quellcode-Anfang:

1. Mouse-over zeigen nur → }}
2. Mouse-over zeigen → }} Text… (mit Leerzeichen!)
3. Mouse-over zeigen → }}Text… (ohne Leerzeichen!)

Fehlerverteilung in Beispielen:

A) in hastemplate:Infobox_Alpiner_Skirennläufer insource:/schweizbezogen-->\{\{/

mit Quelltext: <!--schweizbezogen-->{{Infobox Alpiner Skirennläufer

• alle Artikel
  • zu sehen ist nur → }}

B) in hastemplate:Infobox_See insource:/schweizbezogen-->\{\{/

mit Quelltext: <!--schweizbezogen-->{{Infobox See

alle Mouse-over zeigen nur }}, außer:

• Lago Sfundau
  • zu sehen ist → }} Der Lago Sfundau ist …(mit Leerzeichen!)

C) in hastemplate:Infobox_Stausee insource:/schweizbezogen-->\{\{/

mit Quelltext: <!--schweizbezogen-->{{Infobox Stausee

• Albignasee
  • zu sehen ist nur → }}
• Klöntalersee
  • zu sehen ist → }} Der Klöntalersee ist ein … (mit Leerzeichen zwischen }} und Text!)

(desgl. in Zervreilasee von Vorlage:Navigationsleiste Schweizer Speicherseen aus im Mouse-over; alle anderen dort o. k.)

weitere:

• Hochwasserrückhaltebecken Jonenbach
  • zu sehen ist nur → }}
• Gübsensee
  • zu sehen ist → }}Der Gübsensee ist ein … (ohne Leerzeichen!)

D) in hastemplate:Infobox_Berg insource:/schweizbezogen-->\{\{/

mit Quelltext: <!--schweizbezogen-->{{Infobox Berg

• Säntis
  • zu sehen ist nur → }}
• Finsteraarhorn, Dom (Berg), Piz Kesch, Ebenalp, Altels, Vilan, Sex Rouge (Les Diablerets), Oeschinenhorn, Albristhorn, Alp Sigel, Joderhorn, Trugberg, Schneehüenerstock, Sidelhorn, Almagellerhorn, Chli Bielenhorn, Pfyffe,
  • zu sehen ist → Das Finsteraarhorn ist … (normaler Text) usw.
• Gantrisch, Spechhorn
  • zu sehen ist → }} Der Gantrisch ist …usw.

hth, --Wi-luc-ky (Diskussion) 19:26, 25. Jan. 2018 (CET)

Bist du sicher, dass du mw:Hovercards meinst? Ich kann es nämlich mit Navpopups reproduzieren, mit Hovercards aber nicht. --nenntmichruhigip (Diskussion) 10:38, 26. Jan. 2018 (CET)

Du hast recht, Nenntmichruhigip, nach Ansicht auf den Hilfeseiten muss ich mich korrigieren: es ist das

• Navigation-Popups-Helferlein

bei mir in WP:Helferlein mit einem Häkchen versehen. Vielen Dank für Deine klärende Nachfrage. Gruß, --Wi-luc-ky (Diskussion) 11:06, 26. Jan. 2018 (CET)

Geändert werden müsste übrigens en:MediaWiki:Gadget-popups.js, da dieses im Gadget aufgerufen wird. --Leyo 17:18, 5. Feb. 2018 (CET)

ist /Editnotice kaputt?

Hallo! Seit einiger Zeit funktioniert bei Bearbeitungen auf Wikipedia:Bibliotheksrecherche/Anfragen die Editnotice Wikipedia:Bibliotheksrecherche/Anfragen/Editnotice nicht mehr. Weiß jemand was dazu? (Da Editnotice auf Benutzerseiten auch funktionieren soll, hatte ich es dort ebenfalls erfolglos ausprobiert.) – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 09:05, 26. Jan. 2018 (CET)

diese Änderungen durch den Hexer dürften der Auslöser sein. Gruß, -- hgzh 10:14, 26. Jan. 2018 (CET)

(BK)

Diesen Sinn unter Admins abklären und vor Veränderungen auf BETA erproben.

Ich verstehe den Sinn der Änderung nicht, halte sie für überflüssig, würde auf 2015 zurückkehren und Gegengründe wären erstmal zu benennen. Das Ziel dieses Manövers müsste zuallererst mal erläutert werden, in genau welcher Situation das wozu gebraucht würde.

VG --PerfektesChaos 10:19, 26. Jan. 2018 (CET)

Danke vielmals Vorlage:Smiley/Wartung/zwinker  – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 10:54, 26. Jan. 2018 (CET)

Wenn man in meine weiteren Bearbeitungen im MediaWiki-Namensraum an jenem Tag schaut, kann man zumindest Vermutungen äußern. Faktisch habe ich den Quelltext von Editnotice-0 übernommen und für den Namespace 4 angepasst. In der Tat sieht das allgemein nach sehr viel Geflickel aus, ohne dass es hier einen Standard gibt, der Einzelseiten wie Gruppen grundsätzlich berücksichtigt. Dies sollte ja jeweils schon ermöglicht werden, wenn es diese Funktionalität gibt und teils auch schon genutzt wird. Ich bin nicht der größte Experte, dies umzusetzen und es ist natürlich doof, wenn dann jetzt etwas kaputtgegangen ist. Faktisch dürfte es schon vorher kaputt (bzw. nicht nachhaltig gebaut) gewesen sein, sondern für Einzelfälle wie diesen hier angepasst. Wie setzen wir gemeinsam eine gute Grundlage für alle Namensräume und Fälle auf? Grüße, —DerHexer (Disk., Bew.) 23:46, 29. Jan. 2018 (CET)

• Erstmal stellt sich die Frage, inwieweit das für alle Namensräume in gleicher Weise erforderlich wäre, und wie häufig das benötigt würde.
  • ANR und Projekt-NR (aka 4=WP) haben hier eher Bedarf für Gruppen von Seiten.
  • Kategorie, Diskussionen, Hilfeseiten oder Vorlagen dann eher nicht.
  • Ob es also zwingend für alle NR eine einheitliche Lösung geben müsse, steht dahin.
  • Für den ANR hatte man sich einmal entschieden, einen Sonderweg zu gehen, abweichend von allen anderen Namensräumen. Nur Admins sollen Editnotice für einzelne Seiten (Artikel) definieren können, für alle anderen NR wäre das frei.
  • Siehe grundlegend Hilfe:Editnotice.
  • Bestandsaufnahme:
    • 238 beteiligt
    • 225 ANR-Einzelseiten
    • 1 Gruppe für ANR, 1 Versuch einer Gruppe für WPNR.
    • Ggf. Gruppenregeln in einzelnen NR-Definitionen (NR 2, 4, 4, 5, 8, 10, 100)
• Wenn man es heutzutage reorganisieren wollte, dann sicher mit Lua und mit beliebigen pattern für den Seitennamen.
  • Für jede Einzelseite (ggf. außer ANR) bleibt es bei der individuellen Unterseite, die jeder anlegen kann und die bei Bedarf Admin-Vollschutz bekommen mag.
  • Im ANR kann man davon abweichend oder übergangsweise die bisherigen automatisch vollgeschützten MediaWiki:-Seiten zusätzlich unterstützen. Vielleicht zusätzlich die Unterseite zulassen, ggf. mit heute möglichen Sichterrechten (wobei sowas wenige Beobachter hätte und im Suchmaschinenindex auftauchen würde bzw. von Suchmaschinen ausgeschlossen werden müsste, und ANR-Suchtreffer liefern kann) – es gibt aufgrund von Suchverhalten und wegen Vermengung enzyklopädischer Informationen mit internen Verwaltungsangelegenheiten durchaus Gründe, nicht alle Namensräume identisch zu behandeln.
  • Lua-Pattern und weitere Eigenschaften ermöglichen dann einen für alle NR einheitlichen Satz von Regeln, beliebige Eigenschaften des Seitennamens usw. heranzuziehen.
    • Also auch „endend auf /Doku“.
    • „Ist irgendeine Unterseite von …“ – die bisherige ANR-Gruppe sah nur die letzte direkte Quasi-Unterseite (ANR hat keine Unterseiten) vor.
    • „Name enthält Adolf aber nicht Hüttler“.
    • „Ist keine Unterseite endend auf /Editnotice“ (Standard-Regel, Trick-Effekt mit Link auf Hilfe:Editnotice)
    • „Hat Content Model css“
    • „Name enthält Adolf und ist dreiviertelgeschützt“
  • Die bisherigen Einzel-Regeln in den NR müsste man mal zusammentragen und untersuchen, ob noch sinnvoll.
  • Eine Seite kann aufgrund ihrer Eigenschaften mehrere Hinweisbausteine untereinander auslösen.
  • Alle Regeln für edit müssten sich vermutlich auch auf die Situation create anwenden lassen.
• Einen Lua-Code würde man in zwei vollgeschützte Module aufteilen; eine Programm-Einheit und eine Definition für edit (alle NR).
  Beispiel-Definition:

{ [0]   = { -- ANR ...
          },
  [4]   = { ["Wikipedia:Wikimedia Deutschland/Neue Ehrenamtliche/Onboarding/Geführte Touren/Trainingsmodule/*Editnotice"] =
                  { title = { ["/Geführte Touren/Trainingsmodule/[^/]+$"] = true }
                  }
          },
  [8]   = { ["Wikipedia:Technik/Skin/MediaWiki/Admin-Editnotice"] =
                  { contentmodel = { css = true,
                                     javascript = true }
                  }
          },
  [10]  = { ["Vorlage:Dokumentation/Editnotice Doku-Seiten"] =
                  { title = { ["/Doku$"] = true }
                  }
          },
}

• Bedeutung der Syntax:
  • Die Zahlen an Anfang sind Nummern der Namensräume. Jede öffnet eine Zuordnungstabelle.
  • Jede Zuordnungstabelle enthält genau die (beliebig untergebrachte) Seite, die den darzustellenden Wikitext enthält.
  • Dieser darzustellenden Seite ist ein Satz von Regeln zugeordnet.
  • Die Regeln können einschließend sein (true) oder ausschließend (false).
  • Zuerst werden auf die aktuelle Seite alle einschließenden Regeln angewendet, danach (sofern diese einen Treffer signalisierten) alle ausschließenden Regeln. Wenn dann immer noch im Rennen, dann wird die darzustellenden Seiteneinbindung dem Ergebnis hinzugefügt.
• Braucht ein wenig Reindenken, ist dann aber auch nicht schwieriger als bisher, wird ohnehin nur von einer Handvoll affiner Admins gepflegt. Dafür übersichtlich für alles.

• Weiteres Vorgehen:
  • Notiz hierher auf WP:A/N und HD:EDN.
  • Wiedervorlage im Februar.

VG --PerfektesChaos 03:15, 30. Jan. 2018 (CET)

Skriptwunsch

Moin,
Benutzer:Perhelion hat mich hierher geschickt bezüglich dieser Anfrage. Es geht um ein Skript, dass existierende Biografien in Artikeln hervorhebt, wenn sie nicht verlinkt sind. Kriegt das wer hin oder hat das schon wer? --Kenny McFly (Diskussion) 19:26, 31. Jan. 2018 (CET)

das könnte funktionsverwandt mit MediaWiki:Gadget-Rechtschreibpruefung.js sein. Man bräuchte ein Tool, das im Hintergrund die Biographienliste mit dem Artikeltext abgleicht. Bei über 600.000 Biographien dürfte das allerdings ziemlich lange dauern... -- hgzh 21:39, 31. Jan. 2018 (CET)

Und wie sieht es damit aus, dass ein Skript oder ein Bot das einmalig auf einer Unterseite zusammenträgt als Liste, die man dann abarbeiten könnte? --Kenny McFly (Diskussion) 21:58, 31. Jan. 2018 (CET)

Ob der Datenmenge müsste man sich mal über die Komplexität und Ressourcen klarwerden.

1. Skript
   • Offenbar die Idee bei „Skript … in Artikeln hervorhebt“
   • Das würde heißen, ein JavaScript würde im Browser beim Leser ablaufen.
   • Das würde bedeuten, in die momentane Wiki-Seite müsste bei jedem Seitenaufbau die Liste aller Biografie-Artikel geladen und dann abgearbeitet werden.
   • Naja, das sind an Rohdaten um die 12 MB; verteilt auf 1200 API-Aufrufe, mit Overhead an die 20 MB, bevor es losgehen kann.
   • Allerdings macht vorher der API-Server zu; wegen missbräuchlicher Absaugung.
   • Ich habe es noch nie ausprobiert, aber ein Skript mit diesem Datenvolumen sprengt vermutlich ein Hardware- oder Sicherheitslimit im Browser.
2. Nachdem fünf Minuten lang die API abgefragt wurde, so sie denn noch antworten würde, könnte die Textanalyse beginnen. Utopisch.
3. Labs/Tools
   • Das wäre der einzige Realisierungsweg zur Komplettabdeckung.
   • Man könnte in ein Tool einen Seitennamen eingeben, und das rödelt eine Weile und nennt dann eine Liste von Zeichenketten, die als unverlinkter Text vorkommen.
   • Wie hgzh richtig anmerkt, könnte dann in einem zweiten Schritt in der HTML-Seite nach diesen Zeichenketten gesucht und diese dann auch direkt farbig hervorgehoben werden.
   • Bei Labs/Tools wäre dann eine Datenbank aufzubauen, die täglich oder wöchentlich oder live aus den Bio-Kats aktualisiert werden würde,
   • Für einen gerade neu geschriebenen Biografie-Artikel will man ja innerhalb der nächsten Stunden auch mit dem Einbau in den Artikelbestand beginnen, und nicht erst drei Monate später.
   • Das Tool müsste in der Datenbank die Klammerlemmata abtrennen und separat in einer Liste von Attributen zum eigentlichen Namen speichern.
   • Dann wäre der Seiteninhalt durchzugehen und jedes unverlinkte Wort (mit Großbuchstabe) zu prüfen, ob es der Beginn des Namens Obi-Wan Kenobi oder eines der anderen halben Million unterschiedlicher Namen wäre. Wenn Treffer, dann wäre zu prüfen, ob das bereits an anderer Stelle als Ziel eines Wikilinks auftritt. Machbar für Einzelartikel; dauert etwas, wenn der länger ist.
   • Resultat wäre eine Liste von Kandidaten. Ggf. zur Hervorhebung einsetzbar, nebst Tooltip mit den Klammerlemmata gleichen Personennamens.
4. „einmalig auf einer Unterseite zusammenträgt als Liste, die man dann abarbeiten könnte“
   • Diese Liste würde vermutlich eine Million Zielartikel auflisten und würde auf rund 15–20 maximal großen Unterseiten die in Frage kommenden Artikel verlinken.
   • Müsste man halt glaubhaft machen, dass die durch einen Menschen innerhalb von ein bis zwei Monaten abgearbeitet werden, bevor sie völlig veraltet wäre.
   • Nein, Unsinn, und lokal hier im Wiki schon gleich gar nicht.
   • Jeder Name eines Journalisten, der einen Zeitungsartikel in den Einzelnachweisen geschrieben hatte, taucht auf; jeder Peter Lang als unverlinkter Verlag im Literaturabschnitt, und wenn man alle Aufzählungen usw. ausschließen würde, gingen wieder viele interessante Stellen wie die Söhne und Töchter der Stadt mit drauf. Jeder ist der Sohn irgendwelcher Landwirte Paul Meyer und dessen Ehefrau Friederike Lehmann, und die beiden sind zufällig gleichnamig mit einem berühmten Admiral und einer Kinderbuchautorin, stehen jedoch im Fließtext. Der Bürgermeister des 300-Seelen-Kaffs hieß vor 150 Jahren zufällig genauso wie ein Bundesminister.
   • Über zwei Millionen Artikel gegen 600.000 Bios liefert schlicht eine menschenunwürdige Schnittmenge; sowas übersteigt die sinnvolle Manpower.
5. Ein anderer Ansatz wäre es, sich auf 50, 100, 200 manuell eingepflegte Namen zu beschränken.
   • Das könnten die Artikel sein, die man selbst geschrieben hatte, oder eine Kategorie nigerianischer Skispringer.
   • Die könnten lokal in den Browser per WebStorage geschrieben und über ein kleines Hilfsmittel dort verwaltet werden.
   • Dann kann man mit Cirrus-Suche Name für Name durchgehen, Treffer-Artikel für Treffer-Artikel aufrufen, und wenn einer von den 100 wirklich unverlinkt drin vorkäme diese Vorkommen hervorheben und eine kleine Statistik in den Seitenkopf schreiben.
   • Wenn aus der Cirrus-Trefferliste noch skriptmäßig die Linkliste auf den fraglichen Namen (und alle seine Klammerlemmata) ausgeblendet würden, hätte man Cirrus-Treffer, in denen der Name wie gewünscht unverlinkt auftritt; oder man generiert die Cirrus-Aufrufe mit trickreichem RegExp direkt aus der Liste interessanter Namen.
   • Vergleichbare Skripte mit völlig anderer Methodik habe ich bereits geschrieben, aber bin auf Jahre ausgebucht bzw. mehrere Jahre im Rückstand und die vorhandenen Anwendungsfälle sind auch nicht mal eben umzubiegen.

LG --PerfektesChaos 10:48, 1. Feb. 2018 (CET)

Danke für diese beeindruckende Analyse ^^ Ich nehme das mal als "eher nein". --Kenny McFly (Diskussion) 11:09, 1. Feb. 2018 (CET)

Unverlinkte Namen per Suchfunktion zu finden ist pro Name nicht so schwierig (insource:/Hermann Meier[^\]}][^(]/), aber dann findet man auch Artikel, in denen Herr Meier nur bei der ersten Nennung verlinkt wurde. --mfb (Diskussion) 08:49, 3. Feb. 2018 (CET)

Das wäre der größtmögliche Overkill für diese Lösung überhaupt. Die einzig adäquate Lösung wäre wie beim oben erwähnten Gadget-Rechtschreibpruefung (über wmflabs) eine extra definierte DB abzurufen. -- User: Perhelion 13:18, 3. Feb. 2018 (CET)

PS: Für eine Ziel-Artikel-DB (zum Vorfiltern) müssten dann ~600 000 * 2.913.588 Artikel ≈ 1 290 000 000 000 Aufrufe getätigt werden und wie von PC gesagt jede Woche. Das dürfte ein wenig dauern (ich habe keine Relation bzw. Vorstellung wie lange). Abruf-Filter: Um die Api-Anfragen gering zu halten müsste das Script relevante Phrasen erkennen, was wiederum überaus aufwendig wäre. Wie PC schon sagt, jegliche Lösung wäre höchst wahrscheinlich utopischer Rechenaufwand.

Einfachste Lösung: Bei Textmarkierung eine virtuelle Verlinkung erzeugen (wenn vorhanden blau wenn nicht rot), egal was. @Kenny McFly:? -- User: Perhelion 13:52, 3. Feb. 2018 (CET)

Du meinst, dass man einen Text markiert und sofort gesagt bekommt, ob das ein Lemma ist? Das klingt super und müsste recht schnell zu machen sein oder? --Kenny McFly (Diskussion) 13:55, 3. Feb. 2018 (CET)

Japp, wäre eine sehr allg. Lösung und auch mit dem größten menschlichen Interaktions-Spielraum (bzw. Aufwand). -- User: Perhelion 14:10, 3. Feb. 2018 (CET)

erledigtErledigt Hier ist eine Rohfassung die läuft: m:User:Perhelion/checkTitleExists.js (ob sie mit IE9 funzt kann ich nicht sagen). Zur Aktivierung links den Toollink klicken. @Kenny McFly: VG -- User: Perhelion 23:49, 8. Feb. 2018 (CET)

Was meinst du mit Toollink klicken? Ich hab das mal auf meiner common.js eingebunden, aber nichts passiert. --Kenny McFly (Diskussion) 10:45, 9. Feb. 2018 (CET)

Links in der Werkzeugleiste müsste „Run TitleCheck“ erscheinen. -- hgzh 10:52, 9. Feb. 2018 (CET)

Richtig (danke für den Hinweis), inzwischen habe ich den Titel „Title-Check“ geändert. Das Script startet natürlich nicht automatisch, da bei jeder Text-Markierung eine API-Anfrage ausgelöst wird (sofern mw.Title gültig und nicht schon mal ausgelöst). PS: Ich habe es nur im Artikel-NR aktiv. @Kenny: bräuchtest du es auch woanders?

Wobei mir ein Fehler in unserer Doku beim Modul mw.Title aufgefallen ist. Nicht dass die Funktion exists schon verwirrend genug ist (denn sie prüft nicht ob der Titel existiert, sondern man muss ihn selbst mit einer API füllen!⁈ Obwohl es für andere trivialere Dinge eine solche fertige API gibt, wie bei isCategory).

.exist und .exists sind Funktionen des Moduls selbst und zumindest .exist ist keine Unterfunktion eines neuen „Titel-Objekts“ (dort t) (ergibt auch insofern Sinn als ein oder mehrere neue Title übergeben werden müssen). Also es gibt zwei verschiedene .exists.@PerfektesChaos: -- User: Perhelion 13:44, 9. Feb. 2018 (CET)

PS. @PerfektesChaos: vllt. wäre es ein Phab-Vorschlag wert die Function t.exists() als wirkliche API-Abfrage zu benutzen!? Edit: Ich habe mal die Doku dahingehend geändert (evtl. habe ich die alphabetische Reihenfolge und die nachfolgende Bedeutung von Danach sind für t verletzt) -- User: Perhelion 13:56, 9. Feb. 2018 (CET)

@Kenny McFly: Und wie funzt das Script, kein Feedback? Mir ist noch eingefallen, dass man noch ein kleines Popup-Fensterchen machen könnte, wie die Vorschau mit mehreren Treffern bei einer Suchanfrage!? -- User: Perhelion 20:37, 26. Feb. 2018 (CET)

Funktioniert hervorragend :D (Das mit dem Popup musst du mir erklären^^) --Kenny McFly (Diskussion) 20:40, 26. Feb. 2018 (CET)

Gut :). Ich meine wie das DropDown-Preview bei einer Suchanfrage das schon während des Eintippens erscheint (wie bei Google). Allerdings nur wenn es für deine Belange praktisch wäre? (Wie aufwendig das jetzt wird kann ich noch nicht sagen, jedenfalls habe ich ein anderes Script mit dieser API-Funktion gesehen). -- User: Perhelion 20:47, 26. Feb. 2018 (CET)

Wo gebe ich denn Text ein? Ich dachte ich markiere. Kann das etwa noch mehr? xD --Kenny McFly (Diskussion) 21:13, 26. Feb. 2018 (CET)

Ne, also dann nicht. :P Dann kannst du den Thread gerne abhaken hier. -- User: Perhelion 21:18, 26. Feb. 2018 (CET)

Danke-Button fehlt

Gemeldet in Phabricator
Task T187013

Hi,

bei diesem Edit fehlt der Danke-Button, der normalerweise da ist, und mit dem man dem Editierenden danken kann:

[11].

Man kann für den Edit trotzdem danken, über diesen Link: Danken... --Distelfinck (Diskussion) 22:36, 3. Feb. 2018 (CET)

Das war eine Artikelneuanlage. Die früheren Versionen wurden importiert. --FriedhelmW (Diskussion) 23:05, 3. Feb. 2018 (CET)

Diese Kombination scheint der Grund zu sein --Distelfinck (Diskussion) 00:10, 4. Feb. 2018 (CET)

@Distelfinck, FriedhelmW: In der Mobile-Version ist der Danke-Button da, also ist es ein Bug.[12] Hiermit gemeldet. -- User: Perhelion 00:34, 12. Feb. 2018 (CET)

Benutzerinfo in der Desktopversion

Gemeldet in Phabricator
Task T187011

Moinsen! Wenn man sich in der mobilen WP einen Versionsunterschied ansieht, kann man ganz einfach ablesen, wie viele Edits der Editor hat und welchen Benutzergruppen er angehört und somit auch ob er erfahren ist. Könnte man das nicht auch für die Desktopversion machen? Immer erst im Benutzerverzeichnis zu gucken ist umständlich. LG Girwidz ^{→Hinterlasse mir hier eine Nachricht} 01:44, 11. Feb. 2018 (CET)

Haloooo? -- Girwidz ^{→Hinterlasse mir hier eine Nachricht} 12:30, 11. Feb. 2018 (CET)

Drängel nicht. -- hgzh 12:41, 11. Feb. 2018 (CET)

Das scheint mir ein relativ neues Feature. Lustig ist, dass es auch als "Desktop-Version" benutzt werden kann.[13] Man müsste eine entspr. Anfrage auf Phab. stellen. -- User: Perhelion 12:50, 11. Feb. 2018 (CET)

Was ist ein Phab? Vorlage:Smiley/Wartung/:d 

-- Girwidz ^{→Hinterlasse mir hier eine Nachricht} 12:57, 11. Feb. 2018 (CET)

https://phabricator.wikimedia.org/ - in der Desktopversion kannst du die Info mit irgendeinem Helferlein bekommen. Navigations-Popups? --mfb (Diskussion) 13:44, 11. Feb. 2018 (CET)

Ich blicke hier irgendwie nicht durch...Vorlage:Smiley/Wartung/:/  -- Girwidz ^{→Hinterlasse mir hier eine Nachricht} 15:48, 11. Feb. 2018 (CET)

Wenn du unter deinen Einstellungen das Helferlein Navigation-Popups (unter Navigation) aktivierst und mit dem Mauszeiger über den Benutzerlink fährst, wird eine Vorschau zur Benutzerseite eingeblendet und ganz unten im Pop-Up-Fenster werden die Infos zum Benutzer angezeigt. Vielleicht wäre das eine Möglichkeit? --Diwas (Diskussion) 21:30, 11. Feb. 2018 (CET)

ja, aber eine komplizierte...

--Girwidz ^{→Hinterlasse mir hier eine Nachricht} 21:44, 11. Feb. 2018 (CET)

@Phab:T187011 @Popups ist nichts von WM, es ist ein verhältnismäßig riesiges User-Gadget mit insgesamt 1/4 MB. Ich persönlich empfinde es als nervend (jeglicher unnötige Mouseover und dann schließt es nicht). -- User: Perhelion 23:57, 11. Feb. 2018 (CET)

@Perhelion: und wie siehts zur Zeit aus??

VG Girwidz ^{→Hinterlasse mir hier eine Nachricht} 07:23, 19. Feb. 2018 (CET)

Es gibt m:User:Perhelion/userstatus -- Freddy2001 ^DISK 08:45, 19. Feb. 2018 (CET)

ich weiss, ich habe das auch aktiviert, aber es muss sich ja jeder einstellen um es zu sehen. Es geht, wie oben gennant, darum, dass man die Info (ähnlich wie in der Mobilen Version) auch in der Desktopversion sehen kann (also bei der Versionsgeschichte)...

—Girwidz ^{→Hinterlasse mir hier eine Nachricht} 13:18, 19. Feb. 2018 (CET)

Der Status der Phab-Anfrage ist immernoch ungesichtet (Needs Triage, nur der Volunteer TheDJ hat das Project Community-Tech entfernt). Es kann sich nur um Jahre handeln (leider kein Scherz). -- User: Perhelion 13:30, 19. Feb. 2018 (CET)

Disk-Seiten-Beta (ehemals flow)

Ist hier zufällig bekannt, ob das neue Disk-Seiten-Format, dass erarbeitet wird, auch in de.WP in absehbarer Zeit als Beta zur Verfügung stehen wird? – Das poppte nämlich in der letzten Zeit in verschiedenen Wikis als Beta auf. mit gruessen von VINCENZO1492 00:16, 15. Mär. 2018 (CET)

Soweit ich weiß, wird das nur auf Wunsch der jeweiligen Community aktiviert und soll niemandem mehr zwangsüberverholfen werden. -- hgzh 09:52, 15. Mär. 2018 (CET)

Wenn ich diesen Phab richtig verstehe, wird es aufgrund der mangelhaften Deinstallierbarkeit, sobald auch nur eine Seite jemals mit diesem billigen, unbrauchbaren Forumsabklatsch erstellt wurde, vorsichtshalber bei allen Projekten, die es noch nicht benutzen, aus der Software entfernt. Die Einführung, auch als Beta, einer solch invasiven (und imho unbrauchbaren) Extension sollte nur nach einem klaren MB erfolgen dürfen. Zur Info, was passiert, wenn sich ein Projekt nachträglich gegen diesen Mist entscheidet, und wie sich die WMF dann weigert, das zu deinstallieren, weil es vorgeblich technische Probleme gäbe, hier was zum Nachlesen auf Commons und Phab: WMF Response to proposal to uninstall Flow, Uninstall Flow from Commons, create a Flow uninstall scriptGrüße vom Sänger ♫ ^(Reden) 10:12, 15. Mär. 2018 (CET)

Wenn es sich wirklich um „billigen, unbrauchbaren Forumsabklatsch“ handelt, wäre eine Installation doch Pflicht! Das entspricht in vielen Fällen dem Diskussionsniveau vieler Benutzer in der deutschen WP ;-)

Im Ernst: der von Dir zitierte Phab ist wohl eine Forderung und kein Beschluss. Und die von der WMF beschriebenen technischen Probleme sind nicht vorgeblich, sondern gab es sehr offensichtlich beim de-installieren in der en-WP. Sie werden auch en detail beschrieben.

Und was Alsee dort treibt ist ja klassisch „Man On A Mission“. In Commons hat er praktisch nichts inhaltlich beigetragen (12 nebensächliche Edits), ist aber hyperaktiv da drin bestimmen zu wollen, was für die Nutzer von Commons gut sein soll. Auf seiner Heimwiki ist es nicht anders: 65% Metabeiträge. Und in den Commons-Disks ignoriert er schön die technische Argumentation der WMF-Kollegen, und kommt dann mit seltsamsten Vermutungen und Unterstellungen daher, die er als vermeintliche Tatsachen beschreibt. Eine klassische Ich-bin-aber-der-Chef-Attitüde – was für ein kollaboratives Projekt natürlich die TopTop-Einstellung ist. Darauf fälltst Du doch nicht wirklich rein? Oder kam es Dir entgegen, weil Du Flow nicht magst?

Die ganze Disk auf Commons ist zudem sehr lächerlich, weil flow eh Geschichte ist. Deswegen fragte ich nach dem Nachfolger…… und wie ich inzwischen heraus bekommen habe (nicht hier): die Beta dafür wird – wie von hgzh richtig beschrieben – auf Verlangen der lokalen Community aktiviert. Heißt jetzt übrigens „Structured Discussions“. In einer Community, in der die Beta dafür installiert ist, kann die jeder User für seine eigene Disk aktivieren und sie ist nicht automatisch für alle Seiten aktiv. Zudem kann der jeweilige Nutzer „Structured Discussions“ auch wieder deaktivieren. Da Du, Sänger, diese neue Version ganz offensichtlich bisher nicht getestet hast, ist es schon gewagt, die Erweiterung mit lauter Posaune abzuurteilen.

Desweiteren konnte ich aus einem WMF-Beitrag entnehmen, dass überlegt wird, eventuell die Community noch einmal zu befragen, bevor das Thema Struktur der Diskseiten softwareseitig entscheidend weiter entwickelt wird. Dazu ist aber wohl noch nichts konkret in Planung. mit gruessen von VINCENZO1492 16:57, 16. Mär. 2018 (CET)

Das ist kein Nachfolger, das ist lediglich eine euphemistische Umbenennung des Projekts, als ob reguläre Disk-Seiten unstrukturiert wären. Der Name Flow war halt etwas verbrannt ;) Grüße vom Sänger ♫ ^(Reden) 17:31, 16. Mär. 2018 (CET)

Feedback zur Verbesserung von Lua-Funktionen benötigt

Hallo,

wer regelmäßig Lua-Module verwendet, sie erstellt und verbessert, wird hiermit um Mithilfe gebeten: Das Wikidata-Entwicklungsteam möchte mehr Lua-Funktionen zur Verfügung stellen, um die Erfahrung derer zu verbessern, die Lua-Skripte zur Wiederverwendung von Wikidata-Daten in Wikimedia-Projekten schreiben. Das Ziel ist es, die in den verschiedenen Wikiprojekten existierenden Module zu harmonisieren, die Lua-Programmierung für die Communitys zu vereinfachen und die Performance dieser Sprache zu verbessern.

Das Team möchte gerne mehr darüber erfahren, welche Gewohnheiten und Bedürfnisse Lua-Programmierer haben und was hilfreich für sie wäre. Dazu gibt es ein paar Fragen auf dieser Seite. Die Seite ist auf Englisch, aber es kann gerne auch auf Deutsch geantwortet werden.

Vielen Dank, Lea Lacroix (WMDE) (Diskussion) 10:18, 27. Mär. 2018 (CEST)

AutoWikiBrowser

Ich schaue mir gerade AutoWikiBrowser an und überlege ihn auch einzusetzen allerdings sind die Fehler die ich finde hauptsächlich sehr kleine Probleme. Daswegen frage ich mich ob solche "Mikro" Edits überhaupt durch AWB erlaubt sind.

Ich hab auch irgendwo gelesen das man den AWB mit einem eigenem Bot verbinden kann der dann bestimmte Fehler automatisch behebt. Ich konnte aber leider nicht viel darüber finden, falls jemand mehr Infos darüber hat wäre ich dankbar. --Skittels0 (Diskussion) 20:12, 27. Mär. 2018 (CEST)

Wikipedia-Personensuche

Diese ist bisher in der Vorlage:Normdaten eingebunden. Das führt dazu, dass die Suche nur für Personen mit dieser Vorlage direkt abrufbar ist. Außerdem gibt es haufenweise leere ND-Vorlagen in Artikeln, die sind aber so - bestenfalls - überflüssig wie z.B. ein Abschnitt == Weblinks ==, wo dann keine Weblinks drunter stehen. Schlimmstenfalls, und das kommt oft vor, behindern sie die Normdatenarbeit, weil eben doch Normdaten vorhanden sind. Siehe dazu auch Benutzer Diskussion:Wurgl/Fehler GND#Wikipedia-Personensuche. Vorschlag: die Personensuche wird technisch links unter Werkzeuge für Personenartikel angelegt und dann aus der Vorlage:Normdaten entfernt. Damit hat dann jeder Personenartikel die Suche, und das Hinzufügen der leeren Vorlage nur wegen der Personensuche entfällt (auch ein Argument für das Einfügen, aber ein recht sinnbefreites). MfG --Informationswiedergutmachung (Diskussion) 12:14, 29. Mär. 2018 (CEST)

@MGChecker: Weißt Du etwas, wie man das in die Werkzeugleiste integrieren kann? – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 16:50, 29. Mär. 2018 (CEST)

@Informationswiedergutmachung, Wurgl: @Sargoth hat den Link trotz des stillen Konsens und unserer Diskussion wieder entfernt, weil im Nachhinein @PerfektesChaos, Hgzh damit nicht einverstanden waren. Es gilt wohl, erneut einen Konsens zu suchen, und zu diskutieren, wie das eventuell auf eine bessere Art in die Werkzeugleiste oder woanders hin zu integrieren ist. Es ist günstig, dies mit entsprechenden Pings auf MediaWiki Diskussion:Common.js#Link Personensuche in die Werkzeugleiste zu diskutieren, meinte Sargoth auf WP:AA. Liebe Grüße, – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 11:43, 2. Apr. 2018 (CEST)

Danke für den Ping. Nach der Diskussion zu urteilen ist wohl ein Gagdet (Wikipedia:Helferlein) das Mittel der Wahl (ich selbst z.B. gehe gar nicht auf diese Personenwebsite, weil das mir ein redundantes Datenblatt scheint). Grüße −Sargoth 12:00, 2. Apr. 2018 (CEST)

1. Kenne ich mich technisch nicht aus, kann da also nicht mitreden. 2. Ist mir PerfektesChaos einfach zu billig (Es ist einfach nur zum Kotzen. Ich hoffe, ein Admin hat Rückgrat und revertiert die Kacke von heute Abend). 3. Man hätte ja Hgzh ja auch sagen können, das es aus der ND-Vorlage verschwinden soll, weil es die ND-Arbeit erschwert. Aber ich sage es mal so wie ich Hgzh verstehe: ihm ist die ND-Wartung völlig egal, dafür mir umgekehrt eure Technikprobleme. Ich kann ND, andere eben Benehmen/Zusammenhänge nicht. Ist in Ordnung. Ich steig bald aus der ND-Wartung aus, wenn das hier so weitergeht, denn: es ist zum Kotzen, dass hier die ND-Arbeit torpediert wird. Ich mache noch ein bisserl ND weiter, um mein Ego zu füttern bis 300k-Edits und danach suche ich mir was anderes. Das hat nichts mit Diva zu tun, aber mir reichts langsam. --Informationswiedergutmachung (Diskussion) 12:03, 2. Apr. 2018 (CEST)

Man hätte ja Hgzh ja auch sagen können, das es aus der ND-Vorlage verschwinden soll, weil es die ND-Arbeit erschwert. – hätte man tatsächlich. Danke, dass du das getan hast, damit ist mein zweites Argument natürlich hinfällig. Ich bin in der Normdatenwartung nicht tätig (ist sie mir deshalb egal? – nein, ich weiß auch nicht, auf welcher Grundlage du zu diesem Verständnis kommst), deshalb benötige ich auch keinen zusätzlichen Link auf das Tool in der Werkzeugleiste. Ich möchte niemandes Wartungsarbeit torpedieren, nur die Art und Weise der Bereitstellung des Links gefällt mir nicht, deshalb auch mein Hinweis auf alternative technische Umsetzungsmöglichkeiten. -- hgzh 12:26, 2. Apr. 2018 (CEST)

ABF. Mein AGF ist derzeit beinahe alle. Es fehlt nur noch das Tüpfelchen auf dem i... --Informationswiedergutmachung (Diskussion) 12:38, 2. Apr. 2018 (CEST)

@Informationswiedergutmachung, Sargoth, Hgzh, Wurgl: Ich ping mal viere von Euch an. Ich versteh es auch nicht so ganz, wozu brauchen wir eigentlich das Tool Personensuche, und damit den entsprechenden Link darauf. Für mich sieht es nicht wie etwas redundantes aus, eben weil darin auch weiterführende Links auf andere Datenbanken beinhaltet sind, die wir in der Normdatenleiste gar nicht darstellen. Dafür werden viele dieser Normdaten aus VIAF nach Wikidata integriert und noch einige Datenbanken mehr dort erfasst, das muss auf Wikidata eben einfach aktuell gehalten werden, da kommt ja VIAF teilweise nicht mal hinterher.
Also: Brauchen wir den Link zur Personensuche in der Vorlage Normdaten oder sonst wo oder kann man sich das ganz sparen? – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 14:49, 2. Apr. 2018 (CEST)

Ich hab ein wenig bei Wikipedia_Diskussion:Normdaten#Wikipedia-Personensuche_Teil_2 geschrieben. Eine Wanderdiskussion ist nicht gar so gut nachvollziehbar. --Wurgl (Diskussion) 15:08, 2. Apr. 2018 (CEST)

Einleitung wp:vm

Ich dachte es lag an meinem Handy, aber auch mit dem neuen Gerät wird in der mobilen Ansicht der VM die Einleitung zusammengequetscht dargestellt (IE, FIREFOX) woran liegt das? Liebe Grüße --2A02:810D:1040:A7C:5021:E93F:D06F:E769 16:00, 27. Apr. 2018 (CEST)

In Chrome auch. Ich glaube es liegt an der CSS "margin-right:15em;". Wenn man das wegnimmt sieht es aber auch nicht gut aus. --FriedhelmW (Diskussion) 16:46, 27. Apr. 2018 (CEST)

Magst du das margin-right:15em; mal durch ein overflow:auto; ersetzen? Ich fasse keine der VM-Seiten an. Ich vermute aber, das würde helfen. --Liebe Grüße, Lómelinde Diskussion 17:05, 27. Apr. 2018 (CEST)

Danke, passt! Gruß --FriedhelmW (Diskussion) 17:34, 27. Apr. 2018 (CEST)

Super jetzt ist es behoben, danke! --2A02:810D:1040:A7C:49BB:7ACC:9045:877D 08:22, 28. Apr. 2018 (CEST)

@FriedhelmW: Dass diese Seite Probleme auf mobil macht, ist kein Wunder.

• Wikipedia:Vandalismusmeldung/Intro ist wie viele andere Projektseiten aus der Periode vor 2010 mit einem Kasten umgeben.
  • Der raubt sowieso erstmal Pixel.
  • Er fordert auch ein Layout ein, bei dem entweder zwei Kästen rechts von unserer Mobil-Software als breite Infoboxen eingestuft und über den Artikel gestellt werden, oder aber der gesamte Kasten links in voller Höhe die Breite der Kästen rechts anzeigt.
• Modernes Seitenlayout machen wir aber anders:
  • Es kommt zu allererst ein Einleitungsabschnitt wie bei einem enzyklopädischen Artikel.
  • Das erklärt dann in der Mobil-Ansicht zuerst, worum es in der Seite geht.
  • Auch in den Vorschau-Popups erscheint zunächst die Zweckbeschreibung der Seite.
  • Die Kästen ordnen wir erst später an, ggf. vor oder nach der ersten Abschnittsüberschrift.
  • Die späteren Intro-Absätze können dann auch die volle Fensterbreite nutzen.
• Heißt: Kasten drumrum grundsätzlich weg, hat null Informationswert.
  • Ggf. Abgrenzung zum inhaltlichen Teil ab TOC durch ein anderes optisches Gestaltungsmittel sicherstellen.
• Du hast genug Know-How und Nervenstärke, um dies auf BETA zu erproben und dann den Admins vorzuschlagen; ggf. eher auf WP:A/N.
  • Der Weg von Ló ist nur Notlösung und leider nur Krücke für die Symptome, beseitgt jedoch nicht die beschriebene Ursache.

LG --PerfektesChaos 10:55, 28. Apr. 2018 (CEST)

ich weiß nicht wieso aber scheinbar hat jemand es wieder zurückgeändert, jetzt wird es wieder nicht richtig dargestellt. --109.41.192.175 23:44, 9. Mai 2018 (CEST)

Tool Imagemap

Hallo, ich wurde hier darauf aufmerksam gemacht, dass es bei Wikitools ein Werkzeug geben soll, mit dem man in einem Bild Beschreibungen hinzufügen kann, wenn man mit der Maus bestimmte Bereich überfährt. Wo finde ich das denn?--Σ 12:52, 4. Mai 2018 (CEST)

Hilfe:Imagemap, Vorlage:Große Imagemap, Kategorie:Vorlage:Verweissensitive Grafik … --Liebe Grüße, Lómelinde Diskussion 13:52, 4. Mai 2018 (CEST)

Wikitext highlighting out of beta

Wikitext syntax highlighting, also known as CodeMirror, has been moved out of Beta Features and is available in the 2017 Wikitext Editor on all wikis. Syntax highlighting helps you see problems in your wikitext before previewing or publishing text. Please try out the tool if you did not do so while it was being developed, and feedback is welcome. - Keegan (WMF) (talk)

20:55, 4. Mai 2018 (CEST)

Zu große Klick-Area für die Editorwechsel-Icons des Bearbeitungsfensters

In meiner Konfiguration (Monobook unter Linux) kann man den ganz oben platzierten Rollbalken des Bearbeitungsfenster nie mit der Maus erhaschen, weil der darüber befindliche Doppelicon-Umschalter zwischen visueller und Quelltextbearbeitung den Ḱlick abfängt. Seine Klick-Area ragt anscheinend bis etwa einen Zentimeter unterhalb des als hellgrauer Balken eingefärbten Kopfmenüs herab, sollte aber wohl „in fremden Gefilden“ grundsätzlich nichts verdecken. --Silvicola ^Disk 01:25, 8. Mai 2018 (CEST)

Ich habe den Fehler als phab:T194120 gemeldet, bin mir aber nicht sicher, wie sehr sich die Programmierer für den Monobook-Skin interessieren. Mit Vector oder anderen Skins, die ich probiert habe, tritt das Problem nämlich nicht auf. –Schnark 09:23, 8. Mai 2018 (CEST)

Danke für Deine Bemühung.

Vielleicht wäre es besser, wenn die in den Augen brennende Zwiebel nicht so viele Häute hätte. Eine taugliche genügte ja. Multi skin no win. --Silvicola ^Disk 01:53, 10. Mai 2018 (CEST)

A note on ‘mapframe’ maps and this wiki

Hilf bitte mit, in deine Sprache zu übersetzen

You may have heard that the Foundation’s Collaboration Team has been working on a project to improve maps. We’re planning to release the mapframe feature, which embeds maps in wiki pages, to most Wikipedias. I’m writing this note to clarify that nine Wikipedias are not scheduled to get mapframe as part of the release, including this Wikipedia. The reason is Flagged Revisions.

The nine Wikipedias that are not getting mapframe at this time are wikis that use the strict version of Flagged Revisions. At these wikis the latest changes to a page are not shown by default until they can be approved. This protocol causes problems with mapframe. When an approved version of a mapframe map exists on the page and someone edits the map, the approved page displays a blank frame where the map should be.  

We’ve looked into the issue (T151665) and may have a solution (T192695). It’s not simple. At this time we can’t promise that we’ll be able to fix the incompatibility of Flagged Revisions and mapframe as part of our current maps project. The current maps project has specific goals and a limited time-frame. We will keep an eye on the task, though, and if we can find time, it’s something we’d like to take care of. If you have thoughts or ideas about this, please leave them on the project talk page or in the tasks I’ve linked to.

Danke! CKoerner (WMF) (Diskussion) 21:52, 10. Mai 2018 (CEST)

Script für mobile Version

Das Script Benutzer:Debenben/MathJax.js funktioniert für die Desktop-Ansicht wenn man es in common.js reinschreibt, aber für die mobile Ansicht auch dann nicht, wenn man minerva.js verwendet. Weiß jemand warum nicht bzw. kann es vielleicht beheben? Vielen Dank.--Debenben (Diskussion) 23:21, 16. Mai 2018 (CEST)

Ich tippe darauf, das in der Mobilen Version entweder eine andere CSS-Klasse verwendet wird (womit das Programm die Formeln nicht erkennt) oder der Resource-Loader (Wikipedia:Technik/Skin/JS/ResourceLoader) das Laden von Fremdservern verbietet. (nicht signierter Beitrag von Victor Schmidt (Diskussion | Beiträge) 20:09, 26. Mai 2018 (CEST))

Die CSS-Klassen sind eigentlich da, dann muss es wohl irgendwie an dem ResourceLoader liegen.--Debenben (Diskussion) 14:16, 31. Mai 2018 (CEST)

Nachsignier-Bot

Kann es sein, dass der nicht richtig funktioniert? mit gruessen von VINCENZO1492 18:19, 17. Mai 2018 (CEST)

Welchen meinst du, CopperBot? Dann siehe WP:BA#CopperBot. --тнояsтеn ⇔ 18:40, 17. Mai 2018 (CEST)

Danke, ja das scheint er zu sein. Aber da er über ein Jahr kaputt ist, ist wohl davon auszugehen, das es a) ein technisch anspruchvolles Problem ist oder b) als ein Problem mit nicht hoher Priorität angesehen wird. mit gruessen von VINCENZO1492 09:28, 18. Mai 2018 (CEST)

Das Problem ist weniger die Komplexität, als das der Betreiber, Benutzer:P.Copp, zuletzt 2012 aktiv war und das Problem damit unlösbar ist. Das Eigentliche Problem ist, Das der RC-Stream, über den der Bot seinen Input bekommen hat, abgeschaltet wurde. Da der Betreiber inaktiv ist, kann das Problem nicht durch ihn behoben werden. Derzeit hat Benutzerin:TaxonBota von Doc Taxon (Diskussion • Beiträge • gelöschte Beiträge • hochgeladene Dateien • SBL-Log • Sperr-Logbuch • globale Beiträge • SUL • Logbuch • sperren) den Nachsignierauftrag übernommen -so wei ich bescheid weiß. Victor Schmidt Was auf dem Herzen? 20:05, 26. Mai 2018 (CEST)

mein Urlaub ist in ein paar Tagen um, dann werde ich mich weiter damit beschäftigen, – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 22:11, 26. Mai 2018 (CEST)

@Victor Schmidt: unter den Edits von TaxonBota sind anscheinend keine Nachsignieredits. Und das erscheint mit der Antwort von Doc Taxon dann ja auch logisch.

@Doc Taxon: Danke! mit gruessen von VINCENZO1492 10:00, 1. Jun. 2018 (CEST)

"mw-collapsed" nur mit Buttongrafik steuern?

Hallo, ich habe mich intensiv mit collapsible-Tabellen beschäftigt (vgl. en:Help:Collapsing #Collapsing by default) und nutze viele eingeklappte Tabellen im Ethnologie-Portal, z. B. mit Charts. Jetzt habe ich in einem Mediawiki-Demo im Abschnitt „Pre-made toggle“ die Möglichkeit gesehen, die Auf-/Einklappfunktion auf eine Buttongrafik zu legen und diese je nach Status sogar auszutauschen. Ich habe den kurzen Quelltext des Mediawiki-Abschnitts mal hier rein kopiert, musste allerdings die templatestyles src="Sandbox/CollapsibleDemo.css" auskommentieren (obwohl die vermutlich zur Darstellung benötigt wird):

Text…Text…Text…Text…Text…Text…

Das Ein-/Ausklappen funktioniert, aber der Austausch der Button-Versionen klappt nicht so wie in der MediaWiki-Demo. Kann mir da jemand weiterhelfen?
Grüße -- Chiananda (Disk | Edits | Portal:Ethnologie/Erwünschtes) 20:33, 23. Mai 2018 (CEST)
PS: Ich merke erst jetzt, dass nicht die Buttongrafiken klickaktiv sind, sondern ihr div-Bereich quer über die ganze Seite. Ich vermute, das Austausch-Verhalten der class="up"- und class="down"-spans gründet in der "Sandbox/CollapsibleDemo.css"…

Code mit {{Displaytitle}} ausführbar

Hallo zusammen,

ich glaub, dass ich einen Bug gefunden habe. Und zwar kann man, wenn man den Tittle mit {{DISPLAYTITLE}} formatiert, dort auch Code ausführen. Auf meiner Benutzerseite (Permalink) habe ich dann {{DISPLAYTITLE:Benutzer:Paul Ewe<s>}} geschrieben und es war alles, einschließlich dem Text im Footer, durchgestrichen. In der EN-WP funktioniert das auch. Ich hab auch probiert exec "hallo" zu schreiben, aber dann hatte die DE-WP bei mir ca 20 sek. einen 504. Kann man dort jeglichen Code ausführen? Und ist das ein kritischer Bug?

Vielen Dank schon mal fürs weiterleiten. :) --Paul Ewe »?« 19:17, 24. Mai 2018 (CEST)

Kritisch ist das eher nicht, im Sinne eines Sicherheitsrisikos.

Das DISPLAYTITLE verarbeitet den Parameterwert (also alles nach dem Doppelpunkt) dahingehend weiter, dass sämtliche Tags entfernt werden. Wenn das dann in normalisierter Form (also abgesehen von der Groß- und Kleinschreibung des ersten Buchstabens des Titels und mit gültigen Aliassen für den Namen des Namensraums) mit dem echten Seitentitel übereinstimmt (und bestimmtes fieses CSS nicht verwendet wurde), dann wird das als angezeigter Titel dargestellt, andernfalls gibt es eine Fehlermeldung.

Du hast schlicht und einfach ein für den vorstehenden Check unschädliches öffnendes Tag innerhalb des DISPLAYTITLE zu stehen gehabt, das hätte aber genausogut auch draußen stehen können. Okay, dadurch, dass das vom Seitentitel ausgeht, streicht es die Seite besonders heftig durch, und nicht nur den Inhaltsbereich, aber leicht zu finden und zu reparieren. Wenn du einen Artikelquelltext entsprechend beginnst, ist der dann halt auch wunschgemäß komplett durchgestrichen.

Das mit exec "hallo" wäre erstmal eine völlig andere Nummer, aber ich glaube eher nicht, dass an dieser Stelle ein Programmcode ausgeführt wurde.

Woher der Hänger kam, wäre noch zu analysieren.

Danke trotzdem für’s Bescheidsagen, ich werde es mir bei Gelegenheit nochmal intensiver ansehen.

LG --PerfektesChaos 20:14, 24. Mai 2018 (CEST)

Mir ging es auch eher darum, dass man die Formatierung außerhalb des Inhaltsbereich ändern kann, obwohl das ja eigentlich nicht möglich sein sollte.

Das mit dem exec war auch glaub ich eher eine kurze Vorsorgesperrung meiner IP. Eigentlich wollte ich auch echo schreiben, aber ich hab das Wort verwechselt. Das da war passiert ist und noch untersucht werden muss, glaub ich nicht. Trotzdem danke für die Einschätzung.

--Paul Ewe »?« 00:15, 25. Mai 2018 (CEST)

Wenn du einen Fehler findest, der möglicherweise ein Sicherheitsrisiko darstellt, dann melde ihn bitte nicht öffentlich, sondern am besten wie unter mw:Reporting security bugs beschrieben.

In diesem Fall gehe ich aber wie PerfektesChaos davon aus, dass kein Sicherheitsrisiko besteht, der Serverfehler kam von einer Software-Aktualisierung, die Wikidata betraf.

Dass fehlerhaftes HTML nicht bereinigt wird, ist als phab:T26910 schon länger bekannt. –Schnark 09:32, 25. Mai 2018 (CEST)

Miniatur Vorschau der Wiki Artikel auf eigener Website (Wordpress)

Hallo liebe Wiki Mitglieder, bin ein Anfänger, was das aufsetzen von Websites angeht. Habe eine kleine Website angefertigt, über Wordpress wo ich diverse Links von Websites einfüge. Nun würde ich gerne einige auserwählte Wiki Websites verlinken, mit der Besonderheit, dass ich gerne eine Miniatur Vorschau angezeigt bekommen würde, wenn man über den Hyperlink fährt, so wie sie in einigen Wiki Seiten angezeigt wird. Wie kriege ich das hin? Würde mich über jegliche Lösungsansätze sehr freuen. Beste Grüße und einen schönen Tag wünsche ich euch. --DerPförtner (Diskussion) 19:53, 26. Mai 2018 (CEST)(nicht signierter Beitrag von 2001:4dd5:a9b9:1:5571:c0ae:c087:ff3e (Diskussion) 10:15, 26. Mai 2018 (CEST))

Ich wüsste nicht, das das geht. Man kann glaube ich mittels JavaScript irgendwie Vorschaubilder generieren, denn auf meiner Firefox-Startseite tauchen immer Welche auf, aber das sollte lieber unterlassen werden, da Live-Mirrors nur nach Rücksprache mit der Wikimedia Foundation zulässig sind, und zwar auch dann, wenn das ergebnis gecached wird. Grüße, Victor Schmidt Was auf dem Herzen? 19:57, 26. Mai 2018 (CEST)

Vielen lieben Dank für die ausführliche Antwort, das hat mir schon einmal sehr weiter geholfen. Gruß --DerPförtner (Diskussion) 20:49, 26. Mai 2018 (CEST)

Hi DerPförtner, ich vermute mal, dass es dir nicht unbedingt um eine Live-Vorschau geht. Wie wäre es denn mit Screenshots zB der Artikel-Einleitung oder soweit vorhanden der Infobox eines Artikels, die vlt dauerhaft auf deiner Seite eingeblendet sind (und diese somit vermutlich sogar noch interessanter aussehen lassen) und in denen der Hyperlink zum entsprechenden WP-Artikel integriert ist--Ciao • Bestoernesto • ✉ 02:28, 27. Mai 2018 (CEST)

Hallo bestoernesto, genau diese Option würde ich Erwägung ziehen, wie würde ich es dann umsetzen? Geht das komplett über HTML? Dort habe ich bereits einige Erfahrungen gesammelt, bei JavaScript noch gar keine. Freue mich auch über Anhaltspunkte, welche ich nutzen kann um mein Wissen zu erweitern, sodass ich meine Idee umsetzen kann. Gruß --DerPförtner (Diskussion) 02:35, 27. Mai 2018 (CEST)

Komplett mit HTML und ohne JavaScript geht es nicht. Bei nicht-Live geht Folgendes (Keine Funktionsgarantie!):

  <img class="thumb" src="/media/thumb/beispielvorschau.jpg" onmouseon="this.sytle='display:block';" onmouseout="this.style='display:none';">

und in einer CSS-Datei

  .thumb{
    position:relative;
    width:55px;//Währe gemäß bildgrößen anzupassen
    height:55px//Ebenso
  }

Damit bekommt man ein Bild, das auf deiner Webseite den Pfad /media/thumb/beispielvorschau.jpg hat, hinein. Grüße, Victor Schmidt Was auf dem Herzen? 09:21, 27. Mai 2018 (CEST)

Substitution fehlgeschlagen

Diff. Warum wurde hier die Vorlage nicht substituiert? --тнояsтеn ⇔ 08:47, 30. Mai 2018 (CEST)

Hallo тнояsтеn. Der Parameter Lemma blieb unausgefüllt; mglw. ist er erforderlich, auch um eine Überschrift zu generieren. Gruß, --Wi-luc-ky (Diskussion) 09:41, 30. Mai 2018 (CEST)

Für die Überschrift ist Name zuständig, wenn ich mir Vorlage:WNM-Spiegel ansehe. --тнояsтеn ⇔ 10:22, 30. Mai 2018 (CEST)

Wegen des Kommentars im Titel der Vorlage, würde ich sagen. --Liebe Grüße, Lómelinde Diskussion 09:52, 30. Mai 2018 (CEST)

Kommentar sollte doch – egal an welcher Stelle – die Funktion der Vorlage nicht ändern? --тнояsтеn ⇔ 10:22, 30. Mai 2018 (CEST)

Versuch macht klug. Hab es ausprobiert, den ersten Kommentar entfernt und siehe da: diff. Scheint aber früher nie ein Problem gewesen zu sein, Vorlage:WNM-Spiegel und Vorlage:WNM-Spiegel/preload gibts ja schon länger. --тнояsтеn ⇔ 10:25, 30. Mai 2018 (CEST)

Sollte :-) ich kann dir auch nur sagen, was ich durch testen herausfinde. →{{subst:hallo}} --Liebe Grüße, Lómelinde Diskussion 10:32, 30. Mai 2018 (CEST)

Nachdem sich am Verhalten nichts geändert hat, habe ich den Kommentar aus der Vorlage entfernt: diff. --тнояsтеn ⇔ 09:17, 7. Aug. 2018 (CEST)

Suche sehr kleines WP-Logo ...

... zur Kennzeichnung von WP-Links in einer meiner Linklisten (außerhalb Wikipedia). Also möglichst nicht größer als Schrift, vielleicht 10 pt oder so. Weiß da jemand was? Ich überlege, das dann per CSS automatisiert einzubauen. Danke für Tipps, --Karsten Meyer-Konstanz (D) 18:46, 3. Jun. 2018 (CEST)

@Meyer-Konstanz: In der Größe ist der Puzzelball wohl nicht mehr zu erkennen. Versuch's mal hiermit: .

Wobei ich da schon etwa größer werden würde . // Martin K. (Diskussion) 18:58, 3. Jun. 2018 (CEST)

Dankeschön, Martin K., das bringt mich auf die Idee, ob es nicht diesen Buchstaben als Schrift gibt, so dass er mit der Schrift skaliert würde. --Karsten Meyer-Konstanz (D) 19:59, 3. Jun. 2018 (CEST)

@Meyer-Konstanz: Ja, das gibt es. Die Schrift heißt Linux Libertine und hat das Wikipedia-W als Sonderzeichen. // Martin K. (Diskussion) 20:07, 3. Jun. 2018 (CEST)

Sehr interessant, danke, Martin K.. Du weißt jetzt nicht noch zufällig den Trick, wie man (möglichst nur ein Zeichen) einer Schrift auf dem eigenen Server zur Verfügung stellt? --Karsten Meyer-Konstanz (D) 21:04, 3. Jun. 2018 (CEST)

Nachtrag: Hab's gefunden, werde es morgen versuchen.--Karsten Meyer-Konstanz (D) 22:13, 3. Jun. 2018 (CEST)

@Meyer-Konstanz, Martin Kraft: Extra kleine (Fav-)Icons findet man hier c:Category:Wikipedia favicons (für weitere Wikimedia Icons, s. Eltern-Kat.). -- User: Perhelion 15:35, 28. Jun. 2018 (CEST)

Schönen Dank, @Perhelion:! Wobei ein Schriftzeichen zur Kennzeichnung von (Text-) Links schon besser wäre, weil das Zeichen dann auf jedem Browser mit der Schrift skalieren würde. Nur war mir das dann doch zu kompliziert. --Karsten Meyer-Konstanz (D) 22:52, 28. Jun. 2018 (CEST)

Linkfix – Ideensuche

Beitrag von Wurgl von Diskseite zu Werkstatt hierher verschoben. mit gruessen von VINCENZO1492 11:06, 6. Jun. 2018 (CEST) Hallo!

Ich hab da eine nette Fehlerquelle gefunden und suche Ideen wie ich das möglichst automagisch fixen kann oder wenigstens einen (hoffentlich) großen Teil davon. Betroffen sind knapp 1500 Links in knapp über 1000 Artikeln. Das Problem besteht darin, dass die in die WP eingefügten Links der nte (5te oder 13te) Link innerhalb einer Trefferliste zum Zeitpunkt der Linkerstellung ist. Nun ändert sich die Anzahl der Treffer, teils werden doppelte entfernt und teils werden neue Datensätze die dem Kriterium entsprechen eingefügt. Was also damals der dreizehnte Treffer war, kann morgen die Nummer siebzehn oder zwölf sein.

Ein Beispiel: Im Artikel Über_Friedrich_den_Großen_und_meine_Unterredung_mit_ihm_kurz_vor_seinem_Tode ist der Link https://portal.dnb.de/opac.htm?method=showFullRecord&currentResultId=Zimmermann,+and+Johann+and+Georg,+and+%C3%BCber%26any&currentPosition=17 vorhanden (der tatsächliche ist eventuell mit Host d-nb.de und kann durch IABot bereits als Archivlink oder Totlink markiert sein, das ist aber ein anderes Problem). Der Link zeigt auf ein Werk "Zimmermann, Johann Georg: Ueber die Einsamkeit" gemeint ist aber wohl Treffer 20 (einfach am Ende vom Link die 17 gegen 20 tauschen), also "Fragmente über Friedrich den Grossen [...] und seines Charakters / von [Johann Georg] von Zimmermann". Und sinnvoll wäre ein Ersetzen gegen einen Permalink den es sogar als Vorlage gibt, also ein Wikiquelltext wie {{DNB|1003736491}} bzw. DNB 1003736491.

Wie könnte man das sinnvoll angehen? HTML-Seite des Ziels lesen, dort den Namen des Werks rauspfriemeln und den mit dem Lemma nach irgendeinem Algorithmus (ich mag die Levenshtein-Distanz, gibt aber andere) abgleichen. Da dürfte ich so manche finden die immer noch okay sind. Vielleicht noch ein wenig Text aus der Umgebung des Links sammeln und auch mit einem noch zu entwickelnden Algorithmus abgleichen, so Fälle sind zu erwarten wenn mehrere derartige Links im Artikel zu finden sind.

Gibts schon sowas? Gibt es derartige Nicht-so-schlau-Links auch auf andere Seiten? Hat jemand irgendwelche Ideen dazu? --Wurgl (Diskussion) 19:53, 5. Jun. 2018 (CEST)

Platzhalter für Tabellenhintergrundfarbe

Hallo, ich möchte in einer Tabelle den Zellen einzeln Hintergrundfarben geben, wobei viele Zellen die gleiche Farbe bekommen. Ist es möglich, Platzhalter für die Farben einzusetzen, so dass man später, falls die Farbe bei einer Artikelbearbeitung geändert werden soll, nur den Platzhalter ändern muss, um alle Zellen mit einer bestimmten Farbe umzufärben? --Megatherium (Diskussion) 14:56, 7. Jun. 2018 (CEST)

Mittel der Wahl wäre es, sich an Vorbildern der Kategorie:Vorlage:Tabelle zu orientieren und zumindest eine spezielle Vorlage für die Tabellenzeile anzulegen.

Vorlagen können auch die Parameterwerte auf Gültigkeit und Existenz prüfen, Wartungskategorien auslösen, allgemein die Werte formatieren, und die von dir gewünschten Hintergrundfarben automatisch zuordnen (rot für negative Zahlen, grau bei Null und schwarz oder grün sonst).

Andere nur auf die Farben abzielende Dekoration würde dir einen nicht wartbaren Dschungel einbringen, der wenig Vorteile hat, den niemand außer dir zukünftig pflegen kann und für den man dich wohl irgendwann verfluchen wird.

Mit Suchen+Ersetzen lassen sich aber auch heute problemlos einheitlich Farbwerte ändern, falls es nur einen einzigen Artiel beträfe, und dann wäre überhaupt keinerlei komplizierter Überbau erforderlich.

VG --PerfektesChaos 16:51, 7. Jun. 2018 (CEST)

Vielen Dank, dann mache ich das lieber ganz normal. Ich dachte nur, es gibt vielleicht eine einfache Methode dafür, die ich problemlos einsetzen kann, aber wenn es kompliziert und schwer wartbar wird ... --Megatherium (Diskussion) 17:53, 7. Jun. 2018 (CEST)

Improvements coming soon on Watchlists

Hello

Sorry to use English. Hilf bitte mit, in deine Sprache zu übersetzen! Vielen Dank.

In short: starting on June 18, New Filters for Edit Review (now in Beta) will become standard on Watchlists. They provide an array of new tools and an improved interface. If you prefer the current page you will be able to opt out. Learn more about the New Filters.

What is this feature again?

This feature is used by default on Special:RecentChanges, Special:RecentChangesLinked and as a Beta feature on Special:Watchlist.

Based on a new design, that feature adds new functions to those pages, to ease vandalism tracking and support of newcomers:

• Filtering - filter recent changes with easy-to-use and powerful filters combinations, including filtering by namespace or tagged edits.
• Highlighting - add a colored background to the different changes you are monitoring. It helps quick identification of changes that matter to you.
• Bookmarking to keep your favorite configurations of filters ready to be used.
• Quality and Intent Filters - those filters use ORES predictions. They identify real vandalism or good faith intent contributions that need help. They are not available on all wikis.

You can know more about this project by visiting the quick tour help page.

About the release on Watchlists

Over 70,000 people have activated the New Filters beta, which has been in testing on Watchlist for more than eight months. We feel confident that the features are stable and effective, but if you have thoughts about these tools or the beta graduation, please let us know on the project talk page. In particular, tell us if you know of a special incompatibility or other issue that makes the New Filters problematic on your wiki. We’ll examine the blocker and may delay release on your wiki until the issue can be addressed.

The deployment will start on June 18 or on June 25, depending on the wiki (check the list). After the deployment, you will also be able to opt-out this change directly from the Watchlist page and also in your preferences.

How to be ready?

Please share this announcement!

If you use local Gadgets that change things on your Watchlist pages, or have a customized scripts or CSS, be ready. You may have to make some changes to your configuration. Despite the fact that we have tried to take most cases into consideration, some configurations may break. The Beta phase is a great opportunity to have a look at local scripts and gadgets: some of them may be replaced by native features from the Beta feature.

Please share your questions and comments on the feedback page.

On behalf of the Collaboration team, Trizek (WMF) 15:15, 7. Jun. 2018 (CEST)

Spezial:LintErrors

Kann man irgendwie diese Gesamtliste so aktualisieren, dass sie den tatsächlichen Stand anzeigt? Konkret möchte ich, dass die Phantomanzeigen aus den Listen verschwinden (vergeiche auch Statistikanzeige, die scheinbar treffsicherer ist)

Hohe Priorität

• Tabellen-Tag, das gelöscht werden soll. (5 Fehler) – N aktuell müssten dort 3 Fehler/Seiten stehen (→2 BD 1 P)
• Falsch verschachteltes Tag mit einer unterschiedlichen Darstellung in HTML5 und HTML4 (7.598 Fehler) – N 4081 Fehler
• Verschiedene Tidy-Ersetzungsprobleme (0 Fehler) J
• Mehrzeilentabelle in der Liste (0 Fehler) J
• Mehrere nicht geschlossene Formatierungstags (2 Fehler) – N →0
• Workaround für einen Absatzumbruchfehler (0 Fehler) J
• Selbstschließende Tags (0 Fehler) J
• Tidy-Fehler, die sich auf Links umgebende Font-Tags auswirken. (57.312 Fehler) – N 26.676 Seiten
• Tidy-Leerzeichenfehler (0 Fehler) J
• Nicht geschlossenes Anführungszeichen in der Überschrift (3 Fehler) – N →0

Mittlere Priorität

• Fehlerhafte Dateioptionen (3 Fehler) – N →2 hier kommt erschwerend hinzu, dass beide Seiten noch immer etliche Fehler anzeigen, die aber eigentlich behoben wurden. Die Fehlerlinks sind daher auch nicht mehr zielführend (2017 Q2 zeigt noch 21 und 2017 Q3 zeigt noch 15 Fehler an vermutlich alle behoben)
• Falsch verschachtelter Inhalt (1.579 Fehler) – 1.566
• Falsch verschachtelte Tags (69.204 Fehler) – N 32.569 schwankt stark auch manchmal mit einem Spitzenwert von mehr als 86.000
• Mehrere Doppelpunkte (0 Fehler) J

Niedrige Priorität N hier kann ich absolut nicht ablesen wieviele Fehler wirklich vorhanden sind, die Zahlen schwanken sehr stark oder es werden teilweise für die oberen beiden identische Werte ausgegeben.

• Fehlendes End-Tag (268.590 Fehler)
• Veraltete HTML-Tags (291.855 Fehler)
• Ignorierte Tags (86.296 Fehler)

Das stört mich schon seit Wochen. Entweder sind dort tatsächlich Seiten, dann sollten sie auch in den Einzellisten stehen, oder es gibt dort keine Fehler, dann sollte dort auch in der Gesamtübersicht 0 angezeigt werden. Das ist nervig. Vermutlich stammen einige der Phantome aus Seiten wie den Archiven (immerhin 36 Einträge), da sie noch in den Seiteninformationen stehen, ich weiß nicht wie man das lösen soll (oder wie man die Fehler finden soll, wenn die Links nicht mehr dort landen, irgendwie scheint es ein Serverproblem zu sein, gerade bei so großen Seiten), ich habe sogar schon die eine Archivseite in kleine Abschnitte geteilt (herauskopiert) und einzeln analysiert, um sicherzugehen, dass auch wirklich alles o.k. ist. Sie verschwinden aber einfach nicht aus der Liste. Wie soll man so effektiv arbeiten können? Ich bin nicht die einzige die es mehrmals versucht hat zu lösen. Ich möchte, dass zumindest die tatsächlich leeren Listen auch in der Übersicht als Leer zu erkennen sind, damit man hinzukommende tatsächliche Fehler besser erkennen kann. --Liebe Grüße, Lómelinde Diskussion 07:28, 9. Jun. 2018 (CEST)

Nein, kann man nicht.

Diese Datenbank ist nur ein unterstützendes Provisorium, und wenn da mal durch irgendeinen Schluckauf Phantom-Einträge hineingeraten sind, dann sind die da eben drin und irgendwann weiß auch jeder was wo nicht stimmt.

Diese Datenbank hat keine Bedienoberfläche, um Inhalte zu pflegen oder einzelne Eintragungen zu löschen.

Es könnten höchstens auf allen Wikis alle Linter-Datenbanken vollständig gelöscht werden, wodurch der enWP aber zig und zig Millionen Hinweise verlorengingen, deren Neuaufbau ein halbes Jahr dauern würde.

Einfach geduldig warten; vielleicht vergisst Linter das Phantom nach ein paar Edits auch mal wieder.

LG --PerfektesChaos 14:27, 9. Jun. 2018 (CEST)

Schade wirklich, es erschwert diese Arbeit, weil man es doch immer wieder anklicken muss, um zu schauen, ob sich etwas geändert hat oder es nur die falschen Einträge sind. Und ein unbedarfter der so einen Eintrag anklickt und dann kommt da nichts, der wird schnell die Lust daran verlieren sich da einzusetzen. --Liebe Grüße, Lómelinde Diskussion 14:37, 9. Jun. 2018 (CEST)

Die Frage wäre, ob man via Phab beantragen kann, die Datenbank für deWP zu löschen und neu aufzubauen, selbst wenn das Wochen dauert.--Mabschaaf 14:41, 9. Jun. 2018 (CEST)

Update on page issues on mobile web

Update on page issues on mobile web

Hilf bitte mit, in deine Sprache zu übersetzen Hi everyone. The Readers web team has recently begun working on exposing issue templates on the mobile website. Currently, details about issues with page content are generally hidden on the mobile website. This leaves readers unaware of the reliability of the pages they are reading. The goal of this project is to improve awareness of particular issues within an article on the mobile web. We will do this by changing the visual styling of page issues.

So far, we have drafted a proposal on the design and implementation of the project. We were also able to run user testing on the proposed designs. The tests so far have positive results. Here is a quick summary of what we learned:

• The new treatment increases awareness of page issues among participants. This is true particularly when they are in a more evaluative/critical mode.
• Page issues make sense to readers and they understand how they work
• Readers care about page issues and consider them important
• Readers had overwhelmingly positive sentiments towards Wikipedia associated with learning about page issues

Our next step would be to start implementing these changes. We wanted to reach out to you for any concerns, thoughts, and suggestions you might have before beginning development. Please visit the project page where we have more information and mockups of how this may look. Please leave feedback on the talk page.

CKoerner (WMF) (talk) 22:58, 12. Jun. 2018 (CEST)

Beobachtungsliste

Hallo, seit 2-3 Tagen wird die Beobachtungsliste anders dargestellt: zuerst der Aufzählungspunkt und erst in der nächstn Zeile der jeweilige Text. Dadurch ist die Kompaktheit der vorigen/bisherigen Darstellungsweise verloren gegangen. Da ist bei meinen Privat-PC und auch in der Arbeit (beide Windows + Internet Explorer). lG --Hannes 24 (Diskussion) 13:01, 2. Jul. 2018 (CEST)

Bei mir tritt des selbe Fehler auf. Vfb1893 (Diskussion) 13:15, 2. Jul. 2018 (CEST)

WP:FZW#Darstellungsproblem der Beobachtungsliste im IE --Magnus (Diskussion) 13:30, 2. Jul. 2018 (CEST)

Consultation on the creation of a separate user group for editing sitewide CSS/JS

(Hilf bitte mit, in deine Sprache zu übersetzen)

Hi all,

I'm preparing a change in who can edit sitewide CSS/JS pages. (These are pages like MediaWiki:Common.css and MediaWiki:Vector.js which are executed in the browser of all readers and editors.) Currently all administrators are able to edit these pages, which poses a serious and unnecessary security risk. Soon, a dedicated, smaller user group will take over this task. Your community will be able to decide who belongs in this group, so this should mean very little change for you. You can find out more and provide feedback at the consultation page on Meta. If you are involved in maintaining CSS/JS code, or policymaking around adminship requests, please give it a look!

Thanks!
Tgr (talk) 12:50, 9. Jul. 2018 (CEST) (via global message delivery)

Beobachtungsliste: Zeitraum

Seit gestern wird in meiner Beobachtungsliste die „Anzuzeigende Zeitperiode“ ständig auf 1 Stunde zurückgesetzt. Ich muss jedesmal erneut 7 Tage auswählen, was ziemlich nervt. In meinen Einstellungen ist natürlich 7 Tage konfiguriert. Bis vorgestern hat das auch funktioniert. Das Problem tritt sowohl im Büro mit IE 11 unter Windows als auch daheim mit Chrome unter FreeBSD auf, hat also offenbar nichts mit Browser oder OS zu tun. Cache löschen und das ganze Brimborium habe ich natürlich schon probiert. Bin ich der einzige mit dem Problem? Was kann ich noch versuchen? Bin für jeden Hinweis dankbar. --Winof (Diskussion) 09:27, 13. Jul. 2018 (CEST)

• Ich kann ein solches Phänomen bestätigen.
• Gestern abend war wohl die wöchentliche Software-Aktualisierung.
• Ich bekam für die Beo und nur diese eine Meldung mw.loader.using is not a function (Zeile 156 von etwas nicht Identifizierbarem in der MW-Software).
• Das wäre doch recht besorgniserregend.
• Da ich viele Skripte zu laufen habe, bin ich schlechtes Versuchskarnickel für ein reines Gewissen.
• Nach Abschalten meiner Skripterei ging es fehlerlos, auch nach Wiedereinschalten der Skripte.
• Vermutlich gibt es im Browser-Gedächtnis, womöglich localStorage, ein Relikt der vergangenen Woche, das inkompatibel mit dem Beo-JS ist. Nachdem das einmal rausgeschmissen wurde, ist alles wieder heil.
• Irgendwie ist derzeit auch die Vorgabe am Migirieren von 3 auf 7 Tage, aber das wäre eine andere Geschichte.

Viel Erfolg --PerfektesChaos 10:26, 13. Jul. 2018 (CEST)

Hallo ihr beiden, wollte auch schon schreiben: kann Winof bestätigen (FF 61.0.1, 64-Bit), seit gestern desgleichen. Neuerdings aber: Wenn ich heute als erstes über ein Lesezeichen die Beo direkt aufrufe, werden die letzten Tage mit 250 Edits angezeigt, obwohl die „Anzuzeigende Zeitperiode“: auf „1 Stunde“ steht, obgleich auf „7 Tage“ in den Voreinstellungen festgelegt. Gruß, --Wi-luc-ky (Diskussion) 10:53, 13. Jul. 2018 (CEST)

@PerfektesChaos: Danke für die Hinweise. Ich verwende normalerweise den pageLinkHelper von Dir und Fliegelflagel von Schnark. Ich habe testweise meine common.js geleert und gepurged, aber das hat leider an dem Problem nichts geändert.

Ein Work-around, der funktioniert und mit dem ich leben kann: Ich habe in den Einstellungen den Zeitraum jetzt von 7 auf 8 Tage erhöht. Diese 8 Tage bleiben jetzt auf der Beobachtungsliste erhalten und werden nicht zurückgesetzt. Aber sobald ich wieder 7 Tage auswähle, wird es jedes Mal wieder auf 1 Stunde zurückgesetzt.

@Wi-luc-ky: Evtl. war das ein Missverständnis. Beim ersten Aufruf der Liste werden zwar die Edits von 7 Tagen angezeigt, aber das Formularfeld wird auf 1 Stunde zurückgesetzt. Sobald man nun auf den „Anzeigen“-Button klickt, werden tatsächlich nur die Edits der letzten Stunde angezeigt. Wenn man – wie ich – gewohnheitsmäßig öfters mal auf diesen Button klickt, um die Liste zu aktualisieren, dann muss man jedes Mal vorher das Formularfeld auf 7 Tage zurücksetzen.

Ahoi --Winof (Diskussion) 14:43, 13. Jul. 2018 (CEST)

So war’s gemeint, Winof, und so ist es auch bei mir beim Nachladen. Habe jetzt auch auf „8 Tage“ erhöht; „6 Tage“ gingen auch. Die verflixte 7 halt. (Der Vorschauknopf ist eigentlich groß genug, um solche Verschlimmbesserungen zu vermeiden; aber nicht alles ist gleich durch Vorschau überblickbar, leider.) Gruß, --Wi-luc-ky (Diskussion) 15:15, 13. Jul. 2018 (CEST)

Falsche Reihenfolge in Diff-Ansicht

Hallo,
bei dieser Änderung wird meine Antwort, die ich im Quelltext ganz unten angefügt hatte und die in der Leseansicht auch korrekt dort steht, in der Diff-Ansicht seltsamerweise weiter oben angezeigt. Bin verwirrt …
Grüße --Monow (Diskussion) 01:23, 17. Jul. 2018 (CEST)

Ich habe den Fehler als phab:T199770 gemeldet. Vor dem (meiner Ansicht nach ohnehin nicht wirklich erfolgreichem) Versuch, Verschiebungen in Versionsunterschieden anzuzeigen, trat der Fehler noch nicht auf. Alternativ kannst du in deinen Einstellungen die Beta-Funktion „Visuelle Unterschiede“ aktivieren, die zeigt den Versionsunterschied korrekt (wenn auch nicht wirklich gut) an. –Schnark 09:58, 17. Jul. 2018 (CEST)

Danke Dir für die Mühe --Monow (Diskussion) 20:17, 17. Jul. 2018 (CEST)

Edits mit Tablet / Ipad erschwert

DENN seid neuestem HABE ICH IMMER großbuchstaben, auch wenn ich die dauerhafte GROSSSCHREIBUNG PER FESTSTELLTASTE NICHT EINGESCHALTET HABE? . das ist nur beim SCHREIBEN VON ARTIKELn IN WIKIPEDIA? ERBITTE hilfe. --Orik (Diskussion) 13:32, 30. Jul. 2018 (CEST)

@Orik: Welcher Editor wird genutzt? Welcher Browser und welche Browserversion werden genutzt? Welche Betriebssystemversion wird genutzt? Geschieht dies auch wenn explizit safemode=1 gesetzt wird? --Malyacko (Diskussion) 12:13, 1. Aug. 2018 (CEST)

SORRY! DASS ICH MICH SO SPÄT MELDE, @Malyacko: ICH BIN IN ferien mit nicht so gutem Iternetanschluß. ich benutze den SAFARIBROWSER AUF EINEM IPAD MIT DEM (Betriebssystem für mobile GERÄTE) IoS 10.33. DIE VERSION von SAFARI IST NICHT ERSICHTLICH UND WIRD jeweils MIT DEM BETRIEBSSYSTEM ERneuert. DEr FEHLER MIT DER Klein- und GRossschreibung tritt nur beim editieren in Wikipedia auf. gruß --Orik (Diskussion) 00:48, 5. Aug. 2018 (CEST) PS: Den Editor kann ich nicht benennen.

PS: DER Fehler tritt nur bei Quelltextbearbeitung auf.--Orik (Diskussion) 09:51, 12. Aug. 2018 (CEST)

PROBLEM IMMER NOCH NICHT GELÖST. --Orik (Diskussion) 23:06, 30. Aug. 2018 (CEST)

Seit heute funktioniert die Groß- und Kleinschreibung mit dem Tablet wieder. Ebenso funtioniert das Löschen längerer Texte wieder, weil die Rückschrittaste nach einem bestimmten Anlauf wieder ganze Worte löscht.Orik (Diskussion) 01:50, 5. Sep. 2018 (CEST)

Menüzeilen nach unten verrutscht

Habe seit einigen Tagen ein sehr seltsames Phänomen. Beim unangemeldeten Aufruf einer WP-Seite z.B aus einem Lesezeichen oder über die FF-Erweiterung "Wikipedia (de)-Suche nach […]" Öffnet sich die Seite mit nach unten verrutschten Menüzeilen. Also die Zeile mit

| Nicht angemeldet | Diskussionsseite | Beiträge | Benutzerkonto erstellen | Anmelden |

und die Zeile

| Artikel | Diskussion | | Lesen | Bearbeiten | Quelltext bearbeiten | Versionsgeschichte | [Sucheingabefeld]

befinden sich deutlich nach unten verrutscht im Artikeltext. Dabei ist die obere Menüzeile transparent, die Worte vermischen sich mit den Worten aus dem Artikeltext, was es schwierig macht etwas zu lesen. Hingegen überlagert die zweite Menüzeile den Artikeltext, d.h. dieser ist hinter der verrutschten Menüzeile verschwunden bzw nicht zu lesen. Dabei bleiben alle Funktionen wie z.B. "Anmelden" oder "Suche" erhalten. Kaum angemeldet sind die Menüzeilen dann richtig am oberen Rand. Melde ich mich wieder ab, gehen sie wieder auf "Tauchstation". Dabei habe ich das Phänomen bisher nur bei Artikelseiten und Hilfeseiten gehabt, und zu allem tritt es nicht immer aber immer wieder auf. Löschen von Cache und Cookies sowie Browserneustarts haben nix gebracht. Hoffe es ist nur die Hitze und somit bald wieder vorbei. Oder ist das Problem bekannt?--Ciao • Bestoernesto • ✉ 01:19, 7. Aug. 2018 (CEST)

Momentan hat WMDE so eine Art Banner geschaltet, zur Gewinnung neuer Freiwilliger (wird nur Uangemeldeten gezeigt). Sieht so ähnlich aus wie die Banner bei den Spendenaktionen. Da du dieses Banner nicht erwähnt hast, vermute ich, daß du es nicht siehst?

Diese Banner kann man natürlich abschalten, via css, was unangemeldet nicht so ohne weiteres geht. Vielleicht hast du einen Werbeblocker o. ä., der das Banner löscht, den Text aber nicht wieder nach oben schiebt?

Unangemeldet ist bei mir jedenfalls das Banner sichtbar (kein Werbeblocker), der Text Artikel — Diskussion — Lesen — Bearbeiten etc. rutscht allerdings auch etwas tiefer und hängt mittig auf der Linie, die eigentlich ihren unteren Rahmen bildet. FF 61.0.1 übrigens.

Gruß --Schniggendiller Diskussion 01:46, 7. Aug. 2018 (CEST)

Hallo Schniggendiller, erst mal Danke für die Antwort. Wahrscheinlich hat das zum Teil wirklich was mit dem Banner zu tun, das ich tatsächlich nicht sehe in Folge meines Werbeblockers uBlock Origin, den ich auf Grund deiner Überlegungen mal vorübergehend abgeschaltet habe. Allerdings arbeitete dieser bis dato in der Hinsicht sehr zuverlässig, als dass freiwerdender Platz mit informativem Seiteninhalt befüllt wird. Das passiert in diesem Fall aber anscheinend nur mit dem Artikeltext/Hilfetext. Das Banner scheint nur mit den entsprechenden Seiten gekoppelt zu sein nicht aber mit der irgendwie überlagernden Menüzeilenebene. Da haben die Banner-Installateure vermutlich einfach nur eine platzhaltende Leerfläche eingebaut, die von uBlock Origin nicht als zu entfernende bzw zu blockierende Adware eingestuft wird und somit erhalten bleibt und dem Hochrutschen der Menüzeilen im Wege steht. (Sorry meine laienhafte Beschreibung). Dieser Aufbau der Bannereinblendung scheint sich diesmal aber von bisherigen Verfahren zu unterscheiden, da ich davon ausgehe, dass uBlock Origin mich im Laufe der Zeit schon öfters von WP-Bannern befreit hat, ohne dass dieses Phänomen bisher auftrat. Wäre also ein feiner Zug von den "Banner-Machern" wieder zum bisherigen Verfahren zurück zu kehren.--Ciao • Bestoernesto • ✉ 03:15, 8. Aug. 2018 (CEST)

Okay, da es also wohl tatsächlich am Banner liegt, lasse ich mal ein Ping da für Benutzer:Stefan Schneider (WMDE). Gruß --Schniggendiller Diskussion 12:49, 8. Aug. 2018 (CEST)

Hallo ihr Beiden, vielen Dank, dass ihr mich nochmal kontaktiert habt. Dann können wir das nämlich hoffentlich auch für die Zukunft korrigieren. Ich gebe das auf jeden Fall an die Software-Entwicklung weiter. Die Banneraktion ist seit heute 14:30 Uhr vorbei, daher sollten nun erst mal keine weiteren Probleme auftauchen. Lieben Gruß, Stefan Schneider (WMDE) (Diskussion) 14:45, 8. Aug. 2018 (CEST)

Quelltexteditor - der Unterschreibe-Button

Ach wie schön wäre es, wäre der Unterschreibe-Button nicht ausgerechnet über dem Editorfenster, sondern darunter, nämlich da, wo man speichert / veröffentlicht. Genau dann brauche ich den nämlich, und es ist so gut wie der einzige der Buttons dort, den ich je brauche. Bei genauer Betrachtung gilt das natürlich für sämtliche Funktionen über dem Editorfenster, alle braucht man während des Schreibens, und der Schreibcursor ist nunmal (außer bei extrem kurzen Texten) unten im Fenster. Ich habe das Editorfenster mit Absicht recht groß eingestellt und deshalb nervt es, wenn diese Funktionen oberhalb des Bildschirms sind. Geht das nur mir so? --Karsten Meyer-Konstanz (D) 10:38, 8. Aug. 2018 (CEST)

Das geht wohl mit css. Hast du Monobook oder Vector? Hast du "Erweiterte Bearbeiten-Werkzeugleiste aktivieren" an? Leider nennen sich die Abschnitte alle anders, daher muss man das überall anpassen. --Wurgl (Diskussion) 20:18, 8. Aug. 2018 (CEST)

Hab ein bisschen gespielt: Mit erweiterter Bearbeiten-Werkzeugleiste schreibst du folgendes in deine common.css:

.wikiEditor-ui-left { display: flex; flex-direction: column; }
.wikiEditor-ui-top { order: 2; }    /* Die Knöpfe (erweiterte Werkzeugleiste) */
.wikiEditor-ui-botton { order: 1; } /* Das Editfenster (erweiterte Werkzeugleiste) */
#editform { display: flex; flex-direction: column; }
#toolbar { order: 2; }      /* Die Knöpfe (ohne erweiterte Werkzeugleiste) */
#wpTextbox1 { order: 1; }   /* Das Editfenster (ohne erweiterte Werkzeugleiste) */
.editOptions { order: 3; }  /* Block Zusammenfassung         hier: vor den Sonderzeichen */
.mw-editTools { order: 4; } /* Die Zeile mit Sonderzeichen */
.wikibase-entity-usage { order: 5; } /* In Änderungen zeigen und Vorschau die Wikidata-Objekte */
.templatesUsed { order: 6; } /* In Änderungen zeigen und Vorschau die Templates */
.hiddencats { order: 7; } /* Vorschau */
.limitreport { order: 8; } /* Vorschau */

Wenn du zusätzlich die Leiste mit den Sonderzeichen ebenfalls vor der Zusammenfassung haben willst, dann einfach die letzten beiden Zeilen so:

.editOptions { order: 4; }  /* Block Zusammenfassung         hier: nach den Sonderzeichen */
.mw-editTools { order: 3; } /* Die Zeile mit Sonderzeichen */

--Wurgl (Diskussion) 21:07, 8. Aug. 2018 (CEST)

Alternativ sind doch die klassischen Edittools schon unterhalb der Textbox mit Sig-Zeichen!? Ansonsten kannst du auch mein AutoSig-Script benutzen, dort ist u.a auch ein Extra-Sig-Button unter der Textbox. Allerdings brauchst du diesen fast nicht, da wie der Name schon sagt, automatisch unterschrieben wird. MfG -- User: Perhelion 21:32, 8. Aug. 2018 (CEST)

noch 4 weitere Zeilen für notwendig – fixed --Wurgl (Diskussion) 21:44, 8. Aug. 2018 (CEST)

Recht herzlichen Dank für die schnelle Hilfe! Eigentlich hatte ich das eher als Anregung verstanden, dieses UI generell umzustellen. Aber nachdem sich Wurgl so viele Arbeit gemacht hat: Ich weiß bis heute nicht, was es mit Monobook und Vector auf sich hat, auch wenn ich diese Begriffe hier ab und zu finde. Und leider verstehe ich die Antwort von User: Perhelion überhaupt nicht: Was meinst du bitte für eine Alternative? Ich sehe da nur "Zusammenfassung ... und die beiden Buttons "Nur Kleinigkeiten ..." und "Diese Seite beobachten". Vielen Dank und schönen Gruß, ***scrollnachoben-signierbuttonsuch*** --Karsten Meyer-Konstanz (D) 11:31, 9. Aug. 2018 (CEST)

Einstellungen --> Reiter Aussehen. Dort kannst du das "Skin" einstellen und da gibt es eben Monobook, Vector, Kölnisch Blau und noch ein paar (je nach Geschmack mag man das umschalten oder auch nicht). --Wurgl (Diskussion) 11:46, 9. Aug. 2018 (CEST)

Hilfe:Symbolleisten #Edittools dort sind auch die 4 Tilden abgebildet (wenn du auf Commons schaust so ist diese gleich unterhalb der Textbox). Hier in De scheinen die Edittools (bei mir?) nicht richtig mit dem CodeMirror zu funzen. @Vector: → Hilfe:Skin -- User: Perhelion 11:48, 9. Aug. 2018 (CEST)

Nochmals recht herzlichen Dank Euch beiden! Ich glaub, diese Zeile mit Sonderzeichen da unten hab ich noch nie wahrgenommen - vielen Dank fürs Augen öffnen, ***schäm***, User: Perhelion. Und jetzt hab ich dein tolles signing.js installiert und mal gucken, was passiert. 1000 Dank und schönen Gruß, -- Karsten Meyer-Konstanz (D) 14:45, 9. Aug. 2018 (CEST) -Wow, klapptja prima, wenn auch mit einem Leerzeichen zwischen den Strichen und Tilden.

Wäre es einfach möglich, noch nie gesichtete Artikel von der Suchmaschinen-Indexierung auszuschliessen?

Ich habe auf WP:FzW diese Frage gestellt: WP:FzW#Warum werden ungesichtete Artikel von Suchmaschinen indiziert?. Dazu gab es bisher keine Verweise auf Projektdiskussionen, etc. Bevor ich jetzt eine solche anstoße, um hoffentlich einen Konsens für den Ausschluss von noch nie gesichteten Artikeln zu finden, meine Frage an Euch: Wäre das einfach technisch umzusetzen?

Zusatzinfos: In der enWP sind noch nicht patrouillierte Seiten, die jünger als 90 Tage sind, von der Indexierung ausgenommen. Im Phabricator habe ich zu "flagged revisions" und noindex und ähnlichen Sucheingaben nichts gefunden. --Count² (Diskussion) 16:57, 8. Aug. 2018 (CEST)

Die dort verwendete Programmierung schließt offenkundig alle Artikel jünger als (90) Tage von der Indexierung aus, völlig egal ob diese „patrouilliert“ sind oder nicht.

Das würde heißen, dass auch bei uns ein Artikel zu einem aktuellen Ereignis, der noch nicht ein Alter von x Tagen erreicht hätte, von Suchmaschinen nicht erwähnt werden soll. Dabei ist es völlig egal, ob er gesichtet wäre oder nicht.

Das wird wohl kaum auf breite Zustimmung stoßen.

Um die Frage im Sinne der Überschrift zu beantworten: Technisch möglich schon, auch diese Bedingung in der Programmierung einzubauen; aber da es nur sehr wenige Wikis beträfe, die Programmierung deutlich verkomplizieren und schwerer zu pflegen macht und der allgemeine Trend eher zu Vereinfachung und Entschnörkelung geht, werden die Entwickler kaum mitspielen.

Eine lokale Alternative wäre es, dass du einen Bot-Betreiber überredest, ein NOINDEX (ggf. in auffindbarer Vorlage, mit Kategorisierung als „Neuer Artikel“) in die noch nie gesichteten Artikel einzubauen, und der erste Sichter oder ein späterer Bot-Lauf diese Vorlage dann wieder herauseditiert, wobei Entfernung durch den anlegenden Nicht-Sichter zwecklos wäre, weil der Bot immer wieder kommt.

VG --PerfektesChaos 17:20, 8. Aug. 2018 (CEST)

Danke für die schnelle Antwort! Ein kurzer Einwand: In der enWP werden patroullierte Seiten durchaus schon früher freigegeben („Articles younger than 90 days are not indexed, unless they have been patrolled and do not have the {{NOINDEX}} template on them (or a template that transcludes the {{NOINDEX}} template, such as the speedy deletion templates).“ Fettung von mir), siehe auch en:WP:NPP: „Only New Page Reviewers can mark pages as 'Reviewed' or 'Patrolled' which releases them for indexing by search engines.“ Das mit dem Bot ist aber eine gute Idee! --Count² (Diskussion) 17:26, 8. Aug. 2018 (CEST)

Bei einem Bot gibt es eine Race-Condition zwischen dem Crawler der Suchmaschine und unserem Bot. Wer schneller ist, gewinnt. Das wäre dann so eine halbe Sache, die nicht gar so toll funktioniert. --Wurgl (Diskussion) 17:35, 8. Aug. 2018 (CEST)

Stimmt auch wieder inbesondere da neue Artikel extrem schnell von Google indexiert werden. Da das aber in der enWP so ähnlich funktioniert (nur mit "patrolled" anstelle von "flagged revisions") wäre das ja vielleicht doch gar nicht so schwer zu implementieren? --Count² (Diskussion) 17:38, 8. Aug. 2018 (CEST)

• In der fraglichen Server-Programmierung steht bis heute nur eine Abhängigkeit vom Alter der Seite, egal was sonst noch für ein Status vorläge. Mechanismen, die das übersteuern würden, etwa durch temporären Einbau eines INDEX, sind bei der enWP nirgendwo konkretisiert worden. Es sind erstmal einfach nur Behauptungen auf der Projektseite.
• Wer das race gewinnen würde, unser lauschender Bot oder ein lauschender Crawler, ist offen. Wenn beide das Ohr am selben Kanal haben, klar. Aber wenn wir einführen würden, dass für 24 oder 48 Stunden nach Anlage im ANR das serverseitige NOINDEX automatisch greifen würde, dann wäre Zeit genug für SLA und erste QS, und auch ein Bot könnte ganz in Ruhe eine entsprechende Vorlage einbauen, falls nicht von Sichter angelegt, und könnte damit auch noch ein sichtbares Kästchen mit einem grünen Bäumchen generieren: „Dieser Artikel ist noch ganz jung, wir kennen den selbst noch nicht richtig.“

VG --PerfektesChaos 17:48, 8. Aug. 2018 (CEST)

Die Idee mit dem Bäumchen ist Klasse! --Wurgl (Diskussion) 17:54, 8. Aug. 2018 (CEST)

Hmm, irgendwie/irgendwo ist die Entscheidung nach patrouilliert aber implementiert. So enthält der neue noch nicht patrouillierte Artikel en:USA-130 en:White_N3rd <meta name="robots" content="noindex,nofollow"/> während der autopatrouillierte Artikel en:Sorcerer_of_Siva es nicht enthält. --Count² (Diskussion) 18:04, 8. Aug. 2018 (CEST)

Hier ist die Dokumentation dazu und hier ist der Sourcecode (Function shouldShowNoIndex()). Bei uns wird die Indexierung wohl in setRobotPolicy() in der FlaggedRevs extension bestimmt. So werden wohl auch jetzt schon nur gesichtete Versionen bei uns indexiert, wenn der Artikel gesichtete Versionen hat. Wenn der Artikel aber noch nie gesichtet wurde, zieht die Mediawiki-Standardstrategie. --Count² (Diskussion) 19:02, 8. Aug. 2018 (CEST)

Nur ein kurzer Hinweis: {{NOINDEX}} hat im ANR per Definition bei uns keine Wirkung. Siehe mw:Manual:$wgExemptFromUserRobotsControl/de. Ob die Extension PageTriage für uns eine Lösung ist, mag ich auf die Schnelle nicht beurteilen. — Raymond ^Disk. 19:20, 8. Aug. 2018 (CEST)

Auch nur ein kurzer Hinweis: Google crawlt (fast) keine Seiten in Wikipedia, sondern verwendet verschiedene andere Quellen wie die Letzten Änderungen, ORES, Wikidata, RESTBase (Parsoid), Action-API, etc. –Schnark 11:58, 9. Aug. 2018 (CEST)

Neue, noch nie gesichtete Artikel, findet Google jedenfalls schnell und indexiert sie auch umgehend. Soweit mir bekannt, beachtet Google aber meta noindex und könnte damit von einer Indexierung abgehalten werden. --Count² (Diskussion) 18:18, 9. Aug. 2018 (CEST)

Kann mir jemand weiter Helfen Ist diese seite nicht mehr in Betrieb

https://tools.wmflabs.org/wiwosm/osm-on-ol/kml-on-ol.php?lang=de&uselang=de&zoom=5&lat=51.70274&lon=10.1479

War eine super hilfreich seite für infos mir wikidaten und Ortschaften (nicht signierter Beitrag von 2a02:120b:c3ca:f5b0:4074:6da6:c781:6153 (Diskussion) 09:42, 20. Aug. 2018 (CEST))

@Kolossos: Vermutlich dieses Ticket: phab:T201544? --тнояsтеn ⇔ 10:46, 20. Aug. 2018 (CEST)

Abfrage Benutzer

Hallo, ich bin grad nicht auf dem Laufenden, ob es ein Tool gibt oder wer mir hier helfen könnte: wir möchten für ein Event eine Liste von Benutzerinnen/Benutzern aus der Kategorie:Benutzer:aus Köln, die in den letzten beiden Jahren „n“ Bearbeitungen hatten. Gibt's da was? Danke für eure Hilfe. --elya (Diskussion) 22:33, 23. Aug. 2018 (CEST)

Hier habe ich eine entsprechende Datenbankabfrage erstellt: Liste aller Benutzer aus der Kategorie:Benutzer:aus Köln, die in den letzten beiden Jahren mehr als 200 Bearbeitungen (über alle Namensräume) hatten, alphabetisch sortiert. --Count² (Diskussion) 23:48, 23. Aug. 2018 (CEST)

Count², tausend Dank, das hilft mir sehr weiter, ich hab's schon geforkt und spiele damit rum. Hab's an unserem GLAM-Wochenende gar nicht gesehen, dass das so schnell ging. --elya (Diskussion) 18:44, 26. Aug. 2018 (CEST)

Gern geschehen. Mir hat es Spaß gemacht, mich ein bisschen mit dem MediaWiki-Datenbankschema vertraut zu machen. --Count Count (Diskussion) 18:54, 26. Aug. 2018 (CEST)

Einleitungen verschwinden

Nach einer mehrtägigen WP-Pause habe ich plötzlich einen eigenartigen Einleitungs-Schwund im angemeldeten genauso wie im unangemeldeten Zustand. Egal ob ich einen Artikel durch einen Wikilink, einen Begriff aus der WP-Suchzeile oder aus der Browser-Suchzeile aufsuche, erscheint dieser ohne Einleitung. Es geht sofort mit dem Inhaltsverzeichnis los. Eine Ausnahme davon bilden Einleitungen mit mehreren Absätzen. Da verschwindet nur der erste Absatz. Außerdem bleiben die ggf in der Einleitung eingebauten Bilddateien unbetroffen. Die Bilder werden immer angezeigt, egal ob der Dateilink am Anfang oder am Ende des Einleitungs-Quelltextes eingefügt ist. In der En- und Fr-WP taucht das Phänomen nicht auf. Irgendwie erinnerte mich das ganze an den Problemfall Menüzeilen nach unten verrutscht hier weiter oben, wo sich auch Benutzer:Schniggendiller und Benutzer:Stefan Schneider (WMDE) bemüht haben. In Anlehnung der dortigen Erfahrung schaltete ich meinen Ad-Blocker uBlock Origin mal ab, und siehe da, Einleitungen sind plötzlich in vollem Unfang wieder zu sehen. Da ich an den uBlock Origin-Einstellungen schon seit Monaten nix mehr gedreht habe, befürchte ich einen neuen WP-Bug. Da mittlerer Weile viele Millionen chrome-FF-MS-Edge-Opera-usw-User uBlock Origin nutzen dürfte ich wohl nicht der einzige Betroffene sein.--Ciao • Bestoernesto • ✉ 04:18, 27. Aug. 2018 (CEST)

Tritt der Fehler auch auf, wenn Du dir die Seite unangemeldet anschaust? Gruß --Schniggendiller Diskussion 07:58, 27. Aug. 2018 (CEST)

Ja, im angemeldeten genauso wie im unangemeldeten Zustand, steht gleich im ersten Satz ;-) --Ciao • Bestoernesto • ✉ 08:26, 27. Aug. 2018 (CEST)

<quetsch>Ups, nicht mein Tag … --Schniggendiller Diskussion 11:51, 27. Aug. 2018 (CEST)

Tritt der Fehler auch mit anderen Skins auf (und welchen Skin benutzt du)? Sieht nach irgendeinem Tag aus, das uBlock Origin inkonsistent entfernt. --mfb (Diskussion) 09:49, 27. Aug. 2018 (CEST)

Skin? Sorry mfb, bin mit diesen IT-Fachbegriffen nicht ganz so fit. Wenn Du damit das Erscheinungsbild der Bedienungsoberfläche meinst, "Vektor" (schon immer, habe an meinen WP-Einstellungen auch seit Monaten nix geändert, somit fallen diese als Ursache für den plötzlichen "Einleitungsschwund" eigentlich aus. Habe aber auf deine Frage hin jetzt mal alle Skins durchprobiert, mit dem gleichen Ergebns)--Ciao • Bestoernesto • ✉ 16:30, 27. Aug. 2018 (CEST)

Welchen Browser verwendest du? --Count Count (Diskussion) 16:33, 27. Aug. 2018 (CEST)

Firefox--Ciao • Bestoernesto • ✉ 16:55, 27. Aug. 2018 (CEST)

Hmm, mit Firefox Quantum 61.0.2 (64-bit) und uBlock Origin 1.16.20 auf Windows 10 kann ich das nicht reproduzieren. Welche Versionen hast du? --Count Count (Diskussion) 17:02, 27. Aug. 2018 (CEST)

Da scheint sich bei uBlock Origin was getan zu haben. Bei meinem letzten "Problem-Besuch" hier hatte ich noch v1.16.16; Als ich vorhin neu startete wurde dabei anscheinend auch bei mir auf v1.16.20 aktualisiert, und siehe da, nix isses mehr mit "Einleitungs-Schwund". Danke an alle, die hier versucht habe mir zu helfen--Ciao • Bestoernesto • ✉ 03:26, 28. Aug. 2018 (CEST)

reviewwrapped

Gemeldet in Phabricator
Task T203294

Steckt da ein Fehler drin? Siehe hier: Wikipedia:Fragen zur Wikipedia#reviewwrapped. --Zahnputzbecher (Diskussion) 14:27, 3. Sep. 2018 (CEST)

Ja, bedauerlicher Tippfehler eines lieben Kollegen im Rahmen einer ausgedehnten Änderung; ein $ ging verloren.

Es war um backporting gebeten worden; die schon längst erfolgte Korrektur sollte in die momentanen live-Versionen rückwirkend eingespielt werden.

Das ist dann wohl offenkundig nicht erfolgt; nun kommt es unaufgefordert Donnerstag abend mit der regulären Auffrischung.

LG --PerfektesChaos 14:31, 3. Sep. 2018 (CEST)

Vorlage:Annotiertes Bild

Hallo, die Vorlage wird in der Mobilversion und im Modern-Skin nicht korrekt dargestellt, siehe auch Hilfe_Diskussion:Bilder#Annotierte_Mona_Lisa. Grüße, --Ghilt (Diskussion) 10:38, 4. Sep. 2018 (CEST)

Ergänzung zur Fehlerbeschreibung: in der Doku der Vorlage ist eine Beispiel (Nase der Monalisa) eingebunden. Den Fehler reproduziert man am schnellsten, indem man die Beschreibung der Vorlage aufruft und dann unten auf 'Mobile Ansicht' klickt.

Weitere Ergänung der Fehlerbeschreibung: ruft man die Vorlage in enWP auf (en:Template:Annotated image), dann sieht man das dort das gleichen Monolisa-Nase-Beispiel eingebunden ist (kein Wunder weil die deWP-Version von dort kopiert wurde). Jetzt das überraschenden: klickt man bei enWP auf 'Mobile View' erscheint alles korrekt.

Work Arround: ohne viel zu Analysieren würde ich einefach die de-Vorlage einfach mit der en-Vorlage überschreiben und das wichtigste (Übersetzung der Doku) erneut ausführen.

Fazit (falls der Woraround funktioniert): man sollte bei Kopien möglichst nahe bei Original bleiben.

Wer Lust hat darf natürlich auch Analysieren bis er schwarz wird ... man soll bekanntlich beim Analysieren den Denkapparat trainieren. --Summer • Streicheln • Note 12:44, 4. Sep. 2018 (CEST)

Das Fazit ist m.E. nicht korrekt, denn die Vorlage wurde 2015 originalgetreu übersetzt und beide Vorlagen wurden nachträglich bearbeitet. Aber die en-Version erneut zu übernehmen sollte vermutlich funktionieren. --Ghilt (Diskussion) 13:16, 4. Sep. 2018 (CEST)

Ich habe mal die deWP-Vorlage in der ätesten Version aufgerufen ( https://de.wikipedia.org/w/index.php?title=Vorlage:Annotiertes_Bild&oldid=144153776 ) und auf Mobile Ansicht geklickt. Der Fehler ist sichtbar. Inzwischen gehe ich daher davon aus, das der Fehler in den StyleSheets der deWP liegt (Gegenprobe: bei Moblie view einer alten enWP Version ist kein Fehler zu sehen). --Summer • Streicheln • Note 14:41, 4. Sep. 2018 (CEST)

Vorhin hatte ich die Vorlage aus en.wp erneut übernommen, und es sieht nun in der Mobilversion m.E. gut aus. Warten wir noch ab, ob es im Modern skin auch ok ist, dann können wir hier schließen, Grüße, --Ghilt (Diskussion) 14:44, 4. Sep. 2018 (CEST)

Ich sehe es auch so, das der Fehler nun weg ist. Ich habe nebenbei Denkfehler gemacht. Darf man gerne im Nachgang drüber reden ... aber ohne mich :-) --Summer • Streicheln • Note 14:51, 4. Sep. 2018 (CEST)

Dieser Abschnitt kann archiviert werden. Ghilt (Diskussion) 09:14, 5. Sep. 2018 (CEST)