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
Letzter Kommentar: vor 2 Jahren31 Kommentare10 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 4 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
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
Letzter Kommentar: vor 4 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
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))
Letzter Kommentar: vor 4 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 4 Jahren10 Kommentare3 Personen sind an der Diskussion beteiligt
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
Letzter Kommentar: vor 4 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 4 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
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.
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Sorry to use English. Hilf bitte mit, in deine Sprache zu übersetzen.
This is a reminder of the message sent on Monday 27th April.
A maintenance operation will be performed on Thursday 30th April at 05:00 AM UTC.
It impacts all wikis and is supposed to last a few minutes.
During this time, new translations may fail, and Notifications may not be delivered. 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.
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
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.
Letzter Kommentar: vor 4 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
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)
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:
Letzter Kommentar: vor 4 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 4 Jahren14 Kommentare3 Personen sind an der Diskussion beteiligt
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.
Letzter Kommentar: vor 4 Jahren5 Kommentare4 Personen sind an der Diskussion beteiligt
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.
Letzter Kommentar: vor 4 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 4 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
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:
Letzter Kommentar: vor 4 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
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
Letzter Kommentar: vor 4 Jahren9 Kommentare3 Personen sind an der Diskussion beteiligt
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
Letzter Kommentar: vor 4 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 4 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 4 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 4 Jahren7 Kommentare4 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 4 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
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?
Letzter Kommentar: vor 4 Jahren10 Kommentare3 Personen sind an der Diskussion beteiligt
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
Letzter Kommentar: vor 3 Jahren11 Kommentare5 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 3 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 3 Jahren7 Kommentare4 Personen sind an der Diskussion beteiligt
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
Letzter Kommentar: vor 3 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
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)"
Letzter Kommentar: vor 3 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
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))
Letzter Kommentar: vor 3 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
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.
Letzter Kommentar: vor 3 Jahren8 Kommentare4 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 3 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 3 Jahren5 Kommentare5 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 3 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 3 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
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“.
Letzter Kommentar: vor 3 Jahren8 Kommentare5 Personen sind an der Diskussion beteiligt
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?
Letzter Kommentar: vor 3 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
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)
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)
Letzter Kommentar: vor 3 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 2 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 2 Jahren8 Kommentare4 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 2 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo,
auf COVID-19-Pandemie in Österreich ist es in den letzten Wochen immer wieder zu der genannten Fehlermeldung gekommen. Dann werden ein paar Diagramme mit Vorlage:Graph:Chart rausgenommen und das Problem ist erstmal gelöst. Jedoch ist das Verhalten doch etwas merkwürdig:
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.
Letzter Kommentar: vor 1 Jahr3 Kommentare3 Personen sind an der Diskussion beteiligt
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.
Letzter Kommentar: vor 1 Jahr2 Kommentare2 Personen sind an der Diskussion beteiligt
Hi,
Very sorry about writing in English. I hope somebody can translate this. Thanks in advance.
There's a new proposal to localize Lua modules in a more modern, safe, and convenient manner: mw:Translatable modules. In the foreseeable future it will only affect multilingual sites, such as Wikidata, Commons, Meta, and mediawiki.org, but at a later time it may also be deployed on Wikipedias and other projects.
Letzter Kommentar: vor 1 Jahr9 Kommentare6 Personen sind an der Diskussion beteiligt
(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)
Letzter Kommentar: vor 7 Monaten3 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo, es scheint, daß in letzter Zeit kleingeschriebene Wörter bei der Suche nach Lemmata nicht mehr gefunden werden. Ging mir (der ich manchmal aus Bequemlichkeitsgründen klein schreibe) manchmal so. Konkret soeben: "kerstin hensel" führte mehrfach auf "Seite nicht vorhanden". "Kerstin Hensel" wurde gefunden.--217.70.135.6006:51, 3. Feb. 2020 (CET)
Letzter Kommentar: vor 7 Monaten3 Kommentare3 Personen sind an der Diskussion beteiligt
Verehrte Redaktion,
ich möchte auf der Seite https://de.wikipedia.org/wiki/Liste_der_ungerichteten_Funkfeuer_(NDBs) die aufgeführte Liste als PDF-Datei speichen/drucken in der Sortierung nach Frequenz. Wenn ich es versuche, wird immer wieder die Sortierung ignoriert und die Liste wird in der "Urform" nach Rufzeichen sortiert dargestellt.
Wie kann ich die Sortierung dauerhaft für den PDF-Ausdruck übernehmen?
Welchen Browser benutzten sie? Wenn sie Firefox benutzen, ist es warscheinlich am einfachsten, Firefox Screenshots zu benutzen. (Die Drei Punkte in der Adressleiste -> Bildchirmfoto aufnehmen und dann dasa Bild auszudrucken. Wie das in anderen Browsern aussieht, weiß ich leider nicht. Victor SchmidtWas auf dem Herzen?08:00, 6. Feb. 2020 (CET)
Ohne die E-Mail gesehen zu haben, würde ich sagen, das ist ein Problem des entsprechenden E-Mail-Programms. Ich selber habe im Outlook oft das umgekehrte Problem, nämlich, dass der Punkt am Ende des Satzes noch als Teil des Links interpretiert wird, den ich angegeben habe. Mein Workaround ist dann immer ein Leerzeichen vor dem Punkt zu machen. Ich kann mir gut vorstellen, dass Thunderbird genau diese Problematik bekannt ist und sie deswegen Punkte am Ende von Links grundsätzlich entfernen. DestinyFound (Diskussion) 11:50, 16. Feb. 2020 (CET)
Das ist ein teuflisches Dilemma. Sowas in der Art passiert auch mit schließender Klammer am Ende. Lösungsmöglichkeit wäre: HTML-formatierte Mail … kann sein, dass der Benutzer dann auch die Mail im HTML-Format angucken muss, was bei so manchem Mail-Client ein Einfallstor für tolle Windows-Verbesserungsprogramme (Viren, Trojaner, etc.) sein könnte oder Prozentkodierung verwenden. --Wurgl (Diskussion) 12:11, 16. Feb. 2020 (CET)
Letzter Kommentar: vor 7 Monaten5 Kommentare5 Personen sind an der Diskussion beteiligt
Ich spioniere gerne mal bei meinen Edits in anderssprachigen Wikis um dort nach Referenzen für Unterschiede zu suchen. Solange ich den Artikel selbst anstarre, sehe ich die Interwikilinks, aber beim bearbeiten der Seite ist diese Liste leer (egal ob Quelltext- oder Visual Editor). Kann man die nicht auch beim Bearbeiten anzeigen? --Wurgl (Diskussion) 11:38, 16. Feb. 2020 (CET)
In der Diff-Ansicht wird ausschließlich der Unterschied zwischen dem alten und dem neuen Quelltext dargestellt.
Heißt: Beim Vergleich gibt es auch keine Kategorien und Vorlageneinbindungen und Verknüpfungen mit Wikidata und was auch immer.
Was der Quelltext bedeuten soll wird nicht untersucht.
Das hat Performance-Gründe, und wird wohl auch niemand anfassen wollen.
Das gilt genauso für die Erstbearbeitung&action=edit wenn per Benutzereinstellung auf nacktes kurzes Anzeigen konfiguriert.
Im Vorschau-Modus erfolgt ein komplettes Rendering des neuen Textes. Hier werden neue Kategorien den bisherigen hinzugefügt, die jetzt aktuellen Vorlageneinbindungen usw. angezeigt, und auch die Interlanguages sind die bisherigen zuzüglich solcher die durch geänderten Quelltext hinzugekommen sein werden gehättet gesollt.
Letzter Kommentar: vor 7 Monaten2 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo, viellleicht wisst ihr das (auf FZW erfolglos): ich bereite gerade eine Umfrage Wikipedia:Umfragen/Zukunft des Sichtens vor und will die mit einer gründlichen Analyse vorbereiten. In dem Zusammenhang hab ich die Frage, ob man vom linken Seitenmenue "intelligent" verlinken kann.
Also zB. ein Menuepunkt "Sichten", der für Sichter und Nichtsichter jeweils eine andere Seite aufruft (also abhängig von den Benutzergruppen). Das gäbe die Möglichkeit, Nichtsichtern das einfach zu erklären - Sichtern die Statistiken und Werkzeuge anzuzeigen. Danke. --Brainswiffer (Disk) SICHTET!12:54, 2. Mär. 2020 (CET)
Letzter Kommentar: vor 2 Monaten4 Kommentare2 Personen sind an der Diskussion beteiligt
I have connected 160 000 objects/creators in Europeana to Wikidata see T240290. I think this can be useful also on de:Wikipedia to have an template using this information see T241677
First, it is great that you ask first and not start to implement something in an unknown environment, with local policies over a dozen years possibly violated.
Second, you are not exactly right in this maintenance area, but that is nothing you are supposed to know.
Please drop this issue again at our partner maintenance area, which is focussing on templates: WP:VWS.
The current maintenance area (WP:TWS) is also dealing with technical issues, but more things like browser, JavaScript gadgets, MediaWiki API queries, server access.
Just to get the right audience and archive.
One will execute implementation and documentation there according to your desires.
You might refer to this section.
Third, to give an assessment in advance:
Basically it is no problem to have a template which is wrapping an external link to anything.
However, we made the experience with academic registers that they are often not exciting. That will say: They do not tell anything more than a person with this name is registered at this number.
To insert such template into encyclopedic articles about a person we do expect that the external link is providing additional value: either biographic details (CV) or exhaustive publication list.
If the template is providing access to contents, e.g. book scan, photographs etc. it is most welcome. Metadata alone might be a problem; a painting might have a height of 60 centimetres and 40 centimetres width, but that is not challenging if no image is visible.
Basically we prefer to insert registration identifiers hard-coded into our article sources, since this is a reviewing wiki and every change of data needs review of experienced users. That is sufficiently preventing vandalism, which might happen easily and unobserved on Wikidata.
For the time being if there is no checked ID we can use Wikidata entry as fallback.
@PerfektesChaos: Thanks I will do. I see Europeana as museums Wikicommons were museums can upload material and also group them per creator. If the museums do a good work we in Wikipedia just need to link the Europeana creator id (agent same as Wikidata Qnumber e.g. Wikidata entity Q44007 same as "agent/base/60816") and not every museum PLUS the museums by uploading to Europeana easier get found. What I see is that the quality differ I guess per country and as we in Wikipedia tries to understand Wikidata museums/archives has just started this learning and I hope Wikipedia <-> Wikidata <-> Europeana can learn from each other to make cultural information easier to access see complains oin Europeana at en:Wikipedia link
Hardcoded id or Wikidata
The interesting thing with Europeana is that they have started to use Entities link (same as Wikidata Qnumber) and to get starting they used dbpedia as a source and dbpedia use Wikidata as a source i.e. we are always correct as they use same as Wikidata. I see this as a biproduct that the Wikiproject is moving in the right direction of quality, trust and technology.... If we find an error then the error is in Europeana that has matched an object to the wrong creator. I have written down my experience of this and advice Europeana to get better change management see GLAM/Newsletter/December 2019 - Europeana Entity P7704 - Salgo60 (Diskussion) 13:49, 6. Jan. 2020 (CET)
Wenn innerhalb von <ref> … </ref> ein HTML-Kommentar <!-- begonnen, aber nicht abgeschlossen wird, dann sind zwar im Fließtext die Referenzen brav mit [123] markiert und auch anklickbar, aber im entsprechenden <references />-Abschnitt fehlen sie. Beim Artikel Wachsblumen (Hoya) war das ganz extrem, nur 34 der 76 Einzelnachweise waren im Artikel aufgeführt.
Die Syntax ist mehrdeutig, und es ist pure Glückssache, wie welche Version des Parsers dies interpretiert.
Die ref-Extension geht ohnehin eigene Wege und interpretiert den Wikitext, den sie abbekommt, nur begrenzt und als abgeschlossene Einheit.
Je nachdem ob eine Parserversion zu einem anhängigen <ref> nun zu allererst das schließende </ref> sucht oder aber nach einem anhängigen geöffneten Kommentar das Ende des Kommentars sucht passiert mal dies, mal jenes.
Das ist der Grund, warum seit drei Jahren der Linter läuft und fehlerhafte Verschachtelungen aufzuspüren versucht. Muss man halt eindeutig notieren.
Linter befasst sich allerdings mit inhaltlichen Elementen, also benannten Tags; eher wäre fehlerhaftes Nesting mit Kommentaren ein neues Feld für Linter.
Das prinzipielle Problem ist jedoch uralt und keine Neuigkeit.
Die Fehler kommen bei meiner Liste raus, zwar nicht unbedingt als Verschachtelungsfehler, aber ich finde die. Muss ja nicht doppelt gemoppelt werden. War nur die Frage, ob schon Phab-Eintrag oder nicht. Bzw, jetzt offenbar: Einfach ignorieren. --Wurgl (Diskussion) 13:52, 8. Mai 2020 (CEST)
Letzter Kommentar: vor 2 Monaten3 Kommentare2 Personen sind an der Diskussion beteiligt
Es gibt (unter MonoBook im Firefox auf PC) zu kleine Zeilenabstände von Vorlagen, wenn sie direkt oder nach einer Leerzeile unter einer Aufzählung stehen:
Sieht rangequetscht aus (vergleiche Beispiel), das betrifft auch das Inhaltsverzeichnis, wenn die Artikeleinleitung mit einer Aufzählung endet (altes Beispiel).
Lässt sich dahingehend etwas an der Standard-CSS nachjustieren? Gruß --Chiananda (Diskussion) 17:52, 22. Jun. 2020 (CEST)
Hier ein ähnlicher Abstandsfehler in der Darstellung in der mobilen Ansicht (MonoBook im Firefox auf PC):
Drache (BKS) enthält absichtlich eine Leerzeile vor dem 5. Eintrag (Lokomotive), um einen kleinen Abstand zu erzeugen.
In der mobilen Ansicht steht die Lokomotive näher am vorhergehenden Eintrag dran.
Navigationsleisten und Kategorienleisten anpassbar, im Falle einer Änderung der Benutzeroberfläche?
Letzter Kommentar: vor 2 Monaten4 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo Technik!
Angenommen die deutschsprachige Wikipedia würde per MB entscheiden, Kategorien zwecks höherer Wahrnehmung über die Einzelnachweise zu setzen, wäre dies technisch für Euch insoweit machbar, dass sich Navigationsleisten und die Kategorienzeilen bei kurzen Artikeln (die zugleich Infoboxen und/oder Bilder am rechten Rand haben) anpassen würden, sodass es nicht zu einer überdeckung der Flächen am rechten Rand kommt? Bei etwas längeren Artikeln, bei denen bspw. die Bilder am rechten Rand bis über den Abschnitt der Einzelnachweise hinausreichen, wird der Quellen-Abschnitt automatisch visuell komprimiert. Zu sehen bspw. im Artikel Parker Solar Probe. Bei Navigationsleisten und Kategorienleisten findet diese Anpassung/Komprimierung derzeit (auch bei längeren Artikeln) nicht statt. Das kann man bspw. sehen, wenn man über die Bearbeitung des eben erwähnten Artikels, den Fließtext aus dem Artikel rausnimmt und sich das Ergebnis über die Vorschau ansieht: So folgen erst nachdem die Infoboxen und Bilder am rechten Rand enden, die Navigationsleisten und Kategorienleisten.
Gruß, --LennBr (Diskussion) 03:55 (Nacheditiert um 18:27), 18. Sep. 2020 (CEST)
Theoretisch für Benutzer mit aktiviertem JavaScript schon.
Das Ganze ist in Desktop gedacht; in den Mobildarstellungen nicht umsetzbar.
Global steht das auf allen Seiten in jedem Wiki an der gleichen Stelle, und auch die hiesige Lesersachaft ist es an dieser Stelle gewohnt.
Wenn, dann passiert das auf allen Seiten, und auch Wartungskategorien würden dann mitten im Artikel auftauchen. Irgendwas wie „kurze Artikel“ gibt es nicht. Es gibt auch keine einheitliche Überschrift „Einzelnachweise“, oberhalb so bezeichneten Abschnitts etwas dargestellt werden könnte.
Für Autoren, neue und altgediente, ist die Darstellung ziemlich verwirrend und bedürfte Umlernens, und die Darstellung wäre nicht mehr vorhersagbar. Momentan ist das sehr simpel: Das, was ich als Wikitext angebe, wird in einem einheitlichen Block in genau dieser Reihenfolge auch in der Seite dargestellt. Außerhalb dessen stehen die Kategorien, in allen Namensräumen, immer an der gleichen Stelle. Auch die Leser suchen es in allen Namensräumen in allen Wikis dort und nur dort. Wenn es dort unten nicht zu sehen ist, dann gibt es auch keine Kategorisierung, basta.
Der Artikel sieht Mobil anders aus als Desktop, mit JavaScript gibt es andere Abschnitte als ohne, bei Artikeln ohne „Einzelnachweise“ mit Navigationsleisten ist es wieder anders. Ziemlich konfus.
Die Richtlinien zur Anordnung von Abschnitten in Artikeln müssten umgeschrieben werden.
Performancemäßig katastrophal: Um ein oder zwei Dutzend Seiten umzubauen, die optisch in Frage kämen und auch einen „Einzelnachweise“ überschriebenen Abschnitt hätten, müssten zweieinhalb Millionen Artikel analysiert werden, für jede Darstellung.
Ein MB würde ich persönlich als chancenlos einschätzen, aber das ist nicht meine Aufgabe.
@PerfektesChaos: Sind alle diese Punkte in der Annahme geschrieben, dass nur bestimmte Artikel von einer solchen (hypothetischen) Änderung nach positiven MB betroffen sind? Im Ausgangspost oben habe ich nicht klar genug gemacht, dass ich über ein Verschieben der Navi- und Kategorienleiste bei allen Artikeln nachdenke, sodass diese Leisten besser zur Geltung kommen. Würde also deine Einschätzung/Antwort nun anders ausfallen (unter der Annahme, dass Du dachtest, ich beziehe mich nur auf kurze Artikel)? --LennBr (Diskussion) 18:25, 18. Sep. 2020 (CEST)
Ich ging von deiner Darstellung zum Platz sparen bei kurzen Artikeln und viel Infobox aus, und irgendwas mit Layout und Bildern am rechten Rand. Das Gesamtziel oder ein Konzept habe ich ohnehin nicht verstanden.
Auch übertragen auf alle Artikel bleiben aus rein technischer Sicht die nachstehenden Knackpunkte:
Kategorien lassen sich nur mit aktiviertem JavaScript woanders hin mitten in den Artikel verschieben, mit dem Problem des FOUC und bei anderer Artikelstruktur in einer Mobil- und Desktopdarstellung.
Im Inhaltsverzeichnis taucht dein eingefrickelter Kategorien-Abschnitt grundsätzlich nicht auf, soll aber wohl eine Abschnittsüberschrift bekommen.
Was haben die Wartungskategorien im enzyklopädischen Text zu suchen?
Heißt: Der Artikel wird für viele Leser aus unerfindlichen Gründen dauernd anders strukturiert aussehen.
Das muss überhaupt erstmal eine Mehrheit der MB-Teilnehmer befürworten, und die sehe ich nicht.
Mit Navigationsleisten wird das noch abenteuerlicher.
Verschieben der Navileiste bei allen Artikeln – das klingt nicht wie gründlich durchdacht.
Navigationsleisten stehen nach dem Artikeltext, nachdem alle enzyklopädischen Inhalte zu diesem Lemma erschöpfend behandelt wurden. Sie verweisen dann auf benachbarte enzyklopädische Artikel und stehen genau dort goldrichtig wo sie heute stehen.
Im Anschluss an die Navigationsleisten, sofern vorhanden, kommen nur noch Verwaltungsinformationen und Angelegenheiten außerhalb des enzyklopädischen Inhalts selbst; ggf. eine Gespochene Version oder Auszeichnungen als Lesenswert, Exzellent oder dergleichen.
Dorthin, also zum Verweis auf andere Artikel mit thematischer Nachbarschaft gehören auch die Kategorien.
Ich habe nicht verstanden, was das werden soll, aber diese Werkstatt ist auch definitiv der völlig falsche Ort für diese Frage. Hier war nur nach Darstellung der Kategorien an anderem Ort zu beantworten gewesen.
Am besten baust du Beispiel-Layouts in deinem BNR auf, stellst deine Absichten auch in Extremalfällen dar und diskutierst auf Basis anschaulicher Demonstrationsbeispiele irgendwo anders darüber.
Letzter Kommentar: vor 2 Monaten2 Kommentare2 Personen sind an der Diskussion beteiligt
Es ist einige Monate her, da war ich berufsbedingt gezwungen programmieren lernen, in C++. Als es darum ging ein Übungsprojekt zu finden grub ich eine alte Idee aus, ein Tool das politische Weltkarten automatisch einfärbt, so was wird ja hier sehr oft gemacht. Das Tool wurde während des Kurses auch soweit fertig das es benutzbar ist, es fehlt noch gewisser Feinschliff und Komfortfunktionen. Nun kam es aber anders, aus der angedachten Stelle wurde virusbedingt nichts, und ich nun habe nun mit derartigen Themen (wieder) nur ganz selten was zu tun (und wenn, dann mit Python), lerne also nicht "automatisch" dazu. Lange Rede, kurzer Sinn, "fertigzustellen" geht vllt. noch, Pflegen oder gar Weiterentwicklung des ganzen aber nicht. Frage: Gibt es hier einen Programmierer, der das Tool mitübernehmen könnte?--Antemister (Diskussion) 13:59, 20. Sep. 2020 (CEST)
Letzter Kommentar: vor 2 Monaten6 Kommentare3 Personen sind an der Diskussion beteiligt
Oben im Kopf der Seite sind neben meinem Benutzernamen die Symbole für meine Meldungen (Glocke) und meine Mitteilungen (leerer Bildschirm - oder was immer das ist) zu sehen. Seit Kurzem werden bei beiden Symbolen die Mitteilungen aufgeklappt, nur wenn ich bei der Glocke ganz unten auf den Klöppel klicke, was allerdings schwer zu erwischen ist, dann werden die Meldungen angezeigt. (Windows 10, Firefox 81.0.1 (64 bit), Benutzeroberfläche Vector, Legacy-Vector deaktiviert). Wenn ich auf die alte Vector-Oberfläche zurückschalte, funktioniert es; ist allso offenbar ein Bug in der neuen Oberfläche. --TheRunnerUp22:30, 3. Okt. 2020 (CEST)
Ja, mit Edge 85.0.564.68 (Offizielles Build) (64-Bit) auch, ebenso IE 11.0.9600, Firefox 68.12.0 - mehr habe ich nicht zur Verfügung. --TheRunnerUp12:42, 4. Okt. 2020 (CEST)
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)
RikVII. my2cts 07:16, 17. Okt. 2020 (CEST)
--FriedhelmW (Diskussion) 14:07, 22. Nov. 2020 (CET)
13:43, 20. Jul. 2020 (CEST)
