Wikipedia:Technik/Werkstatt

Automatische Archivierung

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

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

Dauerbaustellen; Spezifikationen für wünschenswerte Werkzeuge

• Echo-Filter
• Weiterleitungshinweis
• Warnung wenn Zusammenfassung fehlt
• Shortcut-Tooltip
• Mehrfach-Sichtungen
• prettytable und wikitable
• Schriftgröße 100%
• Beobachtung nach Karenzzeit beenden
• Mit Maus verschiebbare große Grafik
• Suchergebnis direkt anspringen
• ISBN-Suchbeschleuniger
• Speicher-Button-Aktionen
• Wikilink statt URL in Zusammenfassungszeile
• Hinweis auf Fehler im HTML-Text
• Fehler im Bearbeitungsfeld hervorheben
• Hervorhebung bestimmter Wikilinks
• OSM weltweit
• collapsible Herausforderung

MediaWiki:Common.js/watchlist.js

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

Nur mal drübergeschaut: Mir fehlt da noch ein loader.using mit mediawiki.util und jquery.cookie. Mit Großbuchstaben beginnende Variablennamen sind mir persönlich nicht so lieb. Der dritte Parameter undefined wirkt überflüssig. Man könnte das CSS auch vereinfachen, wenn man die Rules kombiniert und dann nur noch ein display:none hat. Vielleicht komplett auf jQuery umsteigen? Du nutzt einmal setAttribute mit style und einmal obj.style. Auch wenn das letzter für nur ein Attribut einfacher ist, könnte man es einheitlich gestalten. Alles unverbindlich und nur wenn du es auch sinnvoll findest. Der Umherirrende 19:54, 11. Apr. 2012 (CEST)

Meine Überarbeitungen sind noch nicht abgeschlossen. Der Rahmen ist die Empfehlung von mw:Manual:Coding conventions/JavaScript#Closures, die restliche Programmierung ist noch nicht überarbeitet. Ich wollte zuerst Testen, ob CSS hier die gewünschte Verbesserung bringt. --Fomafix (Diskussion) 20:06, 11. Apr. 2012 (CEST)

Je nach Ergebnis von bugzilla:37187 würde ich statt dem Cookie lieber eine Benutzereinstellung sehen. --Schnark 10:21, 29. Mai 2012 (CEST)

Ja, wenn das inzwischen möglich ist, wäre das eine feine Sache. Vielleicht lässt sich das auch mit der neuen Funktion der Änderungen seit dem letzten Besuchen auch realisieren. Das wäre noch eleganter, denn das kommt ohne zusätzliche Speicherung von persistenten Daten aus und ist universeller. --Fomafix (Diskussion) 10:27, 29. Mai 2012 (CEST)

Kann über die API angefragt werden, was die letzte besuchte Revision einer Seite ist? Wenn ja wie? Den Besuchszähler kann man auf die aktuelle Revision setzten, indem man eine Seite besucht. Geht das auch über die API? --Fomafix (Diskussion) 09:51, 31. Mai 2012 (CEST)

Die Hilfe zu action=query&list=watchlist führt unter wlprop den Wert notificationtimestamp an: Adds timestamp of when the user was last notified about the edit, ein Update ist wohl über $.get('/w/index.php?title=...') möglich. Allerdings müsste man dazu alle Benutzer zwingen, eine bestimmte Seite zu beobachten; da man außerdem auf die Antwort der API warten müsste, würde es zudem zu sichtbaren Verzögerungen beim Ausblenden kommen. (Außer man blendet erst mal auf Verdacht aus, und dann je nach Antwort der API wieder ein.) --Schnark 10:08, 31. Mai 2012 (CEST)

Soviel habe ich inzwischen auch herausbekommen. wl_notificationtimestamp existiert nur, wenn die Seite in mw:Manual:Watchlist table ist. Zuerst müsste die Seite per API auf die Beobachtungsliste gesetzt werden, um das notificationtimestamp verwenden zu können. Das bringt mich auf eine andere Idee. Wäre es möglich das Einblenden und Ausblenden der Nachrichten über Einträge in der Beobachtungsliste zu steuern? Ich mache mir ein paar Gedanken. Auch das verzögerte Ein- oder Ausblenden ist ein wichtiges Thema. Derzeit geschieht Ausblenden auch etwas verzögert, weil JavaScript erst nach dem vollständigen Laden der Seite ausblendet. Ein zusätzlicher Request ist aber eine deutliche längere Verzögerung. --Fomafix (Diskussion) 16:05, 31. Mai 2012 (CEST)

Über notificationtimestamp wird das "Fette" auf der Beobachtungsliste oder die E-Mail-Benachrichtigung gesteuert. Dort steht der Timestamp der ersten Änderung, die man noch nicht gesehen hat. Per API kann man das aktuell nicht zurücksetzen (Bug 18758). Der Umherirrende 16:18, 31. Mai 2012 (CEST)

Bug 18758 ist umgesetzt worden. Was für Möglichkeiten gibt es nun? --Fomafix (Diskussion) 15:33, 2. Dez. 2012 (CET)

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

Wenn es nur darum geht, das ist leicht rauszupatchen, indem man getElementsByClassName(docobj, 'div', 'watchlist-message') durch $('div.watchlist-message', docobj).get() ersetzt (getestet, funktioniert). --TMg 21:49, 5. Nov. 2013 (CET)

Ich hab mir die Version von Fomafix nochmal angesehen. So ganz funktioniert sie aktuell nicht. Zum einen ist .watchlist-message aktuell eine Klasse, keine ID. Vor allem sind die aktuell zwei Kästen in MediaWiki:Watchlist-summary per display:none standardmäßig ausgeblendet. Ich halte das für eine sehr gute Idee. Wer JavaScript abgeschaltet hat, hätte sonst überhaupt keine Möglichkeit, die Meldungen verschwinden zu lassen. Dass die Seite beim Einblenden der Kästen kurz hüpft, halte ich für kein Problem. Der Benutzer nimmt die Kästen auf diese Weise sogar besser wahr, liest sie kurz und klickt sie weg. Danach stört (dank des hart kodierten display:none) garantiert nie wieder ein Hüpfer den Seitenaufbau. --TMg 22:16, 5. Nov. 2013 (CET)

Ich habe auf beta einen kleinen Test gestartet: Das ready-Event tritt schon vor dem Laden des /watchlist.js-Skripts auf, sodass es für den Seitenaufbau keine Rolle spielt, ob die gelesenen Boxen gleich beim Laden per CSS (wie bei Fomafix) oder wie bisher per JavaScript nach dem Auftreten des ready-Events ausgeblendet werden. --Schnark 10:22, 6. Nov. 2013 (CET)

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

Formeldarstellungsfehler (LaTeX) mit Android

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

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

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

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

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

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

Bei mir auf dem Desktop-Firefox sind die Formeln in der Einleitung ganz normal, und die darunter (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)

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

Liebe Wiki-Techniker,

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

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

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

Wie ich die hiesigen Pappenheimer kenne, ist die Idee bestimmt nicht neu, es hatte halt noch keiner Lust sie zu programmieren. Aber ich lasse mich gerne überaschen.... 129.13.72.198 12:36, 16. Mär. 2017 (CET)

Hat noch niemand sonst diesen Beitrag gesehen? Ich würde mich über eine Rückmeldung freuen! --Fährtenleser (Diskussion) 19:32, 22. Mär. 2017 (CET)

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

Das ist zwar nett, aber doch keine Wiki-Lösung! Dabei kannst du die Legende nicht sehen und musst etliche Schritte vollführen, die viele User überhaupt nicht können/kennen. Meine Frage bleibt offen: Wie wäre es mit einer Lupenfunktion? --Fährtenleser (Diskussion) 07:19, 27. Mär. 2017 (CEST)

Hat noch niemand außer ProloSozz diesen Vorschlag gesehen? Er würde den Informationswert von großen Landkarten beträchtlich erhöhen! Wo sind die Profis? --Fährtenleser (Diskussion) 12:27, 4. Apr. 2017 (CEST)

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

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 &? --mfb (Diskussion) 19:10, 23. Sep. 2017 (CEST)

Script für mobile Version

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

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

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

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

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

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

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

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

Das wird wohl kaum auf breite Zustimmung stoßen.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fehlermeldung, kein Edit möglich

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:
  • mw.loader.load( "https://de.wikipedia.beta.wmflabs.org/w/index.php?title=MediaWiki:Gadget-Vorlagenmeister/core.js&action=raw&ctype=text/javascript" );
  • Es gibt dann konkreter eingrenzende Fehlermeldungen.

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

• mw.loader.load( "https://de.wikipedia.beta.wmflabs.org/w/index.php?title=Benutzer:PerfektesChaos/buttonWikiEditorSafari5.js&action=raw&ctype=text/javascript" );

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

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'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:

• https://www.wikipedia.org/?search=Coincoin%20et%20les%20z'inhumains
• https://www.wikipedia.org/?search=Coincoin%20et%20les%20z%27inhumains
• Diese erste Form wird vom Wiki-Server in der Darstellung bereits HTML-encoded, Ampersand ggf. ebenso.

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

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)

Wenn ein Beitrag versteckt wird, bricht die Versionsgeschichte ab

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)

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)

Druckversion: obsolete Seitenelemente

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

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

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)

mmh, 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 – ^{(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)

Mouse-over-Vorschau bei Image-Karten

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)

Zeilenumbruch und Fußnoten

Gemeldet in Phabricator
Task T125480

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

VE „verbessert“ DOI

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)

Hinweis auf ungesichtete Versionen in Beobachtungsliste

Gemeldet in Phabricator
Task T237246

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

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)

Deutsch-Englisch-Mischmasch im Menu des Timeless-Skins

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

Andreas M. Fleckner

Gemeldet in Phabricator
Task T246720

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

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

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

Gemeldet in Phabricator
Task T249986 Resolved

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:

• https://de.wikipedia.org/w/index.php?title=Luftwaffenkaserne&diff=198743120&oldid=198742910&diffmode=source
• https://de.wikipedia.org/w/index.php?title=Ausbildungsbereich_Streitkr%C3%A4ftegemeinsame_Taktische_Feuerunterst%C3%BCtzung/Indirektes_Feuer&diff=198740205&oldid=198739944&diffmode=source

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:/<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?

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)

Einbindung von Userscripten in Special:MyPage/common.js

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:

• „Mobil“ ist die Skin „MinervaNeue“ und nur über Special:MyPage/minerva.js zu beeinflussen.
• „Desktop“ sind alle anderen Skins und nur über Special:MyPage/common.js zu beeinflussen.
• meta:Special:MyPage/global.js wirkt auf beide.

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)

Bearbeitung nicht mehr möglich

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)

Das Problem ist erneut aufgetreten. Hier kann ich problemlos schreiben. Mit Google Chrome verschwindet der Text im Artikelnamensraum allerdings sofort. Würde ich die Bearbeitung so abspeichern, hätte ich den ganzen Text gelöscht... Mit Internet Explorer, jetzt Microsoft Edge, geht alles problemlos. Woran kann das liegen? DieNummer9 (Diskussion) 16:08, 29. Sep. 2021 (CEST)

Artikel erstellen: Button Quelltext-Editor

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

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)

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

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

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)

Doppeltes Eingabefeld für Zusammenfassungszeile

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

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)

Wikidata-Einbindung defekt

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)

Frage zu Weblinks auf mobile und Desktopversion

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)

Vorlagen die einen Listeneintrag generieren

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.

• Vorlage:Kongressbio (Beispiel: John Ashcroft#Weblinks)
• Vorlage:Autobahnatlas (Beispiel: Bundesautobahn 44#Weblinks)
• Vorlage:BDLWuppertal (Beispiel: Zeche Karl#Weblinks)
• Vorlage:RIK-PH (Beispiel: Kreuzweg an der Halde Haniel#Weblinks)
• Vorlage:RIK-TR (Beispiel: Route der Industriekultur – Duisburg: Stadt und Hafen#Weblinks)
• Vorlage:RIK-AP (Beispiel: Chemiepark Marl#Weblinks)
• Vorlage:RIK-SL (Beispiel: Wohlfahrtsgebäude Kolonie Eving#Weblinks)
• Vorlage:Hillbilly-Music.com (Beispiel: Jerry Byrd#Weblinks)
• Vorlage:AMACAD-Link (Beispiel: Liste der Mitglieder der American Academy of Arts and Sciences/2018#Weblinks)
• Vorlage:NFL Rosterspieler (Beispiel: Pro Bowl 2015#Team Carter)
• Vorlage:Swisscovery (kein fehlerhaftes Beispiel)
• Vorlage:Online-Bauinventar BE (Beispiel: Liste der Kulturgüter in Aarberg#Weblinks)
• Vorlage:Findagrave wenn der Parameter Abruf leer ist (Beispiel: Marlon Brando#Weblinks, siehe Bild rechts)
• Möglicherweise noch weitere, die das Sternchen auf etwas komplexere Weise generieren

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)

Datei:Screenshot 2021-02-23-20-36-59-448 org.wikipedia.jpg

Ende des Abschnitts Elektrotechnik#20._Jahrhundertin der App

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)

wenn die Sternchen nicht als Liste gelten sollen, sollte man vielleicht " *" schreiben, also mit Leerzeichen davor. Weil dann ja nicht das automatische Newline kommt. --2A02:3035:B07:530:180:786A:E014:DDFD 17:05, 6. Nov. 2024 (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)

Schnarks Normdaten-Skript

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)

In deinen Code den Temlate editor hinzufügen, um manuell nachladen zu können: mw.loader.load('https://de.wikipedia.org/w/index.php?title=Benutzer:Schnark/js/templateEditor.js&action=raw&ctype=text/javascript'); --LG Dwain 11:39, 20. Mär. 2023 (CET)

Probleme bei "Abrufstatistik" ganz unten, vor dem Link zu den Autoren

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)

Technisches zur Wikipedia-App

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)

Aktivitätsanzeige beim Nachladen auf der Beobachtungsliste

Ich habe diese Frage kürzlich in Hilfe Diskussion:Beobachtungsliste#Aktivitätsanzeige beim Nachladen gestellt, wurde dort aber hierher verwiesen.

Ich bin nicht sicher, ob ich den Fragetext hierher kopieren oder nur verlinken sollte. Falls gewünscht, kann dieser Absatz durch den Originalfragetext ersetzt werden.

--Frupa (Diskussion) 20:51, 20. Nov. 2021 (CET)

RefToolbar einrichten

Hallo Leute, ich bin seit Jahren sehr aktiv bei der englischen Wikipedia. Vieles gefällt mir dort besser, zum Beispiel, dass die RefToolbar zum leichten Einfügen von Quellenangaben von vornherein aktiviert ist.

Ich würde gerne auch hier bei de.wiki leichter Quellenangaben einfügen können und versuche deswegen RefToolbar einzurichten. Dieser Nachricht von @PerfektesChaos: auf Wikipedia:WikiProjekt Vorlagen/Werkstatt entnahm ich, dass man den Skript von en:Wikipedia:RefToolbar/2.0/porting seinem common.js hinzufügen kann: Benutzer:Robby.is.on/common.js Bisher hat das leider nicht dazu geführt, dass ich die RefToolbar sehe.

Hat jemand Tipps wie ich weiterkomme? Robby.is.on (Diskussion) 09:49, 23. Nov. 2021 (CET)

Englische Kurzbeschreibung bei Modulseiten

Gemeldet in Phabricator
Task T299279

Ich kann mir grad nicht vorstellen, woran es liegt, aber im Moment bekomme ich in den Suchvorschlägen (neuer Vector, Minerva) bei allen Seiten deutschsprachige Kurzbeschreibungen (soweit vorhanden), außer im Modul-Namensraum, da sind sie plötzlich englisch (also meistens Wikimedia module). Was ist da passiert? --XanonymusX (Diskussion) 16:38, 6. Dez. 2021 (CET)

Kann ich bestätigen, mir fällt auf die Schnelle auch keine mögliche Ursache ein (kann es zeitlich auch nicht eingrenzen), in anderen Wikis ist es auch so. Einen phab-Task habe ich auch nicht gefunden. Wer meldet es? Gruß, -- hgzh 18:57, 6. Dez. 2021 (CET)

Grafik ändern klappt nicht

Habe soeben versucht, meine Grafik auf neuen Stand zu bringen. Komme leider mit den konfusen Fehlermeldungen nicht zurecht: Z.B. "Dateien mit unpassenden oder ohne ausreichende Lizenzinformationen werden ohne weitere Nachfrage gelöscht." Ich will doch daran überhaupt nicht ändern sondern nur die geänderte Grafik hochladen! Habe das vermeintlich gemacht und dann kommt so eine unverständliche Fehlermeldung! Oder, völliger Unsinn: "Die hochgeladene Datei ist ein exaktes Duplikat der aktuellen Version von File:Endglazial - Eiskerndaten mit Kulturen.png." Und das, obwohl auf der Seite noch die alte Grafik erscheint. Unverständlich. Bin zu blöd, das zu verstehen. - Beim ersten Original-upload vor 'Jahren gab es diese Schwierikeiten nicht.HJJHolm (Diskussion) 12:15, 29. Jan. 2022 (CET)

api, images, redirect

Hi, hier als Beispiel die Abfrage aller Bilder auf dem französischen Artikel für 'Erde':

• Spielwiese: https://fr.wikipedia.org/wiki/Sp%C3%A9cial:ApiSandbox#action=query&format=json&prop=images&titles=Terre&redirects=1&imlimit=5000
• API: https://fr.wikipedia.org/w/api.php?action=query&format=json&prop=images&titles=Terre&redirects=1&imlimit=5000

werden hier mit &redirects=1 nicht die Weiterleitungen der Bilder aufgelöst?

• 
  file
• 
  weiterleitung

beide Bilder sind enthalten, eines jedoch ist eine Weiterleitung
Duplikate werden entfernt wenn ich das richtig geprüft habe
was muss ich ändern oder Nachschaltung um Weiterleitungen der Bilder aufzulösen und evtl. daraus entstehende Duplikate zu entfernen? Danke im Voraus --Mrmw (Diskussion) 23:56, 1. Feb. 2022 (CET)

Meiner bescheidenen Meinung nach hast du keine Chance, auch nicht mit der Datenbank.

Zur Datenbank: Wenn in einem Wiki ein Bild eingefügt wird, welches in Commons eine Weiterleitung ist, dann hast du auf commons in der entsprechenden Tabelle namens globalimagelinks zwei Einträge: Einen Eintrag auf die Weiterleitung und einen Eintrag auf das Bild.

Beispiel: Cross-Slab von Edderton hat zwei Bilder. das linke Bild ist im Quelltext [[Datei:"Clach Biorach" (The Pointed Stone), Ardmore - geograph.org.uk - 915406.jpg|mini, wenn du draufklickst, kommst du auf File:"Clach Biorach" (The Pointed Stone), Edderton - geograph.org.uk - 915406.jpg (beachte: Ardmore vs. Edderton). In der Datenbank sieht das so aus:

MariaDB [commonswiki_p]> select * from globalimagelinks where gil_page = 8078806 and gil_wiki = 'dewiki';
+----------+----------+-----------------------+--------------------+-------------------------+------------------------------------------------------------------------------+
| gil_wiki | gil_page | gil_page_namespace_id | gil_page_namespace | gil_page_title          | gil_to                                                                       |
+----------+----------+-----------------------+--------------------+-------------------------+------------------------------------------------------------------------------+
| dewiki   |  8078806 |                     0 |                    | Cross-Slab_von_Edderton | "Clach_Biorach"_(The_Pointed_Stone),_Ardmore_-_geograph.org.uk_-_915406.jpg  |
| dewiki   |  8078806 |                     0 |                    | Cross-Slab_von_Edderton | "Clach_Biorach"_(The_Pointed_Stone),_Edderton_-_geograph.org.uk_-_915406.jpg |
| dewiki   |  8078806 |                     0 |                    | Cross-Slab_von_Edderton | Commons-logo.svg                                                             |
| dewiki   |  8078806 |                     0 |                    | Cross-Slab_von_Edderton | Edderton_Cross_Slab.jpg                                                      |
+----------+----------+-----------------------+--------------------+-------------------------+------------------------------------------------------------------------------+

Also 4 Einträge, wo nur drei Bilder sind und sowohl die Weiterleitung als auch das Weiterleitungsziel ist zu finden.

Wenn du in der Datenbank also auch für das Weiterleitungsziel einen Eintrag hast obwohl das Ziel selbst nicht referenziert ist, dann kann das arme API nix rausfinden.

Du könntest auf Commons alle Seiten in deinem Wiki rausfinden, wo eine Weiterleitung auf ein Bild eingetragen ist (sind übrigens 14657, davon 11945 im ANR). Und dann durch Untersuchung des Quelltextes der Seite gucken, ob sowohl Weiterleitung als auch Bild zu finden ist – mit all den Problemen wie Unterstreichung vs. Leerzeichen, Prozent-Kodierung von Sonderzeichen oder auch &nbsp; statt Leerzeichen im Namen. (Kennst du jemanden, der eine Bachelor-Arbeit schreiben will, S,CNR)

Die query auf Commons wäre sowas wie quarry:query/62093 --Wurgl (Diskussion) 09:56, 2. Feb. 2022 (CET)

danke für die antwort

ich denke rein technisch kann schon abgefragt werden ob ein file eine weiterleitung ist oder nicht - es wird sogar das ziel ausgegeben

• spielwiese https://commons.wikimedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=&list=&titles=File%3AArticle%20de%20qualit%C3%A9.svg%7Cfile%3AArticle%20de%20qualite.svg&redirects=1
• api https://commons.wikimedia.org/w/api.php?action=query&format=json&prop=&list=&titles=File%3AArticle%20de%20qualit%C3%A9.svg%7Cfile%3AArticle%20de%20qualite.svg&redirects=1

aber ich hätte gehofft, die query 'images' würde das intern auflösen wenn ich den schalter für 'redirects' auf '1' schalte --Mrmw (Diskussion) 10:54, 2. Feb. 2022 (CET)

Das API kann auch nix anderes als auf die Datenbank zugreifen und wenn diese Info dort nicht zu finden ist, dann ist es eben nicht möglich (auch nicht technisch). Auch in der Datenbank des lokalen Wikis sind genau die korrespondierenden 4 Links zu finden, wie in der Datenbank von commons.

Wenn du rausfinden willst ob nur der Link auf die Weiterleitung oder zusätzlich noch ein Link auf das Weiterleitungsziel vorhanden ist, musst du entweder den Dump untersuchen oder per API den Quelltext holen und den untersuchen. --Wurgl (Diskussion) 11:05, 2. Feb. 2022 (CET)

Nachtrag: Der Schalter "Redirects" löst die Redirects der Quellseite auf. Bei deinem Spielwiesenlink könntest du fr:Terrestre oder fr:Gaïa (planète) statt fr:Terre im Parameter "titles" angeben. --Wurgl (Diskussion) 11:12, 2. Feb. 2022 (CET)

@Wurgl: danke, ja das mit dem redirect-schalter ist mir jetzt klar

aber bei dem rest bin ich mir nicht sicher ob wir aneinander vorbeireden - womöglich habe ich mich unklar ausgedrückt

an meinem zweiten link-paar ist meiner meinung zu sehen, dass die api für einen bestimmtel titel ermitteln kann, ob es sich um weiterleitung handelt oder nicht, bei der weiterleitung wird auch das weiterleitungsziel angegeben

was ich gern hätte: die liste aller bilder für einen artikel, dabei sollten alle weiterleitungen der bilder aufgelöst werden, im gezeigten beispiel wird die weiterleitung Article de qualite.svg aufgelöst und durch Article de qualité.svg ersetzt, am ende sollten die duplikate, und somit eines der beiden letztgenannten entfallen - meiner meinung sollte das technisch möglich sein, salopp zusammengefasst könnte man sagen, mir sind die weiterleitungen egal, es sollen nur keine duplikate entstehen in den ergebnissen durch nicht aufgelöste weiterleitungen --Mrmw (Diskussion) 15:53, 2. Feb. 2022 (CET)

Mir ist schon klar was du willst. Doppelte Bilder die sich nur unterscheiden, weil das eine ist Bild und das andere ist Weiterleitung. Nur die Datenbank liefert das nicht.

MariaDB [dewiki_p]> select * from imagelinks where il_from = 8078806;
+---------+------------------------------------------------------------------------------+-------------------+
| il_from | il_to                                                                        | il_from_namespace |
+---------+------------------------------------------------------------------------------+-------------------+
| 8078806 | "Clach_Biorach"_(The_Pointed_Stone),_Ardmore_-_geograph.org.uk_-_915406.jpg  |                 0 |
| 8078806 | "Clach_Biorach"_(The_Pointed_Stone),_Edderton_-_geograph.org.uk_-_915406.jpg |                 0 |
| 8078806 | Commons-logo.svg                                                             |                 0 |
| 8078806 | Edderton_Cross_Slab.jpg                                                      |                 0 |
+---------+------------------------------------------------------------------------------+-------------------+

Ich hab oben für diese Seite Cross-Slab von Edderton (ich nehme diese, weil da nur drei Bilder drinnen sind, das ist per Auge schnell zu überblicken) die Bilderchen aus der Sicht von Commons rausgefischt. Und hier nochmals die Bilderchen aus der Sicht der deWP. Da ist kein Unterschied zwischen dem Weiterleitungslink auf Commons und dem eigentlichen Bild.

Die Info gibts also nicht. Woher soll das API denn die Daten haben, wenn nicht aus der Datenbank?

Wie gesagt: Die Query (ich hab da noch eine Spalte dazugepappt) liefert dir Kandidaten wo ein Dateiname in Commons eine Weiterleitung ist und die musst du per Script noch filtern, besser geht es wohl nicht. --Wurgl (Diskussion) 16:13, 2. Feb. 2022 (CET)

@Wurgl: ich versteh nicht wie du beharrlich deine meinung wiederholst, die datenbank könnte keine aussage dazu treffen ob ein bild-titel eine weiterleiterung ist oder nicht, ohne auf meine api-abfrage einzugehen:

• api: https://commons.wikimedia.org/w/api.php?action=query&format=json&prop=&list=&titles=file%3A%22Clach%20Biorach%22%20(The%20Pointed%20Stone)%2C%20Ardmore%20-%20geograph.org.uk%20-%20915406.jpg%7Cfile%3A%22Clach%20Biorach%22%20(The%20Pointed%20Stone)%2C%20Edderton%20-%20geograph.org.uk%20-%20915406.jpg&redirects=1
• spielwiese: https://commons.wikimedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=&list=&titles=file%3A%22Clach%20Biorach%22%20(The%20Pointed%20Stone)%2C%20Ardmore%20-%20geograph.org.uk%20-%20915406.jpg%7Cfile%3A%22Clach%20Biorach%22%20(The%20Pointed%20Stone)%2C%20Edderton%20-%20geograph.org.uk%20-%20915406.jpg&redirects=1

hier frage ich die beiden bilder aus deiner übersichtlichen beispielseite ab, aus dem ergebnis der abfrage geht doch ganz klar hervor welcher bildtitel eine weiterleiterung ist (und wohin sie führt) und welcher bild-titel keine weiterleitung ist, und somit ein tatsächliches file darstellt

und dachte nur, das könnte man direkt in der qurey für 'images' miteinbziehen --Mrmw (Diskussion) 22:42, 2. Feb. 2022 (CET)

Guck mal den Artikel Cross-Slab von Edderton an. Wieviele Bilder sind dort verlinkt? Ich zähle 3 Stück. Das Commons-Logo und zwei Steinplatten. Wieviele Einträge hat die Datenbank? Oben ist die Datenbankabfrage dazu. Ich zähle 4 – wo kommt der vierte Eintrag her? Schau dir den Quelltext der Seite an. Dort ist die Weiterleitung auf Commons verlinkt und der zusätzliche Eintrag ist das Weiterleitungsziel, und dieses Weiterleitungsziel findest du im Quelltext nicht. Ergo: Ich kann nicht unterscheiden ob nur die Weiterleitung verlinkt ist, oder ob die Weiterleitung und das Weiterleitungsziel verlinkt ist, beides sieht in der Datenbank gleich aus. --Wurgl (Diskussion) 01:34, 3. Feb. 2022 (CET)

wenn du oder jemand anders nicht auf die von mir gezeigte abfrage bezug nehmt denke ich kann man das thema beschließen, trotzdem danke für die teilnahme, weiss ich immer zu schätzen --Mrmw (Diskussion) 08:38, 3. Feb. 2022 (CET)

Möglich wäre das schon, wenn die API zum Aggregieren der Daten noch die Titel einzeln abfragt. Dann könnte man Weiterleitungen entsprechend ausfiltern. Als Standardverhalten würde ich das aber nicht empfehlen, da die Einbindung des Ziels nun mal über die Weiterleitung erfolgt und damit zunächst mal auch beide relevant sind. Gruß, -- hgzh 01:07, 4. Feb. 2022 (CET)

redirect wirkt auf titles als Eingabe, nicht auf das Ergebnis. Bei Verwendung von generator=images kannst du die Liste der Bilder als Ausgang für ein prop-Module verbinden. Mit imageinfo kann man sich dann weitere Infos dazuholen und dann prüfen, welches eine Weiterleitung ist. https://de.wikipedia.org/w/api.php?action=query&generator=images&titles=Cross-Slab%20von%20Edderton&prop=imageinfo&iiprop=canonicaltitle und dann die Duplikate per canonicaltitle prüfen. Damit sollte es möglich sein im Nachgang die Weiterleitungen aus seinem Ergebnis zu filtern. Das erspart es zu jedem Bild einzeln (oder als Bündel) den Weiterleitungsstatus in einer zweiten Anfrage zu prüfen. Der Umherirrende 19:45, 5. Feb. 2022 (CET)

@Umherirrender: danke, dein tipp mit dem generator und dem kanonischem bildtitel funktioniert für mich - das war genau was ich brauchte

leider finde ich nur selten doku, die mich direkt zu solchen möglichkeiten führen würde - ich wusste dass es generatoren gibt, weiss aber selbst jetzt nach anwendung nicht genau wie sie arbeiten - gibt es entsprechende doku die ich einfach nicht kenne und bis jetzt nicht gefunden habe? danke --Mrmw (Diskussion) 14:24, 19. Feb. 2022 (CET)

Es gibt auf mw.org ein eigenen Namensraum mit Doku - mw:API:Main page, wo auch Grundsätzliches zur Ettiquette oder zu den Möglichkeiten beschrieben ist. api.php als Root-Seite gibt eine generierte Hilfe zu allen Modulen und Parametern, die auch Übersetzt werden kann (Technisch über die Default-Action action=help abgebildet). Des Weiteren gibt es Spezial:ApiSandbox, wo die Hilfe zu Modulen und Parametern einfach kombiniert werden kann (technisch action=paraminfo). Unter Wikipedia:Technik/Datenbank/API gibt es auch noch Links.

Als Mediawiki-Entwickler habe ich aber auch einige der Funktionsweise oder resultierenden Datenbankabfragen über den Code mir beigebracht. action=query arbeitet bei der Verwendung von titles mit einem PageSet. Die prop-Module arbeiten die Seiten aus dem PageSet zusammen ab und bereiten das Rückgabeergebnis entsprechend auf. Mit der Nutzung von generator und einem list-Modul oder prop-Modul erzeugt das list-Modul bzw. prop-Modul auch ein PageSet und dieses wird dann (wie bei titles) von den prop-Modulen entsprechend abgearbeitet. Der Generator ist also nur eine alternative für die Seiten, wo man etwas von haben möchte. Den Generator gibt es auch bei anderen Actions, er funktioniert aber immer gleich. Dabei sind nicht alle Kombinationen der Module untereinander performant. Das kann aber auch einzelne Filter-Parameter treffen. Timeouts von Datenbankabfragen werden dann meistens als Task im Phabricator angelegt und teilweise gibt es auch entsprechendes Tuning der Abfragen. Der Umherirrende 21:20, 21. Feb. 2022 (CET)

Die nichtglobalen "Globalen Einstellungen"

Bei den Einstellungen kann man ja "Globale Einstellungen" auswählen, also für alle Wikis die selben Einstellungen. Hat den Vorteil, dass z.B. auch auf anderssprachigen/andersschriftigen Wikipedias die Standardlinks in der selben gewohnten Sprache erscheinen. Hab ich auch so eingestellt.

Nur ist global eben nicht so ganz global.

Auf Spezial:Globale_Einstellungen#mw-prefsection-echo sind die ersten Punkte die folgenden:

• Bearbeitung auf meiner Diskussionsseite
• Dankeschön
• Diskussionsseiten-Abonnement
• Übersetzungen
• Erwähnung
• …

Auf Wikidata d:Special:GlobalPreferences#mw-prefsection-echo und vermutlich auch auf anderen Wikipedien mit aktivierter Erweiterung "Strukturierte Diskussion" sind die Punkte wie folgt

• Bearbeitung auf meiner Diskussionsseite
• Dankeschön
• Strukturierte Diskussion
• Diskussionsseiten-Abonnement
• Erwähnung
• …

Also ist auf Wikidata der Haken für "Strukturierte Diskussion" zusätzlich, dafür fehlt "Übersetzungen".

Ich finde das ist suboptimal. Okay, diese Erweiterung für strukturierte Diskussionen gibt es in deWP nicht, die gibt es aber in Wikidata, nur woher soll ich als deWP-user denn wissen, dass es in Wikidata zusätzliche Einstellungen gibt, schließlich hab ich ja globale Einstellungen ausgewählt und da hätte ich schon erwartet, dass damit das gesamte Wikiversum abgedeckt wird. Muss ich jetzt erst recht jede Wikipedia besuchen, weil dort könnten ja noch weitere Einstellungen existieren, die mich interessieren könnten. --Wurgl (Diskussion) 20:33, 11. Feb. 2022 (CET)

Nachtrag: Minimalwunsch meinerseits: Auf der Seite "Globale Einstellungen" einen Hinweis anbringen, dass es in anderen Wikipedien weitere Globale Einstellungen gibt. --Wurgl (Diskussion) 20:40, 11. Feb. 2022 (CET)

Vorlage:Annotiertes Bild mit verschiebbarem Inhalt

2017 hatte ich den Vorschlag Lupenfunktion für große Bilder an die Technik-Werkstatt gepostet. Benutzer:Ulamm hatte im gleichen Jahr den Vorschlag Popupfenster für Landkarten gemacht. Leider wurde bislang nichts davon realisiert…

Ich habe heute die Funktion "Annotiertes Bild" mit dem feature "Bildausschnitt" gefunden. Durch eine (vermutlich kleine) technische Erweiterung könnte man die beiden Wünsche vielleicht in dieser Form befriedigen: Wenn der Bildausschnitt im Bildfenster mit der Maus oder über horizontale und vertikale Scrollbalken verschiebbar wäre, könnte man etwa große Karten einmal "üblich" als verkleinerte Ansicht und zudem mit einem Ausschnitt in 100% Bildgröße zeigen, sodass der Benutzer durch Verschieben des Ausschnitts alle Details erkennen kann und dabei gleichzeitig die Legende oder den Text im Blick behält.

Ich würde mich freuen, wenn der Vorschlag auf diesem Weg neuen Schwung bekäme! --Fährtenleser (Diskussion) 06:42, 16. Mär. 2022 (CET)

Website VIAF

Hallo! Ich hab seit einigen Wochen ein Problem auf der Website von VIAF beim Suchen nach den Normdaten. Es erscheint auf dieser Website immer wieder (nicht nur einmal) das Fenster mit den Cookie-Einstellungen, was normalerweise immer nur dann erscheint, wenn man die Browserdaten komplett gelöscht hatte. Könnt ihr vielleicht mal ausprobieren (Seite aufrufen und einfach mal nach was suchen), ob das bei Euch auch so ist - ich weiß nämlich nicht, ob das an der Website liegt oder ggf. an meinem System. Es nervt gewaltig und nimmt viel Zeit in Anspruch, weil man während der Suche immer wieder anklicken muss, ob man die Cookies akzeptiert oder nur die nötigen. Vielen Dank und Grüße--Nadi (Diskussion) 17:52, 8. Jun. 2022 (CEST)

Bei mir gibt es keine Probleme. --Liebe Grüße, Lómelinde Diskussion 18:48, 8. Jun. 2022 (CEST)

Danke! Hat jemand eine Idee, was ich machen kann, falls das an meinem System liegt? Das passiert nur bei dieser Website.--Nadi (Diskussion) 19:17, 8. Jun. 2022 (CEST)

Ich hab auch keine Probleme. Welchen Browser verwendest du? Geht es mit einem anderen? --Wurgl (Diskussion) 19:26, 8. Jun. 2022 (CEST)

Microsoft Edge und über die Google-Suchmaschine. Anderer geht nicht, weil ich mich hieran gewöhnt habe (schlechte Augen und dieser Browser ist sehr übersichtlich und außerdem sehr viel gespeicherte Seiten etc.)--Nadi (Diskussion) 21:47, 8. Jun. 2022 (CEST)

Okay. Dann sorry. Den hab ich nicht. Da kann ich nix sagen. Du hast wahrscheinlich seitenspezifisch Cookies blockiert. Aber wie man das dort feststellt oder ändert … keine Ahnung. --Wurgl (Diskussion) 21:56, 8. Jun. 2022 (CEST)

Abschnittsverlinkung mittels wikEd-Pulldown-Menü funktioniert nicht

Hallo, die Abschnittsverlinkungen in der VG funktionieren nicht, wenn bei wikEd die Funktion /* */ im Pulldown-Menü der ZQ verwendet wird, weil vor und nach dem Abschnittsnamen jeweils ein Leerzeichen eingefügt wird.

Erzeugt wird ein Link nach dem Schema: Lemmatitel#_Abschnittstitel_, wodurch der Link unbrauchbar wird.

• Bsp. 1: VG von Celle, spezieller Diff, wo auf Celle#_Wappen usw. verlinkt wird, der Link aber auf den Artikelanfang führt.
• Bsp. 2: VG von Diskussion:Julia Franck, spezieller Diff, wo auf Diskussion:Julia Franck#_Namensfragen verlinkt wird usw.

Auch ein händisches Einfügen von /* */ führt zu denselben Fehlern, kann aber nach Vorschau seltsamerweise durch Löschen der Leerzeichen vor und hinter dem Abschnittsnamen und nachfolgendes händisches Wiedereinfügen der Leerzeichen korrigiert werden.

Scheint also irgendeine Codierung überflüssiger zusätzlicher Leerzeichens vorzuliegen.

Gruß, --Wi-luc-ky (Diskussion) 19:14, 27. Jun. 2022 (CEST)

Versuche hideduplicatecontribs.js wiederzubeleben, console.log (u.a.) funzt nicht

Hab leider wenig Ahnung von js. Nachdem ich Teile des alten Skripts in der Firefox-JS-Console ausprobiert bzw. mit dem Quelltext von Spezial:Beiträge abgeglichen habe, habe ich "document.getElementById('month')" als eine Fehlerquelle ausgemacht und in meinem Fork ersetzt. Allerdings, bekomme ich keine Rückmeldung von den ebenso eingebauten Console.Debug() oder Console.Error(). Kann mir wer weiterhelfen? --Amtiss, SNAFU ? 15:51, 3. Aug. 2022 (CEST)

Problematische Ergänzung bestimmter Archiv-Links

Auf archive.org dient der Linkpräfix https://web.archive.org/save/ dazu Web-Snapshots bestimmter Internet-Webseiten anzulegen. In aller Regel sollte dieser Präfix nie in Artikelseiten auf Wikipedia eingetragen und ergänzt werden, denn er bewirkt bei jedem Leser, der dem Link folgt, um bsp.-weise einen Einzelnachweis zu prüfen, dass die Webressource bei archive.org von neuem archiviert wird.

Derart Links können derzeit entweder aus Versehen, als Flüchtigkeitsfehler, oder absichtlich in Artikeln ohne weiteres abgespeichert werden.

Da Wikipedia bereits Mechanismen besitzt, um problematische Edits zu erkennen und abzuweisen, sollten diese dahingehend ergänzt werden, dass bei Erkennung dieses Linkpräfix eine erfolgreiche Speicherung unterbunden wird. Im Normalfall haben wünschenswerte, konstruktive Archivlinks anstelle des save eine Zahlenfolge, die Datum und Uhrzeit der Linkarchivierung repräsentiert.

Ob das Problem in der Form z.B. auch für archive.is existiert (und welche URL man da blocken sollte, um ungewünschte Edits zu verhindern), habe ich nicht untersucht. --91.55.172.80 17:42, 21. Okt. 2022 (CEST)

Kartographer-Fehler?

In letzter Zeit passiert es öfter, dass ich Kartographer-Karten, die ich im Vollbild geöffnet habe, nicht mehr schließen kann. Sogar der Zurück-Button im Browser funktioniert dann nicht mehr, zum Beispiel gerade bei Teshima (Insel) passiert. Meistens verwende ich vorher die "In der Nähe" Funktion und die bei Teshima grün eingezeichnete Fläche war nach Roomzoomen verschoben. Wenn ich es jetzt noch einmal versuche gibt es keine Probleme, aber ich hatte es schon mehrmals. --Lupe (Diskussion) 14:48, 30. Mär. 2023 (CEST)

Hatte ich jetzt auch einmal in der englischsprachigen Wikipedia bei en:Singalila National Park. Also hat es nichts mit der In-der-Nähe-Funktion zu tun. Ich kann dann immer nur den Tab schließen oder neu laden (Firefox Browser). --Lupe (Diskussion) 17:52, 8. Apr. 2023 (CEST)

Aktualisierung Liste der Anime-Titel

Hallo! Einige der Unter-Listen der Liste der Anime-Titel können bzw sollen per Skript aktualisiert werden aus den alphabetischen Listen. Leider ist das schon lange nicht mehr passiert und Mps, der das zuletzt gemacht hatte, ist nur noch sporadisch aktiv. Das läuft wohl über Benutzer:Mps/AnimeListenUpdater.cs, aber ich habe keine Ahnung, wie man das benutzt. Kann jemand hier das Skript einsetzen? --Don-kun • Diskussion 20:09, 6. Mai 2023 (CEST)

Schade, dass sich anscheinend niemand darum kümmern kann. --Don-kun • Diskussion 09:12, 22. Jan. 2024 (CET)

API-Problem

Alle paar Tage hat eines meiner Scripte ein Problemchen. Auf die Anfrage https://de.wikipedia.org/w/api.php?action=query&meta=tokens&type=login&format=json kommt die Antwort {"warnings":{"main":{"*":"Unrecognized parameters: meta, type."}},"login":{"result":"Failed","reason":"Incorrect username or password entered. Please try again."}}

Das war am 2.6 um 00:04 (UTC), davor am 29.5 um 8:03, am 24.5 um 15:03 und 14:05, am 20.5 um 21:06 usw. und dazwischen läuft dieses eine Script so grob einmal in der Stunde. Also kann ich sagen, 200 mal geht es gut und dann *patsch*

Üblicherweise, aber nicht immer braucht dieses Script 2 Sekunden, dann ist es mit allem fertig (ganz selten länger). Wenn der Fehler auftritt, dann so ca. 10 Sekunden nach dem Start des Scripts (ich hab im Logfile die Zeiten von Start/Stop und bei jedem Fehler ebenso diese Zeiten).

Jetzt ist diese Anfrage so ziemlich das erste was ich mache, jedenfalls unmittelbar nach curl_init() (mein Kram ist aus hist(e|o)rischen Gründen in PHP geschrieben). Irgendwie weiß ich da nicht weiter. --Wurgl (Diskussion) 16:23, 4. Jun. 2023 (CEST)

Ḫarǧa wird in div. Browsern teilweise nicht richtig dargestellt

Hallo, das Lemma und die Kapitelüberschriften von Ḫarǧa werden in Browsern wie Opera, Google Chrome, Microsoft Edge nicht korrekt dargestellt, im TOC, Fließtext und in den ENs aber schon!

Etwas ausführlicher in der Lemma-Disku, am (jetzigen) Ende ab 09:34, 26. Jun. 2023 (MESZ).

Können wir etwas tun? Und was?

Danke, --Wi-luc-ky (Diskussion) 00:26, 29. Jun. 2023 (CEST)

Das ist ein Problem mit den Schriftarten. Bei mir wird in Chrome alles korrekt dargestellt, da ich mir vor einiger Zeit die Wikimedia-Standardschriftart für Überschriften Linux Libertine installiert habe. Wenn diese Schriftart nicht vorhanden ist, fällt der Browser auf Georgia zurück, und die kann mit Diakritika leider sehr schlecht umgehen (vgl. zum Beispiel auch Cần Thơ). Wäre fast sinnvoller, wenn gleich auf Times zurückgefallen würde. Wikipedia-Sprachversionen mit vielen Diakritika (etwa die vietnamesische) haben aus diesen Gründen auch andere Schriftarten für Überschriften vorgesehen. Wird sich bei uns aber wohl nicht lohnen. Ich kann also nur empfehlen, Linux Libertine zu installieren! --XanonymusX (Diskussion) 00:56, 29. Jun. 2023 (CEST)

"Ich kann also nur empfehlen, Linux Libertine zu installieren" --- Gibt es dazu eine Anleitung? Scheint mir kompliziert zu sein.

Gruß --Diego de Tenerife (Diskussion) 18:42, 29. Jun. 2023 (CEST)

Das ist kein Hexenwerk. Einfach herunterladen und direkt installieren (zum Beispiel in Win 10). :) Dann sollten die Browser alle direkt darauf zugreifen können (nach Neustart). Vermutlich könnte man auch eine reine Chrome-Lösung wählen, aber eine neue Schriftart ist eigentlich immer eine Bereicherung. --XanonymusX (Diskussion) 19:33, 29. Jun. 2023 (CEST)

Lieber Xanonymus,

folge ich Deinem Hinweis "herunterladen", so wird eine Datei " LinLibertineTTF_5.3.0_2012_07_02(1).tgz" downgeloadet. Wie geht es nun weiter?

Gruß --Diego de Tenerife (Diskussion) 08:35, 30. Jun. 2023 (CEST)

Das komprimierte .tgz mit einem komprimierte Dateien Extractor wie 7zip extrahieren und die nun extrahierten einzelnen .ttf Dateien (sie haben das Änderungsdatum 2012 und werden dir deshalb vermutlich in den Downloads (wenn du dahin extrahiert hast) ganz unten angezeigt) mit der Windows Schriftartenanzeige jeweils öffnen und auf „Installieren“ klicken. --Dwain 11:06, 30. Jun. 2023 (CEST)

Stimmt, hatte vergessen, dass die komprimiert daherkommen. Danach greift dann die oben verlinkte Anleitung (sofern Windows). --XanonymusX (Diskussion) 11:41, 30. Jun. 2023 (CEST)

Vielen Dank! Es hat funktioniert, "Ḫarǧa" wird jetzt in allen Browsern richtig angezeigt.

Gruß --Diego de Tenerife (Diskussion) 17:41, 30. Jun. 2023 (CEST)

Super! Ich finde das Schriftbild von Linux Libertine gegenüber Georgia sowieso eine deutliche Verbesserung. Ist halt schade, dass vermutlich viele Benutzer weiterhin mit den Georgia-Problemen konfrontiert sein werden. Eventuell könnten wir uns längerfristig doch noch eine eigene Schriftartdefinition fürs Fallback in deWP überlegen, wir haben ja doch deutlich mehr Sonderzeichen in Lemmata als die enWP. --XanonymusX (Diskussion) 18:02, 30. Jun. 2023 (CEST)

Schön, dass es geklappt hat. Diego de Tenerife.

Aber es bleibt bei mir die Frage in die Runde, ob wir Lemmatitel kreieren sollten, die nur durch Installation von zusätzlicher Software auf gängigen OMA-Browsern korrekt angezeigt werden.

Anders gesagt: Was hindert, die Wikisoftware so anzupassen, dass sie es nicht nur – wie schon jetzt – im TOC, Fließtext und in den ENs richtig bringt?

Gruß, --Wi-luc-ky (Diskussion) 19:03, 30. Jun. 2023 (CEST)

Die Frage ist nicht ganz richtig gestellt, denn an der Software liegt es ja wie gesagt nicht. „Schuld“ ist letzten Endes Georgia. Dass das Designteam sich bei der Auswahl der Standardschriftarten nicht weiter mit diesem Problem beschäftigt hat, mag am Anglozentrismus liegen. Die enWP hat ja für ihre Lemmata die Regel vorgeschrieben, grundsätzlich Diakritika wegzulassen, während wir bei lateinbasierten Sprachen grundsätzlich möglichst korrekt schreiben wollen. Angesprochen wird das Problem immer wieder. Es könnte sein, dass entweder Chrome oder Windows irgendwann Linux Libertine standardmäßig vorsehen. Oder MediaWiki bringt irgendwann eigene Schriftarten mit. Aber bis dahin können wir nur überlegen, ob wir schlicht Georgia aus der Liste streichen (dann werden viele Benutzer Times sehen) oder etwa nach dem Vorbild der vietnamesischen WP andere Ersatzschriftarten einsetzen. --XanonymusX (Diskussion) 20:27, 30. Jun. 2023 (CEST)

Vielen Dank, XanonymusX, für Deine ausführliche Erläuterung.

Ja, „bis dahin“ gerne nicht „nur überlegen, ob wir schlicht Georgia aus der Liste streichen“, sondern … streichen. Georgia on My Mind reicht mir, muss nicht falsch on My Screen erscheinen. Da ist ein funktionierendes old-times-fashioned Times New Roman doch vorzuziehen? Auf Änderungen Dritter zu warten, ist müßig.

Der jetzige Zustand in den genannten Browsern dürfte jedenfalls Verwirrung stiften, die (kopiert) sich weiter verbreiten wird.

Gruß, --Wi-luc-ky (Diskussion) 22:39, 30. Jun. 2023 (CEST)

Die Definition bei den Vietnamesen sieht statt Georgia Palatino Linotype und auch noch EB Garamond vor, bevor auf Times zurückgefallen wird. Palatino und Georgia sehen im Endergebnis schon recht unterschiedlich aus, ich frage mich, ob eine so sichtbare Änderung nicht auf Widerstand stößt (reiner Rückfall auf Times ebenso). Gleichzeitig bin ich aber auch der Meinung, dass wir mit Georgia eigentlich nicht sinnvoll arbeiten können. Und mit Vector-Usern in Chrome unter Windows ohne zusätzliche Schriftarten ist der Betroffenenkreis jetzt auch nicht riesig.

@Hgzh: Was meinst du dazu? Sollten wir so etwas ins Auge fassen? Man könnte es wohl auf MediaWiki:Vector.css beschränken. --XanonymusX (Diskussion) 23:33, 30. Jun. 2023 (CEST)

Sollte man das nicht dann auch gleich in MediaWiki:Vector-2022.css eintragen? Oder wird das gleich mit korrigiert/ist bei Vector-2022 sowieso kein Problem? --Dwain 08:38, 1. Jul. 2023 (CEST)

Soweit ich weiß, gelten die Definitionen für Vector automatisch auch für Vector 2022, nur nicht umgekehrt. --XanonymusX (Diskussion) 11:38, 1. Jul. 2023 (CEST)

Der Vorschlag wäre, Georgia durch Palatino zu ersetzen (bzw. in der Fallbackreihenfolge davor zu setzen=? Generell finde ich ja, dass das eher upstream gelöst werden sollte, wenn es Probleme mit Georgia gibt.

Umsetzen müsste man es übrigens in Vector.css und Vector-2022.css, das Durchschleifen der Definitionen für Vector nach Vector-2022 soll in näherer Zukunft beendet werden. -- hgzh 12:25, 2. Jul. 2023 (CEST)

Georgia soll weg, ob nun ersatzlos oder eben ersetzt durch Palatino. Das natürlich in Abwartung einer Lösung upstream, die seit mindestens einem Jahr auf sich warten lässt und zu der offenbar noch kein Konzept besteht (phab:T313598). Die Vietnamesen haben das sogar schon im Februar 2021 umgesetzt. --XanonymusX (Diskussion) 13:09, 2. Jul. 2023 (CEST)

Tabelle als Bilddatei (alle Schriftarten installiert)

Zur Veranschaulichung hier mal eine kurze Gegenüberstellung der besprochenen Schriftarten in Problemfällen:

Linux Libertine	Georgia	Palatino	EB Garamond	Times
Ḫarǧa	Ḫarǧa	Ḫarǧa	Ḫarǧa	Ḫarǧa
Cần Thơ	Cần Thơ	Cần Thơ	Cần Thơ	Cần Thơ
Hồ Chí Minh	Hồ Chí Minh	Hồ Chí Minh	Hồ Chí Minh	Hồ Chí Minh
Ӂ	Ӂ	Ӂ	Ӂ	Ӂ
Ḉ ṏ ṹ Ẍ Ẑ	Ḉ ṏ ṹ Ẍ Ẑ	Ḉ ṏ ṹ Ẍ Ẑ	Ḉ ṏ ṹ Ẍ Ẑ	Ḉ ṏ ṹ Ẍ Ẑ

Ich sollte ergänzen: Es ist wohl kein reines Georgia-Problem, da in Nicht-Chromium-Browsern auch Georgia kein Problem mit diesen Diakritika hat. Da aber Chrome nun einmal der mit Abstand meistgenutzte Browser ist und dieser Bug (?) schon sicher über ein Jahr nicht korrigiert wurde, wäre das lokale Ersetzen durch Palatino (zumindest bis zum Abschluss von phab:T313598) in meinen Augen eine gute Idee. Stilistisch ist die Schrift eh näher an Linux Libertine als Georgia, scheint mir.–XanonymusX (Diskussion) 23:46, 1. Jul. 2023 (CEST)

Danke, XanonymusX, für Analyse und Vorschläge.

Was Palatino angeht: In FF 114.0.2 (64-Bit) wird damit Cần Thơ (in der Tabelle) anders, wohl falsch dargestellt: der Gravis rutscht links neben den Zirkumflex.

Gruß, --Wi-luc-ky (Diskussion) 00:35, 2. Jul. 2023 (CEST)

Jein, das ist in Chrome genauso, aber dort (in geringerem Maße) auch bei Linux Libertine; in Safari/iOS sind die beiden hingegen jeweils schön senkrecht, dafür ist dort bei Georgia ein leichtes Nebeneinander zu sehen. Times ist da tatsächlich am stabilsten. Allerdings haben die Vietnamesen das ja in viWP bereits analysiert und abgewogen und sich für die genannte Konstellation entschieden. Wichtig ist bei den Doppeldiakritika einfach, dass die Zuordnung zum Buchstaben (streng genommen: zur Silbe) noch erkennbar ist und keine Löcher ins Wort gerissen werden. Jedenfalls danke für die Beobachtung unter Firefox, den hab ich nämlich nicht! --XanonymusX (Diskussion) 01:06, 2. Jul. 2023 (CEST)

Die Verschiebung bei Linux Libertine in Chrome kann ich nicht bestätigen (Version 114.0.5735.199 unter Windows 11 Home 22H2 22621.1928). Bei mir sieht Linux Libertine genauso korrekt aus wie EB Garamond und Times. Auch ich würde eine Lösung begrüßen, die die Anzeige für möglichst viele Nutzer stabilisiert, die ja nicht alle auf die Idee kämen, irgendwas runterzuladen und zu installieren. Grüße --Monow (Diskussion) 01:27, 2. Jul. 2023 (CEST)

Das könnte freilich daran liegen, dass du hier in allen drei Fällen einheitlich Times angezeigt bekommst, wenn du nämlich Linux Libertine und EB Garamond nicht eigens installiert hast! ;) Das macht den Vergleich auch relativ schwer, da ich mir nicht überall sicher sein kann, was die tatsächlich angezeigte Schriftart ist. Ich werde bei Gelegenheit noch Screenshots beifügen. Georgia, Palatino und Times benötigen auf jeden Fall keine eigene Installation unter Windows, Times ist überall verfügbar. --XanonymusX (Diskussion) 01:35, 2. Jul. 2023 (CEST)

Danke für die Klarstellung – ich hatte mich schon gewundert, wie „ähnlich“ die drei Schriftarten sich sehen! Ja, dann wären Screenshots natürlich sinnvoll, wobei ich Dir die Beobachtung natürlich auch ohne gerne glaube. --Monow (Diskussion) 01:41, 2. Jul. 2023 (CEST)

Da ich ja nun selbst in die Falle getappt bin: Was spricht denn dagegen, die für alle sichtbare Times zu verwenden? --Monow (Diskussion) 01:56, 2. Jul. 2023 (CEST)

Ist letztlich eine Designfrage, sonst könnten wir auch ganz einfach unbestimmt serif schreiben und die Browser individuell machen lassen. In Monobook gibt es keinerlei Schriftartvorgaben, alles ist sans-serif. In Timeless hingegen hat man für Überschriften 'Linux Libertine','Times New Roman','Liberation Serif','Nimbus Roman','Noto Serif','Times',serif vorgesehen, in Minerva 'Linux Libertine','Georgia','Times','Source Serif Pro',serif und in Vector schließlich 'Linux Libertine','Georgia','Times',serif. Times als Überschrift wirkt einfach ziemlich altbacken und unästhetisch, vor allem in einer modernen Webumgebung. Es kann also nicht schaden, ein paar elegantere Alternativen davorzusetzen, da einige User die Schriftarten hoffentlich installiert haben. Und wer gar nichts hat, erhält am Ende eben doch Times. --XanonymusX (Diskussion) 02:27, 2. Jul. 2023 (CEST)

Dann müsste doch nur die nicht funktionierende Georgia aus diesen Auflistungen entfernt werden, oder? --Monow (Diskussion) 02:41, 2. Jul. 2023 (CEST)

Ja, auf jeden Fall so lange, wie der Chrome-Bug diesbezüglich nicht gelöst ist. Aber weil das dann eben für die allermeisten bedeuten würde, auf Times zurückzufallen, plädiere ich für die Hinzufügung von Palatino (und evtl. Garamond), dann sind die Chancen größer, dass eine der Designschriftarten vorhanden ist. --XanonymusX (Diskussion) 02:49, 2. Jul. 2023 (CEST)

*räusper* So ungefähr die Hälfte der Zugriffe ist via mobiles Web und das ist Android + iPhone. Also nicht die "allermeisten" sondern so 35-40% sind betroffen. --Wurgl (Diskussion) 13:51, 2. Jul. 2023 (CEST)

Stimmt, ich hätte von Desktopusern sprechen müssen. Aber die Mobilnutzer verwenden überwiegend Minerva, daher würde ich dort Georgia ja auch lassen (denn iOS kennt von den gelisteten Schriften nur Georgia und Times, Android weiß ich nicht). Für Vector ändert das nichts. --XanonymusX (Diskussion) 17:15, 2. Jul. 2023 (CEST)

Wie ich inzwischen feststellen musste, wird in Chrome unter Android der Gravis bei Hồ Chí Minh durchgängig links neben dem Zirkumflex angezeigt (in allen Tabellenspalten hier, aber auch im Artikelfließtext). Dafür scheint es bei Ḫarǧa überhaupt kein Problem zu geben. Grüße --Monow (Diskussion) 01:06, 5. Jul. 2023 (CEST)

Ja, weil das nicht das Ausgangsproblem ist. Doppeldiakritika sind in erster Linie ein Designproblem, da Buchstaben einer Schriftart ja grundsätzlich alle in die vorgegebene Zeilenhöhe passen müssen. Schon einfache Diakritika bei Großbuchstaben führen in manchen Schriftarten zu seltsamen Quetschungen von Buchstaben (nicht umsonst wird im Italienischen noch heute oft E' statt È geschrieben). Im Doppelpack ist das noch einmal kniffliger. Wie es aussieht, werden bei Linux Libertine und Palatino die Diakritika so gesetzt, dass der Buchstabe insgesamt nicht höher wird als ein normaler Großbuchstabe; bei Times und der hier im Fließtext genutzten serifenlosen Schrift (Verdana, glaube ich) hingegen werden die Zeichen einfach übereinander getürmt, ohne Rücksicht auf die Gesamthöhe. Georgia in Chrome scheint aber nicht daran zu scheitern, denn manche Doppeldiakritika im Vietnamesischen bekommt sie sogar hin; das Ausgangsproblem betrifft eine zufällig wirkende Anzahl von Sonderzeichen. --XanonymusX (Diskussion) 18:02, 5. Jul. 2023 (CEST)

Dann wäre in dem Fall meiner Ansicht nach aber ein Fallback auf New Times Roman sinnvoller … --Dwain 18:17, 5. Jul. 2023 (CEST)

Sehe ich nicht so, es sagt ja niemand, dass Doppeldiakritika übereinander stehen müssen. Und da vor allem Vietnamesisch betroffen ist, würde ich einfach deren Schriftartwahl folgen (ausgenommen Garamond, da wir hier keine Google Fonts aktivieren werden). Palatino ist in der Darstellung doch sogar näher an Linux Libertine als an Times. Fehler erzeugt nur Georgia. --XanonymusX (Diskussion) 18:44, 5. Jul. 2023 (CEST)

Kommt darauf an, wie man Fehler definiert. Ich sehe das zumindest als Fehler an … --Dwain 19:02, 5. Jul. 2023 (CEST)

Das spräche dann aber auch gegen Linux Libertine. --XanonymusX (Diskussion) 21:25, 5. Jul. 2023 (CEST)

Mir scheint übrigens, dass wir für eine Änderung hier besser eine allgemeine Umfrage erstellen sollten. Zum Beispiel mit den Optionen 1: Status quo, 2a: Ersatz von Georgia durch Palatino, 2b: Streichung von Georgia. --XanonymusX (Diskussion) 21:49, 5. Jul. 2023 (CEST)

Wer sagt denn, dass ich zwingend Linux Libertine möchte und nicht New Times Roman viel besser und Linux Libertine total scheußlich finde (das tue ich nämlich; ich dachte nur, dass damit alles korrekt angezeigt wird, weshalb ich den Vorschlag angenommen habe)?

Eine Umfrage wäre vermutlich gut. --Dwain 22:23, 5. Jul. 2023 (CEST)

Nun ja, wir alle werden verschiedene Schriftarten unterschiedlich ästhetisch finden. Times als Überschrift möchte ich im Jahr 2023 nicht sehen. Aber für persönliche Vorlieben sollten wir unsere eigene Common.css nutzen. Ich schau mal, ob ich schnell eine Umfrage zusammenstellen kann. --XanonymusX (Diskussion) 23:50, 5. Jul. 2023 (CEST)

So in etwa: Benutzer:XanonymusX/Überschriften. --XanonymusX (Diskussion) 02:31, 6. Jul. 2023 (CEST)

Ich würde zusätzlich das Problem der Doppeldiakrita miteinbeziehen (auch wenn das kein Bug ist, ist es unschön, statt É E´ zu lesen). --Dwain 08:11, 6. Jul. 2023 (CEST)

Mit gleichem Recht kann man beschreiben, dass Ӂ nur in Palatino mit geraden statt geschwungenen Linien dargestellt wird oder sich Tilde und Trema in ṏ nur in Linux Libertine berühren. Es geht hier nicht um Doppeldiakritika oder Schriftstile, sondern um die Beseitigung eines konkreten Bugs, da sind ausführlichere Beschreibungen zusätzlicher Aspekte eher kontraproduktiv. Das kann aber ja in der dortigen Diskussion noch einmal angesprochen werden. --XanonymusX (Diskussion) 14:11, 6. Jul. 2023 (CEST)

Der Chromium-Bug wird übrigens hier etwas detaillierter beschrieben: [1]. Offenbar erkennt Firefox die kaputte Darstellung in Georgia selbst und fällt dann automatisch auf Times zurück, während Chromium es weiter mit Georgia probiert. Ich schau mal, ob ich die Umfrage demnächst starten kann. Gerne noch mehr Input dort auf der Diskussionsseite. --XanonymusX (Diskussion) 13:49, 10. Jul. 2023 (CEST)

Konflikt Erweiterte Bearbeitungswerkzeugleiste mit editMenus?!

Ich habe seit langem folgendes Problem: Wenn ich einen Wikilink mit der Erweiterte Bearbeitungswerkzeugleiste erzeuge, reagiert editMenus nicht mehr, d.h. ich kann keine neuen Symbole wie typografisch korrekte Anführungszeichen einfügen. Manchmal werden die Symbole, die ich dort anklicke, auch in die Zeile "Zusammenfassungen und Quellen" eingefügt statt in das Quelltextfeld. Erst wenn ich die Seite neu lade, indem ich "Vorschau anzeigen" benutze, funktioniert editMenus wieder, solange, bis ich erneut eine Funktion der erweiterten Bearbeitungsleite nutze.

Ich hatte gehofft, dass sich das Problem mit einem Update irgendwann erübrigt. Aber da das Problem seit längerem fortbesteht, wende ich mich jetzt an die Technikwerkstatt. --Asperatus (Diskussion) 11:49, 2. Jul. 2023 (CEST)

Wäre mir neu.

Systematische Erprobung durch Mitlesende wäre hilfreich.

Die Schilderung in die Zeile "Zusammenfassungen und Quellen" eingefügt legt nahe, dass irgendwer dem TEXTAREA seine Eigenschaft weggenommen hat; dann kann editMenus nichts mehr finden und einfügen und ist machtlos.

Es ist aber auch nicht darauf ausgelegt, beide Systeme simultan zu nutzen.

VG --PerfektesChaos 11:59, 2. Jul. 2023 (CEST)

Does it use jquery.textSelection ? Because otherwise it can't know which textarea is the active one. Especially if things like the syntax highlighter or any other alternative editors are active. --TheDJ (Diskussion) 13:15, 11. Jul. 2023 (CEST)

Browser Opera: Darstellungsproblem

Wikipedia-Seiten von deutschen Städten enthalten in der Infobox die Deutschlandkarte (Germany_adm_location_map.svg). Darin soll die Position der Stadt hervorgehoben sein. An welchem Fehler/Einstellung liegt es, dass diese Hervorhebung (roter Punkt) unter Windows 10 im Browser Opera One (Version: 100.0.4815.54) nicht sichtbar ist? (Mit Chrome, Fixrefox, Edge, Vivaldi ist alles OK.) --Ingo Kniethow (Diskussion) 12:12, 13. Jul. 2023 (CEST)

Löschen von Leerzeilen durch Visual Editor, ggf. nur bei Tabellenbearbeitung

Hallo, ich konnte nicht finden, ob schon bekannt. Daher siehe Benutzer_Diskussion:Felixpf#Bayer_04_Leverkusen,_konkret_Moussa_Diaby: Dort heisst es zwar, „Sobald ich aus der Quelltextbearbeitung in die visuelle wechsle, entsteht hinter dem konkret bearbeiteten Abschnitt ein Absatz, der wenn man ihn nicht eigenständgig entfernt, später von einem Bot entfernt wird.“ siehe aber: SpeziaL:Diff/235716175, Richtig ist: Es wurde dort eine Tabelle mit Visual Editor bearbeitet, worauf die Leerzeile am Ende der Tabelle gelöscht wurde. siehe Spezial:Permanentlink/235716175. --Nordprinz (Diskussion) 16:59, 23. Jul. 2023 (CEST)

Interner IP-Bereich sorgt für externe IP-Sperre

Hallo, neulich war ich kurz gesperrt, bekam nach dem Betätigen des Edit Buttons eine Nachricht angezeigt:

Anonyme Beiträge von deiner IP-Adresse (10.80.1.11) sind nicht erlaubt. Bitte melde dich an.. Beginn der Sperre: 15:29, 22. Aug. 2023 Ablauf der Sperre: unbeschränkt Sperre betrifft: 10.80.1.11 Deine aktuelle IP-Adresse ist 10.80.1.11. Bitte füge alle Informationen jeder Anfrage hinzu, die du stellst.

Eine Nachfrage bei Mediawiki ergab dass es sich bei der IP um eine interne Adresse handele mit der ich eigentlich als IP nichts zu tun haben sollte, es sich also um einen Software-Bug handeln dürfte. Hier ein Link zur Anfrage bei Mediawiki: https://m.mediawiki.org/wiki/Topic:Xoamohr8277fe62x Gruß, -Ani--46.114.154.103 00:09, 25. Aug. 2023 (CEST)

Der 10er-Adress-Block ist privat, der hat im Internet nichts verloren. Seltsam ist, dass du damit überhaupt auf Seiten zugreifen konntest, siehe auch IP-Adresse#Besondere_IP-Adressen

Whois 10.80.1.11 nennt das 10er Netz "PRIVATE-ADDRESS-ABLK-RFC1918-IANA-RESERVED". Ich sehe da keinen Fehler seitens Wikipedia. --Wurgl (Diskussion) 00:27, 25. Aug. 2023 (CEST)

Das würde also bedeuten dass ich in dem Momemt Teil eines Intranets war.? Was wirklich seltsam ist, da ich hier selbst kein WLAN etc in Betrieb habe. -Ani--46.114.154.103 02:32, 25. Aug. 2023 (CEST)

Nein, wie gesagt, solche Adressen können im Internet nicht geroutet werden. Das heißt, du kannst zwar damit Nachrichten versenden, aber erhältst nie etwqs zurück. Sieht tatsächlich nach einem Bug in Mediawiki aus. --Prüm ✉ 05:52, 25. Aug. 2023 (CEST)

Darstellung von Beobachtungslistenelementen in Thunderbird

Schon seit langem habe ich den am linken Seitenrand verlinkten Atom-Feed meiner Wikipedia-Beobachtungsliste als RSS-Feed im Thunderbird eingebunden. Klicke ich im Thunderbird ein Element aus der Liste an, öffnete es sich bisher in der Diff-Ansicht. Das geht seit kurzem aber nicht mehr, wohl seit Installation der neuen Thunderbird-Version 115. Nun wird im Thunderbird als Element-Inhalt nur der Titel des geänderten Artikel-Abschnitts vor dem Benutzernamen angezeigt, also viel zu wenig. Das steht im Gegensatz zu anderen Atom-Feeds von Wikipedia, z. B. dem der KALP-Seite, dort erscheinen die Änderungen tatsächlich in der Diff-Ansicht, wenn auch in etwas anderer Darstellung als vor dem Thunderbird-Update. Hat jemand eine Idee, woran das Problem mit der Darstellung der Beobachtungslistenelemente liegt und wie man es beheben kann? --Stegosaurus (Diskussion) 18:26, 25. Okt. 2023 (CEST)

Verbesserung der Formulierung der Notiz beim Bearbeiten von ungesichteten Artikeln

Ich sichte und bearbeite gerade Spezial:Seiten mit ungesichteten Versionen. Wenn man in einem Artikel mit ungesichteten Änderungen auf Bearbeiten (visueller Editor) klickt, erscheint eine Popup-Notiz, die merkwürdig formuliert ist und vielleicht Neulinge verwirrt:

„Eine Notiz

Deine Änderungen werden angezeigt, sobald sie gesichtet wurden.

Die gesichtete Version wurde am 20. Januar 2024 markiert. Momentan gibt es 1 Änderung, die noch gesichtet werden muss.

Frühere Änderungen an dem Text, den du gerade bearbeitest, wurden noch nicht gesichtet. (Änderungen anzeigen)“

(Vollzitat für den Fall, dass der Text angepasst wird)

Der letzte Satz ist irgendwie merkwürdig nachgeschoben, nachdem die Details bereits aufgezählt wurden. Bedeutet „frühere Änderungen“, dass es noch weitere Änderungen vor der 1 ungesichteten Änderung gibt?? (Nein.) Wenn das hilfreich ist, kann ich gerne einen alternativen Textvorschlag schreiben. Kann gerne auch jemand einfach sinnvoll anpassen. --Frupa (Diskussion) 11:51, 23. Jan. 2024 (CET)

Tja, bis 2016 lautete die Zeile „Hinweis: Einige der noch nicht markierten Änderungen betreffen den Abschnitt des Textes, den du gerade bearbeitest.“ Dann ist diese irreführende Informationsdopplung zwar weg, ich sehe aber nicht unbedingt einen Mehrwert darin. Der Link zu den Änderungen ist ebenfalls doppelt. Eventuell könnten wir MediaWiki:Review-edit-diff einfach ganz leeren. --XanonymusX (Diskussion) 18:07, 23. Jan. 2024 (CET)

Seltsames Verhalten von Bildattributen

Gestern hab ich als Beifang das hier entdeckt/gefixt: Spezial:Diff/245346626

Vorab weil ich selbst erst drauf reingefallen bin: Das Bild ist recht groß, aber das liegt an |778x778px ganz am Ende der Bildattribute, "mini" sollte also nur das Bild nach rechts schieben.

In der vorherigen Version mit "|mini {{Farblegende…" war weder das Bild rechts, noch war die Farblegende zu sehen.

Irgendwas verschluckt sich da. Gibts da schon einen phab-Eintrag bzw. mag da jemand was schreiben? --Wurgl (Diskussion) 15:03, 27. Mai 2024 (CEST)

Was wäre denn deine Idee? Allenfalls könnte ich mir vorstellen, dass bei einem unbekannten Parameter (der durch die Bearbeitung am 21. April entstanden ist) ein Fehler angezeigt wird. Allerdings hätte die Vorschaufunktion vielleicht schon geholfen. --Magnus (Diskussion) 15:15, 27. Mai 2024 (CEST)

Sowas siehst du beim Ändern nicht unbedingt, bzw. es fällt nicht auf. Und als Idee: Wenigstens in der Vorschau irgendeine Meldung in Knallrot. Passiert auch bei "|mini 123" und "|mini tralala", nicht aber bei "|mini|mini tralala" --Wurgl (Diskussion) 15:31, 27. Mai 2024 (CEST)

Das war vermutlich WSTM bei diesem Edit CC: Crazy1880, PerfektesChaos und es würde auch wieder passieren, wenn man die Vorlagen innerhalb der Bildlegende wieder an den Zeilenanfang setzt. Derzeit kann ich den Artikel aber öffnen ohne dass das Pipe verschwindet. --Liebe Grüße, Lómelinde Diskussion 15:20, 27. Mai 2024 (CEST)

Moin Moin zusammen, dann erstmal Entschuldigung, ja das war durch meine Bearbeitung mit WSTM wohl gekommen. Nicht aufgepasst ;( mfg --Crazy1880 17:54, 27. Mai 2024 (CEST)

API-Request mit exintro gibt mehr als nur das Intro zurück

Ich sende folgende API-Request:

https://de.wikipedia.org/w/api.php?action=query&format=json&prop=extracts&titles=Microsoft%7CBerkshire%20Hathaway&formatversion=2&exintro=1&explaintext=1

(Link zur API-Spielwiese)

Der Parameter exintro sollte laut Doku dazu führen, dass nur der Text vor der ersten Abschnittsüberschrift zurückgegeben wird. Stattdessen erhalte ich in der Response den Text des gesamten Artikels.

In Wikis in anderen Sprachen scheint das korrekt zu funktionieren (z.B. en, es). Nur in der deutschen Wikipedia API habe ich dieses Verhalten festgestellt. Kann es sein dass hier in etwas falsch bzw. anders als bei anderen Wikipedias konfiguriert ist (evtl. in der TextExtracts extension)? --FrozenRabbitHole (Diskussion) 17:46, 2. Jul. 2024 (CEST)

Das kann durchaus an den am Anfang eingebundenen Infoboxen liegen, die TextExtracts-Extension ist da ziemlich zickig, leider lässt sich das nur schwer debuggen bzw. beheben. -- hgzh 22:05, 2. Jul. 2024 (CEST)

?? Also ich sehe jetzt nur den Text des jeweils ersten Abschnitts? Was außer dem Datum hat sich geändert? Die Artikel jedenfalls nicht. --Wurgl (Diskussion) 13:30, 6. Jul. 2024 (CEST)

Der Inhalt ist für {{#FORMAL|dein|Ihr}} Browserfenster so breit wie möglich.

Gemeldet in Phabricator
Task T366602

Im Menu hinter dem Brillensymbol (Vector2022, rechts vom Benutzernamen, links neben der "Deine Meldungen"-Glocke) sehe ich unter "Breit" den Text in der Überschrift. Das Problem tritt unter Firefox nur in nicht maximierten Fenstern auf. In anderen Sprachversionen von Wikipedia tritt das Problem nicht auf. --Kallichore (Diskussion) 01:10, 19. Jul. 2024 (CEST)

Ich habe inzwischen den Eintrag im translatewiki.net gefunden. Der Text könnte zu "Der Inhalt ist so breit wie möglich für das Browserfenster." geändert werden. Aber warum funktioniert die Fallunterscheidung für die Anredeform hier nicht? @Raymond: Vielleicht weißt du hier weiter? --Kallichore (Diskussion) 14:03, 19. Jul. 2024 (CEST)

Die #FORMAL-Funktion wurde vor diversen Wochen neu eingeführt und hatte sich schon im BETA als merkwürdig fehlverhaltend gezeigt.

Unser technisches Personal ist jedoch seit Monaten fast nur noch mit Dark-Mode-Angelegenheiten beschäftigt und hat keine Zeit mehr übrig, sich mit irgendwas anderem zu befassen. Ich muss mich fast jeden Tag mit einem neuen Dark-Mode-Problem beschäftigen.

Beim gesamten formal-Thema fielen mehrere Absonderlichkeiten auf:

• Die Programmierungen hatte ich mir angesehen; die waren auf den ersten Blick korrekt.
• Bei einer derartigen neuen Parserfunktion müssten #FORMAL: und #formal: gleich behandelt werden, was sie nicht tun.
• Das Resultat der Parserfunktion ist Grütze.
• Weil die Wirksamkeit von Systemnachrichten teilweise durch einen Cache auf dem Server ausgebremst wird, ist eine sofortige Analyse oft nicht möglich und nach einigen Wochen ist das Problem von selbst verschwunden.
• Der Sprach-Rückfall auf de-formal verhält sich völlig anders als der auf de-at oder de-ch – das legt den Verdacht nahe, dass jemand bei der Versorgung mit Sprachvarianten einen Filter eingebaut hat, der nur zwei Buchstaben kennt, also AT oder CH oder US oder NL oder GB. Das beeinträchtigt möglicherweise die Wirkung dieser Parserfunktion.
• Es gibt bereits mehrere Phab-Tickets und andere beobachtete Seltsamkeiten betreffend de-formal.

VG --PerfektesChaos 14:21, 19. Jul. 2024 (CEST)

In diesem Fall könnte es auch einfach sein, dass die Systemnachricht per JavaScript geladen wird - dort wird diese Parserfunktion nicht unterstützt (und wird es vermutlich auch nicht werden). -- hgzh 14:48, 19. Jul. 2024 (CEST)

Das "Brillensymbol" verschwindet bei deaktiviertem JavaScript. Das hier interpretiere ich auch so, dass eine Unterstützung von #FORMAL: unter JavaScript in naher Zukunft nicht kommen wird. Dann sollte die Übersetzung bei translatewiki.net wohl ohne #FORMAL: erfolgen. Hat hier jemand die erforderlichen Rechte für eine Änderung bei translatewiki.net?--Kallichore (Diskussion) 15:05, 19. Jul. 2024 (CEST)

Erledigt. --Tkarcher (Diskussion) 16:30, 19. Jul. 2024 (CEST)

Danke. Und ich habe lokal MediaWiki:Vector-feature-limited-width-exclusion-notice angelegt, damit die Änderung hier auch direkt wirksam wird. Kann dann nach dem nächsten Livegang, vermutlich nächste Woche Donnerstagabend, gelöscht werden. --Raymond ^Disk. 16:33, 19. Jul. 2024 (CEST)

@ErinnerMichBot: Bitte erinnere mich am 26.07.2024 an diese Seite. MediaWiki:Vector-feature-limited-width-exclusion-notice löschen (lassen). --Tkarcher (Diskussion) 17:02, 19. Jul. 2024 (CEST)

Gerade darüber gestolpert: Das Problem tritt auch noch an weiteren Stellen auf, z.B. beim Einfügen eines automatisch generierten Einzelnachweises über "Belegen" mit einer ungültigen URL:

Es konnte kein Einzelnachweis erstellt werden.
{{#FORMAL:Versuche|Versuchen Sie}} es mit einer anderen Quelle oder {{#FORMAL:Versuche|erstelle|erstellen Sie}} manuell eine mithilfe der Registerkarte „{{int:citoid-citoiddialog-mode-manual}}“ oberhalb.

Muss jetzt weg und kann deshalb gerade nicht weiter forschen, aber ich nehme mal an, auch hier ist ein Verzicht auf den "FORMAL"-Schalter momentan die einzig gute Lösung, oder? --Tkarcher (Diskussion) 18:26, 22. Jul. 2024 (CEST)

Ja, leider wurde das per Gießkanne über zahlreiche Messages ausgerollt. -- hgzh 18:29, 22. Jul. 2024 (CEST)

Die Gießkanne habe ich bedient, weil ich seit Jahren de-formal ignoriere, aber die Hoffnung hatte, das die neue #FORMAL-Parserfunktion das Problem löst. Leider erzeugt es weit mehr Probleme :-( --Raymond ^Disk. 09:29, 23. Jul. 2024 (CEST)

Nachtrag: Leider ist beim Übersetzen überhaupt nicht erkennbar, in welchem Kontext eine Nachricht geparst wird. --Raymond ^Disk. 09:32, 23. Jul. 2024 (CEST)

Ja, das ist ein Problem. -- hgzh 11:24, 23. Jul. 2024 (CEST)

Erledigt. Kann dann wieder zurückgesetzt werden, sobald #T366602 - Support {{#FORMAL:}} in JavaScript gelöst ist. --Tkarcher (Diskussion) 09:38, 23. Jul. 2024 (CEST)

Ich habe MediaWiki:Citoid-citoiddialog-use-general-error-message-body lokal erstellt, damit die geänderte Übersetzung sofort aktiv ist. Kann vermutlich ab dem 1. August hier lokal wieder gelöscht werden. {{int:citoid-citoiddialog-mode-manual}} vermutlich drin bleiben, das funktioniert meiner Erinnerung nach in JS-Systemnachrichten. --Raymond ^Disk. 09:31, 23. Jul. 2024 (CEST)

@Raymond: "{{int:citoid-citoiddialog-mode-manual}} kann vermutlich drin bleiben, das funktioniert meiner Erinnerung nach in JS-Systemnachrichten." --> Ja, hab ich auf meinen Streifzügen durch Phabricator inzwischen auch gelernt und es mit einer zweiten Änderung wieder reingesetzt. @ErinnerMichBot: Bitte erinnere mich am 02.08.2024 an diese Seite. MediaWiki:Citoid-citoiddialog-use-general-error-message-body löschen lassen. --Tkarcher (Diskussion) 09:42, 23. Jul. 2024 (CEST)

Mit welchen Tasten kann ich KontextMenüs steuern?

Ich benutze Windows 8.1 und FireFox

GrundProblem: Mein TouchPad funktioniert nicht mehr; daher muss ich alles mittels der Tastatur machen.

Frage A: Wie kann ich das/ein Kontext-Menü aufrufen?

Frage B: Wie kann ich das Kontext-Menü zum Verschieben eines Fenster-Randes (z.B. von WordPad) öffnen?

Problem: Manchmal geht bei jedem Druck auf die [5]-Taste des Zehner-Blockes das Kontext-Menü auf, obwohl ich das gar nicht will. Dann muss ich immer erst [Esc] drücken, damit das Kontext-Menü verschwindet, bevor ich das Eigentliche tun kann.

Frage C: Wie habe ich das ein-geschaltet ? und Wie kannn ich das wieder aus-schalten?

Steue (Diskussion) 23:25, 23. Jul. 2024 (CEST)

@Steue: Nur mal schnell nach Ziffernblock öffnet Kontextmenü gesucht:

• win-10-forum
• tipps-tricks-kniffe

Sehr verwandt mit Deinen Problemen; könnte helfen oder mindestens weiterhelfen.

Liest sich, als ob Du eine Maus und ein extenes (Funk-)Keyboard (ab 25 €) bräuchtest.

Gute Nacht! --Wi-luc-ky (Diskussion) 01:44, 24. Jul. 2024 (CEST)

Hab's noch nicht gelesen, aber erst mal Danke für beides, vor allem den Hinweis auf die Maus.

Die in meinem Klapprechner (Laptop) eingebaute Tastatur geht aber so weit einwandfrei.

Mein Klapprechner steht auf einem Podest, welches kaum größer als der Rechner ist, auf dem eigentlich weder Platz für eine Maus noch viel weniger eine ganze zusätzliche Tastatur ist.

Vielleicht wäre ja auch Ersatz des Touchpads möglich, falls es das noch gibt.

Steue (Diskussion) 02:02, 24. Jul. 2024 (CEST)

Ich habe mir zwar die beiden Links noch nicht angeschaut, aber kann Dir weiterhelfen, weil ich viel mehr Sachen lieber über die Tastatur mache als mit der Maus (ich komme aus Welten, in denen es noch keine Maus gab!). Wenn Deine Tastatur an sich einwandfrei funktioniert:

zu Frage A: Wenn es eine Windows-Tastatur ist, hast Du rechts zwischen der Win-Taste und der Strg-Taste eine, die das Kontextmenü an der Stelle und in dem Kontext öffnet, wo Du gerade bist.

Ist es keine Windows-Tastatur, drückst Du (zumindest im Windows) Umschalt-F10, da passiert das Gleiche.

zur Frage mit der [5]: Wenn auf der Zehnertastatur komische Dinge passieren: Brauchst Du denn die Funktionen auf den Tasten? Ich habe die immer im Num-Lock-Modus, hab aber auch keinen Laptop.

(Bei Laptops gibts ja oft keine eigenen Cursor-Tasten oder den Block darüber mit [Einf] bis [Bild ab], so dass man diese Dinge über die Zehnertastatur machen muss. Und bei Laptops ist es ja noch komplizierter, weil es da glaube ich noch eine Fn-Taste gibt, die eine zusätzliche Bedienungsebene der Tasten schafft)

Was mir außerdem zum Touchpad einfällt: Hattest Du mal irgendwann eine Maus angeschlossen? Manchmal gibt es die Einstellung, wenn eine externe Maus angeschlossen wird, dass sich das Touchpad abschaltet, weil es beim Tippen stört. Und das hat sich vielleicht nicht wieder zurückgeschaltet?

Und falls Du was im Windows suchen willst (z.B. Einstellungen): Du kannst ja mit den 2 Windows-Tasten (die entsprechen [Strg+Esc]) das Win-Startmenü öffnen, dann tippst Du das was ein, was Du suchst, und mit den Cursortasten kannst Du was aus der Liste auswählen.

(sorry, das war jetzt ein langer Vortrag, bestimmt weißt Du schon etliches davon?)--Hlambert63 (Diskussion) 19:32, 24. Jul. 2024 (CEST)

Text erscheint manchmal an der falschen Stelle

Moin, ich habe folgenden Quelltext:

=== Test ===
[[Datei:E-40 sunset.jpg|mini|Ein Foto]]
Ein Text ganz am Ende.<ref>ich</ref>

Wenn ich diesen Quelltext in der mobilen Version (de.m.wikipedia.org) im Artikelnamensraum schreibe, erscheint der Text über dem Bild. Ich habe dies mit Firefox und Chrome unter Android getestet. Der gleiche Quellcode wird in anderen Namensräumen (zum Beispiel Benutzernamensraum) richtig angezeigt.

Es scheint an dem <ref>-Tag zu liegen. Ich vermute irgend ein CSS-Problem im Artikelnamensraum.

Aufgefallen war mir das Problem, als ich die Bilder im Artikel Bundeskriminalamt (Deutschland) an die richtige Stelle schieben wollte. Dort finden sich also weitere Beispiele.

Wenn jemand mit mehr Ahnung helfen könnte das Problem zu finden und bestenfalls zu fixen wäre ich sehr dankbar. --Marc-André Aßbrock (Diskussion) 22:13, 27. Jul. 2024 (CEST)

fehlerhafte "Umwandlung" von Einzelnachweisnummern in Symbol

Verschoben von Wikipedia:Fragen von Neulingen#fehlerhafte "Umwandlung" von Einzelnachweisnummern in Symbol. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer • Ping mich und nicht meine Disk. an. 14:18, 26. Okt. 2024 (CEST)

Hi, (leider) kein Scherz, sondern bereits mehrmals passiert: Beim Schreiben mit dem Visual Editor werden im Text die Nummern von Einzelnachweisen in ein Symbol, ich meine der Nummer +2603 (9731) Unicodeblock also einen Schneemann, umgewandelt und die entsprechenden Fußnoten "verschwinden" bevor ich die Textänderung veröffentlichen konnte (Daher habe ich auch kein Beispiel zum Zeigen). Ich konnte noch nicht feststellen, wodurch das ausgelöst wird (automatisches Zwischenspeichern der Seite?) ... Ich benutze den Microsoft Edge mit Desktop Gerät. Kennt jemand eine Lösung für das Problem? --Indi Ann Summer (Diskussion) 13:47, 24. Okt. 2024 (CEST)

Warum vergibst du Nummern für die Einzelnachweise? Die werden doch automatisch vergeben und kommen im Quelltext garnicht vor. --Bahnmoeller (Diskussion) 03:10, 25. Okt. 2024 (CEST)

Hi Bahnmoeller, danke, dass Du Dich meldest... Du hast recht, ich benutze den Visual Editor und vergebe keine Nummern, sondern meinte die im Visual Editor Modus automatisch vergebene Nummer beim Einfügen eines Einzelnachweisen (die hochgestellte Fußnummernzahl). Diese hat sich bereits mehrmals während des Schreibens "umgewandelt", sprich: statt der Nummer war das Symbol (oben im Fließtext) und der Text des Einzelnachweises (unten) war (inkl. Nummer) verschwunden. Ich empfinde den Visual Editor als übersichtlicher... Wenn sich das Problem jedoch nicht löst, werde ich wohl gezwungenermaßen auf den Quelltext umsteigen müssen... Aber vielleicht hast ja Du oder jemand anderes noch eine Idee? ... Viele Grüße --Indi Ann Summer (Diskussion) 09:10, 25. Okt. 2024 (CEST)

Kannst du bitte mal so einen Fall auch tatsächlich abspeichern/veröffentlichen (im Zweifel kann man es ja rückgängig machen)? Ich vermute mal es handelt sich alleine um ein Anzeigeproblem (entweder nur bei dir und/oder durch den VisualEditor) und der daraus resultierende Quelltext ist korrekt. Wenn das so ist wie vermutet, dann ist das erstmal kein Problem. --Naronnas (Diskussion) 09:21, 25. Okt. 2024 (CEST)

Vielen Dank, Naronnas, ok, das mache ich... Viele Grüße --Indi Ann Summer (Diskussion) 09:29, 25. Okt. 2024 (CEST)

@Naronnas: Ich hatte erfahren, dass bei meiner Bearbeitung des Artikels Experimentkinder das Zeichen wieder da war und auch für Andere sichtbar: "Was sind diese Zeichen: ☃☃ ? (erstmal entfernt)." Passt das zu Deiner Vermutung? --Indi Ann Summer (Diskussion) 00:00, 26. Okt. 2024 (CEST)

Mhm. Deutlich unerfreulich. Welchen Browser in welcher Version auf welchem Betriebssystem in welchem Skin nutzt du derzeit? Hast du in diesem Browser PlugIns oder Add-ons aktiviert?
Insgesamt sollten wir die Diskussion auf Wikipedia:Technik/Werkstatt weiterführen (wenn nicht jemand Einspruch erhebt verpflanze ich gleich einmal die gesamte Diskussion). Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer • Ping mich und nicht meine Disk. an. 14:16, 26. Okt. 2024 (CEST)

Hi, vielen Dank! Ich verwende Microsoft Edge Version 130.0.2849.56, Windows 11 aktuellste Version, Vector alt (2010) --Indi Ann Summer (Diskussion) 15:47, 27. Okt. 2024 (CET)

keine PlugIns oder Add-ons --Indi Ann Summer (Diskussion) 15:49, 27. Okt. 2024 (CET)

Mhm. Was hast du für Schriftarten in Windows 11 installiert? Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer • Ping mich und nicht meine Disk. an. 17:44, 27. Okt. 2024 (CET)

Standardschriftart und Serifenschrift: Times New Roman; Serifenlose Schrift: Arial; Festbreitenschriftart: Consolas --Indi Ann Summer (Diskussion) 17:55, 27. Okt. 2024 (CET)

Mhm, das ist sehr seltsam. Kannst du mal einen anderen Browser (Google Chrome/Mozilla Firefox) verwenden? Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer • Ping mich und nicht meine Disk. an. 18:30, 27. Okt. 2024 (CET)

@Indi Ann Summer Wenn das Problem dort auch auftritt, wäre es gut einen phabricator Eintrag zu erstellen. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer • Ping mich und nicht meine Disk. an. 09:13, 2. Nov. 2024 (CET)

Dies (Anzeigeproblem?) trifft in Experimentkinder nicht zu. Ich habe die beiden Zeichen in [2] entdeckt und im Quelltext-Edit entfernt ([3], Absatz "Nach der Quarantäne wurden die Kinder...") - da war nichts von ENs zu sehen.

Eine der Refs, <ref name="Mørck"> (früher #6, jetzt #7), war bereits vorher an dieser Stelle und wurde bei [4] durch ☃ ersetzt - ich habe sie jetzt wieder ergänzt.

Wenn wir davon ausgehen, dass diese Zeichen nicht willkürlich eingesetzt wurden, gingen die Refs bei dem Edit "automatisch" verloren. --Alossola (Diskussion) 07:34, 26. Okt. 2024 (CEST)

Das kann durchaus ein Fehler des VisualEditors sein, der benutzt dieses Schneemannsymbol tatsächlich als Platzhalter für irgendetwas, vermutlich geht dann bei der Rückumwandlung irgendetwas schief. -- hgzh 13:45, 8. Nov. 2024 (CET)

Vielen Dank für die Rückmeldungen. Das Problem ist derzeit wieder hochaktuell, s. Bearbeitung des Einleitungstext Racial Profiling Version: 11. November 2024 um 09:18 Uhr (die ersten beiden Abschnitte). Dort wurden die Fußnoten beim Speichern automatisch durch das Symbol ersetzt. Verstehe ich das richtig, dass sich das Problem dann einzig über die Verwendung von Wikitext vermeiden ließe? Grüße --Indi Ann Summer (Diskussion) 10:14, 11. Nov. 2024 (CET)

Nein. Das Problem ließe sich vermeiden, wenn die Entwickler das Problem beheben. Das müsstest du halt melden (s.o.) Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer • Ping mich und nicht meine Disk. an. 14:22, 11. Nov. 2024 (CET)

Ich hab mir das Problem kurz angeschaut, um zu prüfen, ob unsere aktuelle Arbeit an Einzelnachweisen etwas damit zu tun haben könnte. Es scheint, als würde der Bug schon seit Jahren existieren und nicht nur bei Einzelnachweisen aufzutreten [5][6][7]. Scheint aber recht selten zu sein, sonst wär's wohl früher aufgefallen. Solche Bugs gabs anscheinend schon früher mal [8], ein neues Phabricator-Ticket wäre wohl das beste. --Johannes Richter (WMDE) (Diskussion) 14:35, 11. Nov. 2024 (CET)

Ich wollte später mal versuchen, das Problem nachzustellen, dann kann ich mich drum kümmmern. -- hgzh 14:38, 11. Nov. 2024 (CET)

Ich habe versucht, das Problem nachzustellen, bin aber gescheitert. Weißt du noch, was du hier genau gemacht hast? Hast du die Einzelnachweise irgendwie bearbeitet, verschoben o.Ä.? -- hgzh 22:45, 11. Nov. 2024 (CET)

Vielen Dank nochmal für Deine Mühe: Da das Problem mehrmals hintereinander aufgetreten ist: Ja, ich habe mit dem Visual Editor Fußnoten eingefügt (sie waren im Text normal angezeigt) und bei Überprüfung der Bearbeitung in der Vorschau waren sie bereits als "Schneemänner" angezeigt. Wenn ich dann statt zu veröffentlichen wieder zurück in die Bearbeitung gegangen bin, waren die Fußnoten (wieder) normal dargestellt, bei erneuter Vorschau und Veröffentlichung dann jedoch wieder umgewandelt. Grüße --Indi Ann Summer (Diskussion) 23:06, 11. Nov. 2024 (CET)

Einblendung "Dieses Thema konnte nicht gefunden werden"

Nach dem Speichern mancher Bearbeitungen, z. B. von Hilfe:Seitenname bekomme ich die Einblendung:

"Dieses Thema konnte nicht gefunden werden. Möglicherweise wurde es gelöscht, verschoben oder umbenannt."
(schwarze Schrift in einem rosanen Kästchen)

1) Was hat es damit auf sich? Warum wird es eingeblendet?
2) Es enthält keinen Link zu einer Erklärung.
3) Es scheint mir bei diesen meinen Bearbeitungen nicht passend.
4) Es verschwindet nicht von alleine.
5) Es ist nicht ersichtlich, wie man dieses Ding wieder loswird.
6) Es hat keine [ Schließen ]-SchaltFläche.
7) Wenn ich meinen MausZeiger in dieses Kästchen schiebe, wird der MausZeiger zur "ZeigeHand", was normalerweise bedeutet, dass es sich um einen Link handelt. In diesem Falle führt ein Klick aber nirgends wohin, sondern das Kästchen verschwindet nur. (Wenigstens wird man es auf diese Weise wieder los.)
Steue (Diskussion) 02:28, 23. Nov. 2024 (CET)

Das tritt vermutlich immer dann auf, wenn bei einer Abschnittsbearbeitung in der Überschrift alternative Sprungziele mittels Vorlage:Anker zwischen den == enthalten sind; außerdem vermutlich sofern die Überschrift verändert wurde. Wahrscheinlich auch bei Einbindung von Systemnachrichten, oder Expansion von Vorlagen?

Ist eine relativ neue Masche.

• Geht wahrscheinlich auf Diskussionsseiten mit möglicherweise inzwischen archivierten Abschnitten zurück, vor deren irrtümlicher Bearbeitung gewarnt werden soll.

Die Vorlage:Anker muss jedoch zwingend zwischen den == eingebunden werden, die Gründe dafür sind unter H:Ü erläutert.

Die Wiki-Software vergleicht offenbar die im Inhaltsverzeichnis der Gesamt-Seite vorkommenden (und dort bereits reduzierten) Überschriften mit dem, was zwischen den == steht, und stellt fest, dass die Überschrift mit Anker-Wikitext nicht im Gesamt-Inhaltsverzeichnis vorkommt, und das sei irgendwie verdächtig und die Übermutter müsse jetzt warnen, aber gibt keine Hinweise zu Ursachen und Behebung.

Bestenfalls nett gemeint, aber unvollständig gemacht.

• Offenbar muss die gleiche Normalisierung auf den Wikitext zwischen == angewendet werden, wie sie auch beim Eintrag in das TOC erfolgt, und erst dann darf verglichen werden.
• Was die Menschen jetzt mit dieser Warnung anfangen sollen, bleibt offen.
• Kann ja mal jemand ein Phab aufmachen, falls das in der enWP bislang nicht auffiel.

VG --PerfektesChaos 09:43, 23. Nov. 2024 (CET)

Es tritt auch auf, wenn man seltsames Zeugs in die Abschnittsbeschriftung (das zwischen den ==) schreibt, zum Beispiel eine Vorlage mit {{ oder eine Referenz und auch bei so einigen wenigen Sonderzeichen. Einfach ignorieren ;^) --Wurgl (Diskussion) 10:42, 23. Nov. 2024 (CET)

Danke, PerfektesChaos, für die ausführliche und verständliche Antwort.

Phab wäre toll - und nötig.

In Hilfe:Seitenname gibt es tatsächlich Anker in den Überschriften.

Diese Meldung ist mir auch schon begegnet, wenn ein Thema inzwischen archiviert war. Danach klingt auch der Text.

Danke auch Wurgl.

Etwas Anderes als ignorieren blieb mir ja auch nicht, wenn es keinen Sinn macht.

Steue (Diskussion) 12:44, 23. Nov. 2024 (CET)

> Was die Menschen jetzt mit dieser Warnung anfangen sollen, bleibt offen.
Die Meldung finde ich prinzipiell sinnvoll und hilfreich (denn über eine Umbenennung oder Archivierung sollte berichtet werden). Ich sehe auch irgendwie nicht, dass die Software es leisten muss, lokale Befindlichkeiten wie z.B. Vorlage:Anker zu berücksichtigen. Wenn das eben als (berechtigterweise) unterschiedlich erkannt wird, dann sei es so. Ich sehe das nicht in erster Linie als Bug, sondern als (logische) Nebenwirkung der Kombination von Funktion und lokaler Vorlage. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer • Ping mich und nicht meine Disk. an. 23:17, 23. Nov. 2024 (CET)

An Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer

Danke für Deine Stellunghnahme.

Ja, über eine Umbenennung oder Archivierung sollte der Benutzer informiert werden.

Aber wenn:

• ein Benutzer eine Seite bearbeitet hat (die ja offensichtlich dort ist), in deren Überschrift ein Anker ist, und
• dieser Benutzer dann eine Meldung bekommt, dass dieser Beitrag nicht gefunden wurde (was ja nicht der Wahrheit entspricht),

worin liegt dann der Nutzen dieser Meldung für diesen Benutzer?

Steue (Diskussion) 01:26, 24. Nov. 2024 (CET)

Es ist übrigens wohl auch zu beobachten, falls in einer URL ein Fragment auftaucht, das in der Wiki-Seite nicht definiert wird: Wikipedia:Technik/Werkstatt #Gibbetnich

• Das Grundproblem ist, dass die TOC-Standardisierungsprozedur nicht ausgeführt wird.
• Bei den in /* ... */ vorangestellten Abschnittsverlinkungen der Abschnittsbearbeitung haben wir das gleiche Drama, es wird der Text zwischen den == 1:1 zwischen /* und */ geschrieben.
  • Dagegen gibt es sicher schon seit Jahrzehnten bugzilla-Tickets.
  • Wir haben seit langer Zeit per MediaWiki:Gadget-sourceEditing.js einen JS-Code dagegen.
• Für das TOC wird der Content aus dem expandierten Wikitext zwischen den == gestripped; wobei '' bzw. ''' im Linktext als Kursiv- und Fettschrift dargestellt werden.
  • Damit steht in der HTML-Überschrift und im TOC nur id="hü", auch wenn: == {{Anker|hott}} hü ==
  • Für den Bearbeitungskommentar müsste die gleiche Prozedur erfolgen, also /* hü */ statt /* {{Anker|hott}} hü */ wie zurzeit.
• Das Problem gibt es global; ist nicht nur ein Luxusproblem der deWP.
• Steht übrigens offenbar im Zusammenhang mit der Analyse auf eindeutige id= und valide HTML-Dokumente und valide Fragmentverlinkungen.

VG --PerfektesChaos 11:25, 24. Nov. 2024 (CET)

Darstellungsprobleme für Diskussionsseiten unter Minerva

Gemeldet in Phabricator
Task T382104

Darstellung einer Diskussionseite unter Minerva

Bei mir treten auf Diskussionsseiten unter Minerva heftige Darstellungsprobleme auf (siehe Abbildung). In privaten Fenstern im Browser ist das Problem weniger extrem, da die Glocke und das Wort "Abbonieren" fehlt, wodurch mehr Platz für die Überschrift ist. In en.Wikipedia tritt das Problem nicht auf: dort wird links unterhalb der Überschrift "subscribe" angezeigt, ohne dass die Überschrift unpassend umgebrochen wird. --Kallichore (Diskussion) 23:14, 6. Dez. 2024 (CET)

Was ich inzwischen herausgefunden habe: Das Problem hängt mit Hilfe:Diskussionsseiten/Hilfsmittel zusammen. Wenn ich unter Einstellungen/Bearbeiten/Diskussionseiten die Punkte "Diskussionsaktivität anzeigen" und "Abschnittsabonnement" deaktiviere, tritt das Darstellungsproblem nicht mehr auf.--Kallichore (Diskussion) 10:29, 7. Dez. 2024 (CET)

Ja, weil dann die Diskussionsaktivität, die das Umbrechen verursacht, nicht mehr da ist. Das löst aber nicht das generelle Problem: Die Diskussionstools müssen umgebrochen werden, nicht der Titel. Das wäre eine Sache für Phabricator. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 09:19, 9. Dez. 2024 (CET)

Ist das wirklich der Minerva-Skin? Dort kommt eigentlich eine reduzierte Darstellung zum Tragen. -- hgzh 09:47, 9. Dez. 2024 (CET)

Schon. Die Diskussionstools sind aber Skin- und Geräteunabhängig aktiviert. Probiere es doch einfach selbst aus: https://de.wikipedia.org/wiki/Wikipedia:Technik/Werkstatt?useskin=minerva Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 09:59, 9. Dez. 2024 (CET)

Ja, das Problem tritt unter Minerva für de.wikipedia.org auf (durch Auswählen von MinervaNeue als Benutzeroberfläche oder durch useskin=minerva). Unter de.m.wikipedia.org tritt das Problem nicht auf. Zum Hinweis auf Phabricator: Das Problem tritt in en.Wikipedia und anderen Sprachvarianten nicht auf. Das spricht für mich gegen ein allgemeines Problem in Mediawiki.--Kallichore (Diskussion) 10:02, 9. Dez. 2024 (CET)

Ahja, ich hatte im MobileFrontend geschaut. Das Problem tritt auch in der enwp auf, wenn deutsche Spracheinstellungen aktiviert sind; die übersetzten Texte scheinen schlicht zu lang zu sein. -- hgzh 10:05, 9. Dez. 2024 (CET)

Kann man im translatewiki &shy; setzen? Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 14:18, 9. Dez. 2024 (CET)

Es gäbe ja genug Leerzeichen zum Umbrechen. Das Problem liegt beim genutzten Flexbox-Modell, das hier keine Umbrüche erlaubt. -- hgzh 07:56, 10. Dez. 2024 (CET)

Dann also doch etwas für den Phabricator. Das Tool sollte schließlich zuerst umgebrochen werden. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 09:04, 10. Dez. 2024 (CET)

Ich habe nun eine Meldung bei Phabricator erstellt.--Kallichore (Diskussion) 00:57, 13. Dez. 2024 (CET)

Wikipedia:Artikelwünsche

Hallo ihr

die hier unter

Wikipedia:Artikelwünsche

gesammelten Einträge

die ja eine Zusammenfassung der einzelnen Unterseiten der einzelnen Themen-Komplexe sind,

werden in meinen Augen in dieser geballten Form sehr unübersichtlich dargestellt

gäbe es eine technische Möglichkeit, das Ganze übersichtlicher darszustellen, zu entzerren ?

Gruß --Über-Blick (Diskussion) 14:29, 19. Feb. 2025 (CET)

@Über-Blick: Was? Das ist unübersichtlich? Erklär mal, warum (am besten konkret) ... --Doc Taxon (Diskussion) 18:27, 19. Feb. 2025 (CET)

ich finde diese Ballung unübersichtlich

Ideen (ohne Wissen bezüglich Umsetzbarkeit)

ich fände es gut wenn diese Wunschballung entweder so dagestellt werden könnten wie die Einträge in den Kategorien

oder wie hier in diesen Beispielen

• Veldensteiner_Kreis#Referenten
• Ludwig-Erhard-Stiftung#Mitglieder
• Seeheimer_Kreis#Struktur

Gruß --Über-Blick (Diskussion) 19:13, 19. Feb. 2025 (CET)

Naja, das hat man so gemacht, damit die Seiten nicht ganz so groß werden (im Sinne von Bildschirmkilometer). Das ist ja jetzt schon allerhand. Wenn ich das mal überschlage, würde eine solche Listung, wie Du sie vorschlägst, die Länge der Seite ca. verdoppeln, wenn das mal ausreicht. Doc Taxon (Diskussion) 20:52, 19. Feb. 2025 (CET)

also für mich ist da Wiki ist kein Papier ein Bezugspunkt

und so wie es aus- und ein-klappbare tools gibt, so ließe sich da doch eventuell auch eine Lösung finden -oder?

Gruß --Über-Blick (Diskussion) 02:21, 20. Feb. 2025 (CET)

würde mich über weitere Antworten / Reaktionen freuen Gruß --Über-Blick (Diskussion) 05:25, 26. Feb. 2025 (CET)

API Fehler bei Letzten Änderungen

Hallo zusammen, ich beobachte schon länger die letzten Änderungen per API, also etwa folgendermaßen:

from pywikibot.comms import eventstreams
stream = eventstreams.EventStreams(streams='recentchange')
stream.register_filter(type='edit', wiki='dewiki')
while True:
    change = next(stream)
    # do stuff ...
    if time.time() - change['timestamp'] > DELAY_THRESHOLD:
        # handle this problem

dabei ist mir schon vor Längerem aufgefallen, dass der Stream (damals noch sehr selten) zu etwa eine Woche alten Änderungen springt und mir danach die Änderungen der letzten Woche (nochmal) vorsetzt, bis er zu den aktuellen Änderungen aufgeschlossen hat. Die letzten Tage ist das dann nahezu stündlich aufgetreten, woraufhin ich das Skript sobald das auftritt habe neustarten lassen.

Trotzdem möchte ich hier fragen: Tritt ähnliches auch bei anderen auf? Mache ich was falsch? Soll ich mich damit an phabricator wenden?

Vielen Dank für eure Hilfe. --DerIch27 (Diskussion) 15:36, 17. Mär. 2025 (CET)

Mir ist übrigens gerade aufgefallen, dass ich das ganze schon als phab:T365949 im pywikibot phabricator gemeldet und mangels Reaktionen wieder vergessen habe. --DerIch27 (Diskussion) 17:36, 17. Mär. 2025 (CET)

Lint-Fehler: Fehlerhafte Dateioptionen

Hallo,
seit ein paar Tagen werden immer wieder Seiten in der Liste Lint-Fehler: Fehlerhafte Dateioptionen angezeigt, bei denen ich keinen offensichtlichen Fehler erkennen kann (zuletzt beispielsweise die Sprachverteilungsgrafiken im Artikel Spanien, davor z.B. Spezial:Diff/254447264). Das Gemeinsame an den bemängelten Stellen sind aufwendige Bildunterschriften mit Tabellen und mehreren Zeilen. Es scheint mir so, als ob ein Zeilenumbruch in einer Tabelle in einer Bildlegende nicht (mehr) erlaubt ist.
Wenn im Text

Text<br />
weiterer Text in der Folgezeile

vorkam, dann hat meistens das Löschen des Zeilenumbruchs geholfen, den (behaupteten) Lint-Fehler zum Verschwinden zu bringen.
Hast da jemand eine Ahnung, was da der Hintergrund sein kann? --At40mha (Diskussion) 18:41, 23. Mär. 2025 (CET)

Noch ein anderes Beispiel →Spezial:Diff/254480328/254487001, scheinbar ist es tatsächlich der „direkte Zeilenumbruch“ innerhalb einer Tabellenzelle, der stört.

{| style="border:0; padding:0; margin:0; width:100%;"
|-
| Inhalt links …
|
{{Farblegende|#cb0000|{{0|000}}>245}}
 
|}

Für mich gehören generell keine Tabellen in Bildlegenden. Vermutlich ist die (beim letzten Update verschärfte?) Analyse der Fehler darauf ausgelegt, dass Bildattribute eigentlich immer inline (in der selben Zeile) stehen, also so

[[Datei:Bild.png|mini|zentriert|hochkant|alt=Beschreibung für nicht sehende|Bildlegende, kurzer erleuternder oder ergänzender Text]]

Da sind keine Zeilenumbrüche vorgesehen. Dieses Beispiel Hilfe:Bilder#Legende bei farbigen Grafiken (als Empfehlung) hat mich schon immer gestört. --Liebe Grüße, Lómelinde Diskussion 07:56, 24. Mär. 2025 (CET)

Gibt es irgendwo einen Hinweis darauf, dass Tabellensyntax oder Zeilenumbrüche generell innerhalb von Bildlegenden nicht mehr erwünscht sind? Oder ist das ein Bug in der Linteranalyse? Das wäre schon wichtig zu wissen, damit man das, falls es sich um zukünftige Darstellungsfehler handelt, robust anpassen kann. --Liebe Grüße, Lómelinde Diskussion 11:17, 26. Mär. 2025 (CET)

Gesichtete Artikel in Nachsichtungslisten automatisch ausblenden

Ich fände es hilfreich, wenn in Nachsichtungslisten bereits gesichtete Artikel ausgeblendet werden könnten. So spart man sich den einen oder anderen Klick. --Leyo 22:05, 28. Mär. 2025 (CET)
PS. Es geht mir nicht um etwas für mich oder einzelne Benutzer (siehe Beispiel unten), sondern um eine Lösung für alle aktiven Sichter.

 .flaggedrevs-unreviewed {background-color: #EEEEE0 !important;}
 .flaggedrevs-unreviewed2 {background-color: #EEEEE0 !important;}

--Leyo 22:05, 28. Mär. 2025 (CET)

Dafür gibt es deep-out-of-sight als Tool, das mit Livedaten arbeitet. Eine Wikitextliste ist immer eine Momentaufnahme. -- hgzh 07:51, 31. Mär. 2025 (CEST)

Das ist mir klar, aber das erzeugt eine höhere Serverbelastung und bedingt jeweils eine kleine Wartezeit. Ich dachte an ein Ausblenden mit CSS oder JS für alle aktiven Sichter. So könnte der Nutzen der Nachsichtungslisten gesteigert werden. --Leyo 21:19, 5. Apr. 2025 (CEST)

Das ist nicht möglich. -- hgzh 09:35, 19. Jun. 2025 (CEST)

Bist du dir da ganz sicher? Eine Ergänzung unter MediaWiki:Group-editor.css wäre doch möglich. --Leyo 23:32, 19. Jun. 2025 (CEST)

Es gibt keine Möglichkeit, anhand eines Links per CSS herauszufinden, ob die verlinkte Seite gesichtet ist oder nicht. -- hgzh 08:26, 20. Jun. 2025 (CEST)

Offensichtlich doch. Ich habe den obigen Code in meiner monobook.css drin. Dadurch haben bei mir Links auf ungesichtete Seiten einen grauen Hintergrund, z.B. unter Wikipedia:Redaktion Chemie/Sichtung. Anstatt des grauen Hintergrunds könnte man ja den Link ggf. auch ausblenden oder anders formatieren. --Leyo 12:04, 20. Jun. 2025 (CEST)

Das ist das Benutzerskript Benutzer:P.Copp/scripts/markunreviewed.js, also keine reine CSS-Lösung. -- hgzh 07:44, 23. Jun. 2025 (CEST)

Den relevanten Teil könnte man unter MediaWiki:Group-editor.js einfügen. Oder in einem normalen Gadget. --Leyo 10:39, 23. Jun. 2025 (CEST)

Das Skript wirkt auf jede Seite und erzeugt pro Seitenaufruf zwei API-Abfragen. Zudem ist es nach kurzer Durchsicht etwas sanierungsbedürftig. Das ist definitiv nichts für eine Standardaktivierung. Wer das Skript nutzen will, kann es jetzt schon einbinden, da muss es kein Gadget werden. -- hgzh 08:00, 24. Jun. 2025 (CEST)

Deine Argumentation spricht gegen eine Aktivierung für alle Sichter, aber IMHO nicht gegen ein Gadget. Ein solches würde es weniger technikaffinen Sichtern erleichtern, diese Funktionalität zu nutzen. --Leyo 01:26, 28. Jun. 2025 (CEST)

Veränderte Schriftart bei Diff-Vorschau

Servus zusammen, schon länger besteht bei mir teilweise folgendes Problem: im normalen Editor bearbeite ich eine Seite und klicke auf „Vorschau zeigen“. Anschließend wird mir die Unterschiedsanzeige nicht (wie sie sollte) mit einer nichtproportionalen Schriftart angezeigt, sondern in einer „normalen“ Leseschriftart, was den Vergleich erschwert. Ein System dahinter, wann das Problem auftritt und wann nicht, habe ich nicht entdecken können, es tritt aber sowohl bei Vector 2010 als auch Vector 2022 auf. Kann das jemand nachvollziehen oder ist das sogar schon bekannt? Danke schonmal und VG –IWL04 • 17:35, 1. Apr. 2025 (CEST)

Kann es sein, dass du manchmal den Inline-Vergleich aktivierst? Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 12:03, 3. Apr. 2025 (CEST)

Nein, habe ich eigentlich noch nie verwendet … VG –IWL04 • 12:17, 3. Apr. 2025 (CEST)

Der wird mir in der Bearbeitungsvorschau auch gar nicht angeboten, es geht mir nicht um die Diff-Anzeige veröffentlichter Änderungen. –IWL04 • 14:45, 3. Apr. 2025 (CEST)

Was ist denn für dich der „normale“ Editor? Was hast du denn hier Spezial:Einstellungen#mw-prefsection-editing →Hilfe:Einstellungen#Bearbeitungsprogramm eingestellt, da gibt es drei Optionen. Zudem gibt es auch mehrere unterschiedliche Diff-Ansichten so habe ich beispielsweise bei mir derer 3. Die Standarddarstellung (Klassisch [[]], Monospace, gelb/blau) die visuelle (mit dem Auge, Normalschrift, rot/grün) und dann noch die verbesserte Benutzer:Schnark/js/diff (Normalschrift rot/grün). Irgendein Cookie merkt sich, was du zuletzt benutzt hast und wendet das dann so lange an, bis du es wieder umschaltest. „Ein System dahinter, wann das Problem auftritt und wann nicht …“ Ich verwende beispielsweise immer Schnarks Diff, wenn ich aber selbst da Probleme habe wechsle ich zum Klassischen, und natürlich dann wieder zurück. Mir wird auch die Änderung nur angezeigt wenn ich „Änderungen zeigen“ anklicke nicht wenn ich „Vorschau zeigen“ klicke. Aber auch da gibt es, soweit ich mich erinnere mehrere Optionen innerhalb der Einstellungen. --Liebe Grüße, Lómelinde Diskussion 08:22, 6. Apr. 2025 (CEST)

Ja, „Änderungen zeigen“ meine ich natürlich. Ich nutze die klassische Quelltextbearbeitung, nicht den Visual Editor oder Wikitext-Editor 2017, die Vorschau wird mir in Monospace und gelb/blau angezeigt. VG –IWL04 • 14:12, 19. Apr. 2025 (CEST)

Darstellung von "math" in Bildunterschriften

Hallo, Ihr Lieben!

Im Artikel Primzahlsatz hatte ich die Bildunterschrift von π(x)
auf $\pi (x)$ geändert, mit <math>...</math>.

In der Vergrößerung wird leider alles, was zwischen math und /math steht, nicht berücksichtigt. Das zu ändern wäre super!

Viele Grüße,
--Larry2718 (Diskussion) 23:42, 3. Apr. 2025 (CEST)

Hallo, das Problem kann ich mit sämtlichen Formel-Renderern und sowohl browser- als auch sitespezifischem Zoom nicht nachvollziehen. Welchen Browser nutzt du? -- hgzh 07:53, 4. Apr. 2025 (CEST)

Ich vermute, dass es um die Bildunterschrift im Mediaviewer geht, der sich nach einem Linksklick öffnet. Dort sehe ich ebenfalls "von (rot)" ohne $\pi (x)$.--Kallichore (Diskussion) 09:23, 4. Apr. 2025 (CEST)

Ah, das war mit „Vergrößerung“ gemeint. -- hgzh 12:54, 4. Apr. 2025 (CEST)

Weite Breite für Portalnamensraum

Die Hauptseite ist ja in Vector-2022, Einstellung Standartbreite, breiter als die anderen Seiten. Wohl wegen dem mehrspaltiges Layout. Wäre eine erweiterte Breite auch bei Portalen (in der Regel ja auch mehrspaltig) denkbar? Wurde das schon mal diskutiert? --217.238.226.28 13:14, 4. Apr. 2025 (CEST)

Bei mir ist (unangemeldet) die Hauptseite genauso wie überall sonst. Nur das sie eben kein Inhaltsverzeichnis hat und somit die linke Seite fehlt. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 08:26, 6. Apr. 2025 (CEST)

Du brauchst einen relativ breiten Bildschirm (genau: min. 1120px Browserfenster), um den Effekt sehen zu können. Klappe am besten alle Seitenleisten ein, dann sind normale Artikel relativ schmal, die Hauptseite deutlich breiter. Die Hauptseite hat wohl ein max-width: 99.75rem (.mw-page-container), Artikel ein max-width: 59.25rem (.mw-body per Grid). --217.238.236.160 10:37, 7. Apr. 2025 (CEST)

Edge-Browser auf dem iPad funktioniert nur mit Einschränkungen

IPadOS 18.4.1: Edge-Version: 135.0.3179.72: Wenn ich auf „Beantworten“ oder „Danken“ tippe passiert häufig nichts. Alternativ kann ich lange auf „Beantworten“ tippen und die gewünschte Funktion dann in einem neuen Tab aufrufen. Darüber hinaus fehlt manchmal die Bearbeitungsleiste (Quelltextmodus) oder das Einfügen aus der Zwischenablage funktioniert nicht. Teilweise hilft das Neuladen der Seite aber nicht immer. (Mit dem Chrome oder Firefox habe ich solches Verhalten noch nicht bemerkt.) --Molgreen (Diskussion) 13:40, 19. Apr. 2025 (CEST)

Auch das Löschen aller Browser-Daten ist keine Lösung. --Molgreen (Diskussion) 14:03, 19. Apr. 2025 (CEST)

Ich meine, dass das Problem bei Commons nicht besteht!(?) --Molgreen (Diskussion) 13:53, 20. Apr. 2025 (CEST)

Google-Book-Links mit "edition" in Adresse

Ich wollte mal fragen, wie andere das sehen:

Wenn es nach mir ginge, sollten die Links, die von Google Book inzwischen stabdardmäßig ausgegeben werden, durch die klassische Ansicht ersetzt werden. Im Firefox erhalte ich die Fehlermeldung „Firefox darf diese eingebettete Seite nicht öffnen“ und erst nach Schließen dieser Meldung kommt man zur Google-Seite, die dann aber nur die Titelseite anzeigt und nicht die gewünschte Seite. Google bietet dann selbst einen Link zur klassischen Ansicht an. Weil das eventuell der Camelbot übernehmen könnte, pinge ich mal Seth an. Ich habe bei ihm kürzlich wegen einer anderen Sache den Artikel Batterieglas erwähnt, wo in der aktuellen Version vom 8. Mai 2025 um 14:34:02 Uhr mehrfach solche Links vorkommen (ich will in dem Zusammenhang auf meine Nachricht auf der Seite des Benutzers hinweisen, der das eingefügt hat: Spezial:Diff/256348927). Nehmen wir von dort den ersten Beleg dieser Art als Beispiel:

• https://www.google.de/books/edition/Leitfaden_f%C3%BCr_physikalische_Sch%C3%BCler%C3%BCb/JaW0BgAAQBAJ?hl=de&gbpv=1&dq=Batterieglas&pg=PA227&printsec=frontcover (1)
• Nach Klick auf „Zurück zum klassischen Google“ wird man weitergeleitet zu https://books.google.de/books?id=JaW0BgAAQBAJ&newbks=1&newbks_redir=0&printsec=frontcover&pg=PA227&dq=Batterieglas&hl=de&redir_esc=y#v=onepage&q=Batterieglas&f=false (2)
• Meiner Ansicht nach könnte das gekürzt werden zu https://books.google.de/books?id=JaW0BgAAQBAJ&pg=PA227&dq=Batterieglas&hl=de#v=onepage&q=Batterieglas&f=false (3) – dachte ich eigentlich, aber:
• Das Problem hier: Im Microsoft Edge sind die beiden letzten Links nicht zu gebrauchen, weil die Seite nicht angezeigt wird, andere Chromium-Browser müsste man eventuell noch testen).
• Mit Vorlage {{Google Buch}} ergibt sich dagegen der noch kürzere Link https://books.google.de/books?id=JaW0BgAAQBAJ&pg=PA227&q=Batterieglas#v=onepage (4) und der funktioniert in Edge!

Also müsste meiner Meinung nach

https://www.google.TLD/books/edition/$Buchtitel$/$ID$?hl=de&gbpv=1&dq=$Suchbegriff$&pg=$Seite$&printsec=frontcover

($Buchtitel$ ist übrigens nicht immer der vollständige Titel!) geändert werden zu

https://www.google.TLD//books?id=$ID$&pg=$Seite$&q=$Suchbegriff$#v=onepage (oder doch &dq=$Suchbegriff$?)

Oder habe ich etwas übersehen? Und eine Änderung der Art, dass sogar die Vorlage benutzt wird (obwohl ich die für viel lesbarer halte), dürfte zu weit gehen, oder? — Speravir – 02:29, 26. Mai 2025 (CEST)

Gudn Tach!

Verwandte Diskussionen:

• WP:Bots/Anfragen#Vorlage:Google_Buch_einfügen
• WP:Bots/Anfragen#google-books-links_kuerzen

Was meinst du mit "weil die Seite nicht angezeigt wird"? Wenn ich den Link aus deinem dritten Aufzählungspunkt in Chromium aufrufe, erhielt ich beim ersten Aufruf das HTML-Framework, aber auf der Buchseite stand nur "Imange not found". Beim Neuladen war die Buchseite dann aber korrekt zu sehen.

-- seth (Diskussion) 09:04, 26. Mai 2025 (CEST)

Ich fände es schon sinnvoll, die Vorlage zu nutzen. Jede neue Linkänderung kann dann nämlich einfach per Vorlage korrigiert werden. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 09:19, 26. Mai 2025 (CEST)

O je, ich hatte erstmal nur nachfragen wollen, aber wollen wir das vielleicht doch besser nach WP:Bots verschieben?

Ich habe oben nachträglich Nummern hinter die Google-Links gesetzt. Seth, im MS Edge bekam ich bei Link 2 und 3 statt des eigentlichen Inhalts genau die von dir genannte Seite mit grauem Text “Image not found”. Dass ein einfaches Neuladen den richtigen Inhalt ausliefert, darauf kam ich nicht und das darf man doch auch nicht von einem beliebigen Nutzer voraussetzen. Nachdem ich jetzt dasselbe wie Du tat bei Link 2, wurde Link 3 sofort sauber aufgerufen.

MM…, grundsätzlich bin ich ja ebenso für die Vorlage, wie oben schon nebenbei erwähnt. Ich weiß nur nicht, wie komplex die Links sind und ob ein Bot alle Fälle abfangen kann, aber den Teil mit $Buchtitel$ wegzulassen und die ID als Adressfragment wieder einzufügen sowie den überflüssigen Teil zum Frontcover zu entfernen, wenn man eine andere Seite anzeigen will, sollte vollautomatisch möglich sein. Zu einer potentiell irgendwann notwendigen Änderung der Vorlage: Es gibt dabei ein riesiges Problem mit diesen Editionslinks: Dieser Teil $Buchtitel$ darf leider nicht aus der Adresse weggelassen werden (das ist bei anderen Webprojekten anders), obwohl die ID bereits eindeutig sein sollte, wenn sie ihrem Namen gerecht werden soll. IMHO schlecht gemacht von den verantwortlichen Google-Programmierern.

— Speravir – 01:11, 27. Mai 2025 (CEST)

Zu dem Link-Problem: Ok, wenn das bei dir mit dem Neuladen auch klappt, dann vermute ich, dass das Problem vielleicht von kurzer Dauer sein wird, also der Source-Code (JS-Race-Condition?) noch behoben wird.

-- seth (Diskussion) 08:00, 27. Mai 2025 (CEST)

Seth, ich verstehe nicht: Welcher Sourcecode, welches Javascript, das eine Race-Condition auslösen kann? — Speravir – 02:12, 31. Mai 2025 (CEST)

Gudn Tach!

Nur kurz, weil auf dem Sprung. Ich meine die google-seitige Reload-Problematik. Welcher Code das genau ist, müsste man vermutlich stundenlang suchen.

-- seth (Diskussion) 09:26, 31. Mai 2025 (CEST)

Uhr-Symbol in BEO verschwindet vorzeitig

Hallo, das Uhr-Symbol für die zeitlich begrenzte Beobachtung einer Disku wird in meiner BEO nicht mehr angezeigt, obwohl bei Aufruf der VG der Disku zu erkennen ist, dass sie noch ein paar Stunden beobachtet wird.

Verschwindet das Uhr-Symbol also unerwünscht vorzeitig (weil dann noch Änderungen vorgenommen werden könnten), oder anders gefragt: Wie läuft hier die Programmierung?

Gruß, --Wi-luc-ky (Diskussion) 00:33, 16. Jun. 2025 (CEST)

Anzahl Anzeigen

Ich habe bei Wikipedia:Dark Mode/Probleme eine Übersicht Problematischer Parameter hinzugefügt und möchte Fragen kann man da Automatisch daneben die Anzahl der Ergebnisse Anzeigen lassen? Karma (Diskussion) 21:22, 22. Jun. 2025 (CEST)

Code Vorlage:Supported by Wikimedia Deutschland

Hallo,

ich habe soeben mal ausprobiert, wie es aussieht, wenn ich den Code Vorlage:Supported by Wikimedia Deutschland (siehe: Wikipedia:Wikimedia Deutschland/Community-Portal/Förderung/Aktualisierung Förderrichtlinien 2024/Neue Richtlinie ab 1.7.2025, Punkt 4.4.(2.)) als Kopie von dort in die Beschreibung von hochzuladenden Fotos einfüge. Dabei ist bei meinen soeben hochgeladenen Fotos „Im LSG Schnauderaue westlich von Droßkau“ 01 bis 06 und „Die Alte Schnauder westlich von Droßkau“ 01 bis 04 etwas passiert, was ich nicht nachvollziehen kann und ziemlich programmiertechnisch aussieht, aber wesentlch mehr als den Hinweis auf die Förderung kommuniziert.

Wie entferne ich das wieder, ohne noch mehr Unverständliches zu produzieren?

Wie kann ich ab dem 01.07.2025 ordentlich und unaufwändig den nachvollziehbar gewünschten Verweis auf die Förderung von Wikipedia ohne den jetzigen Programmierkauderwelsch in meine Fotodateien einfügen?

Danke schon mal im Voraus für die Hilfe und Aufklärung.

Andreas --Huth, Andreas (Diskussion) 15:45, 25. Jun. 2025 (CEST)

Also weder gibt es die Vorlage noch den Punkt 4.2.(2.) auf der verlinkten Seite.

Wenn du das Problem auf Commons meinst (auch dort gibt es übrigens ein Forum) - du darst das ganze Zeug nicht in die Beschreibungszeile setzen:

|description={{de|1={{Supported by Wikimedia Deutschland|year=2025}}}}[[Category:Images from Wiki Loves Earth 2025, DE landscape]]{{Wiki Loves Earth 2025 special nomination|no}}

Vorlagen und Kategorie gehören extra: https://commons.wikimedia.org/w/index.php?title=File:Im_LSG_Schnauderaue_westlich_von_Dro%C3%9Fkau_06.jpg&diff=prev&oldid=1048800204 --Magnus (Diskussion) 15:59, 25. Jun. 2025 (CEST)

Hallo Magnus,

hab Dank für Deine schnelle Reaktion!

Auf der von mir verlinkten Seite Wikipedia:Wikimedia Deutschland/Community-Portal/Förderung/Aktualisierung Förderrichtlinien 2024/Neue Richtlinie ab 1.7.2025 stehen unter der Überschrift 1. Grades „Neue Förderrichtlinie“ (etwa Beginn des 2. Drittels der Seite) die Überschriften

1. Ziel und Zweck der Förderung

2. Geförderte Personen

3. Art und Umfang der Förderung

4. Verpflichtungen der geförderten Personen.

Und hier stehen die Unterüberschriften:

4.1. Lizenzierung und Weiternutzung sowie

4.2. Weitere Bestimmungen.

Hier folgen die Unterpunkte

(1) Zielgruppen der Projekte und

(2) Hinweis auf die Förderung

Und hier unter diesem Punkt (2) steht (von mir von dort kopiert und hier von mir der Deutlichkeit halber als Zitat kursiv und zusätzlich fett bei dem betreffenden Textteil zu Mediendateien formatiert zitiert): „Mit Unterstützung der Förderung entstandene Ergebnisse und Produkte müssen als solche gekennzeichnet werden (z. B. „Gefördert von Wikimedia Deutschland“). Für Mediendateien auf Wikimedia Commons ist dies zu realisieren, indem in der Beschreibungsseite folgender Code eingefügt wird: Vorlage:Supported by Wikimedia Deutschland. Erstellte Textinhalte der Wikimedia-Projekte (z. B. Wikipedia-Artikel) sind von der Kennzeichnungspflicht ausgenommen.“

Die hier beim Kopieren rot erscheinende Textpassage Vorlage:Supported by Wikimedia Deutschland ist eine Vorlage, supported von Wikimedia Deutschland hatte ich gemeint, ganz simpel kopieren zu können und wie vorgeschrieben in die Beschreibung der Fotodatei beim Hochladen einfügen zu können, wobei ich die vier xxxx auf der Originalseite, die sich hier als kopierte Textstelle gar nicht zeigen, durch die Jahreszahl 2025 ersetzte.

Ich bin kein Programmierer, bediene seit Jahrzehnten nur Apple-Rechner und würde gern das einfache Arbeiten von dort auch gern hier in Wikipedia wiederfinden. Deshalb verstehe ich nicht, was da passiert ist, wenn ich eine vorgegebene Vorlage von Wikimedia Deutschland benutze, und diese bringt nicht das hervor, was sie ankündigt und vorschreibt.

Darauf möchteich hier in der Technik-Werkstatt hinweisen, denn aus meiner Sicht stimmt da etwas nicht beim Programmieren bzw. der Technik. Oder sehe ich das falsch?

Ich habe jetzt Deinen Link https://commons.wikimedia.org/w/index.php?title=File:Im_LSG_Schnauderaue_westlich_von_Dro%C3%9Fkau_06.jpg&diff=prev&oldid=1048800204 geöffnet und meine dort zu sehen, dass Du den ab 01.07.2025 gewünschten Vermerk wieder gelöscht hast.

Das beantwortete aber aus meiner Sicht noch nicht meine Frage: Wie soll ich ab dem 01.07.2025 dem gemäß neuer Föderrichtlinie gewünschten Vermerk auf die Förderung in meine hochzuladenden Bilddateien einfügen? Was ich heute ausprobiert habe, funktioniert nicht.

Deshalb würde ich mich über eine Antwort freuen, die ich einfach und simpel verwenden kann, um den neuen Anforderungen ab 01.07.2025 entsprechen zu können.

Andreas --Huth, Andreas (Diskussion) 17:07, 25. Jun. 2025 (CEST)

Ich habe den Vermerk nicht gelöscht, sondern an die richtige Stelle verschoben.

Ich weiß aber nicht, was du im Hochladeformular siehst. Im normalen Upload-Wizard (also nicht dme angepassten Campain-Tool) gibt es einen Bereich für weitere Angaben. Dort kann man solche Templates eintragen. Diese werden dann unterhalb des Beschreibungsbereichs platziert. --Magnus (Diskussion) 17:17, 25. Jun. 2025 (CEST)

Ok, das mit dem Löschen bzw. Verschiebgen zeigt meine Unkenntnis des Programmierens.

Ich lade meine Fotos über https://uploadmap.toolforge.org/protectedareasde.html hoch. Meinst Du den Uploader: https://commons.m.wikimedia.org/wiki/Special:UploadWizard? --Huth, Andreas (Diskussion) 19:10, 25. Jun. 2025 (CEST)

Ok! Hurra, ich habs! Zum Test habe ich jetzt die Datei https://commons.wikimedia.org/wiki/File:Die_Schnauder_bei_Wischstauden_01.jpg über meinen gewohnten Uploader https://uploadmap.toolforge.org/protectedareasde.html hochgeladen und das aufklappbare Infofenster versuchsweise mit der kopierten Vorlage gefüllt. Und DAS hat jetzt das selbe Ergebnis mit dem Hinweis im hellgrünen Fenster unter allem erbracht.

Ich kann jetzt also den Verweis auf die Förderung einarbeiten!

Hab Dank für Deine Geduld und Hilfestellung! --Huth, Andreas (Diskussion) 19:28, 25. Jun. 2025 (CEST)

In der soeben erwähnten Datei https://commons.wikimedia.org/wiki/File:Die_Schnauder_bei_Wischstauden_01.jpg habe ich der Konsequenz wegen den Hinweis auf die Förderung wieder gelöscht. Alle anderen Dateien zum LSG Schnauderaue beinhalten ebenso nicht diesen Hinweis, der ja auch erst bei geförderten Projekten ab dem 01.07. eingearbeitet werden soll. Meine Fotos vom LSG Schnauderaue sind vom 19.06.

Aber auf alle Fälle habe ich es heute schon gelernt, diesen Verweis ordentlich einzuarbeiten!

So, jetzt habe ich wieder meine Ruhe, und ich lass Dich jetzt auch wieder in Ruhe! --Huth, Andreas (Diskussion) 20:04, 25. Jun. 2025 (CEST)

Nur ein kleiner Hinweis: Der Hinweis auf die Förderung bei erstellten Dateien ist nichts Neues, was erst ab dem 1. Juli 2025 gesetzt werden soll, sondern viel mehr eine seit 2012 gängige Praxis. --Sandro (WMDE) (Disk.) 09:09, 30. Jun. 2025 (CEST)

Ok, Sandro, das wusste ich leider noch nicht. Bei den bisherigen Förderungen wurde ich nicht explizit drauf hingewiesen. Ich werde es aber nun bei jedem Foto, das durch eine Übernahme der Fahrtkosten durch Wikipedia gefördert wurde, in Zukunft so handhaben. „Geübt“ habe ich es ja schon. Ich finde den Hinweisauf die Förderung unter geförderten Projekten völlig gerechtfertigt und sinnvoll! --Huth, Andreas (Diskussion) 13:04, 30. Jun. 2025 (CEST)

Sollte auch überhaupt kein Vorwurf sein. Tatsächlich steht es auch bisher schon in den Förderrichtlinien, Abschnitt „Weiternutzung“ Abs. 2. Aber diese Richtlinien sind deutlich weniger übersichtlich, weshalb mit der neuen Richtlinie ja auch der Wunsch verbunden war, mehr Übersichtlichkeit und Nachvollziehbarkeit zu schaffen. Und es zeigt sich ja hier auch sehr schön, dass das offenbar funktioniert hat.   --Sandro (WMDE) (Disk.) 17:20, 30. Jun. 2025 (CEST)

Deutsches Betawiki unerreichbar

Titel nachträglich (01:59, 29. Jun. 2025 (CEST)) leicht geändert.

Es wundert mich, dass es niemandem anderen aufzufallen scheint, was mich misstrauisch macht, aber: Für mich ist das Betawiki seit mindestens Mitte Mai (archiverte Mitteilung, in deren Zusammenhang es mir auffiel) nicht aufrufbar. Ich bekomme bei Aufruf von https://de.wikipedia.beta.wmflabs.org/wiki/Wikipedia:Hauptseite die Fehlermeldung “Our servers are currently under maintenance or experiencing a technical issue”, und zwar auch mit verschiedenen Browsern. Kann man da nicht etwas tun, es wieder zum Leben zu erwecken? — Speravir – 00:56, 28. Jun. 2025 (CEST)

Bei mir funktioniert der Aufruf, ich erhalte die normale beta-Hauptseite, wie gehabt. --Doc Taxon (Diskussion) 03:34, 28. Jun. 2025 (CEST)

Geht bei mir auch einwandfrei. --tsor (Diskussion) 07:47, 28. Jun. 2025 (CEST)

Bei mir klappt auch alles, aber ich hab in den letzten Wochen wiederholt Ausfälle erlebt. Ich würde vermuten, dass die gelegentlichen Probleme mit phab:T393487 zu tun haben, die Maßnahmen gegen den Bot-Traffic scheinen die Situation zwar verbessert, aber nicht gelöst zu haben. --Johannnes89 (Diskussion) 13:34, 28. Jun. 2025 (CEST)

Danke euch allen. Tja, ich hatte es schon geahnt. Inzwischen habe ich en:Wikipedia:Wikimedia Foundation error gefunden. In der Tat steht im unteren Teil der Seite grau auf grau und ziemlich klein geschrieben “If you report this error to the Wikimedia System Administrators, please include the details below. […]” Ich hab das wegen der geringen Schriftgröße und dem schlechten Kontrast für eine unwichtige, allgemeine Mitteilung gehalten und nicht genau hingesehen. Toll. (Sieht exakt so aus wie hier, hier und hier, nur mit Fehlernummer 403). Man wird dann zu wikitech:/Beta/Blocked geschickt (ist eine Weiterleitung) und das muss ich mir erst einmal ansehen. — Speravir – 01:39, 29. Jun. 2025 (CEST)

… Und auf der Wikitech-Site ist erstens der Phab-Task verlinkt, den Johannes oben schon angegeben hat, und zweitens soll man einen neuen (geschützten) Subtask dazu anlegen, was ich eben getan habe. — Speravir – 01:59, 29. Jun. 2025 (CEST)

Zur Info: Ich habe wieder Zugang. Laut Mitteilung des Entsperrenden war ich unglücklicherweise von einem IP-Range-Block betroffen. — Speravir – 00:08, 1. Jul. 2025 (CEST)

Kann bitte mal jemand dafür sorgen, dass die damit aufhören nach und nach irgendwelche Ranges zu blocken? Was nutzt mir denn bitteschön eine Testversion, wenn ich sie nicht mehr erreichen kann. Selbst der Lesezugriff wird ja verweigert. Ich kann also nicht auf Seiten mit Vorlagen nachschauen, wie man ein Problem eventuell lösen könnte, das ich gern lösen würde. Das ist absolut kontraproduktiv. Es betrifft im Übrigen auch andere Betaversionen, scheint also eine Art global-Block zu sein. Ich habe keine Lust irgendjemanden anbetteln zu müssen, damit ich da wieder reingelassen werde oder ständig zu testen, ob es eventuell wieder von allein geht. Und ich bin auch weder ein Bot noch ein Crawler oder was auch immer sie aussperren wollen. --Liebe Grüße, Lómelinde Diskussion 15:26, 22. Jul. 2025 (CEST)

Das Betawiki ist ja nach https://de.wikipedia.beta.wmcloud.org/wiki/Wikipedia:Hauptseite umgezogen. Betrifft es auch diesen Link? -- hgzh 17:22, 22. Jul. 2025 (CEST)

Ja, der ist ebenso “your ip have been blocked …” wie der andere. --Liebe Grüße, Lómelinde Diskussion 17:54, 22. Jul. 2025 (CEST)

Anders als in phab:T393487 / wikitech:Nova Resource:Deployment-prep/Blocked help beschrieben, geht es wohl aktuell leider nicht, um mit den Botproblemen zurecht zu kommen.

Über diesen Link [9] kann man ein geschütztes Ticket anlegen, worauf nur WMF-Mitarbeitende und Stewards zugreifen können, im Regelfall wird dann innerhalb von 1-2 Tagen die genannte IP / IP-Range freigegeben. --Johannnes89 (Diskussion) 18:51, 22. Jul. 2025 (CEST)

Ich möchte mich aber nicht beim Phabricator anmelden und auch keine Tickets irgendwo anlegen. Ich habe nichts verbrochen und was nutzt es denn, wenn die eine Range oder nur die eine IP wieder freigegeben wird und ich beim nächsten mal mit einer anderen dann wieder draußen stehe? Nein das ist nicht zufriedenstellend. Ich verstehe Phab nicht und möchte mich auch nicht damit befassen. Ich suche nur etwas, das ich derzeit nicht einsehen kann, das mir aber eventuell weiterhelfen würde. Insbesondere wenn es nach Softwareupdates Neuerungen gibt und ich diese auf Beta testen soll, geht das halt zukünftig nicht mehr, dann müssen sich andere kümmern und die Hilfeseiten aktualisieren. --Liebe Grüße, Lómelinde Diskussion 19:22, 22. Jul. 2025 (CEST)

Ich könnte dir anbieten, das nötige private Security-Ticket für dich anzulegen, wenn du mir per Wikimail schickst, welche IPs / IP-Ranges entsperrt werden sollen (siehe [10] als Bestätigung meiner WMF-Vertraulichkeitserklärung). Das würde das Problem für den Moment lösen, dann kann man immer noch schauen, was passiert, solltest du tatsächlich in neuen Ranges landen die sich auch als gesperrt erweisen. Aktuell scheint die WMF keinen anderen Weg zu sehen, als unschuldige User gemeinsam mit Bot-Traffic auszusperren und dann die unschuldigen User auf Anfrage manuell wieder reinzulassen. --Johannnes89 (Diskussion) 19:36, 22. Jul. 2025 (CEST)

Wikipedia-App: 2.7.50538-r-2025-06-24: keine Bearbeitung trotz Anmeldung möglich

Ich wollte in der Wikipedia-App (2.7.50538-r-2025-06-24) in einer Diskussion antworten, kann dies aber nicht, weil "behauptet" wird, ich sei nicht angemeldet, bin es aber definitiv (siehe Screenshots). Der Fehler tritt bei mir auch nach einer Abmeldung und einer erneuten Anmeldung auf.

• 
  angemeldet als Molgreen
• 
  Versuch zu antworten
• 
  zu sehen ist, dass statt Molgreen eine temporäre Kennung (~2025-*) verwendet wird
• 
  Absenden der Antwort nicht möglich
• 
  Absenden der Antwort nicht möglich, da nicht angemeldet: auch nicht als temporäre Kennung
• 
  Benachrichtigungen kommen an
• 
  nach Neuanmeldung

--Molgreen (Diskussion) 16:58, 8. Jul. 2025 (CEST)

Anzuzeigende Zeitperiode wird automatisch reduziert

Hallo, seit gestern fällt bei mir das Pull-Down-Menü für die Anzuzeigende Zeitperiode ungewollt auf 1 Stunde zurück. Nachdem ein größerer Zeitraum gewählt wurde, wird dieser zwar angezeigt, aber die nächste BEO würde wieder nur 1 Stunde umfassen, wenn nicht vorher erhöht wurde usw. Spezial:Einstellungen#mw-prefsection-watchlist: Max. 1 Tag.

Analyse? Lösungen? Gruß, --Wi-luc-ky (Diskussion) 01:54, 12. Jul. 2025 (CEST)

Siehe WP:Fragen zur Wikipedia#Anzuzeigende Zeitperiode auf der Beobachtungsliste, warum soll das hier doppelt besprochen werden? --Liebe Grüße, Lómelinde Diskussion 07:36, 12. Jul. 2025 (CEST)

Mailsendebestätigung

Die Wikimailfunktion ist ja sehr praktisch, allerdings wäre es oft hilfreich, dass der Sender, wie auch immer, eine Information, erhielte, falls das System eine Fehlermeldung wegen Unzustellbarkeit erhält. Oftmals ändert der User im Laufe der Zeit seine Mailadresse, das Postfach ist voll oder wie es auch immer wieder vorkommt, dass Wikipedia-Mails im Spamfilter hängenbleiben und gar nicht zugestellt werden. Ich glaube das wäre sehr hilfreich in der Kommunikation, wenn diese Möglichkeit z. Bsp. in den Meldungen geschaffen würde. --K@rl du findest mich auch im Ö..wiki 09:53, 12. Jul. 2025 (CEST)

Wikidata Item and Property labels soon displayed in Wiki Watchlist/Recent Changes

(Apologies for posting in English, you can help by translating into your language)

Hello everyone, the Wikidata For Wikimedia Projects team is excited to announce an upcoming change in how Wikidata edit changelogs are displayed in your Watchlists and Recent Changes lists. If an edit is made on Wikidata that affects a page in another Wikimedia Project, the changelog will contain some information about the nature of the edit. This can include a QID (or Q-number), a PID (or P-number) and a value (which can be text, numbers, dates, or also QID or PID’s). Confused by these terms? See the Wikidata:Glossary for further explanations.

The upcoming change is scheduled for 17.07.2025, between 1300 - 1500 UTC. The change will display the label (item name) alongside any QID or PIDs, as seen in the image below:

These changes will only be visible if you have Wikidata edits enabled in your User Preferences for Watchlists and Recent Changes, or have the active filter ‘Wikidata edits’ checkbox toggled on, directly on the Watchlist and Recent Changes pages.

Your bot and gadget may be affected! There are thousands of bots, gadgets and user-scripts and whilst we have researched potential effects to many of them, we cannot guarantee there won’t be some that are broken or affected by this change.

Further information and context about this change, including how your bot may be affected can be found on this project task page. We welcome your questions and feedback, please write to us on this dedicated Talk page.

Thank you, - Danny Benjafield (WMDE) on behalf of the Wikidata For Wikimedia Projects Team. MediaWiki message delivery (Diskussion) 14:45, 14. Jul. 2025 (CEST)

Probleme mit http://persondata.toolforge.org

Ich hab aktuell mehrmals gehört, die Seite wäre nicht mehr gar so toll. Dauert lange bis was passiert.

Jetzt hab ich mal das access-log angemacht und festgestellt, dass knapp 70 % der Zugriffe von einem Dings mit der Browser-Kennung Mozilla/5.0 (Linux; Android 7.0;) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 (compatible; PetalBot;+https://webmaster.petalsearch.com/site/petalbot) kommen.

Okay. robots. txt erzeugt und dort PetalBot eingetragen, sollte also bald erledigt sein.

Aber ganz generell frage ich mich, warum der erzeugte HTML-Code so aussieht: <a class="external text" href="https://persondata.toolforge.org/p/Johann_Wolfgang_von_Goethe">Wikipedia-Personensuche</a>

und nicht wie beim Link auf die GND: <a rel="nofollow" class="external text" href="https://d-nb.info/gnd/118540238">118540238</a>

Dieses fehlende "nofollow" gefällt mir nicht so ganz toll. Kann man das in der Vorlage erzwingen?

PS: Ein tools:persondata/robots.txt würde auch nicht helfen, das erzeugt auch kein "nofollow" <a href="//toolserver.org/persondata/robots.txt" class="extiw" title="tools:persondata/robits.txt">tools:persondata/robots.txt</a>

Da frage ich mich, wie kommt die Entscheidung mit/ohne "nofollow" zustande bzw. wie kann ich das im Vorlagen-Code erzwingen? Vorausgestzt natürlich, dass der Crawler von dieser Seite kommt. --Wurgl (Diskussion) 23:33, 15. Jul. 2025 (CEST)

Du bist hier auf der Diskussionsseite und nicht vornerum, aber ich helf ja gerne.

Soweit ich das verstanden habe, fragst du nach der Umsetzung von Wikitext in HTML und <a>.

Da haben wir im Wikitext keinerlei Einfluss drauf, das könnte nur individuelles JavaScript.

Ich weiß auch nicht so genau, an genau welchen Stellen du diesen HTML-Code gesehen hast.

Die WMF kennt aber auch die Familie und toolforge und behandelt ggf. innerfamiliäre Webseiten anders als völlig fremde.

extiw kommt aus Pseudo.Interwiki und ist wieder was anderes als external.

VG --PerfektesChaos 23:44, 15. Jul. 2025 (CEST)

Argh! Verguckt. Einfach in der Beobachtungsliste gesucht und erster Treffer. Argh!

Es war die Seite vom Wolferl, also dem hier: Johann Wolfgang von Goethe, runterscrollen, auf die GND rechte Maustaste … Untersuchen … *tata* ich bin im im Quelltext bei den Developer-Tools des Browsers. Die Klassen sind schon okay, die verwende ich zum Einfärben in meinem commons.css, das "nofollow" hätte ich gerne.

Wenn ich dich richtig verstehe: Phab schreiben und dann gefühlt 2 Jahre warten. --Wurgl (Diskussion) 00:06, 16. Jul. 2025 (CEST)

Nicht 2, sondern 20. Gefühlt macht das dann 200.

Die Verknüpfung mit URL und eingebundenen Bildern läuft im Wiki grundsätzlich anders als in allgemeinem HTML, und zwar aus Sicherheitsgründen.

Das nofollow macht auch nichts dramatisch weltrettendes. Es ist nur ein Tipp an seitendurchsuchende Krabbler der Suchmaschinen, dieser Verlinkung besser nicht zu folgen, weil das wo es hinverlinkt eh uninteressant wäre und die Suchmaschine nur unnötig belasten würde. Und damit werden die richtig per URL generierten Weblinks außerhalb der Familie ausgestattet; damit wir keine überflüssige Reklame für jede Schrott-Website im ANR machen. toolforge scheint als Familienmitglied bekannt zu sein wie wikisource oder wikimedia.org und so. Denen soll von der Suchmaschine gefolgt werden. Wobei google: als Pseudo-Interwiki mit extiw dann Verwandtschaft vortäuscht und nicht external behandelt wird. external und nofollow scheinen verknüpft zu sein, falls Domain nicht WMF.

Nachdem Abschnitt geklärt ist, dann bitte hier spurenlos löschen und umseitig unten dran bamseln.

VG --PerfektesChaos 00:31, 16. Jul. 2025 (CEST)

Umgebamselt. Sorry nochmals. --Wurgl (Diskussion) 00:40, 16. Jul. 2025 (CEST)

Der Kampf ist hart. Die robots.txt schließt jetzt alle Bots aus, da dieser Bösewicht PetalBot (das ist Huawei) und ein paar andere aber nicht beeindruckt waren, bekommt jeder, dessen Useragent nach Bot müffelt, einen Status 403 vor den Latz geknallt. Was nach Bot müffelt entscheidet der folgende Code:

       strpos($_SERVER['HTTP_USER_AGENT'], 'archive.org_bot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'AwarioBot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'Amazonbot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'bingbot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'Brightbot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'CCBot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'ClaudeBot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'DataForSeoBot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'DotBot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'DuckDuckBot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'Googlebot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'GPTBot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'IABot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'libwww-perl') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'MojeekBot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'OAI-SearchBot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'PerplexityBot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'PetalBot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'PriEcoBot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'SemanticScholarBot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'SemrushBot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'SeznamBot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'Thinkbot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'TelegramBot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'Twitterbot') !== false ||
       strpos($_SERVER['HTTP_USER_AGENT'], 'YandexBot') !== false

Jetzt reagiert die Seite wohl wieder brav und (hoffentlich) schnell.

Wer libwww-perl/6.68 als Useragent hat, kann ich nicht sagen, aber 23.770 Einzelzugriffe (von 41.244) seit 0:30 ist ein wenig übertrieben. --Wurgl (Diskussion) 07:43, 17. Jul. 2025 (CEST)

Unterkategorien auf Kategorieseiten ein- bzw. ausklappen

Hallo zusammen. In einem privaten Wiki auf MW-Basis habe ich in einer Kategorie über 40 Unterkategorien. Dies ist am Desktop schon lästig, auf mobilen Endgeräten nervt es richtig. Daher möchte ich die Liste der Unterkategorien standardmäßig einklappen, finde dazu aber keine Lösung. Auch die Suche hier und bei mediawiki.org hat keine zielführenden Lösungen gebracht. Mal soll man mit den CSS-Klasse mw-collapsible und mw-collapsed zu arbeiten, oder die Erweiterung „CategoryTree“ benutzen. Nichts was ich bisher probiert habe, hat funktioniert.

Es geht um folgende Seite: https://wiki.cowboy-of-bottrop.de/wiki/Kategorie:Line_Dance:Stepsheet

Auch wenn es in diesem Fall nicht um die Wikipedia geht, vielleicht kann man hier auch mal irgendwo gebrauchen. Ich bedanke mich schonmal für zielführende Antworten. --CowboyOfBottrop (Diskussion) 18:18, 19. Jul. 2025 (CEST)

@CowboyOfBottrop: – Benutzer:PerfektesChaos/js/catTreeToggling

Müsste auch außerhalb der WMF funktionieren.

Mobil weiß ich nicht sicher, sollte aber gehen.

Common.js wirkt allerdings nur auf Desktop; wie du das in deinem Wiki für Mobil konfigurierst, weiß ich nicht und habe keine Lust es herauszufinden.

VG --PerfektesChaos 16:09, 21. Jul. 2025 (CEST)

Danke, ich werde mir das mal anschauen und dann Rückmeldung geben. --CowboyOfBottrop (Diskussion) 21:12, 21. Jul. 2025 (CEST)

Also, dein Script funktioniert auch außerhalb der WMF, und auch mobil klappt das wie vorgesehen. Das Problem: Es ist nicht das, was ich wollte. Ich möchte eigentlich Innerhalb der Kategorieseite die Subkategorien ausblenden, am Besten bereits beim Laden der Seite. Über einen Button oder Link soll das dann ausgeklappt werden.

Es geht also um <div#mw-subcategories> --CowboyOfBottrop (Diskussion) 00:06, 22. Jul. 2025 (CEST)

VisualEditor löscht list-defined references

Gemeldet in Phabricator
Task T400013

Moi, ich wollte gerade ein Phabricatorticket zu diesem Bug [11] aufmachen, aber bei weiteren Tests stelle ich fest, dass ich den Bug nicht in anderen Projekten replizieren kann, wenn ich den Artikelinhalt z.B. auf ne enwiki BNR-Seite kopiere. Haben wir bei uns in den letzten Tagen irgendwas geändert, was zu einem lokalen Problem führt? Ich kopier mal rein, was ich auf Phabricator geschrieben hätte:

Steps to replicate the issue:

• Open https://de.wikipedia.org/wiki/Benutzer:Johannnes89/Test4 in VisualEditor
• Make a minor change and save the page

What happens?:

• Most list-defined references are removed https://de.wikipedia.org/w/index.php?title=Benutzer:Johannnes89/Test4&diff=prev&oldid=258076729

What should have happened instead?:

• Just the minor edit, no change to the references

Other information:

• Dewiki articles affected so far: [12], [13], [14], [15], [16], [17], [18], [19], [20], [21]
• I was able to reproduce the bug with minimal content but when reducing the content even further the bug no longer occured.

--Johannnes89 (Diskussion) 13:07, 20. Jul. 2025 (CEST)

Hier ist das minimalste Beispiel, das ich finden konnte. In diesem Beispiel spielt die ISBN eine Rolle, die automatisch einen Link auf die ISBN-Suche erzeugt. Welcher Mechanismus steckt hinter den Links auf die ISBN Suche?--Kallichore (Diskussion) 13:51, 20. Jul. 2025 (CEST)

Das erklärt, warum ich das Problem nicht in der Englischsprachigen Wikipedia replizieren konnte, während bei uns mw:Manual:$wgEnableMagicLinks aktiviert ist, wurde das drüben 2021 deaktiviert phab:T275951. Dein Beispiel genutzt, tritt das Problem z.B. auch in frwiki auf [22], aber eben nicht in enwiki [23]. --Johannnes89 (Diskussion) 14:13, 20. Jul. 2025 (CEST)

phab:T400013 erstellt. --Johannnes89 (Diskussion) 23:18, 20. Jul. 2025 (CEST)

Heute Morgen gab es bereits einen Backport, um das Problem zu beheben. Bei mir tritt der Bug im Testbeispiel nicht mehr auf.--Kallichore (Diskussion) 15:22, 21. Jul. 2025 (CEST)

Hier sind noch Reste von gestern, die in obiger Liste noch fehlen. --Pankoken (Diskussion) 15:51, 21. Jul. 2025 (CEST)

Hi, danke an alle, die sich um die Artikel gekümmert haben, die am Wochenende von diesem Fehler betroffen waren (Pankoken, Itti, Kallichore, Wurgl, um ein paar zu erwähnen)! Im Zuge unserer Arbeit an Verbesserungen zu Einzelnachweisen hat das Technische-Wünsche-Team letzte Woche eine Codeänderung vorgenommen, die am Donnerstagabend in der deutschsprachigen Wikipedia wirksam wurde. Leider fiel erst am Wochenende durch aufmerksame Communitymitglieder auf, dass dabei in seltenen Fällen bei VisualEditor-Bearbeitungen Einzelnachweise am Artikelende fehlerhaft entfernt wurden (phab:T400013 / phab:T400038). Insgesamt waren 49 Artikel in sieben Wikipedia-Sprachversionen betroffen, die meisten davon hier in der deutschsprachigen Wikipedia. Montagmorgen haben wir den Fehler behoben und sichergestellt, dass er nicht erneut auftritt. In der Kategorie:Wikipedia:Seite mit Einzelnachweisfehlern befinden sich keine Artikel mehr, die von diesem Fehler beeinträchtigt wurden. Dankenswerterweise sind die meisten Bearbeitungen zügig von Communitymitgliedern repariert oder rückgängig gemacht worden. Unser Team führt zusätzliche automatisierte Tests ein (phab:T400052), damit sich so ein Fehler nicht wiederholt, bitte entschuldigt die Umstände.

Anbei eine Liste der Artikel, die zwischenzeitlich betroffen waren, falls ihr prüfen möchtet, ob ihr die angedachten Änderungen wieder im Artikel durchführen mögt:

• Spitzahorn: Ein Beleg wurde hinzugefügt und durch den Revert wieder entfernt [24]
• Prachtnelke: Ein Wikilink wurde hinzugefügt und durch den Revert entfernt
• Gewöhnliche Robinie: Wurde eigentlich gefixt, aber im Wikitext ist nun ein doppelter "InfoFlora"-Einzelnachweis [25]
• Sonderwaffenlager Himmelpfort: Der Fehler wurde behoben, indem der Einzelnachweis ganz entfernt wurde [26], was vermutlich nicht ideal ist
• Honoki-Magnolie: Durch den Revert fehlt auch die Artikeländerung
• Alecton (Schiff, 1861): Durch den Revert fehlt der Fix “mythologische” -> “mythische” Wesen
• Hubertusburg: Durch den Revert fehlt die Änderung der Artikeleinleitung
• Ludwigsfelde: Einige Einzelnachweise sind nun nicht mehr am Artikelende definiert [27]
• Schmuckzypressen: Durch den Revert fehlt ein hinzugefügter Wikilink
• Kuckuckskind: Durch die Reverts fehlen mehrere Änderungen. Die wiederholten Fehler haben zu einem Seitenschutz geführt
• Pferdeantilope: Durch den Revert fehlt ein hinzugefügter Wikilink
• Hallimasche: Durch den Revert fehlt die Formatierung eines Einzelnachweises
• Star Alliance: Durch den Revert fehlt die Aktualisierung der Strukturdaten
• Liebesgräser: Durch den Revert fehlt die Korrektur des Tippfehlers
• Großes Liebesgras: Durch den Revert fehlt die Korrektur des Tippfehlers
• Berg-Ahorn: Durch den Revert fehlen kleine stilistische Änderungen
• Gemeine Esche: Durch den Revert fehlt ein hinzugefügter Wikilink
• Waffen der Wikinger: Durch den Revert fehlt die Korrektur eines Tippfehlers

Vollständig gefixt sind folgende Artikel: Kartoffelkanone, Luzerne, Das Floß der Medusa (Oratorium), Äthiopischer Hochlandhase, Pestalotiopsis microspora, Plaue (Brandenburg an der Havel), Borneodelfin, Burg Kaysersberg, Goldruten, Apokalypse (Dürer), Peder Claussøn Friis, Schotenmuschel, Blaugrüne Segge, Stink-Täubling, Kleine Königslibelle, Gewöhnliche Rosskastanie, Bergpalmen, Katze, Wilde Karde, Heterometrus, Chile

Wenn ihr Fragen habt oder wir anderweitig helfen können (selber in betroffene Artikel eingreifen, würde die Community wohl nicht gerne sehen), lasst es mich wissen! Viele Grüße --Johannes Richter (WMDE) (Diskussion) 13:44, 23. Jul. 2025 (CEST)

Gemeldet in Phabricator
Task T402986

Ich habe ein weiteres Beispiel für einen Verlust von Referenzen durch diese Bearbeitung entdeckt (Meldung bei Phabricator bereits erstellt). @Johannes Richter (WMDE): Für mich liegt nahe, dass dieser Bug eng mit dem vorherigen Bug zusammenhängt.--Kallichore (Diskussion) 00:46, 31. Aug. 2025 (CEST)

Danke für den Ping, wir schauen nach dem Wochenende drauf. --Johannes Richter (WMDE) (Diskussion) 07:52, 31. Aug. 2025 (CEST)

Mir fällt gerade auf, dass wir zwar im Phabricatorticket reagiert hatten, aber hier nochmal fürs Protokoll: Das gemeldete Problem haben wir letzte Woche behoben, es tritt seither nicht mehr auf und betraf wohl zum Glück kaum Artikel, weil es ein eher seltenes Szenario war und schnell erkannt wurde. --Johannes Richter (WMDE) (Diskussion) 13:03, 12. Sep. 2025 (CEST)

Hier ist noch ein Verlust einer Referenz durch den VE. Der Fall entspricht aber nicht T402986, da keine Referenzgruppen verwendet werden. Stattdessen geht eine Referenz verloren, die ausschließlich in einer Infobox verwendet wird.--Kallichore (Diskussion) 08:29, 12. Sep. 2025 (CEST)

Danke für den Hinweis @Kallichore! Ich frage mich, ob das ein Nebeneffekt von phab:T356471#11160318 sein könnte, falls VE (der ja Einzelnachweise in Infoboxen nicht wirklich erkennen kann) davon ausgegangen ist, dass es keinen re-use dieses list-defined Einzelnachweises gab. Wir schauen uns das ebenfalls an und besprechen das ggf. mit den WMF-Kolleg*innen. --Johannes Richter (WMDE) (Diskussion) 08:48, 12. Sep. 2025 (CEST)

Wir schauen noch weiter drauf, aber mein Anfangsverdacht scheint sich zu bestätigen (hier das Problem nochmal mit simplifiziertem Wikitext [28]), weshalb wir vorgeschlagen haben, die Änderung der WMF erstmal rückgängig zu machen phab:T356471#11175215. --Johannes Richter (WMDE) (Diskussion) 09:32, 12. Sep. 2025 (CEST)

Wie angekündigt haben wir die gestern live gegangene Änderung rückgänig gemacht, damit ist das Problem behoben. Die WMF wollte damit eigentlich einen schon länger präsenten Verbesserungswunsch umsetzen, dass man im VisualEditor Einzelnachweise komplett entfernen kann, die im Abschnitt Einzelnachweise definiert sind. Bisher blieben solche Einzelnachweise nämlich bestehen (und haben nach dem Speichern Fehlermeldungen ausgelöst), wenn man via VisualEditor die zugehörige Fußnote entfernt hat. Nun sollte VE automatisch solche Einzelnachweise entfernen, wenn die letzte Nutzung im Artikeltext entfernt wird. Leider hat die Änderung nicht bedacht, dass VE Nutzungen in Vorlagen nicht erkennt. Auch andere Projekte haben den Fehler bemerkt (phab:T404421#11175424), wir sprechen im Nachgang nochmal in Ruhe mit dem WMF Editing Team, wie man den Wunsch ohne den dadurch ausgelösten Fehler umsetzen kann. --Johannes Richter (WMDE) (Diskussion) 13:14, 12. Sep. 2025 (CEST)

Unerwartetes Verhalten von Gallery

Allem Anschein nach funktioniert die Zentrierung einer Gallery (über class=center) nicht richtig, wenn der perrow-Parameter enthalten ist.
Der Sourcetext

<gallery caption="without perrow" class="center">
Example.jpg|Example Image 1
Example.jpg|Example Image 2
</gallery>
<gallery caption="with perrow=2" class="center" perrow="2">
Example.jpg|Example Image 1
Example.jpg|Example Image 2
</gallery>
<gallery caption="with perrow=3" class="center" perrow="3">
Example.jpg|Example Image 1
Example.jpg|Example Image 2
</gallery>
<gallery caption="with perrow=4" class="center" perrow="4">
Example.jpg|Example Image 1
Example.jpg|Example Image 2
</gallery>

wird wie folgt dargestellt:

• without perrow
• 
  Example Image 1
• 
  Example Image 2

• with perrow=2
• 
  Example Image 1
• 
  Example Image 2

• with perrow=3
• 
  Example Image 1
• 
  Example Image 2

• with perrow=4
• 
  Example Image 1
• 
  Example Image 2

Ich vermute, dass dies ein Bug ist. Da ich mit Phabricator bisher noch nie gearbeitet habe, wollte ich zuvor hier nachfragen, bevor ich weitere Aktionen setze (oder mir jemand dabei hilft). --At40mha (Diskussion) 11:11, 25. Aug. 2025 (CEST)

Es gibt bereits einen Hinweis in einer roten Box auf Hilfe:Galerie#Bilder_pro_Reihe_–_Ausrichtung:

• with perrow=2
• 
  Example Image 1
• 
  Example Image 2

@Lómelinde: weiß hier wahrscheinlich mehr Details (Ist das ein Bug, der gemeldet werden sollte?).--Kallichore (Diskussion) 12:43, 25. Aug. 2025 (CEST)

Nein, ich weiß nur, dass ich Galerien noch nie vollkommen verstanden habe, da sie sich (für mich) sehr merkwürdig verhalten. Das oben beschriebene ist aber insofern logisch, dass perrow ja die Breite vorgibt perrow="4" = etwa 4 × 155px = 620px + Zwischenräume und Seitenabstand. Wenn man angibt, die Galerie habe vier Bilder pro Reihe, aber nur 2 Bilder einbinde, dann muss die Software vermutlich raten, was der Einfügende damit bezwecken wollte.

• class und perrow=2
• 
  Bild 1
• 
  Bild 2
• 
  Bild 3
• 
  Bild 4

• style und perrow=2
• 
  Bild 1
• 
  Bild 2
• 
  Bild 3
• 
  Bild 4

Im umgekehrten Fall mit vier (6, 8, 10 …) Bildern und der Anweisung 2 pro Reihe geht das ja korrekt. Die Überschrift caption soll sich ja mittig über den Bildern anordnen, sagt man also ich binde 2 Bilder ein, sie sollen aber wie drei pro Reihe behandelt werden, dann rückt alles weiter in die Mitte, so weit wie es eben für drei Bilder notwendig wäre. Weiterhefen kann ich hier nicht. Den Hinweis hatte ich nur eingefügt, weil mich das Verhalten sehr verwirrte. Es passiert übrigens identisches, wenn man statt class="center" style="text-align:center;" verwendet. Und zudem wurde das ehemalige class="centered" irgendwann mal entfernt, mit dem sich die Galerie vorher class="center centered" perrow="n" zentrieren ließ. --Liebe Grüße, Lómelinde Diskussion 06:52, 26. Aug. 2025 (CEST)

center setzt die Breite der Galerie auf 100% und zentriert den Inhalt. perrow="x" setzt die Breite aber wiederum auf einen kleineren Wert, damit nach x Bildern ein automatischer Umbruch erfolgt. Damit funktioniert die Textausrichtung nicht mehr wie erwartet. -- hgzh 10:06, 29. Aug. 2025 (CEST)

Warum nur noch verkürzte Auflistungen unter Portal:Ägyptologie/Aktuelle Artikeländerungen und hier ?

Seit einigen Tagen werden unter Portal:Ägyptologie/Aktuelle Artikeländerungen und → konfigurierbare Standardliste aller Artikeländerungen nur noch sehr wenige Artikel gelistet. Das verhindert eine umfangreiche Artikelpflege im Nachhinein, wenn ggf. schon einige Tage vergangen sind. Das war früher viel besser! Ich bitte um Wiederherstellung des alten Zustandes. Das selbe Phänomen ist übrigens auch im Portal:Alter Orient feststellbar! Möglicherweise sind davon auch alle anderen Portale betroffen, die eine Seite wie "Aktuelle Artikeländerungen" haben. -- Muck (Diskussion) 13:29, 26. Aug. 2025 (CEST)

Bei Portal:Film und Fernsehen, Portal:Nahost und Portal:Frauen und QS-bezogene Portallisten habe ich ähnliches bemerkt. Ich habe aber noch nicht rausgekriegt, woran das liegen könnte. Habe schon stundenlang erfolglos gesucht letzte Woche und am Wochenende. --Doc Taxon (Diskussion) 13:36, 26. Aug. 2025 (CEST)

(Möglicherweise wurde eine höhere Kategorieseite entweder gelöscht oder ein Zirkelbezug erstellt. In diese Richtung habe ich aber auch bisher ergebnislos geforscht. --Doc Taxon (Diskussion) 13:42, 26. Aug. 2025 (CEST))

(Es sieht so aus, als wenn das am 18/19. August begonnen hat.) --Doc Taxon (Diskussion) 13:49, 26. Aug. 2025 (CEST)

Falls da ein Bot aktiv ist, von Luke081515 habe ich gelesen, dass seit 18. August das Login mit botpasswords umgestellt wurde. Möglicherweise ist da ein Bot oder Tool (nicht mehr) aktiv, der vorher noch aktiv war. Ich detekte in diesem Fall mal weiter, aber mittlerweile bin ich schon ziemlich ratlos. --Doc Taxon (Diskussion) 14:02, 26. Aug. 2025 (CEST)

Moin, siehe dazu WP:NEU#18. August / WP:Projektneuheiten/Tech News#Technische Neuigkeiten: 2025-35, das dürfte an phab:T399455 liegen. Die Änderung betrifft Spezial:Beobachtungsliste, Spezial:Letzte Änderungen und Spezial:Änderungen an verlinkten Seiten. Man kann zwar individuell für sich einen eigenen Standardwert festlegen und somit einen längeren Zeitraum anschauen, wenn man diese Spezialseiten aufruft, aber wenn man solche Spezialseiten wie auf Portal:Ägyptologie/Aktuelle Artikeländerungen einbindet -> {{Spezial:Änderungen an verlinkten Seiten/Portal:Ägyptologie/Artikelliste}} wird nur der Standardwert angezeigt, der nun bei 24h liegt (anstatt 7 Tage wie früher). Hintergrund ist wohl, das die Server mit standardmäßig größeren Zeitspannen Schwierigkeiten haben (individuell größere Zeiträume zu wählen ist aber kein Problem). --Johannes Richter (WMDE) (Diskussion) 14:31, 26. Aug. 2025 (CEST)

Das temporäre Konto aus der Antwort eins drunter hat auch schon den entsprechenden fix gemacht [29]. In der Tat kann man auch die Einbindung erweitern, z.B. {{Spezial:Änderungen an verlinkten Seiten/Portal:Ägyptologie/Artikelliste|days=7|limit=100}}. Standard sind 50 Beiträge und seit letzter Woche wie gesagt 1 Tag. --Johannes Richter (WMDE) (Diskussion) 14:50, 26. Aug. 2025 (CEST)

Wikipedia:Projektneuheiten#18._August. Es ist standardmäßig ein Tag nun, der angezeigt wird. --~2025-46308-9 (Diskussion) 14:31, 26. Aug. 2025 (CEST)

OK, auf Portal:Ägyptologie/Aktuelle Artikeländerungen ist mit diesem Edit wieder alles ok, Danke!

Aber leider unter "→ konfigurierbare Standardliste aller Artikeländerungen" hier noch immer nicht. Meine Kenntnisse reichen leider für eine Korrektur nicht aus (habe es vergeblich versucht :-( , um auch dort wieder mindestens 7 Tage angezeigt zu bekommen. Ich bitte daher auch dafür um eure Hilfe! Danke im Voraus. -- Muck (Diskussion) 16:40, 26. Aug. 2025 (CEST)

Die Seite bearbeiten und dort http://de.wikipedia.org/w/index.php?title=Spezial:Recentchangeslinked&target=Portal%3A%C3%84gyptologie%2FArtikelliste durch https://de.wikipedia.org/w/index.php?title=Spezial:Recentchangeslinked&target=Portal%3A%C3%84gyptologie%2FArtikelliste&days=7 ersetzen – oder anders formuliert: an die bestehende URL &days=7 anhängen, dabei die Gelegenheit nutzen, aus dem veralteten http besser https zu machen. --Johannes Richter (WMDE) (Diskussion) 16:56, 26. Aug. 2025 (CEST)

Vielen Dank, habe es wie angegeben geändert und nun ist wieder alles im Lot :-) -- Muck (Diskussion) 17:18, 26. Aug. 2025 (CEST)

Event-Erweiterung

Servus, zu CampaignEvents: Unter Hilfe:Namensräume ist der neue Namensraum schon erwähnt, der dazugehörige Diskussions-Namensraum ist allerdings vom üblichen Schema abweichend Event talk statt Event Diskussion. Das gilt wohl auch für TimedText, ist allerdings falsch dokumentiert, denke ich. Könnte jemand die Tabelle oben sowie weiter unten Hilfe:Namensräume#Weitere Details dann entsprechend anpassen? Zudem wäre eine deWP-Hilfeseite wohl nicht schlecht … Danke schonmal und VG –IWL04 • 05:02, 2. Sep. 2025 (CEST)

App auf dem Android

Liebe Wikipedianer*innen,

ich hatte das Problem, aus einem Artikel in der App auf meinen Browser (Firefox) zu geraten. Es hat nur selten funktioniert. Mir wurde geraten, die App neu zu installieren.

Nun aber bin ich auf dem Handy nicht mehr eingeloggt, und meine wertvollen Veränd/Verbesserungen werden mir nicht mehr zugeschrieben. Den Browser zu erreichen ist auch nicht einfacher geworden.

Kann mir (technisch leider unbegabter Frau) jemand auf einfache Weise erklären, wie ich das Dilemma löse? Vielen Dank --Stephphie (Diskussion) 16:09, 4. Sep. 2025 (CEST)

"Alle Koordinaten" in der katalanischen Wikipedia

Als Beispiel: Hier ist das spanische Äquivalent zu {{All Coordinates}} eingebunden, ca:Plantilla:Mapa llista coordenades. Es wird anscheinend auch die richtige Seite aufgerufen, https://osm4wiki.toolforge.org/cgi-bin/wiki/wiki-osm.pl?project=ca&article=Llista_de_monuments_de_Sant_Lloren%25C3%25A7_des_Cardassar, aber dort tut sich nichts. Wo könnte das Problem sein? Kann osm4wiki die Koordinaten aus den Denkmallisten nicht richtig interpretieren? Bei ca:Llista d'illes de les Tuamotu bspw. klappt es, dort werden aber die Koordinaten direkt eingebunden. --Magnus (Diskussion) 16:01, 5. Sep. 2025 (CEST)

@DB111, @Kolossos, @Plenz: Vielleicht könnt ihr Maintainer von osm4wiki hier weiterhelfen? --Count Count (Diskussion) 16:15, 5. Sep. 2025 (CEST)

Hallo, es liegt daran, dass in den Beschreibungen der Koordinaten "mw-content-text" vorkommt, solche Einträge ignoriert @Plenz. Er schaut sich das sicher mal an. Übrigens URL-kodiert die Vorlage doppelt, man sollte aus den FULLPAGENAMEEs mal FULLPAGENAMEs machen. --DB111 (Diskussion) 12:18, 6. Sep. 2025 (CEST)

P.S.: WikiMap könnte man dort natürlich auch mit einbinden. --DB111 (Diskussion) 12:22, 6. Sep. 2025 (CEST)

Hab ich getan. --DB111 (Diskussion) 14:38, 9. Okt. 2025 (CEST)

Ich werde mir das mal anschauen. Aber schon mal eins vorab: der Link "Lenz" hat da nichts zu suchen! Siehe Diskussion zum Baustein. --Plenz (Diskussion) 15:10, 9. Sep. 2025 (CEST)

Fixierter Tabellenkopf verdeckt Rücksprungziel

Hallo, beim Rücksprung aus den ENs in den Tabellentext wird die angesprungene Zeile vom fixierten Tabellenkopf verdeckt. Bsp.: Reformationsstadt Europas. Zu sehen ist dann meist die folgende Zeile mit der nächsthöheren EN-Nummer. Gruß, --Wi-luc-ky (Diskussion) 23:00, 5. Sep. 2025 (CEST)

Das kommt daher, dass der Rücksprung über eine id="XY" (das Sprungziel, das ist oben in der Tabelle) und einen HTML-Verweis href="#XY" (unten neben dem Pfeil in der Liste der Nachweise) geregelt wird. Wird der Verweis angeklickt, scrollt der Browser immer so, dass das Sprungziel am oberen Rand des sichtbaren Bereichs ist. Beim Verweis [1] auf der Seite klappt das, das ist im Fließtext. Wenn sich aber das Rücksprungziel in einer Tabelle mit fixiertem Kopf befindet, klappt das zwar theoretisch auch, aber der Browser ignoriert, dass der Tabellenkopf ein fixiertes Element ist, also nicht dem normalen Scrolling unterliegt.

Technisch wäre das sehr schwer lösbar:

1. Entweder man könnte es irgendwie erreichen, dass nach dem Erreichen des Ziels automatisch wieder ein Stückchen gescrollt wird, so dass das Ziel dann unterhalb der Fixierung sichtbar wird
2. Oder es gäbe eine Möglichkeit, dass beim Sprungvorgang die Fixierung aufgehoben wird, bis der Benutzer wieder weiterscrollt.

Was davon mit HTML-Mitteln oder Javascript möglich wäre, kann ich schlecht abschätzen. --Hlambert63 (Diskussion) 14:02, 6. Sep. 2025 (CEST)

Edit: Offensichtlich geht 1. durch einen CSS-Trick: Dem Ziel-Element muss eine CSS-Property scroll-margin-top: verpasst werden, z.B. 100px. Dann scrollt der Browser noch 100 Pixel nach oben, also das Sprungziel verschiebt sich nach unten. Ich muss zwar gestehen, der Trick kommt von Googles KI-Kopf, hab es aber in den Dev-Tools geschafft, dem Sprungziel die Eigenschaft zu verpassen, und das hat geklappt.--Hlambert63 (Diskussion) 14:39, 6. Sep. 2025 (CEST)

Edit 2: Bevor global da eine Lösung in Abhängigkeit von fixierten Tabellen erdacht wird, kann das auch jeder registrierte User über das benutzereigene CSS hinbekommen: Die Definition findet sich unter "Einstellungen" --> "Aussehen" --> benutzerdefiniertes CSS.

Das hab ich editiert und dort eingetragen

sup.reference { scroll-margin-top: 100px; }

(ohne das Code-HTML hier im Wiki-Quelltext!) Das gilt aber dann für alle Rücksprünge, auch bei EN im Fließtext. Ist aber IMHO gar nicht so schlecht, dann kann man auch mehr vom durch den EN belegten Text / Satz / Absatz lesen als vielleicht nur den letzten Rattenschwanz.--Hlambert63 (Diskussion) 15:24, 6. Sep. 2025 (CEST)

Danke, Hlambert63, für die Lösungsvorschläge.

ad 1.: Wenn das hieße, jeder Referenz müsste eine CSS-Property beigefügt werden, wäre das aufwändig.

ad 2.: Benutzereigene CSS-Anpassung ist eine private Lösung, nichts für die Allgemeinheit oder die gewöhnliche Leserschaft.

Scheint mir noch nicht WP:OMA-tauglich.

Dennoch erstmal dankend. Gruß, --Wi-luc-ky (Diskussion) 22:26, 6. Sep. 2025 (CEST)

DISPLAYTITLE:SEITENTITEL

In den letzten Tagen sind gehäuft Bearbeitungen von verschiedenen angemeldeten und nicht angemeldeten Benutzern aufgefallen, bei denen eine jeweils Änderung in einem anderen Abschnitt getätigt worden ist und gleichzeitig – vermutlich unabsichtlich – das korrekte {{SEITENTITEL:…}} zum fehlerhaften {{DISPLAYTITLE:SEITENTITEL:…}} geändert worden ist: Spezial:Diff/259857935, Spezial:Diff/259867035, Spezial:Diff/259900198, Spezial:Diff/259928519, Spezial:Diff/259945986, Spezial:Diff/259956868, Spezial:Diff/259959321, Spezial:Diff/259966895, Spezial:Diff/259967503, Spezial:Diff/259967738. Woran könnte das liegen? --Der König (Disk.·Beiträge) 21:48, 23. Sep. 2025 (CEST)

phab:T402322, sollte inzwischen eigentlich behoben sein. Am besten dort melden, wenn es dir weiterhin unterkommt. --Johannnes89 (Diskussion) 21:56, 23. Sep. 2025 (CEST)

Die verlinkten Änderungen sind alle – teilweise Tage später – passiert, nachdem der Task schon Resolved war, der letzte gestern. --Der König (Disk.·Beiträge) 22:02, 23. Sep. 2025 (CEST)

Außerdem verstehe ich die Beschreibung so, dass das ein anderer Bug war. --Der König (Disk.·Beiträge) 22:08, 23. Sep. 2025 (CEST)

Oh ja stimmt, hatte den Bug nur kurz überflogen, als er in TechNews erwähnt war. Aber vielleicht ist ein Resultat der Lösung dieses bugs nun der von dir beobachtete Fehler, der ja erneut VE betrifft? --Johannnes89 (Diskussion) 22:19, 23. Sep. 2025 (CEST)

Möglich. Ich habe phab:T405408 erföffnet, mit Verweis auf den anderen Bug. --Der König (Disk.·Beiträge) 22:43, 23. Sep. 2025 (CEST)

Ich konnte es repoduzieren: Das passiert automatisch, wenn ich im Visual Editor eine Seite bearbeite, die {{SEITENTITEL:…}} beinhaltet. --Der König (Disk.·Beiträge) 22:12, 23. Sep. 2025 (CEST)

Die zum Ausführen von Skripten vorgesehene Zeit ist abgelaufen

Hallo zusammen

Bei der Tabelle Liste der Gemeinden in der Provinz Barcelona wird ab einer gewissen Zeile der Fehler: Die zum Ausführen von Skripten vorgesehene Zeit ist abgelaufen angezeigt. Je nach Tageszeit kommt der Fehler einmal früher und dann wieder erst später oder ganz selten gar nicht. Wird zum Beispiel die Version Version vom 24. September 2025 um 18:11 aufgerufen, dann erscheint kein Fehler obwohl sie identisch mit der aktuellen Version ist. Hat jemand von Euch eine Idee, wieso der Fehler bei der aktuellen Version erscheint, bei der identischen vom 24. September aber nicht? Gruss --Tschubby (Diskussion) 10:28, 25. Sep. 2025 (CEST)

Also bei mir sehe ich die Fehler in beiden Versionen und zudem steht die Seite auch in der Kategorie:Wikipedia:Seite mit Skriptfehlern, da wird also entweder etwas falsch ausgefüllt oder verschachtelt sein, oder es werden zu viele Vorlagen eingebunden, die zu viel Zeit verbrauchen. Es wird jedenfalls eine Grenze von 10,000 Sekunden überschritten. --Liebe Grüße, Lómelinde Diskussion 17:01, 25. Sep. 2025 (CEST)

Bei mir erscheint in der Spalte Dichte noch die rote Fehlermeldung: Fehler im Ausdruck: Unerkanntes Wort „strong“. Gruß, --Wi-luc-ky (Diskussion) 18:39, 25. Sep. 2025 (CEST)

Ich sehe den Fehler auch in alten Versionen. Die Lua-Aufrufe sind zu umfangreich, letztendlich führt kein Weg daran vorbei, den Artikel aufzuteilen. -- hgzh 21:28, 25. Sep. 2025 (CEST)

An der Menge der Einträge kann es nicht liegen. Der Artikel Liste der Gemeinden in der Provinz Burgos hat 60 Gemeinden mehr, ist exakt gleich aufgebaut und dort klappt die Anzeige tadellos. Sehr lange hat die Darstellung auch bei Barcelona geklappt. Kann es sein, dass die Grenze in letzter Zeit auf 10,000 Sekunden runtergesetzt wurde und früher höher war? Gruss --Tschubby (Diskussion) 08:40, 26. Sep. 2025 (CEST)

Es muss nicht an der Anzahl der Aufrufe im Artikel liegen, es geht um zeitkritische Aufrufe. Ein sehr großes Wikidata-Datenobjekt wie d:Q1492 für Barcelona abzufragen, dauert länger. Deshalb kann der Fehler auch auftreten, obwohl sich hier in der Wikipedia nichts geändert hat. Es genügt, dass sich Daten auf Wikidata ändern. -- hgzh 09:01, 26. Sep. 2025 (CEST)

Sali Hgzh, ja an Wikidata habe ich nicht gedacht. Das kann nachtürlich gut sein, dass es in Barcelona sehr viel mehr gut ausgebaute Wikidata Artikel gibt als in Burgos. So würde sich das unterschiedliche Verhalten erklären. --Tschubby (Diskussion) 13:47, 26. Sep. 2025 (CEST)

Die Seite steht zusätzlich auch noch in dieser Kategorie:Wikipedia:Seite mit nicht-numerischem formatnum-Argument, das sieht nach irgendeinem Fehler aus, der möglicherweise aus Wikidata (Wikipedia:Seite verwendet P1082) importiert wird. Die andere Seite steht nicht in dieser Kategorie. --Liebe Grüße, Lómelinde Diskussion 09:09, 26. Sep. 2025 (CEST)

Danke für den Hinweis. Habe alle formatnum Fehler die von mir kommen, behoben. Gruss --Tschubby (Diskussion) 13:47, 26. Sep. 2025 (CEST)

Das liegt schlicht daran, dass die Fehlermeldung in die formatnum-Parserfunktion eingespeist wird. Verschwindet die Fehlermeldung, erledigt sich auch das formatnum-Problem -- hgzh 09:23, 26. Sep. 2025 (CEST)

Die Seite ist in in 4 versteckten Kategorien gelistet:

• Kategorie:Wikipedia:Seite verwendet P1082
• Kategorie:Wikipedia:Vorlagenfehler/Parameter:Datum
• Kategorie:Wikipedia:Seite mit Skriptfehlern
• Kategorie:Wikipedia:Seite mit nicht-numerischem formatnum-Argument

Gruß, --Wi-luc-ky (Diskussion) 11:22, 27. Sep. 2025 (CEST)

Also an Wikidata kann es nicht liegen. Hatte kurzfristig die Einwohnerzahl von Wikidata auf Metadaten umgestellt. Auch da kommt der Laufzeitfehler. Interessant ist auch, dass der Gemeindename trotz Laufzeitfehler bis ans Ende der Tabelle angezeigt wird. Dieser wird aber auch über Metadaten ausgelesen. Logisch wäre doch, dass wenn der Laufzeitfehler auftaucht, dass alle Daten ab diesem Zeitpunkt nicht mehr dargestellt oder gelesen werden können. Dies scheint aber nicht der Fall zu sein. Gruss --Tschubby (Diskussion) 12:49, 27. Sep. 2025 (CEST)

Popup „Links auf Seiten in anderen Sprachen hinzufügen“

Wieso unterscheidet sich das Design im Popup-Fenster „Links auf Seiten in anderen Sprachen hinzufügen“ (unter Werkzeuge; nur sichtbar, wenn noch keine andere Sprache angegeben ist, zB Vorlage:Navigationsleiste Apache 207) so sehr von Vector 2022 (aber auch Vector 2010)? Sollte das nicht mal glattgezogen werden? –IWL04 • 02:41, 27. Sep. 2025 (CEST)

Unterscheidet sich inwiefern? Sieht mE recht normal aus. -- hgzh 07:40, 6. Nov. 2025 (CET)

Naja, das graue Interface von da kenne ich sonst nicht und wirkt mehr nach Monobook, auch die Buttons unterscheiden sich optisch von der Darstellung in Vorlage:MediaWiki-Button etc. Wenn das nicht weiterhilft, kann ich auch gerne einen Screenshot erstellen. VG –IWL04 • 05:21, 7. Nov. 2025 (CET)

Jetzt habe ich erst gelesen, dass du dich auf das Popup beziehst, ich hatte an den Link gedacht. Das ist phab:T226976. Gruß, -- hgzh 07:39, 7. Nov. 2025 (CET)

Über sechs Jahre offen, naja … danke für die Info! VG –IWL04 • 01:20, 8. Nov. 2025 (CET)

Help test the new Tone Check tool

Gemeldet in Phabricator
Task T403102

We apologize that this message is in English, help us and translate it! Thank you.

The Wikimedia Foundation’s Editing team is looking for experienced editors to help test a new tool called Tone Check. This tool helps editors find and fix promotional or subjective language in articles, to help make sure Wikipedia keeps its neutral point of view.

What is the test?

You will be asked to review at least 30 edits in your language using a special tool called Annotool. You can review more if you wish. Your job is to see if you agree with the Tone Check tool's suggestions. The link for your language is:

https://annotool.toolforge.org/projects/19

Why should you help?

Our goal is to make your work easier. Your feedback will make the Tone Check tool smarter and more helpful for new editors. This will improve Wikipedia's quality and reduce cleanup work for experienced editors like you.

The test starts on October 3, 2025, and we need your reviews by October 10, 2025.

If you would like to help, please add your username on the on sign-up page.

Thank you for your help! --Dyolf77 (WMF) (Diskussion) 20:06, 1. Okt. 2025 (CEST)

ggu.toolforge.org wieder aktivieren

Hallo, wie kann man erreichen, dass ggu.toolforge.org wieder funktioniert bzw. wo muss man melden, dass es nicht aktiv ist? Vgl. WP:Technik/Cloud/ggu. Anscheinend nutzen das laut global-search.toolforge.org außer mir nur noch Benutzer:WikiBayer auf mehreren Wikis und Benutzer:PerfektesChaos über seine global.js (bzw. dort wird der Host abgefragt), so dass der allgemeine Leidensdruck nicht sehr hoch ist. — Speravir – 02:30, 6. Okt. 2025 (CEST)

Hmm, keine Antwort, obwohl mich wirklich interessiert, wohin ich mich wenden könnte. Andererseits hat es zwar über 24 Stunden gedauert, aber seit irgendwann gestern geht es wieder. — Speravir – 01:40, 8. Okt. 2025 (CEST)

Die Maintainer des Tools sind Benutzerin:Giftpflanze, Benutzer:Platonides und Benutzer:Tim.landscheidt (siehe hier). --Tkarcher (Diskussion) 10:10, 8. Okt. 2025 (CEST)

@Speravir Tool is sehr veraltet das Tool generiert alles aus Datenbank abfragen und ist deshalb auch langsam. Außerdem lädst du das Tool im dewiki sogar zweimal (Benutzer und Benutzerin). Ich habe mir das Problem mal angenommen und lasse dir es mal im barwiki testen ich war mal so frei bar:Nutza:Speravir/common.css --ᵂᶦᵏᶦᴮᵃʸᵉʳ 👤💬 _{Skripte ︱ Rechte ︱ GitLab} 19:08, 8. Okt. 2025 (CEST)

Danke, Tkarcher, auf der Seite war ich sogar. Aber die Benutzer sind alle nicht aktiv – dachte ich, merke allerdings nun, dass das für Platonides nicht zutrifft. Auch dir danke, WikiBayer. Wäre es dir möglich, direkt unter https://markusergroups.toolforge.org/ und/oder unter [[Wikipedia:Technik/Cloud/markusergroups]] (Nachtrag: inzwischen eine WL die WP:Technik-Seite für das Tool) eine kurze Anleitung anzulegen nach dem Vorbild von WP:Technik/Cloud/ggu? — Speravir – 01:04, 9. Okt. 2025 (CEST)

Meinst du soetwas [[Wikipedia:Technik/Cloud/MarkUserGroups]] --ᵂᶦᵏᶦᴮᵃʸᵉʳ 👤💬 _{Skripte ︱ Rechte ︱ GitLab} 01:07, 9. Okt. 2025 (CEST)

Oha! Ja, WikiBayer. Wird auf die Problematik Benutzer/Benutzerin geachtet? Die geschlechterabhängige Lokalisierung gibt es doch bestimmt auch in anderen Wikis (Frankreich?). — Speravir – 01:27, 9. Okt. 2025 (CEST)

geht einfach in dem du alle Lokalen Benutzerlabels eingibst die erkannt werden sollten. Z.B. localuser=User,Benutzer,Benutzerin, --ᵂᶦᵏᶦᴮᵃʸᵉʳ 👤💬 _{Skripte ︱ Rechte ︱ GitLab} 08:42, 9. Okt. 2025 (CEST)

Zur Info; Ich arbeite auch an Spezialfällen wie Schiedsgericht und Ex-Admin ähnlich wie beim dewiki. Hier muss ich die daten aber händisch zusammen stellen, das geht nicht mit Skript. --ᵂᶦᵏᶦᴮᵃʸᵉʳ 👤💬 _{Skripte ︱ Rechte ︱ GitLab} 10:30, 9. Okt. 2025 (CEST)

@WikiBayer, zu „geht einfach in dem du alle Lokalen Benutzerlabels eingibst“: Ach, danke, steht ja auch so in der Anleitung (Wer lesen kann ist … etc.). — Speravir – 23:58, 9. Okt. 2025 (CEST)

@ Wikipedia:Technik/Cloud/markusergroups – der Unter-Seitenname ist immer und überall exakt die Tool-ID.

• Siehe im Übrigen WD:HT/ggu.

VG --PerfektesChaos 14:06, 9. Okt. 2025 (CEST)

Bearbeitung nicht möglich

Trotz Anmeldung kann ich weder von mir erstellte Artikel, noch Artikel, zu denen ich einen Beitrag geleistet habe, bearbeiten. Was kann die Ursache sein und wie kann ich es ändern? --lutki (Diskussion) 11:28, 12. Okt. 2025 (CEST)

Nachdem die Bearbeitung auf dieser Seite hier geklappt hat, scheint es jedenfalls kein grundsätzliches Problem mit Browser oder Proxy zu sein. An welchem Schritt scheitert es denn genau, und gibt es irgendeine Fehlermeldung? --Tkarcher (Diskussion) 19:36, 14. Okt. 2025 (CEST)

Kommentar am Abschnittsende führt zu leeren Zeilen

In einem Artikel war ein Kommentar am Ende eines Abschnitts. Das hatte dazu geführt, dass ständig eine neue, leere Zeile in der Leseansicht entstand. Letztlich habe ich den Kommentar entfernt, um weitere Störungen zu vermeiden, aber das Softwareproblem ist geblieben und Quelltextkommentare dürfen doch auch am Abschnittsende stehen ohne Fehler zu verursachen.

Links:

• Spezial:Versionsgeschichte/Nela Riehl (August–September 2025)
• BD:Ulanwp/Archiv/2025#Hinweise zum Bearbeitungskommentar bei Nela Riehl

--Fan-vom-Wiki (Diskussion) 13:35, 24. Okt. 2025 (CEST)

Kleinigkeit in der mobilen Ansicht

Wenn man in der mobilen Ansicht (egal welcher Artikel) ganz ans Ende der Seite geht, dann steht da diese Zeile mit "… • Nutzungsbedingungen • Klassische Ansicht •". Der Knubbel ganz am Ende gehört raus, der ist unnötig. --Wurgl (Diskussion) 10:57, 27. Okt. 2025 (CET)

@Wurgl in welchem Browser siehst du das? Ich kann's in Safari und Chrome auf dem iPhone nicht reproduzieren, bei mir ist da kein extra Knubbel. --Johannnes89 (Diskussion) 08:09, 1. Nov. 2025 (CET)

Firefox 142.0.1 (aarch64) das ist am Raspberry und Firefox 140.3.0esr auf Suse Linux --Wurgl (Diskussion) 08:56, 1. Nov. 2025 (CET)

Chromium Version 141.0.7390.107 (Offizieller Build) built on Debian GNU/Linux 12 (bookworm) (64-Bit) auf dem Raspberry ebenso --Wurgl (Diskussion) 08:58, 1. Nov. 2025 (CET)

Interessant am Laptop (MacOS) die Mobilversion aufgemacht, kann ich das Problem auch reproduzieren, nur am Handy irgendwie nicht. --Johannnes89 (Diskussion) 10:11, 1. Nov. 2025 (CET)

Ist ja nix weltbewegendes und kann genauso gut ein Bug im Browser sein. Hat irgendwas mit diesen Pseudoelementen ::after zu tun. --Wurgl (Diskussion) 15:11, 1. Nov. 2025 (CET)

Ich hänge das mal hier mit an

Die Liste der Versionen sieht unschön aus, wenn größere Mengen verändert wurden.

• gemeint ist hier der klick auf Mobile Ansicht
• hängt man hingegen ein useskin=minerva an, sieht das Ganze wiederum anders aus, die Liste ist dann anders aufgebaut.

Das Problem ist, dass die Bytezahl beispielsweise -19.248 dann die nachfolgende Zusammenfassung um etwa 1em überschneidet. Wäre die Zahl noch größer +101.248, wäre natürlich auch die Überschneidung größer. Die Überschneidung beginnt ab den Tausendern. --Liebe Grüße, Lómelinde Diskussion 11:54, 3. Nov. 2025 (CET)

Darstellung von Positionskarten

Auf der Nordfriesischen Wikipedia gibt es offenbar Probleme mit der Darstellung von Positionskarten in verschiedenen Browsern, siehe die Anfrage auf meiner dortigen Diskussionsseite: frr:Benutzer Diskussion:Holder#Darstellung von Positionskarte. Kennt jemand das Problem und weiß eine Lösung? LG --Holder (Diskussion) 09:40, 29. Okt. 2025 (CET)

Veranstalter vs. Veranstaltungsorganisator

Nach der Archivierung der ersten Diskussion unter Benutzer Diskussion:Raymond/Archiv 2025-1#Veranstalter vs. Veranstaltungsorganisator nun hier. Es geht nur noch um die fehlerhafte Angabe in MediaWiki:Group-event-organizer: statt Veranstalter wäre richtig Veranstaltungsorganisator. @Raymond: zK. VG –IWL04 • 03:56, 18. Nov. 2025 (CET)

Ist es ein Bug, dass die 404-Fehlerseiten auf de.wikipedia.org englischsprachig sind?

Gemeldet in Phabricator
Task T14302

Geht man z.B. auf https://de.wikipedia.org/Fuchs , bekommt man

= Page not found =

/Fuchs

We could not find the above page on our servers.

Did you mean: /wiki/Fuchs

Alternatively, you can visit the Main Page or read more information about this type of error.

Jetzt ist das aber auf de.wikipedia.org und sollte vermutlich mindestens zweisprachig, aber auf jeden Fall auf Deutsch lesbar sein, oder? --MüllerMarcus (Diskussion) 16:02, 22. Nov. 2025 (CET)

Wie das Dingens schon sagt, hast du das /wiki vergessen.

Inhaltliche Seiten sind in der Domain de.wikipedia.org/wiki für direkte Seitennamen, oder de.wikipedia.org/w – was komplexe Zusammenstellungen meint. Oder nur de.wikipedia.org/ – ergibt eine Weiterleitung auf WP:HS.

Weil du aber weder nach /wiki noch /w gefragt hast, bist du auf Ebene der globalen Serverprogrammierung gelandet. Und der ist ein /Fuchs unbekannt. Darauf antwortet der globale Server in globaler Sprache. Absicht.

Wenn du nach https://de.wikipedia.org/wiki/MüllerMarcus fragst, bekommst du eine deutschsprachige Antwort, die aber kein 404 ist.

Mehr unter: H:URL-P

VG --PerfektesChaos 16:23, 22. Nov. 2025 (CET)

Sorry, mir ist klar weshalb ich die Fehlermeldung kriege. Das war aber auch keineswegs die Frage.

Die Frage war, ob es ein Bug ist, dass eine Fehlermeldung auf der deutschsprachigen de. subdomain Englisch ist, und da hast du nur gesagt:

Darauf antwortet der globale Server in globaler Sprache.

Absicht.

Drei Dinge:

1. "Der globale Server" (im Ggs zur deutschsprachigen Wikipedia): das ist nicht wirklich wie die wikimedia-Server funktionieren, sorry. Egal welche wikipedia.org-Seite ich anfrage, das wird vermutlich primär mal vom Edge-Server in Amsterdam bearbeitet, um dann gegebenfalls von einem App-Server in Virginia oder Texas beantwortet zu werden. (Eine interessante Frage wäre, ob die 404 page von einem cache (Varnish? ATS?) oder vom App-Server kommt.)
2. "globaler Sprache": Du wirst feststellen, dass das unter Menschen nicht existiert. Während mein Englisch doch recht OK ist, ist es zu erwarten, dass wer immer eine mit de.wikipedia.org beginnende URL aufruft deutschsprachige Texte erwartet (weil er/sie nicht notwendigerweise des Englischen mächtig sind).
3. "Absicht": {{citation needed}} Deswegen frag' ich ja. Für mich sieht das wie ein Bug aus: der de. virtual host ist immer noch da, die Fehlermeldung sollte die Infra dementsprechend lokalisiert ausliefern, so weit ich das beurteilen kann. Inwiefern ist das Absicht, dass sie das nicht tut?

--MüllerMarcus (Diskussion) 16:48, 22. Nov. 2025 (CET)

Zu diesem Thema wurde schon 2007 ein Ticket auf Phabricator angelegt. Für das Alter von über 17 Jahren ist die Diskussion dort nicht sonderlich lang.--Kallichore (Diskussion) 17:05, 22. Nov. 2025 (CET)

Das ist noch keine Angelegenheit innerhalb der deutschsprachigen Wikipedia, weil du zu der noch überhaupt nicht vorgedrungen warst.

• Anders als es dir scheinen mag.
• Erst wenn du mit der deutschsprachigen Wikipedia kommunizierst, gibt es auch lokalisierte Meldungen.

Du warst noch bei der WMF und ihren Serverfarmen, und die Serverfarm konnte mit der ungültigen URL nichts anfangen, und kennt nur eine einzige Sprache.

• Domains der WMF usw.
• Die Serverfarm und ihre Aufgabenverteilung weiß nichts von bevorzugten Sprachen, und will sich aus Performancegründen auch nicht darum kümmern. Sie hat an den Burgtoren eine ungültige Anfrage erhalten, die zu keiner konfigurierten Aufgabe führt, und was das für ein Projekt wäre und wie dessen Lieblingssprache sein könnte, interessiert sie nicht. Standard-Antwort, Zugbrücke runter.
• Das Ticket von 2007 ist aus einem anderen Zeitalter; die damaligen Server, -Standorte, -Kontinente, Betriebssysteme gibt es längst nicht mehr.

VG --PerfektesChaos 17:38, 22. Nov. 2025 (CET)

Der Browser schickt bei der Anfrage sowas mit: "Accept-Language=de,en-US;q=0.7,en;q=0.3" Das kann der Server auswerten und in der entsprechenden Sprache antworten. Der PATH-Anteil oder HOST-Anteil der URL ist wumpe. --Wurgl (Diskussion) 17:58, 22. Nov. 2025 (CET)

Liebe/r PerfektesChaos,

Das ist noch keine Angelegenheit innerhalb der deutschsprachigen Wikipedia, weil du zu der noch überhaupt nicht vorgedrungen warst.

Nie behauptet. Ich weiß, ich werde hier repetitiv, aber: de.wikipedia.org/whatever sagt der User will Deutsch, egal ob da ein Mediawiki oder Fred, der ganz schnell tippen kann und viele Sprachen spricht und am Varnish sitzt, die 404 response zurückliefert.

Hör mal bitte auf die Frage "sollte ein User auf de.wikipedia.org eine deutsche oder Englische Fehlermeldung bekommen" mit technischen Details zu beantworten. Es ist eine Frage über das, was Menschen wollen, dass das System tut, und nicht was die Technik heute implementiert. Kategoriefehler, das mit "aber da antwortet (was auch immer)" abwürgen zu wollen. --MüllerMarcus (Diskussion) 18:16, 22. Nov. 2025 (CET)

Ah das beantwortet meine Frage positiv: Ja, das ist ein Bug und wird nach wie vor als solcher betrachtet. Er ist aber schon bekannt, und ich muss nicht rausfinden, wo ich den sonst reporten könnte; danke, @Kallichore! --MüllerMarcus (Diskussion) 18:17, 22. Nov. 2025 (CET)

Es ist ein Performance- und Sicherheitsproblem, und deshalb volle Absicht, und da wird deswegen auch niemand drangehn, und somit auch kein „Bug“.

• @ „Egal welche wikipedia.org-Seite ich anfrage, das wird vermutlich primär mal vom Edge-Server in Amsterdam bearbeitet“
  • Ja, wenn du aus Europa anfragst, dann schalten die hiesigen DNS nach Amsterdam/Haarlem.
  • Genauso in Südamerika, Asien, geplant oder verworfen: Nordafrika, und natürlich USA.
  • Alle europäischen Anfragen landen letztlich bei einem Server.
    • Auf den prasseln eine oder zehn Millionen Anfragen pro Sekunde ein.
    • Dieser Zahlenwert nur als Größenordnung; die aktuellen Daten habe ich keinen Nerv herauszufummeln. Dies oder so ähnlich gab es durchaus mal bei Wiki-Serverfarmen.
  • Dieses Frontend hat nur die eine Aufgabe, die einzelne Abfrage auf den für de.wikipedia.org/wiki oder de.wikipedia.org/w/index.php usw. zuständigen Cluster-Server weiterzuschieben; so schnell wie irgend möglich.
  • Dieses Frontend ist es auch, das die von dir beanstandete Meldung generiert, wenn nichts für diese Anfrage konfiguriert ist. Also die 403 und 404 usw.
  • Außerdem schreibt der an dieser Stelle womöglich schon die Log-Datei; vielleicht auch später jemand anders.
  • Im Cluster, vielleicht eins für die enWP und eins für die deWP mit einigen Wikipedien, und wieder andere für viele kleinere Wikis, hat der Lastverteilungs-Server eine Warteschlange für seine Anfragen.
  • Im Cluster stehen vielleicht 50 oder 100 oder was physische Maschinen herum, die die nächste Anfrage abarbeiten, die ihnen von der Lastverteilung zugewiesen wird.
  • Die einzelne Anfrage kann mal einfacher, mal komplizierter sein: Der Wikitext liegt ggf. schon umgewandelt im Cache vor, oder muss frisch vom Parser generiert werden. Der Nutzinhalt muss mit dem Portal zusammengeführt werden, also der Skin, und bei angemeldeten Konten entsprechend der persönlichen Einstellungen mit diesem und jenem Zeugs abgewandelt. Bei Suchanfragen oder während der Wikitext-Bearbeitung ist das Ergebnis äußerst individuell.
  • Das sind die Server, die wirklich die deWP und deren Inhalte kennen würden.
• @ „gegebenfalls von einem App-Server in Virginia oder Texas beantwortet zu werden“
  • Alle reinen Lese-Anfragen werden nur von der lokalen Serverfarm für Europa, Asien, Südamerika oder USA/Nordamerika beantwortet.
  • Nur die verändernden Aktionen werden an das diensthabende der beiden Master-Rechenzentren in den USA weitergeleitet. Dieses speichert sie und kommuniziert Replicate an die lokalen Serverfarmen in Europa, Asien, Südamerika usw.
  • Die globalen Frontends sind alle gleich, egal ob Amsterdam oder Brasilien.
• Die 403/404 kommt von einer hochbelasteten Instanz, die keine Zeit für Rumgefummel hat, sondern in Mikrosekunden die abschnittseröffnende Antwort generieren und zurückschicken muss, und danach ist der Fall erledigt. Die Antwort ist bereits hinreichend komfortabel, aber für sämtliche normalen Wikis letztlich immer die gleiche und nur minimal angepasst.
• Diese Instanz muss sich mit DDOS und sonstigen Angriffen, mit bösartigen staatlichen Akteuren herumschlagen. Im Falle einer ungültigen selbst gebastelten Anfrage gibt es eine möglichst schnelle Antwort und fertig. Alle von uns kommunizierten URL sind gültig.

VG --PerfektesChaos 23:12, 22. Nov. 2025 (CET)

Es ist ein Performance- und Sicherheitsproblem, und deshalb volle Absicht, und da wird deswegen auch niemand drangehn, und somit auch kein „Bug“.

Das ist nicht was "Bug" bedeutet, sorry. Aber da es einen Bugreport in Phabricator gibt, der immer noch offen ist, und wenn man sich die Diskussionen im selbigen Bugtracker, die in den verlinkten Bugreports (unter anderem zum Design und Rollout von sprachspezifischen Fehlerseiten) durchliest, bist du da auch relativ alleine mit dieser extrem abwegigen Definition von "Bug". Bug ist wenn etwas nicht so tut wie soll, nicht wenn etwas einfach zu lösen wäre, sorry; der Rest von deinem Gemurmele ist also immer noch "Kategoriefehler". --MüllerMarcus (Diskussion) 12:13, 23. Nov. 2025 (CET)

Mag sein, dass vielleicht auch die Verlinkungstitel Phabr. Bugreport irreführend sind und WM das im Phabricator-System nicht einordnen kann, ob es ein Bug ist oder eine Verbesserung? Ich bin Software-Entwickler und habe jede Woche mit solchen Kategorisierungsfragen zu tun:

• Für die, die es bemängeln, ist es ein Bug: Die meinen (aus ihrer Sicht) Das müsste so wie A laufen, läuft aber wie B

• Für uns Techniker, die die internen Details, die Hintergründe und Auswirkungen kennen, ist es kein Bug, sondern es war ein Ergebnis der Abwägung
  • von technischen Einschätzungen (welche Komponente ist für was zuständig und mit welchen Auswirkungen)
  • welche Nutzer sind damit konfrontiert, und welche Auswirkungen hat es, wenn man es einem Recht macht, für Millionen andere?

Besonders die letzte Frage lässt mich dafür plädieren, das Verhalten der Fehlerseiten NICHT zu ändern. Wer gibt das gesuchte Lemma in der URL an, ohne zu wissen, was er tut? --Hlambert63 (Diskussion) 20:43, 23. Nov. 2025 (CET)

Wer gibt das gesuchte Lemma in der URL an, ohne zu wissen, was er tut?

Lass mich das etwas sarkastisch sagen: Na dann ist ja alles gelöst, weil niemand Tippfehler in URLs hat, und die Fehlermeldung brauchen wir nicht mal auf Englisch dann! HTTP 404 zurück, minimaler header, 0B content. Da spart die Wikimedia Foundation jeden Monat cents, wenn nicht ganze Euros, im Vergleich zur aktuellen Lösung. (Page aus dem Varnish sollte wirklich WIRKLICH kaum was kosten.)

(und, Tipp: der cache der vor dem app server load balancer steht, sieht sehr wohl die URL/die subdomain, wie soll' er sonst Anfragen an den richtigen Cluster weiterleiten? Da nen subdomain-spezifischen 404-content zurückzugeben, wow, ja, da muss man wirklich nen Haufen Text schreiben um zu sagen "machen wir grad nicht so", und es als unmöglich darzustellen. Wow, da hab ich mich richtig ernst genommen gefühlt dadurch, @PerfektesChaos.)

Ich bin Software-Entwickler und habe jede Woche mit solchen Kategorisierungsfragen zu tun

Ich leite selber mittel- bis große FOSS-Projekte. Es ist ein Bug, wenn sich Stakeholder einig sind, dass das anders laufen sollte, vollste Zustimmung. Das kann ein Bug im "wontfix" sein, wenn eine Abschätzung sagt, dass es den Aufwand (oder andere Seiteneffekte, z.B. performance) nicht wert sind. (und man sollte diese Aufwandsabschätzung tunlichst nicht in die Kategorisierung "Bug oder Enhancements oder Nichts" reinziehen, sondern danach anwenden. Sonst kommt man sehr schnell in hamwirimmerschonsogemacht-Starre, wo nichts angefasst wird, weil wäre ja größerer Aufwand, und es wird lustig hunderte an Stunden an Minifeatures geschraubt statt die großen Bugs anzugehen. Man kommt von "kann den Zaun nicht flicken, muss Hühner fangen" zu "kann den Zaun nicht flicken, alle Entwickler sind mit Streichen des Hühnerhauses in hübschen Farben beschäftigt, und die Hühner haben wir auch länger nicht gesehen")

Die Frage ist ja genau die, ob Stakeholder das für einen Bug halten. (und nicht ob das Aufwand wäre oder adhoc denkbare Lösungen security downsides hätten.)

Aber mal ganz ehrlich: Ich lass euch in Ruhe damit. Du, liebe(r) @Hlambert63 hast dir wirklich Mühe gegeben, mir das zu erklären, danke! Aber für mich war die Geschichte gestern dann auch durch:

Hat @PerfektesChaos sehr erfolgreich erreicht, damit, wie er da seine Sicht, dass das Nachteile hätte, als diese komplett orthogonale Frage beantwortend, durchdrücken musste. Da kommt jetzt nicht mal Vertrauen auf, dass irgendwer irgendwas anfassen würde, bei diesem herabblickenden Ton. Und, hm, es gibt schönere Anlässe, den Finger im Zshg. mit der Wikipedia Auslauf zu gönnen.

(ich mach mal ein unsubscribe topic) --MüllerMarcus (Diskussion) 23:44, 23. Nov. 2025 (CET)

Jedes Mal, wenn du auf einer Wiki-Seite in das Suchfeld einen Buchstaben eintippst, wird eine neue Anfrage an die Serverfarm geschickt, die für die bisher im Suchfeld vorhandenen Zeichen die zehn besten Treffer zur Auswahl anbietet.

• In die dann dargestellte Seite sind eine Vielzahl einzelner Ressourcen eingebunden; Icons, Formeln, CSS, JavaScript. Die können zwar bereits im Browser-Cache hinterlegt sein, aber zu jeder wird eine Nachfrage an die Serverfarm geschickt, ob das noch aktuell wäre.
• Um einen Wikipedia-Artikel darzustellen, können locker 100–200 URL gebildet und an die Serverfarm gesandt werden. Die sind alle gültig. Alle wollen binnen Millionstel Sekunden beantwortet sein. Das erfordert maximal schnelle Antworten.

Größenordnungsmäßig kommen auf Billionen gültiger URL mal eine ungültige.

• Wie kommt eine ungültige Anfrage zustande?
  1. Böswilliger Angriff.
  2. Schlumpfiger Software-Entwickler hat ein Skript programmiert und das nicht richtig gemacht. Kommt Fehlermeldung, muss man das halt korrigieren und vielleicht vorher ins Manual gucken.
  3. Beschädigung in den Daten – extrem unwahrscheinlich.
  4. Jemand hat manuell versucht, die URL zu erraten; wie abschnittseröffnend.
• Fall 1. braucht keinen Service, Fall 2. bekommt einen klaren Hinweis auf die Fehlerursache. Fall 4. desgleichen.

@ „Stakeholder“

• Es wird von uns nirgendwo beworben oder anempfohlen, jemand solle direkt die URL einer Seite konstruieren.
• Wenn das jemand macht, geschieht das aus eigenem Entschluss und auf eigenes Risiko.
• Der Regelfall ist, dass man Verlinkungen anklickt, die angeboten werden. Die sind bei uns immer korrekt generiert; wer eine URL woandershin bekommen möchte, verwendet intelligenterweise C&P einer angebotenen Verlinkung. Wer händisch neue URL tippt, kann an ganz vielen Stellen Tippfehler machen, und die führen je nach Stelle des Fehlers zu den unterschiedlichsten Problemen, erst recht bei falscher Domain. Trick: Nur de.wikipedia.org oder wikipedia.org oder wikipedia.de tippen und danach die angebotenen Interfaces nutzen.
• Wer Skripte und sonstige nicht-interaktive Abfragen programmiert, braucht schon mal die H:URL-P und muss das dann auch so machen wie beschrieben.
• @ „Es ist ein Bug, wenn sich Stakeholder einig sind, dass das anders laufen sollte“
  • Es gibt ersichtlich keine Einigkeit unter den Stakeholdern.
  • Es gab ein Ticket von 2007, in einer völlig anderen Welt, dann nochmals eine Erörterung 2017, die ein wenig nachdachte, und 2022 den Hinweis, dass auf Youtube die 404 mit einem lustigen Comic mit einem Äffchen dekoriert wäre.
  • Es gibt Hunderte von Millionen Stakeholder. Es gibt vielleicht für die deWP einen außenstehenden Nicht-Entwickler in der Woche, der sowas mal probiert und einen Fehler macht. Es gibt über 1000 Wikis in der Serverfarm, in über 300 Sprachen. Mit einem Dutzend verschiedener Wiki-Typen von Wikis neben den Wikipedien, mit Domains von Wikis die in dieser Sprache gar nicht exisitieren, und soweit die eigentliche Wiki-Software involviert wäre auch deren Nutzung durch beliebige externe Installationen.
  • Es ist abzuwägen gegeneinander: Für die seltenen Fälle, in denen jemand mit einer falsch getippten URL ankommt, gegen „will sich aus Performancegründen auch nicht darum kümmern“ (17:38, 22. Nov.) sowie „Es ist ein Performance- und Sicherheitsproblem, und deshalb volle Absicht“ (23:12, 22. Nov.).
  • Jede Verkomplizierung der höchstkritischen URL-Analyse gefährdet die Stabilität für die gesamte Wiki-Welt.
  • Wir leben in einer Zeit, in der Angriffe gegen Wissens-Infrastruktur gefahren werden, in der versucht wird die Welt zu destabilisieren, in der versucht wird die „Wokepedia“ zu schädigen. Das ist genau der Moment, in dem man an einer maximal kritischen Stelle noch rumbasteln und Verkomplizierungen einbauen sollte.
  • Das Begehren ist teilweise ohnehin nicht Bestandteil der Wiki-Software selbst; bevor da irgendwas wirksam geändert und verkompliziert wird, gucken sowieso noch höhere Etagen drauf. Bislang ist es ein vereinzeltes nice-to-have.

Phabricator ist eine allgemeine Kommunikationsplattform, auf der vielerlei Angelegenheiten abgewickelt werden.

• Bug Reports, Anregungen und Feature Requests, Abwicklung planmäßiger Umstellungen, Migrationen, Weiterentwicklung, Auslieferung von Versionen.
• Nicht alles, was dort eine Ticket-Nummer hat, ist deshalb auch ein Bug.
• Die zitierten Tickets sind Wünsche, könnten explizit als „Feature Request“ klassifiziert werden.
• Derartige Tickets gab es Zigtausende; nur ein minimaler Prozentsatz davon wurde als umsetzungwürdig, ausgereift und Entwicklungsressourcen beanspruchend eingestuft und ist heute Teil der Wiki-Software.
• „Bug“ ist eine „Regression“; wenn es ein offiziell angebotenes und sogar früher funktionierendes Verhalten gibt, das jetzt auf einmal nicht mehr wie beschrieben erfolgt. Es gibt für den abschnittseröffnend beschriebenen Wunsch aber keine Zusicherung, dass dies genau so sein müsse. Ob „sich Stakeholder einig sind, dass das anders laufen sollte“, definiert keinen Bug, und eröffnet die Frage, wer genau zum Kreis der Stakeholder zu zählen wäre, und dann ob unter diesen tatsächlich Einigkeit besteht.

VG --PerfektesChaos 12:41, 24. Nov. 2025 (CET)

Schlussbemerkungen:

• Texte sind entweder global=englisch oder allsprachig=lokalisiert.
  • „allsprachig“ bedeutet, dass jede der 300++ unserer Amtssprachen zum Zuge kommt.
  • Nur englisch, spanisch, französisch und deutsch würde als westlich-kolonialistisch aufgefasst werden und ist unzulässig. Es muss dann eine Lokalisierung in jeder beliebigen Sprache möglich sein.
• Um Texte in über 300 Sprachen korrekt zu übersetzen, Rechtschreibfehler und Formulierungsverbesserungen in den Erstsprachen einzupflegen, ist translatewiki: erforderlich.
• Die fraglichen Server gehören nicht zur MediaWiki-Software, sondern sind eine private WMF-Angelegenheit.
  • Sie sind nur in global=englisch realisiert.
  • Um Updates aus translatewiki: wirksam zu machen, gibt es in MediaWiki einen Mechanismus, der wöchentlich für Zigtausende von Systemnachrichten neue Texte und Veränderungen antizipiert. Wir können die sogar lokal in deWP überschreiben.
  • Die Frontend-Server haben keine Implementierung für Mehrsprachigkeit, und es gibt auch keinen Dienstweg, um translatewiki-Systemnachrichten zu verteilen, und keine Software-Komponenten dafür.
• Die Sprachcodes wie de sehen auf den ersten Blick trivial aus; die ließen sich ja aus der URL entnehmen.
  • Das gilt für die meisten, aber nicht für alle; siehe hier.
  • Ein Wiki weiß qua Konfiguration, wie sein Standard-Sprachcode lautet. Das Frontend arbeitet jedoch nicht mit dem Wiki, sondern ist diesem vorgelagert und übermittelt die Anfrage erst dem Wiki. Das Frontend kennt den Standard-Sprachcode nicht für alle Wikis, und Sonderfälle müssten separat gepflegt und aktualisiert werden.
• Die Frontend-Server sind extrem hoch belastet, primäres Angriffsziel und müssen maximal performant arbeiten und möglichst simpel programmiert sein. Die begehrte Aufgabe müssten sie allein umsetzen, während sie sonst per Lastverteilung an viele physische Maschinen delegieren.

VG --PerfektesChaos 23:29, 30. Nov. 2025 (CET)

Gibt es eine Wikitext-Testseite?

Die Frage nach einer Wikitext-Testseite stellte sich mir beim Lesen des Abschnitts oberhalb #VE tut ungefragt Dinge. So eine Testseite sollte möglichst viele Eigenschaften der Wikitext-Syntax abdecken, inklusive absichtlich gebrochener Syntax, zb nicht passende ref-Tags, Tabellen, Gallerien, Maplinks, Math, Korrekte ISBN, falsche ISBN, HTML Entity an wirren Stellen usw. So eine Seite wäre auch hilfreich für das Testen von Userscripts und Regex. Frohes Schaffen — ⵓ ⌨ [​ɪ​​u:] 16:03, 1. Dez. 2025 (CET)

Das Betawiki [30] sowie das Testwiki [31] sind voller Testseiten, manche sind identisch zu Artikeln, manche testen bewusst verschiedene Syntaxoptionen (z.B. nutzen wir im Technische-Wünsche-Team Seiten wie diese [32][33], um neben unseren automatischen Tests Änderungen natürlich auch manuell anzuschauen). Neue Softwäreänderungen kommen immer zuerst in diese Wikis, um mögliche Fehler bestenfalls zu entdecken, bevor sie hier ankommen können. Viele Vorlagenentwickler nutzen übrigens ebenfalls das Betawiki, um Auswirkungen ihrer Änderungen zu testen. --Johannes Richter (WMDE) (Diskussion) 18:13, 2. Dez. 2025 (CET)

In Beantwortung der Anfrage: Wikipedia:Testseite. Es kann ja sooo einfach sein. Kaputte Syntax müsste hingegen kurzzeitig individuell erstellt und wieder SLA-gelöscht werden, weil dies bei uns LINT-Arbeit verursacht; diese besser auf Testwikis und dann nur eine einzelne Testseite pro spezieller Software-Funktionalität. VG --PerfektesChaos 11:29, 8. Dez. 2025 (CET)

VE tut ungefragt Dinge (2)

Gemeldet in Phabricator
Task T101841

Da die Unterstriche ein technisches Problem und kein Unfug waren, frage ich wegen dieses Edits hier auch mal nach. Es ist nicht das erste Mal, dass bei kleinen Änderungen (ob Unfug oder auch nicht) gleichzeitig <references responsive> auf <references responsive=""> geändert wird. Wiederkehrender Vandalismus oder Programmierfehler? --Horst Gräbner (Diskussion) 14:56, 6. Dez. 2025 (CET) PS: Weitere Beispiele: 1, 2, 3 und 4. --Horst Gräbner (Diskussion) 15:08, 6. Dez. 2025 (CET)

Das ist eine alter Fehler (phab:T101841), den TaxonBot stetig nachkorrigiert (z.B. [34][35][36]). --Johannnes89 (Diskussion) 15:35, 6. Dez. 2025 (CET)

Solange den Fehler keiner behebt ... Nun, @Johannnes89: Ich denke, dass es für Euch WMDE-Techies nicht so schwierig ist, den Task zu claimen und das Problemchen zu beheben, oder? Vielleicht kriegt Ihr das mit nem Sprint zwischendrin hin. Ich, und ich denke, ich kann da auch für Horst sprechen, sicher aber auch für uns alle, wären Euch sehr dankbar. --Doc Taxon (Diskussion) 15:46, 6. Dez. 2025 (CET)

Nach meinem (zugegeben begrenztem) Verständnis lässt sich das schwerer beheben, als es mit Blick auf den Diff aussieht. Andernfalls hätten das WMF Content-Transform-Team oder das WMF Editing Team das wahrscheinlich längst erledigt. Entsprechend kann ich nichts versprechen, aber es mal als mögliche Verbesserung zu Einzelnachweisen in die Diskussion bringen. --Johannnes89 (Diskussion) 16:07, 6. Dez. 2025 (CET)

@Johannnes89: Thiemo kennt den Fall schon. Er meinte auch, dass das wahrscheinlich nicht ganz so einfach ist, wie es erscheint. Aber wenn WMDE sich mit ihren Code-Kenntnissen mal gescheit reinhängt, denke ich, wird das was. --Doc Taxon (Diskussion) 17:46, 6. Dez. 2025 (CET)

@Johannnes89: Ich hab in diesem Task mal einen Vorschlag versucht. Schaut mal rein. Danke, --Doc Taxon (Diskussion) 01:39, 7. Dez. 2025 (CET)

VE tut ungefragt Dinge (3)

Gemeldet in Phabricator
Task T403379

Gemeldet in Phabricator
Task T412007

Spezial:Diff/262211086: Ich finde, dass man sich auf den VE verlassen können sollte. Die Technik-Werkstatt wird ja ohnehin nur von einer Minderheit gekannt und genutzt. Das Problem ist also vermutlich immer größer, als die wenigen Leute melden. Also zur Sache: Ich habe einen kleinen Tippfehler behoben und automatisch wird eine bereits vorhandene Referenz doppelt ausgefüllt, sodass es zu Fehlern kommen würde, wenn man eine der beiden definierenden Referenzen ändern würde. Und außerdem wurde die reference-Klammer verändert. --Fan-vom-Wiki (Diskussion) 22:12, 7. Dez. 2025 (CET)

Letzteres ist phab:T404089, sollte bald gefixed sein. Vgl. dazu auch WP:Subreferenzierung#In Arbeit.

Ersteres nehm ich morgen ins Team mit, mein erster Eindruck ist, dass der Fehler damit zusammenhängen könnte, dass der vollständige Einzelnachweis zuvor innerhalb der Vorlage {{Zitat}} definiert wurde. Identisch habe ich das gerade mit ner Infobox reproduziert [37], wo ja häufiger mal EN liegen (ich hab in der Bearbeitung nur den Fließtext angerührt). --Johannes Richter (WMDE) (Diskussion) 22:50, 7. Dez. 2025 (CET)

Dankesehr! --Fan-vom-Wiki (Diskussion) 10:40, 8. Dez. 2025 (CET)

Ups hab gestern den falschen Link gesetzt, phab:T403379 bezieht sich auf die ungewollte Änderung von <references />, ist wie gesagt in Arbeit. --Johannes Richter (WMDE) (Diskussion) 11:01, 8. Dez. 2025 (CET)

So, das andere Problem hab ich in phab:T412007 gemeldet, das Technische-Wünsche-Team schaut sich das an. --Johannes Richter (WMDE) (Diskussion) 12:53, 8. Dez. 2025 (CET)

 Info: [des Werkstattgründers]

• Es gibt WP:VE/RM → Wikipedia:Technik/Text/Edit/VisualEditor/Rückmeldungen
• Angelegenheiten, die eine eigenständige Diskussionsseite und bereits eine spezielle Plattform besitzen, sollen nicht hier in der allgemeinen Werkstatt erörtert und im Werkstatt-Archiv versenkt werden.
• Die TWS ist für die Situationen gedacht, die ansonsten keinem Werkzeug und keiner Plattform zugeordnet werden können.
• Die Abschnitte VE1 und VE2 sowie dieser sollten spätestens nach Beendigung dorthin verschoben und mit sinnvollen Überschriften versehen werden; hier jedoch nicht doppelt archiviert werden.

VG --PerfektesChaos 11:24, 8. Dez. 2025 (CET)

unterschiedliches verhalten zwischen Notebook und Toachpad

Hallo, ich habe unterschiedlich verhaltensweise bei meinem Thinkpad Lenovo L13 2-1, wenn ich es Notebook oder als Toachpad verwende.

Beim Toachped habe ich das Problem, das die "rechte Maustaste" (langes halten auf dem Link) nicht richtig funktioniert. Auch findet er die seite nicht mehr, wenn ich auf "versionsvergleichen" war und dann wieder auf die Seite möchte (drücke auf Artikel) sucht sich Wiki einen Wolf. Zurück geht auch nicht mehr .... mache ich das ganze als Notebook, alles keine Problem .... --Vielen Dank und viele Grüße Benutzer:Woelle_ffm (Diskussion) 13:04, 8. Dez. 2025 (CET)

Falsches Gendern einer Kategorie

Hier im Artikel Regina Ruben wie auch in vergleichbaren wird die Kategorie:Todesopfer im Vernichtungslager Sobibor gegendert sprich "Sobibor" wird in "Sobiborin" geändert. Falls das hier nicht die richtige Stelle ist, das anzusprechen, bitte ich um einen Hinweis. -- Nicola kölsche Europäerin 16:43, 14. Dez. 2025 (CET)

Du nutzt Benutzer:Reinhard Kraasch/GenderCats.js [38], was nicht mit allen Kategorien gleich gut umgehen kann. Soweit ich weiß wartet @Reinhard Kraasch das Skript aber nicht mehr aktiv, eine Änderung ist also eher unwahrscheinlich, sofern er nicht spontan Lust hat oder einer der WP:BOA Zeit findet (und Reinhard denen Änderungen in seinem Skript erlaubt). Da es ein Benutzerskript ist, bekommen Lesende den Fehler aber nicht angezeigt.

Mit WP:Technische Wünsche/Topwünsche/Geschlechterspezifische Anzeige der Kategorien gab es übrigens mal die Idee, eine MediaWiki-Lösung für alle umzusetzen (die dann solche Fehler auch behoben hätte), aber die Community hat sich damals nie auf ein nötiges Meinungsbild einigen können. --Johannnes89 (Diskussion) 17:13, 14. Dez. 2025 (CET)

Vielen Dank für Deine Antwort. -- Nicola kölsche Europäerin 16:52, 17. Dez. 2025 (CET)

Titelbild in der Suchfunktion

Hallo liebes Wikipedia Team,

ich war bereits mit einem Ihrer Kollegen in Kontakt, welcher meinte, dass ich mich an Sie wenden soll. Wenn man unser Unternehmen SECO SpA auf der deutschen Wikipediaseite sucht oder auf der italiensichen Seite unter dem Namen Seco, ist dort kein Titelbild zu sehen. Unser Logo haben wir bereits mit den Seiten verknüpft und hätten dies auch gerne als Titelbild in der Suchfunktion. Vielleicht können Sie uns dort behilflich sein oder können mir sagen, wie ich dort unterstützen kann.

Italienische Wikipediaseite: https://it.wikipedia.org/wiki/Seco

Deutsche Wikipediaseite: SECO SpA

Ich bedanke mich schonmal im Vorraus und wünsche Ihnen angenehme Feiertage!

Mit freundlichen Grüßen

Leonie Kring --LKSENE (Diskussion) 12:01, 17. Dez. 2025 (CET)

Bilder in Infoboxen werden nicht als Vorschaubilder verwendet.

Bitte Wikipedia:Bezahltes Schreiben beachten. --Magnus (Diskussion) 12:08, 17. Dez. 2025 (CET)

Das Logo hat ein Seitenverhältnis außerhalb der für ein Seitenvorschaubild zulässigen Schranken. -- hgzh 10:39, 18. Dez. 2025 (CET)

Zur Frage: Die Such-Vorschaubilder müssen bestimmte Kriterien bzgl. des Verhältnisses von Länge zu Breite einhalten. Das wird daher wohl nicht klappen, das Logo ist (für die Höhe) schlicht zu breit. --Wurgl (Diskussion) 10:44, 18. Dez. 2025 (CET)

Bug: Mehrspaltige Liste lässt Inhalte in der Anzeige verschwinden (die aber noch im Quelltext sind)

Hallo, ich habe einen seltsamen Bug entdeckt: Im Artikel Jürgen von der Lippe wurde unter "Fernsehsendungen (Auswahl) -> Als Moderator" auf mehrspaltige Liste umgestellt. Setdem fehlt der vorletzte Eintrag teilweise und der letzte Eintrag komplett in der Anzeige. Im Quellcode sind sie noch vorhanden, aber sie werden nicht mehr angezeigt. Obwohhl nur die Tags zur Mehrspaltigen Liste hinzugefügt wurden. --~2025-42794-21 (Diskussion) 15:04, 25. Dez. 2025 (CET)

Der Fehler wurde behoben. Das Problem waren die Pipe-Symbole im Texyt, die die mehrspaltige Liste verwirren. Muss ich mir merken... Vielen Dank dem Korrektor... --~2025-42794-21 (Diskussion) 15:44, 25. Dez. 2025 (CET)

Gern geschehen. Zur genaueren Erklärung und weiteren Lösungsmöglichkeiten (für die Zukunft) siehe Hilfe:Vorlagen#Senkrechter Strich. VG, Tkarcher (Diskussion) 15:49, 25. Dez. 2025 (CET)

Keine Sorge, das wäre morgen früh in meiner Fehlerliste als doppelter Parameter erschienen. --Wurgl (Diskussion) 16:26, 25. Dez. 2025 (CET)

Meist eingegebene Suchbegriffe, zu denen es keine Artikel gibt

Auf https://pageviews.wmcloud.org können unter dem Reiter Topviews die meistaufgerufensten Wikipediaartikel eines Tages, Monats und Jahres angezeigt werden (und dabei gefiltert werden nach der jeweiligen Wikipedia/Sprachversion). Das heißt also, dass die Wikipedia die eingegeben Suchbegriffe nicht nur für die Suche selbst registriert, sondern die Technik dahinter auch die Häufigkeit der eingebenenen Suchbegriffe registriert. Das ist, finde ich, erstmal nichts Außergewöhnliches. Mich interessiert ob die Wikipedia bzw. Wikipediatechnik auch Suchbegriffe und deren Anzahl speichert, wenn es dazu keine Artikel gibt. Es wäre doch interessant zu wissen und einsehen zu können, welche die meisteingegebenen Suchbegriffe sind, zu denen es keine Artikel gibt.
Falls es solch eine Statistikseite noch nicht gibt, schlage ich vor, sie einzurichten. Ich weiß...mit diesem Anliegen wäre ich eigentlich bei Wikipedia:Verbesserungsvorschläge aufgehoben...vielleicht werde ich das dort noch eintragen (andererseits kann ich mir vorstellen, das Benutzer, die jene Seite betreuen, auch die Wikipedia:Technik/Werkstatt betreuen)...zumal ich mich darin irren könnte, dass es eine solche Seite noch nicht gibt. Ich hoffe hier also erstmal auf Aufklärung.
Nebenbei: Mir ist aufgefallen, dass auf der Hauptseite von https://pageviews.wmcloud.org die täglichen Aufrufzahlen der englischsprachigen Wikipediaartikel zu Katzen und Hunde angezeigt werden. Ist zumindest bei mir so...bei Euch auch? --LennBr (Diskussion) 08:26, 30. Dez. 2025 (CET)

Bei der Abrufstatistik handelt es sich um vom Server ausgelieferte und deshalb zu diesem Zeitpunkt existierende reguläre Wiki-Seiten (NR≥0) ohne URL-Parameter. Nur für diese wird weltweit die Statistik der einzelnen Maschinen addiert und als Datenquelle oder über das von dir eingangs verlinkte Werkzeug bereitgestellt.

„Suchbegriffe“ wäre "Paul Schulze" Zürich oder die komplette H:Cirrus-Methodik. Zu derartigen Anfragen oder die daraus resultierenden Trefferlisten gibt es keine Statistik. Somit auch nichts, wo die Trefferliste nicht die Seite enthielt, die ich mir erhofft hätte.

Die von dir genannten Statistiken zählen jeden erfolgreichen Seitenabruf, völlig egal ob direkt über eine URL (wie von jedem Wikilink generiert) oder über die auf eine Suchanfrage generierte Trefferliste und die dort mittels URL verlinkten Einzeltreffer, unter denen ich einen oder mehrere auswählen kann.

VG --PerfektesChaos 12:01, 31. Dez. 2025 (CET)

Ok, in der Annahme, dass es keine Statistiken zu Abfragen von Nicht-existierenden-Artikeln gibt, betrachte ich diese Anfrage als erledigt. Danke für die Rückmeldung. LennBr (Diskussion) 13:15, 31. Dez. 2025 (CET)

Dieser Abschnitt kann archiviert werden. --LennBr (Diskussion) 13:14, 31. Dez. 2025 (CET)

Quelltexteditor: Syntaxhighlight per JS erkennen und umschalten

Ich bin gerade dabei das Script User:TMg/weblinkChecker umzubauen und zu aktualisieren: Siehe Benutzer:ⵓ/beta-externalURLform.js. In der aktuellen Version funktioniert gut, allerdings nur wenn das Syntaxhighlight deaktiveriert ist. Ist Syntaxhighlight aktiviert bleibt die Codezeile 242 (textbox.value = texboxValNew;) wirkungslos. Ich bräuchte eine Möglichkeit das Syntaxhighlight temporär zu deaktivieren. Frohes Schaffen — ⵓ ⌨ [​ɪ​​u:] 13:37, 30. Dez. 2025 (CET)

@TMg fyi falls du selbst nee Idee hast :) --Johannnes89 (Diskussion) 18:18, 31. Dez. 2025 (CET)

Autoren werden nicht angezeigt

Wenn ich im Artikel Pietro Locatelli ganz unten auf "Autoren" klicke, wird mir nicht wie üblich die Liste der Autoren mit Tortendiagramm etc. angezeigt, sondern folgender Hinweis: "Fehler beim Abruf der Wikiwho API: Revision ID (259557257) does not exist or is spam or deleted!" Weiß jemand, wie das zu beheben ist? --~2025-44127-57 (Diskussion) 16:43, 31. Dez. 2025 (CET)

Die API konnte die (zu dem Zeitpunkt) aktuelle Version Spezial:Diff/259557257 nicht finden. Ich hab den vagen Verdacht, dass das mit phab:T364245 zu tun haben könnte, aber vl. ist es auch was ganz anderes. Hab dann nen Miniedit gemacht [39] und nun wird die Autorenstatistik wieder angezeigt [40]. --Johannnes89 (Diskussion) 18:18, 31. Dez. 2025 (CET)

Super, dankeschön! --~2025-44127-57 (Diskussion) 19:24, 31. Dez. 2025 (CET)