Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise
[[Wikipedia:Technik/Archiv/2020#Thema 1]]
oder als Weblink zur Verlinkung außerhalb der Wikipedia
Hi, bekomme seit heute folgende Fehlermeldung, wenn ich den Abschnitt Einzelnachweise bei einigen Artikeln editieren möchte, siehe Kraftwerk Aratiatia.
Fehlermeldung:
Interner Fehler
[Xhm8agpAAEAAABPliC8AAAAL] 2020-01-11 12:15:38: Fataler Ausnahmefehler des Typs „LogicException“
Dies passiert, wenn die Einzelnachweise im Abschnitt unter <references> ... </references> untergebracht sind.
Bir mir (Win10, Firefox 72.0.1, Skin: Timeless) erhalte ich immer die Fehlermeldung "Our servers are currently under maintenance or experiencing a technical problem. Please try again in a few minutes." -- Gruß Sir GawainDisk.17:23, 12. Jan. 2020 (CET)
Ich habe das Problem auch. Das oben Angegebene mag zwar eine Lösungsmöglichkeit sein (ich habe es nicht ausprobiert, ist aber plausibel). Ist aber unbefriedigend und erklärt nicht, wann und warum der Fehler auftritt. Die von Sir Gawain angegebene Fehlermeldung tritt übrigens immer dann auf, wenn das Bearbeitenfeld in einem neuen Tab geöffnet werden soll. -- Kürschner (Diskussion) 17:41, 12. Jan. 2020 (CET)
Das was ich oben beschrieben habe, ist eine Fehlermeldung, die in der beschriebenen Situation auftritt, ... ist also keine Lösung. Der Fehler ist immer noch virulent. Vorhin hatte ich den „... servers are currently under maintenance...“ auch beim Umbennen eines Artikels mehrfach. Irgendwo ist der Wurm drin. Wer weiß mehr??? .. und kann Abhilfe schaffen. Gruß -- Ulanwp (Diskussion) 18:14, 12. Jan. 2020 (CET)
Ich kann das Problem leider nicht reproduzieren. Vielleicht tritt es nur in Zusammenhang mit einem Helferlein oder irgendeiner Benutzeroberflächenerweiterung auf, die du angeschaltet hast? --Count Count (Diskussion) 18:58, 12. Jan. 2020 (CET)
Kann ja sein, ich kann jetzt aber doch nicht alle möglichen Einstellungen ausprobieren. Die/der Entwickler, der Hand angelegt hat, sollte aufgrund der Fehlermelsung in der Lage sein den Bug zu finden. Gruß -- Ulanwp (Diskussion) 19:08, 12. Jan. 2020 (CET)
Das war der Test, ob irgendwelche Benutzerskripte reinfunken. Offensichtlich nicht, trotzdem seltsam, dass der Fehler scheinbar doch nur in einer bestimmten Konfiguration aufzutreten scheint. Dass es sich um das Problem im verlinkten Task handelt, denke ich auch. Habe mich mal durch den Code gelesen, aber da reicht mein Verständnis für die interne Abwicklung der Ref-Syntax nicht aus. Gruß, -- hgzh13:24, 13. Jan. 2020 (CET)
Der Fehler muss noch sehr neu sein. Bei der Vorgabe <references> [text] </references> ist der Absatz (Einzelnachweise) offenbar unter den genannten Vorgaben nirgends mehr separat zu bearbeiten. Was wurde in den letzten Tagen geändert?-- Kürschner (Diskussion) 13:35, 13. Jan. 2020 (CET)
Das Cite-System (die Referenzen) wird schon seit Wochen grundlegend modernisiert und erweitert, unter anderem hierfür. Es gibt also zahlreiche Änderungen, die für Außenstehende wie uns nicht leicht zu durchblicken sind und bei denen auch Fehler passieren. Wir können größtenteils nur zuarbeiten und hoffen, dass das zeitnah behoben wird. Gruß, -- hgzh13:50, 13. Jan. 2020 (CET)
Es gibt jetzt einen Fix, der das hoffentlich behebt. Übrigens habe ich den Fehler nun doch nachstellen können, er tritt nämlich nur bei Betrachten der Vorschau auf, nicht beim bloßen Bearbeiten des Abschnitts (außer, man hat die Option „Vorschau beim ersten Bearbeiten immer anzeigen“ in den Einstellungen aktiviert). -- hgzh10:10, 14. Jan. 2020 (CET)
Danke erst mal. Ich habe „Vorschau beim ersten Bearbeiten immer anzeigen“ eingestellt. Der Fehler tritt allerdings (immer noch) nicht bei der Vorschau auf - dahin gelange ich nicht - sondern bereits beim versuchten Aufruf von Abschnitt „Bearbeiten“. -- Kürschner (Diskussion) 10:33, 14. Jan. 2020 (CET)
Ich vergaß – der Fix ist noch nicht eingespielt, es dauert also wohl noch ein bisschen. Und weil bei dir gemäß deiner Einstellung die Vorschau schon beim Klick auf den Bearbeiten-Button geladen werden soll, bei mir aber erst nach Klick auf „Vorschau zeigen“, kommst du gar nicht zum Bearbeiten, ich aber schon. -- hgzh10:42, 14. Jan. 2020 (CET)
Hoffnung ?! Ich wag's ja kaum zu sagen, aber halbwegs vernünftige Entwicklerteams wussten schon vor Jahrzehnten, wie man Software entwickelt und testet, so dass nicht erst der Benutzer feststellen muss, ob's funktioniert. Genausolang gibt's aber auch schon den Begriff Bananen-Software... ;-) --rolf_acker (Diskussion • Beiträge) 11:08, 14. Jan. 2020 (CET)
Es schimpft sich sehr einfach. Tatsächlich kannst du so viele Testfälle durchgehen wie du willst und trotzdem schlüpfen dir immer wieder Fehler durch. --Wurgl (Diskussion) 11:44, 14. Jan. 2020 (CET)
PS: Im Übrigen konnte ich die letzte Antwort erst im dritten Versuch speichern; die ersten beiden Male verhinderte es ein "fataler Ausnahmefehler"! *grins* --rolf_acker (Diskussion • Beiträge) 12:06, 14. Jan. 2020 (CET)
In Anbetracht des Schimpfens: Ich ziehe mein „Voller Hoffnung“ zurück und erzetze es durch „Voller Zuversicht“. Mit großem Verständnis für die Helfer, die bei der komplizierten Materie noch halbwegs durchblicken. Ihnen sei gedankt! -- Kürschner (Diskussion) 12:12, 14. Jan. 2020 (CET)
Bei mir trat dieser Fehler heute (1.10.2022) direkt nach der Installation der Version 1.38.4 auf. Der Grund war das Hereinziehen von Bildern für die Logos im Zug der Installation. Ohne das Hereinziehen klappte es. --Shadow c2 (Diskussion) 22:32, 1. Okt. 2022 (CEST)
Hallo!
Ich würde gern nicht nur den Text des Eintrags "Regionaler Arbeitskreis Entwicklung, Planung und Verkehr Bonn/Rhein-Sieg/Ahrweiler" ändern, sondern auch die Überschrift selber.
Der Arbeitskreis hat nämlich seinen Namen geändert und heißt jetzt "Regionaler Arbeitskreis Bonn/Rhein-Sieg/Ahrweiler".
Leider kann ich in der Bearbeiten-Funktion ausgerechnet diesen Teil der Seite aber nicht ändern, die Überschrift ist immer grau/inaktiv.
Geht es irgendwie, die Überschrift zu ändern, oder muss ich den Artikel löschen und einen neuen anlegen?
Danke im Voraus und ratlose Grüße!
Margret Zavelberg (nicht signierter Beitrag vonMargret Zavelberg (Diskussion | Beiträge) 08:27, 28. Feb. 2020 (CET))
Komischerweise wird mir beim Verwerfen dieser Änderung [1] angezeigt, dass es sich um einen Nulledi handelt, den ich nicht verwerfen kann. Woran kann das liegen? --MGChecker – (📞| 📝| ) 01:37, 3. Apr. 2020 (CEST)
Dieser Abschnitt kann archiviert werden. MGChecker – (📞| 📝| ) 11:03, 3. Apr. 2020 (CEST): Scheint behoben zu sein.
Bearbeitung einer Seite
Hallo,
Ich habe am Abend des 19.03.2020 eine lange und aufwendige Bearbeitung des Artikels"Jüdisches Leben in WIen " durchgeführt.Leider kam es zu Problemen als ich speichern wollte. Die Änderungen liesen sich nicht speichern und am Ende musste ich die Seite neu Laden.Nun hatte ich die möglichkeit wieder weiter zu machen bei meiner Arbeit nur frierte oder verlangsamte sich der Browser und Firefox sendete mir eine Narchicht gleichen Inhalts.So blieb mir keine anderwe Wahl als die Bearbeitung nicht weiterzumachen aber somit verschwand alles.Könnten Sie mir helfen meine Arbeit wieder zu rekonstruiren? (nicht signierter Beitrag vonAri Fischkopf (Diskussion | Beiträge) 01:49, 20. Mär. 2020 (CET))
Hallo, bekommen diese Fehlermeldung: [Xou6kgpAICMAALjQ25cAAAAT] 2020-04-06 23:26:10: Fataler Ausnahmefehler des Typs „Wikimedia\Rdbms\DBQueryError“ Kann auf manche Seiten nicht zugreifen und in Texten nichts ändern. Bitte um Hilfe. --Erika39 · Disk · Edits01:33, 7. Apr. 2020 (CEST)
Kann es sein, dass der gute alte MwBot (Erbschaft von APPER) nicht mehr funktioniert? Ich bekomme den einen Fehler, der besagt, ich wäre nicht eingeloggt. Gestern gings noch. Keine Veränderung der Scripte und heute wirft er mich ab? --Wurgl (Diskussion) 10:41, 6. Apr. 2020 (CEST)
Die APPER-Seite hab ich ganz vergessen. Generell funktioniert der Login noch, allerdings bin ich (schon länger) dabei das umzustellen und will daher in das alte Zeugs nicht mehr viel Zeit investieren. Bei den Scripten, die noch mit MwBot laufen kommt beim Schreiben einer Seite die Fehlermeldung ist "Anonyme Beiträge von deiner IP-Adresse (172.16.7.167) sind nicht erlaubt. Bitte melde dich an.". Mit meiner neuen Klasse hab ich da kein Problem. Also irgendwas hat sich geändert. --Wurgl (Diskussion) 11:29, 6. Apr. 2020 (CEST)
Ich hab basierend auf MwBot mit Hgzh und anderen damals ein PHP-Framework für Bots aufgebaut, da funktioniert das zuverlässig. Wenn du da Interesse hast, sag einfach bescheid. Viele Grüße, Luke08151515:18, 6. Apr. 2020 (CEST)
Ich hab in den drei Jahren, seit der Übername des APPERbot, schon so ziemlich alle für mich notwendigen Funktionen in einem API-Framework gebastelt. Alles seitdem neu geschriebene, verwendet diese neuen API-Funktionen. Muss das nur noch in ein paar alte Script einbauen. Never touch a running system – aber nun rennt es ja nicht mehr, also ist die Zeit gekommen. --Wurgl (Diskussion) 15:32, 6. Apr. 2020 (CEST)
Sichtbarkeit von gesichteten Bearbeitungen für unangemeldete User
Seit mehreren Wochen fällt mir immer wieder auf, dass gesichtete Bearbeitungen zwar für den angemeldeten Benutzer sofort sichtbar sind, für den anonymen Betrachter jedoch i.d.R. mit erheblicher Verzögerung (teilweise mehrere Stunden). Zuvor war mir das nie aufgefallen. Feature, Bug oder technisches Problem (Serverlast)? --Phrontis (Diskussion) 18:05, 13. Apr. 2020 (CEST)
wobei der Link |url=https://ondemand-mp3.dradio.de/file/dradio/2020/04/14/das_oekostrom_archipel_aland_setzt_auf_100_prozent_dlf_20200414_1840_4dc47134.mp3 gültig ist.
Das liegt an der Umleitung von tools.wmflabs.org/giftbot auf giftbot.toolforge.org, wobei der Parameter nicht weiter übergeben wird. Am besten wird die zuständige Vorlage umgestellt (bei dem Wust habe ich allerdings keine Ahnung, welche das ist). – Giftpflanze11:20, 19. Apr. 2020 (CEST)
Ich hatte (vorher) im oberen Teil einen nicht allzuhohen Rahmen über die ganze Breite und so ein zerbrochenes Notensymbol mittig als einziges Element, hab dann auf das draufgeklickt (auf Neugierde, aus Frust, irgendsowas) und *zack* kam der übliche Fortschrittsbalken und der hat auch losgelabert. Jetzt kommt sofort dieser Laberbalken, im Firefox ganz unten, im Seamonkey weiter oben. --Wurgl (Diskussion) 15:25, 19. Apr. 2020 (CEST)
Hi Team, ich arbeite manchmal mit Tampermonkey um Benutzerskripte direkt im Chrome-Browser auszuführen. Das bringt natürlich das Problem mit sich, dass das mw-Objekt nicht direkt verfügbar ist. Erstaunlicherweise kann ich mw.loader.load problemlos ausführen, bei mw.loader.using bekomme ich hingegen den Fehler mw.loader.using is not a function angezeigt. Muss ich hier noch auf eine Funktion warten oder etwas nachladen? Besten Dank! --FNDE13:58, 24. Apr. 2020 (CEST)
Ist ein zeitliches Synchronisationsproblem, kenne ich auch.
Die plumpe Tour wäre, eine oder zwei Sekunden zu warten, aber unwürdig.
Es gibt in JS sowas wie window.watch() (Obacht bei GreaseMonkey, welches window das eigentlich wann ist, das unsafe brauchst du) und damit kannst du drauf statt Hunderte von Millisekunden 12 Mal abzuwarten eine neue Stufe triggern, sobald window.mediaWiki ein Objekt ist, und danach darauf triggern, ob auch window.mw.loader ja wohl ein Objekt ist, und danach empfehle ich trotzdem nochmal 50 Millisekunden zu warten weil der mw.loader nach seiner Erschaffung noch ein Momentchen für seine eigene Initialisierung und die Bereitstellung von .using() braucht.
Wenn du immer schon mw.loader.load hast, dann wäre die erste Stufe in deiner Konfiguration und Rechnerauslastung geschafft. Dann kannst du in einer Schleife von 50 bis Null alle 50 Millisekunden runterzählend fragen, ob mw.loader.using() eine function ist; müsste sie schon nach dem ersten Timeout sein.
Irgendwie ist in dem mw.loader kein abfragbares Event vorgesehen, das einem mitteilen würde, dass die Initialisierung beendet wäre.
Im Artikel Felix Philippi kann man die eingetragene Liste der Werke nur im Barbeitungsmodus sehen. Könnte das bitte jemand korigieren? Ich habs auf der Diskussionsseite angemerkt, es bewegt sich aber nichts. Dank im Voraus --Goerdten (Diskussion) 12:05, 30. Mai 2020 (CEST)
Sorry to use English. Hilf bitte mit, in deine Sprache zu übersetzen!
A maintenance operation will be performed on Thursday May 5 at 05:00 AM UTC.
It is supposed to take around 15 minutes.
During this time, you may not be able to edit the wikis. For more details about the operation and on all impacted services, please check on Phabricator.
A banner will be displayed 30 minutes before the operation.
Please help making your community aware of this maintenance operation.
In der Seitenleiste (Monobook) steht typischerweise E-Mail an „<Benutzername>“ senden. Befinde ich mich jedoch auf einer Seite wie Spezial:Linkliste/Benutzer:<Benutzername>/<Unterseitenname> steht dort E-Mail an „<Unterseitenname>“ senden. Bug oder lokal durch einen BOA lösbar?--Mabschaaf12:03, 14. Jun. 2020 (CEST)
Dieser Abschnitt kann archiviert werden. FriedhelmW (Diskussion) 17:49, 14. Jun. 2020 (CEST): Danke!
Some CSS for Vector has been simplified
Hallo!
I'd like to make a double-check about a change that was announced in Tech/News/2020/21.
Over-qualified CSS selectors have been changed. div#p-personal, div#p-navigation, div#p-interaction, div#p-tb, div#p-lang, div#p-namespaces or div#p-variants are now all removed of the div qualifier, as in for example it is #p-personal, #p-navigation …. This is so the skins can use HTML5 elements. If your gadgets or user styles used them you will have to update them. This only impacts the Vector skin.
On this wiki, this impacted or still impacts the following pages:
Ich hab heute mal versucht, bei Wikihistory das entsprechend anzupassen: Benutzer:Wurgl/WikiHistory.js. Klappt aber nicht, die Url ist okay, da kommt was zurück. Aber ich hab den Eindruck, dieses mw.loader.load() mag diese Änderung nicht so ganz toll.
Hast du mal im Developer View im Browser geschaut was dort als Fehlermeldung erscheint? --FNDE12:15, 27. Mai 2020 (CEST)
Wenn es denn eine Fehlermeldung gäbe. Da ist nix. Diese vier Zeilen finde ich, aber die sind vor und nach der Änderung vorhanden.
* JQMIGRATE: Migrate is installed with logging active, version 3.1.0
* DNT is on, logging disabled
* Use of "addOnloadHook" is deprecated. Use jQuery instead.
* JQMIGRATE: jQuery.fn.hover() is deprecated
Und das sind laut Browser auch nur Warnungen (aber farblich hervorgehoben) … die anderen Meldungen/Warnungen sind alle zwischen "klappt" und "klappt nicht" gleich, bis auf den Zugriff auf "https://tools.wmflabs.org/wikihistory/wiki/getauthors.php", der fehlt bei "klappt nicht".
erledigtErledigt Ich hab dieses Teufelszeug NoScript im Browser installiert und das hat mir scripte von toolforge.org ganz brav blockiert. Wunderschönes Eigentor. Jetzt klappt alles. --Wurgl (Diskussion) 14:39, 27. Mai 2020 (CEST)
Moin, bei einer Reihe von Links auf gleichnamige Galerieseiten (aufgefallen ist mir das bei 10 Kirchen) verschluckt {{Commons}} das, was in der Klammer steht. Beispiele:
Dann solltest das aber in die andere Werkstatt umtopfen.
PS: Es gibt 151 Klammerlemma, in denen einfach nur {{Commons}} steht, bei all denen sollte man eventüll abklopfen, ob es bei Commons die entsprechende Seite mit Klammer gibt. --Wurgl (Diskussion) 17:49, 15. Jun. 2020 (CEST)
hgzh war nur ausführendes Organ; wenn dann wär ich verantwortlich.
Standardmäßig entklammern wir alle Lemmata; eher selten ist die Situation dass wir ein Klammerlemma hätten und mit exakt gleichem Klammerlemma auf Wikidata eine Galerie liegen würde.
Es gibt einen Bot, der gelegentlich vorbeikommt und sowas repariert.
Sehr viel häufiger als die anderen ist die Situation, dass wir ein Klammerlemma haben, es aber auf Commons die Galerie ohne Klammern geben würde, oder aber mit einer ganz anderen Klammer.
@Wurgl: Magst du mal eine deiner phänomenalen Wartungsquarry bauen und herausfinden, wo es denn Stand jetzt Differenzen geben würde, und diese explizit zuweisen?
Einfach die Quarry-Zeilen umformatieren auf * [[Trefferseite]] und die auf commons:Commons:Sandbox angucken; wo Rotlink da Handlungsbedarf.
Vor anderthalb Jahrzehnten konnten wir noch nicht entklammern; inzwischen haben wir 581 Vorlagen mit Entklammerung und das ist heutzutage der bevorzugte Standard. Was etwas Migrationsbeschwerden nach sich zu ziehen pflegt, in Einbindungen wie in Köpfen.
Ich vermute, in ein paar Wochen haben das einige fleißige Wartungsameisen weggeknabbert; wenn du im Juli freundlicherweise nochmals eine Auswertung hier einstellen würdest, was dann noch übrig sei. Ist mittelüberschaubar; sowas wird auch gern mal händisch durchgeputzt.
Ich werde mal einige fleißige Bienchen so nach und nach alarmieren, sie mögen über deine Liste herfallen und Honig daraus saugen.
Wenn du sie dann übermorgen oder so vielleicht neu generieren würdest? Wegen mittlerweile erledigter Einträge und so.
Die Liste hier auf dieser Seite dürfte inzwischen obsolet geworden sein; wegen Traffic und der dafür nicht vorgesehenen Werkstattseite würde ich empfehlen, sie zu löschen und auf die kleine Wurgl-Seite umzuziehen.
Im englischsprachigen Artikel "Sant Andreu Jazz Band" wird auf den Leiter der Band, Joan Chamorro, verwiesen.
Der Verweis erscheint rot. Es gibt aber schon einen eigenen (deutschen) Artikel über Joan Chamorro, der Verweis sollte also blau erscheinen.
Merkwürdigerweise steht im Quelltext der Name Joan Chamorro schon mit doppelten eckigen Klammern.
Gibt es eine "Barriere" zwischen deutschen und englischen Artikeln,sodass in diesem Fall die eckigen Doppelklammern nicht wirksam werden? (nicht signierter Beitrag vonMinzbacher (Diskussion | Beiträge) 13:31, 4. Apr. 2020 (CEST))
Normale Links zeigen auf Seiten in der gleichen Sprachversion. Alles andere wäre ja auch problematisch: Für viele Lemmagegenstände gibt es Artikel in allen möglichen Sprachen, und welche ein Benutzer versteht, ist unklar. Auf welche sollte also verlinkt werden? Man kann aber mit Interwiki-Links explizit in ein andere Sprachversion verlinken. Diese sind aber zumindest in der deutschprachigen und englischsprachigen Wikipedia im Artikelfließtext nicht erwünscht. --Count Count (Diskussion) 13:42, 4. Apr. 2020 (CEST)
Es müsste eine Projekt-Richtlinie erarbeitet werden, wie allgemein mit der beschriebenen Angelegenheit umgegangen werden soll, und dies danach auch in WP:Weiterleitung hinterlegt werden.
Hallo liebe Community,
am Samstag ist mir aufgefallen, dass das WIWOSM nicht mehr korrekt funktioniert:
wenn ich eine Stadt, einen Landkreis oder ein anderes aktuelles Verwaltungsgebiet aufrufe, dann erscheint zwar die entsprechende Karte, teilweise aber nicht mehr der richtige Ausschnitt, zudem ist die blassrote Darstellung der Fläche inklusive der roten Grenzzeichnung des entsprechenden Gebiets bei allen Karten verschwunden.--Fraiser (Diskussion) 17:51, 14. Jul. 2020 (CEST)
@Fraiser: Das ist bedauerlich, aber ich fürchte das Werkstattpersonal hier steckt da nicht so in den Details drin. Probier es doch mal bei WD:GEO, die bauen diese Dingse. VG --PerfektesChaos15:56, 15. Jul. 2020 (CEST)
Hallo, bei von mir neu angelegten Seiten wird in der Wikipedia Android App unter dem Titel "Titelbeschreibung hinzufügen" angezeigt, siehe zum Beispiel den Artikel Ren Qian. Fast alle anderen Artikel haben eine solche Titelbeschreibung. Wo ist dieses Feature dokumentiert? Ich ziehe es vor, Bearbeitung an Wikipedia nur am Desktop vorzunehmen. Deshalb ergeben sich für mich einige Fragen:
Wo wird die Titelbeschreibung gespeichert?
Kann die Titelbeschreibung im Quelltext des Artikels festgelegt werden?
Wie wird kontrolliert, dass diese Titelbeschreibung Sinn ergibt? (Also was müsste ich auf meine Beobachtungsliste setzen?)
Die Titelbeschreibung liegt im zugehörigen Wikidata-Datenobjekt. Für Ren Qian ist das d:Q20747814. Schau es Dir einfach mal an, auf englisch ist dort "Chinese diver" eingetragen, der deutsche Eintrag fehlt.--Mabschaaf18:08, 3. Aug. 2020 (CEST)
Danke für die schnelle Antwort, ich habe den Eintrag nun ergänzt. Die Antworten auf meine drei Fragen sind also:
Wikidata
Nein
Wikidata-Dataobjekt auf die Beobachtunsliste setzen
Das kann in Special:MyPage/vector.js eingefügt werden (falls Du den Vector-Skin verwendest, sonst eben monobook.js o.ä.), dann steht auch in deiner Desktop-Version unterhalb des Seitennamens z. B. bei Ren Qian folgendes:
Hallo! Als ich mir grad einen Überblick über meine Benutzer-Unterseiten verschaffen wollte, ist mir aufgefallen, dass ich da noch vom Monobook-Skin die js und css habe. Wie kann ich die löschen lassen? Ist jetzt nicht zwingend wichtig, allerdings sind sie ja inzwischen einfach überflüssig. Gruß --MdE✉12:52, 2. Sep. 2020 (CEST)
@Hgzh: Danke dir! :-) @DestinyFound: SLA hatte ich versucht, aber in der Vorschau wurde nur der Quellcode angezeigt und die Vorlage nicht umgesetzt. Gruß --MdE✉18:25, 2. Sep. 2020 (CEST)
Heute ist mir zum zweiten Mal aufgefallen, dass - vermutlich - die Serverreplikation verzögert ist. Eine Änderung die ich vor ca. vier Stunden vorgenommen habe, ist im Artikel nicht zu sehen.
Auf meinem Smartphone ist (bei ausgeschaltetem WLAN) die Änderung im Browser-Modus (klassische Ansicht) sichtbar. --Molgreen (Diskussion) 11:06, 3. Apr. 2020 (CEST)
Hmm. Ich glaube, es ist wahrscheinlicher, dass einige der Varnish-Caches im esams-Datacenter in Amsterdam eine veraltete Version des Artikels haben. Ähnliche Probleme wurde in letzter Zeit öfter gemeldet. Der Replikationsverzug für die Datenbank-Server des für die deutschsprachige Wikipedia zuständigen s5-Shards zeigt mMn keine Auffälligkeiten.
Es wäre gut, wenn jemand, bei dem das Problem auftritt, mit einem Browser im Debug-Fenster den komplette HTTP-Protokollaustausch protokollieren könnte. Dann könnte man sich das genauer anschauen und ordentlich im Bugtracker melden. --Count Count (Diskussion) 11:37, 3. Apr. 2020 (CEST)
Hallo Count Count, vielen Dank für die Rückmeldung. Jetzt ist der Fehler weg . . . Wenn ich das wieder beobachten sollte, könnte ich den HTTP-Protokollaustausch einsenden. Ich hätte folgende Browser zur Auswahl: FF, IE, Edge, Chrome. Mit welchem Browser sollte ich dies am besten tun und vor allem wie geht das? Des weiteren würde ich das Ergebnis gern mailen. Ist das möglich? --Molgreen (Diskussion) 12:10, 3. Apr. 2020 (CEST)
In Chrome: Erst einmal ein Incognito-Fenster öffnen, damit keine Cookies mit gespeichert werden. Dann mit Ctrl-F5 neu laden, um eine alte Version im geteilten Incognito-Browser-Cache auszuschließen. Wenn der Fehler weiterhin reproduzierbar ist, mit F12 das Debug Fenster öffnen und mit Ctrl-R die Seite neu laden. Dann unter Network in der Liste rechts klicken und Save all as HAR file auswählen. Die kannst du mir gerne schicken und ich schaue es mir an und destilliere es in einen Bug Report. Ich schicke dir eine Wiki-Mail, dann hast du meine email-Adresse. --Count Count (Diskussion) 12:30, 3. Apr. 2020 (CEST)
Hallo Count Count, vielen Dank für die Erläuterung. Sollte ich den Fehler wieder einmal nachvollziehen können. Versuche ich Save all as HAR file zu dokumentieren. Ich hoffe, der Screenshot ist zum Nachweis vielleicht ein wenig hilfreich. Viele Grüße --Molgreen (Diskussion) 15:30, 3. Apr. 2020 (CEST)
P.S.: Obwohl ich diesen meinen Edit von vor 15min abgemeldet auch wieder nicht sehe, also Problem ist grundsätzlich noch da. --DB111 (Diskussion) 21:45, 3. Apr. 2020 (CEST)
@DB111: Ich habe dort mal geantwortet. Es wäre interessant zu sehen, ob der Date-Header eine falsche Zeit hat und ob die gleiche Cache-Maschine benutzt wird, wenn der Fehler wieder auftritt. --Count Count (Diskussion) 11:46, 4. Apr. 2020 (CEST)
Sowas ähnliches: Musste heute diese Liste Benutzer:APPER/VIAF neu generieren. Hab also auf toolforge den Job gestartet, nach einiger Zeit ins Log-File geguckt. Job war fertig. Dann Beobachtungsliste neu geladen … die Liste bzw. die Änderung war nicht drauf. Etwas später (dazwischen hab ich nach möglichen Ursachen gesucht) nochmals Refresh der Beobachtungsliste, da war das drauf. --Wurgl (Diskussion) 15:18, 4. Apr. 2020 (CEST)
Wäre möglich, sobald phab:T20562 (Bugzilla:18562) gelöst ist. Von 2009, Patch anhängig seit 2018. Würde automatisch alle nicht-lokalen mit class="external" ausstatten und class="external" löst gerade die Dekoration aus. Geduld. --PerfektesChaos15:09, 2. Mai 2020 (CEST)
Hallo PerfektesChaos, auf dem Portal:Physik haben wir ein entsprechendes Problem. Es gibt dort zwei Boxen, deren Inhalte sich ändern sollten: zum einen die Box mit dem "Artikel des Monats" (Änderung monatlich), zum anderen die "Aktuellen Jahrestage" (Änderung täglich). Ich habe es gestern mit Deinem obigen Vorschlag versucht, die Vorlage:NULL im Portal zu verwenden. Leider sehe ich heute, am 2.3.2020 um 8:30 Uhr, sowohl als nicht angemeldeter, als auch als angemeldeter Leser unter "Aktuellen Jahrestage -> heute" die Einträge vom 1.3.2020. Ich klicke absichtlich nicht auf "Serverseitig acktualisieren" (worüber ein Purge angestoßen werden könnte), damit das auch andere sehen können. Daher meine Fragen:
Habe ich die Vorlage:NULL evtl. an der falschen Stelle auf der Portal-Seite eingebaut?
Gehört die Vorlage:NULL anstelle direkt auf das Portal eventuell auf Portal:Physik/Jahrestage, wo wir mit {{Portal:Physik/Kalender/{{#timel: m-d | +0 days}}}} arbeiten? Oder auf beide Seiten?
Hätte ich bei der Verwendung der Vorlage {{NULL|{{LOCALDAY}}}}{{NULL|{{#timel:G}}}} statt {{NULL|{{LOCALDAY}}}}{{NULL|{{#time:G}}}} schreiben müssen, weil wir ja auf Portal:Physik/Jahrestage auch ein #timel verwenden?
Das einfache zuerst: Die Vorlageneinbindung ist schon korrekt und auch alle Varianten sind egal; eine reicht.
Der Trick soll dadurch wirken, dass eine Seite, die irgendwas von LOCALDAY oder #time: einbindet, früher™ mal einen Flag („TTL“) bekam und im Cache häufiger aktualisiert wurde; eigentlich für alle, mindestens aber für angemeldete Benutzer.
Das funktioniert derzeit noch nicht mal für angemeldete Benutzer, wie ich an Vorlagen-Dokus ablesen kann, wo in den Kopiervorlagen ein Abrufdatum mitgegeben wird. Das war früher mal tagesaktuell, ist aber schon seit einiger Zeit gern eine Woche alt.
Die WMF hat zurzeit wohl Probleme mit der physischen Serverlast.
Nicht angemeldete Lesezugriffe werden von vielleicht 1000 physischen Servern beantwortet, ich habe den Überblick über die Addition aller Maschinen in allen Rechenzentren verloren.
Über 99 % der Anfragen sind unangemeldet; die angemeldeten werden eigentlich auf spezielle Rechenzentren und Server umgeleitet und bevorzugt bearbeitet – erst recht eine Quelltextbearbeitung egal von wem.
Ich verfolge seit mehreren Jahren, dass die Serverfarmen sogar für angemeldete Benutzer nicht mehr hinterherkommen, die dargestellte Cache-Version zeitnah zu aktualisieren.
Der einzige Weg, den ich hier sehe, wäre auf WP:BA einen Bot-Betreiber dazu zu bringen, innerhalb DACH für eine kurze Liste auf einer geeignet formatierten Wiki-Seite hinterlegter Einträge „wiki:Seitenname“ alle elf Stunden ein tiefes API-purge auszulösen.
Die Zahl der gültigen Einträge könnte auf unter 100 begrenzt werden.
Alle elf Stunden mal 100 Seiten ist eine relativ geringe Frequenz, die die Interessen des Gesamtsystems berücksichtigt und die bestehende Überlast nicht noch verschlimmert.
Der Start könnte pro Eintrag eine Minute später gestartet werden, also beginnend um die elfte Stunde seit letztem Serien-Start bis zu anderthalb Stunden lang. Damit werden die Aktionen über breite Zeitspannen gestreut und wandern mit den Zeitzonen durch alle Spitzenzeiten.
Wobei noch das Problem mit der Zeitzone des Lesers hinzukommt. Ein deutschsprachiger Leser in Australien hat eine andere Vorstellung von "Heute" als einer in Deutschland, dort kann (vor allem beim Frühstückskaffee) schon ein Datum sein, das in D-A-CH zu diesem Zeitpunkt als "nächster Tag" bezeichnet wird. --Wurgl (Diskussion) 09:00, 4. Mär. 2020 (CET)
@Prüm: Vielen Dank für den Hinweis! Ich bin bis eben davon ausgegangen, dass der Trick mit {{NULL|{{LOCALDAY}}}}{{NULL|{{#time:G}}}}, den mir Benutzer:PerfektesChaos oben gegeben hat, seit 1. März 2020 auf dem Portal:Physik für die Aktualisierung der Jahrestage sorgt (siehe meinen damaligen Edit). Aufgrund Deines Hinweises habe ich den Quellcode jetzt erneut angesehen und feststellen müssen, dass Benutzer:Antonsusi die Null-Vorlage am 22. Juni 2020 wieder aus dem Portal entfernt hat. Dazu deshalb folgende Fragen:
1.) @Benutzer:Antonsusi: Was war der Grund für Deinen Edit? (Insbesondere, da mein HTML-Kommentar in der Zeile darüber Dich auf den Hintergrund der Zeile hätte hinweisen können...)
{{NULL}} hat meines Erachtens keine sinnvolle Funktion, insbesondere keine, die zum Löschen des serverseitigen Caches führt. Auch Parameterangaben sollten nichts bewirken. Aber da kann ich mich auch täuschen. --Prüm✉16:14, 6. Sep. 2020 (CEST)
Mittlerweile sind die Server so ausgelastet, dass noch nicht mal mehr der alte Trapper-Trick mit der Einbindung von CURRENTDAY usw. noch vorhersagbar sicher funktioniert. Das hatte in der historischen Cache-Programmierung mal garantiert, dass mit Ende des Server-Tages die Seite aus dem Cache flog, aber da sind inzwischen zwei Generationen Reform drüber gegangen. Glaskugel ist trübe. Kann klappen, vielleicht auch nicht.
Die WP:BA mögen eine bei WP:Bots angesiedelte Unterseite für atualisierungsbedürftige Seiten in diesem und befreundeten Projekten einrichten. Eine Benutzerseite eines nicht mehr aktiven Benutzers von einem nicht mehr aktiven Bot ist kein gutes Projektmanagement; das gehört sich als zentrale offizielle Projekt-Aufgabe.
Es kann sich auch jeder selbst in seinen Browser einen kleinen automatischen Aufweck-Bot programmieren; API-Anschubser reicht.
Die Vorlage NULL wird m. E. für allerlei Tricks genutzt, für die es m. E. bessere Lösungen geben sollte. Sowas erschließt sich niemandem. Das ist so ähnlich wie "display:none;". Ich würde es erst mal mit letzterem versuchen. Wenn das funktioniert, dann ist das besser als diese Nullvorlage. Ich füge es mal ein. ÅñŧóñŜûŝî(Ð)16:33, 6. Sep. 2020 (CEST)
(BK)
Die Aktivierung von {{CURRENTDAY}} usw. als Vorlagenparameter langt völlig, um die Parserfunktion auf die Eigenschaften der Seite wirken zu lassen.
Dass dieser Parameter in {{NULL}} angegeben ist und damit nichts dargestellt wird ist dabei völlig unerheblich.
Ich kann nur berichten, dass AsuraBot bzw. TaxonBota offenbar funktioniert, sei es nun auf der Hauptseite oder diversen Projektseiten mit täglicher Aktualisierung. --Prüm✉16:42, 6. Sep. 2020 (CEST)
Wenn der Parser auf {{NULL|{{LOCALDAY}}}} stößt, dann ist er gezwungen, den ersten Vorlagenparameter auszuwerten. Immer. Vorher kann die Auswertung der Vorlageneinbindung nicht fortgesetzt werden.
Damit wissen die Eigenschaften der Seite, dass diese Parserfunktion aufgerufen wurde.
Danach ignoriert Vorlage:NULL zwar diesen und jeden anderen Parameterwert, aber {{LOCALDAY}} ist ausgewertet worden.
Hingegen ist style="display:none" die alte Pfuscherei, Inhalte in die Seite einzufügen, die einem dann an anderer Stelle um die Ohren fliegen. Njet.
Das Problem ist ein anderes: Der Parser ist inzwischen zweimal umprogrammiert worden, und das Cache-Management inzwischen auch midestens einmal.
Außerdem ist dem Serverbetrieb der angemeldeten wie anonymen Anfragen die Cacherei inzwischen ein wenig an die Grenzen gestoßen, und man hat öfters Performance-Probleme.
Früher wurden zumindest die angemeldeten Benutzer bevorzugt bedient.
Kann aber auch alles wieder werden, und der Aufruf der Parserfunktion kann auch wieder zuverlässig einen Cache-Verfall-Zeitpunkt für die Seite setzen. Und das Cache-Management diesen angemeldet und anonym berücksichtigen.
„Diese Portalseite wird gewiss so oft aufgerufen, dass das hier genannte Problem extrem selten auftauchen dürfte“
Es ist völlig wurscht, wie oft eine Seite aufgerufen wird.
Bei jedem Aufruf wird der Inhalt immer aus dem Cache bedient.
Entscheidend ist, wann der Cache aktualisiert wird, nicht wie oft aufgerufen würde.
Maßgeblich ist für angemeldete wie anonyme Benutzer deshalb, dass:
Der Seiteninhalt bearbeitet und gespeichert wurde.
Ein Purge auf die Seite ausgeführt wird.
Eine „TTL-Funktion“ enthalten wäre, wozu LOCALDAY usw. gehören, und das Cache-Management diese Logik dann auch berücksichtigt; sie setzt einen Zeitpunkt, zu dem der Cache ungültig würde.
Im übrigen: Eine Vorlage, welche nichts zurückgibt, einzubinden, nur um den Server zu aktivieren, ist m.E. genauso "Pfuscherei", wenn auch etwas eleganter und genauso ein "versteckter Text" wie "display:none"
Das ist wohl einfach Geschmackssache. Ich finde den direkten Quelltextmit "display:none" besser. Warten wir doch mal ab, ob das Problem überhaupt noch auftaucht. ÅñŧóñŜûŝî(Ð)17:19, 6. Sep. 2020 (CEST)
@Dogbert66, Prüm: Mir ist noch eine andere Lösung eingefallen: Ich habe die TTL-Funktion jetzt als Untertitel direkt in den Abschnitt "Jahrestage" integriert. Damit dürfte das erledigt sein. ÅñŧóñŜûŝî(Ð)18:41, 6. Sep. 2020 (CEST)
@Prüm, PerfektesChaos, Antonsusi: Vielen Dank für Eure zahlreichen Beiträge oben. Ich beantworte sie jetzt nicht einzeln, sondern fasse das mal aus meiner Sicht zusammen (und übersehe dabei hoffentlich keine Frage/Anmerkung):
@Antonsusi: wenn ich das richtig verstehe, so ging es Dir bei Deinem ursprünglichen Edit darum, dass Du die Vorlage:NULL vermeiden möchtest (aus Gründen, die ich noch nicht verstanden habe!). Daher würdest Du {{LOCALDAY}} lieber in einem <span style="display:none;">{{LOCALDAY}}{{#time:G}}</span> sehen als in {{NULL|{{LOCALDAY}}}}, bzw. gleich außerhalb als angezeigter Text wie in Deiner neuesten Version, in der Du Für {{CURRENTDAY}}. {{CURRENTMONTHNAME}}anzeigen lässt.
Daher meine Fragen @PerfektesChaos: Sind diese drei Varianten betreffend der Cache-Aktualisierung äquivalent, oder siehst Du da einen Unterschied? Dem oben Geschriebenen entnehme ich, dass Du die Variante mit Vorlage:NULL klar bevorzugst; dennoch hier nochmal die Frage: würden denn die beiden neuen Varianten ("display:none" bzw. tatsächlich dargestellter Text) prinzipiell funktionieren?
@Antonsusi: Nachdem wir das Portal während unserer Redaktion-Physik-internen Diskussion um die informativ-Auszeichnung sehr intensiv besprochen haben, weiß ich dass die zusätzliche Zeile, die Du mit Deinem neuesten Edit (d.h. mit Für {{CURRENTDAY}}. {{CURRENTMONTHNAME}}) eingefügt hast, unerwünscht ist. Die Argumente dagegen sind unter anderem: das kostet vertikalen Platz, der überflüssig ist; das Datum wird in den drei Kategorien heute/morgen/übermorgen vor jedem einzelnen Namen genannt, daher ist die Zeile redundant. Eine Lösung, die keinen weiteren Platz kosten würde, wäre, das {{CURRENTDAY}}. {{CURRENTMONTHNAME}} in die Zeile "Serverseitig aktualisieren" zu packen, die dann etwa "Wenn heute nicht der xx.xx ist, dann klicke bitte auf Serverseitig aktualisieren" lauten könnte.
@Prüm: So toll ich Deinen Vorschlag mit dem Bot finde, der gemäß der damaligen Diskussion in der Redaktion Physik auch favorisiert wurde, so muss ich Benutzer:PerfektesChaos zustimmen, dass der von Dir vorgeschlagene Bot etwas merkwürdig aussieht:
– Benutzer:AsuraBot gibt gleich am Anfang in der Box an " Der Bot ist zurzeit außer Betrieb",
– der letzter Beitrag von Benutzer:AsuraBot datiert von 17:01, 4. Dez. 2018 (siehe hier),
– der Bot wird von Benutzer:sitic betrieben, dessen letzte Bearbeitung am 14:24, 2. Sep. 2015 stattfand (siehe hier),
Fazit: 1.) Als kurzfristige Lösung, würde ich entweder den oben vorgeschlagenen Text Wenn heute nicht der {{LOCALDAY}}. {{LOCALMONTHNAME}} ist, dann klicke bitte auf {{purge}} einfügen (ggf. mit small-Tag verkleinert, falls es nicht in eine Zeile passt. Dieser Text muss dann aber auf dem Portal und nicht auf Portal:Physik/Jahrestage vorkommen, was derzeit noch auf dem 6.9. steht !!!), oder aber auf die letzte derzeit hoffentlich zuverlässig funktionierende Version zurücksetzen, also die letzten drei Edits revertieren.
Der Einbau, genauer die Ausführung von LOCALDAY CURRENTDAY usw. in eine Seite war völlig hinreichend, um bei der früheren Parser-Programmierung ein Cache-Ablaufdatum auszulösen.
Das ist zurzeit offenbar hinfällig, weil weder die Parser-Programmierung noch dieselbe ist und das mutmaßlich momentan nicht auswertet, noch das Cache-Management noch dasselbe ist und auf den Servern keine Rücksicht auf einen Verfallszeitpunkt genommen würde (mutmaßlich auch aus Performancegründen).
Beides kann im Lauf der Zeit aber auch mal wiederkommen.
Vor einem Dutzend Jahren hatten auch mal Platzhalter im Cache-Text gestanden, die erst im Moment des Seitenabrufs durch Leser mit brandaktuellen Daten gefüllt wurden. Mit zunehmender Vorlagenprogrammierung kam man davon jedoch wieder ab, weil diese Daten nicht direkt im Seitentext angezeigt wurden, sondern in programmtechnischen Konstrukten verglichen wurden und deshalb auch diese Programmierung hätte neu ausgeführt werden müssen.
Eine von den Lesern optisch nicht wahrnehmbare Ausführung von LOCALDAY CURRENTDAY war der heimliche Kunstgriff, um eine automatische Aktualisierung vozunehmen.
Beide Lösungen, eine Auswertung als Vorlagenparameter ohne dann diesen Parameterwert in die Seite zu übernehmen wie auch den Inhalt in die Seite einzubauen und ihn dann rein optisch auszublenden sind hinsichtlich ihres Hack-Charakters genau gleichwertig.
Der gravierende Nachteil des style="display:none" ist jedoch, dass diese Inhalte nach wie vor Inhalt der Seite sind, und in Suchergebnissen von Cirrus und externen Suchmaschinen und als PopUp oder wo auch immer gleichberechtigter Inhalt der Seite sind und als solche erscheinen, weil für diese Inhalte die optische Sichtbarkeit nicht berücksichtigt wird. Deshalb ist die NULL-Variante, zwar Vorlagen auszuführen aber den produzierten Inhalt nicht anzuzeigen die robustere und sicherere Methode.
Es ist ein Problem mit der Organisation von WP:Bots, dass es dort zur Thematik „Purge“ keine Unterseite und Prozedur und zu berücksichtigende Seite gibt, oder eine ausgewertete Kategorie.
Die Seite Benutzer:AsuraBot/Purges ist zurzeit diejenige „Projektseite“, über die das Management abgewickelt wird.
Das ist doof und wurde auch bereits von mir beanstandet.
Der Bot ist inaktiv, und man muss davon ausgehen, dass die Eintragungen dort wirkungslos wären.
Zurzeit wird sie aber trotzdem vom TaxonBota ausgewertet.
Sowas gehört unabhängig von irgendeinem einzelnen Bot, der in irgendwelchen Jahren die Aufgabe übernimmt, auf eine zentrale Unterseite von WP:Bots und dort wird diese Liste gepflegt, ggf. auch eine entsprechende Wartungskat, und es wird vermerkt welcher Bot im Sommer 2020 grad diese einheitliche Liste abarbeiten würde.
Nebenbei bemerkt ist es nicht erforderlich, mich in dieser Werkstatt anzupingen; ich beobachte sie sowieso, habe sie begründet und zucke bei jeder roten Alarmglocke zusammen.
@PerfektesChaos: (erstmal sorry für das oben erfolgte Klingelnlassen Deiner Benachrichtigungsglocke ...) Ich wollte gerade gemäß Deinem Vorschlag einen Beitrag auf Wikipedia:Bots/Anfragen posten; beim Überprüfen der Links habe ich dann aber Deinen Beitrag hier gelesen, dem ich entnehme, dass auch Du meinst, dass TaxonBota die Aufgabe von AsuraBot übernommen hat. Meine Frage habe ich daher erstmal nicht auf Wikipedia:Bots/Anfragen gepostet, sondern in meinem Benutzernamensraum zwischengelagert (siehe hier).
@Doc Taxon: Vielen Dank für die Bestätigung, dass Du (bzw. TaxonBota) das Purge-Skript übernommen hast, und dafür, dass Du den Eintrag gleich vorgenommen hast. Frage: Schreibt TaxonBota das auf Benutzer:AsuraBot erwähnte Log an eine alternative, einsehbare Stelle? Ein kurzer Blick ins Log wäre für mich hilfreich, bevor ich die ganzen Erwähnungen von Vorlage:CURRENTDAY und Vorlage:Purge vom Portal entferne. --Dogbert66 (Diskussion) 18:02, 7. Sep. 2020 (CEST)
Halten wir fest: Vorlage:NULL ist besser als "display:none" (wegen Cirrus) und eine sichtbare Platzierung, also die Nutzung von CURRENTDAY etc. ist noch eleganter.
@Dogbert66: Wenn du heute, am 7. September, auf die Portalseite schaust, dann kannst du feststellen, dass unter "heute" kein Eintrag zu finden ist. Nun kann zwar jeder einen Tag zurückrechnen, aber elegant ist es ohne explizites Datum trotzdem nicht. Letztendlich ist es aber egal, wo man eine sichtbare Einbindung platziert. Damit ist dann sowohl für den de:WP-Leser in Australien, als auch für den de:WP-Leser auf Hawaii sofort klar sichtbar, auf welches Datum Bezug genommen wird. Einen Nutzen, den man diskret mitnehmen kann. ÅñŧóñŜûŝî(Ð)18:56, 7. Sep. 2020 (CEST)
@Antonsusi: Da Doc Taxon das Portal jetzt auf die Liste der Artikel genommen hat, die morgen früh um 0:00 Uhr gepurget werden, ist die Erwähnung von {{CURRENTDAY}} und ähnlichem jetzt nicht mehr nötig, egal ob in Vorlage:NULL oder anderweitig. Das würde ich gerne testen, indem ich {{CURRENTDAY}} wieder aus dem Quellcode entferne und nach Mitternacht die dann gültigen Daten auf dem Portal angezeigt werden. Ich bitte Dich daher, die gleich erfolgende Änderung nicht zu revertieren, und auch heute nacht kein manuelles Purge durchzuführen. --Dogbert66 (Diskussion) 19:11, 7. Sep. 2020 (CEST)
Es wird mich nicht in Trauer stürzen, wenn du es entfernst. Die Zeitzonenproblematik für ferne Leser bleibt aber dann bestehen. Das sollte man aber im Portal abklären. ÅñŧóñŜûŝî(Ð)19:21, 7. Sep. 2020 (CEST)
So, nun habe ich das Verhalten gerade mal getestet: Um 0:22 war für einen nicht angemeldeten Nutzer sowohl bei Portal:Physik/Jahrestage, als auch beim Portal selber der 8.9. noch unter "morgen" gestanden; um 0:43 war der 8.9. dann "heute". Das deutet auf einen Bot-Lauf zwischen 0:22 und 0:43 hin.
@Dogbert66: ich habe das gerade noch mal optimiert, dass das Purging tatsächlich 0:00 oder aufgrund der Reihenfolgen 0:01 passiert. Ein Log zum Purging wäre gigantisch, und täglich erst recht. TaxonBota nutzt schließlich nicht prahlada.py, das ist Geschichte, und wie da die Logs aussahen, konnte ich schon damals nicht mehr nachvollziehen. Für /Jahrestage könnte ich aber ein eigenes Log unter /Jahrestage/Purge-Log anlegen, wenn's beliebt. – Doc Taxon • Disk. • 14:01, 8. Sep. 2020 (CEST)
@Doc Taxon: Sorry, ich habe Dir noch nicht geantwortet, weil ich dachte, ich würde das mal ein zwei Nächte beobachten. Das ist gestern einfach daran gescheitert, dass ich um Mitternacht schon geschlummert habe und mir nicht angesehen habe, dass die Aktualisierung für einen nicht angemeldeten User sichtbar wurde... Vorlage:Smiley/Wartung/;) Jetzt aber erst einmal vielen Dank, dass Du a) TaxonBota mit dem Purge beauftragt hast, und b) die Bot-Aufgabe jetzt sogar nochmal optimiert hast. Was Deinen Vorschlag angeht, ein Log auf /Jahrestage/Purge-Log anzulegen, so wäre das allerdings nur ein Proxy für die eigentlich relevante Information:
Die Seite Portal:Physik/Jahrestage direkt schaut sich wohl niemand an. (Ich habe um 13:04, 7. Sep. 2020 oben ja auch festgestellt, dass die eigentliche Portal-Seite bereits den 7. angezeigt hat, obwohl /Jahrestage noch auf dem 6. stand.) Der wichtigere Lauf ist der vom Portal selber, der dann ja den Code von /Jahrestage inkludiert und mit richtigem Zeitstempel ausführt.
Nützlich ist das dennoch, weil wenn ich sehe, dass das Purge von Portal:Physik/Jahrestage nicht gelaufen ist, so muss ich annehmen, dass auch das darauffolgende Purge von Portal:Physik nicht lief und kann Dich darüber informieren. Und das auch dann, wenn das eigentlich interessantere Log zum Portal gar nicht existiert.
Das heißt als: ja gerne würde ich Deinen Vorschlag annehmen, wenn sich das ohne großen Aufwand realisieren lässt. Ich hielte es allerdings für wichtiger, dass auf Portal_Diskussion:Physik ein nicht zu archivierender Abschnitt steht, der diesen Botlauf dokumentiert. Die dort relevante Information wäre:
"Bei der Aktualisierung der Jahrestage und des Artikels des Monats gab es in der Vergangenheit das Problem, dass insbesondere nicht angemeldeten Nutzern noch eine veraltete Version aus dem Server-Cache angezeigt wurde. Dies wurde dadurch behoben, dass die Portalseite auf AsuraBot/Purges erwähnt wird. Das dazugehörende Skript wird zwar nicht mehr ausgeführt (der Bot ist inaktiv), dennoch gibt es ein anderes Skript (wie heißt es??), das TaxonBota täglich zwischen 0:00 und 0:01 laufen lässt, und das die serverseitigen Caches der auf AsuraBot/Purges genannten Seiten löscht (d.h. ein Purge ausführt). Der dafür verantwortliche Botbetreiber ist Benutzer:Doc Taxon."
Diese Anmerkung ist nur tatsächlich deshalb etwas verwirrend, weil die Seite AsuraBot/Purges zu einem inaktiven Bot gehört; sie sollte eigentlich eine Unterseite bei TaxonBota sein (oder sogar eine noch allgemeinere Seite, wie von PerfektesChaos auf WP:BA#Purge-Bot definieren angefragt wurde). Was meinst Du? --Dogbert66 (Diskussion) 19:14, 9. Sep. 2020 (CEST)
Anmerkung: heute wurde für nicht angemeldeten User um 0:10 der 10.9. korrekt als "heute" angezeigt. Das deutet auf einen sauber abgeschlossenen Purge-Lauf hin. --Dogbert66 (Diskussion) 00:14, 10. Sep. 2020 (CEST)
@Dogbert66: Was Du auf Eure Projektdisk schreibst, musst Du natürlich selbst wissen, das Script heißt schlicht purge0.tcl – ich könnte das Log auch nach Portal:Physik/Purge-Log verschieben und den Purge beider Portalseiten listen. Liebe Grüße, – Doc Taxon • Disk. • 00:15, 10. Sep. 2020 (CEST)
@Doc Taxon: Vielen Dank! Die einzelnen Punkte nochmal mit aus meiner Sicht absteigender Wichtigkeit: a) Fändest Du es nicht sinnvoller, wenn purge0.tcl statt von AsuraBot/Purges zu lesen von TaxonBota/Purges lesen würde, wo man dann die Einträge vornehmen kann? b) Ja, gerne ein Log beider Skript-Läufe unter Portal:Physik/Purge-Log. c) Vielen Dank für den Skript-Namen, ich nehme den Eintrag auf Portal_Diskussion:Physik in den nächsten Tagen gerne selbst vor; der Text sollte dann aber auch die Ergebnisse von a) und b) enthalten. --Dogbert66 (Diskussion) 10:04, 10. Sep. 2020 (CEST)
@Dogbert66: zu Punkt a) Idee, Konzept, Programmierung und Betrieb gingen damals auf den Botbetreiber des AsuraBot, Benutzer:sitic. Was ich selbst gemacht habe, ist die neue Programmierung in einer anderen Programmiersprache. TaxonBota wird von mir hauptsächlich eingesetzt, um andere nützliche Bots, die nicht mehr laufen, bestmöglich zu ersetzen, wie AsuraBot, EfenBot, MerlBot u.a. Man kann vielleicht die Seiten von damals in den BNR TaxonBota verschieben, aber bekannt wurden die Bots auf ihren üblichen Seiten in ihrem BNR. Aus diesem Grund, aber auch um die ehrwürdige Arbeit der ehemaligen Kollegen zu würdigen, habe ich den Ort dort belassen. Wenn ich es endlich mal geschafft habe, auf der Benutzerseite TaxonBota, aber auch TaxonBot, darzustellen, womit sich die Bots alles beschäftigen, kann man das auch nachvollziehen und die Purge-Seite da finden, wo sie auch ist. Ich werde das mal auf meiner Prio-Liste weiter nach oben ziehen. Liebe Grüße, – Doc Taxon • Disk. • 13:33, 10. Sep. 2020 (CEST)
Nein, das sollte auch nicht auf Taxonbota stehen, sondern als Gemeinschaftsangelegenheit des Projekts auf WP:Bots/Purge etc. Ansonsten kommt Taxonbotb oder Taxonbotc oder Benutzer:TaxonBot wird zuständig und wir wandern ewig mit dieser Seite in der Gegend rum.
Für die Perioden, in denen anders nicht sichergestellt werden kann, dass der Server die Seiten aktualisiert ausliefert, gehört das als zentrale Gemeinschaftsaufgabe verwaltet, und da kann dann jeweils vermerkt werden, welcher Bot das jetzt im Moment grad betreuen würde.
In welchem Vierteljahr genau welcher Bot die Aktionen ausführt ist nachrangig, und die Botbetreiber können auch jederzeit untereinander die Aufgaben tauschen; das kann den Benutzern ziemlich egal sein, so lange es läuft.
Auf der zentralen Projektseite zum Thema Purge kann ja auch die Historie früherer Jahrzehnte erwähnt werden, aber wie 2010 mal verdienstvoll ein Purge gehandhabt wurde kann nicht 2020 und in Ewigkeit unsere Seitenstruktur und das Verständnis der Vorgänge beeinträchtigen. Wie gesehen, hat das für etliche KiloByte und Stunden Verwirrung gesorgt. Und ein Purge an eine Seite zu senden ist nicht so hochwissenschaftlich; dazu hatte ich auch schon mal einen Automatismus an meine Beo gekoppelt, der einmal in 24 Stunden ein purge geschickt hatte.
nee, das glaub ich jetzt nicht. Es gibt hier so viele Botbetreiber, die regelmäßige Bots für die Gemeinschaft laufen haben, z.B. Archivierer, Nachsignierer, Informierer, Arbeitslistenersteller, Statistikenersteller ... Und jetzt zeig mir mal ein einziges Skript, das seine Projektseite als Unterseite von WP:Bots zu stehen hat. Auf alle Fälle macht es Sinn, wie Du es beschreibst, ich werde das aber nicht alleine so machen. Zumindest kann man ja erst mal eine Linkseite als Unterseite anlegen, die die Gemeinschaftsaufgaben der Bots listet, damit wäre schon mal viel gewonnen. Liebe Grüße, – Doc Taxon • Disk. • 21:26, 10. Sep. 2020 (CEST)
Vielen Dank an die Zusammenarbeit: an PerfektesChaos für die ursprüngliche Zwischenlösung mit der Vorlage Null; an Prüm für den Hinweis auf AsuraBot und natürlich auch einen Riesendank an Doc Taxon für die zahlreichen Tätigleiten von TaxonBota und die umkomplizierte und schnelle Einarbeitung neuer Änderungen. --Dogbert66 (Diskussion) 10:09, 12. Sep. 2020 (CEST)
da ich nun wegen Urheberrechten etc, das nicht via copy and paste lösen will, weil es dann sicherlich irgendeinen bürokratisch/formalen Ärger gäbe, melde ich mich also hier und bitte um Hilfe
Die Stadtstaaten kannst du eigentlich streichen, bei denen ist im technischen Sinn nämlich keine Infobox vorhanden (sprich: ein Element mit der CSS-Klasse infobox), der Formatter springt also gar nicht erst an und kann keinen Schaden anrichten. Ich zerbreche mir aber seit gestern den Kopf, was der Unterschied zwischen Bielefeld und Düsseldorf sein soll, die müssten sich nämlich echt identisch verhalten.–XanonymusX (Diskussion) 01:04, 20. Sep. 2020 (CEST)
Hast recht. Ich habe das ganze noch mal umstrukturiert und (hoffentlich) übersichtlicher gemacht. Außerdem auch in den Phabricator Task kopiert. -- Chrisahn (Diskussion) 17:10, 20. Sep. 2020 (CEST)
Anmeldung in Firefox-Android führt zu leerer Seite
Seit einiger Zeit habe ich jetzt schon Probleme, Wikipedia auf meinem Handy in der mobilen Ansicht angemeldet zu öffnen.
Was funktioniert:
mobile Ansicht ohne Anmeldung
klassische Ansicht
Was nicht funktioniert:
mobile Ansicht mit Anmeldung
Das Problem sieht so aus: Ich bin in der mobilen Ansicht, gehe auf die Anmeldeseite und melde mich an. Die Anmeldung funktioniert, eine neue Seite wird geladen, und kurz bevor sie fertig ist, wird die Seite blank (weiß). Auch wenn ich jetzt einen Artikel per URL aufrufe, sehe ich ihn beim Laden kurz, und dann ist er wieder weg. Wenn ich im Browser (Firefox für Android) die Desktop-Ansicht auswähle, bleibt der Effekt trotzdem, bis ich das m aus der URL rauswerfe.
Ich habe mich bereits sowohl ab- und wieder angemeldet als auch die Cookies/aktive Logins gelöscht. Erste Anmeldung dann, sofort gleiches Problem. Woran kann das liegen? Was kann ich tun? Danke und Gruß --MdE✉15:18, 7. Aug. 2020 (CEST)
Falls jemand noch einen Tipp für mich hat, bitte anpingen, ich schau erst mal nicht mehr hier vorbei. Auch wenn der Desktop-Modus auf dem kleinen Handyschirm ätzend ist... Gruß --MdE✉16:27, 22. Aug. 2020 (CEST)
Auf einen Verdacht hin habe ich nochmal alle Helferlein/Modifikationen der Oberfläche abgeschaltet – ohne Erfolg, daran liegt es auch nicht. Inzwischen hat der FF für Android ein großes Update gemacht, auch das hat nichts geändert. Es ist immer, sobald die Kombination de.m.wikipedia.org und Anmeldung als MdE auftritt. In einem privaten Browsertab keine Probleme trotz mobiler Ansicht. Hab ich irgend eine Einstellung übersehen? Gruß --MdE✉11:50, 27. Aug. 2020 (CEST)
@FriedhelmW: Danke für den Tipp! Cache leere ich ohnehin bei solchen Tests und stets beim Beenden des Browsers. Aber der Safemode funktioniert! Wie finde ich dann den Übeltäter? Alle Helferlein etc. über die Einstellungen abzuschalten hatte ja nicht geklappt. Gruß --MdE✉20:21, 2. Okt. 2020 (CEST)
Klasse, danke dir! :-) hier Hatte sich der Übeltäter versteckt. Seltsam, dass das nur in der mobilen Ansicht Probleme gemacht hat. Gruß --MdE✉21:38, 2. Okt. 2020 (CEST)
AbuseFilter notice: rmspecials() will no longer remove whitespace when used in filters
Hallo,
Apologies if you are not reading this message in your native language. Hilf bitte mit, in deine Sprache zu übersetzen.
We are making a change to the AbuseFilter extension, which may impact the behavior of some existing filters. The rmspecials() function currently removes spaces in addition to special characters. We will change it such that it will only remove special characters. The existing rmwhitespace() can be used to remove spaces whenever applicable.
As reported on https://phabricator.wikimedia.org/P12854 we believe at least one filter on your wiki has been identified to use the rmspecials() function. Please consider updating these filters by wrapping rmspecials() inside rmwhitespace() like this: rmwhitespace(rmspecials(....))
We need you to update the relevant filters within 2 weeks of this notice. If one of the community members with proper access is volunteering to take this on, we ask them to please respond below and notify User:Huji in their response or in the edit summary. If we don't hear back from you within 2 weeks, Huji will edit the relevant filters on your wiki per the global abuse filter maintainer policy, to ensure the filters won't break once the change is implemented. Thank you for your consideration!
Als ich gestern auf meinem Mobilgerät durch ein paar Länderartikel gegangen bin, ist mir aufgefallen, dass der MobileHTMLFormatter (oder wie das Teil heißt) offenbar wieder einmal durcheinandergekommen ist. Im Direktvergleich von Deutschland und Italien (m-Domain) sieht man es deutlich; Deutschland beginnt korrekt mit dem ersten Absatz, Italien hingegen mit der Infobox. Das Warum habe ich nicht verstanden, es kann weder am BKH (in beiden Fällen Vorlage:Hinweisbaustein) noch an der IPA-Vorlage liegen (die das letzte mal Schuld war, wenn ich mich recht erinnere), da in beiden Artikeln identisch. Meine erste Vermutung war, dass es an der Vorlage:Positionskarte liegt, aber weder verschieben noch löschen (bei Italien probiert) scheint das Verhalten zu korrigieren. Das Fehlverhalten betrifft so gut wie alle Länderartikel; korrektes Verhalten habe ich neben Deutschland nur bei Österreich feststellen können. Die Vorlage:Infobox Staat ist korrekt mit der Klasse infobox versehen, also weiß ich nicht mehr, wo ansetzen. Irgendwelche Ideen? Gruß–XanonymusX (Diskussion) 15:59, 23. Okt. 2020 (CEST)
Ich habe mal die beiden Einleitungen und Infoboxen vertauscht, das führte aber nicht zu neuen Erkenntnissen. Der Italien-Artikel bleibt fehlerhaft. -- hgzh17:16, 23. Okt. 2020 (CEST)
Oh, einen Verdacht habe ich jetzt (da es offenbar nur bei Deutschland und Österreich funktioniert): Wenn die IPA-Vorlage zweimal verwendet wird, müssen die TemplateStyles einmal dedupliziert werden, was einen link-Tag im Quelltext hinterlässt. Damit wäre das Ganze tatsächlich eine Fortsetzung des Bugs vom letzten Mal (phab:T263306), wie Count Count korrekt kommentiert hatte. Dann werde ich den Task wohl doch wieder aufmachen müssen!--XanonymusX (Diskussion) 17:29, 23. Okt. 2020 (CEST)
War es doch nicht. Schuld waren die unsichtbaren Wartungslinks am Ende der Infobox, die, wenn sie angesprungen sind, einen unsichtbaren ersten Absatz erzeugt haben. Hab jetzt einfach die unsichtbaren spans in divs umgewandelt, dann entstehen keine zusätzlichen Absätze mehr. Noch so eine der Tücken des Wartungslink-Systems … Ich hoffe, es ist nach dem Eingriff sonst nichts kaputt gegangen, das Verhalten bei Italien ist jedenfalls wie gewünscht!–XanonymusX (Diskussion) 21:00, 23. Okt. 2020 (CEST)
Es wäre sehr angenehm, wenn bei Suchworteingaben Buchstabendreher "automatisch" verarbeitet würden.
Besonders die Möglichkeit die Schriftgrösse zu verändern (vergrößern) würde ich sehr begrüssen (vielleicht nicht nur ich)
Hallo, Buchstabendreher werden (nach kurzem Selbsttest) eigentlich in den Suchvorschlägen aufgelöst. Die Schriftgröße lässt sich im Browser mittels Strg++ vergrößern. -- hgzh19:33, 13. Aug. 2020 (CEST)
Warum stellst du denn deine Frage nicht an den Betreiber des Tools? Es gibt dort doch extra eine →Diskussionsseite Ich sehe keinen Fehler in deiner Einbindung, oder hast du es möglicherweise auf deiner Benutzerseite selbst versucht? Dann müsstest du vermutlich den Slash hinten ":dewiki:Benutzer:M-B/" weglassen, damit dieses auch aktiviert wird. @PC? --Liebe Grüße, LómelindeDiskussion18:37, 15. Aug. 2020 (CEST)
wäre es auch möglich das Umbruch tool "<br>" so einzustellen,
daß nicht automatisch zum Anfang der nächsten Zeile gesprungen und eine leere Zeile angefügt wird
ähnlich wie bei manchen Zeitungen, die beim copieren von ihren Seiten zwangsweise die url mitliefern
bekommt mensch so mehr geliefert wie sinnvoll ist
Hallo, <br> ist nicht irgendein Tool, das wir irgendwie einstellen könnten, sondern ein weltweit verwendetes HTML-Element, das überall den gleichen Effekt hat und auch haben muss. Abgesehen davon verstehe ich das Anliegen nicht, der Sinn und Zweck von <br> ist ja gerade, einen Zeilenumbruch zu erzwingen. -- hgzh10:34, 6. Okt. 2020 (CEST)
Hallo, ohne dass ich eine Einstellung geändert hätte, sind die Links zu den Sprachversionen seit heute verschwunden. Allgemeines Problem oder was kann ich tun? Vielen Dank!--RikVII.my2cts20:27, 16. Okt. 2020 (CEST)
Bei mir treten seit mehreren Tagen beim Bearbeiten von Artikeln (ich arbeite häufig statt Quelltext mit dem visuellen Editor) technische Probleme auf. So lässt sich, unabhängig vom Artikel, bei dem erstmaligen Klick auf "Bearbeiten" die Benutzeroberfläche nicht korrekt bedienen. Wenn ich bspw. eine beliebige Textstelle anklicke und dort etwas versuche hinzuschreiben, entsteht der Text nicht dort, sondern mehrere Zeilen darunter. Teilweise lässt sich die Seite, obwohl im Bearbeitungsmodus, überhaupt nicht bearbeiten. Zwar löst sich die Problemartik bei einem wiederholten, auf, wenn der Bearbeitungsmodus beendet - und nochmals geöffnet wird. Ein einfaches Aktualisieren der Seite reicht manchmal aber auch nicht aus, da der Bearbeitungsmodus dabei nicht wirklich geschlossen wurde. Ob die technischen Defekte im Quelltextmodus ebenfalls bestehen kann ich nicht sagen. --LennBr (Diskussion) 22:01, 31. Okt. 2020 (CET)
@LennBr: Welche Web-Browser und welche Web-Browser-Versionen wurden getestet? Passiert dies auch mit einem anderen Browser (welchem)? Welcher Editor wird genutzt? Passiert dies auch ohne auf Wikipedia angemeldet zu sein? --AKlapper (WMF) (Diskussion) 09:11, 2. Nov. 2020 (CET)
@AKlapper (WMF): Nutzen tue ich Wikipedia mittels des VisualEditors und Mozilla Firefox (derzeit: Version 82.0.2 (64-Bit)). Die Löschung des Cache hat nichts gebracht. Wenn das Problem weiter anhält, teste ich es mit anderen Browsern. Einige wenige Tests als unangemeldeter Benutzer fielen negativ aus. Dies muss aber nichts heißen, da diese Fehler auch nicht jedes mal als angemeldeter Benutzer auftreten. Obwohl nicht gefragt: Einen Vergleich zwischen langen und kurzen Artikeln kann ich derzeit noch nicht ziehen. Obwohl diese Vorkommnisse vor allem bei der Bearbeitung von langen Artikeln auftraten, war auch schon die Bearbeitung eines kürzen Artikels ebenfalls nicht möglich. --LennBr (Diskussion) 16:47, 3. Nov. 2020 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: Probleme treten nicht mehr auf. Grund, was das Problem aufgelöst und wieder beseitigt hat, sind nicht bekannt. LennBr (Diskussion) 22:36, 28. Nov. 2020 (CET)
Vor 10 Tagen gelöschte Vorlage immer noch im Artikel sichtbar?
Höh? de.wikipedia.org löst bei mir nach 91.198.174.192 auf. Gehst du direkt nach San Francisco, also 208.80.154.224 und nicht über Amsterdam? --Wurgl (Diskussion) 09:23, 4. Dez. 2020 (CET)
"Markierung: Visuelle Bearbeitung" in Recent Changes
Hallo. Vielleicht seh ich den Wald vor Bäumen nicht: Gibt es die Möglichkeit, in der RC-Liste die Links auf "Markierung: xy" (Screenshot) entweder auszublenden oder wenigstens zu entlinken? --Roger (Diskussion) 19:49, 21. Nov. 2020 (CET)
Gibt es auch eine einfache Möglichkeit, "Markierung: Visuelle Bearbeitung" durch eine kürzere Angabe, etwa: "M:VE" zu ersetzen? Ich weiß noch nicht, ob ich es einsetzen würde, aber vielleicht wäre das auch etwas für einen anderen hier möglicherweise Mitlesenden, denn manchmal entstehen nicht nachvollziehbare Änderungen durch Einsatz des VisualEditors. --Diwas (Diskussion) 05:11, 22. Nov. 2020 (CET)
:-D Das "Markierung" kann man auf die Art auch ändern, aber afaik auch nur mit Entfernen des Links (was ja erwünscht sein kann). --nenntmichruhigip (Diskussion) 13:54, 22. Nov. 2020 (CET)
Hallo,
habe die Seite "Tongrubengelände von Bensheim und Heppenheim" neu angelegt. Ein netter Kollege hat dann die Infobox ergänzt, die sich auch auf vielen weiteren Seiten findet.
Aber: der Link in der Info-Box zur Natura-2000ID "DE-63-17-305" führt auf allen diesen Seiten zu einem Fehler. Wie kann das korrigiert werden?
Zudem die Frage: wo gibt es Infos zur Nutzung der Infobox? Woher kommt z.B. der Eintrag Einrichtungsdatum 1988; das Naturschutzgebiet wurde 1977 eingerichtet.
Viele Grüße
Heinz-Vale (nicht signierter Beitrag vonHeinz-Vale (Diskussion | Beiträge) 09:44, 20. Apr. 2020 (CEST))
Hmm, auch seitens Andrew Bogott keine Reaktion; kann sonst jemand anders die Server des petscan clusters neu starten? Zuletzt hat das anscheinend ein User namens Krenair am 4.April gemacht, auch damals schon wegen Gateway-Timeouts . . .
Gibt es irgendwo einen offiziellen Weg, wo man auf einfache Weise (ohne allzu viel Ahnung von Systeminterna) ein Ticket wegen disfunktionaler Wikipedia Infrastruktur aufmachen kann? --Wikipeter-HH (Diskussion) 10:37, 29. Apr. 2020 (CEST)
PS: die Symptome (laut Monitoring) sind ziemlich klar. Der eine Server im Cluster (petscan4) dreht durchgehend auf 100%, während der andere fast durchgehend idle ist. Da scheint etwas mit dme Load-Balancing nicht zu klappen, oder ein User-Prozess ist in einer Loop und belegt den kompletten Server. --Wikipeter-HH (Diskussion) 10:43, 29. Apr. 2020 (CEST)
Zufälliger Artikel: Pinguin-Effekt Unangemeldet sehe ich links in der Leiste unter Werkzeuge den Link auf Wikidata: d:Q2095675 Angemeldet mit MonoBook ist nix zu sehen. MonoBook dem zusätzlichen Parameter ?useskin=Vector (alle, außer monobook zeigen den Wikidata-Link) zeigt den Link wieder an. Ist das nur bei mir so? --Wurgl (Diskussion) 06:41, 5. Jun. 2020 (CEST)
Danke, FriedhelmW, für Deine Antwort hier und den Service im Lemma. Genau so sollte es sein; die Navigation ist so bequemer. (Hatte es wohl nur vergessen und in den Anleitungen nicht mehr gefunden.) Gruß, --Wi-luc-ky (Diskussion) 14:47, 5. Sep. 2020 (CEST)
Anscheinend deaktiviert die Vorlage:TOC das automatische Inhaltsverzeichnis. Dann sollte das und die Lösung auch in die Vorlagendokumentation eingebracht werden. --Diwas (Diskussion) 00:28, 6. Sep. 2020 (CEST)
Gute Idee, Diwas, damit auch nachfolgende Benutzer/innen Nutzen daraus ziehen können. Es sollte sich also jemand, der/die die technischen Hintergründe kennt, daran machen, einen Satz in Vorlage:TOC zu ergänzen. Gruß, --Wi-luc-ky (Diskussion) 00:54, 6. Sep. 2020 (CEST)
In Hilfe:TeX gibt es die Empfehlung (genauer: die Verdonnerung)
<math>\text{für} oder \mbox{für}</math>
zu schreiben – mit dem bekannten äußerst hässlichen Ergebnis:
oder .
Dies wurde schon vielfältig beklagt, z.B. in mehreren Abschnitten in Hilfe_Diskussion:TeX sowie auf dieser Seite hier.
Diese Eingaben gehen mindestens bis ins Jahr 2014 zurück, sind also seit ≥ 6 Jahren überfällig.
Dabei gibt es Fonts wie den in cmunrm.pdf beschriebenen Font "Computer Modern Unicode Serif Roman", der das alles wunderbar draufhat.
Ist das alles viel komplizierter, als Otto Normalverbraucher sich das vorstellt, oder muss man an der WP-Demokratie schlichtweg verzweifeln ?? –Nomen4Omen (Diskussion) 11:25, 9. Sep. 2020 (CEST)
Nein, das weiß ich natürlich nicht. Ich weiß nur, dass es eine Lösung (einen Font) gibt. Implementieren, also den Aufruf etc. durchziehen, muss jemand von „Wikipedia:Technik/Werkstatt“.
Hallo Nomen4Omen, du hast dich bei obigem Task als "Assigned To" eingetragen. Das solltest du nur tun wenn du in der Lage bist das Problem zu lösen. Sonst hindert es evtl. andere daran sich zu kümmern. --FriedhelmW (Diskussion) 14:21, 10. Sep. 2020 (CEST)
@FriedhelmW: Ich bedanke mich sehr. Natürlich bin ich nicht der, der das dann macht. Ich finde die Sprechweise (assigned to? was geht das mich an? muss ich das mitkriegen?) und Schaltflächenangebote im phabricator extrem gewöhnungsbedürftig. Z.B. finde ich nicht mehr den Knopf zum Upload. Ich hoffe, dass dem "Physikerwelt" der eine Screenshot von MS edge reicht. An das cmunrm.pdf müsste er per Google selbst rankommen. (Ich hätte noch einen Screenshot davon und einen von MS IE11.) Auch sonst läuft so Vieles anders und wird anders dargestellt, als man es als Editor gewohnt ist. Zur Sache: Nach meinen Beobachtungen scheint die Darstellung dieser \mathrm-Umlaute vom Browser abzuhängen. Und habe keine Ahnung, wie sich das vom Portal aus beeinflussen lässt. Auf jeden Fall vielen Dank für deine Hilfe. Gruß, –Nomen4Omen (Diskussion) 16:26, 10. Sep. 2020 (CEST)
Hallo zusammen. Seit einiger Zeit wird in der als:Vorlage:Infobox Meerenge, die wir von der dewiki übernommen haben, eine Fehlermeldung bei den Koordinaten angezeigt, siehe z. B. im Artikel zur als:Beringstraße. Ich habe versucht, alle verwendeten Vorlagen aus den aktuellen Stand zu bringen, die Fehldermeldung ist aber geblieben. Mag sich das jemand mal anschauen, woher diese Fehlermeldung kommt? Vielen Dank. LG--Holder (Diskussion) 06:06, 16. Nov. 2020 (CET)
Bitte grundsätzlich damit an WD:GEO wenden, die haben die meiste Erfahrung mit Koordinaten und betreuen die beteiligten Vorlagen.
Diese Werkstatt hier hat ohnehin nichts mit Vorlagen und Seitenquelltext zu tun.
Banner wegen Servertest am 01.09.20 jetzt (03.09.20) z.T. immer noch sichtbar
Guten Morgen, das o.g. Banner ("Am Dienstag, dem 1. September, wird ab 16:00 Uhr MESZ das Bearbeiten der Wikipedia und ihrer Schwester-Projekte für bis zu eine Stunde lang nicht möglich sein. Hintergrund ist die Einrichtung eines zweiten Datenzentrums.") ist teilweise - nach jetzt fast zwei Tagen - immer noch bei manchen Artikeln sichtbar; z.B. bei Donald Trump oder auch Hilfe:Übersicht. Vielleicht lassen sich die Seiten ja zeitnah aktualisieren. Danke und VG --46.114.2.9106:00, 3. Sep. 2020 (CEST)
Fehlermeldung "Fehler bei der Kontaktaufnahme mit dem Parsoid-/RESTBase-Server (HTTP 400)"
Guten Tag, ich habe relativ lange an meiner neuen Seite "gebastelt" und wollte sie in meinem Benutzerkonto hochladen, um sie zu speichern. Es kommt die Fehlermeldung oben. Auch wenn ich auf "Quelltext bearbeiten" gehe, kommt die gleiche Meldung. Was kann ich tun, um nicht alles zu verlieren? Danke für die Hilfe! (nicht signierter Beitrag vonBwieBasel (Diskussion | Beiträge) 15:14, 19. Feb. 2020 (CET))
Hier schlug vorhin ein Problem auf, bei welchem Wikipedia zu einer Porno-Webseite verlinkte, weil die Vorlage die Adresse von Wikidata anzeigte, obwohl sie auf Wikidata als "deprecated" markiert ist. Ich hab da erst bemerkt, dass das Wikidata-Modul auch deprecated Werke zurück liefert und auch keine Option zum ändern davon anbietet. Als "hotfix" hab ich eine solches Argument eingebaut. Bevor ich das Argument dokumentiere, würde ich gerne diskutieren, ob wir die Logik nicht umdrehen sollten. Also Standardmäßig die 'deprecated' Werte nicht anzeigen und einen Parameter anbieten, wenn man das will.
Vorteile:
deprecated heißt immer, dass der Wert falsch und nicht mehr gültig ist, es wird daher praktisch nie in der Wikipedia gebraucht und ist meist unerwünscht.
Wir haben eine große Anzahl an Vorlagen die (nicht beabsichtigt) die Funktion ohne das Argument nutzen und potentiell falsche Werte anzeigen. Alle um einen Parameter zu ergänzen wäre sehr viel Arbeit.
Jetzt sind wir noch früh genug dran um es richtig zu machen und uns nicht noch-einen Klotz ans Bein binden.
Nachteile:
Restrisiko, dass das Modul irgendwo verwendet wird, wo deprecated Werte erwünscht sind und durch die Änderung etwas temporär kaputt geht.
Hallo! Apologies for writing in English. It would be appreciated if somebody could translate this message into German. We have noticed that the community of German-language Wikipedia is currently using technology that was deprecated 3 years ago that optimizes the main page for mobile users. This code will be removed in 1 months time and without any action the main page will look like this test link (notice the squished columns on a mobile screen). Given the importance of German-language Wikipedia we are keen to ensure that this project is not impacted. Luckily the fix for German-language Wikipedia is minimal. Instructions have been added to phab:T254287 which include an option that requires copying 1 line to the main page and creation of a single template(style). Please reach out to me if you have any questions either here or on Phabricator. Thank you! Jdlrobson (Diskussion) 20:58, 16. Jun. 2020 (CEST)
Ah, @Jdlrobson: just to make sure there won’t be a clash with our new mobile styling: will the Minerva pageHeading for the main page (Willkommen, USERNAME! when logged in) stay as it is or is it affected as well? I have no idea where that one is coming from. Best regards, XanonymusX (Diskussion) 00:59, 17. Jun. 2020 (CEST)
it will stay. that said I am not a fan of it and various projects have complained about it. I would support a phabricator ticket asking to remove it or at least asking for it to be configurable. Jdlrobson (Diskussion) 04:47, 17. Jun. 2020 (CEST)
I just wanted to check in here to see how I can help. The deadline is approaching (next week) and I noticed that the main page has still not been updated. I understand that these changes take time but is a short term solution being considered in the event that the more ambitious technical changes have not been completed? Thanks in advance for your answer. Jdlrobson (Diskussion) 19:08, 8. Jul. 2020 (CEST)
Bisher bin ich auf https://toolforge.org gegangen und dann gabs einen Menüpunkt um zu gucken, wie lange die Datenbank hintennach ist. Jetzt gibts die Seite nicht mehr, es geht nach wikitech :-(
Hintergrund:
MariaDB [dewiki_p]> select max(rev_timestamp) from revision;
+--------------------+
| max(rev_timestamp) |
+--------------------+
| 20200718202619 |
+--------------------+
1 row in set (0.00 sec)
Merci! Hab erst auf dem Weiterleitungsziel bei Wikitech gesucht und nix gefunden, danach hatte ich die Idee mit der Textsuche auf Wikitech und wurde fündig. Mir geht diese Seite ab, von dort gab es so einiges zu erreichen, zum Beispiel konnte man die Prozesse in der Cloud angucken, oder eine Übersicht über die Tools. Muss ich da jetzt für jeden Punkt ein Bookmark setzen? Vorher reichte mir die Übersichtsseite :-( --Wurgl (Diskussion) 10:01, 19. Jul. 2020 (CEST)
Wenn ich versuche, den Artikel Bloodywood zu speichern, erscheint folgende Fehlermeldung:
Fehler:
Achtung! Deine Änderung wurde nicht gespeichert.
Diese Aktion wurde automatisch als möglicherweise schädlich erkannt und deshalb nicht ausgeführt.
Kurzbeschreibung der verletzten Regel: „Im Moment keine Bearbeitungen durch un-/neuangemeldete Benutzer“
Für weitere Informationen oder wenn du Fragen hast, gehe bitte auf WP:Bearbeitungsfilter/306.
Das gleiche passierte letzte Nacht schon bei zwei Artikeln, die sich aber heute morgen wieder speichern ließen.
Der Filter war etwas zu scharf eingestellt, sollte nun behoben sein. Bitte bedanke dich bei denjenigen, die ursächlich für diese Maßnahmen sind. -- hgzh10:41, 20. Jul. 2020 (CEST)
Der Virtual Editor schreibt in den Quellcode beispielsweise statt des [[Tempel]]s immer des [[Tempel|Tempels]]. Kann man ihm das abgewöhnen? --bjs13:43, 20. Jul. 2020 (CEST)
Der Visual Editor hat da schon länger Probleme, vgl. u.a. phab:T39939 und phab:T128060 in dieser Stoßrichtung. Scheint nicht allzu hohe Priorität zu genießen (und der hier dargestellte Fall ist ja auch nicht soo schlimm). Gruß, -- hgzh15:58, 20. Jul. 2020 (CEST)
Ich habe aus der der deutschen Wikipedia mir mehrere Templates exportiert und diese dann in mein privates Wiki importiert. Alls Templates erzeugen folgende Fehlermeldung:
Die Vorlage:Dokumentation wird im Artikelnamensraum verwendet. Wahrscheinlich fehlt <onlyinclude> in einer eingebundenen Vorlage oder die Kapselung ist fehlerhaft. Bitte Vorlage:Bearbeiten.
Ich bin Anfänger hinsichtlich Mediawiki, aber trotzdem überrascht über die bereits erzielten Fortschritte, aber diese Fehlermeldung überfordert mich.
Hallo, die Vorlage:Dokumentation (also {{Dokumentation}} muss in einem <noinclude>-Block eingeschlossen sein, bzw. der Rest der Vorlage in einen onlyinclude-Block. Gruß, -- hgzh19:31, 13. Aug. 2020 (CEST)
Deine Adresse ist syntaktisch schon okay; geprüft würde Irgendwas@arcor.de daraufhin, ob es ein @ gibt (gibt es), ob danach eine syntaktisch korrekte Domain folgt (gibt es), ob in dem Zeugs davor keine verbotenen Zeichen oder Leerzeichen stünden (gibt es nicht).
Ich vermute, dass beim Copy&Paste irgendwelche unerlaubten unsichtbaren Zeichen davor oder dahinter hineingeraten sind. Leerzeichen drumrum müsste die Software eigentlich selbst entfernen; normalerweise ist die so schlau.
Einfach nochmal probieren, und insbesondere am Anfang und am Ende die Adresse nach dem Einkopieren nochmals mit händischen Buchstaben überschreiben.
Danke für die Tipps, aber die beschriebenen Probleme sind leider noch vorhanden.
Habe 2x die E-Mail-Adresse gelöscht (leeres Eingabefeld „freigegeben“), anschließend 1x die E-Mail-Adresse komplett händisch eingeben sowie 1x mittels Copy&Paste und, wie vorgeschlagen, Anfang und Ende jeweils einige Buchstaben überschrieben. Erhielt aber keinen „Bestätigungscode per E-Mail“.
Hallo
Ich komme kurz nach meiner letzten technischen Anfrage, zu einem neuen/nicht-verwandten Anliegen. Ich war vor kurzem in einen Edit-War verwickelt, bei dem ich strittige Meldungen in der Nachrichtenbox auf der Hauptseite revertierte und dafür für wenige Stunden gesperrt wurde. In der Sperrzeit habe ich keinen Entsperrwunsch eingereicht (u.a. weil ich keine Zugriffsrechte, weder auf meine Benutzerseite, noch auf Wikipedia:Entsperrwünsche (nachtrag: gemeint ist eigtl. Wikipedia:Sperrprüfung) hatte...Von der Möglichkeit einer E-Mail-Anfrage habe ich in dann gestern Abend keinen gebrauch mehr gemacht. Wie dem auch sei; ich beabsichtige, die Löschung des Sperreintrags einzufordern...Möchte aber mit dieser Anfrage sicher sein, dass dies auch technisch umgesetzt werden kann. --LennBr (Diskussion) 18:05, 19. Sep. 2020 (CEST)
Technisch ist das sowohl eine Versionslöschung des Logeintrags (dann können nur noch Admins den Sperrlogeintrag lesen) als auch eine Unterdrückung per Oversight (dann können nur noch Oversighter den Eintrag lesen) möglich. Beides wird hier aber nicht zur Anwendung kommen, da die Voraussetzungen für ein Oversighting oder eine Versionslöschung nicht vorliegen. Allenfalls könntest du einen 0-Sekunden-Sperrlogeintrag erreichen, in dem erklärt wird, dass die Sperre nicht korrekt war. --Count Count (Diskussion) 18:17, 19. Sep. 2020 (CEST)
Das Schreibrecht auf deiner Benutzerdisku wurde dir nicht entzogen, du hättest dort den sperrenden Admin (oder einen anderen) anpingen können und um Sperrprüfung bitten können. Gruß --Schniggendiller Diskussion 18:31, 19. Sep. 2020 (CEST)
Danke soweit an Count Count für die Beantwortung. Ich konnte während der Sperrzeit meine Benutzerseite nicht bearbeiten. Ich habe es mehrmals versucht: dabei kam jedes mal der Hinweis, dass mein Konto gesperrt sei. --LennBr (Diskussion) 18:35, 19. Sep. 2020 (CEST)
Aus dem Sperrlogeintrag geht hervor, dass du deine eigene Benutzerdiskussionsseite hättest bearbeiten können. Das ist die Standardeinstellung beim Sperren. Das Verbot, die eigene Benutzerdiskussionsseite zu bearbeiten, muss man dagegen als Parameter beim Sperren extra anwählen und dann würde im Sperrlogeintrag „darf eigene Diskussionsseite nicht bearbeiten" stehen. --Count Count (Diskussion) 19:08, 19. Sep. 2020 (CEST)
Danke an dieser Stelle für die Fettmarkierung und Klarstellung. Die Benuterdiskussionsseite zu bearbeiten, die ja für den Entsperrwunsch eigentlich vorgesehen ist, habe ich nicht versucht. --LennBr (Diskussion) 19:25, 19. Sep. 2020 (CEST)
Hier sollte erst einmal geklärt werden, ob die Sperre unberechtigt war. Ist das der Fall, kann der User durchaus verlangen, dass der Eintrag nicht mehr für jeden sichtbar ist. ÅñŧóñŜûŝî(Ð)01:17, 20. Sep. 2020 (CEST)
"Gadgets aufräumen und modernisieren" als Wunsch an das Projekt Technische Wünsche?
Nach der berechtigten Tirade von PerfektesChaos auf der Kurier-Disk zum Zustand vieler Gadgets hat Benutzer:Aschmidt in der MP-Disk vorgeschlagen, das Sichten, Aufräumen und Modernisieren dieser Gadgets als Wunsch an das Projekt Technische Wünsche heranzutragen. Nun bin ich leider viel zu weit weg von der Technik hier, um beurteilen zu können, ob das eine gute Idee wäre. Deshalb meine Frage an dieser Stelle: Wäre so ein Projekt sinnvoll, und hätte es Aussicht auf Erfolg? --Tkarcher (Diskussion) 20:37, 2. Okt. 2020 (CEST)
Nein, das ist absolut keine umsetzbare Idee.
Das Management der eigenen Gadgets ist eine Community-Aufgabe der deWP und bedarf weitreichender Insider-Kenntnisse.
WMDE setzt externe Entwickler dran, und die benötigen eine ganz exakte Aufgabenstellung und Funktionsbeschreibung, und könnten damit genau ein einzelnes Gadget umschreiben oder sonstwas. Aber sie können nicht die Aufgabenstellung (den „Kundenwunsch“) entwickeln, geschweige denn als Externe den hiesigen Gadgetbestand irgendwie weiterentwickeln und pflegen, grad so wie es die hiesige Community brauchen würde.
WMDE entwickelt außerdem Werkzeuge, die potenziell auf allen Wikis der WMF einsetzbar wären.
Wie überfordert WMDE schon damit ist, zeigt sich derzeit am jämmerlichen Debakel um die automatisierte Lösung der Bearbeitungskonflikte, die zwangsweise allen IP aufgedrückt wurde und wird. Hier hatte man als Externe grundlegende Kenntnisse nicht gehabt, nämlich dass BK am häufigsten in Diskussionen um aktuelle Angelegenheiten auftreten werden, jedoch nur für triviale kleine Änderungen an Artikeln programmiert und erprobt. Bis heute funktioniert das nicht brauchbar, wurde aber viel zu früh als angeblich erfolgreich gelöst verkündet und zwangsweise als Standardeinstellung konfiguriert, wo IP nicht mal entrinnen können.
Bevor man eine solche Aufgabe delegieren kann, muss ganz exakt erarbeitet werden, was man eigentlich haben will. „Die sollen das da mal für uns irgendwie hinbringen“ ist keine durch Außenstehende lösbare Aufgabe.
Ein „Sichten und Aufräumen“ ist gleich gar nicht an Externe delegierbar, denn das ist ja gerade die Zielvorstellung der Community, die sie zuvor selbst erarbeiten müsste. Und „Aufräumen“ heißt Gadgets abschalten und nicht mehr anbieten, und das gibt vorhersehbar jeweils einen Sh-Proteststurm. Wofür es auch keinen Anlass gäbe, denn das was Community-Gadget ist wurde bereits (fast durchgängig durch mich) modernisiert, oder es ist bekannt wodurch es zu ersetzen wäre, oder wird irgendwann unrettbar eingehen; ist aber bis dahin mindestens auf dem Stand von 2011. Der Zustand aller Community-Gadgets und deren Prognose ist zumindest mir sehr exakt bekannt.
Jemand der nicht selbst mit einem Tool/Gadget/Helferlein arbeitet oder wenigstens mit der vom Tool/Gadget/Helferlein abgedeckten Problematik vertraut ist, wird nix Sinnvolles auf die Reihe bekommen. Und mit einer ganzen Palette von Tools sind Leute von außerhalb einfach restlos überfordert. --Wurgl (Diskussion) 16:47, 9. Okt. 2020 (CEST)
CSS-Bug mit dem rechten Reiter (Lesen|Bearbeiten|Quelltext bearbeiten|Versionsgeschichte)und schmaler Bildschirmbreite
Wenn man den Browser schmalzieht und dabei die rechten und linken Reiter über dem Artikel sich überlappen würden wippt der rechte Reiter wenn man knapp am Umbruchgrenzwert ist zwischen seiner angestammten Position und der Zeile darunter hin und her. Da scheint das responsivdesign zwischen zwei Zuständen hinundherzuspringen statt die Optionen ins "Weitere-Menü" zu verschieben. Der Bug tritt nur auf wenn man den Reiter mit "Quelltext bearbeiten" auch angezeigt bekommt. Mit nur 3 Punkten funktioniert das Umschalten zuverlässig.
Ja, das ist ein bekanntes Problem. Das wird sich wohl früher oder später mit der generellen Überarbeitung des Vector-Skins lösen, gezielt an dem Problem gearbeitet wird leider nicht.—XanonymusX (Diskussion) 14:34, 22. Okt. 2020 (CEST)
Hallo, wo kann ich mich über Richtlinien bzw. Limits informieren wenn ich mit selbstgebauten externen Werkzeugen automatisiert auf die Wikipedia zugreifen möchte. Konkret denke dabei an Beschränkung hinsichtlich html-requestst, könnte mir allerdings vorstellen, dass es weitere Punkte zu beachten gibt. Danke und Gruß --Mrmw (Diskussion) 16:46, 5. Nov. 2020 (CET)
Es sind Mechanismen eingebaut, die erkennen und drosseln, wenn etwa alle Zehntelsekunde jemand Seiten aus einem Wiki absaugt; zumindest anonym und ohne besondere Rechte.
Insofern sollte im Sinne der bereits genannten Etiquette eine Drossel eingebaut werden, die nur alle 10 bis 30 Sekunden eine Seite liest; also wie ein eifriger Mensch halt auch.
Konkrete Zahlenangaben sind hier kaum möglich, weil permanent daran justiert wird und auch die Erkennung nur durch Zufall passiert. Anonyme Lese-Anfragen laufen auf eigenen Rechenzenten auf, das für uns zuständige stand zumindest mal in Amsterdam. Dort gibt es Hunderte von Servern, die Lese-Anfragen zu allen Wikis beantworten. Über einige Lastverteilungs-Knoten (Server) sind die alle mit dem Internet verbunden. Vom selben Provider wird man vermutlich aber nicht immer auf denselben Eingangs-Server geleitet, der mit dem nächsten freien Beantwortungs-Server verbindet. Der Knoten notiert sich, welche IP-Adressen ihn in den letzten vielleicht 500 Sekunden gefragt hatten und wie oft, und wenn ihm das zuviel wird oder relativ zur momentanen Systemauslastung überkocht dann werden Anfragen mit Fehlermeldung abgewiesen.
Dancing Vector tabs Und der Bildschirm muss schmal sein. Hier auf einem hochkant gestellten iPad. Kommt mir bekannt vor, hatten wir das nicht vor ein paar Monaten schon mal? --MBqDisk07:37, 25. Okt. 2020 (CET)
Guten Tag! Im Portal:Baptisten (rechte Spalte, ziemlich oben) gibt es eine sogenannte Zufallsmaschine, über die man sich einen zufälligen Artikel im Themenfeld Baptisten zeigen lassen kann. Leider funktioniert der Link nicht mehr; klickt man ihn an, erscheint der Hinweis Fatal error .... Woran liegt's? MfG, GregorHelms (Diskussion) 10:34, 18. Dez. 2020 (CET)
Bei Verschiebungen von Artikeln wird (auf Wunsch) die Artikeldisk mitverschoben. Wie ich bei Leopold von Plessen (Minister) festgestellt habe, gilt das aber nicht für Archive der Diskussionsseite. Kann man das ändern, dass auch die Archive mitverschoben werden?--Karsten11 (Diskussion) 11:59, 18. Dez. 2020 (CET)
@ Leyo: Als Admin sehe ich die Option, sie ist sogar vorausgewählt. Für Normalbenutzer scheint sie aber nicht zu existieren. -- Perrak (Disk) 17:32, 18. Dez. 2020 (CET)
Hm, allenfalls wäre es sinnvoll, wenn dies für Sichter geändert würde. Oder aber, dass es irgendwie geloggt würde. --Leyo19:08, 18. Dez. 2020 (CET)
+1. Wenn das als zu risikoreich betrachtet wird, wäre für Nicht-Rechte-Inhaber ein Warnhinweis "Für diese Seite gibt es Unterseiten. Verschiebe diese ebenfalls oder wende Dich an WP:VSW"--Karsten11 (Diskussion) 20:09, 18. Dez. 2020 (CET)
Könnte man machen. Aber warum? Gibt es Fälle, wo eine Diskussionsseite Unterseiten hat, die keine Archivseiten sind, wo die Verschiebung also unerwünscht wäre? Wenn es Probleme mit Verschiebevandalismus gibt, wäre es eher sinnvoll, die Schwelle zur Erlangung des Verschieberechts anzuheben, denke ich.
Loggen und fürs erste ein Warnhinweis an Leute, die das Recht nicht haben, wären natürlich allemal sinnvoll. -- Perrak (Disk) 11:25, 20. Dez. 2020 (CET)
auf COVID-19-Pandemie in Österreich ist es in den letzten Wochen immer wieder zu der genannten Fehlermeldung gekommen. Dann werden ein paar Diagramme mit Vorlage:Graph:Chart rausgenommen und das Problem ist erstmal gelöst. Jedoch ist das Verhalten doch etwas merkwürdig:
Nach Bearbeitung wird zum falschen Anker gesprungen
Servus!
Wenn man einen Artikel bearbeitet und dann speichert, springt Mediawiki ja immer auf diese Überschrift. Wenn man jedoch mehrere gleich benannte Überschriften hat, dann springt Mediawiki immer auf die erste Überschrift.
Hui, fast 14 Jahre schon. Soweit bin ich bei meiner Fehlersuche nicht zurück gegangen. Also kann man wohl nicht auf eine zeitnahe Behebung hoffen. Noch eine Folgefrage: Wäre der Fehler grundsätzlich schwer zu korrigieren? Also würde es sich lohnen, wegen einem kleinen Problem kurz in die Mediawiki-Programmierung einzusteigen? --37.251.226.21420:25, 19. Jan. 2020 (CET)
Extrem mühsam.
Das Grundproblem ist, dass HTML zum ersten Anker mit dieser id= springt.
MediaWiki vergibt deshalb bei gleichlautenden Überschriften eine interne Zählung; hängt also _2_3 usw. oder so ähnlich dran, bis alle Überschriften eindeutige id= zugewiesen bekamen.
Damit kann MediaWiki in der momentanen Textversion die Verlinkungen zwischen Inhaltsverzeichnis und Überschriften sicherstellen.
Wenn jedoch ein Abschnitt bearbeitet wird, dann ist das section=42 und der weiß nicht welche interne Zählung seine Überschrift im Gesamt-Dokument erhielt.
Der Mechanismus, der aus Überschriften das Inhaltsverzeichnis generiert, befindet sich jedoch an einer völlig anderen Stelle als der Abspeicherungsvorgang; der verwendet seine jetzt generierte und vielleicht veränderte Abschnittsüberschrift zur Verlinkung.
In dem Moment, in dem die Abspeicherung vorgenommen wird, wird bereits die Verlinkung auf das spätere Gesamt-Dokument als URL gebildet; das spätere Gesamt-Dokument mit seiner möglicherweise veränderten internen Zählung ist aber noch nicht bekannt, weil der neue Text noch nicht Teil des Gesamt-Dokuments ist, und das wird erst generiert, nachdem die Textbearbeitung abgeschlossen wurde, die deshalb nicht wissen kann, wo zu diesem Zeitpunkt der ursprüngliche section=42 hingekommen ist und welche id= diesem jetzt zuzuordnen wäre. Wobei sogar andere Abschnitte parallel von anderen bearbeitet werden dürfen.
Die neue Zählung mit Inhaltsverzeichnis wird erst dadurch generiert, dass der abspeichernde Benutzer die URL aufruft, um die veränderte Seite angezeigt zu bekommen. Dabei verwendet die URL das, was sie weiß, nämlich die möglicherweise veränderte Abschnittsüberschrift. Dadurch, dass eine Anfrage-URL den Server erreicht, diese Seite anzuzeigen, wird der Prozess angestoßen, der die neue Seite generiert und das Inhaltsverzeichnis generiert. Erst danach wäre die aktuelle _2_3 usw. bekannt.
Da wird sich deshalb auch keiner auf die Socken machen wollen.
Nicht wirklich eine Frage, aber hat schonmal jemand darüber nachgedacht, diese überlange seite zu Archivieren? Ich habe per Suchfunktion gesehen, dass bereits Archive existieren, deswegen frage ich. Victor SchmidtWas auf dem Herzen?18:47, 25. Apr. 2020 (CEST)
Dabei wird es sich um eine nicht spontan lösbare Folge eines 2006 zusammengepfuschten Hack von handeln, der seit vielen Jahren als hochproblematisch bekannt ist.
Man hatte damals naiv und blauäugig gedacht, dass es die damaligen Skins auf ewige Zeiten und nur diese und immer genauso geben würde. Also hatte man dort ein leeres Plätzchen ausgeguckt, und beamt über die vermutlich freie Stelle obendrüber die von dir benannten Beschriftungen, ohne dabei wissen können, ob der Platz dort tatsächlich frei wäre, und sich mit anderen Elementen koordinieren zu können.
Jetzt stehen da also zweie. Naja, müssten die Leutchen mit dem Artikel sich halt koordinieren, welche von beiden dargestellt werden solle; die wissen nix voneinander.
Zur grundsätzlichen Lösung wende dich bitte an WD:GEO.
Very sorry about writing in English. I hope somebody can translate this. Thanks in advance.
There's a new proposal to localize Lua modules in a more modern, safe, and convenient manner: mw:Translatable modules. In the foreseeable future it will only affect multilingual sites, such as Wikidata, Commons, Meta, and mediawiki.org, but at a later time it may also be deployed on Wikipedias and other projects.
(Status: ohne VE, MonoBook, FireFox 82.0, Windows 8.1, WSTM geladen)
Ich bekomme seit paar Tagen beim Bearbeiten im Quelltextmodus nach der ersten Vorschau immer zuoberst die folgende Anzeige:
Dies ist nur eine [[Hilfe:Seite bearbeiten#Vorschau und Speichern|Vorschau]], {{#switch: {{NAMESPACEE}} | =der Artikel | #default=die Seite }} wurde noch nicht gespeichert! → Zum Bearbeitungsfeld gehen
Unter dem Quelltextfenster steht zu den Vorlagen:
{{PLURAL:{{{1|$1}}}|Die folgende [[Hilfe:Vorlagen|Vorlage]] wird|Folgende [[Hilfe:Vorlagen|Vorlagen]] werden}} von dieser {{#ifeq:{{NAMESPACE}}|{{ns:0}}|Artikelvorschau|Seitenvorschau}} verwendet:
Kann ich nicht nachstellen, im Vector ist es bei mir ok und ein Test mit MonoBook ergab auch keine Probleme. Du sagst ja „immer“. Ist das nur bei der ersten Vorschau? Ich habe ebenfalls Firefox und Windows 10. Hast du irgendwelche anderen Tools (Helferlein, Betafunktionen) aktiviert, etwas mit Syntaxhervorhebung beispielsweise? --Liebe Grüße, LómelindeDiskussion18:22, 22. Okt. 2020 (CEST)
Die Anzeige geht bei wiederholten Vorschauen nicht weg. So richtig ist mir das erst in den letzten Tagen aufgefallen; ich dachte, es wäre vielleicht ein Zwischenstadium bei WP-Software-Updates.
Beta-Funktionen habe ich keine aktiviert, auch keine Syntaxhervorhebung.
Mehrere Helferlein sind aktiviert. Ich habe erst einige, dann alle unter "Bearbeitungswerkzeuge" deaktiviert und eine BKS mit Strg+F5 neu vom Server geladen, dann "Seite bearbeiten" → "Vorschau zeigen": immer kommen die beiden Code-Anzeigen.
Jupp, auch bei mir: Monobook, kein VE, "Vorschau ohne Neuladen der Seite anzeigen" & "Vorschau oberhalb des Bearbeitungsfensters anzeigen" aktiviert, Betafunktionen: Videoplayer, Helferlein: Zusätzlicher Karteireiter für ext. Werkzeuge + Vorlagen-Meister + HotCat + Einleitungshelfer + BKL-Check + Wildcardbenutzer-Beiträge + Sonderzeichen + Extra-Editbutton + Revisionjumper + Einblenden Metadaten + WikiminiAtlas + OpenSteetMap + PrettyLog + Revision-Counter + markAdmins + Verschiebeformular + Überspringen lokaler Dateibescheibung + Versionsunterschiede in bisherigen Farben + Fußnoten-Tooltip, Browser/OS: Chrome (gerade 86.0.4240.111) unter Debian testing (Linux 5.9.0-1-amd64). Das rendern passiert aber doch ohnehin serverseitig? --StYxXx⊗23:26, 4. Nov. 2020 (CET)
Also das taucht bei mir auch total random auf, mal ja, mal nein. Wird aber wohl Serverseitig sein, weil wenn ich das ganze mit safemode=yes (deaktiviert Benutzerseitigen Skripte) mache, dann kommt das auch. VG, Luke08151523:42, 4. Nov. 2020 (CET)
Da hilft nur eines: Wenn der Fehler auftritt: --> OFFLINE-Modus, dann den Quelltext anstarren (Ctrl-U bei Firefox). Ganz am Ende steht dann "{"origin":"mw1324","timestamp":"20201104164917", …" dieses "mw1324" ist wohl der Server.
OFFLINE-Modus, weil beim Angucken vom Quellcode wird der sonst neu geladen und man sieht das Ergebnis eines anderen Servers. --Wurgl (Diskussion) 23:54, 4. Nov. 2020 (CET)
Sir Gawain Disk. 17:23, 12. Jan. 2020 (CET)
) 01:37, 3. Apr. 2020 (CEST)
aus. Geduld. --PerfektesChaos 15:09, 2. Mai 2020 (CEST)
Liebe Grüße, – Doc Taxon • Disk. • 17:42, 7. Sep. 2020 (CEST)
RikVII. my2cts 20:27, 16. Okt. 2020 (CEST)
--FriedhelmW (Diskussion) 14:07, 22. Nov. 2020 (CET)
13:43, 20. Jul. 2020 (CEST)
