Wikipedia:Technik/Werkstatt

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

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

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

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

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

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

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


Neue Frage stellen Neue Frage stellen

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

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

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


Inhaltsverzeichnis

Dauerbaustellen; Spezifikationen für wünschenswerte Werkzeuge[Bearbeiten]

  • Echo-Filter
  • Vorlagenmeister
  • 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[Bearbeiten]

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

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

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

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

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

GeSHi für Wikitext[Bearbeiten]

Bekanntlich gibt es noch keine Möglichkeit mit Hilfe:Syntaxhighlight MediaWikis Wikitext etwa auf Hilfeseiten mit einer Syntaxhervorhebung zu versehen. Das hat nur zum Teil etwas damit zu tun, dass es beinahe unmöglich ist, hauptsächlich liegt es aber daran, dass sich einfach noch niemand die Mühe gemacht hat, die entsprechende Syntaxhervorhebung zu programmieren. Deshalb habe ich jetzt mal einen Anfang gemacht, würde mich aber über Mithilfe sehr freuen. Wer helfen will, sollte sich zunächst einmal die Datei für HTML5 ansehen, dann die Dokumentation lesen. Zum Testen muss man MW+mw:Extension:SyntaxHighlight GeSHi installiert haben, das folgende als mediawiki.php bei den anderen Dateien speichern; dann funktioniert <syntaxhighlight lang="mediawiki">. Gleich als Vorwarnung, unser Wikitext hier ist keine Sprache, sondern ein großes Chaos, man sollte also nicht erwarten, dass die Syntaxhervorhebung wirklich gut funktioniert, man kann nur versuchen, dass es einigermaßen stimmt. Verbesserungen können gleich in den Code eingefügt werden, wenn dann alle hier zufrieden sind, schaue ich mal, dass ich den Entwickler von GeSHi davon überzeugen kann, das in die nächste Version aufzunehmen, und dann jemand bei MW finde, der unsere Erweiterung entsprechend aktualisiert. --Schnark 11:28, 1. Jun. 2012 (CEST)

<?php
/*************************************************************************************
 * mediawiki.php
 * ---------------
 * Author:
 * Copyright:
 * Release Version: 
 * Date Started: 
 *
 * MediaWiki wikitext language file for GeSHi.
 *
 * CHANGES
 * -------
 *
 * TODO
 * -------------------------
 *************************************************************************************
 *
 *     This file is part of GeSHi.
 *
 *   GeSHi is free software; you can redistribute it and/or modify
 *   it under the terms of the GNU General Public License as published by
 *   the Free Software Foundation; either version 2 of the License, or
 *   (at your option) any later version.
 *
 *   GeSHi is distributed in the hope that it will be useful,
 *   but WITHOUT ANY WARRANTY; without even the implied warranty of
 *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *   GNU General Public License for more details.
 *
 *   You should have received a copy of the GNU General Public License
 *   along with GeSHi; if not, write to the Free Software
 *   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 *
 ************************************************************************************/
 
$language_data = array (
    'LANG_NAME' => 'Wikitext (MediaWiki)',
    'COMMENT_SINGLE' => array(),
    'COMMENT_MULTI' => array(),
    'CASE_KEYWORDS' => GESHI_CAPS_NO_CHANGE,
    'QUOTEMARKS' => array("'", '"'),
    'ESCAPE_CHAR' => '',
    'KEYWORDS' => array(
        1 => array( // allowed HTML tags
            'abbr', 'b', 'bdi', 'big', 'blockquote', 'br',
            'caption', 'center', 'cite', 'code',
            'dd', 'del', 'dfn', 'div', 'dl', 'dt', 'em',
            'font', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'hr',
            'i', 'ins', 'kbd', 'li', 'ol', 'p', 'pre', 'q',
            'rb', 'rp', 'rt', 'ruby', 's', 'samp', 'small',
            'span', 'strike', 'strong', 'sub', 'sup',
            'table', 'td', 'th', 'tr', 'tt', 'u', 'ul', 'var'
            ),
        2 => array( // standard tags and common extensions
            'gallery',
            'ref', 'references',
            'poem',
            'categorytree'
            ),
        3 => array( // attributes for HTML tags
            'class', 'dir', 'id', 'lang', 'style', 'title'
            ),
        4 => array( // attributes for other tags
            'group', 'name' // for ref
            )
        ),
    'SYMBOLS' => array(
        '/', '=', // in tags
        '[', ']', '{', '}', '|', '|-', '|+', '!' // other (mainly tables)
        ),
    'CASE_SENSITIVE' => array(
        GESHI_COMMENTS => false,
        1 => false,
        2 => false,
        3 => false,
        4 => false
        ),
    'STYLES' => array(
        'KEYWORDS' => array(
            1 => 'color: #000000; font-weight: bold;',
            2 => 'color: #000000; font-weight: bold;',
            3 => 'color: #000066;',
            4 => 'color: #000066;'
            ),
        'COMMENTS' => array(
            ),
        'ESCAPE_CHAR' => array(
            0 => ''
            ),
        'BRACKETS' => array(
            0 => 'color: #66cc66;'
            ),
        'STRINGS' => array(
            0 => 'color: #ff0000;'
            ),
        'NUMBERS' => array(
            0 => 'color: #cc66cc;'
            ),
        'METHODS' => array(
            ),
        'SYMBOLS' => array(
            0 => 'color: #009900;'
            ),
        'SCRIPT' => array(
            0 => 'color: #000000;', // nowiki
            1 => 'color: #808080; font-style: italic;', // comments
            2 => 'color: #500000;', // nowiki-like tags (math, syntaxhighlight)
            3 => 'color: #aa8000;', // &abc;
            5 => 'color: #000000; font-weight: bold;', // headlines
            7 => 'color: #000000; text-decoration: underline;', // weblinks
            8 => 'color: #009900;', // lists
            9 => 'color: #000099;', // bold, italic
           10 => 'color: #000099;' // magic words
            ),
        'REGEXPS' => array(
            )
        ),
    'URLS' => array(
        1 => '',
        2 => '',
        3 => '',
        4 => ''
        ),
    'OOLANG' => false,
    'OBJECT_SPLITTERS' => array(
        ),
    'REGEXPS' => array(
        ),
    'STRICT_MODE_APPLIES' => GESHI_ALWAYS,
    'SCRIPT_DELIMITERS' => array(
        0 => array(
            '<nowiki>' => '</nowiki>'
            ),
        1 => array(
            '<!--' => '-->'
            ),
        2 => array( // nowiki-like tags, may have attributes
            '<math' => '</math>',
            '<syntaxhighlight' => '</syntax' + 'highlight>',
            '<source' => '</source>'
            ),
        3 => array(
            '&' => ';'
            ),
        4 => array(
            '<' => '>'
            ),
        5 => array( // headlines
            "\n======" => '======',
            "\n=====" => '=====',
            "\n====" => '====',
            "\n===" => '===',
            "\n==" => '==',
            "\n=" => '='
            ),
        6 => array( // tables, wikilinks, templates
            '{|' => '|}',
            '[[' => ']]',
            '{{' => '}}'
            ),
        7 => array( // weblinks
            '[http://' => ']',
            '[https://' => ']',
            '[//' => ']',
            '[ftp://' => ']'
            ),
        8 => array( // lists (yes, this is a hack)
            "\n*" => ' ',
            "\n#" => ' ',
            "\n:" => ' ',
            "\n;" => ' '
            ),
        9 => array( // bold, italic
            "'''''" => "'''''",
            "'''" => "'''",
            "''" => "''"
            ),
       10 => array( // magic words
            '__' => '__'
            )
    ),
    'HIGHLIGHT_STRICT_BLOCK' => array(
        0 => false,
        1 => false,
        2 => false,
        3 => false,
        4 => true,
        5 => false,
        6 => true, // to highlight symbols inside
        7 => false,
        8 => false,
        9 => false,
       10 => false
        ),
    'TAB_WIDTH' => 4,
    'PARSER_CONTROL' => array(
    )
);
 
?>
Das könnte man mal auf Beta-Wiki ziehen, wirklich schade drum. Ich habe den Code mal bei der Extension auf der Diss. erwähnt. Perhelion     22:20, 9. Jun. 2014 (CEST)

Fehler beim Zusammenspiel zwischen HotCat und bkl-check[Bearbeiten]

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

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

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

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


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


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

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

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

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


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

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

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

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

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

OpenStreetMap-Karte bei HTTPS[Bearbeiten]

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

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

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

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

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

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

besser:

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

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

Auch die folgenden Links sollten in protokollrelative Links gewandelt werden:

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

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

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

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

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

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

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

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

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

Datei-Sichtung effizienter gestalten[Bearbeiten]

Da immer schon sehr viele Dateien ungesichtet und so anfälliger auf Vandalismus sind, habe ich mir überlegt, wie die Erstsichtung effizienter gestaltet werden könnte. Dabei sind mir zwei Möglichkeiten in den Sinn gekommen:

  • JS: In der Liste der ungesichteten Dateien zusätzlich angeben, wie ob mehrere Versionen existieren oder nur eine. In letzterem Fall müsste die Versionsgeschichte nicht angeschaut werden.
  • pywikipedia: Sichtung nach Uploader (der eingegeben werden müsste), filtern auf Dateien mit nur einer Version oder nur vom Uploader bearbeitet. Bei vertrauenswürdigen Uploadern kann so Vandalismus ausgeschlossen werden und ein kurzer Blick auf die aktuelle Version des Dateibeschreibungs-Quellcodes reicht.

--Leyo 13:29, 3. Okt. 2012 (CEST)

WP:FR#Kleines Dankeschön an IPs[Bearbeiten]

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

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

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

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

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

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

Beim Vorschlag geht es um eine „Einklicklösung“. Es gibt ja etliche Skripte Huggle, etc., die beim Revert auch gleich einen Baustein wie {{Test}} auf der IP-Disk. absetzen. Ich stelle es mir in dieser Art vor, nur halt positiv statt negativ.
Dementsprechend könnten existierende Skripte angepasst und müssten nicht neu geschrieben werden. --Leyo 17:36, 20. Okt. 2012 (CEST)
Der Benutzer:Schnark/js/wikieditor hat seit kurzem einen Knopf für {{Willkommen}}. Ansonsten ist Benutzer:Schnark/js/autoantraege wohl das was du suchst. Auch dieses Skript kann Standardtexte auf der Benutzerdiskussionsseite hinterlassen. Gruß Matthias (Diskussion) 22:42, 20. Okt. 2012 (CEST)
Ich möchte es ja nicht nur für mich, sondern für eine breitere Anwendung, damit IPs nicht immer nur getadelt, sondern (mit geringtem Aufwand) gelobt werden. Beim obigen Kommentar hatte ich insbesondere an Benutzer:DerHexer/rollback.js, aber auch an Scripts wie Benutzer:Schnark/js/autoantraege gedacht. --Leyo 22:52, 20. Okt. 2012 (CEST)
Erstmal schönen Urlaub, oder was immer du geplant hast.
Die Geschichte ist noch nicht operational.
  1. Inwieweit deckt das existierende aber in der deWP nicht aktivierte WikiLove den Wunsch bereits ab, oder könnte es das nicht?
  2. Eine Spezifikation scheint vielleicht wie folgt zu lauten, soweit ich die nebelhaften Vorstellungen bislang durchschauen konnte:
    • Interaktive Auslösung, individuell konfigurierbar
      • Wenn auf einer Seite im ANR, dann Portlet-Link einfügen
      • oder zusätzlich: Wenn Sichtungs-Buttons auf der Seite sichtbar sind, dann füge einen weiteren Button hinzu
      • und außerdem stelle per API eine .fire()-Funktion für eigene GUI-Wünsche bereit; eine solche .fire()-Funktion wird ohnehin für Portlet-Link usw. benötigt und kann dann auch öffentlich gemacht werden.
    • Wenn ausgelöst wird, dann
      • Mache eine API-Abfrage, welcher Benutzer die RevID der aktuell angezeigten Seitenversion editiert hatte, oder lies das aus den Strukturen einer (Sichtungs-)Diffpage heraus.
      • Zeige inzwischen ein Formular zum Zusammenbau eines Textes an.
        • Vorgegebene Standard-Phrasen für alle Gadget-Nutzer, zum Anklicken.
        • Individuell konfigurierte Standard-Phrasen, zum Anklicken.
        • Feld für Freitext.
        • Buttons für Abschicken/API, Manueller Edit, Abbrechen.
      • Wenn Submit, dann bearbeite die Disku des inzwischen (per API?) ermittelten Benutzers (bzw. IP). Füge den zusammengestoppelten Text ein, zusammen mit Backlink auf die bearbeitete Seite und Signatur, Disku-Überschrift und ggf. Neuanlage einer nicht existierenden BD.
        • Ob es sich überhaupt lohnt, für diese letzte Phase ein externes Skript mit völlig anderer Methodik auch noch einzubinden (DerHexer/rollback.js, Schnark/js/autoantraege) oder ob das nicht größeren Aufwand und Probleme verursacht als das integriert selbst vorzuhalten steht dahin. Eigentlich sind das dann nur noch wenige Statements.
  3. Der Überschrift dieses Thread entnehme ich, dass IPs gemeint wären. Der sonstigen Diskussion entnehme ich, dass seit kurzem angemeldete Benutzer gemeint wären, die noch kein Sichterrecht hätten. Wie denn nun?
LG --PerfektesChaos 13:29, 21. Okt. 2012 (CEST)

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

  • Fall A): Ich will nur mal schnell eine IP für ihren Beitrag loben. In der Sichtungsbox (oder in meiner Beobachtungsliste oder in der Versionsgeschichte) klicke ich auf den "WikiDank"-Button Redwikiheart-12M.png, die Dialogbox öffnet sich (ohne das ich dabei ja die Seite verlasse). Ich klicke einfach nur auf "senden" (und ignoriere das optionale Texteingabefeld), damit wird folgendes automatisch auf die IP-Diskussionsseite geschrieben (voreingestelltes Bild und der Standardtext):
Schnittblumenstrauss.jpg Einfach mal ein kleines Dankeschön für Deinen Beitrag in Liste der Universitäten in Ghana...

von Atlasowa (Diskussion) 16:28, 29. Okt. 2012 (CET)

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

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

Boah, gute Arbeit mit den Koordinaten, das kriege ich immer nicht richtig hin! Prost! --Atlasowa (Diskussion) 16:28, 29. Okt. 2012 (CET)

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

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

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

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

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


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

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

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

Erweiterung der Signatur-Zeitstempel auf Diskuseiten[Bearbeiten]

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

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

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

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

Benutzernamen aus Signaturlink anzeigen?[Bearbeiten]

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

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

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

darstellung von thumbs[Bearbeiten]

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

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

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

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

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

HTTP bei HTTPS[Bearbeiten]

Ab Firefox 23 werden auf HTTPS-Seiten Einbindungen von HTTP blockiert (http://www.heise.de/newsticker/meldung/Aurora-Version-gibt-Ausblick-auf-Firefox-23-1866020.html). Spontan fällt mit keine Stelle ein, bei der das noch so verwendet wird. Vielleicht gibt es aber noch irgendwo noch Stellen. Bitte die nächsten Wochen darauf achten und hier melden. --Fomafix (Diskussion) 19:57, 19. Mai 2013 (CEST)

Bei dewiki habe ich bisher nichts gefunden. Bei dewikisource gibt es beispielsweise Probleme in s:MediaWiki:Gadget-PR-robot.js. --Fomafix (Diskussion) 10:28, 20. Mai 2013 (CEST)
Es betrifft mindestens mein Skript Benutzer:Schnark/js/personendaten.js/normdaten.js, wobei das schon immer dokumentiert und mit Konfigurationsvariable ausgestattet war. Da der Internet Explorer (wenn ich mich recht erinnere) schon sehr lange HTTP-Inhalte auf HTTPS-Seiten blockiert, ist das kein neues Problem, abgesehen davon, dass es mehr Benutzer betrifft. --Schnark 10:15, 23. Mai 2013 (CEST)
Richtig, in der Standardkonfiguration zeigte der IE schon immer ein PopUp mit der Bitte um Bestätigung, ob man das Laden der HTTP-Inhalte zulassen möchte. Ich finde es interessiert, das es auf einmal interesse dran gibt, nur weil der FireFox das auch machen möchte.
Gleiche Sache: Der Internet Explorer in der Standardkonfiguration hat schon immer keine Cookies von Drittanbietern zugelassen, daher funktionierte die SUL-Anmeldung nur auf *.wikipedia.org, nicht auf Commons oder anderen Schwesterprojekten. Jetzt kündigt FireFox das gleiche an und schon wird an einer Lösung für das Problem gearbeitet (es wurde beispielsweise schon login.wikimedia.org eingerichtet). Ob es dann auch für IE funktioniert, ist abzuwarten. Der Umherirrende 17:52, 23. Mai 2013 (CEST)
Die Flickr-Bilder-holen-Funktion von UpWiz verwendet HTTP immer, obwohl Flickr auch eine secure-API anbietet. Ich werde nie verstehen, weshalb die bezahlten «professionals» es einfach nicht hinbekommen. Stattdessen grinsen sie einen von Spendenbannern an. Immerhin das können sie gut. Mein Skript macht es dagegen richtig und vor allen Dingen hat es eine eigene Prozedur für Flickr-API-Anfragen und klaubt sie nicht jedes Mal zusammen. Vielleicht mag ja mal jemand der sein Handwerk versteht, das mal verbessern. Sumanah verweigert mir den git-Zugang nur weil ich mit den Labs-Terms nicht einverstanden bin; da habe ich jetzt auch keine Lust mehr. -- RE rillke fragen? 21:39, 26. Mai 2013 (CEST)
@Rillke:, ich habe commits von einem Account mit deinem Namen gesehen, daher wollte ich fragen: Hast du dich dieser Sache angenommen oder möchtest du noch? Der Umherirrende 17:51, 27. Jun. 2014 (CEST)
Dürfte inzwischen gefixt sein. -- RE rillke fragen? 18:08, 27. Jun. 2014 (CEST)

Lokales Wiki und etwas PHP-RegExp-Spielerei benötigt[Bearbeiten]

Hi all,

es geht um Folgendes: In Lua gibt es mehrzeilige Kommentare, die durch zwei eckige Klammern mit dazwischen stehenden Gleichheitszeichen umschlossen werden, wobei die Anzahl vorne und hinten gleich sein muss; ab Null. Außerdem beginnt der Kommentar mit zwei Bindestrichen.

Das geht aber schief und klappt nur bei Null Gleichheitszeichen zwischen den eckigen Klammern. Wenn im Text eckige Klammern stehen, werden aber ein, zwei oder mehr Gleichheitszeichen zum Escapen benötigt.

So soll es aussehen:

--[[ Dieses Beispiel
Dieser Zweck
* service
]]
local x

Macht aber nur die erste Zeile:

--[=[ Dieses Beispiel
Dieser Zweck
* service
]=]
local x

Ganz fies, kriegt sich gar nicht mehr ein:

--[==[
   category - is useful for automatic categorisation of list items
   cat - is text, which has to be put before the text from the list item and after [[Kategorie:
   key - is  the sortkey for the category
]==]
function p.category ( frame )
    text = frame.args[2]
    delimiter = "]]"

Die Definition steht auf geshi/geshi/lua.php.

    'COMMENT_SINGLE' => array(1 => "--"),
    'COMMENT_MULTI' => array('--[[' => ']]'),
    'COMMENT_REGEXP' => array(2 => '/\[(=*)\[.*?\]\1\]/s'),

The index ‘MULTI’ is used for multiline comments (and cannot be an array).

Grundsätzlich ist der COMMENT_REGEXP in Ordnung; das /s lässt beim . auch \n zu. Meine Ideen:

  • COMMENT_MULTI auskommentieren; vielleicht beißt es sich mit COMMENT_REGEXP. COMMENT_MULTI ist zu (=*) redundant.
  • Bindestriche vor /\[ setzen??

Ansonsten ratlos.

Wer kriegt’s hin? Liebe Grüße --PerfektesChaos 23:26, 20. Mai 2013 (CEST)

Habe weder gerade eine lokale MW-Installation mit geshi noch habe ich mit Lua oder geshi weiter beschäftigt, die Lösung sieht für mich aber bei dieser Darstellung offensichtlich aus:
  • Bindestriche zur regexp hinzu, sodass sie gültige Kommentarblöcke erkennt und dazu COMMENT_MULTI entfernen, weil redundant zur regexp.
  • ODER: COMMENT_REGEXP streichen und COMMENT_MULTI erweitern um die häufigsten Fälle. In etwa so:
'COMMENT_MULTI' => array('--[[' => ']]', '--[=[' => ']=]', '--[==[' => ']==]', '--[===[' => ']===]'),
(oder ist genau das mit The index ‘MULTI’ is used for multiline comments (and cannot be an array) gemeint?)--se4598 / ? 23:53, 20. Mai 2013 (CEST)
Habe bei GeSHi einen Bug geöffnet und einen Patch angehängt: GeSHi Bug 225. Der Patch wurde schon applied, bis er aber seinen Weg in die Wikipedia findet kann dauern - Hoo man (Diskussion) 00:59, 21. Mai 2013 (CEST)
Wenn das gesichert funktioniert, kann man ja ein Gerrit-Patch als Hotfix lancieren, bis es auf dem großen Dienstweg von GeSHi kommt.
Ansonsten fein gemacht, LG --PerfektesChaos 22:38, 21. Mai 2013 (CEST)

Anpassung in der erweiterten Bearbeiten-Werkzeugleiste[Bearbeiten]

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

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

PDF runterladen funktioniert nicht[Bearbeiten]

Hallo, bei dem Artikel "Schulausgangsschrift" funktioniert das Erstellen der PDF nur bis zu der Phase "Dokument herunter laden" bzw. eine Seite danach, wo sich die leere Maske zwar füllt, aber danach tut sich nichts. Ich benutze Firefox.

Ich bitte um Behebung dieses Fehlers. Danke--Tost, Renate (Diskussion) 09:45, 30. Jun. 2013 (CEST)

Hallo, Renate. Ich konnte eben die PDF-Datei herunterladen. Dabei hatte ich auch auf "Dokument herunterladen" geklickt. Aber das im Firefox integrierte PDF.js kommt irgendwie nicht damit zurecht. Also habe ich dann nach dem Zurückgehen auf die Erstellungsseite dort mit rechts auf den Link "Dokument herunterladen" geklickt und dann im Kontextmenü "Ziel speichern unter" ausgewählt. Das hat problemlos geklappt. Gruß --Tlustulimu (Diskussion) 10:04, 30. Jun. 2013 (CEST)
+1
Ich bestätige, dass ich den download korrekt ebenfalls problemlos mit Firefox ausführen und das PDF-Dokument lesen konnte.
Ich habe die PDF-Datei ebenfalls zuerst auf meiner Festplatte gespeichert, was bei mir jedoch persönliche Vorgabe ist.
Ich teile die Vermutung von Tlustulimu, dass es damit zusammenhängt, wie PDF im Browser integriert ist. Sollte etwas beteiligt sein, was wir auf dem Wiki-Server besser machen können, werden wir uns darum kümmern.
Schönen Sonntag --PerfektesChaos 10:10, 30. Jun. 2013 (CEST)
Ich habe die Antworten unseres Servers untersucht; er funktioniert ordnungsgemäß.
  • Außerdem habe ich andere Browser und andere Firefox-Einstellungen getestet; ohne Beanstandungen.
  • Es dürfte an der individuellen Firefox-Konfiguration gelegen haben; zu finden:
    • [Extras] → [Einstellungen] → Anwendungen → Portable Document Format
    • Dort mal etwas probieren; vielleicht die „interne Vorschau“ wählen oder statt dessen ein anderes Anzeigeprogramm auswählen.
Es ist aber völlig in Ordnung, hier nachzufragen und uns auf mögliche Fehler aufmerksam zu machen.
Schönen Sonntag noch --PerfektesChaos 14:54, 30. Jun. 2013 (CEST)
Hallo Tlustulimu, hallo PerfektesChaos, bin sehr beeindruckt von eurer Schnelligkeit. Hatte nicht gedacht, dass ihr euch heute schon drum kümmern könnt. Erst mal ganz herzlichen Dank für die intensiven Bemühungen und auch den letzten Satz, was die Nachfrage anlangt. Mein Problem ist, dass ich in den nächsten Wochen eine höhere Frequenz von Aufrufen dieses Artikels(im Zusammenhang mit Interesse am Runterladen) erwarte von Leuten, die sich nicht mit Sonderlösungen auskennen. Ich weiß mit Gewissheit, dass es anderen Benutzer(2)genauso gegangen ist wie mir, also auch schon ausprobiert haben und nicht zum Ziel kamen. Solltet ihr noch eine Lösung finden, wäre das super. Ansonsten bin ich auch bereit, mich damit abzufinden. Nochmals Dank und viele Grüße Renate--Tost, Renate (Diskussion) 19:57, 30. Jun. 2013 (CEST)

Also ich habs auch gerad mal versucht, das runterzuladen bzw. mit dem bei dem Firefox 22 eingebauten PDF-Viewer anzuschauen. Dabei hat sich wie beschrieben nur der Ladebalken im Viewer gefüllt, in der Fehlerkonsole habe ich folgendes gefunden:

Fehler: Error: Dictionary key must be a name object
Quelldatei: resource://pdf.js/build/pdf.js
Zeile: 661

Liegt also anscheinend wirklich an dem eingebauten PDF-Viewer (Standardaktion) von Firefox. Daher mein Rat: Die Datei speichern bzw. mit einem anderen Programm anschauen (wie z.B. oben von PerfektesChaos beschrieben). Grüße --se4598 / ? 20:59, 30. Jun. 2013 (CEST)


Ist ja witzig. Jetzt kann ich es auch reproduzieren.
  • Aber nur mit dem Artikel Schulausgangsschrift, wie vorbildlich eingangs des Thread benannt.
  • Ich hatte zum schnelleren Durchtesten eine winzige Seite ohne Bilder (BKS) benutzt. Dabei funktionierte auch die eingebaute Firefox-Vorschau. Es stellt sich die Frage, ob ein bestimmter Bildtyp oder Probleme mit der Länge (2MB sind nicht wirklich viel) das Problem auslöst.
  • Das PDF-Dokument ist valide.
  • Andere Browser zeigen es auch diret im Browser an.
  • Es handelt sich tatsächlich um eine Unverträglichkeit zwischen Firefox, seiner eingebauten Vorschau und einer Eigenschaft dieses PDF-Dokuments. Wobei das PDF in Ordnung ist und offenbar die FF-Vorschau einen Bug hat, wenn man das mal so oberflächlich backtraced von getObj.Parser_getObj(). Vielleicht trifft FF.js Annahmen über das PD-Format, die nicht erfüllt sein müssen, und irgendein Font in irgendeiner SVG passt nicht ins Weltbild.
Irgendein Forum oder developer.mozilla.org/bugzilla?
Schönen Abend --PerfektesChaos 21:28, 30. Jun. 2013 (CEST)
Länge war meine erste Vermutung, aber Deutschland (44 MB) funktioniert. --Steef 389 21:57, 30. Jun. 2013 (CEST)
Kurios.
Ich habe den Artikel gerade syntaktisch geflöht und aufpolieren lassen; es ist aber auch kein SVG drin, das irgendwelche Objekte transportieren könnte, und auch kein TIFF.
Geht diese PDF-Funktion eigentlich auch von Benutzer-Unterseiten aus, bloß ohne den hilfreichen Link im Portal, oder ist die auf den ANR beschränkt? Wenn es im BNR ginge, sollte man ihn fleddern: Ganz ohne Bilder, mit der Hälfte aller Bilder, mit einem Viertel oder dreiviertel. Ich kann mir eigentlich nur vorstellen, dass in einem dieser JPEG noch etwas steckt, was durchgereicht wird. So schwarzweße Grafiken würden sich ohnehin als PNG anbieten.
Liebe Grüße --PerfektesChaos 23:21, 30. Jun. 2013 (CEST)
Hallo, alle Helfer miteinander. Falls eine Aktion von mir in dieser Angelegenheit erwartet wird, lasst es mich bitte wissen. Wenn möglich, in einfacher Sprache. Bin technischer Laie. Ich muss schon sagen, dass ich fast gerührt bin ob dieses Engagements bei dem Versuch, die Sache zu retten. Herzlichen Dank und eine schöne neue Woche. Renate--Tost, Renate (Diskussion) 06:36, 1. Jul. 2013 (CEST)
Sorry für das Techsprech in meinem Beitrag drüber; er war an die mitlesenden Werkstatt-Mitarbeiter gerichtet. Nein, von Seiten der Autorin gibt es nichts zu tun; es ist ein ordnungsgemäßer Artikel. Mehr lässt sich nicht machen.
Mutmaßlich hat eines der Bilder eine Besonderheit, die sich nicht mit dem eingebauten PDF-Betrachter des Firefox verträgt. Wobei der eigentliche Fehler wohl beim Firefox liegt. Um das aufzuklären und auch den Kollegen vom Firefox einen konkreten Hinweis geben zu können, wären die genaueren Umstände interessant.
Übrigens wird diese Seite hier heute Abend einen Teil ihres Namens verlieren; das hat nichts zu bedeuten, es geht völlig ungestört weiter.
Beste Grüße --PerfektesChaos 11:21, 1. Jul. 2013 (CEST)
Hallo, bitte versteht, dass ich sehr beunruhigt bin, wenn sich für die nächsten Tage auf der Seite etwas ändert. Das möchte ich im Moment gerade nicht, da wäre mir die Unsicherheit beim Herunterladen das kleinere Übel. Bitte lasst dann doch erst mal alles an seinem Platz und ihr verschiebt eure freundlichen Reparaturen auf einen späteren Zeitraum. Ich habe diesen meinen Artikel nämlich als Literatur in der Veröffentlichung einer Fachzeitschrift angegeben, die jetzt im Juli erscheint. Wenn das nicht klappt, steht mit mir auch gleich Wikipedia nicht gut da. Macht erst mal Pause. Vielen Dank für euer Engagement und Verständnis.--Tost, Renate (Diskussion) 11:53, 1. Jul. 2013 (CEST)
Es klingt nach dieser Bug (bzw. Upstream). Im Bug steht leider nicht, in welcher Version der Fehler behoben sein soll, wenn er im Mai im Nightly Build behoben war, müsste es aber mit FF 23 funktionieren. --Schnark 12:00, 1. Jul. 2013 (CEST)
Einschub: Im Firefox 23 ist der Bug noch nicht behoben, frühestens also in der 24 (12 Wochen?). --Steef 389 17:46, 1. Jul. 2013 (CEST)

@ Renate Tost: Keine Sorge; wir werden dem richtigen Artikel nichts antun.

  • Wenn wir Experimente machen, dann fernab der Weltöffentlichkeit, und wenn wir noch eine Lösung finden sollten, dann wird sie den Artikel verbessern. Wir sind hier keine Vandalen.
  • Der wesentliche Fehler lag im Firefox und wurde dort bereits im Mai behoben. In der nächsten Firefox-Version wird er bei allen Benutzern ankommen.
  • Möglicherweise finden wir in den nächsten Tagen einen sicheren Weg, der den Konflikt mit dem momentanen Firefox vermeidet.

@ Werkstatt:

  • Wir sollten gleichwohl ermitteln, warum wir PDF generieren, das nicht über jeden Zweifel erhaben ist.
  • Dazu sollten wir das aktuelle Problem mit dem FF22 zügig nutzen, um eine konkrete Ursache zu identifizieren.
  • Meine Nase sagt mir: JPEG-Unterformat.
  • Ich bitte soeben Perhelion, JPEG durch geeignetes PNG zu ersetzen. Mal sehn, was FF dann macht. Wer schneller sein möchte als Perhelion, möge ihm Doppelarbeit ersparen.
  • β-dewiki kann keine Bilder; ANR des testwiki: böte direkte Links zum systematischen Durchprobieren von Artikel-Varianten.

Liebe Grüße --PerfektesChaos 14:44, 1. Jul. 2013 (CEST)

@Perfektes Chaos: Falls Renate Trost diese Seite gebookmarked hat, solltest Du ihr noch den ab morgen gültigen Link auf diese Diskussion mitteilen (oder wird es eine Weiterleitung geben?). --Mabschaaf 14:54, 1. Jul. 2013 (CEST)
Wo werd ich. Natürlich gibt es WL auf alles, was sich zu beobachten lohnt; schon um des Erhalts aller für die Nachwelt spannenden ¹VG willen. ²VG --PerfektesChaos 17:22, 1. Jul. 2013 (CEST)


Neue Lage:

  • Perhelion hatte alle JPG in PNG konvertiert; Danke schön.
  • Ergebnis:
    • Vor der Sichtung (wegen geänderter Datei-Einbindung) erhielt ich in der FF-Vorschau eine Nur-Text-Version; planmäßig und insofern ordnungsgemäß.
    • Nach der Sichtung die bekannte Fehlermeldung Dictionary key must be a name object. Nix weiter.
    • Herunterladen auf Festplatte problemlos; Dokument in Ordnung.
    • Größe statt gestern 2,3 MB heute nur noch 1,55 MB. Etwas haben die PNG also schon gebracht.
  • Schlussfolgerungen:
    • An den JPEG liegt es nicht; auch kein neumodisches JPEG-Unterformat, das ein altertümlicher PDF-Generierer nicht richtig verstanden hätte.
    • Es liegt aber definitiv an den Grafiken.
    • In Frage käme Bildgröße, Skalierungsverhältnis, thumbnail-Generierung.
    • Auffallend: Im Abschnitt Schulausgangsschrift#Großbuchstaben stehen zwei Bilder (1958 und 1968) links und rechts nebeneinander. Bei der Auflösung für den Druck passen sie nicht auf den Satzspiegel; vielmehr wird das linke (1958) aus dem linken Rand herausgeschoben. Im HTML werden sie übereinander angeordnet.
  • Meine nächste Aktion:
    • Pixelgröße dieser beiden etwas absenken. Mal sehn, was dann passiert.

Viele Grüße --PerfektesChaos 17:22, 1. Jul. 2013 (CEST)

Ich kann bestätigen: Mit dem Internet Explorer und mit Google Chrome geht es tadellos; mit Firefox nicht. Aber Fierefox erzeugt das pdf auch tadellos, nur muss man es (rechts oben) "als Datei abspeichern" und dann kann man das pdf auch öffnen. Viel Erfolg wünscht die Brücke (Diskussion) 17:45, 1. Jul. 2013 (CEST)
Die Bilder allein funktionieren schon nicht, siehe Benutzer:Steef389/Book. Zum Testen welches genau Schuld ist kann gerne experimentiert werden. Firefox 24 löst allerdings das Problem. --Steef 389 18:22, 1. Jul. 2013 (CEST)


Es funktioniert jetzt. Nun mag mir jemand erklären, warum.

  • Was habe ich getan?
    • Die beiden Bilder 1958 und 1968 in Schulausgangsschrift#Großbuchstaben habe ich voneinander getrennt; eines standard-mini rechtsbündig zum Thema „1958“ passend und eines standard-mini rechtsbündig zum Thema „1968“ passend.
    • Außerdem bin ich wegen thumbnail-Größentest und um des Layouts willen von 400px auf 300px gegangen; das hat aber mit ziemlicher Sicherheit keine Auswirkung.
  • Wie war es ursprünglich?
    • Beide Grafiken sollten linksbündig unmittelbar nacheinander stehen. Sie wurden von DIV.clear:both gefolgt.
    • Das PDF, auch wenn es scheinbar problemlos auf die Festplatte geladen wurde oder in anderen Browsern direkt angezeigt wurde, hatte diese beiden nicht linksbündig übereinander, sondern nebeneinander und obendrein aus dem linken Rand heraus geschoben gezeigt.
  • Was hatte nicht gefruchtet?
    • Zwangs-Anordnung in einer Tabelle oder durch DIV.clear:both oder rechtsbündig aufeinander folgend hatte keine Wirkung auf das fehlerhafte Layout im PDF.
    • Teilweise verschwand dadurch das Bild 1958 im PDF.
    • JPEG hat offenbar nichts damit zu tun.
  • Was heißt das?
    • Unser PDF-Generator hat eine Macke.
    • Welche?
      • DIV.clear:both nach zwei Bildern??
    • Wer schreibt den Bugzilla?
    • FF24 mag zwar das beschädigte PDF direkt im Browser anzeigen; aber es ist trotzdem strukturell nicht in Ordnung, und das Layout stimmt nicht mit der HTML-Seite überein. FF24 bricht nur wegen der Beschädigung nicht mehr die Vorschau ab.

Schönen Abend --PerfektesChaos 21:05, 1. Jul. 2013 (CEST)

Großen Dank für die Reparatur[Bearbeiten]

Hallo, ich muss schon sagen: Ihr, die Ihr so um das Ergebnis richtig gekämpft habt, seid echte Perlen!!! Davon wagt man eigentlich nur zu träumen. Ganz herzlichen Dank. Einen wohlverdienten schönen Abend noch. Renate --Tost, Renate (Diskussion) 22:07, 1. Jul. 2013 (CEST)

Bitte sehr, gern geschehen --PerfektesChaos 01:32, 2. Jul. 2013 (CEST)

Position des Signatur-Buttons verändern[Bearbeiten]

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

  • Das ist eine super-super-Idee!
    • Sie kommt leider um etliche Jahre zu spät. Es ist schon absehbar, wann unser klassisches Disku-Seiten-Signieren beendet sein wird.
  • Verschieben von irgendwoher (es gibt mehrere solcher Bearbeitenleisten) ist nicht möglich; der bleibt schon da, wo er ist.
  • Ein Button in gleicher Art wie der Speichern kann aber sehr leicht neu generiert werden.
  • Dass es eine Seite ist, die entweder in einem Disku-Namensraum liegt oder aber (grübel) die Eigenschaft „Abschnitt hinzufügen“ hätte, ließe sich herausfinden. (Hm. PageProps newsectionlink per API? Bestimmte Namen wie „Werkstatt“, „Anfrage“, „Lösch“, „Umfrage“, „Meinungs“ wären fad. Das Magicword kann in einer /Intro stehen. Es kann ein neuer und leerer Abschnitt sein. – Jedenfalls nur WPNR.)
  • Ein Kollege oder ich kann aber relativ bald ein Gadget schreiben, das sowas umsetzt.
Liebe Grüße --PerfektesChaos 00:33, 12. Jul. 2013 (CEST)
PS: Hat jemand eine Glaskugel und weiß, wann dewiki in Flow und Echo abhebt? Einen konkreten deployment plan für den Ersatz der Signaturen durch automatische Threads sehe ich grad nicht.
  • enWP und dewiki listet noch kein derartiges Skript.
  • Es ist möglich, auf Disku und im WPNR immer den Button gleichzeitig mit Seitenaufbau anzulegen.
    • Im WPNR wird er jedoch initial disabled und erst per API scharf geschaltet.
    • Würde man mit der Button-Anlage auf das API-Ergebnis warten, gäbe es da links einen heftigen Ruckler. Der kann sowieso beim Seitenaufbau kommen; aber da bewegt sich ja noch so manches.
    • Optional kann man ihm gelben Hintergrund geben, solange noch keine Tilden im Bearbeitungsfeld stehen, und das beim Verlassen des TEXTAREA aktualisieren.
  • WikEd und Ace können auch aktiv sein.
  • Optional das Einfügen mit zwei Bindestrichen, oder nur vier Tilden.
  • Optional kann man bei Klick auf Speichern das TEXTAREA flöhen, ob Tilden bereits drin sind; und beim Fehlen einmalig warnen. Im Einzelfall (Archivierung, Typo, Linkfix rückwirkend, PS, BK) kann eine Bearbeitung ohne Tilden sinnvoll sein.
Baldiges Wochenende --PerfektesChaos 10:17, 12. Jul. 2013 (CEST)
Flow ist gerade am Anfang seiner Entwicklung (eventuell Ende 2013), Notifications (Echo) könnte diese Quartal kommen. Ansonsten schau mal auf mw:Editor Engagement/2013 strategy planning (Features) und mw:Roadmap bzw. dessen aktuellere Google-Exceltabelle (auf der Seite oben verlinkt)--se4598 / ? 10:40, 12. Jul. 2013 (CEST)
Ah, danke.
  • Flow: „am Anfang seiner Entwicklung“ + „eventuell Ende 2013“ = Frühjahr oder Mitte 2014; könnte sich noch lohnen.
  • Echo schätze ich so ein, dass es mit den in Rede stehenden Tilden nichts zu tun hat.
LG --PerfektesChaos 10:46, 12. Jul. 2013 (CEST)

Edit-Notice[Bearbeiten]

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

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

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

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

Eventhandler werden plötzlich doppelt ausgeführt[Bearbeiten]

Ich könnte heulen. Mal wieder. Warum muss alles, was die Foundation tut, Bestehendes kaputt machen? Mein autoFormatter spinnt für einige Benutzer total, seit diese nervenden, sinnfrei redundanten „Spracheinstellung“ und die darin enthaltenen disfunktionalen „Eingabewerkzeuge“ für alle Benutzer zwangsaktiviert wurden. Das Folgende betrifft mein forceEditSummary, aber ich schiebe es auf die selbe Ursache, da es zur selben Zeit kaputt ging. Ich habe es auf das folgende Beispiel herunter gebrochen. Kopiert das in eure common.js, klickt irgendwo auf Bearbeiten und sofort auf Speichern.

$(document).ready(function()
{
	var i = 0;
	$('#wpSave').click(function()
	{
		alert('Save button click #' + ++i);
		return i > 1;
	});
});

Der onclick-Handler für den Speichern-Button wird doppelt ausgeführt. Was zum Teufel …? --TMg 17:57, 24. Jul. 2013 (CEST)

Und heute ist es nicht mehr nachvollziehbar. Einen Bugreport dazu finde ich aber auch nicht. Erledigt? Ich glaube nicht so recht daran und lasse es mal noch offen. --TMg 23:50, 31. Jul. 2013 (CEST)
Jaaa, da hat irgendein Tool auch einen Observer an den Button gebunden, den Klick mit .preventDefault() aufgehalten und dann selbst nochmal geklickt. Am besten Du machst Folgendes:
$(document).ready(function()
{
	var i = 0, myObserver, $saveButton;
 
	$saveButton = $('#wpSave');
	myObserver = function()
	{
		$saveButton.off('click', myObserver);
		// Und nun weiter in der Geschichte…
	};
	$('#wpSave').click(myObserver);
});
und nun $('#wpSave').click(); -- RE rillke fragen? 15:43, 4. Aug. 2013 (CEST)
Danke, aber es ist gerade der Sinn meines Skripts, mit aufeinander folgenden Klicks zu arbeiten. Mein Problem ist ganz grundsätzlich, dass der Sinn jedes Eventhandlings komplett verloren geht, wenn irgendwelche Skripte anfangen, Events zu simulieren, die gar nicht vom Anwender kamen. Wie soll man das unterscheiden? --TMg 15:56, 4. Aug. 2013 (CEST)
http://stackoverflow.com/questions/6692031/check-if-event-is-triggered-by-a-human // http://stackoverflow.com/questions/10704168/in-javascript-what-is-event-istrigger -- RE rillke fragen? 17:35, 7. Aug. 2013 (CEST)

Neue Dateiversion angeblich ungesichtet[Bearbeiten]

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

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

Darstellungsfehler "Liste neben Tabelle"[Bearbeiten]

siehe hießiger Artikel

links eine Tabelle, rechts eine Liste:

Ölmengen
benötigte Ölmenge bei einfachem Ölwechsel 3,4 Liter
bei Ölwechsel inkl. Ölfilter-Tausch 3,6 Liter
bei kompletter Zerlegung des Motors 4,1 Liter
Spezifikation Motoröl: SAE 10W40 API SE-SG
Standgeräusch dB (A): 91
Fahrgeräusch dB (A): 79

nächste Überschrift[Bearbeiten]

irgendein text, blabla, jetzt die Liste:

  • punkt 1
  • punkt 2
  • punkt 3
  • punkt 4
  • punkt 5
  • punkt 6
  • punkt 7

...und die Listen-"Punkte" dringen links in die Liste ein!

(IE Version 9.0.8112.16421, 64-bit Edition, Updateversion 9.0.19)

Ist evtl. die Liste falsch verwendet?

--arilou (Diskussion) 10:08, 20. Aug. 2013 (CEST)

Das ist ein bekanntes Problem, für das es keine universelle Lösung gibt. --Fomafix (Diskussion) 10:35, 20. Aug. 2013 (CEST)


  • Linkservice: BD:Entlinkt #prettytable
  • wikitable bringt im Moment im o.a. Beispiel zwar nichts, sollte aber perspektivisch in allen einschlägigen Artikeln das veraltete prettytable ersetzen. Es würde schneller besser funktionieren als prettytable.
  • Es ist ein grundsätzliches Problem, Aufzählungen rechts von Bildern oder Tabellen einzusetzen. Die Aufzählungspunkte sollen ja untereinander stehen. Es kann bei schmalen Fensterbreiten und nicht mehr so hohen Bildern oder Tabellen immer mal dazu kommen, dass die letzten Aufzählungspunkte unter dem Objekt durchflutschen und nun ganz links außen stehen. Bei Fließtext ist das egal. Wenn ich hier aber das Fenster schmal ziehe, rutschen KTM 990 Adventure und vielleicht auch Ducati Multistrada aus der Flucht heraus.
  • Abhilfe hier: Layout ändern; generell Elemente links vermeiden. Dreispaltig ist immer ungeschickt; man denke an Smartphones usw.
Liebe Grüße --PerfektesChaos 11:00, 20. Aug. 2013 (CEST)
+ Linkservice: Wikipedia:Verbesserungsvorschläge #Aufzählungszeichen und Bild auf der linken Seite
VG --PerfektesChaos 22:35, 20. Aug. 2013 (CEST)

Verwendung bestimmter HTML-Elemente und Klassennamen analysieren[Bearbeiten]

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

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

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

Ich habe aus dem aktuellen Dump eine Liste der betroffenen Seiten erstellt, du findest sie unter Benutzer:Entlinkt/cite. Nicht erschrecken, das meiste sind Seiten im WNR, hauptsächlich Unterschriften von Benutzer:Herr Th. und einigen anderen, die sogar semantisch korrekt sind. Es kann allerdings noch mehr geben, etwa wenn irgendwo {{FNZ|a|text|cite}} verwendet wird (frag mich nicht wieso, aber bei handgemachten Fußnoten wird <cite> anscheinend gerne missbraucht). Unter der Liste in einem Kommentar habe ich die ursprüngliche Ausgabe meines Skripts angehängt, damit du dir einen Überblick verschaffen kannst, ohne die Artikel einzeln aufrufen zu müssen. --Schnark 09:09, 13. Sep. 2013 (CEST)
Cool, vielen Dank! Ich werde mal schauen, ob das mit vertretbarem Aufwand zu bereinigen ist. Gruß --Entlinkt (Diskussion) 09:39, 13. Sep. 2013 (CEST)
Okay, die Bereinigung scheint geklappt zu haben (bis auf irgendwelche unerkannten Probleme, die bestimmt noch gefunden werden). Jetzt würde mich dasselbe für die folgenden Klassennamen interessieren (teils sind sie veraltet, teils soll die Verwendung geändert werden):
  • hintergrundfarbe10 (außer in Jahresartikeln; zur Analyse; war nie definiert und soll ggf. neu definiert werden)
  • imagemap-inline (kaputt, soll aus common.css entfernt werden)
  • metadata (zur Analyse; Definition in common.css soll evtl. geändert werden)
  • metadata-label (zur Analyse; soll ggf. nach MediaWiki:Gadget-Personendaten.css verschoben werden)
  • NavEnd (kaputt, soll aus common.css entfernt werden)
  • nogrid (kaputt, wurde bereits aus common.css entfernt, betroffene Seiten sollten aufgespürt werden)
  • palaeobox (zur Analyse, soll evtl. mit Klasse taxobox zusammengeführt werden)
Gruß --Entlinkt (Diskussion) 15:58, 13. Sep. 2013 (CEST)
Ja, ja, der kleine Finger und die ganze Hand. ;-) Ich schau mal, ob ich die Listen übers Wochenende erstellen kann. --Schnark 10:22, 14. Sep. 2013 (CEST)
Die Liste steht unter Benutzer:Entlinkt/CSS-Klassen zur Verfügung. --Schnark 09:17, 16. Sep. 2013 (CEST)
Wieder danke! Die Regeln für metadata und palaeobox sind bereits aus der common.css entfernt, NavEnd wird ebenfalls noch eliminiert, die anderen sind etwas komplizierter. Gruß --Entlinkt (Diskussion) 01:17, 17. Sep. 2013 (CEST)

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

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

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

Ist das mit dem {{FNZ|a|text|cite}} komplett erledigt, also eine derartige Nutzung durch die Hintertür jetzt auszuschließen? Ansonsten kann man die Vorlage temporär mit einem Wartungslink versehen. ÅñŧóñŜûŝî (Ð) 20:59, 22. Sep. 2013 (CEST)
{{FNZ|a|text|cite}} erzeugt kein <cite>-, sondern ein <span>-Element (und das war auch nie anders; der 3. Parameter wurde mit diesem Edit eingeführt und seitdem nicht verändert). --Entlinkt (Diskussion) 21:41, 22. Sep. 2013 (CEST)
Aha. "hintergrundfarbe10" kommt gem. Suche in 600 Jahresartikeln vor, immer in der Kombination  ::::colspan="2" class="hintergrundfarbe10" bgcolor=#ececec
Welchen Sinn es machen soll, sowohl eine Klasse, als auch ein bgcolor anzugeben, ist sowieso fraglich. Das sind aber längst nicht alle Seiten. ÅñŧóñŜûŝî (Ð) 11:26, 24. Sep. 2013 (CEST)

"tools.wikimedia.de uses an invalid security certificate"[Bearbeiten]

Einige Links (zB auf Artikellisten mit Wartungsbausteinen) verweisen auf Seiten von wikimedia.de, die offenbar das Zertifikat von toolserver.org verwenden, das für wikimedia.de nicht gültig ist. Beim Ansteuern eines entsprechenden Links zeigt der Broweser eine für normale Benutzer sicher irritierende Warnung an ("This Connection is Untrusted" etc.) Kümmert sich jemand um das Problem? -- Wolfgang Rieger (Diskussion) 13:55, 30. Sep. 2013 (CEST)

Das ist nur eine alte Weiterleitung ohne SSL-Zertifikat. Fixen kann das nur der jeweilige Toolbetreiber, der angesprochen werden muss, damit er den Link ändert, siehe dazu auch diese Diskussion auf FZW. Tools.wikimedia.de soll nicht verwendet werden. --Wyndfang 16:11, 30. Sep. 2013 (CEST)
Und wenn es solche Links hier in der WP gibt, müssen diese alle geändert werden. --Wyndfang 16:13, 30. Sep. 2013 (CEST)
Hier sind einige zu ändernde mit https: und hier welche mit http:, die auch nicht mehr funktionieren, weil auch dort automatisch der http-Link in einen https-Link umgewandelt wird seid der https-Umstellung kürzlich. Das sind die Nachteile bei solchen Umstellungen. :-( Solange es http-Links waren, haben sie funktioniert. Man müsste die automatische Weiterleitung bei tools.wikimedia.de auf https: unterbinden, dann würden sie alle wieder funktionieren. --Wyndfang 16:22, 30. Sep. 2013 (CEST)
Oder eine Botanfrage: Alle Links mit https://tools.wikimedia.de und auch http://tools.wikimedia.de (wegen der automatischen Weiterleitung) müssten nach https://toolserver.org umgebogen werden, dann ist alles wieder in Ordnung. Es kann aber sein, dass einiges davon schon oder auch schon auf Labs liegt, dann sollte man Links direkt dorthin umbiegen, denn die Toolserverlinks werden auch in 1 Jahr alle nicht mehr funktionieren. Man müsste also nach den jeweiligen Tools sortieren, was direkt nach Labs und was auf den normalen Toolserverlink umgebogen werden sollte. --Wyndfang 16:29, 30. Sep. 2013 (CEST)


Sorry, Wyndfang, so halb und halb.
  1. Ursachen:
    • Es handelt sich um veraltende Werkzeuge auf dem Toolserver.
    • In diesen Werkzeugen sind URL auf Ressourcen angegeben, etwa CSS und Grafiken.
      • Diese URL enthalten ein explizites http:// – damals konnte sich niemand Werkzeugbenutzung unter https vorstellen.
    • Die Verwendung unsicherer URL in einer verschlüsselten Verbindung ist unzulässig.
    • An den Zertifikaten für den Toolserver wird niemand mehr herumdoktern, schon gar nicht für die Vorgänger-Domain tools.wikimedia.de und dergleichen.
  2. Toolbetreiber:
    • Die Werkzeuge auf dem Toolserver sind Auslaufmodell.
    • Die Betreiber sind oft dort nicht mehr aktiv.
    • Es ist nicht damit zu rechnen, dass dort noch jemand großflächig herumprogrammieren wird.
    • Alle Anstrengungen richten sich darauf, auf Labs/Tools zu migrieren.
    • Für Labs/Tools sind die alten Programmierungen hoffentlich aufgearbeitet worden, und die URL auf protokoll-relative gekürzt worden.
  3. Soforthilfe Benutzer:
    • Das „s“ aus der URL herauspopeln, dann Seite damit neu anzeigen.
  4. Soforthilfe Admins:
    • Die Systemnachrichten, die in die entsprechenden Spezial- und Funktionsseiten eingebunden sind, bis auf Weiteres anpassen:
      • Ersatz von [// und [[tools: und dergleichen (fullurl?) durch altmodische URL mit explizit angegebenem http://toolserver.org ersetzen.
      • Das zur vorübergehenden Überbrückung bei veraltet programmierten Tools, siehe oben.
    • Mittelfristig ist dann sowieso zu ersetzen durch Labs/Tools.
  5. Diskussionen, Benutzer- und archivierte Seiten:
    • Finger weg.
    • Es ist völlig normal, dass bei fünf Jahre alten Diskussionen irgendwelche Links nicht mehr funktionieren.
    • Selbst wenn die Links wieder arbeiten, zeigen sie heute möglicherweise ganz andere Ergebnisse, als das ein ganz anderes Werkzeug auf einer anderen Domain vor fünf Jahren mal ausgegeben hatte. Deshalb möglichst keine Manipulationen an historischen Seiten; die konkreten Einzelheiten will nach fünf Jahren sowieso niemand mehr wissen.
VG --PerfektesChaos 10:26, 1. Okt. 2013 (CEST)
Hallo Chaos! Vielen Dank für die ausführliche Antwort. Für mich ist das weniger ein Problem. Im Interesse normaler Benutzer sollte dergleichen aber nicht auftreten. Ich gehe jetzt mal davon aus, dass das Problem bekannt ist und jemand sich mittelfristig darum kümmert. Oder habe ich das falsch verstanden? Grüße -- Wolfgang Rieger (Diskussion) 16:18, 1. Okt. 2013 (CEST)
Ich glaube, hier werden zwei Probleme vermischt.
Einmal gibt es das Problem, das tools.wikimedia.de das Zertifikat für toolserver.org nutzt und die Weiterleitung erst nach der zertifizieren erfolgt. Keine Ahnung, ob man das umdrehen kann. Hier könnte es schon helfen, einige der Links auf den Hilfeseiten entsprechend zu ändern.
Zweitens haben einige Tools das Problem, das sie Styles oder Skripte über http einbinden, was bei https-Verbindung zu einem Pop-Up führen kann, oder das es garnicht geladen wird, dann sieht die Seite entsprechend unschön aus. Das zweite Problem können nur die jeweiligen Toolbetreiber lösen, oder es wird kein https-Link auf die Tools angeboten. Der Umherirrende 19:28, 2. Okt. 2013 (CEST)
Nö, ich verwechsel das schon nicht.
  • Wenn jetzt die alte Domain tools.wikimedia.de umgestellt wird auf toolserver.org dann bitte gleich auf http://toolserver.org und keine Experimente. Es lohnt sich nicht, danach noch lange an den Benutzern auszuprobieren, unter welchen Bedingungen dann doch noch eine http-Ressource angefasst wird, und nach nochmaligem Hin und Her und neuen Beschwerden schließlich auch von protokoll-relativ auf explizites http zu gehen.
  • Man muss im Herbst 2013 nicht in die dicke Paranoia ausbrechen, weil jemand unverschlüsselt eine CatScan-Abfrage macht. Die Toolserver-Benutzung braucht https nicht so unbedingt, Passwörter werden nicht übertragen, und geohack zumindest liegt ja schon auf Labs.
  • Bei den toolserver.org, von denen bekannt ist, dass https zu Problemen wegen innerer URL-Benutzung führt, muss von protokoll-relativ auf explizites http geändert werden.
  • Ansonsten lohnt es nicht, die große Philosophie anzuwerfen, weil im Lauf der nächsten Monaten sowieso auf Labs migriert wird.
So klarer? --PerfektesChaos 20:37, 2. Okt. 2013 (CEST)
Zur Information: Die TS-Admins haben ein passendes Zertifikat für tools.wikimedia.de installiert. Das sollte die Weiterleitungs-Probleme lösen. Für die Includierungs-Probleme (z.B. css über http in einem https-Tool) sind – wie Der Umherirrende richtig sagt – die Tools-Autoren zuständig. --DaB. (Diskussion) 15:18, 6. Okt. 2013 (CEST)
Silke schreibt hier, dass das Problem nun behoben sei. --Wyndfang 14:23, 7. Okt. 2013 (CEST)
Das heißt, dass die entsprechenden Links nun alle automatisch auf Adressen mit https://toolserver.org weiterleiten. Die alten Links funktionieren also alle wieder, bis der Toolserver nächstes Jahr ganz abgeschaltet wird. --Wyndfang 14:28, 7. Okt. 2013 (CEST)
Scheint aber ein spezielles Verfahren zu sein, was unter IE8 auf XP (noch) nicht funktioniert. Der Umherirrende 19:55, 7. Okt. 2013 (CEST)
Also, bei mir funktioniert es, aber ich verwende auch keinen IE. Vielleicht fragst du noch mal bei Silke nach, woran das liegt? Oder bei DaB.? --Wyndfang 23:04, 7. Okt. 2013 (CEST)

Das oben als Beispiel angegebene Link funktioniert jedenfalls (bei mir) jetzt ohne Mecker. Soweit dann mal Dank an alle Beteiligten. -- Wolfgang Rieger (Diskussion) 20:41, 7. Okt. 2013 (CEST)

class="metadata" und <ref>[Bearbeiten]

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

Das HTML-Attribut class="metadata" in den Zellen der rechten Spalte blendet die rechte Spalte aus, aber nichts, was im erzeugten HTML außerhalb dieser Zellen steht. Die mit <ref> erzeugten Fußnoten stehen zwar im Wikitext innerhalb der Tabelle, aber nicht im erzeugten HTML (dort stehen sie im unteren Abschnitt, wo man sie auch sieht).
Als Workaround könnte man <references group="bda"/> durch <div class="metadata"><references group="bda"/></div> ersetzen. Gruß --Entlinkt (Diskussion) 18:09, 21. Nov. 2013 (CET)
danke, soweit war ich eben auch schon. Du bist zwischen meine zwei Versuche hineingestolpert, eigentlich wollte ich dafür keine neue group="bda" einführen. lg --Herzi Pinki (Diskussion) 18:18, 21. Nov. 2013 (CET)
Okay, aber die Begründung, weshalb das ohne neue Gruppe nicht funktioniert, gilt trotzdem. Dieser Anwendungsfall ist in der Cite-Erweiterung anscheinend nicht vorgesehen. --Entlinkt (Diskussion) 13:37, 24. Nov. 2013 (CET)

Anzeigeprobleme bei Vorlage:Infobox Sternbild auf kleinen Bildschirmen[Bearbeiten]

Hallo, die Vorlage Vorlage:Infobox Sternbild verursacht in der Wikipedia-iPhone-App Darstellungsfehler. Details finden sich unter Vorlage Diskussion:Infobox Sternbild#Anzeigeprobleme auf kleinen Bildschirmen. Vielleicht kann sich dort ja jemand äußern. Danke! Grüße, — Pajz (Kontakt) 16:49, 3. Dez. 2013 (CET)

Probleme bei Login und (mehrfachem) Wiederherstellen-Exportieren-Löschen per API[Bearbeiten]

Hallo! Könnte jemand technikaffines mal einen Blick in die Diskussion unter Wikipedia:Administratoren/Anfragen#Admin_mit_Programmierkenntnissen_gesucht werfen? Irgendwie kommen wir da gerade nicht wirklich weiter. Mein Skript zu diesem Thema scheint zu funktionieren, nicht jedoch das Skript von Inkowik. Besten Dank schonmal im Voraus! --Asturius (Diskussion) 16:35, 16. Dez. 2013 (CET)

Bezugnehmend auf PerfektesChaos hier: Ja, ich benutz(t)e bisher action=tokens zur Generierung eines Edittokens, diese Variante hat bisher auch immer geklappt. Ich benutze PureBasic (PB) für die Requests, bzw. greife ich über PB auf WinAPI-Funktionen (u.a. InternetOpen und InternetConnect) zu, die das für mich tun. Demzufolgenach sollte eigentlich kein Browser im Spiel sein (oder doch der IE?). Gruß, IW 16:33, 22. Dez. 2013 (CET)


Mir ist aufgefallen, dass die beteiligten Session-Cookies "Secure" und weiterhin noch "HttpOnly" sind.
  • Das kann bedeuten, dass es noch einen weiteren Cookie-Wert gibt, den du mit deiner Zuweisung gar nicht erreichst.
  • Siehe HTTP-Cookie.
  • Allerdings bekommt ein Server eigentlich gar nicht mit, mit welchen Eigenschaften der Cookie bei dir liegt. Sie beeinflussen mehr den Zugriff und die Auswahl innerhalb des Browsers.
  • Trotzdem können sich bei gleichem Cookie-Namen mehrere gegenseitig überlagern: Session, Persistent/normal und "Secure"; und dann noch Pfade. Gesendet wird bei Namenskonflikt wohl der Session-Cookie, und der andere mit Ablaufdatum wird ignoriert.
    • Was genau vereinbarst du doch gleich?
  • Der Original-Cookie von MediaWiki dewikiSession hat für https die Eigenschaften: "Session" "Secure" "HttpOnly"
  • Versuche doch mal zu erlauschen, welche Cookies und Werte tatsächlich an den Server geschickt werden.
  • Ich habe keinen Durchblick, wohin die von dir erwähnte Cookie-Setzung wirkt.
Schöne Feiertage --PerfektesChaos 23:11, 23. Dez. 2013 (CET)
Danke erstmal für die Hinweise, ich schau mir es mal an. Gruß, IW 18:22, 25. Dez. 2013 (CET)

Flickr2Commons-Bookmarklet funktioniert nicht mehr mit WMF Labs[Bearbeiten]

Das Flickr2Commons-Bookmarklet funktioniert, seit das Tool auf WMF Labs läuft, nicht mehr. URI und Passwordfeldname müssen geändert werden und die Foto-ID in das entsprechende Feld übergeben werden. Es könnten auch sofort noch zwei weitere Versionen erstellt werden, die statt der Foto- die Set- bzw. User-ID übergeben. -- 217.186.202.194 15:02, 20. Jan. 2014 (CET)

Wäre es nicht sinnvoller, das Magnus zu sagen? Ich weiß nur leider nicht, wo der am ehesten mitliest. Vielleicht da? --TMg 00:39, 22. Jan. 2014 (CET)

Special:UnconnectedPages[Bearbeiten]

Hallo, gibt es eine Möglichkeit, diese Spezialseite per API abzufragen? Ich habe auf Anhieb erstmal nichts gefunden. Gruß, IW 21:06, 21. Jan. 2014 (CET)

Ich sehe da auch nichts, aber hilft dir, dass Special:PagesWithProp/wikibase_item das Gegenstück sein soll (welches ein API-Äquivalent hat)? --se4598 / ? 22:42, 21. Jan. 2014 (CET)
Danke für den Link, die Pageproperty hilft mir aber nicht, ich möchte auf Wikidata per Bot Datenobjekte für Artikel anlegen bzw. einfache Ergänzungen durchführen, dafür ist die Ausgabe von UnconnectedPages am passendsten. Gruß, IW 19:03, 22. Jan. 2014 (CET)

https auf .beta.wmflabs.org[Bearbeiten]

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

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

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

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

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

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

Eigene Diskussionsbeiträge zusammenholen[Bearbeiten]

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


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

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

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

Timeo Danaos et dona ferentes?[Bearbeiten]

Danaer verstecken sich gut! Oder http://de.wikipedia.org/w/index.php?search=Danaer&title=Spezial%3ASuche&fulltext=Volltext vs. http://de.wikipedia.org/wiki/Danaer

Ok, vermutlich bin ich hier falsch, konnte aber nichts passenderes finden. Viel kann ich nicht beitragen. Nur den Fakt, daß ich als Schlagwort „Danaer“ eingegeben habe und auf dieser Seite „Suchergebnisse“ gelandet bin. Das (und der Umstand, daß der da zuerst genannte Vorschlag der eigentliche Treffer wäre) irritiert doch sehr, macht den Eindruck, als ob hier ein Fehler in irgend einem Software-Teil steckt. Und nun? Tja, „macht doch was Ihr wollt“. — Oh, hoppla: http://de.wikipedia.org/w/index.php?search=was+ihr+wollt&title=Spezial%3ASuche&fulltext=Volltext Steckt etwa Loki (http://de.wikipedia.org/w/index.php?search=loki&title=Spezial%3ASuche&fulltext=Volltext) in der „Laß dich überraschen“-Box? Ist mir etwas entgangen? Wurde da an irgendwelchen Schrauben gedreht? So ein Verhalten erscheint mir jedenfalls ungewöhnlich. Derartige Treffer, noch dazu in solcher Häufung, sind mir bislang nicht untergekommen! (nicht signierter Beitrag von 93.205.110.71 (Diskussion) 21:11, 14. Feb. 2014 (CET))

Scrollbalken bewegt sich von alleine[Bearbeiten]

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

Für die Mitleser: basierend auch auf der anderen Rückmeldung auf Special:Permalink/127875769#Wo Störungen in der Wikipedia melden? führt das ganze meiner Meinung nach über Benutzer Diskussion:Fomafix#IE8-Scroll-Bug zu gerrit:109660 als wahrscheinlicher Auslöser (siehe dort auch die Kommentare) --se4598 / ? 22:45, 23. Feb. 2014 (CET)
Ich habe das eben mal auf Original-XP mit echtem IE8 probert und konnte mit den angegebenen Tastaturaktionen nicht reproduzieren.
Gleichwohl besteht die Notwendigkeit für diesen Fix ganz offenkundig weiter; die Entfernung bitte revertieren. Ich weiß nicht, welche äußeren Umstände mitspielen müssen, aber es kommt ja zu unabhängigen Beobachtungen.
IE8 ist auch etwas, das zwar prozentual abnimmt, aber absolut noch auf Jahre hinaus nicht abgeklemmt werden kann.
VG --PerfektesChaos 23:39, 23. Feb. 2014 (CET)
Ich habe eben mal drei andere Browser ausprobiert. Der Bug betrifft tatsächlich nur den MIE8. --Sassenburger (Diskussion) 01:40, 24. Feb. 2014 (CET)

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

Ich kann (leider) nicht mehr unterstützen, da ich kein Zugriff mehr auf einen IE8 habe. Der Umherirrende 19:54, 12. Mai 2014 (CEST)
Man muss doch zu dem Stand VOR dem Bug zurückgehen können (Versionsgeschichte)? Oder war aus technischen Gründen Quellcode erforderlich, der nun diesen Bug auslöst? --Sassenburger (Diskussion) 23:30, 12. Mai 2014 (CEST)
Ich bin hier nicht involviert, und ich habe auch keine Ahnung, was die Leute von der weltweiten Wiki-Programmierung dazu getrieben hat, diesen IE8-Fix herauszunehmen.
Aber du kannst ja mal zur Selbsthilfe greifen:
  1. Special:Mypage/common.css zum Bearbeiten öffnen.
  2. Die folgenden Zeilen hineinkopieren:
#wpTextbox1 {
  height: 390px;
  width: 500px;
  min-width: 100%;
  max-width: 100%;		
}
Speichern; schaun, was passiert.
Viel Erfolg --PerfektesChaos 23:59, 12. Mai 2014 (CEST)
Super!!!! Der Bug ist weg! Die Firma sagt danke! :-D --Sassenburger (Diskussion) 00:07, 13. Mai 2014 (CEST)
Nö, der Bug ist noch da; aber den hat jetzt ein anderer … --PerfektesChaos 00:14, 13. Mai 2014 (CEST)

Obsoletes auf MediaWiki:Gadget-*[Bearbeiten]

Allmählich schmeißt addOnloadHook deprecated-Warnungen. Mit Ende von MW1.23 soll das angeblich aus dem Verkehr gezogen werden.

Betroffen sind:

MediaWiki:Gadget-PrettyLog.js
addOnloadHook
mw.config.get
importScriptURI
MediaWiki:Gadget-contribsrange.js
addOnloadHook
Kapselung
mw.config.get
importScriptURI
MediaWiki:Gadget-revisionCounter.js
addOnloadHook
importScriptURI
Kapselung; auch für Ajax-Callback
Umschreiben auf jQuery vervollständigen; nicht nur halb
MediaWiki:Gadget-Rechtschreibpruefung.js
addOnloadHook
mw.loader.load
Kapselung
Anwendungsobjekt (mw.libs) statt global; auch für Konfigurationsvariable
Umschreiben auf jQuery
  • Globale DontAutorunRP (73) und RPonAllPages (9) migrieren
  • Dazu ggf. Seiteneinblendung, wenn Variable vorhanden, und zur Umstellung auffordern; nach zwölf Monaten wieder entfernen.
  • Irgendwie kommen mir die Benutzernamen fast alle inaktiv vor.
MediaWiki:Gadget-bkl-check.js
addOnloadHook
Schnark (offline) hat irgendwie schon eine Neuprogrammierung auf der Pfanne?

Wenn man das schon austestet, dann sollte man nicht nur zeilenweise Kosmetik machen, sondern es komplett auf den aktuellen Stand bringen und strict und jshint und pipapo.

  • Eine mögliche Internationalisierung und Flexibilisierung sollte beachtet werden.

Wer möchte was machen?

LG --PerfektesChaos 23:49, 23. Feb. 2014 (CET)

Du spielst wohl auf den Gerrit-Change an, wo #warn und #deprecated auch beim normalen Lesen in der console auftauchen (gerrit:111957). Ob es wirklich verschwindet, kann ich nicht sagen (dann aber wohl um Ende April herum, wenn 1.24 anfängt)
Im Bereich Helferlein ist in der de.wp einiges an Verbesserungspotenzial da. Da wäre ein Admin, der sich gut mit JavaScript auskennt, Zeit und Lust aufbringt und das häufiger macht, eine schöne Bereicherung ;-). Ich bin da nicht so aktiv, weil ich selber die Dinge aktuell nicht brauche und einem auch sofort die Eigentümerschaft von einzelnen Gadgets aufgedrückt wird ;-) Der Umherirrende 20:37, 27. Feb. 2014 (CET)
Oben kl.erg. Ich nutze diese Dinger auch nicht persönlich, und Software umzubasteln, die man selbst nicht in Funktion kennt und nicht selbst konzipiert hat, ist immer mühsam.; erst recht wenn es noch nicht mal eine Doku gibt. --PerfektesChaos 10:44, 9. Jun. 2014 (CEST)
Hm* mw.config.get ist deprecated?? Perhelion     21:07, 9. Jun. 2014 (CEST)
Ist nicht deprecated, sondern da stehen offene Zugriffe auf globale wg* drin und die sollten auf mw.config.get umgeschrieben werden; was soll ich denn deiner Meinung nach da sonst als Schlag- und Stichwort reinhauen? Heißßßß --PerfektesChaos 21:13, 9. Jun. 2014 (CEST)
Achso, dann schreib "fehlt" dazu. Wobei ich den Sinn dahinter, warum man die erst mit diesem get holen muss auch nicht verstehe.:P PS: Und ja, jemand sollte dir wirklich mal unter die Arme greifen, du hast ja schon wirklich einiges getan!blumen Perhelion     22:15, 9. Jun. 2014 (CEST)

Android: Tastatur verschwindet bei Suchvorschlägen[Bearbeiten]

Seit ein paar Tagen (letztes MW-Update?) verliert das Suchfeld wenn Vorschläge geladen werden den Fokus, wodurch sich die Tastatur schliesst, und wenn man Pech hat auch das Such-Interface, womit man dann auch die bisherige Eingabe wiederholen darf. Betroffene Browser sind Dolphin und Lightning, in Firefox und Opera tritt das nicht auf. --nenntmichruhigip (Diskussion) 00:02, 24. Feb. 2014 (CET)

Darstellungsfehler QS-Baustein in Mobilversion[Bearbeiten]

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

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

Darstellungsfehler.png

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

<Ende Übertrag>

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

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

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

Revertkonflikt endlich beheben[Bearbeiten]

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

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

Visual Editor Hinweistext aktualisieren[Bearbeiten]

Wenn man im Visual Editor Wikitext eingibt erscheint folgender Hinweistext: "Wikitext entdeckt Du benutzt VisualEditor. Wikitext funktioniert hier nicht. Klicke auf „Quelltext bearbeiten“, um die Seite im Wikitextmodus zu bearbeiten. Ungespeicherte Änderungen gehen dabei verloren." Der letzte Satz ist veraltet da mittlerweile die Änderungen erhalten bleiben. Wo kann man diese Hinweistexte beabeiten? --Saehrimnir (Diskussion) 16:20, 17. Apr. 2014 (CEST)

MediaWiki:Visualeditor-dialog-beta-welcome-content --Akkakk 17:54, 17. Apr. 2014 (CEST)
Hallo, hinter dem mittleren „kannst“ fehlt noch ein Komma. --Wiegels „…“ 18:23, 17. Apr. 2014 (CEST)
Da der englische Text das auch noch enthält, wäre es wohl besser, wenn man über bugzilla: geht, damit alle Sprachen etwas davon haben. Das Komma habe ich im Original gesetzt, sollte dann die nächsten Tage hier ankommen. Der Umherirrende 19:18, 17. Apr. 2014 (CEST)
Wunsch gibt es wohl als Bug 57700. Der Umherirrende 19:59, 12. Mai 2014 (CEST)
Wenn ich das richtig verstanden habe, bleiben die Änderungen auch nur erhalten, wenn man aus den Seitenoptionen die Wechselmöglichkeit auswählt, wenn man einfach auf den Link "Quelltext bearbeiten" klickt, dann gehen die Änderungen auch verloren, daher passt der Text im Moment noch, müsste nur um die andere Möglichkeit ergänzt werden. Es gibt aber auch noch Bug 57699, wo gewünscht wird, das auch "Quelltext bearbeiten" die Änderungen behält. Ich halte mich da lieber mal raus. Der Umherirrende 20:13, 12. Mai 2014 (CEST)

Hover-Effekt bei Imagemaps[Bearbeiten]

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

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

Wikipedia:Hauptseite/Jahrestage/Bearbeitungshinweise[Bearbeiten]

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

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

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

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

Bildverlinkungen in Galerien unterdrücken?[Bearbeiten]

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

Innerhalb einer Gallery kann man auf alternative Linkziele verweisen:

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

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

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

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

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

Kollision zwischen MediaViewer und Personendaten-Gadget[Bearbeiten]

Am 22. Mai soll hier der MediaViewer aktiviert werden. Er bietet die Möglichkeit, sich durch alle Bilder eines Artikels zu klicken. Dabei tauchen allerdings alle Bilder auf, auch Icons wie jene der Vorlage:Exzellent.

Zu diesem Zweck kann man Bereiche im Wikitext mit class="metadata" versehen. Solche Bereiche werden vom MediaViewer ignoriert. Allerdings verwendet das Personendaten-Gadget leider bereits denselben Klassennamen, und es ist nicht möglich, denselben Klassennamen für beide Zwecke zu verwenden.

Ich fände es wünschenswert, wenn wir das Problem vor dem 22. Mai lösen könnten. Eine Möglichkeit wäre, dass der MediaViewer seinen Klassennamen ändert; das fände ich aber eher unwahrscheinlich, weil die Kollision wohl nur dewiki betrifft. Alternativ könnten wir unseren Klassennamen ändern. Denkbare Vorschläge:

  • class="wp-metadata"
  • class="hidden"
  • class="maintenance"

Gibt es Meinungen oder insbesondere weitere Namensvorschläge hierzu?

Noch ein paar Aspekte:

  • Falls wir das Problem nicht lösen, werden wir die Möglichkeit, Icons vom MediaViewer auszuschließen, nicht nutzen können.
  • Ein Nachteil der Klassenumbenennung wäre, dass diejenigen, die die Personendaten bisher per User-CSS aktiviert haben, sich umstellen müssten. Ein Vorteil ist aber, dass dann vielleicht mehr Leute auf das Gadget umsteigen und wir in Zukunft nicht mehr so viel Rücksicht auf die anderen nehmen müssen.

Gruß --Entlinkt (Diskussion) 19:41, 7. Mai 2014 (CEST)

Der Name selbst wäre mir relativ egal.
Er sollte aber in die Systematik unter Wikipedia:Technik/Skin/CSS/Projektweite Selektoren passen, wie immer die aussehen möge.
  • Eine solche Systematik ist genau dazu vorgesehen, die vom Projekt vergebenen Selektoren von den durch MW vergebenen Selektoren zweifelsfrei unterscheiden zu können.
  • Hätte man sich viele Jahre früher um eine Systematik gekümmert und diese auch dokumentiert, würde jetzt kein derartiges Problem entstehen.
Um über den Namen entscheiden zu können, müsste man überhaupt einmal klarstellen, wozu der Selektor denn eigentlich gut sei soll:
  1. Um irgendwas mit Normdaten und Metadaten zu kennzeichnen; dann müsste der Begriff metadata darin auftauchen.
  2. Um zu signalisieren, dass der aktuelle Benutzer ein Vollprofi ist und verborgenene Elemente sehen möchte; dann ein anderes Schlüsselwort kennzeichnend.
  3. Um zu signalisieren, dass Wartungsinformationen angezeigt werden sollen, die für normale Leser uninteressant sind; dann wieder ein anderes Schlüsselwort kennzeichnend.
Mein Eindruck ist, dass der Selektor bislang quer durch den Garten für allerlei und dies und jenes benutzt wird.
Wenn es keinen internationalen Standard für den beabsichtigten Auswahlzweck gibt, dann kann es auch ein deutsches Schlüsselwort sein.
VG --PerfektesChaos 23:42, 7. Mai 2014 (CEST)
Der Selektor war ursprünglich (vor 10 Jahren) nur für Vorlage:Personendaten vorgesehen, die anderen Anwendungen haben sich auf ziemlich unsystematische und nicht wirklich abgesprochene Weise daran „angehängt“.
Aus diesem Grund weiß vermutlich keiner so ganz hundertprozentig genau, wozu er theoretisch dient. Für den nicht hundertprozentig spezifizierten Zweck (Verstecken von Dingen, so dass sie erst nach Setzen eines Kreuzchens sichtbar sind) funktioniert er aber in der Praxis und sollte weiter funktionieren. --Entlinkt (Diskussion) 23:59, 7. Mai 2014 (CEST)
Na, wenn wir schon umstellen müssen, dann gleich richtig:
  • Ich bin enzyklopädischer Leser und interessiere mich für enzyklopädische Zusatzinformationen wie Normdaten.
    • Diese und nur diese sollten dann angezeigt werden.
  • Ich bin Wartungsameise und suche nach den Lesern verborgenen Informationen über verunglückte Formate und Parameterwerte.
    • Das kann auch die Kombination class="error xxxxxx" sein; für normale Leser der Enzyklopädie unsichtbar.
    • Interessant für Vorlagenwartung und Datumskonventionen und Wartung bestimmter Datentypen.
  • Ich bin im Mentorenprgramm unterwegs und möchte Mentoren, Mentees oder was immer erkennen.
  • … … …
Wenn es nur genau einen Selektor für alle diese Verwendungszwecke gibt, dann ist das Kokolores.
  • Es muss auch nicht alles per Gadget-Häkchen ankreuzbar sein; ein C&P in das User-CSS ist Wartungspersonal zuzumuten.
VG --PerfektesChaos 00:16, 8. Mai 2014 (CEST)
Ich tendiere nach etwas Überlegung derzeit zum Klassennamen hidden. Der ist zwar präsentationsbezogen und nicht semantisch (und deshalb zunächst einmal „böse“), beschreibt aber ziemlich gut, was die Klasse tatsächlich tut und wofür sie tatsächlich benutzt wird.
Die Idee der Zerlegung würde ich zum jetzigen Zeitpunkt ehrlich gesagt nicht verfolgen, weil unsere Community immer wieder gerne äußerst verschnupft auf banale Änderungen an irgendwelchen technischen Dingen reagiert, denen keinen Meinungsbild vorausgegangen ist. Das jetzige Kuddelmuddel ist sicher nicht optimal, aber wenn die User-CSS-Anpassungen nicht mehr funktionieren, wird das schon genug Ärger geben, eine zusätzliche Zerlegung in viele einzelne Klassen würde die Leute überfordern. Bis jetzt hat es auch niemanden gestört, dass das Kuddelmuddel nur en bloc aktivierbar ist.
Gibt es denn irgendwelche Widersprüche dagegen? Ich würde das, wie gesagt, gerne recht zügig angehen. Der Ablaufplan wäre, den neuen Klassennamen in MediaWiki:Common.css und das Gadget und die Vorlagen einzubauen und dann nach ein paar Tagen den alten überall zu entfernen. Währenddessen sollte das Ganze vielleicht auch auf Wikipedia:Projektneuheiten kundgetan werden. --Entlinkt (Diskussion) 23:51, 8. Mai 2014 (CEST)
Ich mahne und warne.
  • Insbesondere finde ich es unweise, die Gelegenheit einer ohnehin erforderlichen Umstellung ungenutzt verstreichen zu lassen.
  • Mit Lua werden zukünftig sehr viel häufiger Gültigkeitsprüfungen auflaufen, die versteckte rote Fehlermeldungen produzieren. Wenn jemand Febuar 2007 geschrieben hatte, blieb das bislang unbemerkt. Künftig wird das nicht nur eine Wartungskat auslösen, sondern unter Hunderten von Vorlageneinbindungen im Artikel muss auch markiert werden, an welcher Stelle das vorkommt. Im Zusammenhang mit den Zitationsvorlagen rechne ich mit über 10.000 Artikeln in den Wartungskats, und entsprechend vielen roten Verzierungen.
  • Das Schlüsselwort hidden würde erneut die altbekannten Fehler wiederholen:
    1. Es ist nicht ersichtlich, dass es sich um eine lokale Festlegung handelt.
    2. Die nächste Namenskollision mit MW ist programmiert; nicht alle neu eingeführten Klassennamen bei MW tragen das Präfix mw- – so grad metadata, as see.
VG --PerfektesChaos 00:40, 9. Mai 2014 (CEST)

Wo ist hier überhaupt ein Problem?

MediaWiki:Gadget-Personendaten.css bekommt erstmal zusätzlich

div.Metadaten,
div.Mentoreninfo,
div.Wartungsinfo {
	display: block;
}
span.Metadaten,
span.Mentoreninfo,
span.Wartungsinfo {
	display: inline;
}
li.Metadaten {
	display: list-item;
}

und freundlicherweise schaltet MediaWiki:Common.css

.Metadaten,
.Mentoreninfo,
.Wartungsinfo {
	display: none;
}

und erspart es den einzelnen Vorlagen und Modulen, mit style= arbeiten zu müssen.

Für die zukünftigen Anwendungen gibt es nur noch div und span und die existierenden Nutzungen könnten ihre table wohl in ein großes div wrappen, so dass die Sonderregeln für tr und li usw. entfallen können. Ein li ohne sichtbaren Inhalt sollte bei smarten Browsern auch kein bullet erzeugen, aber dem IE würde ich auch das zutrauen.

Wenn jemand beim simplen Ankreuzen von „Personendaten“ zu viele Informationen bekommt, kann er sich über selektives Einblenden der gewünschten Informationsart im Benutzer-CSS den persönlichen Bedarf herausfiltern.

Die vorhandenen Vorlagen können bereits jetzt mit zusätzlichen Klassennamen ausgestattet werden; sodann bereits vor künftigen Kollisionen Benutzer-CSS nach und nach angepasst und metadata aus Benutzer-CSS vorsorglich eliminiert werden.

VG --PerfektesChaos 10:31, 10. Mai 2014 (CEST)

Sorry, aber ich würde eigentlich lieber weiter nach einem geeigneten Klassennamen für das bestehende Gadget suchen. class="Metadaten" wäre eine Möglichkeit, ich finde es zwar etwas unglücklich, wenn dasselbe Wort auf Deutsch und auf Englisch etwas unterschiedliches bewirkt, aber es wäre möglich.
Die Vorstellung dreier Klassennamen gefällt mir aber ganz und gar nicht – solange man nur einen hat, den jeder benutzen kann, vermehrt der sich nicht, aber wenn man mal drei hat, wird es schwer zu argumentieren, warum es nicht 5, 10 oder 20 sein sollen.
Von den jetzigen Selektoren im Gadget ist nur table.metadata theoretisch verzichtbar, indem man die Tabelle in ein <div> verpackt. Die Übrigen sind unverzichtbar, sonst hätte ich sie nicht eingefügt. Ich demonstriere das mal nur für den Fall <li> (<tr>, <td> <th> sind analog):
  • Anfang der Demonstration
  • Versteckter Text
  • Ende der Demonstration
Gruß --Entlinkt (Diskussion) 22:05, 12. Mai 2014 (CEST)


Auch sorry, aber ich sehe nicht, dass wir zukünftig um eine stärkere Diffferenzierung nach Art der ein-/ausblendbaren Textelemente herumkommen werden.
Die Benutzer werden ansonsten mit nachvollziehbaren Forderungen kommen, sie von den teils Dutzenden dicken roten Fehlermeldungen zu befreien, wenn sie irgendeinen Artikel lesen. Und die befallen dann alle Mentoren und alle Personendatler, die mit den sonstigen Wartungsarbeiten nichts zu tun haben wollen.
  • Die Vorlagen der alten Generation hatten ohne Parameterprüfung alle Werte akzeptiert; neue Programmierungen prüfen jedoch die Werte, insbesondere wenn Lua im Spiel ist. Wir haben aber noch eine riesige Altlast von -zigtausenden detektierbaren Fehlern im Artikelbestand, die in Kürze aufpoppen werden, weil halt irgendwer mal Febuar getippt hatte. Ich schreibe seit einem Jahr an den Detektoren, und mit Generationswechsel bei den Zitationsvorlagen wird es rund gehen.
Für fundamentale Zwecke von projektweiter Bedeutung kann und muss das nur über Klassen geregelt werden.
  • Dass die Anzahl der Klassen gering zu halten ist, ist mir auch klar.
  • Kleinere, lokale Aufgaben können inline in ein oder zwei Vorlagen geregelt werden; und ein kleiner Interessentenkreis wie etwa die Mentoren kann sich das in sein CSS reinkopieren und ist vom projektweiten Mediawiki-Namensraum abgekoppelt.
  • Das träfe etwa Vorlage:Mentor gesucht – sie könnte sich das display:none inline setzen und die Mentoren können sich das spezifisch sichtbar machen, wenn ihnen die allgemeine Sichtbarmachung sämtlicher verborgener Elemente per Gadget wie oben nicht mehr schmeckt.
  • Wer für seine eine Infobox eine eigene Klasse haben will, müsste schon eine sehr triftige Begründung haben.
  • Vorlage:Denkmalliste Österreich Tabellenzeile kann man gut einer Klasse .Metadaten zuordnen.
  • Deshalb sollen sich auch die Normdaten, die Personendaten, und alle vergleichbaren enzyklopädischen Zusatzinfos sich einen gemeinsamen Klassennamen teilen. Hast du einen besseren und verständlicheren Namensvorschlag für diese Thematik?
Nächste Aufgabe wäre es, per Dump alle irgendwo herumgeisternden Nutzungen von .metadata in den Vorlagen aufzuspüren und inhaltlich zu gruppieren. Die Volltxtsuche findet nicht alle bekannten Verwendungen.
  • Das wäre für eine Umstellung ohnehin erforderlich.
  • Alle Alt-Verwendungen genießen Bestandsschutz und werden in das Universal-Gadget aufgenommen, das gnadenlos sämtliche verborgenen Elemente sichtbar macht.
  • Sie werden umgekehrt über Common.css ausgeblendet, falls sie nicht (wo bei begrenzter Vorlagenzahl sinnvoll umsetzbar) durch inline-style= abgelöst wurden.
  • Wer sich beschwert, dass er zu viele Elemente sieht, kann dann das Gadget abschalten und mit aufgabenspezifischem CSS arbeiten.
  • Irgendwann wird kein aktiver Benutzer das Gadget mehr haben wollen.
Ich sehe nur zwei Anwendungen von projektweiter Bedeutung:
  1. Metadaten, wie bereits seit zehn Jahren.
  2. Wartungsaufgaben (Fehlermeldungen), durch Hunderte von Vorlagen ausgelöst.
  • Wer einen spezifischen Zweck für ein begrenztes Arbeitsfeld hat, soll es sich inline lösen und bekommt weder Gadget noch Common.css angepasst; die Benutzer sollen sich das ins CSS kopieren.
Fatal wäre es aber, den Unsinn der letzten Jahre blind fortzusetzen und weiterhin zu ignorieren, dass es unterschiedliche Gruppen von Benutzern gibt, die zu unterschiedlichen Zwecken spezielle Elemente eingeblendet bekommen müssen und andere nicht brauchen können; die Methode „entweder du guckst dir alle verborgenen Elemente an oder du darfst keines sehen“ ist ein Irrweg.
VG --PerfektesChaos 23:49, 12. Mai 2014 (CEST)

Python-Skripts[Bearbeiten]

Ich versuche, über ein Python-Skript auf die MediaWiki-API zuzugreifen. Vorläufiges Ziel ist, einen Test-Edit auf einer Seite in meinem BNR zu tätigen. Dazu habe ich mir die Skriptsammlung mwclient angeschaut, leider kriege ich sie nicht installiert bzw. eingebunden. (Ich habe die ZIP-Datei von Sourceforge genommen, da die Installation mithilfe Git und PIP-Befehl ebenfalls scheiterte) Wenn ich das auf dieser Seite angegebene Beispiel verwende, sagt der Compiler jedes mal, dass er das Modul mwclient nicht kennt. Weiß jemand weiter? MfG Chewbacca2205 (Diskussion) KALP braucht dich (und deine Artikel) 16:08, 9. Mai 2014 (CEST)

Hallo, pywikibot ist viel verbeiteter als mwclient, ich kenne diesen kaum. Ich verstehe nicht ganz weshalb die Installation per pip gescheitert ist, aber wenn du die Quellcode rumliegen hast solltest du mit
sudo python2 setup.py install
es Sytem-weit installieren können. Siehe auch dazu https://docs.python.org/2/install/, es gibt bei python sehr viele Möglichkeiten ein Modul zu installieren. Grüße sitic (Diskussion)

Danke für die schnelle Info. Wenn ich den pip-Befehl eingebe, dann sagt mir die Git-Konsole, dass sie den Befehl nicht kennt. Das pip-Skript habe ich mir zwar runtergeladen, allerdings meldet auch das Fehler. Ich hab das alles unter Windows 7 probiert, die Probleme können daran liegen, ich werde das mal mit Ubuntu probieren.

Den pywikibot habe ich mir gerade runtergeladen, wenn der aktiver verwendet wird, dürfte der auch häufiger aktualisiert werden. Wenn ich allerdings versuche, den zu starten, dann bekomme ich, wenn ich login.py ausführe, angezeigt, dass er das Modul pywikibot nicht findet. Es ist allerdings vorhanden, im Unterordner scripts/i18n. Orientiert habe ich mich an dieser Anleitung. MfG Chewbacca2205 (Diskussion) KALP braucht dich (und deine Artikel) 18:41, 9. Mai 2014 (CEST)

hast du die alte Version "compat" (aka "trunk") oder die Neuentwicklung "core" (aka "rewrite")? Es hört sich danach an, dass du die aktuelle hast. In diesem Fall bist du wahrscheinlich einfach nur im falschen Arbeitsverzeichnis, d.h. du musst in den übergeordneten Ordner gehen (in diesem Ordner sollte unter anderem die Ordner "pywikibot" und "scrips" liegen und von dort die Skripts aufrufen. In deinem Fall also scripts\login.py (für Windows). Die meisten Anleitungen sind noch für die alte Version, wo vieles in einem Verzeichnis lag --se4598 / ? 19:38, 9. Mai 2014 (CEST)

Ich habe core. Den Verweis habe ich jetzt angepasst, jetzt meldet das Skript allerdings einen anderen Fehler: cannot import name config. MfG Chewbacca2205 (Diskussion) KALP braucht dich (und deine Artikel) 22:57, 9. Mai 2014 (CEST)

Hmm da stimmt immer noch was mit den Pfaden nicht, versuchts mal mit
python pwb.py scripts\login.py
pwb.py ist ein Wrapper-Skript, das eigentlich nicht notwendig ist aber hoffentlich die Pfade richtig korrigiert. Bei Windows musst du ggf. auch wegen UTF-8 aufpassen, siehe mw:Manual:Pywikibot/Windows. Grüße sitic (Diskussion) 14:53, 10. Mai 2014 (CEST)

Hat leider auch nicht funktioniert, jetzt hat die Konsole einen Skriptfehler (undefinierter Bezeichner) in pwb.py gemeldet. Dann habe ich mir die compat-Version geladen, mit der funktioniert alles bestens. VG Chewbacca2205 (Diskussion) KALP braucht dich (und deine Artikel) 16:51, 10. Mai 2014 (CEST)

Ruckeln der Seite beim Laden von Navigationsleisten vermeiden[Bearbeiten]

Hallo,

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

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

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

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

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

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

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

Ob das technisch machbar ist, kann ich nicht beurteilen; da mir dieser Klappeffekt aber gerade aufgefallen ist: in der Sache dafür! Gruß, IW 20:46, 21. Mai 2014 (CEST)
Technisch machbar ist das auf jeden Fall, ich bräuchte nur jemanden, der die oben beschriebene marginale Änderung in MediaWiki:Common.js vornimmt (der Navileistencode muss schon beim ersten Laden der Seite und nicht erst beim ersten „toggle“-Vorgang die display-Eigenschaft aller Navileisten setzen).
Die Änderung ist absolut trivial, ich kann sie aber nicht selbst vornehmen, weil ich die JavaScript-Programmierkonventionen, die sich in den letzten Jahren massiv geändert haben, nicht kenne. (Ich habe zwar schon in der Datei editiert, das waren aber immer nur Löschungen und keine Hinzufügungen.) --Entlinkt (Diskussion) 04:58, 22. Mai 2014 (CEST)
Ein CodeStyle oder andere Konventionen gibt es auf MediaWiki:Common.js nicht wirlich. Ich hatte nur mal einige Dinge in jQuery umgewandelt, damit man sich weniger Gedanken um Browserkompatibilität machen muss. Manches sieht auch einfacher aus und escaping kommt manchmal auch direkt mit. Also nur zu, jeder Admin kann meine Änderungen auf der Seite gerne overrulen. Es wird wohl noch lange dauern bis erfahrende JavaScript-Benutzer die notwendigen Rechte wohlen und/oder bekommen. Der Umherirrende 19:54, 23. Mai 2014 (CEST)
  • Technisch möglich ist alles Mögliche.
    • Die Frage ist nur, was wir sinnvollerweise anbieten und unterstützen und warten und pflegen sollen.
  • Eigentlich ist das ein (geduldeter) Missbrauch der Nav-Klappfunkion.
    • Ich hab ja Verständnis und Sympathie dafür, dass es bei A2, A7 oder Transamericana ziemlich lang wird; jeder Bach, der in die Donau fließt, landet wohl auch in deren Infobox.
    • Wir fördern die Nutzung der Klappmechanismen aber nicht, und bieten auch absichtlich keine ausgefeilte deutschsprachige Doku an.
    • Die fraglichen Infoboxen sollten dann besser class="mw-collapsible" verwenden.
  • mw-collapsible
    • wird weltweit zentral gewartet, wir müssen uns nicht um die Pflege kümmern.
    • unterstützt ausdrücklich Vorgaben für initialen Zustand. Ohne JS wird immer ausgeklappt dargestellt, weil ohne JS der Leser sonst dumm sterben müsste.
    • 2012/13 gab es mal einen Bug mit irgendeiner dämlichen Animations-Spielerei. TMg hatte sich mähtig darüber aufgeregt. Ich weiß nicht, ob der heutzutage immer noch drin ist.
    • Siehe Wikipedia:Technik/Baustellen/collapsible Herausforderung zu Details.
  • In Artikeln ist die Klapperei unerwünscht.
    • Entweder die Information ist enzyklopädisch relevant, dann soll sie sichtbar sein; oder sie ist unwichtig, dann soll man sie weglassen. Oder man legt gesonderte Listenartikel an und lagert endlose Tabellen dorthin aus.
    • Wenn man das noch propagiert und erleichtert, werden die Artikel zu Adventskalendern umgebaut, und erfahrungsgemäß wird von einer nennenswerten Minderheit jede bunte Spielerei eingebastelt, völlig egal ob sie in der Situation sinnvoll ist oder nicht.
  • Unser Nav-Zeugs sollte perspektivisch aussterben.
    • Ich will da nicht weiter dran rumprogrammieren.
    • Dann bin ich auch noch schuld, wenn irgendeine Browser-Version rumspinnt.
    • Nebenwirkungen und Performance durchschaue ich grad nicht.
    • Vielmehr sollte das eines schönen Tages Bot-gestützt Zug um Zug durch mw-collapsible ersetzt werden.
    • Voraussetzung wäre, dass mw-collapsible robust läuft. Bin nicht aktuell, kenne keine Beschwerden.
    • Schon allein dass eine Funktionalität explizit das „Nav“ im Namen trägt, signalisiert, dass dies einen spezifischen Verwendungszweck hat und kein Maßstab für universelle Artikel-Dynamik sein kann; auch nur für diesen einen spezielle Anwendungsfall gewünscht ist.

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

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

Das ist natürlich ein Klassenname (class=) und keine ID (id=), bisher gab es wegen übereinstimmender Formatierung der Überschriften in Monobook und Vector (und in den 9 Jahren davor auch in den anderen Skins) keinen Grund, ihn zu benutzen und deshalb wird er auch nicht benutzt, was natürlich vor der Umbenennung geprüft wurde. Durch die Nicht-mehr-Übereinstimmung seit dem Typografie-Update letztens gibt es den nun aber doch, inklusive einer Anfrage, die Formatierung in unsere CSS-Dateien zu verlagern. Also passt man den unbenutzten Namen besser an die wikipediaweit allgemein übliche Konvention an, bevor damit begonnen wird, ihn zu benutzen.
Zurück zum Thema: Danke für die Ausführungen zu Navileisten, wegen genau solcher Bedenken fragte ich in diesem Fall nach. Allerdings denke ich nicht, dass sich irgendwer in absehbarer Zeit (~ etliche Jahre) daran trauen wird, unseren alten Code durch mw-collapsible zu ersetzen, weil letzteres wegen der leidlich funktionierenden Animation von zahlreichen Benutzern abgelehnt wird. (Im Gegensatz zu dem vorgenannten Klassennamen sieht den Unterschied zwischen NavFrame und mw-collapsible wirklich jeder und deswegen ist damit zu rechnen, dass das nicht nur Leute stören wird, die nach etwas suchen.)
Die Ablehnung von mw-collapsible geht so weit, dass die Verwendung aktuell sogar per Missbrauchsfilter protokolliert wird. Die Zweckentfremdung der NavFrame-Klasse in der fleißig ruckelnden Vorlage:Bilderwunsch ist dagegen durch ein Meinungsbild abgesegnet und neulich las ich auf den Fragen zur Wikipedia die Ankündigung eines Meinungsbilds, das mw-collapsible abschaffen möchte. Gruß --Entlinkt (Diskussion) 04:30, 23. Mai 2014 (CEST)
  • Ü1 nehme ich mit dem Ausdruck des Bedauerns zurück; hatte nicht genau hingeguckt und die Erwartungshaltung hinsichtlich aller anderen Vorlagen-ID in den mageren Teil des Diff projiziert.
    • Als Klassennamen hätte ich allerdings Überschrift1 erwartet: Weder das Präfix Vorlage_ noch der Hinweis auf eine Simulation sind für die Klassifizierung relevant; das soll ja gerade für die Zuweisung einer Eigenschaft genutzt werden, völlig egal wo und wie von der Klasse Gebrauch gemacht wird. Das ist dann allerdings schon vor neun Jahren vergeigt worden.
    • Aus diesem Grund hatte ich das class= auch nicht wahrgenommen.
    • Weiter in der Schwesterwerkstatt.
  • Als 2011 der Bilderwunsch geschrieben wurde, gab es noch kein mw-collapsible.
  • Es gibt drei Infoboxen für langgestreckte geografische Gebilde: Hochrangige Straßen, Flusssysteme und Bahnstrecken. Für diese drei und den Bilderwunsch ist eine initiale Einklappung sinnvoll; und hier sollte auf das vermutlich ruckelfreie mw-collapsible mw-collapsed umgestellt werden. Das bekäme noch nicht einmal der MBF mit.
  • Man sollte bei MW anregen, einen JS-Parameter für das Abschalten der Animiererei einzuführen.
    • Dann könnte die deutschsprachige Wikipedia das komplett abschalten.
    • Anime-versessene Benutzer können das dann persönlich übersteuern und wieder aktivieren.
    • Bisher wird ohne duration-Parameter übergeben an
    • Ein Konfigurationsparameter, der bei Nichtvorhandensein im Moment des Anklickens auf Standard=400ms zurückfällt und von uns auf Null gesetzt werden kann (oder von Langsamdenkern auch auf 2000ms) würde die Animation unterdrücken.
    • Preisfrage wäre, wohin und wie man diesen Konfiguartionsparameter benennen soll; es gibt kein Anwendungsobjekt und keine Struktur zum Andocken und damit nur einen globalen Namen, was weniger schön ist.
    • Benutzer:Umherirrender?
  • Bis ein breiter Konsens über das Verhältnis von Klappspaten und Enzyklopädie ermittelt wurde, werde ich das Feature ansonsten nicht fördern und mich neutral verhalten.
LG --PerfektesChaos 10:07, 23. Mai 2014 (CEST)
Ich glaube nicht, das man eine Abschaltfunktion für die Built-In-Klapp-Funktion durch den Code-Review bekommt, du kannst deine Ideen/Wünsche aber über Bugzilla einbringen, vielleicht irre ich mich auch. Vielleicht gibt es auch Zustimmung von anderen. Der Umherirrende 19:54, 23. Mai 2014 (CEST)
@Umherirrender: Ein Missverständnis? Es geht nicht um das vollständige Abschalten der Funktion, sondern um das optionale Abschalten der Animation durch Reduzierung der duration von 400ms auf 0. LG --PerfektesChaos 21:08, 23. Mai 2014 (CEST)
Ich meine mal gelesen zu haben, das extra auf fade umgestellt wurde, damit es Benutzern möglich ist, das zu deaktivieren (jQuery.fx.off). Ob man die Standardwerte für slow, fast oder default auch so beeinflussen kann, weiß ich nicht. Der Umherirrende 21:33, 23. Mai 2014 (CEST)
jQuery.fx.off sagt mir jetzt nichts? Klingt aber so, als würde dadurch die Funktionalität ganz abgeschaltet. Klappen soll es ja noch, aber auf einen Schlag und ohne Spielkram. --PerfektesChaos 21:49, 23. Mai 2014 (CEST)
OK, ich hab es jetzt einfach mal umgesetzt (im „alten“ Stil, genau wie der bisherige Code). Die „kreativen“ Verwendungen in Infoboxen und Bilderwünschen sind übrigens nur ein Grund unter vielen; ich finde das selbst bei „genuinen“ Navileisten so herum sinnvoller, weil es immer besser aussieht, wenn während des Seitenaufbaus etwas dazukommt, als wenn etwas kurz da ist und dann wieder verschwindet. --Entlinkt (Diskussion) 20:19, 23. Mai 2014 (CEST)
@PerfektesChaos: Ist zwar wirklich off-topic an dieser Stelle, aber ich wollte das doch mal sagen: MediaWiki bildet seit jeher für jede Wikiseite einen charakteristischen Selektor am <body>-Element, bestehend aus page- gefolgt von dem Seitennamen, in dem lediglich Zeichen, die man in CSS escapen müsste, durch Unterstriche ersetzt sind. Für diese Seite lautet dieser Selektor beispielsweise page-Wikipedia_Technik_Werkstatt. Und in Vorlagen ist es wiederum seit langer Zeit üblich, diesen Selektor ohne den Präfix page- – aber mit Vorlage_ – zu übernehmen. Das wird in Hunderten von Vorlagen so gemacht und ich habe – wie dem Bearbeitungskommentar auch zu entnehmen ist – lediglich an diese Praxis angepasst, denn Umlaute braucht man in Klassennamen nicht zu escapen (dies tut MediaWiki auch nicht), im Übrigen entsprach der Selektor aber bereits der üblichen Form. Gruß --Entlinkt (Diskussion) 16:59, 24. Mai 2014 (CEST)
Ich fürchte, wir reden etwas aneinander vorbei.
Mir ging es im Zusammenhang mit der aktuellen Typografie-Debatte schwerpunktmäßig um die einheitliche Formatierung von Überschriften und Simulationen; also um eine von außen zugewiesen Formatierung der Überschrift.
Dass Vorlagen Selektoren zugewiesen bekommen, so dass die Einbindungen auch im HTML-Dokument noch identifizierbar wären (kurioserweise teilweise aber auch als id= – aber das bei Vorlagen, die es nur einmal geben sollte) ist eine andere Geschichte; ich hatte die falsche Erwartungshaltung beim Blick auf den Diff und schlicht nicht richtig hingeguckt; bzw. die selektive Wahrnehmung hatte zugeschlagen.
Kurios ist, dass ich nur extrem selten sehe, dass jemand hinterher in Benutzer-CSS oder anderweitig von diesen mühsam verteilten Selektoren Gebrauch macht, sieht man einmal vom Ausblenden bestimmter Hinweistexte ab. Eigentlich sehe ich nur Letzteres.
Unglücklich finde ich, dass dieses Projekt in dem zurückliegenden Dutzend Jahre nie dokumentiert hatte, was es mit den selbst vergebenen Selektoren anstellt, welche es gibt, wie sie aufgebaut sein sollen, wo sie hingehören – der erste Ansatz dazu kam von mir, und ich breche unter der Nachhollast der unterbliebenen Dokumentationen und Beschreibungen zusammen.
LG --PerfektesChaos 17:30, 24. Mai 2014 (CEST)

Fehler mit tools.wmflabs.org[Bearbeiten]

Bei mir ist unten genannter Fehler aufgetreten:

Fehler: Gesicherte Verbindung fehlgeschlagen Dieser Fehler ist während einer Verbindung mit tools.wmflabs.org aufgetreten. SSL hat einen Eintrag erhalten, der die maximal erlaubte Länge überschritten hat. (Fehlercode: ssl_error_rx_record_too_long)

   Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen Daten nicht verifiziert werden konnte.
   Kontaktieren Sie bitte den Inhaber der Website, um ihn über dieses Problem zu informieren. Alternativ können Sie auch die Funktion im Hilfe-Menü verwenden, um diese Website als fehlerhaft zu melden.

Habe diesen Text kopiert und frage an, wer vielleicht helfen kann!? Danke! --Goldpremium (Diskussion) 16:36, 26. Mai 2014 (CEST)

Mit welchem Tool, und mit welchem Browser? --AKlapper (WMF) (Diskussion) 16:58, 26. Mai 2014 (CEST)

Hallo AKlapper! Danke für Deine schnelle Antwort! Ich kenne mich in der "Computersprache" nicht so richtig aus. Es betrifft die Verwaltung von Benutzern auf der Seite "Benutzerbeiträge": (Verwaltung globaler Benutzerkonten (Wikimedia Meta-Wiki) und "User Analysis for Goldpremium". Über welchem Browser dies läuft weiß ich nicht. Nach Pause und Neustart des Computers funktioniert es wieder. War diese Beschreibung richtig? Was kann ich machen, wenn dies noch einmal passieren sollte? Danke --Goldpremium (Diskussion) 22:42, 26. Mai 2014 (CEST)

Ich nehme mal an dass du den "Firefox"-Browser benutzt, da ich dafuer die meisten Internetseiten finde die besagte Fehlermeldung auflisten. Siehe die (englischsprachigen) Eintraege im Firefox-Supportforum zu diesem Thema, speziell https://support.mozilla.org/en-US/questions/976504 --AKlapper (WMF) (Diskussion) 04:09, 27. Mai 2014 (CEST)

Bilder werden im IE 6 nicht angezeigt[Bearbeiten]

Hallöchen,
mit IE6 auf Win XP werden seit kurzer Zeit (wenigen Wochen) auf Artikelseiten der de.wiki keine Bilder mehr angezeigt.
Dagegen funktionieren die Artikelseiten anderer wikis, z. B. en.wiki; auch die de-Bildbeschreibungsseiten funktionieren. Ich browse unangemeldet. Der Bug tritt mit und ohne JavaScript auf. Er ist Cache-unabhängig und Protokoll-unabhängig (http und https). Andere Browser (Opera, Firefox) funktionieren ebenfalls. Geladen werden die Bilder aber, weil eine als .mht gespeicherte de-Artikelseite die Bilder enthält.
Meine Vermutung: Statt eines gewöhnlichen <img>-Tags werden Bilder auf Artikelseiten irgendwie anders eingebettet.
Hat jemand Rat?
VG,
--85.181.154.110 22:01, 26. Mai 2014 (CEST)

Ich kann das teilweise bestätigen – nicht in einem echten IE 6 (den es nur noch unter dem nicht mehr unterstützten Windows XP und noch älteren Windows-Versionen gibt), sondern mit IETester unter Windows 7.
Die Bilder auf der Hauptseite werden angezeigt. Klickt man den heutigen Artikel des Tages an, dann sieht man, dass alle Thumbnails fehlen – der Platz, an dem sie sein sollten, ist aber frei. Scrollt man allerdings bis ganz nach unten, dann stellt man fest, dass das Exzellenz-Icon vorhanden ist. Nebenbei fällt aber auch auf, dass die Taxobox fehlt.
Ich schließe daraus, dass das Problem nicht Bilder allgemein betrifft, sondern speziell Thumbnails und Floats. Es wirkt so, als hätte man irgendwo visibility:hidden deklariert.
Die Ursache liegt sicher irgendwo in den lokalen CSS-Dateien, aber ich lehne es ehrlich gesagt ab, das zu debuggen, weil der IE 6 sogar von seinem Hersteller nicht mehr unterstützt wird und in Deutschland zurzeit 0,04 Prozent Marktanteil hat.
Falls jemand die Ursache findet, können wir schauen, wie man das beheben kann. (Die Formulierung, dass die Ursache bei uns läge, ist übrigens etwas ungenau – natürlich liegt die Ursache bei den haarsträubenden Bugs des IE 6 und nicht bei uns, unser Code ist 100%-ig standardkonform; als IE-6-Anwender wirst du es wahrscheinlich immer schwerer haben, weil die Webdesigner die Workarounds für diese Bugs zunehmend verlernen.)
Gruß --Entlinkt (Diskussion) 22:52, 26. Mai 2014 (CEST)
Die Lösung:
Die Sache scheint nicht an Wikipedia zu liegen, sondern am IE6. Das Problem besteht darin, dass dieser Browser sehr fehlerlastig ist, wenn ein Link mit einem Backslash beginnt. Bei Wikipedia sind es sehr häufig gleich zwei davon infolge, am Anfang eines Links oder Grafikaufrufs. ("//...")
Mit dem IE6 hatte ich damals mit meiner eigenen Internetseite auch Probleme bekommen, weil Links und Grafiken oft nicht gefunden wurden. Das Problem trat immer dann auf, wenn ich mit Backslashes einen oder mehrere Unterordner zurückspringen und dann zu einem anderen Unterordner abbiegen wollte. Damit kommt der IE6 offenbar nicht klar, weil er immer dann, wenn ein Link nicht mit einer kompletten URL beginnt, die aktuelle Position (Pfad) der aufrufenden Datei nicht berücksichtigt. Für jedes "/" am Anfang eines Links, müsste in der aktuellen Position (Pfad) der aufrufenden Datei, der Ordner am Ende des Pfades entfernt werden. Wenn es jedoch keine aktuelle Position (Pfad) gibt, dann kann natürlich nicht zu vorherigen Ordnern zurückgesprungen werden. Als ich dann für jeden dieser fehlerhaften Links die komplette URL mit Domain im Quellcode eingegeben habe, da funktionierte es wieder. --Sassenburger (Diskussion) 01:54, 27. Mai 2014 (CEST)
Ähm, ok nach eurem Alter möchte ich jetzt nicht fragen.ätsch Aber könnt ihr bitte aufhören Leichen zu fleddern! Wikimedia bietet keinen Support mehr für IE6 und auch Microsoft (mit dem Ende von Windows XP) gibt einen Dreck auf diesen. Woanders werden selbst IE7 Nutzer unter Strafe gestellt!!!(2012) Wenn man Internet Explorer Nutzer in Google eingibt kommt man gleich auf solcherlei Seiten. Und hier noch eine reputative Betrachtung die veranschaulicht, dass selbst der unterdurchschnittlichste Deutsche keinen IE verwendet!:D Liebe Grüße -- ΠЄΡΉΛΙΟ 04:50, 27. Mai 2014 (CEST)

Der IE6 hat Darstellungsprobleme bei Fließobjekten. Der Workaround dazu ist ein position:relative. Vermutlich ist dieser Workaround für den IE6 aus MediaWiki entfernt worden. Laut mw:Compatibility/Software for using MediaWiki#Browser unterstützt MediaWiki den IE6 noch als Grade B Browser. --Fomafix (Diskussion) 08:12, 27. Mai 2014 (CEST)

In dem Zusammenhang sieht natürlich gerrit:125250 verdächtig aus, auch wenn Krinkle behauptet, er hätte nur Code entfernt, der ohnehin nicht funktionierte. --132.230.1.28 11:59, 27. Mai 2014 (CEST)

Hallo Leute,
vielen Dank für eure Beiträge. Aber lasst uns doch bitte bei der Sache bleiben. Wir wollen nicht über Vor- und Nachteile von XP, IE6, Firefox, Google oder Facebook diskutieren. Es geht ausschließlich darum, dass die deutschsprachigen Artikelseiten seit kurzem dem IE6 die Artikelbilder vorenthalten. Ich nutze IE6 und fühle mich jetzt ausgeschlossen. Bis vor Kurzem ging das doch noch! Und die andersprachigen Wikis können es doch auch! Kann jemand, der etwas davon versteht, die deutsche Wikipedia wieder geradebiegen bitte?
VG,
--78.55.234.216 19:27, 27. Mai 2014 (CEST)

Wie gesagt: Wenn jemand etwas davon versteht und den Auslöser findet, kann das Problem sicherlich zügig behoben werden. Aber dazu müsste es eben jemand verstehen, und das ist nicht so einfach (Kenntnisse in korrektem CSS und JavaScript reichen nicht, sondern man muss die IE-6-Bugs kennen. Natürlich werden den IE-6-Nutzern keine Bilder absichtlich vorenthalten, sondern der IE 6 interpretiert irgendwelchen korrekten Code falsch.)
Und auch wenn es nicht deine Frage ist, ist jedem IE-6-Benutzer zu raten, allerschleunigst auf irgendeinen anderen Browser umzusteigen (egal welchen, einen schlechteren als den IE 6 wird man nicht finden.) --Entlinkt (Diskussion) 20:33, 27. Mai 2014 (CEST)
Im Monobook-Skin tritt das Problem nicht auf. Workaround: Spezial:Anmelden. --Entlinkt (Diskussion) 23:07, 27. Mai 2014 (CEST)
OK, ich konnte als einen von mehreren Auslösern mittlerweile das Codestück
#content {
        position: relative;
}
#bodyContent {
        position: static;
}
in MediaWiki:Vector.css identifizieren. Der Code ist von mir, ich bitte aber folgende Dinge zu bedenken:
  • Der Code ist schon seit einem Dreivierteljahr dort und die Bilder fehlen angeblich erst seit ein paar Wochen, also muss es mindestens einen weiteren Auslöser geben und nur die Kombination aus beidem provoziert den „Fehler“.
  • Der Code ist korrekt und funktioniert in allen anderen Browsern; es ist ein typischer IE-6-Float-Rendering-Bug.
  • Der Code ist für die jetzige Positionierung der Koordinaten in der rechten oberen Ecke zwingend erforderlich.
Als Lösung kämen folgende Optionen in Frage:
  1. Man verschiebt wegen 0,04 % IE-6-Nutzern die Koordinaten auch für die anderen 99,96 % an eine Stelle, die allen Benutzern mehr Probleme bereiten wird als die jetzige.
  2. Man baut eine Browserweiche ein.
Ich bin in diesem Fall dann doch gegen beides (mit Verweis auf den Workaround: Anmelden und auf Monobook wechseln oder eine eigene vector.css schreiben) und werde das deshalb anderen Admins überlassen. Viele Grüße --Entlinkt (Diskussion) 23:21, 27. Mai 2014 (CEST)

Hallo Leute,
ich habe das noch mal nachvollzogen. Bis zum 9.1.2014 ging es noch, ab dem 10.1.2014 hat die de-Wiki irgendetwas anders als die anderen Wikis gemacht. Gab es vom 9. zum 10.1.2014 eine Programmänderung?
VG,
--85.180.244.184 20:11, 28. Mai 2014 (CEST)

Es gab zwischen dem 26. November 2013 und dem 27. März 2014 keinerlei Änderungen an den relevanten lokalen CSS-Dateien MediaWiki:Common.css und MediaWiki:Vector.css. Allerdings wurde am Abend des 9. Januar 2014 MediaWiki 1.23wmf9 mit mehreren hundert Code-Änderungen eingespielt.
Ich weise nochmals darauf hin, dass der IE-6-Bug wahrscheinlich weder allein durch MediaWiki-Core-CSS noch allein durch lokale Anpassungen in dewiki ausgelöst wird, sondern durch eine Wechselwirkung zwischen beiden. (Natürlich enthält weder das eine noch das andere irgendeine Anweisung, Bilder unsichtbar zu machen.) --Entlinkt (Diskussion) 20:37, 28. Mai 2014 (CEST)
Eine Merkwürdigkeit (vlt. in dem Zusammenhang) ist mir auch aufgefallen, seit wann wird Transparenz auch auf normalen Seiten (vorher nur auf Commons auf den Dateiseiten selbst) mit den Karos dargetellt, auf Commons? :P Und vlt sollte die IP mal Gründe nennen warum er/sie nicht vom IE6 wegkommt!? Man kann auch ältere Versionen anderer Browser noch downloaden! Nichts gegen euere Hilfsbereitschaft, es servt ja auch niemand mehr mit DOS im Internet. -- ΠЄΡΉΛΙΟ 22:08, 28. Mai 2014 (CEST)
Als Grund für eingeforderte IE-6-Unterstützung wurde bisher immer genannt, dass an Arbeitsplatzrechnern in Unternehmen oft noch der IE 6 vorgeschrieben sei und die Verwendung anderer Browser unterbunden werde. Seit der Support-Einstellung durch Microsoft können vernünftige Unternehmen den IE 6 aber eigentlich gar nicht mehr einsetzen, und Privatleute können in der Regel durchaus updaten, unter Windows XP immerhin bis zum IE 8, der erstmals CSS 2.1 unterstützt.
Tun sie das nicht, dann entscheiden sie sich quasi freiwillig dafür, 1000-mal mehr Probleme als Benutzer anderer Browser zu haben. In dewiki sind die fehlenden Bilder auch bei Weitem nicht das einzige Problem (insbesondere fehlen Tabellen- und Bausteinhintergründe und Linksymbole, und der IE 6 berechnet Abstände falsch, so dass das gesamte Layout so aussieht, als wäre es von jemandem gemacht worden, der einen Knick in der Optik hat). Das ist teilweise schon seit Jahren so und stört kaum jemanden …
Wenn man einen auch nur halbwegs aktuellen Browser benutzt, hat man heutzutage kaum noch (und dann meist keine ernsten) Kompatibilitätsprobleme, weil die heutigen Browser standardkonform sind und standardkonformer Code einfach funktioniert, ohne dass man das überhaupt noch groß testen muss. --Entlinkt (Diskussion) 22:22, 28. Mai 2014 (CEST)
OK, ich habe den wirklichen Auslöser gefunden: Es ist gerrit:120528. (Demnach stimmt die von unserem IE-6-Benutzer oben genannte zeitliche Eingrenzung nicht.)
@Fomafix: In normalen Browsern ist die Deklaration #bodyContent { width: 100%; } natürlich wirkungslos, aber im IE bis einschließlich Version 7 ist width mit jedem anderen Wert als auto ein Trigger für die nicht standardkonforme hasLayout-Eigenschaft und beeinflusst deshalb die Darstellung massiv. Beim Hinzufügen oder Entfernen von hasLayout-Triggern muss man etwas aufpassen, weil hasLayout Bugs sowohl auslösen als auch beheben kann. --Entlinkt (Diskussion) 07:25, 29. Mai 2014 (CEST)
Oh, wenn das der Auslöser war, dann habe ich das verursacht. Ich bin auf das #bodyContent { width: 100%; } durch gerrit:54896 gekommen, dass den etwas unklaren Bug 34557 beheben soll. div { width: 100%; } ist nicht wirkungslos, sondern verbreitert das Element um padding und border.
Wenn der IE6 an der Stelle #bodyContent einen hasLayout-Trigger benötigt, um Fließobjekte korrekt darstellen zu können, und das entfernte #bodyContent { width: 100%; } einen solchen Trigger ausgelöst hatte, dann sollte wieder etwas eingefügt werden, dass beim IE6 wieder den hasLayout-Trigger auslöst. Was wäre hier eine geeignete CSS-Definition, die diesen Trigger auslöst und möglichst wenig Nebenwirkungen zu anderen Browsern hervorruft? Ist der IE7 hier auch von Darstellungsfehlern bei Fließobjekten betroffen? Kann jemand mit dem IE6 bei Bugzilla eine Meldung mit Screenshot zu diesem Problem machen? --Fomafix (Diskussion) 21:06, 29. Mai 2014 (CEST)
width:100% sollte in diesem Fall eigentlich tatsächlich wirkungslos sein, weil #bodyContent kein padding und border hat und eigentlich auch nicht zu erwarten ist, dass das jemals hinzugefügt wird.
Im IE 7 ist mir an dieser Stelle kein Darstellungsproblem aufgefallen. Die möglichen hasLayout-Trigger für den IE 6 wären (Übersicht):
  • position:absolute (scheidet aus)
  • floatnone (scheidet aus)
  • display:inline-block (müsste vor normalen Browsern versteckt werden)
  • width:100%
  • height:0 (müsste vor normalen Browsern versteckt werden)
  • zoom:1 (nicht valide)
  • writing-mode:tb-rl (scheidet aus)
Gruß --Entlinkt (Diskussion) 21:24, 29. Mai 2014 (CEST)
Hallöchen,
einen Screenshot hinterlege ich gern bei Bugzilla, aber ich habe noch nicht verstanden, wovon. Einfach von einer Seite mit nicht angezeigten Bildern?
Grüße,
--78.55.48.177 21:39, 29. Mai 2014 (CEST)
Ja, das wäre gut. Als Patch würde ich folgendes vorschlagen:
/* hasLayout trigger for IE6 to prevent rendering problems with floating objects (bug xxxxx) */
* html .mw-body-content {
	width: 100%;
}
--Fomafix (Diskussion) 21:45, 29. Mai 2014 (CEST)
@IE-6-benutzende IP: Falls du mal sehen möchtest, an welch trivialem Code dein Browser scheitert, habe ich rein spaßeshalber unter Benutzer:Entlinkt/ie6sucks.html einen minimalen Testfall hinterlegt. Ganze zwei Layout-Anweisungen (nämlich background:white und position:relative) reichen aus, um in diesem Scheiß-„Browser“ alle Float-Objekte unsichtbar zu machen! Und natürlich sind das Anweisungen, die sogar ein Browser von 2001 hätte verstehen müssen. Gruß --Entlinkt (Diskussion) 05:27, 31. Mai 2014 (CEST)
Hab ich ausprobiert. Danke für die Demo, war mir nicht bekannt!
VG,
--85.180.172.63 22:17, 1. Jun. 2014 (CEST)

Ich habe einen bug report erstellt:
http://bugzilla.wikimedia.org/show_bug.cgi?id=66008 Dort sind drei Screenshots hinterlegt. Die ersten beiden sind die ersten beiden Bildausschnitte der Seite "Fußball-Weltmeisterschaft_2014", der dritte Screenshot ist der erste Bildausschnitt der Seite "Fußball". VG,
--85.180.172.63 22:17, 1. Jun. 2014 (CEST)

Vielen Dank für die Meldung des Bugs. Unter Kommentar 5 wurde angemerkt, dass wenn der Darstellungsfehler nur dewiki betrifft, dann soll der Workaround auch in dewiki in MediaWiki:Common.css oder MediaWiki:Vector.css eingebaut werden.

Wenn

#bodyContent {
	position: static;
}

in MediaWiki:Vector.css der Auslöser ist, dann gehört auch dort der Workaround hin:

.mw-body-content {
	position: static;
}
/* hasLayout trigger for IE6 to prevent rendering problems with floating objects (bug 66008) */
* html .mw-body-content {
	width: 100%;
}

In dem Beispiel habe ich gleich #bodyContent durch .mw-body-content ersetzt, siehe MediaWiki Diskussion:Vector.css##bodyContent. --Fomafix (Diskussion) 13:28, 2. Jun. 2014 (CEST)

Ich kann mich ja auch mal hier melden ;) Kommentar 5 habe ich verfasst, und das Ganze hat auch einen Hintergrund (Man mag es kaum glauben :P): Und zwar fühle ich mich persönlich unwohl dabei, eine aus dem core entfernte Anweisung zur Unterstützung eines veralteten Browsers (ja, der IE6 ist nun mal schon ziemlich alt) wieder rein zu nehmen, weil ein Wiki ohne diese Anweisung beim IE6 Probleme macht. Langfristig geht die Entwicklung sowieso in die Richtung (ich meine damit das komplette Web), dass nur noch aktuelle Browser, bzw. Webtechnologien, unterstützt werden. Hierbei hat meiner Meinung nach eine Unterstützung für den IE 6 (und wenn man es radikal weitergehen würde auch der IE7 und IE8) nichts mehr zu suchen. Soweit meine Meinung zu dem Thema. Daher mein Vorschlag, dass dieser IE6 Fix in die Common.css oder Vector.css (je nachdem, wo das Problem denn nun auftritt) einzufügen, sollte es nur bei der dewiki zu solch einem Verhalten kommen. Grüße --Florianschmidtwelzow (Diskussion) 13:39, 2. Jun. 2014 (CEST)

Wie sieht's denn weiter aus? Hab ich das im Bugreport richtig gelesen, dass das Problem nur bei Seiten im Artikel-Namensraum auftritt? --Florianschmidtwelzow (Diskussion) 07:25, 4. Jun. 2014 (CEST)

Ja, ganz genau! Zum Beispiel funktionieren lokale und Commons-Bildbeschreibungsseiten super. Auch die Hauptseite sieht tadellos aus. Diskussionsseiten dagegen verhalten sich wie Artikelseiten und sperren mir leider die Bilder aus :(
--85.180.179.69 14:32, 5. Jun. 2014 (CEST)
Die Hauptseite sieht nur deshalb „tadellos“ aus, weil sie in eine unsichtbare Tabelle verpackt ist und Tabellen „hasLayout“-Elemente sind, so dass sogar der dumme IE 6 es hinkriegt, die Bilder anzuzeigen, was jeder andere Browser auch sonst hinkriegt.
Tatsächlich gibt es auf der Hauptseite andere Darstellungsfehler, die einem gestandenen IE-6-User aber wohl nicht auffallen, weil er sie seit 13 Jahren auf jeder Seite sieht – zum Beispiel sind die Abstände ober- und unterhalb der waagrechten Linie im Kasten „In den Nachrichten“ um ein Vielfaches zu groß, weil Trennlinien (<hr>-Elemente) sich im dummen IE 6 und auch im nicht ganz so extrem dummen, aber immer noch sehr dummen IE 7 überhaupt nicht normal stylen lassen (nicht einmal mit dem dämlichsten Workaround, es gibt einfach keinen), in jedem anderen Browser dagegen schon (und zwar natürlich ohne Workarounds, sondern mit ganz normalem Standard-CSS).
Von den Bildern schließt du dich im Wesentlichen selbst aus (nur um mal die Logik weiterzuspinnen, wegen der der Workaround im Core abgelehnt wurde), denn du hast mehrere Alternativen:
  • Einen anderen Browser verwenden, wie es 99,96 % (also ca. 2499 von 2500 Leuten) im deutschsprachigen Raum tun;
  • Spezial:Anmelden und dann unter Spezial:Meine Benutzerseite/common.css nach Herzenslust eine eigene, von IE-6-Workarounds gespickte CSS-Datei schreiben (und dabei vielleicht auch mal lernen, wie vieß „Spaß“ das macht).
Ich war schon ganz zu Beginn dieses Threads davon ausgegangen, dass das Problem durch einen versehentlich aus dem Core entfernten Workaround verursacht wurde und deshalb davon ausgegangen, dass er unproblematisch wieder eingefügt wird, weil MediaWiki den IE 6 noch unterstützt. Ob wir lokal als deutschsprachige Community das noch tun, weiß ich allerdings nicht – unter mw:Compatibility/Software for using MediaWiki#Grade B heißt es, es werden Browser mit über 0,1 % Marktanteil unterstützt, und dies ist im deutschsprachigen Raum bereits deutlich unterschritten (weltweit leider noch nicht, v. a. wegen illegaler XP-Installationen in China).
Da in ein paar Wochen ein Edit auf MediaWiki:Vector.css notwendig wird, überlege ich jetzt doch halbwegs ernsthaft, den Workaround dann einzubauen, bin aber andererseits auch irgendwie dagegen, weil er halt nun mal aus dem Core entfernt wurde (was immer passieren kann und sich definitiv wiederholen wird und im Zweifelsfall einfach Pech für IE-6-User ist) und lokal bei uns neu wäre und es absolut anachronistisch ist, im Jahr 2014 nach Einstellung des Supports durch Microsoft noch neue IE-6-Workarounds einzufügen. Gruß --Entlinkt (Diskussion) 21:43, 5. Jun. 2014 (CEST)
@Entlinkt: Ich stimme dir da voll und ganz zu, möchte aber noch anmerken, dass der Revert des betreffenden Commits für den core auch deshalb abgelehnt wurde, da dass Problem lediglich hier im dewiki reproduzierbar ist. Zudem ist die IE6 Unterstützung eingeschränkt (man beachte auch den letzten Satz im Bereich Grade B auf der verlinkten Seite). Auch sollten sich IE6 User (um das Thema mal gleich erneut anzuschneiden) schon alleine wegen der in Zukunft fehlenden Sicherheitspatches Gedanken dafürber machen zumindest auf den IE8 upzugraden. Ich gehe davon aus, dass auch in Zukunft weitere IE6 Fixes im core (davon gibt es ja auch noch hier und da ein paar) verschwinden werden :) Meine Meinung steht dazu also recht eindeutig fest: keine Einführung von lokalen IE6 Fixes. Aber das müssen andere entscheiden :P (nicht signierter Beitrag von Florianschmidtwelzow (Diskussion | Beiträge) 07:36 , 6. Jun. 2006 (CEST))

Und wenn ich ganz lieb "Bitte, bitte" sage?
 :)
--85.180.246.81 15:47, 8. Jun. 2014 (CEST)

Das müssen die Zuständigen entscheiden, die das entscheiden können. Allerdings nochmals der Hinweis, dass damit nicht das eigentliche Problem, der IE6 an sich, gelöst wird, sondern nur "wieder" Bugfixing für einen längst veralteten Browser betrieben wird ;) Und wer IE6 (egal ob geschäftlich oder privat) verwendet geht eben leider auch wissentlich ein Risiko ein, sowohl in Anbetrcht der Sicherheit/Sicherheitspatches, wie auch der Darstellung standardisierter Objekte und Webelemente :) --Florianschmidtwelzow (Diskussion) 07:16, 10. Jun. 2014 (CEST)
Ok, ich hab noch nicht verstanden, wie's jetzt weitergeht.
--92.227.230.250 19:24, 17. Jun. 2014 (CEST)

Typografie-Helferlein; Erweiterte Beobachtungsliste[Bearbeiten]

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

Bugmeldung MediaViewer: unvollständige Darstellung nach Vollbildanzeige[Bearbeiten]

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

Umgebung: FireFox 29.0.1, Windows Vista SP2.

WP-Situation: eingeloggt, Vector.

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

Testseite: Artikel Ata Demirer.

Vorgehensweise zum Nachvollziehen des Bugs (in Schritten):

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

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

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

danke für die meldung. eingetragen unter bugzilla:66146 --se4598 / ? 01:10, 5. Jun. 2014 (CEST)
Lieben Dank für Deine Begutachtung und Unterstützung. --YAAA NOOO? 01:55, 5. Jun. 2014 (CEST)

Problem mit Tabelle in der mobilen Version[Bearbeiten]

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

Man könnte probieren eine feste Höhe zu setzen (wie es bei gutem Webdesign üblich ist). Ansonsten glaube ich weniger, dass man da was machen kann. User: Perhelion   10:35, 16. Jun. 2014 (CEST)
Siehe auch bugzilla:64577 - Tabellen in mobilen Ansichten sind immer noch problematisch. --AKlapper (WMF) (Diskussion) 10:45, 16. Jun. 2014 (CEST)

"Diskussion" als Nicht-Link[Bearbeiten]

Ziemlich nebensächlich, aber nachdem ich's einmal wahrgenommen habe, nervt es mich: Auf der Diskussionsseite jeden Benutzers wird das Wort "Diskussion" als Bestandteil seiner(!) Unterschrift fett geschrieben. Damit sticht das, was am wenigsten wichtig in diesen Texten ist, am meisten hervor. Eigentlich könnte man das Wort da sogar weglassen, denn ich bin ja auf der Seite, auf die das Wort eigentlich verlinken sollte. Aber statt es als Link zu formatieren, schreibt irgendein Automatismus es fett. Womöglich ist das auch noch nicht lange so, denn erst jetzt fällt es mir auf. --Karsten Meyer-Konstanz (Diskussion) 23:13, 3. Jul. 2014 (CEST)

Nein, das ist im Prinzip wohl schon seit mehr als zehn Jahren so.
Ursache ist der Umstand, der in Navileisten ausgenutzt wird: Beim Selbstlink, also dem Link auf die Seite selbst, wird sie in Fettschrift gezeigt, damit man sich orientieren kann. Auch hier ganz oben rechts gibt es eine Linkbox, in der die momentane Position „Werkstatt“ so hervorgehoben ist.
Deswegen geben viele das Link nicht in der Signatur an, s. u.
Abhilfe auf Server-Seite ist nicht realistisch, und perspektivisch wird sich da auch niemand mehr reinstürzen wollen.
  • Hier im Projekt könnten wir allerdings was tun.
  • Die Teile haben: <strong class="selflink">
  • Das ließe sich im Namensraum 3 mit Glück unterdrücken.
Zumindest auf Hilfe:Signatur sollte man ansonsten die Problematik erwähnen; da steht es offenbar noch nicht drin.
LG --PerfektesChaos 00:00, 4. Jul. 2014 (CEST)
Ganz herzlichen Dank für die ausführliche und auch für mich gut verständliche Antwort, PerfektesChaos! (Den Link in meiner Unterschrift wegzulassen, hilft ja nur auf meiner Seite). --Karsten Meyer-Konstanz (Diskussion) 00:32, 4. Jul. 2014 (CEST)
Der Link auf die Diskussionsseite in der Standard-Signatur ist noch nicht so lange. Selflinks aber generell auf Diskussionsseiten zu entschärfen scheint mir dann auch zu viel zu sein, vorallem wenn jemand eine Tableiste für seine Unterseiten nutzt und das Fette auch haben möchte. Nur die Signaturen wird man aber nicht erwischen. Im englischen ist das Wort kürzer, da fällt das wohl nicht so auf, da dort das ganze wohl kein Thema ist. In en.wp sind die Signaturen aber eh etwas ausgegefallender, so dass das vermutlich garnicht auffällt. Alternativ muss man die lokale Version um den Check auf die eigene Seite einbauen und den Check substen, so dass man davon nichts mehr sieht. Der Umherirrende 17:31, 4. Jul. 2014 (CEST)
Habe mal auf beta die entsprechende Nachricht angepasst. Rumspielen erwünscht ;-) Der Umherirrende 17:39, 4. Jul. 2014 (CEST)
  • Wenn jemand Spielkind ist und Tableisten einsetzt, dann ist der aktuelle Tab sowieso schon optisch hervorgehoben, und wer dazu auch noch fett braucht, kann sich das notfalls selbst programmieren.
  • Die weitaus überwiegende Zahl der selflink kommt aus der Standard-Signatur.
  • Richtig ist, dass die Standard-Auflösung der Tilden erst seit einigen Jahren die Disku mitverlinkt, während selbstgestaltete Signaturen das schon länger haben. Dafür hatte man das dort meist auf einen Buchstaben oder Symbol beschränkt, deshalb fiel das nicht auf.
  • Erklär mir mal lieber, was ich auf MediaWiki:Signature eigentlich sehe? Ist das diese Tildenauflösung, und wir können die konfigurieren? Ich dachte, das liefe auf dem Server und sei dort vor einigen Jahren weltweit geändert worden (doch schon 2008? Wie die Zeit vergeht.).
  • Der Beta-Test scheint erfolgreich; das sollten wir auf alle Fälle für zukünftige Standard-Tilden übernehmen. Wobei das Wort „Diskussion“ samt Klammern drumrum auf der eigenen Disku dann komplett entfallen kann; das ist nur auf anderen Seiten sinnvoll.
  • Fraglich ist, was wir mit den Altbeständen machen.
Schönes Wochenende --PerfektesChaos 23:18, 4. Jul. 2014 (CEST)
MediaWiki:Signature enthält die Standardsignatur, die genutzt wird, wenn du keine fancysig (Individuell gestaltete Signatur (Hinweise und Hilfe zur Änderung der Signatur)) hast. MediaWiki:Signature-anon enthält die Standardsignatur für IPs (die ja keine Einstellungen und damit kein fancysig haben können). Geändert wurde damals (rev:99404) nur die entsprechende Systemnachricht. Die Systemnachricht wird immer in der Inhaltssprache genutzt. Altlasten würde ich so lassen. Wenn man das (Diskussion) ganz weglässt, dann sehen die gerenderten Signaturen aber auf den Seiten sehr unterschiedlich aus, wenn ich nicht so schön fände. Der Wikitext ist durch den fehlenden Link eh schon etwas anders, aber das sollte wohl weniger stören. Der Umherirrende 10:40, 5. Jul. 2014 (CEST)

Darstellungsprobleme Menü oben rechts[Bearbeiten]

Seit einiger Zeit wird oben rechts das Ausklappmenü für Aktionen wie zB "Verschieben" (das div-Element mit der id "p-cactions") verändert dargestellt. Die Einträge stehen nun über den rechten Bildschirmrand hinaus, wenn sie zu lang sind. Das Problem tritt bei mir durch das Verschieben der Suche nach links (mit Benutzer:✓/vector/suchenachlinks.js) nahezu immer auf. Ist es möglich das Menü mit ein paar CSS-Zeilen so rechtsbündig anzuzeigen, dass die kompletten Tooltitel wieder sichtbar sind?

Bsp

Sollte man dafür einen Bug einreichen, oder eher nicht (da der Fall ohne suchenachlinks ja sehr viel seltener auftritt)?

Danke für eure Zeit.--CENNOXX 11:47, 7. Jul. 2014 (CEST)

Heisst das implizit, dass das Problem bereits manchmal auch ohne suchenachlinks aufgetreten ist (da du "sehr viel seltener" schreibst)? --AKlapper (WMF) (Diskussion) 12:16, 7. Jul. 2014 (CEST)
Nein. Wenn die Bezeichnung eines zusätzlichen Tools sehr lang ist (wie lang darf die sein?), kann das Problem zwar theoretisch auch ohne suchenachlinks auftreten, aber nicht bei den standardmäßig zur Auswahl stehenden Punkten wie "Verschieben".--CENNOXX 13:58, 7. Jul. 2014 (CEST)
In Spezial:MyPage/vector.css einfügen:
div.vectorMenu div.menu {
  left: auto;
  right: -1px;
}
--Schnark 10:18, 11. Jul. 2014 (CEST)