Wikipedia Diskussion:Projektneuheiten/Archiv/2013

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/2013#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

Wann kommt 1.21.0 / was bedeutet wmf?

Huhu, ich sehe hier Versionsbezeichnungen wie "1.21wmf9". Was genau bedeutet das wmf. Ist es eine Art Beta-Versionsbezeichnung? Wann ist abzusehen, wann die dt. Wikipedia die finale Version 1.21 einsetzt (bzw. wann sie fertiggestellt wird)? --Nightfly | _Disk 10:21, 31. Jan. 2013 (CET)

wmf steht für Wikimedia Foundation. Es handelt sich hierbei um eine Art Zwischenversion, die auf allen Projekten der Wikimedia Foundation live ist. Gestern ist hierzulande die 1.21wmf8 live gegangen, in voraussichtlich 2 Wochen wird die 1.21wmf9 live gehen. Die Finale 1.21 wird für Frühjahr 2013 erwartet, siehe mw:MediaWiki 1.21. Natürlich kann sich auch jeder MediaWiki-Drittnutzer diese Zwischenversionen auf Git ziehen und damit arbeiten. — Raymond ^Disk. 11:17, 31. Jan. 2013 (CET)

GeoData

Umseitig habe ich diesen Blogbeitrag zu GeoData verlinkt. Weiß jemand, ob es bereits Bestrebungen gibt, {{#coordinate:....}} in unsere Geo-Vorlagen einzubauen? Ich finde es nämlich sehr spannend, wenn die Koordinaten in der Wikipedia-Datenbank gesammelt werden statt nur auf dem Toolserver. — Raymond ^Disk. 14:50, 1. Feb. 2013 (CET)

Schau mal unter Vorlage Diskussion:Coordinate#Parserfunktion. Es gibt noch Verbesserungsbedarf, entweder seitens der Vorlage oder seitens der Extension, gerade hinsichtlich anderer globes. Die list=geosearch habe ich auch nicht ans laufen bekommen. Der Umherirrende 15:10, 1. Feb. 2013 (CET)

Danke! — Raymond ^Disk. 15:32, 1. Feb. 2013 (CET)

Finger weg. Wenn das Ding neben WikiData steht, also eine seperate Datenbank mit eigenem Layout und ein eigenes Markup braucht, dann sollten wir das einfach boykottieren. Wir können unseren Nutzern nicht zumuten, noch ein neues Markup zu erlernen. Wenn und nur wenn es in den Visual Editor integriert ist und der vollkommen funktionsfähig ist, dann könnte sowas anders aussehen. Aber solange sollten wir uns und den Nutzern nicht antun. Grüße --h-stt !? 18:02, 1. Feb. 2013 (CET)

Neues Markup/Layout/Datenbank? Ich verstehe es so, dass man nur diesen Tag in die Vorlage einbauen muss und diese dann von Mediawiki automatisch in eine interne Datenbank übertragen werden, woraus dann andere schlaue Tools z.B. den mobile-Benutzern Artikel zu Orten in deren Nähe anbieten. Etwas Neues (zum lernen) für den normalen Autor erkenne ich da nicht. Aber natürlich ist es am Ende sinnvolle alle Koordinaten nur noch in WikiData zu speichern (wie alle anderen Daten auch).--se4598 / ? 19:08, 1. Feb. 2013 (CET)

Ja, es gibt eine neue Parserfunktion und eine neue Datenbanktabelle, aber das ist alles in {{Coordinate}} "versteckt", der normale Benutzer sieht davon nichts und muss auch nichts neues lernen, sofern er die Vorlage bereits bedienen kann. Die Parserfunktion wird wohl nur auf wenigen Seiten direkt stehen, ansonsten wird alles über Einbindungen realisiert. Mann muss sich also nichts merken und man sollte auch nichts davon mitbekommen. GeoData dient nur dazu, die vorhandenen Daten besser auffindbar zu machen. Mit WikiData lässt sich anschließend immer noch etwas anfangen. Der Umherirrende 19:29, 1. Feb. 2013 (CET)

Die Botschaft hör ich wohl ... lassen wir uns mal überraschen. Grüße --h-stt !? 17:37, 2. Feb. 2013 (CET)

Sortierschlüssel

Hallo, seit einem Softwareupdate soll es ja möglich sein, MediaWiki einige Umlaute selbst korrekt einsortieren zu lassen. Ich weiß nicht, ob das schon angesprochen wurde, aber wäre es nicht sinnvoll, für die de.WP ein paar solcher Sortierschlüssel zu definieren?

• á, à, ä -> a
• ò, ó, ö -> o
• ú, ù, ü -> u
• ß -> ss
• ì, í -> i
• é, è -> e

...

Dann könnte man sich sicher einige {{SORTIERUNG:}}s-Aufrufe am Ende sparen. IW 12:37, 4. Feb. 2013 (CET)

Steht schon (teilweise) in MediaWiki:Common.js. --Steef ³⁸⁹ 13:18, 4. Feb. 2013 (CET)

Das bezieht sich aber nur auf die Sortierung innerhalb von Tabellen. Inkowik bezieht sich aber auf die Seitensortierung. Dazu müsste ein Eintrag für mw:Manual:$wgCategoryCollation in der Konfigurationsdatei erstellt werden, vermutlich mit dem Wert uca-default. Vorher muss aber auf einem Testwiki ausführlich getestet werden, ob uca-default für die deutsche Sprache auch immer die richtige Sortierung liefert. Wenn ich mich recht erinnere, war das für Portugiesisch ein nicht unerheblicher Aufwand. Aber wünschenswert wäre es schon :-) — Raymond ^Disk. 13:33, 4. Feb. 2013 (CET)

Moin Moin zusammen, nur als Hinweis, vom Benutzer:Stefan Kühn gibt es Skript in der CheckWikipedia Syntax-Kontrolle (siehe hier). Wenn die Änderung kommt, dem Benutzer bitte Bescheid geben, dass diese ID deaktiviert werden kann. mfg --Crazy1880 15:05, 4. Feb. 2013 (CET)

Ich hatte auch schon versucht, das anzuregen, siehe Hilfe Diskussion:Kategorien/Archiv/2#Automatisch korrekte Kategorie-Sortierung und nachfolgender Abschnitt. Da sich aber die Mehrheit der Diskutanten lieber darüber stritt, ob man DEFAULTSORT oder SORTIERUNG schreiben sollte, verlief das im Sande. --Schnark 09:14, 5. Feb. 2013 (CET)

Kann man auch Bindestriche und Apostrophe zu keinem Zeichen und Schrägstriche zu einem Leerzeichen ändern lassen. Falls ja, dann entfallen noch mehr händische Änderungen in Zukunft. Bleiben nur noch die Lemma mit Ziffern und solche, die mit Artikeln beginnen. --BlueCücü (Diskussion) 09:40, 5. Feb. 2013 (CET)

Da es im Augenblick nur uca-default gibt, nicht. Prinzipiell mit ein bisschen Programmieraufwand sollte es rein theoretisch möglicherweise machbar sein, eventuell eine andere Collation Element Table zu verwenden, wobei dann noch das Problem geklärt werden müsste, was das erste Zeichen einer Seite ist, die mit einem Bindestrich etc. anfängt. --Schnark 09:57, 5. Feb. 2013 (CET)

Weil es gerade hier thematisiert: Eine Programmierung für Schwedisch ist ganz frisch in den MediaWiki-Code aufgenommen worden: Gerrit:44099. — Raymond ^Disk. 09:08, 6. Feb. 2013 (CET)

WikiMiniAtlas - neue 3D Gebaeude Modelle

Im WikiMiniAtlas werden jetzt in Browsern, die WebGL unterstuetzen, hardwarebeschleunigt dreidimensionale Gebaeudemodelle angezeigt. In browsern wie zwar das Canvas-Element aber kein WebGL unterstuetzen (neuere IE) wird die alte Gittermodell-Ansicht angezeigt. Browser ohne Canvas-Unterstuetzung (aeltere IE) gehen leider leer aus. --Dschwen (Diskussion) 23:46, 8. Feb. 2013 (CET)

Tourdingsbums

Das ist ja richtig toll programmiert. Es verbreitet sich wie eine Seuche über alle offenen Wikipedia-Tabs, und was noch viel schlimmer ist, die Popups sind teilweise außerhalb des Bildschirms sodass man sie gar nicht lesen kann. Wer ist daran Schuld? -- Liliana • 18:54, 8. Feb. 2013 (CET)

Dein veralteter Browser? --Nightfly | _Disk 20:22, 8. Feb. 2013 (CET)

Popups außerhalb des Bildschirms kann ich bestätigen. Und nein, Firefox 18.0.2 ist nicht veraltet. -- Chaddy · D – DÜP – 22:44, 8. Feb. 2013 (CET)

Geht es um die "Guided Tour"? (en:Wikipedia:Village pump (technical)#New feature: guided tours, en:Help:Guided tours, mw:Guided tours, WMF Blog: Adding guided tours to Wikipedia, en:Wikipedia:Editor_engagement_experiments#List_of_experiments) Ist das nicht nur auf en-wiki? --Atlasowa (Diskussion) 16:24, 9. Feb. 2013 (CET)

Siehe umseitig, gibts jetzt auch hier. Hier gibts eine Testtour. --APPER\^☺☹ 16:39, 9. Feb. 2013 (CET)

Siehe auch WP:FzW#New feature: guided tours Der Umherirrende 16:40, 9. Feb. 2013 (CET)

Ich finde solche Touren für Neulinge sehr gut, aber natürlich sollten dann die Probleme gelöst sein. Ich kann weder in Opera noch in Firefox irgendwelche Probleme bemerken, alles wird korrekt dargestellt. @Liliana: Welchen Browser verwendest du denn und welches Skin verwendest du? --APPER\^☺☹ 16:44, 9. Feb. 2013 (CET)

Ich hab es mit Opera 12.14 und dem Monobook-Skin getestet. -- Liliana • 16:47, 9. Feb. 2013 (CET)

Okay, mit Monobook kann ich das Problem nachvollziehen. Die Erklärung des Suchfeldes ist breiter als das Suchfeld und wird nach links erweitert (da in Vector das Suchfeld rechts ist). Bei Monobook ist das Suchfeld links und die Erweiterung nach links lässt dies nach links rausstehen. Ist natürlich schwierig, eine Tour zu gestalten, wenn bei jedem die Elemente woanders sind... evtl. kann man vorher aufs Skin testen, wobei Neulinge wohl zu 99,9% Vector als Skin haben, aber einfach eine Tour anbieten ohne das zu checken, halte ich für nicht so gut. Dass die Tour in jedem Tab kommt ist tatsächlich nervig und auch unnötig... --APPER\^☺☹ 17:08, 9. Feb. 2013 (CET) Ergänzung: Ich habe es nur einmal beobachten können, dass die Tour auch bei anderen Tabs kommt, lässt sich bei mir grad nicht mehr reproduzieren. --APPER\^☺☹ 17:10, 9. Feb. 2013 (CET)

Auch wenn Vector der Standardskin ist, dürfte Monobook auch weiterhin breite Verwendung finden, weshalb man diese Tour schon wenigstens auch auf diesen Skin anpassen sollte. Idealerweise sollten aber natürlich alle angebotenen Skins auch einwandfrei funktionieren, oder man wirft sie ganz raus. Einen Skin anbieten, der dann nicht funktioniert, ist nämlich leicht dämlich... -- Chaddy · D – DÜP – 17:54, 9. Feb. 2013 (CET)

Monobook wird fast ausschließlich von erfahrenen Autoren verwendet, die mit diesem Skin groß geworden sind oder deren Javascript darauf beruht (wie in meinem Fall). Das ist eine komplett andere Zielgruppe als die Neulinge die angesprochen werden sollen. Man könnte allerdings einen Hinweis wie "diese Funktion ist mit deinem Skin „$1“ nicht verfügbar" o.ä. einbauen. --Tobias D B 19:32, 13. Feb. 2013 (CET)

Hat es eigentlich jemand geschafft eine eigene Tour zu erstellen? Ich habe mich auf MediaWiki:Guidedtour-tour-test2.js bemüht; wenn ich Seiten mit ?tour=test2 aufrufe passiert aber nix (trotz lokal und serverseitig geleertem Cache). Was mach ich falsch? --Tobias D B 23:55, 13. Feb. 2013 (CET)

Mindestwert für „Anzahl der Beobachter der Seite“ festlegen (Wert gilt für alle inkl. IPs)

Kontext: Vorschau auf Version 1.21wmf7:

• (Softwareneuheit) Auf der Seiteninformation findet sich die Angabe, wieviele Benutzer die Seiten beobachten, nur für Administratoren. Mit einer neuen Systemvariable kann jedes Wiki individuell einstellen lassen, ab welchem Grenzwert diese Angabe allen Benutzern angezeigt wird. Dazu benötigen die Systemadministratoren aber einen Eintrag im Bugzilla, der auf einen lokalen Konsens verlinkt. Ein erster Diskussionsansatz wäre sicherlich der Grenzwert von 30, mit dem das Toolserver-Tool „Watcher“ arbeitet. Der Vorteil einer systemseitigen Lösung wäre, dass das Projekt ein kleines Stück weit unabhängiger vom Toolserver würde (Bug 39957, Gerrit:27134).

Seit dem 14. Januar ist die Funktion „Anzahl der Beobachter der Seite“ in den Seiteninformationen mit dem Mindestwert 30 auf der deutschsprachigen Wikipedia aktiv.

Siehe "In the coming weeks, I'll be deprecating the tools:~mzmcbride/watcher/|watcher tool", -jkb- 18:11, 18. Jan. 2013 (CET)

Diskussionsabschnitt

Ich wollte mal fragen, wie man das am besten macht? Raymond, würde eine Liste mit Unterschriften auf dieser Seite reichen? Ich fang einfach mal an. Ein MB kommt dir da etwas zu groß für vor. Ich schlage vor, die 30 zu behalten, es scheint ja damit keine Problem zu geben, da aktuell auch für jeden Benutzer die Zahl über 30 erreichbar ist. Nur wenn man die genaue Zahl unter 30 wissen möchte, muss man hier Admin sein oder noch beim Tool angemeldet sein, wobei sich die Frage stellt, wie lange das Tool noch aktiv bleiben wird. Der Umherirrende 19:47, 3. Jan. 2013 (CET)

Ich schlage einen deutlich niedrigeren Wert vor. Ob ein Artikel von 30 oder 38 Benutzern beobachtet wird, ist vollkommen gleichgültig. Viel interessanter ist es, zu wissen, ob ich der einzige Beobachter bin, ob es derer drei oder vielleicht sogar acht gibt, oder am Ende doch kein einziger. Als Sichter sehe ich den genauen Wert ohnehin auf Spezial:Seiten mit ungesichteten Versionen, aber nur, wenn der Artikel zufällig eh gerade auf jener Liste steht. Die gesichteten Versionen sollten dann auch in allen relevanten Namensräumen verhindern, dass sich jemand erfolgreich gezielt unbeobachtete Seiten sucht und vandaliert. --YMS (Diskussion) 20:28, 3. Jan. 2013 (CET)

Habe mal für eine Konsens eine Kontraoption hinzugefügt. Falls so gültig, sollte es aber auch auf Vorlage:Beteiligen verlinkt werden--se4598 / ? 20:31, 3. Jan. 2013 (CET)

Der Sinn des Schwellenwerts (gegen Außenstehende, also Nicht-Sichter) ist, sie im Unklaren zu lassen, wie viele Sichter es gibt und wie groß das Risiko ist, entdeckt zu werden. Gibt es eine einstellige Zahl oder keinen, ist die Chance gut, dass mein unauffälliger Vandalismus nach Passieren der RCler nicht von inhaltlichem Fachpersonal entdeckt wird. Mit Glück wird es en passant mal mitgesichtet. Die paar Beobachter machen vielleicht grad Urlaub oder Wikipause. --PerfektesChaos 20:41, 3. Jan. 2013 (CET)

Wenn man 0 haben möchte, kann man das Recht "unwatchedpages" allen geben und damit auch Spezial:Unbeobachtete Seiten freigeben. Es wird wohl seinen Grund haben, warum das nicht so ist. Die Anzeige im Rahmen der gesichteten Version ist Technisch nicht das gleiche, weil sie etwas anders ermittelt wird (beispielsweise werden nur aktive Benutzer gezählt oder so).

Danke Se4598, für die Ergänzungen. Der Umherirrende 21:04, 3. Jan. 2013 (CET)

Aktuell ist ja der Mindestwert für Admins 0, für alle andern 30. Man könnte ggf. die Sichter von der zweiten in die erste Gruppe „befördern“. Für alle Nicht-Sichter würde es bei 30 bleiben. --Leyo 16:23, 4. Jan. 2013 (CET)

Ich beantworte mir meine Frage selbst. ;-) Die 30 war 2009 scheinbar der kleinste mögliche Kompromiss, gegen den niemand mehr etwas hatte. Der Schwellwert muss recht hoch sein, weil es sonst viel zu leicht möglich ist, gezielt Artikel zu vandalieren, die kaum jemand beobachtet. Allerdings erscheint mir die Zahl befremdlich, gewohnt (bspw. auch hier in Spezial:Beiträge) ist man eher eine 25 oder 20. --TMg 21:43, 3. Jan. 2013 (CET)

Ich sehe das eher wie bei der Diskussion um die Spezialseite Spezial:Unbeobachtete Seiten: Die Zahl ist nicht weiter wichtig, wenn es um Vandalismus geht. Dank der gesichteten Versionen weiß ich, dass es Seiten gibt, die von 30 Leuten beobachtet werden und ein Linkfix auch nach 20 Tagen noch ungesichtet ist, es jedoch auch Seiten gibt, die von niemandem beobachtet werden und recht schnell gesichtet bzw. zurückgesetzt werden. Letztlich sollte es egal sein, ob eine Seite mit 0 Beobachtern bei einem Fachportal auf einer Liste unter ständiger Beobachtung steht, oder ob unter den 30 Beobachtern neben den 5 verstorbenen und 5 inaktiven Benutzern noch 20 gesperrte Sockenpuppen den Artikel auf der Beobachtungsliste haben. Mein Fazit: Schwellwert 0 und auch die genannte Spezialseite per Benutzerrecht für alle freigeben, damit der Mythos darum ein Ende hat. Will man einen Artikel gezielt vandalieren, gibt es deutlich bessere Wege als die Suche nach 0 Beobachtern. --32X → Autorenngilde № 1 01:53, 4. Jan. 2013 (CET)

@Umherirrender: Danke für deine Initiative hier. Zu deiner Frage würde eine Liste mit Unterschriften auf dieser Seite reichen?: Ich denke ja. — Raymond ^Disk. 00:11, 4. Jan. 2013 (CET)

Wie soll das hier ausgewertet werden: Der Wert, der mindestens so hoch ist wie 50%/55%/66,6% aller abgegebenen Stimmen? Vielleicht Median oder Arithmetisches Mittel?--se4598 / ? 00:16, 4. Jan. 2013 (CET)

Ich denke, in diesem „Hinterzimmer“ hier ;-) werden wir keinesfalls unter den „Status quo“ von 30 gehen können. Die Antworten werden aber zeigen, ob es sich evtl. lohnt, ein ordentliches Meinungsbild dazu zu machen. --TMg 00:52, 4. Jan. 2013 (CET)

Zu meiner Zeit hat man ganz pragmatisch auf FzW einen Abschnitt aufgemacht, kurz dargelegt, worum es geht, und abstimmen lassen: Wikipedia:Fragen zur Wikipedia/Archiv/2008/Woche 01#Kleines Meinungsbild: Einrichtung von »WP:« als Alias des Wikipedia-Namensraumes (erl., ist umgesetzt). Auch damals ging der Trend schon zum Meinungsbild und auch damals frug ich mich häufig genug: Bürokratie – warum? --32X → Autorenngilde № 1 02:00, 4. Jan. 2013 (CET)

Wenn du das Vandalismusproblem, das zwangsläufig entsteht, sobald sich jeder die unbeobachteten Artikel raussuchen kann, argumentativ ausräumen kannst, können wir das gern auf einem kürzeren Weg regeln. Einen Gedanken werfe ich mal in die Runde: Ein Missbrauchsfilter, der Edits auf unbeobachteten Seiten nur für angemeldete Benutzer mit einer Mindest-Editzahl zulässt. (Ist nicht zu Ende gedacht, nur zum Anstoßen der Diskussion.) --TMg 02:12, 4. Jan. 2013 (CET)

(BK) Ok, ich interpretiere das mal so: solange sich keine bedeutende Anzahl bei Kontra einträgt, können wir einfach den "Status quo"-Wert von 30 übernehmen. Falls welche dann noch einen niedrigeren haben möchten, kann ja von denen ein Meinungsbild eröffnet werden.--se4598 / ? 02:15, 4. Jan. 2013 (CET)

@TMg: Das würde aber dem Prinzip von Wikipedia entgegenlaufen. Außerdem werden ja gerade unbeobachtete Seiten wohl nicht von einen angemeldeten Benutzer gepflegt, da ist eine helfende IP doch gerade das Wichtige an dem offenen Editiersystem. Eine eventuelle Sammelseite für die verbotenen Edits würde auch nicht mehr bringen als die bisherigen gesichteten Versionen. Soweit meine Meinung--se4598 / ? 02:23, 4. Jan. 2013 (CET)

Teil 1: Ja, so meinte ich das. Teil 2: Ich will um Himmels Willen keinen solchen Filter, das sollte wirklich nur der Diskussion dienen. Ich habe Zweifel daran, ob der Sichtungsstatus allein ausreicht, um das entstehende Missbrauchspotential zu kompensieren. Ich gehe gern bis 10 runter, aber bei allem darunter habe ich Bedenken, ob uns die Beschäftigung damit nicht in der Summe mehr Zeit wegfrisst als es uns hilft. --TMg 02:34, 4. Jan. 2013 (CET)

Arithmetisches Mittel jedenfalls bestimmt nicht, sonst entscheidet Leif Czerny mit seinem "Unendlich" allein. --Grip99 02:38, 7. Jan. 2013 (CET)

Möglicherweise habe ich dazu etwas nicht mitbekommen, aber ein Problem, das (auch) hier in der Diskussion deutlich wird, ist der Wert dieser Zahl. Wirklich wertvoll ist die Zahl der aktiven (!) Beobachter. Wie man aktiv definiert, ist dabei sicher zweitrangig. Wenn es irgendwo schon den Status "aktiver Benutzer" gibt, sollte man den nehmen. Je älter WP wird, desto mehr inaktive Benutzer gibt es. Und die Zahl an Beobachtern wird immer mehr an Aussagekraft verlieren, solange die mitgezählt werden. Anka ☺☻Wau! 09:42, 4. Jan. 2013 (CET)

Gibt es, siehe Spezial:Aktive Benutzer. Wird u.a. auch verwendet, um auf Spezial:Seiten mit ungesichteten Versionen die Anzahl der aktiven Beobachter anzuzeigen (während die InfoAction wohl tatsächlich einfach alle Beobachter zählt). Da sehe ich wie gesagt längst, ob ein Artikel tatsächlich unbeobachtet ist (aber es ist auch problemlos möglich, dort etliche Tage alte Tastaturtests in Artikeln mit einem Dutzend aktiven Beobachtern zu finden (Beispiel)). --YMS (Diskussion) 10:16, 4. Jan. 2013 (CET)

Die ganze Diskussion ist in der Tat weitestgehend sinnfrei, wenn sowieso nicht berücksichtigt wird, ob die Beobachter aktiv sind. Dann ist auch egal, ob man 5 oder 50 als Schwellwert wählt, weil das nichts aussagt. Nur die 0 sagt definitiv etwas aus. Deswegen möchte ich mich noch einmal ganz deutlich dafür aussprechen, mindestens die beiden Werte 0 und 1 ununterscheidbar anzuzeigen. Für die „guten“ Benutzer spielt das keine Rolle. Potentielle „böse“ Benutzer können sich aber nie sicher sein, ob ein Artikel nicht vielleicht doch beobachtet wird. --TMg 13:34, 4. Jan. 2013 (CET)

Das Vandalismus-Argument ist inzwischen doch ohnehin längst keines mehr. Der Leser sieht Änderungen ohnehin erst, wenn der Artikel gesichtet wurde... Sinnlose Panikmache also. -- Chaddy · D – DÜP – 13:59, 4. Jan. 2013 (CET)

Das stört doch den Vandalen nicht, der darauf aus ist, uns unsere Zeit zu stehlen. Auf der anderen Seite: Welchen Nutzen hat es, zwischen Artikeln mit 0 und 1 Beobachter unterscheiden zu können? --TMg 14:16, 4. Jan. 2013 (CET)

Beim Sichten wird häufig nicht der Inhalt geprüft, sondern nur ob offensichtlicher Vandalismus vorhanden war. Etwas subtileren Vandalismus, Werbung und POV, gut gemachte Fakes rutschen gerne durch die geschichteten Versionen durch. Die Wahrscheinlichkeit, dass so etwas im Artikel bleibt, ist bei komplett unbeobachteten Seiten deutlich höher. --Engie 14:26, 4. Jan. 2013 (CET)

Weils grad passt: Man nehme diese Änderung, die schon gesichtet war. Sie ist nur aufgrund weiterer IP-Edits der Eingangskontrolle als Vandalismus aufgefallen. Wenn die IP aufgehört hätte und der Artikel unbeobachtet ist, wäre die PS-Zahl wohl für sehr lange Zeit auf einem falschen Wert geblieben. Bei beobachteten Artikel ist die Wahrscheinlichkeit deutlich geringer, da vielleicht ein Kenner/Interessent sich den Edit inhaltlich nochmals genauer anschaut. --Engie 14:43, 4. Jan. 2013 (CET)

Ich glaub, man müsste mal wegen dem oben genannten Nachhaken. Es wäre tatsächlich sinnvoll, dieses Feature so zu implementieren, dass die aktiven Benutzer gezählt werden. Längst gesperrte Sockenpuppen (möglicherweise des immer selben Vandalen im immer selben Artikel) können sonst das Bild hoffnungslos verfälschen. --PaterMcFly Diskussion ^Beiträge 17:38, 4. Jan. 2013 (CET)

Um Vandalen abzuhalten sollte nicht jeder den Wert nicht sehen. Aber Sichter (editors) sollten ohne einen Schwellenwert das unwatchedpages-Recht bekommen.--Falkmart (Diskussion) 13:59, 5. Jan. 2013 (CET)

Da ja sehr viele (undifferenziert bzw. ohne Kommentar) für Sichtbarmachung des Wertes für alle (auch IPs) votieren, sollte meiner Meinung nach nach diese Umfrage maximal (d.h. nichts darunter) der bisherigen Wert von 30 umgesetzt werden. Für einen anderen Wert sollte es ein Meinungsbild mit Diskussion um Pro/Kontra geben. Insbesondere sollten die Alternativen geprüft und einbezogen werden:

• separates bzw. kein Limit für aktive Sichter (oder andere Benutzergruppe)
• Kalkulation der Beobachter mit diesem (oder neuen) Schwellenwert per Kriterium "aktiver Benutzer" (Spezial:Seiten mit ungesichteten Versionen)

--se4598 / ? 21:19, 6. Jan. 2013 (CET) PS: Vandalismus ist nicht gleich Vandalismus, wer sich Mühe macht, kann sich einen unbeobachteten Artikel aussuchen (gibt bestimmt genug via Spezial:Zufällige Seite) und dann einen grammatisch einwandfreien Satz formulieren. Wer von den Nachsichtern hat zufällig genug Fachwissen, um das zu identifizieren? Mit der Zeit findet sich wer, der doch sichtet (per AGF).

Hallo se4598. Probleme an Deiner Argumentation:

1. Seit wann ist eine Stimme formal mehr wert, wenn sie eine Begründung enthält?
2. Sowohl bei der 30er-Option als auch bei der 0-Option sind etwa die Hälfte der Stimmen ohne expliziten Kommentar abgegeben worden.
3. Der höchste Wert, der in der Umfrage vorkommt, ist "unendlich". Also überhaupt keine Angabe für niemanden.
4. Sichten dient nicht zum Abfangen von subtilen inhaltlichen Falschaussagen, sondern als Filter gegen klassischen Vandalismus.

-<)kmk(>- (Diskussion) 21:51, 6. Jan. 2013 (CET)

Ich habe nicht behauptet, dass welche mit Begründung mehr wert sind. Leider lässt sich ohne Kommentar nicht feststellen, was deren Kenntnisstand bzw. wirkliches Ziel ist. Ich habe nur das Gefühl, dass sich einige nicht klar sind, in welchem Umfang die Änderung ist, insbesondere da ja Kritikpunkte/Kontrapunkte zum Teil erst als Kommentar zur Stimme sichtbar werden werden. Zudem werden ja auch einige "0"-Stimmen auf Sichter oder Zählweise "aktive Benutzer" eingeschränkt. "Unendlich": Da hat sich bisher nur einer von insgesamt 86 eingetragen. Allgemeiner Konsens besteht daher anscheinend für einen Wert, der bei 30 oder weniger liegt. Es geht mir nicht ums sichten, mir geht es um Wahrscheinlichkeiten. Wofür argumentiere ich denn? Ich fordere nur, dass für jeden geringeren Wert als derzeit praktisch vorhanden, ein Meinungsbild gestartet wird.--se4598 / ? 22:46, 6. Jan. 2013 (CET) PS: Das Ganze ist hier als Unterschriftenliste für den bisherigen Wert gestartet[1].

„Allgemeiner Konsens besteht daher anscheinend für einen Wert, der bei 30 oder weniger liegt“ - diese Interpretation ist nicht zulässig, da würde nämlich bedeuten, dass alle, die für 0 stimmen, auch 30 akzeptieren würden. Das ist aber nicht der Fall. -- Chaddy · D – DÜP – 23:34, 6. Jan. 2013 (CET)

„…"Status quo"-Wert von 30 übernehmen. Falls welche dann noch einen niedrigeren haben möchten, kann ja von denen ein Meinungsbild eröffnet werden.“ (Eigenzitat von weiter oben). Bitte erläutere mir, warum deinen Interpretationsweise, jemand, der 0 fordert, 30 schlechter/unaktzeptabler findet als keine Anzeige (die ja weiterhin durch das Tool praktisch möglich ist)?--se4598 / ? 23:44, 6. Jan. 2013 (CET)

was deren Kenntnisstand bzw. wirkliches Ziel ist. Diese Umfrage ist einerseits unterwandert von Vandalen-Schläfern und Troll-Infiltreuren. Und anderseits von Leuten denen es an Kenntnisstand mangelt. Welcher vernünftige Wikipedianer würde schon für keinen Mindestwert stimmen? Insofern sind die kreativen Interpretationen des Zwischenergebnisses verständlich. --Tets 01:17, 7. Jan. 2013 (CET)

Ironie im Beitrag? (Ernstgemeinte Frage, kann ich nicht entscheiden). Einzig und allein wollte ich [2] bejahen. Ihr könnt meine versuchte Zusammenfassung gerne woanders Wort für Wort zerreißen. Mir kommt es auf die Intention an, dass ich ein MB für notwendig und alles andere unter 30 für hier nicht entscheidbar halte. Egal, EOD von meiner Seite. Für sachdienliche Diskussionen (wie weiter verfahren wird), bin ich dennoch hier zu haben.--se4598 / ? 02:08, 7. Jan. 2013 (CET) Wollen mich heute alle misinterpretieren?

war nicht bös gemeint. sry .. die umfrage ist schon prominent verlinkt, es haben sich ja auch schon einige leute beteiligt .. und ob man für jede kleinigkeit jetzt immer so einen bürokratischen zirkus veranstalten muss, weiß ich auch nicht .. --Tets 12:23, 7. Jan. 2013 (CET)

Ich habe die Abschnittsüberschrift geändert, damit klar wird, dass der Wert für all gilt. Wie haben mehrere Abstimmungen mit 0 für Sichter und 30 für andere. Diese inhaltlich identischen Wünsche finden sich aber in mehreren Abstimmungsabschnitten - viele davon bei "Kein Mindestwert", was falsch ist. Bei der Auswertung muss man schauen, ob man die nicht umsortieren muss. Merlissimo 14:36, 8. Jan. 2013 (CET)

Eine Auswertung aufgrund der verschiedenen Kommentare sieht sehr schwierig aus. Vielleicht muss dieser "Umfrage" doch ein Meinungsbild folgen, um zu klären, ob das Recht "unwatchedpages" für die Option "Kein Mindestwert" (+ Spezialseite) oder die neue Variable herhalten muss oder es doch ganz anders aussehen soll. Der Umherirrende 17:41, 8. Jan. 2013 (CET)

Ich hätte einen Vorschlag. Für alle (wirklich alle) sichtbar ist die Zahl der Beobachter, allerdings nur bis zu einer Mindestanzahl. Nutzer die ein gewisses Kriterium erfüllen sehen auch bei geringeren Zahlen die genaue Beobachterzahl. Als Kriterium könnte man die allgemeine Stimmberechtigung verwenden. -- Vuxi (Diskussion) 16:46, 8. Jan. 2013 (CET)

So funktioniert das ganze, nur das man allgemeine Stimmberechtigung aktuell mit MediaWiki nicht abgefragt werden kann. Es wäre höchstens (technisch) möglich für Sichter die Zahl anzuzeigen und die Spezialseite freizugeben. Alles was dann nicht Sichter ist, bekommt die Zahl nur, wenn der Mindestwert erfüllt ist. Der Umherirrende 17:41, 8. Jan. 2013 (CET)

Passt auch. Sichter zu sein erfordert ja auch eine längere Mitarbeit. -- Vuxi (Diskussion) 18:27, 8. Jan. 2013 (CET)

 Info: Ohne dem Ergebnis dieser Diskussion vorzugreifen, habe ich den Standardwert von 30 mit Gerrit:42779 in die WMF-Serverkonfiguration eingespielt. Dieser Wert muss noch reviewed werden, bevor er live geht. Davon profitieren dann alle Projekte, auch wenn sie keine lokale Diskussion führen. Sollte diese Diskussion hier zu einem niedrigeren Wert führen, kann dies sehr leicht umgesetzt werden. Auch ein höherer Wert (der hier wohl nicht zur Diskussion steht) ist möglich. — Raymond ^Disk. 17:37, 8. Jan. 2013 (CET)

Halte ich erstmal für sinnvoll, ein klärendes Meinungsbild kann ja noch durchgeführt werden. Wenn man 30 für alle freischaltet, dann wird die (generelle) Funktion des Tools "Watchers" abgebildet und somit die Abhängigkeit vom Toolserver verringert. Wer hier kein Admin ist und den genauen Wert haben möchte, kann in der Zwischenzeit immer noch das Tool benutzen (bis es irgendwann vermutlich abgeschaltet wird), wie es jetzt auch genutzt wird, also keine Verschlechterung der Situation für diese Benutzer. Der Umherirrende 17:41, 8. Jan. 2013 (CET)

Wow, das war ein megaschnelles Review. Ist soeben live geschaltet worden. — Raymond ^Disk. 20:30, 8. Jan. 2013 (CET)

PS: Da ich gerade beim Testen selber drauf reingefallen bin: Auswirkungen hat das erst, sobald die deutschsprachige Wikipedia (morgen?) auf Version 1.21wmf7 upgedatet wird. — Raymond ^Disk. 20:36, 8. Jan. 2013 (CET)

PPS: Getestet werden kann die Funktionalität schon auf Commons. — Raymond ^Disk. 20:37, 8. Jan. 2013 (CET)

Ja, ich war hier etwas vorschnell mit meiner Frage, weil es auch bis zum 14. Januar erledigt werden sollte, wenn es hier live geht. Der Umherirrende 20:41, 8. Jan. 2013 (CET)

Was meint ihr, ob diese Diskussion hier schon ausreicht, um die Funktion (plus die Spezialseite) für alle Sichter unbegrenzt freizugeben? Ich habe fast den Eindruck, dass darin Einigkeit besteht, aber das ist wie oben schon diskutiert schwer auszuzählen. Dann würde es nur noch um zwei Fragen gehen: Ob IPs und Benutzer ohne Sichterrechte auch Zahlen kleiner 30 sehen dürfen. Und ob man die Funktion so umbauen kann, dass nur aktive Benutzer gezählt werden. --TMg 01:16, 9. Jan. 2013 (CET)

Die Option "ohne Schwelle" wird von einer 2/3-Mehrheit (momentan 78 von 117) bevorzugt, obwohl die mit dem Thema befassten Experten sich im Vorfeld eindeutig für 20, oder 30 ausgesprochen haben. Außerdem äußern sich nur zwei der für "Null" stimmenden so, dass sie dafür zwischen Sichtern und Nicht-Sichtern Unterschiede machen würden. Natürlich kann man dafür noch ein Meinungsbild mit wasserdicht formulierter Fragestellung abhalten. Ich halte es aber für schwer vorstellbar, dass bei so einem Meinungsbild ein deutlich abweichendes Ergebnis liefert.---<)kmk(>- (Diskussion) 02:25, 9. Jan. 2013 (CET)

Welche 2? Wenn mir mein Versuch, das hier voran zu bringen, gleich wieder aus der Hand geschlagen wird, sollten wir es vielleicht wirklich bleiben lassen und das per vernünftig vorbereitetem Meinungsbild klären, in dem sich nicht nach 100 Stimmen nochmal die Fragestellung ändert. --TMg 03:37, 9. Jan. 2013 (CET)

Da dürften aber nur Stimmberechtigte abstimmen. Hier können sich auch IP-Benutzer und Socken eintragen, ds ist bei Umfragen möglich. Man soll sich nur nicht doppelt eintragen. Jedenfalls gibt es hier keine SB. Und bei der Option für 30 seh ich ne Menge auf jeden Fall Stimmberechtigte im Gegensatz zur 0-Option. Ist ja auch kein Wunder. Aber der Nachteil, dass jeder Nichtwikipedianer gezielt mittels eines Klicks auf Seiteninformationen, prominent in der Werkzeugleiste angeboten, sich unbeobachtete Artikel raussuchen und verdeckten Vandalismus, der nicht direkt ins Auge fällt, dort gezielt platzieren kann, ist doch zu groß, um das trotz deutlichen Widerspruchs in der Umfrage und ohne MB einfach einzuführen. Nee, wer das ganz freischalten will, der muss schon ein MB machen. Sonst sollte man zukünftig solche Umfragen besser gleich als ungültig abbrechen, wenn sie anschließend für weitere Änderungen ohne Konsens als MB-Ersatz hergenommen werden.

Und was der Vorteil dabei sein soll, dass jeder Vandale und Neuling sofort sehen kann, welche Artikel und Seiten völlig unbeobachtet sind, hat bisher auch noch niemand erklären können. Solche Argumente wären bei einem MB zumindest Standard, damit man sich dazu überhaupt gescheit eine Meinung bilden kann. Den Meisten, die sich eingetragen haben, dürfte es mehr darum gehen, dass sie selbst nicht die Zahl einsehen können und nicht die Vandalen, IP-Benutzer und Neulinge.

Und ob man hier einen Konsens herauslesen kann, dass die Funktion nur für Sichter ganz freigeschaltet werden kann, müsste man diejenigen fragen, die sich in der Umfrage ohne entsprechenden Kommentar für 30 oder etwas weniger eingetragen haben (eine Abstimmung ist das hier eh nicht). Zumindest lese ich bisher keine Argumente, die dagegen sprächen. Es könnten sich sicher auch findigere Vandalen gezielt die SB und die Sichterrechte mit Kleinstedits verschaffen und dann in unbeobachtete(re)n Artikeln Unsinn treiben. Das würde aber sicher auch mal auffallen und die Arbeit wäre dann dahin. Also würde sich das nicht sonderlich lohnen. Und POV-Pusher sind ja meistens eher an den vielbeobachteten Artikeln interessiert, dafür ist diese Methode nicht sonderlich hilfreich. Insofern kann ich keine guten Gründe finden, die gegen das unwatchedpages-Recht für Sichter sprächen. Zumal man durch gezieltes Entsichten und Sichten auch leicht die Zahl der aktiven Beobachter rausfinden kann, die sogar noch aussagekräftiger ist. Und das auch auf den letzten ungesichteten Seiten angezeigt bekommt. --Geitost 03:38, 9. Jan. 2013 (CET)

Argumente bei 0 wie "Vielleicht werden dann unbeobachtete Seiten verstärkt in Beobachtungslisten aufgenommen", wo doch IP-Benutzer gar keine Bo haben, sprechen jedenfalls auch nicht für eine Freigabe für IP-Benutzer. Und es gibt bei 0 jede Menge Benutzer, die etwas von Sichtern schreiben, nicht nur 2. --Geitost 03:44, 9. Jan. 2013 (CET)

Ich bin in der Sache noch unentschieden, weil ich mich hier noch etwas "argumentativ unterversorgt" fühle. Ich sympathisiere einerseits mit 0 für Sichter / 30 für alle, andererseits mit 0, wegen Argumenten wie von 32X. Ich verstehe nicht ganz: Welche Vandalismusprobleme würden durch eine öffentliche Beobachterzahl erleichtert, die nicht durch die gesichteten Versionen behoben werden?

1) Der Knackpunkt sind die wenig beobachteten Artikel, oder? Wo nur zwei Beobachter sind, werden sich auch nur wenige sachkompetente Sichter finden und das Risiko, dass Fakes/Falschinfos gesichtet werden, steigt. Weil bei Sichtungsanfragen und sachfremden Sichtern nur wirklich grober Vandalismus nicht gesichtet wird?

2) Auch ohne öffentliche Beobachterzahl (=0) kann man die Beobachterzahl abschätzen, indem man die Bearbeiterzahl anschaut, das ist nach meiner Erfahrung stark zusammenhängend. Bei "Seiteninformationen" wird jetzt schon die "Gesamtzahl unterschiedlicher Autoren" angezeigt, ohne Rumsuchen in der Versionsgeschichte. Bei viel bearbeiteten/beobachteten Artikeln ist das sehr ungenau und sowieso egal, bei wenig bearbeiteten/beobachteten Artikeln nicht? Wieso nicht einfach die massenweise angelegten Ortsstummel (Dörfer in der Türkei, Gemeinden in Portugal etc.) vandalieren, die beobachtet vermutlich nicht mal der "Autor"?

3) Bei einer Mindestbeobachterzahl von 5 oder 10 muß man sich nur ein paar Beobachtungssocken anlegen und dann bei Erreichen der Mindestbeobachterzahl deren Zahl substrahieren, um die (echte) Beobachterzahl zu erhalten. Nicht schwierig, bei niedriger Zahl.

4) Es geht nicht um rechtliche Probleme, oder? Wenn jemand bspw. wegen Verleumdung in Personenartikel X klagen will, wird er sich an den Bearbeiter halten und maximal noch an den Sichter, aber wohl kaum an die Beobachter?

Kurz gesagt, hat hier mal jemand ein paar gute sachliche Argumente gegen Mindestbeobachterzahl=0, nicht nur en:Movie plot threats? Oder gäbe es die dann bei dem MB, das ich durchaus angemessen fände? --Atlasowa (Diskussion) 12:30, 9. Jan. 2013 (CET)

Du beantwortest die Frage im Grunde selbst: Es geht lediglich darum, es Vandalen nicht zu leicht zu machen. --TMg 18:15, 9. Jan. 2013 (CET)

Hm, die Frage ist aber: Welche Vandalismusprobleme würden durch eine öffentliche Beobachterzahl erleichtert, die nicht durch die gesichteten Versionen behoben werden? Wie würde das "es Vandalen zu leicht machen"? Dafür hätte ich gerne mal konkrete, realistische Beispiele. --Atlasowa (Diskussion) 00:13, 10. Jan. 2013 (CET)

Die Gesichteten Versionen sind grundsätzlich nur dazu gedacht, um offensichtlichen Vandalismus zu finden. Fakes/Falschinformationen können schon prinzipiell nicht von den Gesichteten Versionen abgedeckt werden, dafür sind die Geprüften Versionen gedacht (die längst fertig entwickelt sind, aber leider bis heute nicht eingeführt wurden). -- Chaddy · D – DÜP – 20:54, 9. Jan. 2013 (CET)

Das ist mir schon klar, aber geht es hier denn um Fakes/Falschinformationen? Inwiefern würde uns das Verstecken einer niedrigen Beobachterzahl vor Fakes/Falschinformationen schützen? Konkretes Beispiel? --Atlasowa (Diskussion) 00:13, 10. Jan. 2013 (CET)

Woher soll ein Beispiel für etwas kommen, das noch nie möglich war? --TMg 00:27, 10. Jan. 2013 (CET)

Du meinst, "noch nie möglich war, Wikipedia vor Fakes/Falschinformationen zu schützen"? Das heißt also, es geht hier nicht um Erleichterung von Fakes/Falschinformationen, bei öffentlich sichtbarer Beobachterzahl? Was genau soll denn die versteckte Beobachterzahl schützen, wie? --Atlasowa (Diskussion) 00:38, 10. Jan. 2013 (CET)

Ich glaube, wir sollten beide ins Bett gehen. Du hast nach Beispielen für Vandalismus gefragt, der durch die Einsehbarkeit niedriger Beobachterzahlen möglich wurde. Niedrige Beobachterzahlen waren noch nie einsehbar. --TMg 01:14, 10. Jan. 2013 (CET)

TMg, es würde schon helfen, wenn Du Deine kryptischen kurzen Gegenfragen zumindest an den passenden Post dranhängen würdest. Du sagst also, Du kannst keine konkreten Beispiele für Vandalismusgefahr durch eine sichtbare Beobachterzahl geben, weil niedrige Beobachterzahlen noch nie einsehbar waren. Keinerlei realistisches Szenario, keine Beispiele, keine sachlichen Argumente. Im Endeffekt ist das also nur "Haben wir schon immer so gemacht" und eine gute Portion FUD. OK, dann weiß ich jetzt wieviel ich von dem Vandalismusargument zu halten habe. --Atlasowa (Diskussion) 17:12, 10. Jan. 2013 (CET)

Wir haben verschiedene Vorstellungen davon, was „konkret“ bedeutet. Die Missbrauchsmöglichkeiten sind so unbegrenzt wie die Phantasie der Benutzer. Die schlimmsten Beispiele sind sowieso immer die, auf die man selbst niemals gekommen wäre. Ich finde nicht, dass wir Vandalen erst die Möglichkeit geben müssen, konkrete Fälle zu schaffen, um uns ein Urteil bilden zu können. Für Sichter freigeben, keine Frage. Auch die Spezialseite. Aber was hat ein unangemeldeter Benutzer davon, zu wissen, dass ein Artikel unbeobachtet ist, wenn er ihn selbst gar nicht beobachten kann? Das ist die Frage, die meiner Meinung nach gestellt werden sollte. --TMg 18:54, 10. Jan. 2013 (CET)

Ja, wozu benötigt man die Zahl eigentlich? Genannt wurden:

• In die eigene Beo unbeobachtete Seiten aufnehmen → bei IP-Benutzern unsinnig, da keine Beo vorhanden.
  • Inwiefern sollte es sinnvoll sein, dass Neulinge derartige Seiten gezielt beobachten, wenn sie meistens noch gar nicht vertraut genug damit sind, wie die WP überhaupt funzt → bei noch nicht automatisch bestätigten Benutzern unsinnig.
  • Leute, die noch nicht mal die passiven Sichterrechte erhalten, weil sie sich noch nicht genug auskennen, denen man noch nachsichtet, oder die wahlweise eventuell Vandalen sind und Schläferkonten für Editwars und Vandalismus in halbgeschützten Artikeln angelegt haben (davon gibt es ja etliche), was sollen die mit gezielt in die Beo aufgenommenen Seiten? → bei noch nicht passiven Sichtern unsinnig.
  • Passive Sichter, denen die aktiven Sichterrechte noch verwehrt werden oder noch nicht automatisch erteilt wurden, denen man also noch nicht genügend Regel-/WP-Kenntnis zutraut, um Vandalismus von Nicht-Vandalismus unterscheiden und somit Artikel nachsichten zu können, warum sollten die unbedingt gezielt unbeobachtete Seiten auf die Beo nehmen können, wenn ihnen die Identifizierung von Vandalismus noch nicht mal zugetraut wird? → bei passiven Sichtern unsinnig.
  • Fazit: das Argument ist erst ab Sichterstatus sinnvoll anwendbar.
• Fachportalen die Möglichkeit geben, wenig oder gar nicht beobachtete Artikel ihres Fachbereichs gezielt auf ihre Beobachtungsliste zu setzen. Also wieder die Beo. Dasselbe wie oben.
  • Wozu benötigen Leute in Fachportalen, die sich mit der WP insgesamt noch nicht genügend auskennen und ganz neu im Portal sind, die Zahlen? Wenn ihnen die korrekte Identifizierung von Vandalismus usw. mangels Erfahrung noch nicht zugetraut wird. Dafür reicht es doch, das Sichtern in geeigneter Weise zugänglich zu machen, beispielsweise nach Kats sortiert. Das muss man dafür aber nicht unbedingt überall öffentlich auslegen und für jeden sichtbar hinschreiben. Es wird dafür bessere Lösungen geben, wenn das speziell den Sichtern nützen soll. Und die passiven Sichter werden normalerweise bei einigermaßen normaler, halbwegs regelmäßiger Mitarbeit schon schnell genug Sichter. Falls sie so wenig Zeit und Lust haben, dass sie so selten mitwirken, dass das dauert, haben sie auch nicht ausgerechnet genügend Zeit und Lust für die unbeobachteten Seiten.

Die Argumente ergeben für Nichtsichter einfach keinen Sinn. Oder gab es noch irgendein anderes, das nicht mit „in die eigene Beo aufnehmen“ bzw. dem Nachsichten zu tun hatte? --Geitost 01:35, 11. Jan. 2013 (CET)

Kurze Wiederholung meines Vorschlags von unten: Freigabe der Spezialseite für Sichter, Freigabe der Zahl in den „Seiteninformationen“ für „automatisch bestätigte Benutzer“. --TMg 01:45, 11. Jan. 2013 (CET)

Das erklärt aber auch nicht, was die „automatisch bestätigten Benutzer“ mit der Info anfangen sollen und was die mit den Seiten in ihrer Beo sollen, wenn sie sich doch nicht genügend dafür auskennen (oder es sich um Schläfersocken für Editwars handelt). --Geitost 02:10, 11. Jan. 2013 (CET)

Ach komm schon, das ist doch genau die „Verfolgungswahn“-Argumentation, die uns vorgeworfen wird. Ein Mensch kann durchaus befähigt sein, einen Nutzen aus dieser Information zu ziehen, noch bevor er die Sichter-Kriterien erfüllt hat. Ob für „automatisch bestätigte Benutzer“ oder erst eine Stufe später für „passive Sichter“, sei mal dahingestellt. Das war ja nur mein Vorschlag, im Detail sollte das ein Meinungsbild klären. --TMg 02:37, 11. Jan. 2013 (CET)

Na ja, ich seh halt keine Gründe, die dafür sprechen, dafür aber gut mögliche Risiken. Das mit dem MB ist eh sinnvoll. Da kann man die Argumente mal übersichtlich auflisten und sich Leute besser entscheiden. Ob man das MB für die Absenkung auf 0 für Sichter braucht, ist allerdings sehr fraglich. Ob man für den Rest ein MB machen will und ob sich das lohnt, auch. Genauso gut könnte man MBs zu anderen sinnvollen Fragen machen. ;-) Aber wenn ich überlege, dass nun seit Beginn der WP (oder seit es derartige Zahlen zu unbeobachteten Seiten gibt) kein Sichter diese Zahlen einsehen konnte und das nicht genügend vermisst wurde, um von selbst mal eher darauf zu kommen, dann ist doch fraglich, warum man das direkt von Einsehbarkeit für Admins auf 0 oder automatisch bestätigte Personen runtersetzen sollte. Das finde ich schon sehr fragwürdig. Man kann auch genauso gut die Grenze auf Sichter runtersetzen und das testen und gucken, was sich daraus so ergibt. Ist gar nicht nötig, etwas nun übers Knie zu brechen, was jahrelang nicht groß von vielen Leuten vermisst wurde. My 2 ct. --Geitost 03:36, 11. Jan. 2013 (CET)

Ist ja nicht so, dass es keine Vandalen gegeben hätte, die sich Vorratskonten für unsinnige und beleidigende Seitenverschiebungen oder Edits in halbgeschützten Seiten angelegt hätten. Und ist auch nicht so, dass es noch keinen MB-Entwurf gegeben hätte, die Rechte für automatisch bestätigte Benutzer abzusenken oder die Kriterien für das Erreichen höher. Da beißt man sich nur ins eigene Fleisch, wenn man nun ausgerechnet so was da mit hineinnähme. Muss doch nicht sein. In der es-Wp benötigt man erst mal 50 Edits, um automatisch bestätigter Benutzer zu werden. Damit verbaut man Leuten aus anderen Wikis Möglichkeiten, halbgeschützte Seiten für Interwikis bearbeiten zu können. Ich bin ganz froh, dass hier das Kriterium nicht restriktiver ist. Dafür sollten dann aber auch nicht solche für diese Benutzergruppe unnötigen Rechte hinzugefügt werden, damit das so bleiben kann und nicht wieder jemand mit einem neuen MB um die Ecke kommt, die Kriterien für die Gruppe anzuheben. Das wäre wirklich sehr unsinnig.

Wenn es keinen guten Grund gibt, einer Benutzergruppe ein zusätzliches Recht zu geben, das am Ende missbraucht werden kann und zu Forderungen nach Verschärfung der Kriterien für das Erreichen der zugehörigen Benutzerrechte führt, dann sollte man so was eben sein lassen. Das bringt doch nix. --Geitost 03:46, 11. Jan. 2013 (CET)

Mal so als Einwurf: „Warum antwortet niemand auf meine hier auf der Diskussion vorgebrachte Kritik? … Oha, niemand beobachtet den Artikel, evtl. sollte ich mich doch an ein Portal wenden.“ --32X 10:25, 11. Jan. 2013 (CET)

Diskussion lang sein, nix alles im Kopf haben. Hatte unten bei den Anmerkungen zu den Umfrageeinträgen nachgesehen, was da so angemerkt wurde.

Also erst mal glaub ich nicht, dass ein Neuling überhaupt genug die Strukturen kennt, um dann auf die Idee zu kommen, ein Portal aufzusuchen. Zweitens sind auch einige Portale so selten belebt, dass man dort auch erst mal auf eine Antwort warten könnte (würde also dann auch nix nutzen, selbst wenn das angeblich soundso viele Leute beobachten). Andersherum könnte man dann auch die irreführende Info erhalten, dass soundso viele Leute den Artikel beobachten und dort eine Antwort erwarten oder erhoffen, übersieht dabei aber (oder weiß gar nicht erst), dass viele Autoren seit langer Zeit völlig inaktiv sind, sodass die da gar nix mehr aktiv beobachten, selbst wenn der Artikel auf noch so vielen Beos steht. Andere wie ich haben eh eine überfüllte Beo und kriegen solche Nachfragen auf Artikeldisks normalerweise eh nie mit. Oder haben darauf auch keine Antwort oder können dazu nix beitragen. Also bringt die Info Neulingen wenig. Wobei ich auch glaube, dass sie die Seite auch erst mal gar nicht kennen und nicht auf die Idee kommen, dort danach zu sehen. Und es ihnen halt auch eh wenig bringen wird. Insofern halte ich das für einen nicht sinnvollen Ansatz und bin dafür, bessere Ansätze dafür auszuprobieren, sei es über Editintros oder kleine Hinweise auf den Disks selbst bzw. bei einer noch roten Seite einen automatisch erzeugten Hinweis dort.

Bei den allermeisten Artikeln, die wenige Leute bearbeiten, bekommt man auch eh auf den Disks erst mal gar keine Antworten. Das sieht man ja immer wieder. Da wäre es wesentlich hilfreicher, wenn man gleich auf alle existierenden Artikeldisks einen kleinen Hinweis setzte, dass man sich an Ort XY (z. B. FZW oder auch FVN) wenden soll, wenn auf eine Frage dort auf der Disk. keine Antwort erhält. Allerdings würde dann wohl keiner mehr dort diskutieren, sondern direkt alle bei FZW o. Ä. auflaufen, das wäre evtl. auch nicht so sinnvoll. Aber man könnte es testen. Zum Beispiel, indem man einen solchen kleinen Hinweis mal testweise in den Text nur für Artikeldisks in die Vorlage {{Diskussionsseite}} einbaut. Die steht zwar wahrscheinlich eher auf den besuchteren Disks, aber Versuch macht kluch, oder? --Geitost 18:50, 12. Jan. 2013 (CET)

Du gehst von der Annahme aus, dass der angehende Wikipedianer zum ersten Mal in der Wikipedia mit MediaWiki in Kontakt kommt. Meine ersten vier Tilden setzte ich außerhalb der WP. Inzwischen meint selbst der anerkannte Soziologe Dr. Thomas König, dass ich ein Experte bin. :) Interessant, dass bei der Vorlage:Diskussionsseite plötzlich das Argument Versuch macht kluch zieht. --32X 19:45, 12. Jan. 2013 (CET)

<Nach links rutsch> Dann finde ich unten noch (mehrfach übrigens) das Argument unter 0:

• „Für Autoren ist es aber auch oft interessant, wer noch den Artikel beobachtet!“

Ist natürlich auch ein schönes Argument, wo man doch nur eine Zahl angezeigt bekommt und nicht etwa, wer den Artikel beobachtet. Da dürfte es schon wesentlich weniger „interessant“ sein, ob es nun 5 oder 25 Leute sind. Was macht man dann als Nichtsichter praktisch mit dieser Info?

• „man kann ggf. auch einfach die aktuelle Sichtung entfernen“

unter 0 trifft auch nur auf Sichter zu und mit dem Argument

• „Das ist Wikiprinzip. Für großen Missbrauch seh ich keine Anzeichen.“

könnte man auch passiven Sichtern schon direkt die Sichterknöppe in die Hände drücken. Oder?

Genau. Gegen die Einführung des Sichtens war ich damals aus prinzipiell dem gleichen Grund. -- TZorn 12:06, 11. Jan. 2013 (CET)

Und bei 0 findet sich auch so was

• „bis man auf dem Stand ist sowas brauchen zu können sollte man normalerweise die Sichterrechte eh schon haben“

Eben. Bleibt noch das Argument mit den "Änderungen an verlinkten Seiten" von BlueCücü:

• „Gleichzeitig den Fachportalen unbeobachtete Artikel ihres Fachbereichs per Bot regelmäßig listen. Dann können Portalmitarbeiter über "Änderungen an verlinkten Seiten" diese Artikel im Auge behalten oder auf ihre Beo nehmen.“

Das ließe sich evtl. anders bewerkstelligen, als gleich alle Leute das ebenfalls einsehen zu lassen, die es nicht gebrauchen können, sondern höchstens missbrauchen. Man könnte den Sichtern das auf andere Weise über Kats zur Verfügung stellen oder einfach jedes Mal jeweils eine andere Auswahl an Artikeln mit weniger als 30 Beobachtern listen und dabei nur für Sichter die genaue Zahl sichtbar machen, dann könnte man sich dort die sehr wenig unbeobachteten rauspicken. Oder man baut in die dann nur für Sichter einsehbare Spezialseite zu den unbeobachteten Seiten eine Funktion ein, diese nicht nur alphabetisch, sondern nach Kats sortiert auszugeben. Oder erfindet eine solche Seite neu per Antrag über Bugzilla. Und baut in diese dann evtl. noch ein, die "Änderungen an verlinkten Seiten" beobachten zu können. Etwas Derartiges wäre noch sinnvoller. --Geitost 02:01, 11. Jan. 2013 (CET)

Vorbehalte bremsen das Projekt vermutlich mehr als Vandalismus. -- · peter schmelzle · disk · art · pics · lit · @ · 10:10, 11. Jan. 2013 (CET)

Für alle, die auf die Beobachtungszahl auf Spezial:Seiten mit ungesichteten Versionen verweisen. Für die Zahl wird geschaut, welcher der Benutzer, die die Seite beobachten, haben in den letzten 2 * 180 Tagen (mw:Manual:$wgCookieExpiration) eine Aktion gemacht. Zu den Aktionen gehören Anmelden, Seiten auf die Beobachtungsliste nehmen/entfernen, Einstellungen verändern oder Bearbeitungen tätigen und vielleicht noch andere Dinge (Ist nicht ganz überschaubar). Das ist ein anderes Verständnis von aktiv, wie auf Spezial:Aktive Benutzer oder die Zahl auf Spezial:Statistik. Der Umherirrende 20:36, 12. Jan. 2013 (CET)

Mmh, hast du grad gesagt „Einstellungen verändern“? Du meinst die persönlichen Einstellungen? Wenn jemand nur die Sprache von de auf de-ch umstellt, wird er dadurch als aktiv gerechnet, auch wenn das niemand hier sieht? Oder wie?

Und mit Anmelden meinst du ein Konto neu bzw. automatisch erstellen (also alles unter Spezial:Logbuch/newusers) oder meinst du, wenn jemand nach 6 Monaten Inaktivität automatisch durch die Software abgemeldet wurde und dann auf den Knopf „Anmelden“ (was eigentlich richtig Einloggen heißen müsste) klickt und sich wieder anmeldet/einloggt?

Warum diese verwirrenden Unterschiede, ich bin jetzt völlig konfus? Was ich aus eigener Erfahrung genau weiß durch Klicks auf „Beobachten“/„Nicht beobachten“ als ich gerade über 30 Tage für diese Seite als inaktiv galt:

Auf Spezial:Seiten mit ungesichteten Versionen werden nur Benutzer als aktiv gelistet, die in den letzten Monaten entweder editiert haben oder auch Logs gemacht haben, Nachsichten ohne Edits zählt als Aktivität in dem Sinne. Das nicht öffentlich sichtbare Einloggen in das Konto zählt dort hingegen nicht als Aktivität.

Andererseits wurde ich ohne Edits nur mit Nachsichten nicht als im Sinne von Spezial:Aktive Benutzer aktiv gezählt, dort war ich also inaktiv, zeitgleich auf Spezial:Seiten mit ungesichteten Versionen aktiv. Ich hatte da im Juni mehrfach eine Seite auf die Beo gesetzt und wieder runtergenommen, um zu checken, dass das nicht nur ein Zufall war. Insofern stimmt der Satz auf der Aktive-Benutzer-Seite nicht ganz. Da steht:

• „Dies ist eine Liste von Benutzern, die innerhalb der letzten 30 Tage Aktivitäten aufwiesen.“

Richtig wäre, was auf Spezial:Statistik steht:

• „Benutzer mit Bearbeitungen während der vergangenen 30 Tage“

Es geht da nur um die Bearbeitungen, nicht um Nachsichtungslogs und so was.

Warum aber immer wieder verschiedene Bedingungen für diese verschiedenen Spezialseiten? --Geitost 22:36, 12. Jan. 2013 (CET)

Ich habe es gerade mal mit einem anderen Account ausprobiert. Der Account hat noch 0 Bearbeitungen und wenn ich dort eine Seite auf die Beobachtungsliste nehmen, dann sehe ich auf "Seiten mit ungesichteten Versionen" dass die Zahl der aktiven Beobachter sich erhöht und nach dem entfernen auch wieder verringert. Mit Anmelden, meine ich das anmelden, nicht Registrieren oder Benutzerkonto anlegen, obwohl diese Fälle auch mit als Aktivität im Sinne von FlaggedRevs fallen dürften.

Warum das unterschiedlich ermittelt wird, kann man nur spekulieren. Der Umherirrende 23:15, 12. Jan. 2013 (CET)

Wahrscheinlich bin ich jetzt bei den verschiedenen Seiten schon ganz konfus. Irgendwie hatte ich jetzt verstanden, dass die Spezialseiten Spezial:Ignorierte Seiten (die ich ja nicht einsehen kann) und Spezial:Seiten mit ungesichteten Versionen auch unterschiedliche Kriterien haben. Und dann gibt es noch die Spezial:Ungesichtete Seiten, wo zumindest bei mir keine Beobachterzahl zu finden ist (aber vielleicht ja bei den Admins?).

Also dann gilt auf der Spezialseite Spezial:Seiten mit ungesichteten Versionen gar keine 30-Tage-Regel? Ich dachte gerade, du hättest von Spezial:Ignorierte Seiten geredet, wie gesagt, ich bin jetzt durcheinander. Dann müsste ich also bei Spezial:Seiten mit ungesichteten Versionen auch schon ohne das Nachsichten als aktiv gegolten haben schon alleine durch das Seiten-auf-Beo-Setzen. Na, ich dachte, die 30 Tage hätten da auf jeden Fall gegolten, oje, wie konfus. Warum steht so was denn nicht dabei? Dann wäre die Zahl dort ja gar nichts mehr wert, wenn sogar seit 255 Tagen gesperrte Socken mit drin sind. Und was gilt dann jetzt für Spezial:Ignorierte Seiten? Wieder was Anderes? Konfuse Grüße --Geitost 00:35, 13. Jan. 2013 (CET)

Ja, es ist konfus. Die Seite Spezial:Ignorierte Seiten arbeitet ohne Bedingungen und zeigt einfach alle Seiten an, die auf gar keiner Beobachtungsliste stehen. Also verhindern auch Seiten auf Beobachtungslisten von gesperrten oder stillgelegten Benutzerkonten ein Eintrag auf der Spezialseite.

Die Spezialseiten der gesichteten Versionen (Spezial:Seiten mit ungesichteten Versionen und Spezial:Ungesichtete Seiten) zeigen nach anfangs genannten Kriterien die "aktiven Benuzter" an. Also nicht die 30-Tage-Regel. Letztere allerdings nur für Admins (unwatchedpages-Recht). Der Umherirrende 10:03, 13. Jan. 2013 (CET)

Nicht gesichtete NRs

Was IMHO von vielen Benutzern vergessen wird, die für die Option 0 für alle sind, ist die Tatsache, dass wir auch NRs haben, wo die Sichtung nicht aktiviert ist. So könnten beispielsweise unbeobachtete Hilfe-, Wikipedia- oder Portal-Seiten ein beliebtes Ziel von Vandalen werden. --Leyo 11:13, 9. Jan. 2013 (CET)

Sämtliche Artikeldiskussionsseiten werden ebenfalls nicht gesichtet, und bei unbeobachteten Disks kann schon mal sehr lange der Vandalismus stehen bleiben. Ähnlich wie vor nicht allzu langer Zeit auch noch bei den Kats, wo Vandalismus monatelang stand, Coe sammelt Derartiges. Und dann gibt's noch den gesichteten Unsinn. --Geitost 16:51, 9. Jan. 2013 (CET)

Wer eine unbeobachtete Nicht-ANR-Seite vandalieren will, kann einfach eine beliebige Seite mit "Archiv" im Titel auswählen, die Wahrscheinlichkeit, dass diese keinen Beobachter hat, dürfte ziemlich groß sein. Wenn die Zahl der Beobachter angezeigt wird, macht das solchen Vandalismus also auch nicht leichter. --Schnark 09:17, 10. Jan. 2013 (CET)

Und die InfoAction (für eine Seite!) aufzurufen, ist ungefähr genauso viel Aufwand wie ein kompletter Vandalismusedit üblicher Bauart. Wenn ich dann noch zig Artikel durchgehen will, bis ich mal einen gefunden habe, den tatsächlich keiner beobachtet, bin ich sicher wesentlich länger mit dieser Suche beschäftigt als mit dem Vandalismus selbst. Sicher, wenn ich bereit bin, wirklich Zeit in einen perfide gemachten und versteckten Vandalismus zu investieren, der gemacht ist, um nicht entdeckt zu werden, dann ist die Information des Unbeobachtetseins ein Mosaicsteinchen, das mir dabei helfen kann (aber auch wohl kaum die entscheidende Information, denn auch Beobachtungslisten sind ja bekanntlich kein Allheilmittel gegen Vandalismus). Dasselbe Mosaicsteinchen können aber auch viele verwenden, die bereit sind, ernsthaft Zeit in die Verbesserung der Wikipedia zu investieren. --YMS (Diskussion) 15:45, 10. Jan. 2013 (CET)

Sollte der Einbau der Funktion in die Software es nicht eigentlich einfacher machen, unbeobachtete Artikel zu finden? Immerhin wird das hier in den Diskussionen auch als schlagendes Argument für eine unbegrenzte Freigabe genannt: Weil es so einfacher wäre, unbeobachtete Artikel zu finden. Wie sieht das praktisch aus? Wenn das tatsächlich so umständlich ist, wie du schilderst, dann ergibt die ganze Diskussion um eine Zahl überhaupt keinen Sinn. Dann wird die Anzeige auf der Infoseite für automatisch bestätigte Benutzer freigegeben und die Spezialseite für Sichter. Ohne irgendwelche Zahlen. --TMg 18:54, 10. Jan. 2013 (CET)

Dass es sonderlich umständlich ist, wollte ich nicht sagen. Um rauszufinden, wie viele Beobachter eine Seite hat, muss ich, angenommen die Seiteninformationen zeigen mir das an, halt eine Spezialseite öffnen, die irgendwo in der Werkzeugleiste verlinkt ist. Die ist standardmässig zugeklappt, ich brauche also zwei Klicks um sie aufzurufen. Das ist so erstmal natürlich keine wahnsinnige Hürde, aber mit diesen zwei Klicks könnte ich auch "Bearbeiten" und "Speichern" drücken, dazwischen halt noch ein paar Tastenanschläge (in der Regel nicht besonders viele), um die Seite tatsächlich zu vandalisieren und somit experimentell rauszufinden, ob Vandalismusschutzmassnahmen bei dieser Seite greifen oder nicht. Will ich dagegen wirklich die Zahl der Beobachter einbeziehen, wird vermutlich nicht gleich die erste Seite, die ich untersuche, unbeobachtet sein, und auch nicht die zweite, die dritte. Wie viele Seiten tatsächlich unbeobachtet sind, weiss ich nicht, aber unter den ersten 500 Einträgen auf Spezial:Seiten mit ungesichteten Versionen finden sich derzeit etwa nur zwei unbeobachtete Artikel (unter den letzten 500 sind es 8), demnach wären also statistisch schon so um die 100 Artikel zu untersuchen, bis ich zufällig einen unbeobachteten finde. Ich nehme an, dass die Beobachtungsquote in Meta-Namensräumen eher noch höher ist. --YMS (Diskussion) 10:47, 11. Jan. 2013 (CET)

Unbeobachtete Seiten kann Admin bereits über die Spezialseite finden, daher muss hier nichts gemacht werden, nur diskutiert werden, wer es sehen soll. Die Seiteninformationen sollen nur eine aktuelle und schönere Ansicht von solchen aggregierten Zahlen auf Seitenbasis anzeigen.

Es sind grob 10 % der Artikel unbeobachtet (ohne Weiterleitungen), siehe Wikipedia Diskussion:WikiProjekt Ignorierte Seiten#115.000 Unbeobachte Artikel (Anfang August 2012). Der Umherirrende 15:10, 11. Jan. 2013 (CET)

Sind diese 115.000 unbeobachtete Seiten tatsächlich auf den Artikelnamensraum eingeschränkt? Nicht dass ich es für ausgeschlossen hielte, dass es doch fast 10 % sind, mich wundert nur, dass dann bei den lange ungesichteten Seiten (die sind ja eigentlich schon der "Bodensatz" für den sich kaum jemand interessiert) so deutlich weniger (rund 1 %, eher noch weniger) auflaufen (und unter den erst seit ganz Kurzem ungesichteten Seiten ebenso, was praktisch ausschliesst, dass es nur in der Spezialseite so aussieht, weil jemand gezielt unbeobachtete Artikel sichtet oder beobachtet). --YMS (Diskussion) 16:18, 18. Jan. 2013 (CET)

Ja, sie wurden alle in einem Benutzerkonto gesammelt (siehe WP:WikiProjekt Ignorierte Seiten), daher gibt es kein "Bodensatz". Alle jetzt auf der Spezialseite gelisteten Seiten sind neue Artikel im Artikelnamensraum (Angelegt oder hinverschoben). Es sammeln sich dort ca. 800 Artiel in 14 Tagen (vom 10.01 bis zum 22.01 sind es 808 gewesen). Die Spezial:Seiten mit ungesichteten Versionen definiert das unbeobachtet auch etwas anders, dazu steht aber irgendwo in dieser Diskussion schon etwas. Der Umherirrende 20:55, 23. Jan. 2013 (CET)

Lösung des Problems, nicht der Symptome

Was von vielen gerne vergessen wird: Würden die Beobachterzahlen offenliegen, hätten die Fachportale endlich die Möglichkeit, wenig oder gar nicht beobachtete Artikel ihres Fachbereichs gezielt auf ihre Beobachtungsliste zu setzen. Ich z. B. wäre gerne bereit, einen Stapel an Artikeln zu meinen Fachgebieten Motorsport, Politikwissenschaft und Soziologie auf meine Beobachtungsliste zu packen. Allerdings weiß ich nicht, welche Artikel dies nötig hätten und kann auch nicht gezielt nach derartigen Artikeln suchen. Letztlich würde sich also die Vandalismusgefahr sogar reduzieren, weil sich die Zahl der unbeobachteten Artikel endlich systematisch verringern ließe. -- Chaddy · D – DÜP – 21:01, 9. Jan. 2013 (CET)

Wikipedia:WikiProjekt Ignorierte Seiten. Der Umherirrende 21:12, 9. Jan. 2013 (CET)

Ist mir bekannt. Das funktioniert aber nur sehr umständlich, kein Wunder, dass dieses Projekt schon längst wieder eingeschlafen ist. Würden die Zahlen offenliegen, wäre das ganze wesentlich effektiver gestaltbar. -- Chaddy · D – DÜP – 21:25, 9. Jan. 2013 (CET)

Kein Mindestwert, aber sichtbar für die Benutzer mit Sichterstatus wäre gut. Alte Schule (Diskussion) 20:49, 11. Jan. 2013 (CET)

Umfrage auslagern

Ich würde diese Umfrage immer noch gerne in der Kategorie:Wikipedia:Umfrage kategorisieren, wo sie wie andere Umfragen hingehört. Nun hieß es dazu aber kürzlich, dann sollte sie ausgelagert werden auf eine eigene Seite. Folgende Möglichkeiten bestünden:

1. Wie es bei einigen älteren MBs in der MB-Kat auch bereits seit Jahren gemacht wird, nur diesen Oberabschnitt zur Umfrage kategorisieren ohne große Auslagerung. Die Kat würde dann später mitsamt dem Abschnitt korrekt archiviert und bliebe bei der Umfrage.
2. Eine Weiterleitung von Wikipedia:Umfrage/Mindestwert für „Anzahl der Beobachter der Seite“ festlegen hierher erstellen und jene Seite kategorisieren, die müsste bei der späteren Archivierung dann aufs Archiv umgebogen werden. Oder:
3. Die ganze Umfrage dorthin auslagern: den Diskussionsabschnitt auf die Disk. und die Umfrageoptionen nach vorne

Das Erste hab ich ja schon probiert, wurde revertiert und als ungünstig betrachtet, obwohl es bei vielen alten MBs genauso gemacht wurde. Ohne diese Option bleiben noch 2. und 3. übrig. Man kann natürlich einfach ne WL anlegen, aber da die Diskussion und Umfrage auch immer länger wird und noch weiter diskutiert wird, halte ich eine Auslagerung für besser. Um es halbwegs übersichtlich zu halten und auch diese Seite mit einer Umfrage nicht zu sehr zu beladen. Dann hätte man auch die Diskussion von den Optionen vorne getrennt und es wäre ne ganz normale Umfrage. Das wäre für die Hauptseitenumfrage kürzlich auch besser gewesen, dort könnte man auch einfach ne WL erstellen, wenn man nicht die Hauptseitendisk. in der Umfragenkat haben will. Da die Disk.-Beiträge alle signiert sein sollten (sonst müsste man unsignierte eben noch markieren) und die Einträge bei den Optionen unten sowieso, bliebe dabei auch nichts, was urheberrechtlich problematisch wäre. Auch könnte man dann mittels Plus-Knopf einen neuen Disk.-Abschnitt anlegen, was hier so gar nicht möglich ist, ohne dass der Abschnitt hier an dieser Stelle landet. Spricht also mehr fürs Auslagern.

Ich bin also für 3. und würde das morgen umsetzen, wenn niemand widerspricht. :-) Also, jemand Einwände? Und was mit der Umfragenkat für die Hauptseitendisk.? --Geitost 00:57, 13. Jan. 2013 (CET)

Pro #3. --Leyo 01:07, 13. Jan. 2013 (CET)

Hört sich gut an. Ich hatte ja nicht gedacht, das es so riesige Diskussion dazu gibt. Danke schonmal. Der Umherirrende 10:03, 13. Jan. 2013 (CET)

Wie gehts weiter?

Die Umfrage läuft nun seit einem Monat. Ich denke, allmählich kann man sie abschließen. Das Ergebnis ist ziemlich eindeutig, aber ich weiß, dass es nur eine unverbindliche Umfrage ist. Was machen wir also nun? Ein MB? Oder gleich den Wille der Community umsetzen? -- Chaddy · D – DÜP – 16:24, 3. Feb. 2013 (CET)

Ich wäre für ein MB. Diese Umfrage hat sich im Laufe in ihren Abstimmoption und Argumenten geändert, auch wenn das wohl im Endeffekt nicht so viel ausmacht. Zudem finden sich in den Stimmen Unterscheidungen zwischen "für alle" und Sichter, das sollte berücksichtigt werden, auch wenn die letzte Variante IIRC in der Form zurzeit noch nicht möglich ist.--se4598 / ? 16:37, 3. Feb. 2013 (CET)

In der Form "Sichter kriegen's ab x Beobachter angezeigt, Nichtsichter ab y" wohl nicht, aber auf jeden Fall machbar wäre, den Sichtern das unwachtedpages-Recht zu geben (mit freilich all seinen Folgen, also auch etwa den Zugriff auf die Spezialseite), und für den Rest in der InfoAction einen Schwellenwert zu setzen. Damit könnte dann ein MB z.B. die Optionen wie "0 für alle", "0 für Sichter, 30 für Rest" und "30 für alle" umfassen. --YMS (Diskussion) 16:49, 3. Feb. 2013 (CET)

Ich gehe davon aus, dass ein MB das gleiche Ergebnis bringen würde. Demnach denke ich, dass diese Umfrage durchaus ausreicht. -- RacoonyRE (✉ Diskussion) 18:33, 3. Feb. 2013 (CET)

Immer sichtbar für Sichter, seh ich als eindeutig an. Aber was mit dem Rest ist, ist mangels vieler unklarer Stimmen, finde ich, nicht eindeutig. -- TZorn 21:37, 3. Feb. 2013 (CET)

Nicht-Sichter sollen wohl kaum „0“ kriegen… Bei der Umfrage wurde zu Beginn leider nicht zwischen Sichtern und Nicht-Sichtern unterschieden. --Leyo 22:08, 3. Feb. 2013 (CET)

Ja aber sicher doch. Es gibt genug Stimmen unten, die Nichtsichter explizit in die 0-Schwelle einschließen. -- TZorn 22:26, 3. Feb. 2013 (CET)

Versprecht euch bitte nicht zu viel davon. Ich überbringe nur ungern die schlechte Nachricht, aber die Community kann diese Funktion nicht ändern, das müsste ein Steward tun. Und für die sind Umfragen und auch Meinungsbilder nicht verbindlich, sondern nur ein Aspekt von vielen in ihrer Meinungsbildung. In der de-WP werden Meinungsbilder inzwischen als bindende Abstimmungen angesehen, so waren sie aber ursprünglich nicht gedacht und werden in den anderen Projekten auch nicht so verwendet. Egal ob Umfrage oder Meinungsbild, ein Steward wird sich die Statements und Stimmen ansehen. Und dann wird er in diesem Fall alles beim Alten lassen. Denn kein Steward wird jemals in der de-WP irgendetwas tun, was gegen die Stimmen von Raymond, Der Hexer, Jan Eissfeldt und DaB wäre, nicht wenn die sich alle einig sind, dass keine Änderung wünschenswert ist. Dies bezüglich sind nicht alle Wikipedianer gleich, Mehrheiten reichen nicht, hier zählen Erfahrung und langjähriges Engagement in Zusammenarbeit mit den projektübergreifend technisch tätigen Leuten. Nicht Demokratie, sondern Meritokratie. Grüße --h-stt !? 15:57, 4. Feb. 2013 (CET)

So düster würde ich das jetzt nicht sehen. Die Foundation hat hoffentlich aus der Bildfilter-Geschichte gelernt und missachtet nicht den Willen der zweitgrößten Wikipedia-Community. Ein Stewart kann es kaum rechtfertigen, ein Mehrheitsverhältnis von 34:106 zu ignorieren, da muss es schon sehr gute Gründe dafür geben. Die gibt es hier aber nicht, wie im Laufe der Diskussion aufgezeigt wurde. -- Chaddy · D – DÜP – 16:20, 4. Feb. 2013 (CET)

Auch Stewards können diese Änderung nicht durchführen, sondern nur Serveradmins. Diese setzen den Willen der Community um, sofern er nicht gegen Grundsätze der Foundation verstößt (was hier nicht zutriffen sollte). Nur muss man den Serveradmins das irgendwie klar machen, da hilft es eine Liste von Benutzernamen zu haben, nur sollten vorher klare Optionen dabei sein. Der Umherirrende 17:11, 4. Feb. 2013 (CET)

Mindestwert für „Anzahl der Beobachter der Seite“ von 30

1. Der Umherirrende 19:47, 3. Jan. 2013 (CET)
2. -- Conan (Nachricht an mich? Bitte hier lang.) 20:08, 3. Jan. 2013 (CET)
3. --Anka ☺☻Wau! 20:26, 3. Jan. 2013 (CET)
4. --PerfektesChaos 20:41, 3. Jan. 2013 (CET)
5. --Steef ³⁸⁹ 23:10, 3. Jan. 2013 (CET) Als Anmerkung ist zu sagen, dass mMn jeder Wert kleiner 20 wohl von den Serveradmins abgelehnt wird.
6. — Raymond ^Disk. 00:12, 4. Jan. 2013 (CET) (könnte auch mit 20 leben)
7. dito  @xqt 11:33, 4. Jan. 2013 (CET)
8. —DerHexer (Disk., Bew.) 12:05, 4. Jan. 2013 (CET) Siehe TMg zu Peter Schmelzle. Einfacherer Zugriff und Freischaltung für Sichter gerne.
9. -jkb- 12:13, 4. Jan. 2013 (CET) unbedingt
10. --Engie 12:38, 4. Jan. 2013 (CET) Null wäre grob fahrlässig, solche Artikel sind ein gutes Ziel für subtilen Vandalismus
11. --Jan eissfeldt (Diskussion) 12:51, 4. Jan. 2013 (CET)
12. --JD {æ} 12:59, 4. Jan. 2013 (CET)
13. --Gerbil (Diskussion) 18:34, 4. Jan. 2013 (CET) meinethalben auch 50; es sei denn, wer länger als z. B. 8 Wochen in WP inaktiv ist, wird automatisch bei der Zählung ignoriert
14. kh80 •?!• 18:35, 4. Jan. 2013 (CET)
15. --Merlissimo 02:38, 5. Jan. 2013 (CET) Vandalen sollten den Wert nicht sehen. Insofern bin ich gegen einen niedrigen Wert oder sogar Freigabe für jedermann. Von mir aus können aber Sichter (editors) gerne das unwatchedpages-Recht bekommen, da sie keine Vandalen sein sollten.
16. --Prüm 10:34, 5. Jan. 2013 (CET) Ausgleichs-30.
17. --Asturius (Diskussion) 19:46, 5. Jan. 2013 (CET)
18. -- Herby 19:32, 6. Jan. 2013 (CET)
19. --Neozoon (Diskussion) 21:35, 6. Jan. 2013 (CET) (status quo hat sich bewährt)
20. --TMg 00:41, 7. Jan. 2013 (CET) Am liebsten wäre mir, dass nur aktive Sichter die Zahl sehen könnten, dann natürlich unbeschränkt. Da das aktuell wohl noch nicht geht, votiere ich vorübergehend für den Status quo.
21. Yellowcard (Diskussion) 00:44, 7. Jan. 2013 (CET) Könnte mir auch niedrigere Werte vorstellen, 0 halte ich für keine gute Idee, da gezielter Vandalismus so ein sehr effektives Tool erhält. Yellowcard (Diskussion) 00:44, 7. Jan. 2013 (CET)
22. --Schreiben ^Seltsam? 08:13, 7. Jan. 2013 (CET)
23. --Filzstift ✎ 08:30, 7. Jan. 2013 (CET) Bei Benutzern mit Sichterrechten dagegen 0. Gezielter Vandalismus ist sonst einfach (siehe Yellowcard).
24. --Mogelzahn (Diskussion) 15:23, 7. Jan. 2013 (CET) per Merlissimo.
25. --Daniel749 Disk. (ST–WPST) 18:52, 7. Jan. 2013 (CET) siehe Vorredner (Merlissimo & Filzstift)
26. Botulph 00:01, 8. Jan. 2013 (CET) Wie vorstehend. Wie stets vorbehaltlich besserer Erkenntnis. Freundlicher Gruß. +verneig+
27. -- P.oppenia (Diskussion) 00:16, 8. Jan. 2013 (CET)
28. --Geitost 01:01, 9. Jan. 2013 (CET) per Merlissimo und Filzstift
29. --DaB. (Diskussion) 21:16, 13. Jan. 2013 (CET) 30 waren gut und sind gut ;-).
30. -- Stechlin (Diskussion) 21:25, 13. Jan. 2013 (CET)
31. -- Quedel ^Disk 00:00, 15. Jan. 2013 (CET)
32. --Bubo 容 17:16, 15. Jan. 2013 (CET)
33. --Sputniktilt (Diskussion) 20:24, 3. Feb. 2013 (CET) ack Merlissimo & Filzstift
34. --h-stt !? 10:44, 4. Feb. 2013 (CET)

Andere Mindestwerte (absteigend)

1. 50 -- Steak 14:55, 19. Jan. 2013 (CET) und das auch nur für Sichter
2. 20 --Leyo 23:00, 3. Jan. 2013 (CET)
3. 20 --se4598 / ? 03:09, 4. Jan. 2013 (CET) Der Wert sollte für dewp reichen (u.a. da wir weniger Gesamtautoren als enwp haben)
4. 15 --APPER\^☺☹ 17:12, 6. Jan. 2013 (CET) Für Sichter 0. Unsere RC funktioniert ganz gut, aber es rutscht immer was durch. Grad mal ein paar Änderungen mit Vandalismus angeschaut, der länger nicht gefunden wurde (seit mindestens vorgestern), die Beobachteranzahl lag zwischen 1 und 14. [3] [4] [5] [6] [7]
5. 10 -- feuerst – disk 22:53, 3. Jan. 2013 (CET) per Schmelzle
6. 10 --Orci Disk 11:27, 4. Jan. 2013 (CET) das Vandalismus-Argument halte ich für nicht sonderlich bedeutend, denn die Bekämpfung davon geht vor allem über die Letzten Änderungen und Gesichteten Versionen, für beides ist die Anzahl Beobachter unerheblich
7. 10 -- Lord van Tasm «₪» ‣P:MB 11:32, 4. Jan. 2013 (CET)
8. 10 Kein Einstein (Diskussion) 15:22, 4. Jan. 2013 (CET)
9. 10 -- Shisha-Tom 12:40, 4. Jan. 2013 (CET) siehe Orci
10. 10 -- Vuxi (Diskussion) 20:38, 10. Jan. 2013 (CET) 0 für Sichter

    5 --Nightfly | _Disk 11:50, 4. Jan. 2013 (CET)

11. 5 --Grip99 02:38, 7. Jan. 2013 (CET)
12. 0 für Sichter, 5 für alle anderen. Grüße — Alleskoenner (Diskussion) 13:56, 19. Jan. 2013 (CET)
13. 0 --Schwäbin 09:03, 11. Jan. 2013 (CET) für Sichter. Nicht für alle freigeben, das ist unnötig. Aber für Sichter ist 0 okay, denn ich habe beim Sichten schon haarsträubende Fehler aus Artikeln entfernt, die von über 50 Benutzern beobachtet wurden, die Zahl sagt also nicht viel aus.

Kein Mindestwert

1. 1 (ja, ich bin mir bewusst, dass das effektiv gleich 0 ist) --Schnark 10:10, 4. Jan. 2013 (CET)
2. 0 YMS (Diskussion) 20:28, 3. Jan. 2013 (CET)
3. 0 -- · peter schmelzle · disk · art · pics · lit · @ · 22:05, 3. Jan. 2013 (CET) (das o.g. Vandalismus-Argument zieht nicht)

   Warum nicht? --TMg 22:26, 3. Jan. 2013 (CET)

   Weil Kennzahlen dieser Größenordnung nichts über die Qualität und Art der Beobachtung aussagen. 20 Beobachter können inaktiv, Sockenpuppen oder Ahnungslose sein, 1 Beobachter kann megaaktiv und fachkundig sein.-- · peter schmelzle · disk · art · pics · lit · @ · 22:52, 3. Jan. 2013 (CET)

   Aber 0 ist definitiv unbeobachtet. Dieser Logik zufolge müsstest du mindestens für 1 2 stimmen. --TMg 23:27, 3. Jan. 2013 (CET)

   0 oder 1 ist in dieser Hinsicht gleichbedeutend, weil beim Schwellenwert 1 die Nichtanzeige bedeutet, dass es 0 Beobachter sind. Aber gerade mit dem Wissen um das Nichtbeobachtetsein des Artikels können sich Benutzer mit guten Absichten derartige Artikel gezielt auf ihre Beobachtungsliste nehmen oder diese Diskussionsseite links liegen lassen. --YMS (Diskussion) 11:32, 4. Jan. 2013 (CET)

   Das ergibt doch gar keinen Sinn. Für 1 zu stimmen kann nur bedeuten, dass 0 und 1 ununterscheidbar angezeigt werden. --TMg 13:26, 4. Jan. 2013 (CET)

   Hmm? In dieser Abstimmung für 1 zu stimmen heisst, dass die Anzahl der Beobachter angezeigt werden soll, sobald mindestens einer die Seite beobachtet. Also wird ausschliesslich bei null Beobachtern nichts angezeigt. --YMS (Diskussion) 13:45, 4. Jan. 2013 (CET)

   Und da genau das nicht den geringsten Sinn ergibt, muss ich davon ausgehen, dass eine Stimme für 1 bedeutet, dass 0 und 1 ununterscheidbar angezeigt werden sollen (außer jemand sagt es ausdrücklich dazu, wie Schnark oben). --TMg 13:55, 4. Jan. 2013 (CET)

   Die Software zeigt (die Frage stelltest du im Bearbeitungskommentar) ab >= Grenzwert an (ich habe unten auch den Code zitiert), und genau so steht das auch in dem WP:NEU-Eintrag, der Anlass dieser Diskussion ist und oberhalb der Abstimmung zitiert ist. Ich sehe da keinerlei Interpretationsspielraum. --YMS (Diskussion) 14:01, 4. Jan. 2013 (CET)

   Meine Frage bezog sich auf das Tool. Hier war überall von einer „Schwelle“ die Rede (habe ich jetzt etwas entschärft), und „Schwelle“ heißt für mich, dass diese überschritten werden muss. --TMg 14:07, 4. Jan. 2013 (CET)

   Der Vollständigkeit halber: Auch das Tool zeigt laut dessen Doku bei >= 30 an ("Pages with fewer than 30 watchers will be listed with a em dash"). --YMS (Diskussion) 14:11, 4. Jan. 2013 (CET)

4. 0 -- Chaddy · D – DÜP – 22:57, 3. Jan. 2013 (CET)
5. 0 --Iste (D) 00:13, 4. Jan. 2013 (CET)
6. 0 --32X → Autorenngilde № 1 01:53, 4. Jan. 2013 (CET)
7. 0 --USt (Diskussion) 11:33, 4. Jan. 2013 (CET) Vielleicht werden dann unbeobachtete Seiten verstärkt in Beobachtungslisten aufgenommen.
8. 0 --Tobias1983 _{Mail Me} 11:34, 4. Jan. 2013 (CET)
9. 0 --Berita (Diskussion) 11:46, 4. Jan. 2013 (CET) Nützliche Information. Die meisten Vandalen werden sich mE nicht die Mühe machen, danach zu schauen und wenn doch, greift das Sichtungsprinzip.

   und womit kannst du es belegen? -jkb- 14:29, 4. Jan. 2013 (CET)

   Ich kann natürlich nichts belegen, was in der Zukunft liegt. Das ist nur meine persönliche Meinung, die sich auf Beobachtungen der bisherigen Vandalismusbekämpfung stützt. Aber sollten sich wirklich Probleme durch die uneingeschränkte Anzeige der Beobachter ergeben, kann man sie ja auch wieder ändern.--Berita (Diskussion) 14:53, 4. Jan. 2013 (CET)

10. 0 --Ne discere cessa! ^Kritik/Lob 11:48, 4. Jan. 2013 (CET) Das Vandalismus-Argument ist praxisfern.
11. nilzéronull --Wwwurm Mien Klönschnack 13:04, 4. Jan. 2013 (CET)
12. 0 --Etmot (Diskussion) 13:07, 4. Jan. 2013 (CET)
13. −10 —[ˈjøːˌmaˑ] 13:08, 4. Jan. 2013 (CET) Nur aus Neugier, was die Software dann macht

    Na was wohl? Die Anzahl der Beobachter wird angezeigt, wenn folgende Bedingung wahr ist: $user->isAllowed( 'unwatchedpages' ) || ( $wgUnwatchedPageThreshold !== false && $pageCounts['watchers'] >= $wgUnwatchedPageThreshold ), also sobald mindestens -10 Leute eine Seite beobachten, also immer. --YMS (Diskussion) 13:42, 4. Jan. 2013 (CET)

14. 0 -Derschueler 13:42, 4. Jan. 2013 (CET) per Berita; Spezial:Unbeobachtete Seiten sollte einsehbar sein

    +1 zu Spezial:Unbeobachtete Seiten. Grüße — Alleskoenner (Diskussion) 13:58, 19. Jan. 2013 (CET)

15. 0 (aber auch jeder andere Wert, der niedriger ist als bisher) --Tets 14:28, 4. Jan. 2013 (CET)
16. 0 --Panter Rei Πφερδ 15:13, 4. Jan. 2013 (CET)
17. 0 --Ijbond (Diskussion) 15:17, 4. Jan. 2013 (CET)
18. 0 --Alex (Diskussion) 16:23, 4. Jan. 2013 (CET) Einfach aus Optimismus heraus: ich spekuliere, dass die technische Hürde unbeobachtete Artikel aufzufinden immer noch so hoch bleibt, dass eher im Umgang mit dem Projekt Erfahrene davon profitieren als dass Vandalen diese Information missbrauchen. Notfalls auf Sichter einschränken.
19. 0 --Austriantraveler (Diskussion) 17:18, 4. Jan. 2013 (CET) Ich glaube, die meisten Vandalen werden dann von dieser Funktion sowieso nicht allzu oft wissen. Für Autoren ist es aber auch oft interessant, wer noch den Artikel beobachtet! Von mir aus kann die Funktion auch nur für Sichter freigeschalten werden
20. 0 --BuschBohne 18:00, 4. Jan. 2013 (CET)
21. --Brainswiffer (Diskussion) 18:12, 4. Jan. 2013 (CET) Offenheit!
22. 0 --Nyan ∗ Dog 19:43, 4. Jan. 2013 (CET)
23. --Sinuhe20 (Diskussion) 20:29, 4. Jan. 2013 (CET)
24. 0 --sitic (Diskussion) 20:49, 4. Jan. 2013 (CET) Vandalismus wird eher durch die gesichteten Versionen und RC verhindert, Sichter können jetzt schon diese Zahl von Seiten auf der BEO herausfinden, man kann ggf. auch einfach die aktuelle Sichtung entfernen und schon taucht die gewünschte Seite dort auf. Ansonsten AGF, siehe nachfolgende Begründung von KaiMartin. --sitic (Diskussion) 18:51, 7. Jan. 2013 (CET)
25. 0 ---<)kmk(>- (Diskussion) 22:05, 4. Jan. 2013 (CET) Das Wikiprinzip nachdem wir hier die mit Abstand beste Enzyklopädie aller Zeiten auf die Beine gestellt haben, beruht im Kern auf einem globalen AGF. Mit diesem Geist ist ein Verstecken auf Grund einer vermuteten Missbrauchsproblematik nicht kompatibel. Wenn sich herausstellen sollte dass die Befürchtungen berechtigt waren, kann man die Schwelle jederzeit wieder höher drehen. Auch damit haben wir schon gute Erfahrung. Siehe die gesichteten Versionen.
26. 0 --Carport ^{(Disk. • ± • MP)} 22:07, 4. Jan. 2013 (CET)
27. 0 --PD70 (Diskussion) 23:02, 4. Jan. 2013 (CET)
28. 0 --LeastCommonAncestor (Diskussion) 23:16, 4. Jan. 2013 (CET)
29. 0 --CENNOXX 00:00, 5. Jan. 2013 (CET) Bisher kann man sich bei Artikeln ja nur umständlicherweise damit behelfen, dass man den Artikel entsichtet & die ungesichteten Artikel der Beobachtungsliste anschaut. (Ergänzung: Sichter 0, Rest meinetwegen 30.--CENNOXX 19:41, 18. Feb. 2013 (CET))
30. 0 --Tommes (D) 01:07, 5. Jan. 2013 (CET) wie kmk; und weil mich die (A)-Quote von derzeit 10/14 bei der Meßlatte von 30 schaudern läßt
31. 0, denn ich möchte schon wissen wer mir folgt. Gruß, Elvaube^?! 03:42, 5. Jan. 2013 (CET)

    Das Tool zeigt nicht an wer einen Artikel beobachtet, sondern wieviel User einen Artikel beobachten. --Engie 12:45, 5. Jan. 2013 (CET)

32. 0, weil Transparenz eher weiterführt. — Filoump 09:35, 5. Jan. 2013 (CET)
33. 0 --Hoff1980 (Diskussion) 11:58, 5. Jan. 2013 (CET)
34. 0 --Biha (Diskussion) 14:01, 5. Jan. 2013 (CET)
35. 0 --Tommy Kellas (Diskussion) 15:00, 5. Jan. 2013 (CET)
36. 0 - zumindest für alle Sichter, denn das ist für Bearbeiter schon eine interessante Info. Wer vandalieren will kann jetzt schon gezielt auf Spezial:Seiten mit ungesichteten Versionen nachschauen. Wenn es tatsächlich zu Problemen kommen sollte kann man das immer noch wieder hochfahren. d65_{sag's mir} 16:28, 5. Jan. 2013 (CET)
37. 0 --ChristianSW (Diskussion) 17:46, 5. Jan. 2013 (CET) wie d65
38. --Stillhart 18:14, 5. Jan. 2013 (CET)
39. 0 --BlueCücü (Diskussion) 18:29, 5. Jan. 2013 (CET) (Gleichzeitig den Fachportalen unbeobachtete Artikel ihres Fachbereichs per Bot regelmäßig listen. Dann können Portalmitarbeiter über "Änderungen an verlinkten Seiten" diese Artikel im Auge behalten oder auf ihre Beo nehmen. Vorher müsste jedes Portal angeben für welche Kats es sich mitverantwortlich fühlt. Das müsste doch bot-bar sein, oder?)
40. 0 --Janjonas (Diskussion) 18:32, 5. Jan. 2013 (CET) Nach meiner Erfahrung ist bei den Seiten mit ungesichteten Versionen nur selten echter Vandalismus dabei, sondern eher bei viel beobachteten Artikeln.
41. 0 --Emergency doc (Diskussion)^{≤≤RM≥≥} 21:38, 5. Jan. 2013 (CET)Vandalismus wird ja spätestens im Rahmen der Nachsichtung auffallen.
42. 0 --Rauenstein 22:20, 5. Jan. 2013 (CET) Das Sichten war von Beginn an eine Totgeburt, sodass es völlig egal ist, wer sieht, wieviele Seiten von wievielen Nutzern beobachtet werden.
43. --Ehrhardt (Diskussion) 23:41, 5. Jan. 2013 (CET)
44. 0 --Tschaensky (Diskussion) 23:47, 5. Jan. 2013 (CET)
45. --$TR8.$H00Tα ^{talk} 00:19, 6. Jan. 2013 (CET)
46. 0 --Paramecium (Diskussion) 00:53, 6. Jan. 2013 (CET) siehe Dietzel65
47. 0 --Bobo11 (Diskussion) 11:56, 6. Jan. 2013 (CET) Wird beobachtet oder wird nicht beobachtet. Ist für mich als Aussage wichtiger als eine Zahl X Beobachter. Denn als Zahl alleine sagt mir das eh nichts über die Qualität der Beobachtung. Dafür müsst ich wissen wer, und das beisst sich hoffentlich mit unseren Datenschutzrichtlinien.--Bobo11 (Diskussion) 11:56, 6. Jan. 2013 (CET)

    ich sach mal einfach: Einer wird wohl meist der Autor sein, egal, ob er noch aktiv ist oder nicht--se4598 / ? 21:22, 6. Jan. 2013 (CET)

48. 0 für sichter, für alle anderen 20 oder 30, aber immer auf aktive benutzer bezogen --Wetterwolke (Diskussion) 12:11, 6. Jan. 2013 (CET)
49. --W.E. Disk 12:13, 6. Jan. 2013 (CET)
50. 0 --Mäx 12:40, 6. Jan. 2013 (CET) Das man dadurch Vandalismus in unbeobachteten Artikeln fördert ist schwachsinn, wir haben eine funktionierenden RC-Bereich. Bei Hilfe- bzw. Metaseiten ists eh wurscht, da es dort auch keine Sichtungsfunktion gibt. --Mäx 12:40, 6. Jan. 2013 (CET)
51. 0 --CiMa 15:22, 6. Jan. 2013 (CET)
52. 0 --Aendy ^{ᚱc ᚱн} 18:30, 6. Jan. 2013 (CET)
53. --Singsangsung ^{Los, frag mich!} 20:28, 6. Jan. 2013 (CET)
54. 0 --Schelm (Diskussion) 20:44, 6. Jan. 2013 (CET)
55. -- ΠЄΡΉΛΙʘ 22:16, 6. Jan. 2013 (CET)
56. --Svíčková na smetaně 22:22, 6. Jan. 2013 (CET) 0 für Sichter, Rest ziemlich egal (bis man auf dem Stand ist sowas brauchen zu können sollte man normalerweise die Sichterrechte eh schon haben)
57. --Hepha! ± ion? 23:08, 6. Jan. 2013 (CET) GSV schlagen VAND-Argument
58. 0. Bernhard Wallisch 08:28, 7. Jan. 2013 (CET)
59. --Tuttist ^waswotsch? 08:47, 7. Jan. 2013 (CET)
60. 0. --styko 10:15, 7. Jan. 2013 (CET)
61. 0. --SDI Fragen? 10:22, 7. Jan. 2013 (CET)
62. 0. --Ghilt (Diskussion) 11:04, 7. Jan. 2013 (CET)
63. 0 für Sichter --Trigonomie - ☎ 13:07, 7. Jan. 2013 (CET)
64. 0 für Sichter--Roland1950 (Diskussion) 13:32, 7. Jan. 2013 (CET)
65. 0. --Reinhardhauke (Diskussion) 14:20, 7. Jan. 2013 (CET)
66. 0 Gemäß Wikiprinzip sollte jeder alle diese Informationen abrufen dürfen. --Martin1978 ^☎/_± 15:23, 7. Jan. 2013 (CET)

    Also auch deine komplette Beobachtungsliste, deine E-Mail-Adresse und dein Passwort? --TMg 19:08, 12. Jan. 2013 (CET)

    (BK) Nee, kritischere Infos werden nie allen zugänglich gemacht. Meistens können sie sogar nur Admins einsehen, weshalb das auch in diesem Fall so war. So kann ich weder irgendeine aus welchen völlig normalen Gründen (z. B. fehlende Relevanz, normaler Vandalismus, usw.) gelöschten Versionen einsehen noch die Details und Einstellungen der meisten nicht-öffentlichen Missbrauchsfilter. Ich weiß ja nicht mal, ob auf meiner BD oder irgendeiner meiner Benutzerseiten einer dieser Missbrauchsfilter gegen meinen Willen geschaltet ist. Wikiprinzip ist das also ganz klar nicht, selbst dann nicht, wenn es dafür keine zwingenden rechtlichen Gründe gibt wie bei URVs. Dann sollte man erst mal die geheimen Missbrauchsfilter veröffentlichen, die ja nicht mal die Sichter einsehen können. --Geitost 19:09, 12. Jan. 2013 (CET)

    Ich halte es im Übrigen für wesentlich intransparenter als diese doch auch für Sichter relativ nebensächliche, wenig aussagekräftige (und eher unbrauchbare bis schädliche als nützliche) Zahl der Beobachter, dass jeder Admin jederzeit irgendeinen geheimen MBF auf welche Seiten auch immer schalten kann und Seitenbearbeitungsverbote für Neulinge oder welche Benutzer auch immer aussprechen kann, ohne dass man davon weiß, selbst die davon betroffenen normal mitarbeitenden Benutzer nicht. Und es wäre viel sinnvoller, wenn man mal gegen das Gemauschel dort etwas unternehmen würde. Das macht mir nämlich richtige Bauchschmerzen. Dass man sich aber stattdessen hier nun derart auf diese Zahl fokussiert, ist mir recht unverständlich. --Geitost 19:21, 12. Jan. 2013 (CET)

    Das ist meine Meinung, Punkt aus. Da gibt es nichts zu diskutieren. Möglicherweise hab ich mich etwas unglücklich ausgedrückt. Aus diesem Grund habe ich meinen Kommentar etwas modifiziert. --Martin1978 ^☎/_± 23:13, 15. Jan. 2013 (CET)

67. 0 darkking3 ^Թ 15:49, 7. Jan. 2013 (CET) Für Sichter, Autoconfirmed reicht da m.M. nach nicht

    Hier gehts um den Wert für alle Benutzer, auch IPs. Für Sichter müsste ein extra MB für das unwatchedpages-Recht her. --Steef ³⁸⁹ 19:52, 7. Jan. 2013 (CET)

    Ich bezweifle, dass alle für diese Option Stimmenden dies für alle Benutzer wollen. --Leyo 20:00, 7. Jan. 2013 (CET)

68. 0 für alle. -- TZorn 16:40, 7. Jan. 2013 (CET) Das ist Wikiprinzip. Für großen Missbrauch seh ich keine Anzeichen.
69. 0 --  Sir Gawain Disk. 21:12, 7. Jan. 2013 (CET)
70. 0 --† Alt ♂ 22:47, 7. Jan. 2013 (CET)
71. 0 --Naboo N1 Starfighter^{( Time to fight?- Abschüsse)} 23:17, 7. Jan. 2013 (CET)
72. 0 --Nordlicht↔ 10:24, 8. Jan. 2013 (CET) weil Vandalen nicht irgendwelche Artikel aufsuchen, dort in der Seiteninfo schauen, wieviele Beobachter es gibt und dann gezielt vandalieren. Viel zu aufwändig. Spezial:Ignorierte Seiten listet dagegen Angriffsobjekte übersichtlich auf und ist daher ein ganz anderes Kaliber und somit nicht vergleichbar. Nutzen überwiegt Gefahr.
73. 0 für Benutzer mit Sichterrecht, 20 oder 30 (egal) für die anderen. --Joyborg 14:25, 8. Jan. 2013 (CET)
74. 0, seit den Sichtungen besteht ohnehin kein akutes Problem mehr. Da wird nun etwas als problematisch angesehen, was es nämlich gar nicht ist. --Micha 15:36, 8. Jan. 2013 (CET) Übrigens bin ich überzeugt, dass genau die Offenlegung dieser Daten dazu führen würde, dass viele aktive Wikipedianer gezielt wenig bis nicht beobachtete Artikel unter die Fittiche nehmen. Bei mir wäre das jedenfalls so. Diese Offenlegung hat deshalb einen positiven Effekt und stimmt auch ganz mit dem Wikiprinzip überein. --Micha 15:40, 8. Jan. 2013 (CET)
75. 0, ich sehe keinen Grund, dass dies nur die Admins sehen sollten. Ich beobachte meine Artikel zudem eh mit CatScan, und ich denke ich bin damit nicht der Einzige. fundriver _{Was guckst du?!} ^Winterthur! 16:14, 8. Jan. 2013 (CET)
76. 0 --Zweedorf22 (Diskussion) 19:22, 8. Jan. 2013 (CET)
77. 0 --Unukorno (Diskussion) 21:21, 8. Jan. 2013 (CET)
78. 0 --HylgeriaK (Diskussion) 23:41, 8. Jan. 2013 (CET)
79. 0 -- Geolina (Diskussion) 08:36, 9. Jan. 2013 (CET)
80. 0 --Voyager (Diskussion) 09:30, 9. Jan. 2013 (CET)
81. 0 --Aalfons (Diskussion) 13:37, 9. Jan. 2013 (CET) Vorteile überwiegen Nachteile
82. 0, soweit technisch möglich. --Hahnenkleer (Diskussion) 13:40, 9. Jan. 2013 (CET)Bei Artikeln mit wenigen Beobachtern ist die Ansage wesentlich wichtiger. Noch schöner wäre es, man wüsste auch, ob diese Beobachter auch aktive User sind, denn der Seite WP:Beitragszahlen kann man entnehmen, dass sehr viele angemeldete Benutzer schon lange inaktiv sind.
83. 0 --morty 13:57, 9. Jan. 2013 (CET) Security through obscurity funktioniert doch sowieso nicht.
84. 0, darauf warte ich schon lange. --Wikiwal (Diskussion) 14:16, 9. Jan. 2013 (CET)
85. 0, denn das Vandalismusargument zieht nicht. Die von niemandem beobachteten Seiten werden garantiert schnell auf viele Beo-Seiten gesetzt. --Schlesinger ^schreib! 22:15, 9. Jan. 2013 (CET)
86. 0 Graf Foto (Diskussion) 14:49, 10. Jan. 2013 (CET)
87. 0 --Se90 (Diskussion) 15:34, 10. Jan. 2013 (CET)
88. 0 -- HilberTraum (Diskussion) 21:05, 11. Jan. 2013 (CET) sollte man probieren. Falls es doch Probleme machen sollte, dann halt nur für Sichter.
89. 0 -- Milad A380 Disku 21:22, 12. Jan. 2013 (CET)
90. 0 --Rubinsky (Diskussion) 14:48, 13. Jan. 2013 (CET)
91. 0 --Rainyx (Diskussion) 17:28, 13. Jan. 2013 (CET)
92. 0 wie Svíčková. Agathenon Bierchen? 21:32, 13. Jan. 2013 (CET)
93. 0 --Zorbedit (Diskussion) 21:40, 13. Jan. 2013 (CET) Es wird sich keine nennenswerte Anzahl an Vandalen die Mühe machen, diese Liste zu durchsuchen. Dann gäbe es immer noch das Nachsichten.
94. 0 für Sichter --Jensibua (Diskussion) 22:02, 13. Jan. 2013 (CET)
95. 0 --WhoisWhoME (Diskussion) 23:13, 13. Jan. 2013 (CET)
96. 0 --LZ6387 Disk. Bewertung 17:31, 14. Jan. 2013 (CET)
97. 0 --an-d (Diskussion) 18:29, 15. Jan. 2013 (CET)
98. 0 --Askalan ^{Sprich Dich ruhig aus!} 13:36, 18. Jan. 2013 (CET)
99. 0 --Simon.hess (Disk, Bewerte mich!) 16:07, 18. Jan. 2013 (CET)
100. 0 --Lena1 (Diskussion) 17:55, 21. Jan. 2013 (CET) ein Mindestwert sollte nicht vorgegeben werden.
101. 0 --Nightfly | _Disk 10:52, 22. Jan. 2013 (CET) Für mehr Transparenz. Das Vandalismus-Argument zieht nicht
102. 0 --Qualiabavariae (Diskussion) 20:46, 22. Jan. 2013 (CET) für Sichter
103. --Wiki Gh! ^✉ 20:54, 24. Jan. 2013 (CET)
104. -- Miraki (Diskussion) 18:55, 27. Jan. 2013 (CET)
105. 0 --jed (Diskussion) 15:19, 28. Jan. 2013 (CET)
106. 0 --Frank C. Müller (Diskussion) 11:30, 4. Feb. 2013 (CET)
107. 0 --«««¤ ☼ ¤»»» 10:33, 8. Feb. 2013 (CET)
108. 0 --Brutus1972 (Diskussion) 18:23, 8. Feb. 2013 (CET)

Gar keine Anzeige der „Anzahl der Beobachter“

1. -- Leif Czerny 11:25, 5. Jan. 2013 (CET)

Einstellung vom Namensraum abhängig machen

Ich bin für eine relativ hohe Einstellung im Namensraum Artikel (20-30) und eine sehr hohe Einstellung im Namensraum Vorlagen (40+) Im Bereich Benutzer und Wikipedia kann die Einstellung gerne auch auf 0 gestellt werden. Bei Kategorie und Datei könnten 10-20 reichen. Frohes Schaffen, Boshomi ☕⌨☺ –  23:54, 22. Jan. 2013 (CET)

$wgAllowMicrodataAttributes

Auf meiner to-do-Liste steht seit einigen Wochen die Beantragung der Aktivierung von mw:Manual:$wgAllowMicrodataAttributes. Seit Gerrit:4251 live ist, wäre damit die Nutzung von <data>, <time>, <meta>, and <link> möglich. Würde uns das irgendwie helfen, z. B. bei einer maschinenlesbaren Attributierung von Dateien? — Raymond ^Disk. 11:14, 16. Feb. 2013 (CET)

Die Verwendung von <date> und <time> scheint mir einleuchtend. Wir würden das überall verwenden, wo es einigermaßen semantisch hin passt. Und natürlich würde es an noch mehr Stellen eingesetzt werden, an denen es nicht passt. Aber das ist kein Argument, es zurückzuhalten. Wir nutzen jetzt schon Mikroformate bspw. für Koordinaten und Literatur. Was das konkret bringt? Wahrscheinlich nicht viel. Es ist ein Angebot an externe Dienste, mehr erst einmal nicht.

Unverständlich ist mir noch, wie <meta> und <link> hier konkret funktionieren würden. Wäre das frei verwendbar und würde dann im <head> der Seite ausgeliefert werden? Was lässt sich damit realisieren? Auch prev- und next-Beziehungen zu anderen Artikeln? up? author-Angaben? Einbettung von Stylesheets und Favicons? Meta-Voodoo? Mir fallen da sehr viel mehr Möglichkeiten ein, es zu missbrauchen, als es nutzbringend zu verwenden. --TMg 21:24, 21. Feb. 2013 (CET)

meta muss itemprop und content haben und link muss itemprop und href haben, damit es im Wikitext gültig ist. data kann value als Attribut haben und time natürlich datetime. data und time kann auch jetzt schon verwendet werden (gleichzeitig mit mark), nur meta und link sind von der Variable betroffen. Vielleicht hilft dir das, beim erkennen, was damit möglich ist. Der Umherirrende 21:37, 21. Feb. 2013 (CET)

Danke. Nach Durchsicht des Changesets wird klar, dass damit nichts von dem möglich ist, was man von den Elementen kennt. Keine rel-Beziehungen, keine Einbettung von Stylesheets, kein SEO-Voodoo. Nur die itemprop-Variante. Dann würde ich wie oben argumentieren. Wenn wir Metadaten anbieten können, warum sollten wir das nicht tun? Was es konkret bringen wird, lässt sich kaum vorhersagen. Projekte, die das nutzen, wird es mit Sicherheit geben. Unklar ist mir noch, warum itemprop nicht überall erlaubt ist. --TMg 21:48, 21. Feb. 2013 (CET)

Der Gerrit-Beschreibung entnehme ich, dass man sich über Sicherheitsfragen Gedanken gemacht hat. Brav.

• whatwg.org linkservice
• <meta> nur mit itemprop= ist langweilig. Beträfe die gesamte Seite; interessiert unseren enzyklopädischen Detail-Inhalt nicht. Wir haben keine Syntax, mit der wir unbekannten Diensten mitteilen könnten, dass der Artikel den Kölner Dom betrifft und dass Köln eine Stadt in Germany und Dom eine church ist.
• Mit <link> und href= und itemprop= würden wir auf eine zentrale externe Seite verlinken, auf der etwas stehen würde. Auch das beträfe die gesamte Artikel-Seite; interessiert unseren enzyklopädischen Detail-Inhalt nicht. Dort würden wir feststellen, dass der Seiteninhalt ein Artikel der deutschsprachigen Wikipedia ist. Wozu?
• Heute schon kann man abhängig vom Inhalt itemprop= an jedes einzelne <div> und <span> dranhängen, wenn man ein Detail attributieren will.

Ich denke, wir sollten den Parameter abgeschaltet lassen, bis jemand explizit eine Verwendung und einen Bedarf darlegt.

Schönen Abend --PerfektesChaos 22:03, 21. Feb. 2013 (CET)

Namensraumübersetzung für Lua-Module

Wenn Lua hier aktiviert wird, dann werden die entsprechenden Module im neuen Namensraum mit dem englischen Namen "Module" erstellt. Sollten wir dann eine Übersetzung "Modul" und "Modul Diskussion" beantragen? (mw:Extension:Scribunto; Namensräume aus Extensions lassen sich nicht direkt im Translatewiki übersetzen) Der Umherirrende 19:33, 21. Feb. 2013 (CET)

Ja, bitte. Welche Nummer bekommt der Namensraum? --Krd 19:35, 21. Feb. 2013 (CET)

In der englischen Wikipedia haben sie 828 und 829 bekommen. Der Umherirrende 19:39, 21. Feb. 2013 (CET)

Wie wär es mit der Mehrzahl also »Module«? Ich mag so nahe Übersetzungen wegen der Gefahr falscher Freunde nicht. Falls »Module« hier nicht möglich ist, warum nicht gleich »Lua«? da wüsste man sofort worum es sich dreht.  Frohes Schaffen, Boshomi ☕⌨☺ –  20:55, 21. Feb. 2013 (CET)

Das englische könnte man auch als Plural verkaufen, da aber alle anderen Namensraumvarianten Singular sind, sollte das hier wohl auch so sein. Falsche Freunde sind möglich, anderseits ist Lua ja nur die Programmiersprache, Scribunto die Extension die das hier zur Verfügung stellt/integriert. Es sollte sich schon nah am englischen orientiert werden. Der Umherirrende 21:32, 21. Feb. 2013 (CET)

Es kommt auch eine neue Parserfunktion {{#invoke:}} hinzu, die bereits mit {{#aufrufen:}} im translatewiki übersetzt wurde. Der Umherirrende 19:43, 21. Feb. 2013 (CET)

Kurz meine Meinung: Namensräume sind seit 2001 alle übersetzt, da sollte auch dieser übersetzt und primär in seiner übersetzten Form verwendet werden. Die Übersetzung von Parserfunktionen halte ich für unnötig und werde sie wie jetzt schon bei den Vorlagen nicht verwenden. --TMg 20:55, 21. Feb. 2013 (CET)

Da nach fast einer Woche nichts weiter kam, habe ich "Modul" und "Modul Diskussion" mit gerrit:51207 vorgeschlagen. Der Umherirrende 21:09, 27. Feb. 2013 (CET)

Und Raymond hat es für gut befunden, danke, somit ist das jetzt irgendwie erstmal gesetzt. Danke für eure Kommentare. Der Umherirrende 21:16, 27. Feb. 2013 (CET)

create language-specific collations for category sorting

Gerrit:49776 sagt: create language-specific collations for category sorting. Hat gerade jemand der Mitleser einen Überblick, ob bzw. welchen Effekt das auf Wikis mit deutscher Sprache hat? — Raymond ^Disk. 15:24, 4. Mär. 2013 (CET)

Unter Hilfe Diskussion:Kategorien/Archiv/2#Automatisch korrekte Kategorie-Sortierung haben wir analysiert, wie die Aktivierung von UCA auswirkt und wie die Regeln für Kategorien-Sortierung angepasst werden müssen. --Fomafix (Diskussion) 15:33, 4. Mär. 2013 (CET)

Solange keiner mw:Manual:$wgCategoryCollation setzt, hat das keine Auswirkungen. Der Wert müsste uca-de sein, wenn den mal gewünscht. Der Umherirrende 19:48, 4. Mär. 2013 (CET)

Da ist schon was vorbereitet: Gerrit:51313. Aber eben noch im Review. — Raymond ^Disk. 08:33, 5. Mär. 2013 (CET)

Die einzige Änderung ist, dass wir uca-de möglicherweise auch ohne einen community consensus bekommen, den wir hier offenbar mangels Interesse nicht zustande bekommen. Rein technisch gesehen ist uca-de einfach nur ein Alias für uca-default, wie man an der gähnenden Leere in <collation type="standard"> sehen kann. --Schnark 09:08, 5. Mär. 2013 (CET)

Firefox-Extension – Tester gesucht

Ich habe ein Firefox-Addon erstellt, mit dem Ziel sehr schnell und bequem Kleinigkeiten wie Tippos direkt beim lesen eines Artikels zu korrigieren, ohne dazu die Bearbeitungsseite öffnen zu müssen. Somit wird der Lesefluss durch die Bearbeitung nur minimal gestört. Inzwischen läuft das Addon bei mir wunderbar und hat auch die Funktionen die ich mir davon erwartet haben (obwohl ich natürlich durchaus noch Verbesserungsideen habe). Da ich natürlich nicht jeden Fall durchprobieren kann suche ich Leute die das Add-on schon mal (vorsichtig) im "Produktivbetrieb" zu testen. Ihr findet das Tool hier. -- Michi 19:58, 13. Mär. 2013 (CET)

Unerwünschter Rand um Bilder in Tabellen seit wenigen Tagen

Hallo, mir ist aufgefallen, dass in allen Tabellen und deshalb auch in allen Infoboxen und Taxoboxen ein Padding von 0.2em um alle Bilder hinzugefügt wird, so dass die Tabellenzelle nicht mehr vollständig mit dem Bild gefüllt wird. Dieser Effekt tritt seit einigen Tagen auf, ohne dass der Code der Infoboxen geändert wurde. Weiß jemand, was da passiert ist? Es wäre schön, wenn das wieder rückgängig gemacht werden könnte. Es ist nicht zu schaffen, für jede einzelne Tabelle der WP einen Workaround zu schreiben. Gruß --Bürgerentscheid (Diskussion) 20:40, 13. Mär. 2013 (CET)

Inhaltsverzeichnis vor Einleitung?

Also mir hat die Vorderseite besser gefallen, als die Einleitung noch vor dem Inhaltsverzeichnis stand … Gruß --Schniggendiller Diskussion 20:15, 16. Mär. 2013 (CET)

+1, sieht sehr seltsam aus, so ganz ohne Einleitungstext. Der unkundige Nutzer sollte doch zumindest informiert werden, worum es auf der Seite geht. --Thogo 01:36, 17. Mär. 2013 (CET)

Nicht hauen *duck*, hab' das Inhaltsverzeichnis wieder an die alte Stelle gesetzt. — Raymond ^Disk. 08:34, 17. Mär. 2013 (CET)

Ich fand das eigentlich recht schön. Wir sollten unbedingt ein Meinungsbild durchführen;-) SCNR. --tsor (Diskussion) 09:33, 17. Mär. 2013 (CET)

Combining efforts to monitor and report noteworthy tech changes

Hallo. Entschuldigung für schreiben aus Englisch, aber mein Deutsch is sehr schlecht! I've started a discussion at m:Talk:Tech/Ambassadors#Noteworthy changes where I mentioned you, and it would greatly benefit from your participation. I'd appreciate if you could take a few minutes to share your thoughts there :) Danke schön! guillom (Diskussion) 18:23, 26. Mär. 2013 (CET)

Neues Icon

Seit ein Paar Tagen hat Wikipedia ein neues Favicon – ist das mit Version 1.22wmf1 gekommen und sollten wir das dann nicht in den Projektneuheiten erwähnen? -- Michi 17:09, 12. Apr. 2013 (CEST)

Huch, noch gar nicht gemerkt. Es besteht kein Zusammenhang mit der Version 1.22wmf1, sondern es handelt sich um eine Änderung der Serverkonfiguration: (Bug 15716) Update wikipedia favicon. Ob es für die Vorderseite wichtig ist? Entscheiden doch die Mitleser :-) — Raymond ^Disk. 19:35, 12. Apr. 2013 (CEST)

Na ja, der einzige Unterschied zum alten Favicon dürften die abgerundeten Ecken sein. Ich habe es auch erst gerade bemerkt, wie es viele andere sicherlich erst jetzt oder gar nicht bemerken. Daher halte ich es nicht für so wichtig, um es umseitig zu erwähnen. IW 20:58, 12. Apr. 2013 (CEST)

Habs gleich bemerkt und grad hier die Info gesucht… Das W wurde ein bisschen geschrumpft, im Vergleich zum alten Icon siehts aus wie ein kleines w.--CENNOXX 00:29, 13. Apr. 2013 (CEST)

Welches der Ws? Unten oder oben? Ich seh überhaupt keinen Unterschied irgendwo, wo ist denn das alte Logo zum Vergleich? --Geitost 15:32, 13. Apr. 2013 (CEST)

Ach so, jetzt hab ich’s auch kapiert; es geht gar nicht um das Logo oben links, sondern die Browserzeile (ich hätte doch gleich auf den Link „Favicon“ klicken sollen). Aber irgendwas Abgerundetes seh ich da auch nicht. Kleiner (im Vergleich zur URL daneben) kann aber hinkommen. --Geitost 15:37, 13. Apr. 2013 (CEST)

In den Tabs sieht es aus wie eh und je, da seh ich auch gar keinen Unterschied. --Geitost 15:40, 13. Apr. 2013 (CEST)

Was du wohl siehst, ist das Icon mit 16×16 Pixeln wie schon Jahre zuvor; und das „W“ hat sich meiner Wahrnehmung nach nicht verändert.

Neu ist, dass in der Datei jetzt auch eine Version 32×32 enthalten ist. Ich weiß allerdings nicht, welchen Browser man wie platzvergeudend einstellen muss, um einen Icon der Größe 32×32 Pixel zur Beschriftung von Tabs zu verwenden.

Richtig ist, dass die vier Pixel an den Ecken der 16×16 nunmehr transparent sind; dadurch erscheint es rund. So sei es.

Eine weltbewegende Software-Neuheit ist das grad nicht.

Schönes Wochenende --PerfektesChaos 15:46, 13. Apr. 2013 (CEST)

Ach so, dann geht es nicht um Rundungen beim W selbst (also die W-Kanten oben und unten, sondern das Icon (Logo) ist nur in den Tabs gerundet, denn in der Browserzeile ist ja nur das W und alles drumherum weiß. Das weiße Gerundete seh ich wohl, dachte aber, es sei immer schon so gewesen – hab ja auch keinen Vergleich zur alten Version. Eine weltbewegende Änderung ist das sicher nicht, eher so was wie eine grafische Spielerei. ;-) --Geitost 16:04, 13. Apr. 2013 (CEST)

MediaWiki:Pageinfo-footer

Sollte man diese unter Seiteninformation erscheinenden Links nicht NR-abhängig anzeigen? Benutzer- und Diskussionsseiten haben beispielsweise keinen Wikidata-Eintrag. Schön wäre ev. auch, die Links bei (noch) nicht vorhandenen Seiten nicht anzuzeigen. Meinungen? --Leyo 02:15, 17. Apr. 2013 (CEST)

Ich habe mal etwas Vorlagenprogrammierung eingebaut. Sieht bei mir erstmal passend aus. Der Umherirrende 21:04, 24. Apr. 2013 (CEST)

Neue Anmeldeseiten

Wie ist das den mit unseren Warnhinweis MediaWiki:Signupstart bzw. MediaWiki:Signupend? Wird darauf verzichtet oder kann man die in einer anderen Form in das neue Design einbringen? Ansprechender u.a. für "editor engagement" ist natürlich die schönen neuen "benefits" rechts neben dem Formular.--se4598 / ? 14:05, 30. Apr. 2013 (CEST)

zumindest uselang=qqx zeigt keine Seiten an, auf denen zusätzliche Hinweise angebracht werden könnten. IW 15:05, 30. Apr. 2013 (CEST)

Siehe hierzu meinen Bug 47883 und den Kommentar von Steven darin. — Raymond ^Disk. 19:40, 1. Mai 2013 (CEST)

Danke für das Erkundigen. Wenn man meint, dass ein Link auf Hilfe:Benutzerkonto anlegen ausreicht, OK. Ich würde mir auch aber ein bisschen mehr (Inline)Hilfe in Bezug auf die technischen Beschränkungen wünschen, z.B. Warnen beim Kleinschreiben des Benutzernamens oder eine mehr konkretere Fehlermeldung beim Eingeben ungültiger Zeichen (@)/ungültiger Namen. Ich nehme an, das mw:Account creation user experience die Projektseite ist. Mal schaun, was mw:/Bugzilla zu meinen Ideen findet.--se4598 / ? 20:58, 1. Mai 2013 (CEST)

Vom Druck ausschließen kaputt

Hat jemand eine Idee, warum sich im PDF-Export nichts mehr ausklammern lässt? Es funktionierte mal, aber jetzt nicht mehr. Ich dachte erst, es würde an dieser Umbenennung liegen, aber die wurde korrekt nachgeführt. Meinem Test zufolge hat die englischsprachige Wikipedia das selbe Problem. --TMg 18:43, 1. Mai 2013 (CEST)

Der QS-Hinweis auf Sparkasse Meißen wird mir im PDF-Export nicht angezeigt. Oder geht es nicht um Vorlagen? Gruß, IW 19:11, 1. Mai 2013 (CEST)

Die Frage kommt von Vorlage Diskussion:ImDruckVerbergen. Die geht nicht mehr. Beispiel: Spezial:Permanenter Link/115709303. --TMg 01:44, 3. Mai 2013 (CEST)

Wenn ich mir den Quelltext anschaue, kann diese Vorlage gar nicht funktionieren. Zum Ausschließen vom Druck ist mE die CSS-Klasse noprint erforderlich. Onlyinclude ist da völlig wirkungslos. IW 18:11, 3. Mai 2013 (CEST)

Die Vorlage funktionierte bisher, weil sie in der Ausschluss-Kategorie steht und die Kategorie wiederum per MediaWiki:Coll-exclusion category title konfiguriert ist. Das hatte zumindest bisher nichts mit CSS zu tun. --TMg 18:56, 3. Mai 2013 (CEST)

bugzilla:48052. --TMg 19:11, 3. Mai 2013 (CEST)

This Month in GLAM: April 2013

This Month in GLAM – Volume III, Issue IV, April 2013 Headlines From the team: Some personal thoughts on GLAM Australia and New Zealand report: Wikipedia in academia and libraries in Australia Denmark report: Upcoming Edit-a-thon 1864 Finland report: WLPA; GLAM Sessions; Funding France report: Brest Germany report: Hamburg Museum; Museum August Kestner Hungary report: Article writing contest about statistics and related sciences Italy report: Wikipedia workshop; Editathon on women's biographies Mexico report: Fotofestín activities; DIY scanner project progress and Winners of the Holy Week in Mexico photo contest at ITESM Campus Ciudad de Mexico Netherlands report: GLAM WIKI UK; Wiki loves Sound; Wikipedian in Residence; Wiki loves Libraries; Wikipedia Training National Museum of Ethnology Spain report: Longest edit-a-thon ever at Fundació Joan Miró in Barcelona Sweden report: GLAM handbook version 3; conferences; hackathons and Wiki Loves Public Art Switzerland report: Swiss Federal Archives looking for a Wikipedian in Residence Taiwan report: Taiwan Government Data Portal Launched UK report: GLAM-Wiki; new and departing Wikipedians in Residence USA report: First GLAM Boot Camp; Consortium meeting; GLAMout; plus workshops and editathon Special story: Intersections between GLAM and Wikinews Open Access report: Featured content; Wikimania sessions Calendar: May's GLAM events Read this edition in full • Single-page To assist with preparing the newsletter, please visit the newsroom. Past editions may be viewed here.

Unsubscribe · Global message delivery 23:48, 8. Mai 2013 (CEST)

Heutige Meldung zum SUL

Hallo, kann jemand bitte nochmal die heutige Meldung erläutern? Ich verstehe sie nicht! Besten Dank und schönen Abend, --Stefan »Στέφανος« ‽ 21:33, 9. Mai 2013 (CEST)

Demnächst werden lokale Konten globalisiert. Dabei ist es sinnvoll, Konten desselben Nutzers zusammenzuführen. Das kann geschehen, wenn zwei oder mehr gleichnamige Konten dieselbe Mail-Adresse und/oder Passwort haben. Ersteres kann automatisch gemacht werden, zweiteres nicht, weil die Passwörter im System nicht im Klartext vorliegen, sondern einwegverschlüsselt. Beim Anmelden gibt der Nutzer sein Passwort im Klartext an, so dass es gegen andere gleichnamige Konten geprüft werden kann und im Erfolgsfall dem SUL hinzugefügt werden kann. --Raketenchirurg (Diskussion) 10:08, 10. Mai 2013 (CEST)

Schau doch auch noch bei Hilfe:Single-User-Login/Finalisierung vorbei. Grüße, —DerHexer (Disk., Bew.) 10:12, 10. Mai 2013 (CEST)

Ah, alles klar. Ich hatte nur die umseitige Formulierung nicht durchdrungen. Danke. --Stefan »Στέφανος« ‽ 20:28, 10. Mai 2013 (CEST)

Spezial:In der Nähe

Funktioniert die neue Spezialseite Spezial:In der Nähe bereits ordnungsgemäß? Bei mir bleibt sie nämlich leer mit dem Hinweis "Themen laden, die in deiner Nähe liegen". Das Englische Pendant en:Special:Nearby ist hingegen mit reichlich Inhalt gefüllt. --Patrick87 (Diskussion) 01:22, 17. Mai 2013 (CEST)

oben in der Adresszeile musst du auf das neue Icon am Anfang klicken, danach die Feststellung deines Standortes erlauben. Ich habe den Scheiß sofort für immer verboten. -jkb- 01:24, 17. Mai 2013 (CEST)

Ok, mein Fehler. Als ich es gestern versuchte hatte es auf der deutschen Seite wirklich noch nicht funktioniert. Heute hatte ich mein WLAN deaktiviert (und mangels GPS-Empfänger) somit keine Geolocation-Daten verfügbar. Also funktioniert jetzt einwandfrei! --Patrick87 (Diskussion) 01:26, 17. Mai 2013 (CEST)

P.S. Klar, datenschutztechnisch ist sowas ein Albtraum, aber dafür fragt der Browser (zumindest der Firefox) ja jedes mal nach. Ich möchte jedoch gar nicht erst wissen was da manches Smartphone treibt (für die die Funktion ja ursprünglich gedacht war). Allerdings finde ich die Implementation hier in der Wikipedia wirklich gelungen, endlich mal eine Anwendung wo die Geodaten wirklich Sinn machen (hab auf Anhieb ein paar Artikel aus meiner Umgebung gefunden, auf die ich anders nie gestoßen wäre). --Patrick87 (Diskussion) 01:32, 17. Mai 2013 (CEST)

Mir gefällt diese Seite auch. Und man kann gleich noch bilderlose Artikel in der Nähe finden. :) --Stefan »Στέφανος« ‽ 01:41, 17. Mai 2013 (CEST)

Das Tool speziell dafür auf dem Toolserver http://toolserver.org/~magnus/wikishootme/index.html kennst Du? Es zeigt places nearby that have articles on Wikipedia but no images yet auf einer beliebigen Wikipedia-Sprachversion. Gruß, --emha ^d|^b 18:16, 17. Mai 2013 (CEST)

Oh, danke. Ich glaube, das ist mir mal irgendwie untergekommen, aber aktiv kannte ich es nicht. Wobei sich, gerade unterwegs, ja special:nearby leichter merken lässt. Vielleicht könnte man einen entsprechenden Filter auf der Spezialseite einbauen. Grüße --Stefan »Στέφανος« ‽ 18:27, 17. Mai 2013 (CEST)

Ich finde die Funktion klasse. Was mir aber noch fehlt (oder was es gibt und ich weiß nicht, wie ich es anstellen muss), wäre, dass man der Spezialseite beliebige Koordinaten mitgeben kann, so dass man zum Beispiel einen festen Link auf "Orte in der Nähe von Helgoland" setzen könnte. --::Slomox:: >< 08:54, 17. Mai 2013 (CEST)

Wie sieht das ganze datenschutzrechtlich ab? Wird mein Standort dann den Wikimedia-Servern übermittelt? Könnte man diese im Falle eines Falles ermitteln? --Filzstift ✎ 08:59, 17. Mai 2013 (CEST)

Laut Aussage auf der englischen Wikipedia von einem WMF-Mitarbeiter wird der Standort gar nicht an die Wikimedia-Server übermittelt. Ob das stimmt und wie das genau geht (denn dann müssten die gesammelten Koordinaten ja an den Browser übermittelt werden) kann ich jedoch nicht sagen. --Patrick87 (Diskussion) 11:18, 17. Mai 2013 (CEST)

Die Aussage ist wohl falsch. Der Browser schickt ein GET mit den Koordinaten an den Server. Ob der Server das speichert, ist eine andere Frage, aber ankommen tun die Koordinaten da. Bei mir sah das grad so aus: GET /w/api.php?format=json&action=query&colimit=max&prop=pageimages%7Ccoordinates&pithumbsize=180&pilimit=50&generator=geosearch&ggscoord=51.045925%7C7.01922&ggsradius=10000&ggsnamespace=0&ggslimit=50 HTTP/1.1. Hier mal ein halbwegs lesbares Beispiel für Helgoland. -- TZorn 12:07, 17. Mai 2013 (CEST)

Die Aussage ist schon richtig, allerdings ist die Formulierung unglücklich. Allein der Browser weiß, wo du dich befindest. Erst wenn du die Erlaubnis gibst, schickt dieser eine Anfrage mit diesen Koordinaten (oder mit beliebigen, wenn man weiß, wie man seinen Browser manipuliert). Wikipedia erfährt also nur die Koordinaten, wenn man die Erlaubnis gibt, und kann sich (theoretisch) nicht sicher sein, dass es auch die eigene Position ist. Das Ziel der Aussage war wahrscheinlich zu zeigen, dass nur der Wille des Benutzers zur Bestimmung der Position zählt, und nicht andere Möglichkeiten zur Positionsbestimmung, wie zum Beispiel die IP, benutzt werden. --Steef ³⁸⁹ 12:41, 17. Mai 2013 (CEST)

Könnte ein Admin Spezial:In der Nähe noch auf Spezial:Spezialseiten auflisten? Grüße sitic (Diskussion) 16:52, 17. Mai 2013 (CEST)

Die Liste der Spezialseiten wird automatisch erstellt und kann nicht verändert werden. --\m/etalhead ✉ 16:57, 17. Mai 2013 (CEST)

Tipp: Wer die Seite auch vom heimischen Rechner aus sinnvoll verwenden will, obwohl er in einer Großstadt wohnt, wo die IP-Geolocation des Browsers versagt, kann das coole Firefox-Addon Geolocater verwenden. Eine Möglichkeit die Koordinate auf der Seite anzugeben wäre aber trotzdem sehr wünschenswert. -- Michi 17:22, 17. Mai 2013 (CEST)

Siehe dazu auch Wikipedia:Fragen zur Wikipedia#Schon gesehen?. --YMS (Diskussion) 17:38, 17. Mai 2013 (CEST)

Flow Portal

Was da Brandon Harris, Senior Designer der WMF, ankündigt, ist möglicherweise der etwa zwei/drei Jahre alte Gedanke in dieser Richtung - keine Ahnung. Es bringt mich aber dennoch zu einem großen Meckern: die Foundation hat bekanntlich Geld genug, um diverse Wikimanias mit Unterkunft- und Flugsubventionen zu organisieren. Offenbar hat sie aber nicht genug, um für so ein Projekt, das die künftige Arbeitsweise von Zehntausenden von Benutzern sehr stark beeinflussen wird, ein paar Übersetzer zu finden, damit man nicht nur alles wie immer gehabt in Englisch serviert bekommt. Vor zwei Jahren habe ich auf Meta darüber diskutiert, etliche, auch damals noch Susan G. fanden es "sehr überlegenswert" und so weiter, nur damit die alte kacke unverändert weiterläuft. Oder findet das jemand normal? -jkb- 17:05, 16. Mai 2013 (CEST)

Nein. Ich kann nur hoffen, das wird nicht wieder so ein Flop wie Echo. Dabei fällt der gewohnte Benachrichtigungsbalken jetzt bereits in der en-WP weg, ohne dass ich irgendwas anderes stattdessen zu sehen bekomme, was ähnlich auffällig wäre. Was übrig bleibt, ist lediglich eine kleine Zahl oben zwischen den Links auf Benutzerseite und -disk., allerdings in Blau, also farblich nicht auffällig. Das wird natürlich übersehen, und dann muss man sich nicht wundern, wenn Benutzer auf Nachrichten nicht mehr reagieren. Aber natürlich alles ganz supertoll so. Es gibt sogar bereits einen Petitionsentwurf deswegen an die Stiftung in der en-WP, weil das mit den Neuerungen so bescheiden läuft. Oh, ich sehe, der Entwurf ist inzwischen fertig und es kann unterschrieben werden. --Geitost 17:39, 16. Mai 2013 (CEST)

Hm, das Design wurde doch inzwischen längst geändert:

Finde ich so eine akzeptable Anpassung. Aber wie WMF da mal so beiläufig und unbekümmert den Kackbalken entsorgt hatte, da kann man sich nur wundern - um es mal milde zu formulieren. Das mw:Flow Portal ist ein klarer Versuch, das zukünftig zu verbessern. --Atlasowa (Diskussion) 18:45, 16. Mai 2013 (CEST)

Ui, jetzt habe ich mir das mal kurz angeschaut – und rein gar nichts verstanden ;). Na ja, das kommt wohl daher, dass es mit der herkömmlichen Diskussionsseite nichts mehr zu tun hat. Solange das nicht wie LiquidThreads langsam dahinstirbt, sieht das ganz interessant aus. Mal sehen, was rauskommt, der Notifications-Balken (bis auf die teils unnötige JS-Nutzung) ist ja schon mal ein guter Anfang. Er sollte aber noch die Möglichkeit von globalen Benachrichtigungen erhalten, damit das Nachgeplapper von Diskussionsseitenänderungen per Mail endlich aufhört. IW 19:30, 16. Mai 2013 (CEST)

Ich stehe dem Projekt derzeit sehr skeptisch gegenüber. Habe gestern ebenfalls den "Interaktiven Prototypen" getestet und habe, wie du schon schreibst, erstmal rein gar nichts verstanden. Jetzt frage ich mich aber: Wenn ich (als mehr oder weniger erfahrener Nutzer) nichts verstehe, wie soll dann ein Neuling damit klar kommen? Ich hoffe das Projekt schießt nicht schnurstracks am Ziel vorbei. --Patrick87 (Diskussion) 19:36, 16. Mai 2013 (CEST)

Bekomme ich denn das neue Design auch zu Gesicht (wann wurde das geändert?) oder nicht? Bisher sah es ja offenbar so aus: en:User talk:Geitost#Juhu. Davon hab ich jedenfalls gar nichts gesehen. Ist das jetzt mit oder ohne Skripte? --Geitost 20:02, 16. Mai 2013 (CEST)

Mal nachgesehen: en:Wikipedia:Notifications/New message indicator#Resolution:

• „This new solution is now enabled as a JavaScript gadget by default for now, for final testing purposes.“

Also geht das auch nur mit Skripten, ändert sich also nix im Vergleich zu letzte Woche. :-( Tja, grundlegende Dinge gehen hier zunehmend nur noch mit Skripten, was für ein Fortschritt! --Geitost 20:12, 16. Mai 2013 (CEST)

Ich glaube dieser Stand ist veraltet, seit 14. Mai ist das obige Design Standard. Du kannst aber optional dieses Standard-gadget deaktivieren (notification preferences -> uncheck the box at the bottom), oder ein gadget aktivieren für den alten Kackbalken (gadget preferences -> "Display a floating alert when I have new talk page messages"), oder dir entsprechende user scripte installieren.

Was bei dem neuen Kackbalken aktuell noch fehlt, ist der direkte Diff-Link - daran wird gerade gearbeitet, siehe Bugzilla:48183. --Atlasowa (Diskussion) 00:31, 17. Mai 2013 (CEST)

Hauptsächlich fehlt weiterhin die Benutzbarkeit, die Barrierefreiheit. Ob nun altes oder neues Design ist schnurz, ich finde die neuen Nachrichten nur noch über die kleine blaue Ziffer oben in Klammern zwischen Benutzerseite und -disk. Das reicht aber nicht aus, damit Benutzer das sehen und darauf reagieren, wenn man das nicht zufällig bereits weiß und ab und zu dorthin schaut – so wie ich das jetzt mache. :-/ Neulinge finden die Zahl nicht und können damit auch nichts anfangen, denn es steht ja bei der Zahl nicht dabei, dass es sich um neue Nachrichten handeln könnte. Das muss man erst mal lernen. Die JS-Abhängigkeit sollte aufgehoben werden, nicht das Design geändert. Das bringt gar nix, null und nothing. --Geitost 15:03, 18. Mai 2013 (CEST)

Wenn das so in der Art hier lokal auch eingeführt werden sollte, dann gibt es ein Problem hier. Dann kann man sich nämlich nicht mehr wie heute darauf verlassen, dass die Nachrichten, die man Benutzern auf die Disk. schreibt, noch in irgendeiner Weise auch ankommen. Es dürften also mehr unnötige Benutzersperren nötig werden, wenn einige (neue oder auch alte) Benutzer auf nichts auf ihrer Disk. reagieren, weil sie es schlicht nicht mehr mitbekommen. Andererseits kann man sich dann jederzeit rausreden, dass man die Nachrichten gar nicht gesehen hat, und das wäre dann plausibel. Was immer das noch bedeuten könnte, aber diese Entwicklung gefällt mir überhaupt gar nicht. Das ist jedenfalls gravierender, als wenn man nur die Interwikis bei Wikidata gar nicht bearbeiten oder die neue Übersetzungsoberfläche gar nicht benutzen kann, da dies eine Grundfunktion der Kommunikation miteinander betrifft, auf die man sich dann nicht mehr verlassen könnte. Ich kann nur hoffen, dass das hier nicht live geht. --Geitost 15:08, 18. Mai 2013 (CEST)

Daher finde ich, dass (zumindest vorerst) der alte Balken (sei es per Gadget oder der alte, hauptsache auch ohne JS etc. sichtbar) standardmäßig Pflicht sein sollte. Die Bedenken, dass man dann die Zahl bzw. die Schrift oben nicht als Nachricht interpretiert, sehe ich dann nicht als bedeutend an, insbesondere die neuen Mitteilungen sind ja auch neu und man verpasst nichts, wenn man sie übersieht. Aber vor allem die jüngere Generation sollte mit dem neuen Design nicht überfordert sein, da es (mich) z.B. etwas an Facebook-Benachrichtigungen erinnert. Wobei natürlich man bei Benutzerdisk.-Nachrichten unmissverständlich hinweisen sollte, dass diese zuerst zu lesen sind.--se4598 / ? 16:16, 18. Mai 2013 (CEST)

Kleiner Test mit Geitost [8][9], bei mir funktioniert der kleine Kackbalken wie oben, bei Geitost anscheinend nur blauen Zahlen. Hm, Einstellungen? Übrigens:

• Echo does work with Javascript disabled. You just don't get the flyout. Kaldari (talk) 18:29, 3 May 2013 (UTC)
• we're hoping to do a couple of weeks of A/B testing, which will hopefully answer this question :). Okeyes (WMF) (talk) 23:45, 16 May 2013 (UTC)
• Echo usage Stats.

Die Echo-Kinderkrankheiten werden wohl jetzt auf enWP auskuriert (u.a. HTML e-mail, die tracking via URL ermöglichen würden), wenn DORT entsprechend protestiert wird. --Atlasowa (Diskussion) 22:37, 18. Mai 2013 (CEST)

Übrigens, beides rote Links: WP:Echo, WP:Flow. Eine echte Verbesserung für deWP wäre bspw. zukünftig eine (halb)automatische Notification an neue Benutzer "Deine Änderung wurde gesichtet". Das kommt aber bisher noch nicht in der Planung vor - weil enWP keine gesichteten Versionen hat und die WMF-Developer das somit nicht auf dem Schirm haben. Hingegen sind "review" Notifications vorgesehen - keine Ahnung was das überhaupt ist. --Atlasowa (Diskussion) 00:55, 17. Mai 2013 (CEST)

We’d like to hire a few community liaisons

Für die Einführung des VisualEditors ist die Wikimedia Foundation auf der Suche nach „Community Liaisons“. Diese sollten gut vermitteln können und diverse language skills besitzen. Als weiteres Plus wird experience with the software development process angesehen.

• 15h/Woche mindestens
• für 3 Monate

Weitere Informationen über dieses Job-Angebot (inklusive detaillierter Beschreibung): im Archiv der wikitech-ambassadors mailinglist. -- RE rillke fragen? 11:34, 18. Mai 2013 (CEST)

meta:Special:RecordImpression

Seit wann gibt es denn diese neue Form des Tracking und warum?

https://meta.wikimedia.org/wiki/Special:RecordImpression?result=hide&reason=empty&country=XX&uselang=de&project=wikipedia&db=dewiki&bucket=1&anonymous=false&device=desktop

Gibt es da eine neue Komponente oder Extension, die das auslöst?--se4598 / ? 19:09, 19. Mai 2013 (CEST) PS: Ich ergänze um https://meta.wikimedia.org/wiki/Special:BannerRandom?uselang=de&sitename=Wikipedia&project=wikipedia&anonymous=false&bucket=1&country=XX&device=desktop&slot=xx

Die Spezialseite RecordImpression gehört zur Extension „CentralNotice“ und soll angeblich die Aufrufe/Zugriffe der zentralen Meldungen protokollieren. Bei mir (unter Firefox) erscheint die Meldung:

Die Grafik „https://meta.wikimedia.org/wiki/Special:RecordImpression“ kann nicht angezeigt werden, weil sie Fehler enthält.

Eine weitere Funktion erschließt sich mir nicht. --\m/etalhead ✉ 20:43, 19. Mai 2013 (CEST)

Tech newsletter #1

Latest Tech news from the Wikimedia technical community. Please inform other users about these changes.

Recent software changes

(Not all changes will affect you.)

• The latest version of MediaWiki (version 1.22/wmf4) was added to non-Wikipedia wikis on May 13, and to the English Wikipedia (with a Wikidata software update) on May 20. It will be updated on all other Wikipedia sites on May 22. [10] [11]
• A software update will perhaps result in temporary issues with images. Please report any problems you notice. [12]
• MediaWiki recognizes links in twelve new schemes. Users can now link to SSH, XMPP and Bitcoin directly from wikicode. [13]
• VisualEditor was added to all content namespaces on mediawiki.org on May 20. [14]
• A new extension ("TemplateData") was added to all Wikipedia sites on May 20. It will allow a future version of VisualEditor to edit templates. [15]
• New sites: Greek Wikivoyage and Venetian Wiktionary joined the Wikimedia family last week; the total number of project wikis is now 794. [16] [17]
• The logo of 18 Wikipedias was changed to version 2.0 in a third group of updates. [18]
• The UploadWizard on Commons now shows links to the old upload form in 55 languages (bug 33513). [19]

Future software changes

• The next version of MediaWiki (version 1.22/wmf5) will be added to Wikimedia sites starting on May 27. [20]
• An updated version of Notifications, with new features and fewer bugs, will be added to the English Wikipedia on May 23. [21]
• The final version of the "single user login" (which allows people to use the same username on different Wikimedia wikis) is moved to August 2013. The software will automatically rename some usernames. [22]
• A new discussion system for MediaWiki, called "Flow", is under development. Wikimedia designers need your help to inform other users, test the prototype and discuss the interface. [23].
• The Wikimedia Foundation is hiring people to act as links between software developers and users for VisualEditor. [24]

Tech news prepared by tech ambassadors and posted by Global message delivery • Contribute • Translate • Get help • Give feedback • Unsubscribe • 22:25, 20. Mai 2013 (CEST)

Important note: This is the first edition of the Tech News weekly summaries, which help you monitor recent software changes likely to impact you and your fellow Wikimedians.

If you want to continue to receive the next issues every week, please subscribe to the newsletter. You can subscribe your personal talk page and a community page like this one. The newsletter can be translated into your language.

You can also become a tech ambassador, help us write the next newsletter and tell us what to improve. Your feedback is greatly appreciated. guillom 22:25, 20. Mai 2013 (CEST)

Den obenstehenden Newsletter habe ich hierher kopiert von WD:Kurier#Tech newsletter: Subscribe to receive the next editions bzw. WP:FzW#Tech newsletter: Subscribe to receive the next editions. Ich war mal mutig und habe diese Diskussionsseite hier (WD:NEU), auf die ja schon die wöchentlichen Wikidata-Newsletter kommen, als Abo-Ziel eingetragen. --UV (Diskussion) 00:28, 21. Mai 2013 (CEST)

Hallo. I wanted to leave a note here to let you know that this newsletter is a follow-up to my proposal a couple months ago about combining forces to monitor software and other technical changes. As WP:NEU contributors, you may be particularly interested in this, since our goal is to avoid duplicating resources.

At a minimum, you can now use the weekly summary to write WP:NEU, and I also encourage you to participate in the process and contribute to the monitoring of tech changes as you've been doing.

If you notice recent or upcoming tech changes, please consider leaving a note or a link on the next tech summary (in addition to WP:NEU) so that all subscribers of tech news across projects benefit from your vigilance.

Vielen Dank. guillom (Diskussion) 16:51, 21. Mai 2013 (CEST)

Spezial: Redirect

Hab mir grade Spezial:Redirect angeschaut und versuche den Sinn und Anwendungsfälle zu ergründen. Dateianzeige ist, denke ich, ganz sinnvoll. Versionsanzeige schon fraglich (warum soll ich eine VersionsID haben, wenn ich nicht auch schon die zugehörige Seite kenne?). Aber wozu braucht man die Weiterleitung auf die Benutzerseite per numerischer Benutzerkennung? Woher kennt man die Kennung eines anderen Benutzers überhaupt? Gibt es für einen Benutzer, der Wikipedia nur über die Weboberfläche benutzt, einen Bedarf nach Kennung zu suchen, oder sind das alles Suchmöglichkeiten für Leute, die die direkt die Datenbank abfragen? -- TZorn 10:59, 23. Mai 2013 (CEST)

Bisschen Background dazu wird in gerrit:59572 zusammengefasst. --YMS (Diskussion) 11:20, 23. Mai 2013 (CEST)

Ich denke, dass diese Funktion insbesondere dann sinnvoll ist, wenn man automatisch (z.B. per Bot oder Vorlage) Links generieren möchte. Beispiel: Du kennst einen Dateinamen, da stelle ich mir dann schwer vor den Direktlink zu der Datei zu bekommen. --Patrick87 (Diskussion) 11:22, 23. Mai 2013 (CEST)

Patrick, ich bin vor Allem über die Benutzerkennungsweiterleitung gestolpert. Aber YMSs Link erklärt die Motivation dafür ja. -- TZorn 17:10, 23. Mai 2013 (CEST)

Newsletter auf dieser Diskussionsseite

Ich bin nicht glücklich mit dem Anlanden der Newsletter auf dieser Diskussionsseite. Sie sind mir zu voluminös, Wikidata interessiert mich nicht, und die durch lokale Menschen initiierten Themen gehen in der Maschinenpost unter.

Ich schlage zwei dauerhafte Unterseiten vor:

• WP:Technik/Neuigkeiten/Wikidata
• WP:Technik/Neuigkeiten/Wikitech

Hier kann themenspezifisch Beo-abonniert werden. Auf den Unterseiten bildet sich eine chronologische Abfolge heraus. Im derzeitigen Archiv dieser Seite wird es übersichtlicher. Die Unterseiten brauchen nicht automatisch archiviert zu werden. Wenn es auf das Megabayte zugeht, kann man den Newsletter jahrgangsweise abheften.

Liebe Grüße --PerfektesChaos 10:01, 21. Mai 2013 (CEST)

Das halte ich für eine gute Idee.--Christian1985 (Disk) 11:05, 21. Mai 2013 (CEST)

Das macht aber gleichzeitig den eigentlichen Gedanken hinter diesem Newsletter zunichte: Möglichst viele Personen zu erreichen und diese mit einer Zusammenfassung aller Neuigkeiten zu versorgen, ohne dass diese unzählige Seiten auf unzähligen Wiki-Projekten beobachten und kontrollieren müssen. Ansonsten kann ich gleich meta:Tech/News/Latest auf meine Beobachtungsliste setzen. --Patrick87 (Diskussion) 11:17, 21. Mai 2013 (CEST)

Das verstehe ich nicht.

• Es wird ja angekündigt, dass der Newsletter XY ab jetzt auf der und der Seite aufläuft. Für Wikidata könnte man ja auch WP:Wikidata als Basis wählen. Wer diesen Wikidata-Newsletter haben möchte, kann genau diese Seite auswählen und beobachten, und bleibt von lauter techie-Zeug verschont, das einen sowieso nicht interessiert.
• Wer beide und möglicherweise weitere haben will, beobachtet eben beide.
• Wer die Newsletter nicht haben möchte und die Menschen der deWP haben möchte, setzt die Newsletter halt nicht auf die Beo.
• Die Archive sind thematisch sortiert und nicht so ein Kuddelmuddel, wie es sich auf dieser Disku herauszubilden beginnt.

Schönen Tag --PerfektesChaos 12:06, 21. Mai 2013 (CEST)

+1, gute Idee. Besonders, weil sich meiner Vorstellung nach vor allem der Wikitech-Newsletter vermutlich stark zur der umseitigen Zusammenstellung redundant ist. Über die Unterseiten müsste man nochmal reden, weil bei WP:Technik/Neuigkeiten/Wikitech ist mir der begriffliche Unterschied zu WP:Projektneuheiten zu klein. Daher schlage ich daher vor, den als Unterseite zu dieser laufen zu lassen. Analog natürlich auch dann für Wikidata. --se4598 / ? 12:45, 21. Mai 2013 (CEST)

Es geht ja auch nicht um Leute wie dich (oder mich) die genau die Seiten beobachten, die sie auch beobachten wollen. Es geht darum, dass die Idee hinter dem neuen Newsletter ist, mehr Personen zu erreichen, die ihre Beobachtungsliste eben nicht so gut pflegen, und von solchen Mitteilungen sonst nichts mitbekommen. Genau darum soll der Newsletter eben an Seiten gehen, die viel frequentiert sind bzw. bereits von vielen Leuten beobachtet werden (z.B. die englischen "Village Pumps"). Mir persönlich wäre ein separate Seite auch lieber. --Patrick87 (Diskussion) 13:08, 21. Mai 2013 (CEST)

Ich glaube, wir brauchen niemanden zwangszubeglücken. Kein Einwand meinerseits, die Newsletter statt auf dieser Diskussionsseite auf separaten, dezidiert dafür geschaffenen Seiten auftreffen zu lassen. --UV (Diskussion) 21:10, 21. Mai 2013 (CEST)

Ich würde auch eine Unterseite begrüßen. Für den techblog hatte ich auch mal eine Angelegt: Wikipedia:Projektneuheiten/Tech blog, wenn man die Sachen auf einer Seite sammelt, kann man auch mit den Änderungen an verlinkten Seiten auf dem Laufenden bleiben. Für WikiData hatte ich auch schonmal daran gedacht, aber war nicht dazu gekommen. Die Leute, die schreiben, das sie nicht informiert wurden, werden die Sachen auch hier nicht lesen, weil sie die gesamte Seite nicht auf der Beobachtungsliste haben. Vielleicht kann man auch im WP:Autorenportal noch versuchen, hatte mal gelesen, das einige sich dort die Infos gewünscht hätten. Keine Ahnung, ob das "zielgruppengerecht" ist. Der Umherirrende 21:16, 21. Mai 2013 (CEST)

Wäre eine einzelne Seite - etwa WP:Projektneuheiten/Newsletter - praktikabel, auf der dann alle Neuigkeiten in Newsletterform gesammelt werden? --Patrick87 (Diskussion) 01:51, 22. Mai 2013 (CEST)

Vielleicht besser wirklich getrennte Seiten je Newsletter, damit man gezielt jene Newsletter beobachten kann, die von Interesse sind. (Dazu natürlich eine Übersichtsseite, auf der die einzelnen Newsletterunterseiten aufgelistet sind.) --UV (Diskussion) 22:33, 22. Mai 2013 (CEST)

Der Charme einer einzelnen Seite ist natürlich, dass nicht jeder einzelne Benutzer up to date bleiben muss, welche Newsletter es zu beobachten gibt. Solange irgendjemand einen neuen Newsletter dorthin abonniert (es scheinen in letzter Zeit ja mehr zu werden. :-)), bekommt man es dort mit. -- TZorn 11:07, 23. Mai 2013 (CEST)

Nach einem Verschieben einer Seite beobachten alle Beobachter die alte und die neue Seite. Damit lassen sich Einträge in der Beobachtungsliste übertragen. --Fomafix (Diskussion) 11:14, 23. Mai 2013 (CEST)

Ja, man kann diese Seite an den Ort verschieben, wo der Newsletter hinkommen soll und wieder zurückverschieben. Dann haben automatisch alle Beobachter dieser Seite die neue Seite auf der Beo, auch wenn die WL gelöscht und dann dort eine neue Seite angelegt wird. --Geitost 18:28, 23. Mai 2013 (CEST)

Und wenn man vor dem Löschen der WL oder Anlegen der Newsletterseite noch die erstellte WL weiterverschiebt an die Orte, wo die verschiedenen Newsletter hin ausgelagert werden sollen, dann sind auch jene Seiten alle automatisch auf den Beos – schließlich wäre es ja nur eine Aufteilung der hiesigen Seite. Dann kann anschließend jeder Benutzer, der die Seiten auf der Beo hat, diese einzeln wieder runterschmeißen, wenn er*sie dies oder jenes nicht lesen will.

Man müsste sich nur hier vorher auf die verschiedenen Seitennamen einigen, wo die Newsletter hinkommen sollen. Wie viele sind es denn jetzt eigentlich: Wikidata, Wikitech, war’s das oder noch mehr? Also, wo soll dann der Wikidata-Newsletter und wo der Wikitech-Newsletter hin? --Geitost 18:30, 23. Mai 2013 (CEST)

• Wikidata dann definitiv als eine Unterseite von WP:Wikidata.
  • Anbieten würde sich ja das intuitiv verständliche WP:Wikidata/Newsletter.
  • Wenn hingegen ein deutschsprachiger Seitenname für den englischsprachigen Inhalt erforderlich ist, mag man auch /Rundschreiben oder /Neuigkeitenbrief nehmen.
• Wikitech als Unterseite von WP:NEU.
  • Abonnieren werde ich das nicht. Die zuverlässig und aufopferungsvoll weitaus überwiegend durch Raymond gepflegte WP:NEU enthält auch dewiki-spezifische Informationen und lokale Verlinkungen und Zusatzinformationen.
  • Gleichwohl spricht nichts gegen ein müheloses automatisches Referenzexemplar in chronologischer Folge. Wenn man mal etwas sucht, findet man dort vielleicht auch Meta-Themen und Ankündigungen, während WP:NEU auf konkrete aktuelle Änderungen abhebt.

VG --PerfektesChaos 10:20, 24. Mai 2013 (CEST)

Bei „Newsletter“ denk ich ja, dass das allgemeinverständlich genug ist und normalerweise auch dafür verwendet wird. Machen wir mal Rotlinks draus, dann sieht man die Vorschläge besser. Also dann WP:Wikidata/Newsletter und WP:Projektneuheiten/Newsletter? Alternativ wäre auch „Aktuelles“ noch denkbar oder so was, ist aber wohl nicht genau genug bezeichnet, oder? „Neuigkeitenbrief“ ist hingegen wohl eher unüblich, da wäre dann „Rundschreiben“ noch besser, aber der Newsletter tut’s auch. Suche in allen Namensräumen ergibt 6.351 Treffer für Newsletter, 0 für „Neuigkeitenbrief“ (das ist also eindeutig unüblich), immerhin 1.247 für Rundschreiben und 180.419(!!) für Aktuelles. Siehe [25], das sind die ganzen Unterseiten der Portalseiten beispielsweise, die allesamt so heißen. Wikipedia:Aktuelles leitet interessanterweise auf den Kurier weiter, was bezeichnungsmäßig ja auch recht gut passen würde, wo der obige Newsletter schon auf der WD:Kurier gelandet war. Die Portalunterseiten mit „Aktuelles“ im Namen binden aber alle aktuelle Dinge auf die Portalseiten ein und sind in dem Sinne keine Newsletter zum Abonnieren.

Andersherum gibt es auch schon WP:Jungwikipedianer/Newsletter und Wikipedia:Newsletter, wo diese dann auch eingetragen werden sollten bzw. Wikidata steht da schon mit meta:Wikidata/Newsletter/Archive. Dazu würde tatsächlich analog WP:Wikidata/Newsletter am besten passen. Also plädier ich dann doch dafür und für WP:Projektneuheiten/Newsletter, dann kapiert wohl jeder sofort, was das für ne Seite und wozu sie da ist. Und wenn man die hiesigen Diskussionen nicht auf der Beo haben will, kann man auch diese Seite abbestellen statt der Newsletter. ;-)

Also könnte man dann diese Seite nach WP:Projektneuheiten/Newsletter und wieder zurück verschieben und dann die dort entstandene WL nach WP:Wikidata/Newsletter weiterverschieben. Und anschließend entweder beide WL zuerst löschen oder direkt dort die Seiten für die Newsletter erstellen. So weit mal dazu. --Geitost 21:42, 24. Mai 2013 (CEST)

Ich frag mich gerade, ob wir überhaupt den Wikitech-Newsletter auf dieser Seite brauchen. Im Grunde genommen steht da zur Zeit das gleiche wie umseitig, evtl. genereller und nicht in dem Maße auf dieses Wiki bezogen. (Und mit ein paar Tagen Verzögerung.)--se4598 / ? 21:00, 23. Mai 2013 (CEST)

Wie gesagt kann es ja auch sein, dass Leute lieber eine kürzere und de-spezifische Seite bevorzugen, da diese evtl. dann verständlicher ist. Zudem muss man diese Disk. nicht mit abonnieren, wenn man das nicht möchte. Also wäre das schon sinnvoll. --Geitost 21:44, 24. Mai 2013 (CEST)

Anmelde-Seite umgestaltet

Moin Moin zusammen, heute sieht die Anmeldeseite irgendwie komplett umgestaltet aus? Welches Update war es denn? mfg --Crazy1880 08:13, 30. Mai 2013 (CEST)

Es wurde hier an einem vielleicht etwas unglücklichen Ort angekündigt und hat ein paar hilfreiche Links. --Knopfkind 12:15, 30. Mai 2013 (CEST)

(quetsch) Gab's auch auf FzW. --YMS (Diskussion) 20:37, 30. Mai 2013 (CEST)

Siehe auch die 3. Softwareneuheit hier. --enomil enomil 13:00, 30. Mai 2013 (CEST)

Vielen Dank --Crazy1880 19:27, 30. Mai 2013 (CEST)

Habe es vorne mal notiert, was aber eigentlich jeder machen kann, wenn er gute Infos findet, verlinken kann … Der Umherirrende 20:23, 30. Mai 2013 (CEST)

MathJax

Mit dem heutige Update wird nun anscheinend auch der "Latex-Befehl" \Q mit MathJax hier richtig als $\mathbb {Q}$ dargestellt. Grüße --Christian1985 (Disk) 20:51, 5. Jun. 2013 (CEST)

Das wurde als Teil von Bug 35186 (gerrit:64530, gerrit:64531) behoben, da fehlt aber wohl noch etwas. Ich habe jetzt keinen Überblick, was bereits funktioniert und was nicht. Kann aber gerne vorne ergänzt werden. Der Umherirrende 21:02, 5. Jun. 2013 (CEST)

Das wird wohl so häppchenweise behoben? Ein Teil der nichtklassischen griechischen Buchstaben wie \coppa klappen schon seit dem letzten oder vorletzten Update, die anderen klappen immer noch nicht und die Euro-Zeichen klappen auch noch nicht. Aber die Zeichen habe ich in einem Wikipedia-Artikel noch nie gesehen. Grüße --Christian1985 (Disk) 21:10, 5. Jun. 2013 (CEST)

Raymond hat es jetzt nachgetragen. Vielen Dank. Der Umherirrende 18:20, 10. Jun. 2013 (CEST)

Neue Galerieansicht

Hallo, wo kann man Kommentare zu dem verlinkten Vorschlag abgeben? IW 19:27, 17. Jun. 2013 (CEST)

Auf Bawolffs Diskussionsseite. --Patrick87 (Diskussion) 19:39, 17. Jun. 2013 (CEST)

Aha, Commons also (wie kommt man darauf? ;). Danke. IW 19:41, 17. Jun. 2013 (CEST)

Steht im ersten Satz auf der verlinkten Seite. Vorlage:Smiley/Wartung/;)  --Patrick87 (Diskussion) 00:13, 18. Jun. 2013 (CEST)

Anmelde-Cookie schon wieder

Trotz Wahl der Option „Dauerhaft angemeldet bleiben“ werde ich bereits nach einigen Tagen wieder hinaus geworfen. --\m/etalhead ✉ 11:35, 16. Jun. 2013 (CEST)

Hallo? --\m/etalhead ✉ 15:22, 20. Jun. 2013 (CEST)

"Bereits nach einigen Tagen" ist nicht weiter schlimm und kann passieren. Bitte einfach neu anmelden. Bei "bereits nach einigen Minuten" bitte nochmal melden, und zwar da, wo so eine Frage hingehört, z. B. WP:FzW, aber garantiert nicht die Diskussionsseite zu "Projektneuheiten". --AndreasPraefcke (Diskussion) 15:30, 20. Jun. 2013 (CEST)

Dieser Abschnitt kann archiviert werden. --AndreasPraefcke (Diskussion) 15:30, 20. Jun. 2013 (CEST)

Hat sich was am Captcha geändert?

Wir haben beim Support-Team gerade innerhalb weniger Minuten 3 Mails von verschiedenen Leuten gekriegt, dass das Captcha beim Speichern unter IP nicht angezeigt wird. Wurde was dran geändert oder ist es Zufall? XenonX3 – (☎ – RIP Lady Whistler)) 15:12, 26. Jun. 2013 (CEST)

Einer der Anfragenden meinte gerade, bei ihm hätte sich das Problem durch das Aktualisieren des Flash Players gelöst. Weiß jemand Näheres? XenonX3 – (☎ – RIP Lady Whistler)) 15:36, 26. Jun. 2013 (CEST)

Die letzte Änderung am Captcha-System, an die ich mich erinnern kann, ist, dass es möglich gemacht wurde, direkt durch Klick einen neuen Code zu erzeugen. Möglicherweise wurde dadurch der Einsatz von Flash oder anderen Skripten nötig. IW 18:50, 26. Jun. 2013 (CEST)

Flash sicher nicht. Ich habe gerade mit IE9 getestet, sowohl im Kompatibilitätsmodus als auch ohne, sowohl mit JavaScript als auch ohne: Das Captcha wird immer angezeigt, in keiner Konstellation traten nennenswerte Probleme auf. Für mich klingt das eher nach kurzzeitigen Serverproblemen (dass eben die Antwortzeit des Servers, auf dem die Captcha-Bilder liegen in diesen wenigen Minuten unerträglich hoch war und dass das Captcha schon noch angezeigt worden wäre, wenn die Benutzer denn bereit gewesen wären im schlimmsten Fall ein paar Minuten darauf zu warten). --Schnark 09:17, 27. Jun. 2013 (CEST)

wmf7 oder wmf8

Ich bin gerade verwirrt. Sind wir aktuelle auf 1.22wmf7 oder 8? Spezial:Version zeigt mir 1.22wmf7. Lt. mediawiki-config sollten alle Projekte auf 8 sein. Habe ich irgendwas verpasst und/oder verschlagen? — Raymond ^Disk. 09:59, 28. Jun. 2013 (CEST)

Habs gefunden. Alle Projekte sind auf 1.22wmf7: https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=75751&oldid=75750 — Raymond ^Disk. 10:09, 28. Jun. 2013 (CEST)

Hallo, Raymond. Warum wurde denn die Aktualisierung revertiert? Gruß --Tlustulimu (Diskussion) 10:37, 28. Jun. 2013 (CEST)

Ein Progammierfehler in der GeoData-Erweiterung, siehe das ServerAdminLogbuch heute Nacht ab 4:54: https://wikitech.wikimedia.org/wiki/Server_Admin_Log

wav Audio-Dateien?

Ich bin erstaunt. Ist das denn ein freies Datenformat? Sind Rechte ausgelaufen? Oder was ermöglicht die Verwendung? Grüße --h-stt !? 18:50, 28. Jun. 2013 (CEST)

War das denn nicht frei? Das ist doch sowieso ein schlechtes, weil ungepacktes Format. So schlecht wie BMP für Bilder. ÅñŧóñŜûŝî (Ð) 22:04, 28. Jun. 2013 (CEST)

WAV ist glaube ich nirgends standardisiert, aber wenn man mal den Header weglässt, sind WAV-Dateien einfache PCM-Daten, da kann man eigentlich nichts schützen. Also mir ist nicht bekannt, dass da irgendwer irgendwelche Rechte dran hat, da praktisch keine erwähnenswerte geistige Leistung drinsteckt. --APPER\^☺☹ 23:11, 28. Jun. 2013 (CEST)

• Der Grund, weshalb die WAV-Unterstützung eingebaut wurde, ist übrigens die "Pronunciation Recording Extension" welche im Rahmen von "Google Summer of Code" entwickelt wird (siehe mw:User:Rahul21/Gsoc). Diese soll es ermöglichen die Aussprache von Wörtern direkt im Browser aufzuzeichnen (aktuelle Browser unterstützen nämlich WAV!) und die Audiodatei automatisch auf Commons hochzuladen. Dort wird sie dann vom "Timed Media Handler" nach OGG konvertiert. --Patrick87 (Diskussion) 23:22, 28. Jun. 2013 (CEST)
• Blos weil das Dateiformat unkomprimiert ist, ist es noch lange nicht schlecht, im Gegenteil. Da die gängigen anderen Audioformate alle verlustbehaftet komprimieren, ist es das qualitativ hochwertigste Tonformat. Ausserdem sind keine aufwendigen Kompressions- oder Dekompressionsalgorithmen notwendig. Bis vor einigen Jahren war wav genau deswegen noch sehr verbreitet: Die Rechner waren zumindest bei der Kompression zu langsam, um sie in Echtzeit hinzubekommen, das wegschreiben der (grösseren) Datenmenge war dagegen möglich. --PaterMcFly Diskussion ^Beiträge 22:18, 29. Jun. 2013 (CEST)

Stimmt nicht ganz: Seit (auch erst vor kurzem) FLAC als unterstütztes Audioformat hinzugefügt wurde, ist dies einem unkomprimierten WAV zur verlustlosen Speicherung von Audiodaten sicher vorzuziehen. Aber grundsätzlich stimme ich dir zu, WAV-Unterstützung ist sicher eine gute Idee, denn WAV wird (gerade weil es so einfach ist) von bestimmt jeder Software unterstützt und ist somit absolut "DAU"-kompatibel. --Patrick87 (Diskussion) 23:14, 29. Jun. 2013 (CEST)

Hinweis: Einem Archivar des Hessischen Rundfunks zufolge, ist WAV mit dem entsprechenden Sampling der Audio-CD das Standard-Archivformat für Audio beim hr – und wahrscheinlich nicht nur dort. Man könnte nun also Original-Archivbestände auf Commons übernehmen, wenn die Rundfunkanstalten dabei mitmachen würden. Es gibt dort mittlerweile auch verwaiste Werke, die durchaus zu Bildungszwecken von Interesse wären.--Aschmidt (Diskussion) 15:48, 2. Jul. 2013 (CEST)

Das Format auf Audio-CDs ist im Prinzip Wav, zumindest wenn man die (für den Musikgenuss unnötigen) Sektorenkennungen weglässt. Um also eine Audio-CD sauber zu archivieren, muss man fast dieses Format verwenden. --PaterMcFly Diskussion ^Beiträge 21:17, 8. Jul. 2013 (CEST)

Sorry, aber verbreite doch nicht solchen Unsinn! Bei den Audiophilen, welche CDs verlustfrei archivieren wollen ist FLAC stand der Technik. FLAC ist genauso verlustfrei wie PCM, jedoch (verlustlos) komprimiert (so wie z.B. ZIP). Wenn man zusätzliche noch eine Cuesheet-Datei mit Metainformationen erstellt, lässt sich aus .FLAC+.CUE eine Bit für Bit identische Kopie der CD rekonstruieren. --Patrick87 (Diskussion) 21:51, 8. Jul. 2013 (CEST)

Uploads im FLAC-Format

Ich würde dann noch vorschlagen, die Unterstützung für ALAC einzuführen. Ist zwar nicht so bekannt, aber immerhin freie Software. --\m/etalhead ✉ 17:24, 22. Jun. 2013 (CEST)

Relative Seiteneinbindungen ...

Hallo,

was ist mit

(Bugfix) Relative Seiteneinbindungen im Haupt-Namensraum (NS0) funktionieren jetzt: {{../Unterseite}} (Nicht für Wikipedia von Interesse, da es im ANR keine Unterseiten gibt, Gerrit:66092).

gemeint? Ich verstehe den Satz leider nicht. Es gibt im ANR leider doch Unterseiten. Beispielsweise werden viele Seiten mit Diskografien als Unterseite im ANR angelegt, obwohl dies den aktuellen Regularien widerspricht.--Christian1985 (Disk) 19:55, 8. Jul. 2013 (CEST)

Dies sind technisch gesehen aber keine Unterseiten, sondern ganz normale Lemmata, bloß mit Schrägstrich drin. Wären es Unterseiten, könnte man oben (wie in anderen Namensräumen) den Link zur Oberseite anklicken. IW 19:59, 8. Jul. 2013 (CEST)

neue Benutzerrechte

Ich habe Verständnisschwierigkeiten mit dieser Neuerung.

• "Das neue Benutzerrecht editsemiprotected erlaubt die Bearbeitung halbgeschützter Seiten. Standardmäßig ist dies Benutzern (älter als 4 Tage), Bots und Administratoren zugeteilt." - Das war doch schon immer so. Wie wurde das denn bisher gelöst, wenn nicht über ein Benutzerrecht? Und vor allem: Wozu wird es gebraucht? Ich sehe momentan den Sinn darin nicht.
• "D.h. Bots können keine vollgeschützten Seiten mehr bearbeiten" - Das konnten sie doch auch bisher nicht; es sei denn, man hat ihnen explizit Adminrechte verliehen. Das sagt doch auch genau der erste verlinkte Bug. Oder verstehe ich da etwas flacsh?

--Stepro (Diskussion) 20:15, 8. Jul. 2013 (CEST)

Also wenn ich den Text im Bug lese, war die Absicht eigentlich genau andersrum, nämlich dass man mit Editprotected einem Bot teilweise Admin-Rechte geben kann, damit er gewisse Aufgaben im entsprechenden Wiki durchführen darf (Interwikilinks in en.wikinews umbiegen zum Beispiel, weil da viele Seiten nach einer gewissen Zeit automatisch vollgesperrt werden). Die Beschreibung scheint mir auch verwirrend. --PaterMcFly Diskussion ^Beiträge 21:29, 8. Jul. 2013 (CEST)

Ich bin genauso verwirrt. Das, was ich umseitig beschrieben habe, basiert auf dieser Standard-Konfigurationdatei. Und das Recht "editprotected" wurde den Bots weggenommen, oder? — Raymond ^Disk. 21:37, 8. Jul. 2013 (CEST)

Die Zeile war auskommentiert und dieses Recht war nie in der Konfiguration explizit für dewiki gesetzt, dh. für die deutschsprachige Wikipedia ändert sich hierdurch gar nichts - Hoo man (Diskussion) 21:43, 8. Jul. 2013 (CEST)

Sehe ich auch so. Jetzt können allerdings Wikis, die Adminbots betreiben, diesen Bots das Adminrecht enziehen und Editprotected geben, wenn der Bot nicht löschen jedoch vollgeschützte Seiten bearbeten soll/muss/darf. -- 32X 21:51, 8. Jul. 2013 (CEST)

Ja, so würde ich das auch verstehen. Bestimmte Bots laufen ja bisher als Admin, da sie sonst keine Edits auf vollgeschützten Seiten machen könnten. Das ist nun nicht mehr nötig, das Admin-Flag kann entzogen werden und statt dessen das editprotected-Flag gesetzt werden.

Wozu allerdings das editsemiprotected-Recht gut sein soll, entzieht sich noch meiner Vorstellungskraft. Alle, außer neue Nutzer in den ersten 4 Tagen, haben es doch sowieso schon. Oder wurde es eingeführt, damit man es gezielt entziehen kann? Das fände ich ja mal interessant: Anstatt eine Seite vollzuschützen oder die Editwarrior zu sperren, entzieht man denen nur dieses Recht und schützt die Seite halb. Das Theater, wenn der erste das so umsetzt, lässt die Popcorn-Aktien mit Sicherheit explodieren. --Stepro (Diskussion) 23:12, 8. Jul. 2013 (CEST)

Allerdings kann man einem Benutzer nicht ein einzelnes Recht entziehen. Die Rechte sind an die Benutzergruppen gebunden, nicht an die Accounts. Man müsste dann schon eine Benutzergruppe ohne editsemiprotected erstellen, in die man die Editwarrior einweist. XenonX3 – (☎ – RIP Lady Whistler)) 00:32, 9. Jul. 2013 (CEST)

PS: Wobei es wohl einfacher wäre, Admins die Möglichkeit zu geben, Benutzer aus der Autoconfirmed-Gruppe zu entfernen. Dann spart man sich die extra Benutzergruppe. XenonX3 – (☎ – RIP Lady Whistler)) 00:35, 9. Jul. 2013 (CEST)

Achso, stimmt, Denkfehler von mir. Da funktioniert das mit den Bots ja aber auch nicht, es sei denn, man erstellt eine zweite Bot-Nutzergruppe, "Premium-Bot". OMG. Also wird wohl alles so bleiben wie bisher, das ist deutlich einfacher. Zumal für manche Bot-Aktionen (wie z. B. beim Seitenschutz-Bot auf Wikisource) ja sowieso Admin-Rechte benötigt werden. --Stepro (Diskussion) 00:44, 9. Jul. 2013 (CEST)

Ein Steward sollte das Recht vergeben können, alternativ stellt man sich eine Benutzergruppe nach Projektbedürfnis zusammen. Commons:Special:ListGroupRights ist da ein gutes Beispiel für Gruppen mit ein oder zwei zusätzlichen Rechten: Der Automatische Kontrollierer mit seinem zusätzlichen Eigene Bearbeitungen automatisch als kontrolliert markieren (autopatrol) gehört zu den 8 Gruppen, die von Admins setz- und entfernbar sind, die mit der gleichen Eigenschaft versehene Gruppe OTRS-Mitglieder hingegen gehört zu den 11 Benutzergruppen, die nur durch Bürokraten oder höher geändert werden können. -- 32X 01:32, 9. Jul. 2013 (CEST)

Globaler MBF

Bezugnehmend auf dies. Sinn und Zweck von globalen Missbrauchsfiltern ist klar: Verhindern von Crosswikivandalismus. Nur hatten wir bislang kaum richtig Probleme mit solchem Vandalismus gehabt (zudem wird vieles schon global verhindert, z.B. TOR, globale Blocklisten etc.) und jede Ausweitung von MBF führt hier bloss zu Misstrauen. Daher meine Frage: ist es geplant, solche MBF eines Tages flächendeckend einzusetzen? Und falls ja: wird da ein Opt-out für dewiki möglich sein? --Filzstift ✏ 10:33, 9. Jul. 2013 (CEST)

Auf der Diskussionsseite dazu wurde es schon (vor einiger Zeit) zumindest anproblematisiert. -jkb- 11:21, 9. Jul. 2013 (CEST)

DISAMBIG (keine) Eile?

Das PerfekteChaos schreibt umseitig: Was wohl heißen würde, dass dieses Schlüsselwort einmalig in die Vorlage:Begriffsklärung hineingeschrieben werden müsste. Die ist 185519 Mal eingebunden und sieht ihrem Ersatz durch Lua entgegen; hat keine Eile

Warum sollte man das Schlüsselwort nicht umgehend einbauen? Schaden tuts doch nicht, oder? Endlich sind BKLs semantisch eindeutig gekennzeichnet und über die PageProps abfragbar. Der Ersatz durch Lua (was bringt Lua hier überhaupt für eine Verbesserung?) kann ja von mir aus auch kommen ;-) — Raymond ^Disk. 22:42, 9. Jul. 2013 (CEST)

2. Zuerst: was bringt Lua für eine Verbesserung?

→ Diese hier.

• Wie detektierst du alle diese Kategorien ohne Lua? Etwa diese: Doppelmoppel. Nebenbei diskutiert das BKS-Projekt ein neues Seitenformat.

1. Zurzeit sind sie ja über Kat und die Vorlageneinbindung detektierbar.

Welche neuartigen Auswertungsverfahren haben wir oder das Projekt BKS zu laufen, dass wir von jetzt auf gleich die neue Methode über die PageProps bräuchten?

3. Schaden tut’s nur den Hamstern, für die 185.000 Seiten.

VG --PerfektesChaos 23:10, 9. Jul. 2013 (CEST)

Die Belastung der Abarbeitungs-Queue kann uns eigentlich egal sein, da die (moderate) Serverbelastung nie ein Grund für eine unterlassene Verbesserung sein sollte. -- 32X 23:17, 9. Jul. 2013 (CEST)

Danke für die Erklärungen. Tiefer einsteigen werde ich später. Hier nur in aller Kürze der Link auf wikitech-l: Disambiguator extension deployed to all WMF wikis (action required). MaW: Über kurz oder lang wird die alte Form der BKL-Kennzeichnung wohl aus dem Code fliegen. — Raymond ^Disk. 07:58, 10. Jul. 2013 (CEST)

Sobald der Patch für bugzilla:50160 gemerget wird, werden solchermaßen gekennzeichnete BKLs auch direkt beim Einfügen (mit der Werkzeugleiste) als solche gekennzeichnet. (Ob der VE das auch kann, weiß ich nicht.) --Schnark 09:14, 10. Jul. 2013 (CEST)

Ich habe das MagicWord in die neue Programmierung eingefügt.

Außer für Werkzeuge ist die PageProp erstmal nicht erforderlich.

Sonnigen Tag --PerfektesChaos 09:31, 10. Jul. 2013 (CEST)

Ich war mal so frei. Wie gesagt, schaden kann es nicht. MediaWiki:Gadget-bkl-check.js brauch man aber erstmal nicht umstellen, weil dort ja auch Falschschreibungen markiert werden und jede beliebige Kategorie markiert werden könnte. Der Umherirrende 16:19, 10. Jul. 2013 (CEST)

Ist es mit dem magischen Wort nun eigentlich möglich BKLs aus der "Rubrik" "Zufälliger Artikel" rauszuhalten?--Christian1985 (Disk) 16:22, 10. Jul. 2013 (CEST)

Da sie jetzt technisch eindeutig erkennbar sind, wäre das möglich. Genauso könnte man sie auch aus der Anzahl der Artikel herausrechnen und es werden sich sicher noch ein paar Anwendungsfälle finden. Der Umherirrende 16:35, 10. Jul. 2013 (CEST)

Das ist geplant, siehe den oben von Raymond verlinkten Beitrag auf der Mailingliste. --Schnark 09:32, 11. Jul. 2013 (CEST)

Universal language selector

Hi, ich habe ein Problem mit dem neuen ULS, wie mehrere Leute zusammen auf WP:FzW herausbekommen konnten. Wenn man im Browser keine prefered User Language(s) angegeben hat, das Feld also leer ist, bricht MediaWiki mehrere JS-Funktionen im Editfenster einfach ab. Betroffen sind alle Editwerkzeuge über dem Fenster und die Sonderzeichen darunter, mit Ausnahme der Funktionen, die eine Eingabemaske öffnen (Link, Bild, ref). Das Problem tritt bei mir unter FF 22.0 (release channel) auf Win 7 pro auf und ist reproduzierbar. Was kann man da tun? Grüße --h-stt !? 17:27, 10. Jul. 2013 (CEST) PS: Das Problem trat schon vor Monaten auf meta auf, dort habe ich es hingenommen, weil ich da sehr selten signiere.

Bug im Bugzilla eintragen. --Patrick87 (Diskussion) 17:36, 10. Jul. 2013 (CEST)

Bin ich zu doof für, bzw ist mein Leben zu kurz um auch das noch zu lernen ... Grüße --h-stt !? 18:02, 10. Jul. 2013 (CEST)

Ich habe ein Patch erstellt: gerrit:73448, mal schauen, wann der angenommen wird. Der Umherirrende 20:41, 12. Jul. 2013 (CEST)

Danke dir. Viele Grüße --h-stt !? 16:56, 15. Jul. 2013 (CEST)

watchlistnotice zu neuer Anmeldeprozedur

Wikipedia:Kurier #Vereinheitlichung der Login-Seiten – „so eine Änderung kann leicht dazu führen, dass Leute Phishing vermuten oder zumindest verwundert bis irritiert sind über die geänderte Benutzerführung.“

• Ich denke, es sollte Tradition werden, 36 Stunden im Voraus die regelmäßigen Benutzer per watchlistnotice/sitenotice von aller Voraussicht nach eintretenden auffallenden und einschneidenden Umstellungen zu informieren.
• Zumindest noch nachträglich zur Erklärung wäre es in diesem Fall für eine knappe Woche sinnvoll.

LG --PerfektesChaos 21:45, 16. Jul. 2013 (CEST)

PS: Bzw. für die Anmeldeseite gibt es wohl auch eine Systemnachricht, mit der man vorab schon temporär einen Hinweis geben kann. VG --PerfektesChaos 21:47, 16. Jul. 2013 (CEST)

Die sitenotice ist auch ohne Skripte zu sehen, die watchlistnotice hingegen nicht. Also besser erstere, da barrierefrei. --Geitost 22:18, 16. Jul. 2013 (CEST)

Das eine tun ohne das andere zu lassen; es gibt einige PowerUser, die die sitenotice dauerhaft ausgeblendet haben.

• Systemnachricht im Sinne einer loginnotice gibt es nicht; aber man könnte für eine knappe Woche Mediawiki:loginlanguagelabel ausdehnen (mit hardcopy von translatewiki).

Endlich wieder atembare Luft. Guten Morgen --PerfektesChaos 00:06, 17. Jul. 2013 (CEST)

Gender-Blüten

Im Bild.

Jetzt hat WP wohl endgültig einen an der Waffel. Was sollen solche Datenerhebungen? -- Smial (Diskussion) 12:27, 12. Jul. 2013 (CEST)

Diese Daten wurden ja "schon immer" erhoben, nur halt nicht bei der Anmeldung, sondern erst später in den Benutzereinstellungen. Was zumindest insofern ungünstig war, als dass sich hier auf der de.wp ja beim Ausfüllen dieses Felds ggf. die "offizielle" Adresse der Benutzerseite ändert. --YMS (Diskussion) 12:44, 12. Jul. 2013 (CEST)

Nein, dank der Grandiosität der Foundation ist das etwas vollkommen anderes. Die Angabe, die man in dem Feld macht dient nur statistischen Zwecken und hat Null Auswirkungen auf Benutzer/Benutzerin auf der Benutzerseite. Gerade ausprobiert. -- southpark 12:58, 12. Jul. 2013 (CEST)

Für statistische Zwecke völlig sinnfrei, erstens wegen dem Button „Ich will es nicht preisgeben“ und zweitens wegen der anonymen Erhebung (kann ja jeder irgendwas anklicken). Und für eine Enzyklopädie ist es auch völlig egal, ob die beitragenden Benutzer männlich, weiblich oder „nicht preisgebend“ sind. --Oltau ^✉ 13:11, 12. Jul. 2013 (CEST)

Das weißt du, das weiß ich. Aber diverse Leute (die interessanterweise selten selbst aktiv beitragen) meinen zu wissen, daß das Geschlecht von Bedeutung für die enzyklopädische Arbeit wäre. Marcus Cyron Reden 14:15, 12. Jul. 2013 (CEST)

Das müsste mir - selbst nach gefühlt 1000 Diskussionen mal - irgend jemand erklären, damit ich diesen Zusammenhang verstehen kann. Das erschließt sich mir einfach überhaupt nicht - und damit alles, was damit zusammenhängt - zwangsläufig - ebenso nicht.Geolina ^{mente et malleo} ✎ 14:21, 12. Jul. 2013 (CEST)

Naja, es geht wohl darum, dass - darf man den Statistiken glauben schenken - wir deutlich weniger weibliche Benutzer als männliche haben. Für mich als Student der Soziologie ist das durchaus ein interessantes Phänomen. Für die enzyklopädische Arbeit (und darum geht es hier ja eigentlich) ist das aber eher irrelevant. -- Chaddy · D – DÜP – 16:18, 12. Jul. 2013 (CEST)

Diese Statistiken stimmen sicher - zumindest in der Grundaussage: es arbeiten in der Wikipedia mehr männliche als weibliche Autoren mit. Das ist insofern blöd, weil damit eine nennenswerte Zahl bei gleichem prozentualen Anteil an Frauen die theoretisch mitwirken könnte und sollte wegfällt. Das ist wegen unserer chronischen Unterbesetzung in nahezu allen Bereichen von Bedeutung weniger wegen ihres Geschlechtes oder ihrer Perspektive. Interessant ist es schon, daß diese statistische Auffälligkeit wirklich eine aus der Statistik heraus resultierende logische Signifikanz hat. Fatal wird es immer dann, wenn versucht wird zu ergründen, warum dem so wäre. Da wird ja am Allerliebsten der Unsinn genommen, daß Frauen mit dem rauen Umgangston nicht klarkommen würden. Wohl jeder der Frauen in seiner persönlichen Umgebung kennt, wird diesen Ansatz nicht verstehen können. Ebenso fatal, daß durch mMn ungeeignete Methoden (eben das Prinzip Zufall) Aussagen zur prozentualen Teilhabe von Frauen am Projekt gemacht werden. Schwarze Feder meinte zuletzt sogar ohne statistische Erhebung von nur 6-9% Frauen in der Wikipedia ausgehen zu können. Viel weniger erwürfelt sind die anderen Zahlen aber eher auch nicht. Jeder der hier aktiver ist kennt Mitarbeiterinnen unter Männeraccount und umgekehrt. Zudem: seit sich die WMF in diesem Themenbereich engagiert, sinken ironischerweise die prozentualen Mitarbeiterzahlen von Frauen. Von 13 über 9 auf 8,5%. Natürlich auch alle unterschiedlich erhoben. Ich persönlich würde ja von etwa 20% Frauenanteil ausgehen. Aber auch das ist nur gefühlt. Und natürlich zuwenig. Aber sicher nicht, weil dadurch weniger Artikel zu Mode, Schuhe, Taschen und Kates Hochzeitskleid geschrieben werden. Marcus Cyron Reden 16:30, 12. Jul. 2013 (CEST)

Bezweifelst Du, dass auf diesen Themenfeldern mehr gemacht würde, wenn die absolute Anzahl der Frauen hier höher wäre? Oder siehst Du bloß den Nutzen dieser Themen für die Enzyklopädie als gering an?

Da wird ja am Allerliebsten der Unsinn genommen, daß Frauen mit dem rauen Umgangston nicht klarkommen würden. Wohl jeder der Frauen in seiner persönlichen Umgebung kennt, wird diesen Ansatz nicht verstehen können.

Statistisch verstehe ich den schon. Es gibt mit Sicherheit sowohl Männer als auch Frauen, die mit dem Umgangston "nicht klarkommen" (im Sinn von: Er verleidet ihnen die Mitarbeit). Bei den Frauen ist der betreffende Prozentsatz aber wahrscheinlich etwas höher. Früher hieß es ja in diesem Sinn sogar ausdrücklich: Wikipedia ist kein Mädchenpensionat. Die Seite wurde aber (vermutlich aufgrund neuester Erkenntnisse der isländischen Genderforschung?) gelöscht. --Grip99 01:17, 13. Jul. 2013 (CEST)

Ich bezweifle, daß Frauen die ein enzyklopädisches Interesse haben, sich sehr vom Interesse der Männer unterscheiden. Im Gegenteil, ich halte die Aussage von Sue Gardner zu den dann mehr vorhandenen Artikeln zu Mode und Schuhen (hätte ich nichts dagegen) für eine sexistische Sichtweise, weil Frauen Klischeehaft auf dieses Zeug reduziert werden. Marcus Cyron Reden 17:19, 20. Jul. 2013 (CEST)

"Reduziert" werden sie ja nicht, Mode und Schuhe sind allenfalls Platzhalter für einen größeren Bereich. Ich vermute zwar auch (ohne mir die unten genannte Studie genau angeschaut zu haben), dass die thematischen Überschneidungen von Durchschnittsfrau und Durchschnittsmann größer als die Abweichungen sind. Aber dass es solche Abweichungen gibt, kann man mMn nicht in Frage stellen. Das wurde ja auch in Studien gezeigt, z.B. in WP:Clubhouse? An Exploration of Wikipedia’s Gender Imbalance (H2a und H2b in Table 7). Könnte in DACH natürlich total anders sein oder sich in den letzten 5 Jahren geändert haben, aber ich glaube nicht daran. --Grip99 01:17, 21. Jul. 2013 (CEST)

Wo werden solche Änderungen eigentlich angekündigt? Da jammern die WMF-Jungs/Mädels/Unbekannt immer, dass die Hürde für neue Autoren zu hoch sei, und diese noch vor ihrem ersten Beitrag vergrault würden, und dann bauen sie so eine nervige "Umfrage" ein! Ein Pop-Up, direkt nach der Anmeldung, was kann man sich mehr wünschen! Zum Glück habe ich das bei meiner Anmeldung nicht zu Augen bekommen, denn ich hätte mich darüber aufgeregt. Insbesondere, wenn es redundant zu bereits bestehenden Einstellungen ist (diese aber auch nicht aktualisiert). --Patrick87 (Diskussion) 13:19, 12. Jul. 2013 (CEST)

Spielt jetzt keine Rolle mehr, aber das Schlimmste ist: es ist viel, viel, viel, viel, viel zu viel Text für eine ganz simple Frage. Das überfordert 80% der Neuanmelder. --Filzstift ✏ 15:54, 17. Jul. 2013 (CEST)

Ist es nicht merkwürdig, dass diese Erweiterung in der englischen Sprachversion raus- und ausgerechnet bei uns reingenommen wird?--Sinuhe20 (Diskussion) 16:13, 13. Jul. 2013 (CEST)

Ich verstehe den Sinn insofern nicht dahinter, wo doch jeder weiß, dass das zu 90 % nicht korrekt angeklickt wird. Also kann ich mir nur ein Wichtigmachen eines Einzelnen (oder Gruppe) vorstellen. Dem sollte aber möglichst bald der Garaus gemacht werden. --K@rl 16:21, 13. Jul. 2013 (CEST)

Um die Eingangsfrage zu beantworten: offensichtlich, denn im Moment läßt man in Frisco keine Möglichkeit aus, neuen Benutzern den Zugang so erschreckend wie möglich zu gestalten und gleichzeitig bestehende Autoren zu vergraulen. Keine der Maßnahmen der letzten Jahre hat sich in irgendeinerweise positiv ausgewirkt. --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 16:38, 20. Jul. 2013 (CEST)

Sag ich doch. Bei der Foundation hasst man die Autoren. Die sind im Weg bei der Verwaltung der Projekte. Ohne den Pöbel wäre das viel einfacher. Marcus Cyron Reden 17:20, 20. Jul. 2013 (CEST)

VisualEditor wird sich nicht abschalten lassen!

In den obigen "Tech news" steht es "VisualEditor will be enabled for all logged-in English Wikipedia users on July 1, and for all users on July 8.". Auf der englischen Wikipedia ist diese Änderung gerade in Kraft getreten. Und hier gab es gerade die offizielle Bestätigung (für die, die ihren eigenen Augen nicht trauen können): VisualEditor wird verpflichtend sein, es wird keine Möglichkeit geben ihn zu deaktivieren!

Ich weiß nicht wie ihr dazu steht, aber für mich scheint es als ob die WMF langsam außer Kontrolle gerät. Nach zahllosen "Kleinigkeiten" wie den neuen Notifications, dem Universal Language Selector, der Neugestaltung der Editsection-Links, etc., die alle auf mehr oder weniger starken Widerstand stießen, hat die WMF nichts dazu gelernt. Im Gegenteil: Mit einem Glockenschlag wird der neue VisualEditor verpflichtend – und das obwohl die Option zum deaktivieren (bislang musste man ihn ja explizit aktivieren) ja eigentlich vorhanden ist! Statt diese jedoch anzubieten wird sie vorsätzlich entfernt! Ich bin entsetzt und sprachlos... Wo soll das alles noch hinführen? --Patrick87 (Diskussion) 00:40, 2. Jul. 2013 (CEST)

Das Interface wird nicht Pflicht und das steht auch nicht in der Debatte auf En.WP. Worüber Oliver & Co drüben diskutieren, ist die Möglichkeit für interessierte Nutzer ggf. VE per Gadget (oder so) komplett auszublenden. "Default" hat in dem Kontext nichts mit irgendeiner Pflicht seitens der Community zu tun, Gruß --Jan (WMF) 01:01, 2. Jul. 2013 (CEST)

"Ausblenden"! Das ist der Punkt! Man wird es mit irgendwelchen Tricks vielleicht verstecken können (die bereits jetzt drüben zu Problemen führen); Abschalten wird man den VisualEditor jedoch nicht können. Verbunden mit allen Nachteilen die er bringt:

• Unnötig verlängerte Ladezeit der Seiten wegen größerer JavaScript-Dateien.
• Verlangsamter Seitenaufbau bei erhöhtem Ressourcenverbrauch auf Grund der JavaScript-Ausführung.
• Verzögertes Erscheinen von Seitenelementen, nachträgliches Verschieben des Seitenlayouts, etc. da die Inhalte von JavaScript eben dynamisch geladen werden (nach [!] dem ersten Seitenaufbau im Browser)

Und das weil die WMF denkt zu wissen was gut für uns ist und dabei so weit geht uns zu bevormunden. "Default" ist recht und gut wenn es eine Wahlmöglichkeit gibt. Diese wurde jedoch vorsätzlich [!] mit der finalen Veröffentlichung entfernt. Während der Beta-Tests war die Checkbox in den Benutzereinstellungen unter "Bearbeiten" noch verfügbar (so wie zur Zeit noch hier in der Deutschen Wikipedia). Mit der zwangsweisen Aktivierung des VisualEditors für alle ist diese jedoch verschwunden. Ich persönlich finde dieses Verhalten seitens der WMF eine Katastrophe. --Patrick87 (Diskussion) 01:19, 2. Jul. 2013 (CEST)

Jan, du bist doch ein "Community Advocate" oder so. Dann sag jetzt bitte deinen Brötchengebern, dass sie gerade massive Scheiße bauen. Ich habe gerade mal testweise bei einem englischen Artikel auf Bearbeiten geklickt und elektronisch gestoppte 25 Sekunden einen lustigen blauen Ladebalken zu sehen bekommen. Totaler Murks. Stefan64 (Diskussion) 01:22, 2. Jul. 2013 (CEST)

Nachdem ich merkte, daß ich den rechten der beiden Bearbeitungsknöppe drücken mußte, hatte ich kein Problem mehr mit Irgendwas. Marcus Cyron Reden 01:50, 2. Jul. 2013 (CEST)

Jo, du kannst auch extra für das Editieren in Wikipedia in deinem Browser Javascript deaktivieren. Aber es kann ja wohl nicht angehen, die Community mit dieser Bananaware zwangszubeglücken. Gruß, Stefan64 (Diskussion) 02:05, 2. Jul. 2013 (CEST)

Da der Visual Editor praktisch keine Akzeptanz hat wird der jetzt per Brechstange durchgedrückt um die massig verschwendeter Spendengelder irgendwo rechtfertigen zu können. Das Ding ist heute noch ziemlich unbrauchbar und ich hab das Ding letztens ausprobiert. --Codc ^Disk Chemie _{Mentorenprogramm} 02:17, 2. Jul. 2013 (CEST)

Ich habe keine Wertung abgegeben - nur meine Erfahrung geschildert. Marcus Cyron Reden 02:20, 2. Jul. 2013 (CEST)

Die in Wiki-en praktizierte Lösung, wobei „Edit“ zum VE führt, während man bei „Edit Source“ zum Quelltext gelangt, finde ich beim jetzigen Entwicklungsstand des VE für sehr praktikabel. Beim Editieren des Fließtexts stark durch Quellcode zergliederter Artikel ist der VE eine Arbeitshilfe, beim Editieren im Formalienbereich des Quellcodes überwiegen die Vorteile des Quellcode-Editors. Ich bin mit der raschen Neuerungs-Frequenz innerhalb der WP nicht unbedingt glücklich, den VE finde ich dennoch für begrüßenswert.-- · peter schmelzle · disk · art · pics · lit · @ · 02:26, 2. Jul. 2013 (CEST)

Ich muss den Kritikern zustimmen. Hier wurde von irgendwelchen mächtigen Leuten unter dem Vorwand der Benutzerfreundlichkeit mal wieder ein Schrott eingeführt, ohne die Benutzer zu fragen, ob sie das überhaupt haben wollen. Das Article-Feedback wurde gerade zum Glück mit 2/3-Mehrheit eines Meinungsbilds abgeschafft. Jetzt arbeitet die Foundation erneut gegen die Benutzer. Ich habe mir den Visual Editor gerade mal in einem Artikel der en.wiki angesehen. Das macht das Bearbeiten nicht einfacher, sondern viel komplizierter. Man muss nicht nur auf das Laden der Seite warten, sondern auch für alles außer reinen Text-Änderungen doppelt und dreifach klicken. Beispiel Wikilink: Normalerweise setze ich das Lemma des Linkziels einfach in eckige Klammern. Beim VE muss ich für einen neuen Link erst auf eine Grafik klicken, dann das Wort schreiben und drittens aus einer Liste von Vorschlägen auf ein Lemma klicken. Zur Bearbeitung eines Links muss ich erst auf das Wort und dann auf einen Bildchen klicken, bevor ich das Lemma des Linkziels ändern darf. Das soll einfacher sein? Bei Grafiken ist es noch schlimmer. Da darf ich nur ein Bild auswählen, das mir zu einem Suchbegriff angeboten wird, und kann gar keine Einstellungen zur Größe, Position etc. angeben. Bei einem vorhandenen Bild darf ich sogar nur die Bildunterschrift bearbeiten. Von Vorlagen ganz zu schweigen.

Pflicht ist der Schrott sehr wohl, Herr Eissfeldt. Ich kann nämlich nicht mehr auf "Bearbeiten" klicken, sondern muss einen anderen Link bemühen, um zum Standard-Bearbeitungsfenster zu gelangen. Außerdem kann ich den Schrott nicht deaktivieren. --MSchnitzler2000 (Diskussion) 02:27, 2. Jul. 2013 (CEST)

Die WMF vertritt die Community, nicht andersrum. Also hat sie sich gefälligst nach unseren Wünschen zu richten und nicht andersrum. Eine Zwangseinführung dieses VisualEditor ist selten dämlich und sollte dringend unterbunden werden. Ansonsten sehe ich schon den nächsten großen Proteststurm kommen (wie z. B. damals beim Bildfilter). -- Chaddy · D – DÜP – 04:15, 2. Jul. 2013 (CEST)

Nö, wie ich drüben beim Kurier schrieb kann das natürlich ausgeblendet und mithin ignoriert werden. Zur Preference-Frage hat Erik hier die FAQ erweitert. Aus der Sachlage mittels AFT-Analogie - das Tool wurde ebenfalls nicht per WMF-Ukas global eingeführt, sondern auf De.WP nach dieser Umfrage in den Test ging - eine Art Pflicht konstruieren zu wollen, erscheint mir reichlich weit hergeholt.

Das die Ladezeit deutlich zu lang ist, ist bekannt und auf der Agenda (offensichtlich; als ich im Mai mit dem Ding gespielt hab lag die Ladezeit bei ~16 Sekunden). Gruß, --Jan (WMF) 07:03, 2. Jul. 2013 (CEST)

Hallo Chaddy vielleicht sollten wir wieder zur Wikipedia des Jahres 2005 zurückkehren. Damals gab es auch noch kein spezielle angepassten Monobook,js von PDD bzw. Littl.

Das Problem ist doch, dass genau wie heute in der Fahrzeugindustrie der Nutzer/Kunde zum Testpiloten wird. Wurden früher erst die ausgereiften Produkte auf den Kunden losgelassen, wird ihm heute ein unfertiges Produkt verkauft und dann ständig nachgebessert. liesel 07:36, 2. Jul. 2013 (CEST)

Also zumindest bei mir (Opera + Monobook) kommt kein Visual Editor. Ist der für diese Konstellation explizit deaktiviert? -- Liliana • 07:09, 2. Jul. 2013 (CEST)

Opera und Internet Explorer werden momentan nicht supported. Stand der Dinge diesbezüglich umfasst afaik Support für FF 11+, Iceweasel 10+, Chrome ?16+, und Safari 6+, Gruß --Jan (WMF) 07:16, 2. Jul. 2013 (CEST)

Und das ist dann die WMF-Definition von "VisualEditor is the new default experience for all users."? So steht es nämlich in der FAQ die du verlinkt hast. Schade, dass die Nutzer von Opera und Internet Explorer nicht zu "allen Benutzern" zählen. Ihr dreht es doch gerade so wie ihr es braucht! Entwickelt den VisualEditor fertig, sodass er wirklich parallel zum WikiEditor läuft und nicht dessen Nutzung ebenfalls erschwert. Dann dürft ihr von mir aus auch Einstellungen zum deaktivieren weglassen. Bis dahin tobt euch mir eurem Feature-Experiment woanders aus (oder macht es abschaltbar). --Patrick87 (Diskussion) 11:38, 2. Jul. 2013 (CEST)

In Opera 15 (heute erschienen und jetzt nicht mehr Presto-, sondern Blink-basiert) funktioniert der VisualEditor. --Entlinkt (Diskussion) 21:58, 2. Jul. 2013 (CEST)

Das ist leider die Richtung, die man in der Webentwicklung (nicht nur bei WMF) schon seit Jahren geht. Weg von einfachen Lösungen, hin zu ressourcenfressendem JS-Müll mit unnötigen Animationen und benutzerunfreundlichen Lösungen.. DestinyFound (Diskussion) 07:52, 2. Jul. 2013 (CEST)

Schonmal vormerken, wenn der Schrott zu uns kommt: en:User:DestinyFound/monobook.css. DestinyFound (Diskussion) 08:30, 2. Jul. 2013 (CEST)

"Das die Ladezeit deutlich zu lang ist, ist bekannt und auf der Agenda" (Eissfeldt WMF). Ja das ist ja schön, dankeschön. Aber wieso zum Henker wird das Ding jetzt bereits auf die Menschheit losgelassen? Als Standardoberfläche einer der meistfrequentierten Webseiten der Welt? Bei Google oder Amazon wären nach so einer Aktion wohl etliche Leute ihren Job los und die CEO würden mit geknickter Miene in allen Nachrichtensendungen ihre Kunden um Verzeihung bitten. Stefan64 (Diskussion) 08:58, 2. Jul. 2013 (CEST)

Hallo, DestinyFound. Danke für den Link. Ich habe die Formate gerade bei mir in der englischen Benutzerseite eingetragen. Gruß --Tlustulimu (Diskussion) 09:00, 2. Jul. 2013 (CEST)

Stefan64 aber dem überwiegenden Teil der Wikipedia-Besuchern es wahrscheinlich sowieso egal ob es einen VE gibt oder nicht, die klicken sowieso nicht auf den "Bearbeiten"-Button. Also nicht Leser mit Editoren verwechseln. liesel 09:12, 2. Jul. 2013 (CEST)

Erfahrungsbericht einer kleinen Änderung: hatte vorhin versucht eine Commonskategorie in einem Artikel auf en einzusetzten: grauselig. bis ich die Vorschau gefunden hatte... dann wurde {{Commonscat}} mit den nowiki-Klammern umgeben. Wieder zurück. Irgend etwas buntes drücken und dann wieder warten, warten, warten um speichern zu können. Ich verbringe ja jetzt schon mehr Zeit auf Wikidata mit dem Warten, dass meine Änderung gespeichert und neu geladen wird, als mit konstruktivem Arbeiten und habe dann ich trotzdem noch ständig BKs, weil meine eigene Änderung noch nicht geladen war, als ich die nächste startete... (herrlich bei Quellenangaben! – das frustet!) Wenn das mit dem VE auch so wird... Gute Nacht. (die "richtige" Position des Commonscat-Bausteines war jedenfalls erst nach dem Speichern ersichtlich. Vorschau Fehlanzeige. Die Auswahlmöglichkeiten für dieses einfache Template haben mich erschlagen, zum Glück hatte ich das "richtige" ausgewählt. Kleinständerungen vorprogrammiert?)

Merke: tab edit source nutzen, tab edit weiträumig meiden. --PigeonIP (Diskussion) 09:31, 2. Jul. 2013 (CEST)

Das Eine muss das andere nicht ausschliessen. Also, ich finde VisualEditor noch praktisch, ich nutze es, um Typos zu beheben oder sonstige Kleinigkeiten am Text zu ändern (also keine Links, Vorlageneinbindungen usw.). Denn dank VisualEditor muss ich die fragliche Passage nicht noch mal suchen, wie das beim Quelltext-Editieren der Fall ist, sondern kann direkt "draufschreiben". Für komplexere Sachen wiederum nutze ich das übliche Editfenster (also "Quelltext bearbeiten" statt "Bearbeiten"). Und wen VisualEditor stört, der muss es einfach nicht nutzen. Deaktivieren/ausblenden und gut ist's. --Filzstift ✏ 09:39, 2. Jul. 2013 (CEST)

Ich wäre sehr dafür, über die Einführung des Visual Editor als Standardeditor ein Meinungsbild abzuhalten und das Tool bei Ablehnung standardmäßig abzuschalten.--Aschmidt (Diskussion) 15:52, 2. Jul. 2013 (CEST)

Für uns wird hier sicherlich niemand eine Extrawurst machen. Und an den Visual Editor muss man sich jetzt sowieso schon gewöhnen, denn wenn dieses Flow Portal (= Diskussionsseite/Liquid Threads 2.0) kommt, wird der zum Standardwerkzeug für die Erstellung von Diskussionsbeiträgen, jedoch ohne Möglichkeit, weiterhin Wikitext zu nutzen.

Generell stört mich die Einstellung der WMF zu den erfahrenen Benutzern. Es ist ja schön und gut, dass man den Visual Editor mit Helferlein oder Javascript deaktivieren kann, aber diese Tools muss sich die Community selbst schreiben und diese selbst warten, nach jedem Softwareupdate geht das Ding erst mal wieder in die Knie und muss repariert werden. Außerdem sehe ich nicht ein, immer mehr Skript-Mist dazuzuschalten, nur weil die WMF zu faul ist, weiterhin ein wenig wartungsintensives Textfeld mit zwei Knöpfen drunter zu betreiben. Und da ist es mir auch völlig egal, ob irgendwelche Studien bewiesen haben sollen, dass ich mich mit dem Visual Editor zurechtfinden muss. Das will ich gern immer noch selbst entscheiden. IW 16:05, 2. Jul. 2013 (CEST)

„Für uns wird hier sicherlich niemand eine Extrawurst machen.“ - Die Foundation kann es sich nicht leisten, einen Communitybeschluss ihrer zweitgrößten lokalen Gemeinschaft zu ignorieren. Das würde nach hinten losgehen. -- Chaddy · D – DÜP – 16:18, 2. Jul. 2013 (CEST)

Vielleicht ist es ja an der Zeit, einen Shitstorm zu starten... ;-) ÅñŧóñŜûŝî (Ð) 16:20, 2. Jul. 2013 (CEST)

Glauben würde ich es gern. Bei so einem zentralen Projekt hab ich da aber meine Zweifel. IW 16:21, 2. Jul. 2013 (CEST)

Da ist so viel Kohle reingeflossen, die sind in Zugzwang. Vielleicht ist ein großer Crash aber mal ganz hilfreich. Gruß, Stefan64 (Diskussion) 16:24, 2. Jul. 2013 (CEST)

Genau, ziurück zur Wikipedia von 2001. Der ganze neumodische Scheiassdreck und Firlefanz muss weg. 2001 ging es ja auch ohne. liesel 16:30, 2. Jul. 2013 (CEST)

Das nicht gerade. Aber weg von einer Wikimedia, die Leute beschäftigt, die Erfolge für die Statistik melden müssen. Schade, dass eine Software keine Rakete ist.... --Alupus (Diskussion) 16:36, 2. Jul. 2013 (CEST)

Also doch solide Russentechnik statt amerikanisches High-Tech? liesel 16:38, 2. Jul. 2013 (CEST)

Ay Yo! ;) Marcus Cyron Reden 18:04, 2. Jul. 2013 (CEST)

solide wäre schon mal ein Anfang. IW 16:40, 2. Jul. 2013 (CEST)

Ist halt die Frage was solider ist, von Freiwilligen nach Lust und Laune zusammengeschriebene Software oder von bezahlten Kräften zusammengeschriebene Software denen eine gierige Autorenmeute im Nacken sitzt. liesel 16:47, 2. Jul. 2013 (CEST)

Bei Betriebssystemen von Servern, wo Solidität mehrere Größenordnungen wichtiger ist als alles andere, ist diese Frage übrigens längst zugunsten des Freiwilligen-Produkts entschieden...---<)kmk(>- (Diskussion) 20:08, 2. Jul. 2013 (CEST)

Linux dürfte auch bei Servern unter 50 % Marktanteil haben - und wird vor allem sehr wohl überwiegend von Profis in ihrer Arbeitszeit entwickelt. --YMS (Diskussion) 20:16, 2. Jul. 2013 (CEST)

Je nach Quelle sind es über 60 %: [26] -- Chaddy · D – DÜP – 21:32, 2. Jul. 2013 (CEST)

Auch 60 % hießen nicht "die Frage ist längst entschieden", aber worauf's mir primär ankam, war ohnehin, zu sagen, dass Linux kein "Freiwilligen-Produkt" ist, zumindest nicht in größerem Maße als das etwa bei der Entwicklung von MediaWiki der Fall ist. Seventy-five percent of all kernel development is done by developers who are being paid for their work. --YMS (Diskussion) 21:42, 2. Jul. 2013 (CEST)

Man muss immer unterscheiden, für wenn man etwas macht. Für erfahrende Wikiautoren ist das erstmal nichts, weil diese sich auch mit Vorlagen und sonstigen Dingen schon besser auskennen und somit bei der Wikisyntax mitkommen. Für Neulinge könnte es aber die Chance sein, hier auch mit zumachen und kleine Ergänzungen vorzunehmen. Man ließt an verschienenen Stellen, das die Bearbeitungsoberfläche von Wikipedia zu altmodisch ist/zu unhandlich usw. Hier muss WMF jetzt eine Gradwanderung hinbekommen und das wird wohl nichts, wenn sie den VisualEditor erzwingen. Wenn man das parallel hält ist das in Ordnung, daher sehe ich eine Option zum deaktivieren dieser Sache als zwingend an, so dass Poweruser von dieser Änderung nichts mitbekommen. Damals konnte man sich auch von Vektor wieder für Monobook entscheiden. Veränderungen werden von vielen Leuten erstmal als blöd/brauch ich nicht gesehen, entweder überzeugt man die Leute, was hier wohl schwierig wird oder man bietet die Möglichkeit, diese Neuerung komplett wieder zu deaktivieren und keinerlei Nebenrauschen davon mitzubekommen und das sollte auf jedem Fall erfolgen (Wird wohl nicht komplett gehen, weil der VisualEditor noch den Quelltext zumüllt, aber der Versuch sollte da sein). Der Umherirrende 18:02, 2. Jul. 2013 (CEST)

Das sehe ich genau so. Der alte Editor ist in die Jahre gekommen. Ein neuer Editor, der weg von Wiki-Quellcode und hin zu einer WYSIWIG-Oberfläche geht, spricht vielleicht (endlich wieder) neue Autoren an, die höhere Anforderungen an die GUI-Convenience stellen, als sie der alte Editor zu leisten vermochte. -- · peter schmelzle · disk · art · pics · lit · @ · 18:12, 2. Jul. 2013 (CEST)

Das Problem mit der Ladezeit kann sowohl durch die Interaktion des Editors mit dem jeweils genutzten Browser (siehe hier) verstärkt werden als auch (temporär) mit Bug 50441 zusammenhängen. Das eine Beta-Version einer Software keine Rakete ist, sollte - wie Liesel und DestinyFound oben schrieben - nicht überraschen. Es geht bei Beta erstmal darum, die bestehenden Funktionen sauber ins Laufen zu bekommen. Dafür brauchen die neben Codern, die das Ding basteln, auch die Nutzer um die Probleme in dem Ding zu finden.
Zu den nowiki-Problem von oben hab ich Heute auf En.WP nochmal diffs gesammelt und den zugehörigen Bug wieder aufgemacht. Da scheint es primär drei Auslöser für die automatisch-nicht beabsichtigte Einfügung von "<nowiki> </nowiki>"zu geben. War das mit Abstand häufigste Problem, das mir da beim durchklicken der RC über den Weg lief und muss gefixt werden. Gruß, --Jan (WMF) 16:55, 2. Jul. 2013 (CEST)

Eine Beta-Version einer Software, die für alle zwingend aktiviert ist... Ihr bei der WMF seit wirklich innovativ, das muss ich euch lassen. Vorlage:Smiley/Wartung/;)  --Patrick87 (Diskussion) 17:02, 2. Jul. 2013 (CEST)

Ist dieser unfertige Editor für alle Namensräume vorgesehen oder nur für Artikel? --Tlustulimu (Diskussion) 17:14, 2. Jul. 2013 (CEST)

Erstmal nur Artikel und Benutzerseiten. --Lydia Pintscher (WMDE) (Diskussion) 17:24, 2. Jul. 2013 (CEST)

Ich kann nicht nachvollziehen, dass die Beta-Version zwingend aktiviert ist. In den Einstellungen ist dieser Punkt nicht angehakt. Woher rührt dann der Vorwurf, dass eine zwingende Aktivierung erfolgte? liesel 17:19, 2. Jul. 2013 (CEST)

Er wurde gestern (1. Juli) in der englischen Wikipedia zwingend aktiviert und wird am 8. Juli auf allen anderssprachigen Wikipedias zwingend aktiviert werden (wenn die WMF Entwickler bis dahin nicht die Nase voll haben). Steht in meinem Eröffnungskommentar zu diesem Abschnitt Vorlage:Smiley/Wartung/;) . --Patrick87 (Diskussion) 17:51, 2. Jul. 2013 (CEST)

Ich verstehe weder die Überschrift noch die Aufregung. Es wird doch niemand gezwungen das Teil zu benutzen. Es gibt einfach einen Link zu einer weiteren Bearbeitungsmöglichkeit. Die klassische Möglichkeit über den Quelltext ist doch immer noch vorhanden. --Engie 17:22, 2. Jul. 2013 (CEST)

Die Überschrift ist unglücklich gewählt - enabled <> compulsory - Das Ding muss man schon selbst einschalten. Evtl. ist das bei neuen Benutzern und/oder etwas anderem als monobook ja auch anders. Ich habe die ÜS bis zur Klärung mal etwas entschärft. Grüße --Nolispanmo Disk. Hilfe? 17:31, 2. Jul. 2013 (CEST)

Nochmal zur Klarstellung: Auf der deutschen Wikipedia tritt die Änderung die wir hier diskutieren erst zum 8. Juli in Kraft. Auf der englischen Wikipedia ist der VisualEditor jedoch bereits seit gestern aktiv (für jeden – ohne die Möglichkeit ihn in den Einstellungen zu deaktivieren). --Patrick87 (Diskussion) 17:55, 2. Jul. 2013 (CEST)

Aber mit der Möglichkeit ihn zu ignorieren, da das normale Bearbeiten weiterhin möglich ist (oben gibt es Links auf CSS-Beispiele). Der Umherirrende 18:03, 2. Jul. 2013 (CEST)

Das ist wohl der Punkt an dem wir uns im Krais drehen... Meine Argumente warum "ignorieren" nicht reicht habe ich oben bereits dargelegt. Und selbst wenn ich ihn ignoriere/ausblende, dann müssen die meisten anderen Nutzer trotzdem damit leben. Wir haben also eigentlich nicht nur ein Problem, sondern zwei! Denn wenn der VE kein Klotz am Bein wäre, und wirklich parallel funktionieren würde, könnte ich mich vielleicht damit abfinden. --Patrick87 (Diskussion) 18:09, 2. Jul. 2013 (CEST)

Sorry ich verstehe es einfach nicht. Warum willst du den VE abschalten (laut neuer Überschrift). Du brauchst ihn doch nicht benutzen. Und der neue Link in der Bearbeitungsleiste verlängert wohl kaum signifikant die Ladezeit der Seite. --Engie 18:19, 2. Jul. 2013 (CEST)

Doch tut er. Mach mal den Selbsttest: Lade eine Wikipedia Seite einmal normal, und einmal mit im Browser deaktiviertem JavaScript. Du wirst erstaunt sein! Neben diesem allgemeinen Trägheitsproblem auf Grund von JavaScript stören mich einige Dinge am VE jedoch ganz besonders (die dazu führen, dass ich ihn auch nicht einfach ignorieren kann):

• Der "Bearbeiten" Button wird erst eingefügt nachdem die Seite schon geladen ist. Das führt zu fleißigem Blinken und Zappeln, wo ich einfach einen (oder von mir aus auch zwei) fixe "Bearbeiten" Links erwarten würde.
• Die "Bearbeiten" Links pro Abschnitt sind mit lästigen Hoverfunktionen belegt. Um überhaupt auf "Quelltext bearbeiten" klicken zu können, sprich die gleiche Funktionalität (die bisher mit einem Klick erreichbar war) zu erhalten, muss ich erst auf "Bearbeiten" hovern, kurz warten, dann den Cursor zu "Quelltext bearbeiten" bewegen und klicken. Total unpraktisch.
• Da der VE noch nicht in allen Namensräumen aktiv ist führt mich ein "Bearbeiten" Link manchmal zum neuen VisualEditor, manchmal zum klassischen Wikitext Editor. Die Beschriftung ist inkonsistent, naiv gesagt weiß ich zunächst nicht, was ich zu erwarten habe. (Klar weiß ich mittlerweile in welchen Namespaces der VE aktiv ist, aber Benutzerfreundlichkeit ist anders).
• Der durch den VE unnötig verkomplizierte Seitenquelltext ist fehleranfällig. Gutes Beispiel: Das erst kürzlich aktualisierte MediaWiki:Gadget-editsection-align-end.css funktioniert dank der Klicki-Bunti-Hover-Buttons nicht mehr richtig. Klar "die WMF unterstütz keine Gadgets", aber man kann HTML-Code auch so schreiben, dass er kompatibel bleibt und muss nicht wie die Axt im Walde wüten. Das genannte Gadget ist überhaupt bloß nötig geworden, weil die WMF krz davor den Einfall hatte, die Bearbeiten-Links von rechts nach links zu verschieben.

Und jetzt habe ich dir die Sachen aufgelistet, die mich am VE stören, wenn ich ihn nicht verwende. Ich fang erst gar nicht damit an aufzulisten was mich am VE selbst alles stört (der ja eigentlich gerade für die breite Masse gedacht ist!). Wie sollen neue Autoren damit klar kommen, wenn ich daran verzweifle? --Patrick87 (Diskussion) 18:46, 2. Jul. 2013 (CEST)

Schreiben die Leute, die dieses Ding aktivieren, bitte gleichzeitig auch alle Hilfeseiten um? Das wird wieder mal das reinste Chaos geben, so wie die Einführung der Beta-Version von Wikidata (ach was, das ist noch nicht mal Beta, wenn man nicht mal Commons integriert hat). --AndreasPraefcke (Diskussion) 18:12, 2. Jul. 2013 (CEST)

Unter mw:Help:VisualEditor/User guide hat das Entwicklungsteam Dokumentation geschrieben und könnte noch Hilfe bei der Übersetzung brauchen. --Lydia Pintscher (WMDE) (Diskussion) 18:21, 2. Jul. 2013 (CEST)

Das ist die Info auf deren Grundlage die hiesigen Hilfeseiten umgeschreiben werden können -- mehr aber auch nicht.---<)kmk(>- (Diskussion) 19:36, 2. Jul. 2013 (CEST)

Also ich habe in "en" lediglich eine neue zusätzliche Bearbeitungsmöglichkeit und kann da nach wie vor wie früher editieren. Mangelt es hier vielleicht in erster Linie (neben technischem Verständnis und einem gewissen Maß an nettem Umgangston) in erster Linie an Englischkenntnissen? Insgesamt empfinde ich diese Diskussion um eine technische Neuerung eher schräg und Aussagen von Admins, die den Weltuntergang heraufbeschwören nachdem sie ein Tool das erste Mal genutzt haben (während sie in dem anderen mehrere 10.000 Edits Erfahrung haben) finde ich absolut unpassend. Gemessen an den eigenen technischen & sozialen Ansprüchen und Erwartungen in Diskussionen und Wahlen sollte man ab und an auch mal das eigene Wirken hinterfragen. Wie so oft wir die schweigende Mehrheit mehr verstanden haben haben, aber ohne Kommentare wie z.B. den von Filzstift (und auch den Gedanken, dass es ja auch um User mit weniger als zehn Jahren Wiki-Erfahrung geht) würde mir hier um die Zukunft von "de" Angst und Bange - und das nicht wegen des neuen Spielzeugs .... --mirer (Diskussion) 21:42, 2. Jul. 2013 (CEST)

Tja, das ist nicht anders als wie bei häufig eingebundenen Vorlagen: wenn eine Änderung nicht sofort perfekt funktioniert, gibt es verbal Prügel... ÅñŧóñŜûŝî (Ð) 21:45, 2. Jul. 2013 (CEST)

Mathjax hat auch nicht auf Anhieb funktioniert und es gab keine dieser emotionalen Diskussionen. IMHO, liegt die Ursache für die Prügel in einem anderen Aspekt: Sie werden provoziert, wenn relevante Neuerungen ohne vorherige Konsultation/Diskussion/Mediation der Autoren vorgenommen werden. Es gehört nicht viel dazu, um auf deren Seine eine aus dem Gefühl mangelnden Respekts gespeiste Frustration zu vermuten. Mündige Mitarbeiter fühlen sich eben nicht gerne als Schafsherde behandelt. Aus der sich daraus ergebenden negativen Grundstimmung erscheinen berechtigte inhaltliche Kritikpunkte dann besonders krass.---<)kmk(>- (Diskussion) 21:37, 3. Jul. 2013 (CEST)

WMF tech hat sich das oben und auf WD:K aufgeworfene Problem mit den 119 KiB von VisualEditor, das auch die User mit Gadget betrifft, nochmal vorgenommen und das Volumen gestern auf 4 KiB gedrückt. AFAIK lädt Mediawiki regulär rund 200 KiB, d.h. VE sind jetzt ~2%. Der Rest von dem Code wird nur geladen, wenn der User selbst (erstmalig) auf "Bearbeiten" statt "Quelltext bearbeiten" klickt.
Ebenfalls ausgebaut wurde die Dokumentation zum Bearbeiten von Belegen, die jetzt wie die FAQ übersetzungsreif sein sollte. Beim nowiki-Bug, der (meinem Eindruck nach weiterhin relativ willkürlich) ungebetene Wiki-Syntax in einige Artikel packt, gibts noch keine Lösung. Ich hab dazu dirty diffs zu unterschiedlichen Syntax-Auslösern eingereicht, gruß --Jan (WMF) 22:43, 5. Jul. 2013 (CEST)
Upd.: Ein Meeting gestern Nacht hat beschlossen, dass der Zeitplan global um eine Woche nach hinten verlegt wird um die Probleme (insb. dirty diffs., Bug 50441 oben) besser angehen zu können. D.h. nächsten Montag findet kein Deployment für IPs auf En.WP statt, sondern das wird auf den 15. Juli verlegt; De.WP & Co rücken auf den 22.07. Das offizielle Statement von James findet sich hier, Gruß --Jan (WMF) 09:59, 6. Jul. 2013 (CEST)

Danke für das Update und wenn du mit der Intervention etwas zu tun hattest, dann auch dafür. Grüße --h-stt !? 19:01, 8. Jul. 2013 (CEST)

Ja, langsam wird das Teil wenigstens benutzbar. Ob brauchbar sei mal dahingestellt... --Patrick87 (Diskussion) 19:20, 8. Jul. 2013 (CEST)

Update zum nowiki-Problem: Tech hat übers Wochenende 49820 und in der Vorwoche andere Bugs zu dem Thema gefixt. Der 49820-Kniff soll verhindern, dass Wikicode und VE während des Bearbeitens kollidieren und so nowiki-Reaktionen (seitens VE) vermeiden. Plangemäß soll das über Nacht - ungefähr zusammen mit den Hinweis-Bannern für den 22.07 - freigeschaltet werden, Gruß --Jan (WMF) 19:08, 15. Jul. 2013 (CEST)

Updates:

• Flow: Es gibt neues zu dem Fragenkomplex VE - Flow. Flow wird die Nutzung von VE nicht erzwingen.
• Dokumentationsseiten: Ich hab wie auf der Seite für Rückmeldungen versprochen den Rohbau von FAQ, Handbuch sowie die Seiten zu TemplateData und zugehörige Hilfeseite von Mediawiki rübergeholt; viele Dank an die Benutzer, die die meisten PD-Texte schon übersetzt hatten und Screenshots für das deutschsprachige Interface einfügen. Diese Materialien sind relativ stabil, aber ich geh da die Tage nochmal sprachlich und lokalisierend rüber, baue die Klarstellung zu Flow ein und Tech hat zudem die Fußnotenfunktion von VE komplett umgebaut (hab ich aber noch nicht ausprobiert). Zu letzterem erwarte ich Anfang der Woche auch Neuerungen bei der Dokumentation (60/40).
• Neuer Zeitplan: Die Überarbeitungen kollidieren nicht mit dem Deployment, denn Tech hat den Zeitplan nochmal nach hinten verschoben um neuen Bugs besser begegnen zu können. Ich hab den gegenwärtigen Stand der Dinge hier notiert.

So weit erstmal, Gruß --Jan (WMF) 04:27, 20. Jul. 2013 (CEST)

Zum ersten Punkt: Bislang ist ausschließlich die Rede von einem "fall-back" für den VE (für Personen ohne JavaScript oder mit Screenreader). Der bekannte WikiEditor wird in Flow nicht verfügbar sein. Wie dieses fall-back aussehen wird und in wie weit die Funktionen eingeschränkt sein werden ist bislang unbekannt! --Patrick87 (Diskussion) 12:11, 20. Jul. 2013 (CEST)

Zum Zeitplan: Ein paar Tage Verschiebung werden nichts daran ändern können, dass der VE das Minimalziel nicht erreicht, das ein Ersatz der herkömmlichen Edit-Technik leisten muss -- er muss mit allen relevanten Edit-Bedürfnissen der Wikipedia klar kommen. Das scheitert schon an seiner Unfähigkeit, Formeln zu bearbeiten. Das macht den VE unbrauchbar für Artikel aus den Bereichen Mathematik, Physik, Chemie, Maschinenbau, Elektrotechnik, etc. Also Gebiete, die zum unverzichtbaren Kern einer Enzyklopädie gehören. Desweiteren ist es nicht möglich Sonderzeichen einzugeben, die nicht direkt von der Tatstatur aus erreichbar sind. Das ist etwas ungünstig für Artikel mit nicht-europäischem Lemma. Bilder-Galerien sind für den VE ebenfalls eine No-Go-Area. Zusätzlich weist der VE massive Usability-Schwächen auf. Das fängt bei den Mouse-over-Pop-up-Edit-Knöpfen an und hört mit einer während des Editiervorgangs nicht bearbeitbaren Zusammenfassungszeile noch lange nicht auf.

Direkte Frage: Wollt ihr dieses Schiff wirklich auf Grund laufen lassen? Wenn ja, dann kann ich nur empfehlen, den aktuellen Zeitplan beizubehalten.---<)kmk(>- (Diskussion) 20:07, 22. Jul. 2013 (CEST)

Newsletter auf dieser Diskussionsseite II

Hallo, nach Eintreffen des nächsten Newsletters auf dieser Seite frage ich mich gerade, weswegen diese Idee aus dem Mai nicht umgesetzt wurde. Wenn ich das richtig lese, dann fand die große Mehrheit der Diskutant/inn/en die Idee mit den (dann einzeln (ab-)abonnierbaren) Unterseiten gut. Ich würde es ja machen, aber das Hin- und Herverschieben der Seite samt Überschreiben der Weiterleitungen benötigt erweiterte Rechte. Findet sich ein/e Admin/a mit Muße? Freundliche Grüße, --emha ^d|^b 17:23, 19. Jul. 2013 (CEST)

Ich hatte da Vorschläge gemacht und gedacht, es kämen noch Rückmeldungen, damit klar ist, wo es nun hin solle und welche Newsletter ausgelagert werden sollen. Aber dann kamen keine Antworten mehr, also schien es doch allen nicht so wichtig zu sein. Wenn keiner was dagegen hat bzw. man das befürwortet, würd ich es wohl entsprechend verschieben, sodass dann die beiden Newsletter unter WP:Wikidata/Newsletter und WP:Projektneuheiten/Newsletter ausgelagert würden. Wäre das so ok? Dafür bräuchte es auch nicht mal nen Admin, man könnte dann direkt auf den entstandenen WL die neuen Seiten für die Newsletter erstellen. Anschließend müssten die Bots noch dorthin umgeleitet werden. Ist eigentlich gar keine Adminaufgabe, könnte ich wohl machen. Wenn diese beiden Ziellemmata für die Newsletter nun so ok sind. --Geitost 18:39, 19. Jul. 2013 (CEST)

WP:Sei mutig! --emha ^d|^b 19:01, 19. Jul. 2013 (CEST)

Ich würde für den zweiten Newsletter WP:Projektneuheiten/Tech News nehmen, dann weiß man direkt welcher das ist und kann in Zukunft auch andere nehmen. Es gibt ja auch schon WP:Projektneuheiten/Tech blog, wenn man an den Blogänderungen interessiert ist (Hat 8 Beobachter). Für die Signpost der en.wp gibt es Benutzer:Steef389/Signpost (2 Beobachter, vermutlich Steef389 selber und ich). Dort könnte man sich auch die Archivierung abschauen. Der Umherirrende 19:09, 19. Jul. 2013 (CEST)

Klingt sinnvoll, dat Dingens heißt ja so. Dann wüsste man direkt, was man kriegt und sieht. Den Link hab ich grad mal gefixt. Weitere Meinungen? Viel Rumgeschiebe halte ich nämlich nicht für so sinnvoll, einmal dahin (und zurück) sollte ausreichen. Dafür sollten die Ziele halt schon vorher klar sein. --Geitost 19:17, 19. Jul. 2013 (CEST)

Man könnte anschließend auch noch die bereits hier auf der Disk. befindlichen Newsletter schon mal rüberkopieren und evtl. auch die archivierten in ein dortiges Archiv kopieren – mindestens aber für den Tech-Newsletter, der ja noch recht neu hier auf der Disk. ankommt, also seit Mai erst. Dann hätte man das auch alles dort direkt zusammen auf einen Blick. Bei Wikidata weiß ich nicht, wie lange der überhaupt schon hier gesammelt wird. --Geitost 19:21, 19. Jul. 2013 (CEST)

Muss man überhaupt verschieben (Hin und rück kann auch jeder Benutzer)? Das wären ja 800 Benutzer, die ungefragt eine neue Seite auf ihrer Beobachtungsliste bekommen. Ohne verschieben, werden wohl die wenigsten das aktiv auf ihre Liste setzen, aber das kann man auch nicht abschätzen. Muss sich ja erst irgendwie etablieren. Vielleicht reicht auch ein aussagekräftiger Bearbeitungskommentar mit Wikilink, so dass man direkt da hin kommt. Der Umherirrende 19:30, 19. Jul. 2013 (CEST)

Das war ja gerade die Idee dabei. Dass alle Benutzer, die diese Seite bisher beobachten und bisher alles erhalten, was hier ankommt, dies auch weiterhin erhalten. Und wenn sie dies dann nicht mehr wollen, es abbestellen können durch Klick auf „nicht beobachten“. Ist mMn wesentlich besser, als wenn man es einfach nicht mehr bekommt, was man bisher erwartet hat. Auf der Beo wird man es ja leicht sehen und kann es ebenso leicht rausnehmen. Standard ist zurzeit, dass man es erhält. Und das Auslagern ist also ein Splitten der Seite. Beim Splitten sollten aber die Beobachter mitgenommen werden, sonst gehen sie eben automatisch verloren. Nicht jeder schaut hier ständig hin, schon gar nicht während des Urlaubs mitten in der Urlaubszeit. Und es mag auch sicher Leute geben, die dann beschließen, nur die Newsletterseiten zu abonnieren und stattdessen diese Seite abzubestellen. Diese Entscheidung sollte aber in der Hand der jeweiligen Benutzer bleiben und ihnen nicht nebenbei weggenommen werden. --Geitost 19:45, 19. Jul. 2013 (CEST)

(BK) Vielleicht gibt es Leute, die diese Seite nur abonniert haben, weil sie sich für die Newsletter interessieren. Und sind dann froh, dass sie die Diskussionen nicht mehr ständig auf der Beo haben zu brauchen und nehmen diese Seite mal eben runter, da sie ab dann die verständlicheren Kurzinfos im Newsletter bekommen. Man kann schlecht für andere entscheiden, welchen Teil der bisher hier zur Verfügung gestellten Infos sie davon haben wollen und welchen nicht. --Geitost 19:50, 19. Jul. 2013 (CEST)

Archiv Wikipedia:Projektneuheiten/Tech News/Archiv/2013 ist angelegt. Der Umherirrende 19:47, 19. Jul. 2013 (CEST)

Ok, dann mach ich mal. --Geitost 19:50, 19. Jul. 2013 (CEST)

Archiv Wikipedia:Wikidata/Newsletter/Archiv/2012 / Wikipedia:Wikidata/Newsletter/Archiv/2013 ist auch angelegt. Der Umherirrende 20:00, 19. Jul. 2013 (CEST)

Ja, mach das mal; danke schön.

Ich finde meine Idee aus dem Mai prinzipiell immer noch gut.

Beim Verschieben bitte auf einen aufschlussreichen und wohldurchdachten Kommentar achten, da er auf 799 Beos erscheint. Ggf. gleich mit Zusatz: „Die beiden Newsletter können jetzt einzeln abbestellt werden.“

Schönes Wochenende --PerfektesChaos 20:02, 19. Jul. 2013 (CEST)

(BK) Die Seiten existieren jetzt (zurzeit leer), dann fehlt jetzt noch der Inhalt von hier, der da rüber sollte. 798 Beobachter wurden mitgenommen. Kann man ja mal weiter verfolgen, wie sich das so entwickelt. Wikidata-Archiv fehlt dann auch noch – und ein Archivierungsmodus. Und die Umleitung der Bots dorthin. --Geitost 20:04, 19. Jul. 2013 (CEST) PS: Danke fürs Anlegen. :-)

@ PerfektesChaos: Ja, auch wahr. Beim 2. hab ich den Newsletter jedenfalls erwähnt. Und erscheint ja auch auf den Beos. Außerdem Hinweis nach hier, dann kann man es auch nachvollziehen, denk ich mal. --Geitost 20:04, 19. Jul. 2013 (CEST)

(BK) Sorry, bin jetzt erst auf der Beo bei 19:52/57 angekommen. --PerfektesChaos 20:06, 19. Jul. 2013 (CEST)

Macht ja nix.

(BK) Übrigens glaube ich auch, dass so lange Verschiebekommentare eh bloß wieder abgeschnitten werden und man dann nur einen kleinen Ausschnitt davon sieht, deshalb halte ich die immer möglichst kurz. Sonst nützt es auch nix. Oft wird auch der gesamte Kommentar schon abgeschnitten und man sieht davon gar nix mehr, weil die Lemmata schon die gesamte Zusammenfassung ausfüllen. :-( --Geitost 20:07, 19. Jul. 2013 (CEST)

Alles verschoben. Der Bot muss noch benachrichtigt werden. Ich hoffe, es gibt keine zu großen Überschneidungen … Der Umherirrende 20:14, 19. Jul. 2013 (CEST)

Die beiden Bots hab ich umgeleitet (andere Seiten eingetragen), nun landet hier nix mehr davon.

Sollte man die Newsletter nicht lieber in Jahresarchiven archivieren, damit die Archive nicht immer größer und größer werden? So ein Jahresarchiv dürfte doch bereits relativ groß werden, oder? Mindestens aber beim wöchentlichen Newsletter, das ist wohl der Tech News. Aber auch bei monatlich dürften doch 12 Newsletter für so ein Archiv ausreichen. Ich wär für Aufteilen. --Geitost 20:32, 19. Jul. 2013 (CEST)

Sind beide wöchentlich, oder? 52 Newsletter sollten unbedingt ausreichen für so ein Archiv. Die sollen ja auch noch ansehbar bleiben. --Geitost 20:37, 19. Jul. 2013 (CEST)

Da kannst du dich gerne austoben. Beide sind ja wöchentliche Newsletter, haben also 52/53 Abschnitte. Eine Archivierung ins Nirwana (/dev/null) wäre auch eine Möglichkeit, weil auf meta auch archiviert wird. Die müsste man dann nur auf der Seite verlinken. Der Umherirrende 20:41, 19. Jul. 2013 (CEST)

Ja, das wäre auch möglich. Wenn dort nicht irgendwann die Löschknöppe die Archive ausradieren sollten aus welchen Gründen auch immer. ;-) Oder man lieber im selben Wiki bleiben will dafür. Könnte man noch mal überlegen.

Jedenfalls ist diese Disk. jetzt schon viel übersichtlicher und wieder besser benutzbar geworden, sehr schön. :-) --Geitost 20:46, 19. Jul. 2013 (CEST)

Vielen Dank an alle: Wenn Der Umherirrende mit dem PerfektenChaos und Geitost was anpacken, kommt eine gute Lösung raus! --emha ^d|^b 09:47, 22. Jul. 2013 (CEST) PS: Mal schau'n, ob sich jemand über die zusätzlichen Seiten auf seiner/ihrer Beobachtungsliste beschwert, und, wie sich die "Abozahlen" dort entwickeln...

Dieser Abschnitt kann archiviert werden. --emha ^d|^b 09:47, 22. Jul. 2013 (CEST)

Dank je wel. :-) Mal schauen, Zwischenstand: diese Seite 799 Beobachter (1 mehr als bei der Verschiebung), Tech News 780 und Wikidata 793. Also gibt’s an Wikidata mehr Interesse als an den zusätzlichen (gegenüber den umseitigen) Tech News. --Geitost 18:56, 22. Jul. 2013 (CEST)

HTML-Änderung am Inhaltsverzeichnis

Das Inhaltsverzeichnis hat sich ja von table nach div geändert. Wenn man eine Seite erwischt, wo noch ein altes table-TOC drin ist, dann sieht das anders aus, weil das padding auf 0 gestellt wird. Da passt was nicht mit der Abwärtskompatibilität.

/* Remove additional paddings inside table-cells that are not present in <div>s */
table#toc td,
table.toc td {
	padding: 0;
}

Jemand eine Idee, wie man das "not present" in allen Browsern abfragt? Oder ist es noch etwas anderes? Danke schonmal im vorraus. Der Umherirrende 21:17, 19. Jul. 2013 (CEST)

Wichtiger wäre mir, dass eine lange Überschrift nicht dafür sorgt, dass das Inhaltsverzeichnis unter Infobox/Eingangsbild(er) rutscht, weil die Zeile nicht mehr umgebrochen wird. Tritt bei mir in Monobook und Vector gleichermaßen auf und sieht äußerst bescheiden aus. -- 32X 23:46, 19. Jul. 2013 (CEST)

@Umherirrender, kannst du nochmal genauer beschreiben, was du meinst? Die oben zitierte CSS-Regel ist nur dazu da, um folgendes abzuschalten, das die Browser in ihren eingebauten Stylesheets stehen haben:

td,
th {
	padding: 1px;
}

@32X: Wenn man ohne Tabellen-Markup das Verhalten einer Tabelle imitieren will, würde man normalerweise natürlich display:table wählen. Die Layout-Unterschiede kommen daher, dass hier stattdessen display:inline-block gewählt wurde – schuld daran sind natürlich mal wieder veraltete IE-Versionen (bis einschließlich 7), die display:table nicht unterstützen. --Entlinkt (Diskussion) 14:46, 20. Jul. 2013 (CEST)

Ich sehe gerade im FireFox, dass mein beschriebenes Problem dort nicht sichtbar ist. Scheint also IE spezifisch zu sein. Zur Erklärung: Das linke Inhaltsverzeichnis hat im Internet Explorer keine Innenabstände zum Text, während das rechte diese hat. Im FireFox haben beide Inhaltsverzeichnies diese Abstände. Daher dachte ich das es nicht abwärtskompatibel ist, scheint aber mal wieder nur einen Browser zu betreffen. Der Umherirrende 18:15, 20. Jul. 2013 (CEST)

Dürfte sich um Bug 51766 handeln. Der Umherirrende 10:02, 31. Jul. 2013 (CEST)

HTTPS

Moin Moin zusammen, ist noch irgendwas live gegangen, da bei mir die Wikipedia jetzt standardmäßig in https ausgeliefert wird? mfg --Crazy1880 19:37, 30. Jul. 2013 (CEST)

Oh, ja: Enable Secure Login everywhere. Werde ich gleich, zusammen mit anderen Neuheite, vorne vermerken. — Raymond ^Disk. 19:54, 30. Jul. 2013 (CEST)

Danke --Crazy1880 20:11, 30. Jul. 2013 (CEST)

Wurde leider rückgängig gemacht :-( — Raymond ^Disk. 21:14, 30. Jul. 2013 (CEST)

War die Überlastung der SSL-Server der einzige Grund? Oder gab es noch andere Schwierigkeiten? Hat jemand etwas gehört? Der Umherirrende 13:20, 3. Aug. 2013 (CEST)

Hat wohl damit zu tun, dass einige Staaten HTTPS zu Wikipedia blocken (z.B. China), siehe https://blog.wikimedia.org/2013/08/01/future-https-wikimedia-projects --sitic (Diskussion) 13:28, 3. Aug. 2013 (CEST)

Bearbeiten / Quelltext bearbeiten

Hm? Ich habe deshalb extra VE wieder eingeschaltet, keine Änderung, nicht mal beim eingeschalteten VE finde ich die VE-Option. -jkb- 09:54, 2. Aug. 2013 (CEST)

Hallo jkb, bezieht sich deine Frage auf meinen umseitigen Eintrag von heute? So ganz verstehe ich deine Frage nämlich nicht. — Raymond ^Disk. 10:18, 2. Aug. 2013 (CEST)

Ja. Ich wollte es ausprobieren und habe den (seit ca 2 Tagen deaktivierten) VE bei mir wieder aktiviert, aber vom VE war nichts zu sehen. Im Moment habe ich die Anzeigen da. Vielleicht ein Cacheproblem... Gruß -jkb- 10:23, 2. Aug. 2013 (CEST)

P.S. allerdings die Anzeige neben der Abschnittsüberschrift hier ist kirre:

[|Abschnitt hinzufügenQuelltext bearbeiten | Abschnitt hinzufügen]

in diewer Schreibweise. -jkb- 10:25, 2. Aug. 2013 (CEST)

Das PS sollte mit dieser Änderung bereits behoben sein. Der Umherirrende 13:18, 3. Aug. 2013 (CEST)

Fehler in neuer Spezialseite

Spezial:RandomInCategory funktioniert nicht mit Doppelpunkt-Kategorien: Beispiel. δ¹ 22:36, 22. Aug. 2013 (CEST)

Doch, wenn du den vollen Kategorienamen angibst (also mit Namensraum): Spezial:RandomInCategory/Kategorie:Wikipedia:Exzellent. Der Umherirrende 14:47, 23. Aug. 2013 (CEST)

Dann ist das inkonsistent, denn bei Kategorien ohne Doppelpunkt funktioniert es auch so: Autor. δ¹ 21:39, 23. Aug. 2013 (CEST)

Der Fehler ist bekannt und wird behoben: Bug 53239, aber für den Moment hat man eine Umgehungslösung, wenn man den Namensraum mit angibt. Der Umherirrende 22:21, 23. Aug. 2013 (CEST)

CodeEditor und IE8

Das der CodeEditor im IE8 nicht einwandfrei funktioniert, ist wahrscheinlich kein Bug …, aber dann sollte er dort standardmäßig auch deaktiviert werden. Der IE8 zerstört teilweise die Newlines, bei JavaScript ist das nicht (immer) problematisch, bei Lua aber schon eher (wo es auch nicht funktioniert). Ungünstig ist auch, das nach dem deaktivieren trotzdem die Newlines kaputt sind. Ich habe keine Lust auf Bugzilla eine solche Browser-Diskussion zu starten, daher nur hier als kleinen Hinweis. Der Umherirrende 14:59, 23. Aug. 2013 (CEST)

„Wenn keine Bugs auftreten, wird …“ ist gut: modules/ext.codeEditor.js

• Opera 11.10 / Linux: copy fails, paste sometimes crashes
• IE 8.0.6001.18702 / Win XP: some newlines mysteriously removed, corrupting data;
  • insertion point keeps resetting back to the top of the page after a click (arrow keys ok)
• Safari / iPad 4.3 (8F190): renders ok, but can't set focus or scroll vertically. No focus means no typing. :(

Es wäre für uns nicht schwer, beim wgPageContentModel ungleich "wikitext" nach dem Browser zu schauen und im selteneren Fall ungeeigneter Browser zu setzen:

$.cookie( "wikiEditor-0-codeEditor-enabled",
          "0",
          { expires: 365,
            path:    "/" } );
mw.loader.state( "ext.codeEditor", "missing" );

• Die erste Anweisung verhindert per Cookie, dass dies planmäßig automatisch aktiviert ist; ließe sich aber noch anklicken. Den Button kann man aber $....remove().
• Wenn die zweite rechtzeitig wirksam werden sollte, wird das Teil gar nicht erst geladen.

Ohne solche Maßnahmen könnten entsprechende Benutzer ihr persönliches JS/CSS nicht mehr bearbeiten; oder es muss jedem vom Himmel die Erkenntnis fallen, dass man auf klicken muss, um arbeiten zu können. Alternativ ein Gadget für das bail out.

Es ist aber eigentlich serverseitig dafür zu sorgen, dass solche Zusatz-Tools erst dann geladen oder scharf werden, wenn sich der Browser dafür eignet. Davon sehe ich nichts. Prinzipiell ist das Ding soweit hilfreich und im Rahmen der Möglichkeiten ausgereift. Als Opt-in unterstütze ich das ausdrücklich.

• Aber mich stimmt die in diesem Jahr auftretende Attitüde der WMF äußerst nachdenklich, dass hemmungslos jedem zusätzliche Software aufgezwungen wird (und nicht einmal ein Opt-out vorgesehen ist), egal ob sie für ihn sinnvoll ist und überhaupt für seine Technik funktioniert. Dazu zählt IME/ULS für lateinisch verschriftete Projekte, das unselige Trauerspiel um den erst halb fertigen VE und jetzt diese Nummer.
• Der Netzwerkaufwand zum Angucken einer Seite steigt immer weiter, die Ladezeit wird auf langsamen Maschinen spürbar ausgebremst, Wikis sind bald nur noch mit neuester Hardware in schnellen Netzwerken lesbar – aber gleichzeitig plärrt WMF was von Wiki-Zugang auf der Südhalbkugel für technologisch schwache Infrastruktur. Und einfache Bearbeitung der Inhalte mit niedrigschwelliger Software gehört zu den Wiki-Basics; oder war mal eine Grundidee gewesen. Wenn kompliziert, dann serverseitig.

Schönes Wochenende --PerfektesChaos 22:45, 23. Aug. 2013 (CEST)

Information der Benutzer betreffend anstehender Umstellung auf HTTPS

In zwei bis drei Tagen steht eine Umstellung von Anmeldeprozeduren und weiterem auf HTTPS an; darüber sollten die Benutzer per sitenotice und/oder watchlistnotice informiert werden; mit Verweis auf Hilfe:Secure Server.

Liebe Grüße --PerfektesChaos 20:55, 26. Aug. 2013 (CEST)

Gemischte Inhalte

Was mir auffällt: die Wikipedia wird zwar via HTTPS ausgeliefert, aber anscheinend nicht komplett. Der Firefox "hat unsichere Inhalte blockiert" und weist mich via Icon in der Adresszeile, dass es "gemischte Inhalte". Auf der zugehörigen Hilfe-Seite [27] steht: „Wenn jedoch die aktuell besuchte HTTPS-Seite auch HTTP-Inhalte enthält, kann der HTTP-Anteil von Angreifern gelesen oder modifiziert werden, obwohl die Seite über HTTPS aufgerufen wurde. Wenn eine HTTPS-Seite HTTP-Inhalt enthält, nennen wir diesen Inhalt „gemischt“. Die Seite, die Sie besuchen, ist nur teilweise verschlüsselt und obwohl sie sicher erscheint, ist sie es nicht.“ Das ist ha sicher nicht im Sinne des Erfinders, oder? Kann man das abstellen? --emha ^d|^b 09:56, 29. Aug. 2013 (CEST)

Kommt vermutlich daher, dass Du in Deinem common.js/monobook.js/vector.js/etc. Sachen per http einbindest. --Krd 10:02, 29. Aug. 2013 (CEST)

Dito. mein verdacht ist Benutzer:Emha/monobook.js oder ähnliches. -- southpark 10:04, 29. Aug. 2013 (CEST)

+1

Infos:

• Seit 2011 sind alle gepflegten Ressourcen auf protokoll-relative Links umgestellt worden.
• Für in Wiki-Texten vorkommende Links wird notfalls automatisch umgestellt auf das richtige Protokoll.

Nur Programmierung in JS (und CSS) käme für veraltete (weil nicht protokoll-relative) Links in Frage.

Siehe Hilfe:Secure Server #Hinweise für die Praxis.

Das document.write und includePage ist auch bös veraltet; siehe Wikipedia:Technik/Skin/JS/Obsolet #Einbindungen.

LG --PerfektesChaos 10:37, 29. Aug. 2013 (CEST)

Danke für die Hinweise - schön, wenn man selbst 'schuld' ist, dann lässt sich sowas am schnellsten beheben :) Grüße, --emha ^d|^b 11:13, 29. Aug. 2013 (CEST)

HTTPS und Sitzungmanager vom Firefox

Hallo. Ich habe vorhin meine gestrige Sitzung im Firefox aufgerufen, nachdem ich mich in der Esperantowikipedia angemeldet hatte. Allerdings blieb ich trotzdem in der deutschen und den beiden sorbischen Wikipedien unangemeldet. Ich habe mir daraufhin mal das Dateiformat der Sitzung angeschaut. Dort stehen alle Adressen noch mit HTTP drin. Das läßt sich aber sehr einfach beheben.

• Ich habe die Sitzung, die im Firefoxprofilordner rumliegt, in meinem Commander kopiert.
  • Falls etwas schief geht, kann man dann nochmal anfangen.
• Und dann alle Adresseinträge für die Wikipedien per Suchen und Ersetzen auf HTTPS geändert.
  • Aber bitte aufpassen, daß alles was nicht zur Wikipedia gehört bei HTTP bleiben sollte.

Jetzt klappt die Anmeldung wieder überall wie gewohnt, wenn man sich in einer der Sprachversionen anmeldet und dann die Sitzung lädt. --Tlustulimu (Diskussion) 13:44, 29. Aug. 2013 (CEST)

Caching-Verhalten

Wurde mit der Umstellung auf Zwangs-HTTPS was am Caching geändert? Wenn ich von einem Artikel aus einen externen Link aufrufe und dann zurückgehe, wurde die Seite früher nicht neu geladen - jetzt ist das schon der Fall. Der HTTP-Header sagt auch "Cache-Control: no-cache". Ich weiß nur nicht, wie das vorher war. Oder ist das normales Browser-Verhalten bei HTTPS? Insgesamt verlangsamt das meine Arbeit schon merklich... --APPER\^☺☹ 23:00, 29. Aug. 2013 (CEST)

Es gibt nur beim IE eine uralte Einstellung, nach der man https-Seiten vom Caching ausschließen könne; dann würdest du aber keinen HTTP-Header "Cache-Control: no-cache" sehen, weil Privatangelegenheit des Browsers.

Ich bin seit mehreren Jahren auf https, und das Caching ist eigentlich ganz normal.

Wenn ich mich recht entsinne, gibt es bei statischen Seiten mit /wiki/ Caching-Infos, und ein no-cache etc. bei /w/index.php und Spezialseiten. Muss ich mal wieder drauf achten.

Vielleicht nur ein temporäres Problem, und irgendwie umstellungsbedingte Absicht aus irgendwelchen Gründen.

LG --PerfektesChaos 00:02, 30. Aug. 2013 (CEST)

Das Verhalten ist eindeutig anders. Wenn ich früher einen Artikel bearbeitet habe und dann beim Speichern eine Fehlermeldung vom Server kam, konnte ich einfach zurückgehen und erneut speichern. Jetzt sind die Änderungen weg... Sorry, so macht die Mitarbeit hier gleichmal wieder weniger Spaß, juchu. --APPER\^☺☹ 16:43, 30. Aug. 2013 (CEST)

Ah, ich seh grad, dass ich das in den Einstellungen deaktivieren kann. Gut. --APPER\^☺☹ 16:45, 30. Aug. 2013 (CEST)

Bei mir ist es genau so, liegt aber am Browser. Opera ermöglicht in den Benutzereinstellungen, die serverseitige Cache-Vorgabe zu ignorieren und Seiten immer aus dem Cache zu laden. Bei https-Seiten wird diese Einstellung allerdings von Opera ignoriert. -- TZorn 18:29, 30. Aug. 2013 (CEST)

Ich bin schon seit Monaten auf https: Über die Firefox-Extension HTTPSEverywhere. Habe keine Probleme mit dem Caching. Wenn ich eine Bearbeitung (durch einen Fehler) verlasse und die Browser-Rück-Taste klicke, werden mir meine Bearbeitungen im Bearbeitungsfenster angezeigt. Aber irgendeinen Unterschied zu dir muss es geben *grübel* — Raymond ^Disk. 19:08, 30. Aug. 2013 (CEST)

Bei mir gibt es auch keine Cache-Probleme. Bearbeiten -> Vorschau -> Browser-Rück führt wieder zum Bearbeiten-Fenster mit meinen Änderungen -> nochmal Browser-Rück führt wieder zum Artikel. Alles sofort da ohne jedes Neuladen. Achja: FF 22.0 ohne irgendwelche umgestellten Einstellungen, falls das hilft. --Stepro (Diskussion) 21:52, 30. Aug. 2013 (CEST)

Danke für eure Kommentare. Das Problem besteht mit Firefox und Chrome nicht, jedoch mit Opera (Opera <15). Das Problem ist das mitgesendete "must-revalidate" im Cache-Control-HTTP-Header. "no-cache" nehm ich zurück, da hab ich mich wohl verguckt. Opera behandelt "must-revalidate" im https-Umfeld strenger und lädt auch in der History die Seite neu - im Gegensatz zu Chrome oder Firefox. Nun kann man sich über die korrekte Interpretation der Absätze 13.13 und 14.9.4 der HTTP-Spezifikation streiten, aber ich halte "must-revalidate" in diesem Fall für übertrieben. Egal, ich deaktiviere HTTPS einfach zunächst - Opera 12 stirbt ja leider sowieso :/ --APPER\^☺☹ 23:49, 30. Aug. 2013 (CEST)

Wikipedia:Umfragen/Technische Wünsche

Zur Info: Wikipedia:Umfragen/Technische Wünsche. — Raymond ^Disk. 21:02, 1. Sep. 2013 (CEST)

Echo

Ist die Einführung auch hier geplant? In der en-WP sind die Notifications seit einer Weile aktiviert und IMO sehr praktisch. --Leyo 11:50, 3. Sep. 2013 (CEST)

[28] (v.a. die Checklist beachten, ich glaube, da hat man aus den Fehlern bei VisualEditor gelernt) --Filzstift ✏ 11:55, 3. Sep. 2013 (CEST)

Wollen wir darum wetten, wie groß der Protestschrei sein wird, dass es mit Echo keinen Kackbalken mehr gibt, gerade im Hinblick auf solche Fälle? --Schnark 12:29, 3. Sep. 2013 (CEST)

@Schnark: Wurde wohl zur optischen Backward Compatibility nachgerüstet; im Sinne der Kinderkrankheiten.

• Es ist vermutlich das Häkchen bei „⧼echo-pref-new-message-indicator⧽“ in der Benutzereinstellung, womit der traditionelle Modus für die eigene Disku zusätzlich hergestellt wird.
• Ich habe den Haken grad reingemacht; schreibe mir doch mal jemand anders was auf en:User talk:PerfektesChaos zum aktuellen Stand.
• Vor ein paar Monaten war das eine verkleinerte Form des traditionellen Balkens gewesen. Das Design ist per CSS voll anpassbar, bis hin zur traditionellen Erscheinungsbild.

LG --PerfektesChaos 12:50, 3. Sep. 2013 (CEST)

en:User talk:PerfektesChaos#Test

Ja, danke.

• Auf die Benutzereinstellung hin wird in der persönlichen Seitenleiste das normale Link auf die eigene Diskussionsseite um die class="mw-echo-alert" erweitert.
  • Damit entsteht innerhalb der Kopfleiste eine verkleinerte Anmutung des traditionellen Balkens.
  • Mittels CSS-Voodoo sollte sich das auf modernen Browsern sogar aus der Kopfleiste herauslösen lassen und über die Breite des Content erstrecken lassen?
  • Auf alle Fälle lässt sich die .mw-echo-alert kinderleicht noch größer, roter und dramatischer gestalten.
  • Spätestens ein winziges JS-Gadget kann aber den traditionellen Extra-Balken separat einfügen; und sonstwas mit den Nicht-BD-Nachrichtenmengen anstellen. Gibt es wohl auch in den wg.
• Wir sollten darauf achten, dass wir die „⧼echo-pref-new-message-indicator⧽“ projektweit standardmäßig möglichst mit Häkchen vorgegeben bekommen; und nach Eingewöhnung die Leutchen sich das Häkchen wegmachen.
• In der enWP gab es im Frühjahr ebenfalls eine Beschwerde, dass der Nachrichtenzähler auf rotem Untergrund für viele nicht auffällig genug sei. Daraufhin hatte man die vorgenannte Lösung realisiert. Hat schon seinen Sinn, es erstmal auf einem Projekt bis zur Praxisreife zu testen, bevor man es weltweit verteilt.

Schönen Tag --PerfektesChaos 13:28, 3. Sep. 2013 (CEST)

Aus meiner Schublade: Hilfe:Echo. Schönen Abend --PerfektesChaos 22:26, 3. Sep. 2013 (CEST)

Mir ist es selbst schon passiert, dass ich diesen Mini-Benachrichtigungsbalken längere Zeit übersehen habe, sodass es mich nicht wundern würde, wenn er auch von neuen Benutzern (die keine Einstellung und erst recht kein CSS verändert haben) übersehen wird, zumal bei Benutzern ohne Benutzerseite sich der rote Link auf diese, die rot hinterlegte Zahl und der orange Balken so wunderbar unauffällig ergänzen.

Ich sehe keinerlei Grund, warum der Benachrichtigungsbalken in seiner bisherigen Form für angemeldete Benutzer abgeschafft werden soll, oder es unsere Aufgabe sein sollte, irgendwelche Behelfslösungen dafür zu entwickeln. --Schnark 09:42, 4. Sep. 2013 (CEST)

Zumindest als Opt-in für angemeldete Benutzer sollte Echo schon zur Verfügung stehen. --Leyo 11:43, 4. Sep. 2013 (CEST)

Wenn man einmal begriffen hat, wozu das rote Dings da ist, entpuppt es sich als durchaus nützlich. Meinswegen gerne als default, Kackbalken optional, für den, der nicht drauf verzichten kann. -- Smial (Diskussion) 16:31, 4. Sep. 2013 (CEST)

• Als „irgendwelche Behelfslösung“ würde ich ein default-Gadget (benötigt JS) wie etwa dieses nicht ansehen.
• Mit Opt-in und Opt-out wird das nix. Wenn das System oder jemand einen Benutzer benachrichtigen will/soll, muss das gesamte Projekt Echo aktiviert haben; sonst klappt das auch nicht mit den Benutzer-Einstellungen. Der bisherige E-Mail-Algorithmus nur für die BD muss für das gesamte Projekt gewechselt werden auf Echo, und der bisherige E-Mail-Algorithmus hat irgendwann auch keinen Support mehr. Die Spezialseite mit allen Benachrichtigungen existiert ohnehin für jeden Benutzer; Opt-in und Opt-out hin oder her.
• Während ich sonst den flächendeckenden Neuerungen auf Ebene der Benutzeroberfläche (ULS/IME im lat. Wiki, VE als Standard, CodeEditor als Standard) skeptisch gegenüberstehe, weil nicht zwingend notwendiges Extra und obendrein ohne Opt-out, geht es hier im die projektweite Infrastruktur auf dem Server. Sie ist aber offenbar funktional ausgereift, und minimale optische Details lassen sich anpassen.
• Ich denke mir, dass das eine reine Gewöhnungssache ist. Nach einer Weile guckt man halt nach dem dunkelroten Dings. Wer das von Anfang an lernt, wird kein Problem damit haben. Für die Übergangsphase kann man sanfte Übergänge bieten; etwa das rote Zählerfeld in dreifacher Größe und mit hellrotem breiten Rahmen; nach zwei Monaten wieder herunterfahren oder auf Adventskranz umrüsten.

VG --PerfektesChaos 21:03, 4. Sep. 2013 (CEST)

»nach zwei Monaten wieder herunterfahren oder auf Adventskranz umrüsten« passt ja dann auch jahreszeitlich. Vorlage:Smiley/Wartung/:-p  Stepro (Diskussion) 22:57, 4. Sep. 2013 (CEST)

MediaWiki:Disambiguationspage

Sobald 1.22wmf17 live geht, wäre MediaWiki:Disambiguationspage überflüssig, da die Systemnachricht vom Core nicht mehr ausgewertet wird (siehe Vorseite). Kann die Systemnachricht dann hier gefahrlos gelöscht werden, oder sind noch lokale Skripte im Einsatz, die die Systemnachricht auswerten? — Raymond ^Disk. 11:10, 10. Sep. 2013 (CEST)

Erneute CSS-Änderung beim Inhaltsverzeichnis

Hallo, die kürzliche problematische Änderung beim Inhaltsverzeichnis (vorangegangene Diskussion) wurde nachgebessert, ich würde (weil es mit einer Vorlage bereits Probleme gab) folgenden Eintrag vorschlagen:

• (Softwareneuheit) Die Formatierung des Inhaltsverzeichnisses wurde erneut geändert, so dass jetzt wieder Zeilenumbrüche möglich sind. Dadurch können sich jedoch bei Vorlagen, die die CSS-Klasse toc mitbenutzen, unerwünschte Änderungen ergeben. Betroffene Vorlagen können auf die Klasse toccolours ausweichen (Bug 658, Gerrit:80435).

Passt das so und mag das jemand in den passenden Abschnitt einfügen? Ich weiß leider nicht, mit welcher MediaWiki-Version das live geht. --Entlinkt (Diskussion) 18:33, 15. Sep. 2013 (CEST)

Danke für die Formulierung, die ich genauso nach vorne übernommen habe. — Raymond ^Disk. 20:56, 16. Sep. 2013 (CEST)

Ach, deswegen haben seit einiger Zeit bei mir die Inhaltsverzeichnisse gefühlt jeden zweiten Artikel (zumindest die mit Infoboxen, Firefox 23 bei Bildschirmauflösung 1024×768) zerhackstückt und große weiße Löcher in die Darstellung gerissen. Die vorige Diskussion war warum auch immer an mir vorbeigegangen. Gut, wenn das wieder beseitigt wird. -- Rosenzweig δ 21:16, 16. Sep. 2013 (CEST)

Kann man sich darauf verlassen, dass es so bleibt? Dann könnte man diese Änderung (teil-)revertieren.--Der Harmlos (Diskussion) 12:59, 21. Sep. 2013 (CEST)

Sollte man sogar, denn aktuel scheint die Breite des Inhaltsverzeichnisses anhand der vorhandenen Breite bei dessen Start eingestellt zu sein. Da ist es ungünstig, wenn das Inhaltsverzeichnis neben einem Hochkantbild anfängt und diesem dann querformatige Bilder folgen – zumindest ich habe unschöne Überlagerungen von Bild und Text. -- 32X 13:49, 21. Sep. 2013 (CEST)

Oh je, wer weiß, wo noch überall solche Formatierungen eingebaut wurden … display:table-cell ist auch nicht so günstig, weil margin dann wirkungslos ist (es ist also auch nicht nötig, das explizit auf Null zu setzen).

Das Inhaltsverzeichnis war jahrelang eine Tabelle und es war keine Änderung des Aussehens beabsichtigt und dank display:table sieht es jetzt mit ziemlicher Sicherheit auch wieder aus wie eine Tabelle, ich würde deshalb davon ausgehen, dass es so bleibt, es war von Anfang an dies gemeint. Gruß --Entlinkt (Diskussion) 13:53, 21. Sep. 2013 (CEST)

Für das als zusätzliche Ebene eingebaute DIV-Element – nicht für das #toc-Element selbst – schien mir display:table-cell schon sinnvoll, display:table wäre allerdings auch gegangen. Aber das ist wohl eine etwas theoretische Diskussion und nicht ganz so wichtig. Also, ich verlasse mich darauf, dass es bei der jetzigen Formatierung bleibt, und nehme meine Änderung wieder heraus.

Bei der Gelegenheit hätte ich noch einen Vorschlag: es wäre sinnvoll, die Klassen .tocnumber und .toctext mit display:table-cell zu formatieren, damit sich die umgebrochenen langen Überschriften nicht unter der Nummer, sondern bündig unter ihrem Anfang fortsetzen. Wo kann man solche Änderungen vorschlagen?

@32X: Gibt es für das von Dir beschriebene Problem ein Beispiel. Ich kann es so gerade nicht nachvollziehen.--Der Harmlos (Diskussion) 15:07, 21. Sep. 2013 (CEST)

Bezüglich display:table-cell: Das hat in aktuellen Chrome- und Firefox-Versionen den Effekt, dass die Links beim Drüberfahren mit der Maus nicht mehr wie gewohnt unterstrichen werden, wogegen man mit einer zusätzlichen Regel angehen muss, insgesamt könnte der Vorschlag dann so lauten:

span.tocnumber {
	padding-right: .5em; /* oder ein anderer geeigneter Wert */
}
span.tocnumber,
span.toctext {
	display: table-cell;
}
#toc li > a { /* unschön: kein einfacher Selektor für diese Elemente */
	display: table-row; /* "table" würde wohl auch gehen */
}

Ich finde, es sieht in aktuellen Browsern durchaus etwas besser aus, allerdings schafft es eine Inkonsistenz zu den Browsern, die die display:table-*-Eigenschaften nicht unterstützen (und man kann die Regel auch nicht so leicht in Abhängigkeit davon verstecken, ob display:table-* unterstützt wird).

Wenn wir das lokal in MediaWiki:Common.css implementieren würden, hätte ich aber vor allem die Sorge, dass das eine der Anpassungen wird, die nie in MediaWiki übernommen werden. Ich würde das deshalb lieber direkt in Bugzilla vorschlagen. --Entlinkt (Diskussion) 19:28, 21. Sep. 2013 (CEST)

Hallo Entlinkt,

dass der Hover-Effekt im Firefox verloren geht, hatte ich übersehen. Man kann ihn aber dadurch wieder herstellen, dass man die span-Elemente ihr text-decoration-Attribut vom übergeordneten A-Element erben lässt. Wenn man dann noch die padding-Bereiche gleichmäßig auf die .tocnumber- und .toctext-Elemente verteilt, würde man sogar mit einem Statement auskommen:

span.tocnumber, span.toctext {
	display: table-cell; text-decoration: inherit; padding: 0 0.25em;
}

Oder wahlweise auch so:

span.tocnumber, span.toctext {
	display: table-cell; text-decoration: inherit; padding-right: 0.5em;
}

Das funktioniert mit Firefox und Safari, nicht aber mit IE7.

Danke für den Hinweis auf Bugzilla, vielleicht schlage ich es dort mal vor. Es ist ja keine Sache, die besonders eilt. Gruß --Der Harmlos (Diskussion) 17:45, 22. Sep. 2013 (CEST)

HTTP-Links im Wikimedia notification system

Hallo, das Wikimedia notification system mit dem Absender wikiwikimedia.org verschickt seine Benachrichtigungen nach wie vor als HTTP-Adressen. Nachdem ja alle Wikimedia-Projekte umgestellt wurden - wäre es dann nicht konsequent, wenn das in diesem System ebenfalls geschähe? Grüße, --emha ^d|^b 12:11, 26. Sep. 2013 (CEST)

CentralNotice CrossWiki Hiding

Bevor ich auf der Vorderseite vorzeitig Freude auslöse: Bedeutet Gerrit:92817 Enable CentralNotice CrossWiki Hiding nun, dass das Schließen eines CentralNotice-Banners das Banner auf allen Projekten bedeutet oder nur auf den im Patchset genannten Projekten? — Raymond ^Disk. 13:48, 5. Nov. 2013 (CET)P

Soweit ich das auf Anhieb sehe betrifft das alle Projekte. Die Projekte dort wurden vermutlich nur gewählt weil da die Wahrscheinlichkeit, dass User einen Account besitzen am höchsten ist. - Hoo man (Diskussion) 19:45, 5. Nov. 2013 (CET)

Ich mein das müsste doch andersherum sein: $wgNoticeHideUrls Locations of Special:HideBanner targets to hit when a banner close button is pressed. The hides will then be specific to each domain specified by $wgNoticeCookieDomain on that wiki. [...] Page code will always hide a banner by setting a cookie for that wiki's domain.

Wie ich das interpretiere: Cookies auf dem einzelnen Wiki entscheiden, ob gezeigt wird oder nicht, und nur die angegebenen URLs werden beim Verstecken auf einem Wiki aufgerufen => Auf anderen Wikis wird der Cookie nicht gesetzt. Oder überseh/weiß ich da was nicht? --se4598 / ? 19:57, 5. Nov. 2013 (CET)

Die Cookies werden vermutlich als wildcard gesetzt, also z. B. für *.wikipedia.org. Das muss für jeder unserer second-level Domains einmal passieren, deshalb die Auswahl der Wikis. - Hoo man (Diskussion) 20:10, 5. Nov. 2013 (CET)

Beta Features

Da ich folgenden Ankündigung noch nicht anderswo gesehen habe und ich auch nicht weiß, wer die Email von Fabrice Florin (WMF) aus unserer Community sonst noch bekommen hat, bin ich mal so mutig und geb das einfach mal so weiter. Wer möchte, kann eine Übersetzung unten dran hängen ;)

TLDR: Ein Programm zum Betatesten von Features wird um den 21. Nov. hier bei uns aktiviert. --se4598 / ? 19:34, 5. Nov. 2013 (CET)

Introducing Beta Features

We would like to let you know about Beta Features, a new program from the Wikimedia Foundation that lets you try out new features before they are released for everyone.

Think of it as a digital laboratory where community members can preview upcoming software and give feedback to help improve them. This special preference page lets designers and engineers experiment with new features on a broad scale, but in a way that's not disruptive.

Beta Features is now ready for testing on MediaWiki.org. This Thursday, it will also be released on Wikimedia Commons and MetaWiki. Based on test results, the plan is to release it on all wikis worldwide on 21 November, 2013.

Here are the first features you can test this week:

• Media Viewer — view images in large size or full screen
• VisualEditor Formulæ — edit algebra or equations on your pages
• Typography Refresh — make text more readable (coming Thursday)

Would you like to try out BetaFeatures now? After you log in on MediaWiki.org, a small 'Beta' link will appear next to your 'Preferences'. Click on it to see features you can test, check the ones you want, then click 'Save'. Learn more on the Beta Features page.

After you've tested Beta Features, please let the developers know what you think on this discussion page -- or report any bugs here on Bugzilla. You're also welcome to join this IRC office hours chat on Friday, 8 November at 18:30 UTC.

Beta Features was developed by the Wikimedia Foundation's Design, Multimedia and VisualEditor teams. Along with other developers, they will be adding new features to this experimental program every few weeks. They are very grateful to all the community members who helped create this project — and look forward to many more productive collaborations in the future. :)

Enjoy, and don't forget to let developers know what you think!

---

--se4598 / ? 19:34, 5. Nov. 2013 (CET)

Kann auf beta.wmflabs.org bereits deutschsprachig bewundert werden.

Beißt nicht; wer’s mag, mag damit spielen.

VG --PerfektesChaos 20:18, 5. Nov. 2013 (CET)

Sehe ich das richtig, das die auf der Seite direkt svg-Icons einbinden? Dann sollten sie für die Anzeige auch ein Feature zur Verfügung stellen, sonst ist das sinnlos, weil nicht jeder Browser das nativ darstellen kann. Der Umherirrende 17:36, 7. Nov. 2013 (CET)

Nur am Rande, da natürlich weiterhin stimmt, dass nicht jeder Browser SVG-Icons nativ anzeigen kann: Jeder halbwegs verbreitete Browser, der in den letzten zwei Jahren rauskam, kann das laut caniuse.com/svg durchaus (demnach wären das dann auch - immerhin - die Browser von 84 % der weltweiten Nutzer). --YMS (Diskussion) 18:13, 7. Nov. 2013 (CET)

Das mag sein, aber dann bräuchte man in normalen Artikeln auch das svg nicht in png umwandeln, wenn man das ganze nicht (mehr) supporten soll. Habe mal Bug 56729 aufgemacht. Der Umherirrende 19:35, 7. Nov. 2013 (CET)

Nur als Anmerkung: Bei dem kleinen "lustigen" Männchen oben neben dem Benutzernamen (im Vector-Skin) handelt es sich ebenfalls um eine SVG-Grafik und die ist schon seehr lange da. --Patrick87 (Diskussion) 19:41, 7. Nov. 2013 (CET)

Ja, aber da gibt es ein Fallback, so dass Benutzer mit älteren Browsern das png bekommen, während andere das svg bekommen. Das gibt es bei BetaFeatures aber nicht. Der Umherirrende 19:52, 7. Nov. 2013 (CET)

JavaScript zerschossen nach Update

Hallo, wer sich mit JS auskennt, möge doch bitte einmal schauen: Wikipedia:Fragen_zur_Wikipedia#JavaScript_mal_wieder. Dankeschön! Yellowcard (D.) 20:56, 7. Nov. 2013 (CET)

Meine Tools funktionieren nicht mehr

Erbitte Hilfe unter Wikipedia:Fragen zur Wikipedia#Kein Zugriff mehr auf de.wikipedia.org von meinen Tools aus, damit WikiBlame etc. bald wieder laufen. Danke und Gruß, --Flominator 11:51, 8. Nov. 2013 (CET)

Gelöst dank Benutzer:Rillke. --Flominator 17:52, 8. Nov. 2013 (CET)

Mouseover explanations for interlanguage links in native languages

Bug 5231 kann den jemand eintragen? --Kino (Diskussion 17:56, 9. Nov. 2013 (CET)

Steht am 17. Oktober drin. Der Bug wurde nur später geschlossen, weil das vermutlich vergessen wurde. Der Umherirrende 18:13, 9. Nov. 2013 (CET)

jQuery UI wird nicht mehr standardmäßig geladen - CSS für Buttons fehlt damit

Hallo zusammen,

mit dem heutigen Update auf MediaWiki Version 1.23wmf2 wird das jQuery UI Modul nicht mehr automatisch geladen. Siehe dazu z.B.

• http://lists.wikimedia.org/pipermail/wikitech-l/2013-October/072779.html
• bugzilla:55550
• en:Wikipedia:Village pump (technical)#jQuery UI CSS may no longer load by default

Das ist zwar im Grunde eine Änderung die ich befürworte, da sich dadurch die Ladezeiten verkürzen, allerdings ergibt sich dadurch für uns auch ein Problem: Alle Buttons die auf das CSS für jQuery UI Buttons zurückgegriffen haben, funktionieren derzeit nicht mehr ordnungsgemäß, darunter die Vorlagen {{Button}} und {{Anklickbarer Knopf}}.

Die Frage wäre wie wir diesem Problem am besten begegnen? Ich sehe derzeit vier Möglichkeiten:

1. Das CSS per mw.loader.using( 'jquery.ui.button' ); in der Common.js laden und das bisherige Design der Buttons beibehalten.
   Das wäre zwar die einfachste Möglichkeit, allerdings laufen wir damit dem Ziel unnötige Module nicht zu laden und dadurch die Performance zu verbessern direkt entgegen. Insofern wohl nicht die beste Lösung.
2. Alle Buttons auf mediawiki.ui umstellen.
   Derzeit müsste man auch dieses Modul noch über die Common.js laden, allerdings handelt es sich dabei um reines CSS und es besteht die Aussicht, dass dieses in Zukunft standardmäßig geladen wird und damit nicht mehr von JavaScript abhängig ist. Im oben verlinkten Beitrag auf der Englischen Wikipedia schreibt Steven Walling auch, dass es das langfristige Ziel ist für GUI-Elemente wie Buttons einheitlich das Modul mediawiki.ui zu verwenden.
   Diese Lösung hört sich damit sehr vielversprechend an und wäre mein persönlicher Favorit, auch wenn er mit etwas Arbeit verbunden ist.
3. Alle Buttons durch CSS direkt im Wikitext gestalten.
   Damit sind wir zwar unabhängig von irgendwelchen Modulen, allerdings sieht dann über kurz oder lang jeder Button anders aus, es ist so ziemlich die unsauberste Möglichkeit die ich mir vorstellen kann und wir haben keine Möglichkeit Hover-Effekte zu realisieren. Erwähne ich hier deshalb eigentlich auch nur der Vollständigkeit halber, für mich persönlich keine Option.
4. Wir fügen das entsprechende CSS für Buttons in die Commons.css ein.
   Das sollte Performance-technisch keinen großen Mehraufwand erzeugen, garantiert zumindest hier in der deutschen Wikipedia einheitliche Buttons und ist eine einigermaßen saubere Lösung. Den Vorteil im Vergleich zu 2. sehe ich jedoch als gering an.

Was denkt ihr dazu? Welche Lösung würdet ihr bevorzugen? Oder habt ihr noch andere Vorschläge? --Patrick87 (Diskussion) 22:48, 7. Nov. 2013 (CET)

Wie ich schon vor einigen Tagen schrieb, bin ich für Lösung 1', siehe Punkt 2 unter MediaWiki Diskussion:Common.js#Wunschzettel. --Schnark 09:24, 8. Nov. 2013 (CET)

2. ist hübsch aber was passiert mit den Icons? Und warum erfindet MediaWiki das Rad neu? UI.button wird man letztlich auch beibehalten müssen, denn das wird von jQuery UI.Dialog und vielen Skripten benutzt. -- RE rillke fragen? 13:49, 8. Nov. 2013 (CET)

Ist jetzt ergänzt. Der Umherirrende 12:45, 10. Nov. 2013 (CET)

Danke! -- RE rillke fragen? 10:18, 15. Nov. 2013 (CET)

Flow Newsletter - November 15

(My apologies for posting this in English. Please help translate this message so that others in your community can read it.)

Hi. This is a brief note to let you know about an update to the Main FAQ (the addition of a large table of Components of the discussion system), and also to specifically request your feedback on two items: our sandbox release plan, and a draft of the new contributors survey. We look forward to reading your input on these or other topics - Flow can only get better with your ideas! Thanks.

(Subscribe or unsubscribe to this Newsletter, at en:Wikipedia:Flow/Newsletter) --Quiddity (WMF) (Diskussion) 20:59, 15. Nov. 2013 (CET)

Echo: 22. Oktober (geplant)

• Technisch habe ich keine Bedenken.
  • Die enWP hatte die Kinderkrankheiten ausgeschwitzt.
  • Seit einem halben Jahr offenbar ohne größere Probleme.
  • Verloren geht nichts, es kommt nur viel Funktionalität hinzu.
• Benachrichtigung unserer Benutzer:
  • Kurier (wer schreibt was?) mit kurzer Zusammenfassung, rotes Dingens.
  • Sitenotice am Einführungstag selbst für eine Woche?
• Hauptproblem war in der enWP die Wahrnehmung gewesen; also der berüchtigte Balken. Nach etwas Gewöhnung bekommt man das rote Etwas sofort mit. Aktiv zuschaltbar wäre für Benutzer der Mini-Balken; dazu müssten sie das aber erstmal wissen und können. Ich schlage deshalb vor:
  • Im restlichen Oktober das rote Teil ungleich Null auf 300–400 % usw. (und/oder Rahmen mit 10px oder was immer) per Mediawiki:Common.css. Definition kann ab jetzt sofort eingebaut werden.
  • Im November reduzieren auf 200 % (auch für seltenere Besucher, nach Herbstferien).
  • Im Dezember weiter reduzieren; langsam ausschleichen, an jedem Advent eine Kerze = 1 Extra-Pixel auspusten.
  • Ab 1. Januar keinerlei projektweiten Extrawürste mehr.

Schöne Woche --PerfektesChaos 09:31, 14. Okt. 2013 (CEST)

Eigentlich finde ich notifications sehr gut und hilfreich, besonders "thank" und "ping". Es wurde auch bei den anderen Sprachversionen gut aufgenommen. Es gibt aber 2 potentielle Probleme:

• 1) Kackbalken wird ersetzt. Ob die deWP Nostalgiker sich wohl trennen können von:

Du hast eine neue Nachricht auf deiner Diskussionsseite.

für sowas:

bzw.

Diskussion: Du hast neue Nachrichten

Drama-Faktor: Hoch. Siehe en:Wikipedia:Notifications/FAQ#What happened to the orange bar for talk page messages on Wikipedia? Auf enWP gibt es ein Einstellungsgadget für die Liebhaber des alten Kackbalken, das bräuchte man hier wohl auch. Aber: "Both the new message indicator and the gadget preference require JavaScript."

• 2) Keine "gesichtet" notification. Siehe bugzilla:52510 und

en:Wikipedia_talk:Notifications#New notification "gesichtet" needed for deWP, plWP, ruWP, arWP etc? und

en:Wikipedia_talk:Notifications#Notifications: The Final Stretch (we encourage the German community to join our worldwide deployment on October 22, which is our best opportunity to deploy the tool on your site this quarter. If we miss that window, we would need to arrange a special German release at the end of the year or early next year, which may be tough to schedule, due to other deadlines. I think a first release of the basic Notifications tool would serve everyone's best interests, even without Flagged Revisions support, because it would motivate local developers to help build the feature you want. Thanks for your understanding, and we hope to deploy Notifications very soon on the German Wikipedia! Fabrice Florin (WMF) (talk) 21:31, 11 October 2013)

Ich fände es schon ziemlich übel, jeden neuen Autor brühwarm über reverts zu benachrichtigen (negatives feedback!), aber kein Wort über Sichtungen seiner Arbeit zu verlieren (kein positives feedback!). Es gibt pro Tag etwa 2.000 - 2.500 Sichtungen und ca. 700 - 1.000 reverts auf deWP. --Atlasowa (Diskussion) 01:35, 18. Okt. 2013 (CEST)

• Sichtungsbenachrichtigung:
  • Da wäre ich mir nicht so sicher. Auf der enwP habe ich keine Sichterrechte, und ich bekomme zumindest bei Neuanlage von Benutzerseiten ein Echo, dass ein erfahrener Benutzer die Seite „überprüft“ habe (“review”). Fabrice Florin sollte sich jedoch damit auskennen.
  • Option: Seitenüberprüfungen
  • Ich durchschaue aber das FR-Sichter-Prüf-Wesen zwischen den WP nicht; nächste Woche mal mit einem Test-edit irgendwie ohne Sichterrechte ausprobieren, was passiert.
  • Viel ändern wird das aber in den verbleibenden vier Tagen ohnehin nicht.
  • Mag sein, dass dies in den kommenden Monaten nachgeliefert würde.
• Wer benachrichtigt weitere Kreise im Kurier?

Schönen Tag --PerfektesChaos 09:52, 18. Okt. 2013 (CEST)

Ich kann nicht nachvollziehen, was "ziemlich übel" daran wäre, Benutzer über Reverts zu benachrichtigen und über Sichtungen nicht. Das eigentlich negative für den Benutzer ist ja der Revert selbst, und nicht die Benachrichtigung darüber. Wenn ich nun die Wahl habe, entweder revertiert zu werden und es nur mehr oder weniger zufällig merken zu können, oder revertiert zu werden und automatisch einen kleinen Hinweis dazu zu kriegen, dann nehme ich doch Letzteres, vollkommen unabhängig davon, ob es zusätzlich auch noch Benachrichtigungen zur Sichtung meiner Beiträge gibt oder nicht. --YMS (Diskussion) 10:09, 18. Okt. 2013 (CEST)

Mal abgesehen davon, dass mir als „Nostalgiker“ der derzeitige Balken natürlich besser gefällt, befürchte ich hauptsächlich Probleme bei Neu-Usern. Auf der VM wird z.B. häufig so vorgegangen, dass man erstmal abwartet, ob der Benutzer auf eine Ansprache reagiert und dann ggf. weitere Sanktionen durchführt. Den Balken zu ignorieren, war auch als Anfänger fast unmöglich, aber diese rote Zahl kann man meines Erachtens viel zu leicht übersehen, gerade wenn man das System noch nicht kennt.--Berita (Diskussion) 20:46, 20. Okt. 2013 (CEST)

Das Problem mit dem Hinweis für die Newbies (das muß ja nicht gleich eine VM sein) sehe ich auch. Der sog. "Kackbalken" ist halt ganz bewußt aufdringlich. Die Warnfunktion "ACHTUNG schau mal auf Deine Disk. !!!" hat ja ihren Sinn und sollte deshalb auch so erhalten bleiben. --Mogelzahn (Diskussion) 18:48, 22. Okt. 2013 (CEST)

Moin Moin zusammen, ich hätte da mal eine Frage zu dem Echo. Ich kenne es nun aus der englischen Wikiepdia. Vllt. könnte man folgendes ja mal für die Zukunft andenken: Ich bin viel in allen Sprachversionen der Wikipedia unterwegs, gerade auch aus dem Projekt um Wikidata. Wäre es vllt. möglich, Benachrichtigungen durch das Echo auch von den anderen Sprachversionen zu empfangen? Hintergrund ist, jemand aus der ungarischen Wikipedia wollte etwas und da bin ich nicht so zeitnah hingekommen. Hätte ich das hier gesehen, hätte man schneller reagieren können. mfg --Crazy1880 19:45, 22. Okt. 2013 (CEST)

Ich habe im Hinterkopf, dass so etwas zumindest langfristig geplant ist, allerdings wohl erst nach der SUL-Finalisierung. Gruß, IW 19:50, 22. Okt. 2013 (CEST)

Gab es eigentlich zu der SUL-Finalisierung einen weiteren Zeitplan? --Crazy1880 20:10, 22. Okt. 2013 (CEST)

Ein paar Hinweise und Denkanstöße zu allem bisher Gesagtem:

• Die eingangs erwähnte Idee einer schrittweisen Designanpassung erscheint mir eher kontraproduktiv. Tatsächlich nahtlos lässt sich der Übergang ohnehin nicht gestalten. Ich halte es für konstruktiver, die Umstellung einmal hinter uns zu bringen.
• So weit mir bekannt, hat sich aus den zum Teil heftigen (englischsprachigen) Diskussionen ergeben, dass unangemeldete Benutzer weiterhin den großen „Kackbalken“ erhalten werden.
• Man sollte den Effekt der Bannerblindheit nicht unterschätzen. Wir Langzeitwikipedianer haben uns an den großen „Kackbalken“ gewöhnt und wissen, was er bedeutet. Aber Neulinge können ihn tatsächlich übersehen, weil sie ihn für ein Werbebanner halten und sich gar nicht die Mühe machen, zu lesen, was darauf steht. Dank Smartphones und Co. sind gleichzeitig immer mehr Benutzer mit dem Konzept kleiner roter Zahlen vertraut. Im besten Fall wird die rote Zahl von Neulingen besser wahrgenommen als der alte „Kackbalken“. Verlieren können wir meiner Einschätzung nach nichts.
• Ich behaupte, dass es auch für uns Langzeitwikipedianer letztlich nur eine Frage der Gewöhnung ist. Ich freue mich darauf, die kleine rote Zahl ganz auf meine Bedürfnisse einstellen zu können und im Zweifelsfall auch mal eine Stunde lang ignorieren zu dürfen, ohne dass mir der riesige Balken die Artikelarbeit (optisch) blockiert.
• E-Mail-Benachrichtigungen sind standardmäßig komplett deaktiviert. Auch die Benachrichtigung über das Verlinken selbst erstellter Seiten ist standardmäßig aus. Dass sich im Urlaub hunderte Benachrichtigungen ansammeln, kann eigentlich nur passieren, wenn in der Zeit hunderte Diskussionsbeiträge mit einem Link zur eigenen Seite geschrieben werden (und man diese Benachrichtigungsart nicht abgeschaltet hat).
• Benachrichtigungen über Sprachversionen hinweg (Cross-Wiki) sind geplant. Der Funktionsumfang, den wir aktuell bekommen, ist streng genommen nur ein erster Schritt. Echo ist mehr als das. Es ist die technische Grundlage für viel mehr.
• Das Selbe gilt auch für die Zusammenarbeit mit der FlaggedRevs-Erweiterung, die nur in einigen Wikis aktiv ist und dementsprechend noch keine Priorität für die Entwickler haben konnte. Auch hier gilt: Wir verlieren nichts. Bisher wurde ja auch niemand über Sichtungen benachrichtigt.
• Was mich aktuell noch stört, ist die zum Teil unnötige Abhängigkeit von JavaScript. Aber das ist ein rein technisches Problem, das sich lösen lässt, und kein Grund für eine Ablehnung.
• Hilfe:Single-User-Login/Finalisierung (hat nur etwas mit eventuellen Cross-Wiki-Funktionen zu tun, nicht dass das falsch gedeutet wird).
• Ob wir die Thanks-Funktion wollen, können wir wie es scheint noch selbst entscheiden. Ich würde es wenigstens mal probieren. Vorsicht: Nicht mit WikiLove verwechseln.

--TMg 22:37, 22. Okt. 2013 (CEST)

Zu deinen ersten 6 Punkten stimme ich voll zu. So charmant die CSS Idee von PerfektesChaos auch ist, lieber kurz 1 mal und schmerzvoll (+optionales Kackbalken-gadget au enWP), als 4 mal die selbe Diskussion (Warum ist das schon wieder geschrumpft? Wie mache ich das rückgängig? Alles Mist!)...

Aber: "Wir verlieren nichts"? Doch doch, wir verlieren wertvolle neue Autoren, weil die systematisch durch ausschliesslich negatives feedback demotiviert werden (revert, revert, sogar ohne Blick in die Beo, und der gute Rest ist Schweigen). Und das ist ziemlich übel. deWP kann und sollte sich das nicht leisten, schau mal meine kleine Statistiksammlung unter Benutzer:Atlasowa/editor_motivation an. Und zu FlaggedRevs-Erweiterung, die "nur in einigen Wikis aktiv ist", das sind immerhin Albanisch, Arabisch, Bosnisch, Klassisches Chinesisch, Englisch (eingeschränkt, nur auf wenigen Seiten), Esperanto, Finnisch, Hindi, Indonesisch, Mazedonisch, Polnisch, Portugiesisch, Russisch, Türkisch, Ukrainisch, Ungarisch um nur "einige" zu nennen. Siehe auch den bugreport-Kommentar dazu: "I feel that it is unlikely this notification will be worked on by others as FlaggedRevs is barely supported as it is."

Aber auf der anderen Seite wurden für Echo extra "review"-notifications entwickelt, die zur Extension PageTriage gehören, die einzig auf enWP läuft... (page review notifications auf enWP sind ca. 700 pro Tag, auf deWP etwa 2.000 - 2.500 Sichtungen pro Tag, + die anderen WPs mit flagged revisions...) --Atlasowa (Diskussion) 23:03, 22. Okt. 2013 (CEST)

Ich würde 17 von über 280 Sprachversionen durchaus „einige“ nennen, aber das ist nur ein Wort, darum geht es nicht. Die Benachrichtigungsart muss selbstverständlich dazu kommen (wahrscheinlich sogar standardmäßig aktiviert), aber ich halte ihr momentanes Fehlen nicht für einen ausreichenden Grund, die anderen Benachrichtigungen abzulehnen. Dass Neulinge „systematisch durch ausschließlich negatives Feedback demotiviert werden“ ist mindestens grob überdramatisiert. Oder anders formuliert: Wer so editiert, dass er Dutzendfach revertiert wird, aber keine anderen Benachrichtigungen erhält, der macht definitiv etwas falsch. Das hat nichts mit Echo zu tun. --TMg 23:39, 22. Okt. 2013 (CEST)

Habe mal Bug 56950 aufgemacht, um Echo auf de.wikipedia.beta.wmflabs.org zu bekommen. Dann bleiben noch ein paar Tage zum rum spielen. Da dort auch FlaggedRevs aktiv ist, kann man auch die Intergration davon testen. Der Umherirrende 19:01, 14. Nov. 2013 (CET)

Ich finde die thanks-Funktion sehr gelungen und wesentlich besser als Wikilove. Fehlt eigentlich nur noch, dass man PMs über Echo senden kann. -- RE rillke fragen? 10:18, 15. Nov. 2013 (CET)

Doch nicht am 22. Oktober

Wir wurden wohl erstmal ausgenommen: gerrit:91072: Enable Echo on all wikis except dewiki and itwiki. Kennt jemand die Hintergründe? Der Umherirrende 20:46, 22. Okt. 2013 (CEST)

mw:Echo/Release Plan 2013/Site List#Scheduled for release in November. Meinen die mit „request of their community“ etwa diese Diskussion hier? Eine andere ist mir nicht bekannt. Will man uns Zeit für einen Hinweisbalken geben, wie oben vorgeschlagen? Wer richtet den ein? --TMg 21:57, 22. Okt. 2013 (CEST)

Hm, vielleicht weiß Benutzer:Paul Conradi (WMDE) (würde er jetzt eigentlich eine Benachrichtigung bekommen?) mehr? Er soll laut Benutzerseite für die begleitende Einführung von Echo zuständig sein. IW 22:06, 22. Okt. 2013 (CEST)

Hatte gerade eine kurzes Chatgespräch mit Fabrice Florin, einem der Produktmanager von Echo. Aufgrund nicht genügend positivem Feedback und zur Vermeidung eines möglichen Konflikts mit unserer Community wurde die Einführung verschoben. Sie ist jetzt vorerst für die Woche vom 18. November vorgesehen. Als Kontaktpersonen (für ihn) hat er mit erstmal hauptsächlich Denis Barthel und Jan Eissfelt genannt. Weitere Infos findet ihr in dieser Antwort. Grüße --se4598 / ? 22:48, 22. Okt. 2013 (CEST)

Jo, da kann ich helfen. Nachdem ich mir die Einführungen auf Pt und Es im September angesehen hatte, bekam Ich das Thema für De offiziell letzten Donnerstag auf den Tisch: sprich: ob Heute oder besser zusammen mit It.WP später einführt werden solle. Mithin hab ich mir den Stand der Dinge angesehen, nochmal mit Oona, die die Einführung auf Pt begleitet hat, telefoniert (um sicherzustellen, dass da nicht noch nachträglich mir unbekannte schwerwiegende Probleme aufgetaucht sind), und Notizen mit dem Team von Denis verglichen. Das gipfelte in einem Meeting Heute Nachmittag, in dem Denis die Idee mit Paul vorlegte. Zudem gab es eine Reihe guter Gründe: es gibt noch Unklarheiten bezüglich der Informationslage zu Notifications und allen Beteiligten mithin mehr Zeit zu geben sich damit zu befassen ist sinnvoll; kurzfristige Einführungen grosser Tech-Produkte sind tendenziell generell kontrovers; ich bastel, wie ich gestern schrieb, ohnehin an im Dezember fälligen Vorschlägen fuer bessere Einführungsmethodiken und kann dabei ggf. noch von diesem von Paul begleiteten Fall was mitnehmen. Lezteres zumal, weil mein neuer Terminvorschlag - Woche des 18.11 - von Tech akzeptiert wurde und die Community so ggf. noch die Möglichkeit hat sich direkt am Wochenende nach der Einführung auf der WikiCon mit WMDEs Community-Team auszutauschen. Den Input und andere Ideen zur Verbesserung der Deploymentmethoden seh ich mir dann im Hinblick auf Dezember in Ruhe an. Inkowik: Jo, Paul hätte jetzt eine Nachricht bekommen ;) Gruss, --Jan (WMF) 23:09, 22. Okt. 2013 (CEST)

Mehr Zeit ist gut. Meiner Einschätzung nach sind die dringendsten Fragen, die wir in dieser Zeit klären sollten:

• Gibt es offene Fragen, die eine Umfrage notwendig machen? Abgesehen von der Frage, ob die deutschsprachige Community die Thanks-Erweiterung will? (Meine Meinung: Ausprobieren und später abstimmen.)
• Wer kann in MediaWiki:Watchlist-summary auf Echo hinweisen, ist das notwendig und der richtige Ort und wann und für wie lange sollte der Hinweis dort erscheinen?

--TMg 23:39, 22. Okt. 2013 (CEST)

1. Ich wüsste nichts, was großartig vorab per Umfrage zu entscheiden wäre; zumal Stellungnahmen etwas Kommunikation auf enWP voraussetzen, um Erscheinungsbild und Verhalten zu kennen.
2. 1–2 Tage vor Aktivierung wäre unbedingt per sitenotice/watchlistnotice auf das geänderte Verhalten (verschwindender Balken) und die Hilfeseite hinzuweisen.
3. Eine angedachte Verschiebung dieses Abschnitts nach HD:Echo brächte nichts, weil dort die Verbesserung der Hilfeseite Thema sein sollte, sowie breite Wichtigkeit. Hier gehen zu viele Themen durcheinander, und 2014 wird das im hiesigen Archiv gut aufgehoben sein.
4. Hat man womöglich Respekt vor deWP bekommen? Ich bin unschuldig; mein erster Satz in diesem Thread sagt „Technisch okay, Kinderkrankheiten durch“.

Guten Morgen --PerfektesChaos 00:07, 23. Okt. 2013 (CEST)

Ich halte nichts von einer Trennung von „Diskussion eines Features“ einerseits und „Diskussion der Hilfe eines Features“ andererseits. Das muss Hand in Hand gehen und wird sowieso ständig von allen Diskussionsteilnehmern vermischt, da kann man es auch gleich zusammen legen. Dann ist alles zum selben Thema an einem Ort, nicht getrennt nur aufgrund der Form. --TMg 00:22, 23. Okt. 2013 (CEST)

Hallo, kurzer Hinweis zu Echo/Notifications: obwohl dieses Tool im Vergleich zum Visual Editor eine hohe Zustimmung in der Community mit ebenso hoher "Produktreife" verbindet, habe ich auf Anfrage des Entwicklerteams und nach Rücksprache mit Communitymitgliedern wie Kollegen bei Wikimedia Deutschland darum gebeten, das Anschalten des Tools noch um ein paar Wochen bis zum 19.11. aufzuschieben. Bei einem solchen Einschnitt sollte die Community immer die Gelegenheit bekommen, sich mit einem Tool vorab vertraut zu machen, derzeit dürfte der größte Teil der Benutzerschaft es hingegen wohl noch kaum kennen. Benutzer:Paul Conradi (WMDE) wird diese Phase in den kommenden Wochen unterstützen und begleiten. In den nächsten Tagen, spätestens am Wochenende, mehr dazu von ihm selbst. Ich würde mich freuen, wenn die Zusammenarbeit fruchtbar wird. Liebe Grüße, Denis Barthel (WMDE) (Diskussion) 00:56, 23. Okt. 2013 (CEST)

Wo? -- Smial (Diskussion) 14:13, 5. Nov. 2013 (CET)

Ich schätze nirgendwo laut dem hier kam es nie soweit, weil die Community sich mal wieder selbst zerfleischt hat. Benutzer:Denis Barthel (WMDE) wie gehts jetzt weiter?--Saehrimnir (Diskussion) 15:00, 5. Nov. 2013 (CET)

Hallo, bitte entschuldigt die späte Rückmeldung. Durch Pauls Rückzug kam alles etwas durcheinander, ich werde die Aufgabe von ihm übernehmen. Noch heute werde ich einen ausführlichen Kurierbeitrag zum Thema veröffentlichen, der deinen Kurierbeitrag, Saehrimnir, noch einmal etwas ausbaut (mit einem Zusatzabschnitt zu den kurz danach kommenden "Beta Features"). Es würde mich freuen, wenn wir gemeinsam uns über weitere begleitende Maßnahmen verständigen könnten. Ich denke z.B., dass eine Site-Notice rechtzeitig vor der Einführung gut und hilfreich wäre, die auf diese Seite (also Hilfe:Echo) verlinkt. Was meint ihr? Denis Barthel (WMDE) (Diskussion) 19:49, 5. Nov. 2013 (CET)

Ja eine Sitenotice hatte ich mir auch vorgestellt vielleicht noch abwarten bis die Watchlistnotice für die Schiedgerichtskandidatensuche vorbei ist. --Saehrimnir (Diskussion) 05:21, 6. Nov. 2013 (CET)

Nur für Angemeldete aber, oder? Wie lang geht die SG-Kandi-Watchlistnotice denn noch? Denis Barthel (WMDE) (Diskussion) 15:31, 6. Nov. 2013 (CET)

Ja logischerweise, weil nur angemeldete eine Beobachtungsliste haben. Von daher spielt es vielleicht wirklich nicht so die Geige. Die müsste doch bei dir auch über der Beobachtungsliste erscheinen oder? Da steht geht bis 7. 23 Uhr.--Saehrimnir (Diskussion) 16:08, 6. Nov. 2013 (CET)

Wie wäre es dann ab kommenden Montag? Denis Barthel (Diskussion) 02:44, 7. Nov. 2013 (CET)

Freitag wäre besser da wir ja die Gelegenheitsbearbeiter erwischen wollen die eher am Wochenende unterwegs sind.--Saehrimnir (Diskussion) 08:34, 7. Nov. 2013 (CET)

Ich unterstelle mal, dass hier die zunächst kommenden Wochentage gemeint sind und der Termin 19. noch steht.

Ich schrieb nicht ohne Grund schon eingangs und wiederholt in diesem Thread:

1–2 Tage vorher, also ca. am 17., eher 18.

Wenn man mehr als eine Woche vorher mit der Kiste ankommt, wird die am Dienstag ausgeblendet und ist am Freitag längst wieder vergessen. Es passiert ja auch über eine Woche lang überhaupt nichts; was sollen die Leutchen denn zur mentalen Vorbereitung anstellen? Wenn dann der 19. ran ist, kann sich niemand mehr dran erinnern, was da am 10. mal für eine Benachrichtigung war. Entscheidend ist vielmehr, dass man möglichst gleichzeitig die Benachrichtigungsbox und das graue bzw. rote neue Dings unmittelbar darüber auf dem Schirm sieht.

Die längerfristige Information erfolgte über den Kurier (dreigestreifte Bake). Großartig vorzubereiten gibt es für Normalbenutzer nichts. Also kommt zwischen eingestreifter Bake und Andreaskreuz die aktuelle Notice: Jetzt, jetzt gleich ist es soweit. Es reicht hier im Prinzip, genau gleichzeitig mit der Aktivierung zu kommen. Wichtiger ist, dass die Leute, die sich in den Tagen und Wochen danach erstmals wieder anmelden, auch noch auf den geänderten Benachrichtigungsmodus hngewiesen werden.

VG --PerfektesChaos 10:59, 7. Nov. 2013 (CET)

Ich bin da andere Meinung wir machen jetzt eine Box die wird dann zur Kenntnis genommen und ausgeblendet und dann am 17./18. nochmal eine andere. So erfassen wir auch die Benutzer die am 17 und 18 nicht aktiv sind.--Saehrimnir (Diskussion) 15:15, 7. Nov. 2013 (CET)

(linksrück) Ich finde: Ab Donnerstag oder Freitag insbesondere über das Wochenende bis zur Umstellung eine watchlist-notice anzeigen. Nach der Umstellung eine Neue für einen längeren Zeitraum (wegen mir diese am Anfang auch in leuchtendem rot ;)). Wie ist das jetzt eigentlich mit dem Kackbalken? Machen wir Standard-aktiviertes Gadget? Grüße --se4598 / ? 23:24, 11. Nov. 2013 (CET)

Mit Machen wir Standard-aktiviertes Gadget? meinst du "Kackbalken weiterhin für alle"? Bitte nicht. Dann bekommen wir die Umstellung nie fertig. — Raymond ^Disk. 07:58, 12. Nov. 2013 (CET)

Ich bin nicht sicher, wie / in welchem Zustand / mit welcher Blickfixierung man Wikipedia lesen muss, um ein rotes Feld sowie einen orange hinterlegten Hinweis, der präzise aussagt, worum es geht, nicht wahrzunehmen. Wie empfangen die Betroffenen eigentlich E-Mails? Beginnt ihr Bildschirm dann rot zu flackern? Was den Hinweis betrifft: Ich würde gar keinen im Voraus in die Sitenotice setzen, sondern dann, wenn auch das Feature aktiviert wird. Sonst weiß man ja nicht, wie man es sinnvoll nutzen soll. Aber da einem nichts weggenommen wird, wenn es eingeschaltet wird, wüsste ich auch nicht, weshalb man im Voraus vorwarnen sollte. — Pajz (Kontakt) 19:12, 14. Nov. 2013 (CET)

Also ich habe den Hinweis anfangs in Projekten übersehen, auf denen ich keine Benutzerseite hatte. Wenn der Link auf die eigene Seite blau ist, kontrastiert das rote Feld gut, aber wenn er rot ist, dann kann man es durchaus übersehen. --Schnark 09:10, 15. Nov. 2013 (CET)

Beim von Pajz erwähnten „orange hinterlegten Hinweis“ handelt es sich um ein Opt-In, dass man sich nächste Woche erst aktivieren muss. Das wurde aus den Erfahrungen der enWP nachträglich programmiert, weil viele Benutzer beklagten, dass das rote Feld für sie zu unauffällig sei.

Ich habe viel mit non-Techies zu tun, die Software bedienen müssen. Es gibt halt verschieden geschärfte Wahrnehmungen; kann man auch mit Eyetracker nachweisen. Software-Profis können eine Bildschirmseite oder ein aufpoppendes Fenster ganz anders erfassen und relevante Informationen herausfiltern als Allerweltsbenutzer.

Es ist eine reine Gewöhnungsfrage. Sobald man beim Aufbau einer Wiki-Seite halb unbewusst und fast aus den Augenwinkeln nach dem Feld schielt, ist die Standard-Hinterlegung ausreichend. Normalbenutzer gucken dort überhaupt nicht hin, sondern fokussieren auf den Seitentitel, den Einleitungsabschnitt, suchen nach dem Inhaltsverzeichnis oder der Infobox. Nicht jeder Benutzer ist in der Lage, mit einem Augenflackern auch gleichzeitig über weitere optische Elemente einer Seite zu scannen. Das Interesse gilt dem Inhaltsbereich.

Schönen Tag --PerfektesChaos 09:57, 15. Nov. 2013 (CET)

Hallo PerfektesChaos, hmm, aber „Show talk page message indicator in my toolbar“ ist bei mir in enwiki in den Einstellungen an und ich wüsste nicht, dass ich daran etwas geändert habe. Das ist doch die entsprechende Darstellung, nicht? Sicher, dass das nicht standardmäßig aktiviert ist? grüße, — Pajz (Kontakt) 10:13, 15. Nov. 2013 (CET)

Keine Ahnung; erstmal die nächste Woche abwarten und gucken, was hier auf deWP tatsächlich passiert.

Ich bin da ein schlechter Zeuge; ich bin schon seit über einem halben Jahr Echo-Empfänger, war das schon vor Programmierung des orangen Extra, und kann mich nicht mehr an irgendwelche Klicks erinnern.

Möglicherweise ist das inzwischen ein enWP-Opt-Out, vielleicht kommt es auf deWP schon als Opt-Out, vielleicht sollten wir das noch nachträglich zur Vorgabe machen.

Als es programmiert und eingeführt wurde, kam es mal als zusätzliches Opt-In.

Schaun wir einfach mal, bis dahin ein schönes Wochenende --PerfektesChaos 10:58, 15. Nov. 2013 (CET)

Nachtrag: en.wikipedia.beta.wmflabs.org hat das Häkchen standardmäßig (Opt-Out); schaun wir mal, ob das dann bei uns auch so ist. LG --PerfektesChaos 11:21, 15. Nov. 2013 (CET)

Weil es da wohl eine Terminverschiebung gab: Aktueller Termin ist Mittwoch, der 20. November, zwischen 23:00 und 1:00 Uhr unserer Zeit (22:00–00:00 UTC, 14:00–16:00 PST) (wikitech:Deployments)--se4598 / ? 16:39, 16. Nov. 2013 (CET)

Damit es nicht in Vergessenheit gerät, habe ich jetzt einmal unter Wikipedia:Administratoren/Anfragen#Watchlist-Summary_f.C3.BCr_Echo einen Vorschlag für ein Banner platziert. Input willkommen. Grüße, Denis Barthel (WMDE) (Diskussion) 17:40, 16. Nov. 2013 (CET)

Dieses Beo-Banner ist nun ja aktiv. Wie auch von einigen angemerkt, sollte man hier eine (barrierefreie) Sitenotice zum Mittwoch planen, um eine größere und möglichst vollständige Abdeckung aller Benutzer zu erhalten, auch die der Gelegenheitseditierer. Gerade Benutzer mit deaktiviertem JS stehen vor einer weitreichenden Änderung. Bestimmte Textideen dazu, ausführlichere Notiz? Grüße--se4598 / ? 01:14, 17. Nov. 2013 (CET)

Spezial:Massennachrichten

zur (Softwareneuheit) Spezial:Massennachrichten Warum nur Admins? dürfen nur Admins zu Stammtischen einladen? (in Hamburg ist das nicht so). Ich denke das sollte auch für stimmberechtige Benutzer freigegeben werden, die haben auch so ihre Kreise die sie vielleich mal gesammt zu einem Artikelproblem anschreiben wollen

mal ein mögliches Beispiel:

wär schon schön mal alle, die sich mit georeferenzierung befasssen mal kurz auf ein Problem hinweisen zu können, aber dazu müßte man dann ja Admin sein, nur leider sind die, die Georef <lagewunschbeseitigend/> machen meist keine Admins (ausser NNW), aber die, die Georef-probleme erzeugen <lagewunscherzeugend/> sind schon oft Admins (ich nenn da mal jetzt keine Namen, kann man dann gern in Kategorie:Wikipedia:Lagewunsch (nach Typ) beobachen, oder noch besser in Kategorie:Wikipedia:Lagewunsch (-)) --Jmv (Diskussion) 22:06, 19. Nov. 2013 (CET)

Naja, es geht wohl darum, dass mit der Funktion kein Spam betrieben wird. Ich hab sie schon mal kurz ausprobiert, das geht wirklich sehr fix und lässt sich, einmal gestartet, nicht mehr abbrechen. Wer es nutzen möchte, kann immer noch auf WP:B/A anfragen, von einem Admin ist das dann dort fix übertragen, sofern die Seitenliste im richtigen Format vorliegt. Verteilt wird übrigens über den Benutzer:MediaWiki message delivery. IW 22:11, 19. Nov. 2013 (CET)

Zeile xyz

wurde dieser Vorschlag weiter verfolgt und wenn ja wo? Gruß --Kino (Diskussion 08:55, 23. Nov. 2013 (CET)

Verbundene Anwendungen?

Auf Spezial:Einstellungen#mw-prefsection-personal gibt es (seit wann?) einen Hinweis auf „verbundene Anwendungen“. Die Infos dazu gibt es bisher offenbar nur auf Englisch. Vielleicht könnte ein Auskenner noch etwas dazu auf der Vorderseite schreiben? Gruß --Schniggendiller Diskussion 12:32, 24. Nov. 2013 (CET)

Ich habe mich mal dran versucht. IW 13:18, 24. Nov. 2013 (CET)

Web Storage aktiviert

• zum (Softwaretest) Für 0,05 % aller Besucher, die einen Web Storage-fähigen Browser (IE >= 8, Firefox, Chrome, Safari und Opera) nutzen, wurde Web Storage aktiviert. Damit wird getestet, ob die Technik eine Performanceverbesserung beim Surfen bringt (Bug 56397, Gerrit:94840).

wen betrifft das wirklich, gehör ich jetzt grad verdammt oft zu 0,05 % oder warum sehen die wp_seiten zu 30% sehr merkwürdig aus ? Als ob meine monobook.js oder monobook.css nicht mehr wissen was sie tun. Wenn ich dann auf refresh oder edit geh sehen sie wieder normal aus. --Jmv (Diskussion) 22:06, 19. Nov. 2013 (CET)

Ob man zu den 0,05 % gehört, kann man testen, indem man in der Browser-Konsole (FF: Strg+Umschalt+K, IE: F12) den Code mw.loader.inspect('store') ausführt. --Schnark 09:21, 20. Nov. 2013 (CET)

Wie wird das technisch geregelt? Bekommt einfach jeder 20ste Browser, der Supercookie-fähig ist und noch keines von WP hat und der die WP ansurft, so ein Supercookie verpasst? Gibt es zusätzlich ein Opt-In? Kann ich das Supercookie erzwingen, auch wenn ich nicht "erwählt" wurde? --Stefan (Diskussion) 14:31, 22. Nov. 2013 (CET)

Technische Einzelheiten gibt es im dazugehörigen Patch Set: gerrit:94840. Wenn man in seine localStorage eine ID rein bekommt, wird die wohl genutzt, so kann man das ganze vermutlich dann aktivieren oder auch bewusst deaktivieren. Der Umherirrende 15:45, 22. Nov. 2013 (CET)

Jupp, gerade mal ausgetestet: Mit localStorage.setItem( 'moduleStorageExperiment', 2 ); aktiviert und schon ging die Schnüffelei über https://bits.wikimedia.org/event.gif los. Folgendes wurde erfasst:

{
	"event": {
		"experimentGroup": 2,
		"experimentId": "2",
		"moduleLoadingTime": 3605,
		"moduleStoreEnabled": true,
		"userAgent": "Mozilla/5.0 und die üblichen Browser-Lügen." + 
"IE11 sendet übrigens nicht mehr MSIE, sondern rv:11. Weil ihr neues Schmuckstück nicht versehentlich " + 
"für einen der Vorgänger gehalten werden soll, so MS.",
		"loadedModulesCount": 119,
		"loadedModulesSize": 531503,
		"moduleStoreExpired": 0,
		"moduleStoreHits": 105,
		"moduleStoreMisses": 0
	},
	"clientValidated": true,
	"revision": <eine_nummer>,
	"schema": "ModuleStorage",
	"webHost": "commons.wikimedia.org",
	"wiki": "commonswiki"
};

-- RE rillke fragen? 02:15, 23. Nov. 2013 (CET)

Experiment scheint schon abgeschlossen zu sein, da der Code mit gerrit:97482 wieder entfernt wurde. Ergebnisse, steht dort, gibt es wohl in 2 Wochen. Der Umherirrende 22:20, 26. Nov. 2013 (CET)

Ah, dann schau doch bitte mal, und mach hier Reklame für die Ergebnis-Zusammenstellung.

Die hatten in ihrer Zusammenstellung nur die Trefferzahlen; es wurde aber nicht erfasst, wie viele Sekunden dieses JSON-Zeugs die Arbeit der betroffenen Karnickel aufgehalten hatte.

Ich halte die Aktion für dummes Zeug. Es gibt bereits ein hocheffizientes Aktualisierungssystem im Browser-Cache, und dagegen mit einer eigenen Bastelei anzustinken ist schräg.

Die in Rede stehenden Pakete sind in der Regel über mindestens eine Woche konstant und werden danach komplett neu aufgebaut und bereinigt. Das ist okay. Nur beim Hotfix muss mal nachgeladen werden. Benutzer- und Site-Ressourcen sind überhaupt nicht betroffen. Wenn die Pakete sich unter der Woche dauernd ändern, ist irgendwer dabei, der etwas verpfuscht.

Dafür kumuliert der getestete Algorithmus alle nicht mehr benötigten Ressourcen praktisch auf ewig, weil es keine Überalterung gibt.

Schönen Abend --PerfektesChaos 22:54, 26. Nov. 2013 (CET)

Ganz so effizient ist der Browser-Cache nicht, da er nur gebündelte Sammlungen von Modulen speichert (eben so, wie sie angefordert wurden), aber nicht einzelne Module. Ich bin etwa ein Drittel meiner Cache-Einträge durchgegangen, jquery.suggestions (und viele andere) sind vier Mal gespeichert, jeweils in leicht unterschiedlichen Zusammenstellungen (etwa, weil ich sowohl Seiten im ANR als auch im BNR besucht habe, und damit einmal die Module für die gesichteten Versionen mitgeladen wurden, das andere Mal nicht). Wenn die Module nur ein einziges Mal gespeichert würden statt unzählige Male, wäre das durchaus eine Verbesserung. --Schnark 09:31, 27. Nov. 2013 (CET)

Der Browser-Cache arbeitet auf Basis einer URL. Durch den ResourceLoader mit minify und combine können sich aber immer andere URLs ergeben und somit werden einige Module häufiger auf Browser-Seite vorgehalten. Das ganze ist aber noch schneller, als wenn jede Resource einzeln heruntergeladen werden muss, weil der Overhead des Connects jeder Resource wegfällt und die Anzahl der paralleln Connects nicht voll ausgeschöfft ist. Wie der localStorage jetzt genau arbeitet und ob er dieses Problem umgehen kann, habe ich mir nicht angeschaut.

Ich werde mal ausschau halten, ob ich die Ergebnisse dann mitbekomme, vielleicht stolpert aber auch schon ein Mitlesener darüber und verlinkt sie dann entsprechend. Der Umherirrende 17:28, 27. Nov. 2013 (CET)

So, wie es im Moment (Standard-Browser-Cache) ist, benötigt es erstmal die wenigste Zeit beim Laden der Seite.

Jede Seite enthält, wie wir wissen, ein Grundpaket mit Funktionen=Modulen, die allesamt sicher benötigt werden (technisch gesehen; ob man’s wirklich braucht?). Das sind typischerweise drei Blöcke der Größe 176, 160, 127 kB (ohne Überschneidungen, zum view). – Ohnehin schon ziemlich reichlich, alles JS zusammen kommt bald auf ein halbes MB, das nicht nur einmal über das Netzwerk transportiert, sondern auch ausgeführt werden muss.

• Dazu kommen dann zusätzliche seitenspezifische Konstellationen, etwa ANR, BNR, Datei:, bearbeiten oder was für den CodeEditor.
• Diese weiteren nicht immer aber in mehreren spezifischen Paketen benötigten JS-Codes, die dann wiederholt in mehreren Paketen für unterschiedliche Situationen auftreten, haben aber jedes nur ein oder zwei kB.
• Diese Pakete sind spezifisch für die Art der Seite oder der Aktion; Bearbeiten, Datei, Beo, Beiträge oder was immer.
• Dass manche Module mehrfach in unterschiedlichen Konstellationen vorkommen, aber nicht in allen Konstellationen, und sich damit spezifische Nachlad-URL ergeben, und einige Ressourcen deshalb mehrfach in Paketen enthalten sind, ist völlig klar und beabsichtigt.

Alles Gefummel, um die 170 bis 200 einzelnen Module einzeln aus dem Super-Cookie herauszufischen, kostet beim Aufbau jeder Seite Zeit. Einmalig müssen sie JSON-verpackt werden, und bei jedem Zugriff JSON-dekodiert. Die Cache-Pakete werden hingegen 1:1 an die JS-Engine übergeben.

• Deshalb bemängelte ich oben den fehlenden Zeitvergleich.

Festplattenplatz ist bei unseren Multimedia-PCs nicht so das Problem, noch nicht mal beim Foto-Smartphone. Zumindest nicht bei den in Rede stehenden paar Dutzend kB von einer Handvoll gängiger jQuery-Komponenten, die nicht in den Grundpaketen enthalten sind, jedoch von vielen aber nicht allen Seiten benötigt werden.

• Browser-Cache wird mit 50 MB oder 100 MB voreingestellt installiert, und Intensivsurfer können da ruhig 500 MB draus machen. Gängige PC haben diverse GB, gar TB zur Verfügung.

Was aber jeder Benutzer mitbekommt, ist die Verlängerung des Seitenaufbaus.

• Es kann ja mal jemand die JSON-Dekodierungszeit für die oben genannten drei Grundpakete auf einem gängigen PC stoppen. Auch der Größen-Overhead an JSON-Speicherplatz mag verglichen werden; liegt aber im Prozentbereich.
• Auf der Wiki-Seite läuft schon viel zu viel für die meisten Benutzer nicht erforderliches Zeugs zwangsweise bei jedem Seitenaufbau; so das ULS bei deutschsprachigen Benutzern in einem lateinisch verschrifteten Wiki. Wenn die konkrete Situation es erfordert oder wenn Benutzer ihre über die Grundsituation eines Wiki-Projektes hinausgehenden Wünsche per Opt-In kundgetan haben, können sie das gern dazubekommen; dann dauert es halt auch entsprechend länger, aber nur für die, die es dann auch wirklich nutzen würden.

Dem getesteten System fehlt Alterungsprozess und Löschung.

• Mit dem Speichern einer unbekannten Modulversion müssen abgelaufene Versionen des gleichen Moduls gesucht und gelöscht werden. Das wurde nicht implementiert.
• Alle jemals irgendwozu geladenen Module verbleiben auf ewig mit mindestens einer Version im Super-Cookie, auch wenn die Aktivität nie wieder stattfindet.
• Die Super-Cookies sind Domain-bezogen. Nach einmaligem Anschauen einer Seite der hawaiianischen Wikipedia oder des portugiesischsprachigen Wiktionary hat man ein halbes MB JSON in der Cookie-Sammlung, für fast alle Zeiten.
• Wenn man eine Aktivität einmal ausführte (etwa Hochladen einer Datei) und dann wochenlang nie wieder, dann wirft das Cache-Management solche Ressourcen raus, sobald der Browser-Cache zu 95 % voll ist. Das fehlt hier; schon weil das WMF-Management nur innerhalb der eigenen Domain tätig werden könnte.
• Die Gesamtgröße aller Super-Cookies und ggf. auch pro Domain ist begrenzt; beispielsweise insgesamt 10 MB und 5 MB einzeln. Nach dem 20. Ansehen einer Seite aus einem unterschiedlichen Wiki-Projekt verweigert der Browser jede weitere Speicherung im WebStorage durch irgendwen.
• Bezeichnend auch, dass man mit Abschalten des Experiments über ein halbes MB (pro Wiki) in der Storage der Versuchskarnickel zurückließ; bis zum Deinstallieren des Browsers bei Normalbenutzern.

Zusammengefasst:

• Das Zeugs kostet nur Ladezeit.
• Mittelfristig kostet das mehr und mehr und immer mehr Speicherplatz auf der Platte des Lesers, als dass irgendwas eingespart würde.

Schönen Abend --PerfektesChaos 20:34, 27. Nov. 2013 (CET)

Die Ergebnisse gibt es unter m:Research:Module storage performance, Web Storage ist demnach 156 ms schneller als der Browsercache. --Schnark 10:54, 3. Dez. 2013 (CET)

Änderungen an Beobachtungsliste (Opera)

Hallo. Gab es irgendwelche Opera betreffenden Änderungen an der Beobachtungsliste? Habe ein paar Tage nicht mehr reingeschaut, aber heute vermisse ich plötzlich den grauen Pfeil (Dreick), wenn mehrere Änderungen zusammengefasst sind. Da, wo er sein sollte, verwandelt sich zwar noch der Mauszeiger in einen Pointer, der Pfeil ist aber nicht da und die Liste lässt sich auch nicht durch Klicken aufklappen. Da wo der Pfeil sein sollte, lese ich im Code:

<span class="mw-collapsible-toggle mw-collapsible-arrow mw-enhancedchanges-arrow mw-enhancedchanges-arrow-space"/>.

In Firefox ist noch alles ok. Da lese ich an entsprechender Stelle:

<span class="mw-collapsible-toggle mw-collapsible-arrow mw-enhancedchanges-arrow mw-enhancedchanges-arrow-space mw-collapsible-toggle-collapsed" tabindex="0"></span>.

Hinter dem mw-collapsible-toggle-collapsed verbirgt sich der Pfeil als Hintergrundgrafik. Was ist da passiert? -- TZorn 13:56, 9. Dez. 2013 (CET)

Ja gibt's das? Jetzt sind die Pfeile wieder da und der Code sieht im Opera wieder aus wie bei Firefox. Hat sich also erst mal erledigt. -- TZorn 14:24, 9. Dez. 2013 (CET)

Scheinbar sind die Pfeile dann nicht zu sehen, wenn ich eine sichere Verbindung benutze, mit http funktioniert es richtig. -- TZorn 14:28, 9. Dez. 2013 (CET)

Durchsuch mal dein Benutzer-JS (Ich vermute mal du verwendest monobook? dann Benutzer:TZorn/monobook.js) nach HTTP-Links. Diese sollten auf protokollrelative Links (d.h. beginnend mit //) umgestellt werden. Sonst meckert der Browser wegen "Mixed Content" und verweigert das Laden. --Patrick87 (Diskussion) 15:53, 9. Dez. 2013 (CET)

P.S. Benutzerskripts sollten übrigens am Besten per importScriptURI() geladen werden. --Patrick87 (Diskussion) 15:56, 9. Dez. 2013 (CET)

Die Monobook-Seiten sind Relikte aus vergangenen Tagen, jetzt nutz ich Vector. Werde die Tage mal untersuchen, ob ich es durch Abschalten der Skripte gelöst bekomme. Danke für den Tipp. -- TZorn 22:46, 10. Dez. 2013 (CET)

ref name= ...

Bisher kenne ich die Syntax bei gruppierten Einzelnachweisen so: <ref name="bezeichner">, bei der wiederholung dann <ref name="bezeichner" />, also der "bezeichner" steht in Gänsefüßchen. Im Artikel Vietnamesen in Tschechien finde ich nun massenweise eine Syntax ohne die Gänsefüße, und es funktioniert (noch rechtzeitig gemerkt). Ist es neu? Es ist sicher einfacher und weniger fehleranfällig, in der Hilfe:Einzelnachweise ist jedoch nichts zu finden. -jkb- 09:37, 10. Dez. 2013 (CET)

nein das ist nicht neu, das sind feinheiten der html syntax. bspw. kannst du einer tabelle auch mit class=wikitable oder class="wikitable" definieren. Soll aber eine weitere Klasse wie sortable definiert bzw. kombiniert werden, so sind die Anführungszeichen zwingend notwendig, da der parser sonst nur eine klasse berücksichtigt und alles ab dem Leerzeichen ignoriert. falsch: class=wikitable sortable; Richtig: class="wikitable sortable". benötigst du also zwingend ein Leerzeichen für name, dann bist du gezwungen, die Anführungszeichen zu nutzen. --darkking3 ^Թ 09:42, 10. Dez. 2013 (CET)

A ja, zwar gut zu wissen, aber dann muss es in die Hilfe nicht unbedingt rein, weil man das Weglassen der Füße unter Umständen auch falsch einsetzen könnte. OK, danke! -jkb- 10:00, 10. Dez. 2013 (CET)

Man kann auch die "einfachen" nehmen, also name='bezeichner', aber name='bezeichner, also mit nur einem oder gar gemischt (name='bezeichner"), funktioniert garnicht. Auch andere, wie name=„bezeichner“ werden ignoriert. name = "bezeichner" ist auch gültig, da ist MediaWiki sehr tolerant. Aber wie gesagt, Leerzeichen oder Umlaute im Text, dann sollte mit einfachen oder doppelten Anführungszeichen geschrieben werden. Der Umherirrende 19:54, 10. Dez. 2013 (CET)

Das meinte ich mit der Fehleranfälligkeit - ich benutzte bislang die gänsefüßchenumradete Version, und da habe ich ab und zu eins davon vergessen; die Bezeichner benutze ich grundsätzlich ohne Diakritik nur in einem Wort. -jkb- 20:06, 10. Dez. 2013 (CET)

Hilfe:Tags #Attribute empfiehlt einheitlich die Gänsefüßchen. Dann muss man nicht jedes Mal nachdenken, welche Sonderzeichen dazwischen stehen dürften und welche doch wieder nicht. Wenn es mehrere Wörter sind und das erste ist eindeutig im Artikel, dann ist das Tag syntaktisch falsch, fällt aber gar nicht auf. Aber die unterschiedlichen Seitenzahlen im zweiten Wort würden dann konsequent ignoriert, und das kriegen die Autoren dann nicht mehr geregelt.

WSTM schließt automatisch alle eindeutigen Fälle in Gänsefüßchen ein.

LG --PerfektesChaos 21:02, 10. Dez. 2013 (CET)

MediaWiki:Scribunto-module-with-errors-category

Ich habe in Vorgriff auf 1.23wmf7 schon mal die Kategorie:Wikipedia:Modul mit Syntaxfehler angelegt, sie kann ab sofort in der Systemnachricht gemäß unserer Namenskonvention vereinbart werden.

LG --PerfektesChaos 21:59, 11. Dez. 2013 (CET)

Erl.: MediaWiki:Scribunto-module-with-errors-category. — Raymond ^Disk. 22:39, 11. Dez. 2013 (CET)