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/2015#Thema 1]]
oder als Weblink zur Verlinkung außerhalb der Wikipedia
Kasten auf Diskussionsseiten von SG-Anfragen automatisch mitgenerieren
Letzter Kommentar: vor 9 Jahren9 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo, wäre es möglich, den Kasten
{{Diskussionsseite|Zweck=Diese Diskussionsseite dient dazu, unklare Punkte an der ''Projektseite'' [[Wikipedia:Schiedsgericht/Anfragen/Beispielanfrage|Beispielanfrage]] zu diskutieren, sachdienliche Hinweise zu liefern und auf eventuelle Fehler oder Probleme aufmerksam zu machen, die bei der Bearbeitung der Anfrage durch die Schiedsrichter auftreten.
'''Allgemeine Betrachtungen zum Projektzustand, Ad-personam-Diskussionen und süffisante Spitzen gegen einzelne Beteiligte gehören nicht hierher.'''}}
bei einer SG-Anfrageerstellung automatisch auf die Diskussionsseite zu setzen? Grüße, --Ghilt (Diskussion) 21:08, 7. Jan. 2015 (CET)
Mmmm.
Wir haben zwar eine preload-Möglichkeit Hilfe:Preload, die auch in der <inputbox> wirken würde.
Du möchtest aber eine völlig andere Seite, nämlich die zugehörige Disku beschreiben, und da sehe ich auch in Hilfe:Eingabefelder keinen Weg.
Ich wüsste nur vier Varianten:
Zweiten Knopf, den die Antragsteller drücken sollen, und das dann speichern. Doof.
Einen solchen Knopf in der Schiedsrichter-Hosentasche, der im Rahmen der #Annahmeentscheidung sichtbar ist, solange die Disku nicht existiert. Schiri drückt selbst und generiert die gewünschte Einbindung und speichert, dann Knopf auch weg.
Einen Bot bitten, diese Seitengenerierung zu belauschen und automatisch eine geeignete Vorlageneinbindung dorthin zu kopieren, ggf. zu substituieren.
Der Umherirrende hat ein newpages-Voodoo zur Hand, das beim ersten Beschreiben der Disku die Vorlage mit davorschreibt.
Danke für die Antwort. Die letzten beiden Varianten klingen gut, die ersten beiden Varianten bedeuten ähnlich viel manuellen Aufwand wie das momentane c&p. Grüße, --Ghilt (Diskussion) 23:32, 7. Jan. 2015 (CET)
In MediaWiki:Newarticletext-5 könnte man auch wieder nur einen Hinweis an den ersten Bearbeiter schreiben, aber das ließe kein Preload in das Editfeld zu.
Dafür könnte in der praktisch noch leeren MediaWiki:editnotice-5 für jeden Bearbeiter irgendeiner SGA-Disku der gewünschte Text während der Bearbeitung unkaputtbar gezeigt werden, beim normalen Lesen der Seite ist das dann allerdings unsichtbar. Für den Umherirrenden sofort umsetzbar. (Info: Bitte obige Kastenunterseite [gibt es die schon?] gleich mit 1=Editnotice einbinden, dann weiß man Bescheid und kann sich drauf einstellen.)
Sonst bliebe nur die Variante Bot, um ggf. zusätzlich auch eine Vorlage einzufügen. Deren Ansicht im Bearbeitungsmodus zu unterdrücken wäre, um nicht moppelt zu doppeln. Machbar.
Ich mach kein Voodoo, hatte mich schon gewundert was du da meinst ;-)
Neben den zweiten Button zum anlegen der Diskussionsseite könnte man auch im SGA-Intro eine Prüfung auf Existenz der Diskussionsseite einbauen und einen Hinweis mit Anlage-Link anbieten. Der Anlage-Link würde den gewünschten Inhalt und eine automatische Zusammenfassung setzen und man brauch nur noch auf Speichern klicken. Ist zwar noch manuell, aber weniger Aufwand für den ersten der den Hinweis sieht. Per Editnotice hat den Nachteil das es nicht beim anschauen der Seite lesbar ist und der ein oder andere sich über zu viel über dem Bearbeitungsfenster beschweren könnte. Der Umherirrende21:19, 8. Jan. 2015 (CET),
"Do do that voodoo that you do so well", vielen lieben Dank für die Tips! Verzeiht bitte eine unbedarfte Frage: Welche Bots haben eine ausreichend hohe Aktualisierungsfrequenz? Grüße, --Ghilt (Diskussion) 21:26, 8. Jan. 2015 (CET)
Jeder Bot kann anders sein, liegt immer an seinem Betreiber. Auf Wikipedia:BA könntest du vielleicht ein Botbetreiber finden, wenn du es nicht selber machen möchtest. Tipps zum selber machen kann ich keine geben. Der Umherirrende19:37, 9. Jan. 2015 (CET)
Revertlink für meinen Diskussionsbeitrag mit dem selben Edit mitliefern?
Letzter Kommentar: vor 9 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
Wenn der Server schon vor dem Speichern speichert, kann ich dann vorab schon die Versionsnummer erfahren? Oder gibt es ein Zauberwort, das beim Speichern durch die Versionsnummer ersetzt wird. --Diwas (Diskussion) 15:38, 9. Jan. 2015 (CET)
Es gibt nicht die Möglichkeit beim Speichern auf die Versionsnummer genau der frisch gespeicherten Version zu kommen (siehe auch den Hinweis zu REVISIONID auf Wikipedia:VAR). Auf Wikipedia:FZW gab es ähnliche Fragen auch schonmal, such nach "revisionid". Der Umherirrende19:35, 9. Jan. 2015 (CET)
Danke, ich hatte hier nur aufgeschnappt, dass der Server (wohl neuerdings) schon vorab Daten erhält, daher kam mir die Frage in den Sinn, als ich andernorts eine flüchtige Off-Topic-Nachricht hinterlassen wollte. --Diwas (Diskussion) 19:50, 9. Jan. 2015 (CET)
@Diwas: Wie gesagt, geht leider nicht; weil die Nummer erst nach dem erfolgreichen Abschluss der Speicherung des Textes bekannt ist und sie deshalb nicht innerhalb des Textes stehen kann.
Danke, für den Versuch und die Teillösung. Eine Vorlage dafür wäre zu viel für spaßeshalber. Ich muss ja nicht jeden Senf loswerden. Wie gesagt, weil ich zufällig diese Neuheit gelesen habe, hatte ich es überhaupt, für möglicherweise neuerdings möglich gehalten. Wäre ja denkbar gewesen, dass nun dabei schon eine Versionsnummer belegt würde. Grüße --Diwas (Diskussion) 01:00, 11. Jan. 2015 (CET)
Letzter Kommentar: vor 9 Jahren10 Kommentare3 Personen sind an der Diskussion beteiligt
Ist es eigentlich eine bekannte Erscheinung, daß manchmal anstatt der üblichen Skin auf einer Seite eine einfache, puristische Skin angezeigt wird, die der Klassik-Skin und der Mobile-Skin ähnelt? Tatsächlich stimmt sie sogar fast vollständig mit demjenigen Aussehen überein, das früher das Einstellen von MySkin erzeugte, wenn man nichts daran verändert hatte (also mit der voreingestellten MySkin). Nach meiner Beobachtung passiert dies, wenn der Text der Seite geladen ist, der Ladevorgang aber verfrüht abgebrochen wurde (den Zeitpunkt gezielt zu erwischen ist aber sehr schwierig), oder (die häufigste Ursache) bei gestörter Netzverbindung. Mir ist allerdings etwas Analoges auch schon bei Facebook passiert (allerdings bisher nur einmal). Passiert das, wenn die CSS-Datei nicht geladen wird?
Schade, daß man diese Skin nicht gezielt einstellen kann. Nicht nur finde ich sie ästhetisch ansprechend, sie ist auch geeigneter als Vector, Monobook & Co., wenn man kurze Zeilen anzeigen will (indem man das Fenster verschmälert oder die Schrift vergrößert), weil beispielsweise Bilder immer wie eigene Absätze angeordnet werden und nie seitlich vom Text. Hingegen machen Vector und Monobook bei allzu kurzen Zeilen Probleme. --Florian Blaschke (Diskussion) 02:06, 10. Jan. 2015 (CET)
Der Effekt, den du schilderst, kommt in der Tat zustande, wenn durch ein Netzwerk-, Browser- oder Server-Problem die Ressourcen nicht geladen werden; hier wohl CSS.
Wenn dir das so gefällt, dann kannst du das auch regelmäßig produzieren. Du müsstest lediglich einem Skriptblocker etc. beibringen, eine URL ungefähr wie die nachstehende abzuwehren, nicht laden zu lassen:
Da steht all das drin, was dir nicht gefällt. Die genaue Gestalt hängt davon ab, was für Einstellungen du vorgenommen hast und auf was für einer Seite du bist. Du bräuchtest also ein Schema, dass entsprechende URL-Formate abblockt.
Am Besten, du blockst gleich //bits.wikimedia.org/ ganz ab, dann wirst du nicht mehr von irgendwelchem Design und irgendwelchen Funktionen belästigt.
Ah, danke! Ich hab das gerade mal mit Adblock Plus ausprobiert und es funktioniert tatsächlich. (Mir ist schon lange aufgefallen, daß bits.wikimedia.org besonders ladeintensiv ist, gerade bei schlechter Netzverbindung ist das deutlich spürbar.) Mal sehen, ob das auch ressourcenschonender ist.
Gut, Echo funktioniert damit sicher nicht (Visual Editor sowieso nicht, aber den brauche ich auch nicht), das ist von den neuen Javascript-Erweiterungen noch die sinnvollste. Bleibt die bei Deiner ersten Option funktional? Ich habe jetzt nur die zweite ausprobiert. --Florian Blaschke (Diskussion) 15:19, 10. Jan. 2015 (CET)
Wenn du selektiv &only=styles blockierst, bekommst du nur kein CSS.
Wenn du bits.wikimedia.org komplett blockierst, dann auch keinerlei JS von MediaWiki.
Theoretisch könnte man trotzdem über eine nicht-bits.-URL einzelne JS-Komponenten anschließend selektiv laden. Die verlassen sich aber auf eine Vielzahl von Bibliotheksfunktionen, die bei bits. mit dabeigewesen wären. Auch die könnte man einzeln ermitteln und zuvor von anderen URL laden, die nicht blockiert sind, aber das wird dir keinen Spaß machen. Auch die gängigen und aktuellen Benutzerskripte würden ohne die Standardbibliotheken nicht funktionieren.
Die Echo-Standardfunktionen klappen auch bei abgeschaltetem JS, nur anders.
Die Netzwerkverbindung hat nichts mit Ressourcen bei der Aufbaugeschwindigkeit zu tun; die weitaus überwiegende Mehrheit liegen in deinem Browser-Cache oder an einer anderen Stelle und werden nicht jedesmal neu vom Server abgerufen. Sie ändern sich in aller Regel maximal einmal wöchentlich. Es wäre allerdings möglich, die standardmäßig permanenten Aktualisierungsrückfragen auszubremsen.
Firefox hat doch diese störende Neigung zum Memory-Leaking (Speicherlecken? ;-) ). Ich habe erwogen, daß die einfachere Darstellung möglicherweise auch hinsichtlich des Arbeitsspeicherverbrauchs Vorteile bieten könnte; die Netzverbindung ist meistens nicht das Hauptproblem, sondern der Speicher (dabei sind 4 GiB gar nicht so wenig): Firefox wird manchmal extrem langsam, obwohl nur wenige Tabs offen sind. Allerdings habe ich gelesen, daß Adblock Plus ironischerweise einer der größten Ressourcenräuber ist und damit dürfte das Add-on jeden Vorteil durch eine einfachere Darstellung bei weitem wieder aufwiegen. :-(
Hm, OK, danke jedenfalls für die Auskunft. Ich werde den puristischen Skin jetzt wohl doch nicht durchgängig verwenden, aber zum Lesen längerer Artikel kann ich ihn jetzt bei Bedarf einstellen. Prima! --Florian Blaschke (Diskussion) 14:52, 12. Jan. 2015 (CET)
Letzter Kommentar: vor 9 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
Warum gibt es bei der Beobachtungsliste den Container #watchlistfor (für den Benutzernamen unter der Überschrift) nur hier und sonst (enwiki, commons, …) nirgends? Wie kann man den Benutzernamen ohne diesen Container selektieren? --nenntmichruhigip (Diskussion) 23:54, 23. Jan. 2015 (CET)
Ok, dann behelfe ich mir mit .mw-special-Watchlist #contentSub{opacity:0;} .mw-special-Watchlist #contentSub:hover{opacity:1;} in global.css und lokal .mw-special-Watchlist div#contentSub{opacity:1;}. --nenntmichruhigip (Diskussion) 08:19, 24. Jan. 2015 (CET)
anzubieten, die -15em musst du noch an deine Länge anpassen, und so ganz sauber ist es nicht, aber vielleicht gefällt es dir ja. --Schnark09:41, 24. Jan. 2015 (CET)
Letzter Kommentar: vor 9 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
Folgendes Problem: Wie kann man am besten (oder überhaupt) feststellen, dass man sich gerade auf einer new-section-Seite befindet? Momentan benutze ich folgenden Code: :/§ion=new/.test(location.search) Allerdings scheint mir das etwas unorthodox und in der Tat ist diese Testabfrage alles andere als zuverlässig (siehe dieser Überschrift).
Ich hatte folgende Achtung: Du hast kein Betreff/Überschrift eingegeben. Wenn du erneut auf „Seite speichern“ klickst, wird deine Bearbeitung ohne Überschrift gespeichert. Der Haken ist nun folgender, nicht dass ich tatsächlich eine Überschrift angegeben hatte und diese dann nochmals in die Zusammenfassung kopiert hatte (tatsächlich ist es genau dasselbe Input-Feld), sondern dass §ion=new aus der URL verschwunden ist und mein Script durchlief. ↔ Benutzer: Perhelion19:40, 2. Feb. 2015 (CET)
Vielen Dank PC, ich denke das ist es. Baue es gleich ein, allerdings wohl ganz hinten, da mir solch eine per jQ-name-Selector doch wesentlich Resourcen-fordernder zu sein scheint (also für jeden Seitenaufruf, ich glaube ich lasse sogar beide drin? :P). Bis auf Weiteres. LG ↔ Benutzer: Perhelion16:07, 3. Feb. 2015 (CET)
Ich hatte noch an eine Art RevisionsID ('wgCurRevisionId') gedacht, die es noch nicht geben dürfte, aber diese wird wohl doch gleich neu generiert. Wie es auch sei, ich bin mit dem new wpSection in die Offensive gegangen (also aufgefangen), habe dein Snipped verwendet und herausgekommen ist (wenn man so will) ein neues Gimmik für Schusselige oder Neulinge (die Code-Änderung hast du vermutlich bemerkt). LG ↔ Benutzer: Perhelion22:30, 5. Feb. 2015 (CET)
Kleinigkeit noch zur Ergänzung: $("#wpMinoredit").length ist wohl tatsächlich noch besser (warum auch immer, aber ich hatte irgendwie eine spontane Eingebung das schon mal vor vielen Jahren verwendet zu haben :P). PS: Ich habe auch noch was historisches wertvolles gefunden Benutzer:PerfektesChaos/js/MinorEdit ↔ Benutzer: Perhelion10:10, 9. Feb. 2015 (CET)
/** * load the Edittools on [[Spezial:Upload]] and prefill the summary textarea * Load pages: [[MediaWiki:Onlyifuploading.js]], [[MediaWiki:Onlyifediting.js]] */if(mw.config.get('wgCanonicalSpecialPageName')==='Upload'){mw.loader.using(['jquery.accessKeyLabel'],function(){importScript("MediaWiki:Onlyifuploading.js");importScript("MediaWiki:Onlyifediting.js");});}
Zufällig hatte ich da mal auf Meta nachgefragt, da die Doku veraltet war. Ich benutze es auch in meinem signing.js. Ich habe es genau so wie du verwendet. ↔ Benutzer: Perhelion21:43, 5. Feb. 2015 (CET)
Es war ja erst vor einer Weile updateTooltipAccessKeys($e) durch mw.util.updateTooltipAccessKeys($e) ersetzt worden; das ist also auch schon wieder obsolet?
Ist nicht so meine Baustelle.
Da stecken noch != drin, Klammern fehlen, mal durch http://jshint.com/ jagen.
/** * Ermöglicht eine Vorschau der Beschreibung auf [[Spezial:Hochladen]] * siehe auch [[phab:T4537]] * wird in [[MediaWiki:Common.js]] eingebunden * Code von [[Benutzer:Schnark]] * <nowiki> */$(document).ready(function(){var$editbox=$('#wpUploadDescription');if($editbox.length!==1){return;// exits silently if not exactly one #wpUploadDescription is found}varparseAsSummary;// Fallunterscheidung für Vorschaufunktionif(mw.util.getParamValue('wpForReUpload')!=='1'){// Kein Upload von neuer Dateiversion?parseAsSummary=false;// bei Upload der ersten Dateiversion wird eingegebener Text auf der Seite erscheinen}else{parseAsSummary=true;// bei Upload von neuer Dateiversion wird eingegebener Text nur im Log erscheinen}if(!mw.config.get('wgEnableAPI')){return;}varpreviewText='Vorschau';if($('#mw-description-preview').length===0){$('#mw-htmlform-description').before($(mw.html.element('div',{id:'mw-description-preview'})));}$('input[name="wpUpload"]').after($(mw.html.element('input',{value:previewText,type:'button',id:'wpPreview',title:previewText,accesskey:'p'})).click(function(){if(typeofwikEd!=='undefined'&&wikEd.useWikEd){// if WikEd is activewikEd.UpdateTextarea();// transfer WikEd to $editbox}varparam={action:'parse',title:'Datei:'+($('#wpDestFile').val()||'Beispiel.jpg'),//Titel, Datei:Beispiel.jpg als Standardprop:'text',pst:'',format:'json'};param[parseAsSummary?'summary':'text']=$editbox.val();//Inhalt des Eingabefeldes entweder als Kommentar oder als Text parsen$.getJSON(mw.util.wikiScript('api'),param,function(json){varcontent=parseAsSummary?'parsedsummary':'text';//Geparster Inhalt entweder in parsedsummary oder in textif(!json||!json.parse||!json.parse[content]||!json.parse[content]['*']){return;}varhtml='<p><strong>'+previewText+':</strong></p><div>'+json.parse[content]['*']+'</div>';$('#mw-description-preview').html(html);});//getJSON}));//click$('#wpPreview').updateTooltipAccessKeys();});//ready//</nowiki>
Oh* super. Das würde ich auf Commons brauchen!! Seit dem ("fortschrittlichen") Hochladeassi wird da gar nix mehr in der (klassischen) Richtung verbessert. ↔ Benutzer: Perhelion11:16, 6. Feb. 2015 (CET)
Korrekterweise braucht dieser Code noch ein mw.loader.using für mediawiki.util.
Ich würde die using und Verwendungen nicht auf zwei verschiedene Seiten verstreuen.
Vielmehr sollte diese und die anloge Seite editing jeweils ein Selbstversorger sein und sich genau die Ressourcen sicherstellen, die gebraucht werden.
Auch in einem anderen Wiki sollte das dann als Einheit funktonieren.
Andernfalls müssten dependencies auch auffallend dokumentiert werden.
Nochmals meine Frage von oben:
Es war ja erst vor einer Weile updateTooltipAccessKeys($e) durch mw.util.updateTooltipAccessKeys($e) ersetzt worden; das ist also auch schon wieder obsolet?
mw.util.updateTooltipAccessKeys ist wieder obsolete, jetzt gibt es das Modul. Ich habe mir den Tag über auch schon gedacht, das es besser ist das using mit in die gleiche Skript zu schreiben und nicht in Common.js. Und wie Schnark schon in seinen Code hat, kann das [p] vom title weg, weil das Modul es selber setzt. Mal den Code prüfen und dann übernehmen. Der Umherirrende15:10, 6. Feb. 2015 (CET)
Ah, na wenn schon umbauen, dann doch gleich richtig und zukunftsweisend:
Es spricht nichts dagegen, innerhalb des commonUpload nochmals per using zu checken; beugt Überraschungen vor, erleichtert Fremdanwendungen und flutscht normalerweise glatt durch.
Bei der Sache mit der Benutzung von Gadgets bin ich mir noch nicht sicher ob wir das so haben wollen. Sinnvoll ist es, vielleicht mit Gadget2.0, 3.0 oder welche Nummer auch immer gerade aktuell ist. Ansonsten habe ich die notwendige Änderung gemacht. Der Umherirrende16:35, 6. Feb. 2015 (CET)
Was mir noch aufgefallen ist: Der Accesskey p ist doppelt, einmal für die Druckversion, einmal für die Vorschau. Das war zwar vorher auch schon so, sollte aber nicht so sein. Die Druckversion braucht in diesem Fall niemand, also schlage ich vor, dort den Accesskey zu entfernen. Dazu müsste die Zeile
$('#wpPreview').updateTooltipAccessKeys();
ersetzt werden durch
$('#t-print a').removeAttr('accesskey');$('#t-print a, #wpPreview').updateTooltipAccessKeys();
Letzter Kommentar: vor 9 Jahren9 Kommentare3 Personen sind an der Diskussion beteiligt
Ausgangspunkt war die Frage in der Vorlagenwerkstatt. Ich habe den Fehler etwas eingegrenzt, er zeigt aber sehr merkwürdiges Verhalten. Die Vorlage:Jahresdiagramm erzeugt schönen <timeline>-Code (Extension), der wird aber ggf. falsch umgesetzt. Wenn ich die Jahre 1999 bis 2007 fülle gibt es den Fehler:
Wenn ich ein beliebiges Jahr ganz entferne, geht es. Wenn ich den Zahlenwert von 2007 auf mindestens den von 2006 erhöhe, funktioniert es, schon 1 darunter gibt es den Bug - den Zahlenwert auf 102762 zu senken hilft aber auch. Wenn ich 2007 lasse und 2006 auf 144247 erhöhe, funktioniert es auch. Wenn ich 1999 auf 175555 oder 165557 erhöhe oder auf 165552 oder 115555 reduziere, funktioniert es auch. Es ist also nicht die reine Anordnung der Zahlen, aber diese scheint zumindest bei 2006/2007 eine Rolle zu spielen. Meistens klappt es, aber ein paar Zahlenkonstellationen führen zum Bug. Jemand eine Ahnung, woran es liegen könnte? --mfb (Diskussion) 00:17, 1. Feb. 2015 (CET)
Auf Spezial:Vorlagen expandieren ergeben sich haufenweise Leerzeilen aus der Vorlage, entfernt man diese, tritt der Fehler nicht auf:
Das sollte zwar keinen Unterschied machen (und wie ich das letzte Mal in den Code für Timeline geschaut habe, ist mir nur aufgefallen, dass Leerzeilen einen unerwarteten Einfluss auf Schriftgröße und Zeilenabstand im Text haben können), aber offensichtlich tut es das doch. Der Code der Timeline-Erweiterung ist eine ziemliche Katastrophe, ein Versuch diesen Leerzeilenbug zu beheben halte ich daher für wesentlich gefährlicher als ihn zu akzeptieren und die Vorlage so umzuschreiben, dass sie keine überflüssigen Leerzeilen erzeugt. --Schnark09:26, 2. Feb. 2015 (CET)
Die Leerzeilen kommen größtenteils von den nicht genutzten Jahren und lassen sich gut entfernen, mache ich dann bei Gelegenheit. Danke für den Tipp. Also haben wir einen Bug, der nur bei vielen Leerzeilen und mindestens 9 streng absteigend sortierten Werten, aber auch dann nicht immer, auftritt. "Okay". --mfb (Diskussion) 11:29, 2. Feb. 2015 (CET)
Vor einer Weile hatten wir mal die Vision, eine Timeline fütternde Vorlage durch Lua zu ersetzen.
War das diese hier?
Wie viele dieser Timeline ansteuernden Vorlagen haben wir insgesamt? Könnten die kategorisiert werden?
Im konkreten Einzelfall hätte Lua den Vorteil, dass die starre Einschränkung auf bestimmte Jahre wegfallen würde; beliebige Jahreszahlen wären möglich, auch negative (Sklavenanzahl beim Pyramidenbau).
Dabei kann man dann sowohl übersichtlich programmieren wie auch Whitespace nicht generieren.
Ich selbst bin voll augelastet und darf mir nichts Neues mehr vornehmen; aber ich könnte mfb bei ersten Schritten in Lua begleiten.
Hmpf. Der Wikipedia-Parser mit seiner Angewohnheit, alles zu trimmen was irgendwo in einem if-Statement ist (also auch Zeilenumbrüche), zusammen mit dem Timeline-Parser mit seiner Angewohnheit, jede Abweichung vom erwünschten Quelltext zu bemängeln (was das Trimmen verhindern könnte), ist eine absolute Katastrophe. Jemand eine Idee, wie man die Zeilenumbrüche sinnvoll entfernt? Man könnte 10er-Blöcke mit jeweils einem gröberen if-Statement und Zeilenumbruch außerhalb machen, aber das ist nicht wirklich schön. --mfb (Diskussion) 17:26, 3. Feb. 2015 (CET)
Die Änderung hilft nicht überall, aber bei den meisten Artikeln hat es gewirkt und für den Rest wurde ein Workaround gefunden. Nicht repariert, aber dennoch erledigt. --mfb (Diskussion) 00:42, 12. Feb. 2015 (CET)
Commons - MediaViewer - HTML-Code für Urheberangabe
Letzter Kommentar: vor 9 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo,
wenn ich im MediaViewer eines Bildes in Commons auf Herunterladen gehe und die Funktionalität für die Quellenangabe (als HTML-Code) nutze, dann fehlt im angegebene HTML-Code das bei den href-Attributen der A-Tags das führende "http" (bis auf das erste A-Tag).
Ist auch in der englischen Version von Commons so.
Letzter Kommentar: vor 9 Jahren8 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo zusammen,
in der Alemannischen Wikipedia verwenden wir seit vielen Jahren hochdeutsche Artikelnamen und eine Javascript-Vorlage, mit Hilfe derer wir den Seitentitel mit einem alemannischen Namen überblenden. Seit ein paar Tagen funktioniert das nicht mehr richtig, z. B. wird im Artikel als:Turtmanntal der Titel (Turtmaatelli) zwar angezeigt, aber gleichzeitig steht er noch einmal in Normalschrift am Anfang des Artikels. Vermutlich liegt das an einem Software-Update, das wir auf als:MediaWiki:Common.js nachkorrigieren müssten. Kann mir da jemand helfen? Vielen Dank und Grüße, --Holder (Diskussion) 05:31, 13. Feb. 2015 (CET)
Nachträglich eingefügte Links ohne neue Signatur funktionieren nicht als Ping. Benutzer:Fomafix. Das liegt am div mit der ID "pTitle", dort ist keine besondere Schrift vorgesehen. --mfb (Diskussion) 21:27, 13. Feb. 2015 (CET)
Letzter Kommentar: vor 9 Jahren14 Kommentare6 Personen sind an der Diskussion beteiligt
Hallo, ich wollte nur fragen, ob es nicht einen Link gibt, der auf den jeweiligen "Artikel des Tages" weiterleitet. Ich hätte das gern, um ein bisschen für die Wikipedia zu werben. Ich sehe zwar auf der Hauptseite immer einen "Artikel des Tages", aber ich hätte es gern dynamisch. Danke euch. --Karsten Meyer-Konstanz (D)19:08, 16. Feb. 2015 (CET)
Ja, der Artikel selbst wäre nach obigem Vorschlag nur über die Verlinkung im Teasertext zu erreichen.
Wobei, bei entsprechendem Bedarf wäre es durchaus möglich, eine direkte Wikipedia:Hauptseite/Artikel des Tages/Heute zu erschaffen – einige routinemäßige Dutzend Zeilen Lua-Voodoo. Aber weder sehe ich breiten Bedarf, noch hätte ich Zeit für eine Frickelei und Erprobung. Vielleicht mal zum Einschlafen.
Okay; Lua ist damit aus dem Spiel, so lange dein Bot lebt (möge er ewig leben).
„Bedarf“ und „gewünscht“ weiß ich nicht; da ist diese Werkstatt der falsche Ort. Da du häufiger mit den AdTlern zu tun hast, kannst du die Anregung ja in der dortigen Disku mal vorschlagen.
Oder: Mach es einfach, wenn es für dich eine Kleinigkeit ist; und mach dann hinterher geeignet Reklame für das neue Feature.
Danke euch sehr für die Beschäftigung mit meinem Problem! Habe den Voodoo-Code auf der persönlichen Seite probiert, und natürlich ginge das auch - aber so richtig optimal fände ich das nicht. Also wenn jemand wirlich so eine Weiterleitung programmieren könnte, fände ich das toll. Der Vorteil des "Artikels des Tages" ist halt schon, dass es sozusagen garantiert gute Artikel sind, was als Werbung für uns schon ideal wäre. Besten Dank! --Karsten Meyer-Konstanz (D)13:36, 17. Feb. 2015 (CET)
Doch noch was: Es wäre schade, wenn das Wissen um den schönen neuen Perma-URL hier im Archiv begraben wird. Sollte man den nicht vielleicht auf einer der oben erwähnten Seiten erwähnen? --Karsten Meyer-Konstanz (D)23:47, 17. Feb. 2015 (CET)
Letzter Kommentar: vor 9 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
Ich hoffe, ich bin hier richtig.
Seit einiger Zeit wird, wenn ich meine Signatur mit --~~~~ oder ~~~~ in das Textfeld eingebe, nach dem Abschicken manchmal Chianti (Diskussion) nicht angezeigt (Uhrzeit und Datum dagegen schon), so dass ich das manuell nachtragen muss. Beispiele aus den letzten Tagen: [1][2][3]. Ist das ein bekannter Fehler? Meine Signatureinstellung ist Standard, nichts geändert oder individuell.
Viele Grüße, --Chianti (Diskussion) 18:31, 20. Feb. 2015 (CET)
Der erste Diff zeigt den Inhalt bei Seitenanlage auf der linken Seite als Zusammenfassung, dort sind 5 Tilden enthalten. 5 Tilden ergibt nur die Uhrzeit, während 3 Tilden nur den Benutzernamen geben. Nur die 4 Tilden geben eine komplette Unterschrift. Wie sie da hingekommen sind, ist als Außenstehender schwer zu sagen. Der Umherirrende22:28, 20. Feb. 2015 (CET)
Ich habe bisher die 4 (und offensichtlich manchmal 5) Tilden tatsächlich über die Tastatur eingegeben (geht schneller als zur Maus zu wechseln): Danke für die Erklärung!--Chianti (Diskussion) 01:48, 21. Feb. 2015 (CET)
Letzter Kommentar: vor 9 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo zusammen,
leider liefert mir ISBN2Wiki nur eine Batterie Fehlermeldungen, wenn ich in das Feld eine ISBN eingebe und auf die [OK]-Schaltfläche klicke. Kann mich aber daran erinnern, dass das Tool schon mal funktionierte. Kennt jemand ein alternatives Webtool, das automatisch durch die Eingabe einer ISBN eine Wikipedia-Referenz erzeugt? --Ak ccm (Diskussion) 07:27, 4. Feb. 2015 (CET)
WMF Labs hat laut Auskunft des Tool-Entwicklers Magnus Manske auf eine neuere PHP-Version umgestellt, weshalb zusätzlich zur Ausgabe eine Reihe von Warnmeldungen ausgegeben wurden. Er hat die Anzeige dieser Meldungen jetzt deaktiviert.
[en] Reminder: Weekly VisualEditor triage meeting tomorrow at 20:00 UTC (12:00 PST)
Letzter Kommentar: vor 9 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
As a reminder, on Wednesday, 11 February 2015 at 12:00 (noon) PST (20:00 UTC) there will be the first of a weekly series of open triage meetings about VisualEditor.
We will discuss the release criteria for VisualEditor, and jointly prioritise the work of the team, talking about the bugs and features which are most important to you. We particularly welcome the presence of volunteers who enjoy contributing MediaWiki code.
The joining instructions are available on MediaWiki.org. Hope to see many of you there.
Mit date. date(j) gibt 17 aus (oder 7, aber nicht 07). date(F) gibt den Monat aus - kann aber sein, dass die Sprachlokalisation nicht passt, in dem Fall date(n) für die Zahl und in einem Array die Monatsnamen abspeichern und abfragen. --mfb (Diskussion) 23:04, 17. Feb. 2015 (CET)
echo '<a href="https://de.wikipedia.org/wiki/'.date(j).'._'.date(F).'">Linktext</a>"; (einfachste Form, HTML-Code ist verbesserbar) - falls das zum 17. February verlinkt, ggf. weit oben im Code setlocale(LC_TIME, 'de_DE'); festlegen. Falls das auch nicht klappt, $monthnames=array(1=>"Januar",2=>"Februar",und so weiter); echo '<a href="https://de.wikipedia.org/wiki/'.date(j).'._'.$monthnames[date(n)].'">Linktext</a>";. Ungetestet, sollte aber klappen. "und so weiter" natürlich mit den restlichen Monaten ersetzen. --mfb (Diskussion) 10:58, 18. Feb. 2015 (CET)
Ganz herzlichen Dank für die schnelle Hilfe! Musste nur eben feststellen, dass auf der Website, wo ich das haben wollte, PHP gar nicht ausgeführt wird. Das muss ich erst ändern. --Karsten Meyer-Konstanz (D)11:30, 18. Feb. 2015 (CET)
Hm, dürfte so ähnlich wie bei den FIMI-Links sein. Da lässt sich nichts machen, fürchte ich; ich bin dazu übergegangen, die Original-URL in <nowiki></nowiki> zu setzen und einen Hinweis dazuzusetzen, die URL bitte zu kopieren. Etwa: http://www.bgbl.de/banzxaver/bgbl/text.xav?SID=&tf=xaver.component.Text_0&tocf=&qmf=&hlf=xaver.component.Hitlist_0&bk=bgbl&start=%2F%2F*[%40node_id%3D%27294424%27]&skin=pdf&tlevel=-2&nohist=1 Text des Gesetzes (Achtung: URL in Adressfeld des Browsers kopieren!).--XanonymusX (Diskussion) 23:33, 9. Mär. 2015 (CET)
Danke sehr! ich habe das Problem dadurch gelöst, dass ich den Link verkürzt habe, da muss der Nutzer eben zum Lesen auf den "PDF-Knopf" drücken. --Ekkehart Baals (Diskussion) 12:31, 11. Mär. 2015 (CET)
Stimmt mit der Sig. Als ich das schrieb, glaubte ich noch an ein Wikipedia-weites Phänomen. Es existiert jedenfalls in der Versionsgeschichte. --Michaelsy (Diskussion) 22:36, 31. Mär. 2015 (CEST)
Ok, danke, das wars. Sinngemäß war da "Andere +1 Stunde" eingetragen. Keine Ahnung warum. Bewusst habe ich da sicherlich niemals dran rumgefummelt... Also nochmals Danke für deine rasche und kompetente Antwort, so macht WP Spaß! --Michaelsy (Diskussion) 23:02, 31. Mär. 2015 (CEST)
Bug oder Feature? Überschneidung Sprachpräfix und IPv6-Benutzerseiten
Letzter Kommentar: vor 9 Jahren13 Kommentare5 Personen sind an der Diskussion beteiligt
Liebe Community,
mir ist folgendes aufgefallen: Ruft man die Benutzerseite einer IPv6-Adresse auf, die noch nicht existiert, wird der Titel zwar korrekt angezeigt, erscheint aber in den Textblöcken "Wenn du Benutzer <IP-Adresse> bist ..." und "Um Kontakt mit <IP> aufzunehmen ..." fehlerhaft.
Fängt die IP-Adresse mit DE an, so wird das erste Byte komplett verschluckt, fängt es mit speziellen Zeichenketten, z. B. AB, AF oder BE an, so erscheint das erste Byte der IP-Adresse komplett in Kleinbuchstaben. Beispiele: Benutzer:DE:0:0:0:0:0:0:1, Benutzer:AB:0:0:0:0:0:0:1. Möglicherweise werden in den erwähnten Textvorlagen die ersten beiden Hexziffern der IPv6-Adresse als Sprachkennung erkannt.
Bei hexadezimalen Folgen, die keiner Wikipedia-Sprachversion entsprechen, z. B. AC, aber auch in der englischsprachigen Wikipedia kommt das Problem nicht vor.
"Wenn du Benutzer DE:0:0:0:0:0:0:1 und angemeldet bist," / "Wenn du Benutzer AB:0:0:0:0:0:0:1 und angemeldet bist"? Letzteres auch unangemeldet getestet, gleiches Ergebnis. Ich sehe das Problem nicht. --mfb (Diskussion) 02:02, 3. Apr. 2015 (CEST)
Text von MediaWiki:Noarticletext-2. Es scheint ein Bug in der Parserfunktion #titleparts zu sein. Im ersten Fall (ohne Unterseite, der hier auch angesprochen wird), kann man aber die Funktion gefahrlos entfernen. --se4598 / ?16:05, 3. Apr. 2015 (CEST)
Es ist kein Bug in titleparts, da Titleparts den Namensraum nicht kennt, nimmt es an, dass es sich um einen Namen im Artikelnamensraum handelt. Dort ist de: ein interwiki und wird dann verworfen. Ein den normalen Fall habe ich es mal entfernt. Für den Text auf Unterseiten denke ich mir noch was aus. Bei Unterseiten ist MediaWiki:Newarticletext-2 auch betroffen. Der Umherirrende16:12, 3. Apr. 2015 (CEST)
Ja stimmt, habe ich gerade in der Doku nachgelesen. Für Benutzerunterseiten: {{#invoke:Str|cropleft|{{#titleparts:{{FULLPAGENAME}}|1}}|9}} ? --se4598 / ?16:20, 3. Apr. 2015 (CEST)
Habe es jetzt so und so gemacht. Also nicht Str, sondern einfach wieder PAGENAME vom gekürzten FULLPAGENAME. Die 9 passt ja auch nicht für Benutzerin ;-). Der Umherirrende16:26, 3. Apr. 2015 (CEST)
Sieht gut aus. Ich weiß leider nicht, an welcher Stelle die Testfälle für den MediaWiki-Namensraum abgelegt werden, aber es wäre schön, wenn du diese ergänzen könntest, wenn noch nicht geschehen. Schöne Feiertage! Gruß --217.255.152.21316:38, 3. Apr. 2015 (CEST)
Letzter Kommentar: vor 9 Jahren2 Kommentare1 Person ist an der Diskussion beteiligt
Gibt es eine JS-Funktion in Mediawiki, die die gleiche Funktion hat wie mw.util.addPortletLink, nur dass sie statt einem Link ein Popup/Dialogfenster öffnet? --MGChecker – (📞| 📝| ) – HDR12:06, 30. Apr. 2015 (CEST)
Letzter Kommentar: vor 9 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
Ich habe ein JS geschrieben, was dazu in der Lage ist, vollautomatsich den Quelltext für einen neuen abschnittl wie gewünscht auszufüllen. Die aktuellste Version (bisher ur in Firefox getestet) ist im Beta-Wiki zu finden. Nur muss man immer extra noch auf Speichern drücken, obwohl man am Quelltext des neuen Abschitts nun nichts mehr ändern muss. Wie ich hier gelesen habe, ist es auch möglich, direkt über die URL zu speichern. Gibt es dazu eine vorgefertigte Lösung oder einen einfachen Weg, um an wpStarttime und wpEdittime dranzukommen? Danke für eure Hilfe, MGChecker – (📞| 📝| ) – HDR00:00, 30. Mai 2015 (CEST)
Da das Script neue Abschnitte erstellt und dann auch keine "Editdauer" hat, sollten Bearbeitungskonflikte nicht vorkommen. Funktioniert es, wenn du für beide Zeiten einfach die aktuelle Zeit einsetzt? --mfb (Diskussion) 00:53, 30. Mai 2015 (CEST)
Wenn ich nur wüsste, wo mein Client-Javascript die Serverzeit herbekommt... Ich habe einiges ausprobiert, doch geklappt hat nix. Kann mir da jemand mit mehr JS-Erfahrung helfen? --MGChecker – (📞| 📝| ) – HDR01:49, 30. Mai 2015 (CEST)
Dann nimm eben die lokale Zeit. Oder eine Zeit die deutlich in der Vergangenheit liegt. Wenn meine Vermutung richtig ist wird so ziemlich alles gehen, außer vielleicht Zeiten in der Zukunft die der Server als Unsinn erkennen könnte. Klingt nach einem schnellen Test, wenn du alles andere hast. --mfb (Diskussion) 02:45, 30. Mai 2015 (CEST)
Letzter Kommentar: vor 9 Jahren14 Kommentare4 Personen sind an der Diskussion beteiligt
Gibt es einen Cirrus-Regex-Ausdruck, der es erlaubt, nach Weblinks zu suchen, die in der URL eine/weitere öffnende eckige Klammer(n) enthalten? Ziel wäre also, solche Syntaxfehler automatisiert finden zu können.--Mabschaaf20:05, 24. Mai 2015 (CEST)
[http://...]foo[bar] ist schwierig zu identifizieren, könnten ja auch zwei Weblinks sein (wobei es wohl meistens Fehler sind). Man kann danach wohl suchen, aber die Suchanfrage würde wohl fürchterlich langsam. Aka sucht bereits gezielt nach Wikilinks in Weblinks und kann das vielleicht einfach zu seinem Script hinzufügen. --mfb (Diskussion) 20:53, 24. Mai 2015 (CEST)
@mfb: Ich meinte eher [http://www.beispiel.com/foo[bar]blubb Linktext] - aber ich nehme an, Du hattest schon verstanden. Ja, vielleicht macht Aka auch das noch...--Mabschaaf21:06, 24. Mai 2015 (CEST)
Ja, ich hatte nur einen Fall erwähnt der trickreich ist, dein Beispiel ist einfacher. Falls Aka das nicht ins Script aufnehmen kann, irgendwas mit insource:/[^\[]\[http[^\[\]]+\[[^\[]/ müsste den Fall [...[ finden, ein Teil der eckigen Klammern sind aber im Linktext und mit nowiki umgeben. Sind relativ wenige Treffer, vielleicht fehlen einige. --mfb (Diskussion) 21:19, 24. Mai 2015 (CEST)
Wikipedia hat Schwierigkeiten, diesen Klammerausdruck zu verdauen, wie überraschend. Vorlagenverwendung repariert. --mfb (Diskussion) 21:20, 24. Mai 2015 (CEST)
@Mabschaaf:
Du bräuchtest:
insource:/\/\/[^ \[\]]+\[[^\[h\/]/
Besser vom Syntaxkorrekturprojekt oder Aka suchen lassen, die wollen auch was zu ameiseln haben.
@PC: Sollte das MB tatsächlich morgen Abend starten, hätte ich tatsächlich wieder Licht am Ende des Tunnels. Den Syntax-Kram mache ich eh nur zwischendurch, wenn es im Kopf für mehr nicht mehr reicht. Citoid habe ich schon am Rande mitbekommen, klingt interessant - vielleicht teste ich es dann auch mal.--Mabschaaf23:23, 24. Mai 2015 (CEST)
Mein Linkfehlerscript sucht recht speziell nach einer anderen Art von Fehlern. Wenn ich testweise mal den Artikelbestand nach /\[http[^\]\ ]+\[/ durchsuche, finde ich insgesamt 158 Artikel:
Sollten nun bis auf ganz wenige alle erledigt sein. @Aka: Würdest Du bitte nochmal eine aktuelle Suche laufen lassen? --Mabschaaf10:19, 4. Jun. 2015 (CEST)
Letzter Kommentar: vor 9 Jahren17 Kommentare2 Personen sind an der Diskussion beteiligt
Hat sich dort kürzlich etwas geändert? Bei mir findet sich seit einigen Tagen in der letzten Zeile des Kastens mit den "Anzeigeoptionen" folgendes: | | Besuchte Seiten: ./.
Weiterhin werden besuchte Seiten nicht mehr ausgeblendet, der Kasten lässt sich auch nicht mehr verbergen/verkleinern. Ich hoffe, das kann jemand nachvollziehen/bestätigen oder gar fixen. Ratlose Grüße --Mabschaaf10:42, 23. Jan. 2015 (CET)
Ja, da hat sich vor ein paar Tagen etwas geändert; jetzt in Version 4.0 mit Button Zwischenzeitlich.
Das | | Besuchte Seiten: ./. steht aber schon seit Jahren dort und ist unverändert. Es wirkt dann als „./.“, wenn es im momentanen Zeitraum überhaupt keine bereits von dir besuchten Seiten gibt. Zeitraum vergrößern, so dass die vorangegangene Stunde mit bei ist, dann müsste jetzt ein Button (war früher ein Link) erscheinen.
„Kasten lässt sich auch nicht mehr verbergen/verkleinern“ – äh, eigentlich schon, vor drei Sekunden ging’s noch. Ist auch Eigenschaft von listPageOptions, Button oben rechts mit rotem X sollte es bringen.
Ich bräuchte nähere Einzelheiten, falls sich das nicht doch wieder anfindet. Ggf. Fehlerkonsole.
Ah, I see your problem. Im Modus „Seitenbezogene Gruppierung“ hakt was, fix im Lauf des Wochenendes. LG --PerfektesChaos 12:05, 23. Jan. 2015 (CET) Äh, jetzt nicht mehr, nicht mehr reproduzierbar. Nähere Einzelheiten erforderlich. --PerfektesChaos 12:07, 23. Jan. 2015 (CET) Also in etwa: Wenn man im Modus „Seitenbezogene Gruppierung“ auf Ausblenden geschaltet hatte und in dieser Stellung auf Anwenden klickt, dann blitzen die Einträge beim Neuaufbau der Seite kurzauf, lassen sich aber nicht mehr wieder einblenden? --PerfektesChaos12:13, 23. Jan. 2015 (CET)
Mhh, ich kann Dir leider bei Deinen Ausführungen nicht ganz folgen, die Buttons hinsichtlich Seitenbezogener Gruppierung werden mir gar nicht mehr angezeigt, der Button mit dem roten "x" auch nicht. Der Kasten mit den Byte-Zahlen und der Erklärung von N/K/B usw. ist kurz zu sehen, wird dann aber sofort wieder ausgeblendet.--Mabschaaf13:45, 23. Jan. 2015 (CET)
Klingt ja böse.
Die Legende (wenn das den Kasten meint) ist für Newbies und bei den erfahrenen Skriptnutzern schon seit Jahren nicht sichtbar.
Einen Bug hinsichtlich „Seitenbezogener Gruppierung“ habe ich grad gefunden, wird über nacht live geschaltet: Die modernisierte Technik von listPageOptions 4.0 interagierte unter bestimmten Umständen mit dem Einklappmechanismus der seitenbezogenen Gruppierung und damit wurde zu heftig ausgeblendet; dies ist beseitigt.
Was den Button mit dem roten X angeht, so besuche doch mal Spezial:Helferlein und prüfe deine Wünsche zum „komprimierten Optionsblock“; zwei Steuerungsmöglichkeiten.
Die Helferleins habe ich besucht, dort geänderte Einstellungen scheinen sich aber nicht auszuwirken. Vielleicht warten wir einfach mal, bis morgen der Fix live ist.--Mabschaaf14:31, 23. Jan. 2015 (CET)
Ich würde jetzt nicht behaupten wollen, dass ich alles verstanden habe, was ich gemacht habe, aber ich bin einen sichereren Weg gegangen und nun müsste es fluppen.
Ich kapiere nicht, warum es von der Festplatte in meiner Erprobung funktioniert und von der Website nicht, aber ich konnte in einer simulierten Umgebung das Problem dann doch reproduzieren und abfangen.
Es scheint etwas mit parallelen zeitlichen Abläufen zu tun gehabt zu haben, und meine Festplatte war immer schneller.
Hm. Einen Schritt weiter, aber wohl noch nicht am Ziel:
Ich sehe jetzt die Abfrage "Mehrere Einträge (ein) | Seitenbezogene Gruppierung (aus) | Besuchte Seiten:" und den Button "einblenden/ausblenden" wieder.
Dort auf ausblenden geklickt, wirkt - bis zum nächsten Aufruf der Beo, dann ist alles wieder eingeblendet, aber der Button ist noch mit "einblenden" beschriftet.
Klick 1 auf den Button wechselt die Beschriftung zu "ausblenden", Klick 2 tut selbiges dann - bis zum nächsten Aufruf der Beo...
Ja, seitenbezogene Gruppierung war aktiv. Gleiches Verhalten nach Deaktivierung.
Ich wundere mich noch immer über | Besuchte Seiten: ./. - Da scheint wohl irgendetwas zu fehlen.
sonst nach wie vor das um 10:54 beschriebene Verhalten mit einem/zwei Klicks; unter Helferleins: "Zusatz-Link; Vorgabe: besuchte ausblenden" aktiviert.--Mabschaaf13:27, 24. Jan. 2015 (CET)
Es sind mehrere Themen, ich sortiere mal:
Die Spezialseiten-Option für [X] lautet „Zusätzliche Knöpfe: Ein- und Ausblenden des Optionsblocks“.
Besuchte Seiten: ./. bedeutet: In der momentanen Auswahl gibt es keine von dir bereits besuchten Seiten, die aus- und eingeblendet werden können. Dann gibt es das ./. statt Button.
Das Merken des vorhrigen Zustands geschieht über ein spezielles Browser-Gedächtnis: sessionStorage – möglicherweise hakt das bei dir.
Nachts werde ich versuchen, deine Konstellation nachzubauen; vielleicht gewinne ich wieder Erkenntnisse.
Ggf. bekommst du sonst ein Link auf ein testwiki mit einer Diagnostik-Version, die Zustände mit dazuschreibt.
Das ./. deutet für mich darauf hin, dass es irgendwo hakt. Es gibt ja besuchte Seiten, die auch ganz richtig nicht mehr fett dargestellt werden - nur eben nicht komplett ausgeblendet.
Ich konnte mit keinerlei Tricks reproduzieren die folgende Schilderung von oben:
Dort auf ausblenden geklickt, wirkt - bis zum nächsten Aufruf der Beo, dann ist alles wieder eingeblendet, aber der Button ist noch mit "einblenden" beschriftet.
Klick 1 auf den Button wechselt die Beschriftung zu "ausblenden", Klick 2 tut selbiges dann - bis zum nächsten Aufruf der Beo...
Ich kann mir eine Fehlersituation vorstellen, die dieses Verhalten bewirken würde:
Beim Seitenaufbau wird die Ausblendung nicht wirksam, obwohl sie angestoßen wurde und der Knopf auch passend beschriftet ist. Beides passiert im selben Arbeitsgang.
Das Skript glaubt somit, die entsprechenden Zeilen wären unsichtbar, und verhält sich entsprechend.
Zur weiteren Aufklärung bräuchte ich folgende Information:
Ist das im Modus „Seitenbezogene Gruppierung“ beschriebene Verhalten im Normalmodus genauso?
Daraus könnte ich wenigstens ableiten, in welcher Ecke das Problem stecken muss.
Dann kann ich in einer privaten Sonderausgabe Tracking-Informationen anzeigen.
Die Einstellung bei "Seitenbezogene Gruppierung" hat (ebenso wie bei "Mehrere Einträge") keine Änderung des beschriebenen Verhaltens zur Folge.
Ja, Deine Vermutung, dass das Skript meint, die Zeilen wären unsichtbar und deshalb mit einen Knopf mit "einblenden" anbietet, scheint für mich richtig.
Keine Ahnung, ob es irgendeinen Zusammenhang gibt: Schalte ich "Seitenbezogene Gruppierung" aus, sehe ich Wikidata-Änderungen, ist die Gruppierung auf "ein", sehe ich diese nicht.
@PerfektesChaos: Solltest Du daran geschraubt haben: Die Drehung ging in die richtige Richtung. Die besuchten Seiten werden nun ausgeblendet, allerdings scheint mir die letzte Zeile der "Anzeigeoptionen" noch fehlerheft - dort steht nur noch: | | Besuchte Seiten: Einblenden
Die Auslösung, dass ausgeblendet werden soll, war in der Konstellation unerreichbar gewesen, weil einer der beteiligten Schalter hinter einer Hürde lag, über die von allein nicht zu gelangen war.
Die Funktionen sind wohl alle okay und funktionieren teils seit Jahren.
Das Problem sind die Steuerparameter, mit denen sie eingeschaltet werden, und die kaskadiered wiken:
Wenn es eine JS-Vorgabe gibt, nimm die als Grundlage.
Wenn auf Spezial:Helferlein etwas eingestellt wurde, dann verändere auf dieser Basis die Vorgabe für Sitzungen.
Wenn in dieser Browser-Sitzung und speziell in diesem Tab bereits etwas ausgewählt wurde, dann ist das die Grundlage für den nächsten Seitenaufbau.
Hinzu kommt, dass möglichst schnell und effizient gearbeitet werden soll, und nur solche Analysen der Seite passieren sollen, die anhand der Steuerparameter auch wirklich benötigtwerden.
Bei mir läuft das alles fundamental anders als beim Normalanwender.
Um den zu simulieren, mus ich mich immer künstlich dumm machen und meine privaten Tricks deaktivieren. Die wirken aber global und auch auf Beta.
Als IP hätte ich keine Beo.
Ich mache in der nächsten Zeit einen neuen Anlauf, um das [X] für alle wiederzufinden; ich selbst hatte immer eins.
Vorlagenmeister um Autofilling-Funktion erweiterbar?
Letzter Kommentar: vor 9 Jahren12 Kommentare3 Personen sind an der Diskussion beteiligt
Kürzlich bin ich auf die RefToolbar der en.WP gestoßen. Mir hat es vor allem das Autofilling-Feature angetan: Einfach DOI, PMID oder ISBN eingeben, auf das Lupensymbol klicken und die übrigen Daten werden automatisch ergänzt. Wäre es möglich, den Vorlagenmeister mit einer solchen Funktion für die Vorlagen Internetquelle und Literatur auszustatten? Von Programmieren habe ich leider keinen blassen Schimmer, aber vlt. findet sich wer, der diese Funktion einbauen könnte? --Ak ccm (Diskussion) 21:49, 1. Feb. 2015 (CET)
Der Vorlagenmeister lebt nur innerhalb der Wiki-Seite und hat keinen Kontakt zur Außenwelt.
Das klingt eher danach, als ob du mit dem (dieser Tage leider kaputten) Wikipedia:LT/isbn2wiki glücklicher würdest.
reftag geht so ähnlich vor, bezieht seine Daten von einer externen Website http://reftag.appspot.com/ – diese liefert unkontrollierten JS-Code zurück, der dann hier beim Benutzer ausgeführt wird.
Aus Sicherheitsgründen würde dieses Dingens deshalb niemals bei uns ein offizielles Gadget werden.
Wenn wir überhaupt Code von einer anderen Website ausführen würden, dann nur solchen auf Wikipedia:LT und nur bei Offenlegung sämtlicher Codes und Wirkmechanismen.
Die en:Wikipedia:RefToolbar/2.0 verschweigt völlig die Funktionsweise, erwähnt das Sicherheitsleck mit keiner Silbe und täuscht die Anwender; das ist keine vertrauenerweckende Dokumentation. Erst Durchwühlen der Quellcodes förderte den Mechanismus zutage.
Danke für Dein Statement. Unterm Strich wird der VM auch künftig keinen Kontakt zur Außenwelt aufnehmen?
In Deinem Link bin ich auf dieses Tool gestoßen. Ich fände es sehr praktisch, wenn es das auch für die Vorlage Literatur gäbe. Wahlweise mit Eingabe der DOI, ISBN und PMID. Und die Ausgabe des kompletten ref-tags ohne die seltsame Formatierung (Absatz, fett). --Ak ccm (Diskussion) 08:09, 2. Feb. 2015 (CET)
Der VM wird nur von außen per XML/TemplateData bedient und keinen inhaltlichen Kontakt zu spezifischen Vorlagen und Informationstypen aufbauen.
Der eben von dir genannte Link doiweb.py ist der sichere und günstigere Weg: Eine externe Website baut den Kontakt zu äußeren Informationsquellen auf und präsentiert Wikitext zum Kopieren. Dabei wird kein Automatismus geschaffen, es kann kein unerwünschter JS-Code unbemerkt und später nicht nachvollziehbar ausgeführt werden.
Der Wiki-Seite und jeder anderen HTML-Seite im Browser wird es aus Sicherheitsgründen vom Browser verboten, Kontakt zu wildfremden Websites aufzunehmen; aus diesem Grund ist wmflabs.org auch eine eigenständige Domain, deren von irgendwelchen Chaoten programmierte Tools nicht in die Wiki-Seiten der WMF einwirken dürfen.
Die Idee ist bekannt; mehrere Ansätze auf Wikipedia:LT waren mal im Gespräch, vielleicht baut das ja mal jemand robust aus.
Dabei muss aus den externen Datenbanken, egal über welchen Identifizierer angewählt, ein neutrales Format Autor(vor|nachname[n]), Titel, TitelErg, Veröffentlichkeitsdatum usw. als Datensatz gewonnen werden.
Danach muss für die jeweilige Projektumgebung angeboten werden, das in die dort geeignete Vorlage (oder gelegentlich mehrere?) zu übernehmen; auch im Format „ein Wert pro Zeile“ oder alles kompakt in einer Zeile.
Dabei muss für jede Vorlage jedes Wikis der neutrale Datensatz übertragen werden in eine nach und nach zu registrierende Vielfalt an Einbindungssyntax, indem die Felder des Datensatzes in Platzhalter wie {{{title}}} geschrieben werden; etwa für
Die momentane Implementierung dort müsste mal die HTML-Tags aus ihren Ergebnissen filtern; dann ist das nicht mehr Fettschrift und Absatz. Wobei ein <em> in der Biologie eine wissenschaftliche Bedeutung hat und in unsere Apostrophe '' zu übersetzen wäre. Ist halt doch eine größere Herausforderung und braucht mehr Hintergrundwissen als mal eben so ein paar Zeilen runterzuhacken.
Danke für den Link – habe ihn gleich mal in die Linkbox des WikiProjekts Pilze aufgenommen. Weißt Du, wie man den Autor des Webtools kontaktieren kann? Wäre es nicht wünschenswert, das Ganze auf Tool Labs statt auf dem Webserver eines Handballvereins zu hosten, um das Webtool langfristig zu sichern? Zur Absatz-Fett-Formatierung der erzeugten Referenz noch ein Gedanke: Gibt es vlt. neue Regeln, dass Referenzen entsprechend zu formatieren sind? Vielleicht bin ich nicht auf dem Laufenden... --Ak ccm (Diskussion) 00:31, 3. Feb. 2015 (CET)
Nein; und wenn, dann wären es welche aus der enWP. Es ist aber auch Unfug, denn der Absatz würde auch dort die Formatierung zerreißen. Das ist schlicht unausgereift.
mw:Citoid ist mir bekannt. An #RefToolbar schreibe aber bitte auch den Hinweis dran, dass dieses Tool heimlich Kontakt zu einer externen Website außerhalb der WMF aufnimmt, dadurch die Möglichkeit hat, die Zuordnung von der IP zum Benutzernamen festzustellen sowie die E-Mail-Adresse des Anwenders und seine Beobachtungsliste auszulesen; falls sysop/CU/OS, dann weitere verdeckte Einsichtnahmen vorzunehmen; falls es sich nicht auf heimliche Ausspähung beschränken möchte, auch im Namen des Anwenders zu einem späteren Zeitpunkt beliebige Aktionen auszuführen. Wie man so einen Mist zum empfohlenen Gadget machen kann und jeden Hinweis auf das Sicherheitsproblem totschweigt, ist mir schleierhaft; aber auf der enWP gibt es sehr unterschiedliche Qualitäten und Kompetenzen. VG --PerfektesChaos19:16, 8. Feb. 2015 (CET)
Ja, für Leser, die JavaScript aktiviert haben, ist vieles möglich, das auch recht robust programmiert werden könnte.
Die Hauptseite könnte mit einem halbdurchsichtigen Grauschleier überzogen werden, der zwei Buttons offeriert, einen zum Entfernen des Grauschleiers und ein Link zu Infomaterial, bis hin zur automatischen Weiterleitung dorthin nach einer Minute.
Über ein Cookie kann man sich merken, wie oft dieser Leser in dieser Sitzung bereits verschleiert wurde, und den Spaß auf drei Besuche begrenzen.
Alle Miniaturbilder können mit einem Grauschleier überlagert werden, der eine Protestinformation enthält und verlinkt. Kriegt man gar nicht weg, entweder Miniaturbild ganz normal zur Dateibeschreibungsseite/Medienbetrachter vergrößern oder grau gucken.
In den Medienbetrachter könnte man im Prinzip ein Banner einfügen; weil der aber sowieso schon den ganzen Bildschirm einnimmt, könnte es ein Platzgerangel geben, und der funkt ohnehin aktiv dazwischen.
Angemeldete Wikipedianer können die Aktion per Gadget-Häkchen abschalten.
Letzter Kommentar: vor 9 Jahren15 Kommentare8 Personen sind an der Diskussion beteiligt
Ich möchte folgenden Teil deiner Signatur (Show some WIKILOVE) entfärben, so dass die entsprechenden Diskussionsseiten besser lesbar sind. Der Code
/* Ignorieren von farbigen Signaturen */a[href*="Benutzer:"]:link*,a[href*="Benutzer_Diskussion:"]:link*,a[href*="Benutzer:"]:visited*,a[href*="Benutzer_Diskussion:"]:visited*{color:inherit!important;}
in meiner monobook.css hilft in diesem Fall nicht. Was muss geändert werden, damit es klappt? --Leyo01:59, 10. Jul. 2015 (CEST)
Das dürfte mEn nicht möglich sein, da der style-Parameter wichtiger als alles andere ist. Unabhängig davon: Der gezeigte Beispieltext verlinkt nicht auf den Benutzer- sodern auf den Wikipedia-Namensraum. Mit wem sprichst du eigentlich? ;-) --nenntmichruhigip (Diskussion) 02:12, 10. Jul. 2015 (CEST)
Ja, stimmt natürlich. Daran habe ich gar nicht gedacht. Ginge es vielleicht, wenn ich WP:Wikiliebe explizit angebe? --Leyo02:17, 10. Jul. 2015 (CEST)
Die Berücksichtigungsreihenfolge lautet:
CSS-Seite
style= im Element
CSS-Seite mit !important
Leyos Ansatz war deshalb völlig korrekt.
Benutzer können in ihrer Signatur weder :link noch :visited beeinflussen. Es genügt daher eine Angabe für den Link allgemein.
Die Intention des Wunsches würde wie folgt erfüllt werden:
Danke! Wären vom Entfetten auch die fetten BD-Links auf der entsprechenden BD betroffen? Oder sind diese für CSS gar keine Links mehr? --Leyo11:22, 10. Jul. 2015 (CEST)
Damit meinst du den Umstand, dass jemand auf seiner eigenen BD unterschreibt, und seine BD verlinkt hat.
Sind in der Tat schon keine Links mehr.
.ns-3strong.selflink{display:none;}
Im NR 3 kann .selflink nur auf den Benutzer selbst zutreffen, und bei der Standardsignatur steht dort in Klammern das Wort „Diskussion“, was einen jetzt nicht so arg weiterbringt, oder sonstiger Quark.
Weg damit; notfalls bleibt nur der Zeitstempel über.
Vielen, vielen Dank an Leyo für die Initiative und an PerfektesChaos für die Umsetzung. Hab das auch gleich mal übernommen und werde in Zukunft dank euch ein glücklicheres und zufriedeneres Leben n Harmonie und Ruhe führen ;). --YMS (Diskussion) 13:39, 10. Jul. 2015 (CEST)
@Doc Taxon: Das ist die falsche Schlussfolgerung. Nur könntest Du den Link so gestalten, dass er bei weniger Benutzern Augenkrebs auslöst. Ich gehe davon aus, dass Du das MB zur Signaturgestaltung kennst. Du bewegst Dich zwar innerhalb dessen Zulässigkeit, solltest aber zur Kenntnis nehmen, dass es auch bei den anderen beiden Abstimmungsoptionen viele Contra-Stimmen gab, sich also offenbar viele Benutzer gestört fühlen. Und "Liebe" durch "stören" zu erreichen, halte ich für - nunja - zumindest sportlich.--Mabschaaf14:17, 10. Jul. 2015 (CEST)
Die richtige Schlussfolgerung mag ich mir nicht vorstellen: der fette rote schattige Text müsste wegen der immensen Bedeutung der Liebe um den Faktor zehn vergößert werden, Doc Taxon. --Holmium(d)14:57, 10. Jul. 2015 (CEST)
Wenn man es ganz streng nimmt, dann bewegt er sich im verboten Bereich. Unter Punkt "Rahmen und abweichende farbliche Gestaltung des Hintergrundes" fällt nämlich auch text-shadow. Durch die Verwendung des Bildes aber hat er das jetzt wieder ausgehebelt/umgangen, auch wenn das sichtbare Ergebnis das gleiche ist. Der Umherirrende21:37, 10. Jul. 2015 (CEST)
Letzter Kommentar: vor 9 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo,
die Seite www.wikipedia.de hat seit letzter Woche folgenden Inhalt:
"It works!
This is the default web page for this server.
The web server software is running but no content has been added, yet."
Zuvor war hier eine Art Startseite u.a. mit Verlinkung zu den wikipedias der in Deutschland gesprochenen Sprachen.
Auch wenn de.wikipedia.org die eigentliche Startseite der deutschsprachigen wikipedia ist, wäre es gut, wenn die Verlinkung wieder funktionieren würde.
Ich bedanke mich vorab.
Beste Grüße
--RasAndi (Diskussion) 12:12, 20. Jul. 2015 (CEST)
@Wolfgang Rieger: Es können dort maximal 255 Bytes eingegeben werden, weil auch nur diese Länge in der Datenbank gespeichert werden kann. Dies hat sich aber in der Vergangenheit nicht geändert. Wie viele Zeichen bekommst du rein? (Einfach 1234567890 einfügen bis nichts mehr geht und dann die Blöcke zählen) Der Umherirrende11:26, 11. Aug. 2015 (CEST)
Ok. Ich kann das nicht mehr reproduzieren. Ich vermute, es fiel mir beim Kopieren einer vermeintlich kurzen SLA-Begründung auf, bei der die Signatur irgendwelchen langen Kokolores enthielt. Danke für Deine Antwort. -- Wolfgang Rieger(Diskussion)11:33, 11. Aug. 2015 (CEST)
Wiki labels & Revision Scoring as a Service for German Wikipedia
Letzter Kommentar: vor 9 Jahren24 Kommentare6 Personen sind an der Diskussion beteiligt
Hello German Wikipedia,
I apologize for my complete lack of German skills. I would most welcome if my post is translated to German.
So computers are very good at crunching numbers. Your average calculator can out smart you in arithmetic. However computers are terrible at pretty much in everything else. Programming computers to under take any task no matter how simple beyond computing tends to be very difficult. This is where Artificial Intelligence comes in. With Artificial Intelligence we teach computers how to solve problems without explicit programming for the solution. This is what we are doing.
We are working on a project called m:Research:Revision scoring as a service which aims to provide quality control Artificial Intelligence infrastructure for Mediawiki and Wikimedia projects. We already have our system implemented and running on Azerbaijani, English, French, Indonesian, Persian, Portuguese, Spanish, Turkish and Vietnamese editions on Wikipedia. We are hoping to adapt our tool to serve German language as well as a number of other languages.
We are currently mainly focusing on vandalism detection where we provide an API (m:ORES) that provides scores. We have made an effort to keep our system robust.
The examples I'll provide are based on a machine learning algorithm that was trained to use 20,000 reverted edits. This is kind of modelling is problematic for two reasons. First is, there are non-vandalism related reasons for edits to be reverted such as mistakes from new users, this would develop such an unproductive bias. Second problem would be it lacks the ability to distinguish good faith users from malicious ones. To demonstrate our system I will give three examples from English wikipedia. I have picked these three semi-random.
As visible in the diff, it is clearly something that shouldn't be welcome on English wikipedia. Algorithms confidence also matches my human assessment.
When I look at the diff it isn't immediately clear to me if this should be reverted. Detailed look reveals that prior version had more neutral information, but new version at a glance isn't exactly clear cut vandalism, albeit spammy. Algorithms confidence drops just as my human assessment.
As visible in the diff this edit clearly improves the article. The algorithms confidence plummets as well. Algorithm is more confident that this edit should NOT be reveted.
We are also working towards a system for article quality where we use existing assessment by en:Wikipedia:Version 1.0 Editorial Teamto train our system. We only have this system on English wikipedia at the moment but we would be more than happy to expand to other language editions. I am uncertain if German Wikipedia has a similar quality assessment scale. I have picked 5 random articles to demonstrate this.
Typical problem is that humans typically do not re-asses articles over time or articles are never assessed in the first place. Our system circumvents this problem by automating this.
We would like to start an edit quality campaign where we request the local community to hand code/label ~2000 revisions labeling them productive/damaging and good faith/bad faith. This would be similar to the campaign on English Wikipedia en:Wikipedia:Labels/Edit quality.
After this we will be able to generate scores for revisions that is usable by gadgets such as ScoredRevisions as well as (potentially) tools like huggle. If community desires it, it can even be used to create a local vandalism reversion bot.
So in a nutshell our algorithm relies on community input to support the community. Feel free to ask any questions. Either here, on meta or on IRC on the freenode server and #wikimedia-ai channel where we hang out. You can also reach us at https://github.com/wiki-ai
English is a diminishing problem and does not matter on this VPT.
That project has been deleted from official project space in German Wikipedia due to supporting and encouraging a broad field of misuse, e.g. anonymous denigration, defamation, hounding and stalking, and complete lack of any counter measures and responsibility for the libellers and slanderers, nor any possibility for blackened users to defend themselves against invalid accusations.
To deal with this project on German Wikipedia you are to file an official poll (Wikipedia:MB), disclosing social impacts and providing transparency over squealers as well as current user scoring causes. And telling the real targets, not a lulling story pretending research. I dare to predict that any kind of automation as described above will be rejected by a wide majority.
Until such a poll succeeded, any use of this tool and its results is prohibited on German Wikipedia.
Our RC and edit approval people prefer human stupidity over artificial intelligence. Since we are using flagged revisions there is no need for such a system on German Wikipedia, especially no “ScoredRevisions” or “a local vandalism reversion bot”. The latter would never ever get a botflag here.
The labeling of a mud-slinging tool as “research” reminds me to declare whale slaughtering for serving dinner tables as “research” and the declared necessity to kill whales in order to count their cadavers properly for reliable scientific population statistics.
PerfektesChaos your assessment is the complete opposite of what we are doing. We merely support scores for your local consumption and make no actual edits of any kind. We are completely uninterested in running bots themselves on any wiki. We are more interested in gathering feedback to create models on what good faith edits, vandalism, and newbie mistakes look like on German Wikipedia. I do not understand what you mean by a poll to be honest. We'd rather be serving communities interested in our work and we will simply ignore and skip communities that do not want it. -- とある白い猫chi?13:28, 17. Aug. 2015 (CEST)
Well, where is the point in an edit rating system if no bot uses it? A human can do the same rating much more accurately if the edit has to be checked manually anyway. Introducing such a bot would need a large majority in a poll, which is unlikely (my personal guess).
We do not have an article rating system, so automatic classifications of articles would not be used anyway. Again, the introduction of such a system would need a poll. --mfb (Diskussion) 13:53, 17. Aug. 2015 (CEST)
Of course you do :). German Wikipedia has 4 classes for article assessment. Stub articles (which are deleted), regular articles, a good article equivalent and a feature article equivalent. Our system can triage that too. For instance it can generate a list of regular articles that need human review since they are almost good article quality. Or perhaps the code can detect stub articles that need to be deleted per how German Wikipedia operates. Maybe edits to a featured article over the past year has actually reduced quality and the article needs some more work. So bot would triage the work of humans in all such cases. Think of it as a sorted backlog than a chaotic one.
As for vandalism detection, above I had shown examples of how the tool would triage it. An edit that is very likely to be damaging but also very likely to be in bad faith can be quickly reverted and people making such edits quickly blocked. Whereas an edit that is very damaging but was done in good faith can be dealt with differently since it is a newbie mistake. This way you have a way to identify new users that are having difficulties and they can be taught to be more productive users.
Using scores provided by our system tools like huggle would provide better results and even tools such as ScoredRevisions (which is a simple javascript+CSS hack that colors bad revisions red etc) would provide feedback to RC patrollers to triage their work.
The requirements for "good" articles here are much higher than in the English wikipedia. In particular, the content has to be good, something the bot cannot check properly. Both candidates for GA and FA have to be nominated in the way the English wikipedia handles nominations for FA (only).
Yes, different types of edits can be handled in a different way, but where is the advantage of some automatic rating if a human has to check the diff anyway? To make it worse, humans might rely on that rating too much. Is the change of a single number vandalism (likely) or an actual fix (possible)? If the rating is "probably vandalism", an editor is even more likely to revert it without thinking about the plausibility of the edit.
Deletion discussions are nearly always about notability, sometimes about how to distribute topics between articles - I doubt a script can assess this properly. All new articles have to get approved via the flagged revision system - incomplete or poorly formatted articles get improved or deleted before that happens. --mfb (Diskussion) 17:34, 17. Aug. 2015 (CEST)
What a good article is and what a featured article is will be trained on local (German Wikipedia) criteria. I gave English wikipedia terms due to my lack of familiarity with local equivalents. We are very good at predicting article class on English wikipedia when there is more room for error (with wider range of assessments). We would like to see how well we perform here on German wikipedia. If we end up with something of an acceptable accuracy then local community may chose to use it. If we fail in that regard that means we need to work harder. All that matters for us is if we are going to be of use to the community we serve. We do not intend to give the community even more work.
The advantage is to triage the workload. Deal with obvious cases first and then look into less obvious ones. Personally speaking, I would ignore edits that have a very high score of good faith and very low score of damaging. I would also look into edits with a high score in damage and also a high score in good faith. There I would expect to see new users making mistakes. You can also think of it this way, our scores would be for example usable by Wikipedia:Huggle so that it is more accurate than it is right now. This is because we do not want to provide a simple score of "Vandalism or not", we have two scales: Damaging/Productive and Good Faith/Bad Faith.
Artificial Intelligence can certainly outperform people for such tasks. This isn't a simple script. It would give an indication of where an article is. It can give suggestions to triage the workload of a backlog. For example, if AI detects than an article is poorly formatted then it would flag it as such for human review. It would do this for say 10 out of 100 articles that are in new article review. So if users are only interested in fixing formatting they would review those 10 articles instead of the 90 the users wouldn't be interested in.
The English system is easier to predict for a script - while I know that the system is more complicated, just looking at the amount of text is probably a reasonable estimate already. You can ask for volunteers, sure, I just don't expect a helpful result. I left a note on our GA/FA discussion page.
How does it help to look at obvious cases first and others later? We have to look at all of them. The system here does not allow to ignore edits because the revision has to get flagged (or reverted) at some point. Okay, users looking specifically for new users that need help would probably profit from it. I notified our vandalism fight project. --mfb (Diskussion) 22:31, 17. Aug. 2015 (CEST)
For article assessment we will use the existing assessments to train and do not expect any volunteer work to get results. We rely on a wide range of content features and at some point we will work with natural language processing where AI would look semantically at the meaning/context of the content to determine an assessment. For instance think of it generating a list of articles that look like GA quality but haven't had human review yet. It would give people interested in say article
We intend to centralize AI aspects of all tools. German Wikipedia uses huggle which does exactly that. It uses complicated static rules that get outdated over time. You would spend less time on more obvious cases and more time on less obvious cases. If someone only adds the word penis 20 times into an article the decision to cast there is fairly obvious. If someone accidentally removes a |} while adding other content then it will probably take a little more time dealing with that. For instance the person making such an edit could be a new user that is making an honest mistake. Indeed,this would be helpful if you only want to deal with new users making mistakes. It would be counter productive to give good faith users a "WARNING VANDALISM OMG STOP" kind of a warning which could discourage them from contributing any further. Also, at some point the community may decide to let bot handle revisions with a score higher than 99% (%99 bad faith, 99% damaging) assuming the community gains confidence in the AI predictions. That however would be a discussion months to perhaps years from now (that is assuming if it ever happens).
These two are our starting point. We hope to help communities triage other backlogs as well. Artificial Intelligence is a very powerful field of computer science. What we handle is the AI end of things which reuire expertise and resources so that actual tool developers (people who write and/or operate bots) do not have to worry about it.
I don't see time saved if we go from "1 second Penis revert -> 10 seconds content change -> 1 second penis revert -> 10 second content change" to "1 second penis revert -> 1 second penis revert -> 10 seconds content change -> 10 seconds content change". Users giving a vandalism warning for obvious good faith edits will do that with or without additional tool - it is wrong in both cases.
Anyway: What are your specific plans? Installing gadgets here won't work without more discussion, but if your tool to get 2000 ratings can run externally (and/or based on the English wikipedia) and you just have to ask for volunteers: that is easy. Prepare a text, we can translate it. Wikipedia:Kurier ("Signpost") and Wikipedia:Fragen zur Wikipedia ("Help desk") are good places to post it. --mfb (Diskussion) 16:49, 18. Aug. 2015 (CEST)
Users giving a vandalism warning for obvious good faith edits do so because they lack a tool telling them that the revision is in good faith. Huggle is moving in this direction but it lacks a model that is usable on German Wikipedia. So even if the code exists, without a good model it will not be accurate. Our system can predict intent which has not been done before.
The gadget is already installed in a userspace and is fully usable. It being in project space or some other namespace isn't that important since it runs externally and does not modify content in any way. What we need and care about is volunteers from German Wikipedia to handcode last years revisions from German Wikipedia. The gadget will merely record handcoding of participating users where they mark if a revision is in good faith/bad faith and separately if it is damaging or productive. Mind that we do not have a campaign running at the moment and therefore the gadget isn't doing anything. I cannot imagine what else is there to discuss beyond that for wikilabels.
I would appreciate if the initial post I have above can be translated to German so that we can gather a more informed decision by the wider community.
"Users giving a vandalism warning for obvious good faith edits do so because they lack a tool telling them that the revision is in good faith" -> citation needed.
The initial post is not focused on the 2000 revisions you want to have flagged and it does not tell the users how and where they can help. Don't worry about language, the vast majority here understands English well enough to follow the discussion. --mfb (Diskussion) 22:47, 18. Aug. 2015 (CEST)
How can I cite the absence of said tool? It doesn't exist which is why we are working on it.
Initial post focuses on the bigger picture we are aiming for. First task is to create a library of bad words, informal words and common words. This has been done already at Wikimania 2015 where our work has made its way to Lila Tretikov's keynote. The second task is a localization of wikilabels so that people looking into our project can understand what it is about and how they can help. This was done earlier in Wikimedia Hackathon 2015 where our project had a live demo for French Wikipedia during the showcase.
I will post something on the two pages you mentioned in English pointing them here. I think this will be better since I'd rather not have multiple parallel discussions.
Your tool page has been deleted from project namespace by sysop decision.
The reason was that you do not consider misuse capabilities and no precautions are taken to defend against malicious usage, also complete lack of transparency and trusted supervisor board.
Any editor using that tool for reverting etc. takes the risk to be blocked until usage has been approved by this community.
This community has its own tools and practices for quality assessment and vandalism fighting.
No additional maintenance list is needed created by an algorithm which has the opinion that a certain article might be improved if there are neither human capabilities nor enthusiasm to work down such a machine-generated list and to follow your recommendations for improvement. And we keep our featured articles on the screen ourselves.
Regarding vandalism I just told you that we prefer human stupidity over artificial intelligence. Our RC and edit approval people are already able to judge over the quality of the edit of an unknown or newbie author, and every article edit of less well known users is presented for review by experienced editors before published. German wikipedia invented and triggered development of flagged revisions ten years ago. Just log out, make a vandalism edit on any article, e.g. change the birthday of Emperor Hirohito, view the displayed article how it has been affected by your edit immediately, and check the page history an hour later.
Before you did not launch a poll and successfully persuaded this community there is no reason to discuss anything any longer.
This is a page on technical problems, like en:WP:VPT. You are not bringing up a software issue, please leave this workshop talk now.
Our tool has never been on this project. Our landing page was which does not perform any work on its own. It merely exists on what we do.
We do take misuse of capabilities very seriously and we do take precautions against misuse. Our code is completely open sourced, our work is logged on a public phabricator. You do not get more transparency than that. We will outright reject any kind of board dictating what we can and cannot do. We exist to serve communities, we will honor their requests to the best of our abilities however we will NOT be bossed around by any board.
This tool (wikilabels) is incapable of reverting anything. This tool only collects information to determine what vandalism looks like and what good faith/bad faith looks like on German wikipedia.
One of those is Huggle which can use our scores to have more accurate results. Maintainers of huggle and us have been in discussion on how to integrate revision scoring into huggle.
We do not intend to create machine generated lists for the community to follow. We merely provide scores. If the community decides to not use them then that's that.
Fine, that was just an example where we could help. Given how you have decided our help isn't needed we will not work on that.
Your wiki uses huggle. Huggle has a set of very difficult to maintain rules. Artificial Intelligence has a self learning nature where it improves over time where as static rules never do.
We will not oppose such a poll, we will not start one either. That is for the community to decide. We are here at the pleasure of the community. If we are asked to ignore German wikipedia, we will. We have 290 other language editions of Wikipedia to worry about if this one is uninterested.
You are trying to ban something that will not in any way modify the wiki under the pretense that it will. You are misleading the community.
Hello WhiteCat/とある白い猫, so you want german volunteers to handcode 20.000(?) old/past edits to train your revision scoring service with this dataset, i get that. Your documentation page is now at Benutzer:Distelfinck/WikiProjekt_Kennzeichnung/Über and half translated. Given the needed investment of volunteer time and effort, the question is what is the point, the benefit of this for dewiki? With regard inclusion to Wikipedia:Huggle, Huggle is controversial in dewiki already as it is. Making huggle even more automatic /bot-like is obviously controversial. But, huggle seems to be of limited usage in dewiki anyway (the real action is at flagged revisions/gesichtete Versionen with thousands of reviewers). What is number of huggle-edits per month at dewiki? There are 100 Wikipedia:Huggle/Users, but how many of them are active last month? Do we have stats on hugglers, via edit-tags or quarry? --Atlasowa (Diskussion) 23:57, 18. Aug. 2015 (CEST)
Actually we will automatically handcode 18,000 of the workload so community would deal with something around 2,000 revisions. Using the combined 20,000 random revisions we would generate a model usable by various tools. This would give us a machine readable example 20,000 revisions to train machine learning classifiers which would tell the machine how good edits, vandalism and mistakes look like. Using this we generate scores. Our goal is to let tool developers to use these tools to their hearts content based on community needs. Using wikilabels we can also model solutions to different backlogs so our work by far isn't limited to the examples here. All that matter is community needs. Give us a complicated problem, and we will see how AI could make it better. :)
The idea here is not to make huggle more bot like, it is to make huggle more accurate using rules fine tuned for German Wikipedia's needs. I would suggest using a piece of code for dealing with RC feed called ScoredRevisions on English Wikipedia to see our scores in action. Just add the following JavaScript snippet to your global.js loader script. Instead of reviewing every revision with ScoredRevisions you can triage and choose to only review the colored ones. It isn't as accurate as it will be because the labeling campaign hasn't been completed on English wikipedia yet but we are very close.
I do not have huggle usage per wiki at my disposal, however I do know that huggle rules are custom designed for English Wikipedia which is not a good way to approach problems in other languages. -- とある白い猫chi?14:26, 19. Aug. 2015 (CEST)
@ とある白い猫: If you want acceptance on de-WP, you will have to start a poll and get approval (chances = snowball in hell). Otherwise the whole thing is moot. And since this is no technical question anyway, this discussion is off topic here. -- Wolfgang Rieger(Diskussion)02:11, 19. Aug. 2015 (CEST)
I will not start a poll of any kind. That would be an interference in local affairs. I'd be happy for someone else starts a poll and I would be happy to answer questions concerning our project that appear on it. Also I'd rather not want to utilize my time if the community is unwilling to discuss the matter on their own. There exists few things more technical than Artificial Intelligence so I cannot comprehend that argument. -- とある白い猫chi?14:26, 19. Aug. 2015 (CEST)
Letzter Kommentar: vor 9 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo! Beim Aufrufen der Versionsgeschichte einer Seite möchte ich gerne die Interwikilinks dieser Seite in der interwikilink-leiste angezeigt bekommen. PerfektesChaos hat zu viel zu tun, und mir ein paar Brocken hingeworfen, mit denen ich das immer noch nicht hinbekomme. Ich verwende monobook.js. Vielen Dank – Doc Taxon • Diskussion • Wiki-MUC • Wikiliebe?! • 17:19, 18. Aug. 2015 (CEST)
langlinks hat ein "autonoym" und "langcode"-Property, der (falls installiert) die Übersetzungen mitgibt, siehe Spezial:ApiHelp/query+langlinks (llprop: 'url|langcode|autonym', llinlanguagecode: mw.config.get( 'wgUserLanguage' )). Du kannst dann auch "url" setzen und brauchst diese nicht selber zusammenbauen (gerade bei Sprachen mit abweichenden Langcode ist das wichtig). Du brauchst noch die Abhängigkeit auf "mediawiki.util" für das portlet. Der Umherirrende19:27, 22. Aug. 2015 (CEST)
Die Weiterleitung von toolserver auf toollabs wurde glaube ich fürs erste wegen Sicherheitsbedenken abgeschaltet. In der Zwischenzeit: Der hier müsste es sein. – Giftpflanze19:13, 24. Aug. 2015 (CEST)
Writing in English is definitely okay on this VPT, no reason for any excuse.
Thank you for nudging our nose on this system message, since we use the interface in English not very frequently here.
Yes, you might want us to shift to Spezial:Listusers/$1 which is Spezial:Benutzer. (The link is titled “user rights” which sounds like Spezial:Userrights – but that is sysop-only, and we want to show the entry with permissions to everyone)
Hallo zusammen, mindestens seit gestern fehlt bei meinem MediaViewer (auf mehreren Rechnern) sowohl hier als auch auf Commons der blaue Button rechts unten, hier erscheint er manchmal nach mehrfachem klicken auf die leere Stelle spontan. --Ailura (Diskussion) 09:24, 2. Sep. 2015 (CEST)
Letzter Kommentar: vor 9 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Der Artikel hat (zumindest in meinem Browser) in der ersten Zeile eine Zahl "1540" stehen. Sie scheint aus dem in de Infobox angegebenen Durchmesser von 154 zu stammen. Was ist denn da kaputt? Gruß, --Maxus96 (Diskussion) 08:44, 3. Sep. 2015 (CEST)
Geht auf mich. Da gab es ein uraltes Syntaxkonstrukt, das infolge einer kürzlichen Modernisierung schwächelt. Die Zahl hatte schon immer dagestanden, nur war sie bis jetzt unsichtbar gewesen. Das ist eine Murkskonstruktion. Muss ich mal anfangen zu denken. LG --PerfektesChaos09:35, 3. Sep. 2015 (CEST)
Da gab es auch noch zwei Schreibweisen name= und Name=, einen unbekannten Parameter Region=, aber jetzt sollte alles heil sein. Danke für die Info --PerfektesChaos10:25, 3. Sep. 2015 (CEST)
Letzter Kommentar: vor 9 Jahren16 Kommentare3 Personen sind an der Diskussion beteiligt
Seit Kurzem werden bei mir pt-userpage, pt-mytalk und pt-mycontris sowie feed-atom ebenfalls eingefärbt, was ich als störend empfinde. Wie muss ich mein monobook.css (ganz oben) ändern, damit die Einfärbung dort verschwindet? --Leyo23:51, 27. Aug. 2015 (CEST)
Funktioniert das (und analog für andere Links)? #pt-userpage ist das li-Element, die Einfärbung geschieht aber innerhalb beim "a" und muss daher dort auch wieder aufgehoben werden. --mfb (Diskussion) 00:26, 28. Aug. 2015 (CEST)
Ich verstehe gerade (noch?) nicht nicht was mfb meint, aber wenn du das – wie es im Kommentar steht – wirklich nur auf der Beobachtungsliste haben willst schreibe einfach .mw-special-Watchlist #content (mit Leerzeichen dahinter) vor das 'a'. --nenntmichruhigip (Diskussion) 00:36, 28. Aug. 2015 (CEST)
Mit Leyos Code werden auch die Links zur Seite/Disk eingefärbt - egal auf welcher Seite man ist, inklusive Beobachtungsliste. Um die geht es. --mfb (Diskussion) 00:46, 28. Aug. 2015 (CEST)
(Nach BK) Der Code von mfb hat gewirkt, aber etwas „zu gut“. Es wurden gleich alle Links auf meine Disk. (überall) entfärbt. Mir geht es nur um die Entfärbung von <Benutzername>, Diskussion und Beiträge oben rechts sowie um Atom in der Toolbox links. Alles andere soll bleiben wie es ist.
Gut, dann kombinieren: #pt-userpage a[href*="Diskussion:Leyo"] { background: transparent !important; } (ungetestet). --mfb (Diskussion) 01:15, 28. Aug. 2015 (CEST)
Ich habe bei deinem Code #pt-mytalk für die Disk. genommen und gleichzeitig die entsprechende Zeile für die Benutzerseite ergänzt. Jetzt fehlen nur noch zwei, bei welchen ich die Zeilen noch nicht zusammengekriegt habe. --Leyo01:28, 28. Aug. 2015 (CEST)
Falls du es auch ausserhalb der Beobachtungsliste haben willst: Ein #content vor dem restlichen Selektor schränkt es auf den bei Vektor weissen Bereich ein. --nenntmichruhigip (Diskussion) 13:09, 28. Aug. 2015 (CEST)
Ich habe vorhin eine neue Nachricht auf meiner Diskussionsseite erhalten. Die orange Einfärbung von Diskussion fehlt nun auch. Dies ist natürlich wenig sinnvoll, im Gegensatz zum Entfärben der funktionslosen Einfärbungen. --Leyo00:38, 2. Sep. 2015 (CEST)
Mein Vorschlag würde die nicht anfassen ;-) Und auf obige Frage lautet die Antwort natürlich "Ja". Windows hat meine Firefox-Sitzung um eine Woche zurückgeworfen, weshalb ich es vergessen hatte. Falls jetzt jemand vorschlagen will, dass ich Linux nutzen könnte: Ja, mach ich auch eigentlich, aber das ist ein geliehenes Notersatzsystem nach mehreren Hardwaredefekten in letzter Zeit. --nenntmichruhigip (Diskussion) 12:26, 2. Sep. 2015 (CEST)
Doch noch nicht ganz erledigt. @Nenntmichruhigip: Wie ich gerade festgestellt habe, fehlt die Einfärbung nun (logischerweise), wenn ich auf der Beobachtungsliste beim MouseOver auf Versionen im Popups-Fenster. Gibt es da eine Abhilfe, also wie die zweite Zeile angepasst werden müsste? --Leyo11:58, 8. Sep. 2015 (CEST)
Versuch mal den Selektor (also den Teil vor der öffnenden geschweiften Klammer) zu duplizieren (also kopieren, weiterhin vor der Klammer einfügen und Komma zwischen das Kopierte und das Eingefügte) und in einem davon '#content' durch .navpopup zu ersetzen. --nenntmichruhigip (Diskussion) 13:21, 8. Sep. 2015 (CEST)
Es muss nichts mit dem Programmierer zu tun haben. Der hat vielleicht vor einem Jahr zuletzt was an seinem Tool gemacht.
Die Werkzeuge auf Labs bleiben öfters mal hängen, und es dauert immer ein paar Tage, bis jemand zufällig vorbeikommt und sie wieder anstubst.
Wenn ich das richtig deute, dann fehlt dem Labs-Server eine Prozedur, die automatisch nach jedem Update/Hochfahren des Servers und ungefragt einmal pro Stunde alle automatisch arbeitenden Werkzeuge bei Bedarf neu startet.
@PerfektesChaos: Inzwischen funktioniert es einigermaßen zuverlässig, dass der Webserver automatisch neu gestartet wird sobald er abstürzt. Leider wird (noch) nicht überprüft ob der Webserver "hängt". Nur die Maintainer und Tools Admins können den manuell neu starten.
Ein ausgereifte Prozedur, falls ein Tool nicht mehr funktioniert, gibt es leider nicht. Zuallererst würde ich die Maintainer anschreiben und falls diese nicht reagieren auf phab:tag/tool-labs-tools-other/ einen Bug erstellen. Dies haben die Tools Admins im Blick und und sind gerne bereit etwas neu zu starten. Bei tiefergehenden Problemen wie bei kmlexport und unerreichbaren Betreibern oder Maintainer ohne Zeit sagen die Admins aber höchstens wo das Problem vermutlich liegt. Ich hab mal einen Link zu dem Phabricator workboard bei Wikipedia:LT hinzugefügt. Grüße, sitic (Diskussion) 00:17, 13. Jun. 2015 (CEST)
Letzter Kommentar: vor 9 Jahren7 Kommentare5 Personen sind an der Diskussion beteiligt
Hallo,
seit ein paar Tagen habe ich das Problem, dass ich die deutsche Wikipedia über einen älteren Firefox 3 plötzlich nicht mehr erreichen kann, weder als http- noch als https-Version. Wenn ich eine Seite aufrufe, wird diese nicht geladen und die Meldung "Fehler: Verbindung unterbrochen // Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde." angezeigt. Gleich vorweg: Das Problem tritt bei einem modernen Browser nicht auf. Aufgrund eines alten Systems ist der Browser-Wechsel aber schwierig.
Das Problem tritt auch nur bei de.wikipedia.org auf; www.wikipedia.de, en.wikipedia.org und diverse andere *.wikipedia.org-Domains (u.a. auch Plattdeutsch und Bairisch) funktionieren ohne Probleme. Über den Firefox lassen sich bspw. auch keine Zertifikate-Informationen zu der de-Subdomain laden, bei den anderen funktioniert das aber. Da dieser Fehler von einem Tag auf den anderen auftrat, ohne dass ich in meinen Einstellungen irgendwas geändert habe, vermute ich, es wurden serverseitig irgendwelche Änderungen vorgenommen. Außerdem werden pings auf de., en. und fr. nach 91.198.174.192 aufgelöst und sind erfolgreich.
Mich würde nun interessieren, ob es da irgendwelche Änderungen gab bzw. ob/wie sich die Server-Einstellungen der deutschen Wikipedia von denen der anderen irgendwie unterscheiden, um so ggf. über System-/Browser-Einstellungen wieder auf die deutsche Version zugreifen zu können. Über Hinweise, wie ich das Problem näher diagnostizieren könnte, würde ich mich natürlich auch freuen. (nicht signierter Beitrag von94.222.224.131 (Diskussion) 04:08, 20. Jun. 2015 (CEST))
Ich vermute auch, dass es irgendwie daran liegt, die Frage ist halt nur woran genau. Die Hinweise auf der verlinkten Seite helfen leider nicht weiter. Alle dort angegeben Domains funktionieren bei mir über eine verschlüsselte Verbindung, also die verschiedenen Sprach-Wikis ("CA, EL, EN, HE, IT, RU, UG, and ZH"), upload.wikimedia.org und bits.wikimedia.org. Der bisher einzige Fall eines Servers aus dem ganzen Wikimedia-Verbund, zu dem ich keine Verbindung herstellen kann, ist de.wikipedia.org, d.h. irgendwas muss bei dem doch anders sein, als bei den anderen. (nicht signierter Beitrag von94.222.224.131 (Diskussion) 00:32, 21. Jun. 2015 (CEST))
"Mozilla discontinued support for Firefox 3.6 on April 24, 2012". Der Wikipedia-Zugriff sollte das geringere Problem darstellen bei all den Sicherheitslücken die sich inzwischen auf dem System angesammelt haben dürften, und vielleicht wäre eine System-Aktualisierung eine bessere Zeitverwendung als das Problem des Wikipedia-Zugriffs zu diagnostizieren. Ansonsten hat FriedhelmW ja bereits zum Support verlinkt. --Malyacko (Diskussion) 10:32, 22. Jun. 2015 (CEST)
@94.222.224.131
Erstmal bist du hier übrigens an der richtigen Adresse.
Es ist sehr unwahrscheinlich, dass das, was wir hier im Projekt an Einstellungen vorgenommen haben, irgendwelche Skripte oder sowas, etwas mit dem Problem zu tun hat.
Vielmehr sind die Wikis in Gruppen auf physischen Servern zusammengeschaltet, je nach Abrufhäufigkeit, und technisch eigentlich überall gleich.
Wir hier könnten einen eigenen Server haben, vielleicht auch zusammen mit einigen weiteren Subdomains der 1000 Wiki-Projekte der WMF, andere Wikipedien von den hier aufgezählten jedoch andere physische Server.
Das unterscheidet sich auch noch dahingehend, ob man nur etwas liest, und das aus Europa heraus, oder eine Seite ändert. Siehe auch: Wikipedia:Server.
Es wird ein Konfigurationsdetail auf Nginx leicht abweichen, wodurch die Kommunikation zwischen Browser und Server zusammenbricht, gerade in der sensiblen HTTPS-Aushandlung.
Da auf mw:Supported browsers #Firefox als unterstütztes Minimum Version 8 angegeben ist, sehe ich keine Chance für weitere Investigationen, weil jede Anfrage mit Hinweis auf diese Liste sofort geblockt werden würde; insbeondere seitens des Betriebspersonals kein FF3 mehr verfügbar ist, um damit etwas auszuprobieren und die Fehlermeldungen im Log rückzuverfolgen. Ansonsten würde man das Problem detektieren, aufklären und beseitigen wollen.
Vieleicht ruckelt es sich eines Tages zufällig anlässlich eines Server-Neustarts oder Verteilung einer allgemeinen Konfigurationsänderung von selbst zurecht.
Letzter Kommentar: vor 9 Jahren10 Kommentare5 Personen sind an der Diskussion beteiligt
Derzeit ist es so, dass ein gesperrter Benutzer, sofern nicht komplett gesperrt, seine Diskussionseite bearbeiten kann. Kann man nicht auch die Sperrprüfungsseite dazunehmen? Das erspart umständliches Anlegen von SP-Socken und deren Bestätigung. Ist das technisch möglich? MfG --Informationswiedergutmachung (Diskussion) 17:53, 17. Jul. 2015 (CEST)
Nicht ohne Codeänderungen oder mindestens erheblichen Mehraufwand für Admins, fürchte ich. Nicht umsonst gab es mal die Idee, die Sperrprüfung auf der Benutzerdisk zu führen und sie ggf. anderswo einzubinden. --mfb (Diskussion) 18:49, 17. Jul. 2015 (CEST)
Diese Diskussion haben wir alle paar Wochen wieder. Ja, es ist sehr schwer das zu ändern, das ist zumindest die Rückmeldung von den Techies. Obwohl ich es gar nciht so schlecht fände, bei EWs keine Benutzer mehr zu sperren, sondern einfach Regeln festzulegen wie Sperre gilt nicht für diese Seiten oder nur für jene Seiten. Das wär mal was, ist aber eindeutig Zukunftsmusik. --MGChecker – (📞| 📝| ) – HDR00:32, 18. Jul. 2015 (CEST)
Es gibt eine Option "sperren (ohne Benutzerdiskussion)" und eine Option "sperren (inklusive Benutzerdiskussion)". Soweit ich weiß ist es derzeit gar nicht möglich, einem Benutzer einzelne Seiten freizugeben. Aber selbst wenn, müssten Admins das manuell machen -> Mehraufwand. Der Mehraufwand ließe sich nur umgehen, wenn Admins eine Sperroption "sperren (ohne Benutzerdiskussion und SP-Seite)" bekommen, aber das wird vermutlich eine Codeänderung benötigen. Ich denke nicht, dass eine solche Spezialseite derzeit vorgesehen ist. --mfb (Diskussion) 00:46, 18. Jul. 2015 (CEST)
Genau diese Sperroption "Sperren (ohne Benutzerdiskussion und SP-Seite)" meine ich. Geht es vielleicht kurz und allgemein und vor allem fachsprachtechnischfrei, warum beim Sperren ausgerechnet die SP-Seite ein Problem ist? --Informationswiedergutmachung (Diskussion) 00:52, 18. Jul. 2015 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: mfb (Diskussion) 22:47, 12. Sep. 2015 (CEST): Hier ist nichts zu tun, bräuchte Codeänderung die nur für diesen Zweck nicht kommen wird.
Letzter Kommentar: vor 9 Jahren9 Kommentare4 Personen sind an der Diskussion beteiligt
Hi,
wenn man unter Wikipedia:Kandidaturen auf den blauen button "neue Kandidatur anlegen" klickt, kommt folgende Fehlermeldung: "Ungültiger Titel. Der angeforderte Seitentitel enthält ungültige Zeichen: „<“."
Ich habe mal versucht, im Quelltext der Vorlage etwas zu finden aber ehrlich gesagt, meine besten Quelltextzeiten sind schon länger vorbei :-) Wäre nett, wenn mal jemand rüberschaut, vielleicht gibts deshalb so wenig Kandidaturen in letzter Zeit ;-) Viele Grüße Martin Bahmann (Diskussion) 09:50, 3. Sep. 2015 (CEST)
Es steht zwar nirgendwo, aber wer auch immer das so gebaut hat, ging wohl davon aus, dass es offensichtlich ist: <Dein Benutzername> im Eingabefeld obendrüber muss vorher durch den Benutzernamen ersetzt werden. (Und den Standardwert zu ändern ist eher schädlich, denn wenn man die Ersetzung vergisst, ist eine Fehlermeldung besser als eine falsch angelegte Seite.) --Schnark10:57, 3. Sep. 2015 (CEST)
Du kommst aber gar nicht bis dahin.
Das schmiert schon vorher ab, und bietet kein Formularfeld zu Ausfüllen mehr an; du hast also auch keine Chance, es zu berichtigen und den richtigen Namen anzugeben.
Arrgh, du hat recht, das neue Design hat mich in Verbindung mit der obigen Problembeschreibung reingelegt.
Der blaue Button ist so dominierend, dass das harmlose vorausgefüllte Feld dadrüber überhaupt nicht auffällt. Das Eingabefeld ist (anders als früher?) so harmlos, weiß, unscheinbar, dass ich den Zusammenhang nicht wahrnahm.
Es erinnert an die Prozeduren „Neuen Abschnitt anlegen“ usw., wo man erst auf den blauen Button klickt, und danach auf der neuen Seite den Gegenstand eintippt. Wikipedia:PRD war auch mal peppiger gewesen.
Also: Design offenkundiger machen; lokal und sinnvollerweise ggf. global.
Die blaue Farbe wird mit MW1.28 ohnehin verschwinden, da laut [5] dann mediawiki.ui.button nicht mehr automatisch geladen werden soll. --Schnark11:38, 3. Sep. 2015 (CEST)
Danke für eure Mühen. Ich denke, die Vorgehensweise ist nicht so klar ersichtlich und der dominierende button lädt förmlich dazu ein, dort zuerst raufzuklicken. Ich werde das mal kurz im Intro präzisieren. Gruß Martin Bahmann (Diskussion) 11:49, 3. Sep. 2015 (CEST)
Letzter Kommentar: vor 9 Jahren12 Kommentare3 Personen sind an der Diskussion beteiligt
Ich versuche gerade eine Autokorrekturfunktion im VE zu implementieren. Wenn man zwei Tastatur-Minuse hintereinander eingibt, sollen sie in einen Gedankenstrich umgewandelt werden. Bis jetzt sieht der Code so aus:
Er funktioniert auch fast (Seite zum Bearbeiten im VE öffnen, Code in Konsole ausführen), nur wandert der Cursor ein Zeichen nach rechts. Versteht jemand die VE-API so gut, dass er mir helfen kann, den Code zu korrigieren? --Schnark11:14, 15. Sep. 2015 (CEST)
Die Frage war rein zeichenmäßig gemeint (diff), aber ich habe das hinzugefügte Leerzeichen jetzt gefunden. Ist wohl eher ein Workaround, es fügt ein Leerzeichen ein das der Nutzer nicht geschrieben hat. --mfb (Diskussion) 18:14, 15. Sep. 2015 (CEST)
Dann bitte ich zu entschuldigen, dass ich die Frage nicht richtig verstanden habe. Ja, genau so ist es. Im Grunde nur eine kleine Erweiterung, den Beistrich, der gewünscht ist, hat der Benutzer ja auch nicht geschrieben. Warten wir das Feedback von Schnark ab, ob nun alles wie gewünscht funktioniert. --Saliwo (Diskussion) 18:17, 15. Sep. 2015 (CEST)
Das Leerzeichen ist ja nicht in allen Fällen erwünscht, sodass eine Ersetzung nur durch den Gedankenstrich schon notwendig ist. Offenbar hat es etwas damit zu tun, dass sich die Zahl der Zeichen ändert. Man könnte mit einem sehr üblen Hack statt des Leerzeichens ein \u0000 nehmen, das wird beim Speichern wohl automatisch entfernt, aber ich hoffe immer noch, dass jemand eine Lösung und nicht nur einen Workaround findet. --Schnark09:23, 16. Sep. 2015 (CEST)
Hast du denn den Code mal ausprobiert? Bei mir (FF und IE) wird gar keins eingefügt. Es steht halt nur im Code. Der Cursor verhält sich korrekt, der Beistrich kommt rein und der Cursor bleibt direkt dahinter stehen. --Saliwo (Diskussion) 09:30, 16. Sep. 2015 (CEST)
Natürlich habe ich den Code ausprobiert, wenn man \u0000 einfügt, dann steht es erst einmal auch im Text, beeinflusst damit Cursorbewegungen und Rechtschreibprüfung. Ein Gedankenstrich ist übrigens etwas anderes als ein Beistrich. --Schnark10:00, 16. Sep. 2015 (CEST)
Letzter Kommentar: vor 9 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
ich arbeite mit dem PDD-Monobook. Das Quickmenü links bleibt normalerweise an seinem Platz und das Orginalmenü ( mit „Suchen“, Navigation“ „Werkzeuge“ etc.) scrollt normalerweise hinter dem links oben feststehenden Quickmenü des PDD nach oben und unten dahinter mit der Seite mit. Bei mir jedoch bleibt - seit 3 Tagen - das Quickmenü starr mit dem dahinter liegenden normalen Menü verbunden und verdeckt es. Das besondere dabei ist, dass dies ausschließlich auf ANR-Seiten so ist. Auf allen anderen Seiten funktioniert es normal. Gleichzeitig sind diverse Zusatzknöpfe in der oberen Menüleiste verschwunden (z. B. „info“, „purge“, Seitenaufrufe etc. ). ebenso xAgent. Alles aber nur auf ANR-Seiten. Auf allen anderen Seiten funktioniert´s wie gehabt. Der Fehler tritt in Safari, Chrome und Firefox identisch auf. Wer kann mir bei diesem Bug helfen? Kann das mit einer Softwareänderung am 1. Oktober 2015 zusammen hängen? Danke und Grüße --Partynia∞RM13:06, 4. Okt. 2015 (CEST)
Softwareänderung am 1. Oktober: Ja, gut möglich.
Ich weiß nicht, ob das schon so geschehen ist; aber diese Frage besser direkt bei PDD/mono erörtern und klären, ob das anderen genauso geht, wieder anderen nicht, und von welchen Umständen es abhängt, dass das Problem auftritt oder nicht aufttritt.
Die Skripte müssten auf &rawcontinue=1 (um die derzeitige Methode weiterzubehalten) umgestellt werden, oder auf das neuere &continue= Methode. Habe ich eine Diskussion verpasst und wurden die Benutzer schon informiert oder muss das noch gemacht werden? Grüße sitic (Diskussion) 18:37, 11. Jun. 2015 (CEST)
Danke, Super-Service.
importUtility ist von mir, Code ergänzt und Test/Update-Prozedur auf dem Weg.
Gadget-bkl-check.js könnte bei der Gelegenheit beerdigt werden.
Habe die vernachlässigten Gadgets mal geändert und ein paar Skripte wo ich weiß dass die Benutzer inaktiv sind, aber wohl auch kein Problem mit Änderungen hätten. Den Rest könnte man auch anpingen, anstatt anzuschreiben. Der Umherirrende20:32, 11. Jun. 2015 (CEST)
Schade, jetzt hast du diese Halbleichen zusammengeflickt; wäre so ein netter Anlass gewesen, BKL zu beerdigen und den contribsrange-Fork zu aktualisieren.
@Umherirrender: Also, wenn du schon Leichenschändung betreibst, dann ersetz doch bei den BKL wenigstens noch dieses importScriptURI durch das argumentgleiche mw.loader.load(), damit meine Konsole nicht bei jedem Artikel überkocht. LG --PerfektesChaos16:13, 13. Jun. 2015 (CEST)
Ich habe die Nachricht ebenfalls erhalten. Nur ist mir nicht klar, welches Script davon betroffen ist. --Leyo02:20, 28. Jun. 2015 (CEST)
Mir auch nicht, und ich weiß auch nicht, nach welchen Kriterien WAID dich ausgewählt hatte. Was macht eigentlich Commons? LG --PerfektesChaos16:24, 28. Jun. 2015 (CEST)
OK, dann unternehme ich vorläufig nichts. Ich war in den letzten zwei Wochen offline und habe allfällige diesbezügliche Aktivitäten bei Commons nicht mitbekommen. --Leyo00:43, 29. Jun. 2015 (CEST)
Falls es noch zu Probleme kommt, sollte die Benutzer diese selber finden. Eventuell einen neuen Abschnitt aufmachen. Nach über 3 Monaten sollten alle wichtigen Stellen gefunden worden sein. Der Umherirrende10:41, 31. Okt. 2015 (CET)
OOUI und spätere Formularänderungen per JavaScript
Letzter Kommentar: vor 9 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
Das Verschiebeformular wurde ja auf OOUI umgestellt, was das verändern von Formularelementen etwas schwieriger macht. In MediaWiki:Gadget-old-movepage.js warte ich jetzt auf das Modul, was OOUI auslöst, das führt aber zum leichten FOUC.
Wie macht man es richtig, oder ist OOUI einfach ein zu großer Container der hier immer mehr unnötig genutzt wird? (Okay, das war eine rhetorische Frage …). Über Ideen würde ich mich freuen. Danke schonmal. Der Umherirrende21:08, 28. Sep. 2015 (CEST)
Man wird um FOUC nicht herumkommen, weil OOUI mal wieder ein Schwergewicht ist.
Statt #new-movepage-hint auszublenden, würde ich es in blassgrau auf weiß-grauem Hintergrund anzeigen; dann springt da nichts mehr so grob.
Ich nehme an, dass der hint von mediawiki.special.movePage kommt, oder was?
Ich weiß jetzt nicht, wer und was alles von Anfang an da ist, aber du könntest dem .movepage-wrapper ein .hide() geben, ihm sogar noch vor DOM.ready per CSS-Injektion ein display:none, und erst nach dem Eintreffen von OOUI die Seite umbauen und dann zum Schluss mit .show() das Endergebnis sichtbar machen. Mit CSS im Voraus müsstest du sogar den hint ruckelfrei ausgeblendet bekommen.
Die allgemeine Bedienungsanleitung kann ja ungestört gezeigt werden; dann sieht es nicht so leer aus und die Benutzer haben schon mal was zu lesen.
Es zeigt sich mal wieder, wie kurzsichtig eine Namenswahl old ist. Jetzt ist „ohne OOUI aber mit NR“ old, und …
Wenn man das Verschiebeformular ohne lokale Veränderungen so lässt, wie es MediaWiki vorgibt, kommt es nicht zu einem FOUC. --Schnark09:43, 29. Sep. 2015 (CEST)
Der Hint kommt aus der lokalen Nachricht, den könnte man natürlich ohne ruckeln eleganter verstecken, wenn man CSS verwendet. Ob man das ganze überhaupt braucht oder nicht, da lässt sich sicher drüber streiten, aber die Umstellung damals hat das Verschieben über Namensräume nicht einfacher gemacht, was man teilweise auch aus den Logbüchern erkennt. Der Umherirrende17:30, 29. Sep. 2015 (CEST)
Dann lassen wir es so. Falls es jemand nicht gefällt, dann muss das gesamte Gadget abgeschaltet werden. Andere Wikis scheinen auch ohne auszukommen oder die sehen die Falschverschiebungen nicht als so schlimm an. Der Umherirrende10:29, 31. Okt. 2015 (CET)
Letzter Kommentar: vor 9 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo habe probleme m, mein Smartphone , sobald ich anschalte , kommt immer wieder android. process angehalten , ich komme dadurch nicht in mein smartphone , da es immer da ist (nicht signierter Beitrag von62.226.243.28 (Diskussion) 08:43, 30. Sep. 2015 (CEST))
Letzter Kommentar: vor 9 Jahren7 Kommentare4 Personen sind an der Diskussion beteiligt
Habe die Sache ursprünglich hier angesprochen, doch nun denke ich, dass auch hier ein guter Ort sein könnte. Nach FSK und JMK steht bei mir nun in den Filminfoboxen direkt die Zahl ohne einen Freiraum. Ich dachte erst, das sei allgemein so, dann stellte ich aber fest, das ist nur der Fall, wenn ich eingeloggt bin. Ich denke, der Grund dafür ist, dass ich mir auf Benutzer:Jobu0101/common.css die Schrift etwas größer gestellt habe. Ich bin aber der Meinung, dass das Design der Wikipedia darunter nicht leiden sollte. Was meint ihr? --Jobu0101 (Diskussion) 10:50, 23. Okt. 2015 (CEST)
Deine Kritik ist nachvollziehbar und berechtigt:
In Vorlage:Medienbox/Film und Fernsehen steht überflüssiges HTML-Syntax-Rumgedödel, das auf dem Rechner des Autor vielleicht mal nett aussah, aber viel zu viele Voraussetzungen hinsichtlich Schriftart und Schriftgröße und Bildschirmauflösung unterstellt:
Das ist im Zweifelsfall überflüssig und kann ganz weg, mindestens ist die Aneinanderreihung von Block-div und Inline-span fragwürdig, und was man damit bezwecken will, ist auch nicht ersichtlich.
Je einfacher, desto besser und robuster. Wenn das irgendeinen verborgenen Sinn haben soll, dann kann man den in einer Infobox-Tabelle simpler erreichen als mit div-Elementen.
Das mit den divs habe ich eingefügt, damit die Zahl hinter FSK und JMK auf gleicher Höhe beginnt (ab Pixel 30). Ohne line-height war der Zeilenabstand zu groß. Kann man sicher auch eleganter lösen, allerdings sollten die Zahlen auf gleicher Höhe beginnen. –Queryzo?!19:43, 27. Okt. 2015 (CET)
Du darfst in solchen Fällen niemalspx als Maßeinheit verwenden. Damit setzt du voraus, dass deine privat-persönliche Schriftauswahl und Schriftgrößenkonfiguration bei jedem Leser auf jeder Geräteart gelten würde, was nicht der Fall ist, wie du jetzt merkst. Wenn überhaupt, wäre em anzuwenden, das immerhin schon mal relativ zur Schriftgröße wäre. Auch das ist hier aber ungeeignet, weil du damit unzulässige Annahmen triffst, wie breit ein M oder ein F oder ein K in den jeweiligen Schriften beim Leser geschnitten wäre, was du aber gar nicht wissen kannst.
Typografisch ist es überhaupt nicht wünschenswert, dass beide Zahlen genau untereinander stehen würden. Das hat zur Folge, dass zwischen dem kürzeren der beiden FSK und JMK (womöglich FSK/JMK) und der Zahl ein unerwartet großer Weißraum entsteht. Sowas macht man nicht; wenn du mehrere Personen auflistest, dann schreibst du auch nicht jeden Nachnamen exakt unter den Nachnamen der vorangehenden Zeile, sondern der Abstand zwischen Vorname und Nachname ist immer gleich, aber in der Regel immer an einer anderen Stelle. Daran ist nichts Schlimmes.
Wenn du unbedingt deine Zahl-genau-unter-Zahl durchdrücken willst, dann musst du eine Tabelle verwenden; nur damit kannst du dynamisch ausrichten.
Wenn du solche Kuriositäten einbaust, dann müsstest du sie für deine Nachfolger auch kommentieren und erläutern, zumal in dieser Vorlagenprogrammierung reichlichst Gebrauch von leeren Kommentaren gemacht wird.
Ok, danke für deine Hinweise. Ich hatte es zunächst als Tabelle versucht, war dann aber an der Wikisyntax und dem Endresultat verzweifelt. Wenn das aber generell unüblich ist, braucht man sich ja nicht unnötig den Kopf zu zerbrechen. Ich habe es nun zurückgesetzt. –Queryzo?!10:46, 28. Okt. 2015 (CET)
Ich meine vor einer Weile ein Skript o.ä. gesehen zu haben, das eine Gruppierung der Einträge analog zur Beobachtungsliste auch auf Spezial:Beiträge einbaut. Täuscht sich da mein Gedächtnis, oder weiß jemand wo das liegt? --Windharp (Diskussion) 09:43, 10. Nov. 2015 (CET)
Letzter Kommentar: vor 9 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Hier ist wohl mit den unbeabsichtigen 1.1.1.1.1.1.1.1.1.1. ein HTML -Fehler aufgetreten, der - für mich - nicht zu beheben ist. Benutzer:H.Albatros der daran mitdesignt hat, ediert leider z. Zt. nicht. Bin ich hier richtig, wer kann helfen? Dank im Voraus. --Artmax (Diskussion) 15:45, 17. Nov. 2015 (CET)
Letzter Kommentar: vor 9 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Gibt es evtl. ein (JS) Modul welches die selbe Funktion übernimmt wie {{int:…}}? Im Zuge der immer globaler werdender Scripte wäre das ein immenser Vorteil. Oder muss man sich die Schnipsel händisch von TranslateWiki holen (und komplett im Script hinterlegen)? ↔ Benutzer: Perhelion11:43, 7. Feb. 2015 (CET)
Letzter Kommentar: vor 9 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Verschiedene Funktionen geben Zugriff auf einige Dateieigenschaften; weiß jemand, wie ich zur Größe (in Bytes) kommen kann? Dazu muss es doch auch eine Variable geben, die ich aber nicht finden kann. sarang♥사랑19:25, 10. Feb. 2015 (CET)
Wie ich ihn kenne, ausschließlich auf Commons (wir hatten dbzgl. auch schon ein Gespräch und ich hatte auch die Lua-Werkstatt erwähnt). :-) ↔ Benutzer: Perhelion11:54, 12. Feb. 2015 (CET)
Ich bin mir jetzt nicht hundertprozentig sicher, aber der Hinweis scheint zu kommen, weil hier nicht auf eine Unterseite archiviert wird, sondern auf eine andere Seite im Unterseitensystem. -- hgzh21:33, 2. Dez. 2015 (CET)
Danke, aber das wird schon seit Jahren so gemacht. Entweder wir haben was zerhackt oder die Vorlagenlogik wurde geändert. LG --PerfektesChaos10:55, 3. Dez. 2015 (CET)
Versionsgeschichte bzw. Metaseiten mittels Python abfragen...
Letzter Kommentar: vor 9 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Kennt jemand eine Möglichkeit per Python-Script die Versiongeschichte und / oder Metaseiten per Python abzufragen?
Der Versuch das mit der Library "Wikipedia" zu machen scheitert an der fehlenden Möglichkeit etwas anderes als Artikel aufzurufen (und damit auch die VG). Wiki-api, supersimplemediawiki und pattern helfen mir auch nicht...
Entweder da werden logins vorausgesetzt, oder es werden gleich massenweise edits als Ziel gesehen oder oder oder... Eine einfache automatisierte Abfrage scheint niemand außer mir zu benötigen? --Wassertraeger11:26, 26. Nov. 2015 (CET) P.S.: Schon schräg, ich könnte (bei entsprechenden Rechten) mittlerweile massenweise Seitenschutzeinstellungen ändern, aber ein simple Abfrage? Finde ich nicht...
hgzh:Doch, das sieht recht gut aus. Auf den ersten Blick genau das was ich suche, muss ich mir aber erst mal in Gänze reinziehen. Danke! --Wassertraeger08:22, 4. Dez. 2015 (CET)
Letzter Kommentar: vor 9 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Seit kurzem wird bei Bearbeitung von Seiten die Verschlüsselung von meinem Browser als unvollständig markiert. Kann das jemand bestätigen/weiterverfolgen? -- Wolfgang Rieger(Diskussion)09:34, 6. Dez. 2015 (CET)
Letzter Kommentar: vor 8 Jahren21 Kommentare3 Personen sind an der Diskussion beteiligt
Seit einiger Zeit fällt mir auf, dass der Abruf von WP-Seiten ganz unverhältnismäßig viel Bandbreite beansprucht. Bei jeder Seite (egal was) wird ein knappes MB heruntergeladen.
Wenn ich mir das mit Firebug ansehen, wird offenbar immer alles geladen. Zum Beispiel MediaWiki:Gadget-popups.js (ziemlich fett mit ca. 250kB), obwohl das längst im Cache ist. Die Header sind:
Deine grundsätzliche Erwartung ist völlig berechtigt.
Es sind allerdings mehrere Aspekte an der bilateralen Kommunikation rätselhaft.
In dem oben dargestellten Beispiel hätte in der Tat auf ein If-Modified-Since ein 304 kommen müssen.
Allerdings haben wir nicht nur einen Server, sondern ein schizophrenes Sklavensystem. Master Boss hätte dir auch so geantwortet; dem Sklaven fehlte es an Einsicht.
Mir fällt beim spontanen Rumklicken auf, dass verschiedene andere Ressourcen (sofern sie nicht ohnehin mittels ResourceLoader im LocalStorage eingelagert wurden) hingegen mit 304 kommen, wie es deinen Erwartungen entspräche.
Mein flüchtiger Eindruck ist:
Mein privater Browser-Cache ist mit 50 MB zu klein gewesen; ich kann mir das alles gar nicht merken.
Die Regel für ein Expires durch MediaWiki ist recht konfus; mal fünf Minuten, mal nicht ganz exakt 30 Tage, mal 47 Sekunden.
Ein Teil des Problems kann auch im Firefox und seinen Abfrage- und Verwaltungspraktiken liegen; er scheint mir grad sehr konservativ und misstrauisch vorzugehen.
Genauso, wie ich anscheinend einen zu kleinen Cache habe, ist möglicherweise auf Seiten der Server irgendeine Tabelle zu klein für alle Seiten und Anfragen.
Dann gibt es nur miss statt wenigstens eines hit in X-Cache.
In diesem Fall weiß der (replizierende) Server nicht mehr so genau, wann die Seite im Originaltext zuletzt verändert wurde, und gibt sie sicherheitshalber komplett in der aktuellen Version zurück.
Die Hitliste wird aber von der Server-Administration kontinuierlich und engmaschig überwacht, und es wird versucht, eine optimale Balancierung zu finden. 200er Antworten bedeuten auch für die WMF-Seite erhöhten Netzwerktraffic, und man versucht wo immer möglich eine kurze 304er Antwort zu geben. Die Statistik wird täglich, minütlich, monatlich beobachtet und ausgewertet, und es wird versucht, Maßnahmen zu ergreifen.
Ich habe jetzt bei einer Serie von Seitenaufrufen den Netzwerktraffic überwacht und in allen Fällen ein unter den gegebenen Umständen ordnungsgemäßes wenn auch teils unbefriedigendes Verhalten gefunden; wenn entweder Firefox es nicht weiß oder die expiry zu kurz ist und zur sofortigen Cache-Löschung im Browser führt oder der antwortende Server sich nicht mehr an die URL erinnern kann.
Hi, PG. Danke für Deine ausführliche Antwort. Dennoch: Das Verhalten ist bei mir jedenfalls reproduzierbar. Den Großteil des Traffics verursachen 3 Dateien, die jedesmal erneut geladen werden, nämlich Popup-Gadget, Vector-Skin und Hotcat-Gadget (insges. ca. 550 kB). Mit dem Browser-Cache kann es eigentlich nichts zu tun haben, denn der Browser wäre ja mit 304 zufrieden. Bei nur ganzen wenigen Dateien sendet der Server 304. Beispiel:
Keine Ahnung; die analytics sind solchen Effekten aber auf der Spur.
Bei einer Software, die pro Sekunde eine Million Antworten über mehrere Dutzend Server in die Welt schickt, mag es Mitte 2015 mal solche überflüssigen Antworten geben.
Solange sie inhaltlich richtig sind (und da sind MW und FF eher zu scharf und zu konservativ und antworten einmal zuviel mit einer frischen Vollversion), ist es erstmal okay.
Die Leute, die derartige Software geschrieben haben, sind keine Volldeppen. Und für die erfahrenen Serverleute ist es eine Herausforderung, die Cache-Quote möglichst über 99 % zu bekommen.
Dass sich dann in manchen Monaten noch einige vermeidbare dazwischenschmuggeln, würde ich kommentarlos hinnehmen; das verschwindet auf unerklärliche Art wieder, und dafür passiert woanders was Seltsames.
Du kannst an deine popups-URL mal dranhängen: &bcache=1&maxage=604800
Ich habe bei meinem Firefox auch festgestellt, dass sehr viele Anfragen mit 200 beantwortet werden statt mit 304. Nach dem Hinweis auf den Firefox-Cache habe ich bei mir den Haken „Automatisches Cache-Management ausschalten“ aktiviert und die Cache-Größe von 350 MB auf die Maximalgröße 1024 MB erhöht. Jetzt kommen wieder Antworten mit 304. Die WMF-Server haben anscheinend die Eigenschaft den Firefox-Cache so zu füllen, dass sinnvoll cachebare Anfragen nicht mehr gecacht werden. --Fomafix (Diskussion) 15:41, 5. Mai 2015 (CEST)
Ich weiß nicht; meine preferences.js habe ich noch von Netscape.2 geerbt und die immer wieder auf neue Maschinen kopiert (inzwischen aber lokal raufgesetzt).
Wenn FF das noch im Cache hatte, dann kennt er auch noch If-Modified-Since und kann es dem Server anbieten; wenn die Seite bei FF aus dem Cache geflogen war, ist das logischerweise unbekannt und muss komplett neu geholt werden.
Lästig ist das must-revalidate usw. von MediaWiki; das ändert die Interpretation von Expires statt
Mindesthaltbarkeitsdatum (wie einer Tüte trockener Spaghetti) zu
Verfallsdatum (wie Hackepeter) – zur absoluten Unbrauchbarkeit.
Es gibt auch Seiten, die hängen einfach falsch auf dem Server in der Cache-Datenbank fest; da müsste ein handelsübliches Purge helfen. Manchmal muss so ein Sklavenserver auch rebootet werden, oder seine Cache-Datenbank mal komplett geleert; durch die Maschinchen gehen Terabyte an Daten, und da kommt es schon mal zum memory leak oder zu einem geistigen Kratzer auf der Festplatte.
Also ich weiß nicht, ob ich mich da richtig ausgedrückt habe. Das ist kein Nebenproblem und das sind auch nicht irgendwelche Dateien. Das sind ein paar ziemlich große Dateien, die bei praktisch jedem Seitenaufruf (Ausnahme z.B. Spezialseiten) eingebunden werden. Wenn das Problem auch nur einen Bruchteil der Benutzer betrifft, dann hat das erheblichen Einfluss auf die serverseitige Bandbreite. Und bei Benutzern mit eingeschränkter Bandbreite (e.g. mobil mit 500MB/Tag) schränkt das die Verwendbarkeit von WP ein. Die Betreffenden werden auf einmal gedrosselt, ohne dass sie wissen, wie ihnen geschieht. Wenn die dann feststellen, dass WP der Bandbreitenfresser ist, werden sie einigermaßen sauer sein. Und mit Recht. IMHO sollte das nicht liegengelassen werden. Könnte jemand einen entsprechenden Bug-Eintrag machen? -- Wolfgang Rieger(Diskussion)08:17, 8. Mai 2015 (CEST)
Nachträge: Ich habe mein Problem anscheinend gelöst, indem ich Firefox blank poliert habe. Die Header lauten jetzt im entsprechenden Fall (GET /w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript):
Mit Chrome funktioniert es auch korrekt. Auch hier wird Response-Status 304 geliefert. Hier lauten die Header:
:host:en.wikipedia.org
:method:GET
:path:/w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript
:scheme:https
:version:HTTP/1.1
REQUEST:
accept:*/*
accept-encoding:gzip, deflate, sdch
accept-language:en-US,en;q=0.8,de-DE;q=0.6,de;q=0.4
cache-control:max-age=0
cookie: ...
dnt:1
if-modified-since:Wed, 10 Dec 2014 23:42:14 GMT
referer: ...
user-agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36
RESPONSE:
accept-ranges:bytes
age:0
cache-control:private, s-maxage=0, max-age=0, must-revalidate
content-encoding:gzip
content-type:text/javascript; charset=UTF-8
date:Fri, 08 May 2015 13:44:56 GMT
last-modified:Wed, 10 Dec 2014 23:42:14 GMT
server:nginx/1.6.2
status:304 Not Modified
vary:Accept-Encoding
version:HTTP/1.1
via:1.1 varnish, 1.1 varnish, 1.1 varnish
x-analytics:https=1;WMF-Last-Access=08-May-2015
x-cache:cp1055 miss (0), cp3007 miss (0), cp3041 frontend miss (0)
x-content-type-options:nosniff
x-powered-by:HHVM/3.3.1
x-varnish:3676403530, 2929413494, 1483623845
Der einzige nennenswerte Unterschied, den ich sehe, ist, dass zuvor Cache-Control: max-age=0 im Request-Header gefehlt hat. Anscheinend verstehe ich HTTP nicht, denn IMHO müsste der Server so oder so 304 senden, wenn if-modified-since passt. Kopfkratz … grübel … Vielleicht doch ein Bug? -- Wolfgang Rieger(Diskussion)20:32, 8. Mai 2015 (CEST)
Wie oben beschrieben hatte ich am 5. Mai meinen Cache im Firefox von 350 MB auf 1024 MB vergrößert und danach wurden wieder Anfragen gecached und es kamen Antworten mit 304. Inzwischen ist auch dieser Cache vollgelaufen und alle Ressourcen werden wieder immer neu geladen mit 200. Ein Verringern und erneutes anschließendes Vergrößern des Caches hat wieder Platz im Cache geschaffen, so dass jetzt wieder Antworten mit 304 kommen. Die Frage ist nun, wird dieses seltsame Cache-Verhalten vom Firefox durch die Konfiguration der WMF-Server provoziert? --Fomafix (Diskussion) 10:12, 18. Mai 2015 (CEST)
Primär ein unglückliches Verhalten von Firefox.
Mit Erreichen von rund 95 % der Plattenquota oder aber wenn nur 5 MB oder was über sind, sollte die garbage collection gestartet werden.
Das klappte eigentlich zwei Jahrzehnte hindurch.
Mozilla muss dann nach bestimmten Strategien (ältere und sehr große und selten angefasste und lange nicht benötigte zuerst) Einträge aus dem Cache entfernen, bis vielleicht nur noch 75 % oder so belegt sind.
Deiner Schilderung nach ist das nicht passiert.
MediaWiki hat damit erstmal nix am tun.
Es wird auch nicht gleichzeitig 1 GB für die Darstellung einer Wiki-Seite benötigt.
Muttu dich mal durch die Foren und den echten Bugzilla googlen.
MediaWiki ist aber auch ein fauler Trafficfresser.
Es wird alles und jedes auf ein Höchstalter von Null Sekunden gesetzt.
Das ist ja lieb, wenn es um Artikel-Inhalte und dergleichen geht.
Aber ein 2004 nach Commons hochgeladenes Bildchen muss nicht alle 30 Sekunden bei jeder Preview erneut gefragt werden, ob’s zufällig grad eben eine neue Version hochgeladen hat.
Meine Frage ist immer noch: Ist es korrekt, dass der Server auf das fehlende Cache-Control: max-age=0 im Request-Header statt mit 304 mit 200 reagiert? Der Server kann natürlich 200 senden, wann immer er will. Nicht aber, wenn er weiß, was für ihn gut ist. Oder ist das eine vergurkte, serverseitige "Mozilla-Optimierung" ala wir drängeln uns jetzt mal wieder auf eine bessere Cache-Position? -- Wolfgang Rieger(Diskussion)10:59, 18. Mai 2015 (CEST)
Das kostet die auch nur Netzwerk-Traffic, und MW hat nichts davon, und man ist bemüht, den Nicht-304-Traffic mit Inhalten zu minimieren.
Die Cache-Position ergibt sich auch mit 304 weiter oben, weil die Zahl der Anfragen auf diese URL im Browser-Cache um eins erhöht wird, der Zeitpunkt des letzten Bedarfs grad eben ist, und damit für die nächsten 24 Stunden oder was möglichst im Cache bleiben sollte. Ob 200 oder 304 ist dabei egal.
Die Serverfarm bemüht sich, bei Fragen auf eine statische URL /wiki/ usw. zu wissen, wann diese Seite zuletzt modifiziert wurde; wenn sie das weiß und damit die Aktualität bestätigt werden kann, kommt 304. Wenn der Sklave die Ressource nicht kennt und deshalb nicht einschätzen kann, ob sie noch aktuell ist, muss er sich beim Master eine frische holen und der sendet dann wohl auch gleich den Inhalt (was nicht ganz so optimal ist). Aber das ist eine komplexe Geschichte, die sich in Tausendstelsekunden in einem Hochgeschwindigkeitsbus abspielt, und die nicht trivial zu durchschauen ist. Die Hit- und Miss-Quoten werden aber beobachtet.
Ich habe in einer virtuellen Maschine mit einem Firefox ohne Addons und mit verringertem Cache etwas experimentiert. Sobald der Cache voll ist, werden bei dewiki über HTTPS Ressourcen aus index.php und load.php nicht mehr gecacht, sondern immer per 200 neu geholt. Bilder werden weiterhin gecacht und die Aktualität wird per 304 bestätigt. Bei einer lokalen MediaWiki-Installation per HTTP werden trotz vollem Firefox-Cache auch Ressourcen gecacht. Die Webserver-Einstellungen der WMF-Server scheinen also das Caching beim Firefox bei vollem Cache negativ zu beeinflussen. --Fomafix (Diskussion) 14:11, 18. Mai 2015 (CEST)
Dafür würde ich gleichwohl in erster Linie den FF verantwortlich machen.
Die Situation „voller Cache“ darf überhaupt nicht auftreten.
Wenn der Cache eine Daumenbreit vor der quota angekommen ist, ist nach irgendeiner Heuristik für alle Dateien ein score zu bilden.
Was vor einer Stunde, einem Tag, einer Woche zuletzt angefasst wurde, bekommt entsprechend mehr Punkte.
Was häufiger verwendet wurde, bekommt mehr Punkte.
Was das MHD noch vor sich hat, bekommt mehr Punkte.
Was schon lange stabil war, bekommt Pluspunkte.
Kleine Dateien bekommen Extra-Punkte. Ein 2 MB großes Foto, das ich mir vor drei Wochen einmal angeschaut hatte, macht mehr realen Speicherplatz frei als 1000 kleine Icons und winzige Pixelgrafiken.
Der score ist dynamisch und kann nicht bei den Einträgen gespeichert werdne, weil die Information „innerhalb der letzten Stunde zuletzt benutzt“ vergänglich ist.
Danach werden von den Einträgen mit wenig Punken so lange welche gelöscht, bis wieder einige Dutzend MB frei geworden sind.
Die Website hat überhaupt keine Möglichkeit, das zu beeinflussen. Sie liefert URL, Last-Modified und Expires.
Wie das in die Speicherbereinigung eingeht, ist allein Sache des Browsers.
Ein Browser muss eine Prognose machen, welche Dateien zukünftig wieder benötigt werden. Die, an denen ich grad sitze, die ich häufig anfasse, die könnte ich wieder brauchen; was ich nur selten und zuletzt vor langer Zeit benutzt habe, muss gelöscht werden.
Damit ich den Cache wieder nutzen kann und Platz für Neues habe, muss Altes raus.
Sicherlich, die Entscheidung was aus dem Cache geworfen wird bzw. was in den Cache aufgenommen wird, ist Sache des Browsers. Ein voller Cache ist der Normalzustand, sofern der Browser eine Weile in Betrieb ist. Firefox hat anscheinend die Strategie, dass Ressourcen mit dem Header Cache-Control:"private, s-maxage=0, max-age=0, must-revalidate" grundsätzlich einen niedrigeren Score bekommen. Bei vollem Cache werden daher solche Ressourcen nicht mehr gecacht, weil im Cache noch Ressourcen mit anderem Cache-Control sind. Dieser Score kann daher vom Webserver beeinflusst werden. Die Konfiguration der WMF-Server ist daher schlecht. --Fomafix (Diskussion) 15:03, 18. Mai 2015 (CEST)
Der Server sieht nur den Request und sonst weiß er von nichts. Der einzige Unterschied im Request, der reproduzierbar zu 200- bzw. 304-Status geführt hat, war eben Cache-Control: max-age=0 im Request-Header. Laut dem entsprechenden Abschnitt in RFC 2616 (HTTP/1.1) sollte dieser Teil des Requests dazu führen, dass alles validiert wird, mehr nicht. Da aber keine neue Version da ist, kann die Validierung nichts Neues liefern, außer auf Serverseite wird das if-modified-since irgendwo in der Kette schlicht weggeschmissen (was IMHO ein Fehler wäre). Dass wie PC meint, ein Slave keine Kopie eben dieser Dateien hat, die bei jedem Seitenaufruf abgefragt werden und sich kaum je ändern, kann ich mir nicht vorstellen. Ich sehe wirklich nur die zwei Möglichkeiten: 1) ich verstehe HTTP nicht bzw. übersehe etwas Offensichtliches 2) das Verhalten der WP-Server ist fehlerhaft bzw. unökonomisch. -- Wolfgang Rieger(Diskussion)15:35, 18. Mai 2015 (CEST)
@Wolfgang Rieger Mein beobachtetes Verhalten stimmt nicht mehr Deinem beschriebenen Verhalten überein. Anfragen mit If-Modified-Since werden bei mir auch immer mit 304 beantwortet – so weit ich sehe. Mir fällt nur auf, dass im Firefox bei vollem Cache Antworten mit Cache-Control: private, s-maxage=0, max-age=0, must-revalidate nicht in den Cache aufgenommen werden und daher die Folgeanfragen immer ohne If-Modified-Since angefragt werden und daher auch immer mit 200 beantwortet werden. --Fomafix (Diskussion) 16:45, 18. Mai 2015 (CEST)
Das scheint mir dann ein anderes, teilweise clientseitiges Problem zu sein. Der Punkt war ja gerade, dass If-Modified-Since da war und die Dateien auch im Browser-Cache vorhanden waren (das lässt sich ja überprüfen). Ich stimme PC hier zu, dass die von den WP-Servern gelieferten Response-Parameter übertrieben konservativ sind. -- Wolfgang Rieger(Diskussion)17:13, 18. Mai 2015 (CEST)
@Wolfgang Rieger: Ich kann übrigens Dein Problem nicht reproduzieren:
Letzter Kommentar: vor 8 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Hello Wikipedia Germany, apologies for posting in English.
This is a note to the page on meta for community tech project ideas., please feel free to engage in the discussion or add a suggestion to project, etc. Thanks --Melamrawy (WMF) (talk) 11:59, 19 May 2015 (UTC)
Fast fertiges Verschiebeskript für den Luke081515-Bot
Letzter Kommentar: vor 8 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo, ich habe ein Skript für den Luke081515Bot programmiert (bzw. es versucht), das bei Klick auf einen Eintrag unter Verschieben zwei DIalogfenster öfnet, und dann per API den Edit speichert. Nun zu meinem Problem: Der Edit wird nicht gespeichert, obwohl sogar "Diese Bearbeitung wurde gespeichert" erscheint. Ich wäre sehr dankbar, wenn mir jemand sagen könnte, wo in meinem Skript der Fehler liegt, mutmaßlich in line 32-47.
Außerdem würde mich im Zuge der Weiternetwicklung des Skriptes imteressierten, ob es möglich ist, seitenspezifische Variablen wie wgCurRevisionId für andere Seiten auszugeben, als auf denen das JS läuft. (In diesem Beispiel konkret für die Variable "Ziellemma") --MGChecker – (📞| 📝| ) – HDR20:36, 2. Jun. 2015 (CEST)
Okay, das Hauptproblem habe ich jetzt gelöst, aber die Frage nach seitenspezifischen Variablen auf anderen Seiten konnte ich noch nicht für mich beantworten. --MGChecker – (📞| 📝| ) – HDR18:29, 3. Jun. 2015 (CEST)
Wenn du die ID einer anderen Seite haben möchtest, müsstes du ein weiteren API-Request machen, beispielsweise action=query mit prop=info (api.php?action=query&prop=info&titles=Page%20A|Page%20). Die aktuelle Seite kennt nur seine seitenbezogenen Dinge. Der Umherirrende20:00, 3. Jun. 2015 (CEST)
Language-Links fehlen auf der Seite "Lautsprecher" wenn ich nicht eingeloggt bin
Letzter Kommentar: vor 8 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Auf der Seite "Lautsprecher" sehe ich in der linken Spalte unter "In anderen Sprachen" keine Links zu den entsprechenden Artikeln in anderen Sprachen, wenn ich nicht bei Wikipedia eingeloggt bin. Wenn ich eingeloggt bin, werden alle Links ordentlich angezeigt. Auf der Seite "Kopfhörer" werden die Language-Links immer korrekt angezeit. Ist das ein bekannter Bug? AxelBoldt (Diskussion) 15:52, 26. Jul. 2015 (CEST)
Letzter Kommentar: vor 8 Jahren17 Kommentare12 Personen sind an der Diskussion beteiligt
Superprotect wurde von der Wikimedia Foundation (WMF) eingeführt um eine Meinungsverschiedenheit in der Produktentwicklung beizulegen. Die WMF hat seitdem kein weiteres Mal auf Superprotect zum Beilegen weiterer Auseinandersetzungen zurückgegriffen. Daher entfernen wir heute Superprotect von den Wikimedia-Servern.
Die Beseitigung von Superprotect entfernt einen symbolischen Konfliktherd. Allerdings besteht weiterhin das grundlegende Problem von Konflikten und daraus resultierenden Verzögerungen in der Phase der Zurverfügungstellung der Software auf den Wikimedia-Servern ("Deployment"). Wir müssen besser in der Softwareentwicklung zusammenzuarbeiten, um bessere Produkte und bessere Features schneller zur Verfügung stellen zu können. Die Zusammenarbeit von WMF und den Communities beruht auf gegenseitigem Vertrauen und konstruktiver Kritik. Daher müssen wir Wikimedia-Abläufe verbessern um Konsens zu schaffen, mehr Stimmen einzubeziehen und Meinungsverschiedenheiten beizulegen.
Es gibt einen ersten Entwurf eines aktualisierten Software-Produktentwicklungsprozesses, der die Richtlinie für die Arbeit der WMF Engineering and Product-Teams sein wird. Er betont dass das Feedback der Community, insbesondere in frühen Entwicklungsphasen, wichtig ist. Mehr und früheres Feedback erlauben es, von der Community angeregte Verbesserungen einfließen zu lassen und mögliche kontroverse Aspekte anzusprechen, solange die Pläne und die Software am flexibelsten angepasst werden können.
Wir begrüßen das Feedback von technischen und nicht-technischen Beitragenden. Mehr Details dazu können in den zugehörigen Fragen und Antworten (Q&A) gefunden werden.
Ich bin gespannt, was sich sonst noch so tut. Oder ob die Kanone beim nächsten Disput wieder ausgerollt wird, anstatt sich dem eigenen Versagen zu stellen. —הגות41419:29, 5. Nov. 2015 (CET)
Gespannt sein kann man. Ich fände es aber gut, wenn nach dieser Aktion auch die Wortwahl gegenüber WMF etwas freundlicher wird, um ein "Neuanfang" zu ermöglichen. Der Umherirrende22:23, 5. Nov. 2015 (CET)
Sehr schön, damit habe ich nicht mehr gerechnet, ehrlich gesagt. Aber ich habe gleich mal die Signatur angepasst. :-) Ein gutes Zeichen jedenfalls, hoffentlich geht es auch so weiter, und zwar in beide Richtungen, nicht nur Feedback von hier für neue Entwicklungen der WMF, sondern auch mehr Vorschläge von hier und Bugmeldungen, die schneller umgesetzt werden. Das wäre wesentlich. --Winternacht in Wikimedias nichtmehrsupergeschützten Wikis 21:44, 5. Nov. 2015 (CET)
Und wann wird das Meinungsbild umgesetzt und der neue Medienbetrachter nun abgeschaltet? Ich rege mich jedes Mal darüber auf, wenn ich unangemeldet unterwegs bin. Gerade auf mobilen Geräten ist der Betrachter klobig und verlangsamt das Browsing. --(Saint)-Louis (Diskussion) 22:15, 5. Nov. 2015 (CET)
Der Medienbetrachter hat sich weiterentwickelt. Auch unangemeldeten Benutzern ist es möglich ihn über ein Klick abzuschalten (wird als Cookie gespeichert).
Jetzt wieder damit anzufangen, dass auf den damaligen Weg auszuschalten, ist sehr kontraproduktiv, weil dann der Vertrauensvorschuss seitens WMF sicher nicht wieder aufholbar ist und es dann für immer bleibt. Der Umherirrende22:23, 5. Nov. 2015 (CET)
Dass das Ding nun auch unangemeldet abschaltbar ist, ist auch erfreulich. Haben sie denn die URV-Probleme mit den mangelnden Autoren-Kennzeichnungen der Bilder eigentlich vollständig gelöst bekommen? Das war auch einer der Hauptgründe für die Kontrastimmen im MB. --Winternacht in Wikimedias nichtmehrsupergeschützten Wikis 22:54, 5. Nov. 2015 (CET)
(reinquetsch, @Winternacht:) Dass das Ding nun auch unangemeldet abschaltbar ist, … – Der Medienbetrachter war von Anfang an auch für unangemeldete Benutzer abschaltbar, das ist keine Neuerung. --Schnark11:18, 9. Jan. 2016 (CET)
... someone said in Berlin. Schön gesagt :D (and sorry, I can read German but not write it at the level required here). Glauben / trusting is important in our partnership, but you don't need to trust blindly. The WMF product development process draft is the important part of my post, because it is in the context of that process where our mutual trust as software partners will be exercised. I have added a Q&A about this. I invite you to contribute to the design of this process today. A big, diverse, well organized, and tech-savvy community like this one could get involved earlier in the development of new products, influence plans and their execution, and identify actionable blockers at the right times. This way of exercising community power can be really efficient and effective (and interesting and fun for a higher diversity of contributors, let me add).--Qgil-WMF (Diskussion) 01:10, 9. Nov. 2015 (CET)
... someone said in the U.S.
Frankly, my experience with giving early feedback in the development of new WMF products is not that this is in the least effective, but rather the feedback is ignored, dismissed or "disagreed with" and that this is a waste of my time and highly frustrating. The WMF product development process draft is very generic and the venue to discuss it is an awfully quiet Flow talk page. A FLOW talk board! Brilliant! OMG. --Atlasowa (Diskussion) 10:12, 24. Nov. 2015 (CET)
Letzter Kommentar: vor 8 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Hey (hoffe, dass ich hier mit meinem Anliegen richtig bin),
am Fuß eines von mir bearbeiteten Artikels ist mir aufgefallen, dass (zumindest) in der Zeile "Diese Seite wurde zuletzt... geändert" die Uhrzeit falsch ist - sie liegt eine Stunde hinter der MEZ. Bezieht sich dieser Uhrzeitfehler auf das ganze System oder nur auf diese Fußzeile? Beides wäre natürlich nicht optimal ;)
Grüßle, --Gambuso (Diskussion) 02:07, 10. Nov. 2015 (CET)
Hallo Leute,
habe ein svg file (Entscheidungsschema.svg) editiert und hochgeladen. Lade ich es wieder herunter, ist alles richtig, aber auf der Dateibeschreibungsseite (und im Artikel Rechnungsabgrenzung) bleibt die alte Version zu sehen - auch nach Browser-Cache-Löschen, Browser-Wechsel und serverseitigem Cache-Löschen bzw. purgen mit ?1 und &action=purge. Was tun?
--Volker Alexander (Diskussion) 22:20, 17. Nov. 2015 (CET)
Mittlerweile hat eine Aktualisierung stattgefunden; ob diese mit einer Artikeländerung eines Dritten zu tun hat, habe ich nicht beobachtet (vermutlich nicht, aber man weiß ja nie...). Danke fürs Verlinken, Perhelion! --Volker Alexander (Diskussion) 14:09, 24. Nov. 2015 (CET)
Letzter Kommentar: vor 8 Jahren14 Kommentare3 Personen sind an der Diskussion beteiligt
Ich würde mir gerne im Rahmen intensiver kontemporärer Wartungsarbeiten ein Skript schreiben, das einem Diskussionsseitenabschnitt einen Bearbeitenlink hinzufügt, das diesen löscht mit dem Bearbeitungskommentar /* … */ fix. Daneben soll es auch aus der Versionsgeschichte heraus SLAs auf Diskussionsseiten stellen können, mit zwei verschiedenen Begründungen (ausschließlich erledigte Bothinweise, Botfehler), und auf einer Seite Abschnitte erledigen. Kann mir jemand sagen, wie man das heutzutage am besten löst? PS: Schön wäre auch, wenn das ganze im Hintergrund stattfinden könnte (Tab wird geschlossen (versteckt?), bei Fehlern wird man benachrichtigt). – Giftpflanze00:28, 17. Dez. 2015 (CET)
Ich kann jetzt schwerlich einer Botbetreiberin die WP:BA anempfehlen.
Wenn die Aufgabe so trivial und narrensicher ist:
Frühestens nach den Feiertagen kann ich ein JS per Mail senden, das genau so etwas wie beschrieben täte. Bin im Moment extrem knapp mit Entwicklungszeit und schaffe allenfalls Palaver.
Ich zweifele aber, dass dies immer so trivial ist, dass immer alle URL in der Einbindung gelöscht werden sollen.
Eine URL hätte nicht sein sollen, oder hat fehlerhaft zugeordnete Flags; okay, muss weg. Aber was ist mit den anderen URL derselben Vorlage?
Kann ich mit Lua etwas für dich tun? Einträge, die bestimmte Kriterien erfüllen, einfach mal verschwinden lassen?
SLA sind unerwünscht.
Es reicht, die Disku komplett zu leeren; sie wird dann später von Amts wegen gelöscht.
Massenhaft generierte SLA würden die manuelle Abarbeitung der normalen SLA verstopfen.
An Hilfsmitteln, die zur Automatisierung kleinerer Routineaufgaben verwendet werden, kann ich ansonsten empfehlen:
Ich hätte nicht gedacht, dass es so schwierig werden würde, diesen Wunsch umzusetzen … Ich habe die Liste gestern abgearbeitet, somit ist mein Anliegen vorerst erledigt. – Giftpflanze11:55, 20. Dez. 2015 (CET)
@PerfektesChaos: Arbeitest du noch an dem Skript? Die Liste ist schon wieder sehr lang, da könnte ich das echt gut gebrauchen. Es kommt häufig vor, dass die Abschnitte, die ich löschen muss, nur einen Link enthalten, bzw. alle Links falsch sind. Wenn es nicht alle sind, bin ich mit manueller Löschung und Speicherung glücklich. Links mit Lua verchwinden zu lassen ist, glaube ich, verwirrend. Es fallen nicht viele SLA an, die sind noch verkraftbar. Alles, was mir bislang so anempfohlen wurde, ist lang, unübersichtlich und kompliziert, damit kann man nicht viel anfangen. Mein Arbeitsablauf: Ich arbeite die Liste Wikipedia:Defekte Weblinks/Bot2015-Problem ab. Dabei müssen reihenweise Abschnitte erledigt werden. Wenn der Bot etwas fehlerhaftes verteilt hat, müssen diese Meldungen entfernt werden, bzw. die Diskussionsseiten gelöscht. Ich hoffe, das war jetzt klarer, wenn nicht, frag ;) – Giftpflanze23:19, 30. Dez. 2015 (CET)
Mangels klarer Aufgabenbeschreibung konnte ich noch nicht mal damit anfangen.
Was ich ohnehin benötigen würde, wäre eine maschinenlesbare Liste der Anfänge der URL, an die du ran willst. Sie müsste auf einer Seite unter de.wikipedia.org liegen.
Wenn jeder Abschnitt, den du archivierst oder zur Kenntnis nimmst, einen Eintrag bekäme wie:
Waswaswas? Hä?! Du bist hier auf dem falschen Dampfer. Ich fühl mich jetzt etwas verloren, ich weiß nicht, wie ich dir begreiflich machen kann, was ich will … Ich will kein intelligentes Abarbeitungsmonster, ich will ein js-Skript, das mir ein paar Klicks und ein bisschen Tipparbeit abnimmt, die sich immer wieder wiederholen. Das Skript braucht als Eingabe keine Domains. Grummelige Grüße, Giftpflanze00:00, 31. Dez. 2015 (CET) PS: Hilfreich könnte es auch sein, sich meine Bearbeitungen in diesem Bereich in letzter Zeit anzugucken.
JavaScript ist kein KeyFireDingens.
Wenn du unbedingt manuell löschen möchtest, dann sind in einem guten Browser so wenige Klicks erforderlich, dass sich ihre Anzahl in den jeweiligen Situationen und Konstellationen nicht sinnvoll reduzieren ließe, wenn du die Standardklicks durch neu programmierte Klicks ersetzen würdest.
Wenn du die oben genannte Liste als Lua-Code erstellen und alle paar Tage aktualisieren würdest, dann bräuchtest du überhaupt keine einzige Disku zu editieren, weil Lua dann die entsprechend beginnenden URL von sich aus ausblenden oder auch mit einem Warnhinweis versehen könnte, und dann wäre auch eine Grundlage für spätere echte Einsparungen mittels JavaScript gelegt. Dieselbe Seite mit maschinenlesbarem Code ließe sich auch später für die physische Löschung erledigter Abschnitte durch GiftBot auswerten.
Diese Geschichte zeigt mir einmal mehr, dass die Methode mit dem Beschreiben von statischen Artikeldiskussionsseiten ein absoluter Krampf ist. Der nächste Durchgang sollte unbedingt auf eine dynamische Auskunft aus einer serverbasierten Datenbank gestützt werden.
„dann sind in einem guten Browser so wenige Klicks erforderlich“ Aha. Und wie macht man so was? Oder meinst du den normalen Bearbeitenablauf? Den könnte man durch einen einzigen Klick ersetzen. – Giftpflanze13:53, 31. Dez. 2015 (CET)
Ich hab zufällig vorhin ein Dutzend erledigter Abschnitte nur mit der Maus plattgemacht; samt BK.
Aber warum kommst du nicht mal langsam aus der Rille raus, du müsstest jetzt sofort jeden Disku-Abschnitt einzeln persönlich bearbeiten?
Helfen ja; aber nur, wenn für uns beide der Aufwand vertretbar ist. Momentan läufst du in der völlig falschen Spur; der Entwicklungsaufwand für dein Begehr ist bei meiner Auslastung und dem Umstand, dass ich an diesen ruhigen Feiertagen meine Programmierungsschulden aus dem Juli 2015 aufarbeite, nicht vor 2017 zu erwarten. Und danach wärst du immer noch auf dem Trip, manuell einzeln an Zeilen und Abschnitten herumzulöschen und womöglich völlig überflüssige SLA zu stellen. Und das Ganze, um per manuellen Edit einige Mausklicks zu sparen. Entweder sind es wenige Edits, dann geht es auch so (wie ich heute zufällig ausprobierte); oder es sind viele, dann ist das manuelle Seitengeöffne sowieso unverhältnismäßig und es sollte ein schlauerer Weg genutzt werden. LG --PerfektesChaos14:44, 31. Dez. 2015 (CET)
Naja, dann halt nicht. Ich wollte eigentlich eh nur Hilfe dabei, es selbst zu machen. Ich werde jetzt das MP-Skript nehmen und mir daraus das gewünschte stricken. – Giftpflanze14:51, 31. Dez. 2015 (CET)
Letzter Kommentar: vor 8 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Kann mir da jemand sagen, wie ich in einem anderen Wiki die Schriftgröße der Einzelnachweise kleiner machen kann (nicht als User, sondern als Betreiber ;-) --danke K@rl11:17, 8. Nov. 2015 (CET)
Auf den ersten Blick wäre das auf MediaWiki:Common.css einzufügen; müsste schon reichen:
.references{font-size:90%;}
Allerdings ist es so, das Ältere und Smartphone-Benutzer mit dieser aus gedruckten Büchern bekannten Tradition Probleme haben; da ein Wiki kein Papier sparen muss, wird das eher nicht empfohlen.
Inhalte innerhalb des Tabellencodes, die nicht zur Tabellensyntax passen, werden gerne über der Tabelle ausgegeben. Siehe Quelltext hier. --mfb (Diskussion) 19:38, 12. Nov. 2015 (CET)
{| class="wikitable"
|bla
|bla
|-
text
|bla
|bla
|}
Letzter Kommentar: vor 8 Jahren11 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo, gibt es einen Bot der systematisch und regelmäßig Bilder nach Commons schiebt? Gibt es einen Bot, der eine Liste von Bildern nach Commons schiebt? Oder ist dies alles "Handarbeit" per Commonshelper? Danke, --Arnd (Diskussion) 16:51, 26. Nov. 2015 (CET)
Danke für den Ping. @Arnd: Regelmässig oder (voll)automatisch mache ich es via bot-script nicht, da dabei die Fehlerrate/Problemfälle zu gross wird. Semi-automatisch mache ich es via Benutzer:wdwdbot, kann dabei aber keinen fixen "Service" garantieren. Für kleinere Anzahl einzelner Bilder mit {{Commonsfähig}} markieren ist eine Möglichkeit. Bildserien, bevorzugt aus einer Quelle, von einem Urheber und möglichst "homogen" in den Motiven, etc.. um die Prüfung auf Stichproben reduzieren zu können: In diesem Fall bitte ich um kurze direkte Rücksprache zwecks Detailabklärung: Größere Dateimengen zu verschieben (bis zu einige 1000 Dateien pro batch-run) sind dabei prinzipiell (technisch) ohne viel Aufwand möglich.--wdwd (Diskussion) 08:44, 27. Nov. 2015 (CET)
Danke wdwd für die schnelle Antwort. Ich kann die Dateien, die ich meine mit {{Commonsfähig}} zu markieren, wenn sie denn geeignet sind. Was spricht dagegen ab und zu alle Dateien mit dieser Vorlage per Bot zu verschieben? Das würde die Arbeit des Erkennens der Commons-Fähigkeit und des Verschiebens unabhängig voneinander machen. --Arnd (Diskussion) 09:14, 27. Nov. 2015 (CET)
Was dagegen spricht sind nicht commonstaugliche Dateien, trotz Markierung, da dieser Markierung im Prinzip jeder eintragen kann, auch im guten Glauben. Das ergibt bei Fehlern dann x-fache Mehrarbeit auf commons (Löschungen) und so die Dateien hier behaltbar ist den Mehraufwand für die Wiederherstellung. (z.b. wegen Panoramafreiheit und dem {{Schutzlandprinzip}} wie Beispiel hier). Der Punkt ist, dass ein simpler Algorithmus (Script/Programm) nicht selber den Zusammenhang der "Commonstauglichkeit" wie in den Beispiel erkennen kann - vergleichbar mit der Situation, dass ein (simpler) Bot auch keine Löschdiskussionen selber entsteiden kann, auch wenn ein Bot technisch leicht (Massen)löschungen potentiell durchführen kann. Damit besteht bei vollautomatischen commonstransfer, auch wenn dieser technisch einfach möglich ist und neben dem Problem wie man potentiellen Missbrauch vermeidet, durch die dann hohe Fehlerquote sich mehr Arbeit anzutun als der Nutzen eines vollautomatischen commonstransfers an Vorteilen wie projektübergreifende Verwendung der Bilder mit sich bringt.--wdwd (Diskussion) 18:46, 27. Nov. 2015 (CET)
Die Markierung kann jeder eintragen, es kann aber auch jeder die Verschiebung durchführen. Vielleicht könnte man es halbautomatisch machen? Sichter bekommen das Recht, den Bot über eine Gruppe von Artikeln oder eine Kategorie laufen zu lassen.--mfb (Diskussion) 13:19, 28. Nov. 2015 (CET)
Machbar wäre ein (halb)automatischer commonstransfer mit mw:Help:OAuth, da damit der Bot unter dem Namen/Account des jeweiligen Benutzers aufscheint und arbeiten kann - so wie der derzeitige commonshelper das auch macht, quasi erweitert auf Listen von Dateien. Das Recht zu OAuth wird von User:wdwdbot dzt. nicht unterstützt und ich weiss derzeit auch nicht mit welchem Umfang das zu erreichen wäre und was da für sonstige Punkte zu beachten sind um möglichen Unfug bzw. auch unpassende Massentransfers in guten Glauben zu vermeiden. Denn einzelne, wenige falsche Commonstransfers zu korrigieren sind eine Sache. Bei einigen 100+ möglicherweise nicht commonsfähigen Dateien wird es ungut, das aufzuräumen.--wdwd (Diskussion) 18:02, 29. Nov. 2015 (CET)
Ja, der Transfer ist damit machbar. Aber fast alle Dateien sind PD-Alt-100 oder PD-alt, puhh. Dürften wohl grossteils commonsfähig sein, ja. Bist Du Dir auch betreffend der URAA-Problematik sicher? Eile besteht keine, ich merke es mir vor. Einzelne Dateien aus der Liste sind schon auf commons.--wdwd (Diskussion) 20:05, 29. Nov. 2015 (CET)
@Leyo Wozu, bzw. wer sagt das? Solange Wikimedia es anders propagiert wäre dies nur ein inkonsistenter Hack gegen Wikimedia. Ist dies nur deine Meinung oder wo ist die tatsächlich vorausgegangene Diskussion (vernehmlich auf Commons) zu deinem Wiki-Syntax-Bild? Wenn Diskussion/Umfrage vorhanden empfehle ich daher für Dein Anliegen allg. einen Phab-Task. ↔ Benutzer: Perhelion23:47, 20. Aug. 2015 (CEST)
Ich verstehe deinen Einwand nicht. Es geht um (1) stimmt es, dass es mit (normalen) Leerzeichen tatsächlich nicht funktioniert und (2) könnte dies allenfalls umgangen werden? --Leyo00:12, 21. Aug. 2015 (CEST)
Letzter Kommentar: vor 9 Jahren11 Kommentare4 Personen sind an der Diskussion beteiligt
Ich schau in letzter Zeit öfter mal Kategorie:Wikipedia:Seite_mit_Einzelnachweisfehlern durch, und habe das über die letzten paar Tage nahezu leer und damit sehr übersichtlich gehalten. Dabei ist mir aufgefallen, dass immer wieder Seiten neu in der Liste auftauchen, die den Fehler schon "ewig" beinhalten. Ein Beispiel von heute ist Pfarrkirche Münzbach. In diesem Fall sieht es so aus, als wäre die Seite durch den Edit um 16. Nov. 2015 von der Software neu überprüft und die Wartungskategorie nachgetragen worden. Das fände ich zwar unschön, aber irgendwie plausibel.
Gestern hatte ich jedoch bei Einstrahliges Flugzeug einen neu in der Kategorie aufgetauchten Fall, wo der letzte Edit 22. Aug. 2015 stattgefunden hat. Irgendwie muss der Mechanismus hinter der Überprüfung also hier ein anderer sein. Weiß jemand was näheres über den Mechanismus? --Windharp (Diskussion) 10:39, 17. Nov. 2015 (CET)
Die Methodik, was als Fehler gilt, wurde vor wenigen Wochen erweitert; es werden inzwischen wesentlich mehr und/oder andere Fehler durch Mediawiki gefunden. Wir hatten intern aber auch schon kategorisiert, was wir jetzt wieder zurückbauen.
Die Neukategorisierung erfolgt immer dann, wenn ein Artikel bearbeitet wurde; ggf. auch aus anderen Gründen.
Es wird erfahrungsgemäß Wochen bis Monate dauern, bis die Altbestände durch den neuen Algorithmus gegangen sind, und in dieser Zeit werden immer mal wieder alte Neuzugänge hereintröpfeln.
Okay, also primär die Methode die ich vermutet habe. Danke PerfektesChaos. Ich vermute es gibt keinen Mechanismus der für Vollständigkeit der Prüfung sorgt? Naja irgendwas muss ja auch in Zukunft zu tun bleiben :-) --Windharp (Diskussion) 13:21, 17. Nov. 2015 (CET)
Irgendwo steht die Aussage, dass Artikel spätestens nach 30 Tagen neu durch den Parser geschickt werden - 30 Tage nach entsprechenden Softwareänderungen sollte also nichts neues mehr auftauchen, außer es werden neue Fehler eingebaut natürlich. Selbst dann kann der letzte Edit aber lange zurückliegen, wenn das Problem durch eine Vorlagenänderung entsteht. --mfb (Diskussion) 13:36, 17. Nov. 2015 (CET)
Es ist richtig, das Artikel nach 30 Tagen neu durch den Parser geschickt werden, aber nur wenn sie auch gebraucht werden. Dies hat aber nur Anzeigeeffekte, die Kategorieeinträge bleiben unverändert. Hier hilft einfach warten. Hat auch den Vorteil, das es nicht zu viele auf einmal sind. Außerdem würde es die Server sehr belasten, wenn man für diesen Zweck die Millionen-Seiten entsprechend neu auswerten muss. Der Umherirrende18:48, 17. Nov. 2015 (CET)
Nun, Seiten mit weniger als einem Aufruf pro Woche haben wir recht wenige. Wieso wird die Kategorieeinordnung nicht aktualisiert? Der Parser stellt doch fest, dass die Seite in die Kategorie soll, wäre sinnvoll dann auch die Kategorie zu aktualisieren. --mfb (Diskussion) 00:59, 18. Nov. 2015 (CET)
Ich meine das war schon immer so. Hintergrund wird wohl sein, das ein reiner lesender Zugriff keinerlei Schreibzugriffe machen soll, damit er von den Slaves bedient werden kann. Ansonsten müsste der Lesezugriff ja von den Mastern bedient werden und die sind vermutlich genug beschäftigt. Der Umherirrende17:27, 18. Nov. 2015 (CET)
Und was wird mit dem Parser-Output dann gemacht? Weggeworfen? Den zu speichern ist auch ein Schreibzugang. Die Aufrufzahlen, ggf. der "gelesen"-Zustand in der Beobachtungsliste, ... geschrieben wird praktisch immer. --mfb (Diskussion) 00:54, 19. Nov. 2015 (CET)
Keine Ahnung, warum man diese Infos nicht weiterverwendet werden. Dafür stecke ich da auch nicht tief genug drin. Die Abrufzahlen werden aber "verteilt" geschrieben und dann vom jedem Server zusammengesammelt. Sie werden nicht synchron in eine Datenbank geschrieben. Der Umherirrende10:13, 22. Nov. 2015 (CET)
Ich habe die Infos die mich interessiert haben, Danke dafür. Da die Diskussion wohl an einem Punkt ist wo wir hier sowieso nichts tun können damit wohl erledigt
Letzter Kommentar: vor 8 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
führt bei mir zum Rauswurf aus dem Wikikonto und zum Löschen des Geschriebenen. (S. auch Thread Fehlfunktion des Linksymbols oberhalb)
Es ist gleichgültig, ob ich das mit der Vorlage oberhalb des Browserfensters mache oder mit den Hilfen unterhalb. --Orik (Diskussion) 09:26, 10. Mai 2015 (CEST)
Windows Vista: Beim Verlassen des "Bearbeiten"-Modus IMMER Warnhinweis
Letzter Kommentar: vor 8 Jahren10 Kommentare5 Personen sind an der Diskussion beteiligt
In Windows Vista:
Beim Verlassen des "Bearbeiten"-Modus kommt immer der Warnhinweis "Möchten Sie wirklich ...? Das Verlassen dieser Seite kann dazu führen ...", auch wenn darin absolut nichts angefasst wurde.
Problem tritt nicht auf: a) in Windows 7 (de:WP); b) unter Vista in der englischen, französischen, italienischen oder schwedischen WP. --Uli Elch (Diskussion) 11:02, 5. Feb. 2015 (CET)
(Schon lustig. ) Also eigentlich (sollte) ja die Meldung nur kommen wenn das Feld geändert wurde. Nun gibt es tatsächlich in den Einstellungen eine Option für den Check (also ein wikiinternes Script dahinter, welches ich nicht benennen kann). Was ich aber eher vermute ist ein Fremd-Script oder -Funktion die den Inhalt des Feldes in irgendeiner Weise verändert. ↔ Benutzer: Perhelion11:11, 5. Feb. 2015 (CET)
Danke für die schnell erfolgte Antwort. Dann müßte sich Fremd-Script oder -Funktion blitzschnell und unsichtbar hinein schleichen, denn die Warnmeldung kommt ja nach "Bearbeiten" und sofort > "Abbruch" (oder Rückpfeil oben links). Vielleicht kennst Du ja noch irgendeinen Dinosaurier, der in der de:WP Vista benutzt; dann könnte man in der Tat sehen, ob es mein Privat-Problem oder ein allgemein deutsches ist. --Uli Elch (Diskussion) 11:32, 5. Feb. 2015 (CET)
Wichtiger als das Betriebssystem wäre der Browser. Hast du das Problem auch mit anderen Skins? Und ausgeloggt? --mfb (Diskussion) 16:12, 5. Feb. 2015 (CET)
+1
Der Browser (IE?) ist maßgeblich.
Die Wiki-Überwachung reagiert darauf, dass das Bearbeitungsfeld den Status „geändert“ erhält. Das kann durch eine Browser-Fehlfunktion erfolgen, würde aber in allen Sprachen gleich ablaufen.
Die Veränderung könnte durch unsichtbaren Whitespace ausgelöst worden sein, etwa ein Zeilenumbruch hinter dem Text, wenn noch keiner da war. Der Vergleich auf der Diffpage ignoriert das.
Interessant wäre, ob die Meldung auch mit einem anderen Browser kommt.
Fremd-Skripte sehe ich keine, weder hier noch global, höchstens Gadget/Common, aber dann müssten auch andere Benutzer berichten.
@Uli Elch: Die Info welcher Browser genutzt wird ist hier noch notwendig/wichtig. Eventuell mit einem anderen Browser auf dem Rechner versuchen ob das Problem auch existiert. Der Umherirrende10:52, 7. Feb. 2015 (CET)
Hallo - ich mag zwar ein brauchbarer Schreiber sein, bin aber software-mäßig ein DAU! a) Immerhin habe ich jetzt herausgekriegt, dass ich offenbar einen "Internet Explorer 8" verwende; ich vermute, dass das der Browser ist. b) Was sind "andere Skins"? c) Problem Warnmeldung tritt wie beschrieben auch dann auf, wenn nicht als Benutzer in WP angemeldet. d) Was ist ein "anderer Browser", und wie kriege ich den zum Laufen - und dann wieder weg?
Dir kann ich zumindest umreißen, was eine „Skin“ ist: Hilfe:Skin.
Rückfrage: In den anderen Sprachen und Wikis – hast du da auch überall das Häkchen gemacht auf der Seite Spezial:Preferences#mw-prefsection-editing beim überall dritten Kästchen, bei uns beschriftet: „Warnen, sofern eine zur Bearbeitung geöffnete Seite verlassen wird, die nicht gespeicherte Änderungen enthält“?
Für Vista ist sicher auch das Download einer aktuelleren Version des IE möglich. Geht normalerweise recht einfach: Rechts außen in der Menüleiste ist ein „Über …“ oder „Hilfe“ – dort irgendwo gibt es „Browser aktualisieren“. Wäre wohl ratsam, weil auch sichereres Surfen.
@Werkstattler:
IE, 8, soso. Ich könnte es geahnt haben.
Zur Funktionsweise: Der ursprüngliche Inhalt wird an ein data-Attribut gehängt; beim Versuch des Verlassens auf byteweise Identität geprüft.
IE8 könnte data nicht sauber unterstützen.
Ein Zeilenumbruch oder BOM könnte irgendwie hinzugekommen sein.
Müsste man aber eigentlich und weltweit mal von gehört haben.
Schon mal schönen Dank, PerfektesChaos. a)Skin habe ich jetzt wohl so grob kapiert. b) In allen anderen erwähnten Sprachen und Wikis ist auch überall das erwähnte Häkchen gesetzt, genau wie in de:WP. c) Den Rest muss ich mir noch mal in Ruhe anschauen; IE neuer als IE8 soll irgendwelche Nachteile haben, muss noch mal einen befreundeten Experten fragen (auch, ob ich den neuen IE bei Bedarf wieder runter kriege!). Ulkig aber, dass es nur in der de:WP auftritt. --- Auch ein schönes Wochenende! --Uli Elch (Diskussion) 17:49, 7. Feb. 2015 (CET)
Generell sind in diesem Wiki derartige Zeichensymbole unerwünscht, da sie bei vielen Lesern nicht erkennbar sind.
Vielmehr würden wir lieber kleine Icon-Dateien Plik: sehen.
Frage doch mal auf Portal Diskussion:Bahn nach,wie das hier gehandhabt wird; vielleicht gibt es dafür eine kleine Szablon – bei den Autobahnen wird das so gemacht.
Wenn du hier Übersetzungen aus einem anderen Wiki anlegst, möchten wir übrigens gern deren Versionsgeschichte importieren; siehe Wikipedia:IMP.
Letzter Kommentar: vor 8 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo,
Ich habe mir die beta Version auf meinem Samsung galaxy tab 4 angesehen (Android Version 4.4.2) angesehen.
mir ist schnell ein Fehler aufgefallen, wenn man auf das Lupen-Symbol drückt soll wohl eine Navigationsleiste erscheinen.
Ich sehe dort keinerlei Text, kann aber die Links anklicken und werde auch weitergeleitet.
Nur leider weiß ich nicht wohin, da ich den Text nicht sehen kann.
Wir werden versuchen, deine Beobachtung an die Entwickler weiterzuleiten.
Nur bin ich im Moment ratlos, um welches der auf Wikipedia:Technik/Skin/Beta genannten Features es sich bei einer „beta navigationsleiste“ handeln würde.
Ich selbst bin nicht mobil unterwegs, eigentlich im Wiki-Urlaub und werde in wenigen Minuten verglüht sein.
Letzter Kommentar: vor 8 Jahren10 Kommentare7 Personen sind an der Diskussion beteiligt
Am 4.3. um 16:16 hat eine IP besagten Artikel bearbeitet, den ich als Sichter drei Minuten später revertiert hatte. Soweit ist noch alles in Ordnung. Aber am 5.3. um 10:23 wurde ein Fehler behoben, den ich nicht verursacht habe. In der Beschreibung wurde fälschlicherweise gesagt, dass meine Änderung rückgängig gemacht wurde. Dabei wurde ich noch über die Benachrichtigung informiert. Wieso hat der entsprechende Automatismus zugeschlagen? -- Raubsaurier (Diskussion) 21:02, 7. Mär. 2015 (CET)
Wenn ich da mal weiter fragen darf: Wenn man eine länger zurückliegende Bearbeitung rückgängig macht, dann wird also nicht alles, was zwischen diesem Zeitpunkt und heute liegt, auch aufgehoben? Gilt das dann für einen Abschnitt oder wie darf man sich das vorstellen? --Karsten Meyer-Konstanz (D)21:44, 7. Mär. 2015 (CET)
Sofern der betroffene Abschnitt nicht weiter bearbeitet wurde, schafft die Software das. Andernfalls bekommt man eine Meldung Die Änderung konnte nicht rückgängig gemacht werden, da der betroffene Abschnitt zwischenzeitlich verändert wurde. (Beispiel)
Ich vermute die Nachricht zum Zurücksetzen kommt von der URL (&undoafter=138629126&undo=138640011), nicht davon was genau man auf die Seite schreibt. --mfb (Diskussion) 21:47, 7. Mär. 2015 (CET)
Richtig. Echo nutzt die Versionskennung aus undo/undoafter zur Ermittlung des Benutzers. Die eigentliche Änderung ist auch in der Zusammenfassung erwähnt, nur nicht verlinkt, daher kommt man da nicht direkt drauf. Der Umherirrende22:16, 7. Mär. 2015 (CET)
Das Problem an a) habe ich jetzt nicht verstanden; aber b) geht so: In der Versionsgeschichte oder bei einer Diffpage auf die gewünschte Basisversion gehen, diese bearbeiten und ggf. nichts weiter machen außer speichern. LG --PerfektesChaos23:05, 7. Mär. 2015 (CET)
Die Antwort auf a) dürfte sein: In der Versionsgeschichte oder auf einer Diff-Seite in den Stammdaten auf "rückgängig". --nenntmichruhigip (Diskussion) 23:25, 7. Mär. 2015 (CET)
Stimmt, danke euch beiden. Klar - in der Versionsgeschichte gibt es ja bei jeder einzelnen Änderung die Möglichkeit dazu. Und deine Lösung, PerfektesChaos, ist natürlich auch logisch - nur dass es nicht ersichtlich ist - außer, man schreibt's halt selbst in den Kommentar. --Karsten Meyer-Konstanz (D)23:53, 7. Mär. 2015 (CET)
Letzter Kommentar: vor 8 Jahren11 Kommentare5 Personen sind an der Diskussion beteiligt
Hallo zusammen, ich habe eben die Einstellung .mw-disambig gefunden und in meine globale CSS-Datei eingebunden, weil ich das standardmäßige Rot zu penetrant finde. Lade ich eine Seite mit einem BKL-Link, dann erscheint der Link während des Ladens in der von mir eingestellten Farbe, wenn die Seite jedoch fertig geladen ist, ändert sich die Hintergrundfarbe wieder auf den Standardwert. Was mache ich falsch? Viele Grüße – Filterkaffee (Diskussion) 13:41, 9. Apr. 2015 (CEST)
Eine kurze Erklärung möchte ich dann aber doch noch einfügen. Ich hatte den entsprechenden Quellcode in meine CSS-Datei kopiert, danach trat das Problem aber weiterhin auf. Die Lösung ist, die BKL-markierung nicht über Fliegelflagel zu aktivieren, sondern über die Einstellungen. Die Fliegelflagel-Erweiterung liest die CSS Datei nicht, deswegen konnte das nicht so funktionieren. Viele Grüße – Filterkaffee (Diskussion) 16:57, 9. Apr. 2015 (CEST)
Welche Problemdimensionen Fliegelflagel hier hinzufügt, weiss ich nicht, aber das ursprüngliche Problem ist, dass MediaWiki von sich aus (und zwar erst seit neuerer Zeit: meta:Tech/News/2014/38) BKL-Links die Klasse "mw-disambig" verpasst. Diese Klasse hast du gefunden und die Links per CSS entsprechend gestylt. Das Helferlein Begriffsklärungs-Check (das natürlich erst nachträglich geladen wird, deshalb der Effekt, dass es erst klappte) fügt um solche Links aber noch ein span mit der Klasse "bkl-link" hinzu, und dessen (standardmässiger) CSS-Style hat dann deine Angaben für .mw-disambig überschrieben. Das Helferlein einfach auszuschalten, hätte anstatt der erneuten CSS-Änderung auch geholfen, wobei dann auch der hochgestellte Text "BKL" verschwunden wäre. --YMS (Diskussion) 17:09, 9. Apr. 2015 (CEST)
Danke für den Hinweis auf die neue Klasse. Ich habe das für mich entsprechend geändert, weil ich eine nur-CSS-Lösung schöner finde. Der Text "BKL" ginge eigentlich mit :after auch in CSS, aber für die Hochstellung finde ich keine wirklich gute Lösung. Egal, brauche ich eh nicht. --nenntmichruhigip (Diskussion) 18:34, 9. Apr. 2015 (CEST)
@Filterkaffee, YMS: Ihr seid euch hoffentlich der Tatsache bewusst, dass durch die CSS-Lösung im Gegensatz zu den Javascript-Lösungen Weiterleitungen auf BKLs, also etwa Ap, nicht mehr markiert werden? --Schnark09:49, 10. Apr. 2015 (CEST)
das Helferlein nicht aktivieren und deine global.css so ändern, dass sie .mw-disambig{background-color: #cfefcf;} und das oben von Schnark geschriebene (für den Text "BKL") enthält.
CSS: Vorteil: einfach, schnell, funktioniert in allen Projekten (also insbes. in global.css). Nachteil: Weiterleitungen auf BKLs werden nicht markiert, keine Unterscheidung möglich zwischen BKL, Falschschreibung und obsoleter Schreibung.
Gadget BKL-Check: Vorteil: einfach, für weitere Kategorien konfigurierbar, Nachteil: langsam, ungepflegt (insbes. funktioniert die Konfiguration höchstwahrscheinlich nicht mehr).
Mein Skript: Vorteil: konfigurierbar, theoretisch in allen Projekten einsetzbar, Nachteil: komplizierter zu aktivieren und konfigurieren als das Gadget (der erste Punkt fällt natürlich weg für Leute, die Fliegelflagel verwenden), „theoretisch in allen Projekten einsetzbar“ heißt in der Praxis nur: de.wikipedia und en.wikipedia (wobei weitere Projekte kein Problem sind, aber von mir von Hand konfiguriert werden müssen).
Mischbetriebe von verschiedenen dieser Varianten sind problematisch und sollten daher vermieden werden. --Schnark09:22, 11. Apr. 2015 (CEST)
Vor kurzem habe ich bemerkt, dass in meinem Android-Browser (2.3.6 auf Samsung Galaxy S plus) das Suchfeld von http://de.m.wikipedia.org/wiki/Wikipedia:Hauptseite nur noch als verschwommener grauer Balken angezeigt wird, der sich nicht mehr für eine Eingabe anwählen lässt (es öffnet sich stattdessen ein Menü, bei zurück schließt der Browser). Identisches Verhalten im mobilen Firefox-Browser. Kann leider den Beginn dieses Effekts zeitlich nicht eingrenzen. BTW: Auch die Auf-/Zu-Zeichen bei den Menüpunkten werden nicht mehr angezeigt, womöglich werden hier nun Zeichen verwendet, die Android 2.3.6 nicht kennt. Fände es ärgerlich, wenn aufgrund von Änderungen (Gründe?) die mobile Wikipedia-Nutzung mit Android 2.3.6 nur noch eingeschränkt möglich wäre. (nicht signierter Beitrag vonClapham44 (Diskussion | Beiträge) 10:05, 26. Mai 2015 (CEST))
Ist bei mir auch schon seit ein paar Wochen (Monaten?) so. Aber da die Suche davor auch schon länger nicht mehr richtig funktionierte… Tipp: Ganz unten auf "klassische Anschicht" klicken, da funktioniert die Suche normal ;-) --nenntmichruhigip (Diskussion) 11:03, 26. Mai 2015 (CEST)
Mir war auch schon aufgefallen, dass da was anders aussieht. Hatte es aber bisher noch nicht ausprobiert, weil ich mir jetzt (seit der Link protokollrelativ gemacht wurde) angewöhnt habe auf "Klassische Ansicht" weiterzuklicken… Also: Bei mir ist das Suchfeld jetzt schmaler als es sein sollte (<50%) und die Suchvorschläge funktionieren nicht. Eingabe und Volltextsuche geht aber. Jedoch habe ich ein so sehr veraltetes Gerät dass ich selbst nur eingeschränkten Support dafür geben würde, also wenn's bei @Clapham44: funktioniert wär's ok für mich :-) --nenntmichruhigip (Diskussion) 10:35, 16. Jun. 2015 (CEST)
Letzter Kommentar: vor 8 Jahren9 Kommentare7 Personen sind an der Diskussion beteiligt
Hallo, ich lege relativ häufig neue Personenkategorien auf Commons an, um die überfüllten People-by-occupation-Kategorien übersichtlicher zu machen und die Verknüpfung der Commons-Inhalte mit den Wikipedia-Personenartikeln zu erleichtern. Die Anlage der Kategorien ist eine recht öde Tätigkeit: Namen für DEFAULTSORT umdrehen, Tätigkeitskategorie und eventuelle Zusatzkategorien bestimmen, Geburtsjahr- und ggf. Todesjahrkategorie eintragen, "People by name"-Kategorie ergänzen. Öde deshalb, weil die ganzen Informationen im deutschen Wikipedia-Artikel eigentlich schon vorliegen und nur angepasst werden müssen. Ist im Einzelfall kein dramatischer Aufwand, wird mit steigender Menge aber doch langweilig. Enorm hilfreich wäre ein Tool, das
den Sortierschlüssel aus einem jeweils vorgegebenen DE-Artikel ausliest und in die Defaultsort-Vorlage umsetzt
dann die im DE-Artikel vorhandenen Kategorien anhand einer von mir angelegten (und ggf. einfach erweiterbaren) Konkordanzliste übersetzt
und das Ergebnis so ausspuckt, dass ich es einfach auf die Commons-Kategorienseite kopieren kann
Beispiel: Wikipedia hat den Artikel Othmar Baier mit dem Sortierschlüssel {{SORTIERUNG:Baier, Othmar}} und den Kategorien [[Kategorie:Hochschullehrer (Technische Universität München)]] sowie [[Kategorie:Geboren 1905]]. Das Tool soll daraus {{DEFAULTSORT:Baier, Othmar}} und (nach einem Abgleich mit meiner Übersetzungsliste) [[Category:Technische Universität München faculty]] sowie [[Category:1905 births]] machen.
Ich habe keinerlei Ahnung von Software oder Programmierung und kann nicht einschätzen, ob sowas möglich ist bzw. wie aufwendig das wäre. Aber ich würde mich sehr darüber freuen, wenn jemand das angehen könnte... --Rudolph Buch (Diskussion) 19:07, 26. Aug. 2015 (CEST)
Klar, gehen tut das. @Rudolph Buch: verschieb dein anlegen mal nach Wikipedia:Bots/Anfragen. Per Bot geht das, den Defaultssort auslesen, und die Kats. Dann von den Kats über Wikidata prüfen, ob in Commons existent, und dann eine Liste anlegen. Wikidata ist nur nicht meine Sache, zumindest noch nicht, deswegen müsstest du dich wohl an einen anderen Botbetreiber wenden, also einfach dein anliegen dort schildern. Viele Grüße, Luke08151519:40, 26. Aug. 2015 (CEST)
Uhm, ich hab es falsch ausgedrückt: Ich will gar nicht, dass ein Bot den ganzen Vorgang für eine Vielzahl von Personen macht - sich jedes Bild und jede Person einzeln "menschlich" anzuschauen, ist schon sinnvoll, weil der Zusammenhang zwischen Bilddatei und Personenartikel nicht immer eindeutig ist. Aber mühsam im Sinne stupider Abtipperei ist dann, die Informationen aus dem konkreten WP-Artikel in Commons zu überführen: Ich habe bislang wohl an die 800 Commonskategorien angelegt, und da nervt es dann irgendwann allein schon, jedesmal die Namen wegen Defaultsort nochmal umgedreht eintippen zu müssen oder "1905 births" einzutippen, obwohl das im Grunde ja schon im WP-Artikel steht - nur halt auf Deutsch. Mein Traum wäre also ein Befehl "Liebes Script, bitte schau in den Artikel X und nimm die Kategorien, die da stehen. Vergleiche diese Kategorien dann mit einer Tabelle, die ich Dir gegeben habe. Und wenn Du in der ersten Spalte dieser Tabelle eine Kategorie aus dem Artikel findest, dann spuck die Category aus der zweiten Spalte der gleichen Zeile aus." Oder so ähnlich :-) --Rudolph Buch (Diskussion) 20:00, 26. Aug. 2015 (CEST)
Per API auf den Artikelquelltext zugreifen, nach Defaultsort und direkt eingebundenen Kategorien suchen, mit einer Liste abgleichen. Ist mit JS wohl gut machbar. Alternativ die Kategorien auch über die API holen, dann hat man Infoboxen besser abgedeckt. --mfb (Diskussion) 09:48, 27. Aug. 2015 (CEST)
Machbarkeitsabschätzung Vorlage für Dokumente in Cloude-Speicher mit Ausnahme für Editfilter
Letzter Kommentar: vor 8 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
Grundsätzlich halte ich Dokumente die in Cloude-Speicher (z.B. Google-Drive, Dropbox,...) für wenig Enzyklopädie-tauglich. Eine wesentliche Ausnahme sind Dokumente mit Backlinks von Seiten die den Kriterien von WP:Q oder WP:WEB voll entsprechen. Ein Beispiel dafür wäre der Backlink http://seedsoflifetimor.org/climatechange/resources/ der zu diesen Dokumenten führt: 238 Verlinkungen im ANR
Die Idee ist nun eine Vorlage zu bauen, die die URL des Backlink als Pflichtparameter, sowie die ID des Cloude-Speichers aufnimmt. Die Vorlage verlinkt auf das Cloude-Dokument, der Editfilter soll in diesem Fall nicht schlagend werden. Ev. könnte die Vorlage noch einen unsichtbaren zusätzlichen Wartungslink mit der ID produzieren.
Die Frage ist nun, ob es möglich ist, Edit-Filter zu bauen, die eine URL nicht filtern, wenn die entsprechende Vorlage verwendet wird. Frohes Schaffen — Boshomi☕⌨☺23:29, 7. Sep. 2015 (CEST)
Ist möglich, aber der Vorlagencode würde ein How-To, wie man den Editfilter umgehen kann. Ich denke das ist es nicht wert. --mfb (Diskussion) 00:06, 8. Sep. 2015 (CEST)
Hmm warte, ich hatte bislang an die URL-Blacklist gedacht. Im Bearbeitungsfilter kann man wohl zwischen Vorlage und Quelltext unterscheiden. Außer einer besseren Nachvollziehbarkeit sehe ich aber keinen Vorteil - man könnte immer noch beliebige Google-Drive-Links einfügen, außer wir erstellen eine Whitelist irgendwo. In dem Fall könnte man aber auch die normale URL-Black/Whitelist nutzen.
Das Problem, was ich eingangs erwähnte: Die URL-Blacklist verhindert recht erfolgreich massenhaften URL-Spam. Wenn eine Vorlage zeigt, wie man die umgehen kann, kann ein Spammer das auch abseits der Vorlage ausnutzen. --mfb (Diskussion) 16:14, 8. Sep. 2015 (CEST)
Defakto geht es mir um einen Vorlagenzwang für Dokumente aus Cloude-Speichern. Wenn die Vorlage verwendet wird gibt der Bearbeitungsfilter ruhe, ansonsten kommt die Meldung, dass die Vorlage zu verwenden ist, ansonsten wird das Abspeichern verhindert. Der Vorteil der Vorlage wäre die deutlich einfachere Überprüfbarkeit. Ich denke da an Bearbeitungsfilter, nicht an die Spamm-Black-List. Die kann man zwar mit White-List-Einträgen überroulen, aber das ist den meisten Benutzern zu kompliziert, und würde bei der Menge an Dokumenten irgendwann an Grenzen stoßen.
Die Frage ist also ob Bearbeitungsfilter tatsächlich auf URLs reagieren können, die durch Vorlagen generiert werden, und auf der Oberfläche unsichtbar sind. Das Problem der Umgehungsmöglichkeit ist wegen der Einschränkung auf wenige Cloude-Domains und dem gleichzeitigen Aufbau manueller Wartungslisten extrem gering, und falls man den zweiten .test-Link in einer Untervorlage steckt sowieso nur von Vorlagenspezialisten auffindbar. Frohes Schaffen — Boshomi☕⌨☺18:02, 8. Sep. 2015 (CEST)
Man kann auf hinzugefügten Text "drive.google.com" prüfen, und die Vorlage soll dann nur id=0B13RUdSV85KfN3Bxb3kyLW9VSjQ&usp=sharing&tid=0B13RUdSV85KfU0tDQ2ctV09Eb1U oder Ähnliches als Parameter bekommen sodass die Domain nicht im hinzugefügten Quelltext erscheint. --mfb (Diskussion) 18:27, 8. Sep. 2015 (CEST)
Letzter Kommentar: vor 8 Jahren13 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo zusammen! Ich bin die Frage schon einmal bei Wikipedia:Fragen zur Wikipedia losgeworden, aber da konnte mir keiner weiterhelfen. Vielleicht ist hier der richtige Ort:
Ich habe seit einigen Wochen das Problem, dass beim Laden der Editierierseiten hier manchmal der Editor nicht richtig geladen wird. Also die Zeile über dem Text (mit Signierbutton und so weiter) fehlt. Ich drücke dann meist auf "Vorschau zeigen", dabei wird ja die komplette Seite neu geladen, dann ist der Editor meist auch richtig zu sehen.
In Benutzer:Jobu0101/common.js machst du aber bereits das Gleiche in moderner; also kannst du es hier löschen.
Was genau darf ich mir eigentlich unter „Zeile über dem Text (mit Signierbutton und so weiter)“ vorstellen – wir haben oben zwei verschiedene Technologien dazu, siehe Hilfe:Symbolleisten.
Du hast zwei weitere wirkungslose Blöcke in Benutzer:Jobu0101/common.js, die ich an deiner Stelle löschen würde:
removeEditWarning – wird nicht gestartet, und würde man anders konfigurieren
if (wgAction=="edit") – tut nix, und irgendwann noch weniger.
Vielen Dank PC für deine schnelle und kompetente Hilfe.
Ich arbeite schon seit langem mit Vector.
Diese Leiste hier: .
Die Absicht war, dass in der Leiste, in der standardmäßig "Standard" ausgewählt ist, automatisch "WikiSyntax" ausgewählt wird. Nur leider sehe ich diese Leiste auch immer seltener.
Ich habe nun das $(selectswitch); mal auskommentiert. Nun wird die Leiste unten wieder angezeigt, nur natürlich nicht auf WikiSyntax umgestellt. --Jobu0101 (Diskussion) 11:42, 24. Sep. 2015 (CEST)
Dein selectswitch hat einen massiven Fehler:
Die drei Variablen tools, summ, sel sind nicht mittels var als Funktions-intern deklariert. Damit würden sie andere Variablen gleichen Namens im globalen Namensraum überschreiben, sofern es dort solche gäbe; was aber auch unklug durch den Autor eines anderen Skriptes wäre.
Einen Schalter [Standard] ./. [WikiSyntax] gibt es; aber nicht in der abgebildeten Leiste oberhalb des Fensters, sondern unterhalb bei einem dritten Werkzeug.
Darf ich dir dazu meine editToolStrIns anempfehlen? Sie wirken erstmal genauso, aber erlauben dir auch die zusätzliche Konfiguration eines eigenen Sortiments, auch etwa zum Einfügen von Vorlagen.
Dein einfacher Wunsch nach Änderung der Reihenfolge würde dann realisiert werden, indem man vor dem Laden angibt:
Ja, mir ist bewusst, dass es sich bei der Leiste, die ich nun als zweites ansprach (das war nicht mein ursprüngliches Anliegen), um eine andere handelt, die unterhalb des Editierfeldes angezeigt wird. Ich habe nun versucht, deine editToolStrIns einzubinden. Jedoch wird standardmäßig immer noch nicht WikiSyntax ausgewählt. Das Skript, das das vorher machen sollte, stammte übrigens nicht aus meiner Feder, aber drübergucken hätte ich wohk trotzdem noch einmal sollen. Vielen Dank für deine Hilfe. --Jobu0101 (Diskussion) 15:27, 24. Sep. 2015 (CEST)
Oh, sorry, ich habe dir eine etwas falsche Auskunft gegeben: Die fragliche Zeile muss lauten
Hintergrund ist, dass der interne eindeutige Bezeichner "[[]]" angegeben werden muss; „WikiSyntax“ ist nur ein beliebiger Text zur Anzeige ohne programmtechnische Bedeutung.
Geschrieben hatte ich das 2011, seitdem nur selten konfiguriert oder mit Anfragen zu tun gehabt; deshalb war es mir nicht mehr so präsent.
Wenn das erstmal funktioniert hat, magst du vielleicht noch etwas anderes ausprobieren; ersetze die fragliche Zeile mal durch
Habe deinen Spezielvorschlag nun endlich mal ausprobiert. Ich bekomme meine eigene Abkürzungsleiste, doch beim Anklicken der neuen Tools passiert nichts, außer dass das Fenster nach oben scrollt. --Jobu0101 (Diskussion) 10:45, 23. Okt. 2015 (CEST)
Inzwischen klappt es. Ich habe jedoch, bevor ich das hier schrieb, das Editierfeld mehrfach neugeladen. War wohl dennoch zu wenig. Vielen Dank, PerfektesChaos, für diese nette Möglichkeit, mir meine eigene Leiste zu basteln. --Jobu0101 (Diskussion) 10:54, 23. Okt. 2015 (CEST)
Übrigens: Das urspüngliche Problem haben wir durch diese Sache hier doch nicht behoben: Es kommt nach wie vor oft vor, dass die obere Werkzeugsleiste einfach fehlt. --Jobu0101 (Diskussion) 10:54, 23. Okt. 2015 (CEST)
Dann stürzt irgendwas ab, zumindest manchmal, je nach Rechengeschwindigkeit, und reißt die Werkzeugsleiste mit sich. Ein paar Fehlerursachen hatte ich oben schon mal identifiziert.
Um aus der Ferne nachvollziehen zu können, was bei dir los ist, bedürfte es Wikipedia:JS #Fehlerkonsole und nur weniger Zeilen an Fehlermeldungen, die beim Aufbau einer kaputten Bearbeitungsseite auftreten und sonst nicht.
Stand der Technik bei Extraktion von Vorlagenparametern?
Letzter Kommentar: vor 8 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Alle paar Monate gleiche ich TV-Episodenlisten und ähnliches mit meiner lokalen Datenbank ab, die ich andererseits wiederum mit IMDb und vergleichbaren Quellen abgleiche. Dazu kopiere ich normalerweise den Wiki-Quelltext und suche/ersetze ad hoc in meinem Editor die Aufrufe von beispielsweise en:Template:Episode list durch SQL-Tupel. Es juckt mir immer in den Fingern, das beispielsweise mit einem (Python-)MediaWiki-Parser zu automatisieren, auf der anderen Seite wäre eine direkte Lösung in JavaScript, die eine Textbox mit den extrahierten Daten zwecks Kopieren in die Zwischenablage anzeigt natürlich schöner.
Wie ist in Zeiten von Parsoid der Stand der Technik, mit Benutzer-JavaScript die Parameter von Vorlagen abzufragen? Hat jemand ein Beispiel-Script dafür? Ich möchte gerne:
=== Series 1 (1999) ===
[…]
{{Episode list
|EpisodeNumber=1
|Title=The Timber Frame Kit House
|Aux1=Newhaven, East Sussex
|OriginalAirDate=29 April 1999
|ShortSummary=Tim Cox and Julia Brock want to build their home on a clifftop in Newhaven.
|LineColor=ffc0b2
}}
[…]
in Tupel à la:
(1,1,'The Timber Frame Kit House','Newhaven, East Sussex'),
Es ist aber eine harte Nuss: Pipes können bei den Parameterwerten in Wikilinks auftreten, in eingeschachtelten Vorlagen, als Vorgabewerte von Parametern, innerhalb eines Kommentars unwirksam, in Bildeinbindungen, deren Bildlegende wieder Vorlagen und Bilder und sogar Tabellen nebst nowiki-unwirksamen Pipes enthalten kann. Ansonsten tun es triviale RegExps.
Über Spezial:ExpandTemplates und dem API-Modul dazu, kann man sich den Parse-Tree holen und versuchen, diesen zu interpretieren. Dann braucht man es nicht selber parsen. Ansonsten gibt es wohl einige Freie MediaWiki-Parser. Bei Parsoid weiß ich nicht, ob man auch an den ParseTree kommt und ob der einfacher ist.
Letzter Kommentar: vor 8 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo! Da ich noch nie mehr mit TemplateData gemacht habe, wollte ich hier mal ein paar Meinungen einholen, wie sinnvoll die Funktionalität bei doch eher komplexen Vorlagen wie konkret {{Charttabelle}} (im Zusammenhang mit {{Charteintrag}}, {{Charteintrag2}} und {{Chartauswertung}}) ist (zur Kenntnisnahme: @Mfb, Darkking3:). Ich sehe hier zum einen das generelle Problem des vermutlich eigenwilligen Ausgabeformats durch TemplateData, zum anderen aber natürlich die Schwierigkeiten durch Kombination und Alternierung mehrerer Einzelvorlagen sowie die variabel gehaltenen (von eingegebenen Parametern abhängigen) Parameter und deren Abhängigkeit untereinander. Gibt es bereits Versuche mit ähnlich aufgebauten Vorlagen? Ich hab mal mit grundsätzlichen Definitionen unter Benutzer:XanonymusX/Charttabelle begonnen.--XanonymusX (Diskussion) 15:47, 6. Mai 2015 (CEST)
Letzter Kommentar: vor 8 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
In jedem ortsbezogenen Wikipedia-Artikel findet man oben rechts einen Link „Karte“. Ein Klick öffnet die OpenStreetMap-Karte und zeigt dort den Ort mit einem Marker hervorgehoben. Alle Wikipedia-Artikel „in der Nähe“ werden auf der Karte ebenfalls mit einem Marker bezeichnet. So sollte es sein. Warum werden aber nicht die Wikipedia-Artikel der Stadtteile von Neustadt bei Coburg angezeigt (z.B Thann, Meilschnitz, Haarbrücken, usw. ), obwohl es diese alle seit ein paar Monaten gibt??? --Störfix (Diskussion) 18:14, 27. Mai 2015 (CEST)
Letzter Kommentar: vor 8 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo! Eine kurze Nachfrage: unter Hilfe:Tabellen für Fortgeschrittene#Sortierbare Tabellen steht Eine sortierbare Tabelle erkennt man daran, dass sie in den Spaltenköpfen kleine Doppelpfeilsymbole zeigt. … Die Symbole sind auch als Icons ( und schmal ) verfügbar. Heißt das, man kann irgendwie die Sortierfunktion mit schmalen Icons statt des Standards durchsetzen? Welche Einstellung ist dazu nötig? Gruß--XanonymusX (Diskussion) 11:49, 2. Jul. 2015 (CEST)
Mit folgender CSS-Definition kannst Du die Symbole schmaler machen:
Was heisst den "funktioniert nicht" genau? Gibt es Fehlermeldungen? Funktioniert es mit einem anderen Browser, oder wenn man den "privaten Modus" vom Browser benutzt? --Malyacko (Diskussion) 13:17, 12. Aug. 2015 (CEST)
Laut Spezial:CentralAuth/J. K. H. Friedgé ist Commons Bestandteil deines Globalen Benutzerkontos. Kann es sein, das du Cookies so stark eingeschränkt hast, das sie für "*.wikimedia.org" nicht funktionieren? Was ist wenn du dich auf Commons zu erst anmeldest, bist du dann hier nicht angemeldet? Der Umherirrende14:12, 12. Aug. 2015 (CEST)
Hallo @Umherirrender:, bin etwas spät, aber Deinen Vorschlag kann ich schlecht ausprobieren, weil ich dann meine ganze "Automatik" abschalten müsste. Was ist da in commons/wikimedia anders? Die Annahme von cookies ist bei mir insoweit reglementiert, als dass sie beim Verlassen der Seite gelöscht werden.
Das erstaunlichste ist ja, dass ich meine Benutzerseite in commons aufrufen kann, indem ich auf der "Globale Benutzerkonten"-Seite auf den commons-link klicke?
Beim nächsten Neustart werde ich versuchen die "Automatik" zu überlisten ;=)
J. K. H. Friedgé (Diskussion) 11:14, 14. Okt. 2015 (CEST)
Nach einem Versionsimport kommt es häufig vor, dass ein Artikel als "noch nie gesichtet" gilt (taucht auf Spezial:Ungesichtete Seiten auf), aber nicht direkt gesichtet werden kann. Man kann dieses Problem zwar beheben, indem man zunächst auf "Sichtung entfernen" und dann auf "Sichten" klickt, jedoch bitte ich um eine allgemeine Fehlerbehebung.
immer wieder fällt mir auf, dass es bei nicht maximierten, beispielsweise an den linken Rand gepackten Fenstern Probleme bei der Anpassung des Seitenlayouts (insbesondere in der Kopfzeile) und somit beim Responsive Design gibt. Ich vermute, dass das ein technisches Problem ist, das sämtliche Wikipedias umfasst und mit der Kernsoftware zu tun hat - ist das richtig bzw. wo kann ich wen auf diesen Bug aufmerksam machen?
Vielen Dank! :)
Falls du damit meinst, dass bei recht schmalem Bildschirmfenster die Tab-Reiter wie hier „Projektseite“ | „Diskussion“ | „Lesen“ | „Bearbeiten“ nach unten über die Überschrift klappen – das Problem ist leider gut bekannt; Meldungen nicht erforderlich. LG --PerfektesChaos21:37, 13. Okt. 2015 (CEST)
Auf den Admin-Anfragen wurde angemerkt, das sich die Danken-Funktion im Safari nicht richtig funktioniert bezüglich des ausblenden und einblendens der Rückfrage.
Es kommen haufenweise Ressourcen und Cookies mit. Es kann gut sein, dass die eine URL einen erforderlichen Cookie oder ein Script liefert, wodurch sie gut funktioniert, während die andere URL nicht alles mitbringt und deshalb erstmal nicht den Inhalt anzeigt, aber nach Besuch der anderen URL alles hätte, insbesondere einen Cookie-Wert.
Wenn die eine nicht richtig funktioniert, aber die andere, dann nehmt halt die andere.
Wenn ich in der Mobilansicht unten auf den Button In einer anderen Sprache lesen tippe und mir eine Sprache auswähle, lädt der Artikel in der anderssprachigen Wikipedia nicht in der mobilen Ansicht sondern in der klassischen Ansicht. Der Link führt auch zu lang.wikipedia.org/wiki/$1 und nicht zu lang.m.wikipedia.org/wiki/$1. Besonders auf kleinen Bildschirm ist die Normalansicht oft schwerer zu lesen und jedes mal von Hand ein m. in die URL zu schreiben ist zwar zielführend, aber nicht besonders komfortabel. --Freddy2001DISK20:33, 27. Okt. 2015 (CET)
Bisher war es afaik so, dass das in einem jeweils für z.B. wikipedia.org (also sprachunabhängig) gültigen Cookie gespeichert wurde. Statt die URL umzuschreiben kannst du auch ganz unten auf "Mobile Ansicht" klicken. Eine richtige Lösung (z.B. wie bisher) wäre natürlich dennoch wünschenswert. --nenntmichruhigip (Diskussion) 21:48, 27. Okt. 2015 (CET)
Letzter Kommentar: vor 8 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Gibt es eine Möglichkeit per API festzustellen, wann ein entsprechender Artikel importiert wurde, bzw. welche die Version in der Versionsgeschichte ist, die den Import darstellt? --Jobu0101 (Diskussion) 09:38, 31. Okt. 2015 (CET)
Du kannst das Import-Logbuch per API auslesen (list=logevents&letype=import). Es gibt aber keine Möglichkeiten die importierten Versionen festzustellen und die Import-Version in der Versionsgeschichte. Einzige Annahme für die Import-Version, es ist die Version mit dem ähnlichen Zeitstempel (muss nicht Sekundengenau sein) wie der Log-Eintrag. Der Umherirrende09:45, 31. Okt. 2015 (CET)
Wenn man bei der Importversion einen Vergleich mit der vorherigen anstellt über die Wikipediasoftware, dann sagt sie, dass beide Versionen identisch seien. Das geht doch ohne Import gar nicht bei aufeinanderfolgenden Versionen, weil die Software sonst das Abspeichern als neue Version verweigern würde, oder? Vielleicht könnte das helfen. --Jobu0101 (Diskussion) 10:02, 31. Okt. 2015 (CET)
Mobil aufgerufene Änderungen als besucht markieren
Letzter Kommentar: vor 8 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Es scheint so, als dass Änderungen, welche von der mobilen Beobachtungsliste aufgerufen werden, in der Desktop-Ansicht danach immer noch in Fettschrift als unbesucht angezeigt werden. --Freddy2001DISK19:08, 26. Nov. 2015 (CET)
[[Benutzer:[Niemand]|[Niemand]]] dankte dir ... (Benachrichtigung zum 'Danke'-Button)
Letzter Kommentar: vor 8 Jahren8 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo Technik-Team,
ich habe eine Anfrage zu einem anderen MediaWiki-Wiki, welches aber mit der WP in Beziehung steht - konkret ist es das '''Regiowiki AT''' (http://regiowiki.at/).
Es geht um die Funktionalität vom 'Danke'-Button in der Versionsgeschichte von Artikeln. Der Button funktioniert scheinbar korrekt, aber die Anzeige der Benachrichtigung beim Empfänger beginnt leider immer mit dem offensichtlich eigentlich als Benutzer-Link vorgesehenem Text [[User:[Niemand]|[Niemand]]] (direkt vor: 'dankte dir für deine Bearbeitung auf ...'). Diese eigenartige Form der Benachrichtigung tritt bei allen Benutzern im Regiowiki AT auf, sowohl unabhängig ob sie selbst Danken oder Bedankungen von Anderen erhalten, als auch scheinbar unabhängig vom die Bedankung betreffenden Artikel.
Zu diesem Thema gibt es bereits eine ältere, aber leider für mich praktisch nicht wirklich hilfreiche, kurze Anfrage vom Betreiber vom Regiowiki AT (Karl Gruber) selbst und bereits mit einer kurzen Antwort dazu unter 'Wikipedia:Fragen zur Wikipedia' (siehe Danke-Button von Juni 2015) - beides hier im Vollzitat (nur ohne Links):
Danke-Button
Eine Frage zu einem anderen Wiki: Woran kann das liegen, wenn ich als Danke ein [[Benutzer:[Niemand]|[Niemand]]] dankte dir für deine Bearbeitung statt dem Usernamen erhalte. Das Erwähnen funktioniert einwandfrei. (Egal von welchem Benutzer) --danke im Voraus K@rl 11:03, 15. Jun. 2015 (CEST)
Wenn dun auf einer Seite erwähnt wurdest, die später gelöscht wurde, sehen die Benachrichtigungen ähnlich aus. Eventuell etwas mit Renameuser oder Usermerge. --MGChecker – (📞| 📝| ) – HDR 17:06, 17. Jun. 2015 (CEST)
In dem diese eigenartigen 'Danke'-Benachrichtigungen betreffenden 'Regiowiki AT' wird die MW-Software noch in der Version 1.23.6 eingesetzt (Angabe der Versions-Spezialseite).
Ich bitte daher um ganz konkrete Angaben zu den möglichen Gründen der Entstehung dieses Fehlers in den Benachrichtigungen. Insbesondere um den Hinweis auf alle konkreten PHP-Dateien oder Konfigurationsdateien, die an der Erstellung dieser Benachrichtigung beteiligt sind oder sein könnten, inklusive den Ablaufdetails des gesamten Vorgangs dazu. Vielen Dank, schon im Voraus!
Hallo Umherirrender, Danke für die Info, aber mit dem Bug T64435 kann ich bezüglich dem konkreten Fehler leider nichts anfangen. Dieser Bug hat mMn eigentlich mit der MW-Erweiterung 'Danke' kaum etwas zu tun bzw. sehe ich den tatsächlichen Zusammenhang bisher noch nicht. Außerdem habe ich darin leider auch keine konkrete Angabe zur erforderlichen Behebung/Korrektur, die in diesem Fall im Regiowiki AT durchzuführen ist, gefunden. -- Gruß, Sonne7Disk!15:08, 9. Apr. 2016 (CEST)
Mit der Danke-Erweiterung hat er zu tuen. Neben dem Fall, das der Benutzer komisch aussieht, gibt es manchmal auch den Fall, dass die Seite nicht richtig dargestellt wird. Dieser Fall ist im Bug beschrieben.
Leider gibt es noch keine Behebung oder Korrektur, die angewendet werden kann (Bug ist noch "open"). Technisch ist der Fall so, dass der Auslöser des Dankes nicht mehr ermittelt werden kann. Dies passiert beispielsweise wenn ein Benutzer über eine andere Erweitung gelöscht oder zwei Benutzerkonten zusammengeführt werden. Der Umherirrende16:09, 9. Apr. 2016 (CEST)
OK, in welcher Datei passiert das? Also welche Datei ist konkret dafür zuständig? Bitte um den Pfad und den Dateinamen. Ich werde sie mir einmal selbst ansehen, mal sehen ob ich darin etwas dazu finde :-) -- Gruß, Sonne7Disk!16:24, 9. Apr. 2016 (CEST)
Wenn man sich aber bedankungen akutell hier in der Wikipedia anschaut, so ist der Benutzer nicht im Text verlinkt, daher kann es sein, das bereits mit einer neueren Version das Problem behoben ist. Der Umherirrende17:28, 10. Apr. 2016 (CEST)
Führt man ihn während einer Bearbeitung aus, dann wird der gesamte Inhalt durch den übergebenen Wikitext ersetzt, überführt in das Format des VE. Nur bei Vorlagen gibt es eine Sache, die mich stört: Lässt man sich etwa {{cite web|first=first name|last=last name|title=title|url=http://en.wikipedia.org}} einfügen, dann kommen im letztendlich erzeugten Wikitext Leerzeichen um die Gleichheitszeichen (sichtbar, wenn man sich die Änderungen vor dem Abspeichern zeigen lässt).
Daher meine Frage: Wo geht die Information über die genaue Formatierung verloren (wenn man einen Artikel mit Vorlagen bearbeiten, bleibt diese ja im Normalfall auch erhalten)? Oder noch besser: Was muss ich ändern, dass der beim Speichern erzeugte Wikitext exakt mit dem eingefügten übereinstimmt? --Schnark11:50, 23. Sep. 2015 (CEST)
Letzter Kommentar: vor 7 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Ich fände eine "Meist gesehen"-Auflistung, wie auf der enwiki (TOP 25 Report) auch für die deutsche wiki nicht schlecht. Jedoch fänd ich es passender, wenn man es monatlich macht, nicht wöchentlich wie auf der englischsprachigen Version. Falls es schonmal diskutiert wurde, sorry, aber ich find hier irgendwie keine Suchfunktion. Was haltet ihr davon?
Hallo. Vor einigen Tagen ist mir aufgefallen, daß bei mir, wenn ich mich in den sorbischen Wikpedien anmelde, einige Gadgets nicht laufen. In der Konsole vom Firefox erscheinen Meldungen, die mit folgenden Texten anfangen:
"Exception thrown by ext.gadget.Direct-link-to-Commons"
"Exception thrown by ext.echo.base"
Hinter beiden Meldungen erscheint denn jeweils noch ""TypeError: mw.config.get(...) is null" TypeError: mw.config.get(...) is null" mit einem gänzlich unübersichtlichen Link. Seltsam ist, daß manchmal sogar noch 2 weitere ähnliche Meldungen auftauchen. Das Problem liegt nicht am Browser, denn bei anderen Browsern laufen die problematischen Gadgets auch nicht. Welcher Code in hsb:MediaWiki:Common.js bzw. dsb:MediaWiki:Common.js muß vollständig ersetzt werden und wie? Ich habe mir schon hiesige Hilfsseiten dazu angesehen, verstehe aber nur Bahnhof. :-( Oder haben die Browser wegen der vielen Skripte schlicht ein Timingproblem?
Ich bin dort zurzeit der einige Admin, dem das Problem aufgefallen ist. Wahrscheinlich nutzen die anderen keine Gadgets oder nur solche, die laufen. Ist es möglich, daß irgendwelche Skripte "mw.config" ruinieren, sodaß sich nichts davon mehr auslesen läßt?
Unangemeldet funktioniert die Einklappfunktion bei den Vorlagen hsb:Předłoha:Infokašćik/LocMap wjacekróć beim Beispiel "Dwě mapje" und den folgenden sowie dsb:Pśedłoga:Infokašćik/LocMap wěcej raz beim Beispiel "Dwě kórśe" und danach problemlos. Aber angemeldet geht es in keinem Browser. Die zugehörige Funktion in Common.js heißt dort "GeoBox_Init". In der obersorbischen Wikipedia hatte ich diese Funktion gestern oder vorgestern nach der französischen Wikipedia aktualisiert. Es läuft nur unangemeldet. Warum?
Gestern hatte ich mal provisorisch meine vector.js geleert. Gebracht hat das aber gar nichts. Also muß der Fehler in Common.js oder einzelnen Gadgets liegen. Ich weiß ja, daß in Common.js dort alter Kram steht, weiß aber leider nicht, wie der aktualisiert werden muß. :-( --Tlustulimu (Diskussion) 10:10, 16. Feb. 2015 (CET)
Ich hatte gerade mal probiert, wie das Wiki reagiert, wenn ich alle Gadgets ausschalte und sie nacheinander wieder aktiviere. Bei hsb:MediaWiki:Gadget-HotCats.js traten die Fehler wieder auf. Aber ich habe das Gadget inzwischen nach der Version der Esperantowikipedia aktualisiert. Jetzt scheinen die Fehler verschwunden zu sein. :-)
Ich würde empfehlen, diesen Abschnitt hier rückstandsfrei auszuschneiden und in Wikipedia:Technik/Werkstatt zu kopieren.
Danach wäre es ratsam, sich Wikipedia:Technik/Skin/JS/Obsolet danebenzulegen und Stück für Stück abzuarbeiten. Das schließt vermeidbare Ursachen aus und hält auch die Fehlerkonsole übersichtlich.
Letzter Kommentar: vor 6 Jahren11 Kommentare3 Personen sind an der Diskussion beteiligt
Mir ist die Idee gekommen eine Kategorie für einen speziellen Grund und für einen speziellen Namensraum zu schaffen (konkret in dem Bereich habe ich das noch nicht getan). Daher vorab hier die Frage, uzw. geht es um Wikipedia: und Seiten die eigentlich Diskussionsseiten sind (wie diese hier). Ich vermute davon könnten einige Scripte (oder Bots) profitieren (bestimmte Bedingungen nur dort, momentan löse ich das mit einer statischen Textliste direkt im Script, aber ich hatte auch schon mittels API nach divers Templates (AddNewSection oder __NEWSECTIONLINK__) oder Autoarchiv gescannt). Es sei denn es gibt schon eine bessere Lösung? Ich weiß nur dass PerfektesChaos hier auch irgendwie eine Prüfung mit seinem Script macht/braucht. Kann man das so in Angriff nehmen? :-) ↔ Benutzer: Perhelion11:31, 6. Feb. 2015 (CET)
Also du meinst etwas wie Forumsseite, die es ja auch in einem Portal geben könnte.
Screengrabbing auf Desktop ist einfach: if( $("#ca-addsection").length ) {
Wenn das nur Skripte und Bots benötigen, sollte das nicht mit einer Kat geschehen, die auch irgendwer pflegen muss, sondern sie sollten sich das Zeugs on-the-fly aus der aktuellen Seite grabbeln.
Ähm* ja, da hätte ich tatsächlich auch alleine drauf kommen können. Das mit der API hatte ich schon mal etwas ähnlich (jedoch wesentlich umständlicher) TMg meinte aber das wäre zuviel des Guten… für so ein Script das im Dauer-/Massenbetrieb sein könnte. Vielen Dank, ich werde dies auch gleich einbauen. ↔ Benutzer: Perhelion14:05, 6. Feb. 2015 (CET)
Jetzt gibt es doch noch einen entscheidenden Haken den ich tatsächlich vergessen hatte (und der Grund ist warum ich das bis jetzt noch nicht so gemacht habe). Im Editiermodus gibt es leider diese schöne Schaltfläche nicht mehr. :-/ Dann bleibt tatsächlich nur noch die API? Oder ich würde auch mit Cookies hantieren, allerdings müsste man dafür wohl alle Bearbeiten-Knöpfe überwachen um dann diese gesuchten Seiten vorher einzufangen (da die Seite wohl leider neu geladen wird)⁉ ↔ Benutzer: Perhelion22:27, 7. Feb. 2015 (CET)
API ist sicher, funktioniert in allen Skins, mobil, und sonstwie.
Du müsstest ansonsten bei jeglicher normalen Seitenansicht in die sessionStorage vorsorglich reinschreiben, dass dies eine Forumsseite wäre. Cookie ist ganz schlecht, weil die den Traffic erhöhen und bei jeglicher Anfrage nach einem Bildchen usw. zum Server geschickt werden.
Ich habe den Code erfolgreich umgesetzt (wie gesagt hatte ich ihn sogar schon mal). Da nun, wie ich sehe diese Function auch von anderen Scripten (s. z.B. hier #Position des Signatur-Buttons verändern) verwendet werden kann (und auch bei meinem Smilie-Script evtl. Missbrauch vorgebeugt werden könnte), würde ich diese als Modul hier ablegen meta:User:Perhelion/forumPage.js, allerdings ist/wird die Abfrage dann etwas komplizierter, da auf die API-Antwort wohl gewartet werden muss. (PS: beim Suchen von Seiten habe ich gleich mal die nicht unbekannten Wikidata-Einträge für Forum und Hilfe:Tags in die richtige Richtung geschoben. :-P) ↔ Benutzer: Perhelion22:11, 11. Feb. 2015 (CET)
@Perhelion:
Du sollst meine Verlinkungen nicht entstellen.
Du sollst WSTM nicht auf Forumsseiten einsetzen; dafür ist das nicht gedacht.
Du kannst dir auf Phab ja wünschen, dass du ein JS-Array aller props gleich mit der Seite mitgeliefert haben möchtest; so wie Wikipedia:JS/V#wgRestrictionMove oder zumindest in der Vorschau wgCategories. Dann sind sie sofort da; auch die normalen Tokens bekommt man heutzutage ohne erneuten API-Abruf.
Oh* sorry, ich war wieder gedanklich woanders (man verbringt einfach zuviel Zeit hier und man wird nicht jünger), werd ich mir hinter die Löffel schreiben. Danke auch für den Hinweis (ich habe mir mal erlaubt auch deinen letzten Link zu fixen, nach ein klein wenig Suche⁉). Ja, das mit wgCategories wäre auch nicht schlecht. Dann werde ich mal dem Pfad deine Rates folgen (und meiner Wege gehen). :) ↔ Benutzer: Perhelion12:12, 12. Feb. 2015 (CET)
Letzter Kommentar: vor 6 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo zusammen, ich bin unsicher, ob ich hier richtig bin. Bitte also um Nachsicht. Frage: In Bundeshaushaltsplan (Deutschland) gibt es eine Liste, die mit "0" beginnt und das auch soll. Das tut sie aber nur im Firefox, nimmt man den IE beginnt sie mit "1". Das muss als an dem <li value="0"> liegen. Hat jemand eine Idee, woran es liegt? --He3nryDisk.16:07, 18. Dez. 2015 (CET)
Am IE. Quelltextmäßig ist alles richtig gelaufen. Aber der IE kann das nicht (wobei der Vergleich ziemlich veraltet wirkt). Vorschlag: 1. nochmal explizit als solches festlegen, dann wird im IE nur die erste Zeile falsch angezeigt. --mfb (Diskussion) 18:05, 18. Dez. 2015 (CET)
Soweit so gut, nur haben wir nun im IE eine doppelte "1". Ich mag ich glauben, dass es für dieses IE-Problem keinen Workaround gibt. --He3nryDisk.09:10, 19. Dez. 2015 (CET)
Letzter Kommentar: vor 6 Jahren8 Kommentare4 Personen sind an der Diskussion beteiligt
Derzeit werden standardmäßig die letzten 50 Beiträge angezeigt, wenn man sich die Beitragsliste eines Benutzers anzeigen lassen will. Man kann dann wählen zwischen (20 | 50 | 100 | 250 | 500). Ich hätte gerne standardmäßig 250 Beiträge rückwärts angezeigt. Kann man das in erweitern? In den Helferlein? Am besten auch gleich auf 1000, also:
Erledigt-Vermerk nochmal raus: eigentlich wollte ich ja nur meine letzten 1000 Beiträge einsehen können. Mit der Änderung bekomme ich jetzt aber auf Spezial:Letzte_Änderungen bzw. Spezial:Neue_Seiten ebenfalls die letzten tausend Seiten. Mich stört es nicht weiter, wollte aber darauf aufmerksam machen, dass sich die Änderung auf alle Spezialseiten bezieht. Aus meiner Sicht: überlastet das nicht die Server? Ist das so gewollt? --Informationswiedergutmachung (Diskussion) 21:17, 26. Jan. 2015 (CET)
Bei mir steht drunter wofür das Limit genutzt wird: "Dies umfasst die Liste der letzten Änderungen, die Versionsgeschichte und die Logbücher.". Fehlt nur ein Hinweis auf die Benutzerbeiträge wo es anscheind auch funktioniert. Der Umherirrende16:38, 29. Jan. 2015 (CET)
Überschriftensimulationen an Typografie-Update anpassen
Letzter Kommentar: vor 6 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo,
kann jemand bitte die Überschriftensimulationen (1, 2, …) an die aktuell standardmäßige Formatierung der Überschriften anpassen? Das wurde nach dem Typography refresh anscheinend nicht gemacht.--CENNOXX20:23, 26. Jan. 2015 (CET)
Das geht deshalb nicht trivial, weil Skin-abhängig.
Es müsste global von der jeweiligen Skin der Stil der Klasse zugewiesen werden, und dann diese dem H1 – dann könnten wir auch in dieser Vorlage davon Gebrauch machen.
Das wurde auch bereits irgendwo hier im Projekt diskutiert.
Vielleicht gibt es schon eine Phab-T.
Bislang war das Erscheinungsbild immer ähnlich gewesen; jetzt weicht Vector ab.
Eigentlich sieht es aber auch nicht schlecht aus, wo es eingesetzt wird.
Wir könnten mit schwer verhältnismäßigem Aufwand für sämtliche Seiten lokal ein workaraund definieren.
Falls der 4. Dezember 2024 noch nicht vorbei ist, so ist es dieser, ansonsten ist es 8. Januar 2025. --Schnark09:27, 30. Jan. 2015 (CET)
Das heißt, falls ich mich nicht verrechnet habe, ist das gesuchte Datum 8. Januar 2025. Natürlich geht das vermutlich irgendwie auch schöner, aber PHP hat nun mal bereits die notwendige Logik für die Wochentage eingebaut, dann kann man sie auch nutzen, das erleichtert auch die Umstellung auf andere Wochentage. --Schnark09:33, 30. Jan. 2015 (CET)
@Schnark: Ah, danke; bei #ifexpr war ich gestern Abend auch schon gewesen, aber zu müde für eine zuverlässige Programmierung.
In PHP stecke ich nur oberflächlich, nicht in diesen Abgründen; hatte mich nur an unsere Hilfe:VP gehalten. Selbstverständlich ist first wednesday die sinnvollere Lösung als die bisher verwendeten Eigenbaukonstruktionen.
Dein Ausdruck scheint bei erstem Nachvollziehen richtig zu sein. Eleganter wird es auch kaum gehen.
Hallo Ihr, ich bin megaschwer beeindruckt, von der schnellen Erzeugung einer verständlichen (und funktionierenden!) Lösung! Ich finde sie enorm nützlich und werde sie sicher weiter empfehlen! Vielen Dank! Vorlage:Smiley/Wartung/blumen -- FCT Berlin • ?! • 11:07, 30. Jan. 2015 (CET)
Nachdem ich nochmal darüber nachgedacht habe: Das schlägt fehl, wenn der Monatserste ein Mittwoch ist: 3. April 2024. Wenn man das first weglässt (das ich nur von einem vorherigen Versuch drin hatte), müsste es gehen: 1. Januar 2025 --Schnark11:50, 30. Jan. 2015 (CET)
Kopiert nicht, aber mindestens Hinweise darauf, dass es zu diesem, jenem und solchem Spezialfall weitere Möglichkeiten gäbe; Syntax und nähere Einzelheiten siehe GNU.
Wenn ich das Link anklicke, dann komme ich wieder bei Adam und Eva an, und hätte auch keine Veranlassung dazu, weil ich nicht ahne, dass es für mein aktuelles Problem etwas Neues gäbe.
Dies wäre mein zweites Problem, welches erst seit kurzem aufgetreten ist. So lassen sich die beiden Spalten im Bearbeitungsmodus und dann bei Vorschau zeigen, einwandfrei sortieren. Im normalen Modus tritt allerdings dieses Problem mit dem nach Zufall sortieren auf... --Kiepski1 (Diskussion) 19:28, 29. Apr. 2015 (CEST)
Nebenbei: Unsere Kollegen von der Nachbarwerkstatt Wikipedia:VWS sind hier eigentlich zuständiger, aber da gibt es einfach nur mehr Beobachter; wir hier können das auch, hier wie dort.
Könnte man nicht eine Vorlage erstellen, welche dieses Problem beheben würde ohne das Aussehen der Tabelle zu verändern. Ich hätte da an folgendes gedacht:
Es gibt imme rnoch das Problem, dass nur Admins das Patrol-Log ausbelnden können, was man endlich beheben sollte, indem man * das patrolmarks-Recht zuweist. Habe ich irgendwo schon mal angesprochen. --MGChecker – (📞| 📝| ) – HDR18:51, 25. Mai 2015 (CEST)
Die verlinkte Seite ist für Admins also tatsächlich sinnvoll nutzbar? ;) Und Admins haben die unsinnigen automatischen Sichtungen (>90% der Seite) sogar standardmäßig nicht in der Liste? Das wäre durchaus ein sinnvolles Feature für alle. --mfb (Diskussion) 19:05, 25. Mai 2015 (CEST)
Daß das patrol-Log für Nicht-Admins nicht sichtbar ist, hatte ich gar nicht mehr auf dem Schirm ;-)
Als Admin sehe ich folgendes: | Markierungs-Logbuch zeigen | Sichtungs-Logbuch zeigen | Dankeschön-Logbuch zeigen Die Pipe am Anfang stört, die hätte ich gern weg. Spezial:Log zeigt mir als Admin standardmäßig keine Markierungen, Sichtungen und Dankeschöns. Unangemeldet sehe ich Markierungs-Logbuch zeigen | Sichtungs-Logbuch zeigen | Dankeschön-Logbuch zeigen . Obwohl ich also Sichtungen nicht sehen sollte, sehe ich sie. Wtf?
Letzter Kommentar: vor 6 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo. Bei mir ist die Betafunktion "Hovercards" in der Esperantowikipedia seit einigen Tagen total verkorkst. Statt der Tooltips erscheint der Text unformatiert unterhalb der Liste der aktuellen Änderungen. Da sind wohl die Formate verschwunden. Leider weiß ich nicht warum. :-( --Tlustulimu (Diskussion) 21:14, 10. Aug. 2015 (CEST)
Wie finde ich denn die "Liste der aktuellen Änderungen" in einem Artikel? Oder bezieht sich dies nicht auf einen Artikel? Genaue Schritte zum Reproduzieren des Problems sehr willkommen. :) --Malyacko (Diskussion) 13:12, 12. Aug. 2015 (CEST)
In meiner dortigen Beobachtungsliste tritt der Fehler auch auf. Wenn ich die Gadgets alle ausschalte, bleibt das Problem bestehen. Es kann also kaum an einem Gadget liegen. --Tlustulimu (Diskussion) 10:19, 14. Aug. 2015 (CEST)
Skript zum farbig unterlegen auf Links zu Artikeln, die ein bestimmter Benutzer erstellt hat
Letzter Kommentar: vor 4 Jahren10 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo,
der ein oder andere hat ja vielleicht schon mitbekommen, dass im Moment viele Boxerartikel erstellt werden, die so gerade den RKs und Qualitätsstandards genügen, aber dann idR vor sich hingammeln. Der Benutzer ist nicht bereit, auf Ansprachen zu reagieren und ich und auch andere Benutzer ärgern mich/sich jedes Mal, wenn sie auf einen solchen Artikel stoßen. Ist es vielleicht möglich, dass ein JS-affiner Mensch ein Skript schreibt, welches Links auf Artikel, welche Benutzer XYZ erstellt hat, farbig unterlegt werden, ähnlich wie bei BKL-Links? Grüße --Der BuckesfelderDisk.bewertenE-Mail08:20, 26. Nov. 2015 (CET)
Ähnlich wie bei BKL geht es sicher nicht - dort hilft die Mediawiki-Software und gibt den Links eine Kennzeichnung, die dann nur noch sichtbar gemacht werden muss. Ein solches Script müsste sich irgendwo extern eine Liste der erstellten Seiten holen und dann jeden Link mit dieser Liste abgleichen. Wenn es dir um die Artikel geht und nicht um Links darauf, wieso nicht einfach diese Liste der erstellten Seiten durchgehen? Links auf relevante Personen sind fast immer sinnvoll, selbst wenn es den Artikel gar nicht gibt. --mfb (Diskussion) 11:46, 26. Nov. 2015 (CET)
Ach so, also exakt das Gegenteil der Suche die ich vorgeschlagen habe. Eine ignore-Funktion quasi. Ja, die möchte ich auch bei einigen haben. Ärgern Dich die Boxer denn so sehr? --Wassertraeger12:57, 26. Nov. 2015 (CET)
Für einen erfahrenen Programmierer wäre es noch nicht mal schwer, sondern Zusammenbasteln von Routine-Elementen.
Ich fürchte allerdings, es gibt niemanden, der Zeit dafür hätte.
Allgemeinverwertbar wäre ein Werkzeug schon, wenn man es von vornherein offen für viele Anwendungsfälle hielte.
Ich kann nur Realisierungstipps geben:
Immer, wenn man auf eine typische Seite käme, etwa die Beobachtungsliste, wird per API das Sortiment von vorgegebenen Regeln abgefragt.
Vorgegebene Regeln können sein:
Benutzer X hat Seite erstellt.
500 Antworten pro Abfrage; ggf. Kette von 500er Schüben.
Seite ist in Kategorie Y (das wäre analog der BKL-Falschschreibung).
Ich beobachte diese Seite.
Seite wurde in den letzten drei Tagen geändert.
Seite wurde seit drei Jahren nicht mehr geändert.
Jede Regel besteht aus einem vorgenannten Kriterium, einem Kurzbezeichner und CSS für diese Verlinkung.
Wenn alle API-Antworten beisammen sind, wird localStorage aktualisiert.
Das ist ein permanenter Textspeicher im Browser.
Damit sind für den Artikel sofort Ergebnisse da; und müssen nicht bei jedem Seitenaufbau erst geholt werden, was zu größerem Ruckler beim Seitenaufbau führt und Netzwerkkosten verursacht. (Cache-Prinzip; Besuch bestimmter Seiten aktualisiert den Cache. Sooo schnell kommen da auch keine Seiten dazu.)
Jeder Treffer erhält eine Zeile mit dem enkodierten Seitennamen, einem Leerzeichen und dem Bezeichner der Regel. In die allererste Zeile schreibt man den Zeitstempel der Aktualisierung.
Wenn irgendeine Seite (in bestimmten Namensräumen) aufgerufen wird, dann werden aus dem Inhaltsbereich alle Wikilinks analysiert.
Dabei wird der enkodierte Namensteil des Linkziels in der localStorage-Komponente mit vorangehendem Zeilenumbruch und nachgestelltem Leerzeichen gesucht.
Man könnte auch jedes Mal erst komplizierte JSON-Objkte parsen und aufbauen und dann darin Komponenten suchen. Zeichenkettensuche ist hier ausreichend und deutlich schneller.
Wenn es einen Treffer gab, kennt man den nachstehenden Kurzbezeichner und kann das diesem Bezeichner zugeordnete CSS dem Wikilink verpassen.
Man könnte auch aus dem Speicher eine gigantische CSS-Regel über womöglich Tausende von Seiten konstruieren und diese dann der kompletten Seite verpassen; aber das wäre voraussichtlich ineffizienter.
Zusätzlich zur CSS-Dekoration könnte man einem Kurzbezeichner auch aktive Funktionen zuordnen; etwa generierte weitere Verlinkungen, oder entlinken oder sonstwas.
OT: Du hattest kürzlich Datumsbedingungen aus dem XML für Internetquelle entfernt; hatte das den Grund, dass im vorhandenen Artikelbestand lauter unerwünschte Datumsangaben diese Bedingung auslösten, oder stürzte das Skript ab?
@PerfektesChaos: Danke für die ausführlichen Informationen. Leider kann ich das (noch) nicht, ab der Ehrgeiz hat mich gepackt und irgendwann habe ich das dann auch (hoffentlich umgesetzt).
Zur {{Internetquelle}}: Das Problem waren nicht die Altlasten. Die wandle ich ich eigentlich, sofern ich den Link bearbeite, in YY-MM-DD um. Vielmehr hatte der Vorlagenmeister Probleme mit neueingegebenen Daten in dem oben genannten Format. Ich konnte leider noch nicht herausfinden woran das liegt, hatte das aber noch vor. Doch durch nervende Stubs und vielen Diskussionen auf WP:VM, WP:QS usw. hatte ich einfach keine Lust und Reiz mehr. Deshalb war ich so egoistisch und habe die entsprechenden Zeilen einfach gelöscht. Falls du eine Idee hast, woran das liegen könnte, nur her damit. Grüße --Der BuckesfelderDisk.bewertenE-Mail13:07, 27. Nov. 2015 (CET)
@Skript-Idee:
Alle aufgelisteten Regeln sollten nicht nur auf Wikilinks vom momentanen Artikel aus gelten, sondern auch für die momentane Seite selbst. Da müsste dann im Seitenkopf ein Kasten angezeigt werden.
Eine weitere Regel könnte sein: Benutzer X hat innerhalb der letzten 50/100/500 Bearbeitungen (maximal 30/90/1000 Tage zurück) die Seite bearbeitet.
Ein Teil der Regeln eignet sich dazu, lokal zur Beschleunigung gespeichert zu werden (Seitenersteller, werden keine 10.000 sein; was beobachte ich? – Seiten in Kategorie/Unterkat); andere wie diese eben müssten live abgerufen werden.
Nicht nur Benutzer-Nicks, sondern auch IPv4-Ranges.
Bei hinreichender Flexibilität in Sachen Regeln würde ein solches Werkzeug in interessierten Kreisen durchaus Anklang finden.
@Vorlagenmeister:
Ich hatte dieses Vorlagenmeister vor einem Jahr geschrieben, damals erfolgreich getestet und seitdem alles vergessen. Ich werde mich, wenn ich mal einen Block konzentrierte Zeit habe, auf BETA an eine Rekonstruktion des von dir geschilderten Problems machen. Wohl eher Jahreswechsel.
Hallo! Man hat mir eine Version mit einer Referenz in ref-Tags im Artikel-Abschnittstitel gezeigt, die in der TOC ausgepackt wird. Ich habe mir die Version mal auf meine Spielwiese geholt: Benutzer:TaxonBot/Schweizer Armee Zum Probieren dürft Ihr den Artikel dort gerne bearbeiten
Problem:
in einer Abschnittsüberschrift wurde eine Referenz in ref-Tags editiert. Sieht so aus:
Panzer der Schweizer Armee [28]
=== Panzer der Schweizer Armee <ref>Urs Heller: ''Die Panzer der Schweizer Armee von 1920 bis 2008.''</ref> ===
in der TOC wird der Inhalt der Referenz ausgeschrieben. Sieht so aus:
9.3 Panzer der Schweizer Armee <ref>Urs Heller: ''Die Panzer der Schweizer Armee von 1920 bis 2008.''</ref>
Ich meine mich zu erinnern, dass dies schon mal anders funktionierte. Die ref-Nr. wird zwar in der Abschnittsüberschrift, wie es auch sein soll, angezeigt. In der TOC wird aber weder die ref-Nr. noch die Referenz selbst und schon gar nicht die ref-Tags angezeigt. Oder irre ich mich jetzt da. Schönen Dank – Doc Taxon • Diskussion • Wiki-MUC • 19:52, 7. Jun. 2015 (CEST)
Ich hab auch ’ne andere Agenda; aber es betrifft nicht nur uns, sondern Hunderte Wikis weltweit. Wird schon jemand von der enWP gemeckert haben.
Die Extension ist bekannt dafür, dass sie bestimmte Syntax innerhalb des ref nicht mehr richtig parsed; ist ein zehn Jahre alter Bug. Diesmal hat sie entweder einen weiteren Kinken abbekommen, oder die Verarbeitung von Überschriften wurde verändert und Wikisyntax innerhalb von Überschriften arbeitet nicht mehr. Gegen letzteres spricht group bei Liste der Herrscher Koreas.
Die Extension ist sowieso buggy, verpennt und schweigsam wie nur was; wundert mich nix.
@AKlapper (WMF): Ja, mit der Hilfe hab ich es versucht. Eine Meldung damit anzulegen ist mir dennoch nicht geglückt. Ich habe den "Assigned To" nicht gewusst und auch "Projects" (de:wp ?) in der Liste nicht gefunden. – Doc Taxon • Diskussion • Wiki-MUC • 02:49, 8. Jun. 2015 (CEST)
"Assigend To": Ein Task ist häufig jemand zugeordnet, wenn er gerade daran arbeitet oder ein Patch eingestellt hat und somit gearbeitet hat. Ein neuer Task wird im Normalfall nicht zugeordnet, dadurch landet er im großen Topf, aus dem sich jeder bedienen kann. Project wäre in diesem Fall "MediaWiki-extension-Cite", weil die Refs aus der mw:Extension:Cite stammen (Muss man nicht wissen, daher frei lassen). Der Umherirrende17:46, 8. Jun. 2015 (CEST)
In der Hauptsache: Die Änderung wurde rollbacked, war schon vor diesem Thread in der enWP aufgefallen.
Letzter Kommentar: vor 4 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Nur durch Zufall bin ich darauf gestoßen, dass „\color{Red}“ in der math-Umgebung das Rendering bei der PDF- bzw. Buchherstellung abstürzen lässt. Es gibt aber noch andere Codes, die ähnliches Unheil bewirken, so lassen sich die Artikel Huffman-Code und Regulärer Ausdruck nicht als PDF-downloaden. Gibt es jemanden der sich das erklären bzw. das ändern kann? Ich hatte die Frage auch hier gestellt, aber die Seite wird wohl nicht allzuoft frequentiert. Dank und Gruß von --Konrad Stein (Diskussion) 19:58, 7. Dez. 2015 (CET)
Fehlfunktion des Linksymbols oben im Bearbeitungsfenster
Letzter Kommentar: vor 3 Jahren10 Kommentare5 Personen sind an der Diskussion beteiligt
Wenn ich beim Artikelschreiben eingeloggt bin und einen Begriff mit Hilfe des Linksymbols oben im Bearbeitungsfenster verlinke, fliege ich beim weiteren Schreiben bei der nächsten Betätigung der Zeilensprungtaste aus meinem Wikipediakonto raus. Der eingegebene Text ist verschwunden und das Bearbeitungsfenster des Lemmas geschlossen. Wie kann das sein? Ich habe gestern beim Erstellen eines Textes 10 Versuche gebraucht, den Text fertigzustellen, wobei mir der Text jedesmal gelöscht wurde.--Orik (Diskussion) 00:00, 4. Mai 2015 (CEST)
Da empfehle ich Dir: Erstelle Deinen Beitrag in einem externen Editor, schreibe die links von Hand aus, und kopiere das fertige Projekt anschließend in das Bearbeitungsfenster. Da geht Dir der geschriebene Text nicht mehr verloren. J. K. H. Friedgé (Diskussion) 09:49, 4. Mai 2015 (CEST)
Wenn ich mit solch laienhaftem Vorgehen, das ich auch versucht habe, zufrieden waere, haette ich mich nicht an die technische Nothilfe gewendet. Waere es nicht passender, die Verlinkungssymbol ( eine Kette) aus dem oberen Rand des Bearbeitungsfensters zu nehmen, um nicht dieses jeden Tag zig-tausendfach auftretende Problem zu vermeiden? Oder man kann ja auch diesen Befehl, der oben am Bearbeitungsfenster sitzt, neu programmieren. Das schöne an dem Werkzeug im Bearbeitungsfenster ist doch, dass ich bereitstehende Symbole verwenden kann und nicht jeden Befehl voll ausschreiben muss. Man kann die Verlinkung auch mit dem Werkzeug am unteren Ende des Berabeitungsfensters machen, das ist nicht ganz so komfortabel, aber geht ohne Probleme. Das obere fehlerhafte Symbol ermöglicht gleichzeitiges Schreiben von Linkziel und einen abweichenden Linktext - - also eigentlich eine gute Einrichtung. --Orik (Diskussion) 10:43, 4. Mai 2015 (CEST)
Dass das Problem "jeden Tag zig-tausendfach" auftritt, darf wohl bezweifelt werden, dann gäb's längst jede Menge Beschwerden dazu. Bei mir scheint es jedenfalls nicht aufzutreten. Gerade hier im Abschnitt testweise gemacht: Text eingegeben, Link mit der Bearbeitungsfenster-Funktion gesetzt, Text weitergeschrieben,
Enter gedrückt, weitergeschrieben, Vorschau, alles gut, weitergeschrieben, Speichern, immer noch eingeloggt. Ist das bei dir hier heute noch reproduzierbar? Mit welchem Browser? --YMS (Diskussion) 11:22, 4. Mai 2015 (CEST)
Ich habe den Assistenten wieder demontiert, mal sehen ob es, Zeilensprung
klappt. Ja, ich bin nicht rausgeflogen. Es funkioniert. Danke für den Tip. Ich habe einen Mac, Syst 10.6.8 und den Safaribrowser 5.1.10 ( alles neuestmögliche Software). Gruss --Orik (Diskussion) 17:36, 4. Mai 2015 (CEST)
Meine Meldung war die eines absoluten Laien in der Technikwerkstatt. Konnte mal jemand den Bugreport vorschriftsmäßig machen? Das wäre schön. Orik (Diskussion) 04:57, 6. Mai 2015 (CEST)
Falscher Abschnitt in Zusammenfassungszeile bei mobilen Bearbeitungen
Letzter Kommentar: vor 3 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Wieso erscheint in der Zusammenfassungszeile dieses Beitrags „(→Einzugsgebiet)“, obwohl Du dich zum Streaming-Portal geäußert hast? Gruß und weiterhin viel Spaß Peter19:46, 3. Jun. 2015 (CEST)
Weil aus mir unerfindlichen Gründen ich bei der mobilen Anwendung ein paar Abschnitte höher bearbeiten muss, damit es am eigentlichen Ziel ankommt. Frag die Software-Entwickler, warum das so ist.--Gruß KriddlBitte schreib mir etwas.09:03, 4. Jun. 2015 (CEST)
Letzter Kommentar: vor 3 Jahren11 Kommentare6 Personen sind an der Diskussion beteiligt
Ich benutze Schnarks kombiniertes PD&ND-Skript derzeit extrem oft. Seit gestern nachmittag kann ich aber plötzlich nur noch die ND bearbeiten, aber nicht mehr die PD. Ich habe zwar Schnark gestern abend auf seiner Seite gefragt, woran es liegen könnte, aber bisher keine Antwort bekommen (auch kein Wunder, so lange ist das ja noch nicht her). Trotzdem frage ich hier nach, weil es für meine derzeitige Arbeit sehr wichtig ist. Ich habe gehört, dass immer Donnerstags Wikipedia-Patchday sei, kann es damit zusammenhängen? MfG --Informationswiedergutmachung (Diskussion) 11:09, 26. Jun. 2015 (CEST)
Es wird möglicherweise an der Änderung von Modul jquery.mwExtension zu Modul mediawiki.RegExp liegen. Schnark verwendet zwar mw.loader.using('jquery.mwExtension'), aber vielleicht ist irgendwo etwas vergessen. Hast Du unter Spezial:Einstellungen#mw-prefsection-editing die Option „Erweiterte Bearbeiten-Werkzeugleiste aktivieren“ aktiviert. Der WikiEditor lädt derzeit noch jquery.mwExtension. Vielleicht hilft das übergangsweise. --Fomafix (Diskussion) 11:28, 26. Jun. 2015 (CEST)
Ich hatte gestern Abend für einige Stunden ein vergleichbares Problem, das sich heute morgen entmaterialisert hatte (phab:T103891).
Browser-Cache heftig löschen.
Wenn du kannst, mal vorübergehend mw.loader.store.clear(); vorn in deine common.js einbauen.
Wenn du kannst, WP:JS#Fehlerkonsole nutzen und uns mögliche Details benennen.
Schnark schaut erfahrungsgemäß morgen früh rein.
Um die Ausgangsfrage zu beantworten: Ja, kann es. Der Plan von Fomafix ist nachvollziehbar.
"Erweiterte Bearbeiten-Werkzeugleiste aktivieren" war schon aktiviert, den Cache habe ich geleert, den mw.loader.store.clear(); eingebaut. Funktioklappt aber trotzdem nicht. Und mit WP:JS#Fehlerkonsole kenne ich mich so gut wie gar nicht aus. Nun ja, muss ich auf Schnark warten, danke für die Antworten. MfG --Informationswiedergutmachung (Diskussion) 12:20, 26. Jun. 2015 (CEST)
Es liegt daran, dass das Modul 'jquery.mwExtension' verwendet wird, bevor es geladen ist. Das Modul war vor der Änderung wohl standardmäßig bei jedem Artikel geladen, so dass die fehlende Abhängigkeit nicht aufgefallen ist. Jetzt wird das veraltete Modul nicht mehr geladen und dann gehen teilweise Skripte kaputt. Ich vermute aber, das alle diese Skripte auch schon vorher die Abhängigkeit nicht eindeutig deklariert hatten. (gerrit:219570, Abhängigkeit war sonst über 'mediawiki.util.js' immer gegeben, weil das Modul immer da ist). @Schnark: müsste migrieren oder die Abhängigkeit ergänzen (oder beides). Der Umherirrende16:39, 26. Jun. 2015 (CEST)
so wie es jetzt ist, ist es jedenfalls unbrauchbar. Mit Hand PD nachtragen oder sie zu überprüfen führt zu einem viel zu hohen Arbeitsaufwand. Gestern habe ich Gustav Laddey erstellt, üblicherweise brauche ich für einen Artikel (ohne Schreibfehlerkorrektur) genau zwei Edits: einen, um ihn neu reinzustellen und einen, um ihn mit PD & ND zu ergänzen. Das dauert keine Minute, gestern habe ich dafür fünf Minuten gebraucht. Die Bitte geht daher an Schnark das nach Möglichkeit schnell zu ändern, u.a. weil ich diese Liste (4.587 Fehler, noch) schnellstmöglich abarbeiten will. Zwar funktioniert das ND-Tool, aber oft genug sind die PD auch ungenügend und zweimal alles abarbeiten wäre reine Zeitverschwendung. --Informationswiedergutmachung (Diskussion) 17:36, 26. Jun. 2015 (CEST)
@Umherirrender: Verwende ich es denn irgendwo ohne die Abhängigkeit korrekt zu deklarieren? Für mich sieht es so aus, als handle es sich nur um Fehler in anderen Skripten, die dann halt auch meine beeinträchtigen. (Was nicht heißt, dass ich die Funktion nicht dringend ersetzten sollte, mein Testskript, das mich über Deprecations unterrichtet, dreht gerade durch und spuckt 8825 Warnungen aus.) --Schnark09:52, 27. Jun. 2015 (CEST)
@Schnark: Ich bin gestern auf eine Artikelseite einer Person gegangen und habe in der Konsole importScript( 'Benutzer:Schnark/js/personendaten.js' ); geschrieben, damit dein Skript geladen wird. Anschließend gab es "Das Objekt unterstützt die Eigenschaft oder Methode "escapeRE" nicht" in der Funktion wo staatenRe aufgebaut wird. Daraus habe ich geschlossen, dass die Funktion dann nicht zur Verfügung steht, wenn sie gebraucht wird. Du lädst die Funktion, aber anscheinend wird sie auch schon bei der Initialisierung benötigt und stand dann nicht zur Verfügung. IE11. Nach deiner Änderung funktioniert wieder alles ohne Fehler. Der Umherirrende10:28, 27. Jun. 2015 (CEST)
↔ Benutzer: Perhelion 10:10, 9. Feb. 2015 (CET)
--XanonymusX (Diskussion) 23:13, 17. Feb. 2015 (CET)
) – HDR 12:06, 30. Apr. 2015 (CEST)
) – HDR 18:31, 3. Jun. 2015 (CEST)
Wikiliebe ist wirklich nicht mehr wichtig ... – Doc Taxon • Diskussion • Wiki-MUC • Show some WIKILOVE • 13:49, 10. Jul. 2015 (CEST)
19:43, 27. Okt. 2015 (CET)
11:26, 26. Nov. 2015 (CET) P.S.: Schon schräg, ich könnte (bei entsprechenden Rechten) mittlerweile massenweise Seitenschutzeinstellungen ändern, aber ein simple Abfrage? Finde ich nicht...
08:22, 4. Dez. 2015 (CET)
.jpg)
(doofe Frage, für was steht MW?).--MBurch (Diskussion) 19:24, 12. Nov. 2015 (CET)
Nicola - Ming Klaaf 20:20, 9. Mär. 2015 (CET)
) Also eigentlich (sollte) ja die Meldung nur kommen wenn das Feld geändert wurde. Nun gibt es tatsächlich in den Einstellungen eine Option für den Check (also ein wikiinternes Script dahinter, welches ich nicht benennen kann). Was ich aber eher vermute ist ein Fremd-Script oder -Funktion die den Inhalt des Feldes in irgendeiner Weise verändert. ↔ Benutzer: Perhelion 11:11, 5. Feb. 2015 (CET)
--Kiepski1 (Diskussion) 14:02, 12. Jun. 2015 (CEST)
23:29, 7. Sep. 2015 (CEST)
15:56, 8. Sep. 2015 (CEST)
..png)
und schmal 
) verfügbar. Heißt das, man kann irgendwie die Sortierfunktion mit schmalen Icons statt des Standards durchsetzen? Welche Einstellung ist dazu nötig? Gruß--XanonymusX (Diskussion) 11:49, 2. Jul. 2015 (CEST)
Danke auch für den Hinweis (ich habe mir mal erlaubt auch deinen letzten Link zu fixen, nach ein klein wenig Suche⁉). Ja, das mit wgCategories wäre auch nicht schlecht. Dann werde ich mal dem Pfad deine Rates folgen (und meiner Wege gehen). :) ↔ Benutzer: Perhelion 12:12, 12. Feb. 2015 (CET)
-- FCT Berlin • ?! • 11:07, 30. Jan. 2015 (CET)