Benutzer Diskussion:Umherirrender/Archiv/2016-2

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

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

[[Benutzer Diskussion:Umherirrender/Archiv/2016-2#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Benutzer_Diskussion:Umherirrender/Archiv/2016-2#Thema_1

Artikel Studentenwerk Oberfranken

Nach meiner Kenntnis gehören externe Links nicht in den Fließtext eines Artikels. Habe ich da eine Änderung verpasst oder sollte dem Sichter dieses Artikels nur etwas mehr Arbeit gemacht werden?

MfG Jan Engelstädter (Diskussion) 15:45, 11. Jul. 2016 (CEST)

Ich habe mir die vorherige Änderungen nicht angeschaut und kann dir da leider nicht weiterhelfen. Der Umherirrende 17:30, 11. Jul. 2016 (CEST)

Alt wie ein Gnu und lernt immer noch was dazu.

Du kannst mir mal was erklären.

• Guck bitte auf diese Navileiste auf BETA.
  • Nach dem ersten Element jedes Blocks kommt ein Bruch in der Tabellenzelle, und das zweite bis letzte Element werden in ein <p></p> eingeschlossen.
  • In der Navi-Definition steht jedes Element auf einer eigenen Zeile.
  • Es braucht nowiki am Anfang der Tabellenzelle für eine fließende Darstellung.
  • Steht hingegen alles in einer Zeile, wie bei Atari_8_Bit, dann läuft es geschmeidig. Was natürlich weniger übersichtlich ist für die Pflege der Navi-Definition.
• Verstehn würde ich ja, wenn sich durch zwei Zeilenumbrüche am Anfang erstmal ein leerer Absatz ergibt, also ein leeres <p></p> und die Tabellenzeile ein Stück tiefer anfängt.
  • Greift sich Tidy dieses leere p und tütet da wilkürlich die erste Zeile rein? Aber warum die zweite bis letzte?
  • ?????????
• Natürlich war es grenzenloser Dilettantismus, statt dieses nowiki einmalig zentral in den Kern zu schreiben es in rund 1.500 Definitionen von Navileisten für jeden Block einzeln vor die Zeilen zu setzen.
  • Und noch dümmlicher war es, dass sich dann irgendwie ein <div /> als Geheimtipp herumgesprochen hatte, das im an den Leser ausgelieferten HTML-Dokument drinblieb, statt das aus dem ähnlichen Problem mit Sternchen und # zu Beginn von Vorlagenwerten bekannte nowiki zu nehmen, das serverseitig eliminiert wird und uns das Gerödel vor ein paar Tagen erspart hätte.
  • Ich hatte ja zuerst geglaubt, das leere Element würde von MediaWiki/Tidy generiert und konnte es nicht fassen, als ich dahinterkam, dass das in jeder einzelnen Navileiste schon drinstand.
• OT: Kannst du hier noch eine 3 spendieren? Ich mag solche Aktionen nicht.

LG --PerfektesChaos 22:16, 18. Jul. 2016 (CEST)

Das ganze Problem lässt sich ja herunterbrechen:

Test, wo das erste Wort auf der gleichen Zeile steht Test Zeile2

Test, wo das erste Wort eine eigene Zeile hat Test Zeile2

Man sieht, das im ersten Fall die neue Zeile ein eigenen paragraph bildet und daher der Umbruch kommt. Man kann dies vermeiden, wenn man auch in der Vorlage vor dem Parameter ein Zeilenumbruch hat oder ein nowiki setzt, was ja dann von einem Zeilenumbruch gefolgt wird (was der eigentliche Trick ist, das nowiki verhindert nur den trim). Der Parser erhalt die oben gemachten Zeilenumbrüche, wenn man die obrige Tabelle also mit dem Parser umwandelt, entsteht:

 <table class="wikitable">
 <tr>
 <td> Test, wo das erste Wort auf der gleichen Zeile steht
 Test Zeile2
 </td></tr>
 <tr>
 <td>
 Test, wo das erste Wort eine eigene Zeile hat
 Test Zeile2
 </td></tr></table>

Auch das ist noch ohne Paragraph, aber wenn jetzt die Logik für Absätze dazukommt, entstehen die paragrahs, dort werden td und tr besonders gehandelt (da close/open zum Rest vertauscht sind). Es ist nicht Tidy. Der Code steht in der vor kurzem refactored BlockLevelPass.php.

OT: Kannst du bei Wikipedia:Dateiwartung/Werkzeug/Optionen nach den Anker gucken? code ist eher unüblich dafür und warum ist das ß-beta so groß geschrieben (ragt in den Content-Bereich im IE11). Der Umherirrende 22:57, 18. Jul. 2016 (CEST)

Ja, aber warum macht der Parser diese Zicken? Ich würde ja verstehen

 <tr>
 <td> Test, wo das erste Wort auf der gleichen Zeile steht

 Test Zeile2
 </td></tr>

oder im zweiten Block; aber was soll der Unsinn bei Tabellen? „td und tr besonders gehandelt (da close/open zum Rest vertauscht sind)“?? Ist mir auch bislang noch nie aufgefallen. War das schon immer so?

@OT: Die div werden vom Skript expandiert und mit aktuellen Inhalten gefüllt; bloß nicht dran rühren.

• Das ß auf BETA ist so groß, damit es jeder sieht. Schon mal mit der Maus drüber gehovert, unter dem Ball?

LG --PerfektesChaos 23:21, 18. Jul. 2016 (CEST)

Ich würde sagen, das war schon immer so. Es vermeidet, das immer die komplette Tabellenzelle in ein paragraph gehüllt ist. Wenn es dafür noch Styles gibt, könnte das dem Tabellendesign schaden. Der Umherirrende 18:17, 19. Jul. 2016 (CEST)

Hilfelink auf Spezial:Log

Auf Spezial:Log und den einzelnen Logbüchern haben wir seit neuestem einen von MW automatisch erzeugten Hilfelink (und damit im Augenblick zwei übereinander). Auf MediaWiki Diskussion:Specialpage-helplink hat Benutzer:Entlinkt ja schon die Nachrichten verlinkt, die einen Hilfelink da platzieren. Die Nachricht, die überschrieben werden muss, um die lokale Hilfeseite zu verlinken, wirst du selber finden, ich bin gerade zu faul zum Suchen. Daher schreibe ich auch direkt hier, auf WP:AAF würde es in dieser Form höchstwahrscheinlich sowieso liegenbleiben, bis du es machst. --Schnark 12:16, 27. Jul. 2016 (CEST)

Danke für den Hinweis, den Gerrit Patch hatte ich gesehen, aber nicht gemerkt, das er auch schon gemerged ist. Ich habe MediaWiki:Log-helppage angelegt und den Hilfelink aus den Systemnachrichten entfernt. Der Umherirrende 19:00, 27. Jul. 2016 (CEST)

Gadget-Pfeil-hoch

Hi,

ich habe das Dingens mal auf BETA komplett neu gebaut.

• Es kommt jetzt wohl ohne die CSS-Seite aus, mit Skins und Prozenten und h und so Pflegefällen.
• Außerdem ein paar Eckchen schneller und robuster.
• Da stand was von Klassen und mw-heading drin, das habe ich nicht verstanden und erstmal rausgeworfen.
• Seiteninfos hätten auch Überschriften, da könnte man das noch mit reinnehmen, aber sooo lang und vielbenutzt sind die auch wieder nicht.
• Wie bisher wird nur der Content geschmückt; wobei eigentlich unten im body beim Impressum sowas ja auch nett wäre.
• Mir persönlich ist der Stil etwas mager, aber es soll ja auch nicht übermäßig auftragen.
• Restlos verstanden habe ich das sowieso nicht, und noch nie benutzt.

Viel Spaß beim BETATEST --PerfektesChaos 14:56, 24. Jul. 2016 (CEST)

Ich glaube den mw.loader.state sollte man im Gadget nicht selber verändern, hier sollte man sich auf die interne des ResourceLoader verlassen. Den Rest schau ich mir an, ob inline-css oder per css-File ist wohl eine Philosophie-Frage. Das mw-heading kommt von Entlinkt durch diese Änderung. Der Umherirrende 16:21, 24. Jul. 2016 (CEST)

• Der mw.loader.state schadet nichts, aber er blockiert erneutes Laden, wenn vorher durch Greasemonkey schon geladen wurde oder hinterher ein mw.loader.load("ext.gadget.Pfeil-hoch") gemacht wird. Ich habe das serienmäßig mit drin. Was anderes macht der RL auch nicht, bloß etwas später automatisch nochmal. Wenn ich ernsthafte Konflikte befürchte, dann blockiere ich sogar einen Zweitstart, falls der state beim JS-Laden nicht mehr jungfräulich ist.
• Das h1 der Seite liegt außerhalb des Content; deswegen war das insoweit wirkungslos. Ich habe es aber auch noch drin; für eine h1 innerhalb des Wikitextes.
• Ob man nun zwischen echten (Wikisyntax) und falschen (HTML-Syntax innerhalb des Content) unterscheiden müsse, kapiere ich nicht; für den Anwender sehen beide weitgehend gleich aus. Wenn manche den Pfeil bekämen und andere nicht, fände ich das verwirrend. Aber ich benutze das Ding ohnehin nicht.
• 2010 ist auch schon etwas her. Vielleicht war damals was anders gewesen.

LG --PerfektesChaos 16:38, 24. Jul. 2016 (CEST)

Der Grund für die Manipulationen mit .mw-heading war seinerzeit ein Kompatibilitätsproblem mit den verschiedenen Skripten, die die [Bearbeiten]-Links verschoben haben. Da letztere seit m:Change to section edit links nicht mehr vorhanden sind, sollten diese Manipulationen IMHO nicht mehr nötig sein. Gruß --Entlinkt (Diskussion) 00:39, 25. Jul. 2016 (CEST)

Ah, danke schön.

„… ob inline-css oder per css-File ist wohl eine Philosophie-Frage“ – nicht ganz.

• Das historische MediaWiki:Gadget-Pfeil-hoch.css hatte für jede Skin und jede Überschriftenart in Prozentzahlen den Kehrwert der Schriftgrößenerweiterung mitgenommen und außerdem ggf. wieder von Fettschrift runtergesetzt. Damit sollten alle Pfeile in etwa gleich aussehen.
• Das war bei jedem Typography-Refresh für alle Skins zu pflegen; einschließlich irgendwelcher Umstellungen der Dokument-Struktur, ignorierend vorstellbare individuelle Veränderungen des Überschriften-Stils.
• Hat sich erledigt; ich hole mir einmalig die Schriftgröße des <body> (bei mir "16px") und setze alle Pfeile auf Normalschrift aufrecht und diese Pixelgröße. Theoretisch müsste man noch die Schriftart vereinheitlichen (sans-serif), aber ich denke mir, ein ↑ wird sich da nicht so arg von Arial nach Roman unterscheiden. Könnte man auch noch etwas runtermultiplizieren, aber das fand ich mickrig; gäbe für User ja noch die Klasse. Ein schattiertes border hätte ich persönlich von Anfang an gesetzt, aber das würde die Leute heute erschrecken. Jedenfalls ist jetzt alles in einer Seite gekapselt und bis auf den deutschen Namen exportierbar.

LG --PerfektesChaos 01:31, 25. Jul. 2016 (CEST)

Nur so zur Info: Mir persönlich ist es relativ gleichgültig, was mit dem Gadget passiert, ich benutze es selbst nicht und hatte damals nur ein Problem gelöst (vielleicht nicht auf die optimale Weise, ist ja auch lange her). Eine Information zu den Schriftgrößen hätte ich aber noch:

Früher, d. h. vor m:Change to section edit links, skalierte MediaWiki die Schriftgrößen der [Bearbeiten]-Links einzeln für jede Überschriftenebene auf die gleiche Art und Weise wie dieses Gadget. Mit der Umstellung der [Bearbeiten]-Links erhielten diese in MediaWiki einheitlich das Schlüsselwort small, also geschah dasselbe auch mit dem Gadget (vgl. m:Talk:Change to section edit links#Font size).

Wenn du jetzt die Schriftgröße des <body> kopierst, passieren zwei Dinge: Erstens stimmt die Schriftgröße der Pfeile nicht mehr mit den [Bearbeiten]-Links überein, und zweitens entsteht eine starke Skinabhängigkeit (die Pfeile werden in Vector sehr, sehr, sehr viel größer als in Monobook, nämlich 16px vs. 10px). Ich würde das deshalb so nicht machen. Welches Ziel verfolgst du denn überhaupt mit dieser Änderung?

• Derzeitige Schriftgröße der [Bearbeiten]-Links und der Pfeile in allen Skins: small, bedeutet 13px
• Schriftgröße von <body> in Vector: medium, bedeutet 16px
• Schriftgröße von <body> in Monobook: x-small, bedeutet 10px

Gruß --Entlinkt (Diskussion) 10:39, 25. Jul. 2016 (CEST)

• Ich hab das auf BETA jetzt mal auf small gesetzt.
• Meine Intentionen:
  • Ich hatte mich an der Normalschrift der Seite orientiert, die der Sehgewohnheit am ehesten entspräche.
  • Die Einheitlichkeit zwischen Skins ist mir eher egal; wer monobooker ist, bleibt dabei, und das Erscheinungsbild eines Elements wird von der optischen Umgebung maßgeblich beeinflusst. Wer absolut gleich lang ist, ist auf Lilliput anders denn auf Krypton drauf.
  • Die Größe des Abschnittbearbeitenlinks hatte ich nicht auf dem Schirm.
• Wichtig war mir die robuste Abschottung gegen Typography refresh und irgendwelche Vererbungen der Zukunft; namentlich kursive Überschriften oder so Zeugs.
• Ich habe das Teil gestern erstmals näher angeguckt.
• Mir war das Dingelchen zu klein, deshalb war ich auf medium gegangen und freute mich auch über noch absolutere Pixel.
• Ich hätte damals ohnehin eher etwas wie ^ in ASCII mit ohne text-decoration geschrieben.

LG --PerfektesChaos 17:46, 25. Jul. 2016 (CEST)

Ich habe mir das auf Beta angeschaut, da es keine Funktionale Verbesserung gibt, lasse ich das Gadget hier so. Wie immer bei Gadgets, heißt es auch hier: Am Leben erhalten. Solange Gadget nicht anders geregelt sind, mach ich lieber nichts kaputt. Falls dir das nicht reicht, kennst du ja einen Weg, das du es auch selber dürftest ;-) Der Umherirrende 19:56, 28. Jul. 2016 (CEST)

Vorlage:Nicht drucken

Warum hast du die gelöscht? War es nicht unerwünscht, reine HTML-Syntax zu benutzen? Das Vorlagensystem ist doch weit flexibler, als den Wiki-Quelltext mit <div>'s zuzustopfen, nicht? So weit ich das beurteilen kann, hast du dich auch vorher nicht darum gekümmert, die Vorlageneinbindungen zu lösen (es sei denn, du hast das mit einer Sockenpuppe getan). Viel Spaß noch beim Umherirren. --Cmuelle8 (Diskussion) 20:50, 28. Aug. 2016 (CEST)

Ich halte es nicht für sinnvoll diese Form in Artikeln zu verwenden. Artikel sollten auf allen Ausgabemedien (einigermaßen) gleich aussehen. Etwas beim Drucken auszublenden sollte zentral beschlossen sein, wie es bei Navigationsleisten passiert. Alles andere ist unnötig auszublenden. Bei Verwendung innerhalb von Vorlagen ist es effektiver die HTML-Varianten zu verwenden. Es gab wenige Vorlageneinbindungen die ich mit diesem Benutzerkonto aufgelöst hatte. Der Umherirrende 21:38, 28. Aug. 2016 (CEST)

Noch ein ich in WP. Und da spende ich im Dezember immer für das wir. Ich kann nicht sehen, dass deine autokratische Entscheidung sinnvoll zentral beschlossen wurde, aber vielleicht bist du ja die Zentrale. Vielleicht ist dir entgangen, dass schon WP selbst, Layout und Inhalt trennt und damit deiner Forderung von sollte überall gleich aussehen schon nicht gerecht wird. Die Mobilversion und die Desktop-Version unterscheiden sich schon signifikant. Der Output in Pedia-Press sieht wiederum völlig verschieden aus, ebenso der in Kiwix. Auch HTML-Druckversion und PDF-Export weichen voneinander ab, völlig unabhängig davon, welche Einstellung du zu "noprint"-Anweisungen in Artikeln besitzt. Wenn also eine Rendering-Eninge Entscheidungen darüber treffen will, welche Inhalte ausgeblendet werden können, dann sollten WP-Autoren Möglichkeiten besitzen und nutzen, dass auch an diese automatisierten Prozesse zu kommunizieren. Wichtig dabei ist, dass die Engine nicht verpflichtet ist, noprint-Anweisungen umzusetzen, es hat also empfehlenden Charakter. Wenn einem Datenkonsumenten, das Desktop-Layout in einer Print-Version wichtig ist, steht es also immer frei, noprint zu ignorieren. Du hingegen malst einmal mehr grau drüber: Deine Farbe. --Cmuelle8 (Diskussion) 23:21, 28. Aug. 2016 (CEST)

Ich halte auch viel vom wir, aber nicht in der Situation sehe ich es als notwendig an. Wikipedia möchte Inhalte produzieren und diese auch anzeigen. Warum sollte man ganze Abschnitte aus Artikel nicht mit ausdrucken sollen? Sind sie für Papierleser unwichtiger als für Online-Leser? Diese Bewertung können wir nicht leisten. Die Bewertung was bei Offline-Reader wie Kiwix oder bei der Mobilen Version wichtig ist, haben aber die Entwickler abgenommen, das ist auch nicht immer schön. Daher sollte diese Möglichkeit in Artikel nicht eingesetzt werden. Es gibt auch Dinge mit nachteilen für die Druckversion, so möchten Benutzer Inhalte in Artikeln ausklappen und wundern sich dann das sie nicht ausgedruckt werden. Es spricht also auch etwas dafür, dieses Element nicht anzubieten.

Da es immer heißt, wenn es eine Vorlage gibt, ist es wohl ganz sicher in Ordnung sie zu verwenden, schien es sinnvoller die Vorlage zu löschen. Es gibt auch noch weitere Klassen die Eingriffe in die Darstellung neben und die nicht direkt in Artikeln verwendet werden sollten (nomobile, noviewer). Die Verwendung ist (aus meiner Sicht) für Navigationselemente oder sonstige Hinweis reserviert. Der Umherirrende 18:07, 29. Aug. 2016 (CEST)

Senf:

1. Wir verwenden im ANR (und auch sonst) die class="noprint" nur, um in der Druckausgabe unangemessene Zusatzhinweise zu unterdrücken:
   • Navigation, wie etwa {{Dieser Artikel}} und BKL-Hinweise usw.; außerdem die Navileisten.
   • Zusätzliche Animationsgrafiken; von diesen würde ansonsten nur das erste Bild als Standbild gezeigt.
2. Enzyklopädische Inhalte werden grundsätzlich nicht unterdrückt.
   • Von GeoHack sind dann vielleicht nur die Längengengrade und Breitengrade im Klartext sichtbar, während Links auf OSM usw. in der Druckausgabe sinnlos sind und wegfallen könnten.
3. Die class="noprint" wird in der Regel nur in der Vorlagenprogrammierung verwendet und die solcherart betroffenen Seiten bzw. Vorlagen werden kategorisiert, damit das überwacht werden kann.
   • Wir verwenden dabei HTML-Klartext, damit die Funktion ohne zusätzliches Nachschlagen nachvollzogen werden kann.
   • Extrem selten vorkommende HTML-Syntax verstecken wir deshalb nie in Vorlagen, weil sich niemand merken kann, welche genaue Wirkung die xy-Vorlage denn hier hätte und man sich sowieso die Programmierung ansehen muss.
4. Die Inhalte sind auf allen Ausgabemedien gleich; nur die Darstellung kann sich je nach Gerät und von Benutzer zu Benutzer ändern.
   • Schon die Breite des aktuellen Browserfenster bewirkt bei jedem Benutzer ein anderes Layout; anderen Zeilenumbruch.
   • Auch die Schriftart mag individuell eingestellt sein.
   • Skins und Mobilgeräte führen auch zu abweichenden Darstellungen.
   • Gleichwohl sind die Inhalte immer gleich.

VG --PerfektesChaos 12:31, 29. Aug. 2016 (CEST)

Es sei denn natürlich, die PDF-Engine quittiert ihren Versuch, eine PDF-Version mit gleichen Inhalten zu generieren, mit einem Fehler. Dann erhält der Datenkonsument auch mal ganz schnell gar keine Inhalte. Das kommt leider immer noch vor und liegt daran, dass ihre Entwickler anderer Meinung sind, als ihr, und die Bildzahl in Artikeln künstlich beschränken.

Für ein Non-Beta-Feature ist es einfach eine Katastrophe, wenn der PDF-Generator mal klappt und mal nicht. Auf WP-Benutzer mit geringer Technik-Affinität wirkt es, als ob diese Funktion quasi nach dem Zufallsprinzip Artikel verarbeitet. Schließlich wird auch nirgends sauber dokumentiert, ob und warum diese Funktion die Umwandlung von Artikeln mit einer hohen Zahl an eingebetteten Bildern verweigert. Genau so wenig, wie nirgends dokumentiert ist, welche Artikelinhalte nun enzyklopädisch sind und welche nicht. Das artikeleigene BKL und Navi-Leisten nicht zum Artikelinhalt gehören, ist eine genauso beliebige und halbgare Behauptung, wie die künstliche Begrenzung der PDF-Generator-Entwickler auf eine bestimmte Anzahl an Bildern pro Artikel.

Was sagt deine Intuition z.B. zu den Info-Boxen - gehören die zum Artikelinhalt, oder sind sie wie BKL und Navi-Leisten abkömmlich (deren Inhalte ebenso klar artikelbezogen sind)? Solange es keinen dokumentierten und ggf. sinnvoll begründeten Konsens gibt, auf den sich bei solchen Debatten verweisen ließe, bleibt das angreifbar: Ein Problem, das einige nach Belieben so lösen, und andere eben nach eigenem gusto anders. Gruß --Cmuelle8 (Diskussion) 20:05, 30. Aug. 2016 (CEST)

MediaWiki:Common.css entlasten

Hi, wenn ich richtig verstehe, was ich heute unter Hilfe:Vorlagenbeschränkungen #preview geschrieben habe, dann kann .limitreport jetzt aus MediaWiki:Common.css raus. LG --PerfektesChaos 22:59, 29. Aug. 2016 (CEST)

Ist ist erledigt. Der Umherirrende 21:46, 4. Sep. 2016 (CEST)

Wartungskategorie

Hallo Umherirrender,

was ist der Sinn der Kat und wo wurde diese vorab abgesprochen? Ich sehe nicht den geringsten Anlass dass diese Kat auf meiner BD steht. --Label5 _(L5) 20:23, 4. Sep. 2016 (CEST)

Hallo Label5, die Wartungskategorie wird von MediaWiki automatisch gesetzt. Sie dient zur Vorbereitung einer zukünftigen Änderung, die HTML-Tags innerhalb des Wikitexts anders interpretiert als es aktuell der Fall ist. Die Verwendung von <div style="clear:both"/> auf deiner Benutzerdiskussionsseite führt zu dieser Kategorie. Wenn es durch <div style="clear:both"></div> ersetzt wird, verschwindet die Kategorie. Das es die Kategorie gibt wurde von den Entwicklern entschieden, um bei der zukünftigen Änderungen keine Nebenwirkungen zu haben. Der Umherirrende 21:38, 4. Sep. 2016 (CEST)

Warum geht Beta immer kaputt?

Ich komme damit mal zu dir, weil ich denke, dass du dich sehr gut auskennst. Ich kann seit Stunden dort nichts mehr speichern. Ich wette, wenn ich das hier schreibe geht es gleich wieder. Weißt du zufällig woran so etwas liegen könnte. Das Fenster springt immer wieder in den Bearbeitenmodus. Ich bekomme aber nur Warnmeldungen in der Konsole, keine Fehler. --Liebe Grüße, Lómelinde Diskussion 19:05, 20. Sep. 2016 (CEST)

Bei mir steht über dem Bearbeitungsfenster:

ACHTUNG: Die Datenbank wurde für Wartungsarbeiten gesperrt, so dass deine Änderungen derzeit nicht gespeichert werden können. Sichere den Text bitte lokal auf deinem Computer und versuche zu einem späteren Zeitpunkt, die Änderungen in die Wikipedia zu übertragen.

Ist nicht wirklich auffällig. Hintergrund sind Wartungsarbeiten wegen phab:T138778:

Due to an unexpected production database outage during last week's
maintenance window, we were unable to complete the Beta Cluster database
migration to the new Debian jessie instances. We'll be performing this
migration during a three-hour read-only maintenance window tomorrow from
1400-1700 UTC.

Please contact Release Engineering (#wikimedia-releng) if you have
concerns/questions regarding this process, or refer to the Phabricator task
(T138778).

Du musst dich etwas gedulden, bis es wieder funktioniert. Der Umherirrende 19:12, 20. Sep. 2016 (CEST)

Etwas wäre ja schön gewesen, aber einige Stunden finde ich recht viel. Oha, ich sollte ausschalten, den Text habe ich glatt übersehen. Dankeschön und einen angenehmen Abend. --Liebe Grüße, Lómelinde Diskussion 19:27, 20. Sep. 2016 (CEST)

@Lómelinde: zur Not kannst du dir auch den Text auf Test2Wiki rüberkopieren, dort ist halt nur nicht alles identisch. Viele Grüße, Luke081515 19:39, 20. Sep. 2016 (CEST)

So wichtig ist es nicht ich wollte nur Zeilen aus einer Tabelle löschen, das kann ich auch morgen noch. Es wunderte mich nur, weil es so lange nicht ging. Ich meine gut vier Stunden oder so, für ein Update ist schon lang. Und den Text da oben verstehe ich eh nicht. „… to the new Debian jessie instances … tomorrow …“ Und Phab geht bei mir gar nicht, da steige ich sofort aus. Auch dir wünsche ich noch einen angenehmen Abend. --Liebe Grüße, Lómelinde Diskussion 19:46, 20. Sep. 2016 (CEST)

Nochmal etwas formeller

Danke für's korrigieren der BKS-Links ;-) Der Umherirrende 12:11, 25. Sep. 2016 (CEST)

Zu FvN

Moin moin. Gib mir mal bitte einen Tip zu WP:FvN#Bild hochladen scheitert an „Cross-wiki upload filter“. Wurde im Log protokolliert. Das hatten wir kuerzlich schonmal, dort wurde dann mitgeteilt, wie der Filter zu umgehen ist (vgl Wikipedia:Technik/Archiv/2016#Artikel-Editor: PNG-Datei Upload mit Button „eingebettete Datei“ - Fehlermeldung nach Button „Hochladen“). Macht es Sinn, diese Moeglichkeit auf der allgemeinen Frageseite oeffentlich hinzuschreiben? Dann kann der Filter gleich abgeschaltet werden. Aber wie kann man dem Benutzer helfen? Fragt -- Iwesb (Diskussion) 03:28, 29. Sep. 2016 (CEST)

Wie man gut damit umgehen sollte, kann ich nicht sagen, das ist ja ein Versuch Probleme auf Commons zu lösen. Wenn wir jetzt alle direkt nach Commons schicken und diese Dateien trotzdem nicht verwendbar sind, ist das schlecht. Ich denke mal, Logos sollten hier sein, oder? Es kann also auch sein, das der Hochladedialog die Benutzer falsch leitet bzw. diese durch die Texte sich selber falsch entscheiden. Alles lokal oder alles auf Commons ist wohl auch keine Lösung. Vielleicht im c:Commons:Forum besprechen? Ich habe keine Ideen, der letzte Benutzer schien mir aber schon erfahren im Umgang mit Uploads. Der Umherirrende 19:26, 29. Sep. 2016 (CEST)

@Logos: inzwischen sind Logos auf Commons sicherer als hier, s. Vorlage:Bild-LogoSH. MfG ↔ User: Perhelion 12:56, 30. Sep. 2016 (CEST)

Gadgets

Schau mal bitte auf WP:HW#type=, ob ich den Quatsch richtig verstanden habe. Danke --PerfektesChaos 10:35, 7. Okt. 2016 (CEST)

Bereits erledigt. Der Umherirrende 20:43, 19. Okt. 2016 (CEST)

Zweimal Störung der Sonntagsruhe

1. Kopierst du mal bitte Beta auf Vorlage:lang? Wurde dort ausgiebig erprobt und soll die Funktionalität deutlich erweitern. Am Bestand ändert sich nichts, mag höchstens mal eine Fehlermeldung zeigen, wo momentan schon putt, aber stellt zukünftig über 200 Parameter bereit.
2. Special:Blankpage
   • Ich beabsichtige, von dieser kürzlich von mir entdeckten Seite stärker Gebrauch zu machen.
   • Mich macht aber misstrauisch, dass sie kaum irgendwo erwähnt wird. Gibt es ein dunkles Geheimnis darum? Wird sie dauerhaft verfügbar bleiben?
   • Spezial:Spezialseiten listet sie nicht, und Hilfe:Spezialseiten verschweigt sie, und auf mw: auch kaum genannt. Hat man sich gegen uns verschworen, um uns wertvolle von dieser Seite gelieferte Infomationen vorzuenthalten?

LG --PerfektesChaos 13:31, 23. Okt. 2016 (CEST)

Wurde die luazifierung besprochen? Einfach so etwas kopieren ist immer einfach gemacht, aber muss ich noch mal drüberschauen.

Special:Blankpage ist für Performance-Messungen ("Special page designed for basic benchmarking of MediaWiki since it doesn't really do much.") und so erstellt worden. Wikipedia:Projektneuheiten/Archiv/2008-2#7. Juli. Schnark nutzt sie auch für seine Skripte. Ich denke das sie verfügbar bleibt. Der Umherirrende 18:29, 23. Okt. 2016 (CEST)

@PerfektesChaos: Ich habe mal mit Kanonen auf Spatzen geschossen. Bitte Doku und TemplateData entsprechend aktualisieren. Der Umherirrende 18:46, 28. Okt. 2016 (CEST)

• Doku und TemplateData wurden aktualisiert.
• Danke schön.
• Bereits seit dem Sommer wurden die Sprachnamenvorlagen luafiziert, weil die einheitliche Parameterhandhabung mit traditioneller Vorlagenprogrammierung, die ich zuerst versucht hatte, schon nicht mehr zu bewältigen war.
  • Als Nebeneffekt bekamen sie den quasi unbegrenzten Parametersatz mit.
  • Den haben inzwischen schon einige Benutzer mitbekommen; etwa 200 Artikel kennen bereits den neuen de=-Parameter; auch der 2= wäre dort neu aber nur mühsam zu suchen.
  • Es wird jedoch mehrere Jahre dauern, bis sich das anhand beobachteter Artikel-Edits so ganz allmählich rumspricht.
  • Die erneuerten Sprachnamenvorlagen sorgten bis letzte Woche für über 76.000 Modul-Einbindungen; heute wurden es 178.093 bei 118.211 für die nackte Vorlage.
• „luazifierung besprochen“ – du bist lustig. Mit wem über welche parameter- und programmierungstechnischen Notwendigkeiten und Alternativlösungen denn wo?

Schönen, ab nun wieder möglichst ungestörten Sonntag noch --PerfektesChaos 11:36, 30. Okt. 2016 (CET)

Kleine Bitte

Könntest du bitte mal auf WP:AA#Sonderzeichenleiste im Bearbeitenmodus vorbeischauen. Ich glaube, dass die letzte Änderung von Syntaxhighlight von dir stammt. So wie es derzeit umgesetzt ist, ist es etwas umpraktisch, da ein überlicher Anwendungsfall: zuerst den Text markieren, danach Klickt auf den Link in der Zeichenauswahl dort anders funktioniert als bei den anderen Tags die dort zur Auswahl stehen. Anstatt den markierten Text zwischen die Tags zu setzten wird der Parameter »<syntaxhighlight lang="$markierter Text hier"></syntaxhighlight>« befüllt. Besser wäre <syntaxhighlight lang="text">$markierter Text hier</syntaxhighlight> Frohes Schaffen — Boshomi ⌨   16:13, 28. Okt. 2016 (CEST)

Das ist aber seit zehn Jahren so, auch schon beim Vorgänger <source> immer so gewesen.

Dies jetzt nachträglich zu verändern, macht alle gewohnten Anwender kirre.

Beide Zeichenketten sind hier Pflichtangaben; es kann aber nur ein Textabschnitt selektiert sein. Also kommt immer einer zu kurz.

Man hat sich hier vor einem Jahrzehnt entschieden, immer den ersten der beiden Werte, wenn selektiert, in das Attribut zu übernehmen.

Völlig identisch ist das bei <ref name=""></ref> mit gleichem Verhalten wie bei <ref name="" />.

PS: Auch alle anderen möglicherweise auflaufenden Veränderungswünsche dieses noch-nicht-Gadgets sind mit Vorsicht zu genießen.

VG --PerfektesChaos 16:24, 28. Okt. 2016 (CEST)

Bei ref name="" gibt es keinen sinnvollen Default-Wert, bei Syntaxhighlight ist "text" durchaus ein brauchbares Default, damit sind diese beiden Fälle nicht vergleichbar. Dass PerfektesChaos derzeit aus schinbar aus Prinzip zu mir in Oppostion steht, habe ich schon längst zur Kenntnis genommen. Frohes Schaffen — Boshomi ⌨   16:34, 28. Okt. 2016 (CEST)

• Muttu halt schlauere und durchdachtere Vorschläge machen; und für eine Änderung des Verhaltens hier kommst du ein Jahrzehnt zu spät. Damals hättest du es ja anregen können. Oder schaffe eine Einverständniserklärung herbei von nachweislich sämtlichen Autoren, die die Werkzeugleiste nutzen und dabei auch syntaxhighlight verwenden, dass sie mit einer Umstellung auf den 1. Januar 2017 einverstanden wären.
• Du kannst aber editToolStrIns verwenden und dir deine privaten Definitionen nach Herzenslust zusammenkonfigurieren.
• Nur ein Bruchteil wäre übrigens lang="text" – bei mir ist es zu mehr als 80 % javascript und zu 10 % css.

VG --PerfektesChaos 16:50, 28. Okt. 2016 (CEST)

Natürlich ist es mit bekannt, dass hier JavaScript die häufigste Verwendung ist, aber bei Verwendung von Text wird wenigstens ein neutraler Text ausgegeben und bei Verwendung der Markierungsfunktion, kann das auch nachträglich verwendet werden. So wie es derzeit umgesetzt ist, bringt der Klick de facto keine Ersparnis zum direkten eintippen, da man sowieso wieder herumkopieren muss. Da es sich hierbei um eine recht versteckte Funktion handelt, die nur selten genutzt wird, halte ich eine Ankündigung in WP:NEU für vollkommen ausreichend. Da die Markierungsfunktion so wie sie ist, derzeit kaum praktikabel ist, nutze ich diese derzeit nicht, und verwende den Klick nur wenn ich die Tags auf einen leeren Curser setzten will. Aber wenn man ein ausgefülltes lang="javaScript" zusätzlich zur derzeitigen Umsetzung ausgäbe, hätte ich auch nichts dagegen.  Frohes Schaffen — Boshomi ⌨   17:17, 28. Okt. 2016 (CEST)

Die aktuelle Form ist von Anfang an drin und kommt von Revolus, der aber nicht mehr aktiv ist. Somit können wir ihn nicht fragen, warum es so gemacht wurde.

Es ist richtig, das die wenigsten "javascript" schreiben, es makieren und dann die Auswahl in der Leiste wählen, um anschließend zwischen die Tags zu navigieren und den eigentlich Code zu schreiben. Auch wenn man es ohne Markierung nutzt, ist es wohl sinnvoll erst die Sprache anzugeben. Wenn es jetzt geändert wird, scheint es erstmal einfacher zu bedienen zu sein (es werden sich wohl alle dran gewöhnen können, da es selten genutzt werden wird), ich denke aber das die meisten dann vergessen die richtige lang auszuwählen, dann braucht es eine weitere Bearbeitung. Es ist in dem Fall auch niemanden geholfen. Ich bin da auch unentschlossen. Der Umherirrende 18:53, 28. Okt. 2016 (CEST)

Ich weiß nicht wie andere diese Schaltflächen nutzen, aber so sieht mein Usecase aus: Die Funktionen die in "WikiSyntax" angeboten werden, sind nur für mich persönlich nur wenig nützlich, wenn ich nur eine einzige Verwendung im gerade zu schreibenden Text habe. Einen praktischen Vorteil sehen ich aber, wenn ich zuerst den unformatierten Text schreibe, und danach meinen Beitrag mit Hilfe der dort angebotenen Tags formatiere, indem ich den zu formatierenden Textabschnitt markiere, und die Tags per Klick einfüge, Textabschnitt für Textabschnitt. Dass ich leere Tags einfüge und diese dann nachträglich mit Text befülle, mache ich sehr selten, weil ich da den mit einer Hand erst von der Tastatur zur Mouse muss, dann das Dropdown suchen muss. Danach wieder zur Tastatur den Text schreiben, mit der Mouse oder der Ende-Taste auf das Ende des Tags springen und dann erst normal weiterschreiben kann. Frohes Schaffen — Boshomi ⌨   15:44, 29. Okt. 2016 (CEST)

Ich nutze diese Sachen gar nicht, kann aber den UseCase nachvollziehen. Ist aber die Frage, wenn man es ändert, was die Leute raus machen. Wenn man das bei den refs auch ändert (wo es ja auch wenig sinnvoll ist), gibt es dann mehr refs mit leerem name="" oder wird erkannt, das man dort was eintragen sollte? Hier wäre wohl ein Assistents-Fenster besser, wenn es zwei Werte zum ausfüllen gibt (Oder Auto-Erkennung ...). So etwas passt aber nicht zur Philosophie des ganzen. Der Umherirrende 10:19, 31. Okt. 2016 (CET)

<ref>{{cite news

Hi Umherirrender, könntest Du Dir bitte mal Diskussion:Lua/Modul/Zitation#<ref>{{cite news ansehen, ich hoffe Du hast ein wenig Erkenntnis / Info zu meinen Fragen, leider hat noch niemand geantwortet. Cheers Rava77 (Diskussion) 20:31, 15. Nov. 2016 (CET)

Antwort dort. Nach 24 Stunden kann man auf "abgelegenen Seiten" nicht mit einer Antwort rechnen. Der Umherirrende 17:51, 16. Nov. 2016 (CET)

WP:HW

Moin,

was passiert eigentlich bei [hidden|default], oder: Was sollte langfristig passieren?

Schönes Wochenende --PerfektesChaos 10:07, 3. Dez. 2016 (CET)

Bei der auf WP:NEU verlinkten Seite mw:Extension:Gadgets#Options steht explizit: "Enable a gadget by default without ability to disable (as modular alternative to Common.js).", also das was du vermutlich erwartest. Der Umherirrende 12:12, 3. Dez. 2016 (CET)

Ah ja, besten Dank.

Ich war nur irgendwann in einem Phab-Strang verheddert, wo man erörterte, ob und inwieweit hidden mit anderen Optionen kombinierbar wäre.

Eröffnet interessante Zukunftsvisionen hin zu modularisiertem, thematisch gegliedertem Code.

Jetzt müsste es das nur noch mit Seitennamen im BNR und globalen Wikis geben, und Gadgets 3.0 wäre realisiert. Mehr ist das nämlich nicht.

LG --PerfektesChaos 12:40, 3. Dez. 2016 (CET)

Unbekannt verzogen

Hi, auf H:GV #Weitere Informationen ist „FlaggedRevs.config.php – allgemeine Konfiguration“ angeboten.

• Gibt es das noch irgendwo anders?
• Entsprach das irgendwie rEFLR/FlaggedRevs.setup.php oder rEFLR/FlaggedRevs.defines.php?
• Lässt sich das sinnvoll ersetzen, oder kann das weg?

LG --PerfektesChaos 22:55, 5. Dez. 2016 (CET)

gerrit:316965 hat die Datei entfernt, aber es wurde vorher geleert: gerrit:316197, also FlaggedRevs.php wäre das neue Ziel, aber da ist auch mehr drin. Der Umherirrende 19:00, 7. Dez. 2016 (CET)

Na, da steht jetzt so viel Zeugs drin, dass der ursprüngliche Zweck, einen Überblick über die für Anwender relevante Konfiguration zu bekommen, nicht mehr erfüllt wird. Schmeiße ich jetzt somit raus. Danke dir --PerfektesChaos 10:22, 8. Dez. 2016 (CET)

JS, Benutzer und Kat

Hi, in Kategorie:',' und Kategorie:"," schlägt JS-Code von überwiegend wohl längst inaktiven Benutzern auf, und das wiederum in Spezial:Kategorien.

Magst du die mal administrativ per //<nowiki> ruhigstellen?

LG --PerfektesChaos 13:21, 6. Dez. 2016 (CET)

Ich habe die Seiten bearbeitet, nicht bei allen fehlte nur das schließende nowiki (hat früher ja mal funktioniert), manchmal auch ganz. Der Umherirrende 19:19, 7. Dez. 2016 (CET)

Kategorie:Foo hat auch noch 6 Seiten zu bieten. --Schnark 09:23, 8. Dez. 2016 (CET)

Auch erledigt. Mehr steht im Moment nicht auf Special:WantedCategories. Der Umherirrende 14:26, 8. Dez. 2016 (CET)

MediaWiki:Searchmenu-new

• WP:FZW #Kein Anlegen von Artikelnamen mit Leerzeichen
• urlencode
• <font> schreiben wir ja auch schon seit zehn Jahren nicht mehr.

LG --PerfektesChaos 20:25, 6. Dez. 2016 (CET)

Inzwischen WP:A/A#MediaWiki:Searchmenu-new.

• <font> schreiben wir trotzdem nicht, und https.

Seufz --PerfektesChaos 14:12, 7. Dez. 2016 (CET)

Habe es mal geändert. & sollte jetzt auch funktionieren. Der Umherirrende 19:31, 7. Dez. 2016 (CET)

Wenn du schon dabei bist, könntest du auch gleich die Farbe korrigieren. Ich habe keine Ahnung wo der Hexer den roten Farbton herhat, aber korrekt wäre #ba0000. --Schnark 09:20, 8. Dez. 2016 (CET)

Monobook hat eine andere als Vector oder Modern. Daher ist Emulieren immer schlecht. Leider lässt der CSS-Qualifier a.new keine anderen Möglichkeiten zu, da man dem Link keine class mitgeben kann. Der Umherirrende 14:19, 8. Dez. 2016 (CET)

Bis MW in die Gänge kommt, habe ich heute Nacht ein vorübergehendes hidden-default-Gadget ausgetüftelt, das für aktive VE -Nutzer in allen NR alle redlinks auf NR 2, 4, 6, 14, 100 (passen die?) auf VE setzt. Wäre das was? LG --PerfektesChaos 10:19, 8. Dez. 2016 (CET)

Hab ich auch schon überlegt. Wie sieht die Performance bei einem Artikel mit vielen Links aus? Die Namensräume sind aber 0, 2, 6, 14. --Schnark 10:47, 8. Dez. 2016 (CET)

0 wäre sowieso inklusive, bei 4 war ich mir nicht so sicher; 100 stelle ich dann zurück (warum denn den nun wieder nicht? egal).

Leider haben wir hier wohl nirgends eine von den VE-Fans aktuell gehaltene Doku, in der sich das mal schnell eben nachgucken ließe.

Code habe ich inzwischen. Die Frage ist nur, wie viele Monate MW für eine saubere Lösung bräuchte; ich vermute jedoch, dass sie es irgendwann 2017 hinbekommen würden.

Performance ist harmlos; Quelltextler biegen sofort links ab, und VEler durchsuchen nach a.new – redlink-Ziele werden meist keinen Doppelpunkt enthalten; wenn doch mal, dann muss man halt nach CSI: Freiburg gucken.

Wahrscheinlich morgen früh auf BETA, aber ungetestet. Habe kein VE an; du kannst das ja dann zerpflücken.

LG --PerfektesChaos 12:28, 8. Dez. 2016 (CET)

Die Liste entsteht vermutlich aus VisualEditorAvailableNamespaces unter InitialiseSettings.php. Dort steht 2, 6, 1012, 14 + Content Namespace und das wäre die 0. Namensraum kann man ja abfragen, da JS die Formatted Namespaces kennt. Der Umherirrende 14:19, 8. Dez. 2016 (CET)

wgNamespaceIds habe ich schon verbaut, aber der Teufel soll mich holen, wenn ich beim Öffnen einer Vorlagenprogrammierung auch noch den VE suggeriere. Maximal /Doku, aber Vorlagenprogrammierer werden ihr TemplateData auch noch ohne VE editiert bekommen. Müsste eher aus VisualEditorAvailableNamespaces entfernt werden. LG --PerfektesChaos 14:34, 8. Dez. 2016 (CET)

Also wenn ich in InitialiseSettings.php nach VisualEditorAvailableNamespaces suche, dann steht da User, File, Help und Category (+ wgContentNamespaces). Im Vorlagennamensraum ist der VE definitiv nicht aktiv.

Auf Beta kommt aber noch die Schwierigkeit dazu, dass es dort bereits den Quelltextmodus des VE gibt, sodass der VE dort für mich in allen Namensräumen aktiv ist, nur eben nicht im visuellen Modus.

Die saubere Lösung von MW existiert bereits lange, nennt sich SET (= Single Edit Tab) und ist in en aktiv. Und das halte ich auch für die beste Lösung, der normale Benutzer will nicht vor jeder Bearbeitung neu entscheiden, welchen Editor er verwenden will. Damit ist ein Edit-Tab, das je nach Kontext und Einstellungen einen unterschiedlichen Editor öffnet, besser geeignet als zwei.

@Farbe: Stimmt, das ist das Monobook-Rot. Da aber Vector das Standard-Skin ist, sollte aber natürlich auch dessen Farbe gewählt werden, wenn man sich für eine entscheiden muss. --Schnark 09:16, 9. Dez. 2016 (CET)

Ja, da habe ich die falsche Zahl hingeschrieben. Bei den Farben muss man sich wohl für ein Übel entscheiden, habe daher Vector genommen. Der Umherirrende 12:43, 9. Dez. 2016 (CET)

Also, nur damit ich es richtig verstehe: Bei dem Gadget geht es darum, die URL bei redlinks auf den momentan vom Benutzer konfigurierten Editiermodus hinzubiegen, weil MW das aktuell nicht schafft. Mit einem „Single Edit Tab“ hat das nichts zu tun, und letzteres wäre wohl fast Frage eines MB. Das BETA halte ich derzeit zurück; zum einen hatte ich heute Nacht gut geschlafen und den Code noch nicht mal in einer Simulation durchlaufen lassen, zum anderen derzeit anderen Trabbel. VG --PerfektesChaos 15:57, 9. Dez. 2016 (CET)

Wieder & in page name

Hi,

please fix encoding at MediaWiki:Wikimedia-copyright (bit different than last time?)

• meta:Talk:Pageviews Analysis #Please check & in title
• I do prefer fullurl:interwiki|

Have a nice weekend --PerfektesChaos 10:09, 17. Dez. 2016 (CET)

Klappt bei mir, da kann ich nichts fixen. Welche URL erwartest du bei den beiden Seiten? Der Umherirrende 14:33, 17. Dez. 2016 (CET)

@Lómelinde: Keine Anhnung, habe das weder verfolgt noch ausprobiert. Nur an Probleme mit & hatte ich mich erinnert, und da erwarten unterschiedliche Server-Schnittstellen zuweilen unterschiedliches Encoding. LG --PerfektesChaos 14:39, 17. Dez. 2016 (CET)

Die Antwort steht auf meiner Diskussionsseite. Wenn ich über das Menü gehe

Mehr 
Verschieben
→Aufrufe (MW)
Seite Purgen
Artikel Statistik

komme ich nicht auf die richtige Analyse. Ich klicke diesen Link und mir wird die Analyse für Moonfleet angezeigt. Das fällt kaum auf, wenn man nicht wüsste, dass die andere Seite mit dem & „Moonfleet & Other Stories“ erst seit drei Tagen existiert. Es ist nicht der Link „Abrufstatistik“ am Ende der Seite, da ist alles o.k., sondern nur, wenn man über das obere Menü „Aufrufe (MW)“ geht. Gleiches auch bei anderen Artikeln, das habe ich extra vorher geprüft, ehe ich mich auf eine englische Fehlermeldung eingelassen habe, was ich höchst ungern tue. --Liebe Grüße, Lómelinde Diskussion 14:54, 17. Dez. 2016 (CET)

Ah, irgendeine URL aus den diversen Tool-erweitere-Tool-Gadgets. Ist auch unser Eigenprodukt, müssen wir auch hier lokal reparieren; die englische Seite ist auch dafür unzuständig.

Tipp: WP:TWS – die prüfen, ob wir das lokal versaut haben oder die weltweite Software dran schuld ist.

LG --PerfektesChaos 15:04, 17. Dez. 2016 (CET)

• MediaWiki:Gadget-toolserver-integration.js ist es wohl nicht.
• Dafür steht dort unter ts_deepcat etwas, das sich nicht mit Wikipedia:Technik/Skin/Gadgets/DeepCat ausgeht.

LG --PerfektesChaos 15:35, 17. Dez. 2016 (CET)

Oh, woher soll ich denn so etwas wissen? ich hatte längst vergessen, dass es unten auch noch so ein Link gibt, das war mal Schrott, da hatte ich mich andernorts an den Ersteller gewandt, der aber scheinbar inaktiv ist. Dann gab es oben den Link im Mehrmenü, das nutze ich oft, auch weil ich da diese schnarksche Statistik anwählen kann. Ich werde mal in der Technikwerkstatt fragen, wenn du meinst dass das sinnvoll wäre, da hätte ich nie gefragt, weil ich überhaupt keinen Durchblick habe wer hier wofür zuständig sein könnte, wie diese Links überhaupt dort in das Menü hineinkommen … . Ich möchte auch nicht an zig Stellen dumme Fragen abladen, wenn ich mir unsicher bin wen ich eigentlich ansprechen müsste. Es hat mich wirklich schon einiges an Überwindung gekostet dort meine Anfrage zu formulieren. Der untere Teil deiner Nachricht galt nicht mir, oder? Das sagt mir nichts. --Liebe Grüße, Lómelinde Diskussion 16:01, 17. Dez. 2016 (CET)

Der von dir oben genannte Text ("Aufrufe (MW)") für den Link findet sich in Benutzer:°/mwArticleStatistics.js, Benutzer:° sollte da etwas zu sagen. Der Umherirrende 16:16, 17. Dez. 2016 (CET)

Soll ich dann lieber noch warten, ehe ich noch mehr „falsche Adressaten“ mit diesem Problem behellige? --Liebe Grüße, Lómelinde Diskussion 16:21, 17. Dez. 2016 (CET)

Ja, warte mal bis Benutzer:° das hier gelesen hat, vielleicht kann er dir schon direkt helfen. Der Umherirrende 16:45, 17. Dez. 2016 (CET)

Das Skript für den Aufruf der Seitenstatistik in "Mehr" habe ich erstellt, als grok noch sinnvolle Ergebnisse für historsche Daten geliefert hat, und andererseits weitere Aufrufzahlentools neben dem von MusikAnimal zu erwarten waren. Zwischenzeitlich hat aber das Tool von MusikAnimal eine Monopolstellung eingenommen und ich habe daher die Weiterentwicklung meines Skript zurückgestellt. Es ist im Wesentlichen derzeit nur dafür sinnvoll, abweichende Zeiträume voreinzustellen oder in anderssprachigen WPs den Link an gewohnter Stelle zu finden. Der Fehler mit dem & ist mir bekannt, hat für mich allerdings nur geringe Priorität. --𝔊 (Gradzeichen Diſk) 20:15, 17. Dez. 2016 (CET)

Dürfte sich mit einem mw.util.wikiUrlencode(mwASpageName.replace(mwASblank,'')) beheben lassen, da mw.util.wikiUrlencode( 'Moonfleet_&_Other_Stories' ); das gewünschte %26 für & ausgibt, ist aber ungetestet. Der Umherirrende 20:24, 17. Dez. 2016 (CET)

@Lómelinde: Ich habe eine entsprechende Änderung vorgenommen. Falls dadurch an anderer Stelle neue Fehler auftreten, bitte anpingen. --𝔊 (Gradzeichen Diſk) 05:32, 18. Dez. 2016 (CET)

@Gradzeichen schade, jetzt ist der Link nicht mehr im Menü, ich kann es also nicht mehr testen, ob sich dadurch eine Änderung ergeben hätte. Ich fand es praktisch, es dort oben abrufen zu können, auch weil es einen Zeitraum von 90 Tagen abgebildet hatte. Dankeschön für eure Hilfe, ich tue mich wirklich schwer damit zu durchschauen wie mir etwas wo oder durch wen angeboten wird. Ich wünsche euch einen schönen Sonntag. --Liebe Grüße, Lómelinde Diskussion 06:29, 18. Dez. 2016 (CET)

@Lómelinde: Jetzt aber!? Statt 90 Tagen kannst Du auch andere Werte einstellen, wie 42 oder 180... --𝔊 (Gradzeichen Diſk) 07:23, 18. Dez. 2016 (CET)

Oh, prima, ja so geht es und du hast gleich noch etwas verbessert, ich kann jetzt über einen einfachen Klick auf den Zurückbutton des Browsers wieder zum Artikel springen, vorher ging das nicht. Vielen Dank. --Liebe Grüße, Lómelinde Diskussion 07:33, 18. Dez. 2016 (CET)

Bitte um Mithilfe

Hallo, Umherirrender! Vielen Dank, dass du meine Anfrage gleich bei "Phabricator" gemeldet hast! Ich will auf keinen Fall unverschämt sein, aber wäre es evtl. möglich, dass du meine bereits vor Monaten auf Wikipedia:Verbesserungsvorschläge eingereichten Anregungen – du findest sie alle, indem du einfach mit Strg + F nach meinem Benutzernamen suchst – ebenfalls bei Phabricator unterbrächtest? Ich komme mit diesem Portal leider überhaupt nicht zurecht – zumal es ja noch dazu ganz anders aufgebaut ist als andere Wiki-Seiten. Eigentlich wollte ich alle diese Dinge neulich bei der großen Umfrage "2016 Community Wishlist Survey" unterbringen, bin aber leider aus persönliche Gründen nicht mehr rechtzeitig dazu gekommen. Seitdem ärgere ich mich regelrecht schwarz und will das unbedingt endlich einmal hinbekommen, aber auf Wikipedia:Verbesserungsvorschläge läuft momentan gar nichts – ich komme seitdem nicht mehr weiter. Wenn du mir helfen könntest, wäre ich dir unendlich dankbar. Herzliche Grüße--Hubon (Diskussion) 16:34, 27. Dez. 2016 (CET)

Hallo Hubon, der von mir verlinkte Task auf Phabricator ist vn 2007, ich habe ihn selber nicht angelegt, sondern dort nur gefunden.

Nicht alle deine Einträge auf WP:Verbesserungsvorschläge betreffen die Software MediaWiki oder Teile davon. Beispielsweise ist die Navileiste eine lokale angelegenheit, auch Leerzeilen können von uns selber gehändelt werden. Mache Dinge werden als allgemeine Änderung aber auch auf Ablehnung stoßen (beispielsweise der automatische Suchfokus), da hilft dann nur eine eigene Lösung. Es ist einzeln zu prüfen, ob ein Task benötigt wird oder nicht. Der Umherirrende 20:41, 27. Dez. 2016 (CET)

Danke dir nochmals. Leider tut sich aber wie gesagt bei meinen Anfragen auf besagter Seite mittlerweile seit geraumer Zeit nicht mehr wirklich viel – in jedem Fall nichts, was nach inhaltlicher Prüfung aussieht... :-(--Hubon (Diskussion) 21:49, 27. Dez. 2016 (CET)

Du kannst mich ja nochmal anpingen, wenn dir noch etwas einfällt oder so. Frohes Neues wünscht dir--Hubon (Diskussion) 13:42, 2. Jan. 2017 (CET)