Wikipedia:Technik/Archiv/2014

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Projektseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Wikipedia:Technik/Archiv/2014#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia:Technik/Archiv/2014#Thema_1

Aus Hilfe:Diskussion:Einstellungen "Aussehen" unter firefox

(monobook etc) setzt beim Anmelden aus. Auf allen Projekten und Sprachen. Stattdessen eine Aufreihung von Text ohne Format und ohne Bilder. Unter Explorer funktioniert es tadellos. Wie lässt sich das bei Firefox wieder reparieren? Danke--Wheeke (Diskussion) 08:53, 18. Jan. 2014 (CET)

Klingt ja ungesund.

Ich habe ein paar Rückfragen; die Antworten bitte an die Wikipedia:TW und hier erl.:

• Einmal massive Cache-Leerung (Löschung von der Festplatte)? Wikipedia:JS #Cache.
• Gibt es im FF irgendwelche Add-ons mit Sicherheitsaufgaben, wie etwa NoScript?

nicht dass ich wüsste, jedenfalls kein noscript.

• Du schreibst „monobook etc“ – hattest du es mit der Skin „vector“ probiert?

ja, es funktioniert mit allen nicht

Wird schon wieder werden; ich habe auch FF, FzW schweigt, trifft also nur dich allein und ist kein weltweiter Bug. --PerfektesChaos 09:14, 18. Jan. 2014 (CET)

FF de- und neuinstalliert, das Problem bleibt bestehen, gruß--Wheeke (Diskussion) 10:55, 18. Jan. 2014 (CET)

Hm, „de- und neuinstalliert“ ist eine sehr radikale Lösung; aber die überleben weder Cache noch Add-ons.

• Du verwendest https:?
• FzW schweigt, ich sitze auch vor einem FF; es muss etwas sein, was dich persönlich trifft.
  • Netzwerk-Anbindung? Allgemeiner Provider, oder ein internes Netzwerk wie an einer Uni oder in einer Firma?
  • In den letzten Tagen irgendwelche Konfigurationsänderungen, am PC, am Netzwerk?

Millionen andere können das, also kriegen wir das auch hin. --PerfektesChaos 11:19, 18. Jan. 2014 (CET)

Unterwegs auf einem Hotelanschluss. Seitdem ist das so :-(Wheeke (Diskussion) 12:16, 18. Jan. 2014 (CET)

Ah ja, deswegen fragte ich jetzt schon dezidiert nach der Netzwerk-Anbindung.

• Die Symptome passen gut auf folgende Situation:
  • Du bekommst die Seiten oder nicht alle Seiten von einem Wiki-Server, sondern dazwischen liegt noch ein Netzwerk-Knoten; etwa vom Hotel oder dessen Telekommunikations-Anbieter.
  • Der liefert dir eine veraltete oder beschädigte Seite.
  • Der IE bemerkt den Fehler nicht und kann damit umgehen; in Firefox stürzt eine Prozedur ab und es wird nicht alle Dekoration in der Seite eingebunden.
• Abhilfe dagegen, und deshalb oben meine Rückfrage: Arbeitest du unter https:?
  • Falls nicht, häng doch mal ein „s“ in die URL (im Adressfeld).
• Weitere Möglichkeit: Das Netzwerk könnte sehr langsam sein; Firefox wartet 30 Sekunden auf irgendeine Info vom Wiki-Server und gibt dann auf; und zeigt das, was bis jetzt da ist.
• Eine weitere Möglichkeit (Web Storage beschädigt) scheidet durch die De- und Neuinstallation aus.
• Meine letzte Idee: JavaScript deaktivieren.
  • Heutzutage leider kompliziert; kein Häkchen verfügbar:
    1. about:config in das URl-Feld kopieren.
    2. javascript.enabled in die Suchmaske (Suchen:) kopieren.
    3. Auf das Feld einmal draufklicken; wechselt von true auf false und wird fett.

Viel Erfolg und gute Reise --PerfektesChaos 12:44, 18. Jan. 2014 (CET)

Vielen Dank. Leider ändert sich auch jetzt nix. Benutze https. Bin auch wieder am heimischen soliden T-Online Anschluss :-(--Wheeke (Diskussion) 13:27, 18. Jan. 2014 (CET)

Allmählich wird es schwierig. Es dauert zwar, bis mir die Ideen ausgehen, aber jetzt fängt der exotische Teil an.

• Sind nur Wikipedia-Seiten betroffen, oder gibt es auch Seltsamkeiten auf anderen Websites?
  • nur WP-Seiten
• Unangemeldet genauso wie angemeldet, oder sehen als IP die Seiten besser aus?
  • Unangemeldet natürlich nicht. Da bietet sich die jedem Unangemeldeten mögliche (vermutlich identische) Ansicht. Aber sobald ich auf Login klicke, geht das Spektakel los :-(
• Könntest du einen Virus haben? Soll ja auf Fernreisen vorkommen, dass man sich da etwas einfängt.
  • Keine Ahnung. Wenn ja, wie erfährt man das? Wie entfernt man das?
• Wenn du ein privates Fenster aufmachst, also Strg+Umschalt+P, und dort in der URL eine Wiki-Adresse eingibst: Gleiches Theater?
  • Gleiches Theater :-(--Wheeke (Diskussion) 15:46, 18. Jan. 2014 (CET)

Mit der De- und Neuinstallation sind alle verdrehten Konfigurationseinstellungen des Browsers, Cache und überhaupt beseitigt. Damit sind eine Reihe browserspezifischer Aspekte außen vor. Problem müsste dann im Rechner oder auf der Netzwerk-Strecke liegen. Letztere ist mit https und zügigem T-Online auszuschließen.

Nur Mut --PerfektesChaos 15:32, 18. Jan. 2014 (CET)

Eventuell Häkchen unter Ansicht → Webseiten-Stil → Kein Stil gesetzt? XenonX3 – (☎ – RIP Lady Whistler) 15:51, 18. Jan. 2014 (CET)

@ Kein Stil – kaum; das beträfe alle Webseiten, und auch unangemeldet. Außerdem wurde der Browser deNeu-installiert; dann ist das weg.

• Aber mit der Benutzeranmeldung muss es dann etwas zu tun haben; ich weiß bloß nicht was.
• Man sollte generell auf jedem Rechner einen kostenlosen Virenscanner zu laufen haben; der meldet sich dann schon. Kommt hier aber kaum in Frage, weil Schadsoftware nicht zwischen angemeldeter und nicht angemelder Wikipedia-Benutzung unterscheidet.

Wheeke hat keine Unterseiten, keine Skripte; sicherlich auch kein Greasemonkey. Sonst wüsste ich 1.000.000 Möglichkeiten, was schiefgehen kann.

Benutzer:Wheeke/common.css kannst du übrigens der besseren Übersichtlichkeit halber leeren; das gibt es nicht mehr. Oder gleich einen SLA reinschreiben; noch übersichtlicher.

Denkpause --PerfektesChaos 16:10, 18. Jan. 2014 (CET)

• Bei dem Gerät handelt es sich um was mobiles, weil Hotelzimmer, aber nicht gerade ein Smartphone oder eine Armbanduhr? Also Laptop oder so ähnlich?
  • Laptop
• Im Firefox: Strg+Umschalt+J → Es erscheint eine Browser-Konsole.
  • Diese so schalten, dass nur bei „JS“ nur die „Fehler“ erscheinen (alles andere ist egal).
  • Als IP dürften keinerlei Meldungen sichtbar sein.
  • Werden angemeldet beim Seitenaufbau irgendwelche Beschwerden gemeldet? C&P!

sowas?:

08:23:15.268 Unbekannte Eigenschaft '-moz-box-shadow'. Deklaration ignoriert. %E5%B0%81%E9%9D%A2
08:23:15.268 Unbekannte Eigenschaft '-moz-border-radius'. Deklaration ignoriert. %E5%B0%81%E9%9D%A2
08:23:15.268 Fehler beim Verarbeiten des Wertes für 'background'. Deklaration ignoriert. %E5%B0%81%E9%9D%A2
08:23:15.268 Farbe erwartet, aber 'top' gefunden. Fehler beim Verarbeiten des Wertes für 'background'. Deklaration ignoriert. %E5%B0%81%E9%9D%A2
08:23:15.269 Farbe erwartet, aber '#C26DEFE' gefunden. Ende des Werts erwartet, aber '#C26DEFE' gefunden. Fehler beim Verarbeiten des Wertes für 'border'. Deklaration ignoriert. %E5%B0%81%E9%9D%A2
08:23:20.013 Fehler beim Verarbeiten des Wertes für 'background'. Deklaration ignoriert. mobile.css:43
08:23:20.016 ',' oder '{' erwartet, aber 'html' gefunden. Regelsatz wegen ungültigem Selektor ignoriert. stylesOldB.css:164
08:23:20.016 ',' oder '{' erwartet, aber 'html' gefunden. Regelsatz wegen ungültigem Selektor ignoriert. stylesOldB.css:168
08:23:23.539 'none' oder URL erwartet, aber 'alpha(' gefunden. Fehler beim Verarbeiten des Wertes für 'filter'. Deklaration ignoriert. newtab:1
08:23:23.539 Unbekannte Eigenschaft '-moz-opacity'. Deklaration ignoriert. newtab:1
08:23:23.539 Unbekannte Eigenschaft 'box-sizing'. Deklaration ignoriert. newtab:1
08:23:23.542 Falsch verwendeter Kombinator. Regelsatz wegen ungültigem Selektor ignoriert. newtab:5
08:23:29.633 Unbekannte Eigenschaft '-moz-box-shadow'. Deklaration ignoriert. load.php:1
08:23:29.633 'none' oder URL erwartet, aber 'alpha(' gefunden. Fehler beim Verarbeiten des Wertes für 'filter'. Deklaration ignoriert. load.php:1
08:23:29.633 Fehler beim Verarbeiten des Wertes für 'display'. Deklaration ignoriert. load.php:1
08:23:29.633 Unbekannte Eigenschaft 'zoom'. Deklaration ignoriert. load.php:1
08:23:29.633 Deklaration erwartet, aber '*' gefunden. Übersprungen bis zur nächsten Deklaration load.php:1
08:23:29.633 'important' erwartet, aber 'ie' gefunden. ';' oder '}' zum Beenden der Deklaration erwartet, aber 'ie' gefunden. Deklaration ignoriert. load.php:1
08:23:29.633 Fehler beim Verarbeiten des Wertes für 'background'. Deklaration ignoriert. load.php:1
08:23:29.634 Fehler beim Verarbeiten des Wertes für 'list-style-type'. Deklaration ignoriert. load.php:1
08:23:29.634 Unbekannte Eigenschaft 'user-select'. Deklaration ignoriert. load.php:1
08:23:29.635 Unbekannte Eigenschaft 'box-sizing'. Deklaration ignoriert. load.php:1
08:23:29.635 Fehler beim Verarbeiten des Wertes für 'background-image'. Deklaration ignoriert. load.php:1
08:23:29.635 Unbekannte Pseudoklasse oder Pseudoelement '-webkit-input-placeholder'. Regelsatz wegen ungültigem Selektor ignoriert. load.php:1
08:23:29.635 Unbekannte Pseudoklasse oder Pseudoelement '-ms-input-placeholder'. Regelsatz wegen ungültigem Selektor ignoriert. load.php:1
08:23:29.636 Unbekannte Eigenschaft 'break-inside'. Deklaration ignoriert. load.php:1
08:23:29.637 Unbekannte Eigenschaft 'speak'. Deklaration ignoriert. load.php:1
08:23:29.637 'none' oder URL erwartet, aber 'chroma(' gefunden. Fehler beim Verarbeiten des Wertes für 'filter'. Deklaration ignoriert. load.php:1
08:23:29.637 Unbekannte Eigenschaft 'zoom'. Deklaration ignoriert. load.php:1
08:23:29.637 Name einer Medienfunktion erwartet, aber '-webkit-min-device-pixel-ratio' gefunden. load.php:1

• Alle betafeatures deaktivieren – falls an. Wüsste nicht, wer damit spielt. „Typografieaktualisierung“ wäre ein Kandidat für Ärger; ist aber nur auf vector, nicht auf monobook.
• Bei allen Helferlein notieren, welche aktiv sein sollen; danach alle deaktivieren, enthakeln.
  • Wirkung?

Null

• Gibt es eine „verbundene Anwendung“ mw:Help:OAuth?

Nein

• Spracheinstellung (Zahnrad links bei Interwikis; wenn wohl nicht mehr sichtbar, notfalls Spezial:Einstellungen): Anzeigesprache deutsch?

Ja

• • Indiskrete Frage, und irrwitzige Idee im Hinterkopf: Befand sich das Hotelzimmer im halbwegs deutschsprachigen Raum, oder ganz weit weg?

Mitteldeutschland

• Wenn du dich mal in einem anderen Wiki anmeldest, auf dem du früher schon mal angemeldet warst (vielleicht Wikisource oder enWP) – wie sieht das da aus?

Genauso komisch

• • Wenn da auch komisch: Melde dich mal bei gan: an (draufklicken sollte reichen) – da warst du sicher noch nie.
• Neues Benutzerkonto anlegen; nur so zum Spaß.
  • Dort genauso, oder alles normal wie bei IP?

Genauso. Wheeke (Diskussion) 08:43, 19. Jan. 2014 (CET)

@ Werkstattkollegen: Vor Jahren gab es doch mal einen Button Alle Einstellungen zurücksetzen – gibt es den noch, und ich habe den irgendwo ausgeblendet und eliminiert, oder wurde der abgeschafft?

• Wenn es den noch geben sollte: Letztes Mittel, dann weiß ich auch nicht mehr weiter:
  1. Guck dir mal auf Spezial:Einstellungen alle Tabs durch, und notiere dir, wenn dir irgendwas am Herzen liegt, oder wo du eine Weile gebraucht hast, bis es deinen Wünschen entspricht. Welche Helferlein aktiv sein sollen, wurde schon oben notiert.
  2. Irgendwas auffällig, übrigens? Ich wüsste nicht, was.
  • Danach auf Spezial:Einstellungen den Knopf Alle Einstellungen zurücksetzen anklicken, so es noch einen gibt.
  • Wenn dann keine Wirkung, bin ich mit meinem Latein für heute am Ende.

Auf ein neues --PerfektesChaos 21:36, 18. Jan. 2014 (CET)

Alle Einstellungen zurücksetzen gibt es: Spezial:Einstellungen#mw-prefsection-personal, nach ganz unten scrollen, → Alle Standardeinstellungen wiederherstellen (in allen Abschnitten). XenonX3 – (☎ – RIP Lady Whistler) 21:39, 18. Jan. 2014 (CET)

Ich muss mich vor mir selbst schützen. Als Kindersicherung entferne ich solche Knöpfe und Links; und weil auf Spezial:Einstellungen die commons.js keine Wirkung hat, steht das seit Jahren irgendwo in meiner Universal-Browser-Wiki-Anpassung vergraben; finde ich noch nicht mal auf Anhieb. Aber danke für die Info, dass es den Knopf noch gibt. Weil das aber auf einem frischen Zweit-Account unverändert ist, hat das Zurücksetzen von Wheeke-Einstellungen auch keinen Sinn. --PerfektesChaos 12:11, 19. Jan. 2014 (CET)

Zwischenbilanz

Wheeke berichtet von einem massiven Darstellungsproblem; „eine Aufreihung von Text ohne Format und ohne Bilder.“

• Es tritt nur mit Firefox auf.
• Unter Explorer funktioniert es tadellos.
• Firefox wurde de- und neuinstalliert.
  • Damit fallen Cache, Web Storage, FF-preferences als übliche Verdächtige weg.
  • Privates Fenster: Kein Einfluss.
• Zusatz-Software gibt es offenbar kaum.
  • Keine Add-ons, kein NoScript.
  • Damit auch kein Greasemonkey etc.
  • Allerdings auch kein Virenscanner.
• JavaScript
  • War/ist deaktiviert.
  • Alle Gadgets enthakelt.
  • Konsole: Auf den ersten Blick nur relativ normale CSS-Warnungen; keine JS-Fehler gemeldet.
  • Ggf. kritischer CSS-Fehler dazwischen. Noch näher untersuchen.
• Alle Skins.
• Das Problem tritt auch in anderen Sprachen und Projekt-Arten auf.
  • Damit entfallen dewiki-Systemnachrichten.
• Benutzernameldung
  • Problem nur als angemeldeter Benutzer.
  • Als IP offenbar Normalzustand.
    • Genauer: Sobald meine IP auf Login klickt und das Anmeldebild erscheint, ist die Skin verschwunden, eine Anmeldung ist da noch nicht einmal erfolgt.--Wheeke (Diskussion) 17:09, 19. Jan. 2014 (CET)
• Wheeke-Account
  • Auf einem frischen Zweit-Account unverändertes Problem.
  • Damit Wheeke-Account unverdächtig, ohnehin keine common.js/.css usw.
• Netzwerk-Anbindung:
  • https; damit keine Proxy und Knoten
  • Mehrere
  • T-online, privat, keine Kapazitätsgrenzen
• Rechner
  • Laptop
• Zeitpunkt
  • Seit mehreren Tagen.
  • Ggf. seit letztem Donnerstag abend?
• Andere Websites
  • Normal.
• Wiki-Server
  • Wurden über unterschiedliche Provider angesprochen. Lastverteilung.
  • Cache-Server mit beschädigtem Modul, das nur im FF einen Folgefehler auslöst, kann ausgeschlossen werden.
• Andere Benutzer
  • FzW schweigt.
  • FF haben viele angemeldete Wiki-Benutzer. Hätte längst großes Drama geben müssen.
• Schadsoftware
  • Möglich. Aber warum sollte sie zwischen angemeldeten und nicht angemeldeten Wiki-Benutzern unterscheiden?

Arbeitshypothese/n:

• Mit letztem Software-Update Donnerstag abend könnte etwas aufgespielt worden sein, das sich mit einer bestimmten FF-Version unter bestimmten Bedingungen nicht verträgt.
  • wmf10 – Nichts Umwerfendes angekündigt.
• Es gäbe unerwünschte Software auf dem Rechner, die auf irgendwas in der Darstellung von Seiten angemeldeter Wiki-Benutzer in einem FF reagiert.

@ Wheeke: Neue Rückfragen.

• Kann der Zeitpunkt auf vergangenen Donnerstag abend (16. Januar) eingegrenzt werden?
• Genaue Bezeichnung der Firefox-Version (über [Hilfe]→[Über Firefox]))

  FF 26 (auf meinem sehr flügellahmen alten acer extensa 5220 läuft es übrigens doch unter FF 22 [auf Windows XP], wie ich gerade feststelle)

• Betriebssystem des Rechners: Welches, Versionsbezeichnung?

  Windows 8

soweit fürs erste, bis späterWheeke (Diskussion) 13:33, 19. Jan. 2014 (CET)

• Zu den Meldungen aus der Konsole, wie du sie oben schon mal aufgelistet hattest:
  • Die meisten dürften „normal“ sein.
  • Hier kann der Schlüssel liegen.
  • Bitte einmal diese Konsole leeren und unangemeldet die Haupseite angucken. Diese Meldungen kopieren.
  • Konsole leeren.
  • Danach angemeldet die Haupseite angucken.
  • Jetzt aus den Meldungen alle herauslöschen, die als IP auch schon kamen.
  • Gibt es welche, die nur angemeldet erscheinen? Dann diese und nur diese hierher.

    sowas? [HTTP-Access-Protokoll gelöscht 2014-01-19, 21:15] … … …

• Virenscanner:
  • Ganz grundsätzlich sollte jeder Rechner damit ausgestattet sein.
  • Es bewahrt allgemein und beim Surfen vor großen Problemen.
  • Dass aktuell Schadsoftware die Ursache ist, glaube ich eher nicht. Aber es scheint auf deinem Rechner und in deiner Umgebung etwas zu geben, was anders ist als bei allen anderen Benutzern.
  • Beim BSI werden auch kostenlose Software-Möglichkeiten dargestellt (PDF).
  • McAfee findet nix--Wheeke (Diskussion) 17:04, 19. Jan. 2014 (CET)

Schönen Sonntag, trotz alledem --PerfektesChaos 12:11, 19. Jan. 2014 (CET)

Okay bis dahin.

• Schadsoftware können wir per McAfee ausschließen; sehr beruhigend.
• Was du kopiert hattest und ich auskommentiert habe, zeigt, dass du in vernünftiger zeitlicher Folge die ganzen Bildchen heruntergeladen hast; brav im Millisekunden-Takt.
• Sie werden dir aber nicht angezeigt.
• Die Fehlermeldungen-Differenz, die ich meinte, stehen in dieser Fehlermeldungs-Konsole beim blauen Punkt „CSS“.
  • Du kannst dich auch auf „Fehler“ beschränken.
  • Den schwarzen Punkt mit dem „Netz“ lass besser aus; habe ich ja gesehen und ist wunderschön.
  • Beim orangen Punkt „JS“ wäre ein Häkchen bei „Fehler“ nicht schlecht.
• „CSS“ sabbelt eine ganze Menge. Entscheidend ist: Welche Fehlermeldungen kommen angemeldet, die als IP nicht erscheinen? Nur diese helfen bei der Aufklärung.

ich hatte versucht, diese rauszufiltern und hier einzugeben. Nützt das was ? [HTTP-Access-Protokoll + CSS-Warnungen gelöscht 2014-01-19, 21:15]

• Eine Info stehengelassen:
  • 19:36:17.833 POST https://fhr.data.mozilla.com/1.0/submit/metrics/ae3bedb1-7dbb-488e-8b1d-cc6c40e91735 [HTTP/1.1 200 Connection Established 312ms]
    • Die hatte ich auch; bis heute abend. Beim Aufbau jeder Seite bekommt mozilla.com eine „metrics“-Meldung, was du dir so wie schnell anguckst. Von mir aber jetzt nicht mehr. --PerfektesChaos 21:15, 19. Jan. 2014 (CET)

• Stimmt meine Vermutung, dass der Ärger Donnerstag Abend losging?

spätestens, sagen wir mal, ob evt schon Mittwoch, kann ich nicht mehr genau sagen--Wheeke (Diskussion) 19:07, 19. Jan. 2014 (CET)

• Ich habe es auch so verstanden, dass du noch einen alten Rechner mit FF22 hast, bei dem du auf deinem Account ganz normal arbeiten kannst, wie auch mit dem IE, während der FF26 spinnt.
  • Das heißt: Mit deinem Account ist alles okay; aber da waren ohnehin keine großartigen Skripte, die hätten spinnen können.

Wir bekommen das hin --PerfektesChaos 18:00, 19. Jan. 2014 (CET)

Ich habe mir deinen Konsolen-Report durchgelesen und mit meinem verglichen. SNAFU. Nur die üblichen Meckereien; kein Grund zum Totalversagen.

• Eines fiel auf, habe ich stehengelassen: Beim Aufbau jeder Seite bekommt „fhr.data.mozilla.com“ eine „metrics“-Meldung. Das wusste ich auch noch nicht. Bei mir aber auch. Muss ich mal bei Gelegenheit reaktivieren und schaun, was da so übermittelt wird; habe es erstmal ausgeknipst.

Wie nun weiter?

• Wenn kein Werkstatt-Kollege eine geniale Idee hat – ich habe dieses Wochenende keine mehr.
• Firefox 26.0 ist das Aktuellste, was es gibt. Versionswechsel bringt nix. In einigen Wochen gibt es sicher einen 26.1 – dann upgraden und hoffen.
• Am Donnerstag kommt ein neues Mediwiki-Update heraus; vielleicht hat man da unauffällig eine Ungereimtheit beseitigt. Freitag mal probieren.
• Bis dahin mit dem IE weiterarbeiten. Deinstallieren und neuinstallieren wäre vermutlich Zeitverschwendung.
• Die Software ist dermaßen komplex, dass es tausenderlei Möglichkeiten gibt, wo sich was nicht verträgt. Seltsam ist, dass es nur dich trifft. Vielleicht mal vorsichtig Diagnosewerkzeuge auf den Laptop anwenden; aber Festplattenfehler und alles andere wird einem auch so gemeldet. Ich will dich da auch in nichts reinquatschen und zweifle am Erfolg. Betriebssystemfehler warten nicht darauf, dass du dich in einem Wiki anmeldest. Eher hat uns ein MediaWiki-Experimentierkünstler irgendeine neue Errungenschaft aufgezwungen.

Ein paar Tage Browser-Wechsel; dann geht der Kampf weiter --PerfektesChaos 21:15, 19. Jan. 2014 (CET)

@Benutzer:PerfektesChaos: Bist du sicher, dass eine Neuinstallation von Firefox das entfernen würde? Das Profil wird ja in $HOME gespeichert, worauf man für eine Neuinstallation keinen Zugriff braucht. Falls nicht könnte man also noch ein neues Firefox-Profil ausprobieren. --nenntmichruhigip (Diskussion) 11:33, 20. Jan. 2014 (CET)

@nenntmichruhigip: (kein ping da keine Benutzerseite) Ja. Das alte Profil war vielleicht xu3mok47.default oder so. Bei einer korrekten Deinstallation wird dieser Ordner auch gelöscht (so die Windows-Benutzerrechte vorliegen); mitsamt dem darüberliegenden Ordner innerhalb der Anwendungsdaten. Bei einer Neuinstallation entsteht jungfräulich was wie: xv8pkl32.default – Es widerspräche auch den Datenschutzgepflogenheiten, den früheren Ordner wiederzuverwenden; er sollte auch so generiert sein, dass nur der aktuelle Windows-Benutzer Leserechte usw. hat. Nebenbei waren wir auch schon im privaten Modus; der kennt den Cache anderer Profile nicht.

LG --PerfektesChaos 14:15, 20. Jan. 2014 (CET)

Neue Taktik

@Wheeke: Überschlafen; neuer Schlachtplan.

• Ich habe es so verstanden, dass keine Bilder zu sehen sind. Das ist ein auffallender Unterschied. Auch ungewöhnlich, das Layout so zu ruinieren. Muss schon eine sehr massive Ursache haben.
• Hauptseite und dahinter ?debug=true (also //de.wikipedia.org/wiki/Wikipedia:Hauptseite?debug=true) aufrufen.
• Dann Strg+Umschlt+K → Schaltfläche [Inspektor]
  • → zeigt eine Untergliederung <html> = <head></head> + <body>
  • Wir ignorieren <body> und klappen das mal zu. Verwirrt nur.
  • Dafür expandieren: <head>
• Da gibt es eine lange Liste; wir gehen ans Ende.
• Uns interessieren nur die Elemente, die heißen: <link ..... rel="stylesheet"></link>
  • Das allerletzte in der Liste markieren und Entf auf der Tastatur.
  • Die Zeile verschwindet.
  • Wiki-Seite angucken. Veränderung?
  • Wenn plötzlich die Bilder erscheinen: Bingo.
    • Merken, wie das Element unmittelbar dadrüber heißt und wo es steht. Weil, das, was gerade gelöscht wurde, von dem wissen wir nicht mehr, wie das hieß.
  • Keine Veränderung, immer noch keine Bilder? Ein <link rel="stylesheet"></link> höher, nochmal.
• Kein Erfolg? Alles alle? Wieder an das Ende der Liste; genauso nochmal mit <style></style>
• Es sind plötzlich die Bilder erschienen:
  • Hauptseite erneut abrufen, wieder mit ?debug=true
  • Das <link> oder <style> wiederfinden, das soeben zuletzt gelöscht wurde.
  • Rechte Maustaste. Zweites Element im Menü: „Äußeres HTML kopieren“.
  • In kleine Textdatei damit. Müsste etwa so aussehen wie <link href="//bits.wikimedia.org/de.wikipedia.org/load.php?debug=true&
  • Jetzt in der Liste genau dieses und nur dieses Entf – Bilder erscheinen genau in diesem Moment? BingoBingo.
• Wenn das Dings identifiziert ist, dessen Ausschaltung die Situation wesentlich verbessert, dann:
  • Beim <link> ist es ungefährlich.
  • Beim <style> mal draufgucken, ob irgendwas drinsteht, was deine Privatsphäre offenlegt; was immer das sein möge. Glaube ich aber nicht. Falls ja, dann kürzen, wir kommen mit den Resten zurecht.
  • Auf diese Disku kopieren.
  • Ob und was das mir und meinen Werkstattkollegen helfen würde, weiß ich noch nicht; müsste man erstmal wissen worum es sich handelt. Aber aus dem Inhalt und jüngsten Veränderungen am Inhalt lassen sich vielleicht Rückschlüsse ziehen.

We never surrender --PerfektesChaos 14:15, 20. Jan. 2014 (CET)

Vielen Dank, so ein Uhrwerk von innen mildert nicht gerade die Irritation :-(. Es hat sich nichts spürbar verändert. Keine Bilder, keine Rahmen, keine Strukturen sichtbar. Nach wie vor: Überschriften sind hervorgehoben. "Willkommen bei Wipikedia" mittig zentriert. Abschn "Artikel des Tages" steht neben "In den Nachrichten". Ab "Schwesterprojekte" steht alles links in langer Schlange untereinander. Gruß--Wheeke (Diskussion) 11:29, 21. Jan. 2014 (CET)

• Keine Bilder.
  • Das ist mysteriös.
  • Es gibt in jedem Browser irgendwo die Möglichkeit, keine Bilder zu zeigen.
    • Das ist für Benutzer mit Sehbehinderung oder langsamem Netzwerk.
    • Das macht aber keinen Unterschied zwischen angemeldeten und nicht angemeldeten Wiki-Benutzern.
  • Es könnte in irgendeinem Werbeblocker //upload.wikimedia.org/wikipedia/commons/thumb/ ausgefiltert werden.
    • Auch das macht keinen Unterschied zwischen angemeldeten und nicht angemeldeten Wiki-Benutzern.
    • Außerdem sind die Bilder abgerufen worden; steht im (oben gelöschten) HTTP-Log.
  • Sie stehen auch im HTML-Dokument (HTTP-Log).
• FzW schweigt.
• Im Inneren des Uhrwerks.
  • Du hast immerhin schon einen kleinen Einblick bekommen.
    • Das ist der einzige Weg, den ich zur Aufklärung sehe.
    • Es muss etwas geben, was auf angemeldete Wiki-Benutzer reagiert, aber nur auf deinem Laptop.
    • Eigentlich müsste es früher oder später auch andere Benutzer treffen.
  • Dass die ganzen Menüs links außen stehen, ist okay. Wir haben alles herausgeschossen, was sie hübsch auf der Seite anordnet.
    • Aber wenigstens die Bilder müssten zu sehen sein.
• Neuer Anlauf.
  • Wir nehmen mal übersichtlichere Seiten, hier drei zur Auswahl: Bartek-Eiche, Bijela, Rivière aux Brochets.
    • Wieder mit ?debug=true hinter der URL aufrufen.
  • Den Inspektor auskoppeln; die Wiki-Seite nach links (damit der linke Rand möglichst gut zu sehen ist) und den Inspektor nach rechts drüber; auch überlappend.
  • Du bist ganz sicher, dass du alle <link> und <style> wie oben beschrieben eliminiert hattest?
    • Zur Sicherheit nochmal im Schnelldurchgang alle <link> und <style> löschen.
  • Immer noch kein Bild sichtbar?
    • Dann jetzt von oben nach unten alles eliminieren, was im Bereich von <head> bis </head> steht; auch alle script und meta und sontigen link-Kram.
    • Ab und zu in den Artikelbereich gucken: Bild aufgetaucht?
    • Schließlich steht da nur noch ein leeres <head></head>. Den kannst du zurKrönung auch noch weghauen.
    • Jetzt muss da aber ein Bild zu sehen sein.
    • Wenn ja: Prozedur mit neu aufgebauter Seite wiederholen, bis klar ist, welches Element das Bild verschwinden ließ.
    • Wenn nein: So langsam fällt mir nix mehr ein.

Mut und Kraft --PerfektesChaos 20:22, 21. Jan. 2014 (CET)

Bitte verzeiht, dass ich nicht alles gelesen hab, ;-) aber für mich klingt das, als würde bits.wikimedia.org einfach nicht antworten (Adblocker, hosts, Rootkit, DNS-Problem). Habt ihr mal Pings auf bits.wikimedia.org im Vergleich zu de.wikipedia.org probiert? --TMg 00:46, 22. Jan. 2014 (CET)

Problem offenbar gelöst

Habe nochmal beide Systeme gewaltsam durchgecleant (FF und IE). Mit x Reinigungsprogrammen, bis es ging. evtl wars nationzoom, der ist jetzt weg. War eine eine ziemliche Menge entfernter Müll. Wieso hat McAfee das nicht gesehen? Vielen Dank für eure Mühe. Sehr erleichterte Grüße--Wheeke (Diskussion) 09:07, 22. Jan. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: TMg 22:22, 22. Jan. 2014 (CET)

EN-Formatierung

Hallo, wie bitte bekomme ich diesen Link als Einzelnachweis formatiert:

http://194.242.233.158/denqPacelli/index.php?view=sub_layout&subConstraints[byID]=yes&subConstraints[id]=1021

? Gruss --Wistula (Diskussion) 18:39, 9. Jan. 2014 (CET)

du meinst bestimmt die Sonderzeichen zu ersetzen? hier: http://194.242.233.158/denqPacelli/index.php?view=sub_layout&subConstraints%5BbyID%5D=yes&subConstraints%5Bid%5D=1021

siehe Hilfe:Links #Links zu externen Webseiten (Weblinks)#Sonderzeichen in URL und Linktitel --se4598 / ? 19:03, 9. Jan. 2014 (CET)

Prima, herzlich bedankt! --Wistula (Diskussion) 19:21, 9. Jan. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 20:38, 30. Jan. 2014 (CET)

Align Umgebung

Die align bzw. aligned Umgebung in Latex produziert einen Fehler. Siehe beispielsweise den Artikel Lorentz-Transformation, oder folgendes:

${\begin{aligned}x&x\\x&x\end{aligned}}$

Die englische Wipipedia hat das gleiche Problem. --D.H (Diskussion) 10:40, 7. Feb. 2014 (CET)

Dürfte ich dich bitten, das Problem in Hilfe Diskussion:TeX vorzutragen; oder kommst du von dort und wurdest hierher verwiesen?

Info: Es gab gestern beim Aufspielen der regelmäßig jeden Donnerstag aktualisierten MediaWiki-Software ein Problem, das auf die Math-Extension verursacht wurde. Tritt die Beobachtung erst seit gestern/heute bei unveränderten Artikeln auf? Dann mal ein paar Tage abwarten, nix tun.

LG --PerfektesChaos 10:47, 7. Feb. 2014 (CET)

Ja, tritt seit gestern auf. Dann werden wir mal abwarten. --D.H (Diskussion) 11:26, 7. Feb. 2014 (CET)

Die letzte Version von Math auf den Servern hat wohl so einige Probleme, siehe die Liste unter "Depends on:" auf bugzilla:60997. --AKlapper (WMF) (Diskussion) 12:39, 7. Feb. 2014 (CET)

Funktioniert wieder nach Ausführung von "?action=purge" . --D.H (Diskussion) 12:41, 9. Feb. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 13:41, 9. Feb. 2014 (CET)

Benutzerdisk kaputt?

Hallo, meine Benutzerdisk lässt sich nicht mehr bearbeiten. Ich habe es an- und abgemeldet versucht, andere Benutzer (Benutzerin:Itti und Benutzer:Ireas ) haben es ebenfalls erfolglos versucht. Ich kann die Seite nicht bearbeiten, nicht löschen, nicht verschieben, nicht schützen, keine Versionen löschen... hab alles probiert. Antwort ist immer:

Es ist ein Datenbankabfragefehler aufgetreten. Dies könnte auf einen Fehler in der Software hindeuten.
Funktion: WikiPage::updateRevisionOn
Fehler: 1205 Lock wait timeout exceeded; try restarting transaction (10.64.32.28)

Was kann das sein und was kann ich da machen? Gruß--Emergency doc (Disk) 01:26, 11. Feb. 2014 (CET)

in #wikimedia-tech bekomme ich nur folgende Auskunft:

<Reedy> There's a couple of queries after the page dits that take 30 seconds or more

--ireas (Diskussion) 01:36, 11. Feb. 2014 (CET)

Mittlerweile funktioniert es wieder. Grüße, --ireas (Diskussion) 01:41, 11. Feb. 2014 (CET)

Danke :-)--Emergency doc (Disk) 01:45, 11. Feb. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Emergency doc (Disk) 01:45, 11. Feb. 2014 (CET)

Helferlein Rechtschreibung

"Des weiteren", mit "weiteren" klein geschrieben, wird nicht als Rechtschreibfehler angezeigt. Kann man das irgendwie ins Helferlein integrieren? Grüße, -- Doc Taxon @ Disc – ♥ BIBR ♥ – 15:31, 27. Feb. 2014 (CET)

Es gibt Wikipedia:Helferlein/Rechtschreibprüfung, wo Wikipedia:Helferlein/Rechtschreibprüfung/Wortliste verlinkt ist, vielleicht lässt es sich schon darüber abbilden, kann aber nicht sagen, ob auch Wortkombinationen möglich sind. Der Umherirrende 20:30, 27. Feb. 2014 (CET)

ich hab's mal eingetragen ... -- danke, Doc Taxon @ Disc – ♥ BIBR ♥ – 21:15, 27. Feb. 2014 (CET)

Es sind technisch leider nur Prüfungen einzelner Wörter möglich, nicht von Wortkombinationen. --APPER\^☺☹ 21:32, 27. Feb. 2014 (CET)

okay, und damit

Archivierung dieses Abschnittes wurde gewünscht von: Doc Taxon @ Disc – ♥ BIBR ♥ – 16:18, 28. Feb. 2014 (CET)

References

Hi. Werden die References (<ref>) irgendwo in der Datenbank abgelegt? Sind Informationen darüber per API abrufbar? Oder werden die einfach beim Parsen einmal erstellt, in den Quellcode gepackt und dann wars das? Grüße --APPER\^☺☹ 21:52, 10. Mär. 2014 (CET)

Nein, nicht dass mir bekannt wäre oder jemals davon gehört hätte. Das ist ein reiner Parsersache, die nach einem schnellen Blick mit Hilfe von Parserhooks nur <ref>-Elemente aufsammelt und bei Auftreten von <references /> wieder ausspuckt. Kann natürlich sein, dass irgendeine andere Extension das bereitstellt, sicher aber nicht Cite selbst. Weiterer Lesestoff: das kleine Repository und mw:Extension:Cite/Cite.php --se4598 / ? 16:55, 13. Mär. 2014 (CET)

Danke, dachte ich mir fast. --APPER\^☺☹ 17:35, 13. Mär. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: se4598 / ? 23:50, 13. Mär. 2014 (CET)

Link zur Diskussion auch in der "mobilen Ansicht"

Hallo ihr fleißigen, ich wäre sehr für einen Link zur Diskussion eines Artikels, wenn ich diesen gerade auf einem Smartphone sehe - in der "mobilen Ansicht". Beste Grüße, --Meyer-Konstanz (Diskussion) 15:53, 13. Mär. 2014 (CET)

Daran wird gearbeitet. Wenn man auf der mobilen Ansicht eingeloggt ist und dann die "Beta" in den dortigen Einstellungen einschaltet (erreichbar links oben übers Menü; Direktlink), erscheint oben neben dem Edit-Stift auch ein Button zur Disk, jedoch ohne Möglichkeit zur Bearbeitung im Gegensatz zur direkten Ansteuerung der Diskussionsseite. Wenn man jetzt die Einstellungen nochmal besucht, kann man auch den "Experimenteller Modus" aktivieren, wodurch man auf dann auch experimentell wie es aussieht neue Antworten hinzufügen kann. Wie gesagt die "mobile Ansicht" wird beständig von der Wikimedia Foundation weiterentwickelt und wie die Warnhinweise bei den Einstellungen andeuten sind da sicher auch noch einige Fehler enthalten. --se4598 / ? 16:32, 13. Mär. 2014 (CET)

Recht schönen Dank für die schnelle und Hoffnung machende Antwort, Se4598! --Meyer-Konstanz (Diskussion) 16:41, 13. Mär. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: se4598 / ? 23:50, 13. Mär. 2014 (CET)

Zeilenumbruch vor einem Beistrich

Beim Text

„Seit dem 1. April 2004 gilt in Deutschland die DIN EN 12831 (Juni 2003). Danach ist eine fachgerechte Planung mit Heizlast-, Rohrnetz-, und Heizflächenberechnung von einem Planer erforderlich. Aus der Planung ergeben sich Wärmebedarf und Volumenströme.“

(im Artikel Hydraulischer Abgleich) gibt es bei meiner eingestellten Vergrößerung den Zeilenumbruch

„Heizlast-
, Rohrnetz-, und Heizflächenberechnung“

Der fehlerhafte Zeilenumbruch ist mir schon mehrmals aufgefallen. Ist das generell reparierbar? -- Ohrnwuzler (Diskussion) 17:47, 22. Jan. 2014 (CET)

Nicht durch uns. Das ist ein Fehler in der von dir verwendeten Webbrowser-Version. Die meisten Webbrowser machen es richtig. Falls du zusätzlich assistierende Werkzeuge, Plug-ins etc. einsetzt, kann es auch daran liegen, dass der Zeilenumbruch-Algorithmus des Webbrowsers gestört wird. Theoretisch gibt es ein paar Kniffe, mit zusätzlichem HTML 5, CSS oder Unicode-Zeichen Umbrüche an solchen Stellen zu verhindern. Aber das macht erfahrungsgemäß alles nur schlimmer, erst recht wenn es sich um einen älteren Webbrowser handelt. Deshalb ist es vernünftiger, damit zu leben, wenn man zu der immer kleiner werdenden Gruppe von Benutzern gehört, bei denen dieses Problem noch auftritt. --TMg 22:45, 22. Jan. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 20:29, 20. Mär. 2014 (CET)

p-navigation alphabetisch

Hallo! In meiner Navigationsleiste stehen die Links, je nachdem, wie sie dort ein- und ausgeblendet werden, alle durcheinander. Ich hätte sie gern immer automatisch alphabetisch geordnet. Was muss ich dazu wo in meine Benutzer:Doc Taxon/monobook.js einfügen? Schon mal vielen Dank, -- Doc Taxon @ Disc – I ♥ BIBR – 19:05, 15. Feb. 2014 (CET)

Sie müssten an Vorgänger gebunden werden; das ist der letzte Parameter nextnode im Funktionsaufruf.

Problem: Einige der Links habe ich dir Namensraum-sensitiv geschrieben; also müsste erst eine Kette in der gewünschten Reihenfolge kommen, und erst dahinter die NR-spezifischen.

Die Kette müsste an einem konstanten Element verankert werden.

Man kann das sogar so gestalten, dass die Abfolge auch bei Namensraum-sensitiven Elementen einheitlich und alphabetisch ist.

• Dazu in der Liste der var eine Variable seq deklarieren.
• seq bekommt vorab den Wert des letzten konstanten Ankerpunktes.
• Nach jeder Zuweisung eines Links bekommt seq den Namen von dessen ID zugewiesen.
• Das (dynamisch wechselnde) nächstfolgende Link wird hinter "#"+seq angefügt, und weist seinen eigenen Namen wieder seq zu.
• Kann man auch mit zwei Varablen machen; seq2 ist ID des neuen Links, seq die ID des vorangehenden, und in jedem Funktionsaufruf steht als erster Parameter seq2, als letzter "#"+seq, und hinter jedem Funktionsaufruf seq=seq2; seq2="p-nächste-ID"; und dann muss man nicht mehr denken.

Viel Spaß --PerfektesChaos 10:28, 18. Feb. 2014 (CET)

Um das nochmal zu präzisieren: Wenn der letzte Parameter nicht angegeben ist oder dort null wirkt, dann kommt dieses Link als letztes in den Container.

Wenn sie also alphabetisch sichtbar sein sollen und als letzte im Container stehen sollen, dann genügt es auch schon (wie jetzt ähnlich geschrieben), sie in alphabetischer Reihenfolge zu definieren und den letzten Parameter nie anzugeben.

Wenn sie mit irgendwas gemischt und dynamisch stehen sollen, dann müssen die genannten seq in Abhängigkeit von ihren Bezugslinks stehen, wobei diese Bezugslinks je nach Namensraum unterschiedlich heißen können.

Was genau du wann wo sehen möchtest, musst du schon selbst wissen.

HGZH --PerfektesChaos 10:56, 18. Feb. 2014 (CET)

Je nachdem, welcher Namensraum gerade geöffnet ist (und welche Links dann zusätzlich erscheinen) sollen sie immer alphabetisch gelistet sein. So wie Du es oben beschrieben hast, bin ich leider zu JS-unbegabt, das verwirklichen zu können. Dabei brauche ich Deine/Eure Hilfe. -- Doc Taxon @ Disc – ♥ BIBR ♥ – 00:52, 25. Feb. 2014 (CET)

• Ich verstehe nicht, worin die Schwierigkeit liegen soll.
• Die Menüfelder werden doch in genau der Reihenfolge aufgebaut, in der sie eingefordert wurden; es sei denn, es wäre deklariert, dass sie vor einem bestimmten anderen liegen sollen.
• Solange du nur deine eigenen Menüfelder alphabetisch sortiert haben möchtest und die systemseitigen nicht in die Sortierung einbezogen werden sollen, müssen die Funktionsaufrufe also nur in der alphabetischen Reihenfolge angeordnet sein; falls einzelne Menüfelder nicht aktiv werden, erscheinen sie halt nicht. Die Reihenfolge der anderen wird dadurch nicht verändert.
• Beispiel:

if ( nsn >= 0 ) {
   // Geht bei Spezialseiten nicht
   .addPortletLink( "Änderungen an verlinkten Seiten" );
   .addPortletLink( "Anti-Cache" );
}
if ( nsn === 2  ||  nsn === 3 ) {
   .addPortletLink( "Benutzerbeiträge" );
   .addPortletLink( "Benutzerrechte" );
}
.addPortletLink( "Datei hochladen" );
if ( nsn >= 0 ) {
   // Spezialseiten können nicht exportiert werden
   .addPortletLink( "Export" );
   .addPortletLink( "Links auf Seite" );
}
.addPortletLink( "Spezialseiten" );
.addPortletLink( "TNX" );

• Auf einer Spezialseite steht:

  [Datei hochladen] → [Spezialseiten] → [TNX]

• Auf einem Artikel steht:

  [Änderungen an verlinkten Seiten] → [Anti-Cache] → [Datei hochladen] → [Export] → [Links auf Seite] → [Spezialseiten] → [TNX]

• Auf einer Benutzerseite steht:

  [Änderungen an verlinkten Seiten] → [Anti-Cache] → [Benutzerbeiträge] → [Benutzerrechte] → [Datei hochladen] → [Export] → [Links auf Seite] → [Spezialseiten] → [TNX]

VG --PerfektesChaos 10:15, 25. Feb. 2014 (CET)

@PerfektesChaos: ja, die eigens hinzugefügten Links sind geordnet. Aber wie Du schon oben erwähnt hast, sind die systemseitigen dabei, die Links [Hauptseite] [Themenportale] [Von A bis Z] [Zufälliger Artikel]. Die sollen mit alphabetisch geordnet werden - und somit mitten unter den von mir hinzugefügten Links erscheinen. Also nur, wenn's möglich ist und nicht allzu aufwändig. Ich möchte eigentlich nur meine BO so komfortabel wie möglich für mich machen. Die [Export], [TNX] und [Anti-Cache] liegen bei mir im p-personal und nicht in p-navigation, kommen in der Liste also nicht vor. (Zumindest bis jetzt.) Könntest Du mir bitte nebenbei dann auch noch die nsn-Nummern aufschlüsseln? Danke sehr, -- Doc Taxon @ Disc – ♥ BIBR ♥ – 05:26, 26. Feb. 2014 (CET)

• Die einfachere Übung sind die Nummern: Hilfe:Namensräume
• Bei den systemseitigen ist dann anzugeben, vor welchem (hoffentlich konstanten, ist aber in diesem Fall unveränderlich) vorhandenen Element das aufzulisten ist.
  • Beispiel:

    "Links auf Seite" soll immer (wenn keine Spezialseite) vor „Themenportale“ und das heißt "n-topics".

addPortletLink( , , "Links auf Seite", , null, null, "n-topics" );

• Die Bezeichner stehen auf Wikipedia:GUI #Aufbau einer Wiki-Seite (hellblau für p-navigation).

• Dein System ist mir sowieso unverständlich.
  • "Links auf Seite" steht bereits als t-whatlinkshere in der Werkzeugbox, die unter Monobook auch immer aufgeklappt dargestellt ist. (Unter Vector kann sie gelegentlich zugeklappt sein, da würde ich verstehen, dass du sie immer sichtbar haben möchtest).
  • Allgemein gehören die von dir gewünschten Links als seitenabhängig entweder in die (gelbe) Werkzeugbox, oder oben als Seitenbezogene Aktionen (grün). Unter „Navigation“ steht die Gesamt-Projekt-bezogene seitenunabhängige Navigation.
  • "Benutzerbeiträge" gibt es in der Werkzeugbox bereits als t-contributions in den gleichen Situationen; "Datei hochladen" gibt es auch schon in der Werkzeugbox.
• Allerdings ist die Werkzeugbox bislang nicht alphabetisch sortiert.
  • Das kann man aber ändern; mittels Paaren von .detach() + .prepend() in Wikipedia:JS/JQ #Seite verändern.
  • Als Fan der Aufräumfotos von Ursus Wehrli, wie ich auch auf meiner Benutzerseite offenbare, stünde ich auch dafür zur Verfügung.
• Ich hab immer gedacht, Taxonomen wären so Systematiker wie ich.

Sonnigen Frühling --PerfektesChaos 10:29, 26. Feb. 2014 (CET)

Die Werkzeugliste gibt's bei mir in Kürze nicht mehr (wird abgeschaltet), es wird alles hübsch in eine Leiste verräumt. Danke sehr, -- Doc Taxon @ Disc – ♥ BIBR ♥ – 15:29, 27. Feb. 2014 (CET)

@PerfektesChaos: Hallo! Leider noch mal was: Du hast mir doch ein Script zur Verfügung gestellt, womit ich das Löschlogbuch nach Wunsch ausfiltern kann - bei mir mit Linknamen "Logbuch alt." Weil dies wahrscheinlich ganz unten im Script steht, passt er alphabetisch nicht in die Liste (steht immer ganz unten). Der Link "Spezialseiten" bspw. steht oben drüber. [Datei hochladen] - [Spezialseiten] - [Logbuch alt.] , das passt ja nicht. Weil du schriebst, dass es reiche, die Links im js von oben nach unten anzuordnen, hab ich es so auch versucht. Da erfolglos, musste ich es wieder revertieren. Habe es auch mit javascript: und function() probiert, kein Erfolg. Weißt Du was, wie ich diesen Link alphabetisch sauber dazwischen krieg? Vielen Dank, -- Doc Taxon @ Disc – ♥ BIBR ♥ – 09:08, 1. Mär. 2014 (CET)

DocTaxon März 2014 Ich sortiere mal meine Anmerkungen:

• Dazu wäre es erforderlich, dem Aufruf unten eine ID mitzugeben, vor dem eingefügt werden soll; und bei der Création oben eine solche ID zu vereinbaren.
  • Es ist aber ohnehin nicht nötig, zwei verschiedene hook-Funktionen für dasselbe Ereignis („HTML-Dokument ist strukturell aufgebaut und kann jetzt manipuliert werden“) nebeneinander zu verwalten; wird nur unübersichtlich. Ich habe jetzt alles in einer zusammengefasst.
  • Damit ist die vorgenannte Nutzung der ID aber nicht mehr erforderlich, weil ich die Blöcke so arrangiert habe, dass sie in der richtigen Reihenfolge erscheinen.
• Der grüne Block mit den Kommentaren dürfte sich erledigt haben; bei der Gelegenheit eliminiert.
• Die Geschichte mit dem $hist (bzw. in der vorangegangenen Notation) hat dir wohl vor langer Zeit mal jemand aufgeschrieben.
  • Sie ist gleichbedeutend mit der Forderung „keine Spezialseite, normale Inhaltsseite“ und das ist gleichbedeutend mit nsn>=0 und damit an dieser Stelle immer identisch erfüllt.
  • Vielleicht ist dieses Konstrukt schon so ururalt, dass es noch kein wgNamespaceNumber gegeben hatte und man deshalb auf solche Tricks zurückgreifen musste.
  • Zur Übersichtlichkeit und Vereinfachung habe ich das gestrichen.
  • Da war noch eine Weiche drin, die die Beschriftung von „Anti-Cache“ ändert, wenn man nicht auf monobook wäre. Da du per Definition nur auf der monobook wirkst, habe ich auch dies vereinfacht.
• Die Internationalisierung aus deiner enWP habe ich übernommen, so dass die Blöcke mit C&P in beliebige andere Wiki-Projekte gebeamt werden können.
  • Damit dass auch in der mongolischen Wikisource funktioniert, habe ich statt der deutsch lokalisierten die generischen und kanonischen Namen der Spezialseten verwendet.

Nachstehend die umgebaute Geschichte; formal getestet, keine praktische Erfahrung damit.

/* ... Code hier gelöscht ... */

Viel Glück, schönes Wochenende --PerfektesChaos 11:03, 1. Mär. 2014 (CET)

besten Dank, erste praktische Tests erzielten nur positive Ergebnisse. Special thanks auch für die Internationalisierung, das ist sehr hilfreich. -- Schöne Sonntagsgrüße, Doc Taxon @ Disc – ♥ BIBR ♥ – 08:57, 2. Mär. 2014 (CET)

Bitte sehr.

Wobei ich beim Scrollen grad sehe: Spezial:Benutzerrechte hieße zwar Spezial:Userrights – die dir allerdings auf einem anderen Wiki nicht zur Verfügung stünden.

Ökonomischer wäre:

      if ( server === "//de.wikipedia.org" ) {
         mw.util.addPortletLink( "p-navigation",
                                 server + "/wiki/"
                                 + "Spezial:Benutzerrechte/" + title,
                                 "Benutzerrechte" );
      }

Ansonsten kann man das ganze Teil 1:1 in irgendein Wiki kopieren; sollte laufen. Meine common.js ist auch auf ein halbes Dutzend Wikis kopiert. Seit Jahren wird gefordert, globale Benutzerressourcen (d.h. solches JS, CSS und Einstellungen) zu unterstützen.

Gleichfalls sonnigen Sonntag --PerfektesChaos 11:20, 2. Mär. 2014 (CET)

@PerfektesChaos: Seit ein oder zwei Wochen ist auf beta mw:Extension:GlobalCssJs aktiv, die Zeichen stehen nicht also nicht schlecht. Zu globalen Einstellungen: Es gibt von Legoktm globalprefs (verbunden wird über OAuth) mit dem sich in der aktuellen Version immerhin schonmal pauschal auf allen Wikis eine gleiche Interfacesprache einstellen kann. Nützlich, damit man nicht gerade in anderen Schriftsätzen beim ersten Besuch eines solchen Wikis sich blind irgendwie zu den Spracheinstellungen kämpfen muss als unbedarfter User. Grüße und gute Nacht--se4598 / ? 00:29, 5. Mär. 2014 (CET)

@se4598: Danke schön. Klingt spannend.

Habe daraufhin heute morgen die Konzeption eines Gadgets globalUserPreferences.js in meinen geistigen Verdauungstrakt eingeführt.

Heißt konkret: Ich plane auf einer meta:-JS-Seite zunächst etwas mit Zeilen wie

          language = de
          date = dmyt
          echo-email-frequency = 1
          echo-subscriptions-email-reverted = 1
          forceeditsummary = 1
          showhiddencats = 1

zur Initialisierung der preferences in einem erstmalig besuchten Projekt; außerdem auf Sonderwunsch Reset nach jedem Login sowie globale wie auch lokale Startseite nach Login.

Unter Verwendung von preferencesGadgetOptions – leider interaktive Konfiguration über Wiki-Grenzen hinweg wohl nur mittels OAuth abfragbar. Aber auch das scheint mir lösbar; wäre dann auch nicht offen sichtbar.

Schönen Tag --PerfektesChaos 10:00, 5. Mär. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 20:29, 20. Mär. 2014 (CET)

Archivierung

Aus welchem Grund archiviert der Archivbot nicht? Beispiel: Diskussion:Super 8 (Film)(== Achtung Spoiler! ==) -?--J. K. H. Friedgé (Diskussion) 10:42, 3. Mär. 2014 (CET)

Weil keine Autoarchiv-Vorlage auf der Seite eingebunden ist. IW 15:34, 4. Mär. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 20:29, 20. Mär. 2014 (CET)

Seiten laden nicht fertig

Bei mir laden seit heute rund 80% aller Seiten nicht mehr fertig. Irgendwas fehlt immer noch, ohne dass erkennbar wäre, worum es sich handelt. Firefox zeigt nur an, von welcher Domain noch ein Ladevorgang läuft, der ist meistens meta (die site notice?), mal de.wikipedia.org. Geht das noch anderen so? Grüße --h-stt !? 14:55, 7. Mär. 2014 (CET)

Hm, verhält sich bei mir normal. Gruß, IW 17:48, 7. Mär. 2014 (CET)

Bei mir auch keine Probleme. Yellowcard (D.) 18:21, 7. Mär. 2014 (CET)

Danke, ich dachte mir das schon, als mehrere Stunden kein Feedback kam. Grüße --h-stt !? 18:42, 7. Mär. 2014 (CET)

1. Gestern war Software-Update. Kann schon sein, dass das irgendeinen Klemmer verursacht hat.
2. Bei mir (FF) ist alles normal. Auch auf FZW alles ruhig. Kollegen melden ebenfalls Frieden. Scheint ein Einzelschicksal zu sein.
3. Du hast kein Benutzer-JS; noch nicht mal CSS. Das schränkt den Kreis der Verdächtigen ein.
4. Von unseren Gadgets wüsste ich spontan keines, das sich Ressourcen von meta holen will. Sehr seltsam.
5. Die Idee mit irgendeiner notice ist nicht verkehrt; aber dann central wegen Steward-Wahlen oder weltweitem Verbot bezahlten Editierens oder so. Diese central-Leute waren in den vergangenen Jahren berüchtigt dafür, dass sie grottenfalsche kaputte Skripte ungetestet zur Weihnachtszeit weltweit zwangsausgeführt hatten; das ist aber inzwischen besser geworden.
6. Da du ja FF hast, mach bitte mal dort Strg+Umschlt+J und dann in dieser Konsole den Knopf „Netz“ mit dem schwarzen Punkt und experimentier mal mit dem Log oder Fehler oder Warnung herum. Das sollte mit etwas scrollen verraten, wenn eine Ressource nicht richtig geladen werden kann, und welche das ist.
7. Was verwendest du an Blockier-Add-Ons, NoScript, Ad-Blocker?
8. Antworten bitte nicht hier, sondern als Kopie des Abschnitts in der Wikipedia:TW.

Viel Erfolg --PerfektesChaos 21:23, 7. Mär. 2014 (CET)

Danke dir für die Bemühungen. Ich war das WE offline, deshalb antworte ich erst jetzt. Das Problem besteht weiterhin. Das Log der FF-Fehlerkonsole ist für mich wertlos, weil jeder Aufruf einer WP-Seite rund 45 Fehlermeldungen erzeugt! Daraus kann ich nichts ablesen, weil mir unklar ist, was davon wichtig ist. Blocker: Nur ein Flash-Blocker, sonst verwende ich gar nichts. Also nichts, das für die WP von Bedeutung wäre. Grüße --h-stt !? 11:49, 10. Mär. 2014 (CET)

• Und mal ganz dumm gefragt: Gab es inzwischen mal eine Total-Cache-Löschung? [Chronik] → Neueste löschen → Vorsicht mit dem Ankreuzen; nicht zuviel, aber „Cache“ + „Offline-Website-Daten“ behäkeln.
• Es kommt vor, dass Ressourcen unvollständig übertragen wurden, beschädigt im Cache liegen; das würde das Einzelschicksal erklären.
• Eine Ressource auf meta: habe ich inzwischen gefunden: WikiMiniAtlas. Das läuft aber unschuldig.

Nur Mut --PerfektesChaos 21:35, 10. Mär. 2014 (CET)

Also: Inzwischen habe ich alles nur denkbare zurückgesetzt und gelöscht. Und jetzt geht wieder alles. Leider war nicht nicht aufmerksam genug, um sagen zu können, welche Löschungen (und welcher Cache) die Ursache waren. Grüße --h-stt !? 18:10, 14. Mär. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 20:29, 20. Mär. 2014 (CET)

Fehlermeldung beim Bearbeiten einer per RevDelete gelöschten Version

Moin, ich wollte gerade eine versionsgelöschte Version im Artikel Gasthaus Zum schwarzen Adler (Karbach (Unterfranken)) bearbeiten (um mir eine Info aus dem Quelltext zu ziehen, die ich in der darauffolgenden Version entfernt hatte), bekam daraufhin aber nur folgende Fehlermeldung (die mit "Bei den Servern der Wikimedia Foundation sind gerade technische Probleme aufgetreten."):

PHP fatal error in /usr/local/apache/common-local/php-1.23wmf12/includes/EditPage.php line 3249:
Call to a member function preSaveTransform() on a non-object

Der Fehler ist reproduzierbar und taucht bei jedem Versuch auf, die Version zu bearbeiten. Ist das ein bekannter Bug? Danke! XenonX3 – (☎) 13:17, 10. Feb. 2014 (CET)

Nach einem erneuten Versuch kam von NoScript eine Warnung wegen eines mögl. Cross-Site-Scripting-Versuchs. Konsolenauszug:

13:58:54.614 [NoScript InjectionChecker] JavaScript Injection in ///w/index.php?title=Gasthaus_Zum_schwarzen_Adler_(Karbach_(Unterfranken))&oldid=127414039&action=edit
(function anonymous() {
title=Gasthaus_Zum_schwarzen_Adler_(Karbach_(Unterfranken)) /* COMMENT_TERMINATOR */
DUMMY_EXPR
})
13:58:54.616 [NoScript XSS] Eine verdächtige Anfrage wurde bereinigt. Original-URL [https://de.wikipedia.org/w/index.php?title=Gasthaus_Zum_schwarzen_Adler_(Karbach_(Unterfranken))&oldid=127414039&action=edit]
angefordert von [chrome://browser/content/browser.xul]. Bereinigte URL:
[https://de.wikipedia.org/w/index.php?title=Gasthaus_Zum_schwarzen_Adler_%20Karbach_%20Unterfranken%20%20&oldid=127414039&action=edit#5385583050444536634].
13:58:54.694 GET https://de.wikipedia.org/w/index.php [HTTP/1.1 500 Internal Server Error 227ms]
13:58:54.967 Mutations-Ereignisse sollten nicht mehr verwendet werden. Verwenden Sie MutationObserver stattdessen.

Meinungen? XenonX3 – (☎) 14:00, 10. Feb. 2014 (CET)

Ein PHP fatal error wäre in bugzilla zu melden. Da ein Logbuch-Eintrag fehlt, nehme ich mal an, dass die Versionen oversighted wurden. Ist das nur bei dieser einen Version oder auch bei den anderen?

Im betawiki habe ich gerade mal eine Version testweise (mangels Rechten auch nur einfach) versteckt und dann auf den Bearbeiten-Link geklickt. Raus kam zwar kein Fehler, aber die Editbox enthielt keinen Text statt den gelöschten Seiteninhalt.

Kannst du mal auch das Datum nennen, wann das versteckt wurde. Irgendwo meine ich auch was von einem Umzug der oversighteten Version zum normalen RevDel gelesen zu haben. Vielleicht hat das damit zu tun. muss ja heute gewesen sein. Das die Editbox kein Inhalt hat oder sonstwie was komisches anzeit soll auch schon ein alter Bug sein laut einem Dev gerade. --se4598 / ? 22:11, 10. Feb. 2014 (CET)

Erg.: Wo hast du genau auf Bearbeiten geklickt? Derzeitige Seite (war das eine Diff-Ansicht?) und Zielurl wären gut. Ich eröffne dann ein Bugreport (Kannst du natürlich auch machen).--se4598 / ? 22:51, 10. Feb. 2014 (CET)

Der PHP fatal error ist jetzt weg, nur bekommt man beim Aufruf des Bearbeitenlinks eine leere Box angezeigt, auch nicht umbedingt besser. Die Version ist admin-only gelöscht. Ich habe mit gerrit:120858 aber eine Software-Änderung angeregt, die die Sache fixed und der Quelltext der gelöschten Version wird dann auch angezeigt. Der Umherirrende 20:23, 25. Mär. 2014 (CET)

Änderung wurde angenommen, wird dann wohl mit Version 1.23wmf22 hier ankommen. Der Umherirrende 18:36, 7. Apr. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 18:36, 7. Apr. 2014 (CEST)

Problem mit meinem Sichtungszähler

kopiert von hiesiger Disk --PerfektesChaos 23:15, 22. Apr. 2014 (CEST)

Hallo! Mein Sichtungszähler funktioniert offenbar nicht richtig. Egal wie viel ich schon gesichtet habe, er bleibt immer bei 150 nachgesichteten Versionen stehen. Kann mir das bitte einer für mich korrigieren? Oder sagt mir, wie das geht. Vielen Dank! Gruß! --LGB-ler (Diskussion) 22:37, 22. Apr. 2014 (CEST)

Lösung weiß ich auch grad nicht; aber wo und was genau ist bei dir dein „Sichtungszähler“?

VG --PerfektesChaos 23:15, 22. Apr. 2014 (CEST)

Ich vermute, es geht um die Statistik von Benutzer:Hannes_Röst, vielleicht fragst Du auf seiner BD, dort gibt es schon Benutzer_Diskussion:Hannes_Röst#Nochmals_Frage_zur_Sichtertabelle. --Mabschaaf 23:44, 22. Apr. 2014 (CEST)

Hallo! Sorry, dass ich falsch gepostet hatte. Die Antworten könnten hinkommen. Auch die Verlinkung. Ich meine diesen Satz hier: "Dieser Benutzer ist Sichter mit 150 nachgesichteten Versionen." Wenn man auf die Zahl klickt, dann werden alle Sichtungen angezeigt. Nur die Zahl 150 bleibt immer gleich, obwohl es inzwischen mehr als 150 Sichtungen sind. Wie kann man das reparieren? Vielen Dank! Gruß! --LGB-ler (Diskussion) 00:09, 23. Apr. 2014 (CEST)

Die "150" steht auf Benutzer:LGB-ler/Sichterbeiträge, ein Klick dort auf "Versionsgeschichte" zeigt Dir, dass der Bot zuletzt am 7. April aktualisiert hat. Bitte wende Dich für weitere Fragen an den Botbetreiber, er kann Dir am besten helfen.--Mabschaaf 00:16, 23. Apr. 2014 (CEST)

OK! Danke! Gruß! --LGB-ler (Diskussion) 10:06, 23. Apr. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Mabschaaf 10:11, 23. Apr. 2014 (CEST)

Tabellenproblem

Hallo, im Artikel ZX81 möchte ich in der ausklappbaren Tabelle die drei Einträge "Microdigital Eletrônica Ltda. (Brasilien)" zu einem einzigen Block zusammenfassen. Leider funktioniert das nicht. Woran liegt das? Kann das bitte jemand erledigen? Viele Grüße, Knurrikowski (Diskussion) 16:49, 31. Mär. 2014 (CEST)

Ich vermute, du hattest dich mit leeren || am Zeilenende irgendwie selbst geleimt und leere Zellen erzeugt, die dir dann im Weg waren. Syntax gefixt, Design und enzyklopädische Stilfrage des Ausklappens unkommentiert. LG --PerfektesChaos 20:17, 31. Mär. 2014 (CEST)

Nun perfekt! Danke und Grüße, Knurrikowski (Diskussion) 20:52, 31. Mär. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Stiegenaufgang (Diskussion) 13:40, 25. Apr. 2014 (CEST)

Hauptseitenaktualisierung

Könnte mal jemand von Euch auf Wikipedia_Diskussion:Hauptseite#Hauptseitenaktualisierung vorbeischauen und der IP eine Antwort geben - bzw. prüfen, ob es auf unserer Seite ein Problem gibt?--Mabschaaf 17:51, 1. Jan. 2014 (CET)

Eigentlich wär's viel zu schade um das Weltverschwörungs-Geschwafel - aber ehrlich gesagt: Mir ist es als IP in den letzten Wochen erschreckend oft (so auch gerade eben) passiert, dass ich HS (z.T. auch gg. 0:45 Uhr noch) manuell purgen musste; ob die Hamster die Winterruhe suchen? Bu63 (Diskussion) 00:39, 4. Jan. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 10:36, 10. Mai 2014 (CEST)

Auslesen von Personendaten über die API

Liebe Wikipedia,

für ein größeres Projekt würde ich gerne verschiedene personenbezogene Internetdatenbanken miteinander abgleichen. Neben englisch- und deutschsprachiger Wikipedia auch die Deutsche Nationalbibliothek, die Library of Congress und das Virtual International Authority File. Da sich die Wikipedia-API über den jeweiligen Klarnamen ansprechen lässt - also mit jQuery z.B. ungefähr so ...:

$.ajax({
		url: "https://de.wikipedia.org/w/api.php",
		data: { action: "query", titles: 'Albert_Einstein', prop: 'info|extlinks', format: 'json', ellimit: '50', callback: 'callback', indexpageids: 'true' },
		dataType : "jsonp"
	})

... dachte ich mir, fange ich hier an und filtere als erstes die GND-, LCCN-, und VIAF-Identifikationsnummern (im Beispiel die zu Albert Einstein) über die externen links aus. Funktioniert soweit prima. Mit Hilfe dieser Nummern kann ich dann entsprechende XML-Dateien abrufen und nach Geburtsdatum, Geburtsort, usw. auswerten.
Aber wie kriege ich die biographischen (Meta-)Daten aus den Wikipedia-Artikeln? Was ich bräuchte sind die Parameter der Vorlage:Person, wie sie im jeweiligen Artikel eingebunden wird, im Beispiel also das da:

{{Personendaten
|NAME=Einstein, Albert
|ALTERNATIVNAMEN=
|KURZBESCHREIBUNG=deutsch-schweizerischer Physiker und Nobelpreisträger
|GEBURTSDATUM=14. März 1879
|GEBURTSORT=Ulm
|STERBEDATUM=18. April 1955
|STERBEORT=Princeton, New Jersey
}}

Ist das irgend wie möglich? Bislang habe ich es nur geschafft, per script auszulesen, welche Vorlagen auf welcher Seite eingebunden werden, nicht aber mit welchem Quelltext.

Liebe Grüße und Danke im voraus, --Florian Rügamer (Diskussion) 10:39, 13. Feb. 2014 (CET)

Soweit ich weiß geht das nicht, du musst wohl den Artikeltext auswerten. Gruß, IW 18:50, 13. Feb. 2014 (CET)

1. Mit der API warst du schon auf der richtigen Fährte.
   • Auf mw:API:Properties/de #revisions / rv (Versionen) findest du rvprop=content – wie Inkowik richtig schreibt, wäre der Artikeltext auszuwerten.
   • Diese Vorlageneinbindung ist sehr stringent formatiert; du wirst die Parameter in aller Regel hübsch angeordnet finden, ohne schreibtechnische Syntax-Variationen, so dass sie sich problemlos über RegExp abgreifen lassen.
   • Auch die Vorlage:Normdaten ist gut auszuwerten.
2. Kontaktiere Benutzer:APPER.
   • Der hat eine Datenbank aller unserer Personen und ihrer Details einschließlich GND, LCCN und VIAF, und vielleicht fällt ihm eine für dich abfragbare Schnittstelle ein.
   • Im Moment migrieren unsere Tools grad von toolserver.org (nicht mehr robust) nach wmflabs.org (noch nicht robust), was etwas nervig ist.
   • tools:~apper/pd/ → tools:~apper/pd/person/Albert_Einstein GND:118529579, LCCN:n7922889, VIAF:75121530

VG --PerfektesChaos 21:26, 13. Feb. 2014 (CET)

Ja, leider geht die Auswertung nur direkt über den Quelltext. Den kann man natürlich per API holen, wie hier schon erwähnt wurde, ist die Auswertung meist recht einfach. Auf dem Toolserver und neu Tool Labs läuft meine Datenbank halbwegs in Echtzeit, die Daten findet man beispielsweise dort. In einem "PeEnDe"-Format, das dem Rohformat der alten PND entspricht, gibt es die Daten auch ([1]). Ansonsten kann man alle Daten auf einen Schwung als Dump in einem CSV-Format runterladen ([2]). Auf Anfrage kann ich gerne auch ein Query-Format für einzelne Artikel einrichten. --APPER\^☺☹ 21:43, 13. Feb. 2014 (CET)

Die Auswertung von Quelltext per RegExp an sich wäre nicht das Problem, aber ich fürchte, dass wenn neben info und extlinks auch noch revisionen und content (wahrscheinlich ja dann immer der komplette letzte Abschnitt) per ajax nachgeladen werden, die Performance (bei ca. 700 Personen, deren Lebensdaten geprüft werden müssen) ziemlich in die Knie gehen wird. Darum ein ganz, ganz dickes Dankeschön für "PeEnDe"-Format und CSV - das ist genau das, was ich brauche. Super! --Florian Rügamer (Diskussion) 22:12, 13. Feb. 2014 (CET)

Der Dump befindet sich auf Tool Labs unter [3]. --APPER\^☺☹ 22:53, 13. Feb. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 10:36, 10. Mai 2014 (CEST)

Variablen - Werteübergabe an Skripte

Ich habe mich jetzt durch zig Seiten hier gekämpft, aber so ganz habe ich nirgends eine Antwort darauf gefunden, wie denn am besten Variablen hier in der Wikipedia an (auch fremde) Skripte übergeben werden soll. Ich suche eine Möglichkeit einen bis mehrere Werte zu übergeben, die allerdings optional sind. Ich dachte mir daher, dass es vermutlich am besten wäre, die Werte in einem Array zu übergeben. Es besteht zum Nutzen des Skriptes aber keine Verwendungspflicht der Werte. Allerdings soll der Anwender selber entscheiden, was er aus einer fixen Auswahlmöglichkeit auswählt. Seine Auswahl soll er dann in das Array schreiben. Innerhalb des Skriptes soll dann geprüft werden welche Werte vorhanden sind.

Es macht aus meiner Sicht auch keine Sinn mehrere Variablen zu nehmen, weil die Werte nicht auf eine Variable festlegbar sind. Ich müsste dann innerhalb des Skriptes jede Variable durchsuchen lassen nach dem Wert. Daher ein Array.

Es steht dann natürlich das ganz klassische var Variable =["Wert 1", "Wert 2", "Wert 3"]; zur Verfügung. Aber was machen die anderen auf den Seiten angegebene Möglichkeiten? Was ist z.B. mit var Variable1 = new mw.Map(); ? Ist das auch ein Variable/Array, das man für seine Zwecke nutzen kann und wenn ja wo besteht der Unterschied? Ich habe (glaube ich) inzwischen rausgefunden, dass mw.config und mw.user.options wohl nicht geeignet dafür sind, sondern eher als Abfrage und Änderungsmöglichkeit für interne Wikipedia-Einstellungen gedacht ist (?), auch wenn für eine kurze Dauer wohl zumindest auch per mw.user.options eigene Variablen angelegt werden können.

Mich interessiert auch, was die sicherste Variante ist. Das heißt, wo der Benutzer keine schadhaften Inhalte übergeben kann (ich schätze aber mal, dass ich das im Skript überprüfen muss), oder wird das durch irgendwelche MediaWiki-Vorrichtungen verhindert?

Dann noch als letztes: Übergebe ich die Werte am besten als "Wert" oder als Wert , wenn keine Rechenoperationen notwendig sind, sondern nur das Vorhandensein von vordefinierten Wörtern getestet werden soll? --Toru10 (Diskussion) 11:04, 16. Feb. 2014 (CET)

Hm, eine sehr weitgefasste Frage.

• Eine allumfassende Antwort, was denn „am besten“ sei, wird sich kaum geben lassen.
• Es hängt sehr von den Umständen des Einzelfalls und dem beabsichtigten Konzept ab.
• Es hängt auch von der Persönlichkeit der Programmierer ab; von einer schnellen Problemlösung quick&dirty bis zu einer langfristigen, ausbaufähigen, anpassbaren und sogar internationalisierbaren Strategie.

Vielleicht schilderst du am besten ein oder zwei konkrete Beispiele, über die du dir momentan den Kopf zerbrichst.

• Dann wird auch klarer, was „Variable“ und was „Werte“ sind; dafür gibt es viele Situationen.

Insbesondere interessant wäre auch die Frage, wer der von dir erwähnte „Benutzer“ ist:

• Ein anderer Programmierer, der Funktionen aus einer von dir erstellten Skriptbibliothek nutzt?
• Ein Anwender, im Sinne eines normalen Wiki-Benutzers, der ein Hilfsmittel für seine besonderen Zwecke konfigurieren möchte?

LG --PerfektesChaos 12:10, 16. Feb. 2014 (CET)

Explizit geht es natürlich um meinen Anwendungsfall. Es soll sich eher um die reine Einbindung eines Skriptes bei anderen Benutzern handeln, die diese konfigurieren können. Es soll nur zur reinen Aktivierung von Bestandteilen des Erweiterung genutzt werden nichts weiter. Keine Übergabe von integrierbaren Werten für z.B. die Suche nach eingegeben Wörtern in einem Text mittels Skript, sondern nur eine Aktivierung anhand vorgegebener Werten. Auf dein Bsp. bezogen: „Ein Anwender, im Sinne eines normalen Wiki-Benutzers, der ein Hilfsmittel für seine besonderen Zwecke konfigurieren möchte.“

Bsp.: var Bereich = ["Technik","Biologie"]; aktiviert Bestandteile für die Bereiche Technik und Biologie die ein Nutzer nutzen möchte. Alternativ wäre aber auch var Bereich = ["Biologie","Geschichte"]; oder var Bereich = ["Technik", "Biologie","IT", "Wirtschaft"]; möglich. Nicht möglich wäre var Bereich = ["Technik","Hallo"]; weil es für „Hallo“ keine aktivierbaren Bausteine gibt. Hallo erzielt also keinen Effekt. (Und soll auch keinen negativen erzeugen)

Konkret geht es um die Konfigurierung des WikiEditors, der vom Benutzer aktivierbare Auswahllisten anzeigen soll oder eben auch nicht. Will der Benutzer keine Listen für den Bereich IT gibt er ihn auch nicht an. Für diesen Fall suche ich die geeignete Lösung. Einen weiteren Ausbau in Zukunft sehe ich eigentlich nicht vor. Bzw. kann ich mir momentan auch nicht vorstellen, was ich da in Zukunft noch integrieren könnte, dass ich jetzt schon die Möglichkeit integrieren müsste?

Die Werte sollten in die common.js eingegeben werde und dann an das darunter eingebundene Skript übergeben werden. Die Werte müssen also vor dem Aufruf des Skriptes vorhanden sein.

Ich hatte mit Absicht so allgemein gefragt, da mich auch die Anwendungsfälle für die anderen von mir oben angegeben Möglichkeiten interessiert. --Toru10 (Diskussion) 13:21, 16. Feb. 2014 (CET)

• Das oben erwähnte new mw.Map(); ist für deine Situation zu kompliziert.
• Generell gibt es zwei Strategien, wie man solche dynamischen Container entweren kann:
  1. Array
     • Vorteil: sehr einfach für alle Elemente zu durchlaufen: for ( i = 0; i < a.length; i++ ) {
     • Elemente hinzufügen: .push(); neu anlegen: a=[ ];
     • Durchsuchen: Mühsamer; Schleife über alle und jedes vergleichen.
  2. Richtiges Objekt (jedes Array ist auch ein object)
     • Vorteil: Einfacher Zugriff auf das richtige Element, obj.Biologie ist entweder vorhanden oder undefined=nix.
     • Für alle Elemente zu durchlaufen ist nicht viel schwerer:for ( s in obj ) {
     • Neu anlegen: obj={ };
     • Elemente hinzufügen: obj.Biologie=xyz; oder obj[s]=xyz;
     • Das Element ist nicht einfach „nur so da“, wie beim Array, sondern hat einen Wert; vielleicht true oder false oder eine Zeichenkette oder ein Unter-Objekt.
     • Problem: Die Elemente haben keine feste und vorhersagbare Reihenfolge wie bei einem Array. Beim Durchlaufen können sie irgendwie auftauchen; es sind aber alle.
• In deinem Beispiel solltest du möglichst einen internen Speicher haben, in dem du als ein Objekt die Datenstruktur aller deiner Wikieditor-Elemente erstmal nur ablegst.
  • Im Moment hast du lauter Funktionsaufrufe, in dem konkrete Elemente vorgegeben sind.
  • Man nennt das „Trennung von Programm und Daten“.
  • In einem zweiten Schritt würde man dann durch alle aktiven Elemente des internen Speichers durchlaufen.
  • Ob ein Element aktiv ist oder nicht, würde dann davon abhängen, ob …
    • … der momentane Namensraum passt. Im Speicher-Objekt könnte eine Regel stehen, für welche Nummern welcher Namensräume das Element aktiviert werden soll; sonst nicht.
    • … der Anwender ausdrücklich konfiguriert hat, was er haben möchte und was nicht; Opt-In oder Opt-out.
  • Dabei würdest du auch merken, ob die Vorgabe des Anwenders gültig ist oder nicht.
    • Der Weg über ein vom Anwender vorzugebendes Array ist gar nicht schlecht und für ihn einfach und leicht.
    • Du läufst nun durch jedes Element von WillHaben=["Technik","Hallo"].
    • Dann guckst du, ob es bei dir gibt: Speicher[ WillHaben[i] ]
    • Im ersten Fall geht das auf: Speicher["Technik"] existiert und du kannst ein Häkchen dran machen: Speicher[ WillHaben[0] ].zeigen=true;
    • Im zweiten Fall klappt das nicht. Speicher["Hallo"] existiert nicht; und du kannst dem Anwender eine Fehlermeldung geben, das du kein Element "Hallo" kennen würdest.
    • Nachdem du alle Vorbereitungen getroffen hattest, läufst du über alle Elemente von Speicher und zeigst diejenigen, bei denen .zeigen angekreuzt wurde; das heißt es gibt nur einen Funktionsaufruf.
    • Problem: Die Reihenfolge ist beliebig und nicht vorhersehbar. Die Knöpfe erscheinen immer mal wieder anders, das möchte man nicht haben. Eine von mehreren Lösungen wäre eine „verkettete Liste“; das heißt, jedes Element trägt in sich den Namen auf das nächste Element; das letzte vielleicht false und du weißt, welches das allererste ist. Eine andere ginge über ein parallel geführtes Array, so das bei jeder Definition eine Funktion aufgerufen wird: Definiere x unter dem Namen y – und es wird in der Definitions-Funktion gleichzeitig angelegt Speicher[x]=y; (Objekt) und Reihenfolge.push(x); (Array); so dass man für die Anzeige die Elemente von Reihenfolge durchlaufen kann und schauen, was die zugehörigen Objekte Speicher[Reihenfolge[i]]=y; so machen.
• Ich habe ein schlechtes Gedächtnis; aber vor ein paar Tagen hatte ich hier sowas geschrieben: Nach ELP.config.css suchen. Dort steht ein vordefiniertes Objekt dieses Namens. Direkt darunter gibt es ELP.config.css.factory – eine Funktion, die meine Vorgabe mit den möglichen Wünschen der Anwender zusammenrührt. Hie und da wird das dann benutzt; muttu nach config.css suchen. Ein ganz großes Speicher-Objekt steht unter Benutzer:Schnark/js/fliegelflagel.js.

Ich hoffe, damit mehr geholfen als verwirrt zu haben --PerfektesChaos 14:38, 16. Feb. 2014 (CET)

Vielen Dank für die umfangreiche Antwort! :) Du hast mir definitiv mehr geholfen als verwirrt. Ich werde mal versuchen das anzuwenden und mich dann nochmals melden. --Toru10 (Diskussion) 19:27, 16. Feb. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 10:36, 10. Mai 2014 (CEST)

Vorlage:Wahldiagramm/Partei/BE

Hallo zusammen!

Ich habe eben die Vorlage Vorlage:Wahldiagramm/Partei/BE angepasst. Genauer gesagt, den Abschnitt "Deutschsprachige Parteien". Allerdings wird die vorletzte Zeile im Quelltext dieses Abschnitts (|Ecolo = {#switch: {2|}|hell=00B000|dunkel=00B000|link=[[Ecolo]]}) in der Ausgabe nicht angezeigt. Woran liegt das? Weiß wer Rat? Hat jemand eine Lösung? Vielleicht daran, dass die Partei Ecolo bei den französischsprachigen Parteien identisch vorkommt? Grüße und herzlichen Dank, El Bubi (Diskussion) 13:58, 2. Mär. 2014 (CET)

Du musst deine Ergänzung in Vorlage:Wahldiagramm/Partei/Doku/BE vornehmen, damit sie dann auf der Doku-Seite sichtbar ist. Alleine ein Eintrag im Quelltext reicht nicht aus. Der Eintrag im Quelltext ist zwar jetzt doppelt, aber das stört nicht. Wikipedia:Vorlagenwerkstatt wäre wohl die bessere Adresse gewesen. Der Umherirrende 19:40, 25. Mär. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 10:36, 10. Mai 2014 (CEST)

Lesenswert-Markierung in der georgischen Wikipedia

Ich wurde von Wikipedia:FZW hierhin verwiesen. Die Vorlage ka:თარგი:Link GA (unsere Vorlage:Link GA) scheint in der ka.wikipedia nicht zu funktionieren, zumindest sehe ich da bei den lesenswerten bei den Interwikis keine Sternchen. Beispiele: ka:უავატოსა (უისკონსინი), ka:Apple. In unserer Wikipedia:Botschaft sehe ich keinen Ansprechpartner für Georgisch. Kann das jemand fixen? --Gereon K. (Diskussion) 08:55, 20. Mär. 2014 (CET)

1. Ich habe mich noch nie mit den Hintergründen beschäftigt.
2. ka:Template:Link GA enthält erstmal einen Syntaxfehler; HTML-konformst sollte der Schrägstrich am Ende des ersten <span> weg.
3. Homo floresiensis scheint mir ein verständlicher Testfall zu sein, weil bei uns und cs und in ka besternt.
4. Es gibt auch noch eine class= in anderen Sprachversionen; vielleicht wird die für den internationalen Austausch benötigt? Wie funktioniert der?

Soviel für den Anfang --PerfektesChaos 09:54, 20. Mär. 2014 (CET)

• Erstmal durchschaue ich jetzt, dass die Auszeichnung nicht automatisiert international übertragen wird (sollte das nicht eine Wikidata-Funktion bei den Items eintragen, damit man es nur abzurufen braucht?), sondern dass es wohl nach wie vor händisch in jedes einzelne Wiki eingepflegt werden muss (es gab wohl mal IW-Bots, die das international propagiert hatten; aber die sind wegen Wikidata abgeschaltet).
• Wenn ich den Code in ka:MediaWiki:Common.js richtig interpretiere, dann setzen die keine Sternchen, sondern ergänzen den Tooltip. ka:Apple hat für bs he sh eine Auszeichnung definiert.
  • Der Code (function LinkFA mit Objekt listFA) liest sich erstmal nachvollziehbar.
  • Ein inneres var s ist zuviel, und hinsichtlich Semikolon und Klammern sehr sparsam.
  • Müsste man im Detail mal dort herumprobieren und debuggen, was für eine Klitzekleinigkeit falsch ist.
• Das ka:MediaWiki:Common.js wird in einigen Monaten in seiner Gesamtheit Schwierigkeiten bekommen, weil das komplette Wikipedia:Technik/Skin/JS/Obsolet zuschlägt.
• ka:Template:Link GA müsste syntaktisch richtig heißen:

  <span id="interwiki-{{{1}}}-ga"></span>

  Andere Vorlagen desgleichen.

  Hat aber keine Auswirkungen, die leeren Elemente stehen brav im HTML-Dokument. HTML Tidy hat nachgeputzt.

• Im HTML-Dokument wird jedoch die Markierung an den Sprachlinks nicht angebracht, auch keine class hinzugefügt.
• Der Fehler liegt in ka:MediaWiki:Common.js und ist nur durch einen georgischen Admin zu beheben.
• In der Peripherie der russischen Föderation und früheren Sowjetrepubliken werde ich derzeit jedoch nicht tätig; zumndest nicht auf russisch.

LG --PerfektesChaos 11:25, 20. Mär. 2014 (CET)

Der Admin ka:მომხმარებელი:Deu spricht Deutsch. Ich habe ihn mal aus seiner Diskussionsseite darauf angesprochen. Beste Grüße, --Gereon K. (Diskussion) 12:00, 20. Mär. 2014 (CET)

Es könnte auch sein, dass die function LinkFA niemals aufgerufen wird.

• Die Umstände durchschaue ich nicht so ganz.
• Wenn function LinkFA aufgerufen wird, müsste es klappen.

Die ganze Seite ka:MediaWiki:Common.js bedarf einer Totalmodernisierung.

• Das müsste ein georgischer JavaScript-Programmierer mit Admin-Connection machen; so aus der Ferne wird das nichts.
• English is welcome here as well.

Greetings --PerfektesChaos 20:29, 20. Mär. 2014 (CET)

Hallo Freunde! Benutzer:Gereon K. hat mir darauf schon gesagt, ich konnte aber leider das Problem nicht lösen. Andere Admins der KaWiki können es sicher, sie sprechen aber kein Deutsch. Könnten Sie bitte uns helfen und auf meiner Diskussionsseite das Problem auf Englisch erklären, so würden georgische Admins es auch möglichst schnell lösen. Danke sehr.

P. S. Georgien und besonders die georgische Wikipedia ist keine russische Peripherie ;). Deu. 07:56, 23. Mär. 2014 (CET)

Auf ka:MediaWiki Talk:Common.js geschrieben; no russian tanks encountered. --PerfektesChaos 10:45, 23. Mär. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 10:36, 10. Mai 2014 (CEST)

Webabfrage - Ortschaftsdaten

Hallo Zusammen, meine Anfrage wurde bei den allgemeinen Fragen beantwortet, jedoch nicht vollständig und ich wurde hierher verwiesen; Ich möchte von allen Schweizer Ortschaften Name, Meereshöhe und Einwohnerzahl aus der Wikipeda "saugen". Ein netter User hat mir eine Webabfrage gemacht, jedoch fehlen dort die Einwohnerzahlen welche per "Metadatenvorlage" (??) eingesetzt wurden. Weshalb ich nun hier bin. Wie ich die Daten ins Excel zur Verwertung bringe ist mir klar, aber wie ich an die Daten komme ist mir als nicht Programmierbefähigter ein Rätsel :(

Thomas --178.196.29.123 09:03, 31. Mär. 2014 (CEST)

Du müsstest von allen unten angegebenen Dingsdas die Zuordnung zwischen dem Schlüssel der Verwaltungseinheit und der Einwohnerzahl auslesen.

Da ist allerdings auch eine URL auf bfs.admin.ch angegeben; vielleicht wirst du mit dieser Datenquelle irgendwie glücklicher.

Grüezi --PerfektesChaos 20:09, 31. Mär. 2014 (CEST)

• Metadaten Einwohnerzahl CH-AG

Metadaten Einwohnerzahl CH-AI

Metadaten Einwohnerzahl CH-AR

Metadaten Einwohnerzahl CH-BE

Metadaten Einwohnerzahl CH-BL

Metadaten Einwohnerzahl CH-BS

Metadaten Einwohnerzahl CH-FR

Metadaten Einwohnerzahl CH-GE

Metadaten Einwohnerzahl CH-GL

Metadaten Einwohnerzahl CH-GR

Metadaten Einwohnerzahl CH-JU

Metadaten Einwohnerzahl CH-LU

Metadaten Einwohnerzahl CH-NE

Metadaten Einwohnerzahl CH-NW

Metadaten Einwohnerzahl CH-OW

Metadaten Einwohnerzahl CH-SG

Metadaten Einwohnerzahl CH-SH

Metadaten Einwohnerzahl CH-SO

Metadaten Einwohnerzahl CH-SZ

Metadaten Einwohnerzahl CH-TG

Metadaten Einwohnerzahl CH-TI

Metadaten Einwohnerzahl CH-UR

Metadaten Einwohnerzahl CH-VD

Metadaten Einwohnerzahl CH-VS

Metadaten Einwohnerzahl CH-ZG

Metadaten Einwohnerzahl CH-ZH

Ich hab von nem Kollegen auch den Verweis auf admin.ch erhalten, aber da muss ich mir eben Einwohnerzahlen + Ortshöhen zu den Ortschaften zusammenbasteln. Wobei das dann ev osgar einfacher geht als die von dir vorgecshlagene variante... Danke trotzdem! Thomas

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 10:36, 10. Mai 2014 (CEST)

Flaggen vertikal ausrichten

Gibt es einen Grund, warum die Flaggen aus den Vorlagen nicht vertikal zentriert werden (wie in gedruckten Publikationen)? So wie es jetzt erzeugt wird, sieht es mit nachfolgendem Text äußerst unschön aus. Kann man das ändern? Mit SPAN und VALIGN funktioniert es leider nicht. Viele Grüße, Knurrikowski (Diskussion) 16:46, 31. Mär. 2014 (CEST)

Ich kann dir grad nicht folgen; würde aber empfehlen, dass du dich an Wikipedia Diskussion:Ländervorlagen mit Flagge wendest; dort hast du die besten Erfolgsaussichten. Vielleicht mit einer konkreteren Problembeschreibung.

Allgemein können dir Fragen zu Vorlagen und Syntaxproblemen die Kollegen der Nachbarwerkstatt im Zweifelsfall eher beantworten, weil dort mehr mitlesen. Hier kann man das auch, ist aber etwas anders spezialisiert.

LG --PerfektesChaos 20:46, 31. Mär. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 10:36, 10. Mai 2014 (CEST)

Internal error beim Export von Artikeln

Aktuell wird beim Export von Artikeln als xml folgender Text an die eigentlichen Exportdaten angehängt:

<!DOCTYPE html>
<html><head><title>Internal error - Wikipedia</title><style>body { font-family: sans-serif; margin: 0; padding: 0.5em 2em; }</style></head><body>
<div class="errorbox">[b3773c39] 2014-05-16 11:15:47: Fatal exception of type DBUnexpectedError</div>
<!-- Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information. --></body></html>

Das Problem tritt sowohl bei der Abfrage über API wie auch beim Webformular Spezial:Exportieren auf, jedoch nur dann, wenn man alle Versionen exportiert. Der Export an sich scheint korrekt zu funktionieren (wenn man von den genannnten überflüssigen Zeilen absieht, die dann beim nachfolgenden Import Probleme machen, wenn man sie nicht löscht). --Asturius (Diskussion) 13:26, 16. Mai 2014 (CEST)

bugzilla:65212 --se4598 / ? 15:59, 16. Mai 2014 (CEST)

thx. Workaround zumindest unter Linux ist übrigens

sed -i '1,/<\/mediawiki>/!d' "$DATEI"

Oder z.B. auch "head -n-4 kaputter_dump.xml > fixed_dump.xml" ;)--Singlespeedfahrer (Diskussion) 17:52, 16. Mai 2014 (CEST)

Stimmt, einfacher. Gar nicht dran gedacht. Allerdings sollte meine Version auch bei nicht_kaputter_dump.xml funktionieren (indem dort alles unverändert bleibt). --Asturius (Diskussion) 04:37, 22. Mai 2014 (CEST)

bzw. löschen der entsprechenden Zeilen per Hand (ansonsten wird beim Import die letzte Version durch eine vollständige Leerung der Seite ersetzt). --Asturius (Diskussion) 16:10, 16. Mai 2014 (CEST)

„beim Import die letzte Version durch eine vollständige Leerung der Seite ersetzt“ aha, interessant. @Brackenheim, Itti: vielleicht mal beim ImportUpload drauf achten? Bug jetzt unter bugzilla:65100 --se4598 / ? 16:32, 16. Mai 2014 (CEST)

Beim IU hatte ich das noch nicht, nur beim IMP. Viele Grüße --Itti Hab Sonne im Herzen ... 16:34, 16. Mai 2014 (CEST)

Problem tritt bei mir nicht mehr auf. Danke fürs Übertragen zu Bugzilla. --Asturius (Diskussion) 04:37, 22. Mai 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Asturius (Diskussion) 04:37, 22. Mai 2014 (CEST)

Bilderrotation

Hallo, ich möchte gerne die Bilder der Seite Wikipedia:Berlin/Bärenrotation als Miniatur linksbündig neben der Willkommensbotschaft auf der Seite Wikipedia:Berlin angezeigt haben. Ich hatte eine Formatierung über eine Box bisher vergeblich versucht, damit wird mir jedoch nur der Link zum Bild, nicht aber das Bild selbst angezeigt. Hilfe. Viele Grüße, --Ghilt (Diskussion) 01:18, 31. Mai 2014 (CEST)

Habe mich nun durch die Erstellung der Vorlage:Bärenrotation durchgefummelt, Grüße, --Ghilt (Diskussion) 23:45, 1. Jun. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Ghilt (Diskussion) 23:47, 1. Jun. 2014 (CEST)

Bildgröße ändert sich beim Speichern ohne Quelltextänderung

Eventuell kann man sich hier des Problems eher annehmen: Wikipedia:Fragen_zur_Wikipedia#Bildgr.C3.B6.C3.9Fe_.C3.A4ndert_sich_ohne_Quelltext.C3.A4nderung.3F. Kurz: Beim Abspeichern werden die im Artikel eingebundenen Hochformat-Fotos ohne ersichtlichen Grund mit einem Mal kleiner als per hochkant, selbst wenn sie nur als mini eingebunden sind. Problem taucht bei diversen Nutzern seit gestern Abend auf. Artikelbeispiele Lou de Laâge, Ata Demirer. Es reicht bei mir schon, bei Artikeln nur die Vorschau anzusehen, schon da werden die Bilder klein angezeigt. --Paulae 19:44, 30. Mai 2014 (CEST)

Wie schon auf WP:FzW geschrieben. Die Änderung kommt nach einer Bearbeitung oder einen Wikipedia:Purge, weil die Umwandlung von Wikitext in HTML verändert wurde. Ich vermute es handelt sich um Bug 63903 der hier umgesetzt wurde. Es wird also jetzt die Standardbildgröße von 220px auch auf die Höhe eines Bildes angewendet. Vielleicht fällt jemand ein guter Satz für Wikipedia:NEU ein. Habe gerade keine Idee das verständlich zu beschreiben. Der Umherirrende 20:41, 30. Mai 2014 (CEST)

Ich habe diesen "Bug" (die Anführungszeichen sind bewusst gesetzt!) bislang zwar nur schnellüberflogen, ahne daraufhin jedoch Schlimmes. Also werde ich mir am Wochenende das Ganze zunächst mal genauer ansehen, bevor ich hier voreilig "ausraste". Gute Nacht allerseits, --YAAA _NOOO? 00:17, 31. Mai 2014 (CEST)

Wenn das eine "Lösung" dieses "Bugs" sein soll, ist sie eine Katastrophe. Dieses bounding-box Modell um eine gleiche "visuelle Größe" zu erreichen, wobei die Bildbreiten nun wirld hin und her springen ist vom Layout her einfach nur völlig daneben.

Da war kein "Bug" der behoben werden müsste. Denjenigen, die das machen wollen, empfehle ich, sich erstmal mit den Grundlagen Layout und Screendesign zu befassen. --Tsui (Diskussion) 03:24, 31. Mai 2014 (CEST)

Äh, verstehe ich das richtig: Bilder werden nun prinzipiell mit einer Höhe von 220px angezeigt, was früher die Breite war? Ein Hochformat ist nun gewollt genauso hoch wie ein Breitformat? Ist nicht wahr, oder? D.h. wir müssen zukünftig alle Hochformatfotos mit hochkant=1.2 oder so angeben? --Paulae 10:39, 31. Mai 2014 (CEST) PS: hochkant=1 führt zur bisherigen Bildanzeige, ist aber anscheinend auch nur ein zeitweiliger Notbehelf, da das als noch zu behebender Bug angesehen wird. [beliebiges Schimpfwort einsetzen] --Paulae 11:07, 31. Mai 2014 (CEST)

Früher wurden alle Bilder mit einer (Standard-)Breite von 220px generiert, was bei hochkant-Bildern zu einem langen Bild führte. Jetzt wird die Höhe bei solchen Bildern auf 220px gedeckelt (die Breite wird im Verhältnis errechnet). Ob das Sinn macht, kann ich nicht sagen, erscheint aber eher nicht so zu sein.

Also kann ein Bild jetzt als miniatur nur noch maximal 220px breit oder hoch sein, je nachdem welche Seitenkante größer ist. Der Umherirrende 12:34, 31. Mai 2014 (CEST)

… was dazu führen wird (und dazu führen soll), dass wir wieder auf feste Bildgrößen ausweichen, so sagts der Benutzer auf en.wp, der das ganze technisch verbockt hat. Ergo sollen wir jetzt zwangsweise auf ein Verhalten zurückgreifen, gegen das wir seit Jahren aktiv vorgehen („keine festen Bildgrößen außerhalb von Infoboxen“). Es ist ein Witz, das alles. --Paulae 12:48, 31. Mai 2014 (CEST)

Offenbar ist die Bildgröße trotz gleichen Quelltexts nicht überall gleich. In John Quincy Adams bespielsweise ist das letzte Bild (mit dem Präsidentendollar) größer als die Fotos darüber, was ich sehr unschön finde. -- Jerchel 11:02, 1. Jun. 2014 (CEST)

Die Änderung wurde heute nach mit gerrit:136704 zurückgenommen, mit Kommentar "Reverting for further discussion, due to community complaints at https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=611154541#Infobox_Image". Um die alten Bildgrößen zu bekommen, reicht ein Wikipedia:Purge des entsprechenden Artikels. Ich schließe mal hier, da eine Diskussion hier von keinem der Entwickler wahrgenommen wird.

Siehe auch Diskussion (oder wie auch immer man es nennen möchte) unter Wikipedia Diskussion:K#Neues Media-Wiki-Geschenk. Der Umherirrende 16:38, 2. Jun. 2014 (CEST)

(BK) Danke, ist so. Zu meiner Freude wurde dieser gefixte "Bug" inzwischen wieder revertiert, vgl. etwa diesen Beitrag und den Verlauf dieser Diskussion. Jedenfalls wird "mein Sorgenartikel" Ata Demirer nun wieder optisch so dargestellt, wie ich das erwarte (d.h. Bildbreite von 220px, da in der Bildplatzierungszeile lediglich "mini" befohlen ist). Mein besonderer Dank gilt den Kollegen DerHexer und Tsui, die durch ihre Postings in "Bug" 63903 den Revert befördert haben. LG, --YAAA _NOOO? 16:55, 2. Jun. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 16:38, 2. Jun. 2014 (CEST)

Umwandlung von %20 verhindern

Hallo, ich möchte verhindern, dass bereits im Wikitext mit %20 maskierte Leerzeichen nach Verarbeitung durch den Bot in Leerzeichen umgewandelt werden: das soll nicht passieren. Gibt es eine Möglichkeit, das %20 vor dem Absenden so zu escapen, dass es nach dem Speichern wieder als solches existiert? Gruß, IW 16:02, 9. Jun. 2014 (CEST)

Es geht offenbar um eine interne Frage deiner Bot-Programmierung?

• Wer ent-escaped denn „vor dem Absenden“, wer führt „nach dem Speichern“ aus?
• Wer holt sich den Wikitext, auf welche Weise genau, und was macht der Bot mit dem Wikitext?

Mir wäre bekannt, dass unser System eigenmächtig bei der Abfrage der „EL“ nach außen und auf der Weblinksuche Zeichen zusätzlich encoded. Aber was hast du damit zu tun, und das wäre ja auch kein decoding wie im geschilderten Problem?

Sahara. --PerfektesChaos 16:23, 9. Jun. 2014 (CEST)

Hm, ich dachte mir schon, dass der kurze Satz nicht ausreicht :)

• Ich hole mir den Seitentext mit action=query&prop=revisions&rvprop=content, dort steht das in der URL maskierte %20 korrekterweise drin, denn so ist es ja auch im Wikitext eingegeben worden.
• ich möchte den Seitentext unverändert über action=edit zurücksenden
• damit die URL-Parameter funktionieren, escape ich & -> %26; + -> %2B; : -> %3A, der Rest, auch das %20 im Wikitext, bleiben unverändert
• jetzt wird, irgendwo logisch, nicht nur das von mir gewollte %26 wieder zum &, sondern eben auch %20 zum Leerzeichen, obwohl es %20 bleiben soll.
• Mein Ansatz war, das %20 irgendwie so zu maskieren, dass es nicht gemeinsam mit den anderen umgewandelt wird.

Gruß, IW 17:19, 9. Jun. 2014 (CEST)

Vermutlich musst du das %-Zeichen auch codieren (nur bei denen, die du schon im Quellcode bekommst, nicht die, die du selbst bei der Codierung einfügst). Vermutlich (ungetestet) also %2520 statt %20 (also %25 statt Prozentzeichen). --APPER\^☺☹ 17:30, 9. Jun. 2014 (CEST)

Ich hatte es schon mal mit %% probiert ([4]), hat aber nicht geklappt. IW 17:39, 9. Jun. 2014 (CEST)

APPER +1

Um es klarzustellen: Nicht nur %20 muss escaped werden, sondern (vor den & + :) jedes Prozentzeichen.

Deinem Code-Beispiel entnehme ich, dass du mit HTTP-GET arbeitest.

• Das ist für einen ganzen Artikel-content ungewöhnlich; das stößt schnell an Grenzen der URL-Länge.
• Nutze doch HTTP-POST – da ist die ganze Encodiererei automatisch erledigt; ich habe mir da noch nie Gedanken machen müssen. Und die Größe des content ist egal.

Heißßßßß --PerfektesChaos 17:42, 9. Jun. 2014 (CEST)

Ich hab's nochmal mit %25 probiert, das scheint zu klappen, warum auch immer %% dann nicht... danach hatte ich diesen Ansatz schon aufgegeben. Danke für's nochmalige draufstupsen.

action=edit funktioniert ja nur mit POST, von daher muss ich da sowieso ran, aber ohne encoding klappt's bei mir damit auch nicht. Oder meinst du das Holen des Contents? Die Prozentzeichen haben bisher noch nie Probleme gemacht, deshalb fand ich es nicht weiter schlimm, die so zu lassen, wie sie sind. Ist halt so, wenn man sich ein ganzes Framework selbst schreibt, man freut sich, wenn's klappt. Gruß, IW 17:50, 9. Jun. 2014 (CEST)

In welcher Sprache programmierst du denn? --APPER\^☺☹ 17:54, 9. Jun. 2014 (CEST)

PureBasic. Das Framework dazu hier. Gruß, IW 18:43, 9. Jun. 2014 (CEST)

Oha. Mein Chef hätte seine wahre Freude, der ist großer PureBasic-Fan ;). --APPER\^☺☹ 18:46, 9. Jun. 2014 (CEST)

Für die reine Anwendungsprogrammierung ist es perfekt; im Netzwerkbereich stößt PB aber immer wieder an Grenzen, beispielsweise muss man sich die meisten Funktionen für HTTP selbst basteln. Aber es wird ja noch dran entwickelt. Gruß, IW 19:01, 9. Jun. 2014 (CEST)

Danke nochmal für die Rückmeldungen, hier erledigt. IW 19:01, 9. Jun. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: IW 19:01, 9. Jun. 2014 (CEST)

Beobachtungsliste

Hallo Technik-Team! Ist es möglich, mit JavaScript in meiner Beobachtungsliste je Eintrag ein Link dazuzusetzen "Von Beobachtungsliste entfernen" oder "Nicht beobachten"? Ich nutze monobook.js , aber der Skin sollte ja sicherlich egal sein, denke ich mal. Für jegliche Vorschläge besten Dank, -- Doc Taxon @ Disc – ♥ BIBR ♥ – 09:11, 27. Apr. 2014 (CEST)
Wofür soll das gut sein, würde mich interessieren? Gruß --J. K. H. Friedgé (Diskussion) 10:29, 27. Apr. 2014 (CEST)

1. Benutzer:PerfektesChaos/js/listPageOptions leistet exakt das (5.); nebst diversen anderen Features.
2. Beispielsweise, um drei oder sieben Tage nach einem Mini-Edit durchzugucken, was so in den letzten 14 Tagen los war, und überall dort zu entbeobachten, wo einen das Thema eigentlich nicht interessiert, um es für eine dauerhafte Beobachtung zu halten, und man nur wissen wollte, ob jemand auf den Mini-Edit reagieren würde. Mache ich auch regelmäßig nach Wartungsarbeiten.

VG --PerfektesChaos 12:31, 27. Apr. 2014 (CEST)

Dass es so etwas schon gibt, dachte ich mir schon. Funktioniert super! Vielen Dank! -- Doc Taxon @ Disc – ♥ BIBR ♥ – 14:40, 27. Apr. 2014 (CEST)

@Doc Taxon: Bitte sehr; allerdings hast du unten auf Benutzer:Doc Taxon/monobook.js so schöne

if ( mw.libs.DocTaxon.nsn === -1 ) {

– das würde sich auch hier anbieten.

Weil, das allererste, was das Skript nach dem Laden macht, ist genau diese Bedingung zu prüfen und sonst sofort wieder auszusteigen.

Aus demselben Grund steht auch unten auf Benutzer:PerfektesChaos/js/listPageOptions ein Kästchen mit Angaben zu sinnvollen Namensräumen.

VG --PerfektesChaos 23:04, 27. Apr. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 20:31, 13. Jun. 2014 (CEST)

eingebundene Videos: Link auf Quelle in Commons

Derzeit werden eingebundene Bilder und Videos ungleich behandelt: Bei Bildern führt ein Klick auf das Bild den Besucher zur Quellseite auf Commons, wo er Metainformationen (Autor, Quelle etc.) erhält. Bei Videos kann mit einem Klick nur der Abspielvorgang ausgelöst werden, die Quellseite bei Commons wird man ohne spezielles Wissen nicht erreichen. Diese Ungleichbehandlung finde ich nicht einsichtig.

Kann man eine Video-Datei so einbinden, dass ein Klick auf den Bereich außerhalb des Abspielknopfes zu der Quellseite auf Commons leitet? Wenn nicht, könnte man eine solche Funktionalität implementieren?

Ich weiß nicht, wo ich diese Frage am besten platziere. Ich habe sie zuerst hier gestellt; wenn das hier auch nicht der richtige Ort sein sollte: bitte verlagern.

Schöne Grüße, --Mosmas (Diskussion) 12:09, 17. Mai 2014 (CEST)

Hallo, es ist wahrscheinlich, dass durch den neuen Media Viewer bei Klicks auf Bilder zukünftig auch nicht auf die Commonsdarstellung weitergeleitet wird, sondern das Bild im Vollbild angezeigt wird (siehe Kurier). Ich hoffe, dass dieser bald auch Videos unterstützt und den häßlichen Videoplayer ablöst. Grüße sitic (Diskussion) 17:09, 17. Mai 2014 (CEST)

Ich nehme alles zurück - unten rechts in der Ecke des Rahmens ist ja bei Bildern und Videos das klickbare Symbol mit dem Tooltip vergrößern und Informationen zum Bild anzeigen. Das macht genau das, worum es mir geht. Hab ich bisher nie wahrgenommen :o) --Mosmas (Diskussion) 17:49, 17. Mai 2014 (CEST)

Info: Kommendes jQuery-Upgrade (breaking change) von v1.8.3 auf v1.11.x

jQuery wird demnächst von v1.8.3 auf v1.11.x geupgraded. Dabei verschwinden auch einige veraltete jQuery-Funktionen. Siehe Mailinglist-Post für mehr Infos. --se4598 / ? 22:40, 7. Mai 2014 (CEST)

@Se4598: Danke für den Hinweis. - Wer von den hiesigen Javascriptprogrammierern kann mir mal verklickern, was ich als Admin an den drei Seiten ändern müßte:

• eo:MediaWiki:Common.js
• dsb:MediaWiki:Common.js
• hsb:MediaWiki:Common.js

Ich habe zwar vor einigen Tagen etwas angepaßt. Aber wahrscheinlich ist trotzdem noch alter Code in den Seiten verteilt. Oder? --Tlustulimu (Diskussion) 13:40, 8. Mai 2014 (CEST)

• Nur eo durchgesehen.
• Ein Bug in function getTextContent(oNode)
  • return ttextContent
  • ttextContent ist immer undefined
• Was den Rest betrifft:
  • Weitaus überwiegend in DOM programmiert (also recht alt), das wenige jQuery ist ersichtlich nicht betroffen.
• Der breaking change betrifft überwiegend sehr exotische, teils undokumentierte Programmierpraktiken und Spezialparameter.
  • In meinem eigenen Zeugs ist nichts zu ändern; die Funktionalitäten kannte ich auch gar nicht, und sie sind ggf. im Manual seit Jahren als deprecated markiert.
  • Ich kann mich auch an keinen Code erinnern, wo solche Features mal genutzt worden wären, abgesehen von live+die.
• Da wird noch Support für seit MW 1.16 nicht mehr existente Funktionen versucht.
  • Es sollte der Bestand an Benutzerskripten usw. durchsucht werden, ob das irgendwo noch verwendet wird, ggf. dort aktualisiert werden, und ansonsten diese Deklaration zunächst auskommentiert werden, nach einer Weile auch gelöscht. getTextContent() kann nie funktioniert haben; wenn sich niemand beschwert hatte, dann kann das weg.
  • Wenn es tatsächlich mal zu Skriptproblemen kommt, dann ist sowas Ursache für übelst schwer zu findende Knoten, und erschwert die Wartung extrem.

LG --PerfektesChaos 00:41, 9. Mai 2014 (CEST)

Das jqueryMigrate-Skript wurde als debug-Skript eingebaut (kommt übernächste Woche mit 1.24wmf5). Wenn man sich also jetzt Seiten mit debug=true anschaut oder das entsprechende Cookie gesetzt hat, das alle Seiten im Debug-Modus kommen sollen, dann soll sich in der Konsole entsprechende Skripte melden. Aber jqueryMigrate wird wohl nicht alles umfassen, daher keine Ahnung, ob das sinnvoll ist. Der Umherirrende 19:29, 12. Mai 2014 (CEST)

jQueryMigrate wurde nach 1.24wmf4 vorgezogen (gerrit:133084). Der Umherirrende 21:42, 13. Mai 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 17:45, 27. Jun. 2014 (CEST)

Sidebar

Darf ich eure geschätzte Aufmerksamkeit hierauf lenken? Kann man das Helferlein aus der en.wp bitte bitte importieren? Ich weiß ja, viele hier verwenden Monobook, aber ich muss jetzt jedesmal, wenn ich eine andere Sprachversion aufrufen will, mehrere Bildschirmmeter runterscrollen … Schöne Grüße _{•  • hugarheimur} 14:55, 1. Jun. 2014 (CEST)

Möglichkeiten wurden dort aufgezeigt. Der Umherirrende 17:44, 27. Jun. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 17:44, 27. Jun. 2014 (CEST)

Möglicher Weblink-Fehler im Artikel Geflügelproduktion

Wer kann helfen??? Hallo liebe Leute der Technik! Es besteht ein möglicher Weblink-Fehler im Artikel Geflügelproduktion. Zum genannten Weblink besteht keine Verbindung. (Weblink: Westafrikanische Krisen durch Europas Hühnerfleischreste (PDF; 5,1 MB) S. 36, Fleischatlas 2013, Daten und Fakten über Tiere als Nahrungsmittel, BUND)(http://www.bund.net/fileadmin/bundnet/publikationen/landwirtschaft/130108_bund_landwirtschaft_fleischatlas.pdf) Wer kann helfen??? Danke --Goldpremium (Diskussion) 09:26, 14. Jun. 2014 (CEST)

Da wurde das PDF wohl unter dem Link aus dem Netz genommen. Per Suche auf der Seite habe ich http://www.bund.net/fileadmin/bundnet/publikationen/landwirtschaft/140328_bund_landwirtschaft_fleischatlas_2013.pdf gefunden, da ist vorne das Datum anders und hinten eine Jahreszahl dran. Ich kann aber nicht bewerten, ob der Inhalt gleich ist, weil ich den alten Inhalt nicht kenne. Per Spezial:Weblink-Suche/www.bund.net/fileadmin könnte man prüfen, ob auch andere Weblinks in der Wikipedia betroffen sind. Eventuell müsste man Kontakt mit dem Webmaster aufnehmen, um zu fragen, ob die Verlinkungen in Zukunft stabil bleiben. Der Umherirrende 09:35, 14. Jun. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 17:43, 27. Jun. 2014 (CEST)

Dropdownmenü öffnet sich standardmäßig am Ende

Hallo, seltsamerweise öffnet sich das Dropdownmenü für die Sperrbegründungen (und nur dieses, die Lösch- und Schutzmenüs verhalten sich normal) seit einiger Zeit standardmäßig ganz nach unten gescrollt. Markiert ist einfach eine leere Zeile ganz am Ende. Hat sich da in letzter Zeit irgendetwas geändert? Und kann man dieses Verhalten zurücksetzen? Halte ich zwar für unwahrscheinlich, dass es am Browser liegt, aber zur Sicherheit: Firefox 28, Windows 8 x64. Gruß, IW 20:11, 8. Apr. 2014 (CEST)

Wird wohl schon am HTML liegen, sehe da ein <option value="other" selected=""></option>, es fehlt also der Test "Anderer Grund" (oder so ähnlich). Die letzte Bearbeitung der Gründe sieht mir nicht verdächtig aus. Da ich es lokal mit den Standards nachstellen kann, wirds wohl ein Bug sein. Ich habe mal auf gerrit:114066 kommentiert, wenn keine Reaktion kommt, versuche ich mich morgen an einem Fix. War die Auswahl "Andere Gründe" sonst am Ende oder wurde die Reihenfolge gedreht (wenn man davon ausgeht, das der jetztige leere Eintrag der fehlende "Andere Grund"-Eintrag ist)? Der Umherirrende 20:41, 8. Apr. 2014 (CEST)

Ich habe gerade in einem Wikia-Wiki geschaut, dort gibt es im Sperrformular die Auswahl „Andere“ ganz oben, beim Aufklappen erhält sie den Fokus. So war es soweit ich weiß auch hier. Gruß, IW 20:55, 8. Apr. 2014 (CEST)

Okay, habe das noch dazugeschrieben, sehe das aber nicht als so großes Problem an, weil die Auswahl der Sperrdauer den Eintrag auch unten hat und früher auch hatte. Wenn es einheitlich ist, wäre es besser, wobei sich da die Frage stellt ob das oben oder unten sein sollte ;-) Ein DropDown sollte aber besser den ersten vorselektiert haben, anstatt des letzten. Mal schauen. Der Umherirrende 21:03, 8. Apr. 2014 (CEST)

Bitte schnellstmöglich korrigieren, es ist wahnsinnig nervig, dass man für popeligen Vandalismus jetzt immer hochscrollen muss... XenonX3 – (☎) 21:07, 8. Apr. 2014 (CEST)

Ich habe gerade in einem anderen, mit MediaWiki laufenden Wiki, in dem ich adminrechte habe, nachgesehen, und dort ist auch die Begründung "Andere" ganz oben im Dropdownmenü. Mariofan13★^{Sprich mit mir!} 13:43, 9. Apr. 2014 (CEST)

Der Text "Anderer Grund" kommt nächsten Donnerstag mit Version 1.23wmf22 wieder (siehe Software-Änderung unter gerrit:124912). Mit gerrit:125209 habe ich eine Software-Änderung vorgeschlagen, die das Feld "Andere" immer oben einfügt, auch bei der Sperrdauer, da es aus meiner Sicht überall gleich stehen sollte. Mal schauen. Der Umherirrende 19:45, 10. Apr. 2014 (CEST)

Die Software-Änderung wurde angenommen und wird vermutlich mit Version 1.24wmf12 hier aktiv. Der Umherirrende 14:32, 29. Jun. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 14:32, 29. Jun. 2014 (CEST)

Personendaten-Tool von Schnark

Für euch vermutlich ein Kinderspiel, ich sitz hier schon fast eine Stunde dran und krieg es nicht auf die Reihe. Ich hatte früher bei monobook ein Tool, mit dem ich halbautomatisch die PD und Kategorien in neue Artikel einfügen konnte. Hier, bzw. Hier hab ich gesehen, dass es das wohl auch gibt. Aber ich bin überfragt, wo man das eigentlich einfügen muss. Bei commons.js hab ich es versucht, aber dann war da nirgendwo etwas, dass ich benutzen konnte. Was hab ich falsch gemacht. Grüße und Danke schonmal--Ticketautomat 21:31, 10. Feb. 2014 (CET)

Eigentlich müsste in deine MyPage/common.js diese Zeile: importScript('Benutzer:Schnark/js/personendaten.js');. Bei mir wird dann bei der "Personendaten"-Box neben der Überschrift ein Button "Bearbeiten" angezeigt. --nenntmichruhigip (Diskussion) 21:44, 10. Feb. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 20:31, 30. Jun. 2014 (CEST)

doi resolver

the use of doi in references like {{doi|10013/epic.43596.d001}} resolves propperly in german wikipedia but generates in english wikipedia an Error: Bad DOI specified! (nicht signierter Beitrag von Hgrobe (Diskussion | Beiträge))

This is a template issue, but we can discuss it here.

We are prepared to equip our template with a validity check, but that has not been used yet. One issue is to find a future-proof name for the maintenance category, the other is to fix all pages popping up in this maintenance category. Should happen one day.

Thank you for reminding me --PerfektesChaos 11:10, 27. Mai 2014 (CEST)

@Leyo, Mabschaaf: c/o --PerfektesChaos 21:57, 27. Mai 2014 (CEST)

Hgrobe, your sample DOI does not follow Digital Object Identifier#Format. No idea why. --Leyo 22:11, 27. Mai 2014 (CEST)

Yes, someone happened to mistake the code in http://hdl.handle.net/10013/epic.43596.d001 (PDF, saving $30) as a DOI.

The issue is to detect this on template usage.

{{#invoke:URIutil|isDOI|10013/epic.43596.d001}} evaluates to »« (=invalid) but {{#invoke:URIutil|isDOI|10.1063/1.881456}} yields »1063« → doi:10.1063/1.881456 – which was intended within Röntgen.

Greetings --PerfektesChaos 22:35, 27. Mai 2014 (CEST)

thank you - perfect. i did not realize that in handles the 10dot is missing. i wanted to provide an open access version of the text but have now exchanged the link in the lemma by the official doi. Hannes Grobe (Diskussion) 09:57, 31. Mai 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 20:24, 30. Jun. 2014 (CEST)

Lua-Fehlermeldung

Moin, auf diversen Seiten (auch hier) wird gerade die folgende Fehlermeldung am Seitenanfang angezeigt (auf Wikipedia:Löschkandidaten/31. Mai 2014 allerdings erst zwischen dem Kasten mit den Tagen und dem Einleitungskasten): mw.title.lua:289: attempt to index local 'b' (a nil value) Mag das jemand abschalten? Danke! XenonX3 – (☎) 18:57, 31. Mai 2014 (CEST)

War ich; kümmere mich drum. Sorry for inconvenience --PerfektesChaos 19:00, 31. Mai 2014 (CEST)

Alles klar, danke! XenonX3 – (☎) 19:02, 31. Mai 2014 (CEST)

Behelfsmäßig geflickt; richtige Reparatur folgt, wenn ich es verstanden habe. LG --PerfektesChaos 19:12, 31. Mai 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 20:22, 30. Jun. 2014 (CEST)

Helferlein Rechtschreibprüfung

Hallo! Das Helferlein funktioniert ja ganz gut, aber ich würde die Markierungen auch im Bearbeitungsmodus gerne sehen wollen (in der Vorschau). Man kann da bestimmt irgendwas einstellen oder in meine Benutzer:Doc Taxon/monobook.js einflechten. Weiß da jemand was? Danke sehr, -- Doc Taxon @ Disc – ♥ BIBR ♥ – 00:33, 28. Jun. 2014 (CEST)

Das Gadget bietet eine solche Konfigurationsmöglichkeit nicht.

Nebenbei ist es in die Jahre gekommen und müsste dringend in moderner Architektur neu aufgebaut werden; dabei auch deinen Wunsch standardmäßig konfigurativ unterstützend.

Bis dahin:

1. Das Ding bei den Benutzereinstellungen aushakeln.
2. MediaWiki:Gadget-Rechtschreibpruefung.js als Privatkopie anlegen, Benutzer:Doc Taxon/Rechtschreibpruefung.js
   • Dann aus der Privatkopie (Obacht, nicht das Original) ganz zum Schluss den ganzen Block function RP_load() bis zum Seitenende durch die folgende Zeichenkette ersetzen:

     $(spellcheck);

3. Dann an Benutzer:Doc Taxon/monobook.js folgenden Block anhängen:

if ( ! ( mw.libs.DocTaxon.nsn % 2 )   &&
     "|view|edit|submit|".indexOf( mw.config.get( "wgAction" ) ) > 0 ) {
   mw.loader.load("//de.wikipedia.org/w/index.php?title="
                  + "User:Doc_Taxon/Rechtschreibpruefung.js"
                  + "&action=raw&ctype=text/javascript",
                  "text/javascript");
}

Und aus der ersten Zeile zu enfernen das dort zusammenhanglose:

var RPonAllPages = true;

Ungetestet, freihändig, sollte klappen, schönes Wochenende --PerfektesChaos 16:15, 28. Jun. 2014 (CEST)

Nun ja, funktioniert ganz gut. Das zusammenhanglose var RPonAllPages = true; ist ja, damit auf allen Seiten eine Prüfung durchgeführt wird, geht's auch ohne? Aber editiere ich einen neuen Rechtschreibfehler und klick auf Vorschau-Button, wird dieses Wort nicht als fehlerhaft markiert, während bereits vorherig dagewesene Rechtschreibfehler markiert werden. Also ganz funktioniert das noch nicht. Vielen Dank für den ersten Ansatz, -- Doc Taxon @ Disc – ♥ BIBR ♥ – 16:26, 29. Jun. 2014 (CEST)

• Das var RPonAllPages = true; ist obenstehend bereits abgebildet als ! nsn % 2 (was soviel heißt wie: „In allen Namensräumen außer Diskussions- und Spezialseiten.“) und damit erstens redundant und würde auch nicht mehr ausgewertet.
• Dein anderer Wunsch geht grundsätzlich nicht: Die Server-Komponente auf Labs/Tools ruft den letzten auf dem Wiki-Server gespeicherten Stand des Seitenquelltextes ab und durchsucht ihn nach Wörtern auf der Wortliste.
  • Was du im Entwurf in deinem Editor zu stehen hast und als Vorschau siehst, kann der Server auf Labs/Tools nicht wissen und berücksichtigen, weil der Seitenquelltext noch nicht wieder auf dem Server gespeichert ist.
  • Dazu müsstest du mal die NSA fragen, die ist da aktueller informiert.
• Ohnehin müsste neben den diversen kleinen Mängeln des Gadgets auch berücksichtigt werden, dass sich der Text der Seite geändert haben könnte und neue Rechtschreibfehler hinzugekommen sein mögen. Im Moment liefert das wochenlang die gleiche Fehlerliste aus dem Browser-Cache und kommuniziert nicht erneut mit dem Server.

VG --PerfektesChaos 17:07, 29. Jun. 2014 (CEST)

Okay, super - vielen Dank -- Doc Taxon @ Disc – ♥ BIBR ♥ – 19:48, 29. Jun. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Doc Taxon @ Disc – ♥ BIBR ♥ – 17:16, 30. Jun. 2014 (CEST)

Darstellungsprobleme Menü oben rechts

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)

Dankeschön, funktioniert perfekt.--CENNOXX 12:51, 18. Jul. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: CENNOXX 12:51, 18. Jul. 2014 (CEST)

Kollision zwischen MediaViewer und Personendaten-Gadget

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)

Nach mw:Help:Multimedia/Media Viewer#How can I disable Media Viewer for unrelated images? kann man class=noviewer verwenden. Ich habe das mal bei Lesenswert und Exzellent beispielhaft gemacht und es funktioniert. Somit ist die Diskussion um die Ablösung von metadata erstmal nicht notwendig außer das ganze kollidiert mit dem MediaViewer, da aber die Personendaten kein Bild anzeigen, ist das egal. Der Umherirrende 14:36, 22. Jul. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 14:36, 22. Jul. 2014 (CEST)

Wiedervorlagenfunktion über "Notiz"

Hallo, wer kann mir zu dieser Funktion etwas sagen? Alle meine Wiedervorlagen-Notizen sind verschwunden. Das ist eine Katastrophe ;) -- Nicola - Ming Klaaf 20:32, 1. Aug. 2014 (CEST)

Ähm, was für eine Notiz-Funktion ist das? Schnark hat wohl sowas. LG --PerfektesChaos 00:23, 2. Aug. 2014 (CEST)

Ja, ich glaube, die ist das. Danke für den Tipp, ich werde ihn mal ansprechen. Gruß, -- Nicola - Ming Klaaf 11:48, 3. Aug. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 11:05, 9. Aug. 2014 (CEST)

Fehler mit tools.wmflabs.org

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)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 22:03, 15. Aug. 2014 (CEST)

math formatierung

Ich habe Probleme damit die Gleichungen im Artikel Quantenteleportation zu formatieren. Zur Darstellung der Formeln habe ich normalerweise MathJax aktiviert. Dort konnte ich die Formeln wie gewohnt setzen und alles war gut. [5] Leider scheinen die Befehle \vphantom und \begin{align} sowie \quad am Anfang der Formel aber nicht ohne MathJax zu funktionieren, was ich leider erst einen Tag später gemerkt habe. Statt align habe ich dann einen umständlichen workaround mittels Tabelle gebastelt. Das Problem dabei ist, dass der Einzug : am Anfang auch den ganzen Text weiter unten einrückt. Daher habe ich folgende Fragen:

• Ist es möglich \vphantom und die align-Umgebung auch für die "normale" PNG-Darstellung zu implementieren?
• Wie lassen sich Tabellen einrücken. Ist der Effekt von : so gewollt?
• Ist es möglich bei der Bearbeitung mit MathJax einen Warnhinweis zu bekommen, wenn der Code als PNG Parser-Fehler verursacht?
• Gibt es eine Wartungsseite, die Seiten mit Parser-Fehlern bei PNG und MathJax Darstellung auflistet?

Kann jemand helfen? Danke!--Debenben (Diskussion) 14:11, 4. Aug. 2014 (CEST)

Ich habe noch ein wenig herumexperimentiert. Das Problem mit dem Einzug tritt nur auf, wenn man eine Tabelle innerhalb einer Tabelle konstruiert: Benutzer:Debenben/Tabellendemo. Das Einzugproblem konnte ich daher umgehen, indem ich nur eine Tabelle verwendet habe. Insgesamt bleibt die Tabelle aber eine Notlösung.--Debenben (Diskussion) 15:31, 7. Aug. 2014 (CEST)

Jetzt müsste man nur noch die Tabellenrahmen in der mobilen Version wegbekommen.--Debenben (Diskussion) 15:48, 7. Aug. 2014 (CEST)

Schildere das doch bitte (per Kopie) auf Hilfe Diskussion:TeX – dort gucken die für diese Fragestellung routinierteren Beobachter zu. LG --PerfektesChaos 11:06, 9. Aug. 2014 (CEST)

Dort aufgeschlagen, damit hier

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 22:05, 15. Aug. 2014 (CEST)

Benutzer:Verschiedenes/monobook.js (Browser: Firefox 31.0)

Guten Tag allerseits. Von Wikipedia:A/A wurde ich hierhin verwiesen. Ich möchte mit einem individuellen Monobook arbeiten, habe aber zwei Probleme: 1. Möchte ich auf der linken Seite nur den ersten Teil (0.99 & MyPages) und die zwei letzten Teile (von AutoPD bis VANDAL+) angezeigt haben. 2. Sehe ich die Änderungen in der Vorschau, nachher aber trotz Purge nicht mehr. Kann mir bitte jemand helfen? Vielen Dank im Voraus und beste Grüße, Verschiedenes (Diskussion) 20:09, 17. Aug. 2014 (CEST)

Hmmmh; man hätte dich wohl besser zu Benutzer:PDD geschickt, aber vielleicht kennt sich hier auch wer damit aus. Nur Mut --PerfektesChaos 21:03, 17. Aug. 2014 (CEST)

Danke hat sich erledigt. PDD hat mir geholfen. Viele Grüße, Verschiedenes (Diskussion) 15:54, 18. Aug. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Verschiedenes (Diskussion) 15:54, 18. Aug. 2014 (CEST)

Geführte Touren Test

Hallo ihr lieben Technikfreaks, ich habe ein klitzekleines Problem. Auf →Hilfe:Geführte Touren habe ich spaßeshalber mal diesen Test (Beispiel) angeklickt und dann auf weiter und weiter … dann kommt ein Fehler, ich bekomme dort eine Schmalversion der Hilfeseite angezeigt, die sich über die Mitte der Seite zieht und die nicht mehr verschwinden will. Gehe ich dann auf eine andere Seite, also beispielsweise einen anderen geöffneten Tab und aktualisiere diese oder rufe von dort eine andere Seite auf, bekomme ich auch dort ständig (nach ein paar Sekunden) diese Schmalversion eingeblendet, auch im Bearbeitungsmodus, was recht nervig ist, man muss dann erst neben diese angezeigte Seite klicken, um etwas schreiben zu können. Also es wäre nett, wenn das mal jemand abstellen könnte. Anmerkung: Bei sehr breiten Bildschirmen ist oben der Button x zum Schließen sichtbar, aber selbst bei meinem Breitbild konnte ich das beispielsweise nicht durch skrollen (wirkt nur auf den Hintergrund) erreichen es geht nur über 2x Strg und - und dann schließen und alles ist wieder gut. Aber wenn man das nicht weiß, dann … könnte es nervig sein. --Liebe Grüße, Lómelinde Diskussion 13:29, 10. Sep. 2014 (CEST)

@Lómelinde: am Ende der test-Tour wird der Inhalt von Hilfe:Geführte Touren/Guider eingebunden. In vorherigen Versionen der Geführte Touren war die Einbindung nicht so schmal und man konnte eine ganze Hilfe-Seite lesen, deshalb hatte ich dort eine Weiterleitung auf Hilfe:Geführte Touren gesetzt. Ich hab es jetzt durch einen Beschreibungssatz ersetzt. Grüße sitic (Diskussion) 12:30, 11. Sep. 2014 (CEST)

Oh prima, so ist es viel besser, Dankeschön. --Liebe Grüße, Lómelinde Diskussion 12:33, 11. Sep. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Liebe Grüße, Lómelinde Diskussion 13:04, 11. Sep. 2014 (CEST)

Visual Editor Hinweistext aktualisieren

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)

Der Bug steht auf FIXED, ich denke das damit der Text jetzt den Vorstellungen entspricht. Der Umherirrende 21:53, 20. Sep. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:53, 20. Sep. 2014 (CEST)

Bilder werden im IE 6 nicht angezeigt

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. 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! 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)
• float ≠ none (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)

•  Kontra Da MediaWiki bald auch kein JavaScript mehr für IE6 ausliefert (gerrit:152072), würde ich lokal auch keine (weiteren) Workarounds für den IE6 mehr einbauen. Der Umherirrende 17:35, 6. Aug. 2014 (CEST)

Da es keine weiteren Rückmeldungen gibt, setze ich das mal auf erledigt. Der Umherirrende 21:50, 20. Sep. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:50, 20. Sep. 2014 (CEST)

Imagemap funktioniert nicht

Hallo an die Experten! Die im Artikel Commodore Plus/4 von mir eingebundene Imagemap funktioniert nicht - keine Ahnung warum. Kann das bitte jemand zum Laufen bringen? Viele Grüße, Knurrikowski (Diskussion) 12:00, 18. Sep. 2014 (CEST)

Erledigt. Knurrikowski (Diskussion) 12:31, 18. Sep. 2014 (CEST)

Da du das ganze selber lösen konntest, setze ich mal den erledigt-Vermerk, damit es archiviert werden kann. Der Umherirrende 21:38, 20. Sep. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:38, 20. Sep. 2014 (CEST)

Monobook

Kann mir bitte jemand mein monobook so einrichten, dass ich wieder damit arbeiten kann? Ich bin ein völliger Programmier-Laie. Vielen Dank im Voraus. --Schubbay (Diskussion) 23:21, 13. Sep. 2014 (CEST)

Ich fürchte, da ist ohnehin ein Problem? Seit Firefox 32 ist mein seit Jahren perfekt funktionierendes "Monobook-Menü" auf 2 Rechnern verschwunden. monobook.js ist unverändert. Nur dort, wo ich es immer gern abgeschaltet hätte. - auf dem IPHONE - ist es noch da. --Brainswiffer (Disk) 10:30, 15. Sep. 2014 (CEST)

Bitte direkt einen der beiden nachstehenden Benutzer kontaktieren:

1. BD:Schniggendiller #Hilferuf
2. Benutzer:PDD

Viel Erfolg --PerfektesChaos 10:56, 15. Sep. 2014 (CEST)

Könnte ab 25. September aufgrund dieser Software-Änderung wieder funktionieren. Getestet werden kann es auf beta.wmflabs. Der Umherirrende 17:41, 20. Sep. 2014 (CEST)

Sollte jetzt wieder funktionieren. Der Umherirrende 21:37, 25. Sep. 2014 (CEST)

Nein, bei mir leider nicht – was muss ich tun? --Schubbay (Diskussion) 23:36, 25. Sep. 2014 (CEST)

Vielleicht mal aktualisieren? Deine Version ist über zweieinhalb Jahre alt. --Entlinkt (Diskussion) 00:27, 26. Sep. 2014 (CEST)

Danke, der Hinweis war gut. --Schubbay (Diskussion) 10:21, 26. Sep. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Schubbay (Diskussion) 10:21, 26. Sep. 2014 (CEST)

Class zebra vs. Jahrescharts

Hallo! Ich frage mich schon seit Längerem, welchen Sinn die class="Jahrescharts" haben soll?! Soweit ich das verstehe, liefert sie das gleiche Ergebnis wie die class="zebra"; sie ist nirgendwo dokumentiert (scheint mir) und trägt noch dazu einen irreführenden Namen (ich wüsste nicht, wo sie für irgendwelche „Jahrescharts“ verwendet werden sollte). Kann mich jemand darüber aufklären? Grüße, XanonymusX (Diskussion) 12:17, 20. Sep. 2014 (CEST)

Es dürfte keine zentrale Styles für "Jahrescharts" geben. Ich habe aber mal gelesen, das es auch Bestrebungen gibt, die Charts-Infobox einzubauen: Vorlage:Infobox Chartplatzierungen, so dass auf diese Klasse und sonstige reine HTML-Konstrukte in Artikeln verzichtet werden kann, wie weit der Stand der Dinge ist weiß ich nicht. Falls du styles für "Jahrescharts" siehst, wäre ein Beispielartikel praktisch. Der Umherirrende 21:42, 20. Sep. 2014 (CEST)

Wird in vielen Musikalben-Artikeln für die Titelliste gebraucht (zB in Wunder gescheh’n). Hab’s mal mit zebra probiert, das Ergebnis war identisch! Soviel zu irreführender Name.--XanonymusX (Diskussion) 22:31, 20. Sep. 2014 (CEST)

Wenn in jeder zweiten Zeile bgcolor steht, sieht es wie zebra aus, ist es aber nicht. Der Umherirrende 11:01, 21. Sep. 2014 (CEST)

Ah ja! :) Soll heißen, die Klasse ist völlig überflüssig, da wirkungslos, oder?--XanonymusX (Diskussion) 11:13, 21. Sep. 2014 (CEST)

Ja, außer sie wird von Benutzern des entsprechenden Portals/WikiProjekt für eigene Styles genutzt. Sonst wäre mir keine andere Verwendung bekannt. Vermutlich steht sie so in einer Kopiervorlage drin. Der Umherirrende 21:56, 21. Sep. 2014 (CEST)

Keine Ahnung, worum es geht; aber manchmal setzen Leute auch Klassen rein, um die Infos mittels Skript oder Bot auszuwerten. Das sollte man dann aber auch in der Doku angeben. – Einfach entfernen, wenn es verwirrt, und mal hören, wer in ein paar Wochen aufschreit. LG --PerfektesChaos 22:22, 21. Sep. 2014 (CEST)

Gibt es eine Möglichkeit, alle Artikel aufzufinden, in denen diese Pseudoklasse verwendet wird? Vielleicht würde sich dann zeigen, ob sie neben der (offensichtlich falschen) Verwendung bei Tracklisten auch anderweitig in Gebrauch ist.--XanonymusX (Diskussion) 11:02, 22. Sep. 2014 (CEST)

Der Anfang ist vermutlich gefunden. Ohne Sinn und Zweck dahinter. Wie die class sich dann aber weiterverbreiten konnte, ist mir ein Rätsel.--XanonymusX (Diskussion) 11:12, 22. Sep. 2014 (CEST)

Nachdem du auf Spezial:Einstellungen #mw-prefsection-betafeatures die „Neue Suche“ angekreuzt und gespeichert hast, kannst du mit diesem Ausdruck recht zuverlässig alle 322 Verwendungen im ANR finden. Sehen alle musikalisch aus.

Wenn man sowas etwa zur Aktualisierung und Auswertung durch Skript oder Bot reinschreibt, gehört es aber unbedingt in eine dokumentierte zentrale Vorlage.

LG --PerfektesChaos 11:31, 22. Sep. 2014 (CEST)

Ja, ich werd das mal in der Musikredaktion ansprechen. Aber das mit der Suche scheint nicht zu klappen, es werden irgendwie nur Seiten angezeigt, in denen „Jahrescharts“ innerhalb eines refs vorkommt.--XanonymusX (Diskussion) 14:44, 22. Sep. 2014 (CEST)

Grrrr, sorry, muss mir das neue Zeugs erstmal angewöhnen.

HHVM, den du ja aktiviert hast, abschalten, und dann damit in Blöcken zu 100. Mehr Ergebnisse auf einmal macht der Server nicht mit, und mit HHVM streckt er gleich alle viere von sich.

Wir haben auch Dump-Durchsucher-Kollegen, aber mit diesem Cirrus sollte allmählich auch das aktuelle Wiki ohne Download durchsuchbar sein.

Jetzt 343, wirklich mit class=, die ersten stichprobenartig geprüft, erstes Dutzend: Half-Life 2 (Spiel) * Recovery (Album) * Loud * True Blue * Relapse (Album) * I Need a Doctor * Unapologetic * Rated R (Rihanna-Album) * Talk That Talk * Ray Wilson * Hell: The Sequel * 21 (Adele-Album)

LG --PerfektesChaos 21:49, 22. Sep. 2014 (CEST)

Also ich hab die Vorlage mit den Jahrescharts einfach von nem anderen Albumartikel irgendwann vor längerer Zeit übernommen. Z. B. diese Kritikbox Recovery (Album)#Kritiken. Wenn die Box anders darzustellen ist, kann das gern geändert werden. MfG --RiJu90 (Diskussion) 02:56, 23. Sep. 2014 (CEST)

Hat sich also offenbar in alle möglichen Tabellen im Musikbereich verirrt. Benutzer:RiJu90, um’s Darstellen geht’s nicht, die Box ist so in schönster Ordnung – wäre sie aber eben auch ohne die sinnlose Jahrescharts-Angabe. Benutzer:PerfektesChaos, danke, ich frage mich, ob man das komplette Entfernen der Angaben einem Bot anvertrauen kann oder ob wir das händisch (evtl. mit Wartungsliste im Musikbereich) machen müssen. Denn im Sinne der Quelltextvereinfachung sollten sie weg, bevor sie Eingang in Dutzende weiterer Artikel finden.--XanonymusX (Diskussion) 00:10, 24. Sep. 2014 (CEST)

Das bekommt ein Bot hin, ohne Kollateralschaden anzurichten.

Bei der Gelegenheit kann auch ein häufig an derselben Stelle kopiertes id="toc" abserviert werden. Das macht das HTML-Dokument ungültig, weil es das immer schon gibt; es wird mit dem automatischen Inhaltsverzeichnis eingefügt: #toc.

Viel Spaß --PerfektesChaos 00:46, 24. Sep. 2014 (CEST)

Anfrage gestellt, ich hoffe, es passiert was.--XanonymusX (Diskussion) 12:03, 26. Sep. 2014 (CEST)

Also zumindest in meinen Artikeln hab ich das Zeug entfernt. --RiJu90 (Diskussion) 18:15, 26. Sep. 2014 (CEST)

Danke dafür.--XanonymusX (Diskussion) 19:41, 26. Sep. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 22:52, 1. Okt. 2014 (CEST)

Problem mit (Extra) Edit Buttons

Hi, seit gestern Abend werden bei einigen Editbuttons die Tooltips direkt angezeigt (rote Pfeile), bei anderen fehlt die Beschriftung (blauer Pfeil). Jemand eine Idee? --Mabschaaf 11:04, 26. Sep. 2014 (CEST)

Das Gadget verlässt sich auf einige interne Details, auf die es sich nie hätte verlassen sollen, und die sich mal wieder geändert haben: https://git.wikimedia.org/commitdiff/mediawiki%2Fcore.git/285c52039bf4d2f9ba78f07656400dac7ba0fef7 (Und nur falls jemand fragt: Ich habe keine Lust, mich um dieses Gadget zu kümmern). --Schnark 11:09, 26. Sep. 2014 (CEST)

Es gab eine Änderung an der Einbindung von Bildern, somit sollten die verschwundenen Bilder wieder da sein. Das Problem mit den Tooltips kann ich im IE11 und FF32 nicht nachvollziehen. Der Umherirrende 18:42, 28. Sep. 2014 (CEST)

Die überflüssige Anzeige der Tooltips ist inzwischen wieder weg, insofern ist dieses Problem nicht mehr existent. Die große Lücke (blauer Pfeil) stammt übrigens nicht von Bildern, die nicht angezeigt werden würden, dort liegen ein paar griechiche Buchstaben (als Text-Typen), die nicht dargestellt werden.--Mabschaaf 19:24, 28. Sep. 2014 (CEST)

Das dürften dann die von dir selbst definierten Schaltflächen (in deiner monobook.js) sein, die aus mangeln an Bildern nicht richtig dargestellt werden (können). Keine Ahnung, wie das vor der Software-Änderung ausgesehen hat, daher kann ich bei einer Korrektur leider nicht helfen. Der Umherirrende 20:30, 28. Sep. 2014 (CEST)

Durch Umgehung gelöst.--Mabschaaf 11:34, 30. Sep. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Mabschaaf 11:34, 30. Sep. 2014 (CEST)

Suche einen bestimmten tag

→ Verweis auf Wikipedia:Fragen zur Wikipedia#Suche einen bestimmten tag -- U-Bahnfreund_(Disk.)^(Beitr.) 18:25, 20. Okt. 2014 (CEST)

Dort beantwortet. --PerfektesChaos 22:25, 20. Okt. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 22:25, 20. Okt. 2014 (CEST)

Wikipedia:Wiki ViewStats

Hallo Techniker, hat zufällig irgendjemand eine Ahnung wie man dieses Tool wieder zum Leben erwecken könnte. Der Softwarebetreiber ist leider seit dem →31. August inaktiv die Nachfragen auf seiner Diskussionsseite, der Projektdiskussion und auf WP:Fragen zur Wikipedia blieben auch erfolglos. Ich weiß gerade nicht, wo ich da sonst fragen könnte. Es scheint keine Verbindung zur Datenbank zu geben.

Es gibt zwei Versionen

• Version 0 – bringt ein nettes Testbild (Das ist die aktuell verlinkte Version, der Aufrufstatistik links)
• Version 2 – kommt bis zur Statistikanzeige, ist aber seit dem 21. September ohne Aktualisierung

Hat zufällig jemand eine Möglichkeit Hedonil persönlich zu erreichen oder weiß jemand, wann er zurückkommen wird? --Liebe Grüße, Lómelinde Diskussion 13:42, 14. Okt. 2014 (CEST)

Tja, Anfang September, kann später Sommerurlaub sein, Klausuren, neuer Job, neues Weib, was weiß ich.

Andere Programmierer im Stats-Projekt wären mir nicht aufgefallen.

Hedonil war ein Jahr sehr fleißig, braucht auch irgendwann eine Pause.

Hoffen wir das Beste --PerfektesChaos 21:56, 14. Okt. 2014 (CEST)

O.k., es hätte ja sein können, dass sich noch jemand damit auskennt oder Zugriff auf das Projekt hat. Ja hoffen wir, dass er bald mal wieder hereinschaut, denn ich finde diese Statistik eigentlich schöner als die andere Abrufstatistik. --Liebe Grüße, Lómelinde Diskussion 07:09, 15. Okt. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 09:59, 30. Okt. 2014 (CET)

Gruppierung von Tabellenzeilen

Gibt es eine Möglichkeit, Tabellenzeilen in einer Vorlage bei Bedarf zu gruppieren? Konkret geht es mir darum, Wertungsspiegel wie hier in eine Vorlage zu bringen. In dieser Tabelle werden Zeilen mit gleichen Einträgen in der Spalte Preisverleihung zusammengefasst. Kann man irgendwie mit Abfragen o.ä. in einer Vorlage umsetzen, dass bei gleichen Einträgen Zeilen gruppiert werden? MfG Chewbacca2205 21:17, 6. Nov. 2014 (CET)

Du bist zwar etwas in die falsche Werkstatt geraten, aber das macht nichts; die Mitarbeiter dieser Werkstatt kommen zur Not auch mit Vorlagen zurecht wie ihre Kollegen der Wikipedia:VWS.

Zu deiner Frage: Im Prinzip ja.

• Nur – du hast davon nichts.
• Damit eine Vorlage mehrere Zeilen zusammenfassen könnte, müsste sie alle Zeilen sehen; das heißt, die Vorlage müsste sämtliche Zellen der gesamten Tabelle als Parameter übergeben bekommen.
• Und wenn du Schreibarbeit sparen möchtest, dann wird da erst recht nichts draus: Du möchtest ja feststellen, ob in zwei aufeinander folgenden Zeilen der gleiche Wert steht; musst ihn also in jeder Zeile erneut eingeben, damit er mit der Zelle der vorangehenden Zeile verglichen werden kann. Als Mensch hast du es da einfacher: Du merkst ja, dass der inhalt gleich ist, und erhöhst einfach rowspan um 1.

LG --PerfektesChaos 21:40, 6. Nov. 2014 (CET)

OK, sowas hatte ich schon befürchtet. MfG Chewbacca2205 23:43, 7. Nov. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Chewbacca2205 23:43, 7. Nov. 2014 (CET)

CirrusSearch

As a part of the continued deployment of the new search engine we'd like to roll this out for all users about a week and a half from now on Wednesday, November 12th. My thanks to the 2.000 or so beta testers on dewiki who've been trying things out. If you have any problems, please let us know on IRC (^d and manybubbles), Bugzilla (MediaWiki -> CirrusSearch component) or the talkpage on mw.org. Thanks! (if someone has the time to translate this to German so everyone can read I'd be super grateful). ^demon (Diskussion) 16:01, 31. Okt. 2014 (CET)

I have added a preview hint to Wikipedia:NEU, our page about changes to the software. It will be moved up to be an actually change, when someone see that it is live. Der Umherirrende 17:30, 3. Nov. 2014 (CET)

And I on Wikipedia:Technik/Skin/Beta the page about beta options Spezial:Diff/135506917. --Wetterwolke (Diskussion) 10:35, 4. Nov. 2014 (CET)

Now live: gerrit:172766 and WP:NEU. Der Umherirrende 20:44, 12. Nov. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:44, 12. Nov. 2014 (CET)

Helferlein zur Weiterleitung nach Commons fehlerhaft

Hallo, folgendes Gadget: MediaWiki:Gadget-Direct-link-to-Commons.js, laut Beschreibung für das "Überspringen der lokalen Dateibeschreibungsseite, um sofort nach Commons zu kommen" funktioniert bei mir nicht mehr. Auf der Diskussionsseite des Gadgets stand jetzt ein weiterer Beitrag, das Gadget sei defekt. Kann jemand das Gadget mal testen und gegebenenfalls mal schauen wo der Fehler liegt?--CENNOXX 23:02, 15. Nov. 2014 (CET)

Ich würde dir ja gern den Fehler suchen; aber bei mir funktioniert es anstandslos, und ich seh am Code auch nichts was irgendwann irgendwodurch beeinträchtigt wäre.

Allerdings habe ich dieses Medienbetrachtungsdingens wohl nicht aktiviert; wie ist das bei dir?

LG --PerfektesChaos 23:46, 15. Nov. 2014 (CET)

Sowas, ich dachte ich hätte ihn deaktviert, dem war aber nicht so. Deaktiviert, jetzt klappts wieder anstandslos.--CENNOXX 15:48, 19. Nov. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: CENNOXX 15:48, 19. Nov. 2014 (CET)

Login via API - Cookies

Moin, ich habe mein Botframework jüngst auf eine Unicode- und Crossplattform-Variante umgestellt und auch eine neue Funktion für das Senden von POST requests geschrieben. Leider funktioniert mit der neuen Funktion die Anmeldung nicht mehr, da Cookies gleich nach der Anmeldung wieder ablaufen (glaub ich). Beim zweistufigen Anmeldevorgang via API bekomme ich vom Server folgendes zurück:

HTTP/1.1 200 OK
Server: Apache
X-Content-Type-Options: nosniff
Cache-control: private
P3P: CP="This is not a P3P policy! See http://de.wikipedia.org/wiki/Spezial:CentralAutoLogin/P3P for more info."
Set-Cookie: centralauth_User=InkoBot; expires=Mon, 22-Dec-2014 11:50:23 GMT; path=/; domain=.wikipedia.org; httponly
Set-Cookie: centralauth_Token=[...]; expires=Mon, 22-Dec-2014 11:50:23 GMT; path=/; domain=.wikipedia.org; httponly
Set-Cookie: centralauth_Session=[...]; path=/; domain=.wikipedia.org; httponly
Set-Cookie: forceHTTPS=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.wikipedia.org; httponly
Set-Cookie: dewikiUserID=1010950; expires=Mon, 22-Dec-2014 11:50:23 GMT; path=/; httponly
Set-Cookie: dewikiUserName=InkoBot; expires=Mon, 22-Dec-2014 11:50:23 GMT; path=/; httponly
X-Frame-Options: DENY
Vary: Accept-Encoding
Content-Type: text/xml; charset=utf-8
X-Varnish: 1380840752, 357139407, 913531227
Via: 1.1 varnish, 1.1 varnish, 1.1 varnish
Content-Length: 208
Accept-Ranges: bytes
Date: Sat, 22 Nov 2014 11:50:23 GMT
Age: 0
Connection: keep-alive
X-Cache: cp1052 miss (0), amssq48 miss (0), amssq56 frontend miss (0)
X-Analytics: php=zend
Set-Cookie: GeoIP=[...]; Path=/; Domain=.wikipedia.org

Die Anmeldung funktioniert zwar (ich bekomme auch die entsprechende Success-Meldung), aber die gesetzten Cookies laufen direkt wieder ab. Ich habe die Vermutung, dass es mit diesem komischen P3P zu tun hat. Die verlinkte Spezial:CentralAutoLogin/P3P verstehe ich nicht („unnötiger Reifen“?). Liege ich mit meiner Vermutung richtig und kann ich dieses P3P-Problem dann irgendwie beheben? Gruß, IW — 12:59, 22. Nov. 2014 (CET)

Wie genau kommst du darauf, dass die Cookies sofort wieder ablaufen? Laut Header sind diese entweder ewig gültig oder einen Monat. Was bekommst du denn für eine Meldung, wenn du mit den gesendeten Session-Daten Dinge tun willst? --APPER\^☺☹ 13:04, 22. Nov. 2014 (CET)

Ach, ich bin ein Trottel, da steht ja Dezember anstatt November... sorry. Ok, aber die Erkennung meines Logins funktioniert später weiterhin nicht. Das merkwürdige ist, dass mein alter Code, der Funktionen der WinAPI benutzt, weiterhin funktioniert. Im Moment scheitert es bereits beim Beziehen des Edit/CSRF-Tokens. Ich bekomme nur +\ zurück. Das ist der Header meiner Anfrage:

POST /w/api.php HTTP/1.0
User-Agent: [...]
Host: de.wikipedia.org
Accept-Charset: utf-8
Cache-Control: no-cache
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 45
Cookie: dewikiSession=[...]; path=/; domain=.wikipedia.org; HttpOnly;

Gruß, IW — 13:18, 22. Nov. 2014 (CET)

In PHP habe ich das einfachste Einloggen beim Script Benutzer:APPER/MwBot.php genutzt. Vielleicht hilft dir das - hat anscheinend noch gestern Nacht funktioniert. --APPER\^☺☹ 14:23, 22. Nov. 2014 (CET)

Habe den Fehler gefunden: mw:API:Login schweigt sich dazu zwar aus, aber anscheinend muss man wirklich alle Cookies aus dem Anmelde-Request wieder zurücksenden, und nicht nur die Session-ID. Der alte WinAPI-Code hat die empfangenen Cookies selbst gespeichert und beim nächsten Request wieder angefügt. Ich habe mir jetzt einen eigenen Cookie-Handler gebaut und es funktioniert. IW — 16:03, 23. Nov. 2014 (CET)

Wenn du schon die Seite verlinkst: mw:API:Login#Handle cookies: "A successful action=login request will set cookies needed to be considered logged in" ;-) Der Umherirrende 19:47, 26. Nov. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: IW — 16:03, 23. Nov. 2014 (CET)

Probleme mit dem Anmelden

Seit ein paar Wochen habe ich als CTHOE in Wikipedia und Wikimedia Commons und als ADSUBIA in Wikivoyage das Problem, dass ich während der Bearbeitung von Artikeln "rausfliege". Die Wieder-Anmeldung unter dem bekannten und gespeicherten Kennwort ist nicht mehr möglich, sodass ich mir ein temporäres Passwort zusenden lassen muss. Das hat früher immer einwandfrei geklappt. Was ist zu tun? Gruß --Claus Diskussionsseite 12:03, 27. Nov. 2014 (CET)

Hast du irgendwelche Browser-Erweiterungen installiert? -- FriedhelmW (Diskussion) 12:30, 27. Nov. 2014 (CET)

Nicht bewusst. Danke für die schnelle Antwort! Übrigens habe ich das Problem nur mit IE 11, nicht mit Chrome. Am liebsten würde ich den IE neu laden, aber das geht nicht, weil er sagt, ich hätte schon die neueste Version. --Claus Diskussionsseite 13:38, 27. Nov. 2014 (CET)

Probier mal unter Internetoptionen > Datenschutz > Erweitert > Automatische Cookieverarbeitung außer Kraft setzen und alle Cookies annehmen. -- FriedhelmW (Diskussion) 14:50, 27. Nov. 2014 (CET)

Alle Einstellungen vorschriftsmäßig geändert: kein Erfolg. --Claus Diskussionsseite 22:14, 27. Nov. 2014 (CET)

Es scheint zu klappen. Ich melde mich, wenn das Problem als erledigt gekennzeichnet werden kann. Danke für die Hilfe! Gruß --Claus Diskussionsseite 10:24, 28. Nov. 2014 (CET)

Ich bleibe zwar trotz entsprechenden Häkchens nicht angemeldet, sondern muss mich beim Neustart von WP erneut anmelden, halte das Problem aber erst mal für gelöst. --Claus Diskussionsseite 21:44, 28. Nov. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: FriedhelmW (Diskussion) 22:08, 28. Nov. 2014 (CET)

Lesbarkeit?

Hallo Leute, folgendes Problem habe ich (seit einer Augen-OP) in der Seitendarstellung werden die bereits aufgerufenen Items in einem (etwas) dunkleren blau dargestellt. Lässt sich das irgendwo einstellen, oder muss ich dazu ein Zusatzprogramm haben? Ich hätte es gerne in einer anderen Farbe, um die Erkennbarkeit zu verbessern? Es gibt sicher eine fertige Lösung, aber ich habe sie nicht gefunden ;=( Da kann eigentlich nur das "Perfekte Chaos" helfen! J. K. H. Friedgé (Diskussion) 10:17, 25. Nov. 2014 (CET)

Das kannst/musst Du in Deinen Browsereinstellungen selbst ändern. Beim Firefox unter "Einstellungen" > "Inhalt" > "Schriften und Farben" > "Farben" > "Besuchte Links"; in anderen Browsern sicher ähnlich zu finden.--Mabschaaf 10:58, 25. Nov. 2014 (CET)

+1

Du siehst, nicht nur das Perfekte Chaos kann helfen, sondern auch andere.

Gleichwohl hätte ich noch mehr Tricks auf Lager; insbesondere wenn du mit vielen Browsern hantierst und das nicht auf jedem Browser umstellen möchtest; oder wenn du bloß eine Einstellung nur für alle Wikis (aber dafür weltweit) haben möchtest und alle anderen Webseiten aber so bleiben sollen wie bisher.

Wir haben auch ein Projekt Wikipedia:BIENE, in dem solche Tipps nachlesbar sein sollten, ggf. zu ergänzen wären.

LG --PerfektesChaos 11:10, 25. Nov. 2014 (CET)

Die Browsereinstellung bewirkt nichts, da sie durch das CSS überschrieben wird.

Folgendes funktioniert aber: schreibe in deine https://meta.wikimedia.org/wiki/Special:MyPage/global.css

a:visited {
      color: green;
}

(oder eine andere Farbe statt green). -- FriedhelmW (Diskussion) 17:05, 25. Nov. 2014 (CET)

• Danke, FriedhelmW, das ist dann schon ein Griff in meine erweiterte Trickkiste.
• Im Firefox gibt es dabei noch ein Häkchen:

  „Seiten das Verwenden von eigenen statt der oben gewählten Farben erlauben“

  – das muss dann natürlich raus, dann geht das auch nur über die von Mabschaaf beschriebene Firefox-Einstellung.

• Wenn es nicht green sein soll, dann stehen auf Hilfe:Farbtabelle noch ganz viele andere; mit # davor angeben: green ist #008000.

LG --PerfektesChaos 21:24, 25. Nov. 2014 (CET)

Leute, der "Sehbehinderte" dankt Euch für die schnelle Hilfe.Dazu dann noch: wie komme ich, ohne dutzende von Hilfeseiten zu durchwühlen, an solche Information? Ich bin nämlich nicht faul ;=)) und hatte schon gesucht (CSS u.s.w.), und dann frustriert aufgegeben. J. K. H. Friedgé (Diskussion) 23:10, 25. Nov. 2014 (CET)

Schau mal bei SelfHtml. -- FriedhelmW (Diskussion) 08:10, 26. Nov. 2014 (CET)

Zur Frage, wie man sowas findet:

• CSS bietet unendlich viele Möglichkeiten, sich eine Wiki-Seite umzudekorieren.
• Unsere Seiten hier würden explodieren und völlig unlesbar werden, wenn wir jede Variante aufführen würden, die man auch noch aus irgendwelchen Gründen einstellen könnte. Zumindest Wikipedia:CSS kann nur häufige Wünsche vieler Benutzer abdecken, die auch Wiki-spezifisch sind.
• Dein Fragestellung müsste deshalb in den Kontext Wikipedia:BIENE/Farbenfehlsichtigkeit und kann dort gern eingearbeitet werden.
  • Diese Seite ist jedoch hemmungslos veraltet (die dargestellte Differenzansicht gibt es schon seit Jahren nicht mehr) und müsste allgemein aufgefrischt werden. Ich bin sehr überlastet und kann mir das nicht selbst aufbürden, kann allenfalls hinterher dort technische Details präzisieren.
• Eine andere gelegentlich gestellte Frage ist die nach Unterbindung von kleineren Schriftgrößen.
  • Das ist im medizinischen Sinne sicher keine Farbenfehlsichtigkeit; die Eingangsfrage dieses Thread auch nicht.
  • Vielleicht müsste man die Sache anders strukturieren. Ich fange gelegentlich mal an zu denken.

LG --PerfektesChaos 10:10, 26. Nov. 2014 (CET)

@PC: Zu deinem Vorschlag "Im Firefox gibt es dabei noch ein Häkchen...": das ist nicht zu empfehlen, weil man dann "blaue" und "rote" Links nicht mehr unterscheiden kann. -- FriedhelmW (Diskussion) 18:35, 26. Nov. 2014 (CET)

Hallo Leute, nochmals danke, habe mich für die CSS-Lösung entschieden, weil doch die anderen Einstellungen des Browsers annehmbar sind. Und die Gedanken PerfektesChaos, müssten sich viele machen, denn die Aktualität einer großen Zahl von Beiträgen, nicht nur auf den Spezialseiten, ist jämmerlich. Hier müsste sich jeder Autor, der einen Artikel mit "Verfalldatum" schreibt, eine Uhr stellen (Wiedervorlage), um die Aktualisierung durchzuführen. Das kann man eigentlich nicht dem zufälligen Besucher überlassen. ?J. K. H. Friedgé (Diskussion) 16:48, 28. Nov. 2014 (CET)

In Bezug auf die Aktualität hast du völlig Recht. Dies hier ist aber die falsche Baustelle. -- FriedhelmW (Diskussion) 10:05, 29. Nov. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: FriedhelmW (Diskussion) 10:05, 29. Nov. 2014 (CET)

Sommerzeit/Winterzeit

Hallo,

irgendwer scheint mir vor geraumer Zeit vergessen zu haben die Uhr umzustellen. Die Angabe: "Diese Seite wurde zuletzt am 3. Dezember 2014 um 22:35 Uhr geändert" (siehe unten) hinkt der Unterschrift um eine Stunde nach. lG Hasso Süßelmann (Diskussion) 23:35, 3. Dez. 2014 (CET)

Bei mir stimmt’s.--XanonymusX (Diskussion) 23:55, 3. Dez. 2014 (CET)

Dann liegt es wohl an meinem Computer. Bei mir steht jedenfalls über der Abrufstatistik: "Diese Seite wurde zuletzt am 3. Dezember 2014 um 22:55 Uhr geändert". Hasso Süßelmann (Diskussion) 00:02, 4. Dez. 2014 (CET)

Guck mal unter Spezial:Einstellungen#mw-prefsection-rendering nach. --Leyo 00:20, 4. Dez. 2014 (CET)

Dankeschön! Problem gelöst.Hasso Süßelmann (Diskussion) 00:23, 4. Dez. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 00:34, 4. Dez. 2014 (CET)

MediaWiki Speicherort unter XAMPP

Hallo, ich hoffe ich bin hier richtig, aber es war die einzige Seite, die einigermaßen auf die Beschreibung passte. Ich habe die MediaWiki Software mithilfe von XAMPP auf meinem Rechner installiert und anschließend diese Anleitung gefunden. Ich hab es auch genauso gemacht. Ich müsste allerdings für ein weiterführendes Projekt wissen, wo die Seiten, und die Eigenschaften für die Seiten (Schutz etc.) gespeichert sind (also den Pfad auf dem PC). Falls euch das weiterhilft: Ich habe Win7 und XAMPP befindet sich unter (C:\Program Files (x86)\XAMPP, das Mediawiki unter C:\Program Files (x86)\XAMPP\apps\mediawiki). Ich freue mich über jede Antwort, denn ich komme überhaupt nicht weiter, und im Internet habe ich auch nichts gefunden... LG, Luke081515 Aufgabe für mich? Sprich mich an! 21:21, 7. Dez. 2014 (CET)

Dass MediaWiki auf einer Datenbank basiert, weißt du aber? Die Seiten sind nirgendwo einfach so „gespeichert“, sondern in der Datenbank abgelegt. Ich würde diese unter \XAMPP\mysql\data vermuten, kann aber auch falsch liegen. Gruß, IW — 21:42, 7. Dez. 2014 (CET)

Wenn du ein "XAMPP Control Panel" hast, wodrüber die Server gestartet werde, klicke mal bei "mysql" auf "Admin", dann landest du in der Datenbanksoftware (oder rufe http://localhost/phpmyadmin auf, sofern dein Wiki auf deinem Rechner läuft), dort dann deine angelegte Datenbank auswählen. In der Tabelle "text" stehen dann die eigentlichen Texte. Je nachdem was du vor hast, kann es auch besser sein, die mw:API deines Wikis zu nutzen oder Spezial:Exportieren oder ein Backup-Skript oder … Der Umherirrende 21:58, 7. Dez. 2014 (CET)

In dem Fall ist exportieren schlecht, denn ich wollte mithilfe von Synchronisierungsprogrammen und einer Cloud das Wiki auf der Cloud speichern, so das jeder Benutzer eine Kopie des Wikis auf seinem Rechner besitzt, und durch ersetzen der Daten mit der Cloud in beide Richtungen, das Wiki automatisch aktualisiert wird. Das mit dem Dateispeicherort der DB hat gut geklappt, ich habe die Datein gefunden. Danke, Luke081515 Aufgabe für mich? Sprich mich an! 22:25, 7. Dez. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Luke081515 Aufgabe für mich? 21:18, 14. Dez. 2014 (CET)

Textmarker auf der Bio

Warum klappt das nicht? --Atamari (Diskussion) 14:17, 14. Dez. 2014 (CET)

Die Anweisung selbst sieht gut aus; im diff alle Seiten aller Namensräume, deren URL auf Pissaro endet.

Aber davor steht eine einzelne Zeile mit // – das ist ein Syntaxfehler, und kann dazu führen, dass von nun an nichts mehr gelesen wird.

Hinweis: Der einzige Kommentar in CSS ist /* ... */ – es gibt zwar auch ein // wie auch /* ... */, aber nur in Sprachen wie JavaScript.

Schönen Sonntag --PerfektesChaos 15:01, 14. Dez. 2014 (CET)

Danke, den falschen Kommentar habe ich heraus genommen. Trotzdem erhalte ich nicht das gewunschte Ergebnis, das Zeilen die das Schlüsselwort enthalten entweder orange oder grün dargestllt werden. --Atamari (Diskussion) 17:04, 14. Dez. 2014 (CET)

Wohl weil du ein paar Zeilen später unter dem Stichwort „Linkfarben“ schreibst:

background: none;

Das heißt, deine Einfärbung passierte vermutlich ordnungsgemäß, lebte aber nur ein paar Zeilen, bis sie wieder eliminiert wurde.

LG --PerfektesChaos 18:03, 14. Dez. 2014 (CET)

So, mit der letzten Version habe ich es hinbekommen, wie ich es möchte. Danke. --Atamari (Diskussion) 21:30, 14. Dez. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Atamari (Diskussion) 21:30, 14. Dez. 2014 (CET)

Timeo Danaos et dona ferentes?

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

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 00:39, 16. Dez. 2014 (CET)

Python-Skripts

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)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 00:40, 16. Dez. 2014 (CET)

"Diskussion" als Nicht-Link

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)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 00:41, 16. Dez. 2014 (CET)

Replace snippet (dedupe)

Hallo, ich habe mal wieder eine kleine Frage (damit die WS hier nicht einschläft) zu einem Problem was evtl. öfters erscheinen könnte. Ich suche einen RegExp oder andere String-Manipulation die ein doppeltes Vorkommen, hier konkret ein Wiki-Template im Textfeld ersetzt mit der Bedingung die Variante zu ersetzen die einen Parameter hat und die andere zu löschen (bei keinem von beidem wohl einfach letzteres löschen, das ist egal). Hier mein "Ansatz":

function replaceTag (editForm) {
	var regexp = /\{\{\(Vorlage1|Template2)[^}]*?\}\}\s*/i;
		cnt = 0, par = "",
		txt = $('#wpTextbox1').val();
	while (txt = txt.replace(regexp, "")) {
		cnt++; if (cnt > 2) break;  // counter da RegExp.lastMatch folgend resettet wird
		if (/\|[^|}]*\s*(\|[^|}]+)/.test(RegExp.lastMatch)) 
			par = RegExp.$1; // save 2. parameter
	}
	return [txt,par];
}

Wobei (mir leidlich) etwas sehr seltsames auffällt (Bsp-Seite (Script live)):

var regx = /\{\{(Convert[_ ]?to|To|2|Should[_ ]?Be)?[_ ]?(?:SVG|Vectorize|In SVG konvertieren)\s*\|?[^|}]*\s*(\|[^|}]+)?\}\}/ig;
var txt = $('#wpTextbox1').val();
console.log("1."+regx.exec(txt)); // egal welche RegExp-Abfrage
console.log("2."+regx.test(txt)); // die Zweite ist negativ !?!

Das geht doch bestimmtnoch optimaler!? → Benutzer: Perhelion 15:05, 24. Aug. 2014 (CEST)

1. „optimal“ kommt vom Superlativ Optimum, und diesen zu steigern, mag als Flapsigkeit durchgehen.
2. Du solltest aber vor alle deine snippets JSHint-Einstellungen setzen, etwa curly:true, eqeqeq:true usw. Das übt. Im CodeEditor werden sie ausgewertet.
3. Am alleroptimalsten wäre der Weg, wie hier als RegExp den ganzen Ausdruck (vorausgesetzt, keine geschachtelte) zu nehmen, mit got1=re.exec(s) die erste und mit got2=re.exec(s) die mögliche zweite Einbindung zu suchen.
   • In den Objekten got1 und got2 stehen alle Zeichenpositionen drin.
   • Wenn es got1 && got2 gibt, kannst du von beiden die Parameterversorgung analysieren (Klammerausdruck um Pipe) und die Einbindung wegschmeißen, die keinen oder einen leeren Parameter hat.
   • Anschließend zurück auf Anfang. Gibt es jetzt wieder got1 && got2 – dann waren dreie drin.

LG --PerfektesChaos 16:00, 24. Aug. 2014 (CEST)

Man kann dem replace auch ein callback mitgeben, anstatt eines Zielstrings mit oder ohne $1-Markern.

$( function() {
 alert( replaceTag( '1{{trans|par}}2{{trans}}3' ) ); // gives: 1{{trans|par}}23
 alert( replaceTag( '1{{trans}}2{{trans|par}}3' ) ); // gives: 12{{trans|par}}3
 alert( replaceTag( '1{{trans}}2{{trans|par}}3{{trans|par2}}4' ) ); // gives: 12{{trans|par}}34
} );

function replaceTag( string ) {
 var paramFound = false;
 return string.replace(
  /\{\{trans((\|[^\}]*)?)\}\}/g,
  function( group0, group1 ) {
   if ( group1 && !paramFound ) {
    paramFound = true;
    return group0;
   }
   return '';
  }
 );
}

So oder so ähnlich entferne ich doppelte DEFAULTSORT aus dem Wikitext, wenn mein Skript aufräumt. Hat natürlich den Nachteil, wenn es keine Einbindung mit Parameter gibt, das dann keine ohne Parameter übrig bleibt, das müsste man dann vorher prüfen, ob man überhaupt ersetzen muss. Außerdem bleibt immer die erste stehen, was wohl nicht ganz mit deiner Anfordernung sich deckt, aber als Idee wollte ich es trotzdem mal schreiben. Der Umherirrende 17:00, 24. Aug. 2014 (CEST)

Ich finde, Perhelion sollte sich etwas in Lua einarbeiten.

Dann kann er auf jeder Seite, in der die Vorlage eingebunden ist, ein Wartungsmodul starten.

Auf jeder einbindenden Seite wird der Quelltext durchgelesen, ob mehr als eine Einbindung vorkommt.

Falls ja, wird eine Wartungskat geworfen.

VG --PerfektesChaos 17:20, 24. Aug. 2014 (CEST)

Oha, danke euch sehr für die sehr guten Anregungen (dachte ich mir schon, dass ohne while und for umzusetzen) Und ja, mit Lua wollte ich mich später mal beschäftigen. → Benutzer: Perhelion 13:43, 25. Aug. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 00:42, 16. Dez. 2014 (CET)

Änderung im Javascript?

Gemeldet in Bugzilla
Bug 69924

Hallo zusammen,

in der Alemannischen Wikipedia verwenden wir seit vielen Jahren hochdeutsche Artikelnamen und eine Javascript-Vorlage, mit Hilfe derer wir den Seitentitel mit einem alemannischen Namen überblenden. Seit ein paar Tagen funktioniert das nicht mehr, z. B. bekomme ich im Artikel als:Turtmanntal den Titel (Turtmaatelli) neuerdings in einem Hellgrau angezeigt und im Artikel als:Burgheim (Unterelsass) wird der Titel (Burige) gar nicht angezeigt. Vermutlich liegt das an einem Software-Update, das wir auf als:MediaWiki:Common.js nachkorrigieren müssten. Kann mir da jemand helfen? Vielen Dank und Grüße, --Holder (Diskussion) 15:06, 25. Aug. 2014 (CEST)

Zieht die Funktion jsImp(i) vor die Funktion ifID(). Seit neuestem werden die JavaScripts in if-Blöcke gepackt, und in if-Blöcken aufgerufene Funktionen müssen vorher schon definiert worden sein. --YMS (Diskussion) 15:20, 25. Aug. 2014 (CEST)

+1

Die Veränderung betrifft nur Firefox; in allen anderen Browsern funktioniert euer .js weiterhin.

Alle Funktionsdefinitionen müssen an den Anfang eurer .js verschoben werden, erst danach mit der Ausführung beginnen. Da sind noch mehr betroffen.

Die Deklaration

function foo() {
   // ...
}

bedeutet eigentlich nichts als

var foo = function () {
   // ...
}

und wenn man, so wie bei euch mit ifID() und jsImp() schreibt

foo();
function foo() {
   // ...
}

dann ist das schlicht und einfach noch nicht deklariert. Die Browser nehmen das unterschiedlich krumm, und für Firefox wurde es mit der kürzlichen if-Klausel zuviel.

Tipp: Fügt die folgenden Zeilen vor dem Anfang ein

/*jshint curly:true, latedef:true, laxbreak:true, trailing:true, undef:true */
/*global window:false, mw:false, $:false */

und schmeißt den Quellcode in die Seite http://www.jshint.com/

Alle was used before it was defined. müsssen verschwinden.

Liebe Grüße --PerfektesChaos 16:09, 25. Aug. 2014 (CEST)

Vielen Dank Euch beiden, es hat funktioniert! --Holder (Diskussion) 17:23, 25. Aug. 2014 (CEST)

function foo () {} und var foo = function () {}; bedeuten nicht das gleiche, auch nicht eigentlich, siehe http://ecma-international.org/ecma-262/5.1/#sec-13. Sie unterscheiden sich im Zeitpunkt der Definition und im Scope (auch wenn ich nicht verstehe, was das heißen soll). Noch unverständlicher ist übrigens, was var bar = function foo () {}; tut.

Das Problem war auch nicht, dass die Funktion genutzt wurde, bevor sie definiert wurde, sondern, dass der Code neuerdings in einen if-Block gepackt wird, aber ohne Syntaxerweiterungen eine FunctionDeclaration (im Gegensatz zu einer FunctionExpression) nicht innerhalb eines solchen Blocks stehen darf.

In einem Browser ohne Syntaxerweiterungen wird der Code in seinem augenblicklichen Zustand also immer noch zu Syntaxfehlern führen, allerdings habe alle verbreiteten Browser entsprechende Erweiterungen, für Firefox ist das FunctionStatement. Eine genaue Definition der Semantik kann ich nicht finden, aber hier trifft wohl das zu, was PerfektesChaos oben geschrieben hat: function foo () {} als FunctionStatement (und nicht als FunctionDeclaration) entspricht var foo = function () {}; (als FunctionExpression).

Das heißt: Der Code mag zwar im Moment in allen Browsern funktionieren, es ist aber nicht garantiert, dass das so bleiben wird, insbesondere wenn (absichtlich oder versehentlich) der Strict-Mode aktiviert wird, wird es nicht mehr funktionieren. --Schnark 09:56, 26. Aug. 2014 (CEST)

Es ist ein Überbleibsel aus den 1990ern, und damals war so ein krudes Gemisch aus Deklarationen und Ausführung üblich. Es ging darum, in eine HTML-Seite ein paar dutzend Zeilen Skript einzufügen und fertig. Mit heutigen Bibliotheken aus Zehntausenden von Statements ist das völlig gaga. Früher wurde auch überhaupt nicht nach dem Ort des Einfügens und der Auswirkung auf Funktionsdeklarationen und var oder nicht und der Art der Deklaration unterschieden, sondern das irgendwie interpretiert.

Seit der Spezifikation nach ECMA ist das so nicht mehr zulässig, wie Schnark richtig anmerkt.

Um die uralten Webseiten aber nicht zu brechen, tolerieren die meisten Browser die Verletzung und führen es sinngemäß aus. Firefox handelt irgendwie seit einer Weile strenger.

LG --PerfektesChaos 10:52, 26. Aug. 2014 (CEST)

Antwort auf: „was var bar = function foo () {}; tut“

• bar kann von innen und außen benutzt werden.
• foo kann nur aus dem Inneren benutzt werden, um sich selbst-rekursiv aufzurufen.
  • Das könnte man vielleicht brauchen, wenn man den Namen von bar nicht kennt und nicht weiß, welche Objektkomponente oder var man selbst ist; aber die Funktion kennt ihren inneren Namen foo und kann sich damit zweifelsfrei selbst identifizieren.

LG --PerfektesChaos 11:12, 26. Aug. 2014 (CEST)

Ich wollte nicht wissen, was das aus Anwender- (= JS-Programmierer) -Sicht tut, sondern aus Sicht der Implementation. Ich verstehe ja schon nicht den Unterschied zwischen VariableEnvironment und LexicalEnvironment, der den zweiten Unterschied zwischen FunctionDeclaration und FunctionExpression ausmacht. Aber die 6-schrittige Anweisung für FunctionExpression mit Identifier übertrifft das an Unverständlichkeit bei weitem. --Schnark 11:54, 26. Aug. 2014 (CEST)

Könnte ab 25. September aufgrund dieser Software-Änderung wieder funktionieren. Getestet werden kann es auf beta.wmflabs. Der Umherirrende 17:41, 20. Sep. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 00:43, 16. Dez. 2014 (CET)

Spam-Filter für die Wikipedia?

Hallo aktive Wiki-Freunde! Ich finde es immer wieder ärgerlich, wenn irgendein nichtangemeldeter Vandale in Artikeln rumpfuscht, um Obszönitäten u.ä. dort zu platzieren. Das Zurücksetzen ist sicherlich eine elegante Funktion, aber wie wäre es, wenn es eine Art Spam-Filter gäbe, der automatisch solche Eingaben verhindert? Ich stelle mir das vor, wie bei meinem Programm „Pop-Monitor", wo ich Filterregeln definiere wie „Wort enthält: fick*, Sex* Scheiß* u.s.w." Kennt Ihr ja sicherlich alle. Wäre doch noch eleganter, wenn das beim Klicken auf den Speichern-Button bereits systemseitig erkannt würde und automatisch verhindert – am besten gleich noch die IP sperrt, von der der Versuch kam (oder ihm zumindest eine Warnung zurückmeldet). ... Falls ich nicht der erste bin, der einen Vorschlag dieser Art gemacht hat, bitte nicht stöhnen – einfach ignorieren :-) Viele Grüße aus Wuppertal --Ökologix (Diskussion) 07:51, 13. Sep. 2014 (CEST)

So ein Mist, sofort nach dem Absenden finde ich Hilfe:Bearbeitungsfilter. Hat sich damit wohl erledigt. Sehr schön! --Ökologix (Diskussion) 07:53, 13. Sep. 2014 (CEST)

@Ökologix: Solche Filter, die rein bei bestimmten Signalwörter zuschlagen sind nicht besonders effektiv da sie nie erschöpfend sind, die falsch-positiv-Rate zu hoch ist und das Rückmeldung für die (neuen) User derzeit sehr schlecht gelöst ist. Der Bearbeitungsfilter ist nur sehr begrenzt gegen alltäglichen Vandalismus einsetzbar, eigentlich nur für sehr einfache Fälle, als Markierhilfe und gegen sehr spezielle Trolle. Bei anderen Wikipedia-Ausgaben sind Bots aktiv, die automatisch revertieren. So basiert en:User:ClueBot NG z.B. auf einem künstlichem neuronalen Netz und lernt welche Bearbeitungen Vandalismus sind und welche nicht. Wenn man sich seine Änderungen ansieht ist er auch recht erfolgreich, er sollte dabei eine falsch-positiv-Rate von maximal 0,1% haben. Hier haben wir das nicht nötig, da wir viel viel weniger Edits pro Stunde haben und unsere Vandalismusbekämpfer recht aktiv sind. --sitic (Diskussion) 16:57, 13. Sep. 2014 (CEST)

Lieben Dank für die Info! --Ökologix (Diskussion) 19:59, 13. Sep. 2014 (CEST)

Es sei noch auf IP-Patrol hingewiesen, das die Spam-Wahrscheinlichkeit auch berechnet und anzeigt (aber nicht mit ANN sondern mit einem viel einfacheren Naive Bayes). --APPER\^☺☹ 20:09, 13. Sep. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 00:43, 16. Dez. 2014 (CET)

Hinweis: [BREAKING CHANGE] Deprecated JavaScript methods to be removed in MediaWiki 1.25

Damit es möglichst viele Lesen, hier ein wichtiger Hinweis für alle JavaScript-Programmierer: [BREAKING CHANGE] Deprecated JavaScript methods to be removed in MediaWiki 1.25. — Raymond ^Disk. 18:08, 21. Sep. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 00:44, 16. Dez. 2014 (CET)

Kleinere Aufgaben und Mentoren gesucht für Google Code-In

Google Code-In (GCI) startet bald wieder - ein sechs Wochen langer Wettbewerb für 13-17 Jahre alte Schüler zum Mitarbeiten an freien Softwareprojekten. Wikimedia hat bereits letztes Jahr teilgenommen mit guten Ergebnissen. Für die Aufgaben (tasks) in GCI sollte ein erfahrener Mitwirkender zwei bis drei Stunden benötigen (aber "beginner tasks" die kürzer dauern sind auch sehr willkommen). Die Kategorien für mögliche Aufgaben lauten: Code, Documentation/Training, Outreach/Research, Quality Assurance und User Interface/Design.

Hast Du eine Idee für eine Aufgabe und kannst Du Dir vorstellen für diese Mentor zu sein? Benötigt etwas zum Beispiel bessere Dokumentation, gibt es kleinere CSS-Probleme zum Bearbeiten, oder Vorlagen die noch zu Lua zu portieren sind aber für die man bisher keine Zeit gefunden hat? (Eine Auswahl an einfacheren Tickets im Bugzilla gibt es auch, die gegebenenfalls Google Code-In-Aufgaben sein könnten und einen Mentor suchen.) Falls das der Fall ist, wirf bitte einen Blick auf mw:Google Code-in 2014 und die dortige "Mentor's corner" und füge die Aufgabe hinzu (sehr gerne bis Sonntag, wir können die Beschreibungen noch bis zum 01. Dezember verbessern wenn der Wettbewerb beginnt)! Und falls etwas unklar ist, bitte einfach auf der zugehörigen Diskussionsseite fragen. Herzlichen Dank! --AKlapper (WMF) (Diskussion) 22:30, 6. Nov. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 00:45, 16. Dez. 2014 (CET)

Bilder in Mediawiki importieren

Ich möchte die Vorlagen wie Erl. improtieren, die Vorlagen habe ich auch schon importiert, nur das mit den Bildern bekomme ich nicht hin. Als XML Datei über Spezial:Importieren geht es nicht, deshlab habe ich die Grafik abgespeichert, und wollte sie über Datei hochladen hochladen, jedoch heißt es dann "Das XML in der hochgeladenen Datei konnte nicht geparst werden." Kann mir jemand weiterhelfen? LG, Luke081515 Aufgabe für mich? 22:25, 14. Dez. 2014 (CET)

Dateien lassen sich nicht importieren. Um viele Dateien zu übernehmen, kannst du die Bildbeschreibungsseiten importieren und dann die Dateien jeweils hochladen. Etwaige Fehlermeldungen kannst du über das Häkchen "Warnmeldungen ignorieren" (oder so) im Uploadformular verhindern. Commons-Dateien brauchst du nicht hochladen, stattdessen kannst du dein Wiki für den Commons-Zugriff freigeben ([6]). XenonX3 – (☎) 22:32, 14. Dez. 2014 (CET)

@XenonX3:: Leider geht es immer noch nicht. Wenn ich erst die Beschreibungsseiten importiere, dann gibt es denselben Fehler, da hilft auch "Warnmeldungen ignorieren" nichts. Und wenn ich InstantCommons anschalte, dann bricht er die Verbindung nach 30 sec. automatisch ab, weil er irgendeine maximale Dauer überschritten hat. Kannst du mir da helfen? LG, Luke081515 Aufgabe für mich? 22:10, 15. Dez. 2014 (CET)

Hat denn deine MediaWiki-Installation Zugriff auf das Internet? Ich denke, wir sollten zunächst mal das Problem bezüglich des Fernzugriffs auf Commons lösen; wenn das klappt, dann kann man auf die gleich Weise den Zugriff auf andere Wikis (bspw. de.WP) machen, dann braucht man keine Dateien übertragen. --Morten Haan 🎄 Wikipedia ist für Leser da 17:47, 20. Dez. 2014 (CET)

Muss man den Internetzugriff extra einrichten? Denn mein PC hat Internet, daran liegt es nicht... LG, Luke081515 Aufgabe für mich? 18:57, 20. Dez. 2014 (CET)

Vielleicht stellt sich die Firewall quer oder die Internetverbindung ist zu langsam. --Morten Haan 🎄 Wikipedia ist für Leser da 23:07, 21. Dez. 2014 (CET)

Interessant, nachdem ich die Windows-Firewall komplett deaktiviert hatte, ging die Bewertung 7Tage plötzlich. Nur das verlinkte Glossar war rot Vorlage:Smiley/Wartung/;-) . Danke!

Luke081515 Aufgabe für mich? 23:36, 21. Dez. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Luke081515 Aufgabe für mich? 23:36, 21. Dez. 2014 (CET)|2=Problem gelöst

Unformatierter Text

Üblicherweise erscheint Text, der mit einem Leerzeichen beginnt

so

aber aus irgendwelchen Gründen geschieht das bei mir unter Monobook nicht mehr durchgehend. Hier auf dieser Seite klappt es, aber auf bspw. Kategoriendiskussionsseiten nicht mehr, etwa diese. Ich vermute, daß irgendwas geändert wurde und deswegen irgendwas in meiner CSS nicht mehr so funzt wie bisher. Könnte bitte ein Kundiger da schauen, woran es liegt? --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 20:52, 28. Dez. 2014 (CET)

Das liegt an dem nicht geschlossen <blockquote>. --Fomafix (Diskussion) 21:14, 28. Dez. 2014 (CET)

Danke dir, nun bereinigt. --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 22:31, 28. Dez. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 22:31, 28. Dez. 2014 (CET)

Merlbot mit anderer Sortierung möglich?

Hallo liebe Technikfreunde,

auf meiner Unterseite Benutzer:mundanus/Überarbeiten sagt mir Merlbot was es alles im Bereich des Steuerrechts zu tun gibt. Das I-Tüpfelchen wäre es, wenn die Listen nicht alphabetisch, sondern nach Priorität (Priorität hätte für mich die höchste Abrufstatistik) sortiert würden. Könnte man das irgendwie hinbekommen? Die Abrufstatistiken müssen auch nicht ganz aktuell sein (Z. B. Vorjahr).--mundanus ^Disk. 21:29, 19. Dez. 2014 (CET)

Der Merlbot ist ein Projekt von Benutzer:Merlissimo, nur er hat Zugriff auf den Quelltext um eventuell neue Funktionien einzubauen. Ob er die Daten für die Artikelstatistik im Zugriff hat, weiß ich auch nicht, so dass dies für mich erstmal nicht möglich erscheint, aber er kann da mehr zu sagen. Der Umherirrende 10:26, 20. Dez. 2014 (CET)

Danke, dann wende ich mich mal an Merlissimo. --mundanus ^Disk. 19:21, 20. Dez. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 16:39, 29. Jan. 2015 (CET)

Syntaxfehler in Benutzer:Lenkhering/common.css?

Mag bitte mal jemand schauen, was in Benutzer:Lenkhering/common.css falsch ist? Ich wurde angefragt wg. einer Modifikation des BKL-Helferleins. Hat auch geklappt, bloß nicht im Internet Explorer, den der Kunde leider verwendet. Durch ein !important; geht es auch mit IE. Ich testete dann, ob andere Funktionen der .ccs noch funktionieren. Fehlanzeige: Weder auf den letzten Änderungen, noch auf der Beobachtungsliste werden die Seiten hervorgehoben, die ich hervorheben will. Da muss irgendein Fehler drin sein, den ich mit meinen (eigentlich nicht vorhandenen) CSS-Kenntnissen nicht sehe. Gruß --Schniggendiller Diskussion 01:52, 23. Dez. 2014 (CET)

In Zeile 7 und 9 sollte statt #F88 border #F88; border stehen. mw:Extension:CodeEditor zeigt das auch an. Wo man den aktivieren kann weiss ich leider nicht mehr. Bei Zeile 12 tippe ich auf Leerzeichen statt Unterstrich. --nenntmichruhigip (Diskussion) 02:49, 23. Dez. 2014 (CET)

Nein, das war es leider nicht :-( Gruß --Schniggendiller Diskussion 03:26, 23. Dez. 2014 (CET)

Und das auch nicht. Gruß --Schniggendiller Diskussion 03:33, 23. Dez. 2014 (CET)

OT: Nein, am Ende muss nicht zwingend ein Semikolon stehen, sieht aber imo schöner aus. --nenntmichruhigip (Diskussion) 05:23, 23. Dez. 2014 (CET)

Ich habe jetzt mal stückchenweise seine common.css in die "Stylebearbeitung" von Firefox eingefügt. Die Zeile .page-Spezial_Beobachtungsliste a[href*="/wiki/Benutzer_Diskussion:Oliver_S.Y."] funktioniert in der von mir geschriebenen Variante (auch mit grossem 'A'), aber nicht, wenn ich die Zeile komplett kopiere. Mein Hexeditor meint, dass sich da vor dem beendenden '"' ein LTR-Mark eingeschlichen hat. Ebenso bei den anderen ausser WP:Verhalten_im_Notfall. --nenntmichruhigip (Diskussion) 05:23, 23. Dez. 2014 (CET)

Guten Morgen, hier ist die Tagschicht. Ihr habt schon gut vorgearbeitet.

• Das LTR-Mark muss unbedingt da raus; ist momentan der eigentliche Blockierer.
  • Y."] im Editor markieren und dann von Hand Y."] drübertippen oder von dieser Seite hier kopieren; dann ist es weg.
  • Das würde sonst in der HTML-Seite in der URL erwartet; steht da aber nicht.
• Es empfiehlt sich, die URL-Adresszeile nach Aufruf der Zielseite mit C&P einzufügen und auf href*="/w zu kürzen; das vermeidet dieses Problem mit dem unsichtbaren Zeichen.
  • Wenn da Umlaute usw. drin sind, bekommt man auch gleich das Prozent-Encoding dafür.
  • Auch der _ in Schon gewusst wäre mit bei gewesen.
• Benutzer, die öfter mal das Geschlecht wechseln, sollten simultan als Benutzerin: vermerkt werden.
• Momentan greift das auch bei beobachteten Unterseiten. Wenn man zwei Benutzer/Seiten beobachtet, wo der eine Name der Beginn eines anderen ist, kann mit $ statt * bei a[href$=" gefordert werden, dass der Name (die URL) exakt so endet.
• A[href oder a[href ist egal.
• Semikolon: Bei längeren Definitionen und auf eigenständigen CSS-Seiten ist es üblich, an das Ende noch ein ; zu setzen; sonst verpennt man das, wenn eine weitere Eigenschaft angefügt oder eine Zeile kopiert wird.
  • Siehe Hilfe:CSS #CSS-Notation und Wikipedia:CSS #Formatierung.
  • Es ist legal, beliebig viele Semikolonse mit nur Weißraum zwischen und vor und nach den Definitionen zu haben.
• Die ! important richten keinen Schaden an, sind aber hier wirkungsfrei.
  • Zum besseren Verständnis würde ich sie hier entfernen.

LG --PerfektesChaos 11:31, 23. Dez. 2014 (CET)

Klappt leider immer noch nicht :-/ Das LTR sollte jetzt raus sein. Den Oliver-Platzhalter habe ich durch etwas anderes ersetzt, nach wie vor keine Hervorhebung. Zum Haareraufen … Gruß --Schniggendiller Diskussion 03:42, 31. Dez. 2014 (CET)

Probiere das mal:

.mw-editsection { margin: 0; }
#mw-navigation+h2, #editpage-copywarn, #pt-betafeatures, .mw-changeslist-legend
{ display:none; }

/* bestimmte Seiten NUR auf den letzten Änderungen hervorheben */
.page-Spezial_Letzte_Änderungen a[href^="/w/index.php?title=Diskussion:Gaster_(Hautfl%C3%BCgler)"],
.page-Spezial_Letzte_Änderungen a[href^="/w/index.php?title=Gaster_(Hautfl%C3%BCgler)"]
{ background-color: #F88; border: 1px solid black; }

/* bestimmte Seiten NUR auf der Beobachtungsliste hervorheben */
.page-Spezial_Beobachtungsliste a[href^="/wiki/Gaster_(Hautfl%C3%BCgler)"]
{ background-color: #F88; border: 3px solid #F88; }

.bkl-link {	background-color: lightgreen; }

Guten Rutsch allen. -- 2A02:810A:8AC0:12FC:415:5612:67EE:58B1 04:40, 31. Dez. 2014 (CET)

Valide (im Vector-Skin) ist sein CSS. Nur ein paar Hinweise das die Rahmenfarbe der Hintergrundfarbe entspricht. Wenn es Gültig ist wäre zu klären warum die IDs nicht erkannt werden. Das einzige Problem könnte das URL-Encoding sein, wie es oben die IP vorgeschlagen hat. Da das HTML die URL-Encodet enthält ist das auch im CSS anzugeben. Mögliche Fehlerquelle: Der FireFox kehrt diese Url-Encoding von Umlauten in der Adresszeile gerne wieder um, der IE tut dies nicht, wenn man also aus der Adresszeile kopiert, kann das schiefgehen. Der Umherirrende 11:34, 31. Dez. 2014 (CET)

Frohes Neues.

• Also, die %-encoded kamen von mir, und in meinem Firefox greifen sie so und nur so.
• Im HTML-Dokument des Wiki-Servers stehen sie %-encoded drin, und das wird vom CSS durchsucht.
• Ich glaube nicht, dass irgendein Vorgang die Link-Zeichenketten rekodiert in Umlaute etc.
• Es schadet aber nicht, beide Formate als Selektoren aufzulisten; schon weil das direkte Format intuitiver lesbar ist.
• Meine Erfahrungen beschränken sich allerdings auf die Beo; hier oben haben wir aber noch ein Ä im Selektor; nämlich von den Letzten Änderungen.
  • Das könnte das Problem bereiten; auf Wikipedia:CSS#Beo wird ziemlich bewusst mit vorangestellter Einschränkung a.mw-changeslist-title gearbeitet, was auf RC wie auf Beo greift.
  • Wenn man sowieso besonders an dieser Seite oder dem Benutzer interessiert ist, kann man aber die Einschränkung fallenlassen und auf allen Seiten alle Verlinkungen darauf markieren; ich umgebe mich selbst beispielsweise überall mit einem dicken hellgrünen Rahmen (das gold von CSS war mir zu schebbich). Oder auf allen Spezialseiten markieren; .ns--1 erwischt allerhand von Logbuch über Beo und RC, lässt aber Disk in Ruhe.

LG --PerfektesChaos 18:52, 1. Jan. 2015 (CET)

Hrmpf, an die verdammten Umlaute hatte ich nicht gedacht … Insgesamt ist die Chose komplizierter als ich dachte. Ich hoffe, daß ich kommendes Wochenende endlich dazu komme, eure Tipps zu testen (verstanden habe ich bislang noch nicht alles). Gruß --Schniggendiller Diskussion 00:22, 8. Jan. 2015 (CET)

Nicht, daß noch jemand denkt, ich hätte diese Baustelle vergessen: Ich habe momentan kein Internet zuhause, ist also nur aufgeschoben, nicht aufgehoben. Gruß --Schniggendiller Diskussion 16:43, 29. Jan. 2015 (CET)

Ich habe mittlerweile in einer nicht-öffentlichen CSS-Datei die folgende Zeichenkette für Firefox gefunden, was auch funktioniert:

.watchlist-4-Importwünsche

Das lässt auf UTF-8 schließen.

Eine oben skizzierte reine ASCII-Lösung a.mw-changeslist-title würde ich trotzdem als stabiler vorziehen, wo das möglich ist.

Immer mit der Ruhe --PerfektesChaos 22:08, 29. Jan. 2015 (CET)

Auch ohne mein Zutun meldete mein „Kunde“, daß die BKLs jetzt wie gewünscht grün sind. Dies löste dann auch die gewünschte Hervorhebung bestimmter Seiten auf RC und BEO aus. Getreu der Devise „Never change a running system“ lasse ich den Code jetzt so wie er ist, auch wenn er nicht ganz optimal sein sollte ;-)
Ich bedanke mich bei allen Helfern! Gruß --Schniggendiller Diskussion 11:41, 16. Feb. 2015 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Schniggendiller Diskussion 11:41, 16. Feb. 2015 (CET)

Tatsächliche Artikelanzahl

Eine Frage an die Datenbanktabellenprofis: Habe ich in http://quarry.wmflabs.org/query/1222 etwas falsch gemacht, oder liegt {{NUMBEROFARTICLES}} inzwischen wirklich um 25.000 Artikel (also etwa die Neuanlagen innerhalb von 75 Tagan) falsch? --Schnark 12:09, 19. Dez. 2014 (CET)

Schau auf Spezial:ValidationStatistics, dort wird die Zahl alle 2 Stunden aktualisiert und ziehe Spezial:DeadendPages ab. 1.787.787 vs. 1.761.991, also ja der Zähler steht falsch. Eine Möglichkeit könnten (abgebrochende) Imports sein, wenn ich da mal eine Bugmeldung richtig gelesen habe. Der Umherirrende 16:42, 19. Dez. 2014 (CET)

Und welche Zahl ist die richtige? Wie kann man den Zähler reparieren? 85.212.38.115 17:41, 19. Dez. 2014 (CET)

„Ungefähr 0“ dürfte eine ebensogute Schätzung für die Anzahl der Sackgassenartikel sein wie die „aktuelle“ (sprich fast zwei Wochen alte) Zahl der Spezialseite. Interessanterweise ist die Zahl in nl.wikipedia ziemlich exakt: http://quarry.wmflabs.org/query/1227. Korrekt ist die kleiner Zahl aus der Datenbankabfrage, ob es ein Maintenance-Skript gibt um die Zahl zu korrigieren, weiß ich nicht, aber: Wollen wir die Zahl überhaupt korrigiert haben? Das ist doch nur Wettmanipulation und noch mehr Gefahr im internationalen Ranking. --Schnark 09:35, 20. Dez. 2014 (CET)

Es gibt mw:Manual:UpdateArticleCount.php, da das aber lange laufen wird, ist es wohl schwierig es zur Ausführung zu bekommen. Außerdem wird während des laufes neue Artikel angelegt, so dass man keine 100 % genauigkeit bekommt, da ist unsere 98,56 % doch auch in Ordnung. Der Umherirrende 10:24, 20. Dez. 2014 (CET)

Das scheint übrigens nicht nur von gescheiterten Importen zu kommen, sondern auch von erfolgreichen: phab:T42009. --Schnark 09:32, 8. Jan. 2015 (CET)

Es gibt jetzt wohl einen periodischen Lauf des besagten Skripts: phab:T68867. Der Umherirrende 20:10, 30. Mär. 2015 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:10, 30. Mär. 2015 (CEST)

Flickr2Commons-Bookmarklet funktioniert nicht mehr mit WMF Labs

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)

Wegen Zeitablauf und möglicher zwischenzeitlicher Veränderungen in den zahlreichen beteiligten Softwarekomponenten nicht mehr im Fokus. --PerfektesChaos 13:24, 29. Jun. 2015 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 13:24, 29. Jun. 2015 (CEST)

Spezial:UnconnectedPages

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

Wegen Zeitablauf und möglicher zwischenzeitlicher Veränderungen in den zahlreichen beteiligten Softwarekomponenten nicht mehr im Fokus. --PerfektesChaos 13:24, 29. Jun. 2015 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 13:24, 29. Jun. 2015 (CEST)

Android: Tastatur verschwindet bei Suchvorschlägen

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)

Weiter unten gab's noch etwas mehr dazu, damit für mich erledigt. --nenntmichruhigip (Diskussion) 17:29, 19. Aug. 2015 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: nenntmichruhigip (Diskussion) 17:29, 19. Aug. 2015 (CEST)

Obsoletes auf MediaWiki:Gadget-*

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

• Eigenständiger Fork in deWP.
• Siehe Wikipedia:Administratoren/Anfragen/Archiv/2014/Juni #Nachtschicht einlegen?

MediaWiki:Gadget-revisionCounter.js

addOnloadHook

importScriptURI

Kapselung; auch für Ajax-Callback

Umschreiben auf jQuery vervollständigen; nicht nur halb

• Neuimplementierung: Benutzer:Fomafix/Gadget-revisionCounter.js

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 --PerfektesChaos 23:23, 27. Aug. 2014 (CEST)

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. PS: Und ja, jemand sollte dir wirklich mal unter die Arme greifen, du hast ja schon wirklich einiges getan! → Perhelion     22:15, 9. Jun. 2014 (CEST)

Habe um den Juli einige Gadget entsprechend geändert. Falls noch etwas offen ist, bitte pro Gadget ein neuen Abschnitt mit den Einzelheiten, dann kann man die noch abarbeiten. Der Umherirrende 10:44, 31. Okt. 2015 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 10:44, 31. Okt. 2015 (CET)

Scrollbalken bewegt sich von alleine

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

Für die Mitleser: basierend auch auf der anderen Rückmeldung auf Spezial: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. Spezial: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)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 20:39, 3. Dez. 2015 (CET)

Revertkonflikt endlich beheben

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

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

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 20:39, 3. Dez. 2015 (CET)

Ruckeln der Seite beim Laden von Navigationsleisten vermeiden

Hallo,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ich fürchte, wir reden etwas aneinander vorbei.

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

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

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

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

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

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 20:39, 3. Dez. 2015 (CET)

Typografie-Helferlein; Erweiterte Beobachtungsliste

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

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 20:39, 3. Dez. 2015 (CET)

Bugmeldung MediaViewer: unvollständige Darstellung nach Vollbildanzeige

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

Umgebung: FireFox 29.0.1, Windows Vista SP2.

WP-Situation: eingeloggt, Vector.

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

Testseite: Artikel Ata Demirer.

Vorgehensweise zum Nachvollziehen des Bugs (in Schritten):

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

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

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

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

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

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 20:39, 3. Dez. 2015 (CET)

Probleme bei Datei-Löschungen

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

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

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

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

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

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

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 20:39, 3. Dez. 2015 (CET)

Falscher Pfad nach Link Extractor (LEA)

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

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

       alert("link="+link);

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

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

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

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

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

Server-Reply auf getJSON-Aufruf, Beispiel Soissons:

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

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

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

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

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 20:39, 3. Dez. 2015 (CET)

HTML5-Quelltext der Artikel teilweise nicht standardkonform

Hallo,

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

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

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

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

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

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

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

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

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

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 20:39, 3. Dez. 2015 (CET)

PDF erstellen

Gemeldet in Bugzilla
Bug 71286

Moin Moin fleißige Techniker,

ich habe folgendes Problem:

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

Er erstellt eine Datein mit diesem Namen:

939975a094033b38618d9a2f16e2ee36ac8ab889

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

Bitte helft mir!

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

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

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

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

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 02:05, 23. Feb. 2016 (CET)

„VM“, neues Signaturbild und kaputter Button in Werkzeugleiste

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

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

@XanonymusX: Besteht das Problem noch? --Leyo 02:06, 23. Feb. 2016 (CET)

@Leyo: Ich hab mittlerweile keinen IE mehr, in Edge passt jedenfalls alles.--XanonymusX (Diskussion) 00:45, 25. Feb. 2016 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 00:48, 25. Feb. 2016 (CET)

Wikipedia:Hauptseite/Jahrestage/Bearbeitungshinweise

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

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

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

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

Ich habe display:table an beiden Stellen entfernt.

Darüber hinaus habe ich auf der entsprechenden Diskussionsseite auch einen expliziten Hinweis hinterlassen, display:table bitte nicht mehr zu verwenden. Seit dieser Änderung hatte es nämlich die Wirkung, dass padding-left:0.5em nicht mehr funktioniert, weil border-collapse:collapse vererbt wird und jede Wirkung von padding-left:0.5em ausschließt. --Entlinkt (Diskussion) 20:48, 24. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 20:48, 24. Apr. 2016 (CEST)

https auf .beta.wmflabs.org

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

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

Und der Kommentar 69 in dem Bug report sagt sogar warum ("Prices offered by SSL vendors felt out of scope"). Ich glaube auch es hackt wenn man Geld fuer ueberteuerte Zertifikate aus dem Fenster wirft, ich weiss aber leider nicht was "senfen" bedeutet, um hier noch glorioser und emotionaler argumentieren zu koennen. Eigentlich glaube ich sogar dass es immer hackt! --Malyacko (Diskussion) 16:50, 3. Feb. 2014 (CET)

Es gibt doch generische Zertifikate, oder? Es gibt ja nur ein Zertifikat für *.wikipedia.org oder für de.wikipedia.org? Dann müssten die ja für jede neue Sprache ein Zertifikat kaufen, das kann ich mir nicht vorstellen. Es müsste also für *.wmflabs.org und/oder *.beta.wmflabs.org ein Zertifikat geben. Das wäre nicht so viel Aufwand, aber ich kenne mich damit nicht wirklich aus, habe das Argument der Bezahlung aber schon häufiger im Zusammenhang mit https gehört. Der Umherirrende 19:19, 3. Feb. 2014 (CET)

Dazu hat sich Krinkle in dem oben genannten Bug schon wie folgt geäußert: We'd only need beta.wmflabs.org and *.beta.wmflabs.org to be in the certificate (at e.g. DigiCert, those wildcards are $1425 for 3 years includes root and *). $1425 sind eine ziemliche Summe... - Hoo man (Diskussion) 20:04, 3. Feb. 2014 (CET)

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

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

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

Wurde im Herbst 2016 als HTTPS konfiguriert.

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 18:03, 13. Nov. 2016 (CET)

Bildverlinkungen in Galerien unterdrücken?

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

Innerhalb einer Gallery kann man auf alternative Linkziele verweisen:

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

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

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

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

Siehe auch Wikipedia:Fragen zur Wikipedia/Archiv/2014/Woche 19#Galerien ohne verlinkte Bilder und meine Antwort von dort:

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

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 00:23, 22. Nov. 2016 (CET)

WP:QS nicht vorhanden und doch angezeigt

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

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 14:33, 21. Nov. 2016 (CET)

Eigene Diskussionsbeiträge zusammenholen

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

---

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

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

Man hat dir vielleicht empfohlen, dich an irgendwas mit Technik zu wenden; aber ausweislich des blauen Kastens ganz oben war Wikipedia: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 Wikipedia:TW meine Kollegen fragen; vielleicht fällt dort jemand etwas ein.

LG --PerfektesChaos 19:09, 8. Feb. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 17:28, 29. Dez. 2017 (CET)

Problem mit Tabelle in der mobilen Version

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

Man könnte probieren eine feste Höhe zu setzen (wie es bei gutem Webdesign üblich ist). Ansonsten glaube ich weniger, dass man da was machen kann. → Benutzer: Perhelion   10:35, 16. Jun. 2014 (CEST)

Siehe auch bugzilla:64577 - Tabellen in mobilen Ansichten sind immer noch problematisch. --AKlapper (WMF) (Diskussion) 10:45, 16. Jun. 2014 (CEST)

Stelle eben fest, dass es mit neuerer Hardware und/oder Software funktioniert. Auf einem LG Optimus 9ii (D605) mit Android 4.4.2 gibt es keine Einschränkungen, und zwar sowohl mit "Internet" als auch mit dem Chrome-Browser und bei beiden sowohl in der normalen, als auch in der mobilen Ansicht. Das einzige, was nicht geht ist, in der mobilen Ansicht das Bild so klein zu ziehen, dass die gesamte Breite der Tabelle sichtbar ist. In der Normalansicht hingegen startet sie so klein. Ist aber keine wirkliche Einschränkung. @Benutzer: Perhelion Gutes Webdesign gibt keine festen Größen vor. --Karsten Meyer-Konstanz (D) 21:08, 6. Aug. 2014 (CEST)

@Meyer-Konstanz Sagt wer? Wenn Prozente die Lösung wären gäbe es mit Sicherheit kein Begriff wie Responsive Webdesign, davon abgesehen dass fixe Größen immer schneller und problemloser aufgebaut werden, darauf bezog ich mich und darum ging es doch hier? Pauschal kann man des eh nicht sagen, vlt. früher mehr, jedoch auch heute kann man das nicht eindeutig sagen, wenn man gewissen (Profi-)Tutorials folgt, z.B.:[9][10]“and there might not be a right or wrong answer.” PS: Ironischer Weise haben alle (unter Vereinsmeyer) auf deiner Benutzerseite als Webdesigner verlinkten Seiten ein Layout mit einer statischen Tabelle (sogar für jede einzelne Zelle). → Benutzer: Perhelion 06:13, 1. Sep. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 17:28, 29. Dez. 2017 (CET)

Nicht angezeigter Bearbeitungskonflikt bei Seitenneuanlagen?

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

@Emergency doc: Hast du diese Willkommen-Meldung per normalen Bearbeitungsfenster gemacht oder ein Tool oder ein Skript verwendet, wie beispielsweise Huggle oder ähnliches? Falls Bearbeitungen nicht per normalen Bearbeitungsfenster gemacht werden, muss das jeweilige Tool oder Skript das ganze mit bedenken und ein zusätzlichen Parameter setzen. Der Umherirrende 21:48, 20. Sep. 2014 (CEST)

Hallo, ich habe keine Hilfsmittel oder Tools eingesetzt sondern nur das normale Bearbeitungsfenster benutzt. Ich weiß aber nicht, ob Benutzer:Tol'biacMG ein Skript oder Programm benutzt.--Emergency doc (Disk) 01:17, 21. Sep. 2014 (CEST)

Falls es weiterhilft - ich nutze PDDs monobook-Skripte, sonst nichts. --Tolbiac|made|gotH 12:05, 21. Sep. 2014 (CEST)

Wichtig beim Bearbeitungskonflikt ist zu wissen, wie der Zweite die Bearbeitung getätigt hat, da die erste schon abgeschlossen ist und daher egal ist wie das passiert ist. Bei 13 Sekunden Unterschied ist es aber schon komisch, das die Erkennung nicht funktioniert hat. Möglicher Unterschied wäre noch mit section=new zu normaler Seitenerstellung. Ich werde die Tage mal testen, wobei sich seit dem 7. August auch schon wieder einiges an MediaWiki geändert haben kann, aber das bekommt man noch raus um das auszuschließen. Der Umherirrende 22:01, 21. Sep. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 17:28, 29. Dez. 2017 (CET)

Hover-Effekt bei Imagemaps

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

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

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 15:57, 30. Nov. 2018 (CET)

MediaWiki:Gadget-osm.js

Hallo,

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

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

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

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

Das Problem mit der zufälligen Ausführungsreihenfolge besteht auch bisher, wenn der Code in MediaWiki:Common.js ist. Nicht schön, aber ich finde das auch nicht schlimm.

Das mw.loader.using im Gadget ist überflüssig, da es bereits in MediaWiki:Gadgets-definition definiert ist.

Der ganze Code kann noch deutlich gestrafft werden. Bei Gelegenheit kann ich das mal machen.

Die Umsetzung als Gadget ist auf jeden Fall sinnvoll. --Fomafix (Diskussion) 00:30, 30. Aug. 2014 (CEST)

Ich hab es jetzt einfach mal aktiviert. Verbesserungen sind ja auch so immer noch möglich. --Entlinkt (Diskussion) 01:17, 30. Aug. 2014 (CEST)

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

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

Wenn man das Gadget deaktiviert (oder wenn JavaScript im Browser deaktiviert ist, insofern bestand das Problem schon immer), liefert {{Karte}} nur den nutzlosen Text "Karte" in der rechten oberen Ecke. Da sollte ein display: none; in die Vorlage und ein $( '#coordinates' ).show(); in das Gadget. --Schnark 09:12, 30. Okt. 2014 (CET)

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

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

Sind die Fixes richtig?

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

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

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

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

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

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 15:57, 30. Nov. 2018 (CET)

Leerzeilenbug

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

Anmerkung bezüglich obigem Fehler: Bitte im ANR kein Hinterher-Korrigieren nötig machen. --Leyo 00:11, 1. Sep. 2014 (CEST)

Die Tickets die Raymond im Bugzilla aufgemacht hat gibt es hier als Liste, ich kann aber spontan kein passendes finden bei der Suche nach "line" und "head". Bugzilla-Accounts gibt's aber umsonst und diese Seite sollte erklaeren wie man dort einen Eintrag macht. :) --AKlapper (WMF) (Diskussion) 12:52, 1. Sep. 2014 (CEST)

Diese Werkstatt ist aber ausdrücklich dazu da, um den weniger technisch versierten NormalbenutzerInnen zu helfen, die keine Lust haben, sich in Produktkategorien von MW einzuarbeiten und zu lernen, wie man diese ganzen Felder ausfüllen soll, und erstmal einen gesonderten Account anlegen und eine E-Mail-Adresse preisgeben zu müssen. Im Übrigen ist auch keine Voraussetzung für die Mitarbeit an einem Wiki, Technisches Englisch zu beherrschen.

Was mediawiki.org mal bräuchte, wäre ein Wiki. Ein niedrigschwelliges Angebot, wo alle und in ihrer Muttersprache Problembeschreibungen einbringen können (so wie diese Werkstatt hier). Das dann in einen Bug-Tracker einzupflegen ist dann Sache für die 100 Hauptamtlichen.

Da du ja jetzt von dem Problem weißt und es anscheinend keinen auffindbaren Bug in dieser Angelegenheit zu geben scheint, kannst du ihn ja jetzt anlegen, und kategorisieren und einstufen.

VG --PerfektesChaos 14:45, 1. Sep. 2014 (CEST)

+1 Dem kann man nur zustimmen, ganz abgesehen davon wie umständlich das alles (momentan) ist würde ich dann gerne wissen wieviele Bugs es dann tatsächlich geben würde. (Je mehr ich selbst dahinter steige desto mehr habe ich den Eindruck die Techniker sind in einer anderen Welt um nicht zu sagen Elfenbeinturm. Aber das Thema wird ja gerade intensiv woanders behandelt.) → Benutzer: Perhelion 16:00, 1. Sep. 2014 (CEST)

+1 und Dank an PerfektesChaos für die gute Idee mit der zentralen Bug-Sammelseite bräuchte, wo Fehler in der Muttersprache des hilfesuchenden Benutzers beschrieben und dann von Profis weiterbearbeitet werden können. Mir ist die Sache mit Bugzilla jedenfalls ebenfalls definitiv zu kompliziert und auf Anfrage bei Wikipediakollegen nach einer hilfreichen Seite wurde ich über Hilfe:Bugzilla bzw. Wikipedia:Technik/Bugzilla hierher gelotst, wo oben im gelben Feld Hilfe bei Problemen wie von mir beschrieben versprochen wird. Gruß -- Ra'ike ^Disk. _LKU ^WPMin 20:05, 1. Sep. 2014 (CEST) P.S. @Perhelion: Der Vergleich mit dem Elfenbeinturm passt übrigens gut. Ich habe jedesmal das Gefühl, ich stehe vor einem, wenn ich mir diese Bugzilla-Seiten ansehe und versuche da durchzusteigen :-/

@PerfektesChaos: Schoen dass die Werkstatt ausdruecklich dazu da ist, das begruesse ich. Ich werde aber kein Ticket in der Fehlerdatenbank zu einem Problem anlegen wenn ich das Problem nicht selbst reproduziert habe, weil der Reporter eines Fehlerberichts ggf. Nachfragen erhalten wuerde, nur um dann wild Nachfragen von A nach B herumzukopieren. Aber wie bereits beschrieben, Phabricator sollte etwas einfacher werden als Bugzilla. --AKlapper (WMF) (Diskussion) 12:14, 5. Sep. 2014 (CEST)

• Ich habe selbst die inhaltliche Seite der Angelegenheit nicht weiter analysiert, das geschah ja im weiteren Verlauf dieses Thread.
• Was die technisch routinierten Beteiligten in dieser Werkstatt machen (siehe auch vierten Punkt im Einleitungsabschnitt sowie vierten Punkt im gelben Kasten), ist Folgendes:
  • Kann das Problem von einem Benutzerskript, einem Gadget oder einer lokalen Eigenschaft der dewiki abhängen?
  • Lässt es sich reproduzieren?
  • Ist es vom Browser oder bestimmten Konfigurationen (Skin?) abhängig?
  • Kann die Ursache in einer extension, dem core, einem bestimmten include nebst Zeilennummern identifiziert werden?
• Anschließend eine möglichst detaillierte Bugzilla-Meldung mit den Ermittlungsergebnissen, oder sogar gleich ein Patch.
• Durch diese Vorfilterung werden unnötige Bugzillas vermieden.

VG --PerfektesChaos 16:01, 6. Sep. 2014 (CEST)

Es steht ja demnächst ein Wechsel von bugzilla & gerrit zu Phabricator (demo) an. Damit entfällt wenigstens dank SUL (OAUTH) die Account-Anlegerei. Ob sich das Bug-Suchen und Anlegen signifikant vereinfachen wird bezweifle ich allerdings. Bugzilla werde ich jedenfalls nicht vermissen. --sitic (Diskussion) 21:29, 1. Sep. 2014 (CEST)

Seufz, die Demo-Weibseite spricht wieder kein HTTPS worauf man zwangsumgeleitet wird. Ist leider bei einigen WMF Projekten so (anderes Beispiel). --sitic (Diskussion) 21:32, 1. Sep. 2014 (CEST)

Habe das mal geändert, wobei ich es nicht begrüße, wenn neue Projekte kein Zertifikat bekommen, müsste man eigentlich per Bugzilla (oder Fab?) beantragen. Der Umherirrende 18:50, 2. Sep. 2014 (CEST)

Das Bug-Anlegen wird sich vereinfachen, zumindest wenn es um das Formular geht (weniger Felder). Warum das "Suchen" bisher (in Bugzilla) als nicht einfach empfunden wurde kann ich nicht nachvollziehen. --AKlapper (WMF) (Diskussion) 12:50, 2. Sep. 2014 (CEST)

Ra'ike: Ich weiß, dass wir über den Bug früher geredet haben, aber ich kann mich leider an keinen Bugeintrag erinnern :-( Spannende Frage: Tritt der Bug auch mit dem VE noch auf? — Raymond ^Disk. 17:55, 2. Sep. 2014 (CEST)

Das von dir beschrieben Verhalten kommt daher, das beim öffnen eines Bearbeitungsfensters immer eine leere Zeile angehängt wird, wenn man jetzt ein Abschnitt bearbeitet, wo der nächste Abschnitt nicht mit einer Leerzeile abgegrenzt ist, so wird einer hinzugefügt (bei zwei Zeilen wird einer entfernt). In deinem Beispiel werden die Kommentare als Text am Ende eines Abschnitts angesehen und somit eine Leerzeile am Ende des Bearbeitungsfensters ergänzt, beim erzeugen des HTML hingegen wird der Kommentar entfernt und es bleibt ein unschöner Absatz stehen. Stellt sich die Frage, ob man die leeren Überschriften im Quelltext haben möchte oder ob man sie anders anordnet oder die Leerzeile davor entfernt oder MediaWiki gar keine Leerzeichen am Bearbeitungsfenster anfügen soll. Ich weiß allerdings nicht ob dann mehr Leute aufschreihen (über alle WMF-Wikis), das dieses Feature fehlt als jetzt aufschreien. Der Umherirrende 18:50, 2. Sep. 2014 (CEST)

@Raymond: Mal abgesehen davon, dass der VisualEditor das grauseligste Bearbeitungstool ist, dass ich je gesehen habe, scheint zumindest der Leerzeilenbug dort nicht aufzutreten [12]. Allerdings kriegt man beim VE auskommentierte (optionale) Texte/Überschriften auch gar nicht erst zu sehen, d.h. man könnte sie im Bedarfsfall auch nicht aktivieren. Nebenbei kann man übrigens mit dem VE eingefügte Links wie z.B. den nach Santa Fe (Oruro) nicht hinter einem Alternativtext (ohne Klammerzusatz) verstecken (oder ich hab's nicht gefunden), verlinkte Teile in Einzelnachweisen (z.B. zur Überprüfung o. Ergänzung von Daten/Fakten) nicht aufrufen und vor allem Tabellen nach wie vor nicht bearbeiten, weshalb der VE für mich bisher auch völlig unbrauchbar ist und ich den nach dem Test auch schnell wieder abgeschaltet habe.

@Umherirrender: So wie Du das Problem beschreibst, erscheint die Funktion mit der Leerzeile (fehlende Abschnitts-Leerzeile wird automatisch ergänzt, überflüssige entfernt) sogar durchaus sinnvoll. Das einzige, was man dem Programm halt noch klar machen müsste ist, dass auskommentierter Text nicht als normaler Text betrachtet werden darf. Zur Not könnte man die optionalen Überschriften wohl auch noch in dieser Form verstecken, aber bequemer wäre es natürlich, wenn sie wie beschrieben nicht als normaler Text erkannt würden und entsprechend automatisch auch keine Leerzeile angehängt würde.

Falls sich jemand fragen sollte, wieso man unbedingt optionale Überschriften in den Artikel einbauen möchte: Sie dienen einerseits als Hilfestellung für ergänzungswillige Benutzer und andererseits der Wahrung einer gewissen Einheitlichkeit der Artikel in diesem Themenbereich. Den meisten Benutzern dürfte nämlich die entsprechende Formatvorlage nicht bekannt sein und außerdem hängt an vier der wichtigsten Überschriften ein Bot, der das Vorhandensein selbiger überprüft und fehlende meldet. Gruß -- Ra'ike ^Disk. _LKU ^WPMin 19:37, 3. Sep. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 15:57, 30. Nov. 2018 (CET)

Alt-Texte im Screenreader

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

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

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

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

Der HTML-Code der <img> sieht sauber aus und ist in allen drei Fällen strukturell identisch. Wird auch von derselben Software generiert.

• Die Textlänge bei Elsa ist mit 338 Zeichen sogar länger als bei Thomas und erst recht bei Aral. An irgendeinem Limit von 255 oder 1024 Zeichen kann es nicht liegen.
• Ich sehe auch keine ausgeflippten Bytes oder exotische Zeichenkodierungen. Gerade Aral ist sehr übersichtlich.

Der geäußerte Verdacht, Commons ./. deWP als eigentlicher Lagerort hätte etwas damit zu tun, käme mir sehr spanisch vor.

• Die HTML-Seite weiß nichts davon, und die URL unterscheidet sich irgendwo im Pfad des Bildes. Die Domain upload.wikimedia.org ist identisch.
• Es ist aber nicht auszuschließen, dass irgendwer oder was damit interagiert; ggf. weitere Software hinterher draufpatscht.

Rückfragen:

• Was macht denn der MediaViewer so bei dieser Geschichte?
• Unter Spezial:Einstellungen #mw-prefsection-gadgets gibt es etwas: „Überspringen der lokalen Dateibeschreibungsseite, um sofort nach Commons zu kommen“ – ist das aktiv und funkt womöglich dazwischen? MediaWiki:Gadget-Direct-link-to-Commons.js verändert an allen Commons-Bildern nachträglich die Umgebung des <img>-Elements, lässt aber die lokalen in Ruhe. Aber die lokalen beiden würden nicht funktionieren, sondern gerade die auf Commons?
• Gibt es Sicherheitssoftware, die Manipulationen an HTML-Seiten beanstandet?
• Passiert das Gleiche als angemeldeter und nicht angemeldeter Benutzer?
• Es wäre sonst notwendig, etwas mehr über die Screenreader zu erfahren:
  • Wie lesen sie die Seite aus; in welcher Architektur sind sie gebaut? Ein eigenständiger Browser, oder ein Plugin in einem normalen Browser, das dann die abgerufenen HTML-Seiten interpretiert?
  • Könnte JavaScript im Spiel sein? Wird JavaScript vom Screenreader genutzt, ist es beim Browsen aktiviert?

Ansonsten:

• Unbesorgt weitermachen; weitere Beispiele sammeln.
• Die momentanen drei Bilder helfen noch nicht zur Identifikation eines Musters; fünf Ausfälle und zehn funktionierende sollten es schon sein.

Wird schon hinzubekommen sein --PerfektesChaos 17:25, 2. Okt. 2014 (CEST)

Antwort vom Firefox-Plugin-User (der jeden Alt-Text beim Mousover korrekt angezeigt bekommt):

• Das Überspringen ist bei mir aktiv, keine Sicherheitssoftware, Verhalten an-/abgemeldet identisch (ok).

Bei Wikinger08 gibt's offenbar ein je nach Screenreader (JAWS bad, NVDA good) unterschiedliches Verhalten.

--Mosmas (Diskussion) 19:13, 2. Okt. 2014 (CEST)

• Naja, dass du das lesen kannst, ahnte ich schon; es ginge um die Konstellation bei Wikinger08.
• JAWS schreibt: „Works with Microsoft Office, Internet Explorer, Firefox, and much more“ – das bedeutet, es läuft ein üblicher Browser und dieses JAWS ist dort obendrauf gesetzt. Damit kann es schon mal zu Kollisionen mit irgendwas kommen, und dessen Programmausführung bricht ab.
• Unsere HTML-Seite ist grundsätzlich in Ordnung; umso mehr, wenn der andere Screenreader es packt.
• Vielleicht haben bestimmte unserer Seiten eine Eigenschaft, die JAWS an der Interpretation hindert; vielleicht muss man nicht zu eng auf das Bild gucken, sondern weiter drumrum in der Seitenstruktur.
  • Mit den bekannten drei Links ist da aber wenig zu sehen; zumal Thomas so übersichtlich ist, dass da eigentlich keine Extravaganzen auftreten.
• Machen wir mal weiter, wenn mehr Informationen vorliegen --PerfektesChaos 20:03, 2. Okt. 2014 (CEST)

Hallo PerfektesChaos,
wenn ich mich abmelde, dann bekomme ich den Alternativtext bei Thomas vorgelesen und angezeigt; beim Aral-Logo hingegen wird er ignoriert. Ich habe wegen des Teilerfolgs mal alle Einstellungen auf Standard zurückgesetzt, doch da fehlen die Alt-Texte der o. g. Dateien wieder. Ob Commons oder dewiki, scheint doch keine Rolle zu spielen, denn im Artikel Weibernetz funktioniert die Interpretation des Alt-Textes.

Einstweilen vielen Dank fürs Überprüfen! --Wikinger08 (Diskussion) 10:10, 3. Okt. 2014 (CEST)

• „wenn ich mich abmelde, dann bekomme ich den Alternativtext bei Thomas vorgelesen und angezeigt“ – das klingt sehr danach, als ob irgendeins unserer zahlreichen JavaScript-Einheiten mit JAWS kollidiert wäre. Das wäre etwas, was im angemeldeten Zustand aktiv und abgemeldet nicht aktiv oder anders justiert ist.
• Mir fiel inzwischen noch MediaWiki:Gadget-Screenreader-Optimierung-TOC.js auf.
  • Der Code ist syntaktisch etwas veraltet. Warum TOC (Inhaltsverzeichnis) im Namen steht, ist nicht so recht ersichtlich – es beschäftigt sich mit allem Möglichen. Elsa und Weibernetz haben ein Inhaltsverzeichnis; Thomas standardmäßig nicht; auf Diskussionsseiten (→Aral) wirkt das Dingens nicht, sondern ausschließlich beim Angucken von Artikeln im ANR.
  • Der Diskussionsseite und den eingestreuten Kommentarzeilen kann ich in etwa entnehmen, was das Teil machen soll.
  • Es wäre zurzeit Kandidat Nummer 1 dafür, irgendetwas durcheinanderzubringen.
  • Das Dings orientiert sich an HTML-Seiten, wie wir sie 2007 produziert hatten. Zwar sehe ich keine Riesenauffälligkeiten, aber da könnte sich im Detail etwas geändert haben.

LG --PerfektesChaos 14:03, 3. Okt. 2014 (CEST)

Das Helferlein „Screenreader-Optimierung“ habe ich gar nicht aktiviert, weil ich keinerlei Vorteile erkennen kann. Es hat bei mir auch keine Auswirkung darauf, ob der Alt-Text funktioniert.

Ich mache jetzt erst mal eine Wikipause und melde mich hier zurück, wenn ich weitere Beispiele für nicht funktionierende Alt-Texte zusammengestellt habe. --Wikinger08 (Diskussion) 17:54, 4. Okt. 2014 (CEST)

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

Im Prinzip ja, macht aber keinen Spaß. Zumal du nicht nur Kurztexte wie „Logo“ lesen willst, sondern gezielt welche suchst, bei denen der Text 100 Zeichen und mehr hat; und da bekommt man derzeit nur selten eine Antwort. Man könnte aber den einige Wochen alten Dump durchsuchen lassen. LG --PerfektesChaos 22:39, 5. Okt. 2014 (CEST)

Wenn man nicht mit regulären Ausdrücken nach längeren Alt-Texten eingrenzen kann, würde ich eben selbst die längeren durch Sichtung herausfinden müssen. Wie würde man denn suchen? Viele Grüße --Mosmas (Diskussion) 09:20, 6. Okt. 2014 (CEST)

• Das Problem ist ein anderes: Mit der neuen Cirrus-Suche, die du vorab über die Beta-Features aktivieren könntest, kannst du zwar einen Suchausdruck eingeben.
• Es würde auch einen regulären Ausdruck geben, mit dem du Texte einer Mindestlänge von 77 Zeichen auffinden kannst:

  /\|\s*alt=[^]|]{77,}/

• Nur musst du dir den Spezialserver für reguläre Ausdrücke offenbar mit allen Zeitzonen der Welt teilen, in denen Englisch gesprochen wird. Heißt: Die Abfrage ist sehr komplex, braucht sehr lange, und du kommst in der Warteschlange nie zum Zug, und falls doch, bricht der Server wegen Überschreitung des Zeitlimits ab. Vergiss es.
• Wenn es unbedingt sein muss, wende dich besser an Wikipedia:B/A; den obigen RegExp kannst du mitbringen, da freuen die sich.

LG --PerfektesChaos 10:22, 6. Okt. 2014 (CEST)

vor regulären Ausdrücken habe ich keine Angst :) Danke, werde ich so machen! Liebe Grüße, --Mosmas (Diskussion) 17:47, 6. Okt. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 15:57, 30. Nov. 2018 (CET)

Fehler bei dem Anchorjump nach dem Bearbeiten eines Abschnittes.

Hi,

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

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

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

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

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

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 16:44, 19. Dez. 2019 (CET)

Darstellungsfehler QS-Baustein in Mobilversion

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

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

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

<Ende Übertrag>

Kann das jemand nachvollziehen und betrifft das evtl. auch andere QS-Bausteine? Könnt ihr helfen? --Mabschaaf 13:46, 16. Mär. 2014 (CET)

Hallo, ähnlich verzerrte Bilder sind mir mit dem Chrome-Browser in Denkmallisten aufgefallen. Vielleicht ist es ein allgemeineres Browser-Problem/Feature. --Wiegels „…“ 14:06, 16. Mär. 2014 (CET)

Für die CSS/Chrome-Experten: Wenn ich in den Developer Tools von Chrome, wenn man das QS-Bild auswählt, die CSS-Regel .content img { max-width: 100% !important; } (von [15]) 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)

Moin Moin @Mabschaaf und se4598, da Benutzer Impériale augenscheinlich nicht mehr im Projekt unterwegs ist, mal an euch beide. Ich würde den Absatz für erledigt ansehen, mag das jemand von euch gegenprüfen? Bugzilla ist geschlossen, meine Mobil-Version zeigt allerdings kein Icon. mfg --Crazy1880 21:55, 8. Jun. 2019 (CEST)

@Crazy1880: Auf meinem Mobilphone sehe ich (beobachtet in Guanidiniumcarbonat) zwar kein verzerrtes Bild wie oben beschrieben, dafür das Icon in geschätzter Größe von 5x5px. Es stört nicht wirklich, weil es so klein ist, aber erfüllt natürlich auch nicht seinen Zweck. Aus meiner Sicht daher nicht erledigt.--Mabschaaf 19:03, 9. Jun. 2019 (CEST)

Der Medizin-QS-Baustein zeigt das linke Bild in gleicher Weise extrem verkleinert, den rechten Wikiball dagegen gar nicht (Chiroskop). Der Baustein der Biologen (Tuberkel) und der Physiker (Gequetschtes Licht) ist anders aufgebaut (Piktogramm wird vom Text umflossen), dort gibt es das Problem so nicht. Falls es hilft: iOS 12.2, Monobook.--Mabschaaf 10:04, 10. Jun. 2019 (CEST)

Hinweis: Da spielt der Skin mit rein! Unangemeldet (Browser-Ansicht mit Vector) beginnt der Text der QS-Box sich unter einer Breite (des Browserfensters) ca. 485 Pixel mit dem Rahmen zu überschneiden, außerdem wandert die Infobox zu weit nach rechts und überschneidet sich mit der Leiste links. Das Icon is QS-Box behält konstante Größe.

Angemeldet mit Monobook wird unter einer Breite ca. 550 das Icon plötzlich winzig und die Leiste links verschwindet. Und bei kleinerer Breite als ca. 390 Pixel wandert die Infobox links aus dem Fenster und ich auch per Scrollbar nicht zu erreichen.

In der mobilen Ansicht ist das Icon in der QS-Box immer recht klein, wird aber je nach Fensterbreite noch kleiner. Bei ca. 1070 Pixel Fensterbreite ist IMHO der erste Verkleinerungsschritt des Icons. Dafür skaliert die Infobox brav, da wird nix abgeschnitten und auch das QS-Fenster skaliert ganz nett, das bekommt eine hor. Scrollbar.

Jeweils Firefox, ein verzerrtes Bild wie am Screenshot sehe ich nicht. --Wurgl (Diskussion) 10:21, 10. Jun. 2019 (CEST)

Ich rate erstmal zur syntaktischen Entrümpelung und Modernisierung, und wenn mit aktueller Syntax das Problem weiter besteht, dann mag es näher untersucht werden. Ist aber Angelegenheit der Chemiker; denen ihr Design und Dings. Mängelliste:

• align:center;
  • Ist falsche Syntax; deshalb komplett ignoriert.
  • Gemeint war: text-align:center;
  • Wirkung trotzdem fraglich bei Block-Elementen auf Seitenbreite. Worauf soll es überhaupt wirken, wenn es nioht ohnehin unwirksam wäre?
  • Kann für den Block eigentlich niemals auftreten, es sei denn, der Text wird auf einer Kinoleinwand in einer einzigen Zeile dargestellt.
  • Wenn überhaupt, dann class="center" oder class="centered"
• Tabelle: Schreiben wir in der Vorlagenprogrammierung vollständig mit |- nach {|
  • Jedoch kein Effekt betreffend Problematik.
• <noinclude>
  • Schreiben wir nicht mehr, sondern <onlyinclude>.
  • Jedoch kein Effekt betreffend Problematik.
• Datei:...|zentriert
  • Inhaltlich sinnlos.
  • Wäre in der Tabellenzelle ohnehin am gleichen Ort, weil Text-Zelle sich maximal ausbreiten wird.
  • Möglicherweise ursächlich.
• Barrierefreiheit
  • Gegenüber blinden Benutzern blenden wir nicht weiterhelfende Dekoration aus. Heißt: Icon nur für Sehende.
• Druckausgabe
  • Da zeigen wir eigentlich keine Management-Kästen.
• {{Dokumentation/ruler}}
  • Damit deuten wir den Beginn der Doku und das Ende der Demo an.
• Tabelle in div
  • Vielleicht mal was Hochmodernes: Gar keine Wikisyntax-Tabelle mehr, dafür responsives Design.
  • Vorlage:QS-Statistik
  • Mal mit den fraglichen Geräten deren Einbindungen ausprobieren. Wenn dort Problem futsch, dann in der syntaktischen Struktur der Statistik die Chemie mit deren Texten und Icon und Farben neu aufbauen, und gut ist.

FF --PerfektesChaos 11:05, 10. Jun. 2019 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 17:48, 29. Nov. 2023 (CET)