Wikipedia:Technik/Werkstatt

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)

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:

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)

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

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)

Hinweis auf ungesichtete Versionen in Beobachtungsliste

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)

Andreas M. Fleckner

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)

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)

Moin Count Count, in der Quary steht für mich nun 55, der Benutzer hat aber 68 Bearbeitungen laut Tracker. Kann es sein, dass sich etwas an der Tabelle geändert hat? mfg --Crazy1880 11:26, 25. Mai 2026 (CEST)

Damals hat die automatische Rechtevergabe ja zweitweise gar nicht funktioniert und auch jetzt sind mir die Implementierungsdetails nicht 100%ig klar. Um welchen Benutzer geht es? --Count Count (Diskussion) 18:09, 27. Mai 2026 (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)

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)

Vorlagen die einen Listeneintrag generieren

Hallo!

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)

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)

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)

Die Wikipedia-App hat gesichtete Versionen noch nie supported, sondern zeigt stets die aktuelle Version. Ist insofern "gewollt", dass phab:T169116 bei den zuständigen Entwicklern offenbar keine Priorität hat. --Johannnes89 (Diskussion) 13:17, 22. Okt. 2026 (CEST)

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)

@Robby.is.on: Das hätte ich ebenfalls gerne. Ist ein Hauptgrund wieso ich nur wenig Motivation habe in der DEWP beizutragen anstatt in der ENWP wo man u.a. scheinbar mehr Respekt gegenüber der Zeit von Beitragenden hat.

Ein Tipp wie du da weiterkommst wäre diesen Wunsch hier zu unterstützen – ob das was bringen wird weiß ich nicht, aber zumindest ist es etwas:

W378: Adding the RefToolbar to Wikipedias that don't have it to make citing sources quick & easy (eg DEWP).

(Ich verstehe nicht warum es so wenige Nutzer zu stören scheint, dass sie etwas was in der ENWP meist in sekundenschnelle geht, stets unnötigerweise von Hand machen sollen einfach weil man hier das bereits-verfügbare Werkzeug grundlos nicht aktiviert.) --Prototyperspective (Diskussion) 10:18, 8. Feb. 2026 (CET)

Danke, Prototyperspective. Hab mich dem Wunsch angeschlossen. Robby.is.on (Diskussion) 15:31, 8. Feb. 2026 (CET)

Hm, man kann aber doch einfach in den Einstellungen den „neuen“ Wikitext-Editor aktivieren (2017-Editor), dann braucht es keine RefToolbar (zumindest sehe ich auf die Schnelle keine Vorteile dieser Toolbar gegenüber der Standardfunktion des neuen Wikitext-Editors und des VisualEditors). --XanonymusX (Diskussion) 16:11, 8. Feb. 2026 (CET)

Meinst du Wikitext#VE-Werkzeugleiste_bei_der_Quelltextbearbeitung, XanonymusX? Dort steht:

Weltweit wurde Ende 2016 eine Möglichkeit verfügbar gemacht, aus der klassischen Quelltextbearbeitung heraus Funktionen des VisualEditor zu nutzen. Dies geschah zunächst als Beta-Feature.

Um dies zu verwenden, musst du es als angemeldeter Benutzer in deinen persönlichen Benutzereinstellungen (Registerkarte Bearbeiten) aktivieren.

Um welche Einstellung in der Registerkarte "Bearbeiten" handelt es sich dann? Robby.is.on (Diskussion) 17:20, 8. Feb. 2026 (CET)

Unter Spezial:Einstellungen#mw-prefsection-editing-editor die letzten beiden Optionen anwählen, dann ist der neue Editor aktiv. --XanonymusX (Diskussion) 17:51, 8. Feb. 2026 (CET)

Danke, das hat geholfen. :-) Robby.is.on (Diskussion) 18:56, 8. Feb. 2026 (CET)

Danke euch beiden. Wenn man "Wikitextmodus innerhalb des visuellen Editors anstelle eines anderen Wikitexteditors verwenden" aktiviert, kann man also die Funktion zum Belege einfügen nutzen. Das hat bezüglich diesem Thema glaube bis jetzt noch niemand erwähnt also scheint es nicht sonderlich bekannt zu sein. Da dieser Editor jedoch nicht der Default-Editor ist und der Nutzer nicht weiß, dass es diese Funktion gibt und man die über die Aktivierung dieser Einstellung in den Nutzereinstellung bekommen kann, ist das in der Praxis keine wirkliche Lösung. Ich würde keinen Anlass sehen zu diesem Editor zu wechseln und nur sehr wenige Nutzer scheinen diesen Editor zu nutzen und wusste auch noch nie warum den manche Nutzer nutzen. Zudem gibt es auch einige Vorteile vom Wikitext-Editor wie zB dass man unten das Feld für die Edit-Summary hat anstatt dass man das erst in einem Popup nach Klick auf Veröffentlichen eingeben kann. Wenn der normale Wikitext-Editor abgeschaltet wird und dieser 2017Editor dann der Default Editor für 'Quelltext bearbeiten' wird, wäre das Problem auch gelöst. Ein Hauptproblem mit diesem scheint mir zu sein, dass man dort keine Preview hat; von daher werde ich bis auf weiteres dennoch nicht zu diesem wechseln. --Prototyperspective (Diskussion) 17:52, 8. Feb. 2026 (CET)

Keine Vorschau? Das wäre mir neu. Ich arbeite jedenfalls seit 2017 exklusiv mit dem neuen Editor und könnte mir den alten nicht mehr vorstellen, na ja. Die WMF hat leider die falschen Prioritäten bei der Weiterentwicklung gesetzt und sich nie getraut, den alten Editor endlich aufzugeben; dadurch fehlen dem aber natürlich auch die Funktionen, die die neueren Editoren bereits haben. Auslaufmodell ist er auf jeden Fall, fragt sich halt, wie lange noch. --XanonymusX (Diskussion) 17:57, 8. Feb. 2026 (CET)

Ich hatte übrigens schon in WP:Projektdiskussion/Archiv/2025#Wieso gibt es in DEWP immer noch kein Zitiertool (RefToolbar/Autofill)? auf den 2017 Wikitext Editor hingewiesen, den ich ebenfalls seit Jahren nutze (inkl. Vorschau). Find ich ideal als Kombination aus Wikitext und Menüoptionen wie Citoid. Aber wenn sich jemand findet, der in dewiki ein Gadget wie RefToolbar für den normalen Wikitext einrichten und betreuen möchte, nur zu. --Johannnes89 (Diskussion) 18:10, 8. Feb. 2026 (CET)

Oh stimmt. Hatte daraufhin dort auch schon auf die Problematik damit inkl dem Problem mit der Vorschau hingewiesen. Ja, das wäre super. Da es das Gadget ja schon in der ENWP gibt, wüsste ich nicht welche Problematiken oder Maintenancenotwendigkeiten hier auftreten könnten, die nicht schon dort gelöst sind bzw sein werden. --Prototyperspective (Diskussion) 19:11, 8. Feb. 2026 (CET)

@ „Aber wenn sich jemand findet, der in dewiki ein Gadget wie RefToolbar für den normalen Wikitext einrichten und betreuen möchte“

• Seit Mai 2015 gibt es citoidWikitext@PerfektesChaos für den normalen Wikitext.

Ansonsten gäbe es ein solches „Gadget“ bei uns nur im BNR, also mit deutschsprachiger Dokumentation, gepflegt durch die verantwortliche Einzelperson.

• Prototyperspective kann das also in den nächsten Stunden umsetzen und anbieten.
• Bei einem echten Community-Gadget ginge die Verantwortung auf die BOA der deWP über, die gezwungen würden, das in den nächsten Jahrzehnten in Ordnung zu halten. Ein von uns einmal eingerichtetes Gadget darf niemals wieder abgeschafft werden, weshalb wir seit anderthalb Jahrzehnten keine neuen JS-Gadgets mehr angelegt haben.
• Übrigens kann auch jeder jetzt sofort den Code aus der enWP laden; ein „Gadget“ ist überhaupt nicht erforderlich.
  • Wie das geht, müsste in der dortigen Doku erläutert werden; falls das dort nicht stünde, taugt die Doku nicht viel.

VG --PerfektesChaos 00:24, 9. Feb. 2026 (CET)

Vielen Dank für diese Erklärungen.

Dieses Skript nutze ich selbst. Es ist jedoch keine Lösung des Problems hier. Dieses Query zeigt, dass lediglich 148 Benutzer über dieses Skript Bescheid wissen und es aktiviert haben, das sind also weniger als 1,8% aller 8590 Benutzer mit >2k Edits. Es funktioniert zudem nicht so einfach/selbsterklärend, schnell und fehlerfrei wie RefToolbar.

Was heißt denn "gepflegt durch die verantwortliche Einzelperson" – ich würde zwar die deutschsprachige Dokumentation schreiben und eventuelle Fragen beantworten, an der Entwicklung mitmachen würde ich aktuell aufgrund zu vieler anderer Projekte nicht. Wenn ich bei der Lösung mithelfen kann, mache ich das gerne. Es ist aber gemeint, dass dieses Tool per Default im Wikiquelltext Editor verfügbar ist – also zB nach einer gewissen Vorlaufzeit in der man das Gadget in den Einstellungen manuell proaktiv aktivieren muss. Sonst profitieren die meisten Nutzer nicht davon (inklusive die relativ neuen Nutzer die den größten Nutzen davon hätten) und es gibt denke auch keinen Grund diesen Button nicht anzuzeigen – man muss ihn ja nicht nutzen und viel Platz verbraucht er nicht.

"weshalb wir seit anderthalb Jahrzehnten keine neuen JS-Gadgets mehr angelegt haben" das klingt dann aber so als wäre das keine gute Idee gewesen so dass man das womöglich neu überdenken bzw diskutieren sollte so dass dieses Hindernis wegfällt.

"Übrigens kann auch jeder jetzt sofort den Code aus der enWP laden" interessant. Vermutlich also indem man etwas zur Benutzername/commons.js Seite hinzufügt. Die Dokumentationsseiten in der ENWP beschreibt jedenfalls nicht wie das geht. Dort steht "RefToolbar 2.0 is now turned on by default for all users on English Wikipedia. You don't have to do anything to install it." und hier "Presence of the toolbar is controlled by two checkboxes: Preferences → Editing → Editor → Enable the editing toolbar […]" Wie genau man das Gadget hier aktiviert falls das tatsächlich geht würde mich interessieren, jedoch wäre es keine Lösung, das noch weniger Benutzer als 2% betreffen würde.

-

Johannes Richter (WMDE) schrieb heute, "Gadgets liegen allerdings in der Hand der Community, dazu kann und darf das Technische-Wünsche-Team nicht aktiv werden, wir sind rund um Verbesserungen der MediaWiki-Software aktiv. Im Prinzip muss nur Konsens [hier] gefunden und dann von den WP:BOA implementiert werden" - es wäre wirklich toll wenn das über diese Diskussion aktiviert wird (gerne auch per default deaktiviert und in in Zukunft dann nochmal eine Diskussion ob man es per default aktiviert wie sie auch vor 14 Jahren hier stattgefunden hat). --Prototyperspective (Diskussion) 20:13, 9. Feb. 2026 (CET)

@ „dass dieses Tool per Default im Wikiquelltext Editor verfügbar ist“

• Derartige Zwangsbeglückungen sind überhaupt nicht erwünscht.
• Siehe aktuelle WP:FZW #Neue Zeile mit überflüssigen Reitern – WP:FZW #Was sind Labels? – WP:FZW #Beobachtungsliste bearbeiten.
• Was du für dich persönlich als hilfreich ansiehst, möchten andere in ihrer Arbeitsweise überhaupt nicht haben, und stören sich an überflüssigen und verwirrenden Angeboten.

@ „Konsens gefunden“ – du müsstest den Konsens mit den Menschen herstellen, die in den nächsten Jahrzehnten ein Community-Gadget betreuen sollen.

• Seit Anfang der 2010er stellen wir keine neuen JS-Funktionalitäten mehr bereit. Eben drum.

@ „dass lediglich 148 Benutzer über dieses Skript Bescheid wissen und es aktiviert haben“

• Du berücksichtigst nicht fliegelflagel@Schnark, worüber dies aktiviert werden kann.
• Du unterstellst, dass alle Menschen genauso arbeiten wollen würden wie du; und die Diskrepanz in den Zahlen wäre darauf zurückzuführen, dass dies nicht alle wissen. Aber viele unserer Leute wollen diese Werkzeuge überhaupt nicht haben.
• Ich selbst benutze citoidWikitext@PerfektesChaos auch nicht.
• Der Quelltext-Editor 2017 stellt ein Werkzeug bereit, wer den VE benutzt hat auch ein Werkzeug. Das genügt, und warum muss sich jemand mit noch mehr Funktionen auseinandersetzen müssen?

VG --PerfektesChaos 22:29, 9. Feb. 2026 (CET)

• Finde deine Weise der Interaktion nicht besonders konstruktiv und teils schon etwas unfreundlich. Scheinbar sind wir unterschiedlicher Meinung – auch gut, dann hoffe ich dass dennoch genügend Nutzer dafür sind diese wichtige und nützliche Funktionalität nicht nur einer winzigen Elite an technisch-versierten Nutzern zu Verfügung zu stellen, sondern allen. Nicht nur in der Theorie oder als 'Möglichkeit' sondern in der Lebensrealität.
• Sprich bitte für dich; wenn 1 Nutzer irgendein neues Feature nicht mag und einen Thread erstellt wie er die gewohnte UI zurückbekommt heißt das absolut gar nichts außer dass dieser 1 Nutzer 1 bestimmtes Feature nicht mag. Der Nutzer hat gefragt wie man das verstecken kann und hat die Antworten bekommen; ist recht irrelevant das hier überhaupt zu verlinken.
• Was ist denn da zu betreuen? Da ist nichts zu betreuen und einfach nur was zu aktivieren. Wenn doch was zu betreuen wäre – abgesehen von Fragen die ich gerne beantworte – dann warte ich immer noch auf die Info was. Ansonsten ist das hier ein Ort wo Konsens gefunden werden kann wie ich hörte.
• Okay angenommen alle Nutzer dieses Skript haben nicht auch das andere installiert, sind das nochmal 171 zusätzliche Nutzer; 148+171 = 319 = 3,7% und das berücksichtigt nicht die vielen Nutzer mit weniger als 2000 Edits für die die direkt und von Anfang an verfügbare Funktion für das einfache Einfügen von Zitaten da wo man es erwartet und leicht findet besonders nützlich wäre.
• Ich unterstelle das nicht, da man die Funktion nicht nutzen muss nur weil man die Möglichkeit hat. Stattdessen unterstellst du, dass jeder so einfach wie du Skripte findet und dass man solche Funktionen nicht schon von Beginn an braucht bzw sehr davon profitieren würde usw.
• Auf reddit findet man das Fehlen dieser Funktion in nicht-EN WPs jedenfalls ebenfalls absolut unverständlich.
• Gerne Mal einen Survey machen was tatsächlich gewünscht ist. Und anstatt dass ein paar superwenige Nutzer elitär nützliche Funktionen nur langjährigen technischversierten Nutzern vorbehalten, wäre es besser zB die Funktion für manche zu Aktivieren (zB Betatester bzw A/B Test) und dann zu fragen wie sie das finden.
• Wie gesagt was den Quelltexteditor2017 angeht fehlt dort die Vorschau und es gibt auch ein paar weitere kleinere Nachteile. In der ENWP nutzt nur ein kleiner Teil den Visuellen Editor und hier ist es auch nicht so dass es die überwiegende Mehrheit ist. Selbst dann wäre das kein Grund einen nützlichen Button beim Quelltexteditor einzufügen. Und man muss sich kein wenig mit noch mehr Funktionen auseinandersetzen. Stattdessen muss man sich mit noch mehr Funktionen auseinandersetzen wenn es diese Funktionalität nicht gibt. Etwa was Vorlagen sind, was Einzelnachweisvorlagen sind, welche Parameter dafür existieren, ggf wo man wie wie Skripte findet und wie man sie installiert, usw. Scheinbar hast du den Sinn von dem ganzen nicht verstanden denn genau das ist ja einer der Hauptgründe wieso RefToolbar-Aktivierung angefragt wurde.

--Prototyperspective (Diskussion) 23:40, 9. Feb. 2026 (CET)

Englische Kurzbeschreibung bei Modulseiten

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)

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)

@Wurgl wir könnten das zumindest für dewiki recht unkompliziert verbessern, indem wir MediaWiki:Globalpreferences-summary ergänzen – hättest du nen Formulierungsvorschlag? --Johannnes89 (Diskussion) 09:08, 4. Jun. 2026 (CEST)

Ich hab da keine Idee für einen sinnvollen Zusatz. Global ist für mich global und nicht "ziemlich viele". Der Unterschied erklärt sich wohl aus unterschiedlichen Konfigurationen verschiedener Sprachversionen. --Wurgl (Diskussion) 10:19, 4. Jun. 2026 (CEST)

„Global“ heißt für mich nur „Vorrang vor lokal“, nicht notwendigerweise „überall und immer“. Wenn man in einem Softwarepaket ein globales Theme auswählen kann, erwarte ich, dass es überall angewendet wird, wo man Themes auswählen kann. Wenn es ein Tool in diesem Paket geben sollte, bei dem man das Theme gar nicht auswählen kann, wird die globale Einstellung dort natürlich nicht angewendet. Sie bleibt in meinem Verständnis aber trotzdem zu Recht eine globale Einstellung, weil sie überall gilt, wo man das Theme überhaupt definieren kann.
Vorschlag: „Diese globalen Einstellungen werden in allen Wikipedias angewendet, in denen sie auch als lokale Einstellung verfügbar sind. In manchen Wikipedias haben sie daher keine Auswirkungen. In manchen Wikipedias kann es zusätzliche lokale Einstellungen geben.“ Troubled @sset   ^{[ Talk ]}   11:44, 4. Jun. 2026 (CEST)

Da es auch um Schwesterprojekte geht, vielleicht etwas abgewandelt und ergänzt:

"Diese globalen Einstellungen werden in allen Wikimedia-Projekten angewendet, in denen sie auch als lokale Einstellung verfügbar sind. In manchen Projekten haben sie daher keine Auswirkungen, in anderen kann es zusätzliche lokale Einstellungen geben, die sich von dort meist ebenfalls global für alle Projekte mit solchen Einstellungen definieren lassen." --Johannnes89 (Diskussion) 15:33, 4. Jun. 2026 (CEST)

@ „Global“ heißt für mich nur „Vorrang vor lokal“

• Es gibt zweimal lokal:
  1. Die lokale Konfiguration des einzelnen Wiki.
  2. Meine persönliche lokale Konfiguration in diesem einzelnen Wiki, mit der ich meine globale Konfiguration genauso überschreibe, wie die lokale Konfiguration des einzelnen Gesamt-Wiki.

 Info: Hilfe:Einstellungen/global

• Beispiel: Ich habe global für alle Wikis vorgegeben, dass ich Englisch als Oberflächensprache haben möchte.
  • Damit bin ich nicht der lokalen japanischen und arabischen Oberfläche ausgeliefert.
  • In den deutschsprachigen Wikis habe ich meine globale Einstellung mit Deutsch überschrieben.
  • Dadurch merke ich auf Anhieb, dass ich grad irgendwo auswärts bin, oder daheim.
• Die Präferenz-Reihenfolge (Kaskade) ist:
  1. Lokale Konfiguration des einzelnen Wiki.
  2. Meine globale Einstellung überschreibt diese.
  3. Meine lokale Einstellung überschreibt diese.

VG --PerfektesChaos 15:46, 4. Jun. 2026 (CEST)

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)

Ich setze hier mal auf erledigt, da kein technisches Problem bzgl. MediaWiki/Wikipedia/Wikimedia und schon ein paar Jahre her. --Johannnes89 (Diskussion) 13:25, 22. Okt. 2026 (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)

@Lupe tritt das Problem bei dir noch auf? Ich kann es weder in Teshima (Tonoshō) noch in en:Singalila National Park reproduzieren, womöglich inzwischen behoben worden? --Johannnes89 (Diskussion) 09:10, 4. Jun. 2026 (CEST)

Wohl erledigt, nicht mehr reproduzierbar. --Johannnes89 (Diskussion) 13:26, 22. Okt. 2026 (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)

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)

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:

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

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)

fehlerhafte "Umwandlung" von Einzelnachweisnummern in Symbol

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 entdeckt und im Quelltext-Edit entfernt (, 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 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 . Scheint aber recht selten zu sein, sonst wär's wohl früher aufgefallen. Solche Bugs gabs anscheinend schon früher mal , 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)

Hier noch dokumentiert: Der Fehler kam neulich erneut auf (WP:Fragen zur Wikipedia/Archiv/2026/Woche 09#Komische Edits bei Bildungssystem in Finnland), aber scheint weiterhin nur sehr sehr selten mal aufzutreten. --Johannes Richter (WMDE) (Diskussion) 07:36, 4. Mär. 2026 (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

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 ${\displaystyle \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 ${\displaystyle \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)

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)

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

--Molgreen (Diskussion) 16:58, 8. 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)

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)

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)

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)

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)

Inzwischen wohl längst erledigt. --Johannnes89 (Diskussion) 13:35, 22. Okt. 2026 (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)

phab:T387797 --Johannnes89 (Diskussion) 20:25, 4. Apr. 2026 (CEST)

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)

phab:T421681 --Johannnes89 (Diskussion) 20:30, 4. Apr. 2026 (CEST)

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

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

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)

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)

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)

you need jquery.textSelection, which is the bridge between editors and the editfield. https://doc.wikimedia.org/mediawiki-core/master/js/module-jquery.textSelection.html TheDJ (Diskussion) 20:27, 10. Jan. 2026 (CET)

WD:Lmul und Anzeige im Artikelheader

Hallo, in Pyhrn-Eisenwurzen Klinikum Kirchdorf Steyr (als Bsp) wird oben aus WD angezeigt: Wikidata: (Keine Bezeichnung) (Q104628335), Krankenhausverbund in Oberösterreich. Das WD-Objekt hat kein Lde Pyhrn-Eisenwurzen Klinikum Kirchdorf Steyr (Q104628335), sondern nur ein Lmul (daher Keine Bezeichnung). Was jetzt keinen Datenfehler darstellt, sondern so vorgesehen ist. Mein Wunsch ist, dass im Artikelheader der Label Lmul angezeigt wird, wenn Lde undefiniert ist. Ich weiß schon, ihr seid da nicht wirklich zuständig, aber vielleicht könnt ihr weiterleiten bzw. mir sagen, wohin ich mich wenden kann (nicht um meinen Kummer loszuwerden, sondern dass das behoben wird). lg --Herzi Pinki (Diskussion) 15:49, 10. Jan. 2026 (CET)

d:User_talk:Yair_rand/WikidataInfo.js#Default/'mul'_label; du bist nicht der erste, der sich das wünscht. Gruß, -- hgzh 16:01, 10. Jan. 2026 (CET)

Danke, immerhin. lg --Herzi Pinki (Diskussion) 18:49, 10. Jan. 2026 (CET)

Wie aus der Diskussion hervorgeht, hat das offizielle polnische Gadget die gewünschte Funktion: pl:MediaWiki:Gadget-WikidataInfo.js (Einbindung mw.loader.load( '//https://pl.wikipedia.org/w/index.php?title=MediaWiki:Gadget-WikidataInfo.js&action=raw&ctype=text/javascript' );) --~2026-77613-7 (Diskussion) 17:30, 4. Feb. 2026 (CET)

Gadget zur Messung von Video-/Audioplays

In phab:T198628 wird schon länger daran gearbeitet, ein neues Werkzeug zur präziseren Messung von Videos und Audiodateien, die in Wikimedia-Projekten eingebunden werden, zu entwickeln. Das Tool Media Views in Categories (unter Nutzung der mediaviews-API) hat sich als ungeeignet erwiesen, da es nicht erfasst, ob ein eingebundenes Video/Audio auch wirklich abgespielt wird. Der aktuelle Vorschlag ist toolforge:commons-play-listener, der die abgespielten Sekunden ermittelt und auf dieser Grundlage Abspielstatistiken erstellt. Der Code liegt derzeit im Userspace des Entwicklers und müsste pro Projekt aktiviert werden, sinnvollerweise als Gadget (für Seiten, in denen Videos oder Audiofiles eingebunden werden). Aktuell ist es nur in der baskischen Wikipedia aktiv. Die bisherige Diskussion in enWP war recht kontrovers, mittlerweile gab es aber ein paar Anpassungen. Da eine neue, fest eingebaute Lösung von WMF noch in weiter Ferne liegt, und die Abspielstatistiken für einige Projekte (bei uns vor allem WP:Wiki Loves Broadcast) ziemlich wichtig sind, wollte ich mal in die Runde fragen, als wie sinnvoll und umsetzbar ein solches Gadget hier beurteilt wird. Gruß --XanonymusX (Diskussion) 16:27, 10. Jan. 2026 (CET)

Als Community-„Gadget“ für alle, die sich irgendeine Seite angucken, ist das ob des sehr speziellen Partikularinteresses an dieser Statistik-Information ganz sicher nix.

• Das Prinzip ist mir nicht so wirklich klar:
  • Immer, wenn eine Mediendatei durch irgendeinen Menschen gestartet wird, soll ein Irgendwer-Toolforge-Entwickler einen Datensatz bekommen, dass jemand im Internet sich in diesen Hundertstelsekunden genau diese Mediendatei anguckt/anhört?
  • Wohl des Wahnsinns fette Beute.
  • Dann gern noch als Cloud-Server mit Zugriff auf die IP und das Browser-Profil? Mit automatischem Forwarding an Putin, Erdogan und MAGA????
  • Mit der Kenntnis des Zugriffs durch irgendwen lässt sich https knacken, der nur wüsste, dass irgendwas aus der WMF-Serverfarm angeguckt wird, aber nicht, welche Datei oder Seite. Wenn ich jetzt Zugriff auf die Provider habe, kenne ich die IP-Adresse und die Wohnanschrift des Kunden, der in diesen Sekunden diese Datei bei der WMF abgerufen hat.
• Die WMF-requests-Datenbank enthält anonyme Statistiken, nachdem sie den Tag über durchgezählt hat.
• Ein JavaScript kennt den Browser (die IP eher nicht direkt) und den Benutzernamen bzw. das TK und wüsste, wer welche Artikel oder Seiten liest oder Mediendateien lauscht.

Einen Abschnitt zu „Datenschutz“ kann ich in toolforge:commons-play-listener nicht erkennen. Ist aber auch egal, denn die Etablierung irgendeines Spionage-Gadgets, das beim Aufruf jeder Seite gestartet werden soll, und das dann auch noch in privater Hand irgendwo in der toolforge liegt, dessen Code-Veränderungen wir nicht auf der Beo haben, und welches das erklärte Ziel hat, den Lesezugang einzelner Seiten zu protokollieren, ist nicht akzeptabel, und die jedem Seitenabrufenden auch noch JavaScript-Ressourcen aufbürdet, damit Verlangsamung, gleichfalls nicht.

VG --PerfektesChaos 21:01, 10. Jan. 2026 (CET)

Fair enough. Ich würde da zwei Punkte unterscheiden:

• Zum einen ist es die erklärte Absicht von WMF/WMDE, dass wir zu Video- und Audiodateien auf Commons auch eine brauchbare Wiedergabestatistik liefern können. Sie wird nie so umfassend wie die von echten Videoportalen sein (Datenschutz, ist klar), aber es soll verlässlich feststellbar sein, wie oft diese Dateien abgespielt werden. Verschiedene technische Lösungsansätze hierfür wurden und werden auf Phabricator diskutiert, aber irgendeine Lösung muss es geben.
• Zum anderen der hier vorgestellte Ansatz. Ganz durchblicke ich die Technik auch nicht, ausgereift ist das Konzept noch nicht, wie mir scheint. Mit der baskischen Wikipedia haben wir ja zumindest einen Testfall, anhand dessen die Entwickler hoffentlich abschätzen können, wie die dauerhafte Lösung aussehen muss. Von unserer Seite ist dann wohl am meisten geholfen, wenn wir uns ggf. auf Phabricator zu Wort melden.

Gruß --XanonymusX (Diskussion) 00:22, 14. Jan. 2026 (CET)

Es wäre sehr sinnvoll etwa für Statistiken von Audiodateien von Wikipedi-Artikel-Audioversionen. --Prototyperspective (Diskussion) 12:48, 17. Feb. 2026 (CET)

Bilddarstellung

In der Gallerie in Chor (Architektur)#Sonstige besondere Chorformen werden zwei Bilder nicht angezeigt. Da ich im Quelltext keinen offensichtlichen Fehler sehe, bin ich mir unsicher, ob es an den Bilddateien oder der Software, evtl. am Zusammenspiel von deWP und Commons liegt. Beim Draufklicken wird die Seite von Datei:Dehio 191 Arbona.png normal angezeigt, bei Datei:Dehio 191 Vaux-de-Cernay.png dagegen wird das Bild als schwarze Fläche angezeigt, erst bei nochmaligem Draufklicken erscheint das richtige Bild. --Duschgeldrache2 (Diskussion) 00:29, 2. Feb. 2026 (CET)

Kann Uploader Fb78 klären? Beim Klick müssten bei Commons eigentlich sofort die Bilder sichtbar sein. Zu sehen ist jweils nur die Übersichtsseite mit den Auflösungen und VG. Danke, --01:52, 2. Feb. 2026 (CET)

Ein WMF Server Problem. Den Technikern hab ich mal bescheid gegeben. Mehr als warten geht jetzt nicht. --Doc Taxon (Diskussion) 10:29, 2. Feb. 2026 (CET)

Okay, dann schon mal im Voraus Danke! --Duschgeldrache2 (Diskussion) 23:26, 2. Feb. 2026 (CET)

Müsste jetzt funktionieren. --Doc Taxon (Diskussion) 14:21, 4. Feb. 2026 (CET)

@Duschgeldrache2: Ich denke gerade über einen Bot nach, der so etwas korrigiert, mal schauen. --Doc Taxon (Diskussion) 17:39, 4. Feb. 2026 (CET)

Fluppt! Nochmal Danke! --Duschgeldrache2 (Diskussion) 17:48, 4. Feb. 2026 (CET)

Beantworten innerhalb von Vorlagen

Mindestens auf WP:VSW führt die angezeigte, aber nicht mögliche, Funktion zu folgender eher weniger sinnvoller Fehlermeldung:

Der Kommentar, auf den du antworten möchtest, konnte auf der Seite nicht gefunden werden. Er könnte gelöscht oder auf eine andere Seite verschoben worden sein.
Bitte lade die Seite neu und versuche es erneut.

Um dort innerhalb der Vorlage ordentlich zu antworten muss der gesamte Abschnitt zum bearbeiten geöffnet werden, und mit entsprechender Syntax (k.A. ob der WP:VE da was anders macht, den nutze ich nicht) innerhalb der Vorlage geantwortet werden.
Gibt es eine Möglichkeit, entweder die Funktion innerhalb von Vorlagen generell nicht anzubieten, oder alternativ, das ordentlich arbeiten zu lassen? Grüße vom Sänger ♫ ^(Reden) 16:05, 9. Feb. 2026 (CET)

Also, innerhalb eines derartigen Vorlagenparameters ganz sicher nicht.

Das Diskussionsseiten-Hilfsmittel arbeitet auf dem Quelltext der Forumsseite und erwartet global standardkonforme Syntax.

• Die Überschrift steht außerhalb der Vorlageneinbindung in erkennbarer Gleichheitszeichen-Syntax. Insofern wäre ein Abschnitt zu finden.
• Gesucht wird für eine Beantwortung jedoch ein signierter Beitrag, auf den geantwortet werden kann. Der ist für das Hilfsmittel jedoch nicht auffindbar, deshalb die Fehlermeldung.

Auf mw:Help:DiscussionTools sehe ich keine Deklaration, mit der eine Seite nur von den DiscussionTools ausgenommen werden könnte. Das geht zwar generell (etwa auf archivierten Seiten), jedoch werden dann auch alle Abschnittsbearbeitungen und neuen Quelltext-Abschnitte deaktiviert.

Auf der dortigen Talk page oder per Phabricator wäre ein derartiges Feature zu erbitten, was aber wenig aussichtsreich wäre. Ich war bei der generellen Aktivierung/Deaktivierung beteiligt, und die Unterscheidung nicht-doch-Diskussions-Namensraum mit/ohne DiscussionTools ist komplex genug.

• [Abonnieren] ist ja sinnvoll, gehört auch in den Dunstkreis. Nur [Beantworten] ist unerwünscht.

Theoretisch könnten wir in /Intro eine Gadget-Kategorisierung einbauen, und damit lokal ein [Beantworten]-Link effizient ausblenden; bei allen betroffenen Forumsseiten. DiscussionToolsNoAnswer

VG --PerfektesChaos 16:30, 9. Feb. 2026 (CET)

Das geht auch einfacher mit mw-archivedtalk. Habe ich in die Vorlage eingebaut. -- hgzh 19:08, 9. Feb. 2026 (CET)

Etwas ähnliches habe ich mit Spezial:Diff/264131031 für erledigte Löschdiskussionsseiten probiert, das scheint aber nicht zu klappen (siehe zB Wikipedia:Löschkandidaten/9. Februar 2025). Was habe ich da falsch gemacht? VG –IWL04 • 19:50, 9. Feb. 2026 (CET)

Also bei mir ist auf der von dir verlinkten, erledigten LD-Seite nun kein Antwortbutton mehr sichtbar. --Johannnes89 (Diskussion) 20:01, 9. Feb. 2026 (CET)

Stimmt, danke, nach Nulledit bei mir nun auch nicht mehr (gepurged hatte ich davor schon ohne Erfolg). –IWL04 • 20:05, 9. Feb. 2026 (CET)

@ „erledigte Löschdiskussionsseiten“

• Wir verwenden für Archive traditionell die __NONEWSECTIONLINK__ mit __NOEDITSECTION__ kombiniert.
• Das wirkt auf Quelltextbearbeitung genauso wie auf DiscussionTools.
• Es markiert die komplette Seite.

@ mw-archivedtalk

• Soweit ich mich erinnere, fällt damit auch [Abonnieren] und [Abbestellen] flach?

VG --PerfektesChaos 21:17, 9. Feb. 2026 (CET)

Okay, [Abonnieren] ist nach mw-archivedtalk noch da, aber da gab es irgendeinen Pferdefuß. VG --PerfektesChaos 21:25, 9. Feb. 2026 (CET)

Ach ja, die verlinkten Löschkandidaten erlauben noch das [Abonnieren], haben aber sogar schon ARCHIVEDTALK aber kein NONEWSECTIONLINK. Keine Ahnung, was da los ist, die eingebundenen Seiten (unerwünscht: Vorlagennamensraum) sind ein ziemliches Kuddelmuddel, und die Schalterfunktionen sind mal hier, mal dort deklariert.

Ich sehe allerdings gerade in anderen Archiven, dass das [Abonnieren] neuerdings an alle möglichen Archiv-Abschnitte drangehängt wird.

• Das war meiner Erinnerung nach nicht immer so.
• Demnach wäre das ein meldepflichtiger Bug, denn bei ARCHIVEDTALK ist das [Abonnieren] sinnfrei und müsste genauso wie andere DiscussionTools-Funktionen unterdrückt werden.

Heißt aber: Sobald bei archivedtalk das [Abonnieren] wieder korrekt unterdrückt wird, hat die abschnittseröffnende WP:VSW dann auch kein [Abonnieren] mehr; das ist dort jedoch sinnvoll, bloß [Beantworten] ist unerwünscht.

VG --PerfektesChaos 21:49, 9. Feb. 2026 (CET)

Das ist ja dasselbe Problem wie in der LD, wo die Kat-Unterseite als Vorlage eingebunden wird. --Matthiasb – ^{(CallMyCenter)} _{Wikinews ist nebenan!} 00:57, 16. Apr. 2026 (CEST)

{{ChartDirekt}}

Am Beispiel Schweizer Entwicklungszusammenarbeit#Entwicklung der Schweizer Beiträge die Texte zu den Kurven (oben im Chart) kann man waagerecht scrollen. Im Hellmodus ist das okay, den dunkleren Pfeil anklicken, der ausgegraute macht nix. Im Dunkelmodus ist das aber verwirrend, da tut der helle Pfeil nix und man muss den "ausgegrauten" anklicken. Zusätzlich ich noch das "1/2" zwischen den Pfeilchen im Dunkelmodus kaum zu sehen. --Wurgl (Diskussion) 09:05, 14. Feb. 2026 (CET)

Ist das denn nur bei dieser Vorlage? Dann wäre es doch besser, dass in der Vorlagendiskussion zu besprechen?

Es sei denn,

• die Vorlage nutzt global verwendete CSS-Klassen, die sich woanders auch auswirken würden
• oder die in der Vorlagen-Disk erwähnte Extension nutzt globale Farb-Ermittlungs-Funktionen,

die im Darkmode komische Effekte verursachen: Wie ich sehe, sind in den HTML-Knoten path und text die Farben hart codiert. Wie die Vorlage diese Knoten dort aber reinzimmert, weiß ich nicht, dazu kenn ich mich mit der Vorlage (bzw. Vorlagen allgemein) zuwenig aus.

Ich weiß aus eigener Erfahrung, dass selbstdefinierte Farben (wenn nur eines von Schrift und Hintergrund definiert werden) bei Darkmode für die Sichtbarkeit tödlich sind--Hlambert63 (Diskussion) 19:41, 14. Feb. 2026 (CET)

Da wird diese Erweiterung {{chart:…}} aufgerufen und von dort, so vermute ich, kommt das. Daher hab ich das hier reingeschrieben. Eventuell ist das ein Fall für den Phabricator? --Wurgl (Diskussion) 19:48, 14. Feb. 2026 (CET)

begin{math} innerhalb von chem funktioniert nicht mehr

\begin{math} war bis vor einiger Zeit eine Möglichkeit, innerhalb des <chem>-Tags <math>-Sonderzeichen oder -Optionen, wie beschriftete Reaktionspfeile oder Kursivschrift zu nutzen. Seit vielleicht einem halben Jahr, kann auch ein Jahr oder mehr sein, funktioniert begin{math} nicht mehr („Fehler beim Parsen (Unbekannte Funktion „\begin{math}“)“). Es gab nur wenige Artikelseiten, die diese Option überhaupt genutzt haben, und dort hab' ich das nicht mehr funktionierende \begin{math} ersetzt, aber auf der Seite Wikipedia:Richtlinien Chemie/Reaktionsgleichungen#Kursiver Text taucht es noch auf, siehe dort für die Fehlermeldung in Rot und für Formelbeispiele, die die Fehlermeldung auslösen. Ist \begin{math} nur vorübergehend oder für immer außer Betrieb? Im letzteren Fall müsste man die entsprechenden Hinweise auf \begin{math} aus den Richtlinien Chemie entfernen. --Nick B. (Diskussion) 21:28, 16. Feb. 2026 (CET)

Im August 2024 hat es jedenfalls noch funktioniert, wie man auf der Seite Wikipedia:Redaktion Chemie/Archiv/2024/August#Problem mit chem erkennen kann (Die Formeln jetzt in Rot).--Nick B. (Diskussion) 21:35, 20. Feb. 2026 (CET)

Das hier funktioniert:

${\displaystyle {\ce {C(CH3)3+ + H2O ->}}{\mathit {tert}}-{\ce {Bu-OH + H+}}}$

Wie genau soll denn das gewünschte Ergebnis aussehen? @Nick B.: Kanns du die Richtlinien auf Basis der Dokumentation anpassen?--Kallichore (Diskussion) 22:29, 20. Feb. 2026 (CET)

Das Ergebnis soll ungefähr so aussehen (Bindestrich nach tert gehört zum Text und ist daher kürzer als die Striche für Bindungen):

${\displaystyle {\ce {C(CH3)3+ + H2O ->}}tert{\text{-}}{\ce {Bu-OH + H+}}}$

Der Formeltext dafür ist (\mathit nicht nötig, da Kursivschrift in <math> Standard ist):

<math chem>\ce{C(CH3)3+ + H2O ->}tert\text{-}\ce{Bu-OH + H+}</math>

Der Vorschlag ist ein guter Weg, um Kursivschrift darzustellen oder um <math>-Sonderzeichen oder -Funktionalität zu nutzen. Danke dafür. <math chem> ist in der deutschsprachigen Wikipedia nur wenig dokumentiert (nur hier beim VisualEditor kurz erwähnt). Insbesondere wird <math chem> auf der Seite Wikipedia:Richtlinien Chemie/Reaktionsgleichungen nicht genannt. Ich kann vielleicht in den nächsten Tagen mal einen Entwurf dafür machen. Es wird bisher auch selten verwendet, es gibt auf de.wikipedia keine zehn Artikel, die <math chem> verwenden.

Darf ich nochmals zurück zu meiner Ausgangsfrage: ist begin{math} dauerhaft außer Betrieb? Muss man den entsprechenden Hilfetext endgültig löschen? Oder kann begin{math} auch wieder funktionieren? --Nick B. (Diskussion) 07:50, 21. Feb. 2026 (CET)

Meine Vermutung ist, dass dies nie ein offizielles Feature, sondern ein Hack war. Deswegen wurde darauf bei Umstellungen wie dieser hier nicht Rücksicht genommen und dieser Hack ist nun dauerhaft außer Betrieb. Für eine definitive Antwort müssten wir wohl die Entwickler, z.B. durch ein Ticket auf mw:Phabricator, kontaktieren. Oder wir gehen einfach pragmatisch vor: Wenn hier kein Veto kommt, stellen wir auf die funktionierende (und dokumentierte) Lösung um.--Kallichore (Diskussion) 08:28, 21. Feb. 2026 (CET)

Einladung zur Diskussion über die Zukunft des Bearbeitens in den mobilen Wikipedia-Apps

Das Mobile-Apps-Team untersucht, was genau passieren sollte, wenn Benutzer:innen der Apps in einem Artikel auf „Bearbeiten“ tippen, und wir würden uns über Rückmeldungen aus deiner Community freuen. Der Kontext ist unten zusammengefasst und vollständige Informationen findest du auf der Seite zur Zukunft des Bearbeitens in den mobilen Apps. Der Plan ist sicherzustellen, dass App-Nutzer innerhalb der App im mobilen Web-Editor bearbeiten, wo bessere Bearbeitungswerkzeuge zur Verfügung stehen.

Problembeschreibung

Die Wikipedia-Apps wurden ursprünglich als Lesetools entwickelt. Lesefunktionen und App-spezifische Funktionen sind die Hauptmotivation für Benutzer:innen, sie herunterzuladen, und bleiben der treibende Faktor für eine hohe Anbindung von Lesenden. In den letzten Jahren wurden spezielle Bearbeitungsmöglichkeiten in die Wikipedia-Apps integriert, um den Bedürfnissen der Nutzenden gerecht zu werden. Eine wiederkehrende Herausforderung war das Fehlen des visuellen Editors in den Apps, was auf technische Einschränkungen zurückzuführen ist; es würde Jahre dauern, einen eigenen funktionalen WYSIWYG-Editor zu bauen. Das Fehlen des visuellen Editors hat dazu geführt, dass alle, die einen Artikel zum Bearbeiten öffnen, sofort mit Wikitext konfrontiert werden, der Programmiercode ähnelt und viele Neulinge abschreckt, da sie vermuten, dass das Bearbeiten technisches Wissen erfordert. Unsere Studien haben bestätigt, dass das Fehlen des visuellen Editors trotz der Investitionen in Verbesserungen des bestehenden Editors eine Barriere für die Bearbeitung von Artikeln schafft, wenn es keine strukturierten Aufgaben wie vorgeschlagene Bearbeitungen gibt. Zusätzlich sind Community-Räume wie Fragen zur Wikipedia in den Apps schwer auffindbar, da sie außerhalb des Hauptnamenraums liegen.

Kontext: Die Lese-Strategie

Die Wikimedia Foundation konzentriert sich vermehrt auf die Verbesserung der Leseerfahrungen neben dem Bearbeiten, mit dem Ziel, Lesende zu unterstützen, neue Benutzer:innen anzuziehen und anzubinden. Wir können uns nicht mehr darauf verlassen, dass uns Lesende über Suchmaschinen finden, wie wir es gewohnt sind, und müssen neue Wege finden, Lesende zu gewinnen, die immer wieder zu den Wikis zurückkehren – und die in Zukunft auch Beitragende werden könnten.

Im Rahmen dieser Ausrichtung werden die Apps vor allem als gute Leseerfahrung für aktive Lesende entwickelt, wobei mehr Wert auf Funktionen wie personalisierte Empfehlungen aufgrund lokaler Gerätedaten, tägliche Beteiligungsmöglichkeiten für Lesende und größere Verbindungen zu Inhalten gelegt wird.

Gleichzeitig werden die Bearbeitungswerkzeuge im Web zunehmend verbessert. Dazu gehören Funktionen wie der Edit-Check im VisualEditor, Bearbeitungsvorschläge und die Neulings-Startseite, die darauf abzielen, das Bearbeiten zugänglicher zu machen und Beitragende besser zu unterstützen.

Dieser Kontext ist für die Gewinnung von Beitragenden wichtig. Die Apps ziehen jedes Jahr neue Lesende an, binden sie gut an und es gibt Pläne, die Sichtbarkeit der Apps zu erhöhen. Viele Beitragende beginnen mit dem Bearbeiten durch Korrektur kleiner Fehler beim schnellen Lesen – wenn sich diese impulsiven Momente innerhalb der App ergeben und Neulinge auf Wikitext ohne die Option des visuellen Editors stoßen, sind sie möglicherweise entmutigt, bevor sie überhaupt eine Chance hatten, es zu versuchen. Die Reader- und Contributor-Teams der Wikimedia Foundation arbeiten zusammen an diesem Problem, und die Einführung des Bearbeitens ist in den Apps besonders wichtig, da ein großer Teil der Benutzer:innen sie täglich besucht, und tägliche Benutzer:innen am wahrscheinlichsten eine Bearbeitung versuchen – zum Beispiel 3 % der Lesenden wurden neue Beitragende mit nicht zurückgesetzten Bearbeitungen, nachdem sie durch die neue Funktion des Aktivitäts-Tabs in der App erfahren hatten, dass sie bearbeiten können.

Worüber wir nachdenken

Das Team erforscht Möglichkeiten, wie Benutzer:innen innerhalb der App das Bearbeiten in der mobilen Webversion fortsetzen können, wo der visuelle Editor und andere vollwertige Werkzeuge zur Verfügung stehen. Es gibt offene Fragen, wie das effektiv umgesetzt werden kann.

Fragen, zu denen das Team gerne Rückmeldungen hätte

• Welche sind die wichtigsten Bearbeitungsroutinen oder Community-Räume, die von der App aus zugänglich sein müssen (auch über eine Weiterleitung)?
• Sollten die mobilen Apps den eigenen Wikitext-Editor und die Bearbeitungsvorschläge vollständig entfernen, wenn der Editor der mobilen Webversion von der App aus zugänglich ist?
• Für Beitragende, die Bearbeiten in der App versucht haben: Wann war die Erfahrung mangelhaft und würde der Zugriff auf den visuellen Editor / die mobile Webversion daran etwas ändern?
• Gibt es Aspekte des Wechsels vom Editor der App zum Editor der mobilen Webversion, die besonders wichtig sind?
• Wie sollte sich dieser Wechsel anfühlen? Ein Hinweis, eine Weiterleitung, eine eingebettete Web-Erfahrung, eine deutliche Erklärung, wohin Benutzer:innen geleitet werden und warum?
• Für Beitragende, die Neulinge begleiten: Wie oft ist die App die erste Bearbeitungsumgebung und welche Probleme ergeben sich daraus?

Die gesamte Diskussion befindet sich auf der Diskussionseite. Auch Rückmeldungen zu diesem Beitrag sind willkommen.

--ARamadan-WMF (Diskussion) 14:29, 17. Mär. 2026 (CET)

Die Projektseite wird in Kürze in deiner Sprache verfügbar sein. --ARamadan-WMF (Diskussion) 20:50, 17. Mär. 2026 (CET)

Viel Leerraum

Ich hoffe ich bin hier richtig. Ich würde gerne bei dem Artikel Nationalliga A (Elektrorollstuhl-Hockey) 2024/25 die Spieltage nebeneinander oder im 2er Block. Ich finde es hat auf der rechten Seiten zuviel Leerraum. Ich habe jetzt schon einiges probiert, aber komme da nicht weiter. --Ambroix (Diskussion) 11:59, 3. Apr. 2026 (CEST)

Der Artikel Turn-Weltmeisterschaften 2017 mit dem Abschnitt Turn-Weltmeisterschaften_2017#Gerätefinals_Frauen könnte hier interessant sein (Verwendungn von "div"). Allerdings zeigt die Betrachtung dieses Artikels in der Wikipedia-App auch Schattenseiten: Die Anpassung an breite Bildschirme erschwert das Lesen auf Smartphones.--Kallichore (Diskussion) 16:14, 3. Apr. 2026 (CEST)

Für Nachbildung der Darstellung auf Smartphones gibt es eine Hilfe:

1. Entwicklertools starten (Im Firefox: Menü --> Werkzeuge --> Werkzeuge für Web-Entwickler; meist mit Ctrl-Shift-I);
2. auf Reiter „Inspektor“ gehen: da ist rechts oben ein Symbol „Bildschirmgrößen testen“, da wird (u.a.) eine Smartphone-Darstelling simuliert.

Die von Dir Kallichore genannte Seite wird dann so dargestellt, dass die Tabellen nicht nebeneinander, sondern untereinander kommen. Wem was besser gefällt, ist aber IMHO Geschmackssache (ob man lieber runterwischt oder auch quer und dann runter).

Edit: Ich weiß aber nicht, ob die WP-Inhalte für die App anders aufbereitet werden als für Webbrowser.

--Hlambert63 (Diskussion) 17:40, 3. Apr. 2026 (CEST)

Hat mal geklappt. Danke für den Tipp. Ich schaue mir das nachher noch auf dem Handy an. Finde im 4er Block sieht es übersichtlicher aus. --Ambroix (Diskussion) 21:48, 3. Apr. 2026 (CEST)

Sieht sowohl am Desktop, als auch im mobilen Browser und in der App gut aus. --Johannnes89 (Diskussion) 13:40, 22. Okt. 2026 (CEST)

Action Required: Update templates/modules for electoral maps (Migrating from P1846 to P14226)

Hello everyone,

This is a notice regarding an ongoing data migration on Wikidata that may affect your election-related templates and Lua modules (such as Module:Itemgroup/list).

The Change:
Currently, many templates pull electoral maps from Wikidata using the property P1846, combined with the qualifier P180: Q19571328.

We are migrating this data (across roughly 4,000 items) to a newly created, dedicated property: P14226.

What You Need To Do:
To ensure your templates and infoboxes do not break or lose their maps, please update your local code to fetch data from P14226 instead of the old P1846 + P180 structure. A list of pages was generated using Wikimedia Global Search.

Deadline:
We are temporarily retaining the old data on P1846 to allow for a smooth transition. However, to complete the data cleanup on Wikidata, the old P1846 statements will be removed after May 1, 2026. Please update your modules and templates before this date to prevent any disruption to your wiki's election articles.

Let us know if you have any questions or need assistance with the query logic. Thank you for your help! ZI Jony using MediaWiki message delivery (Diskussion) 19:09, 3. Apr. 2026 (CEST)

Problem mit Verlinkung von mehrbändig sortierten Werken im Internet-archive

Bitte folgendes Problem beheben. Im Visualeditor wird, wenn man einen normalen Archive-Link einfügt dieser Verkürzt. Das ist ein Problem bei mehrbändig sortierten Werken: Beispiel: https://archive.org/details/jacoby-die-fragmente/Jacoby%2C%20Die%20Fragmente%20der%20griechischen%20Historiker%201/FGrH%202A/page/190/mode/1up

wird zu:

Beispiel

iarchive:jacoby-die-fragmente/Jacoby, Die Fragmente der griechischen Historiker 1/FGrH 2A/page/190/mode/1up

und damit unbenutzbar. Bitte schnellstmöglich lösen Danke --~2026-21925-42 (Diskussion) 12:00, 9. Apr. 2026 (CEST)

Du kannst ja die Vorlage:archive.org verwenden

Aus der Ptolemaeergeschichte – Internet Archive

das geht einwandfrei. --Liebe Grüße, Lómelinde Diskussion 12:28, 9. Apr. 2026 (CEST)

Die Vorlage ist denkbar hässlich (Internet Archive wird WÖRTLICH (¿??!?) genannt) dazu kommt, dass das natürlich auch ohne Vorlage funktioniert muss. --~2026-21925-42 (Diskussion) 12:44, 9. Apr. 2026 (CEST)

Aber warum fügst du Links mit dem Pseudo-Interwikilink iarchive ein? Das ist doch nicht Standard und erfordert Insiderwissen. --Magnus (Diskussion) 12:50, 9. Apr. 2026 (CEST)

Unfug. Bitte anliegen genau lesen. Der Visual-Editor wandelt das automatisch um. Das ist ja das problem. --~2026-21925-42 (Diskussion) 12:55, 9. Apr. 2026 (CEST)

Im Übrigen möchten wir, dass bei jeder externen Verlinkung durch Draufgucken klar wird, auf welche Website das führen würde, und ob das eine problematische oder gute oder völlig unerwünschte Website wäre. Deshalb ist oben unser Artikel über Internet Archive verlinkt, damit alle nachgucken können, wer das sein mag. VG --PerfektesChaos 12:56, 9. Apr. 2026 (CEST)

Das ist nicht viel mehr als ein privater Wunsch. In der Redaktion Geschichte oder Altertum wird das sicherlich nicht auf Gegenliebe stoßen und entsprechend selten wird das auch verwendet. --~2026-21925-42 (Diskussion) 13:02, 9. Apr. 2026 (CEST)

Wirde an dem Problem inzwischen gearbeitet. --~2026-28657-08 (Diskussion) 14:26, 13. Mai 2026 (CEST)

Hm, was denn jetzt, Quelltexteditor (dein Ausgangspost) oder Visual Editor? Der Quelltexteditor macht bei mir keine solchen Sachen. --Magnus (Diskussion) 13:01, 9. Apr. 2026 (CEST)

Oh, sorry hast du recht. VE ist gemeint. Ich änder das quick. --~2026-21925-42 (Diskussion) 13:03, 9. Apr. 2026 (CEST)

Captcha-Hinweis

Kopiert von WP:MW/Ä

Danke für den Hinweis --PerfektesChaos 15:46, 22. Apr. 2026 (CEST)

Ist mit Blick auf WP:NEU#26. Mai (hCaptcha) vermutlich nun egal? --Johannnes89 (Diskussion) 16:18, 4. Jun. 2026 (CEST)

Doku der Vorlage Wikipedia-Suche und Parsoid

Das erste Beispiel in Vorlage:Wikipedia-Suche/Doku erzeugt mit Parsoid in der Darstellung einen Fehler, der mit dem nun alten Parser (Legacy-Parser) nicht auftritt:

• {{Wikipedia-Suche|1=hastemplate:Vorlage insource:/"{<nowiki/>{Vorlage"/}} (nach Hinweis zu Syntaxhighlight geändert) ergibt mit dem Legacy-P.: hastemplate:Vorlage insource:/"{{Vorlage"/, was die erwartete Anzeige ist.
• Mit Parsoid wird anstelle des <nowiki/> eine Zeichenfolge '"`UNIQ--nowiki-00000000-QINU`"' mit Steuerzeichen x07F davor und danach angezeigt, was die Darstellung hastemplate:Vorlage insource:/"{'"`UNIQ--nowiki-00000000-QINU`"'{Vorlage"/ ergibt.

Meine Frage ist jetzt: Sollen wir das als Fehler des neuen Parsers melden oder eher die Doku anpassen? Beachte, dass das Beispiel sich auf den etwas weiter oben stehenden Satz „Andere Zeichen sind nur in Kombinationen kritisch […]“ bezieht. — Speravir – 23:33, 27. Apr. 2026 (CEST)

Sieht so aus, als ob man derzeit einige mögliche Varianten auf der Spielwiese austesten muss, weil die Vorschau nicht ausreichend ist. — Speravir – 23:37, 27. Apr. 2026 (CEST)

Ich bin zu müde, um mir durchzulesen und zu verstehen, welches nowiki du eigentlich meinst, weil im Suchausdruck ja auch noch ein nowiki drinsteht.

Der heutige Gold-Standard, seit es verfügbar ist, wäre für eine Vorlagen-Doku: <syntaxhighlight lang="wikitext">

• Da kann dann die Original-Syntax 1:1 reinkopiert werden, und auch Entities werden so dargestellt wie sie angegeben sind.
• Alle historischen Bastelarbeiten, auch Smartphone-ungeeignete Layout-Tabellen, sind veraltet.
• Für einen konstanten Text sind keine Escape-nowiki-Entity-Umgehungen mehr erforderlich.

VG --PerfektesChaos 01:13, 28. Apr. 2026 (CEST)

Ach ja, stimmt. Ich hab das in der Vorlagendoku und hier oben geändert. Wie nicht anders zu erwarten, bleibt der Fehler aber trotzdem bestehen. — Speravir – 02:36, 28. Apr. 2026 (CEST)

Limitierte Vorschaubildgrößen und Nutzerstile, Nutzerskripte

Nachdem mich Lómelinde mit ihrer Frage in den FzW zu einem Anzeigeproblem mit Symbolbildern im Wikieditor (Iconmopser) auf die Idee gebracht hat, habe ich mal nach Stilen und Skripten gesucht, welche Links zu solchen Vorschaubildern enthalten könnten, die nun angepasst werden müssten wegen phab:T414805, siehe dazu auch mw:Common thumbnail sizes. Wie sollte man vorgehen – alle betroffenen Benutzer informieren oder nur solche, die kürzlich aktiv waren, aber welche Zeitspanne gilt dann als aktiv? Es stellt sich heraus, dass davon auch einige Helferlein betroffen sind. Auch die zwei Helferlein-Skripte MediaWiki:Gadget-OpenStreetMap.js und MediaWiki:Gadget-PB2.js enthalten solch einen Link, aber das letztere war von Anfang an schon auf eine heutige Standardgröße festgelegt, das erstere wurde kürzlich dahingehend abgeändert.

Perhelion und Schnark sind zwei bekannte inaktive Nutzer mit viel genutzten Skripten, bei denen nicht davon auszugehen ist, dass sie selbst eine Aktualisierung vornehmen, PDD wäre ein betroffener aktiver Nutzer, ebenfalls mit von andern genutzten Skripten.

Suchanfragen, die auch Treffer enthalten, wo keine Änderung (mehr) notwendig ist:

• Suche nach Skripten (Stand jetzt 124 Funde).
• Suche nach Stilen (Stand jetzt 315 Funde).

— Speravir – 01:34, 28. Apr. 2026 (CEST)

Bilder laden im Firefox nur sporadisch

Bilder vom Commons eingebettet auf WP-Seiten laden oft nicht, manchmal aber doch. Von mehreren Bildern auf einer Seite laden manche, andere nicht. Manche erscheinen nach einiger Zeit, andere sind hartnäckig verschwunden.

Es hat mit uMatrix in meinem FF 150 zu tun. Schalte ich das Add-on aus, laden die Bilder wie gewohnt. Verhalten erst seit ungefähr 3 Tagen. Fehlermeldung in der Konsole lautet in etwa:

Referrer Policy: Die weniger eingeschränkte Referrer Policy "origin-when-cross-origin" für die Website-übergreifende Anfrage wird ignoriert: https://upload.wikimedia.org/wikipedia/commons/thumb/1/1a/Oberfucha_Kapelle.jpg/250px-Oberfucha_Kapelle.jpg 250px-Oberfucha_Kapelle.jpg

Die Ressource unter "https://upload.wikimedia.org/wikipedia/commons/thumb/1/1a/Oberfucha_Kapelle.jpg/250px-Oberfucha_Kapelle.jpg" wurde durch OpaqueResponseBlocking blockiert. Grund: "after sniff: status code is not in allowed range".

Auf Commons habe ich kein Problem mit der Anzeige. Aber im Mediaviewer von WP:de aus (Leider kann die Datei nicht angezeigt werden). Genauso funktioniert https://de.wikipedia.org/wiki/Datei:Oberfucha_Kapelle.jpg nicht. Ich lese das allerdings als Folgefehler. Mich verwirrt die Zufälligkeit.

OpaqueResponseBlocking in about:config auf false zu setzen mag ich nicht, hat ja einen Sinn. Testweise probiert, das löst das Problem eh nicht.
Die Tage habe ich was in Richtung Parsoid umgestellt, das Verhalten ist allerdings vom Parser unabhängig.

Hat jemand von euch eine Idee, was der Grund dahinter sein könnte? Wo ich weitersuchen könnte?

lg --Herzi Pinki (Diskussion) 18:44, 29. Apr. 2026 (CEST)

Das ist der Request für https://de.wikipedia.org/wiki/Datei:Oberfucha_Kapelle.jpg

GET
https://upload.wikimedia.org/wikipedia/commons/thumb/1/1a/Oberfucha_Kapelle.jpg/960px-Oberfucha_Kapelle.jpg
NS_BINDING_ABORTED

	
GET
	https://upload.wikimedia.org/wikipedia/commons/thumb/1/1a/Oberfucha_Kapelle.jpg/960px-Oberfucha_Kapelle.jpg
Status
429
VersionHTTP/2
Übertragen944 B (0 B Größe)
Referrer Policystrict-origin-when-cross-origin
Anfrage-PrioritätLow
DNS-AuflösungSystem

    	
    access-control-allow-origin
    	*
    access-control-expose-headers
    	Age, Date, Content-Length, Content-Range, X-Content-Duration, X-Cache
    content-length
    	1991
    content-type
    	text/html; charset=utf-8
    date
    	Wed, 29 Apr 2026 16:50:04 GMT
    nel
    	{ "report_to": "wm_nel", "max_age": 604800, "failure_fraction": 0.05, "success_fraction": 0.0}
    report-to
    	{ "group": "wm_nel", "max_age": 604800, "endpoints": [{ "url": "https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0" }] }
    retry-after
    	600
    server
    	Varnish
    server-timing
    	cache;desc="int-front", host;desc="cp3075"
    strict-transport-security
    	max-age=106384710; includeSubDomains; preload
    timing-allow-origin
    	*
    x-analytics
    	
    x-cache
    	cp3075 int
    x-cache-status
    	int-front
    x-client-ip
    	2001:871:25f:6708:e156:85c0:b6ed:cf43
    X-Firefox-Spdy
    	h2
    x-request-id
    	66fd8942-5571-4fb0-9db1-8a8c080917c2
    	
    Accept
    	image/avif,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5
    Accept-Encoding
    	gzip, deflate, br, zstd
    Accept-Language
    	de,en-US;q=0.9,en;q=0.8
    Connection
    	keep-alive
    Cookie
    	WMF-Uniq=...
    Host
    	upload.wikimedia.org
    Priority
    	u=5, i
    Referer
    	https://upload.wikimedia.org/
    Sec-Fetch-Dest
    	image
    Sec-Fetch-Mode
    	no-cors
    Sec-Fetch-Site
    	cross-site
    Sec-Fetch-Storage-Access
    	none
    TE
    	trailers
    User-Agent
    	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:150.0) Gecko/20100101 Firefox/150.0

--Herzi Pinki (Diskussion) 18:57, 29. Apr. 2026 (CEST)

@ASarabadani (WMF) fyi, klingt ähnlich wie en:WP:VPT#"429 Too many requests". --Johannes Richter (WMDE) (Diskussion) 19:09, 29. Apr. 2026 (CEST)

Ja, ich denke auch. Gib mir ein bisschen Zeit um zu recherchieren. --ASarabadani (WMF) (Diskussion) 19:21, 29. Apr. 2026 (CEST)

Ich hab das Problem gefunden. Die Referer-Header ("https://upload.wikimedia.org/") ist nicht echt. Mit normalen Anwendungen (z.B. Firefox oder Chrome) ist die Referer-Header de.wikipedia.org (oder en.wikipedia.org usw.). @Herzi Pinki Benutzen Sie etwas, dass die Referer-Header veranderen kann? --ASarabadani (WMF) (Diskussion) 19:56, 29. Apr. 2026 (CEST)

danke @ASarabadani (WMF): , das ist ein Ansatz. gerne weiter per du :-)

das sind meiner FF Einstellungen bzgl refer(r)er:

network.http.referer.XOriginPolicy	0		
network.http.referer.XOriginTrimmingPolicy	0		
network.http.referer.defaultPolicy	2		
network.http.referer.defaultPolicy.pbmode	2		
network.http.referer.defaultPolicy.trackers	2		
network.http.referer.defaultPolicy.trackers.pbmode	2		
network.http.referer.disallowCrossSiteRelaxingDefault	true		
network.http.referer.disallowCrossSiteRelaxingDefault.pbmode	true		
network.http.referer.disallowCrossSiteRelaxingDefault.pbmode.top_navigation	true		
network.http.referer.disallowCrossSiteRelaxingDefault.top_navigation	false		
network.http.referer.hideOnionSource	true		
network.http.referer.referrerLengthLimit	4096		
network.http.referer.sendFromRefresh	true		
network.http.referer.spoofSource	false		
network.http.referer.trimmingPolicy	0		
network.http.sendRefererHeader	2

nix davor von der Standardeinstellung abweichend. Siehst du da was komisches? Ich habe sowohl FF (Verbesserter Tracking-Schutz ist aktiviert) als auch uMatrix auf möglichst hohe Sicherheit eingestellt, wüsste aber nicht, was da konkret das Problem sein könnte. Was hat sich alles geändert bei mir die letzten Tage: Update auf FF 150, Umstellung auf Parsoid, Einführung serverseitiger Quotas. Sehe gerade es gibt einen neuen FF Update, melde mich nochmals mit dem Status. lg --Herzi Pinki (Diskussion) 20:23, 29. Apr. 2026 (CEST)

FF 150.0.1. und das Problem ist weg. danke für dein Kümmern. aktuell offensichtlich erledigt. lg --Herzi Pinki (Diskussion) 20:26, 29. Apr. 2026 (CEST)

@Herzi Pinki Das Grund ist uMatrix. Anderen Leuten, die diese Anwendung installieren, haben auch das Problem gemeldet. Wir haben die Regeln modifiziert um die Fehlern zu reduzieren aber es kann noch passieren (aber sehr weniger Bilder wurden blockiert). --ASarabadani (WMF) (Diskussion) 21:03, 29. Apr. 2026 (CEST)

@ASarabadani (WMF): ok, dann war das nur Koinzidenz mit dem Update. lg --Herzi Pinki (Diskussion) 22:46, 29. Apr. 2026 (CEST)

DOM-img nodes in js zu svg auf Commons

(Im Anschluss an #Bilder laden im Firefox nur sporadisch)

Habe noch ein Problem mit den urls in Benutzer:Herzi Pinki/GeoDECpopup.js:

			copybutton.src = "//upload.wikimedia.org/wikipedia/commons/thumb/a/a2/Edit-copy.svg/30px-Edit-copy.svg.png";

das schlägt auch fehl. Ähnliche Konstrukte gibt es mehrfach: . Bevor ich weitersuche, gibt es dafür einen good citizen approach, um den url für das Generat aus einem svg zu bekommen (um in javascript ein DOM-Element mit dem svg zu erzeugen)? https://www.mediawiki.org/w/api.php?action=query&titles=File:Erioll_world.svg&prop=imageinfo&iiprop=url hilft auch nicht weiter. lg --Herzi Pinki (Diskussion) 22:16, 29. Apr. 2026 (CEST)

@TMg: Weil dein Besen aus Benutzer:TMg/autoFormatter.js auch seit ein paar Tagen verschwunden ist, das vermutlich das identische Problem ist und du Ahnung hast. lg --Herzi Pinki (Diskussion) 22:46, 29. Apr. 2026 (CEST)

@Herzi Pinki: 30px gibt es als Thumbnail wohl nicht mehr, siehe mw:Common thumbnail sizes --Doc Taxon (Diskussion) 22:52, 29. Apr. 2026 (CEST)

Danke, so einfach kann es sein , wenn man nicht so kompliziert denkt. lg --Herzi Pinki (Diskussion) 23:01, 29. Apr. 2026 (CEST)

Gern, --Doc Taxon (Diskussion) 23:26, 29. Apr. 2026 (CEST)

@Herzi Pinki, Doc Taxon: Siehe auch #Limitierte Vorschaubildgrößen und Nutzerstile, Nutzerskripte. — Speravir – 02:02, 30. Apr. 2026 (CEST)

@TMg:, ich vermute mal, du hast den Wink mit dem Zaunpfahl () und Benutzer:TMg/autoFormatter.js nicht registriert. lg --Herzi Pinki (Diskussion) 11:20, 4. Mai 2026 (CEST)

Fehlerhafte Bearbeiten-Verlinkung auf LD-Seiten

Hallo! Auf LD-Seiten lassen sich die eingebundenen Kategoriediskussionen nicht mehr mit "Bearbeiten"-Link aufrufen. Auch die Beantworten-Funktion der Discussion-Tools führen nicht an den gewünschten Ort. Ich bin der Meinung, dass der Fehler erst seit dem neuen Seitenkopf auf LD (Info an @Antonsusi) eingetreten ist, bin ich mir aber jetzt wirklich nicht sicher. Könnte das jemand bitte checken? @Lómelinde: vielleicht weißt Du auch eine Lösung? Danke Euch, --Doc Taxon (Diskussion) 12:13, 5. Mai 2026 (CEST)

@Doc Taxon: Welche LD-Seiten meinst du? Es gibt Seiten mit offenen Kategorie- und offenen sonstigen Diskussionen, Seiten mit nur noch offenen Kategoriediskussionen und komplett erledigte Seiten. ÅñŧóñŜûŝî (Ð) 20:01, 5. Mai 2026 (CEST)

Selbst auf der noch leeren Seite Wikipedia:Löschkandidaten/6._Mai_2026 kommt nach einen Klick auf "Quelltext bearbeiten" rechts neben "Kategorien:

Du versuchst den nicht vorhandenen Abschnitt T-1 zu bearbeiten. Möglicherweise hat ein anderer Benutzer inzwischen Abschnitte entfernt. Bitte gehe zurück zur Seite „Wikipedia:Löschkandidaten/!Seitenkopf“ und versuche es erneut.

Direkt auf "Kategorien" klicken funktioniert hingegen und führt zu Wikipedia:WikiProjekt Kategorien/Diskussionen/2026/Mai/6.--Kallichore (Diskussion) 20:10, 5. Mai 2026 (CEST)

Parsoid ist Schuld: phab:T422291 --Johannnes89 (Diskussion) 20:20, 5. Mai 2026 (CEST)

@Doc Taxon: Wenn die allgemeinen LDs erledigt sind und ein Admin die Seite mit erl=~~~~ abhakt, dann verschwinden die Bearbeiten-Links, weil __NOEDITSECTION__ eingebunden wird. Das ist für die Seite auch eigentlich sinnvoll, weil die "echten LDs" nicht mehr angefasst werden sollten. Es fehlt noch eine Umgehung für unerledigte Kat-Diskussionen. Ich ergänze mal einen Bearbeiten-Button für die Kat-D-Seite. Die anderen Fälle sind nicht mein Werk. Das ist ein großer Bug, der auch die Abschnitts-Edits der Vorlagendokus betrifft. ÅñŧóñŜûŝî (Ð) 20:53, 5. Mai 2026 (CEST)

Danke für den Button --Doc Taxon (Diskussion) 21:55, 5. Mai 2026 (CEST)

@Johannnes89: Ich denke mal, dass das auch T259824 betrifft, oder? --Doc Taxon (Diskussion) 22:01, 5. Mai 2026 (CEST)

Jap, scheinen mir recht ähnlich zu sein. --Johannnes89 (Diskussion) 23:26, 5. Mai 2026 (CEST)

Der Fehler ist auch auf aktuellen Löschdiskusssionseiten immer noch vorhanden. --Bahnmoeller (Diskussion) 14:56, 9. Jun. 2026 (CEST)

Einfach zum Legacy-Parser zurückwechseln und ein sorgenfreies Leben genießen. Die Entwickler*innen haben einen völlig unfertigen neuen Parser hingerotzt und kümmern sich jetzt wochenlang nicht um dringende Fehlerbehebungen. Das ist einfach frech. -- Chaddy · D 15:24, 9. Jun. 2026 (CEST)

Wie war das nochmal mit dem Übersetzungstool? Ist nicht wirklich etwas neues, dass etwas unfertiges auf das Wikiversum losgelassen wird udn sich dann nicht um Fehlerbeseitigung gekümmert wird. --Ad^tonko 14:51, 14. Jun. 2026 (CEST)

Ja, leider -- Chaddy · D 14:56, 14. Jun. 2026 (CEST)

Verifizierungscodes

Bei der Anmeldung wird jetzt ein Verizifierungscode gewünscht. Der/die übermittelten werden bei der Eingabe als "Ungültig " beantwortet. Mein Konto "Dellstedt" existiert seit 2017. Wo liegt der Fehler? --Dellstedt (Diskussion) 17:23, 9. Mai 2026 (CEST)

@Dellstedt: Aber anscheinend warst Du ja doch angemeldet, um diesen Eintrag hier zu bringen. Ließ sich das Verifizierungscode-Dings irgendwie umgehen oder wie konntest Du Dich anmelden? WMF schraubt die letzten Tage irgendwas an den Anmeldeprotokollen rum, denke dass das daher kommt. --Doc Taxon (Diskussion) 11:01, 10. Mai 2026 (CEST)

Es geht wohl um EmailAuth – bei Problemen am besten an cawikimedia.org wenden. Vermeiden kann man die Codes, wenn man 2FA aktiviert oder wenn man seine Cookies nicht löscht. --Johannnes89 (Diskussion) 16:21, 4. Jun. 2026 (CEST)

markblocked-Script arbeitet nicht mehr auf allen Seiten

Hi, ich wurde neulich darauf aufmerksam gemacht, dass Benutzer:Schniggendiller/markblocked.js nicht mehr richtig arbeitet. Das Script streicht Verlinkungen auf Benutzernamen gesperrter Benutzer durch. Das tut es jetzt aber nur noch auf Spezialseiten wie Spezial:Log/block oder Spezial:Liste der Sperren, nicht aber auf „normalen“ Seiten wie der VM. Ich hatte zuerst vermutet (und iirc auch per Test bestätigt), dass es am neuen Parser liegt. Komischerweise kann ich das jetzt nicht mehr bestätigen *kopfkratz*
Schaue ich auf einer Seite, auf der das Script nicht arbeitet in die Firefox-Fehlerkonsole, bekomme ich haufenweise Meldungen, aber die einzige rote (und wohl auch einzige, die sich auf markblocked bezieht) lautet: „Die Ressource von "https://de.wikipedia.org/w/index.php?title=Benutzer:Schniggendiller/MessageNames&Monobook.js&action=raw&ctype=text/javascript" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). [Weitere Informationen]“. Auf der angegebenen Mozilla-Seite verstehe ich fast nur Bahnhof. Das Seiteninhaltsmodell ist jedenfalls korrekt auf JavaScript gesetzt.
Kann mir jemand sagen, was ich am Script ändern muss? Gruß --Schniggendiller Diskussion 09:47, 10. Mai 2026 (CEST)

Nachtrag:
Ich muss was korrigieren (zu viele Tabs offen): Die Aussage: „einzige, die sich auf markblocked bezieht“ bezog sich darauf, dass in der rechten … hm … Spalte markblocked.js steht. Aber das ist nur der Fall, wenn ich die Konsole auf der markblocked-Seite selbst öffne. Auf einer Seite, auf der das Script nicht funktioniert, verweist an der Stelle auf index.php.
So oder so frage ich mich, was Benutzer:Schniggendiller/MessageNames&Monobook.js damit zu tun haben soll. Das Ding funzt zwar auch nicht, aber schon seit Jahren nicht, und es ist auch nur in meiner common.js eingebunden, nicht aber bei Orci, der mich auf den Fehler bei marbkblocked aufmerksam machte. Verwirrt: --Schniggendiller Diskussion 09:59, 10. Mai 2026 (CEST)

Also, wenn ich auf MessageNames&Monobook.js gucke, stößt mir sofort das & auf.

• Wenn du das von irgendwoher lädst-z-d-zz [gut dass ich das nur schreiben und nicht aussprechen muss], dann muss das & durch %26 ersetzt werden.
• Die beanstandete URL sagt:
  • index.php
  • ?title=Benutzer:Schniggendiller/MessageNames
  • &Monobook.js
  • &action=raw
  • &ctype=text/javascript
• Je nachdem, wie die URL-Auswertung grad drauf ist, ignoriert sie dann das &ctype=text/javascript und liefert den Standard "text/html".

Benutzer:Schniggendiller/markblocked.js ist im Stil der 2000er geschrieben und enthält dutzendweise prolematische Programmierpraktiken.

• Müsste im 2020er Stil neu gemacht werden; Muster für die Gesamtstruktur unter en:User:PerfektesChaos/js aufzufinden.
• So wie es ist, kann ich keinen speziellen Grund für Hänger identifizieren; nicht nachvollziehbar.
• case 'submit': jibbet nicht mehr, ist bei edit mit bei.
• Es fehlen alle Semikolonse. Mag heute was anders interpretiert werden.
• Insbesondere ist das Dingens aber nicht gekapselt, alle Funktionen spielen sich im globalen Namensraum ab, mag andere irgendwann wirkende Skripte geben, die gleichnamige Funktionen in den globalen Namensraum blasen. So kann ich nicht arbeiten.
• Nach einer Totalsanierung müssten die CSS-Selektoren Stück für Stück nachgeprüft werden. Wenn das mit altem/neuem Parser zu tun hätte, gibt es halt in Skins und Seitengenerierung diese Selektoren nicht mehr.

VG --PerfektesChaos 11:24, 10. Mai 2026 (CEST)

Ach, und du erwartest offensichtlich, dass URL mit / beginnen.

• War früher so, als wir noch alternativ mit http oder https betrieben werden konnten.
• Der neue Parser bildet zurzeit URL mit https:// – bissel länger als nötig, schön für auf Platte gespeicherte HTML, aber die Browser ergänzen bei [Seite speichern] die relativen URL aus der aktuellen Tab-URL.
• Müsste flexibel und robust gehandhabt werden, je nachdem was grad geliefert wird.

VG --PerfektesChaos 11:38, 10. Mai 2026 (CEST)

ref-Fehler

Hallo, Ihr Lieben!

Seit einiger Zeit ist die Bearbeitung von ref-Fehlern erheblich schwieriger geworden. Beispiel: es fehlt ein schließendes ref-tag also </ref>. Das wurde früher -so bilde ich mir das ein- im Artikel in Rotschrift angezeigt, jetzt nicht mehr. Man muss das dann mühevoll suchen. So zum Beispiel im Artikel Händlerbund. Viele Grüße, --ÖPNV-Fahrgast (Diskussion) 20:07, 10. Mai 2026 (CEST)

Das Migrationswerkzeug (bei den Werkzeugen zu finden) ist hier nützlich, dort wird links die Ansicht mit dem "Legacy Parser" gezeigt (Beispiel).--Kallichore (Diskussion) 20:42, 10. Mai 2026 (CEST)

Danke, hat weitergeholfen. Aber ob auch andere Autoren diese Möglichkeit entdecken? Grüße, --ÖPNV-Fahrgast (Diskussion) 21:54, 10. Mai 2026 (CEST)

Beim Artikel Wahl zum 22. Deutschen Bundestag nützt auch ein Umschalten auf "Legacy Parser" oder das Anhängen von
?useparsoid=0 nichts. Ich kann die Fehlerstelle nicht finden. Ich komme zur Liste, indem ich "Referenzfehler" in das Suchfeld eingebe, nicht über die Kategorie Wartung. Angezeigt wird "Ungültiges <ref>-Tag; kein Text angegeben für Einzelnachweis mit dem…" dann ist Schluß. --ÖPNV-Fahrgast (Diskussion) 22:47, 10. Mai 2026 (CEST)

In Wahl zum 22. Deutschen Bundestag kann ich keine Fehlermeldung und keinen Fehler sehen (mit Benutzer:PerfektesChaos/js/remindErrorMessages). In der eingespeisten Wahl zum 22. Deutschen Bundestag/Umfragen und Prognosen habe ich <ref name="INSA"></ref> zu <ref name="INSA" /> geändert. Hilft das?

Was ist gemeint mit: Ich komme zur Liste, indem ich "Referenzfehler" in das Suchfeld eingebe?

Gruß, --Wi-luc-ky (Diskussion) 01:06, 11. Mai 2026 (CEST)

Hallo Wi-luc-ky,

wenn ich Lust auf ref-Fehlerbeseitigung habe, dann rufe ich nicht die Wartungskategorie (Kategorie:Wikipedia:Seite mit Einzelnachweisfehlern) auf, sondern gehe ganz oben in das Suchfeld (neben dem Wiki-Logo, vorbelegt mit "Wikipedia durchsuchen") und gebe dort "Referenzfehler" ein. Dann werden mir die betroffenen Seiten angezeigt. Das habe ich mir irgendwann so angewöhnt. Die Auflistung von Wahl zum 22. Deutschen Bundestag ist übrigens jetzt weg. Was mich wundert: Die letzte Änderung war am 22. März 2026, warum erschien der Artikel plötzlich in der Fehlerliste? Weitere Fragen: gerne!

VG, --ÖPNV-Fahrgast (Diskussion) 20:47, 11. Mai 2026 (CEST)

Das ist doch der Punkt – im von dir genannten Artikel war kein Einzelnachweisfehler, sondern im kürzlich bearbeiteten Artikel Wahl zum 22. Deutschen Bundestag/Umfragen und Prognosen. Durch die Einbindung im Hauptartikel wurde dort ein Referenzfehler angezeigt, der gar nicht im Artikel war. --Johannnes89 (Diskussion) 09:44, 12. Mai 2026 (CEST)

+1. Das wollte ich mit meinem obigen Beitrag sagen. Genau die dort genannten Änderungen an dem eingebundenen Artikel scheint den Fehler beseitigt zu haben, da die folgenden Änderungen sich nicht mit ENs befasst haben.

Danke für die Erklärung mit dem Suchfeld + Referenzfehler; ungewühnlich, aber interessant. Kava wäre ein nächster Kandidat fürs Fixen.

Gruß, --Wi-luc-ky (Diskussion) 10:52, 12. Mai 2026 (CEST)

Script gesucht

Hallo, es gibt zahlreiche Scripts, so war meine Überlegung, ob es auch ein Script gibt, was die Beiträge bestimmter User auf Metaseiten unsichtbar macht? Gibt es sowas oder ähnliches? Viele Grüße --Zartesbitter (Diskussion) 18:38, 12. Mai 2026 (CEST)

ist mir erst mal nicht bekannt. Aufgrund Meinungsfreiheit-Problemen wäre ein solches Skript bzw. das Betreiben desselben auch kritisch. --Doc Taxon (Diskussion) 19:05, 12. Mai 2026 (CEST)

Ein vorhandenes Script ist definitiv nicht annonciert.

Könnte sich jemand selbst schreiben; wäre aber nicht ganz einfach, den Beginn des unerwünschten Beitrags sicher und robust herauszufinden.

In der Kommunikation ist sowas wenig sinnvoll, denn auf diesen Menschen hatte ja schon jemand geantwortet, und in anderen Situationen müsste man schon wissen was wörtlich dort geschrieben war, und wenn alle diese Beiträge einfach aus dem Weltbild ausgeblendet werden, müssen eigene Fehlreaktionen die zwingende Folge sein.

VG --PerfektesChaos 19:24, 12. Mai 2026 (CEST)

Ich weiß nicht mehr wo, hatte das aber mal gehört, dass man das Geschriebene der User gezielt unsichtbar machen kann mit diesem Tool. Wenn man wissen will, was diese Person schreibt, kann man es ja wieder deaktivieren. Scheinbar wurde mir Quatsch erzählt. --Zartesbitter (Diskussion) 19:40, 12. Mai 2026 (CEST)

Warum? Man verbietet ja niemanden, was er/sie zu schreiben hat. Lediglich das Anzeigen des Geschriebenen wird verhindert. --Zartesbitter (Diskussion) 19:42, 12. Mai 2026 (CEST)

Benutzer:Martin Kraft/hideUserComments.js, aber keine Ahnung, ob das bspw. mit den Diskussionswerkzeugen noch funktioniert. -- hgzh 22:14, 12. Mai 2026 (CEST)

Vielen Dank, das ist interessant. Ich werde es testen. --Zartesbitter (Diskussion) 21:02, 14. Mai 2026 (CEST)

"Lange" Ladezeiten auf Wikiseiten

Hallo zusammen, mir ist aufgefallen, dass seit etwa einer Woche die Ladezeiten sich verlängert haben. Die Seite seit nicht fertig geladen aus (keine fette Schrift, größere Umbrüche). Leider habe ich kein Screenshot :( Dies habe ich nicht nur auf einem Rechner, sondern an mehreren und nicht nur z.H. sondern auch auf der Arbeit (1G zum zentralen Switch min 20G zum GebäudeSammler; min 40G Campussammler, min 80G zum DE-CIX und dann in die Welt) --Vielen Dank und viele Grüße Benutzer:Woelle_ffm (Diskussion) 00:40, 14. Mai 2026 (CEST)

Moin Benutzer:Woelle_ffm, also bei mir kann ich das nicht feststellen. Hast du ggf. mit deinem System mal einen Neustart gemacht? Ansonsten, was für ein System und was für einen Browser nutzt du und hast du ggf. Extentions aktiviert und hast du das auf anderen Seiten auch? mfg --Crazy1880 10:35, 25. Mai 2026 (CEST)

Moin, Crazy1880, mir ist aufgefallen, wenn es passiert .... es ist auf Seiten die ich auf Wiki noch nie besucht habe.. dies kann bei zu ca. 5sec dauern ... ich habe gerade geschafft ein Screenshot zu machen .--Vielen Dank und viele Grüße Benutzer:Woelle_ffm (Diskussion) 21:47, 25. Mai 2026 (CEST)

Verbesserte Boterkennung und Ersatz unseres CAPTCHA-Systems

Hallo vom Team Product Safety and Integrity! Nach erfolgreichen Tests von hCaptcha für Boterkennung in der englischsprachigen, französischsprachigen, japanischsprachigen Wikipedia und vier weiteren Wikipedia-Sprachversionen, werden wir hCaptcha in den nächsten Wochen in allen Projekten einführen.

Dies beinhaltet die Nutzung von hCaptcha für die Kontoerstellung und für Bearbeitungen neuer User. Damit ersetzen wir das traditionelle “gib dieses Wort ein”–CAPTCHA, was aktuell vielfach erforderlich ist. hCaptcha ist konfiguriert, nur bei wahrscheinlich-verdächtigen Aktivitäten auszulösen, sodass nur sehr wenige Menschen davon gestört werden dürften. In unserem Test haben schätzungsweise nur ~2% aller menschlichen User hCaptcha ausgelöst

Zum Hintergrund: Als Teil unseres Schwerpunkts zum Schutz der Wikis und Erkennung von böswilligen Aktivitäten entwickeln wir bessere Schutzmaßnahmen vor Bots, die Aktivitäten ausführen, die eigentlich für Menschen gedacht sind, wie zum Beispiel das Erstellen von Konten und das Bearbeiten von Inhalten. Da sich das Internet weiterentwickelt hat und Computer immer intelligenter geworden sind, ist unser altes CAPTCHA-System mittlerweile für Menschen eine Herausforderung, aber für Computer ein Kinderspiel.

Wir haben dies erkannt und zunächst hCaptcha, einen Bot-Erkennungsdienst eines Drittanbieters, getestet, um unser altes CAPTCHA zu ersetzen. Seitdem nutzen sieben Wikipedia-Versionen hCaptcha, darunter die englischsprachige, französischsprachige und japanischsprachige Wikipedia, um Kontoerstellung und bestimmte Arten von Bearbeitungen zu schützen. hCaptcha ist ein auf Bot-Erkennung spezialisiertes Unternehmen, das über Erfahrung im Schutz sehr großer Online-Websites verfügt und bei der Entwicklung der Lösung den Datenschutz der Nutzer in den Vordergrund stellt. Wir haben technische Sicherheitsvorkehrungen getroffen, um die Sensibilität der Informationen, die wir an hCaptcha senden, zu verringern.

Außerdem liefert es uns Hinweise darauf, ob Kontoerstellungen und Bearbeitungen wahrscheinlich von Bots erfolgt sind – unabhängig davon, ob hCaptacha ausgelöst hat. Diese Hinweise fließen in die Informationen ein, die wir Checkusern und Stewards zur Verfügung stellen. Diese nutzen sie, um böswillige Aktivitäten aufzuspüren und zu entfernen, die wahrscheinlich von Bots ausgeführt wurden und die auf andere Weise wohl nicht zu entdecken wären.

Weitere Informationen zu diesem Projekt findet ihr auf unserer kürzlich aktualisierten Projektseite. Wir freuen uns über Kommentare hier oder auf der Diskussionsseite des Projekts. Abonniert das Wikimedia Foundation Bulletin, um die wichtigsten Neuigkeiten der Wikimedia Foundation zu verfolgen. Dankeschön! --SGrabarczuk (WMF) (Diskussion) 20:55, 14. Mai 2026 (CEST)

Habs nur in der englischsprachigen Wikipedia intensiv verfolgt, aber da war ich sehr zufrieden mit dem neuen System. --Johannnes89 (Diskussion) 21:47, 14. Mai 2026 (CEST)

Klingt sinnvoll zeitgemäß. -- hgzh 19:59, 15. Mai 2026 (CEST)

Neuer Kommentar siehe hier, und im selben Kontext auch das hier.
Ich verstehe ja, dass Ihr was tun müsst gegen Unsinnsbearbeitungen und Vandalen, aber das hier raubt mir jetzt echt den letzten Nerv. Ich arbeite seit Jahren unangemeldet mit, immer konstruktiv, habe zahlreiche Artikel überarbeitet und viele Stunden in der QS verbracht. Ich habe zwar ganz ganz früher mal einen Account gehabt, war aber nie gesperrt, war nie als Sockenpuppe zweigleisig aktiv, sondern habe mich einfach irgendwann entschieden, dass für mich die unangemeldete Form der Bearbeitung die richtige ist. Sieht so aus, als könnte das jetzt das Ende meiner Tätigkeit bei Wikipedia sein. Wenn das so bleibt wie heute, macht die Mitarbeit keinen Spaß mehr. --~2026-33361-62 (Diskussion) 10:54, 5. Jun. 2026 (CEST)

Kann das bei den üblichen Fehlern zeitnah zurückgedreht werden? (nicht signierter Beitrag von Bahnmoeller (Diskussion | Beiträge) 13:01, 10. Jun. 2026 (CEST))

Ich habe kein JavaScript. Wie kann ich mich in meinen Account einloggen? --~2026-42953-93 (Diskussion) 20:48, 4. Aug. 2026 (CEST) P. S.: Um diese Zeile zu schreiben, muss ich jemand anderen bitten, sie für mich zu schreiben. Ich kann nicht einmal diesen Hilferuf auf dieser Seite schreiben. Mir wird einfach kein hCaptcha angezeigt. Ich kenne das leider von anderen Webseiten, die ich ebenfalls nicht mehr nutzen kann. Es wird einfach JavaScript vorausgesetzt, und wer keines hat oder ein "veraltetes", weil er keinen "Standardbrowser" und kein "Standardbetriebssystem" nutzt, ist sofort verdächtig. Möchte die Wikipedia mich jetzt wirklich als verdächtig brandmarken und wirklich aussperren, weil ich kein JavaScript habe und keinen Standardbrowser habe? Das fühlt sich nicht gut an, und ich finde es ganz gemein. Ich nutze die Wikipedia gern und schon seit langer Zeit. Vor zwanzig Jahren habe ich mich sogar dazu entschlossen, einen Account anzulegen. Diesen würde ich gern weiternutzen. Bitte helft mir, einen Weg zu finden, wie ich das tun kann. Danke.

Vorlage Falsche ISBN und die ISBN-Suche

Es gibt diese Vorlage {{Falsche ISBN}}, wenn man auf den Link klickt, dann kommt auf der Seite Spezial:ISBN-Suche die Meldung in roter Schrift "Vermutlich ist die ISBN ungültig. Bitte prüfe, ob sie korrekt von der Quelle übertragen wurde."

Ich würde mir wünschen, dass die Vorlage diese Meldung unterdrückt. Diese Meldung ist durchaus sinnvoll, aber wenn die im Buch und in den Bibliotheken falsch ist, dann verwirrt das nur.

Beispiel: ISBN 3-7701-2052-2 --Wurgl (Diskussion) 09:34, 17. Mai 2026 (CEST)

Muss man auch bissl aufpassen, eine "formal falsche" ISBN ist keine "ungültige" ISBN. --Doc Taxon (Diskussion) 12:43, 17. Mai 2026 (CEST)

Diese Meldung ist durchaus sinnvoll. Der Text der Fehlermeldung ist schlecht. Die Meldung sollte lauten:

"Diese ISBN ist formal falsch. Bitte prüfe, ob sie korrekt von der Quelle übertragen wurde. Wenn ja, dann wird sie vermutlich trotzdem verwendet."

Also eher den Meldungstext anpassen. ÅñŧóñŜûŝî (Ð) 15:29, 17. Mai 2026 (CEST)

MediaWiki:booksources-invalid-isbn per A/A zu ändern wäre schlauer. WP:ISBN #Fehlerhafte ISBN mag verlinkt werden. Soo schlimm ist der bisherige Text aber doch nicht: „Vermutlich ist die ISBN ungültig. Bitte prüfe, ob sie korrekt von der Quelle übertragen wurde.“

Die Detektierung kommt global von MediaWiki und ist ja als Warnung bei Falscheingabe erstmal berechtigt.

Hintergrund:

• In den 1970ern, auch 1980ern gab es noch keine PC.
• Die Prüfziffer musste deshalb auf einem Formular händisch ausmultipliziert werden.
• Ging öfter mal schief. Also vorrangig bei den ISBN10.
• Wir wissen aber nicht, ob es die Prüfziffer war, oder ob der Drucker sich bei der Bestell- (oder vielleicht Verlags-)nummer vertan hatte. Wir können auch nichts korrigieren. Wir können auch unter keiner anderen ISBN suchen.
• Die Nationalbibliotheken der Zeit hatten das abgetippt und so wie es da stand auf Karteikärtchen geschrieben. Das landete dann auf Lochkarten und Lochstreifen. Ergo steht es dann auch unter der falschen Nummer im Katalog. Ggf. unkorrigiert, also auch nicht unter EAN / ISBN13 aufzufinden.

VG --PerfektesChaos 00:13, 18. Mai 2026 (CEST)

Mir geht es um die Unterdrückung der Meldung bei Verwendung von {{Falsche ISBN}} und nur genau dann. Mehr als diese Vorlage zu verwenden können wir nicht tun. --Wurgl (Diskussion) 10:24, 18. Mai 2026 (CEST)

Zitat von Wikipedia:Internationale Standardbuchnummer#Falsche Prüfziffer:

Auf der Spezial:ISBN-Suche wird in solchen Fällen eine rote Fehlermeldung angezeigt, die ignoriert werden kann.

Die ISBN ist definitiv fehlerhaft, aber der Link in die Bibliothekssuche ist trotzdem möglich, siehe z.B. ISBN 3-257-01801-1 mit Ergebnissen in DNB, ÖNB, Worldcat etc. Ob im Warntext jetzt "ungültig", "falsch" oder "fehlerhaft" steht bzw. er in besonderen Fällen gar nicht angezeigt wird, ist mir ziemlich egal. --At40mha (Diskussion) 13:01, 18. Mai 2026 (CEST)

Naja, mit mittelprächtigem Aufwand wäre Wurgls Wunsch erfüllbar.

• Vorlage:Falsche ISBN müsste eine URL auf Booksources generieren und da einen lokalen URL-Parameter intended=1 dranhängen.
• Wikipedia:Technik/Skin/Gadgets/specialpageLoader müsste Booksources registrieren und in diesem Fall, ggf. nur wenn auch intended=1 in der URL steht, ein neues Gadget aufrufen.
• Das Gadget prüft nochmal, ob intended=1 in der URL, und falls ja dann per Screengrabbing die Seite umstricken; Schrift nicht mehr rot und Warnhinweis austauschen gegen anderen Hinweis, wir wissen dass formal ungültig, suchen aber trotzdem.

Umgekehrt kam man ja von einer Verlinkung, wo dranstand, dass diese ISBN irgendwie falsch ist.

• Ob das den Driss lohnt, müssten BOA entscheiden.

VG --PerfektesChaos 20:30, 18. Mai 2026 (CEST)

Überflüssige Linien im Safari-Browser

Bei diversen Vorlagen im Bereich Tennis erscheinen laufend überflüssige Linien im Safari-Browser (unter MacOs). In Firefox sind sie nicht sichtbar. Kann man das abstellen? Siehe Gonet Geneva Open 2026#Ergebnisse. In der englischen Wikipedia erscheinen auch im Safari-Browser keine überflüssigen Linien. Zum Vergleich siehe hier. In jeder Vorlage sind es andere überflüssige Linien, z. B. French Open 2026/Dameneinzel#Hauptrunde. Eine Übersicht der Vorlagen im Tennis ist hier: Wikipedia:WikiProjekt Tennis. Danke und Grüße --Partynia ^{∞ RM} 10:44, 22. Mai 2026 (CEST)

Das ist ein Bug des Safari-Browsers. Diese Turnierpläne sind Tabellen mit teilweise weggelassenen Zellrändern. Der Safari-Browser kann diese Linien trotz korrektem Quelltext nicht richtig handhaben. Mehr als die Vorlage korrekt zu schreiben, kann man da nicht machen. ÅñŧóñŜûŝî (Ð) 14:28, 22. Mai 2026 (CEST)

...aber in allen anderssprachigen WP-Versionen (siehe z. B. hier oder hier oder hier) funktioniert es fehlerfrei bei gleichem (Safari-) Browser. Also müsste man den Quelltext der Vorlagen in der deutschen Version korrigieren können. --Partynia ^{∞ RM} 16:19, 22. Mai 2026 (CEST)

Oops - der letzte Änderungsversuch hat nunmehr alle Zellränder verschwinden lassen und damit die Tabelle ruiniert. --Partynia ^{∞ RM} 07:07, 23. Mai 2026 (CEST)

Ich habe keine Mac-Computer und deshalb auch keinen Safari-Browser. Ich kann also nur schauen, dass alle Zellen explizit Ränder haben, ggf. mit Breite gleich Null. Um 7 Uhr war ich noch bei der Umsetzung. Wie sieht es jetzt aus? Kannst du Screenshots hochladen? ÅñŧóñŜûŝî (Ð) 12:13, 23. Mai 2026 (CEST)

Danke für Deine Bemühungen. Bisher keine Verbesserung. Hier ein Screenshot. --Partynia ^{∞ RM} 12:29, 23. Mai 2026 (CEST)

Safari hat wohl Probleme mit T-förmigen Ecken. Habe mal was geändert. Jetzt in dieser Vorlage besser? ÅñŧóñŜûŝî (Ð) 13:13, 23. Mai 2026 (CEST)

Der alte Seamonkey-Browser (der Nachfolger von Mozilla) hat eventuell ähnliche Probleme. Ich hab den bis vor einem Jahr verwendet und da hatte ich ähnliche Probleme. Hab das damals ignoriert, weil Firefox ja alles richtig angezeigt hat. Eventuell wäre das ein Brwoser zum Testen. --Wurgl (Diskussion) 13:36, 23. Mai 2026 (CEST)

Danke, jetzt siehts in Safari wieder korrekt aus. --Johannnes89 (Diskussion) 14:33, 23. Mai 2026 (CEST)

Gilt nur für diese Vorlage. Die anderen werde ich jetzt abernicht alle durchkämmen, nur weil ein Browser Macken hat. ÅñŧóñŜûŝî (Ð) 15:07, 23. Mai 2026 (CEST)

Vielen Dank, ÅñŧóñŜûŝî! Super gemacht. Wenn Du mir sagst, was zu ändern ist, dann würde ich es bei den anderen Vorlagen durchführen. --Partynia ^{∞ RM} 16:27, 23. Mai 2026 (CEST)

Das ist sehr aufwändig. Du musst in den Vorlagen Tabellenzellen, welche keine Einträge (Inhalt) haben, aber über mehrere Zeilen / Spalten gehen, an den richtigen Stellen(!) in mehrere kleinere aufteilen. ÅñŧóñŜûŝî (Ð) 19:03, 23. Mai 2026 (CEST)

Tja, da bin doch wohl überfordert. Vielleicht könntest Du die Änderungen bei den wichtigsten und am häufigsten verwendeten Vorlagen durchführen. Das wären dann nicht allzu viele. Jedenfalls Danke und Grüße --Partynia ^{∞ RM} 20:40, 23. Mai 2026 (CEST)

Survey (proposed direction for Wishlist)

Apologies if this has not yet been translated into your wiki's language. Hilf bitte mit, in deine Sprache zu übersetzen.

You are invited to voice your opinion on a new community-proposed direction for the Community Wishlist. Danke! MediaWiki message delivery (Diskussion) 05:07, 29. Mai 2026 (CEST)

Siehe m:Community Wishlist/Community Wishlist 2027 für den Prozess der nächsten WMF Umfrage. --Johannnes89 (Diskussion) 20:23, 20. Okt. 2026 (CEST)

Meinen Benutzernamen (für mich) hervorheben

Hallo zusammen, wie könnte ich bitte meinen Benutzernamen überallzuwiki hervorheben, vielleicht in einer anderen Farbe? Es geht mir darum, z.B. in der Versionsgeschichte von Artikeln, aber auch anderswo, schneller zu sehen, was ich da eigentlich verbrochen hatte. Ich hatte schon überlegt, das den Browser machen zu lassen, aber dann hätte ich das nur auf dem einen PC. Also warum nicht gleich überall? Oder gibt es das an Ende schon und ich müsste es nur anknipsen? Danke für Tipps! --Karsten Meyer-Konstanz (D) 00:02, 4. Jun. 2026 (CEST)

@ „Oder gibt es das an Ende schon“

• Gibt es schon, irgendwie.
• Siehe WP:CSS #Eigene Beiträge und später #Versionsgeschichte.
• Und dann gemäß Inhaltsverzeichnis zum Anfang der Seite, und wo du deine Gestaltung hinschreiben kannst.

@ „ich müsste es nur anknipsen“

• Es gibt unendlich viele Gestalltungsmöglichkeiten, und allle Leute haben ihre ganz individuellen Wünsche. Deshalb gibt es nicht das eine Einheits-Feature für alle, weil das dann immer 90 % der Leute nicht gefällt.

Du hast einen relativ langen Konto-Namen. Du könntest ihn ausblenden, und an seiner Stelle ein poppiges (Ich) oder mir in deinen individuellen Neon-Farben bauen.

Viel Spaß --PerfektesChaos 04:25, 4. Jun. 2026 (CEST)

Ganz herzlichen Dank, @PerfektesChaos! --Karsten Meyer-Konstanz (D) 05:04, 4. Jun. 2026 (CEST)

Sodele, nachdem das dort angegebene Beispiel für einen großen vertikalen(!) Abstand sorgte und ich es andererseits nicht schaffte, meinen Benutzernamen auch in der Beobachtungsliste anzusprechen, habe ich jetzt folgendes Konstrukt in mein globales CSS aufgenommen. Das wirkt in der Versionsgeschichte und in der Beobachtungsliste, es ist nicht aufdringlich und doch sehe ich schnell, wo ich tätig war:

#content a[href$="Benutzer:Meyer-Konstanz"] { background:#DDDDDD; font-weight:bold; } /* meine Signatur hervorgehoben */ --Karsten Meyer-Konstanz (D) 15:01, 4. Jun. 2026 (CEST)

Navigationsleisten-Link zum 'Artikelentwurf'

Da mir empfohlen wurde das ganze hier her zu 'verschieben', kopiere ich meine Anfrage von WP:A/A. --Ad^tonko 00:25, 12. Jun. 2026 (CEST) Übertrag:

Moinsen. Wir haben ja den Meine Benutzerseite/Artikelentwurf-Link in die Navigationsleiste oben bekommen. Ich habe darunter eine WL angelegt auf meine eigentliche Baustellenseite. Wenn ich jetzt auf den Link ind er Navileiste klicke wird ein &redirect=no an die URL gehängt. womit ich natürlich auf /Artikelentwurf lande, auf der mir dann der Link auf meine Baustellenseite angezeigt wird. Das ist irgendwie Kontraproduktiv.

Meine Frage ist jetzt: Wie bekomme ich es hin da die Wikisoftware mich auf die Seite weiterleitet, die ich auf der Artikelentwurfseite hinter legt habe, ohne das ich ein zweites Mal klicken muss? Oder ist das ne globale (de)Wiki Einstellung? --Ad^tonko 18:46, 11. Jun. 2026 (CEST)

Für Neulinge hat das ja so einen Vorteil: Wer seinen Artikel in den ANR verschiebt und auf die automatisch erstellte WL keinen SLA stellt, landet so beim Klick auf den Menülink nicht plötzlich im ANR...

Ich weiß nicht, welchen Skin du benutzt, aber in Vector 2022 könntest du z.B. mit folgendem Javascript in der eigenen common.js das Linkziel ändern (als Beispiel mal /Schreibstube, wie bei dir gewünscht):

mw.loader.using('mediawiki.util').then(function () {
    var link = document.querySelector('#pt-sandbox a');
    if (!link) {
        return;
    }

    // Change destination
    link.href = mw.util.getUrl('User:' + mw.config.get('wgUserName') + '/Schreibstube');
});

--Johannnes89 (Diskussion) 08:54, 12. Jun. 2026 (CEST)

Mit der Vorgeschichte, ein Newbie habe bereits einmal einen Entwurf aus dem BNR in den ANR verschieben lassen, wird das Verhalten &redirect=no sehr sinnvoll. Wiewohl beginners auch ziemlich irritiert sein dürften, wenn sie dann auf dieser seltsamen WL-Seite landen.

Das bedeutet aber, dass sich an der globalen Programmierung wenig ändern lässt.

Sich mittels des vorgestellten JavaScript das Linkziel umzuprogrammieren, scheint mir etwas viel Aufwand für wenig Resultat und kaum zur Weiterempfehlung geeignet.

• Erfahrene haben sich oft auf ihrer ebenfalls verlinkten BNR-Startseite eine Navigationsliste mit individuell wichtigen internen und externen Verlinkungen eingerichtet; das scheint mir simpler als der Versuch, den Portalrahmen dafür nutzbar zu machen.
• Erfahrene blenden das Rotlink kurzerhand aus, und gut ist.

Daraus folgt, dass der globale Gesamtnutzen dieses Entwurfs-Links für Newbies mager ist, gleichwohl gut gemeint.

• Es funktioniert beim allerersten eigenen Artikel für Newbies prima.
• Wird dann dieser Artikel nochmals neu im ANR angelegt, und der reine Text ohne VG dorthin kopiert, funktioniert es auch wunderbar.
• Falls jedoch aus dem BNR in den ANR verschoben wird, bleibt diese unverständliche WL-Seite zurück. Dass deren Inhalt gelöscht und mit dem nächsten Entwurfstext überschrieben werden kann, muss niemand begreifen. Wird wieder verschoben, erscheint im ANR eine kuriose Vor-VG.

Die auf den ersten Blick sinnvolle Idee von Adtonko mit der WL auf die eigentliche eigene Spielwiese ist kaum realisierbar.

VG --PerfektesChaos 15:04, 12. Jun. 2026 (CEST)

Meine Idee war ja eher das man es Einstellen können sollte, ohne Japascript zu können. Also quasi ne Checkbox in den Einstellungen für den Link unter #pt-sandbox a der die WL-Parsung an oder abstellt, standartmäßig aber auf WL unterdrücken steht.

Das der &redirect=no seine Berechtigung hat, habe ich ja nie angezweifelt, mir ging es nur darum, dass man das Verhalten unterdrücken können sollte als 'erfahrener' User. Da man ja schon etwas mehr Erfahrung in der Art und Weise hat, wie die Wiki denn nun funktioniert.

@Johannnes89 danke für ds Snippet. --Ad^tonko 14:28, 14. Jun. 2026 (CEST)

@ „Meine Idee war ja eher das man es Einstellen können sollte“

• Es gibt jetzt schon lokal wie global Beschwerden, dass die Einstellungen-Spezialseite zu unübersichtlich sei und nichts zu finden ist, vor allem wenn der Fachausdruck unbekannt wäre, und die ganzen privat veränderten Konfigurationen nicht mehr durchschaut werden.
• Jede Option verkompliziert aber die PHP-Programmierung, macht sie schwieriger zu pflegen und zukünftige Weiterentwicklung wird erschwert, sinkende Robustheit und häufige Fehlersituationen. Zumal jede eingeführte Möglichkeit für die nächsten 20–30 Jahre unterstützt werden muss, fordert die globale Community.
• Netscape, äh, Firefox hat ja das versteckte about:config ohne Zugang über GUI. Das hätte MW gerade noch gefehlt.
• Vor Jahrzehnten gab es eine Kochsendung, wohl Jamie Oliver, die berühmt war für die spontanen individuellen Varianten des Gerichts, Cheeseburger für jüdisch-orthodoxe Veganerinnnen, oder Mettbrötchen für Muslime mit Glutenallergie.

Das Feature mit Rotlink im GUI ist nett für Newbies und deren allerersten Artikel, aber wer erfahren ist und bereits jahrelang andere Methoden aufgebaut hat, blendet das Dingens dort besser aus und gut ist.

VG --PerfektesChaos 11:01, 15. Jun. 2026 (CEST)

@ Einstellungs Seite zu überladen - "Featurecreep" und kein Konzept im UI/UX. Ich weiß man versucht dagegen an zu arbeiten, aber dennoch ist die Einstellungseite seit (gefühlt) 20 Jahren unangerührt.

@ PHP wird komplizierter - Dass der Link überhaupt erscheint ist schon eine globale An/Aus Option. Das Feature zum An/Aus ist ja da, nur halt in der Admin Ebene.

@ Netscape/Firefox - das will ja auch niemand.

@ Kochsendung - hat jetzt was mit dem zu tun?

@ Ausblenden - genau das ist ja was mMn der Schalter ist, den ich weiter oben angesprochen habe. --Ad^tonko 23:22, 19. Jun. 2026 (CEST)

@ „dennoch ist die Einstellungseite seit (gefühlt) 20 Jahren unangerührt“

• Das fühle ich aber anders.
• Wir dokumentieren schließlich jede Veränderung, und tracken den Prozess dadurch.

@ Feature creep – war schon das richtige Stichwort. Wobei MediaWiki nie einen Projektplan hatte, der eines Tages fertig sein solle.

• Gleichwohl zieht jedes implementierte Feature halt komplexere Codes nach sich, erfordert auch bei ohne GUI erreichbaren Einstellungen eine Dokumentation, und das Testen geht nicht nur über automatisierbare Modultests, sondern bedarf auch der visuellen Prüfung des Zusammenwirkens der Abläufe in jeder Kombination aller Einstellungen bei jedem Gerätetyp.

Die genannte Kochshow war gefürchtet dafür, dass jedes Rezept nochmals in drei Varianten vorgestellt wurde, deren jede noch dreimal modifiziert werden konnte. Damit war das Rezept am Ende völlig unklar, und Spaßvögel hatten mal ausgerechnet, die Speisekarte in diesem Restaurant würde 5678 Bestellvorschläge anbieten. Kaffee mit lauwarmem Milchschaum von braungefleckter Kuh nicht älter als drei Jahre halt, darüber Zartbitter-Streusel mit Kakaogehalt für mich über 65 % bitte.

Für individuelle Anpassungswünsche stellen wir ja CSS und JS bereit, womit in 1000 Wikis Zigtausende regelmäßiger User sich das nochmals privat anpassen können, ohne dass jede persönliche Präferenz in die globale Programmierung für alle übertragen werden muss.

VG --PerfektesChaos 12:44, 20. Jun. 2026 (CEST)

@ Einstellungseite: Mediawiki hat sich entwickelt, das wissen wir alle. Aber vom UI-Konzept her hat sich Spezial:Einstellungen seit 2010 nicht geändert. Das Features über die Zeit hinzugekommen sind, bestreite ich nicht.

@ testing:

• 'PC' 3 major OS (Windoof, Mac, your flavour of Linux) , 3 major browser engines (Chromium, Gecko, Safari)
• 'Mobile' Android (quasi linux) und iOS mit App Implementationen & Browser, wobei die Apps nur nach einer Implementierung der Chromium (A) bzw. Safari (iOS) Engines aussehen.

Ich sehe den Aufwand, ich bestreite nicht einmal dass es viele Kombinationen gibt die 'edge cases' hervorbringen. (Wildes Beispiel: Chrome mit Gecko Engine auf Winux) Aber eine Checkbox, ob man etwas angezeigt haben möchte oder nicht, das bereits durch einen globalen Schalter fest in der Software programmiert ist... Wobei, wir haben mit Parsoid ja ein wunderschönes Beispiel für "Test failed? Deploy anyways".

@ kochshow: also eine typische Bestellung eines amerikanischen Kaffeetrinkers im Starbucks.

Warum ich mir als 'erfahrener' User Javascript und kaskadierende Stylesheets beibringen muss, damit etwas 'nachträglich' auf display:none bzw. das DOM-Objekt nach der Generierung wieder entfernt oder verändert (wie mit Johannes seinem snippet) wird, erschließt sich mir nicht. Mag sein dass ich da als Server-Schubserin verbrannte Leistung sehe, aber wenn ich dem User die Möglichkeit gebe, die Rechenzyklen erst gar nicht zu benötigen, auf beiden Geräten, dann haben beide Seiten gewonnen. --Ad^tonko 13:28, 20. Jun. 2026 (CEST)

Es geht nicht um das eine einzige Feature, sondern es sammelt sich halt über zwei Jahrzehnte jeden Monat eines von gleicher Dramatik an, und kein einmal eingeführtes Angebot darf jemals später entfernt werden, sonst Zwergenaufstand. Damit immer komplexere Programmierung, mehr Dokumentation zu pflegen, Bedienung immer unübersichtlicher.

Hier geht es darum, dass Newbies auf das Rotlink gelockt werden sollen; deshalb muss es als Rotlink dokumentationslos angeboten werden.

• Neue Generationen werden also genau diesen Seitennamen verwenden, und das als Normalzustand ansehen.
• Die älteren Generationen können sich entscheiden:
  1. ihre bestehende Spielwiese auf diesen Seitennamen umzustellen,
  2. die Verlinkung auszublenden,
  3. das Rotlink zu ignorieren.
• Die Biologie lehrt, dass die älteren Generationen in den kommenden Jahrhunderten verschwinden werden, wodurch sich die Angelegenheit von selbst lösen wird.

@ „hinzugekommen“

• Es sind wohl auch mehr Reiter, und pro Reiter deutlich mehr Optionen. Und das ist es, was es für Non-Techies unüberschaubar viel und komplex macht. Man müsste sich von allen Optionen merken, dass es sie gibt und an welcher Stelle sich was verstellen ließe, und das ist je nach Mensch auf 50–100 begrenzt.

Natürlich lässt sich sowas programmieren. Aber das hat auch seinen Preis: Verkomplizierung der Software, und die potenzielle Kundschaft wird eine solche Ankreuzelmöglichkeit unter den vielen Einstellungen überhaupt nicht finden, nicht erwarten, nicht suchen, und bei mehr als der Hälfte der Adressaten käme das niemals an.

• Deshalb ist die Strategie: 100–200 global für fast alle Menschen wichtige Einstellungen werden von MediaWiki angeboten; für die 10.000 anderen Anpassungen, die immer irgendjemand für sich persönlich als wichtig empfindet, gibt es persönliches CSS, notfalls JavaScript.

VG --PerfektesChaos 23:40, 25. Jun. 2026 (CEST)

Deswegen gibt es in jeder guten Software den 'noobie' Modus und den 'expert' Modus. Oder es wir von vorn herrein gesagt: Nutzung nur wenn du weißt was du tust.

Das es für jeden Kleinscheiß natürlich keine Option braucht, ist mir klar.

Aber dieses eine Feature wird doch wohl noch gehen! /ironie

Mir wurde ja gehelft, und wir sind in eine Grundsatzdiskussion am ausufern.

Entsprechend: Merci Beaucoup. --Ad^tonko 02:57, 26. Jun. 2026 (CEST)

Und hier ist der »'expert' Modus« das persönliche CSS.

• Zeig mir mal andere Software, die dem persönlichen Konto die Definition von privatem CSS erlaubt, vom Browser-CSS mal abgesehen.
• Du kannst für jedes Element spezifizieren, dass du es ausblenden, in Fettschrift, vergrößert oder bunt dekoriert haben möchtest. Sogar den Text kannst du teils mittels CSS ändern, erst recht mit privatem JavaScript.

Wenn alles das auch in der globalen Software für alle implementiert wäre, und nach außen dokumentiert und zugesichert, dann findet das auch niemand in der Bedienungsanleitung, aber die Programmierung wird instabil und ist nicht mehr wartungsfähig.

• Wir haben bereits Tausende offener Bug-Tickets für wichtige Funktionalität, die dringlicher abgearbeitet werden müssten als dein Begehren, und teils schon ein Jahrzehnt offen sind.
• Du bekommst hingegen dein persönliches Feature binnen Minuten, in jeder Farbe die du möchtest, ohne ein Ticket einzureichen und Jahre auf eine global wirksame Implementierung zu warten, die sich auf 1000 Wikis innerhalb der WMF und dazu außerhalb und Millionen Menschen im Publikum auswirkt, je nachdem.
• Und wir haben über 400 Hilfeseiten für die Grundfunktionalität und wesentlichen Kernaufgaben. Die werden nicht verständlicher und leichter zu durchschauen, wenn sie um derartige Features vermehrt auf 4000 anwachsen.

VG --PerfektesChaos 15:10, 26. Jun. 2026 (CEST)

per se fällt mir neben MediaWiki da Obsidian ein, auch ne Art (persönliches) Wiki.

Mein #Feature' ist allerdings javascript, nicht pures css. aber, wie bereits gesagt: Mir wurde ja geholfen.

Wie stabil die Programmierung ist, sehen wir ja an Parsoid. --Ad^tonko 15:57, 26. Jun. 2026 (CEST)

Parsoid - Fehler in Ausdruck:Unerwarteter Operator round

Hallo, ich habe nochmals eine Seite mit Darstellungsproblemen mit Parsoid entdeckt, der Legacy Parser zeigt es korrekt an. Ich bin mir jedoch nicht sicher, ob vielleicht in der Seite irgendwo ein Fehler ist, kann jedoch nichts falsches entdecken.

Es geht um Gemeinden des Kantons Aargau. Ab Zofingen kommen die Fehlermeldungen:

• zuerst: Fehler im Ausdruck: Unerwarteter Operator round
• danach: Node-count limit exceeded

--McBayne (Diskussion) 23:23, 14. Jun. 2026 (CEST)

Der unterschiedliche Ressourcenverbrauch fällt auf:

• Legacy: Preprocessor visited node count: 702799/1000000
• Parsoid: Preprocessor visited node count: 1001551/1000000

Parsoid kommt mit dem Artikel auch zurecht, wenn die Tabelle leicht gekürzt wird. Das Problem ist also ein ressourcenintensiver Artikel, der vom Legacy Parser noch verarbeitet werden kann, während Parsoid in Vorlagenbeschränkungen läuft.--Kallichore (Diskussion) 00:06, 15. Jun. 2026 (CEST)

1. „Unerwarteter Operator round“ aus der Überschrift kannste vergessen, das ist ein völlig zufälliger Folgefehler, weil grad an der Stelle node #1000001 erreicht wurde.
2. Kallichore hat mit 1001551/1000000 das „Node-count limit exceeded“ korrekt identifiziert.
   • Die Seite ist schlicht zu groß, oder genauer: zu kompliziert.
   • Wobei Parsoid irgendwas anderes bei den Nodes anders statistisch erfasst als zuvor. Das gab es vor anderthalb Jahrzehnten schon mal, damals zu unseren Gunsten, also dass tote Pfade nicht mehr gezählt wurden (nur noch „visited“).

Was ist zu tun?

• Phab-Tickets durchsuchen, ob dort schon ein veränderter visited node count bekannt ist, ggf. melden. Vielleicht zählen sie wieder die unvisitierten mit.
• WP:VWS um Analyse bitten. Konstrukte in beteiligten, ggf. praktisch nur in dieser Seite wirksamen Vorlagen könnten umgestellt werden, um von den 1001551 auf unter 1000000 zu gelangen.
  • Wobei 1001551 nicht die absolute Anzahl dieser Seite sein muss, weil die Auswertung zuvor abgebrochen wurde und tiefere Ebenen nicht mehr erreicht wurden.

Viel Spaß --PerfektesChaos 10:15, 15. Jun. 2026 (CEST)

Ich hab jetzt in Gemeinden des Kantons Aargau versuchsweise alle {{Anker}} durch id= ersetzt (das hat in anderen Fällen geholfen) und das hat die Zahl von "ppvisitednodes":{"value":1001551,"limit":1000000} auf {"value":1001351,"limit":1000000} reduziert, ist aber noch immer nicht genug.
Das ändert aber nichts an der Tatsache, dass Parsoid offensichtlich anders zählt als der Legacy Parser --At40mha (Diskussion) 11:18, 15. Jun. 2026 (CEST)

Neuer Versuch für Gemeinden des Kantons Aargau: Die Ausrichtung der Tabellenfelder geändert von "Tabelle ohne Ausrichtung, die vier Zahlenspalten rechtsbündig" auf "Tabelle rechtsbündig, die zwei Namensspalten linksbündig". Das hat nichts geändert, immer noch 1001351 von 1000000 bei Parsoid und mit dem Legacy Parser funktioniert es (702531 von 1000000). --At40mha (Diskussion) 18:02, 26. Jun. 2026 (CEST)

Möglicherweise liegt das ja an den aufwändiger Rechenoperationen {{#expr:{{Metadaten Einwohnerzahl CH-AG|4324}}/{{Metadaten Fläche CH|4324}} round 0}}, die eigentlich gar nichts in einem Artikel zu suchen haben. Eine einzelne Berechnung dieser Art erzeugt rund 1800 Knotenbesuche. Das summiert sich bei den 196 Zeilen dann eben schnell auf 352.800 Knoten und das für so einfache Zahlen wie 321. Für mich gehört so etwas nicht in Artikel. Vielleicht mag Parsoid das ebensowenig wie ich. --Liebe Grüße, Lómelinde Diskussion 18:26, 26. Jun. 2026 (CEST)

Denke, da das Problem spezifisch zu Parsoid ist, kann man sich darauf fokussieren, v.a. da einfache Reparaturen fehlgeschlagen sind. Es wäre schön, wenn jemand auf Phabricator das Ticket suchen könnte oder sonst ggf. eins erstellen. Der Hinweis, dass es schon früher einen solchen Bug gab wo die Nodes falsch gezählt wurden, könnte allenfalls mit rein.--McBayne (Diskussion) 00:42, 28. Jun. 2026 (CEST)

Syntaxhighling kaputt, deprecated ResourceLoader module "moment"

Ich hab gerade meine .js- und .css-Dateien durchgeschaut, und finde nicht die Ursache für diese Fehlermeldungen in der Konsole von Firefox und Brave:

Aufruf unbekannte Seite (Beispiel)

[1]= Use of "mw.eventLog.eventInSample" is deprecated. Use "mw.eventLog.pageviewInSample()" instead. log.js:79:11
[1]
[2]= This page is using the deprecated ResourceLoader module "mediawiki.Uri". [1.43] Please use browser native URL. See https://www.mediawiki.org/wiki/Migrating_mw.Uri_to_URL startup.js:1319:11

Aufruf eines Artikel:

movePinnableElement: destination container not found  vector-toc-unpinned-container pinnableElement.js:103:11
Use of "mw.eventLog.eventInSample" is deprecated. Use "mw.eventLog.pageviewInSample()" instead. 2 log.js:79:11
[2]
Das Skript von "https://wikihistory.toolforge.org/wiki/getauthors.php?wiki=dewiki&page_id=7963281" wurde geladen, obwohl sein MIME-Typ ("text/html") kein für JavaScript gültiger MIME-Typ ist.

Bearbeiten eines Abschnitts dort:

This page is using the deprecated ResourceLoader module "moment". [1.44] Use mediawiki.DateFormatter or native Intl function instead. See https://phabricator.wikimedia.org/T146798 startup.js:1319:11
[1]
[1]
[2]

Gleichzeitig landet das Syntaxhighlighting oberhalb der Edit-Box und nicht auf dem Text selbst, sondern als Sammlung von farbigen Rechtecken. Liegt es an meinen manuellen Änderungen oder ist das Syntax. Eine Suche im Archiv, auf Phabricator und auf mediawiki brachte keine Ergebnisse, außer alte Phabricator-Commits (1, ) --Amtiss, SNAFU ? 12:34, 15. Jun. 2026 (CEST)

Bzgl. Syntaxhighlighting würde ich an deiner Stell mal testen, das in Benutzer:Amtiss/toolserverhelferleinconfig.js zu deaktivieren und stattdessen nur das in Spezial:Einstellungen#mw-prefsection-editing-syntax-highlighting zu nutzen, glaub das beißt sich etwas mit dem Skript. --Johannnes89 (Diskussion) 13:10, 15. Jun. 2026 (CEST)

(BK)

Ich habe noch nicht so restlos verstanden, in genau welcher Situation du was kaputt in der Seitendarstellung siehst.

Was die brav aufgezählten Fehlermeldungen angeht:

• Die sind irritierend, weil sie teilweise auch von MediaWiki selbst ausgelöst werden.
• startup.js:1319:11 ist eine MediaWiki-Funktion und die Stelle, die Warnungen protokolliert; die Konsole listet sie dabei selbst mit.
• Wenn du deprecated ResourceLoader module "moment" nicht benutzt, dann macht es eine noch nicht umgebaute MediaWiki-Funktion.
• Die weiteren desgleichen.
• deprecated ResourceLoader module "mediawiki.Uri" wurde in unseren Skripten häufiger mal benutzt; kann sein dass du eines aus dem deWP-Dunstkreis lädst und das dort migrieren sollte.
• Heißt: Wenn du selbst nichts von den deprecated programmiert hast, dann einfach ignorieren.

„Syntaxhighling kaputt“ wäre das größere Problem, aber hat nichts mit diesen Fehlermeldungen zu tun.

• Ist es das Syntaxhighliting von Wikitext oder von CSS/JavaScript?
• Welche Skin nutzt du, mit welchem Element hättest du Wikitext-Syntaxhighliting eingeschaltet, und kannst du es wieder abschalten?
• Eine Kollision mehrerer Syntaxhighliting, wie von Johannnes89 angedeutet, ist vorstellbar.

VG --PerfektesChaos 13:16, 15. Jun. 2026 (CEST)

Hast du eventuell versehentlich den →CodeMirror (Markierstift) angeschaltet? Das kann zu solchen Verdopplungen des Bearbeitungsfeldes führen, wenn man zugleich, so wie ich, schrarks Syntaxhighlight oder ein anderes Skript zur Syntaxhervorhebung verwendet. --Liebe Grüße, Lómelinde Diskussion 13:33, 15. Jun. 2026 (CEST)

Danke, das hat geholfen. Das Problem bestand sowohl bei Wikitext als auch bei Code und ist bei beidem weg. "brav aufgezählt", ja, war Absicht. Ich wollte ein vollständig Problembild liefern, wenn ich schon wen anders beim Aufräumen meiner Einstellungen brauche. Die Warnungen sind jetzt nicht weg. Ich kann gern noch Sachen nachschauen und den Entwicklern rückmelden, wenn ich wüsste, wo es herkommt und es keine veralteten Tools sind. Vielleicht interessiert ja Schnark, dass das Skript nicht zusammen genutzt werden kann. (Ich hatte Firefox ESR und Brave getestet.) Laut Hinweis eher nicht der Fall. --Amtiss, SNAFU ? 13:18, 17. Jun. 2026 (CEST)

„Vielleicht interessiert ja Schnark“ hast du gestrichen; ich wünschte, du könntest es Schnark mitteilen – ist aber leider schon seit zu langer Zeit inaktiv.

„Sachen nachschauen und den Entwicklern rückmelden“ – die gucken schon selber, und haben eine ToDo-Liste, dass es sowas noch im Verantwortungsbereich von MediaWiki gäbe; oder auch sonstige Zulieferung. Wenn alle diese Meldungen weg oder zumindest nicht mehr in MediaWiki sind, wird sowas eines Tages abgeschaltet.

VG --PerfektesChaos 15:57, 17. Jun. 2026 (CEST)

Bedanken fehlgeschlagen

Hallo. Wollte mich gerade in einer Diff-Ansicht bei einem User bedanken. Da kommt ein Pop-up-Kasten:

• Bedanken fehlgeschlagen (Fehlercode: http). Bitte erneut versuchen.

Erneuter Versuch klappte: wohl mit Klick auf Bedanken in der Ansicht der aktuellen Version rechts. Ob ein Klick auf das Okay im Kasten auch so geholfen hätte, ist damit unklar geblieben.

Alles gut soweit. Wollte nur kurz informieren.

Gruß, --Wi-luc-ky (Diskussion) 09:57, 26. Jun. 2026 (CEST)

Hatte ich auch schon zwei Mal ... schon etwas her. Ein zweiter Versuch hatte immer geklappt. "Fehlercode: http" ist wahrscheinlich sehr aussagekräftig, sonst hätte man diesen nicht gewählt. Danke für die Information. --Doc Taxon (Diskussion) 16:43, 26. Jun. 2026 (CEST)

Seit kurzem Probleme wg. Anubis von Techaro bei BeitragsStatsabfragen

Seit kurzem haben sich die X-tools, die den persönlichen Beitragszähler bereitstellen, durch den Einsatz von Fremdsoftware namens Anubis 'geschützt'. Leider ergibt sich für mich dadurch ein Blockieren der eigenen Stats-Abfragen, mithin Erschwernis und Verunsicherung anstatt höherer Sicherheit. Ich bin über 20 Jahre Wikipedianer, hatte da zuvor nie Schwierigkeiten. Ich plädiere dafür, Anubis wieder abzuschaffen oder zumindest optional zu machen. Ob es eine Werkstatt-Stelle/Person gibt, die genau dafür zuständig wäre, ist leider für mich nicht erkennbar; also melde ich mich hier. Eigene Versuche, irgendwelche FF-Add-ons für Wikipedia versuchweise teilabzuschalten, waren nicht ausreichend erfolgreich. -- Just N. (Diskussion) 11:14, 4. Jul. 2026 (CEST)

@Justus Nussbaum xtools wird massiv von KI-Abfragen geflutet, die das Tool in die Knie zu zwingen drohen, siehe WP:FZW#Beitragszähler nicht abrufbar. Deshalb braucht es Anubis, um die Bots draußen zu halten. Du musst lediglich in deinem Browser Cookies zulassen, dann solltest du https://xtools.wmcloud.org/ec/de.wikipedia.org/Justus_Nussbaum problemlos aufrufen können. Einen anderen Weg, dieses von Freiwilligen verwaltete Tool am Leben zu halten, gibt es aktuell nicht, Beschwerdebriefe bitte an die KI-Unternehmen, die das halbe Internet zerstören. --Johannnes89 (Diskussion) 14:12, 4. Jul. 2026 (CEST)

@Johannnes89 Danke meinerseits für die Info über die zugrundeliegende KI-Bots-Misere. War mir zuvor schleierhaft. Was zum Geier haben Kis in den für die wikipedia-interne Statsrückmeldungen zuständigen X-Tools zu suchen? Dossiers anlegen über fleißige Wikipedianer? Sowie über das Nutzungsverhalten der Leser? Ich teile deine skeptisch-kritische Haltung gegenüber destruktiven Tendenzen der KI-Unternehmen. -- Trotzdem wollte ich unbedingt zumindest dokumentieren, dass Anubis eben auch Probleme bereitet bei den Wikipedianern. Wenn sich dazu niemand äußert, wird ja immer gerne so getan, als gäbe es keine Probleme (hier Kollateralschäden von sw-techn. Problemlösungsversuchen). -- Just N. (Diskussion) 16:27, 14. Jul. 2026 (CEST)

Tabellennummerierung in der mobilen Ansicht

Hilfe:Tabellen/Zählung beginnt mit Nr 1 in der Kopfzeile in der mobilen Ansicht in der WP App (statt in der 1. Inhaltszeile). Wenn ich am Desktop auf mobile Ansicht umschalte, ist alles ok. Bsp: Weinviertel#Bevölkerungsreichste Städte und Gemeinden. lg --Herzi Pinki (Diskussion) 10:10, 12. Jul. 2026 (CEST)

Die App wird von dieser Funktion nicht unterstützt. -- hgzh 08:29, 13. Jul. 2026 (CEST)

dann sollte doch für Seiten, die in der WP App angezeigt werden sollen, dieses Feature nicht verwendet werden? Bevor in der App falsch nummeriert wird, vielleicht dort ganz weglassen? Der automatische Zähler funktioniert bei mir auch in der Vorschau nicht (FF). lg --Herzi Pinki (Diskussion) 14:35, 14. Jul. 2026 (CEST)

In dem Beispiel funktioniert die Vorschau bei Abschnittsbearbeitung nicht, weil dann die erforderliche Vorlage:Tabellenstile nicht vorhanden ist, diese wird am Artikelbeginn eingebunden. Bei Bearbeitung und Vorschau der gesamten Seite ist alles korrekt.

Zur App: dies ist ein grundsätzliches Problem. Wikimedia leistet sich die absolute Ressourcenverschwendung, für die Apps einen eigenen Wikitext-Parser bzw. irgendeinen Postprozessor zu betreiben, der allerlei Transformationen vornimmt, bspw. werden Tabellen standardmäßig eingeklappt, ein eigenes Themesystem angeboten etc. Warum man diesen alten Zopf nicht schon längst abgeschnitten hat und einfach den Output für die Mobilversion auf den Apps ausspielt, verstehe ich nicht. Man will (derzeit gerade Thema) die UI-Unterschiede zwischen Mobil und Desktop möglichst minimieren, brät aber für die obskure App zig Extrawürste. Dazu kommt, dass die App-Darstellung an vielen Stellen fehlerhaft ist, die Themes funktionieren nicht richtig und invertieren teils falsch, Default-CSS wird nicht geladen usw. Außerdem ist so gut wie nichts von diesem Output dokumentiert: welche Transformationen finden statt, welche Dokumentstruktur kann man erwarten, welche Änderungen gibt es – findet man nichts zu, läuft alles irgendwo entkoppelt vom Rest in irgendwelchen Parallelwelten. Debugging ist auch die reine Qual, man kommt zwar an den HTML-Output ran, kann diesen dann aber mit modernen Entwicklerwerkzeugen kaum auswerten und damit auch nur sehr schwer für die App optimierte Lösungen finden.

All dies tu ich mir nicht an. Es wird von der WMF schon erwartet, dass „die Community“ (sprich: die paar Hanseln, die durch den Wust von Abhängigkeiten und Änderungen noch durchsehen) eine Mobilversion, eine Desktopversion, einen hellen Modus, einen dunklen Modus, einen Modus mit fixierter Breite, einen Modus mit dynamischer Breite, einen Modus mit kleiner Schrifthöhe, einen Modus mit mittlerer Schrifthöhe und einen Modus mit großer Schrifthöhe unterstützen und Änderungen bitteschön postwendend umsetzen, wenn irgendwo jemand einen Rappel bekommen hat und eine mal angedachte und dann ein Jahr schlummernde Änderung nun ganz dringend innerhalb von einem Monat durchsetzen muss. Ich habe für mich beschlossen: die App erhält von mir, aus den o.g. Gründen, keinerlei Support.

Wer auf Vorlage:Tabellenstile/styles.css#L-167 fortfolgend den Selektorenwust noch mit Sonderfällen für die App aufblasen will, nur zu. Gruß, -- hgzh 08:36, 15. Jul. 2026 (CEST)

Einzelnachweis-Anzeige defekt

ist das nur bei mir so, liegt das am browser (firefox), der vollen Festplatte? wird an dem Problem gearbeitet? vor wenigen Tagen war es so, dass der Link gleich angezeigt und die bisherige Option des Sprungs nach unten, zusätzlich angeboten wurde nun tut sich, beim Klick auf die Fußnotenzahl, seit zwei Tagen gar nichts mehr :-( --Über-Blick (Diskussion) 18:51, 12. Jul. 2026 (CEST)

Bei mir funktioniert alles wie bisher. Bist Du Dir sicher, dass der Browser die Seite komplett geladen hatte? (sieht man daran, dass im Tab statt der Lade-Animation das Seitensymbol (Favicon), also das WP-W-Symbol angezeigt wird) Die Ladegeschwindigkeit aller Internetseiten ist sehr uneinheitlich, je nach Internet-Provider, aktueller Verbindungsbelastung usw. usf.

Es gibt auch die Situation, dass Helferlein o.ä. wie die Rechtschreibfehler-Anzeige das vollständige Laden verlangsamen. Deshalb hab ich per einem Browser-Addon spellcheck.toolforge.org/* deaktiviert, denn das brauchte ewig, bis es sich ausgekäst hatte. Solange die Seite nicht komplett geladen ist, funktioniert kaum was.--Hlambert63 (Diskussion) 21:41, 12. Jul. 2026 (CEST)

@Über-Blick nutzt du die Einzelnachweisvorschau oder Helferlein/Skripte wie navigation-popups, popuprefs oder Fußnoten-Tooltip? (In Spezial:Einstellungen#mw-prefsection-rendering-reading sollte dir ein Warnhinweis angezeigt werden, wenn Helferlein die Einzelnachweisvorschau deaktivieren). --Johannnes89 (Diskussion) 22:17, 12. Jul. 2026 (CEST)

Danke für eure Mühe und Infos, denke u.a. wird das an der übervollen Festplatte liegen, als Inhalts-Nerd und Technik-DAU habe Schwierigkeiten all diese technischen Details zu verstehen und gerade viel anderweitigen Stress. Werde mir das alles demnächst mal in Ruhe ansehen. Ist dann also kein generelles Problem. Danke auf

jeden Fall für eure Hilfe, Tips, Mühe. Liebe Grüße --Über-Blick (Diskussion) 22:39, 12. Jul. 2026 (CEST)

Wenn ich auf der Seite die Meldungen LUA-Fehler sehe: Gab es nicht letztens mal irgendwo Probleme, wenn Tabellen zu lang geworden sind? Ich weiß aber nicht, ob das auch hier die Ursache sein kann.-Hlambert63 (Diskussion) 21:32, 13. Jul. 2026 (CEST)

Seite mit zu vielen Dateieinbindungen

Hallo! Lassen sich Seiten wie Wikipedia:WikiProjekt Wappen/Archiv/2022 mit zu vielen Dateieinbindungen irgendwie in eine Wartungskategorie versammeln, also automatisch? --Doc Taxon (Diskussion) 22:55, 16. Jul. 2026 (CEST)

Kategorie:Wikipedia:Seite mit zu vielen Medieneinbindungen ist dafür vorgesehen und müsste sich peu a peu befüllen. -- hgzh 23:10, 16. Jul. 2026 (CEST)

Das scheint übrigens wieder ein Problem mit den neuen Parser (Parsoid) zu sein. Mit dem "Legacy-Parser" wird die Seite Wikipedia:WikiProjekt Wappen/Archiv/2022 korrekt angezeigt. --At40mha (Diskussion) 08:53, 17. Jul. 2026 (CEST)

@Johannnes89: Ist dieser Fehler schon bugreportet? Parserfehler haben wir ja nun schon zig viele. --Doc Taxon (Diskussion) 19:50, 18. Jul. 2026 (CEST)

Aus Sicht der Entwickler ist es kein Fehler, irgendein Limit sollte es zudem schon allein aus Performancegründen geben. Mein Browser braucht jedenfalls spürbar länger, die verlinkte Seite zu laden (auch im legacy parser). Die Kategorie wurde ja bewusst eingeführt, damit Autoren besser mit dem Limit umgehen können. Das Ticket dazu ist phab:T430854. --Johannnes89 (Diskussion) 20:35, 18. Jul. 2026 (CEST)

@Johannnes89: Das landet aber nicht in der Kategorie, vermutlich weil die Anzeige mit dem Legacy-Parser geht. --Doc Taxon (Diskussion) 20:38, 18. Jul. 2026 (CEST)

Es ist noch Geduld gefragt. MediaWiki_1.47/wmf.11 hat die neue Kategorie zwar angelegt ("Add new tracking category "media-limit-reached""), der Mechanismus zum Befüllen aus Parsoid fehlt aber noch (Details in T430854).--Kallichore (Diskussion) 20:49, 18. Jul. 2026 (CEST)

Inzwischen wurde das Limit übrigens auf 5000 Bilder hochgesetzt, was Probleme bei den meisten Seiten behoben hat. --Johannnes89 (Diskussion) 20:14, 20. Okt. 2026 (CEST)

Die CSS-Klassen "hintergrundfarbeX" funktionieren (scheinbar) nicht in der Wikipedia App

Ergänzung: Selbiges für class="wikitable sortable" oder class="wikitable tabelle-zaehler"

Hallo, irgendwie scheint es ein Problem bei der Darstellung von Tabellen mit den CSS-Farbklassen nach dem Schema class="hintergrundfarbeX" (→Hilfe:Farbe#Klassen) in der Wikipedia App (unter Android) zu geben. Ein Beispiel einer Tabelle wäre die Liste der Wikipedias nach Sprachen (Ergänzung: mit dem neuen Wissen inzwischen bearbeitet und nun somit leider ohne Verwendung von class="hintergrundfarbeX", hier die betreffende alte Version: Liste der Wikipedias nach Sprachen mit CSS) oder die Tabelle unter Wikipedia:Sprachen#Chronologie (Ergänzung: inzwischen bearbeitet und nun leider ohne Verwendung von class="hintergrundfarbeX", hier die betreffende alte Version: Wikipedia:Sprachen mit CSS). Ansonsten ist es gar nicht so leicht, weitere Beispiele zu finden. Offensichtlich werden die Klassen – entgegen ihres ursprünglichen Anliegens der einheitlichen Gestaltung und der Anpassungsfähigkeit an die unterschiedlichen Skins und Anzeigemodi – kaum noch verwendet, weshalb das Problem evtl. auch noch nirgends groß aufgefallen ist. Ein entsprechender Hinweis auf Hilfe:Farbe#Klassen wäre dann sinnvoll, oder natürlich eine Behebung des Problems. Grüße -- W like wiki  ^{Bitte Anpingen! • Postiv1 • Postiv2}  12:10, 22. Jul. 2026 (CEST)

Ja, die funktionieren nicht, siehe dazu auch mein längerer Beitrag in #c-Hgzh-20260715063600-Herzi_Pinki-20260714123500. Sämtliche Systemgadgets werden in der App nicht geladen, ist eine weitere Unzulänglichkeit dieser Dinger. Gruß, -- hgzh 12:15, 22. Jul. 2026 (CEST)

Es ist eher so, dass die Apps kaum verwendet werden, deshalb fällt das nicht so oft auf. Aber ja, das müssen die App-Entwickler beheben. --XanonymusX (Diskussion) 12:25, 22. Jul. 2026 (CEST)

Hallo, erstmal danke für die schnellen Antworten! @Hgzh: Das, was du da oben Herzi Pinki zu den Vorgängen bei der Wikimedia und der "Entwicklung" der App schreibst, klingt alles sehr demotivierend (und eigentlich auch skandalös)! @XanonymusX: So selten wird die App gar nicht verwendet! Im Google Playstore zeigt es mir 50 Mio + Downloads an.
Wie geht man nun mit dem Problem um? Das sollte ja irgendwie abgeglichen werden und vor allem den Wikipedia-Autoren irgendwo erklärt werden!? Entweder muss auf allen Hilfeseiten, wo es um CSS-Klassen geht – wie Hilfe:Farbe#Klassen oder auch Hilfe:Tabellen/Sortierung – ein entsprechender Hinweis eingefügt werden, etwa:

Dieses CSS-Klasse wird von der mobilen App noch(?) nicht unterstützt!

Dabei stellt sich allerdings die Frage: Wird an einer Integration von hintergrundfarbeX oder sortable (oder tabelle-zaehler) überhaupt gearbeitet? Ansonsten müsste ja auf den Hilfeseiten generell von der Verwendung von solchen CSS-Klassen abgeraten werden, da man als Autor davon ausgeht, dass die eingebrachten Informationen – wie etwa Farbhervorhebungen – auch in der App zu sehen sind. Grüße -- W like wiki  ^{Bitte Anpingen! • Postiv1 • Postiv2}  13:34, 22. Jul. 2026 (CEST)

Was ich mit „kaum verwendet“ meine: In den vergangenen drei Monaten wurde Deutschland ca. 895.000-mal aufgerufen. Davon waren ca. 343.000 Aufrufe von Desktop, ca. 513.000 Aufrufe von der Mobilversion, und nur ca. 39.000 Aufrufe von den Apps. Das sind gerade mal 5 %. Ehrlicherweise finde ich das vernachlässigbar, bei all der Arbeit, die wir schon mit den anderen „Variationen“ haben, die wir berücksichtigen müssen. Wir sollten nicht unnötig die Darstellung für 95 % der Fälle anpassen, weil die App-Entwicklung so hinterherhinkt. Daher bin ich auch der Meinung, dass wir hier nichts machen sollten. Gruß --XanonymusX (Diskussion) 13:50, 22. Jul. 2026 (CEST)

Tabelle

kann hier jemand helfen?

Diskussion:Internationaler Preis des Westfälischen Friedens#Tabelle

Gruß --Über-Blick (Diskussion) 17:21, 1. Aug. 2026 (CEST)

Siehe dort. Gruß, -- hgzh 17:34, 1. Aug. 2026 (CEST)

Vielen Dank, wobei die beiden ersten Spalten sehr breit sind. Ob du da vielleicht noch etwas nachjustieren könntest? --Gruß Über-Blick (Diskussion) 19:13, 1. Aug. 2026 (CEST)

Das würde ich besser dem Browser überlassen; der sucht die passende Breitenaufteilung. -- hgzh 21:22, 28. Aug. 2026 (CEST)

Foto-Größe vereinheitlichen

Straße der Erinnerung

kann hier jemand helfen, das die Fotos der Büsten, an der alphabetischen Namensliste orientiert, unter der Aufzählung, in gleicher Größe wiedergeben werden?

Gruß --Über-Blick (Diskussion) 19:16, 1. Aug. 2026 (CEST)

Versteh nicht, was du von der Technik-Werkstatt willst. Wäre das nicht was für WP:FZW?

Bei mir sind die Bilder übrigens alle gleich hoch. Gleich groß geht ja wegen der unterschiedlichen Proportionen nicht. --Magnus (Diskussion) 19:25, 1. Aug. 2026 (CEST)

drei Bilder sind rechts am Rand, drei habe ich unten eingefügt aus dem Artikel über die Stiftung, der überwiegend aus den Infos zur "Straße der Erinnerung" bestand

die Bilder rechts sind groß, die Bilder unten klein

sinnvoll wären alle Bilder unten in mittlerer Größe

--Über-Blick (Diskussion) 20:13, 1. Aug. 2026 (CEST) die Bilder unten sind

Hilfe:Bilder und Hilfe:Galerie beschreiben die Eigenschaften von eingebundenen Bildern einschließlich der Möglichkeiten, die Bildgrößen gegebenenfalls anzupassen. Was soll die Technik/Werkstatt da noch tun? --At40mha (Diskussion) 20:20, 1. Aug. 2026 (CEST)

URL-Prüfung: Technische Zweitmeinung

Hallo, erzeugt dieser Link, der von mir mit der Meldung HTML:Script-inf (Susp) aufrufbar ist, auch bei anderen diese Fehlermeldung, oder ist das nur eine Fehl-Erkennung bei mir?

Inhaltlich handelt sich sich um eine qualifizierte und relevante Rezension, die den Artikel bereichern würde.

Dank im Voraus für Einschätzungen vor einer Sichtung. Gruß, --Wi-luc-ky (Diskussion) 22:01, 1. Aug. 2026 (CEST)

Bei mir kommt kein Fehler, wenn ich diesen rentree-Link aufrufe. Im Artikel ist zwar irgendwo ein Vorlagenfehler, aber nicht an der Stelle, an der dieser rentree-Link reingekommen ist.--Hlambert63 (Diskussion) 12:53, 2. Aug. 2026 (CEST)

Danke, Hlambert63, für die Rückmeldung.

Ich werde das gleich – etwas bearbeitet, da der Link im Artikel noch einen Schreibfehler hat, den ich oben korrigiert habe – mit einem Kommentar auf die Fehlermeldung in das Lemma einstellen.

Der Fehler kommt von der gestern veränderten Vorlage:Krünitz, den ich mit den anderen betroffenen Lemmata fixe.

Gruß, --Wi-luc-ky (Diskussion) 13:57, 2. Aug. 2026 (CEST)

Probleme mit <ref> und Captcha bei unangemeldetem Edit

Moin! Ich habe unter Win11/Firefox/privatesFenster bei Vitamin_E#Vorkommen versucht, einen Tippo zu korrigieren. Erst wurde das Captcha nicht erkannt, dann verschwand die Captcha-Abfrage ganz, das (dann zwangsläufige) Nichtausfüllen wurde aber bemängelt.

Vermutlich unabhängig davon: Schon bei der Vorschau kamen mehrere Fehlermeldungen zu ref: Referenzfehler: Ungültiges <ref>-Tag; kein Text angegeben für Einzelnachweis mit dem Namen :2.

Edit nach Anmeldung war unproblematisch. --OpusNovum (Diskussion) 10:15, 6. Aug. 2026 (CEST)

Zu letzterem: Du hast einen Abschnitt des Artikels bearbeitet, der EN mit dem Namen ":2" war aber außerhalb definiert. Dazu gibt es eine entsprechende Warnmeldung (sinngemäß "kann nicht angezeigt werden, da außerhalb definiert). Seit kurzem wird aber stattdessen die von dir zitierte "kein Text angegeben"-"Warnung angezeigt, das ist in phab:T431137 gemeldet, Schuld ist der neue Parser (mw:Parsoid). Idealerweise würde die Vorschau eines Tages mal so verbessert werden, dass sie auch bei der Abschnittsbearbeitung EN anzeigt, die woanders definiert sind (phab:T124840). --Johannnes89 (Diskussion) 10:52, 6. Aug. 2026 (CEST)

monobook-Skripte funktionieren nicht mehr

Moin, seit einer Weile (ca. ein paar Wochen) funktionieren die Skripte FixQuote, FixEnt und FixMark aus meiner Benutzer:XenonX3/monobook.js nicht mehr. Wenn ich im Werkzeugkasten drauf klicke, passiert nichts. Kann jemand die Ursache finden? Danke! XenonX3 – (☎) 15:42, 9. Aug. 2026 (CEST)

Ich habe deine Seite durchgescrollt, aber keine Auffälligkeiten gesehen.

• Benutzer:PDD/convertEntities.js soll wohl eine der Aktionen sein, aber unverdächtig.
• Bei 1766 Zeilen unübersichtlich.

„seit einer Weile (ca. ein paar Wochen)“

• Echte globale Veränderungen gab es kaum.
• Global hinge das eher mit Parsoid zusammen, aber das beeinflusst ja nicht den Wikitext, weil vorher, aber möglicherweise hinterher, falls versucht wird, aus dem HTML-Dokument der Vorschau etwas abzugreifen, und das nicht robust wäre und fehlschlägt.
• Ursachen mögen in fremden Skripten liegen, aber das werden separate Threads.

Tipps:

1. Gibt es in der JavaScript-Konsole deines Browser Fehlermeldungen? Falls ja, könnte da was abstürzen und alles Spätere mit in den Abgrund reißen.
2. Die PDD-Anwendungs-Community wüsste eher was.

Die Skriptsammlung ist für fehlende Robustheit+Dokumentation+Wartungsfähigkeit bekannt.

VG --PerfektesChaos 23:45, 9. Aug. 2026 (CEST)

Danke für die Rückmeldung! Wenn ich einen Artikel bearbeiten möchte, füllt sich die Konsole mit Folgendem:

Inhalt Fehlerkonsole

16:34:07.399 Laden fehlgeschlagen für das <script> mit der Quelle "https://de.wikipedia.org/w/index.php?title=User:PDD/hideNsLinkSearch.js&action=raw&ctype=text/javascript&maxage=86400&smaxage=60&bcache=1&debug=false". index.php:1:1
16:34:08.513 GET
https://meta.wikimedia.org/w/index.php?title=User:Xiplus/TwinkleGlobal/morebits.css&action=raw&ctype=text/css
[HTTP/2 200 OK 0ms]
16:34:08.513 [Twinkle_global_xiplus] Loading Twinkle_global_xiplus... index.php:47:10
16:34:08.514 GET
https://meta.wikimedia.org/w/index.php?title=User:Hoo_man/functions.js&action=raw&ctype=text/javascript
[HTTP/2 304 174ms]
16:34:08.514 [Twinkle_global_xiplus] Loading Twinkle_global_xiplus... (1/7) index.php:47:10
16:34:08.514 [Twinkle_global_xiplus] Loading Twinkle_global_xiplus... (2/7) index.php:47:10
16:34:08.514 [Twinkle_global_xiplus] Loading Twinkle_global_xiplus... (3/7) index.php:47:10
16:34:08.514 [Twinkle_global_xiplus] Loading Twinkle_global_xiplus... (4/7) index.php:47:10
16:34:08.514 [Twinkle_global_xiplus] Loading Twinkle_global_xiplus... (5/7) index.php:47:10
16:34:08.514 [Twinkle_global_xiplus] Loading Twinkle_global_xiplus... (6/7) index.php:47:10
16:34:08.514 [Twinkle_global_xiplus] Loading Twinkle_global_xiplus... (7/7) index.php:47:10
16:34:08.518 Referrer Policy: Die weniger eingeschränkte Referrer Policy "origin-when-cross-origin" für die Website-übergreifende Anfrage wird ignoriert: https://meta.wikimedia.org/w/api.php?action=query&format=json&origin=https%3A%2F%2Fde.wikipedia.org&meta=userinfo%7Ctokens api.php
16:34:08.518 Referrer Policy: Die weniger eingeschränkte Referrer Policy "origin-when-cross-origin" für die Website-übergreifende Anfrage wird ignoriert: https://www.wikidata.org/w/api.php?action=query&format=json&origin=https%3A%2F%2Fde.wikipedia.org&meta=userinfo%7Ctokens api.php
16:34:08.519 Referrer Policy: Die weniger eingeschränkte Referrer Policy "origin-when-cross-origin" für die Website-übergreifende Anfrage wird ignoriert: https://meta.wikimedia.org/w/index.php?title=User:XenonX3/twinkleoptions.js&action=raw&ctype=text/javascript&happy=yes index.php
16:34:08.519 [Twinkle_global_xiplus] Twinkle Done index.php:47:10
16:34:08.533 GET
https://www.wikidata.org/w/index.php?title=MediaWiki:Gadget-infoboxExport.js&action=raw&ctype=text/javascript
[HTTP/2 304 440ms]
16:34:08.548 Referrer Policy: Die weniger eingeschränkte Referrer Policy "origin-when-cross-origin" für die Website-übergreifende Anfrage wird ignoriert: https://www.mediawiki.org/w/index.php?title=XTools/ArticleInfo.js&action=raw&ctype=text/javascript index.php
16:34:08.562 XHR
GET
https://meta.wikimedia.org/w/api.php?action=query&format=json&origin=https://de.wikipedia.org&meta=userinfo|tokens
[HTTP/2 200 192ms]
16:34:08.569 XHR
GET
https://meta.wikimedia.org/w/api.php?action=query&format=json&origin=https://de.wikipedia.org&meta=userinfo|tokens
[HTTP/2 200 265ms]
16:34:08.570 XHR
GET
https://www.wikidata.org/w/api.php?action=query&format=json&origin=https://de.wikipedia.org&meta=userinfo|tokens
[HTTP/2 200 215ms]
16:34:08.571 GET
https://meta.wikimedia.org/w/index.php?title=User:XenonX3/twinkleoptions.js&action=raw&ctype=text/javascript&happy=yes
[HTTP/2 304 215ms]
16:34:08.625 GET
https://www.mediawiki.org/w/index.php?title=XTools/ArticleInfo.js&action=raw&ctype=text/javascript
[HTTP/2 304 30ms]
16:34:08.625 GET
https://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEdDiff.js&action=raw&ctype=text/javascript
[HTTP/2 304 241ms]
16:34:08.626 GET
https://de.wikipedia.org/w/index.php?title=Benutzer:Schnark/js/artikel-statistik.js&action=raw&ctype=text/javascript
[HTTP/2 304 176ms]
16:34:08.637 XHR
GET
https://de.wikipedia.org/w/api.php?action=query&format=json&prop=pageprops|extlinks&ppprop=wikibase_item&elquery=commons.wikimedia.org&pageids=7626597&continue=
[HTTP/2 200 177ms]
16:34:08.640 XHR
GET
https://de.wikipedia.org/w/index.php?title=Benutzer:Forrester/düp-helperfunctions-monobook.js&action=raw&ctype=text/javascript
[HTTP/2 304 169ms]
16:34:08.640 GET
https://de.wikipedia.org/w/index.php?title=User:РDD3/alertOnChanges.js&action=raw&ctype=text/javascript&maxage=86400&smaxage=60&bcache=1&debug=false
[HTTP/2 304 397ms]
16:34:08.645 GET
https://de.wikipedia.org/w/index.php?title=Benutzer:D/monobook/api.js&action=raw&ctype=text/javascript
[HTTP/2 304 177ms]
16:34:08.646 GET
https://de.wikipedia.org/w/index.php?title=MediaWiki:Gadget-Vorlagenmeister.css&bcache=1&maxage=1209600&action=raw&ctype=text/css
[HTTP/2 304 212ms]
16:34:08.648 GET
https://de.wikipedia.org/w/index.php?title=Benutzer:DerHexer/addvrts.js&action=raw&ctype=text/javascript
[HTTP/2 304 195ms]
16:34:08.650 XHR
GET
https://de.wikipedia.org/w/api.php?format=xml&action=query&prop=categoryinfo&titles=Kategorie:Benutzer:Mentor gesucht
[HTTP/2 200 232ms]
16:34:08.651 XHR
GET
https://de.wikipedia.org/w/api.php?format=xml&action=query&prop=categoryinfo&titles=Kategorie:Benutzer:Wunschmentor gesucht
[HTTP/2 200 274ms]
16:34:08.656 Referrer Policy: Die weniger eingeschränkte Referrer Policy "origin-when-cross-origin" für die Website-übergreifende Anfrage wird ignoriert: https://commons.wikimedia.org/w/api.php?titles=User%3AJack%20who%20built%20the%20house%2FconvenientDiscussions-i18n%2Fde.js&origin=*&format=json&formatversion=2&uselang=content&maxage=86400000&smaxage=86400000&action=query&prop=revisions|info&rvslots=main&rvprop=content&rvlimit=1 api.php
16:34:08.665 XHR
GET
https://commons.wikimedia.org/w/api.php?titles=User:Jack who built the house/convenientDiscussions-i18n/de.js&origin=*&format=json&formatversion=2&uselang=content&maxage=86400000&smaxage=86400000&action=query&prop=revisions|info&rvslots=main&rvprop=content&rvlimit=1
[HTTP/2 200 0ms]
16:34:08.679 GET
https://en.wikipedia.org/w/index.php?title=User:PerfektesChaos/js/preferencesGadgetOptions/r.js&action=raw&ctype=text/javascript&bcache=1&maxage=604801
[HTTP/2 304 448ms]
16:34:08.684 XHR
GET
https://de.wikipedia.org/w/api.php?action=query&format=json&prop=categories&titles=Chauray&clcategories=Kategorie:Wikipedia:Löschkandidat&cllimit=max
[HTTP/2 200 223ms]
16:34:08.684 XHR
GET
https://de.wikipedia.org/w/api.php?action=query&format=json&titles=Chauray&prop=revisions&rvlimit=2&rvprop=content|user|timestamp&rvslots=main&formatversion=2
[HTTP/2 200 202ms]
16:34:08.697 Die Ressource von "https://de.wikipedia.org/wiki/Benutzer:CennoxX/js/bkl-replace.js" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). index.php
16:34:08.698 Laden fehlgeschlagen für das <script> mit der Quelle "https://de.wikipedia.org/wiki/Benutzer:CennoxX/js/bkl-replace.js". index.php:1:1
16:34:08.711 GET
https://meta.wikimedia.org/w/index.php?title=User:Hoo_man/tool.css&action=raw&ctype=text/css
[HTTP/2 200 OK 0ms]
16:34:08.718 Referrer Policy: Die weniger eingeschränkte Referrer Policy "origin-when-cross-origin" für die Website-übergreifende Anfrage wird ignoriert: https://meta.wikimedia.org/w/index.php?title=User:Hoo_man/lang/de/smart_rollback.js&action=raw&ctype=text/javascript index.php
16:34:08.727 GET
https://meta.wikimedia.org/w/index.php?title=User:Hoo_man/lang/de/smart_rollback.js&action=raw&ctype=text/javascript
[HTTP/2 304 159ms]
16:34:08.747 GET
https://de.wikipedia.org/w/index.php?title=Benutzer:DerHexer/logblock.js&action=raw&ctype=text/javascript
[HTTP/2 304 195ms]
16:34:08.766 Referrer Policy: Die weniger eingeschränkte Referrer Policy "origin-when-cross-origin" für die Website-übergreifende Anfrage wird ignoriert: https://meta.wikimedia.org/w/api.php?action=query&format=json&origin=https%3A%2F%2Fde.wikipedia.org&meta=userinfo%7Ctokens api.php
16:34:08.769 XHR
GET
https://meta.wikimedia.org/w/api.php?action=query&format=json&origin=https://de.wikipedia.org&meta=userinfo|tokens
[HTTP/2 200 222ms]
16:34:08.829 Referrer Policy: Die weniger eingeschränkte Referrer Policy "origin-when-cross-origin" für die Website-übergreifende Anfrage wird ignoriert: https://www.wikidata.org/w/api.php?action=wbgetentities&format=json&ids=Q1084405&props=sitelinks&sitefilter=commonswiki|dewikibooks|specieswiki|dewikiquote|dewikisource|dewikiversity|dewikivoyage|dewiktionary&formatversion=2&origin=* api.php
16:34:08.842 XHR
GET
https://www.wikidata.org/w/api.php?action=wbgetentities&format=json&ids=Q1084405&props=sitelinks&sitefilter=commonswiki|dewikibooks|specieswiki|dewikiquote|dewikisource|dewikiversity|dewikivoyage|dewiktionary&formatversion=2&origin=*
[HTTP/2 200 196ms]
16:34:08.892 GET
https://en.wikipedia.org/w/index.php?title=User:Cacycle/diff.js&action=raw&ctype=text/javascript
[HTTP/2 304 205ms]
16:34:08.938 Referrer Policy: Die weniger eingeschränkte Referrer Policy "origin-when-cross-origin" für die Website-übergreifende Anfrage wird ignoriert: https://www.wikidata.org/w/api.php?callback=jQuery371011607013835317859_1786545248092&format=json&action=wbgetentities&sites=dewiki&titles=Chauray&props=info%7Clabels%7Cdescriptions%7Caliases&languages=de&maxage=30&smaxage=30 api.php
16:34:08.943 GET
https://www.wikidata.org/w/api.php?callback=jQuery371011607013835317859_1786545248092&format=json&action=wbgetentities&sites=dewiki&titles=Chauray&props=info|labels|descriptions|aliases&languages=de&maxage=30&smaxage=30
[HTTP/2 200 214ms]
16:34:09.040 Uncaught (in promise) TypeError: can't access property "sitelink", EightSisters.sisterData[key] is undefined
gotWikidataId https://de.wikipedia.org/w/index.php?title=Benutzer:Wurgl/8Schwestern.js&action=raw&ctype=text/javascript:103
index.php:103:20
gotWikidataId https://de.wikipedia.org/w/index.php?title=Benutzer:Wurgl/8Schwestern.js&action=raw&ctype=text/javascript:103
16:34:09.148 GET
https://en.wikipedia.org/w/index.php?title=User:PerfektesChaos/js/versionControl/r.js&action=raw&ctype=text/javascript
[HTTP/2 304 176ms]

Ich habe länger nichts an meinen Skripten geändert, also muss es einen anderen Grund haben. XenonX3 – (☎) 16:39, 12. Aug. 2026 (CEST)

Na, da sind schon mal zwei verräterische Infos mit bei.

16:34:07.399 Laden fehlgeschlagen für das <script> mit der Quelle "https://de.wikipedia.org/w/index.php?title=User:PDD/hideNsLinkSearch.js&action=raw&ctype=text/javascript&maxage=86400&smaxage=60&bcache=1&debug=false".

User:PDD/hideNsLinkSearch.js existiert aber, und ist seit 15 Jahren unverändert.

• Wird mittels importJSL() eingebunden.
• &smaxage=60 ist dabei komplett veraltet; die &maxage=86400&bcache=1 vermutlich zurzeit wirkungslos jedoch unschädlich.
• https://de.wikipedia.org/w/index.php?title=User:PDD/hideNsLinkSearch.js&action=raw&ctype=text/javascript&maxage=86400&smaxage=60&bcache=1&debug=false kann ich problemlos aufrufen. Seltsam. Server-Kollaps, zu viele Server-Anfragen in zu wenigen Millisekunden? Gibt ein ähnliches Problem bei Wiki-Seiten mit sehr vielen Bildchen.

16:34:08.697 Die Ressource von "https://de.wikipedia.org/wiki/Benutzer:CennoxX/js/bkl-replace.js" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). index.php
16:34:08.698 Laden fehlgeschlagen für das <script> mit der Quelle "https://de.wikipedia.org/wiki/Benutzer:CennoxX/js/bkl-replace.js". 

Benutzer:CennoxX/js/bkl-replace.js braucht hinten dran ein &action=raw&ctype=text/javascript wie alle anderen.

• In der Form isses HTML und kein JavaScript.
• Verantwortlich ist aber irgendwer anders in einer eingebundenen JS-Seite.

Die restlichen Meldungen sind hier irrelevant.

Nächster Schritt wäre, an charakteristischen Stellen bei dir JavaScript-Zeilen einzufügen, wo das syntaktisch möglich ist:

console.log( "XenonX3.debugging #1" )
console.log( "XenonX3.debugging #2" )
console.log( "XenonX3.debugging #3" )
console.log( "XenonX3.debugging vor Dingens" )
console.log( "XenonX3.debugging nach Dingens" )
console.log( "XenonX3.debugging Funktion Dingsbums() gestartet" )

Die würden in der Konsole aufgelistet, und damit ließe sich weiter einkreisen, was erreicht wird und was nicht.

VG --PerfektesChaos 17:47, 12. Aug. 2026 (CEST)

Hinweis auf ein Problem

ich bekomme hier

https://de.wikipedia.org/w/index.php?title=Nekrolog_August_2026&diff=269806531&oldid=269806494

ständig folgende Nachricht:

Die Berechnung deiner Änderungen hat zu lang gedauert. Deshalb könnte die unten stehende Beschreibung nicht optimal sein.

wäre schön, wenn das geändert werden könnte

--Über-Blick (Diskussion) 12:54, 20. Aug. 2026 (CEST)

@Über-Blick du hast wohl (absichtlich / versehentlich?) beim Versionsvergleich die Option "Visuell" statt "Klassisch" gewählt. Die visuelle Option ist bei langen Tabellen u.Ä. manchmal überfordert, das Problem wird sich auch nicht so leicht beheben lassen. Einfach in solchen Fällen auf die klassische Diffansicht umschalten, da erhältst du keine Warnung und den normalen Wikitext-Diff. --Johannnes89 (Diskussion) 15:42, 20. Aug. 2026 (CEST)

Danke Johannnes89 du kommst der Sache schon recht nahe. Bei mir erschien irgendwann diese "Visuelle" Version - da ich damit immer wieder Probleme hatte, wollte ich hier vor einiger Zeit nachfragen wie und wo ich wieder zur alten "Klassisch"-Version zurück kann - doch dann funktionierte es und ich dachte, ich würde mich mit der Frage blamieren, da habe ich dass dann hier wieder gelöscht

nun brauche ich also nen Hinweis wo ich den button zur Auswahl finde, damit ich zurück zur alten Darstellungsweise, der "Klassischen" kommen .

Gruß --Über-Blick (Diskussion) 21:48, 20. Aug. 2026 (CEST)

Siehe verlinkte Hilfeseite, oben (rechts) in der Diff-Ansicht gibt es nebeneinander die Buttons "Visuell|Klassisch", dunkelblau hinterlegt ist der Button, der gerade ausgewählt ist, du klickt dann daneben auf "Klassisch". --Johannnes89 (Diskussion) 06:57, 21. Aug. 2026 (CEST)

ok Danke, hab`s nun gefunden --Über-Blick (Diskussion) 14:54, 22. Aug. 2026 (CEST)

arabische Internetquelle vermurkst?

جولة داخل مصنع الورق بمدينة قوص.. 120 ألف طن الطاقة الإنتاجية سنويا بنسبة 25 % من السوق المحلي.. والتصدير للسودان وليبيا وسوريا بنحو 20%. 19. Mai 2024, abgerufen am 20. Dezember 2024 (arabisch). 

aus Qus (Stadt), schaut nicht hübsch formatiert aus (überschreibt sich selbst). parsoid oder nicht macht keinen Unterschied. lg --Herzi Pinki (Diskussion) 00:43, 23. Aug. 2026 (CEST)

So weit ich weiß, müssen die RTL-Schriften immer noch extra in die entsprechende Sprachvorlage eingepackt werden, um korrekt dargestellt zu werden, also hier zB: جولة داخل مصنع الورق بمدينة قوص.. 120 ألف طن الطاقة الإنتاجية سنويا بنسبة 25 % من السوق المحلي.. والتصدير للسودان وليبيا وسوريا بنحو 20% 19. Mai 2024, abgerufen am 20. Dezember 2024 (arabisch).  Gruß—XanonymusX (Diskussion) 01:12, 23. Aug. 2026 (CEST)

Vorstehend ist grundsätzlich schon mal richtig.

H:RTL pflegt erstmal zu helfen.

• جولة داخل مصنع الورق بمدينة قوص.. 120 ألف طن الطاقة الإنتاجية سنويا بنسبة 25 % من السوق المحلي.. والتصدير للسودان وليبيا وسوريا بنحو20% 19. Mai 2024, abgerufen am 20. Dezember 2024 (ar-EG). 
• Endet auf (beginnt mit) 20%, und wenn du a.a.O. weiter unter UBA liest, dann siehst du, dass dies eine ambivalente Zeichenkette ist – ob das RTL oder LTR ist, ordnet sich nicht von selbst richtig zu.
• Damit ist zunächst mal der 19. Mai 2024 sauber, weil die 19. verheiratet sich ambivalent mit 20%.

Dann ist da aber sowohl 25% wie 20% am Start, und das gehört sich nicht untergejubelt. Auch 120 weiß nicht so genau was es ist.

• ألف طن الطاقة الإنتاجية سنويا بنسبة 120 جولة داخل مصنع الورق بمدينة قوص.. %20% من السوق المحلي.. والتصدير للسودان وليبيا وسوريا بنحو %25. In: vetogate.com. 19. Mai 2024, abgerufen am 20. Dezember 2024 (ar-EG). 

Wenn eine Webseite komplett auf RTL eingestellt ist, wird vieles einfacher. RTL mitten in einer LTR-Webseite bildet das nur unvollkommen ab.

VG --PerfektesChaos 02:12, 23. Aug. 2026 (CEST)

ich habe das so mal in Qus (Stadt) eingebaut, danke lg --Herzi Pinki (Diskussion) 15:26, 24. Aug. 2026 (CEST)

Das sieht im Quelltext erst mal auch ziemlich komisch aus. Im Artikel passt's dann aber.

Seyyed Mohammad Javad Mirkhani: عملیات «طریق‌القدس» DefaPress.ir, 28. November 2024, abgerufen am 25. August 2026. 

Doc Taxon (Diskussion) 14:53, 25. Aug. 2026 (CEST)

Farbwechsel bei Blaulinks

Hallo, seit einiger Zeit bemerke ich, dass der automatische Farbwechsel bei Blaulinks von hell- zu dunkelblau, nachdem man eine Seite aufgerufen hat, nur teilweise funktioniert. Ich habe versucht, eine Systematik zu erkennen (Lage im Alphabet…), was mir aber nicht gelungen ist. Es scheint völlig zufällig bzw. willkürlich zu sein, ob ein Farbwechsel stattfindet. Dabei ist er ja praktisch, denn man sieht sofort, ob man eine Seite schon mal aufgerufen hat oder noch nicht. – Es hat jahrelang immer funktioniert, warum jetzt nicht? Ich bitte um eine Erklärung. Danke! --Alfred Kiefer (Diskussion) 12:56, 27. Aug. 2026 (CEST)

Dieses Verhalten wird nicht von der Wikipedia gesteuert, sondern von deinem Browser. Welchen verwendest du, und hast du in letzter Zeit irgendwelche Änderungen daran vorgenommen (zum Beispiel Erweiterungen installiert)? --Tkarcher (Diskussion) 19:40, 27. Aug. 2026 (CEST)

Ich verwende Safari. In der letzten Zeit gab es keine Änderungen und Erweiterungen, deshalb ist es nach wie vor ein Rätsel, zumal es jahrelang immer funktioniert hat. --Alfred Kiefer (Diskussion) 10:46, 28. Aug. 2026 (CEST)

Hm. Einer kurzen Internet-Suche zufolge gab es dieses Problem vor sieben Jahren mal in macOS 10.14.4. Für den unwahrscheinlichen Fall, dass du noch auf dieser alten MacOS-Version unterwegs bist, könntest du die dort beschriebene Lösung mal ausprobieren. Ansonsten bin ich auch ratlos und kann nur nochmal sagen: An der Wikipedia liegt's nicht. --Tkarcher (Diskussion) 15:10, 28. Aug. 2026 (CEST)

Parsoid Syntaxcheck zeigt Fehler bei colspan und Vorlage:N/A-Feld

Hallo an die Experten,
der Parsoid Syntax-Checker zeigt mir bei der Bearbeitung einer Tabelle im Texteditor einen Fehler "inconsistent table layout (table-layout)" an, wenn die Vorlage {{N/A-Feld}} in einem Feld verwendet wird, das gleichzeitig mittels rowspan oder colspan mit anderen verbunden ist.
z.B. | colspan="2" {{N/A-Feld}}
Ein etwas längeres Beispiel habe ich auf Benutzer:At40mha/Artikelentwurf#Fehlermeldung bei rowspan/colspan mit N/A-Feld geparkt, bitte gerne dort ausprobieren.
Für mich sieht das nach einem "False Positive" aus. Tritt das bei Euch auch auf? --At40mha (Diskussion) 15:38, 31. Aug. 2026 (CEST)

Das passiert auch bei anderen ähnlichen Vorlagen. Für Infos zur Aktivierung des Syntaxcheks (CodeMirror) siehe → Wikipedia:Technik/Text/Edit/CodeMirror/Lint. --Liebe Grüße, Lómelinde Diskussion 16:23, 31. Aug. 2026 (CEST)

Jetzt immer noch bei N/A? VG --PerfektesChaos 16:56, 31. Aug. 2026 (CEST)

Der CodeMirror-Linter expandiert keine Vorlagen, er weiß also nicht, dass innerhalb der Vorlageneinbindung noch eine Pipe gesetzt wird und hält alle Angaben, auch das colspan, für Zellinhalt. Damit fehlt für ihn aber in der Zeile eine Zelle, nämlich die, die im expandierten Wikitext dann doch überspannt wird. -- hgzh 16:57, 31. Aug. 2026 (CEST)

Aha; dementsprechend müsste wie bei den Sortierzellen-Vorlagen ein entsprechendes Repertoire an Vorlagenparametern id= lang= rowspan= und colspan= gesetzt werden, damit die Zuweisungen alle in derselben Seite geschehen, der Parser ggf. auch nicht mitbekäme, dass diese Vorlage eine Pipe in den Gesamttext einbringt.

Der Linter ist doooooof.

VG --PerfektesChaos 17:01, 31. Aug. 2026 (CEST)

Nachdem die entsprechenden Ja-Nein-Weißnicht-Vorlagen ausgerüstet wurden, müsste dann ein Bot das zumindest für den ANR umschreiben. VG --PerfektesChaos 17:04, 31. Aug. 2026 (CEST)

Ne, das würde auch nicht helfen: es geht ja um den CodeMirror-Linter, der bekommt zwar den Output des MediaWiki-Linters und stellt dessen Fehler an passender Stelle dar, aber expandiert selbst nicht. Damit sieht für ihn auch | {{N/A-Feld|colspan=2}} noch wie eine Zelle mit Inhalt aus. -- hgzh 17:09, 31. Aug. 2026 (CEST)

Versteh ich nicht. Damit wäre für ihn doch N/A-Feld irgendein Inhalt der Tabellenzelle, ohne Attribute, und es würde keine Pipe fehlen weil keine Attribute erkannt würden, denen dann die Abtrennung durch Pipe fehlte.

class= hatte ich oben noch vergessen.

Wie ist denn das mit einer Seite, die gemäß Wurgl-Tool Vorlage:DatumZelle und irgendein colspan= verwendet? Mir ist grad noch ein wenig überhitzt, und ich habe wenig Lust auf CodeMirror.

Solange das nicht das volle LINT mit Kategorisierung ist, geht es ja noch. Ich habe den CodeMirror nur bei CSS/JS/Lua, und da bringt der auch diverse Falschmeldungen, an die ich mich bereits gewöhnt habe.

VG --PerfektesChaos 17:20, 31. Aug. 2026 (CEST)

Das würde ebenso als Fehlerhaft eingestuft. Setze ich beispielsweise

{| class="wikitable"
|-
| {{DatumZelle |2026-08-31 |colspan=3}}
|-
| nur eine Zelle = ok
|-
| 1
| 2 X
| 3 X
|}

meckert es dann die korrekten Zellen als falsch an und würde eine einzelne Zelle als korrekt ansehen. --Liebe Grüße, Lómelinde Diskussion 17:34, 31. Aug. 2026 (CEST)

Na, dann begreife ich die Logik überhaupt nicht mehr.

Entweder er erkennt ein normales colspan="2" und beschwert sich, dass keine Pipe zu finden sei. Okay, das mag jetzt ein wertvoller Hinweis auf einen offensichtlichen Syntaxfehler sein.

Aber wenn er von dem colspan= überhaupt nix weiß, weil in der Vorlageneinbindung versteckt, dann möge er die Klappe halten.

Wenn er jetzt versucht, eine komplexe Tabellenkonstruktion durchzuzählen, welche Zellen nebeneinander und übereinander stehen, und herausfinden möchte, dass die auch wirklich insgesamt eine rechteckige Tabelle ergeben, dann muss das scheitern; insbesondere wenn da auch noch Vorlagen im Spiel sind. Da überheben die sich.

Dann einfach ignorieren.

VG --PerfektesChaos 17:44, 31. Aug. 2026 (CEST)

Ok, ich glaube das beste ist, wenn ich meine Frage zurückziehe. Offensichtlich ist das ein bekanntes Problem. Für mich ist das als "derzeit nicht lösbar" erledigt. Vielleicht kann das eine zukünftige Version der Software irgendwann richtig interpretieren. Bei meinen letzten Fehlerbehebungen habe ich diese angezeigten "Fehler" ohnehin schon ignoriert. Schönen Tag noch und bitte um Entschuldigung für die Aufregung, die ich mit meiner Anfrage erzeugt habe. --At40mha (Diskussion) 17:46, 31. Aug. 2026 (CEST)

Na, ich mache bei meinem tableXpander auch so einen Syntax-Spaß, und habe dort genug mit den richtigen Zeilen und Spalten bei span= zu tun. Aber da arbeite ich auf dem dargestellten HTML-Dokument. Hier ist Wikisyntax, und um die zu begreifen, müssten auch alle Vorlagen expandiert werden, sonst kann da nur Grütze rauskommen.

Bliebe die Frage, ob die Fehlermeldungen hübscher würden, wenn das colspan="2" in diese Feld-Vorlagen reingezogen würden?

War schon okay, hier anzufragen --PerfektesChaos 17:58, 31. Aug. 2026 (CEST)

Nochmal zur ausführlichen Erklärung, warum PCs Änderung nix bringt: Der Linter erkennt, wieviele Spalten eine Tabellenzeile haben müsste, und berücksichtigt dabei auch syntaktisch korrekte "colspan"-Angaben, d.h. solche, die mit Pipe vom Inhalt der Zelle getrennt sind:

• | colspan = 2 | Test -> Linter erkennt den Zellinhalt "Test" verteilt auf 2 Spalten.
• | colspan = 2 {{N/A-Feld|egalwashiersteht}} -> Linter erkennt den Zellinhalt "colspan = 2 {{N/A-Feld|egalwashiersteht}}" in einer Spalte.

Solange das die einzige Tabellenzeile ist, ist's dem Linter egal, und er meldet auch keinen Fehler. Findet er aber weitere Tabellenzeilen mit abweichender Spaltenzahl, erkennt er das als Fehler. Es ist also völlig wurscht, ob du das colspan als Parameter mitgibst oder nicht - der Linter erkennt es in beiden Fällen nicht korrekt. Das würde er nur tun, wenn in derselben Zeile noch ein Pipe stünde, um klar zu machen, dass "colspan = 2" eben nicht zum Zellinhalt gehört. Aber dieses Pipe erscheint erst beim Expandieren und ist damit für den Linter unsichtbar. Soweit das Problem. Eine einfache Lösung habe ich aber auch nicht. Letztendlich müsste der Linter Vorlagen expandieren. Das dürfte aber extrem komplex in der Umsetzung werden. --Tkarcher (Diskussion) 18:21, 31. Aug. 2026 (CEST)

Naja, das ist ganz einfach aus der trivialen Wikisyntax nicht zu erkennen, weil dazu alle Vorlagen unter den aktuellen Bedingungen expandiert werden müssten.

Ich kann auch eine Tabelle mit drei Überschriftenspalten haben, und hier und da auch drei Datenzellen sichtbar.

• Bei vielen Datenzellen habe ich aber neben dem Objekt in der ersten Spalte eine Vorlage, in die ein einziger Zahlenwert reingeht, und daraus werden zwei Zellen nebeneinander: Fuß und Meter, EUR und USD zum aktuellen Wechselkurs, Zoll/cm, kW/PS, km und Meilen.

Diese Analyse ist nett gedacht, versagt aber ob der Komplexität realer Wikitext-Seiten, und hat ein zu schlichtes Weltbild.

VG --PerfektesChaos 19:15, 31. Aug. 2026 (CEST)

Zusatzfrage, die nicht unmittelbar mit diesem Tabellenproblem zusammenhängt, in Wikipedia:WikiProjekt Vorlagen/Werkstatt#Vorlage:Hauptartikel liefert nichts ausgelagert. --At40mha (Diskussion) 10:46, 16. Sep. 2026 (CEST)

Unterwittbach: unterschiedliche Darstellung Parsoid (mit Fehlern) vs. Legacy

Liebe Experten,
die Seite Unterwittbach wird mit Parsoid fehlerhaft angezeigt, während die Darstellung mit dem Legacy-Parser korrekt aussieht. (Ausprobiert mit Chrome und Edge, an- und abgemeldet; mit Parsoid gerenderte Darstellung am Smartphone zeigt auch Fehler). Mit Parsoid liefern einige LUA-Formeln Fehlermeldungen ("attempt to index field 'val' (a nil value)"). Sieht das bei Euch auch so aus? --At40mha (Diskussion) 14:51, 12. Sep. 2026 (CEST)

Bei mir alles paletti, auch keine Wartungskat.

Kannst du mal die Textstellen spezfizieren, bzw. die Vorlage an dieser Stelle? Dann ließe sich das Modul mit val einkreisen. Es scheinen zwei Dutzend Module beteiligt zu sein.

VG --PerfektesChaos 15:12, 12. Sep. 2026 (CEST)

Der Fehler tritt an den Stellen auf, an denen in der {{Infobox Ortsteil einer Gemeinde in Deutschland}} die Einwohnerzahl ("Einwohner") verarbeitet wird, aber wie gesagt, nicht mit dem Legacy Parser und auch nicht im Bearbeitungsmodus. --At40mha (Diskussion) 15:44, 12. Sep. 2026 (CEST)

Es moniert Beleg 2 {{EWQ|Verwaltungsgemeinschaft Kreuzwertheim}} → abruf=Lua-Fehler in Modul:Data, Zeile 220: attempt to index field 'val' (a nil value)

Ablaufrückverfolgung:

   Modul:Data:220: in der Funktion „chunk“
   mw.lua:678: ?
   [C]: ?
   [C]: in der Funktion „getExpandedArgument“
   mw.lua:232: ?
   Modul:Data:137: in der Funktion „chunk“
   mw.lua:678: ?
   [C]: ?

Zahlen & Daten rund um die Verwaltungsgemeinschaft Kreuzwertheim. Verwaltungsgemeinschaft Kreuzwertheim, archiviert vom Original am 15. September 2023; abgerufen am 15. September 2023.  könnte es am Abrufdatum liegen, da heute erst der 12. September ist, auch wenn das Jahr 2023 dahinter steht. --Liebe Grüße, Lómelinde Diskussion 15:54, 12. Sep. 2026 (CEST)

Ach herrjeh.

• Die 09677562 in Vorlage:Metadaten Einwohnerzahl Verwaltungsgemeinschaft Kreuzwertheim stamm von einem kompletten Wirrkopf, der diesen Wust an duplizierten Quellcodes trotz unserer heftigen Proteste angelegt hatte.
• Das ist mangelhaft oder überhaupt nicht dokumentiert und nicht wartungsfähig; das Konzept in der vorliegenden Form Schrott.
• Diese ganzen Vorlagen und Module, die irgendwie fast nur ein Dutzend Kilometer um seinen Heimatort herumliegen, müssten alle durch eine vollkommen simple Vorlagenprogrammierung ersetzt werden, die einfach nur den Beleg benennt, so wie sonst überall anders auch.
• Schöner Fehlerbericht im ÜBrigen.

VG --PerfektesChaos 16:15, 12. Sep. 2026 (CEST)

Da haben wir also nun zwei Fragen:

1. Warum sieht man den Fehler nur mit Parsoid, nicht aber mit dem Legacy Parser und im Edit-Modus? sowie
2. Wie lässt sich dieser Schrott bereinigen?

--At40mha (Diskussion) 16:59, 12. Sep. 2026 (CEST)

Ich habe das Problem auch gesehen. Nach einem Purge ist der Effekt aber verschwunden, und Parsoid und Legacy sehen gleich aus.--Kallichore (Diskussion) 17:28, 12. Sep. 2026 (CEST)

Danke, der Fehler wird jetzt tatsächlich nicht mehr angezeigt.
Da habe ich wieder etwas gelernt: In der letzten Zeit habe ich mehrmals versucht, "Phantomfehler" durch ein Purge zu beheben, und das gelang nicht, aber mit einem "Nulledit" ist das Problem damals doch verschwunden. Deshalb habe ich es jetzt hier nur mit Nulledits versucht. Allem Anschein nach ging es hier aber nur mit purge. Ergo: Immer beides probieren. --At40mha (Diskussion) 17:40, 12. Sep. 2026 (CEST)

Der ersten Frage (über die ich mir auch bereits vergeblich den Kopf zerbrach) nachzuforschen, würde sich bei einer sinnvollen Programmierung lohnen; hier ist es erstmal wumpe.

• Der nächste Bug gleicher Ursache wird sich schon melden; dann mag das jemand analysieren.
• Ich seh nix.

Die Grundidee mit commons:Data: wäre ja durchaus sinnvoll, wenn es für den ganzen Landkreis dort eine einzige JSON-Seite mit 500 oder 2000 Einwohnerzahlen und ggf. mehreren Jahreszahlen dazu in Folge, und jeweilige Belege geben würde. Und ein einziges programmiertes Modul mit einem etwas aussagekräftigeren Namen als Modul:Data für DACH oder den ganzen Planeten.

• Da findet sich aber dieses Drama.
• Und in jedem JSON nur eine Zahl oder ein vereinzelter Datensatz; commons:Data:Data/DE-096775620.tab ist irgendwie an Unterwittbach beteiligt, aber commons:Data:Data/DE-096775621/1/14/info.tab das Nachbardorf.
• Es gibt auch keine Doku der Datenstruktur.

@ „Wie lässt sich dieser Schrott bereinigen?“

• WP:VWS kann helfen; ich pack grad keine produktive Arbeit. @Darkking3: Was für dich?
• Vorlage:Metadaten Einwohnerzahl Verwaltungsgemeinschaft Kreuzwertheim umbauen:
  • onlyinclude / includeonly
  • #ifeq: {{{2|}}} | QUELLE für Vorlage:EWQ
  • Ganz normale Zitation bauen, für aktuellen Datensatz.
  • Für den Rest den bisherigen Krams beibehalten.
• Die anderen Ortschaften der Umgebung aufspüren und genauso.
• (BK) Würde sich lohnen, wenn wir grad schon soweit sind, weil jetzt bereits analysiert, und das wäre dann vergebens. Auch wenn purge dann hier für den Moment geholfen haben mag.

VG --PerfektesChaos 17:46, 12. Sep. 2026 (CEST)

Ich würde zwar gern helfen, allerdings ist mir noch nicht so klar, worin der Fehler lag und wie die Vorlage umzubauen ist. In Kategorie:Vorlage:Metadaten Einwohnerzahl DE gibt es zwar mehr als genug Vorlagen, aber einfach dürfte das nicht sein, etwas passendes zu finden, da es keine einheitliche Schematik gibt. --darkking3 ^Թ 09:44, 14. Sep. 2026 (CEST)

Das Grundproblem ist, dass dieses commons:Data:-Drama zukünftig nicht mehr wartungsfähig ist.

Das hier eingangs geschilderte Problem scheint nach cache-purge-Aktionen dann ein temporärer Knoten auf den Servern gewesen zu sein (ich habe nie was davon gesehen), aber wir könnten einen vandalierenden Eingriff im Dschungel nicht mit vernünftigem Aufwand auffinden, und wir können in den kommenden Jahren keine neuen Zahlen aktualisieren.

Dabei ist die Aufgabe von Vorlage:Metadaten Einwohnerzahl Verwaltungsgemeinschaft Kreuzwertheim eigentlich mit zwei, drei switch oder so für 1000 Autoren verständlich übersichtlich zu lösen. Eine Quelle, eine Zahl je nach Ortsteil oder was das ist, ein Datum, fertig. Ganz nach Belieben, möglichst simpel strukturiert.

Die Historie ergäbe sich aus der Versionsgeschichte der Vorlage; uns genügt jedoch eine halbwegs aktualle Angabe zur EInbindung in den ANR.

Das JSON-Verfahren hätte ja den Vorteil gehabt, dass sich auch eine beliebige Geschichte tabellarisch oder grafisch ableiten ließe, aber dazu bedarf es eines übersichtlichen intuitiv verständlichen Datenobjekts für die Zahlen, und ggf. noch eines für alle Quellen nach Jahr im Landkreis. Und eine verständliche Bedienungsanleitung zur zukünftigen Pflege.

Nach Umbau der jeweiligen Vorlage für jede Verbandsgemeinde, oder was das jeweils sein mag, können die Dubletten-Module bei uns gelöscht werden. Auf commons:Data: mögen die 300 ndokumentierten JSON in Ewigkeit vor sich hinschimmeln.

VG --PerfektesChaos 13:56, 14. Sep. 2026 (CEST)

Spezial:Defekte Weiterleitungen

Hallo, ich weiß nicht, ob ich richtig bin, aber vielleicht kann jemand trotzdem weiterhelfen: auf der Seite Defekte Weiterleitungen gibt es vier Benutzer-Weiterleitungen, die seit Monaten dort als "fehlerhaft" gelistet werden. Sie sind auch durchgestrichen, ohne dass sie in der letzten Zeit bearbeitet wurden. Wenn die WL korrekt ist, verschwinden diese Meldungen im nächsten Botlauf. Diese vier WL stehen aber schon seit Monaten in dieser Liste und verschwinden nicht - allerdings sind die Linkziele alle existent. Weiß hier jemand jemanden, der da mal schauen könnte, warum diese optisch korrekten WL nicht verschwinden? Danke und Grüße --Mef.ellingen (Diskussion) 18:29, 14. Sep. 2026 (CEST)

1. Gute Nachricht: Du bist hier völlig richtig.
2. Schlechte Nachricht: Keine Ahnung.

Offensichtlich hakt was in der Server-Vernetzung; irgendein Cache. Ob das in den letzten Wochen mehr sei als im langjährigen Mittel, kann ich nicht überblicken.

Ich hab den vieren mal ein Spezial-Purge gegeben, vielleicht hilft’s.

Ansonsten: Einfach ignorieren. Die vier sind ja als vorhanden erkennbar, du kennst sie, und irgendwann verschwinden sie hoffentlich.

VG --PerfektesChaos 19:25, 14. Sep. 2026 (CEST)

Könnte es daran liegen, dass die vier genannten Seiten auf nicht existente Seiten in der deWP weiterleiten, bei denen aber eine Meta-Benutzerseite vorhanden ist, die dann eingeblendet wird und den Link bläut, obwohl lokal keine Seite existiert? ZB ist Benutzer:GinnyTheCar eine Weiterleitung auf Benutzer:GinnyTheCat (lokal rot, aber metaWP wird eingeblendet). VG –IWL04 • 19:55, 14. Sep. 2026 (CEST)

Gratuliere, du hast es geknackt.

Es ist eine shadow-Seite, die bei uns keine VG, keine Seiten-Nummer oder sonstwas hat.

• Du kannst ja mal in deinem BNR anlegen:

#WEITERLEITUNG [[Datei:Wikipedia-logo-v2-de-25-alt-tagline.svg]]

• Das wird als WL funktionieren, aber morgen früh auf der Spezialseite aufschlagen.

Jetzt bräuchte es ein Phab-Ticket, sofern noch keins existiert.

• Vermutliche Bearbeitungsdauer: Fünf Jahre. Eilt also nicht.
• Wenn ein Konto umbenannt wird, werden (automatisch?) diese WL angelegt. Also globales Problem; legitimes Verhalten im eigenen BNR.
• Die WL ist völlig okay und nicht defekt. Hat aber keinen Eintrag in unserer Seiten-Tabelle.

VG --PerfektesChaos 21:27, 14. Sep. 2026 (CEST)

Danke für die Mühe. Aber Kontoumbenennungen finden doch laufend statt und die schlagen hier nicht auf? Und die WL auf die Metaseite direkt kann man nicht machen? --Mef.ellingen (Diskussion) 13:43, 15. Sep. 2026 (CEST)

Weiterleitungen von einer Benutzerseite auf die andere werden dauernd anlegt, ja. Das ist auch in Ordnung und führt allein noch nicht zu oben genanntem Fehler. Der entsteht erst, wenn die neue Benutzerseite nicht (mehr) existiert und die Version von Meta eingebunden wird.

Wie PC schon schreibt ist das ein globales Problem und lässt sich nur per Bugfix über Phabricator lösen. Nur was die vermutete Bearbeitungsdauer angeht, ist PC leider viel zu optimistisch: Das entsprechende Ticket dazu ist seit 11 Jahren offen. :-/ Tkarcher (Diskussion) 14:01, 15. Sep. 2026 (CEST)

Meine Glakugel scheint einen Sprung zu haben.

Dann halt lokale Abhilfe für die vier, mal egal ob die noch hier aktiv wären, und für alle zukünftigen:

• Vorlage:Interwiki redirect statt WEITERLEITUNG und auf die hiesige Seite verlinken.
  • Die Leut können ja auch eine hiesige BNR-Seite neu anlegen.
  • Formaljuristisch existiert das bisherige Konto auch nicht mehr; damit gibt es niemand mit „mein“ BNR.
• Kurzen Hinweis darunter, es handele sich um das <Monat Jahr> umbenannte Konto.

Warten auf globale Lösung ist dann nix; nun halt lokal.

VG --PerfektesChaos 14:59, 15. Sep. 2026 (CEST)

Danke, habe ich eingefügt. Mal abwarten, ob die dann beim Bot-Lauf weg sind.... Grüße --Mef.ellingen (Diskussion) 17:20, 15. Sep. 2026 (CEST)

Bot-Lauf ist durch. Die WL sind weg! Danke. --Mef.ellingen (Diskussion) 09:32, 16. Sep. 2026 (CEST)

Erneuter Test des Bilderkarussells – A/B-Experiment auf Mobilgeräten

Hallo zusammen,

Aufgrund der von den Communitys geäußerten Bedenken haben wir Änderungen an der Bilderkarussell-Funktion vorgenommen. Zuvor hatten wir eine frühere Version des Bilderkarussells in der arabischen, chinesischen, englischen, französischen, indonesischen und vietnamesischen Wikipedia getestet. Nun möchten wir den neuen Prototypen des Bilderkarussells mit diesen Verbesserungen erneut testen.

Das Experiment wird in der Woche ab dem 28. September beginnen und vier Wochen später beendet. Es betrifft 1 % der mobilen Nutzenden der englischen Wikipedia sowie 10 % der mobilen Nutzenden der arabischen, chinesischen, französischen, indonesischen, vietnamesischen, spanischen, polnischen, deutschen, japanischen, schwedischen, portugiesischen, persischen, tschechischen und bengalischen Wikipedia.

Wir haben die Arbeiten in der folgenden Liste festgehalten und möchten sie mit euch teilen. Bitte teilt uns mit, was ihr von den einzelnen Änderungen haltet.

Hier ist ein grober Prototyp, der diese Änderungen veranschaulicht:

Wir möchten in einem A/B/C/D/E-Test Daten zu mehreren unterschiedlichen Versionen der Funktion erheben, um zu sehen, wie sie sich auf die Kennzahlen auswirken:

• A: Kontrollgruppe (kein Karussell)
• B: Karussell in der ursprünglich getesteten Form, d. h. ohne Bildunterschriften oder Link zum entsprechenden Artikelabschnitt
• C: Karussell + Bildunterschriften
• D: Karussell + Link zum entsprechenden Artikelabschnitt
• E: Karussell + Bildunterschriften + Link zum entsprechenden Artikelabschnitt

Wir werden die Ergebnisse des Experiments gemeinsam mit der Community besprechen und anschließend entscheiden, ob die Funktion eingeführt werden soll. Wir möchten gerne eure Meinung dazu hören. Dankeschön! EBlackorby-WMF (Diskussion) 18:23, 18. Sep. 2026 (CEST)

vor nbsp wird umgebrochen

Bei Berliner Stadtbahn steht im ersten Satz: „die –&nbsp;weitgehend“.
Da zufällig auf meinem Handy gerade die Breite und meine eingestellte Schriftgröße etc. passen, hab ich gesehen, dass zwischen dem Halbgeviertstrich und dem geschützten Leerzeichen umgebrochen wurde, und somit in der nachfolgenden Zeile erst das (geschützte‽) Leerzeichen, und dann „weitgehend“ stehen. Getestet bei Firefox auf Android, und Firefox sowie Chrome in Debian, ohne angemeldet zu sein, mit neuem Profil, ohne add-ons.

Das sollte doch so überhaupt nicht geschehen? Ist nicht Sinn und Zweck des nbsp, dass nicht umgebrochen wird?
–joshinils (D) 19:47, 24. Sep. 2026 (CEST)

Ja, kann ich bestätigen. Das dürfte daran liegen, dass das nbsp (neuerdings?) in ein span eingeschlossen wird, also <span typeof="mw:Entity" id="mwBw">&nbsp;</span>. Wozu das gut sein soll, habe ich nicht verstanden, aber es hebelt dann ja die Funktion des nbsp aus, da der Umbruch dann schlicht am Anfang oder Ende des span passiert. --XanonymusX (Diskussion) 20:26, 24. Sep. 2026 (CEST)

Ach so, die Tags sind natürlich ein Parsoid-Feature. Aber wenn ich mich nicht täusche, kriege ich bei dem Artikel selbst im Legacy-Parser den falschen Umbruch, dann scheint die Ursache doch woanders zu liegen. --XanonymusX (Diskussion) 20:34, 24. Sep. 2026 (CEST)

(BK)

1. … sollte doch so überhaupt nicht geschehen – ja. Ist Sinn und Zweck.
2. Es liegt in Verantwortung der Browser.
3. Wir können nur inhaltlich begründete Tipps geben, wie es dargestellt werden sollte.
4. Es sind meist Bugs in den Browsern, die sich nach einem halben Jahr oder zweien oder vier Wochen ohne unser Zutun erledigen.
5. Wir zermanschen nicht unseren Wikitext, um irgendeiner momentane Laune einzelner Browser entgegenzuwirken; das muss für Jahrzehnte in korrkter Syntax passen.
   • Also: einfach in Geduld fassen.
6. Technisch verwenden viele Browser nur wenige sogenannte Engines, und die schwächeln schon mal, zumal sie in vielen Schriftsystemen und Sprachen arbeiten sollen.

@ XanonymusX:

• Theoretisch müsste es trotz <span> auch funktionieren, jedoch ist undefiniert, wer von den beiden Oberhand gewinnt. Der HTML-Standard ist da nicht eindeutig. Lässt sich so interpretieren, wie es offenbar die Browser machen; die verkettende Eigenschaft könnte aber auch über den span-Bereich hinaus als wirksam interpretiert werden.
• (BK) Das <span> für jedees Fitzelchen stammt aus Parsoid und soll dem VisualEditor das Leben vereinfachen. Da gibt es sicher schon ein Phab-Ticket dazu, und die technical village pump der enWP wird es auch schon heiß erörtern.

VG --PerfektesChaos 20:36, 24. Sep. 2026 (CEST)

Nachricht an Einladungsliste verschickt, aber nicht bei allen angekommen

Hallo, heute wurde eine Einladung zum Hamburger Stammtisch verschickt, wozu diese Einladungsliste verwendet wurde. Ich habe zufällig gesehen, dass zumindest bei zwei Benutzern (Ajepbah und Schlurcher) - auch nach Versionsgeschichte - nichts angekommen ist. Warum, oder sehe ich das falsch? --Wosch21149 (Diskussion) 19:23, 25. Sep. 2026 (CEST)

wgScriptPath is not defined

Nach gut 15-jähriger Pause will ich mal wieder einen Artikel erstellen und habe mich dafür wieder angemeldet. Wenn ich als angemeldete Benutzerin andere Seiten aufsuchen will, kommt immer eine Fehlermeldung mit diesem Text: "de.wikipedia.org wgScriptPath is not definded", Ich klicke das durch 'ok' weg, dann kommt dieselbe Meldung wie oben ergänzt durch ein Auswahlkästchen mit dem Text "Weitere Aufforderungen von de.wikipedia.org verbieten". Klicke ich das Kästchen an und dann 'ok' verschwindet es und ich kann mich auf der Seite bewegen. Beim Aufruf einer anderen WP-Seite erscheint es meistens wieder. Klicke ich das Auswahlkästchen nicht an, bleibt die Meldung auf der Seite. Wenn ich nicht angemeldet bin, kommt keine Fehlermeldung. Ich erinnere mich vage an eine technische Änderung von vor etwa 15 Jahren, bei der man irgendetwas in seinen Einstellungen ändern sollte, wobei ich das damals nicht kapiert hatte. Ich bitte um eine laiengerechte Erklärung, wie ich dieses nervige Kästchen wegbekomme. AWI (Diskussion) 15:37, 29. Sep. 2026 (CEST)

@AWI daran dürfte Benutzer:AWI/monobook.js schuld sein. Benutzt du das Skript überhaupt noch oder ist dein Konto heute eh im moderneren Design unterwegs? Falls du eh kein Monobook mehr nutzt, einfach die genannte Seite leeren. Und selbst wenn du Monobook noch nutzt, ist diese Version des Skripts stark veraltet, insofern entweder updaten oder trotzdem die Seite leeren. --Johannnes89 (Diskussion) 16:21, 29. Sep. 2026 (CEST)

(BK)

Du verwendest irgendein ungepflegtes Benutzerskript; möglicherweise auch deine eigene JavaScript-Programmierung.

Wikipedia:Technik/Skin/JS/Variablen beschreibt näher, dass dieser Zugriff auf einen Riesenberg globaler JavaScript-Variabler mit 2021 weggefallen ist.

Jetzt: mw.config.get( "wgScriptPath" )

In den frühen Jahren des Internet hatten die Leute und die Wikis zwei oder drei Skripte benutzt, und ein Dutzend globaler JavaScript-Variable in die Welt gesetzt. Heutzutage geht das in die Tausende prinzipiell möglicher Skripte mit -zigtausenden Variabler. Diese können sich gegenseitig wegschießen, die gleichen Namen verwenden, und niemand blickt mehr durch, wer für die Generierung welcher Variabler verantwortlich ist. Heutzutage gibt es für Wikis meist nur zwei bis vier, darunter mw und $. Moderne und sichere Programmierungen sind außerdem gekapselt, was in den Nuller Jahren auch noch nicht üblich war.

Über dieses mw und davon abgeleitet mw.config.get ist wgScriptPath zugänglich.

VG --PerfektesChaos 16:28, 29. Sep. 2026 (CEST)

Danke schön, aber ich weiß weder ob und welches Skript ich benutze, noch habe ich jemals eine JavaScript-Programmierung vorgenommen. Ich hab, offen gesagt, sehr wenig von Deiner Antwort verstanden. Aber Doc Taxon scheint das Problem gelöst zu haben. Gruß AWI (Diskussion) 22:09, 29. Sep. 2026 (CEST)

Danke! Aber da das Problem durch Doc Taxon gelöst zu sein scheint und ich überhaupt nichts über mein monobook weiß, belasse ich es erstmal dabei. Gruß AWI (Diskussion) 22:11, 29. Sep. 2026 (CEST)

Hallo @AWI: Ich habe zumindest mal dieses eine Problem in Deinem Script notdürftig geflickt. Die Fehlermeldung sollte nicht mehr auftreten, es sei denn, der Pfad wird über andere Skripte noch aufgerufen. Gib uns Bescheid, wenn die Fehlermeldung jetzt ausbleibt oder wiederkommt. Grüße, --Doc Taxon (Diskussion) 17:35, 29. Sep. 2026 (CEST)

Besten Dank für die schnelle Hilfe! Die Fehlermeldung scheint tatsächlich weg zu sein. AWI (Diskussion) 22:06, 29. Sep. 2026 (CEST)

Linterfehler in *.js-Dateien

Seit gestern oder vorgestern zeigt die Liste der Linterfehler mehrere (derzeit knapp 100) Eintragungen unterschiedlicher Art (vor allem missing end Tag, aber auch falsch verschachtelte Tags, stripped Tag) im User-Namensraum in *.js-Dateien. Allem Anschein nach wurde da in der Syntaxprüfung etwas geändert, sodass nun auch *.js-Dateien nach den Kriterien für Wikitext bewertet werden (z.B. .js-Kommentar "//" wird nicht ausgeschlossen). Weiß jemand, was der Hintergrund ist? --At40mha (Diskussion) 09:15, 16. Okt. 2026 (CEST)

Hab mal probiert mit nowiki die Fehler wegzubekommen, hat aber nicht geklappt, irgendwelche ''-Leerstrings versteht die Saftware als kursiv-Tags. Spezial:Diff/271375788 --Wurgl (Diskussion) 09:28, 16. Okt. 2026 (CEST)

Bug bei LINT; bedarf eines Tickets.

Wikitext-LINT darf nur auf das Content Model wikitext angewendet werden.

Wurde auch immer so gehandhabt; gestern ein Software-Update verteilt.

VG --PerfektesChaos 09:44, 16. Okt. 2026 (CEST)

Es gibt bereits ein Ticket phab:T441307 --Liebe Grüße, Lómelinde Diskussion 10:03, 16. Okt. 2026 (CEST)

Danke für die Rückmeldungen! Also abwarten … --At40mha (Diskussion) 10:16, 16. Okt. 2026 (CEST)

Scheint gestern oder heute behoben worden zu sein, damit erledigt. --At40mha (Diskussion) 15:10, 20. Okt. 2026 (CEST)

Inhaltsverzeichnis V22

Hallo, gibt es eine Möglichkeit, das, was ich in Spezial:Diff/271411839 ohne Erfolg versucht habe, irgendwie umzusetzen? Ziel wäre es für das Kurier-TOC im Vector 2022 eine letzte H2-Überschrift für die rechte Spalte einzufügen, die idealerweise aber nicht über der rechten Spalte angezeigt wird … sonst erscheinen alle Beiträge rechts als Unterüberschriften des letzten Beitrags der linken Spalte. Danke schonmal und VG –IWL04 • 15:58, 20. Okt. 2026 (CEST)

Da gibt es zwei Lösungswege:

1. Du könntest zwei Zeilenumbrüche spendieren; per Definition muss das = in der ersten Spalte der Quelltextzeile stehen.
2. Du könntest <h2> gemäß H:Ü #HTML verwenden und style="display:none" einfügen. Plus erläuternden Kommentar.

VG --PerfektesChaos 16:22, 20. Okt. 2026 (CEST)

Danke für die schnelle Antwort! Habe mich für Variante 1 (inkl. Kommentar) entschieden, funktioniert :) VG –IWL04 • 16:32, 20. Okt. 2026 (CEST)

Die Uploadmap – Karte der Schutzgebiete in Deutschland ist seit Stunden nicht erreichbar

Hallo,

ich habe in Firefox ein Lesezeichen eingerichtet, das heißt „Uploadmap – Karte der Schutzgebiete in Deutschland“. Seit Stunden ist dieser Link aber nicht aufzurufen.

Beste Grüße.

Andreas --Huth, Andreas (Diskussion) 20:10, 21. Okt. 2026 (CEST)

Schau mal auf "in den Nachrichten". --Magnus (Diskussion) 21:44, 21. Okt. 2026 (CEST)

Danke für den Hinweis, meinst Du die Abschaltung von Websites wegen der PHP-Sicherheitslücken? Auf der verwiesenen Seite steht sehr viel …

Andreas --Huth, Andreas (Diskussion) 15:25, 23. Okt. 2026 (CEST)

Gut zu wissen, aber es wäre nett, wenn Du hier mal die Zieladresse Deines Bookmarks verlinken könntest. Dann könnte ein Techniker prüfen

• auf was da verlinkt wird
• und warum der Link gerade down ist:
  • wenn es außerhalb der WP ist, ist es hier nur relevant, wenn es um Wikimedia-Links geht
  • andere Links in Deinen Browser-Bookmarks kann hier keiner prüfen

Vielleicht hat das auch mit den weltweiten Server-Updates wegen der PHP2Shell-Lücke zu tun? --Hlambert63 (Diskussion) 21:49, 21. Okt. 2026 (CEST)

Meine Karte steht jetzt auf der Liste der nicht php Tools die hoffentlich zeitnahe wieder eingeschaltet werden. --GPSLeo (Diskussion) 06:35, 22. Okt. 2026 (CEST)

Meine Vermutung ist, dass es um uploadmap.toolforge.org/protectedareasde.html geht und dass die Seite down ist wegen php2shell, wie auch andere toolforge.org-Seiten. Please be patient… --At40mha (Diskussion) 09:54, 22. Okt. 2026 (CEST)

Hallo At40mha,

inzwischen gehe ich auch davon aus. Aber GPSLeo hat ja auch schon etwas dazu geschrieben. Ich übe mich in Gedulr, weil Vorsicht hier wohl viel besser ist als Nachsicht.

Andreas --Huth, Andreas (Diskussion) 15:34, 23. Okt. 2026 (CEST)

Hallo Hlambert63,

die Zieladresse meines Bookmarks lautet: https://uploadmap.toolforge.org/protectedareasde.html. Ich schätze aber, dass es mit der inzwischen öffentlich gemachten Sicherheitslücke von PHP zusammenhängt.

Andreas --Huth, Andreas (Diskussion) 15:31, 23. Okt. 2026 (CEST)

War jetzt doch etwas Aufwand, da das Tool zwar kein Zeile php enthält der Standardserver von Toolforge aber ein php-Server ist, läuft jetzt aber wieder. --GPSLeo (Diskussion) 18:59, 23. Okt. 2026 (CEST)

Abrufstatistik · Autoren

Warum funktionieren die Links Abrufstatistik und Autoren am Artikelende nicht? --Martin Geisler 12:38, 22. Okt. 2026 (CEST)

Siehe #Die Uploadmap – Karte der Schutzgebiete in Deutschland ist seit Stunden nicht erreichbar, WD:Kurier#Vorbereitungen auf ein kurzfristiges Sicherheitsupdate für unsere Dienste, WP:FZW#Petscan funktioniert nicht usw. – die meisten externen Tools sind aktuell deaktiviert, während die Auswirkungen von PHP2Shell behoben werden. --Johannnes89 (Diskussion) 12:44, 22. Okt. 2026 (CEST)