Wikipedia:Technik/Werkstatt

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Auf dieser Seite werden Abschnitte ab Überschriftebene 2 automatisch archiviert, die seit 10 Tagen mit dem Baustein {{Erledigt|1=~~~~}} versehen sind. Die Archivübersicht befindet sich unter Wikipedia:Technik/Archiv.

Dauerbaustellen; Spezifikationen für wünschenswerte Werkzeuge[Quelltext bearbeiten]

  • 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[Quelltext bearbeiten]

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

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

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

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

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

class="metadata" und <ref>[Quelltext bearbeiten]

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

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

Darstellungsfehler QS-Baustein in Mobilversion[Quelltext bearbeiten]

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

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

Darstellungsfehler.png

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

<Ende Übertrag>

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

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

nochmal in Bugzilla gesucht: könnte bugzilla:62460 sein. Der vorgestellte Fix (an einem leicht anderen CSS-Selektor wegen Less?) dort löst laut meinem Test gerade das auf eine spezielle Weise: Das (QS-)Bild wird nicht verzerrt. Es wird einfach nur bis nur Nichterkennbarkeit kleiner. Jemand mehr Durchblick? --se4598 / ? 15:23, 16. Mär. 2014 (CET)
Moin Moin @Mabschaaf und se4598, da Benutzer Impériale augenscheinlich nicht mehr im Projekt unterwegs ist, mal an euch beide. Ich würde den Absatz für erledigt ansehen, mag das jemand von euch gegenprüfen? Bugzilla ist geschlossen, meine Mobil-Version zeigt allerdings kein Icon. mfg --Crazy1880 21:55, 8. Jun. 2019 (CEST)
@Crazy1880: Auf meinem Mobilphone sehe ich (beobachtet in Guanidiniumcarbonat) zwar kein verzerrtes Bild wie oben beschrieben, dafür das Icon in geschätzter Größe von 5x5px. Es stört nicht wirklich, weil es so klein ist, aber erfüllt natürlich auch nicht seinen Zweck. Aus meiner Sicht daher nicht erledigt.--Mabschaaf 19:03, 9. Jun. 2019 (CEST)
Der Medizin-QS-Baustein zeigt das linke Bild in gleicher Weise extrem verkleinert, den rechten Wikiball dagegen gar nicht (Chiroskop). Der Baustein der Biologen (Tuberkel) und der Physiker (Gequetschtes Licht) ist anders aufgebaut (Piktogramm wird vom Text umflossen), dort gibt es das Problem so nicht. Falls es hilft: iOS 12.2, Monobook.--Mabschaaf 10:04, 10. Jun. 2019 (CEST)
Hinweis: Da spielt der Skin mit rein! Unangemeldet (Browser-Ansicht mit Vector) beginnt der Text der QS-Box sich unter einer Breite (des Browserfensters) ca. 485 Pixel mit dem Rahmen zu überschneiden, außerdem wandert die Infobox zu weit nach rechts und überschneidet sich mit der Leiste links. Das Icon is QS-Box behält konstante Größe.
Angemeldet mit Monobook wird unter einer Breite ca. 550 das Icon plötzlich winzig und die Leiste links verschwindet. Und bei kleinerer Breite als ca. 390 Pixel wandert die Infobox links aus dem Fenster und ich auch per Scrollbar nicht zu erreichen.
In der mobilen Ansicht ist das Icon in der QS-Box immer recht klein, wird aber je nach Fensterbreite noch kleiner. Bei ca. 1070 Pixel Fensterbreite ist IMHO der erste Verkleinerungsschritt des Icons. Dafür skaliert die Infobox brav, da wird nix abgeschnitten und auch das QS-Fenster skaliert ganz nett, das bekommt eine hor. Scrollbar.
Jeweils Firefox, ein verzerrtes Bild wie am Screenshot sehe ich nicht. --Wurgl (Diskussion) 10:21, 10. Jun. 2019 (CEST)

Ich rate erstmal zur syntaktischen Entrümpelung und Modernisierung, und wenn mit aktueller Syntax das Problem weiter besteht, dann mag es näher untersucht werden. Ist aber Angelegenheit der Chemiker; denen ihr Design und Dings. Mängelliste:

  • align:center;
    • Ist falsche Syntax; deshalb komplett ignoriert.
    • Gemeint war: text-align:center;
    • Wirkung trotzdem fraglich bei Block-Elementen auf Seitenbreite. Worauf soll es überhaupt wirken, wenn es nioht ohnehin unwirksam wäre?
    • Kann für den Block eigentlich niemals auftreten, es sei denn, der Text wird auf einer Kinoleinwand in einer einzigen Zeile dargestellt.
    • Wenn überhaupt, dann class="center" oder class="centered"
  • Tabelle: Schreiben wir in der Vorlagenprogrammierung vollständig mit |- nach {|
    • Jedoch kein Effekt betreffend Problematik.
  • <noinclude>
    • Schreiben wir nicht mehr, sondern <onlyinclude>.
    • Jedoch kein Effekt betreffend Problematik.
  • Datei:...|zentriert
    • Inhaltlich sinnlos.
    • Wäre in der Tabellenzelle ohnehin am gleichen Ort, weil Text-Zelle sich maximal ausbreiten wird.
    • Möglicherweise ursächlich.
  • Barrierefreiheit
    • Gegenüber blinden Benutzern blenden wir nicht weiterhelfende Dekoration aus. Heißt: Icon nur für Sehende.
  • Druckausgabe
    • Da zeigen wir eigentlich keine Management-Kästen.
  • {{Dokumentation/ruler}}
    • Damit deuten wir den Beginn der Doku und das Ende der Demo an.
  • Tabelle in div
    • Vielleicht mal was Hochmodernes: Gar keine Wikisyntax-Tabelle mehr, dafür responsives Design.
    • Vorlage:QS-Statistik
    • Mal mit den fraglichen Geräten deren Einbindungen ausprobieren. Wenn dort Problem futsch, dann in der syntaktischen Struktur der Statistik die Chemie mit deren Texten und Icon und Farben neu aufbauen, und gut ist.

FF --PerfektesChaos 11:05, 10. Jun. 2019 (CEST)

JavaScript-Lösung für MediaWiki:Specialpage-helplink[Quelltext bearbeiten]

Hallo,

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

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

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

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

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

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

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

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

Die „Design-Ziele“ meines Entwurfs sind folgende:

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

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

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

insource:/\)\|\]\]/[Quelltext bearbeiten]

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

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

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

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

Die Cirrus-Suche im Titel ergibt nun wieder 202 Treffer. Wäre die periodische Korrektur vielleicht eine für einen Bot zu bewältigende Aufgabe? --Leyo 10:27, 2. Nov. 2020 (CET)

Hmm … ist eine interessante Sache. Wenn niemand ein Veto einlegt, dann mach ich das. Einschränkungen:
* Wenn das innerhalb eines Kommentars steht --> Nein
* Wenn zwischen der korrespondierenden [[ und ]] ein nowiki, ein "<" oder ">" (Kommentar-Beginn/Ende bzw. ref, Tag), ein Anker (#), geschlungene Klammern oder noch ein weiteres Pipe-Zeichen steht --> Nein
* Nur im ANR.
--Wurgl (Diskussion) 12:13, 2. Nov. 2020 (CET)
Danke fürs Angebot, hört sich prima an! --Leyo 13:32, 2. Nov. 2020 (CET)
Noch zwei Einschränkungen:
* Der Link muss existieren, siehe Spezial:Diff/205132941 oder wenigstens ein Rotlink sein, der von wo anders verlinkt ist (siehe: Rotlink "Harald Ludwig (Erziehungswissenschaftler)" in Montessoripädagogik)
* und darf kein Link auf eine Kategorie sein, dort gibts auch ein paar Treffer.
sonst: Das Ding macht diese Nacht mal ein paar zum Ausprobieren, Trockentest sieht jedenfalls gut aus.
Und grob die Hälfte der Treffer ist innerhalb eines Kommentars. --Wurgl (Diskussion) 15:36, 2. Nov. 2020 (CET)
Auch diese Einschränkungen machen Sinn. Die Testedits von APPERbot von heute Nacht ab 02:24 sehen alle gut aus. --Leyo 17:21, 3. Nov. 2020 (CET)
Morgen ist er durch. Eventuell erweitere noch um die 5 Treffer bei "insource:/\[[^]:]*\)\| \]\]/", wobei ich gerade eine Trickserei bei der Vorlage Infobox Fluss sehe. Beispiel: Kinzig (Main), die Zuflüsse mit "(ausgeblendete Namen)". Dieses Konstrukt "| ]]" verhindert die Anzeige. Mal sehen. --Wurgl (Diskussion) 08:44, 4. Nov. 2020 (CET)

Anzeige von Änderungen[Quelltext bearbeiten]

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)

Interaktive Karten auf Wikipedia[Quelltext bearbeiten]

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. [2] [3]

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

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

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

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

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

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

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

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

Formeldarstellungsfehler (LaTeX) mit Android[Quelltext bearbeiten]

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

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

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

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

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

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

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

Standardtext beim Verwerfen von ungesichteten Änderungen bei IPv6 ist zu lange[Quelltext bearbeiten]

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

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

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

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

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

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

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

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

@Umherirrender, Raymond:

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

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

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

Lupenfunktion für große Bilder (vor allem Landkarten)[Quelltext bearbeiten]

Liebe Wiki-Techniker,

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

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

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

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

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

Das ist zwar nett, aber doch keine Wiki-Lösung! Dabei kannst du die Legende nicht sehen und musst etliche Schritte vollführen, die viele User überhaupt nicht können/kennen. Meine Frage bleibt offen: Wie wäre es mit einer Lupenfunktion? --Fährtenleser (Diskussion) 07:19, 27. Mär. 2017 (CEST)
Hat noch niemand außer ProloSozz diesen Vorschlag gesehen? Er würde den Informationswert von großen Landkarten beträchtlich erhöhen! Wo sind die Profis? --Fährtenleser (Diskussion) 12:27, 4. Apr. 2017 (CEST)
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)

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

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

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

MathJax Benutzerscript[Quelltext bearbeiten]

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

Quelltextbearbeitung teilweise in englischer Sprache[Quelltext bearbeiten]

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

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

Positionskarte zeigt im mobilen Skin falsche Positionen, wenn die Bildunterschrift zu lang ist[Quelltext bearbeiten]

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)

Rendern zu PediaPress[Quelltext bearbeiten]

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

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

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

sum_cat_disc.py hat ein Login-Problem[Quelltext bearbeiten]

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

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

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

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

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

Timeless und Formatvorlage Bahnstrecke[Quelltext bearbeiten]

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

Meiner Ansicht nach ist phab:T183827 der richtige Ort dafür. –Schnark 10:05, 18. Jan. 2018 (CET)
+1
Muss ja nicht nur .bs-icon betreffen, sondern andere Themen genauso.
Wir könnten bis zur Lösung von T183827 eine temporäre CSS-Regel durch Admin bereitstellen, falls jemand den richtigen kollateralschadenfreien Selektor für img ausguckt.
LG --PerfektesChaos 10:41, 18. Jan. 2018 (CET)
phab:T175890 (wovon das oben genannte ein duplicate war) wurde jetzt vor zwei Jahren als resolved geschlossen und die dort genannte Änderung hat es auch etwas abgemildert, aber das Problem besteht weiterhin (auch in Minerva, wo außerdem teilweise gar keine Symbole angezeigt werden). --nenntmichruhigip (Diskussion) 21:45, 22. Jun. 2020 (CEST)
Wo in MediaWiki talk:Common.css gerade Minerva erwähnt wurde hänge ich hier mal einen weiteren Darstellungsfehler in der FVBS mit der selben Frage („Wo beheben?“) dran: Mit dem Skin Minerva sind die div.bs-icon 0.6 px zu hoch. Mit kleineren Werten für font-size lässt sich das behoben, aber ohne Anpassung ist es genauso wie in Vector 100%; scheint also noch einen anderen Lösungsweg zu geben. --nenntmichruhigip (Diskussion) 11:03, 19. Jan. 2018 (CET)

Zeilenumbruch nach «schweizbezogen» vor einer Vorlage für Mouse-over notwendig[Quelltext bearbeiten]

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

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

Ende Kopie

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

Benutzerinfo in der Desktopversion[Quelltext bearbeiten]

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)

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

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

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

Zu große Klick-Area für die Editorwechsel-Icons des Bearbeitungsfensters[Quelltext bearbeiten]

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

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

A note on ‘mapframe’ maps and this wiki[Quelltext bearbeiten]

Hilf bitte mit, in deine Sprache zu übersetzen

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

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

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

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

Script für mobile Version[Quelltext bearbeiten]

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

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

Miniatur Vorschau der Wiki Artikel auf eigener Website (Wordpress)[Quelltext bearbeiten]

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

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

Edits mit Tablet / Ipad wieder erschwert. 9.9.2018[Quelltext bearbeiten]

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

@Orik: Welcher Editor wird genutzt? Welcher Browser und welche Browserversion werden genutzt? Welche Betriebssystemversion wird genutzt? Geschieht dies auch wenn explizit safemode=1 gesetzt wird? --Malyacko (Diskussion) 12:13, 1. Aug. 2018 (CEST)
SORRY! DASS ICH MICH SO SPÄT MELDE, @Malyacko: ICH BIN IN ferien mit nicht so gutem Iternetanschluß. ich benutze den SAFARIBROWSER AUF EINEM IPAD MIT DEM (Betriebssystem für mobile GERÄTE) IoS 10.33. DIE VERSION von SAFARI IST NICHT ERSICHTLICH UND WIRD jeweils MIT DEM BETRIEBSSYSTEM ERneuert. DEr FEHLER MIT DER Klein- und GRossschreibung tritt nur beim editieren in Wikipedia auf. gruß --Orik (Diskussion) 00:48, 5. Aug. 2018 (CEST) PS: Den Editor kann ich nicht benennen.
PS: DER Fehler tritt nur bei Quelltextbearbeitung auf.--Orik (Diskussion) 09:51, 12. Aug. 2018 (CEST)
PROBLEM IMMER NOCH NICHT GELÖST. --Orik (Diskussion) 23:06, 30. Aug. 2018 (CEST)
Seit heute funktioniert die Groß- und Kleinschreibung mit dem Tablet wieder. Ebenso funtioniert das Löschen längerer Texte wieder, weil die Rückschrittaste nach einem bestimmten Anlauf wieder ganze Worte löscht.Orik (Diskussion) 01:50, 5. Sep. 2018 (CEST)
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)
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)
Änderungen serverseitig an der Wiki-Software erfolgen donnerstags. --Count Count (Diskussion) 12:10, 10. Sep. 2018 (CEST)
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)
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)
@Orik: Ist das noch in irgendeiner Weise ein Problem? --Count Count (Diskussion) 14:10, 6. Sep. 2020 (CEST)
danke der Nachfrage. Das Problem hat sich erledigt. Ich weiß nicht mehr, was der Grund für die Fehlfunktion war. Ich hatte das übrigens mit mehreren Tablets versucht. Gruß --Orik (Diskussion) 23:11, 6. Sep. 2020 (CEST)

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

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

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

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

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

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

Koordinaten verdecken erste Zeile in Infoboxen[Quelltext bearbeiten]

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)

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)
Danke, ich werde vorerst den Weg des geringsten Widerstands gehen und einfach Skin wechseln. K1812 (Diskussion) 17:44, 20. Sep. 2018 (CEST)

Fehlermeldung, kein Edit möglich[Quelltext bearbeiten]

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)

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)
PS: (Da hier wohl der "Vorlagenmeister" im Spiel ist) ist Benutzer:PerfektesChaos der richtige Ansprechpartner. -- User: Perhelion 09:10, 23. Sep. 2018 (CEST)
(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)
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)
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)
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)
@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)
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)

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

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

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

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

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

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 ( typeof window.navigator  ===  "object"   &&
     typeof window.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)

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)

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

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

Ausbessern des Links zur Suche in anderssprachigen Wikipedias[Quelltext bearbeiten]

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)

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

Breite Formeln und Tabellen werden im mobilen Skin abgeschnitten[Quelltext bearbeiten]

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)

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)
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)
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)
Ich schätze, da wird man wohl bei den CSS-deklarationen was Ändern müssen.
  #mw-content-text img[src*="/wikipedia/de/math/"], #mw-content-text table {
    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)

RevisionAccessException[Quelltext bearbeiten]

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)

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

War Programmfehler in der Server-Software; müsste behoben sein. --PerfektesChaos 17:29, 7. Jun. 2019 (CEST)

Autsch. Ist ja doch noch drin. --PerfektesChaos 17:30, 7. Jun. 2019 (CEST)
@Se4598: WOW! Dich jibbet noch? Du lebst? Welch Freude! Lass dir knutschen! --PerfektesChaos 23:04, 9. Jun. 2019 (CEST)

Unterschiedliche Auswertungsergebnisse[Quelltext bearbeiten]

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)

You have enabled both this script and the MediaViewer.[Quelltext bearbeiten]

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)

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)
Schönen Dank, Lómelinde, ich hab jetzt mal hier gefragt. -- Karsten Meyer-Konstanz (D) 14:46, 1. Dez. 2018 (CET)
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)

Wenn ein Beitrag versteckt wird, bricht die Versionsgeschichte ab[Quelltext bearbeiten]

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)

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)
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)
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)
Das scheint nicht beim "klassischen", sondern nur beim "verbesserten Diff" (Benutzer:Schnark/js/diff) aufzutreten. --FriedhelmW (Diskussion) 15:20, 26. Dez. 2018 (CET)
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
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)
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)
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)

Buchfunktion / Sammlungen[Quelltext bearbeiten]

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)

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)

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)

NichtAnzeige bildartiger Elemente in der HomePage[Quelltext bearbeiten]

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)

Edittextfeld beim Sichten zu kurz?[Quelltext bearbeiten]

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

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)

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)

Die Längenbegrenzung ist maxlength="200", während es sonst 500 Zeichen sind. --FriedhelmW (Diskussion) 16:19, 21. Jan. 2019 (CET)
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)
Ich verweise auf die Wikipedia:Technik/Werkstatt. Gruß --FriedhelmW (Diskussion) 21:34, 21. Jan. 2019 (CET)
Danke für den Hinweis auf diese Stelle, werde das Thema nach dort verschieben. VG --Bicycle Tourer (Diskussion) 21:48, 21. Jan. 2019 (CET)

Druckversion: obsolete Seitenelemente[Quelltext bearbeiten]

  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 – Blue ribbon.svg (CallMyCenter) 13:25, 22. Jan. 2019 (CET)

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)
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)
  • 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 – Blue ribbon.svg (CallMyCenter) 23:22, 22. Jan. 2019 (CET)
„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)
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)

Alle meine Scores mit Lilipond und Vorbis-Midi[Quelltext bearbeiten]

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)


\relative c' {\autoBeamOff
             c8 d8 e8 f8 g4 g4 | a8 a8 a8 a8 g2 | a8 a8 a8 a8 g2
             f8 f8 f8 f8 e4 e4 | d8 d8 d8 d8 c2 \bar "|."
}
\addlyrics {
    Al -- le mei -- ne Ent -- chen | schwim -- men auf dem See, | schwim -- men auf dem See,
    Köpf -- chen in das Was -- ser, | Schwänz -- chen in die Höh’.
}

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

Kat-Namen-Übergabe an PetScan[Quelltext bearbeiten]

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)

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)
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)
@Wurgl: Hilfloses Ping an Dich: Das Problem besteht nach wie vor. Wer könnte hier Abhilfe schaffen?--Mabschaaf 08:59, 25. Jul. 2020 (CEST)
In der URL wird doppelt gemoppelt: categories=Benutzer%253Aaus%2BD%25C3%25A4nemark Die Zeile kommt wohl von MediaWiki:Flaggedrevs-categoryview
Ich hab mal auf Beta das urlencode rausgenommen: https://de.wikipedia.beta.wmflabs.org/wiki/MediaWiki:Flaggedrevs-categoryview da klappt es dann, aber hat das irgendwelche anderen unerwünschten Seiteneffekte? Ich hab zu wenig Erfahrung mit dem Zeuchs. --Wurgl (Diskussion) 09:32, 25. Jul. 2020 (CEST)
Nachtrag: Test-Kategorie auf Beta: https://de.wikipedia.beta.wmflabs.org/wiki/Kategorie:Benutzer:aus_Dänemark --Wurgl (Diskussion) 09:38, 25. Jul. 2020 (CEST)
Kann schon sein, dass das dann okay ist; aber es ist dann irgendwie seltsam.
Es ist leider nirgendwo dokumentiert, in welcher Syntax dieses $1 die Systemnachricht erreicht.
Aus dem Verhalten rückgeschlossen, wird offenbar an die Systemnachricht übergeben:
Benutzer%3Aaus+D%C3%A4nemark
Dabei kodiert das + das Leerzeichen in Query-Syntax.
Normalerweise erhalten Systemnachrichten jedoch:
Benutzer:aus Dänemark
und in diesem Fall würde die Petscan-URL nach Benutzer:aus abbrechen und das Dänemark stünde in der Linkbeschriftung.
Nebenwirkungen sind keine zu befürchten.
@Mabschaaf: EIn interessierter Admin kann gern die BETA-Änderung übernehmen.
VG --PerfektesChaos 17:19, 26. Jul. 2020 (CEST)
Done.--Mabschaaf 17:22, 26. Jul. 2020 (CEST)

Prüfung auf doppelte Stimmen[Quelltext bearbeiten]

Hallo, bis vor kurzem konnte ich bei Kandidaturen:

[6]

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)

Aktualisierung der Startseite der alswiki[Quelltext bearbeiten]

Die Startseite der alswiki hängt bei der Aktualisierung regelmäßig mehrere Tage nach, wenn man nicht angemeldet ist. Wir haben die Seite etwas kompliziert aufgebaut, da wir die Sprache der Seite (Begrüßung usw.) wöchentlich wechseln. Dazu kommt der tägliche Wechsel der entsprechenden Vorlage zu Was geschah am ...? Deswegen gibt es es rund 30 Vorlagen, aus denen die Seite aufgebaut ist. Wenn ich angemeldet bin, werden jeweils die aktuellen Vorlagen angezeigt, aber ohne Anmeldung bekomme ich heute immer noch Was geschah am 16. Mai? angezeigt. Kann sich das bitte jemand mal anschauen, ob wir z. B. im Quelltext irgend einen Bug drin haben, der die Aktualisierung verzögert? Danke und liebe Grüße --Holder (Diskussion) 18:30, 22. Mai 2019 (CEST)

Unangemeldet lese ich unten rechts "22. Mai"? --Wurgl (Diskussion) 18:55, 22. Mai 2019 (CEST)
Mittlerweile wird bei mir auch 22. Mai angezeigt. Kann es sein, dass das ein Cache-Problem ist? Wobei ich grundsätzlich beim Schließen des Browsers automatisch den Cache löschen lasse. Vielleicht schauen wir mal, wie es morgen aussieht. --Holder (Diskussion) 20:24, 22. Mai 2019 (CEST)

Es ist eine Caching-Angelegenheit, aber nicht in deinem Browser, sondern bei den Servern.

  • Angemeldete und unangemeldete Benutzer werden von unterschiedlichen Servern bzw. Servergruppen bedient, und jeder Server hat einen eigenen Cache.
  • Angemeldete Benutzer sind weitaus überwiegend Autoren und werden bevorzugt und mit besonders schneller Cache-Politik bedient, auf weniger ausgelasteten Servern.
  • Nicht angemeldete Benutzer, die nach irgendeiner Statistik 99 % der Zugriffe ausmachen würden, sind zu irgendwelchen 99,99 % reine Leser, keine Bearbeiter, und werden ob des Massenandrangs mit einer gemächlicheren Cache-Politik abgefertigt, auf stark frequentierter Hardware.
  • Mir ist so, als ob es früher mal irgendwelche Bots gab, oder sogar heute noch gibt, die bestimmte Seiten zu bestimmten Uhrzeiten purgen, um eine Aktualisierung zu erzwingen.
  • Angemeldet siehst du immer eine möglichst frische Version; nicht angemeldet kann es dauern, bis eine Veränderung in einer Vorlage sich bis zur einbindenden Seite rumgesprochen hat.
  • Ein häufig frequentiertes großes Wiki löst durch viele Seitenbesuche implizite Cache-Aktualisierungen der Unterseiten aus; das könnte ein gewisser Vorteil von dewiki gegenüber alswiki sein.
  • Es wird allen immer der aktuellste Cache-Inhalt geliefert, egal was dein Browser will.

VG --PerfektesChaos 21:42, 22. Mai 2019 (CEST)

Ich kann das jetzt nachvollziehen: Unangemeldet: 22. Mai. Angemeldet: 23. Mai. Nochmals unangemeldet: 22. Mai. --Wurgl (Diskussion) 00:33, 23. Mai 2019 (CEST)

Hallo PerfektesChaos, vielen Dank! Immerhin liegt es dann nicht an einem Fehler im Quelltext ... --Holder (Diskussion) 07:17, 23. Mai 2019 (CEST)

Siehe auch phab:T119366 in mw:Phabricator. --AKlapper (WMF) (Diskussion) 11:08, 24. Mai 2019 (CEST)
  • Danke für das phab-Ticket.
  • Meine letzte tiefer gehende Befassung mit den Cache-Prozeduren liegt ein Jahrzehnt zurück, und zwischenzeitlich sind Serverfarmen und Strategien mehrfach umgemodelt worden. Ich habe nur noch schemenhafte Vorstellungen von den aktuellen Algorithmen.
  • @Holder: Die phab-Geschichte liest sich so, als ob sich eine definitive Lösung noch Jahre hinziehen kann und einer komplexen Lösung und Gesamtstrategie für die gesamte Farm bedürfe; sicher nicht trivial.
    Ich zähle dir mal eine Reihe von Lösungswegen auf, die von unten nach oben als am ehesten praktikabel durchzuprobieren wären.
    • Manuelle Aktualisierung im Browser:
    • Automatisierung (Bot) per API (H:API):
      • Nicht über index.php, sondern api.php.
      • mw:API:Purge
      • Problem: Benötigt purge-Recht.
      • purge-Recht haben in der WMF nur angemeldete Benutzer gemäß Spezial:Gruppenrechte.
      • API-Bot würde den Seitencache der angemeldeten Benutzer leeren. Der ist aber nicht das Problem.
      • Anonymer Automatismus ist möglich, aber diese API-Funktion würde nicht ausgeführt.
    • Automatisierung (Bot) per index.php:
      • Benötigt HTTP-POST (wie auch die API-Variante).
      • Abgeguckt von der interaktiven Bestätigungsseite, deren blauen Button sie simuliert:
      • Müsste von den PC einiger als-Benutzer alle 3 oder 6 Stunden zyklisch abgefeuert werden, die einen 24/7 laufenden Rechner mit permanentem Netz haben.
      • Es gibt für Linux, MS Windows (oder aber in Java) Hunderte und Tausende von kleinen Shell-Hilfsmitteln, mit denen sich ein 10-Zeilen-Skript schreiben ließe, oder entsprechend konfigurierbare komplexere Anwendungsprogramme für sowas. Oder ein hiesiger Bot-Betreiber lässt das nebenbei laufen.
    • Trapper-Trick:
      • Kopiert euch die Vorlage:NULL von hier.
      • Baut unten in der Hauptseite und ggf. weitere sich häufig ändernden Seiten ein:
        {{NULL|{{LOCALDAY}}}}{{NULL|{{#time:G}}}}
      • Könnte zumindest maximal 24 Stunden Hinterherhinken bewirken.
    • Etwaigen Erfolg bitte hier berichten.
VG --PerfektesChaos 14:29, 24. Mai 2019 (CEST)
PerfektesChaos, vielen Dank, ich habe es jetzt mal mit Letzerem versuecht. Da wird allerdings eine schließende geschweifte Klammer auf der Seite angezeigt. Ist da die ein oder andere Klammer in deiner Vorlage zuviel? --Holder (Diskussion) 16:45, 24. Mai 2019 (CEST)
Jau – – VG --PerfektesChaos 16:52, 24. Mai 2019 (CEST)
Hinweis: Der folgende Abschnitt Entsprechendes Problem auf dem Portal:Physik wurde zunächst als Unterabschnitt dieser Diskussion angelegt, wird aber demnächst unabhängig von dieser Diskusssion archiviert. Die dortige Lösung kann dann unter Wikipedia:Technik/Archiv/2020#Entsprechendes Problem auf dem Portal:Physik eingesehen werden. --Dogbert66 (Diskussion) 12:21, 11. Sep. 2020 (CEST)

Mouse-over-Vorschau bei Image-Karten[Quelltext bearbeiten]

Hallo zusammen, In Bezug auf das "Mouse-over-Vorschau mit Karte" Thema wollte ich nachfragen, ob man eine solche Mouse-over Funktion nicht auch bei Interaktiven-Bildern einbauen könnte. So wäre es z.B. sehr wertvoll, wenn man bei der Vorlage Sitzordnung Nationalrat nicht nur den Name sondern auch ein Bild der Person einblenden könnte wenn man mit der Maus über die gewünschte Person fährt. Das gleiche wünschte ich mir auch, wenn man bei der Karte Schweizer SAC Hütten auf einen roten Punkt fährt, dass dann ein Bild der SAC-Hütte erscheinen würde. Gruss --Tschubby (Diskussion) 07:58, 10. Jul. 2019 (CEST)

Transwiki-Formular wird ausgeblendet[Quelltext bearbeiten]

Hallo! Mittlerweile ist es nun bei mehreren aber nicht allen Admins der Fall, dass beim Öffnen von Special:Import das Transwiki-Formular nur kurz aufblitzt und dann verschwindet. Ich bin mir unsicher, aber bei Importeuren ist das so wohl nicht der Fall. Wisst Ihr, was da los ist? Hat es Software-Änderungen gegeben? Was ist zu tun? Danke, – Doc TaxonDisk.Wikiliebe?! 21:49, 13. Jul. 2019 (CEST)

Notiz → @Partynia, Ra'ike, Björn Hagemann, Funkruf: – Doc TaxonDisk.Wikiliebe?! 21:49, 13. Jul. 2019 (CEST)
bei manchen reicht es wohl aus, importUtility zu deaktivieren, bei anderen wieder nicht. Das kann's aber nun auch nicht sein, oder? War importUtility nicht von PerfektesChaos? – Doc TaxonDisk.Wikiliebe?! 21:54, 13. Jul. 2019 (CEST)
Stimmt, einige Minuten nach Deiner Anfrage hier fand Björn die Lösung, die zumindest bei mir funktionierte. Es hilft, in den Spezial:Einstellungen#mw-prefsection-gadgets im Abschnitt "Administratoren und Interna" das Häkchen für importUtility rauszunehmen. Trotzdem vielen Dank für Deine Mühe :-) Viele Grüße -- Ra'ike Disk. P:MIN 21:57, 13. Jul. 2019 (CEST)

Wenn von den routinierten Importeuren mit dem importUtility-System gearbeitet wird, für die dieses Verfahren konzipiert ist, dann ist es entscheidend, dass in dem auf Spezial:Import usw. angebotenen Feldern nichts verändert wird – was irrtümlich mal passieren kann.

  • Falls auf der Spezialseite Informationen verändert würden, dann erfährt die Antragsseite im WP-Namensraum nichts von diesen Änderungen.
  • Im weiteren Verlauf werden anhand der Antragsseite aus Benutzer über Importe informiert usw.; ggf. auch Protokolle erstellt.
  • Wenn jetzt ein importUtility-Importeur auf der Spezialseite im Formular die Aktion manipulieren würde, bekäme der beantragende Benutzer falsche Informationen.

Heißt:

  • Wer massenhaft mit importUtility automatisiert Wünsche der Antragsseiten abarbeiten möchte, kann auf der Spezialseite nichts verändern.
  • Wer nicht die importUtility-Automatik verwenden möchte, sollte auch das Gadget nicht aktivieren.
  • Kann’s also sehr wohl sein.
  • @Brackenheim: FYI

VG --PerfektesChaos 22:27, 13. Jul. 2019 (CEST)

@PerfektesChaos: wenn ich das richtig verstanden habe, heißt dies: wer importUtility eingeschaltet hat, sieht auf Special:Import kein Formular mehr, und das soll so auch erwünscht sein? – Doc TaxonDisk.Wikiliebe?! 22:33, 13. Jul. 2019 (CEST)
Das wurde sogar ganz ausdrücklich von den mit importUtility automatisiert Anträge abarbeitenden Importeuren so gewünscht und erst nachträglich hinzugefügt, nachdem es zu Verwechslungen kam und auf der falschen Seite Angaben verändert wurden.
  • Wer massenhaft mit importUtility automatisiert Wünsche der Antragsseiten abarbeiten möchte, kann auf der Spezialseite nichts verändern.
  • Wer nicht die importUtility-Automatik verwenden möchte, sollte auch das Gadget importUtility nicht aktivieren.
VG --PerfektesChaos 22:37, 13. Jul. 2019 (CEST)
wo gab es Verwechslungen, auf welcher falschen Seite wurden Angaben verändert und wie? Wer manuell mit importUtility arbeitet (es gibt ja hübsche click-Buttons), kann also zunächst erst mal keinen manuellen Transwiki-Import mehr durchführen, weil zuvor erst mal was in den Einstellungen ausgeschaltet werden muss? Und hinterher wieder eingeschaltet werden muss. Was soll denn der Quatsch? – Doc TaxonDisk.Wikiliebe?! 00:31, 14. Jul. 2019 (CEST)
Die Kernaufgabe und der Hauptzweck von importUtility ist die automatisierte Antragsbearbeitung; „um Routineaufgaben beim Import zu automatisieren“ – ein anderer Verwendungszweck als die automatisierte Antragsbearbeitung ist nicht vorgesehen.
  • Dabei kam es zunächst wiederholt zu Bedienfehlern durch die Importeure, weil sie versehentlich auf dem Spezialseiten-Formular Angaben änderten, ohne das in genau gleicher Weise auf der Antragsseite auch zu ändern, oder sonstige Fehlklicks passierten.
  • Auf Wunsch und Anregung wurde deshalb im importUtility-Modus das Spezialseiten-Formular ausgeblendet, wenn von Antragsbearbeitung ausgegangen werden muss.
Mit Aktivierung von importUtility schaltest du den automatisierten Modus der Antragsbearbeitung ein.
Wenn du keine automatisierte Antragsbearbeitung vornehmen möchtest, dann aktiviere importUtility auch nicht.
Die Qualifizierung „Quatsch“ verbitte ich mir ausdrücklich.
--PerfektesChaos 02:12, 14. Jul. 2019 (CEST)
Die verbitte ich mir auch, sorry. Aber danke für die Erklärung,
  • um es bei weiteren Admins gar nicht erst zu dieser Verwirrung kommen zu lassen, fände ich es gut, bei Aktivierung von importUtility auf der Seite Special:Import eine Notiz anzubringen, dass bei eben dieser Aktivierung Formulare ausgeblendet sind. Ich hielte das für sehr sinnvoll. @PerfektesChaos: kriegst Du das bitte noch eingebaut?
Danke, – Doc TaxonDisk.Wikiliebe?! 13:07, 14. Jul. 2019 (CEST)
Falls ich da auch nochmal beispringen darf? Ich hatte ja eigentlich angenommen, der Fall wäre mit der Klärung, dass man mit dem Abschalten des Helferleins "importUtility" wieder die komplette Spezialseite für Importe sehen kann, erledigt.
@PerfektesChaos: Ich denke auch, dass der Vorschlag von Doc Taxon mit der Notiz nicht schlecht wäre, damit man als Admin weiß, warum Teile auf der Spezialseite Importieren ausgeblendet sind. Vorausgesetzt so eine Notiz (vermutlich meint der Doc eine Editnotice) ist auf einer Spezialseite überhaupt möglich. Gruß -- Ra'ike Disk. P:MIN 00:51, 15. Jul. 2019 (CEST)
Die Funktion mit dem Ausblenden wurde damals, soweit ich mich erinnern kann, daher eingefügt, dass man am Formular nichts mehr ändern kann, da doch immer wieder mal etwas schief gegangen ist oder gerade Neulinge mit all den Auswahlmöglichkeiten überfordert waren. Von daher find eich die Funktion nach wie vor nützlich. Den Vorschlag mit dem eingeblendeten Hinweis gefällt mir allerdings ganz gut - aber keine Ahnung, wie man den einblenden kann ... Grüße --Brackenheim 10:43, 23. Jul. 2019 (CEST)

Werden Kategorien von der Suche-Funktion nicht angezeigt ?[Quelltext bearbeiten]

Ich habe die hiesige Suchfunktion wohl bislang noch nie genutzt, um eine Kategorie zu finden.

Darum fiel mir erst jetzt auf, dass nach der Suche nach "Fassadenschmuck" nicht anzeigt wird, dass eine Kategorie:Fassadenschmuck existiert (obwohl das entsprechende Schaltfeld "Kategorie" ja standardmäßig ausgewählt ist).

Auf Commons würde in diesem Fall ja wohl ein Hinweis auf eine entsprechende Kategorie in einem gesonderten Balken oberhalb der eigentlichen Suchergebnisse angezeigt, glaube ich.

Werden Kategorienamen bei uns bei der Suche nicht berücksichtigt?

nette Grüße

-- Kai Kemmann (Diskussion) - Verbessern statt löschen: Enzyklopädie ist altgriechisch für "umfassend" - 10:30, 17. Jul. 2019 (CEST)

Ups, ich muß mich korrigieren: Die Kategorie wird doch angezeigt, allerdings erst ungefähr an 265. Stelle der Suchergebnisse!

Also so weit unten, das man dies im Regelfall wohl gar nicht bemerken würde. Vielleicht wäre ein besonderer Hinweis auf Kategorien wie bei WikimediaCommons auch bei uns wünschenswert? Gerade wenn wie beim obigen Beispiel kein gleichnamiger Artikel existiert, ist es ja wohl oft sehr hilfreich zu erfahren, dass es stattdessen eine Kategorie gibt, die nach dem Suchwort benannt ist. (nicht signierter Beitrag von KaiKemmann (Diskussion | Beiträge) 10:40, 17. Jul. 2019 (CEST))

InvalidArgumentException[Quelltext bearbeiten]

Fehlermeldung bei der Verschiebung von Albert Feldstein‎ nach Al Feldstein‎ (zzt. Weiterleitung):

  • Interner Fehler: [XVBv5wpAADsAAGy2lboAAACV] 2019-08-11 19:43:36: Fataler Ausnahmefehler des Typs „InvalidArgumentException“

Habe es am 2. Mai 2019 schon mal versucht und die gleiche Fehlermeldung erhalten. --Kolja21 (Diskussion) 21:49, 11. Aug. 2019 (CEST)

Ich hab das mal an phab:T225366 drangehängt. Ist nicht ganz die identische Konstellation, aber die Fehlermeldung hat zumindest denselben Typ.
Seit einigen Monaten laufen immer wieder vereinzelte unerklärliche Ereignisse dieser Art auf. Ein eindeutiges Prinzip ist noch nicht erkennbar, und damit keine Identifikation der Ursachen und keine Behebungsmöglichkeit.
Die Vorfälle sind dauerhaft und auch reproduzierbar. Manchmal gibt es irgendeine Störung, gerade Donnerstag Abend, und eine Viertelstunde später ist die wieder weg. Das ist kein behebbarer Software-Bug, sondern vorübergehendes Überlastungs- oder Umstellungsproblem.
Aber Meldungen dieser Art, also die Notfallseite der Software, ohne das Projektportal drumrum, sollten niemals auftreten.
Wenn, dann diese Nummer (und Zeitstempel) [XVBv5wpAADsAAGy2lboAAACV] 2019-08-11 19:43:36 InvalidArgumentException deshalb immer angeben; daran kann im Server-Logbuch das Problem identifiziert werden, um einen detaillierten Absturz-Report ergänzt werden, und Zeitstempel mit Fehlertyp helfen auch ohne Logbuch bei der Einordnung.
VG --PerfektesChaos 12:41, 12. Aug. 2019 (CEST)

Fürs Protokoll: Ich konnte den Artikel heute problemlos verschieben. --Wickie37 17:46, 10. Mär. 2020 (CET)

Ich habe heute den selben Fehler bekommen, als ich einen Artikel verschieben wollte (Dagbani (Sprache)Dagbani). Die WL im Ziellemma hat ein Problem mit den Sichtungen, zweimal bekam ich die Angabe, Vorlagenänderungen seien noch nicht gesichtet, 0 Versionen müssten noch gesichtet werden, nach erneutem Sichten war der Hinweis jeweils wieder weg (und einmal kurz nanach wieder da). Vielleicht gibt es da einen Zusammenhang? --androl ☖☗ 19:01, 4. Okt. 2020 (CEST)
Eine weitere Merkwürdigkeit: In der Linkliste erscheint die Weiterleitung nur, wenn man die Links ausblendet (26 Links (16 im ANR), 1 Einbindung, 3 Weiterleitungen, insgesamt nur 29 angezeigt). Nach einem Nulledit wird sie jetzt richtig angezeigt, dafür ist ein Link aus einem Nichtartikelnamensraum verschwunden, da wurden vorher 10 angezeigt, jetzt sind's noch 9. --androl ☖☗ 22:46, 4. Okt. 2020 (CEST)

einziger Bearbeiter?[Quelltext bearbeiten]

zur Info @Zxmt:

Warum steht in diesem Löschlogbuchkommentar, dass Zxmt der einzige Bearbeiter sei? Da waren soviele weitere Bearbeiter beteiligt. Liegt hier wieder ein Software-Bug vor? – Doc TaxonDisk.Wikiliebe?! 17:33, 13. Aug. 2019 (CEST)

@Leyo, Raymond, Xqt: könnt Ihr vielleicht dazu was sagen? – Doc TaxonDisk.Wikiliebe?! 09:17, 14. Aug. 2019 (CEST)
Dabei habe ich noch nie einen Fehler gesehen. Meine Vermutung, dass das aus deinem Browsercache kommt, hat sich anhand deines Löschlogs nicht bestätigt. --Leyo 09:28, 14. Aug. 2019 (CEST)
Andere Frage, wer kümmert sich denn jetzt darum →Links auf Aspirin (Marke) vs. Links auf Aspirin? Das mit dem einzigen Bearbeiter kenne ich aber auch von Verschiebungen (VG Ziel). Das ist auch für mich immer etwas unlogisch, scheint mir aber irgendwie eine anwählbare oder vorgegebene Option beim Löschvorgang zu sein. --Liebe Grüße, Lómelinde Diskussion 09:56, 14. Aug. 2019 (CEST)
@Lómelinde: mit den Links warten wir lieber, bis die anhängige LD zu Geschichte des Aspirins entschieden ist, sonst machen wir die Arbeit wahrscheinlich doppelt. – Doc TaxonDisk.Wikiliebe?! 10:05, 14. Aug. 2019 (CEST)
Bei den Links auf das Rotlink-Klammerlemma sollte man IMHO nicht zuwarten. Als Zwischenlösung könnte man sie auf die Aspirin-BKS umbiegen. --Leyo 10:53, 14. Aug. 2019 (CEST)
@Leyo: dann seh ich die 100-fachen Beschwerden jetzt schon aufpoppen. Außerdem ist das logischerweise, wie auch immer, in der LP gelandet. Drum würde ich erst recht mal abwarten. – Doc TaxonDisk.Wikiliebe?! 14:16, 14. Aug. 2019 (CEST)
@ Doc Taxon: Den Fehler kann ich nicht nachvollziehen und kenne ihn auch nicht. Nutzt du ein Script zum Löschen, das die Löschbegründung zusammenbastelt? — Raymond Disk. 10:44, 14. Aug. 2019 (CEST)
@Raymond: alles ohne Script, ich habe nur in der Vorauswahl der Löschbegründungen diese mit der Löschdisk genommen. "Einziger Bearbeiter" wird dann wohl irgendwie automatisch dahinter geschrieben, wenn es zutrifft. @PerfektesChaos: Du kennst Dich doch auch bei solchen Sachen aus, weißt Du da was? – Doc TaxonDisk.Wikiliebe?! 10:48, 14. Aug. 2019 (CEST)
Generiert wird die Beschreibung von getAutoDeleteReason() in ContentHandler.php. Im Quelltext sieht man, dass nur die letzten 20 Versionen geprüft werden („Only scan the last 20 revisions“). Waren die letzten 20 Bearbeitungen vor der Löschung von Zxmt? --Count Count (Diskussion) 11:06, 14. Aug. 2019 (CEST)
@Count Count: Bei den letzten 20 war er nur dreimal dabei, aber die ersten 20 waren allesamt von ihm – Doc TaxonDisk.Wikiliebe?! 11:11, 14. Aug. 2019 (CEST)
Und selbst bei den letzten 20 entspräche das ja nicht zwingend der Realität, wenn der 21. ein anderer Bearbeiter gewesen wäre. – Doc TaxonDisk.Wikiliebe?! 11:12, 14. Aug. 2019 (CEST)
Hmm, im Code fehlt für die Datenbankabfrage eine „ORDER BY“-Klausel, so werden jedenfalls nicht die letzten 20 Bearbeitungen abgefragt, sondern irgendwelche 20. Also stimmt der Quelltextkommentar auch nicht. Das ist doch Murks. Die englische Wikipedia hat den Text durch ein „–“ ersetzt, siehe en:MediaWiki:Excontentauthor, und damit der automatischen Kommentar „only contributor...“ komplett ausgeschaltet. --Count Count (Diskussion) 11:20, 14. Aug. 2019 (CEST)

mir ist offen gestanden völlig egal, ob hier ein Bug oder eine Fehlbedienung vorlag. Ich gehe davon aus, dass sich ein Log-Eintrag nachträglich nicht mehr verändern lässt - ist das korrekt? Falls ja, besteht dann wohl nur eine Möglichkeit der Reparatur: wiederherstellen und mit klarem Kommentar und ohne technischen Firefanz neu löschen. Alternativen dafür? --Zxmt Ist das Kunst? 11:16, 14. Aug. 2019 (CEST)

Wir schauen erst mal, worin der Fehler begründet ist und ob und wie wir das beheben können. Diesen Logbucheintrag nehmen wir als Beispiel zur Bugbearbeitung. Daraufhin wird das dann korrigiert werden. – Doc TaxonDisk.Wikiliebe?! 14:20, 14. Aug. 2019 (CEST)
wenn der ursprüngliche Log-Eintrag nicht mehr verändert werden kann, dann kann er nicht mehr verändert werden. (und wenn er verändert werden könnte, dann bräuchten wir keine Logs, denn dann wären die ohnehin zu nichts mehr nütze). --Zxmt Ist das Kunst? 14:25, 14. Aug. 2019 (CEST)

Extras der Graph-Erweiterung[Quelltext bearbeiten]

Wo steht die Dokumentation zu den Features der Graph-Erweiterung, welche wohl nicht zum Standard von Vega gehören (zumindest nicht in der dortigen Doku zu finden), weil sie wohl MW-eigene Extras sind? Konkret: "treeify" ist keine dort beschrieben Transformation. ÅñŧóñŜûŝî (Ð) 23:37, 30. Aug. 2019 (CEST)

Abschaffung der Buchfunktion / Leerung der Vorlage Gespeichertes:Buch[Quelltext bearbeiten]

Es gibt derzeit auf der englischen Wikipedia eine Diskussion über die Abschaffung der Buchfunktion. Diese könnte in einem ersten Schritt durch vollständige Leerung der Vorlage:Gespeichertes Buch realisiert werden. Hintergrund ist die Tatsache, dass diese Funktion im wesentlichen überhaupt nicht mehr funktioniert, sowie die offizielle Bekanntgabe das keinerlei Maßnahmen mehr ergriffen werden um die Funktionsfähigkeit in irgendeiner Weise wieder herzustellen.

Die Diskussion befindet auf der englischen Wikipedia befindet sich hier. Ich möchte euch hiermit einladen, an der Diskussion teilzunehmen, gerne auch auf dieser Seite der deutschen Wikipedia. Ich denke, es ist sinnvoll euch frühzeitig einzubinden, was ich hiermit getan habe. Viele Grüße --Dirk Hünniger (Diskussion) 12:17, 4. Sep. 2019 (CEST)

Hilfe bei JavaScript Benutzer:Boshomi/externalURLform.js gesucht[Quelltext bearbeiten]

Das Script Benutzer:Boshomi/externalURLform.js stammt zu 99% von Benutzer:TMg/weblinkChecker, einige kleinere Änderungen habe ich selbst geschafft, etwa eine zusätzlich Farbe für InternetArchiveBot-Änderungen. Derzeit würde mich interessieren wie man veraltete Parameter durch modernere Parameter ersetzt. Ein Kandidat dafür wäre der Parameter zugriff der gegen abruf ersetzt werden könnte. Ich wär für jede Hilfe dankbar. Ich würde dass in mein Script einbauen, das gründlich testen, und selstverständlich an TMg weitergeben, wenn es richtig funktioniert.

Ein weiterer Wunsch, aber das ist liegt für mich noch etwas weiter weg, wäre eine Anpassung an den neunen Quellcode-Editor.  Frohes Schaffen — Boshomi Defekte URLs - Hilfe mit!  00:35, 5. Sep. 2019 (CEST)

Zeilenumbruch und Fußnoten[Quelltext bearbeiten]

Die Software bricht bisher zwischen Text und Fußnoten um (siehe Screenshot), was offensichtlich unsinnig ist. Könnte man das nicht einfach softwareseitig verhindern (zum Beispiel durch Einfügen eines zero-width no-break space ähnl. wie beim %-Zeichen)? Grüße TRN 3.svg hugarheimur 11:58, 6. Sep. 2019 (CEST)

Würde tatsächlich funktionieren, aber dann müsste man zwischen den refs dieses Zeichen ebenfalls einfügen. (egal ob von Hand oder per Software) --Wurgl (Diskussion) 12:30, 6. Sep. 2019 (CEST)
Genau, ein solches Steuerzeichen gehört dann vor jedes einzelne ref, wie eben auch vor jedes einzelne Prozent-Zeichen. Die „Von-Hand“-Lösung ist ja gerade zu vermeiden – schließlich kann man ja nur schwer absehen, wo von der individuellen Bildschirmbreite abhängige Zeilenumbrüche stattfinden werden. Wenn es natürlich eine elegantere Software-Lösung gibt … Schöne Grüße TRN 3.svg hugarheimur (ohne (gültigen) Zeitstempel signierter Beitrag von Torana (Diskussion | Beiträge) 12:50, 6. Sep. 2019 (CEST))

Es wäre eine Browser-spezifische Besonderheit; klingt nach uraltem Opera oder IE.

  • Die Browser sind für den Umbruch verantwortlich.
  • Die allermeisten Browser, die ich kenne, und sämtliche modernen, machen in der bei uns vorliegenden Situation den Umbruch korrekt.

Das Einfügen irgendwelcher Zauberzeichen würde nichts ändern, und es gibt sie auch nicht.

  • Das Einzige, was bei den beschriebenen Browsern sicher und wirksam helfen würde, wäre der Rücksprung zum Beginn des letzten vorangehenden Wortes, und dort der Beginn eines nowrap span bis hinter das letzte ref. Das könnte aber damit kollidieren, dass die Phrase vor dem ref bereits in ein span eingeschlossen sein könnte, und es dann zu einer unerlaubten Verschachtelung von Elementbereichen käme.
  • Im Übrigen sind unsichtbare Steuerzeichen hochgefährlich, falls jemand per C&P diesen Text irgendwo anders hinkopiert und überhaupt nicht weiß, was dann mit diesen Zeichen weiter passiert, und noch nicht einmal weiß dass sie vorhanden wären. Sie gehören ausschließlich in bestimmte Texte asiatischer Schriften und haben ansonsten in modernen Texten nix mehr am Suchen.
  • Am %-Zeichen steht kein unsichtbares „zero-width no-break space“.

VG --PerfektesChaos 13:29, 19. Sep. 2019 (CEST)

Nur der Vollständigkeit wegen der zugehörige alte Phab-Eintrag dazu. --Wurgl (Diskussion) 15:41, 19. Sep. 2019 (CEST)
Can reproduce using Firefox (tested in Bristol 406 Zagato#Design). --nenntmichruhigip (Diskussion) 22:31, 19. Sep. 2019 (CEST)
Ändere mal die Breite des Fensters so, dass der Zeilenumbruch genau an der Stelle ist. Mit Firefox Quantum 60.8.0esr (64-Bit) / openSUSE Leap kann ich das wunderschön reproduzieren. --Wurgl (Diskussion) 09:32, 20. Sep. 2019 (CEST)
Falls wir uns gerade missverstehen: Der Kommentar von mir richtete sich an das Chaos, denn ich kann es ja auch reproduzieren. --nenntmichruhigip (Diskussion) 15:42, 20. Sep. 2019 (CEST)
Siehe auch Wikipedia:Technische Wünsche/Wunschparkplatz#Kein Zeilenumbruch vor Einzelnachweisen --nenntmichruhigip (Diskussion) 11:05, 26. Sep. 2019 (CEST)

Seltsamer "Link" "News:+" in Datenbanktabelle externallinks[Quelltext bearbeiten]

Siehe quarry:query/38919 … ich möchte die Bedeutung dieses Eintrags "News:" herausfinden. Die Ursache scheint irgendwie mit der Vorlage Internetquelle verknüpft zu sein. Wenn dort im Parameter Autor am Ende das Wort News steht, dann gibt es wohl einen Eintrag, also z.B. "BBC News". Aber was steckt da dahinter, warum diesen Eintrag? Zu den Newsgruppen, wie am Ende der Tabelle in Hilfe:Links#Bearbeitungshilfe beschrieben, wird es ja wohl kaum gehen.

So nebenbei: Könnte man nicht mal auf diese Newsgruppen verzichten? Vor 20+ Jahren hab ich dort ein paar mal was geschrieben und auch gelesen … lang ist es her! --Wurgl (Diskussion) 11:26, 12. Sep. 2019 (CEST)

news: scheint schon auszureichen, um einen Newsgruppen-Link zu erzeugen. Das ist in Vorlage:Internetquelle in Zeile 6 der Fall (Autorenangabe wird Doppelpunkt angefügt). Wo das Pluszeichen dann herkommt, kann ich nicht sicher sagen, vermutlich kodiert RemexHTML das folgende Leerzeichen, da er es als Teil einer URL erkannt hat. -- hgzh 12:11, 12. Sep. 2019 (CEST)
Hmm, sehr gut erforscht! Dann könnte dort ein <nowiki/> vor dem Doppelpunkt nicht schaden. --Wurgl (Diskussion) 12:18, 12. Sep. 2019 (CEST)
Das Problem scheint zu sein, dass das Leerzeichen als Entity kodiert ist (was nötig ist, weil die Parserfunktionen Leerzeichen am Anfang und Ende trimmen: news:+A vs. news: A. Ein nowiki scheint das Problem zu beheben. -- hgzh 12:21, 12. Sep. 2019 (CEST)
Diesen hier: Spezial:Diff/192193614 hab ich mal zu Fuß gefixt. Und jetzt warten bis die Hamster durch sind, es scheint noch 6 solche Spezialfälle zu geben. Bei der Vorlagensuche komm ich nur auf 183 Stück. --Wurgl (Diskussion) 12:57, 12. Sep. 2019 (CEST)
Gab noch einen Fall bei Rruga e Arbërit mit der Vorlage:YouTube. Hab dort auch ein nowiki reingemacht. --Wurgl (Diskussion) 22:39, 12. Sep. 2019 (CEST)

Tabelle innerhalb von ref-Tags[Quelltext bearbeiten]

Screenshot 2019-09-19-10-26-48-909 org.wikipedia.png

In Staatsgerichtshof für das Deutsche Reich (Einzelnachweis 2) und Publikation von Gerichtsentscheidungen (Einzelnachweis 9) ist innerhalb der Ref-Tags eine Tabelle. Bei Mouse-Over wird ein Kasten angezeigt, doch die Tabelle ragt über den rechten Rand des Kastens hinaus. Das finde ich nicht so prickelnd. In der mobilen Ansicht muss man auf die hochgestellte Referenz klicken, dann kommt ein Kasten und dort muss man dann sowohl waagerecht (weil zu schmal) als auch senkrecht scrollen, auch nicht so schön. Und die Wikipedia-App steigt komplett aus, die verschluckt die Definitions-Elemente der Tabelle und zeigt den Rest als Textwurst an, siehe Screenshot. Aus der Zeile für die Spaltenüberschriften
! RGZ !! Lammers/Simons !! Datum !! Register-<br />nummer !! Gegenstand wird "RGZLammers/SimonsDatumRegister-nummerGegenstand102, …". Gruselig.

Ist das jetzt eine Sache für die Technik oder für Portal:Recht?

Ob es weitere solche Fälle gibt, weiß ich nicht. Diese zwei hab ich jedenfalls gefunden. --Wurgl (Diskussion) 10:41, 19. Sep. 2019 (CEST)

Gaaaanz ehrlich haben Tabellen rein gar nichts in Belegangaben verloren, Das zumindest ist meine Meinung ich würde so etwas entweder in den Fließtext setzen oder es komplett entfernen. Was genau soll daran ein Beleg sein? --Liebe Grüße, Lómelinde Diskussion 11:04, 19. Sep. 2019 (CEST)
In Gewerkschaftliche Monatshefte ist bei den drei Referenzen "A 1", "A 2", "A 3" sowas ähnliches, eine Tabelle um eine Liste herum. Dort sieht man in der App nur einen Teil der Einträge (nur die ersten 12), aber wenigsten ist das keine Textwurst. Waagerecht scrollen muss man in der mobilen Ansicht auch nicht und der Rahmen passt. Also da geht das schon besser.
In Haltverbot ist Einzelnachweis 16 eine aufklappbare(!) Liste. Die wird wiederum kaputt angezeigt.
Mit dem Suchstring insource:/\<ref[^{<]*\{\|[^<]*\<\/ *ref/ finde ich einige wenige weitere, aber der Suchstring findet nicht alle. --Wurgl (Diskussion) 11:31, 19. Sep. 2019 (CEST)

Das gehört für den eingangs beschriebenen Fall nach Entscheidungen des Reichsgerichts in Zivilsachen als regulärer Abschnitt des Hauptteils.

  • ref sind nur für kurzen Fließtext vorgesehen, die auch als Pop-Up oder kleiner Tooltip darsgestellt werden könnten.
  • Block-Elemente, etwa Tabellen oder Blockzitate, haben in ref grundsätzlich nix am Suchen und das Layout und die Weiterverarbeitung sind auch nicht darauf eingestellt.
  • Im Übrigen ist es gaga, zweimal derart umfangreiches Datenmaterial identisch in zwei Artikeln parallel zu halten, zu korrigieren, zu vervollständigen und die Weblinks zu pflegen.

Informationen gehören in den Hauptteil der Artikel.

  • Es ist Angewohnheit mancher Wissenschaftler, bei denen regelmäßig zwei Drittel der Seite aus Fußnote besteht, und an eigentlichem Text oft nur noch eine Zeile pro Seite übrigbleibt, und bei denen alles Unwichtige und Nebensächliche als Kleingedrucktes den überwiegenden Text ausmacht.

LG --PerfektesChaos 13:18, 19. Sep. 2019 (CEST)

Wenn die Tabelle über den rechten Rand des Kastens ragt, dann liegt das Problem im Gadget „Fußnoten-Tooltip“. Das hat noch wesentlich größere Probleme, ist also kein echtes Thema. Dass die Tabelle in der mobilen Ansicht gescrollt werden muss, liegt an der Größe der Tabelle, nicht daran, dass sie in einem Einzelnachweis steckt. Dass die App damit gar nicht klarkommt, ist ein Fehler der App, der gemeldet werden sollte, dass er korrigiert werden kann.
Die ref-Syntax wird eben nicht nur für Einzelnachweise verwendet, sondern auch für Anmerkungen etc. und ist damit selbstverständlich für alles von einem kurzen Fließtext bis hin zu langen Auflistungen einschließlich Tabellen vorgesehen.
Ob in einem konkreten Fall eine Tabelle in einem Einzelnachweis sinnvoll ist, ist eine inhaltliche Frage, keine technische. Wenn ein Weiterverarbeiter damit nicht klarkommt, dann liegt das Problem beim Weiterverarbeiter. Wir schreiben hier aber erst einmal für normale Leser. Der hat mit einer Tabelle in einem Einzelnachweis nur wenig Probleme, weil er auf dem Desktop das Gadget nicht verwendet und mobil ohnehin scrollen muss. –Schnark 09:15, 20. Sep. 2019 (CEST)

Daten innerhalb API nicht konsistent[Quelltext bearbeiten]

Vorhin war der replag bei 2 Stunden, die engl. Wikipedia sogar bei 5 Stunden und wikidata bei 7 Stunden. Bin mir nicht sicher, ob die deutsche Wikipedia bei 2 oder 3 Stunden war. Jedenfalls gruselig lange. Grund war möglicherweise ein Crash eines Servers. https://phabricator.wikimedia.org/T233766

Ich hole mir für meine Vorlagen-Datenbank per API (→ Spielwiese) die Daten ab (eingeloggt als APPERbot). Da ist der Timestamp und die Revision dabei. In meinem Log-File steht folgende Zeile:

  • 2019-09-25 09:42:05 Process Page Id:365531 Rev Id:192573058 Timestamp:20190925093700 Title:Liste der konsularischen Vertretungen in Hamburg

Die Zeiten im Logfile sind UTC, also lokale Zeit ist 11:42 und das stimmt mit meiner Datenbank überein, dort steht auch 20190925093700 als Timestamp und 192573058 als Revision.

Dann zerleg ich den Text in einzelne Vorlagen und lege in meiner Datenbank div. Informationen ab, unter anderem das Byte-Offset ab welchem die Vorlage beginnt und deren Länge (inkl. der öffnenden und schließenden Klammern). Jetzt steht "lustigerweise" in meiner Datenbank jeweils das Offset der vorherigen Revision, so als hätte ich zwar Timestamp & Revision der aktuellen Version bekommen, aber den Text von der Version davor.

Die letzte Vorlage "All Coordinates" hab ich angeblich bei Offset 28321 / Länge 19 gefunden, das ist in der vorherigen Revision 190277374 genau der Text "{{All Coordinates}}", in der aktuellen aber ein Teil der ersten Zeile des Abschnitts Handelsvertretungen, nämlich das Fragment "burg]]) – Außenw" (16 Character, aber 19 Byte Länge).

Kann tatsächlich dieser replag dafür verantwortlich sein? Und welcher ist das? Derjenige Wert, den ich bei "meta=siteinfo&siprop=dbrepllag" vom API bekomme? Hier sind ja zwei Werte zu sehen: https://tools.wmflabs.org/replag/ --Wurgl (Diskussion) 16:14, 25. Sep. 2019 (CEST)

Ich hol mir jetzt per API auch den sha1-Wert, berechne aus dem Inhalt ebenfalls einen Hash und vergleiche die beiden und falls die beiden ungleich sind, dann murmle ich was in mein Logfile. So hab ich dann auch gleich einen Testfall zum Nachvollziehen, auch wenn das nur sporadisch auftritt. --Wurgl (Diskussion) 11:04, 27. Sep. 2019 (CEST)
Hab tatsächlich einen Fall gehabt, wo der Hash ein anderer war.
2019-10-03 11:18:30 Process Page Id:7645820 Rev Id:192815153 Timestamp:20191003111824 Title:MTV Eintracht Celle
2019-10-03 11:18:30 *** SHA1 does not match computed: da39a3ee5e6b4b0d3255bfef95601890afd80709 API: 628e76e06f3d101ee48121a03cfd10195f9dd784
Nur passt weder mein berechneter Hash noch der vom API gelieferte zu irgendeiner Version dieses Artikels. Und das kapier ich nun gar nicht. --Wurgl (Diskussion) 15:10, 3. Okt. 2019 (CEST)

Unerwünschtes Anpingen beim Revertieren[Quelltext bearbeiten]

Ein Benutzer hatte die Bearbeitung von jemand anders zurückgesetzt auf die letzte Version, die zufällig ich zuletzt bearbeitet hatte, und mit dem Bearbeitungskommentar meine Benutzerseite verlinkt. Das hat einen Ping bei mir ausgelöst, den ich als Belästigung empfinde, und das geht anderen vermutlich genauso. Auf Anfrage habe ich die Auskunft bekommen, es solle die offizielle Wiki-Software sein. Als ich das jedoch nochmals ausprobierte, hatte der Bearbeitungskommentar bei mir immer noch ganz anders ausgesehen. Ist das wirklich offiziell oder ein veraltetes Benutzerwerkzeug? Danke für Weiterhelfendes --Frau Nilsson (Diskussion) 06:14, 4. Okt. 2019 (CEST)

Die Verlinkung dürfte eine Funktion der Navigation-Popups sein. Der deutsche Reverttext stammt aus Benutzer:Zollernalb/vector.js. Wenn Dich Pings öfter nerven (das sollen sie nicht!), geh mal über Deine Spezial:Einstellungen#mw-prefsection-echo --MBq Disk 08:38, 4. Okt. 2019 (CEST)
Soweit ich weiß, wird der Bearbeitungskommentar auch bei einer normalen Rücksetzung automatisch erzeugt. siehe →MediaWiki:Revertpage = Änderungen von Beispielnutzer (Diskussion) auf die letzte Version von XYZ zurückgesetzt
Mich „erschrecken“ solche Pings auch manchmal. Der Sinn dahinter mag ja sein, dass ein Benutzer, der an einem Artikel zuletzt gearbeitet hatte informiert wird, dass hier nach seinem Edit eine Änderung erfolgte, die jemand anderes als nicht sinnvoll erachtet hat. Aber es kann ja auch vorkommen, dass man damit in einem Editwar landet und dann mehrfach angepingt würde, weil hin- und wieder zurück revertiert wird. Das wäre schon mehr als eine Belästigung. Du könntest es zwar abstellen, indem du in deinen Einstellungen generell die →Erwähnung abwählst, dann aber erhältst du keinerlei Benachrichtigungen mehr, wenn dich jemand gezielt rufen sollte. Ich denke es wäre sinnvoll das aufzusplitten.
  1. Erwähnung per Link auf einer Seite (mit Signatur des Auslösers)
  2. beabsichtigte Erwähnung in einem Bearbeitungskommentar (Zusammenfassungszeile)
  3. Erwähnung in einem automatisch erzeugten Bearbeitungskommentar (Zusammenfassungszeile) durch eine Wiederherstellung (Revertfunktion).  Info: Nachtrag: Entfällt, wenn die Systemnachricht MediaWiki:Revertpage geändert wird. (--Lómelinde 13:54, 4. Okt. 2019 (CEST))
Siehe auch →Erwähnung in der Zusammenfassungszeile
Zudem verwenden manche Benutzer das (Punkt 2) zusätzlich zu einem Link im Textbereich einer Diskussion (Punkt 1), was dann doppelte Pings erzeugt.Auch das empfinde ich als Störung, denn einmal Anbimmeln reicht wohl. Alles andere ist in meinen Augen unnötig aufdringlich. Hätte man also diese Optionen zur Auswahl, könnte man das Pingen über die Zusammenfassung für sich einzeln unterdrücken, je nachdem wie man es selbst gern haben möchte. Allerdings denke ich, dass es in dem Fall den du hier beschreibst aus einem Benutzerskript Benutzer:PDD/addEditAndRevertLinks.js (vermutlich die optionale Funktion Benutzer-Link in Revertinfo über var revlinkshowuser) stammt (siehe auch diese Suche), wie man das abstellen kann, weiß ich auch nicht, es sieht aus als wäre das durch den Verwender anwählbar, also doch nicht automatisch, wie in der „normalen“ Revertfunktion.
CC: Zollernalb --Liebe Grüße, Lómelinde Diskussion 09:13, 4. Okt. 2019 (CEST)

Seltsames Problem mit Prozent-Kodierung[Quelltext bearbeiten]

Das hat jetzt mit Wikipedia nicht unbedingt was zu tun. Beim Tool Wikipedia-Personensuche bekomm ich recht viele (80 Fälle im Monat Oktober, also in 4 Tagen) Aufrufe mit kaputt kodierten Umlauten bzw. Akzent-Buchstaben.

Beispiele:

Alle diese Urls kommen von Android (um genau zu sein: Android 5.1.1 und Android 7). Ich hab da jetzt so einen Würgherum gebaut und werfe rotzfrech die Sequenz "%83%c2" raus, es würde mich aber trotzdem interessieren, wo diese falsche Kodierung herkommt. Probiert hab ich selber auf einem Android 9 und Android 4-Gerät und zwar von der mobile Webseite zu dem Tool und von der Wikipedia-App zu dem Tool, aber ich habs nicht geschafft. Das funktioniert, so wie es soll. Keine fehlerhafte Prozent-Kodierung.

Leider ist kein Referrer im Log-File, daher weiß ich nicht wie das zustande kommt.

Hat da jemand eine Idee? Oder Erfahrung mit so einem Problem? --Wurgl (Diskussion) 11:54, 5. Okt. 2019 (CEST)

Übliches Problem; irgendwer encoded sich zweimal.
Schon tausendmal gesehen und gefixt; ein encoded string wird nochmals encoded, aber Unicode nicht beachtet, sondern als ANSI aufgefasst.
Beispiel:
Nicht unser Ding.
LG --PerfektesChaos 12:26, 5. Okt. 2019 (CEST)

Autoren-Statistik verlässlich?[Quelltext bearbeiten]

Hallo, ich hoffe, ich bin hier richtig: Die Autorenschaft des Artikels "Liste von Ländern nach durchschnittlicher Lebenserwartung" (57.675 Bytes) zeigt den Benutzer Kontrollstellekundl an Nr. 1 mit "24.122 Bytes: 50,6 %" – obwohl ich ihn in der Versionsgeschichte nur 5-mal finde (insg. +2.427 Bytes), erstmalig am 24. Aug. 2018‎ (+660 Bytes) und dann am 4. Okt. 2019 (+1.290 Bytes).

Also woher kommt die berechnete Autorenschaft mit "24.122 Bytes: 50,6 %" für Kontrollstellekundl?
Kann es sein, dass hier unnütze Entfernungen von Zeilenumbrüchen und Syntaxzeichen in den langen Tabellen (3 × 200 Länder) eine Hauptautorschaft bewirkt?
Meine Bearbeitungen umfassten bisher 9.907 Bytes: 20,8 %.

Das Tool "Statistik" aus den "Seiteninformationen" zeigt übrigens ein ganz anderes Bild zu mir an: 25 Bearbeitungen (25 %), 18.926 Bytes (27,3 %) – Kontrollstellekundl: 5 %. Gruß --Chiananda (Diskussion) 14:53, 5. Okt. 2019 (CEST)

Sieht bei Wikihistory etwas anders aus: https://tools.wmflabs.org/wikihistory/wh.php?wiki=dewiki&page_title=Liste+von+Ländern+nach+durchschnittlicher+Lebenserwartung --Wurgl (Diskussion) 15:14, 5. Okt. 2019 (CEST)
Um noch als weitere Variante mein Skript Benutzer:Schnark/js/artikel-statistik anzuführen:
  • Afus199620: 21828 Zeichen (36 %)
  • Chiananda: 18798 Zeichen (31 %)
  • Wiegels: 7650 Zeichen (13 %)
  • Kontrollstellekundl: 6079 Zeichen (10 %)
  • Aidone99: 4691 Zeichen (8 %)
  • 212.184.90.187: 907 Zeichen (2 %)
Schnark 11:08, 7. Okt. 2019 (CEST)

Datenbankfehler?[Quelltext bearbeiten]

https://de.wikipedia.org/w/index.php?title=Kategorie:Vestfoldberge&action=info

Warum werden hier 0 Unterkategorien angezeigt, wenn doch eine besteht? Das ist übrigens nicht der einzige Fall. In der Datenbank ist das übrigens auch nicht zu finden: SELECT cat_subcats FROM category WHERE cat_title = 'Vestfoldberge'; ergibt 0. Dafür werden dort aber 87 Seiten angezeigt, während nur 86 kategorisiert sind. Die Unterkategorie wird demnach wahrscheinlich als Seite erkannt. – Doc TaxonDisk.Wikiliebe?! 00:47, 23. Okt. 2019 (CEST)

gleiche Probleme[Quelltext bearbeiten]

{{erledigt|[[Benutzer:Thgoiter|тнояsтеn]] [[Benutzer Diskussion:Thgoiter|⇔]] 19:04, 18. Nov. 2019 (CET)}}

@Thgoiter: nicht mehr erledigt, es gibt schon wieder neue. – Doc TaxonDisk.Wikiliebe?! 12:39, 19. Nov. 2019 (CET)

BK-Meldung beim Seitenschutz für Admins möglich?[Quelltext bearbeiten]

Hallo zusammen, das wurde bestimmt schon mehrfach gefragt, ich habe allerdings nichts im Archiv dazu gefunden:

Wäre es möglich, eine BK-Meldung beim Seitenschutz für Admins anzeigen zu lassen, wie beim Sperren? Dort kommt es, wenn eine IP bzw. ein Benutzer bereits gesperrt ist, ich ihn aber gerade sperren will, ja der Hinweis im Sinne von "Dieser Benutzer ist bereits gesperrt: [Logbucheintrag]".

Wäre dies nicht auch beim Seitenschutz möglich? Das führt in der Praxis sonst häufig dazu, dass sich mehrere Seitenschütze nacheinander gegenseitig überschreiben (was in der Regel kein Problem ist, aber ja vielleicht technisch vermieden werden könnte?). Danke euch und Gruß, -- Toni (Diskussion) 19:24, 14. Nov. 2019 (CET)

Das wäre sicher möglich. Dafür gibt es bereits einen Feature Request von 2008 in Phabricator. 2015 hat ein Entwickler einen Patch dafür geschrieben, mit dem ein anderer Entwickler aber nicht einverstanden war. Seitdem hat sich nichts mehr getan. --Count Count (Diskussion) 21:12, 14. Nov. 2019 (CET)
Hi Count Count, danke dir für deine Rückmeldung! Kenne mich leider mit dem Phabricator nicht aus und die Verläufe dort sagen mir nicht so viel. Könnte man vielleicht nach all der Zeit nochmal einen Entwickler fragen, ob er sich das Problem anschaut? Gruß, -- Toni (Diskussion) 21:56, 14. Nov. 2019 (CET)
Ja klar, ich habe bei dem Bug Report mal nachgefragt. Es ist immer gut Interesse zu zeigen, dann wissen die Entwickler, die diesen Feature Request beobachten, dass es Leute gibt, denen das fehlt. Allzu viel Hoffnung würde ich mir trotzdem nicht machen, denn es gibt eine Unmenge an offenen Feature Requests im Phabricator.
Eine andere Möglichkeit wäre, das bei den technischen Wünschen einzubringen, wobei ich deren Priorisierungskriterien nicht kenne. --Count Count (Diskussion) 23:01, 14. Nov. 2019 (CET)
Danke dir! :-) Habe da jetzt auch mal eine Antwort hinterlassen, hoffe das war richtig so. Grüße, -- Toni (Diskussion) 17:39, 15. Nov. 2019 (CET)

gesichtete Versionen bei Vorlagen[Quelltext bearbeiten]

Hallo!

Mir erscheinen die Sichtungen bei Vorlagen wertlos. In Vorlage:CAParlbio sind momentan 4 Versionen ungesichtet, aber ob angemeldet oder nicht, man sieht das selbe. Das ist ein Unterschied zu gesichteten/ungesichteten Versionen bei Artikeln, wo der unangemeldete Leser die gesichtete Version sieht, der angemeldete hingegen die ungesichtete. Daher frag ich mich, ob das so gewollt ist, bereits gemeldet ist und sich irgendwann ändern wird oder hat das tatsächlich noch niemand benörgelt?

Zu dieser speziellen Vorlage: Die Links haben sich geändert, es hat vor der Änderung der IP nicht funktioniert, die IP kann also nix kaputt machen --Wurgl (Diskussion) 17:13, 17. Nov. 2019 (CET)

Die Darstellung für die Leser hatte wohl immer schon die aktuellste Version der eingebundenen Seiten berücksichtigt, egal ob diese gesichtet wären oder nicht.
  • Das System müsste sonst im Cache zwei Versionen des HTML-Rumpfes vorhalten; eine mit nur gesichteten Versionen von Vorlagen berücksichtigt, und diese expandiert, und dann eine zweite mit dem HTML, das sich ergibt, wenn die aktuellsten Versionen unabhängig vom Sichtungsstatus eingebunden würden.
Der Cache zeigt aber nur die tatsächlich angefragte Seite an, und zwar entweder basierend auf der in der Versionsgeschichte der angefragten Seite letzten oder zuletzt gesichteten Version, und hat zu dieser oldid eine Version im Cache.
  • Wenn sich jetzt an Vorlagen oder Dateien was ändert, dann merkt der Cache davon sichtungsmäßig nichts und würde auch keine Versionen anders aufbauen.
Es ist aber trotzdem nicht sinnlos: Die Vorlagenseite selbst zeigt eine Meldung, dass sie von irgendwem verändert worden wäre, und fragt nach der Sichtung der von unbekannter Seite vorgenommenen Veränderungen. Damit kann nicht leise und unauffällig Murks in die Programmierung infiltriert werden.
  • Mir ist so, als ob es früher™ mal auch auf dem Artikel einen Hinweis gegeben hätte, dass er ungesichtete Bilder oder Vorlagen einbinden würde; aber vielleicht war das irgendwann irgendwem zu nervig und es wurde rausgenommen.
LG --PerfektesChaos 17:36, 17. Nov. 2019 (CET)
@Wurgl, das stimmt so nicht ich hatte zwischenzeitlich die Vorlage umgebaut, so dass sie auch auf Seiten funktionierte die nicht der Artikelgegenstand waren, funktioniert hatte, nun aber ist sie seit den Änderungen des IP-Users wieder defekt, also nur direkt im WPartikel zu besagter Person verwendbar, ich mach aber nichts mehr daran, das ist mir zu doof, wenn meine Arbeit so verhuntzt wird. Und wenn das jetzt jemand sichtet dann wird es offiziell als korrekt gewertet, obwohl die Vorlage nicht mehr richtig funktioniert. --Liebe Grüße, Lómelinde Diskussion 17:56, 17. Nov. 2019 (CET)

VE „verbessert“ DOI[Quelltext bearbeiten]

Hallo, falls noch nicht bekannt: Der VisualEditor verschlimmbessert DOI-Formatierungen durch duplizierende Pipelinks inkl. span-code, z. B. in diesem Edit eines Dritten, vgl. meine Anfrage bei diesem. Gruß, --Wi-luc-ky (Diskussion) 17:56, 5. Dez. 2019 (CET)

Das Problem hatten wir gelegentlich schon. Es tritt immer dann auf, wenn der ändernde Benutzer den Citavi-Picker installiert hat.--Mabschaaf 18:05, 5. Dez. 2019 (CET)

Falsche Darstellung von mehreren Bilder in der WP-App[Quelltext bearbeiten]

Hallo zusammen, kannn jemand hier helfen? in der WP-App werden bilder falsch dargestellt, wenn eine bestimmte Vorlage genutzt wird. gruß --Z thomas Thomas 16:31, 10. Dez. 2019 (CET)

Hinweis auf ungesichtete Versionen in Beobachtungsliste[Quelltext bearbeiten]

Hallo! Wie ich auf Phabricator erfahren durfte, rührt die in Minerva leicht kaputte Warnungsbox zu Beginn der Beobachtungsliste, die mich über ungesichtete Versionen beobachteter Seiten informiert, von MediaWiki:Flaggedrevs-watched-pending her. Ein Vorschlag zur Reparatur (1) wäre, das für collapse zuständige JavaScript auch mobil explizit zu laden. Ist das so umsetzbar? Ich habe mir vorerst die Box per CSS mobil ganz ausblenden lassen. Gruß–XanonymusX (Diskussion) 00:45, 14. Dez. 2019 (CET)

Beziehung zwischen Datenbanktabelle revision und page[Quelltext bearbeiten]

Bisher bin ich davon ausgegangen, jeder Eintrag in der Tabelle "revision" hätte auch einen Eintrag in der Tabelle "page". Aber wie man bei dieser Quarry sehen kann, gibt es wohl 32701 Änderungen, aber kein zugehöriges Record zu einer Seite. Für einige dieser Einträge hab ich etwas mehr Details extrahiert: quarry:query/40741, es sind oft, aber nicht immer, irgendwelche Verschiebungen und offenbar hat das Ende August 2016 aufgehört. Weiß da jemand was? Waren das echte Aktionen oder ist das einfach Käse? --15:39, 19. Dez. 2019 (CET) (unvollständig signierter Beitrag von Wurgl (Diskussion | Beiträge) )

Zu deiner detaillierten Liste: nach ein paar Stichproben bei den Verschiebungen scheint es sich immer um Erstverschiebungen zu handeln, die anschließend mit Überschreiben einer Weiterleitung zurückverschoben wurden. -- hgzh 15:51, 19. Dez. 2019 (CET)
Von Kolja21: "Ansetzungsform in GND" das passt nicht so ganz in die Verschiebungen. Interessanterweise ist es das einzige Record mit dieser ID in rev_page?
hab bei einigen schon in der Tabelle logging geguckt … nix zu finden. --Wurgl (Diskussion) 16:02, 19. Dez. 2019 (CET)

Ist definitiv ein Bug, darf in einer sauberen Datenbank nicht vorkommen.

  • Produzierender Bug mag 2016 behoben worden sein.
  • Es gibt phab:T212428 mit gewissen Ähnlichkeiten, aber anderem Hintergrund.
  • Wir haben auch hier in der Werkstatt wohl eine oder mehrere Meldungen gehabt, dass zu bestimmten revisions aus der History nur Absturz dargestellt wurde, oder Diffpage damit fehlschlug. Kann auch FZW gewesen sein. Sind vermutlich alle auch Phab-gemeldet worden.
  • Müsste unter corrupted relations in neuer Phab-Task gemeldet werden; konnte keinen Vorgänger mit vergleichbarem Problem finden.
  • Wenn man ein Diff/1001/1002 macht, oder sich oldid=42 anzeigen lassen will, dann muss die revID auf ihre beheimatende pageID zeigen, etwa um den Seitennamen anzeigen zu können. Wenn da solche Klopse drin sind, muss das eigentlich schief gehen. Zumindest wenn bei der weiteren Abarbeitung mit der Tabelle "page" weitergearbeitet wird, und sinnvollerweise angenommen wird, dass diese revID dort ebenfalls eingetragen sind.
  • Kannst ja erstmal deine Waisenkinder an solchen Aufgaben testen.

LG --PerfektesChaos 16:37, 19. Dez. 2019 (CET)

Scheint phab:T102132 eher zu entsprechen. Die enWP ist auch betroffen, etwas stärker: quarry:query/40743 --Wurgl (Diskussion) 18:37, 19. Dez. 2019 (CET)
Ja, ist wohl auch die Ursache.
Sollte per globalem Serverskript überall bereinigt werden, aber da zieren die sich immer mächtig.
Das stellt jedem nachfolgenden Programmierer ein Bein, der in MediaWiki, Quarry oder sonstwo von der einen in die andere Tabelle wechselt und als gesichert annimmt, dass es dort auch einen solchen Eintrag gäbe. Ansonsten könnte man sich nämlich die Zweitversion in page komplett sparen.
Kannst ja mal dein Glück versuchen, aber Geschenke gibt es da nicht mal zu Weihnachten.
LG --PerfektesChaos 18:51, 19. Dez. 2019 (CET)

Problem mit Editieren durch Doppelklick[Quelltext bearbeiten]

Hallo! Schon seit langem nutze ich die Funktion, Seiten per Doppelklick zu editieren. Bislang konnte ich dann auf der Editierseite im Textfenster problemlos Wörter per Doppelklick markieren, wie in jedem Eingabefeld, hier hatte der Doppelklick darüber hinaus keine Wirkung. Jetzt auf einmal kommt dann aber die Frage, ob ich die Seite wirklich verlassen will. Was ist denn da los? Der Doppelklick als Linkersatz soll nur auf der Seite selbst aktiv sein, nicht auf der Editierseite... Betrifft FF 71. Gruß --MdE 01:19, 23. Dez. 2019 (CET)

Hallo MdE, hast Du etwas in Spezial:Einstellungen#mw-prefsection-editing, hier: „Seiten mit Doppelklick“ bearbeiten verändert? Gruß, --Wi-luc-ky (Diskussion) 01:23, 23. Dez. 2019 (CET)
@Wi-luc-ky: Nein, die Option war quasi schon immer bei mir aktiv. Gruß --MdE 01:32, 23. Dez. 2019 (CET)
Tut mir leid, MdE, da muss bitte noch jemand anderes helfen. Wie Du früher kann ich im Editfenster per Doppelklick markieren. Gruß, --Wi-luc-ky (Diskussion) 10:51, 23. Dez. 2019 (CET)
Ich habe es gerade nochmal überprüft: Wenn ich die o. g. Option abschalte, kann ich per Doppelklick im Editfenster markieren. Wenn die Option eingeschaltet ist, wird auch im Editfenster der Seitenaufruf „?action=edit“ ausgeführt :-( Gruß --MdE 14:15, 23. Dez. 2019 (CET)

Deutsch-Englisch-Mischmasch im Menu des Timeless-Skins[Quelltext bearbeiten]

Menü unter Timeless

Ich hoffe, ich bin hier an der richtigen Stelle. Seite einigen Tagen wird mir im "Seiten-Menü" des Skins Timeless ein Mischmasch aus Einträgen in Englisch und Deutsch angezeigt (siehe Screenshot). Da fehlen wohl noch die Übersetzungen einiger Menüpunkte (und ihrer Unterpunkte) ins Deutsche.

Sollte hier der falsche Ort sein, wäre ich für einen Hinweis auf die richtige Anlaufstelle dankbar. -- Danke und Gruß Icone chateau renaissance 02.svg Sir Gawain Disk. 12:02, 29. Dez. 2019 (CET))

Du bist schon an genau der richtigen Stelle.
Eins drüber gibt es das schon mal.
Muss halt jemand auseinanderdröseleln, was die Ursache ist; fehlende deutsche Übersetzungen können hiesige Mitarbeiter freihändig auf dem kleinen Dienstweg auf die Reise schicken; Lücken in der Software öffnen ein etwas größeres Fässchen und die Meldung sollte dann schon möglichst direkt für Programmierer aufzuarbeiten sein.
VG --PerfektesChaos 13:40, 29. Dez. 2019 (CET)

Template in de:Wikipedia for Europeana[Quelltext bearbeiten]

I have connected 160 000 objects/creators in Europeana to Wikidata see T240290. I think this can be useful also on de:Wikipedia to have an template using this information see T241677

Question: If you agree can you help me create it and translate the text see T241677 and english template EuropeanaEntity - Salgo60 (Diskussion) 11:37, 6. Jan. 2020 (CET)

@Salgo60:
Welcome & HNY.
First, it is great that you ask first and not start to implement something in an unknown environment, with local policies over a dozen years possibly violated.
Second, you are not exactly right in this maintenance area, but that is nothing you are supposed to know.
  • Please drop this issue again at our partner maintenance area, which is focussing on templates: WP:VWS.
  • The current maintenance area (WP:TWS) is also dealing with technical issues, but more things like browser, JavaScript gadgets, MediaWiki API queries, server access.
  • Just to get the right audience and archive.
  • One will execute implementation and documentation there according to your desires.
  • You might refer to this section.
Third, to give an assessment in advance:
  • Basically it is no problem to have a template which is wrapping an external link to anything.
  • However, we made the experience with academic registers that they are often not exciting. That will say: They do not tell anything more than a person with this name is registered at this number.
  • To insert such template into encyclopedic articles about a person we do expect that the external link is providing additional value: either biographic details (CV) or exhaustive publication list.
  • If the template is providing access to contents, e.g. book scan, photographs etc. it is most welcome. Metadata alone might be a problem; a painting might have a height of 60 centimetres and 40 centimetres width, but that is not challenging if no image is visible.
  • Basically we prefer to insert registration identifiers hard-coded into our article sources, since this is a reviewing wiki and every change of data needs review of experienced users. That is sufficiently preventing vandalism, which might happen easily and unobserved on Wikidata.
  • For the time being if there is no checked ID we can use Wikidata entry as fallback.
Greetings --PerfektesChaos 13:25, 6. Jan. 2020 (CET)
@PerfektesChaos: Thanks I will do. I see Europeana as museums Wikicommons were museums can upload material and also group them per creator. If the museums do a good work we in Wikipedia just need to link the Europeana creator id (agent same as Wikidata Qnumber e.g. Wikidata entity Q44007 same as "agent/base/60816") and not every museum PLUS the museums by uploading to Europeana easier get found. What I see is that the quality differ I guess per country and as we in Wikipedia tries to understand Wikidata museums/archives has just started this learning and I hope Wikipedia <-> Wikidata <-> Europeana can learn from each other to make cultural information easier to access see complains oin Europeana at en:Wikipedia link
Hardcoded id or Wikidata
The interesting thing with Europeana is that they have started to use Entities link (same as Wikidata Qnumber) and to get starting they used dbpedia as a source and dbpedia use Wikidata as a source i.e. we are always correct as they use same as Wikidata. I see this as a biproduct that the Wikiproject is moving in the right direction of quality, trust and technology.... If we find an error then the error is in Europeana that has matched an object to the wrong creator. I have written down my experience of this and advice Europeana to get better change management see GLAM/Newsletter/December 2019 - Europeana Entity P7704 - Salgo60 (Diskussion) 13:49, 6. Jan. 2020 (CET)

Nach Bearbeitung wird zum falschen Anker gesprungen[Quelltext bearbeiten]

Servus! Wenn man einen Artikel bearbeitet und dann speichert, springt Mediawiki ja immer auf diese Überschrift. Wenn man jedoch mehrere gleich benannte Überschriften hat, dann springt Mediawiki immer auf die erste Überschrift.

Beispiel: https://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese/Unterseite&oldid=195973450 Wenn ich hier bei "Test2" die Überschrift "Test123" bearbeite, die Seite speichere, dann springt Mediawiki anschließend auf die Überschrift "Test123" bei "Test1". Irgendwo verschluckt die Software also beim Anker das "_2" → "#Test123" statt das gerade bearbeitete "#Test123_2". (nicht signierter Beitrag von 37.251.226.214 (Diskussion) 14:34, 19. Jan. 2020 (CET))

Verhalten ist leider schon seit Jahr(zehnt)en so: phab:T2111. --тнояsтеn 17:12, 19. Jan. 2020 (CET)
Hui, fast 14 Jahre schon. Soweit bin ich bei meiner Fehlersuche nicht zurück gegangen. Also kann man wohl nicht auf eine zeitnahe Behebung hoffen. Noch eine Folgefrage: Wäre der Fehler grundsätzlich schwer zu korrigieren? Also würde es sich lohnen, wegen einem kleinen Problem kurz in die Mediawiki-Programmierung einzusteigen? --37.251.226.214 20:25, 19. Jan. 2020 (CET)
Extrem mühsam.
Das Grundproblem ist, dass HTML zum ersten Anker mit dieser id= springt.
MediaWiki vergibt deshalb bei gleichlautenden Überschriften eine interne Zählung; hängt also _2 _3 usw. oder so ähnlich dran, bis alle Überschriften eindeutige id= zugewiesen bekamen.
Damit kann MediaWiki in der momentanen Textversion die Verlinkungen zwischen Inhaltsverzeichnis und Überschriften sicherstellen.
Wenn jedoch ein Abschnitt bearbeitet wird, dann ist das section=42 und der weiß nicht welche interne Zählung seine Überschrift im Gesamt-Dokument erhielt.
Der Mechanismus, der aus Überschriften das Inhaltsverzeichnis generiert, befindet sich jedoch an einer völlig anderen Stelle als der Abspeicherungsvorgang; der verwendet seine jetzt generierte und vielleicht veränderte Abschnittsüberschrift zur Verlinkung.
In dem Moment, in dem die Abspeicherung vorgenommen wird, wird bereits die Verlinkung auf das spätere Gesamt-Dokument als URL gebildet; das spätere Gesamt-Dokument mit seiner möglicherweise veränderten internen Zählung ist aber noch nicht bekannt, weil der neue Text noch nicht Teil des Gesamt-Dokuments ist, und das wird erst generiert, nachdem die Textbearbeitung abgeschlossen wurde, die deshalb nicht wissen kann, wo zu diesem Zeitpunkt der ursprüngliche section=42 hingekommen ist und welche id= diesem jetzt zuzuordnen wäre. Wobei sogar andere Abschnitte parallel von anderen bearbeitet werden dürfen.
Die neue Zählung mit Inhaltsverzeichnis wird erst dadurch generiert, dass der abspeichernde Benutzer die URL aufruft, um die veränderte Seite angezeigt zu bekommen. Dabei verwendet die URL das, was sie weiß, nämlich die möglicherweise veränderte Abschnittsüberschrift. Dadurch, dass eine Anfrage-URL den Server erreicht, diese Seite anzuzeigen, wird der Prozess angestoßen, der die neue Seite generiert und das Inhaltsverzeichnis generiert. Erst danach wäre die aktuelle _2 _3 usw. bekannt.
Da wird sich deshalb auch keiner auf die Socken machen wollen.
LG --PerfektesChaos 22:35, 19. Jan. 2020 (CET) + 22:43, 19. Jan. 2020 (CET)

Großschreibung bei Suche[Quelltext bearbeiten]

Hallo, es scheint, daß in letzter Zeit kleingeschriebene Wörter bei der Suche nach Lemmata nicht mehr gefunden werden. Ging mir (der ich manchmal aus Bequemlichkeitsgründen klein schreibe) manchmal so. Konkret soeben: "kerstin hensel" führte mehrfach auf "Seite nicht vorhanden". "Kerstin Hensel" wurde gefunden.--217.70.135.60 06:51, 3. Feb. 2020 (CET)

Geht hier. Unangemeldet sowohl Desktop- als auch mobile Ansicht. Was verwendest du? --Wurgl (Diskussion) 10:55, 3. Feb. 2020 (CET)

PDF-Datei, Sortierung[Quelltext bearbeiten]

Verehrte Redaktion,

ich möchte auf der Seite https://de.wikipedia.org/wiki/Liste_der_ungerichteten_Funkfeuer_(NDBs) die aufgeführte Liste als PDF-Datei speichen/drucken in der Sortierung nach Frequenz. Wenn ich es versuche, wird immer wieder die Sortierung ignoriert und die Liste wird in der "Urform" nach Rufzeichen sortiert dargestellt.

Wie kann ich die Sortierung dauerhaft für den PDF-Ausdruck übernehmen?

mfg Wilfried (nicht signierter Beitrag von 2A04:4540:5F09:2300:38:BA20:B2D9:9EEB (Diskussion) 10:56, 4. Feb. 2020 (CET))

Welchen Browser benutzten sie? Wenn sie Firefox benutzen, ist es warscheinlich am einfachsten, Firefox Screenshots zu benutzen. (Die Drei Punkte in der Adressleiste -> Bildchirmfoto aufnehmen und dann dasa Bild auszudrucken. Wie das in anderen Browsern aussieht, weiß ich leider nicht. Victor Schmidt Was auf dem Herzen? 08:00, 6. Feb. 2020 (CET)

Falscher Link in Email-Benachrichtigung[Quelltext bearbeiten]

Hallo ich habe gerade eine Benachrichtigungsemail für die Seite Wikipedia:Administratoren/Probleme/Problem zwischen Siphonarius und AnnaS.aus I. erhalten. Der dort angegebene Link auf diese Seite ist jedoch falsch, da der Punkt am Ende dort nicht auftritt, er also auf die Seite Wikipedia:Administratoren/Probleme/Problem zwischen Siphonarius und AnnaS.aus I verweist. Die Difflinks sind wieder korrekt. Ist das jetzt nur ein Problem von meinem Thunderbird, oder kann man das vielleicht verhindern? --Doktor Wu (Diskussion) 13:25, 4. Feb. 2020 (CET)

Ohne die E-Mail gesehen zu haben, würde ich sagen, das ist ein Problem des entsprechenden E-Mail-Programms. Ich selber habe im Outlook oft das umgekehrte Problem, nämlich, dass der Punkt am Ende des Satzes noch als Teil des Links interpretiert wird, den ich angegeben habe. Mein Workaround ist dann immer ein Leerzeichen vor dem Punkt zu machen. Ich kann mir gut vorstellen, dass Thunderbird genau diese Problematik bekannt ist und sie deswegen Punkte am Ende von Links grundsätzlich entfernen. DestinyFound (Diskussion) 11:50, 16. Feb. 2020 (CET)
Das ist ein teuflisches Dilemma. Sowas in der Art passiert auch mit schließender Klammer am Ende. Lösungsmöglichkeit wäre: HTML-formatierte Mail … kann sein, dass der Benutzer dann auch die Mail im HTML-Format angucken muss, was bei so manchem Mail-Client ein Einfallstor für tolle Windows-Verbesserungsprogramme (Viren, Trojaner, etc.) sein könnte oder Prozentkodierung verwenden. --Wurgl (Diskussion) 12:11, 16. Feb. 2020 (CET)

keine Interwiki-Links im Editfenster[Quelltext bearbeiten]

Ich spioniere gerne mal bei meinen Edits in anderssprachigen Wikis um dort nach Referenzen für Unterschiede zu suchen. Solange ich den Artikel selbst anstarre, sehe ich die Interwikilinks, aber beim bearbeiten der Seite ist diese Liste leer (egal ob Quelltext- oder Visual Editor). Kann man die nicht auch beim Bearbeiten anzeigen? --Wurgl (Diskussion) 11:38, 16. Feb. 2020 (CET)

Hier der Phabricator-Eintrag dazu. Ist sogar noch offen, aber keine hohe Prio. Man sieht die Interwiki-Links immerhin, wenn man sich die Vorschau anzeigen lässt. DestinyFound (Diskussion) 11:46, 16. Feb. 2020 (CET)
Im neuen Wikitext-Modus gibt es die Interwikilinks auch im Bearbeitungsfenster.–XanonymusX (Diskussion) 11:57, 16. Feb. 2020 (CET)

Generell gilt seit immer:

  • In der Diff-Ansicht wird ausschließlich der Unterschied zwischen dem alten und dem neuen Quelltext dargestellt.
    • Heißt: Beim Vergleich gibt es auch keine Kategorien und Vorlageneinbindungen und Verknüpfungen mit Wikidata und was auch immer.
    • Was der Quelltext bedeuten soll wird nicht untersucht.
    • Das hat Performance-Gründe, und wird wohl auch niemand anfassen wollen.
  • Das gilt genauso für die Erstbearbeitung &action=edit wenn per Benutzereinstellung auf nacktes kurzes Anzeigen konfiguriert.
  • Im Vorschau-Modus erfolgt ein komplettes Rendering des neuen Textes. Hier werden neue Kategorien den bisherigen hinzugefügt, die jetzt aktuellen Vorlageneinbindungen usw. angezeigt, und auch die Interlanguages sind die bisherigen zuzüglich solcher die durch geänderten Quelltext hinzugekommen sein werden gehättet gesollt.

LG --PerfektesChaos 13:34, 16. Feb. 2020 (CET)

"Intelligente" Menues?[Quelltext bearbeiten]

Hallo, viellleicht wisst ihr das (auf FZW erfolglos): ich bereite gerade eine Umfrage Wikipedia:Umfragen/Zukunft des Sichtens vor und will die mit einer gründlichen Analyse vorbereiten. In dem Zusammenhang hab ich die Frage, ob man vom linken Seitenmenue "intelligent" verlinken kann. Also zB. ein Menuepunkt "Sichten", der für Sichter und Nichtsichter jeweils eine andere Seite aufruft (also abhängig von den Benutzergruppen). Das gäbe die Möglichkeit, Nichtsichtern das einfach zu erklären - Sichtern die Statistiken und Werkzeuge anzuzeigen. Danke. --Brainswiffer (Disk) SICHTET! 12:54, 2. Mär. 2020 (CET)

Andreas M. Fleckner[Quelltext bearbeiten]

Guten Tag,

Andreas M. Fleckner kann vermutlich nicht gesichtet werden. Könntet ihr den Artikel sichten. Vielen Dank im Voraus. --Dr Lol (Diskussion) 13:30, 3. Mär. 2020 (CET)

Wie kommst du darauf? Von allen Anzeigen her könnte ich das - würde es aber ungern. Dem Artikel fehlen vor allem Quellen. Wenn er vom MPI weg ist, wird die einzige auch bald nur noch Archiv sein? --Brainswiffer (Disk) SICHTET! 14:05, 3. Mär. 2020 (CET)
Hallo Dr Lol, derzeit relevanzstiftend nach WP:RK#Wissenschaftler wäre (mangels ausreichender Zahl selbständiger Publikationen nach WP:RK#Autoren, s. DNB) die Professur an HU Berlin, für die aber gerade auf https://www.hu-berlin.de/de nichts zu finden ist. Gruß, --Wi-luc-ky (Diskussion) 15:02, 3. Mär. 2020 (CET)
Die Nachweise habe ich ergänzt.https://agnes.hu-berlin.de/lupo/rds?state=wsearchv&search=1&subdir=veranstaltung&P.vx=mittel&personal.nachname=Fleckner&veranstaltung.semester=20201&P_start=0&P_anzahl=10&P.sort=&_form=display (nicht signierter Beitrag von Dr Lol (Diskussion | Beiträge) 15:12, 3. Mär. 2020 (CET))
Der wäre besser https://agnes.hu-berlin.de/lupo/rds%3Bjsessionid=32066B4F06B4E3D8351127DC4C1D56ED.qisappl8_root?state=verpublish&status=init&vmfile=no&moduleCall=webInfo&publishConfFile=webInfoPerson&publishSubDir=personal&keep=y&purge=y&personal.pid=29408 er ist aber noch nicht zugeordnet. --Brainswiffer (Disk) SICHTET! 15:26, 3. Mär. 2020 (CET)
Habe etwas ergänzt, kann aber auch nicht sichten, da der Button Sichten unten links nach Klick bei Übertragung… hängenbleibt. Wer weiß Rat? Gruß, --Wi-luc-ky (Diskussion) 17:53, 3. Mär. 2020 (CET)
PS: Ich konnte meine Änderungen nur ohne Haken bei Sichten speichern, da mit Haken ein fataler Ausnahmefehler angezeigt wurde (habe mir leider die Nr. nicht notiert). Info: Der Art. wurde zweimal verschoben. --Wi-luc-ky (Diskussion) 18:22, 3. Mär. 2020 (CET)

Ein Klick auf Sichten führt zu einer internen Fehlermeldung beim API-Aufruf, die aber nicht angezeigt wird:

The given Title (Andreas M. Fleckner) does not belong to page ID 11184614 but actually belongs to 11184613

Das sollte auf Phabricator gemeldet werden. Ich werde das später oder morgen erledigen, falls mir niemand zuvorkommt. --Count Count (Diskussion) 18:06, 3. Mär. 2020 (CET)

Au weia, das scheint schlimmer und betrifft mehr @Count Count:. --Brainswiffer (Disk) SICHTET! 18:12, 3. Mär. 2020 (CET)


(Erst)Sichten scheint komplett durcheinander[Quelltext bearbeiten]

Im Moment ist ein Artikel mit über 4000 Tagen Spitzenreiter in der Liste der zu sichtenden Artikel. Da geht aber was durcheinander? In der Arbeitsliste wird Bewegung für Demokratie angezeigt (was noch nie gesichtet wurde und üblicherweise nicht in der Liste erscheint - im Moment nicht gesichtet werden kann), ebenso bei "Versionen". Wenn man nun Sichten wählt, wird der tschechischsprachige Artikel als Weiterleitung dorthin angezeigt, der aber als gesichtet geführt wird und den man folglich gar nicht sichten kann. Sind die da mit den Page-ID durcheinandergekommen? --Brainswiffer (Disk) SICHTET! 08:27, 5. Mär. 2020 (CET)

Update: heute erscheint auch Georg Pahl als 2. Artikel mit über 1000 Tagen in der Liste. diese WL wurde ebenfalls noch nie gesichtet. Bei der Dauer hätte der auch gestern da sein müssen, war er aber nicht. Anders als früher (ich hatte das für meine Befragung geprüft) basteln die wohl dran, dass nun auch die erstzusichtenden Artikel in der Arbeitsliste erscheinen? Das wäre keine schlechte Idee - wenn es denn funktionieren würde. Durchgängig ist das aber auch nicht, Bozena Anna Badura wartet 44 Tage auf Erstsichtung und müsste in der Arbeitsliste Platz 3 haben, ist da aber nicht. --Brainswiffer (Disk) SICHTET! 08:35, 5. Mär. 2020 (CET)

Und wer bastelt da dran? Bei WMF rührt sich in die Richtung schon lange nichts mehr, und WMDE hat wohl aktuell auch keine Kapazitäten dafür, außer wir bringen entsprechende Anliegen bei den nächsten Technischen Wünschen höher.—XanonymusX (Diskussion) 09:06, 5. Mär. 2020 (CET)
Das ist bei Informatik oft so: etwas ist plötzlich anders und keiner will's gewesen sein :-) Dass die am nicht funktionerenden Erstsichten basteln, hoffe ich aber doch stark, da gibts zumindest eine Ticketnummer. Und das sieht wie ein Kollateralschaden aus. --Brainswiffer (Disk) SICHTET! 09:28, 5. Mär. 2020 (CET)
Also, auf Phabricator ist das ganze FlaggedRevs-Projekt schon lange ohne aktiven Betreuer. Das ist natürlich bekannt, finden alle blöd, aber kümmert sich doch keiner drum (betrifft ja enWP nicht). Ab und zu könnte sich etwas (quasi als Kollateralschaden) zum Besseren ändern, aber eher nicht gezielt; und je länger die FlaggedRevs nicht betreut werden, desto größer ist die Chance, dass die Erweiterung irgendwann mit neuen MediaWiki-Versionen überhaupt nicht mehr funktioniert und schlicht abgestellt werden muss. Das würde die eh schon prekären Wartungsprozesse in diesem Projekt ganz schön durcheinanderbringen … –XanonymusX (Diskussion) 12:49, 5. Mär. 2020 (CET)
Auch die enWP verwendet die Flagged-Revisions-Erweiterung, allerdings ist sie dort standardmäßig nicht aktiv und wird nur für manche, öfter vandalierte Seiten eingeschaltet (siehe en:WP:Pending changes und en:WP:Flagged revisions). --Count Count (Diskussion) 12:58, 5. Mär. 2020 (CET)
Mal ne dumme Frage: Bei Wikimedia gibt es angeblich viele Angestellte, auch für Programmierung. Gibt es da eigentlich einen verantwortlichen Koordinator, der die Ressourcen kennt und gezielt ansprechen kann? --Brainswiffer (Disk) SICHTET! 13:09, 5. Mär. 2020 (CET)
Das wird alles in phab:T185664 besprochen; hat sogar hohe Priorität, aber das war’s auch schon. Ich hatte kürzlich mit unserer Ansprechpartnerin bei WMDE über das Problem gesprochen, aber wie gesagt, keine Kapazitäten.–XanonymusX (Diskussion) 14:07, 5. Mär. 2020 (CET)
Danke für die Info. Ich hab mich da mal eingeschaltet. Denn hier gehts nicht um eine Weiterentwicklung, die sich anstellen muss, sondern um eine möglichst schnelle Reparatur von etwas, was offenbar immer mehr kaputtgeht ;/) --Brainswiffer (Disk) SICHTET! 14:21, 5. Mär. 2020 (CET)

Frage zur load.css bezgl unterstrichener links in erzeugten pdfs[Quelltext bearbeiten]

Hi,

Ich lese Wikipedia Artikel gerne im pdf format. Dazu drucke ich die Artikel mit einem pdf printer.. Foxit, nitro oder Microsoft in Firefox. Die im Dezember 2019 gedruckten Artikel enthalten keine unterstrichenen links, die im Februar 2020 gedruckten pdfs schon. Ich empfinde die unterstriche als störend und ich vermute, die Datei load.css ist dafür verantwortlich. Gibt es die Möglichkeit die unterstreichungen zu unterbinden? Zumal die unterstriche im Browser auch nicht zu sehen sind. Sie erscheinen erst im pdf.

Danke im voraus für eure hilfe Burkhard Kühlert, detmold (nicht signierter Beitrag von Bkuehlert (Diskussion | Beiträge) 21:10, 6. Mär. 2020 (CET))

Fehler bei Bearbeitungskonflikten[Quelltext bearbeiten]

Im neuen Tool, um Bearbeitungskonflikte zu lösen, scheint ein Fehler zu stecken. Nachdem ein Bearbeitungskonflikt entstanden war, werden bestimmte Zeichen in HTML-Code umgewandelt und so (Code, nicht Zeichen) im Wikipedia-Artikel angezeigt. Dies betrifft zum Beispiel <, > und ", wie sie etwa bei <references /> und <br /> verwendet werden. Im Folgenden ist dann eine händische Korrektur nötig.

Beispiele:

Ich hoffe, der Fehler kann schnellstmöglich behoben werden.--Asperatus (Diskussion) 10:20, 12. Apr. 2020 (CEST)

Noch ein Beispiel: Franz Ferdinand von Österreich-Este (difflink). --Wurgl (Diskussion) 10:46, 12. Apr. 2020 (CEST)
Das Tool ist in den Einstellungen abschaltbar. Bitte jetzt nicht schlagen wegen dieses Hinweises. --Prüm  11:03, 12. Apr. 2020 (CEST)
P.S.: Ich weiß jetzt nicht, ob das die richtige Stelle zum Reporten ist, aber der Code ist Bestandteil von Mediawiki, siehe mw:Help:Two Column Edit Conflict View und die dortige Diskussionsseite. --Prüm  11:10, 12. Apr. 2020 (CEST)
Mit der Suche nach insource:/&lt;ref/ gibt es noch ein paar Treffer (9 momentan).
Und ja, man kann das abdrehen (ich hab das schon länger weggemacht). Wer schreibt diese an: 5.860 Benutzer testen diese Funktion?(das war eine fiktive Frage) --Wurgl (Diskussion) 11:45, 12. Apr. 2020 (CEST)
Hilfreich wäre zumindest, wenn alle mit diesem neuen Werkzeug gelösten Editkonflikte eine Markierung erhalten würden. Das ist doch bei anderen vergleichsweise neuen Edit-Tools wie dem Visual Editor auch üblich.--Mabschaaf 11:48, 12. Apr. 2020 (CEST)
Ach da kam das her, hatte ich vorhin auch →hier vermutlich muss ich da noch mehr nacharbeiten, ich hatte nur die <> repariert. Aber der Diff zeigt da war noch mehr. --Liebe Grüße, Lómelinde Diskussion 11:52, 12. Apr. 2020 (CEST)
Mir ist das gestern auch passiert, bei Collonil. Da dachte ich, jemand hat das absichtlich zerschossen. - Aber bitte: wie kann ich das abschalten? Schönen ostermontag noch allerseits. 44pinguine 09:41, 13. Apr. 2020 (CEST)
Spezial:Einstellungen#mw-prefsection-editing und dann bei „Zwei-Spalten-Bearbeitungskonflikt-Oberfläche aktivieren, um Bearbeitungskonflikte zu lösen“ den Haken raus. Gruß, -- hgzh 11:54, 13. Apr. 2020 (CEST)
Warum hat der Account Benutzer:WikiHistory-ToolAccount (wird nur für das Tool WikiHistory verwendet, daher 0 Beiträge) den Eintrag "Zwei-Spalten-…" nicht, der Account Wurgl aber schon? Hat das was mit Berechtigungen zu tun? --12:10, 13. Apr. 2020 (CEST) (nicht signierter Beitrag von Wurgl (Diskussion | Beiträge) )

Datenbankinkonsistenz?[Quelltext bearbeiten]

Der Benutzer Benutzer:Beson wurde von meinem Bot für die Vergabe des passiven Sichterrechts vorgeschlagen. Drahreg01 ist aufgefallen, dass da etwas nicht stimmt mit der Bearbeitungszahl. So hat der Benutzer aktuell nur 41 Bearbeitungen insgesamt, mein Werkzeug sagt aber, dass er 469 Bearbeitungen im ANR hat.

Eine schnelle Quarry-Abfrage zeigt, dass das Werkzeug diese Zahl korrekt aus der flaggedrevs_promote-Tabelle entnommen hat. Nur stehen dort komplett unplausible Werte für den Benutzer, wie die 469 ANR-Bearbeitungen. Der Benutzer hat keine gelöschten Bearbeitungen.

Habt ihr irgendwelche Ideen? --Count Count (Diskussion) 18:34, 19. Apr. 2020 (CEST)

Diese Seite Archivieren[Quelltext bearbeiten]

Nicht wirklich eine Frage, aber hat schonmal jemand darüber nachgedacht, diese überlange seite zu Archivieren? Ich habe per Suchfunktion gesehen, dass bereits Archive existieren, deswegen frage ich. Victor Schmidt Was auf dem Herzen? 18:47, 25. Apr. 2020 (CEST)

ja.–XanonymusX (Diskussion) 19:54, 25. Apr. 2020 (CEST)

Diskussionsbeitrag über Handyversion fehlerhaft[Quelltext bearbeiten]

Hallo! Wenn ich über mein Handy etwas in eine Diskussion hinzufügen will, landet es oft leider an einem anderen Punkt in der Diskussionsseite. [7] Siehe z.B da. Der Beitrag wird also an der falschen Stelle hinzugefügt. Das habe ich korrigiert indem ich das auf der alten Art und Weise über den Wikitext gemacht habe. Grüße --Wolsberg (Diskussion) 23:44, 1. Mai 2020 (CEST)

IP-Benutzern danken[Quelltext bearbeiten]

Leider wurde 2015 der Technische Wunsch – Dankesfunktion für IPs (aus IMHO nicht nachvollziehbaren Gründen) nicht erfüllt. Meines Erachtens bietet fr:MediaWiki:Gadget-RevertDiff.js diese Funktion, also mit wenigen Klicks einem IP-Benutzer für eine Bearbeitung danken zu können, auch wenn es noch gewisses Optimierungspotential gäbe. Mag jemand das Script für die de-WP anpassen? Um die auf die IP-Diskussionsseite gepostete Vorlage würde ich mich kümmern? --Leyo 00:05, 3. Mai 2020 (CEST)

Nicht abgeschlossene Kommentare in Referenzen[Quelltext bearbeiten]

In Wachsblumen (Hoya) ist mir das aufgefallen, auf Beta hab ich das in einem kleinen Beispiel demonstriert. References and comment.

Wenn innerhalb von <ref></ref> ein HTML-Kommentar <!-- begonnen, aber nicht abgeschlossen wird, dann sind zwar im Fließtext die Referenzen brav mit [123] markiert und auch anklickbar, aber im entsprechenden <references />-Abschnitt fehlen sie. Beim Artikel Wachsblumen (Hoya) war das ganz extrem, nur 34 der 76 Einzelnachweise waren im Artikel aufgeführt.

Ist das bereits bekannt, oder neuer Phab-Eintrag? --Wurgl (Diskussion) 10:02, 8. Mai 2020 (CEST)

Es ist generell bereits bekannt.
Die Syntax ist mehrdeutig, und es ist pure Glückssache, wie welche Version des Parsers dies interpretiert.
Die ref-Extension geht ohnehin eigene Wege und interpretiert den Wikitext, den sie abbekommt, nur begrenzt und als abgeschlossene Einheit.
Je nachdem ob eine Parserversion zu einem anhängigen <ref> nun zu allererst das schließende </ref> sucht oder aber nach einem anhängigen geöffneten Kommentar das Ende des Kommentars sucht passiert mal dies, mal jenes.
Das ist der Grund, warum seit drei Jahren der Linter läuft und fehlerhafte Verschachtelungen aufzuspüren versucht. Muss man halt eindeutig notieren.
Linter befasst sich allerdings mit inhaltlichen Elementen, also benannten Tags; eher wäre fehlerhaftes Nesting mit Kommentaren ein neues Feld für Linter.
Das prinzipielle Problem ist jedoch uralt und keine Neuigkeit.
LG --PerfektesChaos 12:14, 8. Mai 2020 (CEST)
Die Fehler kommen bei meiner Liste raus, zwar nicht unbedingt als Verschachtelungsfehler, aber ich finde die. Muss ja nicht doppelt gemoppelt werden. War nur die Frage, ob schon Phab-Eintrag oder nicht. Bzw, jetzt offenbar: Einfach ignorieren. --Wurgl (Diskussion) 13:52, 8. Mai 2020 (CEST)

Kein Suchvorschlag bei neu erstelltem Artikel[Quelltext bearbeiten]

Ich habe vor rund drei Wochen die Seite Feel Good Inc. erstellt, allerdings taucht diese nicht als Suchvorschlag auf, wenn man den Begriff in die Suchleiste eingeben will. Ich weiß, es dauert normalerweise ein wenig, bis ein neuer Artikel bei der Suche vorgeschlagen wird, aber nach drei Wochen sollte das doch eigentlich erledigt sein, oder nicht? Kann da ein technisches Problem vorliegen oder dauert das wirklich so lange?--DJNevage (Diskussion) 02:18, 24. Mai 2020 (CEST)

Auf- und Ab-Zappeln der Links der 2. Zeile[Quelltext bearbeiten]

Hallo Freunde von der Technik

Ich habe in meinem Rechner: Windows 8.1 und FireFox 76.0.1 (64-Bit).

Wenn ich die Wikipedia öffne, taucht bei mir jedes mal die
Gruppe von Links:
[Lesen] [Quelltext bearbeiten] [Abschnitt hinzufügen] und [Versionsgeschichte]) einschließlich des Such-Eingabe-Feldes,
zuerst 1 Zeile unterhalb der endgültigen Position auf, und
springt nach einigen Sekunden in die endgültige Position, das ist: die selbe Zeile, in welcher links [Artikel] und [Diskussion] sind.
Das ist zwar etwas irritierend, aber daran habe ich mich gewöhnt.

Als ich in dem Artikel Sarah Bernhardt zur Diskussions-Seite wechselte, erlebte ich ein endloses auf und ab Zappeln der genannten Gruppe von Links: immer wieder zwischen diesen beiden beschriebenen Stellen/Zeilen/Positionen hin und her. Das Gleiche geschah, unter den gleichen Umständen, aber auch beim Artikel Fedora (Filzhut). Es scheint also nicht an einem bestimmten Artikel zu liegen.

Dabei war das Auftreten dieses Zappelns von 3 Umständen abhängig:
A: dem Zoom-Faktor des Browsers,
B: ob ich bei der Wikipedia angemeldet war oder nicht und
C: ob Artikel-Seite, oder Diskussions-Seite.

Nachfolgend eine kleine Art Tabelle (ohne Trenn-Striche):

Nicht angemeldet:
Bei einer Artikel-Seite beim Zoom-Faktor: 133 %.
Bei einer Diskussions-Seite beim Zoom-Faktor: 120 %.

Angemeldet:
Bei einer Artikel-Seite beim Zoom-Faktor: keinem.
Bei einer Diskussions-Seite beim Zoom-Faktor: 120 %

Ich bitte um ein Ping. -- Steue (Diskussion) 01:57, 31. Mai 2020 (CEST)

Zur Technik kann ich nichts sagen, möchte aber WP:?#Versionsgeschichte nicht abrufbar und WP:?#Oben die Leiste spinnt verlinken und ich vermute, dass der Zoom-Faktor (oder Browser?) nur mittelbaren Einfluß hat. Es hängt nach meiner Wahrnehmung, davon ab, inwieweit die Menüpunkte in die Zeile passen. Wenn ich mich unter einem neuen Account anmelde, muss ich (um das Gewackel zu provozieren) das Fenster etwas breiter machen, als wenn ich unangemeldet bin, weil ich angemeldet noch den Stern fürs Beobachten in der Zeile habe. --Diwas (Diskussion) 04:20, 31. Mai 2020 (CEST)
Vermutlich Task 71729. --Diwas (Diskussion) 04:25, 31. Mai 2020 (CEST)


@Steue:, nach BK

+1 Kann dieses Verhalten bestätigen, wollte grade selbst eine Meldung für die Freunde aus der Technik hier hinterlassen. Beobachte es heute zum ersten Mal.
Die genannte Zeile springt um Sekundentakt auf und ab, die Gruppe der Reiter fahren hin und wieder zurück. Zoomfaktor 133%, nicht angemeldet, auf beliebiger Artikelseite. Man hat auch keine Chance, irgend einen Link davon anzuklicken. Bei einer Seite mit ungesichteten Änderungen tritt der Effekt bei 100% Zoomfaktor auf. Ein Wechsel des Zoomfaktors beendet den Spuk. Es scheint die Gesamtbreite der Links im Verhältnis zum zur Verfügung stehenden Platz eine Rolle zu spielen. Ich tippe mal darauf, daß sich die Logik nicht darauf festlegen kann, ob das Menu nun eingeklappt oder ausgeklappt bleiben soll. Gab es in den letzten Tagen Änderungen an diesem Teil der Wiki-Software?


Ergänze die Auftrittsbedingungen also um einen Punkt:


D: Ob es ungesichtete Änderungen auf der Seite gibt.


System: antiX 17.4.1 auf Athlon XP 1,4 GHz, Auflösung: 96dpi, Browser: Firefox_68.8.0_esr_(32bit)


Grüße --88.78.83.66 04:43, 31. Mai 2020 (CEST)
Herzlichen Dank, Diwas und 88.78.83.66
Steue (Diskussion) 04:57, 31. Mai 2020 (CEST)

(Schon wieder BK) Diwas, Du hast da wohl Recht mit Deiner Vermutung: Exakt so wie unter Task 71729 als Bild verlinkt sieht das auch hier aus.

Problem ist also schon bekannt. --88.78.83.66 05:02, 31. Mai 2020 (CEST)

Fehler auf dem Smartphone[Quelltext bearbeiten]

Was zur Hölle? Warum spinnt die Leiste oben so rum? Aktualisieren bringt übrigens nichts. Das bleibt so. Ist jetzt nicht bei jeder Seite, aber irritiert mich trotzdem.

Da muss mal ein Techniker drüber schauen. --Sebastian 31 (Diskussion) 11:42, 2. Jun. 2020 (CEST)

Siehe Abschnitt genau hier drüber. --Magnus (Diskussion) 11:48, 2. Jun. 2020 (CEST)

Beobachtungsliste bearbeiten[Quelltext bearbeiten]

Nach längerer Zeit habe ich mich mal aufgerafft auf der Beobachtungsliste was rauszuwerfen und dann sagt mir sie Seite das:

[b3d29d17-79de-41fb-8803-ace6f1320bfb] 2020-06-08 20:27:45: Fataler Ausnahmefehler des Typs „WMFTimeoutException“

Fatal, ja kann man sagen, da das drei Tage hintereinander kommt. Liegts an der Anzahl der "Beobachteten Seiten"? Gruß --Graphikus (Diskussion) 22:50, 8. Jun. 2020 (CEST)

Siehe Wikipedia:Technik/Archiv/2019#Spezial:Beobachtungsliste_bearbeiten--Masegand (Diskussion) 22:55, 8. Jun. 2020 (CEST)
vielen Dank, schönen Abend noch --Graphikus (Diskussion) 23:00, 8. Jun. 2020 (CEST)

Zeilenabstand einer Vorlage nach einer Aufzählung[Quelltext bearbeiten]

Es gibt (unter MonoBook im Firefox auf PC) zu kleine Zeilenabstände von Vorlagen, wenn sie direkt oder nach einer Leerzeile unter einer Aufzählung stehen:

  • eine Aufzählung
  • zweiter Punkt

Sieht rangequetscht aus (vergleiche Beispiel), das betrifft auch das Inhaltsverzeichnis, wenn die Artikeleinleitung mit einer Aufzählung endet (altes Beispiel).
Lässt sich dahingehend etwas an der Standard-CSS nachjustieren? Gruß --Chiananda (Diskussion) 17:52, 22. Jun. 2020 (CEST)

Hier ein ähnlicher Abstandsfehler in der Darstellung in der mobilen Ansicht (MonoBook im Firefox auf PC):
  • Drache (BKS) enthält absichtlich eine Leerzeile vor dem 5. Eintrag (Lokomotive), um einen kleinen Abstand zu erzeugen.
  • In der mobilen Ansicht steht die Lokomotive näher am vorhergehenden Eintrag dran.
Gruß --Chiananda (Diskussion) 04:06, 28. Jun. 2020 (CEST)

Einbindung von Userscripten in Special:MyPage/common.js[Quelltext bearbeiten]

Man kann dort j Helferlein mittels

mw.loader.load('https://de.wikipedia.org/w/index.php?title=Benutzer:Schnark/js/letzteredit.js&action=raw&ctype=text/javascript');

einbinden,. oder mit

importScript('Benutzer:Schnark/js/letzteredit.js');

Es gibt aber einen klitzekleinen Unterschied: Bei Verwendung von importScript erscheint das in der mobilen Version Helferlein nicht, bei mw.loader.load ist die Funktion auch in der mobilen Version zu finden. Ist das bekannt?

Eventuell Hilfe:Dateien_nach_Commons_verschieben anpassen, dort wird importScript beschrieben, das klappt aber dann mobil nicht – es sei denn das ist Absicht. --Wurgl (Diskussion) 16:06, 25. Jun. 2020 (CEST)

  • Erstmal wäre überhaupt seltsam, dass /common.js in der mobilen Version Wirkung hätte, weil dies nur auf Desktop-Skins ausgeführt wird.
  • Dazu wäre die Situation mal genauer zu rekonstruieren.
  • Der beschriebene Unterschied ist nicht bekannt, aber importScript auch nur ein allmählich auslaufendes Modell aus den frühen Jahren. Selbst wenn die Beobachtung zutreffen würde, hätte das keine Konsequenzen.
  • Für „Commons verschieben“ sind die Commons-verschieben-Leutchen zuständig.
LG --PerfektesChaos 16:21, 25. Jun. 2020 (CEST)
Tatsach! commons.js wirkt! Bei https://de.m.wikipedia.org/wiki/Joachim_Witt/Diskografie sehe ich die Autorenanteile, die WikiHistory erzeugt. Und bei https://de.m.wikipedia.org/wiki/Joachim_Witt sehe ich neben den Normdaten den Knopp "Bearbeiten". --Wurgl (Diskussion) 16:38, 25. Jun. 2020 (CEST)
Ich präzisiere mal mobil und Desktop:
Die Domain de.m.wikipedia.org hat primär nichts mit der Angelegenheit zu tun, weil dort zumindest theoretisch jede Skin möglich sein müsste.
LG --PerfektesChaos 17:34, 25. Jun. 2020 (CEST)
Hab es gerade getestet: Doch, ist echt so! Mit importScript hab ich WikiHistory mobil (Minerva, m-Domain) nicht, mit mw.loader.load schon. Seltsam.
Und zu m/Minerva: Ich wüsste zumindest keinen Weg, mit der m-Domain einen anderen Skin zu erzwingen. Was dort verwendet wird, ist ja auch nur eine reduzierte Fassung von Minerva, nicht die sonst auch installierbare. Gruß–XanonymusX (Diskussion) 18:05, 25. Jun. 2020 (CEST)
Auf jeden Fall kann man auch bei den m-Domains useskin-Parameter anhängen, und erhält dann auch ein paar Modifikationen in anderen Skins ;-) --nenntmichruhigip (Diskussion) 18:13, 25. Jun. 2020 (CEST)
Hast Recht, da muss ich mich vorhin vertippt haben, hatte nämlich genau das getestet …–XanonymusX (Diskussion) 18:37, 25. Jun. 2020 (CEST)
Wie auch immer. Ich hab ja da so ein Dingens, nennt sich Smartphone. Dort hab ich mich eingeloggt. Zufällige Seite aufgerufen. WikiHistory blendet mir die Autoren ein. Zurück auf Google. Merkel eingetippt. Irgendwo unter den Treffern war Wikipedia. Angetippt. WikiHistory blendet mir die Autoren ein. Ich hab auf Meta nix, ich hab keine minerva.js, ich hab nur common.js. Allerdings ist es so, dass einige Ids vom HTML-Elementen in dem Skin nicht existieren, daher diese Änderung: Spezial:Diff/200379311/201289632, möglicherweise ist man deshalb zum Schluss gekommen, die global.js würde nicht gesaugt. --Wurgl (Diskussion) 21:59, 25. Jun. 2020 (CEST)

Vorlage:Coordinate und Vorlage:Infobox_Tunnel kollidieren bei der Textanzeige[Quelltext bearbeiten]

Klüttunnel nutzt sowohl Vorlage:Coordinate als auch Vorlage:Infobox_Tunnel. Die Koordinaten in der Ecke rechts oben sind unlesbar, da wohl beide Vorlagen diesen Platz nutzen wollen. (Falls es einen besseren Ort gibt um dieses Problem anzubringen sind Links recht willkommen.) --Malyacko (Diskussion) 16:17, 10. Jul. 2020 (CEST)

Dabei wird es sich um eine nicht spontan lösbare Folge eines 2006 zusammengepfuschten Hack von handeln, der seit vielen Jahren als hochproblematisch bekannt ist.
Man hatte damals naiv und blauäugig gedacht, dass es die damaligen Skins auf ewige Zeiten und nur diese und immer genauso geben würde. Also hatte man dort ein leeres Plätzchen ausgeguckt, und beamt über die vermutlich freie Stelle obendrüber die von dir benannten Beschriftungen, ohne dabei wissen können, ob der Platz dort tatsächlich frei wäre, und sich mit anderen Elementen koordinieren zu können.
Jetzt stehen da also zweie. Naja, müssten die Leutchen mit dem Artikel sich halt koordinieren, welche von beiden dargestellt werden solle; die wissen nix voneinander.
Zur grundsätzlichen Lösung wende dich bitte an WD:GEO.
VG --PerfektesChaos 17:07, 10. Jul. 2020 (CEST)
Tunnel werden eigentlich immer an beiden Portalen georeferenziert, das langt dann auch. --Bahnmoeller (Diskussion) 15:06, 10. Aug. 2020 (CEST)

ISBN-Formatierer IsbnCheckAndFormat 404[Quelltext bearbeiten]

Hallo, kann bitte jemand den ISBN-Formatierer (IsbnCheckAndFormat) mal wieder anstoßen, da seit einigen Tagen unerreichbar: 404. Vielen Dank, --Wi-luc-ky (Diskussion) 16:36, 10. Jul. 2020 (CEST)

WP:HT/IsbnCheckAndFormat benennt Benutzer:°; falls dieser sich nicht meldet und hier nicht spontan ein Bot- oder Tool-Betreiber aufschlägt dann auf WP:BA vorstellig werden, die haben Routine mit sowas. VG --PerfektesChaos 17:12, 10. Jul. 2020 (CEST)
Ich werde mir ansehen, was da los ist, aber ich komme nicht sofort dazu. Allerdings die Frage: Das meiste der Funktionalität des Tools wird inzwischen von eingebauten MW-Tools und von Nutzer-JS-Skipten erledigt, ich habe den Eindruck, dass mein Tool kaum noch verwendet wird. Eine angefangene Überarbeitung (mit neuer Funktionalität) ruht deshalb seit längerem. Wie sehr wird das Tool überhaupt noch verwendet? (auch @Fano:) --𝔊 (Gradzeichen Diſk) 04:59, 11. Jul. 2020 (CEST)
Danke, 𝔊, für die Rückmeldung. Ich nutze Dein Tool gern und häufig und würde mich über eine einfache Instandsetzung freuen. Eine Erweiterung bräuchte ich derzeit nicht (ohne natürlich die erweiterten Funktionalitäten zu kennen, die Dir vorschweben). An welche MW-Tools hast Du gedacht? JS-Skripte haben den Nachteil, dass sie ohne Vorkenntnisse und Installation nicht nutzbar sind. Im allgemeinen Interesse wäre also ein einfach handhabbares Tool. Gruß, --Wi-luc-ky (Diskussion) 11:32, 11. Jul. 2020 (CEST)
@Wi-luc-ky: In einer Paralleldiskussion hat Lómelinde einen workaround mit der Literaturvorlage empfohlen:
{{Literatur|Titel=Nur ISBN umschreiben|ISBN=978-3928656818}} Nur ISBN umschreiben. ISBN 978-3-928656-81-8.
Das funktioniert zur reinen Formatierung super! Die Skriptlösung mit WSTM habe ich noch nicht probiert. Danke nochmal Lómelinde! --Fano (Diskussion) 14:26, 11. Jul. 2020 (CEST)
@Wi-luc-ky: kommst Du mit dem Template Literatur erstmal klar? Ich werde mich um die 404 kümmern, aber ich muss erst wieder meinen ssh-zugang in Betrieb bringen, das kann schnell gehen oder langwierig. (die zugangsdaten sind auf einem defekten Rechner eingerichtet). --𝔊 (Gradzeichen Diſk) 18:34, 12. Jul. 2020 (CEST)
@°: Mit der VL Lit. in Vollform hatte ich schon gearbeitet; und die Lösung von Lómelinde ist bestechend einfach. Damit kann ich aber leider keine leichte Umrechnung vornehmen, d. h.: Wenn Du das Tool wieder zum Laufen bringen könntest, wäre es optimal. Viel Erfolg! Danke, --Wi-luc-ky (Diskussion) 19:05, 12. Jul. 2020 (CEST)

Ich vermisse das Teil auch. Um die Bindestriche korrekt zu setzen, ist der workaround ok, aber ISBN-10 auf -13 umzurechnen, geht damit wohl nicht. --Gerbil (Diskussion) 10:42, 28. Jul. 2020 (CEST)

Es gäbe da noch einige Internetseiten die das umrechnen können
Wahrscheinlich bin ich zu doof, um mit diesem Tool zurechtzukommen :-( Egal was ich eingebe, ich bekomme immer wieder diesen Hinweis: "If you need an entire prefix of ISBNs converted, visit our inquiry page to get started." Was bitte soll ich dort wo und genau wie eingeben??? Das leider ausgefallene ISBN-Formatierer Tool war hingegen absolut Narrensicher! -- Muck (Diskussion) 23:46, 13. Aug. 2020 (CEST)
Nachtrag: Oder liegt es etwa daran: "This ISBN Converter Tool only supports ISBNs allocated inside the USA and Australia." Wenn ja, was soll ich denn dann mit derartigem Mist ? -- Muck (Diskussion) 23:52, 13. Aug. 2020 (CEST)
@Muck, ich kann das ganz einfach bedienen.
In des Eingabefeld ISBN (10 or 13) gibt man, wie es dort steht, die 10- oder 13-stellige Ziffernfolge ein (Beispielsweise 978-3-608-93977-4 mit oder ohne Bindestriche).
Dann klickt man auf convert und erhält das entsprechende Ergebnis als 13- oder 10-stellige Ziffernfolge. Converted ISBN = 3-608-93977-6 = Der Hobbit, oder, Hin und Zurück : [das Original zum Film]. Klett-Cotta, Stuttgart 2012. (deutsch), sollte aber doch 13-stellig bleiben.
Eine Fehlermeldung bekomme ich da nicht. --Liebe Grüße, Lómelinde Diskussion 07:12, 14. Aug. 2020 (CEST)
@Lómelinde: Vielen Dank für deine Rückmeldung, die mir Ansporn war, bei meinem Browser nach der Fehlerursache zu suchen. Und siehe da, tatsächlich hatte ich übersehen, dass bei mir per Noscript standardmäßig alle Scripte zunächst einmal blockiert sind. Habe sie dann auch für diese URL temporär zugelassen und schon klappte es problemlos. War also mein dummer Fehler. Die Möglichkeiten dieses Tools werden mir also wieder sehr hilfreich sein :-) auch liebe Grüße -- Muck (Diskussion) 11:16, 14. Aug. 2020 (CEST)
@Muck, schön, dass Du es selbst gefunden hast; hatte Dir gerade von NoScript schreiben wollen.
@alle Interessierte: Die Einschränkung – „This ISBN Converter Tool only supports ISBNs allocated inside the USA and Australia.“ – scheint nicht mehr zu bestehen, da ja auch solche ISBNs, die anderen Ländern zugewiesen sind, verarbeitet und umgewandelt werden. Gruß, --Wi-luc-ky (Diskussion) 11:42, 14. Aug. 2020 (CEST)
Also wer das wirklich sucht, hätte da auch etwas finden können einfach bei Google „isbn 10 in isbn 13 umwandeln“ oder ähnliche Suchbegriffe eingeben. --Liebe Grüße, Lómelinde Diskussion 11:15, 10. Aug. 2020 (CEST)
Ja, mit Suche hätte man etwas finden können. Aber das scheinen dann Spezialtools für bestimmte Länder zu sein, was die Nutzung schon wieder schwieriger macht (man muss aufpassen und selektieren). Und den Workaround mit Vorlage:Literatur hatte ich auch schon in Notfällen genutzt. Wenn man aber viel im ISBN-Korrekturbereich arbeitet, dann ist IsbnCheckAndFormat schon alleine deshalb mit Abstand die Nummer 1, weil man feste Tastaturfolgen hat, um sehr effizient die Eingaben zu erledigen. Ich weiß, kann man auch als „Wünsch Dir Was“ sehen, aber eine Ehrenrunde mit Vorlage:Literatur-Workaround dauert 2 Minuten (Achtung, Aufräumen anschließend nicht vergessen), IsbnCheckAndFormat 5 Sekunden (mit Copy&Paste). Lange Rede kurzer Sinn, ich schließe mich Wi-luc-ky an und würde mich freuen, wenn das Tool möglichst schnell in der bisherigen Funktionalität wieder arbeitet. Danke im Voraus und VG --Bicycle Tourer 19:23, 10. Aug. 2020 (CEST)
Nachtrag: Ein weiterer Workaround, wenn es nur um das richtige Format der ISBN geht (Striche an der richtigen Stelle): Man kann in der DNB die korrekte Formatierung abrufen. VG --Bicycle Tourer 22:47, 11. Aug. 2020 (CEST)

Bearbeitung nicht mehr möglich[Quelltext bearbeiten]

Hallo zusammen,

ich habe folgendes Anliegen: Ich kann seit einigen Tagen nichts mehr zur Wikipedia beitragen, da sobald ich in einem Artikel auf den Reiter "Bearbeiten" klicke, der Quelltext zwar für eine Sekunde erscheint, dann aber komplett verschwindet. Die Seite ist dann leer. Ich kann zwar jetzt neuen Text hinzufügen, aber alles was vorher im Artikel stand ist weg. So passiert in meinem Artikelentwurf: https://de.wikipedia.org/wiki/Benutzer:DieNummer9/Ibrahim_Abu_al-Yaqzan Ich wollte ihn vor der Verschiebung in den Namensraum nochmal prüfen, habe abgespeichert. Jetzt zeigt die Versionsgeschichte an "die Seite wurde geleert". Ich habe natürlich sofort versucht, die Änderung rückgängig zu machen, leider ohne Erfolg. Die Seite bleibt leer und ich kann die Änderung nicht zurücksetzen. Was ist hier passiert??

Auch bei anderen Artikeln, die nicht von mir erstellt wurden, passiert dies. Ich kann also quasi nichts mehr bearbeiten, da alles vorherige verschwindet.

Auch ein und ausloggen hat nicht funktioniert. Dieses Phänomen tritt trotzdem weiter auf.

Vielen Dank im Voraus DieNummer9 (Diskussion) 13:00, 23. Jul. 2020 (CEST)

Ich habe mich nun ausgeloggt und den Quelltext zurückgeholt. Es ging. Eingeloggt geht es immer noch nicht. DieNummer9 (Diskussion) 02:57, 24. Jul. 2020 (CEST)
@DieNummer9: Hmm, hier kannst du ja schreiben. Kannst du das mal mit einem anderen Browser probieren? --Count Count (Diskussion) 07:45, 24. Jul. 2020 (CEST)

Artikel erstellen: Button Quelltext-Editor[Quelltext bearbeiten]

Hallo! Wenn man im Suchfeld etwas eingibt, zudem es noch keinen Artikel gibt, kommt ja der allseits bekannte Hinweis Der Artikel „...“ existiert in der deutschsprachigen Wikipedia nicht. Du kannst den Artikel erstellen (Quelltext-Editor, Anleitung). Ich nutze ja mit meinem Benutzerkonto den Quelltext-Editor und komme, wenn ich auf Quelltext-Editor klicke auch darauf. Wenn ich jedoch nicht angemeldet bin, gelange ich über beide Schaltflächen (also sowohl erstellen als auch Quelltext-Editor) auf den Visual-Editor. Lässt sich das beheben? --Ameisenigel (Diskussion) 14:58, 26. Jul. 2020 (CEST)

Seitenvorschau und geklammerte Terme[Quelltext bearbeiten]

Hallo zusammen, bei der Seitenvorschau des Artikels (((echo))) ist mir aufgefallen, dass dort das Wort (((echo))) fälschlicherweise durch () ersetzt wird. Bei anderen Lemmata, z. B. Angela Merkel werden nur die Geburtsdaten versteckt, aber andere eingeklammerte Bezeichnungen, z. B. (CDU) bleiben erhalten. Kennt jemand die Logik dahinter, wann geklammerte Begriffe verschwinden und wann nicht? Wie kann der erste Artikel korrigiert werden, gibt es da einen Trick wie {{SEITENNAME}} oder <nowiki>? --2A02:908:1464:B00:A5D1:7634:B7FA:5905 15:40, 30. Jul. 2020 (CEST)

Ja, ist bekannt; das ist ein Feature, das für in mehreren Schriftsystemen vorliegende Textfragmente in chinesischer Sprache innerhalb derselben Wikipedia vorgesehen ist, usw.
nowiki hilft: (((echo))) durch ''<nowiki>(((echo)))</nowiki>'' deaktiviert das.
Wobei das eigentlich auf geschweifte Klammern ansprechen soll; mit doppelten runden kam es mir auch noch nicht unter.
LG --PerfektesChaos 16:02, 30. Jul. 2020 (CEST)
Nee, er meint die Seitenvorschau mit Mouse-Over. Dort wird statt "((echo))" nur "()" angezeigt. Und dein vorgeschlagenes nowiki klappt leider nicht. --Wurgl (Diskussion) 16:15, 30. Jul. 2020 (CEST)
Wir haben mehrere „Seitenvorschau mit Mouse-Over“, aber die sind irgendwas in JavaScript und da kann es schon sein dass die Programmierer einen unglücklichen Hack angewendet hatten und mit solch einer Syntax, die es ja „niemals im Text geben kann“ sich irgendwelche Markierungen eingebaut haben. Sowas macht man ja auch nicht.
Also verstehe ich richtig, unser Wikitext und auch die HTML-Seitenvorschau ist korrekt, aber im Pop-Up fehlt an genau welcher Stelle (Wörter davor, dahinter) genau was, das im Quelltext wie hinterlegt wäre? Die ersten 16 Bytes in Fettschrift?
VG --PerfektesChaos 16:39, 30. Jul. 2020 (CEST)
Preview-Klammern.png
Es geht wohl um Spezial:Einstellungen#mw-prefsection-rendering und dort um "Leseeinstellungen" → "Seitenvorschaubilder (ruft schnelle Vorschaubilder zu einem Thema ab, während du eine Seite liest):"
statt "(((echo))) und dreifache Klammern …" steht das "() und dreifache Klammern …"
Die engl. Wikipedia hat das selbe Problem, siehe dort en:Template:Alt-right_footer Online culture / Memes / letzter Eintrag "Triple parentheses" auch dort steht "… also known as an (), …" statt "… also known as an (((echo))), …" --Wurgl (Diskussion) 16:55, 30. Jul. 2020 (CEST)

Wenn man unseren Text vergleicht, dann fehlt der Einschub (englisch: triple parentheses) – ich meine mich daran erinnern zu können, dass zur Straffung des Textes eingeklammerte Zusätze weggelassen würden. Ich habe mit diesem Feature nichts zu tun, aber in meinem Hinterkopf meint irgendwas, dass es auch Beschwerden gab, weil bei uns die Lebensdaten (von wann bis wann gelebt) auch futsch wären und das nun aber eine ziemlich wesentliche Info sei und wir sollten das Format von 750.000 biografischen Artikeln umstellen damit dieses Tool sowas anzeigt. VG --PerfektesChaos 17:26, 30. Jul. 2020 (CEST)

Hab auf beta mal mit <nowiki>, mit <s> und mit <noinclude> probiert. Hilft alles nix. --Wurgl (Diskussion) 17:37, 30. Jul. 2020 (CEST)
Auch mit Klammern als &#x28; klappt nicht. --Wurgl (Diskussion) 17:41, 30. Jul. 2020 (CEST)
JavaScript-Werkzeuge arbeiten auf den geparseten Inhalten, also auf dem, was im HTML-Dokument zwischen den Tags steht. Zeichencodes werden bei der Generierung des Dokuments normalisiert.
Wie ist denn das jetzt mit den eingeklammerten Lebensdaten einer Person?
VG --PerfektesChaos 17:56, 30. Jul. 2020 (CEST)
Also mich stören die ausgelassenen Lebensdaten überhaupt nicht, ganz im Gegenteil. Manchmal sind da drölfzig Schreibweisen in unterschiedlichen Schriftsystemen/Sprachen in der Klammer und die muss ich in der Vorschau nun wirklich nicht sehen. Beispiele: Georgische Sozialistische Sowjetrepublik oder Dawit Tschubinaschwili
Der ruft https://de.wikipedia.org/api/rest_v1/page/summary/(((echo))) auf und da fehlt der Inhalt der Klammern schon, sieht nicht nach Javascript aus …--Wurgl (Diskussion) 18:10, 30. Jul. 2020 (CEST)
Mit den Lebensdaten habe ich auch kein Problem. Das ist gewollt, dass diese nicht angezeigt werden, ebenso. Aber ich vermute, irgendwo muss es wohl einen regulären Ausdruck in der Wikimedia-Software geben, der steuert, dassz. B. das Wort (CDU) bei der Mouse-over-Vorschau von Angela Merkel oder das Wort (Oder) bei Kliestow angezeigt werden, aber die Worte (geb. Kasner; * 17. Juli 1954 in Hamburg) und (Anhören?/i) nicht. --95.223.106.242 14:09, 31. Jul. 2020 (CEST)
Das wird wohl so sein, bei der von Wurgl angegebenen API.
Aber das ist globale Software, für 300 Sprachen, in 500 Wiki-Kulturen mit unterschiedlichen Darstellungen für dies und das und jenes, und das voller Ausnahmeregeln zu basteln weil in enWP+deWP = 8 Millionen Artikel es 2 Artikel gibt, bei denen das dann mal schiefgeht, wird niemanden dazu motivieren da lauter Ausnahmeregeln einzubauen für exotische Fälle.
Spannender ist, warum da () überbleibt und nicht (()) – lässt vermuten, dass die Eliminierung zweimal läuft, um irgendwie Klammern in Klammern auch noch auszublenden.
Nö, dieses Pop-Up hat dann halt Pech gehabt; wird wohl kaum ein Entwickler viel investieren wollen und die Performance der API eine Millisekunde runterdrücken. Wenn es der echte Artikeltext wäre, sicher, aber das ist nur eine Blase.
VG --PerfektesChaos 14:26, 31. Jul. 2020 (CEST)
Scheint dieser Teil hier zu sein: mw:Wikimedia REST API. --Wurgl (Diskussion) 14:48, 31. Jul. 2020 (CEST)

Quelltext-Editor Edittools[Quelltext bearbeiten]

Hallo. Gibt es einen Trick (Aufrufparameter, Javaskript etc), mit dem ich erreichen kann, dass beim Start des Quelltexteditors via "Quelltext bearbeiten" nicht die "Edittools-Standardleiste", sondern die "Edittools-WikiSyntax-Leiste" ausgewählt ist (in der Combobox)? Die benötige ich viel häufiger. ÅñŧóñŜûŝî (Ð) 19:04, 2. Sep. 2020 (CEST)

Diff-Ansicht zeigt Wörter mit Umlauten fälschlich als geändert an[Quelltext bearbeiten]

Diff. Unicode-Kodierung (zumindest in der Diff-Ansicht) ist identisch. Hat jemand eine Erklärung? Bug? --Count Count (Diskussion) 11:04, 5. Sep. 2020 (CEST)

Das ist auch im API (Per Browser nach "Benutzer alles im" suchen) nicht zu unterscheiden, die UTF-Zeichen sind als \u... kodiert. Ich dachte erst, das ist so eine seltsame Sache mit UTF-8, wo man Umlaute als einen Codepunkt oder als Komposition aus dem Grundbuchstaben und einem Kombinationszeichen darstellen kann. Ganz seltsam. --Wurgl (Diskussion) 11:36, 5. Sep. 2020 (CEST)
  • phab:T197850
  • Was auffällt: Die Siggi von Valanagut schaut nach Thai-Einfügung aus.
  • Da ich selbst einmal einen Neuschrieb des Diff-Code vorgestellt hatte, weiß ich, dass Thai in der veränderten Zeile eine andere Behandlung erfordert, und die jetzt aktive, seit damals veränderte Implementierung (angeregt durch meine, aber nicht 1.1 übernommen) ist dann wohl von Nicht-ASCII überfordert. Wobei ich nicht mehr mit Gewissheit sagen kann, ob meine damalige Programmierung pfiffiger war und das ignoriert hätte, glaube aber schon, auch so auf den ersten Blick fast ein Jahrzehnt später, weil ich nicht immer die gesamte Zeile vergleiche, sondern separat die Nur-Thai-Sequenzen als einzelne Wörter. Die zuvor und bis heute wirksame Implementierung wendet hingegen den Thai-Diff-Algorithmus auf die gesamte Zeile an, sofern Thai irgendwo darin vorkäme, und versagt deshalb bei Nicht-ASCII.
  • All-in-one-Diff wie Schnark sehen keinen Unterschied an den Umlauten.

VG --PerfektesChaos 15:41, 5. Sep. 2020 (CEST)

"Aktionsanzahl limitiert"[Quelltext bearbeiten]

Hallo Technikwerkstatt,

ich habe heute mal wieder aus heiterem Himmel bei einer völlig harmlosen Bearbeitung die Fehlermeldung "Aktionsanzahl limitiert" bekommen. Da ich dies für eine beabsichtigte Beschränkung hielt, habe ich heute und neulich auch schonmal bei den Admins nachgefragt, aber die wussten auch keinen Rat. Die limitierenden 8 Edits pro Minute habe ich ganz sicher niemals erreicht. Ist es möglich, dass das irgendein Bug ist? Danke, --217.239.3.143 19:21, 17. Sep. 2020 (CEST)

Navigationsleisten und Kategorienleisten anpassbar, im Falle einer Änderung der Benutzeroberfläche?[Quelltext bearbeiten]

Hallo Technik!
Angenommen die deutschsprachige Wikipedia würde per MB entscheiden, Kategorien zwecks höherer Wahrnehmung über die Einzelnachweise zu setzen, wäre dies technisch für Euch insoweit machbar, dass sich Navigationsleisten und die Kategorienzeilen bei kurzen Artikeln (die zugleich Infoboxen und/oder Bilder am rechten Rand haben) anpassen würden, sodass es nicht zu einer überdeckung der Flächen am rechten Rand kommt? Bei etwas längeren Artikeln, bei denen bspw. die Bilder am rechten Rand bis über den Abschnitt der Einzelnachweise hinausreichen, wird der Quellen-Abschnitt automatisch visuell komprimiert. Zu sehen bspw. im Artikel Parker Solar Probe. Bei Navigationsleisten und Kategorienleisten findet diese Anpassung/Komprimierung derzeit (auch bei längeren Artikeln) nicht statt. Das kann man bspw. sehen, wenn man über die Bearbeitung des eben erwähnten Artikels, den Fließtext aus dem Artikel rausnimmt und sich das Ergebnis über die Vorschau ansieht: So folgen erst nachdem die Infoboxen und Bilder am rechten Rand enden, die Navigationsleisten und Kategorienleisten.
Gruß, --LennBr (Diskussion) 03:55 (Nacheditiert um 18:27), 18. Sep. 2020 (CEST)

  • Theoretisch für Benutzer mit aktiviertem JavaScript schon.
  • Das Ganze ist in Desktop gedacht; in den Mobildarstellungen nicht umsetzbar.
  • Es wird sich niemand darauf einlassen:
    • Der Aufwand zu einer Jonglage ist relativ groß.
    • Es wird zu einem Flackern der Seite kommen: FOUC
    • Global steht das auf allen Seiten in jedem Wiki an der gleichen Stelle, und auch die hiesige Lesersachaft ist es an dieser Stelle gewohnt.
    • Wenn, dann passiert das auf allen Seiten, und auch Wartungskategorien würden dann mitten im Artikel auftauchen. Irgendwas wie „kurze Artikel“ gibt es nicht. Es gibt auch keine einheitliche Überschrift „Einzelnachweise“, oberhalb so bezeichneten Abschnitts etwas dargestellt werden könnte.
    • Für Autoren, neue und altgediente, ist die Darstellung ziemlich verwirrend und bedürfte Umlernens, und die Darstellung wäre nicht mehr vorhersagbar. Momentan ist das sehr simpel: Das, was ich als Wikitext angebe, wird in einem einheitlichen Block in genau dieser Reihenfolge auch in der Seite dargestellt. Außerhalb dessen stehen die Kategorien, in allen Namensräumen, immer an der gleichen Stelle. Auch die Leser suchen es in allen Namensräumen in allen Wikis dort und nur dort. Wenn es dort unten nicht zu sehen ist, dann gibt es auch keine Kategorisierung, basta.
    • Der Artikel sieht Mobil anders aus als Desktop, mit JavaScript gibt es andere Abschnitte als ohne, bei Artikeln ohne „Einzelnachweise“ mit Navigationsleisten ist es wieder anders. Ziemlich konfus.
    • Die Richtlinien zur Anordnung von Abschnitten in Artikeln müssten umgeschrieben werden.
    • Performancemäßig katastrophal: Um ein oder zwei Dutzend Seiten umzubauen, die optisch in Frage kämen und auch einen „Einzelnachweise“ überschriebenen Abschnitt hätten, müssten zweieinhalb Millionen Artikel analysiert werden, für jede Darstellung.
  • Ein MB würde ich persönlich als chancenlos einschätzen, aber das ist nicht meine Aufgabe.
VG --PerfektesChaos 15:08, 18. Sep. 2020 (CEST)
@PerfektesChaos: Sind alle diese Punkte in der Annahme geschrieben, dass nur bestimmte Artikel von einer solchen (hypothetischen) Änderung nach positiven MB betroffen sind? Im Ausgangspost oben habe ich nicht klar genug gemacht, dass ich über ein Verschieben der Navi- und Kategorienleiste bei allen Artikeln nachdenke, sodass diese Leisten besser zur Geltung kommen. Würde also deine Einschätzung/Antwort nun anders ausfallen (unter der Annahme, dass Du dachtest, ich beziehe mich nur auf kurze Artikel)? --LennBr (Diskussion) 18:25, 18. Sep. 2020 (CEST)
Ich ging von deiner Darstellung zum Platz sparen bei kurzen Artikeln und viel Infobox aus, und irgendwas mit Layout und Bildern am rechten Rand. Das Gesamtziel oder ein Konzept habe ich ohnehin nicht verstanden.
Auch übertragen auf alle Artikel bleiben aus rein technischer Sicht die nachstehenden Knackpunkte:
  • Kategorien lassen sich nur mit aktiviertem JavaScript woanders hin mitten in den Artikel verschieben, mit dem Problem des FOUC und bei anderer Artikelstruktur in einer Mobil- und Desktopdarstellung.
  • Im Inhaltsverzeichnis taucht dein eingefrickelter Kategorien-Abschnitt grundsätzlich nicht auf, soll aber wohl eine Abschnittsüberschrift bekommen.
  • Was haben die Wartungskategorien im enzyklopädischen Text zu suchen?
  • Heißt: Der Artikel wird für viele Leser aus unerfindlichen Gründen dauernd anders strukturiert aussehen.
  • Das muss überhaupt erstmal eine Mehrheit der MB-Teilnehmer befürworten, und die sehe ich nicht.
Mit Navigationsleisten wird das noch abenteuerlicher.
  • Verschieben der Navileiste bei allen Artikeln – das klingt nicht wie gründlich durchdacht.
  • Navigationsleisten stehen nach dem Artikeltext, nachdem alle enzyklopädischen Inhalte zu diesem Lemma erschöpfend behandelt wurden. Sie verweisen dann auf benachbarte enzyklopädische Artikel und stehen genau dort goldrichtig wo sie heute stehen.
  • Im Anschluss an die Navigationsleisten, sofern vorhanden, kommen nur noch Verwaltungsinformationen und Angelegenheiten außerhalb des enzyklopädischen Inhalts selbst; ggf. eine Gespochene Version oder Auszeichnungen als Lesenswert, Exzellent oder dergleichen.
  • Dorthin, also zum Verweis auf andere Artikel mit thematischer Nachbarschaft gehören auch die Kategorien.
  • Du müsstest deinen Plan mal an der Vorlage:Navigationsleiste The Beatles oder in den Artikeln Jonathan Dayton (Politiker) bzw. Wolfgang Schäuble durchspielen.
  • Ich habe nicht verstanden, was das werden soll, aber diese Werkstatt ist auch definitiv der völlig falsche Ort für diese Frage. Hier war nur nach Darstellung der Kategorien an anderem Ort zu beantworten gewesen.
Am besten baust du Beispiel-Layouts in deinem BNR auf, stellst deine Absichten auch in Extremalfällen dar und diskutierst auf Basis anschaulicher Demonstrationsbeispiele irgendwo anders darüber.
Nebenbei: Nachträglich Pings in bereits signierte Beiträge einzubauen ist wirkungsfrei.
VG --PerfektesChaos 16:43, 19. Sep. 2020 (CEST)

Weiterentwicklung Softwaretool[Quelltext bearbeiten]

Es ist einige Monate her, da war ich berufsbedingt gezwungen programmieren lernen, in C++. Als es darum ging ein Übungsprojekt zu finden grub ich eine alte Idee aus, ein Tool das politische Weltkarten automatisch einfärbt, so was wird ja hier sehr oft gemacht. Das Tool wurde während des Kurses auch soweit fertig das es benutzbar ist, es fehlt noch gewisser Feinschliff und Komfortfunktionen. Nun kam es aber anders, aus der angedachten Stelle wurde virusbedingt nichts, und ich nun habe nun mit derartigen Themen (wieder) nur ganz selten was zu tun (und wenn, dann mit Python), lerne also nicht "automatisch" dazu. Lange Rede, kurzer Sinn, "fertigzustellen" geht vllt. noch, Pflegen oder gar Weiterentwicklung des ganzen aber nicht. Frage: Gibt es hier einen Programmierer, der das Tool mitübernehmen könnte?--Antemister (Diskussion) 13:59, 20. Sep. 2020 (CEST)

Translatable modules[Quelltext bearbeiten]

Hi,

Very sorry about writing in English. I hope somebody can translate this. Thanks in advance.

There's a new proposal to localize Lua modules in a more modern, safe, and convenient manner: mw:Translatable modules. In the foreseeable future it will only affect multilingual sites, such as Wikidata, Commons, Meta, and mediawiki.org, but at a later time it may also be deployed on Wikipedias and other projects.

It will be great if experienced module developers could take a look at the project page, mw:Translatable modules, and its subpages, especially mw:Translatable modules/Proposed solutions.

Thanks! --Amir E. Aharoni (WMF) (Diskussion) 16:34, 22. Sep. 2020 (CEST)

Doppeltes Eingabefeld für Zusammenfassungszeile[Quelltext bearbeiten]

Hallo, das in FzW geschilderte Problem ist nicht gelöst, wurde dort jedoch nicht weiter verfolgt. Ich habe heute mal einen Screenshot gemacht. Kann ich gern hochladen: Wo? Danke, --Wi-luc-ky (Diskussion) 19:13, 25. Sep. 2020 (CEST)

 Info:Die FzW-Diskussion wurde hier archiviert. --Count Count (Diskussion) 12:38, 29. Sep. 2020 (CEST)
Den kannst du auf Commons hochladen, Lizenzbaustein commons:template:wikimedia screenshot, siehe z.B. commons:File:Partial-block-german.png --Count Count (Diskussion) 19:30, 25. Sep. 2020 (CEST)
Danke, Count Count, den Screenshot findest Du nun hier (bitte Beschreibung nachbessern, falls erforderlich). Die obere Zeile ist zwar bearbeitbar, wird aber bei weiterer Vorschau nicht übernommen; stellt also eine Kopie der unter ZQ dar. Tritt auch bei anderen Benutzern auf, verwirrt und führt zu ZQ-Fehlern.
Zu beachten ist auch die Verdopplung der Sonderzeichenleiste darunter. Irgendwelche Skripte laufen da doppelt/parallel. Gruß, --Wi-luc-ky (Diskussion) 12:23, 29. Sep. 2020 (CEST)
@Wi-luc-ky: Kannst du es reproduzieren, wenn du die Toolserver-Integration komplett deaktivierst? --Count Count (Diskussion) 12:43, 29. Sep. 2020 (CEST)

Ich denke mal, ich erkenne charakteristisches Design von wikEd wieder, und das ist meines Wissens ungepflegt, maintainerlos, und der Entwickler, der es geschaffen und ein Jahrzehnt weitergebaut hatte ist inaktiv oder macht nichts mehr daran.

  • Die duplizierten Teile sind im wikEd-Design, also von diesem hinzugefügt, und wahrscheinlich wegen veränderter Selektoren-Struktur werden die Original-MediaWiki-Felder nicht mehr ausgeblendet.

VG --PerfektesChaos 14:48, 29. Sep. 2020 (CEST)

Dank euch beiden, Count Count und PerfektesChaos. Nachfolgend die permutierten Möglichkeiten mit Ergebnissen im ANR (mit kleinem Bsp.-lemma durchgeführt) zur Interpretation:
Kombi div. Benutzereinstellungen
Nr. Zusätzliche
Karteireiter
für externe
Werkzeuge
wikEd Sonder­zeichen­auswahl
(SZA)
Bemerkung
1 Nein Ja Ja 2 ZQs, 1 SZAs
2 Nein Nein Ja 1 ZQ, 1 SZA
3 Nein Ja Nein 2 ZQs, 0 SZA
4 Ja Ja Ja 2 ZQs, 1 SZA
5 Ja Nein Ja 1 ZQ, 1 SZA
6 Ja Ja Nein 2 ZQs, 0 SZA
Die doppelte Sonderzeichenauswahl konnte ich im ANR nicht mehr reproduzieren, jedoch auf dieser Disku bei Vorschau – jeweils bei zugleich drei zugeschalteten Features. (Hinweis: Gestern gab es zwei Änderungen in commons.js seitens WMF.) Gruß, --Wi-luc-ky (Diskussion) 01:23, 30. Sep. 2020 (CEST)
Wie leicht zu sehen ist, sind 2ZQs synchron mit wikEd – was nicht erstaunt, weil die eine ist von MediaWiki und die andere von wikEd; und der wikEd-Mechanismus, der bislang die MediaWiki-ZQ ausgeblendet hatte, funktioniert nicht mehr.
Nur mit wikEd kommt es zu einer Kollision mit den „SZA“ (heißen „editMenus“); warum auch immer.
Die „Karteireiter“ bieten ja nur Werkzeuge an, greifen aber nicht ein, und sind deshalb eher unbeteiligt.
Die bearbeitete Seite ist relativ egal. Mag aber etwas enthalten, was das Fass zum Überlaufen brächte.
VG --PerfektesChaos 22:33, 30. Sep. 2020 (CEST)
Vielen Dank, PerfektesChaos, für die nachvollziehbare Analyse. Es bleibt nun an den Betroffenen, ihre Einstellung zu ändern oder – die Bugs erduldend – zu belassen. Gruß, --Wi-luc-ky (Diskussion) 23:52, 30. Sep. 2020 (CEST)

Klick auf die Bearbeitungsleiste führt zu Änderung nicht im Bearbeitungsfenster, sondern in der ZuQ-Zeile[Quelltext bearbeiten]

Immer häufiger passiert es mir, dass wenn ich auf die Bearbeitungsleiste klicke, ich damit eine Änderung nicht im Bearbeitungsfenster, in der mein Cursor gerade steht, bewirke, sondern in der ZuQ-Zeile. Zuletzt ist mir das hier passiert, als ich unterschreiben wollte. Das ist schon reichlich nervig, vor allem wenn ich die Anführungszeichen einzeln per copy&paste aus der Zusammenfassung in den gewünschten Text transportieren muss. Mach ich was falsch, oder ist das ein Bug? U.A.w.G. Mit herzlichem Dank im Voraus --Φ (Diskussion) 20:19, 28. Sep. 2020 (CEST)

@Phi: Rückfrage: Verwendest du Syntaxhervorhebung, also das wo unser Wikitext bunt eingefärbt wird? VG --PerfektesChaos 14:38, 29. Sep. 2020 (CEST)
Nicht dass ich wüsste.
Es passiert immer dann, wenn ich schon was in die ZuQ-Zeile geschrieben habe und dann noch einmal ins Bearbetungsfenster gehe. --Φ (Diskussion) 15:03, 29. Sep. 2020 (CEST)
Mmmh. „noch einmal ins Bearbetungsfenster gehe“ – Schreibst du dort etwas rein, oder ist sicher dass du da auch angekommen wärst?
Das Dings von uns, das unter dem Bearbeitungsfeld ist, merkt sich in welchem HTML-Eingabefeld der Cursor zuletzt war, technisch: was zuletzt den Fokus hatte, und fügt dann auch in genau dieses Feld das hinein, was von der Werkzeugleiste aus gefordert wird.
Wenn das Bearbeitungsfeld keinen „Fokus“ hat, insbesondere wenn der Cursor dort nicht steht, dann hatte ZuQ zuletzt den Fokus; genauso falls durch andere Werkzeuge das einfache HTML-Eingabefeld deaktiviert oder versteckt würde.
Gibt es gleichzeitig noch andere Werkzeugleisten, die auch sowas Ähnliches machen würden?
Versuche mal, im Bearbeitungsfeld etwas zu selektieren=markieren, etwa ein Wort. Wenn das gelingt und keine Syntaxhervorhebungs-Werkzeuge aktiv sind, dann hat das auch den aktuellen Fokus.
Außerdem bräuchte dieser Fehlerbericht noch: Skin, Desktop/Mobil, Browser-Familie.
VG --PerfektesChaos 15:27, 29. Sep. 2020 (CEST)
Danke für deine Bemühungen. Ich weiß nicht, ob ich alles verstehe, was du schreibst.
Ich spreche von der Bearbeitungsleiste, die unter dem Bearbeitungsfenster erscheint: ''K'' '''F''' [[Seite]] [www] Datei:mini <nowiki> --~~~~ Dahinter kommen dann die Sonderzeichen.
Die reguläre Leiste oberhalb des Bearbeitungsfelds funktioniert einwandfrei.
Der Fehler tritt auch auf, wenn ich unmittelbar davor ins Bearbeitungsfeld geschrieben habe - hab ich gerade ausprobiert.
Ich arbeite mit einem Standgerät und surfe mit Firefox. Wie erfahre ih meinen Skin?
Grüße zurück (und jetzt hab ich schon wieder die Signatur aus der ZuQ-Zeile herauskopieren müssen) --Φ (Diskussion) 15:48, 29. Sep. 2020 (CEST)
Beide Leisten fügen dort ein, wo der Fokus vor dem Klick war. Klick ich in die Zusammenfassungszeile und dann in einer der beiden Bearbeitungsleisten, dann wird in der Zusammenfassungszeile eingefügt. Klick ich ins Bearbeitungsfenster, dann fügen die beiden eben dort ein. Eventuell ist dein Problem, dass der initiale Fokus nicht im Bearbeitungsfenster, sondern in der Zusammenfassung ist. --Wurgl (Diskussion) 15:59, 29. Sep. 2020 (CEST)
H:Skin bekommst du per Einstellungen: Benutzeroberfläche.
Es ist editMenus und mir damit klar, was du beschreibst mit ''K'' '''F''' [[Seite]] [www] Datei:mini <nowiki> --~~~~
Was „reguläre Leiste“ sein soll, verstehe ich nicht, wäre jedoch relevant; müsstest du mal aus Hilfe:Symbolleisten heraussuchen.
VG --PerfektesChaos 16:05, 29. Sep. 2020 (CEST)
Mit „reguläre“ meine ich die Klassische Bearbeitungswerkzeugleiste. Mein Skin ist anscheinend Monobook. Ergibt das für dich irgendeinen Sinn? Grüße --Φ (Diskussion) 17:47, 29. Sep. 2020 (CEST)
Mindestens sind das die Infos, die benötigt werden, um die Situation bei dir möglichst exakt nachzustellen.
Ich kann es nicht reproduzieren.
Falls es ein generelles Problem wäre, müssten sich bald mehr Leute melden.
Ich kann mir nur vorstellen, dass bei dir irgendeine Software aktiv ist, die das echte Wikitext-Bearbeitungsfeld versteckt. Syntaxhervorhebung ist dafür bekannt. Oder irgendeine Browserversion läuft schräg, was bei Firefox aber sehr selten wäre. Oder es gäbe ein spukendes Add-On nur bei dir.
Ich schätze dich mit Verlaub nicht so ein, dass du leicht mit der Fehlerkonsole zurechtkämst. Dort würden möglicherweise aufschlussreiche Fehlermeldungen sichtbar, aber auch Hunderte harmloser informativer Nachrichten. Insbesondere könnte man bei Auftreten des Problems aber die momentane HTML-Struktur inspizieren und analysieren; jedoch erfordert das eine ziemlich präzise Kenntnis von dem was da stehen müssste, um verdächtige Abweichungen vom Normalzustand zu erkennen.
Was noch nicht restlos aus deiner Schilderung hervorging: Kannst du generell niemals in das Wikitext-Bearbeitungsfeld einfügen, oder nur dann nicht mehr, nachdem du einmal im Bearbeitungskommentar drin warst? Oder meist geht es erwartungsgemß, und ohne ersichtlichen Grund landet urplötzlich alles im Kommentarfeld?
VG --PerfektesChaos 22:42, 30. Sep. 2020 (CEST)
Danke für deine Bemühungen. Ich KANN ja im Brearbeitungsfeld arbeiten, nur wenn ich die untere Bearbeitungsleiste betätige, bewirkt das eine Änderung in der ZuQ-Zeile, falls ich in der vorher was geschrieben hatte.
Und du schätzt meine Computerkompetenzen ganz richtig ein. Grüße --Φ (Diskussion) 20:06, 1. Okt. 2020 (CEST)

Hallo Φ und PerfektesChaos, dasselbe Problem hatte ich vor einiger Zeit (wann, wo erinnere ich nicht mehr) schon einmal geschildert und war von Dir, PerfektesChaos, beantwortet worden. Es ging um die Fokussierung an unerwünschtem Ort.

Testbericht bei wikEd 0.9.155 und (damit verknüpftem) Syntaxhighlight:

  • Nach ersten Bearbeiten-Aufruf kann ich mittels beider (!) editMenus (siehe Nebenbemerkung im Thread Doppeltes Eingabefeld für Zusammenfassungszeile eins drüber) den Text im Bearbeitungsfenster bearbeiten (bspw. typographische Anführungszeichen setzen). Nachdem ich Preview geklickt habe, ist das nicht mehr möglich, auch wenn der Cursor nochmals ins Bearbeitungsfenster geklickt wird.
  • Abwahl von Syntaxhighlight bei aktiviertem wikEd hilft nicht.
  • Abwahl von wikEd hilft.
  • Syntaxhighlight allein ist unschädlich, zeigt aber ohne wikEd auch keine farblichen Hervorhebungen an.

WikEd verhindert also die Funktion des EditMenus im Bearbeitungsfeld. Und da wikEd wie eins drüber erwähnt ein Waisenkind geworden ist, können wir das Verhalten unter die nicht anbetungswürdigen Mysterien verbuchen. WikEd bringt auch die Bearbeiten-Werkzeugleiste zum Verschwinden, ein weiterer Nachteil bei vielen Vorteilen: Love it or leave it.

Gruß, --Wi-luc-ky (Diskussion) 01:50, 2. Okt. 2020 (CEST)

Danke für deine Antwort, Wi-luc-ky. Ich hab jetzt den Haken bei wikEd, der unter Einstellungen/Helferlein gesetzt war, entfernt. Das Problem besteht aber fort. Nie rozumiem. --Φ (Diskussion) 14:46, 2. Okt. 2020 (CEST)

Meldungen und Mitteilungen[Quelltext bearbeiten]

Oben im Kopf der Seite sind neben meinem Benutzernamen die Symbole für meine Meldungen (Glocke) und meine Mitteilungen (leerer Bildschirm - oder was immer das ist) zu sehen. Seit Kurzem werden bei beiden Symbolen die Mitteilungen aufgeklappt, nur wenn ich bei der Glocke ganz unten auf den Klöppel klicke, was allerdings schwer zu erwischen ist, dann werden die Meldungen angezeigt. (Windows 10, Firefox 81.0.1 (64 bit), Benutzeroberfläche Vector, Legacy-Vector deaktiviert). Wenn ich auf die alte Vector-Oberfläche zurückschalte, funktioniert es; ist allso offenbar ein Bug in der neuen Oberfläche. --TheRunnerUp 22:30, 3. Okt. 2020 (CEST)

Tritt das Problem mit einem anderen Browser (z.B. Edge) auch auf? Gruß --FriedhelmW (Diskussion) 10:09, 4. Okt. 2020 (CEST)
Ja, mit Edge 85.0.564.68 (Offizielles Build) (64-Bit) auch, ebenso IE 11.0.9600, Firefox 68.12.0 - mehr habe ich nicht zur Verfügung. --TheRunnerUp 12:42, 4. Okt. 2020 (CEST)
Jetzt sehe ich es auch. Das könnte Task phab:T261171 sein. --FriedhelmW (Diskussion) 13:34, 4. Okt. 2020 (CEST)
Ja, das sieht genau so aus. Danke.--TheRunnerUp 14:56, 4. Okt. 2020 (CEST)

Wikidata-Einbindung defekt[Quelltext bearbeiten]

Warum gibt es im File:Heinrich IV (Germany).jpg (Versionen) keine Titelangabe im Summary hinter dem Malernamen im oberen blauen Feld? Bei Revision as of 16:37, 13 October 2020 (#213719203) war alles noch okay. VG --Mateus2019 (Diskussion) 19:05, 13. Okt. 2020 (CEST)

Skin-Codefehler im Vorschaumodus[Quelltext bearbeiten]

(Status: ohne VE, MonoBook, FireFox 82.0, Windows 8.1, WSTM geladen)

Ich bekomme seit paar Tagen beim Bearbeiten im Quelltextmodus nach der ersten Vorschau immer zuoberst die folgende Anzeige:

  • Dies ist nur eine [[Hilfe:Seite bearbeiten#Vorschau und Speichern|Vorschau]], {{#switch: {{NAMESPACEE}} | =der Artikel | #default=die Seite }} wurde noch nicht gespeichert! → Zum Bearbeitungsfeld gehen

Unter dem Quelltextfenster steht zu den Vorlagen:

  • {{PLURAL:{{{1|$1}}}|Die folgende [[Hilfe:Vorlagen|Vorlage]] wird|Folgende [[Hilfe:Vorlagen|Vorlagen]] werden}} von dieser {{#ifeq:{{NAMESPACE}}|{{ns:0}}|Artikelvorschau|Seitenvorschau}} verwendet:

Wo liegt das Problem? Gruß --Chiananda (Diskussion) 18:00, 22. Okt. 2020 (CEST)

Kann ich nicht nachstellen, im Vector ist es bei mir ok und ein Test mit MonoBook ergab auch keine Probleme. Du sagst ja „immer“. Ist das nur bei der ersten Vorschau? Ich habe ebenfalls Firefox und Windows 10. Hast du irgendwelche anderen Tools (Helferlein, Betafunktionen) aktiviert, etwas mit Syntaxhervorhebung beispielsweise? --Liebe Grüße, Lómelinde Diskussion 18:22, 22. Okt. 2020 (CEST)
Die Anzeige geht bei wiederholten Vorschauen nicht weg. So richtig ist mir das erst in den letzten Tagen aufgefallen; ich dachte, es wäre vielleicht ein Zwischenstadium bei WP-Software-Updates.
Beta-Funktionen habe ich keine aktiviert, auch keine Syntaxhervorhebung.
Mehrere Helferlein sind aktiviert. Ich habe erst einige, dann alle unter "Bearbeitungswerkzeuge" deaktiviert und eine BKS mit Strg+F5 neu vom Server geladen, dann "Seite bearbeiten" → "Vorschau zeigen": immer kommen die beiden Code-Anzeigen.
Meine anderen Helferlein:
Navigations-Popups, Pfeil-hoch-Helferlein, markAdmins, Altes Verschiebeformular, Überspringen…Commons, Fußnoten-Tooltip.
Weder am System noch im Browser wurde zwischenzeitlich etwas geändert. In den letzten Wochen habe ich mich nicht abgemeldet/angemeldet.
Gruß --Chiananda (Diskussion) 23:50, 22. Okt. 2020 (CEST)
Dass ich nicht der Einzige bin, beweist diese FzW. --Chiananda (Diskussion) 18:48, 3. Nov. 2020 (CET)
Jupp, auch bei mir: Monobook, kein VE, "Vorschau ohne Neuladen der Seite anzeigen" & "Vorschau oberhalb des Bearbeitungsfensters anzeigen" aktiviert, Betafunktionen: Videoplayer, Helferlein: Zusätzlicher Karteireiter für ext. Werkzeuge + Vorlagen-Meister + HotCat + Einleitungshelfer + BKL-Check + Wildcardbenutzer-Beiträge + Sonderzeichen + Extra-Editbutton + Revisionjumper + Einblenden Metadaten + WikiminiAtlas + OpenSteetMap + PrettyLog + Revision-Counter + markAdmins + Verschiebeformular + Überspringen lokaler Dateibescheibung + Versionsunterschiede in bisherigen Farben + Fußnoten-Tooltip, Browser/OS: Chrome (gerade 86.0.4240.111) unter Debian testing (Linux 5.9.0-1-amd64). Das rendern passiert aber doch ohnehin serverseitig? --StYxXx 23:26, 4. Nov. 2020 (CET)
Also das taucht bei mir auch total random auf, mal ja, mal nein. Wird aber wohl Serverseitig sein, weil wenn ich das ganze mit safemode=yes (deaktiviert Benutzerseitigen Skripte) mache, dann kommt das auch. VG, Luke081515 23:42, 4. Nov. 2020 (CET)
Da hilft nur eines: Wenn der Fehler auftritt: --> OFFLINE-Modus, dann den Quelltext anstarren (Ctrl-U bei Firefox). Ganz am Ende steht dann "{"origin":"mw1324","timestamp":"20201104164917", …" dieses "mw1324" ist wohl der Server.
OFFLINE-Modus, weil beim Angucken vom Quellcode wird der sonst neu geladen und man sieht das Ergebnis eines anderen Servers. --Wurgl (Diskussion) 23:54, 4. Nov. 2020 (CET)
Mal wieder typisch vom mw1324! Mag den nicht. VM?  --Chiananda (Diskussion) 03:40, 5. Nov. 2020 (CET)

Bei Bürostuhl zappeln die 4 - 5 rechtesten Links in der 2. Zeile[Quelltext bearbeiten]

77.189.37.238 03:28, 25. Okt. 2020 (CET)

Anscheinend nur , so lange nicht angemeldet.
Steue (Diskussion) 03:48, 25. Okt. 2020 (CET)
Dancing Vector tabs
Und der Bildschirm muss schmal sein. Hier auf einem hochkant gestellten iPad. Kommt mir bekannt vor, hatten wir das nicht vor ein paar Monaten schon mal? --MBq Disk 07:37, 25. Okt. 2020 (CET)
Ah ja, im Mai [8]. Ist wohl ein alter Bug, im Phabricator bekannt unter dem Namen "Dancing Vector tabs" https://phabricator.wikimedia.org/T71729 , vermutlich bleibt er uns erhalten --MBq Disk 07:43, 25. Okt. 2020 (CET)

Identische Disku-Edits in Folge[Quelltext bearbeiten]

Hallo, in Hilfe Diskussion:Einzelnachweise wurde gestern (lt. Auskunft des Benutzers: unwillentlich) ein Beitrag gleich dreimal hintereinander identisch editiert: Diff_1 und folgende. Woran lag’s bzw. ist so etwas vermeidbar? Gruß, --Wi-luc-ky (Diskussion) 14:43, 29. Okt. 2020 (CET)

Portal:Baptisten / Zufallsmaschine[Quelltext bearbeiten]

Guten Tag! Im Portal:Baptisten (rechte Spalte, ziemlich oben) gibt es eine sogenannte Zufallsmaschine, über die man sich einen zufälligen Artikel im Themenfeld Baptisten zeigen lassen kann. Leider funktioniert der Link nicht mehr; klickt man ihn an, erscheint der Hinweis Fatal error .... Woran liegt's? MfG, GregorHelms (Diskussion) 10:34, 18. Dez. 2020 (CET)

Da müsstest du du einen der Maintainer kontaktieren: https://admin.toolforge.org/tool/erwin85 Das "mysql_connect()" riecht nach notwendiger Portierung von PHP 5 nach PHP 7. --Wurgl (Diskussion) 10:46, 18. Dez. 2020 (CET)

Verschiebung von Artikeln[Quelltext bearbeiten]

Bei Verschiebungen von Artikeln wird (auf Wunsch) die Artikeldisk mitverschoben. Wie ich bei Leopold von Plessen (Minister) festgestellt habe, gilt das aber nicht für Archive der Diskussionsseite. Kann man das ändern, dass auch die Archive mitverschoben werden?--Karsten11 (Diskussion) 11:59, 18. Dez. 2020 (CET)

Es gibt die Option Unterseiten der Diskussionsseite verschieben (bis zu 100). --Leyo 12:03, 18. Dez. 2020 (CET)
Danke für die Info, Problem gelöst.--Karsten11 (Diskussion) 15:17, 18. Dez. 2020 (CET)
@ Leyo: Als Admin sehe ich die Option, sie ist sogar vorausgewählt. Für Normalbenutzer scheint sie aber nicht zu existieren. -- Perrak (Disk) 17:32, 18. Dez. 2020 (CET)
Hm, allenfalls wäre es sinnvoll, wenn dies für Sichter geändert würde. Oder aber, dass es irgendwie geloggt würde. --Leyo 19:08, 18. Dez. 2020 (CET)
+1. Wenn das als zu risikoreich betrachtet wird, wäre für Nicht-Rechte-Inhaber ein Warnhinweis "Für diese Seite gibt es Unterseiten. Verschiebe diese ebenfalls oder wende Dich an WP:VSW"--Karsten11 (Diskussion) 20:09, 18. Dez. 2020 (CET)
Könnte man machen. Aber warum? Gibt es Fälle, wo eine Diskussionsseite Unterseiten hat, die keine Archivseiten sind, wo die Verschiebung also unerwünscht wäre? Wenn es Probleme mit Verschiebevandalismus gibt, wäre es eher sinnvoll, die Schwelle zur Erlangung des Verschieberechts anzuheben, denke ich.
Loggen und fürs erste ein Warnhinweis an Leute, die das Recht nicht haben, wären natürlich allemal sinnvoll. -- Perrak (Disk) 11:25, 20. Dez. 2020 (CET)

Lua-Fehler: not enough memory[Quelltext bearbeiten]

Hallo,

auf COVID-19-Pandemie in Österreich ist es in den letzten Wochen immer wieder zu der genannten Fehlermeldung gekommen. Dann werden ein paar Diagramme mit Vorlage:Graph:Chart rausgenommen und das Problem ist erstmal gelöst. Jedoch ist das Verhalten doch etwas merkwürdig:

Spezial:Permanenter Link/206904507 -> Keine LUA-Fehler

Profiler:
<!-- 
NewPP limit report
Parsed by mw1322
Cached time: 20201226202506
Cache expiry: 2592000
Dynamic content: false
Complications: []
CPU time usage: 8.208 seconds
Real time usage: 8.337 seconds
Preprocessor visited node count: 68957/1000000
Post‐expand include size: 753682/2097152 bytes
Template argument size: 282888/2097152 bytes
Highest expansion depth: 12/40
Expensive parser function count: 4/500
Unstrip recursion depth: 0/20
Unstrip post‐expand size: 342258/5000000 bytes
Lua time usage: 4.488/10.000 seconds
Lua memory usage: 28351166/52428800 bytes
Lua Profile:
    recursiveClone <mwInit.lua:41>                                  1320 ms       31.1%
    Scribunto_LuaSandboxCallback::getEntity                          960 ms       22.6%
    Scribunto_LuaSandboxCallback::find                               220 ms        5.2%
    Scribunto_LuaSandboxCallback::sub                                220 ms        5.2%
    type                                                             180 ms        4.2%
    (for generator)                                                  160 ms        3.8%
    Scribunto_LuaSandboxCallback::getExpandedArgument                140 ms        3.3%
    ?                                                                140 ms        3.3%
    clone <mwInit.lua:39>                                            100 ms        2.4%
    mw.executeFunction <mw.lua:498>                                   80 ms        1.9%
    [others]                                                         720 ms       17.0%
Number of Wikibase entities loaded: 1/400
-->
<!--
Transclusion expansion time report (%,ms,calls,template)
100.00% 6751.023      1 -total
 66.24% 4471.956    232 Vorlage:Internetquelle
 16.13% 1088.669      1 Vorlage:Commonscat
 16.06% 1084.213      1 Vorlage:Wikidata-Registrierung
  6.91%  466.684    232 Vorlage:Str_len
  4.79%  323.522      2 Vorlage:Graph:Chart
  1.13%   75.984      6 Vorlage:Literatur
  0.79%   53.211     12 Vorlage:Webarchiv
  0.68%   46.056      1 Vorlage:Navigationsleiste_COVID-19-Pandemie
  0.63%   42.646      1 Vorlage:Erweiterte_Navigationsleiste
-->

<!-- Saved in RevisionOutputCache with key dewiki:rcache:206904507:dateformat=default and timestamp 20201226202457 and revision id 206904507.
 -->

Nach dem Mini-Diff jedoch plötzlich: Lua-Fehler überall:

<!-- 
NewPP limit report
Parsed by mw1403
Cached time: 20201226202430
Cache expiry: 2592000
Dynamic content: false
Complications: []
CPU time usage: 5.368 seconds
Real time usage: 5.513 seconds
Preprocessor visited node count: 81082/1000000
Post‐expand include size: 2097152/2097152 bytes
Template argument size: 366116/2097152 bytes
Highest expansion depth: 17/40
Expensive parser function count: 4/500
Unstrip recursion depth: 1/20
Unstrip post‐expand size: 489815/5000000 bytes
Lua time usage: 1.385/10.000 seconds
Lua memory usage: 52428793/52428800 bytes
Lua Profile:
    Scribunto_LuaSandboxCallback::getEntity                          760 ms       52.8%
    recursiveClone <mwInit.lua:41>                                   200 ms       13.9%
    Scribunto_LuaSandboxCallback::find                               200 ms       13.9%
    Scribunto_LuaSandboxCallback::sub                                100 ms        6.9%
    (for generator)                                                   40 ms        2.8%
    Scribunto_LuaSandboxCallback::getAllExpandedArguments             40 ms        2.8%
    <mwInit.lua:41>                                                   20 ms        1.4%
    chunk <Modul:WLink>                                               20 ms        1.4%
    split <mw.text.lua:210>                                           20 ms        1.4%
    ?                                                                 20 ms        1.4%
    [others]                                                          20 ms        1.4%
Number of Wikibase entities loaded: 0/400
-->
<!--
Transclusion expansion time report (%,ms,calls,template)
100.00% 4290.264      1 -total
 53.69% 2303.590    232 Vorlage:Internetquelle
 20.24%  868.164      1 Vorlage:Commonscat
 20.15%  864.515      1 Vorlage:Wikidata-Registrierung
  7.61%  326.413    173 Vorlage:Toter_Link
  6.49%  278.592      2 Vorlage:Graph:Chart
  3.65%  156.784    232 Vorlage:Str_len
  3.14%  134.594    173 Vorlage:Toter_Link/Core
  1.72%   73.939      1 Vorlage:Navigationsleiste_COVID-19-Pandemie
  1.63%   69.954      1 Vorlage:Erweiterte_Navigationsleiste
-->

<!-- Saved in RevisionOutputCache with key dewiki:rcache:206913822:dateformat=default and timestamp 20201226202424 and revision id 206913822.
 -->

Kurzform:

Post‐expand include size: 2097152/2097152 bytes
...
Lua memory usage: 52428793/52428800 bytes

Ich glaub, da hats was. Ist das ein bekanntes Problem und vielleicht schon in Arbeit? --Colazivi (Diskussion) 21:43, 26. Dez. 2020 (CET)

Vor allem: Wo kommen denn die auf einmal her?
  7.61%  326.413    173 Vorlage:Toter_Link
...
  3.14%  134.594    173 Vorlage:Toter_Link/Core
Ich kann eine solche Einbindung nicht im Quelltext finden, geschweige denn 173 davon. --Colazivi (Diskussion) 21:57, 26. Dez. 2020 (CET)

JavaScript[Quelltext bearbeiten]

Hallo! Eine Frage: ich möchte definierte Werte aus einer .js für mehrere weitere .js verwenden.

also ../file1.js müsste dann quasi (als ganz simples Beispiel) lauten:

var w = 'wert1';
var x = 'wert2';
return();

Wie übergebe ich diese Werte dann an andere JavaScript-files zu weiteren Verarbeitung?

Danke sehr, – Doc TaxonDisk. 11:36, 13. Jan. 2021 (CET)

Ich bin sicher kein JS-Experte, aber wenn du file1 vor den anderen Dateien lädtst und in diesen im Mainscope auf die Variablen zugreifst, dürfte der Zugriff direkt möglich sein. Sauberer ist wahrscheinlich export/import. Gruß, -- hgzh 12:45, 13. Jan. 2021 (CET)
Der Mainscope heißt global namespace.
  • Der Zugriff darauf so ohne Weiteres könnte irgendwann mal unterbunden werden.
  • Dort reinzuschreiben gilt als unhöflich, genauer pollution of the global namespace.
  • Es gibt zurzeit nur fünf Bezeichner, einschließlich Aliasse, die seitens Wiki-Seiten dort was zu suchen hätten, für nur drei Objekte.
Der saubere Weg verwendet: mw.hook()
  • Die schreibenden Skripte bilden ein Objekt und weisen Komponenten über die Bezeichner zu.
  • Das wird dann mit mw.hook(MeineUnverwechselbareID).fire(o) losgeschickt und kommt in den lesenden Skripten an als mw.hook(MeineUnverwechselbareID).add(fetch) und die Funktion fetch(apply) kennt dieses Objekt apply und kann es auswerten.
Wann was geladen würde ist dabei egal.
  • Es gibt ohnehin keinerlei Zusicherung, in welcher Reihenfolge welche Skript-Ladeanweisung durch den Browser tatsächlich ausgeführt würde; das sind heutzutage parallele Prozesse, und je nach Alter im Cache und Netzwerklaufzeit und sonstiger Auslastung ist die wirksame Reihenfolge völlig beliebig.
export import könnte bei Wikipedianern Browserkompatibilitätsprobleme bekommen.
Interessant wäre der Fall, dass mehrere Absender aktiv würden; was genau soll dann passieren?
VG --PerfektesChaos 15:23, 13. Jan. 2021 (CET)

Spezial:LintErrors/obsolete-tag[Quelltext bearbeiten]

Kann ich die Suche irgendwie auf eine bestimmte Seite anwenden, z.B. meine Benutzerseite? Angezeigt wird dort "Lint-Fehler: Veraltete HTML-Tags 1". Leider steht aber nichts konkretes dabei. Wenn wenigstens dieser veraltete Tag noch hingeschrieben würde, aber so such ich mich ja dämlich. Ist das sinnvoll? Liebe Grüße – Doc TaxonDisk. 12:17, 14. Jan. 2021 (CET)

Per API gibt's mehr Infos: https://de.wikipedia.org/w/api.php?action=query&list=linterrors&lntpageid=988283 -- hgzh 12:26, 14. Jan. 2021 (CET)
Verwende einfach das →LintHint-Tool. Das hilft bei der Suche. Ansonsten kannst du die Listen nach Namensräumen durchsuchen oder ans Ende springen Benutzer Diskussion letzte Seite da steht auch welches Tag gemeint ist. Beim Fehler dann auf Bearbeiten klicken. --Liebe Grüße, Lómelinde Diskussion 14:19, 14. Jan. 2021 (CET)
gut, dabei soll es also um ein veraltetes Font-Tag gehen, zu finden ist da sowas aber nicht. Einer sagt hier nicht die Wahrheit, das Tool, die Seiteninformationen oder ich. – Doc TaxonDisk. 15:59, 14. Jan. 2021 (CET)
Wenn du bearbeiten anklickst landest du genau auf der Stelle wo dieser Text steht Es wäre noch möglich mit size=<font size="+1">+1 ✉</font> und dort ist das font unmaskiert ich meine sogar, dass ich dir das auch auf deine Disk geschrieben hatte Spezial:Diff/207415018/207417643 wo die Fehler zu finden sind. --Liebe Grüße, Lómelinde Diskussion 16:22, 14. Jan. 2021 (CET)
das LintHint-Tool funktioniert nur um Artikelnamensraum, hab ich das Gefühl ... – Doc TaxonDisk. 16:41, 14. Jan. 2021 (CET)
@Lómelinde: ich hatte jetzt von meiner Benutzerseite geredet, steht auch ganz oben. Die Diskussionsseite meinte ich jetzt gar nicht ... – Doc TaxonDisk. 16:44, 14. Jan. 2021 (CET)

Das ist natürlich schwieriger zu lösen da du das vermutlich über einen eingebundenen Baustein dort verbaut hast. Versuch es mal damit Benutzer:Doc Taxon/Wikipe-tan da ist ein font drin. --Liebe Grüße, Lómelinde Diskussion 16:53, 14. Jan. 2021 (CET)

vielen Dank, – Doc TaxonDisk. 17:42, 14. Jan. 2021 (CET)
Immer gern, du verstehst jetzt sicher auch, wie schwierig es manchmal ist die Fehler zu finden und zu beheben. Hier habe ich nun das Limit der Einträge auf 5000 erhöht und so lange nach Unterseiten von dir gesucht, bis ich diese gefunden hatte. :-)  --Liebe Grüße, Lómelinde Diskussion 17:47, 14. Jan. 2021 (CET)

Font-Problem bei der Formeldarstellung[Quelltext bearbeiten]

Auf vielen Matheseiten ist mir aufgefallen, dass Minus-Zeichen in den Formeln fehlen. Diese erscheinen zwar bei Vergrößerung der Schriftgröße. Aber bei sonst normal lesbarer Schriftgröße verschwinden die Minuszeichen. Die Höhe des Striches im Minuszeichen scheint in dem verwendeten Fond zu klein zu sein, so das es zu dem Problem kommt. (nicht signierter Beitrag von 149.203.254.236 (Diskussion) 12:36, 19. Jan. 2021 (CET))

Das ist ein bekannter Fehler des Chrome-Browsers, siehe Phabricator:T269222. --FriedhelmW (Diskussion) 12:48, 19. Jan. 2021 (CET)

Move the coordinates below the page title line[Quelltext bearbeiten]

Hello and belated happy Wikipedia birthday!

We (the Wikimedia Foundation Web team) need to move the geographic (and galactic) coordinates under the page title line for a part of the Vector skin users:

  • The move of the coordinates will only be visible for those who use the new version of the Vector skin. From the editing perspective, and for those who don't use our modern Vector, nothing will change. It's only a visual change about where the coordinates will be displayed.
  • Most large and mid-sized wikis have the coordinates below the line.
  • We will rearrange other indicators (such as the page protection icons) as well. We will make sure nothing overlaps or is in conflict with other icons.

In our new version of Vector, above the page title line, there will be buttons and/or links allowing to switch between the languages. Uncheck Verwende klassischen Vector in your Preferences to see the improvements we have already made and keep up with new ones. For more details about the Desktop Improvements project, see our page on MediaWiki.org.

Could we move the coordinates? What do you think? SGrabarczuk (WMF) (Diskussion) 02:03, 23. Jan. 2021 (CET)

@SGrabarczuk (WMF): I am pretty sure that nobody will mind, I certainly support the move! There has just been an extensive discussion about the positioning of coordinates in general (not displaying them in the mobile version is of course the biggest issue atm), nobody is happy about the current situation. So I think it can only get better! —XanonymusX (Diskussion) 15:50, 24. Jan. 2021 (CET)
How will you technically do the change? The current behaviour is realized locally via MediaWiki:Vector.css and the coordinates are, unlike plwiki, not part of the indicator area. -- hgzh 16:23, 24. Jan. 2021 (CET)
@XanonymusX: thank you! @Hgzh: technically, we will move the indicators and will check if everything is in order. We need volunteers to deal with the wikicode, to edit MediaWiki:Vector.css and possibly other pages if the current behaviour is realized anywhere else. SGrabarczuk (WMF) (Diskussion) 22:51, 25. Jan. 2021 (CET)
Okay, so that means we will have to move the coordinate position by ourselves. Thank you for notifying. -- hgzh 11:32, 29. Jan. 2021 (CET)

Umbrüche bei Glocken-Schlagton verhindern[Quelltext bearbeiten]

Hallo, wie werden in Tabellen wie hier Umbrüche an unerwünschter Stelle bei Ausdrücken für einen Glocken-Schlagton verhindert wie bspw.

  • 2.) fes′–as′–b′; fes′/b′

M. a. W.: Wie kann ein Ton+Apostroph+Bis-Strich umbruchgeschützt zusammengehalten werden. (Bisher wurde ein Zeilenumbruch eingeschoben, der bei breiteren Bildschirmen wiederum stört.) Danke, --Wi-luc-ky (Diskussion) 23:30, 23. Jan. 2021 (CET)

Nun ja, ohne das jetzt selbst in den konkreten Fällen ausprobiert zu haben, fallen mir auf die Schnelle zwei Möglichkeiten ein:
  • den Zeilenumbruch optional als &shy; eingeben (sofern ich die aktuelle „Lösung“ richtig verstanden habe)
  • Einsatz von {{Nowrap}}.
Ob es einen Strich von der Länge gibt, der umbruchgeschützt ist, müsste ich nachforschen, aber beim Zusammentreffen zweier Satzzeichen würde das (zumindest in Chrome) ohnehin nicht funktionieren. Gruß—XanonymusX (Diskussion) 15:58, 24. Jan. 2021 (CET)
PS: Das sind im Übrigen keine Apostrophe, was auch noch zu korrigieren wäre (vgl. WP:Redaktion Musik/Leitfaden Musikartikel#Typografie).

tools.wmflabs.org ⇒ toolforge.org[Quelltext bearbeiten]

Auf dieser Seite Spezial:Verbraucher_auflisten (wurde eben bei FzW verlinkt) sind noch zwei tools.wmflabs.org zu finden. Noch funktionieren die Weiterleitungen auf die neue Domain, aber wie lange noch? Könnte man das anpassen? --Wurgl (Diskussion) 21:29, 26. Jan. 2021 (CET)

Steht letztlich auf Wikipedia:Technik/Cloud #Domains – „alte URL sollen weiterhin unterstützt werden“
Heißt: Was bis zu einem Stichtag im Sommer 2020 einen Tool-Account hatte, ist registriert und als URL-Weiterleitung eingerichtet (um 650) und soll auf „ewig“ zugelassen werden (könnte sein, dass in ein paar Jahren mal jemand den Traffic der vergangenen 12 Monate inspiziert und 300 tote Accounts rausnimmt).
Die Extrawurst behindert die physische Lastverteilung.
Ein triviales Umschreiben der Domain ist nicht möglich, wie du besser wissen müsstest als ich, weil der Pfad ja jetzt ein Segment kürzer ist und die Werkzeugprogrammierer auf den veränderten Pfad reagieren müssen und ihre Parameter dann nicht mehr wie zuvor ablesen können. Du kannst ausprobieren, ob es anders geht, durch Widerrufen der Autorisierung und Neu-Autorisierung.
Perspektivisch sollten alle gepflegten Werkzeuge auf die Unterstützung ihrer eigenen Subdomain migrieren.
VG PerfektesChaos 21:38, 27. Jan. 2021 (CET)

API-Anfragen Limits LogIn[Quelltext bearbeiten]

Hallo, ich möchte gerne über externe selbst geschriebene JavaScript-Skripte API-Abfragen tätigen. Ich will ausdrücklich keine automatisierten Edits ausführen.
Angedacht sind Abfragen größerer Anzahl in Wiki, Commons, Data und Meta. Einzelne Abfragen habe ich bereits realisiert, bin jedoch recht schnell auf den Empfangsstatus 429: 'Scripted requests from your IP have been blocked' gestoßen.
Mit der Aufforderung eine m:User-Agent policy zu nutzen bin ich überfordert.
Es geht wohl darum sich als 'unschädlich' zu authentifizieren? Ist damit mw:API:Login gemeint?
Führt mein Weg über einen eigenen Bot? Dort ist von 5 Bearbeitungen pro Minute die Rede - gilt dieses Limit auch für lesende API-Anfragen?
Letztlich gäbe es noch den Weg über externe Packeges (z.b.: https://www.npmjs.com/package/wikijs). Allerdings weiss ich nicht ob dort auch eine Authentifizierung nötig ist wie dort Limits bei Anfragen greifen.
Ursprünglich wollte ich mich direkt mit der API auseinandersetzen und vorerst nicht mit fertig implementierten Packages arbeiten.
Wäre nett wenn ein Erfahrener ein paar klärende Worte oder einen Ratschlag für mich hätte - Vielen Dank im Voraus. --Mrmw (Diskussion) 23:10, 1. Feb. 2021 (CET)

Setzt du denn einen passenden User Agent? Und wie viele Anfragen (und wie viele pro Minute) waren es denn? -- hgzh 15:30, 2. Feb. 2021 (CET)
@Hgzh: nein ich setze keinen Agent, weil mir nicht einmal klar ist welche Informationen dieser beinhalten müsste und nicht in welchem Format - muss ich meinen Accountnamen und PW angeben?
setze ich diesen Agent in jede URL als API-Anfrage? Wie müsste ich beispielsweise diese URL erweitern um ihr diesen Agent mitzugeben?
https://meta.wikimedia.org/w/api.php?action=query&format=json&prop=iwlinks&iwprefix=d&iwlimit=max&titles=meineZielSeite
Die Anzahl der Abfragen hängt auch davon ab welche Möglichkeiten ich dann letztendlich mit der API habe. Ich habe in dieser Sache leider überhaupt kein Gefühl - allerdings kommen mir ein paar Abfragen pro Minute sehr sehr wenig vor oder ist meine Einschätzung falsch? Danke --Mrmw (Diskussion) 23:04, 2. Feb. 2021 (CET)
Der User-Agent muss im Header der HTTP-Anfrage gesendet werden (vgl. den oben von mir verlinkten Artikel und die User-Agent-Policy) und sollte Kontaktdaten (nicht Kontendaten!) des Anfragenden enthalten, bspw. de:User:mrmw for testing purposes. Anfragen ohne User-Agent werden zeitig zurückgewiesen. -- hgzh 23:11, 2. Feb. 2021 (CET)

@Hgzh: unten mein reduzierter Code ohne Schleifenlogik - kannst du mir sagen an welcher Stelle ich was verändern muss damit es funktioniert? So wird der User-Agent offensichtlich nicht erkannt und beim elften request mit der genannten fehlermeldung abgebrochen

const fetch = require('node-fetch');
const Headers = require('header');
let header = new Headers({"User-Agent": "de:User:mrmw for testing purposes"})
(async () => {
    while (!eoq) {
        const response = await fetch(urlCont, {
            method  : 'GET', 
            headers : header })
})()

--Mrmw (Diskussion) 22:11, 7. Feb. 2021 (CET)

Sieht erstmal nicht falsch aus. Wenn's immer noch nicht funktioniert, kannst du mal Api-User-Agent anstatt User-Agent probieren; das wäre dann aber auch meine letzte Idee. -- hgzh 16:22, 10. Feb. 2021 (CET)
Leider funktioniert es so nicht. Vielleicht hat noch jemand einen Tipp für mich. --Mrmw (Diskussion) 08:10, 18. Feb. 2021 (CET)

Frage zu Weblinks auf mobile und Desktopversion[Quelltext bearbeiten]

Manche Webseiten liefern eine mobile Version und eine Desktopversion aus, wie z.B. https://m.imdb.com/title/tt0321058/ vs. https://www.imdb.com/title/tt0321058/ – manche entscheiden an Hand des User-Agent welche Seite ausgeliefert wird, zum Beispiel https://imdb.com/title/tt0321058/

Nachdem grob die Hälfte der Zugriffe auf die Wikipedia von mobilen Geräten erfolgt, könnte man diese URLs abhängig von mobil/desktop unterschiedlich ausliefern. Zumindest könnten Vorlagen (ja, das wäre nebenan) bei Seiten mit solch einer Weiche das www in der Url weglassen, das wäre natürlich individuell für jede Vorlage für externe Links zu prüfen. --Wurgl (Diskussion) 16:42, 10. Feb. 2021 (CET)

Das beträfe selbst unsere eigenen Seiten, etwa das Ergebnis von {{canonicalurl:}} im jeweiligen Kontext. Hier würde eigentlich gewünscht werden, dass diese URL im mobilen oder Desktop-Kontext generiert würden, während einer explizit angegebenen URL immer so gefolgt wird wie sie da steht (weil sonst überhaupt keiner mehr den Server wechseln könnte). Hingegen führt das Wikilink-Format immer in den aktuellen Seitenkontext.
Der Inhaltsbereich wird aus dem Cache entnommen, und den wird es bis auf Weiteres nur einmalig geben. In keinem Fall haben Vorlagen eine Möglichkeit darüber zu entscheiden, ob sie in einem mobilen oder Desktop-Kontext stehen, weil es nur einen einzigen expandierten Wikitext gibt. Lediglich Systemfunktionen wie {{canonicalurl:}} könnten im Moment der Auslieferung den momentanen Host einfügen.
Es müsste jemand ein Benutzerskript schreiben und es Interessenten anbieten, das für eine vom Maintainer zu pflegende Liste von Hosts die URL in der fertigen HTML-Seite der Leser diese von Desktop auf Mobil (Standardfall) oder notfalls von Mobil nach Desktop (dann bereits in unserem Weblink falsch hinterlegt) umschreibt.
Für beliebige Besucher ist das nix.
Wenn für alle und jeden, dann müsste das eine MediaWiki-Extension sein, global gepflegt werden und bereits das ausgelieferte HTML-Dokument mit den richtigen URL versehen.
VG --PerfektesChaos 16:58, 10. Feb. 2021 (CET)
Mir geht es nur um externe Links. Eben wie im Beispiel oben mit der IMDb. Dass es nicht gar so einfach ist, ist mir schon klar. Da müssten entweder getrennte Caches für desktop/mobil eingerichtet werden oder ein spezielles Postprozessing unmittelbar vor der Auslieferung der Seite.
Alternativ könnte man für Webseiten mit so einer Weiche eine www-lose URL eintragen, bzw. bei den Vorlagen eine solche www-lose aus den Parametern basteln. --Wurgl (Diskussion) 17:27, 11. Feb. 2021 (CET)

Klassische Diff-Ansicht mit Darstellungsfehler arabischer Buchstaben[Quelltext bearbeiten]

Hallo, in der klassischen Diff wird der arabische Buchstabe Ḥā' in der medial verbundenen Form falsch im Wortinnern als Finalbuchstabe dargestellt. In der verbesserten Diff ist es richtig, ebenso in der Artikelansicht und in der ZQ.

(Apropos ZQa: Es geht in den folgenden Bspp. nicht um die in den ZQs dargestellte, gelöste inhaltliche Frage arabischer Rechtschreibung, sondern nur um die Darstellung im Diff selbst!)

Vgl. in den Diffs der Editfolge:

  • Diff-1 (alt/neu richtig)
  • Diff-2 (alt/neu richtig)
  • Diff-3 (alt richtig الكحول, neu falsch الكح ول[1]; nach Einfügung eines Waw و erscheint in der Diff nach sehr kurzer Anzeige des richtigen auf dem Bildschirm das finale )

FF 85.0.2 (64-Bit).

  1. Leerzeichen vor Waw و in dieser Disku rein technisch zwecks Demonstration bedingt, andernfalls wird das Ḥā' medialisiert.

Gerne Erklärungen oder Rückfragen. Danke, --Wi-luc-ky (Diskussion) 01:45, 11. Feb. 2021 (CET)

  1. Allgemein gilt immer: H:RTL#UBA.
    • Browserabhängig, ob und wie UBA hier wirkt.
    • Auch sonst Angelegenheit des Browsers, als was die Zeichenfolge dargestellt würde.
  2. In Spezial:Diff/208678610 gab es jedoch eine Veränderung, weil vor dem spanischen ein Zeichen in das arabische Wort eingefügt wurde.
  3. Sollte der Diff-Algorithmus HTML-Tags an Wortgrenzen einfügen, kann dies die bidirektionale Darstellung unserer Seiten stören, oder diese HTML-Begrenzung eine Wortgliederung und Wort-Enden beeinflussen.
  4. Im Übrigen ist der dargestellte automatisiert generierte Byte-Schnipsel kein formvollendeter Text, und ob der hybriden Situation (RTL eingebettet in LTR) kann da immer mal was seltsam aussehen.
VG --PerfektesChaos 15:59, 11. Feb. 2021 (CET)

Rauswurf[Quelltext bearbeiten]

Seit ein paar Tagen werde ich während der mutmaßlichen rush hour wie außerhalb (zum Beispiel eben jetzt wieder beim Versuch, dieses Beitrag abzusetzen) beständig abgemeldet. Geht das mehr Mitarbeitern hier so? Was ist da los? --Silvicola Disk 05:40, 16. Feb. 2021 (CET)

Bist du Firefox-Nutzer? -- hgzh 10:21, 16. Feb. 2021 (CET)
Ja. --Silvicola Disk 10:40, 16. Feb. 2021 (CET)
Klick mal in der Adressleiste ganz links auf dieses Schutzschild-Icon und deaktiviere den „verbesserten Schutz vor Aktivitätenverfolgung“. Der grätscht wohl ab und an in den SUL-Prozess rein. -- hgzh 10:46, 16. Feb. 2021 (CET)
Danke, werde ich tun! --Silvicola Disk 11:00, 16. Feb. 2021 (CET)
Zusätzlich würde ich alle Blocker für "wikipedia" abschalten bzw. ihre Ausnahmeregeln einstellen (also AdBlock, Ghostery, PrivacyBadger u.ä.). Evtl. auch für "wmflabs" freigeben (Tools), weil Blocker dort wichtige Elemente unterdrücken könnten.
Übrigens: Vor allem AdBlock unterdrückt auf Presseseiten öfters die Angaben zum Datum und manchmal den Autorennamen, wenn die auf einer entsprechenden Seite in einem "Block" zusammen mit den Social-Media-Buttons stehen. Gruß --Chiananda (Diskussion) 00:59, 17. Feb. 2021 (CET)

Vorlagen die einen Listeneintrag generieren[Quelltext bearbeiten]

Hallo!

Screenshot von Marlon Brando#Weblinks in der Wikipedia App

Es gibt einige (wenige) Vorlagen, die für den Abschnitt "Weblinks" gedacht sind und diese Vorlagen generieren automagisch das Sternchen für einen Listeneintrag.

Immer wenn eine solche Vorlage so ein Sternchen generiert und der User bei eintragen in den Artikel schon so ein Sternchen davorgesetzt hat, sieht man in der Wikipedia-App eine leere Zeile mit einem Listenpunkt. Eine recht ausführliche Diskussion findet bereits in Vorlage Diskussion:Findagrave#*_in_Vorlage statt. Ich will hier mal fragen, ob ein Phabricator-Eintrag für die Wikipedia-App zu diesem Problem bekannt ist, oder ob man eher die (Haupt)autoren der genannten Vorlagen ansprechen sollte und dann mittels Bot die Artikel anpassen.

Dieses Problem tritt ausschließlich in der App auf. Die Mobile Ansicht und die Klassische Ansicht haben kein Problem. --Wurgl (Diskussion) 15:22, 23. Feb. 2021 (CET)

Das Ganze ist ein Hack, den sich um 2007 mal in der enWP irgendwer ausgedacht hatte und als superquelltextsparende Erfindung dort verbaut worden war, und die sich dann auch hier ein paar Schlaumeier abgeguckt hatten.
  • Wir hatten es Anfang der 2010er hier aus allen unserer Vorlagen zurückgebaut.
  • Von der Kongressbio wusste ich gefühlsmäßig, ohne dass ich hätte sagen können welche genau das war. Irgendwas mit USA halt.
  • Und dann wusste ich noch von irgendwas mit USA.
  • Dass wir noch so viele rein deutsche Vorlagen hätten war mir nicht bekannt.
Die Geschichte nutzt die (traditionelle) Eigenschaft von Vorlagen aus, dass ein Zeilenumbruch vor das Ergebnis einer Vorlagenexpansion eingefügt wird, falls dieses Ergebnis mit *#;: beginnt.
Damit entsteht der nachfolgende Wikitext, falls mit Sternchen eingefügt worden war:
* Legitimer Eintrag
* Legitimer Eintrag
*
* Unser Hack
* Legitimer Eintrag
* Legitimer Eintrag
Das wird momentan in HTML umgesetzt:
<li>Legitimer Eintrag</li>
<li>Legitimer Eintrag</li>
<li class="mw-empty-elt"></li>
<li>Unser Hack</li>
<li>Legitimer Eintrag</li>
<li>Legitimer Eintrag</li>
Wie jetzt ein leeres <li> in einem Browser dargestellt oder durch Screenreader vorgelesen wird, ist undefiniert.
  • Es ist zwar kein ungültiges HTML, weil <li></li> zurzeit legitim ist; es ist in HTML jedoch völlig undefiniert, als was dies dargestellt werden soll: Als Aufzählungspunkt mit nichts dahinter, oder aber komplett weggelassen (erst recht wichtig für nummerierte Aufzählungen, die dann eins weiterzählen müssten).
  • Kann sein, dass die klassischen HTML-Browser es nicht anzeigen, während die in der App verwendete HTML-Maschine es ausweist. Kann jeder machen was er will.
Die Wikisyntax ist zurzeit nicht formal genug spezifiziert, um anzusagen, was ein loses Sternchen in der Zeile sein soll.
  • Der Parser nimmt es zur Kenntnis.
  • Er generiert aber schon mal class="mw-empty-elt".
  • Wahrscheinlich gibt es früher oder später Linter-Fehler für sowas.
@Phabricator: Da wir kaputte Wikisyntax im Artikel haben, können wir uns nicht über unerwünschte Darstellung einer nicht offiziell unterstützten Wikisyntax beschweren.
Alle Einbindungen ohne Sternchen an Stellen, wo ein Sternchen geboten wäre, sollten jetzt manuell oder bei größerer Anzahl mittels Bot mit einem Sternchen nachgerüstet werden.
  • Danach sollte es per Dump-Kontrolle einige Wochen später nachgeprüft werden.
  • Dann sollten alle entsprechenden Vorlagen zurückprogrammiert werden, wo dies gesichert möglich ist.
VG --PerfektesChaos 18:15, 23. Feb. 2021 (CET)
Wobei (laut Browser/Developer Tools) dieses class="mw-empty-elt" die Eigenschaft "display: none;" hat. Irgendwie kommt das aber bei der App nicht an.
Übrigens hat einer unserer User sowas auch in die enWP gebracht: en:Template:Autobahnatlas Und in en:Bundesautobahn 49 tritt das Problemchen auch auf. --Wurgl (Diskussion) 19:05, 23. Feb. 2021 (CET)

Es scheint doch einen Eintrag beim Phabricator wert zu sein. Hier ist folgendes im Quellcode:

* 1980 wurde die weltweit erste digitale …
*
* 1982 haben [[Stanford Ovshinsky|Stanford R. Ovshinsky]] …
Also ein leerer Listenpunkt. Den sieht man am Desktop und in der mobilen Version nicht, die App zeigt den aber an. Ich hab die in meiner Fehlerliste, werte die aber nicht aus (Sprich: keine Fehlerliste). 1613 solche Fälle gibt es. --Wurgl (Diskussion) 20:49, 23. Feb. 2021 (CET)

Keine Ahnung wie die obige Eingangsliste zu Stande kam, aber vollständig ist die bei weitem nicht. Aus dem Schachbereich fallen mir spontan Vorlage:FIDE und Vorlage:365chess ein, die das Sternchen standardmäßig enthalten.
Wir hatten es Anfang der 2010er hier aus allen unserer Vorlagen zurückgebaut. Die Aussage ist offensichtlich falsch, es reicht ein Gegenbeispiel, und das wäre Vorlage:FIDE. 84.137.71.106 22:31, 23. Feb. 2021 (CET)
Ich hab geschrieben: "Möglicherweise noch weitere". Die Liste ist durch Suche nach "<onlyinclude>*" zustande gekommen, mir war schon klar, dass es da noch weitere gibt, nur die Beispiele reichen um zu zeigen, dass es kein Einzelfall (hier: Findagrave) ist. --Wurgl (Diskussion) 22:57, 23. Feb. 2021 (CET)
<quetsch>Nö, du hattest geschrieben Möglicherweise noch weitere, die das Sternchen auf etwas komplexere Weise generieren. Und das ist bei den zwei Vorlagen definitiv nicht der Fall! Und schon die Eingangsbehauptung "Es gibt einige (wenige) Vorlagen" ist Unsinn, wenn du die Gesamtzahl gar nicht bestimmen konntest. Vorlage:AssembleiaDaRepública ist ein weiterer Fall mit einem einfachen Sternchen davor. Ich bin ja auch dafür, die Sternchen aus den Vorlagen zu entfernen, aber dann bitte alle Karten auf den Tisch, und nicht mit halbgaren Aussagen das Problem kleiner machen als es ist. 80.135.62.20 10:29, 24. Feb. 2021 (CET)
  • Es wurde Anfang der 2010er systematisch aus allen unserer Vorlagen zurückgebaut, derer habhaft zu werden war, und es wurde 2008 auf H:DBL dringend darum gebeten, das bleiben zu lassen. Wenn dabei irgendeine Vorlage übersehen wurde, die sowas gemacht hat, dann ist das der damaligen Lucene-Quelltextsuche zu danken; und die Herrschaften aus dem USA-Bereich, die ganz stolz darauf waren und wohl noch sind, immer alles genauso zu machen wie die enWP saßen auch schon immer ganz fest auf ihren enWP-Kopien.
  • Weder Vorlage:FIDE noch Vorlage:365chess erwähnen in ihren Dokus dieses Verhalten, und 2011 (im Rahmen der systematischen Suche) bzw. 2015 wurden zumindest in den Kopiervorlagen schon mal die Sternchen mitgegeben. Beide sind weder in der syntaktischen Gestaltung noch in ihrer Doku auf Premium-Niveau, aber das ist interne Angelegenheit der Schachler.
  • Wer Fotos links von Aufzählungspunkten anordnet, der bekommt auch leere Aufzählungspunkte hingerichtet.
  • phab:T275558
  • Es ist aber egal; ein leerer Aufzählungspunkt ist perspektivisch ein Linter auslösender Wikisyntax-Fehler, und diese Bastelei gehört bei uns ohne Hektik jedoch systematisch abgebaut.
VG --PerfektesChaos 23:46, 23. Feb. 2021 (CET)

Dateiversion Commons[Quelltext bearbeiten]

Hallo, hier ein Crosslink zu meiner Anfrage auf Commons:

Vielleicht kann jemand helfen - Danke --Mrmw (Diskussion) 19:54, 23. Feb. 2021 (CET)

Doppeltes Bild in der Wikipedia App[Quelltext bearbeiten]

Sorry wenn ich nerve, aber mir fallen so ein paar Sachen auf. Die App zeigt zwei Bilder an. Das obere ist wohl das als 'pageimage' gekennzeichnete und dann kommt der Artikel, wo es nochmals angezeigt wird.

Kann man diese Doppelbildanzeige irgendwie unterdrücken? Diese doppelte Anzeige scheint in jedem Artikel mit einem Bild aufzutauchen, nicht immer ist diese Dopplung direkt untereinander. --Wurgl (Diskussion) 16:37, 24. Feb. 2021 (CET)

Das erste Bild ist im Allgemeinen ein Ausschnitt aus dem zweiten. Du kannst die Anzeige von Bildern generell deaktivieren. Oder einen Task auf Phabricator schreiben. Gruß --FriedhelmW (Diskussion) 18:14, 24. Feb. 2021 (CET)
Irgendeinen Trick gibt es wohl. en:Huzhou (zufällig erwischt) zeigt die Nachtaufnahme aus der Infobox in der App. Die Infobox selbst ist aber in der App nicht zu sehen, nur die darunter mit "Transcriptions [Ausklappen]" sehe ich. Es gibt also eine Möglichkeit diese doppelte Anzeige zu unterbinden, ob das nun sinnvoll ist, ist eine andere Frage. --Wurgl (Diskussion) 18:43, 24. Feb. 2021 (CET)
Ich glaube, das liegt in dem Fall aber an phab:T270981 (Infobox steckt in einem div, dank stack begin) und ist ein Bug, kein Feature. Sogar ein relativ gravierender, in meinen Augen, aber auf Phabricator gilt es als low priority, wohl einfach, weil App-bezogen. Und wie ich gerade sehe, scheint sich das Problem mittlerweile auch noch auf die iOS-App ausgeweitet zu haben, na großartig! Werde gleich mal den Task aktualisieren.–XanonymusX (Diskussion) 00:28, 25. Feb. 2021 (CET)

Verschieben Mobil[Quelltext bearbeiten]

Warum kann man auf der mobilen Wikipedia Webseite keine Artikel verschieben? Ist das beabsichtigt oder einfach noch nicht programmiert? Pintsknife (Diskussion) 23:30, 24. Feb. 2021 (CET)

Ist leider selbst in der erweiterten mobilen Version noch immer nicht Teil der Toolleiste, obwohl schon länger gewünscht. Einen Workaround gäbe es: Du kannst dir über dein Common.js den Link zu [[Spezial:Verschieben/<Artikelname>]] links in der Werkzeugleiste einfügen lassen, der taucht dann auch in der Minerva-Toolleiste auf, wenn du die erweiterten mobilen Bearbeitungen aktiviert hast.–XanonymusX (Diskussion) 00:41, 25. Feb. 2021 (CET)
@Pintsknife: Falls du’s ausprobieren möchtest, so ungefähr habe ich mir das vorgestellt:
// Verschieben-Link in Werkzeugleiste
mw.util.addPortletLink(
	'p-tb',
	mw.util.getUrl( 'Spezial:Verschieben/' + mw.config.get('wgPageName') ),
	'Verschieben',
	't-move-page',
	'Seite verschieben'
);
Wenn du das auf Spezial:Meine Benutzerseite/common.js einfügst, erhältst du einen zusätzlichen Verschieben-Link links unter „Werkzeuge“, der dann auch in der erweiterten Mobilversion über die Werkzeugleiste (unter den drei Punkten) verfügbar ist. Könnte man auch noch für weitere Tools machen. Gruß–XanonymusX (Diskussion) 01:25, 1. Mär. 2021 (CET)

Infoboxfehler - permanenter Eintrag[Quelltext bearbeiten]

Hallo zusammen,

beim Bearbeiten des Artikels: Meckenbeuren (https://de.wikipedia.org/wiki/Meckenbeuren) ist mir aufgefallen, dass in der Infobox das Feld "Einwohner" sowie der angehängte Einzelnachweis nicht bearbeitet werden kann. Selbst wenn ich die gesamte Infobox Vorlage neu einfüge bleibt die Einwohnerzahl bestehen. Diese ist allerdings nicht mehr aktuell. Im Wikicode konnte ich dort keinen "Fehler" feststellen.

Bei Rückfragen gerne melden.

Lukas -- Draggle (Diskussion) 20:32, 5. Mär. 2021 (CET)

Des Rätsels Lösung verbirgt sich in Fußnote 1, Link „Hilfe dazu“. Das führt zu Wikipedia:WikiProjekt Kommunen und Landkreise in Deutschland/Einwohnerzahlen. Kurz gesagt: In der Infobox-Vorlage sind – auch ohne dass man das sieht – weitere Vorlagen enthalten, und die enthalten die entsprechenden Daten. Es ist aber nicht gewünscht, die Daten in der Vorlage zu ändern, weil diese Daten koordiniert en bloc geändert werden. Das hat den Vorteil, dass alle Daten auf demselben Stand sind. Gruß --Schniggendiller Diskussion 20:38, 5. Mär. 2021 (CET)

Ping bei verlorenen Sitzungsdaten[Quelltext bearbeiten]

Hallo! Kommt es beim Veröffentlichen zur Fehlermeldung "Sitzungsdaten verloren", kann man bei einem zweiten Klick auf Veröffentlichen doch noch speichern. Allerdings funktioniert dann die Ping-Routine nicht mehr. Lässt sich das technisch lösen? – Doc TaxonDisk. 11:36, 16. Mär. 2021 (CET)

Darstellung unter Android[Quelltext bearbeiten]

Ich beobachte eine fehlerhafte Darstellung, die bei mir nur unter Android auftritt (in der WP-App aus dem Play-Store):

Rufe ich die Seite "Teufelsbrücke" auf (eine Begriffsklärungsseite), dann erscheint sie unter Android anders als unter Debian/Linux und unter iOS.

Diese Seite besteht im wesentlichen aus zwei Listen, zuerst die deutschsprachigen und dann die übersetzten Namen. Unter Android kommt bei mir die zweite Liste zuerst, wohl fehlerhaft.

--Bernhard Ganter (Diskussion) 17:31, 20. Mär. 2021 (CET)

Kann ich auch für die iOS-App bestätigen! Na grandios, noch so ein verunglückter Versuch von MoveFirstParagraph. Ich schau mal, ob das schon bekannt ist. Danke fürs Melden! Gruß—XanonymusX (Diskussion) 18:01, 20. Mär. 2021 (CET)

Future of FlaggedRevs (Pending Changes) extension[Quelltext bearbeiten]

Hilf bitte mit, in deine Sprache zu übersetzen

Hello, I’m posting this here because this wiki has FlaggedRevs (Pending Changes) enabled.

This extension is one of the oldest extensions we have in production and currently does not have a maintainer. FlaggedRevs has been the cause of several incidents and visible regressions, especially because software decays and our technology constantly changes.

Another problem with this extension is its scope. While most of its functionalities are not enabled at Wikimedia, or are enabled on a very small set of wikis only (e.g. "multiple dimensions" was enabled only on Hebrew Wikisource, and they agreed to disable it). This has made maintaining the extension a tall order (more of a nightmare). In other words, this extension does too many things, and none well.

To move forward, barely used functionalities of this extension will be removed. Such as: support for multiple dimensions (like “style” and “tone”), multiple tiers (“quality” and “pristine”), several one of its special pages (ProblemChanges, ReviewedPages, ReviewedVersions, QualityOversight), and more. This will make it less of a burden to start maintaining and improving the main functionalities. The user interface will have only one mode in the future (currently it has four).

You can check this Phabricator ticket for more information about functionalities being removed: phab:T277883

These removals would simplify its logic drastically, and enable us to rework its old interface, fix several deprecated dependencies that this extension is the last to block their removal of (like the "action=ajax" API), and reduce the number of issues/incidents/regressions that can be caused by this extension.

Most users of wikis that have this extension enabled (including English Wikipedia and German Wikipedia) won't see any difference. Wikis will still be able to use multiple "levels" (but not multiple "tiers") and will still be able to enable pending changes for whole namespaces, or on a group of pages only (otherwise known as “protect mode”). Those features will not be removed.

To follow the discussion around this, take a look at T185664.

Thank you for understanding and sorry for any inconvenience. Ladsgroup (talk) 18:17, 23. Mär. 2021 (CET)

Stellungnahme:
  • Kann ich bestätigen; für uns wird sich durch den Wegfall ungenutzter 2008 mal geplanter Funktionalitäten nichts ändern.
  • Eine Entschlackung des ein Dutzend Jahre alten Codes, an dem viele moderne Weiterentwicklungen vorbeigingen, ist sehr ratsam.
  • Um das nicht sehr robuste Gebilde überhaupt wartungsfähig zu bekommen, sind Verschlankungen und teilweise auch Neuprogrammierungen nach heutigem Erkenntnisstand äußerst wertvoll.
@Ladsgroup:
  • Thanks for broadcasting.
  • Congratulations to the new maintainer. Much fun.
  • This review process is most important to enforce our quality demands on article contents. We do need this extension in robust and maintained state.
Greetings --PerfektesChaos 19:13, 23. Mär. 2021 (CET)
Seconded. We heavily rely on this extension here and I appreciate every work that's done for keeping it up to date and which can maybe fix some blockers in other areas. So thank you for maintaining FR. Regards, -- hgzh 23:13, 23. Mär. 2021 (CET)
+1. Have followed it closely on Phabricator, thanks for the work!--XanonymusX (Diskussion) 23:58, 23. Mär. 2021 (CET)

Vorschlag: Zeitzone (CET/CEST o.ä.) in "Versionsgeschichte" und bei Seitenunterschriften ergänzen[Quelltext bearbeiten]

Habe beobachtet, dass immer nach eine Zeitumstellung (Winter ↔ Sommerzeit) sich alle Zeiten in der Versionsgeschichte, und auch bei den Seitenunterschriften um eine Stunde ändern, z.B. diese (Seitenunterschift): "Diese Seite wurde zuletzt am 26. Januar 2021 um 15:05 Uhr bearbeitet." (Diskussion:Sonne). Ohne sinnvolle Zeitzonenangabe sehe ich das Risiko, dass Zeiten entsprechend vom Nutzer falsch interpretiert bzw. falsch verstanden werden. Zugegeben, die "falschen Zeiten" sind nicht besonders kritisch, aber immerhin sind etliche Zeiten dennoch falsch (um 1h versetzt), was ich im Jahr 2021 computertechnisch nicht mehr für zeitgemäß halte. Wenn ich davon ausgehe, dass zur Sommerzeit im Vergleich zur Winterzeit grob etwa gleich viele Artikel bei der Wikipedia geändert bzw. erstellt werden, dann sind offenbar derzeit immer 50% der Zeitangaben (wegen fehlender Zeitzonenangabe) ungewollt um 1h versetzt bzw. "falsch". Der genannte exemplarische Beitrag (Diskussion:Sonne) auf angegebener Seite wurde offenbar real um »14:05, 26. Jan. 2021 (CET)« (Winterzeit) erstellt, jedoch meint die Bildunterschrift (in der Sommerzeitphase): »Diese Seite wurde zuletzt am 26. Januar 2021 um 15:05 Uhr bearbeitet.« Ich hab das schon mehrfach beobachtet, dass sich die Zeiten in der Versionsgeschichte und den Bildunterschriften immer komplett (alle) um eine Stunde verschieben, wenn eine Winter-/Sommerzeitumstellung erfolgt. Ich halte es für angemessen, wenn - zumindest als Option für den jeweiligen Nutzer - die Zeitzonen mit angezeigt werden; diese Option konnte ich bisher nicht finden. Mag sein, dass bei der WP die jeweiligen Zeitzonen u.U. intern nicht mit abgespeichert wurden, jedoch sollte es möglich sein, wenigstens die aktuell verwendete Zeitzone bei der Anzeige von Uhrzeiten mit einzublenden. Zudem sehe ich hier eine zweistufige Implementierungs-Vorgehensweise: 1. verwendete Zeitzone (Lesezeitpunkt) einfach mit einblenden, das sollte technisch überschaubar einfach sein. 2. verwendete Zeitzone (Schreibzeitpunkt des jeweiligen Autors) abschätzen, ausrechnen, oder mit abspeichern, und dann mit anzeigen. Punkt 2 wäre m.E. technisch aufwändiger (könnte später erfolgen). --NeptunT (Diskussion) 06:55, 30. Mär. 2021 (CEST)

Ich fände es besser, wenn einfach die eingestellte Zeitzone auch wirklich umgesetzt würde, statt nur das danach aktuell geltende Offset zu allen Zeitangaben dazuzuzählen. --nenntmichruhigip (Diskussion) 14:20, 30. Mär. 2021 (CEST)
(BK)
Es ist erfreulicherweise nur ein Darstellungsproblem.
  • Die tatsächlichen Zeitstempel auf dem Server stehen in UTC.
  • Sonst wäre die englischsprachige Wikipedia längst kollabiert; deren Bearbeiter sitzen in Boston, Seattle, Sydney und London.
  • Deshalb kommt es tatsächlich zuweilen zu Seltsamkeiten, etwa wenn eine Zeitspanne von 90 oder 30 Tagen mit plus/minus einer Stunde aufscheint oder Effekte erst um ein Uhr morgens geschehen.
Die Zeitzone, nach der du begehrst, hast du dir selbst eingestellt, und sie gilt für dich persönlich, und ist für dich überall die gleiche, und bedarf deshalb keiner zusätzlichen Kennzeichnung an jeder Uhrzeit.
  • Du kannst in Spezial:Einstellungen #mw-prefsection-rendering die von dir gewünschte Zeitzone einstellen.
  • Ich mutmaße, da steht noch +01:00 und damit Berliner Winterzeit.
  • Wenn du aber in Tunis sitzt, dann ist für dich das ganze Jahr Sommer und Winter, und dieses europäische Gehampel interessiert dich nicht.
  • Du müsstest jetzt wohl zu +02:00 wechseln, um glücklich zu werden.
  • Es gibt auch noch die Konfiguration, das von deinem Browser zu übernehmen. Dann wird hin und wieder beim Besuch gewisser Seiten, vielleicht beim Anmelden oder beim Öffnen dieser Einstellungs-Seite, die Uhrzeit auf deinem Browser irgendwie ermittelt und dann ggf. die Einstellung auf dem Wiki-Server geeignet angepasst. Was für Globetrotter. Der Browser erbt es vom Betriebssystem des Rechners, und das stellt sich automatisch für alle Anwendungen ein oder folgt den Geo-Koordinaten und lokalisiert den Laptop bei jedem Hochfahren neu per GPS.
  • Eine weitere Variante für uns wäre, die momentane Zeitzone des Wiki zu verwenden. Weil die deutschsprachige Wikipedia den Sitten von Berlin zugeordnet ist, hast du dann jetzt MESZ.
VG --PerfektesChaos 14:31, 30. Mär. 2021 (CEST)
Ich hab mir aber "Europe/Berlin" eingestellt, und nicht "MESZ", "CEST" oder "UTC+02:00". --nenntmichruhigip (Diskussion) 14:50, 30. Mär. 2021 (CEST)
Eben nochmal ausprobiert: Explizit "Europe/Berlin" einstellen funktioniert, "Standardzeit dieses Wikis nutzen (Europa/Berlin)" funktioniert nicht. Und "Vom Browser übernehmen" übernimmt wohl auch nur einmalig zur Zeit der Einstellung die Zeitzone vom Browser, womit man sich immerhin das runterscrollen sparen kann. --nenntmichruhigip (Diskussion) 14:55, 30. Mär. 2021 (CEST)
Hmm bei diesem API-Aufruf findet man timecorrection "System|120" und das passt wohl toll im Winter und nur im Winter. Gibts da keine Sommerzeit? --Wurgl (Diskussion) 15:06, 30. Mär. 2021 (CEST)
Um es kurz zu machen: Bei mir steht in Spezial:Globale_Einstellungen#mw-prefsection-rendering beim Abschnitt "Zeitunterschied" im oberen Feld "Europa/Berlin" und das untere Feld ist leer (das sieht man grau einen Hilfetext "Beispielwert: „-07:00“ oder „01:00“") und das klappt.
(PC: in https://persondata.toolforge.org/vorlagen/ mal ich serverseitig UTC rein und per Javascript wurschtelt dein Browser das auf die von dir auf dem Rechner eingestellte Zeitzone um, klappt auch) --Wurgl (Diskussion) 14:42, 30. Mär. 2021 (CEST)
"timecorrection":"System|120" ist Sommerzeit hierzulande, dewiki-Zeit, +02:00 = 120 Minuten plus.
"timecorrection":"ZoneInfo|120|Europe/Berlin" ist ebenfalls +02:00 = 120 Minuten plus.
Lokalpatrioten können auch tiefer scrollen, Europa/Vienna oder Europa/Zurich, kommt aber auch nichts anderes raus.
Winterzeit wäre +01:00.
UTC ist +00:00 per "timecorrection":"Offset|0" oder beliebige Minuten.
Die System und ZoneInfo führt PHP irgendwie nach, und irgendwie wird das über die ZoneInfo in die Benutzerdarstellung reinprojiziert; aber vermutlich ohne die Datenbankfelder zu ändern. Wurgl kann per SQL jedoch wohl nicht die wirklichen Inhalte auslesen.
Gemäß UTC±0 trotz Brexit gerade Sommerzeit in London: "ZoneInfo|60|Europe/London"
Wir wollen die Zeitstempel allerdings für alle Benutzer im HTML-Dokument haben und nicht nachträglich per JavaScript für die wo das aktiviert hätten.
VG --PerfektesChaos 15:42, 30. Mär. 2021 (CEST)
Oops! Ich mag dieses Normalzeit/Sommerzeit nicht. Ich komm da immer durcheinander. Jedenfalls: Ja, 120 Minuten ist Sommerzeit-Differenz.
Und per SQL komm ich an das nicht dran, nur per API (und da musste ich auch erst suchen). --Wurgl (Diskussion) 15:52, 30. Mär. 2021 (CEST)
Für Nachbuddler:
  • includes/MWTimestamp.php
  • Von der Benutzeroption, mutmaßlich durch Pipe in drei Segmente geteilt, betrachte das erste=[0].
  • Wenn dieses ZoneInfo lautet, dann nimm das dritte=[2] und schmeiße dies in new DateTimeZone().
  • DateTimeZone() ist aus der PHP-Bibliothek.
  • Falls übergebener Parameter in Liste unterstützter Zeitzonen dann nimm deren per CLDR in PHP hinterlegte Eigenschaften hinsichtlich Normalzeit und Regeln für Sommerzeit-Umschaltung und gib den Wert in Minuten zurück.
  • Relativ neue Angelegenheit, so insgesamt. War früher anstrengender, aber da konnte PHP das noch nicht selbst.
VG --PerfektesChaos 16:05, 30. Mär. 2021 (CEST)
Es gibt ja seit knapp 2 Wochen diesen Knopp "Meine Benutzerdaten dieses Projekts" in Spezial:Einstellungen. Da kommt etliches Zeugs unter anderem auch diese "timecorrection":
  • Wenn ich "Standardzeit dieses Wiki" auswähle, dann steht dort "System|120" und die Software nimmt die (?)Konfigurationsvariable(?) wgLocalTZoffset … falls die gesetzt ist, sonst nix.
  • Wenn ich "Europa/Berlin" nehme, dann steht dort "ZoneInfo|120|Europe/Berlin" und "Europe/Berlin" wird genommen. Die eine Stunde im Winter/Normalzeit bzw. 2 Stunden Sommer kommen dann aus den Tabellen des Betriebssystems. Dann wird "Offset" in den ersten Teil geschrieben und die 120 aus Teil 2 sind der Offset (wobei ich nicht so recht kapiere warum das gemacht wird und das mit DateInterval('PT120M') Da ist ein Bug in der Beschreibung "M" ist das sowohl Monat aus auch Minute).
  • "Vom Browser übernehmen" setzt nur "Europa/Berlin" im Menü, das macht nix anderes.
Ich hab allerdings Globale Einstellungen, also eine Einstellung für alle Wikis. Ich hab nix lokales.
Jetzt würde mich interessieren, was bei Nenntmichruhigip dort in diesen "Meine Benutzerdaten dieses Projekts" steht. Und ob der globale oder lokale EInstellungen hat. --Wurgl (Diskussion) 16:35, 30. Mär. 2021 (CEST)
Ich (nicht "der" btw) hab normalerweise andere globale Einstellungen, das zum Ausprobieren aber mittels lokalem Überschreiben geändert. Und nochmal zum Mitschreiben für PerfektesChaos, weil das glaube ich noch nicht so klar rüber kam: Das Problem ist, dass Standardzeit dieses Wikis nutzen (Europa/Berlin) und Europa/Berlin unterschiedliche Ergebnisse liefern. --nenntmichruhigip (Diskussion) 18:24, 30. Mär. 2021 (CEST)
Stimmt schon! NORMDATENCOUNT (Versionsgeschichte) zeigt bei "Standardzeit dieses Wikis nutzen (Europa/Berlin)" auch in den Wintermonaten 6:11 an, bei "Europa/Berlin" ist in den Wintermonaten 5:11, so wie ich es auch erwarte. Da sollte die Default-Systemzeit die Sommerzeit berücksichtigen. Nachdem die deutsche Sprache überwiegend in Europa gesprochen wird, mag das hier sinnvoll sein. Bei der englischen, spanischen, portugiesischen und und Wikipedia ist das wohl anders. --Wurgl (Diskussion) 20:10, 30. Mär. 2021 (CEST)
Na, dann mal Freitag abwarten.
  • Mit dem wöchentlichen Software-Update wird meines Wissens der Dämon neu gestartet.
  • Mag sein, dass die „Konstante“ noch den Wert von letzter Woche hat, und da war noch Winter gewesen.
In InitialiseSettings.php steht, dass dewiki in Europe/Berlin wohnt.
Danach ist für dewiki $wgLocaltimezone definiert und diese wird in MWTimestamp.php ausgewertet und der Funktionswert auf den momentan an diesem Ort mit dieser Ortszeit gültigen Wert gesetzt.
Und der sagt der Server-Zeit per setTimezone(), dass sie alle Operationen mit einem Zeitstempel auf Berlin beziehen soll.
Gleichartig setzt Setup.php mittels der PHP-Funktion date-default-timezone-set() dass alle Verwendungen ohne eine von irgendwem explizit angegebenen Zeitzone sich auf den momentanen Zustand in Berlin beziehen sollen.
Nur in der wgLocalTZoffset lebt möglicherweise noch die Zuweisung von letzter Woche weiter, weil es kein Setup gab und der Dämon durchlebte. Zumindest auf dem uns antwortenden Server; also für angemeldete.
VG --PerfektesChaos 21:26, 30. Mär. 2021 (CEST)
Das Problem ist doch gerade, dass die alte Zeitangabe fälschlicherweise in Sommerzeit ist. Wie soll ein auf Winterzeit hängengebliebener Wert das bitte verursachen können? --nenntmichruhigip (Diskussion) 13:19, 31. Mär. 2021 (CEST)

Durchaus vielen Dank für die Antworten und die Bearbeitung der Zeitzonenprobleme. Hiermit möchte ich nochmal darauf hinweisen, dass eine Option, die Zeitzone mit anzuzeigen (in Artikelunterschrift & Versionshistorie) angemessen und hilfreich wäre. Mag sein, dass manch eine oder einer die Zeitzonenangabe nicht sehen möchte. Eine Lokalzeitinformation ohne Zeitzonenangabe ist aber nun mal nicht sicher eindeutig, es gibt nämlich viele Lokalzeiten. Eine Zeitangabe wird wesentlich präziser, wenn die Zeitzone mit angezeigt wird (wenn der Nutzer dies möchte). Hinzu kommen mögliche Fehlkonfigurationen und Implementationsfehler, wie den vorhergehenden Kommentaren zu entnehmen ist. Ich bitte freundlich um Ergänzung der Option zur Zeitzonenangabe (auch zu 'Debugzwecken'), zwecks verwechslungssicherer Eindeutigkeit bei Zeitangaben. --NeptunT (Diskussion) 09:22, 31. Mär. 2021 (CEST)

Dem individuellen Nutzer werden aber alle Zeitangaben ohnehin in der selben Zeitzone angezeigt. Er sieht keine unterschiedlichen "Lokalzeiten". --j.budissin+/- 12:38, 31. Mär. 2021 (CEST)

Gerade unter WP:FZW#Zeitangabe von Beiträgen in der Wikipedia diskutiert. Diese Bearbeitung ist um 0:59 UTC erfolgt (API-Angabe). Nicht angemeldet (also mit Standardeinstellung) wird 3:59 (!) angezeigt. Das ist weder CET (UTC+1) noch CEST (UTC+2). --Count Count (Diskussion) 12:40, 31. Mär. 2021 (CEST)

Äh, nein. ich hatte UTC nicht gesehen, sorry --2003:D5:FF2B:FD00:B459:2C52:91CA:5B4C 15:34, 31. Mär. 2021 (CEST) Erster Eintrag wurde während der "Normalzeit" um 1.59 Uhr (!) getätigt und von mir zur Normalzeit gesehen (die Zeitzone ist unbekannt, aber alle Einträge auf allen WP-Seiten zeigten die korrekte Uhrzeit an). Der nächste Eintrag im Artikel erfolgte um 3.24 Uhr (Sommerzeit) und der vorhergehende Eintrag (vor Sommerzeitwechsel) war plötzlich auf 3.59 Uhr. Auch jetzt sind bei mir (immer noch unangemeldet) alle WP-Einträge zeitlich korrekt. Kann auch auf unterschiedlichen Rechnern provoziert werden: der Eintrag von 3.59 Uhr wurde vom Eintrag 3.24 Uhr revertet. --2003:D5:FF2B:FD00:B459:2C52:91CA:5B4C 15:07, 31. Mär. 2021 (CEST)
Wieso „nein“? Die Bearbeitung wurde um 1:59 CET getätigt. Eine Anzeige von 3:59 für diese Bearbeitung ist in jedem Fall falsch. --Count Count (Diskussion) 15:26, 31. Mär. 2021 (CEST)
sorry, Fehler meinerseits. Posting abgeändert... --2003:D5:FF2B:FD00:B459:2C52:91CA:5B4C 15:34, 31. Mär. 2021 (CEST)
Das Begehren, die Zeitzone (europäisch) dahinter zu vermerken, hat ohnehin einen kulturellen Bias, den eine globale Software nicht erfüllen kann.
  • Es unterstellt, dass alle Menschen, die in einer solchen Zeitzone +01:00 oder +02:00 leben würden, sich auf der Nordhalbkugel aufhalten.
  • Dieselbe Zeitzone gilt aber sowohl als Londoner Sommer wie auch in Tunis wie auch in Namibia.
  • Also sollen jetzt alle Südafrikaner erklärt bekommen, dass die Darstellung in „Mitteleuropäischer Zeit“ erfolgen würde? Die nennen sowas ähnliches dann aber lieber Westafrikanische Zeit und würden Kulturimperialisten und Kolonialisten, die ihnen ihre eurozentrische Sichtweise aufzudrücken versuchen, aus dem Land jagen.
  • Oder schreiben wir hier im Norden zum Ausgleich zukünftig nur noch Central Africa Time statt „Osteuropäische Zeit“?
  • Zeitzonen in Brasilien – die „Brasília-Zeit-1“ ist nicht das was ein Nordamerikaner als (AST) – Atlantic Standard Time bezeichnen würde. Weil, für Brasílianer liegt ihre Atlantikküste woanders, während die US-amerikanische Atlantikküste der Atlantic Standard Time sich mitten im Landesinneren befindet.
  • Soll nach deinen Vorstellungen in der spanischsprachigen Wikipedia die UTC−3 als (UYT) – Uruguay Standard Time oder als (ART) – Argentina Time oder als (CLST) – Chile Standard Time vermerkt werden?
Maximal kann hinter jede Uhrzeitangabe geschrieben werden:
  • (Ortszeit Vienna)
  • (Ortszeit Zurich)
  • (+00:00)
  • (Ortszeit London)
  • (+01:00)
Anders als die Signaturen, für die eine Regel der dewiki gilt, sind die Auflistungen der Versionsgeschichten unabhängig vom lokalen Wiki und müssen für alle Sprachversionen und vielsprachigen Wikis gelten.
VG --PerfektesChaos 19:16, 3. Apr. 2021 (CEST)

Vorschaubilder[Quelltext bearbeiten]

  1. Ich meine hier die Vorschaubilder, die man unangemeldet sieht, nicht irgendein Helferlein.
    Wenn man also unangemeldet mit der Maus auf eine Weiterleitung wie z.B. Alfred Jacobsohn geht, dann wird das Vorschaubild der Zielseite angezeigt. Passt hier überhaupt nicht. Bei manchen Weiterleitungen, wie Katie Crutchfield ist das Bild des Weiterleitungsziels durchaus sinnvoll.
    Nun kann man in MediaWiki:Pageimages-blacklist bestimmte Bilder ausnehmen, aber das wirkt global für alle Seiten. Hier wäre es wünschenswert das Vorschaubild nur für das Mouse-Over auszuschalten. Ich denke da gibt es noch nix, oder? Sowas wie ein neues magisches Wort würde ich erwarten.
  2. Bei Mouse-Over auf eine Weiterleitung wäre ein Hinweis auf Tatsache der Weiterleitung auch ganz nett. Das gibt es wohl auch nix.
  3. Manchmal wird in der Bildbeschreibung ein weiteres Bild verschachtelt. Beispiel: Helmut Schmidt Und manchmal wird dann eben dieses verschachtelte Bild als Vorschaubild angezeigt. Entsprechend sind in MediaWiki:Pageimages-blacklist momentan 8 solche Unterschriften eingetragen, die könnte man sich sparen, wenn verschachtelte Bilder nicht als pageimage eingetragen werden.

Sind zu einem der drei Punkte Einträge beim Phabricator bekannt? --Wurgl (Diskussion) 20:13, 11. Apr. 2021 (CEST)

phab:T91683 ist noch offen. --FriedhelmW (Diskussion) 20:47, 11. Apr. 2021 (CEST)
  • Mit class="noviewer" kann per Hilfe:Seitenvorschaubilder #Vorbereitung der Artikel ein unerwünschtes Bild abgeschaltet werden. Dann aber ganz, für alle Werkzeuge.
  • Mit Weiterleitungen hat das nichts zu tun.
    • In den allermeisten Anwendungen werden Weiterleitungsseite und Zielseite identisch behandelt.
    • Separates Verhalten von Weiterleitungsseite und Zielseite wird kaum möglich sein.
    • Für die Zielgruppe (externe Leser) ist der Umstand einer Weiterleitung völlig irrelevant und nur verwirrend.
    • Sowas interessiert nur interne Bearbeiter.
VG --PerfektesChaos 22:41, 11. Apr. 2021 (CEST)
Klar, die Weiterleitungen sind ein Low-Level Problem, das ist relativ selten. Die verschachtelten Bilder sind halt nicht so toll, die gibts schon öfter. --Wurgl (Diskussion) 00:01, 12. Apr. 2021 (CEST)

Beo bearbeiten: Es gibt hier zu viele Seiten zum Anzeigen.[Quelltext bearbeiten]

Ich bin gerade dabei, meine Beo auszumisten. Im normalen Editiermodus habe ich eine ganze Menge Benutzerseiten als zu löschen markiert und bekam daraufhin folgende Fehlermeldung:

Beobachtungsliste bearbeiten

Von Eloquenzministerium (Beobachtungsliste: Änderungen | normal bearbeiten | im Listenformat bearbeiten (Import/Export) | Beobachtungsliste leeren)

Zur Navigation springenZur Suche springen

Es gibt hier zu viele Seiten zum Anzeigen.

Zurück zur Seite Spezial:Beobachtungsliste.

Was kann man da machen?

Vielen Dank im Voraus vom Eloquenzministerium (Diskussion) 13:41, 17. Apr. 2021 (CEST)

Beispielsweise die Liste kopieren, die Einträge entfernen und überschreiben wie hier beschrieben. Hilfe:Beobachtungsliste#im Listenformat bearbeiten (Import/Export). Das müsste doch funktionieren, wenn nicht kopieren, ausmisten, Beo komplett leeren, und danach die bereinigte Liste einfügen. --Liebe Grüße, Lómelinde Diskussion 14:16, 17. Apr. 2021 (CEST)

Schönen Dank, das ist aber doch eher eine Notlösung. Ich nutze das Mouseover gern, um zu gucken, worum es da ging und habe auch schon mehrfach erfolgreich an die hundert Einträge auf einen Streich gelöscht. Wäre schön, zu wissen, wieviel zuviel ist, damit ich meine Arbeitsweise den Limitierungen der software anpassen kann. Eloquenzministerium (Diskussion) 15:00, 17. Apr. 2021 (CEST)

@Eloquenzministerium: (Keine exakte Antwort:) Also, an Deiner Stelle würde ich da mal kleinere Brötchen backen und mit 10 Löschungen anfangen, diese markieren und editieren. Dann etwas mehr probieren. In alten Zeiten galt: Sieben auf einen Streich. Ein paar mehr sollten heute aber schon gehen. ;-) hth, --Wi-luc-ky (Diskussion) 15:50, 17. Apr. 2021 (CEST)
Entwarnung: Die Löschung hat funktioniert, nur die Anzeige, wieviele Einträge gelöscht wurden hat wohl versagt. Wäre schön, wenn man die Fehlermeldung etwas weniger dramatisch gestalten könnte, aber deswegen werde ich mich nicht der traumatischen Erfahrung einer phabricator-Debatte aussetzen. Eloquenzministerium (Diskussion) 15:55, 17. Apr. 2021 (CEST)
Ein BOA kann MediaWiki:Watchlistedit-too-many ändern. --FriedhelmW (Diskussion) 16:15, 17. Apr. 2021 (CEST)
Eine Boa, auch beunruhigend, aber was ist ein BOA? Mach mich klüger ;-) . Eloquenzministerium (Diskussion) 17:01, 17. Apr. 2021 (CEST)
Ich zum Beispiel, siehe WP:BOA! ;) Wie sollte der Text denn besser lauten? Gruß—XanonymusX (Diskussion) 17:08, 17. Apr. 2021 (CEST)
Wobei diese Nachricht nach meinem Verständnis auch von normalen Admins bearbeitet werden kann.—XanonymusX (Diskussion) 17:11, 17. Apr. 2021 (CEST)

Den Meldungstext zu bearbeiten bringt nix.

  • Es gibt ein in die globale Software eingebautes Limit, das erfahrungsgemäß bei 50 zu liegen scheint.
  • Ist aber undokumentiert und mag sich jederzeit unangekündigt ändern.
  • Oben gab es den Tipp mit 10 Häkchen; ich würde mal drei, vier Dutzend zum Probieren anraten.
  • Der an den Server geschickte Auftrag wird bei zu vielen Häkchen zu lang und knackt an diversen Stellen Begrenzungen.

VG --PerfektesChaos 17:19, 17. Apr. 2021 (CEST)

Danke für die BOA-Aufklärung (bin hier halt kein Stammgast und dankbar für Beiträge, die ich verstehen kann) und das update des Glossars. Eine entschärfte Fehlermeldung sähe etwa so aus:
Die ausgewählten Einträge Deiner Beobachtungsliste sind gelöscht.
Leider waren es zu viele, um sie alle anzuzeigen.
Jedenfalls, wenn sichergestellt ist, daß zumindest die Löschroutine keine willkürlichen Limits hat. Ansonsten habe ich bereits ohne Fehlermeldung um die 80 Einträge auf einen Streich gelöscht (Ja, ich weiß, ich sollte in meiner Beo öfter mal feucht durchwischen...). Eloquenzministerium (Diskussion) 18:10, 17. Apr. 2021 (CEST)
Mir auch schon passiert, bester nichttechnischer Tipp: die Beo klein halten. Man muss nicht jeden Artikel im Auge behalten... :D MfG --Jack User (Diskussion) 18:12, 17. Apr. 2021 (CEST)
Besser wäre es, die Beo auf 1.000 Seiten zu beschränken - wenigstens für Neubenutzer, die Altbenutzer würden bei so einer Einschränkung sicher jammern. --Jack User (Diskussion) 18:14, 17. Apr. 2021 (CEST)
PC hat mit seinem Hinweis insofern recht, dass die Meldung in verschiedenen Zusammenhängen auftreten kann. Man muss also vorsichtig formulieren. --FriedhelmW (Diskussion) 22:58, 17. Apr. 2021 (CEST)

Fehlende End-Tags finden[Quelltext bearbeiten]

Hallo, im Link zu Seiteninformationen werden auch Lint-Fehler wie hier aufgelistet. Wie können da fehlende End-Tags gefunden werden? Tools? Bei Durchsicht nichts gesehen. Gruß, --Wi-luc-ky (Diskussion) 12:42, 20. Apr. 2021 (CEST)

Ist natürlich ein Käse, aber du kannst in der Liste durchblättern und dann findest du hier dass es um i bzw. '' geht. Aber ich sehe das auch nicht. --Wurgl (Diskussion) 12:53, 20. Apr. 2021 (CEST)
Siehe Hilfe:Wikisyntax/Validierung#GadgetBenutzer:PerfektesChaos/js/lintHint Allerdings ist es nicht immer trivial diese Fehler zu finden, weil sie manchmal innerhalb von Vorlageneinbindungen stehen. --Liebe Grüße, Lómelinde Diskussion 13:42, 20. Apr. 2021 (CEST)
Mit PCs Tool habe ich ein störendes {{!}} gefunden, danke Ló. Gruß --FriedhelmW (Diskussion) 18:39, 20. Apr. 2021 (CEST)
[//example.com ''Hier {{!}} mault Lint'']. --FriedhelmW (Diskussion) 20:23, 20. Apr. 2021 (CEST)
Vielen Dank euch allen für die Tipps und Fixes!
In Lint-Fehler: Fehlendes End-Tag wird in der Spalte Fehlendes End-Tag leider nicht erklärt, was die Kürzel (b, i usw.) bedeuten.
So kann nur gemutmaßt werden, dass etwa i das o. g. {{!}} sein könnte, da die obige Gleichsetzung mit " und der darauffolgenden Änderung in einem Lemma half ja nichts. Doch, aber nur halb: war einer von zween Fehlern! Dank und sry.
Eine Erklärung wäre hilfreich für die Hilfewilligen. (In der Übersichtsseite Lint-Fehler: Fehlendes End-Tag noch mehr Kürzel.)
Gruß, --Wi-luc-ky (Diskussion) 23:13, 20. Apr. 2021 (CEST)
Das sind HTML-Tags; <b></b> ist fetter Text (bold), i ist kursiv (italic) usw.—XanonymusX (Diskussion) 23:19, 20. Apr. 2021 (CEST)
Danke, XanonymusX, jetzt klar. Auch dass in dem erwähnten Bsp. erst 2 Lint-Fehler standen, also der eine von Wurgl und der andere von FriedhelmW behobene. Gruß, --Wi-luc-ky (Diskussion) 23:36, 20. Apr. 2021 (CEST)
Ich hab nix behoben. Ich hab nur probiert ob der weg ist. Dummerweise sieht man ja in der Vorschau die Linterfehler nicht. --Wurgl (Diskussion) 23:39, 20. Apr. 2021 (CEST)
@Wurgl: Das hier, die Entfernung von Anführungszeichen im Parameter Titel (s. Lómelinde dazu unten), hatte ich als reparierende Änderung verstanden. Und falls nicht {{!}} gleich 2 Fehler zugleich behoben hat, bleibt nur diese Deine Änderung übrig, die als wirksam in der Beseitigung der beiden Fehler angesehen werden kann. Deshalb mein Dankeschön, --Wi-luc-ky (Diskussion) 11:39, 21. Apr. 2021 (CEST)
Nein, da waren vorher zwei und nachher zwei. Und klar hat das {{!}} zwei behoben. Die Tüddelchen davor waren nicht beendet und die Tüddelchen danach ebenfalls nicht (bzw. waren nicht begonnen). --Wurgl (Diskussion) 12:39, 21. Apr. 2021 (CEST)

@ Wurgl, mit dem Tool kann man sich diese Fehler anzeigen lassen und es immer wieder starten bis alle Fehler weg sind (= grüne Anzeige). Das Auffinden ist nicht immer leicht, oftmals ist es aber gerade bei fehlenden Endtags so, dass beispielsweise das Kursivtag oder Fetttag mit Linkklammern verschachtelt ist.

Beipiel:

''[https//example.com Kursiv innen und außen'']
[https//example.com ''Kursiv innen und außen]''

Korrekt wäre

''[https://example.com Kursiv nur außen]''
[https://example.com ''Kursiv nur innen'']

Das löst dann immer gepaart zwei Fehler i aus. Wenn man das '' also verschiebt sind gleich zwei Fehler weg. Das kann auch passieren, wenn man versehentlich die Tags über zwei Parameter einer Vorlage oder zwei Zellen einer Tabelle spannt, aber auch, wenn man in einem bereits kursiven Parameter einer Vorlage einzelne Kursivtags setzt.

Beispiel: {{Internetquelle |url=https://example.com |titel=Der Seitentiten mit vergessenem Kursivtag am Ende'' |abruf=2021-04-24}}

Leider gibt es davon noch recht viele Fehler und es kommen auch täglich noch neue hinzu. Auch Zeilenumbrüche rufen derartige Fehler hervor, da alle Inlineelemente eigentlich immer in eine Zeile beginnen und enden müssen. Das gilt insbesondere für diese Hilfe:Tags#Inline-Elemente. --Liebe Grüße, Lómelinde Diskussion 08:21, 21. Apr. 2021 (CEST)

Schon klar, dass das Tool das kann. Ich meinte was andreas: Wenn also der Standard (also Wikipedia ohne Tools) auf Seiteninformation die Linter-Fehler anzeigt, dann hätte ich erwartet, dass diese Info auch in der Seitenvorschau angezeigt wird. Es ist schon etwas traurig, dass man dazu ein Tool braucht oder aber x Versionen abspeichern muss um irgendwann Erfolg zu haben.
Und nein, ich hab das nicht installiert. Wird mir zu viel. --Wurgl (Diskussion) 08:44, 21. Apr. 2021 (CEST)
Musst du auch nicht, bezüglich in der Vorschau anzeigen, das wäre sicherlich nett für diejenigen, die so etwas auch beheben wollen, alle anderen wären damit vermutlich überfordert. Aber wenn ich es richtig verstanden hatte, sollte irgendwann eine Umstellung erfolgen und danach würden diese Fehler dann dicke rote Meldungen verursachen, so ähnlich wie class="error" und dann möchte ich das Gemaule nicht hören, warum denn plötzlich alle möglichen Seiten rote Meldungen anzeigen. Zumindest habe ich es so verstanden, dass deshalb diese Listen angelegt wurden, um möglichst viele dieser Fehler schon vorab zu beheben. Und es sind in de:Wikipedia inzwischen nur noch wenige Hunderttausend Seiten übrig. Es gibt schon einige Benutzer, die sich aktiv darum kümmern es wird irgendwann nicht mehr viel übrig bleiben. --Liebe Grüße, Lómelinde Diskussion 09:58, 21. Apr. 2021 (CEST)
Die Male, wo mir Kursiv-Fehler gemeldet wurden, musste ich den ganzen Artikel nach '' durchsuchen und die Paarigkeit der Formatierung überprüfen, bis ich auf den Fehler stieß. Meist behebt eine Reparatur ja gleich 2 Fehler. Gruß --Chiananda (Diskussion) 02:10, 22. Apr. 2021 (CEST)

QS-Baustein-Eintrag löst ungesichtete Vorlage aus[Quelltext bearbeiten]

Siehe VLSI Technology: Vorgehen/Ablauf: 1. im Artikel QS-Baustein eingebaut, 2. dem neu erwähnten Link zur QS-Disk gefolgt und dort den Artikel eingetragen, und das löst dann 3. aus, daß auf der Artikelseite automatisch der "ungesichtete Vorlagen"-Baustein eingetragen wird (obwohl bei Sichtern alles automatisch gesichtet wird). Folgt man diesem Hinweis, soll die eigentlich schon gesichtete Seite nochmals gesichtet werden – der Eintrag auf der QS-Seite ist ohnehin ja auch schon auto-gesichtet ... irgend etwas wird hier unnötigerweise auf ungesichtet gestellt, obwohl gesichtet.

Auf der Artikelseite erscheint der Baustein:

Dies ist die gesichtete Version, die am 24. April 2021 markiert wurde. Es sind noch Vorlagen- und Dateiänderungen vorhanden, die gesichtet werden müssen.

Klickt man "Vorlagen- und Dateiendungen" an, erscheint dann:

Diese Version erneut sichten
Bitte sichte alle Änderungen (siehe unten), die seit der letzten stabilen Version getätigt wurden.
[Sichten] [Sichtung entfernen]
Vorlagen/Dateien wurden aktualisiert (nicht markierte Seiten sind in fett gekennzeichnet): Wikipedia:Qualitätssicherung/24. April 2021
--ProloSozz (Diskussion) 09:14, 24. Apr. 2021 (CEST)
Das Modul:Vorlage:QS-Antrag guckt nach, ob die Seite schon auf der QS eingetragen ist. Daher die Abhängigkeit. Gruß --FriedhelmW (Diskussion) 11:42, 24. Apr. 2021 (CEST)
@ProloSozz:
Das ist ein bekanntes und bereits gemeldetes Phänomen.
Der Inhalt unseres enzyklopädischen Artikels wird beeinflusst durch den Inhalt von Wikipedia:Qualitätssicherung/24. April 2021.
Damit fordern die Sichtungsregeln, dass nach jeder Veränderung der ungesichteten Seite Wikipedia:Qualitätssicherung/24. April 2021 durch einen Sichter überprüft werden muss, ob jene Veränderung keinen negativen Einfluss auf den Artikel hätte.
Ursächlich ist das per AGF kürzlich erstellte Modul:Vorlage:QS-Antrag und die darin enthaltene Anweisung getContent().
  • Das geht aber prinzipiell nicht auf diesem Weg mit dem ANR.
Dem Ersteller ist die Problematik bereits bekannt; du müsstest dich dorthin wenden.
VG --PerfektesChaos 15:17, 24. Apr. 2021 (CEST)

Extension:External Data[Quelltext bearbeiten]

Hallo! Ich teste mit der Vorlage:GlobalEdits gerade die Extension:External Data, die aber ausweislich der Liste mit Erweiterungen von Wikimedia hier gar nicht installiert ist. Die globale Editzahl kann man dann irgendwo substituiert einbinden, z.B. {{{{{|safesubst:}}}GlobalEdits|Uwe Martens}}, verarbeitet diese API-Abfrage (s. zum Vergleich die Abfrage für den lokalen Editcount). Das kann man dann u.a. auf CUA verwenden, wo ich gerade ein neues Tool eingearbeitet habe. Die Erstanmeldung könnte man so auch über die API abfragen und automatisiert eintragen, für den ersten Edit habe ich noch kein API-Call gefunden. Braucht es da erst ein riesen Prozedere a la "Technikwünsche", um so eine Extention zu installieren, oder kann das ein Sysadmin in Eigenregie machen? Eine andere Einbindung von Wikipedia-internen API-Calls gibt es ja scheinbar nicht. Die sonstige Vorlage:Editcount erzeugt ja nur einen Link, also für solche Zwecke unbrauchbar (bzw. gibt es ja offenbar für Spezial:CentralAuth keine API). -- Uwe Martens (Diskussion) 14:45, 25. Apr. 2021 (CEST)

Die Sysadmins aktivieren zusätzliche Erweiterungen nur im Zuge eines Community consensus, also nicht auf Anfrage einiger weniger. Im konkreten Fall könnte ich mir zudem vorstellen, dass Performance-Bedenken aufkommen könnten (ohne mir das genauer angesehen zu haben). Gruß, -- hgzh 18:05, 27. Apr. 2021 (CEST)
Danke für die Rückmeldung! Aber Performanceeinbußen? Bei dem Abruf der Wikipedia-eigenen API? Wohl kaum. Anderenorts diskutiert man groß über das Thema bessere Unterstützung von Geoinformationen, obgleich die ähnliche Extension Kartographer ja hier schon längst implementiert ist. Vielleicht schlage ich da die Extension:External Data einfach mal vor. Das wären dann zwei Fliegen mit, ähm, einer Extension. Sozusagen... Grüße, Uwe Martens (Diskussion) 02:23, 28. Apr. 2021 (CEST)
Der hier skizzierte Fall ist sicher einigermaßen unproblematisch, aber schon dein Vorschlag hier drunter erfordert ja Zugriff auf externe Dienste. Aber wenn du einen Versuch dazu starten möchtest, wäre ich nicht grundsätzlich dagegen. -- hgzh 13:01, 4. Mai 2021 (CEST)
Programmiertechnisch wäre so ein Datenabgleich mit einer einfachen if-Konstruktion zu lösen. Da bei der CAS-Abfrage ja nur ein einfacher Datenabgleich (keine Dateneinbindung) erfolgen soll, könnte man den CAS-API-Call auf true/false bzw. hilfsweise per Vorlage:Str find einen beliebigen String prüfen. Ein weiterer Anwendungsfall ist eben die Einbindung von Geo-Daten, die unter Technische Wünsche/Topwünsche groß diskutiert wird. Mein dortiger Vorschlag Einbindung via JSON API wurde zwar noch nicht kommentiert, aber immerhin auch von den dort aktiven WMDE-Mitarbeitern zur Kenntnis genommen. Dort, auf der Disk der Extension selber oder hier könnte man dann, sofern es mehrheitlich gewünscht wird, auch festlegen, welche externen URLs zur Einbindung in hiesige Wikiseiten zulässig sein sollen bzw. solche Beschränkungen softwareseitig als Bedingung zur Aktivierung der Extension (oder einer Kopie davon) setzen. PHP-seitig ist das ein Zweizeiler. Für den bloßen Datenabgleich könnte man nötigenfalls eine gesonderte Liste zulässiger URLs anlegen. Eine URL-Whitelist kann man für die Extension ja schon standardmäßig anlegen. Ich hoffe jedenfalls, die Diskussionen um die Aktivierung der Extension ziehen sich nicht allzu lang hin. -- Uwe Martens (Diskussion) 07:34, 5. Mai 2021 (CEST)

 Info: Hier haben wir ja mal ein Paradebeispiel für einen Anwendungsfall der Extension:External Data (Permanentlink). Konkret geht es um den Link aus einer Info-Box auf einen externen Datenbankeintrag, dessen Existenz vorher automatisiert zu prüfen wäre. -- Uwe Martens (Diskussion) 20:48, 3. Mai 2021 (CEST)

Was mach ich bei "suggestedvalues" falsch?[Quelltext bearbeiten]

Ich hab in der Doku der Vorlage Normdaten diese zusätzlichen Daten eingefügt. Aber per API sehe ich nix.

Okay, ich hab diesen Block von beta kopiert, dort liefert das API brav die Daten.

Hab das gemacht, weil Timur Vorkul (WMDE) das in Wikipedia:Technische Wünsche als erledigt markiert hat und zwar mit Datum vom letzten Donnerstag. Was mach ich falsch? --Wurgl (Diskussion) 17:24, 1. Mai 2021 (CEST)

Nix.
Vorlage Diskussion:TemplateData #Suggested Values
Die Normdaten-Doku steht bei mir auf der ToDo-Liste, und ich kümmere mich zu gegebener Zeit drum.
VG --PerfektesChaos 17:38, 1. Mai 2021 (CEST)
Aha! Okay. Melde dich bitte, wenn es soweit ist. --Wurgl (Diskussion) 17:49, 1. Mai 2021 (CEST)

@Wurgl: Danke für deine Frage und entschuldige bitte die späte Antwort. Der Grund hierfür ist nun auf der Projektseite beschrieben. Mit besten Grüßen --Timur Vorkul (WMDE) (Diskussion) 14:02, 27. Mai 2021 (CEST)

Ich verwende die Funktion (über die Vorlage) bspw. schon in Vorlage:Charttabelle (etwa die Ländercodes).—XanonymusX (Diskussion) 14:29, 27. Mai 2021 (CEST)
XanonymusX guck mal, auf den TemplateData-Block der Normdaten. Mit Iconchens ;^) Leider sind die nicht per API abrufbar, aber trotzdem hübsch.
Mein Problem am 1. Mai war, dass die Vorlage die diesen TemplateData-Block erzeugt hat, nicht alles intern weitergereicht hat. Das ist jetzt der Fall. --Wurgl (Diskussion) 16:39, 27. Mai 2021 (CEST)
Ja, da kann ich dann die Flaggen auch gleich noch einfügen. Wäre in der Tat schöner, wenn das gleich Teil der Erweiterung selbst wäre, aber besser so als gar nicht.—XanonymusX (Diskussion) 16:42, 27. Mai 2021 (CEST)

Autorenzählung von XTools[Quelltext bearbeiten]

Hallo zusammen! Was ich beschreibe, daran haben sich die Dienstälteren wahrscheinlich längst gewöhnt: Ich habe gerade im Artikel Metropolitanstadt Turin das Bandwurmwort Metropolitanbürgermeister als Amtsbezeichnung von Frau Chiara Appendino durch das noch längere Bandwurmwort Metropolitanbürgermeisterin ersetzt. Normalerweise würde ich das als +2Byte-edit ansehen, XTools attributierte mir 28 Bytes (27 Buchstaben, 1 davon Umlaut). Link: https://xtools.wmflabs.org/articleinfo-authorship/de.wikipedia.org/Metropolitanstadt_Turin?uselang=de. Eigentlich zu viel der Ehre. Gab es da mal eine Diskussion drüber? LG vom -- freshman Himbeerbläuling (Diskussion) 19:35, 6. Mai 2021 (CEST)

Ob es dazu schon eine Diskussion gab, weiß ich nicht, aber ich halte das eher für lässlich. Die Auswertung erfolgt eben auf Basis von Einzelworten, und, wenn man es genau nimmt, ging ja deiner Ergänzung eine Überlegung voraus, ob das komplette neue Wort sinnvoll ist, sodass man dir durchaus auch das komplette Wort anrechnen kann. Im Übrigen können wir daran sowieso nichts ändern, denn die Autorenauswertung erfolgt über einen externen Dienst. Gruß, -- hgzh 09:22, 7. Mai 2021 (CEST)

Schnarks Normdaten-Skript[Quelltext bearbeiten]

Schnarks Normdaten-Skript erleichtert die Eingabe der Normdaten durch ein Eingabeformular. Seit gestern erscheint der Kasten beim Aufruf von Artikeln nicht mehr. Benutzer:Schnark ist leider nicht mehr aktiv. Kann jemand von der Technik-Werkstatt das Problem löschen? (Siehe auch Hilfe Diskussion:Normdaten#Schnarks Normdaten-Skript.) --Kolja21 (Diskussion) 16:59, 8. Mai 2021 (CEST)

bei mir alles normal. browser: firefox 88.01 (64 bit). --Jack User (Diskussion) (ohne (gültigen) Zeitstempel signierter Beitrag von Jack User (Diskussion | Beiträge) 17:19, 8. Mai 2021 (CEST))
Klappte bei mir am Vormittag auch. Irgendwelche Scripte sind bei dir wohl gecacht. bei mir (und wohl auch bei Klja) kommt der Knopf "Normdaten einfügen" nicht bzw. wenn schon welche verhanden sind, fehlt der Knopf "Normdaten bearbeiten". Mach jetzt kein Shift-F5, dann isses bei dir auch kaputt. Aber mit einem zweiten Browser kannst probieren, da wird wohl auch nix kommen. --Wurgl (Diskussion) 17:23, 8. Mai 2021 (CEST)
Bei Ingrid Davis um 17:18: keine Probleme. --Jack User (Diskussion) 17:32, 8. Mai 2021 (CEST)
@Kolja21, Wurgl: bei mir funktionieren beide Skripte. Ich selber nutze Google Chrome und habe es wegen dem angesprochenen Cache auch noch einmal mit einem anderen Browser Edge ausprobiert. Auch dort keinerlei Probleme, auch nach Gebrauch von Shift-F5. Frage: Ich binde die beiden Skripte über Schnarks Fliegelfagel ein. Könnte es eventuell daran liegen? Viele Grüße --Silke (Diskussion) 08:38, 9. Mai 2021 (CEST)
So geht es wieder: Spezial:Diff/211769040 (dass ich Wurgl/Normdaten eingebunden hab, macht keinen Unterschied. Das ist identisch zu Schnark).
Der Fehler ist also das Nachladen von dem templateEditor.js aus dem Normdatenscript. War meine Vermutung doch richtig? --Wurgl (Diskussion) 08:47, 9. Mai 2021 (CEST)
@Wurgl: Ich verstehe nur Bahnhof, aber nachdem ich den Code 1:1 von deiner common.js-Seite kopiert habe, klappt die Bearbeitung mit dem Skript wieder. Muss Benutzer:Schnark/js/personendaten/normdaten#Einbindung entsprechend ergänzt werden? --Kolja21 (Diskussion) 15:51, 9. Mai 2021 (CEST)
Im Normdatenscript guckt er, ob die Erweiterung TemplateEditor (was immer das ist) geladen ist, wenn nicht dann lädt er das nach. Und dieses Nachladen klappt wohl nicht. Mit der Änderung ist das aber schon da, es muss nix mehr nachgeladen werden. --Wurgl (Diskussion) 16:05, 9. Mai 2021 (CEST)
Moin zusammen, also wenn jetzt bei den Normdaten der "Bearbeiten-Button" nicht kommt, was muss ich dann tun? mfg --Crazy1880 21:16, 10. Mai 2021 (CEST)

Probleme bei "Abrufstatistik" ganz unten, vor dem Link zu den Autoren[Quelltext bearbeiten]

Bei anderen Artikeln hab ich bisher nix gemerkt, bei Eureka O’Hara aber lande ich am Ende bei https://pageviews.toolforge.org/?project=de.wikipedia.org&platform=all-access&agent=user&redirects=0&range=latest-20&pages= (man beachte: Parameter pages ist leer!) und nix passiert, außer dass sich der Kreisel dreht. --Wurgl (Diskussion) 08:58, 9. Mai 2021 (CEST)

@Wurgl: Welchen Browser verwendest du? Ich kann das mit Chrome reproduzieren aber nicht mit Firefox und nicht, wenn ich den Link in Chrome in einem Incognito-Fenster öffne... --Count Count (Diskussion) 21:58, 16. Mai 2021 (CEST)
Siehe auch en:User_talk:MusikAnimal#Pageviews_Analysis_–_A_message_from_Wurgl
Zu deiner Frage: Firefox/Linux unangemeldet --Wurgl (Diskussion) 23:13, 16. Mai 2021 (CEST)

GND-Links in de.wikipedia[Quelltext bearbeiten]

Bei meinem Projekt sind jetzt Meldungen nach dem folgenden Muster angefallen:

No GND-link from Wikipedia on Berlin-Marzahn, but GND record 4087331-6 contains https://de.wikipedia.org/wiki/Berlin-Marzahn

Da wäre nach Prüfung entweder ein GND:xxx auf der Wikipedia-Seite zu korrigieren oder dort überhaupt neu anzulegen (wie im Beispiel). Einige der Seiten haben sicher ein englisches Äquivalent, wo das dann über Wikidata läuft, also nochmals einzugeben wäre.

Frage: Muss man das wirklich doppelt eingeben? Momentan habe ich 1273 dieser Meldungen, und ich werde vermutlich weitere produzieren.

Ich wäre für jeden Tipp dankbar!

--AxelCorti (Diskussion) 20:06, 16. Mai 2021 (CEST)

Es fehlen ca. 30.000 GNDs in Geographika, siehe Benutzer:Wurgl/Fehler GND#Parameter GND ergänzen (TYP=g). Ich trage jeden Tag so 25 Stück ein, wobei ich diese auch prüfe (manchmal auch 25 Körperschaften).
In der DNB kommen die Links auf die Wikipedia wahrscheinlich(!) auf dem Weg Wikidata => VIAF-Cluster => DNB.
In Wikidata sind diese GNDs teils von der initialen Übernahme aus den VIAF-Clustern (irgendwann 2015) und teils von irgendwelchen Botläufen eingetragen worden, entsprechend "gut" ist die Qualität. In jedem 25er-Paket sind welche enthalten, wo die DNB einen Nachfolgedatensatz hat oder auch solche, die voll daneben sind. Beispiel für "voll daneben" wäre GND 5298419-9 wo eine Ortschaft mit einer Band verknüpft ist.
@Kolja21: zur Kenntnisnahme. --Wurgl (Diskussion) 20:25, 16. Mai 2021 (CEST)
@AxelCorti: Um welches Projekt handelt es sich? Ich sehe das wie Wurgl: Wir müssen die Datensätze einzeln prüfen. Wenn Wikipedia als Quelle angegeben ist, heißt das ja nicht zwangsläufig, dass sich der Artikel auf die jeweilige Person oder den betreffenden Ort bezieht, für die oder den die GND steht. Und was Wikidata betrifft: Es reicht, die GND in Wikipedia einzutragen. Wikidata importiert die Angaben ungeprüft per Bot. --Kolja21 (Diskussion) 20:37, 16. Mai 2021 (CEST)

@Kolja21: @Wurgl: Begonnen hat es mit einem Projekt für einen anderen Einsatz von GND-Identifiern, speziell waren GND-Ids für Personen aller Art und Organisationen zu suchen, Geografika nur am Rande (in Summe ca. 90.000). Ich habe dann Doubletten in der GND gefunden und mit E-Mail von der Command-Line an die DNB versendet (nicht das lähmende Formular auf der DNB-Seite; WP:GND/F kannte ich nicht). Aber da meine Meldungen teilweise über das hinausgingen, was die DNB in jener Funktionsmailbox erwartet und reibungslos verarbeiten kann, hat mir die DNB nach ca. 100 Meldungen eine eigene Anlaufstelle (Person, keine Mailbox) gegeben, der ich jetzt Meldungen aller Art senden darf. Mittlerweile bin ich mit meiner Suche fertig und jetzt dabei, meine SW zu pflegen und eine brauchbare Dokumentation über die RDF-XML-Schnittstelle zu schreiben.

Ich habe vor einiger Zeit von einem Wikidata-Experten den URL persondata.toolforge.org/redirect/gnd erfahren und verwendet. Bei den Massentests der Analyse der Gegrafika-Rückmeldungen (Suche nach 81 DE-Stadtnamen und Analyse aller Rückmeldungen) habe ich dann am 16.5. den Konsistenzcheck zwischen GND und Wikipedia eingebaut, was eine reiche Ernte ergab. Bei 5223 Records von 56 Queries: TODOs: 1273 Wikipedia, 106 GND. Soeben ist auch AT gelaufen: 1665 Records von 89 Queries, TODOs: 181 Wikipedia, 36 GND. Das ist natürlich nicht systematisch; die vielen Records ergeben sich aus der Unschärfe einer Query, die nur "Berlin" oder "Köln" etc. enthält. --AxelCorti (Diskussion) 07:51, 17. Mai 2021 (CEST)

Wie gesagt: Die VIAF übernimmt regelmäßig die Daten aus Wikidata und bildet auf Grundlage dieser (und anderer Daten) die VIAF-Cluster. Wenn in einem VIAF-Cluster ein Wikidata- und ein DNB-Datensatz enthalten ist und beim Wikidata-Datensatz die deutsche Wikipedia verlinkt ist, findest du auch regelmäßig auf der entsprechenden Seite der DNB einen Link zur deutschen Wikipedia – wie immer der dort reinkommt.
Diese oben verlinkte Fehlerliste, welche ich seit ca. 2 Jahren abarbeite, hatte anfangs 40.000 fehlende GND-Ids für Geographika und 27.000 fehlende GNDs für Körperschaften. Jetzt fehlen noch 30.000 Geographika und 25.000 Körperschaften. Die damals fehlenden 18.000 GND-Ids für Personen sind weitgehend abgearbeitet, ca. 200 Personen-Datensätze sind noch zu prüfen und ev. zuzuordnen (die Personen-GNDs werden von anderen Fleißigen abgearbeitet, unter anderem Kolja21). In den letzten zwei Jahren sind also aus dieser Fehlerliste heraus so Daumen mal Pi 30.000 unserer Artikel einem GND-Datensatz geprüft worden und die Passenden zugeordnet, die unpassenden entsprechend bei Wikidata markiert. Wobei diese Zahl zu klein ist, denn der Artikelbestand hier in der Wikipedia ist ja auch gewachsen.
Leider ist die VIAF-Logik schlicht und einfach blöde und diverse Bots bei Wikidata sind auch nicht besser. Die VIAF ignoriert offenbar Markierungen wie "Missbilligt" und diverse Bots ordnen aus ungeprüften Quellen (unter anderem der VIAF) die IDs zu, egal ob die schon mal entfernt wurden oder nicht. Damit ergibt sich das demotivierende Szenario, dass unsereiner bei Wikidata eine GND entfernt und ein Wikdata-Bot meint, er müsse die GND wieder hinzufügen, weil die ja im VIAF-Cluster enthalten ist. Andererseits: Wenn dieser GND-Datensatz als "Missbilligt" markiert wird, dann behandelt den die VIAF wie eine passende Zuordnung, wenigstens grätschen hier die Wikidata-Bots nicht dazwischen. (Diese Sätze sind nicht aus gesichertem Wissen entstanden, sondern aus Beobachtung und Erfahrung.)
Ich selbst ordne primär hier in der deutschen Wikipedia die (hoffentlich) richtigen GNDs zu, bei Wikidata markiere ich falsche Zuordnungen mit "Missbilligt". Was dann die VIAF draus macht und wie dann die Links auf die Wikipedia in den DNB-Datensatz kommen, kann ich nicht beeinflussen. Bei Geographika (und teilweise bei Körperschaften) gibt es noch die Besonderheit der Nachfolger-Datensätze durch Gebietsreformen, Eingemeindungen, Umbenennungen bzw. Firmenübernahmen. Hier ordne ich den passenden Datensatz in der Wikipedia zu und ignoriere Wikidata. Ich ignoriere Wikidata, weil die VIAF-Cluster auch Datensätze anderer Bibliotheken enthalten und diese nicht unbedingt korrespondierende Nachfolgedatensätze haben. (Es gibt noch die Spezialfälle, wo andere Bibliotheken mehrere Personen/Geographika/Körperschaften vermischen, solche sind einfach nicht lösbar. Und es gibt genügend Fälle, wo eine eindeutige Zuordnung mangels minimalistischen Daten in den Bibliotheken nicht möglich ist Beispiel: GND 7522825-7 entspricht welchem Liběšice?).
Du wirst also auch in Zukunft weiterhin Inkonsistenzen haben. --Wurgl (Diskussion) 09:38, 17. Mai 2021 (CEST)
Durchsucht ihr beide die Datenbestände auf die gleiche Weise? @AxelCorti: 1273 Meldungen sind eine überschaubare Zahl. Wenn du Lust hast, erstelle eine Unterseite (AxelCorti/...) mit der Vermerk Kategorie:Wikipedia:Normdaten-Wartung, dann können wir die Einträge vergleichen und gegebenenfalls von Hand abarbeiten. PS: Falls du bei deinen Meldungen an die DNB die Dubletten aus der Kategorie:Wikipedia:Veraltete Normdaten mit unterbringen kannst, wäre das eine große Hilfe. --Kolja21 (Diskussion) 12:36, 17. Mai 2021 (CEST)

@Kolja21: Mein Verfahren, kurz skizziert. Ich sende eine SRU/CQL Query als Request an services.dnb.de/sru/authorities und nehme das gelieferte XML auseinander (JAXB, Apache Jena). Wenn ich nach Geografika suche, prüfe ich den rdf:type (denn es gibt m.E. verfehlte Typisierungen). Es sollte auch einen preferredName für ein Geografikum geben (und nicht für Körperschaft). Wenn der Record ein Property foaf:page enthält, dann kann geprüft werden, ob dieser Wikipedia-URL mit dem übereinstimmt, den man durch Redirection von persondata.toolforge.org/redirect/gnd mit dem GND-Identifier bekommt. Dieser kann fehlen (Wikipedia hat kein GND), ungleich sein (Wikipedia hat falsches GND) oder übereinstimmen. (Hat der Record kein Property foaf:page, dann ...)

Ich werde jetzt die Klassifizierung dieser Unterscheidungen prüfen und dann sehen, in welcher Form ich meine Funde weiterleite. Die DNB muss mit meinen Reklamationen klarkommen. Die betroffenen de.wikipedia-Seiten kann ich in Angriff nehmen bzw. auch (gem. Vorschlag) auf einer Unterseite veröffentlichen. Ich weiß nicht, ob die DNB scharf darauf ist, eine Wikipedia-Seite (mit eingetragener GND-Referenz) auch auf dem GND-Record zu speichern. Ich weiß auch nicht, wie eifrig sie bei der Verlegung eines Links von einer Vorgängerseite zu einer Nachfolgerseite sind. (Wikipedia spricht von einem Ding "X" mit einer Geschichte von der Stunde Null; GND hat bei Geos und Orgs den Ehrgeiz, aufeinanderfolgende Entities getrennt zu halten. Sinnvoll oder nicht - es ist nun einmal so.) Wikipedia wird den GND-Identifier nach dem historisch letzten GND-Record wählen. Es wird da immer Diskrepanzen geben... --AxelCorti (Diskussion) 13:36, 17. Mai 2021 (CEST)

Ich hole mir den 4-monatlichen DNB-Dump die 6 Files authorities-<TYPE>_lds.rdf von https://data.dnb.de/opendata/ und den monatlichen VIAF-Dump viaf-<timestamp>-links.txt.gz von http://viaf.org/viaf/data/ Die Vorschläge hole ich aus dem VIAF-Dump. Für Online-Abfragen haben wir einfach zu viele Artikel, das würde zu lange dauern. Und viaf-<timestamp>-clusters.xml.gz dürfen die sich an den Hut stecken, die Webseite lässt die Daten nur tröpfeln, so 7-8 Stunden würde der Download dauern (nein, an meinem Internetzugang liegt es nicht). --Wurgl (Diskussion) 11:36, 18. Mai 2021 (CEST)

@Kolja21: @Wurgl: Ich war im letzten November dabei, mit authorities-person_lds.rdf fehlende GND-Identifier (nicht für Wikipedia) zu suchen. Das war schwierig, weil die mir vorgegebenen Namensteile nicht so wie die Teile auf den GND-Records strukturiert waren. Ich habe dann mit Queries an services.dnb.de gearbeitet, das zurückkommende RDF-XML detailliert zerlegt und dann nach anderen Attributen (z.B. Beruf) gefiltert. Es ist nicht leicht, SQL-Queries so zu formulieren, dass ein Minimum zurückkommt.

Eigentlich hatte ich dann begonnen, meine SW nach den K(r)ämpfen mit den RDF-Formaten zu bereinigen; ich war auch schon abseits der GND im Wust der Titel der DNB unterwegs. Ich habe dann vor ein paar Tagen damit begonnen, eher unsystematisch Geografika (siehe hier) zu analysieren, wobei ich nunmehr prüfe, ob

  • GND und Wikidata/-pedia einander genau referenzieren,
  • der GND-Record einen unwarteten Typ oder einen Namen mit einer unwerwarteten Property (oder gar keinen preferredName) hat,
  • GND einen falschen Wikipedia-Link hat,
  • GND den Wikipedia-Link eingetragen bekommen sollte, der sich aus GND:<id> im Wikidata ergibt,
  • GND einen Wikipedia-Link eingetragen bekommen könnte, der sich aus einer Suche bei Wikipedia (API) ergibt (wobei dann im Wikipedia-Artikel ein GND:<id> einzutragen wäre),
  • der GND-Record einen Wikipedia-Link eingetragen hat, aber kein Wikidata/-pedia-Link zu diesem GND-Record existiert.

Die beiden letzten Punkte sind (gegebenenfalls auch) auf der Wikipedia-Seite zu beheben. Die Ergebnisse sehen nicht schlecht aus. Zunächst scheint es mir, dass meine Ergebnisse einige Korrekturen in de.wikipedia anregen, aber weit mehr in GND-Records. (Ich sollte die Liste wohl als Unterseiten zu AxelCorti/GND-Wikipedia-Geografika veröffentlichen.)

Ich habe beim Lauf meines Programms den unangenehmen Effekt, dass nach einigen hundert HTTP-Requests an de.wikipedia.org und services.dnb.de die Requests mit einer Exception ("No route to host") abbrechen, eine Wiederholung erst nach Minuten greift und es dann nur mehr im Mehrminutentakt weitergeht. Wisst ihr etwas dazu? (Ich hörte die Meinung, dass hier eine DoS-Abwehrstrategie dahinter steckt.)

Ich überlege, ob ich mit irgendwelchen "Fischzügen" in der GND weitermachen soll. Ich habe die Option, Queries mit allen deutschen Städten (ohne die 56 Großstädte) zu fahren und zu sehen, was die damit mitkommenden GND-Records hergeben. (nicht signierter Beitrag von AxelCorti (Diskussion | Beiträge) 11:10, 19. Mai 2021 (CEST))

Bezüglich des zugriffs auf de.wikipedia.org, hilft apihighlimits API (Anträge_auf_Botflag)? --Wetterwolke (Diskussion) 12:40, 19. Mai 2021 (CEST)
Ach es gibt ein Limit? *staun* Für die Rechner von Toolforge existiert das Limit wohl nicht. Für Rechner@Hause aus mag das existieren. --Wurgl (Diskussion) 12:57, 19. Mai 2021 (CEST)
Danke für den Hinweis auf das Limit!

Ich habe auf meiner Benutzerseite eine erste Referenz auf eine Unterseite mit Ergebnissen zu österreichischen Geografika eingerichtet. Wer mag, kann sich an Ergebnissen wie die zu "Wienerwald" oder "Baden-Württemberg" (sic!) belustigen. --AxelCorti (Diskussion) 18:57, 19. Mai 2021 (CEST)

Ich hab mir ein paar aus "No GND link from Wikipedia, but GND record contains a Wikipedia URL."
Einige sind von der VIAF-Logik falsch zugeordnet. Beispiel: VIAF:52145602546401362431 Die VIAF ordnet hier Stadlau (Q801608) zu. Sieht erstmal sinnvoll aus, ist aber Käse, weil das Wikidata-Objekt den Bahnhof Wien Stadlau zugeordnet ist. Das ist bei wirklich vielen Artikeln zu Bahnhöfen so ähnlich, leider. Das zweite Problem ist in der Historie der GND zu finden. Es gab mal zwei getrennte Sätze an Normdaten: SWD und GKD und somit gibt es für viele Geographika, Körperschaften (und Kongresse) oft zwei GND-IDs. Den einen ordnet VIAF oft richtig zu, der andere ist dann nicht oder was falschem zugeordnet. Manchmal ist bei uns der eine Datensatz zugeordnet und beim VIAF-Cluster (oder Wikidata) der andere. Die DNB entfernt so nach und nach diese Duplicate und macht aus zwei Stück einen einzigen, Ende dieses Jahrhunderts sind die möglicherweise durch.
Anderes Beispiel: GND 16036018-3 … ganz ehrlich, wenn ich die Beschreibung lese, dann weiß ich nicht ob der Datensatz diese Häusergruppe (DNB schreibt Wohnpark) oder den Bezirksteil beschreibt oder gar beides? Glücklicherweise gibt es GND 1042047669 und das ist eindeutig. Es ist eben nicht gar so einfach und per Bot kaum zu machen. --Wurgl (Diskussion) 11:54, 21. Mai 2021 (CEST)


@Kolja21: @Wurgl: @Wetterwolke: Ich habe einen Antrag auf ein Bot-Flag gestellt. Was mir nicht klar ist: Sollte ich schon jetzt einen Request mit action=edit zum Erneuern des Textes einer Seite machen können? Die Doku scheint mir da keine ganz klaren Aussagen zu machen. Mein POST-Request mit +\ als Token wird mit "Invalid CSRF token" beantwortet, was mich nicht wundert. Oder soll ich irgendwo mit genaueren Angaben fragen gehen, weil ich vermutlich irgendetwas falsch mache? (Den existierenden Seitentext und das +\-Token bekomme ich ohne Fehlermeldung.) (nicht signierter Beitrag von AxelCorti (Diskussion | Beiträge) 10:12, 21. Mai 2021 (CEST))

Du musst erst ein Edit-Token anfordern. Und du musst dich einloggen (dafür wieder ein login-token anfordern), dann kommt was sinnvolles bei z.B. https://de.wikipedia.org/w/api.php?action=query&format=json&meta=tokens&formatversion=2&type=csrf --Wurgl (Diskussion) 11:54, 21. Mai 2021 (CEST)

Bug bei der Überprüfung der Stimmberechtigung?[Quelltext bearbeiten]

Bei der Überprüfung meiner Stimmberechtigung wird die entsprechende Seite stimmberechtigung.toolforge.org geöffnet. Dort steht hinter "Allgemeine Stimmberechtigung" der Link "(neu)", der (wie auch hier verlinkt) auf eine ältere Version von Wikipedia:Stimmberechtigung verweist. Ich vermute, das ist ein Fehler? --Of (Diskussion) 09:38, 18. Mai 2021 (CEST)

Ein Fehler nicht unbedingt, es wird auf die Version verwiesen, in der diese Ergänzung zur Stimmberechtigung erstmals eingetragen wurde. Aber nach elf Jahren ist auch nichts mehr wirklich neu. -- hgzh 13:04, 21. Mai 2021 (CEST)

Technisches zur Wikipedia-App[Quelltext bearbeiten]

Ich hoffe, das ist der richtige Ort für dieses Anliegen: Wenn ich auf Wikipedia nicht angemeldet bin und am Computer einen Artikel mit ungesichteten Versionen aufrufe, dann wird mir als Standard immer die letzte gesichtete Version angezeigt. Wenn ich die ungesichteten Versionen anschauen möchte, dann muss ich zusätzlich klicken. Das finde ich gut, denn so bleibt unentdeckter Vandalismus für die Leser unsichtbar. Nun ist mir aber aufgefallen, dass das in der Wikipedia-App nicht geschieht. Vorhin habe ich einen Artikel in der App gelesen, der ungesichtete Versionen hatte. Ich war in der App nicht angemeldet und war dort auch vorher überhaupt noch nie angemeldet, da ich die Wikipedia ausschließlich am Computer bearbeite und nicht am Handy. Trotzdem hat mir die App direkt die ungesichteten Versionen angezeigt, und das sogar ganz ohne Hinweis darauf, dass eine Sichtung fehlt. Dass ich eine ungesichtete Version gelesen habe, ist mir erst aufgefallen, als ich denselben Artikel am Computer nochmals angeschaut habe. Ich habe das dann bei mehreren anderen Artikeln wiederholt und festgestellt, dass die App offensichtlich die ungesichteten Versionen nicht versteckt. Unentdeckter Vandalismus wird also dem Leser in der App direkt angezeigt, ohne Hinweis darauf, dass eine Sichtung fehlt. Ich kann mir nicht vorstellen, dass das gewollt ist und würde eine Änderung vorschlagen. Sonst sind die ganzen Sichtungen sinnlos. Gruß, Hoppla Schorsch (Diskussion | Beiträge) 18:03, 3. Jun. 2021 (CEST)

Fußnoten auf Diskussionsseiten[Quelltext bearbeiten]

Liebe Leute, mir ist aufgefallen, dass vom Konstrukt ‹ref› diese »Referenzen« zu Fußnoten werden, genaugenommen zu Endnoten. In Haupteinträgen stehen die dann ganz unten als »Einzelnachweise«, mit dieser Überschrift. Auf Diskussionsseiten hingegen stehen diese Art Fußnoten zwar auch am Ende, sind aber nicht vom laufenden Text abgesetzt durch die Überschrift »Einzelnachweise« (»Referenzen« wäre m.E. klarer). Vielleicht könnte man das fixen. Beispiel war eine Diskussion über Ilse Weber zwischen »Ubuy« und mir, die aber nicht (mehr) dort steht, sondern auf https://de.wikipedia.org/wiki/Benutzer_Diskussion:Fritz_J%C3%B6rn#https://de.wikipedia.org/wiki/Diskussion:Ilse_WeberFritz Jörn (Diskussion) 16:13, 12. Jun. 2021 (CEST)

Das einzige was du machen musst ist ein <references /> am Ende eines Abschnittes mit Referenzen reinmachen. Hast du mehrere Abschnitte mit Referenzen, dann eben mehrmals reinmachen.[1] --Wurgl (Diskussion) 16:38, 12. Jun. 2021 (CEST)
  1. Das klappt so! Ganz sicher!
Unter Referenzen (Siehe auch Referenz) verstehe ich etwas völlig anderes als Einzelbelegangaben. Ansonsten wollte ich das ähnlich umschreiben. Man kann auch eine Pseudeüberschrift drüber setzen. --Liebe Grüße, Lómelinde Diskussion 16:45, 12. Jun. 2021 (CEST)[1]

Anmerkung

  1. Hier mit einer Überschrift Anmerkung.
Und wie man sieht, sammelt das Tag <references /> alle Referenzen die seit dem letzten Vorkommen des Tags gefunden werden. Deshalb ist mein <ref> oben und das von Lómelinde unten extra. Von Seiten der Technik muss da wohl nix gemacht werden. --Wurgl (Diskussion) 17:09, 12. Jun. 2021 (CEST)

Benutzer:Hannes Röst/flagged_user_vector.js und Benutzer:DerHexer/rollback.js[Quelltext bearbeiten]

Hallo. Erneut auf die Gefahr hin, dass ich im Technischen noch ahnungsloser bin als ohnehin befürchtet: Benutzer:Hannes Röst/flagged_user_vector.js und Benutzer:DerHexer/rollback.js sind in meiner Benutzer:RoBri/common.js, aber haben irgendwann in den letzten Tagen aufgehört zu funktionieren. Was muss ich machen, wo muss ich klicken? Hilfe, --Roger (Diskussion) 17:51, 12. Jun. 2021 (CEST)

Na wenn ich Probleme mit einem Skript hätte würde ich zunächst mal den Ersteller/Betreiber fragen. Sie sind ja beide aktive Benutzer. dort beim Hexer gab es zumindest letztens Änderungen. CC: Hannes Röst --Liebe Grüße, Lómelinde Diskussion 18:10, 12. Jun. 2021 (CEST)
...zumindest des Hexers Skript scheint wieder zu funktionieren. --Roger (Diskussion) 10:36, 17. Jun. 2021 (CEST)
Da gab es auch heute eine weitere Änderung Spezial:Diff/212873699/213027830, weshalb sich hier keiner der Beiden zu Wort melden, weiß ich nicht, ich finde das allerdings sehr schade, denn es betrifft ja ihre Skripte. --Liebe Grüße, Lómelinde Diskussion 10:48, 17. Jun. 2021 (CEST)
Ich hatte beide noch auf ihren Disks um Hilfe gebeten. Schaumermal. --Roger (Diskussion) 10:53, 17. Jun. 2021 (CEST)

invidious.io[Quelltext bearbeiten]

Da YouTube bekanntlich Nutzerdaten ausspäht und speichert, gibt es inzwischen eine ganze Reihe von Servern, die eine alternative Sicht auf diese Inhalte bieten, ohne Nutzerdaten weiterzugeben. Früher war das invidio.us. Inzwischen gibt es viele; die Liste findet sich unter https://redirect.invidious.io – leider sind immer wieder einzelne der dort davon überlastet; man sucht sich dann aber einfach einen anderen aus, mit anderem URL.

Beispiel: https://redirect.invidious.io/watch?v=8KsXPq3nedY - Eine sehr schöne Aufnahme des Bolero.

Nun juckt es mich manchmal, in einem WP-Artikel auf ein Youtube-Video verlinken – aber wenn möglich nicht direkt, sondern unter Ausnutzung dieses Projekts. Ich hätte nun eigentlich erwartet, dass diese Situation bekannt ist und es bei der WP irgendeinen standardisierten Weg gibt, mit einer kleinen Erklärung auf diesen Übersichtsserver zu verlinken. Ähnlich vielleicht wie die Links zu IMSLP per {{IMSLP2...}}. Gibt es aber offenbar nicht, und es scheint auch keinen Artikel zu diesem Projekt zu geben, offenbar nichtmal in der englischen Wikipedia.

Gibt es einen guten Grund dafür, der mir bisher entgangen ist? Was sollte ich tun?

Danke, Gruß, --INM (Diskussion) 20:36, 17. Jun. 2021 (CEST)

"Gibt es einen guten Grund dafür, der mir bisher entgangen ist? Was sollte ich tun?"
Ja, den gibt es. Und es ist derselbe, aus dem wir in Kinofilm-Artikeln keine passenden Links zu kostenlosen Streaming-Seiten anbieten: Keine Links zu rechtswidrigen Websites. Eine Wiedergabe von Youtube-Inhalten ohne Weitergabe der Nutzerdaten, Einbindung von Werbung etc. verstößt gegen die Nutzungsbedingungen. Es steht uns frei, Inhalte mit CC-Lizenz von Youtube herunterzuladen und datensparsam und werbefrei auf Commons anzubieten (wie z.B. File:Segelflug_Start_Strausberg.webm). Aber wenn sich die Uploader bewusst gegen eine CC-Lizenz entscheiden und ihre Inhalte unter die übliche Youtube-Lizenz stellen, dann verstoßen Projekte wie Invidious gegen diese Lizenz. --Tkarcher (Diskussion) 15:31, 18. Jun. 2021 (CEST)
OK, verstanden. Vielleicht sollte das dann auch irgendwo stehen.
Frage wär dann natürlich noch: Wo sehe ich bei YouTube, welche Lizenz verwendet wurde und wie lade ich die Datei im Falle der Legitimität herunter; was muss ich dann beim Einstellen auf Commons beachten? Danke, Gruß, --INM (Diskussion) 15:52, 18. Jun. 2021 (CEST)
Steht es ja - bei den oben verlinkten Weblink-Richtlinien. Welche Lizenz verwendet wird, findest du bei Youtube in der Videobeschreibung. Steht dort nix, ist es die Standard-Lizenz. Du kannst aber auch per Suchfilter explizit nach CC-Lizenzen suchen. Um bei deinem Bolero-Beispiel zu bleiben: Bolero-Videos mit CC-Lizenz. Und falls du Hilfe beim Download/Upload brauchst, kann dir die Wikipedia:WikiProjekt_Videos/Uploadhilfe helfen. (Das bin dann auch meistens wieder ich. ;-)) --Tkarcher (Diskussion) 16:06, 18. Jun. 2021 (CEST)

Default-Einstellung in Bildergalerien[Quelltext bearbeiten]

Bei der Default-Einstellung einer Bilder-Galerie (wenn keine Angabe über Bündigkeit gemacht wird) kommt auf breiten Monitoren etwas ziemlich schepses heraus: die Bilder kleben linksbündig – aber die zugehörigen Titel geistern irgendwo im leeren Raum in der Mitte des Bildschirms herum ... Hier sollte die Default-Einstellung besser gesetzt werden. --ProloSozz (Diskussion) 12:00, 24. Jun. 2021 (CEST)

Das Problem ist schon länger bekannt, aber bisher leider noch ungelöst: https://phabricator.wikimedia.org/T214092 --Tkarcher (Diskussion) 12:16, 24. Jun. 2021 (CEST)

Wie heißt noch mal das Fehlertool mit roter Schrift auf gelbem Grund?[Quelltext bearbeiten]

Leider habe ich vergessen – und würde gern wissen –, welches Tool mir in diesem Lemma am Anfang einen rot umrandeten Kasten mit roten x, x, w1 auf drei Zeilen zeigt sowie im #6.1 ein gelbes Feld mit jeweils roten x (Tipp: Wasserscheide fehlt) und x (Ausbau fehlt) und darunter w1 (POSKARTE unpassend).

Über diese Fehlermeldungen habe ich mich nur gewundert, da in Vorlage:Infobox Pass Wasserscheide und Ausbau nur optionale Parameter sind und der Parameter POSKARTE regelrecht auf none gesetzt wurde.

Dank, --Wi-luc-ky (Diskussion) 01:13, 9. Jul. 2021 (CEST)

Offenbar Benutzer:PerfektesChaos/js/remindErrorMessages. VG --PerfektesChaos 03:50, 9. Jul. 2021 (CEST)
Vielen Dank, PerfektesChaos. --Wi-luc-ky (Diskussion) 12:57, 9. Jul. 2021 (CEST)
Meintest du das Tool oder meintest du wie solche Texte generell so dargestellt werden und wo man dann diese Fehlermeldung im Quelltext finden kann?
Das ist eine eigene Klasse, die so class="error" im Quelltext der Vorlage zu finden sein sollte und dann so etwas hier ist ein Fehler erzeugt.
Diese Meldungen werden zumeist nur bei der Bearbeitung angezeigt, es sei denn in der Vorlage wurde das nicht als <span class="error editoronly noprint">hier ist ein Fehler</span> definiert, dann sieht es jeder. Und die Vorlage:Pass hat dort kein „editoronly“ (nur für Bearbeiter anzeigen) drin, sondern es steht so dort <div class="error" style="display:none">[[Vorlage:Infobox Pass/Wartung/Ausbau fehlt|x]]</div> also für alle anzeigen obwohl es eigentlich wohl über „display:none“ versucht wurde auszublenden und man eventuell nur eine fiktive Liste erzeugen wollte, um die Vorlage auf fehlende Daten hin zu prüfen. --Liebe Grüße, Lómelinde Diskussion 10:28, 9. Jul. 2021 (CEST)
Vorausgeschickt: Wahrscheinlich kann ich Deine dankenswerten Fragen nicht zufriedenstellend beantworten, Lómelinde. Ich versuche es:
  • Zunächst hat PerfektesChaos das Tool identifiziert, Danke nochmals.
  • Die Auffindung der Fehlerorte ist ja leicht durch Anklicken der Eingangsmeldungen, die dann angesprungen werden können, zu finden. Außerdem steht es im hilfreichen Tooltip.
  • Mglw. liegt es an meinem Verständnis des Wortes „Fehler“, worunter ich einen „notwendigen Reparaturbedarf“ verstehe. In diesem Fall werden zwei fehlende, aber als optional beschriebene Parameter als Fehler gekennzeichnet. Dass sie fehlen, ist objektiv richtig. Ob dies ein Fehler oder nur eine Mängelanzeige ist, wäre die Frage. Insofern sollte ich wohl mein Verständnis der Meldungen in Richtung „Hinweise auf Wünschenswertes“ erweitern und mich nicht weiter darum bekümmern.
  • Mit der Vorlage:Infobox Pass habe ich bisher nichts zu tun gehabt; kann dazu auch nichts beitragen. Für mich ist sprachlich unverständlich nur die Meldung zur ausgeblendeten POSKARTE als „unpassend“. Was kann ein Leser damit anfangen?
  • Die Fehlermeldungen treten bei mir bei Aufruf des Lemmas auf; im Edit-Modus nicht mehr.
Mir ist jetzt schon sehr geholfen; will hier wirklich keinem die Zeit rauben. Dankeschön, --Wi-luc-ky (Diskussion) 12:57, 9. Jul. 2021 (CEST)
Na dann. Für mich sind solche Rotlinks Vorlage:Coordinate/Wartung/POSKARTE unpassend alles andere als sinnvoll, denn gesammelt wird es hier Spezial:Linkliste/Vorlage:Coordinate/Wartung/POSKARTE_unpassend, wer sich das dann ansieht und damit etwas anfangen kann weiß ich beim besten Willen nicht. Also ich zumindest verwende das Tool und sehe es beim Lesen und beim Bearbeiten in der Vorschau. --Liebe Grüße, Lómelinde Diskussion 13:43, 9. Jul. 2021 (CEST)

Vorlage:Navigationsleiste Kader des FC Lausanne-Sport[Quelltext bearbeiten]

Weshalb hat es zwischen „99“ und „Aldin Turkes“ zwei Leerzeichen, ansonsten aber nur jeweils eines? --Leyo 11:55, 17. Jul. 2021 (CEST)

Weiß ich nicht, vielleicht liegt es an der Einbindung aus Wikidata oder an der Zahl 99 die eventuell schon auf dreistellig gesetzt wird. Ich verstehe leider nicht wie diese Einbindung erfolgt oder wo da die Pipes gesetzt werden oder die Formatierung des Inhalts erfolgt. Vielleicht beginnt die Zählung ja mit 0. Dann wäre 99 = 100 = dreistellig.
Aber mal eine andere Frage, wieso hat diese Navigationsleiste als einzige überhaupt Trikotnummern? --Liebe Grüße, Lómelinde Diskussion 12:15, 17. Jul. 2021 (CEST)
Zwecks Sortierung. --Leyo 13:12, 17. Jul. 2021 (CEST)
Vor „Aldin Turkes“ befindet sich ein Zeilenumbruch, der für das zusätzliche Leerzeichen sorgt. -- hgzh 10:17, 20. Jul. 2021 (CEST)

Scripts unter dem neuen Firefox auf IPhone gehen nicht?--GhormonDisk 06:26, 19. Jul. 2021 (CEST)[Quelltext bearbeiten]

Hi, ist bekannt, dass die neue Firefox-Version fürs IPhone bei unseren scripts Probleme hat? Ich tippe auf Nebenwirkungen der Erhöhung der Sicherheit? Beispielsweise kann man auf der Disk nicht mehr erlen und alle scripts vom schönen monobook.js (VM, LA) von @PDD: gehen auch nicht (es kommt bis zum Editfenster, wo aber bei VM der Text schon nicht steht, den man in das Meldefenster ("vandaliert in" ) eingibt. Chrome geht (gleiches Gerät, gleiche Einstellungen). Ein Grund zum Wechseln, obwohl ich an Firefox hänge. Am PC (W10) geht es übrigens noch. GhormonDisk 06:26, 19. Jul. 2021 (CEST) und PS: Hier sollte auch mal jemand einiges erlen oder auch nach 365 Tagen archivieren? --GhormonDisk 06:28, 19. Jul. 2021 (CEST)

Kategorien in der Vorschau[Quelltext bearbeiten]

Wenn man nach dem Herumtippen im Artikel auf Vorschau geht, dann sieht man oberhalb des Edit-Feldes wie der Artikel aussehen wird. Bis auf die Kategorien, die Kategorien sind ganz unten.

Kann man die Kategorien in der Vorschau vielleicht auch oberhalb des Editfensters anordnen, dann wäre zusammen was zusammen gehört. --Wurgl (Diskussion) 09:44, 6. Aug. 2021 (CEST)

ist leider ein alter Hut: phab:T4679. -- hgzh 10:12, 6. Aug. 2021 (CEST)
Es würde auch vielen Benutzies sehr missfallen, weil diese die Strecke zwischen Content-Ansicht und Bearbeitungsfeld so ultrakurz wie irgend möglich halten möchten; idealerweise Textfeld und Abschnittsvorschau innerhalb desselben Bildschirmfensters überblicken möchten, und gleichzeitig noch die Knöpfe zum Speichern oder Diff/Vorschau.
Muttu dir individuelles Skript schreiben, das die Elemente der Seite wie auch immer jongliert.
In allen Skins werden die Kategorien und Interlanguages außerhalb des Content-Bereichs (in Leseansicht wie Quelltextbearbeitung) angeordnet; du möchtest jetzt aber diesen statisch festgelegten Bereich in die Mitte der Content-Region verschieben. Das machen die Skins nicht mit.
VG --PerfektesChaos 10:48, 6. Aug. 2021 (CEST)
Es gibt ja nur noch 4 skins zur Auswahl. In timeless stehen die rechts in einer eigenen Spalte. Passt so. In MinervaNeue werden die gar nicht angezeigt. Bleibt noch Vector und Monobook wo die ganz unten sind. Und eine Zeile mit den Kategorien zusätzlich oberhalb des Editfensters kann nun wirklich kein Problem sein.
Aber 16 Jahre für den phab-Eintrag ist schon toll, der macht bald Abitur. --Wurgl (Diskussion) (ohne (gültigen) Zeitstempel signierter Beitrag von Wurgl (Diskussion | Beiträge) 10:59, 6. Aug. 2021 (CEST))

Query[Quelltext bearbeiten]

Hallo, ich suche nach einer Möglichkeit herauszufinden, ob Blaulinks/Lemmata innerhalb eines Artikels in zwei ganz konkreten Kategorien bereits einsortiert sind. Geht sowas per query und wenn ja, wie? Z.b. alle Personen aus Olympische Sommerspiele 2020/Teilnehmer (Deutschland) in Kategorie:Olympiateilnehmer (Deutschland) und Kategorie:Teilnehmer der Olympischen Sommerspiele 2020. Je nach Größe der Delegation und Anzahl der Blaulinks ist >200-400x manuell reinsehen sehr mühselig, daher würde es mir sehr viel Arbeit sparen, wenn ich wüsste, wo tatsächlich was fehlt. Gruß, Squasher (Diskussion) 14:48, 15. Aug. 2021 (CEST)

Teste doch mal PetScan. Die beiden Kat-Einträge musst Du ggf. nochmal miteinander vertauschen. Die verlinkende Seite steht im dritten Reiter "Vorlagen & Links".--Mabschaaf 15:56, 15. Aug. 2021 (CEST)
Ja, da kommt auf jeden Fall was Brauchbares raus. Ob ichs noch „schöner“ hinbekomme, weiß ich noch nicht, aber es hilft mir auf jeden Fall das Durchgeklicke zu vermeiden. Und allein das ist schon eine massive Erleichterung. Vielen Dank, Mabschaaf! Gruß, Squasher (Diskussion) 20:23, 15. Aug. 2021 (CEST)

Darstellung einer Bildergalerie mit Beschriftungen[Quelltext bearbeiten]

Eine Bildergalerie mit Beschriftungen wurde aus der englischen Wikipedia in die deutsche Wikipedia übernommen. In der englischen Wikipedia werden die Bilder nebeneinander dargestellt und die Beschriftungen sind linksbündig, wie es gewünscht ist. In der deutschen Wikipedia werden die Bilder hingegen untereinander dargestellt und die Beschriftungen sind zentriert, was recht unschön ist. Weiß vielleicht jemand, warum das so ist und wie man es beheben könnte? -- 62.145.29.210 11:57, 28. Aug. 2021 (CEST)

Ich konnte das Problem nun selbst lösen, indem ich die Vorlage:Farblegende durch die Vorlage:Farbindex ersetzt habe. -- 62.145.29.210 19:36, 10. Sep. 2021 (CEST)

Rückgängigbutton[Quelltext bearbeiten]

Seit Ende August 2021 fehlt auf der linken Seite eines Vergleichs von Versionen (Diff) der Button „rückgängig“ ebenso die Auswahlmöglichkeit für den Grund des Zurücksetzens z. B. „Keine Verbesserung des Artikels“. Damit ist es nicht mehr möglich, auf die letzte gesichtete bzw. stabile Version bei mehreren dazwischen liegenden zurückzusetzen. Ich verwende PDD’s Monobook und aktuelles Firefox an einem stationären Desktop-PC, an meinen Benutzereinstellungen hatte ich nichts verändert. Ich hatte das bereits hier zur Sprache gebracht, scheint aber nicht die richtige Seite zu sein. Da es nicht nur mich betrifft, erhoffen wir uns Hilfe. Danke und Gruß —Regi51 (Disk.) 23:43, 2. Sep. 2021 (CEST)

Benutzer:PDD/addEditAndRevertLinks.js#L-32 müsste neu lauten (cc PDD)
if (mainNode.classList.contains("diff-otitle") || mainNode.classList.contains("diff-ntitle"))
damit sollte der (rev)-Link zum Zurücksetzen mit Begründung wiederkommen. Einen rückgängig-Link gibt es mE aber von Haus aus nur auf der rechten Spalte des Diffs, oder der wird von einem weiteren Skript erzeugt. -- hgzh 12:03, 3. Sep. 2021 (CEST)
Ja, ich hatte links nie einen, daher muss das wohl das Skript sein. Rechts ist Standard. --XanonymusX (Diskussion) 12:25, 3. Sep. 2021 (CEST)
Danke Hgzh, da die PDD/addEditAndRevertLinks.js direkt in mein monobook.js Benutzer:Regi51/monobook.js#L-287 an mehreren Stellen eingebunden ist, könnte ich da selbst etwas machen? PDD scheint Urlaub zu haben, war am 19. August 2021 das letzte Mal online. Ihr habt beide recht, dass das links nicht das Gleiche wie rechts war. Jedenfalls konnte man links auf einen Link klicken, hatte dann eine Begründungsauswahl, konnte den Text auch frei wählen und setzte – unabhängig wie viele Versionen dazwischen lagen – auf diese Version zurück. Gruß —Regi51 (Disk.) 12:47, 3. Sep. 2021 (CEST)
Ja, das ist genau die Funktion von addEditAndRevertLinks.js - ich würde noch etwas abwarten wollen, falls PDD selbst in seinem Skript aktiv wird, ansonsten setze ich das direkt um. Gruß, -- hgzh 13:15, 3. Sep. 2021 (CEST)
Danke, das wäre sehr schön. Ich frage mich nur, wieso das plötzlich nicht mehr geht, obwohl weder an PDD's Script noch ich an meinem Monobookscript etwas geändert haben. Gruß —Regi51 (Disk.) 15:36, 3. Sep. 2021 (CEST)
Grund ist wohl eine Softwareänderung bei der Diffanzeige. Die bisherige Zeile 32 im Skript prüft auf genaues Vorhandensein des einzigen CSS-Klassennamens diff-otitle bzw. diff-ntitle. Es gibt nun aber zusätzlich eine weitere Klasse, die kennzeichnet, ob wir uns auf der linken oder rechten Seite des Diffs befinden. Folglich schlägt die genannte genaue Prüfung fehl, stattdessen muss geprüft werden, ob in der Liste von Klassen diff-otitle oder diff-ntitle enthalten sind. Gruß, -- hgzh 15:48, 3. Sep. 2021 (CEST)
Hier [9] ist eine Änderung vom 27. Juli, könnte es das gewesen sein? --MBq Disk 16:04, 3. Sep. 2021 (CEST)
Ja, scheint das Warmlaufen für die Copy&Paste-aus-Diff-Funktion zu sein. -- hgzh 16:35, 3. Sep. 2021 (CEST)
Sollte wieder gehen. -- hgzh 09:36, 8. Sep. 2021 (CEST)
Danke! --Millbart talk 10:00, 8. Sep. 2021 (CEST)
Dank auch von mir! Superarbeit, Hgzh. Gruß —Regi51 (Disk.) 12:34, 8. Sep. 2021 (CEST)
Dieser Abschnitt kann archiviert werden. —Regi51 (Disk.) 12:35, 8. Sep. 2021 (CEST)

Unterschiedlicher Inhalt in App und Web[Quelltext bearbeiten]

Hallo zusammen,

ich habe einen Artikel bearbeitet und der neue Abschnitt ist in der App sichtbar, aber nicht im Web. Woran kann das liegen? (nicht signierter Beitrag von Marketing sparstrom (Diskussion | Beiträge) 13:55, 6. Sep. 2021 (CEST))

@Marketing sparstrom: Jetzt nach Sichtung (!) und Ergänzung müsste er hier sichtbar sein. Gruß, --Wi-luc-ky (Diskussion) 18:01, 6. Sep. 2021 (CEST)

Die zum Ausführen von Skripten vorgesehene Zeit ist abgelaufen.[Quelltext bearbeiten]

Nachdem wir in der Redaktion Chemie nicht recht vorankommen, die Frage hier... In Liste der Chemikalien nach Proposition 65 erscheint nach einer bestimmten Anzahl von Vorlageneinbindungen die Meldung "Die zum Ausführen von Skripten vorgesehene Zeit ist abgelaufen.". Kennt jemand den Hintergrund und kann helfen das zu beheben? Rjh (Diskussion) 08:34, 7. Sep. 2021 (CEST)

Der Artikel verwendet die Vorlage:CASRN zu häufig und müsste geteilt werden. -- hgzh 09:25, 7. Sep. 2021 (CEST)
(BK) Oder man vereinfacht die Vorlage, indem man bei der Prüfziffernberechnung die Multiplikation mit 1 rausnimmt. Das ist zwar auch nicht die Lösung schlechthin, aber das Teilen wird erstmal rausgezögert. --Wurgl (Diskussion) 10:47, 7. Sep. 2021 (CEST)
Ich bin mir nicht sicher, ob das einen Effekt hätte. Die Fehlermeldung bezieht sich auf das Lua-Skript, und die Multiplikation mit 1 interessiert ja eigentlich nur die normale expr-Parserfunktion. Das Problem ist eher der Wikidata-Abgleich. -- hgzh 12:06, 7. Sep. 2021 (CEST)
Ich hab das in der Vorschau ausprobiert. Mit der Multiplikation hatte ich Fehler, ohne diese waren die Fehler weg. Kann natürlich auch sein, dass ich mal einen langsameren und mal einen schnelleren Server erwischt hab. --Wurgl (Diskussion) 12:30, 7. Sep. 2021 (CEST)
Oh, es gibt eine obere Grenze für Vorlagen ? Wie viele Vorlagen darf man denn einbinden ? Gibt es eine Alternative? Weil Teilen der Liste ist unschön. Rjh (Diskussion) 10:42, 7. Sep. 2021 (CEST)
Ja es gibt einige Obergrenzen. Wenn du dir den Source der Webseite des Artikels anguckst, ganz am Ende sind alle diese Limits und die erreichten Werte als HTML-Kommentar zu lesen. --Wurgl (Diskussion) 10:49, 7. Sep. 2021 (CEST)
Siehe dazu auch Hilfe:Vorlagenbeschränkungen. Im Abschnitt Lua wird das Problem erwähnt, die Liste frisst im Moment mehr als die erlaubten zehn Sekunden Ausführungszeit. -- hgzh 12:07, 7. Sep. 2021 (CEST)
Das Problem ist der ineffiziente Prüfzifferncheck in Vorlage:CASRN, ohne den geht es problemlos. Ich würde vorschlagen, diesen in Lua zu reimplementieren. --Count Count (Diskussion) 12:25, 7. Sep. 2021 (CEST)
Das wäre natürlich hilfreich - aber leider sind hier LUA-Programmierer chronisch knapp. Ich bin nur nicht sicher, ob das ausreichen wird, denn die Tabelle bräuchte auch noch bei jedem Eintrag in der Spalte "Gelistet seit" die Vorlage:DatumZelle. Ich fürchte, dass damit dann wieder die Limits geknackt werden.--Mabschaaf 12:35, 7. Sep. 2021 (CEST)
Wenn ich das mit der Parameterübergabe an die Vorlage noch hinkriege (und die Rückgabe) dann könnte ich mich an Lua versuchen. Den Prüfzifferncheck habe ich unter Benutzer:Rjh/Test2 schon mal. Also ist mein allererster Versuch mit Lua, also nicht schimpfen. Rjh (Diskussion) 20:46, 8. Sep. 2021 (CEST)
Kann mir jemand sagen, wie ich die Lua Methode und deren Einbindung in die Vorlage teste, ohne tausende Seiten zu zerschießen? Rjh (Diskussion) 08:20, 9. Sep. 2021 (CEST)
Siehe Hilfe:Vorlagenspielwiese. --Count Count (Diskussion) 08:23, 9. Sep. 2021 (CEST)
Danke. Das war ja ein Krampf höchster Güte. Na immerhin geht es jetzt. Hab ich das Lua-Modul richtig einsortiert und ist das jetzt "fail safe" ? Gebracht hat es anscheinend was. Rjh (Diskussion) 19:39, 9. Sep. 2021 (CEST)
Nachtrag: Sehe ich das richtig, dass anhand der Profiling-Statistik nun nur noch knapp 1 von 10s für die Seite gebraucht wird? Dann könnte es ja für das Datum doch reichen. Rjh (Diskussion) 22:09, 9. Sep. 2021 (CEST)
Ja genau, sieht gut aus. Danke, dass du dich der Sache angenommen hast. --Count Count (Diskussion) 22:25, 9. Sep. 2021 (CEST)
Dieser Abschnitt kann archiviert werden. Rjh (Diskussion) 08:14, 10. Sep. 2021 (CEST)

Nächste Woche könnte es ein Problem mit CSS geben[Quelltext bearbeiten]

Gruß euch,

Leider schreibe ich fast kein einziges Wort Deutsch. I don't fully understand this potential problem, but the part that I grasped is that there's going to be a change that might affect some user scripts/gadgets that depend on something in the CSS. This will probably appear here at the German Wikipedia next Thursday (i.e., 8 days from now).

This change was made months ago at three Wikipedias, and I don't remember any problems there. I assume that the overall risk is fairly low. However, there are more gadgets here than at most wikis, so perhaps the risk is higher here. So: If a gadget breaks next Thursday, please check the CSS.

Thanks, --Whatamidoing (WMF) (Diskussion) 19:50, 15. Sep. 2021 (CEST)

Thank you for heads-up, and attempting German.
Full English is fine on this tech page, and more than hi and bye is not needed in German.
The issue is on DiscussionTools, and I am not aware of any CSS in gadgets nor frequently touched user resources that are affecting anything in talk pages.
If any, we will learn in the next weeks, and should find remedies.
Greetings --PerfektesChaos 20:57, 15. Sep. 2021 (CEST)
I added some technical details to the linked task. These are the same changes that are currently applied when you enable the "Discussion tools" beta feature ("Diskussions-Werkzeuge"), so you can test today whether your scripts/gadgets work fine with that. We're not actually expecthing anything to break (but you never know…). --Matma Rex (Diskussion) 21:00, 15. Sep. 2021 (CEST)
At a quick glance I don't see any issues popping up with these changes. But thank you for notifying. Regards, -- hgzh 23:03, 16. Sep. 2021 (CEST)