„Wikipedia:Technik/Werkstatt" – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied Zum nächsten Versionsunterschied →
Inhalt gelöscht Inhalt hinzugefügt
Zeile 2.135: Zeile 2.135:
:# Der Medienbetrachter ist für bildschirmfüllende Fotos und detaillierte Grafiken vorgesehen. Viele Minibildchen, etwa Icons, deren Informationsgehalt bestens auf einen Daumennagel passt, sind von der bildschirmfüllenden Betrachtungsweise ausgenommen.
:# Der Medienbetrachter ist für bildschirmfüllende Fotos und detaillierte Grafiken vorgesehen. Viele Minibildchen, etwa Icons, deren Informationsgehalt bestens auf einen Daumennagel passt, sind von der bildschirmfüllenden Betrachtungsweise ausgenommen.
: VG --[[Benutzer:PerfektesChaos|PerfektesChaos]] 21:01, 27. Mär. 2019 (CET)
: VG --[[Benutzer:PerfektesChaos|PerfektesChaos]] 21:01, 27. Mär. 2019 (CET)

::Wenn ich dich richtig verstehe, ist der Medienbetrachter grundsätzlich nicht gewillt [[Hilfe:TeX|mathematische Formelzeichen]] darstellen, die in der Dateibeschreibung oder im Untertext des eingefügten Bildes sind. In meinem Beispiel habe ich dann allerdings ein Problem. Ich weiß nicht wie ich das Formelzeichen <math>\triangle F</math> sonst darstellen kann. Gibt es hier irgendeine Alternative? --[[Benutzer:Q42xp|Q42xp]] ([[Benutzer Diskussion:Q42xp|Diskussion]]) 21:23, 27. Mär. 2019 (CET)

Version vom 27. März 2019, 21:24 Uhr

Willkommen in der
Technik-Werkstatt

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

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

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

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

Geeignete Fragen sind beispielsweise:

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

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

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

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

Automatische Archivierung
Automatische Archivierung
Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 10 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Die Archivübersicht befindet sich unter Wikipedia:Technik/Archiv .
  • Echo-Filter
  • Weiterleitungshinweis
  • Warnung wenn Zusammenfassung fehlt
  • Shortcut-Tooltip
  • Mehrfach-Sichtungen
  • prettytable und wikitable
  • Schriftgröße 100%
  • Beobachtung nach Karenzzeit beenden
  • Mit Maus verschiebbare große Grafik
  • Suchergebnis direkt anspringen
  • ISBN-Suchbeschleuniger
  • Speicher-Button-Aktionen
  • Wikilink statt URL in Zusammenfassungszeile
  • Hinweis auf Fehler im HTML-Text
  • Fehler im Bearbeitungsfeld hervorheben
  • Hervorhebung bestimmter Wikilinks
  • OSM weltweit
  • collapsible Herausforderung

MediaWiki:Common.js/watchlist.js

Letzter Kommentar: vor 11 Jahren 13 Kommentare4 Personen sind an der Diskussion beteiligt

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

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

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

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

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

Erweiterung der Signatur-Zeitstempel auf Diskuseiten

Letzter Kommentar: vor 11 Jahren 3 Kommentare3 Personen sind an der Diskussion beteiligt

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

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

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

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

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

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

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

class="metadata" und <ref>

Letzter Kommentar: vor 8 Jahren 5 Kommentare2 Personen sind an der Diskussion beteiligt

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

Das HTML-Attribut class="metadata" in den Zellen der rechten Spalte blendet die rechte Spalte aus, aber nichts, was im erzeugten HTML außerhalb dieser Zellen steht. Die mit <ref> erzeugten Fußnoten stehen zwar im Wikitext innerhalb der Tabelle, aber nicht im erzeugten HTML (dort stehen sie im unteren Abschnitt, wo man sie auch sieht).
Als Workaround könnte man <references group="bda"/> durch <div class="metadata"><references group="bda"/></div> ersetzen. Gruß --Entlinkt (Diskussion) 18:09, 21. Nov. 2013 (CET) Beantworten
danke, soweit war ich eben auch schon. Du bist zwischen meine zwei Versuche hineingestolpert, eigentlich wollte ich dafür keine neue group="bda" einführen. lg --Herzi Pinki (Diskussion) 18:18, 21. Nov. 2013 (CET) Beantworten
Okay, aber die Begründung, weshalb das ohne neue Gruppe nicht funktioniert, gilt trotzdem. Dieser Anwendungsfall ist in der Cite-Erweiterung anscheinend nicht vorgesehen. --Entlinkt (Diskussion) 13:37, 24. Nov. 2013 (CET) Beantworten
Hinweis auf diesen Edit, der m. E. zurückgesetzt werden sollte.
An der Sache selbst hat sich aber nichts geändert: <element class="metadata">...<element> blendet nur aus, was innerhalb des Elements steht, und dazu gehören Fußnoten nun einmal nicht. Es wird sich auch niemals etwas daran ändern, da die Fußnoten ein Feature der MediaWiki-Software sind, während class="metadata" ein lokaler CSS-Hack ist, mit dem die MediaWiki-Software nicht rechnet. Es ist technisch unmöglich, diese Konstellation durch eine Erweiterung des lokalen CSS-Hacks zu erkennen, da CSS hierfür nicht ausdrucksstark genug ist.
PS: Ich sehe die Ausbreitung von class="metadata" mittlerweile als Fehlentwicklung an, die geordnet zurückgebaut werden sollte. --Entlinkt (Diskussion) 06:51, 24. Apr. 2016 (CEST) Beantworten

Darstellungsfehler QS-Baustein in Mobilversion

Letzter Kommentar: vor 10 Jahren 6 Kommentare4 Personen sind an der Diskussion beteiligt

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

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

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

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

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 se4598 / ? 15:13, 16. Mär. 2014 (CET) Beantworten

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

Fehler bei dem Anchorjump nach dem Bearbeiten eines Abschnittes.

Letzter Kommentar: vor 10 Jahren 2 Kommentare2 Personen sind an der Diskussion beteiligt

Hi,

ich war drüben[2] und habe woanders[3] zur Sicherheit nochmal nachgefragt und bin deswegen hier gelandet xD

Fehlerwichtigkeit: Keine Auswirkung auf die Stabilität von Wikipedia, Schönheitskorrektur.
Rekonstruktion:
a) Navigiere auf [4].
b) Mache dich mit dem Inhaltsverzeichnis vertraut. Es beinhaltet zweimal die gleichen Unterkategorien bei Desktop als auch bei Mobil.
c) Navigiere nach 1.3 Core i3
d) Klicke hinter dem Schriftzug "Core i3" auf [Bearbeiten]
e) Beobachte, dass in "Zusammenfassung und Quellen:" "/* Core i3*/" steht.
f) Speichere die Seite durch klick auf "Seite speichern"
g) Nachdem die Seite gespeichert wurde, wirst du auf https://de.wikipedia.org/wiki/Liste_der_Intel-Core-i-Prozessoren#Core_i3 weitergeleitet. Dein gerade bearbeiteter
Abschnitt wird also direkt annavigiert. Dies geschieht über den Anchor #Core_i3.
h) Navigiere zum Inhaltsverzeichnis.
i) Navigiere nach 2.3 Core i3
j) Klicke hinter dem Schriftzug "Core i5" auf [Bearbeiten]
k) Beobachte, dass in "Zusammenfassung und Quellen:" "/* Core i3*/ steht.
l) Speichere die Seite durch klick auf "Seite speichern"
m) Nachdem die Seite gespeichert wurde, wirst du auf https://de.wikipedia.org/wiki/Liste_der_Intel-Core-i-Prozessoren#Core_i3 weitergeleitet. Dies ist nicht der gerade von dir bearbeitete Abschnitt. Der von dir bearbeitete Abschnitt wäre https://de.wikipedia.org/wiki/Liste_der_Intel-Core-i-Prozessoren#Core_i3_2.

=> Über die Zusammenfassungszeile ist eine Unterscheidung zwischen den einzelnen Abschnitten nicht möglich, wenn diese Unterabschnitte gleich heißen.
=> Die Weiterleitung soll wohl im zweiten Fall eher auf #Core_i3_2 laufen.

-- Enomine (Diskussion) 07:42, 26. Jul. 2014 (CEST) Beantworten

Dieser Fehler ist bereits seit fast 10 Jahren gemeldet: Bug 111 --Fomafix (Diskussion) 15:17, 26. Jul. 2014 (CEST) Beantworten

Fehlfunktion des Linksymbols oben im Bearbeitungsfenster

Letzter Kommentar: vor 9 Jahren 9 Kommentare4 Personen sind an der Diskussion beteiligt

Wenn ich beim Artikelschreiben eingeloggt bin und einen Begriff mit Hilfe des Linksymbols oben im Bearbeitungsfenster verlinke, fliege ich beim weiteren Schreiben bei der nächsten Betätigung der Zeilensprungtaste aus meinem Wikipediakonto raus. Der eingegebene Text ist verschwunden und das Bearbeitungsfenster des Lemmas geschlossen. Wie kann das sein? Ich habe gestern beim Erstellen eines Textes 10 Versuche gebraucht, den Text fertigzustellen, wobei mir der Text jedesmal gelöscht wurde.--Orik (Diskussion) 00:00, 4. Mai 2015 (CEST) Beantworten

Da empfehle ich Dir: Erstelle Deinen Beitrag in einem externen Editor, schreibe die links von Hand aus, und kopiere das fertige Projekt anschließend in das Bearbeitungsfenster. Da geht Dir der geschriebene Text nicht mehr verloren. J. K. H. Friedgé (Diskussion) 09:49, 4. Mai 2015 (CEST) Beantworten

Wenn ich mit solch laienhaftem Vorgehen, das ich auch versucht habe, zufrieden waere, haette ich mich nicht an die technische Nothilfe gewendet. Waere es nicht passender, die Verlinkungssymbol ( eine Kette) aus dem oberen Rand des Bearbeitungsfensters zu nehmen, um nicht dieses jeden Tag zig-tausendfach auftretende Problem zu vermeiden? Oder man kann ja auch diesen Befehl, der oben am Bearbeitungsfenster sitzt, neu programmieren. Das schöne an dem Werkzeug im Bearbeitungsfenster ist doch, dass ich bereitstehende Symbole verwenden kann und nicht jeden Befehl voll ausschreiben muss. Man kann die Verlinkung auch mit dem Werkzeug am unteren Ende des Berabeitungsfensters machen, das ist nicht ganz so komfortabel, aber geht ohne Probleme. Das obere fehlerhafte Symbol ermöglicht gleichzeitiges Schreiben von Linkziel und einen abweichenden Linktext - - also eigentlich eine gute Einrichtung. --Orik (Diskussion) 10:43, 4. Mai 2015 (CEST) Beantworten
Dass das Problem "jeden Tag zig-tausendfach" auftritt, darf wohl bezweifelt werden, dann gäb's längst jede Menge Beschwerden dazu. Bei mir scheint es jedenfalls nicht aufzutreten. Gerade hier im Abschnitt testweise gemacht: Text eingegeben, Link mit der Bearbeitungsfenster-Funktion gesetzt, Text weitergeschrieben,
Enter gedrückt, weitergeschrieben, Vorschau, alles gut, weitergeschrieben, Speichern, immer noch eingeloggt. Ist das bei dir hier heute noch reproduzierbar? Mit welchem Browser? --YMS (Diskussion) 11:22, 4. Mai 2015 (CEST) Beantworten
Nun denn, du hast offensichtlich den Assistenten zum Einfügen von Links und Tabellen sowie die Funktion „Suchen und Ersetzen" aktiviert (deaktivieren würde also das Problem ertsmal lösen). An sich steckt dahinter eine simple JavaScript-Function, daher ist die Frage nach Browser und System sehr berechtigt.User: Perhelion 14:13, 4. Mai 2015 (CEST) Beantworten
Ich habe den Assistenten wieder demontiert, mal sehen ob es, Zeilensprung

klappt. Ja, ich bin nicht rausgeflogen. Es funkioniert. Danke für den Tip. Ich habe einen Mac, Syst 10.6.8 und den Safaribrowser 5.1.10 ( alles neuestmögliche Software). Gruss --Orik (Diskussion) 17:36, 4. Mai 2015 (CEST) Beantworten

Kann nicht irgendjemand den Verlinkungsasistenten wieder in Gang bringen! Orik (Diskussion) 22:34, 5. Mai 2015 (CEST) Beantworten
Da müsste man wohl einen Bugreport öffnen: WP:PHAB User: Perhelion 23:10, 5. Mai 2015 (CEST) Beantworten
Meine Meldung war die eines absoluten Laien in der Technikwerkstatt. Konnte mal jemand den Bugreport vorschriftsmäßig machen? Das wäre schön. Orik (Diskussion) 04:57, 6. Mai 2015 (CEST) Beantworten

Falscher Abschnitt in Zusammenfassungszeile bei mobilen Bearbeitungen

Letzter Kommentar: vor 9 Jahren 4 Kommentare2 Personen sind an der Diskussion beteiligt

Wieso erscheint in der Zusammenfassungszeile dieses Beitrags „(→‎Einzugsgebiet)", obwohl Du dich zum Streaming-Portal geäußert hast? Gruß und weiterhin viel Spaß Peter 19:46, 3. Jun. 2015 (CEST) Beantworten

Weil aus mir unerfindlichen Gründen ich bei der mobilen Anwendung ein paar Abschnitte höher bearbeiten muss, damit es am eigentlichen Ziel ankommt. Frag die Software-Entwickler, warum das so ist.--Gruß Kriddl Bitte schreib mir etwas. 09:03, 4. Jun. 2015 (CEST) Beantworten

übertragen von Benutzer Diskussion:Kriddl#Zusammenfassungszeile und mit typographischen Anführungszeichen in meiner eigenen Frage ergänzt.

Das Phänomen habe ich nicht nur bei ihm bemerkt. Gruß und Dank Peter 09:08, 4. Jun. 2015 (CEST) Beantworten

Es nervt noch immer: Spezial:Diff/145198668 -- Peter 17:58, 19. Aug. 2015 (CEST) Beantworten

Referenzen in der TOC

Letzter Kommentar: vor 9 Jahren 10 Kommentare4 Personen sind an der Diskussion beteiligt

Hallo! Man hat mir eine Version mit einer Referenz in ref-Tags im Artikel-Abschnittstitel gezeigt, die in der TOC ausgepackt wird. Ich habe mir die Version mal auf meine Spielwiese geholt: user:TaxonBot/Schweizer Armee Zum Probieren dürft Ihr den Artikel dort gerne bearbeiten

Problem:

  • in einer Abschnittsüberschrift wurde eine Referenz in ref-Tags editiert. Sieht so aus:
    Panzer der Schweizer Armee [28]
    === Panzer der Schweizer Armee <ref>Urs Heller: ''Die Panzer der Schweizer Armee von 1920 bis 2008.''</ref> ===
    
  • in der TOC wird der Inhalt der Referenz ausgeschrieben. Sieht so aus:
    9.3 Panzer der Schweizer Armee <ref>Urs Heller: ''Die Panzer der Schweizer Armee von 1920 bis 2008.''</ref>

Ich meine mich zu erinnern, dass dies schon mal anders funktionierte. Die ref-Nr. wird zwar in der Abschnittsüberschrift, wie es auch sein soll, angezeigt. In der TOC wird aber weder die ref-Nr. noch die Referenz selbst und schon gar nicht die ref-Tags angezeigt. Oder irre ich mich jetzt da. Schönen Dank – Doc TaxonDiskussionWiki-MUC19:52, 7. Jun. 2015 (CEST) Beantworten

Das passiert kurioserweise nicht in den Anm-ref mit group bei Liste der Herrscher Koreas.
Hingegen auch bei: Joseon-Dynastie, Olmütz, Beşiktaş Istanbul, Diakon.
Syntaxfehler zuvor, die das beeinflussen könnten, sind nicht auffindbar.
2.747 Treffer
Sieht nach Bastelei an der Extension aus; mal Phab flöhen. Funktionierte früher; war aber noch nie erwünscht gewesen.
LG --PerfektesChaos 21:07, 7. Jun. 2015 (CEST) Beantworten
@PerfektesChaos: würdest Du das in den Phabricator kritzeln, mir ist das Ding zu unübersichtlich - keine Ahnung, wie das funktioniert – Doc TaxonDiskussionWiki-MUC23:02, 7. Jun. 2015 (CEST) Beantworten
Ich hab auch ’ne andere Agenda; aber es betrifft nicht nur uns, sondern Hunderte Wikis weltweit. Wird schon jemand von der enWP gemeckert haben.
Die Extension ist bekannt dafür, dass sie bestimmte Syntax innerhalb des ref nicht mehr richtig parsed; ist ein zehn Jahre alter Bug. Diesmal hat sie entweder einen weiteren Kinken abbekommen, oder die Verarbeitung von Überschriften wurde verändert und Wikisyntax innerhalb von Überschriften arbeitet nicht mehr. Gegen letzteres spricht group bei Liste der Herrscher Koreas.
Die Extension ist sowieso buggy, verpennt und schweigsam wie nur was; wundert mich nix.
LG --PerfektesChaos 23:12, 7. Jun. 2015 (CEST) Beantworten
na dann probier ich das mal irgendwie mit dem Phabricator – Doc TaxonDiskussionWiki-MUC23:56, 7. Jun. 2015 (CEST) Beantworten
Ticket im Phabricator ist vorhanden (und Hilfe zu Phabricator gibt es auch). --AKlapper (WMF) (Diskussion) 00:29, 8. Jun. 2015 (CEST) Beantworten
@AKlapper (WMF): Ja, mit der Hilfe hab ich es versucht. Eine Meldung damit anzulegen ist mir dennoch nicht geglückt. Ich habe den "Assigned To" nicht gewusst und auch "Projects" (de:wp ?) in der Liste nicht gefunden. – Doc TaxonDiskussionWiki-MUC02:49, 8. Jun. 2015 (CEST) Beantworten
Assigned To darf gern freibleiben und Projects kann auch freibleiben wenn man keine Idee hat. Das ist wahrscheinlich besser auf mw:How to report a bug beschrieben. --AKlapper (WMF) (Diskussion) 10:30, 8. Jun. 2015 (CEST) Beantworten
"Assigend To": Ein Task ist häufig jemand zugeordnet, wenn er gerade daran arbeitet oder ein Patch eingestellt hat und somit gearbeitet hat. Ein neuer Task wird im Normalfall nicht zugeordnet, dadurch landet er im großen Topf, aus dem sich jeder bedienen kann. Project wäre in diesem Fall "MediaWiki-extension-Cite", weil die Refs aus der mw:Extension:Cite stammen (Muss man nicht wissen, daher frei lassen). Der Umherirrende 17:46, 8. Jun. 2015 (CEST) Beantworten

In der Hauptsache: Die Änderung wurde rollbacked, war schon vor diesem Thread in der enWP aufgefallen.

  • Welches project? WP:PHAB/T und nach <ref suchen.

LG --PerfektesChaos 16:38, 12. Jun. 2015 (CEST) Beantworten

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

Letzter Kommentar: vor 9 Jahren 10 Kommentare5 Personen sind an der Diskussion beteiligt

Ich benutze Schnarks kombiniertes PD&ND-Skript derzeit extrem oft. Seit gestern nachmittag kann ich aber plötzlich nur noch die ND bearbeiten, aber nicht mehr die PD. Ich habe zwar Schnark gestern abend auf seiner Seite gefragt, woran es liegen könnte, aber bisher keine Antwort bekommen (auch kein Wunder, so lange ist das ja noch nicht her). Trotzdem frage ich hier nach, weil es für meine derzeitige Arbeit sehr wichtig ist. Ich habe gehört, dass immer Donnerstags Wikipedia-Patchday sei, kann es damit zusammenhängen? MfG --Informationswiedergutmachung (Diskussion) 11:09, 26. Jun. 2015 (CEST) Beantworten

Es wird möglicherweise an der Änderung von Modul jquery.mwExtension zu Modul mediawiki.RegExp liegen. Schnark verwendet zwar mw.loader.using('jquery.mwExtension'), aber vielleicht ist irgendwo etwas vergessen. Hast Du unter Spezial:Einstellungen#mw-prefsection-editing die Option „Erweiterte Bearbeiten-Werkzeugleiste aktivieren" aktiviert. Der WikiEditor lädt derzeit noch jquery.mwExtension. Vielleicht hilft das übergangsweise. --Fomafix (Diskussion) 11:28, 26. Jun. 2015 (CEST) Beantworten
Ich hatte gestern Abend für einige Stunden ein vergleichbares Problem, das sich heute morgen entmaterialisert hatte (phab:T103891).
  • Browser-Cache heftig löschen.
  • Wenn du kannst, mal vorübergehend mw.loader.store.clear(); vorn in deine common.js einbauen.
  • Wenn du kannst, WP:JS#Fehlerkonsole nutzen und uns mögliche Details benennen.
Schnark schaut erfahrungsgemäß morgen früh rein.
Um die Ausgangsfrage zu beantworten: Ja, kann es. Der Plan von Fomafix ist nachvollziehbar.
VG --PerfektesChaos 12:02, 26. Jun. 2015 (CEST) Beantworten
"Erweiterte Bearbeiten-Werkzeugleiste aktivieren" war schon aktiviert, den Cache habe ich geleert, den mw.loader.store.clear(); eingebaut. Funktioklappt aber trotzdem nicht. Und mit WP:JS#Fehlerkonsole kenne ich mich so gut wie gar nicht aus. Nun ja, muss ich auf Schnark warten, danke für die Antworten. MfG --Informationswiedergutmachung (Diskussion) 12:20, 26. Jun. 2015 (CEST) Beantworten
Es liegt daran, dass das Modul 'jquery.mwExtension' verwendet wird, bevor es geladen ist. Das Modul war vor der Änderung wohl standardmäßig bei jedem Artikel geladen, so dass die fehlende Abhängigkeit nicht aufgefallen ist. Jetzt wird das veraltete Modul nicht mehr geladen und dann gehen teilweise Skripte kaputt. Ich vermute aber, das alle diese Skripte auch schon vorher die Abhängigkeit nicht eindeutig deklariert hatten. (gerrit:219570, Abhängigkeit war sonst über 'mediawiki.util.js' immer gegeben, weil das Modul immer da ist). @Schnark: müsste migrieren oder die Abhängigkeit ergänzen (oder beides). Der Umherirrende 16:39, 26. Jun. 2015 (CEST) Beantworten
so wie es jetzt ist, ist es jedenfalls unbrauchbar. Mit Hand PD nachtragen oder sie zu überprüfen führt zu einem viel zu hohen Arbeitsaufwand. Gestern habe ich Gustav Laddey erstellt, üblicherweise brauche ich für einen Artikel (ohne Schreibfehlerkorrektur) genau zwei Edits: einen, um ihn neu reinzustellen und einen, um ihn mit PD & ND zu ergänzen. Das dauert keine Minute, gestern habe ich dafür fünf Minuten gebraucht. Die Bitte geht daher an Schnark das nach Möglichkeit schnell zu ändern, u.a. weil ich diese Liste (4.587 Fehler, noch) schnellstmöglich abarbeiten will. Zwar funktioniert das ND-Tool, aber oft genug sind die PD auch ungenügend und zweimal alles abarbeiten wäre reine Zeitverschwendung. --Informationswiedergutmachung (Diskussion) 17:36, 26. Jun. 2015 (CEST) Beantworten
@Umherirrender: Verwende ich es denn irgendwo ohne die Abhängigkeit korrekt zu deklarieren? Für mich sieht es so aus, als handle es sich nur um Fehler in anderen Skripten, die dann halt auch meine beeinträchtigen. (Was nicht heißt, dass ich die Funktion nicht dringend ersetzten sollte, mein Testskript, das mich über Deprecations unterrichtet, dreht gerade durch und spuckt 8825 Warnungen aus.) --Schnark 09:52, 27. Jun. 2015 (CEST) Beantworten
@Schnark: Ich bin gestern auf eine Artikelseite einer Person gegangen und habe in der Konsole importScript( 'Benutzer:Schnark/js/personendaten.js' ); geschrieben, damit dein Skript geladen wird. Anschließend gab es "Das Objekt unterstützt die Eigenschaft oder Methode "escapeRE" nicht" in der Funktion wo staatenRe aufgebaut wird. Daraus habe ich geschlossen, dass die Funktion dann nicht zur Verfügung steht, wenn sie gebraucht wird. Du lädst die Funktion, aber anscheinend wird sie auch schon bei der Initialisierung benötigt und stand dann nicht zur Verfügung. IE11. Nach deiner Änderung funktioniert wieder alles ohne Fehler. Der Umherirrende 10:28, 27. Jun. 2015 (CEST) Beantworten
Ups, du hast recht. Sollte jetzt korrigiert sein. --Schnark 10:36, 27. Jun. 2015 (CEST) Beantworten
Guten Morgen, ich vestehe zwar euer Fachchinesisch nicht so ganz, aber: das PD-Tool funzt bei mir immer noch nicht wieder. MfG --Informationswiedergutmachung (Diskussion) 11:49, 27. Jun. 2015 (CEST) Beantworten
Letzter Kommentar: vor 9 Jahren 9 Kommentare4 Personen sind an der Diskussion beteiligt

Hallo,

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

Ähnlich wie bei BKL geht es sicher nicht - dort hilft die Mediawiki-Software und gibt den Links eine Kennzeichnung, die dann nur noch sichtbar gemacht werden muss. Ein solches Script müsste sich irgendwo extern eine Liste der erstellten Seiten holen und dann jeden Link mit dieser Liste abgleichen. Wenn es dir um die Artikel geht und nicht um Links darauf, wieso nicht einfach diese Liste der erstellten Seiten durchgehen? Links auf relevante Personen sind fast immer sinnvoll, selbst wenn es den Artikel gar nicht gibt. --mfb (Diskussion) 11:46, 26. Nov. 2015 (CET) Beantworten
Hilft dir evtl. diese Suche weiter? Wassertraeger  12:19, 26. Nov. 2015 (CET) Beantworten
Es geht nicht darum, dass Personen relevant sind. Es geht darum, wie Artikel eines gewissen Benutzers aussehen und diese möchte ich einfach nicht mehr ansehen. --Der Buckesfelder  Disk.   bewerten   E-Mail 12:48, 26. Nov. 2015 (CET) Beantworten
Ach so, also exakt das Gegenteil der Suche die ich vorgeschlagen habe. Eine ignore-Funktion quasi. Ja, die möchte ich auch bei einigen haben. Ärgern Dich die Boxer denn so sehr? --Wassertraeger  12:57, 26. Nov. 2015 (CET) Beantworten
Du könntest etwas analog zu Benutzer:Mfb/monobook.css anlegen (ganz unten), braucht dann eine lange Liste aller (~700) Artikel, die manuell aktualisiert werden muss, und wird vermutlich das Laden von Seiten merklich verlangsamen. Testobjekte: Luis Alberto Pérez (Boxer), Robbie Regan, Lee Haskins. --mfb (Diskussion) 13:24, 26. Nov. 2015 (CET) Beantworten

@Buckesfelder:

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

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

@PerfektesChaos: Danke für die ausführlichen Informationen. Leider kann ich das (noch) nicht, ab der Ehrgeiz hat mich gepackt und irgendwann habe ich das dann auch (hoffentlich umgesetzt).
Zur {{Internetquelle}}: Das Problem waren nicht die Altlasten. Die wandle ich ich eigentlich, sofern ich den Link bearbeite, in YY-MM-DD um. Vielmehr hatte der Vorlagenmeister Probleme mit neueingegebenen Daten in dem oben genannten Format. Ich konnte leider noch nicht herausfinden woran das liegt, hatte das aber noch vor. Doch durch nervende Stubs und vielen Diskussionen auf WP:VM, WP:QS usw. hatte ich einfach keine Lust und Reiz mehr. Deshalb war ich so egoistisch und habe die entsprechenden Zeilen einfach gelöscht. Falls du eine Idee hast, woran das liegen könnte, nur her damit. Grüße --Der Buckesfelder  Disk.   bewerten   E-Mail 13:07, 27. Nov. 2015 (CET) Beantworten
@Skript-Idee:
  • Alle aufgelisteten Regeln sollten nicht nur auf Wikilinks vom momentanen Artikel aus gelten, sondern auch für die momentane Seite selbst. Da müsste dann im Seitenkopf ein Kasten angezeigt werden.
  • Eine weitere Regel könnte sein: Benutzer X hat innerhalb der letzten 50/100/500 Bearbeitungen (maximal 30/90/1000 Tage zurück) die Seite bearbeitet.
  • Ein Teil der Regeln eignet sich dazu, lokal zur Beschleunigung gespeichert zu werden (Seitenersteller, werden keine 10.000 sein; was beobachte ich? – Seiten in Kategorie/Unterkat); andere wie diese eben müssten live abgerufen werden.
  • Nicht nur Benutzer-Nicks, sondern auch IPv4-Ranges.
  • Bei hinreichender Flexibilität in Sachen Regeln würde ein solches Werkzeug in interessierten Kreisen durchaus Anklang finden.
@Vorlagenmeister:
  • Ich hatte dieses Vorlagenmeister vor einem Jahr geschrieben, damals erfolgreich getestet und seitdem alles vergessen. Ich werde mich, wenn ich mal einen Block konzentrierte Zeit habe, auf BETA an eine Rekonstruktion des von dir geschilderten Problems machen. Wohl eher Jahreswechsel.
LG --PerfektesChaos 13:29, 27. Nov. 2015 (CET) Beantworten

Probleme bei der PDF- bzw. Buchherstellung

Letzter Kommentar: vor 9 Jahren 2 Kommentare2 Personen sind an der Diskussion beteiligt

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

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

Shared tabular data storage for Commons!

Letzter Kommentar: vor 8 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt

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

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

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

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

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

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

Letzter Kommentar: vor 8 Jahren 7 Kommentare3 Personen sind an der Diskussion beteiligt

Hallo,

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

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

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

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

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

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

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

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

Die „Design-Ziele" meines Entwurfs sind folgende:

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

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

Statt prependTo fände ich appendTo logischer (auch wenn es in der Praxis keinen Unterschied machen sollte). Der Form halber wäre es zudem schön, wenn es zumindest ein Phabricator-Ticket gäbe, in dem darum gebeten wird, die indicator-Methode überall möglich zu machen, dieses beim Code erwähnt wird und dann natürlich auch die Seiten umgestellt werden, wo kein JS zur korrekten Anzeige mehr notwendig ist. Ansonsten volle Zustimmung von meiner Seite. --Schnark 09:32, 12. Mai 2016 (CEST) Beantworten
Der Beweggrund für prependTo war folgender: Die <indicator>-Elemente sind ja rechtsbündig ausgerichtet und das Skript würde den Hilfe-Link dort hinzufügen. Wenn eine Spezialseite aus irgendeinem Grund ein „echtes" <indicator>-Element enthält, würde ein appendTo des Hilfe-Links dazu führen, dass das „echte" <indicator>-Element während des Ladevorgangs wahrnehmbar nach links rutscht. Mit prependTo wird dieser Effekt vermieden. In der Praxis tritt so eine Konstellation aber derzeit eh nirgends auf.
Ein Phabricator-Task wäre sicher gut, aber ich bin nicht sicher, was drin stehen sollte. Man könnte anregen, dass die <indicator>-Methode in den betroffenen Systemnachrichten verfügbar gemacht wird, aber man könnte auch anregen, dass jede betroffene Spezialseite einen MediaWiki-eigenen Hilfe-Link erhält (was gemäß phab:T45591 vermutlich prinzipiell erwünscht ist). Beides würde unsere Probleme lösen, aber ich fände es etwas dreist, gleich beides anzuregen.
Was mich noch interessieren würde, wäre die Sicherheit. Ist der konkret vorgeschlagene Code dahingehend problematisch? Es werden ja Elemente ungeprüft verschoben, was bei benutzergenerierten Inhalten grundsätzlich problematisch sein kann, allerdings kenne ich benutzergenerierte Inhalte auf Spezialseiten nur auf Special:ExpandTemplates.
Wenn man diese Lösung aktivieren würde, sollte das dann ein hidden-Gadget sein oder sollte der Code direkt in MediaWiki:Common.js stehen? Viele Grüße --Entlinkt (Diskussion) 13:01, 12. Mai 2016 (CEST) Beantworten
Bei appendTo vs. prependTo war meine Überlegung, was passiert, wenn auf einer Spezialseite dynamisch Inhalt hinzugefügt wird, der .specialpage-helplink-Elemente enthält. Das sollte zwar auch nirgendwo vorkommen, aber in dem Fall wäre es logischer, die neuen Elemente anzuhängen.
DOM-Elemente zu verschieben sollte keine Sicherheitsprobleme erzeugen. Da sehe ich keine Probleme. Die ISBN-Suche kann übrigens auch von autoconfirmed-Benutzern bearbeitet werden.
Zu Gadget vs. Common.js: Der Code muss ohnehin auf allen Seiten geladen werden (die Abfrage, ob man sich auf einer Spezialseite befindet vom eigentlichen Code zu trennen, wäre wohl zu ineffizient), da der Code aber immer auf das mediawiki.helplink_Modul warten muss, gäbe es selbst mit einem im Seitenkopf geladenen Gadget keinen flackerfreieren Aufbau. Damit spielen die beiden Hauptgründe für eine der beiden Methoden keine Rolle. Wenn es ein Gadget wird, dann sollte in Common.js zumindest ein Kommentar, der darauf hinweist, damit Benutzer, die an der klassischen Stelle nach dem Code suchen ihn auch finden. --Schnark 10:37, 13. Mai 2016 (CEST) Beantworten
OK, vielen Dank soweit. Aber noch eine Frage:
Eigentlich muss der Code gar nicht immer auf das Modul mediawiki.helplink warten, da dies nur CSS enthält, das nur gebraucht wird, wenn ein .specialpage-helplink-Element vorhanden ist. Ist es überhaupt korrekt, diese Beziehung durch eine Abhängigkeit auszudrücken? Man könnte auch (analog zu dem Nachladen von jquery.ui.button in MediaWiki:Common.js) zuerst die Seite analysieren und es nur laden, wenn mindestens ein .specialpage-helplink-Element da ist. Oder wäre dann ein FOUC zu befürchten?
@Umherirrender: Vielleicht kannst du auch noch etwas dazu sagen, da du die Systemnachricht erstellt hattest? Vor allem würde mich interessieren, warum <indicator> an manchen Stellen nicht geht, wie aufwendig es wäre, das zu ändern und ob es überhaupt sinnvoll ist, diesbezüglich eine Änderung anzuregen.
Sorry für die vielen Fragen, aber ich kenne mich da nicht so aus und möchte vermeiden, dass etwas falsches/suboptimales gemacht wird. Gruß --Entlinkt (Diskussion) 10:54, 13. Mai 2016 (CEST) Beantworten
Mit einem Nachladen statt der Abhängigkeit hätte man (vermutlich, ausprobiert habe ich es nicht) einen en:FOUC, was vermutlich (auch das habe ich nicht probiert) wesentlich störender wäre, als ein leicht verzögertes Auftauchen. --Schnark 11:11, 13. Mai 2016 (CEST) Beantworten
Angefangen hat es hier, als es mehr wurde habe ich eine Vorlage raus gemacht, damit es überall gleich aussieht.
Technische Hintergrund: Das indicator-tag gehört (wie auch ResourceLoader-Module) zu den Metadaten des Output-Objects in MediaWiki. Beim parsen von Systemnachrichten werden diese Metadaten nicht verwendet, sondern nur der Text. Das führt dazu, dass die indicator-Tags in Systemnachrichten nicht funktionieren. Beim TOC ist es ähnlich, da das JS-Modul für das ausblenden zu den Metadaten hinzugefügt wird, ist es auf Spezialseiten nicht vorhanden (T66969). Meine Lösung war mal gerrit:196626, es gibt aber zu viele Bedenken wegen Seiteneffekte.
Am besten wäre es, wenn der generische Systemnachricht-Name zum überschreiben der Helplinks auf allen Spezialseiten funktionieren würde und standardmäßig nur leer ist, dann braucht es kein JS. Dies werde ich mal ausprobieren. Der Umherirrende 15:30, 13. Mai 2016 (CEST) Beantworten

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

Letzter Kommentar: vor 8 Jahren 5 Kommentare3 Personen sind an der Diskussion beteiligt

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

Ist wohl ein Softwarebug. Hat nichts mit Vorlagen zu tun, die gleiche Spezialseite doppelt mit verschiedenen Parametern direkt einzubinden ergibt das gleiche merkwürdige Verhalten. Die ungesichteten Seiten können je nach Reihenfolge einzeln erscheinen, aber die anderen beiden sind immer gleich, egal in welcher Reihenfolge. --mfb (Diskussion) 19:20, 30. Aug. 2016 (CEST) Beantworten
{{Spezial:Änderungen_an_verlinkten_Seiten|days=90|target=Portal:Amateurfunkdienst/Artikelliste|limit=6}}
{{Spezial:Änderungen_an_verlinkten_Seiten|days=90|target=Portal:Amateurfunkdienst/Artikeldiskussionsliste|limit=4}}
{{Spezial:Änderungen an verlinkten Seiten|days=90|namespace=0|target=Portal:Amateurfunkdienst/Artikelliste|hideReviewed=1|limit=6}}
Ich habe mal mit gerrit:308144 einen Software-Änderungs-Vorschlag gemacht. Mal schauen, ob das so angenommen wird. Der Umherirrende 12:00, 2. Sep. 2016 (CEST) Beantworten
@Umherirrender: Danke! Scheint ein globaler MediaWiki Bug zu sein. Nach gerrit:281174 ist der Bug auch bei anderen specialpages, die multipel inkludiert sind zutreffend. Gruß --vy 73 de Ptolusque AFu 18:18, 2. Sep. 2016 (CEST) Beantworten

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

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

Letzter Kommentar: vor 8 Jahren 16 Kommentare7 Personen sind an der Diskussion beteiligt
Gemeldet in Phabricator
Task T4700

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

Bereits lange bekannter Bug, siehe phab:T4700 und gerrit:272916. -- hgzh 15:13, 17. Okt. 2016 (CEST) Beantworten
(BK)
Das ist schon seit einem Dutzend Jahren so; oder seit es die jeweiligen Extensions gibt.
Siehe H:L#Pipe-Trick
Grund: In einer Extension erfolgt kein Reparsing des Wikitextes mehr, und der Pipe-Trick war schon vorher dran gewesen.
Abhilfe: Vorschau benutzen, oder wenigstens nach dem Speichern noch mal drübergucken; so auch Spezial:Diff/155228444 Spezial:Diff/155727135 Spezial:Diff/157814009 Spezial:Diff/158200970 Spezial:Diff/158493844.
@Flominator: FYI qed
VG --PerfektesChaos 15:18, 17. Okt. 2016 (CEST) Beantworten
Das weiß ich mittlerweile selber. Aber diese Arbeitserleichterung war vor einiger Zeit sogar mal Tipp des Tages. Man sollte den Bug mal langsam abstellen - es wird mehr werden und die wenigstens der Fehler sind von mir. Übrigens: nettes Nerd-Kauderwelsch: In einer Extension erfolgt kein Reparsing des Wikitextes mehr, und der Pipe-Trick war schon vorher dran gewesen. :) --Informationswiedergutmachung (Diskussion) 15:30, 17. Okt. 2016 (CEST) Beantworten
Ach ja: 64 Subscribers seit 2005 und nüschts geht? Wem muss man das Hinterteil denn nun abknutschen, dass dieser Uraltbug mal bearbeitet wird? --Informationswiedergutmachung (Diskussion) 15:32, 17. Okt. 2016 (CEST) Beantworten
  1. Ich kann nichts dafür, dass jemand solch brisantes Zeugs auch noch zum Tdt macht.
  2. Mir wäre es lieber, dass auch auf der Hilfeseite nicht für sowas Reklame gemacht werden würde.
  3. Bei den Extensions wird der Inhalt zwischen den H:Tags herausgeschnitten, von dieser intern verarbeitet und das Resultat hinterher in die ansonsten fertige Wiki-Seite einkopiert. Alles, was ansonsten noch auf der Seite passiert, bekommt eine Extension grundsätzlich nicht mit, so auch nicht diesen gefährlichen Trick. Aussicht darauf, dass sich hieran etwas ändert, gibt es wenig, weil der Pipe-Trick zum Kern gehört und die Extension eben gerade außerhalb des Kerns liegt und ihr eigenes Ding macht. Die Architektur der Seitenaufbereitung wird zwar in diesen Jahren grundlegend umprogrammiert, aber das betrifft nur den Kern.
VG --PerfektesChaos 15:39, 17. Okt. 2016 (CEST) Beantworten
Muß man als Technik-Nerd, der ich bin, irgendwie nicht verstehen. Ich verstehe es auch nicht wirklich, aber das man sowas 11 (!) Jahre nicht in den Griff bekommt... Nun ja. Kein echtes Ruhmesblatt für die Wikipedia... --Informationswiedergutmachung (Diskussion) 15:46, 17. Okt. 2016 (CEST) Beantworten
Eher für MediaWiki. Auch wenn man es schaffen würde diesen Bug zu fixen, würde das viele Seiteneffekte haben, die dann wieder als Bug aufgenommen werden sollen, obwohl es Features sind. Alle Tags (also alles mit spitzen Klammern was nicht HTML ist) wird identisch verarbeitet, aber bei pre oder nowiki will man vielleicht kein Pipe-Trick, da sie die Texte so darstellen sollen wie man sie übergeben hat. Man muss also Sachen die identisch behandelt werden, so trennen das es weiterhin das gewünschte Ergebnis liefert. Diesen Fix muss man dann noch ganz tief ins Herzstück der Wikitext-Verarbeitung platzieren. Da traut sich keiner der Freiwilligen dran und den bezahlten ist es vielleicht auch zu heikel. Der Umherirrende 18:49, 17. Okt. 2016 (CEST) Beantworten
@Leyo: Zur Kenntnisnahme. MfG --Informationswiedergutmachung (Diskussion) 18:55, 17. Okt. 2016 (CEST) Beantworten
Von den ursprünglich 70 Treffern sind nun bis auf 19 (zumeist in Kommentaren) alle gefixt. --Leyo 22:25, 17. Okt. 2016 (CEST) Beantworten
Ich versuche mal noobverständlich zu formulieren, was das Problem ist, weil ich's bis eben auch noch nicht verstanden hatte und einen ganz offensichtlichen Vorschlag machen wollte: Wenn der Benutzer auf "Änderungen speichern" drückt wird der Artikelquelltext an den Server gesendet. Dort wird dann der Pipe-Trick (genauso wie {{subst:) schon aufgelöst, und erst danach die Seite gespeichert. Wenn die Seite danach aufgerufen wird, liest der Server die gespeicherte Seite und verarbeitet die ganze restliche Wikisyntax, also u.A. Vorlagen, solche Tags wie <ref>, <gallery> oder <math>, und die Links selbst. --nenntmichruhigip (Diskussion) 21:21, 17. Okt. 2016 (CEST) Beantworten
Du hast schon ein Beispiel geliefert warum man nicht einfach subst und pipe-Trick vor dem Speichern auflösen kann. Nowiki würde nicht mehr funktionieren. Aus diesem Grund wird bereits vor dem Speichern (bzw. vor dem pst - pre-save-transform - "Vor-Speichern-Umwandlung") die Tags interpretiert und das führt zu diesem Ergebnis. Der Umherirrende 22:08, 17. Okt. 2016 (CEST) Beantworten
Oh, stimmt, ich habe beim Schreiben ein paar Sätze vergessen :-) Ich versuche mal sie noch zu retten, wird jetzt evtl leider nicht ganz so noobfreundlich. --nenntmichruhigip (Diskussion) 22:22, 17. Okt. 2016 (CEST) Beantworten
Die Inhalte der Mediawiki-Tags müssen bei der Transformation vor dem Speichern ignoriert werden, weil es bei deren Inhalt sehr wahrscheinlich ist, dass er anders interpretiert werden muss (z.B. <nowiki>, <math>). Wenn dann beim verarbeiten der restlichen Wikisyntax die Mediawiki-Erweiterung, die für die Verarbeitung dieser Tags zuständig ist, sagt "übersetze mir diesen Quellcode" wird er genauso verarbeitet wie der sonstige Quellcode nach dem Speichern. --nenntmichruhigip (Diskussion) 22:22, 17. Okt. 2016 (CEST) Beantworten

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

  • Klar, einfach WSTM anklicken.
  • Die Analyse ist allerdings hochkomplex, muss nowiki, syntaxhighlight und HTML-Kommentare sowie Vorlagensyntax berückschtigen. Mal so eben regexpen wird nix.
LG --PerfektesChaos 13:46, 18. Okt. 2016 (CEST) Beantworten

Sonderzeichen

Letzter Kommentar: vor 8 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt

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

Anzeige von Änderungen

Letzter Kommentar: vor 8 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt

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

Einzelnachweise im Bild

Letzter Kommentar: vor 8 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt

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

Interaktive Karten auf Wikipedia

Letzter Kommentar: vor 5 Jahren 10 Kommentare5 Personen sind an der Diskussion beteiligt
Screenshot einer eingebettet interaktiven Karte.

Hallo,

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

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

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

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

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

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

Topografie --kogo (Diskussion) 23:18, 13. Dez. 2016 (CET) Beantworten
erstmal ist es gut, wenn das Feature aktiviert wird. Ob es dann genutzt wird, ist ja nochmals eine andere Frage. Meine Punkte
  • In Polnähe bietet Kartographer keinen Ersatz für die bisher verwendeten Postionskarten, vergleiche [[8]] (dort den Link folgen) und Südpol / Lage der verschiedenen Südpole. An einigen Stellen (z.B. Infoboxen) wird nicht nach Breitengradregionen unterschieden, d.h es würde die Einsetzbarkeit von Kartographer erst ermöglichen, wenn in den Polregionen die entsprechenden Projektionen verwendet würde und nicht die dort unsinnige (vermutlich) Zylinderprojektion.
  • Kartographer unterstützt keine beliebigen labels, nur einfache ASCII-Zeichen.
  • In WP:de werden je nach Anwendungsfall politische oder topographische Karten (relief) eingesetzt. Um das abzubilden bräuchte Kartographer eine Möglichkeit das zu steuern und je nach Kontext andere Basis-Kartentypen einzublenden bzw. einen einfache Umschaltmöglichkeit in der Karte selbst.
  • generell die Diskussion Hilfe Diskussion:Kartographer beachten.
  • Ich denke, dass ob er Komplexität der Schnittstelle eine direkte Einbindung in Artikel in WP:de eher nicht gewünscht ist.
  • @CKoerner (WMF): I hope you understand the German here.
lg --Herzi Pinki (Diskussion) 01:03, 16. Dez. 2016 (CET) Beantworten
Ja, mein Deutsch ist nicht so gut, aber ich verstehe. Ich warden lasse die Gruppe Ihre Bedenken wissen. Vielen Dank! CKoerner (WMF) (Diskussion) 16:09, 16. Dez. 2016 (CET) Beantworten

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

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

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

тнояsтеn I wish I had more to tell you. Leadership at the foundation is investigating what it would take to better support Maps. I hope to have more information early in the new year. CKoerner (WMF) (Diskussion) 22:58, 15. Dez. 2017 (CET) Beantworten
User:CKoerner (WMF), it's 2019 and it seems nothing happened... Hilfe Diskussion:Kartographer#Aktivierung von Mapframe points to phab:T138057. Any WMF activities on this topic? --тнояsтеn 08:28, 20. Feb. 2019 (CET) Beantworten
тнояsтеn, A little update. We now have a few folks keeping the maps infrastructure running and responding to bug reports. However the issue with flagged revisions persists. I'll ask if there's more information on the task. CKoerner (WMF) (Diskussion) 00:00, 21. Feb. 2019 (CET) Beantworten

Formeldarstellungsfehler (LaTeX) mit Android

Letzter Kommentar: vor 8 Jahren 3 Kommentare2 Personen sind an der Diskussion beteiligt

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

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

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

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

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

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

Bei mir auf dem Desktop-Firefox sind die Formeln in der Einleitung ganz normal, und die dartuner (die bei dir zu klein sind) werden erst sehr viel später, also wohl per Javascript, nachgeladen. Möglicherweise besteht da irgendein Zusammenhang. Wegen Links auf externe Bilder oder Foren: Bei solchen Einträgen zur Problembehebung ist das idR in Ordnung :-) --nenntmichruhigip (Diskussion) 12:19, 28. Jan. 2017 (CET) Beantworten
Danke für die Hinweise. Dann füge ich auch gerade mal die Links bei, mit Bild :).
- http://www.matheboard.de/thread.php?threadid=572681
- http://www.matheboard.de/thread.php?postid=2080897#post2080897
Hoffe das hilft weiter. --Equester 14:36, 28. Jan. 2017 (CET) (ohne Benutzername signierter Beitrag von 1.124.48.156 (Diskussion))
Unten gab es eine weitere Meldung dazu, bei der auch ein paar Phab-Tickets verlinkt wurden. --nenntmichruhigip (Diskussion) 20:49, 8. Feb. 2017 (CET) Beantworten

JavaScript für Anzahl an Verlinkungen auf roten Artikel

Letzter Kommentar: vor 7 Jahren 10 Kommentare2 Personen sind an der Diskussion beteiligt

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

Hallo Freddy, das bekommen wir hin, ich mache mich mal am We daran. LG -- User: Perhelion 00:52, 25. Feb. 2017 (CET) Beantworten
@Freddy2001: Funzt nicht, denn es fehlt wohl ein "'Access-Control-Allow-Origin' header" bei deinem php (CORS)!? Ansonsten, was spräche den gegen einen Wiki-eigenen API-Aufruf? Wohl nur die Belastung des Wiki-Servers!? -- User: Perhelion 16:36, 26. Feb. 2017 (CET) Beantworten
Evtl. haperts auch nur daran, dass einfacher Text übergeben wird!? :-/ (JSONP scheint auch nicht die richtige Wahl, JSON wäre z.B. {count:12}). Hier ist mein Stand der Dinge:
varredlinks={};
functiongetLinksCount(e){
varurl='https://tools.wmflabs.org/freddy2001/linknumbers.php';
var$target=$(this);
vartitle=encodeURIComponent('Beispiel'||
$target.prop('title').replace(' (Seite nicht vorhanden)','')// FIXME: get string dynamically
);
varr="666";// FAIL
if(redlinks.hasOwnProperty(title))return;// run only once
$.ajax({
url:url+"?callback=?",
type:"GET",
crossDomain:true,
beforeSend:function(xhr){xhr.overrideMimeType("text/plain");},
contentType:'text/plain',
processData:true,
dataType:'json',// or 'text'!?
cache:true,
timeout:2000,// Give up if Tool Labs is being slow today
data:"title="+title,
xhrFields:{withCredentials:true},
success:function(r){
redlinks[title]=r;
$target.prop('title',$('#t-whatlinkshere a').text()+" "+r);
alert(r);
},
error:function(err){
alert("no good "+JSON.stringify(err));
}
})
}
$('.new').on('mouseover',getLinksCount);

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

Ich habe mal ein Script ohne Toolserver erstellt, Freddy. -- User: Perhelion 03:37, 6. Mär. 2017 (CET) Beantworten
Hallo Perhelion, das zweite Script auf meta funktioniert ausgezeichnet, genau so möchte ich es haben. Leider ist es jedoch ziemlich langsam (Mobil benötigt es fast eine halbe Minute, bis die Seite geladen ist).
Bei dem Script mit dem Toolserver bekomme ich immer nur linknumbers.php?callback=jQuery111309299507719567893_1488796530972&title=Beispiel und nicht den richtigen Titel des Links übergeben. Falls es helfen würde, könnte ich dort auch mit JSON die Ausgabe zurückgeben.
Zudem wäre es für mobile Verbindungen vermutlich auch besser, wenn nicht jede Anfrage einzeln, sondern mehrere auf einmal angefragt werden (wie bei der API), was auch Traffic sparen würde. -- Freddy2001 DISK 11:44, 6. Mär. 2017 (CET) Beantworten
@Freddy2001: Wäre ein Versuch wert (ich befürchte allerdings dass beim Toolserver CORS deklariert werden muss). Evtl. kann sich ja jemand Drittes hierzu äußern. An die Funktion alle Redlinks in einem Rutsch abzuarbeiten habe ich auch schon gedacht, allerdings nur per konkret manueller Aktivierung (also als Link im Tool-Menue). Wobei man auch eine Art Badge mit Zahl direkt am Link erzeugen könnte ohne Mouseover!? Das Script sollte dann auch nur im Artikelnamensraum geladen werden? Tatsächlich werden momentan 2 Module vorgeladen, die generell ein Laden verzögern könnten (das könnte man auch nach hinten stellen, entweder bei Linkausführung oder erstem Mouseover). Ich könnte die Module auch rausschmeißen und durch nativerem (nur wenig längerem) Code ersetzen. -- User: Perhelion 22:57, 6. Mär. 2017 (CET) Beantworten
@Perhelion:Ich kann auf dem Server gerne die CORS-Informationen mitsenden. So viel, wie ich bisher dazu herausgefunden habe, müsste das doch nur das Header-Feld Access-Control-Allow-Origin: * sein, was ich noch mitsenden müsste. Ideal wäre es, wenn es sich im ANR direkt automatisch aktiviert, jedoch ist es egal ob die Anzahl nur per Mouse-over oder als Zahl in Klammern dahinter steht. Soweit ich deinen Code und meinen Browserlog verstanden habe, liegt die Schwachstelle derzeit dadrin, dass jeder einzelner Link bei der API angefragt wird und diese natürlich weitaus mehr Informationen zurückliefert als benötigt, wie z.B. die Linktitel, die für dieses Script irrelevant sind, was natürlich auch wieder Datenverkehr verursacht. -- Freddy2001 DISK 16:30, 10. Mär. 2017 (CET) Beantworten
@Freddy2001: Ja mache das mal, für einen automatischen Lauf wäre dein Tool sicher besser. Obwohl "mein" Script jetzt auch nur minimale API-Daten bekommt, kann es nun alle Red-Links auf einmal abfragen (wobei ich hier ein Limit von 100 einbauen musste da hier wohl die API-Grenze zu liegen scheint, allerdings funzt Mouseover so oder so dann trotzdem noch). -- User: Perhelion 16:29, 25. Mär. 2017 (CET) Beantworten

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

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

Letzter Kommentar: vor 7 Jahren 12 Kommentare7 Personen sind an der Diskussion beteiligt

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

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

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

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

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

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

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

Naja, wenn JavaScript eh abgeschaltet bleibt, dann bringt eine "Lösung" mit JS eh nix. Nun: ich würde momentan nicht mehr machen als wie im Beisipel oben ausgeführt. D.h.: "Die letzte Text..." entfernen und auf "Änderung" verkürzen (ob das erste oder letzte war, kann doch eh an der Nummer ersehen werden), "wurde" entfernen, "die" entfernen"; damit hat sich's vorläufig. Das wird sich dann weisen, ob das ausreicht oder immer noch zu lang ist. --ProloSozz (Diskussion) 17:03, 5. Mär. 2017 (CET) Beantworten
Also, „das wird sich dann weisen" ist dieser Werkstatt nicht der Brauch. Das kann man sich ja vorher ausrechnen, wie viele Bytes dabei herausspringen werden, und es soll ja auch noch was übrigbleiben, um noch eine kleine Anmerkung dranzuhängen.
Und wenn ich mir Spezial:Diff/163237508 mal genauer anschaue, dann scheinen sich mir folgende Kürzungsmöglichkeiten auf Kosten der Schönheit zu ergeben:
  • Änderungen von [[Spezial:Beiträge/2003:75:8F17:B801:789F:728F:5D2C:79F7(削除) |.&checktime(2003,75,8,':')F17:B801:789F:728F:5D2C:79F7 (削除ここまで)]] (削除) ([[Benutzer Diskussion:.&checktime(2003,75,8,':')F17:B801:789F:728F:5D2C:79F7|Diskussion]]) (削除ここまで) auf die letzte Version von [[Benutzer:Regi51(削除) |Regi51 (削除ここまで)]] zurückgesetzt
    • Die Diskussionsseite einer IPv6 scheint mir kein unmittelbar dringendes Ziel zu sein.
    • Die Maskierung der Beitragsliste mag entfallen.
    • So auch die vornehm gekürzte Linkbeschriftungeiner Versionsnummer.
Warum „wenn JavaScript eh abgeschaltet bleibt" der Fall sein solle, habe ich jetzt nicht verstanden.
LG --PerfektesChaos 17:16, 5. Mär. 2017 (CET) Beantworten
a) "Wird sich weisen ..." Die Textlänge ist auch von der Namenslänge des Vorschreibers abhängig. Und da i.d.R. auf eine Version eines namentlich angemeldeten Benutzers revertiert wird, dessen Name nicht so überlang ist wie eine IPv6-Adresse, ist vorerst mal eine Länge einzuhalten, die für eine (einzige) IPv6-Adresse erträglich ist; und das dürfte mit der bestehenden Feldlänge noch zutreffend sein. Klar wäre es sicher nicht zu verachten, wenn genügend Platz da wäre, um zwei IPv6-Adressen unterbringen zu können. Aber das würde dann wohl nicht ohne Feldlängenvergrösserung gehen; und die könnte jetzt noch zurückgestellt werden. Sollte sich aber trotz Systemtextkurzform das Problem weiterhin zeigen, dann müsste die Feldlänge dann doch erhöht werden. Und genau _das_ wird sich weisen, ob das dann doch nötig würde.
b) Ich hab' JS eigentlich immer abgeschaltet und schalte das nur dann ein, wenn es nicht anders geht. Auf die kleinen Zusatzdetails (wysiwyg etc.) kann ich gerne verzichten, wenn ich es nicht ausdrücklich mal einsetzen will (und dann wird kurzzeitig JS eingeschaltet und nach der Aktion wieder aus). Und das werden hier viele auch so handhaben. Deshalb sollte es eine Lösung sein, die ohne JS auskommt.
c) Als Text würde "Änderung(en) von ÄÄÄÄÄÄÄÄ auf letzte/erste Version(en) 000000000 von ZZZZZZZZ zurückgesetzt." ausreichen; da wäre dann sogar das "erste"/"letzte" noch mit dabei (das "die" kann auch entfallen). --ProloSozz (Diskussion) 19:17, 5. Mär. 2017 (CET) Beantworten
  • @ProloSozz
    • Ich schrieb oben: möglichst Lua; notfalls JavaScript („gehen Lua-Aufrufe vielleicht auch. Falls nicht").
    • Wenn Lua nunmal nicht geht, dann bleibt eben nur JavaScript – wenigstens für die weitaus überwiegende Mehrheit der Benutzer.
    • Erfreulicherweise konnte ich jedoch erproben, dass Lua hier einsetzbar ist.
  • Eine IPv6 nimmt 63 Bytes in Anspruch.
    • In MediaWiki:Revertpage tritt die Benutzerkennung fünfmal auf.
    • Wenn also eine IPv6 eine andere IPv6 revertiert, kommen 315 Bytes für die IDs sowie 131 Bytes zusammen; 446 Bytes würden benötigt.
    • Ein Nick darf für die WMF wohl 32 Zeichen lang sein (mw:Manual:user table meint 255 varchar?) und wenn dafür nur altchinesische Schriftzeichen benutzt werden, dann braucht das nach meiner Kenntnis von UTF 128 Bytes je Nennung. Unser Standard-BK würde 771 Bytes lang.
  • Die Summary ist wohl weiterhin auf 255 Bytes begrenzt.
    • Ideen, das auszudehnen, gehen auf 2006 zurück.
    • Auch in jüngerer Zeit stand man seitens MW einer WMF-weiten Ausdehnung der zulässigen Länge sehr skeptisch entgegen.
    • Ich selbst halte überhaupt nichts von einer Aufblähung des BK. Ich will auf Beo und in der VG keine mehrzeiligen Gedichte zu lesen bekommen, sondern in knappen Schlagworten und ggf. mit Links das Ziel der Aktion zusammengefasst bekommen. Detailfragen sind erst im Diff zu erschließen.
    • Die Vorstellung aus Kindertagen der WP, man könnte im BK die vollständigen Literaturangaben für den Edit unterbringen (weshalb das noch Hilfe:Zusammenfassung und Quellen genannt wird), ist Quatsch. Allenfalls kann da mal eine IP den ungesichteten Edit untermauern. Aber über anderthalb Jahrzehnte alle URL in der Versionsgeschichte durchzuprobieren, damit jedes Mal jeder Leser herausfinden könne, welcher der Beleg für eine bestimmte Aussage sein soll, ist Unfug; dazu haben wir leserfreundliche Einzelnachweise mit direktem Bezug.
    • Eine Lösung über längere BK ist nicht zu erwarten (wir konnten leider ihre Bremsen nicht reparieren – deshalb haben wir ihnen eine lautere Hupe eingebaut).
  • Ich habe mal zur Erprobung Modul:MsgRevert gestartet.

@Umherirrender, Raymond:

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

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

MediaWiki:Undo-summary kommt beim Klick auf (rückgängig), MediaWiki:Revreview-reject-summary-cur und MediaWiki:Revreview-reject-summary-cur-short werden beim Verwerfen einer ungesichteten Änderung benutzt. -- hgzh 11:13, 7. Mär. 2017 (CET) Beantworten
Wenn es mit Lua funktioniert, und so sieht es ja aus, warum nicht? Aber beim Review von Lua-Code bin ich aus dem Spiel :-( — Raymond Disk. 12:15, 8. Mär. 2017 (CET) Beantworten
Ich würde es begrüßen, das in php für alle Wikis zu haben, nicht nur hier. Für FlaggedRevs gibt es bereits Ansätze dazu, daher gibt es "revreview-reject-summary-cur" und "revreview-reject-summary-cur-short". Der Umherirrende 20:10, 10. Mär. 2017 (CET) Beantworten

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

Letzter Kommentar: vor 6 Jahren 7 Kommentare4 Personen sind an der Diskussion beteiligt

Liebe Wiki-Techniker,

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

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

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

Wie ich die hiesigen Pappenheimer kenne, ist die Idee bestimmt nicht neu, es hatte halt noch keiner Lust sie zu programmieren. Aber ich lasse mich gerne überaschen.... 129.13.72.198 12:36, 16. Mär. 2017 (CET) Beantworten
Hat noch niemand sonst diesen Beitrag gesehen? Ich würde mich über eine Rückmeldung freuen! --Fährtenleser (Diskussion) 19:32, 22. Mär. 2017 (CET) Beantworten

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

Das ist zwar nett, aber doch keine Wiki-Lösung! Dabei kannst du die Legende nicht sehen und musst etliche Schritte vollführen, die viele User überhaupt nicht können/kennen. Meine Frage bleibt offen: Wie wäre es mit einer Lupenfunktion? --Fährtenleser (Diskussion) 07:19, 27. Mär. 2017 (CEST) Beantworten
Hat noch niemand außer ProloSozz diesen Vorschlag gesehen? Er würde den Informationswert von großen Landkarten beträchtlich erhöhen! Wo sind die Profis? --Fährtenleser (Diskussion) 12:27, 4. Apr. 2017 (CEST) Beantworten
Gerade für Landkarten bietet es sich an, dass in der Lupe nicht nur vergrößert sondern auch mit mehr Details dargestellt wird. Bin aber kein Fan von Schnickschnack auf WP. --Rainald62 (Diskussion) 14:07, 23. Sep. 2018 (CEST) Beantworten

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

Letzter Kommentar: vor 7 Jahren 3 Kommentare2 Personen sind an der Diskussion beteiligt

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

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

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

Wikipedia loggt Benutzer bei Seitenwechsel aus

Letzter Kommentar: vor 7 Jahren 2 Kommentare2 Personen sind an der Diskussion beteiligt

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

Du hast vermutlich einen sog. "privaten Tab" offen oder hast Cookies deaktiviert. Schau mal in den Einstellungen. --FNDE 14:38, 13. Jul. 2017 (CEST) Beantworten
Siehe Wikipedia:Fragen_zur_Wikipedia#Anmeldung. Gruß --FriedhelmW (Diskussion) 14:56, 13. Jul. 2017 (CEST) Beantworten

Umgang der Suchfunktion mit Umlauten

Letzter Kommentar: vor 7 Jahren 6 Kommentare4 Personen sind an der Diskussion beteiligt

Hallo allerseits,

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

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

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

Bessere Suchergebnisse erzielt man mit Google, z.B. mit der Eingabe Bälle site:de.wikipedia.org. Gruß --FriedhelmW (Diskussion) 19:58, 17. Jul. 2017 (CEST) Beantworten
Das ist schon klar, es geht aber um die WP-eigene Suche. Die soll ja gelegentlich auch verwendet werden. --Katimpe (Diskussion) 20:55, 17. Jul. 2017 (CEST) Beantworten
Hmmm. Das ist IMO kein einfach zu loesendes Problem. Wie man an meinen Beitraegen unschwer erkennen kann, benutze ich eine Tastatur ohne deutsche Umlaute. Da finde ich es richtig gut, dass die aktuelle Suchfunktion mir einzelne Buchstaben ersetzt. Und das gilt auch fuer anderssprachige Sonderzeichen, z.B. Jørgensen (findet die Suche per "Jorgensen"; koenntest Du, Katimpe, problemlos ein "ø" produzieren? - und, falls "ja", koennte das die Mehrheit der Benutzer?). Dass in Einzelfaellen sic! dabei auch "falsche" Ergebnisse erhalten werden stellt mMn kein echtes Ausschlusskriterium dar. Just 0ドル.02 von -- Iwesb (Diskussion) 03:58, 18. Jul. 2017 (CEST) PS: Waere ein entsprechender Schalter unter "Einstellungen" moeglicherweise eine Loesung?Beantworten
In meinen o.g. Beispielen gilt ja gerade das Umgekehrte: ä wird zu a, ø wird zu o und so weiter. Das braucht ganz sicher niemand. Und ansonsten:
  • Jørgensen hast du nur über die Autovervollständigung gefunden, sonst wärst du auf Jorgensen gelandet. Das Problem besteht ja vor allem darin, dass man direkt auf den falschen Artikel geführt wird, wenn der richtige nicht existiert.
  • Das Problem betrifft natürlich im Wesentlichen die Umlaute, mit denen der Durchschnittsbenutzer eben kein Problem hat. Aber auch für Zeichen wie ø haben wir bereits ein Instrument, es nennt sich Weiterleitung. Gäbe es Jorgensen nicht, würde man dort eine Weiterleitung auf Jørgensen einrichten. (btw, wieso muss ich dir das erklären?)
  • Wie ich sehe, ersetzt du das ä nicht durch a, sondern durch ae, was ja auch allgemein üblich ist. Diese Funktion bietet die Software gerade nicht! Könnte man natürlich einrichten - bloß, die Community hat sich meines Wissens vor langer Zeit gegen solche Weiterleitungen entschieden. Aber darum geht es hier nicht.
Was auch immer das Verhalten der Suchfunktion für Vorteile haben mag, sie lassen sich durch Weiterleitungen genauso herstellen, wenn man das denn will. Was man in den Einstellungen einrichten kann, weiß ich nicht, es geht um das Standardverhalten. Und das mag für einen Anglophonen in dieser Form Sinn ergeben, in der deutschen Wikipedia ist es einfach nur fehl am Platz. --Katimpe (Diskussion) 05:08, 18. Jul. 2017 (CEST) Beantworten
Hi everyone,
Sorry for replying in English, and for the very long message. I can get translation help if needed, but it will take a lot of time. I've been following the conversation with the help of Google Translate. Please forgive any misunderstandings.
There are multiple search-related issues here. I will try to identify them and explain them. Then maybe we can find the best course of action for each problem.
First, it is good to know that (1) searching from the input box in the upper right of the window (sometimes called the "Go" feature) and (2) full-text searching use different search methods with different language processing.
(1) The "Go" feature tries to match titles and does not break up words. If it cannot find an exact match, it will remove diacritics and try again. It actually does more than remove diacritics; it will also "fold" many Unicode characters into "simpler" or "more standard" characters. This includes removing diacritics, but also converting "ß" to "ss", Greek final sigma "ς" to regular sigma "σ", fullwidth numbers and letters "012ABC" to "normal" halfwidth "012ABC", halfwidth CJK characters "メ" to fullwidth "メ", and much more.
As a result, you can search in the "Go" (upper right) input box for BaɬĹɇ and you will land on the page Balle, because there is not page called "BaɬĹɇ". This is a more extreme case than Bälle taking you to the page Balle, but it is the same idea.
I believe that text processing for the "Go" feature is currently configured exactly the same on all wiki projects. It does not currently allow for customization.
(2) Full-text searching does language-specific processing of the text. This language-specific processing is provided by Elasticsearch and Lucene. These are the open-source technologies that CirrusSearch is built on. For many languages—like German, English, and French—we initially used with the language-specific processing provided by Elasticsearch without making any changes. We have customized English, French, and others, but German is using the original default configuration. The configuration for German full-text search could be changed. I would like to change it to include general character folding (except possibly ß, ä, ö, and ü), which the default language processing does not do. The extra folding in full-text search has been helpful on English and French wiki projects.
For whatever reason, the German language processing includes a step called "German Normalization" that does the following:* 'ß' is replaced by 'ss'
  • 'ä', 'ö', 'ü' are replaced by 'a', 'o', 'u', respectively.
  • 'ae' and 'oe' are replaced by 'a', and 'o', respectively.
  • 'ue' is replaced by 'u', when not following a vowel or q.
This could be disabled, or possibly replaced with something different.

I often work on language-specific configuration changes. I have a general guideline that I use for configuring character folding for a given language: my first suggestion is that everything should be folded, except for characters used by the language of the project. So, in English projects, I would fold everything. In German projects, I would not fold ß, ä, ö, or ü, but I would fold å, é, î, ø, ÿ, all the letters in "BaɬĹɇ" and all the others. I would of course modify the list of exceptions based on feedback from German speakers!
There also seems to be some problem with the way that ß is treated by Elasticsearch that may make it difficult to treat it correctly in the near future. See phabricator ticket T87136 for more information.
I agree with Iwesb that in general character folding is a good thing, especially for characters that are hard to type. I support maximum character folding for titles, too. Redirects can solve a lot of problems, but they can't cover everything. Many pages don't have redirects without diacritics, and finding them would be a lot of effort that could be spent doing more productive things. It is also impossible to include every potentially useful redirect.
For example, there is an Icelandic band called Sigur Rós. I found a playlist of their music online, which spells the band name Sigür Ròs. Without character folding in the "Go" feature, this would not be a match.
The side effect of this is the situation with Balle/Bälle, and Wasserfälle/Wasserfall/Wasserfalle. I noticed that the Wasserfälle problem has been solved with a redirect. That makes perfect sense, because there isn't any other way to handle it.
Regardless of my preferences, if there is consensus that some set of letters (probably ß, ä, ö, and ü) should not be folded in either the "Go" feature search or in full-text search, I would be happy to try to implement those changes and see what the effect is.
Unfortunately, changing the "Go" feature would be more work and would take longer, because it would require adding the capability to configure how the "Go" feature does character folding. We already have the ability to do that for full-text search.
Because the changes would affect a lot of users, especially inexperienced users who don't have any knowledge of searching, or the Help Desk, etc., I would suggest reaching a consensus among a larger group of users. I don't see the German Wikipedia equivalent of an RfC, but there must be something similar.
I will check back and try to answer any questions or comments. TJones (WMF) (Diskussion) 19:19, 20. Jul. 2017 (CEST) Beantworten

Gadget search-new-tab funktioniert manchmal nicht

Letzter Kommentar: vor 7 Jahren 3 Kommentare2 Personen sind an der Diskussion beteiligt

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

Im Quellcode steht folgender Kommentar:
According to Krinkle, gadgets don't have to wait using $(function() {... (only core stuff)
Diese Behauptung halte ich für falsch. Ich vermute dass das Gadget manchmal nicht funktioniert, weil es eben vor Document-Ready ausgeführt wird. Das $(function() {... würde genau das beheben. --Fomafix (Diskussion) 14:43, 14. Sep. 2017 (CEST) Beantworten
Ich habe jetzt mal auf der Gadget-Disk nachgefragt und dabei Krinkle angepingt. --nenntmichruhigip (Diskussion) 20:19, 14. Nov. 2017 (CET) Beantworten

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

Letzter Kommentar: vor 7 Jahren 2 Kommentare2 Personen sind an der Diskussion beteiligt

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

Klappt es mit &amp;? --mfb (Diskussion) 19:10, 23. Sep. 2017 (CEST) Beantworten
Letzter Kommentar: vor 7 Jahren 3 Kommentare3 Personen sind an der Diskussion beteiligt

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

Da hilft höchstens ein Wechsel des Browsers. --FriedhelmW (Diskussion) 19:25, 1. Okt. 2017 (CEST) Beantworten
Auch das wird nicht helfen: Das ist das bekannte Problem, wenn nachträglich die Seitenlänge geändert wird. Hierzuwiki eher von einklappenden Tabellen bekannt, sind es bei Wikidata die weiteren Sprachen der Itembeschreibung und die Bearbeiten-Links. --nenntmichruhigip (Diskussion) 15:23, 9. Okt. 2017 (CEST) Beantworten

Slideshow

Letzter Kommentar: vor 7 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt

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

1) Die Abstände zum Text oben und unten scheinen mir etwas zu groß.
2) Kann man die Position der Weiter-Pfeile < und > nicht an die Bildgröße darunter anpassen, so dass sie am rechten bzw. linken Bildrand liegen?

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

MathJax Benutzerscript

Letzter Kommentar: vor 7 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt

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

Quelltextbearbeitung teilweise in englischer Sprache

Letzter Kommentar: vor 7 Jahren 3 Kommentare2 Personen sind an der Diskussion beteiligt

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

Hast du das Wiki oder deinen Browser auf Englisch eingestellt? -- Freddy2001 DISK 20:46, 19. Nov. 2017 (CET) Beantworten
Nein. Alles andere, auch links das "Änderungen veröffentlichen" erscheint ja in Deutsch und es passiert auch nicht immer. Übrigens habe ich inzwischen festgestellt, dass es nicht nur beim Google Chrome auftritt. --Rita2008 (Diskussion) 18:01, 22. Nov. 2017 (CET) Beantworten

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

Letzter Kommentar: vor 7 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt

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

Rendern zu PediaPress

Letzter Kommentar: vor 7 Jahren 5 Kommentare4 Personen sind an der Diskussion beteiligt

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

Service für nicht-Eisenbahner: Vermutlich sind Artikel aus Kategorie:Triebfahrzeug (BLS) gemeint. --nenntmichruhigip (Diskussion) 09:13, 11. Jan. 2018 (CET) Beantworten
Wenn ich mich recht entsinne wurde PediaPress doch eingestellt? -- Quotengrote (D|B|A) 10:12, 11. Jan. 2018 (CET) Beantworten
Auf Benutzer:Traktor-Katze/Bücher/BLS Tribfahrzeuge und Benutzer:Traktor-Katze/Bücher/BLS die Drite gibt es oben die Links "PDF" und "Gedrucktes Buch bestellen". Beides geht nicht und das ist wohl das Problem des Fragestellers. --тнояsтеn 10:26, 11. Jan. 2018 (CET) Beantworten

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

sum_cat_disc.py hat ein Login-Problem

Letzter Kommentar: vor 7 Jahren 3 Kommentare1 Person ist an der Diskussion beteiligt

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

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

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

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

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

Timeless und Formatvorlage Bahnstrecke

Letzter Kommentar: vor 7 Jahren 4 Kommentare3 Personen sind an der Diskussion beteiligt

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

Meiner Ansicht nach ist phab:T183827 der richtige Ort dafür. –Schnark 10:05, 18. Jan. 2018 (CET) Beantworten
+1
Muss ja nicht nur .bs-icon betreffen, sondern andere Themen genauso.
Wir könnten bis zur Lösung von T183827 eine temporäre CSS-Regel durch Admin bereitstellen, falls jemand den richtigen kollateralschadenfreien Selektor für img ausguckt.
LG --PerfektesChaos 10:41, 18. Jan. 2018 (CET) Beantworten
Wo in MediaWiki talk:Common.css gerade Minerva erwähnt wurde hänge ich hier mal einen weiteren Darstellungsfehler in der FVBS mit der selben Frage („Wo beheben?") dran: Mit dem Skin Minerva sind die div.bs-icon 0.6 px zu hoch. Mit kleineren Werten für font-size lässt sich das behoben, aber ohne Anpassung ist es genauso wie in Vector 100%; scheint also noch einen anderen Lösungsweg zu geben. --nenntmichruhigip (Diskussion) 11:03, 19. Jan. 2018 (CET) Beantworten

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

Letzter Kommentar: vor 7 Jahren 8 Kommentare4 Personen sind an der Diskussion beteiligt

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

Deine Entdeckung trifft unabhängig der Infobox zu, jedoch seltsamerweise nicht bei allen Artikeln:
Vielleicht ist das etwas für die TWS. --Leyo 18:39, 23. Jan. 2018 (CET) Beantworten

Ende Kopie

Kann sich das Phänomen bitte mal noch jemand ansehen? Danke, --Wi-luc-ky (Diskussion) 19:04, 23. Jan. 2018 (CET) Beantworten
  • Zunächst müsstet ihr herausfinden, um welches Tool es eigentlich geht.
  • Wenn „Navigation-Popups", dann müsstet ihr euch direkt an die enWP wenden, per en:MediaWiki:Gadget-popups.js.
  • Wenn die sogenannten „Hovercards", dann kann die TWS maximal einen Phab-Bericht schreiben und in den richtigen Briefschlitz stecken.
  • In jedem Fall braucht ihr eine tabellarische Analyse, in genau welchen Situationen immer genau was passiert und in genau welchen was nicht; und dazu möglichst zwischendurch nicht mehr umgestrickte Seiten, an denen einige Zeit später ein Entwickler das auch mit der aktuellen Seitenversion nachvollziehen kann.
  • Grundsäzlich sollte ob Quelltextverständlichkeit der Kommentar auf einer eigenen, allerersten Zeile stehen.
VG --PerfektesChaos 19:18, 23. Jan. 2018 (CET) Beantworten 
Danke, Perfektes Chaos, es ist wohl die Hover-Card-Funktion. [Korrektur: das Navigation-Popups-Helferlein. --Wi-luc-ky.] (Vllt. kannst Du mal in meinem „Uhrwerk" nachsehen. Kann bitte auch Leyo schreiben, mit welchem Tool er diese Fehler reproduzieren konnte.)
Vorläufige Zusammenfassung: Es gibt neben der „Normalvorschau" drei Arten fehlerhaften Vorschauen, seltsamerweise bei anscheinend immer gleichem oder vergleichbarem Quellcode-Anfang:
  1. Mouse-over zeigen nur → }}
  2. Mouse-over zeigen → }} Text... (mit Leerzeichen!)
  3. Mouse-over zeigen → }}Text... (ohne Leerzeichen!)
Fehlerverteilung in Beispielen:
A) in hastemplate:Infobox_Alpiner_Skirennläufer insource:/schweizbezogen-->\{\{/
mit Quelltext: <!--schweizbezogen-->{{Infobox Alpiner Skirennläufer
  • alle Artikel
    • zu sehen ist nur → }}
B) in hastemplate:Infobox_See insource:/schweizbezogen-->\{\{/
mit Quelltext: <!--schweizbezogen-->{{Infobox See
alle Mouse-over zeigen nur }}, außer:
  • Lago Sfundau
    • zu sehen ist → }} Der Lago Sfundau ist ...(mit Leerzeichen!)
C) in hastemplate:Infobox_Stausee insource:/schweizbezogen-->\{\{/
mit Quelltext: <!--schweizbezogen-->{{Infobox Stausee
  • Albignasee
    • zu sehen ist nur → }}
  • Klöntalersee
    • zu sehen ist → }} Der Klöntalersee ist ein ... (mit Leerzeichen zwischen }} und Text!)
(desgl. in Zervreilasee von Vorlage:Navigationsleiste Schweizer Speicherseen aus im Mouse-over; alle anderen dort o. k.)
weitere:
D) in hastemplate:Infobox_Berg insource:/schweizbezogen-->\{\{/
mit Quelltext: <!--schweizbezogen-->{{Infobox Berg
hth, --Wi-luc-ky (Diskussion) 19:26, 25. Jan. 2018 (CET) Beantworten
Bist du sicher, dass du mw:Hovercards meinst? Ich kann es nämlich mit Navpopups reproduzieren, mit Hovercards aber nicht. --nenntmichruhigip (Diskussion) 10:38, 26. Jan. 2018 (CET) Beantworten
Du hast recht, Nenntmichruhigip, nach Ansicht auf den Hilfeseiten muss ich mich korrigieren: es ist das
bei mir in WP:Helferlein mit einem Häkchen versehen. Vielen Dank für Deine klärende Nachfrage. Gruß, --Wi-luc-ky (Diskussion) 11:06, 26. Jan. 2018 (CET) Beantworten
Geändert werden müsste übrigens en:MediaWiki:Gadget-popups.js, da dieses im Gadget aufgerufen wird. --Leyo 17:18, 5. Feb. 2018 (CET) Beantworten

ist /Editnotice kaputt?

Letzter Kommentar: vor 7 Jahren 6 Kommentare4 Personen sind an der Diskussion beteiligt

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

diese Änderungen durch den Hexer dürften der Auslöser sein. Gruß, -- hgzh 10:14, 26. Jan. 2018 (CET) Beantworten
(BK)
Diesen Sinn unter Admins abklären und vor Veränderungen auf BETA erproben.
Ich verstehe den Sinn der Änderung nicht, halte sie für überflüssig, würde auf 2015 zurückkehren und Gegengründe wären erstmal zu benennen. Das Ziel dieses Manövers müsste zuallererst mal erläutert werden, in genau welcher Situation das wozu gebraucht würde.
VG --PerfektesChaos 10:19, 26. Jan. 2018 (CET) Beantworten
Danke vielmals ein SmileysymbolVorlage:Smiley/Wartung/zwinker  Doc TaxonDisk.WikiMUCWikiliebe?! 10:54, 26. Jan. 2018 (CET) Beantworten
Wenn man in Editnotice-0 übernommen und für den Namespace 4 angepasst. In der Tat sieht das allgemein nach sehr viel Geflickel aus, ohne dass es hier einen Standard gibt, der Einzelseiten wie Gruppen grundsätzlich berücksichtigt. Dies sollte ja jeweils schon ermöglicht werden, wenn es diese Funktionalität gibt und teils auch schon genutzt wird. Ich bin nicht der größte Experte, dies umzusetzen und es ist natürlich doof, wenn dann jetzt etwas kaputtgegangen ist. Faktisch dürfte es schon vorher kaputt (bzw. nicht nachhaltig gebaut) gewesen sein, sondern für Einzelfälle wie diesen hier angepasst. Wie setzen wir gemeinsam eine gute Grundlage für alle Namensräume und Fälle auf? Grüße, —DerHexer (Disk.Bew.) 23:46, 29. Jan. 2018 (CET) Beantworten
  • Erstmal stellt sich die Frage, inwieweit das für alle Namensräume in gleicher Weise erforderlich wäre, und wie häufig das benötigt würde.
    • ANR und Projekt-NR (aka 4=WP) haben hier eher Bedarf für Gruppen von Seiten.
    • Kategorie, Diskussionen, Hilfeseiten oder Vorlagen dann eher nicht.
    • Ob es also zwingend für alle NR eine einheitliche Lösung geben müsse, steht dahin.
    • Für den ANR hatte man sich einmal entschieden, einen Sonderweg zu gehen, abweichend von allen anderen Namensräumen. Nur Admins sollen Editnotice für einzelne Seiten (Artikel) definieren können, für alle anderen NR wäre das frei.
    • Siehe grundlegend Hilfe:Editnotice.
    • Bestandsaufnahme:
      • 238 beteiligt
      • 225 ANR-Einzelseiten
      • 1 Gruppe für ANR, 1 Versuch einer Gruppe für WPNR.
      • Ggf. Gruppenregeln in einzelnen NR-Definitionen (NR 2, 4, 4, 5, 8, 10, 100)
  • Wenn man es heutzutage reorganisieren wollte, dann sicher mit Lua und mit beliebigen pattern für den Seitennamen.
    • Für jede Einzelseite (ggf. außer ANR) bleibt es bei der individuellen Unterseite, die jeder anlegen kann und die bei Bedarf Admin-Vollschutz bekommen mag.
    • Im ANR kann man davon abweichend oder übergangsweise die bisherigen automatisch vollgeschützten MediaWiki:-Seiten zusätzlich unterstützen. Vielleicht zusätzlich die Unterseite zulassen, ggf. mit heute möglichen Sichterrechten (wobei sowas wenige Beobachter hätte und im Suchmaschinenindex auftauchen würde bzw. von Suchmaschinen ausgeschlossen werden müsste, und ANR-Suchtreffer liefern kann) – es gibt aufgrund von Suchverhalten und wegen Vermengung enzyklopädischer Informationen mit internen Verwaltungsangelegenheiten durchaus Gründe, nicht alle Namensräume identisch zu behandeln.
    • Lua-Pattern und weitere Eigenschaften ermöglichen dann einen für alle NR einheitlichen Satz von Regeln, beliebige Eigenschaften des Seitennamens usw. heranzuziehen.
      • Also auch „endend auf /Doku".
      • „Ist irgendeine Unterseite von ..." – die bisherige ANR-Gruppe sah nur die letzte direkte Quasi-Unterseite (ANR hat keine Unterseiten) vor.
      • „Name enthält Adolf aber nicht Hüttler".
      • „Ist keine Unterseite endend auf /Editnotice" (Standard-Regel, Trick-Effekt mit Link auf Hilfe:Editnotice)
      • „Hat Content Model css"
      • „Name enthält Adolf und ist dreiviertelgeschützt"
    • Die bisherigen Einzel-Regeln in den NR müsste man mal zusammentragen und untersuchen, ob noch sinnvoll.
    • Eine Seite kann aufgrund ihrer Eigenschaften mehrere Hinweisbausteine untereinander auslösen.
    • Alle Regeln für edit müssten sich vermutlich auch auf die Situation create anwenden lassen.
  • Einen Lua-Code würde man in zwei vollgeschützte Module aufteilen; eine Programm-Einheit und eine Definition für edit (alle NR).
    Beispiel-Definition:
{ [0] = { -- ANR ...
 },
 [4] = { ["Wikipedia:Wikimedia Deutschland/Neue Ehrenamtliche/Onboarding/Geführte Touren/Trainingsmodule/*Editnotice"] =
 { title = { ["/Geführte Touren/Trainingsmodule/[^/]+$"] = true }
 }
 },
 [8] = { ["Wikipedia:Technik/Skin/MediaWiki/Admin-Editnotice"] =
 { contentmodel = { css = true,
 javascript = true }
 }
 },
 [10] = { ["Vorlage:Dokumentation/Editnotice Doku-Seiten"] =
 { title = { ["/Doku$"] = true }
 }
 },
}
  • Bedeutung der Syntax:
    • Die Zahlen an Anfang sind Nummern der Namensräume. Jede öffnet eine Zuordnungstabelle.
    • Jede Zuordnungstabelle enthält genau die (beliebig untergebrachte) Seite, die den darzustellenden Wikitext enthält.
    • Dieser darzustellenden Seite ist ein Satz von Regeln zugeordnet.
    • Die Regeln können einschließend sein (true) oder ausschließend (false).
    • Zuerst werden auf die aktuelle Seite alle einschließenden Regeln angewendet, danach (sofern diese einen Treffer signalisierten) alle ausschließenden Regeln. Wenn dann immer noch im Rennen, dann wird die darzustellenden Seiteneinbindung dem Ergebnis hinzugefügt.
  • Braucht ein wenig Reindenken, ist dann aber auch nicht schwieriger als bisher, wird ohnehin nur von einer Handvoll affiner Admins gepflegt. Dafür übersichtlich für alles.
  • Weiteres Vorgehen:
    • Notiz hierher auf WP:A/N und HD:EDN.
    • Wiedervorlage im Februar.

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

Skriptwunsch

Letzter Kommentar: vor 6 Jahren 20 Kommentare5 Personen sind an der Diskussion beteiligt

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

das könnte funktionsverwandt mit MediaWiki:Gadget-Rechtschreibpruefung.js sein. Man bräuchte ein Tool, das im Hintergrund die Biographienliste mit dem Artikeltext abgleicht. Bei über 600.000 Biographien dürfte das allerdings ziemlich lange dauern... -- hgzh 21:39, 31. Jan. 2018 (CET) Beantworten
Und wie sieht es damit aus, dass ein Skript oder ein Bot das einmalig auf einer Unterseite zusammenträgt als Liste, die man dann abarbeiten könnte? --Kenny McFly (Diskussion) 21:58, 31. Jan. 2018 (CET) Beantworten

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

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

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

Danke für diese beeindruckende Analyse ^^ Ich nehme das mal als "eher nein". --Kenny McFly (Diskussion) 11:09, 1. Feb. 2018 (CET) Beantworten
Unverlinkte Namen per Suchfunktion zu finden ist pro Name nicht so schwierig (insource:/Hermann Meier[^\]}][^(]/), aber dann findet man auch Artikel, in denen Herr Meier nur bei der ersten Nennung verlinkt wurde. --mfb (Diskussion) 08:49, 3. Feb. 2018 (CET) Beantworten
Das wäre der größtmögliche Overkill für diese Lösung überhaupt. Die einzig adäquate Lösung wäre wie beim oben erwähnten Gadget-Rechtschreibpruefung (über wmflabs) eine extra definierte DB abzurufen. -- User: Perhelion 13:18, 3. Feb. 2018 (CET) Beantworten
PS: Für eine Ziel-Artikel-DB (zum Vorfiltern) müssten dann ~600 000 * 2.988.050 Artikel ≈ 1 290 000 000 000 Aufrufe getätigt werden und wie von PC gesagt jede Woche. Das dürfte ein wenig dauern (ich habe keine Relation bzw. Vorstellung wie lange). Abruf-Filter: Um die Api-Anfragen gering zu halten müsste das Script relevante Phrasen erkennen, was wiederum überaus aufwendig wäre. Wie PC schon sagt, jegliche Lösung wäre höchst wahrscheinlich utopischer Rechenaufwand.
Einfachste Lösung: Bei Textmarkierung eine virtuelle Verlinkung erzeugen (wenn vorhanden blau wenn nicht rot), egal was. @Kenny McFly:? -- User: Perhelion 13:52, 3. Feb. 2018 (CET) Beantworten
Du meinst, dass man einen Text markiert und sofort gesagt bekommt, ob das ein Lemma ist? Das klingt super und müsste recht schnell zu machen sein oder? --Kenny McFly (Diskussion) 13:55, 3. Feb. 2018 (CET) Beantworten
Japp, wäre eine sehr allg. Lösung und auch mit dem größten menschlichen Interaktions-Spielraum (bzw. Aufwand). -- User: Perhelion 14:10, 3. Feb. 2018 (CET) Beantworten
erledigtErledigt Hier ist eine Rohfassung die läuft: m:User:Perhelion/checkTitleExists.js (ob sie mit IE9 funzt kann ich nicht sagen). Zur Aktivierung links den Toollink klicken. @Kenny McFly: VG -- User: Perhelion 23:49, 8. Feb. 2018 (CET) Beantworten
Was meinst du mit Toollink klicken? Ich hab das mal auf meiner common.js eingebunden, aber nichts passiert. --Kenny McFly (Diskussion) 10:45, 9. Feb. 2018 (CET) Beantworten
Links in der Werkzeugleiste müsste „Run TitleCheck" erscheinen. -- hgzh 10:52, 9. Feb. 2018 (CET) Beantworten
Richtig (danke für den Hinweis), inzwischen habe ich den Titel „Title-Check" geändert. Das Script startet natürlich nicht automatisch, da bei jeder Text-Markierung eine API-Anfrage ausgelöst wird (sofern mw.Title gültig und nicht schon mal ausgelöst). PS: Ich habe es nur im Artikel-NR aktiv. @Kenny: bräuchtest du es auch woanders?
Wobei mir ein Fehler in unserer Doku beim Modul mw.Title aufgefallen ist. Nicht dass die Funktion exists schon verwirrend genug ist (denn sie prüft nicht ob der Titel existiert, sondern man muss ihn selbst mit einer API füllen!?! Obwohl es für andere trivialere Dinge eine solche fertige API gibt, wie bei isCategory ).
.exist und .exists sind Funktionen des Moduls selbst und zumindest .exist ist keine Unterfunktion eines neuen „Titel-Objekts" (dort t) (ergibt auch insofern Sinn als ein oder mehrere neue Title übergeben werden müssen). Also es gibt zwei verschiedene .exists.@PerfektesChaos: -- User: Perhelion 13:44, 9. Feb. 2018 (CET) Beantworten
PS. @PerfektesChaos: vllt. wäre es ein Phab-Vorschlag wert die Function t.exists() als wirkliche API-Abfrage zu benutzen!? Edit: Ich habe mal die Doku dahingehend geändert (evtl. habe ich die alphabetische Reihenfolge und die nachfolgende Bedeutung von Danach sind für t verletzt) -- User: Perhelion 13:56, 9. Feb. 2018 (CET) Beantworten
@Kenny McFly: Und wie funzt das Script, kein Feedback? Mir ist noch eingefallen, dass man noch ein kleines Popup-Fensterchen machen könnte, wie die Vorschau mit mehreren Treffern bei einer Suchanfrage!? -- User: Perhelion 20:37, 26. Feb. 2018 (CET) Beantworten
Funktioniert hervorragend :D (Das mit dem Popup musst du mir erklären^^) --Kenny McFly (Diskussion) 20:40, 26. Feb. 2018 (CET) Beantworten
Gut :). Ich meine wie das DropDown-Preview bei einer Suchanfrage das schon während des Eintippens erscheint (wie bei Google). Allerdings nur wenn es für deine Belange praktisch wäre? (Wie aufwendig das jetzt wird kann ich noch nicht sagen, jedenfalls habe ich ein anderes Script mit dieser API-Funktion gesehen). -- User: Perhelion 20:47, 26. Feb. 2018 (CET) Beantworten
Wo gebe ich denn Text ein? Ich dachte ich markiere. Kann das etwa noch mehr? xD --Kenny McFly (Diskussion) 21:13, 26. Feb. 2018 (CET) Beantworten
Ne, also dann nicht. :P Dann kannst du den Thread gerne abhaken hier. -- User: Perhelion 21:18, 26. Feb. 2018 (CET) Beantworten

Danke-Button fehlt

Letzter Kommentar: vor 7 Jahren 4 Kommentare3 Personen sind an der Diskussion beteiligt

Hi,

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

[9].

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

Das war eine Artikelneuanlage. Die früheren Versionen wurden importiert. --FriedhelmW (Diskussion) 23:05, 3. Feb. 2018 (CET) Beantworten
Diese Kombination scheint der Grund zu sein --Distelfinck (Diskussion) 00:10, 4. Feb. 2018 (CET) Beantworten
@Distelfinck, FriedhelmW: In der Mobile-Version ist der Danke-Button da, also ist es ein Bug.[10] Hiermit gemeldet. -- User: Perhelion 00:34, 12. Feb. 2018 (CET) Beantworten

Benutzerinfo in der Desktopversion

Letzter Kommentar: vor 6 Jahren 14 Kommentare6 Personen sind an der Diskussion beteiligt

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

Haloooo? -- Girwidz zwinker →Hinterlasse mir hier eine Nachricht 12:30, 11. Feb. 2018 (CET) Beantworten
Drängel nicht. -- hgzh 12:41, 11. Feb. 2018 (CET) Beantworten
lol (削除) Das scheint mir ein relativ neues Feature. (削除ここまで) Lustig ist, dass es auch als "Desktop-Version" benutzt werden kann.[11] Man müsste eine entspr. Anfrage auf Phab. stellen. -- User: Perhelion 12:50, 11. Feb. 2018 (CET) Beantworten
Was ist ein Phab? ein SmileysymbolVorlage:Smiley/Wartung/:d  
-- Girwidz zwinker →Hinterlasse mir hier eine Nachricht 12:57, 11. Feb. 2018 (CET) Beantworten
https://phabricator.wikimedia.org/ - in der Desktopversion kannst du die Info mit irgendeinem Helferlein bekommen. Navigations-Popups? --mfb (Diskussion) 13:44, 11. Feb. 2018 (CET) Beantworten

Ich blicke hier irgendwie nicht durch...ein SmileysymbolVorlage:Smiley/Wartung/:/   -- Girwidz zwinker →Hinterlasse mir hier eine Nachricht 15:48, 11. Feb. 2018 (CET) Beantworten

Wenn du unter deinen Einstellungen das Helferlein Navigation-Popups (unter Navigation) aktivierst und mit dem Mauszeiger über den Benutzerlink fährst, wird eine Vorschau zur Benutzerseite eingeblendet und ganz unten im Pop-Up-Fenster werden die Infos zum Benutzer angezeigt. Vielleicht wäre das eine Möglichkeit? --Diwas (Diskussion) 21:30, 11. Feb. 2018 (CET) Beantworten
ja, aber eine komplizierte...
--Girwidz zwinker →Hinterlasse mir hier eine Nachricht 21:44, 11. Feb. 2018 (CET) Beantworten
@Phab:T187011 @Popups ist nichts von WM, es ist ein verhältnismäßig riesiges User-Gadget mit insgesamt 1/4 MB. Ich persönlich empfinde es als nervend (jeglicher unnötige Mouseover und dann schließt es nicht). -- User: Perhelion 23:57, 11. Feb. 2018 (CET) Beantworten
@Perhelion: und wie siehts zur Zeit aus??
VG Girwidz zwinker →Hinterlasse mir hier eine Nachricht 07:23, 19. Feb. 2018 (CET) Beantworten
Es gibt m:User:Perhelion/userstatus -- Freddy2001 DISK 08:45, 19. Feb. 2018 (CET) Beantworten
ich weiss, ich habe das auch aktiviert, aber es muss sich ja jeder einstellen um es zu sehen. Es geht, wie oben gennant, darum, dass man die Info (ähnlich wie in der Mobilen Version) auch in der Desktopversion sehen kann (also bei der Versionsgeschichte)...
Girwidz zwinker →Hinterlasse mir hier eine Nachricht 13:18, 19. Feb. 2018 (CET) Beantworten
Der Status der Phab-Anfrage ist immernoch ungesichtet (Needs Triage, nur der Volunteer TheDJ hat das Project Community-Tech entfernt). Es kann sich nur um Jahre handeln (leider kein Scherz). -- User: Perhelion 13:30, 19. Feb. 2018 (CET) Beantworten

Feedback zur Verbesserung von Lua-Funktionen benötigt

Letzter Kommentar: vor 6 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt

Hallo,

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

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

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

AutoWikiBrowser

Letzter Kommentar: vor 6 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt

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

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

Einleitung wp:vm

Letzter Kommentar: vor 6 Jahren 7 Kommentare6 Personen sind an der Diskussion beteiligt

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

In Chrome auch. Ich glaube es liegt an der CSS "margin-right:15em;". Wenn man das wegnimmt sieht es aber auch nicht gut aus. --FriedhelmW (Diskussion) 16:46, 27. Apr. 2018 (CEST) Beantworten
Magst du das margin-right:15em; mal durch ein overflow:auto; ersetzen? Ich fasse keine der VM-Seiten an. Ich vermute aber, das würde helfen. --Liebe Grüße, Lómelinde Diskussion 17:05, 27. Apr. 2018 (CEST) Beantworten
Danke, passt! Gruß --FriedhelmW (Diskussion) 17:34, 27. Apr. 2018 (CEST) Beantworten
Super jetzt ist es behoben, danke! --2A02:810D:1040:A7C:49BB:7ACC:9045:877D 08:22, 28. Apr. 2018 (CEST) Beantworten

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

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

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

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

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

Letzter Kommentar: vor 6 Jahren 3 Kommentare2 Personen sind an der Diskussion beteiligt

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

Ich habe den Fehler als phab:T194120 gemeldet, bin mir aber nicht sicher, wie sehr sich die Programmierer für den Monobook-Skin interessieren. Mit Vector oder anderen Skins, die ich probiert habe, tritt das Problem nämlich nicht auf. –Schnark 09:23, 8. Mai 2018 (CEST) Beantworten
Danke für Deine Bemühung.
Vielleicht wäre es besser, wenn die in den Augen brennende Zwiebel nicht so viele Häute hätte. Eine taugliche genügte ja. Multi skin no win. --Silvicola Disk 01:53, 10. Mai 2018 (CEST) Beantworten

A note on ‘mapframe’ maps and this wiki

Letzter Kommentar: vor 6 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt

Hilf bitte mit, in deine Sprache zu übersetzen

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

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

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

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

Script für mobile Version

Letzter Kommentar: vor 6 Jahren 3 Kommentare2 Personen sind an der Diskussion beteiligt

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

Ich tippe darauf, das in der Mobilen Version entweder eine andere CSS-Klasse verwendet wird (womit das Programm die Formeln nicht erkennt) oder der Resource-Loader (Wikipedia:Technik/Skin/JS/ResourceLoader) das Laden von Fremdservern verbietet. (nicht signierter Beitrag von Victor Schmidt (Diskussion | Beiträge) 20:09, 26. Mai 2018 (CEST))Beantworten
Die CSS-Klassen sind eigentlich da, dann muss es wohl irgendwie an dem ResourceLoader liegen.--Debenben (Diskussion) 14:16, 31. Mai 2018 (CEST) Beantworten

Nachsignier-Bot

Letzter Kommentar: vor 6 Jahren 9 Kommentare4 Personen sind an der Diskussion beteiligt

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

Welchen meinst du, CopperBot? Dann siehe WP:BA#CopperBot. --тнояsтеn 18:40, 17. Mai 2018 (CEST) Beantworten
Danke, ja das scheint er zu sein. Aber da er über ein Jahr kaputt ist, ist wohl davon auszugehen, das es a) ein technisch anspruchvolles Problem ist oder b) als ein Problem mit nicht hoher Priorität angesehen wird. mit gruessen von VINCENZO1492 09:28, 18. Mai 2018 (CEST) Beantworten
Das Problem ist weniger die Komplexität, als das der Betreiber, Benutzer:P.Copp, zuletzt 2012 aktiv war und das Problem damit unlösbar ist. Das Eigentliche Problem ist, Das der RC-Stream, über den der Bot seinen Input bekommen hat, abgeschaltet wurde. Da der Betreiber inaktiv ist, kann das Problem nicht durch ihn behoben werden. Derzeit hat Benutzerin:TaxonBota von Doc Taxon (Diskussion • Beiträge  • gelöschte Beiträge  • hochgeladene Dateien • SBL-Log • Sperr-Logbuch • globale Beiträge • SUL • Logbuch  • sperren ) den Nachsignierauftrag übernommen -so wei ich bescheid weiß. Victor Schmidt Was auf dem Herzen? 20:05, 26. Mai 2018 (CEST) Beantworten
mein Urlaub ist in ein paar Tagen um, dann werde ich mich weiter damit beschäftigen, – Doc TaxonDisk.WikiMUCWikiliebe?! 22:11, 26. Mai 2018 (CEST) Beantworten
@Victor Schmidt: unter den Edits von TaxonBota sind anscheinend keine Nachsignieredits. Und das erscheint mit der Antwort von Doc Taxon dann ja auch logisch.
@Doc Taxon: Danke! mit gruessen von VINCENZO1492 10:00, 1. Jun. 2018 (CEST) Beantworten
Hallo Doc Taxon: ich nehme an Du hattest keine Zeit Dich mit dem Problem zu beschäftigen? Oder keine Lösung gefunden? Schönen Tag & mit gruessen von VINCENZO1492 11:06, 16. Nov. 2018 (CET) Beantworten
ich hab mir erst mal ein Konzept über Umfang und Programmierung zurecht gelegt, wie ich das am besten mache. Ich bin gerade auf mehreren Baustellen gleichzeitig. Wegen seiner Vielfalt an verschiedenen Möglichkeiten ist die Programmierung auch nicht so ganz trivial. So was ähnliches hab ich schon bei den Normdaten gemacht, ich muss das bloß anpassen. Die Ausgabe wäre dann das Hauptproblem. Ich bleibe dran, – Doc TaxonDisk.Wikiliebe?! 12:18, 16. Nov. 2018 (CET) Beantworten
Danke für die schnelle Antwort & mit gruessen von VINCENZO1492 12:46, 16. Nov. 2018 (CET) Beantworten

Miniatur Vorschau der Wiki Artikel auf eigener Website (Wordpress)

Letzter Kommentar: vor 6 Jahren 6 Kommentare3 Personen sind an der Diskussion beteiligt

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

Ich wüsste nicht, das das geht. Man kann glaube ich mittels JavaScript irgendwie Vorschaubilder generieren, denn auf meiner Firefox-Startseite tauchen immer Welche auf, aber das sollte lieber unterlassen werden, da Live-Mirrors nur nach Rücksprache mit der Wikimedia Foundation zulässig sind, und zwar auch dann, wenn das ergebnis gecached wird. Grüße, Victor Schmidt Was auf dem Herzen? 19:57, 26. Mai 2018 (CEST) Beantworten
Vielen lieben Dank für die ausführliche Antwort, das hat mir schon einmal sehr weiter geholfen. Gruß --DerPförtner (Diskussion) 20:49, 26. Mai 2018 (CEST) Beantworten
Hi DerPförtner, ich vermute mal, dass es dir nicht unbedingt um eine Live-Vorschau geht. Wie wäre es denn mit Screenshots zB der Artikel-Einleitung oder soweit vorhanden der Infobox eines Artikels, die vlt dauerhaft auf deiner Seite eingeblendet sind (und diese somit vermutlich sogar noch interessanter aussehen lassen) und in denen der Hyperlink zum entsprechenden WP-Artikel integriert ist--Ciao • Bestoernesto 02:28, 27. Mai 2018 (CEST) Beantworten
Hallo bestoernesto, genau diese Option würde ich Erwägung ziehen, wie würde ich es dann umsetzen? Geht das komplett über HTML? Dort habe ich bereits einige Erfahrungen gesammelt, bei JavaScript noch gar keine. Freue mich auch über Anhaltspunkte, welche ich nutzen kann um mein Wissen zu erweitern, sodass ich meine Idee umsetzen kann. Gruß --DerPförtner (Diskussion) 02:35, 27. Mai 2018 (CEST) Beantworten
Komplett mit HTML und ohne JavaScript geht es nicht. Bei nicht-Live geht Folgendes (Keine Funktionsgarantie!):
 <img class="thumb" src="/media/thumb/beispielvorschau.jpg" onmouseon="this.sytle='display:block';" onmouseout="this.style='display:none';">
und in einer CSS-Datei
.thumb{
position:relative;
width:55px;//Währegemäßbildgrößenanzupassen
height:55px//Ebenso
}
Damit bekommt man ein Bild, das auf deiner Webseite den Pfad /media/thumb/beispielvorschau.jpg hat, hinein. Grüße, Victor Schmidt Was auf dem Herzen? 09:21, 27. Mai 2018 (CEST) Beantworten

Linkfix – Ideensuche

Letzter Kommentar: vor 6 Jahren 2 Kommentare2 Personen sind an der Diskussion beteiligt

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

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

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

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

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

Improvements coming soon on Watchlists

Letzter Kommentar: vor 6 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt

Hello

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

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

What is this feature again?

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

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

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

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

About the release on Watchlists

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

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

How to be ready?

Please share this announcement!

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

Please share your questions and comments on the feedback page.

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

Spezial:LintErrors

Letzter Kommentar: vor 6 Jahren 4 Kommentare3 Personen sind an der Diskussion beteiligt

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

Hohe Priorität

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

Mittlere Priorität

  • Fehlerhafte Dateioptionen (3 Fehler) – Rotes X oder Kreuzchensymbol für neinN2 hier kommt erschwerend hinzu, dass beide Seiten noch immer etliche Fehler anzeigen, die aber eigentlich behoben wurden. Die Fehlerlinks sind daher auch nicht mehr zielführend (2017 Q2 zeigt noch 21 und 2017 Q3 zeigt noch 15 Fehler an vermutlich alle behoben)
  • Falsch verschachtelter Inhalt (1.579 Fehler) – 1.566
  • Falsch verschachtelte Tags (69.204 Fehler) – Rotes X oder Kreuzchensymbol für neinN 32.569 schwankt stark auch manchmal mit einem Spitzenwert von mehr als 86.000
  • Mehrere Doppelpunkte (0 Fehler) Grünes Häkchensymbol für jaJ

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

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

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

Nein, kann man nicht.
Diese Datenbank ist nur ein unterstützendes Provisorium, und wenn da mal durch irgendeinen Schluckauf Phantom-Einträge hineingeraten sind, dann sind die da eben drin und irgendwann weiß auch jeder was wo nicht stimmt.
Diese Datenbank hat keine Bedienoberfläche, um Inhalte zu pflegen oder einzelne Eintragungen zu löschen.
Es könnten höchstens auf allen Wikis alle Linter-Datenbanken vollständig gelöscht werden, wodurch der enWP aber zig und zig Millionen Hinweise verlorengingen, deren Neuaufbau ein halbes Jahr dauern würde.
Einfach geduldig warten; vielleicht vergisst Linter das Phantom nach ein paar Edits auch mal wieder.
LG --PerfektesChaos 14:27, 9. Jun. 2018 (CEST) Beantworten
Schade wirklich, es erschwert diese Arbeit, weil man es doch immer wieder anklicken muss, um zu schauen, ob sich etwas geändert hat oder es nur die falschen Einträge sind. Und ein unbedarfter der so einen Eintrag anklickt und dann kommt da nichts, der wird schnell die Lust daran verlieren sich da einzusetzen. --Liebe Grüße, Lómelinde Diskussion 14:37, 9. Jun. 2018 (CEST) Beantworten
Die Frage wäre, ob man via Phab beantragen kann, die Datenbank für deWP zu löschen und neu aufzubauen, selbst wenn das Wochen dauert.--Mabschaaf 14:41, 9. Jun. 2018 (CEST) Beantworten

Beobachtungsliste: Zeitraum

Letzter Kommentar: vor 6 Jahren 5 Kommentare3 Personen sind an der Diskussion beteiligt

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

  • Ich kann ein solches Phänomen bestätigen.
  • Gestern abend war wohl die wöchentliche Software-Aktualisierung.
  • Ich bekam für die Beo und nur diese eine Meldung mw.loader.using is not a function (Zeile 156 von etwas nicht Identifizierbarem in der MW-Software).
  • Das wäre doch recht besorgniserregend.
  • Da ich viele Skripte zu laufen habe, bin ich schlechtes Versuchskarnickel für ein reines Gewissen.
  • Nach Abschalten meiner Skripterei ging es fehlerlos, auch nach Wiedereinschalten der Skripte.
  • Vermutlich gibt es im Browser-Gedächtnis, womöglich localStorage, ein Relikt der vergangenen Woche, das inkompatibel mit dem Beo-JS ist. Nachdem das einmal rausgeschmissen wurde, ist alles wieder heil.
  • Irgendwie ist derzeit auch die Vorgabe am Migirieren von 3 auf 7 Tage, aber das wäre eine andere Geschichte.
Viel Erfolg --PerfektesChaos 10:26, 13. Jul. 2018 (CEST) Beantworten
Hallo ihr beiden, wollte auch schon schreiben: kann Winof bestätigen (FF 61.0.1, 64-Bit), seit gestern desgleichen. Neuerdings aber: Wenn ich heute als erstes über ein Lesezeichen die Beo direkt aufrufe, werden die letzten Tage mit 250 Edits angezeigt, obwohl die „Anzuzeigende Zeitperiode": auf „1 Stunde" steht, obgleich auf „7 Tage" in den Voreinstellungen festgelegt. Gruß, --Wi-luc-ky (Diskussion) 10:53, 13. Jul. 2018 (CEST) Beantworten
@PerfektesChaos: Danke für die Hinweise. Ich verwende normalerweise den pageLinkHelper von Dir und Fliegelflagel von Schnark. Ich habe testweise meine common.js geleert und gepurged, aber das hat leider an dem Problem nichts geändert.
Ein Work-around, der funktioniert und mit dem ich leben kann: Ich habe in den Einstellungen den Zeitraum jetzt von 7 auf 8 Tage erhöht. Diese 8 Tage bleiben jetzt auf der Beobachtungsliste erhalten und werden nicht zurückgesetzt. Aber sobald ich wieder 7 Tage auswähle, wird es jedes Mal wieder auf 1 Stunde zurückgesetzt.
@Wi-luc-ky: Evtl. war das ein Missverständnis. Beim ersten Aufruf der Liste werden zwar die Edits von 7 Tagen angezeigt, aber das Formularfeld wird auf 1 Stunde zurückgesetzt. Sobald man nun auf den „Anzeigen"-Button klickt, werden tatsächlich nur die Edits der letzten Stunde angezeigt. Wenn man – wie ich – gewohnheitsmäßig öfters mal auf diesen Button klickt, um die Liste zu aktualisieren, dann muss man jedes Mal vorher das Formularfeld auf 7 Tage zurücksetzen.
Ahoi --Winof (Diskussion) 14:43, 13. Jul. 2018 (CEST) Beantworten
So war’s gemeint, Winof, und so ist es auch bei mir beim Nachladen. Habe jetzt auch auf „8 Tage" erhöht; „6 Tage" gingen auch. Die verflixte 7 halt. (Der Vorschauknopf ist eigentlich groß genug, um solche Verschlimmbesserungen zu vermeiden; aber nicht alles ist gleich durch Vorschau überblickbar, leider.) Gruß, --Wi-luc-ky (Diskussion) 15:15, 13. Jul. 2018 (CEST) Beantworten

Edits mit Tablet / Ipad wieder erschwert. 9.9.2018

Letzter Kommentar: vor 6 Jahren 11 Kommentare4 Personen sind an der Diskussion beteiligt

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

@Orik: Welcher Editor wird genutzt? Welcher Browser und welche Browserversion werden genutzt? Welche Betriebssystemversion wird genutzt? Geschieht dies auch wenn explizit safemode=1 gesetzt wird? --Malyacko (Diskussion) 12:13, 1. Aug. 2018 (CEST) Beantworten
SORRY! DASS ICH MICH SO SPÄT MELDE, @Malyacko: ICH BIN IN ferien mit nicht so gutem Iternetanschluß. ich benutze den SAFARIBROWSER AUF EINEM IPAD MIT DEM (Betriebssystem für mobile GERÄTE) IoS 10.33. DIE VERSION von SAFARI IST NICHT ERSICHTLICH UND WIRD jeweils MIT DEM BETRIEBSSYSTEM ERneuert. DEr FEHLER MIT DER Klein- und GRossschreibung tritt nur beim editieren in Wikipedia auf. gruß --Orik (Diskussion) 00:48, 5. Aug. 2018 (CEST) PS: Den Editor kann ich nicht benennen.Beantworten
PS: DER Fehler tritt nur bei Quelltextbearbeitung auf.--Orik (Diskussion) 09:51, 12. Aug. 2018 (CEST) Beantworten
PROBLEM IMMER NOCH NICHT GELÖST. --Orik (Diskussion) 23:06, 30. Aug. 2018 (CEST) Beantworten
Seit heute funktioniert die Groß- und Kleinschreibung mit dem Tablet wieder. Ebenso funtioniert das Löschen längerer Texte wieder, weil die Rückschrittaste nach einem bestimmten Anlauf wieder ganze Worte löscht.Orik (Diskussion) 01:50, 5. Sep. 2018 (CEST) Beantworten
Leider ist die Zeit des Funktionierens wieder vorbei.Die Regelung für Groß- und Kleinschreibung meines Tablets ist durch Wikipedia im Quelltextmodus ausgeschaltet, ebenso das schnelle Löschen mit der Rückschritttaste. Hilfe erbeten. Orik (Diskussion) 22:18, 9. Sep. 2018 (CEST) Beantworten
Heute geht die Groß- und Kleinschreibung auf zwei Tablets wieder. Hat das was mit den Änderungen von Wikipedia zu tun, die Montag morgen bekannt gemacht werden? --Orik (Diskussion) 12:05, 10. Sep. 2018 (CEST) Beantworten
Änderungen serverseitig an der Wiki-Software erfolgen donnerstags. --Count Count (Diskussion) 12:10, 10. Sep. 2018 (CEST) Beantworten
SEIT DONNERSTAG FUNkTIONIEREN MEINE EDITS MIT MEINEM TABLET NICHT MEHR. ICH kann praktisch NUR NoCH GROSS SCHREIBEN? KANN das nicht mal aufhören? Orik (Diskussion) 09:08, 5. Nov. 2018 (CET) Beantworten
Hast du es mal mit einem anderen Tablet, einem anderen Browser und/oder unangemeldet versucht? Ich bin mir ziemlich sicher, dass das Problem auf deiner Seite liegt. --Magnus (Diskussion) 09:12, 5. Nov. 2018 (CET) Beantworten

Menüzeilen nach unten verrutscht

Letzter Kommentar: vor 6 Jahren 5 Kommentare3 Personen sind an der Diskussion beteiligt

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

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

und die Zeile

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

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

Momentan hat WMDE so eine Art Banner geschaltet, zur Gewinnung neuer Freiwilliger (wird nur Uangemeldeten gezeigt). Sieht so ähnlich aus wie die Banner bei den Spendenaktionen. Da du dieses Banner nicht erwähnt hast, vermute ich, daß du es nicht siehst?
Diese Banner kann man natürlich abschalten, via css, was unangemeldet nicht so ohne weiteres geht. Vielleicht hast du einen Werbeblocker o. ä., der das Banner löscht, den Text aber nicht wieder nach oben schiebt?
Unangemeldet ist bei mir jedenfalls das Banner sichtbar (kein Werbeblocker), der Text Artikel — Diskussion — Lesen — Bearbeiten etc. rutscht allerdings auch etwas tiefer und hängt mittig auf der Linie, die eigentlich ihren unteren Rahmen bildet. FF 61.0.1 übrigens.
Gruß --Schniggendiller Diskussion 01:46, 7. Aug. 2018 (CEST) Beantworten
Hallo Schniggendiller, erst mal Danke für die Antwort. Wahrscheinlich hat das zum Teil wirklich was mit dem Banner zu tun, das ich tatsächlich nicht sehe in Folge meines Werbeblockers uBlock Origin, den ich auf Grund deiner Überlegungen mal vorübergehend abgeschaltet habe. Allerdings arbeitete dieser bis dato in der Hinsicht sehr zuverlässig, als dass freiwerdender Platz mit informativem Seiteninhalt befüllt wird. Das passiert in diesem Fall aber anscheinend nur mit dem Artikeltext/Hilfetext. Das Banner scheint nur mit den entsprechenden Seiten gekoppelt zu sein nicht aber mit der irgendwie überlagernden Menüzeilenebene. Da haben die Banner-Installateure vermutlich einfach nur eine platzhaltende Leerfläche eingebaut, die von uBlock Origin nicht als zu entfernende bzw zu blockierende Adware eingestuft wird und somit erhalten bleibt und dem Hochrutschen der Menüzeilen im Wege steht. (Sorry meine laienhafte Beschreibung). Dieser Aufbau der Bannereinblendung scheint sich diesmal aber von bisherigen Verfahren zu unterscheiden, da ich davon ausgehe, dass uBlock Origin mich im Laufe der Zeit schon öfters von WP-Bannern befreit hat, ohne dass dieses Phänomen bisher auftrat. Wäre also ein feiner Zug von den "Banner-Machern" wieder zum bisherigen Verfahren zurück zu kehren.--Ciao • Bestoernesto 03:15, 8. Aug. 2018 (CEST) Beantworten
Okay, da es also wohl tatsächlich am Banner liegt, lasse ich mal ein Ping da für Benutzer:Stefan Schneider (WMDE). Gruß --Schniggendiller Diskussion 12:49, 8. Aug. 2018 (CEST) Beantworten
Hallo ihr Beiden, vielen Dank, dass ihr mich nochmal kontaktiert habt. Dann können wir das nämlich hoffentlich auch für die Zukunft korrigieren. Ich gebe das auf jeden Fall an die Software-Entwicklung weiter. Die Banneraktion ist seit heute 14:30 Uhr vorbei, daher sollten nun erst mal keine weiteren Probleme auftauchen. Lieben Gruß, Stefan Schneider (WMDE) (Diskussion) 14:45, 8. Aug. 2018 (CEST) Beantworten

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

Letzter Kommentar: vor 6 Jahren 12 Kommentare5 Personen sind an der Diskussion beteiligt

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

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

Die dort verwendete Programmierung schließt offenkundig alle Artikel jünger als (90) Tage von der Indexierung aus, völlig egal ob diese „patrouilliert" sind oder nicht.
Das würde heißen, dass auch bei uns ein Artikel zu einem aktuellen Ereignis, der noch nicht ein Alter von x Tagen erreicht hätte, von Suchmaschinen nicht erwähnt werden soll. Dabei ist es völlig egal, ob er gesichtet wäre oder nicht.
Das wird wohl kaum auf breite Zustimmung stoßen.
Um die Frage im Sinne der Überschrift zu beantworten: Technisch möglich schon, auch diese Bedingung in der Programmierung einzubauen; aber da es nur sehr wenige Wikis beträfe, die Programmierung deutlich verkomplizieren und schwerer zu pflegen macht und der allgemeine Trend eher zu Vereinfachung und Entschnörkelung geht, werden die Entwickler kaum mitspielen.
Eine lokale Alternative wäre es, dass du einen Bot-Betreiber überredest, ein NOINDEX (ggf. in auffindbarer Vorlage, mit Kategorisierung als „Neuer Artikel") in die noch nie gesichteten Artikel einzubauen, und der erste Sichter oder ein späterer Bot-Lauf diese Vorlage dann wieder herauseditiert, wobei Entfernung durch den anlegenden Nicht-Sichter zwecklos wäre, weil der Bot immer wieder kommt.
VG --PerfektesChaos 17:20, 8. Aug. 2018 (CEST) Beantworten
Danke für die schnelle Antwort! Ein kurzer Einwand: In der enWP werden patroullierte Seiten durchaus schon früher freigegeben („Articles younger than 90 days are not indexed, unless they have been patrolled and do not have the {{NOINDEX}} template on them (or a template that transcludes the {{NOINDEX}} template, such as the speedy deletion templates)." Fettung von mir), siehe auch en:WP:NPP: „Only New Page Reviewers can mark pages as 'Reviewed' or 'Patrolled' which releases them for indexing by search engines." Das mit dem Bot ist aber eine gute Idee! --Count2 (Diskussion) 17:26, 8. Aug. 2018 (CEST) Beantworten
Bei einem Bot gibt es eine Race-Condition zwischen dem Crawler der Suchmaschine und unserem Bot. Wer schneller ist, gewinnt. Das wäre dann so eine halbe Sache, die nicht gar so toll funktioniert. --Wurgl (Diskussion) 17:35, 8. Aug. 2018 (CEST) Beantworten
Stimmt auch wieder inbesondere da neue Artikel extrem schnell von Google indexiert werden. Da das aber in der enWP so ähnlich funktioniert (nur mit "patrolled" anstelle von "flagged revisions") wäre das ja vielleicht doch gar nicht so schwer zu implementieren? --Count2 (Diskussion) 17:38, 8. Aug. 2018 (CEST) Beantworten
  • In der fraglichen Server-Programmierung steht bis heute nur eine Abhängigkeit vom Alter der Seite, egal was sonst noch für ein Status vorläge. Mechanismen, die das übersteuern würden, etwa durch temporären Einbau eines INDEX, sind bei der enWP nirgendwo konkretisiert worden. Es sind erstmal einfach nur Behauptungen auf der Projektseite.
  • Wer das race gewinnen würde, unser lauschender Bot oder ein lauschender Crawler, ist offen. Wenn beide das Ohr am selben Kanal haben, klar. Aber wenn wir einführen würden, dass für 24 oder 48 Stunden nach Anlage im ANR das serverseitige NOINDEX automatisch greifen würde, dann wäre Zeit genug für SLA und erste QS, und auch ein Bot könnte ganz in Ruhe eine entsprechende Vorlage einbauen, falls nicht von Sichter angelegt, und könnte damit auch noch ein sichtbares Kästchen mit einem grünen Bäumchen generieren: „Dieser Artikel ist noch ganz jung, wir kennen den selbst noch nicht richtig."
VG --PerfektesChaos 17:48, 8. Aug. 2018 (CEST) Beantworten
Die Idee mit dem Bäumchen ist Klasse! --Wurgl (Diskussion) 17:54, 8. Aug. 2018 (CEST) Beantworten
Hmm, irgendwie/irgendwo ist die Entscheidung nach patrouilliert aber implementiert. So enthält der neue noch nicht patrouillierte Artikel (削除) en:USA-130 (削除ここまで) en:White_N3rd <meta name="robots" content="noindex,nofollow"/> während der autopatrouillierte Artikel en:Sorcerer_of_Siva es nicht enthält. --Count2 (Diskussion) 18:04, 8. Aug. 2018 (CEST) Beantworten
Hier ist die Dokumentation dazu und hier ist der Sourcecode (Function shouldShowNoIndex()). Bei uns wird die Indexierung wohl in setRobotPolicy() in der FlaggedRevs extension bestimmt. So werden wohl auch jetzt schon nur gesichtete Versionen bei uns indexiert, wenn der Artikel gesichtete Versionen hat. Wenn der Artikel aber noch nie gesichtet wurde, zieht die Mediawiki-Standardstrategie. --Count2 (Diskussion) 19:02, 8. Aug. 2018 (CEST) Beantworten

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

Auch nur ein kurzer Hinweis: Google crawlt (fast) keine Seiten in Wikipedia, sondern verwendet verschiedene andere Quellen wie die Letzten Änderungen, ORES, Wikidata, RESTBase (Parsoid), Action-API, etc. –Schnark 11:58, 9. Aug. 2018 (CEST) Beantworten
Neue, noch nie gesichtete Artikel, findet Google jedenfalls schnell und indexiert sie auch umgehend. Soweit mir bekannt, beachtet Google aber meta noindex und könnte damit von einer Indexierung abgehalten werden. --Count2 (Diskussion) 18:18, 9. Aug. 2018 (CEST) Beantworten

Abfrage Benutzer

Letzter Kommentar: vor 6 Jahren 4 Kommentare2 Personen sind an der Diskussion beteiligt

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

Hier habe ich eine entsprechende Datenbankabfrage erstellt: Liste aller Benutzer aus der Kategorie:Benutzer:aus Köln, die in den letzten beiden Jahren mehr als 200 Bearbeitungen (über alle Namensräume) hatten, alphabetisch sortiert. --Count2 (Diskussion) 23:48, 23. Aug. 2018 (CEST) Beantworten
Count2, tausend Dank, das hilft mir sehr weiter, ich hab's schon geforkt und spiele damit rum. Hab's an unserem GLAM-Wochenende gar nicht gesehen, dass das so schnell ging. --elya (Diskussion) 18:44, 26. Aug. 2018 (CEST) Beantworten
Gern geschehen. Mir hat es Spaß gemacht, mich ein bisschen mit dem MediaWiki-Datenbankschema vertraut zu machen. --Count Count (Diskussion) 18:54, 26. Aug. 2018 (CEST) Beantworten

Einleitungen verschwinden

Letzter Kommentar: vor 6 Jahren 11 Kommentare5 Personen sind an der Diskussion beteiligt

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

Tritt der Fehler auch auf, wenn Du dir die Seite unangemeldet anschaust? Gruß --Schniggendiller Diskussion 07:58, 27. Aug. 2018 (CEST) Beantworten
Ja, im angemeldeten genauso wie im unangemeldeten Zustand, steht gleich im ersten Satz ;-) --Ciao • Bestoernesto 08:26, 27. Aug. 2018 (CEST) Beantworten
<quetsch>Ups, nicht mein Tag ... --Schniggendiller Diskussion 11:51, 27. Aug. 2018 (CEST) Beantworten
Tritt der Fehler auch mit anderen Skins auf (und welchen Skin benutzt du)? Sieht nach irgendeinem Tag aus, das uBlock Origin inkonsistent entfernt. --mfb (Diskussion) 09:49, 27. Aug. 2018 (CEST) Beantworten
Skin? Sorry mfb, bin mit diesen IT-Fachbegriffen nicht ganz so fit. Wenn Du damit das Erscheinungsbild der Bedienungsoberfläche meinst, "Vektor" (schon immer, habe an meinen WP-Einstellungen auch seit Monaten nix geändert, somit fallen diese als Ursache für den plötzlichen "Einleitungsschwund" eigentlich aus. Habe aber auf deine Frage hin jetzt mal alle Skins durchprobiert, mit dem gleichen Ergebns)--Ciao • Bestoernesto 16:30, 27. Aug. 2018 (CEST) Beantworten
Welchen Browser verwendest du? --Count Count (Diskussion) 16:33, 27. Aug. 2018 (CEST) Beantworten
Firefox--Ciao • Bestoernesto 16:55, 27. Aug. 2018 (CEST) Beantworten
Hmm, mit Firefox Quantum 61.0.2 (64-bit) und uBlock Origin 1.16.20 auf Windows 10 kann ich das nicht reproduzieren. Welche Versionen hast du? --Count Count (Diskussion) 17:02, 27. Aug. 2018 (CEST) Beantworten
Da scheint sich bei uBlock Origin was getan zu haben. Bei meinem letzten "Problem-Besuch" hier hatte ich noch v1.16.16; Als ich vorhin neu startete wurde dabei anscheinend auch bei mir auf v1.16.20 aktualisiert, und siehe da, nix isses mehr mit "Einleitungs-Schwund". Danke an alle, die hier versucht habe mir zu helfen--Ciao • Bestoernesto 03:26, 28. Aug. 2018 (CEST) Beantworten
@Bestoernesto: Damit Dich uBlock nicht immer beim WP-Genuss stört füge die Seite doch einfach der Whitelist in uBlock hinzu. Ganz einfach: Wenn Du auf einer Seite bist, die mit de.wikipedia.org beginnt (wie zum Beispiel diese hier), einfach das uBlock-Icon in der Symbolleiste des Browsers klicken. Im geöffneten uBlock-Menu dann auf den blauen Ein/Aus-Schalter klicken (Wenn Du den Cursor einen Moment über dem Schalter schweben lässt erscheint auch der Hinweis „Klicken, um uBlock für diese Webseite zu deaktivieren.") uBlock fügt dann de.wikipedia.org automatisch Deiner Whitelist hinzu. Auf anderen Seiten – auch zum Beispiel en.wikipedia.org – bleibt uBlock aktiv. Oder hast Du etwa Bedenken das die deutsche Wikipedia Dich mit Anzeigen für Diätpillen und RTLII-Reality-Shows belästigt? Schönen Tag & mit gruessen von VINCENZO1492 11:37, 16. Nov. 2018 (CET) Beantworten

Koordinaten verdecken erste Zeile in Infoboxen

Letzter Kommentar: vor 6 Jahren 3 Kommentare2 Personen sind an der Diskussion beteiligt

In der Benutzeroberfläche Modern verdecken die Koordinaten die erste Zeile der Infobox bei Artikeln, die sowohl Koordinaten als auch Infoboxen haben, z.B. Flughafen Berlin-Tegel. XGA-Auflösung, Windows 7 Professional, Opera und Firefox. Dies ist als Fehlermeldung gedacht, falls dies der falsche Ort dafür ist, bitte um eine entsprechende Meldung. Der Fehler ist mir nur in der deutschen Wikipedia aufgefallen, die englische, französische und schwedische Wikipediaversionen sind nicht betroffen. --K1812 (Diskussion) 16:40, 20. Sep. 2018 (CEST) Beantworten

Danke, der Modern-Fehler ist bekannt; WD:GEO #Betrifft sämtliche Desktop-Skins.
Kannst ja da mal aufschlagen und etwas drängeln.
LG --PerfektesChaos 16:51, 20. Sep. 2018 (CEST) Beantworten
Danke, ich werde vorerst den Weg des geringsten Widerstands gehen und einfach Skin wechseln. K1812 (Diskussion) 17:44, 20. Sep. 2018 (CEST) Beantworten

Fehlermeldung, kein Edit möglich

Letzter Kommentar: vor 6 Jahren 20 Kommentare4 Personen sind an der Diskussion beteiligt

Ich bekomme seit ein paar Tagen beim Editfenster in Safari keine Werkzeugleiste mehr und dazu folgende Fehlermeldung:

Vorlagenmeister 0.593 * BETA * 2018年08月25日:
init()
'undefined' ist not a function (evaluating
'elem.getAttribute("type")')

Ein Abspeichern eines Edits ist auch nicht möglich und wird mit derselben Fehlermeldung quittiert. Bei Firefox tritt das Problem nicht auf. Dennoch nutze ich auch gern Safari für meine Wikiarbeit. --Fährtenleser (Diskussion) 08:35, 23. Sep. 2018 (CEST) Beantworten

Hallo Fährtenleser, getAttribute ist "relativ" spät (in Jahren gerechnet) von allen großen Browsern unterstützt (obwohl es dieses schon ziemlich lange gibt). Daher würde ich eher jQuery oder eine andere Möglichkeit im Code des Vorlagenmeisters benutzen. Es kann natürlich auch an etwas ganz anderem liegen, allerdings lässt die Benutzung schon auf modernen Code schließen. Welche Version des Safari hast du denn? -- User: Perhelion 09:04, 23. Sep. 2018 (CEST) Beantworten
PS: (Da hier wohl der "Vorlagenmeister" im Spiel ist) ist Benutzer:PerfektesChaos der richtige Ansprechpartner. -- User: Perhelion 09:10, 23. Sep. 2018 (CEST) Beantworten
(BK)
Mitgelesen; wäre auch so angesprungen.
Der Aufruf getAttribute steht bereits seit 2009 im Vorlagenmeister-Code; so simpel und neu ist dieser DOM-Zugriff aus dem letzten Jahrhundert ohnehin nicht.
Ich weiß von keinen Änderungen mit dieser Auswirkung, nicht 2018年08月25日 und nicht zuvor (2016).
Möglicherweise gab es mit Safari oder MediaWiki in den letzten Tagen eine Veränderung?
Gab es in den gut zwei Wochen zwischen dem 3. September und vergangenem Donnerstag erfolgreiche Bearbeitungen mit Vorlagenmeister unter Safari?
Ich habe ein Debugging-Problem, da ich keinerlei Safari so in Reichweite hätte, dass ich darunter sinnvoll Software-Entwicklung betreiben könnte.
  • Du würdest dich vermutlich mit einer geänderten Einbindungs-URL (unter WP:BETA) statt Einstellungs-Häkchen anfreunden müssten; dort kann ich Einkreisungs-Testversionen zum genaueren Eingrenzen der Ursache einbauen.
VG --PerfektesChaos 09:33, 23. Sep. 2018 (CEST) Beantworten
Danke euch Beiden für die schnelle Reaktion! Ich habe jetzt mal den Haken bei meiner Einstellung "VisualEditor während der Beta-Phase deaktivieren" rausgenommen ... und siehe da, ich kann wieder mit Safari arbeiten :-) Falls das Problem dennoch erneut auftritt, melde ich mich wieder hier. VG --Fährtenleser (Diskussion) 10:04, 23. Sep. 2018 (CEST) Beantworten
Guten Morgen, da bin ich leider schon wieder. Es hat offenbar doch nicht an der Einstellung gelegen, denn das Problem ist heute morgen wieder unverändert vorhanden. Schlimmer noch: Jetzt kann ich auch die "Glocke" nicht mehr aufrufen. (Zugegebenermaßen ist es ein älterer Safaribrowser, nämlich 5.1.10 Mac. Neuere laufen auf meinem Rechner leider nicht) --Fährtenleser (Diskussion) 07:36, 24. Sep. 2018 (CEST) Beantworten
Dann lag ich mit meiner Vermutung nicht so verkehrt, denn (wie oben verlinkt) wird getAttribute erst von Safari 6 unterstützt. Ein kleines Update sollte also jetzt angebracht sein!? VG -- User: Perhelion 13:27, 24. Sep. 2018 (CEST) Beantworten
@Fährtenleser:
  • Wir brauchen zu jeder deiner Beschwerden auch die Fehlermeldung aus der Konsole.
  • Zum Problem „Glocke" fehlt diese; und daran hat der Vorlagenmeister keine Schuld.
  • Zurzeit zieht jemand durch die MediaWiki-Software und modernisiert bestehende JavaScript-Aufrufe dahingehend, dass auf modernere JavaScript-Eigenschaften zugegriffen wird, die jedoch in älteren Installationen noch nicht verfügbar sind. Dabei vermurksen die schon mal was, wie bereits geschehen.
  • Safaribrowser 5.1 liegt ausweislich mw:Compatibility #Browsers voll im aktuell zu unterstützenden Bereich.
  • Um die Vorlagenmeister-Problematik einzukreisen, nimm bitte das Häkchen aus den Einstellungen raus und füge den nachstehenden Code in deine Benutzer:Fährtenleser/common.js ein:
@Perhelion: getAttribute in dem von Vorlagenmeister verwendeten Kontext ist Teil des DOM von 1997 und ich erinnere mich dunkel, bereits im letzten Jahrhundert damit gearbeitet zu haben. Vorlagenmeister verwendet es seit 2009, und da das ja die ganze Zeit schon mit dem bisherigen Safari funktioniert hatte, kann das mit Safari 5 und 6 nicht stimmen; viele andere haben fast ein Jahrzehnt mit allen möglichen Safari-Versionen und Vorlagenmeister gearbeitet.
VG --PerfektesChaos 15:22, 24. Sep. 2018 (CEST) Beantworten
Okay, danke für die Mühe! Alldieweil hat sich nach dem Rausnehmen des Häkchens, Einsetzten des Codes und Cache-Löschen in Safari leider nichts an der Fehlermeldung geändert. Sie sieht jetzt wie folgt aus:
Vorlagenmeister 0.593009901 * BETA* 2018年09月24日:
init() equipGUI()
'undefined' ist not a function (evaluating
'elem.getAttribute("type")')
Allerdings kann ich Edits wieder absenden, wenngleich die Werkzeugleiste fehlt. In der Konsole finde ich keine Meldung von Safari. Hilft das? Habe ich alles richtig gemacht? (Ich kenne mich da nicht sonderlich gut aus in der Technik) --Fährtenleser (Diskussion) 19:34, 24. Sep. 2018 (CEST) Beantworten

@Fährtenleser:

  1. Du hast alles richtig gemacht.
  2. leider nichts an der Fehlermeldung geändert – Oooh doch. Sie sieht für mich deutlich anders aus; trägt nämlich wichtige Informationen über den Ablauf, wenn du es mal mit oben vergleichst.
    • Ich hatte die in Frage kommende Region gedrittelt, und es ist ein bestimmtes Drittel angesprungen.
    • Innerhalb dieses Drittels habe ich nun auf potentielle Aktivitäten erneut gedrittelt, kann das jetzt teilweise auf einzelne Anweisungen eingrenzen, die dann verraten, wo der Fehler läge.
  3. Wenn du jetzt einfach wieder den Vorlagenmeister betätigst, dann müsste eine andere Meldung mit 593009902 passieren.
    • Die trägt wieder eine Einkreisungs-Info in sich, und dann schaun wir mal weiter.

Viel Erfolg --PerfektesChaos 20:44, 24. Sep. 2018 (CEST) Beantworten

@PerfektesChaos:
Schön! Da ich nicht genau weiß, was du mit „Vorlagenmeister betätigen" meinst, habe ich einmal mit und einmal ohne entsprechendes Häkchen in den Einstellungen ein Edit unter Safari versucht. In beiden Fällen kam folgende identische Fehlermeldung heraus:
Vorlagenmeister 0.593009902 * BETA * 2018年09月24日:
tm_init().buttonWikiEditor()
'undefined' ist not a function (evaluating
'elem.getAttribute("type")')
Immerhin steht ja die Nummer drin, die du erwartet hast. Gruß aus Wuppertal --Fährtenleser (Diskussion) 15:16, 25. Sep. 2018 (CEST) Beantworten

@Fährtenleser: Sodele, und es stand die Einkreisungs-Info mit bei, die ich benötigte, um die Chose auf eine einzige verdächtige Anweisung einzukreisen.

Nun bau doch mal nachstehende Anweisung zusätzlich vor dem Vorlagenmeister in deine common.js ein:

Wenn du dann irgendwas zur Quelltextbearbeitung öffnest, dann müsste das auf der Fehlerkonsole aufschlagen. Damit wäre der Nachweis erbracht, mit dem ich dann höheren Ortes antanzen kann.

Mit anderen als Safari sollte hingegen ein Button mit Safari-Logo als blauer Kreis und Kompassnadel in der Werkzeugleiste 2010 erscheinen, der sich anklicken lässt.

Viel Erfolg --PerfektesChaos 21:31, 25. Sep. 2018 (CEST) Beantworten

@PerfektesChaos: Wow, ich fühle mich wie eine Marionette :-) Danke jedenfalls! Das Ergebnis ist diesmal allerdings wohl nicht befriedigend: In Firefox sehe ich jetzt tatsächlich das Safari-Logo in den Tools, aber der Aufruf des Fehlers in Safari führt (bei identischer Fehlermeldung zu gestern) zu keinem Eintrag in der Konsole – zumindest finde ich keinen Eintrag, in dem Safari vorkommt. Was mache ich falsch? Darüber hinaus werden meine Probleme mit Safari gefühlt von Tag zu Tag größer: Die Glocke klappt (wie schon erwähnt) gar nicht, der Klick auf "Benachrichtigungen" führt zu einer Seite mit endlos laufender Schraffur (wohl eine Art Ladebalken), die Reiter der Einstellungen lassen sich nicht mehr öffnen und bei der Suchworteingabe werde ich jetzt immer zuerst zu der Seite mit den weiteren Suchergebnissen geleitet und nicht mehr direkt zum Artikel. Uff! --Fährtenleser (Diskussion) 06:49, 26. Sep. 2018 (CEST) Beantworten

Morgen, Marionette, dann zieh ich mal wieder am Fädchen: Nimm mal den Vorlagenmeister-Aufruf komplett raus. Der reißt vermutlich die neue Diagnostik-Meldung vorher mit in den Abgrund. Die hätte ich aber gern als definitive Bestätigung, dass es nur an genau dieser Anweisung liegt. Bis dann --PerfektesChaos 10:15, 26. Sep. 2018 (CEST) Beantworten
Hallo Fädenzieher, habe ich gemacht. Jetzt kommt keine Fehlermeldung mehr und ich kann Edits abspeichern; allerdings habe ich keine Werkzeugleiste. In meiner Konsole findet ich auch jetzt keinen Eintrag mit "Safari". Allein das zur entsprechenden Uhrzeit:
26.09.18 13:33:34	SIMBL Agent[203]	warning: failed to get scripting definition from /Applications/Utilities/Console.app; it may not be scriptable.
Ich vermute, das hilft dir/uns nicht weiter. Übrigens: Edits mit Firefox zeigen zur Zeit ein seltsames Verhalten: Die Eingaben sind viel langsamer als meine Finger auf der Tastatur und kommen entsprechend verzögert. Safari mach dahingehend keine Zicken. Ich muss das nicht verstehen, oder? --Fährtenleser (Diskussion) 13:47, 26. Sep. 2018 (CEST) Beantworten
Ich sehe gerade, die Verzögerung lag wohl daran, weil ich zum Editieren dieses Textes nicht nur den Absatz geöffnet hatte, sondern die gesamte, riesige Seite. Puh! --Fährtenleser (Diskussion) 13:49, 26. Sep. 2018 (CEST) Beantworten

Es hilft mir weiter. Mach dir mal nicht meinen Kopp.

  • Offensichtliche Ursache ist der „WikiEditor"; das ist die Werkzeugleiste „2010".
  • Beim Versuch des Vorlagenmeisters, dort einen Button einzufügen, ging es dahin.
  • Nimm jetzt mal dein Häkchen für die „erweiterte Werkzeugleiste" aus deinen Benutzereinstellungen raus.
  • Als Ersatz bau dir den folgenden Schnipsel ein, der im Firefox die Werkzeugleiste wieder startet:
if(typeofwindow.navigator==="object"&&
typeofwindow.navigator.userAgent==="string"
&&window.navigator.userAgent.indexOf("afari")<0){
mw.loader.load("ext.wikiEditor");
}
  • Erwartetes Verhalten: Dein Safari müsste halbwegs wieder laufen, der Firefox hat außerdem eine Werkzeugleiste beim Bearbeiten.
  • Danach schaun wir mal weiter.

Viel Erfolg --PerfektesChaos 16:58, 26. Sep. 2018 (CEST) Beantworten

Hallo „großer Kopp" :-) Das Häkchen für die erweiterte Werkzeugleiste habe ich entfernt.
ACHTUNG: Jetzt könnte es wirr werden: Ich habe dann das Script eingebaut, in dem unten ( "afari" ) steht. In Firefox habe ich ja eine Werkzeugleiste, nur nicht mehr in Sarafi – da du oben von Firefox sprachst. Die Leiste in Firefox änderte sich daraufhin in eine viel umfangreichere – die ich jedoch nicht benötige. In Safari blieb alles beim alten. Auch nachdem ich den String zu ( "Safari" ) geändert habe. Ich habe das Script also wieder entfernt, um in Firefox wieder die alte Leiste zu haben (die reicht, wenn man nur im Quelltext arbeitet und für viele Formatierungen bereits eigene Makros hat) --Fährtenleser (Diskussion) 14:48, 27. Sep. 2018 (CEST) Beantworten

@Fährtenleser:: beim Durchlesen dieses Threads bin ich gerade über folgende Deiner Bemerkungen gestolpert (eher gefallen): (Zugegebenermaßen ist es ein älterer Safaribrowser, nämlich 5.1.10 Mac. Neuere laufen auf meinem Rechner leider nicht). Meine 50¢ dazu: mit einem Mac auf dem nur Safari 5.1 und das entsprechende Betriebssystem läuft – offenbar Snow Leopard – sollte grundsätzlich vermieden werden im Jahr 2018 noch eine Internetverbindung aufzubauen. Im geschäftlichen Bereich (Datenverarbeitung, Netzwerk et al.) darf der auf alle Fälle nicht mehr in Betrieb genommen werden. mit gruessen von VINCENZO1492 12:40, 16. Nov. 2018 (CET) Beantworten

@Vincenzo1492: ja mag sein, aber ich bin privat unterwegs und möchte meine immer noch tadellos funktionierende computerisierende Maschine so lange nutzen wie irgend möglich (wg. ökologischem Fußabdruck und so). Da bin ich eigen :-) Viele Grüße --Fährtenleser (Diskussion) 19:38, 16. Nov. 2018 (CET) Beantworten
Letzter Kommentar: vor 6 Jahren 5 Kommentare3 Personen sind an der Diskussion beteiligt

Wenn man eine Suche nach „Coincoin et les z'inhumains" durchführt, führt der Link zur „Suche in anderssprachigen Wikipedias" im Suchfeld der Zielseite zu dem Text „Coincoin et les z&#39;inhumains". Es wird der Apostroph ' also erst durch seine en:Numeric character reference ersetzt und dann URL-encodiert. (Wie) kann man das durch eine Änderung an MediaWiki:Searchmenu-new beheben? Jaquento (Diskussion) 04:47, 25. Sep. 2018 (CEST) Beantworten

Okay, Kenntnis genommen, schau ich mir die Tage an und veranlasse Maßnahmen, falls solche möglich. LG --PerfektesChaos 11:12, 25. Sep. 2018 (CEST) Beantworten
Das kommt schon falsch in die Nachricht rein, denn {{urlencode:Coincoin et les z'inhumains|PATH}} Coincoin%20et%20les%20z%27inhumains sieht gut aus. MediaWiki:Searchmenu-new. Im MediaWiki-Code wird wfEscapeWikiText verwendet, bin aber gerade unsicher welche Ersetzung besser ist. Lua-Module? Der Umherirrende 19:59, 28. Sep. 2018 (CEST) Beantworten
Schön, dich zu sehen.
Wir werden hierzuwiki wenig Sinnvolles machen können:
Das Problem liegt weder bei Auflösung der Spezialseite Spezial:Suche mit angehängtem Parameter nach dem Schrägstrich, noch bei der Formular-Eingabe, denn die liefern brav https://de.wikipedia.org/w/index.php?search=Coincoin+et+les+z%27inhumains&title=Spezial%3ASuche&profile=default&fulltext=1
Wir können per Lua eine provisorische Reparatur machen und alle an MediaWiki:Searchmenu-new gelieferten Entities wieder zurückbauen, wobei es aber Absicht sein könnte, dass jemand nach einem Entity sucht, namentlich mittels insource (wobei das dann ungültig würde, und escaped werden müsste).
Da hatte wohl jemand zu viel Angst vor Apostroph-Zeichen gehabt.
  • Es scheint nur Apostroph und & zu betreffen; ich habe mal systematisch die üblichen Verdächtigen durchprobiert, aber kein anderes lieferte Entity.
Aufruf der Systemnachricht, wenn korrekt angesprochen:

Der Artikel „Coincoin et les z'inhumains" existiert in der deutschsprachigen Wikipedia nicht. Du kannst den Artikel erstellen (Quelltext-Editor, Anleitung).
Wenn dir die folgenden Suchergebnisse nicht weiterhelfen, wende dich bitte an die Auskunft oder suche nach „Coincoin et les z'inhumains" in anderssprachigen Wikipedias .

Besser wäre eine weltweite Lösung, die dieses Apostroph-Entity gar nicht erst entstehen lässt.
LG --PerfektesChaos 11:13, 29. Sep. 2018 (CEST) Beantworten
MediaWiki ruft hier wfEscapeWikiText auf, damit eventuelle Wiki-Syntax (zwei Apostrophe für Kursiv/Fett etc.) im Suchwort nicht die Nachricht kaputtmachen. Ich habe zwar schon viele Message-Aufrufe gemacht, aber bei den Feinheiten muss ich auch nochmal ausprobieren ob man darauf verzichten kann. Der Umherirrende 20:32, 30. Sep. 2018 (CEST) Beantworten

Bug Edittools (falscher focus)

Letzter Kommentar: vor 6 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt

Kann jemand (Chrome / IE) den Umstand nachvollziehen, dass der Focus mit den "unteren" Edittools beim Umschalten der Syntaxhervorhebung ( ) nicht auf das gewünschte Feld springt? Dann würde ich phab:T164905 wieder öffnen. -- User: Perhelion 10:53, 26. Sep. 2018 (CEST) Beantworten

Breite Formeln und Tabellen werden im mobilen Skin abgeschnitten

Letzter Kommentar: vor 6 Jahren 5 Kommentare4 Personen sind an der Diskussion beteiligt

Könnt ihr euch mal diese Frage ansehen: Wikipedia:Fragen_zur_Wikipedia#Darstellung_der_Wikipedia-Artikel_am_Tablet? Die mobile Seite schneidet breite Formeln und Tabellen ab. Siehe meine Testseite. Besser wäre eine Verkleinerung wie bei Bildern, oder ein Scrollmechanismus. Kann man das durch lokales CSS erreichen? Oder sollten die Entwickler gefragt werden? Einen Phabricator-Task habe ich dazu noch nicht gefunden. — MBq Disk 20:44, 4. Okt. 2018 (CEST) Beantworten

Hallo,
aus meiner Sicht wäre ein Scrollbalken in mobilen Modus eine geeignete Lösung der Problems.
Grüsse --LoRo (Diskussion) 20:28, 5. Okt. 2018 (CEST) Beantworten
Abgeschnitten wird bei mir nichts. Die breite Formel ragt über die Seite hinaus, ja, ist aber durch horizontales Scrollen komplett lesbar. -- hgzh 21:16, 5. Okt. 2018 (CEST) Beantworten
Ja, muss man aber wissen, und einer Formel oder Tabelle sieht man vielleicht nicht an, dass sie rechts weitergeht? — MBq Disk 16:17, 7. Okt. 2018 (CEST) Beantworten
Ich schätze, da wird man wohl bei den CSS-deklarationen was Ändern müssen.
#mw-content-textimg[src*="/wikipedia/de/math/"],#mw-content-texttable{
overflow:scroll;
}
Diese Deklaration sorgt bei allen durch TeX generierten Bildern und Tabellen dafür, das sie einen Scrollbalken verpasst bekommen. Grüße, Victor Schmidt Was auf dem Herzen? 14:40, 13. Okt. 2018 (CEST) Beantworten

Sortierungszeichen

Letzter Kommentar: vor 6 Jahren 2 Kommentare2 Personen sind an der Diskussion beteiligt

Hallo, ich hätte eine (wohl unerfüllbare?) Idee, um die Sortierung zu vereinfachen. Statt dem bisherigen Verfahren soll ein Zeichen zB ¶ eingeführt werden. zB [[Technik ¶Werkstatt]] soll als „Technik Werkstatt" angezeigt werden und „Werkstatt" ist der Sortierbegriff. Geht wahrscheinlich nur weltweit (für alle wikis) und macht viel Umstellarbeit. lG --Hannes 24 (Diskussion) 13:20, 14. Okt. 2018 (CEST) Beantworten

Es gibt bereits einen Umstellungsprozess für Sortierungen, der dann aber rund eine Million Artikel beträfe und ein halbes Jahr intensiver Betreuung bedarf.
Was du meinst, ist ja ein sehr spezieller Einzelfall, der irgendwie den Schrägstrich abzulösen scheint und eine von sehr vielen Möglichkeiten der Bildung von Seitennamen und Strukturierung von Unterseiten anginge. Das ist noch nicht mal in diesem Wiki einheitlich und konsequent, geschweige denn wäre es weltweit und außerhalb der WMF regelmäßig zu erwarten.
Insofern wäre es keine Vereinfachung, weil es dann auch sehr vieler Ausnahmen bzw. besonderer Regeln bedürfte, und alle Leute noch mehr komplexe Regeln und Extra-Syntax lernen müssen.
Und der ANR hat keine Unterseiten, kann also nur den Meta-Bereich betreffen, und wo bleibt jetzt der Namensraum?
Als was sollte denn dann Wikipedia:Technik/Netzwerk/Verschlüsselte Verbindung ohne Schrägstriche angezeigt werden, und ist in Kategorie:Wikipedia:Technik/Netzwerk und Server unter „V" sortiert.
VG --PerfektesChaos 15:15, 14. Okt. 2018 (CEST) Beantworten

RevisionAccessException

Letzter Kommentar: vor 6 Jahren 3 Kommentare2 Personen sind an der Diskussion beteiligt

Beim Aufruf einer alten Version einer Benutzerdiskussionsseite bekomme ich die Fehlermeldung:

Interner Fehler
[W9n5NApAMEoAAJqHzzYAAABM] 2018年10月31日 18:49:24: Fataler Ausnahmefehler des Typs „MediaWiki\Revision\RevisionAccessException"

Weiß jemand was das bedeutet und warum dieser Fehler auftritt? --Count Count (Diskussion) 19:50, 31. Okt. 2018 (CET) Beantworten

Service: Hier ist die erste Version von BD:Honza gemeint. – Doc TaxonDisk.Wikiliebe?! 20:55, 31. Okt. 2018 (CET) Beantworten
übrigens: exportiert man die Versionsgeschichte, wird die erste Version LEER übertragen: BD:TaxonBot/HonzaTestDoc TaxonDisk.Wikiliebe?! 21:01, 31. Okt. 2018 (CET) Beantworten

Unterschiedliche Auswertungsergebnisse

Letzter Kommentar: vor 6 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt

Hallo, wenn ich die Seiten in der Kategorie „Wikipedia:Defekte Weblinks/Bot" aufrufe, dann erhalte ich eine dargestellte Umfangszahl („Folgende 200 Seiten sind in dieser Kategorie, von XXX.XXX insgesamt.") die immer exakt 19 Seiten geringer ausfällt als die Zahl der Seite Wikipedia:WikiProjekt Weblinkwartung/Monitoring(„Vom Botlauf 2015 sind auf XXX.XXX Diskussionsseiten...") und das obwohl serverseitig aktualisiert wurde. Würde den Unterschied gerne nachvollziehen. Jemand eine Idee? Netten Gruß --Bwbuz (Diskussion) 22:37, 31. Okt. 2018 (CET) Beantworten

Vandalismus-Reporting

Letzter Kommentar: vor 6 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt

Gibt es irgendein Tool, dass Vandalismus-Reporting für Disk-Seiten betreibt bzw. dass man damit beauftragen kann nach den Klassikern von KPA oder BNS auf Diskseiten Ausschau zu halten (Bot) oder das die Suche danach (Script) ermöglicht? mit gruessen von VINCENZO1492 12:51, 16. Nov. 2018 (CET) Beantworten

Abrufstatistiken für gelöschte Seiten?

Letzter Kommentar: vor 6 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt

Gibt es irgendeine Möglichkeit Abrufstatistiken für gelöschte Seiten abzurufen? Oder hat jemand eine Idee ob und wie das implementiert werden könnte?

Ich hatte zwei Fälle bei denen Seiten verschoben wurden. In einem Falle hatte ein Admin die ursprüngliche Seite (falscher Titel) schnell gelöscht. Das war ein freundlich gemeinter Serviceedit seinerseits. Ich hatte allerdings vorher gesehen, das diese Falschschreibung in der Woche zuvor rund 30.000 Abrufe hatte. Deshalb hatte ich die Weiterleitungsseite erst mal bewusst nicht zum Löschen vorgeschlagen, sondern nur die Disk dazu. (Und der Admin hatte sie daraufhin auch wieder hergestellt). Kurz vorher hatte ich einen anderen Fall wo ich ebenfalls ein hohe Abrufrate vermutete – nach der Löschung konnte ich diese Vermutung mangels einer gespeicherten Abrufstatistik aber nicht verifizieren. Ich denke es gibt ein paar andere Situationen in denen Abrufstatistiken für gelöschte Seiten praktisch wären. mit gruessen von VINCENZO1492 13:03, 16. Nov. 2018 (CET) Beantworten

Sichten bei Verschiebung BNR -> ANR

Letzter Kommentar: vor 6 Jahren 14 Kommentare6 Personen sind an der Diskussion beteiligt

Beim Verschieben von im BNR erstellten Artikeln in den ANR sind diese nicht gesichtet und müssen von Hand gesichtet werden. Ich habe passive Sichterrechte, und die funktionieren beim Durchführen von Änderungen im ANR auch ganz normal. Das Problem tritt wohl seit Anfang des Monats auf, siehe die oben verlinkten Diskussionen. Das hier ist aber wohl der geeignetere Ort, das zu besprechen. Grüße --bjs Diskussionsseite 15:33, 23. Nov. 2018 (CET) Beantworten

Ich sehe bis in diesen Sommer zurück keine Veränderungen der Programmierung, die relevant wären.
Funktionsprinzip: Wenn die Verschiebung abgeschlossen ist, wird das bekanntgegeben, und die FlaggedRevs lauschen darauf und handeln entsprechend.
  • Technisch: TitleMoveCompleteFlaggedRevsHooks::onTitleMoveComplete
Quellcode includes/MovePage.php
  • Änderungen bis in den Sommer unauffällig.
  • Zeile 420: TitleMoveComplete
  • Da steht etwas von Deferred mit bei, was ich nicht so restlos verstehe. Könnte von einem Server-Verhalten abhängen; vielleicht liegt das Problem außerhalb der funktionalen Programmierung.
phab:diffusion/EFLR
  • backend/FlaggedRevs.hooks.php
  • Programmierung onTitleMoveComplete sieht so aus, wie wir uns das vorstellen: Wenn Seite neu im Namensraum und Sichtungsnamensraum und Sichterrechte, dann erstsichte.
  • So auch langfristig zurückzuverfolgen.
  • Letzte Infrastruktur-Änderung hier Juni 2018 durch den Umherirrenden
  • So Zeugs mit Datenbank-Replikat und Master; vielleicht was auf Ebene der Server-Kommunikation denn in der Programmierung selbst; vielleicht reden die Server nicht mehr schnell genug miteinander.
Genaueres Einkreisen des Zeitpunktes, wann das definitiv noch funktionierte und wann definitiv nicht mehr wäre hilfreich. Ich selbst verschiebe selten BNR→ANR.
VG --PerfektesChaos 16:37, 23. Nov. 2018 (CET) Beantworten
Ich sage mal am 2. November ging es noch automatisch gesichtet am 7. November nicht mehr, wie man auch aus der nächsten Verschiebung am 8. 11. sieht Markierung →ungesichtete Version. Ich suche mal den genauen Tag, am 3. ging es wohl auch noch auch am 4. hier LukeBot →5. 11. (16:08) auch noch 16:36 ok seit spätestens 5. 11. 17:11 geht es nicht mehr siehe auch 18:07 (steht gesichtet von und nicht mehr automatich gesichtet. Genauer geht es nicht weil dazwischen keine passenden Einträge mehr im Logbuch stehen. --Liebe Grüße, Lómelinde Diskussion 17:25, 23. Nov. 2018 (CET) Beantworten
Danke, Ló.
Für die fragliche Woche gab es keine relevanten Änderungen der beteiligten Programmierung, die da irgendwie wirksam geworden wären.
Aber vermutlich gut in diesen Zeitraum fiel eine Änderung von „Benutzer" in „Akteure", also user→actor im Zusammenhang mit wirksamen Aktivitäten.
Ich könnte mir vorstellen, dass der lauschende FlaggedRev in diesem Moment nicht mehr mitbekommt, welche Rechte ein verschiebender Benutzer hat, und mangels Sichterrechten nix mehr macht.
Rest dann mal wer anders.
Schönes Wochenende --PerfektesChaos 18:53, 23. Nov. 2018 (CET) Beantworten

Lewon Astwazatrjan ist mal wieder so ein Fall. Es muss eindeutig mit dem Verschieben zu tun haben. --Schnabeltassentier (Diskussion) 07:34, 26. Nov. 2018 (CET) Beantworten

Das ist ja auch so hier bekannt und bereits auf eine Änderung am 5. November, wo auch immer, zwischen 16:36 und 17:11 eingegränzt worden, (auch hier wurde aktiv nachgesichtet) nur das, was es auslöst wurde noch nicht repariert. Oder an die zuständige Stelle, ich wüsste nicht wo das ist, weitergeleitet worden. Eher wichtig wäre zu erfahren, ob es seit dem Zeitpunkt auch Verschiebungen gab die nicht nachträglich „aktiv" sondern tatsächlich „automatisch" bei der Verschiebung gesichtet wurden. Ich verschiebe auch nur selten. --Liebe Grüße, Lómelinde Diskussion 08:03, 26. Nov. 2018 (CET) Beantworten
ja, da gab/gibt es wohl, bspw. Lavandia-Syndrom oder Grundstein des Friedens wurden im BNR erstellt und von dort verschoben --Schnabeltassentier (Diskussion) 08:29, 26. Nov. 2018 (CET) Beantworten
Zumindest das erste wurde auch aktiv auf gesichtet gesetzt schau hier der Eintrag für 03:03, 26. Nov. 2018 ... sichtete eine Version von Lavandia-Syndrom (Version: 03:01, 26. Nov. 2018).
Ich meine wirklich eine Version wo im Versionsvergleich ein [automatisch gesichtet] steht wie es ehemals üblich war siehe hier Moonfleet der Eintrag beim Verschieben und vergleiche hier den Eintrag beim Verschieben mit [gesichtet von].
Es passt hingegen beim „Grundstein des Friedens" da steht in der VG 00:34, 26. Nov. 2018‎ [automatisch gesichtet]
Es gilt also herauszufinden was da zwischen den Benutzern oder sonstwo anders gelaufen ist.
Vielleicht verschluckt sich der Server, bekommt etwas nicht korrekt übermittelt (überholt sich selbst), das würde, zumindest für mich, auch unten das Phänomen mit dem Echo erklären. Es geht scheinbar manchmal etwas auf dem Weg verloren. --Liebe Grüße, Lómelinde Diskussion 08:58, 26. Nov. 2018 (CET) Beantworten
Oder kann das was mit verschiedenen Benutzereinstellungen zu tun haben? An irgend etwas muss es ja liegen, dass das plötzlich so gehäuft auftritt, Surfer haben sich früher sicher auch verschluckt und das Echon unten hat ja doch eine ganz natürliche Erklärung gefunden. --bjs Diskussionsseite 15:16, 27. Nov. 2018 (CET) Beantworten
Vielleicht gab es doch eine globale Änderung, die mit der hier lokal vorhandenen Sichtungsanwendung nicht zusammen passt. Was ist denn mit dem oben angesprochenen „Aber vermutlich gut in diesen Zeitraum fiel eine Änderung von „Benutzer" in „Akteure", also user→actor im Zusammenhang mit wirksamen Aktivitäten." In diesem Fall denke ich, müssten wir ein Phab Ticket aufmachen. – Doc TaxonDisk.Wikiliebe?! 15:31, 27. Nov. 2018 (CET) Beantworten
Ach Herr Doctor, ich kann so etwas nicht, ich habe null Hintergrundwissen und Phab ist für mich einfach nur fremdartig. Aber mach ruhig da stand ja weiter oben deutlich Zitat: „Rest dann mal wer anders." Wer auch immer sich da angesprochen fühlt. Ich hatte auch schon vermutet, dass es eventuell mit Einstellungen zusammenhängen könnte, beispielsweise ob man den VE verwendet oder abgeschaltet hat, aber das ist eher nur stochern im Nebel. Aber wenn diese Änderung etwas bewirkt hätte so hätte es (nach meiner Logik) im Anschluss gar keine [automatisch gesichtet]en Verschiebungen geben dürfen. Ich würde zunächst bei den Benutzern ansetzen klappt es bei Benutzer A immer ohne Ausnahme und bei Benutzer B hingegen nie dann könnte man schauen was diese unterscheidet. --Liebe Grüße, Lómelinde Diskussion 15:52, 27. Nov. 2018 (CET) Beantworten
naja, mein technisches Fachenglisch ist jetzt nicht so das beste, als dass ich ein phab ticket aufmachen könnte, das das Problem ausreichend verständlich erklärt (denke ich). Und ich weiß auch von unserem "dewiki-definierten" Sichtungssystem zu wenig. Warte mal, @Giftpflanze hat doch ein Botskript im Bereich Sichten laufen, sicher könnte sie die Problematik in einem phab ticket besser schildern als ich. Giftpflanze, würdest Du bitte? – Doc TaxonDisk.Wikiliebe?! 16:42, 27. Nov. 2018 (CET) Beantworten
Also ich fühl mich da jetzt auch nicht sonderlich kompetent, aber ich hab trotzdem mal einen Bug aufgemacht. – Giftpflanze 17:33, 27. Nov. 2018 (CET) Beantworten
vielen Dank, – Doc TaxonDisk.Wikiliebe?! 18:08, 27. Nov. 2018 (CET) Beantworten

You have enabled both this script and the MediaViewer.

Letzter Kommentar: vor 6 Jahren 4 Kommentare2 Personen sind an der Diskussion beteiligt

Wenn ich z.B. in der englischen Wikipedia ein Bild öffne, steht dieser Text darunter: "You have enabled both this script and the MediaViewer. You should decide for one script and disable the other." Ich gebe zu, dass ich mit der Lösung überfordert bin, weiß ich doch nichtmal, was mit "this script" gemeint ist. Mag und kann mir jemand helfen? Vielen Dank. PS: Den MediaViewer (ich kann mich noch gut an viel Ablehnung erinnern) finde ich gut. --Karsten Meyer-Konstanz (D) 10:55, 29. Nov. 2018 (CET) Beantworten

Hilft dir Hilfe:Medienbetrachter oder Hilfe:Multimedia/Medienbetrachter?
Klicke bitte mal ein Bild an und gehe dann auf das Zahnrad. Dort kannst du den Mendienbetrachter an- oder abschalten. Oder schau mal ob es in deinen Einstellungen aktiviert ist.
Ändert sich etwas wenn du das umschaltest?
Ist bei "this skript" ein Link dem du folgen könntest? Ich sehe diese Meldung nicht. Vermutlich müsstest du mal in der englischsprachigen Wikipedia danach fragen, ich weiß nicht was es dort so alles für Gadgets geben mag. Scheinbar ist eines dabei, was nicht gleichzeitig mit dem Medienbetrachter angeschaltet sein sollte. --Liebe Grüße, Lómelinde Diskussion 12:30, 29. Nov. 2018 (CET) Beantworten
Schönen Dank, Lómelinde, ich hab jetzt mal hier gefragt. -- Karsten Meyer-Konstanz (D) 14:46, 1. Dez. 2018 (CET) Beantworten
So, dort hat man herausgefunden, dass die Meldung von Schnarks Script Imagepopups kommt, welches ein Teil von Fliegelflagel ist. Eigentlich habe ich darin Imagepopups nicht aktiviert ... –Karsten Meyer-Konstanz (D) 22:18, 1. Dez. 2018 (CET) Beantworten

Wenn ein Beitrag versteckt wird, bricht die Versionsgeschichte ab

Letzter Kommentar: vor 6 Jahren 9 Kommentare4 Personen sind an der Diskussion beteiligt

Wird ein Beitrag (z.B. aus rechtlich relevanten Gründen) unsichtbar gemacht, so kann die Versionsgeschichte nicht mehr Änderung für Änderung durchgegangen werden. Beispiel: Versionsgeschichte Microsoft Windows 8; am 24.12.2018 um 10:18 wurde ein Beitrag geschrieben, der laut Logbuch wegen Gewaltaufruf versteckt wurde. Klickt man nun auf "gewählte Versionen vergleichen" (mit den letzten beiden) und danach mehrmals jeweils auf "zum vorherigen Versionsunterschied", so kommt man bis zum genannten Beitrag, landet aber auf einer Fehlerseite - und dann nirgendwo mehr hin (ohne "zurück im Browser"). In so einem Fall sollte mindestens auch die Fehlerseite (die ja theoretisch die Änderung zeigen sollte - die ist aber unsichtbar gemacht worden) den Link auf die vorangegangene und auf die nachfolgende Änderung zeigen, ohne aber den Inhalt zu zeigen. D.h. in so einem Fall sollte nur kein eigentlicher Inhalt angezeigt werden (resp. als "Änderungstext" jeweils eine leere Seite) - die Metadaten hingegen sollten mitgeschleppt und nicht auch unsichtbar gemacht werden. --ProloSozz (Diskussion) 18:24, 24. Dez. 2018 (CET) Beantworten

Ich kann das Problem nicht reproduzieren. Der Versionsunterschied sollte dir so angezeigt werden, wie im folgenden Screenshot dargestellt. --Count Count (Diskussion) 19:28, 24. Dez. 2018 (CET) Beantworten
Screenshot
Wenn Du jetzt nochmals auf "Zum nächsten Versionsunterschied" anklickst, dann erscheint nur noch eine Fehlerseite - ohne wieder zum vorhergehenden oder nächsten Fehler kommen zu können. Da steht dann nur noch folgender Text: Fehler: Eine Version dieser Unterschiedsanzeige (183991817) wurde nicht gefunden. Dieser Fehler wird normalerweise von einem veralteten Link zur Versionsgeschichte einer Seite verursacht, die zwischenzeitlich gelöscht wurde. Einzelheiten sind im Lösch-Logbuch vorhanden. Lösch-Logbuch ist verlinkt - das ist aber auch alles. Mehr steht da nicht mehr - insbesondere kommt man weder zur vorhergehenden, noch zur nächsten Versionsänderung. Genau gleich sieht's von nachfolgenden Versionen aus, wenn man zurück geht. --ProloSozz (Diskussion) 02:09, 25. Dez. 2018 (CET) Beantworten
Man kann "von weiter hinten (vorwärtsgehend)" oder "von weiter vorne (rückwärtsgehend)" auf die Fehlerseite gelangen - sie sieht in beiden Fällen gleich aus - und ohne "zurück (im Browser)" oder einem Klick in die Titelleiste (Artikel, Bearbeiten, Versionsgeschichte etc.) kommt man direkt im Fenster nirgendwo mehr hin ... --ProloSozz (Diskussion) 15:06, 26. Dez. 2018 (CET) Beantworten
(削除) Das scheint nicht beim "klassischen", sondern nur beim "verbesserten Diff" (Benutzer:Schnark/js/diff) aufzutreten. (削除ここまで) --FriedhelmW (Diskussion) 15:20, 26. Dez. 2018 (CET) Beantworten
Auf meiner Disk geht diese Diff nicht, und afaik habe ich keinen Schnark geladen. Grüße vom Sänger ♫ (Reden) 16:20, 26. Dez. 2018 (CET) P.S.: Schnell zu findende versteckte Beiträge wären die von diesem Nutzer Beantworten
Jetzt kann ich das ebenfalls reproduzieren. Genauere Fehlerdarstellung: Bei der versuchten Anzeige eines Versionsunterschieds von der Vorversion ausgehend zur gelöschten Version (diff=next) und von der Folgeversion zurück zur gelöschten Version (diff=prev) kommt keine Fehlermeldung. Sobald aber von der gelöschten Version aus zur Vorgängerversion oder Nachfolgeversion der Versionsunterschied angezeigt werden soll kommt die Fehlermeldung. Bei einem Account mit Admin-Flag wird der Versionsunterschied aber auch in diesen Fällen korrekt analog zum ersten/zweiten Fall angezeigt. Hier findet also offensichtlich bei der Abarbeitung eine Zugriffsprüfung auf die in der URL übergebene Version statt. Technisch sehe ich dafür keinen Grund, insbesondere da letztlich dieselbe Anzeige rauskommen könnte. --Count Count (Diskussion) 13:02, 28. Dez. 2018 (CET) Beantworten
Jetzt bin ich nicht sicher, ob ich das richtig verstanden habe. Nochmal: geht man von den beiden Beispielen (diff=next und diff=prev) nochmals eins weiter resp. zurück (jeweils hin zur durchgestrichenen Version), dann kommt der Fehler. Ich sag's mal so: daß der gelöschte Text nicht anzuzeigen ist, ist klar und nicht zu beanstanden - dennoch sollten aber die Metadaten angezeigt werden (es besteht ja kein Grund, diese nicht zeigen zu dürfen; nur der Text darf nicht gezeigt werden). Da aber mit der Unsichtbarmachung offenbar auch darauf kein Zugriff mehr besteht, erscheint dann eben der Fehler. Oder anders formuliert: es sollte "normal durchgeklickt" werden können - bei der unsichtbaren Version sollte aber nur kein Text erscheinen (einfach auf der gelöschten Hälfte alles leer), die Metadaten dazu aber schon. --ProloSozz (Diskussion) 14:38, 28. Dez. 2018 (CET) Beantworten
Ich habe in meiner Antwort nur das fragwürdige Verhalten genauer erläutert und eine mögliche technische Erklärung angegeben. Meiner Meinung nach gibt es technisch keinen zwingenden Grund dafür, es so zu implementieren, wie es im Moment implementiert ist, und ich sehe es ebenfalls als Nachteil, da man – wie von dir schon dargestellt – sich deshalb nicht von Diff zu Diff hangeln kann. Wenn ich Zeit habe, erstelle ich einen Bug Report/Feature Request im Phabricator. --Count Count (Diskussion) 14:54, 28. Dez. 2018 (CET) Beantworten

Vandalistische Änderungen sollten nicht nachträglich gesichtet werden (削除) können (削除ここまで) müssen

Letzter Kommentar: vor 6 Jahren 24 Kommentare5 Personen sind an der Diskussion beteiligt

Situation: eine noch ungesichtete vandalistische Änderung wird rückgängig gemacht., indem bei der Sichtung die Änderunge verworfen werden und der Button "sichten" NICHT geklickt. Klickt man sich dann aber durch die Versionsgeschichte hindurch, wird man auf gefordert, die unerwünschte Änderung zu sichten. Das ist ein Unding - dieser Version wurde ja ganz bewußt die Sichtung verweigert (resp. sie für nicht angebracht verworfen). Nun gut: die Frage ist, ob die unerwünschten Versionen auch gesichtet werden sollen ... ich erachte es jedoch als eher angebracht, so einer Version die Sichtung zu verweigern - sie also gar nicht für "gültig und erledigt" zu erklären. Oder sollen solche Versionen prinzipiell auch als "gesichtet" erklärt werden? Beispiel: faule edits einer IP. --ProloSozz (Diskussion) 12:45, 27. Dez. 2018 (CET) Beantworten

Dürfte ich dich erstmal höflichst zum Ausschneiden hier und zum Transfer nach WP:VV bitten?
Diese Werkstatt beschäftigt sich mit der Reparatur vorhandener Features; Vorschläge für neue Konzepte werden hier insbesondere nicht unter organisatorischen und strategischen Aspekten erörtert.
VG --PerfektesChaos 17:02, 27. Dez. 2018 (CET) Beantworten
Sorry, nein! Ich gehe eigentlich mit gutem Gewissen davon aus, daß mit einem Klick auf den Button "Änderung verwerfen", den ich alternativ zum Button "Sichten" drücken kann, das System den Sichtungsstatus einer entsprechend abgearbeiteten Seite als "erledigt" wahrnehmen muß. Es macht keinen Sinn, eine Seite als "ungesichtet" stehen zu lassen, die beim Sichtungsprozeß als "nicht publikationswürdig" verworfen wurde. Der Sichtungsprozeß ist damit erledigt und die (für nicht publikationswürdig erachtete) Version muß später nicht nochmal gesichtet werden (und solange als ungesichtet stehenbleiben, bis explitzit "gesichtet" angeklickt wurde, obwohl ihr die Sichtung verweigert wurde). Ich erachte das als fehlerhaftes Verhalten der jetzigen Software und nicht als zusätzlich zu implementierende Funktion. --ProloSozz (Diskussion) 18:26, 27. Dez. 2018 (CET) Beantworten
Gesichtet bedeutet für mich: Überprüft und für die Veröffentlichung geeignet. Liege ich mit dieser Annahme denn dermaßen daneben? –Karsten Meyer-Konstanz (D) 11:36, 28. Dez. 2018 (CET) Beantworten
Noch besser: Aus WP:Gesichtete Versionen „Eine gesichtete Version ... sagt aus, dass ein regelmäßiger Autor der Wikipedia den Artikel durchgesehen hat und die Version frei von offensichtlichem Vandalismus ist." Damit ist klar, dass Vandalismus nicht gesichtet werden darf. In meinen Augen ist das völlig logisch. –Karsten Meyer-Konstanz (D) 11:45, 28. Dez. 2018 (CET) Beantworten
Das ist aber nicht das hier geschilderte Problem. Es geht darum, dass die zwei prinzipiell identischen Methoden den Vandalismus zu revertieren zu zwei unterschiedlichen Ergebnissen führen:
- Revert per Änderungen verwerfen führt zu einer gesichteten Version vor dem Vandalismus.
- Revert per zurücksetzen führt zu einer neuen, ungesichteten Version ohne Unterschied zu der letzten gesichteten, die extra nachgesichtet werden muss, bzw. der Haken nicht vorausgefüllt ist.
Warum wird ein Revert auf die letzte gesichtete Version nicht immer automatisch als gesichtet angesehen? Der Weg über zurücksetzen ist nämlich aus der Versions- oder Beitragsgeschichte möglich, für die explizite Änderung verwerfen-Methode muss in jeden Artikel einzeln geklickt werden. Habe ich das so richtig verstanden, ProloSozz? Grüße vom Sänger ♫ (Reden) 11:56, 28. Dez. 2018 (CET) Beantworten
Andersrum: ein Klick auf Änderungen verwerfen setzt sehr wohl auf die Version vor dem Vandalismus zurück, hinterläßt aber die verworfene Version als ungesichtet (die dann nachträglich nachzusichten wäre, damit der "gesichtet"-Status für sämtliche Versionen gegeben ist), den Artikel insgesamt aber als gesichtet (und das ist eigentlich unlogisch). Dieses unterschiedliche Verhalten ist insbesondere insofern nicht wirklich nachwollziehbar, als die beiden Klicks auf Änderungen verwerfen resp. Sichten eigentlich für den Sichtungsprozeß als gleichwertig wahrgenomen werden (müßten) - einer der beiden ist anzuklicken, um den Sichtungsvorgang durchzuführen. Beim Klick auf "Sichten" erhält diese Version aber den "gesichtet"-Status, beim Klick auf "Änderungen verwerfen" aber eben nicht, obwohl der Sichtungsprozeß durchgeführt wurde und der Artikel danach als gesichtet gilt (nur die verworfene Zwischenversion aber nicht - sie bleibt ungesichtet zurück und müßte nachträglich nochmals gesichtet werden). --ProloSozz (Diskussion) 14:13, 28. Dez. 2018 (CET) Beantworten

Das Verhalten der Software ist erstmal rational und entspricht den Anforderungen.

  • Insofern ist dies hier, wie bereits von mir angemerkt, die falsche Plattform für die Erörterung.

Der in Rede stehende Unterschied besteht wie folgt:

  • Bei „kommentarlos zurücksetzen" geht es tatsächlich auf eine definierte Version zurück, und deren Eigenschaften werden übernommen.
  • Bei „rückgängig" geht es tatsächlich vorwärts; es wird basierend auf einer ungesichteten Version eine ganz gewöhnliche freie Bearbeitung vorgenommen; mit unbekannten Auswirkungen.
  • Weil die Ausgangsversion ungesichtet war, auf der basierend freies Editieren erfolgt, ist die so entstandene Version ebenfalls sicherheitshalber ungesichtet.
  • Das ist der völlig normale Ablauf.
  • Andernfalls könnte es dazu kommen, dass eine noch zuvor liegende Änderung unbemerkt versehentlich gesichtet würde, und eine Fehlinformation übernommen wird.

Man könnte sich jetzt ein neues Feature wünschen:

  • Wenn die Version, die „rückgängig" gemacht wurde, direkt auf einer gesichteten Version basierte, dann und nur dann solle der vorvorige Sichtungszustand (gesichtet) übernommen werden.
  • Zurzeit geht die Software anders vor: Der gesamte Stapel der Versionen gilt als ungesichtet; Sichtung wirkt sich in der Konsequenz immer nur auf die aktuellste Version aus.
  • Das Feature gibt es rund ein Jahrzehnt; bislang wurde das Verhalten akzeptiert.

VG --PerfektesChaos 12:17, 28. Dez. 2018 (CET) Beantworten

Daß das Verhalten bisher offenbar noch nicht ernsthaft beanstandet worden war, heißt noch lange nicht, daß die Bedienung dazu auch optimal ist. Mich hat es nämlich auch schon gestört, daß ich (als Sichter) zwar eine weitere Version anfügen wollte, ich aber davorliegende Versionen ausdrücklich als ungesichtet hätte stehenlassen wollen (da dort drin Änderungen vorgenommen worden waren, über die ich nicht genügend bewandert war). M.E. ist es aber auch zu unterscheiden, ob nur eine einzieg (vandalisierte) Version zu verwerfen ist (die sollte mit "Änderungen verwerfen" als "gesichtet (und für untauglich befunden)" deklariert werden; lägen jedoch mehrere ungesichtete Versionen davor, sähe das aber anders aus. Das Verhalten ist in der beschriebenen Form eben nur bedingt "rational und nachvollziehbar" - eben aus dem Grund, daß mit anklicken von "Sichten" die Version als gesichtet deklariert wird, und stattdessen mit anklicken von "Änderungen verwerfen" zwar derselbe Sichtungsprozeß durchgeführt wird, die Version dann aber als ungesichtet stehenbleibt. Viel mehr müßte mit Klick auf einen der beiden Buttons ("Sichten" oder "Änderungen verwerfen") "der Sichtungsprozeß vollzogen" und somit die zur Sichtung angestandene Version als gesichtet deklariert werden. Ganz koscher sieht das ganze so nicht wirklich aus - auch wenn eine (nicht offensichtliche) Logik dahinterstehen mag. Möglicherweise sind aber die Definitionen (was heißt "gesichtet" - für den Artikel (insgesamt) resp. für eine einzelne Zwischenversion?) hier erst klarer festzulegen. --ProloSozz (Diskussion) 14:13, 28. Dez. 2018 (CET) Beantworten
Nachtrag: das Problem ist doch, daß eine wie oben beschriebene verworfene Version nachträglich doch noch als "gesichtet (und für gut befunden)" erklärt werden kann, obwohl sie beim regulären Sichten ja schon als "gesichtet (und für untauglich befunden)" erklärt (und somit verworfen) worden war. Genau das sollte doch nicht passieren dürfen - daß eine beim Sichtungsprozeß verworfene Version nachträglich doch noch per Sichtung als für in Ordnung befunden wird. --ProloSozz (Diskussion) 14:25, 28. Dez. 2018 (CET) Beantworten
Der „gesichtet"-Status ist technisch gesehen ein Flag, das für jede Version gesetzt oder gelöscht werden kann, mit gewissen Einschränkungen in der Benutzeroberfläche. Du kannst Versionen also den gesichtet-Status auch wieder entziehen. Praktisch gesehen spielt diese Funktionalität für uns, so wie wir gesichtete Versionen verwenden, aber keine Rolle, da bei uns nur zählt, was die neueste gesichtete Version ist. Denn diese wird nicht angemeldeten Benutzern standardmässig angezeigt und von Suchmaschinen indexiert. Übrigens: Es wird technisch immer nur deine neu erzeugte Version als gesichtet markiert, wenn du beim Editieren die Option „Sichte die letzten Änderungen" anhakst. Genauso wird beim Nachsichten über den Reiter „Ungesichtete Änderungen" immer nur die letzte Version als gesichtet markiert. --Count Count (Diskussion) 15:17, 28. Dez. 2018 (CET) Beantworten

Und nochmal von vorne:

  1. Die Linkbeschriftung lautet „kommentarlos zurücksetzen"; genau das passiert auch.
    • Es wird exakt diejenige Version mit dem Sichtungsflag wiederhergestellt.
    • Verändert werden kann das nicht; Bearbeitungskommentar ist auch nicht.
    • Unter der Linkbeschriftung steht &action=rollback – das ist eine besondere Software-Funktion.
  2. Die Linkbeschriftung lautet „rückgängig machen".
    • Das ist in Wirklichkeit: „Bearbeiten auf Grundlage einer früheren nicht gesichteten Version".
    • Genau so verhält sich diese Funktion auch; völlig korrekt.
    • Unter der Linkbeschriftung steht, wenn du dir freundlicherweise mal die URL angucken würdest, &action=edit&oldid= – es ist eine stinknormale Bearbeitung einer früheren Version.
    • Man könnte sich allenfalls wünschen, dass zuvor noch der Sichtungsstatus der vorangegangenen Version auf die momentane Bearbeitung durch einen Sichter übertragen werden solle, falls der Weg über diesen Button gegangen würde; dazu müsste aber noch ein weiterer Parameter in der URL eingeführt werden.
    • Im Übrigen kannn und darf sich diese Funktion nicht anders verhalten.

Völlig richtig weiterhin, was Count Count gerade anmerkte.

  • Und das ist auch der Grund, warum bewusst nichts für den Sichtungsstatus angenomen wird.
  • Für die zurückliegenden Versionen ist nämlich der Sichtungsstatus nicht beeinflussbar, sondern wurde vererbt.

VG --PerfektesChaos 15:47, 28. Dez. 2018 (CET) Beantworten

Sorry, aufgrund der vielen Nichtfließtextzeilenanfängen rücke ich folgendes nicht ein:

Das ist aber ein anderes Prozedere als der übliche Sichtungsprozeß, der wie folgt abläuft:

  • Man stößt auf eine ungesichtete Seite (oder sucht danach) und es erscheint oben ein Balken:
Dies ist die gesichtete Version, die am TT. Monat 2018 markiert wurde. Es gibt 1 ausstehende Änderung, die noch gesichtet werden muss.(+)
  • Klickt man auf den eingebundenen Link (1 ausstehende Änderung), landet man auf einer Seite Sichte Version mit folgendem Inhalt:
Bitte sichte alle Änderungen (siehe unten), die seit der letzten stabilen Version getätigt wurden.
Du kannst andere Benutzer darauf hinweisen, dass du diese Änderungen sichtest.
  • Darunter werden zwei Buttons Sichten und Änderungen verwerfen anklickbar
  • Mit einem Klick auf Sichten ändern die Buttons in erledigt und gesichtet, Änderung verwerfen (ist aber nicht anklickbar) und Sichtung entfernen
  • Verwirft man stattdessen die Änderungen, geht's auf eine Spezialseite mit folgendem Inhalt:
Mit Abschluss dieser Aktion wird die folgende Änderung an ...Lemma/Titel... verworfen:
* (Unterschied) hh:mm, TT. MMM. JJJJ (IP/Benutzer) (Hinweis)
Dies wird die Seite auf die Version vom hh:mm, TT. MMM. JJJJ zurücksetzen. Zudem ein Zusammenfassungsfeld: Die letzte Textänderung von Spezial:Beiträge/(IP/Benutzer) wurde verworfen und die Version 000000000 von (Benutzer) wiederhergestellt.
  • Es ist der Button Diese Änderungen verwerfen anzuklicken, oder den danebenstehenden Link Abbrechen
  • Klickt man auf den Button (Diese Änderungen verwerfen), kommt man auf den gesichteten Artikel zurück und der Sichtungsprozeß ist durchgeführt.
Geht man nun in die Versionsgeschichte, ist die verworfene Version als ungesichtete Version markiert und der Button Sichten kann dort immer noch angeklickt werden.

Man kann also nachträglich die Vandalismus-Version doch noch sichten - was nicht sein sollte, denn sie wurde als nicht-sichtungswürdig verworfen; diese sollte nicht mehr ohne weiteres einfach doch noch als gesichtet markiert werden können! Dort ist doch das Problem. Denn in den ersten Beiden Sätzen der Erklärung im Kapitel über Gesichtete Versionen steht insbesondere im zweiten Satz dick und fett angestrichen: Sie (die Sichtung) sagt aus, dass ein regelmäßiger Autor der Wikipedia den Artikel durchgesehen hat und die Version frei von offensichtlichem Vandalismus ist. Dies impliziert, daß eine erkanntermaßen vandalismusenthaltenden Version nicht mehr (ohne weiteres) als gesichtet erklärt werden können soll(te), nachdem sie in einem Sichtungsprozeß als vandalismusenthaltend erkannt worden war. --ProloSozz (Diskussion) 17:55, 28. Dez. 2018 (CET) Beantworten

Auf dewiki interessiert im Allgemeinen nur, welches die aktuellste gesichtete Version ist. Dass man eine frühere Version sichten und auch wieder entsichten kann, ist allerhöchstens von akademischem Interesse. Selbst wenn man darauf Wert legen sollte, ist die Möglichkeit, den Sichtungsstatus hin und her ändern zu können, natürlich sinnvoll, einfach deshalb, weil man so Fehler (fälschliche Sichtungen, fälschliche Rücksetzungen) rückgängig machen kann. --Count Count (Diskussion) 18:09, 28. Dez. 2018 (CET) Beantworten
Von mir aus - aber das interessante ist soch, daß dann die letzte gesichtete Version ja nicht die letzte Version ist, der Artikel aber dennoch gesichtet (indem die vorhergehende Version als neue letzte angefügt wird). Klar, kann man so machen; mangelt vielleicht etwas der "technischen Ästhetik"; aber klar geht's dann ins Akademische ... Wobei: eigentlich sollten Versionen, die als nicht-sichtungswürdig erkannt worden waren, auch als "für die Sichtung erledigt" markiert werden können. Derzeit gibt's ja nur ungesichtet (wobei nicht klar ist, ob unbeurteilt oder beurteilt und verworfen wurde) und gesichtet. D.h. also: von einer ungesichteten Version ist nicht unbedingt klar, ob sie beurteilt worden war oder nicht. Sprich: das Flag sollte nicht nur zwei, sondern drei Zustände haben (-1/0/1). Dazu bräuchte es aber wohl ein zweites boolsches Flag ... jaja, und dann würde es kompliziert(er); und das würde dann eine größere Baustelle; schon klar ... --ProloSozz (Diskussion) 18:32, 28. Dez. 2018 (CET) Beantworten

Mir scheint, ProloSozz stört, dass es keine Möglichkeit gibt, eine Version als „schlecht" zu kennzeichnen. Es gibt nur „gesichtet" und „nicht gesichtet", wobei letzteres bedeuten kann, dass sich noch niemand damit beschäftigt hat, aber auch, dass die Version nicht für gut befunden wurde. Es gibt vermutlich in der Versionsgeschichte eines jeden etwas umfangreicheren Lemmas etliche Versionen mit dem Status „nicht gesichtet" – immer können beide Gründe die Ursache sein. Da aber nur die letzte Version zählt, hat das bislang noch niemand gestört. –Karsten Meyer-Konstanz (D) 18:51, 28. Dez. 2018 (CET) Beantworten

Richtig. Der Widerspruch erfolgt daraus, daß "gesichtet" sowohl "beurteilt", als auch "für gut befunden" heißen kann, aber nur letzteres markiert wird - oder mit anderen Worten: wird eine Version verworfen, wurde der Artikel zwar gesichtet - jene Version, auf die der Sichtungsprozeß angewandt worden war, bleibt aber dennoch "ungesichtet" (obwohl sie gesichtet wurde). Dies ist unschön. --ProloSozz (Diskussion) 19:03, 28. Dez. 2018 (CET) Beantworten
Jetzt stellst du die Bedeutung von „gesichtet" aber definitiv falsch dar, ProloSozz. Nein, „gesichtet" bedeutet nicht "beurteilt" ODER "für gut befunden", sondern "beurteilt" UND "für gut befunden"! Denn - wie oben gesagt - DÜRFEN vandalisierte Beiträge nicht gesichtet werden. —Karsten Meyer-Konstanz (D) 21:51, 28. Dez. 2018 (CET) Beantworten
In diesem Fall ist die Bezeichnung "sichten"/"Sichter" aber äußerst unglücklich gewählt resp. gar verfehlt. Denn "sichten" bezeichnet ja (rein von der Wortbedeutung her) jene Tätigkeit, die ein Sichter durchführt - nämlich "Artikelversionen mit Änderungen 'sichten'", und das bedeutet in diesem Zusammenhang ja, daß er sich "die noch unpublizierte Version ansieht resp. 'zu Gesichte führt' (oder eben 'sichtet'), um zu beurteilen, ob sie publikationswürdig ist oder nicht, und diese dann entweder freischaltet oder die Änderung verwirft". Dieser Prozeß des "sich ansehens, beurteilens, entscheidens und freischaltens resp. verwerfens" (an sich) beinhaltet ja das "sichten". Folge: rein sinngemäß ist eine Version, die so "in den Sichtungsprozeß genommen worden war", per definitionem "gesichtet worden" - und damit ist sie "gesichtet". Daß dann nur die freigeschaltete als "gesichtet" deklariert wird, die verworfene aber nicht, ist in sich nicht logisch; denn eine verworfene Version wurde von der Tätigkeit eben auch "gesichtet". Die Folge daraus ist dann: ein Artikel, der zwar gesichtet wurde (und verworfen) bleibt ungesichtet, obwohl er gesichtet wurde, aber nicht als gesichtet markiert wird. Im Umkehrschluß ist dann ein "ungesichteter Artikel" sowohl ein Artikel (resp. eine Artikelversion), die a) noch gar nie gesichtet wurde, oder b) zwar gesichtet wurde, aber nicht als gesichtet markiert wurde. Dieser Zustand ist - gelinde gesagt - schizophren und bar jeder Logik oder Konsequenz, da eine einzige Bezeichnung zwei komplett unterschiedliche Zustände beschreibt ... Die Bezeichnungen sind in dieser Form nicht sinnvoll. Abhilfe könnte sein: ein zwar gesichteter, aber für nicht publikationswürdig erachteter Artikel hat auch eine "Bezeichnung"/Markierung (die noch zu definieren wäre) zu erhalten, damit er von noch nicht gesichteten (=angeschauten) Versionen unterschieden werden kann. Ansonsten ist und bleibt das ganze eine Bastelei - was ja nicht das Ziel sein kann und auch nicht im Sinne der Idee des Sichtens ist. --ProloSozz (Diskussion) 15:24, 31. Dez. 2018 (CET) Beantworten
Die Verwendung der Bezeichnung Sichten ist für diesen Prozess hier im Wikipedia-Jargon etabliert. Im Übrigen gibt es keine verworfenen Artikel. Wenn jemand im Sichtungsprozess einen Artikel oder eine Version als nicht veröffentlichungswürdig beurteilt, dann sollte er Verbesserungen durchführen, Versionen revertieren oder nötigenfalls bei Artikeln einen Löschantrag stellen. Wenn er sich die Arbeit nicht machen möchte, dann bleibt der Artikel oder die Version ungesichtet, bis sich jemand anderes ihrer annimmt. Das Nachsichten dient bei uns auch eigentlich nur dazu, dass Leser möglichst nur Versionen zu Gesicht bekommen, die frei von offensichtlichen Vandalismus sind. Nur bei der Erstsichtung sollte der Sichter mehr Sorgfalt walten lassen. --Count Count (Diskussion) 16:30, 31. Dez. 2018 (CET) Beantworten
Hier ist auch nicht die richtige Stelle, das im Detail zu diskutieren, da es hier ausschließlich um technische Aspekte geht. Für weiterführende Diskussionen am besten Wikipedia:Projektdiskussion oder vielleicht auch Wikipedia Diskussion:Gesichtete Versionen verwenden. --Count Count (Diskussion) 16:33, 31. Dez. 2018 (CET) Beantworten
Sorry, aber was Du schreibst, impliziert, daß nach Vandalismus (der ja nicht für "gesichtet" zu erklären ist und der nichts für die Verbesserung der Artikelqualität beiträgt) dennoch vom Sichter der geänderte Inhalt (in diesem Fall Vandalismus) aufzunehmen und damit der Artikel zu verbessern ist - und das schließt ausdrücklich auch Vandalismus der Art, wenn der der gesamte Text mit irgend etwas obszönem ersetzt wird o.ä. auch mit ein - und das kann es definitiv nicht sein. Und genau solche vandalisierten Versionen werden - bei der Tätigkeit des sichtens durch den Sichter - zwar "gesichtet", bleiben aber dennoch für nichtangemeldete nicht sichtbar - und zwar aus gutem Grund. Fazit: das System in der jetzigen Form mit der jetzigen Bezeichnung kann mit zu revertierenden Versionen (resp. solchen, die keinen Mehrwert bringen) nicht wirklich umgehen, da diese nicht vorgesehen sind (und als ungesichtet stehenbleiben müssen, obwohl sie gesichtet wurden). Und das ist genau der Mangel, der hier angekreidet wird und dem die Bezeichnung so nicht gerecht wird. Und nochwas: ich ging davon aus, daß durch den Sichtungsprozeß eine Version auch dann gekennzeichnet wird, wenn sie zwar (durch den anthropogenen Vorgang des "sichtens") gesichtet wurde, aber nicht für publikationswürdig erkannt wurde, und ging von einem technischen Fehler aus, wenn der Klick auf "Änderungen verwerfen" die Version immer noch so stehen läßt, als wäre sie noch gar nie angeschaut und geprüft (und somit gar nicht gesichtet) worden; deshalb kam das hierhin. --ProloSozz (Diskussion) 18:48, 31. Dez. 2018 (CET) Beantworten
Exkurs (da nicht ursprüngliches Problem, aber selbes Thema): die jetzige Methode der Sichtung von mehreren Änderungen en bloc ist offenbar auch eine Baustelle, da dann alle Zwischenversionen ungesichtet bleiben. Nochmal: die Begrifflichkeit resp. Bezeichnungen ("sichten"; "gesichtet" (Perf. vom Verb sichten); "gesichtete Version", die teilweise etwas anderes bezeichnet als "gesichtet" als Verb) ist verwirrend und ungeschickt und sollte überarbeitet werden, damit klar ist, was was bedeutet. Zudem ist das Prinzip, daß bei Sichtung mehrere Änderungen en bloc nur die allerletzte (die manchmal die wesentlichsten Änderungen gar nicht enhält) als "gesichtete Version" stehenbleibt, zu überdenken. Allenfalls ist in "gesichtete (Einzel-)Version" und "gesichteter Artikel" zu separieren. --ProloSozz (Diskussion) 10:24, 1. Jan. 2019 (CET) Beantworten
Es gibt keinen technischen Fehler und die Diskussion zur Bezeichnung „Sichten" und dem Sichtungsprozess im Allgemeinen ist hier fehl am Platz. --Count Count (Diskussion) 12:32, 1. Jan. 2019 (CET) Beantworten

Buchfunktion / Sammlungen

Letzter Kommentar: vor 6 Jahren 3 Kommentare2 Personen sind an der Diskussion beteiligt

Hallo,

seit einiger Zeit ist die Erstellung von PDF Versionen für Sammlungen hier ausser Betrieb. Ich biete daher diese Funktion auf einem Server an:

http://mediawiki2latex.wmflabs.org/

Leider musste ich die maximale Buchgröße, wegen begrenzter Rechenkapazitäten, auf ca. 200 Seiten beschränken. Auf meinem privaten Rechner konnte ich bereits ein Buch mit 5000 Seiten erstellen.

Ich denke nun darüber nach einen Server aufzubauen, der Bücher bis zu 25000 Seiten erstellen kann. Da mich der Spass ca. 3000 EUR kosten würde, ist es für mich interessant zu wissen ob es hier Menschen gibt die ein PDF von Sammlungen haben wollen welches zwischen 5000 und 25000 Seiten lang wäre. Diese mögen sich entweder hier eintragen oder mich andersartig kontaktieren.

Viele Grüße --Dirk Hünniger (Diskussion) 12:53, 27. Dez. 2018 (CET) Beantworten

Danke, aber ich denke, du solltest dein Geld sinnvoller einsetzen.
Der Trick bei den Wikis ist ja, dass sie permanent aktualisiert und verbessert und erweitert werden, und seien es nur die URL von externen Verweisen.
Das ist bei einem PDF ziemlich statisch, und deshalb kommt man schon seit einem Jahrzehnt relativ weit ab von umfangreichen PDF.
Für den armen Nutzer, der sich 10.000 Seiten in einer einzigen Datei herunterladen solle, sehe ich schwarz. Ich persönlich hätte ohnehin keine Verwendung für ein PDF, vielleicht mal einen einzelnen Artikel zum Verschenken, aber ich würde mich grundsätzlich auf Zusammenstellungen zu weniger als 100 PDF-Blätter beschränken wollen, weil das weder als Datei noch zum Download noch zur kontinuierlichen Aktualisierung sonst noch zu handhaben wäre.
Der Trend geht eigentlich eher zum Online-Lesen wild ausgewählter Artikel-Anfänge auf einem Smartphone, denn ein statisches 1000-Seiten-Buch zu einem Thema.
Auf wmflabs.org für dich ohne Geldmittel mit PDF-Generierung zu experimentieren ist sicher eine bereichernde Erfahrung. Dort mag für 24 Stunden ein PDF bereitgehalten werden, und dann ist es halt futsch, dann langt auch der Platz.
VG --PerfektesChaos 16:58, 27. Dez. 2018 (CET) Beantworten

Hi, im Moment werden die PDFs nur eine Stunde gehalten. Deine Idee Inhalte länger zu speichern ist eigentlich ganz gut. Immerhin kann man mit einem Rechner für 1000 EUR in einem Jahr alle Artikel der deutschen Wikipedia in PDFs verwandeln und kann sie dann innerhalb von Sekunden zusammen tackern. Aber du hast natürlich recht: aktuell ist das dann nicht. Aber es wurde mir bereits von Zeitgenossen berichtet die sich 3000 Seiten gedruckte Wikipedia Artikel in ihren Schrank stellen und aktuell sind die dann auch nicht. Aber im Moment habe ich eh keine Zeit soetwas zu starten. Aber das kann ja noch kommen.--Dirk Hünniger (Diskussion) 18:00, 27. Dez. 2018 (CET) Beantworten

NichtAnzeige bildartiger Elemente in der HomePage

Letzter Kommentar: vor 6 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt
Bei mir wird in Eurer Homepage links oben Einiges nicht angezeigt. Dass da etwas ist bzw. sichtbar sein sollte, erkenne ich an dem Zeigefinger-Symbol, zu dem der MausZeiger in dieser Ecke wird.
 Ich würde mir in der Hilfe als oberste Rubrik eine Überschrift wie etwa: "Einstellungen im Browser als Voraussetzungen für die vollständige Anzeige der Website" (es darf auch kürzer sein) wünschen.
 Ich habe z.Z. noch keine E-Mail-Adresse und kann also nur ab und zu nachschauen, ob es in der Hilfe so etwas, inzwischen, gibt.
 Des weiteren vermisse ich eine bereits in der Homepage sichtbare Möglichkeit zum Mitteilen von Hinweisen, die: keine Frage beinhalten/darstellen UND auch keine bestimmte Stelle in einem Text betreffen, also etwa: zum Layout oder zur Funktionalität und BenutzerFreundlichkeit.
 Soweit es vorhandenen Text betrifft, wäre es ideal, wenn der Benutzer einfach: den MausZeiger in diese Stelle schieben könnte und dann über ein ContextMenü so etwas wie: "Mitteilung", "Kommentar" oder "Verbesserungsvorschlag" auswählen könnte, was sich dann automatisch auf diese Stelle im Text beziehen müsste.
 Bei mir ist die Zeile mit den MenüElementen: "Lesen Quelltext bearbeiten Versionsgeschichte" und das SuchFeld von ober her in die Überschrift "Wikipedia Technikwerkstatt neuen Abschnitt hinzufügen" gerutscht.
 Das ist aber nicht nur in dieser Seite, sondern in allen Seiten so.
 Möglicherweise liegt das daran, dass Eure Website die bei mir (in meinem Windows 8.1) vom Standard abweichend eingestellten Größen von Überschriften nicht berücksichtigt.

(nicht signierter Beitrag von 77.7.111.40 (Diskussion) 23:54, 8. Jan. 2019)

Zu den Verrutschten Menüpunkten: Kann es sein, das du auf einem Mobilgerät ohne JavaScript-Unterstützung unterwegs bist? Normalerweise wird nähmlich Mittels JavaScript so viele von diesen Reitern im Dropdownmenü versenkt, bis das ganze eben nicht in die Überschrift rutscht, weil sonst kein Platz ist. Wenn du auf einem Mobilgerät unterwegs bist, empfehle ich dir , die Mobile Version von Wikipedia unter https://de.m.wikipedia.org zu benutzen. Diese ist extra für Bildschirme mit kleiner Breite wie auf Smartphones entwickelt worden. Victor Schmidt Was auf dem Herzen? 19:57, 16. Jan. 2019 (CET) Beantworten

Zeilenumbruch bei Aufzählung in Infobox

Letzter Kommentar: vor 6 Jahren 4 Kommentare3 Personen sind an der Diskussion beteiligt

Hallo, fällt mir gerade erneut auf: Bei einem Zeilenumbruch bei einer Aufzählung in einer Infobox passt der Zeilenabstand nicht, der Text "klebt" aneinander. Aktuelles Beispiel: Die Besetzung bei Diamond Life. --Magnus (Diskussion) 12:21, 16. Jan. 2019 (CET) Beantworten

Das könnte daran liegen die Zeilenhöhe →wurde eingeschränkt, ich zeige dir mal was passiert.
Normale Höhe
Umbruch
Umbruch  Ok
style="line-height:85%;"
Umbruch klebt
Umbruch klebt Rotes X oder Kreuzchensymbol für neinN
Frag Mal XanonymusX. --Liebe Grüße, Lómelinde Diskussion 12:59, 16. Jan. 2019 (CET) Beantworten
Ja, ist bekannt. Habe ich erst mal zugunsten einer stabilen Umsetzung von Aufzählungspunkten in besagter Infobox in Kauf genommen, aber werde ich bei Gelegenheit sicher noch einmal anpassen. Kann leider noch ein bisschen dauern, es dürfen sich also gerne auch andere daran versuchen. Gruß–XanonymusX (Diskussion) 13:02, 16. Jan. 2019 (CET) Beantworten
Ok, danke euch beiden. --Magnus (Diskussion) 13:04, 16. Jan. 2019 (CET) Beantworten

Edittextfeld beim Sichten zu kurz?

Letzter Kommentar: vor 6 Jahren 7 Kommentare2 Personen sind an der Diskussion beteiligt

Anmerkung: Eintrag aus Wikipedia:Fragen_zur_Wikipedia nach hier verschoben, Diskussion ist dort beendet --Bicycle Tourer (Diskussion) 21:58, 21. Jan. 2019 (CET) Beantworten

Zusammenfassung: Es gibt eine Längenbegrenuzung von 200 Zeichen für das Zusammenfassungsfeld, welches im Zusammenhang von Rücksetzungen beim Sichten angeboten wird. Wenn man aus der Versionshistorie heraus zurücksetzt, wird über den Quellcode-Editor das übliche 500 Zeichen lange Feld angeboten. Dies führt dazu, dass man beim Zurücksetzen aus dem Sichten heraus keine ergänzenden Worte zu dem vorgeschlagenen Text hinzufügen kann, da Limit durch den Vorschlag bereits überschritten. Kann die Länge des Feldes beim Sichten auf 500 Zeichen angepasst werden? Danke und VG --Bicycle Tourer (Diskussion) 21:58, 21. Jan. 2019 (CET) Beantworten

Beim Sichten eines Artikels bzw. der Rücksetzung der Änderung(en) aus dem Sichten heraus lässt das Editierfeld für die Zusammenfassung viel weniger Zeichen zu als bei "normalem Rücksetzen". Dieses Phänomen lässt sich mit folgendem Ablauf herbeiführen:

  • Man nehme einen beliebigen Artikel aus der Liste der zu sichtenden Artikel und klicke darauf (z.B. dieser Artikel)
  • Man klicke auf "x Änderungen" im Text "x Änderungen dieser Version sind noch nicht gesichtet. Die gesichtete Version wurde am TT. MONAT JJJJ markiert.", der oberhalb des Artikels angezeigt wird (Im Beispiel führt dies auf diesen Link)
  • Man klicke auf den Button "Änderungen verwerfen" im neuen Kasten über dem Artikeltext (im Beispiel sollte dies nach hier führen, aber nur im Kontext der vorangegangenen Schritte, aus dieser Diskussion heraus kommt leider eine Fehlermeldung)
  • Es erscheint eine Spezialseite mit der Überschrift "Versionen markieren" (Link im Beispiel, der aus dieser Diskussionseite wieder zu der Fehlermeldung führt)
  • Dort gibt es rechts neben dem Text "Zusammenfassung" ein Editierfeld, in dem bereits ein Textvorschlag eingesetzt ist.

Für diese Feld treten folgende Phänomene auf

  • Man kann häufig gar nichts mehr hinzufügen, insbes. wenn eine IP V6 zur Identifikation genutzt wird (der vorgegebene Text ist dann schon recht lang).
  • Wenn man den Text (dramatisch) kürzt, kann man wieder Zeichen hinzufügen.
  • Der vorgeschlagene Text ist u.U. deutlich länger als das was eingegeben werden kann: Man muss u.U. 30 und mehr Zeichen löschen, bevor man ein Zeichen hinzufügen kann.

Wenn man stattdessen die betreffende Version des Artikels nicht über den Sichten Prozess, sondern z.B. aus der Versionsgeschichte heraus "rückgängig macht" (im Beispiel führt der Link hierhin), führt das in das übliche Fenster "Quelltext editieren" mit einem vergleichbaren vorausgefüllten Feld "Zusammenfassung und Quellen". In diesem Feld kann man (bei gleichem Textvorschlag) noch sehr sehr viele Zeichen hinzufügen.

Ich interpretiere das (ohne den dahinterstehenden Code zu kennen) so, dass beim Sichten das Zusammenfassungs-Editierfeld eine Längenbegrenzung hat, die erheblich kleiner ist als für das vergleiche Feld auf der Seite "Quelltext editieren". Diese Längenbeschränkung scheint erst beim Editieren zu greifen, der vorgeschlagene Text kann durchaus schon länger sein als das, was man über Tastatur-Eingabe in dieses Feld hineinbringt.

Jetzt die Frage(n):

  • Ich habe kein Gefühl, wo man dieses Problem am besten meldet (deshalb erst mal in "Fragen zu Wikipedia".). Für jeden Hinweis dafür ein Dankeschön im Voraus, ich würde die Verschiebung des Themas übernehmen.
  • Ist dieses Problem bereits bekannt?
  • Gibt es einen anderen effizienteren "Workaround" als über die Artikelhistorie zu gehen (sehr mühsam, wenn mehrere zu sichtende Edits in einem Rutsch zurückgesetzt werden sollen)

Hinweis: Ich hatte dieses Thema schon mal aufgebracht, aber damals zurückgezogen, weil ich es für einen Bedienfehler meinerseits gehalten hatte.

Danke für jede Art von Hilfe --Bicycle Tourer (Diskussion) 10:01, 21. Jan. 2019 (CET) Beantworten

Die Längenbegrenzung ist maxlength="200", während es sonst 500 Zeichen sind. --FriedhelmW (Diskussion) 16:19, 21. Jan. 2019 (CET) Beantworten
Danke für die Information. Könnte man diese Längenbegrenzung heraufsetzen, um gleichartiges Verhalten zu bekommen, oder gibt es einen Grund, warum dieses unterschiedliche Verhalten gewünscht wird? Ich frage nach, weil eine Eintragung in diesem Feld auch für mich selber als Gedächtnisstütze dient, warum ich zurückgesetzt habe. Danke und VG --Bicycle Tourer (Diskussion) 20:39, 21. Jan. 2019 (CET) Beantworten
Ich verweise auf die Wikipedia:Technik/Werkstatt. Gruß --FriedhelmW (Diskussion) 21:34, 21. Jan. 2019 (CET) Beantworten
Danke für den Hinweis auf diese Stelle, werde das Thema nach dort verschieben. VG --Bicycle Tourer (Diskussion) 21:48, 21. Jan. 2019 (CET) Beantworten

Druckversion: obsolete Seitenelemente

Letzter Kommentar: vor 6 Jahren 6 Kommentare4 Personen sind an der Diskussion beteiligt
  1. Grundsätzlich ist es sinnvoll, daß diverse per Skript hinzugefügte Sonderinformationen mitgedruckt werden, aber bei 65 Versionen seit 2007年02月26日 (+168 Tage), 39 Autoren, 318 Seitenaufrufe (30 Tage), erstellt von: Skipper69 (112.099) · Alle Seitenstatistiken (ich weiß gerade nicht, welches Skript das erzeugt, aber ihr werdet das schon wissen ;-) ) ist es ziemlich nutzlos, daß Alle Seitenstatistiken mit ausgedruckt wird. Bitte ändern oder an der geeigneten Stelle Änderung herbeirufen.
  2. Genauso nutzlos ist, daß vor dem Lemma (H1-Überschrift) die verlinkten Worte Zur Navigation springen und Zur Suche springen mitgedruckt werden. Auf Papier kann man nirgends hinspringen, und selbst beim Klicken, wenn man es auf dem Bildschirm hat, sind die Links ohne sichtbare Reaktion. Kann das lokal ein Admin machen, oder braucht es dazu einen Bugreport?
  3. Ebenfalls nutzlos ist dann am Ende das verlinkte Wort "Entwickler". Kann man zwar in der Bildschirmansicht anklicken, aber das wird wohl keiner auf diesem Umweg tun. Hier gilt dasselbe wie eins drüber. (Den Link zur Cookie-Belehrung wird man da wohl aus rechtlichen Gründen behalten wollen, obwohl die Linkbeschriftung ausgedruckt auch nix bringt.)

Grüße --Matthiasb – (CallMyCenter) 13:25, 22. Jan. 2019 (CET) Beantworten

Das meiste liegt in unseren lokalen Händen und lässt sich konfigurieren. Ist ggf. völlig unser eigenes Zeugs.
Falls etwas nicht in der Macht unserer Admins stehen sollte, werde ich darüber nachdenken, welche globalen Ansätze es gäbe und inwieweit diese Unterdrückungsmechanik in der Druckausgabe eine globale Software-Eigenschaft wäre, und geeignete Anregungen weiterleiten.
Muss ich mir Detail für Detail ansehen, kann etwas dauern.
VG --PerfektesChaos 13:56, 22. Jan. 2019 (CET) Beantworten
Hmmh, da war ich etwas zu optimistisch.
Bei den meisten Punkten haben wir nur den Text der Linkbeschriftung in unserer Hand. Mit dem könnte man zwar per üblem Hack das Ziel erreichen, aber sowas mache ich nicht.
Vielmehr per phab:T214413 zur globalen Lösung weitergereicht; dann haben alle Wikis irgendwann etwas davon und es kann sauber gelöst werden.
Eine Verbesserung habe ich mir vorgemerkt, um sie im Paket mit anderen Sachen an A/A weiterzuleiten.
65 Versionen seit 2007年02月26日 (+168 Tage), 39 Autoren, 318 Seitenaufrufe (30 Tage), erstellt von: Skipper69 (112.099) · Alle Seitenstatistiken
  • Dieses Tool ist mir unbekannt.
  • In Benutzer:APPER/WikiHistory.js passiert sowas Ähnliches, aber der Screenshot auf Benutzer:APPER/WikiHistory sieht deutlich anders aus.
  • @Matthiasb: Musst du schon selbst wissen, welches Hilfsmittel du da benutzt. Ich habe sowas nicht aktiviert und kann auch keine charakteristischen Textfragmente finden.
  • @Mitleser: Weiß jemand, was das für ein Dings ist?
  • Da es nachträglich in die Seite injiziert wird, kann nur ein Maintainer von dem Teil verhindern dass es angezeigt würde. Nebenbei haben wir ziemlich viele nachträglich durch Skripte eingefügte Boxen, die über irgendwas informieren; müsste dann notfalls abgeschaltet werden, wenn man davon eine Druckversion generiert. Wobei es überhaupt seltsam ist, wie in ein PDF ein Skript-Output hineinkommen sollte.
@Matthiasb: Auf genau welche Weise generierst du überhaupt diese „Druckversion", und in was für einem Gebilde erscheint das dann? PDF oder HTML?
VG --PerfektesChaos 20:57, 22. Jan. 2019 (CET) Beantworten
  • Letzteres ist wohl die HTML-Version. Jedenfalls die, wenn man in der Seitenleiste auf Druckversion (rechts)klickt und beim Öffnen im neuen Tab oder Fenster sieht. In der PDF-Version werden diese zusätzlichen Angaben komplett weggelassen; das betrifft beispielsweise auch die Angabe des zugehörigen Wikidataeintrags.
  • es hat etwas gedauert, bis ich das gefunden habe. Es handelt sich um die in Wikipedia:Helferlein/Toolserver-Integration/Konfiguration genannte Option "Artikelinformationen am oberen Seitenrand einblenden" ts_xtools von Benutzer:Hedonil.
Danke für deine in der Sache biser unternommenen Bemühungen. --Matthiasb – (CallMyCenter) 23:22, 22. Jan. 2019 (CET) Beantworten
„Zur Navigation springen", „Zur Suche springen" und „Entwickler" werden nur in Monobook (und vielleicht noch anderen alten Skins) mitgedruckt, in Vector werden sie ausgeblendet. Das sind halt so die Probleme, die man hat, wenn man einen Uralt-Skin verwendet, für den sich niemand mehr richtig interessiert. –Schnark 08:56, 23. Jan. 2019 (CET) Beantworten
Ist die Druckversion wirklich skinabhängig? Eigentlich geht es ja genau darum, nichts zu „skinnen". Und zumindest die Infos zum Springen zu Navigation und Suche habe ich immer, auch als Vector-Nutzer. -- hgzh 10:07, 23. Jan. 2019 (CET) Beantworten

Bearbeitungsbildschirm lädt nicht zu ende - wenn angemeldet

Letzter Kommentar: vor 6 Jahren 3 Kommentare3 Personen sind an der Diskussion beteiligt

Als angemeldeter Benutzer bin ich bei der Wikipedia normalerweise bei der Wikipedia aktiv. Seit einigen Tagen hängt das Laden des Bearbeitungsbildschirms (egal ob Wikitext oder Oberflächenbearbeitung) immer öfter. Komme nun aber überhaupt nicht mehr in den Bearbeitungsmodus als angemeldeter Benutzer. Seitenunabhängig. Der Ladebalken bleibt immer an derselben Stelle stehen (ca. 1/3 vor dem Ende kommt er zum Stehen).--95.91.31.124 09:13, 26. Jan. 2019 (CET) Beantworten

Vielleicht hast du ja auch Spezial:Einstellungen#mw-prefsection-betafeatures angeknipst? Das war's bei mir, weshalb ich den guten, alten Quelltexteditor gar nicht mehr hatte. -- Karsten Meyer-Konstanz (D) 11:06, 26. Jan. 2019 (CET) Beantworten
Versuch mal, deine Browser-Addons abzuschalten, insbesondere NoScript und uBlock Origin. --FriedhelmW (Diskussion) 13:19, 26. Jan. 2019 (CET) Beantworten

Wikipedia-Artikel zu Martin Luther King

Letzter Kommentar: vor 6 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt

Hallo, ich bin nicht sicher, ob ich hier mit meiner Anfrage an der richtigen Stelle bin...

Ich habe den Eindruck, dass ein Zitat von M.L. King aus seiner Autobiographie nicht ganz korrekt aus dem Englischen in ́s Deutsche übersetzt wurde.

Das Original lautet: Clayborne Carson: The Autobiography of Martin Luther King, Jr. S. 9: "We cannot have an enlighted democracy with one great group living in ignorance. We cannot have a healthy nation with one-tenth of the people ill-nourished, sick, harboring germs of disease which recognize no color lines – obey no Jim Crow laws [...]"

Die Übersetzung lautet: „Wir können keine aufgeklärte Demokratie sein, wenn eine große Bevölkerungsgruppe ignoriert wird. Wir können keine starke Nation sein, wenn ein Zehntel der Bevölkerung schlecht ernährt und krank durch Bakterien ist, die keinen Unterschied zwischen Schwarzen und Weißen machen – befolgt die Jim-Crow-Gesetze nicht [...]"[3]

(beide Texte aus dem selben Wikipedia-Artikel)

Meine Frage betrifft den letzten Satzteil nach dem Gedankenstrich. Ich vermute, King wollte sagen: "die Bakterien kennen keinen Unterschied zwischen Schwarzen und Weißen - und (deshalb) befolgen sie auch die Jim-Crow-Gesetze nicht..."

Im Wiki-Artikel kommt es aber wie ein Aufruf/Appell an die Leser bzw. Zuhörer rüber: "die Bakterien kennen keinen Unterschied zwischen Schwarzen und Weißen - und (deshalb, werte Zuhörer,) befolgt auch (Ihr) die Jim-Crow-Gesetze nicht! ..."

Ich habe mir aber ehrlich gesagt jetzt nicht die Mühe gemacht, den ganzen Satz in Zusammenhang des Biographie-Textes anzusehen. Es kann also auch sein, dass ich mich irre. Trotdem kommt mir diese Überestzung im Wiki-Artikel ziemlich seltsam vor.

Mit freundlichen Grüßen, Gerhard Peter (nicht signierter Beitrag von 2001:16b8:57a3:8400:8968:a4a4:d680:e730 (Diskussion) 26. Jan. 2019, 16:08:04‎)

Nein, das gehört nicht hier her, es gehört auf die Artikel-Diskussionsseite. Ich werde es mal dorthin kopieren. Grüße vom Sänger ♫ (Reden) 16:14, 26. Jan. 2019 (CET) Beantworten

Alle meine Scores mit Lilipond und Vorbis-Midi

Letzter Kommentar: vor 5 Jahren 2 Kommentare2 Personen sind an der Diskussion beteiligt

Wenn man Scores mit der Vorbis-Funktion in Wiki hörbar machen will, schiebt sich (zumindest in meiner Ansicht) der doofe Midi-Player in die Textzeile. Das sieht nicht gut aus. Gibt es dafür Abhilfe? Wer kennt sich aus? Mit wurde in der Auskunft diese Seite empfohlen. --Krächz (Diskussion) 23:15, 26. Jan. 2019 (CET) Beantworten

Schau mal:phab:T216305 -- Leif Czerny 14:05, 22. Feb. 2019 (CET) Beantworten

Portal-Gestaltung

Letzter Kommentar: vor 5 Jahren 10 Kommentare2 Personen sind an der Diskussion beteiligt

Hallo liebe Technikwerkstatt, vor kurzem haben wir angefangen, die Portalsseiten der Portal:Philosophie zu entschlacken und zahlreichen dort direkt implementierten code per .css zu vereinheitlichen und zentral zu verwalten. Unsere Seite hat einen schicken Rahmen per .philosphie-portal-rahmen definiert, der auf den Seiten des Portals als div angerufen wird. Das führt auf der Diskussions- und auf der QS-Seite zu dem Problem, das schließende div tags mit dem letzten Disk-Abschnitt archiviert werden. Darf man das Problem lösen, indem die spezifische css [[:Vorlage:Philosophie/Portal.css]] jetzt Portal:Philosophie/styles.css die Stileigenschaften (Rahmen, Hintergrundfarbe, padding, font-family) dem #mw-content-text zuweist? Oder klappt das gar nicht? Oder wäre es einfach nur im hohen Grade unerwünscht und wenig hilfreich?-- Leif Czerny 11:28, 30. Jan. 2019 (CET) Beantworten

Also, erstmal sind Rahmen um ganze Seiten, sogar Rahmen um ganze Abschnitte, die keine Infobox oder Navileiste oder Warnhinweis wären, strikt verpönt.
  • Solche rein dekorativen Rahmen, die keine bedeutungstragende, gliedernde und bedeutungsunterscheidende Funktion haben, nehmen auf Mobilgeräten (Smartphones) sehr viel Platz weg, sind bereits bei schmalen Desktop-Fenstern nervig.
Grundsätzlich technisch möglich, wenn auch nicht wünschenswert und nicht mit Sicherheit auf ewig unterstützt, wären TemplateStyles für bestimmte namentlich aufgezählte Seiten.
  • Die saubere Klassifizierung per class= müsste bereits vor dem Seiteninhalt erfolgen. Das ist dem Wikitext grundsätzlich nicht möglich. Andernfalls geht das nur über ein öffnendes <div>, und um dieses auf derselben Seite wieder zu schließen, muss es ein schließendes </div> nach dem letzten Diskussionsabschnitt geben. Weil aber der aktuellste Diskussionsabschnitt immer dahinter eröffnet würde, kann das nicht funktionieren.
Theoretisch technisch möglich, jedoch unter Beeinträchtigung aller anderen Lesezugriffe, wäre eine projektweit mögliche Spezifikation für bestimmte namentlich aufgezählte Seiten. Das wirkt jedoch auf jeden Seitenabruf, hat aber nur eine Trefferquote von eins zu zehn Millionen Wikitext-Seiten plus weitere zehn Millionen Spezial- und Abfrage-Seiten, und bremst alle nicht gemeinten aus und würde deshalb nicht akzeptiert werden, und für eine ohnehin unerwünschte Dekoration gleich gar nicht.
Die einzige technisch akzeptable Lösung war von Lómelinde bereits erwähnt worden: Die Präsentation des Seiteninhalts müsste auf einer anderen Seite erfolgen, die den Nutzinhalt der Diskussion einbindet. Allerdings wäre das für alle Diskutierer sehr irritierend, weil dieses Konstrukt vermutlich keinen Präzedenzfall hätte und man für einen Diskussionsbeitrag eine andere Seite bearbeiten müsste als diejenige, die man zum Begucken mit Rahmendekoration präsentiert bekäme.
[[Vorlage:Philosophie/Portal.css]] steht nebenbei im falschen Namensraum und ist auch nicht fachgerecht benannt noch dokumentiert.
  • Portal:Rudern/styles hat das praktisch gleiche Ziel, ist jedoch vorbildlich hinsichtlich Namensraum, Seitenname, Benennung der Klassen, Beispielen, Dokumentation, Unterstützung langfristiger Pflege und Wartung sowie projektweiter Registrierung.
VG --PerfektesChaos 13:00, 30. Jan. 2019 (CET) Beantworten
Hallo PC, die Rahmen haben wir seit über 10 Jahren, allerdings als Tabellen. Wenn ich die jetzt abschaffen wollte, muss ich das erst mit den anderen Portalsgranden ausdiskutieren. Allerdings haben wir un unser Portal-css schon ein @media, den Rahme also mobil abzuschalten wäre möglich und sicher etwas, auf das wir uns gerne einlassen. Diskussionsseiten, die auf Unterseiten Stattfinden, hatten wir bereits auch in unserem alten QS-Portal, das wir jedoch angesichts moderner Wartungslisten abgeklemmt hat, hier: Portal:Philosophie/Qualitätssicherung. Die Lösung fand ich allerdings auch unbefriedigend. Ich habe aber nciht ganz verstanden, ob #mw-content-text in der lokalen css-Vorlage zusätzliche Auszeichnungen tragen darf oder nicht. War das mit "theoretisch technisch möglich, jedoch unter Beeinträchtigung aller anderen Lesezugriffe, wäre eine projektweit mögliche Spezifikation für bestimmte namentlich aufgezählte Seiten." gemeint? Wenn nein: Das hat ja auch keiner vorgeschlagen. Ich kann aber gerne mal die Kollegen vom Protal Ruder fragen, ob sie halfen. Dich, lieber PC, möchte ich darauf hinweisen, das hier lokale Freiwilligenarbgeit von einzelnen erfolgt, es aber wenige möglichkeiten gibt, sich wirksam und verbindlich zu informieren - außer dich und Lomelinde zu Fragen. Dass Doku-Standards und Namenskonventionen nicht eingehalten werden und nachgebessert werden müssen, ist daher wohl kaum überraschend. Vielen Dank jedenfalls für die prompte Antwort.--- Leif Czerny 14:02, 30. Jan. 2019 (CET) Beantworten
Die pauschalen Seiten- und Abschnitts-Rahmen treffen auch schmale Desktop-Bildschirme, und konsumieren deren Nutzfläche, ohne jedoch bedeutungsunterscheidende Differenzierung und damit inhaltlichen Nutzen zu liefern.
  • Eine @media-Klausel ist nur mittels TemplateStyles oder aber mittels einer zig Millionen URL betreffenden projektweiten Definition möglich. Die zurzeit einzig vorhandene Regel betrifft allerdings keine Rahmendekoration, sondern ausschließlich das Layout, und sie hat auch nichts direkt mit Mobilgeräten zu tun, allerdings implizit über die Breite eines Bildschirms.
Ihr habt keine Möglichkeit, mittels TemplateStyles sauber an #mw-content-text heranzukommen; das wäre lediglich mit einer auf die zig Millionen unterschiedlichen Seiten anzuwendenden projektweiten Regel möglich, die ob der miserablen Trefferquote aber für alle anderen Seiten unzumutbar wäre.
  • Jeder andere Selektor käme erstens zu spät, oder würde andererseits auch noch ein umschließendes <div> benötigen. Damit wären wir wieder beim Ausgangspunkt.
  • Es liegt an momentaner Wiki-Programmierung und am momentanen Verhalten der Browser, ob und wie sie eine zu späte Regel berücksichtigen würden. Deshalb kann eine TemplateStyles-Lösung nicht robust sein, weil sie erst nach Beginn des Seiteninhalts definiert wäre, sich jedoch bereits vor dem Seiteninhaltsbereich auswirken soll. Dieser Eingriff in die Wiki-Skin ist nur projektweit für alle Seiten möglich. Für TemplateStyles ist es global explizit unerwünscht, funktioniert momentan aber durch Nebeneffekt trotzdem.
Generell sind in der Kindergartenzeit der Wikipedien und vor Beginn der Mobil-Ära verschiedenste Sünden begangen worden, die für eine überschaubare Anzahl an Seiten und Artikeln und Programmierungen und lediglich für große Desktop-PC als Gehversuche durchgingen. Mit über zwei Millionen Artikeln, mehr als 50.000 Vorlagen, immer komplexerer und anspruchsvollerer Programmierung und von dieser erwarteter Funktionalität sowie der Anpassung an beliebige Endgeräte, Barrierefreiheit, Semantik, korrekte Syntax muss allerlei aufgegeben werden, was man früher mal so hinfrickeln konnte, dass es anscheinend irgendwie funktioniert. Es funktioniert nicht mehr in jeder Situation und ist längerfristig auch nicht zu pflegen und funktionstüchtig zu halten.
  • „Layout-Tabellen", das Stilmittel aus dem letzten Jahrhundert zur optischen Gliederung auf einem Bildschirm, ist bereits seit zwei Jahrzehnten wegen Verstößen gegen Barrierefreiheit und Skalierbarkeit auf beliebige Präsentationen strikt verpönt. Vielmehr ist seit 1998 ein float-Design anzuraten, wie es auch in der momentanen [[Vorlage:Philosophie/Portal.css]] eingesetzt wird. Rahmen um ganze Seiten gelten gleichwohl seit langer Zeit nicht als gutes Webdesign, weil sie nur Platz kosten aber den Betrachtern nichts bringen; ggf. käme ein unterschiedlicher Seitenhintergrund zur deutlichen Kennzeichnung unterschiedlicher Inhaltstypen in Frage.
VG --PerfektesChaos 15:03, 30. Jan. 2019 (CET) Beantworten
Hallo PC, die aktuelle Regel betrifft die float-Elemente. damit diese in schmalen Viewports untereinander angeordnet werden. Das war der ursprüngliche Grund des Wechsels weg von den zehn Jahr alten Tabellen. die Erläuterungen zu #mw-content-text kann ich in dieser Form besser verstehen. Ich hatte debenben eben erst einmal um die Umsetzung des alten Designs in das css gebeten, auch wenn der Rahmen wertvolle pixel verschwendet, damit die Akzeptanz erhalten bleibt. Ob das "dem Betrachter" als solchem etwas bringt oder nicht, mag ich da nicht entscheiden ;-). Falls es irgendwo generelle Tips zur responsiven Gestaltung von Portalsseiten gibt, nur her damit!-- Leif Czerny 15:09, 30. Jan. 2019 (CET) Beantworten
WMF-intern kann ich mw:Recommendations for mobile friendly articles on Wikimedia wikis als Ausgangsbasis mit einer Reihe nützlicher Tipps anempfehlen, jedoch weit von einem Tutorial oder Anspruch auf Vollständigkeit im Webdesign entfernt. Was mobile friendly ist, ist immer auch gut für Desktop und schmale Browser-Fenster, und die resultierende Gliederung verbessert im Nebeneffekt sogar die Barrierefreiheit.
Ansonsten gibt es tausenderlei Webdesign-Seiten und Blogs, in die ich seit einem Vierteljahrhundert gelegentlich reinschmökere. Wie bei Ratschlägen zur Typografie gibt es auch da sehr individuelle Geschmacklichkeiten und unbrauchbare Schrullen, jedoch bei mitgelieferten Begründungen und Erörterung von Für und Wider verwertbare Ratschläge.
Eine Regel mal en passant mitgeliefert: Die unterschiedlichen Präsentationen sollten sich dann unterscheiden, wenn es beim Adressaten harte Notwendigkeiten gibt, in unserem konkreten Fall unterschiedliche Bildschirmgrößen und deshalb eine andere Anordnung von Elementen über- oder nebeneinander. Ansonsten sollten sich jedoch alle Darstellungen weitestmöglich ähneln, damit nicht ein und derselbe Inhalt auf einem Smartphone völlig anders dargestellt wird als auf dem PC, und sich Bedienung und Strukturen völlig verwirrend unterscheiden. Beim Wiki-Portal gibt es auf dem Desktop in den klassischen Skins einen Rahmen auf drei Seiten, bei Timeless platzsparender im Prinzip nur einen solchen Block im Kopf und bei der echten Mobil-Oberfläche sind alle Elemente Smartphone-gerecht in einer völlig eigenständigen Navigationsstruktur verbaut.
VG --PerfektesChaos 21:29, 30. Jan. 2019 (CET) Beantworten
Ok, wir haben erstmal mit der Verschiebung angefangen. Wie gesagt, eine richtige Herzensangelegenheit ist der Rahmen für mich nicht, aber ich versuche, bei der Übersetzung eher konservativ zu sein. Wenn es sonst keine spezifischeren Tipps gibt, kümmere ich mich jetzt erstmal um die Doku und schalte die Rahmen auf den Diskseiten bei Gelegenheit ab.-- Leif Czerny 12:01, 31. Jan. 2019 (CET) Beantworten
So, eine rudinentäre doku ist auch da. es fehlen noch die Anwendungsbeispiele. Ich hatte noch eine Idee wegen der schließenden div-tags - wenn Vorlage:Neuer Abschnitt eingesetzt wird, könnte man ja eine Unterseite in den preloder setzen, die ein bedingtes includeoly einsetzt, dass einen letzten Disk-Abschnitt mit den schließenden Disktags einsetzt, unter der Bedingung, dass es sich um den letzten Abschnitt handelt. ist eine solche Bedingug mit Expressions formulierbar? -- Leif Czerny 19:15, 8. Feb. 2019 (CET) Beantworten
Ich vermute, ich habe die Idee verstanden, aber auch das kann nicht funktionieren.
Beim preload würde eine Art Vorlageneinbindung generiert, die unterhalb der künftigen Abschnittsüberschrift säße und auf wundersame Weise manchmal ein </div> produziere und manchmal nicht.
  • Dann schreibt der erste und jeder folgende Diskutant dadrunter.
  • Was bedeutet, dass die Überschrift innerhalb des Rahmens läge, alle nachfolgenden Diskussionsbeiträge jedoch unterhalb des Rahmens.
  • Das ist niemandem zu verklickern, wie er auf dieser seltsamen Seite Diskussionsbeiträge anhängen solle.
Es gibt einen innerhalb einer Wikitext-Diskussionsseite nicht auflösbaren Widerspruch:
  1. Das </div> muss das letzte sichtbar generierte Element der Seite sein.
  2. Diskussionsteilnehmer schreiben ihren Beitrag als letzten in den Abschnitt.
    • Und der jüngste Diskussionsabschnitt ist der letzte auf der Seite und kann immer nur an die gesamte existierende Seite angehängt werden; danach kommt keiner mehr.
Der einzige Weg wurde bereits einmal angedeutet:
  • Es muss auf einer anderen Seite der Diskussionsbeitrag ohne Rahmen von den Diskutanten bearbeitet werden, als hinterher die montierte Gesamtseite erscheint.
  • Sowas gab es vor Jahren mal beim Kurier als zwei unabhängige Unterseiten für Linke Spalte und Rechte Spalte, was auch von der Größe der bearbeitenden Seite her sinnvoll gewesen war, aber irgendwer dann wieder abschaffte, weil zu kompliziert.
Nebenbei gingen auch sonst deine Vorstellungen an das äußerste Maximum der Programmierkunst:
  • Nach jeder Abschnittsüberschrift verbleibt ja die Vorlageneinbindung in der Seite, also viele gleichzeitig, und jede würde eigentlich ein </div> produzieren.
  • Also bräuchten diese Selbsterkenntnis darüber, welche von diesen gleichberechtigten die letzte wäre, und alle anderen müssten stumm sein und nur die letzte dürfte das Tag generieren.
  • Weshalb beim Preload eine Zufallszahl generiert und substituiert werden müsste, wodurch als Parameter sich Einbindungen voneinander unterscheiden.
  • Und dann müsste sich jede Einbindung die Diskussionsseite selbst einlesen (was ginge) und analysieren, welche Zufallszahl die zuletzt auf der Seite vorkommende wäre und ob das mit ihrem Parameterwert übereinstimme.
Es lässt sich nicht verhindern, dass neue Diskussionsabschnitte angehängt werden, ohne den Dienstweg mit preload auzuführen.
Die Fragestellung ist seit einem Jahrzehnt bekannt und nicht lösbar.
  • Hinzu kommt, dass ein Rahmen um alles nichts gliedert, nichts strukturiert, nichts hervorhebt, zweckfrei und pur dekorativ ist. Stehrümchen. Außer auf kleinen Fenstern Platz wegzunehmen.
VG --PerfektesChaos 11:28, 9. Feb. 2019 (CET) Beantworten
Trotzdem schade, das es nicht geht.-- Leif Czerny 13:54, 22. Feb. 2019 (CET) Beantworten

Kat-Namen-Übergabe an PetScan

Letzter Kommentar: vor 5 Jahren 3 Kommentare2 Personen sind an der Diskussion beteiligt

Wenn ich aus einer Kat-Seite (bspw. Kategorie:Benutzer:aus Dänemark) aus der Zeile

Ungesichtete Seiten | Seiten mit unmarkierten Änderungen | Deep sight | PetScan | Cirrus

PetScan aufrufe, wird dorthin der Kat-Name encodiert als

Benutzer%3Aaus D%C3%A4nemark

übergeben. PetScan "versteht" dies aber nicht und findet folglich 0 Ergebnisse. Liegt das Problem hier oder muss da der Tool-Maintainer ran?--Mabschaaf 09:56, 2. Feb. 2019 (CET) Beantworten

Du müsstest mal ein wenig an den URL rumspielen, und gucken, was das PetScan-Formular selbst als URL generiert.
  1. Wenn sich eine funktionierende URL ermitteln ließe, wäre unser Encoding-Algorithmus ggf. anders zu programmieren.
    • D%C3%A4nemark ist normales Zeichen-Encoding im Textbereich.
    • Benutzer%3A ist tückisch. Der Doppelpunkt ist wie der Schrägstrich ein syntaktisches Zeichen, und wird ggf. anders erwartet (unkodiert) als normale Textzeichen.
    • Leerzeichen als %20 oder _ müssten unproblematisch sein, wären sonst schon vor Jahren aufgefallen. Im Wiki-Kontext ist + als Leerzeichen tückisch. Oben steht ein unkodiertes Leerzeichen, aber da machen die meisten Browser %20 draus.
  2. Wenn sich keine funktionierende URL konstruieren lässt, müsste das Tool irgendwas abfangen.
    • Namensraum:Namensraum: könnte für Verwirrung sorgen.
    • Ich erinnere mich aber, in den Kategorie:Vorlage: erfolgreich gePetScant zu haben.
LG --PerfektesChaos 11:26, 2. Feb. 2019 (CET) Beantworten
Ich habe keine Ahnung, wo ich da was rumspielen und ausprobieren sollte - deshalb bin ich hier aufgeschlagen und hoffe weiterhin auf eine Lösung des Problems.--Mabschaaf 10:18, 24. Mär. 2019 (CET) Beantworten

Problem mit TemplateData

Letzter Kommentar: vor 5 Jahren 10 Kommentare7 Personen sind an der Diskussion beteiligt

Hier ein Übertrag von Wikipedia:Fragen zur Wikipedia:

== Vorlage:Internetquelle ==

Wenn ich heute diese Vorlage im Visual-Editor nutzen will, wird (egal auf welcher Seite) bei automatischer Einfügung kein Einzelnachweis aufgebaut. Bei manueller Einfügung des Nachweises über die Vorlage werden keine leeren Felder angeboten. Wenn ich den Inhalt der Vorlage im Quelltexteditor einfüge, funktioniert alles.--Nordprinz (Diskussion) 11:33, 13. Feb. 2019 (CET) Beantworten

Ist bei mir genau so. Es scheinen keine Felder vorhanden zu sein, die der VE mir anzeigen kann. Ich kann Felder manuell hinzufügen. An 2 Rechnern mit unterschiedlichen Netzwerken probiert. Es steht weiterhin: Die Vorlage „Vorlage:Internetquelle" hat noch keine Beschreibung, aber vielleicht gibt es einige Informationen auf der Vorlagenseite." Pause ist vorbei, arbeit geht weiter, kann da @PerfektesChaos: vielleicht mal gucken? Bei Antwort bitte anpingen Danke und Gruß vom --Keks um 13:01, 13. Feb. 2019 (CET) Beantworten
Ja, wollte ich auch eben beklagen. Die TemplateData-Definitionen für die Vorlage werden jedenfalls nicht mehr angezeigt. — Pajz (Kontakt) 14:34, 13. Feb. 2019 (CET) Beantworten
Bei mir das Gleiche!--Nadi2018 (Diskussion) 17:26, 13. Feb. 2019 (CET) Beantworten

Es scheint zurzeit mehrfach sog. "Steuerzeichenfehler" bei TemplateData zu geben. Siehe auch dieses Beispiel des Fehlers. Da der Fehler erst nach einem Purge angezeigt wurde, muss er an einem kürzlichen Update liegen. --FF-11 (Diskussion | Bewertung | Beiträge) 17:44, 13. Feb. 2019 (CET) Beantworten

Schaue ich mir im Lauf des Abends an; danke für den Hinweis. VG --PerfektesChaos 18:00, 13. Feb. 2019 (CET) Beantworten
--FF-11 (Diskussion | Bewertung | Beiträge) 18:12, 13. Feb. 2019 (CET) Beantworten

@FF-11:

  • Ich konnte nach Dokument-Analyse der Vorlagen-Präsentation bestätigen, dass der TemplateData-Abschnitt leer war; bzw. nur eine leere Hülle von TemplateData enthielt.
  • Es gab von unserer Seite keinerlei Veränderungen an Doku oder beteiligten Programmierungen innerhalb mehrerer Wochen; spätestens nach ein oder zwei Tagen wäre sowas wirksam geworden.
  • Debugging der beteiligten Programmierung zeigte ordnungsgemäßes Verhalten.
  • Ich habe dem Ding daraufhin kurzerhand einen tiefgreifenden Cache-Neuaufbau verpasst.
  • Daraufhin war die leere Hülle wieder erwartungsgemäß gefüllt worden.
  • Müsste jetzt ordnungsgemäß funktionieren, bitte ausprobieren.
  • Die Fehlerbeschreibung hier war für mich informativer weil mit präziseren Details über die Situation angereichert als die allerersten Meldungen.
  • Wenn sich das damit gelöst haben sollte, dann bitte auch die diversen anderen Diskussionsorte informieren.
  • Es wird sich um sogenannten Hamster-Schnupfen gehandelt haben; irgendwelche Brösel auf den Servern waren nicht synchron, und vielleicht sind die innerhalb der Server-Farm zwischen Maschinen umgezogen oder sowas.

VG --PerfektesChaos 19:49, 13. Feb. 2019 (CET) Beantworten

Funktioniert bei mir wieder. Danke --Wikipeter-HH (Diskussion) 10:41, 14. Feb. 2019 (CET) Beantworten
@PerfektesChaos: Es tritt wieder auf: Vorlage:Infobox Fernsehsendung --FF-11 (Diskussion | Bewertung | Beiträge) 18:13, 19. Feb. 2019 (CET) Beantworten

Frage zu Parameternamen in Vorlagen

Letzter Kommentar: vor 5 Jahren 8 Kommentare2 Personen sind an der Diskussion beteiligt

Kann mir jemand einen Hinweis geben, was alles so als Zeichen in Parameternamen erlaubt ist? Wie ich gesehen habe, ist ja vieles möglich. Vorlage:Infobox Pflanzenöl hat einen Parameter Vitamin E<sub>2</sub>, Vorlage:Infobox Gemeinde in Frankreich verwendet einen Parameter km2 und in Brake (Unterweser)#Stadtrat wird die Vorlage:Sitzverteilung mit Parametern wie [[Einzelbewerber|ISING]] verwendet, allerdings ist das schon etwas spezieller. Ein Gleichheitszeichen (=), eine Pipe (|) gehen wohl nicht. Ebenso scheint ein Zeilenumbruch im Namen nicht erlaubt zu sein. Gefunden hab ich noch ein obskures Beispiel: Ein leerer Name https://meta.wikimedia.org/wiki/Template_talk:T_empty_string_as_parameter_name aber eine nette Beschreibung was nun erlaubt ist und was nicht, hab ich nirgendwo gefunden. --Wurgl (Diskussion) 20:24, 18. Feb. 2019 (CET) Beantworten

Technisch erstmal alles, was keine Wiki-syntaktische Bedeutung hätte: Gleichheitszeichen, Pipe, zwei schließende geschweifte Klammern.
Führender oder schließender Whitespace zählen nicht, außerdem keine bidi.
Buchstaben, Ziffern (auch nicht-ASCII) sind unproblematisch, auch Interpunktion.
Mehrfacher Whitespace ist nicht definiert, und Unterscheidung zwischen ASCII-Leerzeichen und anderem Whitespace auch nicht.
Leere Zeichenkette als Parametername ist eine kuriose Entartung, aber zurzeit möglich.
Nicht erlaubt sind: HTML-Kommentar, Vorlageneinbindung, Tags, unklar ist die Wirkung von Entities.
Zusammengefasst: Eigentlich alles als Name taugliches, was keine anderweitige Syntax enthält.
LG --PerfektesChaos 20:54, 18. Feb. 2019 (CET) Beantworten
Hintergrund des ganzen: APPERs Datenbank zu Vorlagen wo die Parameter aufgedröset sind. Und ich hab beim Zerlegen der Pärchen VorlagenParameter = Parameterwert noch nicht so richtig geblickt wann das Gleichheitszeichen einen benamsten Parameter draus macht und wann trotz Gleichheitszeichen der Parameter unbenannt bleibt und damit einfach durchnummeriert wird. Da hätte ich gerne was zum Lesen. --Wurgl (Diskussion) 21:03, 18. Feb. 2019 (CET) Beantworten
Zuerst werden Vorlagen-Einbindungen und Verlinkungen sowie HTML-Kommentare konsumiert; die darin enthaltenen Pipes sind damit unsichtbar.
Danach wird anhand der jetzt noch freien Pipes bis zu doppelten schließenden geschweiften Klammern in Segmente unterteilt.
In jedem Segment ist alles links vom ersten Gleichheitszeichen der Parametername.
Ließe sogar den leeren Namen zu, was sich in der Programmierung aber nicht nutzen ließe.
Namen und die Werte benannter Zuweisungen werden getrimmt.
Wo kein Name, so kein Gleichheitszeichen, also unbenannt.
LG --PerfektesChaos 21:15, 18. Feb. 2019 (CET) Beantworten
Diese doch recht freie Auslegung führt zu "Fehlern" wie hier. Hat die Software doch tatsächlich einem Parameter den Namen "(8,95 + 10,53)/2" gegeben.
Zu deiner Aufzählung noch: Alles zwischen "<ref" und "</ref>" wird auch ignoriert. --Wurgl (Diskussion) 11:34, 19. Feb. 2019 (CET) Beantworten

LG --PerfektesChaos 12:38, 19. Feb. 2019 (CET) Beantworten

Schon okay. Wenn die tools-Datenbank wieder läuft (Rest geht, nur persondata noch nicht), dann werd ich mal gucken, ob ich so fehlerhafte Parameter per Programm identifizieren kann. Welche Parameter in der Vorlage selbst verwendet werden, ist ja einfach zu finden: Suchmuster in der Vorlage ist wohl sowas wie "{{{Parametername|" bzw. "{{{Parametername}}}". Gibt ein paar Sonderfälle wie eben Vorlage:Sitzverteilung, aber das ist hinzubekommen. --Wurgl (Diskussion) 13:24, 19. Feb. 2019 (CET) Beantworten
PerfektesChaos, ich hab mal was gebastelt: Benutzer:Wurgl/Fehler_Vorlagen Kritik ist willkommen. Wenn okay, dann schreib ich kurz was bei FzW. --Wurgl (Diskussion) 18:26, 9. Mär. 2019 (CET) Beantworten

Maximale Anzahl von Vorlagen?

Letzter Kommentar: vor 5 Jahren 3 Kommentare2 Personen sind an der Diskussion beteiligt

In Stuttgarter_Kickers/Namen_und_Zahlen sind insgesamt 7890 Vorlagen verwendet, davon 7441 mal die Vorlage:0. Bisschen extrem, oder? Was ist die Grenze? --Wurgl (Diskussion) 20:27, 24. Feb. 2019 (CET) Beantworten

Öffne den HTML-Quelltext der Seite (meist Strg+U) und suche nach NewPP limit report. --FriedhelmW (Diskussion) 20:53, 24. Feb. 2019 (CET) Beantworten
Das war mal. Jetzt steht am Ende der Seite was anderes. Source per Browser angucken ist übrigens gruselig langsam. Per wget saugen und dann im Editor angucken ist bei so großen Seiten um Hochhäuser schneller. --Wurgl (Diskussion) 21:02, 24. Feb. 2019 (CET) Beantworten

Prüfung auf doppelte Stimmen

Letzter Kommentar: vor 5 Jahren 1 Kommentar1 Person ist an der Diskussion beteiligt

Hallo, bis vor kurzem konnte ich bei Kandidaturen:

[12]

nutzen. Es funktionierte bei Admin, CU, OS und B-Kandidaturen.

Seit einigen Tagen kommt nichts mehr. Das Tool hat eine Übersicht über die Stimmabgaben ausgegeben, inkl. rotem Hinweis, wenn es doppelte Stimmen gab und im Kopf noch freundlicherweise eine Zusammenfassung inkl. prozentualer Auswertung. Könnt ihr das zurück ans laufen bringen, oder etwas ähnliches zaubern? Vielen Dank --Itti 08:32, 27. Feb. 2019 (CET) Beantworten

Tabellenende in div in Chrome unsichtbar

Letzter Kommentar: vor 5 Jahren 9 Kommentare2 Personen sind an der Diskussion beteiligt

Hallo! Mir ist gerade aufgefallen, dass das Ende sehr breiter Tabellen, die mittels div style="overflow... mit Scrollbalken versehen werden, in Chromium-Browsern offenbar nicht sichtbar ist. Also zB in URL-Encoding#Relevante ASCII-Zeichen in Prozentdarstellung – wenn ich ganz nach rechts scrolle, ist die Tabelle nicht abgeschlossen (fehlt wohl der Bruchteil eines Millimeters). Ist das ein MediaWiki-Fehler oder macht Chrome das allgemein falsch? In Firefox ist alles okay, soweit ich das sehe. Gruß--XanonymusX (Diskussion) 16:09, 5. Mär. 2019 (CET) Beantworten
Nachtrag: Außerhalb der Wikipedia konnte ich das Problem nicht nachvollziehen. Dürfte wohl was mit Abständen vom rechten Bildrand zu tun haben. Interessant auch, dass die Tabellen in der Vorschau des 2017-Quelltext-Modus sehr wohl abgeschlossen sind, nicht aber im Bearbeitungsmodus des VE. Gruß–XanonymusX (Diskussion) 16:19, 5. Mär. 2019 (CET) Beantworten

In Chrome Version 72.0.3626.121 (Offizieller Build) (64-Bit, W10) ist die Tabelle ok. Gruß --FriedhelmW (Diskussion) 17:03, 5. Mär. 2019 (CET) Beantworten
Ist bei mir gleiche Version und gleiches Betriebssytem, ja (gleiches Verhalten aber auch beim von mir präferierten Fork Iron). Könnte dann noch mit der Bildschirmauflösung zusammenhängen ... Gruß–XanonymusX (Diskussion) 17:10, 5. Mär. 2019 (CET) Beantworten
Wenn ich das Fenster verkleinere sehe ich den Fehler auch. --FriedhelmW (Diskussion) 17:17, 5. Mär. 2019 (CET) Beantworten
(BK)Hm, interessant: Bei gleichbleibender Auflösung (×ばつ1080, wie empfohlen), aber veränderter Skalierung (125% vs. 150%) lässt sich das Problem beheben. Nur sehe ich bei 125% auf diesem Bildschirm fast nichts, ist viel zu klein. Warum jetzt aber eine 150%-Skalierung in Wikipedia und nur über Chrome das Tabellenende schluckt, bleibt ein Rätsel.–XanonymusX (Diskussion) 17:18, 5. Mär. 2019 (CET) Beantworten
Und wenn ich im Browser auf 125% rauf- oder auf 90% runtergehe, sehe ich das Tabellenende wieder. Hm, scheint dann doch eher eine Unzulänglichkeit von Chromium zu sein, oder? Gruß–XanonymusX (Diskussion) 17:23, 5. Mär. 2019 (CET) Beantworten
Da kann man leider nichts machen, außer: Die Tabelle so aufteilen, dass sie ohne Scrollen auf die Seite passt. --FriedhelmW (Diskussion) 17:36, 5. Mär. 2019 (CET) Beantworten
Nur wegen Chrome zahlt sich das nicht aus; vielleicht bekommt der Browser die Darstellung ja mal besser hin. Gruß–XanonymusX (Diskussion) 20:30, 5. Mär. 2019 (CET).Beantworten

Linkwerkzeug funktioniert nicht mehr

Letzter Kommentar: vor 5 Jahren 3 Kommentare3 Personen sind an der Diskussion beteiligt

Hallo Wikitech-Profis, seit ein paar Tagen funktioniert das Linkicon aus der Werkzeugleiste (die mit den 8 Icons) nicht mehr. Ich kann zwar anklicken und auswählen, aber "Link einfügen" funktioniert nicht mehr in Firefox 48.0.2 (Mac). Im Iridium 48 klappt es, den möchte ich aber wenn ́s geht, nicht für Wiki nutzen. Machbar? --Fährtenleser (Diskussion) 15:29, 11. Mär. 2019 (CET) Beantworten

Ich kann zwar nichts dazu beitragen, jedoch Missverständnisse vermeiden.
Meinst du das, was bei Hilfe:Symbolleisten #Klassische Bearbeitungswerkzeugleiste mehr so Richtung zehn und mehr hat und bunt ist, oder eins drunter in grau-grau?
Die FF-Version anzugeben ist klug und weise; 48 kommt mir bauchmäßig ururalt vor und Mac dürfte auch nicht anders sein. Kann sein, dass die Wiki-Zentrale den Support für diesen FF-Jahrgang eingestellt hätte und die Krücken dafür zurückbaut. Guck doch mal, aus welchem Jahr der FF ist.
LG --PerfektesChaos 17:31, 11. Mär. 2019 (CET) Beantworten
Schonmal danke für die schnelle Antwort! Ich meine die grau-grauen. Der FF 48 ist zugegebenermaßen nicht mehr der Jüngste (aber der Neueste, der auf meinem OS 10.6 noch läuft). Er trägt das Datum 24.08.2016. Kannst du dazu mehr sagen? --92.72.142.203 17:59, 11. Mär. 2019 (CET) Beantworten

502 Bad Gateway

Letzter Kommentar: vor 5 Jahren 8 Kommentare5 Personen sind an der Diskussion beteiligt

(Verschoben von Vorlage Diskussion:Internetquelle#502 Bad_Gateway)

Hallo, wenn man von „Vorlage:Internetquelle" – Links auf diese Seite versucht Anzahl der Einbindungen zu erreichen kriegt man nach geraumer Wartezeit lediglich die Fehlermeldung "502 Bad Gateway".--Ciao • Bestoernesto 04:52, 16. Mär. 2019 (CET) Beantworten

Wird temporärer Schluckauf sein; vor einer Weile gab es mal einen Crash in den Labs, und wir sind froh dass die meisten wieder laufen. Könnte eine Nachwirkung sein, dass da was noch nicht wieder ganz stabil ist. Morgen oder übermorgen mal probieren; das hatten einige Tools die Tage vorübergehend, und fingen sich dann nach einigen Stunden wieder.
Direkt daneben sind eigentlich immer Links mit „Cirrus" oder so; der kann das Gleiche für den ANR, und auf Wunsch auch alle Namensräume, und damit den gleichen Wert ermitteln.
LG --PerfektesChaos 12:06, 16. Mär. 2019 (CET) Beantworten
Ich hatte sowas gestern mit persondata, irgendwann um 11:30 ist das ausgefallen (mit 502) und gemerkt hat es Graphikus um 18:30. Ich hab mir einen kleinen Watchdog geschrieben, der alle halbe Stunde prüft. Ist sicher verbesserungswürdig, wer einen Account auf den Servern hat, kann das Ding (inkl. Eintrag in der crontab) lesen: /data/project/persondata/diverses/watchdog.php Ob das Ding funktioniert, werde ich beim ersten Ausfall sehen ... --Wurgl (Diskussion) 12:21, 16. Mär. 2019 (CET) Beantworten
Maintainer Jarry1250 ist inaktiv. Gruß --FriedhelmW (Diskussion) 13:30, 16. Mär. 2019 (CET) Beantworten
Dann ist am 25/26.3 das Problem mit dem 502er erledigt, weil da werden die alten Server abgedreht und wer nicht umgezogen ist, ist dann wohl tot. --Wurgl (Diskussion) 15:04, 16. Mär. 2019 (CET) Beantworten
Ich hatte gerade vor, dieses 502-Problem bei Fehlermeldungen über bestimmte Tools (sofern kein eigener Tag) unter Wikimedia Tool Labs Ressourcen unter zu bringen, kriege aber lediglich die Fehlermeldung "404 Not Found". Wollte dies nunmehr hier melden und stelle fest, dass Dank FriedhelmW das 502-Problem auch schon hier gelandet ist. Jetzt stellt sich nur die Frage, ob das 404-Problem die selbe, wie von PerfektesChaos geschilderte Ursache haben könnte, oder ob das ne andere Baustelle ist.--Ciao • Bestoernesto 15:25, 16. Mär. 2019 (CET) Beantworten
Andere Baustelle. Das Tools-Projekt findet man jetzt unter https://phabricator.wikimedia.org/project/view/703/. --FriedhelmW (Diskussion) 15:53, 16. Mär. 2019 (CET) Beantworten
Geht wieder. --тнояsтеn 08:12, 22. Mär. 2019 (CET) Beantworten
Dieser Abschnitt kann archiviert werden. FriedhelmW (Diskussion) 22:45, 22. Mär. 2019 (CET)

Timelines in mobiler Version unsichtbar

Letzter Kommentar: vor 5 Jahren 4 Kommentare3 Personen sind an der Diskussion beteiligt

Hallo zusammen,
zufällig ist mir aufgefallen, dass das Timeline-Diagramm in Boeing 787#Bestellungen und Auslieferungen nach Jahr in der mobilen Version nicht angezeigt wird (getestet mit Chrome, sowohl unter Windows 10 als auch unter Android 7.1.1 sowie 8.0). Eigentlich bin ich ziemlich sicher, dass das vor wenigen Monaten noch funktioniert hat.
Unter Hilfe:Zeitleisten habe ich dann erfahren, dass diese Funktionalität sowieso nicht mehr lang unterstützt wird. Allerdings tritt beim „Nachfolgemodell" offenbar durchgängig derselbe Fehler auf (siehe etwa mw:Extension:Graph/Demo in der mobilen Ansicht). Insofern ist meine Hoffnung gering, dass ein Umbau auf diese Erweiterung Abhilfe schaffen würde, selbst wenn mir der gelänge.
Hat jemand eine Idee dazu? Vielen Dank im Voraus --Monow (Diskussion) 22:07, 13. Feb. 2019 (CET) Beantworten
Nach mehr als einem Monat ist das Problem unverändert. Es wäre sehr nett, wenn mir immerhin jemand bestätigen könnte, dass der Anzeigefehler nicht nur bei mir auftritt. Danke! --Monow (Diskussion) 21:06, 17. Mär. 2019 (CET) Beantworten

Die Grafik fehlt bei mir in Chrome, Firefox und Edge. Gruß --FriedhelmW (Diskussion) 21:12, 17. Mär. 2019 (CET) Beantworten
Siehe phab:T216318 (und mw:How to report a bug). --AKlapper (WMF) (Diskussion) 02:13, 25. Mär. 2019 (CET) Beantworten

formatierung bei edit-filter kaputt

Letzter Kommentar: vor 5 Jahren 7 Kommentare2 Personen sind an der Diskussion beteiligt

gudn tach!
wenn man in einem artikel z.b. versucht, den 31. Februar oder die zeichenkette '''Fetter Text''' einzubauen, wird man per edit-filter-regel #55 bzw. #6 gewarnt.
im preview auf Special:AbuseFilter/55 bzw. Special:AbuseFilter/6 wird die warnung auch richtig angezeigt. und auch die entsprechenden meldungsseiten sehen korrekt aus: MediaWiki:Abusefilter-warning-falsches-datum bzw. MediaWiki:Abusefilter-warning-testeditwarn.
aber wenn die regel tatsaechlich greift, wird die jeweilige tabelle der meldung nicht als wikitext interpretiert, sondern literal, siehe WP:Bearbeitungsfilter/55#Fehlermeldung. kann auch jeder selbst ausprobieren (die regel greift jedoch nur im main namespace).
woran liegt das? (fyi: user:Umherirrender, user:PerfektesChaos.) -- seth 23:50, 18. Mär. 2019 (CET) Beantworten

Ich mutmaße einen fehlenden Zeilenumbruch vor der Wikisyntax-Tabelle.
Abhilfemöglichkeiten:
  1. Eigene Zeile mit Inhalt <nowiki /> voranstellen.
    • Dann gehört auch ein |- zwischen {| und | – uralte und irritierende Schlampigkeit, die wir versuchen dem ANR abzutrainieren. Einheitlich jeder td-Gruppe ein tr voranstellen vermeidet Verständnisprobleme und Denkfehler.
  2. Umstellung auf <div> macht es noch robuster, reicht in diesem Fall, weil keine Spalten auftreten, Bausteindesign9 würde auch wirken, ginge dann immer über ganze Breite aber ob des Textumfangs die Tabelle auch.
Mich anzupingen ist hier in der TWS nicht erforderlich; ich lese sowieso mit und antworte, wenn es sich fügt, und bedarf keines Alarms; und der Umherirrende ist hierzuwiki leider nur noch selten unterwegs und würde per TWS-Beo reagieren.
LG --PerfektesChaos 10:48, 19. Mär. 2019 (CET) Beantworten
gudn tach!
danke, ich hab's jetzt mal per div umgesetzt. Bausteindesign9 alleine haette nicht genuegt. das padding waere zu klein gewesen. und die schriftfarbe waere dann rot gewesen, was keinen besonders guten kontrast zum hintergrund ergeben haette. bleiben noch drei fragen:
  1. spricht was gegen diese neue formatierung?
  2. da es mehrere regeln betrifft, wuerde ich die formatierung gerne in ein template auslagern. wie sollte das template heissen? (gibt's da irgendwelche konventionen, oder darf ich's einfach z.b. template:edit filter formatting) nennen?
  3. in enwiki gibt's ein template en:template:edit filter warning, auf dem anscheinend deren warnings alle aufbauen. wenn ich sowieso alle unsere edit-filter-warnings nun ueberarbeiten muss, waere es dann sinnvoll, wenn ich beim umbau auch solch ein framework-template einsetze? (ich glaube schon, aber ich mache nur selten mit den templates rum und wuerde mich deshalb ueber meinungen erfahrener leute freuen.) -- seth 10:49, 24. Mär. 2019 (CET) Beantworten
  • In den Vorlagen-Namensraum lieber nicht; dort verkomplizierst du nur die Verwaltung.
    • Einfach genauso wie eine Vorlage programmieren, jedoch als MediaWiki:Abusefilter-!Box im MediaWiki-Namensraum anlegen, und von dort genauso mit Parameterzuweisungen einbinden.
    • Hat noch den Vorteil, dass es vandalensicher ist, und alle, die an der Box designen, sind auch edit-filterer, und mit dem ! vornedran kommt es in der Auflistung aller entsprechenden Seiten ganz oben, zumindest langfristig außerhalb der Reihe, und zeigt die für viele Einzelfilter überspannende Bedeutung.
    • Ich empfehle Text= statt des früher mal üblichen tippereisparenden unbenannten Parameters; wenn im Box-Inhalt nämlich ein HTML-Element vorkommt und da irgendwas mit style= zugewiesen wird, dann ist alles links von diesem Gleichheitszeichen der Parametername und das merkt aber niemand und erst die vom Filter Betroffenen sehen Grütze, nämlich eine leere Box.
    • Ansonsten ist eine solche standardisierte Box für alle Nachrichten gleichen Typs (kann ja ein #switch enthalten mit rot, gelb, hellgrau) ein völlig normaler Vorgang und durchaus zu empfehlen.
  • Schaust du bitte mal in WP:FZW #Archivlinks, ohne den Ort versteckter Entwürfe der breiten Mitleserschaft zu offenbaren? Immer das gleiche Thema; da steht doch was von wenn nicht mehr erreichbar, aber das raffen die Leut einfach nicht.
LG --PerfektesChaos 14:03, 24. Mär. 2019 (CET) Beantworten
gudn tach!
ok, danke. hab jetzt MediaWiki:Abusefilter-!Box erstellt und werde dann mal die meldungen nach und nach anpassen. um den (eigentlich redundanten) parameter mit der filter-regel-nummer kommt man wohl leider nicht herum, da der parameter 2ドル anscheinend (bei einem test von mir) nicht durchgereicht wird, oder?
fuer den type braeuchte ich eigentlich kein switch, da er nur zwei verschiedene werte annehmen kann und ich aktuell einen default-wert angebe. vielleicht schmeisse ich den default-wert aber wieder raus. eigentlich soll der type immer explizit gesetzt werden. (hab mich nur innerlich gestraeubt, weil fuer mich ein switch ohne default gruselig aussieht.) -- seth 18:46, 24. Mär. 2019 (CET) Beantworten
Du musst schon Message-Syntax 2ドル übersetzen in Vorlagen-Syntax; das ist nur beim Auswerten der Message bekannt, später kann das niemand wissen und ist deshalb auch nicht redundant. Wäre genauso, wenn in der Vorlage drüber {{{dingens}}} bekannt ist; davon weiß in einer eingebundenen Vorlage auch keiner was.
Den type kann man ja auch für Icons nutzen, Stoppschilder und Warndreiecke und Infos. Der Appetit kommt beim Essen. Zukunftsoffen großzügig konzipieren.
LG --PerfektesChaos 19:03, 24. Mär. 2019 (CET) Beantworten
so, puh. bin durch alle regeln und unterseiten durch. -- seth 21:49, 24. Mär. 2019 (CET) Beantworten
Dieser Abschnitt kann archiviert werden. -- seth 21:49, 24. Mär. 2019 (CET)

Grauabdeckung durch Timeless

Letzter Kommentar: vor 5 Jahren 6 Kommentare2 Personen sind an der Diskussion beteiligt

Ich hab mir mal spaßeshalber Timeless als neuen Skin installiert, nachdem ich bisher immer Vector benutzt hatte. Inzwischen hab ich aber ein paar merkwürdige Effekte festgestellt.

Ich hatte die Schrift im Firefox mit Strg-+ größer gestellt, was Timeless offensichtlich nicht mag.

  1. Die rot-blau-grüne Linie oben wandelt sich erst zu einer rot-blauen und dann zu einer roten Linie.
  2. Rechts entsteht ein breiter, dunkelgrauer Rand.
  3. Beim Aufruf des Artikels Ohrenrobben zeigte sich, dass dieser dunkelgraue Rand Teile, die über den eigentlichen Artikelrand hinausgehen überdeckt. In vorliegenden Fall betraf dies speziell das zweite Kladogramm im Abschnitt Systematik.
  4. Die grüne Linie unterhalb des eigentlichen Artikels ist rechts "gekappt".
  5. Sobald die obere Linie komplett rot ist, tritt ein Bruch auf, wenn man ganz nach oben geht. Der Linienteil oberhalb des dunkelgrauen Randes wird nach oben versetzt. Erst wenn man wieder ein Stück runter geht, ist die Linie wieder durchgängig.

Am störendsten ist dabei natürlich Punkt 3, da die betroffenen Teile nur noch schlecht lesbar sind. --Duschgeldrache2 (Diskussion) 00:53, 24. Mär. 2019 (CET) Beantworten

Besteht das Problem auch auf dieser Seite? Gruß --FriedhelmW (Diskussion) 16:42, 24. Mär. 2019 (CET) Beantworten
Ist leider immer noch alles so, wie oben beschrieben. --Duschgeldrache2 (Diskussion) 17:03, 24. Mär. 2019 (CET) Beantworten
Okay, Korrektur. Inzwischen scheint das Problem weg zu sein. Tja, egal, was es war. Auf jeden Fall Danke fürs reparieren. --Duschgeldrache2 (Diskussion) 17:33, 24. Mär. 2019 (CET) Beantworten
Das zweite Kladogramm ist zu breit. Ich habe mit <div style="overflow:auto"> einen Rollbalken eingebaut. Gruß --FriedhelmW (Diskussion) 17:40, 24. Mär. 2019 (CET) Beantworten
Hm, dass das Kladogramm über den Artikelrand hinausgeht hatte ich ja auch schon festgestellt. Allerdings ist das ein Problem der Vergrößerung. Stellt man die Schriftgröße mit Strg-- klein genug ein, gibt’s keine Überbreite. Ich tippe mal, dass so ziemlich bei jeder Tabelle o. ä. ab einer gewissen Vergrößerung Überbreite entsteht. Das fällt in vielen Fällen halt nur nicht auf, weil die Tabellen usw. in vielen Artikeln in Normalvergrößerung auch normalbreit erscheinen. Ist mir ja auch erst durch den Grauschleier aufgefallen.
Allerdings denke ich auch, dass sich das Ganze nicht völlig lösen lassen wird. Zum einen benötigen manche halt ’ne größere Darstellung, um Sachen besser lesen zu können (Barrierefreiheit!). Zum andern ist die Frage, ob man so was quasi automatisiert lösen kann. Wahrscheinlich müsste man etliche Konstrukte in WP "verdachtshalber" mit solchen horizontalen Rollbalken versehen, um entsprechende Probleme zu vermeiden. Da werden sich einige freuen (nicht nur die Biologen ;-). Bei Tabellen kann man ja immerhin den Grauschleier durch Festlegung der Hintergundfarbe vermeiden, auch wenn die Tabelle zu breit ist. Das Erledigt spar ich mir mal, falls noch jemand was zu sagen hat. --Duschgeldrache2 (Diskussion) 18:29, 24. Mär. 2019 (CET) Beantworten

Der Medienbetrachter ignoriert Formelzeichen

Letzter Kommentar: vor 5 Jahren 3 Kommentare2 Personen sind an der Diskussion beteiligt

Beispielsweise ist das in der einzigen Grafik des Artikels Dynamische Radlastverteilung zu sehen. Formelzeichen wie しろさんかく F {\displaystyle \triangle F} {\displaystyle \triangle F} werden schlicht nicht angezeigt. Ist das eine Fehlfunktion des Medienbetrachters oder läuft hier sonst was schief? --Q42xp (Diskussion) 20:53, 27. Mär. 2019 (CET) Beantworten

Ohne jetzt in Details der Formeln oder der fraglichen Seite einzugehen:
  1. Der Medienbetrachter ist zur Betrachtung statischer Dateien (=Bilder) vorgesehen, die eine eigene Medien-Seite und eine eigene Dateibeschreibungsseite haben, wie Datei:Beispiel.png.
  2. Formel-Bildchen werden temporär dynamisch spontan generiert. Sie sind deshalb grundsätzlich dem Medienbetrachter nicht zugänglich, weil flüchtig.
  3. Der Medienbetrachter ist für bildschirmfüllende Fotos und detaillierte Grafiken vorgesehen. Viele Minibildchen, etwa Icons, deren Informationsgehalt bestens auf einen Daumennagel passt, sind von der bildschirmfüllenden Betrachtungsweise ausgenommen.
VG --PerfektesChaos 21:01, 27. Mär. 2019 (CET) Beantworten
Wenn ich dich richtig verstehe, ist der Medienbetrachter grundsätzlich nicht gewillt mathematische Formelzeichen darstellen, die in der Dateibeschreibung oder im Untertext des eingefügten Bildes sind. In meinem Beispiel habe ich dann allerdings ein Problem. Ich weiß nicht wie ich das Formelzeichen しろさんかく F {\displaystyle \triangle F} {\displaystyle \triangle F} sonst darstellen kann. Gibt es hier irgendeine Alternative? --Q42xp (Diskussion) 21:23, 27. Mär. 2019 (CET) Beantworten
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Werkstatt&oldid=187000115"