Wikipedia Diskussion:Projektneuheiten/Archiv/2014

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

[[Wikipedia Diskussion:Projektneuheiten/Archiv/2014#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia_Diskussion:Projektneuheiten/Archiv/2014#Thema_1

Frage vllt. Fehler

Moin Moin zusammen, ich habe auf der Seite Special:CentralAuth/<Benutzername> meinen Benutzernamen eingegeben und war etwas verwundert, dass ich erst seit 11. November 2008 registriert sein soll. Mein erster Edit war im April 2007. Oder ist mit Registriert etwas anderes gemeint? Danke --Crazy1880 17:19, 3. Jan. 2014 (CET)

Damit ist die Registrierung deines globalen Accounts gemeint. Mit diesem Tool kannst du sehen, wann die jeweiligen lokalen Accounts von dir registriert wurden. — Raymond ^Disk. 17:30, 3. Jan. 2014 (CET)

Danke Raymond, das Tool kenne ich. Okai dann ist das gemeint. Könnte man dann vllt. einwerfen, dass man dort SUL-Registrierung schreibt? Dann ist es nicht so verwirrend. mfg --Crazy1880 20:18, 3. Jan. 2014 (CET)

@Crazy1880: Würde ich dort nicht hinschreiben, da der gesamte Kasten mit allen Feldern sich auf die SUL-Registrierung bezieht: „Globale Benutzerkonteninformationen“. — Raymond ^Disk. 10:41, 7. Jan. 2014 (CET)

 Ok --Crazy1880 16:50, 7. Jan. 2014 (CET)

[x] Yes to AJAX

Moin zusammen, mit dieser Änderung wurde $wgUseAjax in allen Projekten aktiviert. Hat dies irgendwelche sichtbaren Auswirkungen und/oder ist dies aus anderen Gründen auf der Vorderseite erwähnenswert? — Raymond ^Disk. 08:39, 6. Jan. 2014 (CET)

Frohes Neues; die Auswirkungen durchschaue ich grad nicht.

Negative und Sicherheitsbedenken gibt es wohl keine mehr.

In erster Linie ist das vermutlich für PHP-Programmierer interessant, weil dadurch PHP-Codes etwa zwischen verschiedenen Wiki-Domains besser abfragen können, was bislang wohl nicht möglich war; möglicherweise auch Ergebnisse auf Labs/Tools. In der Wirkung kämen dann irgendwann verbesserte Extensionen und Features zu uns.

Die Motivation zu der Änderung erschließt sich mir nicht, und weder finde ich dies im BK (commit) noch sehe ich einen menschlichen Bearbeiter.

• Ich kann mir vorstellen, dass die Sicherheitsbedenken auf MW 1.9 als ausgeräumt gelten und eine als Sicherheitsvorkehrung eingebaute Einschränkung nunmehr wegfällt.

Erwähnenswert: Mangels aktueller Konsequenzen für uns eher nicht.

Schöne Woche --PerfektesChaos 09:28, 6. Jan. 2014 (CET)

Weder tut diese Variable noch irgendetwas Sinnvolles (AJAX funktioniert heutzutage per API, nicht per action=ajax), noch hatte ich bisher das Gefühl, sie wäre wirksam auf false gesetzt. Insofern: Nicht erwähnenswert. --Schnark 10:13, 7. Jan. 2014 (CET)

Danke für eure Einschätzungen. — Raymond ^Disk. 10:39, 7. Jan. 2014 (CET)

Cirrus

Seit Montag haben wir als alternative Suche auch Cirrus. Kann jemand bestätigen, dass ich den richtigen URL-Parameter erraten habe in https://de.wikipedia.org/w/index.php?title=Spezial%3ASuche&profile=advanced&search=Wikipedia&fulltext=Search&ns0=1&ns14=1&redirs=1&profile=advanced&srbackend=CirrusSearch vs. https://de.wikipedia.org/w/index.php?title=Spezial%3ASuche&profile=advanced&search=Wikipedia&fulltext=Search&ns0=1&ns14=1&redirs=1&profile=advanced ? --Schnark 10:22, 7. Jan. 2014 (CET)

Bestätigt. Bitte beachte aber, dass der Suchindex sich noch im Aufbau befindet. Erst wenn dieser fertig ist, wird die Cirrus-Suche als Beta-Funktion zur Verfügung gestellt. — Raymond ^Disk. 10:36, 7. Jan. 2014 (CET)

Linkformatierung kleiner Seiten

• (Softwareneuheit) Aus der persönlichen Einstellungsmöglickeit „Linkformatierung kleiner Seiten“ wurde die Option zur Eingabe beliebiger Werte gestrichen (Gerrit:103742).

Remove "or other" option for stubtreshold

People use this to set it to absolutely insane values.

Wie schön, dass sich endlich jemand um meine mentale Gesundheit kümmert. Weil eine kleine Anzahl von Personen utopisch hohe Werte eingibt, müssen also alle mit den vorgeschlagenen Werten leben. :( -- 32X 15:26, 9. Jan. 2014 (CET)

Wie unsinnig ist das denn? Grund scheinen ja absurd hohe Werte zu sein - wieso nicht einfach einen Maximalwert festlegen statt die Option "anderer Wert" abzuschaffen. Gerade bei kleinen Seiten ergibt es doch keinen Sinn, nur feste Werte zu haben - je nach Projekt kann eine "kleine Seite" ja sehr unterschiedlich sein. Also einfach auf die 10000 als Maximalwert festlegen und gut ist. --APPER\^☺☹ 16:03, 9. Jan. 2014 (CET) Ergänzung: Die Liste der Verwendungen zeigt ja, dass mehr Leute eine Größe zwischen 100 und 500 (nur 50er Schritte) nutzt als z.B. die Standardeinstellung "5000".

Lieber einen Maxwert abfragen. Ich z.B. habe "666" eingetragen, finde also einen Wert von 500 bis 1000 Bytes für sinnvoll. --Atamari (Diskussion) 16:17, 9. Jan. 2014 (CET)

Ich kann (bei MonoBook) immer noch "Andere" auswählen. --Mogelzahn (Diskussion) 13:40, 11. Jan. 2014 (CET)

Steht ja auch noch im Abschnitt "Vorschau auf Version 1.23wmf10". Ab 16. Januar abends wirst du es dann nicht mehr sehen. Der Umherirrende 14:17, 11. Jan. 2014 (CET)

CirrusSearch

Was ist eigentlich mit der neuen Suchmaschine? Laut wikitech:Deployments hätte das vorgestern als Opt-in-Betafunktion zur Verfügung stehen müssen. --\m/etalhead ✉ 14:10, 15. Jan. 2014 (CET)

Also ich besitze dafür ne Option unter Spezial:Einstellungen#mw-prefsection-betafeatures, habs aber noch nicht ausprobiert. --se4598 / ? 14:21, 15. Jan. 2014 (CET)

Ich habe nicht geahnt, dass sich das in dem Beta-Funktionen-Reiter versteckt. Ich habe mich schon gewundert über den fehlenden Hinweis auf Spezial:Suche. --\m/etalhead ✉ 15:50, 15. Jan. 2014 (CET)

Einschränkung des URL-Parameter „limit“ auf 500

Bis jetzt kann man den URL-Parameter „limit“ per Hand auf größere Werte als 500 festlegen. Maximal sind hier 5000 erlaubt. Klar dauert in solchen Fällen der Seitenaufbau für schwache Systeme sehr lange, wird aber wohl von solchen kaum genutzt, da sowieso nur per Hand erreichbar.

Ich nutzte diese Möglichkeit gelegentlich um beispielsweise schnell nach Stichworten in der Historie zu suchen, einen schnellen Überblick über die Verwendung einer Domain über die Weblinksuche zu bekommen, usw.

Die API ist nur eine theoretische Alternative, da diese ebenfalls auf 500 beschränkt ist.

Da ich nicht sehe, dass diese (versteckte) Möglichkeit zu einem größeren Limit zu gröberen Problemen geführt hat, bitte ich die bisherigen Einstellung mit dem Maximum 5000 zu belassen. Frohes Schaffen — Boshomi ☕⌨☺  14:49, 25. Jan. 2014 (CET)

Es ist nur Spezial:Suche betroffen, die anderen von dir genannten Spezialseiten sind (aktuell) nicht von der Änderung betroffen und sollten weiterhin die höhere Anzahl liefern. Der Umherirrende 15:13, 25. Jan. 2014 (CET)

Dieser Abschnitt kann archiviert werden.  Frohes Schaffen — Boshomi ☕⌨☺  20:47, 4. Feb. 2014 (CET)

Update, Rollback und Math-Extension

Dem BK entnahm ich, dass das zwischenzeitliche Rollback gestern abend mit einem Fehler in der Math-Extension zusammenhängen solle.

Dieser frisch gerenderten Werkstatt-Anfrage entnehme ich, dass das Problem wohl bislang nicht gelöst wurde; oder bestand dieser Fehlertyp schon länger?

Grüße --PerfektesChaos 10:55, 7. Feb. 2014 (CET)

Im Tracking-Bug 60997 zum gestrigen Ereignis gibt es etliche davon abhängige Bugs, zu dem auch Bug 61012 TeX environments "align" and "alignat" broken in PNG mode zählt. — Raymond ^Disk. 11:49, 7. Feb. 2014 (CET)

PENDINGCHANGELEVEL

Mir ist die Verwendung des neuen magischen Wortes nicht klar: {{PENDINGCHANGELEVEL:Simfy}} liefert z. B. nur einen roten Link. Kann das jemand auf H:Variablen genau dokumentieren? --88.66.184.168 21:08, 13. Feb. 2014 (CET)

Bei mir klappt schon {{PENDINGCHANGELEVEL}} nicht, in enwiki funktioniert aber {{PENDINGCHANGELEVEL:San Jacinto College}}. Erzeugt wird autoconfirmed, das magische Wort sagt also nicht ob es Änderungen die einer Sichtung bedürfen gibt sondern die Konfiguration der Seite. --sitic (Diskussion) 00:27, 14. Feb. 2014 (CET)

Die Parserfunktion ist wie PROTECTIONLEVEL und gibt die Konfiguration der Seite zurück. In de.wp werden die gesichteten Versionen anhand der Namensräume vergeben, in en.wp kann man als Seitenschutz die gesichteten Versionen auf Seitenebene aktivieren und dann ist die Parserfunktion/Variable auch aktiv. Ist also eine Konfigurationssache, dass es nicht verfügbar ist. Der Umherirrende 14:55, 14. Feb. 2014 (CET)

Seiten laden nicht fertig

Bei mir laden seit heute rund 80% aller Seiten nicht mehr fertig. Irgendwas fehlt immer noch, ohne dass erkennbar wäre, worum es sich handelt. Firefox zeigt nur an, von welcher Domain noch ein Ladevorgang läuft, der ist meistens meta (die site notice?), mal de.wikipedia.org. Geht das noch anderen so? Grüße --h-stt !? 14:55, 7. Mär. 2014 (CET)

Hm, verhält sich bei mir normal. Gruß, IW 17:48, 7. Mär. 2014 (CET)

Bei mir auch keine Probleme. Yellowcard (D.) 18:21, 7. Mär. 2014 (CET)

Danke, ich dachte mir das schon, als mehrere Stunden kein Feedback kam. Grüße --h-stt !? 18:42, 7. Mär. 2014 (CET)

1. Gestern war Software-Update. Kann schon sein, dass das irgendeinen Klemmer verursacht hat.
2. Bei mir (FF) ist alles normal. Auch auf FZW alles ruhig. Kollegen melden ebenfalls Frieden. Scheint ein Einzelschicksal zu sein.
3. Du hast kein Benutzer-JS; noch nicht mal CSS. Das schränkt den Kreis der Verdächtigen ein.
4. Von unseren Gadgets wüsste ich spontan keines, das sich Ressourcen von meta holen will. Sehr seltsam.
5. Die Idee mit irgendeiner notice ist nicht verkehrt; aber dann central wegen Steward-Wahlen oder weltweitem Verbot bezahlten Editierens oder so. Diese central-Leute waren in den vergangenen Jahren berüchtigt dafür, dass sie grottenfalsche kaputte Skripte ungetestet zur Weihnachtszeit weltweit zwangsausgeführt hatten; das ist aber inzwischen besser geworden.
6. Da du ja FF hast, mach bitte mal dort Strg+Umschlt+J und dann in dieser Konsole den Knopf „Netz“ mit dem schwarzen Punkt und experimentier mal mit dem Log oder Fehler oder Warnung herum. Das sollte mit etwas scrollen verraten, wenn eine Ressource nicht richtig geladen werden kann, und welche das ist.
7. Was verwendest du an Blockier-Add-Ons, NoScript, Ad-Blocker?
8. Antworten bitte nicht hier, sondern als Kopie des Abschnitts in der WP:TW.

Viel Erfolg --PerfektesChaos 21:23, 7. Mär. 2014 (CET)

Spezial:Linkliste nun in andere Seiten einzubinden (1.23wmf20)

Das wäre dann etwas für die Systemnachricht nach Verschiebung und möglicherweise für die SLA-Vorlage; wenn das dann mehr als 50 Verwendungen anzeigt, ist das offenbar größerer Aufwand, wenn es nur einige Bot-Übersichten und LD gibt, eine mager verlinkte Seite.

• Leider kann ein Seitentitel Schrägstriche enthalten; weitere Wikilink-geeignete Parameter wie eine Begrenzung der Anzahl angezeigter Seiten auf 5 sind deshalb ausgeschlossen.
• Man kann ja mal ausprobieren, wie das in einem small-div-Kasten wirken würde.

Nebenbei: Ich hätte gern eine Liste aller includes/specials-PHP, die IncludableSpecialPage unterstützen; und dann auf Hilfe:Seiten einbinden #Spezialseiten eingepflegt bekommen.

Schöne Woche --PerfektesChaos 21:28, 23. Mär. 2014 (CET)

Jeder eingebundenen Spezialseite kann man per Vorlagenargumente die entsprechenden URL-Parameter übergeben, da ist keinerlei Magie im Vorlagennamen notwendig, wie es früher mal war und aus Kompatiblitätsgründen wohl bleiben wird. IncludableSpecialPage ist nicht das einzige Argument, es gibt wohl auch Spezialseiten, die isIncludable selber überschreiben oder im Konstruktor das boolean-Feld setzen. Ein guter Anfang aber auf jedem Fall. Der Umherirrende 21:08, 24. Mär. 2014 (CET)

Wenn das mit roten Wartungslinks so (Beispiel: {{Spezial:Linkliste/Vorlage:Toter Link/!...nourl}} ) so funktionieren würde, wäre das wirklich toll. Ein Dank an die Programmierer! Frohes Schaffen — Boshomi ☕⌨☺  22:44, 24. Mär. 2014 (CET)

@Umherirrender:

• Ich habe noch nie eine eingebundene Spezialseite gesehen und wusste nicht, dass das möglich ist.
• Umso wichtiger ist es, Hilfe:Seiten einbinden #Spezialseiten auszubauen.
• Wenn ich dich richtig verstehe, könnte man immer die Hilfe:URL-Parameter in der Vorlageneinbindung angeben; also etwa:

  {{Spezial:Linkliste/WP:NEU|limit=10|namespace=4}}

  • Das klappt auf Beta schon mal. Cool.
  • Leider schaffe ich es nicht, das Innere dieses Cache-Schnipsels auszulesen und durchzuzählen, wie viele oder gar welche Seiten verlinken.
• Beim Wikilink ginge das im Unterschied zum URL-Link nicht bei der Linkliste.
  • Das Wikilink-Format wäre: Spezial:XY/par1/par2/par3
  • Weil par1 als Seitenname Schrägstriche enthalten kann, kann hier kein weiterer Parameter folgen; so meinte ich das.
• Wie viele Seiten gibt es denn so? Wenn es nur eine Handvoll ist, reicht Hilfe:Seiten einbinden #Spezialseiten; sonst könnte man eine eigene Spalte in Hilfe:Spezialseiten/Liste generieren. Prefixindex scheint zu gehen und vor Kurzem in der Verschiebungsnachricht eingebaut zu sein?

Schönen Tag --PerfektesChaos 10:50, 25. Mär. 2014 (CET)

Du hast es richtig angewendet. Zugriff hast du auf diesen Schnipsel nicht, da er als pures HTML in die fertige Seite eingebaut wird (und eventuell notwendige ResourceLoader-Module würden dann auch mit geladen werden). Die Einbindung einer Spezialseite hebelt aber den Cache aus, so dass solche Seiten meistens etwas länger laden und es nicht ratsam ist, sie auf der Hauptseite einzubinden ;-). Eine Übersicht der Spezialseiten, die sich einbinden lassen, kann ich mal versuchen zu erstellen.

Bei Spezial:Letzte Änderungen beispielsweise werden die Parameterwerte mit Komma getrennt, so dass lustigerweise auch Spezial:letzte Änderungen/hidebots,hideminor,days=5 als Wikilink und nicht nur als Einbindung funktioniert, aber das würde ich nirgendwo dokumentieren, weil es nur ein Hack war, die Infos in die Spezialseite zu transportieren. Da sind die Vorlagenargumente sehr viel übersichtlicher und man brauch auch nichts erweitern, wenn ein Parameter hinzukommt, weil das immer funktioniert. Der Umherirrende 18:10, 25. Mär. 2014 (CET)

In core komme ich auf Spezial:Alle Seiten, Spezial:Änderungen an verlinkten Seiten, Spezial:Beiträge, Spezial:Benutzer, Spezial:Dateien, Spezial:Gewünschte Seiten, Spezial:Letzte Änderungen, Spezial:Neue Dateien, Spezial:Neue Seiten, Spezial:Präfixindex. Bei extension fällt mir noch Spezial:Seiten mit ungesichteten Versionen und Spezial:Sichtungsstatistik ein.

Aber es macht ja auch nicht bei jeder Seite Sinn, wenn beispielsweise Rechte benötigt werden oder Interaktionen möglich sind, ist es etwas schwierig. Eingebundene Spezialseiten haben im normal auch keine Navigationselemente, man kann also nicht die nächsten 50 sich anzeigen lassen. Dafür müsste man sich dann selber ein Link dadrunter packen. Eingebundene Spezialseiten machen auf Artikelseiten wohl auch wenig Sinn. Eine Anwendungsmöglichkeit kannst du dir auf WP:Umfragen/Technische Wünsche/Übersicht#Letzte Änderungen anschauen. Der Umherirrende 18:33, 25. Mär. 2014 (CET)

Danke schön; das ist ein Dutzend, und künftig mögen welche dazukommen.

• Also werde ich demnächst Hilfe:Spezialseiten/Liste um eine Spalte erweitern.

Technisch dokumentiert wird die Funktion erstmal.

• Wer wann was wozu verwendet, ist eine andere Frage. Wenn erweiterte Rechte erforderlich sind, dann vielleicht auf der zugehörigen Systemnachricht einer Admin-Aktion.

Für Artikel ist das sicherlich nix.

• Es geht um Verwaltungsaktionen und Wartungsseiten.
• Nicht alles, was technisch machbar ist, ist auch sinnvoll; das ist in sehr vielen Bereichen so.

Formulare sind nicht zu bedienen. Es geht um sofort sichtbare Listen, die keine, 2, oder 5 Einträge haben sollten. Wer mehr sieht oder mehr braucht, muss sich schon die Seite selbst aufrufen; bekommt vielleicht ein vorkonfiguriertes Link für den Rest druntergepackt.

Bei der Linkliste denke ich an:

• Vorlage:SLA – die ersten zehn Seitenverwendungen.
  • Wenn das nur archivierte Uralt-Diskussionen sind, Bot-generierte Wartungslisten und so, dann kann das wohl weg. Idealerweise gar keine Verlinkungen, weil gerade eben Schreibfehler bei der Seitenanlage.
  • Wenn alle zehn Punkte ausgefüllt werden, ist die Seite wohl noch im produktiven Einsatz. Vielleicht ist der SLA auf die falsche Seite geraten und hat die falsche WL erwischt.
• Systemnachricht nach Verschiebung:
  1. Alle WL auf den bisherigen Namen, bis zu 500
  2. Die ersten zehn Links auf den bisherigen Namen, und Link auf mehr.

Angenehmen Abend --PerfektesChaos 22:02, 25. Mär. 2014 (CET)

Hilfe:Spezialseiten/Liste jetzt ausgebaut; bitte mal kontrollieren, ob ich das auch alles richtig gemacht habe. --PerfektesChaos 11:59, 29. Mär. 2014 (CET)

Sieht gut aus. Der Umherirrende 13:45, 29. Mär. 2014 (CET)

Ich habe die ersten fünf Links auf die zu löschende Seite testweise mal hier eingefügt. Ich denke das hilft, um sich einen schnellen Überblick zu verschaffen, von wo die Seite verlinkt wird (etwas spezifischer als der reine Hinweis, das noch Links existieren). Gruß, IW 20:56, 6. Apr. 2014 (CEST)

Schriftart (Font) für Lemmata und oberste Gliederungsebene

Haben wir eine neue Schriftart (Font) für Lemmata und oberste Gliederungsebene? Die unterschiedlichen Unter- und Oberlängen von Ziffern sind mir vorher nicht aufgefallen.--Ulamm (Diskussion) 23:33, 5. Apr. 2014 (CEST)

Meinst du das hier? Da gibt es schon diverse Diskussionen auf WD:K und WP:FZW. -- Rosenzweig δ 23:53, 5. Apr. 2014 (CEST)

In den Commons kann man mittels Refresh -> Yes von Serifenüberschriften auf serifenfreie Darstellung der Überschriften umschalten. Sofern es das auch für de.wiki, oder gar für alle Wikis gibt, sollte darauf hingewiesen werden und zwar nicht nur für vielschriebende Autoren, sondern auch für zufällige Leser.--Ulamm (Diskussion) 20:26, 6. Apr. 2014 (CEST)

Spezial:ListDuplicatedFiles

Was genau zeigt diese Spezialseite an? Sprich: wie ist "Duplikat" definiert? Was muss alles identisch sein? Das visuelle Erscheinungsbild auf größer X Prozent Übereinstimmung? Muss der Dateityp identisch sein? Die Beschreibung? Oder muss die Datei exakt identisch sein (identische Binärdaten des kompletten Dateiinhalts), sprich selbe Prüfsumme? Wären zwei JPGs Duplikate, wenn sie sich nur in den EXIF-Daten unterscheiden, in den Binärdaten aber exakt identisch sind? --Stefan 19:21, 7. Apr. 2014 (CEST)

Es wird nur der SHA1-Wert des Bildes geprüft. Dieser wird wohl auch die Exif-Daten enthalten, bin mir da aber nicht ganz sicher. Übereinstimmung auf Pixel-Ebene wird wohl zu aufwändig, auch das Erkennen von zwei Duplikat durch Skalierung ist wohl zu aufwändig. Der Umherirrende 19:30, 7. Apr. 2014 (CEST)

OK, danke. :) (da die EXIF-Daten in der Datei stecken, sollten diese dann auch dazuzählen, sofern sich keiner die Mühe gemacht hat, die Dateiheader beim Prüfen extra zu überspringen) --Stefan 19:45, 7. Apr. 2014 (CEST)

SHA1 berechnet MediaWiki aus der gesamten Datei, wie sie vom Benutzer übermittelt wird. Würden die Meta-Daten vorher entfernt, würde der FileAnalyzer nicht mehr funktionieren. -- RE rillke fragen? 14:36, 14. Apr. 2014 (CEST)

Spezial:Präfixindex

(Softwareneuheit) Beim Einbinden von Spezial:Präfixindex kann die Anzahl der Spalten angegeben werden

Scheint bei mir nicht zu gehen. Siehe Benutzer:Frank_C._Müller#Meine Unterseiten. Obwohl ich da

{{Spezial:Präfixindex/{{FULLPAGENAME}}/|columns=2|stripprefix=1}}

angebe, kommen trotzdem drei Spalten. --Frank C. Müller (Diskussion) 09:21, 14. Apr. 2014 (CEST)

Steht in der Überschrift: „die nachfolgend genannten Softwareänderungen [sind] vermutlich Bestandteil der Version 1.23wmf24 (voraussichtlich ab 24. April 2014 hier verfügbar).“ --Fomafix (Diskussion) 09:37, 14. Apr. 2014 (CEST)

Ok. Danke! Da hab' ich mich wohl von der intuitiven Ordnung der Seite (neu : alt : alt : neu) nasführen lassen. So we will wait and see. gruß, fcm. --Frank C. Müller (Diskussion) 13:08, 14. Apr. 2014 (CEST)

Die entsprechende Änderung ist jetzt live, kann also jetzt genutzt werden. Der Umherirrende 21:14, 24. Apr. 2014 (CEST)

Fortgang Technische Wünsche

Da nicht allzuviele Wikipedianer die Seite der technischen Wüsche auf Beobachtung haben (im Moment 12), erlaube ich mir hier auf Wikipedia Diskussion:Umfragen/Technische Wünsche/Top 20#Analyse Wunsch 1 hinzuweisen mit der Bitte um rege Beteiligung. — Raymond ^Disk. 13:23, 26. Apr. 2014 (CEST)

Interwiki-Präfix c:

Ich denke, wir sollten keine große Reklame machen für das Dings (obwohl die Existenz dokumentiert werden muss).

Das ist so unanschaulich und verwirrend wie nur was. Das gleiche Problem gab es schon mal mit m: – von dem kein normaler Nutzer weiß, was es bedeutet. Okay, es wissen auch nur wenige, was das Meta-Projekt ist (was machen die da eigentlich??), aber meta: ist wenigstens selbsterklärend.

• WSTM macht aus allen angetroffenen m: ein meta: und wird sich zukünftig entsprechend bei c: verhalten.
• Wir sollten unsere Quelltexte für Normalbenutzer verständlicher machen und nicht mit immer mehr kryptischen und unverständlichen Abkürzungen immer mehr zur Expertensache. Es ist mir auch egal, ob die enWP das immer schon ganz toll fand.
• Wenn sich Profis auf ihrer Disk oder in der DÜP unterhalten, dann sollen sie es machen, wie sie wollen. Mindestens in Artikeln, Hilfeseiten und auf allgemeinen Projektseiten hat das nix am Suchen.

Der Abkürzungswahn greift immer mehr um sich. Es gibt Tausende von Shortcuts, wobei das Pikante ist, dass diejenigen, die diese Shortcuts zum Verlinken nehmen, regelmäßig auf die falschen Seiten verweisen und den Leser aus der Kurve tragen; nicht mal diese begeisterten Anwender der Shortcuts haben Ahnung davon, was das wirkliche Seitenziel ist. Es gibt inzwischen auch jede Menge Vorlagen, bei denen ich als Werkstattler schon nicht mehr durchsteige, was der Zweck sein soll. Preisfrage: Was ist „AZ“? Nein, nicht die Automatische Zusammenfassung; es geht offenbar um eine Zeitung. Aber welche? Aachener Zeitung? Abendzeitung – welche? Allgemeine Zeitung, wenn ja: welche? Augsburger Zeitung?

Grüße --PerfektesChaos 18:30, 29. Apr. 2014 (CEST)

Mir würde gefallen, wenn die Abkürzungen vor dem Speichern automatisch expandiert werden würden. Der Autor kann seine geliebten Abkürzungen verwenden und alle anderen sehen die normalen ausgeschriebenen Schreibweisen. Lässt sich so etwas umsetzen? Für die Suchfunktion wäre so etwas auch praktisch. --Fomafix (Diskussion) 21:49, 29. Apr. 2014 (CEST)

Es gibt eine alte Grundregel: Der Wikitext wird so gespeichert, wie er da steht; mit sehr wenigen Ausnahmen (etwa die Tilden). Er kann so falsch sein, wie er mag, und eine noch nicht einmal fest in der Software verankerte Zuordnung wie hier, die letztlich projekt-konfiguriert sein kann oder volatil über die Interwiki-Map, wird kaum in das Abspeicherungs-PHP fest verdrahtet aufgenommen werden. LG --PerfektesChaos 22:07, 29. Apr. 2014 (CEST)

Der Pipe-Trick wird auch beim Speichern expandiert. Das betrifft ebenfalls Links. Vielleicht kann die Expansion auch clientseitig durchgeführt werden. Bei der Suchfunktion wäre eine Ersetzung auch rein mit JavaScript realisierbar. Eine projektspezifische oder gar benutzerspezifische Ersetztabelle würde mir hier gefallen. --Fomafix (Diskussion) 22:18, 29. Apr. 2014 (CEST)

Der Pipe-Trick war der andere Fall, der mir bei „mit sehr wenigen Ausnahmen“ vorschwebte.

Pipe-Trick und Tilden stehen aber seit zehn Jahren unmittelbar in der PHP-Implementierung spezifisch hardcoded.

Clientseitig ist Horror, weil nowiki und syntaxhighlight geparsed sein müssen; auch das Innere von Kommentaren. Mit einer trivialen JavaScript-Textersetzung wird das nichts, ich weiß, was ich in WSTM anstelle, um Linkziele zu identifizieren. Und das dann in der Zehntelsekunde, um den bearbeiteten Text abzuspeichern, und wobei nichts schiefgehen darf, und dann ist es ohne Einflussnahme des Bearbeiters abgespeichert.

Ich glaube nicht, dass sich die weltweite PHP-Programmierung auf solche Funktionen einlassen würde.

Wir sollten zurück zum Ausgangspunkt kommen: Wollen wir das in der deWP, und was raten wir Autoren?

VG --PerfektesChaos 23:12, 29. Apr. 2014 (CEST)

Mit Ersetzungen durch JavaScript habe ich an den Linkeingabedialog vom WikiEditor gedacht. Die gleiche Ersetzung kann auch interaktiv in der Suche verwendet werden. Konkret wünsche ich mir, dass bei der Eingabe von „k:“ nach Kategorien gesucht wird, aber ohne Alias. International wäre hier das „c:“ passend. Genau das ist aber jetzt ein Alias für Commons. --Fomafix (Diskussion) 08:18, 30. Apr. 2014 (CEST)

Ah so, Namensaum-Aliasse, die nur im Suchfeld gelten aber nicht als Verlinkung möglich wären? Halte ich für keine glückliche Idee, weil:

1. Jeder dritte Benutzer die dann auch als Verlinkung einsetzt und sich bitter beschwert, dass das nicht funktioniert.
2. Wenn k: zu Kategorie: expandiert wird, dann werden Bandnamen wie k:o oder sonstige Kreationen nicht mehr auffindbar; bzw. können nicht mehr über das Formular verlinkt werden.
3. Wenn ein Seitentitel nicht (mehr) zulässig ist, weil Alias etc., dann kann man ihn weder suchen noch verlinken. Wenn es aber ein zulässiger Seitentitel ist, dann darf es keine Sonderregelungen geben, die seine Handhabung auf unvorhergesehene Weise erschweren.

Ich verstehe ja, dass du das gern abkürzen würdest; und mich nervt auch Vorlage: einzutippen, aber grad vor zwei Sekunden habe ich das glatt geschafft. b: sind aber books und nicht Benutzer: und die Vorlage v: ist, nein, nicht voyage, versity. Man kann auch doi:10.1000/182 in die Suchbox eintippen und bekommt eine für manche unerwartete Antwort.

• Noch mehr Alias-Regeln und Abkürzungen und Ausnahme-Extras neben der Liste der NR-Aliasse sowie der IW-Map, die man ungefähr im Kopf haben müsste, verkomplizieren die Sache weit mehr als es einer Handvoll Experten-Benutzern mal ein paar Tastendrücke spart.
• Es ist nicht nur eine Frage, was einem Computer syntaktisch möglich ist, um zweifelsfrei einen Namen aufzulösen. Es gehören auch Menschen dazu, die sich zu jeder gelesenen und eingetippten Abkürzung merken können, zu welcher Wirkung sie expandiert würde. Mit einem Dutzend der besonders unanschaulichen Ein-Buchstaben-Abkürzungen, der durch ISO 639 eingeschränkten Welt der Zwei- und Drei-Buchstaben-Abkürzungen samt dazwischen herumgeisternden Nicht-Sprachen-Präfixe ist schon längst eine Grenze erreicht, die Normalbenutzer nur noch außen vor lässt.
• Und das alles, damit einige Nerds ein paar Tasten weniger zu drücken brauchen; ich arbeite hingegen viel mit C&P.

Schönen Tag --PerfektesChaos 10:20, 30. Apr. 2014 (CEST)

Ich habe häufig genug nicht funktionierende Links nach Commons:Forum#Problemfall gesehen, weil schon commons: davor stand und vielfach nicht verstanden wurde, dass für den Commons-Namensraum auf Commons commons:commons:Forum verlinkt werden muss. Es wäre grob idiotisch, Leuten jetzt die Abkürzung zu verheimlichen. Wer eine andere Projektsprache verlinken will, soll das Sprachkürzel davorpacken. Wer auch ein anderes Projekt verlinken will, packt das Projektkürzel davor. Wer das verinnerlicht hat, wird auch keine Probleme mehr mit c:commons:Forum haben und es intuitiv machen. -- 32X 09:48, 3. Mai 2014 (CEST)

+1 — Raymond ^Disk. 09:56, 3. Mai 2014 (CEST)

Wenn man es als commons:Commons:Forum schreibt, wird es eigentlich auch ersichtlich, das erst der Projektwechsel und dann der Namensraum gemeint ist. Dein Beispiel sollte man dann aber als c:Commons:Forum schreiben, weil die Zielseite ja auch ein Großbuchstaben am Namensraumanfang hat. Abkürzungen haben immer Vor- und Nachteile. Der Umherirrende 13:03, 3. Mai 2014 (CEST)

Kommendes jQuery-Upgrade (breaking change) von v1.8.3 auf v1.11.x

Info an die hier mitlesenden JS-Entwickler: jQuery wird bei uns demnächst von v1.8.3 auf v1.11.x geupgraded. Dabei verschwinden auch einige veraltete jQuery-Funktionen. Siehe Mailinglist-Post für mehr Infos. --se4598 / ? 22:42, 7. Mai 2014 (CEST)

mw:Talk:Compact_Personal_Bar

Ich würde gerne Rückmeldung zu der compact personal bar geben, aber Flow funktioniert nicht („An error occurred while contacting the server.“) und in #mediawiki fühlt sich auch niemand zuständig. Daher hier auf Zwischenlagerung, bis Flow funktioniert. –ireas (Diskussion) 12:01, 9. Mai 2014 (CEST)

Many users are adding items to the personal bar using the addPortletLink JS function with p-personal. As far as I see, there is no (easy) possibility to add items to the compact personal bar as there are no element IDs. It would be great if (1) the hitherto existing possiblity to use addPortletLink("p-personal", ...) would continue to work (but I guess it’s not possible) or (2) there is a JS method that adds an item to the regular personal bar or the compact personal bar (depending on which is activated at the moment). –ireas (Diskussion) 12:01, 9. Mai 2014 (CEST)

• Es hat vielleicht der oberste Software-Entwickler seinen Daumen dazwischengehalten und das Absenden aufgehalten.
• Das Dings reduziert nur die persönliche Leiste angemeldeter Benutzer auf Smartphone-Breite, nicht aber die Vector-Leiste usw. mit den Seitenfunktionen.
• Die in WP:GUI #Seitenaufbau in magenta dargestellten Selektoren sind im Wesentlichen vorhanden: #p-personal #pt-preferences #pt-betafeatures #pt-watchlist #pt-mytalk #pt-notifications #pt-logout
  • Es ist wie bisher eine (jetzt mehrere) <ul> – die Links wurden bislang als <li> eingefügt.
  • Ohne es getestet zu haben, würde ich denken, dass vorhandener einfügender Code problemlos weiter funktionieren sollte. Ich sehe erst mal nichts, was dagegen spräche.
  • Optisch mag man das unter den Bedingungen der Mini-Leiste etwas anders anordnen wollen, und zukünftiger JS-Code kann herausfinden, ob ein flyout vorhanden ist, und das dann ggf. anders handhaben wollen.
  • Das sollte dann dementsprechend in Other items added by extensions & gadgets landen; dafür sehe ich aber noch keinen vorbereiteten Selektor. Ob der es dann auch schafft, sein Lineal einzufügen, müsste ggf. mw.util zwecks Nacharbeit beim Layout anschubsen.
• Du kannst dir expertenmäßige Pluspunkte einhandeln, wenn du schreibst mw.util.addPortletLink() – weil obsoleting.
• Du kannst aber für mich mitfragen:
  • Was soll Help und Datenschutz als personalisiertes Feature da mittenmang?

    Das muss für die nicht angemeldeten Benutzer sowieso irgendwo auf dem Portal stehen; ist hier also redundant und nimmt nur Platz weg. Es ist auch nicht wie alle anderen Items personalisiert und deshalb nicht nachvollziehbare Systematik.

LG --PerfektesChaos 09:49, 10. Mai 2014 (CEST)

Neues Hindernis bei der Zugänglichkeit von Commons-Dateien

In vielen (möglicherweise den meisten) WPs, glücklicherweise (noch?) nicht in en.wiki und de.wiki, gibt es ein neues Hindernis, in die Artikel eingebettete Bilder und Karten in voller Größe zu betrachten oder die Hintergrundinformationen zu lesen:

Wenn man auf die Abbildung klickt, wird je nach Browser entweder das ganze Fenster schwarz, oder es erscheint auf schwarzem Hintergrund die Abbildung in der Größe, wie sie sonst im Commons-File angezeigt wird, aber ohne die Dateiinformationen. Es besteht stattdessen die wenig gebrauchte Möglichkeit, sich zu den übrigen in dem spanischen oder katalanischen usw. Artikel verwendeten Abbildungen durchzuklicken, aber eben alle ohne Dateiinformationen oder die Möglichkeit, die maximale Auflösung abzurufen.--Ulamm (Diskussion) 22:13, 13. Mai 2014 (CEST)

Das soll bei uns wohl am 22. Mai auch kommen, siehe Wikipedia:Kurier#Media Viewer kommt, Foundation benötigt Rückmeldungen. Gruß --Schniggendiller Diskussion 22:17, 13. Mai 2014 (CEST)

Kategorien verschieben

Endlich mal ein richtiger Meilenstein. Schade, dass ich das nicht vermelden durfte. --\m/etalhead ✉ 19:52, 9. Mai 2014 (CEST)

Wenn ich das gewusst hätte, hätte ich dir gerne den Vortritt gelassen ;-). So lässt sich auf jedem Fall die Versionsgeschichte behalten. Aufgrund der inaktivität des Botbetreibers von Sebbot wird es wohl bei WP:KWS keine automatische Verschiebung geben, aber der Einsteller dort könnte die Kategorieseite vorher verschieben, dann legt Sebbot sie nicht automatisch an, stellt aber den SLA auf die Weiterleitung. Aber dauert ja noch/nur 2 Wochen bis es hier verfügbar ist. Der Umherirrende 20:01, 9. Mai 2014 (CEST)

+1, ich habe mich gerade riesig gefreut. IW 20:06, 9. Mai 2014 (CEST)

Ist denn schon klar, ob es dafür eine eigene Benutzergruppe geben wird? --\m/etalhead ✉ 13:15, 11. Mai 2014 (CEST)

Es gibt ein neues Benutzerrecht move-categorypages, standardmäßig wird jeder Benutzer (Gruppe user) das Recht haben. — Raymond ^Disk. 13:21, 11. Mai 2014 (CEST)

En.wp will wohl nur Admins das erlauben: Bug 65221. Der Umherirrende 16:47, 12. Mai 2014 (CEST)

Zwei Kommentare dazu: a) Man sollte das Verschiebungsrecht - zumindest vorerst - nur Sichtern geben. Ansonsten könnte es Chaos geben. b) Wäre es sinnvoll, bei gelöschten Kategorien mit der Zeit die Versionsgeschichte wieder herzustellen und hinterherzuverschieben? Zumindest, wenn die History sehr lange ist, wäre das erwägenswert. 85.212.38.87 00:02, 13. Mai 2014 (CEST)

Im Kategorienamensraum gibt es aktuell 254.935 gelöschte Versionen unter 47.640 verschiedenen Namen. Das spricht für kurze Versionsgeschichten. Eine Wiederherstellung und Verschiebung (vorher muss das Ziel gelöscht werden oder kann man auf bestehenden Namen ohne Löschung schieben?, Verschiebung ohne Weiterleitung wäre möglich) ist in meinen Augen hier nur ABM ohne Nennenswerten nutzen (Keine Schöpfungshöhe und damit kein Lizenzproblem). Zusätzlich ist darauf zu achten, das es nicht zu Überschneidungen in der Versionsgeschichte kommt. Es könnte auch sein, das per Import die Versionsgeschichte bereits übertragen wurde. Ein Überprüfung, wann eine Kategorie nur gelöscht wurde oder wann sie umbenannt wurde ist wohl auch aufwändig. Nicht alles wurde im Kategorie-Projekt besprochen, das man die dortigen Diskussionen als Grundlage nehmen könnte. Im Grundsatz ist die Idee in Ordnung, aber in so einem alten Projekt wie de.wp sollte man mit diesem Cut leben und sich für die Zukunft freuen. Der Umherirrende 21:40, 13. Mai 2014 (CEST)

Richtig, die meisten Versionsgeschichten sind sehr kurz. Es gibt aber auch Kategorien, die eine sehr lange History hatten, also sie gelöscht wurden. Mir fällt gerade leider kein gutes Beispiel ein, aber sowas wie Kategorie:Geschichte deutscher Städte dürfte schon gut dabei sein, oder? 85.212.38.87 22:21, 13. Mai 2014 (CEST)

Naja, geht so ;-) 27 Versionen, darunter 7 Besuche von Interwikibots. Gruß --Schniggendiller Diskussion 22:25, 13. Mai 2014 (CEST)

Wie siehts aus dem mit den ganzen Kategorien wie Kategorie:Geschichte nach zeitlicher Zuordnung, Kategorie:Sport nach zeitlicher Zuordnung, Kategorie:Person nach zeitlicher Zuordnung, Kategorie:Politik nach zeitlicher Zuordnung etc. ? Da dürfte doch einiges zusammengekommen sein. 85.212.38.87 22:49, 13. Mai 2014 (CEST)

• Kategorie:Geschichte nach zeitlicher Zuordnung 15 Versionen
• Kategorie:Sport nach zeitlicher Zuordnung 5 Versionen
• Kategorie:Person nach zeitlicher Zuordnung 8 Versionen
• Kategorie:Politik nach zeitlicher Zuordnung 2 Versionen

Nein, ich mache das nicht mit Absicht, um dir die Tour zu vermasseln ;-) Ich schaue aber auch sehr sehr selten bei Kategorien in die Versionsgeschichte, wüsste deshalb auch keine mit langer Versionsgeschichte :-/ Gruß --Schniggendiller Diskussion 22:56, 13. Mai 2014 (CEST)

Verteilung in dieser Liste (heute neu gemacht, daher passen die Zahlen zu gestern nicht ganz). Es gibt auch eine gelöschte Kategorie mit 395 Versionen … Sehe den Nutzen aber weiterhin nicht. Es sollte reichen, wenn beim Löschen die Diskussion verlinkt wurde oder der neue Name. Bei einem Nachträglichen Verschieben wäre eine passende/gute nachvollziehbare Begründung wohl auch schwierig, würde ja auch in vielen Beobachtungslisten auftauchen. Der Umherirrende 21:55, 14. Mai 2014 (CEST)

Benutzer-ID

Dass die Benutzer-ID nicht mehr angezeigt wird, halte ich für bedauerlich. Natürlich hat Klaus-Bärbel Normalbenutzer keinen direkten Nutzen, aber die ID ist der Primärschlüssel in der Benutzerverwaltung und ich kann keinen Grund sehen, ihn nicht anzuzeigen. Grüße --h-stt !? 17:04, 14. Mai 2014 (CEST)

Und welche Bedeutung hat er für Otto-Poweruser konkret? — Raymond ^Disk. 18:04, 14. Mai 2014 (CEST)

Wohl doch eine identitätsstiftende, sonst geht am End noch die Identität stiften! Nee, aber im Ernst: Wo wird die Benutzer-ID nicht mehr angezeigt? gruß, fcm. --Frank C. Müller (Diskussion) 18:20, 14. Mai 2014 (CEST)

@Frank C. Müller: dort Spezial:Einstellungen-- Conan (Nachricht an mich? Bitte hier lang.) 18:23, 14. Mai 2014 (CEST)

Und zwar ab dem 22. Mai. --\m/etalhead ✉ 18:23, 14. Mai 2014 (CEST)

Umgedrehte Proportionalität der Zahlengröße zur Penislänge. -- 32X 18:24, 14. Mai 2014 (CEST)

Könnte man das nicht auf den 21. Mai verschieben; da ist - glaub ich - mein Hochzeitstach; vielleicht könnte ich mir den dann besser merken! gruß, fcm. --Frank C. Müller (Diskussion) 18:38, 14. Mai 2014 (CEST)

Ich habe noch keinen Nutzen der ID gefunden. Und wer sie doch wissen will oder gar für irgendwas braucht, kann die API verwenden. Aber ich sehe keinen Grund die ID in den Einstellungen anzuzeigen. Es verwirrt und ist nur Platzverschwendung. -- Michi 22:47, 14. Mai 2014 (CEST)

Na ja, ich würde sagen, sie schmeichelt vielen auch, besonders wenn es eine niedrige, frühe ID war. Schade, ich werde sie sicherlich vermissen, wenn ich meine Einstellungen aufrufe. ;) --Aschmidt (Diskussion) 23:49, 14. Mai 2014 (CEST)

Es sollte lieber die SUL-User-ID angezeigt werden zum Schmeicheln :p. --APPER\^☺☹ 20:49, 19. Mai 2014 (CEST)

Enable the anonymous signup invite experiment

Hi, könnte jemand dazu eine verständliche Meldung auf der Vorderseite verfassen? Mir fehlt gerade die Zeit. Danke. — Raymond ^Disk. 20:23, 19. Mai 2014 (CEST)

sollte mw:Anonymous editor acquisition/Signup invites sein, oder? IW 21:15, 19. Mai 2014 (CEST)

Die Einstellung ist Teil von mw:Extension:GettingStarted. Das umstellen heißt eigentlich nur, das jetzt noch mehr JavaScript geladen wird, aber nur für anonyme Benutzer. Explizit das Modul ext.gettingstarted.anonymousEditorAcquisition. Das scheint dann wohl eine GuidedTour zu starten. Der Umherirrende 21:26, 19. Mai 2014 (CEST)

Auch gut, wenn nach wenigen Minuten schon der erste Bug da ist: Bug 65502. Dort gibt es aber auch ein Screenshot von der Funktion. Der Umherirrende 21:31, 19. Mai 2014 (CEST)

Da jetzt schon die erste Frage auf FZW dazu kam, habe ich mal einen kurzen Stichpunkt ergänzt. Gruß, IW 21:44, 19. Mai 2014 (CEST)

Der Bug-Report hat ja mal einen tollen Titel: Unordered list contents for anonymouseditoracquisitionpostedit tour not showing translated content (Hervorhebung von mir). Fast so schön wie Supercalifragilisticexpialidocious :-)) --Schniggendiller Diskussion 03:04, 21. Mai 2014 (CEST)

Media Viewer am 3. Juni (Kurier-Crossposting)

Verzeiht das Crossposting - aber nicht jeder liest den Kurier und hier dürften sich ja die echten Interessierten und Auskenner finden. Deshalb auch noch mal hier der Hinweis: Nachdem der Media Viewer der Wikimedia Foundation mittlerweile auf Commons und in den meisten Wikipedias als Standard eingeschaltet ist, wird dieser Schritt am Dienstag auch in der deutschsprachigen Wikipedia vollzogen werden. Am 3. Juni wird die Wikimedia Foundation den Media Viewer in der deutschsprachigen und kurz danach in der englischsprachigen Wikipedia einschalten. Wer den Media Viewer noch vorher ausprobieren und dem Multimedia-Team der Foundation Rückmeldung geben will, kann ihn in den Benutzer-Einstellungen im Reiter zu den Beta-Features einschalten und dort an der Umfrage teilnehmen. Auch ist es natürlich möglich, dem Multimedia-Team direkt auf der Diskussionsseite zum Media Viewer Rückmeldung zu geben. Der Media Viewer soll vor allem Lesern eine bessere Bildansicht und einen übersichtlicheren Zugriff auf die wichtigsten Informationen zum Bild geben. Auch nach der Standard-Einschaltung am Dienstag ist es angemeldeten Usern möglich den Media Viewer wieder zu deaktivieren.

Weitere Informationen:

• Hilfeseite in der deutschsprachigen Wikipedia
• Umfrage zur Nutzung
• Liste der bekannten Fehler (englisch)
• Zentrale Diskussionsseite (englisch)

-- Dirk Franke (WMDE) (Diskussion) 13:40, 30. Mai 2014 (CEST)

Wikipedia:Technik/Skin/Beta

Ich habe soeben diese Projektseite angelegt.

• Wem ein neues Beta-Feature auffällt: Bitte dort nachtragen.
• Außerdem die Seite bitte beobachten.

Das soll als Ersatz für die ausgeblendete Hinweis-Funktion und die dadurch blockierte Kommunikation dienen; siehe WD:Umfragen/Redesign April 2014 #Kommunikation.

• Und dann darf das noch jemand der Community beibiegen; auch dass sie sich vorher mit angekündigten Veränderungen beschäftigen sollen und nicht immer erst hinterher; dementsprechend an Veränderungen Interessierte die neue Seite beobachten und bei Bedarf PRD, MB oder sonstwas starten mögen.

LG --PerfektesChaos 21:51, 5. Jun. 2014 (CEST)

Wikimedia Engineering 2014-15 Goals

Hallo, als Weitblick ein kleiner Link-Tipp:

• mw:Wikimedia Engineering/2014-15 Goals

So sind die SUL Finalisierung und eine alpha-Version einer REST-API für Jul–Sep 2014 als Ziel ausgegeben. Grüße sitic (Diskussion) 15:47, 11. Jun. 2014 (CEST)

Thx. Was mögen „Product-friendly projects“ sein? Vermutlich nicht wir. :-)) --PerfektesChaos 16:33, 11. Jun. 2014 (CEST)

Stringvergleich mittels #ifeq: und #switch

Der Erklaerungstext "foo's und foo's werden dadurch identisch" trifft nicht ganz das Problem, welches damit behoben wurde. Die Frage ist, ob {{#switch:Foo's|foo's=true}} bei Variablen identisch bleibt, weil sonst muesten wird einiges aendern - vor allen Vorlagen, die Benutzernamen vergleichen. Merlissimo 01:26, 2. Jul. 2014 (CEST)

Auf beta ist das schon aktiv. Dort kannst du das ausgiebig testen. Dein Beispiel dürfte aber aufgrund von Groß-/Kleinschreibung nicht funktionieren. Es scheint aber, das alle Parameter beim switch decodiert werden. Der Umherirrende 19:54, 3. Jul. 2014 (CEST)

Beispiel wäre Wikipedia:Bots/Liste der Bots/hat Flag mit {{BASEPAGENAME}} im switch und "D&#39;ohBot" im case. Merlissimo 20:01, 3. Jul. 2014 (CEST)

Mein vorher/nachher-Test sieht gut aus. Der Umherirrende 20:17, 3. Jul. 2014 (CEST)

Danke für's nachschauen. Somit müssen wir dann nichts ändern. Merlissimo 23:45, 3. Jul. 2014 (CEST)

Fehlende Tabellenaktualisierung nach Umwandlung von Redirects in Nichtredirects

Nach der Umandlung der Weiterleitung Grün (Vogtland) in einen Kurzartikel wird der Link im Artikel Abhorn nach über 50 Stunden noch immer als Weiterleitung angezeigt (letzte Bearbeitung vor der Umwandlung), im Artikel Lengenfeld (Vogtland) hingegen regulär als Artikel (letzte Bearbeitung nach der Umwandlung). Vor nicht allzulanger Zeit wurden noch die Artikellinks nach der Umwandlung der Weiterleitung in eine Nichtmehrweiterleitung sofort aktualisiert.

Ganz offensichtlich wurde etwas im Verhalten geändert. Ist es ein Bug? Ist es ein Feature? -- 32X 21:39, 7. Jul. 2014 (CEST)

ich habs gepurged für dich. --Wetterwolke (Diskussion) 22:15, 7. Jul. 2014 (CEST)

Bist ein Held, auf die Idee wäre ich gar nicht gekommen. Wirst du das jetzt auch bei allen anderen Artikeln, die auf diesen verweisen, nachholen und zukünftig für alle umgewandelten Ex-Weiterleitungen tun? -- 32X 22:20, 7. Jul. 2014 (CEST)

ne werd ich nicht. aber in Hilfe:Purge#Purge ist ja beschrieben wies geht, also kannst dus duch dranhängen von ?action=purge in der adresszeile und dann enter drücken selbst machen ;)

hier Wikipedia:Vandalismusmeldung/Archiv sind sogar die letzten 6 tage rot. wann automatisch die server-caches geleert werden kann ich dir nicht sagen, aber vielleicht einer der mitlesenden technicker hier. gruß --Wetterwolke (Diskussion) 01:21, 8. Jul. 2014 (CEST)

Es liegt an der Umstellung von | und geht auch wieder weg, sagt Merlissimo. Diese Info hätte ich hier erwartet, nicht eine kindergärtliche Einführung am Herumdoktorn an Symptomen mittels Purge. -- 32X 11:25, 14. Jul. 2014 (CEST)

Dieser Abschnitt kann archiviert werden. -- 32X 11:25, 14. Jul. 2014 (CEST)

Versionsgeschichten vereinen

Mal wieder ein lang ersehnter MediaWiki-Meilenstein, wenn auch nur für Admins. Es kann also nur noch besser werden. --\m/etalhead ✉ 15:49, 10. Jul. 2014 (CEST)

Der umseitige Link ist ja schon blau, allerdings bekomme ich einen Berechtigungsfehler, wenn ich versuche, die Spezialseite aufzurufen. Gibt es derzeit schon Benutzergruppen, die Versionsgeschichten vereinigen können? Gruß, IW 18:50, 10. Jul. 2014 (CEST)

Nein, nach einer Optimierung des Prozesses/Spezialseite wurde lediglich die Berechtigungen an Administratoren auf allen Projekten erteilt. Dem sind aber Bugzilla-Requests einiger Wikis vorrangegangen. Die Spezialseite gibt es schon seit einiger Zeit. Wenn es schon eine Benutzergruppe geben würde, wäre diese auch in der Fehlermeldung enthalten, vergleiche Spezial:Wiederherstellen unangemeldet ;-) Der Umherirrende 19:41, 10. Jul. 2014 (CEST)

Alles klar, danke für die Aufklärung. Gruß, IW 21:23, 10. Jul. 2014 (CEST)

Damit man sich keine zu großen Hoffnungen macht, kleiner test unter http://de.wikipedia.beta.wmflabs.org/wiki/Spezial:Logbuch/merge

Erste Feststellung: Es können nur Versionen der Ursprungsseite übertragen werden, die älter sind als die älteste Version der Zielseite. Dadurch ergeben sich auf jedem Fall keine zeitlichen Vermengungen in der Übersicht der Versionsgeschichte, wie es mit Löschen/Verschieben/Löschen/Wiederherstellen möglich ist. Der Umherirrende 11:50, 16. Jul. 2014 (CEST)

Seit einigen Tagen gibt es im Admin-Handbuch eine eigene Seite zum Fertigschreiben: Hilfe:Seiten vereinen; ggf. Löschen der alten Geschichten – enjoy. --PerfektesChaos 21:15, 16. Jul. 2014 (CEST)

Wartungskategorie für Einzelnachweise Version 1.24wmf14

Moin Moin zusammen, wie kann ich denn Text verstehen: "Der Name der Wartungskategorie kann über die Systemnachricht MediaWiki:Cite error refs without references category konfiguriert werden"? Hier in der deutschsprachigen Wikipedia haben wir ja bereits die Wartungskategorie: Kategorie:Wikipedia:Seite mit fehlendem References-Tag! Wird diese dann benutzt, oder kommt eine völlig Neue? mfg --Crazy1880 11:49, 18. Jul. 2014 (CEST)

@Crazy1880: Danke für den Hinweis. Ich habe die vorhandene Wartungskategorie Kategorie:Wikipedia:Seite mit fehlendem References-Tag jetzt in MediaWiki:Cite error refs without references category eingetragen. Damit wird es keine neue/weitere geben (müssen). — Raymond ^Disk. 11:59, 18. Jul. 2014 (CEST)

@Raymond:, vielen Dank für die schnelle Umsetzung. mfg --Crazy1880 12:02, 18. Jul. 2014 (CEST)

Vorbemerkungen für die Woche vom 25. August

• Für Montag, den 25. August, (zw. 17-18 Uhr) ist die standardmäßige Erhöhung der Vorschaubildgröße von 220px auf 300px geplant. (Gerrit:154408) Änderbar für Angemeldete in den Einstellungen.
• Für Dienstag, den 26. August, (zw. 17-18 Uhr) ist die Aktivierung von globalen CSS und JS-Seiten vorläufig geplant. (Gerrit:154432) Vorsicht, falls man bereits eine global.css/js Benutzerunterseite auf meta-Wiki hat.
• Für Dienstag, den 26. August, (zw. 20-22 Uhr), ist die Einführung eines neuen Beta-Features Other projects sidebar geplant.

Planungskalender auf wikitech:Deployments. Viele Grüße --se4598 / ? 17:24, 18. Aug. 2014 (CEST)

Insbesondere die Erhöhung der minis auf 300px dürfte für einige Projektteilnehmer zur Katastrophe werden. Ich habe das seit ca. 2007 aktiviert (als wir noch 180px-Briefmarken hatten) und habe mich über die Jahre daran gewöhnt, dass vielbebilderte Artikel unter Umständen schlicht Scheiße aussehen (bzw. sogar Scheiße² auf großformatigen Weitbildmonitoren im Vollbild). Wer das jetzt alles auf einen Schlag mitbekommt, ist vielleicht weniger davon angetan. Auch vergleichsweise riesige Eingangsfotos (hochkant=2), die den Text zerquetschen, werden plötzlich überall zu sehen sein. Eventuell sollte Birgit Müller ihre Schäfchen vorwarnen. -- 32X 10:25, 19. Aug. 2014 (CEST)

Als ich diese News las, musste ich schmunzeln, sicher wird das ein Riesenaufreger werden. Aber: Ich bin verdammt froh. So kann man endlich diejenigen in die Schranken verweisen, welche meinen, Bilder exakt so positionieren zu müssen, so dass diese auf dem (eigenen) Monitor perfekt aussehen. Spätestens jetzt sollen die merken, dass so was vergebliche Lebensmüh ist. Besser wäre allerdings noch: die Bildgrösse sollte für angemeldete User jede Stunde auf einem zufälligem Wert ändern ;-) - so wäre man diese Seuche los. --Filzstift ✏ 10:45, 19. Aug. 2014 (CEST)

Was die Hochformat-Vorlage angeht muss ich dir recht geben, die schauen mit 300px wirklich grauenhaft aus – wird man aber anpassen können.

Was ich mir ja schon lange wünsche, ist das in den Einstellungen auch Bildgrößen von über 300px angeboten werden. Mit dieser Änderung wird der Default gleichzeitig das Maximum sein – was sind den die Gründe gegen eine Erweiterung? Server-Performance? -- Michi 12:14, 19. Aug. 2014 (CEST)

@32X, auf der Kurier-Rückseite ist die Neuigkeit schon angekommen. Aber Du hast Recht, das ist ne wichtige Nachricht, um sie weiter zu streuen - es kommt in jedem Fall noch in die Wikipedia:Wikimedia:Woche und vielleicht trotzdem noch in den Kurier. Weitere Ideen? :) -- Birgit Müller (WMDE) (Diskussion) 17:35, 19. Aug. 2014 (CEST)

Ich hab mir sagen lassen, dass recht viele Leute (das mir ziemlich unbekannte) Wikipedia:Autorenportal aufsuchen. Auch kann man eine kurze Vorankündigung bei den WP:Fragen zur Wikipedia hinterlassen, dort muss allerdings eine Alibi-Frage („Findet ihr das dufte?“) gestellt werden, sonst kommt sofort der Erledigtvermerk mit dem Hinweis „Wo ist die Frage zur Wikipedia?“. Im WP:Café gibt es zwar nur Laberköppe, aber evtl. wirken die ebenfalls als Multiplikatoren. (Bitte nicht an jeder Stelle den gleichen Standardtext abkippen, sondern kontextsensitiv/zielgruppengerecht formulieren. Das dauert zwar einen Tick länger, kommt bei der Basis aber auch besser an.) Damit dürfte die hin und wieder von WMDE/der WMF eingeforderte „Bringschuld“ abgegolten sein, der Rest ist eine autorenseitige Informations-„Holschuld“. -- 32X 17:54, 19. Aug. 2014 (CEST)

Kann man die hochkant=2 Bilder (ich bekenne mich schuldig!) eigentlich per neuer insource: Suche finden? Und noch genauer mit incategory: oder so? Tipps?

Beispiel, 1.291 Artikel mit insource:"hochkant=2" https://de.wikipedia.org/w/index.php?title=Spezial%3ASuche&profile=advanced&search=insource%3A%22hochkant%3D2%22&fulltext=Search&ns0=1&profile=advanced --Atlasowa (Diskussion) 18:37, 19. Aug. 2014 (CEST)

@32X, vielen Dank!! Es ist jetzt erst mal im Kurier und in der Woche. Bin die Orte, die Du mir genannt hast, nochmal durchgegangen - im Autorenportal gibt es nicht wirklich einen Ort für Ankündigungen - bzw. wird von dort zu den Projektneuheiten verlinkt... . Fragen zur Wikipedia, ja - vielleicht eher der Ort zum Antworten, wenn sich ab Montag Abend Leute über größere Bilder wundern :). Der Grat zwischen "mehr Mut zu ungewöhnlichen Orten" und "unpassendes Platzieren von Infos an Orten, die eigentlich für was anderes sind" ist in jedem Fall schmal (wie Du es auch beschreibst). Denke, dass zeigt nochmal, dass es hier mehr gute Ankündigungsmöglichkeiten geben muss... - globale Banner ist für größere Änderungen sicher eine Möglichkeit, und für den Bereich Beta-Features gibt es zumindestens gerade Überlegungen, das sichtbarer zu gestalten, zum Beispiel über ein Pop-up-Fenster oder eine Echo-Erweiterung. Die Frage von Informationen und Zugängen wird auch mit Thema der Werkstatt sein, die ich auf der WikiCon anbieten will - solltest Du zufällig dort sein... freue ich mich :). -- Birgit Müller (WMDE) (Diskussion) 20:54, 21. Aug. 2014 (CEST)

@Michi: Prinzipiell spricht nichts gegen eine größere Vorschaubild-Option; man erwägt das Produzieren von Vorschaubildchen ohnehin auf eine andere Technik umzustellen, um sie schneller erzeugen zu können und man zieht in Erwägung nur noch bestimmte Vorschaubildgrößen zu generieren, diese aber nicht on-demand sondern direkt nach dem upload (so dass es für Besucher schneller geht) und plant auch noch andere Änderungen bzgl. Vorschaubildern; Du kannst Deinen Vorschlag also gern zur Diskussion stellen. (z.B. ein feature request auf Bugzilla oder der wikitech-l mailinglist). Evtl. wird es Bedenken bzgl. des Varnish Cache Speichers geben oder der Last auf die "Image Scaler", aber es klingt nach einem vernünftigen Vorschlag und warum sollte man den ablehnen. Für Geräte mit unüblich hoher Pixeldichte werden auch jetzt schon Vorschaubildchen mit höherer Auflösung als 300 px Breite generiert. -- RE rillke fragen? 20:10, 22. Aug. 2014 (CEST)

Danke für die schöne Zusammenfassung der Lage. Hab einen Bug erstellt. -- Michi 16:05, 25. Aug. 2014 (CEST)

So wie es aussieht, kommt die Vorschaugrößenänderung wohl doch nicht zum veranschlagten Termin. Oder Jforrester übergeht alle Bedenken. -- RE rillke fragen? 20:10, 22. Aug. 2014 (CEST)

Ich halte von dieser Änderung gar nichts. Das gibt eine Unmenge Arbeit, da viele Layouts zerschossen werden. Schon die letzte Pixelerhöhung von 180px auf 220px war überdimensioniert, ideal wären 200px. Man sollte noch mal verinnerlichen, dass Bilder der Illustration des Textes dienen. Wo es geboten war, konnte man Bilder mit der Funtion hochkant= anpassen, z. B. bei Karten, die sonst unleserlich wären. Alles andere dient dazu, den Text in den Hintergrund zu drücken, ihn, übertrieben ausgedrückt, zur Bilderbeschreibung zu missbrauchen. Wenn nun Bilder zur Illustration verwendet werden, sind die Möglichkeiten bei 300px begrenzter. Ganz einfach aus dem Grund, dass weniger Bilder verwendet werden können, sie in den entsprechenden Textabschnitten, die sie illustrieren sollen, unterzubringen. Das wird wohl zu mehr Galerien führen, wobei die Bilder dann nicht mehr in den entsprechenden Textabschnitten erscheinen. Das mit dem Wegfall des „Vergrößerungssymbols“ (siehe diese Diskussion) wäre allerdings eine gute Sache für die Bildunterschriften, man klickt sowieso direkt ins Bild, wenn man es groß sehen möchte. Aber das ist am 25. August ja nicht geplant. --Oltau ^✉ 20:20, 22. Aug. 2014 (CEST)

PS: Da kommt noch mehr dazu: Bei Artikeln mit Infoboxen konnte man bisher Bilder am Anfang eines Artikels nach links setzen, ohne dass der Text wesentlich gestört wurde. Bei 300px-Bildern ist der Text dann aber zwischen Bild und Infobox eingeklemmt, wenn überhaupt noch Platz für den Text ist (unterschiedliche Bildschirmauflösung). Die Druckansichten von Wikipedia-Artikeln kann man dann gleich ganz vergessen. In weiteren Artikeln muss man Bilder, die links stehen, herausnehmen, da sie die nächsten Abschnittsüberschriften nach rechts verschieben bzw. ganz in die nächsten Abschnitte hineinragen usw. usf. ...

Die meisten deiner Bedenken kennt die WMF, denn ich hatte mich selbst aktiv gegen die Erhöhung der Größe ausgesprochen, siehe en:Wikipedia:Village pump (technical)/Archive 128#Time for the semi-annual enlarging of thumbnail images (ja, die Leute auf enwiki wurden sogar nach ihrer Meinung gefragt).
Leider lautet die Reaktion der WMF aber auch hier (wie so oft in letzter Zeit...) im Wesentlichen "danke für eure Kommentare, wir haben eure Bedenken zur Kenntnis genommen, wir machen aber trotzdem das was wir selbst für richtig halten". Lieber Wikipedia für einige Leute komplett unbrauchbar machen als der Mehrheit eine suboptimale "experience" zuzumuten *kopfschüttel*... --Patrick87 (Diskussion) 16:25, 23. Aug. 2014 (CEST)

GlobalCssJs Announcement

„I am excited to announce that on Tuesday, August 26, we will be deploying the GlobalCssJs extension, which enables per-user JavaScript and CSS across public Wikimedia wikis. Users will be able to create global.js and global.css subpages on Meta-Wiki and these pages will automatically be loaded across all public Wikimedia wikis.

There is documentation available if you want to load JavaScript on a subset of all wikis (e.g., all Wikisources, all French language projects, etc.).

Some users currently have manually set up global JavaScript/CSS by creating local user subpages (e.g., monobook.js/css subpages) to load their global scripts. For these users, the deployment of the extension will mean that modules will be loaded twice, and they will no longer be included in global scope. A script has been prepared to delete these page if they were created in the standard format. Users can signup at a Meta-Wiki page to have this done on their behalf once the extension is deployed.

Thanks,“

– Legoktm: wikitech-ambassadors mailing list

--se4598 / ? 11:49, 22. Aug. 2014 (CEST)

Toll, endlich kann man den MultimediaViewer für alle Projekte auf einmal deaktivieren :) IW 18:30, 26. Aug. 2014 (CEST)

Es gibt nicht nur das Modul ext.globalCssJs.user, sondern auch ein ext.globalCssJs.site – wozu auch immer, aber wenn man da rankäme, könnte man mal für alle Projekte die Alpha- und Beta-Produkte aussortieren. LG --PerfektesChaos 18:50, 26. Aug. 2014 (CEST)

mw-disambig

Nachdem seit 11. September Links auf Begriffsklärungsseiten mit der CSS-Klasse mw-disambig markiert werden, schlage ich folgende CSS-Definition vor:

.mw-disambig {
	background-color: #ff9191;
}
.mw-disambig:after {
	background-color: #ff9191;
	content: "BKL";
	font-size: x-small;
	line-height: 0;
	vertical-align: super;
}

MediaWiki:Gadget-bkl-check.js markiert neben Links auf Begriffsklärungsseiten aber auch noch Falschschreibungen und obsolete Schreibungen. --Fomafix (Diskussion) 13:28, 13. Sep. 2014 (CEST)

Obiges noch nicht getestet, sieht aber gut aus. Ich würde auch vorschlagen, das derzeitige Gadget aufzuteilen: Der BKL-Check als reines CSS-Gadget, das keinen API-Call mehr benötigt und ein neues Gadget für Falschschreibungen und obsolete Schreibungen. — Raymond ^Disk. 14:05, 13. Sep. 2014 (CEST)

1. Farbvisualisierung
2. @Fomafix: Du verrätst uns nicht, wo du diesen Code hinschreiben möchtest.
   • Nach MediaWiki:Common.css soll das hoffentlich nicht.
     • Das würde bedeuten, dass alle nur-lesenden IP in den Artikeln unverständliche Farben und eine kryptische Abkürzung vorfänden.
     • Die BKL-Markierung ist ein Hilfsmittel für die Artikeltexte pflegende Autoren.
3. Das gehört also wohl eher in ein Gadget-DisambigLight (kein default).
   • Das wäre dann etwas für Leute, die ohne JS arbeiten möchten oder eine langsame und teure Netzwerkanbindung haben oder Wert auf einen schnellen ruckelfreien Seitenaufbau legen, jedoch auf redirect + FS + Kat verzichten können.
4. Das derzeitige Helferlein war mal an der Spitze der Technologie, wird jetzt hinter der roten Laterne nachgeschleift.
   • Es sollte in Ehren durch einen zeitgemäßen Nachfolger ersetzt werden.
   • Auf WD:Helferlein/Begriffsklärungs-Check #Funktioniert das Helferlein aktuell nicht? gibt es schon entsprechende Diskussion; wobei Schnark die zusätzliche API-Abfrage unterlassen könnte, wenn er schon die Klasse sieht.
   • Wer mit JS arbeiten möchte, bekommt dann halt entsprechendes Vollprogramm in einem einzigen Gadget neuer Technologie.

VG --PerfektesChaos 14:40, 13. Sep. 2014 (CEST)

Der obige Vorschlag wird auch Falsch- und obsolete Schreibweisen markieren, da auch diese Vorlagen ein __DISAMBIG__ setzen. Nicht erfasst werden dagegen Weiterleitungen auf Begriffsklärungen.

Insofern ist die CSS-Variante nur geeignet für „einfach und schnell, aber nicht 100%ig korrekt“, für ein ernsthaftes und sinnvolles Markieren kommt man aber um die API nicht herum. Ein doppelgleisiges Arbeiten sowohl mit der Klasse als auch der API macht den Code nur unnötig kompliziert ohne wirkliche Vorteile zu bringen. Ob der potentielle Nutzerkreis für ein reines CSS-Gadget wirklich so groß ist, dass es sich als weiteres Gadget parallel zum bestehenden BKL-Check lohnt, bezweifle ich. Auch wenn ich immer wieder kritisiere, dass unsere Gadgets nicht gepflegt und neueren Entwicklungen angepasst werden, in diesem Fall bin ich sehr dafür, die Neuerung zu ignorieren und alles so zu lassen, wie es ist. --Schnark 09:29, 15. Sep. 2014 (CEST)

• @Gadget-Angebot:
  • Ich stimme zu, dass wir unsere preferences-Ankreuzliste schlank und übersichtlich halten sollten.
  • Insofern wäre es völlig okay, eine geäußerte breitere Nachfrage abzuwarten und einstweilen den CSS-Code in der Gadget-Doku zum Selbereinfügen zu parken.
  • Allein – warum eigentlich ein separates Gadget, fällt mir grad ein?
    • Der obige Code könnte demselben bisherigen Gadget als CSS-Ressource hinzugefügt werden.
    • Bisher war eine CSS-Komponente ja sinnlos.
    • Jetzt würde sie auch bei deaktiviertem JS wirksam werden und eine Q&D-Light-Version mit demselben preferences-Häkchen sicherstellen; halt nicht ganz so präzise.
    • Ohnehin würde das CSS frühzeitig und hoffentlich vor DOM.ready geladen werden und damit ein ruckelfreies Darstellen ermöglichen, weil es dann vor dem Rendern ohne API-Traffic schon aktv wäre. Davon hätten auch die JS-Aktiven etwas.
• Ich schrieb neulich, dass dein Code aufgrund der neuen Klasse überarbeitet werden müsse.
  • Damit meinte ich, dass du das Volumen der API-Abfrage deutlich reduzieren kannst.
  • Abzufragen sind jetzt nur noch die .mw-redirect hinsichtlich ihres Weiterleitungsziels (bis PHP dann vielleicht mal beide Klassen ausliefert), und die .mw-disambig dahingehend, ob die Buchstaben von „BKL“ in „OS“ oder „FS“ nachgebessert werden müssten; prozentual ein sehr geringer Anteil, weil durch Wartungsameisen aus den Artikeln eliminiert.
  • Sicherheitshalber für den Fall einer isolierten Verwendung sollte das JS aber den obigen CSS-Code so früh wie irgend möglich in das Dokument reinschieben; schadet kaum was. Natürlich I18N-BKL benutzersprachlich angepasst.
  • Nur für die seltenen benutzerdefinierten Kategorien müsste nach althergebrachter Art jedes Wikilink im geeigneten NR analysiert werden.

Sonnigen Tag --PerfektesChaos 10:36, 15. Sep. 2014 (CEST)

PS: Ach quack, wir haben doch auch jetzt schon einen MediaWiki:Gadget-bkl-check.css. Der kann jetzt mit dem neuen CSS-Code verfeinert werden; aber warum stand das nicht bisher schon da drin, die brauchen den Links duch nur eine selbst ausgedachte Klasse zuzuweisen? Naja, Altlast halt. VG --PerfektesChaos 10:42, 15. Sep. 2014 (CEST)

Damit meinte ich, dass du das Volumen der API-Abfrage deutlich reduzieren kannst. – Das stimmt nur in der Vorschau (und in einem Artikel ganz ohne Weiterleitungen und BKLs, dort ist eine Reduktion möglich, aber keine deutliche). In allen anderen Fällen kann man das Volumen der API-Abfrage nicht reduzieren (weder deutlich noch sonstwie). Da ich meinen Code für die Vorschau auch für dynamisch erzeugten Inhalt und Spezialseiten verwende (wo die neue Klasse fehlt), würde das auf komplexeren Code hinauslaufen. Die Klasse .m-disambig bietet einen minimalen Geschwindigkeitsgewinn, der aber aufwändigeren Code erfordert, wenn man ihn ohne Nachteile ausnutzen will. Das ist es in meinen Augen einfach nicht wert. --Schnark 11:05, 15. Sep. 2014 (CEST)

Die Auslagerung der Darstellung von MediaWiki:Gadget-bkl-check.js in die oben ausgeführte CSS-Definition habe ich bereits vor über vier Jahren vorgeschlagen und bereitgestellt. Kein Wunder, dass hier die Gadgets vergammeln, wenn Änderungen nicht übernommen werden. --Fomafix (Diskussion) 21:29, 15. Sep. 2014 (CEST)

MediaWiki:Spam-blacklisted-category

re Special:Diff/128499385. Vorschlag für Inhalt der obigen Systemnachricht: „Wikipedia:Seiten mit Links auf der Spam-blacklist“, alternativ auch das B groß geschrieben. --se4598 / ? 15:06, 14. Mär. 2014 (CET)

Veto.

„Spam-blacklist“ ändert gerade ihren Namen auf „Weblinks/Filter“.

Hat noch ein paar Tage Zeit; bitte mit user:lustiger seth abstimmen.

Könnte demnach auch etwas wie Wikipedia:Seiten mit gefilterten Weblinks werden.

VG --PerfektesChaos 15:29, 14. Mär. 2014 (CET)

Hast du dazu weitere Infos? Gefilterte Weblinks hört sich ja jetzt auch nicht schlecht an. Da dazu seth anscheinend gerade noch etwa 3 Wochen im Urlaub ist, fände ich den obigen Vorschlag oder deinen besser als wenn die zwischenzeitlich in Kategorie:Seiten mit schwarzgelisteten Links aufschlagen. --se4598 / ? 15:41, 14. Mär. 2014 (CET)

Dazu gehört noch Gerrit:118636, der aber noch nicht reviewed ist. Damit werden Blacklist-Weblinks im Artikel entlinkt bzw. entfernt. Ich denke, das muss man im Gesamtkontext sehen. Ich habe mich nämlich schon gefragt: wozu eine Kategorie, wenn man doch gar keine Blacklist-Weblinks abspeichern kann. — Raymond ^Disk. 15:44, 14. Mär. 2014 (CET)

Ich habe die Kategorie erstmal auf deaktiviert gesetzt. Ich sehe noch kein Nutzen darin, Seiten aufzulisten die ein geblackten Link enthalten. Vorallem nicht, wenn die Änderung der Blacklist nicht ein LinkUpdate zur Aktualisierung der Kategorieeinträge auslöst. Soweit ich weiß, wurde auf de.wp auch mal Links auf die Blacklist gesetzt, obwohl die bereits existierenden Links okay sind. Dann müsste man solche Links auf die Whitelist setzen, auch wenn man sie nicht in weiteren Artikeln haben möchte oder so. Der Umherirrende 15:50, 14. Mär. 2014 (CET)

Namensgebung: MediaWiki Diskussion:Spam-blacklist #name der unterseite

Zeitplan: April und seth abwarten. Solange niemand die Kat auswertet, muss sie auch noch nicht aktiviert und benannt sein, und spam-blacklisted-text, spam-blacklisted-bad-text sowie spam-blacklisted-url können dann im Zusammenhang konfiguriert werden.

Schönen Sonntag --PerfektesChaos 21:58, 14. Mär. 2014 (CET)

gudn tach!

zum text:

eigentlich egal, ob erst mal "Seiten mit Links auf der Spam-blacklist" oder -- mit blick auf die kuenftige umbenennung -- "Seiten mit gefilterten Weblinks". nur bei den "schwarzgelisteten Links" musste ich ehrlich gesagt lachen.

zum neuen feature: @Raymond, ich hab's noch nicht verstanden. Der Umherirrende hat recht, dass das bisherige verhalten als feature interpretiert und genutzt wurde und man sich bei einer aenderungen recht viel arbeit aufhalsen wuerde. -- seth 22:31, 10. Apr. 2014 (CEST)

HHVM

klingt ja interessant, aber wozu braucht man dafür eine Änderungs-Markierung, wenn gar nicht auf den Prozess des Bearbeitens Einfluss genommen wird? Gruß, IW 17:23, 19. Sep. 2014 (CEST)

Laut Mail-Ankündigung: “Edits made by users with HHVM enabled will be tagged with 'HHVM'. The tag is there as a precaution, to help us clean up if we discover that HHVM is mangling edits somehow. […]” Gruß --Entlinkt (Diskussion) 17:58, 19. Sep. 2014 (CEST)

Ok, aber dann sollte endlich eine Möglichkeit geschaffen werden, solche Markierungen nach dem Ende einer solchen Testphase wieder entfernen zu können. Im Moment sehe ich es kommen, dass mehr und mehr Versionsgeschichten mit dieser Markierung befüllt werden und bleiben, ohne dass sie in einem Jahr noch einen Sinn hätte. Gruß, IW 18:12, 19. Sep. 2014 (CEST)

Welche Nachteile haben die Markierungen? --Tim Landscheidt 20:19, 19. Sep. 2014 (CEST)

Naja, über die Jahrzehnte hinweg betrachtet sind sie doof und verwirrend in der Versionsgeschichte der inhaltlichen Beiträge; und solch temporäres Debugging-Zeugs sollte durch eine weltweite Serverpolitur auch wieder entfernt werden. Gilt auch für alte VE-Bearbeitungen und Mobil-Gedöns, nachdem die Jahresstatistik gemacht wurde. Unsere Artikel sind nicht die Strichliste der Software-Entwickler für ihre Gehversuche.

VG --PerfektesChaos 10:34, 20. Sep. 2014 (CEST)

Kleine Strukturänderung

Angeregt durch eine Session auf der soeben zu Ende gegangenen WikiCon habe ich umseitig für das übernächste Deployment eine kleine Strukturänderung ganz willkürlich ausprobiert:

• Reduzierung auf 2 Abschnittsüberschriften: „Für Jedermann“ und „Für Programmierer“
  • Hintergrund ist, dass viele Wikipedianer die Neuheiten lesen, teilweise über den Ausrufer, aber sich lediglich nur wenige wirklich für den Programmierkram (API, JS, Lua) interessieren. Quelle: Empirie durch persönlich Gespräche.
• Unterhalb von „Für Programmierer“ keine weitere Überschriftshierachie, sondern mit ; gearbeitet (semantisch unsauber, oder? Alternative?).
  • Reduziert die Länge des Inhaltsverzeichnisses

Was ist eure Meinung dazu? Ich habe auch schon drüber nachgedacht, den Programmier-Teil hier auszulagern, aber ich weiß noch nicht, ob das a) wirklich sinnvoll ist und b) wohin. Auch dazu interessiert mich eure Meinung.

Weiterhin werde ich mich bemühen, für den Jedermann-Teil künftig ausführlicher und OMA-tauglicher zu beschreiben, wozu die Neuheit jeweils gut ist, welche Vor- oder Nachteile sie bringt. Auch hierzu benötige ich eure Hilfe für künftige Einträge. Danke. — Raymond ^Disk. 19:19, 5. Okt. 2014 (CEST)

Finde ich gut.

Ich kann problemlos damit leben, dass im Programmierer-Teil nur noch eine einzige *-Liste steht und am Anfang jedes Punktes in kursiv ein Schlagwort steht wie: API: Lua: JS: core: MediaViewer: Bearbeitungsfilter: GUI: CSS:

Vielen Dank bei der Gelegenheit für deinen zuverlässigen und wohl über ein Jahrzehnt gehenden Newsservice --PerfektesChaos 19:52, 5. Okt. 2014 (CEST)

Es gibt auch Leute, die nicht alles verstehen, dennoch über den eigenen Tellerrand blicken wollen und sich freuen, hin und wieder etwas sofort zu verstehen, obwohl es gar nicht für sie gedacht war. Ich würde den zweiten Teil deshalb nicht auslagern, zumal hier eine relativ zentrale Stelle für Neuerungen existiert. Man wird nicht dadurch besser informiert, indem man mehr Seiten auf die Beobachtungsliste nimmt. -- 32X 10:34, 6. Okt. 2014 (CEST)

+1. Normalerweise lese ich nur, was bisher unter Allgemeines stand, überflieg aber gerne auch mal den Rest. Bin daher dafür, dass nichts ausgelagert wird. Ob wir nun zwei Überschriften haben oder vier, ist mir eigentlich egal. -- TZorn 11:30, 6. Okt. 2014 (CEST)

Die umseitig getestete Struktur finde ich in Ordnung, die Fett- und Kursivschrift erscheint mir aber etwas zu wuchtig. Ein einfaches (API), (Missbrauchsfilter) etc. wie bei der (Softwareneuheit) ist mE für die Augen angenehmer. Gruß, IW 19:37, 6. Okt. 2014 (CEST) PS: Auch von mir einen Dank für die jahrelange Pflege dieser Seite. Ich freu mich immer wieder, wenn sie auf meiner Beobachtungsliste auftaucht.

Danke für euer Feedback. Wichtig waren für mich die Aussagen, dass eine Abtrennung des technischen Teils auf eine separate Seite nicht sinnvoll ist. Ich habe die diese Woche kommenden Änderungen entsprechend umgestellt: Wikipedia:Projektneuheiten#Vorschau auf Version 1.25wmf2. Passt das so? — Raymond ^Disk. 20:33, 6. Okt. 2014 (CEST)

Gefällt mir in der aktuellen Vorschau-Version schon sehr viel Besser! Vielen Dank! Man könnte als Kompromiss zwischen den Wünschen "auslagern" und "zusammen lassen", eine einklappbare Box verwenden. "Für Jedermann" könnte man auch in "Für Wikipedianer" umbenennen. -- Michi 20:55, 6. Okt. 2014 (CEST)

New TemplateData editor

Hi all, this looks like a good place to draw some attention to my announcement about the new TemplateData editor which will soon be available also on this wiki. I hope people who were involved in adding TD to templates here will find out, and that the tool will make this task a bit easier and less boring for all :) Best, --Elitre (WMF) (Diskussion) 20:04, 6. Okt. 2014 (CEST)

Related to VE, here's the latest issue of the global newsletter, fully translated! --Elitre (WMF) (Diskussion) 11:55, 13. Okt. 2014 (CEST)

Gerrit:160222

Umseitig wird Gerrit:160222 sowohl bei der Vorschau für Version 1.25wmf5 als auch 1.25wmf6 genannt. Eine Suche in mw:MediaWiki 1.25/wmf5 ergab einen Treffer, allerdings mit einer anderen Gerrit-Nr. (oder habe ich das falsch verstanden?), während mw:MediaWiki 1.25/wmf6 noch leer ist. Gruß --Schniggendiller Diskussion 02:10, 27. Okt. 2014 (CET)

@Schniggendiller: Danke fürs Aufpassen, denn ich habe beim Eintragen gepennt. Der Eintrag gehört wirklich unter 1.25wmf5, da er am bereits am 22. Oktober gemerged wurde. Ein Kommentar am 24. Oktober hat ihn wieder nach oben in die Liste gespült und sah für mich neu aus. Ist nun umseitig korrigiert. — Raymond ^Disk. 07:54, 27. Okt. 2014 (CET)

CategoryCollation

Guten morgen zusammen,

basierend auf diese Fragestellung. Hat sich schonmal jemand mit der Möglichkeit der CategoryCollation für Deutsch auseinandergesetzt? Wenn ich das richtig verstehe, würde die Mehrzahl der SORTIERUNG-Befehle für Umlaut/ß-Lemmata entfallen können? Was wäre nötig, um das hier umzusetzen:

• Testinstanz auf Labs
• (kleines) Meinungsbild

Im Moment sehe ich nur Vorteile, aber gibt es auch Nachteile? — Raymond ^Disk. 08:57, 31. Okt. 2014 (CET)

Siehe Hilfe Diskussion:Kategorien/Archiv/2#Automatisch korrekte Kategorie-Sortierung. Drei Probleme gibt es:

• Die Regel, wie wir unsere Sortierschlüssel für Zahlen mit variabler Stellenanzahl erzeugen, muss angepasst und alle bestehenden Anwendungen aktualisiert werden.
• Die Serveradministratoren müssen gerade in der richtigen Stimmung sein, um sämtliche Sortierschlüssel neu berechnen zu lassen. (bugzilla:56041)
• Selbst ein kleines Meinungsbild kann durch die völlig irrelevante Diskussion, ob es SORTIERUNG oder DEFAULTSORT heißen soll, bis zur Unbrauchbarkeit zerredet werden.

Wer etwas ausprobieren möchte, kann gerne meine portugiesischen Testseiten mitbenutzen: pt:Categoria:!Subpáginas de Schnark. --Schnark 09:51, 31. Okt. 2014 (CET)

Danke für den Link auf die archivierte Diskussion. Hatte ich 2012 verpasst. Was ich aber noch nicht ganz verstanden habe, ist der Punkt Sortierschlüssel für Zahlen mit variabler Stellenanzahl. Wo tritt das Problem auf? Und ließe es sich für diese Fälle nicht mit einem dedizierten SORTIERUNG lösen? — Raymond ^Disk. 13:01, 31. Okt. 2014 (CET)

Moin Moin zusammen, hier wurde angeregt, die Sortierung nach Wikidata zu holen: Sortierung in Wikidata --Crazy1880 13:22, 31. Okt. 2014 (CET)

@Raymond: Der Anfang von Kategorie:Roman, Epik ist ein gutes Beispiel, die Titel sollen nach der numerischen Größe sortiert werden. Würden wir einfach auf uca umstellen, dann wären sie genau falsch herum. Natürlich kann man die Sortierschlüssel entsprechend anpassen, aber das muss man dann eben auch tun – und zwar in sicher einigen tausend Fällen. --Schnark 09:47, 3. Nov. 2014 (CET)

@Schnark: Verstehen, trotzdem greift dein Beispiel hier nicht, denn diese Artikel haben schon alle eine manuelle Sortierung, um unter #... zu erscheinen. — Raymond ^Disk. 10:01, 3. Nov. 2014 (CET)

@Raymond: Doch, mein Beispiel trifft hier zu. Ein manueller Sortierschlüssel ersetzt einen UCA-erzeugten Sortierschlüssel nicht (was auch äußerst schlecht wäre, da ein UCA-Sortierschlüssel ein unleserlicher Zeichensalat ist), der UCA-Sortierschlüssel wird ausgehend vom manuellen Sortierschlüssel (oder vom Seitennamen, falls ein solcher nicht existiert) berechnet, und behandelt die dort benutzten Doppelpunkte in einer Weise, dass die Sortierung (im Gegensatz zur Sortierung nach Codepunkten) nicht mehr stimmt. Schau dir die pt:Categoria:!Subpáginas de Schnark an, die beiden numerischen Seiten verwenden die selbe Doppelpunkt-Technik und sind eben falsch sortiert. --Schnark 10:11, 3. Nov. 2014 (CET)

@Schnark: Oha, da habe ich die Collation-Technik doch noch nicht so ganz verstanden gehabt :-( Danke für die Erklärung. — Raymond ^Disk. 10:22, 3. Nov. 2014 (CET)

Und was das Thema Wikidata angeht, kann ich nur dringend warnen, uns hier völlig von der Existenz einer funktionierenden Verbindung und Seitenzuordnung mit Wikidata abhängig zu machen.

• Die Regeln, nach denen Adelsprädikate und Präfixe und Bestandteile zugeordnet werden, sind schon je nach Muttersprache unterschiedlich, und werden womöglich sogar innerhalb der deutschsprachigen Wikis unterschiedlich gehandhabt. Dann sollen die cross-Wiki-MB kommen, oder die Wikidata-Admins werden zu Super-Admins, die über die Inhalte aller Projekte Entscheidungsbefugnis bekommen?
• Um einen Sortierschlüssel bearbeiten zu dürfen, soll man sich dann womöglich bei Wikidata einloggen müssen?
• Einen Editwar um den richtigen Schlüssel darf man dann mit einem gebrochen Englisch sprechenden Admin aus 10.000 km Entfernung austragen.

Unnötige und überflüssige Verkomplizierung. LG --PerfektesChaos 10:19, 3. Nov. 2014 (CET)

ACK. Es gibt schon kleine Unterschiede in der Sortierreihenfolge zwischen dem Österreichischen Wörterbuch und dem (privaten) Duden. Eine Auslagerung nach Wikidata verspricht in diesem Fall keinerlei Verbesserung. Wer systematisch mit den bestehenden Sortierungen arbeiten will, bleibt der Download des Files dumps.wikimedia.org/dewiki/latest/dewiki-latest-categorylinks.sql.gz

Im Zuge der Suche nach Alternativen für toten bevölkerungsstatistik-Links habe ich inzwischen eine erhebliche Menge Censusdaten angesammelt. Grundsätzlich scheint mir eine Einbringung dieser Daten über wikidata mittelfristig der sinnvollste Weg zu sein, denke aber dass dazu eine Menge an Vorarbeiten noch geleistet werden müssen, und vor allem braucht es ein Meinungsbild, welche Daten wir aus wikidata direkt übernehmen wollen und welche Daten wir aus Qualitätsgründen hier nicht haben wollen, und wie wir im (internationalen) Konfliktfall vorgehen, wenn die Datenqualität auf wikidata nachträglich verwässert wird. Frohes Schaffen — Boshomi ☕⌨☺  10:39, 5. Nov. 2014 (CET)

Upload auf Commons direkt von URLs

Hallo, den umseitig am 28. Oktober neu eingetragenen direkten Upload von vorher bestimmten Quellen auf Commons (Gerrit:168908) finde ich eine sehr gute Idee. Wie kann man denn diese Liste erweitern? Mir fielen da sofort Quellen wie bildindex.de ein. Und ist mit „Dateiprüfer“ C:Commons:Patrol bzw. c:Commons:Kontrollierer gemeint oder ist das ein noch höheres Recht? Freundliche Grüße, --emha ^d^^b 09:52, 5. Nov. 2014 (CET)

@Emha:. Die Quellen wurden bisher vor allem von Nutzer des GLAMwiki Toolsets vorgegeben. Das ist ein Massenuploadtool, bei dem die freigegebenen Institutionen auch Bescheid wissen. Ich würde für bildindex.de mal auf der Diskussionsseite vom GLAMwiki Toolset nachfragen. Und die Dateiprüfer sind ein eigenenständiges Recht, um die Aufgaben unter Commons:Lizenzprüfung zu erfüllen, siehe auch das Benutzerverzeichnis. — Raymond ^Disk. 10:10, 5. Nov. 2014 (CET)

Danke, ich hatte auf c:Commons:Requests for rights nachgesehen und da steht das Recht nicht… Ich werde mir das Toolset mal ansehen. --emha ^d^^b 10:21, 5. Nov. 2014 (CET)

indicator

Ich hatte das neue Tag mal auf labs eingebaut und an einem Artikel ausprobiert: Test. Sah erstmal gut aus, es gibt da aber noch Bug 72887, der irgendwelche Probleme mit normalen Wikilinks beinhaltet. Scheint aber bei der Lesenswert-Vorlage nicht relevant zu sein. Falls jemand das umbaut, sollten die Änderung an CSS und JS-Dateien erst 30 Tage später erfolgen, damit sicher ist, das der ParserCache auch leer ist und es nicht zu ungewollten Darstellungen von den alten Seiten kommt. Diese Möglichkeit der Bilderplatzierung war auch ein Wunsch im Rahmen der Technische Wünsche. Der Umherirrende 16:51, 3. Nov. 2014 (CET)

Danke für den Test, schaut doch gut aus. Leider fehlt auf dem Betawiki eine Koordinaten-Vorlage, um auch diese Variante auszuprobieren. Hat jemand Zeit und Lust, das auf dem Betawiki zu implementieren? Mir fehlt gerade die Zeit :-( — Raymond ^Disk. 10:17, 5. Nov. 2014 (CET)

• Es rennt nicht weg.
  • Das Feature wird heute Abend hier verfügbar sein, wir sind ein Jahrzehnt ohne ausgekommen, wir müssen es morgen früh noch nicht einbezogen haben.
• Entlinkt war im Oktober sehr eingespannt und hat im November hoffentlich mehr Zeit.
• Ein Gesamtkonzept für die optische Neuanordnung sollte vorher erarbeitet sein; womöglich auch irgendwie mit der interessierten Community diskutiert werden.
• Es können wie bisher auf einer Seite mehrere Dingse wirksam werden, die sich dann aber nicht mehr überlappen, sondern irgendwie nebeneinander erscheinen.
  • Mobil?
  • Info: Mehrere Elemente werden auf allen Seiten gleichmäßig und einheitlich in der alphabetischen Reihenfolge ihrer Bezeichner nebeneinander angeordnet. Diese müssen also geschickt gewählt werden, damit der gewünschte Effekt beim Zusammentreffen mehrerer Elemente eintritt.

VG --PerfektesChaos 11:04, 5. Nov. 2014 (CET)

→ WD:Technik/Skin/GUI/Top-Icons --PerfektesChaos 23:08, 5. Nov. 2014 (CET)

Die Leute von den Personendaten hatten vor kurzem auch darüber diskutiert, die Personensuche nach rechts oben zu verlegen, siehe Wikipedia_Diskussion:Normdaten#Position_der_Wikipedia-Personensuche. 85.212.49.20 00:29, 6. Nov. 2014 (CET)

Bug 64333

Der Bug gilt nur für Wikivoyage, oder? So les ich das zumindest auf bugzilla raus. 85.212.48.122 23:19, 7. Nov. 2014 (CET)

Nein, das ist ein generelles Problem --Taste1at (Diskussion) 00:16, 8. Nov. 2014 (CET)

Auf Wikivoyage ist es nur einfacher zu testen weil nicht so häufig sonstige neue Artikel erstellt oder gelöscht werden (und im Zweifelsfall vermutlich auch weil der Tester dort Admin ist). --mfb (Diskussion) 00:29, 8. Nov. 2014 (CET)

Ein Gadget fürs Teahouse

Hallo Alle, momentan wird an einer ersten kleinen Teilentwicklung für ein "Teahouse" in der deutschsprachigen WP gearbeitet: Anonyme Benutzer mit mindestens einem Edit und angemeldete Benutzer, die noch nicht autoconfirmed sind, bekommen einen Fragebutton in der Topbar angezeigt, können über ein Dialogfeld Fragen stellen und werden über ihre geposteten Fragen sowie die erfolgten Antworten benachrichtigt. Das kann jetzt getestet werden: Auf WP:teahouse gibt es alle Infos zum Projekt und zum aktuellen Stand, inklusive Links zur Testseite und zur Projektdoku auf MediaWiki. Bei Interesse: Feedback ist herzlich willkommen! Beste Grüße, Birgit Müller (WMDE) (Diskussion) 16:11, 8. Nov. 2014 (CET)

Fehler im Modern-Skin: Einrückungen der Legende auf der Beobachtungsliste

Auf der modern-Beobachtungsliste wird jede Zeile der dt/dd-Aufzählung in der Legendenbox weiter eingerückt. Findest jemand den Grund? Merlissimo 19:54, 14. Nov. 2014 (CET)

Ich dachte, das sei beabsichtigt. -- FriedhelmW (Diskussion) 20:01, 14. Nov. 2014 (CET)

Hallo, das lässt sich mit .mw-changeslist-legend dt { margin-bottom: 0; } umgehen. --Wiegels „…“ 20:56, 14. Nov. 2014 (CET)

Ich habe das als gerrit:173354 eingestellt. --Fomafix (Diskussion) 21:31, 14. Nov. 2014 (CET)

Die Änderung wurde schon angenommen und wird vorraussichtlich ab dem 26. November hier verfügbar sein (Für extra vorne aufschreiben fand ich sie zu klein/Auswirkungen zu gering, aber wenn jemand das dort vermerken möchte, kann er das gerne machen). Der Umherirrende 10:18, 15. Nov. 2014 (CET)

InputBox: preloadparams[]

Moin zusammen,

ist folgende Änderung für die Vorderseite von Bedeutung? InputBox: Add support for preloadparams[] . Ggfs. bitte vorne in die passende Rubrik für Version 1.25wmf8 eintragen. Danke. — Raymond ^Disk. 14:32, 16. Nov. 2014 (CET)

Die Preload-Parameter waren seinerzeit jedenfalls umseitig erwähnt. Werden die denn hier überhaupt benutzt? Gruß, IW — 15:21, 16. Nov. 2014 (CET)

Es sollte auf Hilfe:Eingabefelder dokumentiert werden, aber ankündigen würde ich es auch nicht, da der Anwendungsfall doch sehr speziell ist. Der Umherirrende 17:19, 17. Nov. 2014 (CET)

Neue Suche

Hallo zusammen; lässt sich die neue Suche irgendwie, ggf. unter den Einstellungen, wieder rückgängig machen? Ich finde die Sortierung der Ergebnisse nicht besonders gut. Jetzt scheint es jedenfalls nicht mehr nach Anzahl der Klicks sortiert werden. -- Jerchel 19:36, 17. Nov. 2014 (CET)

Oversight-Erweiterung

Moin, offenbar wurde die alte Oversight-Erweiterung deinstalliert. Das alte Spezial:Oversight-Logbuch existiert nicht mehr und die Erweiterung ist in Spezial:Version nicht mehr aufgeführt. Kennt jemand die Gründe und kann evtl. Details dazu geben? Ich würde gerne einen kurzen Abschnitt auf WP:Oversight dazu ergänzen. Danke! XenonX3 – (☎) 14:15, 10. Dez. 2014 (CET)

Nach Äonen des Wartens wurden die ehemaligen Oversight-Versionen in das RevDel/Suppression-System übernommen. Damit konnte dann die veraltete Oversight-Extension abgeschaltet werden. Siehe auch Phab:T62373. — Raymond ^Disk. 14:31, 10. Dez. 2014 (CET)

Ah, alles klar! Das ist natürlich die beste Lösung, danke für die Aufklärung. Ich schreib dann mal 2–3 Sätze zur Dokumentation. XenonX3 – (☎) 15:35, 10. Dez. 2014 (CET)

Beschleunigtes Speichern

Mit Version Version 1.25wmf12 haben wir seit heute den Spaß des beschleunigten Speicherns. Kann man das eventuell etwas nachbessern, sodass auch Zeitstempel in Unterschriften synchron zum Speicherzeitpunkt bleiben? Ich war gerade irritiert, dass die gespeicherte Uhrzeit 2 Minuten vor der in der (just vorherigen) Vorschau und 3 Minuten vor der in der Versionsgeschichte lag. -- 32X 17:23, 17. Dez. 2014 (CET)

Kann man das Feature eigentlich auch abstellen? Wenn ich eine 500 kb-Text hierhin copypaste, wird der Browser für mehrere Sekunden blockiert, sobald ich auf das Zusammenfassungsfeld klicke (Details: IE11, eigene Skripte könnten Einfluss haben). --Filzstift ✏ 09:22, 18. Dez. 2014 (CET)

@32X: Ich habe mal phab:T84843 für dich erstellt, du darfst gerne noch ergänzen (und jetzt warte ich mal mit dem Abspeichern, um den Bug selbst zu sehen).

@Filzstift: Prinzipiell müsste das gehen, suche in den entsprechenden Skripts, an welche Events das Ganze gebunden ist, und entferne sie per $.fn.off. --Schnark 09:29, 18. Dez. 2014 (CET)

Bei mir trat das Verhalten im vorherigen Edit nicht auf (mit nur einer Vorschau), neuer Versuch. --Schnark 09:34, 18. Dez. 2014 (CET)

Gut, ich habe eine Vermutung, warum es bei mir nicht auftritt, insofern @Filzstift:: Wenn du einen vernünftigen Browser und Benutzer:Schnark/js/syntaxhighlight verwendest, bist du das Feature vermutlich los. --Schnark 09:37, 18. Dez. 2014 (CET)

Vernünftige Browser... Ach... Es gibt schon gewisse Gründe, warum ich nicht einen "vernünftigen" Browser benutze. Ich bin schon gespannt, was mich im IE9 erwartet. --Filzstift ✏ 09:43, 18. Dez. 2014 (CET)

Übrigens, Syntaxhighlight kann ich leider nicht einsetzen, da damit ein Bearbeiten v.a. auf mobilen Geräten (Safari, iPad, iOS 8, WP in Dekstop-Ansicht) sowie auf älteren IE-Browsern kaum möglich ist. --Filzstift ✏ 09:46, 18. Dez. 2014 (CET)

Deswegen schrieb ich ja: vernünftiger Browser. Abgesehen davon: Anders als meine erste Vermutung behindert dieses Skript doch nicht das Stash-Edit-Feature. --Schnark 09:53, 18. Dez. 2014 (CET)

Ach so... Hab ich glatt falsch aufgefasst ;-) --Filzstift ✏ 09:56, 18. Dez. 2014 (CET)

Ungetestet, aber müsste das Feature ausschalten (allerdings auch eventuell weitere Funktionen, die schon ihre Event-Handler registriert haben):

if ($.inArray(mw.config.get('wgAction'), ['edit', 'submit']) > -1) {
 mw.loader.using('mediawiki.action.edit.stash', function () {
  $(function () {
   $('#wpTextbox1').off('change, keypress');
  });
 });
}

--Schnark 10:07, 18. Dez. 2014 (CET)

Gibt es eine Möglichkeit, das Feature (oder sonstige Skript) nur für bestimmte Browser abzustellen (z.B. dass auf dem iPad die meisten Skripte automatisch deaktiviert werden)? --Filzstift ✏ 10:18, 18. Dez. 2014 (CET)

Klar, mit Browser-Sniffing, entweder manuell, oder per jQuery.client. --Schnark 10:24, 18. Dez. 2014 (CET)

+ Eigenreklame zum Letzteren: Wikipedia:Technik/Skin/JS/jQuery #jquery.client LG --PerfektesChaos 11:24, 18. Dez. 2014 (CET)

Hab's ja nicht so mit js + jQuery und erst recht nicht mit dem MW-Objektmodell. Die Eigenreklame würde besser hinüberkommen, wenn auch noch ein Codebeispiel aufgeführt wäre :-). --Filzstift ✏ 11:51, 18. Dez. 2014 (CET)

Du würdest dich dann über eine überquellende Größe und totale Unübersichtlichkeit von WP:JS/JQ beschweren, wenn zu diesen vielen vielen Dingern auch noch alle möglichen Codebeispiele angegeben wären. Zumal die dann wieder alle gleich aussehen und völlig langweilig sind, wenn man einmal auf den Trichter gekommen war. WP:JS #Module auf dem Server pars pro toto. LG --PerfektesChaos 12:18, 18. Dez. 2014 (CET)

Bei Text mit Zeitvariablen oder REVISION*-Parserfunktionen ("revision-vary") macht das wohl weniger Sinn. Der Umherirrende 19:55, 19. Dez. 2014 (CET)

'vary-revision' wird schon berücksichtigt. 19:59. Der Umherirrende 19:59, 19. Dez. 2014 (CET)

Den Zeitunterschied gab es früher auch schon, aber in der Regel nicht so deutlich. Optionale Deaktivierbarkeit (ohne Nebenwirkungen) fände ich auch gut, obwohl ich momentan keinen für mich ausreichenden Grund habe sie zu nutzen. --nenntmichruhigip (Diskussion) 19:58, 18. Dez. 2014 (CET)

Den Zeitunterschied dürfte es früher nur gegeben haben, wenn der Seitentext zur 59 Sekunde gespeichert wurde und der Versionseintrag zur nächsten 00 Sekunde erstellt wurde. Mehrere Minuten dürfte es nicht gegeben haben. Der Umherirrende 19:55, 19. Dez. 2014 (CET)